Re: [registrars] Regarding establishing a coop entity to run an auction system

[Eric Brunner-Williams in Portland Maine <brunner@xxxxxxxxxxx>]

Bruce,

Whatever entity picks up the contention problem there will be formation,
authority and accountability issues.

We can always say some particular proposed entity won't work, because we
can always decide that solving the non-technical contention problem is as
hard or harder than solving the technical contention problem.

"Put it in the registry" is one solution. The "registry does it" is an
answer to a class of problems, from "universal whois" to clumping groups
of names renewal dates (synchronizing), to ... mediating contention between
registrars for dropped names.

I suppose I should point out that putting VGRS in a position where it can
prefer NSI requires some kind of "blue helment" to police the opportunity
for preference that violates the equal access clause in the RRA.

The need for speed is obvious.  Responses that are as delayed as ICANN's
to VGRS's introduction of wildcards means one quarter _after_ a well-formed
pleading is placed in process is the earliest an answer can be expected,
and if the .net and .net 3rd-party evaluator tenders are any guide, one or
more additional quarters to act on a proposal. According to my cracked
crystal ball, that makes it about four quarters from when ICANN and the
Accumulators created the problem to when the NewProcess interposes on its
first contended-drop with its new, no-contention process.

That said, I don't think the problem is that we have too little time to
fix the problem, I think the problem is that we have too much time. The
"attraction" of calling a service a "registry service" because of the
unitary nature of registry management and its ability to act responsively
(note well: not "responsibly") is not going away any time soon. Either we
fix us (yes, you read that correctly) and invent the means of calling a
service a "registrar service", without creating non-scalable consequences,
or every future service that can be "gamed" into crisis will be solved in
the "registry service" form.

With that pre-amble,

> I assume that a corporate entity is formed as a cooperative.
> Membership is available to any accredited registrar.

Independent of the legal form of the entity, if the benefits are not, in
theory available to all registrars who have some registry-access right,
then the control of the entity over the mechanism to manage or control
the benefits are likely to violate good taste, equal access, or the Sherman
Act, or all three.

> Would the cooperative then elect a Board?

Indepndent of the by-laws of the entity, whether they are copied from my
natural foods cooperative or from the rules for harmony under Kim Il Song,  
and whether the responsible actors are chosen by lots or by election, the
entity will need role-based actors with sufficient responsiblity to carry
out the task of solving the contention problem.

> Does this cooperative then employ staff, set up systems etc, 
> or does it outsource in some way?   Outsource is probably the faster
> model, as there are already connection aggregators that have the
> necessary hardware and software.  However the coop would probably need
> to run a tender process to select the be best provider.
>
> It would then need a business model to operate, with some revenue stream
> that is sufficient to manage its costs.

Your proposal, trading off the cost of build-out the registry to sustain
the connections and response, has all of these feature as well, modulo the
"feature" that VGRS manages the (possibly virtual) outsource contract.

Is there a "best provider"? How can there be a "best provider"? No one has
built such a system, outside of academia where every possible dbms write
contention problem has a thesis somewhere.

The new entity doesn't need a business model, we already have a failed
market and unscalable technical and regulatory process. The new entity
must solve a specific problem, if we "determine" quarterly its funding, or
it "determines" quarterly its refunding, that is secondary to solving the
problem. If a "business model" for lifeboats is necessary to comfort the
those attempting to tred water, we can make some fine paper lifeboats that
are guaranteed to both float and look good at the same time. I'll stick
with a wooden boat. Oars are good, paint is optional.

> I am not entirely sure that this is a faster process than having ICANN
> manage a tender.

Gee. You've made all the race-systems (Snap, Pool, eNom, ... ) qualified to
bid on a system-other-than-race, introduced competitive bidding and compared
that to the usual ICANN turtle race. Looks like a non-functional straw-woman
to me.

> I would see it being defined as a new registry service.

I can see how you get there, registrars can't chew gum and compete at the
same time.

> For future gtlds ...

Theory is wonderful. In theory .pro needs a backorder contention system.

Cheers,
Eric