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

From: Pete Resnick <[email-masked]>
Date: Fri, 12 Dec 2003 14:41:25 -0600

On 12/9/03 at 5:02 PM -0500, Scott Bradner wrote:

>>The broad goal of this WG would be to shift more responsibility and 
>>authority to WGs, while ensuring appropriate accountability to the 
>>IETF as a whole.
>
>I have not seen a consensus that any such a shift is needed or a good idea.

I thought I heard a good deal of comment that shifting some 
*responsibility* to the chairs was a good idea. On the other hand, I 
agree: I certainly heard no consensus about shifting *authority*.

>I do think that a focused discussion on the role of the WG (and WG 
>chair) in the context of the IETF process is a "good idea."

I think that discussion may be a good idea.

>And, I think that  having that discussion in the context of an IETF 
>WG is a reasonable way to proceed

And on that I disagree in the strongest possible terms. I think this 
is a phenomenally bad idea.

Right now any AD can, of his or her own choosing and without any 
change in 2026 or 2418, decide to make their WG chairs responsible 
for the technical writeup of documents, resolving last call issues, 
and shepherding of the document through the IESG including resolving 
discuss issues. An AD can choose to do this now without asking the 
IETF for any consensus whatsoever.

Personally, I think this would be a good thing for an AD to do 
anyway. It certainly has every appearance of addressing the workload 
problem and some more of the transparency problem.

This is not worthy of a WG. It is worthy of implementation.

Having discussions on whether or not it would be a good idea to 
increase the powers and authority of a WG or WG chair might be 
interesting. Having ongoing discussions to decide whether or not 
increasing the responsibilities of WG chairs is working out (once 
started; see previous paragraph) is fine. But forming a WG when there 
is no need for documentation of some of these straightforward 
procedural changes is, IMO, silly. Forming a WG to produce a document 
to discuss this is simply delaying, and delay is something we've seen 
more than enough of.

pr
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

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

---

From: Ted Hardie <[email-masked]>
Date: Fri, 12 Dec 2003 13:37:55 -0800

>
>Right now any AD can, of his or her own choosing and without any change in 2026 or 2418, decide to make their WG chairs responsible for the technical writeup of documents, resolving last call issues, and shepherding of the document through the IESG including resolving discuss issues. An AD can choose to do this now without asking the IETF for any consensus whatsoever.

But, at the moment, this is done at the pleasure of the ADs, and is not a default state of
affairs.  Having a working group decide whether this should be the *expected* state
of affairs does have consequences on how much time working group chairs must expect
to dedicate to their tasks, how the nomcom would see certain candidates for AD roles,
and how the community may want to structure other tasks (including selecting or providing
checks and balances for the working group chairs in their roles).  Considering those
is something that should be done in public, with an aim for consensus, and soon.  A
working group is one way of achieving that.

This does not mean that ADs cannot or should not give those tasks to the willing
working group chairs sooner, but until it is the *IETF* giving those tasks to someone
other than the AD, we are still operating at the pleasure of the AD.   That needs
to change, in my opinion.
	
Just my two cents, obviously,
				Ted

---

From: "James Kempf" <[email-masked]>
Date: Fri, 12 Dec 2003 13:59:22 -0800

> agree: I certainly heard no consensus about shifting *authority*.

This is a recipe for driving people away. If you give someone the
responsibility to do something, they better have the authority to accomplish
the task. Otherwise, who would take the job?

            jak

---

From: Pete Resnick <[email-masked]>
Date: Fri, 12 Dec 2003 16:36:30 -0600

On 12/12/03 at 1:59 PM -0800, James Kempf wrote:

>>*responsibility* to the chairs was a good idea. On the other hand, 
>>I agree: I certainly heard no consensus about shifting *authority*.
>
>responsibility to do something, they better have the authority to 
>accomplish the task. Otherwise, who would take the job?

Someone else mentioned in private mail that they read it the way you 
did. Let me clarify, as that isn't what I meant.

I thought I heard at the plenary many people who thought it was a 
good idea to give certain responsibilities to the chairs:

- Making sure enough technical reviews are done before docs go to the IESG
- Doing a technical writeup of their own
- Tracking Last Call and IESG discuss issues and collecting WG responses

I thought I heard at the plenary many people who thought that giving 
chairs "the authority to say no" was a really bad idea.

A chair does not need the authority to say no in order to get 
technical reviews assigned, do a technical writeup, or track 
outstanding issues. They already have full authority to accomplish 
those tasks.

All that I'm saying is that any AD today *can* ask a chair to do 
these things, and I think that they should. We don't need a WG to 
make that happen.

pr

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Dec 2003 09:28:09 -0800

Dave,

> It depends on the defined task.  If the task is "coordination", then the
> responsibility for tracking document state is entirely appropriate.  It
> does not need accompanying "authority".
>
> Let me suggest that "authority" is looking more and more like exactly
> the wrong construct for fixing IETF problems. Focusing on authority
> ensures that we will need to have curbs against abuse, because there are
> certain to be some abuses.
>
> What is needed is facilitating collaboration. This means that
> "authority" rests with collections of people who reach agreements. Any
> individual who appears to have authority has it by virtue of delegation
> from a collection of participants, for the purpose of efficiency.
>

I think it does involve authority. 2026 only allows the WG chair to judge
rough concensus. If there is rough concensus then the chair must forward the
document to the IESG, regardless of how broken (s)he may think it is. Given
the current rules in 2026, the WG chair can't simply hold the document for
review and send it to a third party group of reviewers, like SIRS, then come
back and insist that the WG fix the problems. (S)he can only do that if the
reviewing party is the IESG. And the chair can't even send along a list of
problems (s)he thinks need attention and request that the review group pay
particular attention to, even if it is the IESG. The chair is expected to
represent the WG concensus to the IESG, nothing more.

We're facing this problem right now in Seamoby. We sent one document out to
a review committee at my request (I'm the co-chair), and it came back with a
list of problems the reviewers wanted to see fixed. But the reviewer's
comments were not any more binding on the design than any others, and the WG
members quibbled with the reviewers on the WG list until the reviewers gave
up, essentially a successful DoS attack.

This isn't "co-ordination", because the WG chair is making a judgement about
the need for enforcable QA on the spec, just as a manager would when doing
software development. If you don't like the word "authority" then pick
another one.

> Let's take the specific case of a rogue working group and a
> knowlegeable, diligent chair. How is the chair -- or the AD -- to
> "control" the wayward choices of a misguided working group? Surely the
> superior expertise of the chair should prevail?
>
> The problems with assuming that the chair has that expertise, and then
> assuming that it will always be applied properly. We are not suddenly
> going to select better Chairs. Some have enough of the relevant types of
> expertise and some do not. Some will invoke it wisely and some will not.
>
>      Let me suggest, instead, that the core test mechanism in the IETF
>      is the ability to recruit others to a point of view.
>
> Hence, the expertise of the Chair (or anyone else, for that matter)
> should be used to recruit a collection of _other_ participants to
> counter the misguided views of the working group.
>
> One might even think that independent, senior IETF reviewers might be
> helpful to this goal...
>

See comments above. Unless the review makes enforcable changes, it's not
worth anything. The WG can continue to  quibble until the reviewers give up.
There needs to be some check on WGs that don't deliver quality. If you don't
like the WG chair exercising their design judgement enforcably, then they at
least need to be able to decide what they don't like and submit it, along
with the document, to some third party group that has the power (sorry for
swearing) to enforce quality.

            jak

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Dec 2003 08:44:42 -0800

James,

>> agree: I certainly heard no consensus about shifting *authority*.
JK> This is a recipe for driving people away. If you give someone the
JK> responsibility to do something, they better have the authority to accomplish
JK> the task. Otherwise, who would take the job?

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Pete Resnick <[email-masked]>
Date: Mon, 15 Dec 2003 13:59:41 -0600

On 12/15/03 at 9:28 AM -0800, James Kempf wrote:

>We're facing this problem right now in Seamoby. We sent one document 
>out to a review committee at my request (I'm the co-chair), and it 
>came back with a list of problems the reviewers wanted to see fixed. 
>But the reviewer's comments were not any more binding on the design 
>than any others, and the WG members quibbled with the reviewers on 
>the WG list until the reviewers gave up, essentially a successful 
>DoS attack.

Depending on the details here, I don't think you need any additional 
authority to hold this document. It's for exactly the same reasons 
that a big company can't (or shouldn't be able to) "pack a room" at 
the IETF and win by a majority: A huge bunch of people agreeing to 
something does not make a rough consensus when there is a significant 
though smaller group of folks who disagree and the larger group isn't 
willing to justify their position.

So in your case: If you had a reasonable size reviewer committee (not 
just 1 or 2 people), that means that you've got a significant number 
of folks who think there are real problems with the document. Once 
they started commenting on the documents, they effectively became 
part of the WG. If by "gave up", you mean they simply stopped posting 
responses in disgust (as opposed to eventually agreeing with the rest 
of the WG), then you can reasonably say that your WG did *not* come 
to rough consensus on those issues. You can say, "Look folks, there 
are well-argued open issues on the list. I have heard quibbles, but I 
have heard nothing so far that actually addresses those issues. 
That's people talking past eachother, but it's not rough consensus. I 
won't pass the documents on until we achieve rough consensus."

Now, if you only had 1 or 2 reviewers and they were unable to garner 
any additional support, or if the reviewers really did agree with the 
rest of the WG and you're the only one left, or if the WG actually 
gave well-reasoned arguments why the outstanding issues aren't really 
problems but you happen to disagree with them, then you *should* 
declare rough consensus and pass the document on. If the problems 
with the document are really that bad, then there should be a 
reasonable contingent that will object when IETF Last Call comes 
around and their won't be IETF-wide consensus. But mind you, if it 
comes down to that, the process broke down long ago: Either there 
weren't enough intelligent people in the WG to do reasonable work (in 
which case it shouldn't have been chartered), or something got out of 
control in the WG some time ago. That can and will happen in WGs, but 
giving more formal authority to WG chairs isn't addressing that 
problem.
-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Dec 2003 12:53:06 -0800

Pete,

I disagree. I see nothing in 2026 or 2418 that gives a WG chair the
authority to hold a document because they believe there are flaws in the
design. Rough concensus doesn't mean one person objects, it means some
significant number, over a majority object.  Besides, if the WG chair does
hold the document, what are they supposed to do with it? Under the current
rules, the only alternative is for the chair to get on the list and try to
work the concensus behind what they believe is the correct solution, and
presumably they've tried that already (if they've been a good chair). To go
on the list again would just be a DoS attack on the WG chair's time.

So the chair can either submit the document to the IESG and let them deal
with it (thereby increasing overload) or try to convince the WG that they're
making a mistake. I suppose a chair could submit the document to the IESG
with a list of flaws that the chair thinks need to get fixed, but even that
is going outside of what 2026 and 2418 prescribe as the WG chair's role. The
chair is just supposed to represent WG concensus.

There is also a point about the role of reviews that I perhaps did not
articulate clearly. The point is that the reviewers are outside the WG, so
that they function like a traditional QA team in software development, as a
check on the spec developers (and thus on WG concensus); otherwise, the
utility of the reviews is limited. Thus, they are not, strictly speaking,
subject to WG concensus. I don't think it would be helpful to go into
microsurgery on the example I gave, but in that particular case, several of
the reviewers did, in fact, get involved in the list discussion precisely
*because* their reviews had no authority to change WG concensus under
current rules, so trying to influence concensus was the only way they could
get their changes instituted (to their credit).

I agree with Margaret's basic contention: the WG chairs need the authority
to be able to hold specs because, in their design judgement, the spec is
flawed. If that's possible, then there needs to be some mechanism for
resolving those problems, and a third party review sounds right (in addition
to reviews at other times, like when a draft goes to WG draft status). I
also think (and this impinges on the ICAR charter a little) that any review
mechanism needs to be binding on the WG, just as third party QA is in
software development. Otherwise, the reviews are of little value.

            jak

----- Original Message ----- 
From: "Pete Resnick" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Dave Crocker" <[email-masked]>; "MPowr" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 15, 2003 11:59 AM
Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG
proposal

---

From: Pete Resnick <[email-masked]>
Date: Mon, 15 Dec 2003 16:19:14 -0600

On 12/15/03 at 12:53 PM -0800, James Kempf wrote:

>authority to hold a document because they believe there are flaws in 
>the design.

I don't know with whom you're disagreeing, because I never said that 
and I don't believe that. I don't believe a WG chair has the 
authority to hold a document because they believe there are flaws in 
the design, nor do I believe that a chair should have such authority. 
I said that the chair can hold a document if there is not rough 
consensus in the WG that the document is ready to go to the IESG.

>Rough concensus doesn't mean one person objects,

Agreed.

>it means some significant number, over a majority object.

And with that I disagree. Though  it is almost always true that a 
rough consensus *is* over a majority of people agreeing, sometimes 
it's not. Sometimes it's a significant *minority* agreeing and the 
majority not feeling strongly at all. That's part of the reason we 
often do hums instead of straw polls: Sometimes it's not a matter of 
the majority, but the strength of the agreement or disagreement. If 
I've got a WG with 2 people who propose that "X" should be in a 
protocol, 100 people who express a preference for "X" but don't care 
strongly one way or the other, and 20 people who object that "X" will 
actively cause damage, there is *not* rough consensus to put "X" in 
the protocol.

>Besides, if the WG chair does hold the document, what are they 
>supposed to do with it?

Post to the list, "There is still a significant number of outstanding 
objections to X, Y, and Z, and nobody here has either persuaded the 
objectors that their problems have been addressed or given any reason 
why the objections should be ignored. Until those issues are 
addressed, we do not have rough consensus in this working group to 
pass the document on to the IESG."

>Under the current rules, the only alternative is for the chair to 
>get on the list and try to work the concensus behind what they 
>believe is the correct solution , and presumably they've tried that 
>already (if they've been a good chair).

First of all, no, the chair should not work for what *they* believe 
is the correct solution (at least in their role as chair). The chair 
can try to get the two sides to come to consensus, but shouldn't push 
their own agenda.

But second of all, even if we're talking about 1 or 2 individuals, 
section 6.5.1 of 2026 addresses *exactly* this problem: The chair 
tries to resolve the dispute, and if not then bring it to the AD, and 
then the IESG, and then the IAB. I suppose if the chair is the *only* 
person objecting (and I want to know how *that* happened), this 
process can also be used, just starting from the AD.

And again, if we've already gotten to this point by the time the WG 
is asking for IETF Last Call, there was a serious management 
breakdown long ago, and I don't want the remedy for that to be "let 
the chair veto anything they feel like". That will only encourage 
lousy chairs to leave their objections to the end of the process and 
then trump.

>There is also a point about the role of reviews that I perhaps did 
>not articulate clearly. The point is that the reviewers are outside 
>the WG, so that they function like a traditional QA team in software 
>development, as a check on the spec developers (and thus on WG 
>concensus); otherwise, the utility of the reviews is limited. Thus, 
>they are not, strictly speaking, subject to WG concensus.

I'm sorry, but this is just nonsense. The point of these kinds of 
reviews is to get input from folks who wouldn't normally be 
participating in the WG (due to time constraints or field of 
expertise), but not to have some sort of unchecked authority over the 
WG. The IETF is a consensus organization (that's where the 
"authority" lies), so *of course* reviews are subject to WG consensus.

And of course the reviews are still of value. Your entire scenario 
for them not being of value is that we have a completely rouge WG 
which refuses to listen. We should not be designing our procedures 
around that sort of world view.

>I don't think it would be helpful to go into microsurgery on the 
>example I gave, but in that particular case, several of the 
>reviewers did, in fact, get involved in the list discussion 
>precisely *because* their reviews had no authority to change WG 
>concensus under current rules, so trying to influence concensus was 
>the only way they could get their changes instituted (to their 
>credit).

That I think is exactly the right way to go. Or, if the WG simply 
refused to heed their reviews, they could have objected under 2026, 
6.5.1.

>I agree with Margaret's basic contention: the WG chairs need the 
>authority to be able to hold specs because, in their design 
>judgement, the spec is flawed.

I have yet to hear any reasoned explanation for why this authority is 
necessary given our other procedures.

pr

---

From: "James Kempf" <[email-masked]>
Date: Mon, 15 Dec 2003 15:29:28 -0800

Dave,

> JK> any review mechanism needs to be binding on the WG,
>
> This moves us back to the "authority" focus, rather than the "consensus"
> focus. Certainly a working group is obligated to deal with comments it
> receives. But what does it mean for those comments to be "binding"?
> Going down that path gets more complicated, because then we must deal
> with questions about the expertise and intent of the reviewer.
>

To my mind, it means the same thing as in software product development when
the QA team comes back to the development group with a list of bugs that
caused their regression tests to fail: the code doesn't go to the customers
until the development group has fixed the problems. What would you call this
if "authority" doesn't sound right? The product group manager isn't acting
as a dictator, he's trying to make sure the product is salable. The division
director isn't going to let him/her ship their code to customers until the
bugs are fixed because they both know that the customers won't buy it.
Presumably the QA group was selected for their expertise (otherwise, they
wouldn't have gotten the job) and their intent is the same as for the
product development group: to ensure that the product is of the highest
possible quality so customers buy it. Both the development group and the
product group manager know this, as does the QA group. The product
development manager gets to say when adequate QA has been done, and
typically that's based on his/her judgement about the impact of the
remaining bugs on customer usability. I don't see much difference here from
the case we are discussing, do you?

I don't want to imply by this that the only check on quality should be a
final review, quite the contrary. Early review is far better as a quality
check, and the WG should also be responsible for coming up with their own
quality review plan. BTW, quality review plans are now starting to show up
in new proposed charters.

> Working groups are usually diligent at dealing with comments.  When they
> aren't, it provides further examples that the wg is rogue.
>

Well, obviously we have had different experiences in this area. What's your
definition of rogue? That they don't live up to their charter or try to
exceed it? What if they fufill the charter but the result of what they come
up with is poorly designed?

                    jak

---

From: Pete Resnick <[email-masked]>
Date: Mon, 15 Dec 2003 22:13:00 -0600

On 12/15/03 at 3:29 PM -0800, James Kempf wrote:

>>Certainly a working group is obligated to deal with comments it 
>To my mind, it means the same thing as in software product 
>development when the QA team comes back to the development group 
>with a list of bugs that caused their regression tests to fail: the 
>code doesn't go to the customers until the development group has 
>fixed the problems.

I'm going to ignore the elephant standing in the room for the moment 
and actually stick to your analogy:

If the QA team finds bugs, it might be the case that the code doesn't 
go to the customer. Or not. If the development team comes back and 
says, "We've told you 20 times that the regression test you people in 
QA are doing is wrong, doesn't represent any customer scenario, and 
should be eliminated; we are not going to waste time fixing that bug 
because it won't effect anybody", the software might very well ship. 
Or perhaps the answer is, "That bug was found too late in the 
process, and it's not like it lops the head off of the user; it's a 
minor user interface flub" and the software will ship. Or maybe the 
development team lead goes to the head of QA and says, "Well, I 
agree, this bug should be fixed. But the folks actually doing the 
coding don't agree, so either we let the bug slide, or if you really 
want I can make a big stink and pass it up to management to deal 
with." And if push comes to shove, you start firing developers if it 
really is something that they need to fix and they refuse.

In the development organizations I've been a part of, either 
development agrees with QA (which happens almost all of the time), in 
which case they fix the bugs, or they don't, in which case either the 
code ships (because QA was wrong or because it wasn't worth arguing 
about) or the management that oversees both groups makes the call. 
Such cases getting to management are rare, I have yet to see 
upper-level management fire someone over such a dispute, and there 
has been no need to give the development lead direct "firing 
authority".

Of course, we do have similar backstops in the IETF (specifically 
2026 section 6.5.1 which I mentioned before), but like the scenario 
above, that should kick in and make it all the way up the chain only 
when the WG in question has completely lost its mind. Folks can 
appeal up the chain, and the IESG can shut down the WG if it's gone 
astray. And there's no reason to give the chair the individual power 
to say "no" if there's no one else saying no.

>What would you call this if "authority" doesn't sound right? The 
>product group manager isn't acting as a dictator, he's trying to 
>make sure the product is salable. The division director isn't going 
>to let him/her ship their code to customers until the bugs are fixed 
>because they both know that the customers won't buy it. Presumably 
>the QA group was selected for their expertise (otherwise, they 
>wouldn't have gotten the job) and their intent is the same as for 
>the product development group: to ensure that the product is of the 
>highest possible quality so customers buy it. Both the development 
>group and the product group manager know this, as does the QA group. 
>The product development manager gets to say when adequate QA has 
>been done, and typically that's based on his/her judgement about the 
>impact of the remaining bugs on customer usability. I don't see much 
>difference here from the case we are discussing, do you?

So here's that elephant in the room: *Of course* there's a 
difference, and I'm a little concerned that you don't see it.

Companies like the one you describe are strict hierarchies. The top 
of the company has the most to gain or lose (monetarily) based on the 
outcome of the efforts of the folks below. The folks further up the 
chain get to choose who is going to do the work below. If the upper 
folks don't like the work being done by the lower folks, they get new 
lower folks to do the work. The upper folks hire some sets of lower 
folks to check the work of the other lower folks. Everything is very 
congenial so long as everyone more or less cooperates. But outside of 
everything working smoothly, you bet it's a dictatorship. Though it's 
nice when there is a consensus among all of the groups, if there's 
not, management has easy ways to solve that problem.

The IETF is not like that. The IETF is a consensus organization. We 
have different levels of consensus (e.g., inside the WG, the whole 
IETF), but at the end of the day, it's the entire population who 
decides whether the work is up-to-snuff. We have some procedures to 
make sure people don't make dumb mistakes along the way (including 
having some folks we think are smart do some final reviews of our 
work), and we've got some management structure to deal with things 
when all hell breaks loose, but even there it's not like the company 
you describe: The IESG can shut down a WG or say "no" to a document, 
but even in those cases, the IESG is supposed to try to resolve the 
conflict and bring the group back to consensus, not just veto. And if 
in the end we can't come to consensus with management, the rest of us 
can appeal the decision of the management, and if we decide that they 
are simply not doing the right thing, we can get rid of them using 
the recall process (or in the extreme, as happened in 1992, change 
the management structure altogether).

Yes, that means we have given our management a good deal of 
responsibility and not very much final authority. There are some 
things that are made really hard by being in an open-membership 
consensus-based organization. Maybe it would be nice if it were 
otherwise. Personally, I kind of like it this way.

pr

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Dec 2003 08:28:48 -0800

Pete,

> the management structure altogether).

So doesn't the fact that the IESG can say "no" make it a hierarchy? I fail
to see any difference in the immediate situation between an Area Director
returning a document to a working group after AD Review and saying "fix this
or I'm not going to submit it to the IESG" and a division director saying
"fix these bugs or I'm not going to release the software".

Of course, there are differences in accountability. The division director is
only accountable to his VP while the AD is accountable to the community. As
I've said in other emails, that means that should WG chairs be given more -
it you don't like the word "authority" call it something else, maybe "X
stuff" - then there needs to be a similar accountability mechanism for them.

> otherwise. Personally, I kind of like it this way.

Sorry, I disagree. No sane person is going to take the responsibility to do
something without the authority to get it done. One argument some have made
against giving the WG chairs more X stuff is that we don't get very good
people as WG chairs. If they aren't given the X stuff to match their
responsibility, we'll get even worse.

                            jak

---

From: Steve Coya <[email-masked]>
Date: Tue, 16 Dec 2003 10:58:41 -0500 (Eastern Standard Time)

>>of folks who think there are real problems with the document.

Perhaps it's the _nature_ of the review (and reviewer comments) - along
with the instructions conveyed to the reviewers (assuming/hoping
instructions were included).

For example, a review which points out that the specification is in direct
conflict with an existing protocol (i.e. architectural or incompatible)
should be seriously considered and addressed, as opposed to an
opinion, for example, that a byte count should start at one instead of
zero - which can be considered and ..... "respectfully declined"

That's just my thought - I could be wrong.

Steve

---

From: Dave Crocker <[email-masked]>
Date: Mon, 15 Dec 2003 14:14:12 -0800

James,

JK> I disagree. I see nothing in 2026 or 2418 that gives a WG chair the
JK> authority to hold a document because they believe there are flaws in the

That is correct.  Chairs do not have the authority to overrule the
Working Group.  The chair's job is to facilitate, not control.

For every example of wayward working groups, we need to worry equally
about wayward chairs.  The challenge is to find a balance.

In the IETF, we try to do that through diverse participation. When a
diverse group strongly embraces a decision, then we have a legitimate
decision.

The challenge with a wayward working group is that it is, at best, a
diverse sample of the larger community that shares a common goal. The
serious problems occur when it is not diverse or experienced enough or
does not have a strongly shared goal.

But the same can be true for the knowledge, perspective and possible
bias of the chair.

JK> design. Rough concensus doesn't mean one person objects, it means some
JK> significant number, over a majority object.

The rough consensus thing comes in two forms.  Objecting and agreeing.
So a rough consensus of agreement means that there is not a strong,
substantial disagreement.

JK>  Besides, if the WG chair does
JK> hold the document, what are they supposed to do with it?

This concern about delaying the process for a chair-invoked hold makes
sense to me pnly if there were some sort of surprise at the end of the
working group process. But there never is, especially with the glacial
pace that most working groups operate at.

So a chair who feels that the working group is wayward has months to
use, to recruit corrective assistance.

           We do not have crises, except through delayed oversight.

           Review early and review often.

JK> . I suppose a chair could submit the document to the IESG
JK> with a list of flaws that the chair thinks need to get fixed, but even that
JK> is going outside of what 2026 and 2418 prescribe as the WG chair's role.

Not really.  The IETF looks for comments whenever they are offered, and
from whoever offers them.

As a matter of efficiency, there are good times and bad, for some input.
That's why the distinction between "I don't like a decision" versus "The
decision won't work" is so important.  The former is useful earlier in
a process, and wasteful any other time.  The latter is always useful.

JK> There is also a point about the role of reviews that I perhaps did
JK> not articulate clearly. The point is that the reviewers are outside
JK> the WG, so that they function like a traditional QA team in software
JK> development, as a check on the spec developers (and thus on WG
JK> concensus); otherwise, the utility of the reviews is limited.

I think that an informed, diligent review is useful, no matter where it
came from.  The problem is with _relying_ on reviews that come from the
developers.

JK> Thus, they are not, strictly speaking, subject to WG concensus.

On the other hand, consensus among reviewers ought to be pretty
noteworthy...

d/

---

From: Keith Moore <[email-masked]>
Date: Tue, 16 Dec 2003 11:05:04 -0500

> the design, nor do I believe that a chair should have such authority. 

that might be the case under our current rules.  however this has an 
interesting implication - that IESG is the only party that has the ability to block a document because of design flaws.

no wonder IESG has such a high workload!

---

From: Pete Resnick <[email-masked]>
Date: Tue, 16 Dec 2003 11:55:05 -0600

On 12/16/03 at 8:28 AM -0800, James Kempf wrote:

>So doesn't the fact that the IESG can say "no" make it a hierarchy?

No, it doesn't. For example:

>I fail to see any difference in the immediate situation between an 
>Area Director returning a document to a working group after AD 
>Review and saying "fix this or I'm not going to submit it to the 
>IESG" and a division director saying "fix these bugs or I'm not 
>going to release the software".

Because the development team can't appeal the division director's 
decision, and the development team members cannot initiate the 
process to fire the division director. And moreover, the development 
team cannot decide (with the rest of the departments) to restructure 
the corporation and get rid of the division director.

Also, the division director is under no obligation to negotiate with 
the development team if the development team disagrees with the 
division director. The division director has no responsibility to try 
to resolve disputes, even if it is a nice thing to do.

>Of course, there are differences in accountability. The division 
>director is only accountable to his VP while the AD is accountable 
>to the community. As I've said in other emails, *that* means that 
>should WG chairs be given more - it you don't like the word 
>"authority" call it something else, maybe "X stuff" - then there 
>needs to be a similar accountability mechanism for them.
[emphasis added]

First of all, *what* means that chairs should be given more 
authority? I don't see how that follows from anything you've said. 
(And I *do* think we're talking about authority here; no need to call 
it "X stuff".)

Second of all, accountability is *not* the only difference between 
the division director and the AD; the entire set of responsibilities 
is similarly different.

>No sane person is going to take the responsibility to do something 
>without the authority to get it done.

You've said that twice now and I'm still at a loss to know what 
you're talking about. It sounds like a catch phrase. What 
responsibility have we given (or do we want to give) to an AD or to a 
WG chair for which we haven't given them the authority to get it 
done? An AD has the responsibility to review documents coming out of 
working groups. Chairs have the responsibility to make sure that 
consensus is reached on all open document issues. We're talking about 
giving chairs the responsibility to collect technical reviews early 
in the process and to do a technical writeup at the end of the 
process. Yes, for all of these responsibilities, the ADs and chairs 
should know that the community has the authority to overrule them. 
But how does that equate to not having the authority to get those 
things done? Does the prospect of appeal or recall prevent ADs from 
pushing back on WGs? Does the prospect of appeal or recall prevent a 
chair from invoking 2026 to say, "Let's try to bring this set of open 
issues from the review to consensus"?

>One argument some have made against giving the WG chairs more X 
>stuff is that we don't get very good people as WG chairs.

Straw man. I've certainly never said that.

>If they aren't given the X stuff to match their responsibility, 
>we'll get even worse.

So effectively you're saying that power is the only reward for which 
good chairs will work. I've not found that to be the case.

pr

---

From: "Lucy E. Lynch" <[email-masked]>
Date: Tue, 16 Dec 2003 09:58:20 -0800 (PST)

> responsibility, we'll get even worse.

Excuse the cross post - but I thought Vixie's take on Authority
might be interesting to folks - seems pretty sane to me.

---------- Forwarded message ----------
Date: 16 Dec 2003 07:14:57 +0000
From: Paul Vixie <[email-masked]>
To: [email-masked]
Subject: Re: Root Authority

> An interesting question I've dealt with a few times:
>
> From whom do the root nameservers derive their authority?

we (i'm speaking for f-root here) have no "authority".  nobody has to
listen to us, we are the most powerless bunch of folks you'll ever meet.

now if you'd asked where we derive our *relevance*, i'd say the same as
mr. bush and mr. kletnieks -- from all the root.cache files that point
at us.  and as long as we don't do anything stupid i guess (and hope)
that this state of affairs will continue.  (relevance trumps authority.)

that having been said, f-root got its start as NS.ISC.ORG and the man
who said it was ok for us to be a root name server was jon postel.  i'm
not sure he had any "authority" either, but folks "pointed at" him and
so what he said was relevant in spite of any authority he mightn've had.
--
Paul Vixie

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Dec 2003 10:03:24 -0800

Pete,

By "immediate situation" I meant the situation of how the QA process is
handled. By "accountability" I meant how alleged abuses are handled.

Your point about appeal is about "accountability", not about "immediate
situation". These are two different processes, and it would be well not to
confuse them.

I agree with you about "accountability", I don't agree about how to
structure the "immediate situation".

        jak

----- Original Message ----- 
From: "Pete Resnick" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "Dave Crocker" <[email-masked]>; "MPowr" <[email-masked]>;
<[email-masked]>
Sent: Tuesday, December 16, 2003 9:55 AM
Subject: Re: Quality Control and that nasty A word (was: Re: [mpowr] Re:
[Solutions] Further work on WG (chair) roles - MPOWR WG proposal)

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Dec 2003 10:05:41 -0800

If you'd rather call it "relevance" than "X-stuff" be my guest.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 16 Dec 2003 14:02:17 -0800

Dave,

> A very serious problem with trying to assign responsibility to the Chair
> for quality, and the like, is that it _removes_ responsibility away from
> the rest of the working group.
>

This presumes that the motivations of the WG are to not produce a quality
spec. While this may sometimes be the case, I don't believe that it is
necessarily always the case, or rather, it should not always be the case.
The Chair and WG need to work as a team.

> The chair is responsible for facilitating a fair, timely, quality
> process.  The entire working group is responsible for actually achieving
> those things.
>
> This is not semantics.  It is a fundamental difference in views about
> the role of the Chair.
>

Clearly, quality requires more than just review at the end of the process.
Your pithy formulation of "review early, review often" is relevant here. The
WG needs to be responsible for quality, the WG chair needs to be responsible
to make sure that is carried through, and have the tools (relevance, what
have you) to carry it out.

As mentioned earlier, new proposed WG charters are starting to have quality
assurance plans. Suppose the IESG were to require that a charter contain a
QA plan before the charter is approved. Thus, the WG is taking
responsibility for quality by proposing the QA plan, the IESG is judging
whether the plan is likely to succeed (from their presumably broader
experience) by approving the charter or suggesting changes, and the chair
has the responsibility for carrying the QA plan out, with the authority
(relevance, etc.) granted to him/her by the WG through the charter.  To make
this work, the chair would need to have some tools available. The primary
tool would be an expert review board like SIRS, and a template of options
and standardized processes as to when reviews are typically carried out. The
WG could agree to make the review binding, or not, and pick from the
template what reviews they intended to have done and when. The IESG's
judgement about the plan would depend on the interest group wanting to form
the WG, the subject area, etc., (the IESG might also decide that they wanted
to review the documents themselves rather than have outside review, for
reasons of interest, possible effect on the Internet, etc.). Another QA tool
might be implementation (as in "running code"). The working group might
include at least one implementation of the protocol, to make sure that it is
cleanly designed from an implementation standpoint, or the IESG might
suggest that an implementation be done as part of the QA plan if they have
concerns. A final tool might be requiring more than one interoperable
implementation. I realize that, today, that is required only for DS, but
there might be cases where interoperability concerns are high at the PS
stage.

Would this satisfy your concerns?

                jak

---

From: Dave Crocker <[email-masked]>
Date: Tue, 16 Dec 2003 12:11:14 -0800

James,

JK>  No sane person is going to take the responsibility to do
JK> something without the authority to get it done.

Rather than debate your point, let me suggest that the question is,
then, what the responsibility of the chair is.

d/

---

From: "James Kempf" <[email-masked]>
Date: Wed, 17 Dec 2003 08:32:07 -0800

> > (relevance, etc.) granted to him/her by the WG through the charter.
>
> As long as the chair can be also a developer, this process is
> fundamentally weak, and prone to play just as a tool for promoting
> the chair's, and chairs friends' work.
>

Sorry, Alex, but I don't understand what this has to do with figuring out a
mechanism whereby QA can be effective, while, at the same time, reducing
IESG workload and ensuring that the responsibility for QA rests with the WG.

> > [...]
> Not mine. Sorry for jumping in.
>

Could you explain a little more? What exactly do you mean by the chair being
a "developer"? If you read Margaret's draft (which I presume you did, since
you're commenting on this thread) then you know that she has proposed that
chairs are no longer allowed to be authors or editors of drafts, except for
a limited period during which they are in transition between one role and
another. So, if that's what you mean by being a "developer", that particular
concern would be covered if that part of Margaret's draft is instituted. As
for the chair's friends, it is up to the IESG to pick someone who can
abstract themselves from purely partisan concerns and act as a moderator in
the tussles that inevitably arise during standardization. If the chair does
not fufill that role, then it is the responsibility of the WG to appeal to
the AD to remove the chair.

Perhaps there needs to be a statement to this effect in 2026bis?

            jak

---

From: Pekka Savola <[email-masked]>
Date: Wed, 17 Dec 2003 18:57:44 +0200 (EET)

On Wed, 17 Dec 2003, James Kempf wrote:
> concern would be covered if that part of Margaret's draft is instituted. 

This is not what the draft says.  WG chairs can be authors and editors 
as well, *as long as* they do not serve in the same role for the 
particular document at the same time.  I.e., if there are two chairs, 
one can author/edit a document without problems still.

Removing that possibility might be interesting, but would the WG get 
anything done then? :-)  WG chairs are often the last resort of 
pushing through the documents when WG falls into paralysis :-)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 17 Dec 2003 11:08:32 -0700 (MST)

On Wed, 17 Dec 2003, Dave Crocker wrote:

> However I think that your own point about the inherent power of the
> working group, compared with the derived power of IETF management,
> including chairs, is the most important point.
>
> This is where reference to the IETF's being a volunteer organization
> is so important. The troops really are in charge.  When we run
> things without paying attention to that, we get volunteers who
> leave, by giving up on the working group.

Dave,

	While I would really like to see IETF functioning that way, I
have a hard time combining "in-charge troops" and "IESG does the final
review and approval and might even modify documents at will". Perhaps
somebody can help me here. I understand that IESG is elected by the
troops. However, if we assume that an election grants superpowers,
then it seems natural to assume that IESG-appointed chair can also
have superpowers within a WG scope.

In other words, you cannot make the "troops" argument against Chair
powers without making a similar argument about IESG or AD powers.
IESG/ADs simply want to delegate a portion of their power to Chairs,
with what they believe sufficient controls. Don't like that?  Appeal,
elect a different IESG, or drastically change the IESG role.

I can understand an organization where the working group is a
superpower, with rules and procedures for cross-group review and
conflict resolution. I can understand an organization where the IESG
is the superpower, with rules and procedures to encourage WG work and
elect IESG. If current IETF is the second kind of an organization (and
it looks like that to me), are we not fooling ourselves with "troops"
arguments? It seems to me that we should either

	- relax and let IESG disperse its powers to Chairs
	  any way it seems fit; it should be within IESG
	  powers to do so if IESG already has powers of so
	  many more important aspects of WG work

	- remove superpowers from IESG and have a WG decide
	  on its Chair authority; leave IESG its current
	  final conflict resolution power.

Both options have real-life precedence in other SDOs, of course. We
seem to be stuck trying to invent a third option that carefully draws
a line between effectively powerless WG and an effective IESG
superpower, with a Chair standing on that line. Such an option may not
exist.

Alex.

---

From: Alex Conta <[email-masked]>
Date: Wed, 17 Dec 2003 13:37:40 -0500

Please see incline:

James Kempf wrote:

>>>As mentioned earlier, new proposed WG charters are starting to have
> 
> quality
> 
>>>assurance plans. Suppose the IESG were to require that a charter contain
> 
> a
> 
>>>experience) by approving the charter or suggesting changes, and the
> 
> chair
> 

Making the QA the responasbility of the WG is a good thing. But QA 
should not be only the task of the WG, since I do not think QA will be 
effective if it is solely a mechanism at WG level.

Reducing the IESG load can be achieved by other means than just shifting 
load to the WG chairs. Personally I would prefer shifting the load to a 
body of people that are elected (nomcom) as opposed to selected by ADs. 
Something like the IESG - perhaps IAB, or a somewhat similar group.

If I didn't say that already, power of decision on QA should be 
collective, and impartial. To ensure impartiality from start, decision 
people should meet certain criteria.

> the AD to remove the chair.

As documents on the standards track are "alive" pretty much as long as 
the WG is alive, any involvement with output of the WG should be a 
disqualifing criterium for a WG chair, regardless of the amount of power 
- current level, or increased level of power. This is practice in many 
SDOs, and would resolve a problem in IETF that exists currently, even 
without giving the chairs more power.

Additional checks and balances mechanims can be looked at - time limits 
on serving as chairs, performance reports after each IETF meeting - 
could be part of the "blue sheet", etc...

regards,
Alex

---

From: Alex Conta <[email-masked]>
Date: Wed, 17 Dec 2003 13:50:51 -0500

> one can author/edit a document without problems still.

My interpretation was the same as yours, which is why I voiced 
unequivocally, and undiplomatically my concerns. So in fact Margaret's 
draft does not suggest changing the current practice, as James's 
interperation suggested. That current practice is a problem even in 
current conditions, without any additional power to the chairs.

> pushing through the documents when WG falls into paralysis :-)

If the WG chairs being the last resort should not be a concern, it means 
no one is interested in the work of that WG, so the WG should be 
disbanded, and the work filed as it is - incomplete work, could be 
resumed later, if interest revives.

Alex

---

From: David Meyer <[email-masked]>
Date: Wed, 17 Dec 2003 11:01:28 -0800

Alex,

>> resumed later, if interest revives.

	While I agree that in a perfect (maybe different) world,
	this could be true. In addition, you might make a similar
	assertion when consensus can't be reached (notably: "No
	one cares enough about this problem to compromise on a
	solution" or similar). However, the reality is somewhat
	different. In the former case (WG chairs as last resort),
	there are just too many issues surrounding how authors 
	work in a volunteer organization to make such a
	(categorical) statement.

	In fact, one of the jobs of a WG chair (IMO) is to manage
	and (frequently overlooked, but equally important) mentor
	the WG's authors. 

	Dave

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 17 Dec 2003 13:31:31 -0700 (MST)

On Wed, 17 Dec 2003, David Meyer wrote:

>>> If the WG chairs being the last resort should not be a concern, it
>>> means no one is interested in the work of that WG, so the WG
>>> should be disbanded, and the work filed as it is - incomplete
>>> work, could be resumed later, if interest revives.
>
> In the former case (WG chairs as last resort), there are just too
> many issues surrounding how authors work in a volunteer organization
> to make such a (categorical) statement.

Nothing in the volunteer nature of an organization implies that
half-baked documents without authors are worth promoting to standard
levels by heroic chair actions.

If we assume that WG documents must be maintained _after_ the IESG
marks them as "proposed standard", then what Alex is saying is not
that categorical. You are saying that a WG chair can be used as a last
resort to save good output of a now-defunct working group. This
implies that a frozen (usually at a near-PS level) output is worth
saving for reasons other than historical.

To me, this is equivalent of releasing beta-quality software without
any support or real possibility of upgrades. This should not be done.
It is far better not to release such software at all and simply
archive it.

Alex.

---

From: David Meyer <[email-masked]>
Date: Wed, 17 Dec 2003 13:27:21 -0800

>> levels by heroic chair actions.

	Who said anything about half-baked documents without
	authors or promoting to standards level (other than you)?
	
>> resort to save good output of a now-defunct working group. 

	I said nothing of the sort.

>> This implies that a frozen (usually at a near-PS level) output is worth

	Maybe it does, but that has nothing to do with what I was
	saying.

	Dave

---

From: Alex Conta <[email-masked]>
Date: Wed, 17 Dec 2003 16:27:03 -0500

Dave,

Managing the authors from a timeline perspective is one thing, managing 
them in terms of content of documents they write is a different thing.
While the former should be part of the chair's job, I strongly believe 
the latter should not. Adequate checks and balances have to be in place.

Mentoring is important. It does not have to be done by the chairs 
though. It can be done by more senior members of the WG, or co-authors, 
or from outside the WG. If an educational arm is being organized, that 
could be given such a  mentoring role as well.

Regards,
Alex

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 17 Dec 2003 14:42:52 -0700 (MST)

> pushing through the documents when WG falls into paralysis :-)

Documents of a paralytic WG are usually half-baked. "Pushing through"
in this context implies "promoting to standard levels" to me.

If I misunderstood the context, I apologize. I hope my agreement with
Alex reaction that such a WG should be disbanded would still stand in
the "right" context, whatever that is.

Alex.

---

From: David Meyer <[email-masked]>
Date: Wed, 17 Dec 2003 13:46:36 -0800

>> the "right" context, whatever that is.

	No worries. I think we're agreeing for the most part.

	Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 17 Dec 2003 13:28:45 -0800

>> the latter should not. Adequate checks and balances have to be in place.

	I understand the distinction you are drawing, and I for
	the most part agree. 

>> could be given such a  mentoring role as well.

	Sure.

	Dave

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Dec 2003 08:51:54 -0800

James,

>> the rest of the working group.
JK> This presumes that the motivations of the WG are to not produce a quality
JK> spec.

Sorry, no.  It presumes nothing of the sort.

It simply uses the observation that explicitly assigning responsibility
to one agent serves to imply that other agents do not have the
responsibility. This is a pretty well-studied psychological phenomenon.

So, consider the difference between saying that the chair is responsible
for quality and timeliness, versus saying that the working group is
responsible for quality and timeliness and the chair is responsible for
facilitating the working group's fulfillment of its responsibility.

JK> While this may sometimes be the case,

It must _never_ be the case.

If the working group is not responsible, then who the heck is the work
for? This is another example of how the IETF differs from a regular
product company. The people producing a specification must be
representative of the community that will use it.

JK> Your pithy formulation of "review early, review often" is relevant here. The
JK> WG needs to be responsible for quality, the WG chair needs to be responsible
JK> to make sure that is carried through

No.  The working group needs to be responsible for it.  The chair needs
to coordinate/facilitate getting it done.  If the working group does not
own that responsibility, then it ultimately does not own the work of the
working group.

JK> As mentioned earlier, new proposed WG charters are starting to have
JK> quality assurance plans. Suppose the IESG were to require that a
JK> charter contain a QA plan before the charter is approved. Thus, the
JK> WG is taking responsibility for quality by proposing the QA plan,

I like that. I suspect its main benefit will be to force the working
group to think about QA and to be explicit in the commitment to
achieving it.

The nice thing about your suggestion is that it imposes a basic
requirement and lets the proto-working group participants figure out how
to achieve it. That's a very IETF style of solving things.

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 17 Dec 2003 08:40:04 -0800

Pete,

>>stuff is that we don't get very good people as WG chairs.

PR> Straw man. I've certainly never said that.

It is pretty close to something that I said.  Of course, I tried to be a
bit more diplomatic, casting the problem in terms of working group
chairs having less experience.

The simple point is that we already have a power with ADs sometimes
exercising their power inappropriately, so we should assume that moving
things down to the chair will suffer at least as much of a problem.
Given that chairs are usually less experienced and are chosen in a
different fashion, the problem could become much worse.

This is where reference to the IETF's being a volunteer organization is
so important. The troops really are in charge.  When we run things
without paying attention to that, we get volunteers who leave, by giving
up on the working group.

d/

---

From: Alex Conta <[email-masked]>
Date: Tue, 16 Dec 2003 18:39:06 -0500

Please see in line

James Kempf wrote:

> flawed. 

How is this fairness and impartiality supposed to work in case the WG 
chair is an author or co-author of a competing spec? Would a chair ever 
block a document he is author or co-author of?

I've seen enough in the last 10 years or so in IETF to say that in 
current conditions, I think this very basic contention is wrong.

Alex

---

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

Please see in line

> The Chair and WG need to work as a team.

In many SDOs, chairs are only moderators, which keeps them (more) 
impartial (than otherwise).

One of the problems in IETF today is that chairs are not only managers, 
they can be in the same time developers, and measurer of quality. A 
direct effect is that they can measure favorably, and promote the work 
they take part in developing. More power in measuring and policing 
quality can exacerbate the problem.

Alex