-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ted Lemon wrote: > George, I didn't get into your game theory because I think it's > irrelevant. The IETF process is not a fast process. If > parasitical organizations decide to try to get the calories they > need from us rather than from ICANN, I am pretty sure they will > quickly learn that this is futile. It might briefly suck for us > while they learn that it won't work, but I don't think so. We > already know how to deal with useless proposals. > > So with that in mind, I think we really are free to do the > technically right thing without concern that it will encourage > badness in the future. > > As to the topic of fairness, that is inherently political, and we > should steer well clear of it. There is no way we can reach > consensus on it, and whether you want to admit it or not, by > advancing the argument you are advancing, that is what you are > asking us to do. > > What you are saying is a really good argument against us reserving > names simply because they have been squatted on. I agree we > should not use that as a reason to reserve a special use name. > ICANN already has a process for that If we want to reserve a > special use name, we should have a technical argument in favor of > doing so. > > But in the case of .onion, .corp and .home, we _do_ have such a > reason. So there is no need to resort to the argument that these > names should be documented in the special use registry because > they were squatted on. > > If .onion were being proposed today, and had no previous > implementation, its proponents would rightly be arguing for > .onion, not for .onion.alt, because how names read _matters_, and > it makes sense for .onion to be a special use TLD, as it does for > .corp and .home.
In the virtual meeting, I stated that if I was developing an app like I2P *now* that needed a non-DNS TLD, and .alt existed, I would use it. I should clarify that I would certainly prefer .TLD over .TLD.alt, because I agree with Ted that how a name reads matters. But, if there was an _easy_ process for securing .TLD.alt, _and I knew about it_, I would probably opt for that. It isn't as pretty, but it's not much harder to educate users that .TLD.alt is the special identifier for this new app that it was to educate users back in 2003 that .i2p is the special identifier for I2P addresses. > > DNS has had a long run as the only name database that is taken > seriously on the Internet, and so we no longer think of names as > being something that has an existence independent of the DNS > hierarchy, but that is not an inherent truth of domain names. It > is just the status quo. I would not want to have to use a > different name hierarchy designator in order to use mDNS, and that > being the case, I don't think you can make the argument that .onion > is qualitatively different from .local. +1. The "domain name" is a concept that pervades all internet-using applications now, and any alternative non-DNS naming system that wants to maintain interoperability with existing apps is forced to use it. That is the primary reason why I2P chose .i2p and (IMHO) Tor chose .onion. The biggest barrier to the rise of hidden services like what I2P and Tor provide is content availability. If the I2P and Tor devs had needed to re-implement _every_ client application they wanted to work over their networks, neither network would be as large as they are today. That doesn't mean that new application developers should not write network-aware applications, or that existing applications can be used without any potential for privacy-compromising leaks. There are definite technical and usability benefits to an application setting up its own I2P tunnel. But it is much easier to e.g. run "TZ=UTC git", or point an I2P server tunnel at Apache and configure vhosts, than it is to implement network-level support. Moreover, supporting a non-"domain name" system would very likely require extensive, expensive modifications throughout the app to e.g. remove any and all dependencies on gethostbyname(). The Tor Browser bundle is IMHO testament to this - its developers have added a slew of privacy-enhancing patches, but the browser still handles "domain name"s in the same way as upstream Firefox does. str4d > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVVS8SAAoJEBO17ljAn7PgLvcP/3HPo38zZNGsQ1Hl+fbhOq0S ODDeQbIJDvqTl7DpK9mV+z8ViCjS4+gtw0oYvtB7v3Ig2Pg/jfCS6q0Xbx784fuJ gkHTe4rAkfKHKyA6ozCeSf7rY4FXR6hSc9IoxEKixm33gSiXRmfvLDcF4YOJLrKU GIraly6of0zPIC5NQVO0oXRceMwsn8Mlk2p+N1pDauhu0b54OzBht/7P/XtfIMD1 rbDVHUPcLE6zQNYFklGv3VGV3LkZbR9GwUMsyQ7Jmor9Sfj8llF37OnTJpjsI7Lm ofQgjOXwYFni3k6rOWbPObh2HtDeKAaHu3HdNHcCb5Sm8PXzrYHL9DpWZcO7VAhd 4Z2kuwEIO/7nM/B2yg1XclXvJBzc5G8Egs1plcmWu79lR7UxdHVCoWSjd+Xj1FZP SkFYPTEjt2y02ZfOGG/83rdN1XVkrqts7hIAD+mHk2sMLebcTykP2IAN3KLz5ME1 dlrogOeESBL9wvWrLmgowtNzWW0oGsKeoQdPmyAKm4a0N6oq4FnlPjm3Oce1TGX7 nq1peZX8bemwYO8kpEhouJP4vANE67GKh1u0rLneqMA6SBBeNx+6rRvBmldjMA/2 Fm6ybvDb/CpC5ZVCk5w8oWMVxrOSVJw1Lu33C5DmMUTXHA4UxoPzib7YmybGI/Di MRIQrfHiMOENSVhzaqXb =njLl -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
