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

From: "dime issue tracker" <[email-masked]>
Date: Fri, 07 Feb 2014 22:19:59 -0000

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

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-docdt-dime-
  [email-masked]        |  [email-masked]
     Type:  defect       |     Status:  new
 Priority:  critical     |  Milestone:
Component:  draft-       |    Version:  1.0
  docdt-dime-ovli        |   Keywords:
 Severity:  Active WG    |
  Document               |
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/49>
dime <http://tools.ietf.org/wg/dime/>

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 11:03:15 -0600

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

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Feb 2014 00:27:19 +0200

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 10 Feb 2014 16:50:56 -0600

It would be easier to implement if there was a single AVP that indicated support (or lack of support by its absence), rather than having more than one, any of which indicate support.

On Feb 10, 2014, at 4:27 PM, Jouni Korhonen <[email-masked]> wrote:

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Mon, 10 Feb 2014 17:27:24 -0600

It has been my assumption that the OC-OLR AVP would only be allowed in
answer messages.  Is this the consensus?

Steve

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Feb 2014 08:45:23 +0200

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

> It has been my assumption that the OC-OLR AVP would only be allowed in answer messages.  Is this the consensus?
> 
> Steve
> 
>> On Feb 10, 2014, at 7:03 PM, Steve Donovan 
>> <[email-masked]>
>>  wrote:
>> 
>>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Feb 2014 08:50:39 +0200

Forgot to say that this is of course debatable. My preference
is/was to have the same behavior both directions but won't be
persistent on that.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 11 Feb 2014 12:32:39 +0000

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 

"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:[email-masked]] On Behalf Of ext Jouni Korhonen
Sent: Tuesday, February 11, 2014 7:45 AM
To: Steve Donovan
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 11 Feb 2014 19:56:26 +0200

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

- JOuni

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 11 Feb 2014 21:14:27 +0000

Hello all,

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

 >Otherwise, we need a way to activate and deactivate the set associated

[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:[email-masked]] On Behalf Of Jouni Korhonen
Sent: martes, 11 de febrero de 2014 18:56
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought

- JOuni

On Feb 11, 2014, at 2:32 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 12 Feb 2014 08:47:00 +0000

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,

Ulrich

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

Hello all,

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Jouni Korhonen
Sent: martes, 11 de febrero de 2014 18:56
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #49: capabilities announcement mechanism needs to be rethought

- JOuni