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

[Fernando Gont <[e-mail]>]

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

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