Subject: Re: Possible ambiguity in definition of DHCP client identifier

From: Kim Kinnear <[email-masked]>
Date: Wed, 3 Nov 1999 09:54:36 -0500 (EST)

I too believe that the client-identifier is the *entire* payload
of the client-identifier option, and that it is opaque to the
DHCP server.

I think the draft is reasonably clear on this point, but that
doesn't mean that it couldn't be made even more clear -- which
would probably be a good idea.

Cheers -- Kim

---

From: Kim Kinnear <[email-masked]>
Date: Wed, 3 Nov 1999 10:54:22 -0500 (EST)

At 09:49 AM 11/3/99 -0500, Bernie Volz wrote:
>Seems like most people feel the type is included as part of the client
>identifier ... 
>
>In the DHCP LDAP Schema draft we've "collapsed" mac-address and
>client-identifier into one attribute (dhcpclientidentifier). The idea
>was that since the client identifier should be prefixed by 0, if it
>was not a hardware address, as specified in RFC2132, we could simply
>combine these fields. That way, if you wanted to identify a client
>by mac address, you could be using <media-type>:<mac-address>.
>
>So, the question is ... does everyone (client implementation) follow the
>rules - specifying t1 as 0 if it is not a mac address.

         I think the only rule about the content of the
         client-identifier is that there *aren't* any rules about
         content of the client identifier -- isn't that what
         "opaque" means?  The only rule is that they must be
         unique within an adminstrative domain.

         There are certainly suggestions, but no rules about the
         form of the content -- at least as I understand it.  So
         we can't depend on *any* specific content in the
         client-identifier.

         And, in fact, I've seen client-identifiers which contain
         all sorts of stuff, strings of various types, etc. etc.

         Cheers -- Kim

>- Bernie Volz
>   Process Software