Re: I-D ACTION:draft-ietf-dhc-userclass-00.txt

["Michael J. Lewis" <[e-mail]>]

I have another variant on the User Class option that I'd like to
present.

At Chevron, we have a large number of mobile notebook clients as well as
a larger number of stationary desktop clients.  We need to be able to
vary lease lengths to these two different classes of users with the 
desktops getting longer leases vis-a-vis the notebooks.  We obviously
can accomplish this with the current User Class definition.

We are finding, however, that more of our mobile users are also
utilizing their notebooks directly as "desktop" machines.  That is,
rather than having a separate desktop at their home office (or a docking
station), our users are simply plugging their notebooks into the home
network just as they would at another site.  This creates a problem in
that their user class at the home site is still "Notebook" and
consequently, they would receive the shorter lease.

What we'd really like is the means to determine that a notebook is
"visiting" rather than at home.  In the visiting case, the notebook
would receive a shorter lease while at home, it would get the standard
"long" lease.  One way we've conceived of doing this is by setting the
user class of each client to its home location; that is machines from
one location are given user class LOCATIONA, those from another
LOCATIONB, etc.  On each server, we would define each of the locations
setting shorter leases for the visiting sites.  While this would conform
to the presented draft, it would be a maintenance problem for a company
like ours that has hundreds of sites.

A cleaner (at least administratively) approach for us would to assigned
a user class to servers as well and then use a mismatch of server and
client classes to indicate a visitor.  That is, servers would also be
assigned classes based on location.  When a machine from LOCATIONA
entered the subnet handled by the server in LOCATIONB, the mismatch
indicates the client is a visitor and consequently a shorter lease 
would be required.  In typing this, it crosses my mind that this server 
class might need to be a subnet option as in a multi-subnetted building,
it is possible for a visitor to be someone from another floor plugging
into a conference room port.

>From reading the draft on user class and previous drafts/RFCs, I don't
believe what I'm suggesting is currently legal.  Is this something that
others might use/require as well?  Are there other ways of handling 
visiting notebook problems?  

Thanks.



[e-mail] wrote:
> 
> --NextPart
> 
>  A New Internet-Draft is available from the on-line Internet-Drafts
>  directories. This draft is a work item of the Dynamic Host Configuration
>  Working Group of the IETF.
> 
>        Title     : The User Class Option for DHCP
>        Author(s) : G. Stump, R. Droms
>        Filename  : draft-ietf-dhc-userclass-00.txt
>        Pages     : 4
>        Date      : 11/15/1996
> 
> This option is used by a DHCP client to optionally identify the type or
> category of user or applications it represents.  The information contained
> in this option is an NVT ASCII text object that represents the user class
> of which the client is a member.
> 
> Internet-Drafts are available by anonymous FTP.  Login with the username
> "anonymous" and a password of your e-mail address.  After logging in,
> type "cd internet-drafts" and then
>      "get draft-ietf-dhc-userclass-00.txt".
> A URL for the Internet-Draft is:
> ftp://ds.internic.net/internet-drafts/draft-ietf-dhc-userclass-00.txt
> 
> Internet-Drafts directories are located at:
> 
>      o  Africa:  ftp.is.co.za
> 
>      o  Europe:  nic.nordu.net
>                  ftp.nis.garr.it
> 
>      o  Pacific Rim: munnari.oz.au
> 
>      o  US East Coast: ds.internic.net
> 
>      o  US West Coast: ftp.isi.edu
> 
> Internet-Drafts are also available by mail.
> 
> Send a message to:  [e-mail]. In the body type:
>      "FILE /internet-drafts/draft-ietf-dhc-userclass-00.txt".
> 
> NOTE: The mail server at ds.internic.net can return the document in
>       MIME-encoded form by using the "mpack" utility.  To use this
>       feature, insert the command "ENCODING mime" before the "FILE"
>       command.  To decode the response(s), you will need "munpack" or
>       a MIME-compliant mail reader.  Different MIME-compliant mail readers
>       exhibit different behavior, especially when dealing with
>       "multipart" MIME messages (i.e., documents which have been split
>       up into multiple messages), so check your local documentation on
>       how to manipulate these messages.
> 
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version
> of the Internet-Draft.
> 
> --NextPart
> Content-Type: Multipart/Alternative; Boundary="OtherAccess"
> 
> --OtherAccess
> Content-Type:  Message/External-body;
>         access-type="mail-server";
>         server="[e-mail]"
> 
> Content-Type: text/plain
> Content-ID: <[e-mail]>
> 
> ENCODING mime
> FILE /internet-drafts/draft-ietf-dhc-userclass-00.txt
> 
> --OtherAccess
> Content-Type:   Message/External-body;
>         name="draft-ietf-dhc-userclass-00.txt";
>         site="ds.internic.net";
>         access-type="anon-ftp";
>         directory="internet-drafts"
> 
> Content-Type: text/plain
> Content-ID: <[e-mail]>
> 
> --OtherAccess--
> 
> --NextPart--