On 12/01/2013 06:45 PM, Jacob Appelbaum wrote: > FYI - if you can reply, it would be helpful, I am about to fly to Europe.
I'll try. > -------- Original Message -------- > Subject: Re: [DNSOP] [[email protected]: I-D Action: > draft-grothoff-iesg-special-use-p2p-names-00.txt] > Date: Sun, 1 Dec 2013 12:35:44 -0500 (EST) > From: Paul Wouters <[email protected]> > To: Ted Lemon <[email protected]>, Jake Appelbaum <[email protected]> > CC: Stephane Bortzmeyer <[email protected]>, dnsop WG <[email protected]> > > On Sun, 1 Dec 2013, Ted Lemon wrote: > >> On Dec 1, 2013, at 11:48 AM, Stephane Bortzmeyer <[email protected]> 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? Because I'm not aware of a P2P system implementing ".bofh", and if there is one, they don't seem to be interested in documenting this or working with us. Some other developers did see our draft and reached out to us to be included, and the list will thus be expanded by one more system for -1. Aside from that, if there are unrelated systems, they should probably write their own RFC, as their requirements may differ. Finally, there isn't a "generic" method, as different pTLDs have different requirements. ".local", ".test", ".arpa" and ".onion" don't all fit under one umbrella. Also, I believe any attempt to document "everything" that happens on the Internet is doomed to failure, so the best we can hope for is an "incomplete", but coherent set of documents that document everything that may be important for users and operators. > 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 was explicitly approved by GNU. You're welcome to ask Richard Stallman himself. Dozens of other GNU maintainers and packages are also involved to some degree. So unless you're suggesting that the GNU project should allow someone ELSE to have a trademark on "GNU", I think this is not about you disallowing something, but you preventing the GNU project from using ".gnu". > 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 who'll manage ".alt"? Now we'll need another process for managing assignment within ".alt", break compatibility for millions of users with hundreds of thousands of domains and for what exactly? I could equally suggest that ICANN should just be given ".icann", and so it becomes "www.google.com.icann". After all, who put them in charge? > 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. There are plenty of reasons not to use ".local", starting with that the names in our draft are non-local, or that the deployed software and existing users don't use ".local". Again, this is NOT a standardization process, this is an _informational_ draft/RFC that documents what is happening. We'll continue to use ".onion", ".i2p", and ".gnu". Users do not need someone's blessing to do so, but from a technical point of view it makes a lot of sense to document these pTLDs and give guidance to operators. That's what we're trying to do with the RFC, we're not really asking for "permission". > 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? I'd say yes, if you can justify that information about ".paul" is relavant to the community. > 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? First of all, who'd they sue? Tor users? Tor developers? IETF for publishing an RFC? I don't think there'd be ground for suing any of those parties in this case. However, more importantly, I think you're not clear on trademark law. Trademarks are awarded for a particular domain and scope AND have to be consistently enforced. So unless you know of a global actor in the domain of networking that has a trademark on GNU that would be recognized by courts and would immediately sue about ".gnu" (leaving the question who they'd sue to begin with, the GNU project? That'd be interesting), there's no case to begin with. So please point me to your .onion inc or .i2p inc before making up some straw man argument. > 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? We considered this, but sadly there's no way to make that work with legacy software. I've not found any application that uses DNS today that'd allow users to switch the class (does your browser or e-mail client allow this?). Please let us know how you propose to enable an alternative name system that uses a different class to be integrated with the code that is out there, I'm quite interested as I couldn't find a way to make it work (and usable --- LD_PRELOAD to replace gethostbyname of libc isn't quite a sane answer in my book). > 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) You're mistaken in that Tor is not _only_ used by browsers -- and started of as a pure proxy without _any_ modifications to browsers. The case is even stronger for GNS, where DNS queries can even be intercepted at the network layer by a dedicated DNS2GNS gateway. > So I think this draft has a lot of issues, technically and legally. I'm not a lawyer, but I'm pretty sure your legal opinion is incorrect, possibly because it is based on partial knowledge of the facts. As for the technical side, I also don't quite buy your arguments, as they excessively conflict with usability and seem to be purely based on the idea that this would set a precedent that would then allow anyone to "just" write a big system (Tor, GNUnet and I2P are all projects with about 300,000 LOC) and an RFC and we'd end up with ten billion special-use reserved pTLDs. I find that's unlikely to happen, but even if it did, great, I'd call that progress. Happy hacking! Christian _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
