Just to clarify my opinion: I think that B is the desirable end
state, for the reasons Harald gives, but that A with a solemn
commitment to migrate to B is the best way to get started
quickly.
Incidentally, it occurs to me that starting with A and migrating
to B doesn't exclude a further migration to C later.
Brian
Harald Tveit Alvestrand wrote:
Following up on Leslie's mail of Friday, and a number of posters (Brian,
Scott, Margaret) who have said something on the order of "I think I
prefer A or B, but I don't understand the difference"..... my particular
perspective..... in order to avoid misunderstandings, I'll define a few
terms first, as used in this memo:
- Bylaws (a bylaw?) is a document that tells how a formally constituted
organization expects itself to behave.
- An MOU is a document that tells the reader how two organizations are
supposed to behave in relation to each other.
- An IETF (Procedure) BCP is a document that tells the IETF how the IETF
expects the IETF to behave. So it may be something like a bylaw for the
IETF.
In the "Option A" scenario, we say that we have BCPs defining the
function - IETF makes agreements with itself. This is necessary. We also
say that it is sufficient. The key phrase from the report:
o The responsibilities that the IETF Administrative Director
would have with respect to IETF activities would be
determined by standard IETF processes (BCPs, RFCs, etc.)
These BCPs are the IETF's expectations on IETF behaviour. They cannot
constrain the behaviour of ISOC, unless ISOC makes an explict commitment
by Board resolution to do so, as it has done for its roles in the
standards process, the Nomcom process and IPR issues.
ISOC's behaviour continues to be governed by the ISOC bylaws and
articles of incorporation (published as RFC 2134 and RFC 2135), as
subsequently modified by ISOC.
(current ISOC bylaws are at
<http://www.isoc.org/isoc/general/trustees/bylaws.shtml>)
(note - RFC 2031 describes the ISOC-IETF relationship, as it was
understood at the time. This document is not an MoU.)
In the "Option B" scenario, we say that this is not sufficient to give
the transparency, clarity and stability of relationship that we desire.
In addition to what ISOC's bylaws and board resolutions say now, we want
commitments of ISOC.
This commitment can take several forms, some of which are mentioned as
mechanisms in the consultant report:
- Declarations in the form of changes to ISOC bylaws to enshrine ISOC's
commitment to the IETF support function (Mechanism 1)
- Promises from ISOC to the IETF community in the form of an MoU between
ISOC and the IETF (Mechanism 5)
- Changes to the ISOC governance structure so that it is more likely
that any potential conflict will be detected early, and that action will
be taken to fix it in a manner that is satisfactory to the IETF
(mechanisms 2, 3, 4, 6, 7)
I, personally, think that if we want a stable, long term relationship,
something more than the "Scenario A" status quo is necessary. I have
great trust in the commitment to IETF of Lynn as President and Fred as
Chairman of the Board. But ISOC has had 2 Presidents and several
Chairmen of the Board while I have been watching. Enshrining the
prinicples that Lynn and Fred are supporting in text that will endure
beyond their tenure seems appropriate to me.
Harald
PS: This note is NOT a statement of opinion about the relative merit of
scenarios A, B, C and D.
It is only about scenarios A and B.
_______________________________________________
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