--On Friday, June 30, 2017 09:59 -0400 Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, Jun 30, 2017 at 07:31:58AM +0200, Olivier MJ > Crépin-Leblond wrote: >> Hello all, >> >> I am reading RFC1591 and RFC3071 and have a couple of simple >> questions: 1. Is a ccTLD defined as restricted to 2-letter >> country codes (ISO3166 alpha 2), or could that include >> 3-letter country codes in the ISO3166 list (ISO3166 alpha 3)? >...(I believe that the traditional resistance to adding > _any_ 2-letter TLD, even if it's not on the 3166 list, comes > from the possibility that a new country will happen that could > collide with such a 2-letter TLD. The ISO list isn't static, > and simply reserving everything in the space seems prudent. Exactly. Even using codes that 3166-1 designates as "private use" is dangerous because there is not reason why some future version to the standard might not press those codes into use if the available code space becomes limited (more likely since the p9licy as to how long 3166/MA needed to wait before reallocating a code that was no longer used was expanded from five years to some really long period). It is worth being explicit about something Andrew implies. If XX were to be delegated to some non-country entity and then a country comes along and is assigned that code by 3166/MA, there is an immediate and nasty crisis because there is no model for allocating any other code to the country and whatever entity had been delegated XX would certainly object to having it taken away and presumably having all of its registrations cancelled. Many pre-ICANN IANA policies were designed around avoiding, rather than encouraging, such problems. > will not comment on the wisdom of adding "country codes" that > are not on the 3166 2-letter list, except to note the text in > 1591, "The IANA is not in the business of deciding what is and > what is not a country." While there was another reason for that statement, yes. 3166 was chosen both because it provided an explicit list of entities that could request/ register ccTLDs and because it avoid arguments about what the country code/ label should be, with neither decision requiring IANA involvement. I've mentioned several times in various discussions that IANA resisted sending even an observer to 3166/MA until well after the transition to ICANN because Jon didn't want anyone to be able to try to demand that he propose adding a country-entity and code to 3166 in other that a TDL could then be registered. >> 2. RFC1591 appears to point at 2-letter, but many other parts >> of this RFC are obsolete - so does this RFC remain valid? > > I am not sure what you mean by "parts of this RFC are > obsolete". There does not appear to be any RFC that obsletes > or even updates RFC 1591. > > What of course is true is that there is a community that has > taken over the policy role for the root zone, and it might be > that that community regards some of the text as obsolete. As > I pointed out repeatedly to colleagues around ICANN during the > preparation for the IANA transition, 1591 is not holy writ. > People could update or obsolete it at any time by using the > normal processes for obsoleting or updating an RFC. There is > the small problem of who has change control over RFC 1591, > since it is not obviously a product of the IETF and looks like > it might have been a product of IANA. yes. If definitely was. I assume the IAB could have objected had they wanted to, but that not only would have set of some sort of constitutional crisis but, at least based on what I was told at the time (much earlier than 1591), part of the reason for establishing IANA as an entity was to keep IAB members insulated from allocation decisions in order to avoid all sorts of potential conflict of interest and antitrust problems. > More likely, since > ICANN is in the business of making policies for the root zone > anyway, ICANN could simply issue a new document that it says > it will follow, and publish a statement that for its policy > purposes RFC 1591 has been superseded by $document(s). Of course, ICANN did issue a document that more or less explicitly updates 1591 in the form of the May 1999 ICP-1. Of course, rather than obsoleting 1591, it references it and essentially reaffirms it. It even includes the "trustee for the domain" and "obligation to serve the community" language. > I got the impression, however, during those conversations, that > several people prefer the current ambiguity because it allows > for divergent opinions, with each opinion holder able to cite > some document. Whether this is because there is an unresolved > difference of opinion that is hidden behind such appeals, or > whether some people just like to have something to argue about > so they can go to meetings, I cannot say. No comment. best, john p.s. In case it is relevant, I was very actively involved in the development and text of 1591 and some other IANA policies during that period.