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