> > > > 1. You've got the source for radius, and can fix it yourself.
> > > Not supported by Livingston.(and I wouldn't expect them to, beyond basic
> > > functionality.)
> >
> > I can't expect them to support my local authentication policy. Its just
> > not going to work. I'm sorry, but I think that radius isn't really very
> > useful unless its modified to suit your own needs. I submit that while
> > it might be nice for Livingston to have a radiusd that does everything I
> > want, and their tech-support knows all about all the little features,
> > there are other things that I'd rather they spent their time and effort
> > on.
>
> 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.
> >
> > > > 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.
> 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.
> 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.
> > > > 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.
> > > And others would like *supported* additions to functionality. It could be
> > > fixed *once* and *properly* as Livingston says they will do, or everyone
> > > could continue to use what Gryphon, MZ(I forget which) say aren't the best
> > > solutions.
> >
> > Again, how do you expect Livingston to SUPPORT local authentication
> > policy? At this point, I don't think their support system is ready to
> > deal with LUSER-ISP that calls up and fusses because he can't figure out
> > the config file syntax for enabling GID based authentication restriction
> > or selective multiple login denial or whatever. (Not to imply that
> > Livingston Tech Support is inadequate, but they probably have enough to
> > deal with right now.)
>
> 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.
> > > Not at all. However I think that *supported functionality* is important to
> > > quite a few people.
> >
> > Yes, I'm sure it is, but there should be other irons in the fire...
>
> Again, you are assuming that the same group is working on all the
> different issues.
>
Not necessarily all of them, but I _KNOW_ (confirmed by Livingston) that
_ALL_ of their engineers are busy on higher priority projects.
Owen