Colleagues Please find below a note from John Klensin which sets out further historical and more current reserved names discussion. This is particularly relevant for the volunteers for the Reserved Names Working Group. Kind regards. Liz ..................................................... Liz Williams Senior Policy Counselor ICANN - Brussels +32 2 234 7874 tel +32 2 234 7848 fax +32 497 07 4243 mob Begin forwarded message:

From: John C Klensin <klensin@jck.com> Date: Sat 20 Jan 2007 14:17:14 GMT+01:00 To: Liz Williams <liz.williams@icann.org>, "Vinton G. Cerf" <vint@google.com>, Alejandro Pisanty <apisan@servidor.unam.mx>, steve@shinkuro.com Subject: FWD: Re: [registrars] Request for Reserved Names WG Volunteers

Hi.

Just FYI. Please feel free to distribute further as you think appropriate. Since ICANN technical staff has still, as far as I know, not changed the "we just discard mail" feature, I don't even know if this reached the registrar list.

john

From: John C Klensin <klensin@jck.com> Date: Sat 20 Jan 2007 14:11:11 GMT+01:00 To: brunner@nic-naa.net Cc: Bruce Tonkin <Bruce.Tonkin@melbourneit.com.au>, Registrars Constituency <registrars@gnso.icann.org>, "Gomes, Chuck" <cgomes@verisign.com> Subject: Re: [registrars] Request for Reserved Names WG Volunteers

--On Friday, 19 January, 2007 20:57 -0500 brunner@nic-naa.net wrote:

...

John,

Your note on the subject of single octet labels was forwarded to the ICANN RC mailing list, where I saw it.

...

When Donald, Bill and I wrote 2929 we also considered the in the context of IANA Considerations for DNS Resource Records, the RR NAME included.

That is certainly consistent with my recollection of discussions at the time.

...

At the time, there were no ICANN considerations, and no IDN, so the whole mistake of Unicode hadn't yet happened.

I no longer have the correspondence that circulated between Donald and I in particular, but we had some discussion related to the issue, circa 1999/2000, which is observable in the lack of overspecification for the values of octets used to construct lables (Section 3.3), and the care we took to document the RR CLASS (Section 3.2).

If memory serves, Donald wanted to nail down the US-ASCII values for each octet, and prevent any octet sequence other than the iso3166 and c/n/o sequences from ever being available for allocation.

...

I think I made the case for future extension that might use values other than .-0-9A-Za-z, and that lables might be made from sequences not in the two-octet (iso3166) or three-octet (c/n/o et al) string spaces.

As you may recall from discussions about RFC2181 a few years earlier, my personal position has been is that the "recommended" text about contents and structure of labels in 1035 should be read as a requirement for RR types specified in 1034/1035 and as more fuzzy only for new Classes and possibly new RR types within Class=IN that specify different rules. That probably puts me, again personally, closer to Donald than to you, but, as you know, I've always been very conservative on this issue, and...

Going back much further, 1123 relaxed the rule against leading digits which was originally instituted to prevent confusion with host numbers (later IP addresses), there was some discussion about whether to explicitly continue to ban all-digit labels. Those of us who don't like look-ahead when it can be avoided would have preferred to retain the prohibition; others felt that looking ahead for four putative labels to see if any non-digit characters appeared was reasonable and that the prohibition was not needed. I can't recall whether there was actually consensus around the latter or whether we just gave up and omitted an explicit rule, but 1123 did end up with an aside about numeric TLDs.

When 1591 was finally written to make fairly long-term practice explicit and more easily available, we discussed TLD naming and whether to include specific rules there. At that time, Jon considered the odds of adding new TLDs, other than those in the 3166 set, to be very low and, if I recall, didn't want to clutter up the text with contingencies, but there was general understanding that

(1) there would be no single-letter TLD names

(2) there would be no TLD names with numeric components (unless ISO introduced them into the 3166 space) and certainly no TLDs starting in digits.

(3) all (additional) two-letter TLD names would be derived from the primary 3166 list, with no further nonsense about "certainly going to be approved", reservations, etc.

(4) any additional gTLDs would have three-character names

(5) four-character gTLD names were to be exclusively "ARPA". I suppose that, in principle, something else connected to a distinct network, might have been created with a four-character name, but we certainly didn't spend time talking about it. By "another network", I'm not referring to topology or connectivity or protocols (as you will recall, ".uucp" and, for that matter, ".csnet" and ".bitnet", were in active use at the time, but as notation within those networks, not in the DNS root), but something really different... I guess I'm having visions of ".MARS" for an infrastructure domain for a network on that planet.

(6) there were to have been _no_ TLD names with five or more letters.

These kinds of firm naming rules aid users and application software in detecting nonsense, producing good presentation forms and error messages, and preventing repeated queries for the impossible. Whether those benefits are sufficiently important to overcome the desire to commercialize one seemingly-attractive string or another is a balance that ICANN needs to figure out how to resolve, preferably after considering the needs of the widest range of materially concerned parties possible rather than only short or medium-term commercialization interests.

Of course ICANN blew the last two rules off in 2000, with no discussion at all. Suggestions that ICANN warn applicants that there was applications software that incorporated those rules and hence might make their domains inaccessible were rejected by staff.

...

Which begs the question of what John's intent was, or whether I then, or ever, have had the smallest part of a clue.

Of course, at that point in time, we weren't trying to see characters through the blinders of font fanatics, so phishing was limited to il1 and o0O bits of nonsense which policy, at either the registry, or the registrar or the zone file publishers, could have (and at times did) interposed upon.

Exactly. As has been pointed out many times, the "confusability" problem introduced by IDNs is, at one level, no different from the ones we have had, in principle, with ASCII since the dawn of the hostname table. However, addition of hundreds or thousands of new "opportunities" with IDNs arguably changes the problem from one about which those involved needed to exercise moderate caution to one that no user is able to fully understand and protect against, making an extremely strong case for some precautions in the registration/zone-entry process lest we essentially put referential integrity at the mercy of the phishers and other Bad Guys.

And, has also been noted multiple times (albeit without much effective success), IDNs --especially any ideas or plans about IDNs at the top level-- also require that we go back and reinterpret and adjust all sorts of rules and conventions that assumed ASCII, LDH, labels. The two most obvious examples involve the questions of what goes into domain registration ("whois") records and how they are indexed and whether such "reserved name" rules as the restriction against single-character names apply to the presentation form or to what is stored in the DNS. The latter question is what makes the single-character prohibition particular important at this time: if the motivation for that prohibition really had been an idea about future expansion, then IDNs would be irrelevant since the form stored in the DNS is always more than four characters long. On the other hand, since the prohibition was imposed because of human factors and retrieval considerations, it should probably apply to the presentation ("native character", "Unicode") form of IDNs.

best regards, john