Subject: [Tools-discuss] Errata

From: "Frank Ellermann" <[email-masked]>
Date: Fri, 20 Jun 2008 00:43:23 +0200

Hi, the errata are not more in sync with the 
reported errata, is that as it should be ?

Examples:
<http://tools.ietf.org/html/rfc3092>, no link to
http://rfc-editor.org/errata_search.php?rfc=3092

<http://tools.ietf.org/html/rfc3406>, no link to
http://rfc-editor.org/errata_search.php?rfc=3406

 Frank

_______________________________________________
Tools-discuss mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tools-discuss

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 20 Jun 2008 23:24:56 +0200

Hi Frank,

> reported errata, is that as it should be ?

No, it's not.  Investigating.

Thanks for the alert!

	Henrik

---

From: "Frank Ellermann" <[email-masked]>
Date: Sat, 21 Jun 2008 05:48:58 +0200

Henrik Levkowetz wrote:
 
> Investigating.

Thanks.  On the rfc-interest list I've reported another nit:
<http://permalink.gmane.org/gmane.ietf.rfc.interest/256>

In that case an erratum was updated / replaced by another
erratum three months ago, but the original reporter (me)
got no info about it.  This affects one PS which can be
still fixed in AUTH48 (in theory time critical), RFC 4408
with its own outsourced errata, work on IDNAbis, and the
2606bis draft (fixed version posted minutes ago).

IOW it would be nice if folks can track any changes of 
errata for published RFC.  On the rfc-interest list I
mentioned "bugzilla", but actually that is overkill, and
besides I'd consider it as excessively hostile to users.

Another idea would be an atom feed for RFCs tracking the
errata, and maybe later also all drafts referencing it.
Is that idea fairly trivial to implement on this side ?

 Frank

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 23 Jun 2008 16:52:56 +0200

Hi,

Are you certain that it really should list these non confirmed ones? I 
actually think not. I do hope we (IESG) will be able to soon get on 
approving the erratas in a meaningful way.

Cheers

Magnus

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Frank Ellermann" <[email-masked]>
Date: Mon, 23 Jun 2008 20:58:48 +0200

Magnus Westerlund wrote:

> Are you certain that it really should list these non confirmed ones?

Absolutely.  It was excessively annoying when a simple missing comma
in RFC 2045 reported by the author needed more than two years to show
up as reported.  It is still unverified, after three years and four
months.  

For technical errata about say the RFC 2069, 2938, or 4122 examples
it is very important to have them published as soon as possible for
implementors - they will be able to judge if an unverified erratum
misses the point.  They might even update it, a rather interesting
case is certainly Errata ID 1081 updated by 1335.  It already made
it into a 2606bis draft, and I'm tempted to move it to the normative
references - replacing RFC 1123, as the only reason that this RFC
is mentioned at all is to get an indirect pointer to this erratum.

Other interesting cases are the outsourced RFC 2616 and 4408 errata,
and I have a good idea how long (measured in months if not years)
it can take to verify non-trivial errata.  Or to get consensus for
non-obvious fixes when different developers interpreted an obscure
corner case in RFC 4408 differently.  But at least they agreed that
something needed fixing - having that on public record was already
a Good Thing.  

> I do hope we (IESG) will be able to soon get on approving the 
> erratas in a meaningful way.

With the given backlog I don't expect any results before 2010.  And
I don't see how you can guarantee a decent turnaround time in 2010,
like say 100 days.

It is just wrong when the RFC 2069 erratum reported isn't shown by
the Tools server anymore, it was reported three years and four 
months ago.  Two years it was hidden in a 1 MB pending errata mbox,
after that it finally showed up.  Hiding it *again* in an IESG list
archive for years would be very bad.

The IETF Tools server is supposed to mirror the important meta data
for RFCs, if it doesn't do this it is worthless for my purposes of
setting links, I'd be forced to use [[purlnet:rfc/2069|RFC 2069]]
or similar.

Maybe invent a "dispute" procedure to remove controversial errata 
from the picture temporarily - admittedly the errata report system
needs a better protection than "e-mail field can't be empty".

 Frank

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 24 Jun 2008 11:26:27 +0200

> up as reported.  It is still unverified, after three years and four

As you may be aware IESG has been working on a statement on how Errata 
for IETF document stream is going to be handled. If not the proposal 
that has been announced for comments where this:

http://www.ietf.org/mail-archive/web/ietf-announce/current/msg04742.html

We are still editing on this but it should be ready pretty soon for 
announcement.

Part of this is that we will not classify most editorial as being worth 
being seen.

> is mentioned at all is to get an indirect pointer to this erratum.

What about the ones that are wrong? We have seen quite a few of these 
erratas filed also. Some quite subtle.

> something needed fixing - having that on public record was already

Yes, and in many cases approving an errata is not the way to fix the 
issue because it actually requires a consensus decision. Thus a updated 
specification is the appropriate way of moving forward.

> I don't see how you can guarantee a decent turnaround time in 2010,

We never can guarantee anything but I think once we have the tool 
support in place we can deliver them in reasonable time. But, I have 
little hope that we will be able to do much until we have a reasonable 
tool to work with. The current system that requires us to use cut and 
past into emails are not working. It is also important that ADs can 
delegate this properly.

> archive for years would be very bad.

For clarity, errata processing will not go to the IESG list.

> setting links, I'd be forced to use [[purlnet:rfc/2069|RFC 2069]]

I agree that the tools servers should contain the important data. 
However, if non processed erratas are important or not is unknown. That 
is the core of the problem from my perspective. Until some human has 
looked at it to confirm it or dispute it we don't know what importance 
that data has.

> needs a better protection than "e-mail field can't be empty".

Well, we have this problem with Erratas that they are trying to change 
something that is supposed to be immutable. That doesn't make this 
process easy.

Cheers

Magnus Westerlund

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 25 Jun 2008 09:38:22 +1200

On 2008-06-24 21:26, Magnus Westerlund wrote:
...

> Part of this is that we will not classify most editorial as being worth

Please don't forget that sometimes a single misplaced comma
can change the technical meaning. I'm not sure that completely
hiding editorial and typographical errata is wise.

    Brian

---

From: "Frank Ellermann" <[email-masked]>
Date: Wed, 25 Jun 2008 04:29:22 +0200

Magnus Westerlund wrong:

> Part of this is that we will not classify most editorial as being
> worth being seen.

As noted by Brian, don't take the classification of a reported
erratum as "editorial" for "waste of our time".  The *critical*
RFC 1123 errata are "editorial" in nature, as they are about a
presumably informative note in RFC 1123.  And as long as no IDN
TLDs exist they also have no immediate consequences whatsoever.  

But as long as they are not approved any future IDN TLD would 
violate STD 3, that might come as a surprise to say lawyers ;-)

> What about the ones that are wrong?

Reject.

> We have seen quite a few of these erratas filed also. Some
> quite subtle.

That is why there is an "unverified" state.  IMO readers are
supposed to judge for themselves if an "unverified" erratum
makes sense.  Clearly there should be ways to reject obvious
nonsense, e.g., on request by anybody finding it.

> in many cases approving an errata is not the way to fix the
> issue because it actually requires a consensus decision.
> Thus a updated specification is the appropriate way of
> moving forward.

Apparently your "archived" state covers this situation.  

But I'm not sure why you split "verified" in "archived" and
"approved" at all.  What to do with a "verified" erratum is
a completely different question.  For an old RFC it might be
the last word.  For an active RFC it might block promotion
on standards track without first fixing the erratum.  For an
implementor it might help, hopefully.  For the RFC-editor it
will help them to improve their editorial work.

> For clarity, errata processing will not go to the IESG list.

With the errata report system as it was some days ago a copy
was sent to the IESG list, that was what I meant.  Of course
you'd need some way to forward it to areas / WGs (where a WG
still exists, e.g., the RFC 4646 erratum.  I could produce a
consenting LTRU co-Chair, but that would be cheating.  The
system has to work for folks not knowing what "IETF" means.)

> However, if non processed erratas are important or not is
> unknown. That is the core of the problem from my perspective.
> Until some human has looked at it to confirm it or dispute
> it we don't know what importance that data has.

Yes, but hiding reported errata isn't a plausible plan to get 
a human to look at it.  Besides not only ADs are humans... :-)

>> the errata report system needs a better protection than
>> "e-mail field can't be empty".

> Well, we have this problem with Erratas that they are trying
> to change something that is supposed to be immutable. That
> doesn't make this process easy.

ACK.  Did somebody already try to pull this stunt, apart from
the known RFC 1123 TLD case ?  

 Frank