Having now read further I am pretty convinced that the advisory is not useful in the context of this thread discussion. Ist sais at the end that [1] was the "impetus" for the advisory. However, [1] states that
"Why not use .alt? The proposed .alt presudo-TLD is specifically only for use as a pseudo-TLD for non-DNS resolution contexts. At one point .alt was being considered both for DNS and non-DNS resolution contexts, but, after much discussion it was decided that the DNSSEC implications (and desired behavior) meant that .alt should be reserved specifically for non-DNS resolution." and " Why not use something.arpa? This is indeed an interesting idea. I suspect that it fails the semantically desirable / understandable case, but is definitely worth further discussion. It may also cause issues when server operators override part of the .arpa domain in order to instantiate something.arpa. " So, I am pretty sure we are back to square one and this advisory (or rather its result) is specifically NOT meant for systems like GNS. In fact, I would even argue that the advisory itself argues that this work is supposed to be done by IETF (see page 5 of the document): " In this document, the SSAC limits its discussion to private-use TLDs intended for use with the DNS protocol and for private use only. Many private-use TLDs, such as .onion and .gnu, do not use the DNS protocol or DNS infrastructure. The reservation and usage for such TLDs would require special handling and is not discussed in this document; there have been efforts in the IETF to address them. " While I must admit that I am a bit ignorant when it comes to what is considered official ICANN position, at least the authors of this advisory seem to think that private TLDs not meant for DNS resolution should be/can be/are(!) worked on by the IETF. [1] https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-internal-00#section-3 BR > On 2. Aug 2022, at 22:09, Martin Schanzenbach <mschanzenb...@posteo.de> wrote: > > Signed PGP part > I just read it and on page 5 it specifically excludes .onion and .gnu as > those do not use the DNS protocol (citing also the alt draft here). > So this is equivalent to the .alt draft only if the private-use TLD is > not limited to private-use DNS queries as investigated in the document. > I find this to be quite odd as I thought this is what .arpa was for > (RFC8375)! > .home is even listed in the table of the SAC document and one of the > motivations. > > So, we would have to see what the actual proposed *use* of this private > TLD would be. If it is limited to DNS, then it is of no use for > alternative name systems and we would still need .alt. > > Excerpts from Andrew Sullivan's message of 2022-08-02 15:34:40 -0400: >> Disclaimer: I work for the Internet Society but I am not speaking for them. >> >> On Tue, Aug 02, 2022 at 07:11:38PM +0000, Paul Hoffman wrote: >>> >>> recommends that the ICANN board to pick a string that will never be put >>> into the DNS root, and thus is usable for systems like GNS. >> >> This was, of course, the whole point of the .alt draft in the first place, >> at least when I was involved in preparing it. I don't think any of us >> involved then cared whether it was alt or one of thousands of other strings >> that it could have been. The main point was to come up with something that >> would not pad total length too much and that could be a clear "protocol >> switch". The registration in the IANA sutld registry was suppossed to >> ensure the same outcome as what is going through SSAC, but it makes no >> difference to me what the characters are. Note that because of the >> old-timey restriction, I suspect the characters must all be alphabetic, >> though perhaps that rule has been superseded by IDNA. >> >> A >> > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
