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

From: Pavan Kurapati <[email-masked]>
Date: Sat, 2 Oct 2010 10:45:21 +0530

Hi Ted, Stephen,

As per both RFC 4388 (and query by remote-id draft),  relay agent
information option is added only when the same is requested in
parameter request list and there is no change in that behavior in our
draft. The only exception was made to "associated-ip" option where
irrespective of whether it is requested or not in PRL, server was
supposed to add it in case multiple IPs are associated with a query by
MAC or client-id or remote-id. If we make it mandatory for an AC to
put a PRL with associated-ip populated only for query by remote-ID, it
may create problems with earlier implementations of query by MAC or
client-ID.

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.

Please let us know if we want the change mentioned in "2" to be made.
It is a minor edit and I can make it in the next draft along with the
other editorial changes suggested during the last call. However, I
think we should be keeping it as it is considering the existing
implementations.

Thanks,
Pavan

On Wed, Sep 29, 2010 at 6:35 PM, Ted Lemon <[email-masked]> wrote:
> On Sep 28, 2010, at 9:53 PM, "Pavan Kurapati" <[email-masked]> wrote:
>
>> I have one question. If an option is requested in parameter-request
>> list, should DHCP server return that option as a MUST? RFC 2132 is not
>> worded very clearly in this respect. RFC 2132 says " The client MAY
>> list the options in order of preference.  The DHCP
>>   server is not required to return the options in the requested
>> order, but MUST try to insert the requested options in the order
>> requested by the client", but it doesnt say that DHCP server MUST
>> return the options listed in the parameter request list?
>
> The server doesn't have to return an option to the client if there's no option to return, regardless of the contents of the prl.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 2 Oct 2010 11:56:28 -0500

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

---

From: Stephen Jacob <[email-masked]>
Date: Sat, 2 Oct 2010 10:10:32 -0700

On Sat, Oct 02, 2010 at 11:56:28AM -0500, Ted Lemon 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
> 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 | [email-masked] | +1 650 381 6051
 Nominum, Inc. |  http://www.nominum.com/  | +1 650 381 6000

---

From: Pavan Kurapati <[email-masked]>
Date: Mon, 4 Oct 2010 15:11:19 +0530

Hi Ted, Stephen

Thanks for the explanation! I guess it is logical now to make it a
MUST in the client but leave the server implementation as is. I will
make this change and publish the draft

Thanks,
Pavan

---

From: Ted Lemon <[email-masked]>
Date: Thu, 7 Oct 2010 09:41:38 -0700

On Sep 28, 2010, at 8:31 AM, Ted Lemon wrote:
> So if you want the draft to proceed to the IESG, please indicate your support for it here on the mailing list.   If you object, please indicate that as well.   The original WGLC was at the end of June, and nobody registered any objections then, so if I don't hear any objections by close of business on Friday, and I do hear substantial support, I'm going to call that consensus.

Okay, this document has passed WGLC, and I'll be sending a request for publication to the IESG.