Diameter Overload Rate Control
draft-ietf-dime-doic-rate-control-11

[Ballot comment]
Thanks for this well-written document!  My comments are all essentially
editorial in nature.

One comment of a general note regards the usage of the word "indicate" --
usually when I read "indicate" I expect that to be part of some
protocol message or other formal data structure, but IIUC the OCS is
entirely a local matter, so "indicating" something in the OCS could be
equally well said as "storing" or "noting" or similar.  (I do see other
similar usage of "indicate" in RFC 7683, so it's unclear that there are
really any grounds for changing the usage in this document.)

Section 4

nit: Saying that nodes MUST indicate support for *both* loss and rate seems
to duplicate the requirement from RFC 7683 and would potentially complicate
future updates.  The descriptive note about "nodes supporting the rate
feature will support both" seems a better way to phrase things.

Section 5.1

Is keeping track of how much a reacting node is actually sending considered
to not be part of the OCS (as opposed to the allocated rate, which is part
of the OCS as noted here)?

Section 6.2

  This extension does not define new overload report types.  The
  existing report types of host and realm defined in [RFC7683] apply to
  the rate control algorithm.  The peer report type defined in
  [I-D.ietf-dime-agent-overload] also applies to the rate control
  algorithm.

side note: I'm curious how the directionality is such that the report type
applies to the algorithm, as opposed to the other way around.

Section 7.1

  Upon receiving the overload report with a target maximum Diameter
  request rate, each reacting node applies abatement treatment for new
  Diameter requests towards the reporting node.

(nit?) My (hasty) reading of 7683 is that "abatement treatment" means
either diversion or throttling, and that traffic processed normally is not
considered to receive "abatement treatment".  If that reading is correct,
then this text is suggesting that no new requests receive normal treatment
after the reception of an OLR with a target rate, which does not seem quite
right.

Section 7.2

  Note that the value of OC-Maximum-Rate AVP (in request messages per
  second) for the rate algorithm provides an upper bound on the traffic
  sent by the reacting node to the reporting node.

I see that this is not using normative language, and that the following
paragraph does clarify the caveats, but "upper bound" usually is read as
"strict upper bound", and there are several ways in which this bound could
(at least temporarily) not be strict.  Perhaps "loose upper bound" is
better phrasing.

Section 7.3.1

Perhaps note explicitly that "//" denotes comments?

  In determining whether or not to transmit a specific message, the
  reacting node can use any algorithm that limits the message rate to
  the OC-Maximum-Rate AVP value in units of messages per second.  For
  ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target
  inter-Diameter request interval.  It may be strictly deterministic,
  or it may be probabilistic.  It may, or may not, have a tolerance

nit: The intervening sentence defining 'T' seems to change the binding of
"It" away from "the algorithm".

  Note that when the OC-Maximum-Rate value is 0 with a non-zero OC-
  Validity-Duration, then the reacting node should apply abatement
  treatment to 100% of Diameter requests destined to the overloaded
  reporting node.  However, when the OC-Validity-Duration value is 0,
  the reacting node should stop applying abatement treatment.

nit: this paragraph seems like it would be better placed elsewhere, as its
content is independent of any particular throttling algorithm.

  Reporting nodes with a very large number of reacting nodes, each with
  a relatively small arrival rate, will generally benefit from a
  smaller value for TAU in order to limit queuing (and hence response
  times) at the reporting node when subjected to a sudden surge of
  traffic from all reacting nodes.  Conversely, a reporting node with a
  relatively small number of reacting nodes, each with proportionally
  larger arrival rate, will benefit from a larger value of TAU.

Am I correct in assuming that "larger" and "smaller" values of TAU here are
to be measured with respect to T (i.e., as a ratio)?  This may be worth
stating more explicitly.

Section 8.3

Do you want to add this requirement as a "Note" on the IANA registry
itself?

Section 9

Other than what Mirja has already noted, I only have one minor remark.

It seems that an attacker that can set up reacting nodes has a slightly
different way to disrupt legitimate traffic when "rate" is used vs. "loss",
but the details of any attack depend on implementation behavior at the
reporting node (e.g., whether it divides its total capacity evenly amongst
reacting nodes or uses a more complicated allocation scheme).  And since an
attacker that can set up new reacting nodes is almost certainly able to
send traffic from those nodes, in practice there is no substantial
difference, so the decision to ignore this difference and just refer to the 7683 security
considerations seems justified.

[Ballot comment]

Thanks to everyone who worked on this document. I have a handful of editorial
comments on its contents that the editor may wish to consider when revising it
to address the I-D nits identified by the document shepherd.

---------------------------------------------------------------------------

§1:

>  of reporting nodes when subjected to rapidly changing loads.  The

Nit: "...rapidly-changing..."

>  One of the benefits of a rate based algorithm over the loss algorithm

Nit: "...rate-based..."

>  to distribute it's load over the set of reacting nodes from which it

Nit: "...its load..."

>  specify the amount of traffic on a per reacting node basis implies

Nit: "...per-reacting-node basis..."

>  traffic to that reacting node.  If the number of reacting node
>  changes, either because new nodes are added, nodes are removed from

Nit: "...number of reacting nodes..."

>  Conveyance (DOIC) solution [RFC7683] to add support for the rate
>  based overload abatement algorithm.

Nit: "...rate-based..."

---------------------------------------------------------------------------

§4:

>  As defined in [RFC7683], a DOIC reporting node supporting the rate
>  feature MUST select a single abatement algorithm

Consider whether normatively reiterating normative language from another
specification makes sense. In the general case, this is a bad idea, since it
opens the door to conflicting normative definitions of behavior. Non-normative
restatement of behavior with a citation to the document that has the normative
description is typically safer.

---------------------------------------------------------------------------

§5.1:

>    This is different from the behavior defined in [RFC7683] where a
>    single loss percentage sent to all reacting nodes.

Nit: "...percentage is sent..." (consider also: "...where a reporting node
sends a single loss percentage to all reacting nodes.")

---------------------------------------------------------------------------

§5.2:

>  OC-OLR AVP as an element of the abatement algorithm specific portion
Nit: "...abatement-algorithm-specific portion..."

---------------------------------------------------------------------------

§5.3:

>  A reporting node that has selected the rate overload abatement
>  algorithm and enters an overload condition MUST indicate rate as the
>  abatement algorithm in the resulting reporting node OCS entries.
>
>  A reporting node that has selected the rate abatement algorithm and
>  enters an overload condition MUST indicate the selected rate in the
>  resulting reporting node OCS entries.

These paragraphs are similar enough that it's kind of tricky to pull out the
intended distinction being made. Consider:

  A reporting node that has selected the rate overload abatement
  algorithm and enters an overload condition MUST indicate rate as the
  abatement algorithm and MUST indicate the selected rate in the resulting
  reporting node OCS entries.

---------------------------------------------------------------------------

§5.6:

>    Other algorithms for controlling the rate MAY be implemented by
>    the reacting node.  Any algorithm implemented MUST result in the
>    correct rate of traffic being sent to the reporting node.

It's not clear why this paragraph is indented. In some RFCs, it's conventional
to indent non-normative editor's notes to help with clarity. The presence of
normative language in this paragraph points away from that usage. Consider
either un-indenting this paragraph, or explaining the way in which this document
uses indented paragraphs (e.g., in the Introduction)

---------------------------------------------------------------------------

§7.  Rate Based Abatement Algorithm

Nit: "Rate-Based..."



---------------------------------------------------------------------------

§8.1:

>  New AVPs defined by this specification are listed in Section 6.  All
>  AVP codes are allocated from the 'Authentication, Authorization, and
>  Accounting (AAA) Parameters' AVP Codes registry.

This is a bit confusing -- it's not clear to me whether the information in §6.3
requires IANA action. It would probably be best to be a bit more explicit in
this section about specifically which actions IANA needs to take.

---------------------------------------------------------------------------

§8.3:

>  All DOIC report types defined in the future MUST indicate whether or
>  not the rate algorithm can be used with that report type.

It is also unclear what actions IANA is expected to perform based on this input.

---------------------------------------------------------------------------

§10:

Either remove or (preferably) populate this section.

[Ballot comment]
Thank you for doing this work, and for basing it on SIP Overload Control. It's nice when protocol designers adopt good ideas from each other.

There are three SHOULDs in Section 5.1, Reporting Node Overload Control State, I'd like to understand better.

  A reporting node that uses the rate abatement algorithm SHOULD
  maintain reporting node Overload Control State (OCS) for each
  reacting node to which it sends a rate Overload Report (OLR).


^^ This one - I'm guessing that this is "SHOULD unless you're still writing code upgrading an implementation that treats all reacting nodes the same way", based on this next sentence, but I'm guessing. Why wouldn't you do this?

      This is different from the behavior defined in [RFC7683] where a
      single loss percentage sent to all reacting nodes.

  A reporting node SHOULD maintain OCS entries when using the rate
  abatement algorithm per supported Diameter application, per targeted
  reacting node and per report type.

^^ Your answer to my previous question is likely to help me understand this one, but I'm guessing reasons why you wouldn't do this.

  A rate OCS entry is identified by the tuple of Application-Id, report
  type and DiameterIdentity of the target of the rate OLR.

  The rate OCS entry SHOULD include the rate allocated to the reacting
  note.

^^ I'm really interested on this one - does the rate abatement algorithm work without knowing the rate that's allocated? but assuming that it does work, I'm still guessing why you wouldn't do this.

  A reporting node that has selected the rate overload abatement
  algorithm MUST indicate the rate requested to be applied by DOIC
  reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.

  All other elements for the OCS defined in [RFC7683] and
  [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
  when using the rate abatement algorithm.

[Ballot comment]
Thank you for doing this work, and for basing it on SIP Overload Control. It's nice when protocol designers adopt good ideas from each other.

There are three SHOULDs in Section 5.1, Reporting Node Overload Control State, I'd like to understand better.

  A reporting node that uses the rate abatement algorithm SHOULD
  maintain reporting node Overload Control State (OCS) for each
  reacting node to which it sends a rate Overload Report (OLR).


^^ This one - I'm guessing that this is "SHOULD unless you're still writing code upgrading an implementation that sends information to all reacting nodes", based on this next sentence, but I'm guessing. Why wouldn't you do this?

      This is different from the behavior defined in [RFC7683] where a
      single loss percentage sent to all reacting nodes.

  A reporting node SHOULD maintain OCS entries when using the rate
  abatement algorithm per supported Diameter application, per targeted
  reacting node and per report type.

^^ Your answer to my previous question is likely to help me understand this one, but I'm guessing reasons why you wouldn't do this.

  A rate OCS entry is identified by the tuple of Application-Id, report
  type and DiameterIdentity of the target of the rate OLR.

  The rate OCS entry SHOULD include the rate allocated to the reacting
  note.

^^ I'm really interested on this one - does the rate abatement algorithm work without knowing the rate that's allocated? but assuming that it does work, I'm still guessing why you wouldn't do this.

  A reporting node that has selected the rate overload abatement
  algorithm MUST indicate the rate requested to be applied by DOIC
  reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.

  All other elements for the OCS defined in [RFC7683] and
  [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
  when using the rate abatement algorithm.

[Ballot comment]
The security considerations of rfc7683 have an own section on non-complaint nodes (section 10.3). While this is discussed in rfc7683, I think it is especially important for this document to remind the reader that there may be non-compliant nodes that may send with a higher than indicated rate. I would recommend to add one more statement to the security considerations section of this doc and potentially point the reader explicitly at section 10.3 of rfc7683.

Two comments on normative language:

1) Section 5.6: "Any algorithm implemented MUST result in the
      correct rate of traffic being sent to the reporting node."
I would recommend to maybe change this to:
"Any algorithm implemented MUST correctly limit the maximum
rate of traffic being sent to the reporting node."
Otherwise I would think this is hard to implement in practice.

2) Section 7.2: "... the reporting node MUST periodically evaluate its overload state..."
Not sure if the normative language is really appropriate here as this does not impact interoperability, nor can be checked. If at all, I guess I would recommend a "SHOULD" instead.

And two more editorial comments:

1) As section 7.3 only describes (in quite some detail) an example algorithm, I would rather have put this in an appendix. But I guess that's a matter of taste...

2) I don't think section 8.2. is needed.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-dime-doic-rate-control-10. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the OC-Feature-Vector AVP Values (code 622) subregistry of the AVP Specific Values registry on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at:

https://www.iana.org/assignments/aaa-parameters/

a single, new value is to be registered as follows:

AVP Value: 0x0000000000000010
Attribute Name: OLR_RATE_ALGORITHM
Reference: [ RFC-to-be ]

Second, in the AVP Codes registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at:

https://www.iana.org/assignments/aaa-parameters/

a single, new value is to be registered as follows:

AVP Code: [ TBD-at-Registration ]
Attribute Name: OC-Maximum-Rate
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, section 6.3 provides AVP Flag Rules.

IANA Question --> Is there a request for registration of this information. If so, where should that registration take place; in what registry? If not, could this information be place elsewhere in a revised draft for clarity to the reader?

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-01-16):

From: The IESG
To: IETF-Announce
CC: ben@nostrum.com, lionel.morand@orange.com, dime-chairs@ietf.org, dime@ietf.org, Lionel Morand , draft-ietf-dime-doic-rate-control@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Diameter Overload Rate Control) to Proposed Standard


The IESG has received a request from the Diameter Maintenance and Extensions
WG (dime) to consider the following document: - 'Diameter Overload Rate
Control'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-01-16.  Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This specification documents an extension to the Diameter Overload
  Indication Conveyance (DOIC) [RFC7683] base solution.  This extension
  adds a new overload control abatement algorithm.  This abatement
  algorithm allows for a DOIC reporting node to specify a maximum rate
  at which a DOIC reacting node sends Diameter requests to the DOIC
  reporting node.

Requirements



The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ballot/


No IPR declarations have been submitted directly on this I-D.

This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I previously reviewed version 8, however since some time has passed I reviewed this version “from scratch”.

In general the draft is in good shape. I think it’s ready for IETF Last Call, which I will request shortly. Please note the last call window will be extended due to the upcoming holidays.

I have a few minor comments that can be resolved along with any last call feedback.
-------------------------------------

§4, paragraphs 2 and 3: Am I correct to assume that, as new DOIC algorithms get added, nodes could support both of these and something else? If so, then in paragraph 2 I suggest s/ “ support both the loss and rate based abatement algorithms”/ "support at least the loss and rate based abatement algorithms”

... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.”

(nit) §5.5, 2nd paragraph: "It is also possible for the reporting node to send overload
reports with the rate algorithm indicated when the reporting node
is not in an overloaded state.”

I suggest s/ “indicated when” / “indicated even when”

(nit) §5.6, first paragraph: The algorithm is detailed in 7.3.

§7.3.1: "To apply abatement treatment to new Diameter requests at the rate
specified in the OC-Maximum-Rate AVP value sent by the reporting node
to its reacting nodes, the reacting node MAY use the proposed default
algorithm for rate-based control or any other equivalent algorithm
that forward messages in conformance with the upper bound of 1/T
messages per second.”

This is redundant to similar normative text in §5.6. I suggest keeping just one (probably this one since it’s more precise) and use descriptive language for the other.

§9: Do the authors think that the rate algorithm might be more effective at DoS mitigation than the loss algorithm? If so, that might be worth a mention in the security considerations.

This is my AD Evaluation of draft-ietf-dime-doic-rate-control-08.

Thank you for doing the work on this. I think the document is on the right track, but needs a little work before it will be ready for IETF last call.
————————————————————
Substantive Comments:

General:
The document seems inconsistent about whether rate limits are only reported during overload conditions, or in advance of overload conditions.

I’d like to see the need to allocate the rate limit across all potential sources of traffic given some more emphasis. (Maybe a sub-section of its own?)

§1:
- “ While this can effectively decrease the load handled by the
  server, it does not directly address cases where the rate of arrival
  of service requests increases quickly."

I think it fails to address cases where the load changes rapidly in either direction, right? At least, the following text seems to say that.

§3: Does the need for future report types to consider the rate algorithm have IANA implications?

§5.1: The first paragraph indicates state should be kept for every reacting node to which it sends an OLR. But the 5th paragraph can be interpreted to say it sends an OLR to every reacting node with which it has negotiated use of the rate algorithm. (see general comment).

§5.4: The first paragraph seems to suggest the reacting node keeps OCS for every server that has indicated support for the rate algorithm, not just nodes that have sent OLRs. Is that the intent?

§5.6, first paragraph: The MAY seems week here. I know and agree that we don’t want to force a particular application. But don’t we need to say that if an implementation uses a different algorithm, it MUST have the same behavior as the algorithm in section 7?

§7.2, third and 4th paragraphs: I don’t understand what this is trying to say. Please elaborate.
-6th paragraph: “  may receive requests at a rate below its target maximum Diameter  request rate while others above that target rate.  But the resulting request rate presented to the overloaded reporting node will converge towards the target Diameter request rate.”

Why do we expect traffic to converge to the rate limit? It seems like that won't happen if some reporting nodes are not sending at full capacity, unless work can be shifted from the high-rate sources to the slow-rate ones.

§7.3.1: paragraph starting with “ In situations where reacting nodes are configured with some knowledge”

that requires knowledge of other traffic sources, not just knowledge of the reporting node.

The example code says to transmit a message if (Xp <= TAU). But the text said the limit was “T+TAU).

§9: I think the security considerations need more thought. What are the security considerations specific to the rate algorithm? If there aren’t any, then please describe the rational behind that. But I suspect there are, for example, can this be used for a DoS? Can it be used to help _mitigate_ a DoS? Could one reacting node cause others to be traffic starved?

Editorial Comments:

General: IDNits returns several issues. Some of those may be errors on its part, but I’m pretty sure some of them are real. Please resolve these.

Requirements: There are instances of lower case “must” and “should”. Please use the new boilerplate from RFC 8174.

§1
- “protect the stability” seems awkward. Maybe “ensure the stability”?
- Also s/ “subjected with” / “subjected to”.

- Please cite the definitions for “reporting node” and “reacting node”. I know they are defined later, but these are somewhat non-intuitive concepts and people will likely stumble over the terms when they are used before they are defined.
- Please expand DOIC and SOC on first mention in the body. (Even if they were expanded in the abstract.)

§2:
- Definitions of “Diameter Node” and “Diameter Endpoint”: Please use proper citations rather than just referring to the RFC in text. For example: “Diameter Node: A Diameter client, server, or agent.  [RFC6733]”

§4,
- first paragraph:
— “This extension defines”: I think this should say “This document defines…”
— Please consider active voice for the last sentence.

- 2nd paragraph: The first sentence seems awkward. Consider something to the effect of “Since all nodes that support DOIC are required to support the loss algorithm…”

- 3rd paragraph: This paragraph seems to belong as part of the previous paragraph.

- 4th paragraph: “ AVP in the sent to the DOIC reacting nodes”: Missing word(s)?

-5th paragraph: “A reporting node MAY select…” : Is that a new permission, or a statement of fact?

§5.1, third paragraph: The text is not clear whether this means OCS should be maintained per supported application, etc, or that it should maintain state when the rate algorithm on a per supported application, etc, basis.
- 4th paragraph: s/overoload/overload

§5.3: 2nd paragraph: This seems like a redundant restatement of the first paragraph.
- third paragraph: The first sentence is convoluted; can it be broken into simpler sentences?

§6.1.1, definition of " OLR_RATE_ALGORITHM”: Two periods at end of sentence.


§7.1, 2nd paragraph: “ signal one another support for rate-based overload
  control”: This seems awkward; are there missing words?

§7.2, last two paragraphs: The MUSTs do not seem necessary. 2119 keywords should be used when there is some sort of choice or room for error. You don’t need them to define the basic operation of the protocol.

§7.3.1: I found the text hard to follow. It would help to declare all the identifiers and initialization up front, and to present things in more of a stepwise fashion.

- T is effectively a time interval, right? It would help to say that, especially later when you subtract a different time interval from it.

- paragraph 9: Should “admit” be “emit”?

- the example code has several mentions of SIP requests.

§7.3.2: “ Request candidates for reduction, requests not subject to reduction (except under extenuating circumstances when there aren’t any messages in the first category that can be reduced).”: That seems like an awkward way to say that the second category is the set of requests that is only subject to reduction if there are no messages left in the first category.

- “ This can be generalized to n priorities using n thresholds for n>2 in the obvious way.”: I suggest you refrain from calling it “obvious".

§7.3.3: Paragraph starting with “ Then (only) if the arrival is admitted, increase the bucket by an amount…”: I think you increase the bucket _count_, right?

1. Summary

The document shepherd is Lionel Morand. The responsible Area Director is Eric Rescorla.

This document defines an abatement algorithm that allows Diameter nodes to notify the maximum rate at which Diameter requests can be received. This is an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution, in which only the loss algorithm was defined, used to request a percentage reduction in the amount of traffic received. 

Intended status: Standards Track

2. Review and Consensus

In the Diameter Overload Indication Conveyance (DOIC) base solution, the default algorithm to support is the "loss" algorithm, used to request a percentage reduction in the amount of traffic received. The present document defines a new algorihtm, "rate", that is used to announce a maximum rate instead of a percentage of requested traffic reduction. Highlighting the limits of the loss algorithm, this new algorithm is designed to better handle spikes in traffic. It heavily relies on the rate-based algorithm defined by the SIP Overload Control working group adapting to the DOIC solution and the Diameter protocol.

The algorithm used to estimate a target maximum Diameter request rate is left out of scope of this document but some recommendations are given.
Any algorithm can be used to limit the message rate to comply with requested maximum sending rate. However, a default algorithm is described in the document.

The proposed solution has not been implemented yet, as vendors are waiting for IANA AVP code value assignment before implementing.  However, no issues are expected with implementation. Moreover, the solution defined in this document inherits from the work done for SIP. It is known that 3GPP operators want to use this rate-based mechanism instead of the loss algo in their network, using a similar mechanism in SIP/IMS.

The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. The version -03 addresses the last comments received after the WGLC process and the shepherd review. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts.

3. Security Considerations

There is no specific security concerns highlighted in this document. The Security considerations section outlined in [RFC7683] apply to the rate overload abatement mechanism that is just a new algo defined for the Diameter overload control mechanism.

4. IANA considerations

The IANA considerations section is consistent with the body of the document. All protocol extensions are associated with appropriate reservations for IANA.

5. Intellectual Property

The author and contributor have confirmed conformance with IETF IPR rules (RFCs 3979, 4879, 3669, and 5378). There are no IPR disclosures on the document.

6. ID Nits

Some IDnits that can be handled with a rev of the document when publishing the document;

  Checking boilerplate required by RFC 5378 and the IETF Trust (see
  https://trustee.ietf.org/license-info):
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking nits according to https://www.ietf.org/id-info/checklist :
  ----------------------------------------------------------------------------

  ** There is 1 instance of too long lines in the document, the longest one
    being 4 characters in excess of 72.

  ** The abstract seems to contain references ([RFC2119], [RFC7683]), which
    it shouldn't.  Please replace those with straight textual mentions of the
    documents in question.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

    No issues found here.

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

    (See RFCs 3967 and 4897 for information about using normative references
    to lower-maturity documents in RFCs)

  -- Looks like a reference, but probably isn't: '0' on line 758

  == Missing Reference: 'T' is mentioned on line 758, but not defined

  == Unused Reference: 'RFC5226' is defined on line 806, but no explicit
    reference was found in the text

  == Unused Reference: 'RFC6733' is defined on line 811, but no explicit
    reference was found in the text

  == Outdated reference: A later version (-11) exists of
    draft-ietf-dime-agent-overload-00

  ** Obsolete normative reference: RFC 5226

    Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--).

    Run idnits with the --verbose option for more detailed information about
    the items above.

7. Other points

An errata report on RFC7683 (Errata ID: 5277) has been issued and it is related to IANA policy for the OC-Feature-Vector AVP value allocation. The present document adds a new algo for DOIC and then a new feature flag is needed in the OC-Feature-Vector AVP. During the review, it has been identified that the current text describing the value for OC-Feature-Vector AVP is not correct. While the AVP is defined as a 64-bit mask, in which each bit indicates a supported feature, the initial text was implying that a value needed to assigned per feature, which was wrong. The current version of this document takes into account this errata report.

A small error remains in the document that can be covered by a last revision: in the default algo for Rate-based Control shown in section 7.3.1, "SIP" is used instead of "Diameter".

For information, the document defines a new algorithm that is referenced as normative reference of draft-ietf-dime-agent-overload-11 (waiting for IESG review), which is itself used as referenced by the draft-ietf-dime-load-09 (already in the RFC Ed Queue).

Comments mainly received from Misha Zaytsev. These should be addressed before submitting the document to the IESG.
See https://www.ietf.org/mail-archive/web/dime/current/msg09118.html
Likely no new WGLC is needed after that.