Subject: Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

From: Warren Kumari <[email-masked]>
Date: Sat, 1 Oct 2016 14:25:06 -0400

On Thu, Sep 29, 2016 at 11:04 PM, Paul Wouters <[email-masked]> wrote:
> On Thu, 29 Sep 2016, Warren Kumari wrote:
>
>> On Thursday, September 29, 2016, Ted Lemon <[email-masked]> wrote:
>>
>>       So, if anyone is still wondering why we need a /good/ problem
>> statement, this discussion is why.  You are
>>       both taking past reach other because you are looking at only the
>> part of the problem you care about.
>>
>> ... and why we need a Special Use Names problem statement, and not just a
>> RFC6761 problem statement. This problem is
>> bigger than just 6761...
>
>
> I still do not see that. Without 6761, if anyone wants to ask for a TLD,
> whether to delegate or never delegate, we (IETF) can say: That is
> outside the area of our expertise - you must go to ICANN.
>
> ICANN already has a blacklist of unsafe domains. IETF can advise them
> on that list if needed.

No, no it really doesn't -- it has some list of names, which seem to
have been fairly arbitrarily chosen. This is not a stable, well
published list -- it lurks in the "gTLD Applicant
Guidebook", published in January 2012, in Section 2.2.1.2.1 ("It was
on display at the bottom of a locked filing cabinet stuck in a disused
lavatory with a sign on the door saying beware of the leopard.").
This list at that point was: "AFRINIC IANA-SERVERS NRO ALAC ICANN
RFC-EDITOR APNIC IESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC
CCNSO INVALID SSAC EXAMPLE* IRTF TEST* GAC ISTF TLD GNSO LACNIC WHOIS
GTLD-SERVERS LOCAL WWW IAB LOCALHOST IANA NIC", and "OLYMPIC OLYMPIAD
OLYMPIQUE OLYMPIADE OLYMPISCH OLÍMPICO (and Olympic in various scripts
which my mailer doesn't want to accept)" and "REDCROSS REDCRESCENT
REDCRYSTAL REDLIONANDSUN MAGENDDAVIDADOM REDSTAROFDAVID CROIXROUGE
CROIX-ROUGE CROISSANTROUGE CROISSANT-ROUGE CRISTALROUGE CRISTAL-ROUGE
(and various Red Cross / Red Crecent and scripts which my mailer
shrugged and stared blankly at)".

A number of the first list are from the IANA Special Use Names
registry -- but many of the others are simply ICANN deciding that
their internal groups are special -- for example, GAC, RSSAC, SSAC,
CCNSO, ALAC. And then they decided that IETF, IAB, RFC-EDITOR IRTF
should also be listed. Seriously, this seems like a good, well run
solution?

> I don't think at this point either ICANN or IETF would want to add TLDs
> to the unsafe list. If at this point someone is still squatting domain
> names, they get what they deserve. And all the known security risky
> domains (as a result of decades of use of unqualified domain names)
> are already known at ICANN, and they won't assign these.

Um. No. See .home, .corp and .mail - many would say that these are
known security risky names -- when security issues were raised, these
were not placed on a blacklist -- instead these have been "deferred
indefinitely. ICANN will collaborate with the technical and security
communities to determine the best way to handle these strings in the
long term.". I have not seen this happening. Applicants for these TLDs
recently sent https://www.icann.org/en/system/files/correspondence/home-registry-inc-et-al-to-icann-board-24aug16-en.pdf.
I would encourage all to read this...

> People creating
> new ones are also going against the long standing don't squat advise,
> and need no further protection from their own foot bullets.

Let's pretend that you had a good reason for needing a name reserved -
for example, let's pretend that you are designing some sort of home
networking protocol where you'd like to be able to connect thingies
together and have name / service discovery just work. It's not mDNS /
.local is not appropriate for you. You go through the full IETF
process - you hold a BoF, you form a WG, you hold meetings, you design
a system. Great. You have IETF consensus. Now what?
Currently you / I / the IETF cannot go to ICANN and say "please
reserve us a string" -- there is no "blacklist", there is just some
list in some applicant guidebook. There is no open process at the
moment -- the last round took many many painful years, and there was
no method to "reserve" a name (in fact, this was explicitly
prohibited). The "list" was not created with the consultation of the
community - in fact many names on that list a: didn't know that they
were, and b: didn't want to be. Also, the process is currently closed,
and even if it were open, last time it cost >$185,000 to apply...

You've been to a number of ICANN meetings - do you really trust this
process to provide a good outcome for the technical community?

Sure, many people didn't like the .ONION discussion / outcome -- but
what would your advice have been to the TOR community if we'd already
decided to abdicate our position? "Dear TOR folk. Go talk to ICANN..
Yeah, I know that that won't actually help you; you don't fit in their
model, and the process isn't open now anyway. Guess you shouldn't have
squatted on that name, huh"?

Anyway, this is FAR into the solution space, and I was really hoping
to avoid getting drawn into that..

I know I'm sounding frustrated / grumpy -=- this whole processes /
discussion has been taking up way way too much of our time, hopefully
we can *soon* make a decision, ship a document and then get onto more
*technical* discussions like "Um, which name is the QNAME?!" :-)

>
> So that brings the problem statement to:
>
>         IETF had the power to allocate or ban domain names based on the
>         Special Names RFC-6761. IETF no longer wants that power.

That's not a problem statement. That's a "we found this annoying and
want someone else to do it" -- that may be true, but that's a
/solution/, not a /problem statement/.

W
>
> And the solution for that is a 6761bis document that confirms this.
>
> Paul

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Philip Homburg <[email-masked]>
Date: Sat, 01 Oct 2016 20:48:48 +0200

In your letter dated Sat, 1 Oct 2016 14:25:06 -0400 you wrote:
> Sure, many people didn't like the .ONION discussion / outcome --
> but what would your advice have been to the TOR community if we'd
> already decided to abdicate our position? "Dear TOR folk. Go talk
> to ICANN..  Yeah, I know that that won't actually help you; you
don't fit in their model, and the process isn't open now anyway.
> Guess you shouldn't have squatted on that name, huh"?

It seems to me that the tor community created two problems. And then put a lot of
pressure on the IETF to solve those problems.

The first problem is that .onion names leak into DNS. This is not a problem 
for DNS, you just get a NXDOMAIN. DNS as a whole has no problem with the
resulting load. But it is a problem for the tor project, because for their
project this is a security problem. Somehow, the IETF went along and was
willing to create additional requirements on all parts of DNS to treat
.onion special. 

The second problem was that CAs refused to sign certificates for .onion. Again,
this was not an IETF problem. But somehow the tor project managed to put 
pressure on the IETF to grant them that name. 

I'd say this is a problem.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 1 Oct 2016 15:12:36 -0400 (EDT)

> should also be listed. Seriously, this seems like a good, well run

Those are not the "unsafe" domains. Those are all vanity domains, and
the IETF really does not want to go near those names because it involves
trademarks and the IETF doesn't have the money for lawyers in that
arena.

> I would encourage all to read this...

Right. And these are the only names that have security concerns. And if
IETF, not ICANN, decides that .mail is a 6761 domain or a 6761bis
domain, then whoever wants to run .mail will be able to sue the IETF
instead of ICANN. Which is why ICANN should maintain the list, for
better or worse. Which is why I came to my one line statement saying
IETF does not want to have this power to decide this.

> a system. Great. You have IETF consensus. Now what?

This is assuming there is a 6761 or 6761bis procedure. What I am saying
is that the above described scenario is _not_ something the IETF wants
to be part of. The IETF should say "use a domain you own". Your protocol
for your new homenet could use smartypants.kumari.net. And it could be
either delegated by you or you will never delegate if that's required
for your protocol. If the name is too long, the market can come up with
a url/domain shortening service.

> list in some applicant guidebook.

Well, "currently" there is disagreement about if the IETF can reserve
a string, due to the existence of 6761, the claim that this path has
been frozen, and the claim that it cannot be frozen until it is formally
closed with a new rfc document. My proposed one liner would permanently
close this.

> There is no open process at the

I don't see how this relates to the discussion. I think the goals are that
the IETF should not get involved in Naming Schemes and Trademark Wars.
Because we don't have the budget for it. That's why ICANN was created.

> process to provide a good outcome for the technical community?

I think it is adequate and the best IETF can do based on its monetary
resources.

I do not think the IETF should create "Special Names" that conflict
with the naming process which has been delegated to ICANN.

Yes, there is a change ICANN decides to delegate names that the IETF
believes endangers the security and stability of the DNS, such as the
.mail domain. But if we create a process within the IETF that hard-fails
those domains out of the hands of ICANN, it just means those lawsuits
will come to the IETF. And the IETF didn't get 1500 * $185k to defend
itself.

> squatted on that name, huh"?

The IETF giving them .onion in itself has been a very risky decision. It
was based on no Big Corporation having an interest in the string. With
.gnu people did not feel as sure about that. I think that's part of the
reason .gnu was not also going to make it like .onion. These decisions
are quicksand.

> to avoid getting drawn into that..

Well, that is because we don't agree about the problem whatsoever. I
think the only problem we have now with naming is that the IETF has
some form of control over names via 6761, and leaves us vulnerable to
lawsuits and therefor I want the IETF to lose that power. That's
completely unrelated to the entities that are lined up for asking the
IETF for a decision on a Special Name.

> *technical* discussions like "Um, which name is the QNAME?!" :-)

I have been shouted to sit down when I brought up this is taking too
much time out of dnsop, so believe me I know how you feel :)

> /solution/, not a /problem statement/.

So change the second sentence to "This is a dangerous liability for the
IETF".

Paul

---

From: Warren Kumari <[email-masked]>
Date: Sat, 1 Oct 2016 20:13:05 -0400

On Sat, Oct 1, 2016 at 3:12 PM, Paul Wouters <[email-masked]> wrote:
>> recently sent
>> https://www.icann.org/en/system/files/correspondence/home-registry-inc-et-al-to-icann-board-24aug16-en.pdf.

Yup. Hopefully a decision on what to do is made, and made soon -- this
whole process has been painful for / harmful to the working group.
It is largely a political morass, and people are becoming
(understandably!) frustrated, worn out, apathetic, polarized or
entrenched (choose 5!)

W

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 1 Oct 2016 20:45:46 -0400

Warren, and all,

We’re working on a response. This past week had some distractions.

Look for an update in the next couple of days.

Suzanne & Tim

> On Oct 1, 2016, at 8:13 PM, Warren Kumari <[email-masked]> wrote:
> 
> 
> \

---

From: hellekin <[email-masked]>
Date: Sun, 2 Oct 2016 09:37:12 +0000

On 10/01/2016 07:12 PM, Paul Wouters wrote:
>
> the IETF doesn't have the money for lawyers in that arena.
>
> [snip]
> 
> [snip]

Thank you for verbalizing that.  Had it been done earlier, I'd have
joined a commercial letter of interest of the GNU corporation who sells
snowboards to the RFC as an appendix, in order to make a precedent that
a technical document can be vested or vetoed by private interests based
on legal risk and self-censorship.

Given the recurrence on this list of the term "squatting" to refer to
real use of a non-ICANN-sanctioned TLDs, and the assumption that people
should be aware of IETF and ICANN processes and avoid using such names
in the first place, that transpired in many negative comments of P2P
Names, why not consider that corporations, being 'people', fall into the
same bag as ourselves, and should be aware that there have been such a
process going on for 3 years already, and they didn't claim anything
about thoses requested TLDs, which shows *no prior interest* in doing
so.  I wonder what kind of court would accept a post-delegation lawsuit
in these conditions.

Nevertheless, I take note that finally, someone put that on the table
clearly and honestly.

I'd like to finish on the note that nothing in RFC 6761 *tells* ICANN to
reserve a name.  Instead it reaffirms that

   The IETF has responsibility for specifying
   how the DNS protocol works, and ICANN is responsible for allocating
   the names made possible by that DNS protocol.

In RFC 2606, IANA considerations say:

   IANA has agreed to the four top level domain name reservations
   specified in this document and will reserve them for the uses
   indicated.

So, even if the IETF reserves a name, it is more like a suggestion for
ICANN to ponder.  Maybe this should be clearly stated within the problem
statement and following materials to avoid IETF self-censorship to avoid
a legal threat.  As a person, I'm not too keen on the idea that someone
could sue something just because they can.  That's a very late-20th
century U.S.American notion that is not particularly welcome in the rest
of the world, and secret corporate courts suing government or other
institutions in the name of 'free trade' sound like neo-colonialism.  So
for good measure, *at least* one step to solve 'the problem' would be to
make it clear that the legal responsibility goes to the big guy in the
room, in our case, as for precedents in relevant RFCs, IANA.  If this
legal risk argument is the main show-stopper, I suggest it's vaporscare
and *not technical*.

## Reminder

The introduction of RFC 6761 gives its scope:

   However, "Reserved Top Level DNS Names" [RFC2606] does
   not state whether implementations are expected to treat such names
   differently, and if so, in what way.

   This document specifies under what circumstances special treatment is
   appropriate, and in what ways.

Regards,

==
hk

---

From: Paul Wouters <[email-masked]>
Date: Sun, 2 Oct 2016 14:38:28 -0400

> On Oct 2, 2016, at 05:37, hellekin <[email-masked]> wrote:
> 
> snowboards to the RFC as an appendix,

I don't think hat would have made people less nervous about it.

> in order to make a precedent that

That hardly matters when serious money gets involved.

> real use of a non-ICANN-sanctioned TLDs,

TLD's are in DNS name space, so squatting is a perfectly fine term. The term "non-ICANN-sanctioned TLDs" is clearly misleading.

>  I wonder what kind of court would accept a post-delegation lawsuit
> in these conditions.

The process of having a lawsuit be thrown out itself can be very prohibitively expensive.

>     If this
> and *not technical*

I disagree it is a vaporscare. Having been involved in a name dispute where I had pgp signed proof and still did not end up with the name, I can tell you it is all about the money you can spend on lawyers.

I do agree it is not technical. In fact, that's large been my point all along. The only technical part of this whole discussion are names that would pose a risk to the stability and security of the DNS. And I think those all have been dealt with already (and new ones are self-inflicted foot bullets we don't need to prevent)

Paul

---

From: "John Levine" <[email-masked]>
Date: 4 Oct 2016 03:13:54 -0000

>I'd say this is a problem.

With the vast amount of money and effort spent on Internet Governance
you wouldn't expect to find a governance vacuum, but whaddaya know,
that's what we have.

The CAs are asking if they should sign .onion and presumably other
oddball names that come along, and want an authority they can point to
for the answer.  ICANN (or perhaps some people within ICANN) are
asking whether they should delegate .corp, .home, and .mail and
presumably other toxic waste names, and want an authority they can
point to for the answer.  The P2P crowd would like to carve out some
names to run their resolution scheme in parallel with the DNS, and it
appears they'd also like an authority they can point at.

I suppose it's flattering that everyone is looking at us, but as we are
seeing, just because a vacuum sucks (by definition, after all) does not
necessarily mean we are qualified to fill it.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Mon, 3 Oct 2016 21:19:15 -1000

Hi,

On October 3, 2016 at 5:14:24 PM, John Levine ([email-masked]) wrote:
ICANN (or perhaps some people within ICANN) are 
asking whether they should delegate .corp, .home, and .mail and 
presumably other toxic waste names, and want an authority they can 
point to for the answer. 

Just a clarification:
As far as I know, neither ICANN (the organization) nor anyone within ICANN (the organization) is asking whether they should delegate such names. Forward motion of those names is currently "indefinitely deferred" pending _somebody_ (not ICANN staff) figuring out what to do with them. I believe the hope had been that the IETF might provide some technical guidance, but that didn't work. Now, some members of the ICANN community are asking the board that those names be delegated and that results in (re)opening the question of what to do with "indefinitely deferred" strings.

The P2P crowd would like to carve out some 
names to run their resolution scheme in parallel with the DNS, and it 
appears they'd also like an authority they can point at. 
Well, some do. To be honest, it feels to me that some appear to want to say "we don't like ICANN" or, more generally, "Screw you, Establishment!" 

Not everyone. I (and I think Paul W) have been suggesting that the IETF is not really the best place to deal with the implications of trying to fill that vacuum -- too many lawyers smelling blood in the water. The new gTLD Applicant's Guide Book was 300+ pages for a reason and it wasn't, as some have (loudly) suggested, because ICANN (the organization) is evil or greedy or incompetent, rather the issues involved in dealing with a resource that can only be allocated to one entity when multiple entities might have an arguably valid claim to the resource, get complicated quite quickly and when money is involved (which names seem to attract), lawyers follow and it gets ugly fast. 

There be serious non-technical dragons here. I don't speak for ICANN, but I suspect ICANN (the organization) would love to have a list to point at that says "can't delegate these because the IETF say so -- talk to them about why" just as ICANN points to ISO-3166/MA when someone comes and demands their 2-letter made up string should represent their "country." This may not be career enhancing, but speaking as an IETF participant (which I assume we all are), it isn't clear to me this would be prudent if we want the IETF (or rather, it's legal parent(s)) to be a viable entity in the long run. Particularly if the "why" turns out to be the winner of a beauty contest decided by the IESG as 6761 current suggests.

Regards,
-drc
(ICANN CTO, but speaking only for myself)

---

From: Jeremy Rand <[email-masked]>
Date: Tue, 4 Oct 2016 16:59:20 +0000

> Well, some do. To be honest, it feels to me that some appear to want to say "we don't like ICANN" or, more generally, "Screw you, Establishment!" 

Hope I'm not stepping on any toes by joining this discussion, but I'd be
surprised if those sentiments were coming from any Namecoin people.  The
Namecoin developers are well aware that Namecoin makes different
tradeoffs from DNS, and that there are plenty of ways that Namecoin is
inferior to DNS as managed by ICANN.  We're actively attempting to
minimize those deficiencies within our design constraints, but some of
the issues are open research problems that may or may not have a
solution.  As such, I hear Namecoin people criticize Namecoin's
technology far more often than I hear them criticize ICANN.

We're trying to build something cool, not tear down ICANN.

(Maybe you were talking about some other P2P naming project, in which
case I apologize for entering this conversation.)

Cheers,
-Jeremy Rand
(Namecoin developer)

---

From: avri doria <[email-masked]>
Date: Thu, 6 Oct 2016 11:22:23 +0200

On 04-Oct-16 09:19, David Conrad wrote:
> As far as I know, neither ICANN (the organization) nor anyone within
> ICANN (the organization) is asking whether they should delegate such
> names. Forward motion of those names is currently "indefinitely
> deferred" pending _somebody_ (not ICANN staff) figuring out what to do
> with them. I believe the hope had been that the IETF might provide
> some technical guidance, but that didn't work. Now, some members of
> the ICANN community are asking the board that those names be delegated
> and that results in (re)opening the question of what to do with
> "indefinitely deferred" strings.

Actually I thought they were asking that work that had been promised on
further researching the problem and mitigation techniques be done as
opposed to just prohibiting things because the first thoughts turned out
to be inadequate.

As for the so-called toxic waste names (i really find that terminology
problematic) someone needs to find a solution otherwise the possibility
of adding more and more names to the so called waste pile of usurped
names over time becomes an increasing possibility.  If someone can just
start using a name and thus make it too hard to delegate we have a much
bigger problem.

avri

avri

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

---

From: hellekin <[email-masked]>
Date: Thu, 6 Oct 2016 09:48:35 +0000

On 10/06/2016 09:22 AM, avri doria wrote:
> problematic)

I agree it's a problem to use that kind of vocabulary to convey a
technical context.

> the so called waste pile of usurped names
>

Therefore this is also a problem to call names-used-in-the-wild
"usurped" or "squatted", because it says that there's a central body
that assigns names, and it defines who can use them, with the
exclusivity of any other approach.  I know this idea may sound funny to
a lot of people given the missions of IANA and ICANN, and the existence
of trademarks and so-called 'intellectual property', but to me, having
an authority over who can use what names *in general*--as opposed to
particular, specific cases (e.g., trademarks)--is akin to the Novlang
Committee.

Names in the DNS are sanctioned by IANA/ICANN, and those names are
'legitimate' in the context of Internet names.  That doesn't mean at all
that names not sanctioned by ICANN are illegitimate, or that names
covered by trademarks are more 'legitimate' than 'unprotected' names.
This is all a matter of transactions and legal-firepower.  But from
there to legitimate this transactional-belligerent perspective over any
other (historical, cultural, incidental, ontogenetic, etc.) seems to me
problematic and abusive.

==
hk

---

From: George Michaelson <[email-masked]>
Date: Fri, 7 Oct 2016 08:20:50 +1000

If you can come up with an efficient, "fair" and trusted process for a
unitary name space on domain principles (domains of scope. trees.)
that doesn't confront collisions over desires for labels at arbitrary
points in the tree, and of essential 'centrality' in decision making
logic over things especially the apex of the tree, computer science
would like to know.

Meantime, we have this tree, and we have a lot of documentation around
this tree, and we have a current bilateral view between two agencies
on this tree, and we're discussing this tree, in the context of one of
those agencies: we're using IETF infrastructure, IETF processes, IETF
methodologies, to discuss that tree.

I agree pejorative language doesn't help, and I share responsibility
for its over-use. I apologize for intemperate use of language.

Peer to peer, hash based, location-id separator, <other unknown> all
discuss concepts which collide in this model.

It might surprise you to know, that outside of this conversation I
hold different views about social equity, and who should or should not
be vested with authority in names. I try to draw distinctions between
what I think as a consumer, and a user, and what I observe from my
training and praxis.

I hold a unitary name space as a public good in very high regard. I
think p2p models, and models of probabalistic or hash naming are
interesting, but they wind up needing to map coherently to DNS names.
What I depart from, in the conversation, is how high in the DNS tree
that coherence has to vest.

A lot of your commentary goes to procedural fairness. I won't pretend
we don't have a problem there. I think you, and others in development
of novel systems have a right to feel severely disadvantaged by
process as it stands.

-G

On Thu, Oct 6, 2016 at 7:48 PM, hellekin <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "John Levine" <[email-masked]>
Date: 7 Oct 2016 01:20:33 -0000

> If someone can just start using a name and thus make it too hard
> to delegate we have a much a bigger problem.

That's been true approximately forever, viz. .onion, .belkin, .corp,
.local, .mail, and probably still .uucp that are too poisoned to allow
reliable delegation and new use.  That's why we're here.

The fundamental and I hope obvious problem, is that the IETF and ICANN
have no control over software that people write and the hardware they
embed it in.  If someone creates popular software leaking requests for
.PICKLE, we can grouse all we want but since we're not the Network
Police, there's not much we can do about it.

R's,
John

---

From: Alain Durand <[email-masked]>
Date: Fri, 7 Oct 2016 18:36:14 +0000

> On Oct 7, 2016, at 6:51 AM, John Levine <[email-masked]> wrote:
> 
> f someone creates popular software leaking requests for

There is not much that can be done after the fact, I agree. However, there is something that can be done before: provide a safe place in the DNS tree where people can exist without colliding with the rest of the tree. We can't prevent people from ignoring it and keep using whatever name they want, but at least we would have provided a way to play nice. In that spirit, efforts like .alt and friends are a step in the right direction.

Alain

---

From: hellekin <[email-masked]>
Date: Fri, 7 Oct 2016 20:31:37 +0000

On 10/07/2016 06:36 PM, Alain Durand wrote:
> 
> However, there is something that can be done before: provide a safe place
> in the DNS tree where people can exist without colliding with the rest of
> the tree. We can't prevent people from ignoring it and keep using whatever
> name they want, but at least we would have provided a way to play nice. In
> that spirit, efforts like .alt and friends are a step in the right direction.
> 

We have .example and example.* for documentation, yet the XMPP
documentation uses shakespeare.lit (I don't think .lit matches any SUN
or any entry in any DNS-related RFC.) FWIW, wikipedia sends .lit to some
Microsoft file extension.  One cannot say that Peter St Andre is
ignorant of IETF processes.  Use of *example* in documentation and
.invalid in free software is a good sign that developers are ready to
follow suit and respect the norms.

==
hk