Subject: [nfsv4] callback version number

From: "J. Bruce Fields" <[email-masked]>
Date: Fri, 14 May 2010 18:43:37 -0400

RFC 5661 (18.36.3) specifies that the callback use rpc program version
4.

The linux server has always used version 1.  I notice that the Linux
client expected version 1 until recently, so for interoperability I
assume that's what every other NFSv4.0 server used too?  Is that
documented in rfc 3530 anywhere?  I didn't see it on a quick skim.

So for now I'm having the linux server use version 1 for NFSv4.0
callbacks and version 4 for NFSv4.1 callbacks.

Apologies if this has already come up and I missed it.

--b.

---

From: <[email-masked]>
Date: Mon, 17 May 2010 12:56:37 -0400

I have some good news and some bad news.

Here's the good news:

In RFC3530, it is just before the acknowledgments:

           version NFS_CB {
                   void
                           CB_NULL(void) = 0;
                   CB_COMPOUND4res
                           CB_COMPOUND(CB_COMPOUND4args) = 1;
           } = 1;

It isn't in the explanatory text that I can see, but it is where you
would look if you were coding up an implementation. 

Now, here's the bad news.

RFC5662 says exactly the same thing!

So RFC5661 and RFC5662 don't agree.  The question is what to do about
it.

I'd argue that we want to create an erratum for at most one document and
we don't want to disturb any existing deployed implementation.

So if there is no 4.1 server that sends rpc version 1 or client that
won't accept rpc version 4, then we simply make the erratum for RFC5662.
You could argue that this is so fundamental that we should reissue the
document because someone might not look at the errata.  But the first
time he tested his implementation with anybody else and sent or received
a callback, he would be directed to the resolution of the issue. 

If we already have incompatibilities out in the world, I think the best
thing would be to add the erratum to RFC5661 and have it say the client
MUST accept both 1 and 4, and the server SHOULD send 1 and MUST send
either 1 or 4.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of J. Bruce Fields
Sent: Friday, May 14, 2010 6:44 PM
To: [email-masked]
Subject: [nfsv4] callback version number

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 17 May 2010 15:53:35 -0400

> RFC5662 says exactly the same thing!

Oof, thanks--I didn't think to look at the xdr!

> won't accept rpc version 4, then we simply make the erratum for RFC5662.

The linux 4.1 server has been using version 1 (queueing up a fix now!).
But I've tried to make it clear it's not production ready, and shouldn't
be turned on by distributions yet, so I doubt anyone's using it....

> a callback, he would be directed to the resolution of the issue. 

Probably so, though it may be easy to be a little lazy about testing
callbacks.

(The Linux server's gotten through a bakeathon or two without our
noticing.  Is that because all the clients accept either version, or
because it's too easy not to notice whether recalls are working?)

--b.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 17 May 2010 23:15:21 +0300

> because it's too easy not to notice whether recalls are working?)

I believe that nfsv4.1 callbacks were tested successfully with Open Solaris
clients and servers.

Benny

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 17 May 2010 16:21:19 -0400

> I believe that nfsv4.1 callbacks were tested successfully with Open Solaris

So that suggests that the Solaris 4.1 client accepts version 1.

--b.

---

From: Benny Halevy <[email-masked]>
Date: Mon, 17 May 2010 23:22:36 +0300

> So that suggests that the Solaris 4.1 client accepts version 1.

Correct (whether they care about it or not I don't know).

Benny

---

From: Robert Gordon <[email-masked]>
Date: Mon, 17 May 2010 15:31:56 -0500

Yup version 1.. 

http://src.opensolaris.org/source/xref/nfsv41/nfs41-gate/usr/src/uts/common/nfs/nfs4_kprot.h#1472

Looks like min/max is set to 1 .. 

http://src.opensolaris.org/source/xref/nfsv41/nfs41-gate/usr/src/cmd/fs.d/nfs/nfs4cbd/nfs4cbd.c#197

Robbert.

---

From: Tigran Mkrtchyan <[email-masked]>
Date: Mon, 17 May 2010 23:02:58 +0200

On 05/17/2010 10:15 PM, Benny Halevy wrote:
> On May. 17, 2010, 22:53 +0300, "J. Bruce Fields"<[email-masked]>  wrote:
and my server uses what ever client is provided.

Tigran.

---

From: Tigran Mkrtchyan <[email-masked]>
Date: Mon, 17 May 2010 23:07:57 +0200

> and my server uses what ever client is provided.
Apologies, the program number provided by client.
Version number is always 1.

Tigran.

---

From: "Labiaga, Ricardo" <[email-masked]>
Date: Mon, 17 May 2010 14:11:11 -0700

Alexandros Batsakis tells me that the Linux client accepts both
versions, routing the request for version=1 and version=4 down the same
path.

- ricardo

> From: J. Bruce Fields [mailto:[email-masked]]
> Sent: Monday, May 17, 2010 1:21 PM
> To: Benny Halevy
> Cc: [email-masked]
> Subject: Re: [nfsv4] callback version number
> 
> > >> You could argue that this is so fundamental that we should
reissue
> the
> > >> If we already have incompatibilities out in the world, I think
the
> best

---

From: <[email-masked]>
Date: Mon, 17 May 2010 17:20:05 -0400

So it sounds to me like people have been using version number one.

Since we have two conflicting documents and have to decide which one is
correct, I propose that we do what would cause least disruption and
decide that RFC 5662 is correct and decide that RFC 5661 should be
changed to say that one is the correct RPC version numbers and that a
client MAY accept version 4.

Besides the fact that version one matches RFC 3530 and RFC 5662, there
is also the fact that there is no good explanation of why version four
should be chosen.  The same RPC version will work for both minor
versions because there is an NFSv4 minor version in CB_COMPOUND and so
there is no reason to change the RPC version and it makes sense to stick
with the same RPC version that we used before.

Opinions?

If we have a consensus on that, I'll enter that as an erratum (or at
least try; I've never done it before). 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tigran Mkrtchyan
Sent: Monday, May 17, 2010 5:08 PM
To: [email-masked]
Subject: Re: [nfsv4] callback version number

On 05/17/2010 11:02 PM, Tigran Mkrtchyan wrote:
>> On May. 17, 2010, 22:53 +0300, "J. Bruce
Fields"<[email-masked]>
>> wrote:
>>>> I'd argue that we want to create an erratum for at most one
document
>>>> and

Tigran.

---

From: Robert Gordon <[email-masked]>
Date: Mon, 17 May 2010 16:24:38 -0500

Sounds good to me. 

Robert.

---

From: "Labiaga, Ricardo" <[email-masked]>
Date: Mon, 17 May 2010 14:32:44 -0700

Sounds good to me as well.

- ricardo

> From: Robert Gordon [mailto:[email-masked]]
> Sent: Monday, May 17, 2010 2:25 PM
> To: [email-masked]
> Cc: NFSv4 list

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 17 May 2010 18:07:55 -0400

> versions, routing the request for version=1 and version=4 down the same

Right, and it looks like that was introduced into the mainline kernel at
the same time as the rest of the 4.1 client code.

--b.

---

From: "J. Bruce Fields" <[email-masked]>
Date: Mon, 17 May 2010 18:33:17 -0400

> with the same RPC version that we used before.

Sounds OK to me.

One exception is the NFSv4.1 pynfs tests, which insist that the server
use version 4.  I suspect the tests haven't been used much yet?  I'm
inclined just to fix the tests to insist on version 1.

--b.

---

From: Benny Halevy <[email-masked]>
Date: Tue, 18 May 2010 15:34:17 +0300

> least try; I've never done it before). 

Agreed.  As a general rule, RFC 5662 should take priority over 5661
anyhow, as RFC 5661 says about attribute Ids:
      In the event of
      conflicts between the assigned number and [13], the latter is
      likely authoritative, but should be resolved with Errata to this
      document and/or [13].  See [44] for the Errata process.

For nfsv4.0, what was said was as follows (which also resolves
inconsistencies the same way):

1.3. Inconsistencies of this Document with Section 18
   Section 18, RPC Definition File, contains the definitions in XDR
   description language of the constructs used by the protocol.  Prior
   to Section 18, several of the constructs are reproduced for purposes
   of explanation.  The reader is warned of the possibility of errors in
   the reproduced constructs outside of Section 18.  For any part of the
   document that is inconsistent with Section 18, Section 18 is to be
   considered authoritative.

Benny

---

From: "Mike Eisler" <[email-masked]>
Date: Thu, 27 May 2010 12:51:22 -0700

Agreed. Errata has been submitted.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Benny Halevy
> Sent: Tuesday, May 18, 2010 5:34 AM
> To: [email-masked]
> Cc: [email-masked]