RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7683, "Diameter Overload Indication Conveyance", October 2015

Source of RFC: dime (ops)

Errata ID: 5277
Status: Reported
Type: Technical

Reported By: Lionel Morand
Date Reported: 2018-03-06

Section 7.2 says:

7.2.  OC-Feature-Vector AVP

   The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
   contains a 64-bit flags field of announced capabilities of a DOIC
   node.  The value of zero (0) is reserved.

   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request messages
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.  The absence of the OC-Feature-
   Vector AVP in answer messages indicates that the default traffic
   abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.


   The following capability is defined in this document:

   OLR_DEFAULT_ALGO (0x0000000000000001)

      When this flag is set by the a DOIC reacting node, it means that
      the default traffic abatement (loss) algorithm is supported.  When
      this flag is set by a DOIC reporting node, it means that the loss
      algorithm will be used for requested overload abatement.

It should say:

7.2.  OC-Feature-Vector AVP

   The OC-Feature-Vector AVP (AVP Code 622) is of type Unsigned64 and
   contains a 64-bit flags field of announced capabilities of a DOIC
   node.  The value of zero (0) is reserved.

      Note: The value of zero (0) any DOIC node supports at least the 
            Loss algorithm. Therefore, the OC-Feature-Vector AVP 
            cannot be sent with no bit set.

   The OC-Feature-Vector sub-AVP is used to announce the DOIC features
   supported by the DOIC node, in the form of a flag-bits field in which
   each bit announces one feature or capability supported by the node.
   The absence of the OC-Feature-Vector AVP in request messages
   indicates that only the default traffic abatement algorithm described
   in this specification is supported.  The absence of the OC-Feature-
   Vector AVP in answer messages indicates that the default traffic
   abatement algorithm described in this specification is selected
   (while other traffic abatement algorithms may be supported), and no
   features other than abatement algorithms are supported.

   The following capability is defined in this document:

+---+------------------+----------------------------------------------+
|bit|  Feature Name    |  Description                                 |
+---+------------------+----------------------------------------------+
| 0 | OLR_DEFAULT_ALGO |When set by a DOIC reacting node, it means    |
|   |                  |that the default traffic abatement (loss)     |
|   |                  |algorithm is supported. When set by a DOIC    |
|   |                  |reporting node, it means that the loss        |
|   |                  |algorithm will be used for requested overload |
|   |                  |abatment.                                     |
+---+------------------+----------------------------------------------+

Notes:

The OC-Feature-Vector AVP is a 64-bit flag field and not a set of values (one per feature). Using the hexadecimal notation, it gives the feeling that there is a unique value for the OC-Feature-Vector AVP per supported capability, hich is incorrect. It is only required to define the use of each bit. This errata report has an impact on the associated IANA regisrty.

Report New Errata