Re: Last Call: 'IETF Process and Operations Documentss' to Experimental RFC (draft-alvestrand-ipod)
John C Klensin <john-ietf@jck.com> Mon, 12 June 2006 12:05 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FplB6-0007Jf-B7; Mon, 12 Jun 2006 08:05:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FplB5-0007JD-Bq; Mon, 12 Jun 2006 08:05:55 -0400
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FplB0-0006yO-Qx; Mon, 12 Jun 2006 08:05:55 -0400
Received: from [127.0.0.1] (helo=p3.JCK.COM) by bs.jck.com with esmtp (Exim 4.34) id 1FplB0-000NOA-C8; Mon, 12 Jun 2006 08:05:50 -0400
Date: Mon, 12 Jun 2006 08:05:49 -0400
From: John C Klensin <john-ietf@jck.com>
To: Brian E Carpenter <brc@zurich.ibm.com>
Message-ID: <3187EFE898B6B2C37AD24523@p3.JCK.COM>
In-Reply-To: <448D3BAD.6010809@zurich.ibm.com>
References: <E1FgprF-0005NC-SM@stiedprstage1.ietf.org> <22CF18227DB74B2E6D92F4D1@p3.JCK.COM> <448D3BAD.6010809@zurich.ibm.com>
X-Mailer: Mulberry/4.0.4 (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: 10ba05e7e8a9aa6adb025f426bef3a30
Cc: iesg@ietf.org, ietf@ietf.org
Subject: Re: Last Call: 'IETF Process and Operations Documentss' to Experimental RFC (draft-alvestrand-ipod)
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 Monday, 12 June, 2006 12:02 +0200 Brian E Carpenter <brc@zurich.ibm.com> wrote: > John, > > John C Klensin wrote: >> >> --On Thursday, 18 May, 2006 17:16 -0400 The IESG >> <iesg-secretary@ietf.org> wrote: >> >> >>> The IESG has received a request from an individual submitter >>> to consider the following document: >>> >>> - 'IETF Process and Operations Documentss ' >>> <draft-alvestrand-ipod-01.txt> as an Experimental RFC >>> >>> This is a proposed process experiment under RFC 3933. >>> The IESG plans to make a decision in the next few weeks, and >>> solicits final comments on this action. Please send any >>> comments to the iesg@ietf.org or ietf@ietf.org mailing lists >>> by 2006-06-15. >> >> >> Hi. >> I think this idea is generally a good one. It seems to me to >> be quite desirable to bring all IETF procedural materials and >> notes into a single series and to decouple the publication of >> those materials from the RFC Editing process: the documents >> are not archival and should not delay, or be delayed by, >> technical specifications. >> >> I have three concerns: >>... >> (3) The document is written on a model that I would describe >> as "here are the principles, the IESG should sort out the >> details". Personally, I think that is the right model, at >> least as long as the IESG's decisions about details are >> subject to appeal. But some of the members of previous IESGs >> have expressed concerns that making similar decisions would >> add to their workload or that documents were not acceptable >> unless they contained much more specific detail. >> >> To permit the community to evaluate this Last Call, it seems >> to be to be critical to know whether the IESG is willing to >> take on that responsibility. > > It's clear to me that this experiment will only succeed > if it is run in a lightweight manner. By that I mean using > procedures like a formal last call, and an approval process > other > than "silence means consent", only when things are contentious. > I don't see the IESG responsibility being any different from > what happens today when, for example, 1id-guidelines gets > updated, or when an IESG Statement is issued. I agree, modulo a comment that has been made elsewhere: in general, anything that requires Last Call now and formal publication now, such as a significant change in procedures, requires that same level of processing under this model. In other words, this is a way to collect documents together in a coherent way, not a way to permit IESG to make major procedural changes --changes it cannot make today-- on its own initiative. Much as I like the general ideas behind this document, if the above restriction is not clear to all concerned, I'd need to oppose this particular proposal. >> It would also be helpful to know whether >> the IESG will consider these documents, especially the ones >> that define the parameters of the series, to be subject to >> the usual appeal procedures when they are adopted and >> published. > > Recently the IESG has chosen to interpret the right of appeal > broadly, even though the text in RFC 2026 is unclear about > scope. > I don't see how we could refuse to consider an appeal about an > ION, although I'd hope that we could normally resolve issues > without the need for it. I would hope we could normally resolve all issues by informal discussion rather than appeals. History indicates that sometimes we cannot. john _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: Last Call: 'IETF Process and Operations Docum… John C Klensin
- Re: Last Call: 'IETF Process and Operations Docum… Harald Alvestrand
- Re: Last Call: 'IETF Process and Operations Docum… John C Klensin
- Re: Last Call: 'IETF Process and Operations Docum… Brian E Carpenter
- Re: Last Call: 'IETF Process and Operations Docum… John C Klensin