[Dime] [Technical Errata Reported] RFC7683 (5277)
RFC Errata System <rfc-editor@rfc-editor.org> Tue, 06 March 2018 10:48 UTC
Return-Path: <wwwrun@rfc-editor.org>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9840D127137 for <dime@ietfa.amsl.com>; Tue, 6 Mar 2018 02:48:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-px-3o96C-c for <dime@ietfa.amsl.com>; Tue, 6 Mar 2018 02:48:07 -0800 (PST)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08153126CF6 for <dime@ietf.org>; Tue, 6 Mar 2018 02:48:07 -0800 (PST)
Received: by rfc-editor.org (Postfix, from userid 30) id EF13EB80E97; Tue, 6 Mar 2018 02:47:50 -0800 (PST)
To: jouni.nospam@gmail.com, srdonovan@usdonovans.com, ben@nostrum.com, lionel.morand@orange.com, bclaise@cisco.com, warren@kumari.net, jouni.nospam@gmail.com, lionel.morand@orange.com
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: lionel.morand@orange.com, dime@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20180306104750.EF13EB80E97@rfc-editor.org>
Date: Tue, 06 Mar 2018 02:47:50 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/owS6-fWbRFXLUTK7gLh6kG54q9Q>
X-Mailman-Approved-At: Tue, 06 Mar 2018 02:48:59 -0800
Subject: [Dime] [Technical Errata Reported] RFC7683 (5277)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Mar 2018 10:48:09 -0000
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> 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
- [Dime] [Technical Errata Reported] RFC7683 (5277) RFC Errata System