Parallel NFS (pNFS) Small Computer System Interface (SCSI) Layout
RFC 8154

Note: This ballot was opened for revision 07 and is now closed.

(Spencer Dawkins) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Stephen Farrell) No Objection

Comment (2016-09-01 for -08)
No email
send info
- 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.

(Joel Jaeggli) No Objection

Comment (2016-08-31 for -08)
No email
send info
Victor Kuarsingh <victor@jvknet.com> performed the opsdir review.

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2016-09-01 for -08)
No email
send info
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!

(Terry Manderson) No Objection

(Kathleen Moriarty) No Objection

Comment (2016-08-29 for -08)
No email
send info
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.

Alvaro Retana No Objection