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

[Tom Talpey <[e-mail]>]

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 <[e-mail]>
> *Sent:* den 30 juli 2020 14:18
> *To:* Magnus Westerlund <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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:[e-mail]>> wrote:
> 
>     Hi Authors and WG
> 
>     This relates to the ongoing AUTH48 for
>     draft-ietf-nfsv4-rfc5661sesqui-msnsI
> 
>     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://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/eid2062
>     <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/eid2249
>     <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/eid2280
>     <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/eid2324
>     <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/eid2330
>     <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/eid2548
>     <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>
> 
>     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:
> 
> 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>
> 
> 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://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://www.rfc-editor.org/errata/eid4215
>     <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.
> 
>     So these I would leave for the proper bis to take care of.
> 
>     Cheers
> 
>     Magnus Westerlund
> 
> --
> 
> Chuck Lever
> 
> 
> _______________________________________________
> nfsv4 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/nfsv4
>