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

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Dec 2019 14:45:59 -0800

Fernando,

> On Nov 26, 2019, at 1:24 PM, Fernando Gont <[email-masked]> wrote:
> 
> On 23/11/19 06:33, Ole Troan wrote:
>> Thank you for reviewing.
>> To confirm, did you also review the fragmentation/reassembly algorithms?
> 
> I skimmed through them. But please let me take a closer look again.
> 
> 
> 
> 
>> Comments below.
>> 
>>>> 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.
>>> 
>>> 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").
>> 
>> 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.
> 
> 
> 
>>>     (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".
>> 
>> 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.
> 
> 

"Per-Fragment headers" is not a change from RFC8200.

> 
> 
>>>> 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?
>> 
>> 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.

This was one of the approaches discussed at the pervious 6man session at the Montreal IETF.

We discussed the current approach with Suresh, this was sent to the list, and was discussed in Singapore 6man session, and it seems to be a reasonable approach to me and Ole.   No one in the w.g. session objected to this approach.

> 
> 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?
> 
> 
> 
> [...]
>>> 2) If there's no concrete plan to do rfc8200bis, shouldn't this be
>>> hanlded in e.g., an updating RFC?
>> 
>> No, why?
>> 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.

I do not think is possible to do an RFC8200bis and limit the changes to just this.

> 
> 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.
> 

We can discuss this after the current errata are processed.

Bob

> 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,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [email-masked]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
> 
> 
> 
>

---

From: Bob Hinden <[email-masked]>
Date: Wed, 4 Dec 2019 14:49:10 -0800

At the Singapore IETF 106 6man session the plan for resolving Errata 5170, 5171, 5172, 5173 on RFC8200 was discussed.  The plan presented was 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 “Verified”.  The slides can be found at:

https://datatracker.ietf.org/meeting/106/materials/slides-106-6man-sessa-next-steps-in-rfc8200-fragmentation-errata

The presentation included the changes in both a side by side diff form, and an inline diff form.

There was support in the w.g. session for this approach.

This confirmation call with end on December 18, 2019.

Note, this action is about how we process the errata, if an updating RFC is found to be useful, the w.g. can discuss this later.

Thanks,
Bob & Ole

> Begin forwarded message:
> 
> From: Bob Hinden <[email-masked]>
> Subject: Next Steps Errata 5170, 5171, 5172, 5173 on RFC8200
> Date: November 17, 2019 at 11:30:02 PM PST
> To: IPv6 List <[email-masked]>
> Cc: Bob Hinden <[email-masked]>, Suresh Krishnan <[email-masked]>, Ole Trøan <[email-masked]>
> 
> 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:
> 
> 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: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Dec 2019 14:02:15 +1300

> This confirmation call with end on December 18, 2019.

I completely agree with this course of action.

   Brian

>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [email-masked]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Dec 2019 23:47:26 -0300

Hello, Bob,

On 4/12/19 19:45, Bob Hinden wrote:
[....]
>> EHs that "must" be processed en route.

?

> "Per-Fragment headers" is not a change from RFC8200.

Exactly. But the new text has a new definition wrt what is considered
"extension headers".

Namely, this is new:
"           Extension headers are all other extension headers that are
           not included in the Per-Fragment headers part of the packet."

I personally believe that this is a circular definition, and thus is
incorrect. Besides, given how "creative" folks have been to circumvent
RFC8200, I don't even want to analyze the possibilities regarding how
this new definition, which essentially states that extension headers are
a subset of what extension headers really are, could be leveraged by
folks trying to find imaginary loopholes in the spec.

> We discussed the current approach with Suresh, this was sent to the list, and was discussed in Singapore 6man session, and it seems to be a reasonable approach to me and Ole.  

My recollection from the pre-Singapore meeting was that Suresh
recommendation (at Montreal) had been to verify the errata and include
any alternative text in the verifier's notes. THere wasn't much on the
topic since then (pre-Singapore), but the proposal in Singapore was
different. Hence my question.

> No one in the w.g. session objected to this approach.

Why would the errata be rejected?  It would seem to me that the errata
can be rejected if it0s incorrect, when in this case it clearly isn't
(ref:
<https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/>)

And I don't see why the alternative text couldn't ve conveyed in the
"verifier's notes", which seems to be what SUresh had suggested at the time.

> I do not think is possible to do an RFC8200bis and limit the changes to just this.

I recall reading about this. But, in any case, I guess we can test the
feasibility before discarding it.

As noted, if you do this in an errata, essentially you cannot reference
the fragmentation part of the specification anymore.

> We can discuss this after the current errata are processed.

It would seem to me that the reason fow which the verification of this
errata is taking so long is that we're trying to cast into stone text
that should be in a Std. Track document...

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Wed, 4 Dec 2019 23:51:56 -0300

On 4/12/19 19:49, Bob Hinden wrote:
> At the Singapore IETF 106 6man session the plan for resolving Errata
> 5170, 5171, 5172, 5173 on RFC8200 was discussed.  The plan presented
> was 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 “Verified”.  The slides can be
> found at:
> 

My question is: what's the rationale for rejecting the errata?

According to
<https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/>,
there does not seem to be any criteria to reject a submitted errata
based on "I have a better way to address it". It would seem to me that,
if anything, that should be part of the "verifier's notes", as opposed
to a criteria for rejecting the errata.

Not that this particular case would worry me a lot. But we'd be setting
a precedent here, which doesn't seem correct to me.

Thanks,
--
Fernando Gont
SI6 Networks

---

From: Ole Troan <[email-masked]>
Date: Thu, 5 Dec 2019 11:05:26 +0100

Fernando,

> My question is: what's the rationale for rejecting the errata?

I believe that has been answered.
There are not 4 separate solutions that map directly to each individual errata 5170, 5171, 5172 and 5173.
One errata with one solutions makes the fix consistent and consumable.

There might be an underlaying problem with the errata system. It conflates the bug reporting part with the document ammending part.
My preference would have been two separate tools. Barring that I would have preferred us to just have the above errata deleted.
Given the current state of process "reject" is the only choice.
I understand that you disagree with this position, although I cannot quite say I understand your rationale for why.

I was hoping that the focus on this discussion would be on getting the bug-fix right, rather than on process issues.
That is regardless Suresh' decision to make.

Best regards,
Ole

---

From: Bob Hinden <[email-masked]>
Date: Tue, 24 Dec 2019 09:24:09 -0800

This concludes the Confirmation Call on Resolution of Errata 5170, 5171, 5172, 5173 on RFC8200.

A new errata will be filed that resolves the issues raised in Errata 5170, 5171, 5172, and 5173.

The new errata will include the following (as required by the RFC Editor errata system):

--------

Type:

  Technical

Section:

  4.5

Original Text:

  [Text from attachment sec4-5-orig.txt]

Corrected Text:

  [Text from attachment sec4-5-new.txt]

Notes:

   This errata replaces and resolves the issues raised in Errata 5170, 5171, 5172, 5173.   Credit
   goes to Fernando Gont for reporting the issues raised in these errata.   They correctly reported
   that the text in Section 4.5 of RFC8200 defined Fragment Offset as pointing to “Fragmentable Part”,
   this was an error and should have pointed to “Extension & Upper-Layer Headers”.

   After review by the 6man working group the conclusion was to fix the issue in a more general way
   than what was proposed in Errata 5170, 5171, 5172, 5173, hence the need for a new errata.

—————

Note, one this issue is closed, if an updating RFC is found to be useful, the w.g. can discuss this later.

Thanks,
Bob & Ole

> On Dec 4, 2019, at 2:49 PM, Bob Hinden <[email-masked]> wrote:
>