Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!DECWRL.DEC.COM!kent From: kent@DECWRL.DEC.COM Newsgroups: comp.protocols.tcp-ip Subject: Re: Dial-up TCP/IP (was interactive SMTP over phone lines) Message-ID: <8705121757.AA19307@armagnac.DEC.COM> Date: Tue, 12-May-87 17:16:34 EDT Article-I.D.: armagnac.8705121757.AA19307 Posted: Tue May 12 17:16:34 1987 Date-Received: Fri, 15-May-87 03:16:08 EDT References: <8705121740.AA16793@opal.berkeley.edu> Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: "Christopher A. Kent" Distribution: world Organization: The ARPA Internet Lines: 22 Greg, Every time this issue comes up, I wonder why people don't want to assign addresses to micros. Is it just a problem of scale? I realize that most of the micros won't be hooked up at the same time. But, if you're going to have server SMTP service on the micro, that probably means that each micro needs a unique name. If you don't assign it a permanent number, then you have a real headache at startup, interacting with the nameserver database, etc. If you're just talking about having client services on the micros, then you can get away with random names/numbers. But home micros are getting powerful enough that people might want to have server SMTP sitting there. Another authorization problem arises for home micros that want to be remote file system clients. It seems very difficult to use the flexible protection/authentication mechanisms that are appearing if you don't know exactly which host is the client -- the 4.2 .rhosts mechanism breaks down pretty quickly. The contents of .rhosts either becomes all possible dialup hostnames, or is essentially useless. chris