Subject: [Iasa20] Thank you & we need your feedback

From: Jari Arkko <[email-masked]>
Date: Wed, 1 Nov 2017 18:53:55 +0100

Thank you for the feedback we’ve received so far (incl. some off-list). Much appreciated, and we are looking at it carefully.

I would like to ask for more people to look at the document, and do so even before the meeting, here on this list. I believe Alissa’s plan is to come out of Singapore with a sense of the community on which direction to pursue, and that can be best achieved if at least some of the substantive discussion can happen before our meeting, and we can better prepare for the questions and ideas people will have.

The document is here:

https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01 <https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01>

Jari for the design team

---

From: Matthew Ford <[email-masked]>
Date: Fri, 3 Nov 2017 12:25:01 +0000

Hi Jari,

Thanks to you and the rest of the design team for this document - it is clear that a lot of work and thought has gone into it. I offer some personal comments (and identify a few editorial nits) below. These are strictly my personal reflections as an IETF participant.

To the questions set out at the beginning:

   o  If the set of options outlined in this draft covers the options
      that should be looked at.

MDF: Yes.

   o  If the analysis of the implications of the options is correct.

MDF: Broadly yes, although see my comments below.

   o  Which direction the community would like to take the work in
      evolving IASA.

MDF: My view is that the subsidiary option provides the means to address the identified issues without incurring the unnecessary additional challenge and expense of the independent org option. 

   IETFAdminOrg will be required to operated in a transparent fashion

MDF: Nit - s/operated/operate

   o  Improve the IETF's Technical Environment: Undertake changes to
      better enable technical contributors to focus more on that
      technical work and less on administrative work or support
      activities.  This could for example mean directing more financial
      resources towards the creation of new or improvement of existing
      tools, which might be produced by contractors rather than solely
      by volunteers.  As a result, volunteers could instead focus on
      developing the standards themselves.

      Thus, if the core competency
      of IETF attendees and their reason for participating in the IETF
      is to develop standards, then create an environment where they can
      focus exclusively on that activity and delegate to contractors,
      staff, or other resources the responsibility for creating and
      maintaining tools and processes to support this activity.

MDF: This makes me uneasy. For this to work well, the responsiveness of contractors/staff/other resources to the community is key. To date the community has done an impressive job of building the tools it wants for itself. The people who build those tools know what the community thinks about them and hears about ways they can be improved and extended because they are part of the community. I’m worried we get to the point where IETFAdminOrg buys off-the-shelf solutions to solve a management problem at the expense of the fine-grained needs of the community.

   o  Clearly Define the IETF-ISOC Relationship: Define the roles of
      IETF and ISOC in a way that helps the above structure be as clear
      as possible, in terms of who does what, how are things accounted
      for, and who is in charge of adjustments and control (e.g., staff
      resources).  This also includes consideration of a new funding
      model that takes into account the historical responsibility for
      the IETF that ISOC has had since its inception.

MDF: To the extent that the relationship between IETF and ISOC is of ongoing importance then I think this will need care. The two organisations benefit most from collaboration rather than rule-following. I agree that things may have gotten to the point where more clarity is required, but I’m just cautioning that providing clarity doesn’t necessarily come without potential downsides too. Continuing to allow for flexibility and creativity in how the two organisations work together is important.

   o  Clarify Overall Roles and Responsibilities: Ensure that all staff,
      contractor, and volunteer roles are clearly documented.  This
      necessarily includes documenting how each of these parties may
      interact or interface with one another in order to conduct and
      support the business of the IETF.  This also includes documenting
      key work processes, decision-making processes and authority (such
      as pertaining to meeting venue selection), etc.  A key objective
      is to minimize ambiguity and uncertainty so that it is clear who
      is responsible for what and who has the power to make certain
      decisions.

MDF: I agree that such documentation and clarity is needed. I think we should strive for it to be as lightweight as possible - it shouldn’t be hard for people in these roles to know what the right thing to do is without referring to lengthy business process documentation.

   o  Re-Define the Role of the IETF Community in Relation to
      Administrative Activities: As the roles and responsibilities for
      support staff and volunteer roles are clarified more precisely,
      the role of the IETF community in relation to those staff and
      volunteer roles must be better defined.  This should acknowledge
      the limited time and availability of IETF volunteers, better
      defining expectations around oversight of and involvement in
      strategic, operational, and execution tasks within the
      administrative efforts.

      The new design needs to ensure that volunteers are not overloaded
      in such things as low level operational decisions, which can be
      delegated to and handled by staff, and can instead focus on
      strategic changes, critical decisions, and so on.  In particular,
      this should focus on clearly documenting the lines between
      responsibility, representation, authority, and oversight.

MDF: There is a tension between the primacy (as I see it) of the IETF Community in its broadest sense, and the lack of interest in or time for administrative work. The risk of capture by the AdminOrg is very real I think. While delegation is clearly necessary, some things can’t be delegated. Luckily we are blessed with a community that is pretty vocal about things it doesn’t like :-)

   o  Define Improved Transparency Requirements: The general level of
      operational transparency and information-sharing between IETF
      administrative staff and groups to the IETF community must be kept
      at an acceptable level, and improved where it makes sense in the
      future.  This includes ensuring the timeliness of sharing of
      information and decisions, as well as seeking comment on
      prospective decisions.  At the same time, we need to reset
      expectations around delegated authority so that once staff or an
      administrative support organization has been delegated certain
      authority it is clear that they are empowered to proceed in a
      particular area, so as to improve organizational efficiency,
      reduce friction, and improve the pace of work and decision-making.
      However, it is clear that enabling a group or staff to act within
      their delegated authority depends upon a clearer definition of
      roles and responsibilities, on improved transparency, on improved
      communications, and on trust (which is built upon all of those
      things over time).

MDF: Yes! Strongly agreed.

5.1.3.  Independent Organization

   In this option, a new non-profit organization (IETFAdminorg) is
   created independent from ISOC as the new legal home of the IETF.
   IETFAdminOrg would have its own bank account, by-laws, charter,
   board, staff, and corporate identity.  The administrative staff for
   IETFAdminOrg could be kept lean and would likely rely on contractors
   for the bulk of administrative tasks.  Minimally, the IETFAdminOrg
   staff would be responsible for administration, development/
   fundraising, communications, and personnel management.

   In the independent organization model, IETFAdminOrg's continued
   existence would not depend on the ISOC organization's choices about
   its future.

MDF: Except that it would, for the reasons you articulate below. To be more constructive, given the constraints below, how would the independent org option differ in practice from subsidiary option? Would it be an explicit goal of an independent org to develop fundraising to the point where ISOC support was not required?

   However, IETFAdminOrg would still depend on the ISOC's
   support, for two reasons:

   o  ISOC's role in supporting the IETF, and

   o  As a practical matter, IETFAdminOrg is not financially viable
      without ISOC's support.

   In order to establish this model, IETFAdminOrg and ISOC would need an
   explicit agreement that outlined expected levels of financial support
   going forward, both in terms of founding endowments and in terms of
   ongoing support.  These agreements might also cover IETFAdminOrg's
   obligations to ISOC, such as the level of reporting from IETFAdminOrg
   to ISOC, and the expected structure of any liaisons.

MDF: Given these constraints, I don’t see the practical difference between this option and subsidiary.

   As in the ISOC Subsidiary model, it would be necessary to transfer
   the existing relationships to IETFAdminOrg.  See the previous section
   for details on this.

5.2.  IETFAdminOrg and the Relationship with IETF

   o  The IETF would provide oversight into the governance of
      IETFAdminOrg, including seating part of the board.

MDF: A majority of the board?

5.3.  Oversight for IETFAdminOrg

   While IASA++ could continue to have an oversight structure populated
   by members of the IETF community, either the Subsidiary or
   Independent models involve the creation of an IETFAdminOrg which
   would need to have its governance structure defined.  This structure
   needs to include the involvement of members with significant
   nonprofit governance experience, while also ensuring accountability
   to and involvement from the IETF Community.

   In order to achieve these objectives, the design team proposes a
   model similar to other nonprofits, in which IETFAdminOrg would be
   governed by a Board of Trustees.  This board, the IASA Board (IB),
   acts to set strategic direction for IETF administrative matters, sets
   budgets, provides fiscal oversight, provides high-level oversight
   about major new projects, and so on.  The board is also responsible
   for hiring and assessing the performance of the Executive Director
   (the highest-level staff director (see Section 5.5).

   The board works with staff who is empowered to carry out the
   operations as directed by the board.  The staff is responsible for
   operating within the limits set by the board, and are accountable to
   the board.

MDF: These is confusing to me at least. A clearer model would be for the board to set high-level goals and make strategic decisions. The ExecD should be accountable to the board, the staff would be accountable to the ExecD. Otherwise we’re back to the confusion around accountability and lines of authority that we have today.

5.4.  Transparency

   Regardless of the chosen reorganization model, transparency deserves
   attention.  As discussed in Section 4, this includes improving the
   timeliness of sharing of information and decisions, seeking comment
   on forthcoming decisions, and a a "reset" of expectations around

MDF: Nit - s/and a a/and a/

   delegated authority.

   In addition, there needs to be an agreement between the IETF
   community and the administrative entity about the where to draw the

MDF: Nit - s/about the where/about where/

   line between community's need for information, and the need to keep

MDF: Nit - s/between community’s/between the community’s/

   some business (or personnel) data confidential.

5.5.  Staff Structure

   o  Director of Operations.  This person is responsible for meeting
      arrangements, IT, tools, managing contracts (including RFC Editor
      and IANA), and day-to-day budget management.

MDF: This role sounds to me like the current IAD and seems quite overloaded - I wonder about assigning some of these tasks elsewhere (e.g. to the ExecD)

   It's worth considering short-term (3-5 years) and long-term (5-10+
   years) plans differently.  In the short term, we can continue to rely
   on our existing funding sources regardless of which organizational
   model we end up with for IASA 2.0, including the independent
   organization model.  The role of ISOC as providing the funding to the
   IETF and agreeing to help us if we get to trouble should stay under
   all of the options, until or if a future funding model change changes

MDF: Nit s/change//

   that.

   While ISOC continues to support IETF financially as they have
   previously, the different reorganization options affect the legal,
   contractual, and accounting related details.  While continuing as-is
   is possible, adopting a a more predictable allocation of funding is

MDF: Nit s/a a/a

   desirable (see Section 5.6.3), and in the subsidiary and independent
   options formal contracts about the funding are also necessary.  The
   exact details of those contracts and contracting parties are for
   further study, but they do not need to change the fundamental
   arrangement that is in place today.

      Sometimes even administrative decisions can impact the nature or
      culture of the IETF, such as when improvements in remote
      attendance support are adopted.  A clear interface between the
      community and the IETFAdminOrg is helpful in specifying what role
      the community and other parts of the system play.  The nomcom-
      appointed board members and the Advisory Council have clearer

MDF: Whether board members are nomcom-appointed or appointed via some other mechanism is still an open question right? So this should probably just say ‘board members’. Also, s/have clearer/have a clearer

      role, and have a more community-focused role in the new
      arrangements to ensure that the community has a strong voice.

   o  Clarify Overall Roles and Responsibilities:

      The reorganization is an opportunity to rethink what staff roles
      are needed, staff levels, whether to organize a function as a
      staff function or as contracted service to a vendor.  All options
      are likely to provide clarified roles and responsibilities.

      However, in IASA++, some of lack of clarity may remain, as lack of

MDF: Nit - s/some of lack/some lack/

      clarity inherent in two organizations controlling resources may
      remain.  In general the subsidiary and independent organisation
      models ensure better tha the IETF community and the IETF

MDF: Nit - s/tha/that

      administrative functions have authority to perform exactly the
      kind of adminstration they want.

      The independent organization model eliminates all ambiquity about

MDF: s/ambiquity/ambiguity

      the IETF having authority independent from ISOC over staff, funds,
      and decisions.

Mat

> On 1 Nov 2017, at 17:53, Jari Arkko <[email-masked]> wrote:
> 
> https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-01
> 
> Jari for the design team
> 
> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Wed, 08 Nov 2017 18:13:34 +0000

> MDF: Except that it would, for the reasons you articulate below. To be
more constructive, given the constraints below, how would the independent
org option differ in practice from subsidiary option? Would it be an
explicit goal of an independent org to develop fundraising to the point
where ISOC support was not required?

Of course, in the subsidiary model, although its own legal entity, the
parent entity (ISOC) could literally tell IETForg what to do. I'm not
saying they would, nor that the subsidiary agreement wouldn't carefully
define that, but the would be no formal control  possible in the
independent model.

I may easily have overlooked something, but that's a major difference in my
opinion.

Best, Joe

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Nov 2017 11:47:30 -0800

Joseph,

> On Nov 8, 2017, at 10:13 AM, Joseph Lorenzo Hall <[email-masked]> wrote:
> 
> Of course, in the subsidiary model, although its own legal entity, the parent entity (ISOC) could literally tell IETForg what to do. I'm not saying they would, nor that the subsidiary agreement wouldn't carefully define that, but the would be no formal control  possible in the independent model.
> 
> I may easily have overlooked something, but that's a major difference in my opinion.

If the IETF continues to be dependent on generous funding from ISOC, then ISOC would continue to have control one way or another.  The independent model isn’t independent if it still depends on ISOC funding.

Bob

---

From: Richard Barnes <[email-masked]>
Date: Wed, 8 Nov 2017 14:57:05 -0500

On Wed, Nov 8, 2017 at 2:47 PM, Bob Hinden <[email-masked]> wrote:

> If the IETF continues to be dependent on generous funding from ISOC, then
> ISOC would continue to have control one way or another.  The independent
> model isn’t independent if it still depends on ISOC funding.
>

This is like the "no point to encrypting SNI as long as we send DNS
requests in the clear" argument.  What you say is of course true, but
myopic.  If the goal here is to allow the IETF community to have more
autonomy, and there are two barriers to that, you're going to have to
remove one of those barriers first.  Just because there are two doesn't
mean there's no point to removing one.

And between the two you've noted, removing the organizational lines of
control seems like the right one to go first, since it is less disruptive
and sets the stage for addressing the second, e.g., via fund-raising under
direct IETF control.

--Richard

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Nov 2017 13:27:49 -0800

Richard,

> On Nov 8, 2017, at 11:57 AM, Richard Barnes <[email-masked]> wrote:
> 
> 
> 
> This is like the "no point to encrypting SNI as long as we send DNS requests in the clear" argument.  What you say is of course true, but myopic.  If the goal here is to allow the IETF community to have more autonomy, and there are two barriers to that, you're going to have to remove one of those barriers first.  Just because there are two doesn't mean there's no point to removing one.
> 
> And between the two you've noted, removing the organizational lines of control seems like the right one to go first, since it is less disruptive and sets the stage for addressing the second, e.g., via fund-raising under direct IETF control.
> 

I don’t see why we have to reorganize to fund raise.

I think our fund raising difficulties have little to do with how we are organized.  It appears to me to be industry changes where potential donors don’t find enough value in what the IETF is doing.  This isn’t going to be fixed by creating an “independent” organization.

Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Nov 2017 16:47:09 -0500

On Wed, Nov 08, 2017 at 01:27:49PM -0800, Bob Hinden wrote:

> I think our fund raising difficulties have little to do with how we are organized.

Well, this is just an anecdote, but it matters in at least _some_
cases.  I personally made appeals to people whose response was, "Why
should I give more money to ISOC?"  Our answer today has to be, "Trust
us, it's a dedicated fund," because we don't have a different
governance organization controlling the money.

Now, this might have been because of the people I was talking to, and
their peculiar focus at the time on governance issues.  But it
certainly isn't an objection to which we have an obvious retort.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 9 Nov 2017 10:59:52 +1300

> certainly isn't an objection to which we have an obvious retort.

As in "Which word in 'dedicated' don't you understand?" ?

I'm not denying that some potential patrons might suffer from this confusion
for a few minutes. But since it's only a matter of some clear wording
about separate accounts and dedicated funds, I truly find it hard
to put much weight on this argument. If we don't have that clear wording
already clearly displayed, that's a problem that should be soluble
within a few days of deciding to solve it.

   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Nov 2017 17:11:17 -0500

> within a few days of deciding to solve it.

I disagree.  First, a "dedicated fund" under the control of the same
entity is an accounting fiction and little more.  (You can set up
rules around the fund, but only if there's a trust can you prevent
those rules from being changed.)  People who work with money all day
long know this perfectly well, and ask questions that reflect that
kind of understanding.  We don't have an answer for them because there
isn't one.  So, we're relying on transparency and reputational damage
to enforce this.  It's probably enough, but that brings us to our
second point.

>From the point of view of someone having to go to his or her board to
approve a large dontation to the IETF, they have to explain why the
IETF needs the money.  Money is fungible.  So the board people will
naturally ask what ISOC is doing with the money the organization
already gives ISOC, and then our fundraising needs are immediately
bound up with everything else that ISOC is doing.

If you want to ask money for your activity, you have to be able to
show you have control of it and that it can't be used in the service
of something else.  To make that work, we have to divorce our pile of
money from ISOC's, or else we are just one of the many things that
ISOC is doing with its money.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Nov 2017 14:12:51 -0800

Andrew,

> On Nov 8, 2017, at 1:47 PM, Andrew Sullivan <[email-masked]> wrote:
> 

How is that going to be different if ISOC is still providing most of the funding for the IETF?  It’s not going to be hidden.

Of course, some time people raise issue like this as a nicer way of saying no.

Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Nov 2017 17:49:24 -0500

> How is that going to be different if ISOC is still providing most of the funding for the IETF?  It’s not going to be hidden.

If you give money today to an ISOC fund that has a red "IETF" in magic
marker on the outside, from the point of view of money people you have
given the money _to_ ISOC, but with the intention that they spend it
on the IETF.  If they don't, then you might have had a reasonable
expectation not met and you might have a legal claim, but ISOC didn't
steal the money.

If you given money to some future legally-incorporated entity called
"IETF" and that entity has a bank account, then if ISOC winds up the
IETF entity there are rules about what it can do with the IETF money,
because it is not just the same as any other money ISOC has.

>From the POV of outsiders, the second of these is trivial to explain
and the first is a pitch that has lost them by the time you got to
sentence two.

> Of course, some time people raise issue like this as a nicer way of saying no.

There are lots of reasons people might do that.  But I want to make
their job of selling us to their boards easier, not harder, and IASA++
does not make it easier.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Nov 2017 14:57:28 -0800

Andrew,

> On Nov 8, 2017, at 2:49 PM, Andrew Sullivan <[email-masked]> wrote:
> 

I should have been clearer.  My point is that if people see that ISOC is still giving a lot of money to the IETF, they will ask the questions like why isn’t ISOC giving more, I already give to ISOC, etc.  Unless we stop taking any significant amount of money from ISOC, I don’t think this problem will go away.  It’s not really about bank accounts.

Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Nov 2017 18:40:34 -0500

On Wed, Nov 08, 2017 at 02:57:28PM -0800, Bob Hinden wrote:

> I should have been clearer.  My point is that if people see that ISOC is still giving a lot of money to the IETF, they will ask the questions like why isn’t ISOC giving more, I already give to ISOC, etc.
>

Well, yes, but there's a faint circularity in that, I think.  For
presumably, if we are successfully raising money into an independent
IETF fund, it is because we have a clear and compelling plan about how
the funds will flow in the future.  Separating the control is
necessary but not sufficient.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Hinden <[email-masked]>
Date: Wed, 8 Nov 2017 21:07:40 -0800

Andrew,

> On Nov 8, 2017, at 3:40 PM, Andrew Sullivan <[email-masked]> wrote:
> 

Agree.  The hard parts are telling potential donors what the value is and what the IETF wants to do in the future it isn’t doing now.

Thanks,
Bob

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 9 Nov 2017 11:05:20 +0000

Thanks to everyone involved in putting this draft together. It is obvious a great deal of time and thought went into it. On the long flight to Singapore without WiFi, I am reading it along with the insightful and thought provoking comments others have already provided.
I thought I’d share a few opinions I formed while trying to digest all of this. I hope they are useful.

* With greater independence comes greater cost, costs covered by ISOC, which is interesting but perhaps a good thing, because ISOC needs to believe in and approve of this plan. In this sense, IASA++ seems best to me, but that is with the big assumption we are able to construct it such that it provides the independence and benefits envisioned with the other options. If not, then the subsidiary model seems necessary and best. Complete independence in all ways from ISOC is not desired, but independence in some things that ISOC agrees to have independent is a really good thing. I realize this is circular, but as I understand it, much of the money continues to come from ISOC with all three models, so ISOC needs to be on board.

* NomCom, as is exists today, is not likely to be in a good position to determine IAOC/Board makeup

* Sponsorship and budgeting/fiscal responsibility suffers from a model in which ISOC cover shortages. A larger, upfront annual budget from ISOC with greater fiscal accountability by the IETF would be better

* Staff and board accountable to IETF seems necessary

* The skillset for the director and fundraiser and the director of communications seems pretty similar to me. Both are primarily outward focused getting the word out about IETF activities and accomplishments and putting them in a good light that attracts members, partners, sponsors, etc. Combining them into a single position might be a good option.

Cheers,
Charles

From: iasa20 <[email-masked]> on behalf of Jari Arkko <[email-masked]>
Date: Thursday, November 2, 2017 at 1:54 AM
To: "[email-masked]" <[email-masked]>
Subject: [Iasa20] Thank you & we need your feedback

The document is here:

Jari for the design team

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 10 Nov 2017 11:38:18 +0800

Hi Brian,

> On Nov 9, 2017, at 5:59 AM, Brian E Carpenter <[email-masked]> wrote:
> 

I think if you look back at the minutes from the BoF at IETF 98 [1], you get quite a different picture. There we had three of the four Global Host companies explaining that separate entities receiving the sponsorship money would make it easier to be an IETF sponsor. I will say that I have personally observed confusion about this within Cisco that wouldn’t exist if the IETF and ISOC were distinct legal entities. Words can’t fix this, because at the end of the day the name on the check has to be tied to a tax ID, and you can’t get your own tax ID if you’re not a legal entity. This is a different argument from the one about governance of the funds and trusting that they will be spent how they’re supposed to be, but since I’ve seen the confusion first hand on more than one occasion, I thought I would mention it.

Earlier this year the IAOC stood up a committee to help strategize about sponsorship. The committee has been slowly grinding gears on a few different aspects of IETF sponsorship, so no results to report yet. But one of the very first issues we discussed was reducing the barriers to becoming a sponsor, and the perception even among existing sponsors that giving money to the IETF is difficult.

Alissa

[1] https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20/ <https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20/>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Nov 2017 16:53:57 +1300

> Earlier this year the IAOC stood up a committee to help strategize about sponsorship. The committee has been slowly grinding gears on a few different aspects of IETF sponsorship, so no results to r…

Yes. That was true even 10 years ago. What I found was that the tricky bit
was justifying the *marketing* value to the sponsor. In most companies,
that sort of money comes from Marketing, not from R&D. In some ways ISOC
was an easier sell from that viewpoint than the IETF; policy and governance
are more saleable than <yawn>standards</yawn>. Explaining that ISOC handled
the money so that geeks didn't need to always seemed easy enough at that time.

To be clear, I fully support the need for a professional fund-raiser, in
any of the models.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 10 Nov 2017 23:54:24 +0800

> I think if you look back at the minutes from the BoF at IETF 98 [1], you get quite a different picture. There we had three of the four Global Host companies explaining that separate entities receiving the sponsorship money would make it easier to be an IETF sponsor.

I can also confirm this, and have witnessed the wish in other instances as well. Also, over the years, many clarifying words have been provided, but it isn’t quite as easily solved as that. At the end of the day, my belief is that further organisational clarity would be beneficial for our fundraising efforts. Certainly not the only or solely sufficient tool as Andrew pointed out, but I think it should be one of the tools. 

Jari

---

From: Richard Barnes <[email-masked]>
Date: Fri, 10 Nov 2017 14:01:47 -0500

On Thu, Nov 9, 2017 at 10:53 PM, Brian E Carpenter <
[email-masked]> wrote:

> > I think if you look back at the minutes from the BoF at IETF 98 [1], you
> get quite a different picture. There we had three of the four Global Host
> companies explaining that separate entities receiving the sponsorship money
> would make it easier to be an IETF sponsor. I will say that I have
> personally observed confusion about this within Cisco that wouldn’t exist
> if the IETF and ISOC were distinct legal entities. Words can’t fix this,
> because at the end of the day the name on the check has to be tied to a tax
> ID, and you can’t get your own tax ID if you’re not a legal entity. This is
> a different argument from the one about governance of the funds and
> trusting that they will be spent how they’re supposed to be, but since I’ve
> seen the confusion first hand on more than one occasion, I thought I would
> mention it.
> >
> > Earlier this year the IAOC stood up a committee to help strategize about
> sponsorship. The committee has been slowly grinding gears on a few
> different aspects of IETF sponsorship, so no results to report yet. But one
> of the very first issues we discussed was reducing the barriers to becoming
> a sponsor, and the perception even among existing sponsors that giving
> money to the IETF is difficult.
>

This does not match my experience.  The companies that are seriously
investing in IETF understand the strategic value that the Internet and the
IETF have to their companies.  The challenges are exactly as Alissa says:
These companies are judging the IETF as they would any other investment,
and in particular, they want to understand how the resources they
contribute are being used.  If they want to donate to the IETF, writing a
check to ISOC with some loose promise that "It will arrive at the IETF
eventually" does not provide the assurance these organizations are looking
for.

--Richard

> > [1] https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20/
> <https://datatracker.ietf.org/meeting/98/materials/minutes-98-iasa20/>
> >>
> >>   Brian
> >>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Nov 2017 08:25:13 +1300

On 11/11/2017 08:01, Richard Barnes wrote:
> IETF have to their companies.  

I'm glad that such companies exist, but if they value the IETF, the
decision is surely not being driven by marketing people?

> The challenges are exactly as Alissa says:

Certainly a "loose promise" is not enough.

   Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Nov 2017 00:01:51 +0000

Hiya,

Thanks again to the DT for their work.

Some additional feedback on the questions asked below. I've read
the draft and recent list traffic and will try to not repeat things
already said.

>   o  Which direction the community would like to take the work in

I prefer that we pursue the IASA++ route.

My main reasons are:

- I think IASA++ allows us to fix what I see as the more pressing
issues (transparency etc). I don't deny that there are other
issues (fundraising) that might be better handled via the other
options but I've not been convinced by the list traffic that
fundraising or other issues better handled via the other options
would be fatally undermined in the IASA++ scenario. IOW IASA++
seems to me good enough.

- I think the subsidiary or independent organisation options will
not be achievable in the next year - my takeaway from the IANA
transition was that such changes will bring up so many issues that
it'd add another year. That is my guess, others' guesses will no
doubt differ but I think IASA++ has to be the smaller change and
hence less complex.

- I'm not keen on the IETF incorporating and like our current
situation where anyone can contribute and nobody needs to be a
member. I accept that some forms of ISOC subsidiary or independent
organisation could preserve that but I fear that either of those
approaches would over time lead to us ending up as a membership
organisation. IMO the risk of us ending up there is lower with
the IASA++ approach when I think about (i.e. guess;-) how things
might evolve over the next 10 years, so for me that's a reason
to fairly strongly prefer IASA++

Cheers,
S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 00:04:59 +0000

On Tue, Nov 14, 2017 at 12:01 AM, Stephen Farrell <[email-masked]
> wrote:

> organisation could preserve that

Nothing we have proposed involves either (a) the IETF incorporating
or (b) requiring people to be members.

> but I fear that either of those

OK, well, given that you don't actually provide any reason to believe
that this will happen other than that you're anxious about it, I'm not
really sure there's not much to usefully say here.

-Ekr

Cheers,

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Nov 2017 00:10:37 +0000

> really sure there's not much to usefully say here.

Sorry, I thought it was fairly obvious:

It seems to me to be in the nature of organisations to end
up more, and not less, bureaucratic. I think a more bureaucratic
organisation that could have members is more likely to end up
requiring people to be members. Either of an ISOC subsidiary
or independent organisation could impose membership as a
requirement. IASA++ means that's less likely to happen.

I think describing that as "anxiety" is trivialising what
seems like a real risk.

S.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 00:14:57 +0000

On Tue, Nov 14, 2017 at 12:10 AM, Stephen Farrell <[email-masked]

> requirement. IASA++ means that's less likely to happen.

It's not at all clear to me that this is the case, given that ISOC *already*
has members [0] and it would therefore be trivial to require IETF
participants
to be ISOC members.

> seems like a real risk.

"seems" is doing a lot of work here. It may seem like a real risk to you
but it doesn't seem like a real risk to me, and your text above doesn't do
much to persuade me.

-Ekr

[0] https://www.isoc.org/membership/rules.shtml

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 13:20:22 +1300

Stephen,

> I think describing that as "anxiety" is trivialising what

I think ekr's right, this is not a real risk. The real risk is
that either of the incorporation models creates bureaucracy but
either does not solve the underlying problems better than IASA++
would do, or leads to alternative problems after a few years.
The alternative problems are probably best described as
"ICANNitis", in other words an organization that develops
a dynamic of its own that its stakeholders don't like.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Tue, 14 Nov 2017 08:20:55 +0800

Stephen:

Thanks.

And your concern was a big basis for us to be careful about what we are doing here. Specifically, keeping IETF (incl. participants, WGs, IESG, etc) and IETFAdminOrg separate. Can you speak to how clearly that comes out of the document, and to what extent that helps keep your worry in check?

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Nov 2017 00:23:59 +0000

> has members [0] and it would therefore be trivial to require IETF

I don't think that'd be at all trivial. The community would, I think,
be quite likely to strongly resist such an attempt. (I would anyway,
and I don't think I'd be alone:-). Changing our processes to ignore
such community input/resistance would require changing a bunch of
BCPs which is never trivial.

> but it doesn't seem like a real risk to me, and your text above doesn't do

Sure, I'm not saying that mine is a killer argument. I'm also not
saying anything is inevitable, and it's fine that we evaluate the
risk differently as there can't be any certainties here. But, my
evaluation of that risk remains one of the reasons I personally
prefer IASA++ as of now.

S.

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 14 Nov 2017 00:24:11 +0000

On 11/13/17, 7:02 PM, "iasa20 on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

> I don't deny that there are other
    issues (fundraising) that might be better handled via the other
    options but I've not been convinced by the list traffic that
    fundraising or other issues better handled via the other options
    would be fatally undermined in the IASA++ scenario. 

[JL] I noticed a number of the global sponsors at the last meeting and on this list suggesting otherwise (that the current approach is problematic). 

> I think the subsidiary or independent organisation options will
    not be achievable in the next year 

[JL] I agree with your sentiment that we must strike a balance – we don’t want to spend years and years on this but at the same time it’d be unfortunate to be back discussing a new approach in just a few years time. So I guess the key is to get to the right administrative model that will last the IETF another 10 years or much longer, but not take up years of time doing so.
	
> I'm not keen on the IETF incorporating and like our current
    member. 

[JL] The administrative options the DT has been considering would not change the participation model. Indeed – preserving it is listed as one of the key goals.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Nov 2017 00:40:11 +0000

Hiya,

> [JL] I noticed a number of the global sponsors at the last meeting and on this list suggesting otherwise (that the current approach is problematic). 

I agree that this aspect is likely harder in the IASA++ scenario
but I don't recall people saying that IASA++ was a showstopper for
that.

> [JL] I agree with your sentiment that we must strike a balance – we don’t want to spend years and years on this but at the same time it’d be unfortunate to be back discussing a new approach in just…

Agree.
	
> [JL] The administrative options the DT has been considering would not change the participation model. Indeed – preserving it is listed as one of the key goals.

I agree the document sets that as a goal and believe that the DT
and people commenting don't want to go there. But over an ~10-year
timeframe I still think IASA++ reduces that particular risk so
for me that remains a reason to prefer IASA++.

Cheers,
S.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Nov 2017 19:40:41 -0500

Hi,

> a dynamic of its own that its stakeholders don't like.

I had assumed that we were already facing that issue, or we wouldn't
be tackling IASA20 at all.  That is, if we thought the administrative
arrangements were already working perfectly smoothly, there would be
no pressure to make any adjustments at all.  I don't think the rough
bits are just accidents: we have been operating this mechanism, and if
it isn't working quite as we like then that must be because it has
some inbuilt issues.

The question therefore is what mechanisms one can build now to make
reforms that make appropriate corrections such that (1) we are not
subject to pressures that restore the current irritants and (2) we do
not create new pressure points that create a different set of
problems.

I think one can legitimately disagree about the right way to go about
that, but I don't think one can consistently claim that one of the
options does not entail making any structural corrections and still
claim this work is worth doing.  If there are no structural changes to
make then this is all just a really expensive way to collect
information for the existing IASA and maybe the nomcom.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Nov 2017 19:42:50 -0500

> but I don't recall people saying that IASA++ was a showstopper for

I actually don't see how it is not; see my recent arguments about
this.  In case it was not clear in those previous postings, let me
make it clear now: I do not think that a completely legally-subsumed
part of ISOC can ever escape those problems.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 00:59:06 +0000

On Tue, Nov 14, 2017 at 12:23 AM, Stephen Farrell <[email-masked]

> BCPs which is never trivial.

And these are exactly the obstacles that would exist in either of the other
two models, except you would *also* need to create a membership
structure first.

-Ekr

---

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Nov 2017 09:30:50 +0800

Ekr,

> On Nov 14, 2017, at 8:04 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 

I am pretty sure if we want to have our own bank account some sort of incorporating will be required.

Bob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 01:35:12 +0000

> incorporating will be required.

The proposal is not that the IETF incorporate but that we create a new
organization which is incorporated to support our work. I think that's an
important difference.

-Ekr

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 13 Nov 2017 20:39:29 -0500

> organization which is incorporated to support our work. I think that's an

That's the model I have: an organisation that stands in the same
relationship to the IETF as ISOC does today, but without the
additional interests that ISOC has, thereby providing a structural
separation from those other interests of ISOC.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 14 Nov 2017 01:40:41 +0000

In the US, yes.  But there are other venues (I know of Belgium) which allow unincorporated non-profit orgs to pretty easily have a bank account.

I am not advocating we host ourselves outside the US, just mentioning it.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 14 Nov 2017 14:45:53 +1300

On 14/11/2017 13:40, Andrew Sullivan wrote:
> no pressure to make any adjustments at all.

100% agreement with that.

> I don't think the rough

No, that's a non sequitur. Either it has some inbuilt issues, or we're
not operating the mechanism correctly. Or more probably, both of the
above apply.

> not create new pressure points that create a different set of

And (3) we do not drift away from operating the mechanism
correctly in future.
 
> information for the existing IASA and maybe the nomcom.

Right, but to the extent that the corrections needed are due to us
not operating the mechanism properly today, the changes need not be
"constitutional" in nature. 

Regards,
     Brian

---

From: Bob Hinden <[email-masked]>
Date: Tue, 14 Nov 2017 09:53:51 +0800

Ekr,

> On Nov 14, 2017, at 9:35 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> The proposal is not that the IETF incorporate but that we create a new organization which is incorporated to support our work. I think that's an important difference.

It is, and apparently getting lost in the discussion.  I think this needs to be clarified.  At least for me, some high level org charts of the different choices would be helpful.

Bob

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 14 Nov 2017 01:57:15 +0000

On Tue, Nov 14, 2017 at 1:53 AM, Bob Hinden <[email-masked]> wrote:

> It is, and apparently getting lost in the discussion.  I think this needs
> to be clarified.  At least for me, some high level org charts of the
> different choices would be helpful.
>

Thanks. I think we could manage to produce some ASCII art for this,

-Ekr

Bob

---

From: Brian Haberman <[email-masked]>
Date: Mon, 13 Nov 2017 21:00:53 -0500

> Thanks. I think we could manage to produce some ASCII art for this,

Or real art these days...

Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 14 Nov 2017 10:02:47 +0800

> different choices would be helpful.

Here's a rough representation of my understanding:

https://ipv.sx/tmp/IASA-org-charts.pdf

---

From: Michael Richardson <[email-masked]>
Date: Mon, 13 Nov 2017 21:22:32 -0500

> incorporating will be required.

define "own"...

    > In the US, yes. But there are other venues (I know of Belgium) which
    > allow unincorporated non-profit orgs to pretty easily have a bank
    > account.

I believe that as part of of the transition from ISOC doing the bookkeeping,
to AMSL doing the bookkeeping, that a new bank account was opened.

I don't know if it's "our own bank account", as I'm sure that there is ISOC
Board authorization to change the list of signers, yet I'm pretty sure you
could inspect the statements if you wanted to.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 15 Nov 2017 00:33:52 +0000

*   Here's a rough representation of my understanding:

  *   https://ipv.sx/tmp/IASA-org-charts.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__ipv.sx_tmp_IASA-2Dorg-2Dcharts.pdf&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=4LM0GbR0h9Fvx86FtsKI-w&m=wjfwf4loP8r0azbmMqscDxHOuOqIWsq55oA_fv3716k&s=LSCn7k_qs5fXgyd4JoL_pCILjcHHUPJeKDhNc_UwtNw&e=>

That is very nice and clear.  It would be good if the draft author said if it’s accurate :)