Re: Spring Appeal and [Errata Rejected] RFC8200 (6003)

[Fernando Gont <[e-mail]>]

Hello, Ole (and IESG),

(please pay particular attention to bullet #4 bellow)

On 15/5/20 06:10, [e-mail] wrote:
> Fernando,
> 
> Can you give a summary of new points, if any, that you bring up in this email?
> That is, aspects that havent previously been discussed in detail on the list or is covered in 6003.

Sure:

1) My email notes that some of the verifier's notes for Erratum 6003 are 
incorrect.

It is irrelevant what the wg may or may have not discussed (besides the 
fact that I don't think these points have been discussed). The 
aforementioned claims have been employed to back the decision to reject 
erratum 6003. However, as these claims have been proven to be incorrect, 
I think reconsideration is warranted.

Specifically, the verifier's notes say:
       "The key text has remained unchanged since RFC 1883"

As it should be evident from my email, it's actually the other way 
around: the key text has been *different* from RFC8200 all the way since 
RFC1883 till the IETF LC of what became RFC8200.



2) Since we are at it, I will also add that the following statement from 
the verifier's notes is incorrect:

     In fact, considering the apparent lack of substantive progress
     toward resolution on this issue in the working group since
     https://www.rfc-editor.org/errata/eid5933 previously attempted
     to revise this text, continuing use of the erratum report process
     for this could risk the appearance of bypassing the working group
     consensus process.

Erratum 5933 was submitted in early December 2019, and was processed 
only in early March 2020. Only a few days later since the erratum was 
processed as "held for document update", an Internet-Draft was posted 
(draft-bonica-6man-ext-hdr-update), and the draft was revised three 
times since then. I don't think the 6man wg could have done any more 
progress on the topic than that, other than requesting the chairs to do 
an adoption call on said draft, which the draft authors did request.


3) Based on item #1 above, any interpretation that RFC8200 allows for 
en-route EH insertion/removal should beg the question that, since this 
would be a major departure from RFC2460, had that been the case, IPv6 
could have never been elevated to "Internet Standard" status.



4) I will point Erik and the rest of the IESG to Suresh Krishnan's 
comment about the outcome of the IETF LC (please see: 
https://mailarchive.ietf.org/arch/msg/ietf/0it68EdnBDs73uxpmzIQqlMw-fE/), 
which clearly states what was the intention of the updated text:

     Thanks to everyone who commented during the IETF Last Call of
     draft-ietf-6man-rfc2460bis-08. The IETF last call discussion for
     this draft was mainly focused around the text in Section 4 that
     discusses the handling of extension headers. The biggest concern
     raised was that the current text is ambiguous on whether header
     insertion is allowed on intermediate nodes or not. There were some
     people arguing that an explicit prohibition is not necessary as the
     text is already clear, while others believed that explicitly
     listing the prohibitions will minimize any misunderstandings in the
     future. There was also a small number of people who wanted to
     explicitly allow header insertion and describe how to do it, but
     this was clearly out of scope for this draft (but may be in scope
     for future work in 6man). Overall, no one argued against the fact
     that the intent of the text in RFC2460 was to forbid insertion of
     extension headers on any other node but the source of the packet.
     The only argument made against adding clarifying text was that the
     text was already clear. Given this, I believe there is consensus to
     add explicit text about header insertion into the draft before it
     progresses further.


As per the above, I do believe the submitted erratum points a bug in the 
spec, and thus should be processed as "Verified".

Besides, since the IESG is processing an Appeal that covers this topic, 
I do expect that this note is considered during their resolution of said 
Appeal.

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