Re: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt

[Ted Lemon <Ted.Lemon at nominum.com>]

> Second, I'd rather see suboption 3 broken out into two different
> suboptions
> denoting the different data types. I'm not aware of any other DHCP
> option
> that has a type field.

This is an excellent point.   Options with variable formats _always_
require special code in the DHCP server to support them.   I think the
authors should choose either an IP address or an FQDN as the format in
which the SIP server's IP address is communicated.   If this is not
possible, then the draft should at least be consistent with the SIP RFC
(rfc3361), which does something similar, but chooses exactly the
opposite meaning for the flag byte.

The problem with allowing the option to contain either an FQDN or an IP
address is that now the DHCP server has to have special code to support
this specific option.   Most DHCP servers (well, admittedly, I only
have experience with two) are table-driven with respect to option
formats, so this is a big deal.   For example, because of the need for
a special hack, I don't know when or if the ISC DHCP server will
support the SIP option described in rfc3361, since I am no longer
working on it.   If SIP had chosen one or the other format, it would
already be supported.