Subject: [nfsv4] Verified editorial Errata on 5561 and sesqui-msns

From: Magnus Westerlund <[email-masked]>
Date: Wed, 29 Jul 2020 09:01:34 +0000

Hi Authors and WG

This relates to the ongoing AUTH48 for draft-ietf-nfsv4-rfc5661sesqui-msns

I got a question from the RFC-editor about some of the errata filed on RFC
5561. These where two errata that are editorial and verified. They are
basically typos or other very basic issues but of potential importance to
understanding. And maybe we should include these change into this document
instead of continue to confuse the reader. However looking in the Errata
list there are more that of this basic type but wasn't obvious in the copy
editing. 

The Errata that I think falls into this category are:

https://www.rfc-editor.org/errata/eid3558

https://www.rfc-editor.org/errata/eid2062

https://www.rfc-editor.org/errata/eid2249

https://www.rfc-editor.org/errata/eid2280

https://www.rfc-editor.org/errata/eid2324

https://www.rfc-editor.org/errata/eid2330

https://www.rfc-editor.org/errata/eid2548

So the above ones is the ones I wonder if we simply should have the
RFC-editor apply before publication? I think this is simply correcting
things that the WG knows are wrong in RFC5661 and it could help the reader.
I am aware of this is not following what was previous said about Errata, but
I think this category should have been included as they appear very straight
forward and have been previously classified as relevant for understanding
and have risk of causing implementation errors. If the WG participants think
we should stick with previous path and not include them I will listen.
However, take a look at them before you make that assessment. 

There are two Errata that are listed as editorial and verified that are not
straight forward nor necessary only editorial

https://www.rfc-editor.org/errata/eid2328

This appears to an Error code that is missing in RFC5661 and should be
listed in Section 15.1.16. This doesn't have text that can just be applied.

https://www.rfc-editor.org/errata/eid4215

This Errata appears to fix a unclear statement in fourth paragraph of
Section 22.2. However, I don't see this as Editorial as it changes the IANA
procedure even if what is currently written is confusing. 

So these I would leave for the proper bis to take care of.

Cheers

Magnus Westerlund

---

From: David Noveck <[email-masked]>
Date: Wed, 29 Jul 2020 22:17:08 -0400

> This relates to the ongoing AUTH48 for draft-ietf-nfsv4-rfc5661sesqui-msns

I'm hoping it won't be going on.uch longer. I don't want it to go past
AUTH192.

> instead of continue to confuse the reader.
>
What two erratta reports did they ask about?

Are they working on these updates now?  I'd like to keep good track of all
the last-minute changes being merged into this document

However looking in the Errata list there are more that of this basic type
> but wasn’t obvious in the copy editing.
>
>
>
> RFC-editor apply before publication?
>
I'll ask the rfc editor of they can address these expeditiously, in the
context of AUTH48.  If they can, then it is just a question of Chuck and me
giving final approval to the AUTH48 changes.

I think this is simply correcting things that the WG knows are wrong in
> RFC5661 and it could help the reader. I am aware of this is not following
> what was previous said about Errata, but I think this category should have
> been included as they appear very straight forward and have been previously
> classified as relevant for understanding and have risk of causing
> implementation errors. If the WG participants think we should stick with
> previous path and not include them I will listen. However, take a look at
> them before you make that assessment.
>

Given that you have requested this change, I don't see waiting for a group
assessment of these verified errata reports in the middle of AUTH48.

>
>
>
>
> There are two Errata that are listed as editorial and verified that are
> not straight forward nor necessary only editorial
>
> listed in Section 15.1.16. This doesn’t have text that can just be applied
>
Doesn't seem very pressing.

> Section 22.2. However, I don’t see this as Editorial as it changes the IANA
Fair enough.

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jul 2020 09:11:30 +0000

Hi David and WG,

WG, I am requesting your input on this matter. I intended to make a decision on
Monday (3rd of August) after 12:00 CEST.  

Please see inline. 

> What two erratta reports did they ask about?

They asked me about Errata 2330 and 2548. Both very basic typos, which I believe
they spotted in working with the document.

> 
> Are they working on these updates now?  I'd like to keep good track of all the
> last-minute changes being merged into this document

No, they are not working on this. They are waiting for me with your input to
tell them what to do with it. 

> > So the above ones is the ones I wonder if we simply should have the RFC-
> > editor apply before publication?
> 

Yes, the intention is to deal with this now before concluding AUTH48. And having
looked at these Errata, this is less than an hours work to incorporate into the
document. So from a work perspective, from the point I make a decision to do
this change (if that is what I conclude) would take the RFC-editor less than a
work day to get the authors the updated document, and then you authors would
have to verify that these changes are properly done. From my perspective it is
likely that this input period is the longest delay here. 

> assessment of these verified errata reports in the middle of AUTH48.

No, I have not requested these changes yet. I am asking the WG if you think this
is the right step? I personally think it makes sense to incorporate the above
listed Errata but no additional errata. However, I want the WG feedback on this
matter. 

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

---

From: David Noveck <[email-masked]>
Date: Thu, 30 Jul 2020 06:33:56 -0400

> Monday (3rd of August) after 12:00 CEST.

I'm not sure what decision you are referring to, given that you are not an
author of this document.  It appears that the rfc editor has confused the
process by raising issues relating to the ongoing AUTH48 with you ex parte.
I hope this will not be repeated as it makes it harder for the authors to
deal with the process.

> tell them what to do with it.

If they wanted my input, they could have asked me for it, and avoided a lot
of confusion and delay.

Let me provide my input now: go ahead and make the changes for 2330 and
2358.

> > giving final approval to the AUTH48 changes.

So I'm asking the editor of they could address these expeditiously. Let the
authors know of any issues you see.  I hope the authors will be able to
make a decision at that point.

> likely that this input period is the longest delay here.

Exactly the problem.

> listed Errata but no additional errata. However, I want the WG feedback on

I can't see the wg members deciding to spend their weekend sorting through
erratta reports.  I don't expect any meaningful feedback.

---

From: Chuck Lever <[email-masked]>
Date: Thu, 30 Jul 2020 08:17:46 -0400

Hi Magnus -

> On Jul 29, 2020, at 5:01 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi Authors and WG
>  
> I got a question from the RFC-editor about some of the errata filed on RFC 5561. These where two errata that are editorial and verified. They are basically typos or other very basic issues but of potential importance to understanding. And maybe we should include these change into this document instead of continue to confuse the reader. However looking in the Errata list there are more that of this basic type but wasn’t obvious in the copy editing. 
>  
> https://www.rfc-editor.org/errata/eid3558 <https://www.rfc-editor.org/errata/eid3558>
> https://www.rfc-editor.org/errata/eid2062 <https://www.rfc-editor.org/errata/eid2062>
> https://www.rfc-editor.org/errata/eid2249 <https://www.rfc-editor.org/errata/eid2249>
> https://www.rfc-editor.org/errata/eid2280 <https://www.rfc-editor.org/errata/eid2280>
> https://www.rfc-editor.org/errata/eid2324 <https://www.rfc-editor.org/errata/eid2324>
> https://www.rfc-editor.org/errata/eid2330 <https://www.rfc-editor.org/errata/eid2330>
> https://www.rfc-editor.org/errata/eid2548 <https://www.rfc-editor.org/errata/eid2548>
>  
> So the above ones is the ones I wonder if we simply should have the RFC-editor apply before publication? I think this is simply correcting things that the WG knows are wrong in RFC5661 and it could help the reader. I am aware of this is not following what was previous said about Errata, but I think this category should have been included as they appear very straight forward and have been previously classified as relevant for understanding and have risk of causing implementation errors. If the WG participants think we should stick with previous path and not include them I will listen. However, take a look at them before you make that assessment.

All of these appear to be errors that might be typically caught and corrected during AUTH48, with one exception:

appears to be technical, and therefore requires review by WG members familiar with implementations of CB_LAYOUTRECALL to avoid protocol changes that would impact interoperability among existing implementations.

With the exception of 2249, I am in favor of addressing these minor issues before publication. I do not believe addressing them would result in undue delay.

> There are two Errata that are listed as editorial and verified that are not straight forward nor necessary only editorial
> https://www.rfc-editor.org/errata/eid2328 <https://www.rfc-editor.org/errata/eid2328>
> This appears to an Error code that is missing in RFC5661 and should be listed in Section 15.1.16. This doesn’t have text that can just be applied.
>  
> https://www.rfc-editor.org/errata/eid4215 <https://www.rfc-editor.org/errata/eid4215>
> This Errata appears to fix a unclear statement in fourth paragraph of Section 22.2. However, I don’t see this as Editorial as it changes the IANA procedure even if what is currently written is confusing. 
>  

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jul 2020 14:10:14 +0000

Hi David and the WG,

Let us straight something out regarding the process here.

Yes, authors need to approve of the changes in AUTH-48 done by the RFC-editor. 

When it comes to any changes proposed by the authors or by the RFC-editor that has the potential to change the document meaning, the AD have the review responsibility and decision power to approve or reject them. My decision can of course be appealed if you authors or the WG think the decision was made in error. However, it is very common that there are some changes in AUTH48 that do require AD approval as the RFC-editor thinks it appear to change the meaning of the document compared what was approved by the IESG. But to make it clear the Responsible AD for the document is not an “ex parte” as David put it in the AUTH48 process. 

So yes these questions from the RFC-editor should have come to the authors and me as AD at the same time. However, due to that I stopped by the RFC-editor table and talked with them, they thought to ask me first which was a mistake. I have told the RFC-editor to forward our single exchange with my response to the authors for transparency. This email basically contains a bunch you will need to ask the authors. Regarding the subject of the two Errata they raised, I short circuited this discussion to not only be the authors that got to provide input to raise this in front of the whole WG directly. Sorry if I didn’t express clearly that this was an proposal from the RFC-editor that I generalized on my own initiative. I am sorry this surprised the authors, and my desire to avoid additional delay apparently caused unnecessary reactions.   But the intention here was only to ensure that this proposal for a change is getting WG input. 

To be clear, there are no decision made yet. It is open for the Authors and WG to provide input to this proposal. However, I consider that the final decision on this is mine, that was why I noted that I would make a decision on Monday after you have had a chance to provide input. If you think the deadline is to short it can be extended. I will most certainly listen to the authors and WG. And if you think we should stick to no errata changes please express that to. 

Hope this clarifies

Magnus Westerlund

From: David Noveck <[email-masked]> 
Sent: den 30 juli 2020 12:34
To: Magnus Westerlund <[email-masked]>
Cc: [email-masked]; NFSv4 <[email-masked]>; RFC Editor <[email-masked]>
Subject: Re: Verified editorial Errata on 5561 and sesqui-msns

On Thu, Jul 30, 2020, 5:11 AM Magnus Westerlund <[email-masked] <mailto:[email-masked]> > wrote:

Hi David and WG,

I'm not sure what decision you are referring to, given that you are not an author of this document.  It appears that the rfc editor has confused the process by raising issues relating to the ongoing AUTH48 with you ex parte. I hope this will not be repeated as it makes it harder for the authors to deal with the process.

 

Please see inline. 

On Wed, 2020-07-29 at 22:17 -0400, David Noveck wrote:
> [email-masked] <mailto:[email-masked]> > wrote:
> > Hi Authors and WG
> >  

If they wanted my input, they could have asked me for it, and avoided a lot of confusion and delay.

Let me provide my input now: go ahead and make the changes for 2330 and 2358.

> > https://www.rfc-editor.org/errata/eid3558 <https://protect2.fireeye.com/v1/url?k=4ffa126e-114a8ff4-4ffa52f5-867b36d1634c-ad7230720dfd2682&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid3558> 
> > https://www.rfc-editor.org/errata/eid2062 <https://protect2.fireeye.com/v1/url?k=7c8df67b-223d6be1-7c8db6e0-867b36d1634c-c63798416b7852e6&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2062> 
> > https://www.rfc-editor.org/errata/eid2249 <https://protect2.fireeye.com/v1/url?k=847b7442-dacbe9d8-847b34d9-867b36d1634c-61d5c65cc8773be8&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249> 
> > https://www.rfc-editor.org/errata/eid2280 <https://protect2.fireeye.com/v1/url?k=bbcfc091-e57f5d0b-bbcf800a-867b36d1634c-4449d2b36fa482f0&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2280> 
> > https://www.rfc-editor.org/errata/eid2324 <https://protect2.fireeye.com/v1/url?k=bf6c7cf2-e1dce168-bf6c3c69-867b36d1634c-cef67b0dee3c8936&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2324> 
> > https://www.rfc-editor.org/errata/eid2330 <https://protect2.fireeye.com/v1/url?k=0d900b06-5320969c-0d904b9d-867b36d1634c-8a5dbc417bb0d4c7&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2330> 
> > https://www.rfc-editor.org/errata/eid2548 <https://protect2.fireeye.com/v1/url?k=d5ec7343-8b5ceed9-d5ec33d8-867b36d1634c-78adef88ff190383&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2548> 
> >  

So I'm asking the editor of they could address these expeditiously. Let the authors know of any issues you see.  I hope the authors will be able to make a decision at that point.

Exactly the problem.  

I can't see the wg members deciding to spend their weekend sorting through erratta reports.  I don't expect any meaningful feedback.

> > https://www.rfc-editor.org/errata/eid2328 <https://protect2.fireeye.com/v1/url?k=e211a879-bca135e3-e211e8e2-867b36d1634c-2f9cf672b2472980&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2328> 
> > https://www.rfc-editor.org/errata/eid4215 <https://protect2.fireeye.com/v1/url?k=f68e8124-a83e1cbe-f68ec1bf-867b36d1634c-af3ea5655b635ae4&q=1&e=2f8ad34d-a579-401f-a893-9bb784ac8ad6&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4215> 
-- 
Cheers

Magnus Westerlund 

SE-164 80 Stockholm, Sweden | mailto: [email-masked] <mailto:[email-masked]>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jul 2020 14:25:42 +0000

Hi Chuck,

If Errata 2249 despite its status as a verified editorial errata is not editorial then lets leave it out of these changes. I really only want to propose things that are truly editorial and have the potential for cause issues for an implementor using this specification. 

Cheers

Magnus

From: Chuck Lever <[email-masked]> 
Sent: den 30 juli 2020 14:18
To: Magnus Westerlund <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: Verified editorial Errata on 5561 and sesqui-msns

Hi Magnus -

On Jul 29, 2020, at 5:01 AM, Magnus Westerlund <[email-masked] <mailto:[email-masked]> > wrote:

Hi Authors and WG

This relates to the ongoing AUTH48 for draft-ietf-nfsv4-rfc5661sesqui-msnsI

 <https://protect2.fireeye.com/v1/url?k=2187309c-7f279e51-21877007-86073b36ea28-7eccff51ed56e2f2&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid3558> https://www.rfc-editor.org/errata/eid3558

 <https://protect2.fireeye.com/v1/url?k=72c62308-2c668dc5-72c66393-86073b36ea28-54630add5fc8660d&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2062> https://www.rfc-editor.org/errata/eid2062

 <https://protect2.fireeye.com/v1/url?k=94ba5266-ca1afcab-94ba12fd-86073b36ea28-60b60d9c5490c0b6&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249> https://www.rfc-editor.org/errata/eid2249

 <https://protect2.fireeye.com/v1/url?k=8da5c41c-d3056ad1-8da58487-86073b36ea28-21dd69a0e0e97c0d&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2280> https://www.rfc-editor.org/errata/eid2280

 <https://protect2.fireeye.com/v1/url?k=f75faa3f-a9ff04f2-f75feaa4-86073b36ea28-ded42b3464c0a2bb&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2324> https://www.rfc-editor.org/errata/eid2324

 <https://protect2.fireeye.com/v1/url?k=e48cd74b-ba2c7986-e48c97d0-86073b36ea28-1ba367ea7b2d71fc&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2330> https://www.rfc-editor.org/errata/eid2330

 <https://protect2.fireeye.com/v1/url?k=e2145460-bcb4faad-e21414fb-86073b36ea28-3e737b266ad059ce&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2548> https://www.rfc-editor.org/errata/eid2548

https://www.rfc-editor.org/errata/eid2249 <https://protect2.fireeye.com/v1/url?k=8fa96a97-d109c45a-8fa92a0c-86073b36ea28-bf9a924cced2a88a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249> 

 

 <https://protect2.fireeye.com/v1/url?k=7f12ac8c-21b20241-7f12ec17-86073b36ea28-ef8e722add5a545a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2328> https://www.rfc-editor.org/errata/eid2328

 <https://protect2.fireeye.com/v1/url?k=e27bb61d-bcdb18d0-e27bf686-86073b36ea28-9e3f3185e9f7c66a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4215> https://www.rfc-editor.org/errata/eid4215

Cheers

Magnus Westerlund

--

Chuck Lever

---

From: Tom Talpey <[email-masked]>
Date: Thu, 30 Jul 2020 10:36:52 -0400

On 7/30/2020 10:25 AM, Magnus Westerlund wrote:
> Hi Chuck,
> 
> If Errata 2249 despite its status as a verified editorial errata is not 
> editorial then lets leave it out of these changes. I really only want to 
> propose things that are truly editorial and have the potential for cause 
> issues for an implementor using this specification.

Totally agree with the goal, but this erratum is 10 years old (!) and
was filed by someone who well-understands the situation. At a minimum
it seems prudent to update the text to clarify this, perhaps while
making a statement of fact that implementations to an earlier version
might have differing behavior.

JMHO.

> 
> Cheers
> 
> Magnus
> 
> *From:*Chuck Lever <[email-masked]>
> *Sent:* den 30 juli 2020 14:18
> *To:* Magnus Westerlund <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: Verified editorial Errata on 5561 and sesqui-msns
> 
> Hi Magnus -
> 
> 
> 
>     On Jul 29, 2020, at 5:01 AM, Magnus Westerlund
>     <magnus.westerlund@ericsson..com
>     <mailto:[email-masked]>> wrote:
> 
>     Hi Authors and WG
> 
>     I got a question from the RFC-editor about some of the errata filed
>     on RFC 5561. These where two errata that are editorial and verified.
>     They are basically typos or other very basic issues but of potential
>     importance to understanding. And maybe we should include these
>     change into this document instead of continue to confuse the reader.
>     However looking in the Errata list there are more that of this basic
>     type but wasn’t obvious in the copy editing.
> 
>     <https://protect2.fireeye.com/v1/url?k=2187309c-7f279e51-21877007-86073b36ea28-7eccff51ed56e2f2&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid3558>
> 
>     <https://protect2.fireeye.com/v1/url?k=72c62308-2c668dc5-72c66393-86073b36ea28-54630add5fc8660d&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2062>
> 
>     <https://protect2.fireeye.com/v1/url?k=94ba5266-ca1afcab-94ba12fd-86073b36ea28-60b60d9c5490c0b6&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249>
> 
>     <https://protect2.fireeye.com/v1/url?k=8da5c41c-d3056ad1-8da58487-86073b36ea28-21dd69a0e0e97c0d&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2280>
> 
>     <https://protect2.fireeye.com/v1/url?k=f75faa3f-a9ff04f2-f75feaa4-86073b36ea28-ded42b3464c0a2bb&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2324>
> 
>     <https://protect2.fireeye.com/v1/url?k=e48cd74b-ba2c7986-e48c97d0-86073b36ea28-1ba367ea7b2d71fc&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2330>
> 
>     <https://protect2.fireeye.com/v1/url?k=e2145460-bcb4faad-e21414fb-86073b36ea28-3e737b266ad059ce&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2548>
> 
>     RFC-editor apply before publication? I think this is simply
>     correcting things that the WG knows are wrong in RFC5661 and it
>     could help the reader. I am aware of this is not following what was
>     previous said about Errata, but I think this category should have
>     been included as they appear very straight forward and have been
>     previously classified as relevant for understanding and have risk of
>     causing implementation errors. If the WG participants think we
>     should stick with previous path and not include them I will listen.
> All of these appear to be errors that might be typically caught and 
> corrected during AUTH48, with one exception:
> 
> <https://protect2.fireeye.com/v1/url?k=8fa96a97-d109c45a-8fa92a0c-86073b36ea28-bf9a924cced2a88a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249>
> 
> appears to be technical, and therefore requires review by WG members 
> familiar with implementations of CB_LAYOUTRECALL to avoid protocol 
> changes that would impact interoperability among existing implementations.
> 
> With the exception of 2249, I am in favor of addressing these minor 
> issues before publication. I do not believe addressing them would result 
> in undue delay.
> 
>     There are two Errata that are listed as editorial and verified that
>     are not straight forward nor necessary only editorial
> 
>     <https://protect2.fireeye.com/v1/url?k=7f12ac8c-21b20241-7f12ec17-86073b36ea28-ef8e722add5a545a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2328>
> 
>     This appears to an Error code that is missing in RFC5661 and should
>     be listed in Section 15.1.16. This doesn’t have text that can just
>     be applied.
> 
>     <https://protect2.fireeye.com/v1/url?k=e27bb61d-bcdb18d0-e27bf686-86073b36ea28-9e3f3185e9f7c66a&q=1&e=343dab95-e554-48c9-9a78-f653c2b76745&u=https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4215>
> 
>     This Errata appears to fix a unclear statement in fourth paragraph
>     of Section 22.2. However, I don’t see this as Editorial as it
>     changes the IANA procedure even if what is currently written is
>     confusing.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jul 2020 14:50:17 +0000

Hi Tom,

Thanks for more input. What you write indicates that this errata should not be included as it requires additional editing. 

I hope you have taken time to look at the other Errata to ensure that there are not more cases that are not pure straightforward and would be good to have more clarifications on. 

Cheers

Magnus

> -----Original Message-----
> From: nfsv4 <[email-masked]> On Behalf Of Tom Talpey
> Sent: den 30 juli 2020 16:37
> To: [email-masked]
> Subject: Re: [nfsv4] Verified editorial Errata on 5561 and sesqui-msns
> 
> > If Errata 2249 despite its status as a verified editorial errata is
> > not editorial then lets leave it out of these changes. I really only
> > want to propose things that are truly editorial and have the potential
> > for cause issues for an implementor using this specification.
> 
> Totally agree with the goal, but this erratum is 10 years old (!) and was filed
> by someone who well-understands the situation. At a minimum it seems
> prudent to update the text to clarify this, perhaps while making a statement
> of fact that implementations to an earlier version might have differing
> behavior.
> 
> JMHO.
> 
> >
> > Cheers
> >
> > Magnus
> >
> >     https://protect2.fireeye.com/v1/url?k=3d26058d-63969815-3d264516-
> 86d8a30ca42b-e88b46058479f168&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid3558
> >
> > <https://protect2.fireeye.com/v1/url?k=2187309c-7f279e51-21877007-8607
> > 3b36ea28-7eccff51ed56e2f2&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid3558>
> >
> >     https://protect2.fireeye.com/v1/url?k=2ce31625-72538bbd-2ce356be-
> 86d8a30ca42b-4f76c1e5e3389d53&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2062
> >
> > <https://protect2.fireeye.com/v1/url?k=72c62308-2c668dc5-72c66393-8607
> > 3b36ea28-54630add5fc8660d&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2062>
> >
> >     https://protect2.fireeye.com/v1/url?k=aaa6ea8f-f4167717-aaa6aa14-
> 86d8a30ca42b-90a77ccb13782ba4&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2249
> >
> > <https://protect2.fireeye.com/v1/url?k=94ba5266-ca1afcab-94ba12fd-8607
> > 3b36ea28-60b60d9c5490c0b6&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249>
> >
> >     https://protect2.fireeye.com/v1/url?k=8d4e7eda-d3fee342-8d4e3e41-
> 86d8a30ca42b-573a9d2214328b51&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2280
> >
> > <https://protect2.fireeye.com/v1/url?k=8da5c41c-d3056ad1-8da58487-
> 8607
> > 3b36ea28-21dd69a0e0e97c0d&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2280>
> >
> >     https://protect2.fireeye.com/v1/url?k=cdee6e28-935ef3b0-cdee2eb3-
> 86d8a30ca42b-93599a2537e07013&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2324
> >
> > <https://protect2.fireeye.com/v1/url?k=f75faa3f-a9ff04f2-f75feaa4-8607
> > 3b36ea28-ded42b3464c0a2bb&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2324>
> >
> >     https://protect2.fireeye.com/v1/url?k=cd09d961-93b944f9-cd0999fa-
> 86d8a30ca42b-f2ec806470c8e679&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2330
> >
> > <https://protect2.fireeye.com/v1/url?k=e48cd74b-ba2c7986-e48c97d0-
> 8607
> > 3b36ea28-1ba367ea7b2d71fc&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2330>
> >
> >     https://protect2.fireeye.com/v1/url?k=b394c5d4-ed24584c-b394854f-
> 86d8a30ca42b-1fa05a73c3a06088&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2548
> >
> > <https://protect2.fireeye.com/v1/url?k=e2145460-bcb4faad-e21414fb-
> 8607
> > 3b36ea28-3e737b266ad059ce&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2548>
> >
> > https://protect2.fireeye.com/v1/url?k=f72d2fec-a99db274-f72d6f77-86d8a
> > 30ca42b-ae756ed4ef9082d8&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=
> > https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249
> > <https://protect2.fireeye.com/v1/url?k=8fa96a97-d109c45a-8fa92a0c-8607
> > 3b36ea28-bf9a924cced2a88a&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2249>
> >
> > issues before publication. I do not believe addressing them would
> > result in undue delay.
> >
> >     https://protect2.fireeye.com/v1/url?k=04b9d705-5a094a9d-04b9979e-
> 86d8a30ca42b-66085810e0d28c85&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid2328
> >
> > <https://protect2.fireeye.com/v1/url?k=7f12ac8c-21b20241-7f12ec17-8607
> > 3b36ea28-ef8e722add5a545a&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid2328>
> >
> >     https://protect2.fireeye.com/v1/url?k=73ab5727-2d1bcabf-73ab17bc-
> 86d8a30ca42b-fd69e6d90af5e081&q=1&e=d7ee75d1-de87-4991-bddf-
> 8b6e98b0f13c&u=https%3A%2F%2Fwww.rfc-
> editor.org%2Ferrata%2Feid4215
> >
> > <https://protect2.fireeye.com/v1/url?k=e27bb61d-bcdb18d0-e27bf686-
> 8607
> > 3b36ea28-9e3f3185e9f7c66a&q=1&e=343dab95-e554-48c9-9a78-
> f653c2b76745&u
> > =https%3A%2F%2Fwww.rfc-editor.org%2Ferrata%2Feid4215>
> >

---

From: Chuck Lever <[email-masked]>
Date: Thu, 30 Jul 2020 11:01:35 -0400

> On Jul 30, 2020, at 10:36 AM, Tom Talpey <[email-masked]> wrote:
> 

To be clear, my hesitancy is not with the reporter's expertise but with the length of time the error has been left uncorrected. No doubt it is a simple cut-and-paste typo.

However, the error has been uncorrected for 10 years. That opens the window for implementations that stick to the word of the spec rather than its intended meaning. I think we cannot change that language without due diligence or a thorough understanding of the interoperability implications. Certainly well within the purview of rfc5661bis, but I feel it is outside the arena of corrections that can be done without harm just before publication.

I'm open to changing my opinion if someone with experience in that area can convince us the proposed text change is totally harmless.

--
Chuck Lever

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 30 Jul 2020 15:08:58 +0000

Chuck,

See at the bottom.

> From: nfsv4 <[email-masked]> On Behalf Of Chuck Lever
> Sent: den 30 juli 2020 17:02
> To: NFSv4 <[email-masked]>
editorial
> then lets leave it out of these changes. I really only want to propose
things
> that are truly editorial and have the potential for cause issues for an
> implementor using this specification.
> >
> To be clear, my hesitancy is not with the reporter's expertise but with
the
> length of time the error has been left uncorrected. No doubt it is a
simple
> cut-and-paste typo.
> 
> However, the error has been uncorrected for 10 years. That opens the
> window for implementations that stick to the word of the spec rather than
its
> intended meaning. I think we cannot change that language without due
> diligence or a thorough understanding of the interoperability
implications.
> Certainly well within the purview of rfc5661bis, but I feel it is outside
the
> arena of corrections that can be done without harm just before
publication.
> 
> I'm open to changing my opinion if someone with experience in that area
can
> convince us the proposed text change is totally harmless.

I am not attempting to change any mind here. I think at the smallest
uncertainty that this is not a harmless change then we leave it for the
5561bis work when the WG has time. The purpose from my side was only to roll
in a small set of obvious editorial errata. 

So from my perspective the safe path here is to leave 2249 out. 

Cheers

Magnus Westerlund

---

From: Tom Talpey <[email-masked]>
Date: Thu, 30 Jul 2020 11:12:48 -0400

Well, I thought all the errata were fine. But after Chuck's
reply, I agree that 2249 could use a slight additional tweak.

If it hasn't caused an issue in 10 years, perhaps we should
assume it won't cause one in future. Sleeping dogs, and all.

Tom.

---

From: Tom Talpey <[email-masked]>
Date: Thu, 30 Jul 2020 12:11:21 -0400

On 7/30/2020 11:08 AM, Magnus Westerlund wrote:> ...
> So from my perspective the safe path here is to leave 2249 out.

I don't disagree, but one question. Because this is an accepted
erratum, what is the procedure for marking the text as such in
the new document? Do we simply transfer the erratum to the update
and the new landing page says "Errata Exist" ab initio?

Tom.

---

From: David Noveck <[email-masked]>
Date: Thu, 30 Jul 2020 12:16:04 -0400

> the new document? Do we simply transfer the erratum to the update

It  has been my understanding that this would be done by the rfc editor

I guess so.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 31 Jul 2020 09:17:55 +0000

On Thu, 2020-07-30 at 12:16 -0400, David Noveck wrote:
> > On 7/30/2020 11:08 AM, Magnus Westerlund wrote:> ....

The RFC-editor can do it, or the authors can make the changes to the source file
and then send it to the RFC-editor. Its up to the authors if you want them to do
the work and then check it, or do the work yourself. 

> I guess so..

So the Errata is on RFC 5661 and that will always exist. The plan discussed
earlier was to have the RFC-editor copy all Errata for RFC5661 that still
applies to the sesqui RFC when it has been published. So this excersise reduces
the number of Errata that needs to be copied. 

Cheers

Magnus Westerlund