Re: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3

[Jon Nevett <jon@xxxxxxxxxx>]

Agreed.  Rogue by definition refers to unprincipled or dishonest actors, so I 
think we are ok with registries that are just unique, but not rogue.  

Thanks.

Jon

On Mar 31, 2010, at 10:44 AM, Ron Andruff wrote:

> Marilyn,
>  
> Regarding your comment on ‘rogue’ registries, this refers specifically to 
> undertakings that are deemed to damage the integrity of the Internet and 
> ICANN, which ultimately harms both individual users and specific communities. 
>  For example the current managers of .TRAVEL have been using that registry as 
> their ‘own pool of domain names’, which irrespective of other’s IP rights are 
> purchased and held in a separate company (held 100% by the managers of 
> .TRAVEL) which has been set up solely to try to monetize their .TRAVEL domain 
> names.  In order to do this, they first established a self-serving bulk 
> purchase policy at massive discounts to the industry retail price.  These are 
> the types of rogue issues that we are recommending ICANN address in the new 
> gTLD contracts – specifically by providing compliance with effective tools to 
> allow them to address the types of issues noted above as soon as they arise.
>  
> Hope this helps to clarify the matter for you and all of the members.
>  
> Kind regards,
>  
> RA
>  
> Ronald N. Andruff
> President
>  
> RNA Partners, Inc.
> 220 Fifth Avenue
> New York, New York 10001
> + 1 212 481 2820 ext. 11
>  
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Marilyn Cade
> Sent: Wednesday, March 31, 2010 7:42 AM
> To: bc - GNSO list
> Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement 
> Amendments DAG v3
>  
> 
> Thanks, Steve, Jon, and Ron, for your work on this position. I largely 
> support the perspective in the document. 
>  
> However, I would propose a change:  I think that your use of domain name 
> tasting as an example is actually not fully factual. I'd propose that you 
> simply strike that example. The PDP 06 is a better example, but I don't think 
> you should substitute it. Instead, just strike the reference to the specific 
> example. [first paragraph under the source: citation]. 
> It would take too much time and detail to factually explain this topic. I'd 
> propose just to remove it as an example. 
>  
> Background to why I am proposing that change:   The BC [and IPC] led a 
> significant effort to push forward awareness of kiting, tasting, and parking, 
> against considerable opposition from some other constituencies within ICANN.  
> The data gathering efforts, which included informational exchanges with the 
> ICANN staff and Board, and by some members of the BC with legal and 
> operational staff was very challenging.  The PDP process could have 
> floundered due to lack of support by some of the constituencies.   Some 
> parties in the business community undertook extensive work, outside of ICANN, 
> to deal with aggregious tasting/parking/kiting when it involved trademarked 
> names.  These actions helped to educate and inform ICANN staff and Board.  
> Ultimately, it was the combination of external and awareness efforts that 
> built willingness to address this contentious issue within the ICANN PDP 
> process.  
>  
> Overall comment:  In reading this, i would note that the BC needs to be very 
> sensitive in our positions, focusing on our role and responsibility as the 
> BC, to be business user centric. Business users are affected by these 
> policies differently than the supplier/contracted parties are.  
>  
> Finally, there is a reference to 'rogue issues', or 'rogue registry'.  A 
> registry with very unique characteristics, such as a brands focused registry, 
>  might find certain requirements impossible to agree to -- e.g. the transfer 
> of the registry operations in the event of a decision to close the registry.  
> This would not make them a 'rogue' registry. 
>  
> Marilyn Cade
> speaking in individual capacity as a BC member
>  
>  
> From: icann@xxxxxxxxxxxxxx
> To: bc-GNSO@xxxxxxxxx
> Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement 
> Amendments DAG v3
> Date: Tue, 30 Mar 2010 17:04:29 -0700
> 
> Thanks Steve, Jon and Ron.  I support this position.
>  
> Mike Rodenbaugh
> RODENBAUGH LAW
> tel/fax:  +1 (415) 738-8087
> http://rodenbaugh.com
>  
> From: owner-bc-gnso@xxxxxxxxx [mailto:owner-bc-gnso@xxxxxxxxx] On Behalf Of 
> Steve DelBianco
> Sent: Tuesday, March 30, 2010 3:31 PM
> To: bc-GNSO@xxxxxxxxx
> Subject: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement 
> Amendments DAG v3
>  
> Last call, folks.   Below is the draft BC position on new TLD Registry 
> Agreement Amendments.  
> 
> Ron Andruff and Jon Nevett provided the draft.  I’ve signaled my agreement, 
> as did Berry Cobb.
> 
> Absent objections by COB tomorrow, we will file as consensus BC comments on 
> 1-Apr-2010. 
> 
> --Steve
> 
> Business & Commercial Users’ Constituency (BC) 
> Position/Comments on Process for Amendments to New gTLD Registry Agreements
> The Commercial and Business Users Constituency (BC) welcomes the opportunity 
> to comment on the New gTLD Program Explanatory Memorandum on the Process for 
> Amendments to New gTLD Registry Agreements, which was published for public 
> comment on February 15, 2010 (see 
> http://icann.org/en/announcements/announcement-4-15feb10-en.htm ).
> 
> ICANN seeks comment as to a fair process to amend New TLD registry 
> agreements.  In DAG v.3, ICANN proposed that it could unilaterally amend 
> registry agreements even after a majority of the registry operators rejected 
> such amendments.  The Registries Stakeholder Group (RySG) recently has 
> proposed a system of good faith negotiations between ICANN and the registry 
> operators, but that each registry would have a veto on proposed changes to 
> that registry agreement.
> As a matter of policy, the BC believes that businesses should not be subject 
> to agreements where the other party has the unilateral right to amend such an 
> agreement.  ICANN’s proposal in which the ICANN Board could unilaterally 
> impose a change to registry agreements notwithstanding the objections of a 
> majority of registry operators, the BC, or any other ICANN organization is an 
> anathema to ICANN’s bottom-up policy making roots.  
> 
> Similarly, the RySG’s proposal, in which each individual registry has the 
> ability to veto a proposed change, also is inconsistent with the efficient 
> functioning and scalability of the New gTLD program.  This issue requires a 
> “balanced” approach that satisfies both parties.  
> The BC analyzes the issue based on whether proposed changes are within the 
> so-called “picket fence” – and subject to Consensus Policy – or not.  All 
> contractual changes should be made in a transparent manner with input from 
> the community. 
> 
> For issues within the picket fence, there is an existing Policy Development 
> Process that carries the power to change all registry and registrar 
> agreements.  As described in current and proposed registry contracts, the 
> picket fence includes most conceivable ways that community and BC members 
> would need to control registry practices:
> 
> 1.2.1. issues for which uniform or coordinated resolution is reasonably 
> necessary to facilitate interoperability, security and/or stability of the 
> Internet or DNS;
> 
> 1.2.2. functional and performance specifications for the provision of 
> registry services; 
> 
> 1.2.3. Security and stability of the registry database for the TLD;
> 
> 1.2.4. registry policies reasonably necessary to implement Consensus Policies 
> relating to registry operations or registrars; or
> 
> 1.2.5. resolution of disputes regarding the registration of domain names (as 
> opposed to the use of such domain names).
> 
> 1.3.1. principles for allocation of registered names in the TLD (e.g., 
> first-come/first-served, timely renewal, holding period after expiration);
> 
> 1.3.2. prohibitions on warehousing of or speculation in domain names by 
> registries or registrars;
> 
> 1.3.3. reservation of registered names in the TLD that may not be registered 
> initially or that may not be renewed due to reasons reasonably related to (i) 
> avoidance of confusion among or misleading of users, (ii) intellectual 
> property, or (iii) the technical management of the DNS or the Internet (e.g., 
> establishment of reservations of names from registration); and
> 
> 1.3.4. maintenance of and access to accurate and up-to-date information 
> concerning domain name registrations; and procedures to avoid disruptions of 
> domain name registrations due to suspension or termination of operations by a 
> registry operator or a registrar, including procedures for allocation of 
> responsibility for serving registered domain names in a TLD affected by such 
> a suspension or termination.
>  
> Source: 
> http://icann.org/en/topics/new-gtlds/draft-agreement-specs-clean-04oct09-en.pdf
> 
> By way of example, a picket fence PDP was how the BC and other community 
> members put a stop to domain tasting that was occurring by abuse of the 
> add-grace period.  While many felt that a 2-year PDP and implementation 
> process took too long, this experience showed that the system works, 
> generating a policy outcome that became part of all registrar and registry 
> agreements.
> 
>  Therefore, ICANN shouldn’t have the ability to unilaterally change such 
> agreements without community consent, and the BC does not see any need for a 
> separate process for amendment on top of the current PDP process.  The ICANN 
> community is tasked with making policy; not the ICANN Board or staff.  We 
> have a process to make changes now.  If that process needs improvement, let’s 
> improve it. Giving ICANN the ability to unilaterally amend the Registry 
> contract is not the answer.
> Certain other issues outside the picket fence also should not be subject to 
> unilateral changes, such as pricing, ICANN fees, and other similar topics 
> where neither party can unilaterally amend an agreement without consent of 
> the other party to the contract.  
> 
> There are some issues outside the picket fence, however, where ICANN and/or 
> the community should be able to amend registry agreements without the 
> specific consent of every single registry operator, as long as there is a 
> consensus of the community.  These issues should include security and 
> stability issues, enforcement tools, registrant protections, and promoting a 
> stable marketplace, and should be enforceable against all registry operators. 
> For example, compliance staff must have the tools to enforce the registry 
> agreements against potential bad actor registries.  One rogue registry should 
> not be able to veto changes that the rest of the community supports. Similar 
> changes to the Registrar Accreditation Agreement were recently adopted 
> without each registrar being able to veto the changes.  
> 
> Even with such rogue issues, neither the ICANN staff nor the Board should be 
> able to amend registry agreements without community involvement and input 
> from the registry operators.  All changes – regardless of the issue -- must 
> be transparent and exhibit the appropriate level of accountability to the 
> community. 
> 
> ICANN needs to strike a balance in the manner in which registry agreements 
> are amended.  In the BC’s view, neither the current ICANN proposal nor the 
> RySG proposal succeeds in doing so yet.  
>  
>  
>