Re: [DNSOP] Questions on draft-ietf-dnsop-private-use-tld-01.txt

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
 d3e3e3@gmail.com

On Fri, Apr 16, 2021 at 11:18 AM Paul Hoffman <paul.hoffman@icann.org>
wrote:

> On Apr 16, 2021, at 5:31 AM, Andrew McConachie <andrew@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
>