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

>...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.

I would be against this because it will take significantly longer
(revising 2131/2132 will take a while to get through the IETF process).

- Bernie

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of
Richard Barr Hibbs
Sent: Tuesday, April 06, 2004 1:07 PM
To: 'Dhcwg'
Subject: 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

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