Subject: RE: Possible ambiguity in definition of DHCP client identifier op

From: Steve Gonczi <[email-masked]>
Date: Tue, 2 Nov 1999 19:21:14 -0500 (EST)

Ted's interpretation makes sense. That is how I always read it.

RFC 2131 says on page 9:

"The 'client identifier' is an opaque key, not to be interpreted by the
server;"

RFC 2132 says on page 30:

"Identifiers SHOULD be treated as opaque objects by DHCP servers.
The client identifier MAY consist of type-value pairs similar to the
'htype'/'chaddr' fields defined in [3]. "

It seems clear (to me), that the "client identifier" 
is the whole payload of the option, and NOT just i1..in

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Tue, 2 Nov 1999 19:58:57 -0500 (EST)

I agree with Steve that a client identifier should be the entire data
payload of option 61 -- an opaque string whose composition should not be the
concern of the server.

I also think that the current RFC wording is a slight disservice to
implementors because some I've encountered read the text suggesting how to
construct a client identifier from hardware type and MAC address as a
requirement that only octet strings which can be decomposed into a hardware
type and address part are legitimate client identifiers.

--Barr

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Tue, 2 Nov 1999 20:35:31 -0500 (EST)

> type and address part are legitimate client identifiers.

Historically, a client id has always been an "opaque string" to the server. The
text suggesting how one might form one is just that - a suggestion. Folks were
asking for guidance on how one might form a client id, so we added the text. The
draft text seems very clear on this; I wonder if people are just used to seeing
client identifiers  of the ARP type + hardware address so much that they're
making incorrect assumptions about client identifiers.

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Tue, 2 Nov 1999 21:20:20 -0500 (EST)

Mike--

you always have good historical perspectives on these matters....

> Historically, a client id has always been an "opaque string" to the
> server. The text suggesting how one might form one is just that - a
> suggestion. Folks were asking for guidance on how one might form a client
> id, so we added the text. The draft text seems very clear on this; I
> wonder if people are just used to seeing client identifiers  of the ARP
> type + hardware address so much that they're making incorrect assumptions
> about client identifiers.
> 
--I can tell you for a fact that more than one vendor of clients believes
wholeheartedly that the only possible value for a client identifier is
constructed only from the hardware type and chaddr.  The example text is a
bit unfortunate because it is so easily misinterpreted.

--Barr

---

From: Bernie Volz <[email-masked]>
Date: Wed, 3 Nov 1999 09:47:39 -0500 (EST)

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.

- Bernie Volz
  Process Software

---

From: Nathan Lane <[email-masked]>
Date: Wed, 3 Nov 1999 10:49:57 -0500 (EST)

At least the largest one does as of service pack 2 or later - Windows NT 4.0.
When setting a CID that is different from the MAC address, t1 is 0.
Most embedded systems vendors don't let us change the CID, so they 
do the MAC thing that has been discussed.

-Nathan Lane
Wal-Mart Stores, Inc.
(501) 277-5786

> -----Original Message-----
> From:	Bernie Volz [SMTP:[email-masked]]
> Sent:	Wednesday, November 03, 1999 8:52 AM
> To:	Multiple recipients of list
> Subject:	RE: Possible ambiguity in definition of DHCP client identifier op
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Nov 1999 10:52:16 -0500 (EST)

> rules - specifying t1 as 0 if it is not a mac address.

Absolutely not, nor does the protocol require it.  Further, it's not
specified that cid==1:4a:2b:ac:19:ad means the same thing as
htype==1/hlen=6/chaddr==4a:2b:ac:19:ad:dc:dc:dc:dc:dc:dc:dc:dc:dc:dc
(dc == don't care).

If you want to collapse the lease database lookup key into a single
key value, which I think is reasonable, you really need to have some
kind of additional type that says where the key came from.   I would
suggest zero for htype/hlen/chaddr and 61 for dhcp-client-identifier.
Otherwise I think that your specification for the construction of a
key based on htype/hlen/chaddr is correct.

			       _MelloN_

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 3 Nov 1999 10:56:20 -0500 (EST)

Hi Bernie,

> Seems like most people feel the type is included as part of the client

No, I don't see this at all. The client identifier is an opaque string,
period. You can't make any assumptions about the contents.

> by mac address, you could be using <media-type>:<mac-address>.

I don't think collapsing these different attributes into one makes sense. Some
folks use a client-identifier which happens to be an asset tag number. In this
case, the client-identifier has no relationship at all to the mac address.
IMHO, I think you should revisit this decision.

> rules - specifying t1 as 0 if it is not a mac address.

What rules?

>   Process Software

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: Bernie Volz <[email-masked]>
Date: Wed, 3 Nov 1999 12:43:24 -0500 (EST)

>From RFC 2132, see ">>" lines. The text does use MAY, SHOULD, and
should. So, these are definitely not MUSTs.

9.14. Client-identifier

   This option is used by DHCP clients to specify their unique
   identifier.  DHCP servers use this value to index their database of
   address bindings.  This value is expected to be unique for all
   clients in an administrative domain.

   Identifiers SHOULD be treated as opaque objects by DHCP servers.

   The client identifier MAY consist of type-value pairs similar to the
   'htype'/'chaddr' fields defined in [3]. For instance, it MAY consist
   of a hardware type and hardware address. In this case the type field
>>   SHOULD be one of the ARP hardware types defined in STD2 [22].  A
>>   hardware type of 0 (zero) should be used when the value field
>>   contains an identifier other than a hardware address (e.g. a fully
>>   qualified domain name).

   For correct identification of clients, each client's client-
   identifier MUST be unique among the client-identifiers used on the
   subnet to which the client is attached.  Vendors and system
   administrators are responsible for choosing client-identifiers that
   meet this requirement for uniqueness.

   The code for this option is 61, and its minimum length is 2.

   Code   Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+---
   |  61 |  n  |  t1 |  i1 |  i2 | ...
   +-----+-----+-----+-----+-----+---

---

From: Eric Michelsen <[email-masked]>
Date: Wed, 3 Nov 1999 12:47:08 -0500 (EST)

> From: Mike Carney - SNT Internet Engineering
> [mailto:[email-masked]]
> Sent: Wednesday, November 03, 1999 7:57
> Subject: RE: Possible ambiguity in definition of DHCP client 
> identifier
> op
> 
> 
> 
> Hi Bernie,
> 

It *is* an opaque string.  And the string *includes* the "type" byte, which
means there is no distinction between the "type" byte, and any other byte.
The presence of a "type" byte is very confusing, because it suggests some
distinction when in fact there is none.  If the string is indeed "opaque,"
then all distinctions between bytes should be removed.

-------------------------------------------
Eric L. Michelsen, Copper Mountain Networks

---

From: Nathan Lane <[email-masked]>
Date: Wed, 3 Nov 1999 12:49:07 -0500 (EST)

> From:	Mike Carney - SNT Internet Engineering [SMTP:[email-masked]]
> Sent:	Wednesday, November 03, 1999 9:57 AM
	[Nathan Lane]  *I* can as an implementor of DHCP network services.  Section 9.14 of 2132 specifies "MAY" consist of type value pairs similar to htype/chaddr.  In the case where it is defined as type/value pairs, a data format is suggested.  My view is that the CID should be given to me via an externalized process or ruleset determined by me within the server.  I agree that the actual DHCP server itself should not assign any cosmic significance to any part of the CID save for the uniqueness within the subnet (perhaps we should change the word "subnet" to "administrative domain of the DHCP server" in 2132), but the server should be able to give the CID to my business rule that is abstracted from the server.  Cisco's product does this well with the TCL or C extensions that are possible with the product.

> IMHO, I think you should revisit this decision.
	[Nathan Lane]  An asset tag number or ToS definitions are the path we are going down until user-class is widely implemented.

> > rules - specifying t1 as 0 if it is not a mac address.
	[Nathan Lane]  Again, doesn't section 9.14 specify a suggestion for a rule?  Am I missing something here?

	-Nathan Lane
	Wal-Mart Stores, Inc.
	(501) 277-5786

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 3 Nov 1999 12:51:03 -0500 (EST)

Ted, et al.--

I am in agreement with Kim and you about the "opaque-ness" of the client
identifier, and I think the text could be revised to be more explicit.

> BTW, I don't know if it's possible at this late date, but I'd really
> like to see the text "the client MAY choose to explicitly provide the
> identifier through the 'client identifier' option" to "the client
> SHOULD choose to explicitly provide the identifier through the 'client
> identifier' option".   Right now I think client implementors tend to
> read this as saying that the client identifier is optional (that's
> certainly how I read it) and may not feel any real motivation to use a
> client identifier.   To say the least, the way client identifiers are
> currently handled is quite a bummer.   If I had my druthers, even
> though the ISC DHCP client doesn't currently implement it, I'd change
> this to a MUST, with a caveat that servers should allow for clients
> that don't supply client identifiers for backward compatibility.
> 
--I'd go a lot further than that!  Not only would I change the wording from
MAY to SHOULD, but I would add text strongly suggesting that whatever value
is chosen for the client identifier, it SHOULD NOT be something that can
easily change, such as a MAC address:  in my experience, one or two NICs
must be replaced every week in our client population, not to mention the
near-constant movement of roaming laptop users, whose MAC address changes
every time they change docking stations!

--Barr

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 3 Nov 1999 12:53:09 -0500 (EST)

Bernie, et al.--

we have a genuine difference of opinion about the composition of client
identifier.

I assert that the entire data payload of option 61 MUST be treated as an
opaque string, so the SUGGESTED encoding of <type><some-data> is erroneous:
I have lots of working examples of clients that send our server client
identifiers such as "63IDDZ100679" and "Mike's PC" just as I have examples
such as 01:00:DD:01:00:FC:DE.  Note that both of the former are "missing"
the type octet, while the latter does carry it.  Both types work "just fine"
because our server treats the entire data payload as an opaque string --
only humans read an encoding scheme into the data.

The drawing in RFC 2131 is unfortunate, because it gives the impression that
option 61 deviates from the general option format of <code><length><data>.
Think about what happens if you apply the interpretation of a distinct type
octet literally:

(1) when the type octet is an ARP type (such as Ethernet or Token-Ring) the
client identifier should be identically equal to the chaddr field.  If that
is truly the case, why do we have a client identifier?  It is completely
redundant in that case!  Worse, if the type octet matches an ARP type,
shouldn't that also imply the length of the remaining data?  What happens if
there is a mismatch?  Does that invalidate the following octets?

(2) if the type octet were 0, implying the remainder of the data is an
NVT-ASCII string, then that seems okay, but what value does that extra octet
offer?  The server MUST treat the client identifier as an opaque string, so
the encoding is pointless.

(3) what do we do with the following cases?
-- a character string encoded as UTF-8
-- a binary string that is not a hardware address

My assertion is that it is not only better, but essential to treat the
entire data payload of option 61 as an uninterpretable (i.e., opaque) value.

What this may do to you LDAP schema is another problem entirely.

--Barr

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 3 Nov 1999 12:55:11 -0500 (EST)

> key based on htype/hlen/chaddr is correct.
I agree with the need to identify the source of the key, but would suggest
that there are more than two possible values:  in my case, we have local
modifications that permit lookup of leases by hostname (soon to be changed
to FQDN, I think), so I think there are at least three values for the key
source.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Nov 1999 13:55:30 -0500 (EST)

That's not a rule - that's a suggestion.   The SHOULD is predicated on
a MAY, so it's only as strong as the MAY.   Personally, I've always
been allergic to the idea that the client-identifier's structure
should be documented at all, but I've been called crazy before... :')

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Nov 1999 13:59:10 -0500 (EST)

> to FQDN, I think), so I think there are at least three values for the key

This is pretty much what I was thinking when I suggested a code of
zero for chaddr and 61 for dhcp-client-identifier.  If you want to
(incorrectly! :') use something else as a client identifier, you could
stick its option code in the first byte of the key.  I'd suggest an
option code of 255 for a key that's neither the hardware address nor
a DHCP option.

Well, actually, I'd suggest not specifying any values other than 61
and 0, and leaving the other values for people to use, actually,
because if you put what I wrote in the previous paragraph into the
LDAP RFC, somebody's going to start claiming that values other than
chaddr and dhcp-client-identifier are blessed as client identifiers in
an RFC.

Actually^2, I'd make the identifier two bytes, to account for the
potentially upcoming transition to 2-byte option codes in DHCPv4NG.

Another advantage of this key :== identifier + data scheme is that it
lets us implement UUID support cleanly when/if it becomes a standard.

			       _MelloN_

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 3 Nov 1999 14:01:14 -0500 (EST)

>    'htype'/'chaddr' fields defined in [3].

9.14 is really confusing. That text was added later in the draft. The
combinations of SHOULD's MAY's, etc.... Geez.

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: Mike Carney - SNT Internet Engineering <[email-masked]>
Date: Wed, 3 Nov 1999 14:03:08 -0500 (EST)

Hi Nathan,

> 	[Nathan Lane]  *I* can as an implementor of DHCP network services.  Section
> 9.14 of 2132 specifies "MAY" consist of type value pairs similar to
> htype/chaddr.  In the case where it is defined as type/value pairs, a data
> format is suggested.  My view is that the CID should be given to me via an
> externalized process or ruleset determined by me within the server.  I agree
> that the actual DHCP server itself should not assign any cosmic significance
> to any part of the CID save for the uniqueness within the subnet (perhaps we
> should change the word "subnet" to "administrative domain of the DHCP
> server" in 2132), but the server should be able to give the CID to my
> business rule that is abstracted from the server.  Cisco's product does this
> well with the TCL or C extensions that are possible with the product.

Sorry - by "You can't" I was speaking from a DHCP server's perspective.
Whether a user / admin choses through administrative/site policy to assign
some special significance to the bits in the client identifier used is fine.
The point I was trying to make was that the clent identifier is opaque from a
protocol perspective.

> Am I missing something here?

It's a suggestion for forming a client identifier - not a "rule"

Mike Carney
SNT Internet Engineering
Sun Microsystems, Inc.
Mailstop UBUR02-212
One Network Drive
Burlington, MA 01803

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 3 Nov 1999 14:05:19 -0500 (EST)

Ted, et al.--

as always, you have cogent comments, but "actually" squared?  hehehe....

> Another advantage of this key :== identifier + data scheme is that itI
> must not have clearly worded my comments....  I am NOT suggesting that we
> somehow try to fit lots of other vlues/encodings/fields into
> client-identifer, but rather that if an LDAP schema proposes that an index
> into a table of leases be coded as to the source of the index value
> (htype/chaddr and client-identifer as the initial sources proposed) then
> there are probably more choices, depending on local implementations.
> 
> This is not the same thing as saying that some other value is to be used
> by the server to identify a lease for assignment purposes -- I'm not
> proposing that at all.  For historical reasons and corporate culture, I
> must provide a way to find leases based on hostname, but all I offer is a
> display of lease information -- I don't substitute option 12, or a
> combination of options 12 and 15, for either the client hardware address
> or client identifier for address assignment, and I'm not proposing any
> changes to RFC 2131.  I'm simply observing that there are other ways in
> which organizations and individuals might like to use to find a lease, so
> it seems appropriate to provide a means to identify more than two sources
> for a key.
> 
> 
Actually, the Intel-originated RFC for UUID is current, although it has a
sunset date of about 2003, so maybe option 97 is already a valid source
indicator.

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Nov 1999 14:07:13 -0500 (EST)

> as always, you have cogent comments, but "actually" squared?  hehehe....

Look, if I don't break the language, somebody else is going to have
to!

> sunset date of about 2003, so maybe option 97 is already a valid source

Yes, but it needs to be made officially part of the protocol (my vote
would be in DHCPv4NG).  Either that, or in DHCPv4NG we should make the
client identifier and UUID the same (I would actually prefer this, but
in some cases a UUID may be difficult to come up with - e.g., in a
kernel that's using DHCP to get an IP address before it's mounted a
root filesystem).

			       _MelloN_

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 3 Nov 1999 15:09:52 -0500 (EST)

Ted, et al.--

the latter bit, about a kernel using DHCP, is precisely what Intel's PXE
specification is about.

I, too, would like a globally unique identifier, but I wonder if we would
break existing behavior in an unfriendly way to replace the current
requirements of client identifier.

You've convinced me that I must take the time to write a new I-D proposing
some changes to the client identifier, which I should be able to distribute
before the WG meeting.

--Barr

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Wed, 3 Nov 1999 15:14:03 -0500 (EST)

> should be documented at all, but I've been called crazy before... :')
agreed: by documenting one possible way to construct a client identifier,
we've led lots of people astray....

--Barr

---

From: Bernie Volz <[email-masked]>
Date: Thu, 4 Nov 1999 08:55:56 -0500 (EST)

>by mac address, you could be using <media-type>:<mac-address>.

Actually, Andy corrected me on this item. The text in the schema draft
was intended to mean that for a client identifier, when it is stored you
prefix it by 00:, just as for a MAC address, you prefix it by the
hardware type field. The client identifier is treated as opaque (not
assumed to have a type field); hence one is added when stored, and
removed when processed. We'll clarify this in the next revision.

- Bernie Volz
  Process Software

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Nov 1999 11:12:41 -0500 (EST)

> removed when processed. We'll clarify this in the next revision.

Hm.   Okay, but this has the same problem: you're confusing ARP types
and non-ARP types in the same identifier.   Why not have an identifier
that says where the key came from, followed by the contents of the
key, which for a client-identifier option would be the opaque data,
and for the chaddr would be the ARP type, followed by bytes zero
through hlen of the DHCP chaddr field?   This would allow us to
unambiguously represent UUID (or any nonstandard key that the server
might decide to use) when that becomes necessary.

			       _MelloN_

---

From: Steve Gonczi <[email-masked]>
Date: Thu, 4 Nov 1999 12:19:03 -0500 (EST)

If I am reading this right, it means that we always prefix a client
identifier
with 00: when stored as an LDAP attribute.

This has nothing to do with prior dicussion of the construction rules of the
payload of 
the DHCP client ID option. 

A client may very well choose to construct the payload in a similar fashion.
We add the 
prefix 00: _when_stored_as_an_LDAP_attribute.

sG
-----Original Message-----
From: Bernie Volz [mailto:[email-masked]]
Sent: Thursday, November 04, 1999 8:57 AM
To: Multiple recipients of list
Subject: RE: Possible ambiguity in definition of DHCP client identifier
op

- Bernie Volz
  Process Software

---

From: Steve Gonczi <[email-masked]>
Date: Thu, 4 Nov 1999 12:21:09 -0500 (EST)

The LDAP representation is _Always_ prefixed by an appropriate
classification byte, indicating the origin.
This is part of the LDAP schema rules, hence it is done consistently by the
storing agent.

Arguably, it would be neater to use a separate argument to classify the ID,
or, at the very least use a 2 byte prefix. 

sG

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Thursday, November 04, 1999 11:16 AM
To: Multiple recipients of list
Subject: Re: Possible ambiguity in definition of DHCP client identifier
op

			       _MelloN_

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Nov 1999 12:21:46 -0500 (EST)

> or, at the very least use a 2 byte prefix. 

Works for me, as long as we retain a requirement that there be exactly
one key.

			       _MelloN_

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Thu, 4 Nov 1999 13:09:25 -0500 (EST)

I agree with Ted's suggestion regarding identifying the source of the key...

--Barr

> Why not have an identifier that says where the key came from, followed by
> the contents of the key, which for a client-identifier option would be the
> opaque data, and for the chaddr would be the ARP type, followed by bytes
> zero through hlen of the DHCP chaddr field?   This would allow us to
> unambiguously represent UUID (or any nonstandard key that the server might
> decide to use) when that becomes necessary.
> 
>

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Thu, 4 Nov 1999 13:11:23 -0500 (EST)

> Works for me, as long as we retain a requirement that there be exactly
..works for me as well...  with the additional suggestion that the
classification argument ought to be obvious, such as 61 for client
identifier or 97 for UUID...

--Barr

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Nov 1999 13:12:42 -0500 (EST)

> with 00: when stored as an LDAP attribute.

I think you and Bernie are saying the same thing, and I think it's not
the right thing to do.  What you're saying is that if you use the
client identifier as the key when you store it in LDAP, the first byte
of this key is always zero.  If you use the MAC address, the first
byte is the htype field of the DHCP packet and the subsequent bytes
are the significant bytes of chaddr.

What is missing from this is the possibility of having a key that is
derived from anything other than the client hardware address or the
client identifier.  And yet we already have identified the UUID as a
possible alternative option to use as a key, and some people use the
hostname option as the key as well.  It would be nice to be able to
represent these cleanly in an LDAP entry.

So I am proposing that we change the algorithm so that the first byte
(or two bytes, preferably) are a type code, and subsequent bytes are
the payload.  So if the client identifier is used as a key, we'd use a
type code of 61 (btw, Barr and Nathan, you have this as 63 in your
draft), and the rest of the key would be the payload in the client
identifier option.  If we use the hardware address, we'd use a type
code of 0, followed by the htype and hlen bytes of chaddr.  If we use
the UUID, the type code would be the DHCP option code for UUID (I
can't remember what it is) and the rest of the key would be the
payload of the UUID option.  Likewise with the hostname option:

chaddr:		00 00 htype chaddr [0..hlen]
client-id:	00 3D option payload
uuid:		?? ?? option payload
hostname:	00 12 option payload

By doing this, we maximize flexibility, at a fairly low cost.

			       _MelloN_

---

From: Andy Bennett <[email-masked]>
Date: Thu, 4 Nov 1999 13:52:15 -0500 (EST)

Ted is right and I think his proposed representation is an improvement -
I'll change it in the next revision to the schema draft.

Andy

> Sent: Thursday, November 04, 1999 1:13 PM

---

From: "HIBBS, BARR (PB)" <[email-masked]>
Date: Thu, 4 Nov 1999 14:43:38 -0500 (EST)

> By doing this, we maximize flexibility, at a fairly low cost.
Agreeing with Ted, I like using fairly obvious values for the key type, such
as 61 for client identifier, 97 for client machine identifier (UUID), 12 for
hostname, 60 for vendor class identifier, etc., with code zero reserved for
a construct based on chaddr, htype, and hlen.

This is not a sneaky attempt to declare something other than client
identifier or chaddr to be the index for specifying a lease by the server or
client, just observing that there are other useful ways to find information.

--Barr

---

From: Nathan Lane <[email-masked]>
Date: Thu, 4 Nov 1999 16:50:52 -0500 (EST)

> > draft), and the rest of the key would be the payload in the client
	[Nathan Lane]  Thanks for pointing that out.

> a construct based on chaddr, htype, and hlen.
	I like this as well, giving everyone the ultimate in flexibility at a very small cost in added complexity.

	-Nathan Lane

---

From: "Henry, Mike" <[email-masked]>
Date: Fri, 5 Nov 1999 20:27:31 -0500 (EST)

A long time ago (1997) we submitted a request to IANA for two new options
and a proposal to add a new "type" to option 61.  The new type was to be of
the "UUID" variety.  IANA was confused by the request for an option 61 type
definition, and as we were not making any progress on getting clarification
on the use or meaning of the "type" field within option 61, we proposed, and
were issued, a new UUID Client Identifier option (Option 97). So, as a
result of this interaction with IANA we were issued DHCP Option numbers 93,
94, and 97.

Subsequently we submitted a draft that defined the use of these new options.
This caused two problems: first, the DHCP working group did not like the
options because they felt that the same functionality could be gained
through the combined use of options 60 and 61, and second, it brought to a
head the general discomfort caused by issuing option numbers before defining
or authorizing their use.

We agreed with the second concern but did not agree with the first (i.e. we
felt there were significant problems with using options 60 and 61 as
suggested by the working group), but nevertheless we agreed to phase out use
of options 93, 94, and 97 over a period of six years.  The definition of
these options and the agreement for their phase out is documented in this
ID:
http://search.ietf.org/internet-drafts/draft-dittert-host-sys-char-03.txt

Sometime after this I wrote an ID defining a "UUID" type for Option 61 (this
draft has expired).  This ID was greeted with mixed reviews, and I have to
admit I did not quite understand the reservations.  These reservations are
clearer now that I have followed this particular mail thread.  The  upshot
of this thread seems to be that, in spite of pretty clear text to the
contrary (see Option 61 text below), a significant number of people appear
to be suggesting that Option 61 does not have "types", and that the "type"
field is (or perhaps is not) part of the identifier proper, and even if the
option text says there are types, well.... there aren't. And, even if there
are, no one uses them, so this is more or less the same thing.  Its
difficult to debate this position other than to present the actual text of
the option. (BTW, this ambiguity about "type" was one of our reservations
about using option 61 in the first place to in some way "mean" an identifier
of type UUID.)

Ted's suggestion (below) to use the option number as the first field in the
LDAP entry makes a certain amount of sense if you accept that Option 61 has
no types.  However, if Option 61 were used as literally written (i.e. making
use of the "type" field for "types"), it seems to me there would be no
problem.  The first byte would be the "type of identifier and the rest would
be the identifier proper. UUID would be represented by it's Option 61 "type"
(I suggested 254 in the ID I believe) as would the various ARP types. This
seems simple. What am I missing?

BTW, I do not believe the "type" field should be interpreted as part of the
identifier proper.  Again, I think the Option 61 text is pretty clear on
this point (min length of 2, type field nomenclated differently than the
Identifier field).

 - Mike Henry

----Option 61 text----------

9.14. Client-identifier

> Sent: Thursday, November 04, 1999 10:13 AM