From vkg@bell-labs.com Fri May 17 14:11:09 2013 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 6D90F21F96E9 for ; Fri, 17 May 2013 14:11:09 -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 NjJCzq0w0o4K for ; Fri, 17 May 2013 14:11:04 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5D321F96C4 for ; Fri, 17 May 2013 14:11:04 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id r4HLB3OD011154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 17 May 2013 16:11:03 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r4HLB3nt024011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 17 May 2013 16:11:03 -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 r4HLB2p3012276; Fri, 17 May 2013 16:11:02 -0500 (CDT) Message-ID: <51969DBA.1050705@bell-labs.com> Date: Fri, 17 May 2013 16:14:34 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 MIME-Version: 1.0 To: Volker Hilt References: <51631B69.1010901@bell-labs.com> <517E7B7F.7030609@bell-labs.com> In-Reply-To: <517E7B7F.7030609@bell-labs.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] WG attention to 2 questions on draft-ietf-soc-overload-control-12 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, 17 May 2013 21:11:09 -0000 On 04/29/2013 08:54 AM, Volker Hilt wrote: > Vijay, All, > > here are my comments on the two questions: > > - oc-algo parameter: this parameter specifies the semantics of the oc > value and defines how that is to be interpreted by the receiver. It does > not define the algorithm used to compute the oc-algo parameter. The > important thing is that the receiver knows what it need to do with the > received oc parameter. This is reflected in the following statement in > the draft. Might be worth while to further clarify in the next rev of > the draft. > > The "oc-algo" parameter > contains a token or a list of tokens corresponding to the class of > overload control algorithms supported by the client. Volker: OK, I will add a clarifying paragraph at the end of S4.2 as follows: The "oc-algo" parameter does not define the exact algorithm to be used for traffic reduction, rather, the intent is to use any algorithm from a specific class of algorithms that affect traffic reduction similarly. For example, the reference algorithm in Section 6.3 can be used as a loss-based algorithm, or it can be substituted by any other loss-based algorithm that results in equivalent traffic reduction. > - I think the current writeup regarding the processing cycles dedicated > to upstream neighbors is fine. OK. Unless someone has any further feedback on the above text, I will -13 early next week and that version can be moved ahead. Thank you, - 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/ | Calendar: http://goo.gl/x3Ogq From internet-drafts@ietf.org Thu May 23 06:17:29 2013 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 86BF221F93D1; Thu, 23 May 2013 06:17:29 -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=[BAYES_00=-2.599, NO_RELAYS=-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 wsz2uONTU-Sn; Thu, 23 May 2013 06:17:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0521F90BB; Thu, 23 May 2013 06:17:28 -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.50 Message-ID: <20130523131728.14883.60390.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 06:17:28 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-control-13.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: Thu, 23 May 2013 13:17:29 -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-13.txt Pages : 35 Date : 2013-05-23 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-13 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-soc-overload-control-13 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From vkg@bell-labs.com Thu May 23 06:33:51 2013 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 79E9A21F93E6 for ; Thu, 23 May 2013 06:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.855 X-Spam-Level: X-Spam-Status: No, score=-109.855 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, 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 unhV8DSvc883 for ; Thu, 23 May 2013 06:33:47 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id DC6EA21F93E5 for ; Thu, 23 May 2013 06:33:46 -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 r4NDXjTY004422 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 23 May 2013 08:33:45 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r4NDXikN017816 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 23 May 2013 08:33:45 -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 r4NDXi9d000156 for ; Thu, 23 May 2013 08:33:44 -0500 (CDT) Message-ID: <519E1B91.7040404@bell-labs.com> Date: Thu, 23 May 2013 08:37:21 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130311 Thunderbird/17.0.4 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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [sip-overload] draft-ietf-soc-overload-control-13 released 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, 23 May 2013 13:33:51 -0000 Folks: I have revised the overload control draft following the second WGLC. The new version (-13) incorporates all of the comments I received, with resolution to the non-editorial comments reflected on the list between Feb-11-2013 to the release of -13 today. All of the comments --- save one --- were editorial in nature and served to clarify affected portions of the draft. The one non- editorial comment involved a rfc2119 change. Specifically, in S4.1, 4th paragraph, a SHOULD was upgraded to a MUST based on Eric Noel spotting a discrepancy with normative language in S5.5 if we were to leave a SHOULD in S4.1 [1]. I will like to thank Janet Gunn, Bruno Chatras, Eric Noel and Volker Hilt for helping with the new version. The diffs are at [2]. The draft is ready to be moved ahead, in my opinion. Thank you, [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00928.html [2] http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-overload-control-13 - 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/ | Calendar: http://goo.gl/x3Ogq From volker.hilt@bell-labs.com Fri May 24 02:59:54 2013 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 D829321F918C for ; Fri, 24 May 2013 02:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 sP-7a7aHYx-j for ; Fri, 24 May 2013 02:59:49 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 4858921F9133 for ; Fri, 24 May 2013 02:59:48 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id r4O9xhIO004808 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 24 May 2013 04:59:43 -0500 (CDT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r4O9xgVL013305 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 24 May 2013 05:59:42 -0400 Received: from [149.204.61.163] (135.5.27.17) by US70UWXCHHUB01.zam.alcatel-lucent.com (135.5.2.48) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 24 May 2013 05:59:42 -0400 Message-ID: <519F3A0B.7090507@bell-labs.com> Date: Fri, 24 May 2013 11:59:39 +0200 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 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.17] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT! 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, 24 May 2013 09:59:55 -0000 Folks, with draft-ietf-soc-overload-control-13 getting close to finalization, we are ready to start the WGLC for our last remaining draft: http://www.ietf.org/id/draft-ietf-soc-overload-rate-control-04.txt The WGLC will end on Fri Jun 7. Please review the draft and send your comments to the mailing list. It is very important that the WG reviews this draft. YOUR comments are important - even if it is just to say you agree! This is our last draft, let's make a final push to get this done. Thanks, Salvatore and Volker SOC WG co-chairs From charles.newyork@gmail.com Sat May 25 12:52:51 2013 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 C0CFB21F8AD1 for ; Sat, 25 May 2013 12:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[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 w8rBJDeuZS08 for ; Sat, 25 May 2013 12:52:47 -0700 (PDT) Received: from mail-oa0-f53.google.com (mail-oa0-f53.google.com [209.85.219.53]) by ietfa.amsl.com (Postfix) with ESMTP id 5E29921F8A54 for ; Sat, 25 May 2013 12:52:47 -0700 (PDT) Received: by mail-oa0-f53.google.com with SMTP id g12so7444996oah.26 for ; Sat, 25 May 2013 12:52:47 -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=rq9zvEiglOP3d52vScSgyVOEzCJH3DPly8NeK48FyKU=; b=lFSe6m+5i3JH54YfSKyXhwmPzJ1mwuxSguva38H8Ik+hXPHMSOuK1YT33PVrMX/qrt J3VO/eLqEuHcpAlIk9UT4LGWnVZfCjErpIUpRhbjxOecBG232QYPOSwORlenGgG5a0zq z6Iu1HCSWyaFSK6MuPXPiE2ArMoimyBIQAH4dsqUMSmTWndPt8f+6AzrUQF+x/haKibP 5XrokSAV1XXI9vZBmMFLk23/xkV2K/swZ35QZbuQegrpveRnpw7M+6qO0O1BAmEKm/R3 h6B6nV64XVyjBZQz7mVNnCF2JxaPfVt0eM1f4xJz5Xt1TFYGgT2xCZ3fP7pFUHVkFiai 7Mcw== X-Received: by 10.60.38.169 with SMTP id h9mr14675614oek.120.1369511566867; Sat, 25 May 2013 12:52:46 -0700 (PDT) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.66.227 with HTTP; Sat, 25 May 2013 12:52:25 -0700 (PDT) In-Reply-To: References: From: Charles Shen Date: Sat, 25 May 2013 15:52:25 -0400 X-Google-Sender-Auth: bYsGthsskcx81fUZpf0jmNbePks Message-ID: To: Richard Barnes Content-Type: multipart/alternative; boundary=089e0149530a75847204dd90426a Cc: sip-overload@ietf.org, draft-ietf-soc-load-control-event-package@tools.ietf.org Subject: Re: [sip-overload] AD review of draft-ietf-soc-load-control-event-package-08 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: Sat, 25 May 2013 19:52:51 -0000 --089e0149530a75847204dd90426a Content-Type: text/plain; charset=UTF-8 Dear Richard, Thank you so much for the great review. I am so sorry for the much delayed response. Please see my comments inline. On Wed, Apr 17, 2013 at 1:53 PM, Richard Barnes wrote: > I have reviewed this document, and have a few questions before IETF LC: > > Major: > > In a few places, for example Section 5.3., the document suggests that this > event package could be used to communicate load filtering policies between > domains. This seems like a bad idea for a few reasons. First, policies > can be based on "P-Asserted-Identity", which is itself limited to use > within a trust domain / Spec(T). It doesn't make sense to have policies > based on these identifiers outside of the domain in which they are used. > Second, inter-domain policies can create subtle and dangerous security > risks. For example, according to the current specification, Domain A could > tell Domain B to drop all calls between Domain B and Domain C. It's not > clear how you would prevent these sorts of attacks, especially where "tel:" > URIs are involved. I think both of these issues go away if this event > package is limited in a similar way to P-Asserted-Identity, i.e., limited > to use within a trust domain. > > [CS] How about phrasing it as being applicable "within trusted intra-domain and/or trusted inter-domain" scenarios? > Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anything about what > goes in the body of a SUBSCRIBE message. On the one hand, it implies that > there could be a body (since the last sentence considers a request without > a body as a special case), but it doesn't say what goes in the body if > there is one. Please either (1) define what may go in the body, (2) > explicitly say that this document does not specify what goes in SUBSCRIBE > bodies, or (3) require that the body be empty. > [CS] Earlier version of this document specifies that "A SUBSCRIBE request for the SIP load control event package MAY contain a body to filter the requested load control event notification. The details of the subscription filter specification are not yet defined." That sentence was later removed because it might cause confusion. ( http://www.ietf.org/mail-archive/web/sip-overload/current/msg00866.html) I am OK going for your option (2) or option (3), although slightly prefer option (2). > (Also, the first paragraph of this section seems out of place here, since > it also has nothing to do with the body.) > > [CS] removed, since the meaning of this paragraph has already been conveyed elsewhere in the document [Section 5.3]. > In Section 6.5., the last sentence is wrong. The presence of an Accept > header indicates that the response body should be one of the indicated > types. The indicated behavior would only be acceptable if the Accept > header included "multipart/mixed". Suggest deleting the last sentence. > (Also, it would be clearer to change "the request body will contain" to > "the request body MUST contain".) > > [CS] Done. > In Section 7.3.1, you need to specify how a "tel:" URI is matched against > a domain value starting with "+". Your examples seem to indicate simple > string prefix matching, but I doubt that's what you actually want, since > non-digit characters can break things. For example, "+1212" should match " > +1-212-555-1212". Please specify a matching algorithm here. > > [CS] So there are a number of possible scenarios that I can think of: a) Matching based on Tel URI comparison: According to RFC 3966 Section 4. Tel URIs like +8135252324, +81-33525-2324, +81 33525 2324 all become 8135252324 during comparison because separators are removed, and they are therefore equivalent. b) Matching based on SIP URI comparison: Defined in RFC3261 Section 19.1.4 c) Matching for Tel converted SIP URI. I am not sure if this is something we need to worry about. Since whitespace is not allowed in URI, Tel URIs like +8135252324, +81-33525-2324, +81 33525 2324 will yield +8135252324@host +81-33525-2324@host Which will be considered different (will it?). If it is not possible to identify which SIP URI is a Tel-converted SIP URI, then we need to specify both in the filter identity conditions, otherwise, we can decide to similarly remove the separators in the username, and make them the same URI. d) Prefix matching Is it sufficient to state that for prefix-based matching, regular expression and rules as determined by the provider of the applicable domains SHOULD be used? We've also dug around, and we have not found any algorithm in published RFC to match numbers such as +8135252324, +81-33525-2324, and +81 33525 2324. There's some note on DRINKS spec about applying regular expression to telephone number. But it just wrote that we could define regular expression for telephone number. It does not illustrate or specify any specific examples either. In Section 7.3.2, please change "Non-initial requests ... are not > subjected" to "Non-initial requests ... MUST NOT be subjected". > [CS] done > > Section 7.4. doesn't adequately define the actions to be taken. Each of > the action elements (, , ) need to define a concrete > action that the proxy should take. > > [CS] It seems to me that how to enforce the rate/window/percent becomes more implementation specific, and these action items are what the rest of the WG documents (http://datatracker.ietf.org/wg/soc/) are using as well. The first paragraph of Section 7.4 also referenced RFC6357 on more details about these actions. Therefore, I am not sure what more concrete actions you are referring to, could you please elaborate a bit on this? > RFC 4745 allows rules to combine when multiple rules match a given call. > This document needs to define combination rules for the actions defined > here. > [CS] For a particular filter policy condition, I don't seem to see how/why an upstream server would send a filter policy action combining different action types (rate/window/percent) or combining multiple values for the same action type. Should we simply make it explicit that no combination is allowed, or do you have any combination scenario in mind? > What's the reason for having both the "drop" action and the "reject" > action? It seems like the "drop" action is almost always harmful. With > unreliable transport, it causes retransmits, and even with reliable > transport, it causes the client to wait unnecessarily until the connection > times out. In any case, the "simple drop" action is underspecified. For > example, does the server simply ignore the SIP message, or does it close > the transport connection? > > [CS] "simple drop" here means simply ignoring the request without doing anything. i.e., in the reliable transport case, it does not have to close the transport connection. It still saves some processing needed in sending out the rejection in reliable transport. But I am open to eleminating it if the group prefers so. > > Minor: > > In Section 7.3, "we re-define" -- the document doesn't re-define any of > the elements in RFC 4745 (that's good; redefinition is bad). Instead, you > should say you define new identity elements. > > [CS] Done. In Section 7.3.1, please break up paragraph starting "To include the two > forms..." for greater readability. Suggested break points: Before "Note > that the tradeoff...", and before "It should be noted..." > [CS] Done. > > In Section 7.3.3, it would be helpful to break up the paragraph starting > "The following are two example...". Break before "Usecase I" and "Usecase > II". Also, s/Usecase/Use case/g > > [CS] Done. Thanks! Charles > > Thanks, > --Richard > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > > --089e0149530a75847204dd90426a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear Richard,=C2=A0

Thank you so much for the great revi= ew. I am so sorry for the much delayed response. Please see my comments inl= ine. =C2=A0

On Wed, Apr 17, 2013 a= t 1:53 PM, Richard Barnes <rlb@ipv.sx> wrote:
I have reviewed this document, and have a few questions before IETF LC:

Major:

In a few places, for example Section 5.3., the document sugge= sts that this event package could be used to communicate load filtering pol= icies between domains. =C2=A0This seems like a bad idea for a few reasons. = =C2=A0First, policies can be based on "P-Asserted-Identity", whic= h is itself limited to use within a trust domain / Spec(T). =C2=A0It doesn&= #39;t make sense to have policies based on these identifiers outside of the= domain in which they are used. =C2=A0Second, inter-domain policies can cre= ate subtle and dangerous security risks. =C2=A0For example, according to th= e current specification, Domain A could tell Domain B to drop all calls bet= ween Domain B and Domain C. =C2=A0It's not clear how you would prevent = these sorts of attacks, especially where "tel:" URIs are involved= . =C2=A0I think both of these issues go away if this event package is limit= ed in a similar way to P-Asserted-Identity, i.e., limited to use within a t= rust domain.


[CS] How ab= out phrasing it as being applicable "within trusted intra-domain and/o= r trusted inter-domain" scenarios?=C2=A0

=C2=A0
Section 6.3., "SUBSCRIBE Bodies" doesn't actually say anythin= g about what goes in the body of a SUBSCRIBE message. =C2=A0On the one hand= , it implies that there could be a body (since the last sentence considers = a request without a body as a special case), but it doesn't say what go= es in the body if there is one. =C2=A0Please either (1) define what may go = in the body, (2) explicitly say that this document does not specify what go= es in SUBSCRIBE bodies, or (3) require that the body be empty. =C2=A0

[CS] Earlier version of t= his document specifies that=C2=A0

"A SUBSCRIB= E request for the SIP load control event package MAY contain a body to filt= er the requested load control event notification. The details of the subscr= iption filter specification are not yet defined."

That sentence was later removed because it might cause = confusion. =C2=A0 (http://www.ietf.org/mail-archive/web/sip-overlo= ad/current/msg00866.html)

I am OK going for your option (2) or option (3), althou= gh slightly prefer option (2).=C2=A0
=C2=A0
(Also, the first paragraph of t= his section seems out of place here, since it also has nothing to do with t= he body.)


[CS] remove= d, since the meaning of this paragraph has already been conveyed elsewhere = in the document [Section 5.3].=C2=A0
=C2=A0
In Section 6.5., the last sentence is wrong. =C2=A0The presence of an Accep= t header indicates that the response body should be one of the indicated ty= pes. =C2=A0The indicated behavior would only be acceptable if the Accept he= ader included "multipart/mixed". =C2=A0Suggest deleting the last = sentence. =C2=A0(Also,=C2=A0=C2=A0it would be clearer to change "the r= equest body will contain" to "the request body MUST contain"= .)


[CS] Done.=C2=A0=
=C2=A0
In Section 7.3.1, you need to specify how a "tel:" URI is matched= against a domain value starting with "+". =C2=A0Your examples se= em to indicate simple string prefix matching, but I doubt that's what y= ou actually want, since non-digit characters can break things. =C2=A0For ex= ample, "+1212" should match "= +1-212-555-1212". =C2=A0Please specify a matching algorithm here.<= /div>


[CS]=C2=A0<= /div>

So there are a number of possible scenarios that I= can think of:

a) Matching based on Tel URI comparison:

=
According to RFC 3966 Section 4. Tel URIs like +8135252324, +81-= 33525-2324, +81 33525 2324 all become 8135252324 during comparison because = separators are removed, and they are therefore equivalent.=C2=A0

b) Matching based on SIP URI comparison:=C2=A0

Defined in RFC3261 Section 19.1.4

c) Matching for Tel converted SIP URI. I am not sure if this is something = we need to worry about.=C2=A0

Since whitespace is not allowed in URI, Tel URIs like += 8135252324, +81-33525-2324, +81 33525 2324 will yield=C2=A0

<= /div>
+8135252324@host
+81-33525-2324@host

Which will be considered different (will it?). If it is not possible t= o identify which SIP URI is a Tel-converted SIP URI, then we need to specif= y both in the filter identity conditions, otherwise, we can decide to simil= arly remove the separators in the username, and make them the same URI. =C2= =A0 =C2=A0=C2=A0

d) Prefix matching

Is it suffi= cient to state that for prefix-based matching, regular expression and rules= as determined by the provider of the applicable domains SHOULD be used?

We've also dug around, and we have not found any al= gorithm in published RFC to match numbers such as +8135252324, +81-33525-23= 24, and +81 33525 2324. There's some note on DRINKS spec about applying= regular expression to telephone number. But it just wrote that we could de= fine regular expression for telephone number. It does not illustrate or spe= cify any specific examples either.=C2=A0

<= div class=3D"h5">
In Section 7.3.2, please change "Non-initial requests ... are not subj= ected" to "Non-initial requests ... MUST NOT be subjected".<= /div>

[CS] done
=C2=A0

Section 7.4. doesn't adequately define the actions to be = taken. =C2=A0Each of the action elements (<rate>, <window>, <= ;percent>) need to define a concrete action that the proxy should take.= =C2=A0


[CS] It see= ms to me that how to enforce the rate/window/percent becomes more implement= ation specific, and these action items are what the rest of the WG document= s (http://datatracker.ietf.= org/wg/soc/) are using as well. The first paragraph of Section 7.4 also= referenced RFC6357 on more details about these actions. Therefore, I am no= t sure what more concrete actions you are referring to, could you please el= aborate a bit on this?=C2=A0
=C2=A0
RFC 4745 allows rules to combine when multiple rules match a given call. = =C2=A0This document needs to define combination rules for the actions defin= ed here. =C2=A0

[CS] For = a particular filter policy condition, I don't seem to see how/why an up= stream server would send a filter policy action combining different action = types (rate/window/percent) or combining multiple values for the same actio= n type. Should we simply make it explicit that no combination is allowed, o= r do you have any combination scenario in mind? =C2=A0=C2=A0


What's the reason for having both the "drop" ac= tion and the "reject" action? =C2=A0It seems like the "drop&= quot; action is almost always harmful. =C2=A0With unreliable transport, it = causes retransmits, and even with reliable transport, it causes the client = to wait unnecessarily until the connection times out. =C2=A0In any case, th= e "simple drop" action is underspecified. =C2=A0For example, does= the server simply ignore the SIP message, or does it close the transport c= onnection?


[CS] "= simple drop" here means simply ignoring the request without doing anyt= hing. =C2=A0i.e., in the reliable transport case, it does not have to close= the transport connection. It still saves some processing needed in sending= out the rejection in reliable transport. But I am open to eleminating it i= f the group prefers so.=C2=A0
=C2=A0

Minor:

In Section 7.3, "we re-define" -- the document does= n't re-define any of the elements in RFC 4745 (that's good; redefin= ition is bad). =C2=A0Instead, you should say you define new identity elemen= ts.


[CS] Done.<= /div>

In Section 7.3.1, please break up paragraph starting "To include the t= wo forms..." for greater readability. =C2=A0Suggested break points: Be= fore "Note that the tradeoff...", and before "It should be n= oted..."

[CS] Done.
=C2=A0

In Section 7.3.3, it would be helpful to break up the paragraph starting &q= uot;The following are two example...". =C2=A0Break before "Usecas= e I" and "Usecase II". =C2=A0Also, s/Usecase/Use case/g


[CS] Done.


Thanks!

= Charles

=C2=A0

Thanks,
--Richard

_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload


--089e0149530a75847204dd90426a--