Re: Should the RFC Editor publish an RFC in less than 2 months?
Sam Hartman <hartmans-ietf@mit.edu> Thu, 29 November 2007 00:08 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 1IxWxe-0001K0-D8; Wed, 28 Nov 2007 19:08:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxWxc-0001Ix-3f; Wed, 28 Nov 2007 19:08:56 -0500
Received: from carter-zimmerman.suchdamage.org ([69.25.196.178]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxWxb-00074c-He; Wed, 28 Nov 2007 19:08:55 -0500
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 1AE684815; Wed, 28 Nov 2007 19:08:53 -0500 (EST)
From: Sam Hartman <hartmans-ietf@mit.edu>
To: Eric Rescorla <ekr@networkresonance.com>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com> <CC3C6CC7EE08DA90C239082B@p3.JCK.COM> <tslve7mc8z7.fsf@mit.edu> <20071128223235.461A033C58@delta.rtfm.com>
Date: Wed, 28 Nov 2007 19:08:53 -0500
In-Reply-To: <20071128223235.461A033C58@delta.rtfm.com> (Eric Rescorla's message of "Wed, 28 Nov 2007 14:32:34 -0800")
Message-ID: <tsl8x4hdiay.fsf@mit.edu>
User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: John C Klensin <john-ietf@jck.com>, ietf@ietf.org, 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
>>>>> "Eric" == Eric Rescorla <ekr@networkresonance.com> writes: Eric> At Wed, 28 Nov 2007 17:15:40 -0500, Eric> Sam Hartman wrote: >> >>>>> "John" == John C Klensin <john-ietf@jck.com> writes: >> John> --On Thursday, 29 November, 2007 09:54 +1300 Brian E John> Carpenter John> <brian.e.carpenter@gmail.com> wrote: >> John> I'd like to see something like the above combined with a John> shorter window, maybe at two levels ("hold publication John> until..." and "provisional until..."). Of course, if an John> appeal is actually filed, it would be sensible to hold John> publication until it is resolved. >> I disagree that it is always sensible to hold publication >> until the appeal is resolved, particularly for expedited >> publication drafts. >> >> We've had some very bogus appeals and writing up the responses >> is not always our top priority. Eric> I'm actually very concerned by this reasoning. Upon deciding Eric> an appeal, the IESG owes the appellant a prompt response. If Eric> they don't have time to write up a response, then that's Eric> fine, they can treat the appeal as undecided but the Eric> document should be held pending the IESG getting time to do Eric> that. I was sloppy in my wording and thought process. In the American legal system, there is a concept of a preliminary injunction--a leagel procedure to stop some action pending the outcome of some legal action. The idea is that there are some cases where it is desirable to hold things pending an outcome being determined, and some cases where there is a desire to clean up the mess later if there ends up being a problem. I think that for some of the same reasons preliminary injunctions make sense in the IETF, it is sometimes desirable to say that the probability that withdrawing a document is going to be the right solution is low enough that the appeal should not block the process. The IESG typically doesn't "decide appeals" without actually having response text in front of it; I think that is right and proper. However, the IESG does sometimes know what direction it is likely to consider in drafting response text and does have an idea about how probable it is that publishing a document and later the IESG or IAB realizing that a mistake was made is harmful. I think there are cases where it is appropriate not to allow an pending appeal to block publication. It might be reasonable for the IAB to be able to hold publication before an appeal had formally reached them. Personally I think the current IAB would be too conservative in applying this power and I'd like the community to come up with some guidance to give the IAB if they were going to do that regularly. I have confidence that if the community could agree on guidance the IAB would do a fine job of applying that and I have confidence that absent guidance the IAB would use their best judgment. I just think the IAB tends to be more conservative than would be appropriate in this case. _______________________________________________ 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