Parallel NFS (pNFS) Block/Volume Layout
RFC 5663
Yes
Lars Eggert
No Objection
(Cullen Jennings)
(Dan Romascanu)
(David Ward)
(Jon Peterson)
(Lisa Dusseault)
(Magnus Westerlund)
(Pasi Eronen)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)
Note: This ballot was opened for revision 12 and is now closed.
Lars Eggert
Yes
Cullen Jennings Former IESG member
No Objection
No Objection
()
Unknown
Dan Romascanu Former IESG member
No Objection
No Objection
()
Unknown
David Ward Former IESG member
No Objection
No Objection
()
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(2008-12-04)
Unknown
Review by Christian Vogt: The specification is overall in good shape and should proceed for publication soon. I do suggest addressing the following comments, though, before forwarding the document to the RFC Editor. Technical: - Section 2.2.1 ("Volume Identification") specifies two methods for identifying a position on a disk: by positive offset starting at the beginning of the disk, and by negative offset starting at the end of the disk. The second method is limited to implementations where server and client have the same understanding of the disk size. This method could be generalized: If you defined an offset, positive or negative, to be in the context of the disk size as seen by the client, then you may potentially also support implementations where server and clients have a different understanding of the disk size. The authors may consider this. - Section 2.4 ("Crash Recovery Issues") specifies recovery procedures that a client could initiate following a server crash. These procedures apply in one specific condition, which is defined at the beginning of the section ("When the server crashes while the client holds a writable layout, and the client has written data to blocks covered by the layout, and the blocks are still in the PNFS_BLOCK_INVALID_DATA state, [then]..."). The section should also consider other conditions. It may be sufficient to explain why only the described condition requires recovery. - Section 2.4 ("Crash Recovery Issues") does not explain how a client detects a server crash. The section should briefly explain this. It may be sufficient to mention that crash detection is specified in a related document, or that it is implementation-specific. Editorial: - The specification uses undefined acronyms in a couple of places, including in the title. Those should be spelled out when mentioned the first time. Search for "pNFS", "SAN", "XDR", "LUN" to find the relevant places in the specification.
Jon Peterson Former IESG member
No Objection
No Objection
()
Unknown
Lisa Dusseault Former IESG member
No Objection
No Objection
()
Unknown
Magnus Westerlund Former IESG member
No Objection
No Objection
()
Unknown
Pasi Eronen Former IESG member
(was Discuss)
No Objection
No Objection
()
Unknown
Ron Bonica Former IESG member
No Objection
No Objection
()
Unknown
Ross Callon Former IESG member
No Objection
No Objection
()
Unknown
Russ Housley Former IESG member
No Objection
No Objection
()
Unknown
Tim Polk Former IESG member
(was No Record, Discuss)
No Objection
No Objection
()
Unknown