Subject: RE: draft-ietf-dhc-csr-02.txt

From: Bernie Volz <[email-masked]>
Date: Wed, 21 Jun 2000 09:53:28 -0400

Ted:

draft-ietf-dhc-csr-02.txt  looks good. I do have one issue with it however.
Why do you want to use the following policy?

   If the DHCP server returns a Routers option, clients that support
   the Classless Static Routes option MUST use the default route(s)
   listed in the Routers option in addition to the routes listed
   in the Classless Static Routes option.

>From a server configuration standpoint, wouldn't it be better if the CSR
option was just and the Routers option ignored?

In this way, one can configure both options for a server (the Routers option
can carry a less-than-optimal routing list because of the limitations of
representing the data and the CSR option can contain the full routing
information). A client can request both (if it supports both) since it does
not know if the server supports CSR or not. The server then sends back both
(since the client requested them) and the client uses the more optimial
option (CSR) if it is present and ignores the Routers (if present).

Otherwise, the configuration gets messy since you might have the following
situations:
A) Client supports only Router option.
B) Client supports both Router and CSR option.
This means that the server's configuration would have to allow for a Router
option if CSR not support and a Router option if CSR supported by client.

So, I'd recommend the text to read:

   If the DHCP server returns both the Routers and Classless Static
   Routes options, clients that support the Classless Static Routes
   option MUST NOT use the default route(s) listed in the Routers
   option; they MUST use only the routes listed in the Classless Static
   Routes option.

Again, that's my only issue.

Regards,

- Bernie Volz
  IPWorks, Inc

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jun 2000 10:02:16 -0700

> option was just and the Routers option ignored?

Yes, it would.   However, the problem with this is that it creates an
insoluble interoperability problem.   By stating the requirements for
the server and client the way I did, we can be certain that if people
follow these requirements, clients that support CSR and clients that
do not will continue to work.   Without following these requirements,
it's easy to imagine situations where some clients won't get a correct
default route.   I think that in an ideal world, we'd just use CSR and
not the routers option, but the world we live in is unfortunately not
ideal in this one small way.   :'}

			       _MelloN_

---

From: Richard Jones <[email-masked]>
Date: Wed, 21 Jun 2000 09:23:30 -0700

I thought the same thing at first, but after a few minutes I came to
agree that from an interoperability standpoint, Ted's language is
the broadest and safest, even though it does mean configuration
gets more difficult.

A couple of non-protocol editorial suggestions: in paragraph 1
sentence 2 of the Introduction, you might remove the first instance
of the phrase "to see if" to make it clearer, i.e.

"it first checks the IP address of the destination"

And in paragraph 6, make 'seperate' into 'separate'.

By the way, if this type of feedback isn't considered useful or
necessary, please let me know and I'll  quit natting the
documents ;-).

Richard