Subject: [DNSOP] Alternative Special-Use TLD problem statement draft

From: Ted Lemon <[email-masked]>
Date: Tue, 5 Apr 2016 19:35:19 +0000

I wrote about six pages of comments on the recently-submitted special-use TLD problem statement document.   However, ultimately I concluded that it would be easier to just write what I thought the problem statement should look like rather than try to suggest (and then no doubt discuss one by one) a large set of changes that I think it needs.

So this weekend I spent quite a bit of time talking to various people who I knew would have insight into the question, and the result is the draft I just submitted.  Ralph Droms was instrumental in inspiring me to write the document, and helped me out by doing an initial review.

I've included the submission announcement below.   I realize that this is a woefully late submission for discussion at IETF 95, since I mostly wrote it yesterday, _at_ IETF 95.   However, I think it may serve as a better starting point for the discussion than the current problem statement draft, so if you have time to read it, I would genuinely appreciate it if you could give it a look.

Thanks!
________________________________________
From: [email-masked] [[email-masked]]
Sent: Tuesday, April 5, 2016 15:09
To: Ralph Droms; Ted Lemon
Subject: New Version Notification for draft-tldr-sutld-ps-00.txt

A new version of I-D, draft-tldr-sutld-ps-00.txt
has been successfully submitted by Ted Lemon and posted to the
IETF repository.

Name:           draft-tldr-sutld-ps
Revision:       00
Title:          Special Use TLD Problem Statement
Document date:  2016-04-05
Group:          Individual Submission
Pages:          15
URL:            https://www.ietf.org/internet-drafts/draft-tldr-sutld-ps-00.txt
Status:         https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
Htmlized:       https://tools.ietf.org/html/draft-tldr-sutld-ps-00

Abstract:
   The Special-Use Domain Names registration policy in RFC 6761 has been
   shown through experience to present unanticipated challenges.  This
   memo explores current IETF and non-IETF publications relating on
   special-use TLDs, describes the history of domain names, and
   enumerates some problems that have come up in connection with the
   Special-Use Domain Names allocation process specifically as it
   related to top-level domains.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Apr 2016 13:17:00 +0200

>I've included the submission announcement below.   I realize that this is a woef
>ully late submission for discussion at IETF 95, since I mostly wrote it yesterda
>y, _at_ IETF 95.   However, I think it may serve as a better starting point for 
>the discussion than the current problem statement draft, so if you have time to 
>read it, I would genuinely appreciate it if you could give it a look.

One thing I sort of missed in your draft is a clear distinction between
standards track protocols and other protocols.

I think that for standards track protocols, the normal IETF consensus process
is likely to produce something reasonable. Nothing is perfect, but the 
examples you gave (.local and .ipv4only.arpa are both quite reasonable
uses for the name space). 

If the IETF feels a need for more non-DNS naming protocols, then probably
there will be a discussion in the relevant working group on how to be co-exist
with DNS.

The problem starts with non-standards track protocols. For just about all
protocol parameters (from IP versions to port numbers to MIME types, whatever)
the IETF is the only organization that can create a registry.

Names (and also addresses and ASNs) are different. There exist organizations
outside the IETF that deal with those.

In fact, there is quite a bit of history already in some programming
languages (for example java) to just register a DNS domain to get a private
part of the global name space.

So anybody who wants to play with an experimental naming service can just
register my-naming-service.net. And use that string in any name switch code.
If so desired, additional DNS types can be registered to mark a delegation to
the new protocol.

This does not require any involvement of the IETF in the registration of the
name. Of course, having to maintain a DNS registration is way less convenient
than having a entry in some special registry. But why should the IETF be
concerned with that.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 08:52:43 -0300

On Wed, Apr 06, 2016 at 01:17:00PM +0200,
 Philip Homburg <[email-masked]> wrote 

> register my-naming-service.net. And use that string in any name switch code.

Strong dissensus here. The problem is there is no safe way to have AND
KEEP such a name. You depend on the registry's policy, which may suit
you or not, and, if the registry uses RRR, you depend on the
registrar's behavior. One mistake by Go Daddy or Network Solutions and
you lose your namespace. One complaint to a private "court" such as
UDRP and you lose your namespace.

It may work for a big company like Sun with a lot of lawyers. It does
not for the typical free software project such as .onion or the people
in the queue (.gnu, .bit, etc).

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 08:57:15 -0300

Eep.  Yes, that's a good point--thanks.   One would hope that if we publish
.ALT, they will use that, since it's no worse than .NET and avoids the
registry problem, but the lack of a .ALT registry is a problem for that.

I tend to think that "IESG approval" is how something that's not standards
track gets a name, either because it came from a different SDO or because a
standards document isn't required (and yet a name is, not sure how that
would happen for a SUTLD), but that's wandering off into solutions, and I
don't think there's consensus on how to handle it.   The hope is that we
can at least get consensus on the problems we are trying to address.

On Wed, Apr 6, 2016 at 8:17 AM, Philip Homburg <[email-masked]>
wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 09:02:44 -0300

Just speaking as an author, I (1) acknowledge your point, with which I
agree and (2) point out that what Philip described is nonetheless a problem
that ought to be mentioned in the problem statement, because cleaning up
after such a registration has been done is actually a hard problem, and so
we want to make sure that whatever solution we propose gives people a
better way to solve the initial registration problem so that they _don't_
register what they intend to be a special-use name under some TLD using the
normal TLD registration process.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 09:21:31 -0300

On Wed, Apr 06, 2016 at 08:52:43AM -0300,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 21 lines which said:

> KEEP such a name.

Also, it would make very difficult to DNS programmers to keep track of
all these "special but not special" domain names. Some people
complained that it was difficult enough with RFC 6761 (because there
is no machine-readable version of the special-use registry) but it
would be worse with scattered domain names in many TLDs.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 13:06:32 +0000

> would be worse with scattered domain names in many TLDs.

Yes.  This could be addressed on a protocol level if we used DNS as the resolution protocol of last resort, but if so we need to say how that works.   Again, this would be in a solutions document, not a problem statement document. :)

---

From: Philip Homburg <[email-masked]>
Date: Wed, 06 Apr 2016 17:05:26 +0200

In your letter dated Wed, 6 Apr 2016 09:21:31 -0300 you wrote:
>all these "special but not special" domain names. 

Personally, I consider naming systems developed outside the IETF a problem.

There should be no register, because they should not exist.

So any hint that there is a process for non-IETF naming systems should
be removed.

Naming at the root of the name space should develop very slowly. Slow
enough that everybody (local name resolution, but also security mechanisms)
can adapt.

These systems should be considered carefully for all implications before they
are deployed. And not just pop up.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 06 Apr 2016 12:13:53 -0300

On 5 Apr 2016, at 16:35, Ted Lemon wrote:

> I wrote about six pages of comments on the recently-submitted 
> special-use TLD problem statement document.   However, ultimately I 
> concluded that it would be easier to just write what I thought the 
> problem statement should look like rather than try to suggest (and 
> then no doubt discuss one by one) a large set of changes that I think 
> it needs.
>
> So this weekend I spent quite a bit of time talking to various people 
> who I knew would have insight into the question, and the result is the 
> draft I just submitted.  Ralph Droms was instrumental in inspiring me 
> to write the document, and helped me out by doing an initial review.
>
> I've included the submission announcement below.   I realize that this 
> is a woefully late submission for discussion at IETF 95, since I 
> mostly wrote it yesterday, _at_ IETF 95.   However, I think it may 
> serve as a better starting point for the discussion than the current 
> problem statement draft, so if you have time to read it, I would 
> genuinely appreciate it if you could give it a look.

Clarifying question: are you formally requesting the WG to stop work on 
draft-adpkja-dnsop-special-names-problem and switch to this one? If not, 
what do think we should do about the two?

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 13:53:31 -0300

On Tue, Apr 05, 2016 at 07:35:19PM +0000,
 Ted Lemon <[email-masked]> wrote 
 a message of 49 lines which said:

> special-use TLD problem statement document.

I like it. I find it better than the awful
draft-adpkja-dnsop-special-names-problem, with its disparaging
terminology ("pseudo-TLD", a term I would be glad to see replaced by
"SUTLD").

> However, I think it may serve as a better starting point for the
> discussion than the current problem statement draft,

+1 and I recommend to everyone to read it before the discussion on
friday.

A few remarks:

> its unilateral allocation by the TOR project without following the
> RFC 6761 process

.onion was created nine years before RFC 6761 so you cannot blame the
Tor people for not following it.

> 4.1.1.  Are Domain Names DNS Names?

You should really mention draft-lewis-domain-names here (you do it,
but later).

> 4.1.2.  Does Every Domain Name Have The Same Meaning Everywhere?

Your claim is that today's differences in DNS answers for a same name,
as we see them today, are not real differences because they don't
change the user experience, or because they are done for good (malware
domains filtering). You forgot a very important use case,
censorship. Today, if a domain name works in Germany and not in France
because of differential censorship, would you say it is "not really an
exception"?

Let's face it, we no longer have a common namespace and names no
longer have the same meaning everywhere, even when taking only the DNS
in to account.

> 4.5.  Experimental Squatting Problem

I dislike the term "squatting" which seems to imply that it was
illegal. Seriously, today, which avenue is open for a application
developer who thinks a special-use TLD would be nice for its
application? Besides patronizing like "we are the Elders, we know it
better, drop this stupid idea"?

> At present RFC 6761 doesn't give specific advice about what
> delegation, if any, should appear for newly registered SUTLDs.  It
> may be worthwhile to make a default recommendation for this.

See draft-bortzmeyer-dname-root, published ten minutes ago.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 13:56:29 -0300

Good comments, thanks. I will add something more about 451.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 14:01:37 -0300

On Wed, Apr 06, 2016 at 05:05:26PM +0200,
 Philip Homburg <[email-masked]> wrote 

> Personally, I consider naming systems developed outside the IETF a

Good summary of the disagreement.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 6 Apr 2016 14:05:13 -0300

On Wed, Apr 06, 2016 at 12:13:53PM -0300,
 Paul Hoffman <[email-masked]> wrote 
 a message of 31 lines which said:

> Clarifying question: are you formally requesting the WG to stop work
> on draft-adpkja-dnsop-special-names-problem and switch to this one?

Not speaking for the authors of draft-tldr-sutld-ps, obviously, but I
fully agree with this suggestion.

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 6 Apr 2016 14:28:43 -0300

Since draft-adpkja-dnsop-special-names-problem  has not been formally 
adopted, I feel it is up to the WG to take up this question.

tim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 15:53:12 -0300

Paul, draft-adpkja-dnsop-special-names-problem document is not a working
group document.   The working group can adopt it or not as the working
group chooses.   The same is true of the document I have offered.

So to answer a slightly different question than the one you asked, what I
am proposing is that the working group adopt the tldr document, likely with
changes, rather than adopting the adpkja document, which I think would take
much more work to get into shape.   The entire reason that I started the
tldr document is that I felt that the adpkja document not only didn't
accurately describe the problem, but contained much more text describing
some authors' beliefs about what the solutions should be than text
describing what the problem is.   I also felt that the scope of the adpkja
document was too narrow--it mostly talks about problems with 6761, without
really talking about the greater context of those problems.

On Wed, Apr 6, 2016 at 12:13 PM, Paul Hoffman <[email-masked]> wrote:

> I wrote about six pages of comments on the recently-submitted special-use
>> TLD problem statement document.   However, ultimately I concluded that it
>> would be easier to just write what I thought the problem statement should
>> look like rather than try to suggest (and then no doubt discuss one by one)
>> a large set of changes that I think it needs.
>>
>> So this weekend I spent quite a bit of time talking to various people who
>> I knew would have insight into the question, and the result is the draft I
>> just submitted.  Ralph Droms was instrumental in inspiring me to write the
>> document, and helped me out by doing an initial review.
>>
>> I've included the submission announcement below.   I realize that this is
>> a woefully late submission for discussion at IETF 95, since I mostly wrote
>> it yesterday, _at_ IETF 95.   However, I think it may serve as a better
>> starting point for the discussion than the current problem statement draft,
>> so if you have time to read it, I would genuinely appreciate it if you
>> could give it a look.
>>
>

---

From: Alain Durand <[email-masked]>
Date: Wed, 6 Apr 2016 20:07:08 +0000

From:  DNSOP <[email-masked]> on behalf of Ted Lemon
<[email-masked]>
Date:  Wednesday, April 6, 2016 at 2:53 PM
To:  Paul Hoffman <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>, Ted Lemon <[email-masked]>
Subject:  Re: [DNSOP] Alternative Special-Use TLD problem statement draft

So to answer a slightly different question than the one you asked, what I am
proposing is that the working group adopt the tldr document, likely with

‹> Ted,

The recent discussions on the wg mailing list have articulated the tussle
between, on one side the desire for the IETF to foster innovation in the
naming area, and, on the other side, the ability (or not) of the IETF, as an
organization, to deal with the socio-economic aspect such as IPR, etcŠ tied
to those ³special names². The argument being that there is nothing
fundamental that differentiate the strings associated with "special names"
from those associated with regular DNS TLDs, and, as such both are
potentially subject to those pressures.

Reading section 4.2 and 4.3 of draft-tldr-sutld-ps-00, it would appear you
are in the camp that does believe those ³special names² are immune those
socio-economic pressures and/or the IETF can deal with this. Do I get this
right?
If that is the case, then, it is not that one document is better than the
other, there is a  fundamental difference between the perspectives of the
authors.

It should follow that this is a non technical issue that is much larger than
DNSop wg.  As such, the DNSop wg might want to refrain from adopting one or
the other document until the IETF, as a community, under the leadership of
the IAB, comes to an agreement on that fundamental question. After all, the
interpretation of RFC2860 (ICANN/IETF MoU) is the prerogative of the IAB.

Alain, long time IETF participant, speaking solely as myself.

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 17:16:49 -0300

On Wed, Apr 6, 2016 at 5:07 PM, Alain Durand <[email-masked]> wrote:
> are in the camp that does believe those “special names” are immune those

I too believe this is implicit in what ted wrote.

> other, there is a  fundamental difference between the perspectives of the

this too I agree with.

It seems to me that there is a substantive issue which has to be
documented as "problem"

Is the IETF actually the right SDO to define a label which has to be
added to a zone which the IETF gave substantive control over, to
another (non-SDO) body?

I think that the socio-legal issues which vest inside ICANN cannot be
ignored simply because of a technical need/merit argument. Especially
when the technology claims a specific label, not just the concept of a
reservation for an otherwise unstated label.

> interpretation of RFC2860 (ICANN/IETF MoU) is the prerogative of the IAB.

And it would come as little surprise that this too,  I concur with.

I like Ted's document. I liked it a lot. But without recognition of
this question of "who decides" I think as a document specifying the
problem statement, its incomplete.

For me, it is simply not a "given" that the IETF is the right place to
determine labels in the top zone.

cheers

-George

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 17:24:42 -0300

it wasn't my intention to ignore the socio-legal issue, but the problem
statement also can't presume a solution. I will think about this and try to
come up with better text. thanks for the feedback, both of you.

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 17:32:34 -0300

As author of a brief, but pointedly direct draft which proposes
closing RFC6761, It should be understood that I do really, believe we
should close RFC6761.

But I'm not blind to the pressures which make people want to "fix
things" and in that sense its sensible to discuss the problem, and
define a problem statement.

I happen to believe that one solution includes closing RFC6761. I
don't think calling the solution RFC6761bis is going to help
distinguish the qualities which we need in deciding how to get labels
in the DNS, on technical grounds.

Please don't misunderstand that to mean I think there is no role in
defining technical reasons for internet-names. I'd expect to see a lot
of discussion about why labels could be homed in .ALT but somehow
cannot be homed in .arpa (or, as Ted notes, in .test or other
delegated spaces during s/w development)

I also believe the barrier to entry "or the 'height of the bar' as its
been put" should be kept high. A lot of the feedback I've received has
been how oppressive this is to s/w developers of good intent, and I
understand how frustrating it is to be blocked in time on IETF
process. I'm just aghast that the place people take themselves to here
is to functionally squat into the space they expect to be given, and
then claim a burden in software development to transit to where they
maybe should have gone (a configurable label, if any)

-George

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 06 Apr 2016 20:42:06 +0000

Why do DNS programmers need to care about these "special" names in the 
normal domain name space?

The question is what protocol to use.

I think we still need to answer the question about whether DNS namespace 
should be polluted for non-DNS resolution.

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Philip Homburg" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "Ted Lemon" 
<[email-masked]>
Sent: 7/04/2016 12:21:31 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 17:43:11 -0300

When I wrote the problem statement I tried to do my best to document the
implications of various actions that might be taken, including the 6761
registry.   I think I did that in the "Domain Name Purity" section.
Closing that registry is certainly something the IETF could do.   However,
there are significant implications if we do so, and we should understand
those implications and either be prepared to do something to address them,
or else accept that there will be consequences for not addressing them.
We should not simply blithely close the registry thinking that that will be
the end of the matter.

On Wed, Apr 6, 2016 at 5:32 PM, George Michaelson <[email-masked]> wrote:

> >> > It should follow that this is a non technical issue that is much
> larger
> >> > than
> >> > DNSop wg.  As such, the DNSop wg might want to refrain from adopting
> one
> >> > or
> >> > the other document until the IETF, as a community, under the
> leadership
> >> > of
> >> > the IAB, comes to an agreement on that fundamental question. After
> all,
> >> > the

---

From: Ted Lemon <[email-masked]>
Date: Wed, 6 Apr 2016 17:44:35 -0300

On Wed, Apr 6, 2016 at 5:43 PM, Ted Lemon <[email-masked]> wrote:

> actions that might be taken, including the 6761 registry.   I think I did
> that in the "Domain Name Purity"
>

That was supposed to be "closing the 6761 registry," in case it wasn't
obvious.

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 06 Apr 2016 20:48:19 +0000

------ Original Message ------
From: "Philip Homburg" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 7/04/2016 3:05:26 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>There should be no register, because they should not exist.
+1

>are deployed. And not just pop up.
I agree.

DNS namespace has worked basically unchanged for decades.

It's battle-hardened.

Now we decide that the DNS namespace is the one and only namespace and 
that we want other resolution protocols so therefore the DNS namespace 
has to be perverted.

And when I see arguments like the IETF should assign root names so that 
organisations who can't afford lawyers can retain perpetual rights over 
a branch of the namespace I have to shake my head.

At the very least can we not segment this off into a single root?

E.g.

have a separate registry for other protocols which all fit under .notdns

I think the security implications of a resolver checking some internet 
source for a machine readable list of the latest special use names have 
not even been considered, and I think it has the potential for some 
serious problems.  What problem(s) are we trying to solve, and what 
problems are we creating by trying to solve it.

Adrien

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Apr 2016 17:48:46 -0300

On Wed, Apr 6, 2016 at 5:43 PM, Ted Lemon <[email-masked]> wrote:
> Closing that registry is certainly something the IETF could do.

Good to understand we think we can do this, as in process permits us to do it.

> However, there are significant implications if we do so, and we should understand
> or else accept that there will be consequences for not addressing them.   We
> should not simply blithely close the registry thinking that that will be the
> end of the matter.

No, indeed. It would be naive to think that actions have no
consequences. I mean, we have a queue already. Its one thing to be
queuing outside a door which is shut but you think will re-open, and
its another to have the security guard post "permanently closed" on
the door.

Uproar aside, I'd expect a pretty direct focus on the problem
statement. From a lot more people. And that for me, is part of the
problem. I've said elsewhere that I think the absence of architecture
is one of the most disappointing aspects of what 6761 does. The
conversation in arcing was a good sign that some people have a sense
of architecture, and are seeking a cohesive position based on
architecture.

-George

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 06 Apr 2016 20:55:56 +0000

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Ted Lemon" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 7/04/2016 4:53:31 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>longer have the same meaning everywhere, even when taking only the DNS
Depends on what you mean by meaning.  for a resolver they still have the 
same meaning.  You stlll use DNS to resolve them.

You're saying that because some companies do geo-location using DNS, and 
other countries use DNS to effect censorship that we should therefore 
break DNS completely by wedging in new protocols?

The actions done by the geo-locators and censors don't change the fact 
that the names are resolved in the DNS.

This is what special use names breaks.

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Apr 2016 21:51:03 -0300

Hi,

> Some people
> is no machine-readable version of the special-use registry)

Last I looked http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml was XML and it's machine-readable.

> but it

OK, I'll say it.

Put special use registry be put into the DNS, e.g.,

$ORIGIN special-use-domain-names.arpa.

10.in-addr.arpa IN URI 10 1 "http://www.iana.org/go/rfc6761"
...
onion  		IN URI 10 1 "http://www.iana.org/go/rfc7686"
...

(in keeping with the t-shirt slogan)

Regards,
-drc
(speaking only for myself)

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Apr 2016 21:52:59 -0300

> There should be no register, because they should not exist.

This appears to assume that naming systems are only developed in the IETF or that a naming system not developed in the IETF is not relevant/impactful.

I don't think this is a good assumption.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 6 Apr 2016 22:19:58 -0300

Adrien,

> I think we still need to answer the question about whether DNS namespace should be polluted for non-DNS resolution.

I believe your question is wrong.

The "DNS namespace" can't be polluted for non-DNS resolution because the DNS namespace is, by definition, only comprised of names that can be resolved via the DNS.  The "Internet namespace" is larger than that.  Even before RFC 6761, there were names that should never hit the DNS, specified in RFCs 2606 and 1918. RFC 7686 added "onion". A number of folks want to add more.

In my view, the real question here is what is the distinguishing characteristic(s) and processes by which an "Internet name" is categorized as a "DNS name" (which, at least at the top level, presumably falls under ICANN community-defined policies) and those fall under a different categorization.

Regards,
-drc

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 01:44:44 +0000

OK, if we look at those 1 at a time.

RFC1918 defines private IP address ranges.

Stating that a reverse lookup for a private IP should never be encoded 
onto a DNS packet and sent to a DNS server flies in the face of 
practice, and there are many many useful scenarios where this is done.

I don't think we are being precise enough when we say "shouldn't hit the 
DNS".  PTR lookups for private IPs is a case where we do it all the time 
on private networks - use DNS to query a local DNS server for the name 
associated with a private IP.  If we took this to heart and prevented 
this by special casing such lookups in our DNS resolver code, we would 
break a lot of legitimate stuff.

It gets more blurred when your ISP assigns you a private IP address.  In 
this case PTR lookups for addresses in the subnet may well be legitimate 
against the ISP's name server.

Looking then at 2606

the top level reserved names

.test
.example
.invalid
.localhost

and

example.com
example.net
example.org

It's clear that the reservation of the second level domains is not 
behaving as we intend with 6761, since I can do a resolution of these 
names with DNS, and connect to the servers with HTTP.

As for the top level ones, localhost is about the only one where you 
typically see actual special code in resolvers AFAICT.

It's one thing to reserve a TLD.  It's another thing to actually use it 
for something non-DNS.

I don't have a problem with necessarily reserving TLDs to never be used. 
  But DNS resolvers should not be making decisions about that, and as 
soon as you reserve one, and then start using it you have these leakage 
problems that TOR is seeing.

I'm also not convinced that there is an "Internet namespace" that's 
usefully different to and a superset of the DNS namespace.  It seems a 
bit of a logical paradox to have the universe being bigger than the tree 
but also being in the tree.  Or is "Internet namespace" the new name for 
the DNS namespace and DNS namespace has been demoted to only being the 
part of the tree that is left after you add these other TLDs.  Seems a 
bit circular to me.

So, we're left with the 1 single TLD that is the problem and that's 
.onion, and regardless of the problems that is demonstrating, we wish to 
roll out more of these.

Adrien

------ Original Message ------
From: "David Conrad" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 7/04/2016 1:19:58 p.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>Adrien,
>
>>  I think we still need to answer the question about whether DNS 
>>namespace should be polluted for non-DNS resolution.
>
>The "DNS namespace" can't be polluted for non-DNS resolution because 
>the DNS namespace is, by definition, only comprised of names that can 
>be resolved via the DNS.  The "Internet namespace" is larger than that. 
>  Even before RFC 6761, there were names that should never hit the DNS, 
>specified in RFCs 2606 and 1918. RFC 7686 added "onion". A number of 
>folks want to add more.
>
>In my view, the real question here is what is the distinguishing 
>characteristic(s) and processes by which an "Internet name" is 
>categorized as a "DNS name" (which, at least at the top level, 
>presumably falls under ICANN community-defined policies) and those fall 
>under a different categorization.
>
>Regards,
>-drc

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 07 Apr 2016 10:10:37 +0200

On 7 Apr 2016, at 3:44, Adrien de Croy wrote:

> It's one thing to reserve a TLD.  It's another thing to actually use it for something non-DNS.

What about .local?

   paf

---

From: Philip Homburg <[email-masked]>
Date: Thu, 07 Apr 2016 12:57:32 +0200

>This appears to assume that naming systems are only developed in the 
>IETF or that a naming system not developed in the IETF is not 
>relevant/impactful.
>

To be more specific. In my opinion, the IETF should not reserve any names for
for naming systems developed outside the IETF. 

Obviously, anybody is completely free to develop a naming system outside the
IETF. And obviously any operating system can implement a name switch function
that decides what names should be resolved by which naming system.

However, having lived through a period where many different naming systems where
use in parallel and seeing what benefits it brought to have to consider just DNS,
I think a model where IETF and ICANN actively control the consistency of the
internet name space is best.

And with actively control I mean that any changes get planned and then designed.
And obviously this planning and designing should happen within the IETF when it
comes to new protocols.

I have created naming systems myself. And there are many reasons to dislike
DNS and do something different.

But ultimately, for the stability of the internet, it is best to not do that.
Write some experimental code, write a few papers and be done with it. Then,
if you still care about the problem, work within the IETF to improve DNS.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 08:26:55 -0300

On Thu, Apr 07, 2016 at 01:44:44AM +0000,
 Adrien de Croy <[email-masked]> wrote 

> behaving as we intend with 6761, since I can do a resolution of
> these names with DNS, and connect to the servers with HTTP.

You should read RFC 6761. Its section 6.5 is clear: "Name resolution
APIs and libraries SHOULD NOT recognize example names as special and
SHOULD NOT treat them differently.  Name resolution APIs SHOULD send
queries for example names to their configured caching DNS
server(s). Caching DNS servers SHOULD NOT recognize example names as
special and SHOULD resolve them normally."

So, they behave exactly as mandated.

That's, by the way, why section 2 of draft-bortzmeyer-dname-root-00 is
written as it is ("if and only if", so excluding .example).

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Apr 2016 08:40:51 -0300

Hi,

After a number of private discussions here in Buenos Aires I feel the need to clarify something:

In keeping with the way I understood the IETF to work, no one who works at ICANN who has responded on this topic is speaking on behalf of ICANN (including me). Like everyone else at the IETF, ICANN staff participate as individuals. If ICANN (the company or the community) wants to make a statement, I believe there is a liaison from the IETF to ICANN through which that statement would go.

As far as I know, ICANN (either the company or the community) does not have an opinion on RFC 6761 or the issues relating to special use names (not just TLDs) it creates. Traditionally, ICANN, as the IANA Function Operator, has been more than happy to rely on external entities to define lists, e.g., ISO-3166/MA who defines the ISO-3166 2 letter codes. If the IETF wishes to define a list of names that are not to be used in the DNS for (presumably) technical reasons (in keeping with RFC 2860 section 4.3(a) or (c)), I am fairly certain the ICANN community (not ICANN the company -- staff simply implements the policies defined by the community) will create a clause in the next Applicant's Guide Book that says "you can't request a name on this list defined by the IETF; if you have a problem with that, take it up with them."

Of course, I personally believe that it would simply be crazy for the IETF to drive into that particular swamp yelling "me too!"[0] and take on the legal responsibilities and liabilities associated with maintaining such an exclusion list (the Applicant's Guide Book is 300+ pages for a reason). Based on past experiences, I suspect saying "but it is only used in a particular context" is unlikely to dissuade too many folks with more lawyers and money than brains who want "their" TLD, but perhaps I'm wrong.

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

[0] with apologies to Dave Clark

> On Apr 5, 2016, at 4:35 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 09:13:46 -0300

On Wed, Apr 06, 2016 at 09:51:03PM -0300,
 David Conrad <[email-masked]> wrote 
 a message of 58 lines which said:

> > Some people complained that it was difficult enough with RFC 6761
> > (because there is no machine-readable version of the special-use
> > registry)
> 
> Last I looked
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xml
> was XML and it's machine-readable.

No. Of course, its structure is machine-readable, but not the
contents, specially the rules about how DNS software should handle
this name. If you write a resolver and want to fully support RFC 6761,
you cannot write a script which will produce code (or configuration)
supporting the special rules, from the downloaded IANA registry. The
only solution is to read every RFC pointed by the registry, and then
update your code (or the default configuration).

It is funny that draft-adpkja-dnsop-special-names-problem spends a lot
of time in political rants and seldom mentions this very practical
limit of RFC 6761.

Addressing it (6761-bis?) won't be easy because it means developing a
limited set of possible policies for special-use names.

> Put special use registry be put into the DNS, e.g.,

No, same problem.

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Apr 2016 09:38:26 -0300

Philip,

> internet name space is best.

I do not believe IETF or ICANN have that level of control. The Internet is known for "permissionless innovation" for a reason.

> DNS and do something different.

Right.

> if you still care about the problem, work within the IETF to improve DNS.

I believe the point of the special use registry is that these are protocols that are not DNS and have no interest in being in the DNS, but which make use of domain name conventions.  The alternative to the special use registry is not that such names won't exist, rather it is that the names will collide with names in the DNS.

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 09:35:32 -0300

On Wed, Apr 06, 2016 at 08:48:19PM +0000,
 Adrien de Croy <[email-masked]> wrote 
 a message of 73 lines which said:

> so therefore the DNS namespace has to be perverted.

>From the discussion at the IETF plenary yesterday evening, I got the
feeling that IETF 100 in Singapore will be clean of perversions :-)

> And when I see arguments like the IETF should assign root names so
> that organisations who can't afford lawyers

Such organisations should not be allowed to exist, I agree.

> I think the security implications of a resolver checking some
> internet source for a machine readable list of the latest special
> use names have not even been considered,

There is today, unfortunately, no such list. Should it exist in
6761-bis, I'm fairly certain the authors would add in the Security
Considerations section that the list must be authenticated (for
instance HTTPS to IANA with a thorough certificate check). It is not
different than the retrieval of the DNS root key.

---

From: Alain Durand <[email-masked]>
Date: Thu, 7 Apr 2016 13:20:26 +0000

>of time in political rants and seldom mentions this very practical

That was mentioned in the -00 version. The point was brought up in
Yokohama, but there was little discussion about it.
It somehow got lost when we shuffled things around to create the -01 and
-02.

Alain.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 11:57:13 -0300

On Thu, Apr 07, 2016 at 09:35:32AM -0300,
 Stephane Bortzmeyer <[email-masked]> wrote 

> feeling that IETF 100 in Singapore will be clean of perversions :-)

I've been told it was a bad joke, and it could be interpreted as
anti-LGBT people. Since it was *not* the intended goal, I withdraw it,
sorry.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 12:06:43 -0300

On Wed, Apr 06, 2016 at 08:42:06PM +0000,
 Adrien de Croy <[email-masked]> wrote 
 a message of 42 lines which said:

> Why do DNS programmers need to care about these "special" names in
> the normal domain name space?

They do not _need_, RFC 6761 is full of SHOULD, the MUST are only for
the DNS registries (typically the root).

> namespace should be polluted for non-DNS resolution.

I think draft-lewis-domain-names addresses your remark (it is the
domain name space, not the DNS name space).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 12:17:22 -0300

On Thu, Apr 07, 2016 at 08:40:51AM -0300,
 David Conrad <[email-masked]> wrote 
 a message of 72 lines which said:

> I am fairly certain the ICANN community (not ICANN the company --
> staff simply implements the policies defined by the community) will
> create a clause in the next Applicant's Guide Book that says "you
> can't request a name on this list defined by the IETF; if you have a
> problem with that, take it up with them."

Thanks for your message, I think it is very clear.

> If ICANN (the company or the community) wants to make a statement, I
> believe there is a liaison from the IETF to ICANN through which that
> statement would go.

Since we have this liaison, does anyone know if it was used to inform
ICANN of this discussion (it seems the right thing to do) and to ask
them if they wanted to comment?
draft-adpkja-dnsop-special-names-problem is full of FUD about how
ICANN could be pissed off by a decision of the IETF to add .something
to the Special-Use registry, but did we actually *asked* ICANN about
it?

<https://datatracker.ietf.org/liaison/posted/?text=icann&source=&destination=&start_date=&end_date=>
seems to indicate the liaison with ICANN does not use a lot of bandwidth...

---

From: Alain Durand <[email-masked]>
Date: Thu, 7 Apr 2016 16:22:37 +0000

> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> ICANN could be pissed off by a decision of the IETF to add 

Stephane,

That is certainly your right to read it that way, but it is not what the authors are saying, or at least not what they intended to say.
What draft-adpkja-dnsop-special-names-problem is doing is explaining that all names are subject to socio-economic pressures,
and ICANN has had to develop a complex process to evaluate those pressures and deal with them. That process may not be perfect, but it exists. 
ETF has no such process in place.

Alain, speaking only for myself.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 07 Apr 2016 14:31:39 -0300

> to the Special-Use registry, but did we actually *asked* ICANN about

This statement seems like FUD to me. Can you point to which paragraphs 
in the document that gives you that feeling? I ask this because, as much 
as I dislike some of the words and organization of the draft, I cannot 
map what you say to anything in the draft (so that I could suggest an 
edit).

--Paul Hoffman

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 Apr 2016 14:34:49 -0300

>> to the Special-Use registry, but did we actually *asked* ICANN about

https://gnso.icann.org/mailing-lists/archives/council/msg16659.html

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 7 Apr 2016 13:39:42 -0400

(Will be answering a bunch of things, in no particular order)

> them if they wanted to comment?

https://datatracker.ietf.org/liaison/1351/ <https://datatracker.ietf.org/liaison/1351/>

(DNSOP co-chairs, AD, and IAB collaborated on this, as the IAB has oversight of liaisons for the IETF.)

Suzanne

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 7 Apr 2016 13:43:26 -0400

Hi,

I’d like it very much if we could park “some people feel institutional arrangements may be ill-suited or ambiguous” as “stipulated as an area to consider in evaluating possible solutions."

I have pushed so hard for so long to have a problem statement, even though that’s not always either necessary or sufficient for progress, because it’s so easy for a discussion of this issue to conflate institutional and other “layer 9” issues with the kinds of architectural and operational questions it seems to me that we should be focused on.

Suzanne

> On Apr 7, 2016, at 1:31 PM, Paul Hoffman <[email-masked]> wrote:
> 
> This statement seems like FUD to me. Can you point to which paragraphs in the document that gives you that feeling? I ask this because, as much as I dislike some of the words and organization of the draft, I cannot map what you say to anything in the draft (so that I could suggest an edit).
> 
> --Paul Hoffman
>

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 7 Apr 2016 13:49:46 -0400

> On Apr 7, 2016, at 12:22 PM, Alain Durand <[email-masked]> wrote:
> 
> 
>> On Apr 7, 2016, at 11:17 AM, Stephane Bortzmeyer <[email-masked] <mailto:[email-masked]>> wrote:
>> 

It is a matter of scope, to say nothing of opinion, that “all names are subject to socio-economic pressures.” There are a great many identifiers in use on the internet, and it’s hard to even evaluate this claim without some discussion of context. (We spent much of the ARCING BOF on pretty much this point.)

Given that discussion of “special use names” is even more likely than most to suffer from assumptions about context, a more precise formulation of this claim would probably be helpful.

Suzanne

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Apr 2016 15:25:18 -0300

Suzanne,

On Apr 7, 2016, at 2:39 PM, Suzanne Woolf <[email-masked]> wrote:
> https://datatracker.ietf.org/liaison/1351/
> 

Out of curiosity, since that liaison statement was made about 18 months after RFC 6761 was published and about a 10 months after draft-grothoff-iesg-special-use-p2p-names was submitted, was there any previous liaison communication to ICANN prior to that statement related to RFC 6761?

Thanks,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Apr 2016 16:05:31 -0300

Suzanne,

On Apr 7, 2016, at 2:49 PM, Suzanne Woolf <[email-masked]> wrote:
> It is a matter of scope, to say nothing of opinion, that “all names are subject to socio-economic pressures.”
> [...]

The way I see it, "Internet names" (that is, domain names whether they are used in the DNS or not) are typically used to identify hosts, end points, or services on the Internet. People tend to get wound up with their identity and how that identity is made available on the Internet (or overlays on top of the Internet). That being wound up often result in socio-economic pressures, e.g., being bought/sold, triggering lawsuits over ownership/existence, etc.  Do some of those identities not get tied up in those socio-economic pressures?  Sure, the vast majority.  However, I'm not sure I can see how all identities are not subject to socio-economic pressures.

Regards,
-drc

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 Apr 2016 16:08:43 -0300

> Out of curiosity, since that liaison statement was made about 18 months after RFC 6761 was published and about a 10 months after draft-grothoff-iesg-special-use-p2p-names was submitted, was there a…

Afaik there's only one liason statement to icann since the inception of
liason statement tracking; the basis of inter-organiation collaboration
is imho largely the RFC series.

> DNSOP mailing lis

---

From: George Michaelson <[email-masked]>
Date: Thu, 7 Apr 2016 16:19:01 -0300

I wouldn't normally invoke 'the nuclear option'  but the parallels
with good science/bad politics are stark here. Norbert Weiner left the
field and moved into biology and cybernetics because he realized his
personal ethics were totally adrift in the sea of consequence of work
on nuclear physics. I think Condon or somebody said after the trinity
test, he lived on sleeping pills forever. I don't want to be in that
space. (its in richard rhodes' book. i forget where)

Ignoring the social consequences of entirely logical technologically
driven decisions is not just silly, its actually dangerous. This is
what RFC6761 does. It ignores consequence in the world of names as
social constructs.

We're not the gods of the internet. The social consequences of build
outs has to be understood to exist. ICANN is the forum where social
constructs meet, and discuss names. technically motivated internet
names have a social context. It has to be discussed properly by the
people who understand it.

I know John Perry Barlow's statement of independence is very popular,
but I live in the real world. Aspirations are not concurrent with
reality, and I prefer desire and reality to align. I believe Barlow
has more recently said he understands aspiration to be different to
reality, so maybe we're all of one mind here.

The best possible alignment right now of desire and reality, is for
ICANN to be the forum which adjudicates what labels exist or are
special in the top levels of worldwide socially visible naming. The
IETF should be seen to ask them, based on sound technical reasons, to
consider names. Not telling, asking.

This is what I believe. This is what motivates me to discuss this
problem: Lets not pretend we can drive this on technology alone. We
can't.

-G

---

From: joel jaeggli <[email-masked]>
Date: Thu, 7 Apr 2016 16:27:23 -0300

> people who understand it.

Oddly enough I agree. to quote the liason statement:

...
Discussion of these requests under the process established in RFC 6761
has revealed difficulties in applying its guidelines in practice.
Under its current charter, the DNSOP working group in the IETF is
responsible to review and clarify the overlap between (among other
things) the special names registry from RFC 6761 and the public DNS
root. This could include consideration of the problem of existing name
collisions, provision of additional guidelines, or further
modification to the process in RFC 6761 to reduce the potential for
collisions in the future. Any changes are to be kept within the
constraints of RFC 2860 (or any future modification to RFC 2860).

All such discussion and any modification will be open and transparent
to participation by interested parties, in accordance with established
IETF processes. We invite participation of interested parties,
including members of the ICANN community, in this work.
...

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 7 Apr 2016 16:15:36 -0400

> On Apr 7, 2016, at 3:05 PM, David Conrad <[email-masked]> wrote:
> 
> Suzanne,
> 

To be clear— I wouldn’t argue that “all identities *are not* subject to socio-economic pressures” any more than I’d argue that “all identities *are* subject to socio-economic pressures”.

I note, for instance, that we spent over two hours in the ARCING BOF on Tuesday morning, discussing assorted ramifications of the fact that identifiers have contexts. It seems somewhat relevant, and motivated my request for a more precise formulation of the initial claim of what’s included in “all names”.

Suzanne

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 20:25:27 +0000

Hi Stephane

don't worry, I didn't take it that way.  For me, the concept of 
perversion and LGBT are entirely independent, and I think people who 
associate the 2 concepts need to look at their own prejudices.

Regards

Adrien de Croy

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Philip Homburg" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 8/04/2016 2:57:13 a.m.
Subject: Re: Alternative Special-Use TLD problem statement draft

---

From: Warren Kumari <[email-masked]>
Date: Thu, 07 Apr 2016 20:27:03 +0000

> including members of the ICANN community, in this work.

Yup.
A number of IETF DNS WG participants *also* happen to participate in the
ICANN SSAC.

Some of use were concerned that the ICANN community might feel blindsided
or that there could be conflict ("What do you mean IETF makes reservations
that impact my ability to apply for a TLD?! Why didn't anyone tell me?!")

We published: https://www.icann.org/en/system/files/files/sac-078-en.pdf,
(and SSAC documents are widely read in the ICANN world.).

There was (largely) a collective shrug. I (personally) may have been more
concerned about the likelihood of conflict between ICANN and the IETF over
this.

W

> >>> Out of curiosity, since that liaison statement was made about 18
> months after RFC 6761 was published and about a 10 months after
> draft-grothoff-iesg-special-use-p2p-names was submitted, was there any
> previous liaison communication to ICANN prior to that statement related to
> RFC 6761?
> >>

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 20:34:45 +0000

------ Original Message ------
From: "David Conrad" <[email-masked]>
To: "Philip Homburg" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 8/04/2016 12:38:26 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>I do not believe IETF or ICANN have that level of control. The Internet 
>is known for "permissionless innovation" for a reason.
>
>I believe the point of the special use registry is that these are 
>protocols that are not DNS and have no interest in being in the DNS, 
>but which make use of domain name conventions.  The alternative to the 
>special use registry is not that such names won't exist, rather it is 
>that the names will collide with names in the DNS.
>
>
>

the question is whether we should fundamentally change the domain name 
system to accommodate this or not.  My position is we should not.

Just because TOR asks for .onion doesn't mean it should be given it.

I understand the IETF is supposed to obtain consensus, but I didn't see 
anything in http WG on this until after the fact.  Special use names has 
wide-ranging repercussions.

If an author of a product chooses to devise a new non-dns resolution 
mechanism, and use names that are confusingly similar to domain names, 
and use names that may be issued by ICANN in the DNS, then I'm sorry but 
they need to look for an alternative technical solution.  Not make 
everyone else in the world change to suit them.

Regards

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 20:36:32 +0000

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Philip Homburg" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 8/04/2016 12:35:32 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>Such organisations should not be allowed to exist, I agree.
I didn't say or imply that - only that they should not be privileged 
compared with everyone else when it comes to getting names reserved in 
the domain name space.

>different than the retrieval of the DNS root key.
And maybe it will be the first protocol ever to not suffer from 
unexpected security consequences.

Adrien

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 7 Apr 2016 17:48:21 -0300

On Thu, Apr 07, 2016 at 04:15:36PM -0400,
 Suzanne Woolf <[email-masked]> wrote 
 a message of 32 lines which said:

> To be clear— I wouldn’t argue that “all identities *are not* subject
> to socio-economic pressures” any more than I’d argue that “all
> identities *are* subject to socio-economic pressures”.

As an example, see this registry
<https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml>
It has many names, some of them being trademarks, and nobody ever
complained. Because of context.

So, I think that the risk of Ser Davos (if you don't know, read George
Martin's novels "A Song of Ice and Fire") suing us for the
registration of .onion is limited.

And, yes, before somesones say so, I Am Not A Lawyer (but I'm
confident I could play one on TV).

---

From: "John Levine" <[email-masked]>
Date: 7 Apr 2016 21:26:51 -0000

>Just because TOR asks for .onion doesn't mean it should be given it.

The TOR project has been distributing software that special cases
the .onion TLD for close to a decade.

If the IETF said "you're wrong, go away", what exactly do you
think they would do?

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 21:50:01 +0000

------ Original Message ------
From: "John Levine" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 8/04/2016 9:26:51 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>If the IETF said "you're wrong, go away", what exactly do you
Who knows.

But just because they've been doing it for a long time doesn't mean it's 
a good thing to do.

And the IETF commonly tells people with bad ideas they should do 
something else.

And maybe then instead they would have gone away and come up with a 
solution that doesn't have this leakage problem.

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 21:54:44 +0000

.local is another excellent example of where we ignore the specs.

If we stopped sending lookups for .local names via DNS (not multicast 
DNS), a lot of things would break.

Regards

Adrien

------ Original Message ------
From: "Patrik Fältström" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "David Conrad" 
<[email-masked]>
Sent: 7/04/2016 8:10:37 p.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

---

From: David Conrad <[email-masked]>
Date: Thu, 7 Apr 2016 19:04:38 -0300

Stephane,

> complained. Because of context.

Yes they have.  On several occasions, back when I was running IANA (circa 2005-2008) -- I received the complaints. I believe I raised that issue to the IESG on a couple of occasions (or maybe not, don't recall exactly).  Maybe things have changed since then.

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Apr 2016 19:06:52 -0300

Sun's "Yellow Pages" would be a highly topical example...

On Thu, Apr 7, 2016 at 7:04 PM, David Conrad <[email-masked]> wrote:

> > <
> https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml
> >
> Yes they have.  On several occasions, back when I was running IANA (circa
> 2005-2008) -- I received the complaints. I believe I raised that issue to
> the IESG on a couple of occasions (or maybe not, don't recall exactly).
> Maybe things have changed since then.
>
> Regards,
> -drc

---

From: Warren Kumari <[email-masked]>
Date: Thu, 07 Apr 2016 22:24:30 +0000

On Thu, Apr 7, 2016 at 5:34 PM Adrien de Croy <[email-masked]> wrote:

> I do not believe IETF or ICANN have that level of control. The Internet is
> known for "permissionless innovation" for a reason.
>
>
> protocols that are not DNS and have no interest in being in the DNS, but
> which make use of domain name conventions.  The alternative to the special
> use registry is not that such names won't exist, rather it is that the
> names will collide with names in the DNS.
>
>
>
>
>
>
> mechanism, and use names that are confusingly similar to domain names, and
> use names that may be issued by ICANN in the DNS, then I'm sorry but they
> need to look for an alternative technical solution.
>

... or choose a different string(s) so that they are *not* confusingly
similar to the DNS. If someone designs a product which uses the suffix
string .c0m the response could be "That's a security (phishing) issue, how
abut you instead use <something else>?".
.onion A: was not a name which had been applied for nor existed in the DNS
and B: had a large installed base.

> Not make everyone else in the world change to suit them.
>

Yup. However (even though I have a badge which claims otherwise) we are not
the Internet police. Using a string to delineate "your" portion of a
namespace is not something that the IETF can prevent ( .onion launched a
sucessful resolution system without "us") - if we provide a process which
has some reasonable review, and is not ridiculously painful to follow, we
can maintain a registry of these. If the process is difficult / arcane /
etc we will simply have "squatters".

W

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 07 Apr 2016 23:13:37 +0000

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "Philip Homburg" <[email-masked]>; "[email-masked]" 
<[email-masked]>; "Ted Lemon" <[email-masked]>
Sent: 8/04/2016 3:06:43 a.m.
Subject: Re: [DNSOP] Alternative Special-Use TLD problem statement draft

>domain name space, not the DNS name space).
OK, I read draft-lewis-domain-names-02.txt

I guess in so far as it deals with this subject matter that is correct.

Even though it has a few issues (e.g. not really contemplating 
prohibited characters in domain tokens) the issue here is philosphical, 
and given that the stated intent in the draft is to provide a 
justification for allowing alternate resolution protocols into the 
domain name space, it's not really discussing that issue.

Most of the examples given of uses of alternate interpretations of 
domain names, in my experience do not do that (e.g. DHCP, FTP, X.509, 
SSH).  As far as I can tell only MDNS and TOR are where the real 
divergence lies, and it's really only TOR that fundamentally departs 
from DNS design.  MDNS retains the hierarchical nature, the token limits 
etc.  All that is changed is the character set (I'm glad punycode was 
abandoned).

The evaluation of the historical origins of domain names could be argued 
another way, rather than used as an argument to diverge from the point 
we converged on with 1035, we could argue that this convergence was the 
enabler for the DNS to become what it is, and we should discard that (no 
matter its warts) at our peril.

Given that there are so many illegal characters in domain tokens, 
another option would have been to use a final token that contains 
illegal characters.

e.g. if the TOR authors wanted to ensure their names would fail in a DNS 
resolver, they could have used any number of illegal characters in the 
final token.  E.g. .[onion] instead of .onion

And maybe this could be the approach for a new root node name under 
which special use names could live.

e.g.

.[]
.()
.$

Or something.  I'm sure some of these would cause parsing problems in 
some protocols, but I'm sure something could be found.

Although it might look like it, I'm not against novel resolution 
mechanisms per se.  What I have a problem with is creating a requirement 
to deploy new DNS resolvers to all the billions of existing deployments. 
  Because that's simply impossible.

Backward compatibility needs its priority elevated IMO.

Adrien

---

From: "John R Levine" <[email-masked]>
Date: 8 Apr 2016 01:43:59 -0300

>> If the IETF said "you're wrong, go away", what exactly do you

Here's a hint: They will keep using it, no matter what we say.

We're the Internet Engineering Task Force, not the Internet Religious Task 
Force.  Our job is to make things work as well as possible in the real 
world.  Sometimes that means dealing with situations where the facts are 
not the ones we would prefer.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 08 Apr 2016 13:50:01 +0200

>If the IETF said "you're wrong, go away", what exactly do you

They would have been in serious trouble.

The problem with the special use registry is that it comes from a line of
thinking that as long as you properly partition the name space, all is fine.

I.e., names have no other properties than that they are either resolved in 
DNS or not.

For the tor project, onion names leaking into DNS is a problem. But is not
clear if and when the current RFC will have any operational impact. It is more a
would be nice if DNS resolvers would filter onion.

There was no real risk that somebody would start using .onion or even that tor
users would be affect by such use.

There was however a really big issue, CA were going to refuse DV certificates
for .onion because officially it did not exist.

Read for example, https://www.ietf.org/blog/2015/09/onion/

So the IETF, saying no we don't want this would have had an impact on this.

The IETF giving a stamp of approval on either a protocol or a name can have a
lot of impact because other (standards) organizations recognize the IETF as the
authority on this.

Adrien de Croy wrote:
"I understand the IETF is supposed to obtain consensus, but I didn't
"see anything in http WG on this until after the fact.  Special use
"names has wide-ranging repercussions.

This is in line with the concept that the special use register is only about
reserving the name. How this impact users of the name space is essentially
not considered. See the rather poor treatment in RFC 7686.

To use the words 'protocol police'. Yes, the IETF is the protocol police. That's
its role in the internet. We can still refer to our documents as 'requests
for comments'. The outside world sees them as the official seal of approval
of the Internet's standards organization.

And in this sense, the IETF should only say yes to a naming protocol if 
it makes sense in the overall architecture of internet related software.
Explictly considering the rather complex interaction between naming and
security in many applications (such as web browsers).

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 8 Apr 2016 17:40:09 -0400

Adrien,

On Thu, Apr 7, 2016 at 7:13 PM, Adrien de Croy <[email-masked]> wrote:
> Even though it has a few issues (e.g. not really contemplating prohibited
> characters in domain tokens) the issue here is philosphical, and given that
> the stated intent in the draft is to provide a justification for allowing
> alternate resolution protocols into the domain name space, it's not really
> discussing that issue.
>
> Most of the examples given of uses of alternate interpretations of domain
> names, in my experience do not do that (e.g. DHCP, FTP, X.509, SSH).  As far
> as I can tell only MDNS and TOR are where the real divergence lies, and it's
> really only TOR that fundamentally departs from DNS design.  MDNS retains
> the hierarchical nature, the token limits etc.  All that is changed is the
> character set (I'm glad punycode was abandoned).
>
> another way, rather than used as an argument to diverge from the point we
> converged on with 1035, we could argue that this convergence was the enabler
> for the DNS to become what it is, and we should discard that (no matter its
> warts) at our peril.
>
> Given that there are so many illegal characters in domain tokens, another
> option would have been to use a final token that contains illegal
> characters.

There are no illegal characters for DNS labels. DNS is a binary clean
protocol. All possible 8-bit bytes are permitted in labels and there
is an easy way to write even kludgy ones like the zero valued byte in
Master Files. See RFC 4343 for example.

> resolver, they could have used any number of illegal characters in the final
> token.  E.g. .[onion] instead of .onion

I would avoid square brackets. To the extent they are supposed to do
anything, they are supposed to indicate that the stuff between the
square brackets is an IP address, as in [8.8.8.8], although admittedly
the IETF has been less than successful in getting this syntactic
distinction to stick.

> And maybe this could be the approach for a new root node name under which
> special use names could live.
>
> e.g.
> .[]
> .()
> .$

I don't see any sense in which these are new roots. They look like OK
two or in the last case one byte TLDs in the DNS to me although you
certainly might have to escape the characters in some interfaces. If
you want to be obscure, how about

.\0  or
.\255

instead of .alt...

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Or something.  I'm sure some of these would cause parsing problems in some
> protocols, but I'm sure something could be found.
>
> Although it might look like it, I'm not against novel resolution mechanisms
> per se.  What I have a problem with is creating a requirement to deploy new
> DNS resolvers to all the billions of existing deployments.  Because that's
> simply impossible.
>