Subject: [Iasa20] Review of draft-haberman-iasa20dt-recs-01

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Oct 2017 13:55:47 -0400

Hey all,

I have reviewed draft-haberman-iasa20dt-recs-01 and wanted to share a few
thoughts.  First, many thanks to the team that put this together.  I think
it
will be valuable in focusing this conversation.  Now, with regard to points
on
which the document requests feedback:

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

Yes.  As I'll discuss some below, I think the overarching questions here are
(1) where the line between IETFAdminOrg and the remainder of ISOC should be
drawn, and (2) how it should be encoded.  The three major options described
in
this document seem like a reasonably complete set of options for the
answers to
these questions.

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

Yes.  I agree with the assessments in the document, and can't think of other
implications that are not covered.  There are of course some details to be
worked out (some discussed below), but I think those are all at the next
level
of detail.

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

As above, I think the critical questions here are where the line between
IETFAdminOrg and the remainder of ISOC should be drawn, and how it should be
encoded.  In light of those questions, I view the three options on display
here
as points along a trajectory or spectrum: Each represents an increasingly
hard
line, and will require correspondingly greater clarity about the roles and
responsibilities of the entities on either side of that line.

To be honest, I'm not totally sure where along the spectrum would be
optimal.
That said, a few thoughts:

* I don't see much point to IASA++.  Given the  degree to which this
exercise
  is focused on increasing clarity and transparency, it seems worth having a
  clear organizational boundary and an entity that is clearly accountable to
  IETF.  If you were to try to meet the clarity and transparency goals while
  keeping the activities within ISOC, you would end up effectively creating
a
  subsidiary anyway, but without the benefit of the clear rules around an
  actual subsidiary.  In other words, IASA++ is just an inferior version of
  the Subsidiary case.

* I don't really see a lot of difference between the subsidiary and
independent
  cases as long as ISOC remains a predominant funding source for the IETF.
On
  the one hand, a subsidiary IETFAdminOrg will only ever be loosely
subsidiary
  to ISOC, given that IETF is going to want to maintain a large degree of
  control/oversight over it.  On the other hand, as long as IETF is largely
  reliant on ISOC for funding, ISOC will have a degree de facto control
  regardless of formal independence -- if they really don't like how IETF is
  being run, they can just pull the funding (or threaten to).

* Likewise, in either the subsidiary or independent cases, there will be a
need
  for an explicit contract / MoU with regard to funding.

* If there's going to be a new entity for IETFAdminOrg (vs. IASA++), where
it
  falls on the subsidiary/independent spectrum will depend largely on (1)
how
  its board is formed, and (2) what resources it shares with ISOC.  So it
may
  make more sense to focus more directly on these questions.

That's all I've got for now.  Looking forward to more discussion here and in
Singapore.

--Richard