Re: Rough consensus? #425 3.5

At 11:50 AM 1/23/2005, John C Klensin wrote:


I deleted all the stuff I agreed with - e.g. most of it.  I'm afraid I 
agree with you that there a vast chasm of differences on this topic.  I 
also agree with you that the body should be independent and that others 
disagree.  *sigh*  In any event I'm pretty close to my last comment on this 
issue.  Some specific comments below:
> Looking at your specific questions in this context:
>
> > What's the goal of the reconsideration or review?  E.g. can
> > this action result in the IAOC or IAD reversing or revising a
> > decision?  If not, why do it?
>
> It can result in a reversal or revision of a decision.  Whether
> it does, even if  the IAOC agrees with the complaint, is up to
> the IAOC.   And, even if that "even if we agree, we aren't going
> to change the decision" result can be anticipated, we should do
> it because it is almost inevitable that we are going to learn
> about what should be done here as we go along.  That makes "hmm.
> good point, we will do it differently next time" a valuable
> result -- perhaps the most valuable result.
The "hmm good point" is agreed.  I just think that doing it as a process 
review (e.g. during the public meeting) instead of a decision review is the 
right level of oversight for the broader community.  In other words the 
"public" doesn't get to cause the IAOC to begin a random fire drill, but it 
can cause them to do an in depth analysis of any specific decision during a 
public hearing.  The IETF may choose after that hearing to twiddle with the 
BCP, but not with the decision.

> > What's the statute of limitations for a demand for
> > reconsideration or review? Is an action or decision subject to
> > reexamination 6 months after the decision?  Does the IAD or
> > IAOC need to announce such decisions with enough of a waiting
> > period that the reexamination process can take place before
> > the decision becomes final?
>
> I hope we can avoid the waiting period, precisely because I
> don't ever want to see the potential of that much
> micromanagement from outside the IAOC (as should be obvious from
> the more general comments above).  But there is no statute of
> limitations.  The only real limitation is that, the longer one
> waits, the higher the odds that the IAOC will respond "will
> consider this the next time an issue like this arises" rather
> than "we will change the decision".   And, if the times start to
> get really long the odds rise that the IAOC will respond with
> "waste of time to consider this" (or not respond at all.
Goes back to whether something is reversible/revisable or not.  If its not, 
then the complaints are just so much make work.  If it is, then theres the 
possibility the IAOC will halt implementation of something important just 
because of a complaint (e.g. IAOC make decision, starts process to 
implement, complaint comes in, IAOC pauses implementation until the 
complaint process completes; 5 years later IAOC is still arguing with two 
very vocal IETF members on the proper way to implement).

> > What is the exact set of decisions subject to this process?
> > Everything?  Meeting sites?  Meeting fees?  A delay in
> > publication of an RFC?  Cost of paper needed to support an
> > IETF meeting?  The date of the public meeting?  Etc.  If we
> > can't come up with a description of this that isn't
> > "everything" I'm very concerned, but I'm having problems
> > figuring out what smaller set is appropriate.
>
> Everything, although I'd expect some of the things you list to
> get very brief consideration.  And, to give an example I'm sure
> won't arise in practice, if the IAB or IESG were to demand that
> the IAOC review explain the cost of paper at frequent intervals,
> I'd expect the IAOC members to make that, and its impact on
> getting work done, known to the community, the nomcom, etc.
I'm confused - I thought you were in the hands-off camp.  OK - let's 
consider one very specific case - meeting site selection.  Please describe 
all the actions possible around this decision listing the IAOC, ISOC, IAD, 
IASA, IAB, IESG and IETF in general.  Please explain what should happen if 
we announce we're going to Beijing and 10 IETF participants complain for 
various reasons and cite the fact the meeting cost would be less in 
Minneapolis.  Does the IAOC *really* need to respond to this formally?  By 
the time things are announced they are contractual and are generally not 
subject to revision without great expense.
Another case.  Selection of the IASO.  The IAOC/IAD writes and issues an 
RFP.  They receive bids, evaluate them and with the ISOC issue a contract 
for services.  Does the public in general get to challenge the signing of 
the contract with org A?  Can the IAB/IESG force the IAOC to reconsider the 
award if they don't like the result?  Is that even legal?
Last case.  IAOC/IAD take to heart the section that only the IAB/IESG can 
compel response.  The IAOC/IAD keep getting 10's of complaints about small 
things which they decline to spend anytime on.  The 10's of complaints come 
from the same 10-20 people.  The IETF body as a whole says - "why are you 
ignoring our rightful complaints?".  What happens then?  Does the IAB/IESG 
start compelling responses?  Why not just have the complaints go to the 
IAB/IESG in the first place and have them filter them to the IAOC/IAD?
> > Who gets to kick this process into starting (e.g. who gets to
> > file a complaint)?
>
> Anyone, but only the IAB or IESG can demand a response.
I'm pretty sure that distinction won't work very well.  See above.

> Is that what I'd like in a perfect world?  Nope.  Do I think it
> will need tuning over time, probably in the direction of more
> IASA autonomy?  Yes, but maybe not in ways that change the BCP.
> But I think that, given the divisions in the community over this
> issue,  it is probably about the best that any of us will be
> able to get.
>
> regards,
>      john
John - all I'm looking for are specific worked examples.  E.g. take various 
cases and work through how they should be handled. Document each step.  See 
if there are common processes for each case. Determine the cost/benefit 
analysis from those processes (e.g. does doing X actually improve the 
behavior of the IAOC?) Derive the BCP from those processes.  Right now the 
BCP describes a process that hasn't even been validated on paper or on a 
white board.  We have neither rough consensus nor running code.




_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf