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

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 19 Nov 2013 14:36:23 +0000

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. 

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. 

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

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

Nits/editorial comments:

---

From: Charles Shen <[email-masked]>
Date: Sun, 24 Nov 2013 15:52:32 +0800

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-masked]>wrote:

> 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.
>

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

> 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

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

---

From: Charles Shen <[email-masked]>
Date: Mon, 25 Nov 2013 17:05:36 +0800

Hi Dan,

On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) <[email-masked]>wrote:

> 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?
>

I see what you mean. In fact I tend to think of this as one of those
micro-aspects that have been covered by existing macro-clauses.
Specifically, as Section 5.3 says:

 Key to this is the fact that following initial
   subscription, the notifier sends a notification without a body if no
   load filtering policy is defined (Section 6.7
<http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-6.7>),
and that the
   subscription needs to be refreshed periodically to make it
   persistent, as described in Section 4.1
<http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-4.1>
and Section 4.2 of [RFC6665]
<http://tools.ietf.org/html/rfc6665#section-4.2>.

The behavior of notifier sending a notification following initial
subscription is mandated in Section 6.7 of this document. And the behavior
of periodic refresh is specified in Section 4.1 and Section 4.2 of RFC
6665.

Both this document and RFC 6665 have already been explicitly listed in
Section 4 of this document. So they seem to have covered the persistency
issue.

That said, I am open to add another explicit clause for this aspect if you
really feel strongly about it. Please let me know. Thanks again!

Charles

---

From: "charles newyork" <[email-masked]>
Date: Mon, 25 Nov 2013 01:39:44 -0800 (PST)

That's great, I will keep it as in the current 11 version then. Again thank you so much for the careful review!

Charles 

—
Sent from Mailbox for iPhone

On 周一, 11月 25, 2013 at 5:32 下午, Romascanu, Dan (Dan) <[email-masked]="mailto:[email-masked]">> wrote:

Hi Charles,

No, this is not a strong comment. Actually all my comments were listed as ‘minor’ thus non-blocking vs. a document I appreciate as of good quality. Thank you
 for the dialog and for considering my comments. 

Regards,

Dan

 

 

From: [email-masked] [mailto:[email-masked]]
On Behalf Of Charles Shen
Sent: Monday, November 25, 2013 11:06 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

Hi Dan,

On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:

 

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?

I see what you mean. In fact I tend to think of this as one of those micro-aspects that have been covered by existing macro-clauses. Specifically, as Section 5.3 says:

   load filtering policy is defined (Section 6.7), and that the

   persistent, as described in Section 4.1 and Section 4.2 of [RFC6665].

The behavior of notifier sending a notification following initial subscription is mandated in Section 6.7 of this document. And the behavior of periodic refresh is specified in Section 4.1 and Section 4.2 of RFC 6665. 

Both this document and RFC 6665 have already been explicitly listed in Section 4 of this document. So they seem to have covered the persistency issue.

That said, I am open to add another explicit clause for this aspect if you really feel strongly about it. Please let me know. Thanks again!

Charles

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 24 Nov 2013 17:09:19 +0000

Hi,

Thank you for addressing my comments. See in-line.

Regards,

Dan

From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Shen
Sent: Sunday, November 24, 2013 9:53 AM
To: Romascanu, Dan (Dan)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-ART review for draft-ietf-soc-load-control-event-package-10.txt

Dear Dan,

On Tue, Nov 19, 2013 at 10:36 PM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

Major issues: None.

Minor issues:

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.

 [[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?

Added.

Thanks!

Charles

Nits/editorial comments:

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 25 Nov 2013 09:32:01 +0000

Hi Charles,

No, this is not a strong comment. Actually all my comments were listed as ‘minor’ thus non-blocking vs. a document I appreciate as of good quality. Thank you for the dialog and for considering my comments.

Regards,

Dan

Hi Dan,

On Mon, Nov 25, 2013 at 1:09 AM, Romascanu, Dan (Dan) <[email-masked]<mailto:[email-masked]>> wrote:

   load filtering policy is defined (Section 6.7<http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-6.7>), and that the

   persistent, as described in Section 4.1<http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-11#section-4.1> and Section 4.2 of [RFC6665]<http://tools.ietf.org/html/rfc6665#section-4.2>.

Charles