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

["Marilyn Cade " <marilynscade@xxxxxxxxxxx>]

:-)
We actually made a lot of progress /and needed to do so, due to an unfortunate 
attitude of some operational staff, legal staff, and Board members -- BEFORE 
getting to agreement to do a PDP. I agree that the PDP was an essential element 
to policy that is enforceable across the board. It was a large group of 
resellers of contracted parties, also. No need to highight the details oin the 
comments. 

In that light, I agree. 
Marilyn
Sent via BlackBerry by AT&T

-----Original Message-----
From: Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>
Date: Wed, 31 Mar 2010 12:46:34 
To: <marilynscade@xxxxxxxxxxx>; <bc-gnso@xxxxxxxxx>
Subject: Re: [bc-gnso] Last Call:   BC Position on New TLD Registry
 Agreement Amendments DAG v3

Marilyn - I think your notes on the domain tasting episode actually help 
showwhy it's a great example of how we can use the Consensus Policy 'picket 
fence' to amend all registry and registrar contracts.    

As you say, some contract parties did not support the domain tasting policy 
change.  But the PDP process and community pressure eventually did prevail - 
thanks in large measure to your own persistence on this issue.   Once staff 
provided implementation details, the new policy was automatically applied to 
ALL contracts, without delays, lawsuits or appeals.  

I can't think of a better example of how we empower the community to develop 
consensus policies that force all contract parties to comply, no matter what's 
in their own  contract/agreement or business plan.

Seeing it in that light, would you agree to retain the example in our position 
statement?

--Steve



On 3/31/10 7:41 AM, "Marilyn Cade" <marilynscade@xxxxxxxxxxx> wrote:


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

Last Call:   BC Position on New TLD Registry Agreement Amendments DAG v3 
Thanks Steve, Jon and Ron.  I support this position.

 

Mike Rodenbaugh

RODENBAUGH LAW

tel/fax:  +1 (415) 738-8087

http://rodenbaugh.com <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.  
 
 
 
       

-- 
Steve DelBianco
Executive Director
NetChoice
http://www.NetChoice.org and http://blog.netchoice.org 
+1.202.420.7482