Re: Should the RFC Editor publish an RFC in less than 2 months?
Eric Rescorla <ekr@networkresonance.com> Wed, 28 November 2007 22: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 1IxVXT-00052K-81; Wed, 28 Nov 2007 17:37:51 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxVXQ-000515-9k; Wed, 28 Nov 2007 17:37:48 -0500
Received: from [209.213.211.195] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxVXP-0003cG-Hj; Wed, 28 Nov 2007 17:37:48 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 461A033C58; Wed, 28 Nov 2007 14:32:35 -0800 (PST)
Date: Wed, 28 Nov 2007 14:32:34 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Sam Hartman <hartmans-ietf@mit.edu>
In-Reply-To: <tslve7mc8z7.fsf@mit.edu>
References: <E1IxTPt-0006r4-ST@ietf.org> <474DD597.9040208@gmail.com> <CC3C6CC7EE08DA90C239082B@p3.JCK.COM> <tslve7mc8z7.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: <20071128223235.461A033C58@delta.rtfm.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
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
At Wed, 28 Nov 2007 17:15:40 -0500, 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. I'm actually very concerned by this reasoning. Upon deciding an appeal, the IESG owes the appellant a prompt response. If they don't have time to write up a response, then that's fine, they can treat the appeal as undecided but the document should be held pending the IESG getting time to do that. Remember that the appellant cannot appeal to the IAB until the IESG has responded to his appeal (S 6.5.2.). Given that many appeals are appeals *of IESG actions* and therefore that the IESG is not a neutral party, it seems quite problematic to allow the IESG to in effect decide the appeal but simply not respond, thus denying the appellant any avenue of recourse to a neutral body. In the limit, the IESG could simply internally decide to proceed as if the appeal had been denied, but hold the appeal response indefinitely, thus indefinitely denying the appellant further recourse under 2026. > One critical assumption in my evaluation is that RFCs can be > withdrawn. I'm quite confident that given a court order the RFC > editor, the IETF website, etc, would find a way to remove an RFC. As > such, we as a community can establish our own processes for > withdrawing an RFC. So, clearly we need some way to withdraw documents *from the repository*, for instance for copyright reasons, but I think that's fundamentally a different issue from retracting them. Let's say that document X is published at PS, but contains some purely informational example source code. If it were later determined that that code was improperly licensed, X would need to be removed from the repository, but we would not treat it as if it didn't exist. If, for instance, document Y had a normative dependency on X, we wouldn't feel the need to go back and mark Y HISTORIC/WITHDRAWN/whatever. We'd just go and do a noninfringing document that obsoleted X. By contrast, if document Z depends on document W and W is subject to a successful appeal, we would need to withdraw Z, any documents that depended on it, and ultimately the transitive closure of any documents depending on W. So, I think these cases are quite different. -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