Subject: Re: [Ianaplan] A draft for your review

From: Eliot Lear <[email-masked]>
Date: Sat, 01 Nov 2014 08:42:59 +0100

On 11/1/14, 6:50 AM, David Conrad wrote:
> Eliot,
>
> On Oct 31, 2014, at 10:44 PM, Eliot Lear <[email-masked]> wrote:
>> On 11/1/14, 6:42 AM, David Conrad wrote:
>>> The same ones in which the folks most active in creating top-level
>>> domains and to whom the administration of the domain space was
>>> delegated were unaware?
>> This is not true for everyone in that community, but to be sure we can
>> always do a better job at making people aware of that.
> I think you might be missing my point.
>
> IIRC, part of this thread (the part Avri was commenting on) was discussing whether there were cases in which coordination was necessary between functions.  I believe RFC 6761 is an example in which coordination was necessary and did not occur.

What I am saying is that the entries there were discussed between
participants in both organizations.

>  Another is between the operational/RIR community and the IETF related to TLAs.

Of this I have no knowledge.  Again, certainly we can all do a better job.

Eliot

---

From: Marc Blanchet <[email-masked]>
Date: Sat, 1 Nov 2014 10:07:19 -0400

> Le 2014-11-01 à 01:50, David Conrad <[email-masked]> a écrit :
> 
> Eliot,
> 
> IIRC, part of this thread (the part Avri was commenting on) was discussing whether there were cases in which coordination was necessary between functions.  I believe RFC 6761 is an example in which coordination was necessary and did not occur. Another is between the operational/RIR community and the IETF related to TLAs. I believe there are others. And that is with a unified IANA. The problem is that it is difficult to know beforehand whether or not coordination is necessary and/or whether the coordination has been sufficient. If IANA is to be functionally decomposed, I believe care must be taken to ensure that coordination can be done effectively.

I agree.  And my take is that most people would agree. The question is how to appropriately put this in text. And in some ways, that exact text is to be coordinated between the parties. circle…

Marc.

> 
> Regards,
> -drc
> 
> _______________________________________________
> Ianaplan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ianaplan

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 1 Nov 2014 11:51:35 -0400

Hi,

I think we have two almost-separate considerations here: how the coordination on topics like "technical use" names is done and how it could be improved; and what it's necessary to say on the subject in the ICG response document.

On the first-- as already pointed out, we've got existing IETF authority (the MoU) and process (RFC 6761, with all the accompanying machinery of writing drafts and making the case for a change in the relevant registry under its rules). We've also got the machinery to change that process if it's inadequate: normal IETF process for updating or obsoleting an RFC, a WG whose charter includes such namespace issues (DNSOP), and an IAB liaison statement sent to ICANN specifically on this topic, also under IETF process and an existing liaison relationship (https://datatracker.ietf.org/liaison/1351/). I can speak as DNSOP co-chair that we're interested in input, because applying RFC 6761 has already proven problematic and people keep writing drafts that attempt it. And I can't speak for the IAB, but response to the liaison statement would probably be welcome too.

If people feel coordination on a specific  "technical use names" issue is needed, there are mechanisms in place today to do it. If people feel better coordination process is needed (such as might follow from a clearer definition of "technical use names"), there are mechanisms in place today to create them too, and even recent suggestions (the DNSOP re-charter, the IAB liaison statement) that people might want to consider invoking them. 

On the IANAPLAN draft specifically: none of the existing coordination mechanisms depend on NTIA or the IANA functions contract, and I humbly submit there's no reason to expect that to change. Documenting the current situation, including the existence of process for changing it, is all we need to do.

The current draft says:

"It is important to note that the IETF includes anyone who wishes to
   participate.  Staff and participants from ICANN or the Regional
   Internet Registries (RIRs) regularly participate in IETF activities.

   o  The IETF has specified a number of special use registries with
      regard to domain names.  These registries require coordination
      with the Generic Names Support Organization (GNSO).  We already
      perform this coordination.[RFC6761]"

My suggested edit:

* I favor preserving the reference to participation in the IETF by ICANN and RIR staff and community participants; it strengthens the point that they are part of the coordination we're discussing in this section.

* I suggest new text for the first bullet point:
	"The IETF has specified a number of special use registries with regard to domain names.  These registries require coordination with ICANN as the policy authority for the DNS root [RFC2860], including community groups that are responsible for ICANN policy on domain names such as the GNSO and the ccNSO.  There are already mechanisms in place to perform this coordination, and the capacity to modify them to meet new conditions as they might arise." [RFC6761, http://www.ietf.org/liaison/managers.html]

best,
Suzanne
(holding assorted roles in both the IETF and ICANN 
universes,  but speaking for myself alone)

---

From: Milton L Mueller <[email-masked]>
Date: Sat, 1 Nov 2014 16:30:10 +0000

I like (support) Suzanne's proposed new text

> -----Original Message-----
> 
> 	"The IETF has specified a number of special use registries with regard
> to domain names.  These registries require coordination with ICANN as the
> policy authority for the DNS root [RFC2860], including community groups that
> are responsible for ICANN policy on domain names such as the GNSO and the
> ccNSO.  There are already mechanisms in place to perform this coordination,
> and the capacity to modify them to meet new conditions as they might
> arise." [RFC6761, http://www.ietf.org/liaison/managers.html]
>

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 1 Nov 2014 12:52:36 -0400

On Fri, Oct 31, 2014 at 07:15:14PM -0700, David Conrad wrote:
> 
> RFC 6761 allows for the preemption of _any_ top-level domain name. This would appear to go beyond "technical uses" and get into policy issues regardless of how "technical uses" might be reasonably defined or who does the defining.
> 

Yes, of course that's what RFC 6761 allows for.  That's because IANA
is responsible for allocating names in the root zone.  RFC 6761 is in
effect a formalization of the procedures for delineating the
_boundary_ of the root zone.  The introduction of 6761 is pretty clear
that these are all for special use, and draws the analogy with IP
allocation policy.  As it says, " This document specifies under what
circumstances special treatment is appropriate, and in what ways."

More importantly, 6761 includes, in section 4, this observation:

	If in all seven categories the answer is
   "none", then possibly no special treatment is required and requesting
   reservation of a Special-Use Domain Name may not be appropriate.

Additions to the registry require either Standards Action or IESG
Approval, which is a high bar.  I would expect the IESG to ask some
pretty pointed questions about a proposed registration if it didn't
meet the seven-category test.

So, I do not agree that there is an actual conflict between the two
areas of action here, and what is necessary is for us to ensure that
everyone is in agreement about the limits on the size of the root
zone, given particular technical needs.

I _can_ imagine things that the IETF might have tried to do that in my
opinion would have been an attempt to legislate policy under the
rubric of technical need.  For example, I can imagine the IETF having
tried to nail down the number of TLDs on the grounds that resolvers or
other clients would configure that list as static data (much as many
clients did in fact do).  To me, that would certainly have been an
attempt to make policy under the guise of technical need.  But that
didn't happen, which suggests to me that the division of labour,
again, is working.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Sat, 1 Nov 2014 10:53:51 -0700

Andrew,

On Nov 1, 2014, at 9:52 AM, Andrew Sullivan <[email-masked]> wrote:
> Approval, which is a high bar.  

Given the IETF has delegated administration via RFC 2860, I would have thought it useful to formally include the delegatee in discussions related to the resource (either domain names or IP addresses) being discussed, not just have the decision be solely dependent on the IESG's opinion. 

Regards,
-drc

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 02 Nov 2014 08:42:15 +1300

> Given the IETF has delegated administration via RFC 2860, I would have thought it useful to formally include the delegatee in discussions related to the resource (either domain names or IP addresse…

Trying to go up a level, what I see here is a very senior member of
our wider community (that would be Mr Conrad) telling us of at least
two cases (the recent RFC 6761, and the ancient blunder of IPv6
Top Level Aggregation, RFC 2374) where he feels that the IETF side of
the house did not in practice consult adequately with the registry or
operators sides of the house. And if he feels that, then it's true
by definition: we didn't consult enough, period.

We fixed the TLA issues by changing the IPv6 specs before any harm
was done. I have no doubt we can fix the RFC 6761 issue too, if
it proves harmful.

There's a lesson there for us, and it isn't one that improving the
text of the current draft will resolve, although I do like Suzanne's
proposed text. If the IETF (or IESG or IAB) gets too wrapped up in
itself, we will screw up.

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 1 Nov 2014 17:40:57 -0400

> Given the IETF has delegated administration via RFC 2860, I would have thought it useful to formally include the delegatee in discussions related to the resource (either domain names or IP addresse…

But surely, the answer to that is participation or at least some
attention paid by the relevant organizations to relevant developments
in the IETF?  It seems to me that ICANN and all the RIRs have
professional paid staff; couldn't some of those pay attention to
proposals that might have some consequences for the organization in
question, given that that's the structure of the MoU?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 1 Nov 2014 17:50:03 -0400

> by definition: we didn't consult enough, period.

Perhaps.  It could also be that, at the time that RFC 6761 was working
its way through the IETF alimentary tract, some participants in the
IETF tried pretty hard to get people in the ICANN world interested in
it, but discovered that they were all completely consumed with the new
gTLD program.  I'm not sure, however, how much value we'll get in
debating the facts of the past.

> itself, we will screw up.

Certainly true.  But it is surely equally true that, if we allow
technical needs that we might have to be driven by other groups'
priorities, we'll have to stop work.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eliot Lear <[email-masked]>
Date: Sat, 01 Nov 2014 23:01:11 +0100

I'm fine with it as well.

---

From: Avri Doria <[email-masked]>
Date: Sun, 02 Nov 2014 10:29:18 +0900

Hi,

Please pardon me for still being slow to understand the implications, or
lack thereof.

In the case of a decomposed IANA, will the IETF still have operational
change access to the name registries?

Or are we arguing that RIRs and [cc,g]NSO+ only have access to their own
registries, but that the IETF maintains operational change access to all
3?  If so would there  need to be additional MOUs &c. with IANA.names
and IANA.numbers?

avri

---

From: John Curran <[email-masked]>
Date: Sun, 2 Nov 2014 01:34:08 +0000

On Nov 1, 2014, at 7:42 PM, Brian E Carpenter <[email-masked]> wrote:
> ...

I actually think we have been doing a pretty good job of policy 
coordination when it comes IETF and the Internet numbers registries.
There have been lots of small issues that have arisen over the years 
(special purpose addresses, documentation prefixes, transition blocks) 
all of which have been worked out, and often with specific coordination
efforts, i.e. folks from both communities attending others meetings.
While the initial IPv6 address format could have benefited by having
more operator input incorporated, that lack can probably be claimed
for most aspects of IP next generation design process (as opposed to 
being the result of any lack of coordination among policy bodies.)

I do think it is worth documenting the need for good coordination 
between the IETF and delegated registries, predominantly because 
the RFP does specifically ask about independencies and good policy 
coordination keeps the IANA operator(s) an administrative function
rather than becoming an arbitration role.

/John

Disclaimer: my views alone.

---

From: John Curran <[email-masked]>
Date: Sun, 2 Nov 2014 01:34:08 +0000

/John

---

From: John Curran <[email-masked]>
Date: Sun, 2 Nov 2014 09:51:40 +0000

> rather than becoming an arbitration role.

I'll also note that this type of coordination among policy authorities
for those registries that have less than algorithmic boundaries (e.g. 
the need for technical/specialized IPv4 reservations from the nearly 
fully allocated IPv4 unicast space, the insertion of a technical entries
into the DNS root zone, etc.) is also quite distinct from the excellent 
IANA operational coordination in registry space publication, e.g. building 
a single in-addr.arpa zone with data from various sources, getting the 
.arpa entry into DNS root alongside other entries, etc.  

These IANA operational coordination tasks work well with a single IANA 
functions operator, and we should note that care is necessary to provide 
the same coordination if multiple IANA operators should ever be the norm.

/John

---

From: JFC Morfin <[email-masked]>
Date: Sun, 02 Nov 2014 13:52:05 +0100

Suzanne,

IANAL but I know that contracts are protocols between 
people/organizations. Asking engineers to discuss contracts seems as 
sure as asking lawyers to write a technical standard RFC.

At 16:51 01/11/2014, Suzanne Woolf wrote:
>On the first-- as already pointed out, we've got existing IETF 
>authority (the MoU) and process (RFC 6761, with all the accompanying 
>machinery of writing drafts and making the case for a change in the 
>relevant registry under its rules). We've also got the machinery to 
>change that process if it's inadequate: normal IETF process for 
>updating or obsoleting an RFC, a WG whose charter includes such 
>namespace issues (DNSOP), and an IAB liaison statement sent to ICANN 
>specifically on this topic, also under IETF process and an existing 
>liaison relationship (https://datatracker.ietf.org/liaison/1351/). I 
>can speak as DNSOP co-chair that we're interested in input, because 
>applying RFC 6761 has already proven problematic and people keep 
>writing drafts that attempt it. And I can't speak for the IAB, but 
>response to the liaison statement would probably be welcome too.
>
>If people feel coordination on a specific  "technical use names" 
>issue is needed, there are mechanisms in place today to do it. If 
>people feel better coordination process is needed (such as might 
>follow from a clearer definition of "technical use names"), there 
>are mechanisms in place today to create them too, and even recent 
>suggestions (the DNSOP re-charter, the IAB liaison statement) that 
>people might want to consider invoking them.

I am afraid I do not see in which manner having mechanisms to achieve 
something makes it so that all of this will be achieved. RFC 2860 is 
clear about this: in case of a standing disagreement, RFC 2860 
Section 4.3, Note: "In the event ICANN adopts a policy that prevents 
it from complying with the provisions of this Section 4 with respect 
to the assignments described in (a) - (c) above, ICANN will notify 
the IETF, which may then exercise its ability to cancel this MOU 
under Section 2 above."

This language does not permit ICANN to be accountable concerning the 
NTIA's demand:  "Maintain the security, stability, and resiliency of 
the Internet DNS". The IETF has the ultimate capacity of decision 
and, therefore, responsibility (actually ISOC has it through the 
appeal process).

>At 17:52 01/11/2014, Andrew Sullivan wrote:
>But that didn't happen, which suggests to me that the division of 
>labour, again, is working.

IMHO, to make the past the guarantee of your future is to ensure that 
you will be fooled.

>At 18:53 01/11/2014, David Conrad wrote:
>Given the IETF has delegated administration via RFC 2860, I would 
>have thought it useful to formally include the delegatee in 
>discussions related to the resource (either domain names or IP 
>addresses) being discussed, not just have the decision be solely 
>dependent on the IESG's opinion.

David, is this truly the "status quo" :-)?

If I understand you, what ICANN wants is to control things through RFC 2960bis.

I have 255 classes that I can use and IETF has a few thousand that it 
can freely affect. Perhaps it is time to contract that the ICANN/NTIA 
"IN" Class is the undisputed ICANN one.

If there are too many or buggy TLDs in the root of that class, users 
will know about it and competition will play its role.

jfc

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 2 Nov 2014 08:12:12 -0500

cc:s trimmed

On Sun, Nov 02, 2014 at 01:52:05PM +0100, JFC Morfin wrote:
> >But that didn't happen, which suggests to me that the division of labour,
> >again, is working.
> 
> IMHO, to make the past the guarantee of your future is to ensure that you
> will be fooled.

I too have read Hume on induction.  It's worth noting that, despite
his position, he would retire to the Poker Club and play billiards and
backgammon.

But anyway, I wasn't looking for a guarantee.  I think you'll note
that my sentence makes assertions in the present tense ("is working").
It is possible that the future will be quite different; at that point,
it seems to me, we'd have to respond according to what changed.
Others seem to hope that they can write down, in advance, a procedure
for every possible case.  That is, IMO, complete folly.  What we need
are mechanisms that allow actors to work effectively, which includes
good incentives to work out differences co-operatively.

The only ways I know to provide those incentives are to provide
another authority or to provide power of independent action.  Some
argue that the NTIA has been serving the former function; I think that
interpretation is a little fanciful, but I don't have some
transcendental access to the truth _sub specie aeternitatus_.  I think
that the potential of independent action is a more powerful way to
focus the minds of the various actors in the case of ill behaviour,
and a meaningless detail when actors are collaborating as well as they
have been.

Regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: JFC Morfin <[email-masked]>
Date: Mon, 03 Nov 2014 15:40:39 +0100

>his position, he would retire to the Poker Club and play billiards and

Andrew,
I suppose you are referring to David Hume? I have never cast a glance 
on a page of his, yet. But you are right, I should. I am just basing 
myself on programmer experience. A bug is something which worked and 
does not anymore because of a small change somewhere, and it is 
usually difficult to find as it is in essence unexpected.

Here, the bug seems to be from RFC 2860 Section 4.3 in the context of 
the ICANN reading "IANA" where the NTIA spells "DNS", and the double 
BUG of the USG wanting to Be Unilaterally Global and of the 
oligarchy's dream of a Business Unregulated Governance.

>But anyway, I wasn't looking for a guarantee.

I understand that. And this is what I object to. We are not 
discussing a poker game or a billiards trick shot, but rather the 
stability of the world's economy and more precisely of the protection 
of my users. This is why I am looking for a guarantee, or at least 
the strongest protection I can get.

>I think you'll note
>for every possible case.  That is, IMO, complete folly.

I agree.

>What we need

I beg to differ with you; here's the WG's thinking here on two points:

1. status quo of an auto-corrected mechanism is not acceptable if you 
remove the correction mechanism (US NTIA)
2. this is why we do not want a mechanism, but a principle. We are 
halfway through from the (Govs) regulation to the (market) 
competition principle. The last remnant of the Govs monopolies is 
supposed to go away. Under those conditions there are two possibilities:

- competition, i.e. several ICANNs and everyone can choose the one 
they think the best.
- new state regulation, i.e. ITU.

The decision is:
- either, as per US/MS oligarchy status quo, in the IETF hands (RFC 
2860 Section 4.3), the IPR owner being the IETF Trust and ultimate 
decision maker ISOC with a few weeks to six months of delays that no 
one can accept.
- either in MYCANN Plug-ins developers (States, ISPs, Business, 
Libre), users (people), sponsors (States).

>another authority

Yes.

- ITU is the most obvious candidate of the Dubai majority.

- I favor a Libre's fringe to fringe internet use oriented task force.

>or to provide power of independent action.

Yes: the MYCANN Plug-ins.

>Some argue that the NTIA has been serving the former function;
>I think that interpretation is a little fanciful, but I don't have some
>transcendental access to the truth _sub specie aeternitatus_.

 From a 37 years of experience of the international network 
perspective, I partly agree that this is not as direct as "NTIA makes 
it all". In fact, I do not see where the USG is quitting the 
function. I only see a political trick, an actual transfer from an 
NTIA contract to a Congress delegation to the FCC.

I understand that Americans contributors may think NTIA and FCC are 
the same. Still the USG is in the lead, and the same statUS quo is, 
therefore, possible, i.e. the way the Chairs read the Charter.

I am afraid that this cannot work. Not anymore. After RFC 6852, 
Dubai, Snowden, the NDN consortium, SDN works, etc. the FCC cannot be 
the only NTIA's heir. The Multitude with the MYCANN Plug-ins will 
become peoples (Libre plug-ins), nations (States plug-ins) and other 
kinds of global communities (cf. RFC 6852: Google, Apple, Microsoft, 
USCC, etc.?) innovatively competing for better interconnectivity as 
per the modern paradigm for standardization; and WSIS consensus for a 
person centered information society.

>I think

Correct.

However, this is not something to happen in the future. This is 
something happening right ***now***, right in ***here***.

1. Either, through Eliot's Draft, the IETF behaves boldly, 
coordinates the collaboration it has established with ICANN and RIRs, 
and tell the world in front of the NTIA and ITU: "trust me, I am the 
boss of my technology and I prove it in standardizing a unique, IANA 
embedded, ICANN fed, multiclass, multitechnology, multilinguistic 
MYCANN Plug-in, and this is my decision as per RFC 2860 Section 4.3., period"

2.  or the focus will be on the effectiveness of independent actions 
in the MYCANN Plug-ins area and a possible upper layers internet use 
task force aggregation.

If the Chairs continue to read the Charter the way Leslie told me, 
whatever the Draft will suggest, the world will decide on its own,

I only hope that the potential of independent action is a more 
powerful way to focus the minds of the various actors in this case, 
that is, if it is ill behavior, or help aggregating a new solution.

This will be to the IESG/IAB to decide if this WG does not want or 
does not succeed in convincing the Libre, State, Business independent 
would-be actors (MYCANN Plug-ins designers, developers, 
disseminators) that the IETF is firmly in the lead.

>At 22:50 01/11/2014, Andrew Sullivan wrote:

Nowadays, technical requirements are driven by global communities' 
(plural) economics for the good of humanity.  This is RFC 6852 - 
endorsed/signed by many who are on this list.

Please note that I do not disagree with that respective RFC's 
pragmatism, but I appealed it because of its lack of ultimate 
conflict resolution and accountability mechanism that we are facing 
here. Unfortunately, I did not have the time to complete the appeal 
process and submit it to the RFC 6852's convenor (ISOC) before the 
NTIA started using it and ICANN intelligently used the NTIA's 
political wake up call to put technologies in competition (however, 
in contempt to the internet governance's "governees", igniting a 
technical competition between its own proposition and the Libre and 
national capacities).

Best
jfc