Skip to main content

Last Call Review of draft-ietf-dime-agent-overload-08
review-ietf-dime-agent-overload-08-opsdir-lc-liu-2017-03-15-00

Request Review of draft-ietf-dime-agent-overload
Requested revision No specific revision (document currently at 11)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-01-23
Requested 2017-01-09
Authors Steve Donovan
I-D last updated 2017-03-15
Completed reviews Opsdir Last Call review of -08 by Will (Shucheng) LIU (diff)
Secdir Last Call review of -08 by Watson Ladd (diff)
Secdir Last Call review of -09 by Ólafur Guðmundsson (diff)
Genart Telechat review of -10 by Fernando Gont (diff)
Assignment Reviewer Will (Shucheng) LIU
State Completed
Request Last Call review on draft-ietf-dime-agent-overload by Ops Directorate Assigned
Reviewed revision 08 (document currently at 11)
Result Has nits
Completed 2017-03-15
review-ietf-dime-agent-overload-08-opsdir-lc-liu-2017-03-15-00
Hi all,

(Sorry for being late that I reviewed this draft with a printed one on my
flight to home last month, however, I left paper there…) I have reviewed
draft-ietf-dime-agent-overload-08 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 specification documents an extension to RFC 7683 (Diameter
   Overload Indication Conveyance (DOIC)) base solution.  The extension
   defines the Peer overload report type.  The initial use case for the
   Peer report is the handling of occurrences of overload of a Diameter
   agent.”

My overall view of the document is 'Ready with nits' for publication.

** Technical **
No.

** Editorial **

*Section 2, page 4
>    A RFC6733 Diameter Client, an RFC6733 Diameter Server, and RFC6733
>       Diameter Agent.

s/ RFC6733/ [RFC6733]
Similar changes should also be made in this section to get consistent with
section 1 and the last sentence in section 2(therein you were using [RFC6733]).

* Section 3.1.1, page 4:

>                              +-+    +-+    +-+
>                               |c|----|a|----|s|
>                              +-+    +-+    +-+

Though I can easily guess what does “c, a, s” mean here, I still suggest to put
full words or at least add a sentence below the figure to explain. The same
issue should be fixed in all the figures below in entire section 3.

* Section 3.1.2, page 6:

>   In the case where one of the agents in the above scenario becomes
>   overloaded

s/ scenario becomes/ scenarios become

If I understand correctly , here you were referring to two scenarios above?

>   When the client has an active and a standby connection to the two
>   agents then an alternative strategy for responding to an overload
>   report from an agent is to change to standby connection to active and
>   route all traffic through the new active connection.

I would suggest to split this sentence in case of misunderstanding.

* Section 3.1.3, page 7:

>  Handling of overload of one or both of agents a11 or a12 in this case
>   is equivalent to that discussed in section 2.2.

Tried hard to find section 2.2, but there is no such section.

* Section 5.1.1, page 8:

>   When sending a Diameter request a DOIC node that supports the
>    OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
>    an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.

Full name of AVP should be put into terminology.