Re: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt

On Mar 15, 2004, at 5:09 PM, Richard Barr Hibbs wrote:
> So, my proposal for this draft is that it should define a
> NEW DHCPv4 option, to be used IN PLACE OF 'client
> identifier' option 61 where interoperability with DHCPv6 is
> required or anticipated.

I must respectfully disagree.   This will create huge interoperability 
problems.   Really, what will happen is that nobody will ever implement 
it.

I am sorry to hear that the conference call came to a decision that was 
in conflict with this draft, but it has been the intention in writing 
the draft to fix the DHCP client identifier, not break it.   Adding a 
new DHCP option that serves the same purpose would break it.

> First, a DHCPv6 DUID is intended to be globally unique,
> while a DHCPv4 'client identifier' is not [from section 9

The 3315id draft fixes this bug in RFC2131/RFC2132.   This is very much 
one of the intended outcomes of the adoption of this draft.   I don't 
see any benefit to perpetuating this bug.

> ignore the 'client identifier' option and use the client's
> hardware address instead.  A clarification of the RFCs seems
> in order.

The 3315id draft makes such a clarification.

> [from section 9.14 of RFC2132, "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...."]

If you conform to the 3315id specification, the client identifier MUST 
NOT be of this form.

>  1. the 'client identifier' is an opaque octet string [not
>     null terminated] from which a DHCPv4 server SHOULD NOT
>     infer or expect any structure.

In the abstract, I think this is a fine thing to say.   However, if 
clients conform to the 3315id draft, this definitely isn't correct.   
If the changes specified in the 3315id draft are folded into the 
replacement for RFC2131/2132, I don't see any benefit to retaining this 
old language with respect to conforming client identifier options.   
Backward compatibility is of course still needed, and I don't mind 
saying that for cases where the 3315id-style identifier is not sent by 
the client, the server should treat the identifier as opaque.

I think the other three points are fine - of course the format of the 
option should be specified in only one place, and of course the two 
RFCs should be consistent in their use of the option.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg