Subject: [Dime] Proposed wording change in Section 6.1

From: Steve Donovan <[email-masked]>
Date: Tue, 25 Nov 2014 08:20:49 -0600

All,

The current wording for the OC-Supported-Features AVP says that it MUST 
be included in all messages a DOIC supporting node sends.

The OC-Supported-
    Features AVP MUST be included in every Diameter request message a
    DOIC supporting node sends.

We need to qualify this a little as there will be cases where a Diameter 
node supports DOIC but the application does not require use of DOIC.  
Requests originated by an HSS in the S6a application is an example of 
this as 3GPP CT4 is defining that application to only use DOIC on 
requests traveling from the MME to the HSS.

I propose the following wording to replace the above sentence:

The OC-Supported-Features AVP MUST be included by a DOIC node in every 
Diameter request message for applications that have defined support for 
the DOIC solution on messages sent by the DOIC node.

       Note: It is expected that there will be applications that define 
the use of DOIC only for requests flowing from Diameter Clients to 
Diameter Servers and not for requests flowing from Diameter Servers to 
Diameter Clients.  In this case a Diameter Server that supports the DOIC 
solution will not include the OC-Supported-Features header in request 
messages it sends.

I'll update the document accordingly unless I hear objections on the list.

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2014 10:24:53 -0600

I'm not sure I agree with the approach. Comments inline:

> On Nov 25, 2014, at 8:20 AM, Steve Donovan <[email-masked]> wrote:
> 
> All,
> 
> The current wording for the OC-Supported-Features AVP says that it MUST be included in all messages a DOIC supporting node sends. 
> 
> The OC-Supported-
> We need to qualify this a little as there will be cases where a Diameter node supports DOIC but the application does not require use of DOIC.  Requests originated by an HSS in the S6a application is an example of this as 3GPP CT4 is defining that application to only use DOIC on requests traveling from the MME to the HSS.
> 
> The OC-Supported-Features AVP MUST be included by a DOIC node in every Diameter request message for applications that have defined support for the DOIC solution on messages sent by the DOIC node.

I don't think we need to tie this to application definitions. A DOIC node can use DOIC with an application that doesn't "define" it. And a deployment might choose not to use DOIC for reasons other than what is in the definition.

Also, I don't think that statement needs to be normative. We don't need 2119 language to describe the basic flow of the protocol. 

Proposal (non-normative)

"A DOIC node indicates that it is willing to act as a reacting node for an application by including the OC-Supported-Features AVP in each request message it sends for that application."

OTOH, if people insist on making this normative:

"A DOIC node that is willing to act as a reacting node for an application MUST include the OC-Supported-Features AVP in each request it sends for that application"

Note: "for an application" might need to be "for a realm and application"

> 
>       Note: It is expected that there will be applications that define the use of DOIC only for requests flowing from Diameter Clients to Diameter Servers and not for requests flowing from Diameter Servers to Diameter Clients.  In this case a Diameter Server that supports the DOIC solution will not include the OC-Supported-Features header in request messages it sends.
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Dave Dolson <[email-masked]>
Date: Tue, 25 Nov 2014 16:42:05 +0000

Is the idea that a host consistently either send the AVP or not send the AVP, but be consistent for a given message type?

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Tuesday, November 25, 2014 11:25 AM
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposed wording change in Section 6.1

Proposal (non-normative)

---

From: <[email-masked]>
Date: Tue, 25 Nov 2014 18:10:32 +0000

Hi Steve, Ben,

IMHO, including the OC-Supported-Features AVP is not related to the type of request but to an application.
You can advertise the supported features in every application request, even if the OLR will be in fine received only in some specific answers (e.g. answer of the HSS in S6a)

So the proposed text could be:

OLD: 

   The OC-Supported-Features AVP MUST be included in every Diameter request message a DOIC supporting node sends.

NEW:

   The OC-Supported-Features AVP MUST be included in every Diameter request message a DOIC supporting node sends for an application supporting the overload control
   mechanism specified in this document.

regards,

Lionel

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Dave Dolson
Envoyé : mardi 25 novembre 2014 17:42
À : Ben Campbell; Steve Donovan
Cc : [email-masked]
Objet : Re: [Dime] Proposed wording change in Section 6.1

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
Sent: Tuesday, November 25, 2014 11:25 AM
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Proposed wording change in Section 6.1

Proposal (non-normative)

_________________________________________________________________________________________________________________________

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: Ben Campbell <[email-masked]>
Date: Tue, 25 Nov 2014 12:30:37 -0600

> On Nov 25, 2014, at 12:10 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Steve, Ben,
> 

The issue is, a node might be willing to be only a reporting node, or only a reacting node, even for the same application. That's why we need to separate requests from answers. I would be okay with your proposed language with a small change:

"The OC-Supported-Features AVP MUST be included in every Diameter request message a DOIC _reacting_ node sends for an application _for_which_it_supports the overload control
  mechanism specified in this document."

But I think to some degree we are making this hard on ourselves. It may be better to just say that a "reacting node" sends OC-Supported-Features in every request. Don't we already have text that indicates that a node may be a reacting node for some applications but not others?

---

From: <[email-masked]>
Date: Tue, 25 Nov 2014 23:17:30 +0000

I understand your point and I'm OK with:

"The OC-Supported-Features AVP MUST be included by reacting nodes in every Diameter request message."

Lionel

-----Message d'origine-----
De : Ben Campbell [mailto:[email-masked]] 
Envoyé : mardi 25 novembre 2014 19:31
À : MORAND Lionel IMT/OLN
Cc : Dave Dolson; Steve Donovan; [email-masked]
Objet : Re: [Dime] Proposed wording change in Section 6.1

> You can advertise the supported features in every application request, 
> even if the OLR will be in fine received only in some specific answers 
> (e.g. answer of the HSS in S6a)
> 

> Envoyé : mardi 25 novembre 2014 17:42 À : Ben Campbell; Steve Donovan 
> Cc : [email-masked] Objet : Re: [Dime] Proposed wording change in 
> Section 6.1
> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.