Re: Should the RFC Editor publish an RFC in less than 2 months?
Robert Elz <kre@munnari.OZ.AU> Tue, 04 December 2007 08:25 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 1IzT6M-0003Md-PB; Tue, 04 Dec 2007 03:25:58 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzT6K-0003K8-PT; Tue, 04 Dec 2007 03:25:56 -0500
Received: from [202.28.99.196] (helo=jade.coe.psu.ac.th) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzT6F-0005zY-UL; Tue, 04 Dec 2007 03:25:56 -0500
Received: from jade.coe.psu.ac.th (localhost [127.0.0.1]) by jade.coe.psu.ac.th with ESMTP id lB48NsRu009774; Tue, 4 Dec 2007 15:23:56 +0700 (ICT)
From: Robert Elz <kre@munnari.OZ.AU>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
In-Reply-To: <47546156.3070304@gmail.com>
References: <47546156.3070304@gmail.com> <2788466ED3E31C418E9ACC5C316615570462D9@mou1wnexmb09.vcorp.ad.vrsn.com> <24721.1196675381@munnari.OZ.AU>
Date: Tue, 04 Dec 2007 15:23:54 +0700
Message-ID: <7026.1196756634@jade.coe.psu.ac.th>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
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
Date: Tue, 04 Dec 2007 09:04:38 +1300 From: Brian E Carpenter <brian.e.carpenter@gmail.com> Message-ID: <47546156.3070304@gmail.com> | It's the instant of formal publication, and that changes at least | two things: | | 1. It allows other SDOs that require a normative citation to proceed | with *their* publication process, in order to meet their own deadlines. And do you really believe that some other SDO wants to proceed with their own activities, only to be told a few weeks later that the RFC has been wathdrawn after a successful appeal? Don't you expect that they're really after some kind of stability? If they really need the actual RFC, don't you think that is because they want the stability that gives - and in that case, shouldn't we be making sure that RFC publication actualy means what it has meant in the past - and not be just a temporary parking place until an appeal (rarely, for sure, but possible) causes it to be removed? For general citations, just having the data is enough. Don't you ever cite papers (your own, or others) that you know are to be published in some journal or proceedings, before he actual paper copy arrives on your desk? | 2. It triggers action by product developers and writers of RFPs, | especially those not actively involved in the IETF. Same as above. If you're issuing an RFP, wouldn't you look a bit silly if you demanded conformance to an RFC that didn't actually exist at the time the responses were due? | The RFC Editor hates to reveal RFC numbers until publication is | a certainty. Yes, Joel Halpern, in a private message, also pointed that out - I wasn't as clear as I should have been. What I meant (should have said) was that at some point in the RFC process (now, past, and no necessary reason to change this in the future - though it could be done) the RFC number is allocated. That's certainly before AUTH48, as when the authors get their copy to review, the RFC number is there. There's no reason any of that should change, or be delayed - the RFC number will still be available as soon as the RFC Editor is ready to make it available, and if that gets closer and closer to the IESG's approval action, that's just fine. There is a variable length delay (and potential termination) of the publication process now, between number allocation and actual publication - the only question is whether it makes sense for there to be some minimum delay to make sure that appeals are no longer possible. If the RFC Editor really wants to hold the number secret until the actual publication is certain, then that means altering current practice, as it is certainly possible for an RFC to be withdrawn during AUTH48. What's more, even ignoring that, if publication is made as soon as possible, the effect would be that occasionally (infrequently for sure) an RFC will get published, only to be removed later after an appeal- and I'd think that's something the RFC Editor would like even less than the occasional "this RFC was never published" gap in the numbering scheme, because of an allocation that ended up unused. 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