Hi,
I read this document. On a quick read, this seemed very reasonable.
David Harrington
dbharrington(_at_)comcast(_dot_)net
ietfdbh(_at_)comcast(_dot_)net
dharrington(_at_)huawei(_dot_)com
-----Original Message-----
From: ietf-announce-bounces(_at_)ietf(_dot_)org
[mailto:ietf-announce-bounces(_at_)ietf(_dot_)org] On Behalf Of The IESG
Sent: Wednesday, April 16, 2008 8:17 AM
To: IETF Announcement list
Cc: iaoc(_at_)ietf(_dot_)org; iab(_at_)iab(_dot_)org;
iesg(_at_)ietf(_dot_)org;
rfc-editor(_at_)rfc-editor(_dot_)org
Subject: Proposed IESG Statement Regarding RFC Errata for
IETF Sream RFCs
The IESG is considering the following statement to guide the
handling of
RFC Errata for IETF Stream RFCs. Your review and comment on
this policy
is encouraged.
Russ Housley
on Behalf of the IESG
- - - - - - - - - - - -
Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
These are strong guidelines and not immutable rules. Common
sense
and good judgment should be used by the IESG to decide what is
the
right thing to do. Errata are meant to fix "bugs" in the
specification and should not be used to change what the community
meant when it approved the RFC. These guidelines only apply to
errata on RFCs in the IETF stream. They apply to new errata and
not errata that had already been approved.
After an erratum is reported, a report will be sent to the
authors and
Area Directors (ADs) of the WG in which it originated. If
the WG has
closed or the document was not associated with a WG, then the
report will be sent to the ADs for the Area most closely
associated
to the subject matter. The ADs for the area will review it,
either
themselves or by delegating, and classify it as falling under
one of the following states:
o Approved - The errata is appropriate under the criteria
below and
should be available to implementors or people deploying the
RFC.
o Rejected - The errata is in error, or proposes a change
to the RFC
that is clearly inappropriate to do with an errata. In
the latter
case, if the change is to be considered for future
updates of the
document, it should be proposed using other channels
than errata,
such as a WG mailing list.
o Archived - The errata is not a necessary update to the RFC.
However, any future update of the document should consider
this
errata, and determine whether it is correct and merits
including
in the update.
Guidelines for review are:
1. Only errors that could cause implementation or deployment
problems or significant confusion should be Approved.
2. Things that are clearly wrong but could not cause an
implementation or deployment problem should be Archived.
3. Errata on obsolete RFCs should treated the same as errata on
non-obsolete RFC where there is strong evidence that some
people are still making use of the related technology.
4. Trivial grammar corrections should be Archived.
5. Ugly typos that are clearly bogus typos but would not cause
any
confusions to implementation or deployments should be
Archived.
6. Changes which are simply stylistic issues or simply make
things
read better should be Archived.
7. Changes that modified the working of a protocol to
something that
might be different from the intended consensus when
the document
was approved should be either Archived or Rejected. Deciding
between these two depends on judgment. Changes that are
clearly
modifications to the intended consensus, or are of major
importance, should be Rejected. In unclear situations, small
changes can be Archived.
8. Changes that modify the working of a process, such as
changing
an IANA registration procedure, to something that might be
different from the intended consensus when the document was
approved should be Archived.
_______________________________________________
IETF-Announce mailing list
IETF-Announce(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-announce
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf