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
Would you also unblock the file and print sharing ports on request?
It's never come up and we don't expect it to, so we don't have a formal policy on those ports. At our size, we can deal case-by-case. If someone had a legal use case, we'd make sure their needs were met; this may or may not involve unblocking the port(s). Using the port 25 blocking as an example... if someone says, "I can't send email from my Gmail address using Outlook.", we say, "Use port 587. Here's how...". This limits the number of exceptions and maintains as much of the security as is possible. However, if they say, "I use Linux and want a proper MTA setup.", we say "We'll unblock port 25. Please make sure to secure your mail server so it can't be use to send spam."
I work for a small, rural ISP. When we advertise X Mbps, a properly working (i.e. not virus laden or too old to get X Mbps on its own) computer will actually get X Mbps to our speed test. In other words, we overprovision the customer's service to account for not just access technology overhead (e.g. ATM for ADSL), but TCP/IP (+HTTP) overhead as well. Our speed test is from Ookla (a popular speed test vendor) and is not doctored in any way; we just can't guarantee speeds to random speed test servers on the Internet. Congestion within our network or on our upstream links would be considered a serious outage. However, if, for example in the case of DSL, your line is simply too long to get X Mbps, you won't; most customers in that position are grateful for whatever they can get. But if you felt we cheated you, canceled your service, and demanded a refund for that first month, you'd get it. (We only require contracts on one type of Internet service--terrestial, fixed location wireless--because of the cost of the equipment and the install, but we'd waive the contract term in such a case.)
Aside from enforcing the speed purchased, we don't shape, throttle, or do evil things to traffic on customer Internet connections, except by customer request. (We offer an *optional*, opt-in service that blocks porn sites using an HTTP proxy.) We don't prioritize or de-prioritize particular packets on customer Internet connections by source, destination, or anything else.
However, for security reasons, we block the Microsoft file and print sharing ports (which nobody should use directly over the Internet anyway) and outgoing port 25 (SMTP) traffic. The latter makes a huge difference in blocking spam from infected customer computers. If you ask for port 25 to be unblocked on your connection, we will unblock it.
Personally, I think this is exactly how ISPs should behave. Anything I should do differently? Is this an "Internet connection", or does the port blocking disqualify it?
Other random details: Our DNS servers verify DNSSEC, but accept expired signatures to avoid customer complaints every time an otherwise working domain forgets to rollover their keys. We unfortunately do not yet sign our own domains and don't yet support IPv6 everywhere, but are working on both. (We only finally got redundant IPv6 upstreams earlier this year after making significant changes to which networks we buy from because one upstream has ignored literally years of IPv6 requests from us.)