Subject: Review of draft-ietf-dime-load-07

From: Shucheng LIU <[email-masked]>
Date: Wed, 01 Mar 2017 22:54:00 -0800

Reviewer: Shucheng LIU
Review result: Has Nits

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.