Subject: [Dime] [dime] #50: OC-OLR AVP implicit info

From: "dime issue tracker" <[email-masked]>
Date: Wed, 12 Feb 2014 07:43:15 -0000

#50: OC-OLR AVP implicit info

 Now (chapter 4.3):

    The OC-OLR AVP does not contain explicit information to which
    application it applies to and who inserted the AVP or whom the
    specific OC-OLR AVP concerns to. Both these information is
    implicitly learned from the encapsulating Diameter message/command.
    The application the OC-OLR AVP applies to is the same as the
    Application-Id found in the Diameter message header.  The identity
    the OC-OLR AVP concerns is determined from the Origin-Host AVP found
    from the encapsulating Diameter command.

 My understanding is that “who inserted the AVP” cannot always be learned
 from the encapsulating Diameter message, since “origin-host” may not
 always contain the host that inserted the OLR.
 A part from that, “whom the specific OC-OLR AVP concerns to”, could be a
 bit misleading… “whom” may be host, realm, or any other future ReportType,
 or even any other “narrowed scope” within the OLR. Last sentence is
 affected by this ambiguity as well.

 New proposal (related to new text proposed chapter 4.6, see to Issue #34):

 The OC-OLR AVP does not contain explicitly all information needed by the
 reacting node in order to decide whether a subsequent request must undergo
 a throttling process with the received reduction percentage.
 The following information is implicitly known from the received
 application answer and OC-OLR AVP, that is used by reacting node to
 identify subsequent requests that are requested to be throttled:

 a)The Application-ID is the value of the Application-ID of the Diameter
   Header of the received message that contained the OC-OLR AVP.

 b)The Destination-Realm AVP (if required, see 4.6) is the value of the
 Origin-Host AVP of the received message that contained the OC-OLR AVP.

 c)The Destination-Host AVP (if required, see 4.6) is the value of the
 Origin-Host AVP of the received message that contained the OC-OLR AVP.

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

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

---

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

Hi,

> a throttling process with the received reduction percentage.

The rest, however, should be replaced with e.g.:

The value of the OC-Report-Type AVP within the OC-OLR AVP indicates which implicit 
information is relevant for this decision (see clause 4.6).

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext dime issue tracker
Sent: Wednesday, February 12, 2014 8:43 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [Dime] [dime] #50: OC-OLR AVP implicit info

 Now (chapter 4.3):

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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 12 Feb 2014 11:31:29 +0200

I am OK with both proposals with a slight preference to Ulrich's
text, since it avoid unnecessary duplication of text from Section
4.6 (which is to be formulated..)

- JOuni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Feb 2014 07:43:47 -0600

> Origin-Host AVP of the received message that contained the OC-OLR AVP.

b) and c) are the same. Was one intended to be Realm?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 12 Feb 2014 07:44:50 -0600

> information is relevant for this decision (see clause 4.6).

I'm not sure I understand. Did you mean to delete the text about where you specifically find the "implicit" parameters? If so, why?

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Wed, 12 Feb 2014 13:49:35 +0000

Ben,

See below
/MCruz

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: miércoles, 12 de febrero de 2014 14:44
To: [email-masked] list
Cc: [email-masked]; Maria Cruz Bartolome
Subject: Re: [dime] #50: OC-OLR AVP implicit info

On Feb 12, 2014, at 1:43 AM, dime issue tracker <[email-masked]> wrote:

> My understanding is that "who inserted the AVP" cannot always be 
> learned from the encapsulating Diameter message, since "origin-host" 
> may not always contain the host that inserted the OLR.
> A part from that, "whom the specific OC-OLR AVP concerns to", could be 
> a bit misleading. "whom" may be host, realm, or any other future 
> ReportType, or even any other "narrowed scope" within the OLR. Last 
> sentence is affected by this ambiguity as well.
> 
> 
> The OC-OLR AVP does not contain explicitly all information needed by 
> the reacting node in order to decide whether a subsequent request must 
> undergo a throttling process with the received reduction percentage.
> _Origin-REALM_ AVP of the received message that contained the OC-OLR AVP.
> 

[MCruz] Yes, this was the intention, corrected in caps above. 

> 
> --
> -------------------------------------+--------------------------------
> -------------------------------------+-----
> -------------------------------------+--------------------------------
> -------------------------------------+-----
>

---

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

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Wednesday, February 12, 2014 2:45 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Dime] [dime] #50: OC-OLR AVP implicit info

I'm not sure I understand. Did you mean to delete the text about where you specifically find the "implicit" parameters? If so, why?
<Ulrich> yes, because this will be covered by clause 4.6 (see issue #34)</Ulrich>