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