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

"john.zhao" <yuankui.zhao@gmail.com> Thu, 15 March 2018 17:53 UTC

Return-Path: <yuankui.zhao@gmail.com>
X-Original-To: aaa-doctors@ietfa.amsl.com
Delivered-To: aaa-doctors@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D9912DA01 for <aaa-doctors@ietfa.amsl.com>; Thu, 15 Mar 2018 10:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level:
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 PW42Gg12ESvQ for <aaa-doctors@ietfa.amsl.com>; Thu, 15 Mar 2018 10:53:48 -0700 (PDT)
Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B1D12DA00 for <aaa-doctors@ietf.org>; Thu, 15 Mar 2018 10:53:48 -0700 (PDT)
Received: by mail-lf0-x243.google.com with SMTP id t132-v6so11499978lfe.2 for <aaa-doctors@ietf.org>; Thu, 15 Mar 2018 10:53:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wWZlENQaMK8ToTUi5qBQs0PvB7LQbD9ssyQnDwsCYFM=; b=PfBndBk+wic0Sg5w7mCMZ/Nr2hheKNIMvqKR8gXhnFeFO9Um2YsVBR5CD2NywBJduI 9a+fRMLSphCWTMyS2g0s8HZSEm5IH9v72ky8rCmZzANu8xoSnr4qc3/2IYr2FOelXYkT 3jRDqPPGxn+bPqkwnje0saH+dNdzJf7WQkJ8PfHaEacoTkIb2d3CilRHPr7BIBg0Tz6P TFSLHfinB4o+Y+bsFgJ+Z0f0dXokR2cQr1LTMJh7S6KrQ7a9oyGr1ctppviaQlAb9m+u uMFAHDqYQmeviPwI3SHmBSiRO9tn21GV3mt7ZHdbn+OmDdv7X4fzSo2qI5CWzilbbM4f 87Hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wWZlENQaMK8ToTUi5qBQs0PvB7LQbD9ssyQnDwsCYFM=; b=HcTxbG3pVn9L+5XlwwiJq1KiA/0iy7pkDKe7NAKAksiqvWTuP/K6Ce7PiDcoV9Zlv+ 7mCW0L4dupCgZMaAGP+nMi3JyGQyqVE5NJtii3zVUtw1VZxY+9JUHdPhgNd0xt+ow2WU g/HRjup6LgvY6gjGUjbhDmUSr9SpjR0arEf6kNDBD/6lcO883eBgqu8oy7H7iRCajTOO c/SC2D6Ov0nfWN0BfIMh0BMnXIuzGJ4fhK42FvoSohMB8g3+nEdIgrAsL7JKKqfZz4UP gtRx2r9YsASCqi/kYO7f/9SZ2BZ2mWSRGzXoEJnV4Quld3yNXKIyaggglrBq3BLrmsuQ EGbg==
X-Gm-Message-State: AElRT7GbVE3L74TO3iCuiIYO6H1yScnatBUnzpCiEFAJbSzOYKe0leOd 8lUJhQIUigDWwQIUH9ZN7Hb2+AnkVu8YEEIcrPE=
X-Google-Smtp-Source: AG47ELs8Rzw03leTuCOA9u/1lMUKts3uYKNPu1EiNKTmWpx3tmzri1AIez6k6i64Yom0UoUSzZVEaHUCKqnwx+wD+S8=
X-Received: by 2002:a19:a003:: with SMTP id j3-v6mr5706991lfe.8.1521136426409; Thu, 15 Mar 2018 10:53:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a19:e820:0:0:0:0:0 with HTTP; Thu, 15 Mar 2018 10:53:45 -0700 (PDT)
In-Reply-To: <397_1521105881_5AAA3BD9_397_423_4_6B7134B31289DC4FAF731D844122B36E2D36D97E@OPEXCLILM43.corporate.adroot.infra.ftgroup>
References: <20180306104750.EF13EB80E97@rfc-editor.org> <68c132b6-52de-59d9-1d05-0bab97bb9212@cisco.com> <CADpucjW=fuxjMRS10Jt3A4No8Li0eVb5Q1S==Z9+yneCvQTFjA@mail.gmail.com> <e438abb8-66b0-b3da-4a1d-7b69f776c42e@cisco.com> <397_1521105881_5AAA3BD9_397_423_4_6B7134B31289DC4FAF731D844122B36E2D36D97E@OPEXCLILM43.corporate.adroot.infra.ftgroup>
From: "john.zhao" <yuankui.zhao@gmail.com>
Date: Fri, 16 Mar 2018 01:53:45 +0800
Message-ID: <CADpucjVke4z+nyp+zC0XtzowOk=cn=ikEjxkP_wy+CaecnJO0A@mail.gmail.com>
To: lionel.morand@orange.com
Cc: Benoit Claise <bclaise@cisco.com>, "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000059e57e0567772c66"
Archived-At: <https://mailarchive.ietf.org/arch/msg/aaa-doctors/_3jyFHtNFkWw642Ky0bVRc6Oc7M>
Subject: Re: [AAA-DOCTORS] Fwd: [Technical Errata Reported] RFC7683 (5277)
X-BeenThere: aaa-doctors@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: AAA Doctors E-mail List <aaa-doctors.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/aaa-doctors/>
List-Post: <mailto:aaa-doctors@ietf.org>
List-Help: <mailto:aaa-doctors-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aaa-doctors>, <mailto:aaa-doctors-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Mar 2018 17:53:52 -0000

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

> 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>;:
>
> 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>; <rfc-editor@rfc-editor.org>;
>
> *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
>
> *CC: *
>
> lionel.morand@orange.com, dime@ietf.org, 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>; <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
> 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.
>
>