No Such Weblog

I have been ranting a lot about Linux’ support for my thinkpad: APM suspend (and, more importantly, resume) has been broken for quite some time, and is getting constantly worse. With the latest Fedora kernel, the machine won’t even suspend any more when the wired ethernet driver is loaded; when that driver is removed, the machine still goes nuts upon resume.Time to revisit ACPI, which was poorly supported when I originally set up the laptop, and swsusp, which still isn’t included with Fedora’s kernels. Turns out that, these days, ACPI suspend and resume is far more stable than APM suspend, and that swsusp2 just works when installed according to Matthias Hensler’s useful instructions.

One of the GNSO’s WHOIS Task Forces is now invoking the ICANN ombudsman, to be able to move on with its work. In December 04, ICANN staff had effectively vetoed one of the policy recommendations the group had made. Since then, the group has not succeeded in even getting an appointment for a conversation with ICANN staff.

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.

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.)

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?

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.

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.

The excellent anonymous Still at Large blog points to this proposal currently under discussion with the registrar constituency. Basically, that proposal amounts to rejecting those recommendations from GNSO WHOIS Task Force 1+2 that haven’t been torpedoed by ICANN staff. Since the registrar constituency is (besides registrants) one of the parties “most affected” by the proposed policies, that constituency’s vote will have to be taken very seriously.As one of the members of TF1+2, I’m of course unhappy that the group has finally come full circle, and that the work done over the past year (it’s not just 175 days — there were TF1 and TF2 before!) seems mostly moot today: On conflicts between applicable law and the RAA, we’re waiting for ICANN staff (still no appointment, sorry); on tiered access, we’re apparently back to “fact-finding” (not that we spent spring 04 on that, in two separate groups); and now, on notification and consent, we can look for a new consensus, because the contracted party objects.Looking for new consensus, though, becomes increasingly difficult: The registrar constituency is now about to reject a consensus that has been negotiated (and, I seem to recall, approved) by that very constituency’s representatives. It is doing so at a stage in overall WHOIS policy-development at which the formal PDP is being used as a process for documenting agreement.The message that the registrar statement is about to send to the overall ICANN community is that its representatives on Task Forces can’t be taken seriously. That’s far worse news than all the missed deadlines and other systemic flaws in ICANN’s policy-making process.

Tonight, I have shut down the mutt bug tracking system: The system (a debbugs installation) wasn’t able to cope with the spam thrown at it, and I didn’t have the resources needed to harden it against the assault.It’s sad that spam makes e-mail-based automated systems increasingly useless.

On a train ride the day before christmas, I observed a group of four people sitting around a table: A mother with her two teenage sons, and a not-too-geeky twentysomething. The teenagers had an MP3 player, one of the cheap USB-stick-like things; the twentysomething had a laptop and a bunch of CDs. Within relatively short time, the twentysomething and the boys had connected, and started talking about music, and started sharing it — or, attempted to share it, going through various technical problems. The story these four people tell is about the social dimension of music and culture, and more specifically, about the social dimension of sharing it.This dimension is not about positioning some product as a cultural movement, marketing-wise: Rather, it is at the very basis of the culture we live in.If anyone was to design a truly cool (as in, cooler than iPod) portable music player, that gadget wouldn’t just be a player that is made a “cultural movement” by marketing. Instead, it would be desinged to connect people by letting them share the music stored on it. It would be designed to strengthen the social fabric that sharing of culture can be. It would be easy to extract stored music. It would be easy to share music between devices, wirelessly. It would be easy to share whatever you listen to currently, by broadcasting (podcasting?) a stream over a local wireless network. It would be easy to tune in to whatever music the others at the table (in the room, on the train, on the plane, …) listen to, if they want to let you in.Obviously, the iPod isn’t that kind of device today, and the social fabric that culture provides is alien to its “cultural movement” of cool, white-headphone-wearing solitude. Apple doesn’t even want you to extract the music stored on it, and the headphones won’t make it easy for you to share whatever you listen to with your seat neighbour. (Nevertheless, iPods are rather nice and quite addictive gadgets.)The technology you need to build the music-sharing gadget I’m dreaming of is there today. But, unfortunately, culture’s social dimension is thoughtlessly denounced as “piracy” these days, so I don’t expect to see that cool device I imagine in the marketplace any time soon.In particular not if the studios get what they want next year.