ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

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

  • To: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] Single Registrant TLDs
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Thu, 08 Apr 2010 17:55:53 -0400

Volker, Jeff,

This is one of those "examples obscure more than they reveal" instances.

CORE spent the better part of a year and some real money working with,
and working without, the IOC, on a TLD proto-project. Given how far
the actual issues are from the representations here, I suggest we
abandon this "example", as it really isn't correct or illuminating.

As for .post, it is simple enough to ask rather than hypothesize.

Eric

On 4/8/10 3:59 PM, Neuman, Jeff wrote:
> 
> 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
>>
>>
>>
>>   
> 
> 
> 
> 
> 




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

Privacy Policy | Terms of Service | Cookies Policy