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

["James Kempf" <[e-mail]>]

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" <[e-mail]>
To: "James Kempf" <[e-mail]>
Cc: "Dave Crocker" <[e-mail]>om>; "MPowr" <[e-mail]>rg>;
<[e-mail]>
Sent: Monday, December 15, 2003 11:59 AM
Subject: [mpowr] Re: [Solutions] Further work on WG (chair) roles - MPOWR WG
proposal


> 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: [phone], Fax: [phone]
>


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