[Dime] Benoit Claise's No Objection on draft-ietf-dime-agent-overload-10: (with COMMENT)

[Benoit Claise <[e-mail]>]

Benoit Claise has entered the following ballot position for
draft-ietf-dime-agent-overload-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Below is the OPS DIR review by Will.

** 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.