>Hmmm... An interesting thought. Yet another problem created by dynamic
>addressing. (Never one of my favorite methods, as even without this
>problem, it seems to create more problems than it solves, but that's
>another topic) Anyway, those 10 friends need to make darn sure they
>don't dial into the same portmaster or they're going to create real
>service problems for each-other.
Huh? Uh...no....they aren't going to cause any problems for each
other...everything will work just hunky dory.
>Most ISP's there's no easy way to
>make sure of that, short of making sure your friends all call different
>POPs, which I suppose could happen, but isn't terribly likely.
>> Again, from the number of questions I've seen asked about this -- and
>> the huge popularity of this feature in Merit radius, I have to disagree.
>> I think that it is a significant issue in many applications, especially
>> an ISP situation.
>Relative to the number of concerns I've seen expressed about other problems,
>I have to say that it isn't as significant as those other issues. Again,
>we're talking about engineering resource allocation. Those resources right
>now are better spent on things like PRI, classless routing, and OSPF.
1) You're assuming that engineering resources are engineering
resources. When there are really many different engineering
resources...ie, someone that could code the multiple login thing maybe
wouldn't be much help at all coding on OSPF/CIDR or PRI issues.
2) I've heard probably as many mentions of the limiting of the login
thing as I have heard mentions of OSPF/CIDR and PRI. Just the requests
for the OSPF/CIDR and PRI have been considerably more strident requests.
For something like multiple logins...many people have been saying "Can
this be done?" and told "using Livingston RADIUS, no." and in response,
"oh darn, that would be nice to have....oh well, I guess I'll live
without it for a while." In other words, not being able to limit logins
isn't going to kill an ISP...not being able to do OSPF, or bring lines
in on PRI isn't likely to kill an ISP either, but its certainly gonna
make a bigger dent.
>> Agreed. It's a pain in the ass. :) Hence the solution I suggested in
>> my email.
>Yes and no. The solution you proposed, as you point out, doesn't scale.
>All of Livingston's products to date DO.
And thus his request for the login-limiting code in RADIUS rather than
trying to kludge something together (tho' from the sounds of it, its a
pretty good kludge) with pmwho and pmcom.
>> Yes, but the succses of Livingston's PM product line is intertwined
>> very closely with their own radius implimentation. Imagine, if you will:
>Not really.
WHAT?! What are you on? The PortMasters are practically worthless
without RADIUS, particulary for an ISP!
>> "And our portmasters allow you to do lots of neat stuff.. if you
>> compile someone else's unsupported code." :) I just can't see that working.
>The PortMasters do lots of neat stuff without RADIUS and about 50% of
>Livingstons customers don't use RADIUS.
No, the PortMasters do not do lots of neat stuff without RADIUS...they
do a *few* neat things without RADIUS, but most of their neat tricks
rely on RADIUS *extensively*. No, not everyone uses Livingston RADIUS
(we don't), but why is that? Because Livingston RADIUS doesn't do what
we need it to do. If Livingston RADIUS and Merit RADIUS both did what
we needed it to do, I would run Livingston in a heartbeat...why?
because then I could call Liv. and say...I'm having this problem and
when they ask me what RADIUS I'm running, not have to fight them to
convince them that the problem isn't with the RADIUS server.
>> Opinion. :) *shrugs* I would say that they're all in relatively high
>> demand by different segments of the market. Ahh well. It's really up to
>> Livingston to decide, and given that there are already ways to solve it
>> that don't require engineering investment on livingston's part, well..
>> *shrugs* But it would be nice to have an official Livingston solution to
>> it some year, simply to reduce the confusion.
>However, if you look at what comes across this list and the makeup of
>Livingston's customers, I'd say less than 10% consider the multiple
>login issue critical, less than 25% consider it important, and that
>something on the order of 80% consider classless routing and OSPF
>critical. Something on the order of 75% consider PRI important.
>If you were in charge of engineering and faced numbers like that,
>which project would you follow?
Are you sure that these projects are mutually exclusive? We've already
been told that the ChoiceNet was not a mutually exclusive project with
OSPF (ie, working on ChoiceNet didn't slow down the OSPF project at
all).
>Those numbers are based on the following sources:
> 1. My observations of this list.
Are you sure you're on the same list I'm on? I would not have come up
with those numbers...I would agree with you that most people on this
list consider OSPF/CIDR and PRI more important than login limiting, but
I don't think it would be as skewed as you say above.
> 3. My knowledge of the ISP industry (~95% of Livingston's
> market)
Which means that 95% of us have approximately the same level of
expertise in this area (maybe more?)
> 4. Discussions and observations with/of other ISPs and their
> netops people at various shows/conferences.
Which for the most part are generally gonna be quite non-commital as to
what really is important to them, and non-forthcoming about how thier
network is set up (I know we are...purposefully)
>True, I didn't use any scientific methods to arrive at those figures, but
>I'll bet they're fairly accurate.
And I've come up with noticeably different figures using the same
criteria.
>Can I presume since you ignored the remainder of my message that you're not
>using UNIX or that you're more concerned about PPP users?
Since most ISP's these days don't offer Shell accounts, I would imagine
that, yes, they either don't run UNIX, or its not important for them,
and yes, they are considerably more concerned about PPP users than they
are about non-existant shell users.
We do offer shell, and have the multiple logins limited at the server
level, but I agree with Dave and others that limiting multiple logons
for PPP would be very nice (personally I would want that more than I
would want OSPF/CIDR and PRI).
-- Jeff McAdams | A feature is a bug IgLou Internet Services | with seniority. e-mail: jeffm@iglou.com | -- unknown