ICANN ICANN Email List Archives


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

[ccnso-idncctld] RE: [ccnso-idncctld] 答复: [ccnso-idncctld] 答复: [ccnso-idncctld] Draft Final Report

  • To: <ccnso-idncctld@xxxxxxxxx>
  • Subject: [ccnso-idncctld] RE: [ccnso-idncctld] 答复: [ccnso-idncctld] 答复: [ccnso-idncctld] Draft Final Report
  • From: "Edmon Chung" <edmon@xxxxxxxxxxx>
  • Date: Fri, 6 Jun 2008 15:40:00 +0800

In addition to Jian's note, I would like to reiterate, as described in the
thread subsequent to our last teleconference that it is inappropriate to
call these suggestions "minority report" because there is no evidence
showing any majority consensus on the matter.


Also, the characterization that " the string should be non-contentious both
within and outside the territory and consequently an objection procedure is
necessary" seems incorrect according to the discussion.


1. The two should be decoupled.  They are related but not necessarily a
consequence of each other.

2. In a previous thread on the mailing list there seems to be an emerging
consensus that characterization of an "objection procedure" is not conducive
to the discussion, rather that we should use wording such as "handling of


At the very least, I feel that these should be rectified to better reflect
the discussions we had.  In summary:


A. Instead of describing the point as "minority report" it should be
described as "alternative opinions"

B. That we should decouple the 2 distinct concepts presented in the "NOTE"
in Principle E

C. That we start to use "handling of comments" rather than "objection


Overall, I feel that the "Final Report" should have more extensive
discussion as well as a simple proposed mechanism.  The draft seems to be
lacking significantly in "reporting" the deliberations of the group.  While
I agree that the proposed mechanism should be simple, the "report" of our
deliberations should not be omitted.


More specifically, I believe we need to provide rationale on how we came to
these conclusions.






From: owner-ccnso-idncctld@xxxxxxxxx [mailto:owner-ccnso-idncctld@xxxxxxxxx]
On Behalf Of zhangjian
Sent: Friday, June 06, 2008 11:45 AM
To: 'Chris Disspain'; 'Bart Boswinkel'; ccnso-idncctld@xxxxxxxxx
Subject: [ccnso-idncctld] 答复: [ccnso-idncctld] 答复: [ccnso-idncctld]
Draft Final Report



Thanks for your quick response.





发件人: Chris Disspain [mailto:ceo@xxxxxxxxxxx] 
发送时间: 2008年6月6日 11:41
收件人: 'zhangjian'; 'Bart Boswinkel'; ccnso-idncctld@xxxxxxxxx
主题: RE: [ccnso-idncctld] 答复: [ccnso-idncctld] Draft Final Report




I have asked Bart to draft a response to this which we will send out asap
over the weekend. There are several issues that you raise which we will need
to responds to.


Thanks for your input.




Chris Disspain

CEO - auDA 

Australia's Domain Name Administrator




Important Notice - This email may contain information which is confidential
and/or subject to legal privilege, and is intended for the use of the named
addressee only. If you are not the intended recipient, you must not use,
disclose or copy any part of this email. If you have received this email by
mistake, please notify the sender and delete this message immediately.
Please consider the environment before printing this email.



From: owner-ccnso-idncctld@xxxxxxxxx [mailto:owner-ccnso-idncctld@xxxxxxxxx]
On Behalf Of zhangjian
Sent: Friday, 6 June 2008 13:24
To: 'Bart Boswinkel'; ccnso-idncctld@xxxxxxxxx
Subject: [ccnso-idncctld] 答复: [ccnso-idncctld] Draft Final Report


Dear all:


As I mentioned in the last call, before we submit the draft for public
review, there is an issue has to be addressed.


We all agree that IDN is a complicated issue. In all previous discussion,
there is consensus that when ccTLD represented in one’s native language,
there would be many potential complications with the meaning of the string
that represent (that was one of the major reasons for setting up fast-track
process). We can foresee that one string selected by one territory may cause
uncomfortableness of another territory which is using the same language.
Further, there is no definition of the term “territory” in the current
draft, and the different understanding of the term from related parties may
cause future disputes over an application. And that, may just jeopardize the
effectiveness of the fast-track. To ensure the fast-track to be truly
“fast”, I’d propose we substitute the term “territory” with
“country/region” based on the following reason:

The proposed string is meaningful, which means along side with the string to
be a meaningful representation of the “territory” in one’s native
language, the string may contain cultural and political connotations. This
is one important characteristic of IDN, compare to the ASCII short code
representation of an “area”. I think the term “country/region” will work
better to avoid such complications than “territory”.

Hence, in order to avoid any potential dispute and to confine Fast Track to
a limited and non-contentious scope, this is advisable that we use the term
“country/region” as a desirable wording instead of “territory”. Or at
least, we should note in the draft that consensus should be reached not only
“within territory”, but also “among territories if necessary”.


Best regards

Jian Zhang





发件人: owner-ccnso-idncctld@xxxxxxxxx
[mailto:owner-ccnso-idncctld@xxxxxxxxx] 代表 Bart Boswinkel
发送时间: 2008年6月4日 21:05
收件人: ccnso-idncctld@xxxxxxxxx
主题: [ccnso-idncctld] Draft Final Report


Dear All,
Included is the first version of the draft Final Report. To be discussed at
the next call. The next IDNC WG call is scheduled for Wednesday 11 June
2008, at noon (12 am) UTC. 

Those members of the IDNC WG who think that Principle E should be re-worded
and/or there should be an objection procedure, please provide wording to be
inserted. In the draft is a section for minority views. It would be most
helpful if the wording could be provided two day in advance of the next IDNC
WG call.

The intention is to post the draft Final Report on the ICANN Website by 13
June 2008.

Kind regards,

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

Privacy Policy | Terms of Service | Cookies Policy