RE: [dhcwg] I-D ACTION:draft-ietf-dhc-3315id-for-v4-02.txt + LAST CALL Comments

> -----Original Message-----
> From: Bernie Volz [mailto:volz@cisco.com]
> Sent: Tuesday, 06 April 2004 06:40
>
> I don't think a new option is such a good idea.
> If a new option is used, how does a client know
> when to send it or the 'old' client identifier
> option? This forces 'new' clients to send both -
> at least in the DISCOVER (older servers would
> not echo back the new option in the OFFER
> and new servers would could send back just the
> new option). This goes against your proposed
> text for 4.1, "but MUST NOT send both."
>
...although I believe that when you significantly change
both the syntax and semantics of an existing option it
should be recast as a new option, I'll relent on that
point...  I also seem to have failed the transition test by
requiring divine knowledge on the part of clients...
oops....


> I'm also not completely happy with encoding the
> IAID and DUID in a single option.
>
> The main reason I don't like this is that it
> forces the server to do something that we don't
> really want it to do - pull apart the data in
> the client identifier option - the option data is
> no longer 'opaque'.  Note that it will be
> important for the DHCP server to do this for:
> 1. Dynamic DNS updates since the client
> identifier is only the DUID portion (see section
> 3.3 of draft-ietf-dnsext-dhcid-rr-07.txt).
> 2. Client based policies (ie, reservations) or
> limits, since these will want to look just at the
> DUID portion.
>
I strongly believe that the client identifier should remain
opaque to the server because to change the semantics is a
significant change to the operation of existing servers.


> But, there is an advantage to encoding the IAID
> and DUID in the option as it supports current
> DHCP server implementations. Without this, a
> client that has multiple interfaces (either
> connected to the same link or not) that are
> serviced by a single DHCP server might not get
> multiple addresses.
>
> I guess given the lesser of the two evils, I'm
> inclined to go along with the option as you've
> proposed it in the draft.
>
> So, I support this document moving forward.
>
...I'd prefer this work to be incorporated into a revision
of RFC2132, rather than creating a new RFC that will
probably be obsoleted shortly after publication, which also
gives us the opportunity to more fully consider the
ramifications of altering the semantics of the client
identifier in the context of DHCP-DNS dynamic updates.

--Barr


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