Subject: Re: [Iasa20] Thoughts on draft-haberman-iasa20dt-recs-01.txt

From: Jari Arkko <[email-masked]>
Date: Wed, 1 Nov 2017 23:39:51 +0100

Thanks much for this, Ted.

> Reading through it, I was particularly struck by a much stronger recognition that some of the issues we face are because of decline in volunteer time as well as external support.  It remains a bit hard to understand the design team's perception of how these proposals will influence those, but I attribute this to the design team hoping community members will analyze this for themselves.  Still, if the design team has a consensus view, a somewhat stronger statement of it would be welcome.

Just speaking for myself, the issue with decline of volunteers for admin tasks in particular has been growing more serious in my mind in the last year.

But as to how that (or external support) affects the different options… that’s a good question. I don’t have an answer immediately but we can think about that.

> By my reading, IASA++ represents a very wide range possibilities, from something close to "do nothing but be open about the issues" (publish this doc and stop, in other words) to a restructuring of the activity within ISOC that would be similar in scope to setting up a subsidiary.  It may be useful to mark out some explicit point along that spectrum, as different community members' understandings of that activity may result  a false sense of shared understanding.

Point taken.

> I also note that the draft discusses the IETF's administrative arrangements without quite saying explicitly that these include the IRTF and IAB.  It would be useful to make that clear.  It is particularly noteworthy on the IAB front because of two issues.  First, the charter of of the IAB (RFC 2850, Section 2) explicitly calls out that it has a dual role as a committee of the IETF and an advisory body of the Internet Society.  Second, the IAB manages many liaison relationships for the IETF community, but some of these are formally arrangements with the Internet Society.  The Category A liaisons to ISO managed by the IAB are, for example, relationships between ISO and ISOC: https://www.iso.org/organization/9418.html <https://www.iso.org/organization/9418.html> .  ISOC is also a sector member of the ITU-T, and that is the source of some of our ability to interact with the ITU.  It is my perspective that moving to an entirely separate organization would required that these be recreated (no doubt with ISOC's support).  It is not clear to me whether the creation of a subsidiary would trigger the same requirement, but it seems less likely or necessary in that case (as the formal relationship remaining with ISOC could be part of the subsidiary agreement).

Another good point. Taken.

> The draft also discusses the potential relationship of new entities with the IETF Trust.  My personal take is that this is no longer simple, because the IETF trust also holds the IANA IPR on behalf of a larger community.  I would recommend not trying to move it into another organization, at least until that organization is well-established and the impact of the change on its stability can be assessed.  The agreement of the wider community would also be required.

Did you mean that IETF Trust should not get into the middle of the reorganisation and be moved around? If so, I personally agree with you. I actually think there are even structural issues that speak in favour of keeping the Trust out of IETFAdminOrg permanently. The design team document doesn’t say the Trust must be kept out of this, but that’s at least partially because we wanted to produce analysis and information and maybe stop short of trying to tell the IETF what to do. But at least I have a personal opinion about the (non) role of Trust here.

> My next comment is on the delicate subject of money.  Going through this exercise is already costing us volunteer time, and many of the changes proposed will result in staff time either on a one-off or a continuing basis.  Change for change's sake is expensive, in other words, and we should generally justify it either in very clear community needs or in substantial returns on the investment in change.  Transparency-related changes seem to me to fall in the community needs category.  Within the document I see three changes that seem to be strongly focused on monetary returns on investment :
> 
> 1) Clear fund-raising responsibilities (discussed in Section 5.5)  
> 2) Improve accounting of costs (discussed in section 6.3)
> 3) Support a re-envisioned funding model (discussed in section  6.1) 

All of that seems about right.

> Some other proposed changes are not so clear.  The inclusion of a director of communications in the proposed staff, for example, might be to support awareness of the organization for fund-raising purposes, to support awareness and adoption of our standards, or to support awareness of our work to encourage participation by new volunteers.  Clarity on how the work will support the IETF in the future would be a useful touchstone in analyzing whether this is a change that is a must-have for right now.

Good question and a fair request. Although the specific case of director of communications is IMHO more about clarifying a role (and an almost full-time person) that in practice already exists today.

> Lastly,in the interests of full transparency, I think the Internet Society has been a consistent source of support and insight  since we made the previous transition, and I generally favor the approaches which maintain a strong relationship between the IETF and ISOC.  I agree that the changes in activities on both sides necessitate a re-examination of how that relationship works, and if the most appropriate change is to a subsidiary structure, I am ready to support that.  But I disagree with Richard's analysis that IASA++ is an inferior form of the subsidiary approach.  IASA++ could imply a much stronger integration with ISOC than we have previously seen, and that could go in a variety of ways.  
> 
> To give one example, ISOC could decide in the course of the IASA++ re-organization to use a more-contractor heavy approach to some of its other work and to manage the overall costs by using the same contractors for IETF work and other Internet Society work. That approach (similar to the "task requester" approach used in some government agencies) would be a change to the way the Internet Society works that would make the IETF work a more natural fit to ISOC's other working methods.   Put another way, IASA++ is really an Internet Society reorg, and assessing whether or not it is the right choice depends heavily on the extent to which ISOC is interested in a re-org of that scope, which would necessarily affect its other activities if it is to be successful.

Here I need more help to understand what you’re thinking. I’ve been having trouble imagining the kinds of things we can improve in IASA++. Your general point about the possibility of integration as good/useful thing is taken. And I understand the more contractor heavy organisational model. And I understand the benefits of integration and synergy effects in general. What I’m having trouble is understanding how they fit our case, and how they help solve the problems about lack of clarity and clear lines of authority and other things that we’ve found troublesome.

But I’m very interested in understanding what useful things we could do here, as at least I could have missed many opportunities here and probably the same is true of the rest of the design team. Can you help us, e.g., by sketching some things that we could do here?

> I am happy to note that the ISOC Board is meeting in Singapore just after the upcoming IETF, and I hope that clarity on that point can come from them as well.

Yes, indeed.

Jari

---

From: Ted Hardie <[email-masked]>
Date: Wed, 1 Nov 2017 19:11:22 -0700

On Wed, Nov 1, 2017 at 3:39 PM, Jari Arkko <[email-masked]> wrote:

> <snip>
>
> The draft also discusses the potential relationship of new entities with
> the IETF Trust.  My personal take is that this is no longer simple, because
> the IETF trust also holds the IANA IPR on behalf of a larger community.  I
> would recommend not trying to move it into another organization, at least
> until that organization is well-established and the impact of the change on
> its stability can be assessed.  The agreement of the wider community would
> also be required.
>
>
> Did you mean that IETF Trust should not get into the middle of the
> reorganisation and be moved around?
>

Yes, that's what I meant.

If so, I personally agree with you. I actually think there are even
> structural issues that speak in favour of keeping the Trust out of
> IETFAdminOrg permanently. The design team document doesn’t say the Trust
> must be kept out of this, but that’s at least partially because we wanted
> to produce analysis and information and maybe stop short of trying to tell
> the IETF what to do. But at least I have a personal opinion about the (non)
> role of Trust here.
>
> Lastly,in the interests of full transparency, I think the Internet Society
> has been a consistent source of support and insight  since we made the
> previous transition, and I generally favor the approaches which maintain a
> strong relationship between the IETF and ISOC.  I agree that the changes in
> activities on both sides necessitate a re-examination of how that
> relationship works, and if the most appropriate change is to a subsidiary
> structure, I am ready to support that.  But I disagree with Richard's
> analysis that IASA++ is an inferior form of the subsidiary approach.
> IASA++ could imply a much stronger integration with ISOC than we have
> previously seen, and that could go in a variety of ways.
>
> To give one example, ISOC could decide in the course of the IASA++
> re-organization to use a more-contractor heavy approach to some of its
> other work and to manage the overall costs by using the same contractors
> for IETF work and other Internet Society work. That approach (similar to
> the "task requester" approach used in some government agencies) would be a
> change to the way the Internet Society works that would make the IETF work
> a more natural fit to ISOC's other working methods.   Put another way,
> IASA++ is really an Internet Society reorg, and assessing whether or not it
> is the right choice depends heavily on the extent to which ISOC is
> interested in a re-org of that scope, which would necessarily affect its
> other activities if it is to be successful.
>
>
> Here I need more help to understand what you’re thinking. I’ve been having
> trouble imagining the kinds of things we can improve in IASA++. Your
> general point about the possibility of integration as good/useful thing is
> taken. And I understand the more contractor heavy organisational model. And
> I understand the benefits of integration and synergy effects in general.
> What I’m having trouble is understanding how they fit our case, and how
> they help solve the problems about lack of clarity and clear lines of
> authority and other things that we’ve found troublesome.
>
> But I’m very interested in understanding what useful things we could do
> here, as at least I could have missed many opportunities here and probably
> the same is true of the rest of the design team. Can you help us, e.g., by
> sketching some things that we could do here?
>
>
A recent example is the shifting of some accounting tasks related to the
IAOC from ISOC to a contract with AMS (actually an amendment to the
secretariat contract).  In an IASA++ world with a tighter integration, ISOC
could have considered or implemented a move of its other accounting
requirements to an outside contractor, which the IETF would have then
shared.

As I said in my previous note, this approach very much depends on the
appetite of ISOC to have a reorg of facilities unrelated to the IETF, so
they were in greater alignment.  That's a matter for the Trustees and staff.

I hope that example helps clarify that avenue of discussion,

regards,

Ted

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 6 Nov 2017 16:27:13 -0500

> On Nov 1, 2017, at 10:11 PM, Ted Hardie <[email-masked]> wrote:
> 
> A recent example is the shifting of some accounting tasks related to the IAOC from ISOC to a contract with AMS (actually an amendment to the secretariat contract).  In an IASA++ world with a tighter integration, ISOC could have considered or implemented a move of its other accounting requirements to an outside contractor, which the IETF would have then shared.
> 
> As I said in my previous note, this approach very much depends on the appetite of ISOC to have a reorg of facilities unrelated to the IETF, so they were in greater alignment.  That's a matter for the Trustees and staff.

I think this gets at an important point: regardless of which path we end up taking, it will be crucial for ISOC to have the appetite needed for the changes associated with the chosen path. This is as true for the IASA++ option as for the others, in my reading of the DT document. Ted used the shift to contractors as one hypothetical example of a change that would require buy-in from both sides, but I think that is just one possibility out of many that could come as part of going the IASA++ route. So my take-away is that to adequately address the problems articulated in the document, we shouldn’t be viewing IASA++ as a status quo option, neither should ISOC, and both we and ISOC need to be on board with that.

Alissa

> _______________________________________________
> iasa20 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/iasa20

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 7 Nov 2017 09:51:46 -0600

Speaking as an interested lurker ...

On Mon, Nov 6, 2017 at 3:27 PM, Alissa Cooper <[email-masked]> wrote:

>> Lastly,in the interests of full transparency, I think the Internet
>> Society has been a consistent source of support and insight  since we made
>> the previous transition, and I generally favor the approaches which
>> maintain a strong relationship between the IETF and ISOC.  I agree that the
>> changes in activities on both sides necessitate a re-examination of how
>> that relationship works, and if the most appropriate change is to a
>> subsidiary structure, I am ready to support that.  But I disagree with
>> Richard's analysis that IASA++ is an inferior form of the subsidiary
>> approach.  IASA++ could imply a much stronger integration with ISOC than we
>> have previously seen, and that could go in a variety of ways.
>>
>> Here I need more help to understand what you’re thinking. I’ve been
>> having trouble imagining the kinds of things we can improve in IASA++. Your
> I think this gets at an important point: regardless of which path we end
> up taking, it will be crucial for ISOC to have the appetite needed for the
> changes associated with the chosen path. This is as true for the IASA++
> option as for the others, in my reading of the DT document. Ted used the
> shift to contractors as one hypothetical example of a change that would
> require buy-in from both sides, but I think that is just one possibility
> out of many that could come as part of going the IASA++ route. So my
> take-away is that to adequately address the problems articulated in the
> document, we shouldn’t be viewing IASA++ as a status quo option, neither
> should ISOC, and both we and ISOC need to be on board with that.
>

+1 Alissa, with the added observation that we're doing the IASA 2.0
exercise as a 10-year review; if that's how long until the next review, we
should definitely be looking past the status quo (as a community), and we
probably can't do this level of review very often, so 10 years is a
reasonable estimate for the next time we do it.

Spencer

---

From: Jari Arkko <[email-masked]>
Date: Tue, 7 Nov 2017 22:21:53 +0200

> I think this gets at an important point: regardless of which path we end up taking, it will be crucial for ISOC to have the appetite needed for the changes associated with the chosen path. This is…

I agree with everything that was said above by you Ted and Alissa.

The use of contractors is a great example, makes a lot of sense, and I think Alissa and the team has already made significant steps in that direction. 

I do want to say though outside of that example, the crux is finding the concrete things that we can do (and my personal ability to imagine what those might be seems a bit limited at the moment). I’ll also say that there are things we cannot do as freely as one might perhaps think when there’s no formal separation between entities, which might limit some things e.g. around managing staff. Although of course the contractor model makes some of those issues not so relevant or at least limits their impact to a small set of people.

Jari