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

[Magnus Westerlund <[e-mail]>]

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

Magnus Westerlund 


----------------------------------------------------------------------
Networks, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  [phone]
Torshamnsgatan 23           | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------