[governance] Friday morning... (Arabic Domain Name) Some

Sun May 16 23:11:49 EDT 2010

JFC,

Hi!

I am interested in knowing more, opened the attachment and it was
blank. Could you please resend the information?

Sala

On 5/10/10, JFC Morfin <jefsey at jefsey.com> wrote:
>
> Thanks to Ginger Paque, Ian Peter, and S. Subbiah for reminding us
> all about this Internet saga.
>
> In addition, I just want to remind you, however, that:
>
> - USA first operated public Katakana services with KDD (Japan) in
> 1983, in using Tymnet and then X.75 protocols.
> - ICANN is politically toying with the international community since
> there is currently _no_ IDN standard by the IETF yet (not published).
> - the IETF WG/IDNABIS IDNA2008 consensus was found over an "a minima"
> consensus concerning the users' side requirements, which eventually
> the IESG did not want to even consider.
> - the currently IESG approved IDNA2008 architecture is under appeal
> (next step is to the IAB) because it is _perfect_ (except that it
> does not support Latin languages) on its Network side,  however no
> IESG disclaimer has ever explained that it is not documented yet, and
> it is opposed by the IAB, on its users' side. The IESG response
> (first step of the appeal) advised to consider a BoF (proposing a new
> WG) on the issue.
>
> What ICANN actually does is to pretend that it still controls the
> Internet Domain Names (IDNs) in preventing scores of (IDN)gTLDs to be
> added to the root. In favoring a few non-ASCII IDNccTLD:
>
> -  ICANN actually technically (and commercially) discriminates on the
> basis of the wrong reasons against structured private projects, in
> legal violation with its by-laws.
> -  behaving like an Internet global Monopoly, it forces LATINgTLDs
> projects, like the one I chair (PROJECT.FRA), to find an independent
> technical solution (even for testing), since IDNA2008 does not
> support yet French's (and the other Latin languages') orthotypography.
>
> This amounts to unfair competion to more than 500 gTLD, LATINgTLD and
> IDNgTLD projetcs, and disloyal commercial behavior at the expense of
> the entire Internet Community.
>
> For those interested, I have provided a more detailed explanation in the
> annex.
> Cheers.
> jfc
>
> -----
>
> The launch of the ICANN Mad Track
>
> The 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. Vint Cerf (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 disciples" by Martin Dürst, or
> 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 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/MIGHT" 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>http://tools.ietf.org/html/draft-iab-idn-encoding-01)
> because (as Vint Cerf 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 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 –
> <mailto:iucg at ietf.org>iucg at 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/>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 Chair, AD, IESG, and other community
> interests including ICANN, which did not want to get involved, while
> Vint Cerf initially suggested that they might coordinate (we then
> underlined they are only a namespace cooperator with Internet Users
> and Industry DNS server operators):
>
> 6.1. We agreed with Vint Cerf 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 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 at 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.
>
> 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, 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.
>
> 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. initiating a test project (Fats Track) which can test nothing new.
> 10.2. reserving it only to IDNccTLD, delaying (IDNgTLD) for years
> without any technical reason.
> 10.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 – ICP-3)
>
> As @large Internet Users, we made all what we could to help a
> community cooperation, debate and responsible approach.
>
> 11.1. france at 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:
>
> 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.
>
> jfc
>

-- 
Salanieta Tudrau Tamanikaiwaimaro
P.O.Box 17862
Suva
Fiji Islands

Cell: +679 9982851
Alternate Email: s.tamanikaiwaimaro at tfl.com.fj

"Wisdom is far better than riches."
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance

Translate this email: http://translate.google.com/translate_t