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

Jouni <jouni.nospam@gmail.com> Sun, 18 March 2018 17:22 UTC

Return-Path: <jouni.nospam@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 2BDA4129C59 for <aaa-doctors@ietfa.amsl.com>; Sun, 18 Mar 2018 10:22:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 BS7Xm7UdY_Gp for <aaa-doctors@ietfa.amsl.com>; Sun, 18 Mar 2018 10:22:46 -0700 (PDT)
Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 8B8DF12946D for <aaa-doctors@ietf.org>; Sun, 18 Mar 2018 10:22:45 -0700 (PDT)
Received: by mail-lf0-x22c.google.com with SMTP id v207-v6so2335181lfa.10 for <aaa-doctors@ietf.org>; Sun, 18 Mar 2018 10:22:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vw65nnVD/iLUMfegMjySk/Ku7MMxAwFvlHzI1O9bb7I=; b=L1lXp9wpO9HLnvBz16C5AlWwl8XJOZ0Tcv+r9GXKwqEzOpM0YiGLBV87uEBKom4yvi RJW2tJJPs8EvLaKOV37ZbbJE41rvhjOYaJbUmAau9Z66+XNF9jaF6o6wq1gbKbKajj8W rJ1T+CgFIoqOW+nXqIfjlD1P3IEHre0ytuUp5A1yaEXtPtnbyXMI6oZyAb8S3aAhq1ef kbWVf68o6NeOwc41e7mMPPfJwu6B80n/zaKsWfRP7LQzbdoyiRGzAuy0aa9xuTIzrBJL QQHgZMlnj/6joNUgC2ZgPIALvl+XO0fUZl8L7Jtn+gQ7g4kBwPhVib8vWGv8c4GSsUqJ 2zgg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Vw65nnVD/iLUMfegMjySk/Ku7MMxAwFvlHzI1O9bb7I=; b=IVZl3sSQcMrqv4NB8KUwryfOXXtJZRwxOoHeg9GwjZyT9guDY67+6LHhUyG0LdAMZP 50dp6BbVfsRQiT6pCxWHNiJVglwtxyuJXWMiax2Vpr74OHSP75YG+LIkGRDzAzAafrwH HvsiyIhO+vAlSehip4yGMOvVhs0C6L8CQZPymMkVMm1lBUJOHqgbfLvH/eFerQGl0CzB Z70G6cckrUYNKsCeBkN12Dr5P7k+I5ynaibNdM5UFJUBtQjxx2NLDQzOtJXx9jwzrA+C zXUmL0B+N5S+pWCWfJr/QXO91qWV1ki2OseLq0sc8qUOaH6Kya8vxTLrHyuDrW2YSKIo bBnw==
X-Gm-Message-State: AElRT7FCvnZuyXVmzdkCBQ/aFvVOMzfbQzJXYg2ITULbA4VLN1HubNE1 uQSWgJxgS4xvho82eH2L/3g=
X-Google-Smtp-Source: AG47ELvH+l7gd1hINpP7J4jVVaY4baMaPqCigSpj5+Wj/0nHPLcn9mZ4xex8N9MJQtl6K013nIlENA==
X-Received: by 2002:a19:e1c3:: with SMTP id l64-v6mr6017017lfk.110.1521393763831; Sun, 18 Mar 2018 10:22:43 -0700 (PDT)
Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id g10-v6sm2953220lfe.21.2018.03.18.10.22.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 18 Mar 2018 10:22:43 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Jouni <jouni.nospam@gmail.com>
In-Reply-To: <397_1521105881_5AAA3BD9_397_423_4_6B7134B31289DC4FAF731D844122B36E2D36D97E@OPEXCLILM43.corporate.adroot.infra.ftgroup>
Date: Sun, 18 Mar 2018 19:22:41 +0200
Cc: "john.zhao" <yuankui.zhao@gmail.com>, "aaa-doctors@ietf.org" <aaa-doctors@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <6B3A4576-57D9-4DA4-B397-5EA220238680@gmail.com>
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>
To: "ext lionel.morand@orange.com" <lionel.morand@orange.com>, Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/aaa-doctors/W8ZXE7kHr25NE6ttoTfJa0qy_oc>
Subject: Re: [AAA-DOCTORS] [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: Sun, 18 Mar 2018 17:22:48 -0000

Sorry for being a late comer to his discussion. (I am also one of the authors but did not participate to the discussion of the errata earlier - shame on me).

First I do not think the added note in the proposed errata text adds any value. The reserved _value_ 0 is reserved. One cannot use/send such in OC-Feature-Vector AVP. Also the wording in the note is somewhat confusing "The value of zero (0) any DOIC node supports at least the Loss algorithm.” Something is missing from that sentence.

The new added table is OK.. but not necessarily needed. What I think really would be useful is the change to Section 9.2. (new IANA registries) that was proposed during the initial discussion of the errata but not in the reported errata. That changed the “value” to “ assigned bit”, which in my opinion makes the use of the assignment very clear.

Regards,
	Jouni



> On 15 Mar 2018, at 11:24, lionel.morand@orange.com wrote:
> 
> 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>;
> 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>;
>  
> 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.
> 
> _______________________________________________
> AAA-DOCTORS mailing list
> AAA-DOCTORS@ietf.org
> https://www.ietf.org/mailman/listinfo/aaa-doctors