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

[Erik Kline <[e-mail]>]

[ IESG to bcc;
  all are welcome to follow on 6man;
  all are welcome to re-cc IESG ]


[1] I began with a reading of the existing and previous text (1883 ->
2460 -> 8200) to see exactly what is said.

RFC 8200 includes a blanket prohibition on on-path nodes doing things
like header insertion or removal.  This text has changed as it evolved
into 8200.

RFC 8200 includes an exemption to this behaviour for nodes whose
address appears in the Destination Address field of the IPv6 header.
This text has not changed from 1883 to 2460 to 8200.

RFC 8200 includes explicit text to remind the reader that when a
Routing Header is present the node in the Destination Address header
may not be that of the ultimate recipient. This text has also not
changed from 1883 to 2460 to 8200.

Jinmei's email of 2020.05.12 presents, IMHO, a fair walk-through of
the evolution of the text.  The final summary of "most people's
interpretation" though is I think possibly a subjective matter.


[2] The consensus achieved on this was rough -- very rough, to quote
Suresh.  In the end, RFC 8200 is the text that we got.

You cite Suresh's email from 2017.03.17.  Alvaro cited, among other
things, the minutes of 6man at IETF 98 on 2017.03.30 in his DISCUSS on
this very text in 2460bis on 2017.04.07.  Indeed, the document and
discussion continued to evolve even further as 2460bis wound its way
through the process.  The final version, draft -13, was uploaded on
2017.05.19.

There were numerous contributions of opinions voiced on all sides when
one goes back through the archives to search for them.  To revise this
contentious point via the erratum report process would:

    [a] necessitate hypothetical re-evaluation of the already rough
consensus from 3 years ago on the new proposed text, and

    [b] risk inappropriately discarding the silent agreement of those
who accept the current text.

I agree with Suresh when, in his handling of erratum report 5933, he wrote:

    "...it is impossible to tell after the fact if the proposed
replacement text would have achieved consensus..."


[3] Understandings of text and their implications may change over
time; that's okay; and we have a process for that.

That process is a new working group document that updates 8200.