RFC Errata
Found 3 records.
Status: Verified (1)
RFC 7683, "Diameter Overload Indication Conveyance", October 2015
Note: This RFC has been updated by RFC 8581
Source of RFC: dime (ops)
Errata ID: 4549
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Jan Kayser
Date Reported: 2015-12-01
Verifier Name: Benoit Claise
Date Verified: 2016-05-17
Section 4.3 says:
The overloaded realm is identified by the Destination-Realm AVP of the message containing the OLR.
It should say:
The overloaded realm is identified by the Origin-Realm AVP of the message containing the OLR.
Notes:
When the overload report is of type "REALM_REPORT", the overloaded realm is identified by the Origin-Realm AVP of the Diameter command i.e. the realm of the originator of the Diameter command with the overload report.
Status: Reported (2)
RFC 7683, "Diameter Overload Indication Conveyance", October 2015
Note: This RFC has been updated by RFC 8581
Source of RFC: dime (ops)
Errata ID: 5277
Status: Reported
Type: Technical
Publication Format(s) : TEXT
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.
Errata ID: 5278
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lionel Morand
Date Reported: 2018-03-06
Edited by: Robert Wilton
Date Edited: 2024-01-12
Section 9.2 says:
9.2. New Registries
Two new registries have been created in the "AVP Specific Values"
sub-registry under the "Authentication, Authorization, and Accounting
(AAA) Parameters" registry.
A new "OC-Feature-Vector AVP Values (code 622)" registry has been
created. This registry contains the following:
Feature Vector Value Name
Feature Vector Value
Specification defining the new value
See Section 7.2 for the initial Feature Vector Value in the registry.
This specification defines the value. New values can be added to the
registry using the Specification Required policy [RFC5226].
A new "OC-Report-Type AVP Values (code 626)" registry has been
created. This registry contains the following:
Report Type Value Name
Report Type Value
Specification defining the new value
See Section 7.6 for the initial assignment in the registry. New
types can be added using the Specification Required policy [RFC5226].
It should say:
9.2. New Registries
Two new registries have been created in the "AVP Specific Values"
sub-registry under the "Authentication, Authorization, and Accounting
(AAA) Parameters" registry.
A new "OC-Feature-Vector AVP Values (code 622)" registry has been
created. This registry contains the following:
Assigned Bit
Feature Name
Specification defining the new capability
See Section 7.2 for the initial assigned bit in the registry.
This specification defines the capbility announced by the setting of
this bit. New values can be added to the registry using the
Specification Required policy [RFC5226].
A new "OC-Report-Type AVP Values (code 626)" registry has been
created. This registry contains the following:
Report Type Value Name
Report Type Value
Specification defining the new value
See Section 7.6 for the initial assignment in the registry. New
types can be added using the Specification Required policy [RFC5226].
Notes:
This errata report is linked to the following errata report: Errata ID: 5277
The IANA registry created for the OC-Feature-Vector AVP Values (code 622) should only describe the use of the bit assigned to a given feature. There is no AVP value assigned to a given feature. The associated IANA registry should provide a table describing the setting of the bit assigned to a given feature/capability.