Subject: [nfsv4] [Technical Errata Reported] RFC7530 (5407)

From: RFC Errata System <[email-masked]>
Date: Sun, 24 Jun 2018 03:23:20 -0700 (PDT)

The following errata report has been submitted for RFC7530,
"Network File System (NFS) Version 4 Protocol".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5407

--------------------------------------
Type: Technical
Reported by: Viral Mehta <[email-masked]>

Section: 16.36

Original Text
-------------
The write
   verifier is a cookie that the client can use to determine whether the
   server has changed instance (boot) state between a call to WRITE and
   a subsequent call to either WRITE or COMMIT.  This cookie must be
   consistent during a single instance of the NFSv4 protocol service and
   must be unique between instances of the NFSv4 protocol server, where
   uncommitted data may be lost.

Corrected Text
--------------
The write
   verifier is a cookie that the client can use to determine whether the
   server has changed instance (boot) state between a call to WRITE and
   a subsequent call to either WRITE or COMMIT.  This cookie must be
   consistent during a single instance of the NFSv4 protocol service and
   must be unique between instances of the NFSv4 protocol server, where
   uncommitted data may be lost. The server implementation should not
   assume that the cookie is on per file basis.

Notes
-----
Different NFS client implementation has chosen to interpret above statement differently. Semantically, it is correct to track cookie on per file basis since both WRITE and COMMIT happens on a single file handle. But, RFC wording says that the cookie should be maintained on a per server instance basis. Either way, I believe the RFC can be more clearer for both client and server implementer.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC7530 (draft-ietf-nfsv4-rfc3530bis-35)
--------------------------------------
Title               : Network File System (NFS) Version 4 Protocol
Publication Date    : March 2015
Author(s)           : T. Haynes, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: Tom Talpey <[email-masked]>
Date: Mon, 25 Jun 2018 16:19:14 +0000

[Trimming non-list to: addresses]

> -----Original Message-----
> Type: Technical
> ...

I agree with the idea, but I don't agree with the suggested last sentence.
It's the server itself that selects the write verifier, therefore I think
this added statement is intended to be a suggestion to the *client*
implementation?

If so, the word "assumes" is a rather weak statement, and the non-normative
use of "should" is also weak. If this is to be considered as an erratum, a much
stronger statement needs to be made.

Are you suggesting that clients MUST issue the same write verifier for all
such operations to this server? Or that there is some alternative choice the
client MAY or SHOULD make, in which case, what is it?

Tom.

---

From: David Noveck <[email-masked]>
Date: Thu, 28 Jun 2018 05:53:41 -0400

> I agree with the idea, but I don't agree with the suggested last
sentence.

Note that, except for the last sentence, the corrected text is exactly the
same as the original text.

> It's the server itself that selects the write verifier,

Yes.

> therefore I think

I don't see why.  The statement begins "The server should not assume".
I have similar issues to you about text that refers to the clients' or
servers'
assumptions, but this statement is clearly directed to the server.

The notes section refers to various different client behaviors such as
Linux's
client-side tracking of this on a per-file basis.  There is nothing
objectionable
in this practice and no reason to suggest that clients "should not" or even
"SHOULD NOT" do this.

My interprepation of the last senentence is that it intends to say something
like the following.

    While clients MAY keep track of verifiers returned by the server on a
    finer-grained (e.g. per-file) basis, servers MUST maintain them on a
    per-server-instance basis, as described above.

On Mon, Jun 25, 2018 at 12:19 PM, Tom Talpey <
ttalpey=[email-masked]> wrote:

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

---

From: Trond Myklebust <[email-masked]>
Date: Thu, 28 Jun 2018 07:47:45 -0400

On Thu, 28 Jun 2018 at 05:53, David Noveck <[email-masked]> wrote:
> I have similar issues to you about text that refers to the clients' or servers'
> The notes section refers to various different client behaviors such as Linux's
> client-side tracking of this on a per-file basis.  There is nothing objectionable

That's the intention, yes. It is a follow up to a discussion on other
mailing lists where we learned that there are clients out there that
maintain the cookie on a per-filesystem basis. The clients that have
been doing this predate the NFSv4 spec, and have been applying the
same semantics to NFSv4 as they do to NFSv3.

This errata was therefore suggested as guidance to future _server_
implementors, to ensure they do not break these existing clients.

>
> On Mon, Jun 25, 2018 at 12:19 PM, Tom Talpey <ttalpey=[email-masked]> wrote:
>>

---

From: Tom Talpey <[email-masked]>
Date: Thu, 28 Jun 2018 09:19:44 -0400

> implementors, to ensure they do not break these existing clients.

Well, it needs to say this. The statement that the server "should not
assume" leaves it all open to guessing. I think Dave's suggested
sentence is good.

Tom.

---

From: "Mehta, Viral" <[email-masked]>
Date: Thu, 28 Jun 2018 13:52:04 +0000

> From: nfsv4 [mailto:[email-masked]] On Behalf Of Tom Talpey
> Sent: Thursday, June 28, 2018 6:50 PM
> To: [email-masked]
> Subject: Re: [nfsv4] [Technical Errata Reported] RFC7530 (5407)
> 
> >> Note that, except for the last sentence, the corrected text is
> >> exactly the same as the original text.
> >>
> >> The notes section refers to various different client behaviors such
> >> as Linux's client-side tracking of this on a per-file basis.  There
> >> is nothing objectionable in this practice and no reason to suggest
> >> that clients "should not" or even "SHOULD NOT" do this.
> >>
> >> My interprepation of the last senentence is that it intends to say
> >> something like the following.
> >>

Yes, this one is more clear.

> > implementors, to ensure they do not break these existing clients.

True. 

> 
> Well, it needs to say this. The statement that the server "should not assume"
> leaves it all open to guessing. I think Dave's suggested sentence is good.
> 
> Tom.
> 
> >
> >>
> >> On Mon, Jun 25, 2018 at 12:19 PM, Tom Talpey
> <ttalpey=[email-masked]> wrote:
> >>>
> >>> It's the server itself that selects the write verifier, therefore I
> >>> think this added statement is intended to be a suggestion to the
> >>> *client* implementation?
> >>>
> >>> If so, the word "assumes" is a rather weak statement, and the
> >>> non-normative use of "should" is also weak. If this is to be
> >>> considered as an erratum, a much stronger statement needs to be made.
> >>>
> >>> Are you suggesting that clients MUST issue the same write verifier
> >>> for all such operations to this server? Or that there is some
> >>> alternative choice the client MAY or SHOULD make, in which case, what is
> it?
> >>>
> >>> Tom.
> >>>