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

[Fernando Gont <[e-mail]>]

Hello, Bob,

On 4/12/19 19:45, Bob Hinden wrote:
[....]
>>> 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.

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.




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

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.



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

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.



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

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