-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hugo Maxwell Connery wrote: > Hi, > > I include below the last of the 8 sections which are included in > the attached piece. I offer this to the DNSOP list for > consideration in the existing 4 proposals for special names > registration. > > I hope that people will read the full text, though you will be > bored by (and possibly complain about) the first section.
Thank you for this nice summary. > > I welcome all comments/complaints. My only complaint is regarding my previous comments at the meeting and on the ML. I feel this text is starting to deviate in essence from what I was trying to say (although I was probably not eloquent enough at the time). For the record, I shall restate my positions clearly below . > > The entirety is 1172 / 200 / 3 (words / lines / pages). > > Regards, -- Hugo Connery, Head of IT, DTU Environment, > http://www.env.dtu.dk > > -- last section -- > > More Commentary and Even More Personal Opinion > > I believe that the grothoff and appelbaum drafts are the first > cases of testing the mechanism for the use of the special names > registry. I also assume that the registry was created to be used > for more than its initial propulation with things like .local and > .invalid. > > Additionally, I agree with some members of the DNSOP community > that names matter. "my-product.invalid" is not a good way to start > a venture. Should .alt be available "my-product.alt" is far > preferrable as confirmed by a member of the I2P community both at > the Interim meeting and in later mailing list communication > (str4d). You are right in saying that .TLD.alt is preferable to .TLD.invalid from a user's perspective. But that does not automatically imply that .TLD.alt is preferable to .TLD. What I said was, if I were writing a new I2P-like application requiring a non-DNS .TLD _after_ .alt had been accepted and publicized as the accepted way of establishing non-DNS domain structures, then I would use .TLD.alt instead of .TLD, because it would be far less hassle (to get it reserved, as I expect having .alt would enable IETF to more easily evaluate and accept reservations under it) for not much additional work educating users. I would of course _prefer_ to use .TLD on its own, but as an app developer I would take the path of least resistance. Right now, that is to register .TLD under RFC 6761. If .alt is accepted, it would be that. > Indeed, that person claims that .alt would have been used if it > was both available and understood. I said that I2P would _probably_ have used it, had .alt existed at the time as the accepted way of establishing non-DNS domain structures. However, I want to ensure that these two points are abundantly clear: * I am not one of the original developers of I2P. I was not involved with I2P until years after .i2p had already been chosen and established, so I cannot speak for what they would actually have done. * Even if .alt does become available, I2P will not be transitioning to it. (This has already been thoroughly discussed previously on this ML around the P2PNames draft in general, and the .onion and .i2p TLDs in particular.) str4d > > I have little concern for the corp request, but it gains weight by > having potential operational impacts in the DNS space. As > mentioned I could not find a draft and thus have no knowledge of > its technical nature. > > I think that the key decision is appelbaum. It meets all criteria > which I list above. > > If this request cannot be processed effectively, that lack of > efficacy throws into question the entire nature of RFC6761. > > As stated, I assume that RFC6761 was well considered and that the > registry was intended to be ammended. > > IMHO, the appelbaum (.onion) proposal meets all possible standards > for approval. > > Finally, I wish to support the .alt proposal. I believe that it > is wise to create a "reading neutral" space for the > creation/testing/deployment of alternate name space communications > technologies, and in this regard I will quote Bruce Schneier from > his presentation at IETF 88: > > "Second, target dispersal. > > We were safer when our email was at 10,000 ISPs than when it's at > ten. Fundamentally, it makes it easier for the NSA and others to > collect. So anything to disperse targets makes sense." > > > > _______________________________________________ DNSOP mailing list > DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVVhVMAAoJEBO17ljAn7PgRLAP/jsLKzodu4r5VISB+pMojs9G fpC7QKQc16DRiOrsGu9U93an/BIxP7s4kzfpKPCsCveEWH+QK5UBHqoOllf5MMib nq703szES505e0RsfjDEWOwPW/lKPp91xYQZv1lOSPA76/0wBsWXka2ogDLUROnL d87e3sgO2p/L2NkH/qtd8GE5d2Ns/DsiCEAcvcy0ldqS8yRf33yaUnZQ1Uvxu8Qn ymIW356WoWsdKsinGluwtxOoZoVh3hbpcUjUvRZOCZJwVAmzgycE9kLTNIbEjvKq D/YgS9TmzFuxkMJalQHL2yBykESAyt/Zb33zZl2yeQWmZsj3/ec1tUlwdK9eXKSi eg6kWTdENVHLp8lDM4pDH8J2G3Bjxakm+pNo/pcI7KynsFWznaeEAOKaqUJbh0ro VsuKEClyGkKGDjZ7PArNAf2hyiGrerBmfV4aCq8sEIa/VU1FtThFgB+7Y+5ZlHk5 ah6RtcBNWWZjwpLmyWyZfMy49iXqt8cjBHW+F7ieJSLuCPRWVOz9xKFabfTYrULJ YPrSBWUJoaFc3yrgWMiKMSg4w3bLmvT1Y498znRplFiiroPwk5beKbMOB3A8qQhh sphaE9Ut/jcw9XSGhf9d9awa8tcpKjWBxQVbtqg8XaDsTskqrSQblapY2r5tNuxl +KDUXYQQ9mVFeQqcKbqd =ci75 -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
