Re: [Ietf] New .mobi, .xxx, ... TLDs?

At 19:08 21/04/04, Dean Anderson wrote:
> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf