Subject: RE: Document Blocking (Was: I-D

From: "Bound, Jim" <[email-masked]>
Date: Fri, 16 May 2003 21:35:12 -0400

I don't disagree with the lightweight process but I think it far easier
just to have an IESG member defend their pushback or whatever on the
mail list and working group. Discuss it with the members have debate.
If we use this as a more and folkway as part of the role and job of an
IESG member and document it we don't need yet another process.  The IESG
is suppose to be our partners and we just need to make a rule or
something that our partners have to the same as any member in this
community and defend and debate their push back if they want to overrule
a WG and Chair.  Now if that don't create compromise then the IESG can
be swayed by the AD to reject a proposal and document why.  Then one
uses the appeal process we have.

/jim

> -----Original Message-----
> From: Pete Resnick [mailto:[email-masked]] 
> Sent: Friday, May 16, 2003 8:29 PM
> To: Keith Moore
> Cc: [email-masked]
> Subject: Re: Document Blocking (Was: I-D
> 
> 
> On 5/16/03 at 4:27 PM -0400, Keith Moore wrote:
> 
> >I do think it would be useful to have some sort of mechanism
> >(lighter weight than an appeal) by which a WG or IESG could push 
> >back on a single IESG member's objections when they seemed trivial 
> >or poorly founded.
> 
> Agree completely. I think that's what I've been looking for.
> 
> >I don't have a good suggestion for how to do that, but I do feel
> >certain that requiring IESG consensus on every Discuss is too 
> >onerous.
> 
> Actually, I think with such a lightweight mechanism in place, this is 
> exactly what you get: If someone says "discuss" and the rest of the 
> IESG thinks it is reasonable (even if they don't exactly understand 
> the details of the problem), then the IESG as a whole has rough 
> consensus to discuss. If a large proportion of the IESG thinks it is 
> trivial or poorly founded, then the IESG does not have consensus and 
> the mechanism can be used to push back on the "discuss".
> 
> Don't get hung up on "consensus" when thinking about it in the 
> context of the current process. In the current process, I consider 
> one "discuss" and the rest "no objection and the discuss seems legit" 
> to be consensus to discuss. It's just that in the current process, 
> that is indistinguishable from one "discuss" and the rest "no 
> objection and the discuss sounds like complete nonsense to me and no 
> one has explained to me what the problem is." The latter isn't 
> consensus, and I think we agree that we don't like the latter, 
> however rare it might be.
> 
> >>As Dave said, "No matter how stellar the expertise of someone, if
> >>they cannot convince others that their views are correct, something 
> >>is very, very wrong."
> >
> >And sometimes Dave is very, very wrong.
> 
> Thanks, that really helped progress this discussion. :-(
> 
> (Let's try to keep this nonsense out of the discussion from now on.)
> 
> >What I might argue instead is that if success of a protocol hinges
> >on something that is too subtle for most of its implementors and 
> >designers to understand, that success is doubtful even if the 
> >protocol specification properly considers that subtlety. But even 
> >that isn't always true.
> 
> Perhaps, but again, if these occurrences are rare anyway, I don't see 
> why we cannot expect an expert to explain this to the satisfaction of 
> at least the rest of the IESG, if not the WG.
> 
> >Right, but IESG has timeouts in place for almost all phases of its 
> >deliberative process.   It's the WG that can hold up things for 
> >arbitrary amounts of time (sometimes because the authors and/or
> >chair are sitting on the document and the WG doesn't know what is 
> >happening, sometimes because the WG refuses to make changes and 
> >doesn't know what to do next).
> 
> Let's not get into finger pointing here. We both know of situations 
> where a document is stuck in the WG (for both unreasonable and 
> reasonable cause), we both know of situations where the IESG has 
> ignored timeouts (for both unreasonable and reasonable cause), and we 
> both know of cases where the token has gotten lost (which can occur 
> even now with the tracker, when there is a discuss item that the WG 
> doesn't understand and can't get enough feedback to fix). We've been 
> talking about unsticking at one point, within the IESG. It is a 
> separate problem to deal with unsticking within the WG, which is 
> probably even trickier.
> 
> >Now it might be useful to have a well-documented process by which
> >IESG provides feedback to a WG on a document, including public 
> >disclosure of the feedback on a web page, and to have an explicit 
> >timeout by which a WG is expected to:
> >
> >a. revise the document and resubmit to IESG
> >b. outline a plan for fixing the document and ask for 
> approval of  that 
> >plan c. abandon the document d. appeal
> 
> Agree wholeheartedly.
> 
> >But it would be even more useful to try to get an explicit dialogue
> >going between the relevant ADs and the relevant WG participants, 
> >because most problems can be solved in this way.
> 
> Most of the time, I think that actually exists. I think what we are 
> talking about here is solving the problem for the times that it 
> doesn't, because those failures are what sticks out like a sore thumb 
> (and engenders distrust between the IESG and the rest of the IETF).
> 
> >(Even before we had public disclosure of the IESG ballots, new ADs
> >learned fairly quickly that raising substantial objections could 
> >cost them both in terms of ease of working with other IESG peoople, 
> >and in temrs of the time spent in discussion with the relevant 
> >parties to try to work out the differences. So there's a significant 
> >incentive to avoid raising non-trivial objections, sometimes even 
> >when they're fairly important. One result is that ADs raise trivial 
> >objections when more serious objections are really warranted.)
> 
> I've heard this from several former ADs, and perhaps it indicates a 
> further problem: The idea that because one AD raises substantial 
> objections, other ADs would make life difficult for him or her, and 
> that trivial objections do not cause that, is unbelievably bad. It is 
> a further indication of distrust among the ADs in the IESG, the very 
> same thing that would make anyone think that "a way to stop bad 
> things from happening" type of veto is necessary. I find the idea 
> that any AD would behave this way instant grounds for recall. The 
> IESG is supposed to be acting as a group to do global-issue review. 
> If new ADs are forced to hold their tongues, we need to start 
> replacing the old ADs.
> 
> As far as time spent discussing the problems, it seems that a 
> knowledgeable directorate would solve that problem.
> 
> >>I would be deeply concerned if there were one or two Discuss, two
> >>Yes, and the rest No Objection *and* the Discuss voter(s) couldn't 
> >>convince any of the Yes or No Objection people to change their 
> >>votes to Discuss.
> >
> >That's not the way it works. Since every Discuss vote has to be
> >explicitly changed before the document can move forward, issues get 
> >resolved faster when there are fewer Discuss votes, and the polite 
> >thing to do is to not vote Discuss when someone else has already 
> >raised the same objection. so if you get multiple Discuss votes only 
> >when there is a very strong and widespread objection to a document, 
> >or when there are widely varying objections to a document.
> 
> I know that's not the way it works now. But now that the process is 
> becoming more public (due to the tracker), I really think it needs to 
> be that way. At the very least, you should never see a single Discuss 
> and two Yes votes; that would be an indication (to an outside 
> observer) of serious disagreement in the IESG and something that 
> needs explanation.
> 
> pr
> -- 
> Pete Resnick <mailto:[email-masked]>
> QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: 
> (858)651-1102
>

---

From: Keith Moore <[email-masked]>
Date: Fri, 16 May 2003 21:40:16 -0400

> IESG member and document it we don't need yet another process. 

My intuitive sense is that IESG has more than enough process already, which is
part of why I'm resisting suggestions to impose more requirements on them.