DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)
draft-ietf-mip6-hiopt-18

The draft uses a number of acronyms with no definition or reference, such
as FQDN (the acronym is not defined in 1035).

The following issues were raised by Scott Bradner in his OPS-DIR review. I do not think that they are show-stoppers, but it would be very goo for the issues to be considered and addressed f the document goes through an extra round of editing. 

1. this document would significantly benefit from a clear description of the use case for this technology.  The problem this ID seems to be addressing comes up when a mobile node is starting up in a remote location and wants to find its home agent.  The mobile node multicasts a dhcp request with some options to indicate that it wants to know its home agent info and some home network information and the dhcp server provides the mobile node with the requested info.  I'm not sure I got that right and I do not see how the dhcp server knows or gets the info about the home agent.  I'm sure its all here somewhere but a paragraph giving a use case overview would help.

2. I do not see where the doc describes the behavior of the mobile node in the case where the dhcp server does not support the required options. (I would have expected to see something about this in section 4.1)

3. The draft does refer to a number of other IDs  such that the ID may be hung up in the RFC Editor queue until  some of them are published.  It also includes the text "[Editor's note: The Diameter AVPs need to be defined]" in section 4.2 that does not seem like the right thing to be publishing in a RFC.

4. a final nit - RFC 2119 should be an informative not a normative reference

Section 3.1., paragraph 5:
>       option-len
>          2 + length of Home Network Identifier field

  Please make it clear that all lentgh fields are in units of bytes.

Section 3.1., paragraph 7:
>          The type of Home Network Identifier:
>              0    Visited domain (local ASP)
>              1    Target MSP
>              2    No preference

  Please clarify what to to with options that have id-types > 2.
  Usually: "MUST NOT send, MUST ignore on receive."

Section 3.2.1., paragraph 3:
>       sub-opt-code

  When sub-opt-code is 1 or 2, the sub-option becomes fixed-length and
  doesn't really need the sub-opt-len length field.

Section 3.2.1., paragraph 4:
>          A 16-bit unsigned integer for the type of the following
>          Home Network Information field. Possible values are:
>              1    Home network prefix
>              2    Home agent address
>              3    Home agent FQDN

  Please clarify what to to with sub-options that have sub-opt-code 0
  or > 2. Usually: "MUST NOT send, MUST ignore on receive." (Also for the
  corresponding option in Section 3.3.1.)

Section 3.2.1., paragraph 8:
>          A home network prefix, home agent IP address or home agent
>          FQDN to be provided to a mobile node according to the
>          sub-opt-code. These are encoded as specified in Section
>          3.2.1.

  This text *is* in Section 3.2.1 (do you mean "as specified below"?)

Section 4.1., paragraph 9:
> In case the Home Network Information option carries the sub-option
> whose 'V' flag is not consistent with the id-type, the mobile node
> SHOULD ignore and skip the sub-option.

  Please define which cases are considered to be consistent and which
  are inconsistent.

To use the IANA policies defined in RFC 2434, you need that as a
(normative) reference.

In couple of places, "SHOULD not" should be spelled "SHOULD NOT".

Please use example.com/net/org instead of "myhomeisp.com".

Section 4.3 is "DHCP Server Behavior" but the first sentence talks about the mobile node
recieving a relay-forward message.  As I skimmed 3315, it appears the relay-forward
message is transmitted from the relay agent to the dhcp server.