subenet-mask option in DHCPACK for DHCPINFORM

[Frank Bulk]

I agree with John.  Follow the RFC's as closely as possible, and then
include options to explicitly turn things on or off.  And because there will
probably be so many, wrap up each individual option into a larger
"compatability mode" option.  At least all the judgment calls are
documented.

Frank

-----Original Message-----
From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
Of John Wobus
Sent: Tuesday, July 24, 2007 11:34 AM
To: dhcp-users at isc.org
Cc: John Wobus
Subject: Re: subenet-mask option in DHCPACK for DHCPINFORM

> It is neither a MUST nor is it a MUST NOT.  In fact, servers MAY
> provide additional options.
>
> In the context of DHCPINFORM, I think this behaviour is not right,
> and we'll fix this in a future release.
>
> In the case of DHCPREQUEST, this behaviour is unfortunately mandatory
> to be compatible (and to actually work on the modern Internet).
>
> I'm a little bit disappointed to see a client that throws an error if
> it sees an option it doesn't understand.  The best thing to do is to
> just ignore the option.  These sorts of things do happen!

We all are disappointed that with the variety of clients out there in
the wild, running (and developing) a production enterprise DHCP
server now represents a maze of things to be done and things
to be avoided.  I vaguely recall on this list, discussion of the concept
of a means to configure an option to be "sent, whether asked for
or not".  In other words, a means to make your server do that thing
that servers MAY do.

Part of me thinks such a feature would be better than silently doing
that very thing for a single special case.  On the other hand, if^H^Hwhen
client developers throw us more curves in the future, I can hardly
predict that that particular configuration feature would be the end of this
story, and likely it wouldn't even make much a dent in the larger problem.

John Wobus