Re: [Ianaplan] CWG draft and its impact on the IETF

[John C Klensin <[e-mail]>]

Milton,

I think our long-term experience has been that, because of
different styles and assumptions, debating each other quickly
becomes frustrating for both of us and either amusing or even
more frustrating to others.  

I think you are entitled to a comprehensive answer to your
questions.  I fear that, as a result, this will be longer than
some members of the community prefer to read but hope you can
bear with me.

In particular, it should come as a surprise to no one that I
believe that an active market in domain names, ease of transfer
of names from one "owner" to another, and strong registry and
registrar profit motives are unhealthy for the Internet (and
especially for identifier stability).  I also believe that the
best model --again from the overall standpoint of Internet
well-being-- is operation along the lines of the "public service
on behalf of the Internet community" language of RFC 1591 and
that a hugely increased number of TLDs, whatever their vanity
value and with the possible exception of IDN-based ones, is far
more likely to increase user confusion and make the DNS
irrelevant to actual users than to bring real benefit (except,
again, to those who profit from selling and managing the names
themselves until that bubble collapses or people notice that it
already has).  

By contrast, you have long argued for just such a market, seeing
considerable advantages in that sort of competition, and giving
much less emphasis to the operational and identifier stability
principles that I consider important. 

Those differences in assumptions and priorities inform our
perspectives on a number of other issues.  Perhaps in a decade
or two it will be clear which of us was correct.

Now, to your specific comments...

--On Wednesday, May 13, 2015 11:15 +0000 Milton L Mueller
<[e-mail]> wrote:

> 
> John Klensin's issues responded to below.
> 
>> -----Original Message-----
>> 
>> I've having trouble understanding it as either a compromise
>> or a step in some right direction.
> 
> OK, so I would interpret this to mean that you don't think
> IANA registry operation should be separated from the policy
> making process; i.e., you are in disagreement with RFC 7500.
> Please explain more about why.

My opinion of RFC 7500 is not particularly relevant to this, in
part because I recognize that, unless IANA is reduced to a
purely clerical function of writing values determined by others
down in a (perhaps virtual) book when commanded, one can always
define "policy" in a way that makes the boundary fuzzy.    I
also note that the separation of IANA from protocol design and
policy activities goes back almost to the creation of IANA
(i.e., long before ICANN and even before the IETF) and soon
became at least as significant as the simple keeping of records.
When ICANN was created, it was not accidental that the
separation was preserved rather than, e.g., simply absorbing the
registry maintenance and operations into general ICANN
operations.

My objection to what I understand you to be suggesting is that
while separating registry operation and policy making is a good
principle, many of the methods that have been developed in the
last decade either raise questions of their own or have bad (or
at least risky) side effects.  Sometimes those side effects
result in reductions in the transparency and accountability that
should, IMO, be the real goal (from that perspective, separation
of policy and administration into separate bodies is just a
tool).   

As one example, the contractual NTIA-ICANN agreement about IANA
requires that IANA staff stay out of policy decisions.  I think
that is worthwhile as a principle.  In practice, those same IANA
staff often have substantive knowledge that is important to the
policy-making so we have, at various times, needed to get
exceptions from NTIA, seen some convoluted behavior within ICANN
that conforms to the letter of the rules but maybe not their
spirit, or decisions have been made without the best advice
possible.  I don't consider any of those outcomes especially
desirable, especially because they reduce the quality of
decisions (or our confidence in their quality), transparency, or
both.

As another, the IETF manages to keep policy-setting separate
from IANA registry/administrative functions by being very public
and clear, on a per-protocol and per-registry basis, about just
what the instructions to IANA are and where IANA does and does
not have discretion.  We don't create or use intermediate
organizations for that purpose.  The IAB and IAOC have also
created a small group to monitor and oversee IANA _performance_
on IETF tasks.  At least in theory, that group does not set
policy, certainly not registry policy.  There have also been, at
least IMO, some difficulties with the transparency and
accountability of that group which, because contracts are
involved (or, as some people have sometimes felt, using that as
an excuse), tends to operate with many things treated as
confidential.

There is a different sort of separation in the way that at least
some of the RIRs have traditionally worked, with broad policies
set by their communities, Boards, and Advisory Committees but
those bodies kept isolated from processing applications for
individual allocations and decisions about them.   One could
quibble forever about whether the latter type of decision-making
is actually policy or not, but the procedures do define a
relatively clear boundary, the boundary is enforced in practice,
and, subject to some confidentiality provisions and constraints
to which the relevant communities have agreed, there is good
transparency and accountability.

The PTI approach, at least as I understand it, concerns me in a
few different ways, none of which imply that I think separating
policy-making from administration and/or registry operation is a
bad idea:

(1) The IETF/IAB and RIRs both have policy models that appear to
work for them and mechanisms for monitoring and overseeing IANA
behavior and operations to the degree they think necessary.  PTI
does not seem to bring any benefits to those bodies and could
create confusion by giving IANA staff a larger number of
masters.  However (and modulo the concerns below) if the real
intent of the PTI idea is to give the names community some
additional mechanism that community believes it needs, I'm all
in favor of it... but then we should be discussing ways to keep
the PTI model from interfering with the protocol and numbers
communities and their normal operations, and probably calling
"PTI" something else because it is not IANA, it is one
community's mechanism for overseeing and insulating IANA.  If,
as I have heard suggested offlist, your concern is that the IETF
and RIR processes are insufficiently transparent and
accountable, let's deal with that directly, in an appropriate
forums, and at appropriate times rather than trying to hide it
as part of this transition activity. 

(2) I have observed, seemingly endless times, that ICANN's
institutional response to a controversial matter, a matter where
some interest really doesn't want transparency or accountability
(except possibly to themselves), or where some group wants a
particular outcome that the broader community does not
particularly favor or that might not be in the best interests of
the Internet, the "solution" is another committee.  In order to
insure that all interested parties are represented, the
committee membership becomes large and/or complex, resulting in
an activity in which no one can afford to participate actively
unless they are either associated with vested interests, are
supported by ICANN (an inherent conflict of interest no matter
how much mitigated by the integrity of the actors), or simply
have too much time (and typically financial support) on their
hands.  The result is typically a report that is too long and
complex for almost anyone to read and understand unless _they_
have vested interests or too much time on their hands and, if
that report doesn't satisfy the needs of whomever pushed for the
committee, calls for another committee and/or report.   Because
of those patterns and the difficulty of following work that goes
on in seemingly-endless committee and subcommittee meetings,
partial drafts, etc., transparency and accountability to the
broader community become, in practice, impossible.  ICANN Staff
is often accused of driving those patterns (with, IMO, some
justification), but the same patterns seem to come from other
groups of constituencies.   One might even suggest that the CWG
and its draft are consistent with the pattern.  

Perhaps you have reasons why PTI would be different and would
actually provide more transparency and community oversight but,
if so, I think that reasoning should be explained to the
community (more specifically, any communities you propose should
be tied up with or part of PTI).


>> Unless a substantial endowment
>> were somehow irrevocably assigned to it, it would still be
>> dependent on ICANN for budget
> 
> A fundamental misunderstanding. As a contractor of ICANN of
> course it would be paid by ICANN. We do not want IANA to be
> independently wealthy, nor do we want it to be a budgeted
> department of ICANN. We want it to be a service provider under
> contract to the names policy entity. 

I may very well not understand what you have in mind.  I
certainly do not understand why you think it is realistic.
First of all and as far as I can tell, if we ended up with the
IETF and/or RIRs/NRO having agreements about relevant IANA
functions with ICANN and the names community having an agreement
with a PTI for IANA functions that are relevant to them, either
we end up splitting IANA into two (or three) separate
organizations or we end up with a picture that looks like:

   IETF -> ICANN -> IANA Department
   NRO -> ICANN ->  IANA Department
   Names Community -> PTI -> ICANN -> IANA Department

I suppose ICANN could give that department enough autonomy to
sign contracts independent of the parent organization, but I
think only two things result from either the above picture or
the slightly more simplified one in which ICANN, outside an
operational IANA functions group, is not involved in the PTI
chain: increased organizational complexity (with likely
resulting increased costs) and far more opportunities to bury
costs and decisions and thereby reduce transparency and
accountability.   Of course, it would provide another committee
with those who collect committee memberships to add to their
CVs, but that is presumably not an important goal.

>> and it could not be spun off without permission from the
>> ICANN Board
> 
> I think this comment shows that you really do not understand
> what is being proposed by CWG. There is a periodic review
> process in the CWG proposal. If the names community found
> itself dissatisfied with PTI's services enough to issue an RFP
> that led to a selection of another operator, it would instruct
> the ICANN board to contract with another operator.

Again, our experience and perspectives differ, but my experience
suggests that the above is a fantasy starting with "instruct the
ICANN Board".   I don't know quite was CWG and its legal team
have in mind, but am reasonably confident that you won't be able
to force an ICANN Board to act against ICANN's best interests as
an organization.  If you get the ability to fire a Board that
didn't follow your "instructions", you would just end up in the
same situation with its replacement, probably after a delay long
enough to be harmful to the Internet.

> The choice
> then is either to contract with a new IFO or not. There is no
> "spinning off" of PTI.  Finding a new operator means shutting
> PTI down. 

And, if the IETF and/or RIRs are not fully-committed parts of
PTI, that decision basically fragments the IANA function(s) into
two or three separate organizations / operations.   Opinions
differ as to how serious that would be, but there would clearly
be some boundary registries to be dealt with, adding more
complexity.

>> and, as long as ICANN saw advantages to itself from being
>> responsible for central coordination and administration of
>> the Internet's names, numbers, and protocol spaces the Board
>> would presumably not agree (and arguably could not agree).
> 
> And we have anticipated that. If you actually read the legal
> and bylaw changes associated with the plan, you will see
> careful treatment of this issue. Special new measures are
> proposed that would make it difficult if not impossible for
> the board to ignore a recommendation from the aforementioned
> IANA Functions Review process. This aspect of the plan
> involves close coordination with the CCWG process.  

See above.   I admit to not having studied those provisions in
detail after the point that I concluded that they are
unrealis6ic.

Now, quite frankly, I think a number of ICANN behaviors and
decision patterns in recent years, some of which I think you
have supported, are causing (and risking) enough damage to the
Internet, the DNS, and the long-term usability and stability of
both that there are days on which I believe that, if one created
structures so constraining and unwieldy that ICANN eventually
collapsed, that wouldn't be entirely a bad outcome even though I
worry about the vacuum it would create.    At the same time, I
think the Internet is interesting enough as a social
communications experiment (intentionally or not) that I am not
very sympathetic to manufacturing "governance" experiments as
well.   In particular, I fear that, were the latter to go wrong,
we would find ourselves in the hands of the precisely the
multilateral or multiple-bilateral arrangements that we seem to
have rather broad consensus (including in the mandate from NTIA)
to avoid.  I think the risk of that is sufficiently serious to
require demonstration of very strong payoffs, solutions to real
and identifiable problems, etc., before carrying out
"governance" or organizational behavior experiments that might
trigger those risks. 

YMMD (and almost certainly does), but, given that the IANA
registries for the names community comprise six registries, at
least two or three of which are not under the control of the
control of ICANN-based names community policies and one more
than probably should not be, PTI seems to be to be solving a
problem that I'm having trouble identifying.  IMO, use of IANA
as a leverage/ final check point for US Government policy
relative to delegation of domain names has always been a
mistake.  Even if one believed the US Govt should have such a
role, IANA registry operations have never been the right place
to apply the review (I think I understand how that happened
historically, but that is another issue).   I am pleased and
relieved that no one seems to be suggesting a replacement for
that review point and role in the post-transition systems, only
increases in the accountability of the bodies who make the
actual decisions.  

However, that brings us to the question of what threat model
this apparently elaborate and complex PTI idea (including ICANN
bylaws changes, etc., as you point out) is intended to protect
against.   I understand the threat of an authoritative body
asking/telling IANA to make a registry change and IANA's taking
too long to do it or getting the change wrong (despite good
instructions), but can't imagine that takes a lot of structure
to deal with (or that a lot of structure would be likely to
help).  Unless the way in which the root signing key is managed
is changed, it is not clear to me that IANA was the right holder
of that key in the first place: it may be that some of the
details of how the root zone is signed and certified need review
and possible rearrangement, but I see no way that adding PTI
structure and review can help with that (it may have some
potential for further obscuring what is going on). 

In the domain space, the most difficult part of the IANA
function has always (since long before ICANN) been validation of
a request to make changes in the delegation records for a
domain, especially when the domain is under control of a
government and a request arrives that says "you've never heard
of me, but I'm part of the government and acting on its
authority and I want you to ...".  Significant parts of the
language in RFC 1591 are there because experience had indicated
that it was important that the IANA not be part of the disputes
that could result, especially if someone else claimed to be the
government and gave contradictory instructions.  For better or
worse, ICANN is erodes those protections.  However, the problem
is hard, is it, AFAICT, always going to be hard for a
multistakeholder organization operating outside the governmental
sector, and I don't see the PTI structure helping with it in any
way other than periodically being able formally to note that it
is still hard.  If you see that differently, please explain.

>> Even the idea that PTI would clarify the financial
>> relationships is dubious if ICANN could set the indirect cost
>> rate... at least unless that the basis for that rate,
>> including very specific numbers, were made fully public
>> and/or subject to auditors who were not chosen by or
>> accountable to ICANN.  It is not obvious to make how such
>> conditions could be met or how one could enforce their
>> continuation in a post-transition ICANN.
> 
> You are really grasping at straws here. PTI would be small and
> not that dependent on shared services. Most of its costs are
> staff, and the staff would not be shared anymore.

As far as I know --and I have not tracked the last few rounds of
ICANN organizational changes-- the IANA staff who are doing the
actual registry work are already segregated from other ICANN
staff in order to meet the requirements of NTIA's "keep IANA out
of policy making" requirements.  Whether one thinks of that
requirement and how it has been administered, there are
presumably no shared IANA operational staff today, so sharing of
them cannot be a present problem you need to solve.  (Whether it
is important to keep them separate, and whether the proposed
post-transition mechanisms are adequate to ensure that if it is,
is a question I wish were getting more attention.)  So, if there
is sharing today, it is precisely of people who are involved in
overhead functions (e.g., accounting and HR).  Stopping those
functions from being shared might save money, but it would be at
least as likely to increase expenses and, as you point out
below, it can't make a lot of difference at the scale of the
ICANN budget.

> It would
> have an independent management board though the legal type is
> not settled. If there were shared services (and maybe it's not
> a good idea for the root zone file managers to be reliant on
> the same facilities as, say, registrar outreach programs) they
> would be a small proportion of a budget that is relatively
> small to begin with. So there's not much room for manipulation
> there, and as a nonprofit it's not clear to me what the
> incentive for meddling with cost allocations would be. So it
> can charge itself more? 

Things like "the legal type is not settled" add to my concerns
in this area.  To me, they translate as "we want the communities
to sign up for a system for which critical details have not been
worked out, but you can trust us to get them right".  ICANN has
made me cynical enough that, in general, the only thing I
believe I can trust is that people and groups who understand
their own self-interests will act according to them.   As a
corollary, if there is a group advocating a position that I see
as a radical and/or complex change that involves at least some
possible consequences that can't be predicted and I don't
understand the motivation and/or self-interest, I get very
nervous... and you are seeing the symptoms of that nervousness.

But, again, there are differences in perceptions and starting
points.  I look at ICANN's reported claim of a USD 6.3 M loaded
IANA function budget and wonder simultaneously how things could
possibly have gotten inflated enough to produce a number like
that and which part of it you consider "small and not that
dependent on shared services".   I think trimming that number
down (maybe by an order of magnitude) would be desirable (if
possible), but that getting there would involves much more
aggressive management than your description above appears to
anticipate and that the PTI proposal seems to be irrelevant to
the important parts of that process... at least unless you have
agendas for PTI that seem inconsistent with your remarks above.

> In fact the transition process has _already_ created pressures
> to increase the transparency and rationality of IANA
> accounting and I suspect that more improvements would take
> place if this continued. Also, the scrutiny of the CSC would
> be independent of ICANN.

You suspect?  I hope that this whole "transition" process is
resulting in increased scrutiny of all aspects of ICANN
operations and accounting/ financial models.  I hope the
community will eventually figure out that an ever-expanding set
of ICANN operations, with its mission seemingly galloping (not
just creeping) in all directions and its budget steadily
expanding, whether those operations are assigned to IANA or not,
is not a desirable goal or beneficial for the Internet.   I wish
the community had been able to effectively initiate those sorts
of reviews without the transition process as a driver and am
somewhat concerned about the reasons why it didn't our couldn't.
But those issues have been segregated into "accountability" and
it remains unclear to me why inserting another organizational
entity into the operational system will improve things in any
way.

>> So, while I might be missing something, most of what I see in
>> the PTI arrangement is increased organizational complexity
>> (which almost always increases total costs) and the potential
>> for reduced practical accountability (since two groups of
>> people and entities would be responsible, not just one)).
> 
> Wrong. Wrt to cost, separation increases visibility and making
> costs more visible always creates a better capability to
> reduce them where they are out of line. And if you are worried
> about separation costs remember that IANA is 3.6% of ICANN's
> total budget (something we know only because of CWG efforts) -
> you could probably cover any lost efficiencies by, say, having
> only 4 instead of 5 staff members covering the weekly
> conference calls of CWG and CCWG. The growth in ICANN's budget
> in the last 5 years would fund about a dozen new IANAs.

Indeed.  But it seems to me that is a reason to engage on the
fundamental issues, rather than spending a lot of energy and
trying to create extensive new structures to tweak that 3.6%.
That is especially true because IAB/IETF and the NRO are on
record as believing that component is working well, perhaps even
exceptionally well.  While I've deliberately not been watching
carefully (too frustrating and I have other ways to spend my
time that actually are important to the Internet), my impression
has been that no one in the names community has stood up and
said "IANA is broken and performing badly in the following
specific ways and therefore needs to be fixed" or even "these
are the specific risks that we are concerned about and that
might plausibly get worse post-transition unless organizational
structures are changed".  So, again, while I think there are
big, Internet-threatening, issues with ICANN, it is not clear to
me why you believe that nibbling at the tip of the tail of the
dog (or, if you prefer a different metaphor, attaching a bell to
it) is a useful way to address that set of problems.

> "Practical accountability" would be enhanced. You have a
> Customer Standing Committee composed mainly of IANA users. You
> have a review process.  The CSC is capable of escalation to
> the ICANN board, or to a special review process in extreme
> cases. Accountability would be far more focused, because IANA
> issues would be concentrated in PTI, and not bundled into the
> gigantic ICANN policy ecosystem. This is more complex, yes.
> But that complexity is not a product of the legal separation
> of PTI. If IANA is not legally separated, you are going to get
> either the same or even more complex internal processes. 

Again, I understand the theory, but I don't see what actual
problem you are solving that justifies either the risk or the
increased complexity.  In addition, I believe that almost every
attempt in the last decade or so to solve an ICANN transparency
or accountability problem by creating more structure has turned
out to provide better mechanisms for hiding and obscuring things
and/or reducing the range of interested and materially affected
parties who are actively involved as well as causing (or
providing excuses for) more organizational expansion.   Perhaps
all the complexity, provisions, and mechanisms you have designed
into this one will make it different, but I don't think you have
actually made that case except by assertion.  More important for
the specific purpose of this list, I don't think you have made
the case that the IAB/IETF have a problem with the Protocol
Registries that needs solving or that, if they don't, why it is
to their/our benefit or that of the Internet to become
intimately involved in what looks to some of us like an
increasingly entangling process.

>> above are fundamental.  For example, as long as ICANN holds
>> the purse strings, it would be irresponsible of them to
>> irrevocably let go of some or all measures of control and
>> that any "instability" arguments that can be made today could
>> be made at any point in the future to support avoiding such
>> irresponsibility.
> 
> When you read the proposal (and your failure to do so is
> excusable given that it involves around 100 pages of CWG and
> 150 ofCCWG)

See comments about spawning of multiple committees and
generation of long and complex reports above.

> you will understand better what is the status of
> the "measures of control" and how they would be both more
> focused and more clearly delineated as a result of the
> structural separation. What are you missing? I don't know, but
> what I am missing is a plausible rationale for your rejection
> of a simple structural approach to these long overdue reforms.

And that takes us back to the difference in assumptions and
perspective from which I started above.  You believe that I need
to provide plausible rationale for rejecting this approach.
Because I see this as a fairly significant organizational change
with potential bad side effects (obviously, we may disagree
about that too), I believe that, if you want my, or
technical/protocol community, support, you need to demonstrate
the advantages of the approach and how those risks will be
contained or mitigated, and to do so without appeal to 250 pages
of reports that are still incomplete (i.e., I assume the
collection will get larger when those legal issues are agreed to
and spelled out) that focus largely on the perceived structural
needs of the names community or by assuming that we all agree
that there are "long overdue reforms" without you having
identified the specific, real, problem you think needs solving.

Again, if we were talking about ICANN having accountability and
bloat (budgetary and otherwise) problems, I would almost
certainly agree and suspect our examples of abuses would be
complementary.  In a more perfect world, the combination of
those problems and the sequencing of other events never would
have allowed IANA to be turned into a policy leverage point and
we would have sorted out the transparency and accountability
issues --including seeing whatever mechanisms were instituted
work successfully for a while -- before anyone had to start
discussing changes to IANA or removal of the US Government from
the presumed role of guarantor that ICANN would keep whatever
agreements it made.  It is not a perfect world and things didn't
work out that way, but I don't see that as justifying
structural/ organizational changes into the transition process
in the absence of clear identification of the problems that are
proposed to be solved and demonstration of why they are real.

best regards,
    john