DHCP Options for the Port Control Protocol (PCP)
draft-ietf-pcp-dhcp-13
Yes
(Ted Lemon)
No Objection
(Alia Atlas)
(Barry Leiba)
(Brian Haberman)
(Jari Arkko)
(Martin Stiemerling)
(Spencer Dawkins)
Abstain
Note: This ballot was opened for revision 11 and is now closed.
Ted Lemon Former IESG member
Yes
Yes
(for -11)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-04-06 for -11)
Unknown
The first para of the Introduction says This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options that can be used to provision PCP server [RFC6887] IP addresses. Of course, you mean that the addresses are stable and are provided as information to the clients. You don't mean that the addresses are provisioned into the server. The Abstract has this a bit better, and I suggest you say something like... This document defines DHCPv4 [RFC2131] and DHCPv6 [RFC3315] options that can be used to inform PCP clients of PCP server [RFC6887] IP addresses.
Alia Atlas Former IESG member
No Objection
No Objection
(for -11)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(2014-04-08 for -11)
Unknown
Good document, looking forward to the resolution of Stephen's questions and Brian's question about the normative reference.
Barry Leiba Former IESG member
No Objection
No Objection
(for -11)
Unknown
Brian Haberman Former IESG member
(was Discuss)
No Objection
No Objection
(for -12)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -12)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2014-04-09 for -11)
Unknown
I support Stephen's position
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -11)
Unknown
Pete Resnick Former IESG member
(was Discuss)
No Objection
No Objection
(2014-04-14)
Unknown
Thanks for addressing my comments.
Richard Barnes Former IESG member
No Objection
No Objection
(2014-04-09 for -11)
Unknown
I agree with Pete's DISCUSS. Either the servers are functionally equivalent, in which case you don't need to distinguish between their addresses, or they're not, in which case you need to provide the client some way to tell which to use. The document currently distinguishes between servers without telling the client how to pick one.
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -11)
Unknown
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2014-04-15)
Unknown
Thanks for handling my discuss #1 and bringing the other point to the attention of the WG. ------- OLD COMMENTS - I agree with Brian's discuss point #2 about the normative reference. - section 1: I didn't get the meaning of the last sentence here. - section 3: The multiple lists thing seems over complex to me but I guess the WG discussed that and the DHC folks are presumably ok with it too. - 3.2: Extracting an IPv4 address from an IPv4-mapped (doesn't that need a ref?) IPv6 address seems quite hacky. Might be good to a) say more about how to do that in general and b) say why you need to do it.
Joel Jaeggli Former IESG member
Abstain
Abstain
(2014-04-09 for -11)
Unknown
ipv6 mapped ipv4 addresses are a serious liability and I would vastly prefer to see those dropped as the mechanism for employing them is elided anyway. that said iwill not block publication on that basis.