Dear Evan, I fully agree with you. ALAC is about advising the ICANN BoD on @large concerns and actions, and about their relations with other Internet @large structures that are not participating in the ALAC. I also agree with you about the possible "technical mission creep" that could superpose the existing social and activist mission creeps propositions. At 17:34 27/08/2008, Evan Leibovitch wrote:
My main concern -- and the reason I suggest "refining" the topic in Cairo in advance -- regards potential abuse of the topic at the Summit. I would resist attempts to use this as an excuse to engage in the theoretical and wishful thinking, without concrete direction for subsequent action *possible by ICANN*.
IMO it is important to identify ICANN's role in the (re)building of public trust in the DNS system (or whatever may take its place), and not to use the Summit to lecture IETF, ARIN, or other bodies. By all means let's find areas of common interest and co-operation with other bodies, and I do believe that ICANN is in an excellent position to sponsor some genuine R&D in this field. But we also need to stay aware of the limits on ICANN's own mandate and resist using this issue as an excuse for further mission creep. ICANN has a hard enough time executing its existing mandate.
To help make a clear distinction between what belongs to IETF, ICANN, and @larges, and how to best concentrate on what concerns ICANN and how it can beneficiate from this, I will answer Khaled and Patrick in documenting the france@large/ATLARGE current effort. Due to the Staff's enduring irregular attitude (we still have not received the announced response to our March accreditation file) this effort is now located outside the ICANN @large community. However, it necessarily concerns ICANN (cf. Part 3). .
At 22:08 27/08/2008, rafik dammak wrote: Hello Patrick, as you highlighted the most problem come from Industry which make choices against common interests.
Dear Rafik, We fully agree. However, industry is making choices in the Industry's common interest. This is up to us @large, i.e. informed users, to make choices in the users' best interest. And those of us who are also engineers should work together along those choices. Bear with me and you will see that there is no conflict with IETF, IEEE, or ICANN. On the contrary (even though there is a need for a clarification in common), this was worked out in the WSIS Tunis agreement. However, it has still to be enacted. This is named "enhanced cooperation" and some are reluctant ...
At 09:27 27/08/2008, Patrick Vande Walle wrote: Khaled, This is indeed an interesting debate to have. As we know, most of the technology we use today was developed 25 years ago.
Khaled and Patrick, This is a key issue that france@large has an active position on, in which I think I need to share with you. I apologise for this relatively unstructured post. It should have been a full liaison report, if we would have been accredited Situation evaluation We fully share your evaluation along with IAB's position in RFC 3869, which emphasizes what Patrick stated about industry (they are not motivated by long-term issues), governement (IAB calls for non-commercial and governmental funding), and multilateralism (that RFC lists Internet R&D priorities and does not even quote the first of them: multilingualization). We discussed with several organizations a set of questions that we posed to Vint Cerf. The point was to know if IDNA intended to address our needs or not, now or in the future. These needs were simply expressed, as an ML-DNS solution, to be reliable in every language just as the DNS is today in ASCII English. The formal response was negative. It also advised us, in an IETF legitimate spirit, to develop our own project. Unofficially, we were advised to find another structure and liaise with IAB when we explained that (1) we could not meet the IETF BoF system, WG delays, RFC system, etc. costs and requirements, (2) our target is not to publish standards, but interoperability basics for a diversity of solutions, and (3) to publish a multilingual dictionary of the Internet technical and legal terms, if we want multilingual TLD to make operational sense. I followed the procedure with Vint Cerf (WG-IDNABIS), Lisa Dussault (Applications AD), and Russ Houssley (IESG Chair). I will appeal the IESG in the coming days in order to obtain a formal response, to be confirmed by IAB in order to make it clear that we did not want a split but intend to follow an IAB liaison process if such a split is imposed on us. If this appeal is denied, we will have to create a working framework. This will most probably be an ATLARGE Open Network Standard structure, proposing to foster a specialised IGF ONSEC enhanced cooperation. In such a case, IAB and IESG will have made it clear that every of us fully respect the WSIS Tunis agreement spirit, and their taking care of the Legacy Internet transition, and ATLARGE/ONS being one of the contributors to the technical Internet emergent issues. The "Internet Plus" Since its inception, france@large has followed my 30 year old Intlnet's target (August 22, 1978): to technically and politically support the independent use of the common network resources of the world digital ecosystem (WDE). The complementarity is that Intlnet is interested in daily operations, R&D support, international strategy, while france@large is interested in usage at the national community level (it is presently reviving the ATLARGE organization that icannatlarge.org lead to incorporate in 2004 in order to resume support at the global community level). Upon Vint Cerf's response, we considered the ML-DNS implication and found that we had to actually engage in an "Internet Plus" consideration project. The target is not to re-engineer the Internet, but rather to help users to re-engineer their own global system, through the existing Internet and other resources of the digital convergence, and open themselves to the semantic strata (we call the Intersem). Our plan was confirmed at the end of the World Internet Week de Paris on July 2. The plan is to write a roadmap towards a White Book. The debate over that roadmap (on our supposedly "non-existing mailing list") has been quite active. It currently leads us to: 1. define our target as a "better people-centric Internet for each of the 6.5 billion of us", as diverse as it may have to be. 2. start from a detailing of our needs, considering those already expressed by IAB, ICANN, WSIS, etc. ethical considerations, and a common communication model that is based on the new cultural/scientific paradigm (open vs. closed systems and networked vs.analytic thinking).) in order to consider the backward compatibility with the current propositions rather than the complexity of a transition that IETF is being met with (ROAP, DNS, IPv6, etc. issues). 3. differentiate three main areas of interest: (1) utilization of the Internet Plus/Intersem, (2) social targets of the Internet Plus/Intersem, (3) technical design and testing of the Internet Plus/Intersem. An example: the DNS usage is different in Web.2.0. The main problems that we are facing are our legitimacy, a lack of time, resources, and competence, as well as the need to adjust to the ongoing ICANN and IETF internal conflicts and IGF emergence. The @larges' legitimacy The rationale is as follows. 1. Capitalism is money-centric by nature and has, therefore, a tendency to support and appropriate network-centric (decentralised) visions. This leads to industry attempts to control the IANA and to appropriate local TLDs: the ICANN "Internet for the Rich" strategy. The stability of such a scheme is the Shumpeter's theory. An entrepreneur has an idea, sells it to bankers who act as reasonable filters. Thisresults in an R&D joint-venture, industrial development, and "super-profits" during the time that the idea remains a market monopoly. 2. This is less and less our societal scheme. Our society is increasingly more based upon the new "lead users" observed behavior. Llead users are persons who adapt the industrial products that they purchase for their own needs. This may represent up to 2% of the customers, and much more in some particular sectors, such as clothing. As a result, increasingly more industries are becoming "lead user driven" (not to be confused with "market driven", which is based on market studies). The lead user is a response to the impossibility to maket study innovation. You innovate yourself or you observe those who innovate. Obviously, FOSS is a typical lead usership example. The france@large definition of an @large person is precisely an Internet lead user. For years I have tried to investigate how IETF could accomodate contributions of that kind of users. Experience has shown that there could not be a fit, for many practical reasons more than conflicting ones. The IETF Internet process is oriented towards industrial co-development of the Internet structures based on rough consensus. Usage is interested in the best way to use the existing resources rather than changing them. This means simplified robust pervasive architecture, the interoperability of multiple forms of usage, and most of all (1) security that the specific Internet infrastructure cannot provide (2) presentation services/layer the Internet architecture does not include (3) multiconsensus based diversity (documentation of multiple interoperable sub-consensuses). Interoperable usage architecture We have committed to remain fully interoperable with IETF solutions when they are clearly defined (we are not going to read 5500 RFCs, it is not our hobby). Our basis is ISO 3166, which is the very structure of the International network since 1978. It has documented the national scripts and languages since its ISO-3166-1:2006 version. We will base ourself on the Open Source LS640 Linguasphere series that served as the basis for the current ISO 639-6 standard preparation of an exhaustive listing of all the language names. We will use (virtual) smart gateways (interbox) to interface the Legacy Internet with Internet Plus user systems (consider a NAT, the other way around). This will enable us to use IPv6 headers, with our own additional parameters and possible services for local, meshed networks and a progressive Internet Plus cloud gathering them all. We call this TCP/IPP (IP Plus). We will use standard DNS software, but in a non-recursive manner, with local roots at every nameserver. These root fileswill be made available through a secured distributed replacement for the IANA (MDRS, Multilingual Distributed Referential System) that will mainly strive to provide the metastructure of the Intersem: supporting the Semantic Addressing (Internet of Ideas), netlocale files (netcentricity documentation), personale files (personal semantics) and the relevant locale files. Project consolidation The plan is to seeds/projects that france@large has identified: - the Intertest - a testing charter for those having to test ("consensus and running code") technical or governance issues in using the real Internet as a test bed. This Charter will fully comply with the published or discussed ICANN ICP-3, IETF, etc. testing constraints. It will be maintained as an IETF I-D that the entire Internet community and IGF can comment on and improve. Among the Governance issues to be tested, there will obviously be a WECANN mailing list to discuss and test a World Enhanced Cooperation for the Administration of Names and Numbers: we expected it to be a part of the ALAC and it will be open to all the ICANNers. - an IPv6 topology centric numbering plan and plug-and-play/translation network grids - the MLTF (Multilingualisation et Technologies de la Facilitation) (Intersem) - Multilinc - to implement geocultural documentation, MDRS, TLD, etc. for each LS640 lingual entity - Netix, network interoperation system and sources - the INTF for those wanting to take advantage of the acquired experience to help the Internet core transition. etc. Context of this plan This plan builds on the propositions that lead to the incorporation of ATLARGE in 2004. It will act as a shell/secretariat structure servicing the international@large community (individuals and national@large structures addressing the national usage specifics, participating in the national and regional Internet Governance Forums, and being Human Rights conformant in discussing their technical contribution in their own language. We would certainly have preferred to engage such a plan with the entire Internet Legacy @large and technical communities. This has not turned out to be possible, however, in spite of a sustained effort over the course of eight years. We cannot wait any more because there are too many risks of seeing the Internet technical deliquescence becoming a commercial/strategic opportunity for some. This is probably an impossible task, but perhaps we are too stupid to understand it. We just hope some open minded common sense people and engineers will rally together and help all of us make it. --- Some comments through your posts:
been no change to the fundamentals, but rather patches designed from the start with backward compatibility.
Yes. Except that ICANN plans to break our 1984 consensus (RFC 920) with its "Internet for the Rich" strategy and its intent to disrespect ISO 3166 along the WSIS resolution on national name spaces sovereignty.
I think most people will agree that the DNS is broken beyond repair. The changes we have seen over the years were all enhancements to the previous standards. DNSSEC and IDNs come to mind. Both were designed to prevent incompatibilities with older software. Punycode is ugly. We would need an 8-bit clean naming system. DNSSEC keys make zone files unreadable by a normal human being.
Yes. There is no technical reason to not develop and deploy such a solution, for example, in using OPES to create the missing presentation layer, except that it represents a dramatic change in Internet architectural and societal values. This is the paradigmatic shift. Our evaluation is that TCP/IP can support it, but this is much more complex for IETF brains.
Note also that, over the last 15 years, most of the new developments in Internet standards were developed by the industry, and not by government funded academic research. The goal of the industry is make profits. Hence, technical choices are mostly short or medium term and tend to perpetuate existing economic models.
RFC 3869.
The DNS hierarchical model has been generating an interesting cash flow for the registries and registrars (and ICANN, BTW). See for example the fact that domain names have largely prevented Verisign from going bankrupt. (http://www.domainpulse.com/2008/08/08/verisign-reports-68-million-loss-873-m...)
Please also note that a heterarchic management of the DNS removes every alibi for the root server system, and hence for its archives along with the international real-time stratetgic intelligence that they collect.
The net result is that there is no real work done to change the fundamental design to address new concerns. IDN ugliness and security are issues, but so is the "one TLD, one registry" model, which prevents real competition in the TLD space. More distributed models for naming systems, like CoDoNS (http://www.cs.cornell.edu/people/egs/beehive/codons.php ) remain purely academic, as there is no willingness from the industry to kill the cash cow.
france@large is probably the only organization that has carried out an ICANN ICP-3 compliant project for the DNS test-bed. Its conclusion is that there is no problem in having a multi-root system if there is no TLD label conflict (as seen in the one created by ICANN with ".biz"). Daily operations have shown that there are practical, simple possibilities to manage multi-registry TLDs. However, multi-registry is not much in need if the WIPO issues are addressed for famous names and everyone can join the TLD name community they like or feel they belong to.
I focused here on the DNS, but similar considerations could apply to other parts of the Internet infrastructure, like traffic routing.
Yes. Multilevel and smart IPvX addressing should be addressed seriously. Multicast is also a priority.
This is where I think ICANN could and should be more active in fostering and sponsoring new research aimed at designing a new Internet, targeting the general public good, with no short term economic considerations. Granted, I do not expect ICANN to do the work of the IETF. However, I think it is not necessarily a good thing to let the engineers be in charge of everything, from the general vision to specifications and implementation. There needs to be a top level vision, a master plan of what we want the Internet to be in 10 years time. From there, we could articulate work packages and deliverables.
Objection! The problem is that there is a master ideology by the "Internet leaders" as they are called by RFC 3935 or the "affinity group" as they are called by RFC 3774. The real need is for less standardization and robust interoperability norms. IETF and ICANN are in charge of the "Legacy Internet" management and evolution. They must not prevent the emergence of alternative solutions and technologies through illegal technical exclusion (I have some experience with this :-)) violating WIPO agreement against Technical Barriers to Trade (TBT) and common innovative sense.
This discussion is very relevant to the ALAC also. While it is good that the ALAC provides comments on ICANN processes, it also needs to know where it wants the Internet to go, especially in the naming and numbering area, and articulate its positions according to its own vision.
This is the core of the ALAC mission: to keep the BoD informed and aware of the impact on ICANN, and liaise with the global @large Internet lead users community.
On Wed, 27 Aug 2008 07:35:52 +0200, Khaled KOUBAA <khaled.koubaa@gmail.com> wrote:
Re-engineering the Internet Source : http://iftf.org/node/2275
During a workshop at IFTF this week, I offered a forecast that there is at least a 50% probability of a fundamental re-engineering of the internet. Here's a bit of detail on this forecast and why I think this last week has been a critical turning point.
Domain Name Services, DNS, like most of the Gen One Internet is a system built on cooperation. DNS servers have a narrow function to accurately translate domain names like ABC.com into numerical IP addresses, using an an up to date directory from other -trusted- DNS servers. The problem in simple terms is the length of the encryption key used by DNS servers to authenticate each other is short enough, that using modern high performance CPUs, it's possible to calculate a key to enable access to " poison" the DNS database on the server server with fraudulent routing information to misdirect any query for ABC.com to XXX.com.
Another issue of concern with the IDNABIS approach and slowness as well as Unicode inflitration with a different technical background and strategic agenda is the confusion. Unfortunately, there is no way to enforce a confusion limitation and, therefore, it is likely that this confusion will disseminate. This means that one may expect the use of alternative "funycode" algorithms to punycode, supporting in turn other kinds of "IDN", and offering different ASCII labels for the same Unicode Label. There is no legal ground for a ccTLD to not register any "xn--" domain name. ".su" already documented that it was actually necessary to support other algorithms. 50% of the possible "xn--" have no Unicode meaning. Why waste so many possible sales? Mess of the mess. jfc