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

[Bart Boswinkel <bart.boswinkel@xxxxxxxxx>]

Dear Bertrand,
Thank you for your comments. Let me try to address the concerns you've raised 
under point 1. Clearer distinction between string selection and delegation, and 
clarify why the two processes are coupled in the manner described in the 
reports (Interim and Final):

 1.  The order you refer to ( step 5 in preparation in territory) is not 
intended to indicate a sequential order, but to indicate the different 
(selection) processes in territory, which can run in parallel. This is also 
reflected in the process diagram ( Annex A).
 2.  Selection of an IDN ccTLD is a clear indication  of the "readiness" 
principle ( Principle C). It is a strong indication there is a real need for an 
IDN ccTLD.
 3.  If the IDNC WG were to follow the reasoning you propose, it would in fact 
turn the fast track into a kind of reservation mechanism. Assume the selected 
string meets all the criteria, and we were to follow your suggestion, it could 
take years before the appropriate IDN ccTLD manager has been selected ( which 
has happened in the past) .
 4.  In order to have a truly fast track process, the need for coordination 
among all actors involved needs to be organised as efficient as possible and by 
minimizing to need for new processes. This can be accomplished, in conjunction 
with other measures, by designating clear points of contact for the full 
process,and building on existing channels of communication and knowledge.
 5.  Current delegation processes of ccTLDs are initiated by the intended 
ccTLD. One of the core elements, and which also is relevant for the Fast Track, 
is documenting the support from the relevant stakeholders in territory. As you 
may have noted for the Fast Track process this documentation is not required at 
the start of Stage 2. It needs to be submitted as part of the delegation stage. 
 This implies, as you suggested, the necessary documentation can be collated 
during the second stage of the process.

Kind regards,
Bart
On 6/9/08 10:22 PM, "Bertrand de La Chapelle" <bdelachapelle@xxxxxxxxx> wrote:

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.