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

[Magnus Westerlund <[e-mail]>]

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]>
> Sent: den 3 september 2020 14:33
> To: RFC Errata System <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Cc: Magnus Westerlund <[e-mail]>;
> [e-mail]; [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]>
> Sent: Thursday, September 3, 2020 7:25 AM
> To: [e-mail]; [e-mail]; [e-mail];
> Noveck, David <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]; rfc-
> [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]> 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