Hi John,
I'm getting more and more troubled by the PESCI process, at
least the portions of it that I can observe by reading the
messages on the public list. I've had some of these concerns
since the process was initiated. I decided to remain silent,
at least in public, about them on the pragmatic theory that
nothing else was working so this was worth a try and I didn't
have a better proposal.
I guess that this was part of my motivation for agreeing to be involved in
the PESCI team. Add to that the belief that something needs to be done.
But, judging from the I-D and the list discussions, PESCI is
tending to wander off into some very familiar weeds.
Yeah. Those weeds are certainly attractive.
We have been actively struggling to stay out.
Worse, as
I had feared, it seems to have preempted virtually all of
whatever energy was left in Newtrk (other than the
"cruft-killing" exercise) while circling around to many of the
same issues from a more restricted perspective. I don't think
what is going on has yet crossed over into abusive behavior,
but it is probably time that the community examine this
carefully, perhaps at the BOF if not sooner.
Is PESCI characterizing the current process or inventing a new
one? Is it about principles for the IETF or principles for
process change?
In as much as it is attempting to set out principles that should guide
process change, it also sets out principles of the IETF itself. Thus, a
principle of process change might have been expressed as "respect the
principles of the IETF" but that would not have been hugely helpful
without some additional granularity.
Three questions have to be asked:
- what are the principles of the IETF?
- what are the principles that must be applied during process change?
- what are the principles that should be enshrined in the revised process?
How much of the efforts of the Problem
Statement effort, Newtrk, Poisson, Poised, etc., etc., is it
replaying without any real mechanism for injecting new
insights? Do we have a model for getting from whatever it
produces to real changes that are focused on IETF's critical
path that doesn't involve more elements of "the IETF Chair
decides"? Is the "team" structured to be, and demonstrating
that it is more effective at, figuring out what that critical
path really is than a number of predecessor efforts have been?
Can't say.
From my perspective, this is an attempt to separate previous attempts at
isolating problems and solving problems, from an understanding of what
needs to guide the process (metaprocess) of isolating problems and solving
problems.
It seems to me that the weed-entangled rat-hole that has been entered in
the past has resulted from an attempt to fix too many problems at the same
time, while attempting to protect too many sacred cows. We lack stepwise
forward movement, and we lack clarity about which principles we must hold
dear, and which are "up for grabs".
Of course, my objectives may not be the same as others in the PESCI team.
If this were an ordinary design team effort, even one with
minutes and an open list, most of those questions would be
premature: we would wait for the results and then make
judgments on that basis.
AFAIK an "ordinary design team" does not normally have minutes or an open
list. usually, it sits in a huddle and produces an I-D. Sometimes it has a
charter and sometimes it doesn't.
The output of an "ordinary design team" is never more than grist to the
mill. I certainly don't expect the I-D we have produced to be in any way
special. On the other hand, it *is* an I-D that can form the basis for
discussion.
But it isn't such a design team: it
is a more or less formal effort convened by the IETF Chair,
with members selected by the IETF Chair using criteria
determined by the IETF Chair, and so on (see Addendum).
Agreed. But I don't see what else you expect the IETF chair to do. Should
he sit there and wring his hands, or should he attempt to kick-start some
discussions?
I would like to point out (as I always point out in my working groups)
that a design team is just a design team. Other people are particularly
welcome to form design teams and to discuss the issues at hand privately
and publicly.
Design teams should, on the whole, be fairly short lived. They are put
together to get some focus on an issue, and to produce work that can then
be discussed, rejected, modified, or accepted.
From formation to I-D submission was just three weeks for the PESCI team.
Now you have an I-D that can be discussed on a dedicated mailing list, and
a BoF has been convened specifically to advance the discussions.
If the
community thinks the process is working well despite those
complications, so be it. I'm not convinced and I'm getting
concerned.
I'd like to understand your concerns better.
Brian, since PESCI is your show,
You may think that. Brian may think that. But I am not so easily bought.
could you reflect and comment
on at least some of this before we hold a BOF and plenary
presentation... a BOF that, were this an effort that was not
driven by the IETF Chair, might well not be considered
coherent enough to get meeting time, much less plenary time?
Ah. That is a valid point.
The issue was, I think, that having produced an I-D we asked ourselves
"what next?" "How can we best facilitate further discussion on this
topic?"
Mailing list is a good idea. But why not get some face-to-face time?
-----------------------
Addendum: Examples of why this team needs to be considered as an
extraordinary procedure, created by extraordinary procedures
and without clear community consent, and cannot be considered
as an "ordinary design team"....
In no particular order...
(1) Design teams tend to self-constitute although they can be
selected. When they are selected by a WG Chair or AD, the
membership criteria are usually clear and then followed. In
this case, membership selection was filtered based, in part, on
the participants not being an activist and, specifically, not
having current drafts for reform. Yet the organizer has a
reform draft, and is generating new versions of it, and is an
exception. (20050923)
I agree with your characterisation of this DT as far as it goes. I
disagree with your characterisation of other DTs.
DT membership is usually limited to a small number of people who believe
that they can work together to a common goal with short-term milestones.
In my experience, when the team is constructed to include a set of people
with a common interest, but without this additional constraint, the result
is pretty disastrous, or else a compromise of such large proportions that
the resulting work is next to useless.
(2) We try to avoid situations in the IETF in which the same
person occupies so many roles as to be, even potentially, the
sole determiner of what occurs. We tend to use pejorative
terms like "acting as judge and jury" or "conflict of interest"
to describe such situations, although neither term is precisely
correct. But, in the instance of PESCI, we have a single
person who:
* Has a known and strong position on how the standards track
should evolve
* Organizes the group
* Chairs and steers the group (the recent 2005.10.24
13:23:22 note is a fairly strong example of "steering")
* Takes a strong leadership and advocacy role in the
discussions themselves.
* Decides, as AD, that the group gets to use a
semi-official IETF mailing list
* In organizing this as a BOF (or whatever it is), ignores
long-standing conventions that we don't just ignore an
existing working group (NEWTRK) whose agenda and mission
clearly overlaps the new effort. Normally, when new
efforts come along to organize a design team that falls
within the scope of an open and putatively-active WG, the
results of that team are referred to that WG, rather than
being discussed and processed separately.
* Decides, as AD (albeit by finding two other ADs to serve
as temporary proxy "Acting General Area ADs"), to allocate
BOF time at IETF, while the relevant WG (also the
responsibility of the same AD) does not meet. Sam's
comments (20051013, 20051019) are helpful in mitigating
this, but stop well short of the "unless you get your act
together, you aren't meeting at IETF" that is usual with
similarly-wandering pre-BOF discussions.
* Chairs the BOF
* Indicates that, when IESG votes come up on the subject,
he will recluse himself. But we are developing a funny
definition of "recluse" for a consensus-based, rather than
voting-based, organization. It now seems to mean that
someone can abstain from voting, but can participate in
discussions and try in every way possible to influence
decisions before a vote is taken. I think that definition
is a problem; I note it is one that PESCI does not seem to
be addressing.
Long list.
Not sure where it is going.
Do you see the chair's job as a passive role or an active role?
Is he responsible for enabling discussion or stimulating discussion?
Should he offer his opinions and experience or stay mum?
Wrt NEWTRK, PESCI considered the overlap and believed that NEWTRK is
important and should be allowed to progress its work. We wrote:
Newtrk issues are in scope for the process change but we should
allow Newtrk to work - there maybe some opportunities to provide
input to newtrk through the principles we propose here.
If you believe that the PESCI I-D should be discussed within NEWTRK I
can't see any harm in that provided it does not derail the useful work
that NEWTRK is doing.
(3) The "team" is expected to report at the Plenary, partially
on the basis of its BOF meeting, but the BOF ends only one
50-minute break before the plenary. Not exactly time for the
team to meet, carefully consider the discussion at the BOF, and
prepare a report. Indeed, while it is reasonable to hope for
something else, this would appear to be a setup for the "well,
we just got a lot of input and are thinking about it, stay
tuned" reports that characterized the admin restructuring
process.
Yes. My concern too.
Not sure what to do with this.
In my opinion, it is valuable to have a forum to discuss the PESCI draft,
and a "BoF" will provide such a forum.
Not everyone will be able to attend the BoF, and the plenary has a "right"
to hear what is going on.
The timing is far from ideal and gives everyone a headache.
(4) We still don't have any real idea how the results of PESCI
will be interpreted and processed. Given the experience of
previous "process" efforts, clear community consensus is
unlikely to emerge from a 15 minute presentation and discussion
at a BOF, nor it is likely that one can be synthesized from
that discussion and discussed on the mailing list before it is
presented, possibly for action, at the plenary. Will we see a
plenary presentation, followed by another IETF Chair
announcement? I hope not, but fear that may be the direction
in which things are trending.
Well, a good way to step in to this would be to discuss section 6 of the
I-D in some detail now, and on the PESCI-discuss list. Section 6 proposes
some next steps. Note that these next steps are not a proposal to develop
process change, but a proposal to develop a process whereby process change
can be made.
There seem to be three distinct proposals:
1. That a metaprocess is needed that will govern all process change
2. That such a metaprocess should be developed by a design team
with open input from all concerned parties
3. That consideration should be given to which elements of IETF process
are most immediately ripe for change.
Perhaps you can comment on these proposed next steps while also commenting
on the over-arching value of defining principles that would underlie the
development of a metaprocess and any individual process changes.
John, as should be apparent, I have not been closely involved in IETF
process change before although I have participated in (suffered from?)
some pilot schemes in the past. I see myself as a user of IETF process who
has at times been frustrated by the process and at times benefited from
it. My principal objective is to be able to further the work of my working
groups and to see an IETF which is more able to grow and react to rapid
changes in Internet technology.
Having found that IETF process change is generally slow to happen and
fogged by overly wide debate, I want to see some focus applied to
resolving broken process now. This does not mean that I think that the
wider discussions are not valid, but there is a clear need to fight fires
as well as plan for the future.
Cheers,
Adrian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf