Re: WGLC - draft-ietf-dhc-container-opt-07 - Respond by 2013-04-28

It would appear to me that this is a solution coming from one particular segment of the industry (informative reference is to CableLabs eRouter spec). I'd like to mention an alternative solution that exists in BBF, for managed "RGs", for DHCPv6 options.

BBF TR-181 "TR-069 Device:2.6 Root Object definition" (http://www.broadband-forum.org/cwmp/tr-181-2-6-0.html) is the root object (xml) data model for TR-069-managed devices. This data model includes, for DHCPv6 server function, the ability to manage the treatment of DHCPv6 options that can get "passed through" from the RG DHCPv6 client to the RG DHCPv6 server. This functionality can be managed at a RG DHCPv6 Server Pool level (Device.DHCPv6.Server.Pool.{i}.Option.{i}. object), where it is possible to define different pools for different sets of client hosts (allowing different DHCPv6 options and other rules for different sets of client hosts). It is possible to have a single pool that all client hosts are a member of. The definition and use of multiple pools is not required, but merely sup
 ported by the data model.

In this solution, there is no container for passed through options. Rather, the RG is explicitly configured as to which options to treat this way. The RG's DHCPv6 client (identified through the "PassthroughClient" parameter, since it is possible for an RG to have multiple DHCPv6 clients -- due to the possibility of multiple WAN interfaces) is expected to request all options listed in this DHCPv6 Server Pool Option data model object that have a "PassthroughClient" identified and make these options available (via the RG DHCPv6 server) to client hosts that are members of the "pool".

The PassthroughClient parameter was not included in the DHCPv4 Server Pool Option data model object because there were no requests for it. If there were demand, the data model could easily be extended to allow similar configuration for DHCPv4 options.

If the ISP who manages the SP DHCP server wants to configure client hosts, trusting to the good will of an unmanaged RG (which may or may not support the container option) may not be the best approach.

With that said, if there is demand for standardizing this option container approach (which I'm ambivalent about), I'll provide the following comments:
1. I recommend using "CE Router" instead of "RG", just to try to get some consistency in terminology used by different WGs and RFCs.
2. Since explicit configuration (as I've described) is a design alternative, I think it should be mentioned.
3. I would like to see some discussion of the "multiple RG DHCP client" case (caused by multiple WAN interfaces), and recommendations for handling this.
4. As it relates to ecrit/geopriv efforts, RFC 6881 (published by ecrit) has a requirement:

   AN-14/INT-15:  Where a router is employed between a LAN and WAN in a
      small (less than approximately 650 square meters) area, the router
      MUST be transparent to the location provided by the WAN to the
      LAN.  This may mean the router must obtain location as a client
      from the WAN and supply an LCP server to the LAN with the location
      it obtains.  Where the area is larger, the LAN MUST have a
      location configuration mechanism satisfying the requirements of
      this document.

To me, this suggests that received DHCP location info gets passed through, one way or another (the LCP [Location Configuration Protocol] server can provide the location info through various methods) to client hosts. I think it's possible for this to occur with or without a specific container that directs the router to pass on the location info from its DHCP server function.

Barbara