A Session Initiation Protocol (SIP) Load-Control Event Package
RFC 7200

Note: This ballot was opened for revision 10 and is now closed.

(Richard Barnes) Yes

(Spencer Dawkins) Yes

Comment (2013-11-30 for -11)
No email
send info
I'm very pleased to see this work moving forward and find it of generally high quality (thank you).

I have some comments. Most are about clarity. None rise to the level of Discuss, but I'd appreciate it if you paid special attention to my comments on 6.8 and 7.4 (it took me three shots at the pseudocode to be fairly sure I was understanding the 7.4 text).

In this text: 6.8.  Subscriber Processing of NOTIFY Requests

   The subscriber SHOULD discard unknown bodies.  If the NOTIFY request
   contains several bodies, none of them being supported, it SHOULD
   unsubscribe.  A NOTIFY request without a body indicates that no load
   filtering policies need to be updated.

I may very well be confused, but I'm reading this as saying that a subscriber that gets NOTIFY bodies it doesn't understand is better off knowing nothing than staying subscribed on the off-chance that future NOTIFY bodies will make sense. Is that right?

That could very well be an appropriate response for most event packages, but a subscriber who unsubscribes from an overload control event package won't be enforcing filtering policies at all - is that the desired behavior?

I'm not understanding why this is a SHOULD, either, but let's ignore that for now.

In this text: 7.3.1.  Call Identity

   A URI identifying a SIP user, however, can also be a 'tel' URI.  We
   therefore need a similar way to match a group of 'tel' URIs.
   According to [RFC3966], there are two forms of 'tel' URIs for global
   numbers and local numbers, respectively.  All phone numbers must be
   expressed in global form when possible.  The global number 'tel' URIs
   start with a "+".  The rest of the numbers are expressed as local
   numbers, which must be qualified by a "phone-context" parameter.  The
   "phone-context" parameter may be labelled as a global number or any
   number of its leading digits, or a domain name.  Both forms of the
   'tel' URI make the resulting URI globally unique.

I don't understand why "must be expressed in global form where possible". I'm reading this paragraph as saying "the resulting URI MUST be globally unique, whether because the number itself was a global number or because the number was qualified using a phone-context parameter". Am I understanding this correctly?

I'll admit that the two lower-case "must"s make me uneasy ...

In this text: 7.4.  Actions

   o  The "drop" action means simply ignoring the request without doing
      anything, which can in certain cases help save processing
      capability during overload.  For example, when SIP is running over
      a reliable transport such as TCP, the "drop" action does not send
      out the rejection response, neither does it close the transport
      connection.  The "drop" action is generally also good at dealing
      with telephony DOS attacks.  However, when running SIP over an
      unreliable transport such as UDP, using the "drop" action will
      create message retransmissions that further worsen the possible
      overload situation.  Therefore, any "drop" action applied to an
      unreliable transport MUST be treated as if it were "reject".

I'm distracted by the offhand remark about telephony DOS attacks (is the point that attackers aren't going to respect rejects or redirects? If so, OK, but how do you know you're being telephony-DOSed?).

I'm reading the rest of this paragraph as 
   IF you can suggest another target
     THEN "redirect"
     ELSE IF unreliable-transport
        THEN treat "drop" as "reject"
        ELSE "drop"

Am I reading this correctly? Or is the point more nuanced?

In this text: 7.5.1.  Load Control Document Examples

   Sometimes it may occur that multiple rules in a ruleset define
   actions that match the same methods, call identity and validity.  In
   those cases, the "first-match-wins" principle is used.  For example,
   in the following ruleset, the first rule requires all calls from the
   "example.com" domain to be rejected.  Even though the rule following
   that one specifies that calls from "sip:alice@example.com" be
   redirected to a specific target "sip:eve@example.com", the calls from
   "sip:alice@example.com" will still be rejected because they have
   already been matched by the earlier rule.

would it be clearer to say 'the calls from "sip:alice@example.com" will not be redirected because they have already been matched by the earlier rule and rejected'? The current text reads as if you're still evaluating calls that have been matched by a previous rule, at least to me.

In this text: 10.  Discussion of this specification meeting the requirements of

      REQ 1: The overload mechanism shall strive to maintain the overall
      useful throughput (taking into consideration the quality-of-
      service needs of the using applications) of a SIP server at
      reasonable levels, even when the incoming load on the network is
      far in excess of its capacity.  The overall throughput under load
      is the ultimate measure of the value of an overload control

   P/A. The goal of the load filtering is to prevent overload or
   maintain overall goodput during the time of overload, but it is
   dependent on the advance predictions of the load.  If the predictions
   are incorrect, in either direction, the effectiveness of the
   mechanism will be affected.

I would agree with this assessment if the mechanism was only used to distribute policies based on predictions, but is this also true when reactive filtering policy distribution is taken into account? ("why isn't this 'Yes?")

Also in Section 10, there are five occurences of "N/A to the load control event package mechanism itself". This is quite terse. If I'm reading it correctly, it's saying "This requirement is N/A to the load control event package mechanism itself, but network elements can use the event package to fulfill this requirement". Is that what's intended? If so, I think you get at least partial credit ...

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

Comment (2013-12-03 for -11)
No email
send info
I take a position of no objection based on a quick scan which shows no impact on the routing system.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-12-05 for -12)
No email
send info
Putting Barry's hat for one minute (private IESG joke).

Anyway, my message is: Not sure a write-up like this is that useful.

(13) Yes

(14) No

(15) No

(16) No

Even if I've been reviewing a lot of write-ups in the last 2 years, I don't want to have to learn the questions by heart.

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2013-12-05 for -12)
No email
send info
Fully support Sean's discuss.

(Brian Haberman) No Objection

Barry Leiba (was Discuss) No Objection

Comment (2013-12-04)
No email
send info
Mostly, I'll let Spencer's review and comments stand here.  This document is as full of bloviation as I've come to expect from SIP documents: we really do need to fix that.  Take note of the quote from Antoine de Saint-Exupéry, "Il semble que la perfection soit atteinte non quand il n'y a plus rien à ajouter, mais quand il n'y a plus rien à retrancher."

The only other thing I'll note is that "MIME types" are now called "media types", and I'd appreciate it, though it's not a big deal, if the former could be globally changed to the latter.

(Pete Resnick) No Objection

Comment (2013-12-05 for -12)
No email
send info
I strongly agree with Barry. This entire document could use a huge editing pass to eliminate a lot of excess verbiage. I suspect there are 10 pages of actual useful spec here, and the rest could probably be cut in half, and perhaps put into appendices.

Here are some specific things that should be changed:

Throughout the document: IETF specifications do not use the "we" and "our" affectation from academic papers, because it's not clear to whom it refers (the authors of the document? the WG? the entire IETF?). Please change these "this document" or "this specification", or in some cases simply rewrite the sentence.

Section 1:
- Strike the first two paragraphs. Unnecessary.
- Third paragraph: The first sentence should reference RFC 6357, which discusses what "congestion collapse" means in the context of SIP. Change "these cases" to "cases of SIP server overload". Strike the last sentence of the paragraph. You can certainly shorten the rest.
- The fifth through seventh paragraphs should be compressed to a single short paragraph.
- I think you could drop the last paragraph. There is a table of contents.

I found none of the definitions in section 3 useful to my understand of the document. You reiterate the first 5 in section 5.1 in context, and fully explain the other two in context in 6.8 and 7.

Section 4 I would strike as non-useful.

Section 5.2: I don't understand what you mean by load filtering "computation". Do you simply mean "design" or "creation" of the load filtering policies? Since you've already said in the introduction that discussion of this is out of scope for the document, I don't understand why 5.2 is here.

Section 5.3:
- Strike the second and third sentence of the first paragraph. Unnecessary.
- Second paragraph: SHOULD is inappropriate. You're not making a protocol statement here. Also, "outgoing signaling neighbor" is a term that is only used in this section and is not necessary. There is a bunch of other unnecessary verbiage in this paragraph. I suggest:

   In order for load filtering polices to be properly distributed, each
   capable SIP entity in the netwok subscribes to the SIP load control
   event package of each SIP entity to which it sends signaling
   requests. A SIP entity that accepts subscription requests is called a
   notifier (Section 6.6).  Subscription is initiated and maintained
   during normal server operation. The subscription of neighboring SIP
   entities needs to be persistent, as described in Section 4.1 and
   Section 4.2 of [RFC6665]. The refresh procedure is describe in
   Section 6.7.  The subscribers can terminate the subscription after an
   extended period of absence of signaling message exchange, and can
   resubscribe if it determines that signaling  with the notifier
   becomes active again.

- The examples could be greatly simplified in language.

Sections 7.5, 9, and 10 should be moved to appendices and could be greatly shortened. I would simply strike section 10.

(Martin Stiemerling) No Objection

(Sean Turner) (was Discuss) No Objection