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

From: [email-masked]
Date: Thu, 13 Jul 2000 09:06:42 +0100

I suggest we don't enter the debate to decide whether the QoS
example is a good one or not. Let's take this example out and
use a less controversial one (such as the one you gave about
the 2 different printers).

If the WG agrees with this approach, I will update the draft
accordingly (this will be version -10 as there is already a version
-09 in the ID queue with a more correct formatting).
I will probably not have time to produce this new version before the
cut-off date (tomorrow). So I will submit it after the Pittsburg meeting.
Please also note that I cannot make the Pittsburg meeting, so if you
have any issues, please post them on this mailing list.

Jerome

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: 12 July 2000 19:53
To: [email-masked]
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