Subject: [DNSOP] draft-wkumari-dnsop-alt-tld-04

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Feb 2015 14:36:39 +0800

Hi all,

Warren and I have prepared draft-wkumari-dnsop-alt-tld-04.  We'd
appreciate feedback.  If there isn't any, maybe that's a sign that we
could just publish it and thereby create a special TLD in which people
could set up their various special use special names?  This would be
tidier than having people doing it in the root zone.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: George Michaelson <[email-masked]>
Date: Thu, 12 Feb 2015 16:44:51 +1000

the concerns in my mind divide up into politics and technology.

The politics response is really simple: "this idea is doomed." -I wish I
felt otherwise, but I think given the context of the debate over ICANN, who
'owns' names, $180,000 application fees, IAB directions to IANA, NTIA role,
this is mired.  I don't want to be a prophet of doom, but this is my honest
perspecive.  Reality is a harsh blowgun which occasionally fires of
beautiful butterflies.

Technology wise, this is short, and simple and clear. Would we had this
before .onion eventuated, and dare I say it even .local from another time
and place. WIring a TLD to be used for alternate namespaces so that we can
safely anchor non-DNS names into the DNS and avoid repetitious stupidity is
a good plan.

Would it be DNSSEC signed with a well known key?

I like the draft. I felt I could understand it, which is always a huge win
for me.

_G

On Thu, Feb 12, 2015 at 4:36 PM, Andrew Sullivan <[email-masked]>
wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 12 Feb 2015 07:49:27 -0500

On Feb 12, 2015, at 1:44 AM, George Michaelson <[email-masked]> wrote:
> Technology wise, this is short, and simple and clear. Would we had this before .onion eventuated, and dare I say it even .local from another time and place. WIring a TLD to be used for alternate namespaces so that we can safely anchor non-DNS names into the DNS and avoid repetitious stupidity is a good plan.

I think that if .alt had existed when .local was defined, nothing would have been different. From a UI perspective, using an extra label to identify that a particular domain is special-use is worse, because it's more typing, and doesn't really make sense--which makes more sense: "myhost.local" or "myhost.local.alt"?

So I think this work is worth doing, because there are probably cases where .alt will do just fine, but I don't think it gets rid of the problem of top-level special-use domains.  The "SHOULD" recommendation in the document is the right level of applicability: "MUST" would be wrong, and I appreciate that the authors did not use it.

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Feb 2015 08:43:49 +1000

I had imagined, in that simpler time, that users never saw alt, but
imported other-name-space calls mapping into gethostbyname() acquired .alt
unless an override was present. Ie, it was a more formal label of inclusion
of a non-DNS namespace so the alt label was in-system, not visible in the
other namespace.

This is how I recall the mapping from the pre-USENET news systems like the
one Jacob Palme ran, on Dec-10s was intruded into usenet news: his stuff
had a qualified form which was legal in-system in usenet, but was acquiring
a magic label on entry from the Dec-10 world. Lots of sendmail.cf files did
transforms which added/removed/appended/re-ordered mail addys to get magic
tokens in and out.

-G

On Thu, Feb 12, 2015 at 10:49 PM, Ted Lemon <[email-masked]> wrote:

> I think that if .alt had existed when .local was defined, nothing would
> have been different. From a UI perspective, using an extra label to
> identify that a particular domain is special-use is worse, because it's
> more typing, and doesn't really make sense--which makes more sense:
> "myhost.local" or "myhost.local.alt"?
>
> So I think this work is worth doing, because there are probably cases
> where .alt will do just fine, but I don't think it gets rid of the problem
> of top-level special-use domains.  The "SHOULD" recommendation in the
> document is the right level of applicability: "MUST" would be wrong, and I
> appreciate that the authors did not use it.
>
>

---

From: David Conrad <[email-masked]>
Date: Fri, 13 Feb 2015 09:38:42 +0800

George,

> The politics response is really simple: "this idea is doomed." -I wish I felt otherwise, but I think given the context of the debate over ICANN, who 'owns' names, $180,000 application fees, IAB directions to IANA, NTIA role, this is mired.  I don't want to be a prophet of doom, but this is my honest perspecive.

As with most "really simple" answers, the reality is a bit more complicated.  My impression of this draft is that it creates a space that would avoid some of the risks associated with RFC 6761. Politically, I suspect this is desirable, even to all the parties you mention. As for the fee, ICANN already defers to the IETF in protocol-related matters, so I don't see why a new gTLD fee would be applicable.  With my ICANN hat on, I'll look into this and report what I hear back.

> Would it be DNSSEC signed with a well known key?

Sure, why not?

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

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Feb 2015 15:42:46 +1000

There is no downside to being a Jeremiah, because being proved wrong makes
the world a better place than I fear.

If you can give some positive indications that a well formed IAB request
for delegation gets a smooth path, then I'm all in favour.

Equally, if that can be done, then .LOCAL can be done. And in principle
.ONION but I guess .ALT is about avoiding the land-grab of me-too. The
downside of ALT is that it won't fix the actual concrete problem of .local
or .onion because neither is going to change codebase. I fear. Equally,
welcome to be proved wrong in practice. Delighted even!

-G

On Fri, Feb 13, 2015 at 11:38 AM, David Conrad <[email-masked]> wrote:

> perspecive.
> As with most "really simple" answers, the reality is a bit more
> complicated.  My impression of this draft is that it creates a space that
> would avoid some of the risks associated with RFC 6761. Politically, I
> suspect this is desirable, even to all the parties you mention. As for the
> fee, ICANN already defers to the IETF in protocol-related matters, so I
> don't see why a new gTLD fee would be applicable.  With my ICANN hat on,
> I'll look into this and report what I hear back.
>

---

From: Paul Vixie <[email-masked]>
Date: Thu, 12 Feb 2015 21:45:51 -0800

> David Conrad <mailto:[email-masked]>
> Thursday, February 12, 2015 5:38 PM
> George,
>

can we sit back and ponder what it will mean if .ALT becomes an implicit
extra search list for many end users, and then xyzzy.alt is created, and
later, .xyzzy is created. i expect this eventuality to spur considerable
interest from icann, perhaps coming in the form of "since we can't
control what the ietf does with implicit search list behaviour, we're
skittish about allowing something like .ALT to come into existence that
would, when combined with implicit search lists, lead to complete and
utter chaos."

this is not in other words simply a protocol-related matter.

-- 
Paul Vixie

---

From: David Cake <[email-masked]>
Date: Fri, 13 Feb 2015 14:20:00 +0800

Yes, this is not simply a protocol-related matter. Which is why the IAB wrote to the ICANN board alerting them to the issue, and the ICANN board passed this on to the community, specifically inviting interested community members to join this list.
Some of us did so. If those of us active in the ICANN names policy community feel that there needs to be a policy response to this issue, we will say so.

I would certainly not assume it is doomed. As David Conrad says, there are many who feel it would serve a useful purpose. Even if there are policy implications, that does not mean that ICANN will not defer to the IETF, we may simply initiate our own internal processes to deal with implications.

Regards

David
(currently vice-chair of the ICANN GNSO Council).

On 13 Feb 2015, at 1:45 pm, Paul Vixie <[email-masked]> wrote:

> 
> 
>> 	David Conrad	Thursday, February 12, 2015 5:38 PM
>> George,
>> 
> can we sit back and ponder what it will mean if .ALT becomes an implicit extra search list for many end users, and then xyzzy.alt is created, and later, .xyzzy is created. i expect this eventuality to spur considerable interest from icann, perhaps coming in the form of "since we can't control what the ietf does with implicit search list behaviour, we're skittish about allowing something like .ALT to come into existence that would, when combined with implicit search lists, lead to complete and utter chaos."
>

---

From: George Michaelson <[email-masked]>
Date: Fri, 13 Feb 2015 16:23:39 +1000

how about if the rules of sub-delegation under ALT are that 1) you only get
an OID 2) the OID has to be registered with IANA in the normal way 3) the
OID registry identifies the external namespace, which is being bound into
the system.

Then, it becomes clear this is a mapping space for functions like
gethostbyname() to have as a context specific search string, and are
significantly less likely to collide with GTLD since they are simply digit
strings.

On Fri, Feb 13, 2015 at 3:45 PM, Paul Vixie <[email-masked]> wrote:

>
>
>   David Conrad <[email-masked]>
> interest from icann, perhaps coming in the form of "since we can't control
> what the ietf does with implicit search list behaviour, we're skittish
> about allowing something like .ALT to come into existence that would, when
> combined with implicit search lists, lead to complete and utter chaos."
>

---

From: Ed Pascoe <[email-masked]>
Date: Fri, 13 Feb 2015 10:05:47 +0200

I like this draft and I think the sooner this becomes a reality the better.

Its seems like every other week there a new application that adds "dns
discoverability" via a made up root zone. Combine this with the new round
of TLD applications that are expected in the next year or two and its going
to get messy.

Just a thought, if the .home and .corp gTLD applications ever get formally
rejected by ICANN maybe they should get the same treatment as .alt? That's
the de facto state of affairs right now anyway.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 13 Feb 2015 15:03:49 +0000

What Paul mentions below raises the specter of name collisions - the
activation of a name resulting in undermining a errant system which, until
the activation, wasn’t all that bothered by the name being inactive.  Search
lists have been one root cause suggested and sometimes even observed as
contributing to this problem.

The issue here is that there are strings that humans use for identification
and there is the DNS.  There’s an overlap when DNS names are transliterated
into printable format - what I mean is that “example.com.” isn’t what the
DNS passes over port 53, it passes
“0x07’e’’x’’a’’m’’p’’l’’e’0x03’c’’o’’m’0x00”.   But we read and write that
as example.com.

There’s a barbershop near the ICANN offices (ironically enough) that has
this on their store front: minibar.ber.shop.  That’s not a domain name, it
is the name of a store.  They did also have “www.minibarbershop.com” on the
banner announcing they’d open in June 2014.  (They advertise beer and
haircuts - I just hope the person with sharp objects isn’t drinking as they
snip.  And I’m not sure how you drink beer and keep your head still.  But I
digress.)

I see the problem as creating a way to use dotted names (that look like
transliterated domain names) that will never resolve in the DNS.  (I think
that’s pretty obvious.)  To do this, what’s needed is a space in the DNS
that will just not be used.  Here “ALT” is proposed.

I am supposed to be working on (as in, I’d be doing it now if I weren’t
responding to email) a draft to propose that the strings corresponding to
the ISO 3166("mumble-mumble" as Warren says) two letter codes for counties
and regions what are categorized as “user assigned” be set aside as TLDs
that won’t ever happen.  (For example - “xx”)  I’m just throwing this out
here as an idea - please respond privately to me until I can get a coherent
draft together on this.  (In the mean time, Wikipedia has a short
description of these codes at
http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#User-assigned_code_elements.
)

What’s promising about reserving the user assigned two-letter codes is that
there is already a $policy (perhaps it’s folklore) that when it comes to the
two letter codes, IANA heeds the advice of the ISO 3166 documents.  Except
for dotUK (and that is noted in Wikipedia’s article).

(An aside, if anyone knows of a formal statement of such a policy, I’d
appreciate it if you can send that to me privately for the draft.  I’ve
heard it said many times over the years, but I don’t know that it was ever
formalized.  Perhaps in some old RFC…)

The only way for all this is to build a convention, because there’s no
protocol solution, for classifying dotted string formatted identifiers as
DNS transliterations or, well, something else.  The only way for the DNS to
not be part of the problem is to burn in the convention so that it doesn’t
undermine errant applications - and by errant here I mean applications using
a legitimate identifier space assuming that it’s part of the DNS space.

On 2/13/15, 0:45, "Paul Vixie" <[email-masked]> wrote:

>> As with most "really simple" answers, the reality is a bit more complicated.
>> My impression of this draft is that it creates a space that would avoid some
>> of the risks associated with RFC 6761. Politically, I suspect this is
>> desirable, even to all the parties you mention. As for the fee, ICANN already
>> defers to the IETF in protocol-related matters, so I don't see why a new gTLD
>> fee would be applicable.  With my ICANN hat on, I'll look into this and
>> report what I hear back.
> 
> can we sit back and ponder what it will mean if .ALT becomes an implicit extra
> search list for many end users, and then xyzzy.alt is created, and later,
> .xyzzy is created. i expect this eventuality to spur considerable interest
> from icann, perhaps coming in the form of "since we can't control what the
> ietf does with implicit search list behaviour, we're skittish about allowing
> something like .ALT to come into existence that would, when combined with
> implicit search lists, lead to complete and utter chaos."
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 14 Feb 2015 17:56:30 +0100

On Thu, Feb 12, 2015 at 02:36:39PM +0800,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 20 lines which said:

> appreciate feedback.  If there isn't any, maybe that's a sign that
> we could just publish it and thereby create a special TLD in which
> people could set up their various special use special names?

This is a bad idea and should be dropped completely.

The main reason why I say so is that we already have RFC 6761 and it
exists precisely to register special names. I was not a big fan of
this RFC (that's an understatement) but, now that it exists, I see no
reason to obsolete it after only two years of existence and only one
TLD, an Apple's one, registered. Worse, draft-wkumari-dnsop-alt-tld-04
misrepresents RFC 6761 by saying things like "Special Use TLDs which
should only be used in exceptional circumstances" while it is never
written in RFC 6761.

Other reasons:

* existing code will not be modified and the names in
draft-grothoff-iesg-special-use-p2p-names will have to be considered
anyway. So, .ALT adds work for dnsop / the IESG without addressing the
existing requests (.ONION, .GNU, .IP2P, etc).

* the draft is confused in terminology between "domain name" and "DNS
name". There is no such thing as a "DNS name". Domain names can be
looked up in the DNS but they are used in many different contexts and
can be resolved by several protocols. If someone sets up a RDAP server
for Namecoin, names in .BIT or .COM will use the same protocol for
information retrieval.

* the draft uses terms like "pseudo-TLD" which are uselessy
deprecative.

* .ALT claims to be registered under the RFC 6761 framework but the
draft ignores the requirments of its section 5.

---

From: David Conrad <[email-masked]>
Date: Sun, 15 Feb 2015 13:31:53 -0800

Stephane,

> exists precisely to register special names.

Well, yes, albeit in the root, thereby generating useless traffic to the root resulting in increased latency, additional network traffic, potential privacy violation, and creating a potential conflict between the IETF and the entity to which the IETF delegated policy for registering TLDs.

> I was not a big fan of
> TLD, an Apple's one, registered.

The reason I see is to try to limit the damage caused by 6761.

> existing requests (.ONION, .GNU, .IP2P, etc).

Do you believe there will be no further requests for TLDs based on 6761?

> can be resolved by several protocols.

In my view, a "DNS name" is the subset of "domain names" that can be looked up via the DNS.

> * the draft uses terms like "pseudo-TLD" which are uselessy

I didn't take "pseudo-" as deprecative, but I suppose it could be viewed that way.

> draft ignores the requirments of its section 5.

Fair enough.

Regards,
-drc

---

From: Warren Kumari <[email-masked]>
Date: Mon, 16 Feb 2015 08:00:24 +0800

On Sun, Feb 15, 2015 at 12:56 AM, Stephane Bortzmeyer <[email-masked]> wrote:
>  Worse, draft-wkumari-dnsop-alt-tld-04

For those following along at home, this comes from the introduction:

"This document provides a solution which should be used in most cases
  instead of [RFC6761].  RFC6761 specifies Special Use TLDs which
  should only be used in exceptional circumstances."

This document is not intended to, and does not, obsolete RFC 6761:

draft-wkumari-dnsop-alt-tld wkumari$ grep -i 'Obsoletes' *
draft-wkumari-dnsop-alt-tld wkumari$

It is trying to provide guidance on when RFC6761 is appropriate and
when this solution should be used instead.
The second sentence was not intended to sound like a quote from
RFC6761, but it could be worded better.

How about:
"This document provides a solution that may be more appropriate than
[RFC6761] in many cases"?

> existing requests (.ONION, .GNU, .IP2P, etc).

Yup. This does not address the existing requests - it's neither my
place, nor intent to do so. I happen to think that some of the
existing requests have merit, but that's not relevant...
This document is intended to cut down on the number of future
requests, and provided guidance to folk who are developing alternate
namespaces.
As we can see from the ICANN new gTLD process (1930 applications,
~$185,000 USD each[0]) people have decided that TLDs (and probably
things that act like TLDs) have value.
I'm quite sure we will see a large increase in people using things
that look and act like TLDs.
This proposal provides a place for people who want to use things that
kinda act like the DNS, without having the names leak into the DNS
(possibly colliding with names in the global DNS, and also potentially
leaking private info, like the names being looked up)

> * the draft uses terms like "pseudo-TLD" which are uselessy

Can you suggest a better term (noting that this term is used in  both
RFC6761 and draft-grothoff-iesg-special-use-p2p-names-04)?
They are things that look like TLDs when leaking into the DNS context,
but are not actually TLDs.

This seems to be a very common term, and was not intended to be
perjorative, see for example:
RFC6761 - Special-Use Domain Names
(https://tools.ietf.org/html/rfc6761)  Section 1:
"This is typically done by stating that any fully qualified domain
name ending in a certain suffix (i.e., falling within a specified
parent pseudo-domain) will receive the special behaviour. "

draft-grothoff-iesg-special-use-p2p-names-04, Section 3 (Terminology
and Conventions Used in This Document):
"The abbreviation "pTLD" is used in this document to mean a pseudo
Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
reserved to P2P Systems in this document."

RFC1429 - Listserv Distribute Protocol, Section 3.3:
"You can use the pseudo-domain ".BITNET" for BITNET recipients: it is
always supported within DISTRIBUTE requests."

RFC1849 -  "Son of 1036": News Article Format and Transmission (Historic):
"The pseudo-domain ".uucp" MAY be used for hosts registered in the
UUCP maps ...."

'Measuring the Leakage of Onion at the Root “A measurement of Tor’s
.onion pseudo-top-level domain in the global domain name system”' -
Matthew Thomas and Aziz Mohaisen.
https://www.petsymposium.org/2014/papers/Thomas.pdf

> draft ignores the requirments of its section 5.

Yup, good catch -- we have not filled in the "form" in RFC6761. This
was one of those things that we kept meaning to get to, but kept
putting off... and then completely forgot about...

W
[0]: Yup, not all were approved, some were withdrawn, some may have
qualified for hardship reductions, this is only application fees,
doesn't count a: auctions, b: legal, c: operations, d: marketing, e:
legal, etc. Whatever the case, lots of folk have decided that there's
gold in them thar hills...

-- 
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: hellekin <[email-masked]>
Date: Mon, 16 Feb 2015 01:13:56 -0300

> reserved to P2P Systems in this document."
*** The terminology in draft-wkumari-dnsop-alt-tld-04 for pseudo-TLD
conflicts with the one in draft-grothoff-iesg-special-use-p2p-names-04:

  pseudo-TLD: A label that appears in a fully-qualified domain name
  in the position of a TLD, but which is not registered in the
  global DNS.

If P2PNames is accepted, "our" pTLDs *will* be registered in the global
DNS as Special-Use Domain Names.  So, your definition is in direct conflict.

Moreover, draft-wkumari-dnsop-alt-tld-04 mentions:

  Unless the name desired is globally unique, has meaning on the global
  context and is delegated in the DNS, it should be considered an
  alternate namespace, and follow the ALT label scheme outlined below.

Therefore names reserved in draft-grothoff-iesg-special-use-p2p-names-04
are not concerned by .ALT: not only some of the P2PNames are globally
unique (.ZKEY, .ONION, .BIT), the others (.GNU, .I2P, .EXIT) have
privacy requirements that cannot be delegated to a DNS zone: the draft
says: "pTLDs are not manageable by some designated administration."
Instead, the DNS software must be aware of these pTLDs and return
NXDOMAIN *without* passing them on to the DNS for resolution.  The
draft-wkumari-dnsop-alt-tld-04 does not cover this case, and cannot
cover it in a better way that RFC6761 and the Special-Use Registry.
(Please review
http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-04#section-2)

Meanwhile, draft-wkumari-dnsop-alt-tld-04 suggests that the Tor project
"could 'root' their namespace under onion.tor.example.com."  This is not
only technically mistaken, it's also irrelevant to this draft, as .onion
names are (probabilistically) globally unique, they have
(self-referential) meaning [in] the global context, and they (will be)
"delegated" to the Special-Use Registry (which prompts for clarification
of what "delegated in the DNS" means--I suppose it means to a registrar,
which is not the case).

Can you please remove any mentions to the Tor project in this draft, as
it is irrelevant and can confuse people into thinking that .onion names
can be delegated to the DNS?

Regards,

==
hk