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
<hardie(_at_)qualcomm(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf