Re: Should the RFC Editor publish an RFC in less than 2 months?
Ted Hardie <hardie@qualcomm.com> Wed, 28 November 2007 21:27 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 1IxUR0-0003yB-Jm; Wed, 28 Nov 2007 16:27:06 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxUQy-0003wh-3s; Wed, 28 Nov 2007 16:27:04 -0500
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxUQw-0004Bb-7p; Wed, 28 Nov 2007 16:27:04 -0500
Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id lASLQwHe004476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 28 Nov 2007 13:26:59 -0800
Received: from [10.0.1.199] (vpn-10-50-0-135.qualcomm.com [10.50.0.135]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id lASLQvV9025817; Wed, 28 Nov 2007 13:26:58 -0800 (PST)
Mime-Version: 1.0
Message-Id: <p06240608c3738ac4aa70@[10.0.1.199]>
In-Reply-To: <CC3C6CC7EE08DA90C239082B@p3.JCK.COM>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com> <CC3C6CC7EE08DA90C239082B@p3.JCK.COM>
Date: Wed, 28 Nov 2007 13:26:56 -0800
To: John C Klensin <john-ietf@jck.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, ietf@ietf.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"
X-PerlMx: Message inspected by PerlMx
X-PerlMx: Message inspected by PerlMx
X-Spam-Score: -4.0 (----)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
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
At 4:02 PM -0500 11/28/07, John C Klensin wrote: >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. At first I thought you meant that all RFCs would be "PROVISIONAL" for two months, but on a second reading, what I understand you to mean is: 1) Anything published before the appeal window closes normally gets whatever status it would have had before (Proposed, Draft, Info, Exp). 2) Anything that gets appealed before the appeal window closed and for which the desired remedy relates to the document's status or language gets marked "provisional" 3) Anything for which the appeal succeeds and the remedy calls for the document to change or the status to change sees the document status go from "provisional" to "historic" and a new document with a new RFC number go out with the change/new status. I'm more-or-less okay with this, given that it does not hold up normal processing, but I note the difference between this and just publishing the docs and later changing their status is pretty small. I'd personally be willing to take the small number of cases where a document is published but quickly moved to historic as a corner case that doesn't need a special status. Appeals tend to be pretty big news within our community, and the rest of the world implements the internet drafts anyway.... This eliminates one possible remedy: removing something from publication. It's replaced with updating a document's status or publishing an update to it saying "withdrawn as a result of appeal". I think that's okay as a consequence of avoiding self-imposed delay, but I do expect someone to squawk. >I'd like to see something like the above combined with a shorter >window, maybe at two levels ("hold publication until..." and >"provisional until..."). Of course, if an appeal is actually >filed, it would be sensible to hold publication until it is >resolved. I don't see any possible reason why we need to give >people two months to get an appeal filed: a month or, at most, >six weeks ought to be more than sufficient. > I also agree that shortening that appeal time is a reasonable idea, though it might require a two-stage "Notify IESG of intent to appeal" and "File final language"; there are some two month periods that have large dead zones (August in Europe, Christmas season in others). The real problem is often that the *combination* of the two month appeal window and the IESG response time can stretch to half a year or longer, especially when the IESG has to do significant work to answer an appeal. That's the only reason I think having a special status indicating the problem is reasonable. Ted _______________________________________________ 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