Re: [council] Proposed Motion requesting Issues Report on Vertical Integration & Registry/Registrar Cross-Ownership
Title: Re: [council] Proposed Motion requesting Issues Report on Vertical Integration & Registry/Registrar Cross-Ownership
I don’t know if you’ve had a chance to listen to the Council meeting mp3 or not. If you have, you will know that during our discussion on your proposed motion, I asked for it to be deferred and indicated that I had some questions about it.
As Mike suggested, in order to get the discussion moving on this, I would like to start by making a couple of points on behalf of the RrC.
First, in the context of our discussions on prioritisation of work, I don’t think that a PDP on this now is good timing. The Council has a lot of other important work already going on. Plus the issue of separation has seen and is still seeing a lot of work done on it as part of the new gTLD program. I think Council resources would be best spent elsewhere at this stage.
That having been said, is this a policy issue anyway?
In your accompanying text, you indicate that you support one of the two CRA recommendations but not the other. That one is policy change while the other isn’t. As both recommendations are logical extensions of one another, it seems hard to split them the way you have and decide that one is policy and one isn’t.
So let’s address that second recommendation you say is a policy change. Who owns a registrar, or a registry, is not policy. It’s not even an ICANN contractual issue. VERISIGN could be a shareholder of INDOM (need I say this is entirely hypothetical? :) ) and there’s no reason why ICANN would have any problem with it. The issue is one of separation. If VERISIGN did own a significant part of INDOM, then it would simply need to use another registrar to register .COM or .NET domains. Allow me to point out that this scenario is not fantasy. Before VERISIGN sold its corporate domain arm DBMS to MELBOURNE IT, it did use other registrars in which it had no shareholding interests to register .COM and .NET domains.
Further, there are several aspects of the new gTLD program that are evolving through implementation. The separation issue is one, but there are others. The IRT suggests that all registries use thick whois only. Should the GNSO engage a PDP on that? The GAC wants geographic names reserved. Should we do a PDP on that? And so on...
In short, we do not feel that a PDP is required or warranted on this, at this time.
Thanks for reading and happy to answer any questions.
Le 28/08/09 01:07, « Mary Wong » <MWong@xxxxxxxxxxxxx> a écrit :
On behalf of the NCUC, I am proposing the following motion:
"Whereas, Recommendation 19 of the GNSO policy authorizing the new gTLD process states: "Registries must use only ICANN accredited registrars in registering domain names and may not discriminate among such accredited registrars;"
Whereas, opening up the market to many new TLD operators calls into question some of the assumptions on which the separation of registry and registrar functions is based;
Whereas, economic research commissioned by ICANN staff also suggests that changes might be justified;
Whereas, the new gTLD policies passed by the Council do not provide any policy guidance regarding the proper approach to cross ownership and vertical integration, but instead suggest that the status quo be left in place;
Resolved: the GNSO Council should initiate a policy development process on registry-registrar cross-ownership and the policies that should be applied to vertical integration or separation of gTLD registrars and registries and requests that an Issues Report be done on this question. This policy process should not delay or affect the progress of the new gTLD application process but should run in parallel."
Thank you. Background information relating to the NCUC position on this issue will follow shortly.
Mary W S Wong
Professor of Law
Franklin Pierce Law Center
Two White Street
Concord, NH 03301
Selected writings available on the Social Science Research Network (SSRN) at: http://ssrn.com/author=437584
Description: S/MIME cryptographic signature