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

From: Eliot Lear <[email-masked]>
Date: Mon, 11 May 2015 20:42:17 +0200

Hi everyone,

I'm writing this with an eye toward a conversation that perhaps the IAB
and IAOC might find useful, as they consider various activities relating
to the IANA transition.

Over the last week or so, I read through the CWG proposal for the naming
component of the IANA functions transition proposal.  That proposal can
be found at [1].  I'm posting some comments here strictly as relates to
the IETF relationship with ICANN, and not the rest of it, since that
discussion should occur elsewhere.

The basis of the naming community's proposal is to create a new entity
to take on the IANA functions, known as Post-Transition IANA (PTI)[2]. 
That entity would be a wholly owned subsidiary of ICANN, but have its
own management structure, including a customer service component, known
as the Customer Standing Committee.  All current IANA functions would be
transferred to the PTI under this proposal.  A multistakeholder IANA
Function Review  (IFR) process is created as well.  In a sense, the
proposal is vaguely reminiscent of our own arrangements.  In particular
it seems that the names community also wants to a customer relationship
with the IANA Functions Operator (IFO) and to have the choice to change
providers, should that ever become necessary.  There's a bunch of
mechanism proposed to reduce the likelihood of a change, including
escalation, a separation review, etc., but at the end of the day the
choice would be the naming community's, just as the IAB has had the
choice to continue the protocol parameters arrangement.

How does this affect the IETF? 

First, if all functions are meant to be transferred to the PTI, it seems
that the IAB would have to agree to an assignment, per the terms of
RFC-2860.[2]  Second, since for the first time the naming community
would have a choice in whether they wish to change IFO, we have to ask
the question, “What if they did?”  What would happen to the PTI?  What,
in particular, are the funding implications?  It has always been
possible for ICANN or the IAB to terminate the arrangement.  If that
happened, however, the IAB and IAOC would have to work with ISOC to
determine a funding source for a new IFO for protocol parameters. 

It's worth noting that NRO Executive Council has stated that they wish
to retain a direct relationship with ICANN, and NOT the PTI[4].  The IAB
could do the same, but then it seems to me that the value of the PTI
itself is diminished.  And so that brings us back to the cardinal
question: what's right for the Internet?  Here I understand that
different people will have varying views.

Having the burden of funding shift to another source can itself be a
source of instability.  The CWG proposal contains the FY15 budget costs
for the IANA function.  That total is $6.3 million[6], but includes
indirect and shared costs as well.  What isn't in those costs is an
allocation across functions.  At the very least we should have that
information.  Preferably we should have those costs separately funded,
to the extent possible.  This would provide the naming community all the
freedom they want, and us all the freedom we want, without budgetary risk.

Having written that last line, I feel the need to once again point out
what we said in our response, that we are satisfied with the performance
of ICANN as IFO, and have been for quite some time, and that all of this
is still contingency planning.[5]

And so questions:

  * Under this new arrangement, does it make sense to continue the
    relationship with ICANN as it stood before or does it make sense to
    go directly to PTI?
  * If the arrangement is with PTI, should we seek a budgetary
    separation, and what would be the complexities of that?

I think there may be other questions for the CWG proposal, but to me
these are the big questions.

Eliot
[1]
https://www.icann.org/en/system/files/files/cwg-stewardship-draft-proposal-with-annexes-22apr15-en.pdf
[2] See III.A bullet 1.
[3] RFC 2860
[4] Message from Axel Pawlik to [email-masked] on 10 May 2015,
"Numbers community proposal contact points with CWG’s Draft IANA".
[5] draft-ietf-ianaplan-icg-response.
[6] See Annex P of the CWG draft.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 May 2015 08:26:12 +1200

I think it's simple enough. If the proposed PTI is a wholly owned
subsidiary of ICANN, the overarching IETF agreement still needs to be
with ICANN. Obviously operational additions such as the SOW and SLA
could be with the subsidiary.

(This of course shows why the PTI is a pointless idea, but that isn't
our discussion here.)

Regards
   Brian

On 12/05/2015 06:42, Eliot Lear wrote:
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan
>

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 11 May 2015 16:34:48 -0400

On Mon, May 11, 2015 at 08:42:17PM +0200, Eliot Lear wrote:
> itself is diminished.

Why?  The names community presumably wants this because it offers some
mechanism to them (in this case a way to break the policy from
implementation, if need be).  It needn't have anything to do with us.

> information.

But what if we can't get it?  The breakout that we got from ICANN, it
seemed to me inside the CWG, was itself rather hard to get.
Apparently ICANN doesn't account things this way.

>     separation, and what would be the complexities of that?

If you need ot answer question 2 in order to answer question 1, then
it seems obbvious to me that if we want to get this done in a
reasonable time frame the answer to 1 is "leave it alone".

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 11 May 2015 22:52:04 -0700

Brian said:

"(This of course shows why the PTI is a pointless idea, but that isn't our
discussion here.)"

[BA] +1 to that!

Unless there is an intent to institute fees, PTI would appear to be a
subsidiary with no revenue and all costs.  Those costs would probably be
higher than the present arrangement, due to the fees required to form the
subsidiary, as well as the costs of operating the subsidiary (e.g.
additional accounting, legal, personnel, etc. expenses) So given that PTI
is going to cost someone (ICANN or the communities or both) something, it
needs to provide some definite benefit to compensate.  However, from what I
can see, there is none.

Typically wholly owned subsidiaries of a non-profit are created in
situations where the subsidiary is expected to generate a profit, not a
loss.  Since the subsidiary is wholly owned by ICANN, the financial results
can be consolidated, but consistently money-losing entities have a way of
garnering extra scrutiny from taxing authorities (and from the executives
and board members of the parent company).

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 12 May 2015 06:32:38 +0000

From: Ianaplan [mailto:[email-masked]] On Behalf Of Eliot Lear

In a sense, the proposal is vaguely reminiscent of our own arrangements.  In particular it seems that the names community also wants to a customer relationship with the IANA Functions Operator (IFO) and to have the choice to change providers, should that ever become necessary.

MM: That is correct. I hope this community understands the importance of doing that.

First, if all functions are meant to be transferred to the PTI, it seems that the IAB would have to agree to an assignment, per the terms of RFC-2860.[2]  Second, since for the first time the naming community would have a choice in whether they wish to change IFO, we have to ask the question, “What if they did?”  What would happen to the PTI?  What, in particular, are the funding implications?  It has always been possible for ICANN or the IAB to terminate the arrangement.  If that happened, however, the IAB and IAOC would have to work with ISOC to determine a funding source for a new IFO for protocol parameters.

MM: If I understand your comment, you are assuming that if the naming community abandons PTI for another IFO, then the IETF would too. This is not necessarily true. IETF could continue to rely on PTI for its own IANA functions even if it did not provide the naming functions if it wanted to. If that were the case, the total budget for PTI would probably to change, but it is not necessarily true that the ICANN affiliate would crease to want to perform the protocol functions as before. However, if PTI were performing badly enough that the names community wanted to leave it, then presumably the protocols people might have concerns, too. But if they did, they would still have to face the funding issues.

It's worth noting that NRO Executive Council has stated that they wish to retain a direct relationship with ICANN, and NOT the PTI[4].  The IAB could do the same, but then it seems to me that the value of the PTI itself is diminished.  And so that

MM: This was a mistake, in my opinion, but it was motivated by uncertainty as to the status of PTI. I would view it as a short-term arrangement that, as PTI matured, would change to a direct relationship. But even if it did not, it does not alter the great value of finally creating a clear separation between the names policy arrangements and the IANA functions. If NRO is short-sighted enough to want to remain in a direct relationship with ICANN, even after its recent treatment by ICANN legal, I suppose that is it’s right, but we shouldn’t allow it to undermine reform in the naming area.

Having the burden of funding shift to another source can itself be a source of instability.

MM: If you don’t choose to move IANA away from ICANN there is no need for a “funding shift.”
If you did choose to do so under RFC 2860 then there would be, and this would be true REGARDLESS of whether there was a PTI or not. So the logic of this comment escapes me.

  *   Under this new arrangement, does it make sense to continue the relationship with ICANN as it stood before or does it make sense to go directly to PTI?
MM: You should embrace the new arrangement and go directly to PTI. But I am sure ICANN will love it if you do not, as you will reinforce their sense that the IANA functions are something they own and should be considered a presumptive monopoly of theirs. And long term, that will not be a positive thing for any of the operational communities, if you consider the bargaining power

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 12 May 2015 06:42:42 +0000

someone (ICANN or the communities or both) something, it needs to provide some definite benefit to compensate.  However, from what I can see, there is none.

MM: A very short-sighted comment. One would think that recent events would have brought home to everyone paying attention the risks of conceiving of the IANA functions as a monopoly of ICANN bundled in with (and dwarfed by) the naming policy development organization. I suggest a quick review of RFC 7500.

Just as a general admonition, IETFers who think that everything about ICANN will be the same once the NTIA and the USG leave the scene are living in a dream world. So your apparent comfort with the status quo needs to be re-examined in the light of future changes – changes that are NOT hypothetical

Typically wholly owned subsidiaries of a non-profit are created in situations where the subsidiary is expected to generate a profit, not a loss.

MM: This observation is completely irrelevant. This is a nonprofit environment and the primary considerations are accountability not profit or loss.

  Since the subsidiary is wholly owned by ICANN, the financial results can be consolidated, but consistently money-losing entities have a way of garnering extra scrutiny from taxing authorities (and from the executives and board members of the parent company).

MM: ICANN is tax-exempt, and if it has a problem along those lines recently, it is the fact that its naming policy activities generate too much money, not its losses. IANA functions currently account for about 3.6% of its overall budget. In terms of transparency, efficiency and the rationality and accountability of the overall system, it is a very good thing for budgets to be separated out and clearer.

---

From: John Curran <[email-masked]>
Date: Tue, 12 May 2015 09:06:19 +0200

On May 11, 2015, at 8:42 PM, Eliot Lear <[email-masked]> wrote:
> ...
> First, if all functions are meant to be transferred to the PTI, it seems that the IAB would have to agree to an assignment, per the terms of RFC-2860.[2]

To be clear, the CWG does not state a firm position with respect to the
assignments of contracts from ICANN to PTI.   See footnote #5, on the
bottom of page 21, which reads -

                "In the case of any existing ICANN contracts, MoUs or other arrangements that relate to the IANA functions, they could be assigned to and assumed by PTI, replaced by new arrangements at the PTI level or remain at ICANN with a subcontract to PTI.”

It’s certainly worth discussing the possibility of doing an assignment (as
opposed to retaining it at the ICANN level), but either outcome appears
to be compatible with the CWG proposal.

/John

Disclaimer: my views alone.

---

From: Olaf Kolkman <[email-masked]>
Date: Tue, 12 May 2015 09:10:29 +0200

> could be with the subsidiary.

I am not there.

Looking at this from a perspective from separation of _policy_ and _implementation_ functions on could argue that the names community has chosen to make a clear separation of ICANN as the _policy_ body and the PTI as the _implementation_ body.

To me there is some logic for the IETF (as a _policy_ body) to contract with the PTI.

Obviously, there still will need to be coordination between the _policy_ bodies but that coordination needs to be there regardless of what the _implementation_ bodies are (yes that is plural, it reflects the current situation of having multiple organizations implementing parts of IANA).

I think it makes much more sense to have an SLA with the _implementation_ body (PTI) without another organization in the middle. There is an esthetic to that setup that I think bring transparency.

But I guess it depends a bit about what type of 'overarching IETF agreement' you are talking about, the cooperation with ICANN is not only about the IANA SLA.

—Olaf

- - -
Olaf Kolkman
Chief Internet Technology Officer
Internet Society
[email-masked]  www.internetsociety.org
LinkedIn: OlafKolkman, Twitter: @Kolkman
- - -

---

From: Jefsey <[email-masked]>
Date: Tue, 12 May 2015 11:43:41 +0200

Difficult for me to fully undestand what you mean here (probably 
language issue). What I observe is that there are several communities 
involved that consider they have a radical monopoloy that RFC 6852 
has conceptually terminated.

==> This is the crux of the whole issue, that Eliot is well raising 
(thanks)  (radical monopoly multistakeholderism vs collective 
empowerment omnistakeholderism : decentralized vs distributed intergovernance)

1. For those not familiar with Ivan Illitch: "By "radical monopoly" I 
mean the dominance of one type of product rather than the dominance 
of one brand. I speak about radical monopoly when one industrial 
production process exercises an exclusive control over the 
satisfaction of a pressing need, and excludes nonindustrial 
activities from competition." —Ivan Illich,

Until now, accountability of in this radical monopolistic system was 
embodied in the iana.arpa mechanism under NTIA supervision of ICANN. 
The transition is to transfer the empowerment of the concerned global 
monopolies through multistakeholderism. With Naming, Parameters, 
Addressing, Political, etc. "functionnal communities".

2. RFC 6852 opposes another vision as it considers "global 
communities" of standards' followers (I call the operational perspective VGNs):

"We embrace a modern paradigm for standards where the economics of 
global markets, fueled by technological advancements, drive global 
deployment of standards regardless of their formal status. In this 
paradigm standards support interoperability, foster global 
competition, are developed through an open participatory process, and 
are voluntarily adopted globally.  These voluntary standards serve as 
building blocks for products and services targeted at meeting the 
needs of the market and consumer, thereby driving innovation. 
Innovation in turn contributes to the creation of new markets and the 
growth and expansion of existing markets.

"Collective empowerment.  Commitment by affirming standards 
organizations and their participants to collective empowerment by 
striving for standards that:
* are chosen and defined based on technical merit, as judged by the 
contributed expertise of each participant;
* provide global interoperability, scalability, stability, and resiliency;
* enable global competition;
* serve as building blocks for further innovation; and
* contribute to the creation of global communities, benefiting 
humanity." (RFC 6852, by IEEE, IAB, IETF, ISOC, W3C).

This can be defined as "omnistakeholderism".]

3. The choice is to be made here, at IAB/ISOC/IG through my appeal, 
or by cybercompetition and conflicts

>implementation, if need be).  It needn't have anything to do with us.

Correct, except that what you call the "names community" is the 
"CLASS "IN"" community. This is the Internet (with capital I to 
describe the governed system, by opposition to the "internet" as the 
technology) BUG, ICANN wants to "Be Unllateraly Global". As long as 
the NTIA is providing an unique political supervision of the 
"Internet" radical monopoly, the BUG was a feature. Now the BUG is just a bug.

This is why, in order to understand how to fix that bug, I intend to 
test the "CLASS "FL"" for "Free/Libre" (in my mind "Free" stands for 
'free software', and LIBRE for "relationnels libres", i.e. 
openprotocol relationware). That test needs to respect the ICANN 
established constraints for such a testing (ICP/3) and avoid 
conflicting with the IETF Transition process (hence the 36 questions 
of my appeal the IESG was unable to answer). Hence also, my delay in 
addressing my appeal to the IAB, in order to permit this WG to 
consider the problem from the IETF affinity group point of viw, as 
Lear just did it.

I have no solution. I only have a problem you did not consider in 
your own terms yet.

>Apparently ICANN doesn't account things this way.

As an example, the LIBRE community will only consider ICANN as a 
source of added value - still to be precisely identified.

> >     relationship with ICANN as it stood before or does it make sense to

Good question. IMHO ICANN has shown the lead: you need to relate with 
PTI, LIBRE and other possible CLASSes "Ledgers" (registry groups) on 
an equal footing basis, but in understanding that budgets and CLASS 
organization may/will drastically differ. This is something I intend 
to understand/experiment through the "FL" CLASS experimentation as 
soon as IAB or ISOC have clarified this liaison between the IETF ans 
a general Ledger (as ICANN), because aside of the CLASS's root, there 
will probably be the need for specific parameters for the CLASS and 
for the relational protocols having required a dedicated CLASS perspective.

>reasonable time frame the answer to 1 is "leave it alone".

This is what I do not fully grasp tthe meaning.

jfc

Temporary principles
    * Freedom 0: The freedom to use the protocol for any purpose.
    * Freedom 1: The freedom to study how the protocol operates, and 
change it to make it do what you wish.
    * Freedom 2: The freedom to document the protocol in ways that 
can help your neighbor(s) through the catenet.
    * Freedom 3: The freedom to improve the protocol, and release 
your improvements to the public, so that the whole community benefits.
    * Freedom 4: The freedom for all to interoperate, cooperate and 
coopete through the protocol whatever the Free or not software being used.

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 12 May 2015 13:38:40 +0200

On Tue, May 12, 2015 at 7:52 AM, Bernard Aboba <[email-masked]> wrote:
> additional accounting, legal, personnel, etc. expenses) So given that PTI is
> going to cost someone (ICANN or the communities or both) something, it needs
> to provide some definite benefit to compensate.  However, from what I can
> see, there is none.

I don't see PTI as a pointless idea, what I see as a pointless idea is
to have it
as a subsidiary of ICANN. If we're going to go down that road, why not go all
the way and make it a separate entity that stands on it's own - ICANN's
role would be to fund it for now. At some later stage other could fund it.

...  on the other hand, done right it would separate the different roles ICANN
have in this world, make it clearer that IANA is just a function that ICANN
host. However, there are other and better ways to do that to.

-- 

Roger Jorgensen           | ROJO9-RIPE
[email-masked]          | - IPv6 is The Key!
http://www.jorgensen.no   | [email-masked]

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 12 May 2015 11:56:31 +0000

> -----Original Message-----
> I don't see PTI as a pointless idea, what I see as a pointless idea is to have it

Some of us pushed very hard to do that but ICANN and its supporters pushed back and others are afraid of the "instability" allegedly caused by a free-standing new entity. The separate legal affiliate was a middle ground. As a step in the right direction, it is an acceptable compromise imho.

---

From: Jefsey <[email-masked]>
Date: Tue, 12 May 2015 13:30:51 +0200

May be 
https://ccdcoe.org/us-announces-intention-hand-over-control-over-dns.html 
is an interesting NATO point of view.
jfc

---

From: John Curran <[email-masked]>
Date: Tue, 12 May 2015 16:07:43 +0200

> host. However, there are other and better ways to do that to.

Indeed - the more obvious approach would have been to move "the structure representing 
the DNS community" external to ICANN (and then have that contract with ICANN for IANA 
naming services), but as noted by Milton, such an approach quickly raises concerns about
risk of capture and stability of the resulting entities.  

It should be noted that there is likely some benefit received from Post-Transition-IANA (PTI)
approach, in that it helps clarify roles and processes which are presently commingled in manner 
which interferes with assessment of accountability to the names community.  It also provides 
some benefit with respect to the identification of IANA costs.

The present challenge with PTI is that its mission, governance model, and legal structure 
are all still to be determined[1][2][3], and as such, it is unclear if one can responsibly contract 
with it for the delivery of IANA services.  Even though existing IANA staff and knowledge would 
transfer to the PTI and presumably function as it does today, the new entity will have its own 
governing Board (which could simply be an ICANN-designated or could be some other form
with various community representation involved) and mission, and either of these could have
impact on the delivery of IANA services.  For example, PTI’s governing Board could establish 
mechanisms that go beyond IANA policy implementation but appear otherwise reasonable 
(e.g. collection of suggestions for IANA policy improvement or quality assessment of new 
IANA policy as received); without knowing the governance structure or mission, it is not at
all apparent how we'd all collectively keep PTI focusing “on course” as the IANA operator
under such circumstances, aside from the obviously destabilizing option of terminating the
relation and contracting with another party for IANA operations.  

In addition, PTI has a funding dependency on ICANN and a likely dependency on the use 
of other ICANN cost centers for fulfillment of its mission.  This doesn’t create any risk if PTI 
is effectively governed by ICANN, but could prove ‘interesting’ if PTI has independent
governance structure and undertakes a direction and/or decisions which ICANN does not 
support.  If ICANN has an obligation to fulfill certain the contractual responsibilities for IANA 
services, then it is unlikely to that any misalignment would result in PTI’s inability to deliver 
on those duties, but it is less clear if that’s the case should the performance obligations be 
held only by PTI.

The IETF should consider all of the above, and the circumstances of its relationship with
ICANN via the existing MOU, and determine what is the best manner to serve the protocol
parameter community.  It might also be helpful to provide guidance on some of the open 
aspects of PTI, in order to shape it in a direction which best meets the community’s needs.

May you live in interesting times...
/John

[1] FAQ on External Legal Counsel Memorandum Proposed Post-Transition Structure - https://www.icann.org/en/system/files/files/legal-counsel-memo-post-transition-structure-faq-08may15-en.pdf <https://www.icann.org/en/system/files/files/legal-counsel-memo-post-transition-structure-faq-08may15-en.pdf>
[2]  "Summary of Legal Structure”, Sidley Austin LLP (CWG external counsel), 3 May 2015 - http://mm.icann.org/pipermail/cwg-stewardship/2015-May/003062.html <http://mm.icann.org/pipermail/cwg-stewardship/2015-May/003062.html>
[3] "PTI: Board Duties and Subsidiary Costs”, Sidley Austin LLP (CWG external counsel), 28 April 2015 - http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150505/8f61bbdd/PTI-0001.PDF <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150505/8f61bbdd/PTI-0001.PDF>

---

From: John Curran <[email-masked]>
Date: Tue, 12 May 2015 17:12:34 +0200

> [2]  "Summary of Legal Structure”, Sidley Austin LLP (CWG external counsel), 3 May 2015 - http://mm.icann.org/pipermail/cwg-stewardship/2015-May/003062.html <http://mm.icann.org/pipermail/cwg-stewa…
The above URL points to an email with the document; the direct link to the pdf is actually this - 
<http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150505/8f61bbdd/PTI-0001.PDF <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150505/8f61bbdd/PTI-0001.PDF>>

/John

---

From: Seun Ojedeji <[email-masked]>
Date: Tue, 12 May 2015 17:59:48 +0100

++1 to John on his entire write-up

Thanks

sent from Google nexus 4
kindly excuse brevity and typos.
On 12 May 2015 15:08, "John Curran" <[email-masked]> wrote:

> [1] FAQ on External Legal Counsel Memorandum Proposed Post-Transition
> Structure -
> https://www.icann.org/en/system/files/files/legal-counsel-memo-post-transition-structure-faq-08may15-en.pdf
> [2]  "Summary of Legal Structure”, Sidley Austin LLP (CWG external
> counsel), 3 May 2015 -
> http://mm.icann.org/pipermail/cwg-stewardship/2015-May/003062.html
> [3] "PTI: Board Duties and Subsidiary Costs”, Sidley Austin LLP (CWG
> external counsel), 28 April 2015 -
> http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150505/8f61bbdd/PTI-0001.PDF
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 12 May 2015 15:08:09 -0400

--On Tuesday, May 12, 2015 11:56 +0000 Milton L Mueller
<[email-masked]> wrote:

>> I don't see PTI as a pointless idea, what I see as a
>> pointless idea is to have it as a subsidiary of ICANN. If
>> we're going to go down that road, why not go all
> 
> Some of us pushed very hard to do that but ICANN and its
> supporters pushed back and others are afraid of the
> "instability" allegedly caused by a free-standing new entity.
> The separate legal affiliate was a middle ground. As a step in
> the right direction, it is an acceptable compromise imho. 

Milton,

I've having trouble understanding it as either a compromise or a
step in some right direction.    Unless a substantial endowment
were somehow irrevocably assigned to it, it would still be
dependent on ICANN for budget and it could not be spun off
without permission from the ICANN Board 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).  

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.

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

As John Curran indirectly points out, how severe the actual risk
is depends on details that have still not been sorted out.  But
I believe that the issues 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.

So, am I missing something and, if so, what?

     john

---

From: JFC Morfin <[email-masked]>
Date: Wed, 13 May 2015 01:28:19 +0200

Dear John,

may be will you remember Paul Towmey at ICANN Luxembourg, annoucing in
front of Vint Cerf the creation of a DNSSEC dedicated affiliate of
ICANN. I would not be surprised if PTI was to be an ICANN replacement
in an NTIA replacement by ICANN scenario. This would make a lot of
sense in a decentralised intergovernance with ICANN at the core,
oversighting the "Internet". With equivalent relational links/beams
with PTI, NRO, IETF, W3C and further-on Versign, Rosettanet, etc.

ICANN's best interest is that the largest numbers of bilateral
relations are signed among the members (including SOs, GAC, etc.) of
its RFC 6852 global community (its periphery). The tasks defined in
these agreement will progressively stabilize as "edge functors" rather
than entities. So, if one entity is denied, it can be replaced by a
newcomer with the same/equivalent duties and procedures, without
affecting the stability of the whole organization network.

IMHO they follow a Tapscott, St-Amour & Caswell NTIA ordered GSN plan
(cf. http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/).
An NSA-compatible (for protection) networked enhanced cooperation
system for the Internet, with a multistakeholderist governance (that
will best disseminate the I*Core positions). In such schemes the
networked governance is perceived as the source of stability and
dynamism. The more connected people, the more bainstorming, the more
consensuses.

This seems a resillient approach. Is it able to nurture and welcome
innovation, I do not know (I never saw spontaneous generation).
However it seems realistic enough. Except the BUG - being unilaterally
global: the ICANN scheme has not foreseen hooks for complementary,
alternative, compettive approaches, technologis, and/or catenet uses.
This is what is to be tested.

jfc

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 May 2015 07:57:58 +0200

Hi Milton (and everyone),

I apologize for the delay in responding.

On 5/12/15 8:32 AM, Milton L Mueller wrote:
>
>  
>
>  
>
> *From:*Ianaplan [mailto:[email-masked]] *On Behalf Of
> *Eliot Lear
>
> In a sense, the proposal is vaguely reminiscent of our own
> arrangements.  In particular it seems that the names community also
> wants to a customer relationship with the IANA Functions Operator
> (IFO) and to have the choice to change providers, should that ever
> become necessary. 
>
>  
>
> First, if all functions are meant to be transferred to the PTI, it
> seems that the IAB would have to agree to an assignment, per the terms
> of RFC-2860.[2]  Second, since for the first time the naming community
> the question, “What if they did?”  What would happen to the PTI? 
> What, in particular, are the funding implications?  It has always been
> MM: If I understand your comment, you are assuming that if the naming
> community abandons PTI for another IFO, then the IETF would too.
>

Quite the opposite.  What would happen if the naming community chose to
separate from the PTI, but the IETF *didn't* want to?  What is the
incentive for the parent organization to continue to fund the PTI?  That
is a new risk for this community.

> This is not necessarily true. IETF could continue to rely on PTI for
> its own IANA functions even if it did not provide the naming functions
> if it wanted to. If that were the case, the total budget for PTI would
> probably to change, but it is not necessarily true that the ICANN
> affiliate would crease to want to perform the protocol functions as
> before. However, if PTI were performing badly enough that the names
> community wanted to leave it, then presumably the protocols people
> might have concerns, too. But if they did, they would still have to
> face the funding issues.
>
>
> to retain a direct relationship with ICANN, and NOT the PTI[4].  The
> IAB could do the same, but then it seems to me that the value of the
> PTI itself is diminished.  And so that
>
>  
>
> MM: This was a mistake, in my opinion, but it was motivated by
> uncertainty as to the status of PTI. I would view it as a short-term
> arrangement that, as PTI matured, would change to a direct relationship.
>

I think that's possible here as well, but it will depend on this
community's belief that the *long term *stability of the function can be
maintained, particularly in the case where one of the other functions
(like names) wants to go their own way.

> But even if it did not, it does not alter the great value of finally
> creating a clear separation between the names policy arrangements and
> the IANA functions. If NRO is short-sighted enough to want to remain
> in a direct relationship with ICANN, even after its recent treatment
> by ICANN legal, I suppose that is it’s right, but we shouldn’t allow
> it to undermine reform in the naming area.
>
>  
>

Sure, so long as it doesn't destabilize long term stability of the other
functions.

> source of instability.
> If you did choose to do so under RFC 2860 then there would be, and
> this would be true REGARDLESS of whether there was a PTI or not. So
> the logic of this comment escapes me.
>

It's all about choice.  The naming community will have new choices. 
That's good for them.  But it requires this community to ask the
question, “what happens to us if they avail themselves of that choice?” 
That was my comment.

>     relationship with ICANN as it stood before or does it make sense
>     to go directly to PTI?
>
> MM: You should embrace the new arrangement and go directly to PTI. But
> I am sure ICANN will love it if you do not, as you will reinforce
> their sense that the IANA functions are something they own and should
> be considered a presumptive monopoly of theirs. And long term, that
> will not be a positive thing for any of the operational communities,
> if you consider the bargaining power
>

You wrote elsewhere that the PTI was a compromise.  I see that John has
responded.  I would simply add that not all of this needs to happen at
once, but that for it to happen in the future, the structure should be
such that there is an incentive for this community to make the change. 
The only incentive to me that matters is the long term stability of the
function.

Eliot

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 May 2015 08:05:44 +0200

Hi Andrew,

> implementation, if need be).  It needn't have anything to do with us.

It does, of course.  At the very least the terms of RFC 2860 needs to be
considered as part of this. Beyond that, it seems like the vision here
is the correct one, that policy is separated from execution, but the
financing of it in particular bothers me (see my note to Milton).
> Apparently ICANN doesn't account things this way.

If you don't ask, you don't get.  I have heard various people over the
years talk about this in rough terms.  Now the names proposal has at
least something.  The simple question to ask is this: how much of that
$6 million is used for protocol parameters?  It's not an unreasonable
question.

> reasonable time frame the answer to 1 is "leave it alone".

At the moment I would tend to agree, but would still want to ask the
above question.   I'd also suggest that feedback be given that if the
PTI is intended to take on more than just names over time, some amount
of thought be given to how the concerns of long term stability of the
other functions should be addressed.

Eliot

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 13 May 2015 08:27:20 +0000

MM: Just a correction. That is not what I said. John Curran is talking about moving what is now the GNSO, ccNSO, ALAC and GAC outside of ICANN (“the structure representing the DNS community”) into some kind of large new entity that makes policy, and leaving IANA inside ICANN corporate. That would also establish a clear separation between policy and implementation, but if you know anything about the political and organizational complexity and dynamics of the ICANN policy process you cannot fail to realize that it is simply not feasible to make such a change. It would be massively destabilizing politically, financially, organizationally. (GNSO alone consists of 4 different stakeholder groups and 5 constituencies; supporting it probably accounts for half of ICANN’s large budget. GNSO, GAC, ALAC, in some sense all compete for power and influence in the ICANN policy process, and the form of separation John refers to would unbalance existing equilibria and force them to renegotiate their relationships. This would open quite a can of worms).

What I proposed and discussed was a much simpler alternative: take IANA out of ICANN rather than the other way around. IANA is small and its functions less political. It is easy to divest it structurally.

Further, while I acknowledged concerns about capture and stability of a separated IANA I did not say those concerns were valid. In fact, they are not. If we are talking about pulling IANA out of ICANN, talk of capture is not to be taken seriously. If the IFO for names is a mere contractor of ICANN, and does not even directly publish the root zone, it controls nothing and there is no point to “capture” it. If for some reason it was, a “captured” IFO could be fired and disposed of.

Re: “stability” one could I suppose worry about the standard hiccups associated with any form of organizational change, but since we are taking the existing IANA department as the basis, it’s hard to make a rational case that this is some big destabilizing change.

The main opposition to separating out IANA has come from ICANN itself, for reasons one can conjecture about, but that is outside the scope of our discussion here.

So unless the community comes back with a clear message of “separate IANA completely” we are stuck with the middle ground solution. And there would still be strong opposition from certain quarters to full separation. And a completely internal model can certainly be ruled out at this stage -- it is no accident that the CWG has twice proposed a solution involving some form of externalization. So let me emphasize that unless this basic approach is confirmed in this round of comments, there will be at least another 6 months delay in the CWG proposal as it would be forced to renew the search for a model that can gain consensus.

I believe such a delay will put the completion of the entire transition at risk. Outside the US, it will be interpreted as a failure of the MS model to deliver, and inside the US, it will give opponents of the transition a chance to renew the ICANN contract for a year and in the next year play all kinds of other games during an election year to impede implementation.

Bottom line: how serious are your little gripes and cavils about how CWG has chosen to constitute PTI? Frankly I haven’t heard anything serious here. Are you focusing on the big picture, or are you entertaining the illusion that this transition can happen without any uncertainty and that one stakeholder can specify and get exactly what it wants?

Of course, if your intention is to kill the transition altogether – and there are people who want to do that – then keep picking away at these things.

--MM

---

From: Roger Jørgensen <[email-masked]>
Date: Wed, 13 May 2015 11:08:02 +0200

(sorry for top posting)

Milton,

In general - I don't really appreciate the tone of this email from
you, it read too much
like you have to take this or bad things will happen.

My personal view is that this PTI construct don't add anything else
than complexity.
I'll repeat that comment over in RIR land to, just working on a better
formulation.

If the goal - clear and stated goal from the names side of things was
to separate
policy from operations that make sense, but call it something else then.

--- Roger J ---

On Wed, May 13, 2015 at 10:27 AM, Milton L Mueller <[email-masked]> wrote:
> MM: Just a correction. That is not what I said. John Curran is talking about
> moving what is now the GNSO, ccNSO, ALAC and GAC outside of ICANN (“the
> structure representing the DNS community”) into some kind of large new
> entity that makes policy, and leaving IANA inside ICANN corporate. That
> would also establish a clear separation between policy and implementation,
> but if you know anything about the political and organizational complexity
> and dynamics of the ICANN policy process you cannot fail to realize that it
> is simply not feasible to make such a change. It would be massively
> destabilizing politically, financially, organizationally. (GNSO alone
> consists of 4 different stakeholder groups and 5 constituencies; supporting
> it probably accounts for half of ICANN’s large budget. GNSO, GAC, ALAC, in
> some sense all compete for power and influence in the ICANN policy process,
> and the form of separation John refers to would unbalance existing
> equilibria and force them to renegotiate their relationships. This would
> open quite a can of worms).
>
>
>
> What I proposed and discussed was a much simpler alternative: take IANA out
> of ICANN rather than the other way around. IANA is small and its functions
> less political. It is easy to divest it structurally.
>
>
>
> Further, while I acknowledged concerns about capture and stability of a
> separated IANA I did not say those concerns were valid. In fact, they are
> not. If we are talking about pulling IANA out of ICANN, talk of capture is
> not to be taken seriously. If the IFO for names is a mere contractor of
> ICANN, and does not even directly publish the root zone, it controls nothing
> and there is no point to “capture” it. If for some reason it was, a
> “captured” IFO could be fired and disposed of.
>
>
>
> Re: “stability” one could I suppose worry about the standard hiccups
> associated with any form of organizational change, but since we are taking
> the existing IANA department as the basis, it’s hard to make a rational case
> that this is some big destabilizing change.
>
>
>
> The main opposition to separating out IANA has come from ICANN itself, for
> reasons one can conjecture about, but that is outside the scope of our
> discussion here.
>
>
>
> So unless the community comes back with a clear message of “separate IANA
> completely” we are stuck with the middle ground solution. And there would
> still be strong opposition from certain quarters to full separation. And a
> completely internal model can certainly be ruled out at this stage -- it is
> no accident that the CWG has twice proposed a solution involving some form
> of externalization. So let me emphasize that unless this basic approach is
> confirmed in this round of comments, there will be at least another 6 months
> delay in the CWG proposal as it would be forced to renew the search for a
> model that can gain consensus.
>
>
>
> I believe such a delay will put the completion of the entire transition at
> risk. Outside the US, it will be interpreted as a failure of the MS model to
> deliver, and inside the US, it will give opponents of the transition a
> chance to renew the ICANN contract for a year and in the next year play all
> kinds of other games during an election year to impede implementation.
>
>
>
> Bottom line: how serious are your little gripes and cavils about how CWG has
> chosen to constitute PTI? Frankly I haven’t heard anything serious here. Are
> you focusing on the big picture, or are you entertaining the illusion that
> this transition can happen without any uncertainty and that one stakeholder
> can specify and get exactly what it wants?
>
>
>
> Of course, if your intention is to kill the transition altogether – and
> there are people who want to do that – then keep picking away at these
> things.
>
>
>
> --MM
>
>

--

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 13 May 2015 10:11:25 +0000

> In general - I don't really appreciate the tone of this email from you, it read
> too much like you have to take this or bad things will happen.

Sorry for that. Not my intent. My goal was simply to acquaint you with the real political and temporal constraints operating on this process. In other words, we are well beyond the point where one can quibble with a structural model without proposing a specific, feasible alternative that can actually gain support.

> My personal view is that this PTI construct don't add anything else than
> complexity.

So you support a completely separate, independent IANA, then? 
  Is that simpler? (hint: ask who would own it and how would it be funded?)
  Is it an option that can gain consensus? 

> If the goal - clear and stated goal from the names side of things was to
> separate policy from operations that make sense, but call it something else
> then.

That is definitely one of the main goals. Another is to enable a severable contractual relationship, which is what protocols already has and numbers has proposed. I am sorry, but I don't understand what "call it something else" means. Call _what_ something else? What does calling it something else accomplish?

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 13 May 2015 11:15:36 +0000

John Klensin's issues responded to below.

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

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

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

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

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

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.

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

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

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

--MM

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 May 2015 08:26:21 -0400

On Wed, May 13, 2015 at 08:05:44AM +0200, Eliot Lear wrote:
> considered as part of this.

Why?  Why should we care _at all_ how ICANN delivers the service to
us?

> Beyond that, it seems like the vision here

The financing is an issue no matter what we do, and as I've said
repeatedly I think the only sane thing to do is to keep our collective
mouth shut until this is over and then figure out how to put this on a
sane financial footing under our own control.  The financing of all of
this has been problematic at least since ICANN started printing money
by imposing its domain name registration fee on all under-contract
registrations: there's too much money sloshing around.  Now that Fadi
is dangling money (or bait, as Ted had it), I think we know how the
story ends no matter whether NTIA goes away or not.

> If you don't ask, you don't get.

My point is that the division is entirely arbitrary and I can only
believe that, if we ask, we'll get an answer that apportions all sorts
of costs to us, the expensive ones, as part of an argument that we
can't afford to part ways and therefore we have to give up the
termination clause or be branded as irresponsible.  In a negotiation,
don't ask questions for which you don't already know the answer,
especially if the other guy can tell you anything and you have no
means of confirming the claims.

Russ told me some time ago that the IAOC mocked up a cost of operating
the service ourselves according to what we thought it'd take, but I
haven't seen that mock up.  That seems more useful to me than stories
told to us in public by ICANN.  I'll see if I can get this.

> least something.

I won't say this on a public list, but honestly, I watched the names
proposal's numbers be generated and the most polite words I can give
to them are "comfortable fiction".

> other functions should be addressed.

As I've said now repeatedly, the long term stability of our function
can only reasonably be assured by us figuring out how to create its
real operation in house.  ICANN has, in the process of the CWG and
CCWG, revealed itself to be even more beset by bureaucratic thinking,
clerical rot, hobby-horse obsessions, unimaginative analyses, and
cut-rate Machiavellian management than I'd believed going in.  I think
it is a fine institution for managing an increasingly-irrelevant
resource (TLDs), but it is not an institution that is in good shape to
ensure the health of the Internet.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 13 May 2015 08:30:57 -0400

On Wed, May 13, 2015 at 08:26:20AM -0400, Andrew Sullivan wrote:
> I won't say this on a public list

Well, I am embarrassed and ashamed at my rant, and I want to apologise
for speaking intemperately.  That message was intended for Eliot and,
because he knows me well, I thought he would understand my exaggerated
phrases in my expression of frustration.  But it was an inconsiderate
set of things to say either privately or publicly, and I ought to know
better.  I am indeed frustrated with the CWG/CCWG efforts, but that is
no reason to have impugned the efforts or motives of those who worked
hard on that effort.

I'm sorry.

Best regards,

Andrew

-- 
Andrew Sullivan
[email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 13 May 2015 10:46:02 -0700

Eliot, thanks for kicking off this discussion.

Having followed the CWG process to some extent, I appreciate that the PTI proposal is the same sort of compromise that we arrive at now and again in the IETF -- one that leaves the interested parties all mildly dissatisfied. If the names community did not represent such a diversity of interests, I’m sure a cleaner proposal that more readily achieves various goals that people have for the naming functions and their accountability could have obtained consensus. But the reality is that the names community is diverse and that compromises are messy by their nature. I think it would be a more productive use of this list’s time to focus on the question of the implications of the CWG proposal for the IETF rather than re-litigate the debates that have already occurred within the CWG about all the aspects of the current proposal that may seem less than ideal depending on where one sits. This is particularly true for the “why not take names policy out of ICANN instead of taking IANA out” line of argument. The last 7 months of CWG discussions have me quite convinced that the current CWG proposal has a much better shot at obtaining broad consensus than either taking names policy out of ICANN or leaving both names policy and IANA as-is inside of ICANN. 

My personal view is that if the PTI is established, it would be preferable to keep the protocol parameters personnel, resources, and MOU at ICANN. Simply put, the current protocol parameters system works well. If it ain’t broke, don’t fix it.

I haven’t seen particularly strong arguments for why the protocol parameters personnel, resources, or MOU would need to move to the PTI if the PTI gets established for names. However, if a compelling argument were to be made, I don’t see major hurdles in moving the personnel or resources to the PTI. In other words, I don’t understand why it is proposed to move those things to the PTI, and I think moving them makes less sense than leaving them at ICANN proper, but I think the protocol parameters registries could probably continue to work just fine if the resources and personnel were moved based on some good argument for doing so.

I don’t see any advantages in moving the MOU even if the personnel and resources move. Since the PTI is proposed as a wholly owned subsidiary of ICANN, we can maintain our agreement with ICANN and they can subcontract the work out to their subsidiary if necessary. Again, no need to make extra changes to things that are working.

I think it’s valid to want to understand the budget for providing the protocol parameters registry services, but that is the case regardless of whether the PTI gets established or not. If the point is for the IETF to understand how much ICANN spends providing the services, that inquiry was as valid 15 years ago when the MOU was signed as it is now or after the transition. I’m not sure it tells us very much about how much we should be willing to pay a different operator in the future, but in any event I don’t think it helps to mix that inquiry with responses to the CWG proposal.

I don’t think it makes sense for the IETF to have a seat on the PTI board. The IAB can continue to exercise its oversight over the registry operator’s performance of the protocol parameters function, so the addition of the board seat is not necessary. The CWG also proposes that the performance of IANA be periodically reviewed post-transition and that the protocol parameter community be offered the opportunity to appoint liaisons to the team performing reviews. Considering that we already have our own performance review process, I don’t think this liaison is necessary either. In short, even if the protocol parameters resources and personnel were to move to the PTI, I think we should stick with our existing oversight and performance review processes, which work well.

Alissa

On May 11, 2015, at 11:42 AM, Eliot Lear <[email-masked]> wrote:

> Hi everyone,
> 
> I'm writing this with an eye toward a conversation that perhaps the IAB and IAOC might find useful, as they consider various activities relating to the IANA transition.
> 
> Over the last week or so, I read through the CWG proposal for the naming component of the IANA functions transition proposal.  That proposal can be found at [1].  I'm posting some comments here strictly as relates to the IETF relationship with ICANN, and not the rest of it, since that discussion should occur elsewhere.
> 
> The basis of the naming community's proposal is to create a new entity to take on the IANA functions, known as Post-Transition IANA (PTI)[2].  That entity would be a wholly owned subsidiary of ICANN, but have its own management structure, including a customer service component, known as the Customer Standing Committee.  All current IANA functions would be transferred to the PTI under this proposal.  A multistakeholder IANA Function Review  (IFR) process is created as well.  In a sense, the proposal is vaguely reminiscent of our own arrangements.  In particular it seems that the names community also wants to a customer relationship with the IANA Functions Operator (IFO) and to have the choice to change providers, should that ever become necessary.  There's a bunch of mechanism proposed to reduce the likelihood of a change, including escalation, a separation review, etc., but at the end of the day the choice would be the naming community's, just as the IAB has had the choice to continue the protocol parameters arrangement.
> 
> It's worth noting that NRO Executive Council has stated that they wish to retain a direct relationship with ICANN, and NOT the PTI[4].  The IAB could do the same, but then it seems to me that the value of the PTI itself is diminished.  And so that brings us back to the cardinal question: what's right for the Internet?  Here I understand that different people will have varying views.
> 
> Having the burden of funding shift to another source can itself be a source of instability.  The CWG proposal contains the FY15 budget costs for the IANA function.  That total is $6.3 million[6], but includes indirect and shared costs as well.  What isn't in those costs is an allocation across functions.  At the very least we should have that information.  Preferably we should have those costs separately funded, to the extent possible.  This would provide the naming community all the freedom they want, and us all the freedom we want, without budgetary risk.
> 
> Having written that last line, I feel the need to once again point out what we said in our response, that we are satisfied with the performance of ICANN as IFO, and have been for quite some time, and that all of this is still contingency planning.[5]
> 
> And so questions:
> Under this new arrangement, does it make sense to continue the relationship with ICANN as it stood before or does it make sense to go directly to PTI?
> If the arrangement is with PTI, should we seek a budgetary separation, and what would be the complexities of that?
> I think there may be other questions for the CWG proposal, but to me these are the big questions.
> 
> Eliot
> [1] https://www.icann.org/en/system/files/files/cwg-stewardship-draft-proposal-with-annexes-22apr15-en.pdf
> [2] See III.A bullet 1.
> [3] RFC 2860

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 May 2015 08:50:21 +1200

On 13/05/2015 20:27, Milton L Mueller wrote:

<snip>

> What I proposed and discussed was a much simpler alternative: take IANA out of ICANN rather than the other way around. IANA is small and its functions less political. It is easy to divest it struct…

Indeed, that would have made ICANN's role clear, although they would then need to
drop an 'N' since they would have no claim over the numbers any more.

<snip>

> Bottom line: how serious are your little gripes and cavils about how CWG has chosen to constitute PTI? Frankly I haven’t heard anything serious here. Are you focusing on the big picture, or are you…

I haven't seen gripes and cavils. What several people have been saying is: the
wholly-owned subsidiary is a meaningless change, because it's still ICANN.
(BTW, the IETF has past experience of getting services from a wholly owned
subsidiary of a non-profit corporation. It had no effect whatever when problems
arose.)

On 13/05/2015 23:15, Milton L Mueller wrote:

<snip>

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

<snip>

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

That seems pretty baroque, and much more complex than the IETF's solution (six
months notice and goodbye). And since the names community is not proposed to be
a separate entity from ICANN, as far as I can see, it all seems very fragile.

Nevertheless, IMHO the IETF's strategy (this being an IETF list, and all) is
not affected: sit tight but keep our finger close to that six-months-notice
button. As long as the protocol parameter registry ain't broke, we shouldn't
fix it.

    Brian

---

From: John Curran <[email-masked]>
Date: Thu, 14 May 2015 07:14:30 +0200

On May 12, 2015, at 4:07 PM, John Curran <[email-masked]> wrote:
> ..
Two additional documents have just become available noting compliance aspects of 
the two proposed options for the legal structure of the Post Transition IANA entity, and 
also the implications under each options considering various stress test scenarios:

1) PTI Entity Structure http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150514/df758365/PTIEntityStructure-0001.pdf <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150514/df758365/PTIEntityStructure-0001.pdf>
2) PTI Board Stress Tests http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150514/df758365/Memorandum-Post-TransitionIANABoardStressTests-May132015_20749...-0001.pdf <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150514/df758365/Memorandum-Post-TransitionIANABoardStressTests-May132015_20749...-0001.pdf>

FYI,
/John

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 14 May 2015 15:38:41 +0000

MM: Thanks for a very interesting and thoughtful intervention, Alissa. My responses in line, and I want especially to take up the issue of whether there are "compelling arguments" for transferring protocols stuff into PTI:

My personal view is that if the PTI is established, it would be preferable to keep the protocol parameters personnel, resources, and MOU at ICANN. Simply put, the current protocol parameters system works well. If it ain't broke, don't fix it.
I haven't seen particularly strong arguments for why the protocol parameters personnel, resources, or MOU would need to move to the PTI if the PTI gets established for names. However, if a compelling argument were to be made, I don't see major hurdles in moving the personnel or resources to the PTI.

MM: I there are 2 compelling arguments and 2 others which may not be quite as compelling. I will quickly set them out below, but keep in mind that most of them hinge on general benefits for Internet governance and not necessarily on specific benefits to IETF. I hope IETF can take the larger view. They are:
1.      Economies in organizational overhead
2.      Complementarity and coordination of functions
3.      More rational financial/resource accounting
4.      More focused negotiation
1) Any PTI will have some fixed organizational costs and the entity will be more efficient if they are spread over more functions and activities. Just to illustrate this point, it would make little sense to create a separate organization for, say, the numbers function alone as that would be maybe two people.

2) If the IANA functions and their management involve any interrelated activities, require coordination, or have some complementarity on the supply side, it would be better to keep them in the same entity rather than forcing the entity to reach across organizational boundaries every time they need to coordinate, etc. I frankly don't know how many interactions there are between protocol registry management and names/numbers management but I suspect there are some, and there are also some for names and numbers. This leads to what I think is a pretty strong response to your "if it's not broken don't fix it" argument, which is that if part of the current IANA dept moves to PTI then keeping the protocol functions inside ICANN is _not_ the status quo but a new and untested organizational arrangement. Further, if all the functions are provided by the same provider the less risk there is discrimination in the execution of the IANA functions. IANA should be by design a stable institution that can avoid conflicts between registries.

3) Structural separation makes things more visible in terms of their costs, which in turn enables greater financial accountability and efficiency.

4) In the future, do you want to negotiate with the legal staff and CEO of ICANN, which has a much broader agenda that is affected by a lot of ancillary things, or with a smaller, more focused entity?

In other words, I don't understand why it is proposed to move those things to the PTI, and I think moving them makes less sense than leaving them at ICANN proper, but I think the protocol parameters registries could probably continue to work just fine if the resources and personnel were moved based on some good argument for doing so.

MM: What you seem to be saying here is that there is really no strong reason _not_ to move them along with the other functions.

I don't see any advantages in moving the MOU even if the personnel and resources move. Since the PTI is proposed as a wholly owned subsidiary of ICANN, we can maintain our agreement with ICANN and they can subcontract the work out to their subsidiary if necessary. Again, no need to make extra changes to things that are working.

MM: That depends on whether you think current relations with ICANN are "working." See point 4 above, and perhaps take another guilty look at Andrew Sullivan's accidental message. ;-) The broader point is: I don't see any disadvantages to moving it, either.

I don't think it makes sense for the IETF to have a seat on the PTI board. The IAB can continue to exercise its oversight over the registry operator's performance of the protocol parameters function, so the addition of the board seat is not necessary. The CWG also proposes that the performance of IANA be periodically reviewed post-transition and that the protocol parameter community be offered the opportunity to appoint liaisons to the team performing reviews. Considering that we already have our own performance review process, I don't think this liaison is necessary either. In short, even if the protocol parameters resources and personnel were to move to the PTI, I think we should stick with our existing oversight and performance review processes, which work well.

MM: I mostly agree with the logic here. But, you may be unaware of the larger issues associated with the PTI board. The main debate in the CWG plan is whether the PTI board is controlled by ICANN or not (could have ICANN on it but not a majority). It's called "insider" vs "outsider" board. CWG is currently trending toward insider board but should it move toward an outsider board and wants non-ICANN people on it, why not an IETF appointee? Not necessarily in their capacity as "IETF," but just someone from the protocols community. If PTI performs all 3 IANA functions, does it not make sense to have someone from protocols on its board?That's more what this issue is about, not about supervision of the IETF MoU and SLA. Just as a hypothetical, suppose ICANN decided to (or its bylaws required it to) appoint its board liaison to the PTI. Doesn't sounds like you would support this, but would you oppose it? Sounds more like you are indifferent.

---

From: Russ Housley <[email-masked]>
Date: Thu, 14 May 2015 11:40:13 -0400

I'm not convinced there is a problem for IANAPLAN.  In the current situation, we have an MOU with ICANN, and the IANA Department does the work.  Under the proposal, we still have an MOU with ICANN, and an affiliate (the PTI) does the work.  I think of it as a reorganization.  ICANN has the same responsibilities and commitments to the IETF community.

I thik they can be glued together in a straightforward manner if the CWG and CCWG works is scoped exclusively to the names registry.

Russ

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 14 May 2015 17:19:27 +0100

Beyond contract/MoU, I guess the nature of PTI that emerge may also
determine the extent of ownership/oversight that ICANN has on PTI and to
what extent it can confidently sub-contract to PTI.

There is the affiliate option; which makes PTI independent of ICANN in
terms of ownership and management. The subsidiary option however ensures
ICANN ownership of PTI and could allow ICANN bearing more PTI liabilities
beyond what is possible with the affiliate option.

Also it's not yet clear how Accountability of PTI board beyond the contract
will look like (especially within the affiliate plus "outer board" option)

CWG is still looking at these options and I expect more definite direction
will be determined after the current PC

Regards
PS: By ICANN, I mean it's staff/board and community.
sent from Google nexus 4
kindly excuse brevity and typos.
On 14 May 2015 16:41, "Russ Housley" <[email-masked]> wrote:

> I'm not convinced there is a problem for IANAPLAN.  In the current
> situation, we have an MOU with ICANN, and the IANA Department does the
> work.  Under the proposal, we still have an MOU with ICANN, and an
> affiliate (the PTI) does the work.  I think of it as a reorganization.
> ICANN has the same responsibilities and commitments to the IETF community.
>
> I thik they can be glued together in a straightforward manner if the CWG
> and CCWG works is scoped exclusively to the names registry.
>
> Russ
>
> and IAOC might find useful, as they consider various activities relating to
> the IANA transition.
>
> component of the IANA functions transition proposal.  That proposal can be
> found at [1].  I'm posting some comments here strictly as relates to the
> IETF relationship with ICANN, and not the rest of it, since that discussion
> should occur elsewhere.
>
> The basis of the naming community's proposal is to create a new entity to
> take on the IANA functions, known as Post-Transition IANA (PTI)[2].  That
> entity would be a wholly owned subsidiary of ICANN, but have its own
> management structure, including a customer service component, known as the
> Customer Standing Committee.  All current IANA functions would be
> proposal is vaguely reminiscent of our own arrangements.  In particular it
> seems that the names community also wants to a customer relationship with
> the IANA Functions Operator (IFO) and to have the choice to change
> providers, should that ever become necessary.  There's a bunch of mechanism
> proposed to reduce the likelihood of a change, including escalation, a
> separation review, etc., but at the end of the day the choice would be the
> naming community's, just as the IAB has had the choice to continue the
> protocol parameters arrangement.
>
> RFC-2860.[2]  Second, since for the first time the naming community would
> have a choice in whether they wish to change IFO, we have to ask the
> question, “What if they did?”  What would happen to the PTI?  What, in
> particular, are the funding implications?  It has always been possible for
> ICANN or the IAB to terminate the arrangement.  If that happened, however,
> the IAB and IAOC would have to work with ISOC to determine a funding source
> for a new IFO for protocol parameters.
>
> It's worth noting that NRO Executive Council has stated that they wish to
> retain a direct relationship with ICANN, and NOT the PTI[4].  The IAB could
> do the same, but then it seems to me that the value of the PTI itself is
> diminished.  And so that brings us back to the cardinal question: what's
> right for the Internet?  Here I understand that different people will have
> varying views.
>
> source of instability.  The CWG proposal contains the FY15 budget costs for
> the IANA function.  That total is $6.3 million[6], but includes indirect
> and shared costs as well.  What isn't in those costs is an allocation
> across functions.  At the very least we should have that information.
> Preferably we should have those costs separately funded, to the extent
> possible.  This would provide the naming community all the freedom they
> want, and us all the freedom we want, without budgetary risk.
>
> what we said in our response, that we are satisfied with the performance of
> ICANN as IFO, and have been for quite some time, and that all of this is
> still contingency planning.[5]
>
> And so questions:
>
>    - Under this new arrangement, does it make sense to continue the
>    relationship with ICANN as it stood before or does it make sense to go
>    directly to PTI?
>    - If the arrangement is with PTI, should we seek a budgetary

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 15 May 2015 13:05:12 +1200

> I'm not convinced there is a problem for IANAPLAN.  In the current situation, we have an MOU with ICANN, and the IANA Department does the work.  Under the proposal, we still have an MOU with ICANN,…

Exactly. We measure IANA's performance today and negotiate any issues
with the people doing the work and their immediate management. In the
worst case, the IETF can give notice and find an alternative provider.
Whether ICANN performs the work in-house or through a subsidiary really
doesn't matter, formally.

What does matter is the direct contact with the people.

(For people less familiar with the history, the IETF has managed
changes of service provider for both the Secretariat and the
RFC Editor in the past. Doing the same for protocol parameter
registration would not be so different. I hope it doesn't become
necessary, of course.)

    Brian

>> The basis of the naming community's proposal is to create a new entity to take on the IANA functions, known as Post-Transition IANA (PTI)[2].  That entity would be a wholly owned subsidiary of ICANN, but have its own management structure, including a customer service component, known as the Customer Standing Committee.  All current IANA functions would be transferred to the PTI under this proposal.  A multistakeholder IANA Function Review  (IFR) process is created as well.  In a sense, the proposal is vaguely reminiscent of our own arrangements.  In particular it seems that the names community also wants to a customer relationship with the IANA Functions Operator (IFO) and to have the choice to change providers, should that ever become necessary.  There's a bunch of mechanism proposed to reduce the likelihood of a change, including escalation, a separation review, etc., but at the end of the day the choice would be the naming community's, just as the IAB has had the choice to con
tinue the protocol parameters arrangement.

---

From: Jefsey <[email-masked]>
Date: Thu, 14 May 2015 09:45:53 +0200

>I'm sorry.

Many of us are sorry you are sorry.
jfc

---

From: John C Klensin <[email-masked]>
Date: Fri, 15 May 2015 12:54:40 -0400

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

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

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

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

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

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 May 2015 19:19:52 +0100

FWIW, I agree with Russ.

S

On 14/05/15 16:40, Russ Housley wrote:
>> The basis of the naming community's proposal is to create a new entity to take on the IANA functions, known as Post-Transition IANA (PTI)[2].  That entity would be a wholly owned subsidiary of ICANN, but have its own management structure, including a customer service component, known as the Customer Standing Committee.  All current IANA functions would be transferred to the PTI under this proposal.  A multistakeholder IANA Function Review  (IFR) process is created as well.  In a sense, the proposal is vaguely reminiscent of our own arrangements.  In particular it seems that the names community also wants to a customer relationship with the IANA Functions Operator (IFO) and to have the choice to change providers, should that ever become necessary.  There's a bunch of mechanism proposed to reduce the likelihood of a change, including escalation, a separation review, etc., but at the end of the day the choice would be the naming community's, just as the IAB has had the choice to cont
 i
nue the protocol parameters arrangement.

---

From: Olaf Kolkman <[email-masked]>
Date: Mon, 18 May 2015 10:04:13 +0200

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

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.

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.

The Names Community is organized within ICANN and there is a funding stream from ICANN to the PTI.

If I understand Milton correctly then he favors:

```
Mental model 2

IETF -> PTI
NRO -> PTI
Names Community -> PTI
```

The picture is a bit more complicated since the Names Community is part of 'ICANN' and the funding of the PTI comes through 'ICANN'.

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?

—Olaf

- - -
Olaf M Kolkman
On Personal Title
- - -

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 18 May 2015 09:27:46 +0100

On Mon, May 18, 2015 at 9:04 AM, Olaf Kolkman <[email-masked]> wrote:

> 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:
>
> The picture is a bit more complicated since the Names Community is part of
> 'ICANN' and the funding of the PTI comes through 'ICANN'.
>
> 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,
>
For RIR and names, model 1 seem to be the case. However from my observation
of current IETF discussion, it seem there is a "but" in their preferred
version of model 1 as thus:

IETF -> ICANN [-> IANA Department ]

Where oversight(administrative) of IETF related function is not done by PTI

Regards

> —Olaf
>  ------------------------------
>  Olaf M. Kolkman
> On Personal Title.  Twitter: @Kolkman <https://twitter.com/kolkman>
> ------------------------------
>

-- 
------------------------------------------------------------------------

*Seun Ojedeji,Federal University Oye-Ekitiweb:      http://www.fuoye.edu.ng
<http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email:
<http://goog_1872880453>[email-masked]
<[email-masked]>*

The key to understanding is humility - my view !

---

From: John Curran <[email-masked]>
Date: Mon, 18 May 2015 07:32:04 -0400

> My mental model of the setup that is being discussed here (that is, if I were to determine the current consensus):

Olaf -

    I do not know what is current consensus, but the current proposals
    (IANAPlan, CRISP, CWG) reflect the following relations, as best I
    can determine -

- IANAplan (Protocol parameter registries)

    The protocol parameter community is represented by the IETF.

    The IETF (via its various structures incl. IAB and IAOC) continues
    its present relationship with ICANN for ICANN to provide IANA
    protocol parameter registry services.   Assignment by ICANN to
    another entity (such as a new PTI affiliate) would require IETF
    approval.

- CRISP (Internet number registries)

    The Internet numbers community is represented by the RIRs.

    The RIRs (via NRO coordination) enters into a service level
    agreement (SLA) with ICANN ICANN to provide IANA number
    registry services. Assignment by ICANN to another entity (such
    as a new PTI affiliate) is not provided for in the present SLA draft.

- CWG  (Internet domain name registry)

    The Internet DNS community is represented by the ICANN
    (as guided by its constituent parts, and with strengthened
     accountability to same as a result of the CCWG changes
     to make ICANN into a formal membership organization)

    ICANN enters into a service level agreement with PTI (a new
    wholly-owned affiliate) to provide IANA DNS registry services.

FYI,
/John

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 18 May 2015 13:35:38 +0000

Olaf:
Answer below

IETF -> ICANN [-> PTI ]

NRO  -> ICANN [—> PTI ]

Names Community -> PTI

Mental model 2

IETF -> PTI

NRO -> PTI

Names Community -> PTI

MM: Yes - as long as you remember that PTI, while a legally separate entity, is also an affiliate of ICANN; i.e., it is indirectly under its control. Further, I don’t think most people on this list are committed to model 1, because from a simple efficiency standpoint PTI will include all the IANA functions. So Mental Model 1 and 2 could co-exist, as long as ICANN assigns its contract with IETF and NRO to PTI. What is not viable is to keep protocols and numbers out of PTI.

MM: I think Russ Housley got it right when he said:

RH: I'm not convinced there is a problem for IANAPLAN.  In the current situation, we have an MOU with ICANN, and the IANA Department does the work.  Under the proposal, we still have an MOU with ICANN, and an affiliate (the PTI) does the work.  I think of it as a reorganization.  ICANN has the same responsibilities and commitments to the IETF community.

MM: The reform here is that the names community achieves the same kind of separation that numbers and protocols have, and there is a contract and SLA for the names IANA just as there is for numbers and protocols.

---

From: Jefsey <[email-masked]>
Date: Mon, 18 May 2015 15:44:07 +0200

Dear John, Olaf, Seun, and John,

Thank you for this clear summary of the I*Community's internal positions.

1. Two "inside" things must be added:

a) Jari Arkko's
<http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition>http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/ 
: "The NTIA must then consider and approve the proposal. Finally, it 
must be implemented." This means that the future of the IETF is not 
to result from an IETF consensus but rather from an NTIA decision.

b) The NTIA/White House/Congress/FCC convoluted political decision 
mechanism and respective responsibilities will be based upon the 
information available to them. This information is:
<<http://www.fas.org/sgp/crs/misc/R44022.pdf>http://www.fas.org/sgp/crs/misc/R44022.pdf>

2. The "outside" thing that must be added is simple: no outside 
aspect is being considered.

3. As a non-US citizen who is not particularly interested in the 
NTIA/White House/Congress/FCC/ICANN deliberations, and as a Libre 
lead user interested in my internet and non-internet protocol 
consistent relations with other local members of the global catenet, 
I am also interested, under the auspices of RFC 6852:

a) in the way the IETF will ensure that its global community's 
technology will stay compatible with other communities' technologies 
and/or practices and/or demands regardless of the number of competing 
"ICANN"s on the global market.

b) to know if the IAB and/or IESG is/are going to sponsor a BoF, 
introduce a charter, create a WG/MULTICANN on the way to use, 
operate, and manage a multi-Overlay Networked Edge Systems (ONES) environment.

c) or if I should request Andrew Sullivan or Jari Arkko  (I am not 
sure about the stream and the responsible AD in that case) to create 
a [email-masked] permanent non-WG mailing list to that end?

4. This results from my observation that:

a) the IETF does not seem to be interested in keeping the catenet's 
internet oriented technologies consistent along with a single IANA 
for all of their RFC 6852 global communities' flavors, enhancements, 
permissionless innovation, national sovereignty protections, and precautions.

b) the IESG has prefered not to consider the questions raised but not 
addressed by the IETF IANAPLAN consensus, I therefore have now to 
bring in the most adquate manner in front of the IAB before mid-June.

jfc

At 10:04 18/05/2015, Olaf Kolkman wrote:

>Working from the thesis that what is confusing to me might be 
>confusing to others. I am going to ask for clarification.
>
>My mental model of the setup that is being discussed here (that is, 
>if I were to determine the current consensus):
>
>Mental model 1
>
>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.
>
>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:
>
>The picture is a bit more complicated since the Names Community is 
>part of 'ICANN' and the funding of the PTI comes through 'ICANN'.
>
>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?
>
>—Olaf
>
>----------

At 10:27 18/05/2015, Seun Ojedeji wrote:

>For RIR and names, model 1 seem to be the case. However from my 
>observation of current IETF discussion, it seem there is a "but" in 
>their preferred version of model 1 as thus:
>
>IETF -> ICANN [-> IANA Department ]Where oversight(administrative) 
>of IETF related function is not done by PTI
>
>Regards

---

From: John Curran <[email-masked]>
Date: Mon, 18 May 2015 14:08:08 +0000

On May 18, 2015, at 9:35 AM, Milton L Mueller <[email-masked]<mailto:[email-masked]>> wrote:
MM: Yes - as long as you remember that PTI, while a legally separate entity, is also an affiliate of ICANN; i.e., it is indirectly under its control. Further, I don’t think most people on this list are committed to model 1, because from a simple efficiency standpoint PTI will include all the IANA functions. So Mental Model 1 and 2 could co-exist, as long as ICANN assigns its contract with IETF and NRO to PTI. What is not viable is to keep protocols and numbers out of PTI.

Milton -

   Your statement -

         “So Mental Model 1 and 2 could co-exist, as long as ICANN assigns its contract with IETF and NRO to PTI.”

   may be accurate but is quite different than -

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

FYI,
/John

---

From: John C Klensin <[email-masked]>
Date: Mon, 18 May 2015 10:43:53 -0400

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

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

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
> 
> 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:
> 
> ```

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.

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

---

From: John C Klensin <[email-masked]>
Date: Mon, 18 May 2015 10:57:23 -0400

--On Monday, May 18, 2015 14:08 +0000 John Curran
<[email-masked]> 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

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 18 May 2015 15:12:40 +0000

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

Wrong. This has been explained repeatedly; PTI provides separation, a limited amount of independence and mirrors the relationship numbers and protocols already have. Complete independence would be preferable but is not politically feasible. 

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

Except that you have not provided any plausible reasons why they shouldn't. The numbers contract doesn't exist yet and thus could easily specify either ICANN or PTI as its counterparty. The protocols MoU and SLA could be assigned to PTI without any change in its substance. 

> 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

As I've said before, there will be an independent-affiliate PTI or there won't be a transition in the next two years. Take your pick.

---

From: Seun Ojedeji <[email-masked]>
Date: Mon, 18 May 2015 17:53:13 +0100

sent from Google nexus 4
kindly excuse brevity and typos.
On 18 May 2015 16:12, "Milton L Mueller" <[email-masked]> wrote:
>
>
> As I've said before, there will be an independent-affiliate PTI or there
won't be a transition in the next two years. Take your pick.
SO: Milton that sounds quite authoritative and a little threatening to me
;-). The last time I checked, me and you represent just a subset of the
communities working on the transition proposal and none of us actually work
for NTIA. While you have made some important points, I think the last part
above may not be appropriate if you are interested in seeing MS at work.

Regards

---

From: Jefsey <[email-masked]>
Date: Mon, 18 May 2015 19:21:39 +0200

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
>
>ÛˆMHX^HŒMK]NM›ÚˆÀ Klensin wrote:
> >
> >š\œÝÙˆ[[™\È˜\ˆ\ÈHØ[ˆ@ll, if we ended up with the
> >QUˆ[™ÛÜˆ'TœËÓ""È]š[€g agreements about relevant IANA
> >YÜ™Y[Y[Ú]H@ for IANA functions that are relevant to
>ˆ[KZ]\ˆwe end up splitting IANA into two (or three)
>ˆike:
>ˆˆQUˆOˆPÐS"ˆOˆPSH\\Y[ˆ""ÈB"0ANN 
>-PSH\\Y[ˆ˜[Y\ÈÛÛ[][š]HBD'Óâ"4àN -> IANA Department
> >
>^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ˆPSH›XÚÀbox ]
>‚ ]¡•É"Ñ¡"}%9‰±…‰½á|€…¹|PTI_ deliver the registry
>X›XØ][Ûˆ[™XZ[[˜[˜ÙH€unctions. The reason why I
>   RIRs -> NRO (?) -PÐS"ˆB"NA-operational-function
>ÒPSH›XÚØ›ÞÈÛÝ[ÛÚÈ[ˆ˜XÝbe the _PTI_, with the IANA
>‚`
>Y[[[Ù[HH[\[Y[][ÛˆˆˆQUˆOˆPÐS"ˆÀ-> PTI ]
> > NRO  -> ICANN [—> PTI ]
>˜[Y\ÈÛÛ[][š]H@> PTI
> > ```
> >
>[™\œÝ[™[™È]^HY[[[Ù[H[YÛœÈwith where most
>ˆH™X\ÛÛ˜X›H™\™\Ù[][ÛˆÙ€ your thoughts‚"Z[ÛˆØ[‹[™™\Ý[XX›HÚ[ÜXZÈ€or 
>himself, but my view
>Community - PTI relationship, some of those linkages are

---

From: Jefsey <[email-masked]>
Date: Mon, 18 May 2015 19:24:11 +0200

At 18:53 18/05/2015, Seun Ojedeji wrote:
>I think the last part above may not be appropriate if you are 
>interested in seeing MS at work.

Seun, I am afraid this IS multistakeholderism at work. jfc

---

From: John Curran <[email-masked]>
Date: Mon, 18 May 2015 17:24:17 +0000

On May 18, 2015, at 11:12 AM, Milton L Mueller <[email-masked]> wrote:
>> (From John Klensin)
>> ...that there are reasons why it might not be in the interest of those bodies
>> to provide that consent.
> 
> Except that you have not provided any plausible reasons why they shouldn’t. ...

Milton - 

An agreement with ICANN provides absolutely clarity on the party which is accountable for the 
delivery of the specific IANA registry services, and does so in a manner which is independent 
of any other circumstances within ICANN.

An agreement for IANA services with PTI must acknowledge numerous dependencies on ICANN 
(e.g. budget, internal services, actions of the ICANN Board, etc.) - these dependencies all become 
risks which now the contracting party  (IETF, RIRs) must now deal with during contracting with 
regards to potential PTI non-performance.  For example, an ICANN/PTI disagreement that materially 
impacts PTI’s ability to deliver on IANA services to a particularly community may result in little direct 
liability to ICANN, if indeed that community contracted with PTI rather than ICANN.  That’s one very
plausible reason not to contract in that manner.  Another reason is that PTI is likely to have rather 
limited assets and reserves, and thus unable to directly address any serious performance issues 
that might arise without seeking additional capital from ICANN.   In general, it is not a prudent move
for businesses to allow assignment of their contracts to entities that are less capable of delivering
on the obligations therein.

/John

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 18 May 2015 10:59:43 -0700

Hi Milton,

Thanks. I guess we are really talking about two aspects of the IANA functions and whether those aspects should change. (1) Currently all the functions are provided by the same entity (the IANA Department) and (2) that department is currently part of ICANN. If either of these must change, you have a preference for changing 2 and not 1; I have a preference for changing 1 and not 2. 

On May 14, 2015, at 8:38 AM, Milton L Mueller <[email-masked]> wrote:

>  
> MM: Thanks for a very interesting and thoughtful intervention, Alissa. My responses in line, and I want especially to take up the issue of whether there are “compelling arguments” for transferring protocols stuff into PTI:
>  
> I haven’t seen particularly strong arguments for why the protocol parameters personnel, resources, or MOU would need to move to the PTI if the PTI gets established for names. However, if a compelling argument were to be made, I don’t see major hurdles in moving the personnel or resources to the PTI.
>  

That may be true, but if the names functions on their own can’t justify the overhead they require, I would question why they’re being split out in the first place. I tend to think they do actually justify their own overhead, and the overhead for protocol parameters and numbers can continue to be subsumed in the larger ICANN cost structure. Furthermore, we’re talking about a pretty small PTI no matter whether it encompasses all three functions or just one — it’s not like the IANA functions are a huge operation. We’re talking about three people who provide the protocol parameters function.

>  
> 2) If the IANA functions and their management involve any interrelated activities, require coordination, or have some complementarity on the supply side, it would be better to keep them in the same entity rather than forcing the entity to reach across organizational boundaries every time they need to coordinate, etc. I frankly don’t know how many interactions there are between protocol registry management and names/numbers management but I suspect there are some, and there are also some for names and numbers. This leads to what I think is a pretty strong response to your “if it’s not broken don’t fix it” argument, which is that if part of the current IANA dept moves to PTI then keeping the protocol functions inside ICANN is _not_ the status quo but a new and untested organizational arrangement.

I’m not aware of much coordination at the operational level. The important coordination happens at the policy level and should continue to be the responsibility of the policy bodies. It’s true that the policy bodies might need to know to inform a different operator if one or more of the functions moves outside the IANA Department, but that seems like the appropriate path to me, rather than asking the operators to coordinate, which seems like it would be outside their mandates anyway.

If the operators all continue to share the same web site then they will need some administrative coordination, but that seems trivial enough and again not sufficient reason to keep the personnel and resources together.

> Further, if all the functions are provided by the same provider the less risk there is discrimination in the execution of the IANA functions. IANA should be by design a stable institution that can avoid conflicts between registries.

I’m not sure what you mean by discrimination and conflicts between registries.

> 4) In the future, do you want to negotiate with the legal staff and CEO of ICANN, which has a much broader agenda that is affected by a lot of ancillary things, or with a smaller, more focused enti…

The above two arguments strike me as additional benefits that you think the CWG proposal provides to the IETF, but the IETF has already submitted its proposal and is on the record as being satisfied with the current arrangements. If we think the above two points are valid, we could pursue them in the future or we could have included them in our own proposal, but we didn’t.

>  
> In other words, I don’t understand why it is proposed to move those things to the PTI, and I think moving them makes less sense than leaving them at ICANN proper, but I think the protocol parameters registries could probably continue to work just fine if the resources and personnel were moved based on some good argument for doing so.
>  

See my point above about preferring to split operations rather than move to PTI.

> MM: That depends on whether you think current relations with ICANN are “working.” See point 4 above, and perhaps take another guilty look at Andrew Sullivan’s accidental message. ;-) The broader point is: I don’t see any disadvantages to moving it, either.

Again, the IETF consensus is that we are satisfied with current arrangements.

> MM: I mostly agree with the logic here. But, you may be unaware of the larger issues associated with the PTI board. The main debate in the CWG plan is whether the PTI board is controlled by ICANN or not (could have ICANN on it but not a majority). It’s called “insider” vs “outsider” board. CWG is currently trending toward insider board but should it move toward an outsider board and wants non-ICANN people on it, why not an IETF appointee? Not necessarily in their capacity as “IETF,” but just someone from the protocols community. If PTI performs all 3 IANA functions, does it not make sense to have someone from protocols on its board?That’s more what this issue is about, not about supervision of the IETF MoU and SLA. Just as a hypothetical, suppose ICANN decided to (or its bylaws required it to) appoint its board liaison to the PTI. Doesn’t sounds like you would support this, but would you oppose it? Sounds more like you are indifferent.

Reading this, it seems like there are too many missing details about the board at this point to really be able to provide an opinion. 

Alissa

---

From: John Curran <[email-masked]>
Date: Mon, 18 May 2015 16:23:44 -0400

>   and would require consent of the parties.

To be clear - 
 
      I don’t see any issue with ICANN having a wholly-owned subsidiary which performs the IANA
      registry services, as long as ICANN is obligated by contract to provide those services to the 
      RIRs and the IETF respectively.

      There’s potentially some real benefits to having a distinct organization as the IANA operator,
      including a better understanding of IANA costs and greatly improved clarity of processes for 
      the names community, as the process line between ICANN and IANA for DNS-related tasks 
      would become explicit.   (For those in the number and protocol communities, the line is quite 
      clear, but the delineation would be much improved to the benefit of the names community.)

      To the extent any folks feel that the CWG proposed PTI structure is not compatible with the
       IANAplan proposal, it would be best to converge on why that is the case so that the IETF 
       can document the result and submit it as a formal comment on the CWG draft proposal
       consultation - 
       <https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en <https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en>>
       
Thanks!
/John

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 19 May 2015 11:36:23 +1200

On 19/05/2015 03:12, Milton L Mueller wrote:

...
> As I've said before, there will be an independent-affiliate PTI or there won't be a transition in the next two years. Take your pick. 

An interesting viewpoint, but as far as the IETF is concerned, there can be a
transition 6 months after we give notice to ICANN. I realise that the names
community is not in the same position.

   Brian

---

From: "John Levine" <[email-masked]>
Date: 19 May 2015 01:58:18 -0000

>...
>> As I've said before, there will be an independent-affiliate PTI or there won't be a
>transition in the next two years. Take your pick. 

>From what I've seen if there were no transition in the next two years,
or in the next 20 years, that would be just fine with the IETF.

---

From: John C Klensin <[email-masked]>
Date: Mon, 18 May 2015 22:03:59 -0400

--On Monday, May 18, 2015 15:12 +0000 Milton L Mueller
<[email-masked]> wrote:

>> 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,
> 
> Wrong. This has been explained repeatedly; PTI provides
> separation, a limited amount of independence and mirrors the
> relationship numbers and protocols already have.

As others have pointed out, there is a fundamental difference
between the IETF relationship (and, to a considerable degree,
the RIR relationship) with ICANN and the "names community"
relationship with ICANN.  That differences lies in the
distinction between "independent actor and customer" and
"constituency" (or, more accurately, "collection of
constituencies".  I'm even putting "names community" in quotes,
not to be disparaging but to remind you and others that the
claim that it is single community with common purpose often does
not appear to be true.   PTI doesn't change that.  To the extent
to which it allows the "names community" to "mirror" the
protocol relationships [1], the mirror is fairly distorted.  

Rather than looking at this in terms of governance, let's
consider the more objective relationships associated with how
IANA registries are created and populated.  For the IETF case,
those decisions are made by IETF processes, completely outside
of ICANN.  IANA has a role to verify clarify and consistency of
the specifications, but no real decision role.  And non-IANA
ICANN processes have no role at all.  ICANN, as an organization,
doesn't even get to review the procedures the IETF uses to make
those decisions.  By contrast, using the most important of the
IANA Names registries, the database of top level domains (aka
"root zone database") as an example, new entries are added to
the database according to rules established by ICANN (one hopes
via bottom-up policy development) and then, IIR, approved one at
a time by the ICANN Board.  Delegation changes, e.g., to adjust
the servers for a particular TLD, also go through ICANN
processes.  Once changes are approved, ICANN directs IANA to
make the registry changes (in the current model, those changes
go through NTIA review too, but that doesn't change ICANN's key
role).

Interestingly, the "names community" doesn't even have final
approval authority over those changes within the ICANN community
and processes (again, with or without NTIA).

In principle, one could change that model to make the "names
community" relationship with ICANN mirror the IETF one, but
doing so would, AFAICT, require a much more significant
reorganization of ICANN than the "2.0" one of circa a dozen
years ago.  To the best of my knowledge, a reorganization of
that sort is not on the table.  In my personal opinion, while it
might be desirable, trying to disguise it as part of this
particular transition would be unwise and far exceeds the
mandates of the various transition-related groups.

>...
> Except that you have not provided any plausible reasons why
> they shouldn't. The numbers contract doesn't exist yet and
> thus could easily specify either ICANN or PTI as its
> counterparty. The protocols MoU and SLA could be assigned to
> PTI without any change in its substance. 

Coming back to my first note in this thread, I see a potential
loss of accountability in such a transfer because it is
difficult to see how agreements with the sort of PTI you
contemplate could be enforced against ICANN if, for some reason,
they decided to not supply PTI with the resources needed or
otherwise constrained PTI's behavior.  You have said that there
are ways to solve that problem and then indicated that the
details have not been worked out.  On that basis, I'm not sure
why the community outside the CWG is being asked to review the
draft at all until there is a complete proposal.  

The question of whether you and the "names community" have to
demonstrate to other communities, e.g., what problems the PTI
model would solve or whether they need to convince you that it
is defective is not one that is likely to achieve more clarity
by either of us repeating ourselves.

> As I've said before, there will be an independent-affiliate
> PTI or there won't be a transition in the next two years. Take
> your pick. 

If you are speaking for the "names community", that puts us in
an interesting position.  Stressing that I'm speaking for myself
only, one of my concerns about various forms of ICANN
reorganizations and assertions of authority (disguised as
"transition" or not) is that, if not managed very carefully and
with careful consideration and protection of the roles in the
Internet of other bodies, changes could turn into mechanisms for
the "names community" and/or "domainer interests" to bully those
other bodies.  

If the position of CWG and the "names community" more broadly is
"we either get our way or we will make sure that no agreement is
reached" -- and "PTI as we have defined it or no transition"
seems to be just that--  then that concern is already validated
and puts those other bodies and communities in a position in
which a transition is actually unwise unless strong protections
against "names community"-driven excesses or decisions that
benefit that community and not the Internet are built into the
system.  

Because I think a transition away from the present NTIA role
would be a good idea, I hope that is not where we are headed.

best,
   john

[1] I know far more about the situation in the IETF wrt
protocols and protocol-associated registries than I do about the
address registries or mechanisms within the RIRs, so will focus
on the former.

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 19 May 2015 07:46:24 +0200

Please see embedded comment below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]] On Behalf Of John C
> Klensin
> Sent: Tuesday, May 19, 2015 04:04
> To: Milton L Mueller
> Cc: [email-masked]; Olaf Kolkman
> Subject: Re: [Ianaplan] CWG draft and its impact on the IETF
> 
> 
> 
> >> Yes.  See the response I just sent to Olaf, but it seems to me that
> a
> >> "PTI" as a subcontracting arrangement to (more or
> > Wrong. This has been explained repeatedly; PTI provides separation, a
> > limited amount of independence and mirrors the relationship numbers
> > and protocols already have.
> 
> As others have pointed out, there is a fundamental difference between
> the IETF relationship (and, to a considerable degree, the RIR
> relationship) with ICANN and the "names community"
> relationship with ICANN.  That differences lies in the distinction
> between "independent actor and customer" and "constituency" (or, more
> accurately, "collection of constituencies".  I'm even putting "names
> community" in quotes, not to be disparaging but to remind you and
> others that the claim that it is single community with common purpose
> often does
> to which it allows the "names community" to "mirror" the protocol
> relationships [1], the mirror is fairly distorted.
> 
> Rather than looking at this in terms of governance, let's consider the
> more objective relationships associated with how IANA registries are
> created and populated.  For the IETF case, those decisions are made by
> IETF processes, completely outside of ICANN.  IANA has a role to verify
> clarify and consistency of the specifications, but no real decision
> role.  And non-IANA ICANN processes have no role at all.  ICANN, as an
> organization, doesn't even get to review the procedures the IETF uses
> to make those decisions.  By contrast, using the most important of the
> IANA Names registries, the database of top level domains (aka "root
> zone database") as an example, new entries are added to the database
> according to rules established by ICANN (one hopes via bottom-up policy
> development) and then, IIR, approved one at a time by the ICANN Board.
> Delegation changes, e.g., to adjust the servers for a particular TLD,
> also go through ICANN processes.  Once changes are approved, ICANN
> directs IANA to make the registry changes (in the current model, those
> changes go through NTIA review too, but that doesn't change ICANN's key
> role).
> 
> Interestingly, the "names community" doesn't even have final approval
> authority over those changes within the ICANN community and processes
> (again, with or without NTIA).
> 
> In principle, one could change that model to make the "names community"
> relationship with ICANN mirror the IETF one, but doing so would,
> AFAICT, require a much more significant reorganization of ICANN than
> the "2.0" one of circa a dozen years ago.  

I agree with John. If PTI is a wholly owned subsidiary of ICANN, then I
don't see how it provides any meaningful separation.

As John points out, ICANN is the policy-making authority for names, so
mirroring the arrangements for protocol parameters and numbers would require
that ICANN contract with an independent entity for the names part of the
IANA function. And this because the policy authorities for protocol
parameters and numbers contract with an independent entity, ICANN, for their
parts of the IANA function.

PTI as currently conceived is not independent of ICANN, so the proposed
transition for names is not at all comparable to the proposed transition for
protocol parameters and numbers.

I have some trouble understanding exactly what problem the creation of PTI
is supposed to solve.

I don't think that it addresses the number 1 priority issue identified by
the Working Group on Internet Governance back in 2005, namely the asymmetric
role of the USA, because it seems that ICANN and PTI will be based in the US
and subject to US law.

SNIP

> Coming back to my first note in this thread, I see a potential loss of
> accountability in such a transfer because it is difficult to see how
> agreements with the sort of PTI you contemplate could be enforced
> against ICANN if, for some reason, they decided to not supply PTI with
> the resources needed or otherwise constrained PTI's behavior.  You have
> said that there are ways to solve that problem and then indicated that
> the details have not been worked out.  On that basis, I'm not sure why
> the community outside the CWG is being asked to review the draft at all
> until there is a complete proposal.

Indeed, I don't see how one can evaluate a proposal that is missing key
elements, namely the exact legal structure of PTI and who controls it.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 May 2015 08:20:51 +0200

Hi Milton,

I apologize for the long delay in responding to you.

On 5/12/15 8:32 AM, Milton L Mueller wrote:
> community abandons PTI for another IFO, then the IETF would too. This
> is not necessarily true. IETF could continue to rely on PTI for its
> own IANA functions even if it did not provide the naming functions if
> it wanted to. If that were the case, the total budget for PTI would

I'm not sure I parsed you entirely correctly here, but the concern I was
raising was this: the ICANN fee and the naming gold rush have
cross-subsidized the other functions, most notably protocol parameters. 
If names pulls out of the PTI, what incentives and mechanisms would
remain in place to continue to fund the other functions at the same
service levels?  That simply was not a concern before.  It is (at least
to me) now.  I don't think it is insurmountable, especially over a
longer term, but perhaps some groundwork may need to be laid within the
naming context now, even if the IETF or RIRs do not choose to go
directly to the PTI.

And yes, it is true that the IETF could always have terminated the
arrangement, and then we would have had a funding problem of our
making.  But that would have been the IETF's decision, not the naming
community's.  This situation is different.

As to whether poor service for one function translates to poor service
for the others, in this hopefully very hypothetical case, I would
imagine that to be possible.  But I also would imagine it to be a case
where that was not the case, and the matter was of sole concern to one
community or that the communities reacted differently to the same
circumstance.  But in any case, if the whole point is choice for each
community, true choice only really comes when they can independently
evaluate the circumstances without a financial Sword of Damocles hanging
over their heads, and in this case, I will claim that the IETF is
particularly vulnerable.

Eliot

---

From: Roger Jørgensen <[email-masked]>
Date: Tue, 19 May 2015 12:30:59 +0200

Milton,

see inline:

On Mon, May 18, 2015 at 5:12 PM, Milton L Mueller <[email-masked]> wrote:
<snip>
> As I've said before, there will be an independent-affiliate PTI or there won't be a transition in the next two years. Take your pick.

Seems like we are, again, at the point where your view/understanding
don't line up with how me and others here see it.

Several others have explained how the relationship is, and how things
work atleast for IETF and partly the number side. With all that in
mind I wonder about what part about our view is that you don't get or
understand, or maybe only disagree with?

--

---

From: "Martin J. Dürst" <[email-masked]>
Date: Tue, 19 May 2015 20:07:21 +0900

> Again, the IETF consensus is that we are satisfied with current arrangements.

That's definitely true. But my understanding would be that this is the 
position of the IETF starting from only the status quo before the whole 
process, i.e. without information about what the other bodies/functions 
want/need/desire/prefer.

It would have been a big waste of time for the IETF to 
discuss/describe/list, purely theoretically, other arrangements that 
might also satisfy us, also because the IETF was the first of the three 
bodies to express its consensus.

However, as far as I understand, that doesn't, at least not in theory, 
exclude that the IETF could be satisfied with other arrangements (e.g. 
in the way/extent that Russ has expressed it). There has been no 
consensus call on that, and so we simply don't know.

> Reading this, it seems like there are too many missing details about the board at this point to really be able to provide an opinion.

That's of course very much true. My guess is that one reason the 
information we received got sent our way at this stage is to test the 
waters.

Regards,   Martin.

---

From: John Curran <[email-masked]>
Date: Tue, 19 May 2015 07:23:48 -0400

> protocol parameters and numbers.

Richard - you are correct.  The best I’ve been able to accomplish in building a mental
model of the names portion of the proposed IANA stewardship plan has been as follows:

   “The community affected by the IANA names registry intends to use ICANN 
    as their overall representative structure, and thus will (via the CCWG efforts) 
    fortify ICANN’s accountability to that community and will have ICANN (via the 
    CWG efforts) not directly perform IANA functions but instead create a separate
    affiliate (PTI) to be a vendor to the names community (via ICANN) for IANA 
    names registry services.”

While similar, this is not the approach taken by the protocol parameter or Internet numbers 
communities (who instead have clear and independent representative structures) and hence
probably not the direction I personally would have proposed if given the problem to solve.

Of course, whether the proposed approach to the problem matches my (or the IETF’s) 
expectations is not really germane - it apparently matches the expectations of the names
community, and the note from the ICG suggests that some aspects would benefit from 
review by the IETF due to potential interaction with the IETF’s plans for IANA services 
(see the attached 29 April 2015 email from Alissa in her capacity as ICG Co-Chair)

> I have some trouble understanding exactly what problem the creation of PTI

The names community WG for the IANA stewardship transition planning (CWG) believes
that the creation of the PTI (plus strengthening of ICANN via the CCWG reforms) should
meet their requirements.   There’s actually quite a few mailing lists and fairly intense work
process going over in that WG (7+ design teams, 50+ teleconferences, etc.) and hence
participating over there would likely be the best place for the enlightenment you seek - 
<https://community.icann.org/display/gnsocwgdtstwrdshp/CWG+to+Develop+an+IANA+Stewardship+Transition+Proposal+on+Naming+Related+Functions <https://community.icann.org/display/gnsocwgdtstwrdshp/CWG+to+Develop+an+IANA+Stewardship+Transition+Proposal+on+Naming+Related+Functions>>

Note that the charter of this working group (IANAplan WG) includes the following - 

"Should proposals made by other communities regarding the transition of other IANA 
functions affect the IETF protocol parameter registries or the IETF, the WG may also 
review and comment on them.”    As such, it would be in scope for the IANAplan working
group to review & comment on how the CWG proposal affects the IETF protocol parameter
registries (particularly with respect to the ICG identified aspects), if it choses to do so….

The public comment period on the CWG draft closes on 23:59 UTC 20 May 2015 - 
<https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en <https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en>>

/John

Disclaimer: my views alone.   this email composed of 100% recycled electrons.

===  ICG to IANAplan regarding CWG proposal availability & noting specific aspects 

Begin forwarded message:

> From: Alissa Cooper <[email-masked]>
> Subject: [Ianaplan] Transition proposal for naming-related functions
> Date: April 29, 2015 at 9:25:32 AM EDT
> To: "Ianaplan@Ietf. Org" <[email-masked]>
> 
> Dear IETF community,
> 
> You may be aware that the Cross Community Working Group developing the IANA stewardship transition proposal for naming-related functions has recently put its proposal out for public comment <https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en <https://www.icann.org/public-comments/cwg-stewardship-draft-proposal-2015-04-22-en>>. We wanted to highlight a few aspects of the proposal that we believe would benefit from review and perhaps comment by your community:
> 
> 1) Overlaps and interdependencies (Section I.D and Annex A)
> As in your community’s proposal, the CWG proposal contains information concerning overlaps and interdependencies with the other communities.
> 
> 2) Post-Transition IANA (Section III)
> The CWG is proposing that a new separate legal entity, Post-Transition IANA (PTI), would be formed as an affiliate of ICANN. The existing IANA naming functions, administrative staff and related resources, processes, data and know-how would be legally transferred into PTI. Your community may want to consider a number of associated implications:
> 
> * The likelihood that personnel and resources dedicated to the non-naming IANA functions would be moved to PTI. Your community may also want to consider its view on having all IANA functions provided by the same entity or allowing them to be separated.
> 
> * Contracting. For existing or new contracts your community may have related to the IANA functions, there may be multiple options available, including maintaining existing contracts with ICANN and letting them subcontract their execution to PTI, assigning an existing contract to PTI, or re-contracting with PTI.
> 
> * PTI Board. The composition of the PTI Board is not highly specified in the CWG proposal. There has been some discussion within the CWG about including representation for the RIRs and IETF on the PTI Board.
> 
> * PTI ownership. If the PTI is formed as an affiliate of ICANN as the CWG proposes, as a legal entity it would be wholly owned by ICANN. Your community may want to consider its view of this whole ownership versus joint ownership involving all or multiple communities.
> 
> 3) Liaisons to IANA Functions Review Team (Section III.A.i.d and Annex F)
> The CWG proposes that the performance of IANA be periodically reviewed post-transition and that the numbering and protocol parameter communities be offered the opportunity to appoint liaisons to the team performing reviews.
> 
> 4) Customer Service Complaint Resolution Process (Annex I)
> The CWG proposes a complain resolution process for naming-related services, but which is open to the protocol parameters and numbering resources communities.
> 
> 5) Composition of the Customer Standing Committee (Section II.A.ii.a and Annex G)
> The CWG proposes the creation of a Customer Standing Committee (CSC) to monitor the performance of the IANA naming function. The proposal mentions the possibility of IAB representation on the CSC. 
> 
> If the ICG can be of further assistance in coordinating your review or understanding of the CWG proposal, please let us know.
> 
> Thanks,
> Alissa Cooper on behalf of the ICG

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 19 May 2015 14:49:07 +0000

From: Eliot Lear [mailto:[email-masked]]

I'm not sure I parsed you entirely correctly here, but the concern I was raising was this: the ICANN fee and the naming gold rush have cross-subsidized the other functions, most notably protocol parameters.  If names pulls out of the PTI, what incentives and mechanisms would remain in place to continue to fund the other functions at the same service levels?  That simply was not a concern before.  It is (at least to me) now.  I don't think it is insurmountable, especially over a longer term, but perhaps some groundwork may need to be laid within the naming context now, even if the IETF or RIRs do not choose to go directly to the PTI.

And yes, it is true that the IETF could always have terminated the arrangement, and then we would have had a funding problem of our making.  But that would have been the IETF's decision, not the naming community's.  This situation is different.

MM: Eliot, let me rephrase your concern this way. Tell me if you think it is fair and then we will have a clearer basis for discussion.

You and Alissa are saying that you want the protocols IANA functions to remain outside of PTI and in ICANN because that way, the names community will have no choice as to whether it can withdraw from the arrangement, whereas IETF can decide whether to withdraw at any time.

Correct?

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 May 2015 16:59:20 +0200

On 5/19/15 4:49 PM, Milton L Mueller wrote:
>
>  
>
>  
>
> *From:*Eliot Lear [mailto:[email-masked]]
>
> I'm not sure I parsed you entirely correctly here, but the concern I
> was raising was this: the ICANN fee and the naming gold rush have
> cross-subsidized the other functions, most notably protocol
> parameters.  If names pulls out of the PTI, what incentives and
> mechanisms would remain in place to continue to fund the other
> functions at the same service levels?  That simply was not a concern
> before.  It is (at least to me) now.  I don't think it is
> insurmountable, especially over a longer term, but perhaps some
> groundwork may need to be laid within the naming context now, even if
> the IETF or RIRs do not choose to go directly to the PTI.
>
>  
>
> MM: Eliot, let me rephrase your concern this way. Tell me if you think
> it is fair and then we will have a clearer basis for discussion.
>
>  
>
> You and Alissa are saying that you want the protocols IANA functions
> to remain outside of PTI and in ICANN because that way, the names
> community will have no choice as to whether it can withdraw from the
> arrangement, whereas IETF can decide whether to withdraw at any time.
>
>  
>
> Correct?
>
>
>

I would state it differently: I am all for the names community to have
choices, but let's agree that there are ramifications for the other
communities, and those ramifications should be addressed and not swept
under the rug.

Eliot

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 19 May 2015 15:18:36 +0000

> don't see how it provides any meaningful separation.

First, let me correct an error: there is no ownership of public benefit corps. If PTI is a public benefit corp. (PBC) it is an affiliate, not a "wholly owned subsidiary." If it is a PBC it can have an insider board or an "outsider" board. An insider board is appointed by and controlled by ICANN; an outsider board is not. If a PBC has an outsider board it can be quite independent. Indeed, the apologists for ICANN have lobbied very strongly against such a proposal for precisely that reason. The issue of PBC vs. LLC is still to be made; and the issue of insider vs outsider board is also not made. So there is a spectrum of separation and independence from ICANN. If your goal is a better proposal (rather than to obstruct a solution) I would interpret your comment to mean that you favor a more independent PTI, as do I. 

However, no matter where the names community locates itself on that spectrum, PTI is still "meaningfully" separated from ICANN. The assets and staff and operations management of PTI would have been moved out of ICANN corporate, 94% of which is names policy related, and into a separately run entity. The work flow process, as John Curran noted yesterday, would become explicit and that would be a meaningful change in terms of separating policy from implementation. By creating a separate affiliate, a contract and creating a periodic review process which has rebidding the contract possible, we also make it more feasible to fire PTI and use a different IANA functions provider. 

> the Working Group on Internet Governance back in 2005, namely the
> asymmetric role of the USA, because it seems that ICANN and PTI will
> be based in the US and subject to US law.

I understand that this is your real concern, so perhaps that explains why you are taking off-target pot shots at PTI. 
But let's confront the real issue, and not make the corporate structure of PTI a proxy. 

My answer to you is:
1) the number 1 concern of the WGIG (and it was 2004, not 2005) was NOT U.S. jurisdiction, but unilateral U.S. government control over the IANA contract. The stewardship transition does address that. 

2) There is surprisingly little support in the names community for moving ICANN or PTI out of U.S. jurisdiction. There would be fervent opposition to doing so from the U.S. Congress and many others. As you know, I am agnostic on that issue; I think PTI could be jurisdictionally domiciled anywhere especially if it is just an independent contractor of ICANN. But as a practical political matter, it probably won't be, at least not in the initial stages of this change.

---

From: Milton L Mueller <[email-masked]>
Date: Tue, 19 May 2015 16:58:08 +0000

EL: I would state it differently: I am all for the names community to have choices, but let's agree that there are ramifications for the other communities, and those ramifications should be addressed and not swept under the rug.

MM:
Let’s address them. I think the ramifications for other communities are minimal if we look at it objectively.
Movement of all 3 functions into PTI is actually the most conservative option because those functions are together now as a single department and we are, as Russ said, simply reorganizing them into a distinct affiliate, which has several improved governance and accountability features. So let’s assume a PTI that includes names, numbers, protocols. What happens if the names community pulls out of PTI at some point in the future, while IETF is happy with PTI? What, especially, are the financial implications for IETF? It is useful to explore this scenario.
My view is that if names pulled out of PTI, nothing would happen to IETF. A smaller PTI would continue to supply numbers and protocols functions as before. Why do I believe this? Because IETF would still have an MoU with ICANN to provide the protocols-related functions, and the RIRs would still have a contract for supply of the numbers functions. If ICANN was providing those functions via PTI, why would it suddenly stop running the protocols/numbers IANA simply because the names root registry was no longer using PTI? Wouldn’t it still be obligated to provide those functions as much as it is obligated now under RFC 2860? How would that obligation change simply because the names IANA functions went somewhere else?
My understanding is that ICANN can also cancel the MoU with IETF, with 60 days’ notice. This could happen whether or not there is a PTI, whether or not the protocol functions are moved to PTI, whether or not names pulls out of PTI in the future. So I fail to see how the reorg of IANA under a PTI affiliate, or any choice of a new operator by the names community, has serious ramifications for the future supply of the protocol functions. If there are political or economic factors pushing ICANN away from its support for IETF, those exist, or not, independently of the PTI structure.
Thus, if the wariness about PTI’s role in protocol IANA functions stems from the concerns I have outlined above, that wariness needs to go away. As Andrew Sullivan famously said in his rug-lifting screed: IETF really doesn’t have autonomy required to shift the functions until and unless it is able to self-support them. That may be a hard problem for IETF, but it is not caused by the PTI structure, nor will it be solved by fiddling with the structures proposed by the names community to solve their problems.
--MM

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 May 2015 12:17:19 +1200

On 20/05/2015 03:18, Milton L Mueller wrote:

<snip>

> However, no matter where the names community locates itself on that spectrum, PTI is still "meaningfully" separated from ICANN. The assets and staff and operations management of PTI would have been…

I've been mulling over the implications of this. Either PTI will be
controlled by ICANN or it won't. If it *is* effectively controlled
by ICANN, the IETF can sit back and relax until our SLA is no longer
met, in which case we go to Plan B (i.e. no change in the state that
has existed for 15 years).

If PTI is *not* effectively controlled by ICANN, we are straight
into Plan B: giving notice to ICANN and bidding out a protocol
parameter services contract, with PTI as an obvious bidder,
hopefully at zero cost. (I would seriously expect several zero-
cost bids to show up.)

What does 'effectively controlled' mean? I think it's an empirical
question. As a counter-example, Ports of Auckland is wholly owned
by Auckland Council Investments Limited, itself owned by the
Auckland Council. But Ports of Auckland prefers to ignore
the wishes of the community* that elected Auckland Council when
it suits their commercial interests. This is a direct result of
the transition from the port being in public ownership to being
semi-privatized.

  Brian

* if you're interested:
http://pilot.stuff.co.nz/business/industries/67454039/famous-aucklanders-protest-port-extension

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 20 May 2015 13:14:25 +0000

> I've been mulling over the implications of this. Either PTI will be controlled
> by ICANN or it won't. If it *is* effectively controlled by ICANN, the IETF can
> sit back and relax until our SLA is no longer met, in which case we go to Plan
> B (i.e. no change in the state that has existed for 15 years).
> 
> If PTI is *not* effectively controlled by ICANN, we are straight into Plan B:
> giving notice to ICANN and bidding out a protocol parameter services
> contract, with PTI as an obvious bidder, hopefully at zero cost. (I would
> seriously expect several zero- cost bids to show up.)

Given current and past history, I am surprised that you find control by ICANN, as opposed to control by a more focused and independent PTI board that could, e.g., contain members from ICANN, ASO and IETF, so comfortable and secure. (Remember this would be a "new" ICANN unsupervised by NTIA). But if you really feel that way and have considered all the ramifications of various governance models for PTI, then by all means file comments in the proceeding saying so. That would be relevant input, assuming you had good reasons for your preference.

> What does 'effectively controlled' mean? I think it's an empirical question. As
> a counter-example, Ports of Auckland is wholly owned by Auckland Council
> Investments Limited, itself owned by the Auckland Council. But Ports of
> Auckland prefers to ignore the wishes of the community* that elected
> Auckland Council when it suits their commercial interests. This is a direct
> result of the transition from the port being in public ownership to being
> semi-privatized.

That is one of the reasons many of us favor incorporating PTI as a California Nonprofit Public Benefit Corp. 
The law under which PBCs are incorporated contain a lot of protections against commercial expropriation.  You can find discussion of this issue here: http://www.internetgovernance.org/2015/05/18/why-the-post-transition-iana-should-be-a-nonprofit-public-benefit-corporation/

In terms of what "control" means, there are various options on the table. A PTI incorporated as a PBC with a board the majority of which is not appointed by ICANN is the most independent option. A PTI inc as a PBC with a board appointed by ICANN but the selections governed by preset rules (e.g., you must appoint someone from IETF, someone from ASO, someone from names) is a slightly less independent option. A PTI with a so-called "insider" board, directly appointed by ICANN, including just ICANN staff members, is not independent at all. A PTI incorporated as a Delaware LLC is the least independent and the most susceptible to control and manipulation by ICANN unless strong protections are negotiated into the management agreement.

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 May 2015 14:08:44 -0400

Brian,

A quick comment on this analysis only:

--On Wednesday, May 20, 2015 12:17 +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> I've been mulling over the implications of this. Either PTI
> will be controlled by ICANN or it won't. If it *is*
> effectively controlled by ICANN, the IETF can sit back and
> relax until our SLA is no longer met, in which case we go to
> Plan B (i.e. no change in the state that has existed for 15
> years).
> 
> If PTI is *not* effectively controlled by ICANN, we are
> straight into Plan B: giving notice to ICANN and bidding out a
> protocol parameter services contract, with PTI as an obvious
> bidder, hopefully at zero cost. (I would seriously expect
> several zero- cost bids to show up.)

The difficulty with "Plan B" is that the costs to the IETF and
the IETF's user community, or invoking it and making some sort
of transfer would be considerable and disruptive.  Good planning
and cooperation from ICANN (or PTI or some other current
operator) could significant reduce that pain, but not either
eliminate it or reduce it to something trivial.  As a result
"SLA is no longer met" is less like to be a simple binary
decision but a collection of evaluations and tradeoffs about
whether things are sufficiently out of hand, or showing enough
of a patter of deterioration, to justify making that move.  

Even if PTI were, by your definition, not controlled by ICANN,
under most scenarios I'd assume the position of the IETF/IAOC
would be to stick with PTI-IANA unless (or until) something went
seriously wrong.  Making a change just because the
organizational structure changes seems to me unlikely in
practice (I note that neither of us would be part of making the
decision other than as members of the community so there are no
commitments in that prediction).   

In either case, the IETF community would need to evaluate costs
and risks of the scenario.  I don't believe that PTI implies
enough advantages for us (or anyone else) to justify that
investment.   Milton doesn't believe that is a legitimate reason
for not going ahead.  And that leaved us at a little bit of an
impasse that your analysis does not address.

   john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 May 2015 08:26:39 +1200

Excuse front posting, but I just want to say that John is correct;
of course Plan B would be neither desirable nor smooth sailing, but there
are circumstances in which it would be the IETF's only choice.

Regards
   Brian

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 May 2015 16:49:41 -0400

--On Thursday, May 21, 2015 08:26 +1200 Brian E Carpenter
<[email-masked]> wrote:

> Excuse front posting, but I just want to say that John is
> correct; of course Plan B would be neither desirable nor
> smooth sailing, but there are circumstances in which it would
> be the IETF's only choice.

Brian,

Thanks is exactly what I'm trying to tease out.  I don't think
we would (or at least should) wait until it is our only choice.
I also don't think we should make that move simply because of
the possibility of a problem.  If we were to do it on the basis
of a possibility, we would have abandoned the ICANN-managed IANA
long ago.   There is a fairly wide range between "possibility of
a problem" and "only choice" about which I hope and assume that
we would continue to be careful, thoughtful, and sensible.

However, to the extent that injecting a new organization and
management structure into the system (in the form of PTI)
increases complexity or uncertainty, it pushes us some distance
along that range, with various sorts of control arrangements
influencing the distance.  And, to the degree to which the IETF
exercising "plan B" would be destabilizing (however temporarily)
of the IETF relationship with the protocol registries, those
registries themselves, or PTI, that is, itself, a reason to not
move in the PTI direction without a clear picture of the problem
it is trying to solve and how that solution would lower
instability risks overall.

    john

---

From: Christian Huitema <[email-masked]>
Date: Wed, 20 May 2015 21:11:31 +0000

> However, to the extent that injecting a new organization and management
> structure into the system (in the form of PTI) increases complexity or
> uncertainty, it pushes us some distance along that range, with various sorts of
> control arrangements influencing the distance.  And, to the degree to which the
> IETF exercising "plan B" would be destabilizing (however temporarily) of the
> IETF relationship with the protocol registries, those registries themselves, or PTI,
> that is, itself, a reason to not move in the PTI direction without a clear picture of
> the problem it is trying to solve and how that solution would lower instability
> risks overall.

There is an underlying question: would the system be less stable if protocols numbers, IP addresses, and domain names were managed by three different structures? Or would it be more stable? Personally, I am not sure. Having system concentrated creates a concentration of power that increases risks for abuse. Having the system separate might increase risks that separate functions may be challenged by wannabe authorities. I am somewhat more worried about the abuse part, but what do I know?

-- Christian Huitema

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 20 May 2015 21:53:21 +0000

> There is an underlying question: would the system be less stable if
> protocols numbers, IP addresses, and domain names were managed
> by three different structures? Or would it be more stable? 

That is the right question. 

Although not all comments are in yet, it looks like the concept of a legally separate PTI has sufficient support from the names community to become part of the plan (indeed, the most salient dissents are calling for more separation, not less). And it's also clear that numbers community is not objecting to this structure and does not see any risk in it, though they have made it clear that they want to continue to contract directly with ICANN.

This means that comments questioning "what problem PTI is trying to solve" or "whether we should move in the PTI direction" are quite misdirected. We are not discussing whether PTI will happen, but whether IETF will choose to secede from it. 

To put the question more bluntly: 

Does IETF want to add to the transition a new process of extracting itself from the current IANA department and leaving the protocols registry as a stand-alone service within ICANN? 

Or does it want the protocols functions to move with the names and number functions into PTI? 

That's the real choice. 

How anyone can portray the first option as less destabilizing than the second, is beyond me. I view the second one as simpler. I hope no one at this point is pretending that the status quo ante is an option. It isn't. 

> Having system concentrated creates a concentration of
> power that increases risks for abuse. 

Remember that while all three functions might be provided by the same organization, each community would have its own distinct contract for those functions. In that respect there is a pretty powerful check/balance in place against abuse of concentrated power. Furthermore, extracting the supply of the IANA functions from an organization that is overwhelmingly dominated by the money and politics of names policy development is also a step in the direction of less concentration of power.

---

From: Ted Hardie <[email-masked]>
Date: Wed, 20 May 2015 15:50:54 -0700

On Wed, May 20, 2015 at 2:53 PM, Milton L Mueller <[email-masked]> wrote:

> Although not all comments are in yet, it looks like the concept of a
> legally separate PTI has sufficient support from the names community to
> become part of the plan (indeed, the most salient dissents are calling for
> more separation, not less). And it's also clear that numbers community is
> not objecting to this structure and does not see any risk in it, though
> they have made it clear that they want to continue to contract directly
> with ICANN.
>
>
​Your statement is not clear.  Are you saying that the numbers community is
not objecting to this structure for the names community and does not see
any risk in that community choosing that for its use?  Given that they have
made it clear they wish to contract directly with ICANN, this seems a
logical inference, but it is not clear that it is the one you have drawn.​

> This means that comments questioning "what problem PTI is trying to solve"
> or "whether we should move in the PTI direction" are quite misdirected. We
> are not discussing whether PTI will happen, but whether IETF will choose to
> secede from it.
>
>
​That is a very curious idea of secession.  The IETF community came to
consensus on a document that was completed prior to the PTI proposal being
made.  Having the IETF community continue to contract with ICANN is not
secession.​

> Does IETF want to add to the transition a new process of extracting itself
> from the current IANA department and leaving the protocols registry as a
> stand-alone service within ICANN?
>
>
​This may be blunt, but it is also wrong.  The IETF has declared itself
satisfied with the work of  IANA and contracting with ICANN for the
relevant SLAs.  We are not adding anything to the transition by keeping
that set of arrangements.

That's the real choice.
>
> How anyone can portray the first option as less destabilizing than the
> second, is beyond me. I view the second one as simpler. I hope no one at
> this point is pretending that the status quo ante is an option. It isn't.
>
>
​The *status quo ante* needs ​a time reference to be sensible.  *ante *the
decision of the NTIA to solicit proposals?  *ante* the publication of the
IANAPLAN and CRISP documents?  *ante* the decision of the names community
to propose PTI?

Ted

> Remember that while all three functions might be provided by the same
> organization, each community would have its own distinct contract for those
> functions. In that respect there is a pretty powerful check/balance in
> place against abuse of concentrated power. Furthermore, extracting the
> supply of the IANA functions from an organization that is overwhelmingly
> dominated by the money and politics of names policy development is also a
> step in the direction of less concentration of power.
>

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 May 2015 00:18:36 +0000

Hi,

> This means that comments questioning "what problem PTI is trying to solve" or "whether we should move in the PTI direction" are quite misdirected. We are not discussing whether PTI will happen, but…

I don't understand how that is a helpful position to take.  People
asking, "What problem is this trying to solve?" and, "Should we move
in that direction?" are not doing that for the fun of it.  Most of us
don't have a professional interest in governance models _qua_
governance model, though I am aware that at least one of us does.

Instead, they are asking perfectly reasonable clarifying questions --
reasonable partly because the CWG released for public comment a
proposal that was _in its own admission_ (indeed, stated in the text
itself) full of incomplete answers, and unsettled and controversial
issues.  It's hardly surprising that people should ask the sorts of
questions they're asking.  

> Or does it want the protocols functions to move with the names and number functions into PTI? 

It's not the "real choice"; in fact it's a false alternative.  It
seems to me that, without quite a lot of additional detail, it's more
or less impossible to know whether it would be better to continue the
MoU with ICANN, or to undertake a new agreement with a PTI, or to
initiate a completely new arrangement including an RFP process, or
just to take the entire thing over and bring it back inside the IETF.
None of that should be news to you, since I in fact made similar
arguments on the CWG list quite some time ago.

And none of this answers the question, either, of what the correct
long-term arrangement ought to be.  Given the terrible lack of detail,
it's entirely possible that whatever the PTI arrangements end up being
will be unstable and poorly-suited to the long term health of the
relevant registries, even if they are perfectly servicable and useful
for the purposes of transition.  As I've said repeatedly in the CWG
context, we had better be assuming that the arrangement can be altered
again in the future if such needs turn up.  If it cannot, then that
suggests we're doing it wrong.  Practical arrangements should never be
so brittle.

Best regards,

A

-- 
--
Andrew Sullivan
[email-masked]
Awkward access to mail.  Please forgive formatting problems.

---

From: John C Klensin <[email-masked]>
Date: Wed, 20 May 2015 23:10:20 -0400

--On Wednesday, May 20, 2015 21:53 +0000 Milton L Mueller
<[email-masked]> wrote:

>...
> This means that comments questioning "what problem PTI is
> trying to solve" or "whether we should move in the PTI
> direction" are quite misdirected. We are not discussing
> whether PTI will happen, but whether IETF will choose to
> secede from it. 
> 
> Does IETF want to add to the transition a new process of
> extracting itself from the current IANA department and leaving
> the protocols registry as a stand-alone service within ICANN? 
>...

Milton, it seems to me that the way you are characterizing the
situation brings us perilously close to a situation in which the
names community will block any transition in which the PTI,
defined however the names community decides to define it, is not
the main element.  My understanding of the charge from NTIA is
that all of the relevant communities need to reach consensus on
a single plan for their to be a transition.  From my point of
view, proposals/positions from the protocol and numbers
community were put on the table and both of those groups
concluded that their proposals were compatible.  Those proposals
also made minimal changes to the existing system and, at least
IMO, explained and justified the changes they did want to make.
Then the names community (or at least the CWG) comes along with
a proposal with big gaps, large changes, and little explanation
or rationale and they (or at least you) say "accept PTI or no
transition" and tell the IETF community what questions we are
allowed to ask and that, because PTI is a done deal, our only
option is to secede.

Speaking again for myself only, I don't see it that way.   What
I do see is a demonstration of a concern that a few of us have
had for some time -- the possibility that, freed of external
oversight, portions of the names community would make decisions
about what is in their best interest without much regard for
other needs or the opinions of other communities (except
possibly in the form of the names community's opinion of what
those communities should want and need) and then, because of the
way ICANN is structured, impose their view on everyone else.  

If that is where we are then, again from my point of view, we
are conclusively demonstrating that we are not ready for a
transition that removes external oversight (whether via NTIA or
otherwise) and that conclusion is largely independent of whether
the IETF and/or numbers community agree to whatever the PTI
model turns out to be.

I think that would be very sad.

   best,
     john

---

From: John Curran <[email-masked]>
Date: Thu, 21 May 2015 06:08:23 -0400

> way ICANN is structured, impose their view on everyone else.  

John - The CWG draft was posted for public comment, and the IETF was specifically asked 
by the ICG to consider it and provide feedback on implications to the protocol community…  
As a result, it’s fairly difficult to characterize the CWG efforts as being done "without much 
regard for other needs or the opinions of other communities”   (In fact, if it were not for the 
"IAB IANA Evolution Program” filing of its comment, it would be relatively straightforward to 
characterize the IETF as the party that is the one that was not considering the needs of the 
other communities…)

The CWG plan is not a work of art, and certainly not how most of us would go about solving
their particular accountability conundrum. It is, however, the result of an enormous amount
of effort by the names community, and the IETF was not being asked to judge the rationale 
for their proposed changes (as you seem so anxious to do), but to consider the associated
implications of the changes for the protocol community and comment accordingly.   If you 
should happen to see someone from the “IAB IANA Evolution Program”, you might want to 
thank them for recognizing this and getting the actual job done (at least from the perspective
of one portion of the IETF community.)

Thanks,
/John

---

From: Avri Doria <[email-masked]>
Date: Thu, 21 May 2015 15:43:26 +0200

Hi,

Since I participate so heavily in the work of CWG Transition in ICANN,
while I follow this list, I normally keep my mouth shut even though I
consider myself a part of the IETf community as well..  In this case I
wanted to try and answer two questions from my perspective while wearing
an ICANN hat.

On 21-May-15 02:18, Andrew Sullivan wrote:
> "What problem is this trying to solve?" 

It is becasue we in ICANN wanted what  IETF has: a contract with ICANN
that would allow us to part company if things started to go really sour.

But as part of ICANN, we could not simply have a contract with ICANN. 
Names needed to find a way to have that legal separation that the IETF 
naturally has.   We went through several ideas, including a brief
flirtation with Names seceding from ICANN, but the PTI solution we have
now put under review  seems the best fit for Names. The PTI  is a
compromise between those who wanted to leave everything as it was, with
perhaps more accountability, and those who wanted to form a completely
separate organization. 

PTI is the way Names gets a contract and gets to define an SLA.  For us
that solves a big problem.

> and, "Should we move
> in that direction?"

No need for you to do so.

IETF has a contract with ICANN, they treat you well enough, and you seem
happy for the most part.  Given all of that, why bother moving in this
direction.  Stick with your contract.  In designing the solution we made
sure that for Numbers and Protocols everything could remain in the
status quo.

Certainly some of us hoped you might consider it because we thought it
might be better for the Internet if you did join us in the PTI and thus
joined us in direct oversight of the IANA functions operator.  It seemed
to some of us that an organization like the PTI  anchored in the three
organizations would be less susceptible to ICANN capriciousness
(something we experience much more than you do).  With 3 organizations
overseeing the PTI, we figured it would be certain that there would be
no policy shenanigans and it would be guaranteed 3 times over that IANA
stuck to its knitting. But given the separation amongst the 3
operational communities, this was no more than a hope.

The IETF will still have its contract with ICANN and will have the same
degree of control over ICANN and IANA it has now.  Our proposal  may
invite you to send liaisons for various things but only because we
respect your viewpoint.  But you don't need to send liaisons if you
don't want to.  Does not affect the solution we propose at all.

As far as i can tell, and I have spent a lot of time on this proposal,
IETF does not have to change anything it does not want to change.  And
if it doesn't change anything, things will remain for IETF as they are now.

As someone wearing an ICANN hat in this process I see no reasn why you
should move in our direction.  But the door remains open, at least
through the transition. so you may if you so decide.

avri

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

---

From: John C Klensin <[email-masked]>
Date: Thu, 21 May 2015 09:47:19 -0400

--On Thursday, May 21, 2015 06:08 -0400 John Curran
<[email-masked]> wrote:

> John - The CWG draft was posted for public comment, and the
> IETF was specifically asked  by the ICG to consider it and
> provide feedback on implications to the protocol community…  
> As a result, it's fairly difficult to characterize the CWG
> efforts as being done "without much  regard for other needs or
> the opinions of other communities"   (In fact, if it were
> not for the  "IAB IANA Evolution Program" filing of its
> comment, it would be relatively straightforward to 
> characterize the IETF as the party that is the one that was
> not considering the needs of the  other communities…)
>...

I should have been more precise.  I am more concerned about
Milton's "take it or leave it" responses and some related
remarks than I am the CWG process and its outputs.  I remain
concerned about the latter for three significant reasons: 

(1) The broader community (including the IETF) has been asked to
review and comment on a report/proposal that is extremely
incomplete in areas that are important to some of us.  Even had
the CWG asked other groups to make suggestions about what should
be filled into those blanks, the timing of the request and
comment cutoff yesterday made it impossible to have a competent
discussion of those subjects, generate proposals, and reach
consensus about them.

(2) While I recognize that everyone is operating under time
pressure and that the CWG proposal is already far later than
originally expected, I see any changes that do more than update
the status quo (or status quo before the transition discussions
started) as involving costs and risks to the community.  I see
the proposal from you and your colleagues to establish an SLA
model similar to the IETF one as fairly low-risk in that regard.
It is, IMO, a small update, the approach has been established
and demonstrated for some years by the IETF, and, again at least
from my perspective, the address community really is a community
with a history of being able to work and act together.  By
contrast, PTI is a new idea, with details still incomplete and
no community experience with, e.g., ICANN creating and relating
to a subsidiary "affiliate" and how that would work out.  To
guess at how (or if) it might work out and to assess the
practical risks, understanding the motivation for it --more
precisely described as "what problem are you trying to solve and
why do you think this solves it" -- is essential.  It might be
less important were there no important missing pieces in the CWG
proposal, but those pieces _are_ important and "what problem are
you trying to solve" is also useful for guessing how they might
be filled in and what criteria the CWG (and the names community
more broadly) might think they have to meet.  So I think those
questions are legitimate and, indeed, important.

(3) Finally, there are multiple examples of various ICANN groups
producing documents and proposals, asking for public comments on
them, getting (and counting) comments, and then, as far as can
be determined from the outside, essentially ignoring the content
and recommendations in those comments.  At least from my point
of view, part of that same picture involves giving particular
groups very narrow scope and treating any comments, concerns, or
suggestions that go beyond those scopes to, e.g., challenge
assumptions, as unacceptable and irrelevant.  I have no reason
to believe that the CWG intends to follow those patterns but,
given that the community that the CWG represents has tolerated
that behavior within ICANN, it is reasonable to view their
posting a draft for public comment and asking for input less
conclusively than your comment above seems to suggest (a view
that is, again, supported by Milton's comments and the absence
of comments from other CWG members rejecting or qualifying his
apparent position).

> The CWG plan is not a work of art, and certainly not how most
> of us would go about solving their particular accountability
> conundrum. It is, however, the result of an enormous amount of
> effort by the names community, and the IETF was not being
> asked to judge the rationale  for their proposed changes (as
> you seem so anxious to do), but to consider the associated
> implications of the changes for the protocol community and
> comment accordingly. 

Again, especially because the plan is incomplete, I don't
understand how we can evaluate it, and especially the associated
risks and costs, without understanding "their particular
accountability conundrum" and/or "the rationale for their
proposed changes".   Without either of those two kinds of
information, I do have an opinion about impact and risks to the
IETF, and have expressed it before, I think in my first note on
the subject: this is too complex, it introduces new risks of
non-transparent behavior that may be accountable to small groups
but is not even as accountable to the broader community as
ICANN's operation of IANA is today, and therefore should not be
considered acceptable.   More details about structure, controls,
and motivation might allay those concerns, but the details are
not present.

> If you  should happen to see someone
> from the "IAB IANA Evolution Program", you might want to 
> thank them for recognizing this and getting the actual job
> done (at least from the perspective of one portion of the IETF
> community.)

https://www.iab.org/activities/programs/iana-evolution-program/

best,
    john

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 May 2015 14:51:35 +0100

On 20/05/15 22:53, Milton L Mueller wrote:
> Does IETF want to add to the transition a new process of extracting
> itself from the current IANA department and leaving the protocols
> registry as a stand-alone service within ICANN?
> 

IMO that's an overstated false dichotomy but no surprise
having read previous mails from Milton in this thread. At
least for me, when I see that kind of thing it decreases
the extent to which I take seriously anything the same author
utters.

That makes it hard to evaluate this thread though since it
seems Milton is the main (only?) one arguing that the IETF
ought pay more attention to the PTI idea. And he is by far
the most vociferous.

So I'd be interested in hearing from other folks who agree
with what might be the position Milton has (after all the
overstatement is discounted:-). Or who think that the IETF
ought do something directly involving the PTI (e.g. to
re-open the MoU to change the partner involved or something.)

In the meantime, I'm not at all convinced the IETF needs to
do anything different. We may want to re-iterate that the
WG consensus isn't affected by the PTI proposal maybe.

S.

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 May 2015 17:00:04 +0300

> I don’t think it makes sense for the IETF to have a seat on the PTI board. The IAB can continue to exercise its oversight over the registry operator’s performance of the protocol parameters functio…

I just wanted to say that I agree with Alissa on all of the above. Thanks.

Jari

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 21 May 2015 14:04:12 +0000

> re-open the MoU to change the partner involved or something.)

I don't know that Avri's message actually meets those criteria, but it
is in my opinion the clearest and best statement of the argument in
this thread as to why the IETF might want to get involved in PTI
directly.  (I, for one, appreciated it.)

A

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 May 2015 15:09:49 +0100

> directly.  (I, for one, appreciated it.)

I also read Avri's message but she didn't seem to be arguing
that we ought do any specific thing now. And when I read that
I mostly thought: "hmm, sounds like we should let the CWG thing
play out and if a PTI is setup we should see how that pans
out and in the meantime, doing nothing (for the IETF) seems
right."

S.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 21 May 2015 17:22:00 +0300

Hi,

> On May 21, 2015, at 12:11 AM, Christian Huitema <[email-masked]> wrote:
> 

Stepping back a bit and speaking for myself.

Independent for how the IANA function is implemented, that is the PTI, the way it is now (a department in ICANN), or something else, there are still three separate functions.  These are of course, the IETF (for the protocol parameters), the RIRs (for addresses), and the ICANN naming communities (CCTLDs and TLDs for DNS names).  These three functions will not be combined.  This discussion is only about how the IANA is structured.

My personal take on the names community proposal that includes the PTI, is that they want a degree of separation of the DNS naming functions in ICANN in an analogous way that the IETF and RIRs have today for the protocol parameters and addresses.  I don’t think the naming community has this now and they would like to see more separation of policy and oversight.  I conclude they think that the PTI will achieve this.  If they are happy with this approach, then I am fine with it and think we can move forward.

I don’t see any reason why at this point in time the IETF and RIRs should not continue to have agreements with ICANN.  The PTI will be under ICANN (as a separate entity, with oversight from the ICANN board).  The ultimate responsibility will remain with ICANN.  If the PTI breaks in some way, it will be ICANNs responsibility to fix it.  As we know more about how the PTI is structured, it’s bylaws, etc., etc., that could change.

Or to say it another way using the IETF as an example, the IESG will interact with an email address like <[email-masked]> and as long as the people behind that are responsive and meet the conditions in the IETF MOU and SLA with ICANN, then all is fine.  If the implementation is in the PTI or an ICANN department, it won’t matter to the IETF.  The interface is the same, so to speak.

Bob

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 21 May 2015 15:18:06 +0000

Your statement is not clear.  Are you saying that the numbers community is not objecting to this structure for the names community and does not see any risk in that community choosing that for its use?

MM: Yes, I am saying that. But I am also saying that the RIRs have expressed no fears about or objections to the numbers functions being provided by the new legal entity (PTI), as long as they can contract with ICANN (a known entity).

That is a very curious idea of secession.  The IETF community came to consensus on a document that was completed prior to the PTI proposal being made.  Having the IETF community continue to contract with ICANN is not secession.​

MM: Agreed, having the IETF community continue to contract with ICANN is not secession. It’s perfectly understandable and reasonable for IETF to want to continue that. And indeed that is what the numbers people are proposing too. You just need to understand that while you will contract with ICANN, ICANN could fulfill that contract via PTI.

It is “secession” – more accurately, a split - if IETF insists that protocol functions of IANA remain inside ICANN when all the other functions are moving into PTI. That is the issue I was addressing. I hope that distinction is clear now.

The various objectives and benefits of creating PTI for names are fully explained in countless documents from the CWG, including professional legal analyses of the advantages and disadvantages.

I’ve engaged in this debate only because I am concerned that objections to PTI may lead to splitting the IANA functions into separate provider entities, one inside ICANN and the other one outside. This imho would be an added complication in the transition process, a bit more disruptive than simply letting them stay together in PTI. And in terms of the overall environment surrounding ICANN, I think it’s better to get all IANA functions out of the DNS policy making entity. But of course it’s IETF’s call. I just hope that the call is not made based on misconceptions of what PTI is and what the options are.

--MM

---

From: John Curran <[email-masked]>
Date: Thu, 21 May 2015 11:33:46 -0400

On May 21, 2015, at 9:47 AM, John C Klensin <[email-masked]> wrote:
> ...
>  Without either of those two kinds of
> considered acceptable.  

John -

You do not consider IETF's MOU for IANA services sufficient to 
mitigate the risks associated with the CWG proposal? It would 
be very useful for this community to understand what risks you 
believe are not addressed by the present RFC 2860 MOU...

Thanks!
/John

Disclaimer: my views alone

---

From: "Lynn St.Amour" <[email-masked]>
Date: Thu, 21 May 2015 12:26:33 -0400

Following all this between IGF MAG discussions, so apologies for the brevity and any directness.    Also, followed this format as I have only had brief moments and needed it to retain my thought process (hope it flows :-) ).

Many of the postings on this thread seem to assume unfavorable conditions for the PTI/PTI Board, etc.   That is because the Names community has not had time to complete all their work..  I think we can help them advance their work, which frankly is our work as well, and is in the interest of a global public Internet.

Here are my working assumptions, please correct them if they are off the mark.  They are obviously missing lots of detail.

1 - We support (as good practice) separation between policy, oversight, and implementation for the 3 components of the IANA function (in each of the 3 areas - the so-called 3x3)
2 - Protocol Parameters has this (and btw, this PTI proposal was modeled heavily on the IETF)
3 - Numbers also largely has this.
4 - The Names community is trying to get to this.
5 - There is a preference for the 3 IANA functions to stay together at the IMPLEMENTATION role (only), but it is not seen as necessary from any of the operating communities (OC's).

More specific to the CWG proposal:

A - The PTI would be a narrow purposed organization built to house only the IANA IMPLEMENTATION functions (preferably for all three operating communities?, and I believe the IETF and RIR's assume the work would be done within the PTI *if* that structure goes forward (that is the IANA staff would be housed within the PTI even while their contracts may remain with ICANN).    This should be clarified as soon as their processes allow, as this seems to be one of the points of confusion.  
B - The PTI would have its own board and would be responsible for the PTI  (many models to accomplish this - even with the funding considerations)
C - The PTI Board need not have a majority of ICANN Board members - this is the current discussion within Names about ‘inside’ and ‘outside'.   The options would allow, I believe, for a full spectrum of:  no special role for ICANN to a strong central role for ICANN.   

I believe the Names community would appreciate input/specific questions from the IETF - and I believe it would be useful to all of us if we could look at the proposal and see what we might be able to live with (or not be able to live with).  Either way we advance the discussion if we can share some concrete questions/preferences.   If we identify too many hurdles, well at least we can be specific on why it won't work for us, and again that will help the OC's and the ICG to advance the transition proposal.  For example, could the IETF identify some preferences re Board composition/by-laws/policies, etc.  Frankly, I can see some benefits to working with a purpose built PTI vs. the full-bodied ICANN :-) . 

If the 3 operating communities could come to agreement on how the proposals fit together, it would help advance the Transition proposal work significantly - for the OC's as well as the ICG.  

Must run, hope this is helpful.

Lynn

---

From: "Lynn St.Amour" <[email-masked]>
Date: Thu, 21 May 2015 17:32:27 -0400

Please see below the ICANN Board response to the CWG request for public comment.  All in all, I think this is a very good start for future discussions, the response clearly opens the door for continued dialogue and accommodations.

http://forum.icann.org/lists/comments-cwg-stewardship-draft-proposal-22apr15/msg00038.html

Other responses to their request for public comment can be found at:  http://forum.icann.org/lists/comments-cwg-stewardship-draft-proposal-22apr15/

Best,
Lynn

---

From: Grace Abuhamad <[email-masked]>
Date: Thu, 21 May 2015 22:02:54 +0000

Thanks for sharing Lynn. We¹ve also set up a file share on the
CWG-Stewardship Wiki so that you can download all the submissions in one
click : <https://community.icann.org/pages/viewpage.action?pageId=53776547>

Best, 
Grace

On 5/21/15, 5:32 PM, "Lynn St.Amour" <[email-masked]> wrote:

>Please see below the ICANN Board response to the CWG request for public
>comment.  All in all, I think this is a very good start for future
>discussions, the response clearly opens the door for continued dialogue
>and accommodations.
>
>Other responses to their request for public comment can be found at:
>http://forum.icann.org/lists/comments-cwg-stewardship-draft-proposal-22apr
>15/
>
>Best,
>Lynn
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 May 2015 15:54:28 +1200

> believe are not addressed by the present RFC 2860 MOU...

I definitely can't speak for John, but empirically, if some new
structure under ICANN can continue the good technical service we
get today under that MoU (and the subsequent additional IETF/ICANN
agreements), we should be happy and the IANAPLAN consensus should
stand. How ICANN organizes and delegates the work isn't our business,
*except* that we need the excellent direct contact with the actual
IANA staff that we have today. I think that's what Stephen Farrell,
Bob Hinden and Avri Doria said too.

But for me at least it is an empirical question; details of
Californian corporation law are remarkably uninteresting.

John Klensin, I suspect, is concerned about the risk that the future
service would fail the empirical test as a result of the proposed
changes. That's clearly a valid concern.

    Brian

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 22 May 2015 18:52:51 +0900

Of all the contributors so far, Bob has expressed in the clearest way 
and I very much agree with him.

Regards,   Martin.

---

From: John Curran <[email-masked]>
Date: Fri, 22 May 2015 07:23:09 -0400

> that would allow us to part company if things started to go really sour.

That’s not the only thing that a contract provides…  it also provides a way 
of setting clear expectations of satisfactory performance & service levels
as viewed by the contracting party

> flirtation with Names seceding from ICANN,  

(which in theory would have been a cleaner approach, but in practice is
quite challenging given the history of ICANN and expectations from the
IANA stewardship transition process)

> … but the PTI solution we have
> joined us in direct oversight of the IANA functions operator.

If the PTI is just performing registry operations services for three communities
under three contracts, then contractual oversight exists and is quite strong…
One wonders why it is necessary to be part of corporate oversight of PTI if
indeed the contractual provisions are properly defined.

>  It seemed
> (something we experience much more than you do).  

Isn’t the ICANN’s accountability to the community being already addressed 
via the CCWG efforts?

> With 3 organizations

I could see binding PTI via its incorporation/structure to some very basic
principles related to operations of the IANA registry operations, e.g. the
principles in RFC 7500.  Such could also include strong language to the
effect that PTI is only to perform registry operations and not registry policy 
development, that it will operate IANA registries under contract to parties
which represent the affected communities, and that in administration of 
the registries, it will follow the policy adopted by those communities.

These sorts of conditions are factual in nature, and mirror provisions that
are already expected in the various IANA registry service agreements.
(whereas having PTI take on any additional roles or adhere to any other
non-core IANA registry principles simply creates conditions whereby the 
PTI board “oversight” that you seek could result in conflict between PTI and 
contracting community in terms of what is proper IANA registry operations - 
you may see that as a feature but to me it looks to be introduction of noise
into the system…)

/John

p.s. my views alone.  To my knowledge, neither the ARIN Board nor community 
has considered this matter and/or established any position in same.

---

From: John C Klensin <[email-masked]>
Date: Fri, 22 May 2015 11:32:25 -0400

--On Friday, May 22, 2015 15:54 +1200 Brian E Carpenter
<[email-masked]> wrote:

>> You do not consider IETF's MOU for IANA services sufficient
>> to  mitigate the risks associated with the CWG proposal? It
>> would  be very useful for this community to understand what
>> risks you  believe are not addressed by the present RFC 2860
>> MOU...
> 
> structure under ICANN can continue the good technical service
> we get today under that MoU (and the subsequent additional
> IETF/ICANN agreements), we should be happy and the IANAPLAN
> consensus should stand. How ICANN organizes and delegates the
> work isn't our business, *except* that we need the excellent
> direct contact with the actual IANA staff that we have today.
> I think that's what Stephen Farrell, Bob Hinden and Avri Doria
> said too.

Yes.

Since my comments seem to be confusing people, let me try this a
different way.  I am much more interested in behavior than I am
in organizational models.  The latter are important only insofar
as they either encourage or retard behavior.   If one assumes
that everyone shares just about the same objectives and
priorities, that everyone is acting in good faith, and that
everything will [therefore?] go smoothly (and that any small
glitches will be swiftly resolved by people working together),
then PTI is probably unnecessary and violates my instinctive
sense that complexity should be avoided when possible, but, if
it makes the names community more comfortable, I'm all for it.

My concerns arise when I start working through cases of what
could go wrong and various scenarios about how issues might be
resolved and resolved swiftly and efficiently.  There, unless
everyone is working together and doing so smoothly and
comfortably (so much so that the formal structures are basically
ignored), the mere presence of an additional semi-separate
organization could turn "would you, as the individual in the
critical path, please get this fixed" into "would you, as
organization 1, please ask organization 2 politely if they would
please ask the right person to get this fixed".  Even if one
assumes that the fix will be forthcoming, the delay by playing
procedural relay could be painful, especially if formal actions
are required at any stage in the process. 

If goals and priorities ended up being different in those
situations,  things could get worse.

> Californian corporation law are remarkably uninteresting.

Yes, and see the comment about behavior rather than structures
above.
 
> John Klensin, I suspect, is concerned about the risk that the
> future service would fail the empirical test as a result of
> the proposed changes. That's clearly a valid concern.

Again, yes and see above.   I also have little or no concern
about what would happen in the months following the transition,
when everyone is more or less on the same page.  The practical
concerns rise over time, especially if (or when) ICANN's
management or economics change and people start struggling over
resources or priorities.

    john

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 22 May 2015 15:56:13 +0000

Yes, the board has accepted (somewhat reluctantly, but still...) the idea of a separate legal entity, although it is very concerned about how it can control it. 
I agree with Lynn that this is a "good thing" because it means that CWG needn't continue debating models but can start fleshing out the details of the model. This has very significant implications for the CWG timeline. It means it is still moving forward rather than backwards.

--MM

> From: Ianaplan [mailto:[email-masked]] On Behalf Of Lynn
> St.Amour
> Sent: Thursday, May 21, 2015 5:32 PM
> To: [email-masked]
> Subject: [Ianaplan] ICANN Board response to the CWG draft for public
> comment
> 
> Please see below the ICANN Board response to the CWG request for
> public comment.  All in all, I think this is a very good start for future
> discussions, the response clearly opens the door for continued
> dialogue and accommodations.
> 
> http://forum.icann.org/lists/comments-cwg-stewardship-draft-
> proposal-22apr15/
> 
> Best,
> Lynn
> 
>

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 May 2015 23:30:56 +0300

John C & John C, :-)

> believe are not addressed by the present RFC 2860 MOU...

For what it is worth, I agree with the latter John. The important
part is our interface, and our ability to deal with any problems
that might occur. 

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 May 2015 23:32:41 +0300

Lynn,

> If the 3 operating communities could come to agreement on how the proposals fit together, it would help advance the Transition proposal work significantly - for the OC's as well as the ICG.  

Thank you for this. I agree.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 May 2015 23:36:09 +0300

Avri,

First, thank you *very much* for your e-mail. Please continue the
dialogue and do not feel that you should be quiet because you’ve
been involved in the CWG work. Your input here is very much
appreciated.

> sure that for Numbers and Protocols everything could remain in the

This is a key statement. Thank you.

> stuck to its knitting. 

My personal opinion is that I think that as long as the details of how you
control PTI are done right, you should have sufficient power. That is,
if the names community has the power you should be all right.

However, I do not think that the IETF having its agreement with
ICANN and the names community working with the PTI necessarily
means that our powers could not be united when needed. Just
like today, the communities are in contact. Just like today, if
a change had to be made, we would all discuss that and try
to do it together in a coordinated fashion.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 22 May 2015 23:58:43 +0300

Folks,

I think it is time to cool down the discussion a bit.
Please take a pause before deciding to comment
on individual posters, use unnecessarily polarised
words (such as seceding, utter), casting a behavioural
pattern on organisations, or painting a very black
and white picture of the road ahead.

We are trying to bring about a significant transition
in the Internet. Parts of this transition are easier,
other parts are harder. At the IETF we are lucky
to be on the easier side, but we also want best
for the whole Internet, and not just for us. While
there are significant challenges still ahead in the
names side, one observation that I would like
to make is that the effort is unprecedented in
how much it is community driven. But work
is still needed,  As Lynn pointed out, we need
to work together.

I would like to separate the discussion about the
rationale and commentary of the names proposal
a bit from the effects to the IETF. 

As for the commentary on the names proposal,
I think it is quite appropriate to make comments
and ask questions. Even hard ones. I am
absolutely certain that the names community
is happy about receiving such input and feedback.
Lets work through that.

But the other question, perhaps even more
immediate for the IETF, is whether the arrangements
have an impact on us. My own view is similar to what
Bob, Brian, and others have stated on the list. That
is, the IETF can work with existing MoUs and that it
isn’t fundamentally incompatible with internal
organisational changes on where the IANA department
actually lives inside ICANN. This is also supported
by what Avri said. However, as several posters have
noted, the names proposal is not complete yet. So 
can we work together on finding the details that
work for us?

I wanted to highlight also that the largest
part of coordination between the three IANA
communities happens indeed between the
communities. Not through IANA. Take the discussions
from a couple years back when we talked about
expanding the private address range, for instance.
There was a lot of back and forth between the IETF
and the RIRs. In the end we made a decision and
communicated it to IANA, which executed it with
the help of the IETF and RIRs doing the right thing.

Jari

---

From: Eliot Lear <[email-masked]>
Date: Sat, 23 May 2015 08:10:46 +0200

Stephen,

You asked this question:

On 5/21/15 3:51 PM, Stephen Farrell wrote:
> So I'd be interested in hearing from other folks [...] who think that the IETF ought do something directly involving the PTI (e.g. to re-open the MoU to change the partner involved or something.)

To me I think there are aspects of moving to the PTI model which are
quite attractive over time, because depending on how it is implemented,
the PTI can provide for better separation from the naming community and
associated politics.

But there are many many risks involved with adopting that approach in
haste.  Maybe there will be opportunities over time to take advantage of
the benefits, once we have some understanding as to how to manage the
drawbacks that have been discussed on this list (there may be more).  My
point is that we should not forever shut the door on the approach.

It's not clear to me that this involves reopening the MoU.  Most of the
hard lifting has to be done at ICANN and how they are organized, and how
funding works.  Some of that probably should be considered by them now,
because it may be harder to fix later, but as we have something that
works reasonably well now, and some of those issues are quite knotty,
and there is only so much time in the day, if the transition is to
happen, ICANN may need to address other more pressing concerns.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 23 May 2015 12:12:30 +0100

On 23/05/15 07:10, Eliot Lear wrote:
>> So I'd be interested in hearing from other folks [...] who think
>> that the IETF ought do something directly involving the PTI (e.g.
>> to re-open the MoU to change the partner involved or something.)
> 
> quite attractive over time, because depending on how it is
> implemented, the PTI can provide for better separation from the
> naming community and associated politics.
> 
> But there are many many risks involved with adopting that approach
> in haste.  Maybe there will be opportunities over time to take
> advantage of the benefits, once we have some understanding as to how
> to manage the drawbacks that have been discussed on this list (there
> may be more).  My point is that we should not forever shut the door
> on the approach.
> 
> It's not clear to me that this involves reopening the MoU.  Most of
> the hard lifting has to be done at ICANN and how they are organized,
> and how funding works.  Some of that probably should be considered by
> them now, because it may be harder to fix later, but as we have
> something that works reasonably well now, and some of those issues
> are quite knotty, and there is only so much time in the day, if the
> transition is to happen, ICANN may need to address other more
> pressing concerns.

That sounds reasonable to me. If a PTI thing works out well
I could see us after some time has elapsed maybe wanting our
SLA or maybe even MoU to evolve to take account of all of
that. I don't see us doing that now though.

So maybe our overall reaction to the CWG thing ought be
something like "Hi CWG, go for the PTI thing as you like, all
we ask is that you bear in mind that we might or might not
want to join in with that later in some yet-to-be-determined
shape or form after it's been seen to be working out well."

S.

> 
> Eliot
> 
> 
> 
> _______________________________________________ Ianaplan mailing
> list [email-masked]