Is it just me or what???? This debate between John and Pete seems to be at such an abstract meta level to me, that I have difficulty to try and see what it means for the IAS BCP doc that I thinkwe are trying to get consensus on. As I said, it could be just me, but I seem unable to map it to any issue(s) with the curremt text in rev 02 of the doc. Bert > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]On Behalf Of > John C Klensin > Sent: Sunday, December 12, 2004 16:44 > To: Pete Resnick > Cc: ietf@xxxxxxxx > Subject: Re: Assuring ISOC commitment to AdminRest > > > --On Saturday, 11 December, 2004 16:00 -0600 Pete Resnick > <presnick@xxxxxxxxxxxx> wrote: > > > On 12/11/04 at 3:07 PM -0500, John C Klensin wrote: > > > >> I suspect that, were ISOC to start changing their bylaws in > >> this sort of direction and in ways that would actually > >> provide the guarantees you want, they would reasonably > >> insist on reciprocal provisions that would prevent IETF from > >> unwinding the relationship without cause, would permit them > >> to step in if they concluded that IETF was about to > >> self-destruct (or fizzle out) -- see my earlier note on the > >> implications of IETF's going under--and so on. > > > > As far as preventing the IETF from unwinding the relationship: > > To unwind the relationship from the IETF side would take a > > change in the BCP, with IETF-wide consensus. It is exactly > > that fact, and the fact that the current state of affairs only > > requires a simple majority of the ISOC board to unwind, which > > I think mandates this. Unwinding the relationship on the IETF > > side would be a "big deal". > > As far as I can tell, to unwind the relationship in practice > requires, in practice, an assertion of an emergency and decision > by the IETF Chair, perhaps in collaboration with the IAOC Chair > (if it turns out to have one) and/or IAD. Doing it that way > would require simply ignoring the proposed language of the BCP, > but there is, unfortunately, significant precedent for just such > actions. And before I go on, I want to repeat that my one of my > two main concerns is less with your note than with the concern > that we are focusing our risk analysis and protection mechanisms > in the wrong place. > > > As far as self-destruction: If such is imminent, I cannot > > imagine that the ISOC board can not get four-fifths of > > themselves (the amount needed to make a by-law change) to > > agree to rescind the by-law I propose. > > Rather than debate the appropriateness of various analogies (I > think we aren't going to agree), let's take this up an > abstraction level. The conventional wisdom about good-quality > standards is that one should specify requirements and behavior, > not particular technologies and mechanisms. I suggest that the > same rule should apply here. Suppose you had said > > "It is unreasonable for the IETF to require a whole > BCP-approval and publication process to unwind, while > ISOC would require only a majority vote. We need to > work out a model with ISOC that requires a more serious > process, perhaps a supermajority vote." > > Despite some concern about a focus on the wrong risks (see > above), you probably would have heard nothing from me. Or > perhaps you would have heard a suggestion that maybe a single > Board vote might not be sufficient and that something else -- > e.g., approval from the AC as well, Board votes at consecutive > meetings -- might be more helpful than a one-meeting > supermajority. But I don't know much, if any, more about how to > predict internal ISOC dynamics than you do, so I would think > that the above would lead to an interaction with ISOC in which > the IETF would say, more or less, > > "It doesn't feel to us that your needing only a simple > majority of the Board, at one meeting, to blow this off > is sufficient protection for this agreement. What > would you suggest, within your procedures and dynamics, > to solve that problem?" > > That is consistent with the sort of partnership I think we > should be looking for here and which I think the community more > or less signed off on in moving toward Scenario O. > > But your note doesn't seem to say that. Instead, it seemed to > say, at least in my reading, "we should not let this go through > unless ISOC agrees to Bylaws changes that are dictated by the > IETF". I don't know what the implied "or else" clause is, > unless someone is looking for an excuse to return to Scenario C, > certainly we won't give up on reorganizing entirely if they > don't. > > I don't want to see ISOC dictating anything to the IETF. I > don't want the IETF dictating anything to ISOC. I want to see > a partnership in which the two organizations work together to > identify and solve problems, with reasonable assumptions of good > faith. Those assumptions should at least be good for today, > even if you (or we) insist that future behavior is completely > unpredictable. And, within the context of those assumptions, > we should be dealing with each other on the basis of "we see a > problem on your side of the boundary, please suggest to us how > you would like to solve it or explain why it really is not an > issue". If, as I have been saying for many months, we treat > each other as hostile parties rather than as partners working > together for common ends we both value, this just isn't going to > work, no matter what words we get on paper. > > john > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf