Subject: Re: RFC Errata: when to file, and when not to

From: "Martin J. Dürst" <[email-masked]>
Date: Thu, 02 Aug 2012 19:28:38 +0900

Hello Barry,

Thanks for explanation about errata, which must have been caused at 
least in part by an erratum that I submitted recently.

Just for the record, I want to mention that the errata report form at 
http://www.rfc-editor.org/errata_report.php has a "type" field with two 
categories, "Technical" and "Editorial", where "Editorial" is defined in 
the help popup as: "spelling, grammar, punctuation, or syntax error that 
does not affect the technical meaning". This would directly contradict 
your "Criterion 2 means that minor typos are NOT appropriate errata."

However, my main point is a different one. At the end of your mail, you 
wrote:

 > In particular, the errata system is NOT meant to be used as an issue
 > tracker; please do not submit errata reports with the *intent* that 
they be
 > marked as "Held for Document Update", to be used as an issue list later.
 >   We have mailing lists, issue trackers, and wikis for this purpose.

Of course we have mailing lists, issue trackers, and wikis, but the 
problem is that none of them are for RFCs. And if there's a tracker for 
a bis version, it's not necessarily easy to find from the RFC.

Actually, even if somebody finds the -bis draft, in many (if not most) 
cases, these drafts don't contain pointers to issue trackers, wikis, or 
the like (a pointer to a mailing list, at least indirectly via the 
mention of a WG, should be there in most cases, I guess).

The question then comes up on whether we can do better. And my guess is 
that in this day and age of linked information, we should be able to do 
better. With the tools version of an RFC, which is quickly becoming the 
preferred version of many, it's already easy to find errata.

There are certainly many open questions when moving to better linking of 
the relevant information, such as "who approves it", "what's 'official' 
(wiki, issue tracker,...) and what not", and so on.

On 2012/08/01 8:27, Barry Leiba wrote:
> We've been seeing a lot of inappropriate errata reports, made by
> well-meaning people who, surely, think their reports are useful, even
> important.  These aren't free: they take time to process, and they form
> clutter in the errata system, obscuring the ones that do fit into what
> errata are meant to be.

These are certainly problems, and we have to work on improving the 
situation. Sending all the errata to the IESG without triage (which 
seems to be done for the "Technical" ones; not sure it's also true for 
the "Editorial" ones) definitely may not be the best for the busy people 
on the IESG to spend their time.

Regards,   Martin.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 2 Aug 2012 10:05:19 -0400

> Thanks for explanation about errata, which must have been caused at least in
> part by an erratum that I submitted recently.

Yours was one of many.  Yours was actually one that I'd like to find a
way to fix -- a URL that needs to be updated.

>> tracker; please do not submit errata reports with the *intent* that they
>> be marked as "Held for Document Update", to be used as an issue
>> list later.  We have mailing lists, issue trackers, and wikis for this purpose.
>
> Of course we have mailing lists, issue trackers, and wikis, but the problem
> is that none of them are for RFCs. And if there's a tracker for a bis
> version, it's not necessarily easy to find from the RFC.

Yes, and we're working on that.  We're looking into ways of handling
this, to provide some sort of issue tracking for RFCs.  Not sure yet
what the right way to do it is.

Barry

---

From: Alessandro Vesely <[email-masked]>
Date: Fri, 03 Aug 2012 08:19:41 -0700

On Thu 02/Aug/2012 03:28:38 -0700 Martin J. Dürst wrote:
>> tracker;
> problem is that none of them are for RFCs.

In addition, those tools seem to be intended rather for IETF internal
use than for general public.

> The question then comes up on whether we can do better. And my guess
> is that in this day and age of linked information, we should be able
> to do better. With the tools version of an RFC, which is quickly
> becoming the preferred version of many, it's already easy to find errata.

It is /not difficult/ to find errata.  "Easy" would mean that people
usually find them even if they're not purposely looking for them.  For
example, the existence of an approved errata could be signaled by
coloring the margin near the relevant text.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 3 Aug 2012 11:38:44 -0400

> use than for general public.

I would say that "IETF internal use" would refer to chairs, ADs, the RFC
Editor (which is not a function that's part of the IETF, by the way), and
so on.  It's very easy for anyone, including my mother, should she want to,
to get a login to the IETF tools system.  We could perhaps make it more
obvious that one is needed, and how to do it, but I don't know that it's
any more of a hurdle than any of the 17,000 other web things that require a
"free one-time signup".

Anyway, as I said, we haven't sorted out how we would do this, and it might
be that something even easier than what we have now would be in order.

> coloring the margin near the relevant text.

I like this idea.  Not colour, maybe -- despite the errata tool's format,
not all errata nicely fit into OLD/NEW text, and one often needs the
explanation even for those that do -- but perhaps an "errata" icon in the
margin next to the relevant text.  One could click the icon and be sent
straight to that erratum.

The trouble is that I can't see how we could do that automatically, so it
would require significant extra manual processing.  I don't have stats on
how many errata are "Verified" (and we'd only do this sort of thing for
those, I imagine), nor any real idea of how much extra work it would be for
someone to add the erratum links.  But no argument at all about how useful
it would likely be.

Barry

---

From: t.p. <[email-masked]>
Date: Tue, 7 Aug 2012 09:29:00 +0100

---- Original Message -----
From: "Alessandro Vesely" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 03, 2012 4:19 PM

<tp>
When I Google RFCnnnn, I am sometimes directed to www.ietf.org, which is
not much help here. Other times, I am directed to tools.ietf.org, whose
format I find less friendly but which does have 'errata exist' in the
top right hand corner.  However, I cannot click on that, unlike the
Obsoletes and Updates fields; but, more importantly, would your average
not-involved-in-standards audience know what errata are?  For me, the
word comes from a classical education, before ever I got involved with
standards, and so is a commonplace, but is it used in the world at
large?  I suspect not.

Tom Petch
</tp>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 7 Aug 2012 13:58:13 +0300

On Aug 7, 2012, at 11:29 AM, t.p. wrote:
> top right hand corner.  However, I cannot click on that,

No, but two lines above it, there's an "Errata" link, which you can click.

> unlike the

Probably not, and neither is "bis". But what can you do about this?  It's either allow updating of RFCs after publication, or have a list or corrections. Would it make it easier to find if they were called "notes" or "corrections" instead of "errata"?

Yoav

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 07 Aug 2012 04:12:36 -0700

On Fri 03/Aug/2012 08:38:44 -0700 Barry Leiba wrote:
> 
>> "Easy" would mean that people usually find them even if they're
>> not purposely looking for them.  For example, the existence of an
>> approved errata could be signaled by coloring the margin near the
>> relevant text.
> 
> I like this idea.  Not colour, maybe -- despite the errata tool's
> format, not all errata nicely fit into OLD/NEW text, and one often
> needs the explanation even for those that do -- but perhaps an
> "errata" icon in the margin next to the relevant text.  One could
> click the icon and be sent straight to that erratum.
> 
> The trouble is that I can't see how we could do that automatically, so
> it would require significant extra manual processing.

Yes, it would be part of a verifier's job.  E.g. an additional field
in the verification form.  Empty field, no icon.  Otherwise, the field
contains an anchor, a section number, or whatever pointer the form
handler may accept.

---

From: t.p. <[email-masked]>
Date: Tue, 7 Aug 2012 14:20:35 +0100

----- Original Message -----
From: "Yoav Nir" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: "Alessandro Vesely" <[email-masked]>; <[email-masked]>
Sent: Tuesday, August 07, 2012 11:58 AM
> top right hand corner.  However, I cannot click on that,

No, but two lines above it, there's an "Errata" link, which you can
click.

> standards, and so is a commonplace, but is it used in the world at

Probably not, and neither is "bis". But what can you do about this?
It's either allow updating of RFCs after publication, or have a list or
corrections. Would it make it easier to find if they were called "notes"
or "corrections" instead of "errata"?

<tp>
Yes, corrections is what I see published in a newspaper to correct
errata in previous editions.  So far, it is the best word I can think of
(but there might be a better one:-).

In the html version of an RFC, it would be easy to provide old and new
in an easy to compare format (as some editors do for I-D), not perhaps
on permanent display but shown when 'errata' (or whatever name we
choose) is toggled.

Tom Petch
</tp>

Yoav

---

From: Alessandro Vesely <[email-masked]>
Date: Wed, 08 Aug 2012 19:09:06 +0200

On Tue 07/Aug/2012 15:20:35 +0200 t.p. wrote:
>> Would it make it easier to find if they were called "notes" or
>> "corrections" instead of "errata"?
>
> errata in previous editions.  So far, it is the best word I can
> think of (but there might be a better one:-).

Errata is an abbreviation of "errata corrige", the Latin for "error
correction".  Switching to the English translation would seem to be
consistent with English being the official publication language for RFCs.

> on permanent display but shown when 'errata' (or whatever name we

Although easy, doing that would require a noticeable amount of
editorial work.  In addition, notes, reasons, and explanations don't
have an obvious graphical rendition.  IMHO, knowing when and why an
errata was proposed and verified is an integral part of it.

---

From: t.p. <[email-masked]>
Date: Thu, 9 Aug 2012 09:07:54 +0100

----- Original Message -----
From: "Alessandro Vesely" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, August 08, 2012 6:09 PM
> errata was proposed and verified is an integral part of it.

Well, start simple and build on it, something the tools team have a
history of doing:-)

First, have only the one highlighted 'corrections made' field on the
html page.

Second, add a new link to a 'corrections help' page telling the viewer
that once issued, a RFC is never changed, that any changes require a
fresh RFC that updates or supersedes the original one (pointing to the
highlighted fields in the top right hand example, perhaps with a worked
example - but not SMTP:-( but that there is an 'erratum' mechanism for
correcting editorial errors or places where the text is or may not be
clear about the intentions of the editors; and that such errata can be
viewed by clicking on the 'corrections made' field.

Finally, change the 'corrections made' to a 'hide corrections/view
corrections' toggle, default the first setting, the second setting
showing OLD/NEW text, old recognisably different eg struck through, with
a link to the RFC Editor page for the erratum; this is only done for
errata that are accepted.  Yes, there would be some intricate errata
that this would not cover, but the screens you get currently by
following the link to the RFC Editor page are so arcane as to switch off
all but those intimately involved in this standards process.

Tom Petch

---

From: Dave Cridland <[email-masked]>
Date: Thu, 9 Aug 2012 09:27:50 +0100

Does anyone other than historians honestly care what the original was? I
mean, really?

Dave.

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Aug 2012 07:00:44 -0400

--On Thursday, August 09, 2012 09:27 +0100 Dave Cridland
<[email-masked]> wrote:

> Does anyone other than historians honestly care what the
> original was? I mean, really?

Dave,

RFCs are often incorporated by reference in procurement
documents and conformity requirements.  If one were trying to
interpret or enforce such a requirement, it would almost
certainly be useful to know _exactly_ what version of an RFC and
its interpretations was agreed to.

   john

---

From: Dave Cridland <[email-masked]>
Date: Thu, 9 Aug 2012 12:35:41 +0100

It seems entirely reasonable that there needs to be a version available
that's precisely as-published, for legal (and quasi-legal) reasons, as you
say - however, that's the version produced by the RFC Editor, and not the
tools version (which is already non-normative, technically, due to the
markup).

What I'm driving at is whether the right way to handle errata is by
changing the document on tools (perhaps by diff submission). This should
reduce the mechanical workload of errata handling to near-zero, and leave
the judgement calls of whether to accept them as the cost.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Aug 2012 14:53:12 +0300

On Aug 9, 2012, at 2:35 PM, Dave Cridland wrote:

It seems entirely reasonable that there needs to be a version available that's precisely as-published, for legal (and quasi-legal) reasons, as you say - however, that's the version produced by the RFC Editor, and not the tools version (which is already non-normative, technically, due to the markup).

What I'm driving at is whether the right way to handle errata is by changing the document on tools (perhaps by diff submission). This should reduce the mechanical workload of errata handling to near-zero, and leave the judgement calls of whether to accept them as the cost.

This means that there would be two documents with the same RFC number. The quasi-leagal "as published" one, and the one of the tools site. Which should I follow when I go to implement?

If the errors amount to something that would really make a difference in implementation, you really need a new RFC, and can't handle this in an erratum.

See for example RFC 4753. The erratum changed bits on the wire, so a replacement RFC (5903) had to be published.

RFC 5903 also has two errata, which were rejected. But they are editorial, so even had they been accepted, they would not require a new RFC.

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Aug 2012 08:34:12 -0400

--On Thursday, August 09, 2012 14:53 +0300 Yoav Nir
<[email-masked]> wrote:

> 
> This means that there would be two documents with the same RFC
> number. The quasi-leagal "as published" one, and the one of
> the tools site. Which should I follow when I go to implement?

Exactly

> If the errors amount to something that would really make a
> difference in implementation, you really need a new RFC, and
> can't handle this in an erratum.
> 
> See for example RFC 4753. The erratum changed bits on the
> wire, so a replacement RFC (5903) had to be published.

And, if I correctly understood it at the time, that is exactly
why the RFC Editor opposed the idea of formal errata for years.
If there were real, substantive, errors, a replacement RFC
should be published as soon as practical.  For anything else,
the most that was desirable would be a collected list of
comments and suggestions that could be considered if/when the
document was revised.

   john

---

From: Yoav Nir <[email-masked]>
Date: Thu, 9 Aug 2012 17:11:58 +0300

> comments and suggestions that could be considered if/when the

There are still the spelling mistakes and obvious errors. Take for example this one from RFC 5296:

   The EMSKname is in the username part of the NAI and is encoded in
   hexadecimal values.  The EMSKname is 64 bits in length and so the 
   username portion takes up 128 octets.

Encoding 64 bits in hex requires 16 octets, not 128. I think anyone implementing this would figure this out, but it is substantive. The RFC was being revised anyway, but do you think a replacement RFC would need to be published if that were not the case?

Yoav

---

From: John C Klensin <[email-masked]>
Date: Thu, 09 Aug 2012 10:59:27 -0400

--On Thursday, August 09, 2012 17:11 +0300 Yoav Nir
<[email-masked]> wrote:

>> why the RFC Editor opposed the idea of formal errata for
>> years. If there were real, substantive, errors, a replacement
>> RFC should be published as soon as practical.  For anything
>> else, the most that was desirable would be a collected list of
>    The EMSKname is in the username part of the NAI and is
> encoded in    hexadecimal values.  The EMSKname is 64 bits in
> length and so the     username portion takes up 128 octets.
> 
> Encoding 64 bits in hex requires 16 octets, not 128. I think
> anyone implementing this would figure this out, but it is
> substantive. The RFC was being revised anyway, but do you
> think a replacement RFC would need to be published if that
> were not the case?

Personal opinion:  I don't know about "need to be", but
replacing an RFC with an error of that type would be desirable
to avoid any possible misunderstanding, however unlikely.  IMO,
it would also be desirable to have some self-examination in the
community about why that error slipped past IETF Last Call, AD
reviews, and AUTH48).

   john

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 9 Aug 2012 12:45:21 -0400

> From: Dave Cridland [[email-masked]]
> 
> Does anyone other than historians honestly care what the original was?

Does anyone honestly care what last month's version of the source code was?

Dale

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 9 Aug 2012 17:20:51 +0000

Lawyers may, in both cases.
Stephan