Parallel NFS (pNFS) Block Disk Protection
RFC 6688

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

(Martin Stiemerling) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2012-06-18 for -02)
No email
send info
I strongly suggest that you remove the conclusion section, which doesn't add anything to this document

(Ralph Droms) No Objection

(Wesley Eddy) No Objection

(Adrian Farrel) No Objection

Comment (2012-06-13 for -02)
No email
send info
Please s/draft/document/ in the text.

(Stephen Farrell) No Objection

Comment (2012-06-14 for -02)
No email
send info
I don't get why you use a  SHOULD in "A pNFS client operating 
system that supports block layouts SHOULD recognize this GUID
and use its presence to prevent data access to pNFS block 
devices until a layout that includes the device is received from
the MDS. " Maybe you mean "SHOULD use its presence" but it reads
as if you're saying "SHOULD recognize."

(Brian Haberman) No Objection

(Russ Housley) No Objection

Barry Leiba No Objection

Comment (2012-06-14 for -02)
No email
send info
These are non-blocking, but please consider them seriously, and feel free to chat with me about them:

-- Section 3 --
        The pNFS Block Storage partitions are identified in the GPT with 
        GUID e5b72a69-23e5-4b4d-b176-16532674fc34.  This GUID has been 
        generated by one of the draft authors for this purpose.

This won't be a "draft" when it's published, and I don't think it matters who generate the GUID.  How about this?:

        The pNFS Block Storage partitions are identified in the GPT with 
        GUID e5b72a69-23e5-4b4d-b176-16532674fc34, which has been
        generated for this purpose.

As I read section 3, what I think I get is that the whole thing defined by this document is this:
- A new GUID is defined.
- If servers put this GUID in, clients can use is presence to behave better.

Is that right?  If so, I think the last paragraph of the Introduction could be expanded by another sentence or two to make the simplicity fully clear.

Of course, if that's NOT right, then I'm missing something, so please tell me what.  :-)

Oh, and you might consider updating the date in the last paragraph of Section 3, especially if you have more recent detail of the implementation.

I don't think the Conclusions section adds anything, and would remove it.  "Conclusions" aren't customary in IETF specs, unless there's really something to say.

(Pete Resnick) No Objection

(Robert Sparks) No Objection

(Sean Turner) (was Discuss) No Objection