Skip to main content

DHCPv4 and DHCPv6 Options for Access Network Discovery and Selection Function (ANDSF) Discovery
draft-das-mipshop-andsf-dhcp-options-07

Yes

(Jari Arkko)

No Objection

(Peter Saint-Andre)
(Ralph Droms)
(Ron Bonica)
(Sean Turner)
(Stewart Bryant)

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

Jari Arkko Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
(was Discuss) No Objection
No Objection (2010-09-09) Unknown
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 Former IESG member
No Objection
No Objection (2010-09-05) Unknown
I think the document would benefit from more clearly stating the need for new DHCP options.
Dan Romascanu Former IESG member
No Objection
No Objection (2010-09-09) Unknown
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.
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection (2010-09-08) Unknown
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? (?)
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2010-10-26) Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection (2010-09-09) Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
(was Discuss) No Objection
No Objection (2010-09-09) Unknown
The length of the address field is probably obvious to most readers, but specifying it wouldn't hurt.