Subject: [dhcwg] 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]

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

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.