On 30/Jun/10 17:52, Jari Arkko wrote:
John [Klensin],
and I'm keenly aware of the fact that
errata, even "approved" errata, do not constitute community
consensus documents, but,
I am with you on that.
IMHO, this is a point that may be worth enhancing. From a functional
POV, it is not possible for users to vote, discuss, or subscribe to an
erratum, a feature that current bug tracking tools offer out of the box.
In addition, an errata status of, say, "implementation mismatch" is
missing. It could be used to report that (some versions of) an
implementation are not compliant on a specific detail. I'm not saying
the IETF should systematically track each and every implementation.
However, accepting non-compliance reports is a means to track how much
popularity specific parts of a protocol have gained.
From a user-interface POV, it is difficult to realize that errata
exist about a specific passage. For example, background color, margin
marks, or footnotes could be used to draw the reader's attention to
existing errata.
I do not believe the IESG is saying that everyone should be using errata
from now on. There is certainly some frustration in the community and
sometimes in some of my fellow ADs about the time it takes to produce an
RFC, and that does sometimes lead people to not bother with doing it,
relying on Internet drafts, errata, common sense, their own memories or
their code base to reflect what the true protocol behaviour should be. I
still think its better to publish RFCs. (And for the record, I do not
believe it is that hard.)
Collecting consensus on specific changes --unbound from any charter or
time-frame-- may help identifying which parts of which RFCs need a
revision.
JM2C
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf