Subject: I-D ACTION:draft-ietf-dhc-userclass-10.txt

From: [email-masked]
Date: Tue, 22 Aug 2000 07:07:23 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

	Title		: The User Class Option for DHCP
	Author(s)	: G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri,
                          A. Demirtjis, B. Beser, J. Privat
	Filename	: draft-ietf-dhc-userclass-10.txt
	Pages		: 5
	Date		: 21-Aug-00
	
This option 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.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-10.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-dhc-userclass-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-dhc-userclass-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: [email-masked]
Date: Tue, 22 Aug 2000 17:48:20 +0100

Thomas,

Would the following changes make the ID more acceptable by the IESG?:

> Abstract
would become
Abstract
 
    This option 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.
    A DHCP server may, based on its administrator policy, use this class
    to select the configuration parameters it returns to the client.

and
> 4. User Class option
>    A DHCP server uses the User Class option to choose the address pool
>    it allocates an address from and/or to select any other
>    configuration option.
would become
     This option is used by a DHCP client to optionally identify the type
     or category of user or applications it represents.
     A DHCP server may, based on its administrator policy, use the User
     Class option to select the configuration parameters it returns to
     the client.

Jerome

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: 22 August 2000 17:30
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt 

> This last sentence again suggests that the address a DHCP server gives
> out may depend on the provided user class.

Maybe I'm being a space cadet here, but why is this a problem?   The
IP address the server gives out also depends on the DHCP Requested
Address option in some cases!   It's perfectly reasonable for the
client to request things, and what the server does depends on policy.
What is it about this that needs to be fixed?

Maybe the thing we want is to say that the client can "request"
variations in how it is treated based on the user class option, and
that whether or not the server honors these requests, and how, is a
decision that should be left up to the server administrator.

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Tue, 22 Aug 2000 21:54:08 -0400

You should send admin requests to [email-masked]; e.g.,
to unsubscribe, send e-mail containing the message "unsubscribe dhcp-v4"

- Ralph Droms

At 05:10 PM 8/22/00 -0700, Monika (Maria) Dorough wrote:
>Someone pleeaaze tell me how to get off this listserve!!!!!

---

From: Eric Michelsen <[email-masked]>
Date: Thu, 24 Aug 2000 10:59:15 -0700

I am totally stunned by this discussion.  The userclass is simply a
convenience for network administrators.  It can be used for a huge set of
things, many of which we can't even think of yet.  Therefore, there are no
"implications" one could describe for how it might be used, because
different uses have totally different implications.

But who cares, anyway?  Administrators are responsible for the implications
of all the decisions they make on their networks.  This is no different than
any one of a thousand other decisions administrators make.  And in fact,
userclass is far less insidious than trying to get your firewall filters set
properly.

I don't understand the big deal.  Userclass is useful, and it hurts no one.
If you're an idiot, you can confuse your network with it.  Isn't that true
of nearly ALL DHCP parameters?

...
> The general issue is that clients shouldn't care what addresses they
> get. I.e., any address should work.

The clients may not care.  It's probably the network administrators that
care.

> Anytime the DHCP server uses
> something like the client ID to influence what address is given out,
> the implication is that different addresses are used in different ways

Sorry, but this is hogwash.  The addresses are used for the administrator's
convenience.  I worked on a network where routers were *.1, engineering was
*.10-*.29, marketing was *.80-*.99, and the dial-in server was *.254.  The
numbering was simply a convenience for the administrator.  This is a total
non-issue.

> If I understand "how it is treated" to mean that some clients get
> different service than others, then we heading in the problematical
> direction.

I agree that the wording should refer only to configuration, because that is
what DHCP does: it configures.  The wording should NOT refer to IP address
specifically, because it is just part of configuration.  But the
implications of that configuration is entirely the responsibility of the
network administrator, and in many ways, far beyond DHCP.  This draft is not
supposed to be a tutorial on IP pitfalls.

---

From: Bernie Volz <[email-masked]>
Date: Mon, 28 Aug 2000 10:57:05 -0400

Isn't an IP Address a "configuration parameter"? I think that would cover it
- we don't explicitly state what can and can not be configured via this
option -- that is policy.

So simply saying that the user class option may be used by the server to
determine the configuration parameters it returns to the client ought to do
it?

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 5:56 PM
To: DHCPv4 discussion list
Cc: DHCPv4 discussion list
Subject: Re: FW: I-D ACTION:draft-ietf-dhc-userclass-10.txt

Thomas - we seem to be at something of an impasse here.  The current 
version of the draft says nothing specific about how the IP address and 
configuration parameters selected for a particular client might be used and 
doesn't explicitly mention differential service in any way.  Similar 
mechanisms are used by DHCP servers today to choose an IP address based on 
other selection criteria.  How can we work around the specific objections 
to the user-class option?

One suggestion is to eliminate the reference to IP address in the user 
class draft, restricting its application to configuration parameters (in 
options) and specifically excluding the choice of IP address based on user 
class.  We would need to gain WG consensus for that change.

- Ralph

At 03:06 PM 8/22/00 -0700, Ted Lemon wrote:
>Can we please just blow off the differential service issue
>and admit that this option has perfectly valid uses regardless of that
>issue and needs to be finished?
>
>                  _MelloN_