Re: Should the RFC Editor publish an RFC in less than 2 months?
Eric Rescorla <ekr@networkresonance.com> Thu, 29 November 2007 00:39 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 1IxXQw-0001lx-OI; Wed, 28 Nov 2007 19:39:14 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXQt-0001kV-6D; Wed, 28 Nov 2007 19:39:11 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxXQs-0008E4-B1; Wed, 28 Nov 2007 19:39:11 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 0636533C3D; Wed, 28 Nov 2007 16:33:58 -0800 (PST)
Date: Wed, 28 Nov 2007 16:33:58 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
In-Reply-To: <tsl8x4hdiay.fsf@mit.edu>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com> <CC3C6CC7EE08DA90C239082B@p3.JCK.COM> <tslve7mc8z7.fsf@mit.edu> <20071128223235.461A033C58@delta.rtfm.com> <tsl8x4hdiay.fsf@mit.edu>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071129003359.0636533C3D@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: iab@ietf.org, ietf@ietf.org, iesg@ietf.org, John C Klensin <john-ietf@jck.com>
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 Wed, 28 Nov 2007 19:08:53 -0500, Sam Hartman wrote: > > >>>>> "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. Yes, I've been thinking about this analogy as well, but I think it cuts the opposite way from what you're arguing. In a legal proceeding, the two parties argue their case before a presumptively neutral arbiter (the judge). As you say, the judge can choose to issue a preliminary injunction while the case is being heard and pending the final outcome. This works because at least in theory the judge is neutral--you wouldn't let the plaintiff or the defendant decide on whether the PI should be granted. A 2026 appeal is an entirely different case, namely, that the party hearing the appeal (the IESG) isn't neutral at all. On the contrary, they're the party who's decision is being appealed! So, no, I don't think they can be allowed to make a decision about whether the appellant is likely to prevail or the damage that is likely to be done if the appeal is later upheld. > 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. It seems to me that if the IESG has enough confidence about the "direction it is likely to consider" to proceed with document publication, they have in effect decided the appeal, regardless of whether the response text has actually been drafted. And if not, then they should stop publication until they have decided the appeal. As for the IESG's ability to predict whether the IAB will eventually uphold an appeal, my experience is that it's not actually that great, and, given the inherent COI involved, I don't see how they can be allowed to make that judgement, regardless of its expected accuracy. > I think there are cases where it is appropriate not to allow an > pending appeal to block publication. That may be so. What I'm saying is that the IESG shouldn't get to make that decision. > 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. Well, that's not what I proposed: rather, I said there should be a hard rule. That said, regardless of whether the IAB is too conservative or not, they're at least in principle neutral, which makes them a far more appropriate body to make this decision than the IESG, which is not. -Ekr _______________________________________________ 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