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

[Roy Arends <[e-mail]>]

Hi Donald,

> On 28 Apr 2021, at 03:34, Donald Eastlake <[e-mail]> wrote:
> 
> 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-eastlake-2606bis/>
> https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/ <https://datatracker.ietf.org/doc/draft-ellermann-idnabis-test-tlds/>
> https://datatracker.ietf.org/doc/draft-ietf-dnsind-local-names/ <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.

Ack. See https://datatracker.ietf.org/liaison/1720/ <https://datatracker.ietf.org/liaison/1720/> to solicit that effect.

> That may have been an earlier era but I think John Postel's position should still have some weight.

I agree.

> 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.

I agree. 

Asking the ISO for a clarification in the form of a liaison statement is an important first step. It indicates that the IETF is aware of these specific UA code elements, and is willing to ask clarification on them, and respects the organisation responsible (the ISO) for these code elements. Following established diplomacy between the IETF and the ISO on this specific matter is IMHO preferable and more inclusive over either sitting in fear and do nothing, because “ISO or IANA may get upset if we (the IETF) do this", or worse, that an emboldened IETF DNSOP WG unilaterally decides that these elements are just like “code elements” and should be “retired” (put on a "do not delegate” list), which IMHO would create unnecessary frustration between various organisations.”

The liaison ( https://datatracker.ietf.org/liaison/1720/ <https://datatracker.ietf.org/liaison/1720/>  ) send by the IAB to the ISO is IMHO a clear indication that a path of diplomacy is preferred over unilaterally retiring code elements.

The working group can (after a potential clarification from the ISO about the future status of code elements) decide if a subset suffices and if so, the composition of the subset.

Warmly,

Roy