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

From: Nathan Lane <[email-masked]>
Date: Tue, 22 Aug 2000 14:15:45 -0500

[Thomas Narten]
> Hmm. What is the purpose of that option? Without knowing the history,
> I would think that option is to tell the server, "hey I was using
> address X before, if its OK with you, I'd like to get it again". Or
> something like that.
> 
> The general issue is that clients shouldn't care what addresses they
> get. I.e., any address should work. 
	  
	While I'd really, really like to believe this, it doesn't work that
way now because of things like 1918 addressing, roaming clients, NAT, etc.
Any address should work; but for what?  An autoconfiguration IP will work on
the local subnet with the specific prohibition that it never be routed past
the local subnet boundary.  A 1918 address will work within an enterprise,
but not without.  There must be a way for us to convey this information to
the addressing server for appropriate selection.
	  
> 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
	[...] The current (and previous ID) says
> absolutely nothing about this bigger issue.
> 
	Agreed; there is a much larger issue here that I feel should be
addressed.  As to whether or not this is the appropriate forum is the point,
isn't it?  When it comes down to the core of the issue, addresses are being
overloaded to mean different things from different perspectives of the
network.  While our lives would be made much easier if an address were
simply a 32-bit integer, they are not.  We do not have guaranteed end-to-end
connectivity anymore; the intelligence is both in the end point and the
network.

	Should this issue be addressed in this draft?  The last time this
came up in July, I believe the consensus was to remove references to address
selection;  I had also proposed that an IP address be considered an "option"
that could be selected by the DHCP server, though that may not be explicitly
correct.  Address selection in DHCP itself is only very loosely codified.
Also I noted that many people are using every bit of information they can
get from a client to determine what to do with them.

	[Thomas Narten]
> What some of the IESG objected to was the implication that the ID
> suggested using the client ID to assign addresses that had special
> characteristics associated with it *without* discussing in a fair
> amount of detail the implication of all this. For example, if a site
> was using diffserv, how do the packets from address X get mapped into
> special diffserv PHBs?
> 
	In product implementations I've seen these days there is a
tremendous amount of heuristics going on to "fake state with stateless
packets", label flows, "differentiate" service, etc.  None of these products
interoperate in any usable fashion, hence the great increase in single
vendor hardware and software shops.  The issue Thomas brings up is large,
much larger than the DHCP option we are discussing.

	[Thomas Narten]
> If I understand "how it is treated" to mean that some clients get
> different service than others, then we heading in the problematical
> direction. It is not DHCP's job to regulate what kind of service a
> client gets. Its DHCP's job just to configure the client with necessary
> parameters.
> 
	Correct me if I'm wrong, but aren't "necessary parameters" the
parameters that give the client the services that they need?  How do we then
tell the client to modify those parameters once the services they need are
no longer located where they once were or have changed function?  Is there
an overall, standardized mechanism for determining client service levels?
Most of the ones I have seen are not widely implemented and bring up even
larger issues (such as who controls the network?  Is the network smart and
the endpoints stupid or vice versa?)

	It's beginning to look like we may need a larger framework than just
DHCP for configuring clients but there are major disagreements as to how to
go about this.

	-Nathan Lane

**********************************************************************
This email and any files transmitted with it are confidential
and intended solely for the individual or entity to 
whom they are addressed.  If you have received this email 
in error destroy it immediately.
**********************************************************************

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Aug 2000 15:06:45 -0700

I really don't think we need to get into a jihad here about what
server administrators should or shouldn't do.   The option is useful,
without ever talking about differentiating classes of service, and
indeed I don't think that was ever the intention; rather, the
intention was to provide a way of differentiating between clients
based on the needs specified by the users of those clients; thus,
"user class."   It completely muddies the issue to bring all this
other crap in, and that's why this option has lingered so long on the
table.   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?

Thanks,

			       _MelloN_

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Aug 2000 17:56:25 -0400

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