Subject: RE: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 27 Aug 2001 17:15:11 -0500

I was always wondering why it was MUST NOT. Seems to me that asking for
both options MIGHT be a good thing during the transition period. Especially
since hand encoding the CSR option is a bit tricky so without some special
server configuration support, it likely won't be widely used - or worse yet,
encoded incorrectly!. Certainly hand encoding 20 or 30 routes, especially if
they could change from time to time won't be fun very long and likely to be
wrong.

As the existing static route option likely isn't used for much, having both
is not going to make packets too big. If that does happen, then I guess
a site would need to use an updated server that does not send both or they'd
need to stop using one.

Using static routes these days is kind of questionable anyway, isn't it?

So, I can't give you a technical reason for using MUST NOT and would support
changing this.

I would really like to see this draft get published!!!!!!! It seemed like such
an easy exercise!

- Bernie Volz

-----Original Message-----
From: Stuart Cheshire [mailto:[email-masked]]
Sent: Monday, August 27, 2001 4:59 PM
To: Ted Lemon; DHCP discussion list
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>

>I find it difficult to believe that any existing, deployed network
>depends on the correct operation of the existing static routes option.
>Do you know of such a network, or are you speaking hypothetically?
>CIDR is close to a decade old now, and I find it difficult to believe
>that there exists a network where the static routes option is needed
>and where it can correctly represent the routing table that one would
>need to send to the client.

Ted,

I'm not trying to impede progress on this document. On the contrary, I 
want to get it published ASAP so I can include it in the next Mac OS 
release, but I can't if it is written in such as way as to prevent me 
from doing that.

Apple ships millions of copies of Mac OS. If we change *anything*, 
there's always a non-zero number of people who will complain about it.

The most common use of static routes I know is to tell a host with a 
global address and a default gateway that Net 10/8 is local and reachable 
via a different route.

I can't ship an update that breaks that.

>kludging this draft to support the old static routes option
>side-by-side CSR *would* break new clients.

Why would this break new clients?

Clients can request all three options, but only use "routers" and "static 
routes" when there's no "classless static routes" data in the packet.

The draft already suggests exactly this mechanism for the "routers" 
option. Why not the same mechanism for "static routes" too?

>The reason for the exclusion is that these options are huge, and if
>the server is asked to send both, it is likely that one of them won't
>fit, or that some other important option won't be sent.

You've said yourself that most sites are not even using "static routes", 
so why is this going to be a problem?

Once CSR support is widespread in clients, sites that are currently using 
(or abusing) "static routes" can simply switch over to CSR instead. I 
expect most servers won't send both -- but the client has to ask for both 
because it doesn't know what the server is going to send.

>I would like to get these drafts done,
>and revising them as you have proposed will then require another long
>review period, and may introduce mistakes that actually damage the
>draft.  There is no such thing as a draft that cannot be meaningfully
>clarified - the question is, does it *need* to be clarified.

I also don't want to delay it, but the "MUST NOT request the Static 
Routes option" wasn't in the first few drafts I read, and I apologize for 
not noticing it sooner. As it is, the draft mandates that I have to break 
existing functionality if I want to support CSR. I can't do that.

I proposed new text to try to help this go smoothly. If the WG members
agree with the proposed new text, then we have consensus.

Question for the Working Group:

    ***********************************************************
    *                                                         *
    * Can anyone give any technical reason why it is          *
    * necessary for *this* document to prohibit clients       *
    * from requesting DHCP option number 6 (static routes)?   *
    *                                                         *
    ***********************************************************

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 31 Aug 2001 13:24:13 -0400

After arguing at length so as to avoid making major changes to the
draft, I reread your message, and I think that all your proposed
changes are actually good ones.  So I will be putting them in a new
version of the draft and submitting it to the RFC editor.  Sorry for
being stubborn - I'm just paranoid about delaying this draft any
further.  Thanks very much for your careful read of the draft, and for
your well-thought-out suggestions for improving it.  I'll try to be
less churlish next time.  :'}

			       _MelloN_