Re: [sip-overload] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

Charles Shen <qs2005@columbia.edu> Sun, 24 November 2013 07:53 UTC

Return-Path: <charles.newyork@gmail.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 073991AE017; Sat, 23 Nov 2013 23:53:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.277
X-Spam-Level:
X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 P2xe_pw5wjYn; Sat, 23 Nov 2013 23:53:02 -0800 (PST)
Received: from mail-ob0-x231.google.com (mail-ob0-x231.google.com [IPv6:2607:f8b0:4003:c01::231]) by ietfa.amsl.com (Postfix) with ESMTP id 80E3F1AE0BC; Sat, 23 Nov 2013 23:53:00 -0800 (PST)
Received: by mail-ob0-f177.google.com with SMTP id va2so2971224obc.22 for <multiple recipients>; Sat, 23 Nov 2013 23:52:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=1Mf59/9Dz1rdKoYjKZNzTlWKgncUhRke+MZ5ElvCpa4=; b=JD3a7wlItvz+WeIWhtFFxNGuiglisafiKC+46L5YVyRuvbJKhuSjBc9XZdePD781tO ii5bK4c4Su6BWwdPLm+9FPDBNlTQ5G4oYSmyomqenHXeNy9o63tpBKRFpqWkfBn7kLxd AN9rirplKLjExgvnCu46ofYgTce9GDcEgRlj6hYqUN+XREt36Oj8WzT03C9FxD1WRZ9I oFZZKR85oYbqXFbljMFfcols7AtsWru3kDxI3w6224n/TIzoMgirWWk9C+vYpOktapC+ Hcv9OkRBXTRviXDyeI24b7+OR1lz1+dFGqvlkOY6EjIAtMP/hYg8/2QlWkGGXDQzvyvN /suA==
X-Received: by 10.60.40.5 with SMTP id t5mr19018907oek.26.1385279572692; Sat, 23 Nov 2013 23:52:52 -0800 (PST)
MIME-Version: 1.0
Sender: charles.newyork@gmail.com
Received: by 10.182.27.9 with HTTP; Sat, 23 Nov 2013 23:52:32 -0800 (PST)
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA12941662@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA12941662@AZ-FFEXMB04.global.avaya.com>
From: Charles Shen <qs2005@columbia.edu>
Date: Sun, 24 Nov 2013 15:52:32 +0800
X-Google-Sender-Auth: 8FA5q0cHEMh8FhC8dKEcaQ13PuI
Message-ID: <CAPSQ9ZXkEBd5JJu-mt08+StkPY5R4KfYwsqcWS35AFSLLxaFXw@mail.gmail.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
Content-Type: multipart/alternative; boundary=089e013cc2b2d855ac04ebe788b0
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "sip-overload@ietf.org" <sip-overload@ietf.org>, "draft-ietf-soc-load-control-event-package.all@tools.ietf.org" <draft-ietf-soc-load-control-event-package.all@tools.ietf.org>
Subject: Re: [sip-overload] Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload/>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2013 07:53:04 -0000

Dear Dan,

Thank you very much for your review. Please see inline.


On Tue, Nov 19, 2013 at 10:36 PM, Romascanu, Dan (Dan)
<dromasca@avaya.com>wrote:

>
> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>;.
>
> Please resolve these comments along with any other Last Call comments you
> may receive.
>
> Document: draft-ietf-soc-load-control-event-package-10.txt
> Reviewer: Dan Romascanu
> Review Date: 11/19/13
> IETF LC End Date: 11/19/13
> IESG Telechat date: (if known)
>
> Summary: The document is ready, there are a few minor issues which are
> worth being clarified.
>
> Major issues: None.
>
> Minor issues:
>
> 1. I had some issues with the examples in the introduction.
>
> >  There are three common examples of legitimate short-term increases in
>    call volumes.  Viewer-voting TV shows or ticket giveaways may
>    generate millions of calls within a few minutes.  Call volume may
>    also spike during special holidays such as New Year's Day and
>    Mother's Day. Finally, callers may want to reach friends and family
>    in natural disaster areas such as those affected by hurricanes.  When
>    possible, only calls traversing overloaded servers should be
>    throttled under those conditions.
>
> I am not sure what the term 'legitimate' means here. I would rather say
> that the paragraph rather deals with increases in call volumes that happen
> at predictable moments in time (assuming here that the time a hurricane
> hits a certain geographic zone is predicted by weather forecasters). There
> would be one more example to add here - the end-of-season (of month, of
> year) peaks in phone orders.
>
> There is another category of unpredicted/unpredictable events which is
> mentioned a few paragraphs later, and which puts a slightly different set
> of requirements. The list already includes earthquakes or terrorist
> attacks, it may add the increase in traffic on call centers that provide
> troubleshooting services when a mass service fails.
>
> A slight re-organization of this text would improve clarity.
>


I have re-organized the contents a bit around the direction you suggested,
please let me know if that solves the clarity issue.


>
> 2. In Section 4 - Design Requirements:
>
>   o  The solution should draw upon experiences from related PSTN
>       mechanisms where applicable.
>
> I have no clue what this section means in the absence of a reference
> and/or a list of what PSTN mechanisms are to be considered.
>

The references have been added.


>
> Also, in the same list of requirements I miss an explicit requirement on
> persistency.
>


This part I am not sure if I understand clearly, could you please elaborate
a bit?



>
> 3. In Section 5.4 in the compliance list - I believe that compliance to
> the SIP Event Notification Framework [RFC 6665] should be added.
>


Added.


Thanks!

Charles

>
> Nits/editorial comments:
>
>
>
>
>