Subject: Last Call on DHCP Options for SLP

From: Ralph Droms <[email-masked]>
Date: Tue, 26 Jan 1999 16:02:34 -0500 (EST)

This is a WG last call for comments on DHCP Options for SLP
<draft-ietf-dhc-slp-06.txt>.  Please respond to the [email-masked]
mailing list with comments by 3/5/99.  If there are no comments, the draft
will be submitted for acceptance as a Proposed Standard.

- Ralph Droms

---

From: [email-masked] (by way of Ralph Droms)
Date: Tue, 26 Jan 1999 19:06:52 -0500 (EST)

message sent to [email-masked] by
[email-masked] follows.
-------------------------------------------------------------------------------
the SLP Service Scope Option still requires a one byte "mandatory" field
within the option.  at the last ietf i thought we concocted a scheme where
the mandatory field was not required.

my preference is that we define options using only the well defined set of
types that have previously been used in option definition and not introduce
a new encoding within an option. this option introduces a "structure"
encoding within the option.

if there is a strong requirement for this type of feature going forward,
then i would like to see the dhcp advisory panel address this in a standard.
by doing so, dhcp configuration systems can be built to allow for data
driven configuration of new options.  the SLP Service Scope option requires
that new option 79 specific code be added to our product (and likely a
number of other vendors products).

in summary, generic new code is good.  specific to an option new code is
bad. option 79 requires the latter. thus i am not in favour of this draft
going forward in its current form.

/gww

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Ralph Droms
> Sent: Tuesday, January 26, 1999 16:06
> To: Multiple recipients of list
> Subject: Last Call on DHCP Options for SLP
>
>

---

From: Erik Guttman <[email-masked]>
Date: Thu, 28 Jan 1999 08:33:42 -0500 (EST)

At the DHC meeting where SLP was discussed I believe we reached two 
conclusions:

  1. A Byte field is acceptable: It would not be hard to implement.

  2. Stating that the DHCP configured value MUST override static configuration
     for the value of scope is a bad idea.  But saying that static config
     overrides the DHCP option supplied value makes the option too weak for
     administrative control over SLP agent behavior.  Adding this control
     byte provides for either case at the discretion of the administrator.

The direction I came away with from the DHC meeting was that I should
remove the flag fields and instead include a byte field, and then to
reissue the internet draft.  

> encoding within the option.

Another way to issue this draft would be to make it stronger and say that
the DHC SLP Scope option, if present, always overrides the user's static
configuration.

> number of other vendors products).

If this is true, then we should probably go with the stricter interpretation
of the option: that it overrides static configuration.  In that case, the
"MANDATORY" byte is not required.

> > will be submitted for acceptance as a Proposed Standard.

Erik Guttman
Sun Labs

---

From: [email-masked] (by way of Ralph Droms)
Date: Fri, 29 Jan 1999 08:26:19 -0500 (EST)

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

> the DHC SLP Scope option, if present, always overrides the user's static

The boolean type is a well-known type that we all know how to
support.   If you, Erik, feel that this boolean is necessary, then I
think you should leave it in.   I'm all in favour of simplifying the
job of DHCP server implementors, obviously, but not at the cost of key
functionality.

			       _MelloN_

---

From: "Glenn Waters" <[email-masked]>
Date: Fri, 29 Jan 1999 09:51:16 -0500 (EST)

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

i whole heartily agree with your last sentence.  what i am suggesting is
that we standardize the way that types may be put together in options.  then
i implement can implement a generic option handler, instead of an new option
handler for each new option that comes along that happens to be a little bit
different.

to be clear i have no problem at all with what erik is trying to accomplish.

/gww

---

From: Erik Guttman <[email-masked]>
Date: Fri, 29 Jan 1999 10:57:53 -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?

A facile answer is that option 21 and 58 concern pairs of 4 byte words
where this concerns a combination of types used in options 20 and 27 on
the one hand and a string value on the other, (like option 12).  Do
options need to contain only tuples of data where all data types in
the tuple have the same length?  Why?

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

Erik

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -