Re: Should the RFC Editor publish an RFC in less than 2 months?
Robert Elz <kre@munnari.OZ.AU> Mon, 03 December 2007 09:52 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 1Iz7yh-0006Ho-CU; Mon, 03 Dec 2007 04:52:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iz7yd-0005kO-Vi; Mon, 03 Dec 2007 04:52:35 -0500
Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iz7yW-00036Y-I2; Mon, 03 Dec 2007 04:52:35 -0500
Received: from delta.noi.kre.to (delta-41 [172.30.3.41]) by jade.coe.psu.ac.th with ESMTP id lB39oXPP025304; Mon, 3 Dec 2007 16:50:50 +0700 (ICT)
Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.noi.kre.to (8.12.11/8.11.6) with ESMTP id lB39nfeg023465; Mon, 3 Dec 2007 16:49:42 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: "Hallam-Baker, Phillip" <pbaker@verisign.com>
In-Reply-To: <2788466ED3E31C418E9ACC5C316615570462D9@mou1wnexmb09.vcorp.ad.vrsn.com>
References: <2788466ED3E31C418E9ACC5C316615570462D9@mou1wnexmb09.vcorp.ad.vrsn.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Mon, 03 Dec 2007 16:49:41 +0700
Message-ID: <24721.1196675381@munnari.OZ.AU>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: iab@ietf.org, Alexey Melnikov <alexey.melnikov@isode.com>, 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
Date: Sun, 2 Dec 2007 17:34:14 -0800 From: "Hallam-Baker, Phillip" <pbaker@verisign.com> Message-ID: <2788466ED3E31C418E9ACC5C316615570462D9@mou1wnexmb09.vcorp.ad.vrsn.com> | Only issue I would raise here is don't expire the ID if this situation | arises... That did not really need to be said - once submitted for IESG action, I-Ds go into a limbo state where they hand around until something happens, either the IESG rejects them, or the RFC is published, during that interval (however long it is, and it has been many years in a few extreme cases) the I-D simply remains available for reference. That, and that the RFC editor allocates the RFC number as one if its first actions after receiving approval to publish (I believe) has led me to read this entire discussion with something bordering on incredulity. Everyone (almost everyone) seems to be assuming that getting the RFC published as quickly as possible is the aim. Why? What does actual appearance of the file in the directories really change? Sure, it makes access a little easier, but that's it (and I guess that now, we could have a temporary placeholder installed, a file called rfcNNNN.2b or something, containing the URL of the I-D that will become the RFC when the editing process is finished - I personally doubt it is necessary, but it could be done). Certainly having the RFC editor reduce the publication delays is a laudable goal, if it RFCs are getting published at a rate slower than the IETF is producing them (over a lengthy period), then we'd have a problem - but if the RFC editor can publish faster than the IETF can produce, then the editor simply has to stall - whether that occurs at the point where everything that has been produced by the IETF is published, or when nothing produced by the IETF is greater than 2 months old really makes no difference at all. Where we want to avoid delays is in everything that happens before the RFC is approved for publication - once that happens its text is (minor editing aside) known, its citation is known, everything that matters is known, and how long the final step takes isn't that important. | Don't publish the rfc before the appeals counter expires, there lies all | sorts of bad stuff and confusion. I agree. Certainly if there is an appeal then until the appeal is resolved, or it is ascertained that the result of the appeal won't affect what is published (the fact, or the content) then publication needs to be stalled. Waiting the prescribed period for appeals (however long that is, which is a different discussion entirely) before publication doesn't hurt anything, and avoids all kinds of changes being needed to how the RFC archives are maintained. What's more, doing this requires no changes to anything at all - we just ask the RFC editor not to get "too" efficient - to use common sense and not publish anything within the appeals window (however long that is updated as it changes) and everything will be happy. What's more, given that essentially no RFCs have ever been (before now) ready to publish that quick anyway, this isn't going to seem any different to what we have had (ever since appeals have existed anyway) - everything will just continue as it always has, and would have, without complaint, had this issue not been raised. kre _______________________________________________ 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