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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf