Re: [Pesci-discuss] Growing concerns about PESCI

["Marshall Eubanks" <[e-mail]>]

Dear John;

On Tue, 25 Oct 2005 14:51:27 -0400
 John C Klensin <[e-mail]> wrote:
> 
> 
> --On Tuesday, 25 October, 2005 13:44 -0400 Marshall Eubanks
> <[e-mail]> wrote:
> 
> > On Tue, 25 Oct 2005 12:53:53 -0400
> >  Leslie Daigle <[e-mail]> 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.
> 

Reading through this, I am beginning to share your concerns. I can
understand short-circuiting certain aspects of the process (such as the time
to appear at Plenary), but I think that having a confusing process 
is very dangerous. Is this
going to be a new model for IETF processes ? If so,  what is  it  exactly ?
Is it  documented ? Did it pass any  form of review ?

It is also dangerous  to throw out a solution that works, albeit with
flaws,  for one that has never been implemented but appears to be easier. It may not be.

In this particular case, I think that one risk is that the effort might collapse into a
morass of arguing about process - really, arguing about how to argue. Such
short cuts may deliver neither agreement nor speed.

Regards
Marshall

> 
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/pesci-discuss