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

[Steve Donovan <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime