Re: IETF Process Evolution

[Leslie Daigle <[e-mail]>]

As I've said on the other occasions I've had to see versions
of Brian's proposal,

> My completely personal opinion:
> 
>     . it's reasonable for Brian to appoint
>       a committee of whomever he wants, by whatever
>       process he wants, to do whatever he wants
> 
>     . the outcome of that committee *MUST* fit in
>       with our existing process:  the IETF cannot
>       be constrained to accept the output of that
>       committee unless it has gone through full
>       IETF review and existing process 


which I think is largely in agreement with what Ted and John
have said, and isn't disagreeing with the text of Brian's
statement.

 From here, the devil is in the implementation details, IMO:

	. how Brian will identify folks with (both) sufficient
	  involvement and time to devote to produce a draft by IETF64;

	. how to have the public review of/input to any proposal(s) that
	  has sufficient community engagement without ratholing (i.e.,
	  simply deferring all the aforementioned unsuccessful
	  points of WGs)

The first point is an oblique suggestion that we have patience
in IETF64; the second is a suggestion of requirements.

Leslie.

John C Klensin wrote:
> Ted,
> 
> I finding myself agreeing with you in many ways, but probably
> for different reasons.  I'm trying to better formulate the
> differences instead of (or at least before) posting something
> incoherent, but, in the meantime...
> 
> --On Friday, 16 September, 2005 16:45 -0700 Ted Hardie
> <[e-mail]> wrote:
> 
> 
>>At 2:28 PM -0700 9/16/05, Dave Crocker wrote:
>>
>>>And since all other public development efforts for process
>>>change have frankly fallen flat, as Brian has cited, what is
>>>your basis for believing that a working group charter will
>>>somehow make yet-another public process more effective at
>>>developing a specification for change?
>>
>>Possibly I'm wrong in this, but I believe that the public
>>process works when the community cares about the outcome.  The
>>IASA work is done, and I believe it is a success because
>>enough people cared about the outcome to make it one.
> 
> 
> I think there are two conditions.  The first is caring and the
> second is a very narrow and specific focus, with serious thought
> and debate going into that focus.  There were good things about
> the AdminRest->IASA process and bad things about it, but there
> was a clearly-defined problem to be solved and a process that
> produced a solution.  Dave believes, I think, that, as it worked
> out, it was the wrong problem to be solving at the time and I'm
> at least sympathetic to that view, but that doesn't change the
> properties of "fairly well-defined problem, fairly well-defined
> solution space, mechanisms that were fairly open at critical
> times (although, IMO, not nearly open enough at others).  
> 
> In that regard, I see the difference between, e.g., IPR and
> Poisson as being the difference between creating a WG with a
> very specific focus and problem to be solved and creating a more
> or less standing WG and telling them to look at Process issues,
> figure out what needs to be done, and do it.   As we could all
> predict from our experience with technical/engineering WGs with
> narrow and well-understood scope versus those that are expected
> to figure out what the problem is before trying to solve it, IPR
> was productive while Poisson spent a lot of time in the weeds.
> 
> In that context, part of what concerns me about the PESCI idea
> is that the is no clear problem definition.  If there were a
> clear and concise problem definition on which there was obvious
> community consensus,  I wouldn't worry much about the committee
> -- the problem definition would provide a good platform from
> which to evaluate success.   If it were a
> spontaneously-occurring design team in which a few colleagues
> got together to sort out a problem and generate a proposal that
> would be treated as an individual submission with not more
> authority than any other such submission, I wouldn't worry about
> it: as Dave points out, some of our best work comes out of such
> teams.  But this one appears to represent neither of those
> cases.   But this is neither of those cases.  Instead, either
> the problem area is open-ended or there are ideas that will
> steer it that Brian has not made public (I assume from his note
> that it is the first).   The group isn't going to be
> spontaneous, it is going to be hand-picked by the IETF Chair and
> presided over by him and that will give it and its product a
> certain level of authority. 
> 
> There is also actually a difference between "sufficient people
> who care to do the work" and "a sufficient number of experienced
> and relevant people in the community who care and are involved
> enough to be sure the work is right".  That, to me, is the area
> of greatest difference between process WGs and engineering/
> specification ones: with the latter, most of the people who get
> in there and do serious work are directly involved with the
> quality of the outcome (whether they do well or not is a
> separate matter).  Process WGs tend to draw a disproportionate
> number of people who are interested in and care about process
> but who are not otherwise significantly contributing to the
> IETF's technical work.
> 
> So...
> 
> 
>>As I said at the beginning of this thread, I believe using
>>PESCI to scope the work and develop support for is fine.
> 
> 
> I'm even concerned about that for the reasons above.
> Agenda-setting is an important part of the process and the
> historical observations about the importance of being the party
> who picks the battlefield or moves first are relevant.  If the
> group were to be chosen via a more open process, including some
> "advice and consent" by, e.g., the IESG or IAB or Nomcom, than
> Brian apparently contemplates, I'd feel better about it.  
> 
> But...
> 
> 
>> I'm
>>deeply concerned, however, about it doing the development work
>>itself, as a process in which selected volunteers replace the
>>public work of those who will use the outcome.
> 
> 
> While we agree, I think, about the risks of the "selected
> volunteers" part, I'm not sure whether we agree or not on the
> rest of the sentence.  If, by "public work of those who will use
> the outcome" you intend to suggest a process that is controlled
> by the IESG, I don't think that works either.  The current IESG
> was chosen, successfully or not, in line with the current
> procedural model and it and its predecessors defined the way in
> which that model is interpreted and used.  That selection
> process should not bias the outcome of the development process
> toward one with which the IESG is comfortable.  IESG input is,
> IMO, very important about what is workable or not and why.  But,
> if we are going to redesign procedures, I think there has to be
> a realistic possibility to making procedures that work for the
> community and then selecting an IESG (or its successor) to
> match, rather than selecting procedures on the basis of a good
> fit to the current IESG.
> 
> best,
>    john
> 
> 
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf