Re: [Dime] OVLI: clarification in 4.2

<lionel.morand@orange.com> Wed, 04 December 2013 11:21 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 128401AE0F3 for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 03:21:53 -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 Q849PH3hREKw for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 03:21:48 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 258B91AE101 for <dime@ietf.org>; Wed, 4 Dec 2013 03:21:45 -0800 (PST)
Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id D794818C407; Wed, 4 Dec 2013 12:21:41 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id BF0D035C05B; Wed, 4 Dec 2013 12:21:41 +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; Wed, 4 Dec 2013 12:21:41 +0100
From: lionel.morand@orange.com
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] OVLI: clarification in 4.2
Thread-Index: AQHO8EzE9ycp5vvTJkqYnoN9DMqTSJpD08WAgAAI+/A=
Date: Wed, 04 Dec 2013 11:21:40 +0000
Message-ID: <7773_1386156101_529F1045_7773_621_1_6B7134B31289DC4FAF731D844122B36E3270A8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se> <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B920972C3CE@ESESSMB101.ericsson.se> <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D90006681519D64C@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519D64C@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.1]
Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E3270A8PEXCVZYM13corpora_"
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.20.60015
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: Wed, 04 Dec 2013 11:21:53 -0000

In this section, we are only defining the Grouped AVP, not all the AVPs contained in the Grouped AVP.

Lionel

De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Envoyé : mercredi 4 décembre 2013 11:19
À : MORAND Lionel IMT/OLN; Maria Cruz Bartolome; dime@ietf.org
Objet : RE: [Dime] OVLI: clarification in 4.2

I prefer the more explicit description in the previous proposal.
Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext lionel.morand@orange.com
Sent: Tuesday, December 03, 2013 6:26 PM
To: Maria Cruz Bartolome; dime@ietf.org
Subject: Re: [Dime] OVLI: clarification in 4.2

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

_________________________________________________________________________________________________________________________

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.