[Dime] Opsdir last call review of draft-ietf-dime-doic-rate-control-10

Susan Hares <shares@ndzh.com> Mon, 21 January 2019 21:03 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: dime@ietf.org
Delivered-To: dime@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C9B1288BD; Mon, 21 Jan 2019 13:03:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Susan Hares <shares@ndzh.com>
To: ops-dir@ietf.org
Cc: dime@ietf.org, draft-ietf-dime-doic-rate-control.all@ietf.org, ietf@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154810458138.8188.8411786024206076306@ietfa.amsl.com>
Date: Mon, 21 Jan 2019 13:03:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/lGDDLg916QUpDJmik33gg4qlkC4>
Subject: [Dime] Opsdir last call review of draft-ietf-dime-doic-rate-control-10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jan 2019 21:03:02 -0000

Reviewer: Susan Hares
Review result: Ready

Steve and Eric:

I have reveiwed this document as part of the  operational directorate (ops-dir)
ongoing effort to review all IETF documents being process by the IESG for
operational aspects.  These comments are to aid the authors and the NM/OPS Area
Directors.  The document editors and the WG chairs hsould treat these comments
as any other last call comments.

Status: ready,  with  2 operator questions and 1 yang question.  The question
are just things to think about for the authors and ADS.


The documentis readable and aligns with RFC7683 and
draft-ietf-dime-agent-overload.     The language in this document also aligns
with language in the SIP Overload Control (SOC) document [RFC7415].

As I am not familar with current DIAMETER deployments, i've got a few
operational questions for the authors to consider:

1)  If a operator where deploying this new algorithm,
   what type of deployment considerations would
    be necessary?   Should certain topologies
    of Diameter deployments utilize certain
   overload algorithms?

 2) What failure modes will the operator see
   in the current overload abatement that
   would encourage the operator to
   spend the effort to go to this new DOIC
   rate limit?

As a researcher and implementer, sections 1 and  7 were sufficient
to answer these questions.   However,  I would ask the authors,
WG chairs, and OPS/NM ADs to determine if these are sufficient
for the normal operators.

Question 3:  Just for my own understanding,
is there a plan to control DIAMETER protocols with YANG