[dhcwg] Comments on draft-ietf-dhc-client-id-03

[Ted Lemon <[e-mail]>]

On Jul 10, 2012, at 5:57 AM, Gaurav Halwasia (ghalwasi) wrote:
> We have taken care of comments which came in the last WGLC and posted a new revision today. Appreciate if you can let us know the next steps in this to proceed.

This text:

> Client MAY use 'client identifier' or 'chaddr' received from server along with 'xid' to map the response to request.  This will guarantee that a particular response from the server is meant for the particular client.

Should say this instead:

> When a client receives a DHCP message containing a 'client identifier' option, the client MUST compare that client identifier to the one it is configured to send.   If the two client identifiers do not match, the client MUST silently discard the message.


The reason for this is that if you say "MAY," nobody will implement it.   Also, if you say "MAY," then you are implying some unspecified heuristic in the client which the client implementor must guess at, and will probably get wrong.

I think the motivation to say "MAY" is predicated on the assumption that not all clients will implement this spec, and we don't want clients that don't implement it to violate it.   But that's not true; only clients that implement this spec are responsible to follow it, and we need not worry about clients that don't implement it.   This spec addresses a very special use case, and it's perfectly understandable if it is not implemented by all clients.

Another concern might be that a client would drop a message it otherwise would have accepted, resulting in a failure for that client to be configured.   This too is not a concern: non-conforming DHCP servers will never send a 'client identifier' option.   Conforming DHCP servers will always send the correct option.   So the only case in which we will see a problem is when a broken implementation does the wrong thing, and we can't prevent that by making the standard overly lax.