Re: [Dime] OVLI: comments to 4.1

Jouni Korhonen <jouni.nospam@gmail.com> Fri, 06 December 2013 10:17 UTC

Return-Path: <jouni.nospam@gmail.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 464091ADC03 for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 02:17:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 jVSl5E0YSKCK for <dime@ietfa.amsl.com>; Fri, 6 Dec 2013 02:17:08 -0800 (PST)
Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC4D1ADBCC for <dime@ietf.org>; Fri, 6 Dec 2013 02:17:08 -0800 (PST)
Received: by mail-lb0-f172.google.com with SMTP id z5so186294lbh.17 for <dime@ietf.org>; Fri, 06 Dec 2013 02:17:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=xravmpWv1NO5n8shudTpoXOUyMMGGLpf4xBhkM+ZJCY=; b=uyW3No7pES+/rYp/E06m1ZjYo1mM76Da3P+eWJm3woe5+1tsxL6vz4yZHZE3Rc6TKp rg8kMANeqIeAie9Vv1X5Jbny+uC+0HNfUln/vieLEJxzZfUE07afx2usY87xkm8cc+Y3 Uvw83xYOFo5VvUU9cqKfmNzXykKC/QzxDtANErmIl0/CFLq2eKbt0UXUXnCiItf5ZwrQ di7sarlWPWrriq6O1XSIPomc/Po06edq/w/JXHb4xemng4hk5wMCY7QJhuYLYTVxM7vu GBlt1s/qGGk1YQJ0sOr9sRTApEPYSxt1K+hUzC5/cjDATMXC8CzL9MjxkpW3vHFr3teY 0amA==
X-Received: by 10.152.219.133 with SMTP id po5mr674116lac.34.1386325023969; Fri, 06 Dec 2013 02:17:03 -0800 (PST)
Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id iy7sm58555423lbc.4.2013.12.06.02.16.58 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 06 Dec 2013 02:16:59 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net>
Date: Fri, 06 Dec 2013 12:17:00 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
X-Mailer: Apple Mail (2.1510)
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: Fri, 06 Dec 2013 10:17:10 -0000

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