Re: Errata #5933 for RFC8200

[Fernando Gont <[e-mail]>]

On 27/2/20 19:19, Suresh Krishnan wrote:
> Hi Fernando,
> 
>> On Feb 27, 2020, at 5:08 PM, Fernando Gont <[e-mail]> wrote:
>>
>> On 27/2/20 18:32, Suresh Krishnan wrote:
>>> Hi Fernando,
>>>> On Feb 27, 2020, at 3:07 PM, Fernando Gont <[e-mail] <mailto:[e-mail]>> wrote:
>>>>
>>>> Suresh,
>>>>
>>>> Two months ago I filled an errata on RFC8200 regarding the processing of IPv6 extension headers. The errata is available here: https://www.rfc-editor.org/errata/eid5933
>>>>
>>>> While I believe that folks with a knowledge of Internet Protocols would be able to interpret what is in RFC8200, given recent discussions on the topic, and upon a re-read of the text, I believe a clarification is warranted, such that we allow all sorts of curious interpretations of the text.
>>> I think this would be fine to clarify, but IMHO the errata process is not the right way to do it.
>>> Based on the IESG Statement about processing of RFC Errata for the IETF Stream (https://ietf.org/about/groups/iesg/statements/processing-rfc-errata/)
>>> "Changes that modify the working of a protocol to something that might be different from the intended consensus when the document was approved should be either Hold for Document Update or Rejected. Deciding between these two depends on judgment. Changes that are clearly modifications to the intended consensus, or involve large textual changes, should be Rejected."
>>
>> The intent of the spec is on the spec itself:
>>
>> Appendix B:
>>
>>    o  Clarified that extension headers (except for the Hop-by-Hop
>>       Options header) are not processed, inserted, or deleted by any
>>       node along a packet's delivery path.
> 
> Correct. This was to clarify the "extension headers are not examined or processed by any node” text in RFC2460 which some people claimed would allow insertion and deletion. And the right way to do that was to do exactly as we did. Waited for the revision of RFC2460 and get WG consensus to make the change. 

That's not what we did. Nobody waited for RFC2460 to be revised. I 
submitted an errata about that, indeed.


Besides, please let me ask: How can you possibly argue that this:
        https://www.rfc-editor.org/errata/eid5945
is acceptable

but this:
      https://www.rfc-editor.org/errata/eid5933

errata #5933 isn't?


This post 
<https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/> 
says:

Only errors that could cause implementation or deployment problems or 
significant confusion should be Verified.


This is exactly the case: clearly folks are confused about how they read 
RFC8200, and are implementing and deploying boxes based on such 
confusion, which may result in deployment problems -- because eh 
insertion and removal breaks so many things.



-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492