Subject: [nfsv4] Adam Roach's No Objection on draft-ietf-nfsv4-versioning-09: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 24 May 2017 15:24:02 -0700

Adam Roach has entered the following ballot position for
draft-ietf-nfsv4-versioning-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-versioning/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

Editorial: 

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

---

From: David Noveck <[email-masked]>
Date: Thu, 25 May 2017 09:15:59 -0400

> choose one and stick with it.

Will fix by adopting "inter-version".

> specifically point implementors to it.

Propose adding the following new (final) paragraph to the Introduction.

The rules in this document supersede previous rules regarding
minor versions.  The new rules concerning protocol extension and
minor versions are summarized in Section 3 while rules regarding
the interaction of minor versions appear in Section 8.

> implement the older version of the feature..."

Good catch.  Will Fix.