Re: Updated IESG Statement "IESG Processing of RFC Errata for the IETF Stream"

[Spencer Dawkins at IETF <[e-mail]>]

Massively chopping this thread of (I'm not being snarky) wisdom, down to
the part I think I can contribute to ...

On Sun, May 9, 2021 at 3:20 PM John C Klensin <[e-mail]> wrote:

>
> These distinctions are particularly important if the IETF is
> going to publish versions of RFCs with errata incorporated.


Because I honestly don't know who might be reading this e-mail thread, and
what they might know, let me say this out loud.

I have no inside knowledge of what the *IETF* might plan to publish, but
for what the RFC Editor publishes, this ship has sailed.

Tl;dr

I had the privilege (HAH!!!) of explaining the Theory and Practice of RFC
Errata to members of the CELLAR working group that I co-chair with Michael
Richardson, during our last virtual meeting. This group has published one
RFC, and https://datatracker.ietf.org/doc/html/rfc8794 is 2700 lines long
and pretty dense, so they're receiving errata report (mostly through
Github, from people who don't even participate in CELLAR, much less grok
the difference between the RFC view in the datatracker and the RFC view on
rfc-editor.org).

They were horrified to discover that RFCs are immutable, and were imagining
that they were going to have to roll another RFC every time someone
reported a bug.

I showed them (as an example) that if they searched for RFC3261 on the RFC
Editor website, and clicked on the cute "HTML with a green check mark"
icon, they got a page that started with this:

This is a purely informative rendering of an RFC that includes verified
errata. This rendering may not be used as a reference.

The following 'Verified' errata have been incorporated in this document: EID
316 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#eid316>, EID
1051 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_1051>, EID
1073 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#eid1073>, EID
1470 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_1470>, EID
2051 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_2051>, EID
3183 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_3183>, EID
4567 <https://www.rfc-editor.org/rfc/inline-errata/rfc3261.html#btn_4567>

And if you click on the links, it shows you where each errata goes, and if
you click on "Expand", it shows you the Verified errata, and if the errata
had OLD/NEW text, the new text is shown inline.

So, what you get is something like this:

   The handling parameter, handling-param, describes how the UAS should Expand
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required"
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

*EID 4567 <https://www.rfc-editor.org/errata/eid4567> (Verified) is as follows:*
*Section:* 20.11
*Original Text:*

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, the
value "required" SHOULD be assumed. The handling parameter is
described in RFC 3204 [19].
*Corrected Text:*

The handling parameter, handling-param, describes how the UAS should
react if it receives a message body whose content type or disposition
type it does not understand. The parameter has defined values of
"optional" and "required". If the handling parameter is missing, or if
the Content-Disposition header field is missing, the value "required"
SHOULD be assumed. The handling parameter is described in RFC 3204 [19].

*Notes:*
None


So, they're SUPER excited about making use of this mechanism, and we can
talk about whether people really read Public Service Announcements *("This
is a purely informative rendering of an RFC that includes verified errata.
This rendering may not be used as a reference.") *- but can we blame them
for *wanting *to do that?

So, ISTM that what our current errata system was set up to do (and I can't
emphasize enough that I wasn't there when it was set up), was to Reject
stuff that wasn't REALLY an errata or obviously not the right correction to
make, Verify obvious corrections, and Hold Everything Else For Document
Updates, so that a working group has a chance to talk about what The Right
Thing To Do is, given that they missed something Technical when they looked
at this for the first time, as opposed to having an AD decide *now* what
The Right Thing To Do will be at some point in the future, and constraining
the working group when they *do* have enough brain cells to update the
document. (If that's not the case, my apologies to the people who set it up
in the first place).

If we wanted to make life easier for people using IETF specifications (as
opposed to going to the Github repos and "making" their own specifications
from Master/Main branches, we might think about

   - How much we want to "warn people away" from using the really helpful
   errata inlining mechanism that is already available from the RFC Editor,
   and
   - How much stuff that's not Verified would be useful to present to the
   people who use our documents - especially stuff that's Rejected because it
   doesn't reflect the thinking of (my own favorite) the NFSv4 working group
   more than a decade ago, but is really close to what they are thinking today.

As always, thanks for listening. And Do The Right Thing.

Best,

Spencer, who used the tools format of RFCs in HTML almost exclusively for
at least a decade, and then switched to the datatracker HTML format,
neither of which were the canonical txt-then, XML-now formats that we wish
people would use.