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

[Pavan Kurapati <[e-mail]>]

I think the point of discussion has come from the section 4.3 of the
draft "In the case where more than one IP address has been involved in
a DHCP message exchange with the client specified by the Remote ID,
then the list of all those IP addresses MUST be returned in the
associated-ip option, whether or not that option was requested as part
of the Parameter Request List option."

Associated-IP option is returned only when there is more than one IP
address involved. But Access concentrator has no way to know that
there is going to be more than one IP address for the remote-ID, hence
making it a MUST in access concentrator's parameter request list may
not be feasible IMO.

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? If this
condition is relaxed, then we may make parameter-request list
mandatory in Access concentrator with option 82 and parameter request
list option as a MUST.

Thanks,
Pavan

On Wed, Sep 29, 2010 at 8:59 AM, Stephen Jacob
<[e-mail]> wrote:
> On Tue, Sep 28, 2010 at 07:44:01PM -0700, Ted Lemon wrote:
>> On Sep 28, 2010, at 5:40 PM, Stephen Jacob <[e-mail]> wrote:
>> BTW, I did actually have one minor suggestion.   If there's strong resistance
>> I'll withdraw it, but if nobody objects I think it'll be a win: the draft
>> currently requires the server to respond with a remote-id option even if it
>> wasn't requested.  I think it would be better to place the burden on the
>> access concentrator to request the option, and if it doesn't, all bets are
>> off.  This would eliminate the need for a bit of special code in the server
>> to check for the missing option in the ORO.
>
> Oh! Very good suggestion.
>
> Strong +1 re Ted's suggestion. :)  Especially in a new specification,
> I really like the idea of putting the onus on the access concentrator.
>
> I'd like to see it made explicit, if the change you suggest is made,
> that it must be requested in the ORO so as to avoid implementors of
> the access concentrator missing that and DHCP server implementors
> having to add the special code anyway to work around that.
>
> Regards,
> Stephen
> --
>  Stephen Jacob | [e-mail] | [phone]
>  Nominum, Inc. |  http://www.nominum.com/  | [phone]
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
>