Hi Donald, On 27 Apr 2021, at 22: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-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 standa rds development organizations for anything that is at all questionable. Thank you for that. I think that's helpful. There is much that is anecdotal and surprisingly informal in the way that decisions around top-level domains are made, and it is not surprising to me that this topic is difficult to address as an engineering problem. The current co-editors of this draft are not in tight agreement about the correct path forward. One of us, in fact, (not me) is waiting for public, crystal clarity from ISO about their future plans, for example. We have asked the working group in past meetings what their preference is, but I don't think we asked clearly, one of the presenters had connectivity issues during the working group slot, etc. The document is not currently clear on its approach and it is unsurprising that people are expressing a variety of discomfort. Personally, I favour the approach that if the IETF has anything useful to say it should minimise the scope of its pronouncements with the goal of balancing useful engineering with the avoidance of politics. My suggestion was that there is a logical argument here that doesn't involve assignment ("grabbing") but is still useful. Here it is: 1. Certain ISO-3166-2 codepoints are designated as being for private use by ISO and will not be assigned for use by countries, economies, etc; 2. Those ISO-3166-2 codepoints continue to be used for correspondingly-private applications in a variety of applications that have nothing to do with the DNS, so the designation from (1) is recognised and widely used; 3. ICANN does not assign two-character labels as TLDs except by reference to ISO-3166-2; 4. Use of ISO-3166-2 private-use codepoints will not clash with any TLD assigned for use in the public DNS. [So far all we have done is made reference to other organisations' policies and observations about how those policies are used. We have not assigned or recommended anything.] 5. Since the policies referred to by (1) and (3) have existed for some time in the past, it is possible that people have used these codepoints as private-use TLDs, and (perhaps more importantly) we cannot know that they have not been used in this way; [This argument makes no assumptions about ICANN or ISO policy in the future; it simply observes that certain policies have existed in the past.] 6. Collisions between private-use namespaces and the public DNS namespace are harmful; 7. The IETF restricts future use of these code-points in protocols in order to avoid the possibility of collisions: the public DNS namespace should not include these code-points. This argument, I think, opens the door for the IETF to say something useful but does not need to predict future policy decisions by other organisations or impinge on any other organisation's policy agenda: the IETF retires code-points all the time because they have been burnt in the wild, and this is just another example. I think even without declaring these code-points to be assigned for private use in the DNS, such a document would be sufficient to document their use for that purpose and to be explicit that such use will continue to be possible and safe from collisions with the public DNS namespace. As I mentioned earlier, this is just my opinion of how to proceed. The current draft contains a mixture of various approaches and the result, I think, is unsatisfying. I am very prepared to be wrong here, however, and I am trying hard to express myself without pushing any particular agenda :-) Joe _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
