DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
RFC 6153

[Ballot discuss]
(Updated 2010-10-11, based on rev -05 {still apply to rev -06], added issues from dhc WG review)

The -05 rev has addressed most of my DISCUSS issues.  However, I think sections 2 and 3 still need work; I suggest the following text for sections 2 and 3 to clarify, simplify and bring into line with the definitions of DHCP options in other IETF documents:

2. ANDSF IPv4 Address Option for DHCPv4
   
  This section describes the ANDSF IPv4 Address Option for DHCPv4.
  The option layout is depicted below:

          Code Len    IPv4 Address 1    IPv4 Address 2
        +----+----+----+----+----+----+----+---------
        | XX | n  |a1  | a2 | a3 | a4 | a1 | ......
        +----+----+----+----+----+----+----+---------
   
        Option Code
   
                OPTION-IPv4_Address-ANDSF(To Be Assigned) 
   
        Length
   
                Length (in bytes) of the option excluding the 'Option
                Code' and the 'Length' fields; Length field is set to
                4N, where N is the number of IPv4 addresses carried in
                the option

        IP Address
   
                One or more IPv4 address(es) of ANDSF Server(s)

  ANDSF servers MUST be listed in order of preference and the client
  SHOULD process them in decreasing order of preference.
 
3. ANDSF IPv6 Address option for DHCPv6
   
  This section describes the ANDSF IPv6 Address Option for DHCPv6.
  The option layout is depicted below:


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Option Code            |          Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IP Address 1                              |
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IP Address N                              |
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Option Code
   
                OPTION-IPv6_Address-ANDSF (To Be Assigned)

        Length

                Length (in bytes) of the option excluding the 'Option
                Code' and the 'Length' fields; Length field is set to
                16N, where N is the number of IPv6 addresses carried
                in the option

        IP Address
   
                One or more IPv6 address(es) of ANDSF Server(s)
 
  ANDSF servers MUST be listed in order of preference and the client
  SHOULD process them in decreasing order of preference.

             
The use of DHCP in sections 4.1.1 and 4.2.1 needs a little more detail; can the mobile host initiate a DHCP message exchange for the ANDSF servers or does it piggyback on other DHCP message exchanges?

(From dhc WG review)
First, please delete sections 4.1.2 and 4.2.2.  DHCP option specifications should never specify DHCP server behavior unless server behavior is different than that defined in RFC3315 or RFC2131/2132.

In the security considerations section, you might want to add a reference to RFC3315, section 21, to complement the reference to RFC3118, which is DHCPv4-only.  Also, for the two-byte integer quantities, I think you should specify that they are in network byte order, to avoid confusion.

[Ballot discuss]
(Updated 2010-10-11, based on rev -05 {still apply to rev -06], added issues from dhc WG review)

The -05 rev has addressed most of my DISCUSS issues.  However, I think sections 2 and 3 still need work; I suggest the following text for sections 2 and 3 to clarify, simplify and bring into line with the definitions of DHCP options in other IETF documents:

2. ANDSF IPv4 Address Option for DHCPv4
   
  This section describes the ANDSF IPv4 Address Option for DHCPv4.
  The option layout is depicted below:

          Code Len    IPv4 Address 1    IPv4 Address 2
        +----+----+----+----+----+----+----+---------
        | XX | n  |a1  | a2 | a3 | a4 | a1 | ......
        +----+----+----+----+----+----+----+---------
   
        Option Code
   
                OPTION-IPv4_Address-ANDSF(To Be Assigned) 
   
        Length
   
                Length (in bytes) of the option excluding the 'Option
                Code' and the 'Length' fields; Length field is set to
                4N, where N is the number of IPv4 addresses carried in
                the option

        IP Address
   
                IPv4 address(es) of ANDSF Server(s)

  ANDSF servers MUST be listed in order of preference and the client
  SHOULD process them in decreasing order of preference.
 
3. ANDSF IPv6 Address option for DHCPv6
   
  This section describes the ANDSF IPv6 Address Option for DHCPv6.
  The option layout is depicted below:


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Option Code            |          Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IP Address 1                              |
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IP Address N                              |
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Option Code
   
                OPTION-IPv6_Address-ANDSF (To Be Assigned)

        Length

                Length (in bytes) of the option excluding the 'Option
                Code' and the 'Length' fields; Length field is set to
                16N, where N is the number of IPv6 addresses carried
                in the option

        IP Address
   
                IPv6 address(es) of ANDSF Server(s)
 
  ANDSF servers MUST be listed in order of preference and the client
  SHOULD process them in decreasing order of preference.

             
The use of DHCP in sections 4.1.1 and 4.2.1 needs a little more detail; can the mobile host initiate a DHCP message exchange for the ANDSF servers or does it piggyback on other DHCP message exchanges?

(From dhc WG review)
First, please delete sections 4.1.2 and 4.2.2.  DHCP option specifications should never specify DHCP server behavior unless server behavior is different than that defined in RFC3315 or RFC2131/2132.

In the security considerations section, you might want to add a reference to RFC3315, section 21, to complement the reference to RFC3118, which is DHCPv4-only.  Also, for the two-byte integer quantities, I think you should specify that they are in network byte order, to avoid confusion.

[Ballot comment]
(Updated 2010-10-11 based on rev -05)

Minor edit, correcting an error in text I had suggested: s/process/process the ANDSF option in the PRL/ in section 4.1.1 and 4.1.2

[Ballot discuss]
(Updated 2010-10-11, based on rev -05)

The -05 rev has addressed most of my DISCUSS issues.  However, I think sections 2 and 3 still need work; I suggest the following text for sections 2 and 3 to clarify, simplify and bring into line with the definitions of DHCP options in other IETF documents:

2. ANDSF IPv4 Address Option for DHCPv4
   
  This section describes the ANDSF IPv4 Address Option for DHCPv4.
  The option layout is depicted below:

          Code Len    IPv4 Address 1    IPv4 Address 2
        +----+----+----+----+----+----+----+---------
        | XX | n  |a1  | a2 | a3 | a4 | a1 | ......
        +----+----+----+----+----+----+----+---------
   
        Option Code
   
                OPTION-IPv4_Address-ANDSF(To Be Assigned) 
   
        Length
   
                Length (in bytes) of the option excluding the 'Option
                Code' and the 'Length' fields; Length field is set to
                4N, where N is the number of IPv4 addresses carried in
                the option

        IP Address
   
                IPv4 address(es) of ANDSF Server(s)

  ANDSF servers MUST be listed in order of preference and the client
  SHOULD process them in decreasing order of preference.
 
3. ANDSF IPv6 Address option for DHCPv6
   
  This section describes the ANDSF IPv6 Address Option for DHCPv6.
  The option layout is depicted below:


    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |      Option Code            |          Length              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IP Address 1                              |
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    IP Address N                              |
    .                                                              .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

        Option Code
   
                OPTION-IPv6_Address-ANDSF (To Be Assigned)

        Length

                Length (in bytes) of the option excluding the 'Option
                Code' and the 'Length' fields; Length field is set to
                16N, where N is the number of IPv6 addresses carried
                in the option

        IP Address
   
                IPv6 address(es) of ANDSF Server(s)
 
  ANDSF servers MUST be listed in order of preference and the client
  SHOULD process them in decreasing order of preference.

             
The use of DHCP in sections 4.1.1 and 4.1.2 needs a little more detail; can the mobile host initiate a DHCP message exchange for the ANDSF servers or does it piggyback on other DHCP message exchanges?

Checked diffs, they look OK and should resolve the discusses. I have some issues of my own, however. But waiting for the other ADs to clear.

[Ballot comment]
Cleared my Discuss after discussions with Jari who explained the meaning of the write-up and the history of the draft and the working group.

[Ballot discuss]
1) Need to add RFC 2119 as a normative reference.

2) Sec 5 (really hoping this is just a typo):

OLD:

It is recommended to use DHCP authentication option ...

NEW:

It is RECOMMENDED to use DHCP authentication option ...

My assumption is that you really do want to recommend (ala RFC 2119) language that the DHCP authentication optoin be used.

3) The last paragraph is troubling to me.  It says:

  In deployments where DHCP authentication is not available, 3GPP
  specific lower layer security services may be sufficient to protect
  DHCP messages. 3GPP ANDSF framework also provides additional
  mechanisms that protect message exchanges between ANDSF client and
  server at the higher layer.

I read that say yeah sometimes no authentication is provided sometimes lower layer services provide it sometimes they don't (i.e., the "may be sufficient part").  Shouldn't this be recommending that lower layer services be employed to ensure tat all the bad things you discussed don't happen?

In the 2nd sentence, what are these additional protections?  Are you saying that there are other mechanisms that can protect the exchange if DHCP authentication is not supported?  Shouldn't these be recommended in the case DHCP authentication isn't supported?

[Ballot discuss]
The current text is probably straightforward to DHCP experts, but it ambiguous to my reading in a number of places.
I think each of these issues can be easily addressed, though:

(1) I assume the length field is in bytes?  There is no indication, and a design where length equaled the number of
IPv4 addresses (in section 2) or IPv6 addresses (in section 3) would be plausible as well.

(2) Is zero a valid Length field?  That is, can the IP Address list be omitted?  Text in 4.1.1 and 4.2.1 ("If the mobile
node receives no address") could be interpreted that way, but there is no indication in Sections 2 or 3 that the
address list is optional.

(2a) Does the text "If the mobile node receives no address" mean the DHCP response did not contain the option,
or the option had zero addresses?  (This issue may be resolved above, if zero is *not* a legal Length.)

(3) The Security Considerations should note in paragraph 1 that a modified response could also be used to mount
an amplification attack.  By inserting the victim's address as the preferred ADNSP server, every node that wanted
network discover and selection assistance would begin by directing traffic to the victim.  Since the nodes would
eventually move on to the server with address "a2" (as shown in the figure immediately before section 3), the client
would experience minor delays but the victim could be significantly affected.

[Ballot discuss]
This Discuss does not require any action from the document authors.
I will eaither clear my position after discussions with the IESG or
convert it into an actionable Discuss.

I would like to discuss with the shepherding AD a paragraph from the
document write-up where it says...

  This document got a couple of reviews from WG members. The MIPSHOP
  WG has earlier worked on discovery of MIH servers. This specification
  is very similar to the specification on MIH server discovery using
  DHCP. More reviews would be nice, but considering that the document
  is not a MIPSHOP WG document and is very similar to earlier specs,
  it has sufficient reviews.

If this mechanism is "very similar" to work done by the working group
I would like to question why it is being published, and why it is
being progressed as an AD-sponsored standards track document. Does it
conflict with the working group's output? Why isn't it directed to the
WG?

[Ballot discuss]
This Discuss does not require any action from the document authors.
I will eaither clear my position after discussions with the IESG or
convert it into an actionable Discuss.

I would like to discuss witht he shepherding AD a paragraph from the
document write-up where it says...

  This document got a couple of reviews from WG members. The MIPSHOP
  WG has earlier worked on discovery of MIH servers. This specification
  is very similar to the specification on MIH server discovery using
  DHCP. More reviews would be nice, but considering that the document
  is not a MIPSHOP WG document and is very similar to earlier specs,
  it has sufficient reviews.

If this mechanism is "very similar" to work done by the working group
I would like to question why it is being published, and why it is
being progressed as an AD-sponsored standards track document. Does it
conflict with the working group's output? Why isn't it directed to the
WG?

[Ballot comment]
I find strange that this document relies on the reading and understanding of two 3GPP documents that are listed as Informational References. Moreover, if I access the two 3GPP documents they include standard notes that seem to indicate that this is work-in-progress:

'The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification'

I assume that the authors are knowleadgeable about the 3GPP processes and the degree of stability of the two referenced documents, but in case this is not the situation I recommend that the issue is revisited.

[Ballot comment]
These are still draft.....

1) Need to add RFC 2119 as a normative reference.

2) Sec 5:

OLD:

It is recommended to use DHCP authentication option ...

NEW:

It is RECOMMENDED to use DHCP authentication option ...

3) Last paragraph is troubling, what if those other mechanisms are not sufficent.

[Ballot discuss]
(Updated 2010-09-08, to include review by Ted Lemon at https://www.ietf.org/mailman/private/iesg/2010-September/078081.html)

The Introduction states that this document defines address list options and domain list options.  I only see the address list options.

What is the "ANDSF discovery procedure" referenced in section 4.1.1?

After reviewing the discussion of this document on the dhc WG mailing list, I think the issue of DHCP server behavior when that server has not been configured with any ANDSF server addresses has been resolved.  However, I don't think the current text accurately reflects the resolution of the issue.    Text in section 4.1.2 should be changed:

OLD:

  When the DHCP server receives an ANDSF IPv4 Address Option in the
  PRL, the DHCP server MUST include the option in its response
  messages (as defined in [RFC2131]and [RFC2132])that may contain a
  list of one or more IP addresses of the ANDSF server hosting the
  service.

NEW:

  When the DHCP server receives an ANDSF IPv4 Address Option in the
  PRL, the DHCP server MUST process and respond according to the
  behavior specified in RFC 2131.

Text in section 4.2.2 should also be changed:

OLD:

  When the DHCP Server receives an ANDSF IPv6 Address Option in the
  ORO, the DHCP server MUST include the option in its response (as
  defined in [RFC3315])that may contain a list of one or more IP
  addresses of the ANDSF server hosting the service.

NEW:

  When the DHCP Server receives an ANDSF IPv6 Address Option in the
  ORO, the DHCP server MUST process and respond according to the
  behavior specified in RFC 3315.

Ted: Strictly speaking, the correct thing to do is simply remove the
  text.  The base protocol spec already says what to do when you
  receive a PRL and have a value for the ANDSF option, and what to do
  if you do not.  If the goal is simply to remind the implementor to
  consult the RFC, this text might be better:

    DHCP clients MAY request the ANDSF IPv6 Address option in an ORO
    option.  DHCP server handling of ORO options is specified in
    RFC3115, section FOO.

  The same comment applies to the IPv4 option.

  Only if the server behavior or client behavior ought to be
  different ought there to be any text in the document talking about
  what to do when the ANDSF option appears in the PRL.  But we would
  tend to discourage this anyway, since options that require protocol
  changes to the DHCP protocol really are trying to fit a square peg
  into a round hole.

Suppose the host receives no DHCP messages with the ANDSF option?  Is it allowed to continue without performing the ANDSF function?

Ted: According to the DHCP protocol specs, it's allowed to consider
  offers from multiple servers before selecting a particular server,
  and this could be used as a criterion in making such a selection.
  However, this would require a custom DHCP client, and hence is not
  likely to be practical except in very restricted use cases.

  [Regardless of the chosen behavior], this document is probably not the place to
  specify that behavior.  As the abstract says, this document just
  defines the options--it doesn't specify a whole protocol.
  Presumably the protocol part is specified somewhere else, and it
  might well say "if no DHCP server responds with an ANDSF option, we
  can't make forward progress."  But that would be out of scope for
  this document.

The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs.  I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation.

[Ballot comment]
I think this text in section 4.1.1 should be clarified for alignment with RFC 2131:

  If the mobile node receives no address, it may either try another
  server or may continue to retransmit the PRL message. However, it
  MUST limit the rate at which it retransmits the message and limit
  the duration of the time during which it retransmits the message.

Ted: To be clear, I think you probably meant to say a DISCOVER or Solicit message containing a PRL, not a "PRL message."  :)

According to RFC 2131, the client collects DHCPOFFER responses to the DHCPDISCOVER message sent by the client.  These DHCPOFFER messages will contain the parameters to be assigned to the client.  I suggest editing the text in mipshop-andsf-dhcp-options to:

  The MN selects a DHCP server that has included an ANDSF option in
  its DHCPOFFER message.

mipshop-andsf-dhcp-options may choose to specify that the MN retransmits its DHCPDISCOVER message; however, it's unlikely to yield any different results beyond 2 or 3 retries (which will recover from an y lost DHCPDISCOVER messages).  These same comments apply to DHCPv6 operation.

Ted: Once the client has received offers, it's supposed to pick one, not
  retransmit.  It's true that if a client receives no satisfactory
  offers, it can keep trying, but the authors of the draft should
  think carefully about whether it makes sense to treat "no ANDSF
  option" as "not a satisfactory response."

  I don't know anything about the protocol, so I'm not qualified to
  say, but it seems unlikely--either you are always on a network that
  knows to send an ANDSF option, in which case this will never
  happen, or else you have to deal with the case where you are not on
  such a network, in which case retrying indefinitely probably isn't
  the right thing to do.

  If the authors do decide to go this route, the retransmission
  behavior is already specified in RFC2131 and RFC3115, so the draft
  should refer to those documents rather than repeating the text from
  those specifications.

I think the comment in section 5 about DHCP authentication mitigating DoS attacks is irrelevant to this document.

There are several missing or incorrect quotation marks in the References section.

[Ballot discuss]
(Updated 2010-09-08, to include review by Ted Lemon at https://www.ietf.org/mailman/private/iesg/2010-September/078081.html)

The Introduction states that this document defines address list options and domain list options.  I only see the address list options.

What is the "ANDSF discovery procedure" referenced in section 4.1.1?

After reviewing the discussion of this document on the dhc WG mailing list, I think the issue of DHCP server behavior when that server has not been configured with any ANDSF server addresses has been resolved.  However, I don't think the current text accurately reflects the resolution of the issue.    Text in section 4.1.2 should be changed:

OLD:

  When the DHCP server receives an ANDSF IPv4 Address Option in the
  PRL, the DHCP server MUST include the option in its response
  messages (as defined in [RFC2131]and [RFC2132])that may contain a
  list of one or more IP addresses of the ANDSF server hosting the
  service.

NEW:

  When the DHCP server receives an ANDSF IPv4 Address Option in the
  PRL, the DHCP server MUST process and respond according to the
  behavior specified in RFC 2131.

Text in section 4.2.2 should also be changed:

OLD:

  When the DHCP Server receives an ANDSF IPv6 Address Option in the
  ORO, the DHCP server MUST include the option in its response (as
  defined in [RFC3315])that may contain a list of one or more IP
  addresses of the ANDSF server hosting the service.

NEW:

  When the DHCP Server receives an ANDSF IPv6 Address Option in the
  ORO, the DHCP server MUST process and respond according to the
  behavior specified in RFC 3315.

Ted: Strictly speaking, the correct thing to do is simply remove the
  text.  The base protocol spec already says what to do when you
  receive a PRL and have a value for the ANDSF option, and what to do
  if you do not.  If the goal is simply to remind the implementor to
  consult the RFC, this text might be better:

    DHCP clients MAY request the ANDSF IPv6 Address option in an ORO
    option.  DHCP server handling of ORO options is specified in
    RFC3115, section FOO.

  The same comment applies to the IPv4 option.

  Only if the server behavior or client behavior ought to be
  different ought there to be any text in the document talking about
  what to do when the ANDSF option appears in the PRL.  But we would
  tend to discourage this anyway, since options that require protocol
  changes to the DHCP protocol really are trying to fit a square peg
  into a round hole.

Suppose the host receives no DHCP messages with the ANDSF option?  Is it allowed to continue without performing the ANDSF function?

Ted: According to the DHCP protocol specs, it's allowed to consider
  offers from multiple servers before selecting a particular server,
  and this could be used as a criterion in making such a selection.
  However, this would require a custom DHCP client, and hence is not
  likely to be practical except in very restricted use cases.

The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs.  I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation.

[Ballot comment]
1) Need to add RFC 2119 as a normative reference.

2) Sec 5:

OLD:

It is recommended to use DHCP authentication option ...

NEW:

It is RECOMMENDED to use DHCP authentication option ...

3) Last paragraph is troubling, what if those other mechanisms are not sufficent.

[Ballot comment]
Section 4.1.2, paragraph 1:
>    When the DHCP server receives an ANDSF IPv4 Address Option in the
>    PRL, the DHCP server MUST include the option in its response
>    messages (as defined in [RFC2131]and [RFC2132])that may contain a
>    list of one or more IP addresses of the ANDSF server hosting the
>    service.

  "MUST include an option that may contain..." is odd. Shouldn't the
  option be required to contain a list of IP addresses?


Section 4.2.1, paragraph 3:
>    If the mobile node receives no address, it may either try another
>    server or may continue to retransmit the ORO message. However, it
>    MUST limit the rate at which it retransmits the message and limit
>    the duration of the time during which it retransmits the message.

  Same issue as in the DISCUSS for Section 4.1.1.


Section 4.2.2, paragraph 1:
>    When the DHCP Server receives an ANDSF IPv6 Address Option in the
>    ORO, the DHCP server MUST include the option in its response (as
>    defined in [RFC3315])that may contain a list of one or more IP
>    addresses of the ANDSF server hosting the service.

  Same issue as in the comment for Section 4.1.2.


Section 5., paragraph 2:
>    It is recommended to use DHCP authentication option described in
>    [RFC3118] where available.

  s/recommended/RECOMMENDED? (?)

[Ballot discuss]
Section 4.1.1, paragraph 3:
>    If the mobile node receives no address, it may either try another
>    server or may continue to retransmit the PRL message. However, it
>    MUST limit the rate at which it retransmits the message and limit
>    the duration of the time during which it retransmits the message.

  DISCUSS: What is the purpose of retransmitting the request to the DHCP
  server if the MN doesn't receive the response it asked for? It's not
  like the DHCP server will suddenly include the requested response next
  time. (And also, you'd need to more fully specify the rate and cutoff
  for these retransmissions if this mechanism stays in - requiring an
  otherwise unspecified scheme is not enough.)

[Ballot comment]
I think this text in section 4.1.1 should be clarified for alignment with RFC 2131:

  If the mobile node receives no address, it may either try another
  server or may continue to retransmit the PRL message. However, it
  MUST limit the rate at which it retransmits the message and limit
  the duration of the time during which it retransmits the message.

According to RFC 2131, the client collects DHCPOFFER responses to the DHCPDISCOVER message sent by the client.  These DHCPOFFER messages will contain the parameters to be assigned to the client.  I suggest editing the text in mipshop-andsf-dhcp-options to:

  The MN selects a DHCP server that has included an ANDSF option in
  its DHCPOFFER message.

mipshop-andsf-dhcp-options may choose to specify that the MN retransmits its DHCPDISCOVER message; however, it's unlikely to yield any different results beyond 2 or 3 retries (which will recover from an y lost DHCPDISCOVER messages).  These same comments apply to DHCPv6 operation.

I think the comment in section 5 about DHCP authentication mitigating DoS attacks is irrelevant to this document.

There are several missing or incorrect quotation marks in the References section.

[Ballot discuss]
(Updated 2010-09-07)

The Introduction states that this document defines address list options and domain list options.  I only see the address list options.

What is the "ANDSF discovery procedure" referenced in section 4.1.1?

After reviewing the discussion of this document on the dhc WG mailing list, I think the issue of DHCP server behavior when that server has not been configured with any ANDSF server addresses has been resolved.  However, I don't think the current text accurately reflects the resolution of the issue.    Text in section 4.1.2 should be changed:

OLD:

  When the DHCP server receives an ANDSF IPv4 Address Option in the
  PRL, the DHCP server MUST include the option in its response
  messages (as defined in [RFC2131]and [RFC2132])that may contain a
  list of one or more IP addresses of the ANDSF server hosting the
  service.

NEW:

  When the DHCP server receives an ANDSF IPv4 Address Option in the
  PRL, the DHCP server MUST process and respond according to the
  behavior specified in RFC 2131.

Text in section 4.2.2 should also be changed:

OLD:

  When the DHCP Server receives an ANDSF IPv6 Address Option in the
  ORO, the DHCP server MUST include the option in its response (as
  defined in [RFC3315])that may contain a list of one or more IP
  addresses of the ANDSF server hosting the service.

NEW:

  When the DHCP Server receives an ANDSF IPv6 Address Option in the
  ORO, the DHCP server MUST process and respond according to the
  behavior specified in RFC 3315.

Suppose the host receives no DHCP messages with the ANDSF option?  Is it allowed to continue without performing the ANDSF function?

The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs.  I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation.

[Ballot discuss]
The Introduction states that this document defines address list options and domain list options.  I only see the address list options.

What is the "ANDSF discovery procedure" referenced in section 4.1.1?

The requesting node behavior and the DHCP server behavior defined in the document may be inconsistent.  The server behavior is described as  "MUST include the option in it's response message" while the behavior for the client is described in the case where no address is received. 

Suppose the host receives no DHCP messages with the ANDSF option?  Is it allowed to continue without performing the ANDSF function?

The formats of the diagrams describing the options are internally inconsistent and inconsistent with the diagrams in other DHCP RFCs.  I mention this issue here (rather than a COMMENT) because of the potential for misinterpretation and incorrect implementation.

IANA understands that pon approval of this document there will be two IANA Actions that must be completed.

First, in the BOOTP Vendor Extensions and DHCP Options subregistry in
the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol
(BOOTP) Parameters registry located at:

http://www.iana.org/assignments/bootp-dhcp-parameters/bootp-dhcp-parameters.xhtml

a single registration must be completed.

Tag: [TBD]
Name: OPTION-IPv4_Address-ANDSF
Data Length: 2
Meaning: ANDSF IPv4 Address Option for DHCPv4
Reference:

Second, in the DHCP Option Codes subregistry in the Dynamic Host
Configuration Protocol for IPv6 (DHCPv6) registry located at:

http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml#dhcpv6-parameters-2

a single registration must be completed.

Tag: [TBD]
Description: OPTION-IPv6_Address-ANDSF
Reference:

IANA understands that these are the only actions that need to be
completed upon approval of the document.

I have looked at the new version and the preceding discussion. I think the draft is in very good shape and can move forward. I have asked IETF last call to be initiated.

I have reviewed this draft.

It is basically in good shape and can move forward. I had one major technical question which we can hopefully resolve easily with the help of DHCP experts, and two relatively minor updates to the security considerations text.

I will ask the DHC WG to review this draft as well, and would also like to ask the authors to revise the draft according to the comments as soon as possible.

Technical:

> In case that the server cannot find any ANDSF Server satisfying
> the requested Option Code, the server MUST return the ANDSF Option
> by setting the Option Code to the requested Option Code and the
> length of the Option to 0.

This seems to be in conflict with advice from RFC 3315:

  If the client has included
  an Option Request option in the Solicit message, the server includes
  options in the Advertise message containing configuration parameters
  for all of the options identified in the Option Request option that
  the server has been configured to return to the client.

In other words, do we return empty options, or no options, for the stuff that the server does not recognize or does not have configuration information for?

This issue may exist on the DHCPv4 side as well.

I would like to ask the DHCP experts to explain what the recommended approach is here. (The draft will need to be reviewed by the DHC working group anyway.)

> 7. Security Considerations

The security considerations text should probably highlight the importance of securing the actual ANDSF as opposed to securing merely the discovery phase. This way you can also avoid reliance on recommending something that is not in practice going to happen (DHCP authentication).

> In deployments where DHCP authentication is not available, 3GPP
> specific lower layer security services may be sufficient to protect
> DHCP messages.

... except in non-3GPP network access scenarios :-) I would suggest simply saying "... specific link layer security services may be sufficient ..."


Editorial:

> ANDSF is specified in [3GPPTS23.402].
I'd prefer to not have references in the abstract so that it can stand on its own. Perhaps this sentence can be removed and only retained in the introduction?

> and selection assistance data to the mobile nodes for multi-access
>   
> network scenarios where 3GPP access-network level solutions are not

Extra empty line.

>    selection of non-3GPP networks[3GPPTS23.402].

missing space between the last word and the "[" character.

> When the DHCP server receives either an ANDSF IPv4 Address Option or
> ANDSF Domain Name List Option in the PRL, the DHCP server MUST
> Include the option in its response messages (as defined in [RFC2131])
> that may contain a list of one or more IP addresses or a list of one
> or more FQDNs of the ANDSF server hosting the service.

I thought that the server's PRL behaviour was actually defined in RFC2132. But I could be mistaken.

>  6.2.1 Mobile node behavior

Different indentation (spaces before the section number) confuses the IETF tools document htmlization.

>    This document also defines two DHCPv6 options as described in
>    Sections
>  4 and 5.

Indentation problems.

>    [3GPP TS23.402] www.3gpp.org/ftp/Specs/html-info/23402.htm
>                    3GPP TS 23.402 V8.8.0 (2009-12): Architecture
>                    enhancements for non-3GPP accesses (Release 8)
>                   
>    [3GPP Ts 24.302] www.3gpp.org/ftp/Specs/html-info/24302.htm
>                    3GPP TS 24.302 V8.4.1 (2009-12): Access to the 3GPP
>                    Evolved Packet Core (EPC) via non-3GPP access
>                    networks; Stage 3;(Release 8)

Inconsistent capitalization and spacing.

Jari

(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?

Vijay Devarapalli is the Document Shepherd for this document. I
have reviewed the document and it is ready for forwarding to the
IESG 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?

This document got a couple of reviews from WG members. The MIPSHOP WG has
earlier worked on discovery of MIH servers. This specification is very
similar to the specification on MIH server discovery using DHCP. More
reviews would be nice, but considering that the document is not a MIPSHOP WG
document and is very similar to earlier specs, it has sufficient reviews.

(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?

None.

(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 specific concerns.

(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?

Not applicable.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize 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.

(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? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document meets all the requirements. No nits found.

(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].

The document splits the references into normative and
informative references.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations 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 [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

The IANA considerations section exists and is consistent with
the body of the document. The document requests reservations in
the appropriate IANA registries. The IANA registries that need to
be modified/created are clearly identified.

(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?

Does not apply.

(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.

This document defines new Dynamic Host Configuration Protocol (DHCPv4 and
DHCPv6) options to enable a mobile node to discover Access Network Discovery
and Selection Function (ANDSF) entities in an IP network. ANDSF is being
developed in 3GPP and provide inter-system mobility policies and access
network specific information to the mobile nodes (MNs).

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

None.

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?

There are no known implementations or vendor plans to implement
the specification.

Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are .'

Document shepherd: Vijay Devarapalli
Responsible AD: Jari Arkko