Subject: Re: Errata 5173 on RFC8200

From: Fernando Gont <[email-masked]>
Date: Mon, 5 Aug 2019 19:04:31 +0300

Hi, Bob,

On 31/7/19 05:07, Bob Hinden wrote:
> During the 6man session on Thursday at IETF 105 in Montreal, we discussed Errata 5173 that have been filed on the Fragment Header Section 4.5 in RFC8200.   The presentation is available at:
> 
> https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-ipv6-rfc8200-fragmentation-errata-00
> 
> The errata can be found at:
> 
> https://www.rfc-editor.org/errata_search.php?rfc=8200
> 
> Errata 5173 proposes to change the reassembled original packet figure from:
> 
>    +--------------+------------------+---------+--------+-//--+--------+
>    | Per-Fragment | Ext & Upper-Layer| first   | second |     | last   |
>    | Headers      | Headers          |frag data|fragment|.....|fragment|
>    +--------------+------------------+---------+--------+-//--+--------+
> 
> to:
> 
>    +--------------+------------------+---------+--------+-//--+--------+
>    | Per-Fragment | Ext & Upper-Layer| first   | second |     | last   |
>    | Headers      | Headers          |fragment |fragment|.....|fragment|
>    +--------------+------------------+---------+--------+-//--+———----—+
> 
> This change is not correct, it is only the fragment data as shown in the figure, unlike the following fragments.  This Errata should be marked as rejected.

I just looked at the text again (after not looking at it for years :-)
), it it still seems to be that the change is correct.

The first and most easy rationale for supporting the change is that:

--- cut here ----
   reassembled original packet:

   +---------------+-----------------+---------+--------+-//--+--------+
   | Per-Fragment  |Ext & Upper-Layer|  first  | second |     | last   |
   |    Headers    |     Headers     |frag data|fragment|.....|fragment|
   +---------------+-----------------+---------+--------+-//--+--------+

---- cut here ----

from page 20 of RFC8200 should clearly match:

---- cut here ----
   +-----------------+-----------------+--------+--------+-//-+--------+
   |  Per-Fragment   |Ext & Upper-Layer|  first | second |    |  last  |
   |    Headers      |    Headers      |fragment|fragment|....|fragment|
   +-----------------+-----------------+--------+--------+-//-+--------+
---- cut here ----

from page 18 of RFC8200.

Otherwise there's a mismatch within RFC8200 itself. It would seem to me
that this errata, as it stands, is correct.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Aug 2019 08:51:54 +1200

Hi Fernando,

Now you've made me go and read the text again ;-)

> ), it it still seems to be that the change is correct.

Well, the problem is slightly deeper than the original erratum states:

1: You are correct that the two figures on p18 and p20 should be identical.

2: Look at the text on page 17/18:

"The first fragment packet is composed of:
    (1)  The Per-Fragment headers...
    (2)  A Fragment header...
    (3)  Extension headers, if any, and the Upper-Layer header...
    (4)  The first fragment."

The problem is that "The first fragment" is *undefined*. I think it
needs to be defined precisely, i.e.:

"   (4)  The first fragment. This is the first part of the fragmentable part
         of the packet."

Bob's reading is that "first fragment" might mean "first fragment packet"
and "first frag data" is supposed to avoid that. But I'd slightly prefer
fixing the text in (4) and using "first fragment" consistently.

Regards
     Brian

---

From: Bob Hinden <[email-masked]>
Date: Mon, 5 Aug 2019 14:29:55 -0700

Brian,

> On Aug 5, 2019, at 1:51 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi Fernando,
> 

BTW, the proposed text for the other Fragmentation errata, changes this figure so this one is no longer relevant.  Please review that.

Bob

---

From: Fernando Gont <[email-masked]>
Date: Tue, 6 Aug 2019 00:18:52 +0300

> Now you've made me go and read the text again ;-)

Same here :-)

> Well, the problem is slightly deeper than the original erratum states:

FWIW, this is acknowledged on subsequent (or prior? :-) ) erratas. I was
reporting as I was reading, and eventually realized that the problem was
deeper (noted "the fix needs more work" in one of the erratas, IIRC).

> needs to be defined precisely, i.e.:

I'm all for proper definitions and terminology.

E.g., as noted in a previous email, "per-fragment headers" vs "extension
headers" doesn't seem 100% correct: the per-fragment headers also
include EHs. The use of "fragmentable part" can also be confusing, since
it includes part of the EH chain, which *should not* be fragmented (the
IPv6 fragmentation mechanism does allow its fragmentation, but
fragmentation of the ipv6 header chain has been banned by RFC7112).

FWIW, throughout the Fragmentation section, "[nth] fragment" seems to be
consistently used for "[nth] chunk of fragmentable part" -- when
referring to a packet, the word "packet" is appended to it.

> fixing the text in (4) and using "first fragment" consistently.

Then the question would be "what's the first fragment data?". -- because
from an IPv6 point of view, the "Ext & Upper Layer headers" are the
fragment data.

Cheers,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 6 Aug 2019 10:58:34 +1200

> BTW, the proposed text for the other Fragmentation errata, changes this figure so this one is no longer relevant.  Please review that.

Yes, it looks OK. I still think that defining the term "first fragment" will avoid any residual misunderstanding, even if it may strictly be redundant.

Regards
    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2019 09:20:00 +0200

Brian,

> fixing the text in (4) and using "first fragment" consistently.

I also find the "first fragment" vs "first fragment packet" somewhat confusing.
"The first fragment" refers back to the figure. 2460 uses "the fragment itself".
That might be somewhat better.

And that comment is made in the context of the proposed new fragment text, not in the context of errata 5173. Which I still think should be rejected.

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 6 Aug 2019 13:58:30 +0300

> That might be somewhat better.

As I mentioned to Bob before
(https://mailarchive.ietf.org/arch/msg/ipv6/wL0G2Ms2awMhFDbetWxam6OOszk), RFC8200
uses two different terms for the same thing. That can't be right.

I'm not sure what's the basis for rejecting this erratum. COuld you
please elaborate?

Thanks,

---

From: Ole Troan <[email-masked]>
Date: Tue, 6 Aug 2019 13:18:59 +0200

Fernando,

> I'm not sure what's the basis for rejecting this erratum. COuld you

My apologies, I read it in reverse. Yes, this is correct.
But it will of course be subsumed by the other fix.

I think this exposes a larger problem with the errata system.
The errata system is like a bug reporting system, where both the bug report and the proposed solution is merged.
That creates a mess. As in this case we have 4 errata, that is solved by one single change.

A cleaner end result would have been one erratum with the problem description and the new text.
Where the new text was a result of IETF consensus.
Is there any way we can achieve that?

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Tue, 6 Aug 2019 14:42:26 +0300

> That creates a mess. As in this case we have 4 errata, that is solved by one single change.

I partly agree.

As noted before, I was reading RFC8200, and when I found the first bug,
I thought it was just that: one small bug in the spec -- hence I
submitted it.

IN the second or third erratum, I realized that there was a larger
problem (and explicitly noted that "this requires more work"), that's
why I ended up submitting three errata, rather than, say, one.

That said, my view of the errata system is that it is meant for minor
patches. For instance, one is expected to quote the problematic text,
and what it should be replaced with.

If one wanted to handle this whole thing with the errata system, it
would seem that one could not apply the usual "replace this with that",
but would have to provide a meta description of the problem, and then
come up with "this 8 pages of the RFC are replaced with these other 8
pages". At which point it's not a minor patch, but a rewrite.

> Is there any way we can achieve that?

At the point in which there is so much text to be replaced, that's when
I start to consider that a quick bis document is the way to go. -- I
have no idea about the mechanism to do it (if it can be AD-sponsored, or
what). And, as noted, rasing any other discussion or rehashing any other
rfc2460bis arguments would be out of scope, of course.

Having an 8-page errata, or an updating RFC that essentially obsoletes
25% of a very core internet standard (IPv6) doesn't seem to be a good idea.

For instance (and I think this is why I was re-reading RFC8200), if I
needed to quote terminology from RFC8200 (that is not actually in
RFC8200 because we have introduced it via the errata system), how should
one go about? "Errata XXXX of RFCYYYY (defines|specifies) that..."?

---

From: Bob Hinden <[email-masked]>
Date: Tue, 6 Aug 2019 08:02:19 -0700

Fernando,

> On Aug 6, 2019, at 4:42 AM, Fernando Gont <[email-masked]> wrote:
> 
> ….

> 25% of a very core internet standard (IPv6) doesn't seem to be a good idea.

You math is off.  RFC8200 is 42 pages, section 4.5 is 7 1/2 pages, far less than 25%.  Further, if you look at the diff I sent earlier, the actual text changes are pretty small.

Let’s move this discussion back to reviewing the proposed text.  What ever we end up doing, the first step is to process the currrent errata.

Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Aug 2019 08:26:52 +1200

> That might be somewhat better.

Anything that removes the potential ambiguity is fine by me.
 
> And that comment is made in the context of the proposed new fragment text, not in the context of errata 5173. Which I still think should be rejected.

Yes, but it's rejected because it's made irrelevant by the fixing of the other errata.

And I agree with Bob that we shouldn't debate the errata system here. This would be a good case study for discussion in the newtrk WG if it still existed.

   Brian

   Brian

---

From: Fernando Gont <[email-masked]>
Date: Wed, 7 Aug 2019 19:53:03 +0300

On 6/8/19 18:02, Bob Hinden wrote:
> You math is off.  RFC8200 is 42 pages, section 4.5 is 7 1/2 pages, far less than 25%.  

FWIW, the math I did, mentioned in my previous email, was something like
(42-page document - 5 pages (boilerplate, references, changelog) ) / 8
page (frag section).

In any case, my point was that if one is to replace a multi-page
section, doing it via errata seems a bit of a stretch. That was my
point, rather that the specific rattio of pages being patched.

> Further, if you look at the diff I sent earlier, the actual text changes are pretty small.

Is the goal to submit such changes into the verifiers notes?
somewhere/somehow else?

> Let’s move this discussion back to reviewing the proposed text.  What ever we end up doing, the first step is to process the currrent errata.

Agreed with that.FWIW,this is my review:
https://mailarchive.ietf.org/arch/msg/ipv6/K8prTVSsgcDDIP6gSaQdjBEIxEk

Thanks,

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Aug 2019 13:53:55 -0700

> On Aug 6, 2019, at 1:26 PM, Brian E Carpenter <[email-masked]> wrote:
> 

The current proposed text is:

      (4)  The first fragment.

I can see how that could be confusing because it could be assume to also include the EH and Upper layer headers.  How about instead:

      (4)  The remainder of the first fragment.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 9 Aug 2019 11:32:27 +1200

>       (4)  The remainder of the first fragment.

Exactly right, IMHO.

   Brian

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 8 Aug 2019 19:52:37 -0400

Hi Ole,

> On Aug 6, 2019, at 7:18 AM, Ole Troan <[email-masked]> wrote:
> 
> Fernando,
> 

In short, no. As you pointed out the errata system has the issue and the resolution conflated. I think this is something we need to think about and provide input about before someone designs the proposed in-line errata system.

Thanks
Suresh

---

From: Bob Hinden <[email-masked]>
Date: Thu, 8 Aug 2019 16:57:53 -0700

> On Aug 8, 2019, at 4:32 PM, Brian E Carpenter <[email-masked]> wrote:
> 

Thanks.   Let’s do that then.

Bob

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 8 Aug 2019 20:11:45 -0400

Hi Fernando,

> On Aug 6, 2019, at 7:42 AM, Fernando Gont <[email-masked]> wrote:
> 

I think as Brian raised in his earlier mail up thread, there does not seem to be much appetite in the WG to do a bis document (though it was one of the options Bob brought up in his presentation). After we agree on the replacement text in the WG, let's decide how to go about effecting the changes.

Thanks
Suresh

---

From: Ole Troan <[email-masked]>
Date: Fri, 9 Aug 2019 10:44:29 +0200

> In short, no. As you pointed out the errata system has the issue and the resolution conflated. I think this is something we need to think about and provide input about before someone designs the pr…

Right, with the inline errata system you cannot accept 4 errata with the same resolution.

I suggest we do the following when we have agreed on text.

- enter a new errata that is carefully designed with both problem description and resolution to present nicely inline for the tool.
- reject/remove the 4 erratas that triggered this work. Noting that they have been replaced with erra-xx

Cheers,
Ole

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Aug 2019 13:29:16 +0300

>       (4)  The remainder of the first fragment.

That improves the text, indeed.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Aug 2019 13:31:29 +0300

On 9/8/19 03:11, Suresh Krishnan wrote:
> Hi Fernando,
> 
>> On Aug 6, 2019, at 7:42 AM, Fernando Gont <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
[....]
> I think as Brian raised in his earlier mail up thread, there does not
> seem to be much appetite in the WG to do a bis document (though it was
> one of the options Bob brought up in his presentation). After we agree
> on the replacement text in the WG, let's decide how to go about
> effecting the changes.

I watched the recording and there wasn't much of a discussion on the
topic. I think the question and the options should be posed to the wg on
the mailing-list. I have no idea what that would converge to, but I do
think the question should be posed to the wg on list, rather than
assuming that's a no-go because nobody argued in favour of it at the
meeting.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 9 Aug 2019 13:34:09 +0300

> Right, with the inline errata system you cannot accept 4 errata with the same resolution.

The thing here is that there were separate errors submitted in different
errata, that would lead to separate patches.

What you propose is to patch multiple things on the same patch/commit.
-- not that I necessarily disagree.

One can use the first errata, put the text in verifier's notes, and I
guess, for the rest, HFDU (or so) and point to the first errata.