Subject: REMINDER: WG Last Call for "The Subnet Selection Option for

From: Ralph Droms <[email-masked]>
Date: Thu, 22 Apr 1999 13:26:12 -0400 (EDT)

REMINDER - WG last call ends 4/23...

This is a WG last call for "The Subnet Selection Option for DHCP",
<draft-ietf-dhc-subnet-option-01.txt>.  This document has been revised
according to the comments from the WG discussion in Minneapolis, 3/99.
According to the consensus of the WG, the document is now in WG last call
prior to submission for acceptance as a Proposed Standard.

Please respond to the mailing list with comments by Friday, 4/23.

- Ralph Droms

- Ralph Droms
  Computer Science Department        (570) 577-1145 (o)
  Bucknell University                (570) 577-1822 (f)
  Lewisburg, PA 17837                [email-masked]

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Mon, 26 Apr 1999 09:29:07 -0400 (EDT)

Glenn, Ralph, Thomas, et al.--

1.   Some annoying grammatical errors appear in section 1, "Introduction,"
that confuse the purpose of the proposed option.  The phrases "... specifies
the subnet on which a DHCP server should use ..." and "... determine the
subnet on which to select an address." should be reworded to avoid this
confusion.

2.   I also agree with Thomas that the introduction of the concept of a
"control" and "packet-handling" plane also serves to confuse the purpose and
use of this option.  I have no idea what the concept is attempting to
accomplish after several readings.

3.  When I first read the draft, I thought it was a straightforward option
by which (a) a client connected to a network segment consisting of multiple
subnets (for example, 129.245.139.0 and 129.245.197.0) might indicate the
preferred subnet from which to obtain an address, or (b) a user or
vendor-class identifier might specify the subnet for use by members of the
class.  Now, however, I don't see what problem the draft is attempting to
solve nor how it can be used in practice:  a client could inadvertently
request a subnet using this option that is unreachable from its network
connection, but "... the server MUST NOT offer an address that is not on the
requested subnet or network segment."  Unlike the requested IP address
option, this one gives the server no room to offer an address to the client
if the client has made an inadvertent mistake.

Glenn--I know that you feel this option solves a particular problem that has
arisen from your clients or for some planned product offering, but I don't
understand it's usefulness.  It almost seems as if you believe that the
client has better knowledge of the network topology in some circumstances
than the network (server) administrator, else why request a specific subnet?

When I thought about a network device such as a switch or router that might
be connected to two or more different network segments, then I could
understand why such a device, as a client [an embedded SNMP agent, perhaps?]
might wish to obtain its operating parameters (including IP address) from
one network segment in preference to another, but I must say that the draft
didn't make the point at all obvious.

--Barr