From ecnoel@research.att.com Thu Apr 5 14:22: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 A767221F866B for ; Thu, 5 Apr 2012 14:22:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[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 ZqB2RdBSbIKV for ; Thu, 5 Apr 2012 14:22:57 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id D00A721F860E for ; Thu, 5 Apr 2012 14:22:56 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 813EB12044A; Thu, 5 Apr 2012 17:22:47 -0400 (EDT) Received: from njfpsrvexg1.research.att.com (njfpsrvexg1.research.att.com [135.207.177.20]) by mail-blue.research.att.com (Postfix) with ESMTP id 75A4AEF846; Thu, 5 Apr 2012 17:22:30 -0400 (EDT) Received: from concierge.research.att.com (135.207.179.20) by njfpsrvexg1.research.att.com (135.207.177.20) with Microsoft SMTP Server (TLS) id 8.3.245.1; Thu, 5 Apr 2012 17:20:13 -0400 Received: from njfpsrvexg6.research.att.com ([fe80:0000:0000:0000:a8f7:a94a:213.189.254.11]) by concierge.research.att.com ([135.207.24.83]) with mapi; Thu, 5 Apr 2012 17:22:45 -0400 From: "NOEL, ERIC C (ERIC C)" To: 'Volker Hilt' , "sip-overload@ietf.org" Date: Thu, 5 Apr 2012 17:24:11 -0400 Thread-Topic: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01 Thread-Index: Ac0MPmSS86udd2loRVCepKZkBCHFDwHLRsKA Message-ID: <2F8FB48C17221643AD77FA295756D2A73E64C15B08@njfpsrvexg6.research.att.com> References: <4F71F78E.80009@bell-labs.com> In-Reply-To: <4F71F78E.80009@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 Subject: Re: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01 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, 05 Apr 2012 21:22:57 -0000 Volker, Apologies for the delayed response. Phil is away and could not provide inp= ut to below, and I am about to go away as well. So I am giving you partial = responses which I will complete upon my return. Janet also provided some in= put in below. - Section 3.4.: But when deriving this rate the server may need to take into account the effect of the client prioritization on the load it receives, e.g. CPU utilization will depend upon the characteristics of the requests. How should the server take the client prioritization into account? Does the= server need to know the prioritization made by the client? [EN/JG] The server does not know the client(s) prioritization rules, but it= could account for it implicitly by relying on a resource measure such as = the average CPU load per request due to the particular request stream mix r= esulting from the client's admission control. Using this measure would all= ow the server to take into account the client prioritization. =20 - Section 3.5.: What is the adjusted-oc-value? Is this the value received in the oc paramet= er? How will it be adjusted? [EN/JG] The parameter "adjusted-oc-value" is a typo, should be "oc-value". = Will be changed in the next version. How should the values TAU1 and TAU2 be set with respect to the overall TAU?= Can you give guidance on how they should be chosen? What will they depend = on? [EN/JG] Putting together a small model to produce guidance on parameter sel= ection.=20 It would be very helpful to have a pseudo-code algorithm for rate based con= trols. This will make the description in this section easier to understand. [EN/JG] Will be added in next version. Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Volker Hilt Sent: Tuesday, March 27, 2012 1:23 PM To: sip-overload@ietf.org Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01 Eric, Phil, here are a few comments on draft-ietf-soc-overload-rate-control-01: - Section 3.4.: But when deriving this rate the server may need to take into account the effect of the client prioritization on the load it receives, e.g. CPU utilization will depend upon the characteristics of the requests. How should the server take the client prioritization into account? Does the= server need to know the prioritization made by the client? - Section 3.5.: What is the adjusted-oc-value? Is this the value received in the oc paramet= er? How will it be adjusted? How should the values TAU1 and TAU2 be set with respect to the overall TAU?= Can you give guidance on how they should be chosen? What will they depend = on? It would be very helpful to have a pseudo-code algorithm for rate based con= trols. This will make the description in this section easier to understand. Thanks, Volker _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From volker.hilt@bell-labs.com Fri Apr 6 13:23:31 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 0661211E809B for ; Fri, 6 Apr 2012 13:23:31 -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 o3tXCuk0uGov for ; Fri, 6 Apr 2012 13:23:30 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 0681311E8098 for ; Fri, 6 Apr 2012 13:23:29 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q36KNDcd002408 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 6 Apr 2012 22:23:13 +0200 Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (135.120.45.63) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 6 Apr 2012 22:23:13 +0200 Received: from [135.112.131.41] (135.5.27.11) by US70UWXCHHUB02.zam.alcatel-lucent.com (135.5.2.49) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 6 Apr 2012 16:23:10 -0400 Message-ID: <4F7F509B.3080608@bell-labs.com> Date: Fri, 6 Apr 2012 16:22: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: "NOEL, ERIC C (ERIC C)" References: <4F71F78E.80009@bell-labs.com> <2F8FB48C17221643AD77FA295756D2A73E64C15B08@njfpsrvexg6.research.att.com> In-Reply-To: <2F8FB48C17221643AD77FA295756D2A73E64C15B08@njfpsrvexg6.research.att.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.5.27.11] X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01 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 Apr 2012 20:23:31 -0000 Eric, thanks for your response. Looking forward to reading the next version. More inline. > > Apologies for the delayed response. Phil is away and could not provide input to below, and I am about to go away as well. So I am giving you partial responses which I will complete upon my return. Janet also provided some input in below. > > - Section 3.4.: > But when deriving this rate the server may need to > take into account the effect of the client prioritization on the > load it receives, e.g. CPU utilization will depend upon the > characteristics of the requests. > How should the server take the client prioritization into account? Does the server need to know the prioritization made by the client? > [EN/JG] The server does not know the client(s) prioritization rules, but it could account for it implicitly by relying on a resource measure such as the average CPU load per request due to the particular request stream mix resulting from the client's admission control. Using this measure would allow the server to take into account the client prioritization. Relying on local measurements and statistics in the servers seems reasonable. Would be good to clarify this in the draft. Thanks, Volker > > - Section 3.5.: > What is the adjusted-oc-value? Is this the value received in the oc parameter? How will it be adjusted? > [EN/JG] The parameter "adjusted-oc-value" is a typo, should be "oc-value". Will be changed in the next version. > > > How should the values TAU1 and TAU2 be set with respect to the overall TAU? Can you give guidance on how they should be chosen? What will they depend on? > [EN/JG] Putting together a small model to produce guidance on parameter selection. > > It would be very helpful to have a pseudo-code algorithm for rate based controls. This will make the description in this section easier to understand. > [EN/JG] Will be added in next version. > > Eric Noel > AT&T Labs, Inc. > Rethink Possible > > Network Design and Performance Analysis > 200 South Laurel Avenue, D5-3D19 > Middletown, NJ 07748 > P: 732.420.4174 > ecnoel@att.com > > > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt > Sent: Tuesday, March 27, 2012 1:23 PM > To: sip-overload@ietf.org > Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01 > > Eric, Phil, > > here are a few comments on draft-ietf-soc-overload-rate-control-01: > > - Section 3.4.: > > But when deriving this rate the server may need to > take into account the effect of the client prioritization on the > load it receives, e.g. CPU utilization will depend upon the > characteristics of the requests. > > How should the server take the client prioritization into account? Does the server need to know the prioritization made by the client? > > - Section 3.5.: > > What is the adjusted-oc-value? Is this the value received in the oc parameter? How will it be adjusted? > > How should the values TAU1 and TAU2 be set with respect to the overall TAU? Can you give guidance on how they should be chosen? What will they depend on? > > It would be very helpful to have a pseudo-code algorithm for rate based controls. This will make the description in this section easier to understand. > > Thanks, > > Volker > > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From salvatore.loreto@ericsson.com Sat Apr 21 12:02:41 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 B628C21F863E for ; Sat, 21 Apr 2012 12:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=-0.242, 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 JrCk6Ux58onC for ; Sat, 21 Apr 2012 12:02:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 499C921F863D for ; Sat, 21 Apr 2012 12:02:37 -0700 (PDT) X-AuditID: c1b4fb25-b7b18ae000000dce-b0-4f93044bbfc3 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 90.FD.03534.B44039F4; Sat, 21 Apr 2012 21:02:36 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.213.0; Sat, 21 Apr 2012 21:02:35 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 8C9ED2326; Sat, 21 Apr 2012 22:02:35 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 923AF520BB; Sat, 21 Apr 2012 22:02:35 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 30969503BA; Sat, 21 Apr 2012 22:02:35 +0300 (EEST) Message-ID: <4F93044A.5020207@ericsson.com> Date: Sat, 21 Apr 2012 22:02:34 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; 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-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Volker Hilt Subject: [sip-overload] 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: Sat, 21 Apr 2012 19:02:41 -0000 Hi there, I have just uploaded the draft of the minutes for the SoC session at IETF83 in Paris. Here the link: http://www.ietf.org/proceedings/83/minutes/minutes-83-soc.txt please review it and eventually send your comments. best regards Salvatore -- Salvatore Loreto, PhD www.sloreto.com From pravindran@sonusnet.com Sat Apr 21 19:32:48 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 B994F21F847A for ; Sat, 21 Apr 2012 19:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.509 X-Spam-Level: X-Spam-Status: No, score=-6.509 tagged_above=-999 required=5 tests=[AWL=0.090, 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 9TCO2QxAgsAY for ; Sat, 21 Apr 2012 19:32:48 -0700 (PDT) Received: from na3sys010aog103.obsmtp.com (na3sys010aog103.obsmtp.com [74.125.245.74]) by ietfa.amsl.com (Postfix) with ESMTP id B35F621F8478 for ; Sat, 21 Apr 2012 19:32:47 -0700 (PDT) Received: from usma-ex-hub1.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob103.postini.com ([74.125.244.12]) with SMTP ID DSNKT5Ntz1G0hR26W0AQYkx2QOZeQTbx5fBu@postini.com; Sat, 21 Apr 2012 19:32:47 PDT Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by usma-ex-hub1.sonusnet.com (66.203.90.16) with Microsoft SMTP Server (TLS) id 14.2.247.3; Sat, 21 Apr 2012 22:32:45 -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, 22 Apr 2012 06:51:47 +0530 From: "Ravindran, Parthasarathi" To: Salvatore Loreto , "sip-overload@ietf.org" Thread-Topic: [sip-overload] draft minutes IETF83 Thread-Index: AQHNH/FX2r8tIMu4aU2GEinS/npxC5amC+XA Date: Sun, 22 Apr 2012 01:21:46 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> References: <4F93044A.5020207@ericsson.com> In-Reply-To: <4F93044A.5020207@ericsson.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: Volker Hilt Subject: Re: [sip-overload] 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, 22 Apr 2012 02:32:48 -0000 Salvatore, I have provided the comment on ietf-soc-overload-control-08 that subscribe/= notify mechanism mentioned in the draft has to updated with proper detail m= echanism or the section to be removed and Vijay agrees to update the draft = with the proper text in the next revision. Please update in the minutes. Thanks Partha >-----Original Message----- >From: sip-overload-bounces@ietf.org [mailto:sip-overload- >bounces@ietf.org] On Behalf Of Salvatore Loreto >Sent: Sunday, April 22, 2012 12:33 AM >To: sip-overload@ietf.org >Cc: Volker Hilt >Subject: [sip-overload] draft minutes IETF83 > >Hi there, > >I have just uploaded the draft of the minutes for the SoC session at >IETF83 in Paris. > >Here the link: >http://www.ietf.org/proceedings/83/minutes/minutes-83-soc.txt > > >please review it and eventually send your comments. > >best regards >Salvatore > >-- >Salvatore Loreto, PhD >www.sloreto.com > >_______________________________________________ >sip-overload mailing list >sip-overload@ietf.org >https://www.ietf.org/mailman/listinfo/sip-overload From salvatore.loreto@ericsson.com Sun Apr 22 09:29:00 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 2927521F85F7 for ; Sun, 22 Apr 2012 09:29:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.48 X-Spam-Level: X-Spam-Status: No, score=-106.48 tagged_above=-999 required=5 tests=[AWL=-0.231, 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 xblfDEIQLXLS for ; Sun, 22 Apr 2012 09:28:59 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61421F85E7 for ; Sun, 22 Apr 2012 09:28:55 -0700 (PDT) X-AuditID: c1b4fb2d-b7b76ae0000063d8-d8-4f9431c50bef Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA) Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CA.12.25560.5C1349F4; Sun, 22 Apr 2012 18:28:54 +0200 (CEST) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.213.0; Sun, 22 Apr 2012 18:28:53 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 305B12326; Sun, 22 Apr 2012 19:28:53 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2239F5233D; Sun, 22 Apr 2012 19:28:53 +0300 (EEST) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id B061351CA2; Sun, 22 Apr 2012 19:28:52 +0300 (EEST) Message-ID: <4F9431C3.8070708@ericsson.com> Date: Sun, 22 Apr 2012 19:28:51 +0300 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Cc: Volker Hilt , "sip-overload@ietf.org" Subject: Re: [sip-overload] 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, 22 Apr 2012 16:29:00 -0000 Hi Partha, I have updated the minutes to include your comments thanks a lot for reviewing the minutes cheers Salvatore On 4/22/12 4:21 AM, Ravindran, Parthasarathi wrote: > Salvatore, > > I have provided the comment on ietf-soc-overload-control-08 that subscribe/notify mechanism mentioned in the draft has to updated with proper detail mechanism or the section to be removed and Vijay agrees to update the draft with the proper text in the next revision. Please update in the minutes. > > Thanks > Partha > >> -----Original Message----- >> From: sip-overload-bounces@ietf.org [mailto:sip-overload- >> bounces@ietf.org] On Behalf Of Salvatore Loreto >> Sent: Sunday, April 22, 2012 12:33 AM >> To: sip-overload@ietf.org >> Cc: Volker Hilt >> Subject: [sip-overload] draft minutes IETF83 >> >> Hi there, >> >> I have just uploaded the draft of the minutes for the SoC session at >> IETF83 in Paris. >> >> Here the link: >> http://www.ietf.org/proceedings/83/minutes/minutes-83-soc.txt >> >> >> please review it and eventually send your comments. >> >> best regards >> Salvatore >> >> -- >> Salvatore Loreto, PhD >> www.sloreto.com >> >> _______________________________________________ >> sip-overload mailing list >> sip-overload@ietf.org >> https://www.ietf.org/mailman/listinfo/sip-overload -- Salvatore Loreto, PhD www.sloreto.com From vkg@bell-labs.com Mon Apr 23 08:00: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 3646321F84F1 for ; Mon, 23 Apr 2012 08:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.326 X-Spam-Level: X-Spam-Status: No, score=-109.326 tagged_above=-999 required=5 tests=[AWL=1.273, 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 S8rj2qu+TV+B for ; Mon, 23 Apr 2012 08:00:45 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 76F8921F8476 for ; Mon, 23 Apr 2012 08:00:44 -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 q3NF0g8T013226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 23 Apr 2012 10:00:42 -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 q3NF0e91029536 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Apr 2012 10:00:42 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3NF0eE8027633; Mon, 23 Apr 2012 10:00:40 -0500 (CDT) Message-ID: <4F956FC8.2030503@bell-labs.com> Date: Mon, 23 Apr 2012 10:05:44 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: "Ravindran, Parthasarathi" References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] 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: Mon, 23 Apr 2012 15:00:53 -0000 On 04/21/2012 08:21 PM, Ravindran, Parthasarathi wrote: > Salvatore, > > I have provided the comment on ietf-soc-overload-control-08 that > subscribe/notify mechanism mentioned in the draft has to updated with > proper detail mechanism or the section to be removed and Vijay agrees > to update the draft with the proper text in the next revision. Please > update in the minutes. Partha: I promised to get back to the list with proposed modifications to S9.1.2 based on your feedback at the mic during the meeting. So, here goes. I believe you are pointing out an incongruity in the text in S9, which discusses two alternatives to providing overload control --- one is by sending the feedback in the Via header (the chosen means) and the second is through a subs/not event package. The incongruity occurs because the phrasing of the text in the subs/not alternative appears to imply that subs/not is supported mechanism as well, which clearly it is not. To remedy this, I propose that we simply remove Section 9 in its entirety. The justification for choosing the Via header is already provided in Section 3, as such Section 9 does not contribute much. The subs/not package is used in a different scenario (as described by Shen et al. [1]). Having the discussion on subs/not in the overload-control document may simply be distracting. Let me know if that is okay with you and I will remove Section 9 in the next revision. [1] http://datatracker.ietf.org/doc/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 bruno.chatras@orange.com Mon Apr 23 08:16:26 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 0261321F8672 for ; Mon, 23 Apr 2012 08:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 xIUJSO65I49K for ; Mon, 23 Apr 2012 08:16:25 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by ietfa.amsl.com (Postfix) with ESMTP id C60A521F8494 for ; Mon, 23 Apr 2012 08:16:24 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 20FD45D8A42; Mon, 23 Apr 2012 17:16:23 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 111325D89CC; Mon, 23 Apr 2012 17:16:23 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Apr 2012 17:16:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 23 Apr 2012 17:16:21 +0200 Message-ID: <9ECCF01B52E7AB408A7EB8535264214104059E8E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4F956FC8.2030503@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sip-overload] draft minutes IETF83 Thread-Index: Ac0hYgNFlJCJ4EahRKGrQe6dHk24/AAASRiQ References: <4F93044A.5020207@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> From: To: , X-OriginalArrivalTime: 23 Apr 2012 15:16:23.0089 (UTC) FILETIME=[0B22D210:01CD2164] Cc: sip-overload@ietf.org Subject: Re: [sip-overload] 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: Mon, 23 Apr 2012 15:16:26 -0000 I support removing Section 9. I think I made this comment on the list in = 2010 actually. BC > -----Message d'origine----- > De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] De la part de Vijay K. Gurbani > Envoy=E9=A0: lundi 23 avril 2012 17:06 > =C0=A0: Ravindran, Parthasarathi > Cc=A0: sip-overload@ietf.org > Objet=A0: Re: [sip-overload] draft minutes IETF83 >=20 > On 04/21/2012 08:21 PM, Ravindran, Parthasarathi wrote: > > Salvatore, > > > > I have provided the comment on ietf-soc-overload-control-08 that > > subscribe/notify mechanism mentioned in the draft has to updated = with > > proper detail mechanism or the section to be removed and Vijay = agrees > > to update the draft with the proper text in the next revision. = Please > > update in the minutes. >=20 > Partha: I promised to get back to the list with proposed modifications > to S9.1.2 based on your feedback at the mic during the meeting. So, > here goes. >=20 > I believe you are pointing out an incongruity in the text in S9, which > discusses two alternatives to providing overload control --- one is by > sending the feedback in the Via header (the chosen means) and the > second > is through a subs/not event package. The incongruity occurs because > the > phrasing of the text in the subs/not alternative appears to imply that > subs/not is supported mechanism as well, which clearly it is not. >=20 > To remedy this, I propose that we simply remove Section 9 in its > entirety. The justification for choosing the Via header is already > provided in Section 3, as such Section 9 does not contribute much. > The subs/not package is used in a different scenario (as described > by Shen et al. [1]). Having the discussion on subs/not in the > overload-control document may simply be distracting. >=20 > Let me know if that is okay with you and I will remove Section 9 in > the next revision. >=20 > [1] > http://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event- > package/ >=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/ > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From volker.hilt@bell-labs.com Mon Apr 23 08:22: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 457A321F8741 for ; Mon, 23 Apr 2012 08:22:46 -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 f979GvVjNDnB for ; Mon, 23 Apr 2012 08:22:45 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id DEF1F21F8744 for ; Mon, 23 Apr 2012 08:22:44 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3NFMh8E030395 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Mon, 23 Apr 2012 17:22:43 +0200 Received: from [149.204.61.31] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 23 Apr 2012 17:22:29 +0200 Message-ID: <4F95732A.1000506@bell-labs.com> Date: Mon, 23 Apr 2012 17:20:10 +0200 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: References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> In-Reply-To: <4F956FC8.2030503@bell-labs.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 Subject: Re: [sip-overload] 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: Mon, 23 Apr 2012 15:22:46 -0000 Vijay, Partha, I think section 9 provides useful background on the discussions that lead to the current solution. For this reason, it would be good to keep this section in the draft. Section 9 does not refer to a specific event packet. Rather, explains general design considerations. I'd suggest the following change to Section 9.1 to point this out more clearly. 9.1. SIP Mechanism A SIP mechanism is needed to convey overload feedback from the receiving to the sending SIP entity. Developing his feedback mechanisms involves a number of fundamental design choices that are discussed in this section. Thanks, Volker On 23.04.2012 17:05, Vijay K. Gurbani wrote: > On 04/21/2012 08:21 PM, Ravindran, Parthasarathi wrote: >> Salvatore, >> >> I have provided the comment on ietf-soc-overload-control-08 that >> subscribe/notify mechanism mentioned in the draft has to updated with >> proper detail mechanism or the section to be removed and Vijay agrees >> to update the draft with the proper text in the next revision. Please >> update in the minutes. > > Partha: I promised to get back to the list with proposed modifications > to S9.1.2 based on your feedback at the mic during the meeting. So, > here goes. > > I believe you are pointing out an incongruity in the text in S9, which > discusses two alternatives to providing overload control --- one is by > sending the feedback in the Via header (the chosen means) and the second > is through a subs/not event package. The incongruity occurs because the > phrasing of the text in the subs/not alternative appears to imply that > subs/not is supported mechanism as well, which clearly it is not. > > To remedy this, I propose that we simply remove Section 9 in its > entirety. The justification for choosing the Via header is already > provided in Section 3, as such Section 9 does not contribute much. > The subs/not package is used in a different scenario (as described > by Shen et al. [1]). Having the discussion on subs/not in the > overload-control document may simply be distracting. > > Let me know if that is okay with you and I will remove Section 9 in > the next revision. > > [1] > http://datatracker.ietf.org/doc/draft-ietf-soc-load-control-event-package/ > > Thanks, > > - vijay From vkg@bell-labs.com Mon Apr 23 08:44: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 D87E521F873A for ; Mon, 23 Apr 2012 08:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.432 X-Spam-Level: X-Spam-Status: No, score=-109.432 tagged_above=-999 required=5 tests=[AWL=1.167, 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 3wD-9l2EXXIE for ; Mon, 23 Apr 2012 08:44:30 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DE13721F8739 for ; Mon, 23 Apr 2012 08:44:29 -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 q3NFiTYH029387 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Apr 2012 10:44:29 -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 q3NFiSLr026029 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Apr 2012 10:44:29 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3NFiRIP006231; Mon, 23 Apr 2012 10:44:28 -0500 (CDT) Message-ID: <4F957A0C.4050606@bell-labs.com> Date: Mon, 23 Apr 2012 10:49:32 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Volker Hilt References: <4F93044A.5020207@ericsson.com> <387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <4F95732A.1000506@bell-labs.com> In-Reply-To: <4F95732A.1000506@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.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] 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: Mon, 23 Apr 2012 15:44:31 -0000 On 04/23/2012 10:20 AM, Volker Hilt wrote: > Vijay, Partha, > > I think section 9 provides useful background on the discussions that > lead to the current solution. For this reason, it would be good to keep > this section in the draft. > > Section 9 does not refer to a specific event packet. Rather, explains > general design considerations. Volker: Indeed, I thought of that as well. But then, I wonder why we did not put this in rfc6357? Regardless, if it is desirable to maintain this section, then I'd be a bit more pro-active in the wording to make sure there is no ambiguity. Something along these lines is what I would suggest if we want to maintain S9: OLD: 9.1. SIP Mechanism A SIP mechanism is needed to convey overload feedback from the receiving to the sending SIP entity. A number of different alternatives exist to implement such a mechanism. NEW: 9.1. SIP Mechanism A SIP mechanism is needed to convey overload feedback from the receiving to the sending SIP entity. Different alternatives exist to implement such a mechanism, and the fundamental design choices related to each are discussed below. This document uses the SIP response headers (Section 9.1.1) to achieve overload control; the design choices related to SIP event package (Section 9.1.2) are provided for the sake of completeness. 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 volker.hilt@bell-labs.com Mon Apr 23 08:52:16 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 9303721F8744 for ; Mon, 23 Apr 2012 08:52:16 -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 WbzpuZ3-nEvN for ; Mon, 23 Apr 2012 08:52:15 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 17C6521F872E for ; Mon, 23 Apr 2012 08:52:14 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id q3NFqCSL005632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 23 Apr 2012 17:52:13 +0200 Received: from [149.204.61.31] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 23 Apr 2012 17:52:07 +0200 Message-ID: <4F957A50.7040402@bell-labs.com> Date: Mon, 23 Apr 2012 17:50:40 +0200 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: "Vijay K. Gurbani" 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> In-Reply-To: <4F957A0C.4050606@bell-labs.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] 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: Mon, 23 Apr 2012 15:52:17 -0000 Vijay, >> >> I think section 9 provides useful background on the discussions that >> lead to the current solution. For this reason, it would be good to keep >> this section in the draft. >> >> Section 9 does not refer to a specific event packet. Rather, explains >> general design considerations. > > Volker: Indeed, I thought of that as well. But then, I wonder why we > did not put this in rfc6357? > This discussion is specific to the mechanism proposed in this draft and it was felt that it is better to keep it there. > Regardless, if it is desirable to maintain this section, then I'd be a > bit more pro-active in the wording to make sure there is no ambiguity. > Something along these lines is what I would suggest if we want to > maintain S9: > > OLD: > 9.1. SIP Mechanism > > A SIP mechanism is needed to convey overload feedback from the > receiving to the sending SIP entity. A number of different > alternatives exist to implement such a mechanism. > > NEW: > 9.1. SIP Mechanism > > A SIP mechanism is needed to convey overload feedback from the > receiving to the sending SIP entity. Different alternatives exist > to implement such a mechanism, and the fundamental design choices > related to each are discussed below. This document uses the SIP > response headers (Section 9.1.1) to achieve overload control; > the design choices related to SIP event package (Section 9.1.2) are > provided for the sake of completeness. > Works fine for me. Thanks, Volker [as individual] From vkg@bell-labs.com Mon Apr 23 09:28: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 3DDDC21F8772 for ; Mon, 23 Apr 2012 09:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.522 X-Spam-Level: X-Spam-Status: No, score=-109.522 tagged_above=-999 required=5 tests=[AWL=1.077, 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 tvFNxzgrFHrI for ; Mon, 23 Apr 2012 09:28:29 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 71E7121F872E for ; Mon, 23 Apr 2012 09:28:29 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q3NGSSEl014382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 23 Apr 2012 11:28:28 -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 q3NGSSBw014758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 Apr 2012 11:28:28 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3NGSRf3025587; Mon, 23 Apr 2012 11:28:27 -0500 (CDT) Message-ID: <4F95845B.2040508@bell-labs.com> Date: Mon, 23 Apr 2012 11:33:31 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 MIME-Version: 1.0 To: Volker Hilt 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> In-Reply-To: <4F957A50.7040402@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.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] 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: Mon, 23 Apr 2012 16:28:30 -0000 On 04/23/2012 10:50 AM, Volker Hilt wrote: > This discussion is specific to the mechanism proposed in this draft and > it was felt that it is better to keep it there. Hmmm ... OK. >> OLD: >> 9.1. SIP Mechanism >> >> A SIP mechanism is needed to convey overload feedback from the >> receiving to the sending SIP entity. A number of different >> alternatives exist to implement such a mechanism. >> >> NEW: >> 9.1. SIP Mechanism >> >> A SIP mechanism is needed to convey overload feedback from the >> receiving to the sending SIP entity. Different alternatives exist >> to implement such a mechanism, and the fundamental design choices >> related to each are discussed below. This document uses the SIP >> response headers (Section 9.1.1) to achieve overload control; >> the design choices related to SIP event package (Section 9.1.2) are >> provided for the sake of completeness. >> > Works fine for me. Unless someone objects to this, I will update the draft as outlined above. 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 Mon Apr 23 18:04:26 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 2209E21F8711 for ; Mon, 23 Apr 2012 18:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 kLRktUgGEObV for ; Mon, 23 Apr 2012 18:04:25 -0700 (PDT) Received: from na3sys010aog105.obsmtp.com (na3sys010aog105.obsmtp.com [74.125.245.78]) by ietfa.amsl.com (Postfix) with ESMTP id 18D8421F86E3 for ; Mon, 23 Apr 2012 18:04:24 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob105.postini.com ([74.125.244.12]) with SMTP ID DSNKT5X8GIbFg7drkjEMYEpy3FNh3uZz4Dtx@postini.com; Mon, 23 Apr 2012 18:04:25 PDT Received: from INBA-HUB01.sonusnet.com (10.70.51.86) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 23 Apr 2012 21:04:24 -0400 Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub01.sonusnet.com ([fe80::5cbc:2823:f6cc:9ce7%11]) with mapi id 14.01.0355.002; Tue, 24 Apr 2012 06:34:18 +0530 From: "Ravindran, Parthasarathi" To: "bruno.chatras@orange.com" , "vkg@bell-labs.com" Thread-Topic: [sip-overload] draft minutes IETF83 Thread-Index: AQHNH/FX2r8tIMu4aU2GEinS/npxC5amC+XAgAIdIQCAAAL3gIAA/+/w Date: Tue, 24 Apr 2012 01:04:18 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E237E0F@inba-mail01.sonusnet.com> References: <4F93044A.5020207@ericsson.com><387F9047F55E8C42850AD6B3A7A03C6C0E228BF8@inba-mail01.sonusnet.com> <4F956FC8.2030503@bell-labs.com> <9ECCF01B52E7AB408A7EB8535264214104059E8E@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214104059E8E@ftrdmel0.rd.francetelecom.fr> 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sip-overload@ietf.org" Subject: Re: [sip-overload] 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: Tue, 24 Apr 2012 01:04:26 -0000 Vijay, It will be good idea to remove Sec 9 from this draft in the next revision. = I agree with your proposal. Thanks Partha >-----Original Message----- >From: bruno.chatras@orange.com [mailto:bruno.chatras@orange.com] >Sent: Monday, April 23, 2012 8:46 PM >To: vkg@bell-labs.com; Ravindran, Parthasarathi >Cc: sip-overload@ietf.org >Subject: RE: [sip-overload] draft minutes IETF83 > >I support removing Section 9. I think I made this comment on the list in >2010 actually. >BC > >> -----Message d'origine----- >> De=A0: sip-overload-bounces@ietf.org [mailto:sip-overload- >> bounces@ietf.org] De la part de Vijay K. Gurbani Envoy=E9=A0: lundi 23 >> avril 2012 17:06 =C0=A0: Ravindran, Parthasarathi Cc=A0: >> sip-overload@ietf.org Objet=A0: Re: [sip-overload] draft minutes IETF83 >> >> On 04/21/2012 08:21 PM, Ravindran, Parthasarathi wrote: >> > Salvatore, >> > >> > I have provided the comment on ietf-soc-overload-control-08 that >> > subscribe/notify mechanism mentioned in the draft has to updated >> > with proper detail mechanism or the section to be removed and Vijay >> > agrees to update the draft with the proper text in the next >> > revision. Please update in the minutes. >> >> Partha: I promised to get back to the list with proposed modifications >> to S9.1.2 based on your feedback at the mic during the meeting. So, >> here goes. >> >> I believe you are pointing out an incongruity in the text in S9, which >> discusses two alternatives to providing overload control --- one is by >> sending the feedback in the Via header (the chosen means) and the >> second is through a subs/not event package. The incongruity occurs >> because the phrasing of the text in the subs/not alternative appears >> to imply that subs/not is supported mechanism as well, which clearly >> it is not. >> >> To remedy this, I propose that we simply remove Section 9 in its >> entirety. The justification for choosing the Via header is already >> provided in Section 3, as such Section 9 does not contribute much. >> The subs/not package is used in a different scenario (as described by >> Shen et al. [1]). Having the discussion on subs/not in the >> overload-control document may simply be distracting. >> >> Let me know if that is okay with you and I will remove Section 9 in >> the next revision. >> >> [1] >> http://datatracker.ietf.org/doc/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 pravindran@sonusnet.com Mon Apr 23 18:24: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 1B85511E8075 for ; Mon, 23 Apr 2012 18:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.524 X-Spam-Level: X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 gl5mgSLevX5C for ; Mon, 23 Apr 2012 18:24:21 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) by ietfa.amsl.com (Postfix) with ESMTP id 02B3111E8072 for ; Mon, 23 Apr 2012 18:24:20 -0700 (PDT) Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKT5YAxLFHqKNkJZW4EZFqiQrG/MyQeh9w@postini.com; Mon, 23 Apr 2012 18:24:21 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; Mon, 23 Apr 2012 21:24:20 -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; Tue, 24 Apr 2012 06:54:09 +0530 From: "Ravindran, Parthasarathi" To: "Vijay K. Gurbani" , Volker Hilt Thread-Topic: [sip-overload] draft minutes IETF83 Thread-Index: AQHNH/FX2r8tIMu4aU2GEinS/npxC5amC+XAgAIdIQCAAAQIAIAACDUAgAAAUQCAAAv5gIAA7okQ Date: Tue, 24 Apr 2012 01:24:07 +0000 Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@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> In-Reply-To: <4F95845B.2040508@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" Subject: Re: [sip-overload] 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: Tue, 24 Apr 2012 01:24:22 -0000 Vijay/Volker, I'm reading this mail after replied to your initial proposal as this mail i= s not in my "To me" folder :-) I have difference of opinion about the content of sub/not in Sec 9 as it is= not fully analyzed after deep-dive into "OC" parameters in "via" header ba= sed mechanism. My opinion comes from the Session Initiation Protocol (SIP) = Resource availability Event package draft (http://tools.ietf.org/html/draft= -partha-soc-overload-resource-availability-00). I personally feel that it = is not worthy to discuss about SUB/NOT mechanism's merits/demerits within t= his draft at this moment. In case you wish to discuss, I'll continue the me= rit/demerit as part of this mail thread. Thanks Partha >-----Original Message----- >From: sip-overload-bounces@ietf.org [mailto:sip-overload- >bounces@ietf.org] On Behalf Of Vijay K. Gurbani >Sent: Monday, April 23, 2012 10:04 PM >To: Volker Hilt >Cc: sip-overload@ietf.org >Subject: Re: [sip-overload] draft minutes IETF83 > >On 04/23/2012 10:50 AM, Volker Hilt wrote: >> This discussion is specific to the mechanism proposed in this draft >> and it was felt that it is better to keep it there. > >Hmmm ... OK. > >>> OLD: >>> 9.1. SIP Mechanism >>> >>> A SIP mechanism is needed to convey overload feedback from the >>> receiving to the sending SIP entity. A number of different >>> alternatives exist to implement such a mechanism. >>> >>> NEW: >>> 9.1. SIP Mechanism >>> >>> A SIP mechanism is needed to convey overload feedback from the >>> receiving to the sending SIP entity. Different alternatives exist to >>> implement such a mechanism, and the fundamental design choices >>> related to each are discussed below. This document uses the SIP >>> response headers (Section 9.1.1) to achieve overload control; the >>> design choices related to SIP event package (Section 9.1.2) are >>> provided for the sake of completeness. >>> >> Works fine for me. > >Unless someone objects to this, I will update the draft as outlined >above. > >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 vkg@bell-labs.com Tue Apr 24 14:15:24 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 E7A1511E80BB for ; Tue, 24 Apr 2012 14:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.599 X-Spam-Level: X-Spam-Status: No, score=-109.599 tagged_above=-999 required=5 tests=[AWL=1.000, 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 k-0SKkAEZdEO for ; Tue, 24 Apr 2012 14:15:24 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 38BC511E80B6 for ; Tue, 24 Apr 2012 14:15:24 -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 q3OLFNKU026269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Apr 2012 16:15:23 -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 q3OLFM5L029200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 24 Apr 2012 16:15:23 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id q3OLFMAC010488; Tue, 24 Apr 2012 16:15:22 -0500 (CDT) Message-ID: <4F97191A.5020501@bell-labs.com> Date: Tue, 24 Apr 2012 16:20:26 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:11.0) Gecko/20120329 Thunderbird/11.0.1 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> In-Reply-To: <387F9047F55E8C42850AD6B3A7A03C6C0E237E4A@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] 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: Tue, 24 Apr 2012 21:15:25 -0000 On 04/23/2012 08:24 PM, Ravindran, Parthasarathi wrote: > Vijay/Volker, > > I'm reading this mail after replied to your initial proposal as this > mail is not in my "To me" folder :-) > > I have difference of opinion about the content of sub/not in Sec 9 as > it is not fully analyzed after deep-dive into "OC" parameters in > "via" header based mechanism. My opinion comes from the Session > Initiation Protocol (SIP) Resource availability Event package draft > (http://tools.ietf.org/html/draft-partha-soc-overload-resource-availability-00). > I personally feel that it is not worthy to discuss about SUB/NOT > mechanism's merits/demerits within this draft at this moment. In case > you wish to discuss, I'll continue the merit/demerit as part of this > mail thread. Initially, I was of the opinion that removing S9 may be the expedient way forward, as my earlier email [1] indicated. However, Volker has made a case that we should maintain S9 as background information to demonstrate the discussions that lead to the choice of the current solution. Having been through a rather brutal IESG review of sipclf where similar justification was asked for, I am sympathetic to providing background information precisely for the purpose of completeness. I gather that you would rather see S9 excised completely. We have to converge at a middle point somewhere. If you are not comfortable with the suggested text of [2], then can I kindly ask you to read S9.1.2 and send me some suggested text that gets your point across? I will be more than happy to put that into the draft and move forward. Please send me the text at your earliest convenience (or post on the list) and we can iterate through it to include it in the next revision. [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00773.html [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00778.html 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/