A CA never has your private key. You generate it locally and it is never sent to them.
I disagree. Imagine I'm an evil ISP: If I was to throttle HTTP to a certain limit, I'm sure I could break Youtube (and other video sites) without breaking the rest of the Web. And if they switch to some non-HTTP protocol, I'll just throttle that protocol across the board. In all cases, I'm treating hosts equally.
Alternatively, if I prioritize some hypothetical Netflix-specific protocol, that will inhibit competitors from entering that market unless they can and do use the same protocol as Netflix, which might not be the best solution in a world without such prioritization.
At least with DR, the key is to exercise the plan as part of routine maintenance. That is, fail over to the backup (server/site/whatever), work on the primary, fail back. Since this provides immediate value, it'll actually get done. And since people do it regularly, they remember how to do it.
This is interesting. Do you have any examples?
My SMTP server will not accept an email claiming to be from my boss* (in either the envelope or a From: header) unless it was sent by him using SMTP AUTH.
* Or most of my users; this is our default, with an opt-out option.
If this was the case, most students would just default, right? And the debt collectors would go after the school because it's a fatter target.
How about employers pay employees cash and then the employees save 15-20% of their income for retirement?
There are well-understood mechanisms for handling this sort of inventory issue. You simply have two part numbers for each item. (There are pros and cons to the approach of the first revision using the same number for both.) The "marketing part number" doesn't change, as long as it's a drop-in replacement. But if any detail changes, then you issue a new "actual part number" (or whatever you want to call it). I had a bunch of IBM gear that had two IBM part numbers on everything. In telecom, CLEI codes can fulfill this role; I've seen gear where the CLEI code changed even though the vendor's marketing part number did not.
I'm pretty sure if you try to disrupt the telephone network, the phone company has every right to disconnect you or take other measures. I don't see how the ISP side should be any different. FWIW, I work for a small, rural, independent telephone company that also provides Internet.
They should have checked your ID since the card was unsigned. Also, Visa does more-or-less prohibit the checking of IDs; from the guidelines, "merchants cannot as part of their regular card acceptance procedures refuse to complete a purchase transaction because a cardholder refuses to provide ID": http://usa.visa.com/download/m...
From the OP, it's 2 years, not four. But that's pretty minor to the point.
If they fail to make the one-time investment "because $4,000 is a lot of money" then they will continue to pay that extra $2,000/year every year. It will only stop once the air conditioner dies and is replaced at that time.
I'm not sure why I should try reading again. You just made the same point in reply to me that I made.
Paying $4,000 extra every two years is also a lot of money for those same people.
I have a dumb phone. It does the same thing.
Cable companies...generally don't PAY for [local channels]. So they don't get to CHARGE for them since the originator of the programming gets nothing from them.
For what it's worth, this used to be the case, but is not any more. Many local channels have switched from "must-carry", where the cable company has to carry them, but doesn't have to pay, to "retransmission consent" where they can charge the cable company. http://en.wikipedia.org/wiki/Must-carry#United_States