Skip to main content

Parallel NFS (pNFS) Block Disk Protection
RFC 6688

Yes

(Martin Stiemerling)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Pete Resnick)
(Ralph Droms)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)
(Wesley Eddy)

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

(Martin Stiemerling; former steering group member) Yes

Yes (for -02)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (2012-06-13 for -02)
Please s/draft/document/ in the text.

(Barry Leiba; former steering group member) No Objection

No Objection (2012-06-14 for -02)
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.

(Benoît Claise; former steering group member) No Objection

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

(Brian Haberman; former steering group member) No Objection

No Objection (for -02)

                            

(Gonzalo Camarillo; former steering group member) No Objection

No Objection (for -02)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -02)

                            

(Ralph Droms; former steering group member) No Objection

No Objection (for -02)

                            

(Robert Sparks; former steering group member) No Objection

No Objection (for -02)

                            

(Ron Bonica; former steering group member) No Objection

No Objection (for -02)

                            

(Russ Housley; former steering group member) No Objection

No Objection (for -02)

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection ()

                            

(Stephen Farrell; former steering group member) No Objection

No Objection (2012-06-14 for -02)
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."

(Stewart Bryant; former steering group member) No Objection

No Objection (for -02)

                            

(Wesley Eddy; former steering group member) No Objection

No Objection (for -02)