Hi Donald,

> On 28 Apr 2021, at 03:34, Donald Eastlake <d3e...@gmail.com> 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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to