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: Jon Nevett <jon@xxxxxxxxxx>
  • Subject: RE: [gnso-vi-feb10] The need to evaluate options in a consistent manner
  • From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Date: Fri, 9 Apr 2010 10:40:08 -0400

Jon,

 I think you have missed my points, so it was probably my fault.

1.  My point with respect to certain SRs are that there are no real "registrar" 
functions or for that matter real 'registry" functions.  In other words, no 
need for EPP transactions, no need for a traditional registrar/end user 
relationship, and no need for a WHOIS database as we know it today.

2.  I NEVER said that contact information for the domain names should not be 
provided.  Far from it.  What I said is that there is no need for the 
traditional WHOIS database since the contact information for every name may be 
the same person.  Thus, it should be acceptable for the owner of the space to 
put up on its webpage that "Person X, Y, Z is the contact person for every 
name" and "here is who you contact".  There is no need for Port 43 WHOIS 
access, nor any need to follow WHOIS protocols.

3.  UDRP - this is an issue that needs to be explored, because I do believe 
that a UDRP may be inapplicable to certain Single Registrant TLD, in that there 
may be no mechanism to transfer a domain name.  That does not mean that IPR 
complaints cannot be lodged, but I think your United example is pretty weak in 
this situation as your example may or may not qualify for a single registrant 
TLD.

4. I completely disagree with you that creating exceptions to Recommendation 19 
is out of scope, but certainly understand why you and Tim want it to be.

Jeffrey J. Neuman
Neustar, Inc. / Vice President, Law & Policy

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


From: Jon Nevett [mailto:jon@xxxxxxxxxx]
Sent: Friday, April 09, 2010 10:04 AM
To: Neuman, Jeff
Cc: 'Gnso-vi-feb10@xxxxxxxxx'
Subject: Re: [gnso-vi-feb10] The need to evaluate options in a consistent manner

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<http://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<mailto:jeff.neuman@xxxxxxxxxxx>  / 
www.neustar.biz<http://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