> 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.