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. <Quote>: 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.
<unquote>
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]