Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-radius-opt-03.txt

["Gaurav Halwasia (ghalwasi)" <[e-mail]>]

Gaurav - * Section 4 heading could say "DHCPv6 OPTION_RADIUS option"
Editorial. How about "DHCPv6 RADIUS option"? 
[Gaurav] Yes, this looks good as well. Just "OPTION_RADIUS" was looking odd.

Gaurav - * Section 4 says, " only the attributes listed in the table below may be included in the OPTION_RADIUS ". What about any other attributes which might be required in future.? Are you suggesting that a new specification will be required to include any other attribute in DHCPv6 RADIUS_OPTION option.? IMO,  keeping the attribute list open for the implementer will increase the usability of this mechanism. I think this specification can just mention the attributes as one of the use-case. 

Editorial. I adopted the roughly same text in my draft as that in the section 4 of RFC4014.

 <quote>To avoid dependencies between the address allocation and other state
   information between the RADIUS server and the DHCP server, the DHCP
   relay agent SHOULD include only the attributes in the table below in
   an instance of the RADIUS Attributes suboption.</quote>

I need consult with the chair to work out a solution for your concern.
[Gaurav] I understand you have borrowed this text from RFC4014. But I still think that keeping the attribute space unrestricted will be good.  Anyhow, let me know when you arrive at any conclusion regarding this based upon your discussion with chair.

Gaurav -* Section 5, "Relay Agent Behavior" says " The relay agent MUST silently discard OPTION_RADIUS
   if received. ". Can you explain about it little more and what is your proposal keeping "Relay Chaining" in mind.?

Technical. Good point. How about ''The relay agent MUST silently discard OPTION_RADIUS if received in the RELAY-REPL (13) message." 
[Gaurav] I am fine with this text.