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

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

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dime-agent-overload-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-agent-overload/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

One rather important comment:
While the security considerations section describes a possible attack, it
does not say anything about how to handle this attack and the actually
impact this attack might have. Please add more text!

And then some mostly editorial high level comments:
All in all, I had a rather hard time reading this document because it
seems on the one hand sightly over-specified and over structured, while
not giving very concrete guidance in some cases.

E.g. in section 5.2.5;
 "In the case that the OCS entry validity duration expires or has a
   validity duration of zero ("0"), meaning that if the reporting node
   has explicitly signaled the end of the overload condition then
   abatement associated with the OCS entry MUST be ended in a
controlled
   fashion."
   I don't think normative language is needed here because there is no
impact of interoperation. But then is does't explain what "in a
controlled fashion means". So I wouldn't even know how to implement that
MUST correctly.

Another example in section 4:
" In this scenario, when doing abatement on the
   PEER report, the reacting node SHOULD take into consideration the
   number of messages already throttled by the handling of the HOST/
   REALM report abatement."
How to take that into consideration? And why is this normative?

Or here in section 5.2.3:
"When a reacting node receives an OC-OLR AVP with a report type of
   peer it MUST determine if the report was generated by the Diameter
   peer from which the report was received.

   If a reacting node receives an OC-OLR AVP of type peer and the
   SourceID matches the DiameterIdentity of the Diameter peer from
which
   the response message was received then the report was generated by a
   Diameter peer."
Why don't you just say the following:
"When a reacting node receives an OC-OLR AVP with a report type of
   peer it MUST determine that the SourceID matches the DiameterIdentity
of the Diameter peer from which
   the response message was received."

Also the indentation used is sometimes confusing. In some cases you
should probably really use real listings with bullet points.