Subject: [nfsv4] Alvaro Retana's No Objection on draft-ietf-nfsv4-minorversion2-40: (with COMMENT)

From: "Alvaro Retana" <[email-masked]>
Date: Mon, 18 Jan 2016 13:21:16 -0800

Alvaro Retana has entered the following ballot position for
draft-ietf-nfsv4-minorversion2-40: 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-minorversion2/

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

I have no objection to this document, but the relationship with the older
versions and how versioning is handled is not clear to me.  Some parts of
the document that add to my confusion:

- Section 2. (Minor Versioning) says that “NFSv4.2 only defines
extensions to NFSv4.1”, but draft-ietf-nfsv4-versioning [*] says that
“minor versions zero and one are not extensible.”

- Section 1.1. (Scope of This Document) says that “NFSv4.2 is a superset
of NFSv4.1, with all of the new features being optional”.  Which sounds
to me as if this document is defining more optional features for NFSv4.1
and not an extension.

In any case, I am not familiar with the versioning (which is why I wanted
to learn about it), but I am now more confused than before.  It may all
be a case of terminology..

[*] Why isn’t the reference to draft-ietf-nfsv4-versioning Normative? 
Also, the reference ([NFSv4-Versioning]) is not formatted correctly.

---

From: David Noveck <[email-masked]>
Date: Mon, 18 Jan 2016 17:03:28 -0500

As that document uses the term, it (non-extensibility) means that
extensions cannot be made within v4.1., i.e., that v4.1 is fixed.  It does
not exclude the possibility that extensions will be made in
a subsequent minor version, based on NFSv4.1.

Why isn’t the reference to draft-ietf-nfsv4-versioning Normative?

One possible reason is that, if it  were, v4.2 would be held up by that
normative reference, for a fairly long time.

I don't think any reference to draft-ietf-nfsv4-versioning is necessary.
The versioning approach for NFSv4.2 was conceived and effectively set in
stone before a single line of draft-ietf-nfsv4-versioning was written.

On Mon, Jan 18, 2016 at 4:21 PM, Alvaro Retana <[email-masked]> wrote:

> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Tom Haynes <[email-masked]>
Date: Fri, 22 Jan 2016 15:54:02 -0800

Hi Alvaro,

Thanks for the review and sorry for the delay.

> On Jan 18, 2016, at 1:21 PM, Alvaro Retana <[email-masked]> wrote:
> 

We did not want to pull in all of the non-changing text from 5661.

> Also, the reference ([NFSv4-Versioning]) is not formatted correctly.

I’ve fixed the formatting by moving the reference to:

   track documents updating that document (e.g., in an RFC based on
   [I-D.ietf-nfsv4-versioning]).

   [I-D.ietf-nfsv4-versioning]
              Noveck, D., "NFSv4 Version Management", draft-ietf-
              nfsv4-versioning-03 (work in progress), January 2016.

which is the current document tracking the effort for minor versioning.

David is correct in that the reference is not normative. And while the
reference could come out, I did want to point out that a change was
in the process.

So perhaps:

   NFSv4.2 does not modify the rules applicable to the NFSv4 versioning
   process and follows the rules set out in [RFC5661] or in standard-
   track documents updating that document (e.g., in an RFC based on
   [I-D.ietf-nfsv4-versioning]).

becomes:

   NFSv4.2 does not modify the rules applicable to the NFSv4 versioning
   process and follows the rules set out in [RFC5661]. Any changes to that
   model would be published in a stand alone standard-
   track document, e.g., perhaps in an RFC based on
   [I-D.ietf-nfsv4-versioning].