ICANN ICANN Email List Archives

[ccnso-idncctld]


<<< Chronological Index >>>    <<< Thread Index >>>

[ccnso-idncctld] IDNccTLD Draft Final Report - Comments from France

  • To: ccnso-idncctld@xxxxxxxxx
  • Subject: [ccnso-idncctld] IDNccTLD Draft Final Report - Comments from France
  • From: "Bertrand de La Chapelle" <bdelachapelle@xxxxxxxxx>
  • Date: Mon, 9 Jun 2008 22:22:16 +0200

Dear all,

Apologies for these late comments. There are two major points I would like
to make suggestions on. The second one tries to explore a possible solution
regarding the "objection procedure" and proposes a formulation for an
additional Guiding Principle.

*1. Clearer distinction between string selection and delegation*

The current draft report is very detailed and good. However, upon closer
reading I found a discrepancy within it regarding one specific element : the
distinction between the string selection and the delegation itself.

**
Recommendation 2 in the end clearly indicates that :
*- the first stage concludes when a string and language table are clearly
defined
- the second stage concludes with "the publication of the selected string on
the ICANN website"
*

Indeed, neither the string selection nor the due diligence process on the
string and language tables require the existence of an already designated
manager.

Still, the whole section regarding string selection currently requires that
the application be made by the "selected delegate", even as the designation
of the IDN ccTLD manager is indicated as step 5 in the "preparation within
the territory", which clearly indicates that it can be the last action
undertaken by the territory's authorities.

This in my view penalizes the countries that already have devoted a lot of
efforts in the initial stages and may well finalize the designation of their
ccTLD operator in the time required for the due diligence on the string. The
parts related to the delegation itself in the draft are limited basically to
: it is up to the authorities to select the manager and the delegation
follows the normal procedures of IANA. So there is clearly a difference and
most of the IDN ccTLD process actually refers to the string selection.

In order to alleviate the above incoherence within the document, it would be
preferable to more clearly separate the two processes : the string selection
and the delegation itself. This would actually be in full accordance with
the paragraph at the very beginning of the report that states in no
ambiguous terms :

*As determined in the Initial and Interim Report, the Fast Track requires
two specific mechanisms:
1. A mechanism for the selection of the IDN ccTLD string; and
2. A mechanism to designate an IDN ccTLD manager.*
To be honest, I even could go as far as considering that the fast track is
mainly devoted to the selection of the string. The delegation process could
actually be mentioned only as : according to existing IANA rules for
delegation (both in the choice of the delegate and the delegation process
itself).

This clearer distinction has strong political benefits, allowing territories
to formally enter the fast track rapidly, and it requires only minor
modifications to the present draft (mostly by replacing the expression
"selected delegate" by "applicant" in the string selection phase). *A
version with corresponding track changes is attached to this mail.*

This is something that I tried to convey in some of the earlier discussions,
but probably did not express myself correctly. I hope this will seem
appropriate and an improvement by other members.

*2. Handling of comments (ie addressing "objections")*

As I have mentioned in previous mails, a formal objection procedure would
only encourage objections. At the same time, putting on the ICANN board only
the responsibility of managing potential objections will make them more
publicly visible, at a later stage and harder to solve. It could also be
understandably resented by some territories.

The objective we should pursue in the present recommendations is therefore
to encourage resolution of possible problems (and we know there will be
some) at the lowest level possible.

In order to avoid the insertion of minority views (due to one specific case
we all have in mind), could we try to place this more generally under the
category of any problem arising within a community of territories that
intend to submit a string in the same script (cyrillic, arabic, chinese,
etc...) ?

In  such a case, I think we agree that any problem arising among those
countries regarding their choice of string should be first and foremost
addressed between them. I understand this is the approach that countries
using arabic script have undertaken already with the Arab League group they
have instituted. A coordination among territories using a common script will
be  useful anyway in the future and there is a benefit to encourage it early
on.

An simple encouragement to hold consultations prior to submitting a string
application would not infringe on the responsibilities of the territory and
would provide additional information to the Board should the problems
persist. Just as the current report encourages "territories using the same
script" to coordinate their language tables, it is proposed to insert an
additional Guiding principle provision that could for instance read as
follows :

*"H. Coordination among territories using the same script

Territories using the same script should hold consultations to address any
issue regarding their string selection prior to submitting their application
to the fast track process" *

This is of course only a basis for discussion and the formulation can
certainly be improved. Guiding Principle E in that context would remain as
is.

I hope this proposal can help the discussion move forward and help us avoid
the insertion of  "minority views" introducing a formal objection procedure
that would probably raise more issues than it would solve.

Apologies again for the late posting.

Best

Bertrand


P.S. Final Note : I leave aside in this mail the possible problems between
two script spaces; for instance if a string in an IDN script is confusingly
similar (in particular visually) to another existing string in ASCII (the
case might arise with cyrillic, if Russia were to apply for .py (.ru in
Cyrillic, which is visually identical to the ccTLD string for Paraguay). I
understand that this has not been proposed by the Russian Federation, but a
comment has been posted on that very point on the Icann comments site
regarding IDNs (see :
http://forum.icann.org/lists/idn-cctld-issues/msg00004.html)<http://forum.icann.org/lists/idn-cctld-issues/msg00004.html%29>

Such problems are clearly within the remit of the language committee, whose
composition is precisely appropriate to handle these trans-script questions.
It could be explicitely mentioned in the mandate of this committee.



-- 
____________________
Bertrand de La Chapelle
Délégué Spécial pour la Société de l'Information / Special Envoy for the
Information Society
Ministère des Affaires Etrangères et Européennes/ French Ministry of Foreign
and European Affairs
Tel : +33 (0)6 11 88 33 32

"Le plus beau métier des hommes, c'est d'unir les hommes" Antoine de Saint
Exupéry
("there is no greater mission for humans than uniting humans")

Attachment: Draft Recommendations IDNCWG version 1 comments France.doc
Description: MS-Word document



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy