Rules for NFSv4 Extensions and Minor Versions
RFC 8178

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

(Spencer Dawkins) Yes

Comment (2017-05-12 for -09)
No email
send info
Russ Housley has provided a Gen-ART review for -09 version of this document, and the author is responding to those comments.

I did have one question that came up during AD Evaluation that I wanted to mention.

The first two drafts that used this mechanism (umask and xattrs) used two different idioms for discovering support. The xaddrs draft defines an xaddr_support attribute, while umask does not.

In conversations with the working group, the reasoning was that xattrs defines a number of operations, so discovering that the complete mechanism is supported before you start trying to use the attributes makes sense, while umask defines only one attribute, and for any attribute, you can find out if it is supported within a given file system by interrogating the appropriate bit position in the REQUIRED attribute supported_attrs, so there is no advantage to adding a umask_support attribute. 

That all made perfect sense to me, but the explanation was helpful enough to me that I wonder if it's worth a sentence or two, pointing out that some protocol designers may choose one idiom, while other protocol designers choose the other, and saying that's not a problem.

If the answer is "that explanation isn't needed", that won't change my ballot position from Yes, of course.

(Alia Atlas) No Objection

(Deborah Brungard) No Objection

(Ben Campbell) No Objection

Comment (2017-05-23 for -09)
No email
send info
Out of curiosity, why isn't this material more appropriate as a BCP?

(Alissa Cooper) No Objection

Comment (2017-05-24 for -09)
No email
send info
It looks like the author has proposed a number of edits in response to the gen-art review, and I'd like to see those incorporated into the next version.

I do not think this document needs to formally update RFC 7530.

(Suresh Krishnan) No Objection

Warren Kumari No Objection

(Mirja K├╝hlewind) No Objection

(Alexey Melnikov) No Objection

Comment (2017-05-24 for -09)
No email
send info

Please have a look at comments raised in ARTART Directorate review: <>

This is one of the most comprehensive documents on versionning/extensibility that I've seen. It is probably overkill for many other protocols, but I am glad that you wrote it for NFSv4+.

I only have a few minor comments:

In Section 6:

   Extensions to the most recently published NFSv4 minor version may be
   made by publishing the extension as a Proposed Standard, unless the
   minor version in question has been defined as non-extensible.  A
   document need not update the document defining the minor version,

Do you mean "need not update" in the sense of not using "Updates" header in the resulting RFC? If yes, I think you should make it clearer.

   which remains a valid description of the base variant of the minor
   version in question.

In Section 8:

   This section addresses issues related to rules #11 and #13 in the
   minor versioning rules in [RFC5661].

It would be good to add section number reference here (Section 2.7), to save readers troubles trying to figure out what #11 and #13 mean.

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

(Adam Roach) No Objection

Comment (2017-05-24 for -09)
No email
send info
I suspect this was discussed as part of the document's development, but it's clear that this new approach to versioning presents new challenges for preventing collisions of numeric constants and bitmap bit meanings. Previously (by my understanding; this isn't my area), minor versions included a full XDR, and therefore effectively carried their own complete and hermetically-sealed registry with them. With the new approach, additional documents may extend the XDR independently. I understand that IANA registration of the various codepoints in NFS is probably too daunting a task to consider reasonable, and that there is effectively an understanding in the working group that future extensions to a minor version are responsible for checking that they don't conflict with any published or pending extensions prior to publication. I don't have an issue with this approach per se, but I think it should be more clearly spelled out in this document.


- The document uses both "interversion" and "inter-version" -- please choose one and stick with it.

- As section 8 is targeted at an audience that may not be concerned with the remainder of the document, I would suggest that the introduction specifically point implementors to it.

- The first bullet under "Based on the type of server" in section 9.2 says older servers can only interoperate with older clients; when, in fact, they can clearly operate with newer clients described by the third bullet of "Based on the type of client:". Recommend: "...interoperate with clients implementing the older version. However, clients that do not implement the older version of the feature..."