Re: [Dime] OVLI: clarification in 4.2

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 03 December 2013 15:03 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 494401AE172 for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 07:03:25 -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 jfxkXkLZ9Ltr for <dime@ietfa.amsl.com>; Tue, 3 Dec 2013 07:03:16 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 96EA01AE174 for <dime@ietf.org>; Tue, 3 Dec 2013 07:03:15 -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 rB3F3BAb016304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Dec 2013 16:03:11 +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 rB3F39aR032144 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 3 Dec 2013 16:03:09 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Tue, 3 Dec 2013 16:03:09 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext 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
Date: Tue, 03 Dec 2013 15:03:08 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519D427@DEMUMBX014.nsn-intra.net>
References: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920972C119@ESESSMB101.ericsson.se>
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_5BCBA1FC2B7F0B4C9D935572D90006681519D427DEMUMBX014nsnin_"
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: 16537
X-purgate-ID: 151667::1386082991-000022AE-865F88FB/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: Tue, 03 Dec 2013 15:03:25 -0000

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
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