> > *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.
> >
> Nope. It's a matter of 100's of people who want 100's of authentication
> policies supported. It's not because I don't need it. It's because you
> still don't seem to want to recognize that this isn't _ONE_ problem. It's
> many different problems and solving it as one problem is a very substantial
> engineering effort. There are at least a hundred things I would rather
> see Livingston's engineering effort concentrate on rather than this quagmire
> of different needs for "A" solution that isn't really A solution, but actually
> is 100's of solutinos. Some want to bump the oldest session. Some want
> to fail to authenticate the new. Some want numeric limits. Some want
> this to work under UNIX. Some want NT. The list of problems goes on and on.
This is your opinion of the situation. I think most of the people
complaining would be happy with numeric limits, at least that is the
impression I get.
The fact that you can think of 100 different things Livingston should be
directing their resource towards is the whole point. You have your
priorities, other people have theirs, and because their priorities differ
does not make them *wrong*, just in the minority, and thems the breaks,
which is fine.
>
> > > > 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.
> >
> We shouldn't. However, it's _EASIER_ to implement this as a local site-
> specific solution. If you want to make it _EASY_ do it that way. Otherwise,
> accept that it's hard and bill.
Easier for whom? Certainly not for me. It has taken me over a week straight
*with* consulting from William Bulley(one of the Merit engineers) to get
Merit up on my system. Multiple logins were not the only reason for the
switch, but hey, it would have been a lot easier to have had this support
in Livingstons code, and not to have had to make the switch.
> > > > 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.
> >
> Lessee... If the vendor codes the solution, they need to code a solution
> that provides for 100's if not 1000's of possible different authentication
> policies at each of these little ISP's, few of which are actually going
> to be sufficiently satisfied with any generic solution that comes out,
> most of which are going to end up modifying the solution that Livingston
Again, your view of the situation, not mine. Who said anything about a
100 different authentication policies, besides you?
> provides as such anyway. Thank god you aren't teaching a class on how
> to run an ISP.
Gee I dunno, "Try to get base code to do what you want," vs. "hack your
own, which your vendor is not going to support" seems to be a better
method of running an ISP.
> > 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.
> >
> HA! This is a complicated enough issue that there's no easy way to explain
> all the tradeoffs in the different solutions that would have to be
> implemented. Sorry, but the way Livingston made their boxes easy to
> configure was by making them do a few things very well. RADIUS is not
> easy to configure. It's easy to clone RADIUS entries and modify them
> using a text editor if you know what you're doing. But Livingston has
> not done anything to make RADIUS easy to "configure". Why do you think
> this extension would be any different?
RADIUS is *hard* to configure!? For whom?
> > > 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.
> >
> And I have never disagreed with that. I have said that it should not get
> a higher priority than it has. I have never called anyone a luser.
> I suspect that your retort suffers from the same problem that my above
> statements do. Read enough mail messages about the same topic and you
> soon forget exactly who said exactly what.
And if you would do the same, you would realize that I never accused you
of calling people lusers.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Patrick Greenwell (510) 943-5769 voice
Systems Administrator (510) 210-2000 modem
Value Net, Inc. (510) 943-1708 fax
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/