Subject: Re: [Dime] Private-Info AVP

From: Daily William <[email-masked]>
Date: Wed, 4 Aug 2010 12:39:38 -0700

> What for?

... 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

[bd]
The example is interesting because this problem exists in the Diameter Credit Control Application.  Several vendors have chosen to address this situation by utilizing the Destination-Host AVP.

The scenario would be:

CCR-Initial -->
Destination-Realm = example.net

                <-- CCA-Initial
                Origin-Host = node.example.net
                Origin-Realm = example.net

CCR-Update (or Terminate) -->
Destination-Realm = example.net
Destination-Host = node.example.net

                <-- CCA-Update (or Terminate)
                Origin-Host = node.example.net
                Origin-Realm = example.net

The Diameter client is expected to capture the value of the Origin-Host AVP from the CCA-Initial sent by the server and use this value in the Destination-Host AVP for all subsequent Credit-Control-Requests.

The rules for the Destination-Host lend itself to this scenario (see http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-20#section-6.1) however this scenario is not explicitly described in Base-Diameter.  Nevertheless, IMHO I don't believe that there are any contradictions in this scenario and the rules in section 6.1.  Again, this practice has been adopted by several vendors.

It has occurred to me the Base Diameter bis version might benefit from a description of this scenario, however since the draft was in a late state it did not seem like an appropriate time to make this type of change.  But since the subject was brought up it does not hurt to put it out there for comment.

Thanks and regards,

Bill

“This e-mail message may contain confidential, commercial or privileged information that constitutes proprietary information of Comverse Technology or its subsidiaries. If you are not the intended recipient of this message, you are hereby notified that any review, use or distribution of this information is absolutely prohibited and we request that you delete all copies and contact us by e-mailing to: [email-masked]. Thank You.”

---

From: Victor Fajardo <[email-masked]>
Date: Wed, 4 Aug 2010 17:56:13 -0400

Hi,

On Wed, Aug 4, 2010 at 3:39 PM, Daily William <[email-masked]>wrote:

>
> The rules for the Destination-Host lend itself to this scenario (see
> http://tools.ietf.org/html/draft-ietf-dime-rfc3588bis-20#section-6.1)
> however this scenario is not explicitly described in Base-Diameter.
>  Nevertheless, IMHO I don't believe that there are any contradictions in
> this scenario and the rules in section 6.1.  Again, this practice has been
> adopted by several vendors.
>

I tend to agree but I think the decision for using these types of schemes
should be left to the context of the application and hence its not
explicitly described in bis (and probably should not be).

>
> It has occurred to me the Base Diameter bis version might benefit from a
> description of this scenario, however since the draft was in a late state it
> did not seem like an appropriate time to make this type of change.  But
> since the subject was brought up it does not hurt to put it out there for
> comment.
>

It maybe better to put items like this in design guidelines rather than bis.
It is really up to an application on how it wants to
maintain message cohession within a sessions.

regards,
victor

>
> Thanks and regards,
>
> Bill
>
>
> “This e-mail message may contain confidential, commercial or privileged
> information that constitutes proprietary information of Comverse Technology
> or its subsidiaries. If you are not the intended recipient of this message,
> you are hereby notified that any review, use or distribution of this
> information is absolutely prohibited and we request that you delete all
> copies and contact us by e-mailing to: [email-masked]. Thank You.”
>  _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 08:31:16 -0400

> It is really up to an application on how it wants to maintain message cohession within a sessions. 

The intent of the Private-AVP is not for applications. Rather, as shown in the example, it was intended to assist Diameter _agents_.  (Although, nothing should prevent an application from using this AVP.)  Agents are not aware of all the application rules.

-David

---

From: rajithr 70236 <[email-masked]>
Date: Thu, 05 Aug 2010 18:14:21 +0500

----- Original Message -----
From: David Lehmann <[email-masked]>
Date: Thursday, August 5, 2010 6:06 pm
Subject: Re: [Dime] Private-Info AVP
To: Victor Fajardo <[email-masked]>, Daily William <[email-masked]>
Cc: [email-masked]

> The intent of the Private-AVP is not for applications. Rather, as 
> shown in the example, it was intended to assist Diameter _agents_. 
> (Although, nothing should prevent an application from using this 
> AVP.)  Agents are not aware of all the application rules.

I think all session stateful agents would be application aware. Let the application handle these considerations.
For stateless agents, Proxy Info AVP would keep the transaction state.

Why would we need this new AVP then?

- Rajith

---

From: <[email-masked]>
Date: Thu, 5 Aug 2010 15:17:41 +0200

> The intent of the Private-AVP is not for applications. 
> Rather, as shown in the example, it was intended to assist 
> Diameter _agents_.  (Although, nothing should prevent an 
> application from using this AVP.)  Agents are not aware of 
> all the application rules.
> 

Difficult to see any specific need for such AVP for Relay or redirect agent. It means that this AVP would be used by proxy and/or server, in which diameter messages are managed at the application level. And therefore, it can be defined in the application requiring such functionality. Except if I missed something. 

Lionel

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 09:18:43 -0400

> I think all session stateful agents would be application aware. Let
the
> application handle these considerations.

The Proxy-Info has a limited lifespan.  The Private-Info is the same as
the Proxy-Info except that it lasts then entire session. (See the
original
example.)

-David

---

From: rajithr 70236 <[email-masked]>
Date: Thu, 05 Aug 2010 19:03:34 +0500

----- Original Message -----
From: David Lehmann <[email-masked]>
Date: Thursday, August 5, 2010 6:48 pm
Subject: RE: [Dime] Private-Info AVP
To: rajithr 70236 <[email-masked]>
Cc: Victor Fajardo <[email-masked]>, Daily William <[email-masked]>, [email-masked]

> > For stateless agents, Proxy Info AVP would keep the transaction 
> state.> 

Why should a (session) stateless agent need to have such a mechanism that lasts the entire session?
For session stateful agent, this may be needed and it would be considered in the application design.

-Rajith

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 5 Aug 2010 10:16:55 -0400

Hi David,

> the Proxy-Info except that it lasts then entire session. (See the

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.

-- victor

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 10:08:11 -0400

> Difficult to see any specific need for such AVP for Relay or redirect
agent.
> It means that this AVP would be used by proxy and/or server, in which
> diameter messages are managed at the application level. And therefore,
it
> can be defined in the application requiring such functionality. Except
if I
> missed something.

My original example provided a specific need for stateless agents.  
I sure there are other examples.

-David

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 11:14:56 -0400

> 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

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 11:22:17 -0400

> Why should a (session) stateless agent need to have such a mechanism
that
> lasts the entire session?

...in order for the agent to be stateless.  If the agent can store
information in the message, it does not need to store it in the agent
(which would be make it stateful).  Without the Private-Info AVP, an
otherwise stateless agent must be come stateful.

-David

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 5 Aug 2010 12:18:30 -0400

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

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 14:04:03 -0400

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.

--

David Lehmann

Ulticom, Inc.

856-787-2952

From: Victor Fajardo [mailto:[email-masked]] 
Sent: Thursday, August 05, 2010 12:19 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; [email-masked]
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

AVP that means

Client                    Agent                    A/S
 |          R1             |         R1+PI         |

Client                    Agent                    A/S
 |          R1             |         R1+PI         |

-David

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 5 Aug 2010 14:07:21 -0400

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <[email-masked]> wrote:

>  *The proposal is primarily  for agents*, not applications. (Although, I
> 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:[email-masked]]
> *Sent:* Thursday, August 05, 2010 12:19 PM
> *To:* David Lehmann
> *Cc:* rajithr 70236; Daily William; [email-masked]
>
> *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

---

From: "David Lehmann" <[email-masked]>
Date: Thu, 5 Aug 2010 14:17:19 -0400

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:[email-masked]] 
Sent: Thursday, August 05, 2010 2:07 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; [email-masked]
Subject: Re: [Dime] Private-Info AVP

On Thu, Aug 5, 2010 at 2:04 PM, David Lehmann <[email-masked]>
wrote:

 

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

	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

	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         |

	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         |

	So the Private-Info is different from the Proxy-Info, but only
in
	regards to lifetime.
	
	-David

---

From: Victor Fajardo <[email-masked]>
Date: Thu, 5 Aug 2010 14:28:57 -0400

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 <[email-masked]> wrote:

> opaque to the applications… just like the Proxy-Info.
>
>
>
> --
>
> *David Lehmann*
>
> Ulticom, Inc.
>
> 856-787-2952
>
>
>
> *Sent:* Thursday, August 05, 2010 2:07 PM
>
> *To:* David Lehmann

---

From: "David Lehmann" <[email-masked]>
Date: Fri, 6 Aug 2010 08:59:10 -0400

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:[email-masked]] 
Sent: Thursday, August 05, 2010 2:29 PM
To: David Lehmann
Cc: rajithr 70236; Daily William; [email-masked]
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 <[email-masked]>
wrote:

--

David Lehmann

Ulticom, Inc.

856-787-2952

To: David Lehmann

 

regards,

victor

	 

	--

	David Lehmann

	Ulticom, Inc.

	856-787-2952

	regards,

	victor

	AVP that means

	Client                    Agent                    A/S
	 |          R1             |         R1+PI         |

	Client                    Agent                    A/S
	 |          R1             |         R1+PI         |

	-David

---

From: "Glen Zorn" <[email-masked]>
Date: Fri, 6 Aug 2010 16:18:54 +0200

David Lehmann [mailto://[email-masked]]
<mailto:[mailto://[email-masked]%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

 

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

To: David Lehmann

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.

regards,

victor

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

regards,

victor

AVP that means

Client                    Agent                    A/S
 |          R1             |         R1+PI         |

Client                    Agent                    A/S
 |          R1             |         R1+PI         |

-David

---

From: <[email-masked]>
Date: Fri, 6 Aug 2010 16:42:32 +0200

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 : [email-masked] [mailto:[email-masked]] De la part de David Lehmann
	Envoyé : vendredi 6 août 2010 14:59
	À : Victor Fajardo
	Cc : Daily William; [email-masked]
	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

	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'.

	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

	To: David Lehmann

	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

		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

		AVP that means

		Client                    Agent                    A/S
		 |          R1             |         R1+PI         |

		Client                    Agent                    A/S
		 |          R1             |         R1+PI         |

		-David

---

From: "David Lehmann" <[email-masked]>
Date: Fri, 6 Aug 2010 12:06:47 -0400

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:[email-masked]] 
Sent: Friday, August 06, 2010 10:19 AM
To: David Lehmann; 'Victor Fajardo'
Cc: 'Daily William'; [email-masked]
Subject: RE: [Dime] Private-Info AVP

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

 

--

David Lehmann

Ulticom, Inc.

856-787-2952

To: David Lehmann

 

regards,

victor

	 

	--

	David Lehmann

	Ulticom, Inc.

	856-787-2952

	regards,

	victor

	AVP that means

	Client                    Agent                    A/S
	 |          R1             |         R1+PI         |

	Client                    Agent                    A/S
	 |          R1             |         R1+PI         |

	-David

---

From: Tom Taylor <[email-masked]>
Date: Fri, 06 Aug 2010 14:08:46 -0400

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?

> Private-Info AVP.   It is simply a tool to aid agents.
...

---

From: "David Lehmann" <[email-masked]>
Date: Fri, 6 Aug 2010 15:34:30 -0400

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:[email-masked]]
> Sent: Friday, August 06, 2010 2:09 PM
> To: David Lehmann
> Cc: Glen Zorn; Victor Fajardo; Daily William; [email-masked]
> Somewhere back in this correspondence the use of the Class AVP for
this
> purpose