Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror

Comment: Re:Part of me says yes, like DR (Score 1) 124

by RLaager (#48799381) Attached to: Do We Need Regular IT Security Fire Drills?

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.

Comment: Re:Dunno how to feel about this... (Score 1) 357

by RLaager (#46626573) Attached to: An Engineer's Eureka Moment With a GM Flaw

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.

Comment: Re:Not imposing common carrier status (Score 1) 235

by RLaager (#46290017) Attached to: FCC Planning Rule Changes To Restore US Net Neutrality

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.

Comment: Re:Good. We can stop relying on people who... (Score 1) 731

by RLaager (#46218669) Attached to: Death Hovers Politely For Americans' Swipe-and-Sign Credit Cards

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...

Comment: Re:What is their obligation to you? (Score 3, Interesting) 376

by RLaager (#41667335) Attached to: FCC To Allow Cable Companies To Encrypt Over-the-Air Channels

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

Comment: Re:File under "No shit Sherlock" (Score 1) 228

by RLaager (#40942145) Attached to: ISPs Throttling BitTorrent Traffic, Study Finds

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."

Comment: Re:File under "No shit Sherlock" (Score 2) 228

by RLaager (#40940743) Attached to: ISPs Throttling BitTorrent Traffic, Study Finds

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.)

A list is only as strong as its weakest link. -- Don Knuth

Working...