Hi all, I have reviewed draft-ietf-dime-load-07 as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. “This document defines a mechanism for conveying of Diameter load information. RFC7068 describes requirements for Overload Control in Diameter. This includes a requirement to allow Diameter nodes to send "load" information, even when the node is not overloaded. RFC7683 (Diameter Overload Information Conveyance (DOIC)) solution describes a mechanism meeting most of the requirements, but does not currently include the ability to send load information.” My overall view of the document is 'Ready with nits' for publication. ** Technical ** No. ** Editorial ** *Section 4, page 4 >That is, the OLR requests that the reacting node reduce the offered load……. s/reduce/reduces * Section 4.1, page 5: >The fundamental difference is that an overload report requires that reduction. What does the second “that” refer to? It may change to “The fundamental difference is that an overload report requires the reduction of offered load”or so. * Section 5, page 10: >For the PEER load report, C follows the same procedure as A1 for determining if the Load report was received from the peer from which the report was sent and, when finding it does, stores the load information for use when making future routing decisions. This sentence may need to split for more readable purpose. * Section 5: Full name of *AVP* should be put into Abbreviations before using first time.