Document: draft-ietf-dhc-container-opt-05
Reviewer: Scott Brim
Review Date:         7 April 2009
IESG Telechat date: 14 April 2009

Summary:

This draft is on the right track but has open issues.

Comments:

More significant:

  I am concerned about multiple interface scenarios as are being
  discussed in MIF and 6MAN, where either the RG is multiply connected
  or the end device is.  For a discussion of the sort of problems that
  lead to this concern, see (for example) notes from the MIF BOF at
  IETF74.

  - There must be a way to associate options with a particular
    upstream DHS they were obtained from, when the container is passed
    to the RG server and perhaps to the end device.  This source
    information may or may not be in the container itself -- that's up
    to the WG to decide.  If it is decided that the source information
    will not be part of the container syntax, at least the fact that
    it is necessary should be documented for people who ultimately do
    specify how container options are passed.
  
  - The SP server may have its ideas of how a consumer device should
    be configured, but it is not appropriate to say that the "SP
    server MUST be able to control which DHCP options are transmitted
    to the consumer device".  The RG server may need to make decisions
    about information from multiple DHCP servers.  Perhaps you could
    say that the SP server MUST be able to "provide information" to
    the RG server.  

Less significant:

  5.1 and 5.2

    Alignment between the v4 and v6 descriptions would be better. The
    v4 description has "code" in the diagram and says that "code" is
    OPTION_CONTAINER_V4.  The v6 description has "OPTION_CONTAINER_V6"
    in the diagram and says that "option-code" is OPTION_CONTAINER_V6.