Re: Why is Tek still keeping logs???

TSI is handling this near-perfectly. I too wish they kept no logs but I acknowledge there are probably business, legal and technical support issues that make IP logging necessary, or at least prudent. Maybe TSI can move to shorter retention periods, maybe they can't. But they've been completely up-front about what they do, so now it's up to me to decide what to do about it.

Here we go again. As I explained above, there are NO *valid* business / technical or legal reasons to keep logs. Please don't repeat this without arguments to support your point of view.

Tek was up-front, well, sort of. As soon as you ask them a question remotely related to legal they suddenly become mute. This topic is sufficient proof.

Seriously???Name 1 Canadian Law that demands mandatory logging.Name 1 Tech Issue that cannot be logged after the fact to solve the issue (i.e. if the issue is gone, why log? / if the issue is still there, the logs will catch it).

Demand all you want. I think you owe TSI an apology for being bombastic and ludicrous, but I'm not egomaniacal enough to "demand" one.

Oh really? Last time I checked being bombastic and ludicrous was not a crime. Committing something illegal was. Slandering somebody by openly saying that they are committing illegal acts is... well... slandering.

Slander:1. defamation; calumny: rumors full of slander.2. a malicious, false, and defamatory statement or report: a slander against his good name.3. Law. defamation by oral utterance rather than by writing, pictures, etc.

And how about we let TSI decide what's good for their business instead of random people who are tough legal experts from behind their keyboard?

Well, because I am a customer. Tek's business model is to fulfill customer's satisfaction. This means to listen to customer's needs and provide them. Actually, Tek owes me a thank you for starting this thread and saving them thousands in customer's surveys and polls.

I'll agree that the matter of law isn't opinion, but neither of us are lawyers with full knowledge of the relevant areas of practice.

Sure, tech issues can be logged after they're noticed. But there is always a business case to be made for being proactive instead of reactive. A good enough business case to outweigh the downsides/costs/etc? That's the golden question.

It is your opinion that when it comes to logging, the risks outweigh the benefits of being proactive. A customer getting one of these emails will probably agree with you. But the customer calling in and being told that they need to suffer through some intermittent issue for a few more days so there are logs that support can go over might disagree with your opinion.

Sure, tech issues can be logged after they're noticed. But there is always a business case to be made for being proactive instead of reactive. A good enough business case to outweigh the downsides/costs/etc? That's the golden question.

It is your opinion that when it comes to logging, the risks outweigh the benefits of being proactive. A customer getting one of these emails will probably agree with you. But the customer calling in and being told that they need to suffer through some intermittent issue for a few more days so there are logs that support can go over might disagree with your opinion.

So yes - seriously.

No, not seriously.Then, how did the Swedish ISPs do it?I didn't see an uproar in swedish customers when they stopped logging. On the contrary, I saw a healthy support from them to the ISPs that had the vision to and the ba**s to stop this practice. Besides, where does it stop?How many fishing expeditions from shark lawyers do we have to endure before a meaningful law/regulation is enacted? Why suffer through all that if ISPs can fix it overnight.As to a customer not getting its issue fixed overnight, don't get me laughing!!! Did you actually worked for IT??? I can pretty much guarantee that NOTHING gets solved overnight. Furthermore, it is much more time efficient to turn logging on for a specific customer when a complaint is received than to spend countless hours wading through logs. Real-time or near-real-time is the way to go.

I can pretty much guarantee that NOTHING gets solved overnight. Furthermore, it is much more time efficient to turn logging on for a specific customer when a complaint is received than to spend countless hours wading through logs. Real-time or near-real-time is the way to go.

Again, never said anything about an issue being solved right away, or overnight, because of the existence of logging.

Differently. That they have been successful with such methods just means that it's a valid method, it doesn't mean it's the only method. And if it's better or worse is a matter of opinion.

Well, I worked with both methods and I can tell you from experience that what you want is a near instantaneous alarm when things go wrong (or appear to go wrong) than find out a few days after the fact when the damage is done and have to wad through a few Gigs worth of logs. Yes, heuristic, near-real-time software is better. It is adaptable and/or rule-based. It can look for new forms of abuse or detect subtleties. You can see, in real-time what's going on. Those are all things that logs can't do. Yes. it is a superior method.

I can pretty much guarantee that NOTHING gets solved overnight. Furthermore, it is much more time efficient to turn logging on for a specific customer when a complaint is received than to spend countless hours wading through logs. Real-time or near-real-time is the way to go.

Again, never said anything about an issue being solved right away, or overnight, because of the existence of logging.

No, but you implied that by having logs things would get solved faster. On average, they do not.

Differently. That they have been successful with such methods just means that it's a valid method, it doesn't mean it's the only method. And if it's better or worse is a matter of opinion.

Well, I worked with both methods and I can tell you from experience that what you want is a near instantaneous alarm when things go wrong (or appear to go wrong) than find out a few days after the fact when the damage is done and have to wad through a few Gigs worth of logs.

Oh, I agree on that. But I've seen many situations where you need to wade through logs to find out what the cause of the problem is. You can do that a lot sooner if the logs already exist.

Real-time is better for spotting problems. Logs are better for spotting causes.

Yes, heuristic, near-real-time software is better. It is adaptable and/or rule-based. It can look for new forms of abuse or detect subtleties. You can see, in real-time what's going on. Those are all things that logs can't do. Yes. it is a superior method.

And real-time can't give you a history to back-track through when necessary. The superior method for troubleshooting (so not getting into cost analysis, legal issues, etc, which bring further pros and cons to each method) is a combination of both real-time and logging.

Re: Why is Tek still keeping logs???

Gabe, if you can ignore the lunacy and help us have a calm discussion about this, I can assure you that most of us appreciate it. To your knowledge, is the 90 day logging window here to stay? Is there any momentum towards shortening (or lengthening) the window?

Oh, I agree on that. But I've seen many situations where you need to wade through logs to find out what the cause of the problem is. You can do that a lot sooner if the logs already exist.

Real-time is better for spotting problems. Logs are better for spotting causes.

Yes, but with a properly configured real-time software, it starts logging when the issue is first detected. And, it intelligently logs only relevant packets. For any intent and purposes, you are loosing almost no important information to determine causality.

And real-time can't give you a history to back-track through when necessary. The superior method for troubleshooting (so not getting into cost analysis, legal issues, etc, which bring further pros and cons to each method) is a combination of both real-time and logging.

Not in my experience. Widespread logs area always a headache. They do suffer as you said, from, cost analysis, troubleshooting, legal, storage, backup and a myriad of other issues.

When I am looking at a log, I want the min info that will be useful, and just the timeframe that is useful. Everything else is just a pain in the neck and not worth my time.

Real-time is the way to go. That's how most *modern* data-centers do it.

Gabe, if you can ignore the lunacy and help us have a calm discussion about this, I can assure you that most of us appreciate it. To your knowledge, is the 90 day logging window here to stay? Is there any momentum towards shortening (or lengthening) the window?

Yes, but with a properly configured real-time software, it starts logging when the issue is first detected. And, it intelligently logs only relevant packets. For any intent and purposes, you are loosing almost no important information to determine causality.

Even properly configured, it can miss out on earlier stages that a human eye might spot (with the benefit of hindsight).

It's only as good as the person who programmed it, and only knows what that person thought of making it know.

And real-time can't give you a history to back-track through when necessary. The superior method for troubleshooting (so not getting into cost analysis, legal issues, etc, which bring further pros and cons to each method) is a combination of both real-time and logging.

Not in my experience. Widespread logs area always a headache. They do suffer as you said, from, cost analysis, troubleshooting, legal, storage, backup and a myriad of other issues.

Real-time also suffers from cost analysis, troubleshooting, etc. Not all of the issues are the same, but there are just as many of them.

Yes, but with a properly configured real-time software, it starts logging when the issue is first detected. And, it intelligently logs only relevant packets. For any intent and purposes, you are loosing almost no important information to determine causality.

Even properly configured, it can miss out on earlier stages that a human eye might spot (with the benefit of hindsight).

It's only as good as the person who programmed it, and only knows what that person thought of making it know.

Earlier stages are overrated. In real life there is very little difference if you catched the first 50 or so packets or not, considering that you got the other 10.000 or so. That's my experience.

And real-time can't give you a history to back-track through when necessary. The superior method for troubleshooting (so not getting into cost analysis, legal issues, etc, which bring further pros and cons to each method) is a combination of both real-time and logging.

Not in my experience. Widespread logs area always a headache. They do suffer as you said, from, cost analysis, troubleshooting, legal, storage, backup and a myriad of other issues.

Real-time also suffers from cost analysis, troubleshooting, etc. Not all of the issues are the same, but there are just as many of them.

Again, not in my experience, not to that degree. Sure, you still need human interaction to actually decode and give significance to what's happening, but with an intelligent system you get a head's up about possible causes instantaneously. Let's say that somebody is abusing port 25. You will know instantly by the packet analysis of the software that somebody is probably spamming. By log alone, well, it can take a while to figure out the pattern.

When I am looking at a log, I want the min info that will be useful, and just the timeframe that is useful. Everything else is just a pain in the neck and not worth my time.

Basic log viewing software can help with that. I'm not saying you should be popping the log open in notepad and going through it line by line...

Obviously, but even the fanciest log analyzers are just sophisticated filters. They are not good at pattern recognition. Heuristic software is. Heck! it can even detect patterns based on how normal packets are affected by abusing packets! It can do statistical analysis far beyond what a simple log analyzer can do.