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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 23 May 2017 05:45:12 -0700

Alexey Melnikov 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:
----------------------------------------------------------------------

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.

---

From: David Noveck <[email-masked]>
Date: Tue, 23 May 2017 09:34:25 -0400

>  It is probably overkill for

I'm glad that it has been written :-)

There were some people in the working group who initially thought it was
overkill for NFSv4 as well.  The reason it had to be written is that we
have a set of standards-track documents prohibiting these sorts of
extensions.

> in the resulting RFC? If yes, I think you should make it clearer

Yes.  Will clarify.

> save readers troubles trying to figure out what #11 and #13 mean.

Will add the reference.