Re: [bc-gnso] Draft v1 of BC comments on latest gTLD Guidebook

[Jon Nevett <jon@xxxxxxxxxx>]

Steve:

Thanks for pulling this together.  

I agree with Jarkko on his point about not limiting the round to an artificial 
number.  The round will be limited based on a number of factors, including 
price, duration, technology, etc.  There will be a natural batching and timing 
deviation for the reasons Jarkko mentions as well.    

Also, could you confirm that the GAC (in either its scorecard or subsequent 
responses) does, indeed, support each of the bullet points quoted below as we 
imply that it does?  I think that we should be sure that we are entirely 
factually accurate on these.     

Finally, I would support a shorter set of comments with just the highlights or 
summary points instead of another 19 page comment set.

Thanks.

Jon


"However, many other BC comments have been disregarded without explanation, 
despite agreement from multiple stakeholders, including the Governmental 
Advisory Committee (GAC). Notable are several previous BC recommendations to 
raise the integrity and availability of new gTLDs:

·       *The first batch should be limited to significantly fewer than 500 
applications, in order to test the operational readiness of newly designed 
application processing and objection / contention systems.

·       *Applicants should be granted fee reductions for additional versions of 
the applied-for string in IDN scripts and other languages.

·       *String Similarity contention sets should not include similar strings 
requested by a applicant seeking linguistic variations of the applicant's other 
applied-for string.

·       *Applicants should be required to pay an objection Response Filing Fee 
in order to defend the rationale already included in their original application.

·       *Community priority evaluation should be given to applicants scoring at 
least 13 points, not 14. 

·       *RPMs are still substantially weaker than those recommended by the IRT. 
 Consumers and businesses will inevitably be harmed by cybersquatting and other 
fraud likely to occur in hundreds of new gTLDs, especially at the second 
level." 

 



On Apr 27, 2011, at 2:57 PM, Steve DelBianco wrote:

> Per discussion on our 21-Apr member call, here is a draft framework for BC 
> comments on the 15-Apr-2011 Guidebook.
> 
> This comment period and docs are described at 
> http://icann.org/en/topics/new-gtlds/comments-6-en.htm 
> These comments are due 15-May, giving us 18 days for edits, review, and 
> approval.
> 
> For this initial draft, I updated our Dec-2010 Guidebook comments in several 
> ways:
>> - Acknowledged areas where ICANN made changes consistent with BC 
>> recommendations.
>> - Moved all our RPM concerns to Module 5
>> - Asked several questions for BC members (in red) 
>> - Added a proposed definition for "Single-Registrant TLD".   We may hold a 
>> separate call on this.
>> 
> All BC members are invited to suggest edits.     Please use track changes and 
> circulate to BC list.   
> I will assemble another draft version with all changes received as of May 1. 
> 
> Below are the primary contributors from our Dec-2011 comments, organized by 
> module. 
> 
>> Module 1: Introduction to New gTLD Application Process and Fees.  (Berry 
>> Cobb, Ron Andruff )
>> 
>> Module 2: Evaluation Procedures.    (Philip Sheppard, Jon Nevett,  Adam 
>> Palmer,  Zahid Jamil,  Sarah Deutsch )
>> 
>> Module 3: Dispute Resolution. ( John Berard, Ron Andruff )
>> 
>> Module 4: String Contention.   ( Ron Andruff )
>> 
>> Module 5: Transition to Delegation; Registry Agreement, Code of Conduct, RPMs
>> ( Philip Sheppard, Fred Fellman,  Berry Cobb, Jon Nevett, Sarah Deutsch )
>> 
> 
> Other notes:
>> In our SFO comments, the BC said the new gTLD communications plan should 
>> help the world's businesses and users understand changes coming in the DNS.  
>> But I didn't see anything in the latest Guidebook about the Communications 
>> Plan. So that comment was not reflected in the attached draft. 
> 
> 
> 
> Steve DelBianco
> vice chair for policy coordination
>> 
> 
> <BC on Apr-2011 App Guidebook.docx>