Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03

Avi Lior <avi@bridgewatersystems.com> Mon, 16 August 2010 21:11 UTC

Return-Path: <avi@bridgewatersystems.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 095523A6AB9 for <dime@core3.amsl.com>; Mon, 16 Aug 2010 14:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 mGEdum1TpSXN for <dime@core3.amsl.com>; Mon, 16 Aug 2010 14:11:41 -0700 (PDT)
Received: from mail200.messagelabs.com (mail200.messagelabs.com [216.82.254.195]) by core3.amsl.com (Postfix) with ESMTP id E38483A6AC6 for <dime@ietf.org>; Mon, 16 Aug 2010 14:11:40 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: avi@bridgewatersystems.com
X-Msg-Ref: server-15.tower-200.messagelabs.com!1281993135!77460713!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [72.35.6.119]
Received: (qmail 13471 invoked from network); 16 Aug 2010 21:12:16 -0000
Received: from mail.bridgewatersystems.com (HELO webmail.bridgewatersystems.com) (72.35.6.119) by server-15.tower-200.messagelabs.com with RC4-SHA encrypted SMTP; 16 Aug 2010 21:12:16 -0000
Received: from m679t05.fpmis.bridgewatersys.com ([10.52.81.148]) by m679t01.fpmis.bridgewatersys.com ([10.52.81.144]) with mapi; Mon, 16 Aug 2010 17:12:15 -0400
From: Avi Lior <avi@bridgewatersystems.com>
To: Glen Zorn <gwz@net-zen.net>
Date: Mon, 16 Aug 2010 17:12:13 -0400
Thread-Topic: [Dime] Review of draft-ietf-dime-realm-based-redirect-03
Thread-Index: Acs9h7L7fQ4frSo7SE275BlzcVuCew==
Message-ID: <023B0737-0E8B-4A68-80ED-EC79767DFB92@bridgewatersystems.com>
References: <3052C5CA-B52F-4DB2-B04A-D32110134CAC@gmail.com> <02AE8F14-B61F-4EAF-8654-7B86F154A9C8@huawei.com> <1FD363A7-3530-4F5F-8F17-0B0A861C33D4@bridgewatersystems.com> <000001cb3d23$4be946c0$e3bbd440$@net>
In-Reply-To: <000001cb3d23$4be946c0$e3bbd440$@net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-exclaimer-md-config: f069778a-5a3c-4a57-aa01-0f5f3f2623e3
Content-Type: multipart/alternative; boundary="_000_023B07370E8B4A6880EDEC79767DFB92bridgewatersystemscom_"
MIME-Version: 1.0
Cc: "draft-ietf-dime-realm-based-redirect@tools.ietf.org" <draft-ietf-dime-realm-based-redirect@tools.ietf.org>, "dime@ietf.org" <dime@ietf.org>, "dime-chairs@tools.ietf.org" <dime-chairs@tools.ietf.org>
Subject: Re: [Dime] Review of draft-ietf-dime-realm-based-redirect-03
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: Mon, 16 Aug 2010 21:11:43 -0000

On 16-08-2010, at 05:13 , Glen Zorn wrote:

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.

If the change in behavior is backward-compatible, why not?


Its not just sufficient to know that an added feature is backwards compatible.

The "approach" taken in Diameter design is that the one entity knows the behavior/capability of a particular another entity.  If you simply add functionality to something how would I know that the new features that i want to use are supported.

Specifically, how do I know that when I forward a message to a Redirect Agent that I would be able to get realm-redirections.  If I have two relay agents how would I know which one to use.

We have to decide that we are okay with building functionality into entities without having the ability to know whether those entities support those features.  And if we are okay with that then that is great.

 The draft solves the problem one way -- it allows the Redirect Agent know whether an Application can handle the new redirect attributes.  How about the other way as well?

Avi Lior
avi@bridgewatersystems.com<mailto:avi@bridgewatersystems.com>
office: +1 613-591-9104x6417
    cell: +1 613-796-4183