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

[Jefsey <[e-mail]>]

Dear John,

After such a positions of yours, compared with the 
<http://www.ietf.org/iana.html>http://www.ietf.org/iana.html clarity, 
you may understand why "ICANN" may mean "Insured Confused Confusion 
in Administrating the Net" to affinity-group non-Members like me.

The first thing would be for the IAB to document why there is a need 
of an ICANN at all and why there is a need of a single one. I mean, 
except for the US/WEF strategy. Why is this still 
undefined/changing/transitioning function so particular that in all 
of the communications world it should be the only one not to be 
mutually regulated by competition. Then, if it MUST technically be a 
monopoly, why should it not be democratically regulated by the UN 
and, therefore, by the ITU along the International Telecommunication 
Regulations (ITRs)?

All of this seems to be a case where:
- there are the names, protocols, and addresses communities. They are 
doing well (may be missing a user documentation one?).
- there is the ICANN imposed but undefined concept: how the hell are 
we going to insert it? The Joe Sims' Contracts Network.

This does not sound reasonable to me. Unless the need is proven and 
documented. Why has no one written an RFC on "The single ICANN 
architectural necessity" yet?

Cheers,
jfc

At 16:43 18/05/2015, John C Klensin wrote:
>Content-Transfer-Encoding: base64Content-Disposition: inline
>
>--On Monday, May 18, 2015 10:04 +0200 Olaf Kolkman
><[e-mail]> wrote:
>
>ۈMHX^HŒMK]NM›ÚˆÀ Klensin wrote:
> >
> >š\œÝو[[™\Ș\ˆ\ÈHØ[ˆ@ll, if we ended up with the
> >QUˆ[™Û܈'TœËÓ""È]š[€g agreements about relevant IANA
> >> functions with ICANN and the names community having an
> >YܙY[Y[Ú]H@ for IANA functions that are relevant to
>ˆ[KZ]\ˆwe end up splitting IANA into two (or three)
> >> separate organizations or we end up with a picture that looks
>ˆike:
>ˆˆQUˆOˆPÐS"ˆOˆPSH\\Y[ˆ""ÈB"0ANN 
>-PSH\\Y[ˆ˜[Y\ÈÛÛ[][š]HBD'Óâ"4àN -> 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.
>
>^HY[@l model of the setup that is being discussed here
>
>] is, if I were to determine the current consensus):
> >
> >
> > ```
> > Mental model 1
> >
> > IETF -PÐS"ˆËOˆPSH›XÚÀbox ]
> > NRO  -> ICANN [—> IANA blackbox ]
> > Names Community -> PTI
>‚ ]¡•É"Ñ¡"}%9‰±…­‰½á|€…¹|PTI_ deliver the registry
>X›XØ][ۈ[™XZ[[˜[˜ÙH€unctions. 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 (?) -PÐS"ˆB"NA-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
>ÒPSH›XÚ؛ÞÈÛÝ[ÛÚÈ[ˆ˜XÝbe the _PTI_, with the IANA
> > department being a one-to-one mapping to the PTI. And the then
> > looks like:
>‚`
>Y[[[Ù[HH[\[Y[][ۈˆˆQUˆOˆPÐS"ˆÀ-> PTI ]
> > NRO  -> ICANN [—> PTI ]
>˜[Y\ÈÛÛ[][š]H@> 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
>[™\œÝ[™[™È]^HY[[[Ù[H[YۜÈwith where most
> > people on this list are going, and Milton, is my mental model
>ˆH™X\ÛۘX›H™\™\Ù[][ۈـ your thoughts‚"Z[ۈØ[‹[™™\Ý[XX›HÚ[ÜXZȀor 
>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.
>
>_______________________________________________
>Ianaplan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ianaplan

At 16:57 18/05/2015, John C Klensin wrote:


>--On Monday, May 18, 2015 14:08 +0000 John Curran
><[e-mail]> wrote:
>
> >>          "So Mental Model 1 and 2 could co-exist, as long as
> >> ICANN has PTI perform the protocol and number registries work
> >> on ICANN's behalf."
>
> >   i.e. an internal subcontracting from ICANN to PRI versus
> > agreement _assignment_ from   ICANN to PTI.   A internal
> > subcontracting arrangement is unlikely to be material for the
> > IETF   and the RIRs, whereas an agreement assignment is
> > visible, has some significant implications,   and would
> > require consent of the parties.
>
>Yes.  See the response I just sent to Olaf, but it seems to me
>that a "PTI" as a subcontracting arrangement to (more or less)
>an internal department is inconsistent with the (apparent) CWG
>of separation and independence and, as you have pointed out a
>separately-managed and accountable PTI that operates as a
>mostly-independent affiliate or subsidary of ICANN would not be
>plausible without IETF and address community consent and that
>there are reasons why it might not be in the interest of those
>bodies to provide that consent.
>
>Assuming that consent will not be lightly or quickly given, the
>question for me becomes whether the independent-affiliate
>version of the PTI concept is valuable enough to the Names
>community to justify splitting up the IANA function.  And, if it
>is, whether the result is a sufficiently consistent and coherent
>proposals to meet NTIA's transition proposal requirements.
>
>best,
>    john
>
>_______________________________________________
>Ianaplan mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/ianaplan