Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
 by ietfa.amsl.com (Postfix) with ESMTP id 3EEE21311F9
 for <dime@ietfa.amsl.com>; Thu, 24 Jan 2019 15:42:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.119
X-Spam-Level: 
X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
 SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001]
 autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44])
 by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 9-thXfw8xdrI for <dime@ietfa.amsl.com>;
 Thu, 24 Jan 2019 15:42:15 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com
 [173.247.247.114])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id DDC32131215
 for <dime@ietf.org>; Thu, 24 Jan 2019 15:42:15 -0800 (PST)
Received: from [97.99.21.33] (port=54784 helo=SDmac.lan)
 by biz131.inmotionhosting.com with esmtpsa
 (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91)
 (envelope-from <srdonovan@usdonovans.com>) id 1gmodI-00Ahd2-Co
 for dime@ietf.org; Thu, 24 Jan 2019 15:42:15 -0800
To: dime@ietf.org
References: <154810458138.8188.8411786024206076306@ietfa.amsl.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <71b3d38a-ac90-8ac7-0aa3-8a6c83d37534@usdonovans.com>
Date: Thu, 24 Jan 2019 17:42:03 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0)
 Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <154810458138.8188.8411786024206076306@ietfa.amsl.com>
Content-Type: multipart/alternative;
 boundary="------------0EB645FECEC4AC41C06D9EEC"
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse,
 please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id:
 srdonovan@usdonovans.com
X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/I2_hQndIqd2K7fzgXATxBAoi-RQ>
Subject: Re: [Dime] Opsdir last call review of
 draft-ietf-dime-doic-rate-control-10
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 24 Jan 2019 23:42:17 -0000

This is a multi-part message in MIME format.
--------------0EB645FECEC4AC41C06D9EEC
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

Susan,

Thank you for your review and comments.

Please see my responses inline.

Regards,

Steve

On 1/21/19 3:03 PM, Susan Hares wrote:
> 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.
>
> Questions:
>
> 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.
SRD> We had multiple operators involved in the development of this
draft, in fact, one of the authors works for an operator.  As such, I'm
confident that their concerns have been addressed.
>
> Question 3:  Just for my own understanding,
> is there a plan to control DIAMETER protocols with YANG
> modules?
SRD> Not to my knowledge.
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www.ietf.org/mailman/listinfo/dime


--------------0EB645FECEC4AC41C06D9EEC
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <font face="Times New Roman, Times, serif">Susan,<br>
      <br>
      Thank you for your review and comments.<br>
      <br>
      Please see my responses inline.<br>
      <br>
      Regards,<br>
      <br>
      Steve<br>
    </font><br>
    <div class="moz-cite-prefix">On 1/21/19 3:03 PM, Susan Hares wrote:<br>
    </div>
    <blockquote
      cite="mid:154810458138.8188.8411786024206076306@ietfa.amsl.com"
      type="cite">
      <pre wrap="">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.

Questions:

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.</pre>
    </blockquote>
    SRD&gt; We had multiple operators involved in the development of
    this draft, in fact, one of the authors works for an operator.  As
    such, I'm confident that their concerns have been addressed.<br>
    <blockquote
      cite="mid:154810458138.8188.8411786024206076306@ietfa.amsl.com"
      type="cite">
      <pre wrap="">

Question 3:  Just for my own understanding,
is there a plan to control DIAMETER protocols with YANG
modules?</pre>
    </blockquote>
    SRD&gt; Not to my knowledge.<br>
    <blockquote
      cite="mid:154810458138.8188.8411786024206076306@ietfa.amsl.com"
      type="cite">
      <pre wrap="">


_______________________________________________
DiME mailing list
<a class="moz-txt-link-abbreviated" href="mailto:DiME@ietf.org">DiME@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www.ietf.org/mailman/listinfo/dime">https://www.ietf.org/mailman/listinfo/dime</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>

--------------0EB645FECEC4AC41C06D9EEC--

