Subject: [nfsv4] Progressing draft-ietf-nfsv4-rfc5661sesqui-msns-01

From: Magnus Westerlund <[email-masked]>
Date: Fri, 13 Sep 2019 08:43:19 +0000

Hi,

This is my proposal for how we make progress of
draft-ietf-nfsv4-rfc5661sesqui-msns.

Step 1: Verification that it is ready. This contains two pieces. 

A.	Magnus to review the scoping text of the changes
B.	Authors to verify that all potentially relevant Errata has been
dealt with.

Step 2: Run a 2-week WG last call when 1 is done, and any necessary edits
have happened

Step 3: Publication request it (I will do the writeups as that should only
require tweaking the previous one)

I hope this is acceptable to everyone. I will do my part of Step 1 by end of
next week. 

Document authors what I want from you from B) above is the following. 

There are 39 Erratas according to: 

https://www.rfc-editor.org/verify_errata_select.php?rfc=5661
<https://www.rfc-editor.org/verify_errata_select.php?rfc=5661&rec_status=15&
area_acronym=tsv&wg_acronym=nfsv4&presentation=table>
&rec_status=15&area_acronym=tsv&wg_acronym=nfsv4&presentation=table

they are listed below. 

Please go through all of these errata and for each one indicate if:

*	The issue is outside of the scope of where this document make
changes
*	The issue in the errata has dealt with by incorporating some set of
changes
*	The issue is no longer relevant due to other changes
*	Something else. 

This is simply to make sure that these haven't been overlooked. 

RFC5661 (2291 <https://www.rfc-editor.org/verify_errata_select.php?eid=2291>
)

18.36.3.

Technical

nfsv4 (tsv)

Michael Eisler

TEXT

2010-05-27

RFC5661 (2005 <https://www.rfc-editor.org/verify_errata_select.php?eid=2005>
)

15.1.11.3

Technical

nfsv4 (tsv)

Michael Eisler

TEXT

2010-01-17

RFC5661 (2299 <https://www.rfc-editor.org/verify_errata_select.php?eid=2299>
)

18.45.3.

Technical

nfsv4 (tsv)

Michael Eisler

TEXT

2010-06-03

RFC5661 (2326 <https://www.rfc-editor.org/verify_errata_select.php?eid=2326>
)

15.1.16.3

Technical

nfsv4 (tsv)

Tom Haynes

TEXT

2010-07-13

RFC5661 (2327 <https://www.rfc-editor.org/verify_errata_select.php?eid=2327>
)

6.4.3.1

Technical

nfsv4 (tsv)

Tom Haynes

TEXT

2010-07-13

RFC5661 (3208 <https://www.rfc-editor.org/verify_errata_select.php?eid=3208>
)

GLOBAL

Technical

nfsv4 (tsv)

Benny Halevy

TEXT

2012-05-02

RFC5661 (5467 <https://www.rfc-editor.org/verify_errata_select.php?eid=5467>
)

15.2

Technical

nfsv4 (tsv)

Trond Myklebust

TEXT

2018-08-17

RFC5661 (3558 <https://www.rfc-editor.org/verify_errata_select.php?eid=3558>
)

15.1.4.2

Editorial

nfsv4 (tsv)

Cal Turney

TEXT

2013-03-19

RFC5661 (2006 <https://www.rfc-editor.org/verify_errata_select.php?eid=2006>
)

15.1.1.3

Editorial

nfsv4 (tsv)

Michael Eisler

TEXT

2010-01-17

RFC5661 (2062 <https://www.rfc-editor.org/verify_errata_select.php?eid=2062>
)

2.10.6.1.3

Editorial

nfsv4 (tsv)

Peter Varga

TEXT

2010-03-04

RFC5661 (2249 <https://www.rfc-editor.org/verify_errata_select.php?eid=2249>
)

12.5.5.2.1.5

Editorial

nfsv4 (tsv)

Michael Eisler

TEXT

2010-05-10

RFC5661 (2280 <https://www.rfc-editor.org/verify_errata_select.php?eid=2280>
)

10.4

Editorial

nfsv4 (tsv)

Paul J Gilliam

TEXT

2010-05-20

RFC5661 (2324 <https://www.rfc-editor.org/verify_errata_select.php?eid=2324>
)

2.10.6.2

Editorial

nfsv4 (tsv)

Trond Myklebust

TEXT

2010-07-12

RFC5661 (2328 <https://www.rfc-editor.org/verify_errata_select.php?eid=2328>
)

15.1.16

Editorial

nfsv4 (tsv)

Tom Haynes

TEXT

2010-07-13

RFC5661 (2330 <https://www.rfc-editor.org/verify_errata_select.php?eid=2330>
)

3.3.7

Editorial

nfsv4 (tsv)

Tom Haynes

TEXT

2010-07-14

RFC5661 (2548 <https://www.rfc-editor.org/verify_errata_select.php?eid=2548>
)

18.36.3

Editorial

nfsv4 (tsv)

J. Bruce Fields

TEXT

2010-10-11

RFC5661 (4215 <https://www.rfc-editor.org/verify_errata_select.php?eid=4215>
)

22.1

Editorial

nfsv4 (tsv)

Tom Haynes

TEXT

2014-12-30

Status: Reported <https://www.rfc-editor.org/status_type_desc.html>  (14)

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

Status:  <https://www.rfc-editor.org/status_type_desc.html> Held for
Document Update (7)

RFC Number
(Errata ID)

Section

Type

Source of RFC <https://www.rfc-editor.org/source/> 

Submitted By

Publication Format

Date Submitted

RFC5661 (3065 <https://www.rfc-editor.org/verify_errata_select.php?eid=3065>
)

12.7.4

Technical

nfsv4 (tsv)

David Black

TEXT

2011-12-27

RFC5661 (3066 <https://www.rfc-editor.org/verify_errata_select.php?eid=3066>
)

12.7.4

Technical

nfsv4 (tsv)

David Black

TEXT

2011-12-27

RFC5661 (3067 <https://www.rfc-editor.org/verify_errata_select.php?eid=3067>
)

18.42.3

Technical

nfsv4 (tsv)

David Black

TEXT

2011-12-27

RFC5661 (3068 <https://www.rfc-editor.org/verify_errata_select.php?eid=3068>
)

18.42.3

Technical

nfsv4 (tsv)

David Black

TEXT

2011-12-27

RFC5661 (4118 <https://www.rfc-editor.org/verify_errata_select.php?eid=4118>
)

20.12.3

Technical

nfsv4 (tsv)

Christoph Hellwig

TEXT

2014-09-17

RFC5661 (3064 <https://www.rfc-editor.org/verify_errata_select.php?eid=3064>
)

12.5.4

Editorial

nfsv4 (tsv)

David Black

TEXT

2011-12-27

RFC5661 (3653 <https://www.rfc-editor.org/verify_errata_select.php?eid=3653>
)

13.4.2

Editorial

nfsv4 (tsv)

Kanda Motohiro

TEXT

2013-06-15

Status: Rejected <https://www.rfc-editor.org/status_type_desc.html>  (1)

RFC Number
(Errata ID)

Section

Type

Source of RFC <https://www.rfc-editor.org/source/> 

Submitted By

Publication Format

Date Submitted

RFC5661 (2722 <https://www.rfc-editor.org/verify_errata_select.php?eid=2722>
)

15.2

Editorial

nfsv4 (tsv)

Ricardo Labiaga

TEXT

2011-02-15

---

From: David Noveck <[email-masked]>
Date: Fri, 13 Sep 2019 07:17:53 -0400

I'm fine with this proposal.  I can start on 1B right away.  I also expect
to be done by the end of next week.

On Fri, Sep 13, 2019, 4:43 AM Magnus Westerlund <
[email-masked]> wrote:

>    1. Magnus to review the scoping text of the changes
>    2. Authors to verify that all potentially relevant Errata has been
>    dealt with.
>
> I hope this is acceptable to everyone. I will do my part of Step 1 by end
> of next week.
>
>
>
> https://www.rfc-editor.org/verify_errata_select.php?rfc=5661&rec_status=15&area_acronym=tsv&wg_acronym=nfsv4&presentation=table
>
> they are listed below.
>
>
>
>    - The issue is outside of the scope of where this document make changes
>    - The issue in the errata has dealt with by incorporating some set of
>    changes
>    - The issue is no longer relevant due to other changes
>    - Something else.
>
>
>
> This is simply to make sure that these haven’t been overlooked.
>
>
>
>
>
> RFC5661 (2291
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2291>)
>
> 18.36.3.
>
> Technical
>
> nfsv4 (tsv)
>
> Michael Eisler
>
> TEXT
>
> 2010-05-27
>
> RFC5661 (2005
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2005>)
>
> 15.1.11.3
>
> Technical
>
> nfsv4 (tsv)
>
> Michael Eisler
>
> TEXT
>
> 2010-01-17
>
> RFC5661 (2299
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2299>)
>
> 18.45.3.
>
> Technical
>
> nfsv4 (tsv)
>
> Michael Eisler
>
> TEXT
>
> 2010-06-03
>
> RFC5661 (2326
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2326>)
>
> 15.1.16.3
>
> Technical
>
> nfsv4 (tsv)
>
> Tom Haynes
>
> TEXT
>
> 2010-07-13
>
> RFC5661 (2327
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2327>)
>
> 6.4.3.1
>
> Technical
>
> nfsv4 (tsv)
>
> Tom Haynes
>
> TEXT
>
> 2010-07-13
>
> RFC5661 (3208
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3208>)
>
> GLOBAL
>
> Technical
>
> nfsv4 (tsv)
>
> Benny Halevy
>
> TEXT
>
> 2012-05-02
>
> RFC5661 (5467
> <https://www.rfc-editor.org/verify_errata_select.php?eid=5467>)
>
> 15.2
>
> Technical
>
> nfsv4 (tsv)
>
> Trond Myklebust
>
> TEXT
>
> 2018-08-17
>
> RFC5661 (3558
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3558>)
>
> 15.1.4.2
>
> Editorial
>
> nfsv4 (tsv)
>
> Cal Turney
>
> TEXT
>
> 2013-03-19
>
> RFC5661 (2006
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2006>)
>
> 15.1.1.3
>
> Editorial
>
> nfsv4 (tsv)
>
> Michael Eisler
>
> TEXT
>
> 2010-01-17
>
> RFC5661 (2062
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2062>)
>
> 2.10.6.1.3
>
> Editorial
>
> nfsv4 (tsv)
>
> Peter Varga
>
> TEXT
>
> 2010-03-04
>
> RFC5661 (2249
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2249>)
>
> 12.5.5.2.1.5
>
> Editorial
>
> nfsv4 (tsv)
>
> Michael Eisler
>
> TEXT
>
> 2010-05-10
>
> RFC5661 (2280
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2280>)
>
> 10.4
>
> Editorial
>
> nfsv4 (tsv)
>
> Paul J Gilliam
>
> TEXT
>
> 2010-05-20
>
> RFC5661 (2324
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2324>)
>
> 2.10.6.2
>
> Editorial
>
> nfsv4 (tsv)
>
> Trond Myklebust
>
> TEXT
>
> 2010-07-12
>
> RFC5661 (2328
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2328>)
>
> 15.1.16
>
> Editorial
>
> nfsv4 (tsv)
>
> Tom Haynes
>
> TEXT
>
> 2010-07-13
>
> RFC5661 (2330
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2330>)
>
> 3.3.7
>
> Editorial
>
> nfsv4 (tsv)
>
> Tom Haynes
>
> TEXT
>
> 2010-07-14
>
> RFC5661 (2548
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2548>)
>
> 18.36.3
>
> Editorial
>
> nfsv4 (tsv)
>
> J. Bruce Fields
>
> TEXT
>
> 2010-10-11
>
> RFC5661 (4215
> <https://www.rfc-editor.org/verify_errata_select.php?eid=4215>)
>
> 22.1
>
> Editorial
>
> nfsv4 (tsv)
>
> Tom Haynes
>
> TEXT
>
> 2014-12-30
> *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)
>
> 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
> Status: Held for Document Update
> <https://www.rfc-editor.org/status_type_desc.html> (7)
>
>
> *RFC Number(Errata ID)*
>
> *Section*
>
> *Type*
>
> *Source of RFC <https://www.rfc-editor.org/source/>*
>
> *Submitted By*
>
> *Publication Format*
>
> *Date Submitted*
>
> RFC5661 (3065
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3065>)
>
> 12.7.4
>
> Technical
>
> nfsv4 (tsv)
>
> David Black
>
> TEXT
>
> 2011-12-27
>
> RFC5661 (3066
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3066>)
>
> 12.7.4
>
> Technical
>
> nfsv4 (tsv)
>
> David Black
>
> TEXT
>
> 2011-12-27
>
> RFC5661 (3067
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3067>)
>
> 18.42.3
>
> Technical
>
> nfsv4 (tsv)
>
> David Black
>
> TEXT
>
> 2011-12-27
>
> RFC5661 (3068
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3068>)
>
> 18.42.3
>
> Technical
>
> nfsv4 (tsv)
>
> David Black
>
> TEXT
>
> 2011-12-27
>
> RFC5661 (4118
> <https://www.rfc-editor.org/verify_errata_select.php?eid=4118>)
>
> 20.12.3
>
> Technical
>
> nfsv4 (tsv)
>
> Christoph Hellwig
>
> TEXT
>
> 2014-09-17
>
> RFC5661 (3064
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3064>)
>
> 12.5.4
>
> Editorial
>
> nfsv4 (tsv)
>
> David Black
>
> TEXT
>
> 2011-12-27
>
> RFC5661 (3653
> <https://www.rfc-editor.org/verify_errata_select.php?eid=3653>)
>
> 13.4.2
>
> Editorial
>
> nfsv4 (tsv)
>
> Kanda Motohiro
>
> TEXT
>
> 2013-06-15
> *RFC Number(Errata ID)*
> *Section*
> *Type*
> *Source of RFC <https://www.rfc-editor.org/source/>*
>
> *Submitted By*
>
> *Publication Format*
>
> *Date Submitted*
>
> RFC5661 (2722
> <https://www.rfc-editor.org/verify_errata_select.php?eid=2722>)
>
> 15.2
>
> Editorial
>
> nfsv4 (tsv)
>
> Ricardo Labiaga
>
> TEXT
>
> 2011-02-15
>
>
>

---

From: David Noveck <[email-masked]>
Date: Sun, 15 Sep 2019 05:47:52 -0400

Here is my review of existing errata and their relationship to
rfc5661sesqui, as required in part 1B of your plan.  Given the way gmail
handles the output of errata search I had to delete the material in later
columns to be able to easily add my sesqui-related evaluation to each
individual errata.

As you can see, I have not found any errata that are applicable to
rfc5661sesqui.    This wasn't very surprising given that none of the errata
mentioned any text in Section 11 or the other small sections revised by
this document.   I understand Chuck will be doing a similar review in
parallel and can inform us if I missed anything.

I've been assuming that the plan you presented is still in effect, although
some recent mail from Spencer, while not objecting to your plan, does seem
at variance with it.  In any case, the fact thay none of the errata for
rfc5661 are relevant to rfc5661sesqui needs to be taken note of to avoid
overcomplicating the process.

*First the Veified Errata:*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*RFC Number (Errata ID)*

*DN: Outside the scope of changes made by this document. *

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document. *

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*RFC Number (Errata ID)*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*DN: Outside the scope of changes made by this document.*

*RFC Number (Errata ID)*

 *DN: Outside the scope of changes made by this document.*

On Fri, Sep 13, 2019 at 7:17 AM David Noveck <[email-masked]> wrote:

>> Step 3: Publication request it (I will do the writeups as that should
>> only require tweaking the previous one)
>>
>>
>>

---

From: Chuck Lever <[email-masked]>
Date: Mon, 16 Sep 2019 15:20:27 -0400

Hi Magnus, et al.

> On Sep 13, 2019, at 4:43 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
>  
> This is my proposal for how we make progress of draft-ietf-nfsv4-rfc5661sesqui-msns.
>  
> Magnus to review the scoping text of the changes
> Authors to verify that all potentially relevant Errata has been dealt with.

Here is my response to Step 1B.

I examined 39 errata targeting RFC 5661 by viewing this page: https://www.rfc-editor.org/errata_search.php?rfc=5661 <https://www.rfc-editor.org/errata_search.php?rfc=5661> . I binned each errata into one of two categories:
The errata might be within the scope of rfc5661sesqui. It should be discussed further by the WG.
2006 clarifies discussion of returning NFS4ERR_DELAY on a SEQUENCE operation.
3379 removes "layouts" from 18.50.3 to avoid persisting a lease when a client explicitly requests lease termination.
4572 correct 18.35.3
5040 adds DESTROY_CLIENTID to the list of operations that cannot appear first in a COMPOUND.
5467 adds NFS4ERR_EXPIRED to the list of allowable error codes for LAYOUTGET.
The errata is outside of the scope of where rfc5661sesqui makes changes.
All others
The five errata for which I'd prefer to see more discussion have to do with state management in some way, and are therefore possibly within the scope of rfc5661sesqui, which changes/clarifies the way state management is handled during filesystem or IP migration. It is not clear to me whether these errata are relevant to sesqui or can be deferred to rfc5661bis.

All other errata I found to be not within the scope of rfc5661sesqui. However, for Verified errata targeting RFC 5661: is there a process for retargeting them to the RFC that rfc5661sesqui will become? If rfc5661sesqui obsoletes RFC 5661, how do implementers find these errata?

> Step 2: Run a 2-week WG last call when 1 is done, and any necessary edits have happened
>  
> Step 3: Publication request it (I will do the writeups as that should only require tweaking the previous one)
>  
> I hope this is acceptable to everyone. I will do my part of Step 1 by end of next week. 
>  
> https://www.rfc-editor.org/verify_errata_select.php?rfc=5661&rec_status=15&area_acronym=tsv&wg_acronym=nfsv4&presentation=table <https://www.rfc-editor.org/verify_errata_select.php?rfc=5661&rec_status=15&area_acronym=tsv&wg_acronym=nfsv4&presentation=table>
> they are listed below. 
>  
> The issue is outside of the scope of where this document make changes
> The issue in the errata has dealt with by incorporating some set of changes
> The issue is no longer relevant due to other changes
> Something else. 
>  
> RFC5661 (2291 <https://www.rfc-editor.org/verify_errata_select.php?eid=2291>)
> 18.36.3.
> Technical
> nfsv4 (tsv)
> Michael Eisler
> TEXT
> 2010-05-27
> RFC5661 (2005 <https://www.rfc-editor.org/verify_errata_select.php?eid=2005>)
> 15.1.11.3
> Technical
> nfsv4 (tsv)
> Michael Eisler
> TEXT
> 2010-01-17
> RFC5661 (2299 <https://www.rfc-editor.org/verify_errata_select.php?eid=2299>)
> 18.45.3.
> Technical
> nfsv4 (tsv)
> Michael Eisler
> TEXT
> 2010-06-03
> RFC5661 (2326 <https://www.rfc-editor.org/verify_errata_select.php?eid=2326>)
> 15.1.16.3
> Technical
> nfsv4 (tsv)
> Tom Haynes
> TEXT
> 2010-07-13
> RFC5661 (2327 <https://www.rfc-editor.org/verify_errata_select.php?eid=2327>)
> 6.4.3.1
> Technical
> nfsv4 (tsv)
> Tom Haynes
> TEXT
> 2010-07-13
> RFC5661 (3208 <https://www.rfc-editor.org/verify_errata_select.php?eid=3208>)
> GLOBAL
> Technical
> nfsv4 (tsv)
> Benny Halevy
> TEXT
> 2012-05-02
> RFC5661 (5467 <https://www.rfc-editor.org/verify_errata_select.php?eid=5467>)
> 15.2
> Technical
> nfsv4 (tsv)
> Trond Myklebust
> TEXT
> 2018-08-17
> RFC5661 (3558 <https://www.rfc-editor.org/verify_errata_select.php?eid=3558>)
> 15.1.4.2
> Editorial
> nfsv4 (tsv)
> Cal Turney
> TEXT
> 2013-03-19
> RFC5661 (2006 <https://www.rfc-editor.org/verify_errata_select.php?eid=2006>)
> 15.1.1.3
> Editorial
> nfsv4 (tsv)
> Michael Eisler
> TEXT
> 2010-01-17
> RFC5661 (2062 <https://www.rfc-editor.org/verify_errata_select.php?eid=2062>)
> 2.10.6.1.3
> Editorial
> nfsv4 (tsv)
> Peter Varga
> TEXT
> 2010-03-04
> RFC5661 (2249 <https://www.rfc-editor.org/verify_errata_select.php?eid=2249>)
> 12.5.5.2.1.5
> Editorial
> nfsv4 (tsv)
> Michael Eisler
> TEXT
> 2010-05-10
> RFC5661 (2280 <https://www.rfc-editor.org/verify_errata_select.php?eid=2280>)
> 10.4
> Editorial
> nfsv4 (tsv)
> Paul J Gilliam
> TEXT
> 2010-05-20
> RFC5661 (2324 <https://www.rfc-editor.org/verify_errata_select.php?eid=2324>)
> 2.10.6.2
> Editorial
> nfsv4 (tsv)
> Trond Myklebust
> TEXT
> 2010-07-12
> RFC5661 (2328 <https://www.rfc-editor.org/verify_errata_select.php?eid=2328>)
> 15.1.16
> Editorial
> nfsv4 (tsv)
> Tom Haynes
> TEXT
> 2010-07-13
> RFC5661 (2330 <https://www.rfc-editor.org/verify_errata_select.php?eid=2330>)
> 3.3.7
> Editorial
> nfsv4 (tsv)
> Tom Haynes
> TEXT
> 2010-07-14
> RFC5661 (2548 <https://www.rfc-editor.org/verify_errata_select.php?eid=2548>)
> 18.36.3
> Editorial
> nfsv4 (tsv)
> J. Bruce Fields
> TEXT
> 2010-10-11
> RFC5661 (4215 <https://www.rfc-editor.org/verify_errata_select.php?eid=4215>)
> 22.1
> Editorial
> nfsv4 (tsv)
> Tom Haynes
> TEXT
> 2014-12-30
> 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)
> 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
> Status: Held for Document Update <https://www.rfc-editor.org/status_type_desc.html> (7)
> 
> RFC Number
> (Errata ID)
> Section
> Type
> RFC5661 (3065 <https://www.rfc-editor.org/verify_errata_select.php?eid=3065>)
> 12.7.4
> Technical
> nfsv4 (tsv)
> David Black
> TEXT
> 2011-12-27
> RFC5661 (3066 <https://www.rfc-editor.org/verify_errata_select.php?eid=3066>)
> 12.7.4
> Technical
> nfsv4 (tsv)
> David Black
> TEXT
> 2011-12-27
> RFC5661 (3067 <https://www.rfc-editor.org/verify_errata_select.php?eid=3067>)
> 18.42.3
> Technical
> nfsv4 (tsv)
> David Black
> TEXT
> 2011-12-27
> RFC5661 (3068 <https://www.rfc-editor.org/verify_errata_select.php?eid=3068>)
> 18.42.3
> Technical
> nfsv4 (tsv)
> David Black
> TEXT
> 2011-12-27
> RFC5661 (4118 <https://www.rfc-editor.org/verify_errata_select.php?eid=4118>)
> 20.12.3
> Technical
> nfsv4 (tsv)
> Christoph Hellwig
> TEXT
> 2014-09-17
> RFC5661 (3064 <https://www.rfc-editor.org/verify_errata_select.php?eid=3064>)
> 12.5.4
> Editorial
> nfsv4 (tsv)
> David Black
> TEXT
> 2011-12-27
> RFC5661 (3653 <https://www.rfc-editor.org/verify_errata_select.php?eid=3653>)
> 13.4.2
> Editorial
> nfsv4 (tsv)
> Kanda Motohiro
> TEXT
> 2013-06-15
> RFC5661 (2722 <https://www.rfc-editor.org/verify_errata_select.php?eid=2722>)
> 15.2
> Editorial
> nfsv4 (tsv)
> Ricardo Labiaga
> TEXT
> 2011-02-15
>  
> _______________________________________________
> 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: Tue, 17 Sep 2019 08:53:24 +0000

Hi,

Thanks for engaing in resolving this. It appears that it will require
at least some discussion in the WG if the Erratas that you Chuck thinks
may require conisderation compared to David. 

Would proposals for text changes towards the draft help clarify what
needs to be done, or other discussion needed? 

On Mon, 2019-09-16 at 15:20 -0400, Chuck Lever wrote:
> 
> All other errata I found to be not within the scope of rfc5661sesqui.
> However, for Verified errata targeting RFC 5661: is there a process
> for retargeting them to the RFC that rfc5661sesqui will become? If
> rfc5661sesqui obsoletes RFC 5661, how do implementers find these 
> errata?

I looked at what I can do in my interface, and I can unfortunately not
duplicate and change the RFC number. I will contact the RFC-editor to
see if they can do something in the backend to duplicate a set of
Erratas to the future RFC. 

Cheers

Magnus

> > Step 3: Publication request it (I will do the writeups as that
> > should only require tweaking the previous one)
> >  
> > RFC5661 (2291)	18.36.3.	Technical	nfsv4 (tsv)	Mic
> > hael Eisler	TEXT	2010-05-27
> > RFC5661 (2005)	15.1.11.3	Technical	nfsv4 (tsv)	Mic
> > hael Eisler	TEXT	2010-01-17
> > RFC5661 (2299)	18.45.3.	Technical	nfsv4 (tsv)	Mic
> > hael Eisler	TEXT	2010-06-03
> > RFC5661 (2326)	15.1.16.3	Technical	nfsv4 (tsv)	Tom
> > Haynes	TEXT	2010-07-13
> > RFC5661 (2327)	6.4.3.1	Technical	nfsv4 (tsv)	Tom
> > Haynes	TEXT	2010-07-13
> > RFC5661 (3208)	GLOBAL	Technical	nfsv4 (tsv)	Ben
> > ny Halevy	TEXT	2012-05-02
> > RFC5661 (5467)	15.2	Technical	nfsv4 (tsv)	Tro
> > nd Myklebust	TEXT	2018-08-17
> > RFC5661 (3558)	15.1.4.2	Editorial	nfsv4 (tsv)	Cal
> > Turney	TEXT	2013-03-19
> > RFC5661 (2006)	15.1.1.3	Editorial	nfsv4 (tsv)	Mic
> > hael Eisler	TEXT	2010-01-17
> > RFC5661 (2062)	2.10.6.1.3	Editorial	nfsv4 (tsv)	Pet
> > er Varga	TEXT	2010-03-04
> > RFC5661 (2249)	12.5.5.2.1.5	Editorial	nfsv4 (tsv)
> > 	Michael Eisler	TEXT	2010-05-10
> > RFC5661 (2280)	10.4	Editorial	nfsv4 (tsv)	Pau
> > l J Gilliam	TEXT	2010-05-20
> > RFC5661 (2324)	2.10.6.2	Editorial	nfsv4 (tsv)	Tro
> > nd Myklebust	TEXT	2010-07-12
> > RFC5661 (2328)	15.1.16	Editorial	nfsv4 (tsv)	Tom
> > Haynes	TEXT	2010-07-13
> > RFC5661 (2330)	3.3.7	Editorial	nfsv4 (tsv)	Tom
> > Haynes	TEXT	2010-07-14
> > RFC5661 (2548)	18.36.3	Editorial	nfsv4 (tsv)	J.
> > Bruce Fields	TEXT	2010-10-11
> > RFC5661 (4215)	22.1	Editorial	nfsv4 (tsv)	Tom
> > Haynes	TEXT	2014-12-30
> > Status: Reported (14)
> > RFC Number
> > (Errata ID)	Section	Type	Source of RFC	Submitted By	Pub
> > lication Format	Date Submitted
> > RFC5661 (2505)	12.5.4.	Technical	nfsv4 (tsv)	Mic
> > hael Eisler	TEXT	2010-08-31
> > RFC5661 (2751)	GLOBAL	Technical	nfsv4 (tsv)	Ric
> > ardo Labiaga	TEXT	2011-03-21
> > RFC5661 (3379)	18.50.3	Technical	nfsv4 (tsv)	Asm
> > ita Karandikar	TEXT	2012-10-15
> > RFC5661 (3714)	13.4.4.	Technical	nfsv4 (tsv)	Yur
> > i Radchenko	TEXT	2013-08-31
> > RFC5661 (3901)	18.43.3	Technical	nfsv4 (tsv)	Tro
> > nd Myklebust	TEXT	2014-02-25
> > RFC5661 (4119)	12.2.10	Technical	nfsv4 (tsv)	Chr
> > istoph Hellwig	TEXT	2014-09-17
> > RFC5661 (4492)	18.17.4	Technical	nfsv4 (tsv)	Dav
> > id 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)	Tro
> > nd Myklebust	TEXT	2016-06-16
> > RFC5661 (5040)	18.46.3	Technical	nfsv4 (tsv)	Jon
> > athan Price	TEXT	2017-06-12
> > RFC5661 (5212)	15.2	Technical	nfsv4 (tsv)	NFS
> > 4ERR_ROFS is not a valid error code for LAYOUTGET	TEXT	201
> > 7-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)	Dyl
> > an Simon	TEXT	2017-01-22
> > RFC5661 (5476)	18.42.3	Editorial	nfsv4 (tsv)	Tig
> > ran Mkrtchyan	TEXT	2018-08-23
> > Status: Held for Document Update (7)
> > RFC Number
> > (Errata ID)	Section	Type	Source of RFC	Submitted By	Pub
> > lication Format	Date Submitted
> > RFC5661 (3065)	12.7.4	Technical	nfsv4 (tsv)	Dav
> > id Black	TEXT	2011-12-27
> > RFC5661 (3066)	12.7.4	Technical	nfsv4 (tsv)	Dav
> > id Black	TEXT	2011-12-27
> > RFC5661 (3067)	18.42.3	Technical	nfsv4 (tsv)	Dav
> > id Black	TEXT	2011-12-27
> > RFC5661 (3068)	18.42.3	Technical	nfsv4 (tsv)	Dav
> > id Black	TEXT	2011-12-27
> > RFC5661 (4118)	20.12.3	Technical	nfsv4 (tsv)	Chr
> > istoph Hellwig	TEXT	2014-09-17
> > RFC5661 (3064)	12.5.4	Editorial	nfsv4 (tsv)	Dav
> > id Black	TEXT	2011-12-27
> > RFC5661 (3653)	13.4.2	Editorial	nfsv4 (tsv)	Kan
> > da Motohiro	TEXT	2013-06-15
> > Status: Rejected (1)
> > RFC Number
> > (Errata ID)	Section	Type	Source of RFC	Submitted By	Pub
> > lication Format	Date Submitted
> > RFC5661 (2722)	15.2	Editorial	nfsv4 (tsv)	Ric
> > ardo Labiaga	TEXT	2011-02-15
> >  
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/nfsv4
> 
> --
> Chuck Lever
> 
> 
> 
-- 
Cheers

Magnus Westerlund 

----------------------------------------------------------------------
Network Architecture & Protocols, Ericsson Research
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Torshamnsgatan 23           | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: David Noveck <[email-masked]>
Date: Tue, 17 Sep 2019 05:24:37 -0400

> may require conisderation compared to David.

Yes.  I will be following up on two ways. First I will be explaining why,
in some of the cases that Chuck identified as potentially relevant, I felt
there was in fact no actual relevance and thus no need for draft change. If
Chuck or anyone else disagrees, we can discuss on the list.

> needs to be done, or other discussion needed?

Also, there is one case I'm which I have concluded that I was wrong in
deciding there was no interaction with the errata. For that case I will be
suggesting potential draft changes for the working group to discuss.

My email with these suggestions should be out within a day.   I hope we can
conclude the ensuing working group discussion by the end of the week,
adhering to the schedule you laid out for part 1B of your plan.

Others may also have text changes in mind.  If they do, it would be best if
those were discussed soon.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 17 Sep 2019 10:05:27 -0400

Hi Magnus-

> On Sep 17, 2019, at 4:53 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 

At this time I do not have new text to propose. My only desire was to
ensure the five errata were discussed. Simply speaking, I'm unsure
whether they are within scope or not. The others I'm certain are not
in scope and therefore IMO they do not need further consideration for
rfc5661sesqui.

I will leave it to Dave to drive the discussion of the five possibly
in-scope errata.

--
Chuck Lever

---

From: David Noveck <[email-masked]>
Date: Tue, 17 Sep 2019 10:53:00 -0400

In

On Mon, Sep 16, 2019 at 3:20 PM Chuck Lever <[email-masked]> wrote:

> I examined 39 errata targeting RFC 5661 by viewing this page:
> https://www.rfc-editor.org/errata_search.php?rfc=5661 . I binned each
> errata into one of two categories:
>
>    - The errata might be within the scope of rfc5661sesqui. It should be
>    discussed further by the WG.
>
> As it turns out, you followed Magnus's instructions differently than I
did.   You identified "potentially relevant errata" which you listed below,
while I tried to identify actually relevant errata and found none.   I
think it makes sense for me to address each of your potentially relevant
errata and explain why I did not think iti was actually relevant.   Note
that in one case, I have changed my mind and want to explain why I now
believe this is relevant and explain what I feel the draft might do to
address the issue.

>
>    - 2006 clarifies discussion of returning NFS4ERR_DELAY on a SEQUENCE
>       operation.
>
> Initially I felt this required no adaptation of the specfication since I
had pretty much assuming, when I wrote Section 11.13.3 that clients would
be re-issuing request which got NFS4ERR_DELAY on SEQUENCE, with SEQUENCE
unchanged.   So I felt that making this explicit did not require any
specification change, since it was generally assumed.

However, when I looked at this more deeply, I decided that there are some
serious issue with errata 2006 which the working group probably wants to
address now.   I'm not sure how this affects the status of 2006 (currently
"Verified") but I think we have to face the fact that the exsting text and
the proposed errata text both ignore the main function of SEQUENCE, i.e.
providing replay protection.   Let's deal separately with the cases in
which DELAY is returned on SEQUENCE and on non-SEQUENCE ops.

   - In the case of DELAY returned on SEQUENCE, it would be inappropriate
   to replay the responses for such requests as there would be no opportunity
   to address situations in which the condition that gives rise to the delay
   is no longer present.   While section 11.13.3 basically says "Don't do
   that", perhaps this issue should be mentioned in 15.1.3.   If it is, then
   the text of 11.13.3 would have to change to adapt although the substance of
   the message would remain the same.
   - In the case of DELAY returned on non-SEQUENCE ops, the problem of
   endless DELAY is addressed by requiring that the associated SEQUENCE op be
   changed on each retry.   The problem with this approach is that it
   undercuts the central function of SEQUENCE (i.e. replay protection).   If
   one has a COMPOUND that includes a non-idempotent operation which is
   followed by an op returning DELAY, the benfits of replay protection are
   lost.   It is probably too late to fix this now but I think that 15.1.3
   should not ignore the issue.  If it doesn't, 11.13.2 should mention the
   problem.

As far as addressing this issue and progressing rfc5661sesqui I think it
makes sense to send out a draft of a revised section 15.1.3 together with
some proposed modified paragraphs for 11.13.2 aqnd 11.13.3.  This will give
the working group something concrete to discuss as we discuss whether
rfc5661sesquii is read to progress.   I'lll be able to send that mateial
out by the end of  the week.

>    - 3379 removes "layouts" from 18.50.3 to avoid persisting a lease when
>       a client explicitly requests lease termination.
>
> This is one of two errata referring to DESTROY_CLIENTID.   I decided it is
not relevant to rfc5661sequi because, although we do deal with some state
management operations, we never refer to any use of DESTROY_CLIENTID or
discuss cicumstances under which a clientid is considred busy.

>
>    - 4572 correct 18.35.3
>
> I could not see how this typo is actually relevant to rfc5661sesqui.   The
typo does need to be fixed in rfc5661bis but it doesn't affect any
discussion of state management in rfc5661sesqui.

>
>    - 5040 adds DESTROY_CLIENTID to the list of operations that cannot
>       appear first in a COMPOUND.
>
>
Actually, it adds DESTROY_CLIENTID to the list of operationd that *can *appear
first in a COMPOUND.   Since rfc5661sesqui does not discuss use of
DESTROY_CLIENTID at all, I conclude that this errata is not actually
relevant.

>
>    - 5467 adds NFS4ERR_EXPIRED to the list of allowable error codes for
>       LAYOUTGET.
>
> Yes, but this has no effect on rfc5661sesqui, which, when it deals with
lease expiration, concerns itself with preventing it from occurring in the
event of migration.   Although this list should be corrected, the changes
in rfc5661sesqui should be unaffected.

>
>    - The errata is outside of the scope of where rfc5661sesqui makes
>    changes.
>       - All others
>
> The five errata for which I'd prefer to see more discussion have to do
> with state management in some way, and are therefore possibly within the
> scope of rfc5661sesqui, which changes/clarifies the way state management is
> handled during filesystem or IP migration. It is not clear to me whether
> these errata are relevant to sesqui or can be deferred to
>
rfc5661bis.
I hope my comments clarify why i feel most of these are not relevant to
rfc5661sequi.   If you are still unclrear on this issue, the working group
can continue the discussion as necessary.

> However, for Verified errata targeting RFC 5661: is there a process for
> retargeting them to the RFC that rfc5661sesqui will become?
>

Good point.  I don't know.

> If rfc5661sesqui obsoletes RFC 5661,
>

I think it will.

> how do implementers find these errata?
>

Not sure but I also wonder about some of the held-over errata which may be
more important to people since they might indicate where following rfc5661
is going to make you incompatible with existing implementations.

---

From: Chuck Lever <[email-masked]>
Date: Tue, 17 Sep 2019 14:59:17 -0400

Hi Dave-

On first reading, your remarks seem sensible. I agree that we should focus on 2006 and leave the other four errata for rfc5661bis.

> On Sep 17, 2019, at 10:53 AM, David Noveck <[email-masked]> wrote:
> 
> In
> 
> On Mon, Sep 16, 2019 at 3:20 PM Chuck Lever <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Magnus, et al.
> 
>> On Sep 13, 2019, at 4:43 AM, Magnus Westerlund <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi,
>>  
> As it turns out, you followed Magnus's instructions differently than I did.   You identified "potentially relevant errata" which you listed below, while I tried to identify actually relevant errata and found none.   I think it makes sense for me to address each of your potentially relevant errata and explain why I did not think iti was actually relevant.   Note that in one case, I have changed my mind and want to explain why I now believe this is relevant and explain what I feel the draft might do to address the issue.
> Initially I felt this required no adaptation of the specfication since I had pretty much assuming, when I wrote Section 11.13.3 that clients would be re-issuing request which got NFS4ERR_DELAY on SEQUENCE, with SEQUENCE unchanged.   So I felt that making this explicit did not require any specification change, since it was generally assumed.
> 
> However, when I looked at this more deeply, I decided that there are some serious issue with errata 2006 which the working group probably wants to address now.   I'm not sure how this affects the status of 2006 (currently "Verified") but I think we have to face the fact that the exsting text and the proposed errata text both ignore the main function of SEQUENCE, i.e. providing replay protection.   Let's deal separately with the cases in which DELAY is returned on SEQUENCE and on non-SEQUENCE ops.
> In the case of DELAY returned on SEQUENCE, it would be inappropriate to replay the responses for such requests as there would be no opportunity to address situations in which the condition that gives rise to the delay is no longer present.   While section 11.13.3 basically says "Don't do that", perhaps this issue should be mentioned in 15.1.3.   If it is, then the text of 11.13.3 would have to change to adapt although the substance of the message would remain the same.
> In the case of DELAY returned on non-SEQUENCE ops, the problem of endless DELAY is addressed by requiring that the associated SEQUENCE op be changed on each retry.   The problem with this approach is that it undercuts the central function of SEQUENCE (i.e. replay protection).   If one has a COMPOUND that includes a non-idempotent operation which is followed by an op returning DELAY, the benfits of replay protection are lost.   It is probably too late to fix this now but I think that 15.1.3 should not ignore the issue.  If it doesn't, 11.13.2 should mention the problem.
> As far as addressing this issue and progressing rfc5661sesqui I think it makes sense to send out a draft of a revised section 15.1.3 together with some proposed modified paragraphs for 11.13.2 aqnd 11.13.3.  This will give the working group something concrete to discuss as we discuss whether rfc5661sesquii is read to progress.   I'lll be able to send that mateial out by the end of  the week.
> 
> This is one of two errata referring to DESTROY_CLIENTID.   I decided it is not relevant to rfc5661sequi because, although we do deal with some state management operations, we never refer to any use of DESTROY_CLIENTID or discuss cicumstances under which a clientid is considred busy. 
> 4572 correct 18.35.3
> I could not see how this typo is actually relevant to rfc5661sesqui.   The typo does need to be fixed in rfc5661bis but it doesn't affect any discussion of state management in rfc5661sesqui. 
> Actually, it adds DESTROY_CLIENTID to the list of operationd that can appear first in a COMPOUND.   Since rfc5661sesqui does not discuss use of DESTROY_CLIENTID at all, I conclude that this errata is not actually relevant.   
> Yes, but this has no effect on rfc5661sesqui, which, when it deals with lease expiration, concerns itself with preventing it from occurring in the event of migration.   Although this list should be corrected, the changes in rfc5661sesqui should be unaffected.    
> I hope my comments clarify why i feel most of these are not relevant to rfc5661sequi.   If you are still unclrear on this issue, the working group can continue the discussion as necessary. 
> 
> All other errata I found to be not within the scope of rfc5661sesqui. However, for Verified errata targeting RFC 5661: is there a process for retargeting them to the RFC that rfc5661sesqui will become?
> 
> Not sure but I also wonder about some of the held-over errata which may be more important to people since they might indicate where following rfc5661 is going to make you incompatible with existing implementations.   

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 19 Sep 2019 13:02:59 +0000

> Erratas to the future RFC. 

The RFC-Editor can duplicate the errata we think are relevant to have
read on RFC5661seqqui when published. So that appear to not be a big
issue. This aspect is something I will bring with me to the discussion
of the proposal by Adam on these limited scope updates. 

Cheers

Magnus Westerlund