Re: [Pesci-discuss] stack overflow

"JFC (Jefsey) Morfin" <jefsey@jefsey.com> Wed, 26 October 2005 02:51 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbNo-0007md-2O; Tue, 25 Oct 2005 22:51:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUbNl-0007mN-HQ for pesci-discuss@megatron.ietf.org; Tue, 25 Oct 2005 22:51:17 -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 WAA15998 for <pesci-discuss@ietf.org>; Tue, 25 Oct 2005 22:51:02 -0400 (EDT)
Received: from montage.altserver.com ([63.247.74.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUbaq-0007hk-7D for pesci-discuss@ietf.org; Tue, 25 Oct 2005 23:04:48 -0400
Received: from ver78-2-82-241-91-24.fbx.proxad.net ([82.241.91.24] helo=jfc.afrac.org) by montage.altserver.com with esmtpa (Exim 4.44) id 1EUbNT-00028J-8a; Tue, 25 Oct 2005 19:50:59 -0700
Message-Id: <6.2.3.4.2.20051026014448.0493dd80@mail.jefsey.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4
Date: Wed, 26 Oct 2005 04:50:50 +0200
To: Melinda Shore <mshore@cisco.com>, <dcrocker@bbiw.net>, John C Klensin <john-ietf@jck.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
Subject: Re: [Pesci-discuss] stack overflow
In-Reply-To: <BF841A6B.2DCA%mshore@cisco.com>
References: <435E9CBA.5000905@dcrocker.net> <BF841A6B.2DCA%mshore@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - montage.altserver.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: pesci-discuss@ietf.org
X-BeenThere: pesci-discuss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Process Evolution Study Committee of the IETF discussion <pesci-discuss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pesci-discuss>, <mailto:pesci-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pesci-discuss>
List-Post: <mailto:pesci-discuss@ietf.org>
List-Help: <mailto:pesci-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pesci-discuss>, <mailto:pesci-discuss-request@ietf.org?subject=subscribe>
Sender: pesci-discuss-bounces@ietf.org
Errors-To: pesci-discuss-bounces@ietf.org

At 23:22 25/10/2005, Melinda Shore wrote:
>On 10/25/05 4:59 PM, "Dave Crocker" <dhc@dcrocker.net> wrote:
> > What *used* to mark the IETF as distinctive was its ability to focus on
> > practical issues in a timely fashion and make real forward progress.
>
>I'm increasingly convinced that the decision-making process is
>no longer appropriate for what the IETF has grown into.

Melinda,
The Roman Republic constitution had a solution to that: a 6 month 
Dictator with the mission to restore democracy. That worked well (and 
seldom) until the size of the Republic lead the Dictator to become 
permanent as an Imperator.

If we consider RFC 1958 there might be a solution. To analyse the 
Internet architecture as separated building areas. Each of them 
having its own IETF. To bring back each unit to an area of shared 
competence and interest.

I experimented Harald's suggestion. The current system is WG 
consensus by exhaustion and IETF consensus by abstention (how can 
Members be competent and have a vision in the area of every LC).

For example, an IAB appeal on the architectural consistency and 
adequacy of a proposition comes only when it as been worked, approved 
and confirmed by  the IESG. Too late.

>There seem to be several problems - for example, this kind of 
>decision-making is easy to disrupt.

The only documented counter powers in the proposition above are 
disruption and appeals to IESG and IAB.
There are many ways of disrupting. They should probably be compiled 
in a complement to RFC 3774 to better understand them.

>Another is that as the organization has grown there's a greater 
>diversity of intentions among the participants and the odds that 
>there are participants unwilling to compromise go up.

Here I must disagree on the term "compromise". We are dealing with 
mechanical/societal systems. Bytes and Users do not compromise. Our 
role is to forget personal or corporate agenda and to discover the 
technical solution everyone can use (consensus).

>Another is that if it's difficult to find people with the skills to 
>manage these kinds of discussions when you have three dozen working 
>groups, it's even more difficult to find the people when you have 
>one hundred working groups.

Yes.But there is worse. There is also a lack of competences. A lack 
of competence on the discussed matter is not a big problem when the 
participants' caliber and humility permits them to quickly get up to date.

>A difficulty with trying to change the decision-making process
>is that it's so intimately connected with the membership/participation
>model, and that question has a third-rail quality to it.   But
>I think that the reason that decisions aren't getting made is
>because the process we use for making decisions has become an
>impediment.  What works well for a small group of people who are
>more-or-less on the same page may not work at all well for a
>large group of people with significantly divergent interests.

Yes.
jfc


_______________________________________________
Pesci-discuss mailing list
Pesci-discuss@ietf.org
https://www1.ietf.org/mailman/listinfo/pesci-discuss