Subject: [Iasa20] draft-haberman-iasa20dt-recs-00.txt

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 07 Jul 2017 16:29:53 +0000

Greetings IASA 2.0 enthusiasts!

The design team has just published a preliminary -00 draft in terms of
analysis of three options. Find it below.

We will have a one-hour meeting at the beginning of the IASA 2.0 slot
(3:50-4:50 local time) on Tuesday of IETF week. Jon Peterson will chair and
send along an agenda. (We are reserving the second hour of that slot for an
in-person design team meeting.)

Note that this is very early work, but far along enough that we would like
to focus the discussion during the meeting as follows:

Feedback on the set of identified possible paths forward or options is the key
question. Are any potential missed options? Also, feedback on the implications
of options being considered would be welcome.

Best wishes, Joe

---------- Forwarded message ---------
From: <[email-masked]>
Date: Fri, Jul 7, 2017 at 12:21
Subject: New Version Notification for draft-haberman-iasa20dt-recs-00.txt
To: Jari Arkko <[email-masked]>, Leslie Daigle <
[email-masked]>, Brian Haberman <[email-masked]>, Jason
Livingood <[email-masked]>, Eric Rescorla <[email-masked]>,
Joseph Lorenzo Hall <[email-masked]>

A new version of I-D, draft-haberman-iasa20dt-recs-00.txt
has been successfully submitted by Cindy Morgan and posted to the
IETF repository.

Name:           draft-haberman-iasa20dt-recs
Revision:       00
Title:          IASA 2.0 Design Team Recommendations
Document date:  2017-07-07
Group:          Individual Submission
Pages:          23
URL:
https://www.ietf.org/internet-drafts/draft-haberman-iasa20dt-recs-00.txt
Status:
https://datatracker.ietf.org/doc/draft-haberman-iasa20dt-recs/
Htmlized:       https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-haberman-iasa20dt-recs-00

Abstract:
   The arrangements relating to administrative support for the IETF were
   created more than ten years ago.  Since then, there has been
   considerable change in the tasks and in our own expectations.  The
   IETF community has discussed these changes and the problems they
   cause.  The community has some sense of the properties they expect
   from future arrangements, including structural and organizational
   changes, changes to volunteer and staff personnel resources, and
   transparency changes.

   This document is a product of a design team, focused on providing
   additional information to the community about solution options, as
   well as supporting analysis of the implications of those options.  To
   be clear, the community is responsible for adopting any
   recommendations or making any final decisions.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- 
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: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 07 Jul 2017 22:42:01 +0200

Hi,

I’ve read the document and in general agree with what is being said. Not really sure about the comparison criteria and how everything has been rated, but I’m sure we will be able to discuss this in the list and the next meeting and have many other inputs.

However, I’m missing some issues, that I think are key:

1) Despite the model chosen (IAOC for IASA++, board of directors for ISOC subsidiary/independent) and in addition to defining how the board/oversight committee is elected, we need to define how the committee members are elected. The actual model “they select the people that they feel more comfortable to work with” is absolutely against the IETF overall spirit and even an insult to all the participants.

2) Accountability of IAOC (or whatever replaces it). We need to make sure that they respond to the community and define strict deadlines for that (I can tell you that I’m still waiting responses from about a couple of years …, which again is an insult to a community member).

3) We also need to specify if anything is not going to be transparent. There is no sense to hide anything from the community, unless is clearly defined upfront.

Regards,
Jordi

-----Mensaje original-----
De: iasa20 <[email-masked]> en nombre de Joseph Lorenzo Hall <[email-masked]>
Responder a: <[email-masked]>
Fecha: viernes, 7 de julio de 2017, 18:29
Para: "[email-masked]" <[email-masked]>
Asunto: [Iasa20] draft-haberman-iasa20dt-recs-00.txt

    The design team has just published a preliminary -00 draft in terms of analysis of three options. Find it below.
    
    We will have a one-hour meeting at the beginning of the IASA 2.0 slot (3:50-4:50 local time) on Tuesday of IETF week. Jon Peterson will chair and send along an agenda. (We are reserving the second hour of that slot for an in-person design team meeting.)
    
    Note that this is very early work, but far along enough that we would like to focus the discussion during the meeting as follows: 
    
    Feedback on the set of identified possible paths forward or options is the key question. Are any potential missed options? Also, feedback on the implications of options being considered would be welcome.

    Best wishes, Joe
    
    ---------- Forwarded message ---------
    From:  <[email-masked]>
    Date: Fri, Jul 7, 2017 at 12:21
    Subject: New Version Notification for draft-haberman-iasa20dt-recs-00.txt
    To: Jari Arkko <[email-masked]>, Leslie Daigle <[email-masked]>, Brian Haberman <[email-masked]>, Jason Livingood <[email-masked]>, Eric Rescorla <[email-masked]>, Joseph Lorenzo Hall <[email-masked]>

    
    
    Name:           draft-haberman-iasa20dt-recs
    Revision:       00
    Title:          IASA 2.0 Design Team Recommendations
    Document date:  2017-07-07
    Group:          Individual Submission
    Pages:          23
    URL:            https://www.ietf.org/internet-drafts/draft-haberman-iasa20dt-recs-00.txt
    Status:         https://datatracker.ietf.org/doc/draft-haberman-iasa20dt-recs/
    Htmlized:       https://tools.ietf.org/html/draft-haberman-iasa20dt-recs-00
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-haberman-iasa20dt-recs-00

    Abstract:

    
    
    Please note that it may take a couple of minutes from the time of submission
    until the htmlized version and diff are available at tools.ietf.org <http://tools.ietf.org>.
    
    The IETF Secretariat

    
    -- 
    
    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
    _______________________________________________
    iasa20 mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/iasa20

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 8 Jul 2017 13:08:23 +0000

On 7/7/17, 4:42 PM, "iasa20 on behalf of JORDI PALET MARTINEZ" <[email-masked] on behalf of [email-masked]> wrote:
> we need to define how the committee members are elected. 

[JL] Speaking as just one person on the design team, we did discuss that a bit. But IIRC we decided to focus on the selection process only after we get more feedback from the community on the various organizational models (at the IETF 99 meeting), and so it would follow after that. I think we all recognize it is an important matter and so share your concern.

>    2) Accountability of IAOC (or whatever replaces it). We need to make sure that they respond to the community and define strict deadlines for that (I can tell you that I’m still waiting responses…
    
[JL] Good point. Accountability & transparency are paramount IMHO.  

>  3) We also need to specify if anything is not going to be transparent. There is no sense to hide anything from the community, unless is clearly defined upfront.

[JL] Ack

---

From: Jari Arkko <[email-masked]>
Date: Sat, 8 Jul 2017 18:08:38 +0300

Thanks Jordi for these points — agreed. And Jason is correct
in saying that we wanted to get some feedback on the various
models before going into the details of selection. But that too
is something that will need to get designed & decided.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 9 Jul 2017 21:51:51 +0100

Thanks for the DT's efforts on this.

I guess I understand how the DT got there, but I'm a bit
disappointed that so far, we only seem to have addressed
the "should the IETF incorporate" aspect of the iasa2
work.

Anyway, my initial take on the draft is:

- IASA++ seems the obviously right option to me.
  The other two structures have either a "pro" or
  a "con" (depending on one's opinion) which is
  that the IETF becomes an incorporated entity.
  I think the effort to reach consensus on that
  topic could de-rail the iasa2 work and we'd risk
  losing the increased transparency etc. we want to
  get. So that'd just leave IASA++ as being the
  only feasible option.

- I didn't find section 6 clear or convincing but
  it's also hard to see how one might document
  such an analysis at this point. Maybe when I
  read it more closely or we see a presentation in
  Prague, it'll be clearer, but as of now, the DT's
  analysis isn't that clear to me. It could be that
  I change my opinion about IASA++ if/when I do
  understand the DT's analysis better, but I'd be
  surprised if that were the case.

Cheers,
S.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 11 Jul 2017 21:56:01 +0300

Stephen,

> the "should the IETF incorporate" aspect of the iasa2

That’s taken a fair amount of discussion, but in the
document Sections 5.2 and 5.3 are not about that.

I guess my question to you (and more generally all
of you) is whether we’ve missed options or aspects
that we should have explored. The idea with the
meeting next week is to talk more about potentially
missing options or what we should put into to the analysis
of those options, than what the “Right Answer” is
for the IETF yet.

So, do you have thoughts on what aspects we
are missing and which should be documented?
Or are you unhappy with the level of detail or
analysis of the current options?

>  surprised if that were the case.

At this point, we’d love to hear your thoughts
on aspects that should be taken into account.
Lets worry about what the right conclusion is
later.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 20:55:17 +0100

Hiya,

> document Sections 5.2 and 5.3 are not about that.

Note that my comment wasn't meant as a criticism of
the DT - I really can see how that would end up being
talked about first and take time and take up most
of the -00 version text. (Disappointed maybe wasn't
the right word, sorry.)

> of those options, than what the “Right Answer” is

For me, the main things that need improving with IASA
nearly all relate to transparency and I think that got
maybe one mention in the draft. (Didn't check back,
sorry if I've gotten that wrong.) I would have hoped
that a default-open statement would have been included
and to see if that'd differ based on the different
organisational options.

So I'd be interested in the analysis covering which
of the options might be most transparent. I worry
there's a big risk that transparency++ might get
lost if we undertake the two more radical changes
to the organisation.

> analysis of the current options?

Not sure it's that useful to note but there are
things with which folks seem generally very happy
(e.g. AMS staff today) and I don't think the draft
covers not-breaking-those. So what other things
do we not want to break? Lack of membership is
one I'd like to keep, there may be more. So maybe
consider documenting things we like too?

> Lets worry about what the right conclusion is

Fair enough. But TBH, I think I still need to see
the presentation in Prague to get what's being
said in the analysis. I'll try give it another
read in the meantime if I can and respond further
but not sure I'll have a chance.

Cheers,
S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 11 Jul 2017 15:58:16 -0400

>   get. So that'd just leave IASA++ as being the

Hi Stephen!

Can you say a bit more why the two more legal separation/incorporation
options are obviously not right to you?

The reason I ask is that we consciously tried to bound the solution
space and having an enhanced status quo, some of the benefits of legal
separation, and then full fledged legal separation seemed like the
right way to do that.

If we are missing any gleans on the IASA++ options, it would be great
to get that into list discussion if you are game. Thanks as always for
wonderful feedback.

best, Joe

---

From: Ted Hardie <[email-masked]>
Date: Tue, 11 Jul 2017 12:59:54 -0700

Howdy,

I have read the draft and I appreciate the work that has gone into it.  I
must confess, however, that my disquiet with the result is both large and
distressingly hard to articulate.  As it stands, the best place for me to
hang my concern seems to be in Section 5.2, where the draft touches on
issues related to oversight.

It appears to me that one key concern is that the type of oversight
exercised by the IAOC may not be appropriate.  Some folks feel that it is
working at the "decision by decision" level rather than in the "strategic,
goal-setting level" mode and that this contributes to a series of other
issues (speed, transparency, and consistency all being effected).  What
worries me is that the draft appears to believe that a shift in this
oversight style can and would be accomplished by re-structuring the
relationship to ISOC.  A new board type would naturally, it appears to
suggest, have a new board style and strategic level.

>From my perspective, this issue lies along a completely different axis of
change.  Changes in the relationship to ISOC might be useful for clarity in
fund raising, in financial management, and in other structural things, but
I don't think it can solve this problem.   Many different board types dive
in and out of the weeds and selecting a new type thus may not help us avoid
that.   Avoiding that requires understanding what drives a board to drill
down and what keeps them in that path after (in our case, I suspect it was
initially concerns over capture and eventually precedent).

Making the goal of shifting the strategic level of board discussion a part
of the decision to pick a different structure worries me.   If we think
we're getting a better shot at strategic thinking-level board behavior by
picking structure X, we may weight that heavily in choosing X.   If they
are, in fact, only loosely related, we may end in a different place than we
should as a result.

Make no mistake, I agree that there is change needed along this axis.  But
presuming we get that change for free with an unrelated structural change
seems to me at best optimistic and at worst problematic.

Thanks again for your efforts,

Ted

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 21:07:04 +0100

> to get that into list discussion if you are game. Thanks as always for

You're too nice:-)

As I kinda said in response to Jari, I fear that the
changes I'd most like to see (transparency++) would
get lost in the noise of all the added overhead of
the larger organisational changes.

I guess that's based on seeing how horrible the IANA
transition was - such a simple change required such
a huge effort. Of course, iasa/2 is much more IETF
internal, but I'd still fear that a lot of the same
cruft would accrue.

Cheers,
S.

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 11 Jul 2017 17:12:19 -0400

On Tue, Jul 11, 2017 at 3:59 PM, Ted Hardie <[email-masked]> wrote:
> change.

We had been trying very hard to keep both of those as orthogonal
issues -- we referred to the first in our discussions as overall
organizational structure and the second as internal reorganization. It
sounds like from this that we didn't do a good job explicitly saying
we see these as dependent but separate. (dependent in that the
internal reorg naturally will look differently depending on the
organizational reorg.)

Or did I miss nuance, Ted?

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Jul 2017 01:29:19 +0300

> and to see if that'd differ based on the different

The transparency topic has been high on our
mind, but we’ve struggled to figure out what
exactly to say about that. The default-open
statement is certainly one way forward,
thanks for reminding us of that.

But, what specifically will that include? I suspect
that the devil is in the details. Personnel discussions…
contract awards… sums until an award for a project
is made… negotiation strategies… discussion of
legal issues such as court cases where IETF is
included… there are a fair number of these, even
outside the most discussed topic of hotel contracts.

Would a specification (e.g., RFC) of what’s open and what’s
not open be the ultimate outcome of that approach, or
would you see that as an alternative to the
default-open statement?

> lost if we undertake the two more radical changes

Impacts on transparency are clearly a necessary
piece of the analysis. That needs to be added. Thanks.

> consider documenting things we like too?

Good points. Would certainly want to include
a positive statement about things that are currently
working well.

> but not sure I'll have a chance.

In honesty, the analysis section is very early
text.

Let me turn your statement around a bit. We still
need to hear what you care about in Prague in
order to produce a more complete analysis section :-)

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Jul 2017 23:37:12 +0100

Just one addition for now:

WRT default-open: I'd suggest starting from a
position where there's a default-open policy
with a published list of exceptions that can
be changed (shortened or added to) via some
TBD iasa/2 process - for today, I'd suggest that
the IAOC publish changes to that list via the
[email-masked] list and have to take feedback
from the community - the future analog of that
shouldn't be hard to figure. in future.

The inclusion of something like the above in
the draft would mean happiness++ for me:-)

Cheers,
S

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Jul 2017 01:40:11 +0300

What Joe said.

Despite what the document may be saying, we did think of the nature of the
IAOC decision making and ISOC relationship as two different dimensions of
the solution space. They are related, but not bound to each other. My personal
opinion is that there absolutely needs to be a change in what the scope of
community-filled oversight board does from what they are doing today,
irrespective of what happens in the ISOC interface.

Ted wrote:

> Changes in the relationship to ISOC might be useful for clarity in fund raising, in financial management, and in other structural things …

Well articulated.

> Many different board types dive in and out of the weeds and selecting a new type thus may not help us avoid that.   Avoiding that requires understanding what drives a board to drill down and what keeps them in that path after (in our case, I suspect it was initially concerns over capture and eventually precedent).

Good points. It wasn’t the intent to claim that a change in the ISOC
interface would bring about a change in board behaviour, we were
trying to ask for an independent change in the scope of the board.
Your point about board’s official role not necessarily driving this
sort of behaviour is valid. Would be interested in your thoughts
(you now also being an IAOC member) on how to change that
in this particular case.

Also:

> Make no mistake, I agree that there is change needed along this axis.

Let me ask a clarifying question. Since again you’ve now seen
the insides of IASA, do you personally agree that this is at least
a part of the problem we are having:

> … one key concern is that the type of oversight exercised by the IAOC may not be appropriate.  Some folks feel that it is working at the "decision by decision" level rather than in the "strategic, goal-setting level" mode and that this contributes to a series of other issues (speed, transparency, and consistency all being effected) ...

Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Jul 2017 01:42:58 +0300

Stephen,

> shouldn't be hard to figure. in future.

Ok. That seems reasonable — kind of a transparency
about transparency -process :-)

Jari

---

From: Ted Hardie <[email-masked]>
Date: Wed, 12 Jul 2017 09:29:26 -0700

> trying to ask for an independent change in the scope of the board.

Scope is an interesting problem here, because in some of these structures
(Subsidiary and independent org), a board will have a fiduciary duty to the
organization.  That duty defines the scope to a very great degree.  The
issue
isn't with scope, at least in my view, but with a combination of mechanism
and culture.

> a part of the problem we are having:
I have not been part of the IAOC for very long, so my opinion is mostly
shaped
by experiences outside it.  My take with that combination of experience is
that
the IAOC could not suddenly revert to a more strategic approach right now,
because many
of the processes and committees it has are built around the current way of
working.
I do think that it could move to a more strategic approach (as, IASA++
suggests)
if  a new set of support systems were in place.  The trick, and it will be
trick, is making
sure that the change goes with the adoption of the support systems *because
it will
not be an inherent part of that change*.  Some combination of personnel
changes (like
dropping the number of ex officio members), new instructions to NomCom, and
very
active recruitment of outside talent will be required.  That is likely
true, honestly, whatever
structural changes we put in place.

Obviously, this is my personal opinion, and should be taken with a bit of
"still a newbie at this"
weighting.

regards,

Ted

> > … one key concern is that the type of oversight exercised by the IAOC
> may not be appropriate.  Some folks feel that it is working at the
> "decision by decision" level rather than in the "strategic, goal-setting
> level" mode and that this contributes to a series of other issues (speed,
> transparency, and consistency all being effected) ...
>
> Jari
>
>

---

From: Jari Arkko <[email-masked]>
Date: Wed, 12 Jul 2017 23:18:23 +0300

Ted,

> My take with that combination of experience is that
> the IAOC could not suddenly revert to a more strategic approach right now, because many
> of the processes and committees it has are built around the current way of working.

Agreed.

> I do think that it could move to a more strategic approach (as, IASA++ suggests)
> if  a new set of support systems were in place.  The trick, and it will be trick, is making
> sure that the change goes with the adoption of the support systems *because it will
> not be an inherent part of that change*.  Some combination of personnel changes (like
> dropping the number of ex officio members), new instructions to NomCom, and very
> active recruitment of outside talent will be required.  That is likely true, honestly, whatever

Makes sense. Thanks.

Jari

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Jul 2017 15:47:56 +1200

In case your reaction to my review just posted is TL;DR:
>> of the processes and committees it has are built around the current way of working.

Hence my question: what were the conditions and dynamics that led
to the IAOC becoming effectively an executive committee rather
than the oversight committee intended? If we don't understand that,
it will probably happen again.

   Brian

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 15 Jul 2017 08:26:56 +0000

On 7/14/17, 5:47 AM, "iasa20 on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:
> Hence my question: what were the conditions and dynamics that led to the IAOC becoming effectively an executive committee rather than the oversight committee intended? If we don't understand that, it will probably happen again.

The design team discussed some thoughts as to why this is the case and how to avoid it. This may be best addressed by a question at the microphone during the meeting. 

My personal sense, which I am happy to expand upon at the meeting (and will make little sense in 1 sentence), includes issues around job definition & scope, transparency, background/experience & goals of the people/group selecting for the roles, background/experience of the candidates, and more. 

- Jason

---

From: Matthew Ford <[email-masked]>
Date: Sat, 15 Jul 2017 10:32:02 +0200

> On 15 Jul 2017, at 10:26, Livingood, Jason <[email-masked]> wrote:
> 

The history of the IASA experience is certainly interesting and relevant. In addition I think there are also natural human tendencies at work here, so to the extent that any future structure depends upon the clear demarcation of roles between strategy and operations, we probably need to think carefully about mechanisms that could help prevent the natural tendencies diluting original intent or at least support roleholders as they attempt to maintain alignment between practice and theory.

Mat

---

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 15 Jul 2017 08:45:10 +0000

+1, Matt – good point

On 7/15/17, 10:32 AM, "Matthew Ford" <[email-masked]> wrote:
The history of the IASA experience is certainly interesting and relevant. In addition I think there are also natural human tendencies at work here, so to the extent that any future structure depends upon the clear demarcation of roles between strategy and operations, we probably need to think carefully about mechanisms that could help prevent the natural tendencies diluting original intent or at least support roleholders as they attempt to maintain alignment between practice and theory.

---

From: Bob Hinden <[email-masked]>
Date: Sat, 15 Jul 2017 14:07:21 +0200

Hi,

I finished reading the draft and have some comments I would like to share.

I think it is an oversight in the document to not discuss the financial implications of the different models.  It’s most significant in the Independent organization, but they all have financial impact.  Creating an ISOC subsidiary or Independent organization will have a significant financial impact and should be part of the discussion.  Where will the money come to pay for the increase?  I think it’s critical to understand the financial implications of the different model.

The current expense level (from 2017 IASA budget) is a little over $7M a year (including indirect ISOC contributions of staff).  ISOC contributes about $2.2M to make up the difference revenue and expenses.  I don’t know how much additional an independent organization will cost, but I suspect it will be a large number.  It’s going to have to cover new staff, insurance, overhead of running a corporate entity (filing taxes, HR, corporate reporting, etc.), etc.  New issues will be created, for example will a venue want to sign a contract with the new IETF org it has never heard about before and doesn’t have a credit rating?

I agree we have a fund raising problem, but it’s not going to be fixed simply by adding a Director of Fundraising.  The problems are more structural and caused by changes in the industry.  We recently all saw a large company that provided significant support for the IETF, layoff many long time IETF contributors.   We need to come up with better ways of show the value the IETF brings to the Internet.  Essentially, how do we sell the value of IETF to potential donors?  This isn’t fixed by reorganizing ourselves.

Significantly increasing the cost of the IETF without knowing how expensive the new plan is, or knowing how it is going to be paid for isn’t going to work well.  If we want to be an independent organization, we need to also be responsible for the finances.  We have lived in a world were decisions were made without thinking about how much they will cost.  No cost benefit analysis.  If the IETF is going to be an independent organization, that culture will have to change.

One of the issues raised in the document is the difficulty of the NomCom finding qualified volunteers for the IAOC.  Unless we can understand how to fix that, how is the NomCom going to fill positions on a Board of Directors?   It’s only going to become worse.

Another thing the IETF is not very good about is managing staff.  That is, writing performance reviews, setting appropriate goals, fairly judging their performance, replacing them as needed.  If we are going to have more staff, then this needs to be dealt with.  It’s hard for volunteers to manage paid employees.

I think it’s important that the IETF Trust should be kept of of this.  It is working, it has a bank account, and is doing well holding the IETF IPR, and IANA trademarks and domains.  Bringing it into some sort of new IETF organization, might well cause the ICANN community to reconsider moving the IANA trademarks and domain there.  Let’s not go there, the rest of this is hard enough.  At some point, we might consider having the IETF Trust have a set of trustees who are not the same as the IAOC.  But again, that doesn’t need to be done now.

Bob

---

From: Bob Hinden <[email-masked]>
Date: Sat, 15 Jul 2017 14:08:16 +0200

[Resend without Draft in the Subject, please respond to this one]

Hi,

Bob

---

From: Lou Berger <[email-masked]>
Date: Sat, 15 Jul 2017 08:57:55 -0400

Bob,
	+1 for your comments on considering financial impact; they resonate
with me.

Lou

---

From: Jari Arkko <[email-masked]>
Date: Sat, 15 Jul 2017 15:38:12 +0200

> I think it’s critical to understand the financial implications of the different model.

Acknowledged and agreed.

> I think it’s important that the IETF Trust should be kept of of this.

(I think you meant “out of this”?)

FWIW, and I’m not speaking for anyone else than myself here, but I definitely agree. I think the Trust could be a part of the changes, but only to the extent that you separate the members of Trust and any other board that governs the rest. I don’t believe it would be useful to merge the Trust’s account or role with other entities. Even if we were to create an independent IETF organisation, there are good reasons to keep the ownership of IETF IPR separate. Separation of concerns, ensuring that IETF IPR is separate from any financial issues that IETF might otherwise have, etc.

Jari

---

From: Bob Hinden <[email-masked]>
Date: Sat, 15 Jul 2017 15:55:05 +0200

Jari,

> On Jul 15, 2017, at 3:38 PM, Jari Arkko <[email-masked]> wrote:
> 
> 

Yes, that is what I meant.

> FWIW, and I’m not speaking for anyone else than myself here, but I definitely agree. I think the Trust could be a part of the changes, but only to the extent that you separate the members of Trust…

Good.  The best approach is probably to limit the IASA 2.0 to what is critical to fix, not everything we can think of.

Thanks,
Bob

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Jul 2017 08:43:08 +1200

> The history of the IASA experience is certainly interesting and relevant. In addition I think there are also natural human tendencies at work here, so to the extent that any future structure depend…

Yes, and we should be honest with ourselves. A lot of us, certainly including me,
are generally impatient to get on and do something when we see that something
needs to be done. In some ways the IETF attracts people with that tendency. 
So many of us are intrinsically bad candidates for an *oversight* committee.

    Brian

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 17 Jul 2017 15:00:12 -0400

Hi Bob,

> On Jul 15, 2017, at 9:38 AM, Jari Arkko <[email-masked]> wrote:
> 
> 

Another note here about the DT’s work scope, since this is something I talked with them about before they started: I agree as well, but thought it would be useful for the DT to generate a few options for initial discussion before asking them to produce a full-on financial plan attached to each option. For one thing, they had about six weeks to get a draft together, so the scope of their work needed to make it feasible to produce something for discussion in that time frame. Furthermore, if it were the case that the community has no interest in some of the options, then it would not much be worth investigating and proposing funding models for them. So getting some initial substantive feedback before doing that seemed like it might expedite the process.

Alissa

---

From: Bob Hinden <[email-masked]>
Date: Tue, 18 Jul 2017 08:13:13 +0200

Alissa,

> On Jul 17, 2017, at 9:00 PM, Alissa Cooper <[email-masked]> wrote:
> 
> Hi Bob,
> 

Understood, however I don’t think the community can realistically evaluate the options with out some information on how much each plan will increase our overhead.  This doesn’t need to be an detailed financial plan for each, but some high level estimates.  Otherwise it’s akin to going shopping for a car without knowing the prices and/or ones budget.

Thanks,
Bob

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 18 Jul 2017 04:03:09 -0400

Dear colleagues,

I'm unlikely to be in the IASA 2.0 BoF today.  I've read the draft and
I have some remarks. 

I want to thank the DT for their work and for getting this together so
quickly.  

> of options being considered would be welcome.

I think that the possible options, to a first order of approximation,
are right, but I fear that the trade-off discussion is a little too
flat.  In particular, I fear that the analysis does not place enough
emphasis on the achievability of each potential option, compared to
the advantages that each might bring.  This is in some sense similar
to Bob's worry about financial impact: one might like the advantages
of the most expensive option, but if one doesn't have the money then
one can't have it.  The same is true of time: if the difference in
transition time between two options is measured in years, that seems
like it will be a pretty important factor.  My own sense is that
anything we predict will take more than 18 months is a non-starter,
because of the term length of appointees.

This brings me to a second issue: the document is silent on the term
length of IASA++/board members, but I think that issue has to be faced
squarely.  We have a serious structural problem in that the oversight
function ought to be responsible for longer-term considerations, but
as a practical matter they can't have a horizon of more than 2 or
maybe 3 years because of appointment lengths: nobody who makes a
current plan can say with any assurance that they'll be around when a
plan takes effect.  We already see this problem explicitly in
controversies over meeting site selection, but I think the problem is
a deep one.  If we don't tackle this problem as a first-order one,
we'll miss it in any arrangements that we make.

Finally, and perhaps related to the first issue, I disagree very
strongly with the claim that we should not try to separate the Trust
membership from the IAOC-or-successor membership at the same time we
are making other changes.  On the contrary, I think the linking of the
Trust is a really serious structural problem that could easily hurt
our ability to do something about IASA if we do not plan explicitly to
address it.  The Trust once was responsible only for property that
affected the IETF directly, but that is no longer true.  We need to
avoid creating the conditions under which issues that people have with
the Trust composition constrain our freedom of movement in what we can
do to our administrative support arrangements.  At the same time, the
overloading of the IAOC membership with Trust responsibilities means
that the workload arrangements are quite bad if there is a lot for the
Trust to do; so fixing that overloading ought to be an important goal
in this effort.

I think that the DT draft is a good start, and I look forward to
continued progress.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Tue, 18 Jul 2017 08:59:52 +0000

Thank you so much, Andrew. I think you may actually be agreeing on the IETF
Trust piece: I think Bob and others were worried more about the legal
status of the trust in the later two options, not the composition of the
Trust Board, which I think it's fair to say was a good arrangement -- to
overlap substantially with IAOC -- but that recent developments (IANA
transition -- have exposed how that can be over-stained such that it would
be good to explicitly plan for those sets to be more disjoint. (I think
Jari has been making this point as it was painful (my words) over his Chair
tenure.)

I may be misunderstanding everyone is no one here! Best, Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jul 2017 08:39:31 +1200

On 18/07/2017 20:59, Joseph Lorenzo Hall wrote:
> Trust Board, ...

That was certainly my concern. I think it's vital that the trust remains
legally independent and self-standing, as it is today. How the trustees
are appointed is a separate matter, and I can certainly see that the
original choice (Trust members == IAOC members) is open to debate today.

    Brian

---

From: Jari Arkko <[email-masked]>
Date: Fri, 21 Jul 2017 09:54:55 +0200

Thanks for your comments, Andrew.

> flat.

Certainly. We are not very far either in the complete description
of the options or their comparison. And personally I felt that
the comments in the BOF also pointed to that we need a better
mapping from problems we intend to solve to individual components
of a new organisation. For instance, transparency is largely
orthogonal to some of the structural issues.

> In particular, I fear that the analysis does not place enough

Good point.

> we'll miss it in any arrangements that we make.

Ok.

> Trust to do; so fixing that overloading ought to be an important goal

FWIW, if I understand your comment correctly I also agree with it.
I personally would like to keep Trust separate, and intentionally
firewall it from the rest, for the reasons you state and also some
other reasons; trust serves Internet’s users and the global community
(e.g., copyrights of the RFCs) and the IETF admin otherwise largely
serves the needs of the much smaller IETF community.

Jari