[Dime] OVLI: comments to 5.3.1

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Fri, 06 December 2013 16:07 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 D0C991AE388 for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 08:07:40 -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 IfBvbeL82ixj for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 08:07:38 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id B96F11AE384 for <dime@ietf.org>; Fri, 6 Dec 2013 08:07:37 -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 rB6G7ViL021652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Fri, 6 Dec 2013 17:07:31 +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 rB6G7VPc004181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Fri, 6 Dec 2013 17:07:31 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Fri, 6 Dec 2013 17:07:30 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Fri, 6 Dec 2013 17:07:30 +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.1
Thread-Index: Ac7ynUN6ecqCUZ/BTEKoQ6BxYT0Qzw==
Date: Fri, 6 Dec 2013 16:07:30 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DDBB@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.117]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519DDBBDEMUMBX014nsnin_"
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: 6278
X-purgate-ID: 151667::1386346052-000030AF-13E60919/0-0/0-0
Subject: [Dime] OVLI: comments to 5.3.1
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: Fri, 06 Dec 2013 16:07:41 -0000

Dear all,

here are comments to clause 5.3.1:

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

   The basic principle is that the first DOIC capable/willing Diameter
   node (including the client) on the path from client to server takes
   the role of  the "reacting node" and announces its support for the
   overload control mechanism by inserting in the request message the
   OC-Feature-Vector AVP with those capabilities it supports and is
   willing to use for this Diameter session (or transaction in a case
   of a non-session state maintaining applications, see Section 3.1.2
   for more details on Diameter sessions).

2. 2nd sentence: Why is it only RECOMMENDED to insert the Feature-Vector into every request?
The reacting endpoint may not even know which remote reporting endpoint the request will be sent to. The reporting endpoint would interpret an absent Feature-Vector in the received request as "there is no downstream reacting endpoint" and will not send back Feature-Vectors or OLRs. Proposal is to say:

   The reacting endpoint MUST insert the capability announcement into every
   request regardless it has had prior message exchanges with the
   (possibly not yet) given remote endpoint.

3. 3rd sentence: Proposal:

   Once the reacting endpoint that inserted the capability announcement into
   the request message receives an answer message from the remote endpoint, it
   can detect from the received answer message whether the remote endpoint
   supports the overload control solution and in a case it does, what features are
   supported.


Best regards
Ulrich