Re: [Dime] OVLI: comments to 4.1
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Mon, 09 December 2013 12:47 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 BA39A1AE28D for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 04:47:17 -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 5Es18llySnA4 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 04:47:15 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E274C1ADF70 for <dime@ietf.org>; Mon, 9 Dec 2013 04:47:14 -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 rB9Cl8qD025492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Dec 2013 13:47:08 +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 rB9Cl8Rj023453 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 9 Dec 2013 13:47:08 +0100
Received: from DEMUHTC013.nsn-intra.net (10.159.42.44) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 9 Dec 2013 13:47:08 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC013.nsn-intra.net ([10.159.42.44]) with mapi id 14.03.0123.003; Mon, 9 Dec 2013 13:47:08 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Jouni Korhonen <jouni.nospam@gmail.com>
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg
Date: Mon, 09 Dec 2013 12:47:07 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com>
In-Reply-To: <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com>
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: 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: 4804
X-purgate-ID: 151667::1386593229-000030AF-58251DCA/0-0/0-0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [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: Mon, 09 Dec 2013 12:47:17 -0000
Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon? Ulrich -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] Sent: Monday, December 09, 2013 1:12 PM To: Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: Re: [Dime] OVLI: comments to 4.1 Ulrich, On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote: > Hi Jouni, > > thank you for your response. > > With regard to 3) > I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify. Since we also allow extending the OC-Feature-Vector beyond recognition, it has good chances become a rather complex grouped AVP. In that context the Sequence-Number allows an easy and quick way to check if the feature vector contains something that an implementation needs to act upon. > With regard to 4) > This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the"). Ack. Fixed the missing 'of'. - Jouni > > Best regards > Ulrich > > > -----Original Message----- > From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] > Sent: Friday, December 06, 2013 11:17 AM > To: Wiehe, Ulrich (NSN - DE/Munich) > Cc: dime@ietf.org > Subject: Re: [Dime] OVLI: comments to 4.1 > > > On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote: > >> 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" > > OK with me. > >> 2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP" > > OK with me. > >> 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), > > My original proposal was to have seqnr as a timestamp. Some folks argued > it is no good and suggested seqnr. I still think time makes more sense than > seqnr. > >> 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. > > Do not agree removing it. > >> 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? > > Because then they have found a way to exchange something that both ends > know how to handle it. > >> Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back > > There is an obvious typo. It should say: > > policies. At least one the announced capabilities MUST match > mutually. If there is no single matching capability the reporting > 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. > > - JOuni > > >> 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 >> >> >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >
- [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Ben Campbell
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- [Dime] Conclusion for OC-Feature-Vector - was Re:… Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Steve Donovan
- Re: [Dime] OVLI: comments to 4.1 Ben Campbell
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Steve Donovan
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Steve Donovan
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Steve Donovan
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Jouni Korhonen
- Re: [Dime] OVLI: comments to 4.1 Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] OVLI: comments to 4.1 Ben Campbell
- Re: [Dime] OVLI: comments to 4.1 Ben Campbell
- Re: [Dime] OVLI: comments to 4.1 Ben Campbell