subenet-mask option in DHCPACK for DHCPINFORM

[John Wobus]

> 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