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

[Abdussalam Baryun <[e-mail]>]

Hi Barry,

Could you refer to a RFC that states your below information or
procedure, if there is not, I recommend some one doing procedure
drafts to take it over. Please note that ALL reports from any
participant should be useful for IETF community and system. Even if
he/she misunderstood, this does not mean that he/she is not useful,
that means the IETF system/community needs to adjust to help
participants to understand and follow.

For me I will note your procedure so that I will not report wrongly,
but I will continue reporting my comments/views, and hope if some
thing is wrong I get a reply like your, thanking you,

AB
IETF Particpant
==================================================
The mission of the Internet Engineering Task Force is to make the
Internet work better by producing high-quality and relevant technical
documents that influence the way people design, use, and manage the
Internet.
==================================================

> 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.
>
>
> So I wanted to clarify what's meant to be reported, and what's not.
>
>
> A valid erratum, one that the IESG will mark as "Verified", mets two
> criteria:
>
>
> 1. It is truly an *error* in the original document.  That is, it would
> have been considered an error *at the time the document was
> published*, had it been noticed at the time.
>
>
> 2. It is important, an error that would cause someone to misread the
> document in a significant way, causing implementation or deployment
> problems, or other serious issues.
>
>
> Criterion 1 means that anything that is "wrong" because of situations
> or discussions that have come up since publication are not appropriate
> errata.  Consider the differences among these:
>
>
> - (a) Someone realizes that the document forgot to specify the valid
> range of a value.
>
>
> - (b) Someone realizes that the range specified did not correctly
> reflect the result of the discussion at the time (the change got
> missed and no one noticed).
>
>
> - (c) Someone realizes that the range specified causes problems in
> practice, but we didn't know that would happen when we published the
> document.
>
>
> (a) and (b) are valid errata, and should get marked as "Verified".
> (c) is NOT valid for the errata system, and really ought to be marked
> as "Rejected".
>
>
> Criterion 2 means that minor typos are NOT appropriate errata.  The
> IESG will mark these as "Held for Document Update", but, really, there
> is no need to say that "an" should be "and", that a comma is missing
> (unless it seriously affects the meaning and is likely to be
> mis-read), or that "concensus" is misspelled (as here).  Again,
> consider the differences:
>
>
> - (a) "The server will now respond with an error code," where "now"
> should have been "not".
>
>
> - (b) "The server will not repond with an error code," where "repond"
> should have been "respond".
>
>
> - (c) "The server will not respond with and error code," where "and"
> should have been "an".
>
>
> (a) is the only valid one here.  There's no real value in recording
> the others as errata.
>
>
> 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.
>
>
> Barry, Applications AD
>