Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics

From: Maria Cruz Bartolome <[email-masked]>
Date: Tue, 2 Sep 2014 08:11:59 +0000

Dear JJ, all,

See comments inline for some clarifications in the draft.
Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: viernes, 29 de agosto de 2014 17:50
To: Steve Donovan; [email-masked]
Subject: Re: [Dime] Issue #48 - M-bit gives wrong sementics

Hi Steve and  all

M-bit on which I am cautious as often at the origin  of interoperability issues, is mentioned in different  places  in the 03 draft (sections 4.3, 6 and 6.8) with rules according to the following:

- when DOIC is supporting in an existing application, Mbit SHOULD not be set in DOIC AVPS (cf 6.8)
- a new application can incorporate the DOIC mechanism as mandatory (cf 6), in this case the OC-Feature-Vector and OC-OLR AVPs reused in newly defined Diameter applications SHOULD have the M-bit flag set
[MCruz] Fine

Some (non fundamental) remarks hereafter:
a) We can have a new application where DOIC is not mandatory (when reading 6), but in 6.8 it is stated "when reused in newly defined Diameter applications, the DOC (note: to be DOIC)  related AVPs SHOULD have the M-bit set". If DOIC is optional for this new application, Mbit is not  set at least for the OC-Supported-features AVP in the requests, so to be ignored by a non DOIC supporting node receiving the request. May be to clarify.
[MCruz] Agree to clarify in the draft

b) We have text with general statements about DOIC AVPs and some text in 6 (not contradictory)  related to OC-Feature-Vector and OC-OLR . I think that, in 6, OC-Supported-Feature could be added, or even replace OC-Feature-Vector AVP which is a sub AVP of OC-Supported features and so already addressed in 4.3. 
[MCruz] Agree to use OC-Supported-Features

c) About "existing commands" in 6, sometimes an application which can be a new one can reuse an existing command defined in another application, the Mbit rule here is attached to the application, so, to avoid misinterpretation,  may be better to write "commands of an existing application" in 6.
[MCruz] Agree to be clarified.

d) About an intermediate  proxy DA for an application but not supporting DOIC for this application (as not needed), how  does it behave when transferring  requests with OC-Supported-Features or OLR AVPs with Mbit set, is it clear that the DA transfers the DOIC AVPs and not reject them for AVP unsupported?    
[MCruz] If the proxy DA supports application X, when DOIC AVPs are sent in application X responses, with M-bit set, isn't that the application will reject them?

e) in 4.3, it is written "NOT RECOMMENDED", I think better to write " M-bit in sub-AVPs SHOULD not be set" 
[MCruz] Agree

I hereafter remind the verison03  extracts mentioning M-bit In 4.3
   More specifically, the sub-AVPs inside the
   OC-Supported-Features and OC-OLR AVP MAY have the M-bit set.
   However, when overload control AVPs are piggybacked on top of an
   existing applications, setting M-bit in sub-AVPs is NOT RECOMMENDED

in 6 
   When added to existing commands,both OC-Feature-Vector and OC-OLR
   AVPs SHOULD have the M-bit flag cleared to avoid backward
   compatibility issues

   A new application specification can incorporate the overload control
   mechanism specified in this document by making it mandatory to
   implement for the application and referencing this specification
   normatively.  In such a case, the OC-Feature-Vector and OC-OLR AVPs
   reused in newly defined Diameter applications SHOULD have the M-bit
   flag set.  However, it is the responsibility of the Diameter
   application designers to define how overload control mechanisms works
   on that application.

In 6.8 
   As described in the Diameter base protocol [RFC6733], the M-bit
   setting for a given AVP is relevant to an application and each
   command within that application that includes the AVP.

   The Diameter overload control AVPs SHOULD always be sent with the
   M-bit cleared when used within existing Diameter applications to
   avoid backward compatibility issues.  Otherwise, when reused in newly
   defined Diameter applications, the DOC related AVPs SHOULD have the
   M-bit set.

Best regards

JJacques 

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Jouni Envoyé : jeudi 31 juillet 2014 20:49 À : <[email-masked]> Cc : [email-masked]; Ben Campbell Objet : Re: [Dime] Issue #48 - M-bit gives wrong sementics

OK++;

On Jul 31, 2014, at 8:41 PM, <[email-masked]> <[email-masked]> wrote:

> Ok for me.
> 
> Envoyé depuis mon Sony Xperia SP d'Orange
> 
> ---- Ben Campbell a écrit ----
> 
> 
> No objection
> 
> On Jul 31, 2014, at 11:52 AM, Steve Donovan <[email-masked]> wrote:
> 
>> All,
>> 
>> The proposal coming out of the meeting in Toronto was to close this issue with no changes to the existing text.
>> 
>> Let me know if there are objections to doing so, otherwise I'll close the issue.
>> 
>> Regards,
>> 
>> Steve
>> 
>> _______________________________________________
>> DiME mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> 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.
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

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

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