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

Paul Hoffman <paul.hoffman@vpnc.org> Wed, 28 November 2007 23: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 1IxWBs-0001m1-Ux; Wed, 28 Nov 2007 18:19:36 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWBp-0001gP-Ah; Wed, 28 Nov 2007 18:19:33 -0500
Received: from balder-227.proper.com ([192.245.12.227]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxWBo-0005Ld-Un; Wed, 28 Nov 2007 18:19:33 -0500
Received: from [10.20.30.108] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id lASNJUxr084704 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Nov 2007 16:19:31 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
Mime-Version: 1.0
Message-Id: <p0624081fc373a6b5e8fb@[10.20.30.108]>
In-Reply-To: <E1IxTPt-0006r4-ST@ietf.org>
References: <E1IxTPt-0006r4-ST@ietf.org>
Date: Wed, 28 Nov 2007 15:18:34 -0800
To: ietf@ietf.org
From: Paul Hoffman <paul.hoffman@vpnc.org>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: iab@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

One easy solution to the problem is to not change anything in the 
current IETF or RFC rules. If an RFC has been published before the 
appeal is brought, and that appeal is ultimately successful, a new 
RFC is issued that obsoletes the old RFC. That new RFC can 
essentially be a NULL, although hopefully it would have an 
explanation why an empty RFC is obsoleting a non-empty one. That new 
RFC can also be partially populated; for example, if the resolution 
of the appeal is to pull a contentious section or appendix.

Given the extreme rarity of the situation where an appeal leads to 
non-publication or changed publication, it seems wasteful to create 
new rules (and spend lots of time arguing about them) when no new 
rules are needed.

--Paul Hoffman, Director
--VPN Consortium

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