Actually, some of the comments are that there is at least a perception that ice damage has increased since the return to flight after Columbia.
The thought is that since they've added an extra hour into the countdown after the external tank is fueled that there is a longer time for ice to build up, and then a great tendency for it to break off and smack the orbiter.
Oh, and for another tidbit. Ice, since its denser, and heavier than the insulating foam, is a bigger problem than the foam is when it breaks off. It takes a smaller chunk of ice to break off and smack the orbiter to cause an equivalent amount of damager to a larger chunk of foam.
Ah, ok, so you wouldn't qualify, at present, for IPv4 PI space either, you've just got it through a legacy setup.
Yes, that is annoying for someone in a position such as yourself. Fortunately or unfortunately, depending on your viewpoint, there aren't going to be all that many people in a situation such as that (in the overall scheme of things).
Sure, its secure, but its not secure because of the IP address mangling. Its secure because the NAT device is looking at every packet, keeping track of what conversations are going on and deciding which to forward (and mangle) based on the state that its keeping.
The problem with your argument is that you qualify it with "not in the DMZ". Putting it "in the DMZ" (which isn't a real DMZ anyway) is still NAT, and your protection just went *poof*. NAT (ie, just mangling IP addresses) doesn't provide any protection. Having stateful inspection of every packet and deciding which ones to forward on is what provides protection. This means that a stateful inspection firewall is capable of providing exactly, completely, 100% the same level of security; oh, and do so without breaking any protocol that tries to use the Internet as a real communications network rather than some simplistic I-make-a-request-and-get-a-response-back pseudo-communications network.
Do try to keep up. That page was posted sometime in 2003. We've got 4 more years of data and growth to look at now, and the current projections (including by one of the leading experts who had a message that was also quoted on that page) is that ARIN will be allocating the last of its blocks in March of 2010, with the RIR's allocating the last of the blocks from their level in approximately 6 to 36 months. So, best case, you will not be able to go back to the well to get more IPv4 addresses in March of 2013.
I'm not sure what it would take for you to call it a shortage, but this certainly qualifies in my book.
You're right...there was a fair amount of hand-waving in my message (hey, its a slashdot comment, of *course* is over-simplified;), and there are serious challenges to ipv6 deployment, I totally agree, but let's go back to the start of all of this controversy. We're going to be out of ipv4 addresses is roughly 3 years. *NOW* is the time to start working on these issues. We're starting to deploy ipv6 in our network where I work, despite *knowing* for certain that some of our equipment doesn't support it. But we're beating up on those vendors, and getting to say things like, "We've got ipv6 deployed in our whole internal network except where your equipment gets in the way. You're behind the curve, get with it." (literally, I've used those exact words in email messages to some of our equipment vendors)
>there are lots of software routers (c.f. 72xx series), and there are all kinds of versions of 65xx code which handle v4 forwarding in a more efficient way than v6 forwarding
That's true...like I said, there's lots of legacy stuff out there that doesn't handle ipv6 as well as it should, by and large, it doesn't prevent ipv6 deployment, it just may not do it as well and as efficiently as it should. Then there's stuff that just flat out doesn't support it at all, and that has to be addressed as well. Again, though, ipv4 addresses are going to run out, now is the time to get fixes for this stuff, not when your back is against the wall.
(I don't think I need to respond to your message point by point since my responses will basically be more of the same. Now is the time to start deploying to find out what challenges you're going to face to give yourself time to address those challenges, it will only be that much harder when you're trying to do it when your back is against the wall).
>Besides, not all 128 bits of the address are going to be random. If i recall correctly, half is network and half is host. That would make scanning a network on par with scanning a class B network.
Uhm, no.
Because the host portion of the addresses (presuming you're using stateless autoconfiguration) is 64 bits long, the better analogy would be that it like scanning the whole Internet IPv4 address space...more than 4 billion times over.
Here's a hint. When you fill out your justification forms. Include all your RFC1918 IP addresses (ie, 10.x.x.x, 172.16.x.x, 192.168.x.x, et al). Since there is no space reserved in IPv6 equivalent to RFC1918, meaning you generally need to allocate "global" IPv6 addresses for your internal systems as well, you can include your internal numbering space as part of the justification.
Otherwise, in North America, the criteria for getting IPv6 PI space is exactly the same as IPv4 PI space, and is based on your usage of IPv4 space...and since you can count the RFC1918 space in your justification, it actually ends up easier to get IPv6 space.
NAT (ie, the mangling of IP addresses) doesn't give you any security whatsoever. Putting your box in the DMZ isn't bypassing the NAT, its just setting up a different type of NAT.
The security that you get behind your NAT device is because the device necessarily has stateful packet inspection and filtering engine...because dynamic NAT doesn't work without it...its the stateful inspection and filtering that gives you the security, not the NAT/mangling of the IP addresses.
You could stick a stateful inspection and filtering device that denies inbound connections by default in your laptop travel bag and have exactly the same level of security, without breaking useful applications like NetMeeting (admittedly dated), and other useful applications that connect directly client to client.
> Nobody is IPV6-only, so there is no financial benefit to being an early adopter
There is no *short-term* financial benefit. There's a *huge* financial benefits for people and enterprises that are able to see beyond their own nose.
>(maybe we'd PI some old/8's)
What do you think ARIN and the RIR's have been doing for the past 5+ years?
At current run rates, we're going to run out of IPv4 address, completely, in 2010 or 2011. There won't be any old/8's left available to turn into PI space.
Wake up and smell the coffee, you need to start thinking about deploying IPv6 now, or experience extreme pain in 3-4 years when you find yourself up against a wall because you can't get IPv4 addresses, and/or can't get to services that are starting to deploy *only* on IPv6 because that's all they can get.
If they're a halfway clueful ISP, yes, you'll get more than one IPv6 address at your home. And, no, hopefully there will not be NAT in IPv6 world (someone will probably do it, but its stupid, "Just Say No to NAT"). NAT is evil crap, it breaks things for no real benefit (other than IP address conservation, which isn't needed in IPv6 world). NAT doesn't provide any security, stateful packet inspection and firewalling provides security (NAT provides the illusion of security because stateful inspection and firewalling is required for dynamic NAT to work). Mangling IP address only breaks things, it doesn't actually provide you any protection. If you don't believe me, set your NAT device "DMZ host" to your PC and watch your PC get pwned in a matter of minutes just as if it were not behind the NAT device. Mangling the IP addresses doesn't protect you from anything, it just breaks protocols that need to signal IP address endpoints such as VoIP, IM file transfers, and the like.
At the risk of feeding the troll, I wanted to try to clear up some misconceptions.
1. Cisco routers suck at IPv6.
Anything reasonably current doesn't route IPv6 in software. Yes, there's legacy stuff out there that will have to be dealt with, but there are solutions to those legacy hardware deployments that aren't terribly arduous. But it does mean people need to get started dealing with this *NOW* rather than later.
2. There are too many addresses.
Uhm...so don't use them all. I'm not sure what sort of objection this is. "Oh, we can't do that because that solution will give us more resources than we need." Oh the horrors of not having to worry about running out of addresses, I'm not sure I can deal with that problem
3. IPv6 addresses are too large.
The ISP that I used to work for advertises 7 or 8 routes into the IPv4 default-free zone. With a move to IPv6, they could easily, without breaking a sweat, move to only advertising a single route. So, an IPv6 route would have to consume more than 8 *times* the memory that an IPv4 address does for it to be a loss for the routes that said ISP would advertise. Many enterprises advertise many many more routes than that in IPv4 and could drop down to a single (or very few) IPv6 routes. Yes, the memory footprint of each individual route in routers would be bigger, but the number of them will be significantly smaller, meaning overall router memory consumption will drop.
4. The IPv6 header is too large.
Ooh, 3.4% (and that's worst case)...I'm not sure the world can handle those sorts of inefficiencies. Yes, IPv6's larger header will drop data throughput efficiencies ever so slightly. That's better than the 100% drop in efficiency you'll have when you can't get an IPv4 address at all.
Uhm...perhaps you're under a different RIR than I am, but my company has PI IPv6 space (North America), and working great (within the constraints that we're not fully deployed for IPv6 internally, yet, but that's in progress...we can ping6 from our border routers and such, so we've got the first building blocks in place and are moving forward with more).
Unfortunately, you're suffering from, apparently, the same lack of understanding that the FCC is.
There are two services in play, here.
The first is DSL or cable modem service, which are clearly telecommunications services. These are the actual DSL or cable modem signalling over the wire.
Then there's the Internet Access overtop of the DSL or cable modem service. This is correctly classified by the FCC as an information service. Their problem (and apparently yours as well) is that they/you don't realize that DSL and cable modem service isn't *inherently* Internet service. DSL has, quite successfully, been used for non-Internet services, and cable modems could easily be used in the same ways. The FCC's stance on DSL and cable modem service, however, has made most of these uses uneconomical. A more reasonable stance, that takes into consideration of the layered nature of networking technologies, would much more realistically align the regulatory environment with the real world...both technically, and wrt competitiveness. (Internet service is competitive, DSL transport service is notsomuch).
Only in the implementations that you have specifically mentioned. The general idea is not technically stupid.
The idea being, make "cell phones" just do data transfer...likely even IP specifically. And then voice calls are carried as VoIP calls over that data connection.
There are already moves in some areas in this direction in technology. The local jurisdiction of police in my area is rolling out a new radio system do to the city/county merger and the merging of the police required a new radio system. The radio system is technically a pure data system. Voice "radio" communications on this system are carried as H.323 calls over the data connection that the radios provide. There are all kinds of benefits for this, which will be left as an exercise for the reader...but there's no good reason that commercial wireless providers couldn't move in the same direction...the technologies are basically the same, just the commercial providers would have to scale it up much larger than a police force would.
FWIW, plenty of other people are pointing out other states that have this type of law (I think I saw, Indiana, and Georgia, at least, mentioned).
Kentucky does as well. http://www.kycall0.com
I heard a stat a month or so ago (aigh...wish I could remember the attribution for it), that fully 1/3 of the state's households had signed up for the nocall list (Kentucky does it on a per-household, actually, per-phone number, basis). This was right *after* the nocall list took effect in Kentucky. I can only assume that the number of households/phone lines has increased since then.
I think the original comment was more about how long this has been going on, and that many of this would have thought this activity (by Verisign and others) would be common knowledge at this point.
At least, that's what *I* thought when I read the story. (and saw the posting on nanog).
The trick is that so many of the so-called experts mis-understood the nature of the worm.
Once the worm went dormant, it stays dormant. So all of the worm infections that were out there as of July 19th were not a threat.
What is is a threat is the possibility of the worm beginning to spread again, which is exactly what is happening. Within the past few hours, attempts have increased...to recently for the media to have picked up on it yet, but it is happening, the growth rate is exponential, just like July 19th, and it will get to be a significant problem within a matter of hours.
So Cringley was somewhat right...while the systems with their clocks set wrong aren't inherently any greater of a danger than any other...they did allow the worm to go back into spread mode and become widespread again.
This is basically the same bill that Tauzin introduced last year as H.R. 2420, but the bill number this year 1542. This is *important* as people calling to urge their congresspersons to kill this bill will need to get the number correctly.
1) standards != monopolies
2) The monopoly of Ma Bell was broken up...into a bunch of other monopolies with limited geographic scope, the monopoly situation still existed, and as you pointed out, local service cost shot through the roof. In long distance, which was opened to effective competition, you've seen a decrease in cost, as you pointed out.
You just proved that monopolies *do* cause problems, and that open monopoly scenarios to competition *does* lower cost and improve service.
Jeff
Head Network Administrator - IgLou Internet Services, Inc.
>I dont think there is anything we can really do though. Anyone have any ideas?
Write your congressperson!
I cannot stress this enough! Do it quickly, too, Tauzin is pushing this bill through quickly in an effort to get it through before rightful opposition can build up.
Better yes, call your congressperson, particularly in the house as that is where this bill currently is. Call your senators as well, just to be sure.
Let me reiterate what others have said about the effect of this bill (sorry I don't have a link to the actual text handy...easy to find at www.house.gov).
- This bill will eliminate the requirement that ILECs sell unbundled network elements (UNEs) to CLEC, which basically puts CLECs out of business.
- This bill will eliminate the requirement that ILECs sell wholesale access to ISPs to access their broadband networks, which basically puts independent ISPs out of business.
- This bill will eliminate state, and much of the federal, regulatory powers over ILECs broadband services.
Take these three effects together and what do you get? A single, ISP is all that is available to you for DSL, and no way to keep the rates in check, meaning that before long, DSL prices will skyrocket.
Jeff
Head Network Administrator - IgLou Internet Services, Inc.
>Story about a wireless ISP being investigated by the FCC.
Oh, man...this couldn't happen to a better person.
I went to middle school with Jeff Wellemeyer (the article mis-spelled his name I believe), and he is *SUCH* a twit. He was a twit in middle school, and in past dealings with my company he has been a twit, and even criminal.
Of course, it probably doesn't help that Darwin is in Chapter 11 right now.:)
Uhm...you do realize, of course, that they are being demanded to do this because they signed contracts saying that they would reduce their power consumption in emergencies in order to get cheaper prices on their electric bills.
In other words...the power companies didn't just decide on their own to go and demand that these companies reduce their power usage...these companies opened themselves up to this possibility by signing these contracts.
Slashdot Mirror
Actually, some of the comments are that there is at least a perception that ice damage has increased since the return to flight after Columbia.
The thought is that since they've added an extra hour into the countdown after the external tank is fueled that there is a longer time for ice to build up, and then a great tendency for it to break off and smack the orbiter.
Oh, and for another tidbit. Ice, since its denser, and heavier than the insulating foam, is a bigger problem than the foam is when it breaks off. It takes a smaller chunk of ice to break off and smack the orbiter to cause an equivalent amount of damager to a larger chunk of foam.
Ah, ok, so you wouldn't qualify, at present, for IPv4 PI space either, you've just got it through a legacy setup.
Yes, that is annoying for someone in a position such as yourself. Fortunately or unfortunately, depending on your viewpoint, there aren't going to be all that many people in a situation such as that (in the overall scheme of things).
Wish I had better answers for you.
Sure, its secure, but its not secure because of the IP address mangling. Its secure because the NAT device is looking at every packet, keeping track of what conversations are going on and deciding which to forward (and mangle) based on the state that its keeping.
The problem with your argument is that you qualify it with "not in the DMZ". Putting it "in the DMZ" (which isn't a real DMZ anyway) is still NAT, and your protection just went *poof*. NAT (ie, just mangling IP addresses) doesn't provide any protection. Having stateful inspection of every packet and deciding which ones to forward on is what provides protection. This means that a stateful inspection firewall is capable of providing exactly, completely, 100% the same level of security; oh, and do so without breaking any protocol that tries to use the Internet as a real communications network rather than some simplistic I-make-a-request-and-get-a-response-back pseudo-communications network.
http://www.apnic.net/archive/news/hot-topics/index .html#ip-addressing
Do try to keep up. That page was posted sometime in 2003. We've got 4 more years of data and growth to look at now, and the current projections (including by one of the leading experts who had a message that was also quoted on that page) is that ARIN will be allocating the last of its blocks in March of 2010, with the RIR's allocating the last of the blocks from their level in approximately 6 to 36 months. So, best case, you will not be able to go back to the well to get more IPv4 addresses in March of 2013.
I'm not sure what it would take for you to call it a shortage, but this certainly qualifies in my book.
You're right...there was a fair amount of hand-waving in my message (hey, its a slashdot comment, of *course* is over-simplified ;), and there are serious challenges to ipv6 deployment, I totally agree, but let's go back to the start of all of this controversy. We're going to be out of ipv4 addresses is roughly 3 years. *NOW* is the time to start working on these issues. We're starting to deploy ipv6 in our network where I work, despite *knowing* for certain that some of our equipment doesn't support it. But we're beating up on those vendors, and getting to say things like, "We've got ipv6 deployed in our whole internal network except where your equipment gets in the way. You're behind the curve, get with it." (literally, I've used those exact words in email messages to some of our equipment vendors)
>there are lots of software routers (c.f. 72xx series), and there are all kinds of versions of 65xx code which handle v4 forwarding in a more efficient way than v6 forwarding
That's true...like I said, there's lots of legacy stuff out there that doesn't handle ipv6 as well as it should, by and large, it doesn't prevent ipv6 deployment, it just may not do it as well and as efficiently as it should. Then there's stuff that just flat out doesn't support it at all, and that has to be addressed as well. Again, though, ipv4 addresses are going to run out, now is the time to get fixes for this stuff, not when your back is against the wall.
(I don't think I need to respond to your message point by point since my responses will basically be more of the same. Now is the time to start deploying to find out what challenges you're going to face to give yourself time to address those challenges, it will only be that much harder when you're trying to do it when your back is against the wall).
>Besides, not all 128 bits of the address are going to be random. If i recall correctly, half is network and half is host. That would make scanning a network on par with scanning a class B network.
Uhm, no.
Because the host portion of the addresses (presuming you're using stateless autoconfiguration) is 64 bits long, the better analogy would be that it like scanning the whole Internet IPv4 address space...more than 4 billion times over.
Here's a hint. When you fill out your justification forms. Include all your RFC1918 IP addresses (ie, 10.x.x.x, 172.16.x.x, 192.168.x.x, et al). Since there is no space reserved in IPv6 equivalent to RFC1918, meaning you generally need to allocate "global" IPv6 addresses for your internal systems as well, you can include your internal numbering space as part of the justification.
Otherwise, in North America, the criteria for getting IPv6 PI space is exactly the same as IPv4 PI space, and is based on your usage of IPv4 space...and since you can count the RFC1918 space in your justification, it actually ends up easier to get IPv6 space.
I'm being completely serious.
NAT (ie, the mangling of IP addresses) doesn't give you any security whatsoever. Putting your box in the DMZ isn't bypassing the NAT, its just setting up a different type of NAT.
The security that you get behind your NAT device is because the device necessarily has stateful packet inspection and filtering engine...because dynamic NAT doesn't work without it...its the stateful inspection and filtering that gives you the security, not the NAT/mangling of the IP addresses.
You could stick a stateful inspection and filtering device that denies inbound connections by default in your laptop travel bag and have exactly the same level of security, without breaking useful applications like NetMeeting (admittedly dated), and other useful applications that connect directly client to client.
> Nobody is IPV6-only, so there is no financial benefit to being an early adopter
/8's)
/8's left available to turn into PI space.
There is no *short-term* financial benefit. There's a *huge* financial benefits for people and enterprises that are able to see beyond their own nose.
>(maybe we'd PI some old
What do you think ARIN and the RIR's have been doing for the past 5+ years?
At current run rates, we're going to run out of IPv4 address, completely, in 2010 or 2011. There won't be any old
Wake up and smell the coffee, you need to start thinking about deploying IPv6 now, or experience extreme pain in 3-4 years when you find yourself up against a wall because you can't get IPv4 addresses, and/or can't get to services that are starting to deploy *only* on IPv6 because that's all they can get.
If they're a halfway clueful ISP, yes, you'll get more than one IPv6 address at your home. And, no, hopefully there will not be NAT in IPv6 world (someone will probably do it, but its stupid, "Just Say No to NAT"). NAT is evil crap, it breaks things for no real benefit (other than IP address conservation, which isn't needed in IPv6 world). NAT doesn't provide any security, stateful packet inspection and firewalling provides security (NAT provides the illusion of security because stateful inspection and firewalling is required for dynamic NAT to work). Mangling IP address only breaks things, it doesn't actually provide you any protection. If you don't believe me, set your NAT device "DMZ host" to your PC and watch your PC get pwned in a matter of minutes just as if it were not behind the NAT device. Mangling the IP addresses doesn't protect you from anything, it just breaks protocols that need to signal IP address endpoints such as VoIP, IM file transfers, and the like.
NAT is evil, it needs to die.
At the risk of feeding the troll, I wanted to try to clear up some misconceptions.
1. Cisco routers suck at IPv6.
Anything reasonably current doesn't route IPv6 in software. Yes, there's legacy stuff out there that will have to be dealt with, but there are solutions to those legacy hardware deployments that aren't terribly arduous. But it does mean people need to get started dealing with this *NOW* rather than later.
2. There are too many addresses.
Uhm...so don't use them all. I'm not sure what sort of objection this is. "Oh, we can't do that because that solution will give us more resources than we need." Oh the horrors of not having to worry about running out of addresses, I'm not sure I can deal with that problem
3. IPv6 addresses are too large.
The ISP that I used to work for advertises 7 or 8 routes into the IPv4 default-free zone. With a move to IPv6, they could easily, without breaking a sweat, move to only advertising a single route. So, an IPv6 route would have to consume more than 8 *times* the memory that an IPv4 address does for it to be a loss for the routes that said ISP would advertise. Many enterprises advertise many many more routes than that in IPv4 and could drop down to a single (or very few) IPv6 routes. Yes, the memory footprint of each individual route in routers would be bigger, but the number of them will be significantly smaller, meaning overall router memory consumption will drop.
4. The IPv6 header is too large.
Ooh, 3.4% (and that's worst case)...I'm not sure the world can handle those sorts of inefficiencies. Yes, IPv6's larger header will drop data throughput efficiencies ever so slightly. That's better than the 100% drop in efficiency you'll have when you can't get an IPv4 address at all.
Uhm...perhaps you're under a different RIR than I am, but my company has PI IPv6 space (North America), and working great (within the constraints that we're not fully deployed for IPv6 internally, yet, but that's in progress...we can ping6 from our border routers and such, so we've got the first building blocks in place and are moving forward with more).
Unfortunately, you're suffering from, apparently, the same lack of understanding that the FCC is.
There are two services in play, here.
The first is DSL or cable modem service, which are clearly telecommunications services. These are the actual DSL or cable modem signalling over the wire.
Then there's the Internet Access overtop of the DSL or cable modem service. This is correctly classified by the FCC as an information service. Their problem (and apparently yours as well) is that they/you don't realize that DSL and cable modem service isn't *inherently* Internet service. DSL has, quite successfully, been used for non-Internet services, and cable modems could easily be used in the same ways. The FCC's stance on DSL and cable modem service, however, has made most of these uses uneconomical. A more reasonable stance, that takes into consideration of the layered nature of networking technologies, would much more realistically align the regulatory environment with the real world...both technically, and wrt competitiveness. (Internet service is competitive, DSL transport service is notsomuch).
Jeff
>VoIP over 3G Technically stupid, but likely.
Only in the implementations that you have specifically mentioned. The general idea is not technically stupid.
The idea being, make "cell phones" just do data transfer...likely even IP specifically. And then voice calls are carried as VoIP calls over that data connection.
There are already moves in some areas in this direction in technology. The local jurisdiction of police in my area is rolling out a new radio system do to the city/county merger and the merging of the police required a new radio system. The radio system is technically a pure data system. Voice "radio" communications on this system are carried as H.323 calls over the data connection that the radios provide. There are all kinds of benefits for this, which will be left as an exercise for the reader...but there's no good reason that commercial wireless providers couldn't move in the same direction...the technologies are basically the same, just the commercial providers would have to scale it up much larger than a police force would.
Jeff
FWIW, plenty of other people are pointing out other states that have this type of law (I think I saw, Indiana, and Georgia, at least, mentioned).
Kentucky does as well. http://www.kycall0.com
I heard a stat a month or so ago (aigh...wish I could remember the attribution for it), that fully 1/3 of the state's households had signed up for the nocall list (Kentucky does it on a per-household, actually, per-phone number, basis). This was right *after* the nocall list took effect in Kentucky. I can only assume that the number of households/phone lines has increased since then.
I think the original comment was more about how long this has been going on, and that many of this would have thought this activity (by Verisign and others) would be common knowledge at this point.
At least, that's what *I* thought when I read the story. (and saw the posting on nanog).
*shrug*
Jeff
>If you can use a tunnel server, like IPSEC or PPTP or SSH
or L2TP
Jeff
>My problem is that SMTP has no authentication that I can find that would allow me to let him use our SMTP server from wherever he was,
SMTP Auth is exactly what you're asking for...most MTA and MUA's support it at this point.
Jeff
Not true...it is not difficult for an ISP to set up the use of things like MAPS RBL on a user by user basis.
Jeff
The trick is that so many of the so-called experts mis-understood the nature of the worm.
Once the worm went dormant, it stays dormant. So all of the worm infections that were out there as of July 19th were not a threat.
What is is a threat is the possibility of the worm beginning to spread again, which is exactly what is happening. Within the past few hours, attempts have increased...to recently for the media to have picked up on it yet, but it is happening, the growth rate is exponential, just like July 19th, and it will get to be a significant problem within a matter of hours.
So Cringley was somewhat right...while the systems with their clocks set wrong aren't inherently any greater of a danger than any other...they did allow the worm to go back into spread mode and become widespread again.
Jeff
Tauzin's bill is H.R. 1542, *not* 2420.
This is basically the same bill that Tauzin introduced last year as H.R. 2420, but the bill number this year 1542. This is *important* as people calling to urge their congresspersons to kill this bill will need to get the number correctly.
Please correct this in the summary.
Thanks!
Jeff
1) standards != monopolies
2) The monopoly of Ma Bell was broken up...into a bunch of other monopolies with limited geographic scope, the monopoly situation still existed, and as you pointed out, local service cost shot through the roof. In long distance, which was opened to effective competition, you've seen a decrease in cost, as you pointed out.
You just proved that monopolies *do* cause problems, and that open monopoly scenarios to competition *does* lower cost and improve service.
Jeff
Head Network Administrator - IgLou Internet Services, Inc.
>I dont think there is anything we can really do though. Anyone have any ideas?
Write your congressperson!
I cannot stress this enough! Do it quickly, too, Tauzin is pushing this bill through quickly in an effort to get it through before rightful opposition can build up.
Better yes, call your congressperson, particularly in the house as that is where this bill currently is. Call your senators as well, just to be sure.
Let me reiterate what others have said about the effect of this bill (sorry I don't have a link to the actual text handy...easy to find at www.house.gov).
- This bill will eliminate the requirement that ILECs sell unbundled network elements (UNEs) to CLEC, which basically puts CLECs out of business.
- This bill will eliminate the requirement that ILECs sell wholesale access to ISPs to access their broadband networks, which basically puts independent ISPs out of business.
- This bill will eliminate state, and much of the federal, regulatory powers over ILECs broadband services.
Take these three effects together and what do you get? A single, ISP is all that is available to you for DSL, and no way to keep the rates in check, meaning that before long, DSL prices will skyrocket.
Jeff
Head Network Administrator - IgLou Internet Services, Inc.
>Story about a wireless ISP being investigated by the FCC.
:)
Oh, man...this couldn't happen to a better person.
I went to middle school with Jeff Wellemeyer (the article mis-spelled his name I believe), and he is *SUCH* a twit. He was a twit in middle school, and in past dealings with my company he has been a twit, and even criminal.
Of course, it probably doesn't help that Darwin is in Chapter 11 right now.
Jeff
Uhm...you do realize, of course, that they are being demanded to do this because they signed contracts saying that they would reduce their power consumption in emergencies in order to get cheaper prices on their electric bills.
In other words...the power companies didn't just decide on their own to go and demand that these companies reduce their power usage...these companies opened themselves up to this possibility by signing these contracts.
Jeff