Re: [Pesci-discuss] Growing concerns about PESCI

John C Klensin <john-ietf@jck.com> Tue, 25 October 2005 18:51 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTtb-0000aQ-3c; Tue, 25 Oct 2005 14:51:39 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUTtZ-0000aL-L1 for pesci-discuss@megatron.ietf.org; Tue, 25 Oct 2005 14:51:37 -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 OAA12221 for <pesci-discuss@ietf.org>; Tue, 25 Oct 2005 14:51:23 -0400 (EDT)
Received: from ns.jck.com ([209.187.148.211] helo=bs.jck.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUU6a-00060H-1t for pesci-discuss@ietf.org; Tue, 25 Oct 2005 15:05:04 -0400
Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.34) id 1EUTtP-000LxP-FR; Tue, 25 Oct 2005 14:51:27 -0400
Date: Tue, 25 Oct 2005 14:51:27 -0400
From: John C Klensin <john-ietf@jck.com>
To: Marshall Eubanks <tme@multicasttech.com>, Leslie Daigle <leslie@thinkingcat.com>, pesci-discuss@ietf.org
Subject: Re: [Pesci-discuss] Growing concerns about PESCI
Message-ID: <92CDAD938E5F923C2ABA7F9B@scan.jck.com>
In-Reply-To: <web-3031527@multicasttech.com>
References: <web-3031527@multicasttech.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: a7d2e37451f7f22841e3b6f40c67db0f
Content-Transfer-Encoding: 7bit
Cc:
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


--On Tuesday, 25 October, 2005 13:44 -0400 Marshall Eubanks
<tme@multicasttech.com> wrote:

> On Tue, 25 Oct 2005 12:53:53 -0400
>  Leslie Daigle <leslie@thinkingcat.com> wrote:
>> 
> 
> Dear Leslie;
> 
> May I suggest to everyone that the first step in having PESCI
> be a normal working group  might be to start acting like a
> normal working group, and stop cc:ing the IETF list with every
> message :) (Done here, BTW.)

Marshall, may I suggest that your note contains the internal
contradiction that is a significant part of the problem I'm
seeing here, and maybe part of the one Leslie is seeing as well.


If this were a normal working group, it would have a charter, a
charter that would have been through a process of review and
approval by the community.  Its membership would be open, and
there would be no room for internal WG discussions that were not
visible  to the community.  If it held interim meetings or
teleconferences, there would be an expectation that those would
be announced to the community in advance and arrangements made
so that anyone who was inclined to do so and had the resources
could attend and participate.  It would have a chair who was not
the AD in charge of the relevant area, nor would that principle
be bypassed by a quickie substitution.  And we would hold the WG
--and its chair and AD-- responsible for paying serious
attention to community input.  So, whatever it is, it isn't a
normal working group.

Instead, if this were a normal group --design team or
otherwise-- that came together to organize a normal WG, it would
(normally) get a BOF slot only when it had demonstrated a fair
amount of coherence.  More important, the first (or only
significant) agenda item for that BOF would be the contents and
appropriateness of that charter, how the would-be WG intended to
conduct itself, perhaps the area to which the WG would be
assigned if there was doubt, etc.   There is virtually no chance
that it would get a BOF slot and then get a significant amount
of plenary time: it would be unlikely to get even a few
sentence's worth of announcement at a plenary, and certainly
would not get a half-hour or more.  So, whatever it is, it isn't
a normal group (design team or otherwise) trying to put a WG
together.
 
> Generally, "requirements" in a standards body are both
> implicit and explicit, and are not based purely on the legal
> framework. There has to be  a certain amount of trust (and
> trustworthiness) between the parties; if there is not, then
> things can go very wrong indeed. A formal requirement to
> listen to good ideas (where-ever they come from) is basically
> never really enforceable, but is always morally present
> whenever people are trying to act for the good of a larger
> entity.

Well, I certainly agree with this.  But part of our
justification for design teams is that they are often not
charged with producing an IETF-consensus result, merely a result
that is sufficiently clear and internally consistent to permit
community evaluation.  Without the constraints that implies, we
would be likely to get the worst sorts of design-by-committee --
not merely a camel, but perhaps a horse with gills and flippers
at one end.   The difficulty with, and danger of, design teams
is that they need to produce one or more proposals for community
consideration.  If they operate in an environment in which their
proposals are essentially the only options that can or will be
considered (perhaps modulo fine tuning), then we will have blown
off all sorts of important aspects of what makes the IETF
function and be taken seriously.

This isn't, however, one of those sorts of design teams either.
Those teams usually report their results back to a WG or, as
discussed above, a WG-in-formation, and then more or less close
down, leaving the WG to sort out the proposal.   That doesn't
seem to be the plan here either: instead, we get a short BOF
session, a fifteen minute discussion of how to proceed, then an
almost-immediate 30 minute report to a plenary, followed by an
"open meeting" session whose listed "Admin and Operations topics
only" theme would not seem to admit of discussion of the PESCI
issues.  So, whatever this is, it isn't a design team in the
usual sense.   

I posted my note to the IETF list because I think the IETF list
ought to be discussing this basic principles here, not just the
subset of people who are inclined to watch PESCI's
sausage-making through the cloudy windows of a -discuss list.
To me, the question the IETF should be discussing is the degree
to which we are willing to abandon our principles of open
discussion, responsibility to the community, and decision and
evaluation chains that don't involve people talking to
themselves in order to figure out a new way to do the things
that the existing processes are intended to protect.

And that is why I believe Leslie's question was appropriate for
the IETF list as well.    If this were a normal working group,
or on track to become a normal working group, the answers would
probably be different.

     john




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