[Dime] #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent
<lionel.morand@orange-ftgroup.com> Sat, 21 August 2010 03:53 UTC
Return-Path: <lionel.morand@orange-ftgroup.com>
X-Original-To: dime@core3.amsl.com
Delivered-To: dime@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050323A6781 for <dime@core3.amsl.com>; Fri, 20 Aug 2010 20:53:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.835
X-Spam-Level:
X-Spam-Status: No, score=-102.835 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhd6HqdlWkEe for <dime@core3.amsl.com>; Fri, 20 Aug 2010 20:53:07 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AFA183A635F for <dime@ietf.org>; Fri, 20 Aug 2010 20:53:06 -0700 (PDT)
Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DCE09768009 for <dime@ietf.org>; Sat, 21 Aug 2010 05:56:25 +0200 (CEST)
Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id CB946768008 for <dime@ietf.org>; Sat, 21 Aug 2010 05:56:25 +0200 (CEST)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sat, 21 Aug 2010 05:53:40 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sat, 21 Aug 2010 05:53:37 +0200
Message-ID: <D109C8C97C15294495117745780657AE0CC0EC35@ftrdmel1>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent
Thread-Index: Acs5+DNGJcrHMeZRQludAQSkE/zi4wG7C0mA
From: lionel.morand@orange-ftgroup.com
To: dime@ietf.org
X-OriginalArrivalTime: 21 Aug 2010 03:53:40.0454 (UTC) FILETIME=[711B8060:01CB40E4]
Subject: [Dime] #6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2010 03:53:08 -0000
#6: Review from Avi Lior: Issue on changing the semantics of Redirection-Agent ----------------------------------------------+------------------------- ----------------------------------------------+---- Reporter: lionel.morand@... | Owner: Type: defect | Status: new Priority: major | Milestone: Component: realm-based-redirect | Version: Severity: In WG Last Call | Keywords: ----------------------------------------------+------------------------- ----------------------------------------------+---- I have reviewed draft-ietf-dime-realm-based-redirect-03 document -- or I should say i started but I had to stop because there are serious fundamental issues with this draft. I should start with the fact that i think the problem statement raised by the draft is valid. Also, I think that Diameter base 3588 should have supported Realm based redirection as well as host based redirection. Actually Realm-based redirection are probably more useful. However, the problem I am having is that the draft is changing the semantics of a Redirect Agent as defined by base and I dont think that we should be allowed to do that. I get that the draft got around backwards capability issue surrounding the new AVPs be introduced by asserting that only new applications will support the attributes. But in order to deliver this feature in 3588 the behavior of the Redirect Agent had to change. This new redirect agent has to differentiate between applications that do support realm base redirection vs non-realmbased redirection. This is new base behavior and thus should be done in Diameter V2 There is an alternative - which i thought was the approach taken when i started to read the draft and that is: -let the Application itself perform the redirection. To use the example provided, if the operator does not want to host the application anymore, it can let the Application respond back with the realm and/host redirection attributes. -- Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/6> dime <http://tools.ietf.org/wg/dime/>
- [Dime] #6: Review from Avi Lior: Issue on changin… lionel.morand
- Re: [Dime] [dime] #6: Review from Avi Lior: Issue… dime issue tracker