Subject: [Dime] Private-Info AVP

From: "David Lehmann" <[email-masked]>
Date: Tue, 3 Aug 2010 14:37:28 -0400

Hello,

Currently, Diameter has an AVP called Proxy-Info AVP which can be put
into a request and it is guaranteed to be in the corresponding answer.
This is very useful to allow agents to remain stateless.  However, it
has its limitations. Namely, the Proxy-Info AVP can (1) only be added to
the request and (2) must be removed by the agent that added the AVP to
the message.

Consider the following diagram in which all messages are for the same
session.  Proxy-Info (PI) was added to R1 by the Agent.  The Agent must
remove the Proxy-Info from the answer before sending the answer to the
client. The same procedure is done for subsequent transactions.

Client                    Agent                    A/S
  |          R1             |         R1+PI         |
  |------------------------>|---------------------->|
  |                         |                       |
  |          A1             |         A1+PI         |
  |<------------------------|<----------------------|
  |                         |                       |
  |          R2             |         R2+PI         |
  |------------------------>|---------------------->|
  |                         |                       |
  |          A2             |         A2+PI         |
  |<------------------------|<----------------------|

I would like DIME to consider a more general AVP, "Private-Info" AVP.
The Private-Info AVP can be added to a request or answer.  Considering a
multi-transaction session, the Private-Info AVP can be added in any leg
of the session.  Each diameter node must forward/include the
Private-Info AVP in all subsequent messages for that session.   Only the
originator of the Private-Info AVP may remove the AVP from the message.

In the following diagram, PI is the "Private-Info" AVP.  The agent
inserts the Private-Info in the first request of the session and does
not remove the AVP when forwarding the answer.  In subsequent requests
from the client for the same session, the Private-Info AVP is added to
the message.

Client                    Agent                    A/S
  |          R1             |         R1+PI         |
  |------------------------>|---------------------->|
  |                         |                       |
  |          A1+PI          |         A1+PI         |
  |<------------------------|<----------------------|
  |                         |                       |
  |          R2+PI          |         R2+PI         |
  |------------------------>|---------------------->|
  |                         |                       |
  |          A2+PI          |         A2+PI         |
  |<------------------------|<----------------------|

If such an AVP already exists, please let me know.  If there is no such
AVP, can we discuss the possibility of adding such an AVP?

-David

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 3 Aug 2010 21:10:59 +0200

> client. The same procedure is done for subsequent transactions.

What for?

---

From: Sebastien Decugis <[email-masked]>
Date: Wed, 04 Aug 2010 10:45:19 +0900

Hello,

I think the Class AVP has a similar semantics, AFAIU...
See http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-20#section-8.20.

Hope this helps,

Best regards,
Sebastien.

Le 04/08/2010 03:37, David Lehmann a écrit :
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

-- 
Sebastien Decugis
Research fellow
Network Architecture Group
NICT (nict.go.jp)

---

From: "David Lehmann" <[email-masked]>
Date: Wed, 4 Aug 2010 08:47:50 -0400

> -----Original Message-----
> From: Glen Zorn [mailto:[email-masked]]
> Sent: Tuesday, August 03, 2010 3:11 PM
> To: David Lehmann
> Cc: [email-masked]
> Subject: RE: [Dime] Private-Info AVP
> 

... for similar reasons that the Proxy-Info AVP was provided.  One
example is to allow the Agent to be stateless.  Suppose there is a pool
of A/Ses. The agent wants to store an identifier of which A/S it sent
the first request (R1) so subsequent requests (R2) can be sent to the
same A/S.

-David