Easy is always good--from an end-user perspective--but not all ISPs understand this. Sometimes just getting to the local-number cache is difficult. Some clients are just too clunky--dialers that require a profile for every number displayed. Getting to the list of possible phone numbers should be straightforward. Look for an ISP that asks the user to provide an area code and then returns a list of cached local numbers to try. The easier a dialer is to use, the fewer helpdesk calls you'll get.

Help--When & Where You Need It

If the ISP provides a helpdesk, that's one less area your helpdesk needs to cover. Find out what kind of help is offered. Is it advertised as a 24/7/365 desk? What type of expertise and staffing is available on a Sunday night? After all, just like tackling that term paper at the last minute, you may find yourself creating a presentation the night before the big meeting--and grabbing stats from the database back at the plant when you're already checked in at the Ramada means dial-up. See if you can try some service calls before you buy.

Find out, too, if escalation is available. Is this part of the standard contract, or do you have to negotiate for it, and if so, what percentage of the ISP's customers have a similar contract? Being the only ISP customer with an escalation contract may sound good until you try to explain to the night maintenance man that you really do have such a service contract.

Keeping the Network Safe

How will Your dial-up users be authenticated? Ideally, the ISP should use RADIUS, TACACS or a live read of the authentication database to grant users access. The more out of date the ISP's database is, the less control you have over who is accessing your network. You can control local file and mail privileges, of course, but if you can't control access privileges through the ISP, you have a huge security hole.

A VPN (virtual private network) provides private access to the corporate network, but you must determine if your provider will run the VPN servers and back haul the traffic to your enterprise. If not, you'll be stuck operating VPN equipment. If you're running your own VPN service, the ISP's client may not work for you anyway. Will its dial-up client work with your client via an API? More important, will the ISP package your VPN client for installation with the dial-up client for distribution from its Web site?

AT&T, Fiberlink Communications Corp. and OpenReach offer managed-user dial-up and VPN services in a single package. They install the CPE (customer premises equipment) VPN gear supporting the VPN over dial-up. The gear and, in the case of AT&T's offering, the policies are managed for you.

Also on the dialing end, note that the protocol stack the dialer uses may affect the client. If the dialer is using the Microsoft Windows PPP stack, it's likely the VPN software will not be affected, but this is not guaranteed. Test it. If, on the other hand, the ISP is installing its own PPP stack and you're supplying the VPN client--beware! Every dial or VPN client upgrade may require a test run.

SLAs

Service agreements for dial-up services are standard and the ISP should provide frequent reports on that service agreement. It's common for service providers to offer monthly billing reports, but if there is a rash of dial-up connectivity problems, you don't want to wait for the end-of-month report. Your best bet is a portal offering a "My Yahoo"-type page that gives you a quick glance at the service with daily updates.

The services covered by the SLA are crucial. An agreement that covers only the point at which a user's call is on the provider's network may not be enough service for you. An SLA needs to cover network availability, connection speeds and latency. The agreement must be specific, and in the case of dial-up, availability just isn't enough.

When it comes to SLAs, billing credit can bite, but the penalties really hurt. Any SLA with this kind of teeth needs to have clearly defined thresholds. Is a single failure by a single user going to initiate a credit? Not likely. What about two failures? What about three failures for 10 users? You'll have to negotiate these terms, but talking with your users should give you some idea where to start.

Automated billing has long been available from service providers, but accounting codes for bill-back and the flagging of 800 numbers are very important. It is possible that a user doesn't have a choice of a local dial-in number. In this case, matching 800 use with available local numbers is required to accurately bill-back misused 800 numbers.

Dial-up will be with us for some time. Your best bet is to push for easier, smarter clients as well as better back-end reporting.

Bruce Boardman is executive editor of Network Computing. Write to him at bboardman@nwc.com.