On Sat, 13 Oct 2001, Keith Moore wrote:
> Neither POISSON nor any working group gets to do what it wants to do
> when it wants to do it. All topics have always needed IESG approval.
while this is true, neither Poisson or its predecessors has ever been
quite like any other working group. in my experience IESG has felt
considerable pressure to follow the direction of Poisson, and some
reluctance to object to Poisson discussing a particular topic.
The issue is not whether POISSON discusses any particular topic but what
is the result (actions after consensus) of that discussion, regardless
of where it took place.
The issues are far broader than that. We are talking about dismantling
poisson and about what might replace it in its absence.
Whether chartered for that purpose or not, poisson served as a public
sounding board for problems with our processes. The number of problems
that were aired in this way illustrates a need for better means of
resolving these problems.
I sympathize with those who think that poisson is no longer terribly
effective, but I don't think that the mechanism proposed to serve in
its absence is sufficient.
Assuming that's what you meant, you seem to be suggesting that because a
discussion took place nominally within the venue of a working group,
that gives it some greater standing than if the same discussion took
place on the general IETF mailing list. I disagree.
That's rather an odd position. First of all, IESG has a difficult time
ignoring the output of *any* chartered working group - even if it's
garbage (as happens once in awhile). Poisson would not be an exception
to this rule even if it did produce garbage - not that I can recall an
instance of that. Second, in my experience from having served on IESG,
several IESG members were indeed sensitive to the awkwardness of refusing
to allow the poisson WG to make recommendations about process that IESG
doesn't like.
furthermore there's an inhernet problem with IESG demanding that it have
tight reign on a WG that specifies the process that IESG must
follow.
This issue is only interesting to the extent that you believe the IESG
does not already control POISSON.
Clearly it has not controlled discussion on poisson, as several issues that
have been embarassing to IESG or its members have been aired there with no
evidence of censorship (in contrast to some working group discussions).
And this discussion has been useful for the community. However, one might
conclude that pulling the plug on poisson is an attempt to squelch such
complaints. I don't believe that, but I do believe that the complaints that
we've seen on poisson are indicative of more general problems that need to be
addressed.
It appears that we need better mechanisms for quickly dealing with
each of two conditions:
1. process problems which are not addressed in our current documents
2. alleged violations of process on the part of those who are
running things.
both of these mechanisms need to have clear and publically visible ways
of raising the issue, and inviting public comment where appropriate.
Personally I'm in favor of the IESG doing its best to do what is
needed at the moment its needed. If it needs further review after that
then we do that, through a working group or whatever. Isn't this part
of the reason why we have the IESG?
IESG is already spread too thin trying to do technical review and area
management. and as for having IESG be critical path for appeals, in my
experience it's not very good at that - it's too busy (and therefore
too slow) and it's almost inherently too biased. IESG might be okay
at handling disputes between WG management (someone not on IESG)
and a WG participant, but it is *really* taxed by trying to do a fair
job at handling disputes between IESG participants and other parties.
I don't doubt the intentions of the IESG members, but political realities
make it very difficult for any IESG member to admit that another IESG
member may have violated process.
I have no particular opinion on our appeals process, having no direct
experience with it. I'm not inclined to participate in changing
something I don't think is broken, but I'm certainly open to being
convinced that something is broken.
I've seen it from the inside.
I'm still of the opinion that the general ietf mailing list is a clear
and publically visible way to raise and discuss, inviting public comment
as needed, any such issues. I do not (yet?) understand why the poised
list is special in this regard.
It was special because at one time it had a charter to work on process
issues, and because it became the well-known forum for discussing such
issues. I'm not saying that Poisson has to stay in place, or even that
the main IETF list is not a good place to discuss such issues. What I'm
saying is that we have problems which cannot be satisfactorily addressed
merely by telling people "bring this discussion to the IETF list".
Keith