ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

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

  • To: "'vgreimann@xxxxxxxxxxxxxxx'" <vgreimann@xxxxxxxxxxxxxxx>, "'Gnso-vi-feb10@xxxxxxxxx'" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: Re: [gnso-vi-feb10] Single Registrant TLDs
  • From: "Neuman, Jeff" <Jeff.Neuman@xxxxxxxxxx>
  • Date: Fri, 9 Apr 2010 06:41:38 -0400

So what you are saying is that in order to maintain the cherade of having 
registrars in a SR TLD (even without any consumer benefit), registries should 
be forced to build in extra protections and make their systems much more 
complicated than today. And I am not even talking about a real registry like we 
have today.  In other words, simply to perform data entry into a registry that 
does not even need an SRS function, you will require .post or a SR TLD to build 
an expensive SRS and these extra locks simply to have registrars, but for no 
consumer benefit?

That does not make sense to me.
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: Fri Apr 09 06:19:26 2010
Subject: Re: [gnso-vi-feb10] Single Registrant TLDs


I do not agree on the dangers you propose in the .post example. A 
deletion could be prevented by the registry technically or by policy, 
for example by not allowing registrars to delete immediately, and 
imposing a pre-deletion phase instead, where the domain remains active 
but the registrant must choose a new registrar. Preventing changes can 
be prevented by registry locks which must be lifted by the registrant 
directly before changes can take place.

I do agree that of course the IOC or any other registry _can_ do all 
necessary functions in house. It will probably be easier and more 
comfortable for them. Their registration policies will likely hold many 
of these functions in house. However, how do you differentiate such 
possibly legitimate registries from others that will claim the same 
perogative for themselves, but will only use this as a loophole. Why 
should .web, .shop, .youcanprobablythinkofmanymoreexamples not also be 
allowed to set up a similar membership scheme that will allow them to 
bypass registrars entirely, if other gTLD registries are allowed to use 
such a model? Why should established registries in this scenario still 
be forced to continue using registrars, if nGTLD registries are freed 
from this requirement?

I am not proposing not to have VI registries, however I do think that if 
we decide to propose such a system to the board, we should be clear 
about the consequences such integration may have, and find ways to 
prevent a circumvention of the current system, which in the past decade 
has proven to be an effective and good system. I do believe we will end 
up with some form of VI, but only as an exception, not the rule. Given 
the limited time available, I do suggest to first define the rule, and 
leave the exceptions for later.

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


-- 
Bei weiteren Fragen stehen wir Ihnen gerne zur Verfügung.

Mit freundlichen Grüßen,

Volker A. Greimann
- Rechtsabteilung -

Key-Systems GmbH
Prager Ring 4-12
66482 Zweibrücken
Tel.: +49 (0) 6332 - 79 18 85
Fax.: +49 (0) 6332 - 79 18 61
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Folgen Sie uns bei Twitter oder werden Sie unser Fan bei Facebook:
www.key-systems.net/facebook
www.twitter.com/key_systems

Geschäftsführer: Alexander Siffrin
Handelsregister Nr.: HR B 1861 - Zweibruecken
Umsatzsteuer ID.: DE211006534

Der Inhalt dieser Nachricht ist vertraulich und nur für den angegebenen 
Empfänger bestimmt. Jede Form der Kenntnisgabe, Veröffentlichung oder 
Weitergabe an Dritte durch den Empfänger ist unzulässig. Sollte diese Nachricht 
nicht für Sie bestimmt sein, so bitten wir Sie, sich mit uns per E-Mail oder 
telefonisch in Verbindung zu setzen.

--------------------------------------------

Should you have any further questions, please do not hesitate to contact us.

Best regards,

Volker A. Greimann
- legal department -

Key-Systems GmbH
Prager Ring 4-12
DE-66482 Zweibruecken
Tel.: +49 (0) 6332 - 79 18 85
Fax.: +49 (0) 6332 - 79 18 61
Email: vgreimann@xxxxxxxxxxxxxxx

Web: www.key-systems.net / www.RRPproxy.net
www.domaindiscount24.com / www.BrandShelter.com

Follow us on Twitter or join our fan community on Facebook and stay updated:
www.key-systems.net/facebook
www.twitter.com/key_systems

CEO: Alexander Siffrin
Registration No.: HR B 1861 - Zweibruecken
V.A.T. ID.: DE211006534

This e-mail and its attachments is intended only for the person to whom it is 
addressed. Furthermore it is not permitted to publish any content of this 
email. You must not use, disclose, copy, print or rely on this e-mail. If an 
addressing or transmission error has misdirected this e-mail, kindly notify the 
author by replying to this e-mail or contacting us by telephone.









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

Privacy Policy | Terms of Service | Cookies Policy