(1) Proposed Standard

(2) Technical Summary:

The document defines an event package for the Session Initiation Protocol (SIP) to prevent signaling overload. The load event package complements feedback-based SIP overload control mechanisms. It allows SIP entities to distribute filtering policies to other SIP entities in the network. These policies contain rules to throttle requests based on their source or destination domain, telephone number prefix or for a specific user.

Working Group Summary:
This draft complements the feedback-based SIP overload control mechanism for cases of known short-term overload (e.g., calls to a game show). This mechanism was developed in parallel to feedback-based SIP overload control and was adopted by the working group without contention. There was no competing proposal to address the WG deliverable 'A specification for a SIP load filtering mechanism.'.

Document Quality:
The specification has been implemented and evaluated in a simulator by the main author at Columbia University. NTT strongly supports the mechanism and co-authors the specification. France Telecom Orange has indicated that they want to use this spec as a basis for a 3GPP spec. The draft was first submitted to the SIPPING WG in 2008 and moved to SOC in 2010. It has been reviewed thoroughly by several members of the SOC WG including Bruno Chatras, Janet Gunn, Shida Schubert, Phil Williams, and Adam Roach.

Personnel:
Shepherd: Volker Hilt
AD: Robert Sparks

(3) The document was reviewed several times during its lifecycle by the shepherd.

(4) No concerns on the reviews performed.

(5) No additional review needed.

(6) No concerns.

(7) Yes.

(8) No.

(9) A significant number of WG members were involved in the discussion of the document over time and it can be expected that the majority of the WG understands and agrees with the document.

(10) No

(11) No nits.

(12) This specification registers a SIP event package, a new MIME type, a new XML namespace, and a new XML schema. Since this is an IETF-stream standards-track document, none of these need additional formal review.

(13) Yes

(14) No

(15) No

(16) No

(17) All protocol extensions that the document makes are associated with the appropriate reservations in IANA registries and the IANA considerations section is clear.

(18) No IANA registries are created.

(19) XML has been validated with http://www.xmlvalidation.com/ and http://www.w3schools.com/xml/xml_validator.asp