Re: Progressing RFC errata for RFC 5661

Chuck Lever <[email protected]>
Newsgroups gmane.ietf.nfsv4
Message-ID <[email protected]>

> On Sep 13, 2019, at 4:27 AM, Magnus Westerlund <[email protected]> wrote:
> 
> Hi,
>  
> To make progress on two aspects, both ensure that the RFC errata are dealt with, and to progress draft-ietf-nfsv4-rfc5661sesqui-msns-01 I like to do the following:
>  
> From the discussion it appears that some think that the reported errata should mostly be accepted. Based on that I want at least one WG participant to look at each errata and public state their opinion on what Status that particular errata should be in. Before doing that please read https://www.rfc-editor.org/errata-definitions/ <https://www.rfc-editor.org/errata-definitions/> and the IESG statement on errata https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/ <https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/> . 
>  
> Below you have the list of errata in reported state. When you have looked at one and judged, you respond to this email and write below the specific errata your recommendation. I will then review that errata to see if I concur with the judgment and then make it so. 

4711
The text in RFC 5661 Section 15.1.5.5 is clearly incorrect.
Compare with text in RFC 7530 Section 13.1.5.5.
I recommend this errata is assigned status Verified.
4712
The text in RFC 5661 Section 6.2.1.3.1 matches the text in RFC 7530 Section 6.2.1.3.1. Should there be a similar errata filed against RFC 7530?
Should the Notes section of the errata be added to Section 6.2.1.3.2 ?
Are there already server implementations that reject RENAME operations in these cases, or do all server implementations permit RENAME?
I recommend this errata is assigned status Rejected, and the issues addressed in rfc5661bis after further discussion.
Additional Editorial correction: The Discussion subsections of ACE4_DELETE and ACE4_DELETE are missing the word "how". 
5040
The text in RFC 5661 Section 18.46.3 is inconsistent with the text in Section 18.50.3. Section 18.50.3 clearly intends to allow DESTROY_CLIENTID to be submitted as a single operation without a SEQUENCE. 
I recommend this errata is assigned status Verified.
5212
There was no follow-up discussion of this errata on the mailing list.
Does this errata propose a change in WG consensus? Will existing client implementations handle an NFS4ERR_ROFS result to LAYOUTGET?
I recommend this errata is assigned status Rejected, and the issues addressed in rfc5661bis after further discussion.

>  
> RFC Number
> (Errata ID)
> Section
> Type
> Source of RFC <https://www.rfc-editor.org/source/>	
> Submitted By
> Publication Format
> Date Submitted
> RFC5661 (2505 <https://www.rfc-editor.org/verify_errata_select.php?eid=2505>)
> 12.5.4.
> Technical
> nfsv4 (tsv)
> Michael Eisler
> TEXT
> 2010-08-31
> RFC5661 (2751 <https://www.rfc-editor.org/verify_errata_select.php?eid=2751>)
> GLOBAL
> Technical
> nfsv4 (tsv)
> Ricardo Labiaga
> TEXT
> 2011-03-21
> RFC5661 (3379 <https://www.rfc-editor.org/verify_errata_select.php?eid=3379>)
> 18.50.3
> Technical
> nfsv4 (tsv)
> Asmita Karandikar
> TEXT
> 2012-10-15
> RFC5661 (3714 <https://www.rfc-editor.org/verify_errata_select.php?eid=3714>)
> 13.4.4.
> Technical
> nfsv4 (tsv)
> Yuri Radchenko
> TEXT
> 2013-08-31
> RFC5661 (3901 <https://www.rfc-editor.org/verify_errata_select.php?eid=3901>)
> 18.43.3
> Technical
> nfsv4 (tsv)
> Trond Myklebust
> TEXT
> 2014-02-25
> RFC5661 (4119 <https://www.rfc-editor.org/verify_errata_select.php?eid=4119>)
> 12.2.10
> Technical
> nfsv4 (tsv)
> Christoph Hellwig
> TEXT
> 2014-09-17
> RFC5661 (4492 <https://www.rfc-editor.org/verify_errata_select.php?eid=4492>)
> 18.17.4
> Technical
> nfsv4 (tsv)
> David Noveck
> TEXT
> 2015-10-05
> RFC5661 (4711 <https://www.rfc-editor.org/verify_errata_select.php?eid=4711>)
> 15.1.5.5
> Technical
> nfsv4 (tsv)
> Tom Haynes
> TEXT
> 2016-06-16
> RFC5661 (4712 <https://www.rfc-editor.org/verify_errata_select.php?eid=4712>)
> 6.2.1.3.1.
> Technical
> nfsv4 (tsv)
> Trond Myklebust
> TEXT
> 2016-06-16
> RFC5661 (5040 <https://www.rfc-editor.org/verify_errata_select.php?eid=5040>)
> 18.46.3
> Technical
> nfsv4 (tsv)
> Jonathan Price
> TEXT
> 2017-06-12
> RFC5661 (5212 <https://www.rfc-editor.org/verify_errata_select.php?eid=5212>)
> 15.2
> Technical
> nfsv4 (tsv)
> NFS4ERR_ROFS is not a valid error code for LAYOUTGET
> TEXT
> 2017-12-19
> RFC5661 (4572 <https://www.rfc-editor.org/verify_errata_select.php?eid=4572>)
> 18.35.3
> Editorial
> nfsv4 (tsv)
> Sai Chakravarthy Tangudu
> TEXT
> 2015-12-30
> RFC5661 (4914 <https://www.rfc-editor.org/verify_errata_select.php?eid=4914>)
> 14.3.3
> Editorial
> nfsv4 (tsv)
> Dylan Simon
> TEXT
> 2017-01-22
> RFC5661 (5476 <https://www.rfc-editor.org/verify_errata_select.php?eid=5476>)
> 18.42.3
> Editorial
> nfsv4 (tsv)
> Tigran Mkrtchyan
> TEXT
> 2018-08-23
>  
> Cheers
>  
> Magnus Westerlund
> _______________________________________________
> nfsv4 mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
--
Chuck Lever

_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.