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

From: [email-masked]
Date: Mon, 10 Apr 2000 08:58:41 +0100

Thanks for your comments. See my answers below.

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

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.

I was asking this question to answer a proposition by Steve Gonczi to
increase the length field to 2 bytes.
In any case I agree with you, let's keep it 1 byte so that we can
go to Proposed without waiting for DHCPv4NG to become an RFC.

> Regarding using a start and end time subfields for each class:
> I would prefer to keep the User class option as simple as
> 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.
:')

Fine. I will use your text.

> 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.   :'}

You are right. I will make the changes you suggested.

Thanks again for your comments. I will edit a new version of the draft
with these changes.

Jerome