Subject: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Oct 2014 11:04:20 +0200

Hi,

We were all agreed on the call as to the need to resolve IPR issues such
that the protocol parameters registry ends up in the public domain. 
However, I raised an additional issue around confusion at the end of the
contract as to where the authoritative IETF parameters reside, should
the contract be terminated.  I had suggested that we include a statement
that there be no confusion as to this point on the IANA web site.

As I understand it, there were three main objections to my proposal:

 1. "The IETF is not the boss of the world."  The IETF could not
    reasonably expect that ICANN to abide by a statement after the
    termination of our agreement, and that as an organization that
    espouses voluntary standards we could not reasonably insist on
    *anyone* referring to or using OUR version of the protocol database.
    [Andrew Sullivan]
 2. Related, our ultimate authority is moral and those who seek the best
    results will follow the IETF approach, assuming it is the best
    approach [Alissa].
 3. This is not a problem that developers will have [Alissa].

I apologize in advance if I have at all mischaracterized these
arguments.  I will address the above.  If there are others, then we can
take them in turn.

On issue one, I find this argument specious for two reasons.  First, the
IETF is contractually engaged only with ICANN, and our position is that
they hold a concession for us.  It is not unheard of or even uncommon
that rights persist beyond the termination of any such relationship.  I
know that my own employer requires me to hold safe their proprietary
information when my employment terminates.  And so such arrangements can
and do happen all the time.  If anyone ELSE wants to set up their own
IANA, that is perfectly fine with me.  We the IETF do not have an MoU
with anyone else.

Taking issues two and three together, while I agree on the whole that
the IETF is a voluntary standards organization, and that ultimately our
authority is moral and not in any way normative or binding on anyone,
the matter at hand is whether or not confusion will ensue during
transition when developers go to www.iana.org to either look up a value
or to register a value.  By my count, excluding "Help: I'm being
attacked by prisoner.iana.org!" (RFC 6305), there are 780 of our own
RFCs that mention iana.org.  Our own *permanent* documentation refers to
that location. Vendor documentation also refers to iana.org.[1]  Books
and informational web sites refer to iana.org.[2]  It is in internal
company documentation.[3]  It is in OS distribution documentation.[4]
Therefore, the issue at hand is not moral authority but stale pointers
that will last for a very long time.

Arguably neither of the other communities (names or numbers) require
IANA.ORG to perform their function.  If you agree with the above
analysis, then we do.  However, we do not require that we hold the
name.  That is one option.  Another option is that should ICANN and the
IETF go our separate ways, ICANN simply leave pointers to IANA.ORG.  The
principle here is that we not introduce confusion as a consequence of
separating at a point when our relationship may or may not be amicable. 
I do not care which option is chosen so long as the principle is
upheld.  That is necessary for the good of the Internet.

Eliot

[1] http://support2.microsoft.com/kb/174904
[2]
http://www.tcpipguide.com/free/t_TCPIPApplicationAssignmentsandServerPortNumberRang-2.htm
[3] Sorry, I can't provide an internal reference, but I doubt that Cisco
is alone.
[4]
http://svnweb.freebsd.org/base/head/etc/services?view=markup&pathrev=258863

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 07 Oct 2014 11:31:20 +0200

Eliot Lear wrote on 07/10/14 11:04:
[...]
> IANA.ORG to perform their function.  

I wouldn't be so sure, at least for numbers. IANA.ORG holds the
top-level Internet Numbers Registry (shared or overlapped with the IETF
Protocol Parameters) and I am sure it is being used for all sorts of
things, including building router filters. So IANA.ORG is bigger than
just IETF's part (as the IANA itself), and that becomes tricky as soon
as the functions separate.

Andrei

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Oct 2014 13:05:07 +0200

Hi Andrei,

> as the functions separate.

If you have some additional information about the above, that would be
useful.  Are you referring to [1] and [2]?  It still doesn't negate my
main point, even so.

Eliot

[1]
http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
[2]
http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 7 Oct 2014 13:32:00 +0200

Dear Eliot,

Your summary of the discussion matches my understanding, but perhaps not everybody had the same perception of what we were discussing.

I did not think that we were discussing the issue of the "IANA.ORG" domain name.  But I agree that that is an issue that should be discussed.  It seems to me that, way back when, IANA.ORG implicitly morally belonged to the IETF, even if the IETF was not a legal person way back when and so could not own it legally.  The PIR WHOIS doesn't give historical data, so I don't know who first registered that domain name.  I guess it might have been UCLA or ISI.

Be that as it may, that domain name is currently registered by ICANN.

As part of the transition agreement, ICANN could agree to transfer the domain name to ISOC (which is the legal entity for the IETF), with the understanding that this is a sort of "escrow" agreement, and that ISOC will use the domain name only to provide the IANA function as agreed by the customers of the IANA function, in particular the IETF.

Eliot provides considerable evidence to the effect that the string "IANA.ORG" is hard-coded in many RFCs.  That might have been an unfortunate practice, but we have to live with it.  So I think it is legitimate to require that the IETF be able to decide who uses that domain name, and for what.

Eliot says "Arguably neither of the other communities (names or numbers) require IANA.ORG to perform their function."  I think that this is clearly correct, because, for IP addresses, IANA.ORG only provides the list of /24 allocations (and they are not always up to date).  The NRO could easily provide that, and anyway what is of more interest in practice is the WHOIS maintained by each RIR.  Similarly, for domain names, IANA.ORG only provides the list of gTLDs and ccTLDs, and who they are assigned to.  That information could be provided directly by whoever provides that part of the IANA function and, again, it is of less interest that the WHOIS maintained by each TLD.

So I fully agree with what Eliot says below.

Best,
Richard

 -----Original Message-----
From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
Sent: mardi, 7. octobre 2014 11:04
To: [email-masked]
Subject: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion

Hi,

We were all agreed on the call as to the need to resolve IPR issues such that the protocol parameters registry ends up in the public domain.  However, I raised an additional issue around confusion at the end of the contract as to where the authoritative IETF parameters reside, should the contract be terminated.  I had suggested that we include a statement that there be no confusion as to this point on the IANA web site.

"The IETF is not the boss of the world."  The IETF could not reasonably expect that ICANN to abide by a statement after the termination of our agreement, and that as an organization that espouses voluntary standards we could not reasonably insist on anyone referring to or using OUR version of the protocol database. [Andrew Sullivan]

Related, our ultimate authority is moral and those who seek the best results will follow the IETF approach, assuming it is the best approach [Alissa]. 
This is not a problem that developers will have [Alissa]. 
I apologize in advance if I have at all mischaracterized these arguments.  I will address the above.  If there are others, then we can take them in turn.

On issue one, I find this argument specious for two reasons.  First, the IETF is contractually engaged only with ICANN, and our position is that they hold a concession for us.  It is not unheard of or even uncommon that rights persist beyond the termination of any such relationship.  I know that my own employer requires me to hold safe their proprietary information when my employment terminates.  And so such arrangements can and do happen all the time.  If anyone ELSE wants to set up their own IANA, that is perfectly fine with me.  We the IETF do not have an MoU with anyone else.

Taking issues two and three together, while I agree on the whole that the IETF is a voluntary standards organization, and that ultimately our authority is moral and not in any way normative or binding on anyone, the matter at hand is whether or not confusion will ensue during transition when developers go to www.iana.org to either look up a value or to register a value.  By my count, excluding "Help: I'm being attacked by prisoner.iana.org!" (RFC 6305), there are 780 of our own RFCs that mention iana.org.  Our own permanent documentation refers to that location. Vendor documentation also refers to iana.org.[1]  Books and informational web sites refer to iana.org.[2]  It is in internal company documentation.[3]  It is in OS distribution documentation.[4] Therefore, the issue at hand is not moral authority but stale pointers that will last for a very long time.

Arguably neither of the other communities (names or numbers) require IANA.ORG to perform their function.  If you agree with the above analysis, then we do.  However, we do not require that we hold the name.  That is one option.  Another option is that should ICANN and the IETF go our separate ways, ICANN simply leave pointers to IANA.ORG.  The principle here is that we not introduce confusion as a consequence of separating at a point when our relationship may or may not be amicable.  I do not care which option is chosen so long as the principle is upheld.  That is necessary for the good of the Internet.

Eliot

[1] http://support2.microsoft.com/kb/174904
[2] http://www.tcpipguide.com/free/t_TCPIPApplicationAssignmentsandServerPortNumberRang-2.htm
[3] Sorry, I can't provide an internal reference, but I doubt that Cisco is alone.
[4] http://svnweb.freebsd.org/base/head/etc/services?view=markup&pathrev=258863

---

From: "Richard Hill" <[email-masked]>
Date: Tue, 7 Oct 2014 13:56:02 +0200

Dear Eliot,

As stated in my previous E-Mail, the summary seems correct to me, but I did not understand that the issue was the domain name "IANA.ORG".  I thought that we were discussing a more general issue, namely number 4 in my E-Mail of 30 August. That E-Mail is at:

 http://www.ietf.org/mail-archive/web/ianaplan/current/msg00090.html

The text in question is:

>6) In section 2, part IV, under "Transition Implications", the IETF response is
> "No structural changes are required." This is correct, but I think that
> some contractual changes are required in order to make it clear that the
> ultimate authority for the protocol parameters is IETF, not ICANN.
>
>So I would propose to add, at the end of that section, the following three paragraphs.
>
>"At present, article I.1 of the ICANN Bylaws implies that ICANN has the
> overall responsibility for the coordination and allocation and assignment 
> of the protocol parameters. That article should be modified to make it clear
> that, as specified in RFC 2860, it is the IETF that has the overall
> responsibility for the coordination and allocation and assignment of
> the protocol parameters.
>
>"And item 4 of RFC 2860 should be modified to read as follows:
>
>"4. Agreed technical work items.  ICANN agrees, notwithstanding any provisions
> in its Bylaws or other corporate documents that might be construed differently,
> that during the term of this MOU it shall cause IANA to comply ..."
>
>For reference, item 4 of RFC 2860 currently reads "4. Agreed technical work
> items. ICANN agrees that during the term of this MOU it shall cause IANA
> to comply ..."

In accordance with the rather extensive discussions that took place on the mailing list regarding this proposal, I do agree that my reference to "ultimate authority" above is incorrect.  As Andrew (and others) have correctly pointed out, the ultimate authority rests with those who use the protocol parameters.

So what I should have said is something like "but I think that some contractual changes are required in order to make it clear that it is the IETF, not ICANN, who makes decisions regarding allocation etc. of protocol parameters published by IANA."

I think that, in that light, my proposals for changes to the ICANN Bylaws and RFC2860 are still valid.  The motivation for those proposals being (1) to minimize the risk that ICANN would do something that the IETF does not agree with, which situation might lead to a separation and (2) to avoid any confusion in case of separation, by specifying up front that the IETF thinks that its version of the allocation, etc. is the one that people should use. (But of course people are free to use any other version.) 

But I recognize that there was no consensus (in fact considerable opposition) to those proposals.

So, although we did not discuss the matter explicitly, I wonder whether there would be agreement to add this issue to the list of issues for consideration for new text in future versions of the SLA.  That is, mandate the people who negotiate the SLA versions to include consideration of this issue, namely how best to capture in legal text what I think is agreed, namely that the IETF has its version of the protocol parameters allocations and wishes to see that version published by IANA, as opposed to some other version.

I think that this is consistent with what Eliot says below, even if it goes a bit further than who gets to use the IANA.ORG domain name.

Best,
Richard

-----Original Message-----
From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear
Sent: mardi, 7. octobre 2014 11:04
To: [email-masked]
Subject: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion

Hi,

Eliot

---

From: Miles Fidelman <[email-masked]>
Date: Tue, 07 Oct 2014 08:04:59 -0400

Maybe a silly thought, but wouldn't the whole issue of ownership of 
iana.org simply go away if ownership were transferred to IETF now, or as 
part of the NTIA transition?

Miles Fidelman

Richard Hill wrote:
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

---

From: Andrei Robachevsky <[email-masked]>
Date: Tue, 07 Oct 2014 15:35:01 +0200

Eliot Lear wrote on 07/10/14 13:05:
> useful.  Are you referring to [1] and [2]?  

Yes, plus a couple of other number registries. The "BGP operations and
security" draft
(https://tools.ietf.org/html/draft-ietf-opsec-bgp-security) mentions
several of them, all residing at iana.org.

> It still doesn't negate my
> main point, even so.

It doesn't, I support your view. Just wanted to point out that the
question where registries reside is important to numbering (and routing)
communities, too, making it a bit more complex. For instance, as a
practical example, I do not think IETF can run away with iana.org.

This touches on the issue of overlapping registries that we discussed.

Andrei

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Oct 2014 09:11:57 -0700

I agree with Andrei that if only the IETF were to change operators and not other communities, then it might not be clear what to do with IANA.org. The NTIA-ICANN contract assumed that all functions would move together; if that is no longer true it needs to be taken account in the transition plan.

> On Oct 7, 2014, at 6:35 AM, Andrei Robachevsky <[email-masked]> wrote:
>

---

From: JFC Morfin <[email-masked]>
Date: Tue, 07 Oct 2014 18:43:03 +0200

At 13:56 07/10/2014, Richard Hill wrote:
>In accordance with the rather extensive discussions that took place 
>on the mailing list regarding this proposal, I do agree that my 
>reference to "ultimate authority" above is incorrect.  As Andrew 
>(and others) have correctly pointed out, the ultimate authority 
>rests with those who use the protocol parameters.

Richard,

Andrews and others are correct. The ultimate authority rests with me 
for my VGN; with my communities for our VGNs, etc. When I used the 
term "ultimate authority" it was in the context of an appeal system 
and/or the - not yet credibly defined - system of "self-accountability" that,

- ICANN is to find and document
- I personally suggest as a multitude's polycratic system,
- while the USG proposes a possibly identical/reduced(?) 
multi-stakeholder solution, in being unclear about the mutual 
recognition of the stakeholders and the decision process).

When we are out of this context, I suggest using an "ultimate referent".

The whole issue is here:

- RFC 6852 suffers from the same flaws as the NTIA proposition: they 
do not address the question of the ultimate referent (they say it is 
the "global community's market economics"). Until now, it was the 
USG, regulating the internet through the IETF (cf. IEN 48, the 
Internet being a "set of rules" - cf. Lessig: "code is law"), i.e. a 
more centralized way than the ITU democratic club of monopolies - 
with the same target: ensuring (rule) or obtaining (using 
competition) a universal high grade service for everyone.

- As a minority leader, the NTIA cannot propose a democratic 
approach: it would be the WCIT.

- IMHO, the only alternative is the one that the FCC found in 1977 
(through competition) and IEE/IAB/IETF/ISOC/W3C in RFC 6852 (through 
multiple global technically competing communities): not a single 
ultimate referent. Then, we are back to the UN if only Govs are 
considered, to the ITU if Govs, edge providers, and peers are 
considered, to the IGF if everyone can participate, to 
"self-organized polycracy" if everyone has his/her decision actively 
considered.

A balance has to be found. It is likely that things will stabilize at 
the "'IANA+' adapted information" provider's layer, which I call 
VGNICs. The relation between the IETF and them, starting with the 
"historic VGNIC" (Internic, and then ICANN), is to be decided at this 
WG once the IESG/Chairs accept it. Otherwise, this will be outside of 
the IETF, probably - due to the implied delay created by this WG 
denial - at the ITU within the WCIT framework. Until the whole thing 
polycratically stabilizes in the coming decade or so.

It is not easy to accept the way a global network behaves.

jfc

---

From: Jefsey <[email-masked]>
Date: Tue, 07 Oct 2014 18:52:55 +0200

At 18:11 07/10/2014, Bernard Aboba wrote:
>I agree with Andrei that if only the IETF were to change operators 
>and not other communities, then it might not be clear what to do 
>with IANA.org. The NTIA-ICANN contract assumed that all functions 
>would move together; if that is no longer true it needs to be taken 
>account in the transition plan.

Bernard,
Innovation through technically competing multiple global communities 
necessarily progressively means new parameters and new paremeter sets 
to be maintained. People will not want to go to different sources 
they will not know the compatibility. Compatibility between tables of 
different sources calls for a use referent and a trusted operator.

iana.org will probably soon enough be forgot as the internic.org 
(which is registered by ICANN).
http://definitions.uslegal.com/i/internic-network-solutions-trademark/

jfc

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 7 Oct 2014 12:09:53 -0700

Eliot,

I am in the same boat as Richard — it was not obvious to me at all that the discussion we were having on the call was really a proxy discussion about iana.org. I thought we were talking about whether ICANN can continue to publish/operate the “authoritative” protocol parameter registries. Given that from your perspective the discussion was about iana.org, I don’t understand what your ask is. What does it mean for us to require ICANN to “simply leave pointers to iana.org”?

I think it helps to be clear about the hypothetical situations we are talking about. Let’s say we obtain the IPR declarations that we’ve been discussing — that all parties who at present appear as if they could have IPR claims over the protocol parameter registries declare that the registries and their contents are in the public domain. Then let’s imagine that either the IETF or ICANN gives its six months’ notice that they will terminate the MOU, and six months passes and it is terminated (let’s call this “post-MOU-conclusion”). At that point a few things could happen:

1. The IETF contracts with a different party to operate the registries, and all registries, pre-MOU-conclusion and post-MOU-conclusion, get published at iana.org. This is sort of like how it works today, except with a different operator. 

2. The IETF publishes all pre-MOU-conclusion registries and all post-MOU-conclusion registries at some new domain, say registries.example.com. ICANN removes mirrors this site at iana.org.

3. Same as 2, except ICANN makes big public claims that iana.org is the authoritative source of IETF protocol parameters.

4. The IETF publishes all pre-MOU-conclusion registries and all post-MOU-conclusion registries at some new domain, say registries.example.com. ICANN removes all pre-MOU-conclusion registries from iana.org (but keeps what it needs there to fulfill names/numbers/time zone/other obligations).

3. Same as 4, except ICANN leaves all pre-MOU-conclusion registries at iana.org, exactly as they were at the time of the MOU’s conclusion.

4. Same as 4, except ICANN alters some of the pre-MOU registry contents (for whatever reason … hard to think of a reason off the top of my head, but let’s consider it as a hypothetical).

6. ICANN keeps all pre-MOU-conclusion registries published at iana.org and the IETF publishes all post-MOU-conclusion registries at registries.example.com.

These are the hypothetical cases I can think of. In my opinion, none of them warrant us making the kind of concession that was discussed on the call — i.e., that the authority of the published parameters derives from the IETF contractually restricting another party from claiming that the version they publish is authoritative.

#1 and #2 are not problematic from a transition perspective. Anyone used to looking for a parameter at iana.org can find it there still.

#3 is not problematic operationally, because both sites publish the same parameters. But it starts to get to Andrew’s point on the call. If the authority that the parameters have derives from whether people decide to use them, we have no good reason for contractually preventing any other party from making marketing claims. Unlike the employee termination example you give below, in this case we’re talking about information that is in the public domain.

#4-6 would require some re-education of people on our part so that they know where to look to find the parameters they need. We may also need to go back through our documentation and change references to iana.org to the correct new domain name. From my perspective, these are operational annoyances, but they are not a big deal. You found many of the references yourself quite easily, and the authors of other documentation would too. :) If anything, there is already pressure on us as an Internet organization to be more willing to be nimble in terms of the registry interface and management (see the happiana discussion). Making a decision about this based on what is published in books seems like exactly the opposite of what we should do. 

Furthermore, the magnitude of the task of transition to a new domain seems fairly minimal compared to what we would be losing in terms of our value to the technical community by admitting that what makes the parameters authoritative is a contract that prevents ICANN from claiming that they publish authoritative parameters.

With all of that said, if what we were actually talking about on the call (as opposed to what I thought we were talking about) was putting some language in the SLA that says that in the event of the need for either party to host the parameters somewhere besides iana.org, both parties will work together to minimize confusion on the part of iana.org visitors, I see no problem with that.

Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Oct 2014 08:49:18 +1300

On 08/10/2014 00:32, Richard Hill wrote:
...

> As part of the transition agreement, ICANN could agree to transfer the domain name to ISOC (which is the legal entity for the IETF), with the understanding that this is a sort of "escrow" agreement…

No. The legal entity for this purpose is the IETF Trust, whose specific
reason for existence is to own intellectual property on behalf of
the IETF. When the Trust was created, ISOC (and CNRI) transferred all
their relevant IPR to the Trust, but we refrained from tackling the
ICANN IPR issue at that time.

You can see the original Trust Agreement at http://trustee.ietf.org/trust-agreement.html

   Brian

---

From: Eliot Lear <[email-masked]>
Date: Tue, 07 Oct 2014 22:45:42 +0200

Hi Alissa,

On 10/7/14, 9:09 PM, Alissa Cooper wrote:
> Eliot,
>
> I am in the same boat as Richard — it was not obvious to me at all
> that the discussion we were having on the call was really a proxy
> discussion about iana.org <http://iana.org>. I thought we were talking
> about whether ICANN can continue to publish/operate the
> “authoritative” protocol parameter registries. Given that from your
> perspective the discussion was about iana.org <http://iana.org>, I
> don’t understand what your ask is. What does it mean for us to require
> ICANN to “simply leave pointers to iana.org <http://iana.org>”?

An example of an arrangement that would be appropriate would be to
change the links on the main iana.org site to point to
registries.example.com from your example (2) below.
>
> I think it helps to be clear about the hypothetical situations we are
> talking about. Let’s say we obtain the IPR declarations that we’ve
> been discussing — that all parties who at present appear as if they
> could have IPR claims over the protocol parameter registries declare
> that the registries and their contents are in the public domain. Then
> let’s imagine that either the IETF or ICANN gives its six months’
> notice that they will terminate the MOU, and six months passes and it
> is terminated (let’s call this “post-MOU-conclusion”). At that point a
> few things could happen:
>
> 1. The IETF contracts with a different party to operate the
> registries, and all registries, pre-MOU-conclusion and
> post-MOU-conclusion, get published at iana.org <http://iana.org>. This
> is sort of like how it works today, except with a different operator. 
>
> 2. The IETF publishes all pre-MOU-conclusion registries and all
> post-MOU-conclusion registries at some new domain, say
> registries.example.com <http://registries.example.com>. ICANN removes
> mirrors this site at iana.org <http://iana.org>.
>
> 3. Same as 2, except ICANN makes big public claims that iana.org
> <http://iana.org> is the authoritative source of IETF protocol parameters.
>
> 4. The IETF publishes all pre-MOU-conclusion registries and all
> post-MOU-conclusion registries at some new domain, say
> registries.example.com <http://registries.example.com>. ICANN removes
> all pre-MOU-conclusion registries from iana.org <http://iana.org> (but
> keeps what it needs there to fulfill names/numbers/time zone/other
> obligations).
>
> 3. Same as 4, except ICANN leaves all pre-MOU-conclusion registries at
> iana.org <http://iana.org>, exactly as they were at the time of the
> MOU’s conclusion.
>
> 4. Same as 4, except ICANN alters some of the pre-MOU registry
> contents (for whatever reason … hard to think of a reason off the top
> of my head, but let’s consider it as a hypothetical).
>
> 6. ICANN keeps all pre-MOU-conclusion registries published at iana.org
> <http://iana.org> and the IETF publishes all post-MOU-conclusion
> registries at registries.example.com <http://registries.example.com>.
>
> These are the hypothetical cases I can think of. In my opinion, none
> of them warrant us making the kind of concession that was discussed on
> the call — i.e., that the authority of the published parameters
> derives from the IETF contractually restricting another party from
> claiming that the version they publish is authoritative.

As I will discuss below, we we are making no concessions.  These are
termination condition discussions, and so I would join you in hoping
that all of this will remain hypothetical.  Again, we're getting great
service from ICANN today and have been for quite a while.

>
> #1 and #2 are not problematic from a transition perspective. Anyone
> used to looking for a parameter at iana.org <http://iana.org> can find
> it there still.
>
> #3 is not problematic operationally, because both sites publish the
> same parameters. But it starts to get to Andrew’s point on the call.
> If the authority that the parameters have derives from whether people
> decide to use them, we have no good reason for contractually
> preventing any other party from making marketing claims. Unlike the
> employee termination example you give below, in this case we’re
> talking about information that is in the public domain.
>
> #4-6 would require some re-education of people on our part so that
> they know where to look to find the parameters they need. We may also
> need to go back through our documentation and change references to
> iana.org <http://iana.org> to the correct new domain name. From my
> perspective, these are operational annoyances, but they are not a big
> deal. You found many of the references yourself quite easily, and the
> authors of other documentation would too. :) If anything, there is
> already pressure on us as an Internet organization to be more willing
> to be nimble in terms of the registry interface and management (see
> the happiana discussion). Making a decision about this based on what
> is published in books seems like exactly the opposite of what we
> should do.

People use what documentation they have– some of it hardcoded.  Ours is
in effect hardcoded.  We are not going to update all of those RFCs with
new ones and even if we did, the old ones persist.  The person doing the
code or reading the book who is looking for a port number just wants to
know the right place to go.  What you call an annoyance I would call an
obstacle.  Yes, it can be gotten around with time and effort, but let's
simply avoid adding new ones when we can.  I think we both can agree
that it's hard enough today for those who haven't been doing this for a
long time, and even for some who have.
>
> Furthermore, the magnitude of the task of transition to a new domain
> seems fairly minimal compared to what we would be losing in terms of
> our value to the technical community by admitting that what makes the
> parameters authoritative is a contract that prevents ICANN from
> claiming that they publish authoritative parameters.

Thank you for that explanation.  To state the converse, the high level
principle is that our value to the technical community is defined by the
quality of our work, and not, as you rightly protest against, by some
point authority.  We are entirely in agreement on that point.  I'm sorry
we didn't get to the core of your concern on the phone.

However, in much the manner you describe below, I believe it is
perfectly reasonable for the IETF and ICANN to agree that neither shall
make the lives of those who use the protocol parameters any harder than
necessary during a transition.  That's the high order bit to me.  I do
not believe we are admitting anything by asking the current protocol
parameters operator to make clear where the IETF protocol parameters
registry resides.  ICANN could have their own if they so chose, but that
operational confusion should be avoided.

Also, it's just as important to make clear when ICANN is performing an
action on our behalf versus on their own.  They've done a reasonably
good job at managing that separation for us, and so I am confident this
is something that we can find agreement on.

>
> With all of that said, if what we were actually talking about on the
> call (as opposed to what I thought we were talking about) was putting
> some language in the SLA that says that in the event of the need for
> either party to host the parameters somewhere besides iana.org
> <http://iana.org>, both parties will work together to minimize
> confusion on the part of iana.org <http://iana.org> visitors, I see no
> problem with that.

That is pretty much what I had in mind.  Details to be worked out by the
IAOC and ICANN in a supplemental agreement.

Eliot

---

From: Alissa Cooper <[email-masked]>
Date: Tue, 7 Oct 2014 15:59:45 -0700

Hi Eliot,

On Oct 7, 2014, at 1:45 PM, Eliot Lear <[email-masked]> wrote:

> People use what documentation they have– some of it hardcoded.  Ours is in effect hardcoded.  We are not going to update all of those RFCs with new ones

Why not? I mean, why would we take off the table our ability to do a global search-and-replace on the domain name?

> and even if we did, the old ones persist. 

Again, why? I mean, at least in our repository, I don’t understand why we would declare right now that they would have to, or that we would even consider a version with the old domain name and a version with the new one to be two different RFCs.

> That is pretty much what I had in mind.  Details to be worked out by the IAOC and ICANN in a supplemental agreement.

Good. As long as this is a request to the IAOC about avoidance of confusion related to iana.org, and not the location of the authoritative registries, I think we are in agreement.

Alissa

---

From: Eliot Lear <[email-masked]>
Date: Wed, 08 Oct 2014 06:31:56 +0200

Hi Alissa,

On 10/8/14, 12:59 AM, Alissa Cooper wrote:
> Hi Eliot,
>
> On Oct 7, 2014, at 1:45 PM, Eliot Lear <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> People use what documentation they have– some of it hardcoded.  Ours
>> is in effect hardcoded.  We are not going to update all of those RFCs
>> with new ones
>
> Why not? I mean, why would we take off the table our ability to do a
> global search-and-replace on the domain name?

Because the suggestion that we would is beyond the pale, and it doesn't
solve the problem.  RFCs are meant to be entirely stable.  They are
widely distributed.  They have been translated into different
languages.  They have been incorporated into other documentation,
including books.  And even if we did change them, we CAN'T change other
peoples' documentation.

>>> call (as opposed to what I thought we were talking about) was
>>> putting some language in the SLA that says that in the event of the
>>> need for either party to host the parameters somewhere
>>> besides iana.org <http://iana.org/>, both parties will work together
>>> to minimize confusion on the part of iana.org
>>> <http://iana.org/> visitors, I see no problem with that.
>>
>> That is pretty much what I had in mind.  Details to be worked out by
>> the IAOC and ICANN in a supplemental agreement.
>
> Good. As long as this is a request to the IAOC about avoidance of
> confusion related to iana.org <http://iana.org>, and not the location
> of the authoritative registries, I think we are in agreement.
>

To be clear: it must be clear to all where *we* think our authoritative
registry is, and ICANN must make that clear as well on IANA.ORG   That
is what is necessary.

Eliot

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 07:12:35 +0200

I agree with Eliot. And I still think that it would be better if IANA.ORG were transferred to the IETF Trust. 

Best Richard

On October 8, 2014 6:31:56 AM CEST, Eliot Lear <[email-masked]> wrote:
>------------------------------------------------------------------------
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 07:14:30 +0200

I agree with Eliot. 

Best Richard

On October 7, 2014 10:45:42 PM CEST, Eliot Lear <[email-masked]> wrote:
>the

---

From: manning bill <[email-masked]>
Date: Tue, 7 Oct 2014 23:05:12 -0700

presuming, of course, that the other groups affected by the IANA transition (the addressing community and the dns registry/naming community) have no problems
with the IETF trust (the protocol bits)  holding the IANA public presence…

/bill
PO Box 12317
Marina del Rey, CA 90295
310.322.8102

On 7October2014Tuesday, at 22:12, Richard Hill <[email-masked]> wrote:

> Because the suggestion that we would is beyond the pale, and it doesn't solve the problem.  RFCs are meant to be entirely stable.  They are widely distributed.  They have been translated into different languages.  They have been incorporated into other documentation, including books.  And even if we did change them, we CAN'T change other peoples' documentation.
> 
>> 
> To be clear: it must be clear to all where we think our authoritative registry is, and ICANN must make that clear as well on IANA.ORG   That is what is necessary.
> 
> Eliot
> 
> 
> Ianaplan mailing list
> [email-masked]

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 08 Oct 2014 18:16:15 +0900

> Why not? I mean, why would we take off the table our ability to do a global search-and-replace on the domain name?

I don't think we need to take it off the table. It may be necessary in a 
desperate situation. But if we can do something now with a good chance 
of avoiding it (e.g. transferring the rights to iana.org to the IETF 
Trust or so), we really try to it.

> Again, why? I mean, at least in our repository, I don’t understand why we would declare right now that they would have to, or that we would even consider a version with the old domain name and a ve…

There is no global search-and-replace for the Web, and even less for 
deat trees.

Regards,   Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Wed, 08 Oct 2014 18:21:25 +0900

> with the IETF trust (the protocol bits)  holding the IANA public presence…

Of course. I think this may depend on how it is proposed. It's not that 
the IETF wants exclusive control, but that the IETF Trust is already 
established for such cases, and such a solution would provide an 
additional element of "checks and balances" and additional stability for 
everybody. Setting up another organization would lead to a lot of 
useless overhead.

Regards,   Martin.

---

From: manning bill <[email-masked]>
Date: Wed, 8 Oct 2014 04:57:15 -0700

On 8October2014Wednesday, at 2:21, Martin J. Dürst <[email-masked]> wrote:

> Of course. I think this may depend on how it is proposed. It's not that the IETF wants exclusive control, but that the IETF Trust is already established for such cases, and such a solution would provide an additional element of "checks and balances" and additional stability for everybody. Setting up another organization would lead to a lot of useless overhead.
> 
> Regards,   Martin.

Of course these other communities also, already have (and in some cases with a longer history than the IETF trust) such vehicles to handle such cases (the NRO comes to mind).  The IETF is not 
special, unique, or privileged over these other groups.  The have equal  interest/standing and (imho) should not be dismissed out of hand when considering the fate of IANA.ORG.   It should not be 
considered a done deal that the IETF trust is the proper home for this site.  Again, imho.   I have no standing and no vested interest in any particular community.

/bill manning

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2014 08:12:17 -0400

>     *anyone* referring to or using OUR version of the protocol database.

This wasn't precisely what I was trying to say.  I agree with your
point that contracts often have clauses that obtain after the
conclusion of the agreement.  But my objection is threefold.  First,
our authority is less moral than practical: people use our stuff to
the extent it works (and ignore it when it doesn't).  Second, as a
consequence I think it's harmful to us to try to insist on being "the
official" anything, because it chips away at the argument that the
basis for being "the standard" is the simple fact that that's what
people are using.  

Both of those would not be worth considering, however, except that I
also think this is a term over which we'd have to negotiate and which
does us no good.  If the termination clause came into effect in an
amicable way, then I cannot imagine any responsible former IANA
operator continuing to keep a copy of the "alternate" registry up
(this is sort of by definition -- "amicable" termination implies
co-operation).  If, on the other hand, the termination came into
effect under disputatious circumstances, then the very nature of the
dispute would almost certainly turn on the correct actions with
respect to the registry.  (If the IETF had another reason, it seems to
me that it would be an indication that the IETF had gone off the
rails, and in that case it would be by no means obvious that the
registry _should_ move, in so far as the good of the Internet is
concerned.)  In that case, it's hard to imagine a way in which the
to-be-terminated operator could plausibly take down the published
registry under dispute, and still maintain their claim.  So there'd be
a dispute anyway, and it would be public and harmful regardless of
what the contract says.

I think it is a point of prudence that you never negotiate over
something where the outcome makes no difference.  This seems to me to
be such a case, and therefore I don't think we should add this item.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Wed, 8 Oct 2014 09:25:18 -0400

On Oct 8, 2014, at 7:57 AM, manning bill <[email-masked]> wrote:

> Of course these other communities also, already have (and in some cases with a longer history than the IETF trust) such vehicles to handle such cases (the NRO comes to mind).  The IETF is not special, unique, or privileged over these other groups.  The have equal  interest/standing and (imho) should not be dismissed out of hand when considering the fate of IANA.ORG.   It should not be considered a done deal that the IETF trust is the proper home for this site.  Again, imho.   I have no standing and no vested interest in any particular community.

mumble... (general expression indicating that I'm somewhat at a loss 
for words for how to appropriately phrase a coherent response)

Short answer: I think Martin has it correct - the IETF providing a 
specific approach for handling such an issue is not a declaration of 
any form of control, but simply the recognition that there should be 
clarity in this area and offering one possible proposal for doing so.

Given the variety of the communities involved, it is quite likely that 
proposals to the ICG will have quite a diversity in identified issues 
and corresponding mechanisms for addressing each...  All of them will 
need to be considered simply for what they are, i.e. _proposals_, not 
declarations of territory/authority/control, not "a done deal", etc.

It is crucial that each communities views are fully included in their 
ICG proposals, as it will be in reviewing these proposals that the 
material issues (overall alignment/differences in approach) will be 
identified.

/John

Disclaimer: my views alone.

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 8 Oct 2014 09:33:04 -0400

maybe one way forward about this (IPR, iana.org ownership, and other IP related issues) is to "indicate" to the communities that the IETF Trust is a possible neutral vehicule for these issues and should be considered.  The tone is of "please consider it", not "we want this".

Marc.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2014 09:33:35 -0400

> clarity in this area and offering one possible proposal for doing so.

Doesn't that just kick the can down the road?  The ICG is supposed to
give NTIA one proposal, not a menu, I though?  So these various ways
of handling the issue would need eventually to be reconciled in any
final proposal, wouldn't they?  And since the ICG isn't supposed to be
making decisions, at that point wouldn't this all have to go back
through community processes?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 8 Oct 2014 09:48:06 -0400

> through community processes?

I understand the process as ICG is "coordination". My interpretation of this is that if there are multiple/different proposals/views on a specific topic, they would have to discuss with the communities to try to reach concensus on something _and then_ come back to the communities to confirm concensus. ICG not deciding. That is my definition of a coordination body, well, at least an active one, instead of a passive collecting documents.  

Marc.

---

From: John Curran <[email-masked]>
Date: Wed, 8 Oct 2014 09:50:18 -0400

On Oct 8, 2014, at 8:12 AM, Andrew Sullivan <[email-masked]> wrote:

> ... If, on the other hand, the termination came into
> something where the outcome makes no difference. 
> ...

Andrew - 

Does the IETF have any duty to the community to provide the registry data 
to the public in a clear and unambiguous manner?  I expect that some of 
the protocol-using community would not appreciate two conflicting registry 
instances (both asserting to be the correct one) operating for very long...   

One benefit of a termination clause for such a situation is that the IETF 
could have a basis for seeking prompt legal resolution during a dispute,
and this might not be readily available unless data handling post-termination 
has already be established in any agreement.  (Of course, this also presumes 
that the IETF isn't the one gone "off the rails", thus highlighting why these
IANA Stewardship discussions have governance and accountability aspects that
go beyond simply the routine supervision of IANA's registry administration.)

/John

---

From: John Curran <[email-masked]>
Date: Wed, 8 Oct 2014 09:58:05 -0400

> through community processes?

It may very well lead to such, but that's not "kicking the can down the
road", since what comes back should actually contain both the IETF's view 
as well as any other communities countervailing views on the issue, and 
the IETF can then decide how to proceed in light of that feedback.

Think of it sort of like an "IESG review", only done on a larger scale...

:-)
/John

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2014 10:22:27 -0400

On Wed, Oct 08, 2014 at 09:50:18AM -0400, John Curran wrote:
> to the public in a clear and unambiguous manner? 

To the extent the IETF is able to do that, yes.  But _ex hypothesi_,
we're talking about a case where the right thing to do for the
registry is what's under disagreement.  And just as the IETF doesn't
prevent (for instance) faq.org from republishing the RFCs, I sincerely
hope we're not trying to suggest that the protocol parameters are
supposed to be under IETF control.  Indeed, the proposal that the data
all be put in the public domain by definition will give anyone
permission to publish it.

What people really are asking for here is a promise that others won't
compete.  For cases where they're all acknowledging the IETF's
correctness, that's not going to be a question.  So the only case
we're taking about is where someone else is claiming that the IETF has
somehow lost legitimacy as the source of the registry data, and that
therefore an alternative data source is needed.  

> I expect that some of 

Of course not.  But surely you're not asserting that, if such a
dispute actually arose, it'd be the sort of thing that would be
trivially resolved by someone saying, "Oh!  I see!  A contract term!"

> could have a basis for seeking prompt legal resolution during a dispute,

I think you have a different meaning of "prompt" than I do.  In my
opinion, in a case like this, if we do not have an actual shared
belief on the Internet about the right data source, then it makes no
difference what lawyers and judges say because there will continue to
be controversy.  If we _do_ have an actual shared belief about the
data source, that will be reflected very quickly on the Internet given
the practical requirements for interoperation -- certainly, we should
expect _de facto_ convergence long before any _de jure_ decision could
be rendered final.

This is why I continue to doubt that such a term makes any difference
in the end, and why I don't think it's worth opening any negotiation
over.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John Curran <[email-masked]>
Date: Wed, 8 Oct 2014 10:53:29 -0400

> permission to publish it.

"to publish it", or to _accurately/faithfully_ publish it?  If I chose to 
publish the RFC series on numerous websites (RFCs.[newgTLD], bestRFCs.foo, 
etc.), I don't think the IETF should have a problem with my doing so, but 
if I choose to publish RFCs with minor changes sprinkled throughout, that 
is a different matter, no?

> compete.

I would disagree; it's not a question of competition; it is about whether
the IETF has any position on IANA data integrity...

> For cases where they're all acknowledging the IETF's

Not correct.  While that may be the expected case, it could also be simply
a commercial dispute (SLA's, $) that leads to termination.  If the ex-IANA
operator decides to continue to accept registration requests, e.g. for
Private Enterprise Numbers <http://pen.iana.org/pen/PenApplication.page>
and charge for the service, does the IETF care?  Once contracted, does 
that IANA operator have an an eternal franchise on making entries into 
IANA registries, even post-termination?

> trivially resolved by someone saying, "Oh!  I see!  A contract term!"

Actually, such a contract term could provide crucial for the IETF (and its 
_new_ IANA operator) are able to continue to publish what it feels is the 
correct information.  I do not know the value of this to the IETF community, 
but do recommend its discussion.

> be controversy.

Yes and no, depending on the reason for termination as noted above...

In disputed terminations, the ability for the IETF to continue to facilitate 
IANA registry administration and publication without interference could easily 
be predicated on the specific termination language that is contracted.

This will do nothing to settle dispute controversy in the community over "the 
right data source", but note that there are many other potential termination 
disputes for which it may be rather important.

/John

---

From: Jefsey <[email-masked]>
Date: Wed, 08 Oct 2014 19:05:51 +0200

At 15:48 08/10/2014, Marc Blanchet wrote:
>That is my definition of a coordination body, well, at least an 
>active one, instead of a passive collecting documents.

Are you sure you do not confuse coordinating with concerting?
jfc

---

From: JFC Morfin <[email-masked]>
Date: Wed, 08 Oct 2014 19:17:57 +0200

At 16:53 08/10/2014, John Curran wrote:
> > then it makes no difference what lawyers and judges say because 
> there will continue to be controversy.
>

This is an inter-US citizen dialog irt. a global system: which 
lawyers and which judges?
The solution MUST come with its own standalone appeal settlement and 
accountability solution.
jfc

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 8 Oct 2014 10:54:06 -0700

> I understand the process as ICG is "coordination". My interpretation of this is that if there are multiple/different proposals/views on a specific topic, they would have to discuss with the communi…

Different communities having different views is not the same thing as one or more communities saying “here’s a way something could be done, but we’re not specifically suggesting it.” The latter should be avoided, in my opinion. If there is a topic that seems important enough to address in the transition proposal for protocol parameters, then there should be an IETF community consensus view stated about that topic. If not, the topic should be left out.

And open questions that there might be an IETF view on and different views from other communities should be coordinated between the communities *now*. There is no reason to wait until after proposals have been submitted to the ICG.

Alissa

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 8 Oct 2014 10:57:14 -0700

Hi Eliot,

> To be clear: it must be clear to all where we think our authoritative registry is, and ICANN must make that clear as well on IANA.ORG   That is what is necessary.

So that is different enough from what I suggested above that it gets back into the territory where I don’t think we should be asking the IAOC for this at all. Agreement to minimize confusion seems fine; a requirement on ICANN to declare that we have some authority is a non-starter from my perspective.

Alissa

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 8 Oct 2014 14:12:08 -0400

> Different communities having different views is not the same thing as one or more communities saying “here’s a way something could be done, but we’re not specifically suggesting it.” The latter sho…

I'm getting more and more in the camp of "let's propose it (iana.org in IETF trust) and see how it flies".... (ok, that is an overstatement, but...)

Marc.

---

From: Richard Hill <[email-masked]>
Date: Wed, 08 Oct 2014 20:14:18 +0200

As I understand it, Eliot is saying that the IETF should clearly say where it expects its allocations etc will be published.  Namely at IANA.ORG. That makes sense to me. 

Best Richard

On October 8, 2014 7:57:14 PM CEST, Alissa Cooper <[email-masked]> wrote:
>>>>> With all of that said, if what we were actually talking about on
>the call (as opposed to what I thought we were talking about) was
>need for either party to host the parameters somewhere besides
>iana.org, both parties will work together to minimize confusion on the
>part of iana.org visitors, I see no problem with that.
>>>> 
>>>> That is pretty much what I had in mind.  Details to be worked out
>by the IAOC and ICANN in a supplemental agreement.
>>> 
>confusion related to iana.org, and not the location of the
>authoritative registries, I think we are in agreement.
>>> 
>> 
>> To be clear: it must be clear to all where we think our authoritative
>So that is different enough from what I suggested above that it gets
>back into the territory where I don’t think we should be asking the
>IAOC for this at all. Agreement to minimize confusion seems fine; a
>requirement on ICANN to declare that we have some authority is a
>non-starter from my perspective.
>
>Alissa
>
>> 
>> Eliot
>
>
>

---

From: JFC Morfin <[email-masked]>
Date: Wed, 08 Oct 2014 20:22:45 +0200

At 07:12 08/10/2014, Richard Hill wrote:
>I agree with Eliot. And I still think that it would be better if 
>IANA.ORG were transferred to the IETF Trust.

 > were transferred to the IETF Trust.

Certainly not !!! :-)
This would force an immediate Internet standardization split and add 
to the legal/political complexity of the whole thing.

The "IETF Trust" owns a right of legal life and death on every IETF 
derivative work. The whole ISOC/NTIA's move is to relocate the 
Internet IPR from an uncertain USG executive oversight to a rock 
solid IETF Trust property under US jurisdiction. The WCIT, to the 
contrary, wishes to place it under international law and the ITU. My 
IUser position is to make it a humanity's common good because "being 
unilaterally global" is just a BUG as much as is a "business 
unilateral governance" (cf. RFC 3839) that some others are preparing.

This is the matter of my appeal.

Either ISOC accepts a compromise where the IETF continues to look for 
an "internet working better for everyone" (my vision of an acceptable 
"status quo") or they want the ISOC's, Leslie's, and Brian's IETF 
Trust "status quo" vision.

- In the first case, the "IANA protocol" that every global community 
(RFC 6852) technology needs to document their own parameters, names, 
and numbers can be documented by the IETF only after changing the 
clause on the derivative works;

- in the second case, a new task force for higher networking layers 
is to be created that will document it.

A difficult decision for the IESG

The decision is difficult for the IESG. On the one side of the coin, 
they know what works today. On the other side of the coin, they have 
documented the new reality as they perceive it from an SDO club point 
of view (RFC 6852) influenced by economic priorities. However, (1) 
this is new, (2) their participants do not fully adhere, while (3) 
they know they missed many important aspects such as cultures, 
languages, politics, societal evolution, intelligent use (brainware) 
stratum, cyber and normative war aspects, new technologies, complexity, etc.

The main problem that they have seems to be the lack of an 
interlocutor other than a semi-organized ICANN (the first side of the 
coin). On the other side of the coin, they know that they have a 
disorganization of Governments, Defense Ministries, emerging 
Technology Consortiums like for NDNs (Lixia Zhang could inform us), 
Libre, civil society, etc. The IESG/IAB and all of us are 
technicians. Therefore, we need to concentrate the problem into 
technical metaphors that everyone can understand, attach importance 
to, assess,  discuss, and resolve.

The technical metaphors

Eliot's metaphor is the "iana.org" domain name. It is a good one. 
Moreover, we have the "internic.org" experience. This is something 
that can result in an I_D proposing an agreement under the terms of 
the present charter.

My metaphor is the "RFC conformant MYCANN Plug-in under ICANN/ICP-3 
terms and conditions". This is something clear that can result in an 
I_D. However, the present terminology of the Charter does not make 
sure that the case will be addressed by this WG. Hence, Leslie 
suggested that the IESG should be appeal to, which I am doing just 
that. However, this has to be well planned: the worst situation would 
be when the plug-in is up in the air without anyone to standardize 
it. This would be AltRoots+NAT+Loc/ID+more.

Milestones

Therefore, my Libre IUser milestones are:

November 7, 2014        : submit an appeal to the IESG, once having 
benefited from the maximum of inputs.
January 7, 2015+        : probable appeal to the IAB (ditto)
March 7, 2015++ : probable appeal to the ISOC appeal (ditto)
April 2015              : "RFC conformant MYCANN Plug-in under 
ICANN/ICP-3 terms and conditions + intertesting conditions" IETF or 
else (*) WG Charter.
June/July 2015          : "RFC conformant MYCANN Plug-in under 
ICANN/ICP-3 terms and conditions" IETF or else (*) temporary 
standardization document and probable announcement of various 
plug-ins releases from different sources.
September 2015  : significant enough use of the released plug-ins to 
permit the NTIA to decide on an extension of the oversight period 
until stabilization or not.

  (*) "IETF or else" means:
A.  either the IETF, if the appeal has succeeded in identifying that 
the IETF technology must include an open IANA protocol, part of the 
end of the "status quo" 1983/2015 strategy that prevents the second 
objective of the IEN 48 project

B. or a new structure if it failed. I observe that there are two 
candidate formulas:
B.1. either an ITU-I corresponding to the WCIT vote and respecting 
the existing IETF/ITU relations.
B.2. or an IUTF (Intelligent Use TF) non IETF-Trust Free/Libre 
extension of the IETF/IRTF.
     In both cases, setting up a temporary charter would be quick and easy.

---

From: Jefsey <[email-masked]>
Date: Wed, 08 Oct 2014 20:40:03 +0200

At 19:57 08/10/2014, Alissa Cooper wrote:
>Agreement to minimize confusion seems fine; a requirement on ICANN 
>to declare that we have some authority is a non-starter from my perspective.

Allissa,

dont you think that where there is confusion it should be clarified 
rather than minimized? Is it not better to have a tough negociation 
today rather than a conflict further on? Do you mean that ICANN could 
have some authority on any structural issue? Their role is to govern, 
not to normalize.

Architectonics is the political science that deals with how things 
are. Governance is the political art to command to free (now 
interconnected) men. (Aristotle). The IETF area is the first one, the 
ICANN area is the second one. If we are not strict on this, we will 
add to confusion at the IETF level, and multiply confusion outside 
because others will create their own clearly separated documentation.

I think we miss the USCC position in this debate. What are they ready 
to accept from ICANN? or has Admiral Michael S. Rodgers already a 
budget for a IANATO?

We are discussing a new phase for a real world.
jfc

---

From: Seun Ojedeji <[email-masked]>
Date: Wed, 8 Oct 2014 19:41:31 +0100

On Wed, Oct 8, 2014 at 7:14 PM, Richard Hill <[email-masked]> wrote:

> As I understand it, Eliot is saying that the IETF should clearly say where
> it expects its allocations etc will be published. Namely at IANA.ORG.
> That makes sense to me.
>

Ultimately its looking like the ownership of domain "iana.org" denotes the
authority which IMO is somewhat the least part of it. For all they care,
ietf (or any other community) could decide to start publishing their
parameters/allocations on "revolutiondomain.org" the 2 questions if this
happens is:

- Does the initial iana.org cease to become unofficial(ilegal source) as a
result of the communities decision?
- What happens to the actual process that make-up the publications. By
process i mean the community processes and the IANA staff processes?

Cheers!

>> call (as opposed to what I thought we were talking about) was putting some
>> language in the SLA that says that in the event of the need for either
>> party to host the parameters somewhere besides iana.org, both parties
>> will work together to minimize confusion on the part of iana.org visitors,
>> I see no problem with that.
>>
>>
>> confusion related to iana.org, and not the location of the authoritative
>> registries, I think we are in agreement.
>>
>>
>> So that is different enough from what I suggested above that it gets back
>> into the territory where I don’t think we should be asking the IAOC for
>> this at all. Agreement to minimize confusion seems fine; a requirement on
>> ICANN to declare that we have some authority is a non-starter from my
>> perspective.
>>
>> Alissa
>>
>>
>> Eliot
>>
>>
>> ------------------------------
>>
>> Ianaplan mailing list
>> [email-masked]

*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: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2014 14:44:21 -0400

In case I haven't been clear,

On Wed, Oct 08, 2014 at 06:31:56AM +0200, Eliot Lear wrote:
> registry is

this I agree with,

> , and ICANN must make that clear as well on IANA.ORG   That
> is what is necessary.

and this I think is an attempt to tell ICANN what opinion they have to
have in the future.  I think this second request is asking for
something we'll never get without negotiation on some other topic, and
I don't think it has any meaningful force, and therefore I don't think
we should ask for it.

If the WG wants to put in its output a request that the IAOC ask for
such promises without making them a requirement (in other words, to
put this in the "nice to have" rather than "need to have" list), I
can't work myself up about it, but I think it's a waste of effort.

Perhaps there are people who wonder why I care at all about this, and
if you're in that class then you won't be bored by the rest of this
note.  Otherwise, you will be and you can stop now.

One of the things that I learned really early about the DNS is that
"_the_ single root" is actually an emergent property of the tree.
That is, there is one Internet namespace root as a mathematical fact;
but to know what it is you have to look to see what everyone (or
anyway, most everyone) thinks it is.  If lots of people diverge
together, then we don't have one DNS at all, but multiple.  That's bad
for a common network of networks.  If lots of people diverge in
independent ways, it makes no difference: the part that is common is
the Internet name space, and everything else is effectively not part
of the Internet.  (See? there really are ways in which M. Morfin and I
do not disagree completely.)  If there is convergence, then whatever
"everyone" is using -- no matter what any authorit-eye says -- is the
real, common DNS root.  But it must be a single root, as a fact of
math, or we don't have one Internet namespace.  (Proposals for
"parallel" name spaces are in fact just proposals to move the root.
First you figure out which name space you're in -- that's the root --
then you follow from there.  It's a fancy search path.)  I believe
this voluntary participation and admission of the emergent properties
of Internetworking is not just an important feature of having an
Internet, but an _essential_ property (in the Aristotelian or
Thomistic sense) of having an Internet.

Similar thinking permeates my view of Internet standards and protocols
and parameters and so on.  And so, in the case of the protocol
parameters registry, I don't think it is remotely possible to have a
rule that says someone won't compete with what we deploy (and have it
be effective).  But I also don't care whether they compete, because I
believe that _if such a dispute happened_ -- and I don't actually
think it will, but good contracts make good neighbours -- it would be
fabulously disruptive for a short time and then everything would, for
practical purposes, sort itself out.  Some will accuse me of being
naïve or Panglossian, but my experience makes me disagree.

Several years ago, I worked at Afilias, who had the contract for
technical operation the .org domain from PIR.  I was directly involved
in the cutover.  Immediately after the cutover, of course, every whois
client in the world was broken.  They all pointed at Verisign, and
Verisign didn't have authority any more, and whois sort of sucks so
you just got stale data or errors or crap (all of these).  In 6
months, this was all fixed.  I realise that 11 years is a long time on
the Internet (this was in 2003), but most of the tools I use now (the
big exception is my iphone) I was using then.  When it matters, people
are extremely good at learning that the registry operator for what
they needed has changed.  And if it doesn't matter, who cares?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2014 15:04:35 -0400

> As I understand it, Eliot is saying that the IETF should clearly say where it expects its allocations etc will be published.  Namely at IANA.ORG. That makes sense to me. 

That doesn't help us at all if other registry data sources decide to
publish with the "current IANA operator" (e.g. ICANN) and the IETF
decides to publish somewhere else.  So then you have to have a rule
that, if we decide to publish somewhere else, they promise not to
publish anything different.  

And now we're reduced to the very point I keep trying to make, which
is that if they're operating sanely they never will publish anything
different, and if they are disagreeing about the contents of the
registry then we have a problem _regardless_ of what the contract
says, since that's the very topic of dispute.  Alissa laid out the
various alternatives, I thought, clearly and distinctly and completely
upthread.  What are we missing?

A
-- 
Andrew Sullivan
[email-masked]

---

From: Milton L Mueller <[email-masked]>
Date: Wed, 8 Oct 2014 19:31:29 +0000

I agree with Eliot Lear's original analysis and proposal. In particular, I can't accept these arguments:

From: Ianaplan [mailto:[email-masked]] On Behalf Of Alissa Cooper

#4-6 would require some re-education of people on our part so that they know where to look to find the parameters they need. We may also need to go back through our documentation and change references to iana.org<http://iana.org> to the correct new domain name. From my perspective, these are operational annoyances, but they are not a big deal. You found many of the references yourself

It is a big deal, or at least big enough to cause some confusion and so easy to avoid that I fail to understand why anyone would oppose foreclosing it.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Oct 2014 16:08:13 -0400

> is a different matter, no?

The analogy now falls apart, however, because what we've discussed
asking for so far in the case of the registries is "public domain" and
not "copyright."

RFCs have copyrights, and modern ones are held jointly with the IETF
Trust.  As a result, if someone were to publish RFCs with minor
changes sprinkled about, the IETF Trust would actually be able to
undertake some sort of action (presumably, on the grounds of
plagiarism).  

That's not the plan with the registries, at least last I heard.  One
of the consequences of asking for "public domain" is that you can't
_do_ anything if others do something with it you don't like.  (This
is, of course, the very reason for the Mickey Mouse Protection Act and
similar legislation.)

My view is that PD is just fine, because our registries are more
useful than ones that differ and so the IETF contents will be more
valuable and therefore people will trust them.  As a technical matter,
it might be a good idea to sign the various registries with some
public key mechanism to prove that they're the right ones -- that is,
to detect deviations.  But trying to use legal authority rather than
volition here is, as I've now argued repeatedly (so I'll try to stop
beating this horse) a waste of time.

> and charge for the service, does the IETF care?  

Maybe.  It depends on whether the registrations conflict with anything
we're doing.  Otherwise, why should we?  I don't understand this
question: isn't this exactly the sort of dispute we're talking about,
or else irrelevant?

> correct information.

How would it help?  I keep hearing, "It might help."  Everyone who
says that seems to think that the decisions of contract lawyers and
courts are going to be more important than what is included in running
code and networks.

The case we are talking about is where the termination clause is
exercised, and one of the parties is not co-operating.  In that case,
_by definition_ there is a dispute about which is the authoritative
registry.  I claim that the Internet would have to sort this out
before the law could (it makes no difference what the jurisdiction is.
Merely getting the briefs together will be too long).  What are you
claiming?  That the Internet will sit around waiting until some
[US|other] court makes up its mind?  That there will be no appeal or
disputes about jurisdiction or national government foot-stomping about
foreign control over "their" Internet?

I claim that, if the IETF has exercised termination, and subject to
the assured provision that the contents are in the public domain, then
the IETF could go off and do whatever it would like.  Others might try
to dispute what the IETF would do, but I think operational reality
would be more important than lawsuits.  So what's important is that
the IETF can do what it needs do, and it can do it with dispatch, and
it can do it in such a way that consumers of registry data (including
operators) can pick up the pieces of what is bound to be an
unfortunate situation no matter what.  Others seem to believe that
everyone's going to sit around while legal arguments are heard.  But I
work for an operator.  We are going to make our decision in the
interim, and I bet that it sticks regardless of what the law decides
or contracts say.  Rough consensus, sure, but running code!  If you
don't believe that, then I suggest you compare the deployment of whois
and iris.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 8 Oct 2014 13:24:02 -0700

On Oct 8, 2014, at 12:31 PM, Milton L Mueller <[email-masked]> wrote:

> I agree with Eliot Lear’s original analysis and proposal. In particular, I can’t accept these arguments:
>  
> #4-6 would require some re-education of people on our part so that they know where to look to find the parameters they need. We may also need to go back through our documentation and change references toiana.org to the correct new domain name. From my perspective, these are operational annoyances, but they are not a big deal. You found many of the references yourself
>  

I fail to see how negotiating contractual terms with ICANN could be described as easy. I fully expect it to be just the opposite. 

From an IETF perspective, implementers choosing to use protocol parameters that are defined elsewhere but that compete or fail to interoperate with the parameters defined in RFCs is a big deal with potentially big implications for the Internet. Implementers being confused for a brief stretch of time about where to find a registry is not.

Alissa

---

From: Miles Fidelman <[email-masked]>
Date: Wed, 08 Oct 2014 22:07:06 -0400

Alissa Cooper wrote:
> On Oct 8, 2014, at 12:31 PM, Milton L Mueller <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> I agree with Eliot Lear’s original analysis and proposal. In 
>> particular, I can’t accept these arguments:
>> *From:*Ianaplan [mailto:[email-masked]]*On Behalf 
>> Of*Alissa Cooper
>>
>> need to go back through our documentation and change references 
>> toiana.org <http://iana.org/>to the correct new domain name. From my 
>> deal. You found many of the references yourself
>> It is a big deal, or at least big enough to cause some confusion and 
>> so easy to avoid that I fail to understand why anyone would oppose 
>> foreclosing it.
>
>
> I fail to see how negotiating contractual terms with ICANN could be 
> described as easy. I fully expect it to be just the opposite.
>
> From an IETF perspective, implementers choosing to use protocol 
> parameters that are defined elsewhere but that compete or fail to 
> interoperate with the parameters defined in RFCs is a big deal with 
> potentially big implications for the Internet. Implementers being 
> confused for a brief stretch of time about where to find a registry is 
> not.
>

But probably a lot easier to negotiate contractual terms with ICANN 
BEFORE the transition, than after the NTIA contract is no longer a 
lever.  Best to get this stuff done now, rather than kick it down the 
street.

Miles Fidelman

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 9 Oct 2014 02:37:35 +0000

Absolutely right. I see no reason why formalizing what in effect they have already agreed to do would be difficult. In the environment leading up to the transition, ICANN is not in a position to make things difficult for IETF. Afterwards, who knows? 

> But probably a lot easier to negotiate contractual terms with ICANN BEFORE
> the transition, than after the NTIA contract is no longer a lever.  Best to get
> this stuff done now, rather than kick it down the street.
> 
> Miles Fidelman
>

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 8 Oct 2014 22:45:14 -0700

> On Oct 8, 2014, at 7:07 PM, Miles Fidelman <[email-masked]> wrote:
> 
> Alissa Cooper wrote:
>>> On Oct 8, 2014, at 12:31 PM, Milton L Mueller <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> *From:*Ianaplan [mailto:[email-masked]]*On Behalf Of*Alissa Cooper
>>> 
>>> #4-6 would require some re-education of people on our part so that they know where to look to find the parameters they need. We may also need to go back through our documentation and change references toiana.org <http://iana.org/>to the correct new domain name. From my perspective, these are operational annoyances, but they are not a big deal. You found many of the references yourself
> But probably a lot easier to negotiate contractual terms with ICANN BEFORE the transition, than after the NTIA contract is no longer a lever.  Best to get this stuff done now, rather than kick it down the street.

From my perspective this logic does not apply, because writing the kind of contract that is being suggested will be as bad of an idea in the future as it is now or as it would have been in the past. The authority doesn't come from a contract, it comes from independent parties collectively deciding to use our stuff. If that stops being true in the future, the root of the problem will not be the lack of a problem, nor will signing a contract be the solution.

Alissa

---

From: Andrei Robachevsky <[email-masked]>
Date: Thu, 09 Oct 2014 09:09:40 +0200

> From my perspective this logic does not apply, because writing the kind of contract that is being suggested will be as bad of an idea in the future as it is now or as it would have been in the past…

Yes, the authority doesn't come from a contract. But the contract can
help minimize possible confusion in the future. The hardcoded registry
location is a pretty strong lever in whatever possible future
negotiations, IMO.

Andrei

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 09:12:55 +0200

I agree with Andrei.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Andrei
> Robachevsky
> Sent: jeudi, 9. octobre 2014 09:10
> To: Alissa Cooper; Miles Fidelman
> Cc: [email-masked]
> Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
> change and avoiding confusion
> 
> 
> >> But probably a lot easier to negotiate contractual terms with 
> ICANN BEFORE the transition, than after the NTIA contract is no 
> longer a lever.  Best to get this stuff done now, rather than 
> kick it down the street.
> 
> > From my perspective this logic does not apply, because writing 
> the kind of contract that is being suggested will be as bad of an 
> idea in the future as it is now or as it would have been in the 
> past. The authority doesn't come from a contract, it comes from 
> independent parties collectively deciding to use our stuff. If 
> that stops being true in the future, the root of the problem will 
> not be the lack of a problem, nor will signing a contract be the solution.
>

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:11:42 +0200

Please see below.

Thanks and best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Andrew
> Sullivan
> Sent: mercredi, 8. octobre 2014 20:44
> To: [email-masked]
> have in the future.  

Yes.  But the possibility of doing that is explicitly part of the request that NTIA made, namely how to replace its current contract with ICANN for the IANA function.

That contract puts some constraints on ICANN, so, in principle, there is nothing wrong with envisaging that some other future contracts would also put some constraints on ICANN.

>I think this second request is asking for

But others hold a different view, as seen in messages subsequent to this one.

> together, then we don't have one DNS at all, but multiple.

Yes, but the question is actually a bit different, as you correctly point out lower down.  It is "what is at the top of the tree?"  At present, most people accept that it is the name space published by ICANN.  But not everybody, see:

  http://www.open-root.eu/?lang=en 

As you say below, one can think of the collection of all names spaces as a bigger tree, in which the existing name spaces, such as the one published by ICANN, are subtrees.

At present, in order to access the names spaces other than the one published by ICANN, one has to manually configure a DNS server other than the one provided by one's ISP.

But one could envisage a more elaborate syntax for URLs, where, say,

 http:<149.154.159.12>//www.whatever.geewhiz 

would tell your software to use the name server at <149.154.159.12>, thus accessing the name space published there instead of the name space published by ICANN.  And of course there would be a default in case the <> were omitted.

A more refined version of such a syntax would allow for names for DNS servers instead of IP addresses.

>  That's bad
> real, common DNS root.  

This seems to assume that, at present, everybody has access to all names.  But that is not true.  Corporate firewalls typically include software that makes certain names not accessible, for example those corresponding to adult entertainment sites.  And some states (in particular China) block access to certain names or to certain URLs.

So, already, many users only see a subset of the name space published by ICANN.

>But it must be a single root, as a fact of
> then you follow from there.  It's a fancy search path.) 

Yes.

> I believe

I would say that it is an essential property of all telecommunications networks. Or at least of all electronic telecommunications networks.

> naïve or Panglossian, but my experience makes me disagree.

I do agree with you.  But the whole point of this exercise, the IANA transition, is, as I understand it, to come up with whatever set of formal agreements are needed in order to (1) minimize the risk that a dispute will take place and (2) minimize the disruption if a dispute does take place.

As I mentioned in the conference call, anybody who has gone through a divorce without a prenuptial agreement will understand the point.

As you say, good contracts make good neighbors.  At present, there is a very strong contract, the IANA Functions contract between NTIA and ICANN.  The purpose of our discussions is, as already mentioned, to make sure that there are adequate contracts in place in the future, if the current contract between NTIA and ICANN no longer exists.

I realize that some people think that the existing contract between NTIA and ICANN has no significance or effect, at least for what concerns protocol parameters, but it is also the case that other people think differently.

And I think we have all agreed that there is one point where some new language is needed, namely ownership of data.

> they needed has changed.  And if it doesn't matter, who cares?

As you say yourself, it does matter, albeit only for a certain period of time.  And some people care.

More fundamentally, ICANN's Board is under a fiduciary duty to act in the best interests of ICANN as an entity, not of anybody else.

If ICANN is contrained by contract to do X, then the Board is unlikely to do something contrary to X, because that would not be in ICANN's best interests.

But if ICANN is not constrained by contract to do X, then there is no particular reason for the Board not to do something contrary to X, if the Board thinks that doing something contrary to X would be in ICANN's best interests.

Now one can argue that there is no conceivable scenario in which it would be in ICANN's best interests to order its IANA department to publish a protocol parameter that differs from the value published by the IETF.

But it's hard to make predictions, especially about the future, so why not "buy some insurance" through appropriate contractual terms, especially since there is no monetary cost to this particular bit of insurance: all that is needed is to negotiate some language.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:17:48 +0200

Please see below.

Thanks and best,
Richard

> Sent: mercredi, 8. octobre 2014 21:05
> To: [email-masked]
> > As I understand it, Eliot is saying that the IETF should
> clearly say where it expects its allocations etc will be
> published.  Namely at IANA.ORG. That makes sense to me.
> >
>

I wouldn't go that far.  I think it would suffice that ICANN agree not to
publish under the name "IANA".

> upthread.  What are we missing?

I don't think that you are missing anything.  I think that there are
differing views of how much effort should be put into developing contractual
language whose purpose is (1) to minimize the possibility of not operating
sanely and (2) to minimize any disruptions that might be caused in case they
don't operate sanely.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:18:42 +0200

Indeed I agree with Milton, as I've tried to explain in more detail in my
last two messages.

Best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Milton L
Mueller
  Sent: mercredi, 8. octobre 2014 21:31
  To: Alissa Cooper; Eliot Lear
  Cc: [email-masked]
  Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
change and avoiding confusion

  I agree with Eliot Lear's original analysis and proposal. In particular, I
can't accept these arguments:

  From: Ianaplan [mailto:[email-masked]] On Behalf Of Alissa
Cooper

  #4-6 would require some re-education of people on our part so that they
know where to look to find the parameters they need. We may also need to go
back through our documentation and change references to iana.org to the
correct new domain name. From my perspective, these are operational
annoyances, but they are not a big deal. You found many of the references
yourself

  It is a big deal, or at least big enough to cause some confusion and so
easy to avoid that I fail to understand why anyone would oppose foreclosing
it.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:27:33 +0200

Please see below.

Thanks and best,
Richard

> Sent: mercredi, 8. octobre 2014 22:08
> To: [email-masked]

SNIP

>  But trying to use legal authority rather than

I don't think that the issue is trying to use legal authority to prevent
somebody from publishing whatever they want.

I think that there are two issues:

1) How to discourage the IANA operator from publishing anything other than
what the IETF wants.

2) How to prevent somebody from using the name IANA to publish things other
than what the IETF wants.

> Everyone who

I think that the issue is how to avoid getting into courts, namely, how to
ensure that people can easily know which set of numbers to use in order to
keep the code and the networks running smoothly.

> Merely getting the briefs together will be too long).

Agreed.  And, as I said before, the point of appropriate contract language
is to avoid this happening in the first place.

>What are you
> the IETF could go off and do whatever it would like.

Sure. But I think it would be helpful if the contractual framework made it
clear that, in such a case, ICANN could not claim that it could continue to
use the name IANA.

>Others might try
> unfortunate situation no matter what.

Sure.  But as Eliot has pointed out, it will be much easier if the operators
can continue to rely on the information published at IANA.ORG, rather than
having to reconfigure their systems to point to some other source.

>Others seem to believe that

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:30:09 +0200

Alissa says "I fail to see how negotiating contractual terms with ICANN
could be described as easy. I fully expect it to be just the opposite."

That puzzles me.  The contractual terms that we are discussing here are
nothing more than a restatement of what is in the current IANA functions
contract, and what everybody agrees is the way that things work now to
everybody's satisfaction.

So why should there be any difficulty in reproducing the status quo in some
new set of documents?

Best,
Richard

-----Original Message-----
From: Ianaplan [mailto:[email-masked]]On Behalf Of Alissa Cooper
Sent: mercredi, 8. octobre 2014 22:24
To: Milton L Mueller
Cc: [email-masked]; Eliot Lear
Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator

I agree with Eliot Lear’s original analysis and proposal. In particular, I
can’t accept these arguments:

#4-6 would require some re-education of people on our part so that they know
where to look to find the parameters they need. We may also need to go back
through our documentation and change references toiana.org to the correct
new domain name. From my perspective, these are operational annoyances, but
they are not a big deal. You found many of the references yourself

It is a big deal, or at least big enough to cause some confusion and so easy
to avoid that I fail to understand why anyone would oppose foreclosing it.

>From an IETF perspective, implementers choosing to use protocol parameters
that are defined elsewhere but that compete or fail to interoperate with the
parameters defined in RFCs is a big deal with potentially big implications
for the Internet. Implementers being confused for a brief stretch of time
about where to find a registry is not.

Alissa

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:30:53 +0200

Indeed, this is exactly the same point that I made in the message that I
just sent.

Best,
Richard

> Sent: jeudi, 9. octobre 2014 04:38
> To: Miles Fidelman
> Cc: [email-masked]
> Absolutely right. I see no reason why formalizing what in effect
> they have already agreed to do would be difficult. In the
> environment leading up to the transition, ICANN is not in a
> position to make things difficult for IETF. Afterwards, who knows?
>
> ICANN BEFORE

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 10:42:31 +0200

Please see below.

Thanks and best,
Richard

> Sent: jeudi, 9. octobre 2014 07:45
> To: Miles Fidelman
> Cc: [email-masked]
> >>> On Oct 8, 2014, at 12:31 PM, Milton L Mueller 
> <[email-masked] <mailto:[email-masked]>> wrote:
> >>> 
SNIP

> past. 

Sorry, you've lost me.  Exactly that contract is what we have now, in the IANA Functions contract between NTIA and ICANN.

Are you suggesting that that contract was a bad idea? 

>The authority doesn't come from a contract, it comes from 
> independent parties collectively deciding to use our stuff. 

That's a different issue.  The contract we are talking about here is the one between the people that assign numbers (IETF in this case) and the people that publish them (IANN in this case).

Let's step back for a moment and look at things from a distance.

Many standards require number assignments.  The organization that publishes the standard (SDO) either outsources the administration of the assignments (e.g. ISO outsources some administration) or does it itself (e.g. ITU or GSMA).  I think that the most common situation is where the SDO secretariat administers the assignments, but both situations are common.

Historically, the IETF was not a legal entity, so it couldn't easily administer assignments itself.  So the task was outsourced.

At present, there is a legal entity that provides the IETF secretariat, so that entity could also take care of publishing protocol assignments.

Or the task can continue to be outsourced.

But the IETF has every right, and I would say even an obligation, to set the terms and conditions under which the task is outsourced.  And indeed it has done so, through its MoU with ICANN.

So the question at hand is not "should there be a contract with ICANN for the IANA function", but "are any changes/enhancements needed to the contract with ICANN for the IANA function".

As noted earlier, I think that there is consensus that at least one enhancement is needed, namely a provision regarding data ownership.

Now we are discussing a possible additional enhancement, namely who is entitled to use the name IANA and the domain name IANA.ORG.

>If

---

From: JFC Morfin <[email-masked]>
Date: Thu, 09 Oct 2014 11:00:25 +0200

>I agree with Andrei.

Yes. But one does not change people and their habits. One change 
their context. Things are simple: if the nexus is not the USG anymore 
what will it be? ICANN/Business, ITU/Gov, IUse/people, a World 
Digital Organization, or chaos? Unless some want the IETF to be that 
nexus, the IETF is not to side with one camp but to make sure the 
internet is ready for the context resulting from any of them.

> > location is a pretty strong lever in whatever possible future

Note: I know most of the people on the ianaplan mailing list do not 
read my posts. They are writen for those who work for an intelligent 
world for all rather than a world of intelligence on all and for the 
coming negociation background and probable (?) IETF higher layers 
fork. This is ***their*** decision - unless the IESG, IAB, ISOC

jfc

PS. The GSN concept that guide the world: "A global solution network 
consists of diverse stakeholders, organized to address a global 
problem, making use of transnational networking, and with membership 
and governance that are self-organized". This has a name: in 
politics, a lobby, in the real world, an enhanced global coalition of 
global interests and RFC 6852 communities toward the RFC 6852 "huge 
bounty". Such nexus architectonically oppose a WSIS people centered society.

http://gsnetworks.org/sponsorship/
http://www.libertyglobal.com/about-us.html
http://www.rockefellerfoundation.org/
http://www.rbc.com/aboutus/index.html
http://google.com
etc.

---

From: Seun Ojedeji <[email-masked]>
Date: Thu, 9 Oct 2014 11:07:20 +0100

> So why should there be any difficulty in reproducing the status quo in some

Maybe because its not clear who is the contractor here. Are you saying IETF
award the IANA contract (on behalf of the communities) to ICANN?

Lets just assume that IETF awards the contract, then ICANN messes up and
IETF re-award the contract to some other organisation...what is the
assurance that the new organisation will not also mess-up and then the
contracting goes on and on....instead of this circle, why not setup/fix
ICANN processes in a manner that allow any possible mess-ups to be fixed
and called to order!

Maybe if we get the goal right then a way to achieve it will be easier. I
would have thought the major goal will be to improve on the current
status-quo which involves making the ownership of the functions rest more
on the community through processes/policies that is respected by the
operator and binding.

Cheers!

> know
> easy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Oct 2014 11:19:51 +0100

On 09/10/14 06:45, Alissa Cooper wrote:
> The
> authority doesn't come from a contract, it comes from independent
> parties collectively deciding to use our stuff. If that stops being
> true in the future, the root of the problem will not be the lack of a
> problem, nor will signing a contract be the solution.

+1

I think its silly to try to force implementers to use protocol
parameters from here or there. It will not matter what some
contract that does not get read by developers says on that
topic. What would matter in the event of the current IETF/IANA
setup ceasing would be what developers think of the IETF at that
point in time and not what a contract says.

I also think its true to say that its enormously rare for a
developer to start from the IANA registry when doing any kind
of work. AFAIK, they start mostly from the RFCs. So if there
were an issue with there being multiple entities claiming to
be authoritative for protocol parameters in future, we could
just fix that in the RFCs in question without any problem.
So some at least of the "problems" here are really not
problems.

That said, it doesn't seem harmful for the ianaplan WG to say
that it might be handy if iana.org were owned by the IETF trust.
(Or whatever is the right term.) I don't feel strongly about it
but it seems tidy, iff the RIRs and ICANN agree, and would
mean we could very slightly more confidently use stable URIs
containing that DNS name in RFCs. (Which is not current practice
mostly.) If the RIRs or ICANN didn't like that move, then the
status quo is just fine.

If there was any other concrete suggestion being made in the
mails in this thread, I've not seen it. (All the talk about
preventing mythical beings from claiming to be IANA in future
also seems silly to me at least;-) I've also noted a serious lack
of suggested text, so its hard for me to know what it is that
those suggesting change actually want.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 13:53:54 +0200

Dear Seun,

I agree with what you say below and in fact I think that that is what we are all trying to do: to set up a system which will function correctly in the future.

Best,
Richard
  -----Original Message-----
  From: Seun Ojedeji [mailto:[email-masked]]
  Sent: jeudi, 9. octobre 2014 12:07
  To: Richard Hill
  Cc: Alissa Cooper; Milton L Mueller; [email-masked]; Eliot Lear
  Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion

  Maybe because its not clear who is the contractor here. Are you saying IETF award the IANA contract (on behalf of the communities) to ICANN? 

  Lets just assume that IETF awards the contract, then ICANN messes up and IETF re-award the contract to some other organisation...what is the assurance that the new organisation will not also mess-up and then the contracting goes on and on....instead of this circle, why not setup/fix ICANN processes in a manner that allow any possible mess-ups to be fixed and called to order!

  Maybe if we get the goal right then a way to achieve it will be easier. I would have thought the major goal will be to improve on the current status-quo which involves making the ownership of the functions rest more on the community through processes/policies that is respected by the operator and binding. 

  Cheers!

    Best,
    Richard

    -----Original Message-----
    From: Ianaplan [mailto:[email-masked]]On Behalf Of Alissa Cooper
    Sent: mercredi, 8. octobre 2014 22:24
    To: Milton L Mueller
    Cc: [email-masked]; Eliot Lear
    Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator
    change and avoiding confusion

    Alissa

  -- 

    Seun Ojedeji,
    Federal University Oye-Ekiti
    web:      http://www.fuoye.edu.ng
    Mobile: +2348035233535
    alt email: [email-masked]

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 14:11:02 +0200

Regarding suggested text, please see:

and the message that I sent earlier today:

  http://www.ietf.org/mail-archive/web/ianaplan/current/msg00525.html

To the point at hand, I suggest the following.

In section IV of the draft, add the following new paragraph after the first
(so it is the second paragraph):

"However, a new contractual clause regarding ownership of data, rights in
the trademark IANA, and registration of the domain name IANA.ORG must be
negotiated between IAOC and IANA.  And new clauses regarding jurisdiction
and dispute resolution might also be required."

I would also propose to go a bit further and to add the following additional
sentence:

"Data rights shall rest with the IETF Trust. Ownership of the IANA trademark
and registration of the domain name IANA.ORG must be transferred to the IETF
Trust, provided that the other operational communities agree with this."

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Stephen
> Farrell
> Sent: jeudi, 9. octobre 2014 12:20

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 9 Oct 2014 13:34:40 +0000

> I think its silly to try to force implementers to use protocol parameters from
> here or there. It will not matter what some contract that does not get read by

I think it's much sillier and increasingly counterproductive for you and others to keep pretending that this debate is about forcing anyone to use protocol parameters from any particular source. That actually has nothing to do with the issue here.

It is primarily about 1) whether IETF has contractual authority over who it uses for IANA functions or not, 2) whether it will consistently assert that authority in the transition process and 3) whether there will be clear, consistent and institutionalized identification of the source where IETF parameters are published. 

I am still waiting for an supportable, positive reason why IETF should _not_ make the iana domain and trademark part of its contract with ICANN for the IANA services.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 15:40:07 +0200

I guess that it must be obvious by now that I agree with what Milton says
below.

Best,
Richard

> Sent: jeudi, 9. octobre 2014 15:35
> To: Stephen Farrell; Alissa Cooper; Miles Fidelman
> Cc: [email-masked]
> parameters from
> I think it's much sillier and increasingly counterproductive for
> you and others to keep pretending that this debate is about
> forcing anyone to use protocol parameters from any particular
> source. That actually has nothing to do with the issue here.
>
> It is primarily about 1) whether IETF has contractual authority
> over who it uses for IANA functions or not, 2) whether it will
> consistently assert that authority in the transition process and
> 3) whether there will be clear, consistent and institutionalized
> identification of the source where IETF parameters are published.
>
> I am still waiting for an supportable, positive reason why IETF
> should _not_ make the iana domain and trademark part of its
> contract with ICANN for the IANA services.
>
>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Oct 2014 14:47:57 +0100

Hiya,

On 09/10/14 14:34, Milton L Mueller wrote:
>> contract that does not get read by
> 
> I think it's much sillier and increasingly counterproductive for you
> and others to keep pretending that this debate is about forcing

I don't believe I've pretended anything. My mail said what I
think and not what I pretend to think.	Were I cranky about
this I might ask you to not say such things. But I'm not (yet:-)

> anyone to use protocol parameters from any particular source. That
> actually has nothing to do with the issue here.
> 
> It is primarily about 1) whether IETF has contractual authority over
> who it uses for IANA functions or not, 2) whether it will
> consistently assert that authority in the transition process and 3)
> whether there will be clear, consistent and institutionalized

Sorry I don't get how your (3) is not a way to "try to force
implementers to use protocol parameters from" a particular
place. Maybe "institutionalized identification" means something
I don't get though. If your (3) just means that the IETF will
always point at where we think folks find protocol parameters
then that's sensible and ok and not a problem - we do that
in RFCs now and I see no future universe worth discussing in
which we forget to do that.

Let me try put it this way: today we have "IANA considerations"
sections. If needed, in future we could decide to add "BLAHBLAH
considerations" for any value of BLAHBLAH that we (with IETF
consensus) choose, which could be BLAHBLAH==IANA or not.

> should _not_ make the iana domain and trademark part of its contract
> with ICANN for the IANA services.

"Not needed now" is supportable I think. I don't know if its
a positive reason or not.

But again, if such a transfer was easy and nobody else had
a problem then it may well be ok, as I said before and might
make it easier to derive stable URLs involving iana.org for
use in RFCs. I would be a bit concerned though that such a
transfer might not be easy in which case I'm fine if it does
not happen since I only see a very minor benefit for those
who read and use RFCs.

S.

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

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Thu, 9 Oct 2014 13:03:22 +0000

Hi

I have limited connectivity and so please excuse limited and delayed responses ...

> publish anything different.  

They can publish whatever they want, but not in such a way that others would believe it has our authority.   Because our own RFCs and lots of history purport just that, the current location would need a clear statement.  The important point on which we might agree is choice on the part of the developer. Informed choice is what is necessary.  That requires notice of a change. 

Eliot

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Thu, 9 Oct 2014 13:53:07 +0000

Hi

To be clear: it must be clear to all where we think our authoritative registry is, and ICANN must make that clear as well on IANA.ORG<http://IANA.ORG>   That is what is necessary.

There is a difference between declaring that we are The Authority versus requiring the current operator make clear upon termination that their copy is no longer the version that is maintained on our behalf, where at on point (today and hopefully long from now) it was.

Eliot

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 16:16:04 +0200

I find that Eliot has formulated the issue very well.

Best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Eliot Lear (elear)
  Sent: jeudi, 9. octobre 2014 15:53
  To: Alissa Cooper
  Cc: [email-masked]; Eliot Lear
  Subject: Re: [Ianaplan] From yesterday's interim: managing IANA operator change and avoiding confusion

  Hi

  Eliot

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 9 Oct 2014 14:21:38 +0000

> > 3) whether there will be clear, consistent and institutionalized identification 
> > of the source where IETF parameters are published.
> 
> Sorry I don't get how your (3) is not a way to "try to force implementers to
> use protocol parameters from" a particular place. 

Really? So you don't understand the distinction between 
a) trademarking a sign or word as an authoritative identifier of origin and 
b) forcing people to consume the goods or services so trademarked? 

So, e.g., when Syracuse University doesn't allow other universities to claim to be "Syracuse University" we are in effect forcing all the world's college students to use our educational services? 

I think you can see the fallacy here. That argument is dead. Please drop it.

> "Not needed now" is supportable I think. I don't know if its a positive reason
> or not.

The "not needed now" argument is at least logically coherent, but I think it's been demolished on this list. We are in the middle of the IANA transition process. ICANN must deal with you. This will be the easiest time to get it done. If you need to assert these rights due to a contingency that arises some time in the future, it should be obvious that you will not be able to get it without difficult negotiations and, probably, an expensive lawsuit. The need for asserting it would only come up if some problem were caused and some of us are just saying that it makes more sense to prevent those problems than to react to them later. 
 
> I would be a bit concerned though
> that such a transfer might not be easy in which case I'm fine if it does not
> happen since I only see a very minor benefit for those who read and use
> RFCs.

My frank assessment is that IETF is in a position to get anything it wants from this process at this time. It will never be easier than it is now.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Oct 2014 15:41:36 +0100

On 09/10/14 15:21, Milton L Mueller wrote:
>> implementers to use protocol parameters from" a particular place.
> 
> Really? So you don't understand the distinction between a)
> trademarking a sign or word as an authoritative identifier of origin
> and b) forcing people to consume the goods or services so
> trademarked?
> 
> So, e.g., when Syracuse University doesn't allow other universities
> to claim to be "Syracuse University" we are in effect forcing all the
> world's college students to use our educational services?
> 

Your fallacy is clear but irrelevant IMO. The IETF has no need
to continue to use the term IANA, should using that term be a
problem. So "owning" the trademark and domain are maybe-nice
but no more. TBH, I don't believe that the average developer who
implements IETF protocols knows or cares that IANA exists, nor
need they. Many of them don't know the IETF exists, and that's
also sorta fine:-)

You appear to want us to try force folks to always take protocol
parameters from whoever owns the IANA trademark, but I think we
can have that function done by a person called Fred if we so
choose and all will be well, so long as Fred is who implementers
ask and Fred is able to manage to answer. And the IETF can
arrange that both of those are ok.

To be concrete, for RFC 5326 (I'm a co-author is the only reason
I know or care, I don't have this stuff in my head:-) we eventually
(in RFC 7116) allocated some codepoint ranges for CCSDS to allocate
via their Space Assigned Numbers Authority (SANA). And the world
didn't break. Nor would it if for some reason the IETF in future
decided that the CCSDS folks could take over all of what IANA
now does for the IETF. (Not that we'd want to, but we could.) In
that future, new RFCs would have "SANA considerations" probably
and developers would get the idea over time and the world would
not break. (I'm sure we'd also document it all in some other RFC
too, but no developers would read that;-)

Sure, life will be easier if the IETF can keep saying IANA but its
not a huge deal (for the IETF) even if not.

> 
>> "Not needed now" is supportable I think. I don't know if its a
>> positive reason or not.
> 
> The "not needed now" argument is at least logically coherent, but I
> think it's been demolished on this list. 

We disagree. And demolished is just pointless overstatement.
Maybe you're pretending it was demolished though:-)

> We are in the middle of the
> IANA transition process. ICANN must deal with you. This will be the
> easiest time to get it done. If you need to assert these rights due
> to a contingency that arises some time in the future, it should be
> obvious that you will not be able to get it without difficult
> negotiations and, probably, an expensive lawsuit. The need for
> asserting it would only come up if some problem were caused and some
> of us are just saying that it makes more sense to prevent those
> problems than to react to them later.
> 
>> I would be a bit concerned though that such a transfer might not be
>> easy in which case I'm fine if it does not happen since I only see
>> a very minor benefit for those who read and use RFCs.
> 
> My frank assessment is that IETF is in a position to get anything it
> wants from this process at this time. It will never be easier than it
> is now.

Possibly. I've no objection to asking. I do have a problem
with gating progress on that, as I don't think its needed and
even if now is the best time to ask, that doesn't mean it's
a good idea to ask.

S.

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 9 Oct 2014 14:53:55 +0000

> From: Stephen Farrell [mailto:[email-masked]]
> You appear to want us to try force folks to always take protocol parameters
> from whoever owns the IANA trademark, 

I'm sorry, but this fallacy has been refuted (I am sure the rest of the list can see that) and this conversation with you is over.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Oct 2014 16:06:21 +0100

On 09/10/14 15:53, Milton L Mueller wrote:
> 
> 
>> -----Original Message----- From: Stephen Farrell
>> [mailto:[email-masked]] You appear to want us to try
>> force folks to always take protocol parameters from whoever owns
>> the IANA trademark,
> 
> I'm sorry, but this fallacy has been refuted (I am sure the rest of
> the list can see that) 

Well, if you don't want to force that, then I don't see why
the trademark and domain are any more than a nice-to-have,
from the IETF perspective. The consequence of that being
that "not needed now" is an entirely reasonable position
for this WG to take wrt those.

Calling a thing a fallacy does not make it so. Talking
as if getting a thing done is critically important does
not make it so.

> and this conversation with you is over.

Probably just as well. One side of it seemed to be getting
fairly narky:-)

S.

---

From: "Richard Hill" <[email-masked]>
Date: Thu, 9 Oct 2014 17:13:58 +0200

Personally, I think that ensuring that implementers and operators can rely
on the name IANA as the source for the values duly assigned by IETF is more
than "nice to have".

If implementers and operators don't want to use the IETF values, that's
their right.  But I don't think that they should have to hunt around to
discover that, no, the source for the IETF values is no longer IANA, it is
somebody else.

But of course reasonable people can have different opinions.

Best,
Richard

> Sent: jeudi, 9. octobre 2014 17:06

---

From: Jefsey <[email-masked]>
Date: Thu, 09 Oct 2014 18:23:38 +0200

Richard,

people are no fool. They will easily remember that their IANA data, 
and the data of the other technologies they may use (such as NDN 
names) are documented by their VGN's information center (VGNIC). It 
may even be called such as "iana.org.jefsey.com" for my "jefsey" VGN. 
This would make it strictly compliant with the existing hard coded RFCs.

jfc

---

From: JFC Morfin <[email-masked]>
Date: Thu, 09 Oct 2014 18:24:07 +0200

At 15:34 09/10/2014, Milton L Mueller wrote:
>That actually has nothing to do with the issue here.

Milton,
some more element to support your position.

>It is primarily about

>1) whether IETF has contractual authority over who it uses for IANA 
>functions or not,

The IETF is a collective author. It has authority on what it writes, 
i.e. RFCs and a common set of annex tables it calls "IANA" for nearly 30 years.
It contracts who it wants to publish it.

>2) whether it will consistently assert that authority in the 
>transition process and

The IETF owns the text of its RFCs and the content of its IANA tables 
as every author.
This authority these texts and content represent is acknowledged by 
the Internet Users using them when interconnecting their machines.

>identification of the source where IETF parameters are published.

RFCs and IANA Content are copyrighted. All rights are reserved to the 
IETF Trust and the persons identified as the document authors.  They 
are subject to BCP 78 and the IETF Trust's Legal Provisions Relating 
to IETF Documents (http://trustee.ietf.org/license-info) in effect on 
the date of publication of this document. This makes a very complex 
system. This is unerlined by the mention "Please review these 
documents carefully, as they describe your rights and restrictions 
with respect to this document."

This is not really appropriate to an international public as several 
non clearly identified provisions on several documents, one of them 
not being clearly identified nor being made directly accessible ("BCP 
78"), that may vary in time.

>with ICANN for the IANA services.

The iana.org domain name has been registered in 1995, i.e. three 
years BEFORE ICANN was registered. May be Jay Daley could help in 
finding who was the initial registrant owner (no me !). This is worth an UDRP.

The mention "iana.org" which is hard coded in RFC does not pose any 
problem since, for example, Mr. Andrew Michael Phillips owns the name 
"iana.org", in the ".uk" zone. This can be replicated in any other 
TLD where the name is not already registered.

Best
jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Oct 2014 13:01:09 -0400

> a) trademarking a sign or word as an authoritative identifier of origin and 

Trademarks aren't actually of help in knowing whether the data you got
is the data that the origin you trust send.  If that's what you want,
you need digital signatures.  Fortunately, that is something we can
achieve without any lawyers.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Oct 2014 14:00:56 -0400

> and dispute resolution might also be required."

As I think I've said every way I know how, I believe that asking for
anything we do not already have is dangerous.  

We have a number of provisions in an existing agreement.  That
agreement is working well for us, as we've said repeatedly and as was
re-enforced at the BoF in Toronto.  Our charter says, "[M]inimal
change in the oversight of the IETF protocol parameters registries is
preferred in all cases and no change is preferred when possible."

We have been granted not ownership rights in data, but a disclaimer by
ICANN of ownershp rights in data, by the Chair of the ICANN Board of
Directors.  We do not now have either the trademark IANA or the domain
name iana.org.

If we ask for those things that we don't have, then ICANN will quite
correctly want something in return.  It seems to me that they might
well ask us for something we don't want to give up in that case, and I
think it would be extraordinarily unwise for us to bargain away any of
the existing agreement since it's working so well for us.

Moreover, I do not see any argument being made by any actual
implementer of widely-deployed software or actual operator of large
networks that suggests the trademark "IANA" or the website iana.org is
critical to their functioning.  "Nice to have stability"?  Yes.  But
that's a reason for us to change as little as possible.  "Critical
that it doesn't change"?  No, and in fact there is _no way_ to
guarantee that at least for something.  For instance, it is possible
(though undesirable) that protocol parameters and various domain name
things get separate registry operators.  Suppose that IETF retained
iana.org under those cases; then _someone else_ has to deal with the
cost of the change of the domain name that serves the registry data,
and that's at least as bad for Internet operation stability as
changing the location of the IETF protocol parameters registries.

Our charter tells us to do the minimum possible.  We should heed its
instructions.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 09 Oct 2014 19:29:27 +0100

+1

I'm not really concerned that asking is dangerous, but strongly
agree with the above and also don't see the need (as opposed to
desire) to try acquire the trademark and domain at this point.

S.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 9 Oct 2014 11:48:11 -0700

Here is the additional text I would suggest in response to the questions in section IV of the RFP:

"The IAOC should coordinate with the IAB and the IETF Trust to request public declarations from ICANN, NTIA, ISOC, and the IETF Trust that any rights to the contents of the IETF protocol parameters registries be transferred to the public domain, or should take other steps as it sees fit to accomplish the goal of clarifying that the registry contents reside in the public domain.

The IAOC, together with the IAB as appropriate, should investigate the possibility of adding language to the 2015 IETF-ICANN service level agreement to establish that in the event of the need for either the IETF or ICANN to host the IETF protocol parameters registries at a location other than iana.org, both parties will work together to minimize confusion on the part of iana.org visitors.”

I don’t think the second paragraph is necessary, but I think it’s okay to include.

Alissa

---

From: Milton L Mueller <[email-masked]>
Date: Thu, 9 Oct 2014 19:00:46 +0000

> As I think I've said every way I know how, I believe that asking for anything
> we do not already have is dangerous. [snip]
> If we ask for those things that we don't have, then ICANN will quite correctly
> want something in return.  It seems to me that they might well ask us for
> something we don't want to give up in that case, and I think it would be
> extraordinarily unwise for us to bargain away any of the existing agreement
> since it's working so well for us.

Let me reiterate what we all should know already. The NTIA has asked ICANN to convene the community to develop a transition plan, and has said in every way it knows how that it will respect the result of that process. The ICG, which is the official recognized agent for assembling the community proposals (and this recognition was publicly reiterated here at the ARIN meeting by a NTIA attendee) has said that each operational community will develop a proposal. If those proposals are approved as a package, the NTIA and ICANN are obligated to implement them, and the NTIA has the clear authority to require them. There is nothing in the NTIA statement that makes room for ICANN to bargain with, resist or impose 'danger' as a result of changes in the IANA contract. 

To be more specific, if part of the IETF transition plan is that ownership of the IANA domain and the use of the term IANA comes under the control of IETF and not ICANN, that will happen. 

So your fears are ungrounded.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Oct 2014 08:28:22 +1300

IMHO this is fine, and a good enough approximation to necessary and sufficient.

   Brian

---

From: John Curran <[email-masked]>
Date: Thu, 9 Oct 2014 16:01:54 -0400

> There is a difference between declaring that we are The Authority versus requiring the current operator make clear upon termination that their copy is no longer the version that is maintained on ou…

Agreed, but that involves more than intellectual property rights (IPR) status of the registry 
data itself.

The IANA Stewardship transition proposal being requested by NTIA has to designed for
an environment where the NTIA no longer has a contract with the IANA Operator (and 
that the IANA Operator is instead performing the duties under the auspices of the global
Internet community via the mechanisms specified in the stewardship transition plan.)

Presently, the IANA operator is subject to several provisions in the IANA functions contract
which explicitly address transition to a new IANA operator; these include C.7.3 and I.61
(I have attached the relevant text for these provisions below for reference.)

Does the IETF intend to include similar provisions in its IANA operator contracting?  If not, 
is there a clear explanation of why the potential issues that these clauses address would not 
pose any issue with respect to a transition of the IETF protocol parameter registry services?

/John

=== Provision C.7.3 from the IANA Function Contract SOW

C.7.3 Transition to Successor Contractor – In the event the Government selects a successor contractor, the Contractor shall have a plan in place for transitioning each of the IANA functions to ensure an orderly transition while maintaining continuity and security of operations. The plan shall be submitted to the COR eighteen (18) months after date of contract award, reviewed annually, and updated as appropriate.

=== Provision I.61 from the IANA Function Contract SOW

I.61 52.237-3 CONTINUITY OF SERVICES (JAN 1991)

(a) The Contractor recognizes that the services under this contract are vital to the Government and must be continued without interruption and that, upon contract expiration, a successor, either the Government or another contractor, may continue them. The Contractor agrees to --

(1) Furnish phase-in training; and

(2) Exercise its best efforts and cooperation to effect an orderly and efficient transition to a successor.

(b) The Contractor shall, upon the Contracting Officer’s written notice,
(1) furnish phase-in, phase-out services for up to 90 days after this contract expires and

(2) negotiate in good faith a plan with a successor to determine the nature and extent of phase-in, phase-out services required.

The plan shall specify a training program and a date for transferring responsibilities for each division of work described in the plan, and shall be subject to the Contracting Officer’s approval. The Contractor shall provide sufficient experienced personnel during the phase-in, phase-out period to ensure that the services called for by this contract are maintained at the required level of proficiency.

(c) The Contractor shall allow as many personnel as practicable to remain on the job to help the successor maintain the continuity and consistency of the services required by this contract. The Contractor also shall disclose necessary personnel records and allow the successor to conduct on-site interviews with these employees. If selected employees are agreeable to the change, the Contractor shall release them at a mutually agreeable date and negotiate transfer of their earned fringe benefits to the successor.

(d) The Contractor shall be reimbursed for all reasonable phase-in, phase-out costs (i.e., costs incurred within the agreed period after contract expiration that result from phase-in, phase-out operations) and a fee (profit) not to exceed a pro rata portion of the fee (profit) under this contract.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Oct 2014 19:46:58 -0700

John Curran stated:

"Presently, the IANA operator is subject to several provisions in the IANA
functions contract
which explicitly address transition to a new IANA operator; these include
C.7.3 and I.61
(I have attached the relevant text for these provisions below for
reference.)"

[BA] Indeed.  Given that ICANN has already filed a transition plan as
required under the contract, it seems sensible for me for the appropriate
groups (probably the IETF Trust in the case of the IETF) to obtain and
examine that plan, with the goal of analyzing it and opining on its
usefulness in the situation we now face.   While it highly likely that
there are additional corner cases (such as individual functions moving to a
new operator) not handled by the filed plan, it represents at least one
take on what would be required for a unitary transition.

My assumption is that given the overall good relationship with the
Contractor, that the Transition Plan could be obtained merely by asking
(possibly with some redactions), assuming that the USG did not get in the
way.  While we *could* act as if the plan did not exist and attempt to
recreate it from scratch, it's hard for me to imagine why this approach
would be preferred.

Given the potential complexities that could arise in analyzing the
transition issues, it is probably best for that work to getting underway
sooner rather than later, especially given that much of the IANAPLAN WG
discussion is now centering on issues that (at least to me) appear to be
out of scope of the charter.   Given that we seem to have consensus that
there are issues that the IETF Trust needs to address, and given that the
IETF Trust has the responsibility and indeed the duty of moving forward on
these issues, it seems to me that the right thing to do is to communicate
this need to the IETF Trust and request an expeditious response.

On Thu, Oct 9, 2014 at 1:01 PM, John Curran <[email-masked]> wrote:

> > There is a difference between declaring that we are The Authority versus
> requiring the current operator make clear upon termination that their copy
> is no longer the version that is maintained on our behalf, where at on
> point (today and hopefully long from now) it was.
>
> C.7.3 Transition to Successor Contractor – In the event the Government
> selects a successor contractor, the Contractor shall have a plan in place
> for transitioning each of the IANA functions to ensure an orderly
> transition while maintaining continuity and security of operations. The
> plan shall be submitted to the COR eighteen (18) months after date of
> contract award, reviewed annually, and updated as appropriate.
>
> (a) The Contractor recognizes that the services under this contract are
> vital to the Government and must be continued without interruption and
> that, upon contract expiration, a successor, either the Government or
> another contractor, may continue them. The Contractor agrees to --
>
> (2) negotiate in good faith a plan with a successor to determine the
> nature and extent of phase-in, phase-out services required.
>
> The plan shall specify a training program and a date for transferring
> responsibilities for each division of work described in the plan, and shall
> be subject to the Contracting Officer’s approval. The Contractor shall
> provide sufficient experienced personnel during the phase-in, phase-out
> period to ensure that the services called for by this contract are
> maintained at the required level of proficiency.
>
> (c) The Contractor shall allow as many personnel as practicable to remain
> on the job to help the successor maintain the continuity and consistency of
> the services required by this contract. The Contractor also shall disclose
> necessary personnel records and allow the successor to conduct on-site
> interviews with these employees. If selected employees are agreeable to the
> change, the Contractor shall release them at a mutually agreeable date and
> negotiate transfer of their earned fringe benefits to the successor.
>
> (d) The Contractor shall be reimbursed for all reasonable phase-in,
> phase-out costs (i.e., costs incurred within the agreed period after
> contract expiration that result from phase-in, phase-out operations) and a
> fee (profit) not to exceed a pro rata portion of the fee (profit) under
> this contract.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Fri, 10 Oct 2014 16:31:27 +0900

>> -----Original Message-----
(by Andrew Sullivan)
> Let me reiterate what we all should know already. The NTIA has asked ICANN to convene the community to develop a transition plan, and has said in every way it knows how that it will respect the result of that process. The ICG, which is the official recognized agent for assembling the community proposals (and this recognition was publicly reiterated here at the ARIN meeting by a NTIA attendee) has said that each operational community will develop a proposal. If those proposals are approved as a package, th
 e
>   NTIA and ICANN are obligated to implement them, and the NTIA has the clear authority to require them. There is nothing in the NTIA statement that makes room for ICANN to bargain with, resist or impose 'danger' as a result of changes in the IANA contract.
>

I'm personally not too attached to "IETF control"/IETF Trust as the only 
solution, but I very much agree that just leaving iana.org with ICANN 
the way it is now would be a big missed chance at a structural improvement.

In another mail, Marc Blanchet worte:
"I'm getting more and more in the camp of "let's propose it (iana.org in 
IETF trust) and see how it flies".... (ok, that is an overstatement, 
but...)"

I think we should make our proposal somewhat staged:

- We absolutely want it to be clear that the protocol assignments data 
(in all its forms) is in the public domain (or equivalent).

- We have a very strong preference for moving "iana.org" (trademark and 
domain name registration) out of the lone control of ICANN.

- For the above, if there is a need for an organization to hold the 
rights (e.g. to the trademark), we have a very strong preference for an 
existing organization (absolutely no need to create even more bodies!).

- We think that the IETF Trust would be very suited for holding the 
above rights, but we will examine proposals for other organizations.

I also think that transferring the trademark and domain name 
registration from ICANN to another organization are not the only way to 
deal with the trademark issue. A softer way would be for ICANN, the IETF 
(and others) to contractually agree that ICANN currently holds the 
trademark and domain name for the community and that it will transfer 
them as part of a transfer of the registration contract.

That's maybe what ICANN always had in mind (when charged with doing 
IANA, not registering the trademark could have been seen as negligent 
and dangerous indeed).

That's (maybe) also what the transition plan mentioned by Bernard could 
reveal. A transition plan that said "we transfer to a new entity A, but 
we'll keep the trademark rights and the domain name so that we can saw 
confusion" would indeed be a very bad transition plan.

Regards,   Martin.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Oct 2014 11:09:27 +0100

> IMHO this is fine, and a good enough approximation to necessary and

I need to re-read the draft to see how/where it fits in, but that
kind of text looks ok to me.

S.

>> "The IAOC should coordinate with the IAB and the IETF Trust to
>> request public declarations from ICANN, NTIA, ISOC, and the IETF
>> Trust that any rights to the contents of the IETF protocol
>> parameters registries be transferred to the public domain, or
>> should take other steps as it sees fit to accomplish the goal of
>> clarifying that the registry contents reside in the public domain.
>> 
>> The IAOC, together with the IAB as appropriate, should investigate
>> the possibility of adding language to the 2015 IETF-ICANN service
>> level agreement to establish that in the event of the need for
>> either the IETF or ICANN to host the IETF protocol parameters
>> registries at a location other than iana.org, both parties will
>> work together to minimize confusion on the part of iana.org
>> visitors.”
>> 
>>>> Our charter tells us to do the minimum possible.  We should
>>>> heed its instructions.
>>> +1
>>> 
>> Ianaplan mailing list [email-masked]

---

From: John Curran <[email-masked]>
Date: Fri, 10 Oct 2014 06:55:35 -0400

On Oct 9, 2014, at 10:46 PM, Bernard Aboba <[email-masked]> wrote:

> John Curran stated: 
> 
> "Presently, the IANA operator is subject to several provisions in the IANA functions contract
> (I have attached the relevant text for these provisions below for reference.)"
> 
> [BA] Indeed.  Given that ICANN has already filed a transition plan as required under the contract, it seems sensible for me for the appropriate groups (probably the IETF Trust in the case of the IETF) to obtain and examine that plan, with the goal of analyzing it and opining on its usefulness in the situation we now face.   While it highly likely that there are additional corner cases (such as individual functions moving to a new operator) not handled by the filed plan, it represents at least one take on what would be required for a unitary transition.
> 
> My assumption is that given the overall good relationship with the Contractor, that the Transition Plan could be obtained merely by asking (possibly with some redactions), assuming that the USG did not get in the way.  While we *could* act as if the plan did not exist and attempt to recreate it from scratch, it's hard for me to imagine why this approach would be preferred.  

I'm not quite as concerned about the details of such a plan, as the obligation that it 
creates for the current IANA operator to _transition_, i.e. to actively cooperate with 
a planned change in the state of affairs from them performing to another doing so.

The important question is whether the IETF (and to some extent the RIRs) feel it is 
desirable to include similar obligations in their IANA contracting; this would provide
contractual assurance that termination (e.g. for SLA reasons) is actually a termination
rather than bifurcation/duplication of IANA registry services, with ensuing confusion
in the community as a result.

Not doing so when contracting would leave open a fairly significant issue for any future 
transition and could easily be argued to be poor stewardship of these functions (i.e. it's 
not often that one is accused of doing a worse job of planning than "the government", 
but it would appear to be apt in this case if not included in IANA operator accountability 
requirements outlined in any IANA stewardship transition plan.)

FYI,
/John

Disclaimer: my views alone

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 10 Oct 2014 14:13:06 +0200

Dear Brian,

Whether that language is necessary and sufficient depends on what its intent is.

I'm proceeding from the assumption that we are trying to minimize the downside risks, that is, to come up with measures that are intended to make a dysfunction unilikely and that will minimize the effects of any dysfunction.

If people want a concrete scenario, here is one. GAC decides, for whatever reason, to advise the ICANN Board to order IANA not to publish some IETF protocol parameter.  The Board decides to accept the GAC advice.  So the IETF decides to cancel its MoU with ICANN and to make some other arrangements for the protocol parameters part of the IANA function.  

If you map the language below to a pre-nuptial agreement, it would say "If we divorce we will work together to minimize disputes regarding financial matters and child custody".

I'm sure that many people on this list have enough experience with divorce (and disputes in general) to appreciate that such language is of no practical use, if a dispute does arise.

So, no, I don't think that that language is appropriate.

And I have to admit that I am unable to understand why there appears to be opposition to agreeing some language that would have a real effect in (1) preventing a dispute from arising in the first place and (2) minimizing any disruption that might arise as a consequence of a dispute.  

My failure to understand is no doubt due to the fact that I'm not intelligent enough.  But I will continue to think hard about the issue, and perhaps assiduous thinking will lead me to understand.

Best,
Richard

> From: Ianaplan [mailto:[email-masked]]On Behalf Of Brian E
> Carpenter
> Sent: jeudi, 9. octobre 2014 21:28
> To: Alissa Cooper
> Cc: [email-masked]
> Subject: Re: [Ianaplan] Suggested text
> 
> 
> > The IAOC, together with the IAB as appropriate, should 
> investigate the possibility of adding language to the 2015 
> IETF-ICANN service level agreement to establish that in the event 
> of the need for either the IETF or ICANN to host the IETF 
> protocol parameters registries at a location other than iana.org, 
> both parties will work together to minimize confusion on the part 
> of iana.org visitors.”
> >

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Oct 2014 13:31:15 +0100

On 10/10/14 13:13, Richard Hill wrote:
> My failure to understand is no doubt due to the fact that I'm not intelligent enough.

I doubt it:-) But it could be that those who are more familiar
with recent/frequent use of the protocol parameters registries
are more easily able to see what are, and what are not, likely
to be real showstoppers in the event of a change in provider.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Fri, 10 Oct 2014 14:45:35 +0200

Yes, but, despite your diligent efforts to explain, I am unable to
understand.  So that must be a failure of intelligence on my part.

Best,
Richard

> Sent: vendredi, 10. octobre 2014 14:31
> To: [email-masked]; Brian E Carpenter; Alissa Cooper
> Cc: [email-masked]

---

From: "Eliot Lear (elear)" <[email-masked]>
Date: Fri, 10 Oct 2014 14:47:41 +0000

Hi Alissa

On Oct 9, 2014, at 9:48 PM, Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:

We've agreed that this is more than a nice-to-have. The language above suggests otherwise.  Better to say:

As the protocol parameters are a community resource, they belong to the public.   NTIA, ICANN, and the IETF must take steps to leave no doubt but that they are in the public domain.

The IAOC, together with the IAB as appropriate, should investigate the possibility of adding language to the 2015 IETF-ICANN service level agreement to establish that in the event of the need for either the IETF or ICANN to host the IETF protocol parameters registries at a location other than iana.org<http://iana.org>, both parties will work together to minimize confusion on the part of iana.org<http://iana.org> visitors.”

The above makes too weak a demand, and therefore does not sufficiently protect against the obstacle I mentioned earlier.   I'll propose another alternative in due course.

Eliot

---

From: Jefsey <[email-masked]>
Date: Fri, 10 Oct 2014 18:08:54 +0200

At 16:47 10/10/2014, Eliot Lear (elear) wrote:
>NTIA, ICANN, and the IETF must take steps to leave no doubt but that 
>they are in the public domain.

Unfortunately they are not. BCP 78 is not CC. This is the whole issue.
jfc

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Oct 2014 08:37:06 +1300

On 11/10/2014 01:13, Richard Hill wrote:
...
> I'm proceeding from the assumption that we are trying to minimize the downside risks, that is, to come up with measures that are intended to make a dysfunction unilikely and that will minimize the…

I have no experience with ICANN's current legal counsel, but in 1998-2000
their counsel would absolutely not allow them to make any binding commitment
to the IETF until after their original contract with DoC was in place.

This time around, I am pretty certain that their counsel will not allow
them to make any new binding commitment to the IETF Trust until after their
contract with the DoC has gone away (unless doing so becomes a condition
for that contract to go away).

That being so, I fail to see what this WG can recommend beyond the text
suggested by Alissa.

   Brian

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 10 Oct 2014 15:39:19 -0400

> for that contract to go away).

Which might be the whole point of forcing these issues now.

Miles Fidelman

---

From: Milton L Mueller <[email-masked]>
Date: Fri, 10 Oct 2014 20:37:14 +0000

> From: Ianaplan [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> This time around, I am pretty certain that their counsel will not allow them to
> make any new binding commitment to the IETF Trust until after their contract
> with the DoC has gone away (unless doing so becomes a condition for that
> contract to go away).

Clearly, past experiences which are not applicable to the current situation are distorting some judgments about how to proceed today. 

You need to understand that you are not bargaining with ICANN, as you were in 1999-2000. You are making a proposal to the NTIA, which is then supposed to require ICANN to abide by it. I don't know how many times I have to reiterate this simple fact.

Lots of problems could intervene (the US congress, for example), but one problem we do not have is ICANN's counsel not allowing them to do what a finalized proposal from ICG asks them to do.

---

From: Jefsey <[email-masked]>
Date: Sat, 11 Oct 2014 07:20:39 +0200

At 22:37 10/10/2014, Milton L Mueller wrote:
>Clearly, past experiences which are not applicable to the current 
>situation are distorting some judgments about how to proceed today.

Correct. And this is true for everything, including the technology 
deployment as it has been affected by the IANA oversight through the 
"status-quo" strategy. The post-partum internet will be inherently 
different from the ante-partum internet.

>You need to understand that you are not bargaining with ICANN, as 
>you were in 1999-2000. You are making a proposal to the NTIA, which 
>is then supposed to require ICANN to abide by it. I don't know how 
>many times I have to reiterate this simple fact.

Correct. I don't know either how many times I have to reiterate the 
simple fact that the NTIA own's new environment is (1) the 
post-Dubai/Snowden context, (2) the RFC 6852 uncompletely documented 
normative paradigm and (3) the natural "IUse" trend, i.e. a free and 
individually/communinitarily autonomous lead user approach of the 
Internet utilization.

>Lots of problems could intervene (the US congress, for example), but 
>one problem we do not have is ICANN's counsel not allowing them to 
>do what a finalized proposal from ICG asks them to do.

Correct. But be sure that their/our legal counsels will certainly 
influence the ante-partum finalization of the proposal finalization 
process. The same as people like you and me, communities of technical 
interests, and Govs will try to influence the whole 
technical/political context through technical break-throughs (such as 
the MYCANN Plug-in) and/or political influence (as your mails). No 
one reasonable can accept that their daily global digital presence 
and investments depend on an unaccountable zombicann structure.

jfc

---

From: "Richard Hill" <[email-masked]>
Date: Sat, 11 Oct 2014 11:47:40 +0200

I agree with what Milton says below, and would add the following points.

NTIA asked ICANN to convene a process to develop a proposal.  ICANN has done
that, by creating the ICG, which body has issued the RFP that this group is
preparing to respond to.

So this group is working to deliver a proposal to the ICG, which the ICG
will integrate with other proposals and deliver to NTIA.

Since ICG is an emanation of ICANN, and is acting in accordance with the
mandate given to it by ICANN, I don't see why ICANN's counsel would (or even
could) advise ICANN to do anything other than what is in the final ICG
proposal.

That is, how can ICANN not do what ICANN itself, via the ICG, decided should
be done?  For more on why I think that ICG is in fact ICANN for the purposes
of this excercise, see:

  http://forum.icann.org/lists/icg-forum/msg00015.html

Turning to the substantive matter, the NTIA said that the transition
proposal must "maintain the security, stability, and resiliency of the
Internet DNS".

I think that we all agree that an unfriendly separation between ICANN and
IETF regarding the IANA function would result in some instability, even if
we disagree regarding the duration or severity of that instability.

So it seems to me that the transition plan should resist a stress test, of
the form "what happens in case of unfriendly separation".

That is, the transition plan should be such that stability is maintained
even in the worst case scenario, provided of course that the resultant plan
is implementable.

Best,
Richard

> From: Milton L Mueller [mailto:[email-masked]]
> Sent: vendredi, 10. octobre 2014 22:37
> To: Brian E Carpenter; [email-masked]
> Cc: [email-masked]; Alissa Cooper
> Subject: RE: [Ianaplan] Suggested text
>
>
>
>
> you were in 1999-2000. You are making a proposal to the NTIA,
> which is then supposed to require ICANN to abide by it. I don't
> know how many times I have to reiterate this simple fact.
>
> Lots of problems could intervene (the US congress, for example),
> but one problem we do not have is ICANN's counsel not allowing
> them to do what a finalized proposal from ICG asks them to do.
>
>

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sun, 12 Oct 2014 16:13:43 +0900

> could) advise ICANN to do anything other than what is in the final ICG

Well, sure it might be possible for a lawyer to try to come up with some 
minor legality in order to try to avoid (perceivedly) unpleasant things. 
But we shouldn't worry about that in advance.

> we disagree regarding the duration or severity of that instability.

Even if we all agreed that the duration and severity of such an 
instability would be very minor, I think there's another aspect to consider:

Some other organizations (governments, ITU,...) may want to claim that 
after NTIA is gone, stability has decreased. Whatever we can do to 
reduce their argumentation surface is probably a good thing.

Regards,   Martin.

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 12 Oct 2014 08:19:49 -0400

Something I really don't understand here:  The NTIA transition is 
explicitly a contractual matter - why the reluctance to deal with 
contractual and legal issues?

For that matter, why is it that IETF is the entity responding to the 
TCG, not the legal entity involved (IETF trust or ISOC - it's getting 
harder and harder to keep track of the players, without a scorecard).

Miles Fidelman

"Martin J. Dürst" wrote:
> Well, sure it might be possible for a lawyer to try to come up with 
> some minor legality in order to try to avoid (perceivedly) unpleasant 
> things. But we shouldn't worry about that in advance.
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Oct 2014 13:29:12 +0100

> contractual and legal issues?

Keeping a working system working is not a legal matter. I would
be reluctant to see us open up issues unnecessarily and there do
seem to be a bunch of folks who seem keen to do just that.

> harder and harder to keep track of the players, without a scorecard).

We're dealing with this in our usual open manner is why. Establishing
IETF consensus for whatever the response will be.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 12 Oct 2014 14:42:09 +0200

Dear Stephen,

I think that it would be more correct to say that there seem to be a bunch of folks who think that it is necessary to open up certain issues, in particular certain contractual issues.

The reason being that those folks think that the future smooth operation of the IANA function might be endangered if those contractual issues are not settled now.

Now I realize that others think that the current NTIA contract with ICANN is not significant and has no effect, but the NTIA did not think that, otherwise (1) it would not have imposed that contract in the first place and (2) it would not have renewed it periodically.

And the IETF clearly thinks that contractual issues are relevant, because it has an MoU with ICANN, and that MoU has been updated with SLAs.  Nor are there any proposals to abrogate that MoU.

I appreciate that some people think that no changes at all are needed to the current contracts between IETF and ICANN, but I think that there is consensus that at least some change is needed, in particular regarding data rights.

So the issue of contractual changes appears to me be necessary, even if we have not (yet) agreed on the exact nature and scope of those changes.

Best,
Richard

> Sent: dimanche, 12. octobre 2014 14:29
> To: Miles Fidelman
> Cc: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Oct 2014 13:47:11 +0100

On 12/10/14 13:42, Richard Hill wrote:
> I think that there is consensus that at least some change is needed,
> in particular regarding data rights.

In this process, it is the WG chairs' call as to whether the WG have or
have not reached rough consensus on a topic. I realise you may not be
familiar with that process, but its not considered stylish to try to
pre-empt consensus calls that the chairs are likely to make.

S.

---

From: "Richard Hill" <[email-masked]>
Date: Sun, 12 Oct 2014 15:08:56 +0200

Dear Stephen,

Thank you for this helpful clarification, even if I thought that it was obvious that I was not using the term "consensus" in the formal sense that you refer to below.  Indeed, I'm well aware of the fact that formal consensus calls are issued by the WG chairs.

I apologize to those who feel that I was trying to pre-empt anything.

Regrding style, I've seem various posts to the effect that something was "in the rough", so I mistakenly assumed that it was also OK to posit that something was the opposite of "in the rough".  I apologize for that.

Question: is it also considered not sylish to suggest that the time has come for a consensus call?  Not that I think the time has come now, I'm just asking for advice on the procedural niceties on this list.

Thanks again and best,
Richard

> Sent: dimanche, 12. octobre 2014 14:47
> To: [email-masked]; Miles Fidelman
> Cc: [email-masked]

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 12 Oct 2014 10:03:31 -0400

> IETF consensus for whatever the response will be.
Except, that the WG charter includes this specific tasking and language:

"... However, the mechanisms required to
address the removal of the overarching NTIA contract may require
additional documentation or agreements. The WG will identify, but
not create, such required agreements.

....

of IETF protocol parameters registries may require detailed terms of
agreements or other details of procedures that are normally delegated
to and handled by the IAB or IAOC. The working group will not attempt
to produce or discuss documentation for these details, but will
request the IAB or IAOC to provide them separately.

The WG shall seek the expertise of the IAB IANA Evolution Program to
formulate its output. It is expected that members of the IAB IANA
Evolution Program will actively participate in the WG."

----
I see little evidence that the working group either wants to engage with 
these issues or ancillary groups.  Where are the folks who actually pay 
attention to "documentation and agreements?"  And why is it that there 
has been zero mention of the "IAB IANA Evolution program" or its 
expertise in the formulation of WG output?

It simply strikes me that the folks participating in this working group 
are primarily those who share the belief that "Keeping a working system 
working is not a legal matter" - because those who believe differently 
(and perhaps know from experience) are not engaged, by dint of the 
normal focus of IETF activities, and the relegation of such issues to 
other bodies.

Which brings me back to commenting that this working group seems to have 
a major blind spot when it comes to part of its charter.

Miles Fidelman

---

From: Seth Johnson <[email-masked]>
Date: Sun, 12 Oct 2014 10:08:04 -0400

I for one am very glad it's IETF and not the legal entities.  But
first: that's the design of the process -- supposedly this is all
about how "multistakeholderism" is going to work well in the overall
transition, so it has to be done through the piece that most looks
like that, to at the least maintain that impression.  However, second:
the form of collaborative/participatory stewardship that IETF has
traditionally conducted is the thing most at stake, while the
contractual/legal issues that have been raised don't really deal with
that.  Nothing else is, to be sure, but the contractual and legal
considerations being raised aren't real cognizant of that issue.

But also: I think that legal issues could be discussed in the IETF
discourse (I'm not convinced the arena of legal discussion is really
best understood in terms of contracts though).  I just think having
the legal discussion is mostly useless until people start recognizing
what's missing in the international arena, address the legal
circumstances in relation to that, in terms of how we're going to lose
the kind of stewardship context we're accustomed to.

Seth

---

From: Jefsey <[email-masked]>
Date: Sun, 12 Oct 2014 18:04:29 +0200

>contractual and legal issues?

For the simple reason that we, the member of this list, are not 
lawyers, and for most not considering this issue as an international 
law case. Actually they are told not to.

This may also be that the NTIA is attempting a "multi-stakeholder" 
non-democratic minority coup against the Dubaï democratic (both in 
terms of States and of represented people) vote. This is not 
surprising since the USG Executive branch, of which the NTIA is a 
part, also oversights the NSA democratic usages.

>TCG, not the legal entity involved (IETF trust or ISOC - it's 
>getting harder and harder to keep track of the players, without a scorecard).

The IETF Trust is the tool to support BCP 78, which is the non-CC RFC 
license. The whole things is the ISOC GSN (1) dtrategy. This approach 
was documented by Lynn St-Amour (on this list) and Don Tapscott in a 
very long Press Release accompanied by two big books published on 
.... March 4, 2014. It was their immediate reaction to the NTIA 
annoucement in reaction to the unexpected NETmundial unexpected 
decision by Fadi and Dilma 
http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/

The Lynn/Don's strategy for the Internet this WG is engineered to 
help endorsing results from a several years cooperation that is 
documented on Don's site:
http://martinprosperity.org/media/GSN%20Prospectus%20101012.pdf
http://martinprosperity.org/media/R%20GSN%20Prospectus%202013.pdf
etc.

This can be described as a mutially selected/recognised stakeholders 
aristocracy doctrine to counter a fractal (independent of the scale) 
democratic legimacy and deny its ultimate mulitude's polycratic 
mechanisms (the way democracy works without states) the network 
technology leads to and enforces. The efficient internet of the 
dominants vs. the interneted people's life. They know better than me 
what makes me happy ....

jfc

---- notes ----

(1) "a global solution network consists of diverse stakeholders, 
organized to address a global problem, making use of transnational 
networking, and with membership and governance that are 
self-organized". This is the not-at-all democratic thinking behind 
the US "multi-stakeholderism". It is introduced by Don Tapscott 
(http://dontapscott.com/) Lynn St-Amour
Martin Properity,

This thinking is engineered by GSN sponsored among others by 
(http://gsnetworks.org/sponsorship/) : Google, MasterCard, HP, SAP, 
Liberty Globa, Royal Bank of  Canada, Rockefeller Foundation, 
accenture, Ontario, Seagate,  Qualcomm, the  US State Department, 
Cisco,  the Canadian Ministry of Industry; in partnership with the UN 
Global Compact (2), the Lisbon Council (3), Digital Opportunity Trust 
(4), C40 Cities (5)

(2) "The UN Global Compact asks companies to embrace universal 
principles and to partner with the United Nations. It has grown to 
become a critical platform for the UN to engage effectively with 
enlightened global business." UN Secretary-General Ban Ki-moon

(3) "The Lisbon Council is a Brussels-based think tank and policy 
network committed to making a positive contribution by engaging 
political leaders and the public at large in a constructive exchange 
about the economic and social challenges of the 21st century"

(4) Digital Opportunity Trust (DOT) is a leading international social 
enterprise headquartered in Ottawa, Canada with local operations 
around the globe.  Its mission is "To create global networks of 
talented, energetic young leaders who make real change by educating 
local communities to apply technology effectively to real life."

(5) C40 Cities : a compact representing 1/12 of the people of the 
world and 18% of the world GNP.

>>some minor legality in order to try to avoid (perceivedly) 
>>unpleasant things. But we shouldn't worry about that in advance.
>>
>>
>>Some other organizations (governments, ITU,...) may want to claim 
>>that after NTIA is gone, stability has decreased. Whatever we can 
>>do to reduce their argumentation surface is probably a good thing.
>>
>>Regards,   Martin.
>>
>>

---

From: JFC Morfin <[email-masked]>
Date: Sun, 12 Oct 2014 19:16:48 +0200

At 09:13 12/10/2014, Martin J. DÃ¼rst wrote:
>that after NTIA is gone, stability has decreased. Whatever we can do 
>to reduce their argumentation surface is probably a good thing.

Martin,

this is exactly what we (as Libre and citizens) feel. This trust 
decrease will also affect the IETF in proportion to the 
firmeness/adequation of the position adopted by this WG.

This is why the "mycann plug-in" definition and development projects 
start receiving some momentum and support. I frankly doubt they can 
be prevented (dont ask me the date as this is new development or 
political decision) because some Govs already have one and we all 
know that any geek can navigate the internet without paying attention to ICANN.

However, their generalization, together with the coexistence with new 
technologies (NDN, SDN, VGN conception) is actually leading to the, 
long "status-quoed", IEN 48 second objective.

This will be something like a "super-NAT" case. If we do not pay 
attention to it, we will not be entitled to complain afterward. The 
IETF should consider the end to end interface aspects of this fringe 
to fringe resulting middleware.

jfc

PS. I know nobody cares. My mails are just to demonstrate it.

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 12 Oct 2014 15:15:02 -0400

> law case. Actually they are told not to.

Which really begs the question of how IETF is to coordinate a complete 
response to TCG request for proposals, specifically Section IV. 
(Transition Implications), which includes:
"Description of any legal framework requirements in the absence of the 
NTIA contract."

As I understand the WG charter, identifying issues is in scope, but 
proposing things is out of scope.  So... how are such issues to be 
addressed in IETF's response?

Miles Fidelman

---

From: Seun Ojedeji <[email-masked]>
Date: Sun, 12 Oct 2014 12:27:18 -0700

Hi Richard,

> will integrate with other proposals and deliver to NTIA.

Hopefully you already know the last line above is not the case; the ICG
delivers to ICANN

> This section has a +1 for me also. Although i would re-frame by saying "i
won't see why ICANN would change anything on the proposal delivered to it
by the ICG".

Cheers!

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 12 Oct 2014 14:08:11 -0700

On Oct 12, 2014, at 5:47 AM, Stephen Farrell <[email-masked]> wrote:

> have not reached rough consensus on a topic.

[BA] To be clear, the IETF trust is responsible for rights issues, including obtaining appropriate counsel. So while this WG might raise questions for the Trust to investigate and address, there is not much more that the IANAPLAN WG can do. It is my assumption that the Trustees are following this discussion and are thinking about next steps.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Oct 2014 11:08:13 +1300

> addressed in IETF's response?

The charter says "The IANAPLAN working group is chartered to produce an IETF
consensus document that describes the expected interaction between the IETF
and the operator of IETF protocol parameters registries...
the mechanisms required to address the removal of the overarching NTIA
contract may require additional documentation or agreements. The WG will
identify, but not create, such required agreements."

IMHO that can include our expectations for any future additional
legal framework, plus the factual statement that the IETF Trust is
the responsible body for actual legal ink on paper.

    Brian

---

From: Miles Fidelman <[email-masked]>
Date: Sun, 12 Oct 2014 18:20:36 -0400

> the responsible body for actual legal ink on paper.
Maybe it's the fact that I spend half my life responding to RFPs, but....

As I understand the process - each community is supposed to respond to 
the TCG RFP with a "complete response."  Unless I'm off base here, the 
IETF is one of the communities that received the RFP, without a 
distinction between the IETF per se, and the IETF Trust. To me, that 
suggests that we're talking about a response that combines IETF issues 
with IETF Trust issues.  Kicking the can down the street does not seem 
appropriate.

Which, to me, says that:
1. The WG charter is not sufficient to yield a complete response to the 
TCG, and
2. It is not at all clear how the parts of the response, outside the 
WG's purview, are to be developed and coordinated.

If the response is to be both complete, and the result of a consensus 
process -- leaving those issues in limbo seems inappropriate.

Miles Fidelman

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 12 Oct 2014 19:28:57 -0400

On Oct 12, 2014, at 6:20 PM, Miles Fidelman <[email-masked]> wrote:

> 
> As I understand the process - each community is supposed to respond to the TCG RFP with a "complete response."  Unless I'm off base here, the IETF is one of the communities that received the RFP, without a distinction between the IETF per se, and the IETF Trust. To me, that suggests that we're talking about a response that combines IETF issues with IETF Trust issues.  Kicking the can down the street does not seem appropriate.
> 
> Which, to me, says that:
> 1. The WG charter is not sufficient to yield a complete response to the TCG, and
> 2. It is not at all clear how the parts of the response, outside the WG's purview, are to be developed and coordinated.

It seemed from the charter that any components of the response outside of the WG's scope are provided for here:

"Fully documenting the interaction between the IETF and the operator

> If the response is to be both complete, and the result of a consensus process -- leaving those issues in limbo seems inappropriate.

I don't think they are in limbo-- it seems that everything needed for a complete response can come from either the WG by consensus, or the IAB and IAOC in the course of processes already delegated to them-- but I'm looking to our chairs or IAB members to clarify.

best,
Suzanne

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 13 Oct 2014 03:52:49 +0000

Excellent point, Miles. I hope to see some response to this point from responsible IETF participants. 

> It simply strikes me that the folks participating in this working group are
> primarily those who share the belief that "Keeping a working system working
> is not a legal matter" - because those who believe differently (and perhaps
> know from experience) are not engaged, by dint of the normal focus of IETF
> activities, and the relegation of such issues to other bodies.
>

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 13 Oct 2014 03:59:53 +0000

> Keeping a working system working is not a legal matter. 

From the standpoint of a social scientist, this is a profoundly ignorant comment. I would challenge anyone on this list to come up with a single example of a technical system the workings of which did not rely heavily on social, organizational, legal and institutional foundations. 

> I would be reluctant
> to see us open up issues unnecessarily and there do seem to be a bunch of
> folks who seem keen to do just that.

The necessity of opening up those issues has been demonstrated persuasively time and again. 

> We're dealing with this in our usual open manner is why. Establishing IETF
> consensus for whatever the response will be.

Interesting how you use the word "we" in a way that seems to exclude at least half of the people engaged in the dialogue on this list. Is that how IETF consensus works?

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 13 Oct 2014 08:25:46 +0100

On 13/10/14 04:59, Milton L Mueller wrote:
> From the standpoint of a social scientist, this is a profoundly
> ignorant comment. I would challenge anyone on this list to come up
> with a single example of a technical system the workings of which did
> not rely heavily on social, organizational, legal and institutional
> foundations.

That seems like a profound misreading of what I said.

> 
>> I would be reluctant to see us open up issues unnecessarily and
>> there do seem to be a bunch of folks who seem keen to do just
>> that.
> 

Truth by blatant assertion? And you (profoundly:-) ignore that
I said "unnecessarily" which does not imply that there are
no issues at all to tackle.

>> We're dealing with this in our usual open manner is why.
>> Establishing IETF consensus for whatever the response will be.
> 
> Interesting how you use the word "we" in a way that seems to exclude
> at least half of the people engaged in the dialogue on this list. Is
> that how IETF consensus works?

In this case "we" means whoever posts to this list and is by
doing so participating in the WG. In particular:

On 13/10/14 04:52, Milton L Mueller wrote:
> I hope to see some response to this point
> from responsible IETF participants.
>

You are an IETF participant since you are posting to this list.

S.

---

From: JFC Morfin <[email-masked]>
Date: Mon, 13 Oct 2014 00:47:48 +0200

At 00:20 13/10/2014, Miles Fidelman wrote:
>As I understand the process - each community is supposed to respond 
>to the TCG RFP with a "complete response."  Unless I'm off base 
>here, the IETF is one of the communities that received the RFP, 
>without a distinction between the IETF per se, and the IETF Trust. 
>To me, that suggests that we're talking about a response that 
>combines IETF issues with IETF Trust issues.  Kicking the can down 
>the street does not seem appropriate.
>
>Which, to me, says that:
>If the response is to be both complete, and the result of a 
>consensus process -- leaving those issues in limbo seems inappropriate.

In addition, it is supposed that the responses are only 
organizational (i.e. can be contracted). What I observe is that they 
are mostly architectural, i.e. in the IETF area. Subject to BoF, 
charter, debate, rough consensus, standard track RFCs and appeals.

jfc

---

From: "Richard Hill" <[email-masked]>
Date: Mon, 13 Oct 2014 12:08:52 +0200

Dear Seun,

The IGC charter says that the ICG will deliver its report to the NTIA.  Since the discussions on this list are about replying to the ICG, I think that we have to stick to what the ICG charter says.

Best,
Richard
  -----Original Message-----
  From: Ianaplan [mailto:[email-masked]]On Behalf Of Seun Ojedeji
  Sent: dimanche, 12. octobre 2014 21:27
  To: Richard Hill
  Cc: Milton L Mueller; Alissa Cooper; Brian E Carpenter; [email-masked]
  Subject: Re: [Ianaplan] Suggested text

  Hi Richard,

  Hopefully you already know the last line above is not the case; the ICG delivers to ICANN  

  This section has a +1 for me also. Although i would re-frame by saying "i won't see why ICANN would change anything on the proposal delivered to it by the ICG".

  Cheers! 

  -- 

    Seun Ojedeji,

---

From: Milton L Mueller <[email-masked]>
Date: Mon, 13 Oct 2014 18:54:48 +0000

> That seems like a profound misreading of what I said.

What you said is right there, in black and white. If I misread it please explain how. You certainly didn't explain in this response. 

If you like, I can dig up and compile the discussion on this topic to refresh your memory. To my mind you position amounts to nothing more than "things are working well now (under NTIA supervision) so there's no need to change anything when the NTIA goes away," which is both a logical fallacy and just bad operational practice (to have no safeguards or ability to change providers). 

> In this case "we" means whoever posts to this list and is by doing so
> participating in the WG. In particular:

Then don't tell me we have anything near consensus. 

> > I hope to see some response to this point from responsible IETF
> > participants.
> 

Sigh. I know. I was referring to the language of the charter. I am not responsible for that.  Try to keep statements in context.

---

From: Seth Johnson <[email-masked]>
Date: Mon, 13 Oct 2014 20:16:32 -0400

On Sun, Oct 12, 2014 at 3:15 PM, Miles Fidelman
<[email-masked]> wrote:
> response to TCG request for proposals, specifically Section IV. (Transition
> Implications), which includes:
> "Description of any legal framework requirements in the absence of the NTIA
> contract."

The legal implications of the removal of the NTIA contract are significant.

It's a clear marker of a relationship of the US to the IANA functions.
Its presence has meant US citizens could hold their government to
account for whatever might develop.  That is, as an element of the US
government, the limits that apply to the US government also apply to
the NTIA and its relationship to the IANA functions.  Even though no
such claim may have been levied against the NTIA, and evidently the
NTIA has done nothing and/or has not allowed anything to happen that
would raise that response.  Doesn't mean that the presence of the
relationship was not significant.

I'm not saying anything about US control or influence here.  Just
characterizing the nature of the transition in terms of the
relationship of all of us to the overall process.  And I'm certainly
not advocating retaining the US role (!).  Just noting that the legal
implications of the transition are quite significant.

Seth

> proposing things is out of scope.  So... how are such issues to be addressed
> in IETF's response?
>
> Miles Fidelman
>
>
> --