[ccnso-idncctld] Wording edits for Principle E and suggested wording for Alternative Views

["Edmon Chung" <edmon@xxxxxxxxxxx>]

Below was the email I had meant to send to the list before the meeting but
had not been able to.  I had mentioned the first two points on the call as
well as the suggestion of some wording edits for Principle E.  Finally,
there are also a few paragraphs of alternative views presented regarding
some specific issues.  Some of which may have been addressed in the call
already.
Edmon




Hi Everyone,

Before I talk about Principle E and alternative views, there are 2 minor
items I would like to bring up:

1.  There is perhaps an inconsistency with the Draft regarding Principle D
and Stage 1.1:

Principle D states that: D: Fast Track only for non-Latin scripts
Stage 1.1 defines non-Latin scripts as: For purposes of the Fast Track a
non-Latin script is considered to be a script which identifiers are
represented with characters in Unicode not being ASCII, i.e. [a- z, 0-9].

As such, does it mean that accented Latin characters are acceptable as IDN
ccTLDs in the Fast Track?

2.  Do we have a better definition of IDNA2008?  Are we talking about the
eventual RFC or the current draft?  Also, does it mean that the Fast Track
process cannot start before "IDNA2008" is completed?



Below are my personal thoughts on suggested rewording for Principle E and my
additions to the alternative views section.

Principle E:


E. The IDN ccTLD for Fast Track should be non-contentious within the
territory.

Delegation of an IDN ccTLD should only be possible in the Fast Track where
the designation of the selected delegate is non-contentious within the
territory.  This should be evidenced by the support/endorsement of the
relevant stakeholders in the territory for the selected delegate.  The IDN
ccTLD string proposed should be non-contentious within the territory, and
should be non-contentious for the security and stability of the Internet.
This should be evidenced by the support/endorsement of the relevant
stakeholders that the selected string is a meaningful representation of the
name of the territory and that the security and the stability for the
Internet community is maintained.



Alternative Views:

There is an alternative view that a mechanism to handle comments early in
the IDN ccTLD Fast Track process would be beneficial.  The mechanism should
allow potential issues that affect the security and stability of the
technical and social fabric of the Internet to be raised and subsequently
addressed to improve the efficiency and transparency of the overall process.

There are also alternative views that the IDN ccTLD string for Fast Track
should be non-contentious not only within the territory as defined in the
ISO 3166-1 list.  Because not all ccTLDs (i.e. the list of entries of in the
ISO 3166-1 standard), are sovereign countries, it may be useful to consider
non-contentiousness within a corresponding country, region or collective of
territories.  It was also identified that 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.

Another alternative view understands that based on available documentation
of ccTLD practices, including the GAC ccTLD principles, while it is accepted
that the delegation of a ccTLD should be a matter within the corresponding
territory, the current practice for the selection of the ccTLD string is
explicitly established through international collaboration.  More
specifically, the current ccTLD practice is not a mechanism whereby each
territory proposes a particular two-letter string to ICANN, but rather it
follows the process of the ISO 3166-1 standard.  The IDN ccTLD Fast Track,
will introduce a new method that cannot be said to be identical with the
current ccTLD practices.  Therefore, it is important to continue to
maintain, as the IDNC WG charter expresses, that the IDN ccTLD introduced in
the Fast Track should be non-contentious.

While this report is silent on the issue of whether any formal arrangement
should be established between ICANN and the Fast Track IDN ccTLD, an
alternative view holds that in consideration of the overarching technical
requirements for the deployment of IDN, this report should encourage ICANN
to have in place an expressed understanding with the Fast Track IDN ccTLD to
ensure continued compliance with the IDN standards and ICANN IDN Guidelines.
Furthermore, such expressed understanding should ensure a smooth transition
of the Fast Track IDN ccTLD to the ccPDP IDN process once it is established.




I will not likely be able to join for the good part of the call today, as I
will be speaking at an event at that time.  Will try to join as soon as
possible.  Anyway, I have spent quite some time thinking about the issues
raised in the last few months about this process and I hope the above
suggestions could help improve the chances that the Fast Track would really
work.

Edmon