Re: IETF Process Evolution

Ted Hardie <hardie@qualcomm.com> Fri, 16 September 2005 19:23 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLni-0005xV-AB; Fri, 16 Sep 2005 15:23:10 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGLng-0005xQ-Lb for ietf@megatron.ietf.org; Fri, 16 Sep 2005 15:23:08 -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 PAA06789 for <ietf@ietf.org>; Fri, 16 Sep 2005 15:23:06 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGLsj-0007GF-PQ for ietf@ietf.org; Fri, 16 Sep 2005 15:28:23 -0400
Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8GJMtcU011392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 16 Sep 2005 12:22:56 -0700 (PDT)
Received: from [192.168.1.4] (vpn-10-50-0-57.qualcomm.com [10.50.0.57]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8GJMr7S020363; Fri, 16 Sep 2005 12:22:54 -0700 (PDT)
Mime-Version: 1.0
Message-Id: <p0623090abf50c3b34bc6@[192.168.1.4]>
In-Reply-To: <03c301c5baed$f2aa4df0$75087c0a@china.huawei.com>
References: <E1EGI1e-00038I-8N@newodin.ietf.org> <p06230901bf509c2b07b4@[192.168.1.4]> <03c301c5baed$f2aa4df0$75087c0a@china.huawei.com>
Date: Fri, 16 Sep 2005 12:22:51 -0700
To: Spencer Dawkins <spencer@mcsr-labs.org>, ietf@ietf.org
From: Ted Hardie <hardie@qualcomm.com>
Content-Type: text/plain; charset="us-ascii"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc:
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

At 1:39 PM -0500 9/16/05, Spencer Dawkins wrote:
>
>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.

Spencer,
	"simply does not work" is good rhetoric, but it doesn't fit all the facts.
Groups like NomCom and IPR have taken on tasks and done them, with community
discussion of their charters and with community discussion as their documents
went through the process.  They are process change groups, and they work.
	Let's say I put forward a charter like the following:


>WG Name:  New Queues (NQ)
>Description of Working Group:
>
>The IETF has too many decisions passing through the same body, the IESG.
>The creation of the IASA and IAD has removed one set of tasks from that queue,
>but there are a considerable number of others which might be moved.
>
>In order to return the IESG to its historic task of managing working groups and
>their output, this working group will describe a process by which new decision
>making queues can come into being.  While the process will be general, the working
>group will fully specify the creation of a process management decision making
>body.  Among other targets for new queues:  oversight of registered values in IANA
>registries; IETF responses to RFC-Editor queries related to RFC-Editor published documents;
>approval of experimental and informational documents that are not created by
>working groups.
>
>Goals and Milestones:
>
>1st Draft of document describing general queue creation mechanism
>
>1st Draft of document describing process management decision making body
>
>2nd Draft of GQCM
>
>2nd Draft of PMDM
>
>WGLC GQCM
>WGLC PMDM
>
>Publish QGCM
>Publish PMDM
>
>Re-charter to use GQCM for new queues, or close.

	Can the IETF community not discuss whether this is the output it wants
and this is the direction of change it wants in terms of this charter?  It may say "no",
but how to say yes or no to a charter is pretty clear, as is how to participate in the
group or react to its output.  Using an ad hoc mechanism to get from the existing
process change mechanism to a new one would work well if we had strong consensus
on where we want to go in process change, but that is the same condition in which
working groups achieve success as well.  If we do not have strong consensus on the
desired process change, the ad hoc mechanism has far muddier mechanisms by
which it is created, by which people participate, and by which its output may be
challenged.  The most obvious mechanism for the last is for someone to put forward
an alternate proposal.  If there are alternate proposals than those coming from the design
team, how do you want to decide among them in the absence of a working group?
Sure, we can invent all kinds of mechanisms to handle it that are equally ad hoc, but
as I said in the Paris plenary, the hard but probably right answer is to use the
existing mechanism one last time to replace it, then move on.  That will require
a lot of work from the Area Director, the WG Chair, and the community, but it is
still the right answer.
				regards,
					Ted Hardie	

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf