Hi, FWIW our draft [1] which is currently in IESG conflict review is related to this "issue". Namely, the question of namespace ambiguity is discussed in it [2] as we were unable to register a Special-Use TLD in the past [3] (as some of you may remember). There already have been discussions with the ISE regarding this property as well. We currently see three options for our draft:
1. Leave it as is since it is an "informational" document and describes the current implementation, possibly leading to a negative conflict review response (?). 2. Use a special-use TLD (which would need to be requested again as per RFC 6761 with uncertain outcome). 3. Use this approach although I am not particularly happy with the lack of a registry for the labels beneath ALT and the resulting length of the names. To me, the purpose of this draft is a bit unclear if RFC6761 exists and can be followed and (at least in theory) we could just have special-use TLDs for alternative name systems (see 2.). OTOH, although possibly a bit of sacrilege here, maybe it is also a chance to think about a "DNS-NG". New alternative name systems may be specified and tested without a hard requirement on sub-namespaces, but a soft-requirement for namespace unambiguity within their deployments. Because possibly/eventually they may be able to replace the current DNS and resolve its names. For our draft, the question is if a special TLD must/should be specified along with the protocol specification or if we can just discuss namespace ambiguity and possibly use a "temporary" deployment and testing namespace (e.g. "gns.alt" or "whatever you want but beware the DNS dragons"). BR Martin [1] https://datatracker.ietf.org/doc/draft-schanzen-gns/ [2] https://www.ietf.org/archive/id/draft-schanzen-gns-19.html#name-namespace-ambiguity [3] https://datatracker.ietf.org/doc/html/draft-grothoff-iesg-special-use-p2p-names-04 > On 27. Jun 2022, at 22:29, Michael StJohns <m...@nthpermutation.com> wrote: > > It's either time to put a stake through the heart of this DNS vampire that > rises from the grave every 6 months, or to push it for publication. Given > that in 8 years it has yet to gain enough traction for publication, perhaps > we de-adopt the draft back into the caring hands of its author? E.g. - back > to draft-kumari-something. Or contribute to some flowers for a final burial? > > In any event, having looked at this for the first time thanks to the > announcement, and reading the proposed use, why isn't this reserving > something like "%ALT" or some other string containing an illegal DNS > character? > > Later, Mike > > > On 6/14/2022 3:51 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 WG of the >> IETF. >> >> Title : The ALT Special Use Top Level Domain >> Author : Warren Kumari >> Filename : draft-ietf-dnsop-alt-tld-15.txt >> Pages : 11 >> Date : 2022-06-14 >> >> Abstract: >> This document reserves a string (ALT) to be used as a TLD label in >> non-DNS contexts. It also provides advice and guidance to developers >> developing alternative namespaces. >> >> [Ed note: Text inside square brackets ([]) is additional background >> information, answers to frequently asked questions, general musings, >> etc. They will be removed before publication. This document is >> being collaborated on in Github at: https://github.com/wkumari/draft- >> wkumari-dnsop-alt-tld. The most recent version of the document, open >> issues, etc should all be available here. The authors (gratefully) >> accept pull requests. ] >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-alt-tld-15 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-15 >> >> >> Internet-Drafts are also available by rsync at >> rsync.ietf.org::internet-drafts >> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop