Re: [Dime] Private-Info AVP

<lionel.morand@orange-ftgroup.com> Fri, 06 August 2010 14:42 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 4270A3A6A94 for <dime@core3.amsl.com>; Fri, 6 Aug 2010 07:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.898
X-Spam-Level:
X-Spam-Status: No, score=-102.898 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 pWNKIBLKUaFI for <dime@core3.amsl.com>; Fri, 6 Aug 2010 07:42:09 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 020913A6AC1 for <dime@ietf.org>; Fri, 6 Aug 2010 07:42:09 -0700 (PDT)
Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 341D78B803F; Fri, 6 Aug 2010 16:43:09 +0200 (CEST)
Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 25C818B8031; Fri, 6 Aug 2010 16:43:09 +0200 (CEST)
Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Aug 2010 16:42:33 +0200
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_01CB3575.9A8FB581"
Date: Fri, 06 Aug 2010 16:42:32 +0200
Message-ID: <D109C8C97C15294495117745780657AE0CBB2D89@ftrdmel1>
In-Reply-To: <A51D8ACD861B7E41BFC7FE5C64BE96481167B03E@MTLEXVS01.ulticom.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Private-Info AVP
Thread-Index: Acs0zBKtj01JbAzPTTWbFAKGVj8KXAAmkG3gAAOtH/A=
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>
From: lionel.morand@orange-ftgroup.com
To: dlehmann@ulticom.com, vf0213@gmail.com
X-OriginalArrivalTime: 06 Aug 2010 14:42:33.0777 (UTC) FILETIME=[9AFAE210:01CB3575]
Cc: 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 14:42:11 -0000

Hi David,
 
As said, I don't see what should be the usefulness of this functionality for Relay and Redirect agents. Proxies are used at the application level and can then rely on application-specific AVPs.
 
So what is the specific type of forwarding agents that would need such generic AVP?
 
Regards,
 
Lionel


________________________________

	De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de David Lehmann
	Envoyé : vendredi 6 août 2010 14:59
	À : Victor Fajardo
	Cc : Daily William; dime@ietf.org
	Objet : Re: [Dime] Private-Info AVP
	
	

	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.

	 

	--

	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