Stripping out a raft of cc:s, a nit and a comment in line.
On Apr 16, 2008, at 11:16 AM, The IESG wrote:
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
I would suggest
s/modified/modify/
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.
I don't know about this - strip out the "or" clause and you get
Changes that ... are of major importance, should be Rejected.
Are you intending to say that only unimportant errata will be accepted ?
Regards
Marshall
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 mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf