A few thoughts on [Re: Invitation to Network Providers]

Thu Mar 10 04:26:12 UTC 1994

>         The software program will also obtain, or alternatively ask 
> for, the name of the network provider and/or the brand of the 
> communications server used at the network provider's POP (typically 
> CISCO, Livingston, Emulex, or other hardware).  This will enable 
> CSI's program to construct the brief but critical connect-time 
> SLIP/PPP negotiation macro used for initializing the network 
> connection and in some cases, for obtaining the user's dynamic IP 
> address assigned at connect time by some network providers. 

Handwaving this is inviting trouble.  A macro language for writing chat 
scripts (such as Apple's ARA CCL, which sucks but works) needs to be 
specified, and the scripts should be delivered in human-readable/editable 
(eg. text file, not compiled) format so that they can be tweaked to fit any 
local weirdnesses for a particular provider or have hacks installed by a 
savvy user to get around local problems like a cranky PBX (ie, don't let the 
desire to be user-friendly eclipse the need to be easily reconfigurable by a 
knowledgable person).  Moreover, hooks for more parameters than just UserID, 
Password, IPAddress, PhoneNumber, and MaxSpeed need to be provided to support 
things like secondary passwords, callback, etc.

DefaultGatewayIP is superfluous in the case of the single leaf node connected 
to a terminal server running PPP.  Since nothing else here addresses the 
complexities of routing to a subnet, I conclude that this proposal only 
addresses the former case.  You may as well just dike that field out.

For POP3, NNTP, and SMTP, you need to specify return addresses and full-
names.  These will not necessarily be the same as the username in the 
terminal emulator or PPP session, for obvious reasons.

  I like the idea of a configuration language that hides the nuts and bolts 
of PPP from Joe and Jane Luddite with their 486-PC-running-Windows <grin> but 
I think it needs lots more thought before it is viable in the wide variety of 
circumstances it will find itself in out there in real world.

Oh yeah, I don't think it's such a hot idea to promulgate a new standard in 
which (a) passwords are stored online in cleartext, and (b) reusable 
passwords are passed back and forth over the net in cleartext.  Better by far 
to specify Kerberos or a session key handshake for user authentication, and 
maybe even encrypt the entire session...

Just my two cents worth...

							---Rob