Well, the priority seems to have been stated quite clearly
> 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.
Correct, so this would involve pulling someone from somewhere, or hiring
additional people. Both of these cost money.
> Because they can be an important part of the way a business functions.
>
> 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.
Yes, but YOU decided what local policies that you wanted. Livingston
never promised you the ability to prevent multiple logins. I'm saying
that if its important enough to pitch a fit over, it should be important
enough for YOU go find your your own solution. Right? If you aren't
willing to try to implement your own solution right now, it must not be
that big of a problem. After all, you bought the Portmaster knowing that
this feature wasn't supported. What were you thinking? Either you didn't
see multiple logins as a problem, or you planned on writing your own code
or whatever.
Do you see what I'm getting at? I've no doubt that Livingston will, in
time, add this feature to their version of radiusd, but bitching at them
to get it done yesterday is silly.
> 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.
Correct. We both found solutions to a common problem. As this problem is
common to a large percentage of their userbase, its unlikely that they
will ignore these requests. Gryphon stated what reality was on this
issue, and that is what everyone is going to have to deal with.
> > No, they can code up something themselves if its so damned important to
> > them. This is my point.
> Which costs money.
Oh! So you agree that some things cost money? Do you think it costs
Livingston something to add these features to radiusd, document them,
train support to field calls for the new features and maintain the code?
Livingston appears to have priorities regarding what is to be done today,
tomorrow, and a year from now. I'm assuming that they, like other
companies, have limited resources with which to accomplish these goals.
Again, if it is SO important to you that you have the ability to limit
multiple logins, then you can at least come up with a kludge that will
hold you over until Livingston gets around to implementing it for you.
> That is another matter altogether. Livingstons support should be such
> that they can support their customer base. Period.
Yes, and I've seen that they don't commit themselves to supporting a
feature until they are good and ready. This is a good thing as we don't
need to waste time dealing with Support Which Has No Clue(tm)
> Again, you are assuming that the same group is working on all the
> different issues.
No, I'm assuming that nobody is sitting on their duff. Everybody is
already working on stuff. You can't just say "These guys aren't working
on OSPF, so we can use them somewhere else."
Have a good one. (My, this has been an interesting diversion today.)
| Matthew N. Dodd | winter@jurai.net | http://www.jurai.net/~winter |
| Technical Manager | mdodd@intersurf.net | http://www.intersurf.net |
| InterSurf Online | "Welcome to the net Sir, would you like a handbasket?"|