RE: [gnso-vi-feb10] The case for exception

[Milton L Mueller <mueller@xxxxxxx>]

Eric
It's not clear what proposal you are addressing. The cross-ownership 
liberalization in the MMA proposal retains the registry-registrar separation 
but simply allows a cross-owned registry-registrar entity to be one of the 
registrars. There is actually no departure from Rec. 19 there. 

If you are talking about SR TLDs, the reason for not having registrars has been 
made clear time and again. But the MMA proposal, and others, seem to see this 
as a longer term change. 

For the sake of keeping things in perspective, let's not lose sight of the 
factual situation, which serves as a powerful antidote to some of the more 
lurid fantasies that are being entertained on this list about the potential 
harms of any change. 

At present, 100% of the gTLD market operates under the standard Rec. 19 
paradigm. We all know that it is extremely difficult for new gTLDs to establish 
a presence and share in the market. The 10 or so new gTLDs who have been 
afforded privileged entry into a highly restricted market have obtained, what, 
less than 5% after a decade? So let's not talk as if TLDs that have had a 
decade(s)-long head start in a market with ENORMOUS switching costs are going 
to be at some terrible disadvantage or suffer irreparable harm if a bunch of 
new TLDs are let into the market under slightly different terms. Especially 
when the existing players can make use of those new terms as long as they are 
not market-dominant. 

At best, these new TLDs might expand the market by 20% and obtain half or less 
of the _growth_ in domain name registrations. Which means that if they are 
lucky, they will manage to eke out another 5% share. To express my own personal 
view bluntly, I don't know why anyone in their right mind is applying for new 
TLDs at all. The idea that this kind of market entry by tiny mice represents a 
horror and a terror to the elephants who already exist is just getting 
ludicrous. Let's keep in mind the overall market situation: new entrants are 
the ones suffering from an enormous handicap and the dominant incumbents and 
the economic arrangements that sustain them are the ones that need to be shaken 
up.

Milton Mueller
Professor, Syracuse University School of Information Studies
XS4All Professor, Delft University of Technology
------------------------------
Internet Governance Project:
http://internetgovernance.org

> -----Original Message-----
> From: owner-gnso-vi-feb10@xxxxxxxxx [mailto:owner-gnso-vi-
> feb10@xxxxxxxxx] On Behalf Of Eric Brunner-Williams
> Sent: Tuesday, April 13, 2010 9:29 AM
> To: Gnso-vi-feb10@xxxxxxxxx
> Subject: [gnso-vi-feb10] The case for exception
> 
> 
> In the past I've argued that exception from Recommendation 19 is
> unnecessary for registries, existing and anticipated, to find one or
> more registrars which provide public registration services to their
> registries.
> 
> I've argued that exception is unnecessary, and has disadvantages.
> 
> So what might be the advantages to exception?
> 
> Each applicant making the critical planning choice of obtaining the
> exception condition does not need to build, buy or lease a back end
> which is "registrar capable". In a nutshell, the value of CORE's
> technical platform, and any other existing technical platform, from
> Chuck's to Elaine's, drops to ZERO.
> 
> There may be terms in DAGv4 (or v5) which have SLA and audit language
> which still apply to them, but in theory a deck of 3x5 cards database
> and a recycled desktop on a semi-reliable connection running bind to
> publish the zone will suffice.
> 
> Perhaps someone will come up with "registry-in-a-can" package and do
> well in this new few rules market.
> 
> Having no reason to use existing resources or "registry development
> consultants" to draft their application's technical component, or
> operate it when approved, if there is an incentive for such an
> applicant to use a pre-existing plan for the protection of third-party
> rights, I've not thought of it yet. In a nutshell, the value of CORE's
> policy platform, and any other policy platform, from "none" to
> highly-policied, also drops to ZERO.
> 
> Again, There may be terms in DAGv4 (or v5) which have IRT and DRP
> language which still apply to them, but in theory these applicants can
> make their rules up as they go.
> 
> Perhaps someone will come up with "IP-policy-in-a-can" package and do
> well in this new few rules market.
> 
> So, significant reductions in costs to the exception oriented
> applicant, and no apparent incentive to look beyond the ICANN contract
> and the de minimus necessary to avoid ICANN incurred costs.
> 
> In this model there is no economic motivation for any registrar, or
> registry operator operating under Recommendation 19, to be aware of
> the existence of registries operating under an exception to
> Recommendation 19. Whether there is a rational for other GNSO
> stakeholders to be aware of the existence of registries operating
> under an exception to Recommendation 19 I can't say.
> 
> What this means is that registry failure, at least for registries
> operating under an exception to Recommendation 19, will resemble
> registrar failure as we know it today. This will be a big change for
> the ICANN community, going from a "registries are precious" mindset to
> a "registries are junk" mindset.
> 
> Low cost, and freedom to fail.
> 
> Where I'm drawing a blank is innovation. Other than the innovation of
> one string over another, say "HCC" (High Cadre Children, PRC) as
> opposed to DAR (Daughters of the American Revolution, USA), whatever
> innovation an applicant has on plan when seeking classification as a
> registry exempted from Recommendation 19 has to either "work" for a
> total registration below where transition from that exemption is
> required by contract, or it must "work" after the end of exemption, or
> "work" for "exempt registrants" and "not work" or "work differently"
> for "post-exempt registrants".
> 
> I'm sure better cases for innovation can be made than just "innovation
> in three letter acronyms", but as I can't, I'll leave that for others.
> 
> Eric