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