Steve and Eric: 

I have reveiwed this document as part of the  operational directorate (ops-dir) ongoing effort to review all IETF documents being process by the IESG for operational aspects.  These comments are to aid the authors and the NM/OPS Area Directors.  The document editors and the WG chairs hsould treat these comments as any other last call comments. 

Status: ready,  with  2 operator questions and 1 yang question.  The question are just things to think about for the authors and ADS. 

Questions: 

The documentis readable and aligns with RFC7683 and draft-ietf-dime-agent-overload.     The language in this document also aligns with language in the SIP Overload Control (SOC) document [RFC7415]. 

As I am not familar with current DIAMETER deployments, i've got a few operational 
questions for the authors to consider: 

1)  If a operator where deploying this new algorithm,
   what type of deployment considerations would 
    be necessary?   Should certain topologies 
    of Diameter deployments utilize certain 
   overload algorithms? 

 2) What failure modes will the operator see 
   in the current overload abatement that 
   would encourage the operator to 
   spend the effort to go to this new DOIC
   rate limit? 

As a researcher and implementer, sections 1 and  7 were sufficient 
to answer these questions.   However,  I would ask the authors, 
WG chairs, and OPS/NM ADs to determine if these are sufficient
for the normal operators. 

Question 3:  Just for my own understanding, 
is there a plan to control DIAMETER protocols with YANG
modules?