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

From: [email-masked]
Date: Fri, 7 Apr 2000 15:53:59 +0100

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

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

Thanks,
Jerome Privat
BT

-----Original Message-----
From: Steve Gonczi [mailto:[email-masked]]
Sent: 03 March 2000 19:51
To: DHCPv4 discussion list
Subject: Comments on draft-ietf-dhc-userclass-05.txt

Hello,

I believe the N and Ln fields should be 2 byte fields. 
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).

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.

/Steve Gonczi
Process Software Corporation

---

From: Ted Lemon <[email-masked]>
Date: Fri, 07 Apr 2000 11:09:18 -0700

> to have the N field (total length of the option) being a 2-byte

If it's a DHCP option for RFC2131/2132, then the length has to be one
byte.   If it's for DHCPv4NG (the work Mike Carney has been doing)
then it should be two bytes.   Given that we don't have an RFC number
to refer to for DHCPv4NG, it's probably reasonable to specify one
byte.   I'm not sure why you're asking this question, though - the
draft currently specifies a one-byte length.

> Regarding using a start and end time subfields for each class:
> possible

I would prefer this too.   Indeed, unless we want to spend another
year specifying how the start and end times should be used, I don't
see that we have a choice.

Since I'm looking at it, here are some additional comments:

> If i is the number of User Classes carried in the option,
> its total length N is equal to i + sum(Li). 

This use of mathematical notation is a bit questionable, because you
don't have the wherewithal to do subscripting.   I would suggest
phrasing it in english:

 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.

I'm not claiming this is any clearer - it's just that it doesn't
assume people will guess that, for example, sum(Li) means the sum of
all Len fields starting with Len1 and going to the last Len field.
:')

> Servers not equipped to interpret the user class specified by
> a client MUST ignore it (although it may be reported).

I'd rephrase this:

 A server that is not equiped to interpret any given user class
 specified by a client MUST ignore it (although it may be reported).
 If a server recognizes one or more user classes specified by the
 client, but does not recognize one or more other user classes
 specified by the client, the server MAY use the user classes it
 recognizes.

> DHCP clients implementing this option SHOULD allow users to enter
> their User Class.

 DHCP clients implementing this option SHOULD allow users to enter one
 or more user class values.

These latter two changes come up because of the ability for this
option to carry more than one class - I think the language in the
draft is from a time when the user class option only specified one
class.   :'}

			       _MelloN_