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

[Jari Arkko <[e-mail]>]

Thanks for your comments, Andrew.

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

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

Good point.

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

Ok.

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

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