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

[Stuart Cheshire <[e-mail]>]

>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 <[e-mail]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



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