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

[Fernando Gont <[e-mail]>]

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.




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

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.

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