Skip to main content

Parallel NFS (pNFS) Block Disk Protection
draft-ietf-nfsv4-pnfs-block-disk-protection-03

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 IESG member
Yes
Yes (for -02) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2012-06-13 for -02) Unknown
Please s/draft/document/ in the text.
Barry Leiba Former IESG member
No Objection
No Objection (2012-06-14 for -02) Unknown
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 IESG member
No Objection
No Objection (2012-06-18 for -02) Unknown
I strongly suggest that you remove the conclusion section, which doesn't add anything to this document
Brian Haberman Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Ralph Droms Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Robert Sparks Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection (for -02) Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Stephen Farrell Former IESG member
No Objection
No Objection (2012-06-14 for -02) Unknown
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 IESG member
No Objection
No Objection (for -02) Unknown

                            
Wesley Eddy Former IESG member
No Objection
No Objection (for -02) Unknown