Re: [Dime] Private-Info AVP

"David Lehmann" <dlehmann@ulticom.com> Fri, 06 August 2010 19:36 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 6EDF13A6A9D for <dime@core3.amsl.com>; Fri, 6 Aug 2010 12:36:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.406
X-Spam-Level:
X-Spam-Status: No, score=-2.406 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599]
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 EY54qLOHIaFY for <dime@core3.amsl.com>; Fri, 6 Aug 2010 12:35:42 -0700 (PDT)
Received: from bw.ulticom.com (bw.ulticom.com [208.255.120.43]) by core3.amsl.com (Postfix) with ESMTP id 159993A6A75 for <dime@ietf.org>; Fri, 6 Aug 2010 12:35:14 -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 FB11A15ECDD38661; Fri, 6 Aug 2010 15:34:56 -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 o76JYU8b024806; Fri, 6 Aug 2010 15:34:34 -0400 (EDT)
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: Fri, 06 Aug 2010 15:34:30 -0400
Message-ID: <A51D8ACD861B7E41BFC7FE5C64BE96481167B04E@MTLEXVS01.ulticom.com>
In-Reply-To: <BLU0-SMTP65CB4FEF991EE243761EBFD8910@phx.gbl>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Dime] Private-Info AVP
Thread-Index: Acs1kn2U6O/fj/qBR1yNXOv8O2NspgACf9vA
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> <A51D8ACD861B7E41BFC7FE5C64BE96481167B046@MTLEXVS01.ulticom.com> <BLU0-SMTP65CB4FEF991EE243761EBFD891! 0@phx.gbl >
From: David Lehmann <dlehmann@ulticom.com>
To: Tom Taylor <tom111.taylor@bell.net>
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 19:36:01 -0000

No.  The Class AVP has a specific use for apps.  Section 8.20 says that
the Class AVP "is to be used by Diameter Servers".  It is not intended
for agents.

In addition, it says that the Class AVP "MUST be present in subsequent
re-authorization, session termination and accounting messages."  The
Private-Info would have the requirement that it "MUST be present in
subsequent messages in the session".

Also, the Private-Info, being an extension of Proxy-Info would contain
Proxy-Host AVP to identify who owns the data.  If a Class AVP were
inserted by an agent, one of the endpoints may try to interpret it as
its own data.

--
David Lehmann
Ulticom, Inc.
856-787-2952


> -----Original Message-----
> From: Tom Taylor [mailto:tom111.taylor@bell.net]
> Sent: Friday, August 06, 2010 2:09 PM
> To: David Lehmann
> Cc: Glen Zorn; Victor Fajardo; Daily William; dime@ietf.org
> Subject: Re: [Dime] Private-Info AVP
> 
> Somewhere back in this correspondence the use of the Class AVP for
this
> purpose
> was noted. I know that we used it to preserve state in the IETF Rs
> application,
> running in stateless mode. Does it not serve your needs too?
> 
> David Lehmann wrote:
> > 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
> >
> ...