[Dime] OVLI: comments to 5.3.2

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Mon, 09 December 2013 09:33 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 9F4A71AE156 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 01:33:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.599
X-Spam-Level:
X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANGLED_LIST=2.3, 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 MuLmVscM-pkn for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 01:33:18 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5811AE092 for <dime@ietf.org>; Mon, 9 Dec 2013 01:33:17 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB99XAOA032411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Mon, 9 Dec 2013 10:33:10 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB99X9Ss017035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Mon, 9 Dec 2013 10:33:10 +0100
Received: from DEMUHTC011.nsn-intra.net (10.159.42.42) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 10:33:09 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC011.nsn-intra.net ([10.159.42.42]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 10:33:09 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: OVLI: comments to 5.3.2
Thread-Index: Ac70wauBU5OlawLjTzGjBpbbgzQqTw==
Date: Mon, 9 Dec 2013 09:33:08 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DF07@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DF07DEMUMBX014nsnin_"
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: 4152
X-purgate-ID: 151667::1386581591-00002466-873B24B9/0-0/0-0
Subject: [Dime] OVLI: comments to 5.3.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: Mon, 09 Dec 2013 09:33:21 -0000

Dear all,

here are comments to clause 5.3.2:

1. 1st sentence: The request message initiating node is always the client but is not necessarily the reacting endpoint. Proposal is to modify the first sentence as follows:

   When a remote endpoint (i.e. a "reporting node") receives a request
   message in can detect whether the client or any other downstream
   Diameter node has support for the overload control solution based
   on the presence of the OC-Feature-Vector AVP.

2. 3rd sentence: OC-Feature-Vector AVP can be present in request and in answer messages. The actual text here should only refer to OC-Feature-Vector AVP as received in the request message. Furthermore the reporting node is not necessarily the node that initiated the answer. Proposal is to modify the sentence as follows:


   Based on the content of the received OC-Feature-Vector AVP the
   request message receiving endpoint knows what overload control
   functionality the other endpoint supports and then act accordingly
   for the subsequent answer message it returns.



Best regards
Ulrich