Last Call Review of draft-ietf-dime-load-07
review-ietf-dime-load-07-opsdir-lc-liu-2017-03-01-00

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.