Dear Dan, Thank you very much for your review. Please see inline.
On Tue, Nov 19, 2013 at 10:36 PM, Romascanu, Dan (Dan) <[email protected]>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: > > > > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
