[DNSOP] Fwd: Questions about the used of ISO 3166-1 user defined codes

[Suzanne Woolf <[e-mail]>]

Dear colleagues,


The internet-draft draft-ietf-dnsop-private-use-tld, adopted by the WG late last year, includes text that would create entries in the IANA Special-Use Domain Names registry for certain ISO 3166-1 two-letter codes that have been labeled by the appropriate ISO agency as “user-assigned”, formally "ISO 3166-1 alpha-2 User-assigned Code Elements”. The chairs requested guidance on whether this was an appropriate use of another standards body’s work (not an unusual step when an IETF RFC proposes to include elements or properties of another organization’s standards, especially a standards-track RFC).

Liaison relationships are managed for the IETF by the IAB, which conveyed our questions to John Klensin as the liaison manager for the IETF’s relationship with the ISO-3166 maintenance agency.  Below we’ve forwarded his comments on the response to the IAB’s questions.

Please note that this communication is from the official IAB liaison to ISO/TC46. Please note also that in his view, based on lengthy experience and recent conversations, there will be no formal response from ISO regarding the questions the IAB posed on our behalf in the liaison communication at https://datatracker.ietf.org/liaison/1720/ <https://datatracker.ietf.org/liaison/1720/>, because there’s no mechanism for one to be created. (This explanation appears under item 1, starting with the second paragraph.)

However, even if we leave the question open of whether there will be further response to the liaison request from the IAB, it’s the case today that the note below from John is the response we have, and it does contain some guidance for the WG. We will discuss further in Thursday’s meeting.


Best,
Suzanne
For the DNSOP chairs

> Begin forwarded message:
> 
> From: John C Klensin <[e-mail]>
> Subject: Questions about the used of ISO 3166-1 user defined codes
> Date: July 23, 2021 at 6:58:42 PM EDT
> To: [e-mail]
> Resent-From: <[e-mail]>
> Resent-To: [e-mail], [e-mail], [e-mail]
> 
> DNSOP Chairs,
> 
> I am writing in my capacity as liaison to ISO/TC 46, the
> Technical Committee responsible for the ISO 3166 Standard and,
> via its WG 2 and 3166/MA groups, the development and
> maintenance of that Standard. It is probably worth noting that
> I have additional perspectives on the use of the ISO 3166 (now
> 3166-1:2020 [1]) alpha-2 code space in the DNS having, among
> other things, been part of the original discussions leading to
> the decision to use those codes for DNS ccTLD purposes. I was
> then part of what became known as the IDNB when RFC 1591 was
> published and until the handoff of IANA DNS responsibility from
> USC-ISI to ICANN.
> 
> The IAB sent a liaison message to TC 46 about the questions
> raised by the proposal for use of user-assigned code points as
> suggested by draft-ietf-dnsop-private-use-tld (referred to as
> "the Arends et al.I-D" or just "the I-D" below). I was
> instructed by the IAB to follow up on that communication.  I
> have done so.  The notes below are a summary of discussions
> with ISO/TC 46 and ISO/TC 46/WG 2 leadership and the responses I
> received.   They also reflect my effort to put parts of those
> responses into a context that reflects similarities between ISO
> and IETF procedures.
> 
> The issues appear to me to come down to two key questions. In
> addition to those questions, which relate to the interpretation
> and use of ISO 3166-1, there are also some additional issues
> that involve long-established principles about the use of the
> two-letter DNS TLD space and the reasons for them; they are not
> addressed in this note. 
> 
> 
> (1) Is using the user-assigned code space of the 3166 alpha-2
>   namespace for this purpose consistent with the intent of the
>   standard?
> 
> Summary answer:  No.  Also terms that IETF considers equivalent
>     may not be equivalent elsewhere.  Details follow.
> 
> My reading of the Standard, confirmed by discussions with the
> ISO Technical Program Manager for TC 46 and the Chair of 
> TC 46/WG 2, is that it is clear that both the user-assigned
> space and the various reserved lists are for use by countries
> and country-like entities in situations were country codes
> would be appropriate and needed and not for other purposes. I
> am guessing that the provisions in the Arends et al. I-D result
> from confusion that conflated "user-assigned" as used in ISO
> 3166-1 with "private-use". The IETF often uses the two terms
> interchangeably, both meaning that the relevant standard has
> nothing to say on the matter and that people are free to use
> code points thus designated for any purpose they consider
> suitable.  That is not the case with the definitions of ISO
> 3166-1: the private Internets contemplated by the I-D are, as
> that draft makes clear, not the country-like entities
> contemplated by the ISO Standard.
> 
> It is important to note that, like the IETF, ISO has no
> mechanisms to offer official interpretations of a published
> Standard other than going through the full process of reaching
> consensus on an amendment, update, or replacement of the
> Standard. If a document were actually unclear and the ambiguity
> were important, the only course of action would be to initiate
> a process to fix or replace it. In the case of ISO 3166-1:2030,
> I do not believe it is unclear and I have seen no indication
> that anyone associated with ISO/TC 46 sees ambiguity either.
> 
> Although there are difference in procedures, he principles
> above are just like the IETF situation: even when errata
> reports are filed and approved by the IESG, the Standard itself
> does not change until it is updated or replaced by publication
> of an I-D, processing via an IETF Last Call (and whatever steps
> lead to it), and approval of the document by the IESG based on
> the consensus in the community as expressed in responses to
> that Last Call. So, for those who would like an official,
> formal, recorded decision by TC 46 that the use suggested in
> the Arends et al, I-D is appropriate (or not), you should not
> expect it, any more than a WG or the IESG would be expected to
> respond to a similar request about one of our standards track
> documents 
> 
> 
> (2) Will ISO guarantee that the current user-assigned code
>   space will not, in the future, be allocated to some other
>   purpose in some future version of the standard?
> 
> Summary answer:  No.  Details follow.
> 
> Analogies to IETF procedures and practices are appropriate here
> as well. Various people may have opinions about the likelihood
> of a change in some list. Sometimes we even write those
> opinions into a spec, explaining why no changes should be made
> in a particular area. Reasonable people might make predictions
> based on such statements and their ideas of good sense.
> However, we cannot guarantee that some future version of a
> standard will not change some of the properties of an earlier
> one. To take one of the more extreme examples I can think of,
> there is nothing in the IETF procedures that would prevent a
> future replacement for RFCs 1034 and 1035 from reassigning the
> port number for DNS queries or the RRTYPE codes for widely used
> record types. Our protection against such possibilities is that
> a change would be sufficiently disruptive to have no chance of
> getting community consensus (at least I hope it would not), not
> because someone can stand up and say "we guarantee". 
> 
> I would be happy to discuss this further as appropriate but
> note that I am not on the DNSOP mailing list and have not
> participated actively in IETF DNS work in many years. There
> have been a few exceptions when my attention has been called to
> a particular issue but they are exceptions.
> 
> regards,
>   John
> 
> 
> [1[ https://www.iso.org/standard/72482.html
>