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