Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought

Hello,

not sure I understand the proposal.

Isn't it so that session states are maintained by client and server whereas capabilities are exchanged between reacting node and reporting node?
In the following example configuration

                                         +--------+
+----------------+                       | A1     |              +---------+
| client         |-----------------------|        |--------------| Server  |
| not supporting |                       +--------+              |         |   
| DOIC           |                       +--------+              |         |     
|                |-----------------------| A2     |--------------|         | 
+----------------+                       |        |              +---------+
                                         +--------+

A first request within a session may be sent from Client via A1 to the server; a second request within the same session may take the path via A2. A1 and A2 may support different capabilities.
The proposed requirement not to allow a capability change within a session would not be met by such example configurations.

I'm ok with Ben's proposal 

 >.....to mandate that the capabilities are stateless,
 >that is, must be included in every request, and any OLR in a response must
 >match the OC-Supported-Features from the corresponding request.

Ulrich

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, February 11, 2014 10:14 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought

Hello all,

I would like to come back to the initial comments by Ben on this subject:

>The capabilities announcement mechanism needs serious rethought.
 >Specifically, the lifetime of the state associated with a capabilities
 >announcement is unclear. It does not make sense to tie that lifetime to
 >Diameter session lifetimes, unless we expect to have different capability
 >sets for different sessions. (and it doesn't help at all for non-session
 >applications or pseudo-sessions.)

[MCruz] I agree we do not need to tie a capability set to a session, but on the other hand, what could be the reason to modify the capability set within a session?
I think this was the original reason why it is considered that the capability just needs to be announced once per session. In fact, I think this is a valid solution.

> I think we either need to mandate that the capabilities are stateless,
 >that is, must be included in every request, and any OLR in a response must
 >match the OC-Supported-Features from the corresponding request.
 >Otherwise, we need a way to activate and deactivate the set associated
 >with a capabilities set.

[MCruz] We could allow to define the capability set just once per session (obviously for session-based applications, for non-session based keeps being in each message).
We can define that within a session it is not allowed to modify the capability set.

-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Jouni Korhonen
Sent: martes, 11 de febrero de 2014 18:56
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org; ben@nostrum.com
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought

Fine with me. That just needs to be just stated more clearly.
Now there are too many SHOULDs and stuff.

- JOuni

On Feb 11, 2014, at 2:32 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

> I agree that OC-OLR AVPs are allowed only in answer messages.
> 
> But I do not agree with
>>> if there are other DOIC AVPs in the request, then the absence of the 
>>> OC-Supported-Features is interpreted as support for the default 
>>> abatement algorithm.
> 
> "other DOIC AVPs" would be AVPs defined for future extensions. A reporting node that does not support any future extension would simply ignore "other DOIC AVPs" and would interprete the absence of OC-Supported-Features as "DOIC not supported by any downstream node".
> 
> Things are not symmetric.
> Ulrich
> 
> 
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Jouni 
> Korhonen
> Sent: Tuesday, February 11, 2014 7:45 AM
> To: Steve Donovan
> Cc: ben@nostrum.com; dime@ietf.org; 
> draft-docdt-dime-ovli@tools.ietf.org
> Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism 
> needs to be rethought
> 
> 
> Your assumption is correct. "Other DOIC AVPs" is a future thing.
> Currently we have no other DOIC AVPs for requests. It is just I asking 
> the same semantics for the OC-Supported-Features for both directions.
> 
> - Jouni
> 
> 
> On Feb 11, 2014, at 1:27 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:
> 
>> It has been my assumption that the OC-OLR AVP would only be allowed in answer messages.  Is this the consensus?
>> 
>> Steve
>> 
>> On 2/10/14 4:27 PM, Jouni Korhonen wrote:
>>> Basically yes.. however, if there are other DOIC AVPs in the 
>>> request, then the absence of the OC-Supported-Features is 
>>> interpreted as support for the default abatement algorithm.
>>> We should have that behaviour in both requests and answers.
>>> 
>>> - Jouni
>>> 
>>> On Feb 10, 2014, at 7:03 PM, Steve Donovan 
>>> <srdonovan@usdonovans.com>
>>> wrote:
>>> 
>>> 
>>>> My sense from recent discussions is that the lifetime of the OC-Supported-Feature AVP is assumed to be one transaction.  This means that the AVP must be included in all request messages sent by a reacting node.
>>>> 
>>>> Steve
>>>> 
>>>> On 2/7/14 4:19 PM, dime issue tracker wrote:
>>>> 
>>>>> #49: capabilities announcement mechanism needs to be rethought
>>>>> 
>>>>> The capabilities announcement mechanism needs serious rethought.
>>>>> Specifically, the lifetime of the state associated with a 
>>>>> capabilities announcement is unclear. It does not make sense to 
>>>>> tie that lifetime to Diameter session lifetimes, unless we expect 
>>>>> to have different capability sets for different sessions. (and it 
>>>>> doesn't help at all for non-session applications or 
>>>>> pseudo-sessions.)
>>>>> 
>>>>> I think we either need to mandate that the capabilities are 
>>>>> stateless, that is, must be included in every request, and any OLR 
>>>>> in a response must match the OC-Supported-Features from the corresponding request.
>>>>> Otherwise, we need a way to activate and deactivate the set 
>>>>> associated with a capabilities set.
>>>>> 
>>>>> (This is a side effect of allowing DOIC to cross non-supporting 
>>>>> agents. If we didn't allow that, we could make DOIC support and 
>>>>> capabilites negotiation happen as part of the CAR exchange. )
>>>>> 
>>>>> 
>>>>> 
>>> 
>> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime