Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10

Jouni - ...for all the RADIUS attributes the client included in the request.

The DHCPv6 client never include the RADIUS attribute in this draft, the
DHCPv6 relay include the RADIUS attribute from the RADIUS client.

Ted - So it's the relay that may need to deal with an inappropriate response
from the DHCP server?
Tomek - DHCPv6 Server will never send this option back,...

Tomek's words sounds right in most cases, including those cases described in
Fig.1 & 2 of the draft.

Best Regards,
Leaf

-----Original Message-----
From: radext-bounces@ietf.org [mailto:radext-bounces@ietf.org] On Behalf Of
Ted Lemon
Sent: Tuesday, April 09, 2013 10:36 PM
To: Tomek Mrugalski
Cc: <dhcwg@ietf.org>; <radext@ietf.org>
Subject: Re: [radext] [dhcwg] draft-ietf-dhc-dhcpv6-radius-opt-10

On Apr 9, 2013, at 10:31 AM, Tomek Mrugalski <tomasz.mrugalski@gmail.com>
 wrote:
> On 09.04.2013 11:59, Jouni Korhonen wrote:
>> What I am after is a note stating that a _client_ must be prepared 
>> for a reply from a server that does not provide adequate 
>> response/information for all the RADIUS attributes the client 
>> included in the request. This is solely meant for the future 
>> specifications using the OPTION_RADIUS.
> When clarifying that, we must remember to be explicit about which 
> client or server (radius or dhcpv6) we are talking about here.
> 
> Here's DHCPv6 point of view: This DHCPv6 option will never reach 
> DHCPv6 client. DHCPv6 client will never send it either. DHCPv6 Server 
> will never send this option back, just receive it from the DHCPv6 relay.

Oops, right.   So it's the relay that may need to deal with an inappropriate
response from the DHCP server?

_______________________________________________
radext mailing list
radext@ietf.org
https://www.ietf.org/mailman/listinfo/radext