I am not comfortable with grabbing all the permanently unassigned 2-letter country codes for DNS private use.
Note: I was the primary author of RFC 2606 and have been involved in this sort of thing before. See https://datatracker.ietf.org/doc/draft-eastlake-2606bis/ https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/ https://datatracker.ietf.org/doc/draft-ietf-dnsind-local-names/ At one early point I considered the addition of a number of additional TLDs for testing purposes to the draft that became RFC 2606 including, as I recall, one that was 63 octets long and a number 2-letter codes taken from the permanently unassigned 2-letter ISO country codes. John Postel rejected such efforts and in particular, if I recall correctly, indicated that as IANA (at the time when essentially all registries were Expert Review and John was the universal expert) he would reject any effort to assign any DNS use to any ISO 2-letter code, other than as a national country code, unless a liaison was received from ISO explicitly permitting such use regardless of public statements by ISO that ISO would not assign a use to such any or all such code in the future. That may have been an earlier era but I think John Postel's position should still have some weight. And I would note that more recently, the IESG has wanted a liaison to be crystal clear about permissions from other standards development organizations for anything that is at all questionable. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 2386 Panoramic Circle, Apopka, FL 32703 USA d3e...@gmail.com On Fri, Apr 16, 2021 at 11:18 AM Paul Hoffman <paul.hoff...@icann.org> wrote: > On Apr 16, 2021, at 5:31 AM, Andrew McConachie <and...@depht.com> wrote: > > > If I understand section 4.3 correctly, DNSSEC validating stub resolvers > SHOULD NOT resolve these names. Is that the intention of Section 4.3? > > No, definitely not. The text says: > 3. Name resolution APIs and libraries SHOULD NOT recognise these > names as special and SHOULD NOT treat them differently. Name > resolution APIs SHOULD send queries for these names to their > configured caching DNS server(s). > Not recognizing them as special means to treat them like any other name. > There is no mention of DNSSEC. > > > Why reserve so many names for a singular purpose? If human semantics are > irrelevant then why not just pick a name at random and reserve that one? > There may come a time in the future where one of these names might be > useful for something else. > > The question of "why" is a good one. There are two extremes: > > - All these labels are equivalent, so the WG should just allow one to be > used. > > - These labels have different semantic properties to different people, so > let them choose freely among the set. > > This hasn't been well-discussed in the WG. My personal preference is the > latter (which is what is in the draft) because names and abbreviations > matter, whether or not we techies like that. There is no technical downside > to the list being large but bounded, I think. > > --Paul Hoffman_______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
