Subject: [Dime] OVLI: comments to 5.3.1

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Dec 2013 16:07:30 +0000

Dear all,

here are comments to clause 5.3.1:

1. 1st sentence: The request message initiating node is always the client and is not necessarily the reacting endpoint. Proposal is to modify the first sentence as follows:

   The basic principle is that the first DOIC capable/willing Diameter
   node (including the client) on the path from client to server takes
   the role of  the "reacting node" and announces its support for the
   overload control mechanism by inserting in the request message the
   OC-Feature-Vector AVP with those capabilities it supports and is
   willing to use for this Diameter session (or transaction in a case
   of a non-session state maintaining applications, see Section 3.1.2
   for more details on Diameter sessions).

2. 2nd sentence: Why is it only RECOMMENDED to insert the Feature-Vector into every request?
The reacting endpoint may not even know which remote reporting endpoint the request will be sent to. The reporting endpoint would interpret an absent Feature-Vector in the received request as "there is no downstream reacting endpoint" and will not send back Feature-Vectors or OLRs. Proposal is to say:

   The reacting endpoint MUST insert the capability announcement into every
   request regardless it has had prior message exchanges with the
   (possibly not yet) given remote endpoint.

3. 3rd sentence: Proposal:

   Once the reacting endpoint that inserted the capability announcement into
   the request message receives an answer message from the remote endpoint, it
   can detect from the received answer message whether the remote endpoint
   supports the overload control solution and in a case it does, what features are
   supported.

Best regards
Ulrich