Re: Should the RFC Editor publish an RFC in less than 2 months?
Harald Alvestrand <harald@alvestrand.no> Thu, 29 November 2007 06:51 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 1IxdFK-0004Jx-4z; Thu, 29 Nov 2007 01:51:38 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxdFI-0004JA-7S; Thu, 29 Nov 2007 01:51:36 -0500
Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxdFF-0008IO-Pz; Thu, 29 Nov 2007 01:51:36 -0500
Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id DFE042596D8; Thu, 29 Nov 2007 07:51:32 +0100 (CET)
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13961-07; Thu, 29 Nov 2007 07:51:27 +0100 (CET)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5412C2596D7; Thu, 29 Nov 2007 07:51:27 +0100 (CET)
Message-ID: <474E61A4.2000201@alvestrand.no>
Date: Thu, 29 Nov 2007 07:52:20 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Thunderbird 1.5.0.14pre (X11/20071023)
MIME-Version: 1.0
To: ietf@ietf.org
References: <E1IxTPt-0006r4-ST@ietf.org>
In-Reply-To: <E1IxTPt-0006r4-ST@ietf.org>
X-Enigmail-Version: 0.94.2.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at alvestrand.no
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15
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
IETF Chair skrev: > Dear IETF Community: > > Due to a lot of hard work, the RFC Editor is publishing approved > Internet-Drafts more quickly. Overall this is just what we want to > happen. However, I am concerned that the RFC Editor is might be getting > too quick. Anyone can appeal the approval of a document in the two months > following the approval. In the past, there was not any danger of the RFC > Editor publishing a document before this timer expired, and the only > documents that became RFCs in less than 60 days were the ones where the > IESG explicitly asked for expedited processing. The recent improvements > by the RFC Editor make it likely that all documents will be moving through > the publication process in less than two months. > My short reply: Bad idea. In my opinion, placing such a hold on documents is a triumph of process over sanity. We have already lost the opportunity to restrict the circulation of the text when we published the I-D, which anyone in the world can copy. So the further aggravation of having copies out there of a document with an RFC number that isn't in the index any more is, if it is a difference at all, an extremely marginal one. So the remedy of "making the text not published" is already unavailable. In that case, the only difference between "holding an approved document and then not publishing it" and "publishing an RFC and then withdrawing it" is that in the latter case, we're left with a permanent mark in our RFC Index saying "This RFC was withdrawn". (I know this option does not exist now, as Leslie pointed out. I have big problems seeing a situation where it would be appropriate, but if people really argue that we need it once we admit that we can't "unpublish" an I-D, we can change the rules.) If we err so egregriously as to end up in a situation where a retraction is the appropriate remedy (as opposed to the situation where we can publish another RFC saying "on further consideration, the idea we approved in RFC 6666 was stupid, and we regret doing it; it's now Historic"), having to live with the blame for such a mark "forever" is appropriate and just punishment. We're ALREADY in a no-hold situation in many cases; when someone appeals the decision on an appealed approval, we do NOT, in general, hold the publication of the RFC, even though we are not just afraid there'll be an appeal, we positively *know* that there is an appeal. The same thing applies for appeals against the RFC Editor/WG chair/author's decision to approve an AUTH48 change. Such a hold is a dumb idea, and we shouldn't do it. Just publish, and if we turn out to have made the wrong decision, make a public statement saying that; one form of public statement is leaving a hole in the RFC Index. (As to the ideas for further complexity in the process with "provisional" markers considered by Brian and John: My opinion is that they add cost, and in practice provide zero value. Just publish, and if needed, unlist.) Harald _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Should the RFC Editor publish an RFC in less than… IETF Chair
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- RE: Should the RFC Editor publish an RFC in less … Wassim Haddad
- Re: Should the RFC Editor publish an RFC in less … Ted Hardie
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … Leslie Daigle
- Re: Should the RFC Editor publish an RFC in less … Russ Housley
- Re: Should the RFC Editor publish an RFC in less … Cullen Jennings
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Re: Should the RFC Editor publish an RFC in less … Tim Polk
- Re: Should the RFC Editor publish an RFC in less … Paul Hoffman
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Re: Should the RFC Editor publish an RFC in less … Tom.Petch
- Re: Should the RFC Editor publish an RFC in less … Harald Alvestrand
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Norbert Bollow
- Re: Should the RFC Editor publish an RFC in less … Iljitsch van Beijnum
- Re: Should the RFC Editor publish an RFC in less … Eric Rescorla
- Re: Should the RFC Editor publish an RFC in less … Dave Crocker
- Re: Should the RFC Editor publish an RFC in less … Alexey Melnikov
- Re: Should the RFC Editor publish an RFC in less … Jari Arkko
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Paul Hoffman
- Re: Should the RFC Editor publish an RFC in less … Sam Hartman
- Re: Should the RFC Editor publish an RFC in less … Harald Alvestrand
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … Bob Hinden
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Spencer Dawkins
- Re: Should the RFC Editor publish an RFC in less … Magnus Westerlund
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Alexey Melnikov
- Re: Should the RFC Editor publish an RFC in less … Jari Arkko
- Re: Should the RFC Editor publish an RFC in less … Russ Housley
- Re: Should the RFC Editor publish an RFC in less … Bob Hinden
- Re: Should the RFC Editor publish an RFC in less … Harald Tveit Alvestrand
- Re: Should the RFC Editor publish an RFC in less … John C Klensin
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Bob Hinden
- Re: Should the RFC Editor publish an RFC in less … Lixia Zhang
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Iljitsch van Beijnum
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Hallam-Baker, Phillip
- Re: Should the RFC Editor publish an RFC in less … Robert Elz
- OOXML (was Re: Should the RFC Editor...) Norbert Bollow
- Re: Should the RFC Editor publish an RFC in less … Norbert Bollow
- Re: Should the RFC Editor publish an RFC in less … Tom.Petch
- Re: Should the RFC Editor publish an RFC in less … Daniel Brown
- Re: Should the RFC Editor publish an RFC in less … Brian E Carpenter
- Re: Should the RFC Editor publish an RFC in less … Harald Tveit Alvestrand
- Re: Should the RFC Editor publish an RFC in less … Scott O. Bradner
- Re: Should the RFC Editor publish an RFC in less … Robert Elz
- RE: Should the RFC Editor publish an RFC in less … Tobias Gondrom
- Re: Should the RFC Editor publish an RFC in less … Frank Ellermann
- Re: Should the RFC Editor publish an RFC in less … Henrik Levkowetz
- Re: Should the RFC Editor publish an RFC in less … Loa Andersson
- Re: Should the RFC Editor publish an RFC in less … JP Vasseur
- Re: Should the RFC Editor publish an RFC in less … Russ Housley