Re: [Dime] OVLI: comments to 4.1

On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:

> There is a fundamental difference:
> OLRs need to be stored, Feature-Vectors not.

How come feature vector does not need to be stored? I do not
get that? I would set my implementation to a specific state
or mode based on the feature vector. When that changes I'd
like to know that. And then keep functioning based on that.

- Jouni

> When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.
> When receiving a Feature-Vector you just act on it.
> 
> Ulrich 
> 
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com] 
> Sent: Monday, December 09, 2013 1:55 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: dime@ietf.org
> Subject: Re: [Dime] OVLI: comments to 4.1
> 
> 
> In the same vein as folks wanted send OLRs with the new or old information,
> the feature vector should behave in a same way IMHO. That implies there are
> situations when a reception of the feature vector does not change anything
> in an endpoint current behavior.
> 
> - Jouni
> 
> On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> wrote:
> 
>> 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
>>> 
>> 
> 