Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

[Joe Abley <[e-mail]>]

On 2014-02-12, at 11:28, Marc Blanchet <[e-mail]> wrote:

> - I like better that approach than the previous draft registering many tlds.

The previous draft (at least for some of the TLDs) was anchored in the reality that changing the name already in use was not practical, e.g. there's a sufficient deployed base that uses DNS-like names ending in ONION that proposals to use things like ONION.ARPA were non-starters.

I think therefore that the ALT draft addresses quite a different problem: the choice of DNS-like (but not DNS) name structure for new applications that we don't know about yet.

I suspect that there would be fewer roadblocks involved in choosing an anchor ALT.ARPA than ALT, since ARPA is under the control of an IETF family member while the root is controlled by distant cousins. If I'm right that this proposal is for future, as-yet-unknown applications, then the choice of anchor should be arbitrary; it feels in that case like the path of least resistance is the right one.

> - I would prefer an IANA registry under .alt with "expert" review policy.  A namespace with possible collisions (past or future) have very low value to me. names are leaking in various contexts, so collisions would be bad for the protocols and deployment using that .alt tld.

I think that if we are talking about DNS names, we already have mechanisms to ensure uniqueness.

If we're not talking about DNS names, then the only consideration we really need is to avoid collisions with the DNS. We can do that by reserving ALT (or ALT.ARPA, or whatever), specifying that it's a reasonable domain to sink locally (RFC 6303) and perhaps providing some kind of AS112++ sink for leaks to the wider network (draft-ietf-dnsop-as112-dname).

(An AS112++ sink for a domain is probably easier to realise for ALT.ARPA than it is for ALT, since the root zone is maintained using specific registry machinery that would require changes to support DNAME, I think, and the track record suggests such changes might take a long time to action.)

I don't see an obvious reason to insist on IETF restrictions on an ALT-like namespace if the point of the namespace is to be available for use outside the IETF. If restrictions existed (no matter how simple we imagine they were to follow) the likely outcome is that ALT would either be abused (used without registration) or ignored.


Joe