Subject: Next Steps Errata 5170, 5171, 5172, 5173 on RFC8200

From: Bob Hinden <[email-masked]>
Date: Mon, 18 Nov 2019 15:30:02 +0800

Hello,

Following up on the discussion from the 6man and the discussion on the IPv6 list, Three files are attached:

sec4-5-orig.txt                  The original section 4.5 from RFC8200
sec4-5-new.txt                   The proposed section 4.5 replacement
sec4-5-new-from-orig.diff.html   A diff of the two.

This incorporates one change agreed to on the list to change the text describing the first fragment packet from:

    (4)  The first fragment.

  to:

    (4)  The remainder of the first fragment.

The plan agreed to with Suresh, our Internet AD, is to open a new Errata that describes the errors in the Fragmentation text in Section 4.5 of RFC8200 and include the revised text in sec4-5-new.txt in the errata, and then close Errata 5170, 5171, 5172, and 5173 as “Rejected" with a pointer to the new Errata.  The new Errata would then be marked as “Held for Document Update”.

This will be discussed at the first 6MAN session on Thursday in Singapore.

Thanks
Bob & Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 22 Nov 2019 00:28:15 -0300

Hello, Bob,

For some reasons I failed to recive and/or see this before. COmments
in-line...

On 18/11/19 04:30, Bob Hinden wrote:
> sec4-5-orig.txt                  The original section 4.5 from
> RFC8200 sec4-5-new.txt                   The proposed section 4.5
> replacement sec4-5-new-from-orig.diff.html   A diff of the two.
> 
> This incorporates one change agreed to on the list to change the text
> describing the first fragment packet from:
> 
> (4)  The first fragment.
> 
> to:
> 

I did a fresh review of the text. Comments:

      The Per-Fragment headers must consist of the IPv6 header plus any
      extension headers that must be processed by nodes en route to the
      destination, that is, all headers up to and including the Routing
      header if present, else the Hop-by-Hop Options header if present,
      else no extension headers.

Based on the updated processing of HbH OPtions EH, this should probably
say something like "that may need to be processed" (as opposed to "must").

      (3)  Extension headers, if any, and the Upper-Layer header.  These

I'd use a qualifier for these EHs, such as "per-datagram extension
headers", if you wish. Otherwise there's a double and conflicting
definition of "EH".

> The plan agreed to with Suresh, our Internet AD, is to open a new
> Errata that describes the errors in the Fragmentation text in Section
> 4.5 of RFC8200 and include the revised text in sec4-5-new.txt in the
> errata, and then close Errata 5170, 5171, 5172, and 5173 as
> “Rejected" with a pointer to the new Errata.  The new Errata would
> then be marked as “Held for Document Update”.

Two questions regarding this:

* At the previous IETF, the plan was for the errata to be accepted and
for the alternative text to be conveyed in the verifier notes. Is there
any rationale for this procedural change?

* Given that the portion of text being updated is non-minor, I wonder:

 1) Is there any concrete plan of doing rfc8200bis? (I assume there isn't)

 2) If there's no concrete plan to do rfc8200bis, shouldn't this be
hanlded in e.g., an updating RFC?

Thanks!

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

---

From: Ole Troan <[email-masked]>
Date: Sat, 23 Nov 2019 10:33:26 +0100

Thank you for reviewing.
To confirm, did you also review the fragmentation/reassembly algorithms?

Comments below.

> say something like "that may need to be processed" (as opposed to "must").

Current wording as from 2460 is fine.

> headers", if you wish. Otherwise there's a double and conflicting

Let's not introduce new terminology.

> any rationale for this procedural change?

Reconciling the 4 existing errata would not give a consistent and consumable view of the change.

> 1) Is there any concrete plan of doing rfc8200bis? (I assume there isn't)

Correct.

> hanlded in e.g., an updating RFC?

No, why?
See also inline-errata. Example https://www.rfc-editor.org/rfc/inline-errata/rfc4960.html

Best regards,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Nov 2019 18:24:14 -0300

> To confirm, did you also review the fragmentation/reassembly algorithms?

I skimmed through them. But please let me take a closer look again.

> Current wording as from 2460 is fine.

That's the point: RFC8200 changed in this respect (IIRC) -- there's no
EHs that "must" be processed en route.

> Let's not introduce new terminology.

The text *is* introducing new terminology, anyway -- e.g. "per fragment
headers". Definitions like "extension headers are all the extension
headers that were not included..." (or the like) seem very confusing to me.

> Reconciling the 4 existing errata would not give a consistent and consumable view of the change.

Why not? Just verify them, and include the text in the "verifier notes"
of one of them -- or even in all of them, if you which.

That's what Suresh suggested in March, IIRC.

A meta question is that based on the discussion that happened earlier
this year, it seemed to me that:

* The extisting errata would be verified, and the correcting text would
be added to the verifier notes.

* It was inappropriate to fix this in an errata, but rather this would
require an i-d of some sort -- most likely an updating I-D that would
contain the whole fragmentation/reassembly text, and that would formally
update RFC8200.

So my question is: when did the action plan change, and how?

[...]
> See also inline-errata. Example https://www.rfc-editor.org/rfc/inline-errata/rfc4960.html

I guess this part says it all: "This is a purely informative rendering
of an RFC that includes verified errata. This rendering may not be used
as a reference." -- It doesn't seems sensible to have a core and
substantial part of the spec in an errata.

That aside, I consider myself a person that reads RFCs, and wasn't even
aware that this tool/feature existed... and have no reason to believe
that folks that occasionally read RFCs will know better.

Reality is that folks look at (and print) RFCs. Given that the portion
of text that is affected is rather significant, and that I'd expect that
we use IPv6 for quite some time, I think this deserves to be addressed
in a more clear and explicit way.

If you ask me, I'd probably do rfc8200bis **if** it can be done on the
condition that the bis effort is meant to **only** address the pending
errata (there's another technical bit, yet unverified, submitted by
somebody else). Not that I like it, but that would give us a clean,
stand-alone document that we can use and reference.

As a second option, I'd have an updating RFC. At least the "Updates:
RFC8200" metadata will more clearly note that there's another doc to be
read.

Doing a multi-page update of a core document in an errata doesn't seem
like the proper way to go to me.

Thanks!

Cheers,