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

From: <[email-masked]>
Date: Tue, 3 Dec 2013 17:35:50 +0000

Hi,

The proposed format for OC-Report-Type AVP is Enumerated.
This would lead to extensibility issue as discussed several times.

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.

---

From: Jouni <[email-masked]>
Date: Tue, 3 Dec 2013 20:14:57 +0200

> 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

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Dec 2013 16:30:37 -0600

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

I'm missing something--what's the problem with extending Enumerated AVPs in this context?

I recognize that we don't want new applications to change the set of values in Enumerated AVPs defined by another application. But that's not what we're talking about here. Why couldn't we, for example, create an Enumeration for DOIC that is intended to be extensible, and maybe even has an IANA registry?

(But for the record, I'm fine with Unsigned64).

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 22:50:32 +0000

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?

Lionel

-----Message d'origine-----
De : Jouni [mailto:[email-masked]] 
Envoyé : mardi 3 décembre 2013 19:15
À : MORAND Lionel IMT/OLN
Cc : [email-masked]
Objet : Re: [Dime] OVLI: Clarification on the format of the OC-Report-Type AVP

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 4 Dec 2013 12:14:32 +0200

> 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 reg…

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