From vkg@bell-labs.com Mon Jul 2 11:52:30 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C05811E80A3 for ; Mon, 2 Jul 2012 11:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.932 X-Spam-Level: X-Spam-Status: No, score=-109.932 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LU4PmpMin4UL for ; Mon, 2 Jul 2012 11:52:29 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 1160D11E8083 for ; Mon, 2 Jul 2012 11:52:28 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q62IqM9Q028544 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 2 Jul 2012 13:52:34 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q62IiNg3027611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 2 Jul 2012 13:44:23 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q62IiNDo021734 for ; Mon, 2 Jul 2012 13:44:23 -0500 (CDT) Message-ID: <4FF1ED69.60209@bell-labs.com> Date: Mon, 02 Jul 2012 13:50:17 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [sip-overload] Updated loss-based algorithm X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 18:52:30 -0000 Folks: The last iteration of the loss-based draft's default algorithm [1] was presented in the Paris IETF. List discussions right before the meeting [2] indicated that the algorithm will need to go through one more revision. The reasons for this revision are outlined as the last two bullet items in [2]. I believe that to address these two bullet items, we have to make the algorithm responsive to the traffic mix, i.e., category 1 and category 2 prioritization markers need to reflect the mix of the traffic at any point in time. That way, the algorithm can adequately respond to any situation. In an emergency situation, the number of category 2 requests will dominate, so the reduction will occur from these whereas in non-emergency situations, normal messages will dominate the traffic mix and it makes sense to cull requests from category 1 as much as we can before moving to category 2. An updated algorithm that takes the changing traffic mix into account is presented below. I would appreciate review of the updated algorithm by the WG to make sure it is on the right track. Here is the updated algorithm that will go in -09: cat1 := 80.0 // Category 1 --- subject to reduction cat2 := 100.0 - cat1 // Category 2 --- Not subject to // reduction. 80/20 mix. // Note that the above ratio is simply a reasonable default. The actual // values will change through periodic sampling as the traffic mix // changes over time. while (true) { // We're modeling message processing as a single work queue // that contains both incoming and outgoing messages. sip_msg := get_next_message_from_work_queue() update_mix(cat1, cat2) // See Note below switch (sip_msg.type) { case outbound request: destination := get_next_hop(sip_msg) oc_context := get_oc_context(destination) if (oc_context == null) { send_to_network(sip_msg) // Process it normally by sending the // request to the next hop since this particular destination // is not subject to overload } else { // Determine if server wants to enter in overload or is in // overload in_oc := extract_in_oc(oc_context) oc_value := extract_oc(oc_context) oc_validity := extract_oc_validity(oc_context) if (in_oc == false or oc_validity is not in effect) { send_to_network(sip_msg) // Process it normally by sending // the request to the next hop since this particular // destination is not subject to overload. Optionally, // clear the oc context for this server (not shown). } else { // Begin perform overload control r := random() drop_msg := false if (cat1 >= cat2) { category := assign_msg_to_category(sip_msg) pct_to_reduce_cat2 := 0 pct_to_reduce_cat1 := oc_value / cat1 * 100 if (pct_to_reduce_cat1 > 100) { // Get remaining messages from category 2 pct_to_reduce_cat2 := 100 - pct_to_reduce_cat1 pct_to_reduce_cat1 := 100 } if (category == cat1) { if (r <= pct_to_reduce_cat1) { drop_msg := true } } else { // Message from category 2 if (r <= pct_to_reduce_cat2) { drop_msg := true } } } else { // More category 2 messages than category 1; // indicative of an emergency situation. Since // there are more category 2 messages, we // simply treat category 1 and category 2 equal // for discard purposes. if (r <= oc_value) drop_msg := true } if (drop_msg == false) { send_to_network(sip_msg) // Process it normally by // sending the request to the next hop } else { // Do not send request downstream, handle locally by // generating response (if a proxy) or treating as // an error (if a user agent). } } // End perform overload control } end case // outbound request case outbound response: if (we are in overload) { add_overload_parameters(sip_msg) } send_to_network(sip_msg) end case // outbound response case inbound response: if (sip_msg has oc parameter values) { create_or_update_oc_context() // For the specific server // that sent the response, create or update the oc context; // i.e., extract the values of the oc-related parameters // and store them for later use. } process_msg(sip_msg) end case // inbound response case inbound request: if (we are not in overload) { process_msg(sip_msg) } else { // We are in overload if (sip_msg has oc parameters) { // Upstream client supports process_msg(sip_msg) // oc; only sends important requests } else { // Upstream client does not support oc if (local_policy(sip_msg) says process message) { process_msg(sip_msg) } else { send_response(sip_msg, 503) } } } end case // inbound request } } Note: A simple way to sample the traffic mix for category 1 and category 2 is to associate a counter with each category of message. Periodically (every 5-10s) get the value of the counters and calculate the ratio of category 1 messages to category 2 messages since the last calculation. Example: In the last 5 seconds, a total of 500 requests arrived at the client. Assume that 450 out of 500 were requests subject to reduction and 50 out of 500 were classified as requests not subject to reduction. Based on this ratio, cat1 := 90 and cat2 := 10, or a 90/10 mix will be used in overload calculations for the next time period. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-08#section-6.3 [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00764.html Comments and feedback is eagerly sought. Thanks, - 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From salvatore.loreto@ericsson.com Mon Jul 2 12:08:40 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 432F611E80CA for ; Mon, 2 Jul 2012 12:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BcIqVEJcXtFn for ; Mon, 2 Jul 2012 12:08:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id E8E7011E8098 for ; Mon, 2 Jul 2012 12:08:38 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc26d000005908-3f-4ff1f1b85bb3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 8C.9A.22792.8B1F1FF4; Mon, 2 Jul 2012 21:08:40 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Mon, 2 Jul 2012 21:08:40 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 086A72AE3; Mon, 2 Jul 2012 22:08:40 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 162145330D; Mon, 2 Jul 2012 22:08:41 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id AB02851E2D; Mon, 2 Jul 2012 22:08:40 +0300 (EEST) Message-ID: <4FF1F1B6.2080406@ericsson.com> Date: Mon, 2 Jul 2012 22:08:38 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvre6Ojx/9Dbr6FCyuzWlks9j/NMFi 3v49rA7MHq3P9rJ6LFnyk8lj1s4nLAHMUVw2Kak5mWWpRfp2CVwZm1/MZSw4x1Kx5MAXxgbG B8xdjJwcEgImEt9X9bFD2GISF+6tZ+ti5OIQEjjFKPH+4m4oZz2jxOcVT9ghnN2MEhPaTjCC tAgJrGOUuNeoBZHYziix4OQ2pi5GDg5eAW2JnVstQGpYBFQk3j/8C7aOTcBM4vnDLcwgJaIC yRJ//6eDhHkFBCVOznzCAmKLCBhLHHm8hRGkhFkgUmLhJyMQU1jAUmLaoTqQCmYBW4kLc66z QNjyEtvfzoH6RU3i6rlNzBCHaUn0nu1kmsAoPAvJgllI2mchaV/AyLyKUTg3MTMnvdxQL7Uo M7m4OD9Przh1EyMw1A9u+a27g/HUOZFDjNIcLErivFxJ+/2FBNITS1KzU1MLUovii0pzUosP MTJxcEo1MEpJRnA92Pb67mLlW29+653OesJqktd/KX6u4pIZ/hd13Rs+aEkFewYIiWsaLtRX nH/R9ZLcDZfPJg9c1hl+99L8L3jzn4b+/BOyIq06uc6L3S6mzavYbhfBdYBl/Vfr7ekcjRfy p1Q8ZAhydNniHMV28PLv48/O+IYeeHWzt6TxpXrOBaV5h5VYijMSDbWYi4oTAT7qFlpDAgAA Cc: Volker Hilt Subject: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2012 19:08:40 -0000 [as chair] based on the mailing list discussion and the one we had during the last SoC f2f meeting in Paris, the chairs think the draft-ietf-soc-oload-control-event-package is ready for the WGLC. Today we are starting a two-week working group last call. This call ends on Wednesday, July 16th. the last version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03 reviews and comments are really appreciate and requested from all the participants cheers /Sal -- Salvatore Loreto, PhD www.sloreto.com From internet-drafts@ietf.org Fri Jul 6 14:17:11 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E2D21F869A; Fri, 6 Jul 2012 14:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6GBPU0B79r5X; Fri, 6 Jul 2012 14:17:10 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36FC221F8656; Fri, 6 Jul 2012 14:17:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.30p2 Message-ID: <20120706211710.1624.1997.idtracker@ietfa.amsl.com> Date: Fri, 06 Jul 2012 14:17:10 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-control-09.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 21:17:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : Session Initiation Protocol (SIP) Overload Control Author(s) : Vijay K. Gurbani Volker Hilt Henning Schulzrinne Filename : draft-ietf-soc-overload-control-09.txt Pages : 35 Date : 2012-07-06 Abstract: Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-control There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-control-09 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-control-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vkg@bell-labs.com Fri Jul 6 14:23:46 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373C011E80F3 for ; Fri, 6 Jul 2012 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.099 X-Spam-Level: X-Spam-Status: No, score=-108.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t0Fhpnn8kX1W for ; Fri, 6 Jul 2012 14:23:45 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5DEED11E808F for ; Fri, 6 Jul 2012 14:23:45 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q66LO1BS022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 6 Jul 2012 16:24:02 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q66LO1vV026499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 6 Jul 2012 16:24:01 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q66LO1kw014683 for ; Fri, 6 Jul 2012 16:24:01 -0500 (CDT) Message-ID: <4FF758D7.3010203@bell-labs.com> Date: Fri, 06 Jul 2012 16:29:59 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [sip-overload] draft-ietf-soc-overload-control-09 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 21:23:46 -0000 Folks: The last iteration of the loss-based draft's default algorithm [1] was presented in the Paris IETF. List discussions right before the meeting [2] indicated that the algorithm will need to go through one more revision. The reasons for this revision are outlined as the last two bullet items in [2]. I believe that to address these two bullet items, we have to make the algorithm responsive to the traffic mix, i.e., category 1 and category 2 prioritization markers need to reflect the mix of the traffic at any point in time. That way, the algorithm can adequately respond to any situation. In an emergency situation, the number of category 2 requests will dominate, so the reduction will occur from these whereas in non-emergency situations, normal messages will dominate the traffic mix and it makes sense to cull requests from category 1 as much as we can before moving to category 2. An updated algorithm that takes the changing traffic mix into account is now part of the revised version of the draft, version -09 [3]. I would appreciate review of the updated algorithm by the WG to make sure it is on the right track. I have also attended to all but two of the comments in [2]. I need to think on how to attend to the comments related to S5.4 in [2]. Besides these, I do not believe that there are any other outstanding comments. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-08#section-6.3 [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00764.html [3] http://tools.ietf.org/html/draft-ietf-soc-overload-control-09 Thanks, - 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Fri Jul 6 14:31:21 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5E511E80F3 for ; Fri, 6 Jul 2012 14:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.799 X-Spam-Level: X-Spam-Status: No, score=-109.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFXTfqehJhQT for ; Fri, 6 Jul 2012 14:31:20 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2589411E808F for ; Fri, 6 Jul 2012 14:31:20 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q66LVaje024428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 6 Jul 2012 16:31:37 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q66LVaIe011634 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 6 Jul 2012 16:31:36 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q66LVZIO015994; Fri, 6 Jul 2012 16:31:35 -0500 (CDT) Message-ID: <4FF75A9E.5090307@bell-labs.com> Date: Fri, 06 Jul 2012 16:37:34 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com> <4F957A0C.4050606@bell-labs.com> <4F957A50.7040402@bell-labs.com> <4F95845B.2040508@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@inba-mail01.sonusnet.com> <4F97191A.5020501@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "sip-overload@ietf.org" , Volker Hilt Subject: Re: [sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: draft minutes IETF83] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jul 2012 21:31:21 -0000 This response is for Partha's original email archived at http://www.ietf.org/mail-archive/web/sip-overload/current/msg00789.html. I am not inline including his original email. Please see above URL for the context. Partha: I am in the process of closing the open issues for draft-ietf-soc-overload control. One of these is yours, although I do not think your comments in the above URL will necessitate any changes in the draft. But to close the loop, please see below. To recap, I had suggested that we remove S9 from draft-ietf-soc-overload-control [1], but it was felt that S9 provides useful information that should be retained for archival purposes [2]. The merits and demerits of choosing the Via parameter approach over SUBS/NOT were looked at a long time ago, and I just want to make sure that your intent is not to reopen that discussion. (Personally, I don't think that is a good use of our time.) In the instance where SUBS/NOT adds value to the general SIP overload control problem, an event package has been defined for that purpose [4]. So, let's be sure that S9 is currently there for archival purposes only. Unless you have specific objections to proceeding with S9 in the draft --- and I don't think you do based on your earlier response in [3] --- I'd rather continue moving the work ahead. Please advise. [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00773.html [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00775.html [3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00780.html [4] http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03 Thanks, - 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From pravindran@sonusnet.com Sat Jul 7 21:23:53 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6796921F85D4 for ; Sat, 7 Jul 2012 21:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnM0ghkwjsG3 for ; Sat, 7 Jul 2012 21:23:52 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) by ietfa.amsl.com (Postfix) with ESMTP id 16FE621F85D0 for ; Sat, 7 Jul 2012 21:23:52 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKT/kLbKBxYusFv8btUg8ZPGLGKL1lsvDB@postini.com; Sat, 07 Jul 2012 21:24:13 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sun, 8 Jul 2012 00:24:11 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Sun, 8 Jul 2012 09:54:08 +0530 From: "Ravindran, Parthasarathi" To: "Vijay K. Gurbani" Thread-Topic: Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: [sip-overload] draft minutes IETF83] Thread-Index: AQHNRI86dm1Q0tcgiE28amjvCK4nLpccmckAgAJgQGA= Date: Sun, 8 Jul 2012 04:24:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C1605D895@inba-mail01.sonusnet.com> References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com> <4F957A0C.4050606@bell-labs.com> <4F957A50.7040402@bell-labs.com> <4F95845B.2040508@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@inba-mail01.sonusnet.com> <4F97191A.5020501@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.com> <4FF75A9E.5090307@bell-labs.com> In-Reply-To: <4FF75A9E.5090307@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [121.242.142.186] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip-overload@ietf.org" , Volker Hilt Subject: Re: [sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: draft minutes IETF83] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 04:23:53 -0000 Vijay, I'm fine with your approach. Thanks Partha >-----Original Message----- >From: Vijay K. Gurbani [mailto:vkg@bell-labs.com] >Sent: Saturday, July 07, 2012 3:08 AM >To: Ravindran, Parthasarathi >Cc: Volker Hilt; sip-overload@ietf.org >Subject: Re: Comment on draft-ietf-soc-overload-control SIP Event >package section [was RE: [sip-overload] draft minutes IETF83] > >This response is for Partha's original email archived at >http://www.ietf.org/mail-archive/web/sip-overload/current/msg00789.html. >I am not inline including his original email. Please see above URL for >the context. > >Partha: I am in the process of closing the open issues for draft-ietf- >soc-overload control. One of these is yours, although I do not think >your comments in the above URL will necessitate any changes in the >draft. But to close the loop, please see below. > >To recap, I had suggested that we remove S9 from draft-ietf-soc- >overload-control [1], but it was felt that S9 provides useful >information that should be retained for archival purposes [2]. > >The merits and demerits of choosing the Via parameter approach over >SUBS/NOT were looked at a long time ago, and I just want to make sure >that your intent is not to reopen that discussion. (Personally, I don't >think that is a good use of our time.) In the instance where SUBS/NOT >adds value to the general SIP overload control problem, an event package >has been defined for that purpose [4]. > >So, let's be sure that S9 is currently there for archival purposes only. >Unless you have specific objections to proceeding with S9 in the draft - >-- and I don't think you do based on your earlier response in [3] --- >I'd rather continue moving the work ahead. > >Please advise. > >[1] http://www.ietf.org/mail-archive/web/sip- >overload/current/msg00773.html >[2] http://www.ietf.org/mail-archive/web/sip- >overload/current/msg00775.html >[3] http://www.ietf.org/mail-archive/web/sip- >overload/current/msg00780.html >[4] http://tools.ietf.org/html/draft-ietf-soc-load-control-event- >package-03 > >Thanks, > >- 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} / vijay.gurbani@alcatel-lucent.com >Web: http://ect.bell-labs.com/who/vkg/ > From vkg@bell-labs.com Sun Jul 8 07:34:06 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB39B21F8562 for ; Sun, 8 Jul 2012 07:34:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CR0iNmpRICdt for ; Sun, 8 Jul 2012 07:34:06 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 445F421F8554 for ; Sun, 8 Jul 2012 07:34:06 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q68EYRmA012882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 8 Jul 2012 09:34:28 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q68EYRVo023754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 8 Jul 2012 09:34:27 -0500 Received: from shoonya.ih.lucent.com (mhnguyen.lra.lucent.com [135.244.0.4] (may be forged)) by umail.lucent.com (8.13.8/TPES) with ESMTP id q68EYQK6002823; Sun, 8 Jul 2012 09:34:26 -0500 (CDT) Message-ID: <4FF99BDA.7060307@bell-labs.com> Date: Sun, 08 Jul 2012 09:40:26 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com> <4F957A0C.4050606@bell-labs.com> <4F957A50.7040402@bell-labs.com> <4F95845B.2040508@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@inba-mail01.sonusnet.com> <4F97191A.5020501@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C16045036@inba-mail02.sonusnet.com> <4FF75A9E.5090307@bell-labs.com> <387F9047F55E8C42850AD6B3A7A03C6C1605D895@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C1605D895@inba-mail01.sonusnet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "sip-overload@ietf.org" , Volker Hilt Subject: Re: [sip-overload] Comment on draft-ietf-soc-overload-control SIP Event package section [was RE: draft minutes IETF83] X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jul 2012 14:34:07 -0000 On 07/07/2012 11:24 PM, Ravindran, Parthasarathi wrote: > Vijay, > > I'm fine with your approach. Partha: Great. Thank you for getting back expeditiously. - 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From salvatore.loreto@ericsson.com Sun Jul 8 23:51:11 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5F821F8799 for ; Sun, 8 Jul 2012 23:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+vz4z9joJTX for ; Sun, 8 Jul 2012 23:51:10 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4F71321F877E for ; Sun, 8 Jul 2012 23:51:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7fc26d000005908-f9-4ffa7f738111 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 32.97.22792.37F7AFF4; Mon, 9 Jul 2012 08:51:31 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.264.0; Mon, 9 Jul 2012 08:51:31 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 03A952420 for ; Mon, 9 Jul 2012 09:51:30 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D49B2532E2 for ; Mon, 9 Jul 2012 09:51:31 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 67A015324F for ; Mon, 9 Jul 2012 09:51:31 +0300 (EEST) Message-ID: <4FFA7F71.9060903@ericsson.com> Date: Mon, 9 Jul 2012 08:51:29 +0200 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4FF1F1B6.2080406@ericsson.com> In-Reply-To: <4FF1F1B6.2080406@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+JvrW5x/S9/g3vNBhb7nyY4MHosWfKT KYAxissmJTUnsyy1SN8ugSvj0btPTAW3WSs2zv/L1MB4gqWLkZNDQsBE4s6j/ewQtpjEhXvr 2boYuTiEBE4xSuw5O5cVwlnPKPH15klGkCohgeuMEsem88NVnbm6hxkicZlRYuqEShCbV0Bb Yvm0Y2BxFgEViYtNF8FsNgEziecPtwDZHByiAskSf/+nQ5QLSpyc+QTsIhEBSYkvzyeC7RIW cJJY0zqXBaRcCGjkvf/CIGFOAR2J9qYNTCA2s4CtxIU511kgbHmJ7W/nMEM8oyZx9dwmqMu0 JHrPdjJNYBSZhWTbLCTts5C0L2BkXsUonJuYmZNebqiXWpSZXFycn6dXnLqJERjcB7f81t3B eOqcyCFGaQ4WJXFerqT9/kIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoY3SZu9i4rnJ7F95I3 ocnvyjseR5Udd86JbuN0PdA8//TbHoZzZix21j73nyXcMD5nrX2/UvPpouxzF0t2ngj9UvUh RlNtLt+qx8+kjJ1K3WLfGuc4Ptb4zbXzxNHeqz93CO5jXKnAa/XOZfKP9gCpLx8Si6P/CXpe ufawMdHOwGVL9weJLQ2WSizFGYmGWsxFxYkAKVYK8zwCAAA= Subject: [sip-overload] reminder: WGLC: draft-ietf-soc-load-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jul 2012 06:51:11 -0000 please send your reviews/comments we need them in order to let this draft to move on thanks Salvatore On 7/2/12 9:08 PM, Salvatore Loreto wrote: > [as chair] > > based on the mailing list discussion and the one we had during the last SoC f2f meeting in Paris, > the chairs think the draft-ietf-soc-oload-control-event-package is ready for the WGLC. > > Today we are starting a two-week working group last call. > *This call ends on Wednesday, July 16th.* > > the last version of the document can be retrieved here: > http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03 > > > reviews and comments are really appreciate and requested from all the participants > > > cheers > /Sal > From shida@ntt-at.com Mon Jul 9 17:27:18 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12E611E816F for ; Mon, 9 Jul 2012 17:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfsMULLtDfPJ for ; Mon, 9 Jul 2012 17:27:18 -0700 (PDT) Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3180111E816D for ; Mon, 9 Jul 2012 17:27:18 -0700 (PDT) Received: from [36.2.1.98] (port=49218 helo=[192.168.1.18]) by gator465.hostgator.com with esmtpa (Exim 4.77) (envelope-from ) id 1SoOIp-0003sK-RQ; Mon, 09 Jul 2012 19:27:43 -0500 Mime-Version: 1.0 (Apple Message framework v1280) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4FFA7F71.9060903@ericsson.com> Date: Tue, 10 Jul 2012 09:27:42 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <982E5DB9-5460-4E47-9C80-9ADBF114ABBC@ntt-at.com> References: <4FF1F1B6.2080406@ericsson.com> <4FFA7F71.9060903@ericsson.com> To: Salvatore Loreto X-Mailer: Apple Mail (2.1280) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.1.18]) [36.2.1.98]:49218 X-Source-Auth: shida.schubert+tingle.jp X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: sip-overload@ietf.org Subject: Re: [sip-overload] reminder: WGLC: draft-ietf-soc-load-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2012 00:27:19 -0000 All the comments I provided to the previous version (01) of=20 this draft has been addressed, and I think the draft is ready to=20 go.=20 Many Thanks Shida On Jul 9, 2012, at 3:51 PM, Salvatore Loreto wrote: > please send your reviews/comments > we need them in order to let this draft to move on >=20 > thanks > Salvatore >=20 > On 7/2/12 9:08 PM, Salvatore Loreto wrote: >> [as chair] >>=20 >> based on the mailing list discussion and the one we had during the = last SoC f2f meeting in Paris, >> the chairs think the draft-ietf-soc-oload-control-event-package is = ready for the WGLC. >>=20 >> Today we are starting a two-week working group last call. >> *This call ends on Wednesday, July 16th.* >>=20 >> the last version of the document can be retrieved here: >> = http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03 >>=20 >>=20 >> reviews and comments are really appreciate and requested from all the = participants >>=20 >>=20 >> cheers >> /Sal >>=20 >=20 >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From bruno.chatras@orange.com Wed Jul 11 00:32:54 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6853221F85DB for ; Wed, 11 Jul 2012 00:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.133 X-Spam-Level: X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyFJOIjxp48c for ; Wed, 11 Jul 2012 00:32:53 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id EA2D521F8564 for ; Wed, 11 Jul 2012 00:32:50 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 91A112DC0A7; Wed, 11 Jul 2012 09:33:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 74C954C015; Wed, 11 Jul 2012 09:33:19 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 11 Jul 2012 09:33:15 +0200 From: To: Salvatore Loreto , "sip-overload@ietf.org" Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package Thread-Index: AQHNWIYghEHWjP/zI0+dx9hFlVmae5cjvLPw Date: Wed, 11 Jul 2012 07:33:15 +0000 Message-ID: <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> In-Reply-To: <4FF1F1B6.2080406@ericsson.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.6.19.115414 Cc: Volker Hilt Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2012 07:32:54 -0000 Hi! Here are my comments about this I-D. 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5 (i.e. a= fter line 360) and modifies the first two sentences as follows: "In the above case, the network entity where load filtering policy is first= introduced is the SIP server providing access to the resource that creates= the overload condition. In other cases, the network entry point of load fi= ltering policy could also be an entity that hosts this resource. " 2) Section 5.8, line 525-528 The current text suggests that incoming requests are filtered irrespective = of their actual destination. The subscriber should rather apply filters on = requests that are outgoing to the pre-overloaded destination. One solution = would be to rephrase the following text: "A subscriber receiving the notification first installs these rules and the= n filter incoming requests to enforce actions on appropriate requests, for = example, limiting the sending rate of call requests destined for a specific= SIP entity." With "A subscriber receiving the notification first installs these rules and the= n filter outgoing requests towards the notifier to enforce actions on appro= priate requests, for example, limiting the sending rate of call requests de= stined for a specific SIP entity." This would however not permit the use of external state agents as described= in section 5.12. Therefore it seems that a "target sip entity" parameter s= hould be added to overload control documents.=20 3) Section 5.8, add the following text (adapted from draft-ietf-soc-overloa= d-control) after line 537: "When enforcing actions on requests matching the filters, subscribers SHOUL= D honor the local policy for prioritizing SIP requests such as policies bas= ed on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]).= Specific (namespace.value) RPH contents may indicate high priority reques= ts that should be preserved as much as possible during overload. The RPH = contents can also indicate a low-priority request that is eligible to be dr= opped during times of overload. Other indicators, such as the SOS URN [RFC= 5031] indicating an emergency request, may also be used for prioritization." 4) Section 6.3.1, matching identities: After line 699, add the following te= xt: "Before evaluating call-identity conditions, the subscriber shall convert U= RIs received in SIP header fields in canonical form as per RFC 3261, except= that the phone-context parameter shall not be removed, if present." 5) Section 6.3.1, local number grouping: The proposed solution for local numbers is not suitable. For example, if th= e phone-context for short service numbers in a country is the country code,= the solution does not permit to define a filter that excludes all E.164 nu= mbers in that country but retain all short service numbers. I think we shou= ld either define another solution or state that grouping of local numbers i= s not supported or state that grouping of local numbers only works under sp= ecific assumptions on the use of phone-context values. 6) Section 6.3.1, line 746 - 753, remove the last but one sentence and rewo= rd the rest of the text accordingly. Reason: The use of local number 'tel' = URI in the R-URI and To header field is not rare. In several countries, sho= rt numbers are used quite extensively to access special services. "Second, use of the local number 'tel' URI in practice is expected to be ra= re."=20=20 7) Clause 6.3.3, after line 800, add: "SUBSCRIBE requests are not filtered if the event-type header field indicat= es the event package defined in this document." 8) Section 7, line 985 - 990: replace "call type" with "call identity type"= (3 times) 9) Section 8.1 Line 1048, add "except in specific cases when the Intelligent Network archi= tecture is used [AINGR]. Line 1060, remove the last part of the first sentence starting with "and th= e number of prefix to be matched.": ITU IN specifications allow for dynamic= sets. Line 1068, remove the last part of the first sentence staring with "with a = fixed set.": Reason: ITU IN specifications allow for dynamic sets. 10) Miscellaneous points Section 1, line 106, replace RFC3265 with RFC3261 Section 4.1, line 231, replace "proxy" with "node" (this text should apply = to any type of SIP entity) Section 4.3, line 265, replace "proxy" with "node" (this text should apply = to any type of SIP entity) Section 4.3, Line 341, replace "singling" with "signaling" Section 4.3, Line 342, replace "all signaling relationship in Figure 1 is" = with "all signaling relationships in Figure 1 are" Section 5.6, Line 503, add "request" after "SUBSCRIBE" Section 5.11, Line 585, remove "is" Section 6.5, Line 851, replace "vliad" with "valid" Bruno > -----Message d'origine----- > De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.or= g] > De la part de Salvatore Loreto > Envoy=E9=A0: lundi 2 juillet 2012 21:09 > =C0=A0: sip-overload@ietf.org > Cc=A0: Volker Hilt > Objet=A0: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package >=20 > [as chair] >=20 > based on the mailing list discussion and the one we had during the last > SoC f2f meeting in Paris, > the chairs think the draft-ietf-soc-oload-control-event-package is ready > for the WGLC. >=20 > Today we are starting a two-week working group last call. > This call ends on Wednesday, July 16th. >=20 > the last version of the document can be retrieved here: > http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03 >=20 >=20 > reviews and comments are really appreciate and requested from all the > participants >=20 >=20 > cheers > /Sal >=20 > -- > Salvatore Loreto, PhD > www.sloreto.com >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete al= tere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for message= s that have been modified, changed or falsified. Thank you. From volker.hilt@bell-labs.com Mon Jul 16 14:19:55 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C137611E826B for ; Mon, 16 Jul 2012 14:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4kugU42YPj3 for ; Mon, 16 Jul 2012 14:19:55 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id E605B11E80D0 for ; Mon, 16 Jul 2012 14:19:54 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6GLKdto020834 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 16 Jul 2012 23:20:39 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 16 Jul 2012 23:20:39 +0200 Received: from [135.244.2.207] (135.5.27.12) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 16 Jul 2012 17:20:36 -0400 Message-ID: <500485A2.80405@alcatel-lucent.com> Date: Mon, 16 Jul 2012 17:20:34 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [sip-overload] Agenda Requests X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 21:19:56 -0000 Folks, we have a slot on the agenda of the next IETF meeting. Our session will be on TUESDAY, July 31, 2012 at 0900-1020 Vancouver time. If you would like to request a slot on the agenda of the SOC session, please send the chairs a private email with a short description of the topic, the desired time and the drafts that are related to the request. Thanks, Volker From charles.newyork@gmail.com Tue Jul 17 09:36:18 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4630421F84FD for ; Tue, 17 Jul 2012 09:36:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EcQw2yGB-JRf for ; Tue, 17 Jul 2012 09:36:16 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B8C121F855A for ; Tue, 17 Jul 2012 09:36:16 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so477869vbb.31 for ; Tue, 17 Jul 2012 09:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=Sbcgb978VpD66j0EfQDSXAUb6UkBUc7NBBhzgiVGeFo=; b=f/0eA403dz+mTMl/ffPJsaVhojUAPpS+wBxHMQUg/FJJePG5pH5xN0cQA6ldqz0cSD FoxL+mXDJyVLT9CC9XYUAzkgrJt6m1nix6u0IHPk9Zht+PCxcZS0ezqRbbhxnpuKMgur xc/0QIqk5yI/WslDNQ/lFMTfAt7wl/VSZuVxv2SL1aORnFfjCtbX3Gl9k06T0u1gOYDf bE2RQDPlfLAcXrtcWZcPeJGYlcvxnOnBQ3o+i1CiU1eLuWfW38C5Stt/6OmGDMEviZxE F7mxc3zGiFBCyHY01EblbBEtc2/Mo/H4zCyvBAe7GJcvPHvAXuq84MU2l5K81mT2HVKr 7oiw== Received: by 10.220.107.130 with SMTP id b2mr1507266vcp.35.1342543023810; Tue, 17 Jul 2012 09:37:03 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.244.201 with HTTP; Tue, 17 Jul 2012 09:36:43 -0700 (PDT) In-Reply-To: <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: Charles Shen Date: Tue, 17 Jul 2012 12:36:43 -0400 X-Google-Sender-Auth: KYKZ7aruhpBLvdlX_7cYqTEsX7Q Message-ID: To: bruno.chatras@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 16:36:18 -0000 Hi Bruno, thank you so much for the detailed review and comments! I've addressed 8 out of the total 10, except the following two which I'd appreciate more clarification. > 2) Section 5.8, line 525-528 > > The current text suggests that incoming requests are filtered irrespectiv= e of their actual destination. The subscriber should rather apply filters o= n requests that are outgoing to the pre-overloaded destination. One solutio= n would be to rephrase the following text: > > "A subscriber receiving the notification first installs these rules and t= hen filter incoming requests to enforce actions on appropriate requests, fo= r example, limiting the sending rate of call requests destined for a specif= ic SIP entity." > > With > > "A subscriber receiving the notification first installs these rules and t= hen filter outgoing requests towards the notifier to enforce actions on app= ropriate requests, for example, limiting the sending rate of call requests = destined for a specific SIP entity." > > This would however not permit the use of external state agents as describ= ed in section 5.12. Therefore it seems that a "target sip entity" parameter= should be added to overload control documents. > I think I might have not understood your point. The requests are filtered based on the call identities, which can convey information including the call destination. Could you elaborate what this "target sip entity" is exactly for? > 5) Section 6.3.1, local number grouping: > > The proposed solution for local numbers is not suitable. For example, if = the phone-context for short service numbers in a country is the country cod= e, the solution does not permit to define a filter that excludes all E.164 = numbers in that country but retain all short service numbers. I think we sh= ould either define another solution or state that grouping of local numbers= is not supported or state that grouping of local numbers only works under = specific assumptions on the use of phone-context values. > How about adding the following text? It should be noted that the method of grouping local numbers as defined in this document does not support all cases. For example, if the phone-context for short service numbers in a country is the country code, this solution does not permit to define a filter that excludes all E.164 numbers in that country but retain all short service numbers. A complete solution for local number grouping requires a separate method outside the scope of this document. Thanks! Charles On Wed, Jul 11, 2012 at 3:33 AM, wrote: > Hi! > > Here are my comments about this I-D. > > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5 (i.e.= after line 360) and modifies the first two sentences as follows: > > "In the above case, the network entity where load filtering policy is fir= st introduced is the SIP server providing access to the resource that creat= es the overload condition. In other cases, the network entry point of load = filtering policy could also be an entity that hosts this resource. " > > 2) Section 5.8, line 525-528 > > The current text suggests that incoming requests are filtered irrespectiv= e of their actual destination. The subscriber should rather apply filters o= n requests that are outgoing to the pre-overloaded destination. One solutio= n would be to rephrase the following text: > > "A subscriber receiving the notification first installs these rules and t= hen filter incoming requests to enforce actions on appropriate requests, fo= r example, limiting the sending rate of call requests destined for a specif= ic SIP entity." > > With > > "A subscriber receiving the notification first installs these rules and t= hen filter outgoing requests towards the notifier to enforce actions on app= ropriate requests, for example, limiting the sending rate of call requests = destined for a specific SIP entity." > > This would however not permit the use of external state agents as describ= ed in section 5.12. Therefore it seems that a "target sip entity" parameter= should be added to overload control documents. > > 3) Section 5.8, add the following text (adapted from draft-ietf-soc-overl= oad-control) after line 537: > > "When enforcing actions on requests matching the filters, subscribers SHO= ULD honor the local policy for prioritizing SIP requests such as policies b= ased on the content of the Resource-Priority header (RPH, RFC4412 [RFC4412]= ). Specific (namespace.value) RPH contents may indicate high priority requ= ests that should be preserved as much as possible during overload. The RP= H contents can also indicate a low-priority request that is eligible to be = dropped during times of overload. Other indicators, such as the SOS URN [R= FC5031] indicating an emergency request, may also be used for prioritizatio= n." > > 4) Section 6.3.1, matching identities: After line 699, add the following = text: > > "Before evaluating call-identity conditions, the subscriber shall convert= URIs received in SIP header fields in canonical form as per RFC 3261, exce= pt that the phone-context parameter shall not be removed, if present." > > 5) Section 6.3.1, local number grouping: > > The proposed solution for local numbers is not suitable. For example, if = the phone-context for short service numbers in a country is the country cod= e, the solution does not permit to define a filter that excludes all E.164 = numbers in that country but retain all short service numbers. I think we sh= ould either define another solution or state that grouping of local numbers= is not supported or state that grouping of local numbers only works under = specific assumptions on the use of phone-context values. > > 6) Section 6.3.1, line 746 - 753, remove the last but one sentence and re= word the rest of the text accordingly. Reason: The use of local number 'tel= ' URI in the R-URI and To header field is not rare. In several countries, s= hort numbers are used quite extensively to access special services. > > "Second, use of the local number 'tel' URI in practice is expected to be = rare." > > 7) Clause 6.3.3, after line 800, add: > > "SUBSCRIBE requests are not filtered if the event-type header field indic= ates the event package defined in this document." > > 8) Section 7, line 985 - 990: replace "call type" with "call identity typ= e" (3 times) > > 9) Section 8.1 > > Line 1048, add "except in specific cases when the Intelligent Network arc= hitecture is used [AINGR]. > > Line 1060, remove the last part of the first sentence starting with "and = the number of prefix to be matched.": ITU IN specifications allow for dynam= ic sets. > > Line 1068, remove the last part of the first sentence staring with "with = a fixed set.": Reason: ITU IN specifications allow for dynamic sets. > > 10) Miscellaneous points > Section 1, line 106, replace RFC3265 with RFC3261 > Section 4.1, line 231, replace "proxy" with "node" (this text should appl= y to any type of SIP entity) > Section 4.3, line 265, replace "proxy" with "node" (this text should appl= y to any type of SIP entity) > Section 4.3, Line 341, replace "singling" with "signaling" > Section 4.3, Line 342, replace "all signaling relationship in Figure 1 is= " with "all signaling relationships in Figure 1 are" > Section 5.6, Line 503, add "request" after "SUBSCRIBE" > Section 5.11, Line 585, remove "is" > Section 6.5, Line 851, replace "vliad" with "valid" > > Bruno > > >> -----Message d'origine----- >> De : sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org= ] >> De la part de Salvatore Loreto >> Envoy=C3=A9 : lundi 2 juillet 2012 21:09 >> =C3=80 : sip-overload@ietf.org >> Cc : Volker Hilt >> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package >> >> [as chair] >> >> based on the mailing list discussion and the one we had during the last >> SoC f2f meeting in Paris, >> the chairs think the draft-ietf-soc-oload-control-event-package is ready >> for the WGLC. >> >> Today we are starting a two-week working group last call. >> This call ends on Wednesday, July 16th. >> >> the last version of the document can be retrieved here: >> http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-03 >> >> >> reviews and comments are really appreciate and requested from all the >> participants >> >> >> cheers >> /Sal >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From bruno.chatras@orange.com Tue Jul 17 10:07:07 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0EB21F86A6 for ; Tue, 17 Jul 2012 10:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.288 X-Spam-Level: X-Spam-Status: No, score=-2.288 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L3YWJNjHDNw for ; Tue, 17 Jul 2012 10:07:05 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 34DA821F865E for ; Tue, 17 Jul 2012 10:07:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 9B0C23B43D4; Tue, 17 Jul 2012 19:07:52 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7B87635C045; Tue, 17 Jul 2012 19:07:52 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Tue, 17 Jul 2012 19:07:50 +0200 From: To: Charles Shen Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package Thread-Index: AQHNWIYghEHWjP/zI0+dx9hFlVmae5ctw8EPgAABoiA= Date: Tue, 17 Jul 2012 17:07:49 +0000 Message-ID: <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.17.155416 Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2012 17:07:07 -0000 SGkgQ2hhcmxlcywNCg0KU2VlIGJlbG93Lg0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0t LQ0KPiBEZcKgOiBjaGFybGVzLm5ld3lvcmtAZ21haWwuY29tIFttYWlsdG86Y2hhcmxlcy5uZXd5 b3JrQGdtYWlsLmNvbV0gRGUgbGENCj4gcGFydCBkZSBDaGFybGVzIFNoZW4NCj4gRW52b3nDqcKg OiBtYXJkaSAxNyBqdWlsbGV0IDIwMTIgMTg6MzcNCj4gw4DCoDogQ0hBVFJBUyBCcnVubyBSRC1D T1JFDQo+IENjwqA6IFNhbHZhdG9yZSBMb3JldG87IHNpcC1vdmVybG9hZEBpZXRmLm9yZzsgVm9s a2VyIEhpbHQ7IEhlbm5pbmcNCj4gU2NodWx6cmlubmU7IEFyYXRhIEtvaWtlDQo+IE9iamV0wqA6 IFJlOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vbG9hZC1jb250cm9sLWV2 ZW50LQ0KPiBwYWNrYWdlDQo+IA0KPiBIaSBCcnVubywgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHRo ZSBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRzISBJJ3ZlDQo+IGFkZHJlc3NlZCA4IG91dCBv ZiB0aGUgdG90YWwgMTAsIGV4Y2VwdCB0aGUgZm9sbG93aW5nIHR3byB3aGljaCBJJ2QNCj4gYXBw cmVjaWF0ZSBtb3JlIGNsYXJpZmljYXRpb24uDQo+IA0KPiA+IDIpIFNlY3Rpb24gNS44LCBsaW5l IDUyNS01MjgNCj4gPg0KPiA+IFRoZSBjdXJyZW50IHRleHQgc3VnZ2VzdHMgdGhhdCBpbmNvbWlu ZyByZXF1ZXN0cyBhcmUgZmlsdGVyZWQNCj4gaXJyZXNwZWN0aXZlIG9mIHRoZWlyIGFjdHVhbCBk ZXN0aW5hdGlvbi4gVGhlIHN1YnNjcmliZXIgc2hvdWxkIHJhdGhlcg0KPiBhcHBseSBmaWx0ZXJz IG9uIHJlcXVlc3RzIHRoYXQgYXJlIG91dGdvaW5nIHRvIHRoZSBwcmUtb3ZlcmxvYWRlZA0KPiBk ZXN0aW5hdGlvbi4gT25lIHNvbHV0aW9uIHdvdWxkIGJlIHRvIHJlcGhyYXNlIHRoZSBmb2xsb3dp bmcgdGV4dDoNCj4gPg0KPiA+ICJBIHN1YnNjcmliZXIgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRp b24gZmlyc3QgaW5zdGFsbHMgdGhlc2UgcnVsZXMNCj4gYW5kIHRoZW4gZmlsdGVyIGluY29taW5n IHJlcXVlc3RzIHRvIGVuZm9yY2UgYWN0aW9ucyBvbiBhcHByb3ByaWF0ZQ0KPiByZXF1ZXN0cywg Zm9yIGV4YW1wbGUsIGxpbWl0aW5nIHRoZSBzZW5kaW5nIHJhdGUgb2YgY2FsbCByZXF1ZXN0cw0K PiBkZXN0aW5lZCBmb3IgYSBzcGVjaWZpYyBTSVAgZW50aXR5LiINCj4gPg0KPiA+IFdpdGgNCj4g Pg0KPiA+ICJBIHN1YnNjcmliZXIgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRpb24gZmlyc3QgaW5z dGFsbHMgdGhlc2UgcnVsZXMNCj4gYW5kIHRoZW4gZmlsdGVyIG91dGdvaW5nIHJlcXVlc3RzIHRv d2FyZHMgdGhlIG5vdGlmaWVyIHRvIGVuZm9yY2UNCj4gYWN0aW9ucyBvbiBhcHByb3ByaWF0ZSBy ZXF1ZXN0cywgZm9yIGV4YW1wbGUsIGxpbWl0aW5nIHRoZSBzZW5kaW5nIHJhdGUNCj4gb2YgY2Fs bCByZXF1ZXN0cyBkZXN0aW5lZCBmb3IgYSBzcGVjaWZpYyBTSVAgZW50aXR5LiINCj4gPg0KPiA+ IFRoaXMgd291bGQgaG93ZXZlciBub3QgcGVybWl0IHRoZSB1c2Ugb2YgZXh0ZXJuYWwgc3RhdGUg YWdlbnRzIGFzDQo+IGRlc2NyaWJlZCBpbiBzZWN0aW9uIDUuMTIuIFRoZXJlZm9yZSBpdCBzZWVt cyB0aGF0IGEgInRhcmdldCBzaXAgZW50aXR5Ig0KPiBwYXJhbWV0ZXIgc2hvdWxkIGJlIGFkZGVk IHRvIG92ZXJsb2FkIGNvbnRyb2wgZG9jdW1lbnRzLg0KPiA+DQo+IA0KPiBJIHRoaW5rIEkgbWln aHQgaGF2ZSBub3QgdW5kZXJzdG9vZCB5b3VyIHBvaW50LiBUaGUgcmVxdWVzdHMgYXJlDQo+IGZp bHRlcmVkIGJhc2VkIG9uIHRoZSBjYWxsIGlkZW50aXRpZXMsIHdoaWNoIGNhbiBjb252ZXkgaW5m b3JtYXRpb24NCj4gaW5jbHVkaW5nIHRoZSBjYWxsIGRlc3RpbmF0aW9uLiBDb3VsZCB5b3UgZWxh Ym9yYXRlIHdoYXQgdGhpcyAidGFyZ2V0DQo+IHNpcCBlbnRpdHkiIGlzIGV4YWN0bHkgZm9yPw0K W0JDXSANCg0KTGV0J3MgdGFrZSB0d28gZXhhbXBsZXMgdGhhdCBJIHRoaW5rIGFyZSBub3QgY292 ZXJlZCBieSB0aGUgY3VycmVudCB3b3JkaW5nLiANCg0KMSkgRXhhbXBsZSAxDQoNCkNhbGwgY29u ZmlndXJhdGlvbjogQSBpcyBjb25uZWN0ZWQgc28gU1AxLCBCIGlzIGNvbm5lY3RlZCB0byBTUDIu IFNQMSBhbmQgU1AyIGFyZSBjb25uZWN0ZWQgdmlhIFNQMy4gU1AzIGlzIGNvbm5lY3RlZCB0byBh biBBcHBsaWNhdGlvbiBTZXJ2ZXIgKEFTKS4gVW5kZXIgbm9ybWFsIGxvYWQgY29uZGl0aW9ucywg YSBjYWxsIGZyb20gQSB0byBCIGlzIHJvdXRlZCBhbG9uZyB0aGUgZm9sbG93aW5nIHBhdGg6IEEt U1AxLVNQMy1BUy1TUDItQi4gVGhlIEFTIHByb3ZpZGVzIGEgbm9uLWVzc2VudGlhbCBzZXJ2aWNl IGFuZCBjYW4gYmUgYnlwYXNzZWQgaW4gY2FzZSBvZiBvdmVybG9hZC4NCg0KTm93IGxldCdzIGFz c3VtZSB0aGF0IEFTIGlzIG92ZXJsb2FkZWQgYW5kIHNlbmRzIHRvIFNQMyBhIGZpbHRlciByZXF1 ZXN0aW5nIHRoYXQgNTAlIG9mIElOVklURSBtZXNzYWdlcyBiZSBkcm9wcGVkLCByZWdhcmRsZXNz IG9mIHRoZSBjb250ZW50cyBvZiB0aGUgZnJvbS90by9QQUkvUi1VUkkuDQoNCkFjY29yZGluZyB0 byB0aGUgY3VycmVudCB3b3JkaW5nLCBTUDMgd2lsbCBpbmRlZWQgZmlsdGVyIDUwJSBvZiB0aGUg SU5WSVRFIHJlcXVlc3RzIHdoaWxlIHRoZXkgY291bGQgYmUgcm91dGVkIHRvIEIgdmlhIFNQMi4N Cg0KMikgRXhhbXBsZSAyDQoNCkNhbGwgQ29uZmlndXJhdGlvbjogQW4gODAwIHRyYW5zbGF0aW9u IHNlcnZpY2UgaXMgaW5zdGFsbGVkIG9uIHR3byBBcHBsaWNhdGlvbiBTZXJ2ZXJzIEFTLTEgYW5k IEFTLTIuIEEgaXMgY29ubmVjdGVkIHRvIFNQMSBhbmQgY2FsbHMgODAwIDEyMzQgNDUyOSwgd2hp Y2ggaXMgdHJhbnNsYXRlZCBieSBBUy0xIGFuZCBBUy0yIGludG8gYSByZWd1bGFyIEUxNjQgbnVt YmVyLCBkZXBlbmRpbmcgb24gZS5nLiB0aGUgY2FsbGVyJ3MgbG9jYXRpb24uIFNQMSBmb3J3YXJk cyBJTlZJVEUgcmVxdWVzdHMgd2l0aCBSLVVSSSA9ICI4MDAgbnVtYmVyIiB0byBBUy0xIG9yIEFT LTIgYmFzZWQgb24gYSBsb2FkIGJhbGFuY2luZyBzdHJhdGVneS4NCg0KQXMgY2FsbHMgdG8gODAw IDEyMzQgNDUyOSBjcmVhdGVzIGEgcHJlLW92ZXJsb2FkIGNvbmRpdGlvbiBpbiBBUy0xLCBBUy0x IHNlbmRzIHRvIFNQLTEgYSBmaWx0ZXIgcmVxdWVzdGluZyB0aGF0IDUwJSBvZiBjYWxscyB0b3dh cmRzIDgwMCAxMjM0IDQ1MjkgYmUgcmVqZWN0ZWQuDQoNCkFjY29yZGluZyB0byB0aGUgY3VycmVu dCB3b3JkaW5nLCBTUDMgd2lsbCBhcHBseSB0aGUgZmlsdGVyIG9uIGluY29taW5nIElOVklURSBy ZXF1ZXN0cywgaXJyZXNwZWN0aXZlIG9mIHdoZXRoZXIgdGhleSBhcmUgaW50ZW5kZWQgdG8gYmUg c2VudCB0byBBUzEgb3IgQVMyLg0KDQo9PT4gSXQgc2VlbXMgdGhhdCB0aGVzZSB1c2UgY2FzZXMg Y291bGQgYmUgc29sdmVkIGJ5IGFwcGx5aW5nIHRoZSBmaWx0ZXJzIHRvIG91dGdvaW5nIHJlcXVl c3RzIChub3QgaW5jb21pbmcgcmVxdWVzdHMpIHRoYXQgYXJlIHRvIGJlIHJvdXRlZCB0byB0aGUg QVMgdGhhdCBzZW50IHRoZXNlIGZpbHRlcnMuIFRoaXMgbWVhbnMgdGhhdCB0aGUgU1AgaGFzIHRv IHN0b3JlIHRoZSBBUyBhZGRyZXNzIHRvZ2V0aGVyIHdpdGggdGhlIHJlY2VpdmVkIGZpbHRlcnMg b3IgdGhpcyBhZGRyZXNzIGhhcyB0byBiZSBpbmNsdWRlZCBleHBsaWNpdGx5IGFzIGEgbmV3IGZp bHRlciBjcml0ZXJpYS4NCiANCj4gDQo+IA0KPiA+IDUpIFNlY3Rpb24gNi4zLjEsIGxvY2FsIG51 bWJlciBncm91cGluZzoNCj4gPg0KPiA+IFRoZSBwcm9wb3NlZCBzb2x1dGlvbiBmb3IgbG9jYWwg bnVtYmVycyBpcyBub3Qgc3VpdGFibGUuIEZvciBleGFtcGxlLA0KPiBpZiB0aGUgcGhvbmUtY29u dGV4dCBmb3Igc2hvcnQgc2VydmljZSBudW1iZXJzIGluIGEgY291bnRyeSBpcyB0aGUNCj4gY291 bnRyeSBjb2RlLCB0aGUgc29sdXRpb24gZG9lcyBub3QgcGVybWl0IHRvIGRlZmluZSBhIGZpbHRl ciB0aGF0DQo+IGV4Y2x1ZGVzIGFsbCBFLjE2NCBudW1iZXJzIGluIHRoYXQgY291bnRyeSBidXQg cmV0YWluIGFsbCBzaG9ydCBzZXJ2aWNlDQo+IG51bWJlcnMuIEkgdGhpbmsgd2Ugc2hvdWxkIGVp dGhlciBkZWZpbmUgYW5vdGhlciBzb2x1dGlvbiBvciBzdGF0ZSB0aGF0DQo+IGdyb3VwaW5nIG9m IGxvY2FsIG51bWJlcnMgaXMgbm90IHN1cHBvcnRlZCBvciBzdGF0ZSB0aGF0IGdyb3VwaW5nIG9m DQo+IGxvY2FsIG51bWJlcnMgb25seSB3b3JrcyB1bmRlciBzcGVjaWZpYyBhc3N1bXB0aW9ucyBv biB0aGUgdXNlIG9mIHBob25lLQ0KPiBjb250ZXh0IHZhbHVlcy4NCj4gPg0KPiANCj4gSG93IGFi b3V0IGFkZGluZyB0aGUgZm9sbG93aW5nIHRleHQ/DQo+IA0KPiBJdCBzaG91bGQgYmUgbm90ZWQg dGhhdCB0aGUgbWV0aG9kIG9mIGdyb3VwaW5nIGxvY2FsIG51bWJlcnMgYXMNCj4gZGVmaW5lZCBp biB0aGlzIGRvY3VtZW50IGRvZXMgbm90IHN1cHBvcnQgYWxsIGNhc2VzLiBGb3IgZXhhbXBsZSwg aWYNCj4gdGhlIHBob25lLWNvbnRleHQgZm9yIHNob3J0IHNlcnZpY2UgbnVtYmVycyBpbiBhIGNv dW50cnkgaXMgdGhlDQo+IGNvdW50cnkgY29kZSwgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBwZXJt aXQgdG8gZGVmaW5lIGEgZmlsdGVyIHRoYXQNCj4gZXhjbHVkZXMgYWxsIEUuMTY0IG51bWJlcnMg aW4gdGhhdCBjb3VudHJ5IGJ1dCByZXRhaW4gYWxsIHNob3J0DQo+IHNlcnZpY2UgbnVtYmVycy4g QSBjb21wbGV0ZSBzb2x1dGlvbiBmb3IgbG9jYWwgbnVtYmVyIGdyb3VwaW5nDQo+IHJlcXVpcmVz IGEgc2VwYXJhdGUgbWV0aG9kIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQpb QkNdIA0KDQpMb29rcyBPSyBmb3IgbWUuDQoNCg0KPiANCj4gDQo+IFRoYW5rcyENCj4gDQo+IENo YXJsZXMNCj4gDQo+IA0KPiBPbiBXZWQsIEp1bCAxMSwgMjAxMiBhdCAzOjMzIEFNLCAgPGJydW5v LmNoYXRyYXNAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4gSGkhDQo+ID4NCj4gPiBIZXJlIGFyZSBt eSBjb21tZW50cyBhYm91dCB0aGlzIEktRC4NCj4gPg0KPiA+IDEpIFNlY3Rpb24gNC4zLCBtb3Zl IHBhcmFncmFwaCA3IChsaW5lIDM3NiAtIDM4NikgYWZ0ZXIgcGFyYWdyYXBoIDUNCj4gKGkuZS4g YWZ0ZXIgbGluZSAzNjApIGFuZCBtb2RpZmllcyB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBhcyBm b2xsb3dzOg0KPiA+DQo+ID4gIkluIHRoZSBhYm92ZSBjYXNlLCB0aGUgbmV0d29yayBlbnRpdHkg d2hlcmUgbG9hZCBmaWx0ZXJpbmcgcG9saWN5IGlzDQo+IGZpcnN0IGludHJvZHVjZWQgaXMgdGhl IFNJUCBzZXJ2ZXIgcHJvdmlkaW5nIGFjY2VzcyB0byB0aGUgcmVzb3VyY2UgdGhhdA0KPiBjcmVh dGVzIHRoZSBvdmVybG9hZCBjb25kaXRpb24uIEluIG90aGVyIGNhc2VzLCB0aGUgbmV0d29yayBl bnRyeSBwb2ludA0KPiBvZiBsb2FkIGZpbHRlcmluZyBwb2xpY3kgY291bGQgYWxzbyBiZSBhbiBl bnRpdHkgdGhhdCBob3N0cyB0aGlzDQo+IHJlc291cmNlLiAiDQo+ID4NCj4gPiAyKSBTZWN0aW9u IDUuOCwgbGluZSA1MjUtNTI4DQo+ID4NCj4gPiBUaGUgY3VycmVudCB0ZXh0IHN1Z2dlc3RzIHRo YXQgaW5jb21pbmcgcmVxdWVzdHMgYXJlIGZpbHRlcmVkDQo+IGlycmVzcGVjdGl2ZSBvZiB0aGVp ciBhY3R1YWwgZGVzdGluYXRpb24uIFRoZSBzdWJzY3JpYmVyIHNob3VsZCByYXRoZXINCj4gYXBw bHkgZmlsdGVycyBvbiByZXF1ZXN0cyB0aGF0IGFyZSBvdXRnb2luZyB0byB0aGUgcHJlLW92ZXJs b2FkZWQNCj4gZGVzdGluYXRpb24uIE9uZSBzb2x1dGlvbiB3b3VsZCBiZSB0byByZXBocmFzZSB0 aGUgZm9sbG93aW5nIHRleHQ6DQo+ID4NCj4gPiAiQSBzdWJzY3JpYmVyIHJlY2VpdmluZyB0aGUg bm90aWZpY2F0aW9uIGZpcnN0IGluc3RhbGxzIHRoZXNlIHJ1bGVzDQo+IGFuZCB0aGVuIGZpbHRl ciBpbmNvbWluZyByZXF1ZXN0cyB0byBlbmZvcmNlIGFjdGlvbnMgb24gYXBwcm9wcmlhdGUNCj4g cmVxdWVzdHMsIGZvciBleGFtcGxlLCBsaW1pdGluZyB0aGUgc2VuZGluZyByYXRlIG9mIGNhbGwg cmVxdWVzdHMNCj4gZGVzdGluZWQgZm9yIGEgc3BlY2lmaWMgU0lQIGVudGl0eS4iDQo+ID4NCj4g PiBXaXRoDQo+ID4NCj4gPiAiQSBzdWJzY3JpYmVyIHJlY2VpdmluZyB0aGUgbm90aWZpY2F0aW9u IGZpcnN0IGluc3RhbGxzIHRoZXNlIHJ1bGVzDQo+IGFuZCB0aGVuIGZpbHRlciBvdXRnb2luZyBy ZXF1ZXN0cyB0b3dhcmRzIHRoZSBub3RpZmllciB0byBlbmZvcmNlDQo+IGFjdGlvbnMgb24gYXBw cm9wcmlhdGUgcmVxdWVzdHMsIGZvciBleGFtcGxlLCBsaW1pdGluZyB0aGUgc2VuZGluZyByYXRl DQo+IG9mIGNhbGwgcmVxdWVzdHMgZGVzdGluZWQgZm9yIGEgc3BlY2lmaWMgU0lQIGVudGl0eS4i DQo+ID4NCj4gPiBUaGlzIHdvdWxkIGhvd2V2ZXIgbm90IHBlcm1pdCB0aGUgdXNlIG9mIGV4dGVy bmFsIHN0YXRlIGFnZW50cyBhcw0KPiBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjEyLiBUaGVyZWZv cmUgaXQgc2VlbXMgdGhhdCBhICJ0YXJnZXQgc2lwIGVudGl0eSINCj4gcGFyYW1ldGVyIHNob3Vs ZCBiZSBhZGRlZCB0byBvdmVybG9hZCBjb250cm9sIGRvY3VtZW50cy4NCj4gPg0KPiA+IDMpIFNl Y3Rpb24gNS44LCBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0IChhZGFwdGVkIGZyb20gZHJhZnQtaWV0 Zi1zb2MtDQo+IG92ZXJsb2FkLWNvbnRyb2wpIGFmdGVyIGxpbmUgNTM3Og0KPiA+DQo+ID4gIldo ZW4gZW5mb3JjaW5nIGFjdGlvbnMgb24gcmVxdWVzdHMgbWF0Y2hpbmcgdGhlIGZpbHRlcnMsIHN1 YnNjcmliZXJzDQo+IFNIT1VMRCBob25vciB0aGUgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXpp bmcgU0lQIHJlcXVlc3RzIHN1Y2ggYXMNCj4gcG9saWNpZXMgYmFzZWQgb24gdGhlIGNvbnRlbnQg b2YgdGhlIFJlc291cmNlLVByaW9yaXR5IGhlYWRlciAoUlBILA0KPiBSRkM0NDEyIFtSRkM0NDEy XSkuICBTcGVjaWZpYyAobmFtZXNwYWNlLnZhbHVlKSBSUEggY29udGVudHMgbWF5DQo+IGluZGlj YXRlIGhpZ2ggcHJpb3JpdHkgcmVxdWVzdHMgdGhhdCBzaG91bGQgYmUgIHByZXNlcnZlZCBhcyBt dWNoIGFzDQo+IHBvc3NpYmxlIGR1cmluZyBvdmVybG9hZC4gIFRoZSBSUEggY29udGVudHMgY2Fu IGFsc28gaW5kaWNhdGUgYSBsb3ctDQo+IHByaW9yaXR5IHJlcXVlc3QgdGhhdCBpcyBlbGlnaWJs ZSB0byBiZSBkcm9wcGVkIGR1cmluZyB0aW1lcyBvZiBvdmVybG9hZC4NCj4gT3RoZXIgaW5kaWNh dG9ycywgc3VjaCBhcyB0aGUgU09TIFVSTiBbUkZDNTAzMV0gaW5kaWNhdGluZyBhbiBlbWVyZ2Vu Y3kNCj4gcmVxdWVzdCwgbWF5IGFsc28gYmUgdXNlZCBmb3IgcHJpb3JpdGl6YXRpb24uIg0KPiA+ DQo+ID4gNCkgU2VjdGlvbiA2LjMuMSwgbWF0Y2hpbmcgaWRlbnRpdGllczogQWZ0ZXIgbGluZSA2 OTksIGFkZCB0aGUNCj4gZm9sbG93aW5nIHRleHQ6DQo+ID4NCj4gPiAiQmVmb3JlIGV2YWx1YXRp bmcgY2FsbC1pZGVudGl0eSBjb25kaXRpb25zLCB0aGUgc3Vic2NyaWJlciBzaGFsbA0KPiBjb252 ZXJ0IFVSSXMgcmVjZWl2ZWQgaW4gU0lQIGhlYWRlciBmaWVsZHMgaW4gY2Fub25pY2FsIGZvcm0g YXMgcGVyIFJGQw0KPiAzMjYxLCBleGNlcHQgdGhhdCB0aGUgcGhvbmUtY29udGV4dCBwYXJhbWV0 ZXIgc2hhbGwgbm90IGJlIHJlbW92ZWQsIGlmDQo+IHByZXNlbnQuIg0KPiA+DQo+ID4gNSkgU2Vj dGlvbiA2LjMuMSwgbG9jYWwgbnVtYmVyIGdyb3VwaW5nOg0KPiA+DQo+ID4gVGhlIHByb3Bvc2Vk IHNvbHV0aW9uIGZvciBsb2NhbCBudW1iZXJzIGlzIG5vdCBzdWl0YWJsZS4gRm9yIGV4YW1wbGUs DQo+IGlmIHRoZSBwaG9uZS1jb250ZXh0IGZvciBzaG9ydCBzZXJ2aWNlIG51bWJlcnMgaW4gYSBj b3VudHJ5IGlzIHRoZQ0KPiBjb3VudHJ5IGNvZGUsIHRoZSBzb2x1dGlvbiBkb2VzIG5vdCBwZXJt aXQgdG8gZGVmaW5lIGEgZmlsdGVyIHRoYXQNCj4gZXhjbHVkZXMgYWxsIEUuMTY0IG51bWJlcnMg aW4gdGhhdCBjb3VudHJ5IGJ1dCByZXRhaW4gYWxsIHNob3J0IHNlcnZpY2UNCj4gbnVtYmVycy4g SSB0aGluayB3ZSBzaG91bGQgZWl0aGVyIGRlZmluZSBhbm90aGVyIHNvbHV0aW9uIG9yIHN0YXRl IHRoYXQNCj4gZ3JvdXBpbmcgb2YgbG9jYWwgbnVtYmVycyBpcyBub3Qgc3VwcG9ydGVkIG9yIHN0 YXRlIHRoYXQgZ3JvdXBpbmcgb2YNCj4gbG9jYWwgbnVtYmVycyBvbmx5IHdvcmtzIHVuZGVyIHNw ZWNpZmljIGFzc3VtcHRpb25zIG9uIHRoZSB1c2Ugb2YgcGhvbmUtDQo+IGNvbnRleHQgdmFsdWVz Lg0KPiA+DQo+ID4gNikgU2VjdGlvbiA2LjMuMSwgbGluZSA3NDYgLSA3NTMsIHJlbW92ZSB0aGUg bGFzdCBidXQgb25lIHNlbnRlbmNlIGFuZA0KPiByZXdvcmQgdGhlIHJlc3Qgb2YgdGhlIHRleHQg YWNjb3JkaW5nbHkuIFJlYXNvbjogVGhlIHVzZSBvZiBsb2NhbCBudW1iZXINCj4gJ3RlbCcgVVJJ IGluIHRoZSBSLVVSSSBhbmQgVG8gaGVhZGVyIGZpZWxkIGlzIG5vdCByYXJlLiBJbiBzZXZlcmFs DQo+IGNvdW50cmllcywgc2hvcnQgbnVtYmVycyBhcmUgdXNlZCBxdWl0ZSBleHRlbnNpdmVseSB0 byBhY2Nlc3Mgc3BlY2lhbA0KPiBzZXJ2aWNlcy4NCj4gPg0KPiA+ICJTZWNvbmQsIHVzZSBvZiB0 aGUgbG9jYWwgbnVtYmVyICd0ZWwnIFVSSSBpbiBwcmFjdGljZSBpcyBleHBlY3RlZCB0bw0KPiBi ZSByYXJlLiINCj4gPg0KPiA+IDcpIENsYXVzZSA2LjMuMywgYWZ0ZXIgbGluZSA4MDAsIGFkZDoN Cj4gPg0KPiA+ICJTVUJTQ1JJQkUgcmVxdWVzdHMgYXJlIG5vdCBmaWx0ZXJlZCBpZiB0aGUgZXZl bnQtdHlwZSBoZWFkZXIgZmllbGQNCj4gaW5kaWNhdGVzIHRoZSBldmVudCBwYWNrYWdlIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudC4iDQo+ID4NCj4gPiA4KSBTZWN0aW9uIDcsIGxpbmUgOTg1IC0g OTkwOiByZXBsYWNlICJjYWxsIHR5cGUiIHdpdGggImNhbGwgaWRlbnRpdHkNCj4gdHlwZSIgKDMg dGltZXMpDQo+ID4NCj4gPiA5KSBTZWN0aW9uIDguMQ0KPiA+DQo+ID4gTGluZSAxMDQ4LCBhZGQg ImV4Y2VwdCBpbiBzcGVjaWZpYyBjYXNlcyB3aGVuIHRoZSBJbnRlbGxpZ2VudCBOZXR3b3JrDQo+ IGFyY2hpdGVjdHVyZSBpcyB1c2VkIFtBSU5HUl0uDQo+ID4NCj4gPiBMaW5lIDEwNjAsIHJlbW92 ZSB0aGUgbGFzdCBwYXJ0IG9mIHRoZSBmaXJzdCBzZW50ZW5jZSBzdGFydGluZyB3aXRoDQo+ICJh bmQgdGhlIG51bWJlciBvZiBwcmVmaXggdG8gYmUgbWF0Y2hlZC4iOiBJVFUgSU4gc3BlY2lmaWNh dGlvbnMgYWxsb3cNCj4gZm9yIGR5bmFtaWMgc2V0cy4NCj4gPg0KPiA+IExpbmUgMTA2OCwgcmVt b3ZlIHRoZSBsYXN0IHBhcnQgb2YgdGhlIGZpcnN0IHNlbnRlbmNlIHN0YXJpbmcgd2l0aA0KPiAi d2l0aCBhIGZpeGVkIHNldC4iOiBSZWFzb246IElUVSBJTiBzcGVjaWZpY2F0aW9ucyBhbGxvdyBm b3IgZHluYW1pYw0KPiBzZXRzLg0KPiA+DQo+ID4gMTApICAgICAgICAgIE1pc2NlbGxhbmVvdXMg cG9pbnRzDQo+ID4gU2VjdGlvbiAxLCBsaW5lIDEwNiwgcmVwbGFjZSBSRkMzMjY1IHdpdGggUkZD MzI2MQ0KPiA+IFNlY3Rpb24gNC4xLCBsaW5lIDIzMSwgcmVwbGFjZSAicHJveHkiIHdpdGggIm5v ZGUiICh0aGlzIHRleHQgc2hvdWxkDQo+IGFwcGx5IHRvIGFueSB0eXBlIG9mIFNJUCBlbnRpdHkp DQo+ID4gU2VjdGlvbiA0LjMsIGxpbmUgMjY1LCByZXBsYWNlICJwcm94eSIgd2l0aCAibm9kZSIg KHRoaXMgdGV4dCBzaG91bGQNCj4gYXBwbHkgdG8gYW55IHR5cGUgb2YgU0lQIGVudGl0eSkNCj4g PiBTZWN0aW9uIDQuMywgTGluZSAzNDEsIHJlcGxhY2UgInNpbmdsaW5nIiB3aXRoICJzaWduYWxp bmciDQo+ID4gU2VjdGlvbiA0LjMsIExpbmUgMzQyLCByZXBsYWNlICJhbGwgc2lnbmFsaW5nIHJl bGF0aW9uc2hpcCBpbiBGaWd1cmUgMQ0KPiBpcyIgd2l0aCAiYWxsIHNpZ25hbGluZyByZWxhdGlv bnNoaXBzIGluIEZpZ3VyZSAxIGFyZSINCj4gPiBTZWN0aW9uIDUuNiwgTGluZSA1MDMsIGFkZCAi cmVxdWVzdCIgYWZ0ZXIgIlNVQlNDUklCRSINCj4gPiBTZWN0aW9uIDUuMTEsIExpbmUgNTg1LCBy ZW1vdmUgImlzIg0KPiA+IFNlY3Rpb24gNi41LCBMaW5lIDg1MSwgcmVwbGFjZSAidmxpYWQiIHdp dGggInZhbGlkIg0KPiA+DQo+ID4gQnJ1bm8NCj4gPg0KPiA+DQo+ID4+IC0tLS0tTWVzc2FnZSBk J29yaWdpbmUtLS0tLQ0KPiA+PiBEZSA6IHNpcC1vdmVybG9hZC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86c2lwLW92ZXJsb2FkLQ0KPiBib3VuY2VzQGlldGYub3JnXQ0KPiA+PiBEZSBsYSBwYXJ0 IGRlIFNhbHZhdG9yZSBMb3JldG8NCj4gPj4gRW52b3nDqSA6IGx1bmRpIDIganVpbGxldCAyMDEy IDIxOjA5DQo+ID4+IMOAIDogc2lwLW92ZXJsb2FkQGlldGYub3JnDQo+ID4+IENjIDogVm9sa2Vy IEhpbHQNCj4gPj4gT2JqZXQgOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1v bG9hZC1jb250cm9sLWV2ZW50LQ0KPiBwYWNrYWdlDQo+ID4+DQo+ID4+IFthcyBjaGFpcl0NCj4g Pj4NCj4gPj4gYmFzZWQgb24gdGhlIG1haWxpbmcgbGlzdCBkaXNjdXNzaW9uIGFuZCB0aGUgb25l IHdlIGhhZCBkdXJpbmcgdGhlDQo+IGxhc3QNCj4gPj4gU29DIGYyZiBtZWV0aW5nIGluIFBhcmlz LA0KPiA+PiB0aGUgY2hhaXJzIHRoaW5rIHRoZSBkcmFmdC1pZXRmLXNvYy1vbG9hZC1jb250cm9s LWV2ZW50LXBhY2thZ2UgaXMNCj4gcmVhZHkNCj4gPj4gZm9yIHRoZSBXR0xDLg0KPiA+Pg0KPiA+ PiBUb2RheSB3ZSBhcmUgc3RhcnRpbmcgYSB0d28td2VlayB3b3JraW5nIGdyb3VwIGxhc3QgY2Fs bC4NCj4gPj4gVGhpcyBjYWxsIGVuZHMgb24gV2VkbmVzZGF5LCBKdWx5IDE2dGguDQo+ID4+DQo+ ID4+IHRoZSBsYXN0IHZlcnNpb24gb2YgdGhlIGRvY3VtZW50IGNhbiBiZSByZXRyaWV2ZWQgaGVy ZToNCj4gPj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zb2MtbG9hZC1j b250cm9sLWV2ZW50LXBhY2thZ2UtDQo+IDAzDQo+ID4+DQo+ID4+DQo+ID4+IHJldmlld3MgYW5k IGNvbW1lbnRzIGFyZSByZWFsbHkgYXBwcmVjaWF0ZSBhbmQgcmVxdWVzdGVkIGZyb20gYWxsIHRo ZQ0KPiA+PiBwYXJ0aWNpcGFudHMNCj4gPj4NCj4gPj4NCj4gPj4gY2hlZXJzDQo+ID4+IC9TYWwN Cj4gPj4NCj4gPj4gLS0NCj4gPj4gU2FsdmF0b3JlIExvcmV0bywgUGhEDQo+ID4+IHd3dy5zbG9y ZXRvLmNvbQ0KPiA+Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+PiBzaXAtb3ZlcmxvYWQgbWFpbGluZyBsaXN0DQo+ID4+IHNpcC1vdmVy bG9hZEBpZXRmLm9yZw0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcC1vdmVybG9hZA0KPiA+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPg0KPiA+IENlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cw0KPiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0K PiA+IHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXoNCj4gcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyDQo+ID4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzDQo+IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gPiBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYQ0KPiBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gPg0KPiA+IFRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQo+ID4gdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uDQo+ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZA0KPiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMuDQo+ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAt IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvcg0KPiBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4gVGhhbmsgeW91Lg0KPiA+DQo+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXAtb3Zl cmxvYWQgbWFpbGluZyBsaXN0DQo+ID4gc2lwLW92ZXJsb2FkQGlldGYub3JnDQo+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXAtb3ZlcmxvYWQNCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpD ZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZv cm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVj ZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVz IGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBj b25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0 ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVk IHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRl bGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From charles.newyork@gmail.com Tue Jul 17 22:37:11 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DD811E812E for ; Tue, 17 Jul 2012 22:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP0XANaXZbRt for ; Tue, 17 Jul 2012 22:37:09 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 03DBB11E8125 for ; Tue, 17 Jul 2012 22:37:08 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so915762vbb.31 for ; Tue, 17 Jul 2012 22:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5T9oyGsYFFS9vwGOZqzKW1BU5cs1dbyrpVHRzSZUiBQ=; b=0jOKOVkL/w2hgygjxB1UnakuHxqx94y+U6S008dsPVZMuXedIrGUW53BumfdcnhOHO ZuHTrh+WXFxI4QuSaHjvd6usExS5X7TB/XCl1Ih6XjyhtfTOlgalfnM/3WrMpP6OhNUw LAMPnhHiO2XaCBXtkqbH0+055AAyvKMppJEhYbSN6Dlra3+7DBwaoC8J0M2ND4KxqREs u7Fm0U0XhBrSK2nDV3L6vYjCWQu9TjZpeZV0v0D0Rjqe/o7Mc0ZrQywbz3maFq3clYUK O4ZkpxcEVW2+nKs4JV7Gkw0jVGlIkkgom7wFFsdHxD9EnJsgO1oTZuCTM8JMl1Icudxm hmxQ== Received: by 10.52.88.170 with SMTP id bh10mr2438258vdb.11.1342589877889; Tue, 17 Jul 2012 22:37:57 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.244.201 with HTTP; Tue, 17 Jul 2012 22:37:37 -0700 (PDT) In-Reply-To: <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: Charles Shen Date: Wed, 18 Jul 2012 01:37:37 -0400 X-Google-Sender-Auth: Y324gvaEMHJvZYs_2sCc8ZinDW8 Message-ID: To: "bruno.chatras@orange.com" Content-Type: multipart/alternative; boundary=20cf3071c86ec029ee04c5141051 Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 05:37:11 -0000 --20cf3071c86ec029ee04c5141051 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bruno, if i understand correctly it's essentially the multi-path/load balancing problem - you have multiple next-hop SIP entities through which you can route to the same destination. In that case it indeed seems that the filtering will have to be next hop specific. In the subscribe-notify w/o state agent case, the subscriber can record the corresponding notifier; in the state agent case, if the rule is inserted directly into a subscriber (instead of through a notifier), then the specific next hop will need to be explicitly defined. So are you suggesting we define a new element for the identity of "target SIP entity" (and is this a better term than, say "next-hop SIP entity"?). When applicable, it will contain the server name or IP address of the specific next hop SIP entity, and by default it can be null which means it applies to all next hop SIP entities? Thanks Charles On Tuesday, July 17, 2012, wrote: > Hi Charles, > > See below. > > > -----Message d'origine----- > > De : charles.newyork@gmail.com [mailto:charles.newyork@gmail.com] De la > > part de Charles Shen > > Envoy=C3=A9 : mardi 17 juillet 2012 18:37 > > =C3=80 : CHATRAS Bruno RD-CORE > > Cc : Salvatore Loreto; sip-overload@ietf.org; Volker Hilt; Henning > > Schulzrinne; Arata Koike > > Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event- > > package > > > > Hi Bruno, thank you so much for the detailed review and comments! I've > > addressed 8 out of the total 10, except the following two which I'd > > appreciate more clarification. > > > > > 2) Section 5.8, line 525-528 > > > > > > The current text suggests that incoming requests are filtered > > irrespective of their actual destination. The subscriber should rather > > apply filters on requests that are outgoing to the pre-overloaded > > destination. One solution would be to rephrase the following text: > > > > > > "A subscriber receiving the notification first installs these rules > > and then filter incoming requests to enforce actions on appropriate > > requests, for example, limiting the sending rate of call requests > > destined for a specific SIP entity." > > > > > > With > > > > > > "A subscriber receiving the notification first installs these rules > > and then filter outgoing requests towards the notifier to enforce > > actions on appropriate requests, for example, limiting the sending rate > > of call requests destined for a specific SIP entity." > > > > > > This would however not permit the use of external state agents as > > described in section 5.12. Therefore it seems that a "target sip entity= " > > parameter should be added to overload control documents. > > > > > > > I think I might have not understood your point. The requests are > > filtered based on the call identities, which can convey information > > including the call destination. Could you elaborate what this "target > > sip entity" is exactly for? > [BC] > > Let's take two examples that I think are not covered by the current > wording. > > 1) Example 1 > > Call configuration: A is connected so SP1, B is connected to SP2. SP1 and > SP2 are connected via SP3. SP3 is connected to an Application Server (AS)= . > Under normal load conditions, a call from A to B is routed along the > following path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essential servi= ce > and can be bypassed in case of overload. > > Now let's assume that AS is overloaded and sends to SP3 a filter > requesting that 50% of INVITE messages be dropped, regardless of the > contents of the from/to/PAI/R-URI. > > According to the current wording, SP3 will indeed filter 50% of the INVIT= E > requests while they could be routed to B via SP2. > > 2) Example 2 > > Call Configuration: An 800 translation service is installed on two > Application Servers AS-1 and AS-2. A is connected to SP1 and calls 800 12= 34 > 4529, which is translated by AS-1 and AS-2 into a regular E164 number, > depending on e.g. the caller's location. SP1 forwards INVITE requests wit= h > R-URI =3D "800 number" to AS-1 or AS-2 based on a load balancing strategy= . > > As calls to 800 1234 4529 creates a pre-overload condition in AS-1, AS-1 > sends to SP-1 a filter requesting that 50% of calls towards 800 1234 4529 > be rejected. > > According to the current wording, SP3 will apply the filter on incoming > INVITE requests, irrespective of whether they are intended to be sent to > AS1 or AS2. > > =3D=3D> It seems that these use cases could be solved by applying the fil= ters > to outgoing requests (not incoming requests) that are to be routed to the > AS that sent these filters. This means that the SP has to store the AS > address together with the received filters or this address has to be > included explicitly as a new filter criteria. > > > > > > > > 5) Section 6.3.1, local number grouping: > > > > > > The proposed solution for local numbers is not suitable. For example, > > if the phone-context for short service numbers in a country is the > > country code, the solution does not permit to define a filter that > > excludes all E.164 numbers in that country but retain all short service > > numbers. I think we should either define another solution or state that > > grouping of local numbers is not supported or state that grouping of > > local numbers only works under specific assumptions on the use of phone= - > > context values. > > > > > > > How about adding the following text? > > > > It should be noted that the method of grouping local numbers as > > defined in this document does not support all cases. For example, if > > the phone-context for short service numbers in a country is the > > country code, this solution does not permit to define a filter that > > excludes all E.164 numbers in that country but retain all short > > service numbers. A complete solution for local number grouping > > requires a separate method outside the scope of this document. > [BC] > > Looks OK for me. > > > > > > > > Thanks! > > > > Charles > > > > > > On Wed, Jul 11, 2012 at 3:33 AM, wrote: > > > Hi! > > > > > > Here are my comments about this I-D. > > > > > > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5 > > (i.e. after line 360) and modifies the first two sentences as follows: > > > > > > "In the above case, the network entity where load filtering policy is > > first introduced is the SIP server providing access to the resource tha= t > > creates the overload condition. In other cases, the network entry point > > of load filtering policy could also be an entity that hosts this > > resource. " > > > > > > 2) Section 5.8, line 525-528 > > > > > > The current text suggests that incoming requests are filtered > > irrespective of their actual destination. The subscriber should rather > > apply filters on requests that are outgoing to the pre-overloaded > > destination. One solution would be to rephrase the following text: > > > > > > "A subscriber receiving the notification first installs these rules > > and then filter incoming requests to enforce actions on appropriate > > requests, for example, limiting the sending rate of call requests > > destined for a specific SIP entity." > > > > > > With > > > > > > "A subscriber receiving the notification first installs these rules > > and then filter outgoing requests towards the notifier to enforce > > actions on appropriate requests, for example, limiting the sending rate > > of call requests destined for a specific SIP entity." > > > > > > This would however not permit the use of external state agents as > > described in section 5.12. Therefore it seems that a "target sip entity= " > > parameter should be added to overload control documents. > > > > > > 3) Section 5.8, add the following text (adapted from draft-ietf-soc- > > overload-control) after line 537: > > > > > > "When enforcing actions on requests matching the filters, subscribers > > SHOULD honor the local policy for prioritizing SIP requests such as > > policies based on the content of the Resource-Priority header (RPH, > > RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may > > indicate high priority requests that should be preserved as much as > > possible during overload. The RPH contents can also indicate a low- > > priority request that is eligible to be dropped during times of overloa= d. > > Other indicators, such as the SOS URN [RFC5031] indicating an emergency > > request, may also be used for prioritization." > > > > > > 4) Section 6.3.1, matching identities: After line 699, add the > > following text: > > > > > > "Before evaluating call-identity conditions, the subscriber shall > > convert URIs received in SIP header fields in canonical form as per RFC > > 3261, except that the phone-context parameter shall not be removed, if > > present." > > > > > > 5) Section 6.3.1, local number grouping: > > > > > > The proposed solution for local numbers is not suitable. For example, > > if the phone-context for short service numbers in a country is the > > country code, the solution does not permit to define a filter that > > excludes all E.164 numbers in that country but retain all short service > > numbers. I think we should either define another solution or state that > > grouping of local numbers is not supported or state that grouping of > > local numbers only works under specific assumptions on the use of phone= - > > context values. > > > > > > 6) Section 6.3.1, line 746 - 753, remove the last but one sentence an= d > > reword the rest of the text accordingly. Reason: The use of local numbe= r > > 'tel' URI in the R-URI and To header field is not rare. In several > > countries, short numbers are used quite extensively to access special > > services. > > > > > > "Second, use of the local number 'tel' URI in practice is expected to > > be rare." > > > > > > 7) Clause 6.3.3, after line 800, add: > > > > > > "SUBSCRIBE requests are not filtered if the event-type header field > > indicates the event package defined in this document." > > > > > > 8) Section 7, line 985 - 990: replace "call type" with "call identity --20cf3071c86ec029ee04c5141051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Bruno, =C2=A0if i understand correctly it's essentially the multi-pa= th/load balancing problem - you have multiple next-hop SIP entities through= which you can route to the same destination. In that case it indeed seems = that the filtering will have to be next hop specific. In the subscribe-noti= fy w/o state agent case, the subscriber can record the corresponding notifi= er; in the state agent case, if the rule is inserted directly into a subscr= iber (instead of through =C2=A0a notifier), then the specific next hop will= need to be explicitly defined.=C2=A0

So are you suggesting we define a new element for the identi= ty of "target SIP entity" (and is this a better term than, say &q= uot;next-hop SIP entity"?). When applicable, it will contain the serve= r name or IP address of the specific next hop SIP entity, and by default it= can be null which means it applies to all next hop SIP entities?=C2=A0

Thanks=C2=A0
=
Charles


On Tuesday, July 17, 2012, wrote:
Hi Charles,

See below.

> -----Message d'origine-----
> De=C2=A0: charles.newyork@gmail.com [mailto:charles.newyork@= gmail.com] De la
> part de Charles Shen
> Envoy=C3=A9=C2=A0: mardi 17 juillet 2012 18:37
> =C3=80=C2=A0: CHATRAS Bruno RD-CORE
> Cc=C2=A0: Salvatore Loreto; sip-overload@ietf.org; Volker Hilt;= Henning
> Schulzrinne; Arata Koike
> Objet=C2=A0: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-eve= nt-
> package
>
> Hi Bruno, thank you so much for the detailed review and comments! I= 9;ve
> addressed 8 out of the total 10, except the following two which I'= d
> appreciate more clarification.
>
> > 2) Section 5.8, line 525-528
> >
> > The current text suggests that incoming requests are filtered
> irrespective of their actual destination. The subscriber should rather=
> apply filters on requests that are outgoing to the pre-overloaded
> destination. One solution would be to rephrase the following text:
> >
> > "A subscriber receiving the notification first installs thes= e rules
> and then filter incoming requests to enforce actions on appropriate > requests, for example, limiting the sending rate of call requests
> destined for a specific SIP entity."
> >
> > With
> >
> > "A subscriber receiving the notification first installs thes= e rules
> and then filter outgoing requests towards the notifier to enforce
> actions on appropriate requests, for example, limiting the sending rat= e
> of call requests destined for a specific SIP entity."
> >
> > This would however not permit the use of external state agents as=
> described in section 5.12. Therefore it seems that a "target sip = entity"
> parameter should be added to overload control documents.
> >
>
> I think I might have not understood your point. The requests are
> filtered based on the call identities, which can convey information > including the call destination. Could you elaborate what this "ta= rget
> sip entity" is exactly for?
[BC]

Let's take two examples that I think are not covered by the current wor= ding.

1) Example 1

Call configuration: A is connected so SP1, B is connected to SP2. SP1 and S= P2 are connected via SP3. SP3 is connected to an Application Server (AS). U= nder normal load conditions, a call from A to B is routed along the followi= ng path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essential service and ca= n be bypassed in case of overload.

Now let's assume that AS is overloaded and sends to SP3 a filter reques= ting that 50% of INVITE messages be dropped, regardless of the contents of = the from/to/PAI/R-URI.

According to the current wording, SP3 will indeed filter 50% of the INVITE = requests while they could be routed to B via SP2.

2) Example 2

Call Configuration: An 800 translation service is installed on two Applicat= ion Servers AS-1 and AS-2. A is connected to SP1 and calls 800 1234 4529, w= hich is translated by AS-1 and AS-2 into a regular E164 number, depending o= n e.g. the caller's location. SP1 forwards INVITE requests with R-URI = =3D "800 number" to AS-1 or AS-2 based on a load balancing strate= gy.

As calls to 800 1234 4529 creates a pre-overload condition in AS-1, AS-1 se= nds to SP-1 a filter requesting that 50% of calls towards 800 1234 4529 be = rejected.

According to the current wording, SP3 will apply the filter on incoming INV= ITE requests, irrespective of whether they are intended to be sent to AS1 o= r AS2.

=3D=3D> It seems that these use cases could be solved by applying the fi= lters to outgoing requests (not incoming requests) that are to be routed to= the AS that sent these filters. This means that the SP has to store the AS= address together with the received filters or this address has to be inclu= ded explicitly as a new filter criteria.

>
>
> > 5) Section 6.3.1, local number grouping:
> >
> > The proposed solution for local numbers is not suitable. For exam= ple,
> if the phone-context for short service numbers in a country is the
> country code, the solution does not permit to define a filter that
> excludes all E.164 numbers in that country but retain all short servic= e
> numbers. I think we should either define another solution or state tha= t
> grouping of local numbers is not supported or state that grouping of > local numbers only works under specific assumptions on the use of phon= e-
> context values.
> >
>
> How about adding the following text?
>
> It should be noted that the method of grouping local numbers as
> defined in this document does not support all cases. For example, if > the phone-context for short service numbers in a country is the
> country code, this solution does not permit to define a filter that > excludes all E.164 numbers in that country but retain all short
> service numbers. A complete solution for local number grouping
> requires a separate method outside the scope of this document.
[BC]

Looks OK for me.


>
>
> Thanks!
>
> Charles
>
>
> On Wed, Jul 11, 2012 at 3:33 AM, =C2=A0<bruno.chatras@orange.com= > wrote:
> > Hi!
> >
> > Here are my comments about this I-D.
> >
> > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph= 5
> (i.e. after line 360) and modifies the first two sentences as follows:=
> >
> > "In the above case, the network entity where load filtering = policy is
> first introduced is the SIP server providing access to the resource th= at
> creates the overload condition. In other cases, the network entry poin= t
> of load filtering policy could also be an entity that hosts this
> resource. "
> >
> > 2) Section 5.8, line 525-528
> >
> > The current text suggests that incoming requests are filtered
> irrespective of their actual destination. The subscriber should rather=
> apply filters on requests that are outgoing to the pre-overloaded
> destination. One solution would be to rephrase the following text:
> >
> > "A subscriber receiving the notification first installs thes= e rules
> and then filter incoming requests to enforce actions on appropriate > requests, for example, limiting the sending rate of call requests
> destined for a specific SIP entity."
> >
> > With
> >
> > "A subscriber receiving the notification first installs thes= e rules
> and then filter outgoing requests towards the notifier to enforce
> actions on appropriate requests, for example, limiting the sending rat= e
> of call requests destined for a specific SIP entity."
> >
> > This would however not permit the use of external state agents as=
> described in section 5.12. Therefore it seems that a "target sip = entity"
> parameter should be added to overload control documents.
> >
> > 3) Section 5.8, add the following text (adapted from draft-ietf-s= oc-
> overload-control) after line 537:
> >
> > "When enforcing actions on requests matching the filters, su= bscribers
> SHOULD honor the local policy for prioritizing SIP requests such as > policies based on the content of the Resource-Priority header (RPH, > RFC4412 [RFC4412]). =C2=A0Specific (namespace.value) RPH contents may<= br> > indicate high priority requests that should be =C2=A0preserved as much= as
> possible during overload. =C2=A0The RPH contents can also indicate a l= ow-
> priority request that is eligible to be dropped during times of overlo= ad.
> Other indicators, such as the SOS URN [RFC5031] indicating an emergenc= y
> request, may also be used for prioritization."
> >
> > 4) Section 6.3.1, matching identities: After line 699, add the > following text:
> >
> > "Before evaluating call-identity conditions, the subscriber = shall
> convert URIs received in SIP header fields in canonical form as per RF= C
> 3261, except that the phone-context parameter shall not be removed, if=
> present."
> >
> > 5) Section 6.3.1, local number grouping:
> >
> > The proposed solution for local numbers is not suitable. For exam= ple,
> if the phone-context for short service numbers in a country is the
> country code, the solution does not permit to define a filter that
> excludes all E.164 numbers in that country but retain all short servic= e
> numbers. I think we should either define another solution or state tha= t
> grouping of local numbers is not supported or state that grouping of > local numbers only works under specific assumptions on the use of phon= e-
> context values.
> >
> > 6) Section 6.3.1, line 746 - 753, remove the last but one sentenc= e and
> reword the rest of the text accordingly. Reason: The use of local numb= er
> 'tel' URI in the R-URI and To header field is not rare. In sev= eral
> countries, short numbers are used quite extensively to access special<= br> > services.
> >
> > "Second, use of the local number 'tel' URI in practi= ce is expected to
> be rare."
> >
> > 7) Clause 6.3.3, after line 800, add:
> >
> > "SUBSCRIBE requests are not filtered if the event-type heade= r field
> indicates the event package defined in this document."
> >
> > 8) Section 7, line 985 - 990: replace "call type" with = "call identity
--20cf3071c86ec029ee04c5141051-- From bruno.chatras@orange.com Wed Jul 18 02:53:18 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574F921F85C2 for ; Wed, 18 Jul 2012 02:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.365 X-Spam-Level: X-Spam-Status: No, score=-2.365 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZzLo96Zu7OI for ; Wed, 18 Jul 2012 02:53:16 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B546621F85B6 for ; Wed, 18 Jul 2012 02:53:15 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 47113324422; Wed, 18 Jul 2012 11:54:05 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 288284C015; Wed, 18 Jul 2012 11:54:05 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0298.004; Wed, 18 Jul 2012 11:54:02 +0200 From: To: Charles Shen Thread-Topic: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package Thread-Index: AQHNWIYghEHWjP/zI0+dx9hFlVmae5ctw8EPgADaL/2AAEZ5wA== Date: Wed, 18 Jul 2012 09:54:01 +0000 Message-ID: <32464_1342605245_500687BD_32464_3470_2_88CAD1D4E8773F42858B58CAA28272A004E786@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.5] Content-Type: multipart/alternative; boundary="_000_88CAD1D4E8773F42858B58CAA28272A004E786PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.7.18.51519 Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2012 09:53:18 -0000 --_000_88CAD1D4E8773F42858B58CAA28272A004E786PEXCVZYM12corpora_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hhcmxlcywNCg0KU2VlIGJlbG93DQoNClRoYW5rcw0KQkMNCg0KRGUgOiBjaGFybGVzLm5l d3lvcmtAZ21haWwuY29tIFttYWlsdG86Y2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNvbV0gRGUgbGEg cGFydCBkZSBDaGFybGVzIFNoZW4NCkVudm95w6kgOiBtZXJjcmVkaSAxOCBqdWlsbGV0IDIwMTIg MDc6MzgNCsOAIDogQ0hBVFJBUyBCcnVubyBSRC1DT1JFDQpDYyA6IFNhbHZhdG9yZSBMb3JldG87 IHNpcC1vdmVybG9hZEBpZXRmLm9yZzsgVm9sa2VyIEhpbHQ7IEhlbm5pbmcgU2NodWx6cmlubmU7 IEFyYXRhIEtvaWtlDQpPYmpldCA6IFJlOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRm LXNvYy1vbG9hZC1jb250cm9sLWV2ZW50LXBhY2thZ2UNCg0KSGkgQnJ1bm8sICBpZiBpIHVuZGVy c3RhbmQgY29ycmVjdGx5IGl0J3MgZXNzZW50aWFsbHkgdGhlIG11bHRpLXBhdGgvbG9hZCBiYWxh bmNpbmcgcHJvYmxlbSAtIHlvdSBoYXZlIG11bHRpcGxlIG5leHQtaG9wIFNJUCBlbnRpdGllcyB0 aHJvdWdoIHdoaWNoIHlvdSBjYW4gcm91dGUgdG8gdGhlIHNhbWUgZGVzdGluYXRpb24uIEluIHRo YXQgY2FzZSBpdCBpbmRlZWQgc2VlbXMgdGhhdCB0aGUgZmlsdGVyaW5nIHdpbGwgaGF2ZSB0byBi ZSBuZXh0IGhvcCBzcGVjaWZpYy4gSW4gdGhlIHN1YnNjcmliZS1ub3RpZnkgdy9vIHN0YXRlIGFn ZW50IGNhc2UsIHRoZSBzdWJzY3JpYmVyIGNhbiByZWNvcmQgdGhlIGNvcnJlc3BvbmRpbmcgbm90 aWZpZXI7IGluIHRoZSBzdGF0ZSBhZ2VudCBjYXNlLCBpZiB0aGUgcnVsZSBpcyBpbnNlcnRlZCBk aXJlY3RseSBpbnRvIGEgc3Vic2NyaWJlciAoaW5zdGVhZCBvZiB0aHJvdWdoICBhIG5vdGlmaWVy KSwgdGhlbiB0aGUgc3BlY2lmaWMgbmV4dCBob3Agd2lsbCBuZWVkIHRvIGJlIGV4cGxpY2l0bHkg ZGVmaW5lZC4NCg0KU28gYXJlIHlvdSBzdWdnZXN0aW5nIHdlIGRlZmluZSBhIG5ldyBlbGVtZW50 IGZvciB0aGUgaWRlbnRpdHkgb2YgInRhcmdldCBTSVAgZW50aXR5IiAoYW5kIGlzIHRoaXMgYSBi ZXR0ZXIgdGVybSB0aGFuLCBzYXkgIm5leHQtaG9wIFNJUCBlbnRpdHkiPykuIFdoZW4gYXBwbGlj YWJsZSwgaXQgd2lsbCBjb250YWluIHRoZSBzZXJ2ZXIgbmFtZSBvciBJUCBhZGRyZXNzIG9mIHRo ZSBzcGVjaWZpYyBuZXh0IGhvcCBTSVAgZW50aXR5LCBhbmQgYnkgZGVmYXVsdCBpdCBjYW4gYmUg bnVsbCB3aGljaCBtZWFucyBpdCBhcHBsaWVzIHRvIGFsbCBuZXh0IGhvcCBTSVAgZW50aXRpZXM/ DQpbQkNdIFllcyBhIG5ldyBlbGVtZW50IGluIHRoZSBmaWx0ZXIgd291bGQgZG8gdGhlIGpvYiBJ IGJlbGlldmUuIOKAnFRhcmdldCBTSVAgZW50aXR54oCdIHdvdWxkIGJlIG1vcmUgZ2VuZXJpYyB0 aGFuIOKAnE5leHQgSG9wIFNJUCBlbnRpdHnigJ0uIFRoZSBTSVAgY2xpZW50IHdvdWxkIG1hdGNo IGl0IHRvIHRoZSBmdWxsIGNvbnRlbnRzIG9mIHRoZSByb3V0ZSBoZWFkZXIgKGlmIGFueSksIG5v dCBqdXN0IHRvIHRoZSBuZXh0IGlkZW50aXR5IG9mIHRoZSBuZXh0IGhvcC4NCg0KVGhhbmtzDQoN CkNoYXJsZXMNCg0KDQoNCk9uIFR1ZXNkYXksIEp1bHkgMTcsIDIwMTIsIHdyb3RlOg0KSGkgQ2hh cmxlcywNCg0KU2VlIGJlbG93Lg0KDQo+IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLQ0KPiBE ZSA6IGNoYXJsZXMubmV3eW9ya0BnbWFpbC5jb20gW21haWx0bzpjaGFybGVzLm5ld3lvcmtAZ21h aWwuY29tXSBEZSBsYQ0KPiBwYXJ0IGRlIENoYXJsZXMgU2hlbg0KPiBFbnZvecOpIDogbWFyZGkg MTcganVpbGxldCAyMDEyIDE4OjM3DQo+IMOAIDogQ0hBVFJBUyBCcnVubyBSRC1DT1JFDQo+IENj IDogU2FsdmF0b3JlIExvcmV0bzsgc2lwLW92ZXJsb2FkQGlldGYub3JnOyBWb2xrZXIgSGlsdDsg SGVubmluZw0KPiBTY2h1bHpyaW5uZTsgQXJhdGEgS29pa2UNCj4gT2JqZXQgOiBSZTogW3NpcC1v dmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb2xvYWQtY29udHJvbC1ldmVudC0NCj4gcGFj a2FnZQ0KPg0KPiBIaSBCcnVubywgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHRoZSBkZXRhaWxlZCBy ZXZpZXcgYW5kIGNvbW1lbnRzISBJJ3ZlDQo+IGFkZHJlc3NlZCA4IG91dCBvZiB0aGUgdG90YWwg MTAsIGV4Y2VwdCB0aGUgZm9sbG93aW5nIHR3byB3aGljaCBJJ2QNCj4gYXBwcmVjaWF0ZSBtb3Jl IGNsYXJpZmljYXRpb24uDQo+DQo+ID4gMikgU2VjdGlvbiA1LjgsIGxpbmUgNTI1LTUyOA0KPiA+ DQo+ID4gVGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0IGluY29taW5nIHJlcXVlc3RzIGFy ZSBmaWx0ZXJlZA0KPiBpcnJlc3BlY3RpdmUgb2YgdGhlaXIgYWN0dWFsIGRlc3RpbmF0aW9uLiBU aGUgc3Vic2NyaWJlciBzaG91bGQgcmF0aGVyDQo+IGFwcGx5IGZpbHRlcnMgb24gcmVxdWVzdHMg dGhhdCBhcmUgb3V0Z29pbmcgdG8gdGhlIHByZS1vdmVybG9hZGVkDQo+IGRlc3RpbmF0aW9uLiBP bmUgc29sdXRpb24gd291bGQgYmUgdG8gcmVwaHJhc2UgdGhlIGZvbGxvd2luZyB0ZXh0Og0KPiA+ DQo+ID4gIkEgc3Vic2NyaWJlciByZWNlaXZpbmcgdGhlIG5vdGlmaWNhdGlvbiBmaXJzdCBpbnN0 YWxscyB0aGVzZSBydWxlcw0KPiBhbmQgdGhlbiBmaWx0ZXIgaW5jb21pbmcgcmVxdWVzdHMgdG8g ZW5mb3JjZSBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlDQo+IHJlcXVlc3RzLCBmb3IgZXhhbXBsZSwg bGltaXRpbmcgdGhlIHNlbmRpbmcgcmF0ZSBvZiBjYWxsIHJlcXVlc3RzDQo+IGRlc3RpbmVkIGZv ciBhIHNwZWNpZmljIFNJUCBlbnRpdHkuIg0KPiA+DQo+ID4gV2l0aA0KPiA+DQo+ID4gIkEgc3Vi c2NyaWJlciByZWNlaXZpbmcgdGhlIG5vdGlmaWNhdGlvbiBmaXJzdCBpbnN0YWxscyB0aGVzZSBy dWxlcw0KPiBhbmQgdGhlbiBmaWx0ZXIgb3V0Z29pbmcgcmVxdWVzdHMgdG93YXJkcyB0aGUgbm90 aWZpZXIgdG8gZW5mb3JjZQ0KPiBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlIHJlcXVlc3RzLCBmb3Ig ZXhhbXBsZSwgbGltaXRpbmcgdGhlIHNlbmRpbmcgcmF0ZQ0KPiBvZiBjYWxsIHJlcXVlc3RzIGRl c3RpbmVkIGZvciBhIHNwZWNpZmljIFNJUCBlbnRpdHkuIg0KPiA+DQo+ID4gVGhpcyB3b3VsZCBo b3dldmVyIG5vdCBwZXJtaXQgdGhlIHVzZSBvZiBleHRlcm5hbCBzdGF0ZSBhZ2VudHMgYXMNCj4g ZGVzY3JpYmVkIGluIHNlY3Rpb24gNS4xMi4gVGhlcmVmb3JlIGl0IHNlZW1zIHRoYXQgYSAidGFy Z2V0IHNpcCBlbnRpdHkiDQo+IHBhcmFtZXRlciBzaG91bGQgYmUgYWRkZWQgdG8gb3ZlcmxvYWQg Y29udHJvbCBkb2N1bWVudHMuDQo+ID4NCj4NCj4gSSB0aGluayBJIG1pZ2h0IGhhdmUgbm90IHVu ZGVyc3Rvb2QgeW91ciBwb2ludC4gVGhlIHJlcXVlc3RzIGFyZQ0KPiBmaWx0ZXJlZCBiYXNlZCBv biB0aGUgY2FsbCBpZGVudGl0aWVzLCB3aGljaCBjYW4gY29udmV5IGluZm9ybWF0aW9uDQo+IGlu Y2x1ZGluZyB0aGUgY2FsbCBkZXN0aW5hdGlvbi4gQ291bGQgeW91IGVsYWJvcmF0ZSB3aGF0IHRo aXMgInRhcmdldA0KPiBzaXAgZW50aXR5IiBpcyBleGFjdGx5IGZvcj8NCltCQ10NCg0KTGV0J3Mg dGFrZSB0d28gZXhhbXBsZXMgdGhhdCBJIHRoaW5rIGFyZSBub3QgY292ZXJlZCBieSB0aGUgY3Vy cmVudCB3b3JkaW5nLg0KDQoxKSBFeGFtcGxlIDENCg0KQ2FsbCBjb25maWd1cmF0aW9uOiBBIGlz IGNvbm5lY3RlZCBzbyBTUDEsIEIgaXMgY29ubmVjdGVkIHRvIFNQMi4gU1AxIGFuZCBTUDIgYXJl IGNvbm5lY3RlZCB2aWEgU1AzLiBTUDMgaXMgY29ubmVjdGVkIHRvIGFuIEFwcGxpY2F0aW9uIFNl cnZlciAoQVMpLiBVbmRlciBub3JtYWwgbG9hZCBjb25kaXRpb25zLCBhIGNhbGwgZnJvbSBBIHRv IEIgaXMgcm91dGVkIGFsb25nIHRoZSBmb2xsb3dpbmcgcGF0aDogQS1TUDEtU1AzLUFTLVNQMi1C LiBUaGUgQVMgcHJvdmlkZXMgYSBub24tZXNzZW50aWFsIHNlcnZpY2UgYW5kIGNhbiBiZSBieXBh c3NlZCBpbiBjYXNlIG9mIG92ZXJsb2FkLg0KDQpOb3cgbGV0J3MgYXNzdW1lIHRoYXQgQVMgaXMg b3ZlcmxvYWRlZCBhbmQgc2VuZHMgdG8gU1AzIGEgZmlsdGVyIHJlcXVlc3RpbmcgdGhhdCA1MCUg b2YgSU5WSVRFIG1lc3NhZ2VzIGJlIGRyb3BwZWQsIHJlZ2FyZGxlc3Mgb2YgdGhlIGNvbnRlbnRz IG9mIHRoZSBmcm9tL3RvL1BBSS9SLVVSSS4NCg0KQWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IHdv cmRpbmcsIFNQMyB3aWxsIGluZGVlZCBmaWx0ZXIgNTAlIG9mIHRoZSBJTlZJVEUgcmVxdWVzdHMg d2hpbGUgdGhleSBjb3VsZCBiZSByb3V0ZWQgdG8gQiB2aWEgU1AyLg0KDQoyKSBFeGFtcGxlIDIN Cg0KQ2FsbCBDb25maWd1cmF0aW9uOiBBbiA4MDAgdHJhbnNsYXRpb24gc2VydmljZSBpcyBpbnN0 YWxsZWQgb24gdHdvIEFwcGxpY2F0aW9uIFNlcnZlcnMgQVMtMSBhbmQgQVMtMi4gQSBpcyBjb25u ZWN0ZWQgdG8gU1AxIGFuZCBjYWxscyA4MDAgMTIzNCA0NTI5LCB3aGljaCBpcyB0cmFuc2xhdGVk IGJ5IEFTLTEgYW5kIEFTLTIgaW50byBhIHJlZ3VsYXIgRTE2NCBudW1iZXIsIGRlcGVuZGluZyBv biBlLmcuIHRoZSBjYWxsZXIncyBsb2NhdGlvbi4gU1AxIGZvcndhcmRzIElOVklURSByZXF1ZXN0 cyB3aXRoIFItVVJJID0gIjgwMCBudW1iZXIiIHRvIEFTLTEgb3IgQVMtMiBiYXNlZCBvbiBhIGxv YWQgYmFsYW5jaW5nIHN0cmF0ZWd5Lg0KDQpBcyBjYWxscyB0byA4MDAgMTIzNCA0NTI5IGNyZWF0 ZXMgYSBwcmUtb3ZlcmxvYWQgY29uZGl0aW9uIGluIEFTLTEsIEFTLTEgc2VuZHMgdG8gU1AtMSBh IGZpbHRlciByZXF1ZXN0aW5nIHRoYXQgNTAlIG9mIGNhbGxzIHRvd2FyZHMgODAwIDEyMzQgNDUy OSBiZSByZWplY3RlZC4NCg0KQWNjb3JkaW5nIHRvIHRoZSBjdXJyZW50IHdvcmRpbmcsIFNQMyB3 aWxsIGFwcGx5IHRoZSBmaWx0ZXIgb24gaW5jb21pbmcgSU5WSVRFIHJlcXVlc3RzLCBpcnJlc3Bl Y3RpdmUgb2Ygd2hldGhlciB0aGV5IGFyZSBpbnRlbmRlZCB0byBiZSBzZW50IHRvIEFTMSBvciBB UzIuDQoNCj09PiBJdCBzZWVtcyB0aGF0IHRoZXNlIHVzZSBjYXNlcyBjb3VsZCBiZSBzb2x2ZWQg YnkgYXBwbHlpbmcgdGhlIGZpbHRlcnMgdG8gb3V0Z29pbmcgcmVxdWVzdHMgKG5vdCBpbmNvbWlu ZyByZXF1ZXN0cykgdGhhdCBhcmUgdG8gYmUgcm91dGVkIHRvIHRoZSBBUyB0aGF0IHNlbnQgdGhl c2UgZmlsdGVycy4gVGhpcyBtZWFucyB0aGF0IHRoZSBTUCBoYXMgdG8gc3RvcmUgdGhlIEFTIGFk ZHJlc3MgdG9nZXRoZXIgd2l0aCB0aGUgcmVjZWl2ZWQgZmlsdGVycyBvciB0aGlzIGFkZHJlc3Mg aGFzIHRvIGJlIGluY2x1ZGVkIGV4cGxpY2l0bHkgYXMgYSBuZXcgZmlsdGVyIGNyaXRlcmlhLg0K DQo+DQo+DQo+ID4gNSkgU2VjdGlvbiA2LjMuMSwgbG9jYWwgbnVtYmVyIGdyb3VwaW5nOg0KPiA+ DQo+ID4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGZvciBsb2NhbCBudW1iZXJzIGlzIG5vdCBzdWl0 YWJsZS4gRm9yIGV4YW1wbGUsDQo+IGlmIHRoZSBwaG9uZS1jb250ZXh0IGZvciBzaG9ydCBzZXJ2 aWNlIG51bWJlcnMgaW4gYSBjb3VudHJ5IGlzIHRoZQ0KPiBjb3VudHJ5IGNvZGUsIHRoZSBzb2x1 dGlvbiBkb2VzIG5vdCBwZXJtaXQgdG8gZGVmaW5lIGEgZmlsdGVyIHRoYXQNCj4gZXhjbHVkZXMg YWxsIEUuMTY0IG51bWJlcnMgaW4gdGhhdCBjb3VudHJ5IGJ1dCByZXRhaW4gYWxsIHNob3J0IHNl cnZpY2UNCj4gbnVtYmVycy4gSSB0aGluayB3ZSBzaG91bGQgZWl0aGVyIGRlZmluZSBhbm90aGVy IHNvbHV0aW9uIG9yIHN0YXRlIHRoYXQNCj4gZ3JvdXBpbmcgb2YgbG9jYWwgbnVtYmVycyBpcyBu b3Qgc3VwcG9ydGVkIG9yIHN0YXRlIHRoYXQgZ3JvdXBpbmcgb2YNCj4gbG9jYWwgbnVtYmVycyBv bmx5IHdvcmtzIHVuZGVyIHNwZWNpZmljIGFzc3VtcHRpb25zIG9uIHRoZSB1c2Ugb2YgcGhvbmUt DQo+IGNvbnRleHQgdmFsdWVzLg0KPiA+DQo+DQo+IEhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxv d2luZyB0ZXh0Pw0KPg0KPiBJdCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgbWV0aG9kIG9mIGdy b3VwaW5nIGxvY2FsIG51bWJlcnMgYXMNCj4gZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50IGRvZXMg bm90IHN1cHBvcnQgYWxsIGNhc2VzLiBGb3IgZXhhbXBsZSwgaWYNCj4gdGhlIHBob25lLWNvbnRl eHQgZm9yIHNob3J0IHNlcnZpY2UgbnVtYmVycyBpbiBhIGNvdW50cnkgaXMgdGhlDQo+IGNvdW50 cnkgY29kZSwgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBwZXJtaXQgdG8gZGVmaW5lIGEgZmlsdGVy IHRoYXQNCj4gZXhjbHVkZXMgYWxsIEUuMTY0IG51bWJlcnMgaW4gdGhhdCBjb3VudHJ5IGJ1dCBy ZXRhaW4gYWxsIHNob3J0DQo+IHNlcnZpY2UgbnVtYmVycy4gQSBjb21wbGV0ZSBzb2x1dGlvbiBm b3IgbG9jYWwgbnVtYmVyIGdyb3VwaW5nDQo+IHJlcXVpcmVzIGEgc2VwYXJhdGUgbWV0aG9kIG91 dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQpbQkNdDQoNCkxvb2tzIE9LIGZvciBt ZS4NCg0KDQo+DQo+DQo+IFRoYW5rcyENCj4NCj4gQ2hhcmxlcw0KPg0KPg0KPiBPbiBXZWQsIEp1 bCAxMSwgMjAxMiBhdCAzOjMzIEFNLCAgPGJydW5vLmNoYXRyYXNAb3JhbmdlLmNvbT4gd3JvdGU6 DQo+ID4gSGkhDQo+ID4NCj4gPiBIZXJlIGFyZSBteSBjb21tZW50cyBhYm91dCB0aGlzIEktRC4N Cj4gPg0KPiA+IDEpIFNlY3Rpb24gNC4zLCBtb3ZlIHBhcmFncmFwaCA3IChsaW5lIDM3NiAtIDM4 NikgYWZ0ZXIgcGFyYWdyYXBoIDUNCj4gKGkuZS4gYWZ0ZXIgbGluZSAzNjApIGFuZCBtb2RpZmll cyB0aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBhcyBmb2xsb3dzOg0KPiA+DQo+ID4gIkluIHRoZSBh Ym92ZSBjYXNlLCB0aGUgbmV0d29yayBlbnRpdHkgd2hlcmUgbG9hZCBmaWx0ZXJpbmcgcG9saWN5 IGlzDQo+IGZpcnN0IGludHJvZHVjZWQgaXMgdGhlIFNJUCBzZXJ2ZXIgcHJvdmlkaW5nIGFjY2Vz cyB0byB0aGUgcmVzb3VyY2UgdGhhdA0KPiBjcmVhdGVzIHRoZSBvdmVybG9hZCBjb25kaXRpb24u IEluIG90aGVyIGNhc2VzLCB0aGUgbmV0d29yayBlbnRyeSBwb2ludA0KPiBvZiBsb2FkIGZpbHRl cmluZyBwb2xpY3kgY291bGQgYWxzbyBiZSBhbiBlbnRpdHkgdGhhdCBob3N0cyB0aGlzDQo+IHJl c291cmNlLiAiDQo+ID4NCj4gPiAyKSBTZWN0aW9uIDUuOCwgbGluZSA1MjUtNTI4DQo+ID4NCj4g PiBUaGUgY3VycmVudCB0ZXh0IHN1Z2dlc3RzIHRoYXQgaW5jb21pbmcgcmVxdWVzdHMgYXJlIGZp bHRlcmVkDQo+IGlycmVzcGVjdGl2ZSBvZiB0aGVpciBhY3R1YWwgZGVzdGluYXRpb24uIFRoZSBz dWJzY3JpYmVyIHNob3VsZCByYXRoZXINCj4gYXBwbHkgZmlsdGVycyBvbiByZXF1ZXN0cyB0aGF0 IGFyZSBvdXRnb2luZyB0byB0aGUgcHJlLW92ZXJsb2FkZWQNCj4gZGVzdGluYXRpb24uIE9uZSBz b2x1dGlvbiB3b3VsZCBiZSB0byByZXBocmFzZSB0aGUgZm9sbG93aW5nIHRleHQ6DQo+ID4NCj4g PiAiQSBzdWJzY3JpYmVyIHJlY2VpdmluZyB0aGUgbm90aWZpY2F0aW9uIGZpcnN0IGluc3RhbGxz IHRoZXNlIHJ1bGVzDQo+IGFuZCB0aGVuIGZpbHRlciBpbmNvbWluZyByZXF1ZXN0cyB0byBlbmZv cmNlIGFjdGlvbnMgb24gYXBwcm9wcmlhdGUNCj4gcmVxdWVzdHMsIGZvciBleGFtcGxlLCBsaW1p dGluZyB0aGUgc2VuZGluZyByYXRlIG9mIGNhbGwgcmVxdWVzdHMNCj4gZGVzdGluZWQgZm9yIGEg c3BlY2lmaWMgU0lQIGVudGl0eS4iDQo+ID4NCj4gPiBXaXRoDQo+ID4NCj4gPiAiQSBzdWJzY3Jp YmVyIHJlY2VpdmluZyB0aGUgbm90aWZpY2F0aW9uIGZpcnN0IGluc3RhbGxzIHRoZXNlIHJ1bGVz DQo+IGFuZCB0aGVuIGZpbHRlciBvdXRnb2luZyByZXF1ZXN0cyB0b3dhcmRzIHRoZSBub3RpZmll ciB0byBlbmZvcmNlDQo+IGFjdGlvbnMgb24gYXBwcm9wcmlhdGUgcmVxdWVzdHMsIGZvciBleGFt cGxlLCBsaW1pdGluZyB0aGUgc2VuZGluZyByYXRlDQo+IG9mIGNhbGwgcmVxdWVzdHMgZGVzdGlu ZWQgZm9yIGEgc3BlY2lmaWMgU0lQIGVudGl0eS4iDQo+ID4NCj4gPiBUaGlzIHdvdWxkIGhvd2V2 ZXIgbm90IHBlcm1pdCB0aGUgdXNlIG9mIGV4dGVybmFsIHN0YXRlIGFnZW50cyBhcw0KPiBkZXNj cmliZWQgaW4gc2VjdGlvbiA1LjEyLiBUaGVyZWZvcmUgaXQgc2VlbXMgdGhhdCBhICJ0YXJnZXQg c2lwIGVudGl0eSINCj4gcGFyYW1ldGVyIHNob3VsZCBiZSBhZGRlZCB0byBvdmVybG9hZCBjb250 cm9sIGRvY3VtZW50cy4NCj4gPg0KPiA+IDMpIFNlY3Rpb24gNS44LCBhZGQgdGhlIGZvbGxvd2lu ZyB0ZXh0IChhZGFwdGVkIGZyb20gZHJhZnQtaWV0Zi1zb2MtDQo+IG92ZXJsb2FkLWNvbnRyb2wp IGFmdGVyIGxpbmUgNTM3Og0KPiA+DQo+ID4gIldoZW4gZW5mb3JjaW5nIGFjdGlvbnMgb24gcmVx dWVzdHMgbWF0Y2hpbmcgdGhlIGZpbHRlcnMsIHN1YnNjcmliZXJzDQo+IFNIT1VMRCBob25vciB0 aGUgbG9jYWwgcG9saWN5IGZvciBwcmlvcml0aXppbmcgU0lQIHJlcXVlc3RzIHN1Y2ggYXMNCj4g cG9saWNpZXMgYmFzZWQgb24gdGhlIGNvbnRlbnQgb2YgdGhlIFJlc291cmNlLVByaW9yaXR5IGhl YWRlciAoUlBILA0KPiBSRkM0NDEyIFtSRkM0NDEyXSkuICBTcGVjaWZpYyAobmFtZXNwYWNlLnZh bHVlKSBSUEggY29udGVudHMgbWF5DQo+IGluZGljYXRlIGhpZ2ggcHJpb3JpdHkgcmVxdWVzdHMg dGhhdCBzaG91bGQgYmUgIHByZXNlcnZlZCBhcyBtdWNoIGFzDQo+IHBvc3NpYmxlIGR1cmluZyBv dmVybG9hZC4gIFRoZSBSUEggY29udGVudHMgY2FuIGFsc28gaW5kaWNhdGUgYSBsb3ctDQo+IHBy aW9yaXR5IHJlcXVlc3QgdGhhdCBpcyBlbGlnaWJsZSB0byBiZSBkcm9wcGVkIGR1cmluZyB0aW1l cyBvZiBvdmVybG9hZC4NCj4gT3RoZXIgaW5kaWNhdG9ycywgc3VjaCBhcyB0aGUgU09TIFVSTiBb UkZDNTAzMV0gaW5kaWNhdGluZyBhbiBlbWVyZ2VuY3kNCj4gcmVxdWVzdCwgbWF5IGFsc28gYmUg dXNlZCBmb3IgcHJpb3JpdGl6YXRpb24uIg0KPiA+DQo+ID4gNCkgU2VjdGlvbiA2LjMuMSwgbWF0 Y2hpbmcgaWRlbnRpdGllczogQWZ0ZXIgbGluZSA2OTksIGFkZCB0aGUNCj4gZm9sbG93aW5nIHRl eHQ6DQo+ID4NCj4gPiAiQmVmb3JlIGV2YWx1YXRpbmcgY2FsbC1pZGVudGl0eSBjb25kaXRpb25z LCB0aGUgc3Vic2NyaWJlciBzaGFsbA0KPiBjb252ZXJ0IFVSSXMgcmVjZWl2ZWQgaW4gU0lQIGhl YWRlciBmaWVsZHMgaW4gY2Fub25pY2FsIGZvcm0gYXMgcGVyIFJGQw0KPiAzMjYxLCBleGNlcHQg dGhhdCB0aGUgcGhvbmUtY29udGV4dCBwYXJhbWV0ZXIgc2hhbGwgbm90IGJlIHJlbW92ZWQsIGlm DQo+IHByZXNlbnQuIg0KPiA+DQo+ID4gNSkgU2VjdGlvbiA2LjMuMSwgbG9jYWwgbnVtYmVyIGdy b3VwaW5nOg0KPiA+DQo+ID4gVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGZvciBsb2NhbCBudW1iZXJz IGlzIG5vdCBzdWl0YWJsZS4gRm9yIGV4YW1wbGUsDQo+IGlmIHRoZSBwaG9uZS1jb250ZXh0IGZv ciBzaG9ydCBzZXJ2aWNlIG51bWJlcnMgaW4gYSBjb3VudHJ5IGlzIHRoZQ0KPiBjb3VudHJ5IGNv ZGUsIHRoZSBzb2x1dGlvbiBkb2VzIG5vdCBwZXJtaXQgdG8gZGVmaW5lIGEgZmlsdGVyIHRoYXQN Cj4gZXhjbHVkZXMgYWxsIEUuMTY0IG51bWJlcnMgaW4gdGhhdCBjb3VudHJ5IGJ1dCByZXRhaW4g YWxsIHNob3J0IHNlcnZpY2UNCj4gbnVtYmVycy4gSSB0aGluayB3ZSBzaG91bGQgZWl0aGVyIGRl ZmluZSBhbm90aGVyIHNvbHV0aW9uIG9yIHN0YXRlIHRoYXQNCj4gZ3JvdXBpbmcgb2YgbG9jYWwg bnVtYmVycyBpcyBub3Qgc3VwcG9ydGVkIG9yIHN0YXRlIHRoYXQgZ3JvdXBpbmcgb2YNCj4gbG9j YWwgbnVtYmVycyBvbmx5IHdvcmtzIHVuZGVyIHNwZWNpZmljIGFzc3VtcHRpb25zIG9uIHRoZSB1 c2Ugb2YgcGhvbmUtDQo+IGNvbnRleHQgdmFsdWVzLg0KPiA+DQo+ID4gNikgU2VjdGlvbiA2LjMu MSwgbGluZSA3NDYgLSA3NTMsIHJlbW92ZSB0aGUgbGFzdCBidXQgb25lIHNlbnRlbmNlIGFuZA0K PiByZXdvcmQgdGhlIHJlc3Qgb2YgdGhlIHRleHQgYWNjb3JkaW5nbHkuIFJlYXNvbjogVGhlIHVz ZSBvZiBsb2NhbCBudW1iZXINCj4gJ3RlbCcgVVJJIGluIHRoZSBSLVVSSSBhbmQgVG8gaGVhZGVy IGZpZWxkIGlzIG5vdCByYXJlLiBJbiBzZXZlcmFsDQo+IGNvdW50cmllcywgc2hvcnQgbnVtYmVy cyBhcmUgdXNlZCBxdWl0ZSBleHRlbnNpdmVseSB0byBhY2Nlc3Mgc3BlY2lhbA0KPiBzZXJ2aWNl cy4NCj4gPg0KPiA+ICJTZWNvbmQsIHVzZSBvZiB0aGUgbG9jYWwgbnVtYmVyICd0ZWwnIFVSSSBp biBwcmFjdGljZSBpcyBleHBlY3RlZCB0bw0KPiBiZSByYXJlLiINCj4gPg0KPiA+IDcpIENsYXVz ZSA2LjMuMywgYWZ0ZXIgbGluZSA4MDAsIGFkZDoNCj4gPg0KPiA+ICJTVUJTQ1JJQkUgcmVxdWVz dHMgYXJlIG5vdCBmaWx0ZXJlZCBpZiB0aGUgZXZlbnQtdHlwZSBoZWFkZXIgZmllbGQNCj4gaW5k aWNhdGVzIHRoZSBldmVudCBwYWNrYWdlIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudC4iDQo+ID4N Cj4gPiA4KSBTZWN0aW9uIDcsIGxpbmUgOTg1IC0gOTkwOiByZXBsYWNlICJjYWxsIHR5cGUiIHdp dGggImNhbGwgaWRlbnRpdHkNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91 IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQg bGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKRnJhbmNlIFRlbGVj b20gLSBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgRnJhbmNlIFRlbGVjb20gLSBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLgpUaGFuayB5b3UuCgo= --_000_88CAD1D4E8773F42858B58CAA28272A004E786PEXCVZYM12corpora_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl Pg0KPCEtLQ0KIC8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCiBAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OlNpbVN1bjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2lt U3VuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCiAvKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAu ODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0 aW9uMTt9DQotLT4NCjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CiAgPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQogPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+SGkgQ2hhcmxl cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 DQpjb2xvcjojMUY0OTdEIj5TZWUgYmVsb3c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7DQpjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7DQpjb2xvcjojMUY0OTdEIj5CQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OzsNCmNvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBjaGFybGVzLm5ld3lvcmtAZ21haWwuY29tIFttYWlsdG86Y2hh cmxlcy5uZXd5b3JrQGdtYWlsLmNvbV0NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IENoYXJsZXMgU2hl bjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtZXJjcmVkaSAxOCBqdWlsbGV0IDIwMTIgMDc6 Mzg8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IENIQVRSQVMgQnJ1bm8gUkQtQ09SRTxicj4NCjxiPkNj Jm5ic3A7OjwvYj4gU2FsdmF0b3JlIExvcmV0bzsgc2lwLW92ZXJsb2FkQGlldGYub3JnOyBWb2xr ZXIgSGlsdDsgSGVubmluZyBTY2h1bHpyaW5uZTsgQXJhdGEgS29pa2U8YnI+DQo8Yj5PYmpldCZu YnNwOzo8L2I+IFJlOiBbc2lwLW92ZXJsb2FkXSBXR0xDOiBkcmFmdC1pZXRmLXNvYy1vbG9hZC1j b250cm9sLWV2ZW50LXBhY2thZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBCcnVubywgJm5ic3A7aWYgaSB1bmRlcnN0YW5kIGNvcnJlY3RseSBpdCdz IGVzc2VudGlhbGx5IHRoZSBtdWx0aS1wYXRoL2xvYWQgYmFsYW5jaW5nIHByb2JsZW0gLSB5b3Ug aGF2ZSBtdWx0aXBsZSBuZXh0LWhvcCBTSVAgZW50aXRpZXMgdGhyb3VnaCB3aGljaCB5b3UgY2Fu IHJvdXRlIHRvIHRoZSBzYW1lIGRlc3RpbmF0aW9uLiBJbiB0aGF0IGNhc2UgaXQgaW5kZWVkIHNl ZW1zIHRoYXQgdGhlIGZpbHRlcmluZyB3aWxsDQogaGF2ZSB0byBiZSBuZXh0IGhvcCBzcGVjaWZp Yy4gSW4gdGhlIHN1YnNjcmliZS1ub3RpZnkgdy9vIHN0YXRlIGFnZW50IGNhc2UsIHRoZSBzdWJz Y3JpYmVyIGNhbiByZWNvcmQgdGhlIGNvcnJlc3BvbmRpbmcgbm90aWZpZXI7IGluIHRoZSBzdGF0 ZSBhZ2VudCBjYXNlLCBpZiB0aGUgcnVsZSBpcyBpbnNlcnRlZCBkaXJlY3RseSBpbnRvIGEgc3Vi c2NyaWJlciAoaW5zdGVhZCBvZiB0aHJvdWdoICZuYnNwO2Egbm90aWZpZXIpLCB0aGVuIHRoZSBz cGVjaWZpYw0KIG5leHQgaG9wIHdpbGwgbmVlZCB0byBiZSBleHBsaWNpdGx5IGRlZmluZWQuJm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBhcmUg eW91IHN1Z2dlc3Rpbmcgd2UgZGVmaW5lIGEgbmV3IGVsZW1lbnQgZm9yIHRoZSBpZGVudGl0eSBv ZiAmcXVvdDt0YXJnZXQgU0lQIGVudGl0eSZxdW90OyAoYW5kIGlzIHRoaXMgYSBiZXR0ZXIgdGVy bSB0aGFuLCBzYXkgJnF1b3Q7bmV4dC1ob3AgU0lQIGVudGl0eSZxdW90Oz8pLiBXaGVuIGFwcGxp Y2FibGUsIGl0IHdpbGwgY29udGFpbiB0aGUgc2VydmVyIG5hbWUgb3IgSVAgYWRkcmVzcyBvZiB0 aGUgc3BlY2lmaWMgbmV4dCBob3ANCiBTSVAgZW50aXR5LCBhbmQgYnkgZGVmYXVsdCBpdCBjYW4g YmUgbnVsbCB3aGljaCBtZWFucyBpdCBhcHBsaWVzIHRvIGFsbCBuZXh0IGhvcCBTSVAgZW50aXRp ZXM/Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6DQomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0JD XSBZZXMgYSBuZXcgZWxlbWVudCBpbiB0aGUgZmlsdGVyIHdvdWxkIGRvIHRoZSBqb2IgSSBiZWxp ZXZlLiDigJxUYXJnZXQgU0lQIGVudGl0eeKAnSB3b3VsZCBiZSBtb3JlIGdlbmVyaWMgdGhhbiDi gJxOZXh0IEhvcCBTSVAgZW50aXR54oCdLg0KIFRoZSBTSVAgY2xpZW50IHdvdWxkIG1hdGNoIGl0 IHRvIHRoZSBmdWxsIGNvbnRlbnRzIG9mIHRoZSByb3V0ZSBoZWFkZXIgKGlmIGFueSksIG5vdCBq dXN0IHRvIHRoZSBuZXh0IGlkZW50aXR5IG9mIHRoZSBuZXh0IGhvcC48L3NwYW4+PC9pPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ow0KY29sb3I6IzFGNDk3RCI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGFybGVzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N Ck9uIFR1ZXNkYXksIEp1bHkgMTcsIDIwMTIsIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGkgQ2hhcmxlcyw8YnI+DQo8YnI+DQpTZWUgYmVsb3cuPGJyPg0KPGJy Pg0KJmd0OyAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS08YnI+DQomZ3Q7IERlJm5ic3A7OiBj aGFybGVzLm5ld3lvcmtAZ21haWwuY29tIFttYWlsdG86Y2hhcmxlcy5uZXd5b3JrQGdtYWlsLmNv bV0gRGUgbGE8YnI+DQomZ3Q7IHBhcnQgZGUgQ2hhcmxlcyBTaGVuPGJyPg0KJmd0OyBFbnZvecOp Jm5ic3A7OiBtYXJkaSAxNyBqdWlsbGV0IDIwMTIgMTg6Mzc8YnI+DQomZ3Q7IMOAJm5ic3A7OiBD SEFUUkFTIEJydW5vIFJELUNPUkU8YnI+DQomZ3Q7IENjJm5ic3A7OiBTYWx2YXRvcmUgTG9yZXRv OyBzaXAtb3ZlcmxvYWRAaWV0Zi5vcmc7IFZvbGtlciBIaWx0OyBIZW5uaW5nPGJyPg0KJmd0OyBT Y2h1bHpyaW5uZTsgQXJhdGEgS29pa2U8YnI+DQomZ3Q7IE9iamV0Jm5ic3A7OiBSZTogW3NpcC1v dmVybG9hZF0gV0dMQzogZHJhZnQtaWV0Zi1zb2Mtb2xvYWQtY29udHJvbC1ldmVudC08YnI+DQom Z3Q7IHBhY2thZ2U8YnI+DQomZ3Q7PGJyPg0KJmd0OyBIaSBCcnVubywgdGhhbmsgeW91IHNvIG11 Y2ggZm9yIHRoZSBkZXRhaWxlZCByZXZpZXcgYW5kIGNvbW1lbnRzISBJJ3ZlPGJyPg0KJmd0OyBh ZGRyZXNzZWQgOCBvdXQgb2YgdGhlIHRvdGFsIDEwLCBleGNlcHQgdGhlIGZvbGxvd2luZyB0d28g d2hpY2ggSSdkPGJyPg0KJmd0OyBhcHByZWNpYXRlIG1vcmUgY2xhcmlmaWNhdGlvbi48YnI+DQom Z3Q7PGJyPg0KJmd0OyAmZ3Q7IDIpIFNlY3Rpb24gNS44LCBsaW5lIDUyNS01Mjg8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIGN1cnJlbnQgdGV4dCBzdWdnZXN0cyB0aGF0IGluY29t aW5nIHJlcXVlc3RzIGFyZSBmaWx0ZXJlZDxicj4NCiZndDsgaXJyZXNwZWN0aXZlIG9mIHRoZWly IGFjdHVhbCBkZXN0aW5hdGlvbi4gVGhlIHN1YnNjcmliZXIgc2hvdWxkIHJhdGhlcjxicj4NCiZn dDsgYXBwbHkgZmlsdGVycyBvbiByZXF1ZXN0cyB0aGF0IGFyZSBvdXRnb2luZyB0byB0aGUgcHJl LW92ZXJsb2FkZWQ8YnI+DQomZ3Q7IGRlc3RpbmF0aW9uLiBPbmUgc29sdXRpb24gd291bGQgYmUg dG8gcmVwaHJhc2UgdGhlIGZvbGxvd2luZyB0ZXh0Ojxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyAmcXVvdDtBIHN1YnNjcmliZXIgcmVjZWl2aW5nIHRoZSBub3RpZmljYXRpb24gZmlyc3Qg aW5zdGFsbHMgdGhlc2UgcnVsZXM8YnI+DQomZ3Q7IGFuZCB0aGVuIGZpbHRlciBpbmNvbWluZyBy ZXF1ZXN0cyB0byBlbmZvcmNlIGFjdGlvbnMgb24gYXBwcm9wcmlhdGU8YnI+DQomZ3Q7IHJlcXVl c3RzLCBmb3IgZXhhbXBsZSwgbGltaXRpbmcgdGhlIHNlbmRpbmcgcmF0ZSBvZiBjYWxsIHJlcXVl c3RzPGJyPg0KJmd0OyBkZXN0aW5lZCBmb3IgYSBzcGVjaWZpYyBTSVAgZW50aXR5LiZxdW90Ozxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXaXRoPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7ICZxdW90O0Egc3Vic2NyaWJlciByZWNlaXZpbmcgdGhlIG5vdGlmaWNhdGlvbiBmaXJz dCBpbnN0YWxscyB0aGVzZSBydWxlczxicj4NCiZndDsgYW5kIHRoZW4gZmlsdGVyIG91dGdvaW5n IHJlcXVlc3RzIHRvd2FyZHMgdGhlIG5vdGlmaWVyIHRvIGVuZm9yY2U8YnI+DQomZ3Q7IGFjdGlv bnMgb24gYXBwcm9wcmlhdGUgcmVxdWVzdHMsIGZvciBleGFtcGxlLCBsaW1pdGluZyB0aGUgc2Vu ZGluZyByYXRlPGJyPg0KJmd0OyBvZiBjYWxsIHJlcXVlc3RzIGRlc3RpbmVkIGZvciBhIHNwZWNp ZmljIFNJUCBlbnRpdHkuJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoaXMg d291bGQgaG93ZXZlciBub3QgcGVybWl0IHRoZSB1c2Ugb2YgZXh0ZXJuYWwgc3RhdGUgYWdlbnRz IGFzPGJyPg0KJmd0OyBkZXNjcmliZWQgaW4gc2VjdGlvbiA1LjEyLiBUaGVyZWZvcmUgaXQgc2Vl bXMgdGhhdCBhICZxdW90O3RhcmdldCBzaXAgZW50aXR5JnF1b3Q7PGJyPg0KJmd0OyBwYXJhbWV0 ZXIgc2hvdWxkIGJlIGFkZGVkIHRvIG92ZXJsb2FkIGNvbnRyb2wgZG9jdW1lbnRzLjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IEkgdGhpbmsgSSBtaWdodCBoYXZlIG5vdCB1bmRl cnN0b29kIHlvdXIgcG9pbnQuIFRoZSByZXF1ZXN0cyBhcmU8YnI+DQomZ3Q7IGZpbHRlcmVkIGJh c2VkIG9uIHRoZSBjYWxsIGlkZW50aXRpZXMsIHdoaWNoIGNhbiBjb252ZXkgaW5mb3JtYXRpb248 YnI+DQomZ3Q7IGluY2x1ZGluZyB0aGUgY2FsbCBkZXN0aW5hdGlvbi4gQ291bGQgeW91IGVsYWJv cmF0ZSB3aGF0IHRoaXMgJnF1b3Q7dGFyZ2V0PGJyPg0KJmd0OyBzaXAgZW50aXR5JnF1b3Q7IGlz IGV4YWN0bHkgZm9yPzxicj4NCltCQ108YnI+DQo8YnI+DQpMZXQncyB0YWtlIHR3byBleGFtcGxl cyB0aGF0IEkgdGhpbmsgYXJlIG5vdCBjb3ZlcmVkIGJ5IHRoZSBjdXJyZW50IHdvcmRpbmcuPGJy Pg0KPGJyPg0KMSkgRXhhbXBsZSAxPGJyPg0KPGJyPg0KQ2FsbCBjb25maWd1cmF0aW9uOiBBIGlz IGNvbm5lY3RlZCBzbyBTUDEsIEIgaXMgY29ubmVjdGVkIHRvIFNQMi4gU1AxIGFuZCBTUDIgYXJl IGNvbm5lY3RlZCB2aWEgU1AzLiBTUDMgaXMgY29ubmVjdGVkIHRvIGFuIEFwcGxpY2F0aW9uIFNl cnZlciAoQVMpLiBVbmRlciBub3JtYWwgbG9hZCBjb25kaXRpb25zLCBhIGNhbGwgZnJvbSBBIHRv IEIgaXMgcm91dGVkIGFsb25nIHRoZSBmb2xsb3dpbmcgcGF0aDogQS1TUDEtU1AzLUFTLVNQMi1C LiBUaGUNCiBBUyBwcm92aWRlcyBhIG5vbi1lc3NlbnRpYWwgc2VydmljZSBhbmQgY2FuIGJlIGJ5 cGFzc2VkIGluIGNhc2Ugb2Ygb3ZlcmxvYWQuPGJyPg0KPGJyPg0KTm93IGxldCdzIGFzc3VtZSB0 aGF0IEFTIGlzIG92ZXJsb2FkZWQgYW5kIHNlbmRzIHRvIFNQMyBhIGZpbHRlciByZXF1ZXN0aW5n IHRoYXQgNTAlIG9mIElOVklURSBtZXNzYWdlcyBiZSBkcm9wcGVkLCByZWdhcmRsZXNzIG9mIHRo ZSBjb250ZW50cyBvZiB0aGUgZnJvbS90by9QQUkvUi1VUkkuPGJyPg0KPGJyPg0KQWNjb3JkaW5n IHRvIHRoZSBjdXJyZW50IHdvcmRpbmcsIFNQMyB3aWxsIGluZGVlZCBmaWx0ZXIgNTAlIG9mIHRo ZSBJTlZJVEUgcmVxdWVzdHMgd2hpbGUgdGhleSBjb3VsZCBiZSByb3V0ZWQgdG8gQiB2aWEgU1Ay Ljxicj4NCjxicj4NCjIpIEV4YW1wbGUgMjxicj4NCjxicj4NCkNhbGwgQ29uZmlndXJhdGlvbjog QW4gODAwIHRyYW5zbGF0aW9uIHNlcnZpY2UgaXMgaW5zdGFsbGVkIG9uIHR3byBBcHBsaWNhdGlv biBTZXJ2ZXJzIEFTLTEgYW5kIEFTLTIuIEEgaXMgY29ubmVjdGVkIHRvIFNQMSBhbmQgY2FsbHMg ODAwIDEyMzQgNDUyOSwgd2hpY2ggaXMgdHJhbnNsYXRlZCBieSBBUy0xIGFuZCBBUy0yIGludG8g YSByZWd1bGFyIEUxNjQgbnVtYmVyLCBkZXBlbmRpbmcgb24gZS5nLiB0aGUgY2FsbGVyJ3MgbG9j YXRpb24uIFNQMQ0KIGZvcndhcmRzIElOVklURSByZXF1ZXN0cyB3aXRoIFItVVJJID0gJnF1b3Q7 ODAwIG51bWJlciZxdW90OyB0byBBUy0xIG9yIEFTLTIgYmFzZWQgb24gYSBsb2FkIGJhbGFuY2lu ZyBzdHJhdGVneS48YnI+DQo8YnI+DQpBcyBjYWxscyB0byA4MDAgMTIzNCA0NTI5IGNyZWF0ZXMg YSBwcmUtb3ZlcmxvYWQgY29uZGl0aW9uIGluIEFTLTEsIEFTLTEgc2VuZHMgdG8gU1AtMSBhIGZp bHRlciByZXF1ZXN0aW5nIHRoYXQgNTAlIG9mIGNhbGxzIHRvd2FyZHMgODAwIDEyMzQgNDUyOSBi ZSByZWplY3RlZC48YnI+DQo8YnI+DQpBY2NvcmRpbmcgdG8gdGhlIGN1cnJlbnQgd29yZGluZywg U1AzIHdpbGwgYXBwbHkgdGhlIGZpbHRlciBvbiBpbmNvbWluZyBJTlZJVEUgcmVxdWVzdHMsIGly cmVzcGVjdGl2ZSBvZiB3aGV0aGVyIHRoZXkgYXJlIGludGVuZGVkIHRvIGJlIHNlbnQgdG8gQVMx IG9yIEFTMi48YnI+DQo8YnI+DQo9PSZndDsgSXQgc2VlbXMgdGhhdCB0aGVzZSB1c2UgY2FzZXMg Y291bGQgYmUgc29sdmVkIGJ5IGFwcGx5aW5nIHRoZSBmaWx0ZXJzIHRvIG91dGdvaW5nIHJlcXVl c3RzIChub3QgaW5jb21pbmcgcmVxdWVzdHMpIHRoYXQgYXJlIHRvIGJlIHJvdXRlZCB0byB0aGUg QVMgdGhhdCBzZW50IHRoZXNlIGZpbHRlcnMuIFRoaXMgbWVhbnMgdGhhdCB0aGUgU1AgaGFzIHRv IHN0b3JlIHRoZSBBUyBhZGRyZXNzIHRvZ2V0aGVyIHdpdGggdGhlIHJlY2VpdmVkIGZpbHRlcnMN CiBvciB0aGlzIGFkZHJlc3MgaGFzIHRvIGJlIGluY2x1ZGVkIGV4cGxpY2l0bHkgYXMgYSBuZXcg ZmlsdGVyIGNyaXRlcmlhLjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAmZ3Q7 IDUpIFNlY3Rpb24gNi4zLjEsIGxvY2FsIG51bWJlciBncm91cGluZzo8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGZvciBsb2NhbCBudW1iZXJzIGlz IG5vdCBzdWl0YWJsZS4gRm9yIGV4YW1wbGUsPGJyPg0KJmd0OyBpZiB0aGUgcGhvbmUtY29udGV4 dCBmb3Igc2hvcnQgc2VydmljZSBudW1iZXJzIGluIGEgY291bnRyeSBpcyB0aGU8YnI+DQomZ3Q7 IGNvdW50cnkgY29kZSwgdGhlIHNvbHV0aW9uIGRvZXMgbm90IHBlcm1pdCB0byBkZWZpbmUgYSBm aWx0ZXIgdGhhdDxicj4NCiZndDsgZXhjbHVkZXMgYWxsIEUuMTY0IG51bWJlcnMgaW4gdGhhdCBj b3VudHJ5IGJ1dCByZXRhaW4gYWxsIHNob3J0IHNlcnZpY2U8YnI+DQomZ3Q7IG51bWJlcnMuIEkg dGhpbmsgd2Ugc2hvdWxkIGVpdGhlciBkZWZpbmUgYW5vdGhlciBzb2x1dGlvbiBvciBzdGF0ZSB0 aGF0PGJyPg0KJmd0OyBncm91cGluZyBvZiBsb2NhbCBudW1iZXJzIGlzIG5vdCBzdXBwb3J0ZWQg b3Igc3RhdGUgdGhhdCBncm91cGluZyBvZjxicj4NCiZndDsgbG9jYWwgbnVtYmVycyBvbmx5IHdv cmtzIHVuZGVyIHNwZWNpZmljIGFzc3VtcHRpb25zIG9uIHRoZSB1c2Ugb2YgcGhvbmUtPGJyPg0K Jmd0OyBjb250ZXh0IHZhbHVlcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBI b3cgYWJvdXQgYWRkaW5nIHRoZSBmb2xsb3dpbmcgdGV4dD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBJ dCBzaG91bGQgYmUgbm90ZWQgdGhhdCB0aGUgbWV0aG9kIG9mIGdyb3VwaW5nIGxvY2FsIG51bWJl cnMgYXM8YnI+DQomZ3Q7IGRlZmluZWQgaW4gdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBzdXBwb3J0 IGFsbCBjYXNlcy4gRm9yIGV4YW1wbGUsIGlmPGJyPg0KJmd0OyB0aGUgcGhvbmUtY29udGV4dCBm b3Igc2hvcnQgc2VydmljZSBudW1iZXJzIGluIGEgY291bnRyeSBpcyB0aGU8YnI+DQomZ3Q7IGNv dW50cnkgY29kZSwgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCBwZXJtaXQgdG8gZGVmaW5lIGEgZmls dGVyIHRoYXQ8YnI+DQomZ3Q7IGV4Y2x1ZGVzIGFsbCBFLjE2NCBudW1iZXJzIGluIHRoYXQgY291 bnRyeSBidXQgcmV0YWluIGFsbCBzaG9ydDxicj4NCiZndDsgc2VydmljZSBudW1iZXJzLiBBIGNv bXBsZXRlIHNvbHV0aW9uIGZvciBsb2NhbCBudW1iZXIgZ3JvdXBpbmc8YnI+DQomZ3Q7IHJlcXVp cmVzIGEgc2VwYXJhdGUgbWV0aG9kIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQu PGJyPg0KW0JDXTxicj4NCjxicj4NCkxvb2tzIE9LIGZvciBtZS48YnI+DQo8YnI+DQo8YnI+DQom Z3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtzITxicj4NCiZndDs8YnI+DQomZ3Q7IENoYXJs ZXM8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gV2VkLCBKdWwgMTEsIDIwMTIgYXQg MzozMyBBTSwgJm5ic3A7Jmx0O2JydW5vLmNoYXRyYXNAb3JhbmdlLmNvbSZndDsgd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7IEhpITxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBIZXJlIGFyZSBt eSBjb21tZW50cyBhYm91dCB0aGlzIEktRC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsg MSkgU2VjdGlvbiA0LjMsIG1vdmUgcGFyYWdyYXBoIDcgKGxpbmUgMzc2IC0gMzg2KSBhZnRlciBw YXJhZ3JhcGggNTxicj4NCiZndDsgKGkuZS4gYWZ0ZXIgbGluZSAzNjApIGFuZCBtb2RpZmllcyB0 aGUgZmlyc3QgdHdvIHNlbnRlbmNlcyBhcyBmb2xsb3dzOjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyAmcXVvdDtJbiB0aGUgYWJvdmUgY2FzZSwgdGhlIG5ldHdvcmsgZW50aXR5IHdoZXJl IGxvYWQgZmlsdGVyaW5nIHBvbGljeSBpczxicj4NCiZndDsgZmlyc3QgaW50cm9kdWNlZCBpcyB0 aGUgU0lQIHNlcnZlciBwcm92aWRpbmcgYWNjZXNzIHRvIHRoZSByZXNvdXJjZSB0aGF0PGJyPg0K Jmd0OyBjcmVhdGVzIHRoZSBvdmVybG9hZCBjb25kaXRpb24uIEluIG90aGVyIGNhc2VzLCB0aGUg bmV0d29yayBlbnRyeSBwb2ludDxicj4NCiZndDsgb2YgbG9hZCBmaWx0ZXJpbmcgcG9saWN5IGNv dWxkIGFsc28gYmUgYW4gZW50aXR5IHRoYXQgaG9zdHMgdGhpczxicj4NCiZndDsgcmVzb3VyY2Uu ICZxdW90Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAyKSBTZWN0aW9uIDUuOCwgbGlu ZSA1MjUtNTI4PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBjdXJyZW50IHRleHQg c3VnZ2VzdHMgdGhhdCBpbmNvbWluZyByZXF1ZXN0cyBhcmUgZmlsdGVyZWQ8YnI+DQomZ3Q7IGly cmVzcGVjdGl2ZSBvZiB0aGVpciBhY3R1YWwgZGVzdGluYXRpb24uIFRoZSBzdWJzY3JpYmVyIHNo b3VsZCByYXRoZXI8YnI+DQomZ3Q7IGFwcGx5IGZpbHRlcnMgb24gcmVxdWVzdHMgdGhhdCBhcmUg b3V0Z29pbmcgdG8gdGhlIHByZS1vdmVybG9hZGVkPGJyPg0KJmd0OyBkZXN0aW5hdGlvbi4gT25l IHNvbHV0aW9uIHdvdWxkIGJlIHRvIHJlcGhyYXNlIHRoZSBmb2xsb3dpbmcgdGV4dDo8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJnF1b3Q7QSBzdWJzY3JpYmVyIHJlY2VpdmluZyB0aGUg bm90aWZpY2F0aW9uIGZpcnN0IGluc3RhbGxzIHRoZXNlIHJ1bGVzPGJyPg0KJmd0OyBhbmQgdGhl biBmaWx0ZXIgaW5jb21pbmcgcmVxdWVzdHMgdG8gZW5mb3JjZSBhY3Rpb25zIG9uIGFwcHJvcHJp YXRlPGJyPg0KJmd0OyByZXF1ZXN0cywgZm9yIGV4YW1wbGUsIGxpbWl0aW5nIHRoZSBzZW5kaW5n IHJhdGUgb2YgY2FsbCByZXF1ZXN0czxicj4NCiZndDsgZGVzdGluZWQgZm9yIGEgc3BlY2lmaWMg U0lQIGVudGl0eS4mcXVvdDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2l0aDxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAmcXVvdDtBIHN1YnNjcmliZXIgcmVjZWl2aW5nIHRo ZSBub3RpZmljYXRpb24gZmlyc3QgaW5zdGFsbHMgdGhlc2UgcnVsZXM8YnI+DQomZ3Q7IGFuZCB0 aGVuIGZpbHRlciBvdXRnb2luZyByZXF1ZXN0cyB0b3dhcmRzIHRoZSBub3RpZmllciB0byBlbmZv cmNlPGJyPg0KJmd0OyBhY3Rpb25zIG9uIGFwcHJvcHJpYXRlIHJlcXVlc3RzLCBmb3IgZXhhbXBs ZSwgbGltaXRpbmcgdGhlIHNlbmRpbmcgcmF0ZTxicj4NCiZndDsgb2YgY2FsbCByZXF1ZXN0cyBk ZXN0aW5lZCBmb3IgYSBzcGVjaWZpYyBTSVAgZW50aXR5LiZxdW90Ozxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyBUaGlzIHdvdWxkIGhvd2V2ZXIgbm90IHBlcm1pdCB0aGUgdXNlIG9mIGV4 dGVybmFsIHN0YXRlIGFnZW50cyBhczxicj4NCiZndDsgZGVzY3JpYmVkIGluIHNlY3Rpb24gNS4x Mi4gVGhlcmVmb3JlIGl0IHNlZW1zIHRoYXQgYSAmcXVvdDt0YXJnZXQgc2lwIGVudGl0eSZxdW90 Ozxicj4NCiZndDsgcGFyYW1ldGVyIHNob3VsZCBiZSBhZGRlZCB0byBvdmVybG9hZCBjb250cm9s IGRvY3VtZW50cy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgMykgU2VjdGlvbiA1Ljgs IGFkZCB0aGUgZm9sbG93aW5nIHRleHQgKGFkYXB0ZWQgZnJvbSBkcmFmdC1pZXRmLXNvYy08YnI+ DQomZ3Q7IG92ZXJsb2FkLWNvbnRyb2wpIGFmdGVyIGxpbmUgNTM3Ojxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0OyAmcXVvdDtXaGVuIGVuZm9yY2luZyBhY3Rpb25zIG9uIHJlcXVlc3RzIG1h dGNoaW5nIHRoZSBmaWx0ZXJzLCBzdWJzY3JpYmVyczxicj4NCiZndDsgU0hPVUxEIGhvbm9yIHRo ZSBsb2NhbCBwb2xpY3kgZm9yIHByaW9yaXRpemluZyBTSVAgcmVxdWVzdHMgc3VjaCBhczxicj4N CiZndDsgcG9saWNpZXMgYmFzZWQgb24gdGhlIGNvbnRlbnQgb2YgdGhlIFJlc291cmNlLVByaW9y aXR5IGhlYWRlciAoUlBILDxicj4NCiZndDsgUkZDNDQxMiBbUkZDNDQxMl0pLiAmbmJzcDtTcGVj aWZpYyAobmFtZXNwYWNlLnZhbHVlKSBSUEggY29udGVudHMgbWF5PGJyPg0KJmd0OyBpbmRpY2F0 ZSBoaWdoIHByaW9yaXR5IHJlcXVlc3RzIHRoYXQgc2hvdWxkIGJlICZuYnNwO3ByZXNlcnZlZCBh cyBtdWNoIGFzPGJyPg0KJmd0OyBwb3NzaWJsZSBkdXJpbmcgb3ZlcmxvYWQuICZuYnNwO1RoZSBS UEggY29udGVudHMgY2FuIGFsc28gaW5kaWNhdGUgYSBsb3ctPGJyPg0KJmd0OyBwcmlvcml0eSBy ZXF1ZXN0IHRoYXQgaXMgZWxpZ2libGUgdG8gYmUgZHJvcHBlZCBkdXJpbmcgdGltZXMgb2Ygb3Zl cmxvYWQuPGJyPg0KJmd0OyBPdGhlciBpbmRpY2F0b3JzLCBzdWNoIGFzIHRoZSBTT1MgVVJOIFtS RkM1MDMxXSBpbmRpY2F0aW5nIGFuIGVtZXJnZW5jeTxicj4NCiZndDsgcmVxdWVzdCwgbWF5IGFs c28gYmUgdXNlZCBmb3IgcHJpb3JpdGl6YXRpb24uJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IDQpIFNlY3Rpb24gNi4zLjEsIG1hdGNoaW5nIGlkZW50aXRpZXM6IEFmdGVyIGxp bmUgNjk5LCBhZGQgdGhlPGJyPg0KJmd0OyBmb2xsb3dpbmcgdGV4dDo8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJnF1b3Q7QmVmb3JlIGV2YWx1YXRpbmcgY2FsbC1pZGVudGl0eSBjb25k aXRpb25zLCB0aGUgc3Vic2NyaWJlciBzaGFsbDxicj4NCiZndDsgY29udmVydCBVUklzIHJlY2Vp dmVkIGluIFNJUCBoZWFkZXIgZmllbGRzIGluIGNhbm9uaWNhbCBmb3JtIGFzIHBlciBSRkM8YnI+ DQomZ3Q7IDMyNjEsIGV4Y2VwdCB0aGF0IHRoZSBwaG9uZS1jb250ZXh0IHBhcmFtZXRlciBzaGFs bCBub3QgYmUgcmVtb3ZlZCwgaWY8YnI+DQomZ3Q7IHByZXNlbnQuJnF1b3Q7PGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7IDUpIFNlY3Rpb24gNi4zLjEsIGxvY2FsIG51bWJlciBncm91cGlu Zzo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIHByb3Bvc2VkIHNvbHV0aW9uIGZv ciBsb2NhbCBudW1iZXJzIGlzIG5vdCBzdWl0YWJsZS4gRm9yIGV4YW1wbGUsPGJyPg0KJmd0OyBp ZiB0aGUgcGhvbmUtY29udGV4dCBmb3Igc2hvcnQgc2VydmljZSBudW1iZXJzIGluIGEgY291bnRy eSBpcyB0aGU8YnI+DQomZ3Q7IGNvdW50cnkgY29kZSwgdGhlIHNvbHV0aW9uIGRvZXMgbm90IHBl cm1pdCB0byBkZWZpbmUgYSBmaWx0ZXIgdGhhdDxicj4NCiZndDsgZXhjbHVkZXMgYWxsIEUuMTY0 IG51bWJlcnMgaW4gdGhhdCBjb3VudHJ5IGJ1dCByZXRhaW4gYWxsIHNob3J0IHNlcnZpY2U8YnI+ DQomZ3Q7IG51bWJlcnMuIEkgdGhpbmsgd2Ugc2hvdWxkIGVpdGhlciBkZWZpbmUgYW5vdGhlciBz b2x1dGlvbiBvciBzdGF0ZSB0aGF0PGJyPg0KJmd0OyBncm91cGluZyBvZiBsb2NhbCBudW1iZXJz IGlzIG5vdCBzdXBwb3J0ZWQgb3Igc3RhdGUgdGhhdCBncm91cGluZyBvZjxicj4NCiZndDsgbG9j YWwgbnVtYmVycyBvbmx5IHdvcmtzIHVuZGVyIHNwZWNpZmljIGFzc3VtcHRpb25zIG9uIHRoZSB1 c2Ugb2YgcGhvbmUtPGJyPg0KJmd0OyBjb250ZXh0IHZhbHVlcy48YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgNikgU2VjdGlvbiA2LjMuMSwgbGluZSA3NDYgLSA3NTMsIHJlbW92ZSB0aGUg bGFzdCBidXQgb25lIHNlbnRlbmNlIGFuZDxicj4NCiZndDsgcmV3b3JkIHRoZSByZXN0IG9mIHRo ZSB0ZXh0IGFjY29yZGluZ2x5LiBSZWFzb246IFRoZSB1c2Ugb2YgbG9jYWwgbnVtYmVyPGJyPg0K Jmd0OyAndGVsJyBVUkkgaW4gdGhlIFItVVJJIGFuZCBUbyBoZWFkZXIgZmllbGQgaXMgbm90IHJh cmUuIEluIHNldmVyYWw8YnI+DQomZ3Q7IGNvdW50cmllcywgc2hvcnQgbnVtYmVycyBhcmUgdXNl ZCBxdWl0ZSBleHRlbnNpdmVseSB0byBhY2Nlc3Mgc3BlY2lhbDxicj4NCiZndDsgc2VydmljZXMu PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7ICZxdW90O1NlY29uZCwgdXNlIG9mIHRoZSBs b2NhbCBudW1iZXIgJ3RlbCcgVVJJIGluIHByYWN0aWNlIGlzIGV4cGVjdGVkIHRvPGJyPg0KJmd0 OyBiZSByYXJlLiZxdW90Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyA3KSBDbGF1c2Ug Ni4zLjMsIGFmdGVyIGxpbmUgODAwLCBhZGQ6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 ICZxdW90O1NVQlNDUklCRSByZXF1ZXN0cyBhcmUgbm90IGZpbHRlcmVkIGlmIHRoZSBldmVudC10 eXBlIGhlYWRlciBmaWVsZDxicj4NCiZndDsgaW5kaWNhdGVzIHRoZSBldmVudCBwYWNrYWdlIGRl ZmluZWQgaW4gdGhpcyBkb2N1bWVudC4mcXVvdDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgOCkgU2VjdGlvbiA3LCBsaW5lIDk4NSAtIDk5MDogcmVwbGFjZSAmcXVvdDtjYWxsIHR5cGUm cXVvdDsgd2l0aCAmcXVvdDtjYWxsIGlkZW50aXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8UFJFPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2lu dGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3Ug cHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApGcmFuY2UgVGVsZWNv bSAtIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQg aXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGlu Zm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBi ZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBGcmFuY2UgVGVsZWNvbSAtIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_88CAD1D4E8773F42858B58CAA28272A004E786PEXCVZYM12corpora_-- From volker.hilt@bell-labs.com Wed Jul 25 15:52:59 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7412C21F867D for ; Wed, 25 Jul 2012 15:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-t2OecMFmWH for ; Wed, 25 Jul 2012 15:52:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id B193521F8679 for ; Wed, 25 Jul 2012 15:52:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6PMqswZ027157 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Jul 2012 00:52:55 +0200 Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 26 Jul 2012 00:52:54 +0200 Received: from [135.244.37.206] (135.5.27.12) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 25 Jul 2012 18:52:52 -0400 Message-ID: <501078C3.8030208@bell-labs.com> Date: Wed, 25 Jul 2012 18:52:51 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Subject: [sip-overload] final agenda X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jul 2012 22:52:59 -0000 Folks, below is a link to the final agenda for our session at the IETF meeting in Vancouver next week: https://datatracker.ietf.org/meeting/84/agenda/soc/ Please let us know if you have any comments/concerns. Looking forward to a productive meeting! Volker From keith.drage@alcatel-lucent.com Wed Jul 25 18:01:15 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B553011E8072 for ; Wed, 25 Jul 2012 18:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.793 X-Spam-Level: X-Spam-Status: No, score=-109.793 tagged_above=-999 required=5 tests=[AWL=0.456, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YKneQvWzGLX9 for ; Wed, 25 Jul 2012 18:01:15 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id B755821F8605 for ; Wed, 25 Jul 2012 18:01:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6Q11DuZ014266 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 26 Jul 2012 03:01:13 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Thu, 26 Jul 2012 03:01:13 +0200 From: "DRAGE, Keith (Keith)" To: "soc@ietf.org" Date: Thu, 26 Jul 2012 03:01:11 +0200 Thread-Topic: Alignment of priority and emergency call handling Thread-Index: Ac1qye36rAWSTp6cQIKXrdyt5rnJEw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 x-scanned-by: MIMEDefang 2.69 on 155.132.188.83 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 25 Jul 2012 18:03:00 -0700 Subject: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 01:01:15 -0000 5.10.1 of draft-ietf-soc-overload-control-09 contains the text: A SIP client SHOULD honor the local policy for prioritizing SIP requests such as policies based on the content of the Resource- Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may indicate high priority requests that should be preserved as much as possible during overload. The RPH contents can also indicate a low-priority request that is eligible to be dropped during times of overload. Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization. Local policy could also include giving precedence to mid-dialog SIP requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A local policy can be expected to combine both the SIP request type and the prioritization markings, and SHOULD be honored when overload conditions prevail. While draft-ietf-soc-load-control-event-package-03 covers priority, it does= not say anything specifically about emergency calls, see as follows: In addition, whatever the actual policy is, SIP servers SHOULD honor the Resource-Priority Header (RPH) [RFC4412] when processing messages. The RPH contents may indicate high priority requests that should be preserved as much as possible, or low priority requests that could be dropped during overload. SIP request rejection and message prioritization at an overloaded server are also discussed in Section 5.1 of [I-D.ietf-soc-overload-control] It would therefore appear sensible that the two drafts are aligned. Regards Keith From vkg@bell-labs.com Thu Jul 26 05:48:40 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C58A21F856D for ; Thu, 26 Jul 2012 05:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.756 X-Spam-Level: X-Spam-Status: No, score=-109.756 tagged_above=-999 required=5 tests=[AWL=0.843, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vCSFfCqiiC5 for ; Thu, 26 Jul 2012 05:48:36 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 4D26721F85E6 for ; Thu, 26 Jul 2012 05:48:35 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q6QCmYgL024060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Jul 2012 07:48:34 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6QCmYbY010665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 26 Jul 2012 07:48:34 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6QCmY3V026411 for ; Thu, 26 Jul 2012 07:48:34 -0500 (CDT) Message-ID: <50113CA3.4030202@bell-labs.com> Date: Thu, 26 Jul 2012 07:48:35 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: sip-overload@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 12:48:40 -0000 Keith: Please see inline. On 07/25/2012 08:01 PM, DRAGE, Keith (Keith) wrote: > 5.10.1 of draft-ietf-soc-overload-control-09 contains the text: > > A SIP client SHOULD honor the local policy for prioritizing SIP > requests such as policies based on the content of the Resource- > Priority header (RPH, RFC4412 [RFC4412]). Specific (namespace.value) > RPH contents may indicate high priority requests that should be > preserved as much as possible during overload. The RPH contents can > also indicate a low-priority request that is eligible to be dropped > during times of overload. Other indicators, such as the SOS URN > [RFC5031] indicating an emergency request, may also be used for > prioritization. > > Local policy could also include giving precedence to mid-dialog SIP > requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A > local policy can be expected to combine both the SIP request type and > the prioritization markings, and SHOULD be honored when overload > conditions prevail. > > While draft-ietf-soc-load-control-event-package-03 covers priority, > itdoes not say anything specifically about emergency calls, see as follows: > > In addition, whatever the actual policy is, SIP > servers SHOULD honor the Resource-Priority Header (RPH) [RFC4412] > when processing messages. The RPH contents may indicate high > priority requests that should be preserved as much as possible, or > low priority requests that could be dropped during overload. SIP > request rejection and message prioritization at an overloaded server > are also discussed in Section 5.1 of [I-D.ietf-soc-overload-control] > > It would therefore appear sensible that the two drafts are aligned. draft-ietf-soc-overload-control-09 states that, "... Other indicators, such as the SOS URN [RFC5031] indicating an emergency request, may also be used for prioritization." Do we need to include other artifacts besides the SOS URN and RPH for emergency call handling? If so, can you please specify which ones? Thanks, - 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From keith.drage@alcatel-lucent.com Thu Jul 26 08:24:04 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569D321F8767 for ; Thu, 26 Jul 2012 08:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.802 X-Spam-Level: X-Spam-Status: No, score=-109.802 tagged_above=-999 required=5 tests=[AWL=0.447, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4z4k1APuBpM for ; Thu, 26 Jul 2012 08:24:00 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 497FC21F8715 for ; Thu, 26 Jul 2012 08:23:59 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6QFMPjn009631 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 26 Jul 2012 17:23:55 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 26 Jul 2012 17:23:22 +0200 From: "DRAGE, Keith (Keith)" To: "Gurbani, Vijay K (Vijay)" , "sip-overload@ietf.org" Date: Thu, 26 Jul 2012 17:23:21 +0200 Thread-Topic: [sip-overload] Alignment of priority and emergency call handling Thread-Index: Ac1rLQSO0nM8DNbkSAiUgqTSIAEYoQAFWXtw Message-ID: References: <50113CA3.4030202@bell-labs.com> In-Reply-To: <50113CA3.4030202@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 15:24:04 -0000 I do not believe you need to include other artifacts. Rather overload-control lists both RPH and sos URN, and the event package l= ists only RPH. Keith > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org= ] > On Behalf Of Vijay K. Gurbani > Sent: 26 July 2012 13:49 > To: sip-overload@ietf.org > Subject: Re: [sip-overload] Alignment of priority and emergency call > handling >=20 > Keith: Please see inline. >=20 > On 07/25/2012 08:01 PM, DRAGE, Keith (Keith) wrote: > > 5.10.1 of draft-ietf-soc-overload-control-09 contains the text: > > > > A SIP client SHOULD honor the local policy for prioritizing SIP > > requests such as policies based on the content of the Resource- > > Priority header (RPH, RFC4412 [RFC4412]). Specific > (namespace.value) > > RPH contents may indicate high priority requests that should be > > preserved as much as possible during overload. The RPH contents ca= n > > also indicate a low-priority request that is eligible to be dropped > > during times of overload. Other indicators, such as the SOS URN > > [RFC5031] indicating an emergency request, may also be used for > > prioritization. > > > > Local policy could also include giving precedence to mid-dialog SIP > > requests (re-INVITEs, UPDATEs, BYEs etc.) in times of overload. A > > local policy can be expected to combine both the SIP request type > and > > the prioritization markings, and SHOULD be honored when overload > > conditions prevail. > > > > While draft-ietf-soc-load-control-event-package-03 covers priority, > > itdoes not say anything specifically about emergency calls, see as > follows: > > > > In addition, whatever the actual policy is, SIP > > servers SHOULD honor the Resource-Priority Header (RPH) [RFC4412] > > when processing messages. The RPH contents may indicate high > > priority requests that should be preserved as much as possible, or > > low priority requests that could be dropped during overload. SIP > > request rejection and message prioritization at an overloaded serve= r > > are also discussed in Section 5.1 of [I-D.ietf-soc-overload-control= ] > > > > It would therefore appear sensible that the two drafts are aligned. >=20 > draft-ietf-soc-overload-control-09 states that, "... Other indicators, > such as the SOS URN [RFC5031] indicating an emergency request, may also > be used for prioritization." >=20 > Do we need to include other artifacts besides the SOS URN and RPH for > emergency call handling? If so, can you please specify which ones? >=20 > Thanks, >=20 > - 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} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ >=20 >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From vkg@bell-labs.com Thu Jul 26 09:03:50 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171D821F8615 for ; Thu, 26 Jul 2012 09:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.821 X-Spam-Level: X-Spam-Status: No, score=-109.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dNLTK0LFahgZ for ; Thu, 26 Jul 2012 09:03:46 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 41D1D21F8608 for ; Thu, 26 Jul 2012 09:03:46 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id q6QG3iQ2011682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 26 Jul 2012 11:03:44 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q6QG3iFN006030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2012 11:03:44 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q6QG3iX7021261; Thu, 26 Jul 2012 11:03:44 -0500 (CDT) Message-ID: <50116A60.8040600@bell-labs.com> Date: Thu, 26 Jul 2012 11:03:44 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: sip-overload@ietf.org References: <50113CA3.4030202@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2012 16:03:50 -0000 On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote: > I do not believe you need to include other artifacts. > > Rather overload-control lists both RPH and sos URN, and the event > package lists only RPH. So it is a simple matter of ensuring that the text in draft-ietf-soc-load-control-event-package is consistent with the text in draft-ietf-soc-overload-control? If so, Charles --- can you please take care of this in draft-ietf-soc-load-control-event-package? Thanks, - 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} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From jgunn6@csc.com Sun Jul 29 14:49:08 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4C711E80D2 for ; Sun, 29 Jul 2012 14:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.085 X-Spam-Level: X-Spam-Status: No, score=-2.085 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_43=0.6, MIME_BAD_LINEBREAK=0.5, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rbb8erlgmjQB for ; Sun, 29 Jul 2012 14:49:07 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 54E3F11E80C5 for ; Sun, 29 Jul 2012 14:49:07 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-85.messagelabs.com!1343598545!38588652!1 X-Originating-IP: [20.137.2.88] X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13741 invoked from network); 29 Jul 2012 21:49:05 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-7.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 29 Jul 2012 21:49:05 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6TLn4Hb008809 for ; Sun, 29 Jul 2012 17:49:04 -0400 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: <50116A60.8040600@bell-labs.com> References: <50116A60.8040600@bell-labs.com>, <50113CA3.4030202@bell-labs.com> From: Janet P Gunn To: vkg@bell-labs.com Message-ID: Date: Sun, 29 Jul 2012 17:49:01 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP3 July 10, 2011 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP3|July 10, 2011) at 07/29/2012 17:49:01, Serialize complete at 07/29/2012 17:49:02, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/29/2012 05:45:12 PM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org, shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Jul 2012 21:49:08 -0000
I agree with Keith's comments about priority and emergency call= s.
=0D
 
=0D
I also have a number of other comments,= mostly editorial (I apologize for my lateness in responding).
=0D 
=0D

Introduction should stress that this approach is f= or situations where you can predict, in advance, a likely traffic surge, =0D
and its source/destination distribution.  For instance, it= is appropriate for a mass-phone-voting event, Mother's Day, New
=0D<= DIV>Years, and even a hurricane (there is usually some advance notice).&nbs= p;
=0D
However, it is less likely to be effective for the initial= phase of unpredicted/unpredictable mass calling events, such as
=0D<= DIV>earthquakes or terrorist attacks.  In these latter cases, the loca= l traffic load may peak by more than an order of magnitude =0D
in= minutes, if not seconds.  This does not allow time to either
effec= tively identify the filters needed, nor distribute then to the appropriate = servers, soon enough to prevent congestion
=0D
attack.  Once= other, more immediate, techniques (such as the loss-based or rate-based&nb= sp; methods) have prevented the initial
=0D
congestion collapse, = the event package can be used to effectively control the continuing overloa= d.
=0D
--
=0D
This sentence
 Load filtering wor= ks best if it prevents calls as close to
 the user agent clients as= possible.
=0D
could be clarified by including the word "originati= ng"
 Load filtering works best if it prevents calls as close to
=  the originating user agent clients as possible.
=0D
--
= =0D
There appears to be a cut and past error here
=0D
Secondly= , since we are describing a specific control
   mechanism base= d on filtering, the term "load control" in this
   specificati= on is used inter-changeably with the term "load filtering"
   = unless when associated with other explicit context. 
=0D
I s= uspect it is supposed to be
=0D
Secondly, since we are describing = a specific control
   mechanism based on filtering, the term "= load control" in this
   specification is used inter-changeabl= y with the term "load filtering"
   unless associated with oth= er explicit context.
--
 
I am not sure I understand this st= atement
=0D
This
   specification, however, does not = preclude the load control document
   defined here (Section 6)= to be extended in the future for other forms
   of control as= appropriate.
=0D
What sorts of "other forms of control" are you r= eferring to?  Presumably not service level and QoS control, as you hav= e
=0D
already defined them (or at least referred to them) as "loa= d control" but not "overload control".
--
=0D
 Section 3=0D
I think that
=0D
For destination-specific overload si= tuations, the load filter
      needs to be abl= e to describe the callee.
=0D
should be
=0D
For destinati= on-specific overload situations, the load filter
    = ;  should be able to specify the callee.
=0D
--
=0D
= This bullet
=0D
 To address accidental and intentional high-v= olume call generators,
      the load filter sh= ould allow to specify the caller.
=0D
does not use correct grammar= .
=0D
I suspect you mean
=0D
 To address accidental= and intentional high-volume call generators,
    &n= bsp; the load filter should be able to  specify the caller.
=0D--
With regard to this bullet,
=0D
   o  For = telephone numbers, it should be possible to specify prefixes
  = ;    which allow control over limited regionally-focused ove= rloads.
=0D
This is really an assumption rather than a requirement= .
=0D
Furthermore, I do not believe it is true.  In these day= s of number portability, and people retaining their original mobile
= =0D
phone number, as their primary number, when they move across the co= untry, the correlation between "telephone number prefix"
=0D
(aka= area code) and "physical location" is rapidly decreasing.
=0D
I a= gree that,for regional calling events, you need a way of identifying the ge= ographical location (originating and/or
=0D
terminating) to deter= mine which calls to filter.  But I do not think that area codes will c= ontinue to be the most effective
=0D
way of doing this.
=0D<= DIV>Perhaps an alternate wording would be=0D
   o = It should be possible to specify particular information in the SIP headers= (e.g., prefixes in telephone numbers)
      wh= ich allow control over limited regionally-focused overloads
---
=0D=
sec 4.2
 in this statement
=0D
 and that loads a= re allocated in a way which
   both prevents overload and mini= mizes the likelihood of network
   resource under-utilization.=
=0D
would it be better to say "maximizes effective throughput(aka= goodput)" instead of "minimizes the likelihood of network
   = resource under-utilization."?
=0D
---
=0D
sec 4.3
= =0D
 
=0D
Should this
=0D
In order for load filt= ers to be properly distributed, each SIP proxy
   server in th= e network is required to subscribe to the load control
   even= t package from all its outgoing signaling neighbors, known as
 &nbs= p; notifiers (Section 5.6).
=0D
be
=0D
In order for load = filters to be properly distributed, each SIP proxy
   server i= n the network SHOULD subscribe to the load control
   event pa= ckage from all its outgoing signaling neighbors, known as
   n= otifiers (Section 5.6).
? (not sure myself)
=0D

---
= =0D
For case II, perhaps "hurricane" (which has a more predictable, and= more gradual, increase in traffic) would be a better
=0D
example= than "earthquake", due to the issues mentioned above.
--
=0D
S= ec 5.3
=0D
In sec 4.4 you say
=0D
Another important aspec= t that affects the applicability of SIP load
   filtering is t= hat all possible signaling source neighbors need to
   partici= pate and enforce the designated filter.  Otherwise, a single
 =   non-conforming neighbor could make the whole control efforts useless=
   by pumping in excessive traffic to overload the server.=0D
But in section 5.3 you say
=0D
a subscriber may be inte= rested in some
   specific types of load control policy only. =
=0D
Maybe I am misunderstanding what you mean by "types of load c= ontrol policy", but the statement in 5.3 ("only interested in
=0Dsome") seem inconsistent with the statement in 4.3 ("all must participate"= ).  Perhaps you could add a clarifying statement.
=0D
---=0D
5.8
=0D
Modifications of existing load
   c= ontrol policies at the subscriber is performed after directly
 &nbs= p; receiving notifications containing updated load control policies.
= =0D
Grammar
either
... modifications ... are ...
or
...modi= fication ...is ...
=0D
but NOT
... modifications ... is ...=0D
---
5.11
=0D
This sentence
"Another factor usuall= y not known precisely or is
   computed automatically is the v= alidity duration of the load control
   event."
Seems to b= e a cut and paste error of some sort.
=0D
...
=0D
8.1
= Should this
"... administrative option for routing failed
  = ; call attempts to either Recorder Tone or a special announcement...."
b= e "Reorder Tone" instead of "Recorder Tone"?
=0D
 
=0D 
=0D
Janet
=0D
 
=0D


-----sip-overload-bounces@ietf.org wrote: ----- =0D
=0D
To: sip-o= verload@ietf.org
From: "Vijay K. Gurbani"
Sent by= : sip-overload-bounces@ietf.org
Date: 07/26/2012 12:03PM
Cc: shen@att= .com
Subject: Re: [sip-overload] Alignment of priority and emergency cal= l handling

On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote:
> = I do not believe you need to include other artifacts.
>
> Rathe= r overload-control lists both RPH and sos URN, and the event
> packag= e lists only RPH.

So it is a simple matter of ensuring that the text= in
draft-ietf-soc-load-control-event-package is consistent with the
= text in draft-ietf-soc-overload-control?

If so, Charles --- can you = please take care of this in
draft-ietf-soc-load-control-event-package?
Thanks,

- 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} / vijay.gurbani@alcatel-lucent= .com
Web:   http://ec= t.bell-labs.com/who/vkg/


=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
sip-overload mailing list
sip-overl= oad@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload


This is a PRIVAT= E message. If you are not the intended recipient, please delete without cop= ying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regar= dless of content, this e-mail shall not operate to bind CSC to any order or= other contract unless pursuant to explicit written agreement or government= initiative expressly permitting the use of e-mail for such purpose.= = = From charles.newyork@gmail.com Sun Jul 29 20:07:08 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7269111E8088 for ; Sun, 29 Jul 2012 20:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.827 X-Spam-Level: X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MANGLED_PAIN=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36iEj78HTleo for ; Sun, 29 Jul 2012 20:07:07 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id BAC9421F84E4 for ; Sun, 29 Jul 2012 20:07:06 -0700 (PDT) Received: by vcbfo14 with SMTP id fo14so4415258vcb.31 for ; Sun, 29 Jul 2012 20:07:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=m0A0NRFM1LabTN+4BcrZGIBsVA5TAFy68z2J6ohdVPA=; b=slKXtbqcw1mHnojJR0g/w0ABi6nkPd6utqpXDuoiobWRsnPg8rzZ49haC+FuO3mVkJ s5ewHrIKEHDeXmptfUX2jH/9LC5NlJzcL9j6sODg8qp0Zy/nafjW4txBB3o0VmIdgoCW 0AYfNIl53Dw2xLEXr7ktm2HuWlC+DsKts+YAnbzeG11Syjp1Cind+MX7ZXPVp7YnbWYX Vf7cfb61mAv0riy8uf+vlu/DEnu3XqGKlNCuKdaoz9ps06PvdJwrRLAVQWde+kQH4y9Y b7PHJyRR1ko350+QTiuWgNR/bkIQwFz6A4QFpIuRoQ/K5+7JpOe8aokYtMsyp/7ReM7X vgWA== Received: by 10.52.95.225 with SMTP id dn1mr8332001vdb.99.1343617626247; Sun, 29 Jul 2012 20:07:06 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.208.132 with HTTP; Sun, 29 Jul 2012 20:06:46 -0700 (PDT) In-Reply-To: <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <4FF1F1B6.2080406@ericsson.com> <3810_1341991999_4FFD2C3F_3810_124_1_88CAD1D4E8773F42858B58CAA28272A0049191@PEXCVZYM12.corporate.adroot.infra.ftgroup> <17665_1342544872_50059BE8_17665_7162_1_88CAD1D4E8773F42858B58CAA28272A004DFFD@PEXCVZYM12.corporate.adroot.infra.ftgroup> From: Charles Shen Date: Sun, 29 Jul 2012 23:06:46 -0400 X-Google-Sender-Auth: pGpboiMvWE6-6dD96d6IBdbjAvo Message-ID: To: bruno.chatras@orange.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Volker Hilt , "sip-overload@ietf.org" , Arata Koike , Henning Schulzrinne Subject: Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event-package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 03:07:08 -0000 Hi Bruno, sorry for the delayed response! I've updated the local number grouping text. For the multi-path filtering policy problem, since it will affect texts in multiple sections, I'd like to discuss a bit more in terms of the solution. Assuming the following scenario, P3A alice@p1 --- P1 --- P2 -- / \ --- P4 --- bob@p4 \ / P3B where P2 can reach bob through either P3A or P3B, the call identity in the existing policy does not distinguish the calls to bob@p4 through P3A from those through P3B. Therefore it would be good for the load control policy to include not only the call destination (e.g., bob@p4 in this case), but also through which path the call is routed. One possible solution could be to add a new sub-element called under the existing schema. In the simple case, the new element can be of the same type as the element in [RFC4745]. The contents of the element holds what you call target SIP entities. Using the same example above, server P1 may receive a policy containing the new element as below: Similarly server P2 may receive a policy containing the new element as belo= w: Then the call filtering can match both the call destination and the path (assuming either a SIP Route header is included, or a next hop SIP server is chosen dynamically). There is still a small problem though - if the new element is defined as one of element in RFC4745, then the sub-elements under it are not ordered, while here we seem to need an ordered list (as in the list of SIP Route headers). Therefore, we might have to define new rules for the element to make its sub-elements ordered. Any thoughts? Charles On Tue, Jul 17, 2012 at 1:07 PM, wrote: > Hi Charles, > > See below. > >> -----Message d'origine----- >> De : charles.newyork@gmail.com [mailto:charles.newyork@gmail.com] De la >> part de Charles Shen >> Envoy=C3=A9 : mardi 17 juillet 2012 18:37 >> =C3=80 : CHATRAS Bruno RD-CORE >> Cc : Salvatore Loreto; sip-overload@ietf.org; Volker Hilt; Henning >> Schulzrinne; Arata Koike >> Objet : Re: [sip-overload] WGLC: draft-ietf-soc-oload-control-event- >> package >> >> Hi Bruno, thank you so much for the detailed review and comments! I've >> addressed 8 out of the total 10, except the following two which I'd >> appreciate more clarification. >> >> > 2) Section 5.8, line 525-528 >> > >> > The current text suggests that incoming requests are filtered >> irrespective of their actual destination. The subscriber should rather >> apply filters on requests that are outgoing to the pre-overloaded >> destination. One solution would be to rephrase the following text: >> > >> > "A subscriber receiving the notification first installs these rules >> and then filter incoming requests to enforce actions on appropriate >> requests, for example, limiting the sending rate of call requests >> destined for a specific SIP entity." >> > >> > With >> > >> > "A subscriber receiving the notification first installs these rules >> and then filter outgoing requests towards the notifier to enforce >> actions on appropriate requests, for example, limiting the sending rate >> of call requests destined for a specific SIP entity." >> > >> > This would however not permit the use of external state agents as >> described in section 5.12. Therefore it seems that a "target sip entity" >> parameter should be added to overload control documents. >> > >> >> I think I might have not understood your point. The requests are >> filtered based on the call identities, which can convey information >> including the call destination. Could you elaborate what this "target >> sip entity" is exactly for? > [BC] > > Let's take two examples that I think are not covered by the current wordi= ng. > > 1) Example 1 > > Call configuration: A is connected so SP1, B is connected to SP2. SP1 and= SP2 are connected via SP3. SP3 is connected to an Application Server (AS).= Under normal load conditions, a call from A to B is routed along the follo= wing path: A-SP1-SP3-AS-SP2-B. The AS provides a non-essential service and = can be bypassed in case of overload. > > Now let's assume that AS is overloaded and sends to SP3 a filter requesti= ng that 50% of INVITE messages be dropped, regardless of the contents of th= e from/to/PAI/R-URI. > > According to the current wording, SP3 will indeed filter 50% of the INVIT= E requests while they could be routed to B via SP2. > > 2) Example 2 > > Call Configuration: An 800 translation service is installed on two Applic= ation Servers AS-1 and AS-2. A is connected to SP1 and calls 800 1234 4529,= which is translated by AS-1 and AS-2 into a regular E164 number, depending= on e.g. the caller's location. SP1 forwards INVITE requests with R-URI =3D= "800 number" to AS-1 or AS-2 based on a load balancing strategy. > > As calls to 800 1234 4529 creates a pre-overload condition in AS-1, AS-1 = sends to SP-1 a filter requesting that 50% of calls towards 800 1234 4529 b= e rejected. > > According to the current wording, SP3 will apply the filter on incoming I= NVITE requests, irrespective of whether they are intended to be sent to AS1= or AS2. > > =3D=3D> It seems that these use cases could be solved by applying the fil= ters to outgoing requests (not incoming requests) that are to be routed to = the AS that sent these filters. This means that the SP has to store the AS = address together with the received filters or this address has to be includ= ed explicitly as a new filter criteria. > >> >> >> > 5) Section 6.3.1, local number grouping: >> > >> > The proposed solution for local numbers is not suitable. For example, >> if the phone-context for short service numbers in a country is the >> country code, the solution does not permit to define a filter that >> excludes all E.164 numbers in that country but retain all short service >> numbers. I think we should either define another solution or state that >> grouping of local numbers is not supported or state that grouping of >> local numbers only works under specific assumptions on the use of phone- >> context values. >> > >> >> How about adding the following text? >> >> It should be noted that the method of grouping local numbers as >> defined in this document does not support all cases. For example, if >> the phone-context for short service numbers in a country is the >> country code, this solution does not permit to define a filter that >> excludes all E.164 numbers in that country but retain all short >> service numbers. A complete solution for local number grouping >> requires a separate method outside the scope of this document. > [BC] > > Looks OK for me. > > >> >> >> Thanks! >> >> Charles >> >> >> On Wed, Jul 11, 2012 at 3:33 AM, wrote: >> > Hi! >> > >> > Here are my comments about this I-D. >> > >> > 1) Section 4.3, move paragraph 7 (line 376 - 386) after paragraph 5 >> (i.e. after line 360) and modifies the first two sentences as follows: >> > >> > "In the above case, the network entity where load filtering policy is >> first introduced is the SIP server providing access to the resource that >> creates the overload condition. In other cases, the network entry point >> of load filtering policy could also be an entity that hosts this >> resource. " >> > >> > 2) Section 5.8, line 525-528 >> > >> > The current text suggests that incoming requests are filtered >> irrespective of their actual destination. The subscriber should rather >> apply filters on requests that are outgoing to the pre-overloaded >> destination. One solution would be to rephrase the following text: >> > >> > "A subscriber receiving the notification first installs these rules >> and then filter incoming requests to enforce actions on appropriate >> requests, for example, limiting the sending rate of call requests >> destined for a specific SIP entity." >> > >> > With >> > >> > "A subscriber receiving the notification first installs these rules >> and then filter outgoing requests towards the notifier to enforce >> actions on appropriate requests, for example, limiting the sending rate >> of call requests destined for a specific SIP entity." >> > >> > This would however not permit the use of external state agents as >> described in section 5.12. Therefore it seems that a "target sip entity" >> parameter should be added to overload control documents. >> > >> > 3) Section 5.8, add the following text (adapted from draft-ietf-soc- >> overload-control) after line 537: >> > >> > "When enforcing actions on requests matching the filters, subscribers >> SHOULD honor the local policy for prioritizing SIP requests such as >> policies based on the content of the Resource-Priority header (RPH, >> RFC4412 [RFC4412]). Specific (namespace.value) RPH contents may >> indicate high priority requests that should be preserved as much as >> possible during overload. The RPH contents can also indicate a low- >> priority request that is eligible to be dropped during times of overload= . >> Other indicators, such as the SOS URN [RFC5031] indicating an emergency >> request, may also be used for prioritization." >> > >> > 4) Section 6.3.1, matching identities: After line 699, add the >> following text: >> > >> > "Before evaluating call-identity conditions, the subscriber shall >> convert URIs received in SIP header fields in canonical form as per RFC >> 3261, except that the phone-context parameter shall not be removed, if >> present." >> > >> > 5) Section 6.3.1, local number grouping: >> > >> > The proposed solution for local numbers is not suitable. For example, >> if the phone-context for short service numbers in a country is the >> country code, the solution does not permit to define a filter that >> excludes all E.164 numbers in that country but retain all short service >> numbers. I think we should either define another solution or state that >> grouping of local numbers is not supported or state that grouping of >> local numbers only works under specific assumptions on the use of phone- >> context values. >> > >> > 6) Section 6.3.1, line 746 - 753, remove the last but one sentence and >> reword the rest of the text accordingly. Reason: The use of local number >> 'tel' URI in the R-URI and To header field is not rare. In several >> countries, short numbers are used quite extensively to access special >> services. >> > >> > "Second, use of the local number 'tel' URI in practice is expected to >> be rare." >> > >> > 7) Clause 6.3.3, after line 800, add: >> > >> > "SUBSCRIBE requests are not filtered if the event-type header field >> indicates the event package defined in this document." >> > >> > 8) Section 7, line 985 - 990: replace "call type" with "call identity >> type" (3 times) >> > >> > 9) Section 8.1 >> > >> > Line 1048, add "except in specific cases when the Intelligent Network >> architecture is used [AINGR]. >> > >> > Line 1060, remove the last part of the first sentence starting with >> "and the number of prefix to be matched.": ITU IN specifications allow >> for dynamic sets. >> > >> > Line 1068, remove the last part of the first sentence staring with >> "with a fixed set.": Reason: ITU IN specifications allow for dynamic >> sets. >> > >> > 10) Miscellaneous points >> > Section 1, line 106, replace RFC3265 with RFC3261 >> > Section 4.1, line 231, replace "proxy" with "node" (this text should >> apply to any type of SIP entity) >> > Section 4.3, line 265, replace "proxy" with "node" (this text should >> apply to any type of SIP entity) >> > Section 4.3, Line 341, replace "singling" with "signaling" >> > Section 4.3, Line 342, replace "all signaling relationship in Figure 1 >> is" with "all signaling relationships in Figure 1 are" >> > Section 5.6, Line 503, add "request" after "SUBSCRIBE" >> > Section 5.11, Line 585, remove "is" >> > Section 6.5, Line 851, replace "vliad" with "valid" >> > >> > Bruno >> > >> > >> >> -----Message d'origine----- >> >> De : sip-overload-bounces@ietf.org [mailto:sip-overload- >> bounces@ietf.org] >> >> De la part de Salvatore Loreto >> >> Envoy=C3=A9 : lundi 2 juillet 2012 21:09 >> >> =C3=80 : sip-overload@ietf.org >> >> Cc : Volker Hilt >> >> Objet : [sip-overload] WGLC: draft-ietf-soc-oload-control-event- >> package >> >> >> >> [as chair] >> >> >> >> based on the mailing list discussion and the one we had during the >> last >> >> SoC f2f meeting in Paris, >> >> the chairs think the draft-ietf-soc-oload-control-event-package is >> ready >> >> for the WGLC. >> >> >> >> Today we are starting a two-week working group last call. >> >> This call ends on Wednesday, July 16th. >> >> >> >> the last version of the document can be retrieved here: >> >> http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package- >> 03 >> >> >> >> >> >> reviews and comments are really appreciate and requested from all the >> >> participants >> >> >> >> >> >> cheers >> >> /Sal >> >> >> >> -- >> >> Salvatore Loreto, PhD >> >> www.sloreto.com >> >> >> >> _______________________________________________ >> >> sip-overload mailing list >> >> sip-overload@ietf.org >> >> https://www.ietf.org/mailman/listinfo/sip-overload >> > >> > >> ________________________________________________________________________ >> _________________________________________________ >> > >> > Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> > a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> > France Telecom - Orange decline toute responsabilite si ce message a >> ete altere, deforme ou falsifie. Merci. >> > >> > This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> > they should not be distributed, used or copied without authorisation. >> > If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> > As emails may be altered, France Telecom - Orange is not liable for >> messages that have been modified, changed or falsified. >> > Thank you. >> > >> > _______________________________________________ >> > sip-overload mailing list >> > sip-overload@ietf.org >> > https://www.ietf.org/mailman/listinfo/sip-overload > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > France Telecom - Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, France Telecom - Orange is not liable for messa= ges that have been modified, changed or falsified. > Thank you. > From charles.newyork@gmail.com Sun Jul 29 20:09:10 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D286F21F851E for ; Sun, 29 Jul 2012 20:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.383, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iEYS0YpyPIFy for ; Sun, 29 Jul 2012 20:09:10 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E9D9D21F84E4 for ; Sun, 29 Jul 2012 20:09:09 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4468891vbb.31 for ; Sun, 29 Jul 2012 20:09:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=XapBh4PPUbmXq6iA+0gzF6ds7gUqaePXbtZTnxS3cZM=; b=Gu3G0yDqtPTuqlf7YFRKQ02kJFNH9ffOtuetYceSHEsGG+ejvn0mqh9pFP1KvNo0ep wz1dXKFXpu51VRFotpvrfhS3suAiXzSrrHSScHPHv3NrCNbn6WxjiJxHEayX0JaHaMcs O9/Cso6adJ4cywP0lbDQgILFDTO1J+YZqSbZUXYxaSozDfFe7bPcsM9tu8MxyBfoCxKd z3ICASSz8HuW7RgH0Kiw6nKd78baCfiigbMyUVlXLmF3MdF2UCIV3b3KCJwy7dhL6aMi ZPe2SyIEOQa8fBP/X2r/gewvKH7NuP/VG9bF5hYkGuS6+bRaxaE1I23gj5GZglP23FHo W+Ug== Received: by 10.52.22.38 with SMTP id a6mr8510769vdf.37.1343617749464; Sun, 29 Jul 2012 20:09:09 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.208.132 with HTTP; Sun, 29 Jul 2012 20:08:49 -0700 (PDT) In-Reply-To: <50116A60.8040600@bell-labs.com> References: <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> From: Charles Shen Date: Sun, 29 Jul 2012 23:08:49 -0400 X-Google-Sender-Auth: BQ-ij9v4n0p8fBX6dcJoVBFQ9F4 Message-ID: To: "Vijay K. Gurbani" Content-Type: text/plain; charset=UTF-8 Cc: shen@att.com, sip-overload@ietf.org Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 03:09:10 -0000 Hi Vijay, I will do. Thanks Charles On Thu, Jul 26, 2012 at 12:03 PM, Vijay K. Gurbani wrote: > On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote: >> >> I do not believe you need to include other artifacts. >> >> Rather overload-control lists both RPH and sos URN, and the event >> package lists only RPH. > > > So it is a simple matter of ensuring that the text in > draft-ietf-soc-load-control-event-package is consistent with the > text in draft-ietf-soc-overload-control? > > If so, Charles --- can you please take care of this in > draft-ietf-soc-load-control-event-package? > > > Thanks, > > - 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} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From charles.newyork@gmail.com Sun Jul 29 20:35:46 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C813A11E8104 for ; Sun, 29 Jul 2012 20:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=-0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcWigFZrE7iR for ; Sun, 29 Jul 2012 20:35:43 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D787F21F8442 for ; Sun, 29 Jul 2012 20:35:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so4482276vbb.31 for ; Sun, 29 Jul 2012 20:35:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=OHprfQTyO6SQfwJfD2JS5vDaSAt4Lj8zRI/d8nP0I1w=; b=Rz1Ixn3gmAOEgpASDopP6bqqyy/B8A+/QEhl6l0q39ZCaFHowaGYGjRs2rt1BCY5To JQbtHxJB/TXxuqQ+8KhDYsji2ph+PgfmNUmDdU2ITkjDp7PrErXF/rcj86hQc5qlXwhT nt5VnNt6cP4XmLiFJ9K5KglvMNvnHN7w2Yk6gPzREK2YwLuBZqwEDnKjJWB2bigRfVi7 RYjomRV4SvJcHh0Re+qEJZFEnmKcKM/1IdZAbZZ8yekXrjC6Fx8mmYSRg/UlV+rjW+zU VsaOySO7iacunSlqOUCKhm/P9ytX5Lru6O35Mc81tRla7kMUhLdyUCLYcRDiCDxTQcUE nwAw== Received: by 10.52.22.38 with SMTP id a6mr8551637vdf.37.1343619342330; Sun, 29 Jul 2012 20:35:42 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.58.208.132 with HTTP; Sun, 29 Jul 2012 20:35:22 -0700 (PDT) In-Reply-To: References: <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> From: Charles Shen Date: Sun, 29 Jul 2012 23:35:22 -0400 X-Google-Sender-Auth: mXXjuJj0HIdDGMqqn3HdF87yPHc Message-ID: To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 Cc: sip-overload@ietf.org, shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 03:35:46 -0000 Hi Janet, thank you very much for your detailed comments! I've incorporated them in the new revision. Also please see response inline. On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn wrote: > I agree with Keith's comments about priority and emergency calls. > done > I also have a number of other comments, mostly editorial (I apologize for my > lateness in responding). > > > Introduction should stress that this approach is for situations where you > can predict, in advance, a likely traffic surge, > and its source/destination distribution. For instance, it is appropriate > for a mass-phone-voting event, Mother's Day, New > Years, and even a hurricane (there is usually some advance notice). > However, it is less likely to be effective for the initial phase of > unpredicted/unpredictable mass calling events, such as > earthquakes or terrorist attacks. In these latter cases, the local traffic > load may peak by more than an order of magnitude > in minutes, if not seconds. This does not allow time to either > effectively identify the filters needed, nor distribute then to the > appropriate servers, soon enough to prevent congestion > attack. Once other, more immediate, techniques (such as the loss-based or > rate-based methods) have prevented the initial > congestion collapse, the event package can be used to effectively control > the continuing overload. > -- agree. > This sentence > Load filtering works best if it prevents calls as close to > the user agent clients as possible. > could be clarified by including the word "originating" > Load filtering works best if it prevents calls as close to > the originating user agent clients as possible. > -- right > There appears to be a cut and past error here > Secondly, since we are describing a specific control > mechanism based on filtering, the term "load control" in this > specification is used inter-changeably with the term "load filtering" > unless when associated with other explicit context. > I suspect it is supposed to be > Secondly, since we are describing a specific control > mechanism based on filtering, the term "load control" in this > specification is used inter-changeably with the term "load filtering" > unless associated with other explicit context. > -- > right > I am not sure I understand this statement > This > specification, however, does not preclude the load control document > defined here (Section 6) to be extended in the future for other forms > of control as appropriate. > What sorts of "other forms of control" are you referring to? Presumably not > service level and QoS control, as you have > already defined them (or at least referred to them) as "load control" but > not "overload control". > -- Yes, it could be confusing, so I removed this sentence. > Section 3 > I think that > For destination-specific overload situations, the load filter > needs to be able to describe the callee. > should be > For destination-specific overload situations, the load filter > should be able to specify the callee. > -- agree. > This bullet > To address accidental and intentional high-volume call generators, > the load filter should allow to specify the caller. > does not use correct grammar. > I suspect you mean > To address accidental and intentional high-volume call generators, > the load filter should be able to specify the caller. > -- agree > With regard to this bullet, > o For telephone numbers, it should be possible to specify prefixes > which allow control over limited regionally-focused overloads. > This is really an assumption rather than a requirement. > Furthermore, I do not believe it is true. In these days of number > portability, and people retaining their original mobile > phone number, as their primary number, when they move across the country, > the correlation between "telephone number prefix" > (aka area code) and "physical location" is rapidly decreasing. > I agree that,for regional calling events, you need a way of identifying the > geographical location (originating and/or > terminating) to determine which calls to filter. But I do not think that > area codes will continue to be the most effective > way of doing this. > Perhaps an alternate wording would be > o It should be possible to specify particular information in the SIP > headers (e.g., prefixes in telephone numbers) > which allow control over limited regionally-focused overloads > --- agree > sec 4.2 > in this statement > and that loads are allocated in a way which > both prevents overload and minimizes the likelihood of network > resource under-utilization. > would it be better to say "maximizes effective throughput(aka goodput)" > instead of "minimizes the likelihood of network > resource under-utilization."? > --- agree > sec 4.3 > > Should this > In order for load filters to be properly distributed, each SIP proxy > server in the network is required to subscribe to the load control > event package from all its outgoing signaling neighbors, known as > notifiers (Section 5.6). > be > In order for load filters to be properly distributed, each SIP proxy > server in the network SHOULD subscribe to the load control > event package from all its outgoing signaling neighbors, known as > notifiers (Section 5.6). > ? (not sure myself) > > --- agree. > For case II, perhaps "hurricane" (which has a more predictable, and more > gradual, increase in traffic) would be a better > example than "earthquake", due to the issues mentioned above. > -- > Sec 5.3 > In sec 4.4 you say > Another important aspect that affects the applicability of SIP load > filtering is that all possible signaling source neighbors need to > participate and enforce the designated filter. Otherwise, a single > non-conforming neighbor could make the whole control efforts useless > by pumping in excessive traffic to overload the server. > But in section 5.3 you say > a subscriber may be interested in some > specific types of load control policy only. > Maybe I am misunderstanding what you mean by "types of load control policy", > but the statement in 5.3 ("only interested in > some") seem inconsistent with the statement in 4.3 ("all must participate"). > Perhaps you could add a clarifying statement. > --- Since the details of the subscription filter specification are not defined anyway, I removed this "For example" sentence to avoid the confusion. > 5.8 > Modifications of existing load > control policies at the subscriber is performed after directly > receiving notifications containing updated load control policies. > Grammar > either > ... modifications ... are ... > or > ...modification ...is ... > but NOT > ... modifications ... is ... > --- right > 5.11 > This sentence > "Another factor usually not known precisely or is > computed automatically is the validity duration of the load control > event." > Seems to be a cut and paste error of some sort. > ... Changed to " Another factor that is usually not known precisely or needs to be computed automatically is the validity duration of the load control event. " > 8.1 > Should this > "... administrative option for routing failed > call attempts to either Recorder Tone or a special announcement...." > be "Reorder Tone" instead of "Recorder Tone"? > > I think this is something like a recording machine playing something message, am I correct? thanks Charles > Janet > > > > -----sip-overload-bounces@ietf.org wrote: ----- > > To: sip-overload@ietf.org > From: "Vijay K. Gurbani" > Sent by: sip-overload-bounces@ietf.org > Date: 07/26/2012 12:03PM > Cc: shen@att.com > > Subject: Re: [sip-overload] Alignment of priority and emergency call > handling > > On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote: >> I do not believe you need to include other artifacts. >> >> Rather overload-control lists both RPH and sos URN, and the event >> package lists only RPH. > > So it is a simple matter of ensuring that the text in > draft-ietf-soc-load-control-event-package is consistent with the > text in draft-ietf-soc-overload-control? > > If so, Charles --- can you please take care of this in > draft-ietf-soc-load-control-event-package? > > Thanks, > > - 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} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to bind > CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From internet-drafts@ietf.org Sun Jul 29 21:25:57 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63D111E8118; Sun, 29 Jul 2012 21:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfSDt3XGbxCa; Sun, 29 Jul 2012 21:25:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58B111E810F; Sun, 29 Jul 2012 21:25:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.32 Message-ID: <20120730042556.9790.54360.idtracker@ietfa.amsl.com> Date: Sun, 29 Jul 2012 21:25:56 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-load-control-event-package-04.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 04:25:57 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of the= IETF. Title : A Session Initiation Protocol (SIP) Load Control Event P= ackage Author(s) : Charles Shen Henning Schulzrinne Arata Koike Filename : draft-ietf-soc-load-control-event-package-04.txt Pages : 35 Date : 2012-07-29 Abstract: We define a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute load filters to other SIP servers in the network. The load filters 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-load-control-event-package-04 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-load-control-event-pack= age-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From adam@nostrum.com Mon Jul 30 10:27:19 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE6511E816B for ; Mon, 30 Jul 2012 10:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hu1uuMUq1US7 for ; Mon, 30 Jul 2012 10:27:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81C11E8168 for ; Mon, 30 Jul 2012 10:27:17 -0700 (PDT) Received: from dhcp-1418.meeting.ietf.org (dhcp-1418.meeting.ietf.org [130.129.20.24]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id q6UHRD48075617 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 30 Jul 2012 12:27:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <5016C3F1.4060709@nostrum.com> Date: Mon, 30 Jul 2012 10:27:13 -0700 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: draft-ietf-soc-load-control-event-package@tools.ietf.org Content-Type: multipart/alternative; boundary="------------010208020703070802050602" Received-SPF: pass (nostrum.com: 130.129.20.24 is authenticated by a trusted mechanism) Cc: "SOC \(SIP Overload Control\) WG" Subject: [sip-overload] Comments on SOC Event Package X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 17:27:19 -0000 This is a multi-part message in MIME format. --------------010208020703070802050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I apologize for coming in so late after WGLC with these comments. The first, and most important comment is that this document is presently based on the obsolete RFC3265. That document has been replaced by RFC 6665. This has a number of impacts. The first, most obvious one is that the references to the SIP events document need to be replaced to cite RFC6665 instead. This also necessitates that the section numbers cited in RFC3265 need to be updated to match the corresponding sections in 6665. If you have trouble figuring out where any specific bit of text went, I'll be happy to point you in the right direction. One of the concepts that is now deprecated by 6665 is sharing multiple subscriptions on the same dialog. This means that the final sentence of the second paragraph of section 4.3 (starting "The same subscription dialog can also be used...") needs to be removed. Section 5.12 can be removed. The concept of State Agents has been removed from 6665. Related to SIP events, but not the 6665 changes: I looked very carefully for an indication of which Request URI is supposed to be used in the SUBSCRIBE messages sent for this event package, but saw no guidance. I suspect that you want a URI of the form "sip:server.example.com" (i.e., without a user) where "server.example.com" represents the server whose overload state is being requested. Full example messages would help to make this clearer. The second paragraph on page 13 effectively turns the soft state mechanism of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as you can end up with a situation in which a communication disruption (say, a change in authentication) can lead to persistent throttling when it is not appropriate to do so. This artificially limits throughput, which is somewhat counter to what the overload control effort is supposed to do. What is the justification for keeping state beyond the duration of a subscription? The third paragraph on page 13 says that a NOTIFY request that does not contain a body MUST be ignored. In contrast, section 4.3 says that a notification includes an empty body indicates that no overload rules are in effect. These statements are in conflict with each other, unless you are intending to distinguish between a message containing an *empty* (but present) body, and a message that does not contain a body. If that's the distinction being made, you need to be far more explicit that such is the intention. I would strongly counsel against such a decision; even if the difference is made clear in the text, it is such a subtle distinction that it is unlikely to be implemented correctly. Unrelated to the 6665 issues, I have some additional comments. At the top of page 9, there is a statement that the proxies to which proxies should subscribe can be learned from the signaling messages sent and received. I think we need some guidance about when this learned information can be purged. Presumably we don't want a single interaction between proxies to result in a subscription that is kept in place for the rest of all time. Near the top of page 16, the document specifies that elements containing multiple , , and elements are ORed together. I don't think this is quite what you intend. If you have a and an , you don't really want to match everything that is in the OR everything excluded by the . I can kind of figure out what you really meant, but the language needs to be adjusted to actually say it. On page 19, one of the specified actions is "drop." There is passing implication that doing this over an unreliable link will cause retransmissions. This needs more treatment in the text. In fact, as dropping requests over an unreliable link will *always* make overload worse rather than better, I would strongly recommend that we add text that specifies that any "drop" rule applied to an unreliable transport MUST be treated as if it were "reject." Similarly, we run into an issue in which an ACK response to a 200 is dropped, as doing so will cause the 200 to be retransmitted, which again exacerbates any overload condition that may arise. In other words, I think we need to specify that "drop" cannot be applied to ACK (and reject clearly can't, since ACK never sees a response) -- so ACKs must always go through regardless of overload filters. For the same reason, proxies that receive an ACK response to a non-200 need to always process the ACK rather than dropping it. On to topic of rejects, I note that the current draft simply gives an example (500 Server Internal Error) rather than specifying how rejection is performed. This will make troubleshooting a system more difficult. I would suggest that we add a new 500-class error code that is used to indicate this specific situation. We also need to think about whether "Retry-After" handling is appropriate in this case. I think it is, but we need to work through how it is set (i.e., is it part of the overload rule, or is it set by the server itself?) Finally, I note that we have a "forward" rule. I think we would be well served by a very similar "redirect" rule that sends a 300-class response rather than forwarding the request to an alternate destination. Small editorial nit: while the use of the date "79 AD" in the example at the top of page 21 is both clever and amusing to those who have both received an education on the topic of Vesuvius' destruction of Pompeii and recall its details, the use of a two-digit year in an example is likely to lead to confusion on the part of implementors. We really don't need examples from which implementors might incorrectly infer that omitting the century portion of the year in ISO-style dates is acceptable. Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly we can cite an international specification for the discussion of call gapping -- doesn't Q.1248 cover this?. It seems a bit provincial to use a Bellcore spec to the exclusion of an ITU-T spec in the context of a document to be published by an international standards body such as the IETF. /a --------------010208020703070802050602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I apologize for coming in so late after WGLC with these comments.

The first, and most important comment is that this document is presently based on the obsolete RFC3265. That document has been replaced by RFC 6665. This has a number of impacts. The first, most obvious one is that the references to the SIP events document need to be replaced to cite RFC6665 instead. This also necessitates that the section numbers cited in RFC3265 need to be updated to match the corresponding sections in 6665. If you have trouble figuring out where any specific bit of text went, I'll be happy to point you in the right direction.

One of the concepts that is now deprecated by 6665 is sharing multiple subscriptions on the same dialog. This means that the final sentence of the second paragraph of section 4.3 (starting "The same subscription dialog can also be used...") needs to be removed.

Section 5.12 can be removed. The concept of State Agents has been removed from 6665.

Related to SIP events, but not the 6665 changes: I looked very carefully for an indication of which Request URI is supposed to be used in the SUBSCRIBE messages sent for this event package, but saw no guidance. I suspect that you want a URI of the form "sip:server.example.com" (i.e., without a user) where "server.example.com" represents the server whose overload state is being requested. Full example messages would help to make this clearer.

The second paragraph on page 13 effectively turns the soft state mechanism of SUBSCRIBE/NOTIFY into a hard-state mechanism. This is problematic, as you can end up with a situation in which a communication disruption (say, a change in authentication) can lead to persistent throttling when it is not appropriate to do so. This artificially limits throughput, which is somewhat counter to what the overload control effort is supposed to do. What is the justification for keeping state beyond the duration of a subscription?

The third paragraph on page 13 says that a NOTIFY request that does not contain a body MUST be ignored. In contrast, section 4.3 says that a notification includes an empty body indicates that no overload rules are in effect. These statements are in conflict with each other, unless you are intending to distinguish between a message containing an *empty* (but present) body, and a message that does not contain a body. If that's the distinction being made, you need to be far more explicit that such is the intention. I would strongly counsel against such a decision; even if the difference is made clear in the text, it is such a subtle distinction that it is unlikely to be implemented correctly.

Unrelated to the 6665 issues, I have some additional comments. At the top of page 9, there is a statement that the proxies to which proxies should subscribe can be learned from the signaling messages sent and received. I think we need some guidance about when this learned information can be purged. Presumably we don't want a single interaction between proxies to result in a subscription that is kept in place for the rest of all time.

Near the top of page 16, the document specifies that elements containing multiple <one>, <except>, and <many> elements are ORed together. I don't think this is quite what you intend. If you have a <many> and an <except>, you don't really want to match everything that is in the <many> OR everything excluded by the <exclude>. I can kind of figure out what you really meant, but the language needs to be adjusted to actually say it.

On page 19, one of the specified actions is "drop." There is passing implication that doing this over an unreliable link will cause retransmissions. This needs more treatment in the text. In fact, as dropping requests over an unreliable link will *always* make overload worse rather than better, I would strongly recommend that we add text that specifies that any "drop" rule applied to an unreliable transport MUST be treated as if it were "reject."

Similarly, we run into an issue in which an ACK response to a 200 is dropped, as doing so will cause the 200 to be retransmitted, which again exacerbates any overload condition that may arise. In other words, I think we need to specify that "drop" cannot be applied to ACK (and reject clearly can't, since ACK never sees a response) -- so ACKs must always go through regardless of overload filters. For the same reason, proxies that receive an ACK response to a non-200 need to always process the ACK rather than dropping it.

On to topic of rejects, I note that the current draft simply gives an example (500 Server Internal Error) rather than specifying how rejection is performed. This will make troubleshooting a system more difficult. I would suggest that we add a new 500-class error code that is used to indicate this specific situation. We also need to think about whether "Retry-After" handling is appropriate in this case. I think it is, but we need to work through how it is set (i.e., is it part of the overload rule, or is it set by the server itself?)

Finally, I note that we have a "forward" rule. I think we would be well served by a very similar "redirect" rule that sends a 300-class response rather than forwarding the request to an alternate destination.

Small editorial nit: while the use of the date "79 AD" in the example at the top of page 21 is both clever and amusing to those who have both received an education on the topic of Vesuvius' destruction of Pompeii and recall its details, the use of a two-digit year in an example is likely to lead to confusion on the part of implementors. We really don't need examples from which implementors might incorrectly infer that omitting the century portion of the year in ISO-style dates is acceptable.

Finally, I note that we cite GR-2938-CORE at the top of page 24. Certainly we can cite an international specification for the discussion of call gapping -- doesn't Q.1248 cover this?. It seems a bit provincial to use a Bellcore spec to the exclusion of an ITU-T spec in the context of a document to be published by an international standards body such as the IETF.

/a
--------------010208020703070802050602-- From salvatore.loreto@ericsson.com Mon Jul 30 14:21:45 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279B811E8087 for ; Mon, 30 Jul 2012 14:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.404 X-Spam-Level: X-Spam-Status: No, score=-106.404 tagged_above=-999 required=5 tests=[AWL=-0.155, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LXMzU73DexP2 for ; Mon, 30 Jul 2012 14:21:44 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 2689A21F849C for ; Mon, 30 Jul 2012 14:21:43 -0700 (PDT) X-AuditID: c1b4fb30-b7f916d000000bfb-78-5016fae6425e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7B.3A.03067.6EAF6105; Mon, 30 Jul 2012 23:21:42 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.264.0; Mon, 30 Jul 2012 23:21:42 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 4BFF42AE2 for ; Tue, 31 Jul 2012 00:21:42 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D692053088 for ; Tue, 31 Jul 2012 00:21:42 +0300 (EEST) Received: from dhcp-1553.meeting.ietf.org (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 1ECF4523EC for ; Tue, 31 Jul 2012 00:21:41 +0300 (EEST) Message-ID: <5016FAE4.6000002@ericsson.com> Date: Mon, 30 Jul 2012 14:21:40 -0700 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+Jvre6zX2IBBn9mmVjsf5rgwOixZMlP pgDGKC6blNSczLLUIn27BK6M3rNz2AveMlbc+rierYFxN2MXIyeHhICJxN3+x+wQtpjEhXvr 2boYuTiEBE4xSky+/I8RwtnAKPHz3GEmCOc6o8SjEx9ZEMo+rGCHc5b9XscKMoxXQFvi6uVp zCA2i4CqxI9HD5hAbDYBM4nnD7eAxUUFEiU+z7/BBFEvKHFy5hMWEFtEwFjiyOMtYAcKC2hK tJ05CVbDLGArcWHOdRYIW15i+9s5zBCHq0lcPbcJzBYS0JLoPdvJNIFRaBaSsbOQtM9C0r6A kXkVo3BuYmZOerm5XmpRZnJxcX6eXnHqJkZg0B7c8ttgB+Om+2KHGKU5WJTEefVU9/sLCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYOxTSt/ypnrHp/srsy8typz7cW9G3+OjIVtOH3q2/dS3 mYvteUVvNBetbG7Q/fL1oUvdvuQfGYtdlhUfv3RQ90/LKzmeV/p9ZitWuK38d7z5sOyJZfXG 3/a8StpeHdzkkpz5QP/cvon7Juew9DC8rJxg53Y34/IM6+X8nzq3vzyYeyG83bjk4X4tJZbi jERDLeai4kQAsEP2vCgCAAA= Subject: [sip-overload] slides for SoC meeting at IETF84 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 21:21:45 -0000 Hi there, all the slides that will be used during the tomorrow meeting have been uploaded. here the link: https://datatracker.ietf.org/meeting/84/materials.html cheers /Sal -- Salvatore Loreto, PhD www.sloreto.com From jgunn6@csc.com Mon Jul 30 15:03:37 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A1621F8653 for ; Mon, 30 Jul 2012 15:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.015 X-Spam-Level: X-Spam-Status: No, score=-3.015 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, J_CHICKENPOX_43=0.6, MIME_BAD_LINEBREAK=0.5, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYZwMDFfDcgC for ; Mon, 30 Jul 2012 15:03:35 -0700 (PDT) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id 79AD521F8650 for ; Mon, 30 Jul 2012 15:03:35 -0700 (PDT) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-11.tower-87.messagelabs.com!1343685812!13354564!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.2; banners=-,-,- X-VirusChecked: Checked Received: (qmail 22578 invoked from network); 30 Jul 2012 22:03:33 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-11.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2012 22:03:33 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id q6UM3Tlx001162 for ; Mon, 30 Jul 2012 18:03:30 -0400 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> From: Janet P Gunn To: charles@cs.columbia.edu Message-ID: Date: Mon, 30 Jul 2012 18:03:27 -0400 X-Mailer: Lotus Domino Web Server Release 8.5.2FP3 July 10, 2011 X-MIMETrack: Serialize by Notes Server on AMER-ML22/SRV/CSC(Release 8.5.2FP3|July 10, 2011) at 07/30/2012 18:03:27, Serialize complete at 07/30/2012 18:03:27, Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 07/30/2012 05:59:37 PM Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org, shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:03:37 -0000
Thanks
=0D
 
=0D
WRT the last comment - = "Reorder tone" is also known (at least in the US) as "fast busy".
=0D<= DIV>I agree that there might be "announcements"
=0D
but I do not k= now what you mean by "Recorder tone". Do you mean the tone that sometimes c= omes on just BEFORE an announcement?
=0D
 
=0D
Janet=
=0D

-----charles.newyork@gmail.com wrot= e: -----
=0D
=0D
To: Janet P Gunn/USA/CSC@CSC
From: Charles Shen
Sent by: charles.newyork@gmail.com
Date: 07/29/2012 11:35= PM
Cc: vkg@bell-labs.com, sip-overload@ietf.org, shen@att.com
Subject= : Re: [sip-overload] Alignment of priority and emergency call handling
<= BR>= Hi Janet, thank you very much for your detailed comments! I've
incorpora= ted them in the new revision. Also please see response
inline.

On= Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn <jgunn6@csc.com> wrote:> I agree with Keith's comments about priority and emergency calls.>

done

> I also have a number of other comments, mostl= y editorial (I apologize for my
> lateness in responding).
>>
> Introduction should stress that this approach is for situatio= ns where you
> can predict, in advance, a likely traffic surge,
&g= t; and its source/destination distribution.  For instance, it is appro= priate
> for a mass-phone-voting event, Mother's Day, New
> Yea= rs, and even a hurricane (there is usually some advance notice).
> Ho= wever, it is less likely to be effective for the initial phase of
> u= npredicted/unpredictable mass calling events, such as
> earthquakes o= r terrorist attacks.  In these latter cases, the local traffic
>= load may peak by more than an order of magnitude
> in minutes, if no= t seconds.  This does not allow time to either
> effectively ide= ntify the filters needed, nor distribute then to the
> appropriate se= rvers, soon enough to prevent congestion
> attack.  Once other, = more immediate, techniques (such as the loss-based or
> rate-based &n= bsp;methods) have prevented the initial
> congestion collapse, the ev= ent package can be used to effectively control
> the continuing overl= oad.
> --

agree.

> This sentence
>  Load = filtering works best if it prevents calls as close to
>  the use= r agent clients as possible.
> could be clarified by including the wo= rd "originating"
>  Load filtering works best if it prevents cal= ls as close to
>  the originating user agent clients as possible= .
> --

right

> There appears to be a cut and past er= ror here
> Secondly, since we are describing a specific control
&g= t;    mechanism based on filtering, the term "load control" in th= is
>    specification is used inter-changeably with the ter= m "load filtering"
>    unless when associated with other e= xplicit context.
> I suspect it is supposed to be
> Secondly, s= ince we are describing a specific control
>    mechanism ba= sed on filtering, the term "load control" in this
>    spec= ification is used inter-changeably with the term "load filtering"
> &= nbsp;  unless associated with other explicit context.
> --
&g= t;

right

> I am not sure I understand this statement
&g= t; This
>    specification, however, does not preclude the = load control document
>    defined here (Section 6) to be e= xtended in the future for other forms
>    of control as ap= propriate.
> What sorts of "other forms of control" are you referring= to?  Presumably not
> service level and QoS control, as you hav= e
> already defined them (or at least referred to them) as "load cont= rol" but
> not "overload control".
> --

Yes, it could be= confusing, so I removed this sentence.

>  Section 3
>= I think that
> For destination-specific overload situations, the loa= d filter
>       needs to be able to describe the call= ee.
> should be
> For destination-specific overload situations,= the load filter
>       should be able to specify the= callee.
> --

agree.

> This bullet
>  To = address accidental and intentional high-volume call generators,
> &nb= sp;     the load filter should allow to specify the caller.
&g= t; does not use correct grammar.
> I suspect you mean
>  T= o address accidental and intentional high-volume call generators,
> &= nbsp;     the load filter should be able to  specify the cal= ler.
> --

agree

> With regard to this bullet,
>= ;    o  For telephone numbers, it should be possible to spec= ify prefixes
>       which allow control over limited = regionally-focused overloads.
> This is really an assumption rather t= han a requirement.
> Furthermore, I do not believe it is true.  = In these days of number
> portability, and people retaining their ori= ginal mobile
> phone number, as their primary number, when they move = across the country,
> the correlation between "telephone number prefi= x"
> (aka area code) and "physical location" is rapidly decreasing.> I agree that,for regional calling events, you need a way of identify= ing the
> geographical location (originating and/or
> terminati= ng) to determine which calls to filter.  But I do not think that
&g= t; area codes will continue to be the most effective
> way of doing t= his.
> Perhaps an alternate wording would be
>    o &= nbsp;It should be possible to specify particular information in the SIP
= > headers (e.g., prefixes in telephone numbers)
>     &n= bsp; which allow control over limited regionally-focused overloads
> = ---

agree

> sec 4.2
>  in this statement
>= ;  and that loads are allocated in a way which
>    bo= th prevents overload and minimizes the likelihood of network
>  =  resource under-utilization.
> would it be better to say "maxim= izes effective throughput(aka goodput)"
> instead of "minimizes the l= ikelihood of network
>    resource under-utilization."?
= > ---

agree

> sec 4.3
>
> Should this
&g= t; In order for load filters to be properly distributed, each SIP proxy
= >    server in the network is required to subscribe to the loa= d control
>    event package from all its outgoing signalin= g neighbors, known as
>    notifiers (Section 5.6).
>= be
> In order for load filters to be properly distributed, each SIP = proxy
>    server in the network SHOULD subscribe to the lo= ad control
>    event package from all its outgoing signali= ng neighbors, known as
>    notifiers (Section 5.6).
>= ; ? (not sure myself)
>
> ---

agree.

> For cas= e II, perhaps "hurricane" (which has a more predictable, and more
> g= radual, increase in traffic) would be a better
> example than "earthq= uake", due to the issues mentioned above.
> --
> Sec 5.3
>= ; In sec 4.4 you say
> Another important aspect that affects the appl= icability of SIP load
>    filtering is that all possible s= ignaling source neighbors need to
>    participate and enfo= rce the designated filter.  Otherwise, a single
>    n= on-conforming neighbor could make the whole control efforts useless
>=    by pumping in excessive traffic to overload the server.
&g= t; But in section 5.3 you say
> a subscriber may be interested in som= e
>    specific types of load control policy only.
> = Maybe I am misunderstanding what you mean by "types of load control policy"= ,
> but the statement in 5.3 ("only interested in
> some") seem= inconsistent with the statement in 4.3 ("all must participate").
> P= erhaps you could add a clarifying statement.
> ---

Since the d= etails of the subscription filter specification are not
defined anyway, = I removed this "For example" sentence to avoid the
confusion.

> 5.8
> Modifications of existing load
>    contr= ol policies at the subscriber is performed after directly
>   &n= bsp;receiving notifications containing updated load control policies.
&g= t; Grammar
> either
> ... modifications ... are ...
> or<= BR>> ...modification ...is ...
> but NOT
> ... modifications= ... is ...
> ---

right

> 5.11
> This sentence=
> "Another factor usually not known precisely or is
>   &= nbsp;computed automatically is the validity duration of the load control>    event."
> Seems to be a cut and paste error of som= e sort.
> ...

Changed to "  Another factor that is usuall= y not known precisely or
needs to be computed automatically is the valid= ity duration of the
load control event.  "

> 8.1
> = Should this
> "... administrative option for routing failed
> &= nbsp;  call attempts to either Recorder Tone or a special announcement= ...."
> be "Reorder Tone" instead of "Recorder Tone"?
>
>=

I think this is something like a recording machine playing somethin= g
message, am I correct?

thanks

Charles


> Ja= net
>
>
>
> -----sip-overload-bounces@ietf.org wrot= e: -----
>
> To: sip-overload@ietf.org
> From: "Vijay K. = Gurbani"
> Sent by: sip-overload-bounces@ietf.org
> Date: 07/26= /2012 12:03PM
> Cc: shen@att.com
>
> Subject: Re: [sip-ov= erload] Alignment of priority and emergency call
> handling
>> On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote:
>> I do= not believe you need to include other artifacts.
>>
>> R= ather overload-control lists both RPH and sos URN, and the event
>>= ; package lists only RPH.
>
> So it is a simple matter of ensur= ing that the text in
> draft-ietf-soc-load-control-event-package is c= onsistent with the
> text in draft-ietf-soc-overload-control?
>=
> If so, Charles --- can you please take care of this in
> dra= ft-ietf-soc-load-control-event-package?
>
> Thanks,
>
= > - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcate= l-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (= USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-luc= ent.com
> Web:   h= ttp://ect.bell-labs.com/who/vkg/
>
>
> =5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
> sip-overload= mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listin= fo/sip-overload
>
>
>
> This is a PRIVATE messa= ge. If you are not the intended recipient, please
> delete without co= pying and kindly advise us by e-mail of the mistake in
> delivery. NO= TE: Regardless of content, this e-mail shall not operate to bind
> CS= C to any order or other contract unless pursuant to explicit written
>= ; agreement or government initiative expressly permitting the use of e-mail=
> for such purpose.
> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F
> sip-overload mailing list
> sip-o= verload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>=


This is a PRIVATE message. If you are not the intended recipient, please d= elete without copying and kindly advise us by e-mail of the mistake in deli= very. NOTE: Regardless of content, this e-mail shall not operate to bind CS= C to any order or other contract unless pursuant to explicit written agreem= ent or government initiative expressly permitting the use of e-mail for suc= h purpose.= = From keith.drage@alcatel-lucent.com Mon Jul 30 15:19:11 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1488011E820A for ; Mon, 30 Jul 2012 15:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.498 X-Spam-Level: X-Spam-Status: No, score=-109.498 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Avoq-n+LGlM3 for ; Mon, 30 Jul 2012 15:19:08 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id E755B11E81EB for ; Mon, 30 Jul 2012 15:19:07 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6UMIp6O010905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 31 Jul 2012 00:18:51 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 31 Jul 2012 00:18:51 +0200 From: "DRAGE, Keith (Keith)" To: Janet P Gunn , "charles@cs.columbia.edu" Date: Tue, 31 Jul 2012 00:18:49 +0200 Thread-Topic: [sip-overload] Alignment of priority and emergency call handling Thread-Index: Ac1unzIvT+RyxlJ4QhCpVmZIBQSc0wAAeQ8w Message-ID: References: , <50113CA3.4030202@bell-labs.com> <50116A60.8040600@bell-labs.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE240B548A0FRMRSSXCHMBSC3d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Cc: "shen@att.com" , "sip-overload@ietf.org" Subject: Re: [sip-overload] Alignment of priority and emergency call handling X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2012 22:19:11 -0000 --_000_EDC0A1AE77C57744B664A310A0B23AE240B548A0FRMRSSXCHMBSC3d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Can I suggest that we stick to the terminology available in ITU-T Recommend= ation E.182 (and E.180) as this U.S. terminology is very specific to the U.= S. and other terms are used elsewhere in world. Keith ________________________________ From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Janet P Gunn Sent: 30 July 2012 23:03 To: charles@cs.columbia.edu Cc: sip-overload@ietf.org; shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handli= ng Thanks WRT the last comment - "Reorder tone" is also known (at least in the US) as= "fast busy". I agree that there might be "announcements" but I do not know what you mean by "Recorder tone". Do you mean the tone th= at sometimes comes on just BEFORE an announcement? Janet -----charles.newyork@gmail.com wrote: ----- To: Janet P Gunn/USA/CSC@CSC From: Charles Shen Sent by: charles.newyork@gmail.com Date: 07/29/2012 11:35PM Cc: vkg@bell-labs.com, sip-overload@ietf.org, shen@att.com Subject: Re: [sip-overload] Alignment of priority and emergency call handli= ng Hi Janet, thank you very much for your detailed comments! I've incorporated them in the new revision. Also please see response inline. On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn wrote: > I agree with Keith's comments about priority and emergency calls. > done > I also have a number of other comments, mostly editorial (I apologize for= my > lateness in responding). > > > Introduction should stress that this approach is for situations where you > can predict, in advance, a likely traffic surge, > and its source/destination distribution. For instance, it is appropriate > for a mass-phone-voting event, Mother's Day, New > Years, and even a hurricane (there is usually some advance notice). > However, it is less likely to be effective for the initial phase of > unpredicted/unpredictable mass calling events, such as > earthquakes or terrorist attacks. In these latter cases, the local traff= ic > load may peak by more than an order of magnitude > in minutes, if not seconds. This does not allow time to either > effectively identify the filters needed, nor distribute then to the > appropriate servers, soon enough to prevent congestion > attack. Once other, more immediate, techniques (such as the loss-based o= r > rate-based methods) have prevented the initial > congestion collapse, the event package can be used to effectively control > the continuing overload. > -- agree. > This sentence > Load filtering works best if it prevents calls as close to > the user agent clients as possible. > could be clarified by including the word "originating" > Load filtering works best if it prevents calls as close to > the originating user agent clients as possible. > -- right > There appears to be a cut and past error here > Secondly, since we are describing a specific control > mechanism based on filtering, the term "load control" in this > specification is used inter-changeably with the term "load filtering" > unless when associated with other explicit context. > I suspect it is supposed to be > Secondly, since we are describing a specific control > mechanism based on filtering, the term "load control" in this > specification is used inter-changeably with the term "load filtering" > unless associated with other explicit context. > -- > right > I am not sure I understand this statement > This > specification, however, does not preclude the load control document > defined here (Section 6) to be extended in the future for other forms > of control as appropriate. > What sorts of "other forms of control" are you referring to? Presumably = not > service level and QoS control, as you have > already defined them (or at least referred to them) as "load control" but > not "overload control". > -- Yes, it could be confusing, so I removed this sentence. > Section 3 > I think that > For destination-specific overload situations, the load filter > needs to be able to describe the callee. > should be > For destination-specific overload situations, the load filter > should be able to specify the callee. > -- agree. > This bullet > To address accidental and intentional high-volume call generators, > the load filter should allow to specify the caller. > does not use correct grammar. > I suspect you mean > To address accidental and intentional high-volume call generators, > the load filter should be able to specify the caller. > -- agree > With regard to this bullet, > o For telephone numbers, it should be possible to specify prefixes > which allow control over limited regionally-focused overloads. > This is really an assumption rather than a requirement. > Furthermore, I do not believe it is true. In these days of number > portability, and people retaining their original mobile > phone number, as their primary number, when they move across the country, > the correlation between "telephone number prefix" > (aka area code) and "physical location" is rapidly decreasing. > I agree that,for regional calling events, you need a way of identifying t= he > geographical location (originating and/or > terminating) to determine which calls to filter. But I do not think that > area codes will continue to be the most effective > way of doing this. > Perhaps an alternate wording would be > o It should be possible to specify particular information in the SIP > headers (e.g., prefixes in telephone numbers) > which allow control over limited regionally-focused overloads > --- agree > sec 4.2 > in this statement > and that loads are allocated in a way which > both prevents overload and minimizes the likelihood of network > resource under-utilization. > would it be better to say "maximizes effective throughput(aka goodput)" > instead of "minimizes the likelihood of network > resource under-utilization."? > --- agree > sec 4.3 > > Should this > In order for load filters to be properly distributed, each SIP proxy > server in the network is required to subscribe to the load control > event package from all its outgoing signaling neighbors, known as > notifiers (Section 5.6). > be > In order for load filters to be properly distributed, each SIP proxy > server in the network SHOULD subscribe to the load control > event package from all its outgoing signaling neighbors, known as > notifiers (Section 5.6). > ? (not sure myself) > > --- agree. > For case II, perhaps "hurricane" (which has a more predictable, and more > gradual, increase in traffic) would be a better > example than "earthquake", due to the issues mentioned above. > -- > Sec 5.3 > In sec 4.4 you say > Another important aspect that affects the applicability of SIP load > filtering is that all possible signaling source neighbors need to > participate and enforce the designated filter. Otherwise, a single > non-conforming neighbor could make the whole control efforts useless > by pumping in excessive traffic to overload the server. > But in section 5.3 you say > a subscriber may be interested in some > specific types of load control policy only. > Maybe I am misunderstanding what you mean by "types of load control polic= y", > but the statement in 5.3 ("only interested in > some") seem inconsistent with the statement in 4.3 ("all must participate= "). > Perhaps you could add a clarifying statement. > --- Since the details of the subscription filter specification are not defined anyway, I removed this "For example" sentence to avoid the confusion. > 5.8 > Modifications of existing load > control policies at the subscriber is performed after directly > receiving notifications containing updated load control policies. > Grammar > either > ... modifications ... are ... > or > ...modification ...is ... > but NOT > ... modifications ... is ... > --- right > 5.11 > This sentence > "Another factor usually not known precisely or is > computed automatically is the validity duration of the load control > event." > Seems to be a cut and paste error of some sort. > ... Changed to " Another factor that is usually not known precisely or needs to be computed automatically is the validity duration of the load control event. " > 8.1 > Should this > "... administrative option for routing failed > call attempts to either Recorder Tone or a special announcement...." > be "Reorder Tone" instead of "Recorder Tone"? > > I think this is something like a recording machine playing something message, am I correct? thanks Charles > Janet > > > > -----sip-overload-bounces@ietf.org wrote: ----- > > To: sip-overload@ietf.org > From: "Vijay K. Gurbani" > Sent by: sip-overload-bounces@ietf.org > Date: 07/26/2012 12:03PM > Cc: shen@att.com > > Subject: Re: [sip-overload] Alignment of priority and emergency call > handling > > On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote: >> I do not believe you need to include other artifacts. >> >> Rather overload-control lists both RPH and sos URN, and the event >> package lists only RPH. > > So it is a simple matter of ensuring that the text in > draft-ietf-soc-load-control-event-package is consistent with the > text in draft-ietf-soc-overload-control? > > If so, Charles --- can you please take care of this in > draft-ietf-soc-load-control-event-package? > > Thanks, > > - 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} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > > > This is a PRIVATE message. If you are not the intended recipient, please > delete without copying and kindly advise us by e-mail of the mistake in > delivery. NOTE: Regardless of content, this e-mail shall not operate to b= ind > CSC to any order or other contract unless pursuant to explicit written > agreement or government initiative expressly permitting the use of e-mail > for such purpose. > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > This is a PRIVATE message. If you are not the intended recipient, please de= lete without copying and kindly advise us by e-mail of the mistake in deliv= ery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC= to any order or other contract unless pursuant to explicit written agreeme= nt or government initiative expressly permitting the use of e-mail for such= purpose. --_000_EDC0A1AE77C57744B664A310A0B23AE240B548A0FRMRSSXCHMBSC3d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Can I suggest that we stick to the terminology available in ITU= -T Recommendation E.182 (and E.180) as this U.= S. terminology is very specific to the U.S. and other terms are used elsewhere in world.

 

Keith

 

From:= sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 30 July 2012 23:03
To: charles@cs.columbia.edu<= br> Cc: sip-overload@ietf.org; shen@att.com
Subject: Re: [sip-overload] Alignment of priority and emergency call handling

 

Thanks

 

WRT the last comment - "Reorder tone" is als= o known (at least in the US) as "fast busy".

I agree that there might be "announcements"<= o:p>

but I do not know what you mean by "Recorder tone". Do you mean the tone that sometimes comes on just BEFORE an announcement?

 

Janet


-----charles.newyork@= gmail.com wrote: -----

To: Janet P Gunn/USA/CSC<= /st1:stockticker>@CSC
From: Charles Shen
Sent by: charles.newyork@gmail.com
Date: 07/29/2012 11:35PM
Cc: vkg@bell-labs.com, sip-overload@ietf.org, shen@att.com
Subject: Re: [sip-overload] Alignment of priority and emergency call handli= ng

Hi Janet, thank you very much for your detailed comments! I've
incorporated them in the new revision. Also please see response
inline.

On Sun, Jul 29, 2012 at 5:49 PM, Janet P Gunn <jgunn6@csc.com> wrote:=
> I agree with Keith's comments about priority and emergency calls.
>

done

> I also have a number of other comments, mostly editorial (I apologize = for my
> lateness in responding).
>
>
> Introduction should stress that this approach is for situations where = you
> can predict, in advance, a likely traffic surge,
> and its source/destination distribution.  For instance, it is appropriate
> for a mass-phone-voting event, Mother's Day, New
> Years, and even a hurricane (there is usually some advance notice). > However, it is less likely to be effective for the initial phase of > unpredicted/unpredictable mass calling events, such as
> earthquakes or terrorist attacks.  In these latter cases, the loc= al traffic
> load may peak by more than an order of magnitude
> in minutes, if not seconds.  This does not allow time to either > effectively identify the filters needed, nor distribute then to the > appropriate servers, soon enough to prevent congestion
> attack.  Once other, more immediate, techniques (such as the loss-based or
> rate-based  methods) have prevented the initial
> congestion collapse, the event package can be used to effectively cont= rol
> the continuing overload.
> --

agree.

> This sentence
>  Load filtering works best if it prevents calls as close to
>  the user agent clients as possible.
> could be clarified by including the word "originating"
>  Load filtering works best if it prevents calls as close to
>  the originating user agent clients as possible.
> --

right

> There appears to be a cut and past error here
> Secondly, since we are describing a specific control
>    mechanism based on filtering, the term "load control" in this
>    specification is used inter-changeably with the term "load filtering"
>    unless when associated with other explicit context.
> I suspect it is supposed to be
> Secondly, since we are describing a specific control
>    mechanism based on filtering, the term "load control" in this
>    specification is used inter-changeably with the term "load filtering"
>    unless associated with other explicit context.
> --
>

right

> I am not sure I understand this statement
> This
>    specification, however, does not preclude the load contro= l document
>    defined here (Section 6) to be extended in the future for other forms
>    of control as appropriate.
> What sorts of "other forms of control" are you referring to?  Presumably not
> service level and QoS control, as you have
> already defined them (or at least referred to them) as "load control" but
> not "overload control".
> --

Yes, it could be confusing, so I removed this sentence.

>  Section 3
> I think that
> For destination-specific overload situations, the load filter
>       needs to be able to describe the callee.
> should be
> For destination-specific overload situations, the load filter
>       should be able to specify the callee.
> --

agree.

> This bullet
>  To address accidental and intentional high-volume call generator= s,
>       the load filter should allow to specify the calle= r.
> does not use correct grammar.
> I suspect you mean
>  To address accidental and intentional high-volume call generator= s,
>       the load filter should be able to  specify t= he caller.
> --

agree

> With regard to this bullet,
>    o  For telephone numbers, it should be possible to specify prefixes
>       which allow control over limited regionally-focus= ed overloads.
> This is really an assumption rather than a requirement.
> Furthermore, I do not believe it is true.  In these days of numbe= r
> portability, and people retaining their original mobile
> phone number, as their primary number, when they move across the count= ry,
> the correlation between "telephone number prefix"
> (aka area code) and "physical location" is rapidly decreasin= g.
> I agree that,for regional calling events, you need a way of identifyin= g the
> geographical location (originating and/or
> terminating) to determine which calls to filter.  But I do not th= ink that
> area codes will continue to be the most effective
> way of doing this.
> Perhaps an alternate wording would be
>    o  It should be possible to specify particular information in the SIP
> headers (e.g., prefixes in telephone numbers)
>       which allow control over limited regionally-focus= ed overloads
> ---

agree

> sec 4.2
>  in this statement
>  and that loads are allocated in a way which
>    both prevents overload and minimizes the likelihood of network
>    resource under-utilization.
> would it be better to say "maximizes effective throughput(aka goodput)"
> instead of "minimizes the likelihood of network
>    resource under-utilization."?
> ---

agree

> sec 4.3
>
> Should this
> In order for load filters to be properly distributed, each SIP proxy >    server in the network is required to subscribe to the loa= d control
>    event package from all its outgoing signaling neighbors, known as
>    notifiers (Section 5.6).
> be
> In order for load filters to be properly distributed, each SIP proxy >    server in the network SHOULD subscribe to the load contro= l
>    event package from all its outgoing signaling neighbors, known as
>    notifiers (Section 5.6).
> ? (not sure myself)
>
> ---

agree.

> For case II, perhaps "hurricane" (which has a more predictab= le, and more
> gradual, increase in traffic) would be a better
> example than "earthquake", due to the issues mentioned above= .
> --
> Sec 5.3
> In sec 4.4 you say
> Another important aspect that affects the applicability of SIP load >    filtering is that all possible signaling source neighbors need to
>    participate and enforce the designated filter.  Otherwise, a single
>    non-conforming neighbor could make the whole control effo= rts useless
>    by pumping in excessive traffic to overload the server. > But in section 5.3 you say
> a subscriber may be interested in some
>    specific types of load control policy only.
> Maybe I am misunderstanding what you mean by "types of load contr= ol policy",
> but the statement in 5.3 ("only interested in
> some") seem inconsistent with the statement in 4.3 ("all mus= t participate").
> Perhaps you could add a clarifying statement.
> ---

Since the details of the subscription filter specification are not
defined anyway, I removed this "For example" sentence to avoid th= e
confusion.


> 5.8
> Modifications of existing load
>    control policies at the subscriber is performed after directly
>    receiving notifications containing updated load control policies.
> Grammar
> either
> ... modifications ... are ...
> or
> ...modification ...is ...
> but NOT
> ... modifications ... is ...
> ---

right

> 5.11
> This sentence
> "Another factor usually not known precisely or is
>    computed automatically is the validity duration of the lo= ad control
>    event."
> Seems to be a cut and paste error of some sort.
> ...

Changed to "  Another factor that is usually not known precisely = or
needs to be computed automatically is the validity duration of the
load control event.  "

> 8.1
> Should this
> "... administrative option for routing failed
>    call attempts to either Recorder Tone or a special announcement...."
> be "Reorder Tone" instead of "Recorder Tone"?
>
>

I think this is something like a recording machine playing something
message, am I correct?

thanks

Charles


> Janet
>
>
>
> -----sip-overload-bounces@ietf.org wrote: -----
>
> To: sip-overload@ietf.org
> From: "Vijay K. Gurbani"
> Sent by: sip-overload-bounces@ietf.org
> Date: 07/26/2012 12:03PM
> Cc: shen@att.com
>
> Subject: Re: [sip-overload] Alignment of priority and emergency call > handling
>
> On 07/26/2012 10:23 AM, DRAGE, Keith (Keith) wrote:
>> I do not believe you need to include other artifacts.
>>
>> Rather overload-control lists both RPH and sos URN, and the event<= br> >> package lists only RPH.
>
> So it is a simple matter of ensuring that the text in
> draft-ietf-soc-load-control-event-package is consistent with the
> text in draft-ietf-soc-overload-control?
>
> If so, Charles --- can you please take care of this in
> draft-ietf-soc-load-control-event-package?
>
> Thanks,
>
> - 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} / vijay.gurbani@alcatel-lucent.com<= br> > Web:   http://ect.b= ell-labs.com/who/vkg/
>
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/sip-overload
>
>
>
> This is a PRIVATE message. If you are not the intended recipient, plea= se
> delete without copying and kindly advise us by e-mail of the mistake i= n
> delivery. NOTE: Regardless of content, this e-mail shall not operate t= o bind
> CSC to any order or oth= er contract unless pursuant to explicit written
> agreement or government initiative expressly permitting the use of e-m= ail
> for such purpose.
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https:/= /www.ietf.org/mailman/listinfo/sip-overload
>



This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of = the mistake in delivery. NOTE: Regardless of content, this e-mail shall not ope= rate to bind CSC to any order or = other contract unless pursuant to explicit written agreement or government initia= tive expressly permitting the use of e-mail for such purpose.=

--_000_EDC0A1AE77C57744B664A310A0B23AE240B548A0FRMRSSXCHMBSC3d_-- From ietf@meetecho.com Mon Jul 30 23:31:22 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5604A21F85A8 for ; Mon, 30 Jul 2012 23:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.116 X-Spam-Level: X-Spam-Status: No, score=-0.116 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csxM2V4GFK5r for ; Mon, 30 Jul 2012 23:31:21 -0700 (PDT) Received: from smtplq04.aruba.it (smtplq-out6.aruba.it [62.149.158.26]) by ietfa.amsl.com (Postfix) with SMTP id CFAF721F859B for ; Mon, 30 Jul 2012 23:31:19 -0700 (PDT) Received: (qmail 27098 invoked by uid 89); 31 Jul 2012 06:31:17 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq04.aruba.it with SMTP; 31 Jul 2012 06:31:17 -0000 Received: (qmail 16837 invoked by uid 89); 31 Jul 2012 06:31:17 -0000 Received: from unknown (HELO ?172.16.1.102?) (alex@meetecho.com@209.82.28.249) by smtp2.ad.aruba.it with ESMTPA; 31 Jul 2012 06:31:16 -0000 Message-ID: <50177B9F.9050701@meetecho.com> Date: Tue, 31 Jul 2012 08:30:55 +0200 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:14.0) Gecko/20120713 Thunderbird/14.0 MIME-Version: 1.0 To: sip-overload@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtplq04.aruba.it 1.6.2 0/1000/N Subject: [sip-overload] Meetecho support for SOC WG X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 06:31:22 -0000 Hi all, a virtual room has been reserved on the Meetecho system for Tuesday's SOC WG meeting session. Access to the on-line session (including audio and video streams) will be available at: http://www.meetecho.com/ietf84/soc The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. Remote participants might also send their own voice to the room, if they want to, by either calling a landline phone number, or using our embedded VoIP applet (in this last case they are *strongly* advised to use a headset). A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf84 Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From volker.hilt@bell-labs.com Tue Jul 31 16:43:02 2012 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B1421F896D for ; Tue, 31 Jul 2012 16:43:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.582 X-Spam-Level: X-Spam-Status: No, score=-9.582 tagged_above=-999 required=5 tests=[AWL=0.667, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMYnC32lHRyQ for ; Tue, 31 Jul 2012 16:43:01 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 5582821F895B for ; Tue, 31 Jul 2012 16:43:01 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q6VNh0Hm007364 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 1 Aug 2012 01:43:00 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 1 Aug 2012 01:42:59 +0200 Received: from [135.244.35.105] (135.5.27.12) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 31 Jul 2012 19:42:56 -0400 Message-ID: <50186D7E.3040000@bell-labs.com> Date: Tue, 31 Jul 2012 16:42:54 -0700 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.12] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.84 Subject: [sip-overload] minutes X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jul 2012 23:43:02 -0000 Folks, I've just uploaded the minutes of today's meetings to the IETF Web site (big thanks to Keith for taking notes!). http://www.ietf.org/proceedings/84/minutes/minutes-84-soc Please let us know if you have any comments. Thanks, Volker