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

From: Nathan Lane <[email-masked]>
Date: Fri, 14 Jul 2000 12:13:54 -0500

> -----Original Message-----
> From:	Ted Lemon [SMTP:[email-masked]]
> You can't use it as a credential - if you
> have to look the credential up on the server, there's no point in the
> client sending it.
> 
	I actually hadn't intended to imply I was going to use it as a
credential.  In a situation where a user class is valid on network A, but
not network B, there would have to be a mechanism to choose not to apply the
user class.  I chose unfortunate wording of "look it up", implying an
external credential data store.

	Would it be a bad thing to validate the user class for applicability
at least?  We wouldn't want people breaking their machines.

	These are off topic for the draft, though so if anyone has thoughts,
I'd like to hear them off-line.

	-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: "Barr Hibbs" <[email-masked]>
Date: Mon, 17 Jul 2000 10:19:43 -0700

[Ted Lemon]
> > You can't use it as a credential - if you have to look the
> > credential up on the server, there's no point in the
> > client sending it.

[Nathan Lane]
> credential.  In a situation where a user class is valid on
> network A, but not network B, there would have to be a mechanism
> to choose not to apply the user class.
>
> Would it be a bad thing to validate the user class for
> applicability at least?

[Barr Hibbs]
In general, this is an implementation decision:  what to do when an unknown
User Class Identifier is presented?  This is quite important when trying to
build a robust server implementation, but very difficult to completely
specify in an RFC.  While we could try to insert language in every RFC
covering the protocol and options requiring servers to adequately cover all
cases of valid and invalid (or unknown) values for options, but that would
be largely hollow.

If anyone can offer some practical wording for handling these cases, but
which does not unduly restrict current or future implementors by
overspecifying, I would definitely support its inclusion.

--Barr