Re: [Iasa20] Review of draft-haberman-iasa20dt-recs-00

[Joseph Lorenzo Hall <[e-mail]>]

I must admit I found Brian's feedback hard to turn into constructive
changes to this effort or the draft, but we're determined to figure it out
so if would be great to dig in on each point further. Best, Joe

On Fri, Jul 14, 2017 at 12:41 Stephen Farrell <[e-mail]>
wrote:

>
> Hiya,
>
> Just to note that I read through (all of:-) this and
> agree with basically all of Brian's comments. If the
> DT took these on board for the next iteration that'd
> be great. It'd be even better if possible to include
> these in any presentations in Prague as changes that
> are TBDs. (But I'd understand if the DT haven't time
> to get that done for Prague.)
>
> Cheers,
> S
>
>
> On 14/07/17 04:33, Brian E Carpenter wrote:
> > Hi,
> >
> > Apologies for the length of this, but I will not be in Prague
> > and I have a number of comments, needing text extracts to make
> > any sense. First though I want to thank the team for their work.
> > If the following appears critical it's because I've covered
> > my points of disagreement, not the parts that I agree with. One
> > general remark: we do have problems and do need changes. The
> > debate is about the nature of the changes.
> >
> >> 3.  Challenges
> >>
> >>    Discussion leading to this document has been framed by the issues
> >>    discussed on IETF mailing lists and documented elsewhere
> >>    [I-D.daigle-iasa-retrospective], [I-D.hall-iasa20-workshops-report],
> >>    [I-D.arkko-ietf-iasa-thoughts].  The reader is referred to those
> >>    documents and ongoing discussion on the [e-mail] mailing list
> >>    for fuller details on the range of challenges facing the IETF in its
> >>    handling of administrative matters.
> >
> > To be frank I think this isn't enough of a problem statement to justify
> what
> > follows. Last time around we had two RFCs before problem solving even
> started:
> > RFC3774 and RFC3844. Maybe the problems now are less severe, but I think
> > we still need a consensus version of the problem analysis.
> >
> >>    In summary, the key areas of challenge that have shaped this work
> >>    are:
> > ...
> >>    o  Lack of predictably of funding levels combined with regular
> >>       shortfalls.
> >
> > This seems a bit inaccurate. Isn't the problem that meeting income
> > is unpredictable so there have been unpredictable budget shortfalls,
> > combined with ad hoc budget top-ups from ISOC? And is this the place
> > to mention that the IETF does not have its own reserve fund?
> >
> > I think there's a missing bullet in this list, and it may have
> > consequences later on:
> >
> > o  The committee intended to provide oversight of administrative
> >    work has in practice become directly involved in performing
> >    some aspects of the work.
> >
> > We might also add this, which does come up later on:
> >
> > o  The committee intended to provide oversight of administrative
> >    work has also become responsible for various intellectual
> >    property issues.
> >
> > ...
> >> 4.  Considering a Change
> > ...
> >>    The overall structure also includes questions such as whether IETF is
> >>    an organisation...
> >
> > I find that phrase bizarre. There's no doubt that the IETF is an
> > organisation; the question is what sort of organisation it is.
> > And there is a complicated question, which perhaps belongs above
> > in the Challenges, about how volunteers and paid staff interact
> > in the administrative work.
> >
> > ...
> >> 4.1.  Goals
> > ...
> >>    o  Define the roles of the oversight entities and staff/contractors
> >>       to match the grown size of the tasks.  Ensure that we have a
> >>       structure that can adapt to future growth and other changes.
> >
> > I suggest including in that: Define how volunteer contributions to
> > the tasks interface to staff and contractors, and specifically how
> > volunteer effort is directed and managed.
> > [In plain English, who tells the volunteers what to do or not do?]
> > ...
> >
> >> 5.1.1.  IASA++
> > ...
> >>    o  Add IASA staff to better reflect the increased workload on what is
> >>       now a single staff member.
> >
> > I think you should point out that this might be partly a re-badging
> > exercise in which some existing staff are formally assigned (full-time
> > or part-time) to IASA++, i.e. no new money in those cases.
> >
> > ...
> >> 5.1.2.  ISOC Subsidiary
> > ...>    o  Eliminate the IETF Trust and have the IETF subsidiary assume
> >>       responsibility for the IETF's intellectual property rights (IPR).
> >>       This would simplify the overall structure, but would also bundle
> >>       the IPR with the rest of the IETF operations.  Note that the IETF
> >>       Trust currently holds IPR also on behalf of the users of IANA.
> >
> > I think that would a very, very bad idea. If the IETF Trust is trusted
> > at all, it's because it is a completely independent legal entity.
> > Rolling it up into ISOC would cause endless debate in the wider world
> > of Internet "governance".
> >
> >>    o  Transfer existing ISOC funds earmarked for the IETF to the
> >>       subsidiary's bank account, and have future IETF income held in
> >>       that subsidiary's bank account.
> >
> > That will of course change nothing about the need for unpredicted
> > budget top-ups from ISOC; it is 100% cosmetic.
> >
> >> 5.1.3.  Independent Organization
> >>
> >>    In this option, a new non-profit organization (e.g., IETForg) is
> >>    created independent from ISOC as the new legal home of the IETF.
> >>    IETForg would have its own bank account, by-laws, charter, board of
> >>    directors/trustees, staff, and corporate identity.  The
> >>    administrative staff for IETForg could be kept lean and would likely
> >>    rely on contractors for the bulk of administrative tasks.  Minimally,
> >>    the IETForg staff would be responsible for administration,
> >>    development/fundraising, communications, and personnel management.
> >
> > Having watched ISOC since 1992, and ICANN since 1998, I can only say
> > that the result of this would be entirely predictable. After ~10 years
> > IETForg would be bloated, bureaucratic, people would be complaining
> > that it was "as bad as ISOC" or even "as bad as ICANN". Keeping
> > such an entity lean and mean indefinitely is virtually impossible.
> >
> > So, after ten years, do IASA 3.0.
> >
> > ...
> >> 5.2.  Oversight
> >
> > A missing bullet:
> >
> > o Whether the operational subcommittees (which include volunteers)
> >   report to staff or to the oversight function
> >
> >> 5.2.1.  Strategic Board
> >>
> >>    In this option, the current IAOC is disbanded and replaced by a
> >>    traditional oversight board, common in most non-profit organisations.
> >>    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.3).
> >
> > Of course, this was the original intention for the IAOC. So to make this
> > happen in future, we need to understand the conditions and the 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 composition of the board needs careful attention.  It is
> >>    important to have regular IETF participants in the board, but at
> >>    least some of the board members need to have skills and experience
> >>    less common among IETF participants, namely non-profit management,
> >>    budget experience, and ability to help make connections to raise
> >>    money or provide advice about fundraising (all of which are typical
> >>    for a non-profit board).
> >
> > Yeah. I've heard all that before. For the ISOC Board. For the ISOC
> > Advisory Committee. For IAOC too. I bet every non-profit organisation
> > has those requirements. It's not that I disagree; but the pool of
> > available people won't change.
> >
> >> 5.2.2.  Strategic Board and an Advisory Council
> > ...
> > I read the words, but I heard "ISOC 2.0". I think there's a lot
> > of wishful thinking here. There isn't a new pool of people for
> > these roles; we'd be competing directly with ISOC.
> >
> >> 5.3.  Staff Structure
> > ...
> >
> >>    o  Executive Director.  The person in this role is in charge of the
> >>       overall IASA effort, but can rely on other staff members below as
> >>       well as contractors.  The Executive Director is accountable to the
> >>       Board.
> >>
> >>    o  Director of Operations...
> >
> > I think this is over-design. It's the Executive Director's job
> > to decide on her staff structure.
> >
> > Also, my reaction is that if the IETF needs a Director of Communications,
> > we have gone collectively mad.
> >
> >>    Note: The Executive Director likely needs to be a full-time employee,
> >>    as is likely the case for the other Director-level positions.
> >
> > That is entirely unclear to me, unless "Director" means somebody
> > who actually does something, which sounds like an abuse of the English
> > language. The word "bloat" comes to mind again.
> >
> >> 6.2.1.  Pros and Cons
> >
> > I will have to overtype my comments on the tables in UPPER CASE,
> > not to shout but to distinguish them in a single fixed width font:
> >
> >>    Table 1 highlights the pros and cons of the IASA++ option.
> > ...
> >>    +--------------------------------+----------------------------------+
> >>    | Pros                           | Cons                             |
> >>    +--------------------------------+----------------------------------+
> >>    | Maintains familiar structures  | Does not provide the IETF with   |
> >>    | and relationships              | true independence of funding or  |
> >>    |                                | staff from ISOC                  |
> >                                         WHO CARES? WHY DOES IT MATTER?
> >>    +--------------------------------+----------------------------------+
> >>    | Start-up costs limited to      | Creates risk that challenges     |
> >>    | those associated with hiring   | present in the current IASA will |
> >>    | additional staff               | not actually be solved or will   |
> >>    |                                | re-emerge over time              |
> >        AND REORGANISATION "NERVES"      IMHO THIS DEPENDS MAINLY ON
> >        AMONG EXISTING STAFF             SEPARATING OVERSIGHT FROM
> >                                         EXECUTION
> >>    +--------------------------------+----------------------------------+
> >>    | Does not require legal and     | Potentially requires ISOC to     |
> >>    | administrative work to         | cede more authority to the IETF  |
> >>    | incorporate a new entity       | community or increase            |
> >>    |                                | transparency beyond ISOC's       |
> >>    |                                | comfort zone                     |
> >        DOES NOT RISK ONGOING BLOAT      STRAWMAN. NOT A REAL RISK
> >>    +--------------------------------+----------------------------------+
> >>    | Allows IETF to continue to     | Continuing confusion about       |
> >>    | rely on ISOC to somewhat       | alignment between ISOC and IETF  |
> >>    | frictionlessly compensate for  | on policy and standards matters. |
> >>    | budget shortfalls if necessary |                                  |
> >                                         WHAT CONFUSION? THIS IS NOT
> >                                         JUSTIFIED BY ANYTHING ABOVE
> >>    +--------------------------------+----------------------------------+
> >>
> >>                        Table 1: IASA++ Pros and Cons
> >>
> >>    Table 2 highlights the pros and cons of the ISOC subsidiary option.
> >
> >>    +----------------------------------+--------------------------------+
> >>    | Pros                             | Cons                           |
> >>    +----------------------------------+--------------------------------+
> >>    | Forces some delineation of       | Leaves open some potential for |
> >>    | responsibility, staff, and funds | continued lack of clarity      |
> >>    | between the IETF and ISOC        | about authority and funding    |
> >>    |                                  | between the IETF and ISOC      |
> >        WHY IS THAT AN ADVANTAGE?          THE NEED FOR FINANCIAL TOP-UPS
> >                                           WILL DO THAT ANYWAY
> >>    +----------------------------------+--------------------------------+
> >>    | Provides the IETF community with | Potentially requires ISOC to   |
> >>    | greater authority over IETF      | cede more authority to the     |
> >>    | administration                   | IETF community or increase     |
> >>    |                                  | transparency beyond ISOC's     |
> >>    |                                  | comfort zone                   |
> >        MAYBE, MAYBE NOT                   STRAWMAN. NOT A REAL RISK
> >>    +----------------------------------+--------------------------------+
> >>    | Can leverage existing ISOC legal | Requires legal and             |
> >>    | structures and personnel to keep | administrative work to         |
> >>    | administrative work required to  | incorporate subsidiary         |
> >>    | incorporate subsidiary to a      |                                |
> >>    | minimum                          |                                |
> >                                           AND EXTRA ONGOING ADMIN
> >>    +----------------------------------+--------------------------------+
> >>    | Requires less IETF community     | Vests more decision-making     |
> >>    | volunteer time commitment to     | authority in paid staff than   |
> >>    | administrative matters than      | under current IASA             |
> >>    | current IASA                     |                                |
> >        BUT NOT COMPARED TO IASA++
> >>    +----------------------------------+--------------------------------+
> >>    | Allows IETF to continue to rely  | Start-up costs include costs   |
> >>    | on ISOC to somewhat              | of incorporating the           |
> >>    | frictionlessly compensate for    | subsidiary and re-             |
> >>    | budget shortfalls if necessary   | organizing/hiring additional   |
> >>    |                                  | staff                          |
> >                                           AND EXTRA ONGOING COSTS
> >>    +----------------------------------+--------------------------------+
> >>    | Allows IETF to continue to       | Continuing confusion about     |
> >>    | leverage expertise of ISOC       | alignment between ISOC and     |
> >>    | administrative personnel         | IETF on policy and standards   |
> >>    |                                  | matters.                       |
> >                                           WHAT CONFUSION? THIS IS NOT
> >                                           JUSTIFIED BY ANYTHING ABOVE
> >>    +----------------------------------+--------------------------------+
> >>
> >>                   Table 2: ISOC Subsidiary Pros and Cons
> >>
> >>    Table 3 highlights the pros and cons of the independent organization
> >>    option.
> >
> >>    +-------------------------------------+-----------------------------+
> >>    | Pros                                | Cons                        |
> >>    +-------------------------------------+-----------------------------+
> >>    | Eliminates all ambiguity about IETF | Start-up costs include      |
> >>    | having authority independent from   | legal and administrative    |
> >>    | ISOC over staff, funds, and         | costs to incorporate a new  |
> >>    | decisions                           | entity, hire new staff,     |
> >>    |                                     | transfer contracts and      |
> >>    |                                     | funds                       |
> >>    +-------------------------------------+-----------------------------+
> >>    | Provides the IETF community with    | ISOC's financial support    |
> >>    | potentially complete authority over | for the IETF may be viewed  |
> >>    | IETF administration and funding     | as more tenuous if the IETF |
> >>    |                                     | is a legally separate       |
> >>    |                                     | entity from ISOC            |
> >                                              INDEED, BUT THE NEED FOR
> >                                              TOP-UPS FROM ISOC WILL
> REMAIN
> >>    +-------------------------------------+-----------------------------+
> >>    | Requires less IETF community        | Ability for the IETF to     |
> >>    | volunteer time commitment to        | rely on ISOC in the event   |
> >>    | administrative matters than current | of budget shortfalls may be |
> >>    | IASA                                | more limited                |
> >        BUT NOT COMPARED TO IASA++            THAT'S A SHOW-STOPPER
> >>    +-------------------------------------+-----------------------------+
> >>    | Allows for direct investment in     | Vests more decision-making  |
> >>    | small number of professional staff  | authority in paid staff     |
> >>    | specifically tailored to the IETF's | than under current IASA     |
> >>    | needs and culture, while continuing |                             |
> >>    | to rely heavily on contractors      |                             |
> >                                              IMHO THAT'S A PRO, BUT IT
> >                                              APPLIES TO THE OTHER 2
> >                                              SOLUTIONS TOO
> >>    +-------------------------------------+-----------------------------+
> >>    | Provides opportunity to structure   | Requires more from board    |
> >>    | board in such a way to overcome     | members than what is        |
> >>    | current challenges with IAOC        | currently required of IAOC  |
> >>    | structure                           | insofar as hiring and       |
> >>    |                                     | evaluating staff            |
> >        WE CAN DO THAT IN THE 2 OTHER
> >        MODELS AS WELL
> >>    +-------------------------------------+-----------------------------+
> >>    | Removes need for alignment between  | Requires IETF to assume     |
> >>    | ISOC and IETF on policy and         | legal risk currently        |
> >>    | standards matters.                  | assumed by ISOC             |
> >        NOT TRUE. WE WILL STILL BE            AND THAT'S ANOTHER
> >        FINANCIALLY ENTANGLED WITH ISOC,      SHOW-STOPPER
> >        AND WE WOULD BE CRAZY NOT TO
> >        BE ALIGNED WITH ISOC ANYWAY.**
> >>    +-------------------------------------+-----------------------------+
> >>
> >>               Table 3: Independent Organization Pros and Cons
> >
> > ** Also, any the authority the IAB has derives directly from ISOC
> >    and that covers the RFC Editor and IANA too. And also the IESG,
> >    given the Nomcom process. We would be playing with fire to change
> >    this dependency. The Internet governance wars aren't over, they're
> >    just on hold following the ICANN debate that exhausted everybody.
> >
> >> 6.2.2.  Comparison to Criteria
> >>
> >>    For the overall structure, the implications of the current situation
> >>    and the three options are summarized in Table 4.
> >
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | Criteria  | Current     | IASA++   | ISOC       | Independent     |
> >>    |           | situation   |          | Subsidiary | Organization    |
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | SCALE     | NO          | NO       | YES        | YES             |
> >                                  YES!
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | EVOLVE    | NO          | NO (Note | MAYBE      | YES (Note 1)    |
> >>    |           |             | 1)       | (Note 1)   |                 |
> >                                  YES!       YES!
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | STRAT TSK | NO          | NO (Note | YES        | YES             |
> >>    |           |             | 1)       |            |                 |
> >                                  YES!
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | OPS TSK   | YES         | YES      | YES        | YES             |
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | OVERLOAD  | YES         | YES      | YES        | YES             |
> >>    | SEP       |             |          |            |                 |
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | CLEAR     | NO          | NO       | YES        | YES             |
> >>    | ISOC REL  |             |          |            |                 |
> >                                  YES!
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | DIR       | NO          | NO       | YES        | YES             |
> >>    | CONTROL   |             |          |            |                 |
> >                                             NO!
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | CULTURE   | YES         | YES      | YES        | YES             |
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | WORK SEP  | YES         | YES      | YES        | YES             |
> >>    +-----------+-------------+----------+------------+-----------------+
> >>    | IASA EXP  | NO          | MAYBE    | MAYBE      | MAYBE (Note 2)  |
> >>    |           |             | (Note 2) | (Note 2)   |                 |
> >>    +-----------+-------------+----------+------------+-----------------+
> >>
> >>                Table 4: IETF-ISOC Relationship Implications
> >
> > I'm afraid I find these assessments quite inaccurate, mainly for the
> > IASA++ option. IASA++ will be what we make it. It scales because
> > it explicitly has more staff. It can evolve because the ED decides
> > on the staff structure (of course, within a financial envelope,
> > but there will always be a financial envelope). It can act
> > strategically because we'll fix things so the IAOC++ does strategy.
> >
> >>    Note 1: Evolution in the current system is more difficult than if
> >>    IETF was either clearly a subsidiary or its own organisation.  This
> >>    is because changes need agreement from two organisations, and, in the
> >>    current model, the control of IETF-dedicated resource is not as clear
> >>    as it could be.
> >
> > If you mean the accounts aren't clear, maybe, but that is completely
> > fixable in IASA++. As far as negotiating resources go, that is largely
> > fixed by correctly designating the staff who work for IASA. The bit
> > you can't fix in *any* model is negotiating the financial support from
> > ISOC. That's intrinsic and will never go away
> >
> >>    A subsidiary or independent model would also ease
> >>    driving any strategy that the IETF wants to drive, as decisions would
> >>    be more on the IETF side than something that today would require
> >>    negotiation with ISOC.
> >
> > I don't believe it. They have the money. If you want more of it,
> > you have to justify it with a strategy (a.k.a. business plan).
> >
> > ...
> >> 6.3.  Oversight
> >>
> >>    For the internal organisation, the implications of the current
> >>    situation vs. a strategic board model is summarised in Table 5.
> >
> > But somehow this doesn't address the question of why the IAOC
> > today doesn't work as intended, i.e. strategic oversight. I fully
> > support the goal, but unless we understand why it isn't working like
> > that already, how can we go forward?
> >
> > I still think the key is the way executive and oversight functions
> > have got mixed up, but I'm genuinely at a loss to see why we can't
> > fix that in the IASA++ model.
> >
> > ...
> >> 6.4.  Financial Impacts
> > ...
> >>    Secondly,there are some actual increases in required financial
> >>    resources.  We expect all the alternatives to lead to somewhat higher
> >>    funding needs, and in fact shifting more work to staff from
> >>    volunteers is one of the goals.
> >
> > Who decided that is a goal? Without seeing a clear accounting of
> > volunteer hours versus staff hours, how can we even discuss it?
> >
> > If this is code for saying "The IAOC is not there to do the actual
> > work," I completely agree. But that's a different issue, where the
> > goal is to make IAOC++ stick to strategy.
> >
> > If this is code for saying "volunteer work needs to be under
> > executive control from the IAD/ED/whoever," I agree too.
> >
> > But I have no basis for knowing whether reducing the volunteer
> > hours is in itself a valid goal.
> >
> > ...
> >> 6.5.  Other Impacts
> >>
> >>    Depending on the chosen option, volunteers are needed for either
> >>    different roles than today (the board) or for both different roles
> >>    and more volunteers (the board and the advisory council).
> >
> > And what about volunteers who do work, e.g. on the tools or the meeting
> > network? They deserve at least as much glory as those who sit on
> > committees.
> >
> > Regards
> >    Brian Carpenter
> >
> > _______________________________________________
> > iasa20 mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/iasa20
> >
>
> _______________________________________________
> iasa20 mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/iasa20
>
-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [e-mail], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871