Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Tue, 3 Dec 2013 09:25:51 +0000

Maria-Cruz,

> we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application
Yes. The above is my concern. I tried giving APN as one example AVP which we may want to include in OC-OLR. Let me give another possible example.
As of now, the OC-OLR can indicate application + host/realm level "required-reduction-percentage".
However, for the given application (e.g. Gx) we may want to define a narrower scope with "session-type = {M2M, Others}" AVP. So basically, the Gx nodes can advertise different "required-reduction-percentage" for M2M sessions v/s other type of sessions for the same application Gx and for the same destination-host.

So in general, if any application needs to define a different (i.e. narrower) scope than application + host/realm, it can do so by adding a new AVP in OC-OLR.
And then we might have two instances of OC-OLR from the same host.

We could achieve the above by defining new Report-Type for each new AVP added by each application. But would this scale or is this a reasonable approach?
I am not sure and you have already identified one of my concerns below
> if we extend ReportType, does it need to be done by IETF, or could it be done per application by 3GPP?

In summary, in my view, we need to define the handling of multiple instances with the same Report-Type as part of the DOIC draft. Or we say that multiple instances with the same Report-Type is not allowed - this seems unnecessary restriction to me.
Otherwise, if later, we realize the need to do so then we may not be able to do so since the handling is not defined in the base solution.

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Nirav,

I think I understand your concern. It may occur that we need that a reacting node should apply two different OLR when sending a request towards one specific host.
Then, we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application, I think this is your interpretation, but... we can as well consider a new ReportType=applicX_ReportY, that may apply e.g. for any request send to this application, or just for this application+host, and then Host could be another AVP to be included in the OLR, or we could define expected behaviour when defining this new ReportType.

Would this cover your concerns? If not, could you try to provide an example that requires two OLR with ReportType=host?

A part from that, a question for all, if we extend ReportType, does it need to be done by IETF, or could it be done per application by 3GPP?

Thanks
/MCruz

From: DiME [mailto:[email-masked]] On Behalf Of Nirav Salot (nsalot)
Sent: jueves, 28 de noviembre de 2013 17:11
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Hi Lionel,

I am not sure if defining new ReportType for every new AVP 3GPP would add for a specific application would be a good solution.
I thought ReportType would indicate if the corresponding OC-OLR should be used while sending the traffic towards the host or towards the realm.
So from that point of view, all the OC-OLR generated by the server should have ReportType=host. i.e. when the reacting node sends the traffic towards that host, it should make use of the corresponding OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as well as 3GPP application specific AVPs.

In general, I was just thinking that it may be good idea to define some of the principles such as

-          More than one instances of OC-OLR with ReportType=host may be present in the answer message if the OC-OLR definition is extended by the application using the same. In that case, it is the responsibility of the application to define the valid combination of OC-OLR instances in a given message

-          If the reporting node includes more than one instance of OC-OLR, the reporting node shall always include all the active instances of OC-OLR in a response message.

-          When the reacting node receives one or more instances of OC-OLR with the given ReportType and with new timestamp value, it should overwrite all the existing OC-OLR of the same ReportType.

Regards,
Nirav.

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]
Sent: Thursday, November 28, 2013 7:39 PM
To: Nirav Salot (nsalot)
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Hi Nirav,

The Report Type should be able to differentiate such cases. In your example, I would define a specific Report type.
But difficult to appraise all the future use cases. But for me, the main use of the report type is to differentiate OC-OLR received in the same message.
And it is the reasons of my recommendation. Actually, the exact wording will be a "SHOULD" saying that it is recommended but you may have serious reasons to do otherwise.

Lionel

De : Nirav Salot (nsalot) [mailto:[email-masked]]
Envoyé : jeudi 28 novembre 2013 13:00
À : MORAND Lionel IMT/OLN
Cc : [email-masked]<mailto:[email-masked]>
Objet : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Lionel,

3gpp may define an optional avp which can be included by the reporting node if it wishes to do so. E.g. APN can be additionally included by the reporting node to indicate APN specific overload within the given application.
In that case, the reporting node may also want to indicate application level overload without including the APN (e.g. this overload report is applicable to all other APNs).

And hence there is a possibility of including multiple instances of the overload report.

I am not suggesting that 3gpp will define APN (or any other avp) within overload report. But later, if 3gpp need to define the same, then corresponding handling needs to be defined within IETF now.

Regards,
Nirav.
On Nov 28, 2013 3:56 PM, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>> wrote:
Hi Nirav,

Not sure to understand the proposal or question.
The OLR is significant per application (piggybacking principle). So if the 3GPP decides to add specific AVPs in the OLR (that will be possible), what would be the need to add the OLR without the specific 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?

Lionel

De : DiME [mailto:[email-masked]] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 28 novembre 2013 10:33
À : [email-masked]<mailto:[email-masked]>
Objet : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Hi,

As I understand IETF will define the base overload control solution as part of DOIC. Then 3GPP would adopt the defined solution for each of its application.
When that happens, 3GPP might want to add 3GPP specific AVP within OC-OLR AVP. Based on the current definition of the OC-OLR AVP this should be allowed since it contains "* [AVP]" in its definition.
e.g. for a given application 3GPP decides to add information into OC-OLR which changes the scope of the OC-OLR from application level to the provided information level.
Additionally, the reporting may want to advertise the OC-OLR at the application level scope - i.e. the OC-OLR without any 3GPP specific info.

So if the above is allowed, we will have the possibility of the reporting node wanting to include two instances of OC-OLR with the Report-Type="host".
And then we need to define the handling of multiple instances of OC-OLR in the DOIC draft.

So the questions are,

-          Is 3GPP (or any other SDO) allowed to extend the definition of OC-OLR by adding information into it?

-          If no, can we guarantee that application level scope of OC-OLR (which is what we have defined currently) is sufficient (and not restricting) to all the applications of 3GPP?

Regards,
Nirav.

_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 3 Dec 2013 09:43:00 +0000

Nirav,

Yes, I agree the restriction to do not allow multiple instances with the same Report-Type does not seem necessary.

In fact, if we want to narrow OLR applicability, in case a new ReportType is defined, it means that it should apply to host OR/AND realm plus something else. This information should be either provided by the ReportType definition and/or by adding extra AVPs into corresponding OLR, what makes things more complex. I agree we could benefit from the flexibility to allow more than one instance of same ReportType.

Best regards
/MCruz

From: Nirav Salot (nsalot) [mailto:[email-masked]]
Sent: martes, 03 de diciembre de 2013 10:26
To: Maria Cruz Bartolome; [email-masked]
Subject: RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Maria-Cruz,

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Maria Cruz Bartolome
Sent: Tuesday, December 03, 2013 1:57 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Nirav,

Thanks
/MCruz

Hi Lionel,

Regards,
Nirav.

Hi Nirav,

Lionel

Lionel,

Regards,
Nirav.

Lionel

Hi,

So the questions are,

Regards,
Nirav.

Thank you.

Thank you.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 3 Dec 2013 09:48:10 +0000

Nirav,

I still do not see the need for more than one OLR in an answer.

More than one OLR means more complexity. Let's try to avoid that.

The server gets a request that either is or is not in the narrower scope. If it is not, why shoud the server return an OLR for the narrower scope? It can do so when it gets a request within the narrower scope (which possibly never happens).

Ulrich

From: DiME [mailto:[email-masked]] On Behalf Of ext Nirav Salot (nsalot)
Sent: Tuesday, December 03, 2013 10:26 AM
To: Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Maria-Cruz,

Regards,
Nirav.

Nirav,

Thanks
/MCruz

Hi Lionel,

Regards,
Nirav.

Hi Nirav,

Lionel

Lionel,

Regards,
Nirav.

Lionel

Hi,

So the questions are,

Regards,
Nirav.

Thank you.

Thank you.

---

From: <[email-masked]>
Date: Tue, 3 Dec 2013 10:40:28 +0000

Nirav,

If there are more than one OLR of the same type in the same answer, based on what I understood from the examples given below, the client will have to figure out which reduction to apply only based on extra AVPs received in the OLRs. I'm not so sure that it is something advisable from a standard point of view.

Regards,

Lionel

De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mardi 3 décembre 2013 10:48
À : ext Nirav Salot (nsalot); Maria Cruz Bartolome; [email-masked]
Objet : Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

Nirav,

Ulrich

Maria-Cruz,

Regards,
Nirav.

Nirav,

Thanks
/MCruz

Hi Lionel,

Regards,
Nirav.

Hi Nirav,

Lionel

Lionel,

Regards,
Nirav.

Lionel

Hi,

So the questions are,

Regards,
Nirav.

Thank you.

Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 3 Dec 2013 12:58:41 +0200

> If there are more than one OLR of the same type in the same answer, based on what I understood from the examples given below, the client will have to figure out which reduction to apply only based…

Agree.. the implementation then needs to go into weird heuristics based on the presence of different AVPs for the same OC-Report-Type. I have hard time seeing how that would be better than having explicitly specified report types where the handling of AVPs is known. Interop across vendors would at least be easier to achieve.

The text I wrote into -01 last week does not allow OLRs with the same report type.. 

- Jouni

> More than one OLR means more complexity. Let’s try to avoid that.
>  
> In summary, in my view, we need to define the handling of multiple instances with the same Report-Type as part of the DOIC draft. Or we say that multiple instances with the same Report-Type is not allowed – this seems unnecessary restriction to me.
> Then, we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application, I think this is your interpretation, but… we can as well consider a new ReportType=applicX_ReportY, that may apply e.g. for any request send to this application, or just for this application+host, and then Host could be another AVP to be included in the OLR, or we could define expected behaviour when defining this new ReportType.
>  
> To: [email-masked]
> Cc: [email-masked]
> From: [email-masked] [mailto:[email-masked]] 
> Cc: [email-masked]
> Cc : [email-masked]
> On Nov 28, 2013 3:56 PM, "[email-masked]" <[email-masked]> wrote:
> Hi Nirav,
>  
> À : [email-masked]
> Additionally, the reporting may want to advertise the OC-OLR at the application level scope – i.e. the OC-OLR without any 3GPP specific info.
>  
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Steve Donovan <[email-masked]>
Date: Tue, 03 Dec 2013 09:34:47 -0600

Nirav,

If we allow AVPs to be added without a new report type then where will
the behavior associated with the presence of that AVP be documented?

Requiring the definition of a new registered report type insures that
implementers have a well defined place to go to find out how to deal
with the presence of that AVP.

Steve

On 12/3/13 3:25 AM, Nirav Salot (nsalot) wrote:
>
> Maria-Cruz,
>
>  
>
> >we may think that we need two different OLRs with ReportType=host, and
> one of them includes the extra info (AVPs) required for that application
>
> Yes. The above is my concern. I tried giving APN as one example AVP
> which we may want to include in OC-OLR. Let me give another possible
> example.
>
> However, for the given application (e.g. Gx) we may want to define a
> narrower scope with "session-type = {M2M, Others}" AVP. So basically,
> the Gx nodes can advertise different "required-reduction-percentage"
> for M2M sessions v/s other type of sessions for the same application
> Gx and for the same destination-host.
>
>  
>
> So in general, if any application needs to define a different (i.e.
> narrower) scope than application + host/realm, it can do so by adding
> a new AVP in OC-OLR.
>
> We could achieve the above by defining new Report-Type for each new
> AVP added by each application. But would this scale or is this a
> reasonable approach?
>
> In summary, in my view, we need to define the handling of multiple
> instances with the same Report-Type as part of the DOIC draft. Or we
> say that multiple instances with the same Report-Type is not allowed
> -- this seems unnecessary restriction to me.
>
> Otherwise, if later, we realize the need to do so then we may not be
> able to do so since the handling is not defined in the base solution.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Maria Cruz
> Bartolome
> *Sent:* Tuesday, December 03, 2013 1:57 PM
> *To:* [email-masked]
> *Subject:* Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the
> same type) within a response message
>
>  
>
> Nirav,
>
>  
>
> I think I understand your concern. It may occur that we need that a
> reacting node should apply two different OLR when sending a request
> towards one specific host.
>
> Then, we may think that we need two different OLRs with
> ReportType=host, and one of them includes the extra info (AVPs)
> required for that application, I think this is your interpretation,
> but... we can as well consider a new ReportType=applicX_ReportY, that
> may apply e.g. for any request send to this application, or just for
> this application+host, and then Host could be another AVP to be
> included in the OLR, or we could define expected behaviour when
> defining this new ReportType.
>
>  
>
> Would this cover your concerns? If not, could you try to provide an
> example that requires two OLR with ReportType=host?
>
>  
>
> A part from that, a question for all, if we extend ReportType, does it
> need to be done by IETF, or could it be done per application by 3GPP?
>
>  
>
> Thanks
>
> /MCruz
>
>  
>
> *From:*DiME [mailto:[email-masked]] *On Behalf Of *Nirav Salot
> (nsalot)
> *Sent:* jueves, 28 de noviembre de 2013 17:11
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the
> same type) within a response message
>
>  
>
> Hi Lionel,
>
>  
>
> I am not sure if defining new ReportType for every new AVP 3GPP would
> add for a specific application would be a good solution.
>
> I thought ReportType would indicate if the corresponding OC-OLR should
> be used while sending the traffic towards the host or towards the realm.
>
> So from that point of view, all the OC-OLR generated by the server
> should have ReportType=host. i.e. when the reacting node sends the
> traffic towards that host, it should make use of the corresponding
> OC-OLR. Now, this OC-OLR may contain the AVPs defined by DOIC draft as
> well as 3GPP application specific AVPs.
>
>  
>
> -          More than one instances of OC-OLR with ReportType=host may
> be present in the answer message if the OC-OLR definition is extended
> by the application using the same. In that case, it is the
> responsibility of the application to define the valid combination of
> OC-OLR instances in a given message
>
> -          If the reporting node includes more than one instance of
> OC-OLR, the reporting node shall always include all the active
> instances of OC-OLR in a response message.
>
> -          When the reacting node receives one or more instances of
> OC-OLR with the given ReportType and with new timestamp value, it
> should overwrite all the existing OC-OLR of the same ReportType.
>
>  
>
> Regards,
>
> Nirav.
>
>  
>
> *From:[email-masked] <mailto:[email-masked]>
> [mailto:[email-masked]]
> *Sent:* Thursday, November 28, 2013 7:39 PM
> *To:* Nirav Salot (nsalot)
> *Cc:* [email-masked] <mailto:[email-masked]>
> *Subject:* RE: DOIC: Multiple instance of OC-OLR AVP (of the same
> type) within a response message
>
>  
>
> Hi Nirav,
>
>  
>
> The Report Type should be able to differentiate such cases. In your
> example, I would define a specific Report type.
>
> But difficult to appraise all the future use cases. But for me, the
> main use of the report type is to differentiate OC-OLR received in the
> same message.
>
> And it is the reasons of my recommendation. Actually, the exact
> wording will be a "SHOULD" saying that it is recommended but you may
> have serious reasons to do otherwise.
>
>  
>
> Lionel
>
>  
>
> *De :*Nirav Salot (nsalot) [mailto:[email-masked]]
> *Envoyé :* jeudi 28 novembre 2013 13:00
> *À :* MORAND Lionel IMT/OLN
> *Cc :* [email-masked] <mailto:[email-masked]>
> *Objet :* RE: DOIC: Multiple instance of OC-OLR AVP (of the same type)
> within a response message
>
>  
>
> Lionel,
>
> 3gpp may define an optional avp which can be included by the reporting
> node if it wishes to do so. E.g. APN can be additionally included by
> the reporting node to indicate APN specific overload within the given
> application.
> In that case, the reporting node may also want to indicate application
> level overload without including the APN (e.g. this overload report is
> applicable to all other APNs).
>
> I am not suggesting that 3gpp will define APN (or any other avp)
> within overload report. But later, if 3gpp need to define the same,
> then corresponding handling needs to be defined within IETF now.
>
> Regards,
> Nirav.
>
> On Nov 28, 2013 3:56 PM, "[email-masked]
> <mailto:[email-masked]>" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Nirav,
>
>  
>
> The OLR is significant per application (piggybacking principle). So if
> the 3GPP decides to add specific AVPs in the OLR (that will be
> possible), what would be the need to add the OLR without the specific
> 3GPP AVPs as the OLR will be anyway handle by 3GPP aware entities?
>
>  
>
> Lionel
>
>  
>
> *De :*DiME [mailto:[email-masked]] *De la part de* Nirav Salot
> (nsalot)
> *Envoyé :* jeudi 28 novembre 2013 10:33
> *À :* [email-masked] <mailto:[email-masked]>
> *Objet :* [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same
> type) within a response message
>
>  
>
> Hi,
>
>  
>
> As I understand IETF will define the base overload control solution as
> part of DOIC. Then 3GPP would adopt the defined solution for each of
> its application.
>
> When that happens, 3GPP might want to add 3GPP specific AVP within
> OC-OLR AVP. Based on the current definition of the OC-OLR AVP this
> should be allowed since it contains "* [AVP]" in its definition.
>
> e.g. for a given application 3GPP decides to add information into
> OC-OLR which changes the scope of the OC-OLR from application level to
> the provided information level.
>
> Additionally, the reporting may want to advertise the OC-OLR at the
> application level scope -- i.e. the OC-OLR without any 3GPP specific info.
>
>  
>
> So if the above is allowed, we will have the possibility of the
> reporting node wanting to include two instances of OC-OLR with the
> Report-Type="host".
>
> -          If no, can we guarantee that application level scope of
> OC-OLR (which is what we have defined currently) is sufficient (and
> not restricting) to all the applications of 3GPP?
>
>  
>
> Regards,
>
> Nirav.
>
>  
>

---

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

> More than one OLR means more complexity. Let’s try to avoid that.

I agree it adds complexity for the reacting node. As I outlined in my original email on the mixed dh/dr example, I think _not_ allowing it adds more complexity for the reporting node, since it may need to send more reports than it has answers to put them in.

I think it's reasonable to transfer complexity from the reporting node to the reacting node, since the reporting node is often the overloaded entity.

---

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

On Dec 3, 2013, at 9:34 AM, Steve Donovan <[email-masked]> wrote:

> Nirav,
> 
> If we allow AVPs to be added without a new report type then where will the behavior associated with the presence of that AVP be documented?
> 
> Requiring the definition of a new registered report type insures that implementers have a well defined place to go to find out how to deal with the presence of that AVP.
> 

The big issue is that we don't have conflicting reports in an answer.

It seems like requiring a new report type for a new "kind" of report is simpler than allowing any random new AVP to discriminate among types. It also gives better backwards compatibility, since a node that doesn't understand some new AVP will not know that it indicates a different scope.

So I concur with Steve.

---

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

> If there are more than one OLR of the same type in the same answer, based on what I understood from the examples given below, the client will have to figure out which reduction to apply only based…

Definitely not advisable.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 4 Dec 2013 10:52:46 +0000

Not allowing more than one OLR adds some complexity to the agent (not to the potentially overloaded server), as the agent should replace rather than add an OLR.

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 11:16 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Nirav Salot (nsalot); Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

> Then, we may think that we need two different OLRs with ReportType=host, and one of them includes the extra info (AVPs) required for that application, I think this is your interpretation, but. we can as well consider a new ReportType=applicX_ReportY, that may apply e.g. for any request send to this application, or just for this application+host, and then Host could be another AVP to be included in the OLR, or we could define expected behaviour when defining this new ReportType.
>

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Sat, 7 Dec 2013 08:35:20 +0000

Jouni, All,

As most of you have indicated, I am fine with the assumption that when an application specific parameter is added in the OC-OLR, new Report-Type is defined correspondingly.

However, the above does not guarantee that we will never have require multiple instances of OC-OLR with the same Report-Type.
e.g. if a new parameter APN and Report-Type=host_and_APN is defined by a 3GPP application.
Now, the APN can take multiple values. Or in other words, the reporting node may want to send different report for APN1 v/s APN2.
And hence it requires to provide two instances of OC-OLR, both with Report-Type="host_and_APN" and one instance containing APN=APN1 and another one with APN=APN2.

So in summary, I still believe that we should not have restriction that "multiple instances with same Report-Type is not allowed".
On the other hand, I believe we should define the principles of the handling of the same - in case any application extending the IETF defined OC-OLR defines new parameter.

Regards,
Nirav.

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, December 03, 2013 4:29 PM
To: [email-masked]
Cc: Wiehe, Ulrich (NSN - DE/Munich); Nirav Salot (nsalot); Maria Cruz Bartolome; [email-masked]
Subject: Re: [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) within a response message

- Jouni

>  
> Regards,
>  
> Lionel
>  
> De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich 
> (NSN - DE/Munich) Envoyé : mardi 3 décembre 2013 10:48 À : ext Nirav 
> Salot (nsalot); Maria Cruz Bartolome; [email-masked] Objet : Re: [Dime] 
> DOIC: Multiple instance of OC-OLR AVP (of the same type) within a 
> response message
>  
> Nirav,
>  
> > we may think that we need two different OLRs with ReportType=host, 
> > and one of them includes the extra info (AVPs) required for that 
> > application
> De : Nirav Salot (nsalot) [mailto:[email-masked]] Envoyé : jeudi 28 
> novembre 2013 13:00 À : MORAND Lionel IMT/OLN Cc : [email-masked] Objet 
> : RE: DOIC: Multiple instance of OC-OLR AVP (of the same type) within 
> a response message
>  
> Lionel,
> 
> De : DiME [mailto:[email-masked]] De la part de Nirav Salot 
> (nsalot) Envoyé : jeudi 28 novembre 2013 10:33 À : [email-masked] Objet 
> : [Dime] DOIC: Multiple instance of OC-OLR AVP (of the same type) 
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
> ______________________________________________________________________
> ___________________________________________________
>  
> 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.
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 11:10:56 +0200

Nirav,

The APN example has a good point. However, in that case (assuming you have a
specific report type for it) you know exactly what additional AVP to look 
after. In a generic case, for example with report type "plain" host, the 
implementation has no idea what AVPs it should consider the differentiator
and how to treat them differently. 

Maybe these things should be clarified for the cases where new report types
are added.. if and when a new report type could make use of multiple instance
of OLRs with the same report type?

- Jouni