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

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

--On Monday, May 18, 2015 10:04 +0200 Olaf Kolkman
<[e-mail]> wrote:

> On 15 May 2015, at 18:54, John C Klensin wrote:
> 
>> 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
> 
> Working from the thesis that what is confusing to me might be
> confusing to others. I am going to ask for clarification.

I think I agree with John Curran's formulation, but your mental
model does not seem to me to be more clear than the above and
John's seems to leave out a critical issue.  See below.

> My mental model of the setup that is being discussed here
> (that is, if I were to determine the current consensus):
> 
> 
> ```
> Mental model 1
> 
> IETF -> ICANN [-> IANA blackbox ] 
> NRO  -> ICANN [—> IANA blackbox ]
> Names Community -> PTI 
> ```
> 
> Where the _IANA blackbox_  and _PTI_ deliver the registry
> publication and maintenance functions. The reason why I
> picture an IANA blackbox is because the SLA is with ICANN and
> how the service is being subcontracted is a detail that the
> IETF and NRO would not particularly care about as long as the
> SLA is honored.

At least for the IETF piece of the puzzle, I don't think that is
correct.  I don't remember how explicit the current SLA draft is
about it, but the IETF-IANA relationship assumes a certain level
of staff experience and direct contact that is very different
from "black box".  That is in part because the current model
(see my response to Milton from which you quote) involves an
IANA evaluation process for establishing new registries and, in
may cases, for new values.  They don't get to say "no", but they
are expected to check things and make sure the instructions and
relationships are clear and consistent (and provide feedback if
they are not).

That in inconsistent with "black box" because, from the IETF's
standpoint as I understand it, ICANN has to take responsibility
for maintaining the particular skills needed to do those things
and do them smoothly and efficiently.  If an intermediate
management structure is introduced and it is responsible for
qualifying, selecting, and managing IANA staff, then that direct
relationship is broken.  More specifically, were something to go
wrong, IETF would need to remonstrate and negotiate with ICANN
and then ICANN would need to decide whether (and how
aggressively) to negotiate with PTI (which is probably a
misnomer, see below).  If PTI were independent enough to satisfy
whatever needs for separation from ICANN that that names
community thinks are needed, then ICANN's ability to negotiate
might be fairly weak (and, given that senior ICANN executives
regularly forget that there even are protocol registries, their
motivation possibly low).

Now, if PTI is really an oversight function that works out
agreements with ICANN for performance of the (operational) IANA
function (let's call that "IANA Names Oversight Board" (INOB) to
reduce confusion) then the relationships become:

  IETF -> IAB/IAOC -> ICANN -> IANA-operational-function
  RIRs -> NRO (?) -> ICANN -> IANA-operational-function
  ICANN Names Community -> INOB -> ICANN ->
IANA-operational-function

Completely parallel structure, and how INOB is constituted and
structured is a names community problem alone.

On the other hand, if the intent is that PTI is really an
organization that, among other things, selects and supervises
IANA operational stuff, then we have a picture closer to the one
John Curran outlined.  The IETF and RIR lines stay essentially
the same but the Names Community one looks more like 

  ICANN Names Community -> ICANN -> PTI-Names and
	  IANA-operational-function

(The term "PTI-Names" is used to clarify that this is not the
full IANA function but the domain names-related part(s).)

If the IETF (and presumably the number registries) insist on a
direct relationship with an organization that is clearly
accountable for how the relevant IANA operational functions are
carried out and by whom and the names community conditions for
PTI-Names are that it operate as a largely-independent affiliate
with no staff overlap with anyone directly employed by ICANN or
working on activities that are not assigned by PTI-Names, then
we've just split IANA into two (or three) separate groups and
functions.

Independent of the various historical and philosophical issues
associated with that, the split is part of what causes my
concerns about increased costs and, for that set of models,
reduced accountability in practice.

> Depending on how ICANN sub contracts the IANA services the
> _IANA Blackbox_ could look in fact be the _PTI_, with the IANA
> department being a one-to-one mapping to the PTI. And the then
> looks like:
> 
> ```
> Mental Model 1 - implementation 
> 
> IETF -> ICANN [-> PTI ] 
> NRO  -> ICANN [—> PTI ]
> Names Community -> PTI 
> ```
> 
> Where PTI == the IANA department.

I think that works iff "the IANA department" really is a
department, rather than a (mostly) independently-operated and
overseen affiliate/ subsidiary.  To the extent to which the
latter is a CWG goal, I don't think that picture works.

>...
> So here is my clarification question: Am I correct in my
> understanding that my mental model 1 aligns with where most
> people on this list are going, and Milton, is my mental model
> 2 a reasonable representation of your thoughts?

Milton can, and presumably will, speak for himself, but my view
is that, for the IETF community at least, the IANA protocol
function has not been a "black box" since 1998 [1].  There are
named individuals, with specific skills, clustering together to
do a very specific set of jobs, and we know what the
accountability mechanisms are and, more important, how to
address any failures.  On similar dimensions, even for the Names
Community -> PTI relationship, some of those linkages are
unknown because they are identified in the CWG draft as to be
determined later.

    john

[1] Arguably, pre-ICANN IANA was more of a black box --and its
internal operations and decision-making less transparent-- than
the IANA functions are today.  That is in spite of the fact that
the pre-ICANN IANA actually had far or discretionary authority
to make decisions.  On the other hand, the community knew
exactly who to hold accountable if something went wrong and his
agenda was both clear and trusted.  The clarity part (at least)
contrasts with the many, sometimes conflicting, agendas that
appear to drive ICANN.