On Tue, Mar 08, 2016 at 02:09:12PM +0000, Alain Durand <[email protected]> wrote a message of 207 lines which said:
> draft-adpkja-dnsop-special-names-problem-01 has been posted today. [One warning: I think the entire idea is bad. There is no "problem" to solve, we have RFC 6761 and it works (it worked for Apple, it can work for free software like GNUnet). I do not object to an effort to create a 6761-bis, addressing lacks like the absence of a mailing list designated to review the proposals like it exists for URI schemes, media types, etc.] > The authors know that the subject addressed in this document is > controversial. We hope it will help clarify the discussion. In many > places, we know different opinion exits. We have tried to reflect > the existence of those opposition views to the best of our > possibilities. I cannot say it was successful... Quite the contrary, the draft tries to do too much, by mentioning everything the authors can think about against RFC 6761, sometimes without a serious evaluation. An example is mentioning that Tor is a non-IETF protocol, as if it should make any difference. > This means that these names can be entered in any application which > takes exiting DNS names. The draft speaks sometimes of DNS names, sometimes of domain names, and does not explain if there is a difference. Clearly, a DNS name uses the DNS so 7j3ncmar4jm2r3e7.onion is *not* a DNS name (it is a domain name). [I agree with Paul Hoffman that a section explaining the difference, and the constraints on DNS names, would be useful.] > More over, the answers to the seven questions are not available in a > machine readable form to applications that want to follow [RFC6761]. It's funny, it is one of the few points where there is clearly something lacking in RFC 6761 and it just deserves one sentence. I would prefer to see dnsop working on addressing this issue, than on trying very hard to close to door to new TLDs. > The discussions in the DNSOP WG and the IETF Last Call processes > about the .onion registration in the Special Use Domain Names > registry (1,200 messages) have made it apparent that clarity about > if and how to treat this "protocol switching" practice would help a > lot I don't think the number of messages is a good metric. The issue is hot because names are sensitive and because of the heavy politicization of the subject, this is why there have been so many messages, not because RFC 6761 is not clear. > What is missing in [RFC6761] is the consideration of the name > itself. If one were to contrast the procedures relating to the > admission of a name to the IETF Special Use Name registry to the > processes associated with the New gTLD Program operated by ICANN, > then it is evident that the IETF process does not admit many > considerations which appear to be areas of evaluation in the new > gTLD program. I would not mention the ICANN processes as an example, far from it. "ICANN has a heavy and political and complicated process for this, so we must not attempt to do it if we don't have such a process." > They refer to bad precedents such as .uucp and .bitnet. In what way were there "bad"? Instead of labelling software with such terms, one should explain, and draw real lessons from experience. .bitnet and .uucp were big successes, the software behind it disappeared but they were not "bad". > For example, is large scale prior deployment an acceptable criteria? > A number of voices have clearly answered "no" to that question as it > would only encourage "squatting" on names. The draft carefully forgets to mention that many people objected to .gnu, .zkey and .i2p on the basis of insufficient deployment. People outside of the IETF who brings things to the IETF receive an extremely unfriendly welcome, with strong requirments to do one thing and its complete opposite. > String similarity ICANN has an entire process for evaluating the > string similarity / confusability between applied for (and current) > strings Which is a complete failure (such as Eurid being refused a name under the pretext that it collides with a name... which is not even delegated.) Good thing it does not exist at IETF. https://centr.org/system/files/agenda/attachment/ga55-seppia_idn_delegation-20160217.pdf https://centr.org/system/files/agenda/attachment/ga51-seppia-similarity_perception_at_icann-20140313.pdf http://domainincite.com/17538-bulgaria-and-greece-win-idn-cctlds-on-appeal > However, it should be noted that, if the IETF were to formalize the > concept of protocol/name switch in the Internet architecture, > coordination would be require between ICANN and IETF on such names. > Using the analogy described above of a catalog/registry of such > switches, care must be taken to make sure we do not end up with 2 > process streams allowed to create entries without any > synchronization. This is probably one of the weakest arguments. The processes of ICANN and IETF are slow, very slow. And a good part of them is public. And many people follow both (and we have a formal liaison to ICANN). The risk of a collision (between an ICANN delegation and an IETF reservation) is nil. These were remarks on the actual text. There is also something completely missing: whatever we decide, people will deploy new TLD. We will have to live with it, anyway. (Someone at the IESG during the .onion decision said "we must make our processes work for the Internet, not the other way around". Internet is permission-less and this is a good thing.) Now, the technical issues: > The names can follow the common DNS syntax of LDH labels, The DNS does not restrict labels to LDH. And the editorial ones: > the reserved names could be any label in any random string, not just > the rightmost Last, not rightmost (some scripts are right-to-left). I know, the RFC are in english, that's why I put that under "Editorial", not "Technical". > would be require Would require or would be required? _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
