Re: Should the RFC Editor publish an RFC in less than 2 months?
John C Klensin <john-ietf@jck.com> Sat, 01 December 2007 20:43 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 1IyZBd-0001kB-2m; Sat, 01 Dec 2007 15:43:41 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyZBb-0001k2-Cs for ietf@ietf.org; Sat, 01 Dec 2007 15:43:39 -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 1IyZBZ-0005ek-0d for ietf@ietf.org; Sat, 01 Dec 2007 15:43:39 -0500
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1IyZBY-000Dby-7K; Sat, 01 Dec 2007 15:43:36 -0500
Date: Sat, 01 Dec 2007 15:43:35 -0500
From: John C Klensin <john-ietf@jck.com>
To: Frank Ellermann <hmdmhdfmhdjmzdtjmzdtzktdkztdjz@gmail.com>, ietf@ietf.org
Message-ID: <CBC755EE60AFCD6DFB52BDB3@p3.JCK.COM>
In-Reply-To: <fisflk$f34$1@ger.gmane.org>
References: <E1IxTPt-0006r4-ST@ietf.org> <474E61A4.2000201@alvestrand.no> <010901c83339$b56e0d20$0601a8c0@pc6> <firlnd$5h7$1@ger.gmane.org> <41DBABA8CD72B065EE053127@p3.JCK.COM> <fisflk$f34$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: 73734d43604d52d23b3eba644a169745
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 21:22 +0100 Frank Ellermann <nobody@xyzzy.claranet.de> wrote: > John C Klensin wrote: > >> 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. > > Yes, and you also said that you're not going to do it. Yes. I have made a personal decision that spending my time on Internet technology and protocols is better for the Internet and better for my mental and physical health than making further investments in IETF procedures. That decision has been reinforced by an assortment of actions in the past, including IAB, IESG, and Nomcom actions. I will probably continue to track issues like this, and IPR ones, etc. I may even express opinions about what might be placed in an I-D. But, if process I-Ds need to be written, someone else will need to write them, at least unless someone starts paying me a salary to do so. > If Brian wants to tackle it he'd likely integrate your > idea in his "appeal" I-D, Harald might prefer an ION to > have it on public record, IMO there are various ways to > "implement" your proposal. Of course, although I am in strong agreement with Spencer's comments that making rigid, BCP-level, procedures for unusual cases has almost never served us well. I more or less said that, but Spencer's note is much more clear and explicit. >> 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. > > Okay, but it's not a clean hack. In both cases where I felt > a sudden urge to appeal (sitefinder-verisign and termination > of MARID) I ended up with speed reading RFCs based on grep > and Google searches, I'd certainly have missed anything more > subtle, e.g. an ION or old IESG announcement buried in a list > archive. I needed three months to find "3710 to historic" as > a potential "remedy", it wasn't on my CD ROM with RFCs, and > of course three months was anyway far too late. > > BTW, that's a flaw in Brian's proposal to deprecate the STD 1 > rule, not everybody reads the RFCs online with access on a > list of current STDs (etc.) published as rfc-editor.org page. I think you are conflating two issues. The first is that what I suggested is not, IMO, a hack. It is taking advantage of flexibility and options for applying discretion that are built into the system (mostly not by accident). YMMD, of course. The second is about whether the IETF processes are straightforward and well-documented enough that someone who is not already very familiar with them can efficiently navigate the process. We are probably in agreement about that state of affairs. I would favor fixing it but, based on painful experience, I would recommend that anyone who wants to try get IESG signup first and that they not get the effort entangled with working on the answer to any short-term or isolated question (of which publication delay issues are certainly an example). Your other comments are much more general. Whether I agree or disagree, I don't have time to respond adequately this weekend. I would, however, note that several of the issues you identify would have been resolved by proposals that were made a few years ago. The IESG decided those changes were either unnecessary, undesirable, or not worth the trouble and the community accepted those decisions (even if the only concrete way to measure "accepted" is that no one got recalled and the IESG did not get fired in toto). For better or worse, that suggests that the people who care about these things are a minority and that they have not been successful in convincing the majority that the topics are worth significant consideration. I think those of us who make up that minority need to accept that face... and I have. 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