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