On Sun, 1 Dec 2013, Ted Lemon wrote:
On Dec 1, 2013, at 11:48 AM, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:
For the record, I've reviewed
draft-grothoff-iesg-special-use-p2p-names-00, I find it well-written
and clear and I fully support it. Registering these names would be a
very good idea.
Why do you support it? Why is registering these names a good idea?
I'm curious too. I'd rather see a generic method instead of an
(incomplete?) list of domain names to reserve. Why wasn't .bofh on
that list? Why was .gnu on that list? What if GNU or someone else
wishes to register .gnu as a new gTLD based on a trademark? Who
are we to disallow that?
This also seems similar to the USENET problem, where John Gilmore
proposed/created the alt.* hierarchy.
It would make more sense to me to reserve something like .alt where
people can plugin onion.alt, gnu.alt, etc, and are guaranteed that
the .alt domain will never actually be delegated by the root. That
means new players who want some peer to peer, no DNS dependancy don't
have to come back here to reserve _their_ names later on.
And once you go that way, one can wonder why not use the already
existing .local for that? Perhaps avoid talking to different protocol
software is a good enough reason not to re-use .local.
But can an RFC even do anything here? Whether you agree with ICANN
procedures for new gTLDs or not, if I write some software that becomes
popular using a .paul pseudo domain, when does it become valid for me
to request it under RFC 6761? What precedent would tor/gnu/zkey/etc set?
Does IETF even have any say in such matters? Isn't this up to IANA or
ICANN? What about trademarks? What about lawsuits by Gnu Inc or Onion
Corp who want their gTLD?
Other questions I would have is why aren't these people using a
different class from IN? They can have a class of TOR or ONION or GNU?
The traditional reasons for not using any non-IN class is that a lot
of software would not work well with that, but in these cases, the
consumers aren't actually interested in real DNS anyway, and using
a URI that indicates a different class should not be too hard to plug
into existing browsers? A specific tor:// URI plugin would make
more sense to me that sticking with http://sdggjaksgdkgda.onion
construct, especially as at least with tor right now, you are stuck
with the SOCKS API anyway. If tor would be truly transparent and map
to a real ip address handled at the kernel/socket level, then it would
make even more sense to map tor://sdggjaksgdkgda.onion onto a new DNS
class like: sdggjaksgdkgda.onion. IN ONION 1.2.3.4 (or perhaps even a
non-A/AAAA identifier, like a straight public key if that's what the
new socket family would take)
So I think this draft has a lot of issues, technically and legally.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
