Subject: [dhcwg] Option syntax in draft-ietf-mos-dhcp-options

From: Ralph Droms <[email-masked]>
Date: Tue, 23 Dec 2008 15:10:51 -0500

I'd like to get WG feedback on draft-ietf-mos-dhcp-options, especially  
the option syntax in sections 2 and 3.  How does this syntax align  
with the guidelines in David Hankins draft, and with implementation  
practice?

- Ralph

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

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 23 Dec 2008 14:20:42 -0800

On Tue, Dec 23, 2008 at 03:10:51PM -0500, Ralph Droms wrote:
> I'd like to get WG feedback on draft-ietf-mos-dhcp-options, especially the 

I think you mean s/mos/mipshop-mos/?

> option syntax in sections 2 and 3.  How does this syntax align with the 
> guidelines in David Hankins draft, and with implementation practice?

Wow.  I'm not really sure where to start.

It looks like the lemma I summarize as "conditional formatting is
hard" is the one that needs to be reasserted here.  These 'encoding
octets' sound like a great idea, but in practice their inclusion means
these sub-options are not going to be adopted by the existing DHCP
network.  It requires code changes, and I'm not convinced these
configuration parameters are a big enough draw either for a sysadmin
to upgrade his software, nor for a software manufacturer to write new
code to support it specifically.

I don't know a lot about MIP or MOS or ES or CS or IS or any of it, I
admit.

But the case hasn't been made for me to understand why the FQDN format
has been included at all.  It seems at first inspection as though the
only benefit of the FQDN format in its NAPTR->SRV->A dereferencing is
that it also carries DNS-based load balancing / management and port
numbers.

Well, DHCP servers can provide the same kind of load balancing by
giving out different answers to different clients (if you like, I can
show how we did this trivially as recently as IETF Philadelphia).  If
you want to include port numbers, then just switch to a 6-octet sized
array (IP-address plus port number, compound arrayed).  Existing
software supports this, no upgrades necessary.

Which brings me to the 7 sub-options being used here.  This can also
be written as (2^3)-1, which makes more sense when you realize that
these 7 options are designed to convey all combinations of including
IS, ES, and CS feature sets (2^3), minus the one combination that
includes none of them.  This is a scaling problem.  If more feature
sets are later defined, then you will need an exponential increase in
option codes.  This results in an exponential increase in written
lines of code that surely will have to deal with the situations that
arise when conflicting configuration is present in multiple
suboptions.  It is further limited to just 7 sets of feature sets;
2^8-1 is 255, which may be treated by some older software as an END
option, even in a sub-option space that has no such definition.

It seems to me it would be better to define just three sub-options,
and if any server fulfilled multiple roles, list them in each option.

In essence, if a client were looking for a particular role, it would
use the list specific to that service it is soliciting.

As a minor note, I'd suggest calling the suboption numerical
assignments "codes" and not "types."  Maybe it's just me, but it seems
that we refer to DHCP "code and length octets" comprising DHCP
options and suboptions.

-- 
Ash bugud-gul durbatuluk agh burzum-ishi krimpatul.
Why settle for the lesser evil?	 https://secure.isc.org/store/t-shirt/
-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		     you'll just have to do it again."
Internet Systems Consortium, Inc.		-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg