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

From: Bernie Volz <[email-masked]>
Date: Thu, 22 Jun 2000 09:36:10 -0400

Ted:

>I don't want to specifically disallow putting static routes in the CSR
>option because it places an unnecessary requirement on the server.
>Given how unlikely it is that anybody would use the old static routes
>option in this day and age, I think that simply stating it as an
>operational requirement is sufficient.

I think disallowing and forcing use of the existing option for this purpose
is best. It avoids misconfiguration errors. Question: Why was it not allowed
in the Static Route Option? Perhaps because it wasted 4-bytes per route, but
perhaps also they didn't want the same piece of information to be configured
two different ways.

>I think we should just say that no client that implements the CSR
>option should implement the SR option.   Can you see any advantage to
>a client that supports both?

No you can't do this. The client has NO idea what the server supports. So,
the only thing the client can do is request both and hope that the server
supports CSR and sends that back. So, a client must implement both options.

>I would strongly resist placing this sort of restriction on the
>server.   In general, right now, there are only a few options that
>DHCP servers need to treat specially in terms of how they're handled
>in the parameter request list.   Adding this requirement would be a
>significant burden on implementors, and I don't think it would add
>value.

It is a SHOULD or MAY. It is not a requirement as the client will process
only the CSR option anyway. It is just that I'd like a statement that says a
server MAY (or SHOULD) not send both as that means the packet doesn't
contain useless data - any savings in bytes may be desireable under certain
cases (such as with restricted MTU sizes, etc).

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, June 21, 2000 7:11 PM
To: Bernie Volz
Cc: DHCPv4 discussion list
Subject: Re: draft-ietf-dhc-csr-02.txt

> - We can debate this, but I think it best to leave default routes in the
> Router Option and, as the Static Route Option (33) does, disallow default
> routes in the CSR option. I think it is cleaner and less likely to lead to
> configuration errors or problems (after all, that's what you're trying to
> do). Put a piece of data in only one place is usually a good rule.

I don't want to specifically disallow putting static routes in the CSR
option because it places an unnecessary requirement on the server.
Given how unlikely it is that anybody would use the old static routes
option in this day and age, I think that simply stating it as an
operational requirement is sufficient.

> 	- If a client receives a Static Route Option (33) and a CSR option
> (and it supports both), it MUST ignore the Static Route Option and install
> the CSR option routes.

I think we should just say that no client that implements the CSR
option should implement the SR option.   Can you see any advantage to
a client that supports both?

> 	- If a server receives a parameter list request from a client for
> both the Static Route Option and the CSR option and it has configuration
> information for both, it SHOULD only send the CSR option (to conserve
packet
> space).

I would strongly resist placing this sort of restriction on the
server.   In general, right now, there are only a few options that
DHCP servers need to treat specially in terms of how they're handled
in the parameter request list.   Adding this requirement would be a
significant burden on implementors, and I don't think it would add
value.

So what I would suggest, based on your message, is that we do as you
say and explicitly mention the router option code as well as making it
singular, not plural.   In addition, I would suggest that we add the
requirement that any client that implements the CSR option MUST ignore
the SR option if received, and MUST NOT request the SR option.

			       _MelloN_