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

[David Noveck <[e-mail]>]

>  It is probably overkill for
> many other protocols, but I am glad that you wrote it for NFSv4+.

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.

> 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

Yes.  Will clarify.

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

Will add the reference.

On Tue, May 23, 2017 at 8:45 AM, Alexey Melnikov <[e-mail]>
wrote:

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