Re: [Dime] OVLI: clarification in 4.2

<lionel.morand@orange.com> Tue, 03 December 2013 17:26 UTC

Return-Path: <lionel.morand@orange.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7381ABD2A for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 09:26:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PHOKOXSt4dl for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 09:26:07 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 912BA1AD6BF for <dime@ietf.org>; Tue, 3 Dec 2013 09:26:06 -0800 (PST)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 178E52DC1D0; Tue, 3 Dec 2013 18:26:03 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E7C6D27C059; Tue, 3 Dec 2013 18:26:02 +0100 (CET)
Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 3 Dec 2013 18:26:02 +0100
From: lionel.morand@orange.com
To: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] OVLI: clarification in 4.2
Thread-Index: Ac7wLSOy5PcGMIF3QXy86CAXysOX/AABwHCQ///6zID//9CjIA==
Date: Tue, 03 Dec 2013 17:26:02 +0000
Message-ID: <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.5]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E313AC8PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.12.3.151814
Subject: Re: [Dime] OVLI: clarification in 4.2
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 17:26:12 -0000

The clarification is welcome but I think that we don't have to state what is missing in the OLR (because a lot of things could be added to the list) but what we can do with the OLR as defined in this document.

We could have something as simple as:

As defined in this document, the overload report contained in the OC-OLR AVP
applies to the application identified by the application-id used in the Diameter header
of the Diameter message. The value of the Report-Type AVP indicates the scope of
applicability of this overload report for this application, as described in section 4.6.

No need for extra info here as we have more details in section 4.6 e.g. "The reacting node learns the "host" implicitly from the Origin-Host AVP of the received message that contained the OC-OLR AVP"

Regards,

Lionel

De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
Envoyé : mardi 3 décembre 2013 16:11
À : dime@ietf.org
Objet : Re: [Dime] OVLI: clarification in 4.2

Hello Ulrich,

You are right, it is 4.3 in version under development:
https://github.com/jounikor/draft-docdt-dime-ovli/blob/master/draft-ietf-dime-ovli-01.txt
Your proposal looks fine.
Best regards
MCruz

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: martes, 03 de diciembre de 2013 16:03
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] OVLI: clarification in 4.2

Hi MCruz,

isn't this clause 4.3?

I agree that clarification is needed.
But isn't it so that the OLR contains some explicit information (e.g. the Report-Type) that is not implicitly learned from the encapsulating Diameter message?

My proposal:
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 reported percentage. To take this decision the reacting node must check

a)      whether the subsequent request's Application-ID matches the Application-Id received in the OC-OLR AVP's encapsulating answer command;

b)      if the Report-Type received in the OC-ORL is "host"
b1)  whether the subsequent request's Destination Host is present and matches the Origin Host received in the OC-OLR AVP's encapsulating answer command;
if the Report-Type received in the OC-OLR is "realm"
b2) whether the subsequent request' Destination Host is absent and the Destination Realm matches the Origin Realm received in the OC-OLR AVP's  encapsulating answer command;

Best regards
Ulrich



From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 2:56 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: [Dime] OVLI: clarification in 4.2

Hello,

I would like to propose a clarification on 4.2
                ....
   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.

Some rephrasing may be considered:
   The OC-OLR AVP does not contain explicit information that may be

   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. When Report-Type is

   a Destination-Host, the identity

   the OC-OLR AVP concerns is determined from the Origin-Host AVP found

   from the encapsulating Diameter command.


Best regards
/MCruz


_________________________________________________________________________________________________________________________

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.