IETF Logo Mail Archive

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

Ted Lemon <Ted.Lemon@nominum.com> Tue, 09 April 2013 14:35 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982EB21F9357; Tue, 9 Apr 2013 07:35:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.55
X-Spam-Level:
X-Spam-Status: No, score=-106.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BSOzZevwmguN; Tue, 9 Apr 2013 07:35:48 -0700 (PDT)
Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC2121F9351; Tue, 9 Apr 2013 07:35:47 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQnQtaR+E9czanszywpIslpm4ntl344@postini.com; Tue, 09 Apr 2013 07:35:48 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id C28AF1B84E5; Tue, 9 Apr 2013 07:35:46 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id BAD5A190061; Tue, 9 Apr 2013 07:35:46 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 07:35:46 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wIABnQAAgABL5wCAAAE1gA==
Date: Tue, 09 Apr 2013 14:35:45 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B63077513A692@mbx-01.win.nominum.com>
References: <CAC8SSWtBMyDgShEDofyUjgcBiQ_ttY_DUbDNHnhhnf531+9XXA@mail.gmail.com> <FB413294-CF61-4AD9-AF26-41EC8A30DF37@gmail.com> <5162d5aa.0794420a.2f19.fffff597@mx.google.com> <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com> <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com> <AC349589-AC7B-442B-9CE8-D7343BC44BCC@gmail.com> <5164263E.50402@gmail.com>
In-Reply-To: <5164263E.50402@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <6BA4DDBD5FC67D419AD2C9532C274349@nominum.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "<dhcwg@ietf.org>" <dhcwg@ietf.org>, "<radext@ietf.org>" <radext@ietf.org>
Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Apr 2013 14:35:49 -0000

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?

v2.23.0 | Report a Bug | By Email