Skip to main content

RADIUS Option for the DHCPv6 Relay Agent
RFC 7037

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 steering group member) Yes

Yes (2013-05-29 for -12)
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 steering group member) Yes

Yes (for -12)

                            

(Adrian Farrel; former steering group member) No Objection

No Objection (for -12)

                            

(Barry Leiba; former steering group member) No Objection

No Objection (2013-05-28 for -12)
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 steering group member) No Objection

No Objection (2013-05-30 for -12)
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 steering group member) No Objection

No Objection (2013-05-29 for -12)
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 steering group member) No Objection

No Objection (for -12)

                            

(Joel Jaeggli; former steering group member) No Objection

No Objection (for -12)

                            

(Martin Stiemerling; former steering group member) No Objection

No Objection (for -12)

                            

(Pete Resnick; former steering group member) No Objection

No Objection (for -12)

                            

(Richard Barnes; former steering group member) No Objection

No Objection (for -12)

                            

(Sean Turner; former steering group member) (was Discuss) No Objection

No Objection (2013-07-19 for -13)
Thanks for dealing with my discuss point.

(Spencer Dawkins; former steering group member) (was Discuss) No Objection

No Objection (2013-07-05 for -13)
Thank you for resolving my DISCUSS comments.

(Stephen Farrell; former steering group member) (was Discuss) No Objection

No Objection (2013-07-10 for -13)
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 steering group member) No Objection

No Objection (for -12)