Subject: Re: [DNSOP] Fwd: Re: [[email-masked]: I-D Action: draft-grothoff-iesg-special-use-p2p-names-00.txt]

From: Christian Grothoff <[email-masked]>
Date: Sun, 01 Dec 2013 19:22:02 +0100

On 12/01/2013 06:45 PM, Jacob Appelbaum wrote:
> FYI - if you can reply, it would be helpful, I am about to fly to Europe.

I'll try.

> -------- Original Message --------
> Subject: Re: [DNSOP] [[email-masked]: I-D Action:
> draft-grothoff-iesg-special-use-p2p-names-00.txt]
> Date: Sun, 1 Dec 2013 12:35:44 -0500 (EST)
> From: Paul Wouters <[email-masked]>
> To: Ted Lemon <[email-masked]>, Jake Appelbaum <[email-masked]>
> CC: Stephane Bortzmeyer <[email-masked]>, dnsop WG <[email-masked]>
> 
> On Sun, 1 Dec 2013, Ted Lemon wrote:
> 
>> On Dec 1, 2013, at 11:48 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>>> For the record, I've reviewed
>>> draft-grothoff-iesg-special-use-p2p-names-00, I find it well-written
>>> and clear and I fully support it. Registering these names would be a
>>> very good idea.
>>
>> Why do you support it?   Why is registering these names a good idea?
> 
> I'm curious too. I'd rather see a generic method instead of an
> (incomplete?) list of domain names to reserve. Why wasn't .bofh on
> that list? 

Because I'm not aware of a P2P system implementing ".bofh", and if there
is one,
they don't seem to be interested in documenting this or working with us.
 Some
other developers did see our draft and reached out to us to be included, and
the list will thus be expanded by one more system for -1.  Aside from that,
if there are unrelated systems, they should probably write their own RFC, as
their requirements may differ.  Finally, there isn't a "generic" method, as
different pTLDs have different requirements.  ".local", ".test", ".arpa" and
".onion" don't all fit under one umbrella.  Also, I believe any attempt to
document "everything" that happens on the Internet is doomed to failure,
so the
best we can hope for is an "incomplete", but coherent set of documents that
document everything that may be important for users and operators.

> Why was .gnu on that list? What if GNU or someone else
> wishes to register .gnu as a new gTLD based on a trademark? Who
> are we to disallow that?

This was explicitly approved by GNU.  You're welcome to ask Richard
Stallman himself.  Dozens of other GNU maintainers and packages are
also involved to some degree.  So unless you're suggesting that the
GNU project should allow someone ELSE to have a trademark on "GNU",
I think this is not about you disallowing something, but you preventing
the GNU project from using ".gnu".

> This also seems similar to the USENET problem, where John Gilmore
> proposed/created the alt.* hierarchy.
>
> It would make more sense to me to reserve something like .alt where
> people can plugin onion.alt, gnu.alt, etc, and are guaranteed that
> the .alt domain will never actually be delegated by the root. That
> means new players who want some peer to peer, no DNS dependancy don't
> have to come back here to reserve _their_ names later on.

And who'll manage ".alt"?  Now we'll need another process for managing
assignment within ".alt", break compatibility for millions of users with
hundreds of thousands of domains and for what exactly?  I could equally
suggest that ICANN should just be given ".icann", and so it becomes
"www.google.com.icann".  After all, who put them in charge?

> And once you go that way, one can wonder why not use the already
> existing .local for that? Perhaps avoid talking to different protocol
> software is a good enough reason not to re-use .local.

There are plenty of reasons not to use ".local", starting with that the
names in our draft are non-local, or that the deployed software and
existing users don't use ".local".  Again, this is NOT a standardization
process, this is an _informational_ draft/RFC that documents what is
happening.  We'll continue to use ".onion", ".i2p", and ".gnu".  Users
do not need someone's blessing to do so, but from a technical point of
view it makes a lot of sense to document these pTLDs and give guidance
to operators. That's what we're trying to do with the RFC, we're not
really asking for "permission".

> But can an RFC even do anything here?  Whether you agree with ICANN
> procedures for new gTLDs or not, if I write some software that becomes
> popular using a .paul pseudo domain, when does it become valid for me
> to request it under RFC 6761?

I'd say yes, if you can justify that information about ".paul" is relavant
to the community.

> What precedent would tor/gnu/zkey/etc set?
> Does IETF even have any say in such matters? Isn't this up to IANA or
> ICANN? What about trademarks? What about lawsuits by Gnu Inc or Onion
> Corp who want their gTLD?

First of all, who'd they sue?  Tor users?  Tor developers?  IETF for
publishing an RFC?  I don't think there'd be ground for suing any of
those parties in this case.  However, more importantly, I think you're
not clear on trademark law.  Trademarks are awarded for a particular
domain and scope AND have to be consistently enforced.  So
unless you know of a global actor in the domain of networking that has
a trademark on GNU that would be recognized by courts and would immediately
sue about ".gnu" (leaving the question who they'd sue to begin with,
the GNU project? That'd be interesting), there's no case to begin with.
So please point me to your .onion inc or .i2p inc before making up some
straw man argument.

> Other questions I would have is why aren't these people using a
> different class from IN? They can have a class of TOR or ONION or GNU?

We considered this, but sadly there's no way to make that work with legacy
software.  I've not found any application that uses DNS today that'd
allow users to switch the class (does your browser or e-mail client allow
this?).  Please let us know how you propose to enable an alternative
name system that uses a different class to be integrated with the code
that is out there, I'm quite interested as I couldn't find a way to
make it work (and usable --- LD_PRELOAD to replace gethostbyname of libc
isn't quite a sane answer in my book).

> The traditional reasons for not using any non-IN class is that a lot
> of software would not work well with that, but in these cases, the
> consumers aren't actually interested in real DNS anyway, and using
> a URI that indicates a different class should not be too hard to plug
> into existing browsers? A specific tor:// URI plugin would make
> more sense to me that sticking with http://sdggjaksgdkgda.onion
> construct, especially as at least with tor right now, you are stuck
> with the SOCKS API anyway. If tor would be truly transparent and map
> to a real ip address handled at the kernel/socket level, then it would
> make even more sense to map tor://sdggjaksgdkgda.onion onto a new DNS
> class like: sdggjaksgdkgda.onion. IN ONION 1.2.3.4 (or perhaps even a
> non-A/AAAA identifier, like a straight public key if that's what the
> new socket family would take)

You're mistaken in that Tor is not _only_ used by browsers -- and
started of as a pure proxy without _any_ modifications to browsers.
The case is even stronger for GNS, where DNS queries can even be
intercepted at the network layer by a dedicated DNS2GNS gateway.

> So I think this draft has a lot of issues, technically and legally.

I'm not a lawyer, but I'm pretty sure your legal opinion is incorrect,
possibly because it is based on partial knowledge of the facts.

As for the technical side, I also don't quite buy your arguments, as
they excessively conflict with usability and seem to be purely based
on the idea that this would set a precedent that would then allow
anyone to "just" write a big system (Tor, GNUnet and I2P are all
projects with about 300,000 LOC) and an RFC and we'd end up with
ten billion special-use reserved pTLDs.   I find that's unlikely to
happen, but even if it did, great, I'd call that progress.

Happy hacking!

Christian

---

From: David Conrad <[email-masked]>
Date: Fri, 6 Dec 2013 12:50:50 -0800

Christian,

On Dec 1, 2013, at 10:22 AM, Christian Grothoff <[email-masked]> wrote:
> Aside from that,
> their requirements may differ.

Personally, I'd prefer each requester of a top-level pseudo-domain (to use the term from RFC 6761) submit their own draft. A possible implication of bundling is that the applications are sufficiently similar that they could fall under a single top-level pseudo-domain.

>  Finally, there isn't a "generic" method, as
> ".onion" don't all fit under one umbrella.  

Just to be clear: .ARPA is not a pseudo-domain.

> And who'll manage ".alt"?  

Why does it matter? Does it even need management? The issue here is that without the reservation of the top-level name, there is a chance that it will be delegated via ICANN's new gTLD process.  Since the names in question (.onion, .gnu, etc) aren't DNS names, the applications that will be making use of these names will presumably have their own (software-based) mechanisms to do whatever management they'll need. Are you assuming that the allocation of these top-level pseudo-domains is somehow going to prevent others from using those names as they see fit?

> I could equally

See RFC 2860.

> Again, this is NOT a standardization
> happening.  

It's a little more complicated than that. The use of the mechanisms in RFC 6761 explicitly preempt strings from use in the DNS. By my reading of the existing MoUs between the IETF and ICANN, ICANN, as the IANA functions operator, must abide by that preemption or risk termination of the MoU.  

> We'll continue to use ".onion", ".i2p", and ".gnu".  Users

Understood. However, if the names aren't reserved, I suspect there is an increased likelihood that the names will be acquired under the ICANN new gTLD program at some point. 

> So please point me to your .onion inc

http://www.onion.com

> or .i2p inc

http://impossible2possible.com/home

> before making up some straw man argument.

According to USPTO, there are 470 records that result from a search of the string "onion", 4 for "i2p", and 35 for "gnu", the latter including a clothing manufacturer whose trademark is the bare word "gnu". I am not a lawyer or even that well versed in ICANN's trademark clearinghouse, but I suspect it would be a mistake to blithely dismiss this particular issue.

> intercepted at the network layer by a dedicated DNS2GNS gateway.

Sorry, I'm confused. The point of the RFC 6761 reservation scheme is that the names are _NOT_ intended for use in DNS resolution. What do you mean by "DNS queries can be intercepted at the network layer"?

> ten billion special-use reserved pTLDs.  

Part of my concern is that RFC 6761 provides insufficient (IMHO) constraint on its use.  It doesn't have any requirements for system size, lines of code, number of users, etc. It leaves the decision up to a subjective evaluation on the part of IESG (unless it is a standards action).  

> I find that's unlikely to happen, but even if it did, great, I'd call that progress.

An interesting view of progress.

Regards,
-drc

---

From: Christian Grothoff <[email-masked]>
Date: Fri, 06 Dec 2013 22:43:08 +0100

> Why does it matter? Does it even need management? The issue here is that without the reservation of the top-level name, there is a chance that it will be delegated via ICANN's new gTLD process.  Si…
I meant 'management' in the sense of assigning names under .alt to
groups/organizations/software.  We'd effectively need another process to
decide who gets to implement a mechanism for ".com.alt".  Besides, as
was already pointed out, RFC 6761 rejected the idea of ".alt", and I
agree with Stephane that, as RFC 6761 has consensus, we should not
reopen that discussion just because we're trying to use it for the first
time.

> It's a little more complicated than that. The use of the mechanisms in RFC 6761 explicitly preempt strings from use in the DNS. By my reading of the existing MoUs between the IETF and ICANN, ICANN,…
Sure, but of course the point of having a mechanism in place is that it
should be used.  If you don't use it, even termination won't matter. 
Now, I'm hoping that this discussion will eventually turn away from the
"we shouldn't use that mechanism at all" to specific discussions about
the text of the draft.
> Understood. However, if the names aren't reserved, I suspect there is an increased likelihood that the names will be acquired under the ICANN new gTLD program at some point. 
Sure, and that's of course one reason why we're trying to do this.
>> So please point me to your .onion inc

Actually, they are already proposing to use ".com2" and a few others
(which I wholeheartedly support), so I suspect ".onion" would be clearly
too boring for them:
http://www.theonion.com/articles/new-internet-destinations-created,28607/

> According to USPTO, there are 470 records that result from a search of
> the string "onion", 4 for "i2p", and 35 for "gnu", the latter
> including a clothing manufacturer whose trademark is the bare word
> "gnu". I am not a lawyer or even that well versed in ICANN's trademark
> clearinghouse, but I suspect it would be a mistake to blithely dismiss
> this particular issue. 
I guess we can agree that we're both not trademark lawyers; regardless,
I suspect that IAB/IESG is going to check with ICANN lawyers on this in
due time, so maybe us engineers should focus on the engineering discussion?

> Sorry, I'm confused. The point of the RFC 6761 reservation scheme is that the names are _NOT_ intended for use in DNS resolution. What do you mean by "DNS queries can be intercepted at the network…
The GNS queries won't go to the DNS resolver hierarchy; however,
applications may use the DNS protocol initially (for legacy reasons),
and then at a 'personal' DNS resolver might decide to forward ".gnu" to
GNS and other queries to DNS.  So the question is what you consider "DNS
resolution" -- GNS resolution does not involve the DNS root zone, but
applications may talk to a GNS resolver using the DNS protocol (we have
a proxy that supports DNS-UDP with the standard query, response and
record formats).  I do not consider this using "DNS resolution", as the
distributed database that is DNS is not involved and anyone familiar
with DNS resolution would not say that the process is the same -- except
for the first UDP packet and (the format of the) final response that the
application generates/receives.

> Part of my concern is that RFC 6761 provides insufficient (IMHO) constraint on its use.  It doesn't have any requirements for system size, lines of code, number of users, etc. It leaves the decisio…
Well, setting such constraints in an absolute fashion is hardly useful
anyway, I'm not sure a debate on metrics for this would be fruitful.  In
the end, yes, somebody will have to make a call on this, unless of
course nobody even is willing to say "yes" or "no" anymore (or even
hum...).  For now, we'll continue to try to integrate constructive
feedback into the draft.
> An interesting view of progress.
Well, some people think ICANN selling thousands of gTLDs is progress;
I'm personally more interested in new technical developments.  But
business people are certainly free to disagree ;-).

Happy hacking!

Christian

---

From: David Conrad <[email-masked]>
Date: Fri, 6 Dec 2013 15:02:48 -0800

Christian,

On Dec 6, 2013, at 1:43 PM, Christian Grothoff <[email-masked]> wrote:
> decide who gets to implement a mechanism for ".com.alt".  

The RFC 6761 registry (http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.txt) would not designate who gets to implement a mechanism for .onion/.gnu/.i2p, it would merely state those strings are reserved so that they aren't allocated as DNS top-level domains and provide a reference to the (first) specification that reserved the name. I see no difference between the suffix being "." and ".alt" in the context of management. Indeed, the registry already lists non-TLD strings.

> Besides, as
> was already pointed out, RFC 6761 rejected the idea of ".alt",

RFC 6761 says nothing regarding ".alt".  To be clear, the idea is to provide a namespace alternative to the root that reduces the risk of name collisions for applications that do not make use of the DNS (the choice of ".alt" is mostly arbitrary -- it could be pretty much anything).  As I've asked before, beyond aesthetics, what arguments are there against ".alt"?

> and I

By this logic, we should have stuck with RFC 2065 for DNSSEC. It is not unusual for RFCs to not survive their first interaction with the real world.

> GNS and other queries to DNS.

To be sure I understand: you're saying that if I take my favorite unmodified browser on my favorite unmodified operating system and point it at (say) gcc.gnu, a DNS query sent out by my machine to my local resolver using the standard DNS protocol would be received on UDP (or TCP?) port 53 by the special GNS resolver which would notice the trailing string ".gnu" and do something special with it, throwing everything else to the regular DNS resolution process?

Thanks,
-drc

---

From: Christian Grothoff <[email-masked]>
Date: Sat, 07 Dec 2013 00:34:27 +0100

> The RFC 6761 registry (http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.txt) would not designate who gets to implement a mechanism for .onion/.gnu/.i2p, it would me…

My point is that many issues some people were raising here would still
not be solved by .alt, such as trademark issues.

> RFC 6761 says nothing regarding ".alt".  To be clear, the idea is to provide a namespace alternative to the root that reduces the risk of name collisions for applications that do not make use of th…

Beyond aesthetics, what arguments are there again against appending
".icann" to reference the
ICANN-managed root zone? Aesthetics is important, as any Apple fan will
tell you (hence .local,
and not local.apple.com, I'm sure).

> By this logic, we should have stuck with RFC 2065 for DNSSEC. It is not unusual for RFCs to not survive their first interaction with the real world.

Well, naturally nothing is final. But I'm not volunteering to revise RFC
6761 ;-).

> To be sure I understand: you're saying that if I take my favorite unmodified browser on my favorite unmodified operating system and point it at (say) gcc.gnu, a DNS query sent out by my machine to…

Well, "unmodified operating system" might be a bit restrictive, as you
may at least have to configure
your resolver IP (i.e. in /etc/resolv.conf) to point to something that
you don't usually get via DHCP
from your traditional ISP.  But that's nitpicking about the definition
of 'unmodified' OS.  Other
than that, yes, that's pretty much how gnunet-dns2gns works (it also
does something special for '.zkey').
This is one of the main reasons why the notion of using a different
class for GNS is rather silly.

Note that there are _other_ ways to access GNS, but this is likely to be
a popular method until
DNS is completely replaced ;-).

Happy hacking

Christian

---

From: David Conrad <[email-masked]>
Date: Sun, 8 Dec 2013 20:19:46 -0500

Christian,

On Dec 6, 2013, at 3:34 PM, Christian Grothoff <[email-masked]> wrote:
> My point is that many issues some people were raising here would still not be solved by .alt, such as trademark issues.

I actually think it would (since the use of <trademark>.alt would not need to be exclusive as .<trademark> in the DNS must be), but since as you say neither of us are trademark lawyers, let's leave that argument to others. 

> ".icann" to reference the ICANN-managed root zone?

We can't even get new RR types deployed on the Internet (e.g., see type 99) and you're suggesting we try to change pretty much every existing domain name on the planet? 

Technically, however, in accordance with RFC 2860, ICANN manages the root zone on behalf of the IETF. If the IETF were to decide that ICANN must append ".icann" to every existing TLD, I suppose ICANN would have to do that or risk a cancellation of the IETF MoU. I'll let you make the argument that the current DNS hierarchy needs to be renamed to the IETF :).

Do you have any statistics on how many deployments of GNS there are?

> Aesthetics is important, as any Apple fan will tell you (hence .local, and not local.apple.com, I'm sure).

I would assume Apple chose ".local" for Rendezvous/Bonjour for functional reasons, e.g., because the resources addressable via mdns were, you know, local to the LAN and it would make sense even to Pointy Haired Bosses to reference local resources as "printer.local". If it were for aesthetic purposes, they'd probably have chosen ".apple" or maybe ".mac". I'm not sure I see how this functional argument would apply to ".gnu"/".zkey".  I could, however, see a functional argument for ".p2p". 

> yes, that's pretty much how gnunet-dns2gns works (it also does something special for '.zkey').

Thanks for the explanation.

> class for GNS is rather silly.

It would mean revising the stub resolver on each client system that is using GNS, which would be necessary in environments without the "gnunet-dns2gns" proxy, right?

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 9 Dec 2013 04:21:43 +0100

> It would mean revising the stub resolver on each client system that is using GNS, which would be necessary in environments without the "gnunet-dns2gns" proxy, right?

Yes, see my earlier post on how this is implemented.

   Patrik

---

From: Christian Grothoff <[email-masked]>
Date: Mon, 09 Dec 2013 02:57:18 +0100

On 12/09/2013 02:19 AM, David Conrad wrote:
>> Beyond aesthetics, what arguments are there again against
>> appending ".icann" to reference the ICANN-managed root zone?
> 
> We can't even get new RR types deployed on the Internet (e.g., see
> type 99) and you're suggesting we try to change pretty much every
> existing domain name on the planet?

Not seriously ;-).  In fact, I think that the idea that changing domain
names that are in use is silly to begin with.  After all, it wasn't me
who suggested to change ".onion" to ".onion.alt" or ".onion.p2p". :-)

> Do you have any statistics on how many deployments of GNS there are?

Given that the code is very new, there'd have to be very few.  There are
certainly way more .i2p, .onion or .bit out there (the Namecoin
community talks about hundreds of thousands, I have not seen stats for
the others anytime recently).  Now, you're never going to really get
statistics for ".gnu" as the system doesn't allow anyone to enumerate
the zones (or records) that exist by design.

>> Aesthetics is important, as any Apple fan will tell you (hence
>> .local, and not local.apple.com, I'm sure).
> 
> I would assume Apple chose ".local" for Rendezvous/Bonjour for
> functional reasons, e.g., because the resources addressable via mdns
> were, you know, local to the LAN and it would make sense even to
> Pointy Haired Bosses to reference local resources as "printer.local".
> If it were for aesthetic purposes, they'd probably have chosen
> ".apple" or maybe ".mac". I'm not sure I see how this functional
> argument would apply to ".gnu"/".zkey".  I could, however, see a
> functional argument for ".p2p".

.zkey is functional in that in LABEL.zkey, the LABEL is the zone's
(public) key.  .gnu is functional in that GNU gives _you_ the freedom to
(0) use for any purpose, (1) change it so that it does as you wish, (2)
redistribute the information to others, and (3) allows others to make
modifications to their copies.  So if you're familiar with GNU (if not,
please read http://www.gnu.org/philosophy/free-sw.html), you'll find
that ".gnu" is highly descriptive from a functional perspective.  That
it internally uses a P2P system is a technical artifact, which in fact
hardly matters to the users (ditto for .onion, and .bit, btw. -- there
have in fact been people arguing with me if one should consider
Tor/Namecoin P2P systems to begin with).  I believe all of the proposed
pTLDs were picked to be descriptive from the _user's_ perspective.

>>> To be sure I understand: you're saying that if I take my favorite
>>> unmodified browser on my favorite unmodified operating system and
>>> point it at (say) gcc.gnu, a DNS query sent out by my machine to
>>> my local resolver using the standard DNS protocol would be
>>> received on UDP (or TCP?) port 53 by the special GNS resolver
>>> which would notice the trailing string ".gnu" and do something
>>> special with it, throwing everything else to the regular DNS
>>> resolution process?
>> This is one of the main reasons why the notion of using a
>> different class for GNS is rather silly.
> 
> It would mean revising the stub resolver on each client system that
> is using GNS, which would be necessary in environments without the
> "gnunet-dns2gns" proxy, right?

Actually, even on systems with the gnunet-dns2gns proxy that would be
needed. However, on systems where GNS is locally installed, we can
intercept in say the libc NSS code via a plugin, and then that'd be
before the 'class' is ever set.  So in that case the stub resolver would
be modified in a different way that still doesn't involve DNS classes
(see https://gnunet.org/svn/gnunet/src/gns/nss/nss_query_gns.c)

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Dec 2013 18:28:52 +1100

> who suggested to change ".onion" to ".onion.alt" or ".onion.p2p". :-)

ip6.int to ip6.arpa would be a more realistic example of moving a
prefix.

You introduce the new domain.  You have software call the new domain
and if not found call the old domain.  Give it 10 years or so and
stop calling the old domain.  Anyone who hasn't transitioned by
then is cut off.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Dec 2013 12:01:41 -0500

Christian,

On Dec 8, 2013, at 8:57 PM, Christian Grothoff <[email-masked]> wrote:
> that ".gnu" is highly descriptive from a functional perspective.  

I am somewhat skeptical that a canonical Pointy Haired Boss (or other non-technical individual) would have the slightest clue what "gnu", "zkey", or any of the others meant or implied. On the other hand, my grandparents could easily grasp the concept behind ".local" even if they had no exposure the mDNS or Apple's Rendezvous/Bonjour (or the philosophy behind it).

> (see https://gnunet.org/svn/gnunet/src/gns/nss/nss_query_gns.c)

"Not Found

The requested URL /svn/gnunet/src/gns/nss/nss_query_gns.c was not found on this server."

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2013 12:26:24 -0500

Can I just point out here that the only real technical points that have been raised in this discussion thus far, at least that I can recall, are that:

(1) defining sTLDs produces a small (relatively) amount of useless traffic at the root
(2) defining sTLDs may have trademark implications that the IETF is not competent to address
(3) supporting sTLDs in stub resolvers requires changes to stub resolvers
(4) it would be nice to have stable specifications for the proposed sTLDs

There have been a lot of expressions of strong opinion on this topic, many coming from people whose opinions I generally respect, but none of these have been rooted in any technical argument that was in any way overtly expressed.

Please do not respond to this message by re-asserting your strong opinion.   Please do not respond to this message by asserting that there's a better way than what's been proposed in the draft we are discussing, in your opinion.

I assume that there is some reason for the strong negative reaction some DNS glitterati have expressed towards this proposal, but whatever that reason is has not yet been expressed.   If you have an inkling of what that reason might be, and it is not simply a strong feeling based on history, a feeling of dislike for one of the proposed name resolution protocols, or a concern about how someone might react to the IESG taking action on this, I would greatly appreciate it if you could express that reason.

I should point out that I don't have the power to call consensus on this, so you don't need to get all upset if you think this conversation is not going in the direction you want.   I'm just trying to figure out why this has generated so much heat, and so little light.

And, it is gently snowing outside.  Yay!

---

From: [email-masked]
Date: Tue, 10 Dec 2013 13:26:53 -0500

> > (public) key.  .gnu is functional in that ...

http://xkcd.com/1301/

---

From: Christian Grothoff <[email-masked]>
Date: Tue, 10 Dec 2013 18:51:58 +0100

> The requested URL /svn/gnunet/src/gns/nss/nss_query_gns.c was not found on this server."

Sorry, typo: https://gnunet.org/svn/gnunet/src/gns/nss/nss_gns_query.c

-Christian

---

From: David Conrad <[email-masked]>
Date: Tue, 10 Dec 2013 14:12:52 -0500

Ted,

> (1) defining sTLDs produces a small (relatively) amount of useless traffic at the root

The amount of useless traffic is unknown/unknowable. All we have by way of example is ".local" which accounts for something like 5-10% of the traffic to the root servers steady state (based on stats available from "L" and extrapolating). I don't think it would have been possible to estimate that number prior to Apple deciding to deploy technology that uses ".local".

However, with that said, it is very likely for the traffic any sTLD or even combination of sTLDs generates to be far less than the root servers must be able to handle to deal with DoS attacks. Probably.

> (2) defining sTLDs may have trademark implications that the IETF is not competent to address

I think a better way of describing the concern is that 6761 preempts all the efforts ICANN has undertaken to protect intellectual property right holders and thus, puts the IETF/IESG in the crosshairs of IPR lawsuits. This (probably) is not directly relevant to the draft in question (although I suppose it is possible that the folks behind gnu.com could want to get a ".brand" TLD).

> (3) supporting sTLDs in stub resolvers requires changes to stub resolvers

Or, more relevantly, lack of support in stub resolvers most likely implies applications/systems using the DNS protocols to do the lookup, implying (a) noise sent to various parts of the infrastructure (resolvers, root servers, etc) and (b) confusion on the part of end users when the resolution fails on one system but works on another.

That is, pretty much the exact same arguments people used in the past to argue against alternative roots.

> (4) it would be nice to have stable specifications for the proposed sTLDs

Sure, but I imagine a sufficiently large deployed base could be a substitute.  Which leads to:

(5) it would be nice to have more objective metrics by which one can measure the potential impact of the sTLD, e.g., it probably does not make sense to reserve a sTLD for a protocol with exactly one user whereas it probably does make sense for a protocol with 1,000,000+ users.

With respect to the draft in question:

(6) bundling the various sTLD requests into a single draft makes discussing the pros/cons of a specific sTLDs more complicated.

> Please do not respond to this message by re-asserting your strong opinion.   Please do not respond to this message by asserting that there's a better way than what's been proposed in the draft we a…

I hope I met your requirements.

Regards,
-drc

P.S. Shouldn't it be 'TLPDs' (using the terminology from 6761: "top-level pseudo-domains")? To me, "sTLDs" is confusingly similar to "sponsored TLDs", but that might be because of my ICANN infection.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 10 Dec 2013 14:15:36 -0500

> I hope I met your requirements.

Yes, thanks.   :)

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 12 Dec 2013 13:45:22 -0500

Hi Ted,

I think this is a really helpful question, so I'll attempt to answer it constructively….

I'm also going to suggest a reframing though, because (to start at the end of your note), I think a lot of the fireworks have occurred because we're talking about two different sets of issues here: the specifics of the draft and the special-use names registry (operational and implementation implications of the request and the draft itself) and some broader, systemic issues of architecture and even (shudder!) policy.  Each can be volatile on its own, so mixing them is guaranteed to be :)

The draft itself is obviously a serious attempt at justifying the reservation requested under RFC 6761, and I commend the authors for doing that. I hope they don't take the concerns being raised as unfriendly to their participation here.

("DNS glitterati" I'm not, but I've run a few nameservers and participated in DNS protocol discussions from time to time….)

In order to your points….

> (1) defining sTLDs produces a small (relatively) amount of useless traffic at the root

This is a specific operational issue. I think David Conrad nailed it; my own experience of root name server operation makes it difficult to see this as a problem, with a couple of caveats:
	* scalability comes into play at some point; I'd be fairly nervous about a special-use names registry that was significantly bigger than the "real" DNS root, for example! (see to your question 3 below). Six names is nowhere near a concern from that perspective.
	* The amount of leakage is going to be larger or smaller, and more or less predictable, depending on the clarity of the instructions to implementors on how to avoid it for the protocols using the reserved names. In turn this has scalability implications for how widely used a given name/protocol becomes as well as how many there are. I'm not familiar with those protocols in detail, so I don't know the answer to this question. But if having a reserved name associated with the protocol is expected to support expanded use, it's worth looking at how to make use of the reserved name as simple and foolproof as possible.
	
> (2) defining sTLDs may have trademark implications that the IETF is not competent to address

This is an architectural and policy issue, and isn't inherent in any specific special-use name but comes up as soon as we've admitted that one of the desirable properties of DNS-like namespaces is that they promote the use of names that have some significance to humans. 

Names are controversial. Scope of names doesn’t always travel with them; one of the problems with using things that look like DNS names is that in certain policy realms, people think of DNS names as global, particularly DNS names that look like TLDs. Not all of the controversies about what names are OK in the DNS root are likely to come along with RFC 6761 names, but some will, and the RFC 6761 assertion that such names are “protocol” and therefore strictly “technical” does not end the argument that will ensue.

After some years of experience with DNS protocol and namespace issues, including a front-row seat to the controversies ICANN has been involved in, I understand completely that no one— not ICANN, not vendors like my current employer, not even the IETF— can tell people what to do or what to name things inside their own networks. I understand that there’s no way to force people to use the special use names registry, and no way that reserving or refusing to reserve a name can be relied upon to change anybody’s behavior in the real world, so complaining that an RFC 6761 name reservation encourages or blesses behavior someone doesn’t like is going to be dubious at best. But I’m not the person you need to be concerned about here.

I’m also not arguing that these issues can’t be overcome. I *am* arguing that there’s more to handling them than asserting "these names are for ‘technical' use and only look like DNS names, so none of the issues around ‘real' TLDs apply.” Some don’t (e.g. registry policy, DNSSEC). Some do (“you can’t have $foo in the DNS because it would collide with a reserved name.” “But it’s incredibly valuable as a DNS name and I have the right to use it!”— see the name collision problem we’ve already got, with the accompanying problem of proving something *isn’t* already in use.)

In terms of scalability, it's worth noting that whatever problems we might be "borrowing" from ICANN-space become more likely roughly in proportion to how many names we're talking about and how widely used/visible they're going to be.

> (3) supporting sTLDs in stub resolvers requires changes to stub resolvers

This appears to be the case and is another operations/implementation issue. The expectation appears to be that the stub the application uses will know that a given protocol requires/expects not only that certain names aren't really DNS names, but what special handling to apply instead (five of the six discussed in the draft are supposed to get NXDOMAIN, the sixth appears to require something more complex). 

This expectation is more realistic for an application-specific stub than for a system-specific one. Which architecture it makes more sense to expect an implementor to be trying to build is a judgment for people who know lots more about application  behavior than I do. 

Part of the answer here also goes to scalability. A system-based or general-purpose stub is going to get harder to write, configure, and debug as the list of special names gets longer and the list of special behaviors that have to be coded into it expands. Overall, the complexity of administering namespaces and resolving names grows with the number of special names. Since DNS resolvers and DNS-like namespaces can be pretty complex already, it's again a question of how many of these things do we want or need? in addition to the utility of any given one. 

I suspect there are lots of protocols people are working on now, or will work on in the future, where "Hey, a special-use DNS-like name would help here, let's get one….or several…." will sound like a good idea. Having lots of them may not be such a good idea regardless of the merits of any one in particular.

How useful is useful enough, then? 6761 provides some guidance on this, but leaves lots of room for judgment, which is why we're having this conversation.

> (4) it would be nice to have stable specifications for the proposed sTLDs

I'd go further than "it would be nice," because I happen to think for the reasons above that it shouldn't be too easy to get a special-use  name and it shouldn't be too difficult for the implementor to tell how they should be treated when they do appear-- "it's not a DNS name, so don't worry about it" won't cut it.

Having not reviewed the underlying protocol specifications associated with this draft, I'm not comfortable judging whether they are strong enough.
> I assume that there is some reason for the strong negative reaction some DNS glitterati have expressed towards this proposal, but whatever that reason is has not yet been expressed.   If you have a…

My reasons:
	* I'm not convinced the current draft is clear enough on the operational specifics of how an implementor should treat the requested names, or how the overall DNS system will manifest leakage or other mishandling of these names. This is operational and probably fixable.
	* I'm not convinced we've thought through how to manage "technical"/infrastructure DNS-like names in a world where those have policy implications we may not like but can't reasonably ignore. This is a matter of architecture and policy and can really only be resolved by discussion and judgment.

Hope this helps,
Suzanne

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Dec 2013 16:07:56 -0500

Thanks—this is a very helpful response.   So if I were to condense your response down, I would pull out the following (I'm doing this not to put words in your mouth, but because I'm trying to make sure I don't misrepresent what you've said):

1. Although the current proposal doesn't create a clearly bad amount of stress on root servers, a policy of allocating tons of sTLDs might eventually have a substantial impact on the root, simply because of the large number of unanswerable queries that would be emitted from brokenware and not caught by intermediate caches.   So we should be figuring out what, if anything, we can do about that eventuality, should it arise.

2. You seem to be agreeing with the statement that's been made by a number of folks that if the particular proposed allocations are to happen, the discussion ought to include ICANN, because they have thought about this issue a lot (you didn't actually say this, but it's what I take from your response to my point 2).   And this has the same scaling problems you mentioned in point 1, this time with respect to the thought process about trademarks.

3. Adding a lot of sTLDs really will have a significant impact on stub resolvers (you gave some good examples).

4. Not having clear specifications will exacerbate the problem mentioned in 3, and you don't know whether the current specifications are clear enough (my own experience of them from having gone and looked is that there is probably a lot of the right information, but it's not straightforward to find it, and it's not clear that it's stable in any useful sense).

> 	* I'm not convinced the current draft is clear enough on the operational specifics of how an implementor should treat the requested names, or how the overall DNS system will manifest leakage or ot…

Yup.   I think we need to have a better answer than we currently have, and to a point drc made a while back, probably better data than we have now on the current garbage query load on the root.

> 	* I'm not convinced we've thought through how to manage "technical"/infrastructure DNS-like names in a world where those have policy implications we may not like but can't reasonably ignore. This…

That's pretty much what moved me to start this conversation.   I think it's been a useful conversation, but I don't think we've really got an answer yet.

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 18 Dec 2013 10:58:16 -0500

Hi Ted,

Thanks for this, a couple of clarifications inline….

> 1. Although the current proposal doesn't create a clearly bad amount of stress on root servers, a policy of allocating tons of sTLDs might eventually have a substantial impact on the root, simply b…

Sadly I think this is true….we have to engineer not only to the DNS when it works and people are operating everything properly, but to the DNS when it doesn't and they aren't, at least as far as foreseeing the problems we're buying. As a minor point-- this sounds like a fairly far-fetched hypothetical in your formulation, and I don't regard it as particularly far-fetched.

> 2. You seem to be agreeing with the statement that's been made by a number of folks that if the particular proposed allocations are to happen, the discussion ought to include ICANN, because they ha…

I do think that some discussion with ICANN is called for, although both 6761 and the IAB's MoU with ICANN are silent on the course such a discussion should take. There's an IAB liaison to ICANN's Board which should get involved-- I think I saw a reference in another discussion (the dns-dir message archive) to doing that already, which seems right to me.

The concern over potential controversy takes two forms: 
	* intellectual property and related politics; not just trademark-- see for example the controversy among government and commercial players over .amazon or .wine.
	* we don't know if or when ICANN has additional plans to expand the namespace significantly again. If there are none, many of these risks go away. But otherwise it would be nice to have some idea how the IETF process for picking future special names could limit the risk of a problem over a particular name, and to be sure ICANN was equally intent on avoiding a problem with the special use registry.

Experience in both realms convinces me that everyone is interested in avoiding a problem. But we may need some additional consideration of how exactly to do that.

> 3. Adding a lot of sTLDs really will have a significant impact on stub resolvers (you gave some good examples).

It adds complication. As an operator, this is my primary concern-- not what the names are, but how they're supposed to work.

> 4. Not having clear specifications will exacerbate the problem mentioned in 3, and you don't know whether the current specifications are clear enough (my own experience of them from having gone and…

I've looked briefly at a couple of the underlying documents since I wrote last, agreed on this.

> Yup.   I think we need to have a better answer than we currently have, and to a point drc made a while back, probably better data than we have now on the current garbage query load on the root.

FWIW there is some good data, not only the L-root public data but the datasets various people used in their analyses of existing namespace collisions between private use names leaked to the root and the current round of new gTLD names applied for with ICANN. Other root servers make various data publicly available; for example, the RIPE NCC regularly publishes per-node data for K-root at http://k.root-servers.org on most popular TLDs queried, including non-valid ones, and on distribution of return codes sent including NXDOMAIN. 

More, and on a more common basis across servers, would be really helpful. There are folks working on this….

> That's pretty much what moved me to start this conversation.   I think it's been a useful conversation, but I don't think we've really got an answer yet.

You and me both :)

best,
Suzanne