IETF Logo Mail Archive

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

Jouni Korhonen <jouni.nospam@gmail.com> Tue, 09 April 2013 09:59 UTC

Return-Path: <jouni.nospam@gmail.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 047B621F8E7B; Tue, 9 Apr 2013 02:59:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 znFejwvlgUwc; Tue, 9 Apr 2013 02:59:51 -0700 (PDT)
Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id E71A221F9123; Tue, 9 Apr 2013 02:59:50 -0700 (PDT)
Received: by mail-ee0-f54.google.com with SMTP id e51so2852301eek.13 for <multiple recipients>; Tue, 09 Apr 2013 02:59:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=UctFiYFhFkf420aVPuD7z9Ywc0RckOWP0YwOtSpdUAs=; b=x0+haXdgxbMjSnezNNmAthUD7nWXHssMkFVcmk5iM/dnvHULeA6Gyk0ZYNRzonRh0w bzxIbHtjQ8iq+yZGOObLLxMlt7A/rTUb0jCt9GB6Up6QSK7DcOFBYQEBqWKxD73ruEz9 uw/G/VW4XxnIw9WaY/MbA+sPS0A6IhScF9LdVmyOubBB6+KPXsipoDCAFxUo+bKm2dT1 vnObuhk6NOfAVL8QqbDIbrl4317InbRypg7dyWoHFzcM5X2ei4CINUCSYWxr/xYbbVnZ xqGGNuACuR29iilJHdQvuibiW0Zd8FvyhrT+Z8+Es0iFA6i+uE5s5IC+aGYQSbiAB4LI FkCQ==
X-Received: by 10.14.216.2 with SMTP id f2mr58460601eep.44.1365501589930; Tue, 09 Apr 2013 02:59:49 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:39c5:a766:d0ea:341d? ([2001:1bc8:101:f101:39c5:a766:d0ea:341d]) by mx.google.com with ESMTPS id cd3sm27182663eeb.6.2013.04.09.02.59.48 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Apr 2013 02:59:49 -0700 (PDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.com>
Date: Tue, 09 Apr 2013 12:59:46 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <AC349589-AC7B-442B-9CE8-D7343BC44BCC@gmail.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>
To: Bernie Volz <volz@cisco.com>
X-Mailer: Apple Mail (2.1503)
Cc: "<radext@ietf.org>" <radext@ietf.org>, Ted Lemon <Ted.Lemon@nominum.com>, dhcwg <dhcwg@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 09:59:52 -0000

On Apr 8, 2013, at 7:25 PM, Bernie Volz (volz) <volz@cisco.com> wrote:

> (This is with chair hat off! I have to remember to indicate that.)
>  
> > having the server reflect the option back is easy
>  
> The ERO option can be specified to cause the server to send back the option to the relay. I don’t think we want to server to “change” the data in the option.
>  
> I wonder whether Jouni’s concern is that the server may not send the client the correct response? But in that case

This is my concern and yes, it is not a concern of this document but the future documents using the OPTION_RADIUS.

> you need to assure your server is updated accordingly (to use the new Radius attribute) and I don’t see that this is really a concern for this document?
> 
> We can’t assume servers would know how to do something for something that is not yet defined. The “old” server ignoring the attribute in the option is the correct action until it is updated.

Sure.

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.

- JOuni

>  
> -          Bernie
>  
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ted Lemon
> Sent: Monday, April 08, 2013 11:42 AM
> To: Leaf Yeh
> Cc: <radext@ietf.org>; dhcwg
> Subject: Re: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
>  
> On Apr 8, 2013, at 10:34 AM, Leaf Yeh <leaf.yeh.sdo@gmail.com> wrote:
> Jouni - it is possible in future when new attributes get added to registry server silently discarding attributes may lead to a situation where the server fails to provide enough information back to relay.
>  
> Also, having the server reflect the option back is easy; having it make changes to the option is actually a protocol update, and probably not a good idea.
>  
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

v2.23.0 | Report a Bug | By Email