Subject: Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt

From: Bud Millwood <[email-masked]>
Date: Thu, 14 Nov 2002 11:55:09 +0100

Apologies for not getting these out sooner, I've just gotten around to
implementing this option.

draft-ietf-dhc-packetcable-04.txt

In this document, two things seem to veer slightly from the existing DHCP
protocol.

First, it seems that suboptions 1 and 2 could be consolidated into one
suboption only. Regular DHCP options carry multiple values in preferential
order, so I don't see why this suboption couldn't do the same.

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.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
mailto:[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Nov 2002 10:46:43 -0600

> denoting the different data types. I'm not aware of any other DHCP

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.