Re: [Dime] OVLI: clarification in 4.2

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 04 December 2013 10:19 UTC

Return-Path: <ulrich.wiehe@nsn.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 807EC1AE23B for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 02:19:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] 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 w7ZrhToDkatr for <dime@ietfa.amsl.com>; Wed, 4 Dec 2013 02:19:32 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF81AE242 for <dime@ietf.org>; Wed, 4 Dec 2013 02:19:24 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB4AJJ1P029189 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Dec 2013 11:19:20 +0100
Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB4AJJNI023095 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 4 Dec 2013 11:19:19 +0100
Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 4 Dec 2013 11:19:19 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Wed, 4 Dec 2013 11:19:19 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "ext lionel.morand@orange.com" <lionel.morand@orange.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: AQHO8EzE9ycp5vvTJkqYnoN9DMqTSJpD08WA
Date: Wed, 04 Dec 2013 10:19:18 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D64C@DEMUMBX014.nsn-intra.net>
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>
In-Reply-To: <26806_1386091563_529E142A_26806_2128_1_6B7134B31289DC4FAF731D844122B36E313AC8@PEXCVZYM13.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.117]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519D64CDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 30794
X-purgate-ID: 151667::1386152360-000022AE-4DF8D484/0-0/0-0
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 10:19:51 -0000
X-List-Received-Date: Wed, 04 Dec 2013 10:19:51 -0000

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.