I may fault ICANN on many things, but I don't find myself agreeing with your characterizations of ICANN.

First off, ICANN has been glacial with regard to new top level domains - on average about one per year. That is a long way short of "barely comprehensible" and certainly not even close to "infinite soon".

As for following name conventions - ICANN has been very closely following the hostname conventions and the internationalized name rules established by the IETF. Perhaps the only thing that ICANN has done that differs is that ICANN has been questioning whether single letter top level domains ought to be allocated.

As for Beckstrom - he is unknown to me, but I do fear that his "no central point of control" point may carry him too far into believing that institutions such as ICANN don't need someone firmly in charge and willing to say "no" to expansion and mission creep.

I hope he recognizes that ICANN is supposed to make sure that the domain system works and that ICANN is not to be a policeman doing trademark enforcement for the intellectual property protection industry or enforcing various governments' views about what is acceptable use of the net.

Syn flooding is very old hat - from the 1970's.

I'm talking about attacks in which the attacker connects to the server, sends the protocol hello sequence, but either does not do a TCP ack or does not provide a sufficient receive window. In both cases the sender (the TCP stack of the machine under attack) sits waiting for a TCP state change that never occurs.

Sendmail and other servers are probably vulnerable to this kind of thing. And it is not necessarily the server application itself may not be where the core of the server slowdown occurs. For example, if one were to spread this kind of attack across several different types of TCP-based protocols (SMTP/SMTPS, IMAP(S), HTTP(S), DNS(tcp version), etc then the operating system's TCP engine might start suffer from too many TCP control blocks. (And it isn't just the memory occupied - some silly implementation might do a sequential scan rather than hash lookups when matching incoming packets to TCP connection blocks.)

There is another version of this kind of attack in which rather than sending incomplete data the attacker simply is extremely lazy about sending TCP ACKs - it does so only enough to keep the connection alive. Yet another alternative is that the attacker maintains a TCP receive window that is just a tad too small to contain what the attacked machine is trying to send back.

There is a flip side of this - one can build an email server that is closely integrated with the TCP stack so that incoming mail is validated while the TCP connection is open. Then if the incoming mail is bogus the machine can go into slow ACK/small receive window mode and try to constipate the TCP stack of the spamming machine. Unfortunatly that technique was more useful before hordes of bots were used as spam amplifiers.

I see the "demanded" part, but I don't see any evidence of the "subsequently received" part.

By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open.

But those people will work at the behest of somebody and, after watching president Nixon knock off Attorney General after Attorney General during the Saturday Night Massacre, I tend to wonder about the extreme limiting cases.

Who will be the person who gets to hold the master crypto keys used to sign the root zone?

Somebody, somewhere, has to do this. Who?

Even the Whitehouse.gov website has a 1x1 pixel web bug that is in violation of their own privacy policy, not to mention 5 USC 552a.

The text of the bill does not yet seem to be visible, but the Rockefeller press release suggests that open source means code that does not limit use or distribution. One could argue that GPL2/3 imposes material limitations on use and distribution and thus would not qualify under the bill.

The GPL's position under the bill may not be helped by the use of the words "free" rather than "open source" by many deep in the GPL community.

It is not at all clear that Google is breaking no laws.

Try taking a photograph of the Hollywood Sign - it's protected by trademark or copyright law and the folks in Hollywood do go after people.

The latest King Kong flick had a note in the credits that the had licensed the image of the Empire State Building.

Architects sometimes try (and succeed) in protecting their creations.

And Google is in it for the money - they use these photos to gain more click data and to sell more ads. Google is not some innocent taking a few snapshots.

So don't jump too quickly to the conclusion that Google isn't violating some of the property owners rights.

From the point of view of most users the internet address is a URL/URI, not an IPv4 or IPv6 sequence of bits.

The fact that some protocols work poorly over NATs is based on architectural aspects that we've known are wrong for years - most particularly the carriage of lower layer addresses within higher layer protocols. SIP, particularly its use of SDP, is an example of this and which is why SIP tends to have trouble with NATs and needs assistance from things like STUN. This may the reason why Skype use so greatly dominates SIP.

HTTP/HTTPS is becoming the new transport. And HTTP/HTTPs anticipates the kind of proxying and relaying that comes as the net evolves into a lumpy world of NATs, firewalls, and application level gateways.

This is a minor nit - ARP cache timeouts are normally on the order of 300 seconds, not two minutes.

A less minor nit is this: IPv6 does not help decrease the size of routing tables as seen by major providers. Nor does IPv6 reduce the burden of sending routing updates so that routing updates are propagated faster than the underlying rate of change of usable net paths. (Enterprise subnets, whether IPv4 or IPv6, don't generally propagate into the routing announcements as seen by the big carriers.)

The compelling argument, for me at least, is that IPv6 is really a new internet that runs along side of the existing IPv4 net - there is no direct interoperability. This means that pretty much any new expansion of the net is going to require IPv4 connectivity, and IPv4 addresses, to reach the legacy net. And that makes IPv6 redundant from the user's point of view. That sort of drains the oil out of the IPv6 crankcase.

Of course the biggest argument of all is that IPv6 does not solve the hard issues of propagating routing information and finding usable paths across the net, particularly as the demands of human-conversational traffic and the political acts of nations are (unfortunately) driving routing to become increasingly aware of the types of traffic being routed.

I'm waiting to be shown that I'm wrong - I helped do the very first calculation of IPv4 address consumption back in the mid 1980's. And I was in the group at Sun back in the very early 1990's where IPv6 took form. I spent time at Cisco wrestling with questions like how to efficiently mechanize 128-bit longest-prefix matching on 32 and 64 bit hardware. And my company currently has IPv6 testing products. So I've been watching IPv6 for what will soon be two decades.

To me one of the tilt-points of IPv6 will be when I can go into Frys Electronics and find IPv6 capable print servers and other widgets of that ilk on the shelves.

I saw ISO/OSI come and go (I was rather a fan of TUBA - which included the use of ISO/OSI CLNP for the new IP layer - when the various IPv4 alternatives were being considered in the early 1990's.) It would not surprise me to see IPv6 go the way of ISO/OSI.

Google blurred the satellite photo of the US Naval observatory in DC, a public building, in order to protect VP Cheney.

If Google is willing to protect the privacy of a public figure than it ought to be even more protective of the privacy of a private homeowner by burring a photo taken while being a non-invited intruder on that homeowner's own property.

As I read it Google was trespassing on private property and took photos while on that private property. The court says it is OK for Google to keep the photos.

OK, suppose now that I just happen to wander into Google 's offices in Mountain View while a receptionist is in the bathroom and go into the building and take photos of Google's stuff.

I guess under this ruling I would get to keep my photos?

I've had Motorola phones that have a micro USB connector but refuse to accept a charge from anything except a Motorola charger.

I would hope that this agreement to use USB goes further than simply adopting the physical connector.

It should be possible to attach to any convenient USB plug - without benefit of drivers - and recharge a phone.

There is a strong chance that many of the claims in these patents have predecessors in the Capability Based operating systems of the 1970's.

Check out the Intel 432 architecture.

Check out IBM's "SWORD" project.

Check out UCLA Data Secure Unix.

Check out the Plessy capability systems from that period.

SRI did a lot of work in this area as well. And so did we at System Development Corp. (SDC).

The idea of a capability is a descriptor that defines access rights in an extensible manner - for example one can say that the disk driver can't deal with tape hardware or that a text editor can only do certain things to a particular SQL database.