headers
Frank Ellermann | 20 Jun 00:43

Errata

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
Permalink | Reply |
headers
Henrik Levkowetz | 20 Jun 23:24

Re: Errata

Hi Frank,

On 2008-06-20 00:43 Frank Ellermann said the following:
> Hi, the errata are not more in sync with the 
> reported errata, is that as it should be ?

No, it's not.  Investigating.

Thanks for the alert!

	Henrik
Permalink | Reply |
headers
Frank Ellermann | 21 Jun 05:48

Re: Errata

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
Permalink | Reply |
headers
Magnus Westerlund | 23 Jun 16:52
Favicon

Re: Errata

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

Frank Ellermann skrev:
> 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
> Tools-discuss <at> ietf.org
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 

--

--
(Continue reading)

Permalink | Reply |
headers
Frank Ellermann | 23 Jun 20:58

Re: Errata

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
(Continue reading)

Permalink | Reply |
headers
Magnus Westerlund | 24 Jun 11:26
Favicon

Re: Errata

Frank Ellermann skrev:
> 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.  

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.

> 
> 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
(Continue reading)

Permalink | Reply |
headers
Brian E Carpenter | 24 Jun 23:38

Re: Errata

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

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

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
Permalink | Reply |
headers
Frank Ellermann | 25 Jun 04:29

Re: Errata

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.
(Continue reading)

Permalink | Reply |

Gmane