Subject: [nfsv4] NFSv4.2-15: "obsolete" vs "must not implement"

From: Mike Kupfer <[email-masked]>
Date: Mon, 15 Oct 2012 11:26:25 -0700

The text in Section 12 (page 46 of the -15 I-D) distinguishes between
"obsolete" and "must not implement".  But on page 47 both OBS and MNI
are shown to mean "must not implement".  Shouldn't the text on page 47
say that OBS means OBSOLETE?

mike

---

From: "Haynes, Tom" <[email-masked]>
Date: Mon, 15 Oct 2012 19:13:18 +0000

> say that OBS means OBSOLETE?

You are correct in that it is wrong.

Just choking on saying "OBSOLETE to implement". :->

How about

OBS OBSOLETE, might be required to implement

I.e., most OBSOLETE ones can be dropped by the client, e.g., READ,
but MUST be supported by the server.

Some of the callbacks could be dropped by the server, but MUST
be supported by the client.

---

From: Mike Kupfer <[email-masked]>
Date: Tue, 16 Oct 2012 11:37:07 -0700

> Just choking on saying "OBSOLETE to implement". :->

Heh. :-)

> be supported by the client.

Hmm.  That wording's a bit vague for my tastes.

Here's a counter-proposal:

    OBS    OBSOLETE, required to accept

This works because we only have one obsolete operation, READ, and
"required to accept" describes the requirements around READ.

Here's a second, more general, counter-proposal:

    OBS    OBSOLETE, see operation-specific text

Then spell out the requirements for each operation in an appropriate
subsection of Section 13.  For READ, this would be a new subsection
("Operation 25: READ - Read from File").  It would say little more than
READ is optional for clients and required for servers, and is otherwise
the same as in minor version 1.

mike

---

From: "Myklebust, Trond" <[email-masked]>
Date: Tue, 16 Oct 2012 18:46:11 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mike Kupfer
> Sent: Tuesday, October 16, 2012 2:37 PM
> To: Haynes, Tom
> Cc: <[email-masked]>
> Subject: Re: [nfsv4] NFSv4.2-15: "obsolete" vs "must not implement"
> 
> Haynes, Tom wrote:
> 
> > I.e., most OBSOLETE ones can be dropped by the client, e.g., READ, but
> > MUST be supported by the server.
> >
> > Some of the callbacks could be dropped by the server, but MUST be
> > supported by the client.
> 
> ("Operation 25: READ - Read from File").  It would say little more than READ is
> optional for clients and required for servers, and is otherwise the same as in
> minor version 1.

That still doesn't make sense. If READ is optional to implement for the client, then that means READ_PLUS would be mandatory to implement on the server. Otherwise, you might end up with a client that has no way to read...

Trond

---

From: "Haynes, Tom" <[email-masked]>
Date: Tue, 16 Oct 2012 19:11:18 +0000

> That still doesn't make sense. If READ is optional to implement for the client, then that means READ_PLUS would be mandatory to implement on the server. Otherwise, you might end up with a client th…

OBSOLETE means it was REQUIRED in the previous release.

The challenge would be for new implementations, do they support it or not?

I'm leaning towards RECOMMENDED, it has a nice description. But I am
fine with staying with my proposal...

---

From: "Myklebust, Trond" <[email-masked]>
Date: Tue, 16 Oct 2012 19:21:39 +0000

> From: Haynes, Tom
> Sent: Tuesday, October 16, 2012 3:11 PM
> To: Myklebust, Trond
> Cc: Mike Kupfer; nfsv4 list
> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Mike Kupfer
> >> ("Operation 25: READ - Read from File").  It would say little more
> >> than READ is optional for clients and required for servers, and is
> >> otherwise the same as in minor version 1.
> >
> > That still doesn't make sense. If READ is optional to implement for the
> client, then that means READ_PLUS would be mandatory to implement on
> the server. Otherwise, you might end up with a client that has no way to
> read...
> >
> > Trond
> 
> 

I'm saying that marking READ as OBSOLETE in NFSv4.2 is premature. It MUST always be supported by both the client and the server, since neither can rely on READ_PLUS being implemented by their counterparts. We can mark READ as OBSOLETE in 4.3 if we decide to make READ_PLUS mandatory to implement.

> I'm leaning towards RECOMMENDED, it has a nice description. But I am fine
> with staying with my proposal...

I'm not sure that I understand how even RECOMMENDED is useful here. Clearly we believe that READ_PLUS has value, or we wouldn't be putting it in the protocol. Why do we need to supplement that information?

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 16 Oct 2012 19:27:29 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Myklebust, Trond
> Sent: Tuesday, October 16, 2012 12:22 PM
> To: Haynes, Tom
> Cc: nfsv4 list
> > >> Then spell out the requirements for each operation in an
> > >> appropriate subsection of Section 13.  For READ, this would be a
> > >> new subsection ("Operation 25: READ - Read from File").  It would
> > >> say little more than READ is optional for clients and required for
> > >> servers, and is otherwise the same as in minor version 1.
> > >
> > the server. Otherwise, you might end up with a client that has no way
> > to read...
> > >
> > > Trond
> >
> >
> I'm saying that marking READ as OBSOLETE in NFSv4.2 is premature. It MUST
> always be supported by both the client and the server, since neither can rely on
> READ_PLUS being implemented by their counterparts. We can mark READ as
> OBSOLETE in 4.3 if we decide to make READ_PLUS mandatory to implement.
[Spencer] 

Right.  Need two "releases" to completely remove an operation.

Spencer

> I'm not sure that I understand how even RECOMMENDED is useful here. Clearly
> we believe that READ_PLUS has value, or we wouldn't be putting it in the
> protocol. Why do we need to supplement that information?
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Mike Kupfer <[email-masked]>
Date: Fri, 19 Oct 2012 15:45:53 -0700

> Right.  Need two "releases" to completely remove an operation.

I'm still confused about where we are with READ and WRITE.

In the first paragraph of Section 12 the -16 I-D has

   The designation of OBSOLETE if implemented is reserved
   for those operations which are defined in either NFSv4.0 or NFSV4.1,
   can be implemented in NFSv4.2, and are intended to be MUST NOT be
   implemented in NFSv4.3.

Note "*can* be implemented in NFSv4.2".  But as Trond pointed out, since
READ_PLUS and WRITE_PLUS are optional, READ and WRITE MUST be
implemented.

How about

   The designation of OBSOLETE if implemented is reserved for those
   operations which are defined in either NFSv4.0 or NFSV4.1, and are
   intended to be MUST NOT be implemented in NFSv4.3.  Such operations
   can be implemented in NFSv4.2 if they were previously RECOMMENDED or
   OPTIONAL, and they MUST be implemented if they were previously
   REQUIRED.
   
Oh, I just noticed a typo: "V"->"v" in "NFSV4.1".

mike

---

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 20 Oct 2012 06:19:04 +0000

> Oh, I just noticed a typo: "V"->"v" in "NFSV4.1".

I agree with the spirit, just not the language.

An issue is that we defined "obsolete" in Section 2.7 of 5661 as meaning
MUST NOT implement. And I am using "OBSOLETE" as an end-of-life
statement.

Looking at the relevant clauses in Section 2.7 of 5661, we see:

   5.   Minor versions must not delete operations.
   8.   Minor versions may declare an operation MUST NOT be implemented.
   9.   Minor versions may downgrade features from REQUIRED to
        RECOMMENDED, or RECOMMENDED to OPTIONAL.
   10.  Minor versions may upgrade features from OPTIONAL to
        RECOMMENDED, or RECOMMENDED to REQUIRED.
   12.  Except for infrastructural changes, a minor version must not
        introduce REQUIRED new features.

And while the spirit is that we take two releases to remove an operation,
Rule 8 allows us to do so right away.

I think I need to change OBSOLETE to be EOL - it preserves the text
within Rule 8.

And then we need to mark READ and WRITE as EOL - RECOMMENDED.
So your " they MUST be implemented if they were previously REQUIRED"
is too strong.

So, taking some snipping liberty:

   The following tables summarize the operations of the NFSv4.2 protocol
   and the corresponding designation of REQUIRED, RECOMMENDED, and
   OPTIONAL to implement or either END-OF-LIFE or MUST NOT implement.
   The designation of END-OF_LIFE is reserved for those operations which
   are defined in either NFSv4.0 or NFSv4.1 and are intended to be
   classified as MUST NOT be implemented in NFSv4.3.  The designation of
   MUST NOT implement is reserved for those operations that were defined
   in either NFSv4.0 or NFSV4.1 and MUST NOT be implemented in NFSv4.2.

…

   EOL  END-OF-LIFE and will be modified with either REC or OPT

…

   +----------------------+---------------------+----------------------+
   | Operation            | EOL, REQ, REC, OPT, | Feature (REQ, REC,   |
   |                      | or MNI              | or OPT)              |
   +----------------------+---------------------+----------------------+

   | READ                 | EOL (REC)           |                      |
   | WRITE                | OBS (REC)           |                      |
   +----------------------+---------------------+----------------------+

---

---

From: "Myklebust, Trond" <[email-masked]>
Date: Sat, 20 Oct 2012 15:34:50 +0000

>    EOL  END-OF-LIFE and will be modified with either REC or OPT

I read your definition above of READ and WRITE being EOL, as doing 2
things:

1) They are no longer required to be implemented in 4.2.
2) They will no longer be permitted to be implemented in 4.3.

W.R.T. point 1): a 4.2 client/server that doesn't implement READ or
WRITE is not guaranteed to interoperate with all 4.2 servers/clients. So
how does declaring the operations to be RECOMMENDED make any difference
to the protocol other than introducing uncertainty?

W.R.T. point 2): what if we decide that READ_PLUS and WRITE_PLUS are not
mature enough to be made mandatory in 4.3? Suddenly our hands are tied,
and we have basically added a label of MANDATORY-TO-IMPLEMENT-IN-4.3 to
READ_PLUS/WRITE_PLUS from the get-go in 4.2. To me that violates the
spirit of rule 12, which was put in place to allow us to try out new
operations and make sure that they are useful before any decision is
made to make them mandatory.

I'd therefore urge that we drop the END-OF-LIFE label in this case, and
just defer to minor version 3 the decision of whether or not to make
READ/WRITE MUST NOT implement.

-- 
Trond Myklebust
Linux NFS client maintainer

NetApp
[email-masked]
www.netapp.com

---

From: Chuck Lever <[email-masked]>
Date: Sat, 20 Oct 2012 12:02:00 -0400

> READ/WRITE MUST NOT implement.

I agree.  Interoperability is the prime purpose of this document.  The minor version 2 draft should leave the READ and WRITE operations labeled as "REQUIRED to implement" no matter what our future intentions are.  Those intentions should not be documented here.

Note the first full paragraph on page 52 (draft 16) ends with "along with other relevant explanatory text within this either specification or that of NFSv4.1 [1]."  The phrase "within this either" should probably be "within either this".

-- 
Chuck Lever
chuck[dot]lever[at]oracle[dot]com

---

From: "Haynes, Tom" <[email-masked]>
Date: Sat, 20 Oct 2012 16:23:34 +0000

On Oct 20, 2012, at 10:34 AM, "Myklebust, Trond" <[email-masked]<mailto:[email-masked]>> wrote:

…

…

  | READ                 | EOL (REC)           |                      |
  | WRITE                | OBS (REC)           |                      |

"are intended to be classified" is different from "MUST be classified".

The first indicates that we can change our mind, the second states that
we cannot.

We want to be able to phase out an operation - we agree that it has
to occur over two releases - specifically for this very reason, we may
be wrong and have to keep it.

So we are dropping READ and WRITE from REQUIRED to RECOMMENDED.

In NFSv4.3, the plan of record is to mark them as MUST NOT implement. Nothing
in what we have put in place requires us to do so.

And lets use RFC 2119 to define these:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

In my mind, there is no uncertainty - if you know your server will only be used by
clients that only support READ_PLUS and WRITE_PLUS, make an informed
decision and go with it. I'm not here to hold your hand.

No, they are marked as OPTIONAL and we do not have to promote them
to either RECOMMENDED or REQUIRED.

Our hands are tied in that we cannot introduce READ_PLUS and WRITE_PLUS
in NFSv4.2 as REQUIRED. We could introduce them as RECOMMENDED,
but I don't see what that gains us and I like the mantra that all new features
are optional.

And I'd rather not be in the situation where someone objects to dropping
them from NFSv4.3 because we never announced in NFSv4.2 that we
planned to drop them.

NetApp
[email-masked]<mailto:[email-masked]>
www.netapp.com

---

From: spencer shepler <[email-masked]>
Date: Sat, 20 Oct 2012 12:47:17 -0700

Let me summarize where I think we are on this topic…

We are working through the issue of introducing an operation 4.2 that
directly replaces (and in this case enhances) a 4.1 operation.
Following the minor versioning rules in 5661, we are unable to mark
the new operation as mandatory to implement and thus providing a
direct replacement.   This means that for at least one minor version,
we will have both of the operations; the existing operation marked as
mandatory to implement and the new operation marked as recommended.
To this point, I have not seen anyone advocate that this is broken.

An argument has been made that in 4.3 we will likely mark the old
operation as mandatory not to implement.  That is a decision we will
make in the future.  I have not seen anyone advocate for an explicit
statement in 4.2 (and I prefer that there not be one).  It is a
decision we will make in the course of 4.3 definition. given that we
may introduce an operation that directly replaces both of the
operations as defined in 4.2 it is prudent not to make such statements
if they can be avoided.

The only issue raised so far with this approach is the possibility of
future complaints about the removal (mandatory not to implement) of
operations without prior notice.  Let’s not worry about that now.  We
will have plenty of time to discuss that and many other topics in the
course of 4.3 definition.

Spencer

On Sat, Oct 20, 2012 at 9:23 AM, Haynes, Tom <[email-masked]> wrote:
>
> On Oct 20, 2012, at 10:34 AM, "Myklebust, Trond"
> <[email-masked]> wrote:
>