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

[David Noveck <[e-mail]>]

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

Will fix by adopting "inter-version".

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

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.


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

Good catch.  Will Fix.

On Wed, May 24, 2017 at 6:24 PM, Adam Roach <[e-mail]> wrote:

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