Subject: [nfsv4] Minor versioning rules in NFSv4.2

From: "Haynes, Tom" <[email-masked]>
Date: Thu, 8 Nov 2012 22:50:32 +0000

I've added a new section (in GitHub) for the minor versioning rules.

Of interest to the earlier discussion for NFSv4.2:

      <t>
        Minor versions may declare an operation to be DEPRECATED, which
        indicates the plan to remove the operation in the next release.
        Such a labeling does not effect whether the operation is
        REQUIRED or RECOMMENDED or OPTIONAL. I.e., an operation may
        be both REQUIRED for the given minor version and earmarked
        for MUST NOT be implemented for the next release. Note that
        this two minor version release approach is put in place to
        mitigate design and implementation mistakes. As such, even
        if an operation is marked DEPRECATED in a given minor release,
        it may end up not being marked as MUST NOT implement in
        the next minor version.
      </t>

      <t>
        Minor versions may downgrade features from REQUIRED to
        RECOMMENDED, or RECOMMENDED to OPTIONAL. Also, if a feature
        was marked as DEPRECATED in a prior minor version, it may
        be downgraded from REQUIRED to OPTIONAL.
      </t>

And ...

+
+      <t hangText='DEP'>
+        Also DEPRECATED for future versions.
+      </t>

-      <c>READ                 </c> <c> EOL (REC) </c> <c>              </c>
+      <c>READ                 </c> <c> REQ (DEP) </c> <c>              </c>

-      <c>WRITE                </c> <c> OBS (REC) </c> <c>              </c>
+      <c>WRITE                </c> <c> REQ (DEP) </c> <c>              </c>

Not sure I'm fully happy with this, but it should be a good start.

---

From: "Myklebust, Trond" <[email-masked]>
Date: Fri, 9 Nov 2012 02:49:14 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Haynes, Tom
> Sent: Thursday, November 08, 2012 5:51 PM
> To: nfsv4 list
> Subject: [nfsv4] Minor versioning rules in NFSv4.2
> 

"a non-binding intention to remove..."?

>         Such a labeling does not effect whether the operation is

affect

> Not sure I'm fully happy with this, but it should be a good start.

Still not sure that we need any of this. As such, I'd very much prefer that we drop the "DEPRECATED" term.

Trond

---

From: "Noveck, David" <[email-masked]>
Date: Fri, 9 Nov 2012 11:13:29 -0500

> Not sure I'm fully happy with this, but it should be a good start.

I think it is a good start.  Please look at my slight course-correction
below.

Trond said:
> Still not sure that we need any of this. 

I think we need something in this area.

> As such, I'd very much prefer that we drop the "DEPRECATED" term.

I agree.  If I was going to "deprecate" an operation, I'd say something like 
"This operation is a mess" or "How could anyone ever think this was a good idea?".  
I can't see saying anything like that about READ or WRITE.

Maybe what we want to talk about is "OBSOLESCENT operations".

How about something like:

      <t>
        Minor versions may declare an operation to be OBSOLESCENT,
        which indicates an intention to remove the operation
        (i.e. make it MANDATORY TO NOT implement) in a subsequent
        minor version.  Such labeling is separate from the question of
        whether the operation is REQUIRED or RECOMMENDED or OPTIONAL
        in the current minor version. An operation may be both REQUIRED 
        for the given minor version and marked OBSOLESCENT, with the
        expectation that it will be MANDATORY TO NOT implement
        in the next (or other subsequent) minor version. 
      </t>
      <t>
        Note that the early notification of operation obsolescence
        is put in place to mitigate the effects of design and implementation 
        mistakes, and to allow protocol development to adapt to unexpected 
        changes in the pace of implementation. Even if an operation is marked 
        OBSOLESCENT in a given minor version, it may end up not being marked
        MANDATORY TO NOT implement in the next minor version.  In unusual 
        circumstances, it might not be marked OBSOLESCENT in a 
        subsequent minor version, and never become MANDATORY TO NOT implement
      </t>

      <t>
        Minor versions may downgrade features from REQUIRED to
        RECOMMENDED, from RECOMMENDED to OPTIONAL, or from OPIONAL
        to MANDATORY TO NOT implement. Also, if a feature
        was marked as OBSOLESCENT in the prior minor version, it may
        be downgraded from REQUIRED to OPTIONAL from RECOMMENDED
        to MANDATORY TO NOT implement, or from REQUIRED to 
        MANDATORY TO NOT implement
      </t>

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Haynes, Tom
Sent: Thursday, November 08, 2012 5:51 PM
To: nfsv4 list
Subject: [nfsv4] Minor versioning rules in NFSv4.2

      <t>

      <t>

And ...

+
+      <t hangText='DEP'>

Not sure I'm fully happy with this, but it should be a good start.
_______________________________________________
nfsv4 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Fri, 9 Nov 2012 12:26:31 -0500

Sent from my iPhone

>        MANDATORY TO NOT implement

I like this language.  It touches on all the right points.

---

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 10 Nov 2012 23:47:34 +0000

Okay, changes up on GitHub.com, will appear in the next release.

---

From: Mike Kupfer <[email-masked]>
Date: Sat, 10 Nov 2012 16:44:03 -0800

> On Nov 9, 2012, at 11:13 AM, "Noveck, David" <[email-masked]> wrote:
[...]

> I like this language.  It touches on all the right points.

Agreed.

mike