Subject: [Dime] Resolution of issue #73 clarifications on M-bit

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 21 Oct 2014 21:25:39 +0000

Dear all

In reference to the Lionel's minutes on  issue #73 Clarifications on the M-bit:

Summary: Mbit is mentioned in different places in the 03 draft (sections 4.3, 6 and 6.8). It is proposed clarifications to ensure a good consistency between the different sections.

Output of the discussion:

It is agreed that the draft should just refer to the RFC6733 for everything regarding the M-bit setting. How and when to set the M-bit is defined in the base protocol.

I will follow the output of the discussion, taking into account that I think we still need to indicate that for existing applications, the Mbit should be cleared for backward compatibility.

Hereafter the different places where M-bit is mentioned with the proposed changes

In 4.3.  Protocol Extensibility

Existing text:
   It should be noted that [RFC6733] defined Grouped AVP extension
   mechanisms apply.  This allows, for example, defining a new feature
   that is mandatory to be understood even when piggybacked on an
   existing applications.  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.

Proposal: To keep the reference to RFC 6733;  the text about  existing applications is removed as  overlapping with the 6.8 one.

   It should be noted that [RFC6733] defined Grouped AVP extension
   mechanisms apply.

In 6.  Attribute Value Pairs

Existing text
   This section describes the encoding and semantics of the Diameter
   Overload Indication Attribute Value Pairs (AVPs) defined in this
   document.

   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.

Proposal: to remove two paragraphs as overlapping with 6.8
   This section describes the encoding and semantics of the Diameter
   Overload Indication Attribute Value Pairs (AVPs) defined in this
   document.

In 6.8.  Attribute Value Pair flag rules

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

Proposal: To keep the reference to RFC 6733 and the particular case of existing applications

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

If OK, I will update the proposal for the issue #73 in the Dime Tracker

Best regards

JJacques

---

From: Steve Donovan <[email-masked]>
Date: Wed, 22 Oct 2014 08:34:39 +0200

Jean-Jacques,

I have made changes and closed issue #73.

Please look at the version of the draft I sent this morning and see if 
the changes I made for this issue are acceptable.  If not, please let me 
know and I'll update accordingly.

Regards,

Steve

On 10/21/14, 11:25 PM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:
> Summary: Mbit is mentioned in different places in the 03 draft 
> (sections 4.3, 6 and 6.8). It is proposed clarifications to ensure a 
> good consistency between the different sections.
>
> It is agreed that the draft should just refer to the RFC6733 for 
> everything regarding the M-bit setting. How and when to set the M-bit 
> is defined in the base protocol.
>
> I will follow the output of the discussion, taking into account that I 
> think we still need to indicate that for existing applications, the 
> Mbit should be cleared for backward compatibility.
>
> Proposal: To keep the reference to RFC 6733;  the text about  existing 
> applications is removed as overlapping with the 6.8 one.
>
> Proposal: to remove two paragraphs as overlapping with 6.8**
>
> Proposal:**To keep the reference to RFC 6733 and the particular case 
> of existing applications
>
> **
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Wed, 22 Oct 2014 08:03:21 +0000

Hi Steve

Comments  on your changes

For 4.3 Protocol Extensibility, I am OK

For 6.  Attribute Value Pairs, I considered the existing text of 2 paragraphs was overlapping with the one in 6.8.
When we duplicate text but with  wording differences, it may rise ambiguities with the questioning of why the text is different.

So I prefer to have one place to deal with M-bit and 6.8 seems for me the right place as dealing with AVP flag rules (so covering M-bit), and we do not need to say something in 6.

In 6.8, my proposal is to remove
   " Otherwise, when reused in newly
   defined Diameter applications, the DOC related AVPs SHOULD have the
   M-bit set."

This point was discussed and it depends on how the application deals with Diameter overaload. if it is optional the MBit is not set . So here  as according to the output discussion, only the reference to RFC 6733 is sufficient (1st paragraph). We nevertheless keep the statement for existing applications.

Best regards

JJacques

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mercredi 22 octobre 2014 08:35
À : [email-masked]
Objet : Re: [Dime] Resolution of issue #73 clarifications on M-bit

Jean-Jacques,

Please look at the version of the draft I sent this morning and see if the changes I made for this issue are acceptable.  If not, please let me know and I'll update accordingly.

Regards,

Steve

Existing text:

Existing text

Existing text

Best regards

JJacques

DiME mailing list

[email-masked]<mailto:[email-masked]>