ICANN ICANN Email List Archives

[bc-gnso]


<<< Chronological Index >>>    <<< Thread Index >>>

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

  • To: "'Jon Nevett'" <jon@xxxxxxxxxx>
  • Subject: RE: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement Amendments DAG v3
  • From: "Ron Andruff" <randruff@xxxxxxxxxxxxxxx>
  • Date: Wed, 31 Mar 2010 11:14:12 -0400

Marilyn and all,

 

Please have a look at the redline version attached and advise if this meets
the suggested need.  I have added in both yours and Jon's comments to expand
that section.

 

Thanks,

 

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
Jon Nevett
Sent: Wednesday, March 31, 2010 10:57 AM
To: Ron Andruff
Cc: 'Marilyn Cade'; 'bc - GNSO list'
Subject: Re: [bc-gnso] Last Call: BC Position on New TLD Registry Agreement
Amendments DAG v3

 

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

 

Attachment: BC on new TLD contract amendment Draftv4 (RA).doc
Description: MS-Word document



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy