On 7/21/15 9:20 AM, Eliot Lear wrote:
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.
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.
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.
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