Re: IETF Process Evolution
"Spencer Dawkins" <spencer@mcsr-labs.org> Fri, 16 September 2005 18:39 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGL7k-0002OV-5a; Fri, 16 Sep 2005 14:39:48 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGL7h-0002OK-Uu for ietf@megatron.ietf.org; Fri, 16 Sep 2005 14:39:46 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03269 for <ietf@ietf.org>; Fri, 16 Sep 2005 14:39:44 -0400 (EDT)
Received: from sccrmhc11.comcast.net ([63.240.76.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGLCi-00061I-Nn for ietf@ietf.org; Fri, 16 Sep 2005 14:45:00 -0400
Received: from s73602 (unknown[65.104.224.98]) by comcast.net (sccrmhc11) with SMTP id <2005091618392901100on2ome>; Fri, 16 Sep 2005 18:39:29 +0000
Message-ID: <03c301c5baed$f2aa4df0$75087c0a@china.huawei.com>
From: Spencer Dawkins <spencer@mcsr-labs.org>
To: ietf@ietf.org
References: <E1EGI1e-00038I-8N@newodin.ietf.org> <p06230901bf509c2b07b4@[192.168.1.4]>
Date: Fri, 16 Sep 2005 13:39:18 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Content-Transfer-Encoding: 7bit
Subject: Re: IETF Process Evolution
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>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
From: "Ted Hardie" <hardie@qualcomm.com> >I would like to note that the use of this process was not agreed to by a >consensus of > the IESG. > > Brian sent early versions of this proposal to the IESG, and it received > considerable pushback, some of it from me. I strongly encouraged > Brian to use a design team to draft a charter for a tightly focused > working > group in the General Area instead. I agree with Brian that general > discussion of IETF process change tends to diverge and to move slowly, > but I believe that working groups like NomCom show that we can succeed > with focused charters in establishing new procedures or revising existing > ones. I believe the public chartering process of a focused working group > is a useful, necessary part of the openness of the IETF process, and that > the public discussion within that charter, once established, is critical > for process change of the scope envisioned. Hi, Ted, There are a lot of very helpful comments later in your note to Brian, which I snipped, but I wanted to respond to this paragraph. While it seems plausible that we could use the same mechanism for protocol design and for process evolution, my understanding of the Problem working group's efforts and the subsequent newtrk/icar/proto/mpowr (and yes, there were others) efforts is that this approach simply does not work. I used to believe that it could, and was honestly surprised when it didn't. I was wrong. It happens. I wrote my observations on "why working groups don't work for process change" in an early draft of what became RFC 3933. I agreed to remove the observations in order to publish the draft (the question was, "do you want to publish the draft or argue about the observations?"), but I still think Sections 1, 2 and 3 of http://bgp.potaroo.net/ietf/all-ids/draft-klensin-process-july14-01.txt were accurate when they were written, and I do not know why these observations would have been invalidated in the past two years. Whenever I refer to this version of the draft, I need to add this disclaimer: The reason this approach fails isn't anyone's fault - it's systemic. I continue to have the highest respect for the ADs who supported these efforts to improve things, and for the BOF chairs, WG chairs, and editors who tried to make improvements happen. But we've already been here. At the very least, I expect "coming up with a tight charter" to derail any discussion of evolution until IETF 65. That's what happened in newtrk and icar, when IETF participants went from discussing proposals to discussing a charter. Spencer _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- Re: IETF Process Evolution Ted Hardie
- Re: IETF Process Evolution Spencer Dawkins
- Re: IETF Process Evolution Ted Hardie
- Re: IETF Process Evolution Dave Crocker
- Re: IETF Process Evolution C. M. Heard
- Re: IETF Process Evolution Ted Hardie
- Re: IETF Process Evolution Joel M. Halpern
- Re: IETF Process Evolution Spencer Dawkins
- Re: IETF Process Evolution John C Klensin
- Re: IETF Process Evolution Pekka Savola
- Re: IETF Process Evolution Ted Hardie
- Re: IETF Process Evolution JFC (Jefsey) Morfin
- Re: IETF Process Evolution Brian E Carpenter
- Re: IETF Process Evolution Brian E Carpenter
- Re: IETF Process Evolution Spencer Dawkins
- Re: IETF Process Evolution Leslie Daigle
- Re: IETF Process Evolution Harald Tveit Alvestrand
- Re: IETF Process Evolution Brian E Carpenter