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

From: Bernie Volz <[email-masked]>
Date: Wed, 21 Jun 2000 18:51:07 -0400

Ted:

OK ... I feel a lot better now that it is the Router Option (3) and not the
Static Route Option.

Sorry for the confusion but I guess it shows that the draft could use some
fine tuning.

And, it does raise the question about what to do with the Static Route
option.

My recommendations regarding the draft:
- Fix references to Router Option and specify the option code (3) to assure
clarity.
- 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.
- Regarding the Static Route Option, I'd suggest:
	- 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.
	- 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).

- Bernie Volz
  IPWorks, Inc.

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

> When, in the draft, you say "Routers option", are you referring to "Router
> option" (code 3) or the "Static Route option" (code 33)? There technically
> is no "Routers option" in RFC 2132. I guess the CSR draft should be clear
> about which option it is speaking of (giving the code numbers wouldn't
hurt
> for clarity).

Oops.   I was referring to the router option.   I thought it was
plural.   Sorry about that.

> If you're talking about the "Router option" (code 3), then I certainly
have
> no problems in applying those as the default routers to whatever is
received
> with the CSR.

Okay, sounds like we actually agree, then.

> However, the Static Route option (33) explicitly forbids the default
> route. Yet, CSR allows it. And, why not just use the Router option
> for default routes?

Right.   I don't know why the Static Route option explicitly forbids
the default route, but it makes a certain amount of sense,
anyway... :'}

> In a classless environment, the Static Route option (33) either becomes
> useless and one is forced to using default routes; or, if one really needs
> routes, one must construct the network configuration carefully and then it
> becomes less than optimal for classless systems.

I'm not sure what to suggest about the static routes option.   I know
that some companies *try* to make use of it, but I don't think anybody
is _really_ making use of it, and I can't see any reason why anybody
would implement a client that tried to use both.   I guess it might
not be a bad idea to explicitly forbid it - that hadn't occurred to
me.

			       _MelloN_

---

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

> 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.

> (and it supports both), it MUST ignore the Static Route Option and install

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?

> information for both, it SHOULD only send the CSR option (to conserve packet

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_

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 21 Jun 2000 16:25:32 -0700

> a client that supports both?

I can't see any disadvantages from supporting both, since the code for
maintaining either will still have to be there. If a client asks for
both and gets one or the other, what's the difference if it gets both?
It should still be able to deal with both kinds of routes, passing them
to the stack as net/mask pairs (or whatever) in either case. What
end-user benefit is there in saying "clients MUST not do both" other
than to simplify the code for client programmers a very wee bit?

If that's not the goal, maybe just deprecating 33 is the best thing to
do. Since the predominate client(s) don't support 33 that's no loss to
most of the end-users.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/

---

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

> do. Since the predominate client(s) don't support 33 that's no loss to

This is precisely the point, and this is what the proposed language
effectively does.  Classed routes effectively don't exist anymore.  If
you happen to have them, they can easily be supported by the CSR
option - you just have to include a netmask.  So there's no benefit to
the end user of the DHCP client in having the DHCP client support both
options.

You could say that there might be some benefit to some server
administrator.  But in practice it seems unlikely that there would be
any such benefit - usually when we hear about option 33, it's somebody
asking how you specify the netmask, and then giving up once they
confirm that you can't.  So the number of server administrators that
would be required to upgrade in order to provide similar functionality
to new clients on an existing network where option 33 is being used
seems likely to be quite small, and I wouldn't want to use them as a
justification for requiring extra complexity in the client.

			       _MelloN_

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 21 Jun 2000 16:43:36 -0700

> > If that's not the goal, maybe just deprecating 33 is the best thing
> > to do. Since the predominate client(s) don't support 33 that's no
> > loss to most of the end-users.
> 
> effectively does.

It should state it explicitly if the justification can withstand debate.
If it cannot, then both of them should continue to be supported. At the
very least, support for both would at least allow admins with complex
networks and 33-capable clients to transition from one to the other.