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

Note: This ballot was opened for revision 07 and is now closed.

(Jari Arkko) Yes

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) (was Discuss) No Objection

(Lars Eggert) (was Discuss) No Objection

Comment (2010-09-08)
No email
send info
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? (?)

(Adrian Farrel) (was Discuss) No Objection

Comment (2010-09-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

Alexey Melnikov No Objection

Comment (2010-09-05 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
I think the document would benefit from more clearly stating the need for new DHCP options.

(Tim Polk) (was Discuss) No Objection

Comment (2010-09-09)
No email
send info
The length of the address field is probably obvious to most readers, but specifying it wouldn't hurt.

(Dan Romascanu) No Objection

Comment (2010-09-09 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.

(Peter Saint-Andre) No Objection

(Sean Turner) (was Discuss) No Objection