Date: Fri, 12 Oct 2001 10:15:57 +0200
From: Harald Tveit Alvestrand <harald(_at_)Alvestrand(_dot_)no>
Message-ID:
<930592431(_dot_)1002881757(_at_)[192(_dot_)168(_dot_)1(_dot_)31]>
| Since 199x, the IETF's process issues have been handled by a couple of
| working groups, POISED and POISSON.
There was also poised'95 (just to pick nits, so I am allowed to send to
the ietf-process list ... This is clearly relevant to the poisson WG,
so sending to its list has to be relevant, and apparently the trash bag
of ietf lists is important to this as well...)
| POISED finished its initial work of defining the IETF process and was
| closed down;
And a day later (or the same day), poised'95 was created.
When that "finished" ...
| POISSON has tackled issues that have occured since that time.
This should be some kind of hint (even the mailing list has remained
basically stable throughout that time, it is still
poised(_at_)(_dot_)(_dot_)(_dot_))
If you were just proposing that it is time to kill poisson and create
a new WG to take its place (because poisson has filled up too much I-D
space, or is reaching some other limit), I wouldn't mind - meaningless
change doesn't tend to do too much harm. But this isn't anything like
that.
| It is a widespread impression that the process currently is not working
| terribly well.
That may be, but this is no improvement.
I know that there have been IESG members (past and present) who have
disliked the poisson working group, as it has failed to rubber stamp
proposals that (to the ADs) are obviously the right thing to do.
I have disliked other WGs that have failed to rubber stamp my proposals
which were (and still are...) obviously the right thing to do (to me).
That doesn't mean I'm about to propose killing any such WG in retribution.
Aside from that poisson has worked about as well as most other WGs that
are around - and probably still would be, it it was allowed to actually
go ahead and do some of the work it should be doing, rather than being
stifled by "we don't want to open that can of worms just yet" all the time.
| Debates in the WG tend to be wide-ranging, contentious, inconclusive and
| not terribly well informed; many members of the community are staying away
| from the WG because they do not relish the style of dialogue; it takes a
| very long time to get consensus on even reasonably simple things.
That cannot possibly be helped by starting the debates in a wider community,
it can only be made worse. While exposing process issues to a wider group
can't hurt the overall process, doing that in the name of making things run
more smoothly is not rational. Not even close.
What's more, the "style of dialogue" on poised has in general been reasonable,
certainly better than on some other WG lists (if not as good as all of them).
It has tended to be orders of magnitude better than the IETF list. If there's
any list to stay away from in the IETF, it is the general IETF list.
| These are all consistent with the characteristics of long-lived working
| groups; in other areas, the Right Thing is most of the time to close the
| working group and start over.
|
| This proposal suggests the same thing for POISSON.
Maybe I missed something, where is the "start over" in this proposal?
| The proposal is funded on the idea that process work is more like an area
| than it is like a working group;
except that, as you point out, it is too small to be an area. Then remember
what areas are/were .. they were originally working groups, which outgrew
themselves and split into parts - the parts then reforming as areas. That is,
an area is what happens when a working group gets too big. Since, as you
correctly point out, this working group has not become too big, it isn't
tackling so many different issues, even thinking of it as an area is starting
out down the wrong path.
| Proposal components
| -------------------
| Procedural issues are a task of the General Area of the IETF.
| The IETF Chair will act as AD for this area, and perform the usual
| functions of process management for the process-making process.
That's a restatement of the status quo, no problem there.
| There will no longer be a special IETF process list; instead, issues of
| interest to the community will be raised on the general IETF list.
| This list will be used for pre-charter discussion of new items, as well as
| general process issues.
That's a terrible idea however, for lots of reasons. Aside from the IETF
list being must better to avoid than any other list in the IETF, it is
directly counter productive to actually getting anything done.
| When items of a significant nature are to be considered, working groups
| will be chartered as needed.
Aside from Dave Crocker's point - the delay - this also has the hidden
pre-condition "and the IESG thinks the item is a good thing". If the
IESG doesn't like the idea, no WG will happen (probably not even the first
BOF on the formation of the WG, let alone the currently apparently mandatory
2nd BOF at the next IETF to formulate a charter).
A big attraction of the current setup is that it allows the poisson WG
to undertake work that it decides it ought to do, and once finished that
is WG product, which is much harder to kill.
The individual submission, and 4 week last call is never going to work for
anything that relates (in any significant way) to the IETF process - as you
point out, may of the issues are contentious, and result in opposition.
That's going to mean that there will always be objections at the last call
stage to any individual submission, which will always be enough for the IESG
to decide that there is no consensus for the doc, and relegate the thing to
the bin. Occasionally prehaps instead propose a WG to discuss the matter.
Simply leaving poisson around where it could have been discussed from day
one avoids all of that delay, and also allows us to avoid the illusion (even
if no more than that) that the only things the IESG allows the IETF to
discuss are the matters it approves of.
| Proposal discussion
| -------------------
| The existence of formalized, short-term working groups may help with the
| problem of "WG rot" that has characterized the POISSON effort.
The only real rot in poisson is that it isn't being allowed to do any work.
It isn't like some other WGs have been where camps form, and issues proposed
by one camp are immediately attacked by another, regardless of merit.
| The increased focus may also help with the problem that POISSON has had
| with meeting at IETFs: when it is scheduled opposite other meetings, there
| will always be participants who have no possibility of attending; in
| particular, most of the IESG will be busy in other meetings.
| More focused WGs will not need so much attention.
Not true at all. There's only a need to attend a poisson meeting if it is
to discuss something of interest to the person considering attending. If the
issue is of importance, then attendance will be desirable (or required)
regardless of the name of the working group. What this might do, if
multiple groups get formed in parallel is allow the times when the issues
are to be discussed to be more plainly defined - by having separate discussions
in separate slots the timetabling can be more obvious (and the scheduling
can be optimised for those who want to attend). The same could be done
for poisson WG meetings of course (if one ever happens again) - there can
easily be multiple slots scheduled, with a particular issue set to be
discussed in each slot.
Of course, there's always the other insidious possibility, that were
multiple process issue groups formed, they could deliberately be scheduled
against each other, to prevent people from attending both. Keeping just
a single WG avoids even the possibility of this happening, and increases
the overall appearance of appropriatness.
| Not having a special "process" list is one of the more uncertain aspects of
| this proposal.
| The advantages of using the general IETF list are:
| - A great number of relevant people are already present on this list
and lots of others have already decided that the list is a wasteland and
avoid it.
| - It is better linked into the community than a process-only list is likely
| to be
That's true ... so sending announcements of issues of concern to the general
ietf list (or even ietf-announce which is probably a better idea) when they're
being discussed on a specific process oriented list (like poised) would be
a good idea - inform the community when something is being discussed, so those
interested in just that particlar issue, but not process issues in general,
can subscribe to the list until discussion dies down, then leave again.
That would have been a better approach here, make this proposal on the
poised list, and announce it on ietf-announce for anyone interested to
know it was happening.
Actually moving meaningful discussion onto the IETF list is not a sane thing
to want to do - if it were possible, it would be better to close down that
list. Of course, if the underlying proposal is to stifle community driven
progress (or protest) then perhaps it is exactly what should be done.
| The disadvantage is that all participants will have to read process-related
| discussions whether they are interested or not.
Yes. And tolerate meaningless messages from those having a boring day
who aren't really interested, but just want to see their name in the From:
header of a message...
| There is a very real danger that documents that are too small to require a
| working group will get inadequate review.
Yes.
| This can be ameliorated by:
| - discussing the documents on the IETF list
which won't help.
| - using 4-week Last Calls, with pointers to appropriate mailing lists
the point of a 4-week last call is to make sure everyone gets a reasonable
chance to object to documents that haven't received much review - ie: to make
it as easy as possible to kill all the nonsense. It doesn't help actually
get almost anything done (just occasionally something which is so obviously
the right thing to do can get written by an individual and through the
process quicker this way than forming a meaningless WG, aside from that
the 4 week last call is just a way to kill stuff).
| - the ADs requesting independent review of documents
That can happen wherever it comes from.
| The General AD will monitor all 3 relevant lists, and make a decision on
| the proposal no earlier than October 19.
Hmm ... an individual proposal, with 1 week "last call" ... That's an
interesting concept.
What we should be doing is asking poisson to actually do some work, instead
of just continually telling it not to do anything. One obvious "some work"
would be to consider possible mechanisms for handling IETF process issues,
whether the current method is adequate ("running code" and all that), or
whether it ought to be updated somehow, and if so, how. Your proposal could
then be input into that discussion, instead of an ultimatum.
Kill this idea.
kre