[Ballot comment]
I propose an alternate IESG note:

      This RFC is not a candidate for any level of Internet Standard.
      The IETF disclaims any knowledge of the fitness of this RFC for
      any purpose and in particular notes that the decision to publish
      is not based on IETF review for such things as security,
      congestion control, or inappropriate interaction with deployed
      protocols.  The RFC Editor has chosen to publish this document at
      its discretion.  Readers of this document should exercise caution
      in evaluating its value for implementation and deployment.  See
      RFC 3932 for more information.

      This RFC does not offer any security mechanisms to provide
      data origin authentication and integrity, yet these
      security services are vitally important in this context.

[Ballot comment]
I propose an alternate IESG note:

      This RFC is not a candidate for any level of Internet Standard.
      The IETF disclaims any knowledge of the fitness of this RFC for
      any purpose and in particular notes that the decision to publish
      is not based on IETF review for such things as security,
      congestion control, or inappropriate interaction with deployed
      protocols.  The RFC Editor has chosen to publish this document at
      its discretion.  Readers of this document should exercise caution
      in evaluating its value for implementation and deployment.  See
      RFC 3932 for more information.

      This RFC does not offer any security mechanisms to provide
      data origin authentication and integrity, yet these
      security services are vitally important in this context.

[Ballot comment]
Gen-ART review comments from Elwyn Davies:

The document is generally in good shape but needs a small number of clarifications:
- It should be made explicit which extensions are allowed in registration requests and which in registration replies.
- The sub-type fields in s3 should be explicitly stated to contain an integer from 0 to 255.
- The Home Network Prefix extension would be better named Home Network Prefix Length extension.
- In s3.1: It would be worth stating that other values of the selector are reserved... presumably some form of flag word was intended originally but this is now presumably moot.

Questions about the DHCP Client ID Extension:
- Regarding the summary in s2: If the Client ID is *really* used to obtain the IP address for the mobile node, this can only be done while the node is at home.  If the mobile node is booting up on a foreign network it needs to find its IP address by some other means than DHCP.  What is actually implemented here?  Is the home agent to query the DHCP server and obtain the client ID and pass it on?  Is the mobile node supposed to know what its Client ID is and pass it through the Home Agent which can use it on behalf of the mobile node?
- In s3.5, it should be made clear if this is expected to be in a registration request or a registration reply (or either).
- [Aside] There has been some discussion in the wg as to what information should be obtained through this sort of request.  Much of it could be obtained through DHCP once the mobile node is told the address of the DHCP server.  And there is no particular need for the home agent to know the DHCP Client ID as far as I can see.

<snip>

Editorial:
s3.8: s/atmost/at most/
s5: s/information/informational/

[Ballot discuss]
Even if the document is not going to offer solutions to the
  security issues, it should make it clear that data origin
  authentication and integrity are vitally important.