Re: [Dime] OVLI: comments to 4.1

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

For the OC-Feature-Vector AVP I still think that there is no need for anything like sequence number or timestamp (for OC-OLR things are different).

Including the sender identity of the node that sent the OC-Feature-Vector is not needed and would add complexity.

Ben wrote:

"...the point of having a sequence number here was so that if a reacting-node chooses to send the feature vector in every request, the reacting node can easily determine if the contents have changed, and ignore it if not..."

However, an unchanged Feature-Vector must not be ignored. It is still valid and the receiving node must honor it. Of course it could instead honor an identical stored Feature-Vector, but this again adds unnecessary complexity ("check if the received feature vector has changed, if not take the stored feature vector otherwise take the received feature vector" rather than "always take the received feature vector").

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[e-mail]] 
Sent: Friday, December 06, 2013 10:45 PM
To: Jouni Korhonen
Cc: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
Subject: Re: [Dime] OVLI: comments to 4.1


On Dec 6, 2013, at 4:17 AM, Jouni Korhonen <[e-mail]> wrote:

[...]

>> 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.
> 

Whether it's a timestamp, sequence number, or random number, we should describe the required uniqueness properties. (i.e. unique for that sender, unique across all senders, unique over a short period of time vs long period of time, etc.)

There may be other reasons to identify who sent the OC-Feature-Vector. Should we consider including the sender identity?

>> 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.

I concur with Jouni. IIRC, the point of having a sequence number here was so that if a reacting-node chooses to send the feature vector in every request, the reacting node can easily determine if the contents have changed, and ignore it if not. But it might be reasonable to consider whether that saves enough work to make it worth the trouble.

[...]