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

["Noveck, David" <[e-mail]>]

>       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:

   " 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 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
      those issues to be clearer in what is unclear or wrong and should be
      considered in the future.


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
      (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.

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 <[e-mail]>
Sent: Thursday, September 3, 2020 8:57 AM
To: Noveck, David <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Cc: [e-mail]
Subject: RE: [Errata Rejected] RFC5661 (5212)

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


> -----Original Message-----
> From: Noveck, David <[e-mail]<mailto:[e-mail]>>
> Sent: den 3 september 2020 14:33
> To: RFC Errata System <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Cc: Magnus Westerlund <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> 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.
>
> -----Original Message-----
> From: RFC Errata System <[e-mail]<mailto:[e-mail]>>
> Sent: Thursday, September 3, 2020 7:25 AM
> To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> Noveck, David <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; rfc-
> [e-mail]<mailto:[e-mail]>
> 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".
>
> --------------------------------------
> You may review the report below and at:
> 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
>
> --------------------------------------
> Status: Rejected
> Type: Technical
>
> Reported by: NFS4ERR_ROFS is not a valid error code for LAYOUTGET
> <[e-mail]<mailto:[e-mail]>> 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