Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed S tandard

From: "Kostur, Andre" <[email-masked]>
Date: Fri, 20 Oct 2000 08:02:39 -0700

Personally, I think Microsoft (and all vendors) should be required to
provide service packs/patches to their existing DHCP client stacks.  To
quote from every draft I've read:

"It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."

When they included the User Class option in a production environment, they
knew that the option they were using could be subject to changes.

> -----Original Message-----
> From: Bernie Volz [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 7:55 AM
> To: DHCPv4 discussion list
> Cc: [email-masked]
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> S tandard
> 
> 
> While using a new option number is certainly a solution, it 
> likely means
> we'll have to keep the old one around forever.
> 
> As it should likely be fairly easy for a server to detect the 
> difference,
> perhaps that needs to be described in the draft/RFC ... I assume that
> Microsoft's implementation is just to send the user class 
> string in the
> option. As this is likely to be ASCII, it should be easy for 
> a server to
> look at the received option and detect a 'problem' if the 
> first class length
> is greater than the option length (as that should not be 
> possible). In that
> case, it could assume that it is an old Microsoft client and 
> use that option
> format? Or, it would need to drop that option OR the entire 
> packet as being
> mal-formed.
> 
> - Bernie Volz
> 
> -----Original Message-----
> From: A. Gregory Rabil [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 9:20 AM
> To: DHCPv4 discussion list
> Cc: [email-masked]
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Jerome,
> Of course I understand that Microsoft's implementation long 
> predated the
> User Class as Proposed Standard.  My question goes more 
> toward the fact
> that although MS may update future clients, server vendors will likely
> have to deal with W2K clients for quite some time anyway.  It 
> seems that
> it would have been prudent to select a new option number for the new
> format, just to ease the transition, then phase out 77 and use it for
> something else.
> 
> My $0.02,
> Greg
> 
> -----Original Message-----
> From: Jerome Privat [mailto:[email-masked]]
> Sent: Friday, October 20, 2000 3:02 AM
> To: [email-masked]'; [email-masked]
> Cc: [email-masked]'
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Greg,
> 
> Implementation for existing Microsoft 2000 clients was 
> written well before
> the User Class was accepted as Proposed Standard (which just 
> happenned now).
> So it is normal it does not support what is in the spec now 
> (the same is
> true for other pre-standard implementations).
> 
> That being said, the syntax in the draft was discussed with 
> people from
> Microsoft (Ann Demirtjis at the time, who co-authored the 
> draft). So I would
> expect next versions of MS clients to adhere to the spec.
> 
> Jerome
> 
> Jerome Privat
> Northstream AB
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, October 19, 2000 6:30 PM
> To: [email-masked]
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> I apologize for the repost, but I hear crickets... anyone 
> care to comment?
> 
> Greg
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of A. Gregory Rabil
> Sent: Wednesday, October 11, 2000 6:09 PM
> To: DHCPv4 discussion list
> Subject: RE: Protocol Action: The User Class Option for DHCP 
> to Proposed
> Standard
> 
> 
> Has anyone given thought to the implications involved with 
> the existing
> Microsoft Windows 2000 DHCP clients that use this option?  
> Specifically, MS
> W2K clients use option 77, but they don't have/support the 
> multiple user
> classes as defined in this latest revision.  This seems like 
> a very big
> interoperability problem for servers that are using this 
> option with W2K
> clients today.
> 
> Greg
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of The IESG
> Sent: Tuesday, October 10, 2000 2:16 PM
> To: IETF-Announce: ;
> Cc: RFC Editor; Internet Architecture Board; [email-masked]
> Subject: Protocol Action: The User Class Option for DHCP to Proposed
> Standard
> 
> 
> 
> 
> The IESG has approved the Internet-Draft 'The User Class Option for
> DHCP' <draft-ietf-dhc-userclass-10.txt> as a Proposed Standard.  This
> document is the product of the Dynamic Host Configuration Working
> Group.  The IESG contact persons are Erik Nordmark and Thomas Narten.
> 
> 
> Technical Summary
> 
> This document defines a DHCP option that is used by a DHCP client to
> optionally identify the type or category of user or applications it
> represents. The information contained in this option is an opaque
> field that represents the user class of which the client is a member.
> Based on this class, a DHCP server selects the appropriate address
> pool to assign an address to the client and the appropriate
> configuration parameters.  This option should be configurable by a
> user.
> 
> Working Group Summary
> 
> There was strong support for this option within the WG, and no issues
> were raised during the IETF Last Call.
> 
> Protocol Quality
> 
> This document has been reviewed for the IESG by Thomas Narten.
>

---

From: Bernie Volz <[email-masked]>
Date: Fri, 20 Oct 2000 11:26:19 -0400

While that would be nice, does it mean everyone will install it? No.

I think for server implementors, perhaps the best rule to follow is ignore
the option if it is malformed (and understand that it could easily be
malformed because of these older implementations). That might be the
quickest way to resolve the problem and get the draft out.

-----Original Message-----
From: Kostur, Andre [mailto:[email-masked]]
Sent: Friday, October 20, 2000 11:03 AM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
S tandard

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 20 Oct 2000 11:40:16 -0400

>knew that the option they were using could be subject to changes.

         Even if vendors chose to provide service packs/patches
         for DHCP clients, many customers will not apply them.
         And as a vendor of DHCP servers, I'm interested in making
         a DHCP server that works correctly whether or not an
         individual user has applied a service pack or not.

         I strongly believe that we need a way that we can tell in
         an unambiguous way if this is an old-style or
         correct-style userclass option.  If we can get that from
         the current userclass definition, then we are fine (more
         or less, though it would be nice if it were simple to
         understand).  If we can't, then I think we need a new
         option number or a new definition of "correct-sytle"
         userclass.  If we do a new option number, the old one
         will be around for years and years (not a value
         judgement, just a fact).

         Bernie's algorithm seems to work fine as long as the
         first user-class class length doesn't happen to be in the
         range of printable ascii.  Ignoring punctuation marks,
         the ascii space is 32 decimal, and numeric 0 is 48.  Both
         of these would seem to be reasonable values for a
         userclass class length, wouldn't they?  Or am I missing
         something.

         Cheers -- Kim

---

From: Bernie Volz <[email-masked]>
Date: Fri, 20 Oct 2000 11:58:42 -0400

Yes, the technique I suggested won't work for all cases. But I think it is
relatively safe as (1) I would suspect all alpha characters are more typical
and (2) shorter class names will be much more common.

Perhaps Microsoft can provide some input here as to what classes they
recommend or support - perhaps the configuration utilities only support a
limited character set and an upper length (<32).

It certainly is, IMHO, a better solution than assigning another option
number given that the available option space is rather small.

If you wanted to assure you have compatibility, perhaps a solution is to
have the new format insert a 0 byte as the first class string. Then, the
issues are we waste a byte and some small processing time and the only
reserved character for older style Microsoft implementations to avoid is the
0 (null) character.

- Bernie

-----Original Message-----
From: A. Gregory Rabil [mailto:[email-masked]]
Sent: Friday, October 20, 2000 11:45 AM
To: DHCPv4 discussion list
Cc: [email-masked]
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard

Unfortunately, I don't think it is possible to detect a 'problem'.  For
example, assume a User Class of the following:

!SomeThirtyThreeCharacterUserClass

Note that the '!' is a decimal 33.  Therefore, if the option code 77 was
followed by a length byte of decimal 34, then the above ascii string
(including the prefixed '!').  In this case, this is valid for both
formats of the UserClass option.  It appears impossible to determine if
the User Class is "SomeThirtyThreeCharacterUserClass" or
"!SomeThirtyThreeCharacterUserClass".

Regards,
Greg

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Friday, October 20, 2000 10:55 AM
To: [email-masked]'; DHCPv4 discussion list
Cc: [email-masked]
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard

While using a new option number is certainly a solution, it likely means
we'll have to keep the old one around forever.

As it should likely be fairly easy for a server to detect the difference,
perhaps that needs to be described in the draft/RFC ... I assume that
Microsoft's implementation is just to send the user class string in the
option. As this is likely to be ASCII, it should be easy for a server to
look at the received option and detect a 'problem' if the first class length
is greater than the option length (as that should not be possible). In that
case, it could assume that it is an old Microsoft client and use that option
format? Or, it would need to drop that option OR the entire packet as being
mal-formed.

- Bernie Volz

-----Original Message-----
From: A. Gregory Rabil [mailto:[email-masked]]
Sent: Friday, October 20, 2000 9:20 AM
To: DHCPv4 discussion list
Cc: [email-masked]
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard

Jerome,
Of course I understand that Microsoft's implementation long predated the
User Class as Proposed Standard.  My question goes more toward the fact
that although MS may update future clients, server vendors will likely
have to deal with W2K clients for quite some time anyway.  It seems that
it would have been prudent to select a new option number for the new
format, just to ease the transition, then phase out 77 and use it for
something else.

My $0.02,
Greg

-----Original Message-----
From: Jerome Privat [mailto:[email-masked]]
Sent: Friday, October 20, 2000 3:02 AM
To: [email-masked]'; [email-masked]
Cc: [email-masked]'
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard

Greg,

Implementation for existing Microsoft 2000 clients was written well before
the User Class was accepted as Proposed Standard (which just happenned now).
So it is normal it does not support what is in the spec now (the same is
true for other pre-standard implementations).

That being said, the syntax in the draft was discussed with people from
Microsoft (Ann Demirtjis at the time, who co-authored the draft). So I would
expect next versions of MS clients to adhere to the spec.

Jerome

Jerome Privat
Northstream AB

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, October 19, 2000 6:30 PM
To: [email-masked]
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
Standard

I apologize for the repost, but I hear crickets... anyone care to comment?

Greg

-----Original Message-----

Has anyone given thought to the implications involved with the existing
Microsoft Windows 2000 DHCP clients that use this option?  Specifically, MS
W2K clients use option 77, but they don't have/support the multiple user
classes as defined in this latest revision.  This seems like a very big
interoperability problem for servers that are using this option with W2K
clients today.

Greg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of The IESG
Sent: Tuesday, October 10, 2000 2:16 PM
To: IETF-Announce: ;
Cc: RFC Editor; Internet Architecture Board; [email-masked]
Subject: Protocol Action: The User Class Option for DHCP to Proposed
Standard

Technical Summary

Working Group Summary

Protocol Quality

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 20 Oct 2000 12:13:13 -0400

At 11:58 AM 10/20/00 -0400, Bernie Volz wrote:
>[...]

         I rather like this, though it always costs a byte.
         It *does* seem better than wasting another option number,
         or putting our heads in the sand and ignoring the problem.

         Of course, from a purist perspective, it is totally
         unnecessary and wasteful.  Unfortunately, neither I
         nor my customers live in a purist world.

         Cheers -- Kim

---

From: Steve Gonczi <[email-masked]>
Date: Fri, 20 Oct 2000 12:28:32 -0400

I rather like Bernie's solution.

The reserved character does not have to be zero, it could be any
character reserved for this purpose.

It would be nice to hear from MS to see if this would work for them.

/sG

>have the new format insert a 0 byte as the first class string.

---

From: Bernie Volz <[email-masked]>
Date: Fri, 20 Oct 2000 19:10:18 -0400

There is a benefit in using 0. From the draft:

	The value in UC_Len_i does not include the length field itself and
	MUST be non-zero.

So, 0 is not technically a legal class length for the option but would be in
this case as a filler (ie, no class specified).

We could either allow it as a length (meaning no class) or just REQUIRE it
as the first value if the new option format is in use.

Perhaps even a better approach ... if we assume that the class names (as
Microsoft has it implemented today) may NOT begin with a ASCII character
0..31, then we could even only require the special 0 byte if the length of
the first class in the class list is >31. That saves the extra byte and
likely means it would be extremely rare anyway.

- Bernie

-----Original Message-----
From: Steve Gonczi [mailto:[email-masked]]
Sent: Friday, October 20, 2000 12:29 PM
To: DHCPv4 discussion list
Subject: RE: Protocol Action: The User Class Option for DHCP to Proposed
S tandard

/sG