Network Working Group Jean-Francois C. Morfin Internet-Draft Projet.FRA Intended status: Informational May 28, 2010 Expires: November 28, 2010 Projet.FRA IDNA2008 related reports to the community draft-iucg-afra-reports-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on November 28, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Morfin Expires November 28, 2010 [Page 1] Internet-Draft A-FRA reports May 2010 This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Abstract This Memo was sent to the IESG prior to their approval of the IDNA document set (except the "Mapping" WG consensual document) by the Chair of Projet.FRA, a French speaking netspace. It is completed by a community report sent after ICANN launched their "FAST TRACK" project. Table of Contents 1. Introduction................................................... 3 2. The Internet layer:............................................ 3 3. The IDNA interface protocol:................................... 3 4. The user implementation of this protocol....................... 4 5. The impact on the network naming topology...................... 4 5.1. Impact on the virtual root file.......................... 5 5.2. Impact on the Internet usage architecture................ 5 5.2.1. Principles......................................... 5 5.2.2. Requirements....................................... 6 5.2.3. Interplus.......................................... 6 6. The technical and political interinfluence of the resulting c.. 6 7. Comments....................................................... 7 8. ICANN starts "FAST TRACK"...................................... 8 9. Security Considerations....................................... 16 10. IANA Considerations.......................................... 16 Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Morfin Expires November 28, 2010 [Page 2] Internet-Draft A-FRA reports May 2010 1. Introduction This Memo was sent to the IESG prior to their approval of the IDNA document set (except the "Mapping" WG consensual document) by the Chair of Projet.FRA, a French speaking netspace. The IESG Chair, copying the concerned authors and parties answered it as follows: "Thanks for you IETF Last Call comments. Your comments stimulated a significant amount of discussion of the documents from the IDNAbis WG. The IESG approved the documents that you are most concerned with on their telechat today. The announcement of this action will come out next week." "I think it is important to point out that some of your suggestions are beyond the scope of the IDNAbis WG charter, and in fact, some of them are research." IDNA has been specified as permitting a support of IDNs without any DNS change. I identify five layers in these proceedings, which are: 1. the internet layer 2. the IDNA interface protocol 3. the user implementation of this protocol 4. the impact on the network naming topology 5. the technical and political interinfluence of the resulting changes. 2. The Internet layer: The internet is to provide regular Internet transport, network, and DNS LDH resolution services. This is to remain unaffected. This has been respected thus far. 3. The IDNA interface protocol: This was controverted between Unicode, the IETF culture, and us. Moreover, the proper support of French is turning out to be the most complex issue due to the use of the same Roman charset as English, while the French key concept of "majuscules" is absent in English and Unicode. The success of IDNA2008 is to have reached a workable consensus between these three positions (however proper French [Latin languages] orthotypography obliges ".FRA" to find an additional way to support them). We designate IDNA2010 a BCP Draft project that would document the various ways IDNA2008 is/can be implemented by Zone Managers. For the time being, the related workon@idna2010.org mailing list is only for the informational purposes of its respective members. Active debate will only be started in coordination with the WG/IDNABIS Chair, so that there is no confusion. To date, there are people of various origins on the list, but none from ICANN. Morfin Expires November 28, 2010 [Page 3] Internet-Draft A-FRA reports May 2010 4. The user implementation of this protocol In suppressing Nameprep, IDNA2008 means progress in flexibility. However, this flexibility may lead different applications on the same machine to resolve the same IDN to different IP addresses. This means that there is not only a problem of transition, but also a problem in the architecture of the user's machine in order to address this risk. As initially indicated, I had planned to address this need in full compatibility with IDNA2008 via the ML-DNS approach (cf. infra) I announced, as soon as IDNA2008 would be approved by the IESG. Lisa Dussault preferred raising the question once IDNA2008 was completed but still not yet approved. This provides you with full control over the decision, but you now need to know the resulting upward and downward contexts better. The simplest and most rewarding solution is an "IDNApplication" that: 1. respects the IDNA architectural principle of U-Labels that are to be dealt with at the user application layer. 2. intercepts all the domain name entries 3. transcodes them before sending them to the DNS in: * leaving ASCII domain names unchanged. * differentiating the few TLDs supporting IDNA2003 in order to address them specifically. * respecting IDNA2008 otherwise. In this way all applications and protocols will be provided transparently with the same adequately formatted labels. In addition, IDNA2003 transition schemes will be possible at dates that are decides by each of the concerned TLD Managers. The fastest and easiest ways to deploy this IDNApplication are either: * to use an OPES like front-end to existing nameservers (work on this was foreseen but not completed by the WG/OPES) * or to embed the support of punycode (or rather, "punyplus" (http://tools.ietf.org/html/draft-iucg-punyplus-03.txt) within new various nameservers releases. 5. The impact on the network naming topology There are three quick (and, therefore, stabilizing) large scale and easy to disseminate deployment strategies: * ISP "patching", as is currently and similarly done for Chinese Domain and Key Names. Morfin Expires November 28, 2010 [Page 4] Internet-Draft A-FRA reports May 2010 * public DNS services, such as Google's PDNS proposition that may help enforce that type of service immediately on a large scale. * implementation of non-external-caching DNS servers at the user's machine. 5.1. Impact on the virtual root file This happens while a demand for many more IDNg/ccTLDs than ICANN is prepared to accept in their Root file. In addition, ICANN in Seoul has strategically and commercially favored some non-Roman IDNccTLDs that will enter the NTIA root file through the "Fast Track" experiment; private, civil, and government IDNgTLDs projects that were previously incitated to be planned and to apply will probably be delayed for several years. The solution for these rebuked TLDs candidates (like .FRA) is very simple: to be declared as ULDs at the user's nameservers (for improved clarity, we call "user level domain" the top level or New.Net style domains that are declared by users). This means, in other words, local root files with all the TLDs and ULDs that each user needs. At a PDNS, this will call for the support of all of them. All of this amounts to acknowledging the need to manage the virtual root file that has already been in use for years (cf. the way Chinese TLDs are declared in top level nameservers). 5.2. Impact on the Internet usage architecture As indicated, the user innovative project (.FRA) introduced by france@large, together with the IUCG early @large participants, committed to document an IDNA2008 extension called ML-DNS (multi-layer). ML-DNS is part of an Internet Usage architectural framework that is able to provide a comprehensive and robust basis to the semiotic strata (Intersem) of which .FRA is interested in order to support intercomprehension facilitation (Internet of the Users and of their thoughts). 5.2.1. Principles Its principles are: (1) the strict equivalence (synonymy) of a domain name pile ranging from the UDN (user domain name) to the IDN (Internet Domain Name as documented by IDNA2008) (2) a generalized extended value IDNA consistent syntax (our rationale is that languages are supported through the presentation layer. If IDNA works, it means that it uses the Internet presentation layer, i.e. in this specific case, the "xn--" presentation). Morfin Expires November 28, 2010 [Page 5] Internet-Draft A-FRA reports May 2010 5.2.2. Requirements Our .FRA (as many other TLD projects including the Multilinc set of one sociolinguistic per ISO 639-6/LS 640 linguistic entity) requirements are: * French (Latin languages) majuscules support (and other similar particularities in other scripts), * extension of the Internet passive content support to ambient and active contents, * complete access to presentations and classes, * a "commuting cloud" of network services open capacity, * Unicode TR46 considerations * etc. 5.2.3. Interplus All of this is embodied through the "Interplus" (internet plus plugged layers on the user side), which does not change a single Internet bit and conceptually adds on the user side: * two real layers: * an interapplication communications overlay. * and a pseudo-network service area. Its general purpose is to support network extended services that users may easily "interplug" for an optional "smart network" experience. Software slots may support services such as: * ML-DNS nameserver * an Application Firewall * Virus protection, social network, Intersem metastructural distributed referential services (MDRS) * the virtual presentation layer (managed by the ML-DNS along the the "xx--" format, with the "x--" format that is being used for a "Netix" interapplication command set). 6. The technical and political interinfluence of the resulting changes ICANN has imposed pressure on the IDNA text finalization in order to match the Seoul date. This led to some transition confusion (now Morfin Expires November 28, 2010 [Page 6] Internet-Draft A-FRA reports May 2010 sorted out) between the WG/IDNABIS and the workon@idna2010.org mailing list. Then, the ICANN Seoul announcements were both perceived as an ICANN opposition to the open deployment of IDNA and as a technically premature move, since Fast Track is more of a legal work than a technical test, and there has been no consideration as of yet of IDNA2008 practical implementation and usage issues. ICANN participants in WG/IDNABIS either did not perceive the stakes or were not entitled to comment. They did not answer the various questions that we raised regarding their position(s) on IDNA2008 and ULDs. As a result, we may have: (1) four different works on the way in order to implement IDNA2008: * ICANN Guidelines supporting closed committees representing approx. 120 second level zone managers among millions. * IUCG workon@idna2010.org open mailing list, targeting an informational BCP for concerted and interoperable implementations of IDNA2008 * some major Public DNS services unilateral policies * idem for some national deployments. (2) confusion over the namespace, with ULDs popping up here and there without any coordination. Local root dissemination means a heterarchic naming structure. This was foreseen in the ICANN ICP-3 document, but we are the only ones to have run a community test-bed as requested by ICANN. If we want to keep the DNS namespace stable, we need some virtual root cooperative management through an IDNAlliance. We also have to take into account that: * class usage is off-the-shelves of any IDNApplication solution * I only describe the simplest thing that I am to deploy as the Project.FRA Chair in order to get the .FRA namespace operational, at NO change whatsoever except for the loading of a slightly enhanced version of Bind on the participating machines. Everyone else can do the same, and many other TLD project may wish and have better funding to do it. There is NO change in any way. This is simply a normal reading of the RFCs from an IDNA2008 point of view. The Internet legacy turns out being still more powerful than expected. 7. Comments Morfin Expires November 28, 2010 [Page 7] Internet-Draft A-FRA reports May 2010 The decision is yours. You can either approve or delay IDNA2008 and request more information. * IMHO, if you do not approve IDNA2008, which is certainly excellent work, you will cast suspicion on the entire IDNA scheme, as ICANN will have to delay Fast Track due to an IESG decision. Furthermore, this would delay what needs to be built over IDNA2008. During that time, people would certainly start building it up over IDNA2003, thereby initiating a terrible mess. * this is why we have started building a technical position against IDNA2008 under the terms imposed by ICANN's urgency (lack of consideration of the abovementioned points). If you approve IDNA (as you technically should), I will appeal against your decision (I fully approve) due to its non considered specific context. I will upset many. However, my expectation is that it would provide many more people with a four to six month respite in order to better organize and work out an IDNA2010 BCP proposition or start a WG/VIRTUALROOT, in turn preventing the current 500 ICANN TLD candidates (and probably many more) from deploying as uncoordinated and most probably conflicting ULDs. In this case, some will initiate lawsuits against others (this has already started): this will result in an unknown US jurisprudence on TLD and ULD attribution that, by essence, no ULD will respect outside the USA. 8. ICANN starts "FAST TRACK" Since the Projet.FRA report above was sent to the IESG, ICANN started their "FAST TRACK" project (also called "Fast Track to doom", or "MAD TRACK"). The following community report was then published by Projet.FRA. : As a result the Internet adminance (i.e. community administration, operations, maintenance, users' specification set) situation is as follows: 1. When we started the IETF WG/IDNABIS, I asked (on behalf of several linguistic mailing lists) if the target was for the Internet to work better, or also for the users' needs to be addressed. I described these users' need as an "ML-DNS providing non-ASCII users the same QoS as the DNS does to ASCII users". 1.1. The Chair of the WG/IDNABIS was very clear: the charter did not speak of users, but of making the Internet work better and of being compatible with former RFCs (IDNA2003). 1.2. I then committed, on behalf of a francophone group that is interested in e-multilinguistics, francophone, and architectural TLD projects (later on nicknamed "Jefsey's Morfin Expires November 28, 2010 [Page 8] Internet-Draft A-FRA reports May 2010 disciples" by a WG Member, who became the "JEDIs"). 1.2.1. - to support the WG/IDNABIS effort along its charter. 1.2.2. - to build an ML-DNS atop of it. 1.3. Unless indicated otherwise, when "we" is used in this memo it is referring to these @large supported "JEDIs". Their announced project is to bring to the Internet the additional services that are necessary to support an semiotic stratum (intersem) that is interested in meaning, such as the Internet stratum being interested in content, and the telecom stratum being interested in digital signals. Their plan includes four experimental "externets" (global virtual open networks within the world digital ecosystem [WDE]) that are supported by: 1.3.1. Projet.FRA: a francophone zone of which the namespace will serve as the taxonomy of an open public ontology in order to explore semantic addressing system (SAS). 1.3.2. Multilinc: a multilinguistics (in the meaning of linguistic cybernetics) test bed, supporting more than 25,000 linguistic zones. 1.3.3. Perfida: a project to explore RFID applications in order to investigate the Internet of things vs. the Internet of thoughts areas. 1.3.4. MDRS (Metadata Distributed Registries System), i.e. the an ISO 11179 conformant metastructure for the Intersem. 2. The WG life has been tense on some occasions. The difficulty was to determine how to match the linguistic diversity while respecting the users' empowerment. This was also the case because it was meant to exemplify how the Internet architecture supports diversity, and its "presentation layer" (which is architecturally intrinsic to multilinguistic support but not documented in the Internet approach). There were two possibilities here: 2.1. - increasing the technical core's capacity (tables, protocols, DNS, etc.) as the IETF has always done in the past. 2.2. - supporting multiplicity, as something intelligent, i.e. at the fringes. There were three possible fringes then: 2.2.1. on the Internet side, i.e. in the protocols. The charter objected to it, but a technical control of usage was Morfin Expires November 28, 2010 [Page 9] Internet-Draft A-FRA reports May 2010 technically very tempting for some industry leaders and large SSDOs. 2.2.2. on the user side. This was eventually consensually agreed as it also permitted the last possibility: 2.2.3. in between, i.e. in a new architectural domain that we called IUI (Internet Use Interface) and that is now to be well identified and documented, but by whom? 3. IDNA2008 definitely chose to say that it MUST be "multiplicity at the fringes". This implies that fringes SHOULD do what nameprep did in IDNA2003. Then, it should require to give at least one example of what application developers MIGHT do. This "unusual" MUST/SHOULD/MAY areas description was carried out as follows: 3.1. the IETF WG/IDNABIS consensually defined the IDNA2008 unaltered way that the Internet DNS will behave. This is stability for the Internet "intrastructure" (i.e. protocols, parameters, BCPs, etc.) documented (RFC 3935) by the IETF: 3.1.1. No change in DNS, and no (mapping) intelligence inside the Internet to particularly accommodate IDNs. 3.1.2. Independence from Unicode versions. 3.2. This provided a stable, proven, reliable, and already deployed quasi perfect basis. 3.2.1. This with the exception, however, that in still being bound to Unicode it does not support orthotypography [a correct semantic use of typography]: for example, Latin majuscules metadata is lost. 3.2.2. Consensus could be found because a description of the way users COULD proceed on the fringes (proving feasibility) was consensually adopted. This was the "Mapping" document. 3.2.3. We documented ( http://tools.ietf.org/html/draft-iucg-punyplus-03 ) what we MIGHT do to overcome the lost metadata issue. 4. However, IDNA2008 failed to address IAB's key points (http://tools.ietf.org/html/draft-iab-idn-encoding-01) because (as the Chair had initially pointed it out) they are outside of its charter. The IETF Applications AD raised those points that question the very basic principle of the IDNA architecture (as being IDN "in applications" and not, for example, as a single "IDNApplication"). As Morfin Expires November 28, 2010 [Page 10] Internet-Draft A-FRA reports May 2010 a result, that document was not considered by the IESG. This means that the: 4.1. Current IDNA concepts do not consider how to prevent resolution conflicts between different applications on the same machine. 4.2. Unpublished, as of yet, IDNA2008 permits developers to address Asian, and supports Arabic, needs (most of them at least). Usage of IDNA in other areas (IRIs, etc.) is not completed. 4.3. Unpublished, as of yet, IDNA2008 does not address some French, Latin, and other languages' orthotypographic needs. This implies that Project.FRA (and many other linguistic and multilinguistic projects) need an enhanced operational solution. 5. That solution is a DNS fully transparent, and 100% IDNA conformant, ML-DNS that we (as Internet Users, members of the Internet Users Contributing Group u iucg@ietf.org) have committed ourselves to propose and experiment. To that end, two additional works are to be carried out. In order to avoid the confusion that the ccNSO started to introduce concerning a possible future evolution of IDNA2008, and to emphasize the whole IDNA architectural stable continuity, we named them IDNA2010 and IDNA2012. 5.1. IDNA2010 (http://idna2010.org) is to document the IDNA user's side corresponding to the IDNA2008 Internet side. 5.2. IDNA2012 is to document the IDNA2008/IDNA2010 adminance (i.e. how they are to be deployed, maintained, and evolve). 6. We were fully open to the WG Chair, AD, IESG, and other community interests including ICANN, which did not want to get involved, while he had initially suggested that they might coordinate the remaining tasks (we then underlined they are only a namespace cooperator with Internet Users and Industry DNS server operators): 6.1. We agreed with the WG Chair to delay the IDNA2010 work in order to permit IDNA2008 to be clearly approved by the IESG. 6.2. We documented with the IESG (which indicated having actively considered it before approving the IDNA2008 documents as we requested it) how Project.FRA, and the 22,500 linguistic zones of the Multilinc multilinguistic test bed, will have to Morfin Expires November 28, 2010 [Page 11] Internet-Draft A-FRA reports May 2010 deploy, since they are kept outside of the ICANN Fast Track experimentation, as every other candidate (IDN)gTLD. 6.3. In this report to the IESG, I explained that I fully supported the approval of IDNA2008 but that I would appeal against this approval if it was not put into its whole context in order to give stakeholders time to consider the practical implications of IDNA together, before ICANN started its political technically closed Fast Track, no-experimentation, project. ICANN eventually indicated that they might reassess their position in the function of the appeal timing. 7. The reasons as to why there are two initial debates to carry out any decisions to be made is: 7.1. IDNA2010 sits outside of the IETF scope. Who is to document it: a new IETF area? or the iucg@ietf.org mailing list (Internet users contributing group)? or another SDO? The Web is documented by the W3C, and IUI is of similar importance. 7.2. IDNA2012 will necessarily discuss the governance of the unique Virtual Root Open Matrix (VROOM) in the context of a non-ICANN centric, non-Internet centric, but user-centric management of the namespaces with an entirely new and still unprotected economy of (IDN)gTLDs and a different context of the net and user centricities. 8. At this stage, the ISOC (IETF) side has not decided yet (through IAB and a possible appeal to its Chair), but the IESG has already 8.1. acknowledged that I: 8.1.1. support the publication of the IDNA2008 set of documents, 8.1.2. but wish that the documents had been published along with a specific complementary warning to the Internet community [by or upon the guidance of the IAB] , 8.1.3. asked it would have noted the new architectural opportunities that are available in IDNA2008, and warned of possible confusion until these opportunities are properly governed, 8.1.4. deemed necessary a disclaimer indicating that IDNA2008 should not be deployed or tested until coordinated usage documentation is produced. Morfin Expires November 28, 2010 [Page 12] Internet-Draft A-FRA reports May 2010 8.2. in what they found no possible remedial action since the IESG does not direct the work of the IAB and 8.2.1. In rejecting this appeal, which does not suggest remedial action by the IESG, they actually found the appropriate action, since the next step of the appeal procedure permits me to obtain the IAB comment that we think the community needs, whatever this comment may be, in front of the very large amount of supporting material that I provided in order to "include a detailed and specific description of the facts of the dispute." (RFC 2026) 8.2.2. However, at the same time, the IESG observes that the appeal includes a plea for the Internet community to initiate some work. I, therefore, suggested the submission of an Internet-Draft and then to approach an appropriate Area Director to sponsor a BOF Session or sponsor the publication of the document, along RFC 5434. 8.3. The RFC 2026 calendar had so far been strictly respected: 8.3.1. ICANN wished to deploy IDNs. 8.3.2. IAB (RFC 4690) indicated that a revision of IDNA2003 was necessary. 8.3.3. IESG created the WG/IDNABIS to that end by giving the possibility to adapt its own Charter. 8.3.4. The WG reached a consensus within the limits of a slightly amended Charter. 8.3.5. That consensus exemplifies a set of fundamental changes in the Internet overall architecture that is outside the limits of the WG scope. 8.3.6. IESG approved the consensus while knowing that an appeal would be carried out concerning the impact of the architectural change that mainly concerns the IAB and the global community. 8.3.7. IDNA2008 publication is blocked by an appeal that IESG considers to belong to IAB. 8.3.8. The next step under way is my appeal to IAB. 8.3.9. The IAB response should have permitted the community to know whether IDNA2008 could be published and tested as it is (disregarding my concerns), or if a preliminary architectural, Morfin Expires November 28, 2010 [Page 13] Internet-Draft A-FRA reports May 2010 technical, governance, or adminance debate was necessary to preserve the Internet stability, as we believe, basing our belief on the only community test bed that was carried out along the ICANN-ICP-3 request and standards (Project.dot-root), and via our personal daily experience of navigating the Internet in using our very simple user centric ML-DNS prototype. 8.4. There are two actions to break the respect of that calendar: 8.4.1. The IESG advice above, which was also advised by Applications AD and the WG/IDNABIS Chair, was to publish a Draft. The reason why we did not want to publish a Draft is that we might poorly introduce and, therefore, delay or dangerously confuse what is simply a new reading of the existing architecture. This is why we consider it more secure to first obtain the IAB opinion and possible guidance. 8.4.2. The ICANN unilateral decision, in launching Fast Track before any concerted discussion with the Internet Users' side could be achieved after such an IAB technical guidance, has forced their de facto allies in the Internet dominant "ISOCANN enhanced cooperation" to take sides for what seems to amount to purely political and commercial reasons or possible lack of technical consideration, in favor of a technically unstable choice. 9. Because appeals are to be individual, the pressure that is being imposed on me in this way by ICANN is in violation of the ISOC/IETF appeal process as well as of the community trust, since Fast Track cannot refer to any newly published RFC to be tested. Therefore, its consequences only seem to undercut: 9.1. a grass-root move based upon a community based open, sound, secure architecture; and the competitive progress of the namespace that ICANN is supposed to foster. 9.2. a technical solution that will permit the quick, transparent, low cost, easy to understand deployment of hundreds of (IDN)gTLD candidates in a new phase of the Internet architecture and growth (that will also most probably be supported/sponsored by governments). 10. Delaying any further the debate on the ML-DNS, IUI, and their implications on the management of the namespace structure and economy would only dramatically increase the risks of confusion. Morfin Expires November 28, 2010 [Page 14] Internet-Draft A-FRA reports May 2010 10.1. The only way for us to respond now is to proceed in considering the ISOCANN enhanced cooperation as the architectural "competitive option" that they actually chose to be in: 10.1.1. initiating a test project (Fats Track) which can test nothing new. 10.1.2. reserving it only to IDNccTLD, delaying (IDNgTLD) for years without any technical reason. 10.1.3. barring within IDNccTLDs the most technically demanding ones, i.e. the LATINcc/gTLDs. 10.2. This means for us to focus on the Internet Users' linguistic, innovative, and semantic much more dynamic Internet Users option. 10.2.1. The harm that a noncontextually and uncooperatively prepared innovation may create has delayed me for years. 10.2.2. However, we now see that it will most probably not exceed what would result from a continuation of the sole ISOCANN governance and adminance of the namespace, under an ICANN inadequate dominance and an impossible common understanding at this stage without a real clarification by the IAB contradiction, the WG/IDNABIS could not provide when the AD demanded it because it is out of the scope of its charter. 11. "Responsible experimentation is essential to the vitality of the Internet. Nor does it preclude the ultimate introduction of new architectures that may ultimately obviate the need for a unique, authoritative root. But the translation of experiments into production and the introduction of new architectures require community-based approaches, and are not compatible with individual efforts to gain proprietary advantage."(ICANN in ICP-3). As @large Internet Users, we made all what we could to help a community cooperation, debate and responsible approach. 11.1. france@large, the eldest ALS, was denied the right to join ALAC, 11.2. we were barred from participating in IDNA related ICANN working groups, 11.3. we are now bypassed in our legitimate respect of the ISOC/IETF appeal procedures. 12. The only responses to such an ICANN unilateral attitude are: Morfin Expires November 28, 2010 [Page 15] Internet-Draft A-FRA reports May 2010 12.1. to give a last chance to a practical debate and show where the responsibility of the coming confusion lies in not interrupting the ISOC/IETF appeal process, so that the Internet Governance ISOCANN Enhanced Cooperation cannot claim that it did not know. 12.2. to engage in development and experimentation, in as much as ICANN permits it to the community, along the respect of the recommendations of ICANN's ICP-3 document, section "5. Experimentation". 12.3. to try to reduce the confusion that experimental or commercial alternatives might introduce, in not documenting our architectural options before they have been fully experimented; then documenting them as public domain through the bodies that could emerge to assume their open adminance and IETF Drafts. 9. Security Considerations This text comments on the harm that the author expects to result from what it considered as an ICANN irresponsible lack of precaution. 10. IANA Considerations There is no other expected consequences than the change from a centralized IANA to a distributed IANA replacement. Author's address Jean-Francois C. Morfin A-FRA Intlnet - 23 rue Saint Honore Versailles 78000 Versailles France Phone: (33.1) 39 50 05 10 Email: jefsey@jefsey.com URI: http://a-fra.org Morfin Expires November 28, 2010 [Page 16]