Subject: Re: [nfsv4] Progressing RFC errata for RFC 5661

From: Chuck Lever <[email-masked]>
Date: Thu, 24 Oct 2019 10:48:51 -0400

> On Sep 13, 2019, at 4:27 AM, Magnus Westerlund <[email-masked]> 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-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/nfsv4 <https://www.ietf.org/mailman/listinfo/nfsv4>
--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 25 Oct 2019 08:38:58 +0000

Thanks Chuck,

I will wait a week before processing your recommendations to give people a
chance to comment on these recommendations. 

I have processed David's recommendation and three from Bruce Fields. What he
sent to me directly was:

> On Thu, Oct 24, 2019 at 09:54:41AM -0400, Chuck Lever wrote:
> > 4572 - Fields
> > 4914 - Fields
> > 5476 - Fields
> 
> FWIW, those three are all typos that may be annoying but are too obvious
> to create any real confusion, so clearly fall in the "Hold for Update"
> category.
> 

Having looked at them I saw no reason to wait. 

Cheers

Magnus

On Thu, 2019-10-24 at 10:48 -0400, Chuck Lever wrote:
> > 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/ and the IESG statement on
> > 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 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?
> Are there already server implementations that reject RENAME operations in
> these cases, or do all server implementations permit RENAME?
> 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. 
> Does this errata propose a change in WG consensus? Will existing client
> implementations handle an NFS4ERR_ROFS result to LAYOUTGET?
> > (Errata ID)	Section	Type	Source of RFC	Submitted By	Publication
> > Format	Date Submitted
> > RFC5661 (2505)	12.5.4.	Technical	nfsv4 (tsv)	Michael
> > Eisler	TEXT	2010-08-31
> > RFC5661 (2751)	GLOBAL	Technical	nfsv4 (tsv)	Ricardo
> > Labiaga	TEXT	2011-03-21
> > RFC5661 (3379)	18.50.3	Technical	nfsv4 (tsv)	Asmita
> > Karandikar	TEXT	2012-10-15
> > RFC5661 (3714)	13.4.4.	Technical	nfsv4 (tsv)	Yuri
> > Radchenko	TEXT	2013-08-31
> > RFC5661 (3901)	18.43.3	Technical	nfsv4 (tsv)	Trond
> > Myklebust	TEXT	2014-02-25
> > RFC5661 (4119)	12.2.10	Technical	nfsv4 (tsv)	Christoph
> > Hellwig	TEXT	2014-09-17
> > RFC5661 (4492)	18.17.4	Technical	nfsv4 (tsv)	David Noveck
> > 	TEXT	2015-10-05
> > RFC5661 (4711)	15.1.5.5	Technical	nfsv4 (tsv)	Tom Haynes	
> > TEXT	2016-06-16
> > RFC5661 (4712)	6.2.1.3.1.	Technical	nfsv4 (tsv)	Trond
> > Myklebust	TEXT	2016-06-16
> > RFC5661 (5040)	18.46.3	Technical	nfsv4 (tsv)	Jonathan
> > Price	TEXT	2017-06-12
> > RFC5661 (5212)	15.2	Technical	nfsv4 (tsv)	NFS4ERR_ROFS
> > is not a valid error code for LAYOUTGET	TEXT	2017-12-19
> > RFC5661 (4572)	18.35.3	Editorial	nfsv4 (tsv)	Sai
> > Chakravarthy Tangudu	TEXT	2015-12-30
> > RFC5661 (4914)	14.3.3	Editorial	nfsv4 (tsv)	Dylan Simon	
> > TEXT	2017-01-22
> > RFC5661 (5476)	18.42.3	Editorial	nfsv4 (tsv)	Tigran
> > Mkrtchyan	TEXT	2018-08-23
> >  
> > Cheers
> >  
> > Magnus Westerlund
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever
> 
> 
> 
-- 
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]
----------------------------------------------------------------------