Subject: RE: Comments on draft-ietf-dhc-userclass-05.txt

From: "HIBBS, BARR (SBCSI)" <[email-masked]>
Date: Fri, 7 Apr 2000 09:37:00 -0700

> From: 	[email-masked][SMTP:[email-masked]]
> Reply To: 	[email-masked]
> 
> - Regarding the length fields, I am wondering if it is valid
> to have the N field (total length of the option) being a 2-byte
> field.
> RFC 2132 says that every variable-length DHCP option
> starts with a tag octet followed by a length octet, followed 
> by "length" octets of data. This seems to imply that a valid
> DHCP option must have a one-byte length field.
> 
...more than "implies."  DHCPv4 (per RFC2132) supports only a one-octet
length field, permitting the total length of an option to be 1-255 octets (0
is permitted, of course, but why bother sending a null option?)

> - Regarding using a start and end time subfields for each class:
> I would prefer to keep the User class option as simple as
> possible, just carrying the User Class values as opaque objects.
> A DHCP server admin can configure different lease times for
> different address pools and/or different User Class values.
> Has anybody else on the list a view on that? The WG consensus at
> the Washington meeting was to keep the option as simple as it
> can be...
> 
...I agree that the User Class option should be treated very much like the
Vendor Class option, that is, the option data should be considered an opaque
octet string.

...Steve's original point was about starting and ending times rather than
lease durations, but I agree with you that including times in the option
violates the principal of simplicity, presumably because that implies the
server would not treat the data as a string of opaque octets.

> -----Original Message-----
> From: Steve Gonczi [mailto:[email-masked]]
> Sent: 03 March 2000 19:51
> 
> 
> I believe the N and Ln fields should be 2 byte fields. 
> 
...are you suggesting that we ratchet up the DHCPv4 version number, Steve?
That is really a much bigger issue than the User Class option.

> It is quite possible, that the individual class values end up longer than
> 255
> esp. if the values are generated by some ticket issuing authority /
> self-registration server. (In practice, these class values may end up
> being 
> certificates, or some simpler authenticated tickets).
> 
...I don't believe we should be concerned with the contents of the option at
all -- treat it as an opaque octet string.

> Also, it would be quite useful to include start and end time subfields for
> each class value. (Something like time_t formatted UTC values... 32 bit
> NBO etc..
> etc..) The obvious use of the end time is to provide a ttl for the ticket
> (a.k.a
> class x ) and the start time could be used for reserving resources for a
> specific time
> slot. E.g.: to schedule a video conference ahead of time.
> 
...again, the contents of the User Class data shouldn't be of concern to the
working group.  In the application for User Classes that I forsee, time
values would be of no use at all, so I would argue that it should not be
included.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 7 Apr 2000 12:45:45 -0700

Out of curiousity: what is the difference between
the user class option and the DHCP authentication
option, when used with Protocol 0 (authentication
token). 

It seems to me that both options accomplish the
same thing, sending an opaque string that can be
construed as a claim of identity. 

Some potential differences:

* The authentication option Protocol 0 seems 
designed to be sent from the server to the client.
However, it does not appear prohibited for
clients to send it in a DHCPDISCOVER and for
servers to use this as an indication of the
class of user.  

* DHCP authentication requires that the receiver
discard the packet if the contents of
the authentication option cannot be validated.
Thus there is a difference in behavior between
sending an unknown Protocol 0 token and sending
an unknown user class option.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 07 Apr 2000 16:35:22 -0700

> construed as a claim of identity. 

No, they don't.   A class is not the same thing as an identity.
There can be many non-identical members of a class.   It would be
entirely appropriate for more than one client to report the same user
class, and this should not result in incorrect behaviour on the part
of the server.

A better question would be, what is the difference between the client
identifier option and the DHCP authentication option, when used with
Protocol 0.   :')

			       _MelloN_