Subject: [nfsv4] [Errata Rejected] RFC5661 (5212)

From: RFC Errata System <[email-masked]>
Date: Thu, 3 Sep 2020 04:24:36 -0700 (PDT)

The following errata report has been rejected for RFC5661,
"Network File System (NFS) Version 4 Minor Version 1 Protocol".

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

--------------------------------------
Status: Rejected
Type: Technical

Reported by: NFS4ERR_ROFS is not a valid error code for LAYOUTGET <[email-masked]>
Date Reported: 2017-12-19
Rejected by: Magnus Westerlund (IESG)

Section: 15.2

Original Text
-------------
   | LAYOUTGET            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT,      |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,      |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,          |
   |                      | NFS4ERR_INVAL, NFS4ERR_IO,                 |
   |                      | NFS4ERR_LAYOUTTRYLATER,                    |
   |                      | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, |
   |                      | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,       |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP,            |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION,                 |
   |                      | NFS4ERR_RECALLCONFLICT,                    |
   |                      | NFS4ERR_REP_TOO_BIG,                       |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP,                |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS,    |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE                         |

Corrected Text
--------------
   | LAYOUTGET            | NFS4ERR_ACCESS, NFS4ERR_ADMIN_REVOKED,     |
   |                      | NFS4ERR_BADIOMODE, NFS4ERR_BADLAYOUT,      |
   |                      | NFS4ERR_BADXDR, NFS4ERR_BAD_STATEID,       |
   |                      | NFS4ERR_DEADSESSION, NFS4ERR_DELAY,        |
   |                      | NFS4ERR_DELEG_REVOKED, NFS4ERR_DQUOT,      |
   |                      | NFS4ERR_FHEXPIRED, NFS4ERR_GRACE,          |
   |                      | NFS4ERR_INVAL, NFS4ERR_IO,                 |
   |                      | NFS4ERR_LAYOUTTRYLATER,                    |
   |                      | NFS4ERR_LAYOUTUNAVAILABLE, NFS4ERR_LOCKED, |
   |                      | NFS4ERR_MOVED, NFS4ERR_NOFILEHANDLE,       |
   |                      | NFS4ERR_NOSPC, NFS4ERR_NOTSUPP,            |
   |                      | NFS4ERR_OLD_STATEID, NFS4ERR_OPENMODE,     |
   |                      | NFS4ERR_OP_NOT_IN_SESSION,                 |
   |                      | NFS4ERR_RECALLCONFLICT,                    |
   |                      | NFS4ERR_REP_TOO_BIG,                       |
   |                      | NFS4ERR_REP_TOO_BIG_TO_CACHE,              |
   |                      | NFS4ERR_REQ_TOO_BIG,                       |
   |                      | NFS4ERR_RETRY_UNCACHED_REP, NFS4ERR_ROFS,  |
   |                      | NFS4ERR_SERVERFAULT, NFS4ERR_STALE,        |
   |                      | NFS4ERR_TOOSMALL, NFS4ERR_TOO_MANY_OPS,    |
   |                      | NFS4ERR_UNKNOWN_LAYOUTTYPE,                |
   |                      | NFS4ERR_WRONG_TYPE                         |

Notes
-----
It could be argued that the OPEN takes care of a NFS4ERR_ROFS for a LAYOUTGET of a LAYOUTIOMODE4_RW, but that does not explain why WRITE is allowed to return a NFS4ERR_ROFS.

With the Flex File Layout Type, the storage device depends on the metadata server enforcing the read-only filesystem semantics. An NFSv3 WRITE to the storage device might be accepted even though the filesystem might be RO. Further, if a snapshot is taken, the storage device might not be aware of the fact that a data file is in a snapshot.

Currently, if the underlying filesystem determines that the LAYOUTGET for a LAYOUTIOMODE4_RW is going to return NFS4ERR_ROFS, to be spec compliant, it MUST convert the error code to NFS4ERR_SERVERFAULT.  The client may then decide to perform IO through the metadata server with NFSv4 WRITE calls, which will in turn get a NFS4ERR_ROFS error. This change pushes the responsibility to be on the LAYOUTGET and allows the client to inform the application of an error earlier.

AD Comments:
This topic requires WG discussion and establishment of consensus. Thus for future document update. 

 --VERIFIER NOTES-- 
   This topic requires WG discussion and establishment of consensus. Thus for future document update.

--------------------------------------
RFC5661 (draft-ietf-nfsv4-minorversion1-29)
--------------------------------------
Title               : Network File System (NFS) Version 4 Minor Version 1 Protocol
Publication Date    : January 2010
Author(s)           : S. Shepler, Ed., M. Eisler, Ed., D. Noveck, Ed.
Category            : PROPOSED STANDARD
Source              : Network File System Version 4
Area                : Transport
Stream              : IETF
Verifying Party     : IESG

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 3 Sep 2020 12:33:28 +0000

The explanatory text, with I agree with, indicates why this
Should be held over for update, presumably in rf5661bis.  However the subject line says "rejected" and I don't understand why.

-----Original Message-----
From: RFC Errata System <[email-masked]> 
Sent: Thursday, September 3, 2020 7:25 AM
To: [email-masked]; [email-masked]; [email-masked]; Noveck, David <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [Errata Rejected] RFC5661 (5212)

NetApp Security WARNING: This is an external email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

The following errata report has been rejected for RFC5661, "Network File System (NFS) Version 4 Minor Version 1 Protocol".

Reported by: NFS4ERR_ROFS is not a valid error code for LAYOUTGET <[email-masked]> Date Reported: 2017-12-19 Rejected by: Magnus Westerlund (IESG)

Section: 15.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

AD Comments:

 --VERIFIER NOTES--

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Sep 2020 12:56:57 +0000

Hi David,

I might have misjudged this one. However, from my perspective it falls under 
the following part from the instructions:

" or proposes a change to the RFC that should be done by publishing a new RFC 
that replaces the current RFC."
See Rejected:
https://www.rfc-editor.org/errata-definitions/

It could likely have been put in Held for Document update. However, I prefer 
those issues to be clearer in what is unclear or wrong and should be 
considered in the future.

You editors of the 8881bis will have to go though all Erratas against RFC 5661 
to determine which are already addressed and which are non-relevant and which 
needs considerations and discussion. Even before this one we had one Errata 
(https://www.rfc-editor.org/errata/eid2751) which was a significant change of 
the protocol that got rejected  due to it going beyond established consensus 
at time of publication.

If you feel strongly we can change it to Held for Document update.

Cheers

Magnus

> From: Noveck, David <[email-masked]>
> Sent: den 3 september 2020 14:33
> To: RFC Errata System <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Cc: Magnus Westerlund <[email-masked]>;
> [email-masked]; [email-masked]
> Subject: RE: [Errata Rejected] RFC5661 (5212)
>
> The explanatory text, with I agree with, indicates why this Should be held
> over for update, presumably in rf5661bis.  However the subject line says
> "rejected" and I don't understand why.
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
>
> The following errata report has been rejected for RFC5661, "Network File
> System (NFS) Version 4 Minor Version 1 Protocol".
>
> https://protect2.fireeye.com/v1/url?k=9b44cc6b-c5f451f3-9b448cf0-
> 861fcb972bfc-cf4c513c9d5ddf90&q=1&e=7b26cc7e-e55f-4723-adbc-
> 3949013eb251&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid5212
>
> Reported by: NFS4ERR_ROFS is not a valid error code for LAYOUTGET
> <[email-masked]> Date Reported: 2017-12-19 Rejected by: Magnus
> Westerlund (IESG)
>
> Section: 15.2
>
> Original Text
> -------------
> It could be argued that the OPEN takes care of a NFS4ERR_ROFS for a
> LAYOUTGET of a LAYOUTIOMODE4_RW, but that does not explain why
> WRITE is allowed to return a NFS4ERR_ROFS.
>
> With the Flex File Layout Type, the storage device depends on the metadata
> server enforcing the read-only filesystem semantics. An NFSv3 WRITE to the
> storage device might be accepted even though the filesystem might be RO.
> Further, if a snapshot is taken, the storage device might not be aware of 
> the
> fact that a data file is in a snapshot.
>
> Currently, if the underlying filesystem determines that the LAYOUTGET for a
> LAYOUTIOMODE4_RW is going to return NFS4ERR_ROFS, to be spec
> compliant, it MUST convert the error code to NFS4ERR_SERVERFAULT.  The
> client may then decide to perform IO through the metadata server with
> NFSv4 WRITE calls, which will in turn get a NFS4ERR_ROFS error. This change
> pushes the responsibility to be on the LAYOUTGET and allows the client to
> inform the application of an error earlier.
>
> AD Comments:
>    This topic requires WG discussion and establishment of consensus. Thus 
> for
> future document update.
>
>

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 3 Sep 2020 14:27:59 +0000

>       I might have misjudged this one.

Since your judgment differs from mine, you obviously did 😊

>       However, from my perspective it falls under the following part from the instructions:

It does.

>       It could likely have been put in Held for Document update.

It fits under that definition as well.   That’s a real problem with this approach.  Some things fit under multiple classifications.

>       However, I prefer

I think that is clear whichever  choice is made.

>       You editors of the 8881bis

We’ve been calling it rfc5661bis.  8881 was rfc5661 sesqui and I don’t know the Latin for “two  and a half”.

>       will have to go though all Erratas against RFC 5661
   to determine which are already addressed and which are non-relevant and which
   needs considerations and discussion.

True.

>       Even before this one we had one Errata

That was different in that there it was clear that the new approach was outside the existing
Consensus.

In this case, there is some reasonable concern that it might be outside the existing consensus,
Do the working group has to discuss and decide the issue.

-----Original Message-----
From: Magnus Westerlund <[email-masked]>
Sent: Thursday, September 3, 2020 8:57 AM
To: Noveck, David <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Errata Rejected] RFC5661 (5212)

Hi David,

Cheers

Magnus

> From: Noveck, David <[email-masked]<mailto:[email-masked]>>
> To: RFC Errata System <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> Cc: Magnus Westerlund <[email-masked]<mailto:[email-masked]>>;
> [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> From: RFC Errata System <[email-masked]<mailto:[email-masked]>>
> To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
> Noveck, David <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; rfc-
> [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> Date Reported: 2017-12-19 Rejected by: Magnus
> Westerlund (IESG)
>
> Section: 15.2
>
> Original Text
> -------------

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Sep 2020 07:19:35 +0000

Hi,

I will ask the RFC-editor to change this one to Held for document update.

Cheers

Magnus

On Thu, 2020-09-03 at 14:27 +0000, Noveck, David wrote:
> It fits under that definition as well.   That’s a real problem with this
> approach.  Some things fit under multiple classifications.
>  
> However, I prefer
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Alice Russo <[email-masked]>
Date: Fri, 4 Sep 2020 13:59:56 -0700

Re: https://www.rfc-editor.org/errata/eid5212

FYI, the status has been changed to "Held for Document Update" per a request from Magnus Westerlund.

RFC Editor/ar

> On Sep 3, 2020, at 5:33 AM, Noveck, David <[email-masked]> wrote:
>