[Dime] Mirja Kühlewind's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind 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:
----------------------------------------------------------------------

The security considerations of rfc7683 have an own section on non-complaint
nodes (section 10.3). While this is discussed in rfc7683, I think it is
especially important for this document to remind the reader that there may be
non-compliant nodes that may send with a higher than indicated rate. I would
recommend to add one more statement to the security considerations section of
this doc and potentially point the reader explicitly at section 10.3 of rfc7683.

Two comments on normative language:

1) Section 5.6: "Any algorithm implemented MUST result in the
      correct rate of traffic being sent to the reporting node."
I would recommend to maybe change this to:
"Any algorithm implemented MUST correctly limit the maximum
 rate of traffic being sent to the reporting node."
Otherwise I would think this is hard to implement in practice.

2) Section 7.2: "... the reporting node MUST periodically evaluate its overload
state..." Not sure if the normative language is really appropriate here as this
does not impact interoperability, nor can be checked. If at all, I guess I
would recommend a "SHOULD" instead.

And two more editorial comments:

1) As section 7.3 only describes (in quite some detail) an example algorithm, I
would rather have put this in an appendix. But I guess that's a matter of
taste...

2) I don't think section 8.2. is needed.