Hi, Thank you for addressing my comments. See in-line.
Regards, Dan From: [email protected] [mailto:[email protected]] On Behalf Of Charles Shen Sent: Sunday, November 24, 2013 9:53 AM To: Romascanu, Dan (Dan) Cc: [email protected]; [email protected]; [email protected] Subject: Re: Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt 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]<mailto:[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. [[DR]] The re-organized text in draft-11 looks fine. 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? [[DR]] In section 5.3, second paragraph there are a couple of references to the persistency of subscriptions of neighboring SIP entities and periodic refresh. Should not this be mentioned explicitly in the list in Section 4? 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
