Subject: [Dime] draft-ietf-dime-ovli-04.txt: feedback

From: Benoit Claise <[email-masked]>
Date: Fri, 17 Oct 2014 12:35:01 +0200

Dear all,

Here is some feedback on draft-ietf-dime-ovli-04.txt.
Note that some of it might overlap with what was discussed during the 
interim meeting during these 2 days.

-
Note that the overload control solution defined in this
specification does not address all the requirements listed in
[RFC7068]. A number of overload control related features are left
for the future specifications.

You have to be more specific on which requirements this document 
support, and why a subset is only supported.
Can you please open an issue tracker for this (not Internet connectivity 
right now)

- OLD:
Furthermore, the solution is designed to apply to existing
and future Diameter applications, requires no changes to the Diameter
base protocol [RFC6733] and is deployable in environments where some
Diameter nodes do not implement the Diameter overload control
solution defined in this specification.

NEW:
Furthermore, the solution, _which is _designed to apply to existing
and future Diameter applications, requires no changes to the Diameter
base protocol [RFC6733] and is deployable in environments where some
Diameter nodes do not implement the Diameter overload control
solution defined in this specification.

-
Abatement Algorithm
An algorithm requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.

I think the reporting nodes request a mechanism, not an algorithm.
Proposal:
Abatement Algorithm
A _mechanism _requested by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.

Alternate proposal:
An algorithm _initiated _by reporting nodes and used by reacting
nodes to reduce the amount of traffic sent during an occurrence of
overload control.

- Terminology:
It would be beneficial if you would tell which RFC 6733 terms you use in 
this document, and be consistent with those.
Also, be consistent throughout the draft regarding capitalized terms.
Example: RFC 6733 speaks of Diameter Client/Server. This document speaks 
sometimes client, Diameter client, Diameter Client

-
OLD:
Reacting Node
A Diameter node that consumes and acts upon a report.

NEW:
Reacting Node
A Diameter node that consumes and acts upon _an overload report._

- OLD:
Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP all request messages originated or relayed by
the Diameter node.

NEW:
Reacting nodes indicate support for DOIC by including the OC-
Supported-Features AVP _in _all request messages originated or relayed by
the Diameter node.

- I've been confused by the "Loss Algorithm" name, which is really about 
a "percentage reduction".
If you have in the future a "rate reduction" algorithm, how will you 
call this one?

- There are multiple sections discussing the same topic, for example the 
default value for the OC-Validity-Duration.
Section 6.3

    The default value for the OC-Validity-Duration AVP value is 5 (i.e.,
    5 seconds)

Section 6.4,

    The default value for the OC-Validity-Duration AVP is 5 (i.e., 5
    seconds).

- There are multiple sections discussing the same topic, for example M-bit
covered in section 4.3 (normative)

    More specifically, the sub-AVPs inside the OC-Supported-Features and
    OC-OLR AVP MAY have the M-bit set.

covered in section 6. Attribute Value Pairs (Normative)

    When added to existing commands, both OC-Feature-Vector and OC-OLR
    AVPs SHOULD have the M-bit flag cleared to avoid backward
    compatibility issues.

covered in 6.8. Attribute Value Pair flag rules

    The Diameter overload control AVPs SHOULD always be sent with the
    M-bit cleared when used within existing Diameter applications to
    avoid backward compatibility issues.

I believe that the document will be clearer with a single normative 
section discussing one topic.
Btw, that's a generic comment at this point: the draft looks like a 
series of edits, and would be benefit from an editorial/consistency pass.

-
OC-OLR AVPs with unknown values SHOULD be silently discarded and the 
event SHOULD
be logged.

What do you mean by "OC-OLR AVPs with unknown values"?   Unknown to whom?
* Do you mean "out of range", like OC-Reduction-Percentage of 101 % (for 
Integer32)
If yes, this is covered already:

    The value of the Reduction-Percentage AVP is between zero (0) and
    one hundred (100). Values greater than 100 are ignored

* Do you mean "not assigned", like OC-report-type value of 2, which 
doesn't exist
Note: section 6.7 should point to IANA, I guess

- I believe that the IANA considerations "AVP codes" section 8.1 should 
be extended.
Take an existing RFC as an example.

Regards, Benoit