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

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

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 [email-masked] 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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Jul 2017 11:41:31 +0100

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

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 14 Jul 2017 15:50:32 +0000

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

-- 
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: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Jul 2017 08:35:39 +1200

> so if would be great to dig in on each point further. Best, Joe

I didn't have time to propose specific changes, but I would say that
getting the problem/"challenge" analysis agreed would be the next step
(as it was in 2003). There are several gaps there which I think I pointed
out, but not all in one place:

o  Lack of clarity about how volunteers, paid staff and contractors
   interact in the administrative work.

o  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.

There are also seem to be a couple of perception problems
that I don't understand:

o  Perception of a lack of clarity about budget and money
   flow [which IMHO are perfectly clear from the published
   data, except for hidden staff costs].

o  Perception of confusion about alignment between ISOC 
   and IETF on policy and standards matters [which IMHO
   has been clear since 1992 and has never changed]. 

    Brian

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 14 Jul 2017 20:52:12 +0000

Thanks for the clarification!

---

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

is unpredictable so there have been unpredictable budget shortfalls,
    combined with ad hoc budget top-ups from ISOC? 

[JL] I think what you are saying here and what the DT intended in the bullet item are essentially the same. Perhaps it would benefit from some revision in order to make that more clear.

> And is this the place to mention that the IETF does not have its own reserve fund?
    
[JL] Good point and that is indeed an issue/concern that is one part of the broader financial questions IMO.

> o  The committee intended to provide oversight of administrative work has in practice become directly involved in performing some aspects of the work.

[JL] Probably good to add this as well. There certainly seems consensus that this is one of the key issues, which is what is driving the suggestion for additional staff/contract resources to perform this work, better job descriptions & expectations, and so on.
    
> o  The committee intended to provide oversight of administrative work has also become responsible for various intellectual property issues.
    
[JL] Seems a good suggestion as well. 

> [In plain English, who tells the volunteers what to do or not do?]
   
[JL] Ack

> So, after ten years, do IASA 3.0.
   
[JL] Most companies re-organize every few years, and certainly within every 10 years. Why should the IETF be any different from any other org? I guess my point is that how IASA operates or is structured should always be evolving and we shouldn’t shy away from being open about the need for continuous evolution/iteration. Maybe there should be an expected/planned evolution every 1 – 2 years in some formal sense. Certainly, I would hope for a review (and possible revision) of any new structure to follow some short time after it was implemented.
 
> o Whether the operational subcommittees (which include volunteers) report to staff or to the oversight function
    
[JL] Ack

[JL] I don’t necessarily agree with you that the pool of people will not change.

---

From: Ted Hardie <[email-masked]>
Date: Sat, 15 Jul 2017 11:02:58 +0200

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

>
> [JL] Most companies re-organize every few years, and certainly within
> every 10 years. Why should the IETF be any different from any other org?

I think this is the wrong parallel to make.  The IETF re-organizes its work
all the time, with new working groups, area shifts, and so on.  That's the
parallel to the typical corporate re-org.  You get a new WG chair
(manager), you get a new project (WG),  the VPs change out (ADs cycle off),
maybe even a business unit re-aligns (RAI and APPs merge to become ART).

This effort  contemplates a very different type of change, one which might
involve re-incorporation.    Re-doing that even every decade is certainly
not my experience of business practice in our industry, and I don't want us
to get on a pace of doing it that often.

I guess my point is that how IASA operates or is structured should always
> be evolving and we shouldn’t shy away from being open about the need for
> continuous evolution/iteration.

The parallel here might be the introduction of IASA committees and the
ability to spin then up, change their membership, and close them down.  I
agree with you that this should always be evolving.  I don't think we want
to describe IASA 2.0 at this level of granularity, beyond saying whether or
not it should have the ability to make these changes and what sort of
community review is expect.

> [JL] I don’t necessarily agree with you that the pool of people will not
As I said in a previous message,  the pool may change if there is a
concerted effort to make it change by recruiting outside our own
community.  But we don't get that for free by changing the structure.

regards,

Ted

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 17 Jul 2017 14:52:04 -0400

Thanks Brian, just one brief comment below re the DT’s efforts:

> On Jul 13, 2017, at 11:33 PM, Brian E Carpenter <[email-masked]> wrote:
> 
> Hi,
> 

When I asked the DT to work on this, I did not ask them to work on refining the problem statement. There may be a need to synthesize the content of the two drafts referenced above into a more crisp articulation of the problems, but that was not part of what they were tasked to do. And personally I would hope that we could proceed with that work in parallel with the community discussion generated by draft-haberman-iasa20dt-recs-00.

Alissa