Re: [Dime] Private-Info AVP
"David Lehmann" <dlehmann@ulticom.com> Fri, 06 August 2010 16:06 UTC
Return-Path: <dlehmann@ulticom.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 009633A67F5 for <dime@core3.amsl.com>; Fri, 6 Aug 2010 09:06:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.387
X-Spam-Level:
X-Spam-Status: No, score=-2.387 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 cMi-lGEUDN6d for <dime@core3.amsl.com>; Fri, 6 Aug 2010 09:06:23 -0700 (PDT)
Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id CAB5D3A679F for <dime@ietf.org>; Fri, 6 Aug 2010 09:06:22 -0700 (PDT)
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by bw.ulticom.com (BorderWare Security Platform) with ESMTP id DA41B17D05E26522; Fri, 6 Aug 2010 12:06:52 -0400 (EDT)
Received: from MTLEXVS01.ulticom.com (mtlex01.ulticom.com [172.16.40.5]) by colby.ulticom.com (8.13.4/8.12.10) with ESMTP id o76G6mxS025842; Fri, 6 Aug 2010 12:06:48 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3581.5F82C54C"
Date: Fri, 06 Aug 2010 12:06:47 -0400
Message-ID: <A51D8ACD861B7E41BFC7FE5C64BE96481167B046@MTLEXVS01.ulticom.com>
In-Reply-To: <007d01cb3572$4e48d150$eada73f0$@net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Private-Info AVP
Thread-Index: Acs0zBKtj01JbAzPTTWbFAKGVj8KXAAmkG3gAAKTH2AAAx2/MA==
References: <mailman.123.1280948420.8403.dime@ietf.org><7C3581CDE8F4EE488C7C2A497B59DF161B8E46D995@EXUS.comverse.com><AANLkTin2gcK59pEBP_EzNsct=v5O16dhQMc9C=SOVPCN@mail.gmail.com><A51D8ACD861B7E41BFC7FE5C64BE96481167B026@MTLEXVS01.ulticom.com><fad8d306988.988fad8d306@huawei.com><A51D8ACD861B7E41BFC7FE5C64BE96481167B029@MTLEXVS01.ulticom.com><AANLkTimELdyghDfaxqBcyzV0ujnyVe5RHqBK9AiZtzBM@mail.gmail.com><A51D8ACD861B7E41BFC7FE5C64BE96481167B02C@MTLEXVS01.ulticom.com><AANLkTikR1kY8haazZB0fDao0FX=bFi-GB6scKr2Jkkxu@mail.gmail.com><A51D8ACD861B7E41BFC7FE5C64BE96481167B032@MTLEXVS01.ulticom.com><AANLkTik0dEDTkRLeP1ziQqSuXUbTVj+mCgOOAW25-GAh@mail.gmail.com><A51D8ACD861B7E41BFC7FE5C64BE96481167B034@MTLEXVS01.ulticom.com> <AANLkTimr0X-EFrRD6JLdgnye+OyRWdf5zb-N=RbSD9vB@mail.gmail.com> <A51D8ACD861B7E41BFC7FE5C64BE96481167B03E@MTLEXVS01.ulticom.com> <007d01cb3572$4e48d150$eada73f0$@net>
From: David Lehmann <dlehmann@ulticom.com>
To: Glen Zorn <gwz@net-zen.net>, Victor Fajardo <vf0213@gmail.com>
Received-SPF: none
Cc: Daily William <Bill.Daily@comverse.com>, dime@ietf.org
Subject: Re: [Dime] Private-Info AVP
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: Fri, 06 Aug 2010 16:06:32 -0000
I was using the general term "agent" because it doesn't matter which type it is, from the RFC's point of view. The Private-Info is just an extension of the Proxy-Info. For the same reason that the Proxy-Info exists, the Private-Info AVP has the same desired purpose: "It contains state information that would otherwise be stored at the Diameter entity that created it. As such, this AVP MUST be treated as opaque data by entities other Diameter entities." The RFC (section 6.1.9) states that the Proxy-Info can be use by a Proxy or Relay agent. So it really does matter which type of agent uses the AVP nor does it matter for which purpose. Who knows all of the clever ways an agent uses the Proxy-Info? The RFC does not provide the specific purposes of the Proxy-Info, and rightly so. Nor does the RFC need to spell out the purposes of the Private-Info AVP. It is simply a tool to aid agents. -- David Lehmann Ulticom, Inc. 856-787-2952 From: Glen Zorn [mailto:gwz@net-zen.net] Sent: Friday, August 06, 2010 10:19 AM To: David Lehmann; 'Victor Fajardo' Cc: 'Daily William'; dime@ietf.org Subject: RE: [Dime] Private-Info AVP David Lehmann [mailto://dlehmann@ulticom.com] <mailto:[mailto://dlehmann@ulticom.com%5d> writes: The agent is just forwarding messages and it would like to be application agnostic. The Private-Info AVP would aid in this effort, while allowing it to be stateless. As already noted by others, applications have defined messages which survive all subsequent legs of the session. The Private-Info is defining an AVP for similar purpose, but is intended for agents. It would help me, at least, if you said what type of agent you're talking about since there are 4... -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Thursday, August 05, 2010 2:29 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP your agent is a proxy which means its doing more than just forwarding messages. by definition, if your a proxy you have an application running in this agent that does special handling with these messages prior to forwarding ... hence we keep going back to the term 'application'. On Thu, Aug 5, 2010 at 2:17 PM, David Lehmann <dlehmann@ulticom.com> wrote: Forget the applications using this AVP. Think about agents. It is opaque to the applications... just like the Proxy-Info. -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Thursday, August 05, 2010 2:07 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <dlehmann@ulticom.com> wrote: The proposal is primarily for agents, not applications. (Although, I have no problem with applications employing the new AVP.) Agents can introduce the Private-Info into the messages to allow it to remain stateless without having knowledge of specific applications. Besides, you don't want an agent using an AVP which was intended be used for applications just because the AVP has the property of surviving on all legs of a session. An agent should introduce its own data in an AVP which is opaque to other nodes. It is cleaner, IMHO. But the content(s) and semantcis of the Private-Info is known only to the application :) ... so I'm not convinced if its really cleaner :) regards, victor -- David Lehmann Ulticom, Inc. 856-787-2952 From: Victor Fajardo [mailto:vf0213@gmail.com] Sent: Thursday, August 05, 2010 12:19 PM To: David Lehmann Cc: rajithr 70236; Daily William; dime@ietf.org Subject: Re: [Dime] Private-Info AVP Ok. Then rolling back to the same line of questioning ... why do you want to generalize this ? Other applications commonly define their own AVP's to accomodate round-trip information such as this. regards, victor On Thu, Aug 5, 2010 at 11:14 AM, David Lehmann <dlehmann@ulticom.com> wrote: > Unless I'm missing something, Proxy-Info can be included in an stateful application which > can control it's lifetime .... so I'm still not sure why we need a new AVP that means > the same thing. How does one control the lifetime of the Proxy-Info? The RFC currently states, "If the last Proxy-Info AVP in the message is targeted to the local Diameter server, the AVP MUST be removed before the answer is forwarded." Look at the original diagram. The Proxy-Info (PI) was added to R1 by the Agent, but the Agent "MUST" remove the Proxy Info before forwarding the answer to the client. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1 | A1+PI | |<------------------------|<----------------------| | | | | R2 | R2+PI | |------------------------>|---------------------->| | | | | A2 | A2+PI | |<------------------------|<----------------------| The proposed Private-Info AVP would be the same as the Proxy-Info, except that it lasts for the whole session (or until the owner removes it). Again the diagram with PI being the Private-Info. Client Agent A/S | R1 | R1+PI | |------------------------>|---------------------->| | | | | A1+PI | A1+PI | |<------------------------|<----------------------| | | | | R2+PI | R2+PI | |------------------------>|---------------------->| | | | | A2+PI | A2+PI | |<------------------------|<----------------------| So the Private-Info is different from the Proxy-Info, but only in regards to lifetime. -David
- [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Glen Zorn
- Re: [Dime] Private-Info AVP Sebastien Decugis
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Daily William
- Re: [Dime] Private-Info AVP Victor Fajardo
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP rajithr 70236
- Re: [Dime] Private-Info AVP lionel.morand
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP rajithr 70236
- Re: [Dime] Private-Info AVP Victor Fajardo
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Victor Fajardo
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Victor Fajardo
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Victor Fajardo
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Glen Zorn
- Re: [Dime] Private-Info AVP lionel.morand
- Re: [Dime] Private-Info AVP David Lehmann
- Re: [Dime] Private-Info AVP Tom Taylor
- Re: [Dime] Private-Info AVP David Lehmann