Re: [gnso-vi-feb10] a starter-list of Harms

[Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>]

Alan,

As you know, CORE-Registrar does not sell .museum or .cat, as both
MuseDoma and PuntCat use CORE-Registry-Services-Provider.

We view this -- functional separation -- as a win.

First, as the RSP, our duty to each of .museum and .cat to ensure that
each has registrars, and albeit concerns over the registrars of
.museum correctly executing that registry's eligibility policy, our
interest is that those registrars have no reason to be concerned by
the registrar function, in other TLDs, of the RSP. Happy RRs means
happy ROs, who choose to renew their RSP contract with CORE-RSP.

Perhaps the issue is the "large registrar", which CORE is not, and can
be adequately captured by a market cap criteria.

So this is an "abuse", if we allow uncapped RRs (or uncapped RSPs) to
compel RO choice of RSP based upon access to RR choices.

It is a "feature", if we do not allow RSPs who are also RRs to sell
the inventories for which they provide RSP services, a la CORE and the
.museum and .cat gTLDs.

Note that "big" may not be the only issue. Suppose there is a Hebrew
Script registry, say for Yiddish, and for political reasons beyond our
control, all registrars offering Hebrew Script refuse to sell Yiddish
names, except one, located in some jurisdiction which does not
officially deprecate the use of Yiddish. If that RR has an RSP
capability, does the RO for a Yiddish label and a Yiddish language and
culture community charter have freedom to select an RSP?

I think all of the elements of this example are in place, other than
the desire by the RO applicant to choose an RSP other than the RSP the
applicant has selected, but there may be similar fact patterns and the
RO may actually find itself with only one real choice.

The problem may also arise where a ccTLD RSP/RO with a ccRR set offers
predatory terms to a gTLD RO community-based applicant where the
community is primarily "domestic" to the ccTLD RSP/RO market.

I think all of the elements of this example are in place, in several
instances, where the ccTLD RSP/RO seeks to compel the choice of RSP
for some applicants for a gTLD RO status.

The universe of harms is larger than merely the two ICANN
counter-parties and the gTLD RSPs not also covered by one or more RO
contracts.

Eric

On 6/17/10 2:43 PM, Alan Greenberg wrote:
> 
> Mikey, one of the potential VI harms that was discussed earlier but does
> not seem to be in your list is a large registrar who is also an RSP
> applying pressure to prospective Registries to use their back-end
> services or the registrar will not carry the TLD (or will not feature it).
> 
> I don't know to what extent this is an issue, but it was discussed in
> earlier meetings looking at the competition studies.
> 
> Alan
> 
> At 31/05/2010 12:31 PM, Mike O'Connor wrote:
>> hi all,
>>
>> i liked the "Harms" conversation that Roberto kicked off and went
>> looking for a list, since several people mentioned that there were
>> lists out there.  i couldn't really find one, so i decided to start
>> building one for us.  i've attached my very-first, extra-lame draft
>> version of the list and have also included it in the agenda for the
>> call today.  please give this a quick read and identify any that i've
>> missed.
>>
>> Roberto and i are thinking that we'll work through a basic risk
>> assessment process -- 1) describe the possible harms, 2) determine
>> their likelihood and importance and 3) describe ways to reduce their
>> likelihood and impact.  so this is part one -- make sure we have a
>> complete list...
>>
>> mikey
>>
>>
>>
> 
> 
> 
>