Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

Agreed, there is nothing contentious here.  I agree that the report
applies only to the application ID included in the message carrying the
overload report. 

Ulrich's wording isn't clear on which messages are being referenced.  Or
I wasn't looking at full context.  It might be better to try to change
the proposed wording from:
How about changing Ulrich's proposal from:

      c) The value of the Application-ID in the Diameter Header of the
         request matches the value of the Application-ID of the Diameter
         Header of the received message that contained the OC-OLR AVP.

to the following:

"The value of the application-ID in the Diameter Header of new request
messages matches the value of the Application-ID is an active overload
report."

Steve

On 2/11/14 4:50 AM, lionel.morand@orange.com wrote:
> I think that there is no contentious issue here :)
> I think that Ulrich is right saying that the reacting node needs to take into account the application-id to perform the abatement. Not when receiving the OLR... but when sending a new request.
>
> Lionel
>
> -----Message d'origine-----
> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
> Envoyé : mardi 11 février 2014 11:43
> À : dime@ietf.org
> Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Exact, I agree.
> Cheers
> /MCruz
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
> Sent: martes, 11 de febrero de 2014 10:37
> To: ext Steve Donovan; dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
> Steve,
>
> I do not agree.
>
> e.g. 
> 1. reacting node sends Request with application ID = x to reporting node 2. reporting node sends back answer (containing an OLR) with application ID = x 3. reacting node now may very well send  a new request with application ID = y to the reporting node without breaking any Diameter rules. 
> The new request sent in step 3 is NOT subject to throttling according to the OLR received in step 2.
> I hope this is not contentious.
> In order to provide a complete list of conditions to say when an OLR of a given type applies to a new request, we should not let c) go by the board.
>
> Ulrich
>
>
>  
>
>
> -----Original Message-----
> From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
> Sent: Monday, February 10, 2014 3:44 PM
> To: dime@ietf.org
> Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>
>>>       c) The value of the Application-ID in the Diameter Header of the
>>>          request matches the value of the Application-ID of the Diameter
>>>          Header of the received message that contained the OC-OLR AVP.
>> No need for this since we agreed that DOIC implicitly always refers to 
>> the application on which the DOIC AVPs are carried in.
>> <Ulrich>yes, we agreed on that, so c) is correct and it does not harm 
>> to keep c)</Ulrich>
> SRD> I don't see the reason for including this statement.  By
> definition, an overload report
> applies to the application ID in the answer message.  There is no way for the application-id in the answer message to be different than the application-id in the request message without breaking Diameter.
>
> _______________________________________________
> 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
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime
>