FW: [dhcwg] Question about 3315id-for-v4

-----Original Message-----
From: Richard Barr Hibbs [mailto:rbhibbs@pacbell.net]
Sent: Wednesday, 21 April 2004 09:13
To: Ted Lemon
Subject: RE: [dhcwg] Question about 3315id-for-v4

comments in-line

--Barr

> -----Original Message-----
> From: Ted Lemon
> Sent: Tuesday, 20 April 2004 17:35
>
> On Apr 20, 2004, at 8:58 AM, Ralph Droms wrote:
> > Is there some other way in which the use of the
> > DHCID RR can be defined to avoid requiring the
> > parsing of any client identification (either
> > DHCpv4 or DHCPv6)?
>
> No.   During the last call both Bernie and Barr
> expressed a wish that we could do this, and we
> discussed and rejected a method for doing this.
> The problem is that the only way to make it so
> the server doesn't have to parse the identifier
> is to add an additional identifier option, and
> if we do that, clients supporting the new
> identifier style will not interoperate with
> servers that do not in some cases.
>
...I'll take another look at the DHCID RR, the DNS update
I-D, and the proposed change to the client identifier today
to see if we may have been too quick to reject proposed
solutions.

> The only objection I can think of to the server
> parsing the client identifier option is that we
> have historically said the client identifier is
> opaque.  However, there is a good reason to
> break with this tradition, and I don't see how
> doing so would create an interoperability
> problem.  So if we try to keep this tradition,
> we break interoperability with old servers.  If
> we break this tradition, we do not.   So I
> think we have to use the IAID+DUID form of the
> client identifier option, and not add a separate
> IAID option.
>
...I don't believe that we have ever identified a good
reason why the client identifier MUST be an opaque value,
save that it does simplify one aspect of interoperability:
if the value is opaque, it can be changed by the client for
any reason, especially convenience, without worrying how a
server will react to the change.

So, if I may restate the issue, "Do we want a client
identifier that contains no data that can be processed by
the server to glean any information about the client, such
as additional qualification similar to vendor or user class
information, or not?"

There are really two competing philosophies here:  (1) keep
the size of the packet (and number of options sent/received)
as small as possible by avoiding duplicated or overlapping
data; and (2) maintain absolute clarity as to the purpose
and interpretation of every option by having one and only
one use for each.  Both are valid perspectives, but I lean a
bit towards the second because of the Law of Unintended
Consequences, which in this case would suggest that changing
the client identifier will have some as yet unforeseen
complication.

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