Re: IETF Process Evolution

[Ted Hardie <[e-mail]>]

Thanks to John for his long and considered note.  Two short responses inline before
I have to sign off for the weekend:

At 12:36 AM -0400 9/17/05, 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). 

I agree with the properties of "fairly well-defined problem, fairly
well-defined solution space", but I see I missed making one of
the crucial points about IASA.  It did not use a working group
process, but that did not eliminate the inherent problems in
getting a large group of people onto the same page about change--it
moved them into plenary, onto the IETF mailing list, and into
the hands of the IAB and IESG to judge consensus.  That it worked
is a testament to efforts on the part of Leslie, Harald, the doc authors,
and the community, but it was far from easy.    There
were also serious concerns throughout about the openness of the
process, and I believe that only the personnel and contractual nature
of some aspects of the negotiation justified the process in the eyes
of some long-time IETFers.

I don't think the same justifications for a non-WG process exist here, and
until PESCI produces its output, we won't know if there are other justification.
I appreciate Brian's effort to not rule out any specific onward process from
PESCI, but I remain pretty concerned that the presumption seems to be it
skips the usual mechanisms for public participation.   My own experience is that
the ad hoc replacements aren't easy, and they stress already overloaded
aspects of the existing system.


>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.

I did not mean the IESG, and thanks for the opportunity for making
that clear.  I meant the community when I said "those who will use
the outcome".


> 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.

I agree.    If process change produces something that works for
the community, there will be community volunteers to fill the roles
created.  Limiting the change to rolls for which the current set of
volunteers would also volunteer would be a terrible constraint.

			regards,
				Ted Hardie

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