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

[Charles Shen <[e-mail]>]

Dear Dan,

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


On Tue, Nov 19, 2013 at 10:36 PM, Romascanu, Dan (Dan)
<[e-mail]>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:
>
>
>
>
>