[Dime] OVLI: comments to 4.3

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 05 December 2013 15:24 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 34FB61AE06E for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 07:24:08 -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 gUz-thuFSg6n for <dime@ietfa.amsl.com>; Thu, 5 Dec 2013 07:24:05 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0C4DF1AE06D for <dime@ietf.org>; Thu, 5 Dec 2013 07:24:04 -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 rB5FO0VR029320 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Thu, 5 Dec 2013 16:24:00 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rB5FO0mE011302 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Thu, 5 Dec 2013 16:24:00 +0100
Received: from DEMUHTC007.nsn-intra.net (10.159.42.38) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 5 Dec 2013 16:24:00 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC007.nsn-intra.net ([10.159.42.38]) with mapi id 14.03.0123.003; Thu, 5 Dec 2013 16:24:00 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: OVLI: comments to 4.3
Thread-Index: Ac7xzgT7drC0NV4iSVSEGFHx9aP+WQ==
Date: Thu, 05 Dec 2013 15:23:59 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519DB1B@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_5BCBA1FC2B7F0B4C9D935572D90006681519DB1BDEMUMBX014nsnin_"
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: 3269
X-purgate-ID: 151667::1386257040-00002466-91915991/0-0/0-0
Subject: [Dime] OVLI: comments to 4.3
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 15:24:08 -0000

Dear all,

here are comments to clause 4.3:

1. Extensions in OC-OLR must either be mutually supported or must be ignorable. In the first case it is not enough for the reporting node to declare support of an extension in the sent OC-Feature-Vector AVP. For the second case there is no need to declare (or even define) support of an extension.
Proposal is to expand the second sentence as follows:

   OC-OLR may also be used to convey additional information about mutually supported extensions that are
   declared in the OC-Feature-Vector AVPs, and may also be used to convey additional ignorable information.

2. TimeStamp has been replaced with Sequence-Number. This has the negative impact that reacting nodes must calculate the expiration time base on OLR-reception time. OLR reception time and OLR creation time  may be significantly different.
I don't see any reason in favour of Sequence-Number. Proposal is to replace Sequence-Number with TimeStamp.

Best regards
Ulrich