On my re-reading of the thread, I think:
. you are right that there wasn't substantive disagreement on
the inclusion of the text:
"This BCP will take effect upon adoption of the BCP by the IESG and the
concurrent <<insert thing that ISOC does which codifies in some
interesting way the adoption of the relationship by ISOC>>"
. but I disagree that there was considerable support for filling
the <<>> with by-law changes in ISOC.
The filling of <<>> that seemed to have support (though, as you
restated today, you don't agree with it) is the passing of a
resolution to undertake the role outlined in the BCP.
Speaking personally, I can live with inserting the text above,
with a notion of "passing a resolution" in <<>>, though I think
that the only thing that really counts at this juncture is
getting on with making this a new operational IETF/ISOC relationship
that works. (I.e., if the relationship does not work, no number of
legal phrasings will help).
That said, let me offer a few thoughts on why I specifically
don't think a by-law change is what you want. The
by-laws deal primarily in the mechanics of ISOCs structural
implementation: who is a trustee, how many trustees it takes
to do anything, etc. I know you would look to a lawyer to provide
the specific wording, but I'm trying to grapple with what sort
of a thing would be inserted here to meet your need: something
that says "ISOC will support the IETF per the structure outlined
in BCPXX" seems vastly out of place.
What I really think you're looking at is the articles of
incorporation, which spell out the purpose and reason for ISOC's
existence and operation. Those already talk broadly of a mission of
supporting Internet technology development. "Broadly" is the
key word -- this is the "generally specific" sort of text that
lawyers create when they know it's what the organization is
going to be held to in order to defend such things as tax exempt
status. The draft phrase I suggested above would not fit there;
by the time a lawyer was done making it suitably "generally
specific", I don't think you'd be any more satisfied.
So, why not a resolution, then? It's a formal record of an ISOC
BoT having declared support for this activity, with the expectation
of future ISOC BoTs adhering to the principle. Yes, a future ISOC
BoT could adopt a resolution to change or nullify that support
with little warning and less than a 4/5 majority vote. But, the truth
of the matter is, if the ISOC BoT has gotten to the point where that
seems like a reasonable course of action, we (the IETF, ISOC,
the Internet at large) are in such deep doo-doo in our relationship
that the action is not the bad news.
All, of course, in my personal opinion.
Leslie.
Pete Resnick wrote:
On 1/13/05 at 1:34 PM +0100, Harald Tveit Alvestrand wrote:
I believe #739 is a matter that requires ISOC to form an opinion
I agree; ISOC must suggest the mechanism by which they will agree to
this "partnership".
it is not something that the IETF needs to come to consensus about,
and it should not affect the text of the BCP.
I completely disagree, and I think it is not at all bourne out by the
discussion on the list. There was disagreement by some of us as to what
specific mechanism ISOC should bring to bear on this (and I agreed with
the proposal that ISOC should be solicited for that mechanism and the
IETF should come to consensus on whether that mechanism was acceptable).
However, I don't think there was any disagreement (including from Brian)
that text needed to be added of the form:
"This BCP will take effect upon adoption of the BCP by the IESG and the
concurrent <<insert thing that ISOC does which codifies in some
interesting way the adoption of the relationship by ISOC>>"
The open (and I believe still open) argument is:
As Brian Carpenter said:
I'm not saying a bylaw change would be a bad thing, in due time. But
ISOC can get a Board motion through in about 2 weeks, whereas a bylaw
change takes several months. Making it a prerequisite would cause us
to lose precious time.
And the ISOC BoT has plenty of stuff on its plate just caring for the
rest of the effects of this process, if I understand Steve Crocker
correctly.
I personally don't believe that a resolution is a sufficient mechanism
for codification of this on the ISOC side. I made the suggestion of a
by-law change, and I'm not convinced of the "takes several months"
(though I'm willing to hear some convincing arguments as to why that
should be the case). I'm willing to hear about other codifying
mechanisms. I can't speak for others, but I suspect there are others in
the same boat with me.
I suggest that we close this ticket as "no change required" - the
issue will not be forgotten, but it should not affect this document.
I object to this entirely.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf