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

Ben Campbell <> Wed, 16 January 2019 18:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54086124BE5; Wed, 16 Jan 2019 10:09:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id siaQ4J1v9y71; Wed, 16 Jan 2019 10:09:20 -0800 (PST)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34192124BAA; Wed, 16 Jan 2019 10:09:20 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x0GI9HCp078067 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 16 Jan 2019 12:09:18 -0600 (CST) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1547662158; bh=LudrXC/vTaH8tDC1LXXDEksgAtaAVR6RqerlUjbtgHg=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=QB9ssKmvAS30W/kOdOC0hwpzM9b/Y+nkDIaJUpkU5YI06d2q5mPzkRlHscpKZAggd qCnfnD4WLzwfVikxeSyROhTaGwkwnsEnptyWDPtT2iVFRFKqK6tFf2m5e8N46XWIbz rCFLWeRYUBHBh3+ZyFepbi1xBO6+6nwlrYHwIH+0=
X-Authentication-Warning: Host [] claimed to be []
From: Ben Campbell <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_08389655-C2E1-42A7-951E-81DCD8A83D64"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Wed, 16 Jan 2019 12:09:17 -0600
In-Reply-To: <>
References: <>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <>
Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-doic-rate-control-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 16 Jan 2019 18:09:22 -0000


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.



> On Dec 21, 2018, at 5:06 PM, Ben Campbell <> 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.