Re: [gnso-vi-feb10] One Proposal

[Avri Doria <avri@xxxxxxx>]

Hi,

Might be worth sending the collection of proposals people will be drafting 
(recommendations under phasing thread) out to for the public comment.
This gets comments in early, but gives people some substance to comment on.

a.

On 24 Mar 2010, at 15:36, Neuman, Jeff wrote:

> I am fine with discussing it on the next call or pursuing that strategy, but 
> everyone should understand that a later comment period would still have to be 
> 20 days and not be a substitute or replacement for the public comment period 
> after the “initial report” and after the “final report” before council 
> consideration.  The longer we wait to start the 1st comment period, the more 
> delay that will cause.
>  
> Jeffrey J. Neuman 
> Neustar, Inc. / Vice President, Law & Policy
> 
> The information contained in this e-mail message is intended only for the use 
> of the recipient(s) named above and may contain confidential and/or 
> privileged information. If you are not the intended recipient you have 
> received this e-mail message in error and any review, dissemination, 
> distribution, or copying of this message is strictly prohibited. If you have 
> received this communication in error, please notify us immediately and delete 
> the original message.
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Margie Milam
> Sent: Wednesday, March 24, 2010 2:22 PM
> To: Gnso-vi-feb10@xxxxxxxxx
> Subject: RE: [gnso-vi-feb10] One Proposal
>  
> Jeff,
>  
> The public comment period was on our agenda to discuss yesterday, but we did 
> not get to it.   In past PDPs, the working group has been involved with 
> crafting questions to be included in the public comment forum, which is 
> something that might be beneficial for this working group.  For example, the 
> WG might seek comment on specific options for vertical integration for the 
> New gTLD Program.   We should discuss this on the next VI WG call to decide 
> how the WG would like to conduct the initial public comment period.
>  
> Best Regards,
>  
> Margie
>  
> ____________
>  
> Margie Milam
> Senior Policy Counselor
> ICANN
> ____________
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Jeff Eckhaus
> Sent: Wednesday, March 24, 2010 11:43 AM
> To: Gnso-vi-feb10@xxxxxxxxx
> Subject: RE: [gnso-vi-feb10] One Proposal
>  
> Marika/Margie – If there is supposed to be a 20 day comment period, when will 
> that begin?
>  
>  
> Thanks
>  
> Jeff
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Neuman, Jeff
> Sent: Wednesday, March 24, 2010 10:31 AM
> To: Jothan Frakes
> Cc: Jon Nevett; Gnso-vi-feb10@xxxxxxxxx
> Subject: RE: [gnso-vi-feb10] One Proposal
>  
> LOL.  Oops - 20 day public comment period J
>  
> Jeffrey J. Neuman 
> Neustar, Inc. / Vice President, Law & Policy
> 
> The information contained in this e-mail message is intended only for the use 
> of the recipient(s) named above and may contain confidential and/or 
> privileged information. If you are not the intended recipient you have 
> received this e-mail message in error and any review, dissemination, 
> distribution, or copying of this message is strictly prohibited. If you have 
> received this communication in error, please notify us immediately and delete 
> the original message.
>  
>  
> From: Jothan Frakes [mailto:jothan@xxxxxxxxx] 
> Sent: Wednesday, March 24, 2010 1:12 PM
> To: Neuman, Jeff
> Cc: Jon Nevett; Gnso-vi-feb10@xxxxxxxxx
> Subject: Re: [gnso-vi-feb10] One Proposal
>  
> Jeff, hopefully you meant to say "20 days of public comment" and not "20 
> public comment periods".  I realize it is somewhat of a nuance to the text 
> but I'm turning 42 in Brussels and I was in my mid 20s when this new TLD 
> process began. 
> 
> Jothan Frakes
> +1.206-355-0230 tel
> +1.206-201-6881 fax
> 
> On Wed, Mar 24, 2010 at 9:56 AM, Neuman, Jeff <Jeff.Neuman@xxxxxxxxxx> wrote:
> Technically, the PDP process requires a 20 public comments period at the 
> outset, which I do not believe has started.  I also believe that the Working 
> Group needs to spend some time familiarizing how we got to this point as I 
> know we have a number of new players.  Everyone needs to understand the 
> concerns expressed by all sides in this issue to evaluate any of the 
> proposals submitted.
>  
>  
> Best regards,
>  
> Jeffrey J. Neuman 
> Neustar, Inc. / Vice President, Law & Policy
> 
> The information contained in this e-mail message is intended only for the use 
> of the recipient(s) named above and may contain confidential and/or 
> privileged information. If you are not the intended recipient you have 
> received this e-mail message in error and any review, dissemination, 
> distribution, or copying of this message is strictly prohibited. If you have 
> received this communication in error, please notify us immediately and delete 
> the original message.
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Jon Nevett
> Sent: Wednesday, March 24, 2010 11:16 AM
> 
> To: Gnso-vi-feb10@xxxxxxxxx
> Subject: [gnso-vi-feb10] One Proposal
>  
> WG Colleagues:
>  
> As I stated last week, I agree with Milton's thinking that we should get on 
> with it and see if we can reach some kind of resolution and worry less about 
> the Board's potential default position.  I also am not concerned about what 
> we look to as a "baseline" -- but am more interested in what we look to as a 
> solution.  
>  
> In the interest of moving this forward, I think that we should take a close 
> look at the relevant language in the .mobi, .tel or .asia agreements on these 
> points.  I have copied the .mobi language below.  It seems to strike a 
> balance between the two sides of the debate that we saw in Seoul.  
>  
> Section 7.1(c) of the .mobi agreement keeps the .com, .net, .org, .biz, .info 
> prohibition on a Registry Operator having more than 15% ownership of a 
> registrar, but says that the registry could seek ICANN approval to purchase 
> more than 15%.  This kind of language would permit this WG to come up with 
> criteria for ICANN to use when evaluating a request for approval to exceed 
> 15%, and gives ICANN and the Registry Operators some flexibility when faced 
> with certain cases, including new and innovative business models.   As others 
> have mentioned, a hard and fast rule would have unintended consequences.  
>  
> This .mobi language would meet the calls of some in the community to keep the 
> status quo.  I think that Jeff Neuman mentioned a concern about using 
> sponsored TLD language as a model.  The most recent TLDs, however, sponsored 
> or not,  will more closely resemble the New TLDs than incumbent registries 
> with millions of domain names already under management.  
>  
> It also would solve the "small registry that has a hard time getting 
> registrars to sell its name" issue -- or the community issue that others have 
> raised.  I suspect that most folks would not have an issue with a registry 
> that doesn't have traction in the marketplace and can't get registrars to 
> sell its names starting its own registrar to sell its names.  This language 
> gives some latitude for ICANN to approve a waiver for a registry in that 
> position.  Size and registrar penetration rates could be factors that ICANN 
> takes into account in evaluating a RO's request to start or purchase its own 
> registrar.  Obviously, there would need to be others.  
>  
> It also would address the brand or single registrant TLD issue by giving New 
> TLD RO's the same ability that certain current RO's enjoy to select among the 
> hundreds of registrars based on objective criteria.  Once selected, the RO 
> could not discriminate against the registrars selected.  In other words, a 
> broad-based registry would want to select as many registrars as possible, but 
> a single registrant TLD would not have to select more than one.  As Avri 
> pointed out and as the GNSO already has approved, every registration would 
> need to be registered with the benefit of the requirements and obligations in 
> the RAA.  Also, it would maintain the requirement that RO's cannot 
> discriminate among registrars selling its names, but not every registrar need 
> to be able to sell every extension.  
>  
> I also would suggest some tweaks to the current .mobi language -- limiting 
> the 15% only to registrars that sell the registry operator's extension vs. 
> any registrar.  This was the position espoused by the incumbent registry 
> operators.  Therefore, an eNom-affiliate could apply for a name without 
> violating the agreement, but it couldn't sell it through its affiliated 
> registrar without ICANN approval.  I also would change the concept of 
> "acquire" to some type of corporate affiliation as Jeff N. also suggested.  
>  
> As far as phasing, if folks like a modified .mobi language, we could agree 
> soon on language to insert into the New TLD agreement in DAG 4.  We then 
> could start on discussing and debating the criteria that ICANN should 
> consider in evaluating waiver requests.  
>  
> I am trying to get the ball rolling with a way forward that doesn't hold up 
> New TLDs and provides ICANN with some flexibility, but doesn't open the 
> floodgates.  It also would give ICANN some latitude, but would give the 
> community the ability to shape and restrict ICANN's discretion.  
>  
> I am very open to discussing other proposals as well, but let's minimize 
> discussing processes and baselines and work towards solutions.  
>  
> Thanks.
>  
> Jon 
> .mobi Registry Agreement
> Section 7.1   Registry-Registrar Agreement.
> 
> a.  Access to Registry Services. Registry Operator shall make access to 
> Registry Services, including the shared registration system, available to 
> ICANN-accredited registrars. The criteria for the selection of registrars 
> shall be as set forth in Appendix S. Following execution of the 
> Registry-Registrar Agreement between Registry Operator and the 
> ICANN-accredited registrar, and subject to such registrar's compliance with 
> the Registry-Registrar Agreement, Registry Operator shall provide operational 
> access to Registry Services, including the shared registration system for the 
> TLD. Such nondiscriminatory access to such registrars shall include without 
> limitation the following:
>                     i.        All registrars (including any registrar 
> affiliated with Registry Operator) can connect to the shared registration 
> system gateway for the TLD via the Internet by utilizing the same maximum 
> number of IP addresses and SSL certificate authentication;
>                  ii.         Registry Operator has made the current version 
> of the registrar toolkit software accessible to all registrars and has made 
> any updates available to all registrars on the same schedule;
>                iii.        All registrars have the same level of access to 
> customer support personnel via telephone, e-mail and Registry Operator's 
> website;
>                iv.        All registrars have the same level of access to 
> registry resources to resolve registry/registrar or registrar/registrar 
> disputes and technical and/or administrative customer service issues;
>                   v.        All registrars have the same level of access to 
> data generated by Registry Operator to reconcile their registration 
> activities from Registry Operator's Web and ftp servers;
>                vi.        All registrars may perform basic automated 
> registrar account management functions using the same registrar tool made 
> available to all registrars by Registry Operator; and
>              vii.        The shared registration system does not include, for 
> purposes of providing discriminatory access, any algorithms or protocols that 
> differentiate among registrars with respect to functionality, including 
> database access, system priorities and overall performance.
> Such Registry-Registrar Agreement may be revised by Registry Operator from 
> time to time, provided however, that any such revisions must be approved in 
> advance by ICANN.
> 
> b. Registry Operator Shall Not Act as Own Registrar. Registry Operator shall 
> not act as a registrar with respect to a “domain name registration” as that 
> term is defined in Section 7.2(b) below. This shall not preclude Registry 
> Operator from registering names within the TLD to itself through a request 
> made to an ICANN-accredited registrar.
> c.   Restrictions on Acquisition of Ownership or Controlling Interest in 
> Registrar. Registry Operator shall not acquire, directly or indirectly, 
> control of, or a greater than fifteen percent ownership interest in, any 
> ICANN-accredited registrar, without ICANN's prior approval in writing, which 
> approval shall not be unreasonably withheld.
> 
> Appendix S
> Part 5
> 
> Selection of Registrars
> 
> Subject to Registry Operator’s compliance with this Registry Operator TLD 
> Registry Agreement, including all attachments and appendices thereto (the 
> “Agreement”) and any Temporary Specifications or Policies or Consensus 
> Policies as defined in the Agreement, and provided the scope of the Charter 
> is not exceeded:
> 
> Registry Operator will select registrars from among ICANN-Accredited 
> Registrars in a manner that promotes the following characteristics in the 
> group of authorized ICANN-Accredited Registrars:
> 1. Recognition of the specific aspects of the mobile services community to be 
> supported by the sTLD and a willingness to participate in that spirit;
> 2. Thorough understanding of the principles and goals underlying sTLD 
> policies, including without limitation the domain name management policy;
> 3. Demonstrated ability to provide Eligibility and Name-Selection Services 
> (ENS Services) and demonstrated familiarity with the needs of the sTLD 
> Community in the language and region(s) served by the registrar, and 
> established modes for reflecting these needs in the ENS Services processes;
> 4. Dedicated willingness and ability to propagate and enforce sTLD policies 
> in an observant and diligent manner and in accordance with policies and 
> procedures prescribed by Registry Operator;
> 5. Broad geographic distribution and language diversity of registrars;
> 6. Established collaborative contact with one or several associations 
> representing Providers and Representatives (as defined in Part 3 above) in 
> the language and geographical region or sector served by the registrar;
> 7. Dedicated willingness and ability to act together with the mobile 
> communications community in the processing of registration requests.
> 8. Established business relationships with substantial numbers (proportionate 
> to the size of the registrar) of Providers and Representatives in the 
> region(s) served by the registrar;
> 9. Demonstrated willingness and ability to publicize and market the sTLD, to 
> follow all sTLD marketing guidelines, and to develop and use sTLD marketing 
> materials as appropriate, as reflected by a minimum committed marketing 
> budget of an amount proportionate to the size of the registrar;
> 10. Demonstration that sufficient staff resources are available and able to 
> interface with automated and manual elements of the sTLD registry process and 
> a willingness to implement modifications and revisions reasonably deemed by 
> the Registry Operator to be required based on the characteristics and 
> functions of the sTLD;
> 11. The existence of proven systems designed to avoid submission of 
> unqualified or incomplete applications that will burden the ENS system or 
> make it impossible for Registry Operator to fulfill its commitments to ICANN;
> 12. The existence of proven systems to avoid transfer disputes among 
> registrars;
> 13. Demonstrated willingness to share relevant marketing information with the 
> Registry Operator, including, consistent with applicable law, information 
> about current registrants with whom the registrar has relationships who are 
> eligible for registration.
> 14. Willingness to provide reduced fee or free services to Providers and 
> Representatives from developing countries who meet minimum criteria 
> reasonably established by Registry Operator for special assistance; and
> 15. Willingness and ability to post and refresh a minimum deposit against 
> which fees will be drawn.
> This Part 5 of this Appendix S specifies the criteria for Registry Operator’s 
> selection of ICANN Accredited Registrars wishing to enter into a 
> Registry-Registrar Agreement to register domain names in the sTLD. Registry 
> Operator will determine the initial number of ICANN-Accredited Registrars to 
> be selected and, in collaboration wit the sTLD Community, will review and 
> revise its selection of registrars and registrar criteria from time to time 
> as appropriate.
>  
>