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.
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.
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.
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.
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.
"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.
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.
There are technical benefits to IPv6. But we don't need them yet, or for at least 10 years more. Effective NAT, and better handling of non/8,/16, and/24 network spaces has heavily reduced and nearly eliminated the need for them for the next decade.
Uhm...try about 5 years...if we're able to *really* stretch things.
Current trends show us running out of IPv4 space in 2011 at the global level. The regional registries keep about 6 months "inventory" on hand, so tack on a half year to that. At that point, the IPv4 addresses your organization has is all you're going to get unless a "gray market" of IPv4 address trading gets going, and there's plenty of ugly that goes along with that.
You have a lot of ignorance about IPv6 display in your post, but I wanted to pick on this one as just the most egregious.
>Yes, with IPv6 your IP pool is dependent on your ISP, with no reserved IPs. So, you keep the ISP you have forever, or re-ip every single box on your network if you change.
That is patently untrue. You can get provider independent IPv6 addresses from virtually all routing registries these days.
Yes, IPv6 was originally envisioned as completely using provider assigned addresses, but that concept has been reversed and provider independent IPv6 address are readily available today.
You would think the idea would be to chuck in drives (with some minimum, like 8 or 12) and have the physical data storage be totally abstracted from the user, with N+2 redundancy and hotspare functionality totally guaranteed, and then allow the user to create LUNs without concern for underlying physical storage.
When you need more space, you add more drives and the system manages the striping, re-striping as necessary for optimum throughput and maximum redundancy, rebuilding failed drives as necessary. There are systems out there that do this sort of thing, but they're *expensive*.
Take a look at HP's EVA line. They're really quite good at this.
I'd be careful about using the terms "optimum" and "maximum" in that last paragraph, but they get quite close to that mark.
Other vendors have equipment that performs about as well...IMO, the HP EVA line is the best at it, however.
Jeff (only affiliated with HP as a mostly happy customer)
Yes, that's a smaller task (though I wouldn't call it small...there are all sorts of corner cases to consider with that sort of solution).
But its the same answer. If its gonna take you 2 years, you need to start now. If its gonna take less than 2 years, then you've got a little bit of time...but do you really want to risk painting yourself in a corner if it doesn't go as smoothly as you expect?
I would say start now (if you haven't already) and if you get done before hand...well, good for you, you're ready to go early. I'd much rather be ready to go early than late.
The reality of the situation is that stateless autoconfig in IPv6 is one way to get basic networking connectivity setup, DHCP is another. Depending on your situation, the phase of the moon, and any of a number of philosophical viewpoints held by the network admin, stateless autoconfig might or might not get used. *shrug* Even with stateless autoconfig, DHCPv6 might also get used to configure other information that is not handled by stateless autoconfig (DNS servers, NTP servers, any of a huge list of other things).
The important point to remember, though is *2 YEARS*. That's how long we have until the IPv4 address space is fully allocated at the top level. It may take a little longer (months?) before people start really feeling any pain from that at the end-user level. But its the critically important point for people to realize. Can you be ready for IPv6 in 2 years? You need to be. If its gonna take you 2 years to get IPv6 functioning in your network, then you need to start *NOW*.
>Has Viacom (as a corporation) actually learned anything from this exchange?
There's no guarantee that Viacom has actually given in as the title of the article indicates.
Yes, the article seems to indicate that Viacom has backed down, but, unless I missed something, there was no communications from Viacom indicating that they backed down. The communication in question was from YouTube indicating that the content had been reposted as a result of the counter-notice.
Keep in mind that, under the DMCA rules, the service provider has to take the content down when given a notice, but it is equally responsible to post the content again if counter-notice is filed. At that point, it is up to the party filing the original notice to file an actual lawsuit to continue to pursue the take-down of the content. Just because they didn't file a lawsuit and get a temporary injunction to maintain the take-down in the 10 days before the counter-notice takes affect, doesn't mean that they don't intend to continue to pursue this issue.
Perhaps there's more communications that are not yet public from Viacom indicating that they don't intend to push forward with this, but just because the content gets re-posted doesn't mean that they have necessarily given in.
Only parroting comments I heard from folks while watching NASA TV (I've been playing with multicast on our network and NASA TV is a nice good stream to multicast around). Perhaps I should've clarified that statement as also being comments that I had heard from relatively authoritative sources...I don't mean to make any claims of absolutely truth on it.
There were also some references (if I remember correctly) to the velocity of whatever substance impacting the orbiter was a result of the delta-v of the shuttle, rather than the delta-v of the chunks of whatever. Some indications that this is the reason that foam impacts in the first minute or so after launch were the most problematic because that's when the delta-v of the shuttle is highest, apparently.
I'm no expert, here, just passing on comments I've heard watching this stream...whether its all legit or not, I'll let you decide.
Slashdot Mirror
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/
There are technical benefits to IPv6. But we don't need them yet, or for at least 10 years more. Effective NAT, and better handling of non /8, /16, and /24 network spaces has heavily reduced and nearly eliminated the need for them for the next decade.
Uhm...try about 5 years...if we're able to *really* stretch things.
Current trends show us running out of IPv4 space in 2011 at the global level. The regional registries keep about 6 months "inventory" on hand, so tack on a half year to that. At that point, the IPv4 addresses your organization has is all you're going to get unless a "gray market" of IPv4 address trading gets going, and there's plenty of ugly that goes along with that.
A decade? No way.
You have a lot of ignorance about IPv6 display in your post, but I wanted to pick on this one as just the most egregious.
>Yes, with IPv6 your IP pool is dependent on your ISP, with no reserved IPs. So, you keep the ISP you have forever, or re-ip every single box on your network if you change.
That is patently untrue. You can get provider independent IPv6 addresses from virtually all routing registries these days.
Yes, IPv6 was originally envisioned as completely using provider assigned addresses, but that concept has been reversed and provider independent IPv6 address are readily available today.
When you need more space, you add more drives and the system manages the striping, re-striping as necessary for optimum throughput and maximum redundancy, rebuilding failed drives as necessary. There are systems out there that do this sort of thing, but they're *expensive*.
Take a look at HP's EVA line. They're really quite good at this.
I'd be careful about using the terms "optimum" and "maximum" in that last paragraph, but they get quite close to that mark.
Other vendors have equipment that performs about as well...IMO, the HP EVA line is the best at it, however.
Jeff (only affiliated with HP as a mostly happy customer)
Check out the privacy extensions to stateless autoconfiguration. Problem solved.
Jeff
How about saying goodbye to flying to a funeral.
They're really gonna expect people to get cleared 72 hours in advance to go to their mother's funeral (to pick an example)?
Well, I guess they (TPTB at the TSA) continue to demonstrate how utterly clueless they are.
>Nope, you won't get any business benefit.
Here's a problem.
I consider the basic ability to grow the IT infrastructure (and therefore the business) to be a business benefit.
Yes, that's a smaller task (though I wouldn't call it small...there are all sorts of corner cases to consider with that sort of solution).
But its the same answer. If its gonna take you 2 years, you need to start now. If its gonna take less than 2 years, then you've got a little bit of time...but do you really want to risk painting yourself in a corner if it doesn't go as smoothly as you expect?
I would say start now (if you haven't already) and if you get done before hand...well, good for you, you're ready to go early. I'd much rather be ready to go early than late.
DHCP does a whole lot more than that.
The reality of the situation is that stateless autoconfig in IPv6 is one way to get basic networking connectivity setup, DHCP is another. Depending on your situation, the phase of the moon, and any of a number of philosophical viewpoints held by the network admin, stateless autoconfig might or might not get used. *shrug* Even with stateless autoconfig, DHCPv6 might also get used to configure other information that is not handled by stateless autoconfig (DNS servers, NTP servers, any of a huge list of other things).
The important point to remember, though is *2 YEARS*. That's how long we have until the IPv4 address space is fully allocated at the top level. It may take a little longer (months?) before people start really feeling any pain from that at the end-user level. But its the critically important point for people to realize. Can you be ready for IPv6 in 2 years? You need to be. If its gonna take you 2 years to get IPv6 functioning in your network, then you need to start *NOW*.
>Has Viacom (as a corporation) actually learned anything from this exchange?
There's no guarantee that Viacom has actually given in as the title of the article indicates.
Yes, the article seems to indicate that Viacom has backed down, but, unless I missed something, there was no communications from Viacom indicating that they backed down. The communication in question was from YouTube indicating that the content had been reposted as a result of the counter-notice.
Keep in mind that, under the DMCA rules, the service provider has to take the content down when given a notice, but it is equally responsible to post the content again if counter-notice is filed. At that point, it is up to the party filing the original notice to file an actual lawsuit to continue to pursue the take-down of the content. Just because they didn't file a lawsuit and get a temporary injunction to maintain the take-down in the 10 days before the counter-notice takes affect, doesn't mean that they don't intend to continue to pursue this issue.
Perhaps there's more communications that are not yet public from Viacom indicating that they don't intend to push forward with this, but just because the content gets re-posted doesn't mean that they have necessarily given in.
As is so often the case, IANAL.
Jeff
Ok, I'll buy that as being possible.
Only parroting comments I heard from folks while watching NASA TV (I've been playing with multicast on our network and NASA TV is a nice good stream to multicast around). Perhaps I should've clarified that statement as also being comments that I had heard from relatively authoritative sources...I don't mean to make any claims of absolutely truth on it.
There were also some references (if I remember correctly) to the velocity of whatever substance impacting the orbiter was a result of the delta-v of the shuttle, rather than the delta-v of the chunks of whatever. Some indications that this is the reason that foam impacts in the first minute or so after launch were the most problematic because that's when the delta-v of the shuttle is highest, apparently.
I'm no expert, here, just passing on comments I've heard watching this stream...whether its all legit or not, I'll let you decide.