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

[Ole Troan <[e-mail]>]

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

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.

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

> * 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)

Correct.

> 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

Best regards,
Ole