Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin <john-ietf@jck.com> Sat, 01 December 2007 16:38 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 1IyVMH-0001FL-2I; Sat, 01 Dec 2007 11:38:25 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyVMG-0001FF-6j for ietf@ietf.org; Sat, 01 Dec 2007 11:38:24 -0500
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyVMF-0005nE-HA for ietf@ietf.org; Sat, 01 Dec 2007 11:38:24 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IyVME-0002cw-W8; Sat, 01 Dec 2007 11:38:23 -0500
Date: Sat, 01 Dec 2007 11:38:22 -0500
From: John C Klensin <john-ietf@jck.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf@ietf.org
Message-ID: <41DBABA8CD72B065EE053127@p3.JCK.COM>
In-Reply-To: <firlnd$5h7$1@ger.gmane.org>
References: <E1IxTPt-0006r4-ST@ietf.org> <474E61A4.2000201@alvestrand.no> <010901c83339$b56e0d20$0601a8c0@pc6> <firlnd$5h7$1@ger.gmane.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc:
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 Saturday, 01 December, 2007 13:59 +0100 Frank Ellermann <nobody@xyzzy.claranet.de> wrote: > Tom Petch wrote: > >> a 60 day hold seems rather a good idea. > > Indeed, unless somebody transforms John's proposal "6 weeks" > in an ION and/or 2026 update, or whatever red tape cutting > this needs. If appeals are drafted by a kind of community > this needs time (e.g. to figure out who read the relevant > "procdoc" RFCs... ;-) Frank, while figuring out what we are doing and documenting it would certainly be a good idea, my suggestion was carefully written to be feasible without any action as formal as opening 2026. The IESG clearly has the authority today (if only because the RFC Editor believes that they do) to ask for a publication hold. All it would take to implement that part of my suggestion would be an announcement that, while the appeal window remains at two months, any appeals that intend to ask for a publication hold must be announced in some substantive way within some much shorter time. Whether or not publication delays are then granted might, as I suggested, depend on joint IESG/IAB decisions about the level of possible damage and merit of the appeal. But, as many others have pointed out, the cases are few in which significant damage would be done by publishing and then changing status and/or posting a follow-up. I'd even suggest that a document that was significant enough to achieve IETF consensus as measured by the IESG --even if that measurement is overturned on appeal-- is a document that would normally deserve publication as a "path not traveled" independent or individual submission. That view argues that, in the rare cases in which a publication delay might be justified, someone who thinks one is needed should ask (presumably by posting a notice of intent to appeal with that request and justification) really quickly, before the RFC Editor can review, publish, and post _however_ short that time is. I'd then expect the IESG to ask that publication be suspended until they and the IAB can sort out whether a delay while the appeal is filed and sorted out is appropriate. But, again, while an ION to record whatever the plan is would be appropriate, I don't think we would be doing ourselves a favor by turning this into a big deal with a lot of formal procedures and cutoffs. As I think more about it, harm is more likely to be caused by IANA registrations specified in a document as requiring IETF or IESG approval and then needing to undo such registrations after an appeal than by publication of the document itself. As far as I know, we have never insisted on a two month hold for such registrations: we just assume that we can deprecate them if we have to. john _______________________________________________ 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