Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC7683 (5277)

["john.zhao" <[e-mail]>]

Hi Benoit,

        The last word of "abatment" should be "abatement". In side of the
'description' column, the "OLR_DEFAULT_ALGO"could be set but as 1 always
should be stated. As any other features could be set but 0 or 1 in the
future.

        Just FYI.

        Thanks,
BR//John Zhao

2018-03-06 19:21 GMT+08:00 Benoit Claise <[e-mail]>:

> Feedback on this one?
>
> Regards, B.
>
>
> -------- Forwarded Message --------
> Subject: [Technical Errata Reported] RFC7683 (5277)
> Date: Tue, 6 Mar 2018 02:47:50 -0800
> From: RFC Errata System <[e-mail]>
> <[e-mail]>
> To: [e-mail], [e-mail], [e-mail],
> [e-mail], [e-mail], [e-mail],
> [e-mail], [e-mail]
> CC: [e-mail], [e-mail], [e-mail]
>
> The following errata report has been submitted for RFC7683,
> "Diameter Overload Indication Conveyance".
>
> --------------------------------------
> You may review the report below and at:http://www.rfc-editor.org/errata/eid5277
>
> --------------------------------------
> Type: Technical
> Reported by: Lionel Morand <[e-mail]> <[e-mail]>
>
> Section: 7.2
>
> Original Text
> -------------
> 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.
>
> Corrected Text
> --------------
> 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.
>
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC7683 (draft-ietf-dime-ovli-10)
> --------------------------------------
> Title               : Diameter Overload Indication Conveyance
> Publication Date    : October 2015
> Author(s)           : J. Korhonen, Ed., S. Donovan, Ed., B. Campbell, L. Morand
> Category            : PROPOSED STANDARD
> Source              : Diameter Maintenance and Extensions
> Area                : Operations and Management
> Stream              : IETF
> Verifying Party     : IESG
> .
>
>
>
> _______________________________________________
> AAA-DOCTORS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/aaa-doctors
>
>