Re: [gnso-vi-feb10] One Proposal

[Jon Nevett <jon@xxxxxxxxxx>]

That approach works with me as well.  I'm not looking for a first mover 
advantage -- just looking to advance the ball.  I am very open to other 
proposals.  

We can get into the substance when the group is ready, but the "flaw" that 
Antony raised in the .mobi language might be considered a benefit to many.  
This might be a situation that calls for some flexibility to deal with known 
infirmities in other proposals, and that would minimize unintended 
consequences.  With that said, such flexibility must be curbed with objective 
standards.  It also provides for a contractual safety net for ICANN and 
registry operators that already exists and hasn't been abused in the current 
marketplace.    

Anyway, I'm looking forward to discussing the various approaches and proposals 
at whatever time the group believes is appropriate.

Best,

Jon


On Mar 24, 2010, at 2:17 PM, Milton L Mueller wrote:

>  
> Good comments, Jeff. I like the proposed approach. We should also encourage 
> parties submitting proposals to coordinate with other WG members to submit 
> joint proposals with multiple supporters.
> Milton Mueller
> Professor, Syracuse University School of Information Studies
> XS4All Professor, Delft University of Technology
> ------------------------------
> Internet Governance Project:
> http://internetgovernance.org
> 
>  
>  
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Neuman, Jeff
> Sent: Wednesday, March 24, 2010 12:56 PM
> To: Jon Nevett; Gnso-vi-feb10@xxxxxxxxx
> Subject: RE: [gnso-vi-feb10] One Proposal
> 
> Thanks Jon for this straw man.  I am not saying I agree or disagree with your 
> proposal at this point. 
>  
> What I propose, rather than getting fixated on one model, is to allow for two 
> weeks for the WG members to submit their proposals to the WG.  [We can 
> discuss the appropriate time frame].  Then the WG can analyze the pros and 
> cons of each proposal and decide how to process.  I do not believe that a PDP 
> process should be rushed simply because the ICANN Board decided to punt the 
> issue.  Nor do I believe that since you are the first one to submit a 
> proposal, that your proposal is given a “first mover advantage” for being the 
> first formally submitted.  Remember, this is a formal PDP process and not an 
> STI-type process.  We are chartered by the GNSO Council and not the Board.
> 
> 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.
>