Requirements for Parallel NFS (pNFS) Layout Types
RFC 8434
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
Alvaro Retana No Objection
Warren Kumari No Objection
Thank you for this.
I had one readability issue -- I find:
" control communication requirements: are for a layout type the
details regarding information on layouts, stateids, file metadata,
and file data which must be communicated between the metadata
server and the storage devices."
to be very hard to read. I tried for a while to break this up into multiple sentences but was unable. It would be nice if the authors could succeed where I failed...
(Benjamin Kaduk; former steering group member) (was Discuss) Yes
Thanks for addressing my discuss/comments; changing to Yes as promised. (Original ballot text preserved below for posterity.) DISCUSS Thanks for writing this up; it's good to have better clarity about the requirements placed on various actors in pNFS. I will change to Yes once this issue is resolved: Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, and we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific requirements are being changed/added; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661]". COMMENT Section 1 Such matters are defined in a standards-track layout type specification. This could be read as saying that there is a single document, which happens to be a layout-type specification and standards-track, that gives guidance on how layout types differ. Maybe: Each layout type will define the needed details for its usage in the specifciation for that layout type; layout type specifications are always standards-track RFCs. Section 3.3 [..] If the document does not impose implementation requirements sufficient to ensure that these semantic requirements are met, it is not appropriate for the working group to allow the document to move forward. Maybe "it is not appropriate for publication as an IETF-stream RFC"? o If the metadata server does not have a means to invalidate a stateid issued to the storage device to keep a particular client from accessing a specific file, then the layout type specification has to document how the metadata server is going to fence the client from access to the file on that storage device. Is the stateid issued to the storage device or to the client? Section 4 leaves me confused about what exactly from RFC 5661 is being updated. That is, the subsections look to be some discussion about how the "real requirements" (i.e., this document) apply to the given layout types, we are told that these sections do not update the specification for those specific layout types. So it's hard to get a clear picture about which specific things are being updated; this leads me to wonder if the top-level Section 4 should not say "This section updates Section 12 of [RFC5661]" and leave the "discussed here only to illuminate the updates made to Section 12 of [RFC5661[". Section 6 [...] In the latter case, I/O access writes are reflected in layouts [...] s/writes/rights/
(Spencer Dawkins; former steering group member) Yes
(Adam Roach; former steering group member) No Objection
Thanks to all involved for the work they did on this document. I had the same confusion as Benjamin, and support his discuss. I also found one very small grammar nit in §2: > (file) data: is that part of the file system object which contains > the data to read or written. Change to either "...to read or write." or "...to be read or written."
(Alexey Melnikov; former steering group member) No Objection
(Alissa Cooper; former steering group member) No Objection
(Ben Campbell; former steering group member) No Objection
(Deborah Brungard; former steering group member) No Objection
(Eric Rescorla; former steering group member) No Objection
(Ignas Bagdonas; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
Please use RFC8174 boilerplate and maybe double-check the use of lower case MUSTs and MAYs, e.g. should this sentence in the security considerations maybe use an upper case MUST: "The layout type specification must ensure that only data accesses consistent with the NFSV4.1 security model are allowed."
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection