ICANN/GNSO GNSO Email List Archives

[council]


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

RE: [council] FW: [ccnso-idncctld] Draft Final Report

  • To: "Edmon Chung" <edmon@xxxxxxxxxxx>, "Council GNSO" <council@xxxxxxxxxxxxxx>
  • Subject: RE: [council] FW: [ccnso-idncctld] Draft Final Report
  • From: "Gomes, Chuck" <cgomes@xxxxxxxxxxxx>
  • Date: Wed, 11 Jun 2008 17:41:07 -0400
  • In-reply-to: <000401c8cbea$0eb18580$2c149080$@org>
  • List-id: council@xxxxxxxxxxxxxx
  • Sender: owner-council@xxxxxxxxxxxxxx
  • Thread-index: AcjGQ5jg70yDg10XpE+I+IPdWWm24QBXu/SwALkCgdAACf8t8AA60FHAABxhRDA=
  • Thread-topic: [council] FW: [ccnso-idncctld] Draft Final Report

Thanks for the feedback Edmon.  I find it ironic that the ccNSO is looking for 
the Board to make the hard decisions on delegation in contrast to what we did 
in the GNSO in trying to minimize putting the Board in that position.  I am not 
sure they would have done it for us anyway but it will be revealing if they do 
it for the ccNSO.

Chuck 

> -----Original Message-----
> From: owner-council@xxxxxxxxxxxxxx 
> [mailto:owner-council@xxxxxxxxxxxxxx] On Behalf Of Edmon Chung
> Sent: Wednesday, June 11, 2008 1:39 PM
> To: 'Council GNSO'
> Subject: RE: [council] FW: [ccnso-idncctld] Draft Final Report
> 
> 
> Hi Chuck,
> 
> Thanks for the fresh eyes on the document.
> 
> > 'C: Purpose of Fast Track is to meet pressing demand'
> > * I find it interesting that 'pressing demand' will be measured by 
> > 'readiness of the selected delegate and relevant 
> stakeholders in the 
> > territory to meet the requirements to introduce an IDN ccTLD'.
> 
> Good point.  I think it was meant to be a balance of pressing 
> demand and an effective Fast Track.  The Fast Track is also 
> expected to be on-going and the expectation is that those 
> would pressing demand would get themselves ready.
> 
> > * If that is ultimately what is decided, am I correct in concluding 
> > that
> any
> > ccTLD organization that is ready will be deemed to have a 
> pressing demand?
> 
> I do not think that is true.  In fact the report has already 
> indirectly defined pressing demand in the sense that the 
> script of the IDN TLD string should be non-Latin based.
> 
> > * Sorry for the unrealistic example and one that will not be allowed
> because
> > it is a non-Latin script but I think it illustrates my point:  If 
> > deNIC demonstrates it is ready to offer name registration 
> services for 
> > .deutschland, then they will have satisfied the criterion; is that 
> > accurate?  So they would be deemed to establish pressing 
> demand even 
> > if there isn't any.
> > * The same flawed logic could be used for a non-Latin script.
> 
> The reasoning is that those with pressing demand would get 
> themselves ready.
> The reverse was not considered.  It is a good point and one 
> which I will try to convey to the group.
> 
> > * It might make more sense to have a criterion of readiness 
> instead of 
> > pressing demand if that is the way it will be measured.
> 
> That is i think the idea.
> 
> 
> > E: The proposed string and delegation request should be 
> > non-contentious within the territory * I won't restate the problems 
> > you are already aware of with regard to the definition of 
> > non-contentious.
> 
> :-)
> 
> 
> > Section 4
> > 
> > 'Stage 1: Preparing for the Fast Track in Territory'
> > * How is a delegate selected?
> > * Who selects a delegate?
> > * Is that left totally up to the local community?
> 
> Yes the argument presented by the draft's authors are that 
> they are considered entirely in-territory process.
> 
> 
> > "Requirements relating to the script
> > 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]."
> > * This definition may need to be refined.  As I read it, it 
> could be 
> > interpreted to mean that German, Spanish and French are based on 
> > non-Latin scripts because they each have non-ASCII characters.
> 
> Good point.  Will address this with the group.
> 
> 
> > 'Technical Requirements'
> > * In the 1st & 7th bullets, what is meant by 'IDNA2008'?
> > * Does it refer to the yet to be revised IDNA protocol?
> > * If so, is it accurate to assume that fast track ccIDNs 
> will not be 
> > introduced until the IDNA protocol revision is finished?
> 
> Good point.  I think it is anticipated that IDNA2008 will be 
> completed by that time, but I will ask the specific question.
> 
> > 
> > 
> > Implementation Questions
> > * In reading this document, I can't help but think that 
> implementing 
> > these recommendations is going to be complex and time-consuming not 
> > unlike implementation of the new gTLD recommendations.  Do 
> you agree?
> 
> Yes I agree.  I also think it will require the board to 
> potentially make hard decisions if in fact comments or 
> concerns are being raised with regards to a particular Fast 
> Track IDN ccTLD application.  The current process provides 
> the board with limited information from the community at 
> large or inter-territory issues to make or I think even 
> consider such discussions.
> 
> 
> > * Have there been any discussions about implementation?  
> How it would 
> > happen?  How long it might take?  etc.
> 
> The concept in brief is to have all preparations completed 
> within the corresponding territory, then a simple delegation 
> request which would require the two committees to "check" the 
> application, and then have the board decide on everything 
> else.  Including the determination of whether an application 
> is in fact non-contentious.
> 
> That is an important reason for the on-going principle (i.e. 
> those who are ready can go first, but realistically it is a 
> long process).
> 
> > 
> > Thanks for all of the time each of you are spending on this work.
> 
> Am continuing to try hard to bring up the issues and discuss, 
> however, being from the GNSO brings, it seems, a 
> pre-determined bias that somehow the gTLDs want to delay this 
> process.  I find it some what discouraging to hear that and 
> continue to hope that the contributions are in fact positive 
> even if it means pointing out potential issues of the current design.
> 
> Edmon
> 
> 
> 
> 
> > 
> > Chuck Gomes
> > ________________________________________
> > From: owner-council@xxxxxxxxxxxxxx 
> > [mailto:owner-council@xxxxxxxxxxxxxx]
> On
> > Behalf Of Edmon Chung
> > Sent: Friday, June 06, 2008 3:04 AM
> > To: 'Council GNSO'
> > Subject: [council] FW: [ccnso-idncctld] Draft Final Report 
> Attached is 
> > the draft IDNC final report by Bart and Chris Edmon
> > 
> > 
> > From: owner-ccnso-idncctld@xxxxxxxxx
> [mailto:owner-ccnso-idncctld@xxxxxxxxx]
> > On Behalf Of Bart Boswinkel
> > Sent: Wednesday, June 04, 2008 9:05 PM
> > To: ccnso-idncctld@xxxxxxxxx
> > Subject: [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,
> > Bart
> 
> 
> 




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