Subject: [Dime] [dime] #73 (draft-ietf-dime-ovli): Clarifications On Mbit

From: "dime issue tracker" <[email-masked]>
Date: Wed, 10 Sep 2014 07:18:43 -0000

#73: Clarifications On Mbit

 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.

 1) In 4.3, existing text:

    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

 Proposed text with an affirmation instead of a negation and the use of
 SHOULD:
    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, the M-bit in sub-AVPs SHOULD be cleared.

 2) in section  6,  existing text:

    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.

 It is proposed  to replace  OC-Feature-Vector by OC-Supported-Features
 (Mbit for OC-Feature AVP case is already covered by the statement about
 Sub-AVPs in  4.3). “Existing commands” is a bit ambiguous  as an existing
 command may be used in a new application, it is proposed “commands of
 existing applications”

 Proposed text:
    When added to commands of existing applications, both OC-Supported-
    Features and OC-OLR AVPs SHOULD have the M-bit flag cleared to avoid
    backward compatibility issues.

 3) In 6.8, existing text:

    Otherwise, when reused in newly defined Diameter applications, the DOC
    related AVPs SHOULD have the M-bit set.

 This text indicates  that for a new application, there is a high
 recommendation to use DOIC, as we have a SHOULD. The specification of a
 new application may only define an optional use of DOIC. In this case
 should the Mbit be set for DOIC AVPs?

 In the following use case, the  reacting node advertise DOIC support for a
 new application in a request and set the MBit in the OC-Supported-Features
 AVP; the reporting node does not support DOIC for this new application.
 The reporting node must not reject the request because containing an AVP
 which is not supported,  it should simply ignore it and DOIC will not be
 used between these two nodes. Is additional text needed to avoid rejecting
 requests?

-- 
-------------------------------------+-------------------------------------
 Reporter:  jean-jacques.trottin     |      Owner:  draft-ietf-dime-
  @alcatel-lucent.com                |  [email-masked]
     Type:  defect                   |     Status:  new
 Priority:  minor                    |  Milestone:
Component:  draft-ietf-dime-ovli     |    Version:
 Severity:  Active WG Document       |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/dime/trac/ticket/73>
dime <http://tools.ietf.org/wg/dime/>