Re: [dhcwg] WGLC: draft-ietf-dhc-leasequery-by-remote-id

[Stephen Jacob <[e-mail]>]

On Sat, Oct 02, 2010 at 11:56:28AM -0500, Ted Lemon wrote:
> On Oct 2, 2010, at 12:15 AM, Pavan Kurapati wrote:
> > Now, we have 2 options. 1) to keep the draft as it is. Servers which have
> > anyway implemented RFC 4388  will be adding associated-ip whether requested
> > or not.  2) Change it only for query by remote ID draft to make sure that
> > AC adds PRL with associated-IP option populated. Server will reply with
> > associated-ip only if it is requested in the leasequery by remote-id.
> > However, server should continue to give it for other query types.
> 
> When I talked with SJ about this while I was in Redwood City this week, he
> seemed to think that even though the base spec requires the server to send
> the associated IP regardless of whether it was requested, it was a mistake to
> put this in RFC4388, and it's better not to compound the error in this spec.
> I tend to agree with this.
> 
> At the same time, I don't think we should make things *worse* by placing a
> new requirement on the server that it *not* do the behavior specified in
> RFC4388.   Rather, what I would suggest is that this spec say that the client
> MUST request the option, and then this spec should not place any requirement
> on the server that it either send, or not send, the associated-ip address
> option.   I think in general implementations will send the associated-ip
> address option regardless, because of the requirement in RFC4388.
> 
> My main motivation for saying that we should remove the language in this
> draft is not that I expect it to change implementations, but that it's a bad
> precedent to place requirements like this on servers, and I don't want
> someone reading the draft to get the impression that it's okay to place such
> requirements on servers, when they write a future draft.

That's a reasonable summary of my opinion.

I think that it is better to avoid specifying too many options that
the server must send unconditionally (regardless of PRL) and that
even if this option is specified as "MUST send" in another
specification (RFC4388) it seems like a net good to avoid further
proliferating such requirements.

There is no harm if a server implementation *does* send the option
unconditionally (indeed, if/when we implement this draft, I am sure
our implementation will do so, due to existing DHCPLEASEQUERY code
paths).

I like the idea of requiring implementors of access concentrators
to include it in the PRL because there is no harm in requesting an
option that would have been sent anyway, but there is harm in not
requesting an option you need to receive that might (correctly or
incorrectly) be omitted by the server.  The fewer exceptions
codified in RFCs to the rule of 'request it if you want it' the
better.

Regards,
Stephen
-- 
 Stephen Jacob | [e-mail] | [phone]
 Nominum, Inc. |  http://www.nominum.com/  | [phone]