Re: Errata #5933 for RFC8200

[Suresh Krishnan <[e-mail]>]

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. If you had submitted an Erratum on RFC2460 to make the same change on RFC2460 we would have had the same result.

> 
> 
> Routing Headers, for instance, are specified as:
> 
> 4.4.  Routing Header
> 
>   The Routing header is used by an IPv6 source to list one or more
>   intermediate nodes to be "visited" on the way to a packet's
>   destination.
> 
> 
> Just to be clear, I believe that your stated decision of processing this errata as "Hold for document update" is not only incorrect, but also doesn't represent the consensus this working group got during the rfc2460bis effort -- now RFC8200.

> 
> It is also unfortunate to have a second instance of this, because, at the time the same group was pushing other IPv6 insertion/removal ideas, I also objected 6man shipping rfc2460bis as such. And we only got to improve on that during IETF LC.
> 
> As such, I will formally Appeal your decision.

Please do go ahead. I stand by my assessment that this is a misuse of the Errata process and it is not a simple clarification as you claim.

Thanks
Suresh