No Such Weblog

Against my earlier plans, I'll spend next week's Monday and Tuesday at the GNSO's Amsterdam meeting on the ICANN strategic plan. I'll be speaking there on behalf of the ALAC. When I'm done preparing my remarks, the slides will be here.

I spent Monday and Tuesday of this week in the basement of the Schiphol Sheraton, at the GNSO meeting that was renamed to the "Amsterdam Consultation on the ICANN Strategic Plan."

Notes here.

Mainstrem media talk about evil twins, the security monkey points to stories of hotspot billing systems being so widely open that users can easily reconfigure hotspots to free-of-charge mode. Hotspots are insecure, it seems.

But what does "insecure" or "secure" mean when you talk about a wireless hotspot?

This is extremely cool: nss-mdns 0.3 finally provides decent client-side support for mdns; for RPM-based distributions, a spec file is available.

In simple terms, this means that you (1) build a package from this, (2) add "mdns4" to the line in /etc/nsswitch.conf that starts with "hosts", and (3) enjoy the .local zone as if you were using a Macintosh.

(Major linux distributions have been shipping with mDNSResponder enabled for some time. That's the server side on the equation, and it made the linux box visible to nearby Macs. A usable client-side implementation was missing so far.)

Bret Fausett points out that the registrar accreditation agreement is under review, and that ICANN expects to put out a new one in June. It will be interesting to see how the GNSO Council is going to interact with this process.

This is also a good occasion to recall the relationship between policy and contract in the ICANN environment. For purposes of illustration, let's look at Marilyn Cade's public comment on .net and WHOIS. In this comment, Marilyn skillfully conflates current contractual practice (thick registries regularly have a WHOIS that makes far too much information available, and the important thick registry WHOIS services all look similar), diffuse notions of policy, and the very specific concept of a consensus policy (as defined in the relevant contracts). From this concept stew, she derives that any bidder for .net that promises less than a thick registry with all the WHOIS information you could imagine, on ports 80 and 43, is violating applicable policy, and hence not eligible for the future operation of .net.

Marilyn's conclusion is amazing, for several reasons. On the one hand, there simply is no consensus policy that would demand that a thick registry provide a "full" set of WHOIS information. Close inspection of the existing registry contracts will, indeed, show that there are quite a few variations already.

On the other hand, those bidders that the comment attacks propose different variants of thick (or mostly thick) registries. Each of these models would make more information visible on the registry level than what is available from the current thin registry. And each of these models would leave the registrar-level WHOIS services intact.

Finally, there is certainly no explicit policy at all that would mandate gTLD registries to be thick. There was nothing in the GNSO criteria for .net that would envision a mandatory thick registry, and the .net RFP clearly envisions thin registry proposals. This despite the fact that all newly added gTLD registries have been thick - or have been changed into thick registries during contract negotiations, as has been the case for .name. That TLD was originally proposed to run on a thin registry.

I wonder when we are going to see an ICANN community that stops playing around with smoke and mirrors, and starts engaging in rational discourse. After all, we need an ICANN that works, not one that pretends to work.