Subject: RE: draft-ietf-dhc-userclass-08.txt

From: Bernie Volz <[email-masked]>
Date: Wed, 12 Jul 2000 15:22:26 -0400

Thomas, et al:

>The issue is that this isn't done today, and is not where QOS (ala
diffserv) is heading.

I wonder what world the IESG lives in? While I would question whether this
option would be used to do this, this is exactly what several companies
we've been dealing with want to do. But again, this may be a useless debate
since using this option is not how they intend to do this.

Since this option is supposed to be configured by the "user", I agree that
it is much more useful for setting other options, such as the default
printer, etc. I think this makes for a perfectly good example and is useful.

It might also be used to indicate the type of system. For example, a
"laptop" is more likely to be mobile and therefore giving it a shorter lease
has value (desktop systems can have longer leases).

I am a bit surprised that the IESG didn't find the option name bad. DHCP is
for giving client systems addresses, not users. While in today's world it is
pretty common for the same user to use the same system day in and day out,
that is by no means certain. But, what's in a name after all?

In summary, I'd suggest your second approach.

- Bernie Volz
  IPWorks, Inc.

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Wednesday, July 12, 2000 2:53 PM
To: DHCPv4 discussion list
Cc: [email-masked]; Ralph E. Droms
Subject: draft-ietf-dhc-userclass-08.txt

Folks:

The IESG has been discussing this document and some of the wording  in
it has attracted some attention. Specifically:

> 1. Introduction
 
> It is often desirable to provide different levels of service to
> different users of an IP network.  In order for an IP network to
> implement this service differentiation, it needs a way to classify
> users. A simple solution to this is to use source IP addresses for
> classification.  Under this scheme, network administrators first
> configure network devices such as routers to recognize traffic from
> a particular source IP address (or address range) and handle it
> specially to meet the desired level of service. Next, they assign
> the IP addresses to the hosts of the intended users so that the user
> will receive the appropriate level of service.

The issue is that this isn't done today, and is not where QOS (ala
diffserv) is heading. RSVP also has a different model. Finally, it has
been stated that the above is not a reflection of real deployments
today. So, the motivational introductory text is problematic and
possibly out of touch with reality.

Then, the security considerations section points out that without
authentication, doing the above is dubious anyway (which leads the
IESG to wonder what this option is really good for). So again, using
this as an example is far from ideal.

My guess (which may be wrong) is that this is not actually what the
primary usage of this option is intended for. I thought it was more
for configuring all the folks in the accounting department to use a
different printer than the folks in marketing.

I see two ways out:

1) Make it clear what the real relationship between this DHCP option
   and related QOS mechanisms. Note that even making this clear will
   probably still not leave the IESG happy, given the reasons cited
   above. So if this is the approach the WG wants to take, we should
   discuss first.

2) take the example out and use a more appropriate one.

Comments?

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Wed, 12 Jul 2000 15:37:50 -0400

Hi Bernie.

> I wonder what world the IESG lives in?

You aren't the first person to wonder that. :-)

> While I would question whether this option would be used to do this,
> this is exactly what several companies we've been dealing with want
> to do.

I think the issue is scalability. So while some folks may think it
makes sense to do QOS based on IP addresses if they haven't thought
through it in a lot of detail, it's not clear that its used in
anything other than very restricted environments. It certainly isn't
used in backbones.  But as you say, debating this point is probably
academic.

Thomas