Comments/questions on latest draft
"Philip A. Prindeville" <philipp@erols.com> Mon, 22 April 1996 00:27 UTC
Received: from ietf.cnri.reston.va.us by IETF.CNRI.Reston.VA.US id aa10994;
21 Apr 96 20:27 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa10990;
21 Apr 96 20:27 EDT
Received: from reef.bucknell.edu by CNRI.Reston.VA.US id aa12647;
21 Apr 96 20:27 EDT
Received: from localhost by reef.bucknell.edu with SMTP
(5.65/IDA-1.2.8) id AA18232; Sun, 21 Apr 1996 20:23:56 -0400
Date: Sun, 21 Apr 1996 20:23:56 -0400
Message-Id: <199604212336.TAA23335@erols.erols.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
X-Orig-Sender: dhcp-v4@bucknell.edu
Precedence: bulk
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Philip A. Prindeville" <philipp@erols.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Comments/questions on latest draft
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
3.5 -- should be deprecated. We can do the same in 5.8... I like the idea of including FQDN instead of IP addresses for most services expect perhaps the DNs servers themselves. But that complicates things a bit, since we would break older implementations. Perhaps we could go to a new version number of the protocol? 3.19 -- "Root path". This is unix-centric. Couldn't this be made "system volume" or something like that? 4.3 -- did anyone actually implement this? 5.7 -- you might want to reference the default (all routers) multicast address, and mention that this can be a multicast or broadcast address. 5.8 -- a better format would be: dst-address, mask, next-hop-router, preference preference should be two octets long. 4 seems unnecessary. If the dst-address is 0.0.0.0 or the mask is 0 bits long, then this is a default route (maybe we should mandate both so there is no ambiguity). Perhaps attach a note that this is preferred to using 3.5 which would be deprecated. General -- an SNMP community the box (client) should belong to, as well as whether it is a read-only or read-write community. The format of this might be: +----+----+----+----+----+----+----+-- | XX | nn | YY | community string ... +----+----+----+----+----+----+----+-- where XX is the option number as given by the numbers Czar, nn is the length of the option, YY is access (0 = read-only, 1 = read-write, other values are reserved), the community string is a non-NULL terminated string that gives the community name. Multiple communities may be specified. Can we put multiple instances of the same option, or do we need a sub-length code? Other options to consider: A (possibly one-shot) session identifier (or login) to be used when accessing servers; A tagged session key to be used with the above identifier (the tag might specify that it is a clear-text password, a CHAP secret, a Kerberos V4 cookie, a Kerberos V5 cookie, etc); An SMTP address that the user may send mail as (ie. some sites like to "obscure" or hide the user's login name when sending mail by using an unrelated name that maps one-to-one to a login id, or by using the fullname of a user like Philip_A._Prindeville@...); A list of proxies: httpd (in which case we obsolete 8.17), gopher, ftp, socks, possibly others? since security might be a local concern; A timeshare host where the user can have a "shell"; A URL that the user should consult for the latest information from his site administrator. A sort of "message-of-the-day" for remote hosts. A lot of this information seems to be session-specific, but for dialup users, that's the very nature of configuration information that they need. Now, one might argue that there are better places to solve these (higher-level) issues. I'll agree. It's just that known of these alternates have been specified. -Philip
- Comments/questions on latest draft Philip A. Prindeville