RADIUS Option for the DHCPv6 Relay Agent
RFC 7037

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

(Jari Arkko) Yes

Comment (2013-05-29 for -12)
No email
send info
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) Yes

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-05-30 for -12)
No email
send info
I guess the answer is yes, but let me make sure...
Does this mechanism support the RADIUS protocol extensions (RFC 6929)?

Regards, Benoit

(Spencer Dawkins) (was Discuss) No Objection

Comment (2013-07-05 for -13)
No email
send info
Thank you for resolving my DISCUSS comments.

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss) No Objection

Comment (2013-07-10 for -13)
No email
send info
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

--- 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."

(Brian Haberman) No Objection

Comment (2013-05-29 for -12)
No email
send info
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.

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2013-05-28 for -12)
No email
send info
To the document shepherd: I found the shepherd writeup for this document to be particularly good; thanks, Tomek, for being clear and thorough.

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection

Comment (2013-07-19 for -13)
No email
send info
Thanks for dealing with my discuss point.