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

[Steve DelBianco <sdelbianco@xxxxxxxxxxxxx>]

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.p
>> df 
> 
> 
> 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 
>