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

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:aaa-doctors-bounces@ietf.org] De la part de Benoit Claise
Envoyé : mercredi 14 mars 2018 21:45
À : john.zhao
Cc : aaa-doctors@ietf.org
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 <bclaise@cisco.com<mailto:bclaise@cisco.com>>:
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 <rfc-editor@rfc-editor.org><mailto:rfc-editor@rfc-editor.org>

To:

jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>, srdonovan@usdonovans.com<mailto:srdonovan@usdonovans.com>, ben@nostrum.com<mailto:ben@nostrum.com>, lionel.morand@orange.com<mailto:lionel.morand@orange.com>, bclaise@cisco.com<mailto:bclaise@cisco.com>, warren@kumari.net<mailto:warren@kumari.net>, jouni.nospam@gmail.com<mailto:jouni.nospam@gmail.com>, lionel.morand@orange.com<mailto:lionel.morand@orange.com>

CC:

lionel.morand@orange.com<mailto:lionel.morand@orange.com>, dime@ietf.org<mailto:dime@ietf.org>, rfc-editor@rfc-editor.org<mailto:rfc-editor@rfc-editor.org>

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 <lionel.morand@orange.com><mailto:lionel.morand@orange.com>

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
AAA-DOCTORS@ietf.org<mailto:AAA-DOCTORS@ietf.org>
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.