A Session Initiation Protocol (SIP) Load-Control Event Package
draft-ietf-soc-load-control-event-package-13

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
     RFC5390

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

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