Subject: On the handling of errata in RFC8200

From: Fernando Gont <[email-masked]>
Date: Mon, 5 Aug 2019 18:37:40 +0300

Folks,

I'd like to ask/point out some meta comments/questions about the
handling of errata:

1) Is there an expected/specified timeframe for handling erratas? The
errata that I filled on the fragmentation part of RFC8200 stayed in
reported status for two years, and there's still other errata (#5256,
https://www.rfc-editor.org/errata/eid5256), that hasn't even been
discussed. All errata (not just the fragmentation related one) should be
processed.

2) Given the importance of the document (RFC8200), and how long we
expect it to be alive and used, I would expect the wg to make a careful
analysis of how to keep the specs in shape.

Given that fragmentation is a core part of the spec, I'd expect that at
least an RFC that replaces the fragmentation section is warranted.

However, given the importance of the document, and given that there's
other pending errata (see above), it would seem to me that the wg could
simply do rfc8200bis, with the project explicitly targeting the
addressing of existing verified. -- doing this need not "open a can of
worms", and given the importance of the RFC, this would lead to a much
cleaner outcome, relieving the reader and implementer of having to do a
mental replace of the text that has been replaced (whether by a verified
errata or by an RFC that replaces a section).

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

---

From: Bob Hinden <[email-masked]>
Date: Mon, 5 Aug 2019 10:53:30 -0700

Fernando,

This was discussed in the 6man session in Montreal, see:

https://datatracker.ietf.org/meeting/105/materials/slides-105-6man-sessa-ipv6-rfc8200-fragmentation-errata-00

The direction we received from our AD was to first close the Errata.   Then we can consider doing an updating RFC.   The text I sent for review would be the basis for that.  But we first need to agree on the text.

There was not any support that I heard for doing an RFC8200bis.

Bob

p.s. The two other reported errata on RFC8200 are editorial on Appendix B. "Changes Since RFC 2460".  Hardly pressing to resolve.

> On Aug 5, 2019, at 8:37 AM, Fernando Gont <[email-masked]> wrote:
> 
> Folks,
>

---

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

On 5/8/19 20:53, Bob Hinden wrote:
> The direction we received from our AD was to first close the Errata. 

As noted in the errata itself, I guess it can be marked as verified, and
possible amended (verifier notes) at any time. Doing a full rewrite of
the section, while worthwhile, would seem more than an errata. i.e., the
more complete rewrite (while nice) seems IMHO more appropriate for an
updating RFC or bis document.

>  Then we can consider doing an updating RFC.   The text I sent for review would be the basis for that.  But we first need to agree on the text.
> 

I watched the recording. IIRC, I didn't see many opinions on any
specific path, other than the AD noting that the errata should be verified.

I certainly wouldn't want an RFC8200bis that opens up discussion for the
IPv6 std (and rehash discussions we previously had), but wish we had a
clean base spec.  I'm frustrated of not having catched this when
reviewing rfc2460bis piecemeal, and only catching it when re-reading the
doc from scratch for other reasons. But, anyway, I'd expect the lifespan
of IPv6 to be long enough that getting a clean base spec now is worth doing.

> p.s. The two other reported errata on RFC8200 are editorial on Appendix B. "Changes Since RFC 2460".  Hardly pressing to resolve.

Those could be simply marked as "accepted for future document update" --
although at the same time, as you correctly note, I don't care much
about an error in "changes since..".

The other errata I was referring to refers to an error in Section 4.8.
It is this one: https://www.rfc-editor.org/errata/eid5256 , and should
be marked as "Verified".

Thanks,

---

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

> There was not any support that I heard for doing an RFC8200bis.

I'd go further: the muttering in the room was that we'd be asking for trouble
by doing so at this point in time. The issues that were contentious when
we did RFC8200 are still contentious. I don't think anyone said this at the
microphone, so you won't find it in the minutes.

   Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

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

> microphone, so you won't find it in the minutes.

Thanks for the note!

Can't a document be bis-ed on with a concrete goal and limiting the
changes that can be applied? -- I've seen this done for other documents.

(fwiw, and for the record: I would be against reopening the rfc2460bis
discussions, but would like a clean ipv6 base spec.. hence the suggestion)

---

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

Fernando et al,

> discussions, but would like a clean ipv6 base spec.. hence the suggestion)

There is a tool in the works that I have lots of hope for.
It will apparently give you a way of showing the document with the errata applied.
I'm sure that requires some tagging in the errata themselves.
If that works, then that would serve the purpose of providing a consistent document.

Cheers,
Ole

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 6 Aug 2019 09:15:20 +0100

> If that works, then that would serve the purpose of providing a consistent document.

There really ought to be a process where the WG (or AD) can declare a 
scope limit to a bis change.

We get IETF documents from time to time where it is important there is a 
clean text with all changes applied, a unique RFC number that 
distinguishes it from earlier versions and it is in the main RFC repository.

Very few people outside the IETF really know about the errata system.

- Stewart

---

From: Alvaro Retana <[email-masked]>
Date: Tue, 6 Aug 2019 06:46:33 -0400

On August 6, 2019 at 4:15:43 AM, Stewart Bryant ([email-masked])
wrote:

FYI — with the intent for it to *not* be discussed on this thread; there’s
been some discussion on the ietf@ietf list.

https://tools.ietf.org/html/draft-roach-bis-documents

Alvaro.

---

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

> distinguishes it from earlier versions and it is in the main RFC

Agreed. Suresh?

> Very few people outside the IETF really know about the errata system.

Fully agree. That's yet one more reason to have the ipv6 base spec in a
single and clean document.

Thanks!

Cheers,

---

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

> If that works, then that would serve the purpose of providing a consistent document.

Given that these errata have been filled almost two years ago, I don't
think it makes sense to sit on them waiting for something else to happen.

That said, while such a tool may be of value, reality is that, as
Stewart noted, a lot of people don't even know about the errata system.
And many of us, including myself, work off-line with a copy of the RFC
repository.

Having to patch (whether mentally, manually, or via a tool) such a core
document as the IPv6 base spec is not a good idea, IMO.

---

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

On 6/8/19 13:46, Alvaro Retana wrote:
> On August 6, 2019 at 4:15:43 AM, Stewart Bryant
> ([email-masked] <mailto:[email-masked]>) wrote:
> 
> FYI — with the intent for it to *not* be discussed on this thread;
> there’s been some discussion on the ietf@ietf list.
> 

Thanks a lot for this pointer! -- Looks like it covers the situation I'm
referring to. I will read it fully, and provide comments on ietf@

Thanks!

---

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

Fernando,

> single and clean document.

The tool would hopefully present that as one single and clean document.
Let's wait and see.

There are a few options open to us as presented by Bob:

1) Errata. Complete new text for section 4.5 in errata.
2) Updsating document. New document that provides a new section 4.5
3) Refreshing RFC8200

3 is problematic for a set of reasons, mostly regarding outside perception.
Now if we were to do 3 today, I'd suggest we'd publish that document without any section 4.5 at all.

Best regards,
Ole

---

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

> 1) Errata. Complete new text for section 4.5 in errata.

That doesn't look like errata -- even when I filled them. It looks like
a complete rewrite of an important section, something worth an updating
RFC or bis document. 8 pages of errata seems to me like a bit of a stretch.

> 2) Updsating document. New document that provides a new section 4.5

Better than 1), indeed. Still that is ~8 pages obsoleted from a from a
35 page documents (when you remove boilerplates).

> Now if we were to do 3 today, I'd suggest we'd publish that document without any section 4.5 at all.

I suggest that we leave the "perception" thing to other entities like
the IPv6 forum and such, and that we do our best to publish good and
clean specs.

Without raising a new debate, it would seem to me that we are quite
frequently failing to improve things and ship better specs on that
premise of the external perception. (that has no scientifically proof
that links it to ipv6 deployment (or lack thereof). RFC8200 was shipped
as full standard, in part, to send a signal to the outside. The fact
that most of us agree that fragmentation shouldn't be there might make
some wonder if we were supposed to elevate rfc2460 to std, as is.

Focusing on external perception seems to lead to suboptimal
specifications, and doesn't seem to have any correlation with increased
IPv6 deployment.

Thanks,