Re: IETF Process Evolution

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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
<hardie@xxxxxxxxxxxx> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]