ietf
[Top] [All Lists]

RE: Assuring ISOC commitment to AdminRest

2004-12-12 13:14:28
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