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

[Adam Roach <[e-mail]>]

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..."

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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.")

---------------------------------------------------------------------------

§5.2:

>  OC-OLR AVP as an element of the abatement algorithm specific portion
Nit: "...abatement-algorithm-specific portion..."

---------------------------------------------------------------------------

§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.

---------------------------------------------------------------------------

§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)

---------------------------------------------------------------------------

§7.  Rate Based Abatement Algorithm

Nit: "Rate-Based..."



---------------------------------------------------------------------------

§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.