> > > This isn't a general case. There are no 'clean' solutions to the multiple
> > > login problem. It will take time to come up with a good solution that
> > > works on all supported platforms.
> >
> > Yup, and there are people out there that want this to be higher up
> > on the priority pole.
> >
> Yup. However, they aren't the majority of Livingston's customers.
Who said they were? Certainly not me.
> > As it has been pointed out before, we are dealing with different
> > resources. The people that are working on OSPF are probably not the same
> > people that would be working on this issue. The engineers working on a
> > PRI solution are probably not the people that would be working on this issue.
> >
> It's been speculated before, but the reply from Livingston was:
> "We don't have ulimited engineering staff. Putting someone on this
> would require pulling them off of something else."
>
> Reality check here. The priority projects for the majority of the units
> deployed are classless routing, OSPF (mainly because it's required for
> the previous item), and PRI. That's what Livingston is concentrating their
> effort on.
And I think that is great. Those are the two things I can use right now.
> > > > > 2. There are 2 or 3 other radius implementations that will do what you're
> > > > > asking for.
> > > > Not supported by Livingston.(and I wouldn't expect them to, beyond basic
> > > > functionality.)
> > >
> > > Exactly, so why do we want them to support all of the various local
> > > authentication policies?
> >
> > Because they can be an important part of the way a business functions.
> >
> Huh? How is that a reason for Livingston to have to support each individual
> ISP's authentication policy? That's all the more reason for each ISP to
> roll their own local modification.
*SIGH* It has been said by many people that this would be a useful
function. This is not a matter of one, oddball that wants a weird or
unusual authentication policy supported. Again, because *you* don't need
it, or are using an alternate method, it doesn't invalidate the request
of other customers for a *supported* solution.
> > As our company offers unmetered accounts, I can say that it is would be
> > much easier to disallow multiple logins rather than attempt to actually
> > get people to pay for multiple usage. Good luck.
> >
> If you want easy, run a garbage company. You're an ISP. Nobody ever said
> it was going to be easy.
And why should we try to keep it hard? This is very poor reasoning.
> > You hacked your RADIUS to prevent multiples. We switched to Merit. But
> > none of this invalidates the request that Livingston offer support for
> > this function. It is a reasonable request, and given that the market is
> > moving more and more towards "unlimited" usage, it becomes more important
> > to the ISP market in general.
> >
> Noone ever said the request was invalid. We're just saying it's not the
> current top priority.
Who said anything about *top* priority?
> > > > > 3. Its probably in the works anyway.
> > > > Possible, but what do you expect everyone to do, sit in a room and just
> > > > hope for it?
> > >
> > > No, they can code up something themselves if its so damned important to
> > > them. This is my point.
> >
> > Which costs money.
> >
> So? If it costs you more to code it than it does to let people log in
> multiple times, ignore it. Otherwise, it pays for itself. Welcome to
> business.
Lessee, we can have the vendor code a solution, which they said they
will, or we can have tens if not hundreds of ISP's spending resources
individually on solutions. Thank god you aren't teaching a business class.
> > That is another matter altogether. Livingstons support should be such
> > that they can support their customer base. Period.
> >
> Yes. And how do you propose that they control that? One way is not to
> release support for complicated features that are difficult to implement
> in a flexible scaleable way with minimal benefit over what could be done
> as a local hack. There you have it. It is not a seperate matter. If
> Livingston releases it, they will have to support it. You said so youreslef
> in the previous paragraph. As such, the cost of supporting it has to be
> a factor in their decision to release it or not. Especially when you
> consider that you're asking them to give it to you at no cost. That means
> they take on this support nightmare for no revenue. Hmmm...Just how
> many additional TS units do you really think this feature will sell?
> As long as no other TS has this function, I'd bet none.
One of Livingston's biggest assets is that it creates easy to configure
devices. I would imagine that support this functionality would be no
different. Your theory about a support nightmare is just that: a dream.
> Not necessarily all of them, but I _KNOW_ (confirmed by Livingston) that
> _ALL_ of their engineers are busy on higher priority projects.
>
Even after posting to the contrary, you have the misconception that I feel
that this is the most important feature on earth. I don't. All I have
ever said is that the request is valid, should be implemented, and those
that are asking for it are not "lusers" by default.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (510) 943-5769 voice
Systems Administrator (510) 210-2000 modem
Value Net, Inc. (510) 943-1708 fax
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/