ICANN ICANN Email List Archives

[gnso-vi-feb10]


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

Privacy Policy | Terms of Service | Cookies Policy