Subject: RE: ASCII text message option (option 56)

From: Nathan Lane <[email-masked]>
Date: Fri, 30 Jun 2000 13:32:04 -0500

> -----Original Message-----
> From:	Barr Hibbs [SMTP:[email-masked]]
> Sent:	Friday, June 30, 2000 1:28 PM
> To:	[email-masked]; DHCPv4 discussion list
> Subject:	RE: ASCII text message option (option 56) 
> 
> 
> > From: Nathan Lane
> 
> > But how does AAA work when the DHCP server has already denied any
> network
> > connectivity at all? Or placed you in a different class (i.e.,
> > more limited) of service than you expected?
> >
> I don't understand your point about class of service:  DHCP really doesn't
> support that functionality in the way I understand it (e.g., delay, packet
> loss, and bandwidth characteristics.)
> 
	[Nathan Lane]  DHCP the protocol does not.  DHCP how I configure it
does.  I have an internal CID specification that, in lieu of yet to be
widely deployed user-class option, can drive the DHCP server to allocate a
different range of IP addresses for certain classes of workstation.  I'd
like a message or way to direct a user to know why he can't access a certain
resource instead of generating a help desk call.  Many times, said user
cannot even access an authentication server, so this would have to be very
early in the process.

	Note that something similar can be done now with faking out DNS
servers to point to a "registration" web page or other clever things, but
this clubs the client over the head, so to speak.
>   
> > This option is ideal for it...I could put up a message saying "Oops, you
> > plugged your Mac into a network that doesn't have Appletalk turned on."
> >
> ...forgive me, Nathan, but how can DHCP do this, given that it is largely
> protocol independent?  I don't think we should be cognizant of anything in
> the protocol stack above the IP layer.
> 
	Isn't that up to me?  DHCP the protocol does not have to be
cognizant of it, but DHCP should be able to communicate what it did to a
device in a way that gets back to the actual user.  I see the "user message"
option more as a "this is why you didn't get an IP"; this new option as a
way to communicate what I mentioned above.

> > This option is something I can use right now, in any form and
> > applies to me both in the limited sense that Apple is doing it
> > and, if others  adopt it, I could apply it more generally.
> >
> start a web browser following Stuart's suggestion, but without an IP
> address, how does that work?)
> 
	User message (56) would be used in the case of a NAK, and therefore
the lack of an IP.  The new option would be used to communicate additional
information...in my view, directly related to the IP allocation that did
occur, but it needn't be.

	-Nathan

**********************************************************************
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 please notify the Wal-Mart E-mail administrator at
" [email-masked] ".
**********************************************************************