Re: Should the RFC Editor publish an RFC in less than 2 months?
Brian E Carpenter <brian.e.carpenter@gmail.com> Wed, 28 November 2007 21:37 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 1IxUb4-0003TY-01; Wed, 28 Nov 2007 16:37:30 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUb2-0003St-6e for ietf@ietf.org; Wed, 28 Nov 2007 16:37:28 -0500
Received: from rv-out-0910.google.com ([209.85.198.189]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxUb1-0000so-Oz for ietf@ietf.org; Wed, 28 Nov 2007 16:37:28 -0500
Received: by rv-out-0910.google.com with SMTP id l15so1282769rvb for <ietf@ietf.org>; Wed, 28 Nov 2007 13:37:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; bh=M9y5lciRs5Gql1GJI5yhzGls966QJggS5GZmOJv0AzM=; b=DS4RBSzkBSoCRULuW+9wp1Jt45pMBtZpukcvasTJOefcYpvNGVlpEaIaOUKRWAypPkComv2ZxPR3Lh33o4RCvAVafRoXsgmW+hnRUF3VaPbdn/UkSrBnJZrGrCp6cnMBgyrdPjMt2R2Htojob7WyduEExc+lnZEFYql2A1NP4gA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:organization:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=R6VVg+kFV2paA5UexguyscKlt5lQPjjgCIqHXodcCDgskbqBpSQGfe4kEDZ9HHRaFFHo967XJYuoQuAKTcX8Rug8JesV5vPoav7+2llQWmCVitTt5wLMht3uz1r4DUb2vqmmw1gKrIYj8bA2ciAnfzkBuRadvcJc953J2gDP3sQ=
Received: by 10.141.48.10 with SMTP id a10mr2875329rvk.1196285847018; Wed, 28 Nov 2007 13:37:27 -0800 (PST)
Received: from ?130.216.38.124? ( [130.216.38.124]) by mx.google.com with ESMTPS id c19sm1750447rvf.2007.11.28.13.37.24 (version=SSLv3 cipher=RC4-MD5); Wed, 28 Nov 2007 13:37:26 -0800 (PST)
Message-ID: <474DDF90.8020507@gmail.com>
Date: Thu, 29 Nov 2007 10:37:20 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Eric Rescorla <ekr@networkresonance.com>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com> <20071128211412.E3C3533C57@delta.rtfm.com>
In-Reply-To: <20071128211412.E3C3533C57@delta.rtfm.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4
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
On 2007-11-29 10:14, Eric Rescorla wrote: > At Thu, 29 Nov 2007 09:54:47 +1300, > Brian E Carpenter wrote: <snip> >> 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. Very possibly. It's always struck me that "the situation shall then be as it was before" is a rather unrealistic goal, since you can't un-send email, un-publish a draft, cancel a past mailing list suspension, etc. Decisions can be revoked, but their physical consequences sometimes can't be. So in any case, that phrase in 2026 probably needs qualification. (For example, "insofar as this is materially possible".) Brian _______________________________________________ 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