Subject: RE: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWRWG proposal

From: [email-masked]
Date: Mon, 15 Dec 2003 14:19:36 -0500

Hi John,

I find that I must respectfully disagree with you.

> * While it may be difficult to do so, it is ultimately more
> reasonable to judge _IETF_ consensus on a procedural issue by
> surveying comments on a wide-participation list than it is to
> judge it from a narrowly-constituted WG

AFAIK, we don't have any effective mechanism to reach a large
percentage of the IETF population that doesn't select for some
specific group.

Any WG activity and/or process-specific mailing list (such as
poised, solutions, problem...) will select for people who have
the time and inclination to work on process-oriented activities.
However, they do allow everyone who is interested in those
discussions to participate.

We get, by far, the highest number of respondents when we
conduct polls at the plenaries, and perhaps those polls are
our best way to judge "IETF consensus".  However, they select
for people who can afford to attend the meetings, and they are
usually limited to simple (yes/no) questions.

We do not get a strong enough response to any IETF Last Calls
to believe that they reach a large representative sampling of
the IETF population.

> * Any decisions coming out of the WG will be subject to IESG
> approval.  If the IESG does not approve, then the WG becomes a
> waste of time.  If the IESG knows of things of which it will
> approve, then, if it believes there is some basis in community
> consensus, it is free to make the changes today.  That leaves a
> (probably very small, IMO) area in which the IESG possibly
> prefers to not do something, but might be persuaded by a large
> community consensus.  But, again, a narrow-focus WG is not the
> best was to demonstrate such consensus.

This assumes that the IESG already knows every possibility for
improving the IETF, and can pre-judge everything that might come
out of such a WG.  Personally, I trust the community to come up
with some good ideas that I would not come up with on my own.

The IESG does not have perfect knowledge of the IETF, nor do
we encompass the perspectives of all participants.  So, I believe
that wider community involvement in improving the IETF is needed,
not just community review, at an IETF Last Call level, of 
IESG-developed plans.

> * As Pete and others have pointed out, most of the things that a
> WG might decide to permit or require under this proposed charter
> are already within the scope of authority of a WG Chair ...
> assuming that the relevant AD decides to interpret the scope and
> authority that way.

There are two different sets of changes:

    - Changes that fall within the current bounds of RFCs
      2418 and 2026.

    - Changes that would require modifications to our BCPs.

I agree with you that the IESG can unilaterally enact changes that 
fall into the first category, and I think we should.  Some ADs are 
already running some experiments in their areas.  We're also forming 
the PROTO Team to do some focused work in this area, and to come
up with a set of recommendations to the IESG regarding what types
of experiments should be run and eventually what changes should be 
made.

I do NOT believe that it is the perogative of the IESG 
(hisory not withstanding) to enact changes that lie outside
the bounds of RFCs 2418 and 2026.  Those changes can only
be enacted through community consensus.  

I agree with you that there are some options, other than a WG, 
for achieving community review and consensus, but I don't see
other options that will allow for the breadth of community
input that a well-run WG could allow. 
 
> (1) Let's have those ADs who are enthused about transferring
> more authority and responsibility to WG Chairs, do it.

Within the bounds of RFCs 2418 and 2026, we are already working
on this.  Some ADs are already running experiments, and we're
forming the PROTO Team to provide a focused effort in this area.
There is nothing about the proposed WG that should delay these
efforts, and I do not think that the IESG can (or will) use 
"lack of community consensus" as an excuse for not improving
the procedures and tools that we developed without any community
involvement in the first place.

While "just do it" sounds very compelling, we don't want to cause 
confusion and/or create serious problems that will seriously delay 
work within the IETF.  So, we are "just doing it" more carefully 
than you might be suggesting.

However, I think that the community can (and should) push the
IESG to produce results in this area, as well as in the area of
early cross-area review.  

I will, personally, be extremely disappointed in the IESG if we 
can't show some significant progress in the following two areas
by ~March 2004:

    - Improving the scalability, openness and effectiveness
      of our internal procedures and tools, particularly 
      improving the visibility and control that WGs have
      over their documents in the later stages of document
      processing.

    - Improving the level of cross-area review that is done
      outside the IESG, particularly earlier in the process.

To me, significant progress would include some specific plans 
for improvements that may be implemented in 2004, early reports
from some ongoing experiments, etc.

> Just
> make an announcement about what you are expecting WG Chairs to
> do and that you will rubber-stamp that action, without delay,
> when it gets to you as AD. 

Some of this is already being done.

It isn't clear that individual ADs can run all of the experiments
that we'd like to see run.  

For instance, I'd like WG chairs to have the authority to temporarily 
suspend the posting privileges of disruptive mailing list participants, 
but that isn't something I can "just do", since it is not within my 
perogative to approve the suspension -- the whole IESG needs to approve 
it. 

Also, there are two ADs in most areas, so we need to reach some 
agreement with our co-ADs about what experiments will/won't be run 
within each area.  In most cases, this type of moderating influence
is probably a good thing.

> (2) The other major concern that has been voiced involves WG
> Chairs abusing their (possibly new-found) power.  But WG Chairs
> serve more or less at the pleasure of ADs.   An abuse can be
> discussed with the relevant AD (the procedures are pretty clear
> about that).  If the AD refuses to do anything, that situation
> can be appealed (that is less clear from the procedures, but,
> IMO, it would be completely rational for the community to
> consider recalling any AD who said "my nit-picking reading of
> the procedures doesn't permit an appeal in this case, so I vote
> to reject it without considering the issues").

I more-or-less agree that this should be sufficient chain of
accountability, but unfortunately there are some well-respected 
and outspoken members of the community who do not agree.  So,
we need to do some more work before we can any reach consensus in
this area.
 
> If, once we have the output from this type of experimental
> process, we conclude that the relevant BCPs need rewriting (as I
> suspect we will), that is the right time to form WGs, if needed.
> They will, at that point, have firm experience behind them to
> evaluate.   But, right now, I think the criterion for forming
> more WGs ought to be "there is evidence that we need to do X,
> and we can't even try that without a change in procedures".

I think that there is evidence that we need to give WG Chairs more
authority to control WG mailing lists.  I also think that we want
to give WG chairs the authority to hold the WG to a set of internal
WG processes that may include criteria for accpetance at various
stages and/or certain amounts of cross-area or expert review.

Some people say that RFCs 2418 and 2026 already empower WG chairs 
to do those things, but other argue that having WG chairs do these
things would violate RFCs 2418 and 2026...  People who have been
in my WGs and/or my WG Chairs training know where I fall, but 
my view is certainly not universal.  So, at the very least, it 
would be nice if our BCPs were less ambiguous about the responsibility 
and authority of WG chairs.

Margaret

_______________________________________________
mpowr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpowr

---

From: John C Klensin <[email-masked]>
Date: Mon, 15 Dec 2003 21:21:26 -0500

--On Monday, 15 December, 2003 14:19 -0500 
[email-masked] wrote:

> the time and inclination to work on process-oriented
> activities. However, they do allow everyone who is interested
> in those discussions to participate.

They do not.  They allow everyone who is interested in those 
discussions and can put up with the near-infinite N/S ratio to 
participate.  And that is a small subset of the number of people 
who are materially concerned with the outcome.

Please also note that, as soon as you say that we have no 
effective mechanism to get IETF community consensus on 
_anything_ (and you haven't said that, but you are getting 
close), then we either need to accept the notion that some group 
has oracular powers to determine consensus or you are proposing 
that we are out of business.   And, while there are members of 
the community who believe the IESG acquires oracular powers on 
installation, I don't... and I know you don't either.

> usually limited to simple (yes/no) questions.

I would certainly be very concerned if there appeared to be a 
difference of opinion on an issue between a large number of 
people at a plenary and a smaller number on a mailing list, 
despite the greater openness of a mailing list.  I would be 
especially concerned if the difference arose on a procedural 
matter rather than an engineering one.  And my concern would be 
independent of which side I found myself on.

> to believe that they reach a large representative sampling of

See comments above about inability to determine consensus 
without an Oracle.  Also note that I consider "not enough 
response to Last Calls" and "people comment lavishly on 
documents they haven't read" to be, at best, symptoms of IETF 
problems that ought to have high-order bits set.  I don't 
believe that IESG review, no matter how many hours a week people 
put in, can really substitute for either cross area checks by 
the community or review and discussion after reading documents. 
If the workflow is too high to make that plausible, then we need 
to attack the workflow (whether it hits IESG, WG Chairs, or the 
community first).

Whether they were good solutions or bad ones, the Huston-Rose 
and O'Dell-Klensin I-Ds of a year or so ago were intended to 
address the workflow problem.  Things that have been under 
discussion lately discuss ways of moving work around, but not 
ways to change the total workload to a level that the community 
can effectively manage and cope with.   And, yes, largely as a 
result, I've gotten impatient with process-diddling (or 
arguments about process- diddling) that don't address those 
basic issues of meaningful review and meaningful consensus.

>> consensus, it is free to make the changes today.  That leaves
>> a (probably very small, IMO) area in which the IESG possibly
> improving the IETF, and can pre-judge everything that might
> come out of such a WG.  Personally, I trust the community to
> come up with some good ideas that I would not come up with on
> my own.

I am _not_ suggesting or requiring that the IESG be the source 
of ideas.   I am suggesting that there are a lot of ideas 
floating around already (the ones represented in your I-D 
included).  I'm getting closer to offering some more.  I am 
suggesting that some serous triage of those ideas by the IESG, 
with the IESG really being willing to take responsibility for 
what they/you like and don't like, would be in order.   I'd be 
really pleased to see the IESG take the ideas that have been 
floating around and divide them into

	* "Good idea, let's do it"
	* "Terrible idea, we won't accept it under any
	circumstances"
	* The community needs to think more about this, work
	through tradeoffs, and advise us further.

Bluntly, if the IESG were to put everything into the third 
category, either because you (collectively) didn't have an 
opinion about what would be helpful and what wouldn't, or 
because you couldn't agree, or because any attempt to have the 
discussion deteriorated into nit-picking, then I think it is 
time to start firing IESG members.  And I'd like to see the 
community have more hints about who to fire.

If some significant number of things were assigned the first 
category, and were implemented, it might generate enough 
interest to get some valuable, but totally frustrated right now, 
people into the discussions about the third category and 
additional ideas.

> we encompass the perspectives of all participants.  So, I
> believe that wider community involvement in improving the IETF
> is needed, not just community review, at an IETF Last Call
> level, of  IESG-developed plans.

Margaret, the IESG regularly behaves as if it has perfect 
knowledge, not only of the IETF, but of everything that affects 
the protocol suite.  As far as I can tell, the IESG has 
concluded that its knowledge and understanding is great enough 
that it is appropriate for them to exercise a complete gating 
function on all important Internet innovations (and maybe all 
unimportant ones as well).   A decade or so ago, we could get 
HTTP developed and deployed, and even assigned a system port, 
without unanimous IESG agreement that it was a good thing and 
met all IESG criteria for protocol design.  To digress a bit 
further, there is a huge difference between saying "the IETF 
functions as a standards body and, if you want the IETF seal of 
approval, you must satisfy the community, and the IESG as 
representative of that community, that you have met the IETF's 
criteria" and saying "in order to do something that is fully 
functional on the Internet, you need IESG approval".  The IESG, 
with _no_ authorization from any procedural BCP or charter (even 
if such a document could grant that sort of authority), seems to 
be rapidly sliding toward the latter.  And that, IMnvHO, is bad 
for the IETF and bad for the Internet.

But, if the IESG can believe that it has sufficient depth and 
breath of understanding to set itself up for that level of 
gating function, then, sorry, but it is reasonable for the rest 
of us to assume that level of omniscience should extend to 
figuring out what the IETF needs.

On the other hand, if these things really do require community 
involvement, and I agree that they do, then I suggest the 
community, or the (declining) fraction of the community that 
cares and is willing to put up with the noise), has been 
involved since Yokohama.  The question is what the stopping rule 
is; when we shift from proposals and discussion to 
implementation.  I am suggesting, based partially by subjective 
estimates of participation drop-off and the number of new and 
plausible suggestions coming in, that "now" would be a good time 
to make that shift (and that it may already be some months too 
late).  And my problem with MPOWR, is that I don't see stopping 
rules, only an opportunity for more discussion, more generation 
of suggestions that may not be much different from those already 
on the table, and, finally, another review point at which you 
(and I _know_ you are not the worst offender by a wide margin) 
say "well, the IESG can't know everything it needs to know, so 
we need another discussion and another WG".   At the risk of 
sounding like, and maybe agreeing with, Dave Crocker, Yokohama 
was 17 months ago this week, I don't see any significant changes 
that have resulted from community discussion, so I have to 
question the value of further discussion of that type.

>> * As Pete and others have pointed out, most of the things
>> that a WG might decide to permit or require under this
>> proposed charter are already within the scope of authority of
>> a WG Chair ... assuming that the relevant AD decides to
>> interpret the scope and authority that way.
>
> I agree with you that the IESG can unilaterally enact changes
> that  fall into the first category, and I think we should.
> Some ADs are  already running some experiments in their areas.
> We're also forming  the PROTO Team to do some focused work in
> this area, and to come up with a set of recommendations to the
> IESG regarding what types of experiments should be run and
> eventually what changes should be  made.

Good.

> be enacted through community consensus.

I would like to agree with you.   I will do so the moment the 
IESG starts vigorously rolling back all of the changes it has 
made in violation of those documents and the boundaries they 
set.  Otherwise, I contend that the IESG can't both

	* make the changes that appeal to them, independent of
	existing BCPs and
	
	* not make changes for which there seems to be plausible
	community consensus, but about which the IESG cannot
	reach unanimity, by citing those existing BCPs as a
	reason.  From my point of view, other reasons, carefully
	explained and ideally identifying differences in
	position within the IESG and who holds which ones, would
	be extremely welcome.  But not either appeal to
	documents that the IESG feels free to ignore on other
	occasions or "death by sequential WGs".

Others probably have other lists, but, from my perspective, I 
would like to see the IESG roll back, as a start on change and 
evidence of good faith...

	(i) AD approval reviews, with arbitrarily long time
	allowances, between when a WG asks for a Last Call on a
	document and when the Last Call is issued.    We don't
	need to do it that way.  Yes, if a WG asks for an IETF
	Last Call without a good mutual understanding with the
	relevant AD, and the AD doesn't look at the document
	again until the Last Call is under way, the WG risks a
	nasty late surprise.  But the WG should be able to make
	that decision.
	
	(ii) No reviews of documents independently submitted to
	the RFC Editor that go beyond the "end run"  and
	"potential harm" criteria.  And no interpretation of
	"end run" as "hold publication until some WG, or
	combination of WGs, have completed their work, even if
	that is forever.  Disclaimers, yes.  Encouraging the RFC
	Editor to push back on authors for more clarification of
	where their ideas fit in the grand scheme of things,
	yes.  Deep holes into which to throw things, no.    And
	ignoring timeouts... no to that too: The IESG asked for,
	and negotiated, the current review process and the
	review process documented in 2026.  If the IESG doesn't
	consider the reviews important enough to do on a timely
	basis, then the IESG should figure out a way to get out
	of that business (which might include letting some
	things go and trusting the RFC Editor to decide).
	
	(iii) No IESG rejections of port or protocol assignment
	requests to IANA unless the IESG is able to reach
	consensus to reject and supply reasons to the requester
	that can be made public and that will withstand laugh
	tests.   If the IESG cannot reach such consensus, and do
	so quickly, it is a decision that this review task,
	which the IESG assigned itself, is not important enough
	and the request should go through.

Just examples, of course, and maybe not the most important ones. 
I may try to for another list, and more details, soon.

> input that a well-run WG could allow.

The problem isn't the running of the WG.  The problem is 
involvement by a significant fraction of the active, 
working-on-protocols or other substantive WGs, community.   It 
looks to me as if MPOWR is going to attract a subset of those 
who are (still?) involved in Solutions, and that is an 
unrepresentative enough group that it should make you as nervous 
as it makes me.

> forming the PROTO Team to provide a focused effort in this
> area. There is nothing about the proposed WG that should delay
> these efforts, and I do not think that the IESG can (or will)
> use  "lack of community consensus" as an excuse for not
> improving the procedures and tools that we developed without
> any community involvement in the first place.

I don't share your confidence.  Of course, I don't expect to 
hear "lack of community consensus".  Instead, I'd just expect 
the ideas to go swimming around the bottom of some rathole until 
the IESG decides that it likes them enough to stop nit-picking 
(or doing whatever causes things to be thrown into such holes).

> While "just do it" sounds very compelling, we don't want to
> cause  confusion and/or create serious problems that will
> seriously delay  work within the IETF.  So, we are "just doing
> it" more carefully  than you might be suggesting.
>

Ok.  We agree.  I consider these notes to be part of doing that 
pushing, even if not quite the way you might like.

> I will, personally, be extremely disappointed in the IESG if
> we  can't show some significant progress in the following two
> areas by ~March 2004:

20 months after Yokohama.

>       outside the IESG, particularly earlier in the process.

I would definitely consider those things to be worthwhile 
accomplishments.  Do you have, and are you willing to discuss, 
your contingency plan if you find yourself "significantly 
disappointed"?  To state that differently, if I believed we 
would be there by March 2004 (although I'd add a few other 
things to the list... hints above), I would be settling down and 
working on MPOWR, or whatever you suggested would get us there, 
rather than complaining in this way and proposing alternatives. 
After 17 months, I lack that confidence.   If you have a plan 
about what we do if I turned out to be right and no significant 
changes occurred by March, then I'm still willing to wait and 
participate.   But I am concerned that, come March, we will 
still be exchanging these sorts of notes and that little will 
have occurred of significance other than the expenditure of more 
time, bits, and hot air.

Moreover, as you know, I tend to be a lot more concerned about 
organizational behavior than about rule-structures.  The latter 
are, at best, an accurate reflection of organizational behavior 
and culture; they don't cause either.   If there are forces 
within the IESG that are acting to block progress in these 
areas, or that are likely to (continue to) ignore any rules the 
community sets, they need to be identified to the Nomcom a long 
time before March.

> from some ongoing experiments, etc.

My standards may be a tad higher, too.  If it were three or four 
months past Yokohama, yes.  But, for 20 months out,...

> It isn't clear that individual ADs can run all of the
> experiments that we'd like to see run.
>
> For instance, I'd like WG chairs to have the authority to
> temporarily  suspend the posting privileges of disruptive
> mailing list participants,  but that isn't something I can
> "just do", since it is not within my  perogative to approve
> the suspension -- the whole IESG needs to approve  it.

Ahem.   And who made the rule that the whole IESG needs to 
approve this?  The IESG.  Without commenting on whether or not 
it is a good rule or a bad one, you could get that rule changed 
by convincing the IESG and the IESG alone.  And, if you are 
sufficiently convinced that changing it is important, you could 
propose that to the IESG and, if you couldn't get agreement, 
identify to the community the IESG members who didn't like it.

> Also, there are two ADs in most areas, so we need to reach
> some  agreement with our co-ADs about what experiments
> will/won't be run  within each area.  In most cases, this type
> of moderating influence is probably a good thing.

Sure.  But I also keep being told that, increasingly, ADs are 
dividing up the work in areas and not having much involvement 
with each other's WGs.  Personally, I think that, if true, is an 
unfortunate trend.  But you can't have a "those WGs are yours, 
and these are mine, and we don't interfere with each other" 
model and control over each other's experiments and management 
styles.  One or the other.  And, again, the spirit of openness 
would permit the two ADs involved to come forward and tell the 
community "I favored the following experiment, and she didn't, 
and we couldn't even reach agreement on doing it with some WGs 
and not others".   Maybe the community would accept that.  Maybe 
the community would decide it wasn't important.  Maybe the 
community would retire one or both of you (via the Nomcom or via 
recall).   I'm not convinced that any of those would be bad 
outcomes.

>> Chairs abusing their (possibly new-found) power.  But WG
>> Chairs serve more or less at the pleasure of ADs.   An abuse
>> can be discussed with the relevant AD (the procedures are
>> pretty clear about that).  If the AD refuses to do anything,
>> that situation can be appealed (that is less clear from the
>> procedures, but, IMO, it would be completely rational for the
>> community to consider recalling any AD who said "my
>> nit-picking reading of the procedures doesn't permit an
>> appeal in this case, so I vote to reject it without
>> considering the issues").
>
> accountability, but unfortunately there are some
> well-respected  and outspoken members of the community who do
> not agree.  So, we need to do some more work before we can any
> reach consensus in this area.

And how will you decide when you have consensus?  Do you expect 
some poor sucker who gets the job of MPOWR chair to make that 
call?    Do you assume that more discussion between the people 
who are sure that 2026/ 2148 provide all of the flexibility and 
authority needed (at least assuming the ADs back people up) and 
the people are believe that documents would need to be rewritten 
in a major way will change enough minds for a clear consensus to 
emerge?  Is the IESG going to accept it when that WG Chair 
claims consensus or apply its own judgment?  If the latter, can 
it just apply that judgment now?

>> process, we conclude that the relevant BCPs need rewriting
>> (as I suspect we will), that is the right time to form WGs,
>> if needed. They will, at that point, have firm experience
>> behind them to evaluate.   But, right now, I think the
>> criterion for forming more WGs ought to be "there is evidence
>> that we need to do X, and we can't even try that without a
>> change in procedures".
>
> I think that there is evidence that we need to give WG Chairs
> more authority to control WG mailing lists.  I also think that
> we want to give WG chairs the authority to hold the WG to a
> set of internal WG processes that may include criteria for
> accpetance at various stages and/or certain amounts of
> cross-area or expert review.
>
> Some people say that RFCs 2418 and 2026 already empower WG
> chairs  to do those things, but other argue that having WG
> chairs do these things would violate RFCs 2418 and 2026...

Margaret, even a narrow reading of 2418 and 2026 -- much more 
narrow than the IESG has applied when it suits their purposes-- 
says that the ADs, and the IESG, has most or all of this 
authority.  I can find nothing in either document that says "the 
AD has to do all of this himself or herself".  So, if an AD says 
to a WG Chair (and the WG), "I want you to do X using your own 
best judgment.  When you do it, do it in my name and I promise 
to back you", the WG Chair gets the authority and _no_ 
procedures are being violated.  Now the community may decide it 
doesn't like that.   It might scream at the nomcom for the AD to 
be removed, or initiate a recall, or start burning people in 
effigy.   And it might be entirely rational for an AD to decide 
that he or she is to afraid of those outcomes to do anything. 
But the authority and ability to do it certainly exists.

> People who have been in my WGs and/or my WG Chairs training
> know where I fall, but  my view is certainly not universal.
> So, at the very least, it  would be nice if our BCPs were less
> ambiguous about the responsibility  and authority of WG chairs.

Sure.  But either

	* the IESG has to lead the community, change the
	documents, and take the heat, or
	
	* the IESG has to lead, propose a process with some
	stopping rules in it that will actually lead to
	consensus and results, or
	
	* we will be having this discussion in six months.

john

---

From: Ted Hardie <[email-masked]>
Date: Tue, 16 Dec 2003 08:05:12 -0800

There is a lot in John's original message, including a great deal of emotion.  Without
wishing to indicate a lack of interest or concern with the other points or
over that emotion, I've made comments on a few points below.

>
>They do not.  They allow everyone who is interested in those discussions and can put up with the near-infinite N/S ratio to participate.  And that is a small subset of the number of people who are materially concerned with the outcome.
>
>Please also note that, as soon as you say that we have no effective mechanism to get IETF community consensus on _anything_ (and you haven't said that, but you are getting close), then we either need to accept the notion that some group has oracular powers to determine consensus or you are proposing that we are out of business.   And, while there are members of the community who believe the IESG acquires oracular powers on installation, I don't... and I know you don't either.

On your first point, having focused groups allows the chairs to ask for (and sometimes
get) the conversations to stick to the points in the charter.  That can help the n/s ratio.
Having a system in which you have a staged series of lists (IETF for very broad discussion on
the nature of the IETF, solutions for discussions on what needs to be done, focused groups
for specific areas of work) does make for complex procmail rules, but it can help.  It
may not allow for everyone materially concerned with the outcome to participate, but
it does show people where to concentrate their efforts to match their interests. 

On your second point, I note the wisdom of not trying to get community consensus on
some things.  We don't pick folks for the IAB, as an example, by community consensus.
The IETF decided a long time ago to constitute a specific group for that task (the NomCom);
the rules under which the NomCom works are in the -bis stages of revision, but that
does not mean we changed to consensus for those decisions.  Community consensus
might pick different people, but the costs of that seem to be outweighed by the
benefits of the other process.

I personally believe that the work Solutions is discussing falls into two different
camps:  work for which small groups can go off and "just do it" and work for which
community involvement and buy-in is so critical that any change, even if functionally
perfect, would fail if done outside of the normal process because the community
wouldn't agree to work under a system it hadn't a hand in designing.

Scott's recent BoF on the new standards track is an example of the second; it is
clear to me that community consensus on this type of change is critical for the
change to succeed.  The EDU team seems to me an example of the former, as
the development of new training materials kind of falls into a "just do it" category.

We may disagree about where ICAR, PROTO, and MPOWR fall in those two categories,
but I think we agree that the two categories exist.  Getting more work on
the "just do it" category done now may be the biggest short term win.  It's
been hard to do for many reasons, including both the emotional attachment
people have to certain ways of doing things and the tendency of some us
(including me) to want to think about the whole system, including the
eventual mechanisms needed for ongoing change. 

>  I am suggesting that some serous triage of those ideas by the IESG, with the IESG really being willing to take responsibility for what they/you like and don't like, would be in order.

The IESG has publicly said that they/we would accept whatever change the community
decided on.  We have lost two members since that statement and gotten one new
one, but I think the decision stands.  We have and are trying to facilitate work on
ideas we think the community has agreed to discuss.  That's "triage" of a very different
sort, though.

>	documents, and take the heat, or

Speaking personally, I think what you are seeing is us, trying both to
listen to the community on the work that needs to be done and lead
a sometimes highly contentious community effort to create better sets
of systems for doing it.  However badly we're doing it, that *is* what I believe
our effort to be.   This is also us, taking the heat.

				kind regards,
					Ted Hardie

---

From: Eric Rosen <[email-masked]>
Date: Tue, 16 Dec 2003 11:15:17 -0500

Margaret> We get, by far, the  highest number of respondents when we conduct
Margaret> polls at the  plenaries, and perhaps those polls  are our best way
Margaret> to judge "IETF consensus"

This mystifies  me.  Unless the  room is filled  with people who  have given
careful thought to the issues, taking a poll of the room is unlikely to give
a useful result.  If you poll a  large room filled with tired people who are
primarily there as observers, are you getting informed and considered expert
opinions, or are you just getting a reaction to the personalities and to the
rhetoric?  

Polling  the  plenary is  only  useful  as a  way  for  the "leadership"  to
manipulate the outcome so that they can claim support.  So not surprisingly,
there  is always  a  dispute about  whether  the plenary  actually did  show
consensus.

>> to reject it without considering the issues").

Margaret> I  more-or-less agree  that  this should  be  sufficient chain  of
Margaret> accountability

I don't think so.  In the past I've successfully appealed WG chair decisions
to  the AD  by  demonstrating that  the  decision was  not  supported by  WG
consensus.  But  as the chairs get  more responsibility, there  will be more
possible grounds  for appeal,  and there  will be more  details that  the AD
needs  to know in  order to  judge the  appeal.  Appeals  will be  even less
effective than they currently are. 

At  the very  least, it  has to  be made  extremely clear  what  grounds are
appropriate for a chair to use when making a particular decision.

Harald has said that we should just trust to everyone's good intentions, but
of course that rather misses the point.

---

From: Alex Conta <[email-masked]>
Date: Tue, 16 Dec 2003 20:13:59 -0500

Please see inline

[email-masked] wrote:

>> [...]

The polls may in fact hide a superficial knowledge of the topic, and may 
reflect an immediate reaction to the eloquence, or wit of the person 
conducting the poll. Which is why polls in the plenary are not always 
the best indication.

>> [...]

This is extermely dangerous, and am against it!

Poeple that make just noise are ignored anyway, and do not need 
suspension of privileges.

Giving such a privilege to chairs is just creating even a better 
dictatorial environment than the one existing today, and a way to ensure 
that mailing list will be 100% chair-friendly. Expect then to see some 
mailing list called 'free-X WG', or 'free-IETF' !

>[...]
>>Chairs abusing their (possibly new-found) power. 

Chairs already have a lot of power, exacerbated by the right
to participate directly to the output of the chaired WG. Which
gives the easy key to progress in the WG: "have the chair as a
co-author of your spec".

Such a right does not exist in any of the other major SDOs I am familair
with.

>> But WG Chairs
>>serve more or less at the pleasure of ADs.  

This is a disturbing acknowledgment of a BIG problem, since it goes two 
ways - both that the ADs can fire a WG chair at will, and that the ADs 
can choose and keep a WG chair as long as they want.

>> An abuse can be
> accountability, 

So you yourself are not 100% sure about the chain. The problem is that 
the check and balances is fragile - to be mild - and too many times not 
working as it is. More power to the WG chairs, is going to further 
exacerbate an existing reality - the friends of the WG chairs have a 
better chance to succeed in a WG.

The check and balances mechanism need major changes or major 
reinforcement, before any more power being given to the WG chairs.

> but unfortunately there are some well-respected 
> and outspoken members of the community who do not agree. 

Luckily.

>  So,

Maybe you just suspend the posting rights to the outspoken ones...

> authority to control WG mailing lists. 

Cenzorship made it easy. NOoooooooooooooooooooooooooo.

 >  I also think that we want

There is enough room for wrong doing right now, that would just make 
more room.

> [...] it

I certainly agree with that.

Alex

> Solutions mailing list
> [email-masked]
> http://eikenes.alvestrand.no/mailman/listinfo/solutions
> 
>