Subject: [sip-overload] remind: WGLC: draft-ietf-soc-load-control-event-package

From: Salvatore Loreto <[email-masked]>
Date: Fri, 7 Dec 2012 09:16:43 +0200

this is a remind

we are running a second WGLC for the load-control-event-package

please read the last version of the document and provide your view on it
(e.g. the draft is ready to move on, etc) or eventual feedback you have.

thanks
Salvatore

On 11/29/12 3:21 PM, Salvatore Loreto wrote:
> [as chair]
>
> due to the comments and feedback received during the first one [1],
> we have decided to run a second WGLC on the updated version of the draft:
> http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-05
>
> Today we are starting another two-weeks working group last call.
> This call ends on Thursday, December 13th.
>
> reviews and comments are really appreciate and requested from all the 
> participants cheers
>
>
> Volker and Salvatore
>
> [1]http://www.ietf.org/mail-archive/web/sip-overload/current/msg00799.html 
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>
>

---

From: Shida Schubert <[email-masked]>
Date: Sat, 8 Dec 2012 16:02:51 +0900

I think overall, the draft is looking good and will be ready 
after adding some clarifying text and using consistency 
terminology through out the draft. 

 My comments below

** Technical ******

1. Section 5.8.
 - The second paragraph talks about enforcing rules  even 
   when re-activation of subscription fails.. There is a chance 
   that event was cancelled or no longer valid, do we still 
   want to enforce this event then?? I guess it's better to be 
   safe (be overreactive to prohibit the chance of overload).. 

2. Section 5.8. 
 - 5th paragraph talks about NOTIFY body containing no supporting 
   bodies, but in section 5.5 is clearly mandating the inclusion of 
   at least "application/load-control_xml" in NOTIFY . So there seems 
   to be a bit of contradiction here..

3. Section 5.11
 - 2nd paragraph mentions the need to keep track of the version 
  number, when subscriber has missed receiving a version. But 
  why is this necessary when it is mentioned that subscriber asks 
  for a full snapshot of the state (filters).. Also these statements 
  seem like they should be written with the RFC2119 language. 

4. Section 6.4 
  - 2nd paragraph has normative statement about "reject", "drop" 
  I am assuming that these are normative statements for the 
  subscriber (servers that installs filter) to follow, but this is not 
  clarified.. I suggest you clarify who takes these actions a bit 
  more explicitly..

** Editorial ******

1. Design Requirements 
 - Bullet 5 
   The target should include domain as destination domain is 
    mentioned as a target in the section 4.1..

2. Terminology

 Terminology is still rather confusing are the followings terms 
same or not? If they are same, I think same terminology should 
be used. 
 
 I think terminology section may help with this, but never the 
less I encourage the use of consistent terminology across the 
document. 

 Are the following terms all the same? 
    load filter === load filtering rules, load filtering policy(ies), filter

 What is dynamically computed filter, are they different in the 
sense that they are not installed via this spec? (section 4.3)
 
  What is the difference between load control rules and load control 
filter and load control policy? 

 What is load control notification? Isn't this just a notification with 
filter as a body?

 What is a filtering server? I am assuming it is a server that 
receives a notification (subscriber) with filter which installs filter 
and executes policy/rules inside the filter.. But this is not clearly 
specified but rather left up to the reader.. 

3 Term control policy is not really explained but I am assuming 
it is the control you achieve by entity receiving the filter, actually 
installing the filter. If this is the case, section 5.3 should simply 
say 

 "The effectiveness of SIP load filtering relies on the scope of 
distribution and installation of the load filters in the network" 

 Latter paragraph uses the control policies, as well and should 
be replaced with load filtering. 

 Other editorial nits, I will send to the authors directly.

 Regards
  Shida

On Dec 7, 2012, at 4:16 PM, Salvatore Loreto wrote:

>> reviews and comments are really appreciate and requested from all the participants cheers
>> 
>> 
>> Volker and Salvatore
>>

---

From: Charles Shen <[email-masked]>
Date: Sun, 9 Dec 2012 11:35:42 -0500

Hi Shida, thank you very much for your comments! please see inline:

>    safe (be overreactive to prohibit the chance of overload)..
The current text says:

 Regardless of whether
   this re-activation of subscription is successful or not, when the
   validity time is reached, the subscriber SHOULD enforce the
   corresponding rules.

This is a conservative approach (even if the event has been cancelled, if
we do not receive a cancellation, the rule should still be enforced) seems
to be inline with your "safe/over-reactive" suggestion, or did I get it
wrong?

>    to be a bit of contradiction here..
In normal cases, the subscriber should not receive unknown bodies, so the
wording about no supporting bodies is more concerning error conditions. Do
you want to make it more explicit, saying e.g., "in unexpected cases, when
the subscriber receives unknown bodies ..." ?

>   seem like they should be written with the RFC2119 language.
Using the version number, the subscriber knows whether it misses any delta
update or not. It needs to ask for a full snapshot of the state *only* when
it finds out that it had missed some previous delta update (so it could not
reconstruct the full current state solely based on the delta updates it
has). This paragraph is referencing RFC6665 (
http://tools.ietf.org/html/rfc6665#section-5.3.2), so I can add a "MUST" to
the "include a version number that ..." part.

>   clarified.. I suggest you clarify who takes these actions a bit

Will do.

>     mentioned as a target in the section 4.1..
ok.

>     load filter === load filtering rules, load filtering policy(ies),

To me load filter / filter can have a physical sense while policy/rules
have a more abstract meaning. Rules/Policies are installed in filters. For
example, you can have a filter initiated with no rules, or configured with
rule set A, then changed to rule set B, it is the same filter but with
different rules.

Another interpretation may regard filter and filter rules the same thing,
in that a filter on the same entity but with different rules are viewed as
different filters, if that makes more sense to the group, I can consider
clarification on that too.

> sense that they are not installed via this spec? (section 4.3)
Meaning the filtering contents are dynamically computed based on current
network status. It is more about the computation of the filter, not about
installation.

> filter and load control policy?
I did not find "load control filter" in this version,  (it should have been
removed after your earlier comments about terminology). Also S1 second last
paragraph has a sentence:

 since we are describing a specific control
   mechanism based on filtering, the term "load control" in this
   specification is used inter-changeably with the term "load filtering"
   unless associated with other explicit context.

I am also using "policies" and "rules" inter-changeably in the document,
but I can consolidate both into "rules" (or "policies") if that's clearer.

>  What is load control notification? Isn't this just a notification with
Yes it is. It occurred twice in the document so I can change them to just
NOTIFY request to match the rest of the document.

> specified but rather left up to the reader..
OK, I will make it explicit.

> be replaced with load filtering.
Sure, will correct.

>  Other editorial nits, I will send to the authors directly.
Got them, thanks!

Charles

> >> [1]
> http://www.ietf.org/mail-archive/web/sip-overload/current/msg00799.html

---

From: Shida Schubert <[email-masked]>
Date: Mon, 10 Dec 2012 02:17:16 +0900

Hi Charles;

 My comments inline..

On Dec 10, 2012, at 1:35 AM, Charles Shen wrote:

> This is a conservative approach (even if the event has been cancelled, if we do not receive a cancellation, the rule should still be enforced) seems to be inline with your "safe/over-reactive" suggestion, or did I get it wrong? 

 Sounds good. Just wanted to confirm.

> In normal cases, the subscriber should not receive unknown bodies, so the wording about no supporting bodies is more concerning error conditions. Do you want to make it more explicit, saying e.g., "in unexpected cases, when the subscriber receives unknown bodies ..." ?

 May be good to be more explicit but current text is fine as is, as it really tries to prevent things from breaking..

> Using the version number, the subscriber knows whether it misses any delta update or not. It needs to ask for a full snapshot of the state *only* when it finds out that it had missed some previous delta update (so it could not reconstruct the full current state solely based on the delta updates it has). This paragraph is referencing RFC6665 (http://tools.ietf.org/html/rfc6665#section-5.3.2), so I can add a "MUST" to the "include a version number that ..." part. 
>  

 I guess it was rather confusing because it read like you only keep 
track of versioning number in case you miss a version.. I think 
what you mentioned above somehow SHOULD be mentioned. 

 Something along the line of 

 1. MUST keep track of versioning number.
 2. If there is a miss then ask for full snapshot.

>   clarified.. I suggest you clarify who takes these actions a bit

 OK.

> To me load filter / filter can have a physical sense while policy/rules have a more abstract meaning. Rules/Policies are installed in filters. For example, you can have a filter initiated with no rules, or configured with rule set A, then changed to rule set B, it is the same filter but with different rules. 
> 
> Another interpretation may regard filter and filter rules the same thing, in that a filter on the same entity but with different rules are viewed as different filters, if that makes more sense to the group, I can consider clarification on that too. 

 Okay, so I think it would be good to add a terminology section to 
lay out your interpretation of each of the terminology used. 
 
 Reader will not know what you mean by each of the terminology 
and it will be left to the read as to how one interprets each term..

 Your response looks good, I highly suggests that you add a 
terminology section.. 

 Thanks
  Shida

> Meaning the filtering contents are dynamically computed based on current network status. It is more about the computation of the filter, not about installation. 
>  
> I did not find "load control filter" in this version,  (it should have been removed after your earlier comments about terminology). Also S1 second last paragraph has a sentence: 
> 
> I am also using "policies" and "rules" inter-changeably in the document, but I can consolidate both into "rules" (or "policies") if that's clearer. 
>  
> Yes it is. It occurred twice in the document so I can change them to just NOTIFY request to match the rest of the document.
> 
>

---

From: Charles Shen <[email-masked]>
Date: Sun, 9 Dec 2012 12:33:21 -0500

Hi Shida, in that case, I will try to add a terminology section. Thanks!

Charles

On Sun, Dec 9, 2012 at 12:17 PM, Shida Schubert <[email-masked]> wrote:

>  May be good to be more explicit but current text is fine as is, as it
> really tries to prevent things from breaking..
>
>
>
>> 3. Section 5.11
> http://tools.ietf.org/html/rfc6665#section-5.3.2), so I can add a "MUST"
> to the "include a version number that ..." part.
>
>
>
> I did not find "load control filter" in this version,  (it should have
> been removed after your earlier comments about terminology). Also S1 second
> last paragraph has a sentence:
>