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 >
