New registry services: WLS and Sitefinder as use cases.

In thinking about the new registry services PDP that is now beginning in the GNSO, I’m trying to find use cases for the planned decision-making process, and to figure out why the process should produce what result — and how the rationale for the …

In thinking about the new registry services PDP that is now beginning in the GNSO, I’m trying to find use cases for the planned decision-making process, and to figure out why the process should produce what result — and how the rationale for the suggested decision can be cast into an objective criterium. I’m less interested, at this point, in arguments about the contractual standing that ICANN might have to deny or acknowledge any particular service.Two examples tonight: SiteFinder and WLS.I feel that SiteFinder is relatively easy — not so much because of stability considerations, but most importantly for two other reasons: (1) It moved decisions from the edge to the center, thereby negatively affecting competition. (2) It caused cost to the public, for the benefit of a single player, much like environmental pollution.WLS is a more difficult case. It grew out of a “tragedy of the commons” situation, as Rick Wesson observed accurately: Registrars were using up shared resources (transaction bandwidth) that came without a price tag to the point where these resources degraded, and “normal” registration was affected; using overflow pools and other limitations only moved the cattle to a different pastry. The WLS proposal appeared to introduce an approach to the registration of expiring names that would not lead registrars to engage in behavior that is detrimental to the public (although perfectly rational for the individual registrar!). The downside is that WLS gives precedence to a specific business model for registering expiring names. Different business models are essentially pushed out of the market.Had there been an alternative to WLS in order to stop the detrimental behavior? I believe yes — namely, changing the price structure for using registry resources in a way which rewards successful registrations, but financially punishes failed transactions and excessive use of bandwidth. In such an environment, publicly detrimental consumption of transaction bandwidth would be irrational (and ruinous); different providers of expired domain name registration could continue to compete on an equal footing, and with the business models they desire; many of the complexities of WLS would simply be unnecessary.Now, how should ICANN have dealt with the situation in the light of this argument (which, I believe, wasn’t made at the time — but I might be wrong)? My current inclination would be to say that ICANN should have denied WLS, and should have favored the decentral approach. If that’s indeed the right approach, then how can the argument be cast into a more generic form that would be useful for an evaluation process?Comments welcome!

Yesterday’s council call

Yesterday’s council call (besides re-electing Bruce Tonkin as GNSO Chair and voting on the number of representatives on the newly-created WHOIS task forces) mostly dealt with the new registry services issues report. Since the report had been relea…

Yesterday’s council call (besides re-electing Bruce Tonkin as GNSO Chair and voting on the number of representatives on the newly-created WHOIS task forces) mostly dealt with the new registry services issues report.Since the report had been released less than 24 hours before the call began, there was less discussion than I had anticipated, mostly dealing with clarifications and some procedural issues (and with the registries stating a number of concerns). It seems like there is general agreement (including ICANN staff that was present on the call) that the suggested PDP will not be about establishing a new consensus policy (that would then be binding for registries), but that it is about definining a process that is used by ICANN for reviewing proposals by the registries that require ICANN approval under the existing contractual terms.This understanding is also mirrored in the draft Terms of Reference that Bruce Tonkin has extracted from the issues report.The Council will vote on commencing the policy-development process on a conference call on 2 December, in order to give constituencies and council members time to review the issues report and refine the terms of reference.

Shadow Board?

The idea to have a shadow board is currently floating through the ICANN blogosphere (icann.Blog; Chris Ambler; ICANNwatch). Such a shadow board would vote on the same topics as the real board, but would deliberate and discuss entirely in the open….

The idea to have a shadow board is currently floating through the ICANN blogosphere (icann.Blog; Chris Ambler; ICANNwatch).Such a shadow board would vote on the same topics as the real board, but would deliberate and discuss entirely in the open. My guess would be that, with many (not all!) of the important topics, this might be a far less interesting exercise than it may seem: Many of the juicy discussions about consensus policies, for instance, happen among the members of the GNSO council, in the GNSO’s task forces.Maybe a shadow council would actually be more interesting than a shadow board.

What’s really in that Issues Report?

After having read the issues report on new registry services several times and after having slept over it, I’m still trying to parse what ICANN staff is really suggesting here. Your comments would be highly welcome.

After having read the issuesreport on new registry services severaltimes and after having slept over it, I’m still trying to parse whatICANN staff is really suggesting here. Your comments would behighly welcome.

Fedora Core Notes.

I’ve been playing around quite a bit with Fedora Core recently, the successor to the non-enterprise versions of RedHat Linux — RedHat 9.1, if you want.

I’ve been playing around quite a bit with Fedora Core recently, the successor to the non-enterprise versions of RedHat Linux — RedHat 9.1, if you want.