For "gave up on fiber" they sure are throwing it in the ground here in Louisville at a ferocious rate.

Hint: they didn't totally give up on fiber, just kinda rethought it a bit (using micro-trenching now heavily), and never pulled back their deployment process here in Louisville at all.

Google hasn't abandoned fiber. They're throwing it into the ground here in Louisville faster than they ever have anywhere.

They have rethought how they use it a bit, but to say that they have completely abandoned it is just not true.

None of that is in debate here in Louisville. The part 2 there only concerns with whether there is space on the pole, and if the pole is strong enough to carry the wire. That's all handled as part of the permitting process for being allowed to attach.

The controversy here in Louisville is about how the make ready work happens *after* the permit is issued. Who gets to move the wires around to make the room available to the new attacher on a pole that has already been determined to have enough space and be strong enough.

Yes, the ordinance explicitly included provisions for inspection and correction of problems when these moves occur.

From what I hear, the state Public Service Commission is completely ok with the ordinance that Metro Louisville passed. That's some hearsay, but it's pretty in-line with what the PSC would like to see happening for fostering competition.

Hardly. Google is going out of their way to comply with regulations. They are *also* trying to get those regulations change, for everybody, because it benefits them, sure, but they certainly aren't trying to skirt the regulations.

BTW, you don't have to be a telecom to put wires on poles...all you have to have is a franchise agreement with the city.

Well, unless you're AT&T, in which case you were granted a statewide franchise by the state legislature in 1886, so they don't have to go in and negotiate franchise agreements with each individual municipality that they want to provide service to in the state.

So, how's that level playing field now?

I haven't checked this specifically, but I suspect Google *is* a telecom. All it takes is a filing with the state utility commission (the Public Service Commission, in Kentucky).

Also, TWC had wires up on the poles before they were a telecom, you don't actually have to be a telecom to put wires on the poles.

All you need is a franchise agreement with the city. (Well, except for AT&T, which was granted a statewide franchise by the state of Kentucky back in 1886)

Funny quirk here. AT&T doesn't actually have a franchise with the City of Louisville. Back in 1886, our state legislature granted AT&T a statewide license to operate telecommunications infrastructure statewide.

So every new operator that provides service in Kentucky has to get local franchise agreements in place wherever they want to provide service, but AT&T can just go at it willy-nilly.

Actually, in Louisville (I'm a lifelong resident and have been following this issue pretty closely for quite some time) the poles *are* owned by AT&T...well, actually by AT&T and our local power utility (Louisville Gas & Electric, LG&E)...about 60% by LG&E, about 40% by AT&T...with a smattering of others owned by others like TWC. But that's not actually relevant here. This isn't an issue about who gets to attach to the poles...that's regulated and new providers such as Google are allowed to attach to the poles, there's no debate about that, and AT&T isn't fighting that.

What AT&T *is* fighting in the make ready process that the city modified in the ordinance passed. Traditionally, for a new attacher to attach to a pole, anyone that has wires on the pole (excluding LG&E, power cables are up on the poles passed the safety exclusion zone...none of this has any implications for LG&E at all) has to come out and move where their wires attach on the pole to make room for the new attacher. This, also, is regulated. AT&T, and whoever else is on the pole *has* to do this to allow a new attacher (assuming the pole can handle the new attacher...that's all part of the permitting process that is done before any of this ever comes into play) room to attach...but they can take their own sweet time about it. One of the Metro Council members recounted how AT&T held up a road construction project for *18 months* because of how long they took to come move wires to new poles. The "One Touch Make Ready" process that was adopted by the Metro Council (Metro Louisville is a merger of the old city of Louisville and Jefferson County governments, thus "Metro Council") allows the new attacher to hire a contractor to do all of the make ready work in one shot if it won't cause any outages (there are some other considerations that come into play if there is a reasonable expectation that the work would cause outages). *This* is what AT&T is throwing a hissy about because they don't want anyone else touching their *wires*.

>What hasn't really been mentioned is the use of cdp.

Or even better, the much more widely supported (including Cisco in any halfway modern version of IOS), non-proprietary, and technologically superior LLDP.

And to take it one step further, this really isn't a 'full mobile browser'. Its a 'full browser that happens to be on a mobile device'

When you go to web pages that would serve up a "mobile" version of their page to devices like the iPhone, or Blackberries, or whathaveyou, with the N900 (even with the built-in Fennec based browser, but with this Firefox version as well) you don't get the mobile version of the page, you get the regular version of the page...and its quite usable doing it, too.

The Internet uses about 10-12 /8's per year.

Yes, it buys a bit of time, but not a lot.

And given that you're already talking about validating functionality of most of the Internet with these new address types...well, you're not saving yourself much work over just going ahead and doing IPv6.

To add to the other good replies to your message.

"Recalling" those "huge" blocks (and note that there is no legal justification for any entity to be able to do so) would also only be a band-aid. If you "recall" all of the /8 blocks that are globally assigned that are likely underutilized, you only extend the lifetime of IPv4 by a handful of years.

Many people point to NAT as a way to prevent the depletion of IPv4 address space, but what most of them don't realize is that NAT (despite the huge problems that hitch along for the ride) has *already* served that purpose. We're *still* running out of IPv4 address space, even with ubiquitous use of NAT (including being hobbled by the problems that it brings). If NAT hadn't seen widespread use already, we would have run out of IPv4 address space years ago.

NAT creates problems, and it doesn't even fix the problem that people are positioning it to fix (ie, the depletion of IPv4 address space). We're still going to run out, we still need to transition to IPv6, even if you "recall" those big blocks and make everyone use NAT. Taking the steps you suggest only extends the horizon of the problem, and only extends it by a relatively small amount.

Uhm...to say that there is no unified protocol for video and voice on XMPP just doesn't match reality.

The jingle specs are fairly universal in the XMPP world. Google's, interestingly enough, is actually a bit out of date at this point, but they've promised to update to the jingle specs once the XSF has settled them, which has only really happened pretty recently.

Other clients that support some level of jingle A/V, where some of them may be audio only (and remember, there's basically no support needed at the server level for any of this) are Psi, Cocinella, Spark (in Windows), and now Pidgin. Talkonaut is a mobile (WinMo and Symbian) client that does jingle voice. More niche clients that have support are some of the IP PBX systems like Asterisk and FreeSwitch. There are others that are listed in places that have support for it, but I don't know the degree of that support, so I'm not going to list them...others can speak up if they know better on some of the others.

iChat is definitely the outlier in the XMPP world for not supporting jingle, or at least supporting something jingle-like (Google hasn't moved up to the standard as specified yes, as I said).

Oh, and just to knock down a bit of bias...I'm typing this on a Mac, so ostensibly, I'm one of those snobby iChat users as well, except that I don't use it.

They lost, and they lost rather completely.

Here's a starting point for exploring some of this data. There's probably more places where this data is available from the NWS in very open formats, and I believe more is to come.

http://www.weather.gov/rss/