draft-droms-dhc-container-opt-00.txt

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
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

Tom,

I'm not sure I'm a fan of this container option either, but
I see the
need, and I also see another view of what you describe:  If
the RG is
owned by the user, then presumably the RG can provide the
user with RG
configuration access to create the desired policy.  Then the
data
provided by the SP is simply available for use, but not
necessarily
used.  A device owned by a user is not going to force a user
to do
something it doesn't want to do.  If it did, the user would
buy a
different device.

The more common case is that the user (whether a RG owner or
not) has no
clue and trusts the SP completely, and the SP wants to
provide relevant
configuration data to let the devices in the home take
advantage of the
service.  But doesn't have to be the only case allowed by
the container
option.

-josh

Thomas Herbst 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
> dhcwgietf.org
> https://
www1.ietf.org/mailman/listinfo/dhcwg

-- 
============================================================
=========
Josh Littlefield                                  Cisco
Systems, Inc.
joshlcisco.com                             1414
Massachusetts Avenue
tel: 978-936-1379  fax: 978-936-2226       Boxborough, MA 
01719-2205

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg

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" <herbstcisco.com> 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
> dhcwgietf.org
> https://
www1.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg