On Sun, Sep 25, 2016 at 1:48 PM, hellekin <helle...@gnu.org> wrote: > On 09/12/2016 11:57 AM, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations of the IETF. >> >> Title : The ALT Special Use Top Level Domain >> Authors : Warren Kumari >> Andrew Sullivan >> Filename : draft-ietf-dnsop-alt-tld-05.txt >> Pages : 10 >> Date : 2016-09-12 >> >> Abstract: >> This document reserves a string (ALT) to be used as a TLD label in >> non-DNS contexts or for names that have no meaning in a global >> context. It also provides advice and guidance to developers >> developing alternate namespaces. >> > > Finally I read this draft after I realized the presence of this "or" in > "... in non-DNS contexts *or* for names that have no meaning in a global > context." > > I must apologize for staying on > https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-04 and not > reading anymore of this draft, as it was explicitly stating the following: > > "The ALT label MAY be used in any domain name as a pseudo-TLD to signify > that this is an alternate (non-DNS) namespace." > > And: > > "Currently deployed projects and protocols that are using pseudo-TLDs > (for example, the ".onion" pseudo-TLD (and other labels in > [I-D.grothoff-iesg-special-use-p2p-names]) are encouraged but not > required to move under the ALT TLD. Rather, the ALT TLD is being > reserved so that future projects of a similar nature have a designated > place to create alternate resolution namespaces that will not conflict > with the regular DNS context." > > Yet, this explicit recognition of existing name requests for P2P systems > was removed from the next draft on, and is obviously absent from the > current draft-ietf-dnsop-alt-tld-05.txt, which implicitly declares the > special-use names of P2P systems as falling under .ALT. Since this > draft is reserving the .ALT TLD using RFC6761, and there's an ongoing > discussion about this RFC to figure out a proper way to use it, update > it, or dismiss it, I find the situation unacceptable. Please correct me > if I'm wrong, but it really seems to me that this is the case, and that > the .ALT draft, which wasn't meant to threaten the history of the P2P > names, indeed became a way to easily dismiss any further discussion > about them.
This document is not intending to stop discussion of the P2P names. In my opinion, discussions on those is orthagonal to these. If .ALT is created and any of them are able to AND would like to, they can move under .ALT. One of the main things that we seem to have learned from the Special Use Names discussion is that we are not the DNS police. There is nothing that we can do to prevent somebody from "squatting" on a string. The only thing we can do is provide a sandbox for those who would like to use it, which will not collide with delegated TLDs. The .ALT draft is still parked and so we are not making significant changes to it at the moment. Once it is unparked, we are happy to incorporate the working group's desires and text. In deference to the chairs, let's not open these discussions at the moment. (We believe this will be unparked soon.) It's been a really long time, but IIRC, we removed the mention of the P2P names because we thought you wanted that -- somewhere around this whole discussion: https://www.ietf.org/mail-archive/web/dnsop/current/msg13338.html My opinion really doesn't matter, but I happen to think that, at this point, we should evaluate the requested P2P names according to RFC 6761 -- you followed the process in effect *at the time*, and jumped through many hoops. The process is far from perfect (see draft-tldr-sutld-ps) but that *was* the process at that point, and so your drafts should (IMO) be evaluated against that. If the IETF had been able to quickly and clearly come to consensus that the process was broken, and what to do to fix it, I might feel differently, but changing the rules retroactively feels unfair. Interestingly enough, just above that mail, Stephane also objected to "pseudo-TLD", but we asked the WG for a better term and (IIRC), didn't get any better suggestions: "Can you suggest a better term (noting that this term is used in both RFC6761 and draft-grothoff-iesg-special-use-p2p-names-04)? They are things that look like TLDs when leaking into the DNS context, but are not actually TLDs. This seems to be a very common term, and was not intended to be perjorative, see for example: RFC6761 - Special-Use Domain Names (https://tools.ietf.org/html/rfc6761) Section 1: "This is typically done by stating that any fully qualified domain name ending in a certain suffix (i.e., falling within a specified parent pseudo-domain) will receive the special behaviour. " draft-grothoff-iesg-special-use-p2p-names-04, Section 3 (Terminology and Conventions Used in This Document): "The abbreviation "pTLD" is used in this document to mean a pseudo Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761] reserved to P2P Systems in this document." RFC1429 - Listserv Distribute Protocol, Section 3.3: "You can use the pseudo-domain ".BITNET" for BITNET recipients: it is always supported within DISTRIBUTE requests." RFC1849 - "Son of 1036": News Article Format and Transmission (Historic): "The pseudo-domain ".uucp" MAY be used for hosts registered in the UUCP maps ...." 'Measuring the Leakage of Onion at the Root “A measurement of Tor’s .onion pseudo-top-level domain in the global domain name system”' - Matthew Thomas and Aziz Mohaisen. https://www.petsymposium.org/2014/papers/Thomas.pdf " > > Regards, > > == > hk > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
