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

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

Hi Lionel and Benoit,


My minor comments : Beyond the 'OLR_DEFAULT_ALGO‘, any coming feature could
be set per legacy version and update version.

+---+------------------+----------------------------------------------+
|bit|  Feature Name    |  Description                                 |
+---+------------------+----------------------------------------------+
| 0 | OLR_DEFAULT_ALGO |*This bit should be set as 1 always.*           |
|   |                  |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 |
|   |                  |abat*e*ment.                                    |
+---+------------------+----------------------------------------------+

Note: changes has been marked by the "under score".

In addition, both erratas are necessary from my perspective.

        Thanks,

BR//John Zhao



2018-03-15 17:24 GMT+08:00 <[e-mail]>:

> This errata report has been discussed with authors (including Ben
> Campbell) and is triggered after the review of another diameter draft that
> want to define a new feature.
>
> The conclusion was that the clarification was needed. The only issue was
> about IANA impacts and if the proposed erratum was enough to trigger an
> update of the IANA registry.
>
>
>
> Regards,
>
>
>
> Lionel
>
>
>
> *De :* AAA-DOCTORS [mailto:[e-mail]] *De la part de*
> Benoit Claise
> *Envoyé :* mercredi 14 mars 2018 21:45
> *À :* john.zhao
> *Cc :* [e-mail]
> *Objet :* Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC7683
> (5277)
>
>
>
> Dear all,
>
> Any other views on the last two errata?
>
> Regards, B.
>
> 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
>
>
>
>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>