[ccnso-idncctld] FW: Comments on the Draft Final Report

[Bart Boswinkel <bart.boswinkel@xxxxxxxxx>]

FYI,
Steve's note.
Bart
------ Forwarded Message
From: Steve Crocker <steve@xxxxxxxxxxxx>
Date: Sat, 21 Jun 2008 06:22:33 -0700
To: <ccnso-idncctld@xxxxxxxxx>, Bart Boswinkel <bart.boswinkel@xxxxxxxxx>, 
Denise Michel <denise.michel@xxxxxxxxx>
Cc: Steve Crocker <steve@xxxxxxxxxxxx>
Subject: Comments on the Draft Final Report

This is very nice work.  I congratulate the chair and the committee on moving 
this along.  Compliments notwithstanding, here are comments on the Draft Final 
Report in three groups: Substantive, Clarification of Intent, and Clarification 
of Wording.

Substantive

It really is necessary that the new TLD operator conform to the IDN standards 
and conformance to the ICANN IDN Guidelines.  We cannot afford to have 
territories that implement IDNs for their country names to "opt-in" to 
conformance to IDN standards and the IDN Guidelines.  This ought to be a hard 
requirement, and not placed in the "Alternative View" section.

The proposed IDN string should be three or more IDN characters and should be 
unambiguously descriptive and unquestionably distinct from any existing TLD 
string.  Full words are preferable to abbreviations or acrnoyms.  Two letters 
should not be used at all.  We need to avoid possible confusion.  It's 
particularly important on the fast track to be very cautious and choose names 
which are very safe, not merely "probably safe" or "seems ok."  Thus, in the 
technical requirements for Step 2, the penultimate bullet should be 
strengthened to "... no names shorter than three characters in non-ASCII may be 
used and full names or words are strongly preferred over abbreviations or 
acronyms."

As a related but technically distinct matter, the proposed label must not 
contain a character for which there is a homograph in a different script which 
is common in the same territory.

While document is cast in terms of creating completely distinct, new ccTLDs, 
the document should also permit and even encourage the addition of IDN ccTLD 
which is structurally just an additional name for the same registry.  This 
might be implemented via DNAME or something similar.

Clarification of Intent

Under "B. Non-pre-emption of overall policy" we need some examples or 
additional text to help the reader understand what issues are expected to be 
dealt with in the overall policy.  It's hard to know from reading this whether 
or not we're effectively making policy even though we're saying we're not.

Principle D speaks to Fast Track for non-Ltin scripts.  Why is this here at 
all?  This is a fast track for IDN ccTLDs, so it seems to me that Latin ccTLD 
designations are automatically out of scope.  Moreover, there is already a well 
defined policy for Latin ccTLDs, viz the ISO 3166-1 list and the existing IANA 
delegation process.  I was particularly confused by the sentence "Accordingly, 
in the Fast Track, the scrpt has to be non-Latin to avoid pre-empting the 
outcome of the ccPDP."  Is there a PDP for Latin ccTLDs?

Clarification of Wording

In principle F, "experimental" may not be the best word to use.  If I 
understand the intent, we're trying to say that we may make some assignments 
and then discover the reasoning process behind that assignment is problematic 
and thus we might not want to use the same reasoning in a future decision.  In 
saying we don't mean the delegation is temporary, I think we're trying to say 
we have no intention of withdrawing an assignment once it's made, but we may 
not want to use it a precedent for future decisions.

Thanks,

Steve



------ End of Forwarded Message