Re: [rfc-i] Fwd: Re: Old Errata

"HANSEN, TONY L" <tony@att.com> Wed, 14 September 2016 15:23 UTC

Return-Path: <rfc-interest-bounces@rfc-editor.org>
X-Original-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Delivered-To: ietfarch-rfc-interest-archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA55E12B3B0 for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Wed, 14 Sep 2016 08:23:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.128
X-Spam-Level:
X-Spam-Status: No, score=-4.128 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJY_J6v5Q1dq for <ietfarch-rfc-interest-archive@ietfa.amsl.com>; Wed, 14 Sep 2016 08:23:09 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D8812B3A8 for <rfc-interest-archive-eekabaiReiB1@ietf.org>; Wed, 14 Sep 2016 07:48:28 -0700 (PDT)
Received: from rfcpa.amsl.com (localhost [IPv6:::1]) by rfc-editor.org (Postfix) with ESMTP id D2C4DB81ED0; Wed, 14 Sep 2016 07:48:27 -0700 (PDT)
X-Original-To: rfc-interest@rfc-editor.org
Delivered-To: rfc-interest@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id AF1BFB81ED0 for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 07:48:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYYxrAcJXz2d for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 07:48:23 -0700 (PDT)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) by rfc-editor.org (Postfix) with ESMTPS id C7DC8B81ECE for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 07:48:23 -0700 (PDT)
Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id u8EEZLwA016035 for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 10:48:23 -0400
Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049458.ppops.net-00191d01. with ESMTP id 25f78090kv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 10:48:19 -0400
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8EEmInE023961 for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 10:48:19 -0400
Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id u8EEm7m7023613 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 10:48:13 -0400
Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor) for <rfc-interest@rfc-editor.org>; Wed, 14 Sep 2016 14:19:44 GMT
Received: from MISOUT7MSGUSRCG.ITServices.sbc.com ([169.254.7.113]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0301.000; Wed, 14 Sep 2016 10:19:24 -0400
From: "HANSEN, TONY L" <tony@att.com>
To: RFC Interest <rfc-interest@rfc-editor.org>
Thread-Topic: [rfc-i] Fwd: Re: Old Errata
Thread-Index: AQHSDfWJ3px8Sk/IcUShUdfINvbIUaB5ApsA
Date: Wed, 14 Sep 2016 14:19:23 +0000
Message-ID: <B7463EFF-2EC7-4E39-B2A8-039BD440A1D0@att.com>
References: <9AB5C86B88A8BFFABA4297BA@JcK-HP8200> <4234fdff-9728-c2b2-fc1e-2c360b73288f@gmail.com> <etPan.57d85434.32ad7e60.8438@rfc-editor.org>
In-Reply-To: <etPan.57d85434.32ad7e60.8438@rfc-editor.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.188.226.24]
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-14_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609140200
Subject: Re: [rfc-i] Fwd: Re: Old Errata
X-BeenThere: rfc-interest@rfc-editor.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "A list for discussion of the RFC series and RFC Editor functions." <rfc-interest.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/rfc-interest/>
List-Post: <mailto:rfc-interest@rfc-editor.org>
List-Help: <mailto:rfc-interest-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/rfc-interest>, <mailto:rfc-interest-request@rfc-editor.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============6048820038623745960=="
Errors-To: rfc-interest-bounces@rfc-editor.org
Sender: "rfc-interest" <rfc-interest-bounces@rfc-editor.org>

One problem I see is that there’s essentially only a single ping to the IESG or RFC Editor, with no subsequent follow up. Things get stale when that initial ping gets lost or ignored. This might be an action item for the RFC Editor to enhance the pinging mechanism.

I’m really glad that the editorial errata are now being taken care of by the RFC Editor; having the IESG spend time on those always troubled me.

For the older Errata regarding RFCs that have become obsolete, an “overtaken by other events” might be an appropriate response.

However, for still active protocol RFCs, someone trying to implement the protocol really would be served by having responses. Is an erratum saying that “an ABNF production is wrong” correct or not? Right now, the developer will be forced to make a decision that may or may not be proper.

I’m not saying that it is the IESG that has to make these determinations – delegation of responsibility can be a useful tool, after all.

                Tony

From: rfc-interest <rfc-interest-bounces@rfc-editor.org> on behalf of Heather Flanagan <rse@rfc-editor.org>
Date: Tuesday, September 13, 2016 at 3:32 PM
To: RFC Interest <rfc-interest@rfc-editor.org>rg>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: [rfc-i] Fwd: Re: Old Errata

In terms of how having unhandled errata reflect on the reputation of the RFC Series, yes, this is an RFC Editor issue. That said, we do not have the necessary information to make the necessary judgements on technical errata. That must come from the authors, the WGs, or the stream approving bodies as appropriate. The RFC Editor does take responsibility for the editorial errata; that’s a relatively recent change in the last two years or so.

As for the old Legacy RFCs, those now have pointers to either the specific groups as requested by the IESG or the IESG as a whole on their info pages.

On September 12, 2016 at 12:58:21 PM, Brian E Carpenter (brian.e.carpenter@gmail.com<mailto:brian.e.carpenter@gmail.com>) wrote:
So, I don't want to upset the IETF list, but it seems to me that unhandled errata
should be primarily an RFC Editor issue, not an IETF issue, even if most of them
need to be resolved by the IETF stream.

Certainly the backlog is a Bad Thing, but I agree with John's final comment
below.

(The large number of RFCs in status Unknown is a similar problem to which John's
comment also applies.)

-------- Forwarded Message --------
From: John C Klensin <john-ietf@jck.com>

Part of the point is that our Status and Type categories are
really not up to the job (something that has been discussed
extensively in the past with, AFAIK, no resolution). Given the
current categories, just leaving some documents in "Reported"
forever might be the right disposition. If we are going to use
errata to make minor technical changes, then we probably should
have a Status of "Sure, but there needs to be another way to
notify people about this issue", maybe with an appropriate
Action number in that tracker. It is also tempting to suggest
that the "Type" for this kind of erratum should be "smells of
dead fish": certainly it is not "Editorial" because the RFC was
absolutely correct --technically, operationally, and
editorially-- when written.

Seems to me that just keeping an alias or link until a few years
after the relevant RFC becomes obsolete would be a lot less
trouble.

I doubt this is the only case -- the errata filing system
doesn't have a great track record for S/N ratio and I, at least,
would much prefer to have ADs paying attention to WGs and
processing of current documents rather than studying the errata
files looking for loose ends.

john

_______________________________________________
rfc-interest mailing list
rfc-interest@rfc-editor.org
https://www.rfc-editor.org/mailman/listinfo/rfc-interest