Re: [gnso-vi-feb10] Single Registrant TLDs

[Richard Tindal <richardtindal@xxxxxx>]

i agree it would be good to get all the perceived harms and benefits on the 
table

JEFF E --   Consistent with the definitions we've been using, you're advocating 
unlimited Cross Ownership.      

In a nutshell you're proposing that the shareholders of a registry can also be 
the shareholders of a registrar in that TLD.  You're also saying the registry 
will provide equivalent access to other qualified registrars.   Is that right?

Richard

 

On Apr 9, 2010, at 7:56 AM, Jeff Eckhaus wrote:

> Jeff- As you can imagine, I disagree that it is a waste of time.
>  
> In the past both sides presented their opinions and were hoping for someone 
> to choose them, it was a beauty contest.  Now we are in a collaborative group 
> that is looking to make an informed decision based on the facts.  I do not 
> think it is a waste of time to put all the facts on the table to help in the 
> decision.
>  
> I also want to separate what the perceived harms would be from the issue of 
> lack of trust of a combined entity. I think these can be dealt with in 
> different ways and not be forced to be put in a VI/CO good or bad basket. I 
> mean CADNA came out with a fear of $1 billion cost to TM holders for due to 
> new TLDs.  That is their fear and concern, does not mean there is an ounce of 
> truth to it.
>  
> I also think having all the information in front of us would be fantastic. I 
> would love to read the papers submitted by small and medium registrars on the 
> harms of Vertical Integration.
>  
> As for the desire to have a neutral independent party and consumer experts 
> judge and understand, I do not think the call for experts has helped in the 
> past or will in the future. I think we are here and we need to decide this.
>  
>  
> I would like to clarify one minefield I stepped in and that is the definition 
> of Vertical Integration I used, which I will attempt to clear up without 
> blowing myself up to bits.
> I am not going to attempt to define VI right now just explain how I used VI 
> in my original statement below which many of you may think is not VI but CO 
> which I am fine with.
> The ability of a Registry to own a Registrar (or vice –versa) with no 
> ownership limits and the ability of that combined entity to distribute any 
> TLD including the ones that the combined entity owns.
>  
> If this is a CO that I apologize and will do a find and replace for the term 
> VI with CO and will be using that term going forward.  Also if that is 
> Co-ownership, could we then discuss what are the issues with CO?
>  
> Jeff E
>  
>  
>  
>  
>  
>  
> From: Neuman, Jeff [mailto:Jeff.Neuman@xxxxxxxxxx] 
> Sent: Thursday, April 08, 2010 2:29 PM
> To: Jeff Eckhaus; 'vgreimann@xxxxxxxxxxxxxxx'; 'Gnso-vi-feb10@xxxxxxxxx'
> Subject: RE: [gnso-vi-feb10] Single Registrant TLDs
>  
> Jeff,
>  
> While I appreciate what you are trying to do, I am not sure an analysis from 
> a registrar (or registry for that matter) on the pros and cons of vertical 
> integration (or separation) is not going to help us achieve our short terms 
> goals.  We have done that MANY times before.  We have had economists talk 
> about it at ICANN meetings and consultations, we had a live debate between 
> those in support and those against in Seoul.  Some Registries (and in fact 
> some small and medium registrars) have submitted numerous papers on the harms 
> of integration, while new TLD applicants/some registrars have submitted 
> numerous papers in support.  We have had IP attorneys and businesses talk 
> about their fears of VI and their lack of trust of a combined entity.  We 
> have had new TLD Applicants talk about how it would benefit them for 
> competition…….  
> 
> Your exercise, while certainly worthwhile in the long term is in fact what 
> this group is supposed to do IN THE LONG term.  But your exercise should not 
> be done by an entity that wants to see integration (or one that does not), 
> but by a neutral independent party that is able to truly understand the 
> market and economic conditions as well as consumer experts that can 
> understand the true effects. 
>  
> So, rather than have a debate on Monday (which I can not be there for 
> anyway), lets put off your exercise and concentrate on some short term 
> solutions in the context of what we can accomplish by DAG 4 (or shortly 
> thereafter).
>  
> Just a friendly suggestion.
>  
> 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: Jeff Eckhaus [mailto:eckhaus@xxxxxxxxxxxxxxx] 
> Sent: Thursday, April 08, 2010 5:17 PM
> To: Neuman, Jeff; 'vgreimann@xxxxxxxxxxxxxxx'; 'Gnso-vi-feb10@xxxxxxxxx'
> Subject: RE: [gnso-vi-feb10] Single Registrant TLDs
>  
> I have been following this thread on Single Registrant TLDs would like to 
> make an observation and maybe try to move this discussion forward.
>  
> I understand all the arguments on SR and actually think there is not much 
> disagreement here as it pertains to Vertical Integration, the argument has 
> been more towards once the Vertically Integrated entity exists solving 
> registrars, becoming accredited and fees paid. Maybe some other minor points 
> as well.
>  
> I have been reading and re-reading the emails and think people are just 
> talking past each other on this and we are not far apart.  I think if there 
> is a small group focused on these details it can be sorted fairly quickly.
>  
> What I have not seen in this SR discussion is the reason why there should not 
> be a Vertically Integrated entity. As I mentioned earlier I will be 
> presenting something soon on all the benefits, and hopefully have some time 
> next week to present on the call (HINT to the Co-Chairs) . What I would like 
> to see is the reasoning why we should not have full Vertical Integration and 
> those who are opposed to full VI to explain why.
>  
> I believe if this group sees both sides of the issue, we can begin the 
> analysis of the pros and cons and work towards an informed decision on the 
> topic, maybe even by DAGv4
>  
>  
> Thanks
>  
>  
> Jeff E.
>  
>  
>  
>  
> -----Original Message-----
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-feb10@xxxxxxxxx] On 
> Behalf Of Neuman, Jeff
> Sent: Thursday, April 08, 2010 1:00 PM
> To: 'vgreimann@xxxxxxxxxxxxxxx'; 'Gnso-vi-feb10@xxxxxxxxx'
> Subject: Re: [gnso-vi-feb10] Single Registrant TLDs
>  
>  
> The disadvantage is having to rely on a third party (a registrar) which can 
> undermine the security and stability of the space.  What I am saying is that 
> the onlympic committee can do the dns function in house if it chose to.  Why 
> should they be forced to even consider a third party to do "registrations".  
> The mere fact of using a third party that essentially could have the right to 
> make changes to its registration system may not be one that the entity even 
> wants to take on.  That is the reason some organizations run their own dns in 
> the first place (because they may not want to outsource the functionality).
>  
> Think of the .post example.  Does the UPU want to force all national pst 
> offices to have to use a third party registrar for the simple act of data 
> entry when that third party registrar could have the power to delete a 
> registration, change the name servers, etc. Thereby bringing down the entire 
> postal system in that nation.  Maybe they do trust a third party to that or 
> maybe they donw.  My point is that they should actually have a choice.
> Jeffrey J. Neuman, Esq.
> Vice President, Law & Policy
> NeuStar, Inc.
> Jeff.Neuman@xxxxxxxxxxx
>  
>  
>  
> ----- Original Message -----
> From: owner-gnso-vi-feb10@xxxxxxxxx <owner-gnso-vi-feb10@xxxxxxxxx>
> To: 'Gnso-vi-feb10@xxxxxxxxx' <Gnso-vi-feb10@xxxxxxxxx>
> Sent: Thu Apr 08 06:00:07 2010
> Subject: Re: [gnso-vi-feb10] Single Registrant TLDs
>  
>  
> Jeff, I see your point but let me ask one question here:
>  
> What is the operative disadvantage of maintaining the
> registry-registrar-system even in such cases? The same goals could
> easily be accomplished by using the registry-registrar-registrant model
> the following way:
>  
> The IOC applies for .olympic, and limits the ability to register certain
> domain names domain names to NOCs, organizing cities and the official
> sponsors only, while at the same time reserving other  domains for their
> own use in their policy, just as any registry does today. The list of
> reserved domain names would of course be longer. The delegated domains
> are registered by applicable registrants through their registrar of
> choice while the reserved domain names must be used by the IOC directly.
>  
> The only change would be that the NOCs would be the actual registrants
> of the delagated domains, not the IOC. The IOC would retain the right to
> vet any application; domains would only be activated after such approval
> is granted by the registry. A similar model has just been imposed in
> .CN. I think .museum operates a similar system as well. While it makes
> registrations more complicated and increases registry control, this
> effect would be desirable to the registry owner of a .brand or .ngo.
>  
> There is no actual need to eliminate the registrar in such a model as
> the same goals can be reached with the current system.
>  
> Now the second question that arises in this scenario is of course if the
> registry should be allowed to operated a registrar of its own. I would
> think that many registrars would be hesitant to even consider
> implementing .olympic into their system even if given equal opportunity
> to do so due to the low number of total registrations to be expected
> compared to the cost of implementation and maintaining registry
> relations. This ties in directly with one of the earlier suggestions in
> the discussions of VI and CO, where VI and CO would be permitted, under
> the condition that the VI/CO-registrar be limited in the number of
> domains it may register in total.
>  
> Best regards,
>  
> Volker A. Greimann
>  
> Key-Systems GmbH
>  
>  
> > An organization (commercial or noncommercial or nongovernmental) could 
> > establish a SR TLD whereby it owns all of the names and allows others to 
> > use those names, but there is no concept of having others" register" names. 
> >  For example, what if the International olympic committee wanted .olympic 
> > and they only had 200 registrations (1 for each country's olympic 
> > committee...i.e., USOC.olympic (for the US Olympic Committee). In that 
> > case, you could have one person at the International Olympic Committee 
> > enter all of the relevant information into a database (notice I didn't use 
> > the word registry database).  There is no SRS or WHOIS functionality per se 
> > normally thought of as a registry, and no real registrar functionality of 
> > going through a EPP registration process.  There is no value add of having 
> > to go through an entity we today call a registrar.
> > 
> > This is a made up example, but I think is very real and in some ways 
> > similar to what I have heard .post is today.  I don't have any inside 
> > information for .post, but as I understand the application from years ago, 
> > .post may want to give the second level registrations to the national post 
> > offices to use as they see fit.  The charade of having to select registrars 
> > because of legacy requirements just makes no sense.  There is no real 
> > concept of a registrar in that sense nor any value add of requiring the 
> > ultimate recipient of the .post ( the national post offices) to have to 
> > select a registrar.  There is no need for the complexity of setting up a 
> > shared registration system at the registry level either. 
> > 
> > I see traditional brand tlds the same way and very real. Although no Brand 
> > TLDs may have filed public comments, let me tell you we have talked to some 
> > and this is a very real example (though I made up the olympic example).
> > 
> > 
> > Jeffrey J. Neuman, Esq.
> > Vice President, Law & Policy
> > NeuStar, Inc.
> > Jeff.Neuman@xxxxxxxxxxx
> > 
> > 
> > 
> > ----- Original Message -----
> > From: owner-gnso-vi-feb10@xxxxxxxxx <owner-gnso-vi-feb10@xxxxxxxxx>
> > To: Gnso-vi-feb10@xxxxxxxxx <Gnso-vi-feb10@xxxxxxxxx>
> > Sent: Wed Apr 07 22:50:56 2010
> > Subject: [gnso-vi-feb10] Single Registrant TLDs
> > 
> > 
> > All,
> > 
> > We may be getting a little wrapped around the axle on this topic (this is 
> > no-one's fault as it's complex) so I'd like to take a shot at summarizing 
> > where it stands.  
> > 
> > We're not debating whether or not Single Registrant (SR) TLDs should be 
> > allowed.   They are allowed  -- and have been allowed from the first 
> > version of the DAG.      Any registry can register names just to itself and 
> > no registry is required to provide open access to registrars.
> > 
> > Also, no rule we devise will prevent SR TLDs.   We're making rules about 
> > who can own registries and registrars, not about who can own domains.  An 
> > SR TLD can exist if we recommend zero cross ownership and it can exist if 
> > we recommend 100% cross ownership.
> > 
> > What we're debating is whether or not,  in order to register its names,   
> > an SR TLD registry must be accredited as a registrar  (and, importantly,  
> > pay the fees that accompany that registrar accreditation).  This is the 
> > area of contention.  
> > 
> > If anyone feels I've mischaracterized the issue please jump in.
> > 
> > 
> > Also, I agree with the argument Volker made yesterday.    I think we should 
> > first see if we can find a rule-set that suits all types of registries.  
> > This may be possible.   If we find the overall rule-set doesn't suit a 
> > particular registry-type then we can drill down on exception cases.
> > 
> > RT
> > 
> > 
> > 
> >  
>  
>  
>