Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP

[Jouni Korhonen <[e-mail]>]

On Dec 4, 2013, at 12:50 AM, [e-mail] wrote:

> Hi Jouni,
> 
> The setting of the M-bit will be decided per application and not by this document.
> Obviously, when reused in existing applications, it will be purely optional. But designers may decide to include this AVP as mandatory AVP to understand in a new application and then the issues regarding Enumerated AVP will come back, no?

Changing the enumerated to unsigned64 does not change the situation.
You have the same issue still. The best thing we can do is to define
the procedures when receiving a value that is not understood.

We do have an error code for invalid values. So the application
designer have two choices. Define the report type with M=0 and just
ignore the AVP (+OLR) when the value is not understood or then
just return DIAMETER_INVALID_AVP_VALUE when M=1. This is independent
whether the AVP type is enumerated or something homegrown. 

- JOuni


> 
> Lionel
> 
> -----Message d'origine-----
> De : Jouni [mailto:[e-mail]] 
> Envoyé : mardi 3 décembre 2013 19:15
> À : MORAND Lionel IMT/OLN
> Cc : [e-mail]
> Objet : Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP
> 
> 
> On Dec 3, 2013, at 7:35 PM, <[e-mail]> <[e-mail]> wrote:
> 
>> Hi,
>> 
>> The proposed format for OC-Report-Type AVP is Enumerated.
>> This would lead to extensibility issue as discussed several times.
> 
> I know what you refer to but I think it is a non-issue since the
> AVP is optional and we can define the default behavior when the
> content is not understood.
> 
> - Jouni
> 
> 
> 
>> 
>> I would propose to define the OC-Report-Type AVP as Unsigned64 and create specific values. The same registry can be used to add values but we would get rid of the problem with Enumerated AVP.
>> 
>> Comment?
>> 
>> Lionel
>> 
>> _________________________________________________________________________________________________________________________
>> 
>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
>> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>> 
>> This message and its attachments may contain confidential or privileged information that may be protected by law;
>> they should not be distributed, used or copied without authorisation.
>> If you have received this email in error, please notify the sender and delete this message and its attachments.
>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
>> Thank you.
>> 
>> _______________________________________________
>> DiME mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dime
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>