Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT)

Steve Donovan <srdonovan@usdonovans.com> Mon, 04 February 2019 19:51 UTC

Return-Path: <srdonovan@usdonovans.com>
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 AF697130EEF for <dime@ietfa.amsl.com>; Mon, 4 Feb 2019 11:51:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no 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 QydkSLKV2xrm for <dime@ietfa.amsl.com>; Mon, 4 Feb 2019 11:51:02 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A48D6126DBF for <dime@ietf.org>; Mon, 4 Feb 2019 11:51:02 -0800 (PST)
Received: from [97.99.21.33] (port=62536 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <srdonovan@usdonovans.com>) id 1gqkGZ-00GgGT-By for dime@ietf.org; Mon, 04 Feb 2019 11:51:02 -0800
To: dime@ietf.org
References: <154820228584.13271.9727761853618479099.idtracker@ietfa.amsl.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <3a7150e2-5347-f7af-7aa0-b4e0471dba69@usdonovans.com>
Date: Mon, 4 Feb 2019 13:50:50 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <154820228584.13271.9727761853618479099.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------C8CCDD70D9D64403C00E1B4E"
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/Mh-BDDqXwEjPTy4Fe7u7wi9vdYc>
Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT)
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 04 Feb 2019 19:51:06 -0000

Adam,

Thanks for your review and comments.

Please see my responses inline.

Steve

On 1/22/19 6:11 PM, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-dime-doic-rate-control-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> Thanks to everyone who worked on this document. I have a handful of editorial
> comments on its contents that the editor may wish to consider when revising it
> to address the I-D nits identified by the document shepherd.
>
> ---------------------------------------------------------------------------
>
> §1:
>
>>  of reporting nodes when subjected to rapidly changing loads.  The
> Nit: "...rapidly-changing..."
>
>>  One of the benefits of a rate based algorithm over the loss algorithm
> Nit: "...rate-based..."
>
>>  to distribute it's load over the set of reacting nodes from which it
> Nit: "...its load..."
>
>>  specify the amount of traffic on a per reacting node basis implies
> Nit: "...per-reacting-node basis..."
>
>>  traffic to that reacting node.  If the number of reacting node
>>  changes, either because new nodes are added, nodes are removed from
> Nit: "...number of reacting nodes..."
>
>>  Conveyance (DOIC) solution [RFC7683] to add support for the rate
>>  based overload abatement algorithm.
> Nit: "...rate-based..."
SRD> The above changes have been made.  My English teaching wife would
be embarrassed by the use of "it's"...
>
> ---------------------------------------------------------------------------
>
> §4:
>
>>  As defined in [RFC7683], a DOIC reporting node supporting the rate
>>  feature MUST select a single abatement algorithm
> Consider whether normatively reiterating normative language from another
> specification makes sense. In the general case, this is a bad idea, since it
> opens the door to conflicting normative definitions of behavior. Non-normative
> restatement of behavior with a citation to the document that has the normative
> description is typically safer.
SRD>  Good suggestion.  Changed to:

        As defined in [RFC7683], a DOIC reporting node supporting the rate
        feature selects a single abatement algorithm in the
OC-Feature-Vector
        AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC
reacting nodes.
>
> ---------------------------------------------------------------------------
>
> §5.1:
>
>>     This is different from the behavior defined in [RFC7683] where a
>>     single loss percentage sent to all reacting nodes.
> Nit: "...percentage is sent..." (consider also: "...where a reporting node
> sends a single loss percentage to all reacting nodes.")
SRD> Changes made.
>
> ---------------------------------------------------------------------------
>
> §5.2:
>
>>  OC-OLR AVP as an element of the abatement algorithm specific portion
> Nit: "...abatement-algorithm-specific portion..."
SRD> Change made.
>
> ---------------------------------------------------------------------------
>
> §5.3:
>
>>  A reporting node that has selected the rate overload abatement
>>  algorithm and enters an overload condition MUST indicate rate as the
>>  abatement algorithm in the resulting reporting node OCS entries.
>>
>>  A reporting node that has selected the rate abatement algorithm and
>>  enters an overload condition MUST indicate the selected rate in the
>>  resulting reporting node OCS entries.
> These paragraphs are similar enough that it's kind of tricky to pull out the
> intended distinction being made. Consider:
>
>    A reporting node that has selected the rate overload abatement
>    algorithm and enters an overload condition MUST indicate rate as the
>    abatement algorithm and MUST indicate the selected rate in the resulting
>    reporting node OCS entries.
SRD> Change made.
>
> ---------------------------------------------------------------------------
>
> §5.6:
>
>>     Other algorithms for controlling the rate MAY be implemented by
>>     the reacting node.  Any algorithm implemented MUST result in the
>>     correct rate of traffic being sent to the reporting node.
> It's not clear why this paragraph is indented. In some RFCs, it's conventional
> to indent non-normative editor's notes to help with clarity. The presence of
> normative language in this paragraph points away from that usage. Consider
> either un-indenting this paragraph, or explaining the way in which this document
> uses indented paragraphs (e.g., in the Introduction)
SRD> I'm not sure why it was indented.  I've removed the indentation.
> ---------------------------------------------------------------------------
>
> §7.  Rate Based Abatement Algorithm
>
> Nit: "Rate-Based..."
SRD> Change made.
>
>
>
> ---------------------------------------------------------------------------
>
> §8.1:
>
>>  New AVPs defined by this specification are listed in Section 6.  All
>>  AVP codes are allocated from the 'Authentication, Authorization, and
>>  Accounting (AAA) Parameters' AVP Codes registry.
> This is a bit confusing -- it's not clear to me whether the information in §6.3
> requires IANA action. It would probably be best to be a bit more explicit in
> this section about specifically which actions IANA needs to take.
>
> ---------------------------------------------------------------------------
>
> §8.3:
>
>>  All DOIC report types defined in the future MUST indicate whether or
>>  not the rate algorithm can be used with that report type.
> It is also unclear what actions IANA is expected to perform based on this input.
>
> ---------------------------------------------------------------------------
>
> §10:
>
> Either remove or (preferably) populate this section.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime