ICANN ICANN Email List Archives

[gnso-vi-feb10]


<<< Chronological Index >>>    <<< Thread Index >>>

[gnso-vi-feb10] The case for exception

  • To: "Gnso-vi-feb10@xxxxxxxxx" <Gnso-vi-feb10@xxxxxxxxx>
  • Subject: [gnso-vi-feb10] The case for exception
  • From: Eric Brunner-Williams <ebw@xxxxxxxxxxxxxxxxxxxx>
  • Date: Tue, 13 Apr 2010 09:29:27 -0400

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



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy