Re: On the difference between scenarios A and B in Carl's report

[Brian E Carpenter <[e-mail]>]

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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/ietf
> 

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf