Ballot for draft-ietf-nfsv4-scsi-layout
Yes
No Objection
Note: This ballot was opened for revision 07 and is now closed.
Victor Kuarsingh <victor@jvknet.com> performed the opsdir review.
For the security considerations, it would be good to include a few examples of the security provided by iSCSI, like encryption via IPsec (tunnel and transport mode - IMO opinion this RFC makes it difficult to set this up in an interoperable way, but that's not the responsibility of this draft), authentication, etc. RFC7143 is such a large document, just a pointer isn't as helpful here in comparison to the no security example. This is just at the comment level since the pointer is technically sufficient, but sets one up for a lot of reading.
Nits: 1) Maybe spell out what RFC5663 is about...? OLD: "[RFC6688] is unnecessary in the context of the SCSI layout type because the new layout type provides mandatory disk access protection as part of the layout type definition." NEW "pNFS Block Disk Protection [RFC6688] is unnecessary in the context of the SCSI layout type because the new layout type provides mandatory disk access protection as part of the layout type definition." 2) Why is this not a MUST? "Since SCSI storage devices are generally not capable of enforcing such file-based security, in environments where pNFS clients cannot be trusted to enforce such policies, pNFS SCSI layouts SHOULD NOT be used." 3) "Storage devices such as storage arrays can have multiple physical network ports that need not be connected to a common network" Should this be network interfaces instead on network ports? 4) "The client SHOULD track the number of retries, and if forward progress is not made, the client should abandon the attempt to get a layout and perform READ and WRITE operations by sending them to the server" Should the second 'should' also be upper case? I believe there are actually more cases (at least in this section) where upper case SHOULDs and MAYs could be used. Please check!
- 1.4: (A question for the IESG/RFC editor and not the document authors.) How will shell scripts like this be affected by new RFC formats? Have we thought about whether that'll work? Maybe the text here (and in similar cases) ought in future say that it's the plain ascii form of the RFC that needs to be fed into the script, as odd things may happen with other formats. (Note: I don't think this document ought be held up while that is discussed, if discussion is needed.) - 2.4.10: MDS is used without expansion or reference. A very quick search didn't help me figure out for sure what that means btw;-) Is it metadata-server? - 2.4.10: is "device device ID" a typo? - section 6: Is the SAM-5 reference correct? Is the XXXXX something that the RFC editor will need to fix? If so, that probably should be noted in the document so it's not forgotten. If the XXXXX means that that's a draft that's not yet final then you probably also need to tell the RFC editor to wait until the final document is published.