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
> 