Bert, I think Pete proposed "the IAS BCP should not take effect, regardless of what other provisions it contains, until ISOC modifies their bylaws in a way dictated by the IETF and, presumably, by provisions to be incorporated by the BCP". That strikes me a fairly concrete. My response was, admittedly, more abstract, but its bottom line is that, IMO, no such modifications or text are needed and that, if there really were a problem, what Pete proposes is the wrong way to go about solving it. john --On Sunday, 12 December, 2004 21:06 +0100 "Wijnen, Bert (Bert)" <bwijnen@xxxxxxxxxx> wrote: > 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