Subject: [dhcwg] dhcpv6-24: vendor-specific issues

From: Thomas Narten <[email-masked]>
Date: Wed, 08 May 2002 11:14:28 -0400

>    Servers can interpret the meanings of multiple class specifications
>    in an implementation dependent or configuration dependent manner, and
>    so the use of multiple classes by a DHCP client should be based on
>    the specific server implementation and configuration which will be
>    used to process that User class option.

This sure reads badly in the sense that it smells like
interoperability will not result. But I'm not sure what the intent of
the wording is here... Could someone clarify?

> 22.18. Vendor-specific Information option
>
>    This option is used by clients and servers to exchange
>    vendor-specific information.  The definition of this information is
>    vendor specific.  The vendor is indicated in the enterprise-number
>    field.  Clients that do not receive desired vendor-specific
>    information SHOULD make an attempt to operate without it, although
>    they may do so (and announce they are doing so) in a degraded mode.

This also reads badly and against interoperabilty. DHC clients should
never depend on vendor-specific options in order to function
correctly.

Thomas

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 15 May 2002 13:23:33 -0400

>the wording is here... Could someone clarify?

The idea is to support additional flexibility and precision in identifying 
clients in some deployments.  This situation anticipates that clients will 
be configured to send additional classing information and servers will have 
policies to select configuration information based on those 
classes.  Because both the clients and server have been "managed" for this 
deployment, they will interoperate.  A client that moves and tries to use a 
server that does not have policies for the classes specified by the client, 
or a client that does not supply the class specifications will get 
configuration information that is not selected on the basis of the client 
classes.

>never depend on vendor-specific options in order to function

This text is essentially copied directly from section 8.4 of RFC2132 
(which, of course, doesn't necessarily make it a good idea).  Perhaps the 
differentiation should be "enhanced operation" with the vendor-specific 
information versus "functioning operation" without?

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Wed, 15 May 2002 16:31:55 -0400

> configuration information that is not selected on the basis of the client 

I think my issue is more with the wording than the intent.

TO be sure I understand, the User Class option is one that is
configured by the end user. I.e., to say "accounting", "engineering",
etc. In that case, the server processing shouldn't be "implementation
specific" or "vendor specific".

Another confusing part. The text is talking about multiple occurances
of the option. How this is dealt with shouldn't be configuration
specific... We don't get interoperability that way... 

On rereading this, one thing that is missing is discussion about how
the client sets the value. Is it really "opaque data"? Shouldn't  this
be a utf-8 string (for ease of configuration)?

Also, the server should treat them as opaque values in conjunction
with its configuration-specific data. This is not stated.

Does this help clarify my concern?

> information versus "functioning operation" without?

yes. It should not be implied that things "may not work well" if the
server doesn't support the option. Rather, when it is supported, there
maybe enhanced operation.

Thomas