Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2014-04-30
13 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2014-03-31
13 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2014-03-07
13 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2014-02-03
13 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2014-02-03
13 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2014-02-03
13 (System) IANA Action state changed to Waiting on Authors from In Progress
2014-02-02
13 Gunter Van de Velde Request for Telechat review by OPSDIR Completed. Reviewer: Benoit Claise.
2014-02-02
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Benoit Claise
2014-02-02
13 Gunter Van de Velde Request for Telechat review by OPSDIR is assigned to Benoit Claise
2014-01-23
13 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent
2014-01-23
13 (System) RFC Editor state changed to EDIT
2014-01-23
13 (System) Announcement was received by RFC Editor
2014-01-23
13 (System) IANA Action state changed to In Progress
2014-01-23
13 Amy Vezza State changed to Approved-announcement sent from IESG Evaluation::AD Followup
2014-01-23
13 Amy Vezza IESG has approved the document
2014-01-23
13 Amy Vezza Closed "Approve" ballot
2014-01-23
13 Amy Vezza Ballot approval text was generated
2014-01-23
13 Amy Vezza Ballot writeup was changed
2014-01-23
13 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2014-01-23
13 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2013-12-18
13 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2013-12-14
13 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-12-14
13 Charles Shen IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2013-12-14
13 Charles Shen New version available: draft-ietf-soc-load-control-event-package-13.txt
2013-12-05
12 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-12-05
12 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake.
2013-12-05
12 Cindy Morgan [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo by Cindy Morgan
2013-12-05
12 Richard Barnes
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? …
(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

- Proposed Standard

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up.

- 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) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

- The document was reviewed several times during its lifecycle by the shepherd.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

-  No concerns on the reviews performed.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

- No additional review needed.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

- No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

- Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

- No.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

-  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) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

- No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

-  No nits.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.

- 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) Have all references within this document been identified as either normative or informative?

- Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

- No

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

- No

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

- No

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).

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

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

- No IANA registries are created.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.

- XML has been validated with http://www.xmlvalidation.com/ and http://www.w3schools.com/xml/xml_validator.asp
2013-12-05
12 Pete Resnick
[Ballot comment]
I strongly agree with Barry. This entire document could use a huge editing pass to eliminate a lot of excess verbiage. I suspect …
[Ballot comment]
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.
2013-12-05
12 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2013-12-05
12 Stephen Farrell [Ballot comment]

Fully support Sean's discuss.
2013-12-05
12 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2013-12-05
12 Sean Turner
[Ballot discuss]
0) I don't believe the 1st bullet is complete:

  o  The mechanisms used to secure the communication among SIP entities
    …
[Ballot discuss]
0) I don't believe the 1st bullet is complete:

  o  The mechanisms used to secure the communication among SIP entities
      within the Trust Domain.

Shouldn't it be "There is a mechanism to secure the communication ...  and it is [insert protocol here]".

1) I get that the components in the Trust Domain need to be compliant with RFC 3261.  I know there's text in there about user-to-user and user-to-proxy security.  Where is the text about proxy-to-proxy security?
2013-12-05
12 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded for Sean Turner
2013-12-05
12 Benoît Claise
[Ballot comment]
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) …
[Ballot comment]
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.
2013-12-05
12 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2013-12-04
12 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed
2013-12-04
12 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-12-04
12 Barry Leiba
[Ballot discuss]
The media type registration in Section 12.2 cites RFC 6838, yet does not use the template from 6838 -- in fact, it …
[Ballot discuss]
The media type registration in Section 12.2 cites RFC 6838, yet does not use the template from 6838 -- in fact, it doesn't even use the one from RFC 4288, staying with the one from RFC 2048, which has been obsolete since 2005.  Please update the template (and see the note in the comment about the term "MIME type").
2013-12-04
12 Barry Leiba
[Ballot comment]
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 …
[Ballot comment]
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.
2013-12-04
12 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2013-12-04
12 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-12-04
12 Charles Shen New version available: draft-ietf-soc-load-control-event-package-12.txt
2013-12-03
11 Dan Romascanu Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu.
2013-12-03
11 Stewart Bryant [Ballot comment]
I take a position of no objection based on a quick scan which shows no impact on the routing system.
2013-12-03
11 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-12-02
11 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-12-02
11 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-11-30
11 Spencer Dawkins
[Ballot comment]
I'm very pleased to see this work moving forward and find it of generally high quality (thank you).

I have some comments. Most …
[Ballot comment]
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 ...
2013-11-30
11 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2013-11-27
11 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2013-11-27
11 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2013-11-24
11 Charles Shen New version available: draft-ietf-soc-load-control-event-package-11.txt
2013-11-22
10 Richard Barnes Placed on agenda for telechat - 2013-12-05
2013-11-22
10 Richard Barnes State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-11-22
10 Richard Barnes Ballot has been issued
2013-11-22
10 Richard Barnes [Ballot Position Update] New position, Yes, has been recorded for Richard Barnes
2013-11-22
10 Richard Barnes Created "Approve" ballot
2013-11-22
10 Richard Barnes Ballot writeup was changed
2013-11-22
10 Richard Barnes
(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 …
(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
2013-11-20
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2013-11-20
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Jouni Korhonen
2013-11-20
10 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Bruce Nordman was rejected
2013-11-19
10 Dan Romascanu Request for Last Call review by GENART Completed: Ready. Reviewer: Dan Romascanu.
2013-11-19
10 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-soc-load-control-event-package-10. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-soc-load-control-event-package-10. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA has a question for some of the IANA actions requested in the document.

IANA understands that, upon approval of this document, there are three
actions which must be completed.  We have the question about the action
count.

First, in the Session Initiation Protocol (SIP) Event Types Namespace
registry located at:

http://www.iana.org/assignments/sip-events/

a new SIP event package is to be registered:

  Package name: load-control

  Type: package

  Contact: Charles Shen, charles@cs.columbia.edu

  Reference: [RFC-to-be]

NOTE: We will initiate a request and send this to the designated expert
for review.

Second, in the MIME Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application

a new Application Media type is to be registered:

  Application Name: load-control+xml
  Reference: [RFC-to-be]
 
  Template:

      MIME media type name: application

      MIME subtype name: load-control+xml

      Mandatory parameters: none

  Optional parameters: Same as charset parameter application/xml in
  [RFC3023]

  Encoding considerations: Same as encoding considerations of
  application/xml in [RFC3023]

  Security considerations: See Section 10 of [RFC3023] and Section 11
  of this specification

  Interoperability considerations: None

  Published Specification: This specification

  Applications which use this media type: load control of SIP entities

  Additional information:

  Magic number: None

  File extension: .xml

  Macintosh file type code: 'TEXT'

  Personal and email address for further information:

  Charles Shen, charles@cs.columbia.edu

  Intended usage: COMMON

  Author/Change Controller: IETF SOC Working Group , as designated by the IESG


Third, in the sub-registry "schema" in the IETF XML Registry located at:

http://www.iana.org/assignments/xml-registry

the following new schema should be registered:

  ID: load-control
  URI: urn:ietf:params:xml:schema:load-control
  XML: the XML schema to be registered is contained in Section 8.
  Reference: [RFC-to-be]

QUESTION: Section 12 mentions four types of registrations:

"This specification registers a SIP event package, a new MIME type, a
  new XML namespace, and a new XML schema."

We however saw only sections 12.1, 12.2 and 12.3 in the current version.
Is the "new XML namespace" still required?

IANA understands that these are the only actions required to be
completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.
2013-11-19
10 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-11-19)
2013-11-11
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bruce Nordman
2013-11-11
10 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bruce Nordman
2013-11-08
10 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2013-11-08
10 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2013-11-08
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2013-11-08
10 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2013-11-05
10 Amy Vezza IANA Review state changed to IANA - Review Needed
2013-11-05
10 Amy Vezza
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Session Initiation Protocol (SIP) …
The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Session Initiation Protocol (SIP) Load Control Event Package) to Proposed Standard


The IESG has received a request from the SIP Overload Control WG (soc) to
consider the following document:
- 'A Session Initiation Protocol (SIP) Load Control Event Package'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-19. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  We define a load control event package for the Session Initiation
  Protocol (SIP).  It allows SIP entities to distribute load filtering
  policies to other SIP entities in the network.  The load filtering
  policies contain rules to throttle calls based on their source or
  destination domain, telephone number prefix or for a specific user.
  The mechanism helps to prevent signaling overload and complements
  feedback-based SIP overload control efforts.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package/ballot/


No IPR declarations have been submitted directly on this I-D.


2013-11-05
10 Amy Vezza State changed to In Last Call from Last Call Requested
2013-11-05
10 Richard Barnes Last call was requested
2013-11-05
10 Richard Barnes Ballot approval text was generated
2013-11-05
10 Richard Barnes State changed to Last Call Requested from AD Evaluation::AD Followup
2013-11-05
10 Richard Barnes Last call announcement was generated
2013-11-05
10 Richard Barnes Last call announcement was generated
2013-11-05
10 Richard Barnes Ballot writeup was changed
2013-11-04
10 Richard Barnes Ballot writeup was generated
2013-11-04
10 Charles Shen New version available: draft-ietf-soc-load-control-event-package-10.txt
2013-07-30
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-07-30
09 Charles Shen New version available: draft-ietf-soc-load-control-event-package-09.txt
2013-06-14
08 Richard Barnes State changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2013-04-17
08 Richard Barnes State changed to AD Evaluation from Publication Requested
2013-03-18
08 Cindy Morgan
(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 …
(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
2013-03-18
08 Cindy Morgan Note added 'Volker Hilt (volker.hilt@alcatel-lucent.com) is the document shepherd.'
2013-03-18
08 Cindy Morgan Intended Status changed to Proposed Standard
2013-03-18
08 Cindy Morgan IESG process started in state Publication Requested
2013-03-18
08 (System) Earlier history may be found in the Comment Log for draft-soc-load-control-event-package
2013-03-14
08 Charles Shen New version available: draft-ietf-soc-load-control-event-package-08.txt
2013-02-20
07 Salvatore Loreto Changed shepherd to Volker Hilt
2013-02-20
07 Salvatore Loreto IETF state changed to WG Consensus: Waiting for Write-Up from WG Document
2013-02-01
07 Charles Shen New version available: draft-ietf-soc-load-control-event-package-07.txt
2012-12-31
06 Charles Shen New version available: draft-ietf-soc-load-control-event-package-06.txt
2012-10-22
05 Charles Shen New version available: draft-ietf-soc-load-control-event-package-05.txt
2012-07-29
04 Charles Shen New version available: draft-ietf-soc-load-control-event-package-04.txt
2012-03-02
03 Charles Shen New version available: draft-ietf-soc-load-control-event-package-03.txt
2012-01-10
02 (System) New version available: draft-ietf-soc-load-control-event-package-02.txt
2011-07-11
01 (System) New version available: draft-ietf-soc-load-control-event-package-01.txt
2011-01-17
00 (System) New version available: draft-ietf-soc-load-control-event-package-00.txt