Subject: Re: [dhcwg] draft-droms-dhc-container-opt-00.txt

From: Ralph Droms <[email-masked]>
Date: Wed, 11 Apr 2007 01:25:38 -0400

Tom - I understand your concern.  I think there is at least one mechanism
already in place to mitigate the problem.  The CPE includes the Parameter
Request List option (55) in its DHCPDISCOVER and DHCPREQUEST messages.  The
RG server includes only those options requested by the CPE in its DHCPOFFER
and DHCPACK messages.  While this behavior is defined in RFC 2131 and RFC
2132, it should probably be made explicit in the container option spec.

There is another issue regarding the policy of overriding option values from
the container option with option values configured directly in the RG DHCP
server.  The container option spec should likely be extended with text to
the effect of "The DHCP server in the RG MAY use locally configured option
values instead of option values received in the container option"

- Ralph

On 3/28/07 7:57 PM, "Thomas Herbst" <[email-masked]> wrote:

> I've been thinking about this draft since the WG meeting
> last week and time has not made it smell any better.
> 
> The principal purported benefit of the proposal is it's
> major problem - the unlimited extensibility enables the
> SP to pass any DHCP option to the clients with the RG
> not having any visibility to apply policy.
> 
> In the case that the RG is provided as part of a SP service,
> it can be rationally argued that the SP can inflict
> any parameters they choose on their customer.  In the case
> where the RG is consumer owned, they should get the opportunity
> to apply policy to the parameters the SP is attempting to foist
> upon them.  Should the SP have a list of specific parameters
> they would like to be passed to set top boxes or other devices
> behind the RG, they can provide that list to the RG vendor
> for propagation.   Not planning the parameters needed for your
> service is not an excuse to have a standards codified, protocol
> based blank check for the future.
> 
> This is not a "policy detail", this is the whole issue with the
> container approach.
> 
> tom
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg