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

[John C Klensin <[e-mail]>]

--On Wednesday, July 15, 2015 09:00 +0200 Patrik Fältström
<[e-mail]> wrote:

> On 14 Jul 2015, at 21:47, George Michaelson wrote:
> 
>> But we do not exist in a vacuum and I think the combination
>> of 'because we coded it that way'  and 'we want it' are
>> really very poor reasons to enact the special-use domain name
>> request.
> 
> Unfortunately that train left the station with .LOCAL.

Patrik, I don't think so.  While I would have preferred to see
even the formalization of LOCAL. handled in a different way,
ideally including recommendations to ICANN from SSAC about names
restricted up-front in the gTLD allocation/delegation process, I
believe LOCAL. has been widely deployed and used for a _very_
long time, almost certainly pre-ICANN.  The special name
"localhost." has probably been in use even longer.  I am less
sure about, e.g., "invalid." and "test." but, while one might
question why the IETF has fallen victim to the "try to put
things in the root" syndrome rather than using hierarchy, they
are clearly in the spirit of "example."   At least for local.
and localhost., putting the strings into the Special Names
registry may act as a helpful warning to the naive that
expecting to use the names on the public Internet as ordinary
TLDs would be really stupid, but I don't think that registration
changes a thing for any reasonably savvy DNS operation.

In that sense, "this name should be reserved or allocated at the
top level because some application needs it" really is now, the
associated train is still in the station, and we now face a
decision about whether to let it out and, if we do, where the
new boundaries are.

> What IETF might need is a stopping function for approval of
> usage of the domain name namespace outside of the DNS.

I think the intent was that the specifications and
considerations in RFC 6761 established precisely such a stopping
rule.  If this "onion." proposal (and/or the other special-use
names proposals I've seen floating around) demonstrate to the
community that 6761 is not adequate, then perhaps we should put
those proposals for new special-use names on hold and go back
and review 6761 to see if the evaluation criteria need
improvement.

Personal opinion (and maybe a hint about something that may need
examination about the way 6761 is being interpreted): If someone
came to the IETF with a new piece of protocol that needed a
reserved domain name and asked for a root-level name, I assume
they would get a lot of pushback suggesting that they use a
ARPA. subtree or some commercially-available subdomain instead.
I'd hope the IETF would listen carefully to arguments about why
a TLD was really needed, but, assuming we still believe in the
distributed hierarchy model that underlies the DNS, I'd assume
that the default would be "no" and a persuasive case for a
root-level name would be very hard to make.  The difference
between that scenario and some of the special names proposals
that now seem to be floating around is that, rather than
engaging with the IETF when the protocols were being designed,
the community involved decided to pick a TLD-style name, squat
on it, deploy, and then come to the IETF looking for help in
obtaining formal rights to the previously-squatted name.  It
does not seem to be to be in the best interests of either IETF
or the Internet for us to encourage that type of sequence of
events.  

best,
    john