RE: Assuring ISOC commitment to AdminRest

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(_at_)lucent(_dot_)com> 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(_at_)ietf(_dot_)org 
> > [mailto:ietf-bounces(_at_)ietf(_dot_)org]On
> > Behalf Of John C Klensin
> > Sent: Sunday, December 12, 2004 16:44
> > To: Pete Resnick
> > Cc: ietf(_at_)ietf(_dot_)org
> > Subject: Re: Assuring ISOC commitment to AdminRest
> >
> >
> > --On Saturday, 11 December, 2004 16:00 -0600 Pete Resnick
> > <presnick(_at_)qualcomm(_dot_)com> 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(_at_)ietf(_dot_)org
> > https://www1.ietf.org/mailman/listinfo/ietf




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