RE: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs

"David Harrington" <ietfdbh@comcast.net> Fri, 18 April 2008 15:15 UTC

Return-Path: <ietf-announce-bounces@ietf.org>
X-Original-To: ietf-announce-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-announce-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F4823A702F; Fri, 18 Apr 2008 08:15:48 -0700 (PDT)
X-Original-To: ietf-announce@core3.amsl.com
Delivered-To: ietf-announce@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 691F228C530 for <ietf-announce@core3.amsl.com>; Thu, 17 Apr 2008 09:39:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.16
X-Spam-Level:
X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[AWL=0.439, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZovimClEvnA for <ietf-announce@core3.amsl.com>; Thu, 17 Apr 2008 09:39:16 -0700 (PDT)
Received: from QMTA08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id DFA3828C518 for <ietf-announce@ietf.org>; Thu, 17 Apr 2008 09:39:15 -0700 (PDT)
Received: from OMTA14.westchester.pa.mail.comcast.net ([76.96.62.60]) by QMTA08.westchester.pa.mail.comcast.net with comcast id EfR61Z0011HzFnQ5805b00; Thu, 17 Apr 2008 16:38:39 +0000
Received: from Harrington73653 ([24.128.66.199]) by OMTA14.westchester.pa.mail.comcast.net with comcast id Egfd1Z0054HwxpC3a00200; Thu, 17 Apr 2008 16:39:51 +0000
X-Authority-Analysis: v=1.0 c=1 a=ERyaEZiE3-0A:10 a=jOOrUSkyzfwA:10 a=48vgC7mUAAAA:8 a=1Omil-5G8MORAIOkUBYA:9 a=TvYHXMxqDTqUjZWsgMIA:7 a=aHOSTePk5uSfagCztxlaIpyjQLoA:4 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=lZB815dzVvQA:10 a=M1DkEnbHmpQA:10 a=1eQkaoUQ5BgA:10 a=50e4U0PicR4A:10
From: David Harrington <ietfdbh@comcast.net>
To: ietf@ietf.org, iesg@ietf.org, 'IETF Announcement list' <ietf-announce@ietf.org>
References: <20080416151659.F075C3A6C0B@core3.amsl.com>
Subject: RE: Proposed IESG Statement Regarding RFC Errata for IETF Sream RFCs
Date: Thu, 17 Apr 2008 09:39:35 -0700
Message-ID: <000c01c8a0a9$a10e1130$0600a8c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
Thread-Index: Acif1Qyzzk4fe9eGRd6a6BkdHqBWFwAO2EFw
In-Reply-To: <20080416151659.F075C3A6C0B@core3.amsl.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
X-Mailman-Approved-At: Fri, 18 Apr 2008 08:15:38 -0700
Cc: iaoc@ietf.org, iab@iab.org, rfc-editor@rfc-editor.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Announcements <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org

Hi,

I read this document. On a quick read, this seemed very reasonable.

David Harrington
dbharrington@comcast.net
ietfdbh@comcast.net
dharrington@huawei.com


> -----Original Message-----
> From: ietf-announce-bounces@ietf.org 
> [mailto:ietf-announce-bounces@ietf.org] On Behalf Of The IESG
> Sent: Wednesday, April 16, 2008 8:17 AM
> To: IETF Announcement list
> Cc: iaoc@ietf.org; iab@iab.org; iesg@ietf.org; 
> rfc-editor@rfc-editor.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@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 


_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce