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

["Patrik Fältström " <[e-mail]>]

On 15 Jul 2015, at 17:33, John C Klensin wrote:

>> 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.

There are many shades of gray ;-)

But, I understand your view...

> 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.

Well, I hope that adding names to the special names registry will result in the names be on the "forbidden" list of potential new round of TLDs ICANN might launch. All up to the result of the PDP run by ICANN of course.

> 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.

To me we talk about whether the string (and by that, that branch of the namespace) is to be used in the root of the domain name system or not.

And then the specification is to be sound, and pass the consensus process IETF decides what it should be.

Yes, you are absolutely right that IETF must make up its mind on what the actual process is, but for me that is a smaller issue than the fact special names CAN be added, and by adding them they will NOT be resolvable globally using the DNS and the root ICANN manages.

I know some people say that opens the door for someone to request strings in IETF and create a denial of service attack against the "approval process" ICANN runs, but, I trust IETF to do the right thing.


Ok, now the question is whether .ONION has passed the bar regarding for example deployment etc, and I think it has. Yes, more limited deployment than .LOCAL but definitely deployment, and, if I understand things correctly, multiple independent implementations and deployments.

>> 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.

Agree.

> 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.

Note what I wrote above, that IETF special name registry is NOT for things that goes as a TLD in the root zone. The contrary. So IETF can not this way allocate a TLD in the root zone, which I interpret your text above implying.

If you here talk about allocation of a branch of the namespace, the question is whether bullet 1 in section 2 is strong enough:

  1.  Users: human users are expected to recognize .onion names as
      having different security properties, and also being only
      available through software that is aware of onion addresses.

I guess this goes back to discussions similar to whether one should have URI:HTTP:// or just HTTP:// and we all remember those discussions...

> 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.

Fair.

> 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.

True, but if we look at the chat protocols, IETF could not agree on which one of three different protocols should move forward. Then XMPP came and, well, was developed elsewhere and basically "won".

We now have HTTP/2 which some people do believe could have been done multiple years ago based on BEEP, which is a very good protocol at least academically/theoretically...but how is it going with it?

Anyway...

I am just saying that having ideas actually be cooked inside IETF is not easy...and have not been easy for many years. So just the fact an idea is brought to the IETF when being deployed can not by itself be a reasoning for saying no.

That said, I completely understand what you write (I hope!), and you are right that in there are questions.

Will we be able to find just objective rules for saying yes or no? I don't think so...unfortunately.

   Patrik