[Dime] OVLI: comments to 4.1

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 05 December 2013 13:23 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 2C0361ADDD2 for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 05:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WbDSDFf5rA4e for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 05:23:38 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 963461ADEBF for <dime@ietf.org>; Thu, 5 Dec 2013 05:23:38 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rB5DNXYU021044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Thu, 5 Dec 2013 14:23:34 +0100
Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB5DNXx7019543 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Thu, 5 Dec 2013 14:23:33 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 14:23:33 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasA==
Date: Thu, 05 Dec 2013 13:23:33 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 2270
X-purgate-ID: 151667::1386249814-00002466-4F64B0C5/0-0/0-0
Subject: [Dime] OVLI: comments to 4.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: Thu, 05 Dec 2013 13:23:41 -0000

Dear all,

here are comments to clause 4.1:

1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"

2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"

3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client), it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.
4. The text

   The reporting node that sends the answer also includes the OC-
   Feature-Vector AVP that describe the capabilities it supports.  The
   set of capabilities advertised by the reporting node depends on local
   policies.  At least one the announced capabilities MUST match
   mutually.  If there is no single matching capability the reacting
   node MUST act as if it does not implement DOIC and cease inserting
   any DOIC related AVPs into any Diameter messages with this specific
   reacting node.

is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability? 
Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.
Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent. 
Proposal is to keep only the first sentence and delete the rest.

Ulrich