RADIUS Option for the DHCPv6 Relay Agent
draft-ietf-dhc-dhcpv6-radius-opt-14
Yes
(Ted Lemon)
No Objection
(Adrian Farrel)
(Gonzalo Camarillo)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Richard Barnes)
(Stewart Bryant)
Note: This ballot was opened for revision 12 and is now closed.
Jari Arkko Former IESG member
Yes
Yes
(2013-05-29 for -12)
Unknown
This is a useful document - thank you for writing it. I have one comment that is indeed a comment only, not a blocking issue. It relates to how the attribute is designed. It is my belief additional interoperability could perhaps been achieved, if you had used the Diameter attribute format. This would have allowed carrying both RADIUS and Diameter attributes (see http://tools.ietf.org/html/rfc6733#section-4.1), at the cost of only a few bytes. (It is of course also possible to define a separate DHCP option for carrying Diameter attributes, perhaps in a separate document.) Did the authors or the working group consider this design choice, or work out what the implications would have been? Or are there existing specifications or other reasons (such as practices on the DHCPv4 side) that dictate the particular design chosen in the draft?
Ted Lemon Former IESG member
Yes
Yes
(for -12)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -12)
Unknown
Barry Leiba Former IESG member
No Objection
No Objection
(2013-05-28 for -12)
Unknown
To the document shepherd: I found the shepherd writeup for this document to be particularly good; thanks, Tomek, for being clear and thorough.
Benoît Claise Former IESG member
No Objection
No Objection
(2013-05-30 for -12)
Unknown
I guess the answer is yes, but let me make sure... Does this mechanism support the RADIUS protocol extensions (RFC 6929)? Regards, Benoit
Brian Haberman Former IESG member
No Objection
No Objection
(2013-05-29 for -12)
Unknown
I support Spencer's DISCUSS points on the use of SHOULDs vs/ MUSTs. One way to clarify why SHOULDs are appropriate would be to add an example exception case where the options are not included.
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -12)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -12)
Unknown
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -12)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(for -12)
Unknown
Richard Barnes Former IESG member
No Objection
No Objection
(for -12)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2013-07-19 for -13)
Unknown
Thanks for dealing with my discuss point.
Spencer Dawkins Former IESG member
(was Discuss)
No Objection
No Objection
(2013-07-05 for -13)
Unknown
Thank you for resolving my DISCUSS comments.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2013-07-10 for -13)
Unknown
Thanks for handling my discuss points. I didn't check if the comments below still applied so I'll leave them there just in case it helps someone sometime:-) --- old comments: abstract: this is very unclear to me, having read it the spec could be about three or four different things, but I'm none the wiser. It should say that this is for when the RADIUS client is the DHCP relay and wants to tell the DHCP server about RADIUS stuff. section 1: This bit needs a rewrite. "In that case the NAS directly responds the DHCPv6 messages as per the indication conveyed by the attributes in the Access-Accept message from the RADIUS server."
Stewart Bryant Former IESG member
No Objection
No Objection
(for -12)
Unknown