I suspect I am going to regret asking, but how is this a "slippery slope", and why should anyone be against it? Perhaps more to the point, why should the IETF have any interest whatsoever?
May be should I respond this as I do agree with "slippery slope" and I am known to support a far wider number of TLDs. Also because I think the issue is crucial.
First, I am afraid John is wrong when he refers to RFC 1591 as having started it. Actually Tim is right : it has not started yet, or only partly started in 2000. Please refer yourself to RFC 920 and previous RFCs on DNS. DNS is the naming system of the legacy ARPANET Internet. It was aggregated to the international naming scheme in 1984 after meeting the operators of the external networks, since 1983 RFC 880/2. DoD/ARPA meeting with Tymnet in 12.83, Tymnet annoucement of IP support early 84. Some in here participated and might comment. What is important is that the today situation is similar and that the 1984 consensus described in RFC 920 has proven to be stable and good enough for 33 years (cf.infra).
As Vint says, why to change something which works?
The target was, as it is today, to get accepted end to end interoperability with more external systems. This meant openness, no conflict, naming format consistency and credibility. Actually RFC 920 describes the way it developed since 1971 (first commercial user) and 1977 (beginning of the global interconnects) and the way Internet could nicely insert itself into it. Internet did it so seamlessly that it took over.
1. the different connected real (COM, NET) or virtual (EDU) networks had their root names (names of their root into the APANET Internet) accepted (they are named "TLD" in the DNS jargon). As the ARPANET Internet had its "ARPA" root name.
2. the global backbone was, by then, the international public packet switch system by monopolies and common carriers. It used Tymnet or X.25/75 links and identified networks (real and virtual) in either using ISO 3166 3 letter codes or X.121 DCCs. Some virtual communities networks (externets) piped (refilled) their traffic through it. The largest number were the Telex refillers. They were identified for their support and some naming through Telex ISO 3166 2 letter codes. RFC 920 only uses that common practice in foreseeing ccTLDs (RFC 1591 introduces nothing new, and its rightfully that ICANN claims its legitimacy over the Legacy from RFC 920 and 921 - cf. ICP-3). In 1986 Austrian people forged the IP address cluster concept to support their Internet island (through Tymnet and X.25 link by Radio Austria). Then IETF was created and changed nothing. Why to change something which works?
3. RFC 920 details the process of creating new TLDs. The need is to avoid conflict with other existing names (like today "Macedonia" for country names) and the name to be accepted in the root files of all the inter-netted networks. By then, the de facto world referent being the Tymnet registry, the retained RFC 920 rule is its best practice, based on its international experience since 1977. It calls for an expected significant number of domain owners (500 is quoted) to credibly organize it together (multiorganization TLDs). Experience had shown it warranted the projects to be serious, open enough to avoid conflicts, credible enough to be accepted by other operators and by the market and to rise enough commercial interest to foot the various costs involved. RFC 1591 confirms this in describing the TLD Manager as the trustee of his community and in saying that IANA is not in the business of saying what is a country (the same as ICANN should not be in the business of saying what is a TLD).
If IANA/ICANN are not in the business of saying what is a TLD, IETF is however in the business of saying what is technically _not_ a TLD.
".tel" and ".mobi" are technically inconsistent propositions. They confuse what belongs to the scheme (protocol/application) with what belongs to the naming (users group). The same as was ".web" did in 2000.
To better understand, let take the mnemonic "IBM" and its ASCII domain name "ibm.com".
- when I enter http://ibm.com I expect to reach the IBM web site in using the HTTP protocol.
- when I enter tel://ibm.com I expect to reach the IBM switchboard (once the current VoIP delaying confusion is cleared).
- what will I expect to reach when entering http://ibm.tel, and what is tel://ibm.tel adding to me ?
Actually they create at least four major technical problems:
1. a conflict with multilingualization while MINC is working hard to implement IDNA and to test a response to the ML.ML urgency. ".tel" or ".mobi" are application oriented and are not multilingual. How do I know the _language_ that an English or a French sounding name will use. How will I give my "xn----.tel" Arabic name to a Chinese correspondent?
2. real demand IMHO goes far beyond ML. I think it goes to total vernacularization (schemes, formats, LHS, names and TLDs). What will mean the possible "vernacularization like" registration of "33142928100.tel" (Chirac's) ? Who will people reach? Will it be the same number as in using an ENUM system? Is there an RFC on this convergency? (3314292281000.far is under the control of the FR ccTLD Manager).
3. There are 6 possible IPv6 plans. The only one discussed right now (IPv6.001) is a flat plan offering a lot of problems and a world wide control to ICANN. Many voices therefore call for the study of another plan (IPv6.010) permitting to test IPv6 as a multi-plan system and able to match the architecture of other plans in use, complying with international standards. This would permit a universal numbering scheme of the world digital ecosystem (Internet, TV, Radio, Telephone, Geolocated services, Roads, Airplanes, Emergency services, Mobiles, etc.). It is likely that there will be relations between such uniname and uninumber systems. If there is a layer violation of the magnitude of ".tel" or ".mobi" on the Internet side, dedicating a non defined name space to a restricted part of the numbering scheme, this will either delay the global digital convergence or keep the internet out of it.
4. We could say that a TLD is the common name of a (bootstraping) group of registrants [RFC 920] or of a non discriminatory [laws] specialized [RFC 920] non protocol oriented [see above conflict with schemes] interest. So, ".tel" (such as .aero) could be used by Telecoms people and organizations.
But it could also be used for domains restricted to telecom applications: ftp://ibm.tel would not work, only would tel://ibm.tel. Browser manufacturers would then default "ibm.tel" to "tel://ibm.tel" and prevent the use of "http://ibm.tel";. We could imagine this could relate to service rates etc.
- this would be a major architectural addition to be discussed by IAB/IETF
- an RFC should be published on its technical needs (ex. support of the different economical models involved)
- this should be tested with IETF according to ICANN ICP-3 (reversibility, non-profit, open to the global community, no danger to existing operations, by IETF or other dedicated structures). In the WSIS context and due to the importance of the telephone area, this should call on an agreement with ITU (after ITU has created an Internet dedicated interface/sector able to adequately sustain relations with the Internet governances on such matters) .
That perspective could have a dramatic impact on the intenet and on the use of the telephone. I do think that it should then supported using virtual zones (meaning that such a ".tel"/".mobi" should be co-managed by telephone operators acting as co-registries). But before that the study of mobile application programming, relations, exchanges should be more advanced.
The "slippery slope" is here. Not with the request. But with ICANN BoD's possible response.
We are in a situation where the whole internet concept is at stake (spam, TCP/IP, IPv6.001 plan, cybersecurity, WSIS/UN/ITU). There might be a temptation of "fait accompli" by ICANN to try to force others (Govs, developers, operators, users) to keep the current internet os the core of the Information Society (technology and ICANN). We saw that with ".biz" when ICANN reported to the USG it did not create any risk. We see that with the current silence on IPv6.001 uniqueness and unique hierarchy.
IMHO this would only speed the development of alternatives to the current internet, with a dramatic impact on technology and on the telecoms and datacoms industries.
Is there a possible process and is there the time?
This is an habit of ICANN to establish dead lines and to use as an alibi they are bound by the lack of time they provide. "So what would you have the IETF say, and how would you propose organizing a process to approve such a statement, ideally between now and April 30?" tries John (now on the ICANN side :-).
The process may only be to follow on this post, to make John Klensin and the other BoD Members understand there actually are serious and even critical technical concerns involved in some propositions. They are gown boys. As John says, he has his own opinions. Let confort them.
ICANN's credibility is already at stake. Showing we understand that the Internet consistency and evolution can be at stake will only help them to take wise decisions. They (quite) did it in 2000 (not exciting, but not too harming). IMHO ICANN (or any single centralized organization) is not adequate to manage anything else than status quo (political as well ad technical): the only thing we should ask them is not to degrade it. This was John's and Vint's position about the RSSAC. This is Vint's position about the whole Internet.
Why to harm something which works ? jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf