Subject: Re: [Dime] draft-ietf-dime-ovli-08

From: <[email-masked]>
Date: Tue, 2 Jun 2015 10:59:15 +0000

Hi Ulrich, Steve,

Ok in the principle. But we will have to work on the wording as there is nothing about M-bit setting in this section and here we will have to make a statement on the setting of the M-bit for OC related AVPs in the response whereas there is nothing about the setting in the request and a general statement in sec. 7.8 saying:  "As described in the Diameter base protocol [RFC6733], the M-bit usage for a given AVP in a given command may be defined by the application."

Regards,

Lionel  

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (Nokia - DE/Munich)
Envoyé : mercredi 27 mai 2015 01:50
À : [email-masked]
Objet : [Dime] FW: draft-ietf-dime-ovli-08

Dear all,

please see below.
Is there any objection to allow reporting nodes (while in overload) to unconditionally include OC specific AVPs with M-bit cleared to answer messages even when the corresponding request did not indicate support of DOIC?

Best regards
Ulrich

-----Original Message-----
From: Wiehe, Ulrich (Nokia - DE/Munich)
Sent: Wednesday, May 27, 2015 1:45 AM
To: 'ext Steve Donovan'
Subject: RE: draft-ietf-dime-ovli-08

Thank you Steve,

I shall forward the question to the DIME list to see whether there are objections.

Regards
Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, May 26, 2015 8:00 PM
To: Wiehe, Ulrich (Nokia - DE/Munich)
Subject: Re: draft-ietf-dime-ovli-08

Ulrich,

If I remember correctly the MUST NOT was inserted based on your input.  
I think it was related to constraining the number of OC-S-F AVPs received by reacting nodes.

I don't have any objection to changing it if the rest of the DIME list agrees.

Steve

On 5/20/15 8:17 AM, Wiehe, Ulrich (Nokia - DE/Munich) wrote:
> Hi Steve,
>
>
> draft-ietf-dime-ovli-08.txt says in clause 5.1.2:
>
>     A reporting node MUST NOT include the OC-Supported-Features AVP, OC-
>     OLR AVP or any other overload control AVPs defined in extension
>     drafts in response messages for transactions where the request
>     message does not include the OC-Supported-Features AVP.
>
> This requirement seems to be too strict.
> Would it not be enough to demand not including OC-specific AVPs with M-bit set and allow including OC-specific AVPs with M-bit cleared?
>
> The reporting node, when in overload, may want to check only application ID and Command Code before deciding that a negative response is returned. In this case parsing the complete message to detect presence of the OC-Supported-Features AVP unnecessarily consumes resources and an unconditional inclusion of OC-OLR and OC-Supported-Features AVPs with M-bit cleared may be acceptable.
>
> What do you think?
>
> Regards
> Ulrich
>

_______________________________________________
DiME mailing list
[email-masked]
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.

---

From: Jens Schendel <[email-masked]>
Date: Tue, 2 Jun 2015 13:27:13 +0000

Hi all,

sorry for jumping in here. But I have been wondering why M-Bit usage is not specified in that I-D. "... may be defined by the application." is not a safe statement: it either MUST be defined or it may be re-defined. 
In general I would even think the default should be that M-Bit MUST NOT be set in the table. As I understood that  if the answering node did not implement DOIC (maybe because of pending node upgrade or because the application definition specified DOIC as optional feature), it should not be forced to reject any request message with OC-Supported-features.

Jens

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Dienstag, 2. Juni 2015 12:59
To: Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] draft-ietf-dime-ovli-08

Hi Ulrich, Steve,

Regards,

Lionel  

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (Nokia - DE/Munich) Envoyé : mercredi 27 mai 2015 01:50 À : [email-masked] Objet : [Dime] FW: draft-ietf-dime-ovli-08

Dear all,

please see below.

Best regards
Ulrich

-----Original Message-----
From: Wiehe, Ulrich (Nokia - DE/Munich)
Sent: Wednesday, May 27, 2015 1:45 AM
To: 'ext Steve Donovan'
Subject: RE: draft-ietf-dime-ovli-08

Thank you Steve,

Regards
Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, May 26, 2015 8:00 PM
To: Wiehe, Ulrich (Nokia - DE/Munich)
Subject: Re: draft-ietf-dime-ovli-08

Ulrich,

Steve

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 Korhonen <[email-masked]>
Date: Wed, 10 Jun 2015 08:34:49 -0700

OK in pricinple what Ulrich is now reverting ;)

Regarding M-bit setting, I think the current text is OK. For existing 
applications one does not have too much choices than clearing the M-bit. 
New applications can (and should) always define their M-bit settings for 
OC-* AVPs.

- Jouni

Sorry for jumping in late. If I recall correctly the discussion we had 
back then that

---

From: Jens Schendel <[email-masked]>
Date: Wed, 10 Jun 2015 18:19:01 +0000

Hi Jouni,

yes, it is obvious that existing application should let M-Bit unset. I just was thinking about a scenario where e.g. 3GPP specifies the DOIC for a particular interface in a specific release (e.g. Release 13). The operator has a lower interface release reference (e.g. 11) but wants to introduce DOIC. If the DOIC specification already stated M-Bit as unset - fine. Otherwise he should not forget to specify this (in particular when in R13 M-Bit would be set - which I would not hope :-)
So, of course you can say the implementer of the specification using DOIC is in charge of that. But my experience is that the "safer" a specification is the better it will prevent issues.

Jens

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]] 
Sent: Mittwoch, 10. Juni 2015 17:35
To: Jens Schendel; [email-masked]; Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] draft-ietf-dime-ovli-08

Regarding M-bit setting, I think the current text is OK. For existing applications one does not have too much choices than clearing the M-bit. 
New applications can (and should) always define their M-bit settings for
OC-* AVPs.

- Jouni

Sorry for jumping in late. If I recall correctly the discussion we had back then that

---

From: <[email-masked]>
Date: Wed, 10 Jun 2015 22:24:07 +0000

Hi,

For an existing 3GPP Application, any new AVP will be added with M-bit not set, whatever in which release the AVP is introduced. Otherwise it would be needed to create a new application as per RFC 6733.

Now, for a new defined application, it is up to the implementors to decide whether they want to set M-bit for DOIC AVP.In some scenarios, it may be desired that non-supporting nodes reject commands that contain the DOIC AVPs when not understood.

So I think that the current statement in the draft is correct.

Regards,

Lionel

Envoyé depuis mon mobile Orange

----- Reply message -----
De : "Jens Schendel" <[email-masked]>
Pour : "Jouni Korhonen" <[email-masked]>, "MORAND Lionel IMT/OLN" <[email-masked]>, "Wiehe, Ulrich (Nokia - DE/Munich)" <[email-masked]>, "[email-masked]" <[email-masked]>
Objet : [Dime] draft-ietf-dime-ovli-08
Date : mer., juin 10, 2015 20:19

Hi Jouni,

Jens

-----Original Message-----
From: Jouni Korhonen [mailto:[email-masked]]
Sent: Mittwoch, 10. Juni 2015 17:35
To: Jens Schendel; [email-masked]; Wiehe, Ulrich (Nokia - DE/Munich); [email-masked]
Subject: Re: [Dime] draft-ietf-dime-ovli-08

- Jouni