Re: [GNU/consensus] Fwd: An Update from the Name Resolution Trenches

[hellekin]

-----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-----