Re: Should the RFC Editor publish an RFC in less than 2 months?

Eric Rescorla <ekr@networkresonance.com> Wed, 28 November 2007 21:19 UTC

Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUJa-0000rt-8k; Wed, 28 Nov 2007 16:19:26 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUJY-0000qB-Du; Wed, 28 Nov 2007 16:19:24 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxUJX-0007FM-Uq; Wed, 28 Nov 2007 16:19:24 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id E3C3533C57; Wed, 28 Nov 2007 13:14:12 -0800 (PST)
Date: Wed, 28 Nov 2007 13:14:12 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <474DD597.9040208@gmail.com>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071128211412.E3C3533C57@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: iab@ietf.org, ietf@ietf.org, iesg@ietf.org
Subject: Re: Should the RFC Editor publish an RFC in less than 2 months?
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

At Thu, 29 Nov 2007 09:54:47 +1300,
Brian E Carpenter wrote:
> 
> On 2007-11-29 09:21, IETF Chair wrote:
> ...
> > If we receive an appeal before the RFC is published, we can put a hold on
> > the document, preventing pblication until the appeal has been studied. 
> > However, we have no way to pull an RFC back if it is published before the
> > appeal arrives.  As we all know, once an RFC is published, it cannot be
> > changed.  Thus, the RFCs form an archival series.  If we find a bug in an
> > RFC, we write a revised RFC that obsoletes the one that contains the
> > error.  So, what should we do if there is a successful appeal after the
> > RFC is published?
> 
> I thought about this a bit when the RFC Editor started to catch up and
> accelerate; it's excellent news that it's no longer a theoretical
> question, so kudos to the Editor team (and IANA, who also have a role
> to play in getting many RFCs out).
> 
> My conclusion is that the number of appeals is relatively low. I'd hate
> for the low risk of having to roll back an approval to slow down all
> publications. So my personal preference is to not hold up publication
> (unless there is good reason to expect an appeal), but to add a new
> RFC status, let's call it PROVISIONAL for the sake of argument, that
> would be applied if an appeal is received within the 2 month window
> but after publication. If the appeal succeeds, the status can be
> changed as appropriate (likely to HISTORIC), and if the appeal fails
> it can revert to its original value.

So, obviously it's important not conflate statements about what the
rules *should* say with what they *do say*, but with that in mind, my
reading of 2026 is that this isn't necessarily sufficient. Here's
the relevant passage:

S 6.5.2.
   If circumstances warrant, the IAB may direct that an IESG decision be
   annulled, and the situation shall then be as it was before the IESG
   decision was taken. The IAB may also recommend an action to the IESG,
   or make such other recommendations as it deems fit. The IAB may not,
   however, pre-empt the role of the IESG by issuing a decision which
   only the IESG is empowered to make.

It seems to me that the situation of an existing RFC marked HISTORIC
is pretty different from that of no RFC existing at all, so what
ISTM that what you propose would require a change to 2026.

-Ekr





_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf