Subject: Re: Last Call: <draft-ietf-dnsop-onion-tld-00.txt> (The .onion Special-Use Domain Name) to Proposed Standard

From: John C Klensin <[email-masked]>
Date: Mon, 20 Jul 2015 13:15:11 -0400

--On Monday, July 20, 2015 4:14 PM +0200 Andrew Sullivan
<[email-masked]> wrote:

> Hi,
> 
> On Wed, Jul 15, 2015 at 09:56:27AM -0700, Ted Hardie wrote:
> 
>> From an architectural perspective (but still wearing my hat
>> as an individual), this method for partitioning the namespace
>> has a very poor long-term characteristics.
>...
> On Wed, Jul 15, 2015 at 03:13:35PM -0400, John C Klensin wrote:
> 
>> mechanisms be allocated (and placeholders delegated if needed)
>> in a separate DNS CLASS, say "SN" for "Special Name".  Zero
>> impact on the ICANN/IANA root from queries gone bad, no
>> conflict with names ICANN allocates even if the labels are
>...

> We have some features in the DNS that are also duplicated as
> work-arounds that are widely deployed.  The obvious example is
> RRTYPEs.  In lots of cases, rather than using a nice
> special-purpose type designed to carry the kind of data a
> conforming application wants, people have created one or more
> "underscore labels" and put structured RDATA in a TXT record.
> This is a kind of in-band signalling that is ugly, but which
> worked around the deplpoyability issues with new RRTYPEs.
> 
> It seems to me that local and onion are another example of
> this, only either for classes, or else for resolution protocol
> switching (I suspect these two boil down to the same thing).
> Basically, local was a way of communicating, "Don't query me
> in the IANA DNS root name space."  Since classes mostly didn't
> work anywhere, rather than starting a new class to do this,
> mDNS and now Tor use the end-most non-null label to signal,
> "Don't look this up in the IANA root."
> 
> But it seems to me that the fact people are inventing ways to
> do the things the protocol already offers, and doing violence
> to the overall system at the same time, suggests that we're
> doing something fundamentally wrong with DNS.  I wish I had a
> clue what to do about this, because I think there's faint hope
> that we're going to be able to prevent these continued
> innovations: RRTYPEs are not a great deal easier to deploy
> (though they're easy in nameservers themselves), and CLASSes
> still don't really work[1].  I don't know whether what this
> shows is that we just have to put up with the mess that all of
> this is making, or whether what it's really telling us is that
> DNS's seams are finally bursting from all the stuff we have
> tried to stick in there (cf.
> http://www.cafepress.com/nxdomain/8592477 Note: possibly
> offensive term).

Andrew,

I agree with your analysis, modulo one question.  You make the
comment that CLASSes don't really work, as have others.  I'd
like to understand it better.  We've had some experience in
which they have worked to support namespaces that are not really
part of the global/public Internet. Yes, using them at scale
would require we think about roots , root location, and root
management, etc., in new contexts. QCLASS=ANY is conceptually
impossible, but the fishing expedition it implies should never
actually be needed. I would not be surprised if you told me that
CLASS has been botched in some implementations and there has
been no incentive to fix it, that shouldn't surprise me at all.
However, if there were an important application, I assume those
implementations could be fixed.  So what do you see as the
issue?   Is it that we have needs to intermix ordinary public
names with "don't try to resolve this there" stuff in the same
environments?  I agree that would be a problem for CLASS, but
note some very strong analogies with the IDNA kludge.

I am, However, getting increasingly concerned with another
aspect of the problem.  It may be worth sharing that concern.
While I think it is entirely reasonable for the IETF to write
rules about categories of DNS labels or restrictions on them
("don't use "xn--... for anything but IDNA" or "labels with
leading underscore are reserved for protocol and service
location use" are reasonable examples), our being in the
business of allocating (or blocking) labels one at a time
impresses me as a bad idea, inviting both misunderstandings and
getting the IETF dragged into the sorts of ICANN policy debates
that few people in our community really enjoy and fewer seem
equipped to really understand and engage with.

Rather than engaging in a drama that looks from a distance like
"ICANN asserts that they are in charges of everything, including
the IETF" and "IETF asserts they can grab whatever names they
want, whenever they like". why can't we take the Special Names
problem to them, say "look, we understand that these names look
like names in the public DNS root and that confusion that would
have bad effects is a real risk, how about you devise a
procedure for dealing with them that recognizes the importance
of existing deployment and use and considers the low likelihood
that people who are using these names will stop because you tell
them too.  Clearly the procedure you use for new gTLD
applications won't work.  And, because some of these names won't
wait, if you can't get that procedure together immediately, we'd
be willing to let you delegate things to us on some reasonable
basis until you do."

It seems to me something like that, rather than continual
testing of boundaries, is how two peer organizations led by
adults treat each other.  It also allows us to take the position
that we are ICANN's customers for the IANA function but are
otherwise an independent entity that can work with them when
that is in the best interests of both of us and of the Internet,
but that is not, in any respect, responsible for them or their
operational or governance models.

best,
    john

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Jul 2015 13:57:53 -0400

On Jul 20, 2015, at 1:15 PM, John C Klensin <[email-masked]> wrote:
> like to understand it better. 

To understand why classes don’t work, can you tell me what a URL for a name in a non-IN class would look like?

---

From: John C Klensin <[email-masked]>
Date: Mon, 20 Jul 2015 14:20:34 -0400

--On Monday, July 20, 2015 1:57 PM -0400 Ted Lemon
<[email-masked]> wrote:

> To understand why classes don't work, can you tell me what a
> URL for a name in a non-IN class would look like?

Depends on your perspective.  If we had used CLASSes for IDNs (a
bad idea for other reasons, but seemingly interesting at the
time), the answer would have been "detect non-ASCII characters
in the domain".   More generally and with the understanding that
it doesn't actually help us make progress, it would be plausible
to answer your question above with "CLASSes work fine, it is
URLs that are broken and don't work".  Seriously.   One would
need some lexical mechanism to determine whether an apparent
domain in a URL  is to be resolved in CLASS=IN or some other
CLASS.  That is no such mechanism. but, while the makes CLASSes
hard to deploy, the fault lies with the RUL/ URI system and its
having become some complex and rigid that it is difficult or
impossible to extend and adapt to previously-unidentified
requirements.
 
   john

---

From: "John Levine" <[email-masked]>
Date: 20 Jul 2015 19:22:19 -0000

Now that you and Andrew have pointed it out, and after today's dnsop
session, I agree that the trickle of not-DNS domain names is likely
only to become larger, and we need a better way to deal with it than a
two-month all-IETF debate per name.

> why can't we take the Special Names

That is an excellent question, and I suppose it couldn't hurt to ask.
But I have little confidence that ICANN in anything like its current
form, where it is dominated by people who want to collect rent on
every imaginable TLD, would come up with an answer any better than let
them pay $185K and take their chances.

As a second level issue, we might want to consider whether it's
worth standardizing DNS escapes which are now typically done by
a hacked version of a SOCKS server or DNS resolver.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Jul 2015 19:44:25 -0400

On Jul 20, 2015, at 2:20 PM, John C Klensin <[email-masked]> wrote:
> More generally and with the understanding that
> URLs that are broken and don't work".

OK, let’s run with that for a bit.   Suppose we change URLs.   What about hostnames for ssh?   What about for ftp?   What about for every other place where hostnames are used?

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2015 01:33:18 -0000

>OK, let’s run with that for a bit.   Suppose we change URLs.   What about hostnames for ssh?   What about for ftp?  
>What about for every other place where hostnames are used?

I think we agree that changing the syntax of every application that
uses domain names won't work.  So that means we pick some set of names
currently unused in the DNS and carve it out to mean that a name gets
handled specially.

We already have a draft for that.  See draft-wkumari-dnsop-alt-tld-06.

R's,
John

---

From: George Michaelson <[email-masked]>
Date: Tue, 21 Jul 2015 07:36:13 +0200

SOCKS works with a shim. there is no .SOCKS domain to make SOCKS work.

shims work.

url tor://{http://.....} would work as a nesting function

ssh tor://{user@host ssh part} might work

so you have shim, and you have wrap.

wrap is every app changes. shim is no app changes.

notice neither of them needed DNS tricks.

On Tue, Jul 21, 2015 at 1:44 AM, Ted Lemon <[email-masked]> wrote:

> OK, let’s run with that for a bit.   Suppose we change URLs.   What about
> hostnames for ssh?   What about for ftp?   What about for every other place
> where hostnames are used?
>
>

---

From: Geoff Huston <[email-masked]>
Date: Tue, 21 Jul 2015 08:37:30 +0200

> operational or governance models.

Having been around at the time when the IETF was first engaged in
"policy debates that few people in our community really enjoy and fewer seem
equipped to really understand and engage with.” and actively played in that space
at the time, I find the reversion of putting the IETF back into the frame
for a repeat play an amazing poor move on the part of all concerned.

FWIW I strongly object to this draft moving forward to a proposed standard.

Furthermore, I appreciate and support John’s analysis and suggested
approach here.

  Geoff

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jul 2015 09:20:07 +0200

Hi,

On 7/20/15 9:22 PM, John Levine wrote:

> [John Klensin's question about taking all of this back to ICANN] is an excellent question, and I suppose it couldn't hurt to ask.

That's exactly it.  Some mechanism is needed to address pragmatics of a
situation, something that the IETF has a pretty good (albeit not
perfect) record on addressing.  That mechanism could sit at ICANN, the
IETF, or even both organizations.  No matter what one's opinion of Tor
is, the fact is that it's out there and in use.  They don't intend that
the DNS be used, and yet there is clearly an interaction between the two
namespaces at the CA level.  It's possible that the CA people could have
created a new usage constraint, but history shows that the extension
isn't well accepted, and that could actually hinder secure deployment.

And so to those who think ICANN should reserving names, one reasonable
question would be “why haven't they done so?”  Perhaps the answer is
that they have sufficient confidence in the approach that we are
following that they don't feel the need to do anything else.

Someone noted that having a lengthy argument on the IETF list about this
a bad thing.  If we had to repeat the principles argument without any
new information or ideas, I would tend to agree.  But otherwise this
discussion has served as a healthy self-limiting function over the
growth of 6761 reservations; which is exactly what should happen, and
perhaps the reason why folks at ICANN should be very confident in the
IETF's decision process in this regard.

And it call comes down to pragmatics, which, John, you highlighted in
your first comment about All of This.  That's why I support the draft
going forward.

Eliot

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Jul 2015 03:46:31 -0400

Eliot,

> On Jul 21, 2015, at 3:20 AM, Eliot Lear <[email-masked]> wrote:
> 

FWIW— DNSOP has discussed these issues at some length, and to the extent that an answer to the interesting questions here lie within what the WG can do, we’re forming a design team to examine them and consider the possibility the community needs to work on a revision to RFC 6761.

For some of the questions pulled from discussion on .onion (WG and IETF LC) and other internet-drafts proposing special-use names registry additions, see the slides as included in the meeting materials, https://www.ietf.org/proceedings/93/slides/slides-93-dnsop-7.pdf <https://www.ietf.org/proceedings/93/slides/slides-93-dnsop-7.pdf>.

best,
Suzanne

---

From: George Michaelson <[email-masked]>
Date: Tue, 21 Jul 2015 10:25:58 +0200

you can take the discussion here as indicating some loud voices for "RFC
6761 was a mistake" so the -BIS document should consider one option being
to say "we made a mistake: we don't do this"

-G

On Tue, Jul 21, 2015 at 9:46 AM, Suzanne Woolf <[email-masked]>
wrote:

> FWIW— DNSOP has discussed these issues at some length, and to the extent
> that an answer to the interesting questions here lie within what the WG can
> do, we’re forming a design team to examine them and consider the
> possibility the community needs to work on a revision to RFC 6761.
>
> For some of the questions pulled from discussion on .onion (WG and IETF
> LC) and other internet-drafts proposing special-use names registry
> additions, see the slides as included in the meeting materials,
> https://www.ietf.org/proceedings/93/slides/slides-93-dnsop-7.pdf.
>
>
> best,
> Suzanne
>
>

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jul 2015 10:49:47 +0200

On 7/21/15 10:25 AM, George Michaelson wrote:
> you can take the discussion here as indicating some loud voices for
> "RFC 6761 was a mistake" so the -BIS document should consider one
> option being to say "we made a mistake: we don't do this"

Just don't consider me one of those voices.  We can always do better,
but it's not like we're piling on the names in that registry.

Eliot

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 21 Jul 2015 04:54:15 -0400

> On Jul 21, 2015, at 4:49 AM, Eliot Lear <[email-masked]> wrote:
> 
> 
> 
>> you can take the discussion here as indicating some loud voices for "RFC 6761 was a mistake" so the -BIS document should consider one option being to say "we made a mistake: we don't do this"
> 
> Just don't consider me one of those voices.  We can always do better, but it's not like we're piling on the names in that registry.

This may not be a particularly good assumption. We have five requests being actively pursued in the WG at the moment, and were told yesterday in so many words that there are more to come. 

The effort we’ve put into handling just one (.onion) is not going to scale well to even 10x, particularly if we want add some form of active coordination with another body’s processes.

Suzanne

---

From: Douglas Otis <[email-masked]>
Date: Tue, 21 Jul 2015 10:56:00 +0200

> your first comment about All of This.  That's why I support the draft

Dear Eliot,

Not all names resolve with DNS. For example, mDNS
automatically adds '.local' (RFC6761) to service names to
imply mDNS resolution. '.onion' informally implies Tor
although mentioned in RFC4303. To support home environments--
https://tools.ietf.org/html/draft-ietf-dnssd-hybrid-00
introduces the '.home' TLD.  Great for those handy with ASCII.

'.home' however is likely derived from user input. IPv6 Home
Networking Architecture Principles (RFC7368) suggests
Ambiguous Local Qualified Domain Name (ALQDN) space and
gives an example of '.sitelocal'. This seems to imply use of
a trailing '.' is acceptable.  Lack of 'xn--' prefix with
non-ASCII UTF-8 (more than 7 bit) and the lack of  A-Label
collision could indicate a sitelocal TLD.  A-Label versions
might leak to DNS so local services should authenticate
clients in some manner (likely by a sitelocal IP address).
Special handling of 'xn--" prefixes could offer non-ASCII
users a friendly DNS escape mechanism and not require
exhaustive lists of IDNA special use equivalent versions.

Regards,
Douglas Otis

---

From: Eliot Lear <[email-masked]>
Date: Tue, 21 Jul 2015 10:57:28 +0200

Remember: the WG and the IETF can always say "no".  I recommend it early
and in less deployed circumstances.

Eliot

On 7/21/15 10:54 AM, Suzanne Woolf wrote:
>
>> On Jul 21, 2015, at 4:49 AM, Eliot Lear <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
> This may not be a particularly good assumption. We have five requests
> being actively pursued in the WG at the moment, and were told
> yesterday in so many words that there are more to come. 
>
> The effort we’ve put into handling just one (.onion) is not going to
> scale well to even 10x, particularly if we want add some form of
> active coordination with another body’s processes.
>
>
> Suzanne
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2015 07:09:26 -0400

> We already have a draft for that.  See draft-wkumari-dnsop-alt-tld-06.

What Warren’s draft does is orthogonal to what RFC 6761 does.   Were Warren’s draft to achieve consensus, that would provide an escape for some applications that might otherwise tend to go through the RFC 6761 process, but it would not address the onion use case, nor several other use cases, nor does it solve the general problem you and I are presently discussing.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2015 07:26:00 -0400

> SOCKS works with a shim. there is no .SOCKS domain to make SOCKS work.

This is a non-sequitur.   SOCKS is a tunnel for your network API.   Architecturally, it’s quite a poor choice for solving the problem we are discussing.   It’s used to solve that problem because it’s the easiest hack to make it work, not because it’s the right thing to do.

---

From: George Michaelson <[email-masked]>
Date: Tue, 21 Jul 2015 13:38:10 +0200

I don't believe its a non-sequitur because its architecturally addressing
some of the space of the problem and intrudes into the API without
requiring a name. The implication all activity in the path between
communicating entities require names to be used seems to me to be somewhat
moot. I used it as an example to discuss two specific methods of dealing
with the question of how different application spaces cope with these
situations. Shims and wraps are common.

The question(s) were posed 'how would ssh..' or 'how would ftp...' and I
replied, contextually how I feel other people have approached the problem.
What I took from their approach is: they found a way to do it without magic
labels in the DNS

I could have mentioned tun/tap too.

-G

On Tue, Jul 21, 2015 at 1:26 PM, Ted Lemon <[email-masked]> wrote:

> This is a non-sequitur.   SOCKS is a tunnel for your network API.
> Architecturally, it’s quite a poor choice for solving the problem we are
> discussing.   It’s used to solve that problem because it’s the easiest hack
> to make it work, not because it’s the right thing to do.
>
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Jul 2015 07:48:06 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted>    On Jul 21, 2015, at 1:36 AM, George Michaelson
    Ted> <[email-masked]>
    Ted>    wrote:

    Ted>    This is a non-sequitur.  SOCKS is a tunnel for your network
    Ted> API.  Architecturally, it€™s quite a poor choice for
    Ted> solving the problem we are discussing.  It€™s used to
    Ted> solve that problem because it€™s the easiest hack to
    Ted> make it work, not because it€™s the right thing to
    Ted> do.

However, efficiency of implementation is a concern it's reasonable for
the IETF to value and we typically value it highly.
Being able to implement things like TOR on top of sox shims, and being
able to implement hidden services on top of SOX shims is very valuable.
It allows us to add support for hidden services without modifying the
end applications.
Being able to do that is a requirement.

Using a mechanism like a URI, a separate DNS class, or something other
than a reserved name would make it much harder to meet this requirement.

having thought about this and a number of related issues, I strongly
support the basic idea of registering .onion as a special-use name.
I don't have particular stakes in the discussion about the  resolver or
application behavior sections of the draft.

--Sam

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Jul 2015 07:52:04 -0400

--On Tuesday, July 21, 2015 07:26 -0400 Ted Lemon
<[email-masked]> wrote:

>...
> It's used to solve that problem because it's the easiest
> hack to make it work, not because it's the right thing to do.

Ted, independent of SOCKS or other possibilities, I suggest one
of the things that can be said about apparent domain names that
are not expected to resolve in the DNS but are lexically
indistinguishable, overuse of TXT RRs, etc., is precisely "used
to solve that problem because it's the easiest hack to make it
work, not because it's the right thing to do.".   One difficulty
is that such hacks don't scale particularly well.  One or two of
them (I note that "localhost." is just about as old as the NDS)
is not a problem (although perhaps still a hack). Beginning to
add them in large numbers makes them harder to track, increases
the chance of leakage, and probably implies that we will
eventually need new hacks to categorize and organize the other
hacks.

It still might be the right thing to do (although I agree with
George, Andrew, and others that, if we are committed to good
design and engineering, we ought to be doing better).   My
concern is much more about how we (speaking very broadly)
organize the decision-making about particular names than about
the alternatives but, again, if the IETF is actually supposed to
be doing Internet Engineering rather than Internet Name
Selection, we should probably be concentrating a bit more on the
former than the latter.

best,
    john

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Jul 2015 14:05:23 +0200

Geoff,

On Jul 21, 2015, at 8:37 AM, Geoff Huston <[email-masked]> wrote:
> I find the reversion of putting the IETF back into the frame

I would agree, however I don't believe that's what we're discussing.

I thought we were talking about how to deal with the reality that there are non-global and/or non-DNS uses of domain names. RFC 6761 has created a mechanism to describe those uses, but did not provide any criteria by which a decision would be made as to whether the domain names would be reserved for that use (well other than Standards action or IESG decision).

That is, RFC 6761 has already placed the IETF back into that particular frame. However, if we assume the requests made for Special Use Names are technical and not political or economic, it would seem the IETF would be the right place to come up with the criteria by which those names are placed on the Special Use Names registry, no?

> Furthermore, I appreciate and support John’s analysis and suggested

John's suggested approach confuses me.

It seems to be suggesting that ICANN should take on the role of doing the technical analysis of whether a particular protocol meets a set of technical criteria specified in a document in which the ICANN community had no input.

That can't be right, so I suspect I misunderstand.

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2015 08:25:58 -0400

> It allows us to add support for hidden services without modifying the

Absolutely.   However, it is perhaps worth noting that there is a long-standing solution to the problem that doesn’t require socks: nsswitch.conf.   It’s not the right architectural solution either, for a couple of reasons: not an appropriate UI for non-hackers, and a bit too dependent on the list of things switched being small.   But the point is that this is actually a pretty well-understood problem, and if, as a policy, we continue to add special-use names as required, the solution to the problem of how to handle these special-use names in the host stack is already well understood.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2015 08:39:24 -0400

> eventually need new hacks to categorize and organize the other

I think there’s some truth to this, but I think it’s unfair to lay the whole problem at the feet of RFC 6761: it wasn’t our intention that TLDs be allocated will-he, nill-he, by ICANN, but we delegated change control to them and they did it.   If I were to architect a solution to this in the abstract, the way I would do it is as follows:

-2: Have a configuration mechanism for registering new special-use domains, so that (1) isn’t unnecessarily restrictive
-1: If we get a registration for a special-use domain, validate its non-existence as a domain name using DNSSEC, or else using the software signing practices of the OS.

1. If I get a query for name under a TLD that I recognize as special-use, do the special-use thing.
2. if I don’t recognize the TLD as special-use and I don’t have a cached record for it, do a query _just for the TLD_ to get the SOA for that TLD.
3. if I get NXDOMAIN, or if I can’t validate the TLD delegation using DNSSEC, stop.
4. Otherwise do a query on the whole name.

This accomplishes three things.   First, it deals with special-use names that are popular enough to be implemented broadly, and also with special-use names that the end user needs, but that are not needed generally.   Secondly, it securely prevents malware from installing interceptors for legitimate TLDs.   Third, it prevents leakage of queries that should be private: the network can see that I am interested in a .onion URL, but not _which_ URL.

So I think that this is a very tractable problem, despite the handicaps that we come in with.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 21 Jul 2015 15:42:15 +0200

Geoff,

Which John? Mr. Klensin or Mr. Levine?

thanks
tim

---

From: Sam Hartman <[email-masked]>
Date: Tue, 21 Jul 2015 10:16:13 -0400

>>>>> "Ted" == Ted Lemon <[email-masked]> writes:

    Ted>    Absolutely.  However, it is perhaps worth noting that there
    Ted> is a long-standing solution to the problem that
    Ted> doesn€™t require socks: nsswitch.conf.
    Ted> It€™s not the right architectural solution either,
    Ted> for a couple of reasons: not an appropriate UI for non-hackers,
    Ted> and a bit too dependent on the list of things switched being
    Ted> small.  But the point is that this is actually a pretty
    Ted> well-understood problem, and if, as a policy, we continue to
    Ted> add special-use names as required, the solution to the problem
    Ted> of how to handle these special-use names in the host stack is
    Ted> already well understood.

At least on my OS, nsswitch.conf only allows me to change name
resolution.
It doesn't allow me to connect to a hidden service without modifying my
application.
(There's no IP address corresponding to  the application.)
I could I guess allocate a IPv6 ULA (or site-local eve) block to a local
tun adapter, have a name service engine that allocated addresses in that
range to hidden services, and then grab the packets out of that tun
interface, map back to v4, and run through TOR.

However, both the sox approach and what I'll call the
nsswitch+extra_complexity approach have a dependence on DNS in common.
The slot that my application has is a hostname slot, not a URI slot when
interacting with the network layer.

--Sam

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2015 10:19:10 -0400

> interacting with the network layer.

Yes, it’s certainly true that what we actually want is connect_to_name, not resolve_name_to_address+connect_to_address.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 21 Jul 2015 16:39:40 +0200

Hi,

Warning to the ietf@ audience: this contains a bunch of stuff about
the DNS.  If that makes your eyes glaze over, you might as well go to
the next message.  It's probable that, if this generates more follow
up, the thread should move to dnsop@ or dnsext@ (WG is closed, but the
list is still alive) or something like that.

> like to understand it better.
[…]
> note some very strong analogies with the IDNA kludge.

The first issue is exactly what you suggest: the class code is almost
completely unexercised except to get responses to CHAOS queries, and
that generally just for one purpose.  So we have an enormous installed
base with likely bit-rot, even assuming the code ever did the right
thing.  But that's not the problem.

It turns out that aliases are defined as class-independent.  The CNAME
algorithm (it works similarly in DNAME) is defined in RFC 1034, in
section 3.6.2.  That algorithm says that you look for a CNAME record
with a matching class, which sounds like you can have different RDATA
at a name in one class vs another, which would mean that even though
the CNAME RR is class independent there is no influence between classes.

Unfortunately, the discussion of the way the namespace is divided up
says this:

    The class partition is simple.  The database for any class is
    organized, delegated, and maintained separately from all other
    classes.  Since, by convention, the name spaces are the same for
    all classes, the separate classes can be thought of as an array of
    parallel namespace trees.  Note that the data attached to nodes
    will be different for these different parallel classes.

Now, if the databases are parallel for all classes, then presumably
the RDATA of an aliasing record ought to maintain that parallelism.
Since in principle the RDATA in different classes ought not to affect
the other classes, this seems at least problematic.

Now perhaps we could just reject this "convention" (which would be the
opposite of what we did with the preferred syntax, but of course that
was widely used whereas classes perhaps are not).  At that point, we
start to realise why people didn't use classes in the first place.
For in a DNS packet, the class is in a really awkward place.  Even
though the names might not be the same in all the classes, when you
get an RR you get the name first, and only after that learn what the
class is.  This means that you really have to parse the entire message
before you realise, "Oh, look, this class says not to look this record
up."  At bottom, the DNS message format is designed such as to make
classes a pain in the neck to use.  I suspect that this fact is what
is really encouraging the encoding of metadata about resolution inside
the domain name itself: the name is the piece of data that is first
and most easily accessible.  So, this is why I say that classes don't
really work.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Jul 2015 13:24:44 -0400

Andrew,

Thanks.  I have always assumed that class-independent aliases
were either an error or fuzzy thinking in RFC 1034/1035, but the
response format issue is significant.  Your explanation led me
to realize that while I can, in principle, specify records from
several CLASSes in the same (external format) zone file, or even
have a single owner in that zone file with records associated
with different classes, either would constitute a threading
nightmare for different root and delegation structures.   That
"same zone file" or "same owner" capability is, in retrospect,
completely consistent with class-independent aliases: with
appropriate restrictions, one could get one or the other to work
but not hoth.

The combination is, to me at least, at least as clearly
"mis-specified and cannot work" as, e.g., RFC 1034 inverse
queries.  

Good idea while it lasted.  The feature of separate trees (and,
btw, label types or equivalent) is probably a candidate for the
"DNSng" list.  Also, your explanation and parts of the above may
be candidates for any update to RFC 2181.

     john

--On Tuesday, July 21, 2015 16:39 +0200 Andrew Sullivan
<[email-masked]> wrote:

> Hi,
> 
> Warning to the ietf@ audience: this contains a bunch of stuff
> about the DNS.  If that makes your eyes glaze over, you might
> as well go to the next message.  It's probable that, if this
> generates more follow up, the thread should move to dnsop@ or
> dnsext@ (WG is closed, but the list is still alive) or
> something like that.
> 
>> actually be needed. I would not be surprised if you told me
>> that CLASS has been botched in some implementations and there
>> has been no incentive to fix it, that shouldn't surprise me
>> at all. However, if there were an important application, I
>> assume those implementations could be fixed.  So what do you
>> see as the issue?   Is it that we have needs to intermix
>> ordinary public names with "don't try to resolve this there"
>> stuff in the same environments?  I agree that would be a
>> problem for CLASS, but note some very strong analogies with
>> the IDNA kludge.
> 
> The first issue is exactly what you suggest: the class code is
> almost completely unexercised except to get responses to CHAOS
> queries, and that generally just for one purpose.  So we have
> an enormous installed base with likely bit-rot, even assuming
> the code ever did the right thing.  But that's not the problem.
> 
> It turns out that aliases are defined as class-independent.
> The CNAME algorithm (it works similarly in DNAME) is defined
> in RFC 1034, in section 3.6.2.  That algorithm says that you
> look for a CNAME record with a matching class, which sounds
> like you can have different RDATA at a name in one class vs
> another, which would mean that even though the CNAME RR is
> class independent there is no influence between classes.
> 
> Unfortunately, the discussion of the way the namespace is
> divided up says this:
> 
>     The class partition is simple.  The database for any class
> is     organized, delegated, and maintained separately from
> all other     classes.  Since, by convention, the name spaces
> are the same for     all classes, the separate classes can be
> thought of as an array of     parallel namespace trees.  Note
> that the data attached to nodes     will be different for
> these different parallel classes.
> 
> Now, if the databases are parallel for all classes, then
> presumably the RDATA of an aliasing record ought to maintain
> that parallelism. Since in principle the RDATA in different
> classes ought not to affect the other classes, this seems at
> least problematic.
> 
> Now perhaps we could just reject this "convention" (which
> would be the opposite of what we did with the preferred
> syntax, but of course that was widely used whereas classes
> perhaps are not).  At that point, we start to realise why
> people didn't use classes in the first place. For in a DNS
> packet, the class is in a really awkward place.  Even though
> the names might not be the same in all the classes, when you
> get an RR you get the name first, and only after that learn
> what the class is.  This means that you really have to parse
> the entire message before you realise, "Oh, look, this class
> says not to look this record up."  At bottom, the DNS message
> format is designed such as to make classes a pain in the neck
> to use.  I suspect that this fact is what is really
> encouraging the encoding of metadata about resolution inside
> the domain name itself: the name is the piece of data that is
> first and most easily accessible.  So, this is why I say that
> classes don't really work.
> 
> Best regards,
> 
> A

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2015 18:04:13 -0000

>Yes, it’s certainly true that what we actually want is connect_to_name, not
>resolve_name_to_address+connect_to_address.

Right.  But connect_to_name is just what SOCKS does.  I agree that
SOCKS has its problems, but in this case its API is pretty good for
name-that-is-not-in-the-DNS-for-service-that-is-not-TCP.

Even if we posit a cleaner connect_to_name than SOCKS, and an extended
nsswitch.conf that handles mappings from names to libraries that
implenent various non-TCP transports, we're still back to the question
of where does the list of names and libraries come from.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Jul 2015 14:17:03 -0400

> name-that-is-not-in-the-DNS-for-service-that-is-not-TCP.

Okay, that’s an interesting point, but the way it works is that you have a switch based on the TLD.   There is no other way to make it work.   So this is basically orthogonal to the question we are discussing.

> of where does the list of names and libraries come from.

Happily, there is an IANA registry for special-use domain names!   :)

But if you mean “should we have some other process,” the answer may be yes, but I don’t see how to get there from here.   In order for us to have a process that could work, we’d need for it to be the case that ICANN doesn’t allocate new TLDs under some other process, and that ship has, for better or for worse, sailed.   I don’t see any way to put the toothpaste back in the tube.   I wish that the terms of service for ICANN back when we gave them authority over the namespace were that TLDs had to be allocated through an IETF process.   That would make a lot more sense than the status quo.   But the status quo is, by some strange definitional twist of fate, what we have.

---

From: "John Levine" <[email-masked]>
Date: 21 Jul 2015 22:24:43 -0000

>It turns out that aliases are defined as class-independent.

Oh, it's worse than that.

$ fgrep -i "class independent" rfc????.txt
rfc3845.txt:   The NSEC RR RDATA format is class independent and defined for all
rfc4025.txt:   This resource record [IPSECKEY] is class independent.
rfc4034.txt:   The DNSKEY RR is class independent.
rfc4034.txt:   The RRSIG RR is class independent.
rfc4034.txt:   The NSEC RR is class independent.
rfc4034.txt:   The DS resource record is class independent.
rfc5155.txt:   The NSEC3 RR RDATA format is class independent and is described
rfc5155.txt:   The NSEC3PARAM RR RDATA format is class independent and is described
rfc6698.txt:   The TLSA RR is class independent.
rfc6742.txt:   The NID RR is class independent.
rfc6742.txt:   The L32 RR is class independent.
rfc6742.txt:   The L64 RR is class independent.
rfc6742.txt:   The LP RR is class independent.
rfc7043.txt:   The EUI48 RR is class independent.
rfc7043.txt:   The EUI64 RR is class independent.
rfc7553.txt:   The URI resource record is class independent.

I think this means that all of the other RR's are only valid in class
IN, but I don't really know.

R's,
John

---

From: David Morris <[email-masked]>
Date: Tue, 21 Jul 2015 16:17:13 -0700 (PDT)

OR, class independence is specified such that it doesn't match.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Jul 2015 15:01:35 +1000

> IN, but I don't really know.

The RR types that are class dependent are called out as such.  A,
AAAA and WKS are class dependent.  A's structure and text representation
changes based on the class.  AAAA and WKS only make sence in IN.
WKS as a IN A record embeded in it and IN specific port numbers.

For a developer class dependence/independence impacts on how you
parse the record and the wire encoding of the record.

% ls lib/dns/rdata/in_1/
a6_38.c         aaaa_28.h       kx_36.c         nsap_22.h       wks_11.c
a6_38.h         apl_42.c        kx_36.h         px_26.c         wks_11.h
a_1.c           apl_42.h        nsap-ptr_23.c   px_26.h
a_1.h           dhcid_49.c      nsap-ptr_23.h   srv_33.c
aaaa_28.c       dhcid_49.h      nsap_22.c       srv_33.h
% 

% ls lib/dns/rdata/ch_3/
a_1.c   a_1.h
% 

% ls lib/dns/rdata/hs_4/
a_1.c   a_1.h
% 

% ls lib/dns/rdata/generic/
afsdb_18.c      eui64_109.c     lp_107.c        nsec3_50.c      rt_21.c
afsdb_18.h      eui64_109.h     lp_107.h        nsec3_50.h      rt_21.h
caa_257.c       gpos_27.c       mb_7.c          nsec3param_51.c sig_24.c
caa_257.h       gpos_27.h       mb_7.h          nsec3param_51.h sig_24.h
cdnskey_60.c    hinfo_13.c      md_3.c          nsec_47.c       soa_6.c
cdnskey_60.h    hinfo_13.h      md_3.h          nsec_47.h       soa_6.h
cds_59.c        hip_55.c        mf_4.c          null_10.c       spf_99.c
cds_59.h        hip_55.h        mf_4.h          null_10.h       spf_99.h
cert_37.c       ipseckey_45.c   mg_8.c          nxt_30.c        sshfp_44.c
cert_37.h       ipseckey_45.h   mg_8.h          nxt_30.h        sshfp_44.h
cname_5.c       isdn_20.c       minfo_14.c      openpgpkey_61.c tkey_249.c
cname_5.h       isdn_20.h       minfo_14.h      openpgpkey_61.h tkey_249.h
dlv_32769.c     key_25.c        mr_9.c          opt_41.c        tlsa_52.c
dlv_32769.h     key_25.h        mr_9.h          opt_41.h        tlsa_52.h
dname_39.c      keydata_65533.c mx_15.c         proforma.c      txt_16.c
dname_39.h      keydata_65533.h mx_15.h         proforma.h      txt_16.h
dnskey_48.c     l32_105.c       naptr_35.c      ptr_12.c        unspec_103.c
dnskey_48.h     l32_105.h       naptr_35.h      ptr_12.h        unspec_103.h
ds_43.c         l64_106.c       nid_104.c       rp_17.c         uri_256.c
ds_43.h         l64_106.h       nid_104.h       rp_17.h         uri_256.h
eui48_108.c     loc_29.c        ns_2.c          rrsig_46.c      x25_19.c
eui48_108.h     loc_29.h        ns_2.h          rrsig_46.h      x25_19.h
% 

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 22 Jul 2015 10:45:28 +0200

On Tue, Jul 21, 2015 at 02:05:23PM +0200,
 David Conrad <[email-masked]> wrote 
 a message of 65 lines which said:

> RFC 6761 has created a mechanism to describe those uses, but did not
> provide any criteria by which a decision would be made as to whether
> the domain names would be reserved for that use 

Which was may be wise since trying to find such criteria will
certainly prove very difficult. Apparently, there was only two
suggested, the size of the installed base, and the leaks to the USG
root. The first one contradicts the very common statement that P2P
developers should humbly ask for a special-use TLD *before* deploying
their software. It is also a difficult criterium for software which
claims to provide privacy and therefore have difficulties computing
statistics. The second criterium, leaks to the root, is too easy to
forge.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 22 Jul 2015 10:42:04 +0200

On Tue, Jul 21, 2015 at 10:25:58AM +0200,
 George Michaelson <[email-masked]> wrote 
 a message of 87 lines which said:

> "RFC 6761 was a mistake"

It is the RFC we currently have. If we publish a RFC, use it for a big
corporation whose software used .local, then close the door when free
software developers want to do the same, we seriously undermine the
credibility of IETF.

You may like RFC 6761 or not, but saying that it must be used when you
approve the proposal (.local) and suddenly that it must not be used if
you don't like the current proposals is not a proper process.

> so the -BIS document should consider one option being to say "we
> made a mistake: we don't do this"

The current "design team" (which did not produce yet a document
besides monday's slides) does not reflect a consensus in the working
group. 

It may be interesting to make a 6761bis but first, we need a consensus
on what are the issues with 6761 and there is no such consensus. (The
"design team" is too obviously an effort to "close the door" to future
reservations of special-use TLDs.)

---

From: George Michaelson <[email-masked]>
Date: Wed, 22 Jul 2015 12:28:48 +0200

I partially agree. The consequences of generalising .Local and .corp as
pragmatism -> formalised pragmatism is why we are now here.

It may be very uncomfortable backing the steam train out of the dead end,
but if you want to pretend the train only has a forward gear, I think you
wind up in some very awkward places.

So yes. a 6761bis invites criticism and (legitimate) complaint about
procedural unfairness. And, we look silly. And yes, there is no consensus
for a 6761bis.  I'm not claiming I have a big caucus near me, or see one to
join.

I merely noted that there are voices (myself included) who think a revision
might be most useful if it abnegated the right to make these decisions and
said "the root zone vests with other people: ask other people to do things"

-G

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Jul 2015 18:01:33 +0200

[Back to dnsop where it belongs]

On Wed, Jul 22, 2015 at 12:28:48PM +0200,
 George Michaelson <[email-masked]> wrote 
 a message of 115 lines which said:

> I merely noted that there are voices (myself included) who think a
> revision might be most useful if it abnegated the right to make
> these decisions and said "the root zone vests with other people: ask
> other people to do things"

IMHO, before we embark on discussions about RFC6761bis, we need an
Internet-Draft describing precisely what is (perceived as) wrong in
RFC 6761. I was shocked that we have a "design team" to work on RFC
6761bis while we still do not have a consensus on the problems with
6761.

---

From: John Curran <[email-masked]>
Date: Thu, 23 Jul 2015 17:45:19 -0400

On Jul 22, 2015, at 6:28 AM, George Michaelson <[email-masked]> wrote:
> I merely noted that there are voices (myself included) who think a revision might be most useful if it abnegated the right to make these decisions and said "the root zone vests with other people: ask other people to do things”

George -

A interesting assertion, given that the root zone is the entire top-level of the
identifier space and would specifically include "assignments of domain names
for technical uses”.  I will observe that the latter is a right which the IETF has 
already reserved for itself, ceding to ICANN the general purpose assignments,
i.e. that which "present policy issues” (at least as described in the IETF/ICANN 
MOU [RFC2860])

That’s not to say that the IETF can’t revise this position as desired, only that 
it should be recognized as a change from documented state.  It might also be
good to consider the principle of whether it is ever good practice for the IETF 
to completely delegate an registry identifier space without retaining some 
ability for making specialized/technical assignments…)

/John

Disclaimer: my views alone.  email contains 100% reused electron content.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jul 2015 17:54:37 -0400

Ideally, ICANN ought to give IETF an opportunity to say “no, don’t allocate that name” for any common word or common abbreviation for a common word (modulo the one-letter, ISO country code and similar constraints, of course).   That would cover all of the cases we’re talking about.   I think it’s too late to do that now, but that’s what I’d want if it were possible to do it.

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Jul 2015 18:15:07 -0400

--On Thursday, July 23, 2015 17:54 -0400 Ted Lemon
<[email-masked]> wrote:

> Ideally, ICANN ought to give IETF an opportunity to say "no,
> don't allocate that name" for any common word or common
> abbreviation for a common word (modulo the one-letter, ISO
> country code and similar constraints, of course).   That would
> cover all of the cases we're talking about.   I think it's
> too late to do that now, but that's what I'd want if it
> were possible to do it.

Ted,

At the risk of being pragmatic... ICANN has developed a complex
and expensive application process for new gTLDs.  I've heen told
by applicants that the circa $186K (USD) fee isn't even half of
the total application costs.  So someone makes one of those
applications, moves a name through the ICANN process, and then
ICANN comes to the IETF and says "is it ok to approve and
delegate that name".   I hesitate to think about what would
happen if we said "no", but assume it would involve
organizations trying to get their $300-$400K (each) back and
lawyers.

One could imagine a completely different process, but it
probably is, as you suggest, too late now.

One useful property of the model I suggested is that it would
be, AFAICT, compatible with ICANN's current new gTLD process and
its likely successors.  Of course nothing is going to solve the
problem that would exist if ICANN delegates a root-level name
and the IETF (or someone else) comes along and says "whoops,
that conflicts with...".

   john

---

From: Steve Crocker <[email-masked]>
Date: Thu, 23 Jul 2015 18:26:14 -0400

John,

I thought your message was quite helpful.  With respect to where things stand on the ICANN side of this, ICANN opened a window for applications for new top level domains and then closed that window.  We have been processing the applications that came in during that period but we have not accepted *any* new applications, with the possible exception of IDN ccTLDs.  We do expect to open the window again in the future, but we will go through several steps before we do so, including evaluating any security and/or stability issues.

Thus, I think we’re actually in a very good position to work out sensible coordination of the top level of the name space.  Everyone involved on both the ICANN side and the IETF side now have the benefit of seeing what has happened, and since we’re in a quiet state we can hammer out a sensible process.

As you point out, it would be helpful for our applicants to know ahead of time if a string they desire is unavailable.  Someone should fill in the blanks and make this work.

Steve

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Jul 2015 01:52:45 +0200

John,

On Jul 23, 2015, at 11:45 PM, John Curran <[email-masked]> wrote:
> for technical uses”.

The root zone is NOT the entire top-level of the identifier space. It is the top-level of the subset of the identifier space that is comprised of (a) strings that are valid in the DNS protocol and (b) have been permitted by policies defined by (at least some portion of) the IETF community as documented in RFC 1591 and, later (post RFC 2860), the ICANN community through the various bottom-up, consensus-based processes that ultimately led to the Applicant's Guide Book.

Even if you meant "what could potentially be placed in the root zone", this would still be limited by (a) by the simple fact that the root zone is a DNS protocol implementation artifact, not a namespace artifact, and is thus constrained by the limitations of the DNS protocol.

> I will observe that the latter is a right which the IETF has

Sure. Please define "technical uses". Or, more specifically, please describe how the IETF determines which string out of the universe that may potentially be placed into the root zone should be reserved and which shouldn't. That, AFAICT, is the key issue here.

Some are arguing that this should be done by ICANN (whether this means the ICANN community or ICANN staff is unclear). This seems a bit surprising to me, since the same folks are typically often highly critical of ICANN's technical competence but they are implicitly demanding the ICANN community make a determination as to what is a technical use and what is not. However, I'm sure I'm misunderstanding something.

Regardless, as Stephane points out, RFC 6761 is what we have now. That RFC has laid out a set of criteria by which, in most cases, the IESG (not ICANN) gets to choose whether a string should be removed from the potential universe of strings that may be eligible for allocation via the ICANN community defined processes. Given the 10+ years that it has taken the ICANN community to come up with the 300+ pages of policies detailing what are and are not eligible, I don't envy the IESG in their deliberations. However, perhaps the politics and economics that impacted the ICANN processes will be avoidable in this case.

> it should be recognized as a change from documented state.

My reading of RFC 6761 is that a change of state has already occurred and people are just now realizing the implications, prompted by ONION and other non-DNS names.

Regards,
-drc

---

From: Ted Lemon <[email-masked]>
Date: Thu, 23 Jul 2015 21:04:53 -0400

On Jul 23, 2015, at 6:15 PM, John C Klensin <[email-masked]> wrote:
> So someone makes one of those
> delegate that name". 

No offense, John, but you appear to be erecting a straw man to argue with here.   Of course, the time to ask “does it make sense to allocate this name” is at the beginning of the process, not at the end of the process.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Jul 2015 05:29:38 +0200

> organizations trying to get their $300-$400K (each) back and

On the other hand, that model nicely matches how we do standards
approval, in terms of requiring extended, up-front investment, with no
basis for determining likely approval...

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: John C Klensin <[email-masked]>
Date: Thu, 23 Jul 2015 23:40:34 -0400

--On Friday, July 24, 2015 5:29 AM +0200 Dave Crocker
<[email-masked]> wrote:

> On the other hand, that model nicely matches how we do
> standards approval, in terms of requiring extended, up-front
> investment, with no basis for determining likely approval...

Yes, but I'm not sure the analogy works.  In the standards
situation, if the work is done, the people who do it are happy
with the results, but the IETF does not approve a standard, the
interested parties are, in general, still free to go ahead and
deploy products and, if they want endorsement from someone, to
go forum shopping.  We've even seen cases in which an enterprise
discovers that lying about having a standard is almost as good
as having one.  By contrast, in the TLD names case, if one
applies for a name in the root and doesn't get it, there is no
practical alternative (other than alternate roots, of course) --
if one thinks one wants or needs a name and the application is
rejected, one has nothing and no alternatives other than the try
to get the decision reversed.

It would be interesting to try to estimate the cost of
participants of developing an IETF Proposed Standard and then to
compare that to various estimates of the cost to develop and
submit a TLD application.

    john

---

From: Dave Crocker <[email-masked]>
Date: Fri, 24 Jul 2015 06:18:45 +0200

> submit a TLD application.

Many years ago, I did a back of the envelope calculation for the
aggregate cost of an easy and quick IETF standards effort and landed on
US$ 1M.

I'm sure it is a multiple of that now and that the larger efforts run
into aggregate costs that are 10 times as high.

Engineers are expensive. A group of many engineers is quite a bit more
expensive.  Engineers over many months are...

d/

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Jul 2015 09:21:03 +0200

Hi,

On Jul 24, 2015, at 12:15 AM, John C Klensin <[email-masked]> wrote:
>> Ideally, ICANN ought to give IETF an opportunity to say "no, don't allocate that name"
> I hesitate to think about what would

Yep. In addition, it would probably result in the non-trivial political and economic forces endemic to ICANN interested in blocking a name (for whatever reason) redirecting their energies to the IESG (or whoever the IETF decides "we" are). After all, if they can't legitimately block a name through the ICANN processes, they'd get one last bite at the apple at the IETF.

I'm guessing this probably isn't what folks in the IETF would want.

Regards,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Jul 2015 10:48:46 +0200

Hi,

> I'm guessing this probably isn't what folks in the IETF would want.

This is ridiculous.

As Ted highlighted, John has thrown up a straw man that nobody would
ever reasonably propose (the IESG being consulted on every name), where
that has nothing to do with 6761 or any other existing or contemplated
process.

Can we please at least stay within the realm of reality?

Eliot

---

From: David Conrad <[email-masked]>
Date: Fri, 24 Jul 2015 11:32:19 +0200

Eliot,

On Jul 24, 2015, at 10:48 AM, Eliot Lear <[email-masked]> wrote:
> ever reasonably propose (the IESG being consulted on every name),

Ted said:

'Ideally, ICANN ought to give IETF an opportunity to say "no, don't allocate that name"'

and later clarified:

'Of course, the time to ask “does it make sense to allocate this name” is at the beginning of the process, not at the end of the process.'

I'd note that Ted did not constrain the names that would be asked nor the process that the IETF would be given an opportunity to say "no."

However to my point, regardless of where in the ICANN process the "IETF" is asked, do you believe those with political/economic interests in blocking a name would not try to take advantage of that opportunity, or, upon being refused would not invoke lawyers?

> where that has nothing to do with 6761 or any other existing or contemplated process.

I'd agree that this has nothing to do with 6761.

Regards,
-drc

---

From: Eliot Lear <[email-masked]>
Date: Fri, 24 Jul 2015 12:12:02 +0200

On 7/24/15 11:32 AM, David Conrad wrote:
> However to my point, regardless of where in the ICANN process the
> "IETF" is asked, do you believe those with political/economic
> interests in blocking a name would not try to take advantage of that
> opportunity, or, upon being refused would not invoke lawyers?

Sorry- let's turn that around: where is there any sign that such abuse
of our processes has even been contemplated?  And this is the concern I
have with this whole discussion.  The IETF has a legitimate need from
time to time clarify the DNS name space.  We do not do so lightly, and
we do so based on firm technical grounds.  If someone were to try to sue
us for doing that – AND IF THEY WON – then we could decide at that point
to simply close the registry.  But the number of IFs there and those
implied are so long that I like our chances quite a lot of doing just
what we're doing.

My understanding about the situation of 6761 is that people are more
concerned about having to have lengthy debates about each and every
proposed addition, and whether or not that would be a DOS attack on the
IETF or dnsops.  I'm sympathetic to that argument, by the way. 
Especially now.  But that's an argument for proposing stronger criteria
in a 6761bis with which I would likely have no serious objection.

Eliot

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 24 Jul 2015 07:18:47 -0400

On Thu, Jul 23, 2015 at 7:52 PM, David Conrad <[email-masked]> wrote:
> John,
>
> ...
>
> The root zone is NOT the entire top-level of the identifier space. It is the top-level of the subset of the identifier space that is comprised of (a) strings that are valid in the DNS protocol ...
>

If you truly mean the DNS protocol, as opposed to various user
interfaces or conventions, labels in DNS names are binary byte strings
restricted only by a maximum length of 63 bytes (and the minimum
length zero is only permitted as indicating the root). Interesting
byte values such as 0x00 or 0xFF work just fine inside labels in the
DNS protocol.

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

---

From: John Curran <[email-masked]>
Date: Fri, 24 Jul 2015 08:54:00 -0400

> The root zone is NOT the entire top-level of the identifier space. It is the top-level of the subset of the identifier space that is comprised of (a) strings that are valid in the DNS protocol and…

Acknowledged, but will point out that there is a difference between the
technical requirements on those strings and the policy constraints that
ICANN places upon its policies.

> Even if you meant "what could potentially be placed in the root zone", this would still be limited by (a) by the simple fact that the root zone is a DNS protocol implementation artifact, not a name…

I was referring to what could potentially _not_ be placed in the root zone”;
i.e. including entries such as .localhost are part of the namespace, but not
part of the DNS root zone.

> Sure. Please define "technical uses". Or, more specifically, please describe how the IETF determines which string out of the universe that may potentially be placed into the root zone should be res…

It’s a technical matter within the IETF’s purview; one would hope that there
is at least some consultation with the DNS community over in ICANN so as
to minimize/mitigate any fallout.

> Some are arguing that this should be done by ICANN (whether this means the ICANN community or ICANN staff is unclear). This seems a bit surprising to me, since the same folks are typically often hi…

I am also surprised by such, but at the end of day, I still believe it is the IETF’s
call to make.

> Regardless, as Stephane points out, RFC 6761 is what we have now. That RFC has laid out a set of criteria by which, in most cases, the IESG (not ICANN) gets to choose whether a string should be rem…

It is possible that determining what string is _not_ eligible to appear in DNS and will be
assigned to the IETF to be used for technical purposes is a tad easier than determining
what is eligible and the process by which one party (often for commercial benefit) among
many others will receive it...

> My reading of RFC 6761 is that a change of state has already occurred and people are just now realizing the implications, prompted by ONION and other non-DNS names.

It would be nice to agree or reconfirm some clear rules for how this should work (in general)
before turning the crank and executing the process for a particular instance (.e.g.   .onion)

/John

Disclaimer: my views alone.  This message will self-destruct (at heat death of the universe)

---

From: Richard Shockey <[email-masked]>
Date: Fri, 24 Jul 2015 09:58:27 -0400

+1 

Dave I completely agree. The cost problem is getting out of hand around
here, but the real causation is endless process delays.  To John¹s point
SDO shopping is already going on and its going to be a larger problem in
the future unless there is some serious thought about reforms.

‹ 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jul 2015 13:29:25 -0400

> Yep. In addition, it would probably result in the non-trivial political and economic forces endemic to ICANN interested in blocking a name (for whatever reason) redirecting their energies to the IE…

Yup, and after I went to bed last night I realized that the problem with asking the IETF first is that we take forever to decide anything, and the IESG shouldn’t be held responsible for that.  The bottom line is that this is a really hard problem to solve.   It may be that RFC 6761 got it as right as we can manage under the circumstances.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jul 2015 17:54:31 -0400

> However to my point, regardless of where in the ICANN process the "IETF" is asked, do you believe those with political/economic interests in blocking a name would not try to take advantage of that…

Can you give a practical example, with names redacted, or is it impossible?   I’m having trouble imagining a situation like this where the right outcome wouldn’t simply be “a pox on all your houses,” but maybe there is one?

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2015 22:26:59 -0000

> By contrast, in the TLD names case, if one

That's not a new problem.  In the recent round of applications many
names got multiple applications.  A few combined their applications, a
surprising number went to auction, and a few are still slugging it
out, notably the two applicants for .africa.  Some applications were
turned down or withdrawn for completely nontechnical reasons such as
.amazon and .patagonia.

The domains .corp, .home. and .mail, all three of which have multiple
active applications, are in limbo, all "on hold" so they don't
progress, but not rejected either.  It's unclear (quite possibly also
within ICANN) whether these are intended to be rejections, or if
they'll just wait and see whether there turns out to be some way to
clear out the existing informal use to a level that would be
compatible with selling them.

In view of all that, one more hoop for applicants to jump through, an
early check for technical problems, doesn't seem unreasonable,
particularly compared to what happened this time, a late check a year
into the process.  I agree with the concerns about whether the IETF
can do something like that fast enough, but if the actual schedule for
the next round of new TLDs is anything like the schedule for this
round, there should be plenty of time.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 24 Jul 2015 22:31:03 -0000

>Can we please at least stay within the realm of reality?

Well, OK.  If the plan isn't that we get to look at every name in the
next round, what names do we get to look at?

It doesn't seem likely that we can prepare a complete set of names
with substantial informal use or other technical problems.  Some of
the problems depend on context.  For example, there is a lot of old
CPE that leaks queries for .BELKIN.  But maybe if a TLD application
were from the same company that made the leaky devices, that would be
OK.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Fri, 24 Jul 2015 19:11:14 -0400

> next round, what names do we get to look at?

If something like this were to have any hope of working, which I am not convinced it would anymore, it would have to be a list of names that came through every so often, and got last called.   Any individual name for which someone raises an objection would have to be discussed.   No global objections.   Any name that doesn’t get an objection raised can proceed through the paid process.   Names that do get objections get discussed, and if there is a valid reason for objecting, we say no.   But I have no idea what that would be.   I think that we would obviously have objected to names like .home and .onion on the grounds that they are in use in a way that makes sense (at least to some of us!).   It’s possible that a process like this would turn up reasons not to allocate names, but it’s hard to imagine it scaling, and I can’t come up with any objective criterion.   I just would prefer that these names be allocated because they _could_ be useful in the future.

Short of that, which I think is impossible, I think 6761 actually accomplishes what we need it to accomplish.   If anything, I would suggest that we tweak the criteria a bit: a name that’s in wide use already qualifies.   A name that is proposed to be used in an IETF protocol that is being actively worked on qualifies, until it’s no longer being actively worked on.   A name that is proposed to be used by a protocol being actively developed by another SDO or an open source organization qualifies.   The term should be generic, not a trademark, e.g., I would say that “.gnu” fails here because it’s too close to being a vanity TLD, even if the use that’s proposed for it is otherwise legitimate.   But we’d have to debate that.

I think that one of the reasons people are resistant to this is that in fact it really does suck that it’s either the IETF or ICANN that has to do this, and it could indeed be a DoS attack on the IETF in theory.   But I think that most of the DoS thus far has been arguments over points that we could probably reach consensus on, and needn’t discuss every time.   And I don’t think we can get out of this responsibility—it’s not ICANN’s business, I think, to judge whether a _protocol_ use for a special-use TLD makes sense.   I don’t mean to impugn the qualifications of ICANN participants; I just mean that it’s the wrong hat for them to be wearing.

---

From: "John R Levine" <[email-masked]>
Date: 24 Jul 2015 21:15:15 -0400

>> Well, OK.  If the plan isn't that we get to look at every name in the next round, what names do we get to look at?
>
> If something like this were to have any hope of working, which I am not 
> convinced it would anymore, it would have to be a list of names that 
> came through every so often, and got last called.  Any individual name 
> for which someone raises an objection would have to be discussed.

That's just how the ICANN new TLD program worked.  There was a deadline by 
which all the applications had to be in, 1900 of them last time, and then 
a sequence of deadlines for the various groups doing the various 
evaluations.  I was on one of the technical panels, and there were 
applications that we failed, and had to be corrected.  Some of the isues 
were unexpected, e.g. the string similarity between .unicorn and .unicom, 
eventually resolved by .unicorn withdrawing.

We could have looked at the names and put in technical stability 
objections at the same time everyone else was objecting for other reasons.

> I think that one of the reasons people are resistant to this is that in 
> fact it really does suck that it’s either the IETF or ICANN that has to 
> do this, and it could indeed be a DoS attack on the IETF in theory.

Yes, that's certainly a problem.  But it seems that looking at one big 
bunch of names every three years would be less of a hit than trickling 
them through individually or in handfuls.

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

---

From: Eliot Lear <[email-masked]>
Date: Sat, 25 Jul 2015 06:35:48 +0200

> next round, what names do we get to look at?

We don't.  Why would we?  It's better simply to stick with a list of
known problematic names – and keep that list relatively small.  For
instance...

> were from the same company that made the leaky devices, that would be

I hesitate to get into a pseudo- 6761 application process, but if it's a
problem now, then we should discuss it now and not wait for
applications.  I don't know if .belkin rises to the level where we
should seriously consider it, but I know some people who have some views
on that ;-)

Eliot

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 25 Jul 2015 06:59:11 +0200

On 25 Jul 2015, at 0:31, John Levine wrote:

> For example, there is a lot of old

Related to this, .BELKIN is a special case where whoever makes a judgement can base the judgement on SAC-045. If this is what you are saying, then I claim you say that "the basis for a 'no' is some report from someone else [who?] that say something is different from something else", or?

   Patrik

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 25 Jul 2015 07:01:20 +0200

On 25 Jul 2015, at 3:15, John R Levine wrote:

> That's just how the ICANN new TLD program worked.  There was a deadline by which all the applications had to be in, 1900 of them last time, and then a sequence of deadlines for the various groups doing the various evaluations.  I was on one of the technical panels, and there were applications that we failed, and had to be corrected.  Some of the isues were unexpected, e.g. the string similarity between .unicorn and .unicom, eventually resolved by .unicorn withdrawing.

First of all the process had a list of strings that one could not apply for. So first question is how IETF do believe that list is to be created. By IETF? By ICANN? In cooperation?

Secondly, we have what you talk about, various steps where different communities had the ability to send in input and reactions on the specific names.

I think personally IETF should help creating the initial black list. Before applicants do send in the strings they want.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 25 Jul 2015 01:43:53 -0400

> First of all the process had a list of strings that one could not apply 
> for. So first question is how IETF do believe that list is to be 
> created. By IETF? By ICANN? In cooperation?

In the current round, ICANN published this list of forbidden names on
pages 2-9 and 2-10 of the AGB. I have to say was rather peculiar:

AFRINIC ALAC APNIC ARIN ASO CCNSO EXAMPLE GAC GNSO GTLD-SERVERS IAB
IANA IANA-SERVERS ICANN IESG IETF INTERNIC INVALID IRTF ISTF LACNIC
LOCAL LOCALHOST NIC NRO RFC-EDITOR RIPE ROOT-SERVERS RSSAC SSAC TEST
TLD WHOIS WWW

They also reserved translations of TEST and EXAMPLE into an
unspecified set of other languages.

TEST, EXAMPLE, INVALID, LOCAL, and LOCALHOST are ours, for the rest I can 
mostly guess where they came from, but I don't know and nobody else seems 
to, either.  (What's ISTF?)

On page 2-11, there's two additional lists of names related to the
International Olympic Committee and the Red Cross.  I understand the
political reasoning (they're not trademarks because they belong to
international treaty organizations rather than businesses) but I don't
understand why those two treaty orgs and not a hundred others got
their names special cased beyond the practical fact that these two
complained louder.

I certainly don't want the IETF to get involved in whatever processes
produced those lists.

> I think personally IETF should help creating the initial black list.
> Before applicants do send in the strings they want.

We can try, but I think the chances are high that we would spend a
great deal of time arguing about the list, then later would find that
we'd missed a few that someone applied for.

Also, it's a moving target.  In 2009, .BELKIN was one of the top 10
bogus requests, but nobody was thinking about .ONION.  Now it's
possible that most of the old leaky Belkin routers have been retired,
but I don't know, and I don't know a good way to find out.  There's
the annual DITL snapshots of root traffic, but they're just once a
year, not really comparable from year to year, and there is some
reason to think (papers at the Verisign collision workshop in London
earlier this year) that some of the traffic varies cyclically over a
month or even a quarter so a one day snapshot could miss it.

Regards,

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 25 Jul 2015 07:50:51 +0200

> I certainly don't want the IETF to get involved in whatever processes

Ok, fair. Let me then state my view differently, because I do not think we really disagree with each other.

IF IETF would have a list of domain names not suitable for being TLDs (which it has, but you understand what I mean, I strongly would encourage ICANN to point at that list by IETF when ICANN create this list of theirs, at least for the bootstrap, or maybe even the IETF list would be that black list. But now I know I discuss ICANN PDP here and not IETF, but unfortunately the two are intertwined.

   Patrik

---

From: "John R Levine" <[email-masked]>
Date: 25 Jul 2015 01:56:37 -0400

> IF IETF would have a list of domain names not suitable for being TLDs (which it has, but you understand what I mean, I strongly would encourage ICANN to point at that list by IETF when ICANN create…

ICANN excluded the IETF reserved names last time, and it seems certain 
they would do so next time.  The question is whether we can update that 
list to be complete enough to be useful, and do so in a timeframe that 
would keep it useful.  I have my doubts.  More than doubts.

Regards,

---

From: "Patrik Fältström" <[email-masked]>
Date: Sat, 25 Jul 2015 08:03:32 +0200

On 25 Jul 2015, at 7:56, John R Levine wrote:

> ICANN excluded the IETF reserved names last time, and it seems certain they would do so next time.  The question is whether we can update that list to be complete enough to be useful, and do so in a timeframe that would keep it useful.  I have my doubts.  More than doubts.

Agree.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Jul 2015 12:39:05 -0400

--On Saturday, July 25, 2015 8:03 AM +0200 Patrik Fältström
<[email-masked]> wrote:

>> ICANN excluded the IETF reserved names last time, and it
>> seems certain they would do so next time.  The question is
>> whether we can update that list to be complete enough to be
>> useful, and do so in a timeframe that would keep it useful.
>> I have my doubts.  More than doubts.
> 
> Agree.

And that is, from my point of view, another way to look at the
problem.  We are not, AFAICT, in the "keep a comprehensive list
of applications on the Internet that might use DNS-style names"
business.  Perhaps some of the operational groups (NOG or
otherwise) might be more suitable.  Or not.

Putting that aside for a moment, suppose we make a list and
ICANN treats that as comprehensive (either because the list was
there or because we told them to).  Something that is
significant to some community doesn't make it onto our list.
Remember, for example, that our world now includes IDN TLDs, and
no one has moved to exclude the translation of "local" into
Lower Slobbovian or proposed that all translations of special
names should, themselves, be excluded.  So, some Lower
Slobbovian application is built and becomes widely popular in
that country that uses the relevant name.

Now assume that, since it is not on the list that we built,
ICANN entertains an application for that name.  Assuming there
were a Lower Slobbovian GAC representative by then (there isn't
now) or that someone from another country happens to visit the
country and notice the name in use and mentions it in the GAC.
"Local" and its translations are not a place or national name in
any country that I've heard of, so the GAC doesn't make a strong
recommendation, they just say "you'd better watch out for this
one" at some appropriate part of the process.   Based on the
recent AFRICA decision, ICANN decides to ignore that advice as
excessively vague and outside the GAC charter.  So the name is
delegated and 2/3 of Internet service in Lower Slobbovia ceases
working predictably (for everyone who is old enough, especially
those who recently spent time in Prague, remember what happened
when "CS." was delegated from the root).

That would clearly constitute a mess, probably a "stability
problem" for the global Internet.  I believe the following
responses are predictable:

 * ICANN 1: Not our problem, we used the IETF's list and
	that wasn't on it.
	
 * ICANN SSAC: No one asked us that specific question, so
	we didn't research the name and give an opinion.
	
 * IETF: No one told us about that name or usage.  Of
	course, everyone on the Internet is obligated to tell us
	every time they deploy an application that uses a name.
	That would be consistent with "permissionless
	innovation" because they need to tell us, not ask,
	except, whoops, getting a name on the list requires IETF
	Consensus and IETF Consensus _does_ imply our giving
	permission or at least deciding the string is important
	enough.
	
 * ICANN 2: It is the responsibility of all applicants to
	do due diligence on the name they picked so, if they
	apply for a name and we allocate and delegate it, and
	then it causes problems, those problems are their fault;
	sort it out with them. [1]
	
 * Government of Lower Slobbovia (and/or one or more BRIC
	countries or the ITU or the next WSIS-related or IGF
	meeting):  This proves that IETF and ICANN are US pawns,
	that the US government doesn't care about Lower
	Slobbovia or anyone else who is not directly relevant to
	their short-term political interests, and therefore all
	DNS name registration (and exclusion) issues should be
	handled by an International Treaty Organization.

There are also race conditions inherent in this (as I think
others have pointed out).   If I correctly understood him, Steve
mentioned that it is probably too late to do anything about the
current list of applications -- if there were problems there,
their handling would have to be according to the current
Applicant Handbook and, unless I've forgotten something, it
doesn't say "no names that appear on the IETF's Special Names
list at the time of application".  So we are now making claims
on name reservations for the next round, when and if it happens
but, if a name shows up on our list after that round starts and
people submit applications and pay money, there is another
ambiguity.

I don't want to see us go anywhere near there.  Dumping this on
ICANN and hoping they can figure out a way to handle it without
things getting too political or being sold to the highest bidder
is almost certainly unfair and probably seems more so to those
who believe that it is impossible for ICANN to make a
TLD-related decision without its being controlled by politics or
"moneyed interests".   Perhaps putting them in a position in
which they have to give SSAC a more prominent and authoritative
role and, independently, get out of the "second-guessing
committee" business is unfair too.   However, it seems me that
they signed up for the job when they were chartered.  

We didn't.  And shouldn't.  Should we agree to tell some
ICANN-designated entity or process every time we run across a
name that should be considered "special"?  Definitely.  That is
just being professional.  Should we offer official opinions
about names that are tied up with our protocols or that appear
especially important to us?  I, personally, think that would be
a fine idea.  But the IETF is not in the business of maintaining
authoritative and comprehensive lists of names that should be
excluded; we don't have the skills, knowledge, and process
appropriate to that activity [2]; and, if we were to go into it
on a per-name basis, it would expose us to engagement in
finger-pointing and claims the could damage our core mission.

I do believe there is one very constructive thing we can do
here.  That is to sort out some appropriate reserved TLD name
with ICANN, possibly even have it delegated to something that
generates authoritative NXDOMAIN messages (or worse) and then
issue a strong statement to developers of future applications
that they should use names in that tree, possibly with courtesy
registrations to help them stay out of each other's way, rather
than potentially causing Internet instabilities or getting
themselves entangled with ICANN.  The "ALT" proposal appears to
be a good step in that direction but I think this discussion has
exposed several issues that future revisions of it should
consider.

   best,
   john

[1] That "due diligence by applicants" argument suggests that
this is a huge fuss about nothing.  If one reaches that
conclusion, I'm not sure why we need to have the discussion or a
Special Names registry whose contents stretch beyond IETF
protocols and names that are obviously widely deployed in
narrowly DNS contexts.

[2} I just had a nightmare vision of adding to our IPR
statements and requirements of the Note Well and related
documents a requirement that all participants in the IETF
disclose any name they know about, even names used internally
and confidentially by their employers or other enterprises, that
might be confused with, or with resolution attempted in, the
DNS.   Not a good idea.

---

From: "John Levine" <[email-masked]>
Date: 25 Jul 2015 16:58:29 -0000

>this is a huge fuss about nothing.

The problem, as noted with .CS, is that it screwed up people who have
no connection to the applicant and no interest in buying a domain name
from them.  Viz. the current concerns about .corp, .home. and .mail.

I suppose you could say that about .onion, but you could also say that
their current request to be added to the 6761 list is the due
diligence.

R's,
John

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Jul 2015 13:19:31 -0400

--On Saturday, July 25, 2015 4:58 PM +0000 John Levine
<[email-masked]> wrote:

> The problem, as noted with .CS, is that it screwed up people
> who have no connection to the applicant and no interest in
> buying a domain name from them.  Viz. the current concerns
> about .corp, .home. and .mail.

Exactly.  A "due diligence by applicant" requirement might still
require those applicants to search for unrelated parties who
might be negatively affected, but one could reasonably expect
them to not be highly motivated in such a search and for the
affected parties to be hard to find.    The place where the CS.
analogy breaks down is that we certainly knew enough about
"relative name" practices to anticipate trouble but, given other
arrangements at the time, we had little or no standing to object
and neither the relevant government nor 3166/MA considered
"don't cause an Internet DNS mess" to be among their criteria,
much less their priorities.

> I suppose you could say that about .onion, but you could also
> say that their current request to be added to the 6761 list is
> the due diligence.

I may not have said this explicitly before, but I don't have a
problem adding onion to the list given the model that now
exists.  My problem is that I don't see a stopping rule and the
idea of the IETF reserving names using our own collective but
very subjective judgment strikes me as risky, both wrt the
quality and completeness of the list and because I think ICANN
and IETF both benefit from clear delineation about boundaries
and responsibilities.  At least unless we can make the stopping
rules much more clear or the evaluation rules much less
subjective, we are, IMO, at high risk getting risk of getting
ourselves into a situation in which we build lists that ICANN
then becomes responsible for using --and likely evaluating-- in
what has historically been the most political and
special-influence-prone part of their processes.  

I continue to believe that the most straightforward solution is
to turn the list-keeping over to them, with the IETF free to
make recommendations that ICANN could decline only with reasons
and willingness to participate in discussion, but with ICANN
able to accept recommendations from others (including its ACs)
as well.  I can imagine other solutions, but most of them
require significant internal organizational changes within ICANN
(e.g., allowing a technically-oriented AC to say "no" not merely
(even if implicitly) "we suggest 'no' but you can always
override our decision or appoint more committees".

If nothing else, if it is their list, the broader Internet
community knows who to hold accountable.  If it is our list and
they, either as a decision or a matter of sequencing with other
decisions, don't use its provisions, the opportunities for
finger-pointing or worse are, well, considerable.

    john

---

From: Christian Huitema <[email-masked]>
Date: Sat, 25 Jul 2015 18:52:02 +0000

On Saturday, July 25, 2015 7:20 PM, John C Klensin wrote: 
>...
>  My problem is that I don't see a stopping rule and the
> and responsibilities... 
> to turn the list-keeping over to them...
>

There is a technical problem: special purpose names, that have their own resolution process, different from the DNS. When a group developed such systems, the practice until now was to pick some reasonable top level name, such as ".local" or ".onion", and then ask for a special rule so that particular name could be excluded from the DNS. That was somewhat problematic, because it took some time for DNS code to be updated and exclude these names, but at least we "knew" that it did not conflict with ".net", ".org" or ".com." Well, we don't know that anymore.

We should note however that there is no technical requirement that special purpose domains be top level domains. When we developed the peer-to-peer naming system PNRP, we simply registered "PNRP.NET," and rooted the peer names there. That meets the "registration" requirement, but it does not meet the kind of special purpose processing that ".local" or ".onion" require, when security dictates that the special names must not me resolved by the DNS.

Suppose now that we reserved a special purpose top level domain, with the definition that it should not be resolved by the DNS, and that queries to it should always get an NXDOMAIN response from DNS servers. We might call it ".not" or ".nxd", or whatever other name ICANN might agree to. Developers of special purpose applications could reserve a second level domain such as "example.nxd". No risk of conflict with domain name entrepreneurs buying a conflicting domain, no risk of interference with DNS resolution.

Isn't that a reasonable path? 

-- Christian Huitema

---

From: John C Klensin <[email-masked]>
Date: Sat, 25 Jul 2015 16:12:01 -0400

--On Saturday, July 25, 2015 6:52 PM +0000 Christian Huitema
<[email-masked]> wrote:

>> I continue to believe that the most straightforward solution
>> is to turn the list-keeping over to them...
>> 
> 
> There is a technical problem: special purpose names, that have
> their own resolution process, different from the DNS. When a
> group developed such systems, the practice until now was to
> pick some reasonable top level name, such as ".local" or
> ".onion", and then ask for a special rule so that particular
> name could be excluded from the DNS. That was somewhat
> problematic, because it took some time for DNS code to be
> updated and exclude these names, but at least we "knew" that
> it did not conflict with ".net", ".org" or ".com." Well, we
> don't know that anymore.

Christian, as I have told others, there was, between
approximately when the DNS came into use and when ICANN decided
to ignore it, a firm rule about such names.  The rule was that
there would never been names (labels with delegation records) in
the DNS root longer than four characters, so one was free to
improvise with ".local", ".localhost", etc.  No special rules
(or additional special rules) needed.

"Onion." is another matter because, I assume, it started being
use after ICANN had abandoned the name-length restriction.

> We should note however that there is no technical requirement
> that special purpose domains be top level domains. When we
> developed the peer-to-peer naming system PNRP, we simply
> registered "PNRP.NET," and rooted the peer names there. That
> meets the "registration" requirement, but it does not meet the
> kind of special purpose processing that ".local" or ".onion"
> require, when security dictates that the special names must
> not me resolved by the DNS.

And that is exactly why I, and others, have been suggesting
since long before the most recent discussions started that, if
people believe in the DNS hierarchical structure, it was better
to use hierarchy than to create new special-purpose names at
root level, and far better the first squatting on such names and
then asking they be reserved on the grounds of deployment and
stability.  

> Suppose now that we reserved a special purpose top level
> domain, with the definition that it should not be resolved by
> the DNS, and that queries to it should always get an NXDOMAIN
> response from DNS servers. We might call it ".not" or ".nxd",
> or whatever other name ICANN might agree to. Developers of
> special purpose applications could reserve a second level
> domain such as "example.nxd". No risk of conflict with domain
> name entrepreneurs buying a conflicting domain, no risk of
> interference with DNS resolution.
> 

Absolutely.  A few details aside, it is a path that several of
us have been suggesting on and off for years and that, as I
understand it, draft-ietf-dnsop-alt-tld is intended to
implement.  I also think that, once the TLD name is worked out
with ICANN and clearly delegated or reserved for this purpose,
it would be entirely reasonable to set up a registry of
reservations on a FCFS basis or something very close to it,
rather than having these painful IETF-list debates.

   john

---

From: Ted Lemon <[email-masked]>
Date: Sat, 25 Jul 2015 20:09:27 -0400

On Jul 25, 2015, at 2:52 PM, Christian Huitema <[email-masked]> wrote:
> We should note however that there is no technical requirement that special purpose domains be top level domains. When we developed the peer-to-peer naming system PNRP, we simply registered "PNRP.NET <http://pnrp.net/>," and rooted the peer names there. That meets the "registration" requirement, but it does not meet the kind of special purpose processing that ".local" or ".onion" require, when security dictates that the special names must not me resolved by the DNS.

This has been discussed earlier in the conversation.   This is probably a valid solution in some cases, but the length and understandability of the name does matter in some cases, so if we were to implement this as a solution for all problems of this type, it would likely not be found satisfying in all cases.   Doesn’t mean we shouldn’t do it, but it doesn’t really solve the problem.   E.g., “.home.blort” is clearly worse than “.home”, because it’s more typing, and the token of meaning isn’t on the end.

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 26 Jul 2015 09:29:37 +0200

> (or additional special rules) needed.

Given what I know of operations at the time (and bearing in mind that
I was not directly involved in TLD operations until the time ICANN was
changing the rule), I believe the above to have been true. But it
hasn't been true since 2001, and it seems to me that is long enough
for us to say that the policy clearly changed.

Anyway, it's not clear to me that this rule was ever actually written
down, so it's hard to see how firm it was.  RFC 1123 has some rules
about the top level, but thost rules do not include the 4-character
limit.  RFC 1123 _does_ note that the DNS ought to work in a network
not connected to the Internet, and talks about "local names", so it is
clear there was an expectation that there would be some.  RFC 1591
outlines the top-level domains, and it is silent on the 4-character
rule.  Anyway, it's quite clear that ICANN's new delegation decisions
circa 2001 rendered 1591 obsolete (though why ICANN never published
updates to 1591 is a mystery to me).  

Best regards,

A (speaking as ever as an individual)

-- 
Andrew Sullivan
[email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Jul 2015 10:52:00 +0100

On 26/07/15 01:09, Ted Lemon wrote:
> This has been discussed earlier in the conversation. 

Not aiming at Ted alone, I have to say that I'm seeing an awful lot
of repetition in this discussion.

Perhaps it's past time we only sent messages with novel arguments or
facts not already raised here or in dnsop?

S.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2015 02:34:12 +1200

On 26/07/2015 19:29, Andrew Sullivan wrote:
> Anyway, it's quite clear that ICANN's new delegation decisions

At least, an update rescinding the sentence "It is extremely unlikely that
any other TLDs will be created." But it was always clear that the IETF
kept the power of decision for assignments of domain names for technical
uses, which has nothing to do with string lengths.

     Brian

---

From: Ted Lemon <[email-masked]>
Date: Sun, 26 Jul 2015 11:02:20 -0400

> facts not already raised here or in dnsop?

It would help if we had a practice of tracking these conversations so that new participants could quickly come up to speed on the discussion to date, and not have to feel like they are unintentionally sea-lioning the other participants.

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 26 Jul 2015 17:13:04 +0200

On 26 Jul 2015, at 16:34, Brian E Carpenter wrote:

> At least, an update rescinding the sentence "It is extremely unlikely that any other TLDs will be created."

There are more clarifications IETF could make, as pointed out in for example the CWG work. See updates and clarifications made in RFC 3152, RFC 4159 and others -- including the letter exchange between Karen Rose and Luis Touton that can be found in Appendix A in RFC 3172.

> But it was always clear that the IETF kept the power of decision for assignments of domain names for technical uses, which has nothing to do with string lengths.

Yes.

   Patrik

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Jul 2015 11:36:29 -0400

--On Sunday, July 26, 2015 9:29 AM +0200 Andrew Sullivan
<[email-masked]> wrote:

>> approximately when the DNS came into use and when ICANN
>> decided to ignore it, a firm rule about such names.  The rule
>> was that there would never been names (labels with delegation
>> records) in the DNS root longer than four characters, so one
>> was free to improvise with ".local", ".localhost", etc.  No
>> special rules (or additional special rules) needed.
> 
> Given what I know of operations at the time (and bearing in
> mind that I was not directly involved in TLD operations until
> the time ICANN was changing the rule), I believe the above to
> have been true. But it hasn't been true since 2001, and it
> seems to me that is long enough for us to say that the policy
> clearly changed.

Absolutely.  The point was only that this is a problem of the
community's making, one with a partially-unanticipated
consequence with which we now have to deal.   In part because
the boundaries were seen as a bit more clear than we seem to see
them today, the IETF/IAB decided to not intervene in 2000-2001
when applications were being accepted and considered.  And,
again, the issue was called to ICANN's attention at the time and
the decision was that ignoring it (and not warning applicants of
the possible consequences) was justified by the need to build
competition, etc.

> Anyway, it's not clear to me that this rule was ever actually
> written down, so it's hard to see how firm it was.  RFC 1123
> has some rules about the top level, but thost rules do not
> include the 4-character limit.  RFC 1123 _does_ note that the
> DNS ought to work in a network not connected to the Internet,
> and talks about "local names", so it is clear there was an
> expectation that there would be some.  RFC 1591 outlines the
> top-level domains, and it is silent on the 4-character rule.

Both mostly deliberate decisions, coming from the same thinking
that produced the "will be alphabetic" statement about TLD names
in RFC 1123.   Pre-ICANN, decisions about specific TLD
allocation was an IANA responsibility, not an IETF one, so it
was more appropriate to tell the IETF what was happening and
going to happen, not to, e.g., make statements about IETF
decisions.

> circa 2001 rendered 1591 obsolete (though why ICANN never
> published updates to 1591 is a mystery to me).  

Given that ICANN, and a number of ICANN-related entities
(notably some ccTLDs and regional ccTLD organizations) continue
to cite 1591, "rendered obsolete" may be a little strong even
though some of its comments are certainly OBE at this point.
And ICANN did publish an update to 1591 in the form of something
called ICP-1 [1].  It didn't say much and, IIR, was not
well-received and has sort of vanished from everyone's radar.  I
would suppose that the "update" for 1591 is the combination of
the ccTLD fast track procedure and the Applicant Handbook, with
1591 and/or ICP-1 still applying to 3166-1-based ccTLDs and
redelegations.

    john

[1]
https://www.icann.org/resources/pages/delegation-2012-02-25-en
as of today.

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Jul 2015 11:58:38 -0400

--On Monday, July 27, 2015 2:34 AM +1200 Brian E Carpenter
<[email-masked]> wrote:

>...
> But it was always clear that the IETF
> kept the power of decision for assignments of domain names for
> technical uses, which has nothing to do with string lengths.

At the risk of hair-splitting, it was always clear that the IETF
always had (and kept) the power of decision over name properties
such as characters to be used.  Lengths were another matter and
probably fell under the same general policies that resulted in
decisions about particular parameter values being treated as
requests.  In particular, IANA made the decisions about what
names or parameter values were actually allocated, not the IETF
or the requester.

However, until circa 1998 - 1998, the IETF _never_ had the
"power of decision" over what went in the root, technical or
otherwise.  RFC 1591 was never an IETF document. It was an IANA
document for community information, one that described
IANA-developed procedures and plans.  The IETF was never
involved in, e.g., ccTLD assignments.  Had the IETF asked (or
"decided") that additional TLD names (whether shorter or longer)
be delegated for technical purposes, I don't know what would
have happened, but that statement from 1591 about anticipation
of new gTLDs may constitute a hint.

That model started changing in the last 1990s and changed
considerably as ICANN took over and the staffing and complexion
of IANA changed.  In particular, the IETF started assigning
specific values and directed IANA to put them into registries
and started reserving DNS names, notably the "example" set.  The
snit with ICANN staff that resulted in RFC 3172 could be seen
from the IANA perspective as an attempt to assert the authority
IANA had before ICANN came into being but we viewed it as
interference in authority the IETF and IAB acquired as part of
the transition to ICANN.

    john

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 26 Jul 2015 20:23:42 +0200

> 1591 and/or ICP-1 still applying to 3166-1-based ccTLDs and

If we are having this discussion, which I do not think we should have here, I would be more careful with wording and separate the issues with various different PDPs inside the ICANN Community (most notably ccNSO and gNSO driven ones) and whatever work ICANN staff and Board run processes create. And not only say "ICANN" (although the use of the word "ICANN" definitely show correctly that one of the larger issues that not even people active in ICANN can separate the processes from each other -- and sometimes they can, but they deliberately mix them up).

Now, I agree ICP-1 is not very good, but I am still of the view that IETF could very well update RFC 1591 according to what the IETF view has changed during the years. If nothing else as a historical document, and it would also have made the handoff to the ICANN be much easier than what it has been now.

If nothing else, we see on this discussion how entangled the IETF process and view is with the ICANN process and view, and I still think it would have been better if IETF would have created a box in the namespace within which ICANN could play. Similarly to what the RIRs are allowed to do within the IPv4/IPv6 address spaces.

Too late?

   Patrik

---

From: "John Levine" <[email-masked]>
Date: 26 Jul 2015 19:19:56 -0000

>It would help if we had a practice of tracking these conversations so that new participants could quickly come up to speed on the
>discussion to date, and not have to feel like they are unintentionally sea-lioning the other participants.

Seeme like an ideal use for the currently empty dnsop wiki

http://trac.tools.ietf.org/wg/dnsop/trac/wiki

If I have time, I'll try and add some of the points from the
discussion here and in dnsop.

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Jul 2015 07:56:44 +1200

Patrik,

On 27/07/2015 06:23, Patrik Fältström wrote:
...
> Now, I agree ICP-1 is not very good, but I am still of the view that IETF could very well update RFC 1591 according to what the IETF view has changed during the years. If nothing else as a historic…

RFC 1591 is not an IETF document. It was written by IANA and published
by the RFC Editor, which at that time involved a very short walk indeed*.
I don't quite see how the IETF could claim to update it unilaterally.

*There may have been some discussion between IANA and the IAB, but
that was just before I joined the IAB, so I don't know.

    Brian