ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

Re: [gnso-vi-feb10] The need to evaluate options in a consistent manner

  • To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] The need to evaluate options in a consistent manner
  • From: Jon Nevett <jon@xxxxxxxxxx>
  • Date: Fri, 9 Apr 2010 10:03:53 -0400

Folks:

Recommendation 19 says that registries must use registrars.  It doesn't say 
that registries may not become registrars and handle registrar functions as 
well.  In the SR use case, what is the big deal about having a registry handle 
the registrar functions and being considered both a registry and registrar?  As 
I have pointed out before, registrar functions include certain consumer 
benefits, including all of the requirements in the RAA and Consensus Policies. 

Here is an example -- let's say United Airlines gets .united as an SR -- only 
it and its employees can use it.  At some point, they start selling 
international storage services at www.storage.united.  Little did they know 
that there is a storage company with the trademark United in South Africa.  The 
South African United would want to look at Whois to check the registrant 
contact information of storage.united.  Various Whois requirements are in the 
registrar agreement and should be enforced for all domain names.  If the United 
SR didn't sign on to the registrar requirements, then they would not sign on to 
the registrar Whois requirements.  Jeff has stated in the past that these names 
might not need to be in Whois.  I don't agree, and I doubt that many in ICANN 
community would be comfortable with a segment of domain names not having Whois 
information available.  To continue with the example, let's say that United 
Storage in South Africa wants to file a UDRP against United Airlines to get the 
name taken down permanently.  Such a UDRP complaint requires that registrars 
take certain actions.  If no entity signs on to registrar obligations, there 
are UDRP requirements that cannot be effectuated.  Would there be consumer harm 
with no effective UDRP?  I'm sure that Milton could lead an interesting 
academic argument on that issue, but there certainly would be harm to trademark 
holders.  Obviously, this is only two examples.

My point has been that to re-open Recommendation 19 and to permit any names to 
be registered without the use of a registrar would mean that we would have to 
open up every Consensus Policy to determine the market and consumer impacts of 
not having a registrar of record for every name.  To what end, would we want to 
go through that process -- so an SR could operate as a combined entity and not 
have to sign an RAA form also?  Again, what is the big deal?  If we permit VI 
for SRs, then have them sign an RAA as an addendum to their registry 
agreements.  Easy solution.  If the fees that a combined entity would pay to 
ICANN is the issue, that certainly should be open for discussion and debate.  

As for Jeff's history lesson, he doesn't say with whom he spoke with on 
Council, but this exact SR issue was raised by Adrian Kinderis and discussed by 
others during the debate on Recommendation 19 in Los Angeles in October 2007.  
After a protracted debate, the GNSO Council decided that every domain name 
should be registered under the terms of the RAA and existing Consensus 
Policies.  I agree with Tim that revisiting this issue is not in scope in this 
WG and would continue to complicate our work and cause needless delays.  The 
arguments against Recommendation 19 are not new and should not be raised here 
again to derail our work.  

We need to discuss what VI/CO rules should be in place and whether we want an 
SR exception to such VI/CO rules if applicable NOT whether a combined SR would 
need to be bound by the requirements of both the registry agreement and the 
registrar agreement -- that issue was settled by Council.

Thanks.

Jon


On Apr 9, 2010, at 8:21 AM, Neuman, Jeff wrote:

> This last week has been an interesting one on this list, but one in which I 
> believe we have taken hypocritical inconsistent approaches.
>  
> What is interesting to me is that many on the list are advocating that we do 
> not need to look at the competitive landscape among registry providers, but 
> rather we need to look at the benefits/harms to consumers when talking about 
> vertical integration/cross ownership at the registry level.  But when looking 
> at the registrar level, some of these same parties are arguing that we should 
> not look to the consumer benefits and harms, but rather only look at the 
> competitive landscape of registrar providers.
>  
> We need to choose to do one or the other and remain consistent in what we do. 
>  If we choose to look at the consumer harms/benefits of having vertical 
> integration / cross ownership at the registry level, then we need to look at 
> the consumer harms/benefits of having registrars in the first place 
> (especially with respect to single registrant and community based TLDs.   If 
> we choose to only look at the competitive landscape at the registrar level 
> (and not the consumer benefits/harms), then we should only look at the 
> competitive landscape at the registry level. 
>  
> Some registrars are conveniently citing GNSO Recommendation 19 as a reason 
> that we should not open up the discussion about having to use accredited 
> registrars.  They argue that that issue has been decided and we should not 
> look back.  I have actually talked to a number of GNSO councilors that were 
> on the council at the time Recommendation 19 was approved and many of them 
> assumed that the vertical separation requirements would remain at least what 
> they were today.  In other words, changing the VI/CO part of the equation 
> changes the assumptions that went into approving recommendation 19 in the 
> first place.  So if we change the VI/CO part of the equation at the registry 
> level, it is inconsistent (or possibly even hypocritical) to not open up the 
> other part of the equation at the registrar level. 
> 
> I am fine with either approach.  What I am not fine with is how a number of 
> registrars on this list want to have it both ways.  They argue that we must 
> look at the consumer benefits/harms of VI or CO at the registry level, but 
> want to dismiss looking at it at the registrar level.  They often cite “fear 
> of gaming” at the registrar level as the reason we should not delve into 
> issues of Single Registrant TLDs not having to use registrars.  Incidentally, 
> the Registries Stakeholder Group also argued the fear of gaming as a reason 
> to tighten the separation requirements between registries and registrars, but 
> that seems to have been lost in the noise because the same entities that 
> would have us look at the competitive landscape amongst registrars, do not 
> want to look at the competitive landscape amongst registries.
>  
> I know some registrars will attack this note, but I must request that the 
> chairs of this group apply consistency in how we work.  Either we consider 
> consumer harms/benefits at both the registry and registrar levels, or we do 
> not consider it at all at either level.  Like I said, I am fine with either 
> approach, so long as we are consistent.  The proposal Neustar submitted was 
> contingent on looking at both sides of the equation.
>  
> Jeffrey J. Neuman 
> Neustar, Inc. / Vice President, Law & Policy
> 46000 Center Oak Plaza Sterling, VA 20166
> Office: +1.571.434.5772  Mobile: +1.202.549.5079  Fax: +1.703.738.7965 / 
> jeff.neuman@xxxxxxxxxxx  / www.neustar.biz     
> 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.
>  



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

Privacy Policy | Terms of Service | Cookies Policy