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

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 06 Sep 2004 09:32:02 +0200

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Sep 2004 11:19:51 +0200

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:
> 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 
> 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:
> 
> 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.
> (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.
> 
> - 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)
> 
> 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
>

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 6 Sep 2004 10:19:15 -0400

Hi Harald,

At 9:32 AM +0200 9/6/04, Harald Tveit Alvestrand wrote:
>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.

Any of the choices that you have put forth would require an explicit 
resolution by the ISOC Board of Trustees.  I don't personally think 
that one type of ISOC Board resolution represents a lesser commitment 
than another, and I believe that ISOC's track record shows that we 
take the responsibilities quite seriously that we have accepted based 
on IETF BCPs.

At 9:32 AM +0200 9/6/04, Harald Tveit Alvestrand wrote:
>- Declarations in the form of changes to ISOC bylaws to enshrine 
>ISOC's commitment to the IETF support function (Mechanism 1)

Just  a point of clarification:

The ISOC By-Laws do not say anything about what ISOC does.  They only 
describe the top-level ISOC governance structure, such as the 
responsibilities of the ISOC President and Board of Trustees.  The 
By-Laws don't even state how the Board is constituted or selected, 
those decisions are left to the Board.

What changes would you suggest at this level to enshrine ISOC's 
commitment to the IETF support function?

It would make more sense, IMO, to update ISOC's guiding principals 
and mission (http://www.isoc.org/isoc/mission/principles/) to include 
an expanded responsibility for IETF support.

>- Promises from ISOC to the IETF community in the form of an MoU 
>between ISOC and the IETF (Mechanism 5)

I don't understand what legal entity would hold up the "IETF" end of 
this MOU.  Currently when someone needs to make a contract with the 
IETF (the RFC Editor, another standards group, a hotel, etc.) that 
contract is signed by either ISOC or CNRI/Foretec acting on behalf of 
the IETF.  Do you know of  some way that the IETF (by which I think 
you mean the standards development portion) can be an MOU signatory? 
Would the IETF approve the MOU by publishing a BCP on our end?

>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 

I have some quibbles with the specific mechanisms described in Carl's 
document, but something along these lines might be feasible.  I don't 
personally think that these changes are necessary, though, because I 
believe that the ISOC and IETF governance and funding models are 
already sufficiently intertwined.

IMO, no set of BCPs, MOUs, By-Laws or rules will ensure the 
philosophical and strategic alignment of two separate communities 
over the long term.  Either there is natural alignment (because we 
are comprised of and accountable to a single community, as I believe 
that the IETF and ISOC are today) or there is not.  The real answer 
to maintaining ISOC's alignment (or the alignment of any corporation) 
with the IETF community is for the IETF community to remain actively 
engaged in ISOC.  We can do this by becoming members of ISOC, 
volunteering to serve on the ISOC Board or ISOC committees, joining 
ISOC chapters, participating in ISOC Board member elections, 
influencing the choice of IETF-selected Board members, responding to 
ISOC opinion polls, attending ISOC Board meetings, etc.

Although there is already a significant level of engagement between 
ISOC and the IETF community, I think that an increase in ISOC's 
responsibilities to the IETF should be accompanied by an increase in 
IETF community engagement in ISOC.  This increased engagement may 
happen as a natural outgrowth of ISOC taking increased 
responsibility, or we may need to do some things to encourage it.

Margaret

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2004 12:08:09 -0400

Harald,

While I think this analysis and the distinctions you draw are
reasonable, I think the presentation in the document about the
difference between "A" and "B" is deeply flawed in that it seems
to present two options, neither of which is acceptable.  Your
note hints about intermediate options (as, in fairness, does the
document introduction), but I don't see how we are going to get
there efficiently and with the clear backing of the community
that I think is necessary: the IETF list is not traditionally a
good mechanism for fine-tuning text.

In particular, if one concludes, as I gather you have, at an
"Scenario A", with no additional statements or constraints, is
insufficient, that doesn't suggest to me that we should go
nearly as far as "Scenario B" seems to suggest.   As the
"Problem Statement" effort pointed out, the IETF has a somewhat
uncomfortable history of simply ignoring provisions of process
documents that prove uncomfortable (and BCP status doesn't seem
to help), so trying to bind the IETF and ISOC more strongly by
"legal" constraints may not mean much.  I believe, nonetheless,
that clearer statements of mutual understanding and intent
(through MOUs or otherwise) are always helpful.  I also note,
with Carl, the risk that "more up-front definition is sometimes
a good thing, but can also lead to a great deal of time solving
problems that don't exist".

If we are to understand Scenario B as "identical to Scenario A,
but [with a bit] more up-front work is put into defining the
relationship." (bracketed text mine, not Carl's) than I think we
may be getting close to agreement on Scenario B (at least among
those two choices).    But, if Scenario B really means adoption
of a significant fraction of the "mechanisms" described on page
33 of the I-D, then it would be, at least for me, a non-starter.
A fairly specific MOU (Mechanism 5) seems fine, but, as the text
points out, it is hard to imagine even Scenario A without it.
But most of the rest of those "mechanisms" seem to me to be
strange,  actively harmful to either the IETF or ISOC, very
risky to the fact and appearance of an independent standards
process, or some combination of those unfortunate
characteristics.

So I am left close to the question that prompted your response,
with little additional information from that response.  I can't
parse the difference between "scenario A with MOU and maybe some
other things to be developed as needed" and "scenario B with MOU
but without pointless or risky tampering with how ISOC is
organized" ... that is, unless we take Scenario B as requiring
that everything be figured out and chiseled into granite before
we do anything.   And I suggest (and will suggest in more detail
in an upcoming note) that anything that can wait long enough for
the granite-chiseling is something that probably doesn't need to
be done at all.

   best,
     john

--On Monday, 06 September, 2004 09:32 +0200 Harald Tveit
Alvestrand <[email-masked]> 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.
>...

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 06 Sep 2004 19:57:14 +0200

Thanks, John!

> the granite-chiseling is something that probably doesn't need to

It seems to me that we are rapidly converging on one point of total IETF 
consensus:

  Putting the IETF administrative function under ISOC requires a documented 

  IETF-ISOC agreement (call it an MoU, a contract or something else - it IS
  a document, it IS an agreement and it DOES have two parties).

Agreed?

The thing that left me most uncomfortable with Scenario B as described was 
that it presented a smorgasboard of options ("here are ten menu choices - 
take your pick"), where some of them (the MoU) were totally obvious, and 
some had (in my mind) severe disadvantages. So we can't say "we go for 
scenario B" and have the discussion be finished, we have to be able to say 
"Options 1, 3, 5 and 7 make sense, the rest does not, and besides, here's 
option 17 that wasn't in the original document".

---

From: Carl Malamud <[email-masked]>
Date: Mon, 6 Sep 2004 13:25:06 -0700 (PDT)

> option 17 that wasn't in the original document".

There are 7 mechanisms listed, but in no way did I expect some substantial
number of them to be adopted.  Indeed, they are listed as straw-men and
I did not make a recommendation.  The idea was to illustrate a range of 
options and I left the hard part (deciding what to do) to the community to 
decide.  

Regards,

Carl

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Mon, 6 Sep 2004 13:28:39 -0700

At 7:57 PM +0200 9/6/04, Harald Tveit Alvestrand wrote:
>It seems to me that we are rapidly converging on one point of total 
>IETF consensus:
>

Agreed.

--Paul Hoffman, Director
--VPN Consortium

---

From: John C Klensin <[email-masked]>
Date: Mon, 06 Sep 2004 16:52:49 -0400

--On Monday, 06 September, 2004 19:57 +0200 Harald Tveit
Alvestrand <[email-masked]> wrote:

>> So I am left close to the question that prompted your
>> response, with little additional information from that
>> response.  I can't parse the difference between "scenario A
>> with MOU and maybe some other things to be developed as
>> needed" and "scenario B with MOU but without pointless or
>> risky tampering with how ISOC is organized" ... that is,
>> unless we take Scenario B as requiring that everything be
>> figured out and chiseled into granite before we do anything.
>> And I suggest (and will suggest in more detail in an upcoming
>> note) that anything that can wait long enough for the
>> granite-chiseling is something that probably doesn't need to
>> be done at all.
> 
> It seems to me that we are rapidly converging on one point of
> total IETF consensus:
> 

I think so, although I think, given some of the text in the
report and some other conversations, that I would add to "DOES
have two parties", "each of whom is assumed to be acting in good
faith, out of good intentions, and with the best interests of
the other in mind".   I don't know that needs to be explicit,
and I think those conditions are generally met today, but, as I
tried to say in my note, relying on legal agreements to protect
us if there isn't general agreement about behavior strikes me as
a bad idea.   And, incidentally, if there is a problem in that
area, I think we would hit it with Scenario C as well.

> The thing that left me most uncomfortable with Scenario B as
> described was that it presented a smorgasboard of options
> ("here are ten menu choices - take your pick"), where some of
> them (the MoU) were totally obvious, and some had (in my mind)
> severe disadvantages. So we can't say "we go for scenario B"
> and have the discussion be finished, we have to be able to say
> "Options 1, 3, 5 and 7 make sense, the rest does not, and
> besides, here's option 17 that wasn't in the original
> document".

So, to get a stake in the ground, only the MOU "mechanism" makes
obvious sense to me.   The others seem either harmful or
sufficiently muddled in the details of what they might mean that
I think significant clarification would be needed to even
evaluate them properly.   And I think I'd like to see more
discussion about what real problem we are trying to solve before
I'd think that added effort would be worth putting in.

     john

---

From: Leslie Daigle <[email-masked]>
Date: Tue, 07 Sep 2004 18:09:10 -0400

I don't think (and maybe we're in agreement here) that what
you're describing is captured at all in the current set of
scenarios.  In my reading of Scenarios A & B, the suggestion
is that ISOC takes on the administrative work more-or-less
directly.   "B" differs from "A" in that it calls for more IETF
involvement in the management of the organization that is (then)
directing the administrative work.  I.e., allowing realtime
course correction to make sure that ISOC and IETF administration
keep flying in formation in ways that are mutually acceptable.

Putting an MoU-like agreement on the table could shift the "center
of gravity" of the responsibility for the future of the administrative
activity further from the centre of the ISOC organization.  The
further out it gets, the less sense it makes to undertake
(anything like) the other mechanisms in Scenario B that get
IETF participation right into the ISOC organization.

Now, I (as a generic IETF participant) would want to see a real
draft of such an MoU before I called it a scenario and
had an opinion as to whether I thought it could solve the problems
we're looking at.  Since you clearly stated that the other Scenario B
mechanisms make no sense to you, I'm thinking you might have a clear
idea of the sorts of things that would be reasonable in such a document.

By the way, it doesn't seem to make a lot of sense to me, personally,
to talk about an MoU between ISOC and "the IETF", which either
doesn't exist or is an activity of ISOC.  I wonder if this is
something that would be better framed as an IETF process document
  -- requires IETF consensus process to change, and ISOC BoT
approval to put into effect, per our current rules.

Leslie.

> process, or some combination of those unfortunate
[and]

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
[email-masked]
-------------------------------------------------------------------

---

From: Geoff Huston <[email-masked]>
Date: Wed, 08 Sep 2004 08:25:51 +1000

>>  a document, it IS an agreement and it DOES have two parties).

Its easy to identify the first party to this MoU - its ISOC, but, in a 
formal sense,  who would be the second party? I'm not sure the division I 
work has a MoU with the CEO, nor do I think in terms of organizational 
sociology that the divisions of an entity are normally bound together with 
MoUs.

It appears to me that if we are heading down the contract / MoU path we 
have already implicitly set up the IETF as its own entity, and are now 
undertaking an outsourcing function to sub-contract activities to another 
entity.

I've also gained the impression that there is some hesitancy in taking such 
a step and assigning such role labels to the IETF and to ISOC and what we 
might be looking for here is something subtly different, which is a public 
undertaking on the part of ISOC regarding its commitment to the IETF role, 
and a public undertaking on the part of the IETF as to recognition of 
certain obligations on its part to ISOC.

    Geoff

---

From: Paul Vixie <[email-masked]>
Date: 07 Sep 2004 23:52:26 +0000

> >>  Putting the IETF administrative function under ISOC requires a
> >>  documented IETF-ISOC agreement (call it an MoU, a contract or
> >>  something else - it IS a document, it IS an agreement and it DOES
> >>  have two parties).
> 
> 
> formal sense,  who would be the second party? [...]
> 

and what is the relationship of an ietf participant to that entity?  will
we be "members" of the "ietf association"?  isoc has members.  usenix has
members.  ietf eschews not only voting, but membership and classification.
is that time over?
-- 
Paul Vixie

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 7 Sep 2004 20:09:39 -0400

>IETF participation right into the ISOC organization.

IMO, a similar shift could be achieved by forming an IETF 
community-selected board to manage this function and housing that 
board within the ISOC corporate umbrella (like the IAB is today).  I 
don't think that housing our administrative functions within ISOC has 
to mean that those functions are directly managed by the ISOC BoTs. 
And, in fact, I would prefer that they are not.

>we're looking at.

Scenario B includes the MOU mechanism as one of the choices for 
defining a relationship between ISOC and the IETF.  The draft says 
that some or all of the mechanisms could be used, so we're still 
talking about Scenario B, aren't we?  Since ISOC would clearly be one 
of the parties to this MOU, I'm not sure how useful it would be for 
the IETF to produce a draft MOU in the absence of ISOC input.

>approval to put into effect, per our current rules.

I agree with you that an IETF BCP that is published through the IETF 
document process and formally accepted by the ISOC BoTs would make 
sense as a way to formalize any changes or extensions to  ISOC-IETF 
relationship.  This model has been used to define the ISOC-IETF 
relationship in the past and it seems to be working well, IMO.

Margaret

---

From: [email-masked] (scott bradner)
Date: Tue, 7 Sep 2004 20:10:54 -0400 (EDT)

leslie sez:
> In my reading of Scenarios A & B, the suggestion
> directly. 

takes on" the admin work or "contracts vendors" to do the admin work

i.e., the difference between hiring people and paying vendors

it might make a difference if bolt blowing becomes needed

Scott

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Sep 2004 08:09:22 +0200

> takes on" the admin work or "contracts vendors" to do the admin work

takes on the admin work of contracting vendors to do the real work.

at least that's my understanding of what makes sense.

---

From: Fred Baker <[email-masked]>
Date: Tue, 07 Sep 2004 23:27:24 -0700

At 08:09 PM 09/07/04 -0400, Margaret Wasserman wrote:
>Scenario B includes the MOU mechanism as one of the choices for defining a 
>relationship between ISOC and the IETF.

for the record, I think the relationship between ISOC and IETF needs to be 
stated in any case. We have RFC 2031 now, but it is dated and could use 
revising at minimum to include the things ISOC does now and the things IETF 
participants do in ISOC. If we are going to further tweak the relationship 
- and I think we will - we need to state how it changed. So some form of 
MOU is advisable in any scenario.

---

From: Erik Huizer <[email-masked]>
Date: Wed, 08 Sep 2004 09:26:17 +0200

--On dinsdag 7 september 2004 20:09 -0400 Margaret Wasserman 
<[email-masked]> wrote:
> Since ISOC would clearly be one of the parties to
> this MOU, I'm not sure how useful it would be for the IETF to produce a
> draft MOU in the absence of ISOC input.

It would not be wrong for the IETF to discuss the contents and form of such 
an MoU, then draft it and ask the ISOC BoT to comment (and of course the 
IETF-ers), in order to reach consensus.

Erik