Subject: [sip-overload] Review of draft-ietf-soc-load-control-event-package-05

From: "Vijay K. Gurbani" <[email-masked]>
Date: Sat, 15 Dec 2012 13:27:49 -0600

Dear Charles: I read the -05 version of draft-ietf-soc-load-control-
event-package.  My review is below.  Thank you.

The document is well written and ready to be moved ahead.  I do have a
couple of comments from reading the document.

First, as a general comment, the draft states at various places that
a subscription or notification can include an empty message body.
However, an empty body can be a body with 0 octets.  On the other hand,
an empty message body could contain some XML markings that are
essentially a no-op, something like this:

<?xml version="1.0" encoding="UTF-8"?>
    <ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
                xmlns:lc="urn:ietf:params:xml:ns:load-control"
                version="0" state="full">
    </ruleset>

Which one of these did you mean?  I suspect that when you say an empty
body you probably mean a body with 0 octets.  But just the same it will
be good to make this explicit.

Second, I am not sure what the second to last paragraph ("A SUBSCRIBE
request... are not yet defined.") in Section 5.3 means.  Isn't what
this draft is specifying a filter to throttle requests?  Or am I
missing something?

And finally, Keith had opened up a thread [1] on the list on
harmonizing overload and emergency handling in this draft as well as
draft-ietf-soc-overload-control.  I need to put the text agreed to on
the list in draft-ietf-soc-overload-control as well.  The final text
was suggested by Janet in [2], which is what I will end up inserting in
the draft-ietf-soc-overload-control.

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00848.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00849.html

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Charles Shen <[email-masked]>
Date: Sun, 16 Dec 2012 00:27:01 -0500

Dear Vijay, Thanks for your comments! please see inline.

On Sat, Dec 15, 2012 at 2:27 PM, Vijay K. Gurbani <[email-masked]> wrote:

>    <ruleset xmlns="urn:ietf:params:xml:ns:**common-policy"
>                xmlns:lc="urn:ietf:params:xml:**ns:load-control"

Yes, I meant a body with 0 octets, and I will make it explicit.

> this draft is specifying a filter to throttle requests?  Or am I
No, this might be a confusion caused by the overloaded use of the word
"filter". The SUBSCRIBE has an Accept header (application/load-control+xml)
indicating it is accepting the load control document specifying *load
filters* as defined in this document. The SUBSCRIBE body could be used to
refine its subscription, e.g., only to a subset of *load
filters* (therefore is a filtering of the subscription itself). If I have
to come up with some examples, maybe it could say something like "only
subscribe to   *load filters* for hurricane load spike". But we are not
getting into those perspectives (nor do I think we need to). Therefore, the
sentence just states a possibility that we are not using right now. I can
clarify a bit if needed.

> draft-ietf-soc-overload-**control.  I need to put the text agreed to on
> the list in draft-ietf-soc-overload-**control as well.  The final text
> the draft-ietf-soc-overload-**control.
>
> [1] http://www.ietf.org/mail-**archive/web/sip-overload/**
> current/msg00848.html<http://www.ietf.org/mail-archive/web/sip-overload/current/msg00848.html>
> [2] http://www.ietf.org/mail-**archive/web/sip-overload/**
> current/msg00849.html<http://www.ietf.org/mail-archive/web/sip-overload/current/msg00849.html>
>
>
I will do. Thanks!

Charles

> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.**com<[email-masked]>
> Web:   http://ect.bell-labs.com/who/**vkg/<http://ect.bell-labs.com/who/vkg/>
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 17 Dec 2012 14:38:32 -0600

Charles: Please see inline.

On 12/15/2012 11:27 PM, Charles Shen wrote:
> "filter". The SUBSCRIBE has an Accept header
> (application/load-control+xml) indicating it is accepting the load
> control document specifying *load filters* as defined in this document.
> The SUBSCRIBE body could be used to refine its subscription, e.g., only
> to a subset of *load filters* (therefore is a filtering of the
> subscription itself). If I have to come up with some examples, maybe it
> could say something like "only subscribe to   *load filters* for
> hurricane load spike". But we are not getting into those perspectives
> (nor do I think we need to). Therefore, the sentence just states a
> possibility that we are not using right now. I can clarify a bit if needed.

I believe that S5.4.3 of rfc6665 concerns itself with asking designers
of event control packages to define what type of event bodies are
expected in SUBS/NOT requests.  The expectation, further, is that
"these bodies will typically modify, expand, filter, throttle, and/or
set thresholds for the class of events being requested."

My interpretation of S5.4.3 of rfc6665 is that if I have a media type
(and subtype) associated with my event package and that media type
allows events further parameterized by parameters "bar" or "foo" (i.e.,
I can filter events based on "bar" and "foo" and the resulting document
upon changing the discriminator is distinct from before), I do not need
to list these discrimination criteria.  The media type remains the same.

Taking this further to your case, it does not matter whether you want
to subscribe to load filters for a hurricane load spike or you want
to subscribe to load filters for a mother's day load spike, your
media type still remains "application/load-control+xml".

Based on my understanding, you can remove the second paragraph in
Section 5.3 of your document without any loss of generality.  It's
appearance in the document now just adds to ambiguity (where, at least
I can see, none exists).

Thanks,

- vijay

---

From: Charles Shen <[email-masked]>
Date: Tue, 18 Dec 2012 13:31:24 -0500

Hi Vijay, I am fine with what you propose. Thanks!

Charles

On Mon, Dec 17, 2012 at 3:38 PM, Vijay K. Gurbani <[email-masked]> wrote:

> media type still remains "application/load-control+xml"**.
>