<<<
Chronological Index
>>> <<<
Thread Index
>>>
RE: [gnso-vi-feb10] First stab at objectives and a definition of VI
- To: Stéphane Van Gelder <stephane.vangelder@xxxxxxxxx>
- Subject: RE: [gnso-vi-feb10] First stab at objectives and a definition of VI
- From: Milton L Mueller <mueller@xxxxxxx>
- Date: Sat, 6 Feb 2010 07:00:13 -0500
________________________________________
From: Stéphane Van Gelder [stephane.vangelder@xxxxxxxxx]
>Equal access is a prerequisite in the new gTLD program.
Yes. That's a short-term issue.
>Are you suggesting we revisit this?
I am not suggesting that we "revisit" it, I believe it has never been visited.
That is the main reason we need a PDP, in my opinion.
As the CRAI report and other discussions have made clear, looking forward there
may be a reason to consider when and where real vertical integration should be
permitted.
It would be nice if the policy making process was ahead of events, rather than
lagging behind them, for a change.
>If so, I think that's way out of scope of this group.
Why? The motion creating this PDP used the term vertical integration. And
vertical integration, as you note below, is a live issue with respect to .brand
TLDs.
>So if equal access is a given (i.e. a registry must treat all registrars
>indiscriminately), why should an analysis of VI cover anything beyond
>the possibility that one of the registrars is actually the registry (which
>doesn't preclude said registry from providing equal access to the other
>registrars)?
Because in the future, we may not want to assume that equal access is a given.
One might want to change that. Or one might decide not to. But since vertical
separation and equal access were designed to deal with the dominance of .com,
there are a number of obvious situations (e.g., a .brand TLD, or a small
community-based TLD) where that model just doesn't apply.
> The only case that I can think of right now where equal access may
> not be a given, i.e. where a registry is its own registrar and doesn't
> service other registrars in the same way, is corporate or single-owner
> TLDs which are operated on such a narrow focus (registrants can only
> be employees of the corporation for example) that it cannot hope to
> attract many registrars to its TLD and therefore would be prevented
> from being able to operate a viable TLD by an equal access rule.
Exactly. the same situation I was contemplating.
>Apologies if I am still missing your point.
No, you seem to be getting my point quite clearly, or at least our
understanding of the implications of the definitions is making real progress.
There are short-term issues related to cross ownership and long term, more
fundamental issues related to VI.
For me, the cross ownership issue is a short term issue that pertains to the
DAG drafted by the staff. As I understand it, the DAG v3 would allow cross
ownership and allow a cross-owned registry to use its own registrar to
distribute its own TLD. There was a debate leading into Seoul as to whether
that constitutes a policy change or whether it is "implementation." If we
resolve that issue, we need to do so very quickly so as to not delay the new
gTLD round. But it is a relatively narrow issue, and does not fundamentally
alter the basic regulatory framework for registries and registrars.
If we move on to consider vertical integration, on the other hand, we would be
considering a fundamental departure from established policy, or at least under
what conditions such fundamental departures should be allowed. This would have
longer term implications for the domain name industry.
I think now you can appreciate better why I want to clearly separate the
definitions of VI and CO.
They are two distinct tasks. If we resolve the short-term, CO issue we are not
resolving the longer term questions about VI.
I would like to see this PDP do both. Indeed, in terms of clarity it would be a
big step forward for this group's charter to separate those topics and have
clear and distinct definitions of CO and VI so that people would stop using the
terms interchangeably and consider each problem distinctly.
--MM
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|