Re: Errata #5933 for RFC8200

[Fernando Gont <[e-mail]>]

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.


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.

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