Re: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04

["Gaurav Halwasia (ghalwasi)" <[e-mail]>]

Thanks Marcin for reading the document and commenting.

I agree with Bernie.

For 4, I think it's pretty much clear in the WG and it's clear from the discussions so far that this document in no way suggesting to replace DUID.  I don't see that this document in any way gives the impression to replace DUID. So I think that making it explicit might not be required.

For 5, We will take care of it in the next revision or at the time of AUTH48 (whichever is earlier)

-Gaurav
From: [e-mail] [mailto:[e-mail]] On Behalf Of Be
rnie Volz (volz)
Sent: Wednesday, February 20, 2013 8:22 AM
To: Marcin Siodelski; [e-mail]
Cc: Wojciech Dec (wdec)
Subject: Re: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04

(WG co-chair hat off - not that it has yet really been put on anyway.)

Regarding #1 and #2, while perhaps best to clarify that there is only one (in the Relay-Forw closest to the client), I think these really are not 'require' to be addressed. We generally assume that only one is present when it is pretty clear that is all that makes sense and the server would use only the first (I doubt most servers would care to check for a second because there is no reason to do so - yes, a server that processes the options sequentially might save just the last but that isn't a major issue and for various reasons I doubt any server processes options this way).

For #3, if a client adds this, it will be in the client's message and not in Relay-Forw so it will be ignored by the server (and other relays).


-          Bernie

From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Marcin Siodelski
Sent: Tuesday, February 19, 2013 12:45 PM
To: [e-mail]<mailto:[e-mail]>
Cc: Wojciech Dec (wdec)
Subject: [dhcwg] Comments regarding draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04

Hello,

I have just read the draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-04 and I have a few comments to share....

1. It is easy to deduce that there can be just a single instance of the option carrying the link-layer address in a particular message. However, I think it should be explicitly mentioned for the clarity of the document. Note that the standards don't prohibit sending multiple instances of the option with the certain code. Also, some of the options may be included only once.

2. I suggest that it is mentioned what a server is supposed to do if it finds two instances of the option in the single DHCP message. ignore the options? Ignore the whole message? It is specifically important when multiple options carry different link-layer addresses.

3. It is said that the Relay Agent MAY add the link-layer option to the message, but it is NOT said what happens if a client sends this option. Again, is this ignored by the Relay Agent OR the Server?

4. I suggest that it is explicitly mentioned that the new option does not replace the DUID in any sense but it rather carries the supplementary information - the client-id requirements from the RFC3315 still apply.

5. Minor: there is the inconsitency with respect to the name of the option. In section 3: it is "Client Link-layer Address", in the header of the page it is "Client Link-layer address", in section 5 it is "client link-layer address", in section 7 it is "Client Link Layer Address".

Cheers,
Marcin