Subject: RE: User Class draft

From: Bernie Volz <[email-masked]>
Date: Wed, 3 May 2000 10:30:08 -0400

><draft-ietf-dhc-userclass-06.txt> includes the last changes agreed on this
>list. It has been out for a couple of weeks now without further comments.
>
>Could we go to WG Last Call for this draft?

Sorry about these late comments ... 

I have a nit with the draft as it stands. This change is recommended to
clarify the definition of the option data.

In section 4 it current says:

>Each User Class value is indicated in an opaque field and is
>preceded by a one-byte field giving its length.
>The length of the option as specified in Len must be the sum
>of the lengths of each of the class names, starting with Len1
>through to the length of the last class.
>
>
>   Code   Len   Len1            Len2
>  +-----+-----+-----+----------+-----+--------------+----
>  | TBD |  N  |  L1 |  class 1 | L2  |    class 2   |...
>  +-----+-----+-----+----------+-----+--------------+----

I assume L1, L2, ... are the length of the class name (class 1, ...)
PLUS the 1 byte for the length.

The security section (5) is also a bit weak. It might be useful to point
out that there is no explicit authentication of whether a particular
client is allowed to use a user class or not - we "trust" the client to
supply an appropriate class.

And, perhaps it is worth pointing out that naming this "user class" is
really not correct as there is NO true correlation to the user(s) of the
client system. It is really a client class (however name is already
taken).

While I can understand reasons for wanting to keep the draft flexible
and leave a lot of the policy issues to server implementations, I think
that for this option to be useful, a warning that says something to the
effect that "servers implementations are free to intreprete the meanings
of multiple class specifications as they desire and thus the behavoir
when multiple classes are specified by a client is not standardized."

- Bernie Volz
  IPWorks, Inc.

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 03 May 2000 11:41:20 -0400

>PLUS the 1 byte for the length.

         I read the draft w/out looking at Bernie's comments and I
         had the same problem as Bernie.  As described, the Len1,
         Len2 etc.  would seem to be the length of class 1, class
         2.  If this is the case, i.e., if they don't also include
         themselves, then Len cannot equal Len1 + Len2 +...+ Lenn,
         because it would come up "n" short.  But the draft says
         that Len is the sum of all of the Len1...Lenn.

         So, either Len1 must equal the length of Class 1 + 1, *or*
         Len should be defined as Len1 + Len2 + ...  + Lenn + n.
         I don't care which, but one of these should be made clear.

>when multiple classes are specified by a client is not standardized."

         At some level, what we are standardizing here isn't the
         behavior of the server when presented with a user class
         option, but rather the way to transmit that option from a
         client to the server in a standardized manner.  I think
         that is appropriate, because the way that a server
         behaves when presented with a user class option will be
         driven totally by its configuration given by the network
         administrator configuring the server.  That is just the
         way an option like this works.

         I think that while we could add the comment Bernie
         suggests above and it would be true, if we are going to
         add a comment, we might say something like "servers may
         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".  Which is true anyway
         and for all user class options whether they are multiple
         or not because this is just the way that an option
         like this works.  But it might make sense to stress this
         for multiple class specifications, since the number of
         different ways that a server could process it is greater
         than that of a single class.

         I could go either way, put it in or leave it out.

         Cheers -- Kim

---

From: Ted Lemon <[email-masked]>
Date: Wed, 03 May 2000 18:19:11 -0400

> PLUS the 1 byte for the length.

I hope not, since this would be the only place in any DHCP-related
protocol where the length included itself.

			       _MelloN_

---

From: Richard Jones <[email-masked]>
Date: Wed, 03 May 2000 16:47:40 -0700

> protocol where the length included itself.

I understood the issue to be over the length byte that immediately
follows the tag [TBD] byte, which describes the length of the whole
option field. In the draft, it's not clear that the whole option length
has to include the length byte for each userclass name as well as the
length of the name itself, when multiple classnames are in the option
space.

Richard