OSPF is great, and so is PRI, don't get me wrong, but there seems to be an established base
of customers here who are seemingly being left to fend for themselves because Livingston must
stay competitive in this market by offering NEW products and services. As the actual hack is
not all that hard, probibly would take someone at Livingston less than 2 days. Let's see, at normal
programmer salary of $35,000 to $45,000, I wouldn't think that this should be an issue. They seem
to have the idea of what they need to. (At least when I originally spoke with them, they sent me
an email as what to do, and the approximate place in the code to be changed) But by doing it
by ones self, we cannot upgrade easily.
Anyone needing this in RADIUS, stand up and Say "EYE"
Shawn Lewis
---------------------------------------------
Shawn Lewis slewis@thecia.net
Sr Systems Engineer 617.225.4100 x122
Complete Internet Access, Inc
We Give Good Web!!!!
---------------------------------------------
----------
From: Owen DeLong[SMTP:owen@delong.sj.ca.us]
Sent: Monday, June 24, 1996 6:54 PM
To: Dave Andersen
Cc: owen@delong.sj.ca.us; angio@aros.net; felipe@avatar.pty.com; portmaster-users@livingston.com
Subject: Re: NO multiple logins !! Livingston won't listen
> > Let's put this in a slightly broader perspective:
> >
> > 1. Livingston does not have an infinite budget.
> > 2. Quality Software Engineers are NOT in infinite supply.
> > 3. The percentage of portmasters deployed for shell access type
> > services is probably less than 10.
> > 4. This problem doesn't really apply to network access as it
> > does to shell access.
>
> Wrong-o. This applies more to network access for those of us who are
> assigning dynamic IP addresses. Think about it -- one customer could
> give out their password to 10 friends, and they could all be logged in
> simultaneously without some form of concurrent login control.
>
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. 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.
> > 5. One customer with four PortMasters is not overwhelming demand.
> > Sure, there are a few other people asking for this, but the
> > vast majority of Livingston's customers don't consider this
> > important.
>
> 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.
> > 6. The multiple login problem is not a problem which can be solved
> > on the PortMaster itself.
>
> 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.
> > 7. RADIUS is a NON-REVENUE product for Livingston. That's right,
> > it's FREEWARE!
>
> 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.
> "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.
> > 8. NO terminal server solves this problem (NO other terminal
> > server comes as close to solving this problem as Livingston).
>
> Agreed. Completely.
>
> > 9. If you're running UNIX, the place to solve this is by
> > creating a replacement for the distributed quota(1M)
>
> > 10. There are many other features which Livingston Engineering
> > is focused on which are much more important to a much
> > larger percentage of their customers.
>
> 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?
Those numbers are based on the following sources:
1. My observations of this list.
2. My conversations with people in engineering at Livingston
3. My knowledge of the ISP industry (~95% of Livingston's
market)
4. Discussions and observations with/of other ISPs and their
netops people at various shows/conferences.
True, I didn't use any scientific methods to arrive at those figures, but
I'll bet they're fairly accurate.
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?
Owen