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 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