-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 01/26/2015 12:02 PM, carlo von lynX wrote: > Useful mail, thank you. > Regarding Mr Connery's personal opinion however: > >> I have a suggestion to the tor, gnunet, i2p, and >> other overlay communities. It seems likely to me >> that the IANA will not be too happy about reserving >> all of .onion, .exit, .gnu, .zkey, .i2p and .bit. >> I suggest that you ask for ONLY ONE pTLD. For >> example, .p2p, and then stick all your specifics inside >> that. e.g >> >> .onion.p2p >> .gnu.p2p > > Yes yes, bow to politics and bureaucracy.. would be so > amusing if by 2030 hardly anyone is using traditional > DNS and therefore all Internet business happens over > something .p2p, yet for backwards compatibility there's > always this senseless .p2p in the way. > > Also, public-key routing is not limited to P2P architectures. > *** The authors of the P2P Names Internet Draft[0] thought a lot about the possibility of applying for a single TLD for GNUnet, I2P, Namecoin, and Tor. We came to the conclusion that it does not make any sense:
1. it would require a lot changes in the existing deployments. This is probably the least of the issues, but this is still considerable work (and cost) as well as prone to breaking a lot of legacy working code. 2. each of the six pTLDs have a different way to manage names and to resolve them. It would be confusing for both implementors and users to have them all under one tree. 3. a single TLD introduces the issue of who manages the assignation of names under this TLD. As the .alt I.-D.[1] demonstrates, by proposing a first-come-first-served-but-without-guarantee-of-uniqueness, this is likely to be a mess, but our proposal is simple and clear. 4. existing TLDs such as .test, .example, .invalid, .localhost (RFC2606), as well as .local (RFC6762), etc. should then receive the same treatment and all move under a single TLD. That is unlikely to happen, and it makes to technical sense. 5. the only valid argument in favor of a single TLD is to validate the superiority of the top-down hierarchical tree and consider any alternate approach as an annoying and invading experiment. That is not a technical approach. And that is not loyal to the permissive-network and end-to-end fundamental axioms of the Cerf/Khan Internet Protocol that made it future-proof and wildly successful. Additionally, 2. and 3. bring another usability issue. Consider HTTPS, the HyperText Transfer Protocol, whose final "S" either means "perfectly forward secure" or "completely compromised". That is confusing. Now it's complicated enough for users to make a difference between two similar but completely different HTTPS--one secure, one not. How would you expect that they make a difference between different P2P systems and their scope, threat models, privacy implications, etc., if they all went under a single .p2p (or whatever) TLD? TLD is made to distinguish one thing from another: If I hit .de, it's a German site, if I hit .int, it belongs to the United Nations. If I hit a .p2p, it's... Peer-to-peer? Really? Should we move all legacy applications under .c2s for client-to-server? Of course not. If P2P Names share commonalities, they are also different from each other. They belong to the same "family" as far as IANA is concerned, because it makes sense technically, and also for implementors, it makes sense to look up one RFC and find them there. In conclusion, refusing to grant 6 names instead of a single one when RFC1591 declared "[i]t is extremely unlikely that any other TLDs will be created", and when RFC6762 reserved 6 names (one TLD and 5 in-addr.arpa names), in the year the Root Zone became crowded with .boo, .fail, .foo, .porn, .sucks, .wtf and a thousand others is kind of insulting. Regards, == hk [0] https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ [1] https://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJUxvPsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0 ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg97E0P/1eWHa7BEPz9vYNCoKtNUAPn KY3IjYsI6hSNBYHHywMFPjTfk9gqhmWw+G6wcvyhpi1HOMniJMtiIqzvUkkfX8ri kFy0Vxq1feFOD8M7xu2OekXqr/WBFebYejepIJGZ/u3noumtIPGYrdlBjVEztrHT p9WkN9BVgj+JqF5AfXu3QkX5R090IEk7QHCztd65D9UxR5VyB77eMb4UIcbgc4K0 1y1RvZf0iLWAetbYA96iOJT9XXHV4Mwt/Evsn+9Eru+l6kRYmha5Hrh65kuuxWKF EVrGgTkdzAuGkfzz5xJhEjU/35mkXZTy9nvaTzYHe8wJurnHTvTtiN9PyOavKEMO 8jh9Oq698nSdTIZqVbQ2JYKdJ6pJcdEjxELFt+v9gCPFa3T8nj2aGBryvxRFDZnb Q+GFUgq4gia1CiZJvVRgaaCeOMe4YtTf6cOFddgrRb+s2c4q4pylmySO+Irr1eiL JQpjMXx2laeXtoqiiWu2vn7TjjHkEiJey6mjgMu8w7sWxcnokvwvB28mW2k6sRoR +b6+ZduGcA3T4iC/xFm792ZyhCbRlzbQlPgcbcuS12Gv9zvcvXVssc7o9+KnzSid UlSRQuDrTptBBx3kZmNVWd+YcV2YystUfEShoSEmM7M0XXsCaSSlYuRBZMpqPEvU kQJO1VWFevu4BpPZbtq0 =/IMS -----END PGP SIGNATURE-----
