<<<
Chronological Index
>>> <<<
Thread Index
>>>
Re: [gnso-vi-feb10] Tacit assumptions on SR?
- To: Richard Tindal <richardtindal@xxxxxx>
- Subject: Re: [gnso-vi-feb10] Tacit assumptions on SR?
- From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
- Date: Sun, 18 Apr 2010 17:21:30 -0400
> ... I see two main types of SR. The first I
> call Single Registrant Single User (SRSU). ... The other type I call Single
> Registrant Multiple User (SRMU).
You propose the organizational principle being the distinct agency, a
"user" in the second case. Aside from ICANN deciding not to use the
sponsor model in this round, how does the SRMU differ from sponsorship
and conditional registration?
> Para 2.6 of the DAG's registry contract allows ...
Well, maybe. It is a gamble to assume that nothing will upset this
particular apple cart, and there are a lot of "innovation adverse" ,
if not any new gTLD adverse actors out there, a lot of them
intellectual property protection and/or customer confidence motivated.
> ... I'm not talking about HOW the registry would register the names.
And we're in complete agreement there, other differences overlooked or
settled by others.
> *Vertical Integration*: This means the registry entity is also
> accredited as a registrar for the TLD. The registry entity could
> either sign two contracts with ICANN (one for registry and one for
> registrar) or we could spend a few months work and try to merge the
> contracts into one (specifically for SRs).
Urk. However, not a few of the advocates of the working group
recommending a much less restrictive policy are opposed to
distinguishing between application types. So for what its worth, and I
could be wrong, and those advocates could change their minds, it seems
prudent to cost in that time, and a few months may be under budgeting.
>...
> Now to the question at hand - what cross ownership and VI rules should
> we allow for SRs?
>
> *SRSU*. If you're an SRSU I don't think it matters. You'd set a
> policy that says all names are to be registered to the registry.
> Regardless of cross ownership rules you'd find an unaffiliated registrar
> to register the names (for a low mark-up per name) -- and you're in
> business.
Nuance. As the registry is the registrant, solutions allowing equal
access, or revenue sharing, with functional registrars (not the 600 or
so back-order shell registrars) are possible, and therefore preferable.
> ...
> *SRMU. As these names are provided to other parties (employees,
> members, customers, etc) they compete with other TLDs. Given this, I
> think SRMU registries should operate under the same rules we decide for
> other TLDs - whatever those end up being. To do otherwise would create
> an uneven playing field. If SRMUs out-compete other types of TLDs, so
> be it. It means they've better satisfied consumer needs - which is
> what the new TLD process is about. *
Agree, as you know.
> In summary:
>
> A. SRSU TLDs probably don't need their own registrar - unless they
> plan to register a very large number of names; and
>
> B. I dont think we need a separate rule set for SRMU TLDs.
>
> Comments welcome.
Off-list I've mentioned scale to you, as a very small "single
registrant" and a very large "single registrant", may share the
property that no third-party agency exists, all content, all
resolution, all redirection, all "visitor" personally identifying
information, ... are all, for want of a better phrase, those of the
registry.
I don't think contract-alone is sufficient, though I can see the
lawyers thinking it is.
So, modulo the exists-or-not problem, I see your approach to the
registrar problem less problematic than solutions that assert some
necessity or utility claim for exception. I think the taxonomy of
things that don't fit either the "standard" or "community-based" types
well as something that needs further thought.
Where I suspect you'll have a problem is with those who already have a
fully-formed SR model which admits no distinction between any SR
sub-type, or even with non-SR types, and lack motivation to collaborate.
Eric
<<<
Chronological Index
>>> <<<
Thread Index
>>>
|