Re: [Dime] AD Evaluation of draft-ietf-dime-doic-rate-control-10

[Ben Campbell <[e-mail]>]

Hi,

IETF Last Call ends today, and unless I missed something there has been no comments that require changes beyond those I made below. However, IDNits also complains about the reference in the abstract. Normally the RFC editor prefers to have no references in the abstract. Fixing this would mean simply removing “[RFC7683]” from the abstract.

This will probably end up on the IESG Telechat on 24 January. If you are able to make any updates this week it would be helpful. Otherwise please wait until after the telechat.

Thanks!

Ben.

> On Dec 21, 2018, at 5:06 PM, Ben Campbell <[e-mail]> wrote:
> 
> Hi,
> 
> 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.
> 
> Thanks!
> 
> Ben.
> 
> -------------------------------------
> 
> §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.
> 
>