Subject: RE: Last Call on DHCP Options for SLP

From: "Glenn Waters" <[email-masked]>
Date: Mon, 1 Feb 1999 12:35:32 -0500 (EST)

> > Do you object to the option going forward because you fear a precedent
> > which will allow arbitrarily formatted options to be standardized?  I
> > am certainly not attempting to open the door to that.  I explicitely
> > asked the WG if they thought this particular format would be easy to
> > implement on existing servers; the answer in Orlando was "Yes."
>
> I did say in Orlando that this format is easy to implement, and
> several of the other DHCP server implementors nodded and mmm-hmmed
> sagely.

i concur with this observation.

> The objection previously was with putting bit-fields into an
> option, not with putting more than one data type into the option.
> There's no really special interpretation needed here - just two data
> items of different types, concatenated.
>
> I will admit that this is a bit harder than interpreting a single data
> item, but I really think it's going too far to say that this is adding
> another data type, or arguing that it shouldn't be done because it is
> somehow hard to implement.

i am not saying that this is a new data type or that this is hard to
implement.  i am saying that i would like to implement option handling code
once and that code will be able to handle all options -- existing and new
ones.

there is no good way to keep a implementation up to date with all of the new
options if the only way to configure the option is too add some code.  my
impression was that dhcp supported a number of basic data types in an
option. only one of those data types could appear in a single option; in
scalar or array form.  now, none of the RFCs specifically state that rule,
however all existing options to date observe that rule. also, the dhcp panel
work implies (but does not directly state) that a only single data type in
scalar or array form can be encoded in an option.

since solution are good here is what i propose.

1. let option 79 go through as is.

2. have the dhcp panel define how data is allowed to be packed into an
option.  i want to ship a product that can be extended to support new
options without having to send my customers a new version each time a new
option is defined with a new combination of the basic data types.

> I suppose the counter-proposal would be to have two options, one of
> which contains the boolean and one of which contains the the
> UTF8-encoded name.  Given our determination to motivate ourselves to
> implement wider option codes, I guess this isn't an entirely bad idea,
> but we've been talking about this option for a *long* time.  The
> current proposal is perfectly reasonable and implementable.  Requiring
> Erik to go through yet another revision for the stated reason strikes
> me as being unreasonable.
>
> 			       _MelloN_

/gww

---

From: "Glenn Waters" <[email-masked]>
Date: Mon, 1 Feb 1999 12:43:21 -0500 (EST)

> Glenn,
>
> I want to make sure I fully understand the context of your consideration.
> I am therefore going to state the nature of things as completely
> as possible
> so that we can figure out what to do.
>
> Currently it looks like there are the following types transmitted:
>
> OPTION #   TYPE USED
> ========   =========
>  0,255      NOTHING (Pad, END)
>  1,2        LEN (4), 4 byte data (Subnet mask, Time offset, ...)
>  3,4,...    LEN (4n), n 4 byte addresses follow (Router, Time Server, ...)
>  12         LEN (n), n restricted ASCII bytes (Hostname)
>  13,26      LEN (2), 2 byte data, unsigned, (Boot File Size,
> Interface MTU)
>  20,27      LEN (1), 0/1 binary value, (Non-Local Source Routing Enable,
>                      All Subnets are Local, ...)
>  21,58      LEN (8n), n times 4 bytes of address then 4 bytes of mask
>                      (Policy Filter Option, Static Route Option
> is similar)
>  22         LEN (1), 1 byte of unsigned data (Default IP Time to live)
>
> draft-ietf-dhc-slp-06.txt includes two options:
>
> Option 78 is of type 3 above:
>
>   +------+-----+------+------+------+------+------+------+------+-----
>   |  78  |  n  |  a1  |  a2  |  a3  |  a4  |  a1  |  a2  |  a3  | ...
>   +------+-----+------+------+------+------+------+------+------+-----
>
> This is therefore OK.  Option 79 is the one you are concerned about.
> It has the form:
>
>   +------+-----+------+------+------+------+------+------+------+-----
>   |  79  |  n  | BOOL |  s1  |  s2  |  s3  |  s4  |  s5  |  s6  |  ...
>   +------+-----+------+------+------+------+------+------+------+-----
>
> BOOL is a 0 or nonzero.  s1-s(n-1) are the bytes of a UTF-8 encoded
> string.  Thus, there are two values encoded.  Further it is possible
> that the value of n will be 1, which is to say the string may be
> omitted from this option.
>
> One question is:  How is this different than options 21 or 58
> which include
> n pairs of 4 byte data.  This includes one pair of boolean and
> string data?

i would claim that both options 21 and 58 include one data type (IP address)
in array form. i.e.: the syntax of the elements are identical, the semantics
are different (address versus a mask).

see my response to ted's last message for a more detailed response and a
proposed solution.

/gww

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 1 Feb 1999 15:59:03 -0500 (EST)

At 12:39 PM 2/1/99 -0500, Glenn Waters wrote:
[...]
>option is defined with a new combination of the basic data types.
[...]
>/gww

I strongly concur with Glenn -- thanks Glenn for taking the time
to be so clear on this.  I'll echo Glenn's final comment:

    "I want to ship a product that can be extended to support new
    options without having to send my customers a new version each 
    time a new option is defined with a new combination of the basic
    data types."

Cheers -- Kim

---

From: [email-masked] (by way of Ralph Droms)
Date: Tue, 2 Feb 1999 07:16:03 -0500 (EST)

message sent to [email-masked] by [email-masked] follows.
------------------------------------------------------------------------

> my impression was that dhcp supported a number of basic data types
> in an option. only one of those data types could appear in a single
> option; in scalar or array form.

This is probably a result of my days of hacking on gcc, but I've
always interpreted the spec as saying that any number of data elements
of varying types could be present in an option.  My server code is
written that way - it uses a trivial stack language to parse option
data.  Admittedly, in browsing through my table of options, I don't
see any that take advantage of this, other than options that take
arrays of pairs of IP addresses.

> 1. let option 79 go through as is.

Sounds good.

> option is defined with a new combination of the basic data types.

This also sounds like a good idea, within reason: we shouldn't
restrict the sorts of data types that might be added in the future,
although we may want to explicitly differentiate options that add new
data types from options that do not.   The current draft already
explicitly differentiates options that require protocol changes from
options that do not, so this wouldn't be a surprising change.

			       _MelloN_