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

[John C Klensin <[e-mail]>]

--On Monday, 15 December, 2003 14:19 -0500 
[e-mail] wrote:

>
> 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.

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.

> 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.

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.

> 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.

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.

>> * 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.

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.

> 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.

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.
>
> 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.

Good.

> 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 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.

> 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.

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.

>> (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.

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.
>
> 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.

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.

>     - 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.

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.

> To me, significant progress would include some specific plans
> for improvements that may be implemented in 2004, early reports
> 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,...

>> 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.

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.

>> (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.

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?

>> 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...

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



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