IETF Logo Mail Archive

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

"Bernie Volz (volz)" <volz@cisco.com> Mon, 08 April 2013 16:25 UTC

Return-Path: <volz@cisco.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 CFA9121F9415; Mon, 8 Apr 2013 09:25:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level:
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
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 uSkG9IYVZlwU; Mon, 8 Apr 2013 09:25:06 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 21F2421F9410; Mon, 8 Apr 2013 09:25:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10677; q=dns/txt; s=iport; t=1365438306; x=1366647906; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rSbWy5PtlFkWtIXPnP0IpjxpUlWka2brqqj7J6cFBpc=; b=OUfAP3BThx1konH0gy7bGxdGntnWio15F2EqP1nK4QdzFkPhEz7NHHtM nitCXyANZKu4kamGUrVhTblrqH1+5dpBkZt2oSWqSMy/xC9H8eJrvVLuB 8UjKwjrq8FBNb/y3SEq2lt2mxc6vGCpaxVWeIV5hi20QMxY0YZZ1HScqk c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Ai0FAIruYlGtJXG8/2dsb2JhbABRgkJENsEsgQoWdIIfAQEBAwEtTAULAgEIEQQBAQsdByERFAkIAgQBDQUIh3oDCQazMQ2JXYkLg0WCIjEGAYJgYQOVE41UhRuDC4Io
X-IronPort-AV: E=Sophos; i="4.87,432,1363132800"; d="scan'208,217"; a="196286228"
Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 08 Apr 2013 16:25:05 +0000
Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r38GP5TL025192 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Apr 2013 16:25:05 GMT
Received: from xmb-rcd-x04.cisco.com ([169.254.8.60]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 8 Apr 2013 11:25:05 -0500
From: "Bernie Volz (volz)" <volz@cisco.com>
To: Ted Lemon <Ted.Lemon@nominum.com>, Leaf Yeh <leaf.yeh.sdo@gmail.com>
Thread-Topic: [dhcwg] [radext] draft-ietf-dhc-dhcpv6-radius-opt-10
Thread-Index: AQHONCshVSG79PrhReiNj3Ln9NlMtJjM2WGAgAAS14D//5W4wA==
Date: Mon, 08 Apr 2013 16:25:04 +0000
Message-ID: <489D13FBFA9B3E41812EA89F188F018E184EBA72@xmb-rcd-x04.cisco.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>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B630775138825@mbx-01.win.nominum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.86.252.121]
Content-Type: multipart/alternative; boundary="_000_489D13FBFA9B3E41812EA89F188F018E184EBA72xmbrcdx04ciscoc_"
MIME-Version: 1.0
Cc: "<radext@ietf.org>" <radext@ietf.org>, 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: Mon, 08 Apr 2013 16:25:07 -0000

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


-          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<mailto: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.

v2.23.0 | Report a Bug | By Email