Container Option for Server Configuration
draft-ietf-dhc-container-opt-07

This document did NOT pass WGLC as there was no support for it and Ralph indicated that there were several IESG Discusses from several years ago (2009) that did not get addressed. Also, Barbara Stark commented about " alternative solution that exists in BBF, for managed "RGs", for DHCPv6 options."

The authors are encouraged to update the draft addressing the open issues and try again.

However, we will need additional support for this work if it is to pass a future WGLC.

- Tomek & Bernie

IESG positions from previous ballot

Robert Sparks
Discuss (2010-04-13)

This document appears to target a very specific type of deployment, but doesn't
explicitly restrict the applicability of the option to that deployment scenario.

Given the very limited semantic definition it's very difficult to anticipate
the potential consequences should some other type of deployment attempt to use
the option, or if the option leaks into unintended places.

There was some list discussion around multiple interfaces in an RG, but it
focused on DHCP-clients on those interfaces. It's not clear what could happen
that's sane if the RG element had more than one interface where it was acting
as a server.

---- (4/13/2010 Adopting Cullen Jenning's Discuss) ------

I would like the geopriv and ecrit folks to get a chance to look at this. My
understanding of their assumptions about DHCP will work is not at all
consistent with this and this could have some fairly significant implications
to plans for Emergency 911 type systems.

Today, RG are almost always NATs and they are deployed in a nested fashion. So
the DSL modem may have a RG, but very often another "RG" that is perhaps a
wireless AP is plugged into that. This draft needs advice on how it works with
multiple layers of RGs. My current read of it, it does not look like it would
work in the layered case.

This draft needs advice on how the RG deals with conflicts. For example, if
normally it would take whatever DNS server was found by the RG client and
advertise that in the RG server. But imagine the container also has the name of
the DNS server. Which one does the RG Server use?

I don't understand why the the SP needs to be able send different information
to the equipment behind the RG than it sends to the RG. Can you clarify the
reasoning behind this requirement?

In section 3, the third req bullet point. I'm not clear on the requirement. Are
you saying there much be a way for a SP to add new potion that gets sent to the
user equipment without changing the software/config on the RG? This would make
sense to me as a requirement but I'm not sure this draft meets that. When the
RG Server gets an option it does not know about in he container, what does it
do with it?

How is expiry of the information in the container handled? If the SP wants to
change some of the information in it, how is that done?

These containers are going to get very large - does anything need to be said
about size? With this work with a 10k container?

In section 5.5, can you please explicitly list the things the RG Server needs
to discard - as an implementer I would not know what to do.

Can the SP send a container even if the RG client does not request it? This
seems inconsistent with other DHCP stuff. Why is it like this?

Can the RG server return a container to someone that requests it and what goes
in it?

The idea that DHCP authentication would be configure between two nested RG in
grandma's house seems extremely unlikely. I am not aware of any deployments
that use authenticated DHCP between SP and RG. The idea that I can get pushed a
container with the RG client did not even send a request, seems very disturbing
from a security point of view. This is going to contain things like my location
for E911 calls. I realize that what is possible for the security is going to be
pretty limited but I'd like to see it at least mitigate attackers that were not
on the path between RG Client and SP DHCP server.

The statement that the RG server MAY discard everything make a device that
passes nothing useful down fully compliant with the spec. This seems a bit
problematic for trying to deploy services that actually use this. I rather see
something along lines of SHOULD pass it all unless explicitly configured to
block something and default configuration needs to not block.
***************

Ronald Bonica
Discuss (2009-04-22)

This document probably deserves some discussion. To be honest, I am torn
between voting YES and DISCUSS. Let's see how the discussion on the call goes.

On the one hand, the DHCP container object is a good thing. It permits the host
and the SP DHCP Server, even when the intervening RG client has no idea what
those two parties are discussing.

On the other hand, this conversation could be dangerous. If one were to think
of the customer and SP domains as being separate, the RG client would be a
reasonable place to put the security boundary. If the boundary were implemented
at the RG client, it would be a bad thing for the client to pass on messages
that it doesn't understand.

If this option were to be used, each client host would have to protect itself
from bad behavior on the part part of the SP (e.g., installing as route to
0.0.0.0/0 through your other provider, installing a static route to the SP's
competitor through /dev/null).
***************

Russ Housley
Discuss (2009-04-21)

  The Gen-ART Review by Scott Brim posted on 7 April 2009 raises some
  concerns that have not been addressed.  Responses to these concerns
  are needed, even if there are not any document changes.  The review
  can be found at:
    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-dhc-container-opt-05-brim.txt

***************
[Cullen Jennings]
Discuss (2009-04-22)

My apologies for getting to this draft so late. I did not realize what it was
and did not even realize this work was in progress. It has lots of implication
to VoIP and IpTV work in RAI.  These are discus discuss and many of them simply
reflect I am just getting up to speed on this now.

I would like the geopriv and ecrit folks to get a chance to look at this. My
understanding of their assumptions about DHCP will work is not at all
consistent with this and this could have some fairly significant implications
to plans for Emergency 911 type systems.

Today, RG are almost always NATs and they are deployed in a nested fashion. So
the DSL modem may have a RG, but very often another "RG" that is perhaps a
wireless AP is plugged into that. This draft needs advice on how it works with
multiple layers of RGs. My current read of it, it does not look like it would
work in the layered case.

This draft needs advice on how the RG deals with conflicts. For example, if
normally it would take whatever DNS server was found by the RG client and
advertise that in the RG server. But imagine the container also has the name of
the DNS server. Which one does the RG Server use?

I don't understand why the the SP needs to be able send different information
to the equipment behind the RG than it sends to the RG. Can you clarify the
reasoning behind this requirement?

In section 3, the third req bullet point. I'm not clear on the requirement. Are
you saying there much be a way for a SP to add new potion that gets sent to the
user equipment without changing the software/config on the RG? This would make
sense to me as a requirement but I'm not sure this draft meets that. When the
RG Server gets an option it does not know about in he container, what does it
do with it?

How is expiry of the information in the container handled? If the SP wants to
change some of the information in it, how is that done?

These containers are going to get very large - does anything need to be said
about size? With this work with a 10k container?

In section 5.5, can you please explicitly list the things the RG Server needs
to discard - as an implementer I would not know what to do.

Can the SP send a container even if the RG client does not request it? This
seems inconsistent with other DHCP stuff. Why is it like this?

Can the RG server return a container to someone that requests it and what goes
in it?

The idea that DHCP authentication would be configure between two nested RG in
grandma's house seems extremely unlikely. I am not aware of any deployments
that use authenticated DHCP between SP and RG. The idea that I can get pushed a
container with the RG client did not even send a request, seems very disturbing
from a security point of view. This is going to contain things like my location
for E911 calls. I realize that what is possible for the security is going to be
pretty limited but I'd like to see it at least mitigate attackers that were not
on the path between RG Client and SP DHCP server.

The statement that the RG server MAY discard everything make a device that
passes nothing useful down fully compliant with the spec. This seems a bit
problematic for trying to deploy services that actually use this. I rather see
something along lines of SHOULD pass it all unless explicitly configured to
block something and default configuration needs to not block.

***************
[Dan Romascanu]
Discuss (2009-04-21)

I share the concerns expressed by othe ADs about the danger of this document
being interpreted as defining an extension of DHCP that would allow usage as  a
more generic service configuration protocol. I believe that there is need for
more strict language that clarifies the scope of the container option and
restricts the deployment space to RGs.

Specifically wherever it makes sense replace 'configuration information' by
'DHCP configuration information'.

Also in the Intorduction section:

  The DHCP Container option defined in this document provides a
  mechanism through which the RG DHCP client can pass DHCP options to
  the RG DHCP server without explicit knowledge of the semantics of
  those options.  With this option, the SP DHCP server can pass both
  current and future DHCP options to the RG DHCP server.

  The DHCP Container option does not carry IP addresses, IPv6 prefixes
  or other information about leases.  It carries other configuration
  information.

The last phrase should make clear that the DHCP container option carries
configuration information expressed as DHCP options.

Also, in the OPS-DIR review by Tina Tsou the observation was made that it is
not clear from the text that the RG client and RG server are always considered
as being physically colocated in the same device. It would be good to make this
statement explicit, to avoid any other 'creative' deployments or
interpretations in the future.

***************
[Lars Eggert]
Comment (2009-04-20)

I'm abstaining. Basically, the addition of this option turns DHCP from a host
configuration protocol into a DHCP server operations&management protocol.
That's a pretty dramatic change in scope for DHCP, and even if I thought this
was a good idea, I'm missing documents that describe how a DHCP that had been
extended with this options would be used for this purpose.

***************
[Magnus Westerlund]
Comment (2009-04-23)

I do support the discusses from Cullen on the need to clarify and explain
multi-level deployments.

I am also worried about the architectural change and lack of documented
analysis on what the change means.

***************
[Tim Polk]
Discuss (2009-04-22)

Joe Salowey's secdir review (posted on 14 April 2009) proposed clarifying text
for the security considerations and raised questions regarding the suitability
of this protocol for interactions between the RG server and client hosts.  I
have not seen a response to this message, and am interested in hearing the
author's position on the proposed text and the applicability question.

Ralph thinks there is one customer for this. Ralph will take an action item to determine with the chairs if that's really the case. If not, the document can be moved to dead.

[Ballot discuss]
This document appears to target a very specific type of deployment, but doesn't explicitly restrict the applicability of the option to that deployment scenario.

Given the very limited semantic definition it's very difficult to anticipate the potential consequences should some other type of deployment attempt to use the option, or if the option leaks into unintended places.

There was some list discussion around multiple interfaces in an RG, but it focused on DHCP-clients on those interfaces. It's not clear what could happen that's sane if the RG element had more than one interface where it was acting as a server.

---- (4/13/2010 Adopting Cullen Jenning's Discuss) ------

I would like the geopriv and ecrit folks to get a chance to look at this. My understanding of their assumptions about DHCP will work is not at all consistent with this and this could have some fairly significant implications to plans for Emergency 911 type systems.


Today, RG are almost always NATs and they are deployed in a nested fashion. So the DSL modem may have a RG, but very often another "RG" that is perhaps a wireless AP is plugged into that. This draft needs advice on how it works with multiple layers of RGs. My current read of it, it does not look like it would work in the layered case.

This draft needs advice on how the RG deals with conflicts. For example, if normally it would take whatever DNS server was found by the RG client and advertise that in the RG server. But imagine the container also has the name of the DNS server. Which one does the RG Server use?

I don't understand why the the SP needs to be able send different information to the equipment behind the RG than it sends to the RG. Can you clarify the reasoning behind this requirement?


In section 3, the third req bullet point. I'm not clear on the requirement. Are you saying there much be a way for a SP to add new potion that gets sent to the user equipment without changing the software/config on the RG? This would make sense to me as a requirement but I'm not sure this draft meets that. When the RG Server gets an option it does not know about in he container, what does it do
with it?


How is expiry of the information in the container handled? If the SP wants to change some of the information in it, how is that done?

These containers are going to get very large - does anything need to be said about size? With this work with a 10k container?

In section 5.5, can you please explicitly list the things the RG Server needs to discard - as an implementer I would not know what to do.

Can the SP send a container even if the RG client does not request it? This seems inconsistent with other DHCP stuff. Why is it like this?

Can the RG server return a container to someone that requests it and what goes in it?

The idea that DHCP authentication would be configure between two nested RG in grandma's house seems extremely unlikely. I am not aware of any deployments that use authenticated DHCP between SP and RG. The idea that I can get pushed a container with the RG client did not even send a request, seems very disturbing from a security point of view. This is going to contain things like my location for E911 calls. I realize that what is possible for the security is going to be pretty limited but I'd like to see it at least mitigate attackers that were not on the path between RG Client and SP DHCP server.


The statement that the RG server MAY discard everything make a device that
passes nothing useful down fully compliant with the spec. This seems a bit
problematic for trying to deploy services that actually use this. I rather see something along lines of SHOULD pass it all unless explicitly configured to block something and default configuration needs to not block.

Ralph and I agreed that this work item should be handled by the DHC chairs:

- find a new author (to replace Ralph)
- find a use case
- confirm that the approach using DHC is architecturally right, as opposed
  to using some of the other means that have been developed independent
  of DHCP and which are less reliant on the network architecture
- solve the problem with passing unrecognized options

[Ballot discuss]
Under what charter item has this work been done in the DHC WG? Looking at the charter and milestones I find this item:

* Develop extensions to the DHCP infrastructure as required to meet
new applications and deployments of DHCP. The topics currently
in development are:

- Subnet allocation mechanisms
- Virtual subnet identification option
- Option for passing DNS domain information in DHCPv6
- DHCP relay agent assignment notification in DHCPv6
- Option for DHCPv6 server reply sequence numbers
- Rebinding capability for DHCPv6 Reconfigure messages
- Behavior of layer 2 relay agents

The adoption of new items requires explicit agreement from
the AD or rechartering.

This doesn't seem to fit any of the explicitly listed items. Has the AD explicitly approved this work? I am asking as there are no milestone for this document what I can find.

Considering the architecture change, shouldn't maybe this gone through a recharter action?

[Ballot comment]
I do support the discusses from Cullen on the need to clarify and explain multi-level deployments.

I am also worried about the architectural change and lack of documented  analysis on what the change means.

[Ballot discuss]
My apologies for getting to this draft so late. I did not realize what it was and did not even realize this work was in progress. It has lots of implication to VoIP and IpTV work in RAI.  These are discus discuss and many of them simply reflect I am just getting up to speed on this now.

I would like the geopriv and ecrit folks to get a chance to look at this. My understanding of their assumptions about DHCP will work is not at all consistent with this and this could have some fairly significant implications to plans for Emergency 911 type systems.


Today, RG are almost always NATs and they are deployed in a nested fashion. So the DSL modem may have a RG, but very often another "RG" that is perhaps a wireless AP is plugged into that. This draft needs advice on how it works with multiple layers of RGs. My current read of it, it does not look like it would work in the layered case. 

This draft needs advice on how the RG deals with conflicts. For example, if normally it would take whatever DNS server was found by the RG client and advertise that in the RG server. But imagine the container also has the name of the DNS server. Which one does the RG Server use?

I don't understand why the the SP needs to be able send different information to the equipment behind the RG than it sends to the RG. Can you clarify the reasoning behind this requirement?


In section 3, the third req bullet point. I'm not clear on the requirement. Are you saying there much be a way for a SP to add new potion that gets sent to the user equipment without changing the software/config on the RG? This would make sense to me as a requirement but I'm not sure this draft meets that. When the RG Server gets an option it does not know about in he container, what does it do with it?


How is expiry of the information in the container handled? If the SP wants to change some of the information in it, how is that done?

These containers are going to get very large - does anything need to be said about size? With this work with a 10k container?

In section 5.5, can you please explicitly list the things the RG Server needs to discard - as an implementer I would not know what to do.

Can the SP send a container even if the RG client does not request it? This seems inconsistent with other DHCP stuff. Why is it like this?

Can the RG server return a container to someone that requests it and what goes in it?

The idea that DHCP authentication would be configure between two nested RG in grandma's house seems extremely unlikely. I am not aware of any deployments that use authenticated DHCP between SP and RG. The idea that I can get pushed a container with the RG client did not even send a request, seems very disturbing from a security point of view. This is going to contain things like my location for E911 calls. I realize that what is possible for the security is going to be pretty limited but I'd like to see it at least mitigate attackers that were not on the path between RG Client and SP DHCP server.


The statement that the RG server MAY discard everything make a device that passes nothing useful down fully compliant with the spec. This seems a bit problematic for trying to deploy services that actually use this. I rather see something along lines of SHOULD pass it all unless explicitly configured to block something and default configuration needs to not block.

[Ballot discuss]
This document probably deserves some discussion. To be honest, I am torn between voting YES and DISCUSS. Let's see how the discussion on the call goes.

On the one hand, the DHCP container object is a good thing. It permits the host and the SP DHCP Server, even when the intervening RG client has no idea what those two parties are discussing.

On the other hand, this conversation could be dangerous. If one were to think of the customer and SP domains as being separate, the RG client would be a reasonable place to put the security boundary. If the boundary were implemented at the RG client, it would be a bad thing for the client to pass on messages that it doesn't understand.

If this option were to be used, each client host would have to protect itself from bad behavior on the part part of the SP (e.g., installing as route to 0.0.0.0/0 through your other provider, installing a static route to the SP's competitor through /dev/null).

[Ballot discuss]
This document probably deserves some discussion. To be honest, I am torn between voting YES and DISCUSS. Let's see how the discussion on the call goes.

On the one hand, the DHCP container object is a good thing. It permits the host and the SP DHCP Server, even when the intervening RG client has no idea what those two parties are discussing.

On the other hand, this conversation could be dangerous. If one were to think of the customer and SP domains as being separate, the RG client would be a reasonable place to put the security boundary. If the boundary were implemented at the RG client, it would be a bad thing for the client to pass on messages that it doesn't understand.

If this option were to be used, each client host would have to protect itself from bad behavior on the part part of the SP (e.g., installing as route to 0.0.0.0/0 through your other provider, installing a static route to the SP's competitor through /dev/null).

[Ballot discuss]
Joe Salowey's secdir review (posted on 14 April 2009) proposed clarifying text for the
security considerations and raised questions regarding the suitability of this protocol
for interactions between the RG server and client hosts.  I have not seen a response
to this message, and am interested in hearing the author's position on the proposed text
and the applicability question.

[Ballot discuss]
The Gen-ART Review by Scott Brim posted on 7 April 2009 raises some
  concerns that have not been addressed.  Responses to these concerns
  are needed, even if there are not any document changes.  The review
  can be found at:
    http://www.softarmor.com/rai/temp-gen-art/
    draft-ietf-dhc-container-opt-05-brim.txt

[Ballot discuss]
I share the concerns expressed by othe ADs about the danger of this document being interpreted as defining an extension of DHCP that would allow usage as  a more generic service configuration protocol. I believe that there is need for more strict language that clarifies the scope of the container option and restricts the deployment space to RGs.

Specifically wherever it makes sense replace 'configuration information' by 'DHCP configuration information'.

Also in the Intorduction section:

  The DHCP Container option defined in this document provides a
  mechanism through which the RG DHCP client can pass DHCP options to
  the RG DHCP server without explicit knowledge of the semantics of
  those options.  With this option, the SP DHCP server can pass both
  current and future DHCP options to the RG DHCP server.

  The DHCP Container option does not carry IP addresses, IPv6 prefixes
  or other information about leases.  It carries other configuration
  information.

The last phrase should make clear that the DHCP container option carries configuration information expressed as DHCP options.

Also, in the OPS-DIR review by Tina Tsou the observation was made that it is not clear from the text that the RG client and RG server are always considered as being physically colocated in the same device. It would be good to make this statement explicit, to avoid any other 'creative' deployments or interpretations in the future.

[Ballot discuss]
This document appears to target a very specific type of deployment, but doesn't explicitly restrict the applicability of the option to that deployment scenario.

Given the very limited semantic definition it's very difficult to anticipate the potential consequences should some other type of deployment attempt to use the option, or if the option leaks into unintended places.

There was some list discussion around multiple interfaces in an RG, but it focused on DHCP-clients on those interfaces. It's not clear what could happen that's sane if the RG element had more than one interface where it was acting as a server.

[Ballot comment]
I'm abstaining. Basically, the addition of this option turns DHCP from a host configuration protocol into a DHCP server operations&management protocol. That's a pretty dramatic change in scope for DHCP, and even if I thought this was a good idea, I'm missing documents that describe how a DHCP that had been extended with this options would be used for this purpose.

[Ballot comment]
Basically, the addition of this option turns DHCP from a host configuration protocol into a DHCP server operations&management protocol. That's a pretty dramatic change in scope for DHCP, and even if I thought this was a good idea, I'm missing documents that describe how a DHCP that had been extended with this options would be used for this purpose.

[Ballot discuss]
Basically, the addition of this option turns DHCP from a host configuration protocol into a DHCP server operations&management protocol. That's a pretty dramatic change in scope for DHCP, and even if I thought this was a good idea, I'm missing documents that describe how a DHCP that had been extended with this options would be used for this purpose.

[Ballot discuss]
In Setion 1 you have:
  The DHCP Container option does not carry IP addresses, IPv6 prefixes
  or other information about leases.  It carries other configuration
  information.
And I note that there is no use of RFC 2119 language.

So I looked later in the I-D for a definition of what may be found in "DHCP Options for RG server". All I could find was in section 5.3:
  the policy determining the
  contents of the Container object are out of scope of this document
  and left unspecified.
Which seems to be significantly in conflict with section 1.
And section 5.5:
  The RG server MUST discard any options related to IP address
  assignment, IPv6 prefix delegation or operation of the DHCP protocol
  itself.
which implies that the IP addresses MAY be present, but MUST be discarded.

Consistency please.

Oh, and when banning the use of addresses in this way, half a sentence saying why would be nice.

[Ballot comment]
The second sentence of the Abstract is particularly flimsy.
"This DHCP option carries a set of DHCP options that can be used by another DHCP server."
An option carries a set of options?
"Used by"?
"Another DHCP server" with respect to what?

This optional use of the word "option" gets heavy again in the penultimate paragraph of section 1.

IANA questions/comments:


IANA has reviewed draft-ietf-dhc-container-opt-05.txt, which is
currently in Last Call, and has the following questions and comments:

- What's the Data Length of the DHCPv4 Option?

Action 1:

Upon approval of this document, IANA will make the following
assignment in the "BOOTP Vendor Extensions and DHCP Options"
registry at
http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

Tag Name Data Length Meaning Reference
--- ----- ----------- --------- ----------
TBD OPTION_CONTAINER_V4 ? Container Option
[RFC-dhc-container-opt-05]


Action 2:

Upon approval of this document, IANA will make the following
assignments in the "DHCP Option Codes" registry at
http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml

Value Description Reference
----- ----------- ---------
TBD OPTION_CONTAINER_V6 [RFC-dhc-container-opt-05]


We understand the above to be the only IANA Actions for this document.

    (1.a) Who is the Document Shepherd for this document? Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

John Jason Brzozowski, dhc WG co-chair.  I have reviewed the document
and believe it is ready for publication.

    (1.b) Has the document had adequate review both from key WG members
          and from key non-WG members? Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has had adequate review.  The WG last call discussion
thread starts at
http://www.ietf.org/mail-archive/web/dhcwg/current/msg08858.html

There are no concerns regarding the review of this document.

    (1.c) Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No.

    (1.d) Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of? For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it. In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here. Has an IPR disclosure related to this document
          been filed? If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

No there are no known issues that the responsible AD needs to be aware
of.  There are no sections of this document that the shepherd has
concerns with.  There are no known IPR disclosures related to this document.

    (1.e) How solid is the WG consensus behind this document? Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

The consensus for the document is from a minority of WG members, with
no dissenting opinions.

    (1.f) Has anyone threatened an appeal or otherwise indicated extreme
          discontent? If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director. (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No appeals have been threatened.

    (1.g) Has the Document Shepherd personally verified that the
          document satisfies all ID nits? (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/). Boilerplate checks are
          not enough; this check needs to be thorough. Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

It passes the ID nits tool.  No other review is necessary.

    (1.h) Has the document split its references into normative and
          informative? Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state? If such normative references exist, what is the
          strategy for their completion? Are there normative references
          that are downward references, as described in [RFC3967]? If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

All normative references are to published documents.  There are no
downward references.

    (1.i) Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document? If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries? Are the IANA registries clearly identified? If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations? Does it suggest a
          reasonable name for the new registry? See [RFC5226]. If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

There is an IANA considerations section, which requests new DHCP
option codes in the "BOOTP Vendor Extensions and DHCP Options" and
"DHCPv6 Option Codes" registries.  No new registries are required.

    (1.j) Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

N/A

    (1.k) The IESG approval announcement includes a Document
          Announcement Write-Up. Please provide such a Document
          Announcement Write-Up? Recent examples can be found in the
          "Action" announcements for approved documents. The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document. If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in WG process that is worth noting? For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

          Document Quality
            Are there existing implementations of the protocol? Have a
            significant number of vendors indicated their plan to
            implement the specification? Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues? If
            there was a MIB Doctor, Media Type or other expert review,
            what was its course (briefly)? In the case of a Media Type
            review, on what date was the request posted?

Document announcement write-up:

Technical Summary

  In some DHCP service deployments, it is desirable for a DHCP server
  in one administrative domain to pass configuration options to a
  DHCP server in a different administrative domain.  This DHCP option
  carries a set of DHCP options that can be passed from one DHCP
  server to another DHCP server to pass configuration information to
  clients served by that second DHCP server.

Working Group Summary

  There has been consensus in the dhc WG to support the development
  of this document throughout the WG review process.  The WG last
  call showed consensus to advance the document to the IESG,
  http://www.ietf.org/mail-archive/web/dhcwg/current/msg08858.html
  Issues raised during the WG last call have been addressed in the
  most recent revision of the document.

Document Quality

  A version of this option was developed as part of the CableLabs
  eRouter DHCP Container vendor-identifying vendor-specific option,
  and defined in "CableLabs' DHCP Options Registry".  There is wider
  applicability of this option beyond cable service provider
  deployments, so the dhc WG was asked to develop an Internet
  Standard specification of the option.

(end)