From nobody Tue Jan 3 04:07:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EB4129512 for ; Tue, 3 Jan 2017 04:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrKCUW8NZ3M9 for ; Tue, 3 Jan 2017 04:07:35 -0800 (PST) Received: from mail1.bemta3.messagelabs.com (mail1.bemta3.messagelabs.com [195.245.230.163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF3C129575 for ; Tue, 3 Jan 2017 04:07:34 -0800 (PST) Received: from [85.158.138.179] by server-3.bemta-3.messagelabs.com id 5F/C8-14551-5049B685; Tue, 03 Jan 2017 12:07:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHKsWRWlGSWpSXmKPExsWi75nTpcsyJTv C4OgxC4s9fxexW1xat5XJ4uuPTWwOzB47Z91l91iy5CeTx6ydT1gCmKNYM/OS8isSWDOmTN/B UtAmV3F/ySfGBsYrsl2MXBxCAtsYJbbsmcgC4RxilFgy9TxrFyMnkHOYUaLvcRREYhOjROPrf sYuRg4ONgF7iRl7YkBqRAS8JBqXv2cBsZkF5CSuf9jIBmILCwRJPD45gwmiJlji+MRX7BC2kc SlhSuYQWwWARWJk3efgNXzCoRKXJxxmBliVwujxKP+LWDNnAKBEuvuHQZbwCggK/GlcTUzxDJ xiVtP5oPVSAgISCzZc54ZwhaVePn4HyvIncwCmhLrd+lDlCtKTOl+yA6xS1Di5MwnLBA/qkr8 W7mIaQKj2CwkU2chdM9C0j0LSfcCRpZVjBrFqUVlqUW6hgZ6SUWZ6RkluYmZOUCesV5uanFxY npqTmJSsV5yfu4mRmC81TMwMO5g3NblfIhRkoNJSZQ3miE7QogvKT+lMiOxOCO+qDQntfgQow wHh5IEb/1koJxgUWp6akVaZg4w8mHSEhw8SiK8xyYBpXmLCxJzizPTIVKnGBWlxHkFQPoEQBI ZpXlwbbBkc4lRVkqYl5GBgUGIpyC1KDezBFX+FaM4B6OSMK84yBSezLwSuOmvgBYzAS3eHgC2 uCQRISXVwLhWm49DPrLjn9nrI/GTuXp+KQesiPn0/bXBFOXkMMFParKPAivbPykz8ZVo/3Z7J rCvOCt/5rKTGuzLVBYfiGJWCNzVJrRLd9uyJt5jyWKmvVFf1my7N3f11DyPlFWMAX8D928RWB qZKbp9nXOYlZOJVAyL8lvueetmPru+xztyvkc9ywPu60osxRmJhlrMRcWJAK8gktMxAwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-6.tower-169.messagelabs.com!1483445252!87820649!1 X-Originating-IP: [47.73.108.138] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29134 invoked from network); 3 Jan 2017 12:07:32 -0000 Received: from vgdpm12vr.vodafone.com (HELO voxe02hw.internal.vodafone.com) (47.73.108.138) by server-6.tower-169.messagelabs.com with AES256-SHA encrypted SMTP; 3 Jan 2017 12:07:32 -0000 Received: from VOEXH08W.internal.vodafone.com (47.73.211.206) by edge1.vodafone.com (195.232.244.47) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 3 Jan 2017 13:07:30 +0100 Received: from VOEXC05W.internal.vodafone.com (145.230.101.25) by VOEXH08W.internal.vodafone.com (47.73.211.212) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 3 Jan 2017 13:07:30 +0100 Received: from VOEXC20W.internal.vodafone.com (145.230.103.125) by VOEXC05W.internal.vodafone.com (145.230.101.25) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 3 Jan 2017 13:07:29 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by VOEXC20W.internal.vodafone.com ([145.230.103.125]) with mapi id 14.03.0294.000; Tue, 3 Jan 2017 13:07:29 +0100 From: "Dawes, Peter, Vodafone Group" To: Andy Hutton , Adam Roach Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSW549jON1XdNft0qMWj02oHw2Q6EmsFcw Date: Tue, 3 Jan 2017 12:07:28 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 12:07:37 -0000 SGVsbG8gQWxsLCANCkEgZmV3IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMt dW53YW50ZWQtMDA6DQpUaGUgdGV4dCBpbiB0aGUgQWJzdHJhY3QgY2xhdXNlICJUaGUgdGVybWlu YXRpbmcgU0lQIGVudGl0eSBtYXkgdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYWRqdXN0IGZ1dHVy ZSBjYWxsIGhhbmRsaW5nIGJlaGF2aW9yIGZvciB0aGlzIGNhbGxlZCBwYXJ0eSBvciBtb3JlIGJy b2FkbHkuIiBtZW50aW9ucyBvbmx5IHRoZSB0ZXJtaW5hdGluZyBTSVAgZW50aXR5IGFuZCB0aGUg SW50cm9kdWN0aW9uIGNsYXVzZSBzYXlzICJDYXJyaWVycyBhbmQgb3RoZXIgc2VydmljZSBwcm92 aWRlcnMgbWF5IHdhbnQgdG8gaGVscCB0aGVpciBzdWJzY3JpYmVycyBhdm9pZCByZWNlaXZpbmcg c3VjaCBjYWxscyAiLiBEb2VzIHRoaXMgZHJhZnQgcHJvaGliaXQgYW55IGludGVybWVkaWFyeSBT SVAgZW50aXR5IGFkanVzdGluZyBpdHMgY2FsbCBoYW5kbGluZyBiZWhhdmlvdXI/IEFsc28sIGl0 IG1pZ2h0IGhlbHAgZm9yIHRoZSBkcmFmdCB0byBhbGxvdyBnZW5lcmFsIGFkanVzdG1lbnQgb2Yg ZnV0dXJlIGhhbmRsaW5nIG9mIGNhbGxzIGZyb20gdGhlIGNhbGxpbmcgcGFydHkuIA0KDQpXaGF0 IGlzIG1lYW50IGluIHRoaXMgZHJhZnQgYnkgImNhbGxlciI/IElzIGl0IHRoZSBvcmlnaW5hdGlu ZyBpZGVudGl0eSB1c2VkIGZvciB0aGUgcGFydGljdWxhciByZWplY3RlZCBjYWxsLCBvciBpcyBp dCBhbnkgaWRlbnRpdHkgb3duZWQgYnkgdGhlIHBlcnNvbiB3aG8gbWFkZSB0aGUgY2FsbD8gSSB0 aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIG9uIHRoaXMuDQoNCklzIHRoaXMgZHJhZnQg c2NvcGVkIHNwZWNpZmljYWxseSB0byB3aGF0IGRyYWZ0LWlldGYtc3Rpci1yZmM0NDc0YmlzLTE1 LnR4dCByZWZlcnMgdG8gYXMgIlRlbGVwaG9uZSBOdW1iZXJzIj8gSSBkb24ndCBzZWUgYW55dGhp bmcgaW4gdGhlIGRyYWZ0IGFib3V0IFNJUCBVUklzLiBJIHRoaW5rIHRoZSBzY29wZSByZWdhcmRp bmcgY2FsbGVyIGlkZW50aXRpZXMgc2hvdWxkIGJlIGNsZWFyLg0KDQpBbmQgYSBjb3VwbGUgb2Yg ZWRpdG9yaWFsczoNCkNsYXVzZSA1LjEgc2F5cyAiIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXIgYSBu ZXcgU0lQIHJlc3BvbnNlIGNvZGUuIg0KQ2xhdXNlIDYgY29udGFpbnMgdGhlIHdvcmQgInJlc2Vy dmlibGUiDQoNClJlZ2FyZHMsDQpQZXRlcg0KDQoNCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkgSHV0dG9uDQpTZW50OiAy MSBEZWNlbWJlciAyMDE2IDE1OjI0DQpUbzogQWRhbSBSb2FjaA0KQ2M6IFNJUENPUkUNClN1Ympl Y3Q6IFJlOiBbc2lwY29yZV0gQWRvcHRlZCAvIFdHTEM6IGRyYWZ0LXNjaHVsenJpbm5lLWRpc3Bh dGNoLXN0YXR1cy11bndhbnRlZA0KDQpNaW5vciBXR0xDIGNvbW1lbnQuDQoNClRoZSBhYnN0cmFj dCBzdGF0ZXMgIlRoZcKgdGVybWluYXRpbmcgU0lQIGVudGl0eSBtYXkgdXNlIHRoaXMgaW5mb3Jt YXRpb24uLi4uIi4NCg0KQnV0IHRoaXMgaXMgbm90IEkgYmVsaWV2ZSByZWZlcnJpbmcgdG8gdGhl IGFjdHVhbCB0ZXJtaW5hdGluZyBTSVAgZW50aXR5IHdoaWNoIGlzIHRoZSBjYWxsZWQgdXNlcnMg ZGV2aWNlIGJ1dCBpcyByZWZlcnJpbmcgdG8gc29tZSBwcmVjZWRpbmcgU0lQIGVudGl0eSBwcm9i YWJseSB0aGUgc2VydmljZSBwcm92aWRlci4NCg0KUmVnYXJkcw0KQW5kecKgDQoNCg0KDQoNCg0K T24gTW9uLCBEZWMgMTIsIDIwMTYgYXQgOTowNSBQTSwgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVt LmNvbT4gd3JvdGU6DQpbYXMgY2hhaXJdDQoNCkkndmUgc2VlbiBzaWduaWZpY2FudCBzdXBwb3J0 IGZvciBhZG9wdGlvbiBvZiBkcmFmdC1zY2h1bHpyaW5uZS1kaXNwYXRjaC1zdGF0dXMtdW53YW50 ZWQgYXMgYSBTSVBDT1JFIGl0ZW0gYW5kIG5vIG9iamVjdGlvbnMuIE91ciByZXZpc2VkIGNoYXJ0 ZXIgdGhhdCBpbmNsdWRlcyBzY29wZSBmb3IgdGhpcyBraW5kIG9mIGl0ZW0gaGFzIGJlZW4gYXBw cm92ZWQuIFRoZSBkb2N1bWVudCBpcyBub3cgYWRvcHRlZCBieSBTSVBDT1JFLiBJIGhhdmUgYXNr ZWQgdGhlIGF1dGhvciB0byBzdWJtaXQgc3Vic2VxdWVudCB2ZXJzaW9ucyBvZiB0aGUgZG9jdW1l bnQgYXMgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC4NCg0KR2l2ZW4gdGhlIHJl bGF0aXZlbHkgdW5jb21wbGljYXRlZCBtZWNoYW5pc20gYmVpbmcgZGVzY3JpYmVkIGFuZCB0aGUg cmVxdWVzdHMgZm9yIGV4cGVkaXRlZCBwcm9jZXNzaW5nLCB3ZSB3aWxsIGJlIHN0YXJ0aW5nIG91 ciB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiB0aGUgZG9jdW1lbnQgdG9kYXkuIEluIHJlY29n bml0aW9uIHRoYXQgdGhlIHVwY29taW5nIHdpbnRlciBob2xpZGF5cyB3aWxsIHRha2Ugc29tZSBw b3J0aW9uIG9mIG1hbnkgcGFydGljaXBhbnRzJyBhdHRlbnRpb24sIGFuZCB0aGF0IG1hbnkgcGVv cGxlIHdpbGwgb2JzZXJ2ZSBhIE5ldyBZZWFyJ3MgSG9saWRheSBvbiBKYW51YXJ5IDJuZCwgd2Ug d2lsbCBydW4gdGhpcyBsYXN0IGNhbGwgZm9yIHRocmVlIHdlZWtzLCBlbmRpbmcgb24gSmFudWFy eSAzcmQuIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFuZCBwcm92aWRlIGNvbW1lbnRzIG9u IGJlZm9yZSB0aGF0IGRhdGUuDQoNCi9hDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9y Zw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCg== From nobody Tue Jan 3 08:48:13 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3AC9129670 for ; Tue, 3 Jan 2017 08:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ca21hUZHfZbE for ; Tue, 3 Jan 2017 08:48:11 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FE9C129534 for ; Tue, 3 Jan 2017 08:48:11 -0800 (PST) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03Gm8jX078819 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 3 Jan 2017 10:48:10 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: "'SIPCORE'" References: From: Adam Roach Message-ID: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> Date: Tue, 3 Jan 2017 10:48:07 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 16:48:12 -0000 This is a reminder that the WGLC for this document ends today. If you have not had time to read and comment on it, please do so in the next few hours. The document is fairly short, and should take very little time to review. Even comments like "I have read the document and believe it is ready for publication" would be useful. /a On 12/12/16 15:05, Adam Roach wrote: > [as chair] > > I've seen significant support for adoption of > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no > objections. Our revised charter that includes scope for this kind of > item has been approved. The document is now adopted by SIPCORE. I have > asked the author to submit subsequent versions of the document as > draft-ietf-sipcore-status-unwanted. > > Given the relatively uncomplicated mechanism being described and the > requests for expedited processing, we will be starting our working > group last call on the document today. In recognition that the > upcoming winter holidays will take some portion of many participants' > attention, and that many people will observe a New Year's Holiday on > January 2nd, we will run this last call for three weeks, ending on > January 3rd. Please review the document and provide comments on before > that date. > > /a > From nobody Tue Jan 3 09:26:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301EF1296B1 for ; Tue, 3 Jan 2017 09:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVTABgp2QKUH for ; Tue, 3 Jan 2017 09:26:50 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0078.outbound.protection.outlook.com [104.47.42.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62EC6129698 for ; Tue, 3 Jan 2017 09:26:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xg90ukEMJBrXXApeL5f33fY+uc9ZWMwmjs3ESVYU2jg=; b=IzBfGmvcBG+i5VfbIxZ2GvYaW1OPo3aUE1frnJQoqj/j5jRuXgGU3BMmdpCzxeE81qviR4uBLqsnTA0PKHHmP1A+w/ihf2RoEjAPE1Po7nRt2JAUoWNoC5Q+oVjhK2rTItG4u0EWbmZUZn39Jl0zKZjHtN/lh8brNGHN7UZZH10= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 17:26:48 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 17:26:47 +0000 From: "Asveren, Tolga" To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvkesfMOzoPkCxU0eOhKCbpKEnAADw Date: Tue, 3 Jan 2017 17:26:47 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> In-Reply-To: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: a29a1ca1-8102-471e-1f84-08d433fdb262 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:3EO5OLRm19oOTRD9Vpr2ekytwA3o9JNtie8GS+EDg8YSV33+MlEiWYaWJOJm1Mnz9SrZSe8zwv2XpFodTUktSnjKZ51Hz8wH7xOVI01xIwEJ1FVY362cLnMVSkF39n4SxKlB+k1YNrMFP7mxfVWiGXrakurzGz0yd8NyZ/zyh+79i1i2T9V9ict6HpQWRZWDl5gYQK27X5lOIlrYE1QSaidC7nw2PlxyYiRN12BYfJT268zHxBvWsmtdE8O7WZPkJ/xskO9pTRSSoupkZMC4IbIblTA7VCP7q6W1HtiDwdFDlq5g+v/fQRsgXuJ6mMN4ma2KWJlv1+WnXUE6/2Jmz+SYfbch6nAQPd2uD0pFEHg9cyMSXwojqfJc0PSyJqAKyiRXhIgORaf7/nfxF8c1vj4YdImg0AqWkapVnEIg9W1j2J3kV+/scp8uE8henyg6HRrDPkHHTYwA6UzSh3XV8g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(13464003)(12213003)(24454002)(199003)(377454003)(106356001)(7696004)(77096006)(5660300001)(38730400001)(7736002)(6436002)(86362001)(74316002)(81166006)(25786008)(2906002)(6506006)(2900100001)(122556002)(3660700001)(8936002)(229853002)(33656002)(2950100002)(9686002)(3280700002)(50986999)(5001770100001)(66066001)(230783001)(107886002)(189998001)(81156014)(99286003)(8676002)(55016002)(3846002)(92566002)(102836003)(68736007)(76176999)(97736004)(305945005)(101416001)(6116002)(106116001)(54356999)(105586002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 17:26:47.6077 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:26:52 -0000 I read the document and have only a single doubt: Would it be better to use "may" instead of "MAY" in 4. (except for the sent= ence about Reason header)? This section is about non-SIP-protocol specific = behavior (except the Reason header usage), which is local and does not need= to be/is not standardized. Not using RFC2119 keywords seems more appropria= te IMHO -but it is not a big deal either way-. Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Tuesday, January 03, 2017 11:48 AM > To: 'SIPCORE' > Subject: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > unwanted >=20 > This is a reminder that the WGLC for this document ends today. If you hav= e > not had time to read and comment on it, please do so in the next few hour= s. > The document is fairly short, and should take very little time to review. >=20 > Even comments like "I have read the document and believe it is ready for > publication" would be useful. >=20 > /a >=20 > On 12/12/16 15:05, Adam Roach wrote: > > [as chair] > > > > I've seen significant support for adoption of > > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no > > objections. Our revised charter that includes scope for this kind of > > item has been approved. The document is now adopted by SIPCORE. I have > > asked the author to submit subsequent versions of the document as > > draft-ietf-sipcore-status-unwanted. > > > > Given the relatively uncomplicated mechanism being described and the > > requests for expedited processing, we will be starting our working > > group last call on the document today. In recognition that the > > upcoming winter holidays will take some portion of many participants' > > attention, and that many people will observe a New Year's Holiday on > > January 2nd, we will run this last call for three weeks, ending on > > January 3rd. Please review the document and provide comments on > before > > that date. > > > > /a > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 3 09:54:27 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51238127ABE for ; Tue, 3 Jan 2017 09:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d5m7Urkj8cNH for ; Tue, 3 Jan 2017 09:54:23 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6309E129A7A for ; Tue, 3 Jan 2017 09:54:23 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03HsGD4091790 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Jan 2017 11:54:16 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: SIPCORE Date: Tue, 03 Jan 2017 11:54:17 -0600 Message-ID: In-Reply-To: <20170103175011.D8B0FB81248@rfc-editor.org> References: <20170103175011.D8B0FB81248@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: aamelnikov@fastmail.fm, alissa@cooperw.in, drage@alcatel-lucent.com, dean.willis@softarmor.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 17:54:25 -0000 Does anyone have thoughts on this errata report? Thanks! Ben. On 3 Jan 2017, at 11:50, RFC Errata System wrote: > The following errata report has been submitted for RFC3515, > "The Session Initiation Protocol (SIP) Refer Method". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898 > > -------------------------------------- > Type: Editorial > Reported by: Marianne MOHALI > > Section: 2.1 > > Original Text > ------------- > Refer-To: biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> > > Corrected Text > -------------- > Refer-To: biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com> > > Notes > ----- > The "=" between the header name (hname) and the value (hvalue) in the > headers component of the URI does not have to be in the percent-coded > format as part of the ABNF of the headers component defined in > RFC3261: > sip:user:password@host:port;uri-parameters?headers > headers = "?" header *( "&" header ) > header = hname "=" hvalue > hname = 1*( hnv-unreserved / unreserved / escaped ) > hvalue = *( hnv-unreserved / unreserved / escaped ) > hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC3515 (draft-ietf-sip-refer-07) > -------------------------------------- > Title : The Session Initiation Protocol (SIP) Refer > Method > Publication Date : April 2003 > Author(s) : R. Sparks > Category : PROPOSED STANDARD > Source : Session Initiation Protocol > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From nobody Tue Jan 3 10:20:51 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51DF2129A6B for ; Tue, 3 Jan 2017 10:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNsBt1WVv2qu for ; Tue, 3 Jan 2017 10:20:47 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DBEF129A69 for ; Tue, 3 Jan 2017 10:20:47 -0800 (PST) Received: from unnumerable.local (mobile-166-173-058-100.mycingular.net [166.173.58.100]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03IKeE1094520 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 3 Jan 2017 12:20:41 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-100.mycingular.net [166.173.58.100] claimed to be unnumerable.local To: Ben Campbell , SIPCORE References: <20170103175011.D8B0FB81248@rfc-editor.org> From: Robert Sparks Message-ID: <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> Date: Tue, 3 Jan 2017 12:20:34 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: drage@alcatel-lucent.com, dean.willis@softarmor.com, alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 18:20:49 -0000 Marianne - why do you think this is important? I'll go do the work to verify that your read that the particular '=' you point to is not necessary to encode, but even it that's correct, it's still allowed to encode it. I don't see how making the change you propose with the errata will help anyone? RjS On 1/3/17 11:54 AM, Ben Campbell wrote: > Does anyone have thoughts on this errata report? > > Thanks! > > Ben. > > On 3 Jan 2017, at 11:50, RFC Errata System wrote: > >> The following errata report has been submitted for RFC3515, >> "The Session Initiation Protocol (SIP) Refer Method". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Marianne MOHALI >> >> Section: 2.1 >> >> Original Text >> ------------- >> Refer-To: > biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >> >> Corrected Text >> -------------- >> Refer-To: > biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com> >> >> Notes >> ----- >> The "=" between the header name (hname) and the value (hvalue) in the >> headers component of the URI does not have to be in the percent-coded >> format as part of the ABNF of the headers component defined in RFC3261: >> sip:user:password@host:port;uri-parameters?headers >> headers = "?" header *( "&" header ) >> header = hname "=" hvalue >> hname = 1*( hnv-unreserved / unreserved / escaped ) >> hvalue = *( hnv-unreserved / unreserved / escaped ) >> hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC3515 (draft-ietf-sip-refer-07) >> -------------------------------------- >> Title : The Session Initiation Protocol (SIP) Refer Method >> Publication Date : April 2003 >> Author(s) : R. Sparks >> Category : PROPOSED STANDARD >> Source : Session Initiation Protocol >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG From nobody Tue Jan 3 10:30:03 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AE8129A9B for ; Tue, 3 Jan 2017 10:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boPjnDa2Q0-0 for ; Tue, 3 Jan 2017 10:29:58 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2FBC1295DE for ; Tue, 3 Jan 2017 10:29:58 -0800 (PST) Received: from unnumerable.local (mobile-166-173-058-100.mycingular.net [166.173.58.100]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03IToDw095374 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 3 Jan 2017 12:29:52 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-100.mycingular.net [166.173.58.100] claimed to be unnumerable.local To: Ben Campbell , SIPCORE References: <20170103175011.D8B0FB81248@rfc-editor.org> <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> From: Robert Sparks Message-ID: <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> Date: Tue, 3 Jan 2017 12:29:45 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: drage@alcatel-lucent.com, dean.willis@softarmor.com, alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 18:30:01 -0000 Eh - nevermind - Marianne's point is that escaping that particulear "=" _isn't_ allowed by the ABNF (shown by what she quotes). So, this is an bug in an example, and the error doesn't affect the specification. This one should go into 'hold for document update'. RjS On 1/3/17 12:20 PM, Robert Sparks wrote: > Marianne - why do you think this is important? > > I'll go do the work to verify that your read that the particular '=' > you point to is not necessary to encode, but even it that's correct, > it's still allowed to encode it. I don't see how making the change you > propose with the errata will help anyone? > > RjS > > > > On 1/3/17 11:54 AM, Ben Campbell wrote: >> Does anyone have thoughts on this errata report? >> >> Thanks! >> >> Ben. >> >> On 3 Jan 2017, at 11:50, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC3515, >>> "The Session Initiation Protocol (SIP) Refer Method". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Marianne MOHALI >>> >>> Section: 2.1 >>> >>> Original Text >>> ------------- >>> Refer-To: >> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >>> >>> Corrected Text >>> -------------- >>> Refer-To: >> biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com> >>> >>> Notes >>> ----- >>> The "=" between the header name (hname) and the value (hvalue) in >>> the headers component of the URI does not have to be in the >>> percent-coded format as part of the ABNF of the headers component >>> defined in RFC3261: >>> sip:user:password@host:port;uri-parameters?headers >>> headers = "?" header *( "&" header ) >>> header = hname "=" hvalue >>> hname = 1*( hnv-unreserved / unreserved / escaped ) >>> hvalue = *( hnv-unreserved / unreserved / escaped ) >>> hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC3515 (draft-ietf-sip-refer-07) >>> -------------------------------------- >>> Title : The Session Initiation Protocol (SIP) Refer >>> Method >>> Publication Date : April 2003 >>> Author(s) : R. Sparks >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG > From nobody Tue Jan 3 11:28:05 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23215129A5A for ; Tue, 3 Jan 2017 11:28:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L86m6N2rB6JE for ; Tue, 3 Jan 2017 11:28:01 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0043.outbound.protection.outlook.com [104.47.41.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E78129A7B for ; Tue, 3 Jan 2017 11:28:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kH+W7WA3kmfswRRI+VUanhoz2qr/U30bqi8xAGngVYA=; b=DFPOsTTTe6lyylrOB5l1124rOaStbdVs5v30iRy8+XjoajKCcyEQNM7DaWnE/lii2T47ZnxJGKrEp01CIbgAc+8GhJq5O0EDYB81zDT7m0KFWPnro3Pwz3+hOT0FTv/PLCvbctfri7IwqN66ruRhb5e3IG6GKqw85gunXqeYYWs= Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 19:27:54 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 19:27:54 +0000 From: "Asveren, Tolga" To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvkesfMOzoPkCxU0eOhKCbpKEnAADwgAAi49A= Date: Tue, 3 Jan 2017 19:27:54 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: e4c5d5ea-b92d-4b23-c979-08d4340e9dcc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:nZ3jT7/4HwC04NyS1G0jr+uphjuMgvI571Lh854fMhRcqhbIoYqTZAW2Id5pGAPizmI1WS9f4XUw2WYr9TVx/KxvMA6EigaFmIBYS0jZ0l2E+iVICtJmgAkZdXPeKGCMhy4u8zq6WN3Zs3H592pPX6O4LDdIpkFdG0Qs4C4+bIDwjDd8GD6CIQ1UmcpQCamzscQar82xpbtNcEk3Ju7yUQtbNvAQTgZbQXiBrivPWuyJ8EHkbEmNmyetOhzlY4gcOzvHJ8bNoEHMYCTyjoT2ljbHBi0LDh4FXkFw83L64ljMw1QMwjf7+3gN+/bgNhk/M+k2SVkXm5ZOUir1+j8ZL+9OVD1R3ylLuYS2VZUHaM9W3mOVoq9i/1832OyDjs5gzjURIFsBwEU64Y2WDcXJ/BEo9TNId0tQi3fU/htriCqsEn5pIeroYE2g0fks1FrlYRSgg+UGzke8Nk60EQKItg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(13464003)(12213003)(24454002)(199003)(377454003)(7696004)(106356001)(77096006)(38730400001)(5660300001)(7736002)(6436002)(86362001)(74316002)(81166006)(25786008)(2906002)(122556002)(2900100001)(6506006)(3280700002)(3660700001)(8936002)(229853002)(33656002)(9686002)(50986999)(5001770100001)(66066001)(230783001)(3900700001)(107886002)(189998001)(81156014)(99286003)(8676002)(55016002)(3846002)(92566002)(102836003)(76176999)(68736007)(97736004)(305945005)(101416001)(6116002)(106116001)(54356999)(105586002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 19:27:54.4568 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 19:28:04 -0000 One more question/comment: Is there a particular reason why 666 shouldn't be applicable to MESSAGE met= hod? Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Tuesday, January 03, 2017 12:27 PM > To: 'Adam Roach' ; 'SIPCORE' > Subject: RE: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > unwanted >=20 > I read the document and have only a single doubt: >=20 > Would it be better to use "may" instead of "MAY" in 4. (except for the > sentence about Reason header)? This section is about non-SIP-protocol > specific behavior (except the Reason header usage), which is local and do= es > not need to be/is not standardized. Not using RFC2119 keywords seems > more appropriate IMHO -but it is not a big deal either way-. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam > > Roach > > Sent: Tuesday, January 03, 2017 11:48 AM > > To: 'SIPCORE' > > Subject: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > > unwanted > > > > This is a reminder that the WGLC for this document ends today. If you > > have not had time to read and comment on it, please do so in the next f= ew > hours. > > The document is fairly short, and should take very little time to revie= w. > > > > Even comments like "I have read the document and believe it is ready > > for publication" would be useful. > > > > /a > > > > On 12/12/16 15:05, Adam Roach wrote: > > > [as chair] > > > > > > I've seen significant support for adoption of > > > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no > > > objections. Our revised charter that includes scope for this kind of > > > item has been approved. The document is now adopted by SIPCORE. I > > > have asked the author to submit subsequent versions of the document > > > as draft-ietf-sipcore-status-unwanted. > > > > > > Given the relatively uncomplicated mechanism being described and the > > > requests for expedited processing, we will be starting our working > > > group last call on the document today. In recognition that the > > > upcoming winter holidays will take some portion of many participants' > > > attention, and that many people will observe a New Year's Holiday on > > > January 2nd, we will run this last call for three weeks, ending on > > > January 3rd. Please review the document and provide comments on > > before > > > that date. > > > > > > /a > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 3 12:12:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43A21129B6E for ; Tue, 3 Jan 2017 12:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ligUobVda5Wp for ; Tue, 3 Jan 2017 12:12:08 -0800 (PST) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F6912945E for ; Tue, 3 Jan 2017 12:12:07 -0800 (PST) Received: from us70tumx2.dmz.alcatel-lucent.com (unknown [135.245.18.14]) by Websense Email Security Gateway with ESMTPS id 3DA1CD23A3048; Tue, 3 Jan 2017 20:12:05 +0000 (GMT) Received: from us70tusmtp2.zam.alcatel-lucent.com (us70tusmtp2.zam.alcatel-lucent.com [135.5.2.64]) by us70tumx2.dmz.alcatel-lucent.com (GMO) with ESMTP id v03KC6Dw009581 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 3 Jan 2017 20:12:06 GMT Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by us70tusmtp2.zam.alcatel-lucent.com (GMO) with ESMTP id v03KC5Bb017457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 3 Jan 2017 20:12:06 GMT Received: from [135.185.238.154] (shoonya.ih.lucent.com [135.185.238.154]) by umail.lucent.com (8.13.8/TPES) with ESMTP id v03KC4Ev013867; Tue, 3 Jan 2017 14:12:04 -0600 (CST) References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> To: Adam Roach , Henning Schulzrinne From: "Vijay K.Gurbani" Message-ID: <8d871de6-b601-3393-69e1-08404b294cf7@nokia-bell-labs.com> Date: Tue, 3 Jan 2017 14:12:04 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:12:10 -0000 On 01/03/2017 10:48 AM, Adam Roach wrote: > This is a reminder that the WGLC for this document ends today. If you > have not had time to read and comment on it, please do so in the next > few hours. The document is fairly short, and should take very little > time to review. > > Even comments like "I have read the document and believe it is ready for > publication" would be useful. Adam, Henning: Document is in good shape. One small nit: - S4: s/and reservible./and reversible./ (I think you mean an action that can be reversed, instead of an action that can be reserved.) Cheers, - vijay -- Vijay K. Gurbani, Bell Laboratories, Nokia Networks Email: vkg@bell-labs.com / vijay.gurbani@nokia-bell-labs.com Web: https://www.bell-labs.com/usr/vijay.gurbani Calendar: http://goo.gl/x3Ogq From nobody Tue Jan 3 12:39:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3031296E5 for ; Tue, 3 Jan 2017 12:39:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Lpdx7scEITR for ; Tue, 3 Jan 2017 12:39:11 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C081296D7 for ; Tue, 3 Jan 2017 12:39:10 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03Kd2ik007887 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 3 Jan 2017 14:39:02 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Robert Sparks" Date: Tue, 03 Jan 2017 14:39:01 -0600 Message-ID: <6757A890-7A1A-4CD4-8C46-7C865D2B82E9@nostrum.com> In-Reply-To: <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> References: <20170103175011.D8B0FB81248@rfc-editor.org> <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: aamelnikov@fastmail.fm, alissa@cooperw.in, SIPCORE , drage@alcatel-lucent.com, dean.willis@softarmor.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:39:13 -0000 Do I read correctly that while Marianne's notes says the "=" "does not have" to be escaped, the reality is that is "not allowed" to be escaped? If so, the note probably needs an adjustment. On 3 Jan 2017, at 12:29, Robert Sparks wrote: > Eh - nevermind - Marianne's point is that escaping that particulear > "=" _isn't_ allowed by the ABNF (shown by what she quotes). > > So, this is an bug in an example, and the error doesn't affect the > specification. This one should go into 'hold for document update'. > > RjS > > On 1/3/17 12:20 PM, Robert Sparks wrote: >> Marianne - why do you think this is important? >> >> I'll go do the work to verify that your read that the particular '=' >> you point to is not necessary to encode, but even it that's correct, >> it's still allowed to encode it. I don't see how making the change >> you propose with the errata will help anyone? >> >> RjS >> >> >> >> On 1/3/17 11:54 AM, Ben Campbell wrote: >>> Does anyone have thoughts on this errata report? >>> >>> Thanks! >>> >>> Ben. >>> >>> On 3 Jan 2017, at 11:50, RFC Errata System wrote: >>> >>>> The following errata report has been submitted for RFC3515, >>>> "The Session Initiation Protocol (SIP) Refer Method". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898 >>>> >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Marianne MOHALI >>>> >>>> Section: 2.1 >>>> >>>> Original Text >>>> ------------- >>>> Refer-To: >>> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >>>> >>>> Corrected Text >>>> -------------- >>>> Refer-To: >>> biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com> >>>> >>>> Notes >>>> ----- >>>> The "=" between the header name (hname) and the value (hvalue) in >>>> the headers component of the URI does not have to be in the >>>> percent-coded format as part of the ABNF of the headers component >>>> defined in RFC3261: >>>> sip:user:password@host:port;uri-parameters?headers >>>> headers = "?" header *( "&" header ) >>>> header = hname "=" hvalue >>>> hname = 1*( hnv-unreserved / unreserved / escaped ) >>>> hvalue = *( hnv-unreserved / unreserved / escaped ) >>>> hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, >>>> please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party >>>> can log in to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3515 (draft-ietf-sip-refer-07) >>>> -------------------------------------- >>>> Title : The Session Initiation Protocol (SIP) Refer >>>> Method >>>> Publication Date : April 2003 >>>> Author(s) : R. Sparks >>>> Category : PROPOSED STANDARD >>>> Source : Session Initiation Protocol >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG >> From nobody Tue Jan 3 12:44:56 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D8F61296F0 for ; Tue, 3 Jan 2017 12:44:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3JYBLpwdRh2 for ; Tue, 3 Jan 2017 12:44:53 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 661AE1296E9 for ; Tue, 3 Jan 2017 12:44:52 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03Kiqjc003807; Tue, 3 Jan 2017 20:44:52 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0049.outbound.protection.outlook.com [23.103.198.49]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p5uehjtn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 20:44:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0FliVDPG6AbbeyuFb2hsFI7KkRvsXJE5IREv7hyglFs=; b=Dlh3HTbMgpZHNWZMFgDmGKfHrdPMVfZQ2F0c3P35fn9oZcecuvBKR9haLBtTX9Inuu7Lxj+C7Hjk4zcCmo2HkImQSeg490qkqVjaZPGkzFslw26olPUTjJDnFqUE4hEFBOzNRbMVu+lbpdWf4XaXHzqS4yl/L5jHIT6Ht6BbnD8= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 20:44:49 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 20:44:49 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , Adam Roach , "'SIPCORE'" Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvTc3ftebulUCpYFxZePDirKEnAVyAgAA2o+A= Date: Tue, 3 Jan 2017 20:44:49 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 92b3980e-fff6-479a-121a-08d434195caf x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:ZunDLBgmZHBrHIA+VE568Jjdr0EkVhr9IQylJjvRzGt+v/oWQvysZB1rQ2/g0RLDh525w6oU3rMbqWe/zaPQn8UQvI0Ylyp7TjKHEMEvCv2KKbEw8a+FA0kQZPkgP1tDkTA/P8jZuSRio64rqfRpT/5buh6TUIkYiHjhIraMEZJK5kfZLmXkGlnC4LmUaewBCzGufr+fAgBXL8/HjXvXbXaqg6jHbvIY7dxt2ylYeWdNs7aO2WibF194weFXN78b8jeuGdczNuTeWMFVggwLrAmq/JNCzjnk+0x0LTioOovT26rRWoR04QMHiFSvC0QRje6Z6T95AizHUXm9yeucMkAyohvzciqjpN4MdeoFFKBaKJwUzXFfKBKIa0Xw9N6V42lTmWXbsK4LEBTR4d7uowcWZcN7T//lY5VLcMcfM/HynNKWrilOavrC3GTSPc1zDKNeJPxzWlKuCR29FoPlKw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(13464003)(199003)(12213003)(377454003)(92566002)(7736002)(55016002)(7696004)(8676002)(33656002)(81166006)(105586002)(81156014)(38730400001)(86362001)(106116001)(189998001)(77096006)(305945005)(3280700002)(102836003)(99286003)(2906002)(107886002)(5001770100001)(5660300001)(9686002)(6436002)(3846002)(230783001)(6116002)(229853002)(97736004)(6506006)(50986999)(3660700001)(74316002)(2950100002)(106356001)(2900100001)(25786008)(66066001)(101416001)(8936002)(54356999)(68736007)(122556002)(76176999)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 20:44:49.8555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:44:55 -0000 I believe https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-00 addresses this issue. (There's only one MAY, in connection with the Reason = header.) If not, please point out what I missed... -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Tuesday, January 03, 2017 12:27 PM To: Adam Roach ; 'SIPCORE' Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-un= wanted I read the document and have only a single doubt: Would it be better to use "may" instead of "MAY" in 4. (except for the sent= ence about Reason header)? This section is about non-SIP-protocol specific = behavior (except the Reason header usage), which is local and does not need= to be/is not standardized. Not using RFC2119 keywords seems more appropria= te IMHO -but it is not a big deal either way-. Thanks, Tolga =20 From nobody Tue Jan 3 12:46:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948AB129456 for ; Tue, 3 Jan 2017 12:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EezBx9m9fQxp for ; Tue, 3 Jan 2017 12:46:49 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D629F129412 for ; Tue, 3 Jan 2017 12:46:49 -0800 (PST) Received: from unnumerable.local (mobile-166-173-058-100.mycingular.net [166.173.58.100]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03Kkgq7008666 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 3 Jan 2017 14:46:43 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-100.mycingular.net [166.173.58.100] claimed to be unnumerable.local To: Ben Campbell References: <20170103175011.D8B0FB81248@rfc-editor.org> <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> <6757A890-7A1A-4CD4-8C46-7C865D2B82E9@nostrum.com> From: Robert Sparks Message-ID: Date: Tue, 3 Jan 2017 14:46:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <6757A890-7A1A-4CD4-8C46-7C865D2B82E9@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: aamelnikov@fastmail.fm, alissa@cooperw.in, SIPCORE , drage@alcatel-lucent.com, dean.willis@softarmor.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:46:51 -0000 That's how I read it, yes. On 1/3/17 2:39 PM, Ben Campbell wrote: > Do I read correctly that while Marianne's notes says the "=" "does not > have" to be escaped, the reality is that is "not allowed" to be > escaped? If so, the note probably needs an adjustment. > > On 3 Jan 2017, at 12:29, Robert Sparks wrote: > >> Eh - nevermind - Marianne's point is that escaping that particulear >> "=" _isn't_ allowed by the ABNF (shown by what she quotes). >> >> So, this is an bug in an example, and the error doesn't affect the >> specification. This one should go into 'hold for document update'. >> >> RjS >> >> On 1/3/17 12:20 PM, Robert Sparks wrote: >>> Marianne - why do you think this is important? >>> >>> I'll go do the work to verify that your read that the particular '=' >>> you point to is not necessary to encode, but even it that's correct, >>> it's still allowed to encode it. I don't see how making the change >>> you propose with the errata will help anyone? >>> >>> RjS >>> >>> >>> >>> On 1/3/17 11:54 AM, Ben Campbell wrote: >>>> Does anyone have thoughts on this errata report? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On 3 Jan 2017, at 11:50, RFC Errata System wrote: >>>> >>>>> The following errata report has been submitted for RFC3515, >>>>> "The Session Initiation Protocol (SIP) Refer Method". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898 >>>>> >>>>> -------------------------------------- >>>>> Type: Editorial >>>>> Reported by: Marianne MOHALI >>>>> >>>>> Section: 2.1 >>>>> >>>>> Original Text >>>>> ------------- >>>>> Refer-To: >>>> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> Refer-To: >>>> biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com> >>>>> >>>>> Notes >>>>> ----- >>>>> The "=" between the header name (hname) and the value (hvalue) in >>>>> the headers component of the URI does not have to be in the >>>>> percent-coded format as part of the ABNF of the headers component >>>>> defined in RFC3261: >>>>> sip:user:password@host:port;uri-parameters?headers >>>>> headers = "?" header *( "&" header ) >>>>> header = hname "=" hvalue >>>>> hname = 1*( hnv-unreserved / unreserved / escaped ) >>>>> hvalue = *( hnv-unreserved / unreserved / escaped ) >>>>> hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary, please >>>>> use "Reply All" to discuss whether it should be verified or >>>>> rejected. When a decision is reached, the verifying party >>>>> can log in to change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC3515 (draft-ietf-sip-refer-07) >>>>> -------------------------------------- >>>>> Title : The Session Initiation Protocol (SIP) Refer >>>>> Method >>>>> Publication Date : April 2003 >>>>> Author(s) : R. Sparks >>>>> Category : PROPOSED STANDARD >>>>> Source : Session Initiation Protocol >>>>> Area : Real-time Applications and Infrastructure >>>>> Stream : IETF >>>>> Verifying Party : IESG >>> From nobody Tue Jan 3 12:56:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06030129705 for ; Tue, 3 Jan 2017 12:56:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vCqKD05zo69 for ; Tue, 3 Jan 2017 12:56:08 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9579129704 for ; Tue, 3 Jan 2017 12:56:08 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03Ks9kJ011513; Tue, 3 Jan 2017 20:56:08 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p5u21xj5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 20:56:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZfRDREtrovMcpCgfH0rz+gs3/CJcUdWrMAj/wSr4JyI=; b=F7EEDyqJO2AwlrFVzltzGBuEobvpcQ/jcQP8OJtJtWLxmPqGLD+VuaCGNpC5zsl/F4CGLvSh9AelWT6xnbAk5mOnrZjYAFlu1Deodc4x/UeTt/srwvHEoHUiEaKteR6PFqoJJBeOFatSiu9wktzFa1HJK6LtDldQqJmb1eMTqbI= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 20:56:06 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 20:56:06 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , Adam Roach , "'SIPCORE'" Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvTc3ftebulUCpYFxZePDirKEnAADwgAAi49CAABaiYA== Date: Tue, 3 Jan 2017 20:56:05 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 22d215ad-70ff-40cc-77ae-08d4341aefc1 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:+PW9v1dSPxdlgfV4/bi134OMreV/X7hVOtcISEaEp/bn9mqNPj3wX6bGLlpGerflMuAABba17TcHaKHs8P/BvfCfwz7hxGGAEmafLMlGJddioUPBWnX31vFJTKI9VrnfrFU/RBvIbWRAN4BPcc4e0FEicD7L7C65YFm6iu1EkXCypjnobDKXcRi/DCywKwrpczS2HJaNmIYsWF1RuBXa6YXLjmfFkPDb5E1lkHYF+6kjBWp2leAR9Qyz5CBaL21lzsQs1xpshyuhN7doJwIbOt2vRV8UPR7KD60+OQYlPW8KYj4Ea6QLpud3s13u51pa2Mys9iVS02idmz6wosPn1GVZh8SaJvadTzynYGmdLWpvzE8bZxVCzRvq4e9ROyOPhR5s8UUtGA7aZjGim08V4sivrFAGk6WfKSIR7gyeqsuQRoFCMXMacPG5+g3Vte1J9J3nVJavUyh4IZi5iBh8dA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(24454002)(13464003)(377454003)(12213003)(189002)(74316002)(9686002)(230783001)(6436002)(25786008)(2950100002)(3846002)(2906002)(86362001)(8676002)(66066001)(122556002)(76176999)(7736002)(81166006)(3900700001)(92566002)(305945005)(575784001)(68736007)(81156014)(3660700001)(8936002)(55016002)(50986999)(107886002)(229853002)(54356999)(6506006)(2900100001)(101416001)(189998001)(3280700002)(33656002)(97736004)(105586002)(77096006)(5660300001)(38730400001)(7696004)(106116001)(99286003)(6116002)(106356001)(102836003)(5001770100001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 20:56:05.9729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 20:56:11 -0000 Tolga, I believe it should indeed apply to MESSAGE as well. MESSAGE makes a cameo = appearance in the introduction ("typically INVITE or MESSAGE"). Should there be an explicit restriction to methods? I checked the IANA regi= stration and the related RFCs of a few non-3261 response codes, and they ge= nerally don't specify the methods they are used with. One reason would be t= o avoid having to update all the documents defining status codes if SIPCORE= adds another SIP method. Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Tuesday, January 03, 2017 2:28 PM To: Adam Roach ; 'SIPCORE' Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-un= wanted One more question/comment: Is there a particular reason why 666 shouldn't be applicable to MESSAGE met= hod? Thanks, Tolga > -----Original Message----- > From: Asveren, Tolga > Sent: Tuesday, January 03, 2017 12:27 PM > To: 'Adam Roach' ; 'SIPCORE' > Subject: RE: [sipcore] Reminder: WGLC:=20 > draft-schulzrinne-dispatch-status- > unwanted >=20 > I read the document and have only a single doubt: >=20 > Would it be better to use "may" instead of "MAY" in 4. (except for the=20 > sentence about Reason header)? This section is about non-SIP-protocol=20 > specific behavior (except the Reason header usage), which is local and=20 > does not need to be/is not standardized. Not using RFC2119 keywords=20 > seems more appropriate IMHO -but it is not a big deal either way-. >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam=20 > > Roach > > Sent: Tuesday, January 03, 2017 11:48 AM > > To: 'SIPCORE' > > Subject: [sipcore] Reminder: WGLC:=20 > > draft-schulzrinne-dispatch-status- > > unwanted > > > > This is a reminder that the WGLC for this document ends today. If=20 > > you have not had time to read and comment on it, please do so in the=20 > > next few > hours. > > The document is fairly short, and should take very little time to revie= w. > > > > Even comments like "I have read the document and believe it is ready=20 > > for publication" would be useful. > > > > /a > > > > On 12/12/16 15:05, Adam Roach wrote: > > > [as chair] > > > > > > I've seen significant support for adoption of=20 > > > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and=20 > > > no objections. Our revised charter that includes scope for this=20 > > > kind of item has been approved. The document is now adopted by=20 > > > SIPCORE. I have asked the author to submit subsequent versions of=20 > > > the document as draft-ietf-sipcore-status-unwanted. > > > > > > Given the relatively uncomplicated mechanism being described and=20 > > > the requests for expedited processing, we will be starting our=20 > > > working group last call on the document today. In recognition that=20 > > > the upcoming winter holidays will take some portion of many participa= nts' > > > attention, and that many people will observe a New Year's Holiday=20 > > > on January 2nd, we will run this last call for three weeks, ending=20 > > > on January 3rd. Please review the document and provide comments on > > before > > > that date. > > > > > > /a > > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma > > ilman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoD= kWM > > 5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D1TnbdxFZGrU6_AsNQJD_xJ6RP5OKuGq > > H2wITUbdg4Gs&s=3DPDIm8MQuwX-JVCng-BEDirWcio4ELjzyIl0OmPl2rgU&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D1TnbdxFZGrU6_AsNQJD_xJ6RP5OKuGqH2wITUbdg4G= s&s=3DPDIm8MQuwX-JVCng-BEDirWcio4ELjzyIl0OmPl2rgU&e=3D=20 From nobody Tue Jan 3 13:06:24 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D2D129717 for ; Tue, 3 Jan 2017 13:06:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOBRcXzx7LiF for ; Tue, 3 Jan 2017 13:06:21 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6AA1293FF for ; Tue, 3 Jan 2017 13:06:21 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03Ki38C006192; Tue, 3 Jan 2017 20:47:08 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0055.outbound.protection.outlook.com [23.103.198.55]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p5u21xdd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 20:47:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iXHvD2dyGz0OfrV2Vsg5rnf99ssBG0SNYEIfK9yvJA4=; b=sJywJVQygc9CpZVT70vUQmNdgisOJ6ngn9uyCjoxfZoG9wns9PVOyW8MUhP/ujL1/N49iw7eQWIfnmbDKXJ4ASgR12ymqdDzqKwseuiqRqD6HkRvBcsUXzXy6XgzkuZtv2reirJg5yMemG/UJIu42LSJoiqFsOnXPkhv2yPS9Sw= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 20:47:06 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 20:47:06 +0000 From: Henning Schulzrinne To: "Vijay K.Gurbani" , Adam Roach Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvTc3ftebulUCpYFxZePDirKEnL4oAgAAJjbA= Date: Tue, 3 Jan 2017 20:47:06 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> <8d871de6-b601-3393-69e1-08404b294cf7@nokia-bell-labs.com> In-Reply-To: <8d871de6-b601-3393-69e1-08404b294cf7@nokia-bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 66e4e540-6296-4d58-1a40-08d43419addb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:d5cjdP6N4ibZ/WL8NdfDCV9n6cDp34XHVPJFPDFfxLA/5BbJE4xLR/Zt4YhQXYbKItPKYi5N3s9UFMmT+zQcd5B7eev4h38nEDxwSzQFlziPwi+/oxH+AXG7hSAqASOu1KWzidjd+JoX/juP9m7aefW9oC+xTkbOcxb8AYYsXredDR4SoBtJo5VMkGWvpVwwXcWQV+SwcN/icLkpGjgGD/O8PHBGuiDDbcUKj2IhVi/rDQT7bt7fki6OLJgAhD768JLND7POKbD4jjZhkQ3iaqDP/D+TI/zTGAfBkZccONS9jZ5UHrgCv/gMsACnWLEAQLxt+1sFLzNeGHW8IgLUdUHs0Xk4KMK6/liODZrXRk965snwH2blvAEdr2/TqCN9k8fHqUo/RlKYPRzn6h8CPyz3RVZBup9Ab8hFtKdJdP8H4PbZPJycZ66V4CXCKmGlCIcxiyhxK+sMUZmxjs6fYw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85170053105377); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(13464003)(199003)(12213003)(377454003)(92566002)(7736002)(55016002)(7696004)(8676002)(33656002)(81166006)(105586002)(81156014)(38730400001)(86362001)(106116001)(189998001)(77096006)(305945005)(3280700002)(102836003)(99286003)(2906002)(5001770100001)(5660300001)(9686002)(6436002)(3846002)(230783001)(6116002)(229853002)(97736004)(6506006)(50986999)(3660700001)(74316002)(2950100002)(106356001)(4326007)(2900100001)(25786008)(66066001)(101416001)(8936002)(54356999)(68736007)(122556002)(76176999)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 20:47:06.0325 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:06:23 -0000 Yup, blame auto-correct :-) Fixed. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Vijay K.Gurban= i Sent: Tuesday, January 03, 2017 3:12 PM To: Adam Roach ; Henning Schulzrinne Cc: sipcore@ietf.org Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-un= wanted Adam, Henning: Document is in good shape. One small nit: - S4: s/and reservible./and reversible./ (I think you mean an action that can be reversed, instead of an action that can be reserved.) Cheers, =20 From nobody Tue Jan 3 13:22:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635091296B4 for ; Tue, 3 Jan 2017 13:21:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPufyVy9WKNR for ; Tue, 3 Jan 2017 13:21:57 -0800 (PST) Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AC512966F for ; Tue, 3 Jan 2017 13:21:56 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 21DA3C0BD8; Tue, 3 Jan 2017 22:21:55 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id D4E1212006D; Tue, 3 Jan 2017 22:21:54 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 22:21:54 +0100 From: To: Robert Sparks , Ben Campbell , SIPCORE Thread-Topic: [Editorial Errata Reported] RFC3515 (4898) Thread-Index: AQHSZenXQao3RUyO60SWEGR4I7ygGKEm+DaAgAAHWACAAAKRgIAAK2uw Date: Tue, 3 Jan 2017 21:21:53 +0000 Message-ID: <10032_1483478514_586C15F2_10032_3554_1_8B970F90C584EA4E97D5BAAC9172DBB81C88D2E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20170103175011.D8B0FB81248@rfc-editor.org> <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> In-Reply-To: <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "drage@alcatel-lucent.com" , "dean.willis@softarmor.com" , "alissa@cooperw.in" , "aamelnikov@fastmail.fm" Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:21:59 -0000 Hi Robert, FYI, we have experienced an equipment that rejects a REFER because of parsi= ng issues caused by percent-coded characters not identified as ABNF element= s for the header.=20 Indeed, this only an example in RFC3515 and that's why I put the "editorial= " category for the Errata. >From RFC3261 : Characters other than those in the "reserved" set (see RFC 2396 [5]) are eq= uivalent to their ""%" HEX HEX" encoding. -> which is not the case of the reserved character "=3D"=20 BR, Marianne -----Message d'origine----- De=A0: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Envoy=E9=A0: mardi 3 janvier 2017 19:30 =C0=A0: Ben Campbell; SIPCORE Cc=A0: alissa@cooperw.in; aamelnikov@fastmail.fm; dean.willis@softarmor.com= ; drage@alcatel-lucent.com; MOHALI Marianne IMT/OLN Objet=A0: Re: [Editorial Errata Reported] RFC3515 (4898) Eh - nevermind - Marianne's point is that escaping that particulear "=3D"= =20 _isn't_ allowed by the ABNF (shown by what she quotes). So, this is an bug in an example, and the error doesn't affect the specific= ation. This one should go into 'hold for document update'. RjS On 1/3/17 12:20 PM, Robert Sparks wrote: > Marianne - why do you think this is important? > > I'll go do the work to verify that your read that the particular '=3D'=20 > you point to is not necessary to encode, but even it that's correct,=20 > it's still allowed to encode it. I don't see how making the change you=20 > propose with the errata will help anyone? > > RjS > > > > On 1/3/17 11:54 AM, Ben Campbell wrote: >> Does anyone have thoughts on this errata report? >> >> Thanks! >> >> Ben. >> >> On 3 Jan 2017, at 11:50, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC3515, "The=20 >>> Session Initiation Protocol (SIP) Refer Method". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=3D3515&eid=3D4898 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Marianne MOHALI >>> >>> Section: 2.1 >>> >>> Original Text >>> ------------- >>> Refer-To: >> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >>> >>> Corrected Text >>> -------------- >>> Refer-To: >> biloxi.example.net&Call-ID=3D55432%40alicepc.atlanta.example.com> >>> >>> Notes >>> ----- >>> The "=3D" between the header name (hname) and the value (hvalue) in=20 >>> the headers component of the URI does not have to be in the=20 >>> percent-coded format as part of the ABNF of the headers component=20 >>> defined in RFC3261: >>> sip:user:password@host:port;uri-parameters?headers >>> headers =3D "?" header *( "&" header ) >>> header =3D hname "=3D" hvalue >>> hname =3D 1*( hnv-unreserved / unreserved / escaped ) >>> hvalue =3D *( hnv-unreserved / unreserved / escaped ) >>> hnv-unreserved =3D "[" / "]" / "/" / "?" / ":" / "+" / "$" >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please=20 >>> use "Reply All" to discuss whether it should be verified or=20 >>> rejected. When a decision is reached, the verifying party can log in=20 >>> to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC3515 (draft-ietf-sip-refer-07) >>> -------------------------------------- >>> Title : The Session Initiation Protocol (SIP) Refer=20 >>> Method >>> Publication Date : April 2003 >>> Author(s) : R. Sparks >>> Category : PROPOSED STANDARD >>> Source : Session Initiation Protocol >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jan 3 13:24:13 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2851296B4 for ; Tue, 3 Jan 2017 13:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8nmKT8HWaHC for ; Tue, 3 Jan 2017 13:24:09 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D28312966E for ; Tue, 3 Jan 2017 13:24:09 -0800 (PST) Received: from unnumerable.local (mobile-166-173-058-100.mycingular.net [166.173.58.100]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03LO3Kt012376 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Tue, 3 Jan 2017 15:24:04 -0600 (CST) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-100.mycingular.net [166.173.58.100] claimed to be unnumerable.local To: marianne.mohali@orange.com, Ben Campbell , SIPCORE References: <20170103175011.D8B0FB81248@rfc-editor.org> <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> <10032_1483478514_586C15F2_10032_3554_1_8B970F90C584EA4E97D5BAAC9172DBB81C88D2E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Robert Sparks Message-ID: <921520c9-b6fd-b81d-528d-cb387f00fd95@nostrum.com> Date: Tue, 3 Jan 2017 15:23:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <10032_1483478514_586C15F2_10032_3554_1_8B970F90C584EA4E97D5BAAC9172DBB81C88D2E9@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "drage@alcatel-lucent.com" , "dean.willis@softarmor.com" , "alissa@cooperw.in" , "aamelnikov@fastmail.fm" Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:24:11 -0000 On 1/3/17 3:21 PM, marianne.mohali@orange.com wrote: > Hi Robert, > > FYI, we have experienced an equipment that rejects a REFER because of parsing issues caused by percent-coded characters not identified as ABNF elements for the header. > Indeed, this only an example in RFC3515 and that's why I put the "editorial" category for the Errata. > > From RFC3261 : > Characters other than those in the "reserved" set (see RFC 2396 [5]) are equivalent to their ""%" HEX HEX" encoding. > -> which is not the case of the reserved character "=" More specifically, the URI production rules you quote are more specific about what can be escaped than the rest of the ABNF are, and that particular "=" sign does not allow escaping where it is produced. > BR, > Marianne > -----Message d'origine----- > De : Robert Sparks [mailto:rjsparks@nostrum.com] > Envoyé : mardi 3 janvier 2017 19:30 > À : Ben Campbell; SIPCORE > Cc : alissa@cooperw.in; aamelnikov@fastmail.fm; dean.willis@softarmor.com; drage@alcatel-lucent.com; MOHALI Marianne IMT/OLN > Objet : Re: [Editorial Errata Reported] RFC3515 (4898) > > Eh - nevermind - Marianne's point is that escaping that particulear "=" > _isn't_ allowed by the ABNF (shown by what she quotes). > > So, this is an bug in an example, and the error doesn't affect the specification. This one should go into 'hold for document update'. > > RjS > > On 1/3/17 12:20 PM, Robert Sparks wrote: >> Marianne - why do you think this is important? >> >> I'll go do the work to verify that your read that the particular '=' >> you point to is not necessary to encode, but even it that's correct, >> it's still allowed to encode it. I don't see how making the change you >> propose with the errata will help anyone? >> >> RjS >> >> >> >> On 1/3/17 11:54 AM, Ben Campbell wrote: >>> Does anyone have thoughts on this errata report? >>> >>> Thanks! >>> >>> Ben. >>> >>> On 3 Jan 2017, at 11:50, RFC Errata System wrote: >>> >>>> The following errata report has been submitted for RFC3515, "The >>>> Session Initiation Protocol (SIP) Refer Method". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3515&eid=4898 >>>> >>>> -------------------------------------- >>>> Type: Editorial >>>> Reported by: Marianne MOHALI >>>> >>>> Section: 2.1 >>>> >>>> Original Text >>>> ------------- >>>> Refer-To: >>> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >>>> >>>> Corrected Text >>>> -------------- >>>> Refer-To: >>> biloxi.example.net&Call-ID=55432%40alicepc.atlanta.example.com> >>>> >>>> Notes >>>> ----- >>>> The "=" between the header name (hname) and the value (hvalue) in >>>> the headers component of the URI does not have to be in the >>>> percent-coded format as part of the ABNF of the headers component >>>> defined in RFC3261: >>>> sip:user:password@host:port;uri-parameters?headers >>>> headers = "?" header *( "&" header ) >>>> header = hname "=" hvalue >>>> hname = 1*( hnv-unreserved / unreserved / escaped ) >>>> hvalue = *( hnv-unreserved / unreserved / escaped ) >>>> hnv-unreserved = "[" / "]" / "/" / "?" / ":" / "+" / "$" >>>> >>>> Instructions: >>>> ------------- >>>> This erratum is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or >>>> rejected. When a decision is reached, the verifying party can log in >>>> to change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3515 (draft-ietf-sip-refer-07) >>>> -------------------------------------- >>>> Title : The Session Initiation Protocol (SIP) Refer >>>> Method >>>> Publication Date : April 2003 >>>> Author(s) : R. Sparks >>>> Category : PROPOSED STANDARD >>>> Source : Session Initiation Protocol >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Tue Jan 3 13:40:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18BB31295D4 for ; Tue, 3 Jan 2017 13:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFxcICdr9IVP for ; Tue, 3 Jan 2017 13:40:10 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5200F129461 for ; Tue, 3 Jan 2017 13:40:09 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03Le6Sr017804; Tue, 3 Jan 2017 21:40:09 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0047.outbound.protection.outlook.com [23.103.198.47]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4n29m7s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 21:40:08 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NJp6DiKrZ1hCuMN0ssZxRjfnmtzxKSClb+Ha2Axg/yo=; b=iLUiaG30PUi8+1bF8IVlDejJ1JDpbxwh1J117WDrlr7d0MEKoB6PvmUNbPXgaD5g+hEsjnMABBHI9MEK6Ehcs7NpwFV3sbXXgpQ5mJ13aVhWjjHWNQDDnkiOKtPK+06ZdXN1H+06V2KopVDeuKJ8577O9LpWbwjhlj0FlXob9Q0= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 21:40:06 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 21:40:06 +0000 From: Henning Schulzrinne To: "Dawes, Peter, Vodafone Group" Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSW548qMD8vRge80+2+9lpYnPuvKEmvKsAgACZRLA= Date: Tue, 3 Jan 2017 21:40:06 +0000 Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 86932c95-1b8d-44a8-a01b-08d434211573 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:jYUF6Li0afjAsLh9iMwW6FMWIIXtSvYnE6C4x0cWPYUB9UpzZr07OslaqVZMa7jqeV/YDN+OJUg6IWloJZo47MtptooVJ7YTSuKVN7GaKFzLfq0YBuVHSF9PF0IW/hxIhFmsd2+FRaK1Lm3cFZXXkw1+uB8wrIsbxADB5kNKDAaM80b81zGRqGssQfCkknsdf3i1ukTiNne6UiYFPFoWml9HYbjJpgs6YgWZAhGTa3p04R2gIMYD4p9sWVGTmtl1QY4x29J8RA04lS7kGRB2+BYEEdYUBvO7fQSYFMaaTC+44CCDVfYzkP0wF8R6TF19FO+JXSlfvMFGG160/5GSmbisefEtxuLFHnpZx3IqZNhto2g+SBGpvbMqnYE1QMqpRsNhv/EOvHOpItX0FRrnMNaPoXeV4sGZf+AR2uDb2pzXxS1KUSMhinks+xJRqxp08WiYDR2HJJsnuioWeJ2PIg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558021)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(13464003)(189002)(377454003)(53754006)(54356999)(81156014)(8676002)(7736002)(76176999)(86362001)(92566002)(122556002)(50986999)(8936002)(101416001)(2900100001)(105586002)(4326007)(74316002)(106356001)(102836003)(6506006)(38730400001)(3660700001)(106116001)(3280700002)(8656002)(25786008)(68736007)(229853002)(81166006)(2950100002)(33656002)(7696004)(6436002)(189998001)(97736004)(5660300001)(77096006)(6116002)(99286003)(230783001)(55016002)(110136003)(790700001)(3846002)(9686002)(66066001)(2906002)(6916009)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06340ECD968A14BD7B94D482EA6E0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 21:40:06.2064 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:40:13 -0000 --_000_CY1PR09MB06340ECD968A14BD7B94D482EA6E0CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGxlYXNlIHNlZSBpbmxpbmUuDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IERhd2VzLCBQZXRlciwgVm9kYWZvbmUgR3JvdXANClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMDMs IDIwMTcgNzowNyBBTQ0KVG86IEFuZHkgSHV0dG9uIDxhbmR5aHV0dG9uLmlldGZAZ21haWwuY29t PjsgQWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT4NCkNjOiBTSVBDT1JFIDxzaXBjb3JlQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBBZG9wdGVkIC8gV0dMQzogZHJhZnQtc2No dWx6cmlubmUtZGlzcGF0Y2gtc3RhdHVzLXVud2FudGVkDQoNCg0KDQpIZWxsbyBBbGwsDQoNCkEg ZmV3IGNvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDA6DQoN ClRoZSB0ZXh0IGluIHRoZSBBYnN0cmFjdCBjbGF1c2UgIlRoZSB0ZXJtaW5hdGluZyBTSVAgZW50 aXR5IG1heSB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBhZGp1c3QgZnV0dXJlIGNhbGwgaGFuZGxp bmcgYmVoYXZpb3IgZm9yIHRoaXMgY2FsbGVkIHBhcnR5IG9yIG1vcmUgYnJvYWRseS4iIG1lbnRp b25zIG9ubHkgdGhlIHRlcm1pbmF0aW5nIFNJUCBlbnRpdHkgYW5kIHRoZSBJbnRyb2R1Y3Rpb24g Y2xhdXNlIHNheXMgIkNhcnJpZXJzIGFuZCBvdGhlciBzZXJ2aWNlIHByb3ZpZGVycyBtYXkgd2Fu dCB0byBoZWxwIHRoZWlyIHN1YnNjcmliZXJzIGF2b2lkIHJlY2VpdmluZyBzdWNoIGNhbGxzICIu IERvZXMgdGhpcyBkcmFmdCBwcm9oaWJpdCBhbnkgaW50ZXJtZWRpYXJ5IFNJUCBlbnRpdHkgYWRq dXN0aW5nIGl0cyBjYWxsIGhhbmRsaW5nIGJlaGF2aW91cj8gQWxzbywgaXQgbWlnaHQgaGVscCBm b3IgdGhlIGRyYWZ0IHRvIGFsbG93IGdlbmVyYWwgYWRqdXN0bWVudCBvZiBmdXR1cmUgaGFuZGxp bmcgb2YgY2FsbHMgZnJvbSB0aGUgY2FsbGluZyBwYXJ0eS4NCg0KDQoNCk5vIHByb2hpYml0aW9u IGlzIGltcGxpZWQ7IEkgd2lsbCBhbGlnbiB0aGUgd29yZGluZyBpbiB0aGUgYWJzdHJhY3Qgd2l0 aCB0aG9zZSBpbiB0aGUgaW50cm9kdWN0aW9uLiBJIHRoaW5rLCBpbiBnZW5lcmFsLCBmb3IgYW55 IFNJUCByZXNwb25zZSBjb2RlLCBhbnkgU0lQIGVudGl0eSB0aGF0IHJlY2VpdmVzIHRoZSBjb2Rl IGNhbiBkbyB3aGF0IGl0IG5lZWRzL3dhbnRzIHRvIGRvIChzdWJqZWN0IHRvIGl0cyByb2xlIGlu IHRoZSBjYWxsIGZsb3cpLiBJ4oCZbSBub3QgcXVpdGUgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IOKA nGdlbmVyYWwgYWRqdXN0bWVudOKAnS4gUmUtcmVhZGluZyB0aGUgc2VudGVuY2UsIHRoaXMgY291 bGQgYmUgaW1wcm92ZWQgdG8gaW5jbHVkZSBib3RoIHRoZSBjYWxsZWQgYW5kIGNhbGxpbmcgcGFy dHk6IOKAnFNJUCBlbnRpdGllcyBtYXkgdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYWRqdXN0IGhv dyBmdXR1cmUgY2FsbHMgZnJvbSB0aGlzIGNhbGxpbmcgcGFydHkgYXJlIGhhbmRsZWQgZm9yIHRo ZSBjYWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LuKAnSBJcyB0aGF0IGNsZWFyZXI/DQoNCg0K DQpXaGF0IGlzIG1lYW50IGluIHRoaXMgZHJhZnQgYnkgImNhbGxlciI/IElzIGl0IHRoZSBvcmln aW5hdGluZyBpZGVudGl0eSB1c2VkIGZvciB0aGUgcGFydGljdWxhciByZWplY3RlZCBjYWxsLCBv ciBpcyBpdCBhbnkgaWRlbnRpdHkgb3duZWQgYnkgdGhlIHBlcnNvbiB3aG8gbWFkZSB0aGUgY2Fs bD8gSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIG9uIHRoaXMuDQoNClBsZWFzZSBz ZWUgYWJvdmU7IGFueSB3b3JkaW5nIHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KDQpJcyB0aGlz IGRyYWZ0IHNjb3BlZCBzcGVjaWZpY2FsbHkgdG8gd2hhdCBkcmFmdC1pZXRmLXN0aXItcmZjNDQ3 NGJpcy0xNS50eHQgcmVmZXJzIHRvIGFzICJUZWxlcGhvbmUgTnVtYmVycyI/IEkgZG9uJ3Qgc2Vl IGFueXRoaW5nIGluIHRoZSBkcmFmdCBhYm91dCBTSVAgVVJJcy4gSSB0aGluayB0aGUgc2NvcGUg cmVnYXJkaW5nIGNhbGxlciBpZGVudGl0aWVzIHNob3VsZCBiZSBjbGVhci4NCg0KTm8sIEkgZG9u 4oCZdCB0aGluayB0aGlzIG5lZWRzIHRvIGJlIHJlc3RyaWN0ZWQgdG8gcGhvbmUgbnVtYmVycy4g QXMgbG9uZyBhcyB0aGUgY2FsbGluZyBwYXJ0eSBjYW4gYmUgaWRlbnRpZmllZCAodGVsIG9yIFNJ UCBVUkkpLCBJIHNlZSBubyByZWFzb24gdG8gcmVzdHJpY3QgaXQuIEkgd2lsbCBub3RlIHRoYXQg dGhpcyBkb2VzIG5vdCBkZXBlbmQgb24gdGhlIFNJUCBVUkkuIFRoZXJl4oCZcyB0aGUgb3BlcmF0 aW9uYWwgcHJvYmxlbSBvZiBtYXBwaW5nIG11bHRpcGxlIHJlbmRlcmluZ3Mgb2YgdGhlIHNhbWUg bnVtYmVyIHRvIGJlIHRoZSBzYW1lIOKAnHBhcnR54oCdLCBidXQgSSBkb27igJl0IHRoaW5rIHRo ZSBkcmFmdCBuZWVkcyB0byBnbyB0aGVyZSwgYXMgdGhpcyBzZWVtcyBsaWtlIGFuIGltcGxlbWVu dGF0aW9uIGNob2ljZS4gVXNpbmcgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJvY2VkdXJlIGluIFJG QzQ0NzRiaXMgU2VjdGlvbiA4LjMgaXMgbGlrZWx5IGEgZ29vZCBpZGVhLiBTaG91bGQgdGhpcyBi ZSBjYWxsZWQgb3V0Pw0KDQoNCg0KUmVhZGluZyB0aGUgcmVsZXZhbnQgc2VjdGlvbnMgb2YgNDQ3 NGJpcyByZW1pbmRzIG1lIHRoYXQgYW5vbnltb3VzIFNJUCBVUklzIHNob3VsZCBwcm9iYWJseSBu b3QgYmUgaW5jbHVkZWQgaW4gYW55IFVSSS1zcGVjaWZpYyBjYWxsIGhhbmRsaW5nLiBJ4oCZdmUg YWRkZWQgYSBzZW50ZW5jZSBpZGVudGlmeWluZyB0aGUgaXNzdWUsIHdpdGhvdXQgYW55IG5vcm1h dGl2ZSBzdGF0ZW1lbnRzLg0KDQoNCg0KQW5kIGEgY291cGxlIG9mIGVkaXRvcmlhbHM6DQoNCkNs YXVzZSA1LjEgc2F5cyAiIFRoaXMgZG9jdW1lbnQgcmVnaXN0ZXIgYSBuZXcgU0lQIHJlc3BvbnNl IGNvZGUuIg0KDQpDbGF1c2UgNiBjb250YWlucyB0aGUgd29yZCAicmVzZXJ2aWJsZSINCg0KQm90 aCBmaXhlZC4NCg0KDQoNCg0KDQo9DQo= --_000_CY1PR09MB06340ECD968A14BD7B94D482EA6E0CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNv UGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxh aW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UGxlYXNlIHNlZSBpbmxpbmUuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4tLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwPGJyPg0KU2Vu dDogVHVlc2RheSwgSmFudWFyeSAwMywgMjAxNyA3OjA3IEFNPGJyPg0KVG86IEFuZHkgSHV0dG9u ICZsdDthbmR5aHV0dG9uLmlldGZAZ21haWwuY29tJmd0OzsgQWRhbSBSb2FjaCAmbHQ7YWRhbUBu b3N0cnVtLmNvbSZndDs8YnI+DQpDYzogU0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8 YnI+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEFkb3B0ZWQgLyBXR0xDOiBkcmFmdC1zY2h1bHpy aW5uZS1kaXNwYXRjaC1zdGF0dXMtdW53YW50ZWQ8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+SGVsbG8gQWxsLCA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDou NWluIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj5BIGZldyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVz LXVud2FudGVkLTAwOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSB0ZXh0IGluIHRoZSBBYnN0cmFjdCBj bGF1c2UgJnF1b3Q7VGhlIHRlcm1pbmF0aW5nIFNJUCBlbnRpdHkgbWF5IHVzZSB0aGlzIGluZm9y bWF0aW9uIHRvIGFkanVzdCBmdXR1cmUgY2FsbCBoYW5kbGluZyBiZWhhdmlvciBmb3IgdGhpcyBj YWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LiZxdW90OyBtZW50aW9ucyBvbmx5IHRoZSB0ZXJt aW5hdGluZyBTSVAgZW50aXR5IGFuZA0KIHRoZSBJbnRyb2R1Y3Rpb24gY2xhdXNlIHNheXMgJnF1 b3Q7Q2FycmllcnMgYW5kIG90aGVyIHNlcnZpY2UgcHJvdmlkZXJzIG1heSB3YW50IHRvIGhlbHAg dGhlaXIgc3Vic2NyaWJlcnMgYXZvaWQgcmVjZWl2aW5nIHN1Y2ggY2FsbHMgJnF1b3Q7LiBEb2Vz IHRoaXMgZHJhZnQgcHJvaGliaXQgYW55IGludGVybWVkaWFyeSBTSVAgZW50aXR5IGFkanVzdGlu ZyBpdHMgY2FsbCBoYW5kbGluZyBiZWhhdmlvdXI/IEFsc28sIGl0IG1pZ2h0IGhlbHAgZm9yIHRo ZSBkcmFmdA0KIHRvIGFsbG93IGdlbmVyYWwgYWRqdXN0bWVudCBvZiBmdXR1cmUgaGFuZGxpbmcg b2YgY2FsbHMgZnJvbSB0aGUgY2FsbGluZyBwYXJ0eS4gPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gc3R5bGU9ImNv bG9yOiM0RjgxQkQiPk5vIHByb2hpYml0aW9uIGlzIGltcGxpZWQ7IEkgd2lsbCBhbGlnbiB0aGUg d29yZGluZyBpbiB0aGUgYWJzdHJhY3Qgd2l0aCB0aG9zZSBpbiB0aGUgaW50cm9kdWN0aW9uLiBJ IHRoaW5rLCBpbiBnZW5lcmFsLCBmb3IgYW55IFNJUCByZXNwb25zZSBjb2RlLCBhbnkgU0lQIGVu dGl0eSB0aGF0IHJlY2VpdmVzIHRoZSBjb2RlIGNhbiBkbyB3aGF0IGl0IG5lZWRzL3dhbnRzDQog dG8gZG8gKHN1YmplY3QgdG8gaXRzIHJvbGUgaW4gdGhlIGNhbGwgZmxvdykuIEnigJltIG5vdCBx dWl0ZSBzdXJlIHdoYXQgeW91IG1lYW4gYnkg4oCcZ2VuZXJhbCBhZGp1c3RtZW504oCdLiBSZS1y ZWFkaW5nIHRoZSBzZW50ZW5jZSwgdGhpcyBjb3VsZCBiZSBpbXByb3ZlZCB0byBpbmNsdWRlIGJv dGggdGhlIGNhbGxlZCBhbmQgY2FsbGluZyBwYXJ0eTog4oCcU0lQIGVudGl0aWVzIG1heSB1c2Ug dGhpcyBpbmZvcm1hdGlvbiB0byBhZGp1c3QgaG93IGZ1dHVyZQ0KIGNhbGxzIGZyb20gdGhpcyBj YWxsaW5nIHBhcnR5IGFyZSBoYW5kbGVkIGZvciB0aGUgY2FsbGVkIHBhcnR5IG9yIG1vcmUgYnJv YWRseS7igJ0gSXMgdGhhdCBjbGVhcmVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPldoYXQgaXMgbWVhbnQgaW4gdGhpcyBkcmFmdCBieSAmcXVvdDtjYWxsZXImcXVvdDs/ IElzIGl0IHRoZSBvcmlnaW5hdGluZyBpZGVudGl0eSB1c2VkIGZvciB0aGUgcGFydGljdWxhciBy ZWplY3RlZCBjYWxsLCBvciBpcyBpdCBhbnkgaWRlbnRpdHkgb3duZWQgYnkgdGhlIHBlcnNvbiB3 aG8gbWFkZSB0aGUgY2FsbD8gSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIG9uDQog dGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj5QbGVhc2Ugc2VlIGFib3ZlOyBhbnkgd29yZGluZyBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5JcyB0aGlzIGRyYWZ0IHNjb3BlZCBzcGVjaWZpY2FsbHkg dG8gd2hhdCBkcmFmdC1pZXRmLXN0aXItcmZjNDQ3NGJpcy0xNS50eHQgcmVmZXJzIHRvIGFzICZx dW90O1RlbGVwaG9uZSBOdW1iZXJzJnF1b3Q7PyBJIGRvbid0IHNlZSBhbnl0aGluZyBpbiB0aGUg ZHJhZnQgYWJvdXQgU0lQIFVSSXMuIEkgdGhpbmsgdGhlIHNjb3BlIHJlZ2FyZGluZyBjYWxsZXIg aWRlbnRpdGllcyBzaG91bGQNCiBiZSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj5ObywgSSBk b27igJl0IHRoaW5rIHRoaXMgbmVlZHMgdG8gYmUgcmVzdHJpY3RlZCB0byBwaG9uZSBudW1iZXJz LiBBcyBsb25nIGFzIHRoZSBjYWxsaW5nIHBhcnR5IGNhbiBiZSBpZGVudGlmaWVkICh0ZWwgb3Ig U0lQIFVSSSksIEkgc2VlIG5vIHJlYXNvbiB0byByZXN0cmljdCBpdC4gSSB3aWxsIG5vdGUgdGhh dCB0aGlzIGRvZXMgbm90IGRlcGVuZCBvbiB0aGUNCiBTSVAgVVJJLiBUaGVyZeKAmXMgdGhlIG9w ZXJhdGlvbmFsIHByb2JsZW0gb2YgbWFwcGluZyBtdWx0aXBsZSByZW5kZXJpbmdzIG9mIHRoZSBz YW1lIG51bWJlciB0byBiZSB0aGUgc2FtZSDigJxwYXJ0eeKAnSwgYnV0IEkgZG9u4oCZdCB0aGlu ayB0aGUgZHJhZnQgbmVlZHMgdG8gZ28gdGhlcmUsIGFzIHRoaXMgc2VlbXMgbGlrZSBhbiBpbXBs ZW1lbnRhdGlvbiBjaG9pY2UuIFVzaW5nIHRoZSBjYW5vbmljYWxpemF0aW9uIHByb2NlZHVyZSBp biBSRkM0NDc0YmlzDQogU2VjdGlvbiA4LjMgaXMgbGlrZWx5IGEgZ29vZCBpZGVhLiBTaG91bGQg dGhpcyBiZSBjYWxsZWQgb3V0PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxzcGFuIHN0eWxlPSJjb2xvcjojNEY4MUJEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBzdHlsZT0iY29sb3I6IzRG ODFCRCI+UmVhZGluZyB0aGUgcmVsZXZhbnQgc2VjdGlvbnMgb2YgNDQ3NGJpcyByZW1pbmRzIG1l IHRoYXQgYW5vbnltb3VzIFNJUCBVUklzIHNob3VsZCBwcm9iYWJseSBub3QgYmUgaW5jbHVkZWQg aW4gYW55IFVSSS1zcGVjaWZpYyBjYWxsIGhhbmRsaW5nLiBJ4oCZdmUgYWRkZWQgYSBzZW50ZW5j ZSBpZGVudGlmeWluZyB0aGUgaXNzdWUsIHdpdGhvdXQgYW55IG5vcm1hdGl2ZQ0KIHN0YXRlbWVu dHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4g c3R5bGU9ImNvbG9yOiM0RjgxQkQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5BbmQgYSBjb3VwbGUg b2YgZWRpdG9yaWFsczo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5DbGF1c2UgNS4xIHNheXMgJnF1b3Q7IFRo aXMgZG9jdW1lbnQgcmVnaXN0ZXIgYSBuZXcgU0lQIHJlc3BvbnNlIGNvZGUuJnF1b3Q7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+Q2xhdXNlIDYgY29udGFpbnMgdGhlIHdvcmQgJnF1b3Q7cmVzZXJ2aWJsZSZx dW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gc3R5bGU9ImNvbG9yOiM0RjgxQkQiPkJvdGggZml4ZWQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPj0gPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_CY1PR09MB06340ECD968A14BD7B94D482EA6E0CY1PR09MB0634namp_-- From nobody Tue Jan 3 13:47:05 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5879D12978C for ; Tue, 3 Jan 2017 13:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GuQZ6sFsU-79 for ; Tue, 3 Jan 2017 13:46:58 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40C121297A5 for ; Tue, 3 Jan 2017 13:46:23 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03Li6hH005622; Tue, 3 Jan 2017 21:46:22 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p5u21yjb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 21:46:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WntXOD51MjISDjprpOjwFgCgQby1bG7sBfkQU/1DyEg=; b=d2kZsIM9YR4wFScc/PC5aUUqG2qPPH7xepuF7vsw5xTjUi+54Ssp0igpkVSaJEESdg4wg6WhpZtfo0Gz0sELVarFejod6aeidd+OfeSueX1qU0Wye4GHcTzGJStvG+OyWc6Ptbaltbqefh96zUT8byaBQqfaruoBVUKwPjMXSOc= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 21:46:20 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 21:46:20 +0000 From: Henning Schulzrinne To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 Thread-Index: AQHSW9J2lGbrqplf3EWoUnRl4wh8oqEUSY6AgBMUQNA= Date: Tue, 3 Jan 2017 21:46:19 +0000 Message-ID: References: <87tw9xvuap.fsf@hobgoblin.ariadne.com> <16e6ecb4-64cd-b814-d3c9-8c1c5e7cbe94@comcast.net> In-Reply-To: <16e6ecb4-64cd-b814-d3c9-8c1c5e7cbe94@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 62520af1-5ef0-43cd-82fd-08d43421f436 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:vSMA9oU9bU0W7vSSd48Nu1K8MQwBRuGQTCUSTsJuptJXDqUyxPHN48WgM3eMPm0e285+oeV5kP21lmvfVJmFxGVhl7A0s8cEKUKUyZcYoOaK85VShXb4wnQwuHkQ1JD1Ge5vi0YWALgXC1mwBE6eCRAMTnSN01nbkk6d4VSeEqE//TYO7aJkEiaGQtC/OQaWhq6g/+blrKPEvYggRRFFLdRDlxyVetGqCKWvJ8LTosERvbTDWUYWPMmsOpf6kMXhBYHCcp9LoPSN/3ZIBcdfqwCOPKUVM3tLewHGDhZAA97gcHWGzPZruPM2VKfxo8ehIg+9sf0fLJw3oe3+rTlK10xY5YviK+2QlwgRxyBhWonyZ68UXorHth9uwH7jbT/VmhtO/u620D/EpZbyFMvFvd1U4L3ECg+ZO34pp5MuWV5fOqNdeURkSLoUINJU3N5ijy+MVvUxGXRSR6WfyjA50g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(199003)(377454003)(24454002)(13464003)(6506006)(2900100001)(107886002)(50986999)(229853002)(8666007)(54356999)(106356001)(6116002)(5001770100001)(102836003)(97736004)(33656002)(105586002)(101416001)(189998001)(3280700002)(99286003)(7696004)(38730400001)(5660300001)(77096006)(106116001)(8676002)(66066001)(122556002)(76176999)(86362001)(81166006)(7736002)(230783001)(9686002)(6436002)(74316002)(2950100002)(2906002)(3846002)(25786008)(3660700001)(8936002)(2501003)(55016002)(92566002)(305945005)(81156014)(68736007)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 21:46:19.8598 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 21:47:01 -0000 I have re-formulated the sentence in the manner suggested. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Thursday, December 22, 2016 1:24 PM To: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 On 12/21/16 4:36 PM, Dale R. Worley wrote: > The service provider delivering calls to > the user issuing the response may, for example, add the calling party > to a personal blacklist specific to the called party, or may use the > information as input when computing the likelihood that the calling > party is placing unwanted calls ("crowd sourcing"), might initiate a > traceback request, or could report the calling number to government > authorities. > > This list has 4 items: > > may, for example, add the calling party to a personal blacklist > specific to the called party, > > or may use the information as input when computing the likelihood > that the calling party is placing unwanted calls ("crowd > sourcing"), > > might initiate a traceback request, > > or could report the calling number to government authorities. > > There is a lack of parallelism in that clauses use "may", "might", and=20 > "could" to indicate possbility. There are two uses of "or". The=20 > first item contains commas, but the items are not separated by=20 > semicolons. Reformulating this by (1) consistently using MAY, (2)=20 > using one "or" before the last item, and (3) moving the "for example" > to before the list (thus escaping the rule regarding semicolons): > > The service provider delivering calls to the user issuing the > response, for example, MAY add the calling party to a personal > blacklist specific to the called party, MAY use the information as > input when computing the likelihood that the calling party is > placing unwanted calls ("crowd sourcing"), MAY initiate a traceback > request, or MAY report the calling number to government > authorities. IIUC these actions are not mutually exclusive. So I would: s/or MAY report/and MAY report/ Thanks, Paul =20 From nobody Tue Jan 3 14:13:22 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC81E129854 for ; Tue, 3 Jan 2017 14:13:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7fDoJFsMjKbM for ; Tue, 3 Jan 2017 14:13:17 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B320C129850 for ; Tue, 3 Jan 2017 14:13:17 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03M9DLq019530; Tue, 3 Jan 2017 22:13:14 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0051.outbound.protection.outlook.com [23.103.198.51]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p5u22017-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 22:13:14 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zQhLw35Y8Po+ba8ACSrTpmURJwdpISgDYxXh7qmcgNI=; b=E3JO4qa9w6abrR5jWyAG9fr5TVCtfW89hV6siRkYw/ddVR+MnbVMzwCfCXIKlM/GfBkqIlmqcwZPbzZav3TpenCoBMzviTeMJM8heLOvbs9wCtLu9PxqoWWTexIADH+jkMiACisSNB5UiQ7fuqxABHJSffjf+/KDtutNoReNx64= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 22:13:12 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 22:13:12 +0000 From: Henning Schulzrinne To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 Thread-Index: AQHSW9J2lGbrqplf3EWoUnRl4wh8oqEnX16Q Date: Tue, 3 Jan 2017 22:13:12 +0000 Message-ID: References: <87tw9xvuap.fsf@hobgoblin.ariadne.com> In-Reply-To: <87tw9xvuap.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: acb63f86-2830-46fe-3aee-08d43425b51b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:dVGZN3p5KEiKn7Pezy+zmYK/gteoaehX4Nk+q/kzKsNCz8yIwUWZ+YJWqwN5Rzb0SvnmOLF31BwLYiUvAUaOa3FBkDUxWebtXEc5Ax7f2rSqn2fSeGN9cfC288iGCNlUbZD6oChdTdVONu/zIkU5DKzSZanZf5HKpdCPn0CF4IxEkc5QMPgYOyL2a2xfCkQnqUjRK9G3e7PjNRIVUhz8ZPfQ5ZQ5IHtoYs500i1dd3YI9qaq5zxZmdN+uEYEZQ+MY7eBGTLIIIoWqKyGbCV5R24BMedu3f7044Hb1BBIvEjLAQqftY1Vxc/E3jNrDZ7xas6OZ5DIKf85A9CBCivLUhKyY8grS2KFjRPwJZDXVloiej5NfRDsKvcbHPi3dpOu4xBpKtJySBs5PVKfQaPykyuAThXBOlFkpUav7V8WAFEY8SHMyFr0Vmq6hYEQlp+vxLAROuOHiI6L+cPInSDGhA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506)(10436049006162)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(377454003)(189002)(13464003)(6116002)(230783001)(229853002)(6436002)(3846002)(9686002)(50986999)(97736004)(6506006)(5001770100001)(107886002)(2906002)(5660300001)(66066001)(25786008)(2900100001)(106356001)(2501003)(76176999)(54356999)(101416001)(8936002)(122556002)(68736007)(3660700001)(2950100002)(74316002)(81166006)(105586002)(7736002)(55016002)(92566002)(575784001)(7696004)(8676002)(33656002)(305945005)(3280700002)(77096006)(99286003)(102836003)(38730400001)(86362001)(81156014)(189998001)(106116001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 22:13:12.0435 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_19:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:13:20 -0000 I have modified the wording as suggested. (Introduction has become moot due= to earlier change suggestions.)=20 For the "Security Considerations" comment, I reformulated to clarify that t= his is the party that is being protected by the blacklist. I don't think we= 'd necessarily want to inform the caller, although they may also get the 66= 6 response. There are exceptions - I can imagine that some automated, legit= imate robocalling operation could report statistics to the entity placing t= he calls, just like mass email senders presumably inform the human sender o= f spam reports ("5% of your messages were not delivered since they were rej= ected as spam"). But that seems beyond the scope of what the draft needs to= discuss. Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Wednesday, December 21, 2016 4:37 PM To: sipcore@ietf.org Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-00 All of these comments are editorial. 1. Introduction The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. s/a automata/an automaton/ 4. Behavior of SIP Entities The response code MAY also be used in Reason header fields [RFC3326], typically when the UAS issues a BYE request terminating an incoming call. This doesn't fully explain the intended behaviors. Better would be a descr= iption like: The response code 666 MAY be used in a failure response for an INVITE, MESSAGE, or other request to indicate that the offered communication is unwanted. The response code MAY also be used as the value of the "cause" parameter of a "SIP" reason-value in a "Reason" header field [RFC3326] in a BYE request terminating an incoming call that is unwanted. -- The same user interface action might also trigger addition of the number to a local, on-device blacklist or graylist, e.g., causing such calls to be flagged or alert with a different ring tone. This construction parallels "to be flagged" with "alert with a different ri= ng tone". Probably s/alert/alerted/ so that the parallelism is "to be (fla= gged | alerted with a different ring tone)". -- We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that it supports this particular response code. Except that the registrar doesn't support the response code, really. It's the proxy that does lookups in the location service that the registrar= maintains. So perhaps: We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that the corresponding proxy supports this particular response code. 6. Security Considerations Thus, any additions to a personal list of blocked numbers should be observable by the subscriber, e.g., on a web page or by regular email notification, and reservible. s/reservible/reversible/ The meaning of "the subscriber" is unclear. Is it "the recipient" or "the = caller"? Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DhWTNNu7TWkMZ4Qm1eQInwGVBt2OPXV9iF2iJm24XiB= M&s=3DZbB3Jap_Wj3g42vgW5IzVwq9VSHfdQy7R975GD3bnYU&e=3D=20 From nobody Tue Jan 3 14:16:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB491297B8 for ; Tue, 3 Jan 2017 14:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-DJftgBJs8t for ; Tue, 3 Jan 2017 14:16:53 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B768F1294A6 for ; Tue, 3 Jan 2017 14:16:53 -0800 (PST) Received: from pps.filterd (m0102173.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v03MEV0u015317; Tue, 3 Jan 2017 22:16:49 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0020.outbound.protection.outlook.com [23.103.198.20]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p5fsa0b4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 22:16:49 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qaou2vYfK2kJPb89Sbk5nLHpycLmHKDLRct5NF/5QmY=; b=avrUDZiwfyFguQ9fXM2drVzq9/gAEHnPo4AOqP691DA95yOEndbvOnuFsExUJQs4W4Ay24VHSRe/CoEyn0kJF2wcuHjO1zoPB0jNZy46rUm2xuSz06kPTFjKoXkFe7UsCFWmASBApvOOyVleP1G4k7Q0BcQ3FeEPOdFjw9Q8F5U= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 3 Jan 2017 22:16:47 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 3 Jan 2017 22:16:47 +0000 From: Henning Schulzrinne To: "DOLLY, MARTIN C" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Thread-Index: AQHSVX1sWRRKPiOkHUi6mpUAv+5fGqEP0kPDgAAExDGAF5sx0A== Date: Tue, 3 Jan 2017 22:16:47 +0000 Message-ID: References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com>, <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: a3527930-0fde-45cf-a375-08d43426359d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:d6dhL7WeA1MuTcIWpYTtOrCSxBefyklAhRM5UHSMedcBy7jW91hmx4ikxuCtAe6oCWNKtEtU8bI7FwgzYZqcW6PenBM3ZblU7jJwuFF9iOkJXwEJoVaOKdcVhGDh/UfdDlZtsRAe3DcbBdvaETMPLSJRsvPCv4RAOYVRaXFUmGLdHzeTlLorx3U70KtN5a0TAj4hCTU9F2nQ97SeNFe7PLJxisNF/GjjdCDt+Nh7MQBdkimkMIwfl/EfT42KZujl1PmZHt+gCfsnbtK04cOqGBVlgTPglMJImZX4olIHPBkn0vCXfWtnlJqo9K/EpN5lbVzrNt47TH2sMBD0b8PFGzqkRLqZuSlf5sfL6ZeP2tcEG75qvawF2A47QAiPMKOC9W5xRr+VYL6Gqji4A/dW5VoEtr70ULYTX8SyMhji4pJUDLhjw7zEpCPMgwHsf8w6hoPmdSZUkgfnngLTGBI0rA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(95541549313216)(10436049006162)(97927398514766)(788757137089)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01762B0D64 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(252514010)(24454002)(189002)(199003)(377424004)(377454003)(92566002)(606005)(55016002)(54906002)(7696004)(8676002)(7736002)(33656002)(575784001)(81166006)(7906003)(105586002)(19609705001)(110136003)(81156014)(38730400001)(86362001)(345774005)(106116001)(93886004)(189998001)(3280700002)(77096006)(102836003)(99286003)(2906002)(5660300001)(9686002)(6436002)(3846002)(230783001)(6116002)(229853002)(97736004)(6506006)(50986999)(14971765001)(3660700001)(74316002)(4001150100001)(6916009)(2950100002)(106356001)(4326007)(66066001)(2900100001)(25786008)(101416001)(54356999)(8936002)(790700001)(68736007)(122556002)(325944008)(76176999)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E4A1BBB3B6082CB89E2EEA6E0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jan 2017 22:16:47.7076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_19:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:16:56 -0000 --_000_CY1PR09MB0634E4A1BBB3B6082CB89E2EEA6E0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The automaton has been dropped and only human agency is implied. Not sure w= hat happens when the grand child of Alexa or Siri answers phone calls - see= http://motherboard.vice.com/read/ai-professor-proposes-turing-red-flag-law= for one option... From: DOLLY, MARTIN C [mailto:md3135@att.com] Sent: Monday, December 19, 2016 4:44 PM To: Henning Schulzrinne Cc: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t Greetings Small issue with Paul's comments. The user needs to make a "clear" decision on 666 being sent. So the user pr= essing a button is clear, whether pre/post answer, but an application scena= rio is not Need to fully understand the consequences of initiating trace back and a fr= aud report Regards Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne > wrote: Thank you for the comments. -01 will include the text suggestions you made. I would like to "ship" -01 before the holidays, so please wrap up your holi= day comment gifts and express-mail them so that only robocallers will find = coal in their stockings. Henning ________________________________ From: sipcore > o= n behalf of Paul Kyzivat > Sent: Tuesday, December 13, 2016 3:13:43 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t I reviewed this new version. I have a couple of suggestions for small wording changes: * Section 1: The wording of the following: ... The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. is odd. AFAIK, the "called party" here is a person who interacts with the called UA to indicate that the call is unwanted. The called party doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA, acting as an automata, may generate the response without a stimulus from the called party. I suggest the following to replace the above: ... The called user agent (UAS), based on input from the called party or internal logic, uses this code to indicate that this call and future calls from the same caller are unwanted. * Section 2: This section has some text having a similar issue: None of the existing 4xx, 5xx or 6xx response codes allow the called party to convey that they not only reject this call, e.g., using 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), 603 (Decline) or 606 (Not Acceptable), but that the caller is unwanted. I suggest: None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party. Otherwise I like it. Thanks, Paul On 12/12/16 4:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core of the = IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-00.txt > Pages : 6 > Date : 2016-12-12 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. The > terminating SIP entity may use this information to adjust future call > handling behavior for this called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h0omCe0= jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_= CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8JTEvWKRNFsrY_6wj__= iKqw8lQ&e=3D > > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0omCe0j= AUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44GaF1yEWLsRiOymrdGvqm= N07_P8&e=3D > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t-2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8l= DU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D= qnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd= 0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D > _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0t= M&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_CY1PR09MB0634E4A1BBB3B6082CB89E2EEA6E0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The automaton has been dropped and on= ly human agency is implied. Not sure what happens when the grand child of A= lexa or Siri answers phone calls – see http://motherboard.vice.com/read/ai-professor-proposes-turing-red-flag-law<= /a> for one option...

 

From: DOLLY, MARTIN C [mailto:md3135= @att.com]
Sent: Monday, December 19, 2016 4:44 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Cc: Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt

 

Greetings 

 

Small issue with Paul's comments. 

 

The user needs to make a "clear" decision = on 666 being sent. So the user pressing a button is clear, whether pre/post= answer, but an application scenario is not

 

Need to fully understand the consequences of initiat= ing trace back and a fraud report

 


On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

T= hank you for the comments. -01 will include the text suggestions you made.<= o:p>

<= o:p> 

I= would like to "ship" -01 before the holidays, so please&nbs= p;wrap up your holiday comment gifts and express-mail them so that only rob= ocallers will find coal in their stockings.

<= o:p> 

H= enning

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of Paul Kyzivat <pky= zivat@alum.mit.edu>
Sent: Tuesday, December 13, 2016 3:13:43 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt

 

I reviewed this new= version. I have a couple of suggestions for small
wording changes:

* Section 1:

The wording of the following:

    ... The called party or a automata acting on her behalf = uses this
    to indicate that future calls from the same caller are a= lso unwanted.

is odd. AFAIK, the "called party" here is a person who interacts = with
the called UA to indicate that the call is unwanted. The called party
doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA,
acting as an automata, may generate the response without a stimulus from the called party.

I suggest the following to replace the above:

    ... The called user agent (UAS), based on input from the= called
    party or internal logic, uses this code to indicate that= this call
    and future calls from the same caller are unwanted.

* Section 2:

This section has some text having a similar issue:

    None of the existing 4xx, 5xx or 6xx response codes allo= w the called
    party to convey that they not only reject this call, e.g= ., using 480
    (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Ev= erywhere),
    603 (Decline) or 606 (Not Acceptable), but that the call= er is
    unwanted.

I suggest:

    None of the existing 4xx, 5xx or 6xx response codes sign= ify that
    calls from this caller are unwanted by the called party.=

Otherwise I like it.

        Thanks,
        Paul

On 12/12/16 4:50 PM, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Session Initiation Protocol Core of t= he IETF.
>
>         Title   = ;        : A SIP Response Code for Unwan= ted Calls
>         Author  &nbs= p;       : Henning Schulzrinne
>        Filename   &n= bsp;    : draft-ietf-sipcore-status-unwanted-00.txt
>        Pages    = ;       : 6
>        Date    =         : 2016-12-12
>
> Abstract:
>    This document defines the 666 (Unwanted) SIP respons= e code, allowing
>    called parties to indicate that the call was unwante= d.  The
>    terminating SIP entity may use this information to a= djust future call
>    handling behavior for this called party or more broa= dly.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h= 0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= ;m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8= JTEvWKRNFsrY_6wj__iKqw8lQ&e=3D
>
> There's also a htmlized version available at:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0= omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44Ga= F1yEWLsRiOymrdGvqmN07_P8&e=3D
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1= RlHtBd0tM&s=3DqnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-= Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e= =3D
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25E= OFNeSGgejY&e=3D

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--_000_CY1PR09MB0634E4A1BBB3B6082CB89E2EEA6E0CY1PR09MB0634namp_-- From nobody Tue Jan 3 14:20:25 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC0E129A5B for ; Tue, 3 Jan 2017 14:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.019 X-Spam-Level: X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pDvEHv6Kv_iW for ; Tue, 3 Jan 2017 14:20:22 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B9E1296C5 for ; Tue, 3 Jan 2017 14:20:22 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 650C360CD8; Tue, 3 Jan 2017 23:20:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 4207FC0052; Tue, 3 Jan 2017 23:20:20 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 23:20:19 +0100 From: To: Robert Sparks , Ben Campbell Thread-Topic: [Editorial Errata Reported] RFC3515 (4898) Thread-Index: AQHSZenXQao3RUyO60SWEGR4I7ygGKEm+DaAgAAHWACAAAKRgIAAJB6AgAACHgCAACkz0A== Date: Tue, 3 Jan 2017 22:20:19 +0000 Message-ID: <30319_1483482020_586C23A4_30319_433_1_8B970F90C584EA4E97D5BAAC9172DBB81C88D4C5@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20170103175011.D8B0FB81248@rfc-editor.org> <053a17a2-ea75-eb25-b634-434fb5de9881@nostrum.com> <14ee5bbc-34b7-45e3-b06a-b278790c1682@nostrum.com> <6757A890-7A1A-4CD4-8C46-7C865D2B82E9@nostrum.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "drage@alcatel-lucent.com" , "dean.willis@softarmor.com" , SIPCORE , "alissa@cooperw.in" , "aamelnikov@fastmail.fm" Subject: Re: [sipcore] [Editorial Errata Reported] RFC3515 (4898) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:20:24 -0000 So sentence: >The "=3D" between the header name (hname) and the value (hvalue) in the he= aders component of the URI does not have to be in the percent-coded format = as part of the ABNF of the headers component defined in RFC3261: should be modified to: The "=3D" between the header name (hname) and the value (hvalue) in the hea= ders component of the URI must not be in the percent-coded format as part o= f the ABNF of the headers component defined in RFC3261: ok? BR, Marianne -----Message d'origine----- De=A0: Robert Sparks [mailto:rjsparks@nostrum.com]=20 Envoy=E9=A0: mardi 3 janvier 2017 21:47 =C0=A0: Ben Campbell Cc=A0: SIPCORE; alissa@cooperw.in; aamelnikov@fastmail.fm; dean.willis@soft= armor.com; drage@alcatel-lucent.com; MOHALI Marianne IMT/OLN Objet=A0: Re: [Editorial Errata Reported] RFC3515 (4898) That's how I read it, yes. On 1/3/17 2:39 PM, Ben Campbell wrote: > Do I read correctly that while Marianne's notes says the "=3D" "does not= =20 > have" to be escaped, the reality is that is "not allowed" to be=20 > escaped? If so, the note probably needs an adjustment. > > On 3 Jan 2017, at 12:29, Robert Sparks wrote: > >> Eh - nevermind - Marianne's point is that escaping that particulear=20 >> "=3D" _isn't_ allowed by the ABNF (shown by what she quotes). >> >> So, this is an bug in an example, and the error doesn't affect the=20 >> specification. This one should go into 'hold for document update'. >> >> RjS >> >> On 1/3/17 12:20 PM, Robert Sparks wrote: >>> Marianne - why do you think this is important? >>> >>> I'll go do the work to verify that your read that the particular '=3D'= =20 >>> you point to is not necessary to encode, but even it that's correct,=20 >>> it's still allowed to encode it. I don't see how making the change=20 >>> you propose with the errata will help anyone? >>> >>> RjS >>> >>> >>> >>> On 1/3/17 11:54 AM, Ben Campbell wrote: >>>> Does anyone have thoughts on this errata report? >>>> >>>> Thanks! >>>> >>>> Ben. >>>> >>>> On 3 Jan 2017, at 11:50, RFC Errata System wrote: >>>> >>>>> The following errata report has been submitted for RFC3515, "The=20 >>>>> Session Initiation Protocol (SIP) Refer Method". >>>>> >>>>> -------------------------------------- >>>>> You may review the report below and at: >>>>> http://www.rfc-editor.org/errata_search.php?rfc=3D3515&eid=3D4898 >>>>> >>>>> -------------------------------------- >>>>> Type: Editorial >>>>> Reported by: Marianne MOHALI >>>>> >>>>> Section: 2.1 >>>>> >>>>> Original Text >>>>> ------------- >>>>> Refer-To: >>>> biloxi.example.net&Call-ID%3D55432%40alicepc.atlanta.example.com> >>>>> >>>>> Corrected Text >>>>> -------------- >>>>> Refer-To: >>>> biloxi.example.net&Call-ID=3D55432%40alicepc.atlanta.example.com> >>>>> >>>>> Notes >>>>> ----- >>>>> The "=3D" between the header name (hname) and the value (hvalue) in= =20 >>>>> the headers component of the URI does not have to be in the=20 >>>>> percent-coded format as part of the ABNF of the headers component=20 >>>>> defined in RFC3261: >>>>> sip:user:password@host:port;uri-parameters?headers >>>>> headers =3D "?" header *( "&" header ) >>>>> header =3D hname "=3D" hvalue >>>>> hname =3D 1*( hnv-unreserved / unreserved / escaped ) >>>>> hvalue =3D *( hnv-unreserved / unreserved / escaped ) >>>>> hnv-unreserved =3D "[" / "]" / "/" / "?" / ":" / "+" / "$" >>>>> >>>>> Instructions: >>>>> ------------- >>>>> This erratum is currently posted as "Reported". If necessary,=20 >>>>> please use "Reply All" to discuss whether it should be verified or=20 >>>>> rejected. When a decision is reached, the verifying party can log=20 >>>>> in to change the status and edit the report, if necessary. >>>>> >>>>> -------------------------------------- >>>>> RFC3515 (draft-ietf-sip-refer-07) >>>>> -------------------------------------- >>>>> Title : The Session Initiation Protocol (SIP) Refer=20 >>>>> Method >>>>> Publication Date : April 2003 >>>>> Author(s) : R. Sparks >>>>> Category : PROPOSED STANDARD >>>>> Source : Session Initiation Protocol >>>>> Area : Real-time Applications and Infrastructure >>>>> Stream : IETF >>>>> Verifying Party : IESG >>> ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue Jan 3 14:27:28 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA864129A62 for ; Tue, 3 Jan 2017 14:27:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.612 X-Spam-Level: X-Spam-Status: No, score=-0.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_IoK6RIN39S for ; Tue, 3 Jan 2017 14:27:23 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C54E129A5B for ; Tue, 3 Jan 2017 14:27:23 -0800 (PST) Received: from pps.filterd (m0049295.ppops.net [127.0.0.1]) by m0049295.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v03MOeP4003854; Tue, 3 Jan 2017 17:27:05 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049295.ppops.net-00191d01. with ESMTP id 27rk33tsre-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jan 2017 17:27:04 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v03MR3MD030489; Tue, 3 Jan 2017 17:27:03 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v03MQxZ9030430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 3 Jan 2017 17:27:01 -0500 Received: from MISOUT7MSGHUBAF.ITServices.sbc.com (MISOUT7MSGHUBAF.itservices.sbc.com [130.9.129.150]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Tue, 3 Jan 2017 22:26:47 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAF.ITServices.sbc.com ([130.9.129.150]) with mapi id 14.03.0319.002; Tue, 3 Jan 2017 17:26:47 -0500 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Thread-Index: AQHSVX1sWRRKPiOkHUi6mpUAv+5fGqEP0kPDgAAExDGAF5sx0IAAA73y Date: Tue, 3 Jan 2017 22:26:46 +0000 Message-ID: References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com>, <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CCEB1DF954834503B9D5AD2A5B423A74attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-03_19:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701030338 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:27:25 -0000 --_000_CCEB1DF954834503B9D5AD2A5B423A74attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Agreed, there is going to be a learning period with education of the consum= er and carriers adjusting actions taken Regards Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Jan 3, 2017, at 5:16 PM, Henning Schulzrinne > wrote: The automaton has been dropped and only human agency is implied. Not sure w= hat happens when the grand child of Alexa or Siri answers phone calls =96 s= ee http://motherboard.vice.com/read/ai-professor-proposes-turing-red-flag-l= aw for one option... From: DOLLY, MARTIN C [mailto:md3135@att.com] Sent: Monday, December 19, 2016 4:44 PM To: Henning Schulzrinne > Cc: Paul Kyzivat >; sip= core@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t Greetings Small issue with Paul's comments. The user needs to make a "clear" decision on 666 being sent. So the user pr= essing a button is clear, whether pre/post answer, but an application scena= rio is not Need to fully understand the consequences of initiating trace back and a fr= aud report Regards Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne > wrote: Thank you for the comments. -01 will include the text suggestions you made. I would like to "ship" -01 before the holidays, so please wrap up your holi= day comment gifts and express-mail them so that only robocallers will find = coal in their stockings. Henning ________________________________ From: sipcore > o= n behalf of Paul Kyzivat > Sent: Tuesday, December 13, 2016 3:13:43 PM To: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t I reviewed this new version. I have a couple of suggestions for small wording changes: * Section 1: The wording of the following: ... The called party or a automata acting on her behalf uses this to indicate that future calls from the same caller are also unwanted. is odd. AFAIK, the "called party" here is a person who interacts with the called UA to indicate that the call is unwanted. The called party doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA, acting as an automata, may generate the response without a stimulus from the called party. I suggest the following to replace the above: ... The called user agent (UAS), based on input from the called party or internal logic, uses this code to indicate that this call and future calls from the same caller are unwanted. * Section 2: This section has some text having a similar issue: None of the existing 4xx, 5xx or 6xx response codes allow the called party to convey that they not only reject this call, e.g., using 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Everywhere), 603 (Decline) or 606 (Not Acceptable), but that the caller is unwanted. I suggest: None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party. Otherwise I like it. Thanks, Paul On 12/12/16 4:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core of the = IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-00.txt > Pages : 6 > Date : 2016-12-12 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. The > terminating SIP entity may use this information to adjust future call > handling behavior for this called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.o= rg_doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h0omCe0= jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_= CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8JTEvWKRNFsrY_6wj__= iKqw8lQ&e=3D > > There's also a htmlized version available at: > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_htm= l_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0omCe0j= AUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44GaF1yEWLsRiOymrdGvqm= N07_P8&e=3D > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_interne= t-2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8l= DU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D= qnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd= 0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D > _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0t= M&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_CCEB1DF954834503B9D5AD2A5B423A74attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Agreed, there is going to be a learning period with education of the c= onsumer and carriers adjusting actions taken

Regards

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Jan 3, 2017, at 5:16 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

The automaton has been dropped and on= ly human agency is implied. Not sure what happens when the grand child of A= lexa or Siri answers phone calls =96 see http://motherboard.vice.com/read/ai-professor-proposes-turing-red-flag-law<= /a> for one option...

 

From: DOLLY, MARTIN C [mailto:md3135@att.com]
Sent: Monday, December 19, 2016 4:44 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Cc: Paul Kyzivat <pkyziv= at@alum.mit.edu>; sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt

 

Greetings 

 

Small issue with Paul's comments. 

 

The user needs to make a "clear" decision = on 666 being sent. So the user pressing a button is clear, whether pre/post= answer, but an application scenario is not

 

Need to fully understand the consequences of initiat= ing trace back and a fraud report

 

Regards

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: += 1.609.903.3360

Email: md3= 135@att.com

 


On Dec 19, 2016, at 4:29 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

T= hank you for the comments. -01 will include the text suggestions you made.<= o:p>

<= o:p> 

I= would like to "ship" -01 before the holidays, so please&nbs= p;wrap up your holiday comment gifts and express-mail them so that only rob= ocallers will find coal in their stockings.

<= o:p> 

H= enning

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of Paul Kyzivat <pky= zivat@alum.mit.edu>
Sent: Tuesday, December 13, 2016 3:13:43 PM
To: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt

 

I reviewed this new= version. I have a couple of suggestions for small
wording changes:

* Section 1:

The wording of the following:

    ... The called party or a automata acting on her behalf = uses this
    to indicate that future calls from the same caller are a= lso unwanted.

is odd. AFAIK, the "called party" here is a person who interacts = with
the called UA to indicate that the call is unwanted. The called party
doesn't use the 666 response code - the called UA uses it, based on some (unspecified) stimulus provided by the called party. Or the called UA,
acting as an automata, may generate the response without a stimulus from the called party.

I suggest the following to replace the above:

    ... The called user agent (UAS), based on input from the= called
    party or internal logic, uses this code to indicate that= this call
    and future calls from the same caller are unwanted.

* Section 2:

This section has some text having a similar issue:

    None of the existing 4xx, 5xx or 6xx response codes allo= w the called
    party to convey that they not only reject this call, e.g= ., using 480
    (Temporarily Unavailable), 486 (Busy Here), 600 (Busy Ev= erywhere),
    603 (Decline) or 606 (Not Acceptable), but that the call= er is
    unwanted.

I suggest:

    None of the existing 4xx, 5xx or 6xx response codes sign= ify that
    calls from this caller are unwanted by the called party.=

Otherwise I like it.

        Thanks,
        Paul

On 12/12/16 4:50 PM, internet-d= rafts@ietf.org wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
> This draft is a work item of the Session Initiation Protocol Core of t= he IETF.
>
>         Title   = ;        : A SIP Response Code for Unwan= ted Calls
>         Author  &nbs= p;       : Henning Schulzrinne
>        Filename   &n= bsp;    : draft-ietf-sipcore-status-unwanted-00.txt
>        Pages    = ;       : 6
>        Date    =         : 2016-12-12
>
> Abstract:
>    This document defines the 666 (Unwanted) SIP respons= e code, allowing
>    called parties to indicate that the call was unwante= d.  The
>    terminating SIP entity may use this information to a= djust future call
>    handling behavior for this called party or more broa= dly.
>
>
> The IETF datatracker status page for this draft is:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.org= _doc_draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted_&d=3DDgICAg&c=3Dy0h= 0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= ;m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0RGC_RjQLE0D4e1MF8= JTEvWKRNFsrY_6wj__iKqw8lQ&e=3D
>
> There's also a htmlized version available at:
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html_= draft-2Dietf-2Dsipcore-2Dstatus-2Dunwanted-2D00&d=3DDgICAg&c=3Dy0h0= omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&= m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3Dv2Iwj1kwSfluBGM44Ga= F1yEWLsRiOymrdGvqmN07_P8&e=3D
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> https://urldefense.proofpoint.com/v2/url?u=3Dftp-3A__ftp.ietf.org_internet-= 2Ddrafts_&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-Z8WkEZo1= RlHtBd0tM&s=3DqnHOAe3aYl8FZOnL0WUWcgF3wE1RYztyGZhov8k3nLY&e=3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_CJxlY2iaBLZoJX4c-= Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25EOFNeSGgejY&e= =3D
>

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dra_qnaAY_C= JxlY2iaBLZoJX4c-Z8WkEZo1RlHtBd0tM&s=3D0LtCsPJ8E9s1apz4RoWgc9Id1UpeWe25E= OFNeSGgejY&e=3D

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--_000_CCEB1DF954834503B9D5AD2A5B423A74attcom_-- From nobody Tue Jan 3 14:52:22 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 241C412988C for ; Tue, 3 Jan 2017 14:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.002 X-Spam-Level: X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlXHpqpDxOy5 for ; Tue, 3 Jan 2017 14:52:19 -0800 (PST) Received: from nostrum.com (raven.nostrum.com [69.55.229.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C647512988A for ; Tue, 3 Jan 2017 14:52:19 -0800 (PST) Received: from mutabilis.routerlogin.net (mobile-166-173-058-100.mycingular.net [166.173.58.100]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v03MqHOL022432 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 3 Jan 2017 16:52:18 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-100.mycingular.net [166.173.58.100] claimed to be mutabilis.routerlogin.net To: "'SIPCORE'" References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> From: "A. Jean Mahoney" Message-ID: <9e9fb1bb-c0fb-3634-3c04-f21319e0e029@nostrum.com> Date: Tue, 3 Jan 2017 16:52:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jan 2017 22:52:22 -0000 I'm good with all the discussed changes and have just a nit in the "IANA Considerations" section: s/method and response-code sub-registry/"Response Codes" sub-registry Thanks! Jean, as an individual On 1/3/17 10:48 AM, Adam Roach wrote: > This is a reminder that the WGLC for this document ends today. If you > have not had time to read and comment on it, please do so in the next > few hours. The document is fairly short, and should take very little > time to review. > > Even comments like "I have read the document and believe it is ready for > publication" would be useful. > > /a > > On 12/12/16 15:05, Adam Roach wrote: >> [as chair] >> >> I've seen significant support for adoption of >> draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and no >> objections. Our revised charter that includes scope for this kind of >> item has been approved. The document is now adopted by SIPCORE. I have >> asked the author to submit subsequent versions of the document as >> draft-ietf-sipcore-status-unwanted. >> >> Given the relatively uncomplicated mechanism being described and the >> requests for expedited processing, we will be starting our working >> group last call on the document today. In recognition that the >> upcoming winter holidays will take some portion of many participants' >> attention, and that many people will observe a New Year's Holiday on >> January 2nd, we will run this last call for three weeks, ending on >> January 3rd. Please review the document and provide comments on before >> that date. >> >> /a >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 3 18:59:52 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59349129B33 for ; Tue, 3 Jan 2017 18:59:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jd-pi_8R-L6u for ; Tue, 3 Jan 2017 18:59:50 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74AF5129526 for ; Tue, 3 Jan 2017 18:59:50 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with SMTP id Obn6cdQOgj8tqObnpcoyX7; Wed, 04 Jan 2017 02:59:49 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-19v.sys.comcast.net with SMTP id ObnocLQdvJrREObnocGIuo; Wed, 04 Jan 2017 02:59:49 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v042xlAU012915; Tue, 3 Jan 2017 21:59:47 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v042xl3D012908; Tue, 3 Jan 2017 21:59:47 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Andy Hutton In-Reply-To: (andyhutton.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 03 Jan 2017 21:59:47 -0500 Message-ID: <8737gzjzrw.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOY4sekOvkHmxpJHm9seo68Rtng6IJ/mYtnrCtjg1feW1f+P6gyDH6i1I+xznHohQhloEW9Zg7CVQ5D7uWzDsI1Ostdq1hHlquUuzXyWb71VgS64YGC3 0iANjvHHMiGNxaqLHMAa+C+Refjc1a9cFpGN1QJkhEl+hCmi413QQnmzpV6bvWFy6oxlVA0zuRoYgU1L92TWr5X3U27Blts1pyQ= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 02:59:51 -0000 Andy Hutton writes: > The abstract states "The terminating SIP entity may use this > information....". > > But this is not I believe referring to the actual terminating SIP entity > which is the called users device but is referring to some preceding SIP > entity probably the service provider. I suspect that a better wording would be "The terminating SIP service ...". "Asveren, Tolga" writes: > Is there a particular reason why 666 shouldn't be applicable to > MESSAGE method? It should be applicable to any out-of-dialog request (whether or not it is dialog-forming). I can imagine a 666 response to SUBSCRIBE as well. Dale From nobody Tue Jan 3 20:52:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A81BC129517 for ; Tue, 3 Jan 2017 20:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1lnyMjCifWc for ; Tue, 3 Jan 2017 20:51:59 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A764127077 for ; Tue, 3 Jan 2017 20:51:58 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-08v.sys.comcast.net with SMTP id OdXSckoKAdT7bOdYMc4f62; Wed, 04 Jan 2017 04:51:58 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-20v.sys.comcast.net with SMTP id OdYLcVnHAEwWaOdYLcy3Ig; Wed, 04 Jan 2017 04:51:58 +0000 To: Henning Schulzrinne , "DOLLY, MARTIN C" References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu> From: Paul Kyzivat Message-ID: <54c46adb-16a1-0159-65d1-233359bee392@alum.mit.edu> Date: Tue, 3 Jan 2017 23:51:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHvvxQO8xYZRUhtgPb8YIRzI5XAknITGX5Sc8PzEw/Ii/P1A2XWrAeIHHdM3Q117CILuh+yIZ0LULXbCDiumejQBMd33zPLAOndTPR+f0CjsiP1ejX+b SqLWbt3OvLW4Z0nIZwXiZJPWKEhFllRnDDnzcIFBMCEbSPq7RGZ/wbMvzJKUs/mgdtdGb4SEKg9939Mh6MCB1hx96HjwGBRcFPB/Z9uX70w54zo7OGaDlCJ8 5UxeKt0PGZB5HR3FhdwzZw== Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 04:51:59 -0000 On 1/3/17 5:16 PM, Henning Schulzrinne wrote: > *From:*DOLLY, MARTIN C [mailto:md3135@att.com] > *Sent:* Monday, December 19, 2016 4:44 PM > *To:* Henning Schulzrinne > *Cc:* Paul Kyzivat ; sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-status-unwanted-00.txt > > Small issue with Paul's comments. > > The user needs to make a "clear" decision on 666 being sent. So the user > pressing a button is clear, whether pre/post answer, but an application > scenario is not I expect we are in violent agreement here, but just in case... I agree the user needs to make an active decision to press the button (or whatever). And to do so thoughtfully the user must understand the implications of doing so. But most users will *not* know that pushing the button results in a 666 being sent. Rather they associate the button with the actions taken elsewhere as a result of the 666 being sent. Thanks, Paul From nobody Wed Jan 4 00:44:49 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC8D1294A4 for ; Wed, 4 Jan 2017 00:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1NzT3PFQTtnX for ; Wed, 4 Jan 2017 00:44:46 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1A9129444 for ; Wed, 4 Jan 2017 00:44:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=td0RE29G9ak+F+KcnRkylT23Mujb+w/x/W6zLFMVtLs=; b=qllvzyCKvua+xL4XKGGGNyWBOQlxOofH+4MO15AY6Dq/FOqtGBZhTM0yGuRmdXLb1NKP3HyT/VoJ2eZBM9v83Q6FmueeGtfczPlr2GOroAvyierpJKpIeQlYS2b3dKSgFhe+IhCVBWQQKaDnPNLTAd3orx5CPTlNV5TNlJBZfSU= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0015.outbound.protection.outlook.com [216.32.181.15]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-28-k8S2AlaJNsKWUjp5BkxJrg-1; Wed, 04 Jan 2017 03:44:43 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 08:44:39 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 08:44:39 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvkesfMOzoPkCxU0eOhKCbpKEnAADwgAA4sICAAMivYA== Date: Wed, 4 Jan 2017 08:44:38 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 3bf4db57-5118-4ee3-95b8-08d4347deb6e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:cOXJky7hQiEBXEZF2SqooMYRBeBRhXSubIrqL6/XgIJuiSfDS+K7wfkmLtzFzCawr6ROVHEbIb9qluTuwh8saWiS9DR9w+7d53c40W3RS+IOnr5CnHYDyU8XeBgTc8c7nI6E46T2XJpCL/NL2AsIwF/HrEcxXOUS86MF8gPe1rhbBRIu+BWt2KT/ronnAyP7DekzmDj9Oi5SaMm+I+032TJ57fizNIiqB8Nq+HbBIeGVIpqMq2hzUO/pp9CS1Z55tHroUy2v6L8e8UvatLeOWvV3lNWh6BkOgCWE1wNE80jOW9eiEgatCsbNR6KKAIhWL8lCsegJ8lzWEZf1GO/P6VQ6uIIU5HFPPJY1Z05QEfBJEeUha8XArPmN8YymoJgKfqIJqhl4m/zt/mun8jZZHw+gPrRXpCIOY0qGqrD+nXiFfrwlaPSjFjv3h9RJKLC93gYW6Y05cQiqU3iQORO5Rw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558021)(20161123564025)(20161123562025)(6072148)(6047074); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(12213003)(189002)(199003)(13464003)(377454003)(97736004)(2906002)(105586002)(68736007)(6436002)(101416001)(66066001)(93886004)(189998001)(55016002)(3660700001)(5001770100001)(102836003)(8936002)(6116002)(2900100001)(5660300001)(92566002)(54356999)(74316002)(3280700002)(230783001)(107886002)(99286003)(6506006)(25786008)(106116001)(50986999)(305945005)(76176999)(33656002)(122556002)(7736002)(81166006)(81156014)(8676002)(3846002)(7696004)(9686002)(86362001)(229853002)(106356001)(2950100002)(77096006)(38730400001)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 08:44:38.9189 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: k8S2AlaJNsKWUjp5BkxJrg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:44:48 -0000 Mea culpa (I was deceived by the draft name in the Subject line). Yes, the new version looks good. Thanks, Tolga > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Tuesday, January 03, 2017 3:45 PM > To: Asveren, Tolga ; Adam Roach > ; 'SIPCORE' > Subject: RE: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > unwanted >=20 > I believe > https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-00 > addresses this issue. (There's only one MAY, in connection with the Reaso= n > header.) If not, please point out what I missed... >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, > Tolga > Sent: Tuesday, January 03, 2017 12:27 PM > To: Adam Roach ; 'SIPCORE' > Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > unwanted >=20 > I read the document and have only a single doubt: >=20 > Would it be better to use "may" instead of "MAY" in 4. (except for the > sentence about Reason header)? This section is about non-SIP-protocol > specific behavior (except the Reason header usage), which is local and do= es > not need to be/is not standardized. Not using RFC2119 keywords seems > more appropriate IMHO -but it is not a big deal either way-. >=20 > Thanks, > Tolga >=20 From nobody Wed Jan 4 00:46:18 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF67129C43 for ; Wed, 4 Jan 2017 00:46:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXX5v0Sj6TFS for ; Wed, 4 Jan 2017 00:46:15 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B441294A4 for ; Wed, 4 Jan 2017 00:46:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HOgLn7FYoiRFfeMBq9iVPa+cE9QJzh0vM3J1naokx7E=; b=abe6iF03PQRapaA4p9gcajNsLwDrxN5KTnU/i7x3yA1MCAAzGHXBUwjMmQGuygyaY4kPWq6wiUvLwz+SdafFokIQVKDOBI8Vq7x+S2Wh+kSmR2aWxN8qf4c1rIbxq53+d2Nsvk2zB9xNuANu8l7HbkAIIQztSQ1MVJmKf3B9rgI= Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0120.outbound.protection.outlook.com [207.46.163.120]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-58-yo4l_4fIOLe0aDNBTJk94Q-1; Wed, 04 Jan 2017 03:46:13 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 08:46:09 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 08:46:09 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZeEvkesfMOzoPkCxU0eOhKCbpKEnAADwgAAi49CAABjzgIAAxcuw Date: Wed, 4 Jan 2017 08:46:09 +0000 Message-ID: References: <8d75574c-b98c-ebec-0502-06d232b2c432@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ec71db89-36ee-4a65-61b7-08d4347e212a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:tuYYpbSTWxwBbSw3vebTDOVi+ejB23PWKY5rW51iLDFIc8J6VzkGAkre43uKvuJrNqylXf4aGa5j/2rOkqad/kbEmqcLnlGBzNVOwlFXP5evAaxuV3IAUqsOA3GNLDgcQ7MDMI8yzKvPlvY6PwuyAgU1N+Vz43l66j2MdwnbK7mJDnS3H/zJ4XIbqNTSSq+e62OgUXBXpr6NMOs/8cJ2672gOq7m0trYekkpqqjlFEvOdh08PGFMcCrzXbX5TIzMao+lqfremQ691NFqXoq4xQaQWk123+2tnjwHWEZWJ8sBZobzA79heFHZmkPcU9MZcHywaCPg24UNbIVv6xlQ3993Xcg+94guKB7yCuqJX5cqTxbUEjbopqd2wxqDzKH66i/8dhbo3qWxPk0A4OEuSjMUJ0q/S6MiIbqVY2im2SfD6o8Dzx4p1pspvi+EO411nQPffLGqbavbVFzWvaILHQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(189002)(199003)(12213003)(13464003)(24454002)(7696004)(9686002)(102836003)(3900700001)(50986999)(76176999)(5001770100001)(25786008)(305945005)(106116001)(5660300001)(3660700001)(86362001)(575784001)(101416001)(2900100001)(74316002)(6436002)(81156014)(106356001)(105586002)(97736004)(2950100002)(2906002)(7736002)(189998001)(38730400001)(6506006)(77096006)(8936002)(107886002)(66066001)(81166006)(33656002)(8676002)(93886004)(6116002)(92566002)(55016002)(230783001)(54356999)(229853002)(3846002)(122556002)(99286003)(68736007)(3280700002)(26123001)(19627235001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 08:46:09.1710 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: yo4l_4fIOLe0aDNBTJk94Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 08:46:17 -0000 Agreed, the new version looks good to me. I also don't see the need to rest= rict use of "unwanted" to a specific method. People/Industry is usually mor= e creative than we may imagine and who knows for what other method types it= could be utilized. Thanks, Tolga > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Tuesday, January 03, 2017 3:56 PM > To: Asveren, Tolga ; Adam Roach > ; 'SIPCORE' > Subject: RE: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > unwanted >=20 > Tolga, >=20 > I believe it should indeed apply to MESSAGE as well. MESSAGE makes a > cameo appearance in the introduction ("typically INVITE or MESSAGE"). >=20 > Should there be an explicit restriction to methods? I checked the IANA > registration and the related RFCs of a few non-3261 response codes, and > they generally don't specify the methods they are used with. One reason > would be to avoid having to update all the documents defining status code= s if > SIPCORE adds another SIP method. >=20 > Henning >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, > Tolga > Sent: Tuesday, January 03, 2017 2:28 PM > To: Adam Roach ; 'SIPCORE' > Subject: Re: [sipcore] Reminder: WGLC: draft-schulzrinne-dispatch-status- > unwanted >=20 > One more question/comment: >=20 > Is there a particular reason why 666 shouldn't be applicable to MESSAGE > method? >=20 > Thanks, > Tolga >=20 > > -----Original Message----- > > From: Asveren, Tolga > > Sent: Tuesday, January 03, 2017 12:27 PM > > To: 'Adam Roach' ; 'SIPCORE' > > Subject: RE: [sipcore] Reminder: WGLC: > > draft-schulzrinne-dispatch-status- > > unwanted > > > > I read the document and have only a single doubt: > > > > Would it be better to use "may" instead of "MAY" in 4. (except for the > > sentence about Reason header)? This section is about non-SIP-protocol > > specific behavior (except the Reason header usage), which is local and > > does not need to be/is not standardized. Not using RFC2119 keywords > > seems more appropriate IMHO -but it is not a big deal either way-. > > > > Thanks, > > Tolga > > > > > -----Original Message----- > > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam > > > Roach > > > Sent: Tuesday, January 03, 2017 11:48 AM > > > To: 'SIPCORE' > > > Subject: [sipcore] Reminder: WGLC: > > > draft-schulzrinne-dispatch-status- > > > unwanted > > > > > > This is a reminder that the WGLC for this document ends today. If > > > you have not had time to read and comment on it, please do so in the > > > next few > > hours. > > > The document is fairly short, and should take very little time to rev= iew. > > > > > > Even comments like "I have read the document and believe it is ready > > > for publication" would be useful. > > > > > > /a > > > > > > On 12/12/16 15:05, Adam Roach wrote: > > > > [as chair] > > > > > > > > I've seen significant support for adoption of > > > > draft-schulzrinne-dispatch-status-unwanted as a SIPCORE item and > > > > no objections. Our revised charter that includes scope for this > > > > kind of item has been approved. The document is now adopted by > > > > SIPCORE. I have asked the author to submit subsequent versions of > > > > the document as draft-ietf-sipcore-status-unwanted. > > > > > > > > Given the relatively uncomplicated mechanism being described and > > > > the requests for expedited processing, we will be starting our > > > > working group last call on the document today. In recognition that > > > > the upcoming winter holidays will take some portion of many > participants' > > > > attention, and that many people will observe a New Year's Holiday > > > > on January 2nd, we will run this last call for three weeks, ending > > > > on January 3rd. Please review the document and provide comments on > > > before > > > > that date. > > > > > > > > /a > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_ma > > > > ilman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoD > kWM > > > > 5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D1TnbdxFZGrU6_AsNQJD_xJ6R > P5OKuGq > > > H2wITUbdg4Gs&s=3DPDIm8MQuwX-JVCng- > BEDirWcio4ELjzyIl0OmPl2rgU&e=3D >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps- > 3A__www.ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAU > Gr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D1 > TnbdxFZGrU6_AsNQJD_xJ6RP5OKuGqH2wITUbdg4Gs&s=3DPDIm8MQuwX- > JVCng-BEDirWcio4ELjzyIl0OmPl2rgU&e=3D From nobody Wed Jan 4 02:59:18 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEFB1294E1 for ; Wed, 4 Jan 2017 02:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW5GPi-w_Qe4 for ; Wed, 4 Jan 2017 02:59:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAFF01288B8 for ; Wed, 4 Jan 2017 02:59:15 -0800 (PST) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v04AtTE4001889; Wed, 4 Jan 2017 05:59:12 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 27rwky1hbd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2017 05:59:12 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v04AxB5u029416; Wed, 4 Jan 2017 05:59:11 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v04Ax5UC029354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Jan 2017 05:59:07 -0500 Received: from MISOUT7MSGHUBAH.ITServices.sbc.com (MISOUT7MSGHUBAH.itservices.sbc.com [130.9.129.152]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Wed, 4 Jan 2017 10:58:48 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAH.ITServices.sbc.com ([130.9.129.152]) with mapi id 14.03.0319.002; Wed, 4 Jan 2017 05:58:47 -0500 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Thread-Index: AQHSVX1sWRRKPiOkHUi6mpUAv+5fGqEP0kPDgAAExDGAF5sx0IAAwyyAgAASrGs= Date: Wed, 4 Jan 2017 10:58:47 +0000 Message-ID: References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu> , <54c46adb-16a1-0159-65d1-233359bee392@alum.mit.edu> In-Reply-To: <54c46adb-16a1-0159-65d1-233359bee392@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F40DF1EC85FC45D7B99B7F00DD03FD13attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-04_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701040179 Archived-At: Cc: "sipcore@ietf.org" , Henning Schulzrinne Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 10:59:17 -0000 --_000_F40DF1EC85FC45D7B99B7F00DD03FD13attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Correct, we are in agreement Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Jan 3, 2017, at 11:52 PM, Paul Kyzivat > wrote: On 1/3/17 5:16 PM, Henning Schulzrinne wrote: *From:*DOLLY, MARTIN C [mailto:md3135@att.com] *Sent:* Monday, December 19, 2016 4:44 PM *To:* Henning Schulzrinne > *Cc:* Paul Kyzivat >; s= ipcore@ietf.org *Subject:* Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Small issue with Paul's comments. The user needs to make a "clear" decision on 666 being sent. So the user pressing a button is clear, whether pre/post answer, but an application scenario is not I expect we are in violent agreement here, but just in case... I agree the user needs to make an active decision to press the button (or w= hatever). And to do so thoughtfully the user must understand the implicatio= ns of doing so. But most users will *not* know that pushing the button resu= lts in a 666 being sent. Rather they associate the button with the actions = taken elsewhere as a result of the 666 being sent. Thanks, Paul --_000_F40DF1EC85FC45D7B99B7F00DD03FD13attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Correct, we are in agreement 

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Jan 3, 2017, at 11:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/3/17 5:16 PM, Henning Schulzrinne wrote:

*From:*DOLLY, MARTIN C [mailto:md3135@att.com]
*Sent:* Monday, December 19, 2016 4:44 PM
*To:* Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
*Cc:* Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org
*Subject:* Re: [sipcore] I-D Action:=
draft-ietf-sipcore-status-unwanted-00.txt

Small issue with Paul's comments.

The user needs to make a "clear" = decision on 666 being sent. So the user
pressing a button is clear, whether pre/pos= t answer, but an application
scenario is not

I expect we are in violent agreement here, but just in case...=

I agree the user needs to make an active decision to press the button= (or whatever). And to do so thoughtfully the user must understand the impl= ications of doing so. But most users will *not* know that pushing the butto= n results in a 666 being sent. Rather they associate the button with the actions taken elsewhere as a result of = the 666 being sent.

   Thanks,
   Paul

--_000_F40DF1EC85FC45D7B99B7F00DD03FD13attcom_-- From nobody Wed Jan 4 03:48:31 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E126C129410 for ; Wed, 4 Jan 2017 03:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.089 X-Spam-Level: X-Spam-Status: No, score=-4.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ecco-8Jalp6T for ; Wed, 4 Jan 2017 03:48:28 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72B1A1293EC for ; Wed, 4 Jan 2017 03:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LLh2r1bUl4nIMj5dfamQcfo+9bIJI0qsai7a78lwmv4=; b=JLTkGKoGa/Y3ZOhSoIvsxGPV3w9XUYKPpi6JdAtTGFI1DKMfF9OBY2VIJsggLMSlPIY6IQDmyxTyOnAh83BdVmlFTUBYw3A0L+PUlT1w6AFS3K3cu+bUs3mkkPm/GVUQcVRIuTpoyqQT8XUCrK1nbMEfpIfY5C3MFd8g4c6Ar5k= Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0021.outbound.protection.outlook.com [216.32.180.21]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-52-KJ9cMwGOPW-OQBtq5AP7iw-1; Wed, 04 Jan 2017 06:48:25 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 11:48:20 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 11:48:20 +0000 From: "Asveren, Tolga" To: "DOLLY, MARTIN C" , Paul Kyzivat Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Thread-Index: AQHSVMHSOtfKqrDPvEGEGtM6mvk80aEGUUmAgAmC/oCAAAQ4gIAXnCKAgABuaYCAAGZ+gIAABqBw Date: Wed, 4 Jan 2017 11:48:20 +0000 Message-ID: References: <148157942485.22396.6580667337601476424.idtracker@ietfa.amsl.com> <34872878-300c-1de2-e30b-bd5f7f8fcd42@alum.mit.edu> , <54c46adb-16a1-0159-65d1-233359bee392@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 8483ef77-26d1-443c-a23a-08d4349794cb x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:UWlyin8BqlkeocUo6738a/DzDKnMYF6jMNHXY5WlpPI/4vHyqthVvKUkXW3QeMZ6XST1/Cm+wKvtin1uSOtxHeIcP0BfC/nveAUV0hOyiRKGLzYszhz2DcZUE9VnJlXcXVyV46Oe8/jmF4ST/aP4M5asHvjeBetsVxvaSb3Xp8mL50YOD5VsR0adiQkd/EBuXss3xy5lAClPGG4U7Skyd+ytdUegLuMWgie7GPU00q1JAG255MGVVGb494SYxDQ4Fk+K6jqJcWKfj3/9iWCNMje+8loOscVW4dSHqd/PuziPszx9zoOoMn40aM5ahnbt+nQILP96VdYN4CkUv6YqifdgGQGphJYkuCk7GjU5QlODeZPW1kHM5SPPOr+yyYbHvDdPKZWIcGpKs8fxV4t6qYbyBo3YE3lFvU5z1ape7Luav2NsKfe/L/Frn0UOCuM1W4EKaUSaYZIalHJa69odRA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(252514010)(189002)(24454002)(377454003)(199003)(106356001)(77096006)(7696004)(5660300001)(325944008)(38730400001)(2906002)(6436002)(7736002)(86362001)(74316002)(81166006)(25786008)(2900100001)(6506006)(2171001)(122556002)(3280700002)(4326007)(19609705001)(229853002)(2950100002)(3660700001)(8936002)(33656002)(9686002)(101416001)(50986999)(5001770100001)(66066001)(230783001)(81156014)(189998001)(99286003)(102836003)(55016002)(92566002)(8676002)(3846002)(76176999)(68736007)(97736004)(790700001)(106116001)(93886004)(105586002)(6116002)(54356999)(54906002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 11:48:20.5420 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 X-MC-Unique: KJ9cMwGOPW-OQBtq5AP7iw-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350EAB7595A6EF4D9C3DAA1B2610SN2PR03MB2350namp_" Archived-At: Cc: "sipcore@ietf.org" , Henning Schulzrinne Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 11:48:31 -0000 --_000_SN2PR03MB2350EAB7595A6EF4D9C3DAA1B2610SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I think clear decision !=3D pressing a button (at least not necessarily). F= or example, I can envision some UI, which lets the user enter some numbers = it considers as spam (based on previous experience) and a 666 reply is gene= rated without even ringing the phone/user not pressing a button if a call i= s received from such a number. This would satisfy the "clear decision" crit= erion (the user enters the number/ID to the list) but does not require the = user to press a button for subsequent calls. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of DOLLY, MARTIN = C Sent: Wednesday, January 04, 2017 5:59 AM To: Paul Kyzivat Cc: sipcore@ietf.org; Henning Schulzrinne Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.tx= t Correct, we are in agreement Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Jan 3, 2017, at 11:52 PM, Paul Kyzivat > wrote: On 1/3/17 5:16 PM, Henning Schulzrinne wrote: *From:*DOLLY, MARTIN C [mailto:md3135@att.com] *Sent:* Monday, December 19, 2016 4:44 PM *To:* Henning Schulzrinne > *Cc:* Paul Kyzivat >; s= ipcore@ietf.org *Subject:* Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-00.txt Small issue with Paul's comments. The user needs to make a "clear" decision on 666 being sent. So the user pressing a button is clear, whether pre/post answer, but an application scenario is not I expect we are in violent agreement here, but just in case... I agree the user needs to make an active decision to press the button (or w= hatever). And to do so thoughtfully the user must understand the implicatio= ns of doing so. But most users will *not* know that pushing the button resu= lts in a 666 being sent. Rather they associate the button with the actions = taken elsewhere as a result of the 666 being sent. Thanks, Paul --_000_SN2PR03MB2350EAB7595A6EF4D9C3DAA1B2610SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I think clear decision !=3D pressing a button (at l= east not necessarily). For example, I can envision some UI, which lets the = user enter some numbers it considers as spam (based on previous experience) and a 666 reply is generated without even ringing = the phone/user not pressing a button if a call is received from such a numb= er. This would satisfy the “clear decision” criterion (the user= enters the number/ID to the list) but does not require the user to press a button for subsequent calls.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of DOLLY, MARTIN C
Sent: Wednesday, January 04, 2017 5:59 AM
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: sipcore@ietf.org; Henning Schulzrinne <Henning.Schulzrinne@fc= c.gov>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwante= d-00.txt

 

Correct, we are in ag= reement 

Martin C. Dolly

Lead Member of Technical Staff

Core & Government/Regulatory Standards

AT&T

Cell: += 1.609.903.3360

Email: md3= 135@att.com

 


On Jan 3, 2017, at 11:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 1/3/17 5:16 PM, Henning Schulzrinne wrote:


*From:*DOLLY, MARTIN C [mailto:md3135@att.com]

*Sent:* Monday, December 19, 2016 4:44 PM=

*To:* Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>

*Cc:* Paul Kyzivat <pkyzivat@alum.mit.edu>; sipcore@ietf.org

*Subject:* Re: [sipcore] I-D Action:

draft-ietf-sipcore-status-unwanted-00.txt=

 

Small issue with Paul's comments.

 

The user needs to make a "clear" decision = on 666 being sent. So the user

pressing a button is clear, whether pre/post answer,= but an application

scenario is not


I expect we are in violent agreement here, but just in case...

I agree the user needs to make an active decision to press the button (or w= hatever). And to do so thoughtfully the user must understand the implicatio= ns of doing so. But most users will *not* know that pushing the button resu= lts in a 666 being sent. Rather they associate the button with the actions taken elsewhere as a result of = the 666 being sent.

   Thanks,
   Paul

--_000_SN2PR03MB2350EAB7595A6EF4D9C3DAA1B2610SN2PR03MB2350namp_-- From nobody Wed Jan 4 04:13:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4790A129437 for ; Wed, 4 Jan 2017 04:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e51O2q4aK7ZM for ; Wed, 4 Jan 2017 04:13:37 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31874128B44 for ; Wed, 4 Jan 2017 04:13:36 -0800 (PST) Received: from [85.158.136.83] by server-10.bemta-5.messagelabs.com id 3B/05-04988-DE6EC685; Wed, 04 Jan 2017 12:13:33 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPKsWRWlGSWpSXmKPExsWi75nTqfvmWU6 Ewd/1IhY/j+xmtfj6YxObA5PH7dtv2DyWLPnJFMAUxZqZl5RfkcCa0XZnH3vBt4WMFbu/HGdu YLwzn7GLkZNDSGAbo8Tql5pdjFxA9iFGiZW9Z9ngnM4vH1khnI2MEteWbmLuYuTgYBOwl5ixJ wakW0TAVOJs41s2EJtZQE7i+oeNYLawQJDE45MzmCBqgiWOT3zFDmE7SSyftAZsM4uAisS8yd 1gcV6BUIkXd3qhFi9kkrjbfRmsmVMgVuL7iutgQxkFZCW+NK5mhlgmLnHryXywGgkBAYkle84 zQ9iiEi8f/2OFqMmTeD/tAivEAkGJkzOfsEC8rCrxb+UipgmMorOQjJqFpGUWkpZZQC8zC2hK rN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMGsWpRWWpRbpGlnpJRZnpGSW5iZk5uoYGpnq5q cXFiempOYlJxXrJ+bmbGIERWc/AwLiD8fIWv0OMkhxMSqK8fe05EUJ8SfkplRmJxRnxRaU5qc WHGGU4OJQkePmAES4kWJSanlqRlpkDTA0waQkOHiUR3uVPgdK8xQWJucWZ6RCpU4yKUuK87CB 9AiCJjNI8uDZYOrrEKCslzMvIwMAgxFOQWpSbWYIq/4pRnINRSZjXFmQ8T2ZeCdz0V0CLmYAW bw/IBllckoiQkmpg5HWTPnXlzed5V1hd9ylsEWOLm6doVnxq+qSQ1WEFC7w5XVOLbfdIzI88p 8H0ekHC3UmVyY9Nz31tVN/EIuZ0sch9g9H+rqkxmuee1hyvdkx9WjLLMq3EzstvadyXA5wPD6 9db8GfGradmbmmfqLOXt3opNx/r3+524tf51YvPbXsQv+yt+9XKbEUZyQaajEXFScCAD/cdwR CAwAA X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-11.tower-36.messagelabs.com!1483532009!79990979!2 X-Originating-IP: [47.73.108.137] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25429 invoked from network); 4 Jan 2017 12:13:31 -0000 Received: from vgdpm11vr.vodafone.com (HELO voxe05hw.internal.vodafone.com) (47.73.108.137) by server-11.tower-36.messagelabs.com with AES256-SHA encrypted SMTP; 4 Jan 2017 12:13:31 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.50) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 4 Jan 2017 13:13:28 +0100 Received: from VOEXC02W.internal.vodafone.com (145.230.101.22) by VOEXH06W.internal.vodafone.com (47.73.211.210) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 4 Jan 2017 13:13:28 +0100 Received: from VOEXC13W.internal.vodafone.com (145.230.101.15) by VOEXC02W.internal.vodafone.com (145.230.101.22) with Microsoft SMTP Server (TLS) id 14.3.294.0; Wed, 4 Jan 2017 13:13:25 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc13w.internal.vodafone.com ([145.230.101.15]) with mapi id 14.03.0294.000; Wed, 4 Jan 2017 13:13:24 +0100 From: "Dawes, Peter, Vodafone Group" To: Henning Schulzrinne Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSW549jON1XdNft0qMWj02oHw2Q6EmsFcwgACbjgCAAPZScA== Date: Wed, 4 Jan 2017 12:13:23 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710A@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710AVOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 12:13:39 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710AVOEXM31Winterna_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBsaWtlIHlvdXIgc3VnZ2VzdGVkIHdvcmRpbmcg4oCcU0lQIGVudGl0aWVzIG1heSB1c2UgdGhp cyBpbmZvcm1hdGlvbiB0byBhZGp1c3QgaG93IGZ1dHVyZSBjYWxscyBmcm9tIHRoaXMgY2FsbGlu ZyBwYXJ0eSBhcmUgaGFuZGxlZCBmb3IgdGhlIGNhbGxlZCBwYXJ0eSBvciBtb3JlIGJyb2FkbHku 4oCdIGZvciB0aGUgQWJzdHJhY3QgY2xhdXNlLg0KDQpNeSBjb25jZXJucyBhYm91dCB0aGUgbWVh bmluZyBvZiDigJxjYWxsZXLigJ0gYXJlIHRha2VuIGNhcmUgb2YgYnkgdGhlIHJldmlzZWQgd29y ZGluZyBhYm92ZSBhbmQgYnkgdGhlIGNvbW1lbnQgZnJvbSBQYXVsIEt5eml2YXQgdG8gY2hhbmdl IHRoZSB3b3JkaW5nIGluIFNlY3Rpb24gMiBmcm9tIOKAnHRoYXQgdGhlIGNhbGxlciBpcyB1bndh bnRlZOKAnSB0byDigJwgdGhhdCBjYWxscyBmcm9tIHRoaXMgY2FsbGVyIGFyZSB1bndhbnRlZCBi eSB0aGUgY2FsbGVkIHBhcnR5LuKAnQ0KDQpJIGFtIG5vdCBhbiBpbXBsZW1lbnRlciwgYnV0IGl0 IG1ha2VzIHNlbnNlIHRvIG1lIHRvIHBvaW50IG91dCB0aGUgY2Fub25pY2FsaXphdGlvbiBwcm9j ZWR1cmUgaW4gUkZDNDQ3NGJpcyBTZWN0aW9uIDguMyB0byB0cnkgdG8gYXZvaWQgdGhlIHNhbWUg bnVtYmVyIGJlaW5nIHN0b3JlZCBpbiBtdWx0aXBsZSBmb3JtYXRzLiBJIGd1ZXNzIGl0IGNvdWxk IGJlIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQg4oCcQmVoYXZpb3Igb2YgU0lQIEVudGl0aWVz4oCd Lg0KDQpUaGFua3MsDQpQZXRlcg0KDQpGcm9tOiBIZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86 SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292XQ0KU2VudDogMDMgSmFudWFyeSAyMDE3IDIxOjQw DQpUbzogRGF3ZXMsIFBldGVyLCBWb2RhZm9uZSBHcm91cA0KQ2M6IFNJUENPUkUNClN1YmplY3Q6 IFJFOiBbc2lwY29yZV0gQWRvcHRlZCAvIFdHTEM6IGRyYWZ0LXNjaHVsenJpbm5lLWRpc3BhdGNo LXN0YXR1cy11bndhbnRlZA0KDQoNClBsZWFzZSBzZWUgaW5saW5lLg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwDQpTZW50 OiBUdWVzZGF5LCBKYW51YXJ5IDAzLCAyMDE3IDc6MDcgQU0NClRvOiBBbmR5IEh1dHRvbiA8YW5k eWh1dHRvbi5pZXRmQGdtYWlsLmNvbTxtYWlsdG86YW5keWh1dHRvbi5pZXRmQGdtYWlsLmNvbT4+ OyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4N CkNjOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQWRvcHRlZCAvIFdHTEM6IGRyYWZ0LXNjaHVsenJpbm5l LWRpc3BhdGNoLXN0YXR1cy11bndhbnRlZA0KDQoNCg0KSGVsbG8gQWxsLA0KDQoNCg0KQSBmZXcg Y29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMDoNCg0KDQoN ClRoZSB0ZXh0IGluIHRoZSBBYnN0cmFjdCBjbGF1c2UgIlRoZSB0ZXJtaW5hdGluZyBTSVAgZW50 aXR5IG1heSB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBhZGp1c3QgZnV0dXJlIGNhbGwgaGFuZGxp bmcgYmVoYXZpb3IgZm9yIHRoaXMgY2FsbGVkIHBhcnR5IG9yIG1vcmUgYnJvYWRseS4iIG1lbnRp b25zIG9ubHkgdGhlIHRlcm1pbmF0aW5nIFNJUCBlbnRpdHkgYW5kIHRoZSBJbnRyb2R1Y3Rpb24g Y2xhdXNlIHNheXMgIkNhcnJpZXJzIGFuZCBvdGhlciBzZXJ2aWNlIHByb3ZpZGVycyBtYXkgd2Fu dCB0byBoZWxwIHRoZWlyIHN1YnNjcmliZXJzIGF2b2lkIHJlY2VpdmluZyBzdWNoIGNhbGxzICIu IERvZXMgdGhpcyBkcmFmdCBwcm9oaWJpdCBhbnkgaW50ZXJtZWRpYXJ5IFNJUCBlbnRpdHkgYWRq dXN0aW5nIGl0cyBjYWxsIGhhbmRsaW5nIGJlaGF2aW91cj8gQWxzbywgaXQgbWlnaHQgaGVscCBm b3IgdGhlIGRyYWZ0IHRvIGFsbG93IGdlbmVyYWwgYWRqdXN0bWVudCBvZiBmdXR1cmUgaGFuZGxp bmcgb2YgY2FsbHMgZnJvbSB0aGUgY2FsbGluZyBwYXJ0eS4NCg0KDQoNCk5vIHByb2hpYml0aW9u IGlzIGltcGxpZWQ7IEkgd2lsbCBhbGlnbiB0aGUgd29yZGluZyBpbiB0aGUgYWJzdHJhY3Qgd2l0 aCB0aG9zZSBpbiB0aGUgaW50cm9kdWN0aW9uLiBJIHRoaW5rLCBpbiBnZW5lcmFsLCBmb3IgYW55 IFNJUCByZXNwb25zZSBjb2RlLCBhbnkgU0lQIGVudGl0eSB0aGF0IHJlY2VpdmVzIHRoZSBjb2Rl IGNhbiBkbyB3aGF0IGl0IG5lZWRzL3dhbnRzIHRvIGRvIChzdWJqZWN0IHRvIGl0cyByb2xlIGlu IHRoZSBjYWxsIGZsb3cpLiBJ4oCZbSBub3QgcXVpdGUgc3VyZSB3aGF0IHlvdSBtZWFuIGJ5IOKA nGdlbmVyYWwgYWRqdXN0bWVudOKAnS4gUmUtcmVhZGluZyB0aGUgc2VudGVuY2UsIHRoaXMgY291 bGQgYmUgaW1wcm92ZWQgdG8gaW5jbHVkZSBib3RoIHRoZSBjYWxsZWQgYW5kIGNhbGxpbmcgcGFy dHk6IOKAnFNJUCBlbnRpdGllcyBtYXkgdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8gYWRqdXN0IGhv dyBmdXR1cmUgY2FsbHMgZnJvbSB0aGlzIGNhbGxpbmcgcGFydHkgYXJlIGhhbmRsZWQgZm9yIHRo ZSBjYWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LuKAnSBJcyB0aGF0IGNsZWFyZXI/DQoNCg0K DQpXaGF0IGlzIG1lYW50IGluIHRoaXMgZHJhZnQgYnkgImNhbGxlciI/IElzIGl0IHRoZSBvcmln aW5hdGluZyBpZGVudGl0eSB1c2VkIGZvciB0aGUgcGFydGljdWxhciByZWplY3RlZCBjYWxsLCBv ciBpcyBpdCBhbnkgaWRlbnRpdHkgb3duZWQgYnkgdGhlIHBlcnNvbiB3aG8gbWFkZSB0aGUgY2Fs bD8gSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGJlIGNsZWFyIG9uIHRoaXMuDQoNCg0KDQpQbGVh c2Ugc2VlIGFib3ZlOyBhbnkgd29yZGluZyBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KDQoN CklzIHRoaXMgZHJhZnQgc2NvcGVkIHNwZWNpZmljYWxseSB0byB3aGF0IGRyYWZ0LWlldGYtc3Rp ci1yZmM0NDc0YmlzLTE1LnR4dCByZWZlcnMgdG8gYXMgIlRlbGVwaG9uZSBOdW1iZXJzIj8gSSBk b24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGRyYWZ0IGFib3V0IFNJUCBVUklzLiBJIHRoaW5rIHRo ZSBzY29wZSByZWdhcmRpbmcgY2FsbGVyIGlkZW50aXRpZXMgc2hvdWxkIGJlIGNsZWFyLg0KDQoN Cg0KTm8sIEkgZG9u4oCZdCB0aGluayB0aGlzIG5lZWRzIHRvIGJlIHJlc3RyaWN0ZWQgdG8gcGhv bmUgbnVtYmVycy4gQXMgbG9uZyBhcyB0aGUgY2FsbGluZyBwYXJ0eSBjYW4gYmUgaWRlbnRpZmll ZCAodGVsIG9yIFNJUCBVUkkpLCBJIHNlZSBubyByZWFzb24gdG8gcmVzdHJpY3QgaXQuIEkgd2ls bCBub3RlIHRoYXQgdGhpcyBkb2VzIG5vdCBkZXBlbmQgb24gdGhlIFNJUCBVUkkuIFRoZXJl4oCZ cyB0aGUgb3BlcmF0aW9uYWwgcHJvYmxlbSBvZiBtYXBwaW5nIG11bHRpcGxlIHJlbmRlcmluZ3Mg b2YgdGhlIHNhbWUgbnVtYmVyIHRvIGJlIHRoZSBzYW1lIOKAnHBhcnR54oCdLCBidXQgSSBkb27i gJl0IHRoaW5rIHRoZSBkcmFmdCBuZWVkcyB0byBnbyB0aGVyZSwgYXMgdGhpcyBzZWVtcyBsaWtl IGFuIGltcGxlbWVudGF0aW9uIGNob2ljZS4gVXNpbmcgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJv Y2VkdXJlIGluIFJGQzQ0NzRiaXMgU2VjdGlvbiA4LjMgaXMgbGlrZWx5IGEgZ29vZCBpZGVhLiBT aG91bGQgdGhpcyBiZSBjYWxsZWQgb3V0Pw0KDQoNCg0KUmVhZGluZyB0aGUgcmVsZXZhbnQgc2Vj dGlvbnMgb2YgNDQ3NGJpcyByZW1pbmRzIG1lIHRoYXQgYW5vbnltb3VzIFNJUCBVUklzIHNob3Vs ZCBwcm9iYWJseSBub3QgYmUgaW5jbHVkZWQgaW4gYW55IFVSSS1zcGVjaWZpYyBjYWxsIGhhbmRs aW5nLiBJ4oCZdmUgYWRkZWQgYSBzZW50ZW5jZSBpZGVudGlmeWluZyB0aGUgaXNzdWUsIHdpdGhv dXQgYW55IG5vcm1hdGl2ZSBzdGF0ZW1lbnRzLg0KDQoNCg0KQW5kIGEgY291cGxlIG9mIGVkaXRv cmlhbHM6DQoNCg0KDQpDbGF1c2UgNS4xIHNheXMgIiBUaGlzIGRvY3VtZW50IHJlZ2lzdGVyIGEg bmV3IFNJUCByZXNwb25zZSBjb2RlLiINCg0KDQoNCkNsYXVzZSA2IGNvbnRhaW5zIHRoZSB3b3Jk ICJyZXNlcnZpYmxlIg0KDQoNCg0KQm90aCBmaXhlZC4NCg0KDQoNCg0KDQo9DQo= --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710AVOEXM31Winterna_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLlBsYWlu VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1z dHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBs aWtlIHlvdXIgc3VnZ2VzdGVkIHdvcmRpbmcgPC9zcGFuPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj7igJxTSVAgZW50aXRpZXMgbWF5IHVzZSB0aGlzIGluZm9ybWF0 aW9uIHRvIGFkanVzdCBob3cgZnV0dXJlIGNhbGxzIGZyb20gdGhpcyBjYWxsaW5nIHBhcnR5IGFy ZSBoYW5kbGVkIGZvciB0aGUgY2FsbGVkIHBhcnR5IG9yIG1vcmUgYnJvYWRseS7igJ0gZm9yIHRo ZSBBYnN0cmFjdCBjbGF1c2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk15IGNvbmNlcm5zIGFib3V0IHRoZSBtZWFuaW5nIG9m IOKAnGNhbGxlcuKAnSBhcmUgdGFrZW4gY2FyZSBvZiBieSB0aGUgcmV2aXNlZCB3b3JkaW5nIGFi b3ZlIGFuZCBieSB0aGUgY29tbWVudCBmcm9tIFBhdWwgS3l6aXZhdCB0bw0KPC9zcGFuPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5jaGFuZ2UgdGhlIHdvcmRpbmcgaW4gU2VjdGlvbiAyIGZy b20g4oCcdGhhdCB0aGUgY2FsbGVyIGlzIHVud2FudGVk4oCdIHRvIOKAnCB0aGF0IGNhbGxzIGZy b20gdGhpcyBjYWxsZXIgYXJlIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFydHku4oCdDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkkgYW0gbm90IGFuIGltcGxlbWVudGVy LCBidXQgaXQgbWFrZXMgc2Vuc2UgdG8gbWUgdG8gcG9pbnQgb3V0IHRoZSBjYW5vbmljYWxpemF0 aW9uIHByb2NlZHVyZSBpbiBSRkM0NDc0YmlzIFNlY3Rpb24gOC4zIHRvIHRyeSB0byBhdm9pZCB0 aGUgc2FtZSBudW1iZXIgYmVpbmcgc3RvcmVkIGluIG11bHRpcGxlIGZvcm1hdHMuIEkgZ3Vlc3Mg aXQgY291bGQgYmUgbWVudGlvbmVkDQogaW4gU2VjdGlvbiA0IOKAnEJlaGF2aW9yIG9mIFNJUCBF bnRpdGllc+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSGVubmluZyBTY2h1bHpyaW5uZSBb bWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAw MyBKYW51YXJ5IDIwMTcgMjE6NDA8YnI+DQo8Yj5Ubzo8L2I+IERhd2VzLCBQZXRlciwgVm9kYWZv bmUgR3JvdXA8YnI+DQo8Yj5DYzo8L2I+IFNJUENPUkU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtzaXBjb3JlXSBBZG9wdGVkIC8gV0dMQzogZHJhZnQtc2NodWx6cmlubmUtZGlzcGF0Y2gtc3Rh dHVzLXVud2FudGVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBzZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS08YnI+DQpGcm9tOiBzaXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVo YWxmIE9mIERhd2VzLCBQZXRlciwgVm9kYWZvbmUgR3JvdXA8YnI+DQpTZW50OiBUdWVzZGF5LCBK YW51YXJ5IDAzLCAyMDE3IDc6MDcgQU08YnI+DQpUbzogQW5keSBIdXR0b24gJmx0OzxhIGhyZWY9 Im1haWx0bzphbmR5aHV0dG9uLmlldGZAZ21haWwuY29tIj5hbmR5aHV0dG9uLmlldGZAZ21haWwu Y29tPC9hPiZndDs7IEFkYW0gUm9hY2ggJmx0OzxhIGhyZWY9Im1haWx0bzphZGFtQG5vc3RydW0u Y29tIj5hZGFtQG5vc3RydW0uY29tPC9hPiZndDs8YnI+DQpDYzogU0lQQ09SRSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4N ClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQWRvcHRlZCAvIFdHTEM6IGRyYWZ0LXNjaHVsenJpbm5l LWRpc3BhdGNoLXN0YXR1cy11bndhbnRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gQWxs LCA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSBmZXcgY29tbWVudHMgb24gZHJhZnQtaWV0Zi1z aXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSB0ZXh0 IGluIHRoZSBBYnN0cmFjdCBjbGF1c2UgJnF1b3Q7VGhlIHRlcm1pbmF0aW5nIFNJUCBlbnRpdHkg bWF5IHVzZSB0aGlzIGluZm9ybWF0aW9uIHRvIGFkanVzdCBmdXR1cmUgY2FsbCBoYW5kbGluZyBi ZWhhdmlvciBmb3IgdGhpcyBjYWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LiZxdW90OyBtZW50 aW9ucyBvbmx5IHRoZSB0ZXJtaW5hdGluZw0KIFNJUCBlbnRpdHkgYW5kIHRoZSBJbnRyb2R1Y3Rp b24gY2xhdXNlIHNheXMgJnF1b3Q7Q2FycmllcnMgYW5kIG90aGVyIHNlcnZpY2UgcHJvdmlkZXJz IG1heSB3YW50IHRvIGhlbHAgdGhlaXIgc3Vic2NyaWJlcnMgYXZvaWQgcmVjZWl2aW5nIHN1Y2gg Y2FsbHMgJnF1b3Q7LiBEb2VzIHRoaXMgZHJhZnQgcHJvaGliaXQgYW55IGludGVybWVkaWFyeSBT SVAgZW50aXR5IGFkanVzdGluZyBpdHMgY2FsbCBoYW5kbGluZyBiZWhhdmlvdXI/IEFsc28sIGl0 IG1pZ2h0IGhlbHANCiBmb3IgdGhlIGRyYWZ0IHRvIGFsbG93IGdlbmVyYWwgYWRqdXN0bWVudCBv ZiBmdXR1cmUgaGFuZGxpbmcgb2YgY2FsbHMgZnJvbSB0aGUgY2FsbGluZyBwYXJ0eS4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzRG ODFCRCI+Tm8gcHJvaGliaXRpb24gaXMgaW1wbGllZDsgSSB3aWxsIGFsaWduIHRoZSB3b3JkaW5n IGluIHRoZSBhYnN0cmFjdCB3aXRoIHRob3NlIGluIHRoZSBpbnRyb2R1Y3Rpb24uIEkgdGhpbmss IGluIGdlbmVyYWwsIGZvciBhbnkgU0lQIHJlc3BvbnNlIGNvZGUsIGFueSBTSVAgZW50aXR5IHRo YXQgcmVjZWl2ZXMgdGhlIGNvZGUgY2FuIGRvDQogd2hhdCBpdCBuZWVkcy93YW50cyB0byBkbyAo c3ViamVjdCB0byBpdHMgcm9sZSBpbiB0aGUgY2FsbCBmbG93KS4gSeKAmW0gbm90IHF1aXRlIHN1 cmUgd2hhdCB5b3UgbWVhbiBieSDigJxnZW5lcmFsIGFkanVzdG1lbnTigJ0uIFJlLXJlYWRpbmcg dGhlIHNlbnRlbmNlLCB0aGlzIGNvdWxkIGJlIGltcHJvdmVkIHRvIGluY2x1ZGUgYm90aCB0aGUg Y2FsbGVkIGFuZCBjYWxsaW5nIHBhcnR5OiDigJxTSVAgZW50aXRpZXMgbWF5IHVzZSB0aGlzIGlu Zm9ybWF0aW9uDQogdG8gYWRqdXN0IGhvdyBmdXR1cmUgY2FsbHMgZnJvbSB0aGlzIGNhbGxpbmcg cGFydHkgYXJlIGhhbmRsZWQgZm9yIHRoZSBjYWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LuKA nSBJcyB0aGF0IGNsZWFyZXI/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPldoYXQgaXMgbWVhbnQgaW4gdGhpcyBk cmFmdCBieSAmcXVvdDtjYWxsZXImcXVvdDs/IElzIGl0IHRoZSBvcmlnaW5hdGluZyBpZGVudGl0 eSB1c2VkIGZvciB0aGUgcGFydGljdWxhciByZWplY3RlZCBjYWxsLCBvciBpcyBpdCBhbnkgaWRl bnRpdHkgb3duZWQgYnkgdGhlIHBlcnNvbiB3aG8gbWFkZSB0aGUgY2FsbD8gSSB0aGluayB0aGUg ZHJhZnQNCiBzaG91bGQgYmUgY2xlYXIgb24gdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojNEY4MUJEIj5QbGVhc2Ug c2VlIGFib3ZlOyBhbnkgd29yZGluZyBzdWdnZXN0aW9ucyBhcmUgd2VsY29tZS48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+SXMgdGhpcyBkcmFmdCBzY29wZWQgc3BlY2lmaWNhbGx5IHRvIHdoYXQgZHJh ZnQtaWV0Zi1zdGlyLXJmYzQ0NzRiaXMtMTUudHh0IHJlZmVycyB0byBhcyAmcXVvdDtUZWxlcGhv bmUgTnVtYmVycyZxdW90Oz8gSSBkb24ndCBzZWUgYW55dGhpbmcgaW4gdGhlIGRyYWZ0IGFib3V0 IFNJUCBVUklzLiBJIHRoaW5rIHRoZSBzY29wZSByZWdhcmRpbmcNCiBjYWxsZXIgaWRlbnRpdGll cyBzaG91bGQgYmUgY2xlYXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzRGODFCRCI+Tm8sIEkgZG9u4oCZdCB0aGluayB0 aGlzIG5lZWRzIHRvIGJlIHJlc3RyaWN0ZWQgdG8gcGhvbmUgbnVtYmVycy4gQXMgbG9uZyBhcyB0 aGUgY2FsbGluZyBwYXJ0eSBjYW4gYmUgaWRlbnRpZmllZCAodGVsIG9yIFNJUCBVUkkpLCBJIHNl ZSBubyByZWFzb24gdG8gcmVzdHJpY3QgaXQuIEkgd2lsbCBub3RlIHRoYXQgdGhpcyBkb2VzIG5v dA0KIGRlcGVuZCBvbiB0aGUgU0lQIFVSSS4gVGhlcmXigJlzIHRoZSBvcGVyYXRpb25hbCBwcm9i bGVtIG9mIG1hcHBpbmcgbXVsdGlwbGUgcmVuZGVyaW5ncyBvZiB0aGUgc2FtZSBudW1iZXIgdG8g YmUgdGhlIHNhbWUg4oCccGFydHnigJ0sIGJ1dCBJIGRvbuKAmXQgdGhpbmsgdGhlIGRyYWZ0IG5l ZWRzIHRvIGdvIHRoZXJlLCBhcyB0aGlzIHNlZW1zIGxpa2UgYW4gaW1wbGVtZW50YXRpb24gY2hv aWNlLiBVc2luZyB0aGUgY2Fub25pY2FsaXphdGlvbiBwcm9jZWR1cmUNCiBpbiBSRkM0NDc0Ymlz IFNlY3Rpb24gOC4zIGlzIGxpa2VseSBhIGdvb2QgaWRlYS4gU2hvdWxkIHRoaXMgYmUgY2FsbGVk IG91dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiM0RjgxQkQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzRGODFCRCI+UmVhZGluZyB0aGUgcmVsZXZhbnQgc2VjdGlvbnMgb2YgNDQ3NGJp cyByZW1pbmRzIG1lIHRoYXQgYW5vbnltb3VzIFNJUCBVUklzIHNob3VsZCBwcm9iYWJseSBub3Qg YmUgaW5jbHVkZWQgaW4gYW55IFVSSS1zcGVjaWZpYyBjYWxsIGhhbmRsaW5nLiBJ4oCZdmUgYWRk ZWQgYSBzZW50ZW5jZSBpZGVudGlmeWluZyB0aGUgaXNzdWUsIHdpdGhvdXQNCiBhbnkgbm9ybWF0 aXZlIHN0YXRlbWVudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojNEY4MUJEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QW5kIGEgY291cGxlIG9mIGVkaXRvcmlh bHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5DbGF1c2UgNS4xIHNheXMgJnF1b3Q7IFRoaXMgZG9j dW1lbnQgcmVnaXN0ZXIgYSBuZXcgU0lQIHJlc3BvbnNlIGNvZGUuJnF1b3Q7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5DbGF1c2UgNiBjb250YWlucyB0aGUgd29yZCAmcXVvdDtyZXNlcnZpYmxlJnF1 b3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6IzRGODFCRCI+Qm90aCBmaXhlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj49IDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710AVOEXM31Winterna_-- From nobody Wed Jan 4 08:41:24 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B891299A5 for ; Wed, 4 Jan 2017 08:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.719 X-Spam-Level: X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYhpZI3aRM1b for ; Wed, 4 Jan 2017 08:41:22 -0800 (PST) Received: from relais-inet.orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E02AA12999E for ; Wed, 4 Jan 2017 08:41:21 -0800 (PST) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id EA9CA40EF3 for ; Wed, 4 Jan 2017 17:41:19 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id CC47D4005B for ; Wed, 4 Jan 2017 17:41:19 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0319.002; Wed, 4 Jan 2017 17:41:19 +0100 From: To: "sipcore@ietf.org" Thread-Topic: Errata to RFC3261 Thread-Index: AdJmpFOrQCMC55QHTemMxuphfmO4nA== Date: Wed, 4 Jan 2017 16:41:19 +0000 Message-ID: <28332_1483548079_586D25AF_28332_2196_4_8B970F90C584EA4E97D5BAAC9172DBB81C890EB4@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:41:23 -0000 Hi, I would like to submit an errata to RFC3261 on the following point: RFC 3261 (section 20 Table 2) states that Content-Type header is not applic= able to the CANCEL method (meaning that a CANCEL must not contain a body). Header field=A0=A0=A0=A0=A0=A0=A0=A0=A0 where=A0=A0 proxy ACK BYE CAN INV O= PT REG _________________________________________________ [...] Content-Type=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 *=A0 =A0 * =A0=A0 -=A0=A0 *=A0=A0 *=A0 =A0 * *: The header field is required if the message body is not empty. -: The header field is not applicable. Whereas, in RFC3312 (for preconditions) in case of precondition failure, it= is mentioned that CANCEL should contain an SDP=A0: =A0=A0" 580 (Precondition Failure) responses and BYE and CANCEL requests, =A0=A0 indicating failure to meet certain preconditions, SHOULD contain an =A0=A0 SDP description, indicating which desired status triggered the =A0=A0 failure.=A0 Note that this SDP description is not an offer or an =A0=A0 answer, since it does not lead to the establishment of a session. =A0=A0 The format of such a description is based on the last SDP (an offer =A0=A0 or an answer) received from the remote UA." My proposal for the Errata is: ***OLD*** Header field where proxy ACK BYE CAN INV OPT REG _________________________________________________ [...] Content-Type * * - * * = * ***NEW*** Header field where proxy ACK BYE CAN INV OPT REG _________________________________________________ [...] Content-Type * * * * * = * Are people fine with this understanding? Best regards, Marianne Mohali ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jan 4 08:45:06 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A70C1299AD for ; Wed, 4 Jan 2017 08:45:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bDZfAG4e3L5 for ; Wed, 4 Jan 2017 08:45:03 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1811A12999E for ; Wed, 4 Jan 2017 08:45:03 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v04Ghrcl003396; Wed, 4 Jan 2017 16:45:02 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0017.outbound.protection.outlook.com [23.103.198.17]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4n2a0c0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2017 16:45:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/lhD99DC1XijZEOl9dR9Jo4UHNMPJ6YTxpw8+7mroII=; b=EBnXg9N4CClosNXXGQuNQzfts9dm07wZ2s8ZqvEHu+r/bcsu9fMvXhFL1WiSwLTbzxjpg/azHUkUssNNWO4E+AE3cdDqk9h1ZegyXCBX0hYlZAHTd0mjXulqC8MPDAxtFiCaRSijuHo83J9x80cAOF6t7Ynr1EAlvvIkkUxQv/8= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 16:44:59 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 16:44:59 +0000 From: Henning Schulzrinne To: "Dawes, Peter, Vodafone Group" Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSW548qMD8vRge80+2+9lpYnPuvKEmvKsAgACZRLCAAPq4gIAAS2QA Date: Wed, 4 Jan 2017 16:44:59 +0000 Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710A@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710A@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 0d5deaeb-bb13-4962-5039-08d434c105ec x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:k+KglSZcZtpSnqSGn8TUmATLd0kR19GpooUcuDN2COxl9DQGZu/IUi/R7eZSc8rmKWKLT6K1jBs8vP6km8mRjDV9ZKexx6BrSaLjoi/UhRgii8TC36eYO6MrHOiRu4GwVJDJSILJVlvWkDU5hQQpuWFJ6owUUh+Yrhc6ufXayEh8ZoF1HSiKRGRgYHTMoMsnjEKf5ceOAPKcIDoge4WoojCDvRW0pwbNet0q1gncgDom/TEnhy7uK0W7uwiFB6rLrq5KZDzU+G6xG8MXJwygDR8e+rnKxdjC39E5ZHAWUlsjfn9JmcRwemWjXwExWYuphcoRtnXKYz6ib76vxi4IiN9ZMrRTjzZdEAQsfGPLMwfG6YPBgung7wkfr1pIeRp3RQsXmpla8R0a2Tw5800SDaQGl9T+DpSSZYUGRrvi4prr5jnKKzy7g+NXjidM9AUBoKbZGvSd/R7Xe0iyZ5JPKw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67444318432085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123558021)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(189002)(377454003)(54356999)(81156014)(8676002)(2906002)(7736002)(105586002)(2900100001)(92566002)(86362001)(122556002)(50986999)(76176999)(8936002)(4326007)(101416001)(74316002)(189998001)(106356001)(102836003)(97736004)(229853002)(106116001)(3660700001)(3280700002)(8656002)(25786008)(68736007)(93886004)(81166006)(2950100002)(38730400001)(33656002)(6506006)(7696004)(6436002)(5660300001)(77096006)(99286003)(230783001)(55016002)(19609705001)(110136003)(790700001)(6116002)(3846002)(9686002)(6916009)(66066001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063471AD54680D003F0E3EDEEA610CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 16:44:59.7807 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-04_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:45:04 -0000 --_000_CY1PR09MB063471AD54680D003F0E3EDEEA610CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIGFkZGVkIGEgbm9uLW5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gUkZDIDQ0NzRiaXMgY2Fu b25pY2FsaXphdGlvbi4NCg0KU2luY2UgYSBsb3Qgb2YgdGhlIHdvcmRpbmcgaGFzIGJlZW4gdHdl YWtlZCwgSSB3aWxsIHN1Ym1pdCBhIGRyYWZ0IG5ldyB2ZXJzaW9uIHNob3J0bHksIHNvIHRoYXQg ZXZlcnlvbmUgY2FuIG1ha2Ugc3VyZSB0aGF0IEkgZGlkbuKAmXQgbWlzcyB0aGVpciBpbnRlbnQg b3Igc3VnZ2VzdGlvbi4NCg0KSGVubmluZw0KDQpGcm9tOiBEYXdlcywgUGV0ZXIsIFZvZGFmb25l IEdyb3VwIFttYWlsdG86UGV0ZXIuRGF3ZXNAdm9kYWZvbmUuY29tXQ0KU2VudDogV2VkbmVzZGF5 LCBKYW51YXJ5IDA0LCAyMDE3IDc6MTMgQU0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5u aW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+DQpDYzogU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQWRvcHRlZCAvIFdHTEM6IGRyYWZ0LXNjaHVsenJpbm5l LWRpc3BhdGNoLXN0YXR1cy11bndhbnRlZA0KDQpJIGxpa2UgeW91ciBzdWdnZXN0ZWQgd29yZGlu ZyDigJxTSVAgZW50aXRpZXMgbWF5IHVzZSB0aGlzIGluZm9ybWF0aW9uIHRvIGFkanVzdCBob3cg ZnV0dXJlIGNhbGxzIGZyb20gdGhpcyBjYWxsaW5nIHBhcnR5IGFyZSBoYW5kbGVkIGZvciB0aGUg Y2FsbGVkIHBhcnR5IG9yIG1vcmUgYnJvYWRseS7igJ0gZm9yIHRoZSBBYnN0cmFjdCBjbGF1c2Uu DQoNCk15IGNvbmNlcm5zIGFib3V0IHRoZSBtZWFuaW5nIG9mIOKAnGNhbGxlcuKAnSBhcmUgdGFr ZW4gY2FyZSBvZiBieSB0aGUgcmV2aXNlZCB3b3JkaW5nIGFib3ZlIGFuZCBieSB0aGUgY29tbWVu dCBmcm9tIFBhdWwgS3l6aXZhdCB0byBjaGFuZ2UgdGhlIHdvcmRpbmcgaW4gU2VjdGlvbiAyIGZy b20g4oCcdGhhdCB0aGUgY2FsbGVyIGlzIHVud2FudGVk4oCdIHRvIOKAnCB0aGF0IGNhbGxzIGZy b20gdGhpcyBjYWxsZXIgYXJlIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFydHku4oCdDQoNCkkg YW0gbm90IGFuIGltcGxlbWVudGVyLCBidXQgaXQgbWFrZXMgc2Vuc2UgdG8gbWUgdG8gcG9pbnQg b3V0IHRoZSBjYW5vbmljYWxpemF0aW9uIHByb2NlZHVyZSBpbiBSRkM0NDc0YmlzIFNlY3Rpb24g OC4zIHRvIHRyeSB0byBhdm9pZCB0aGUgc2FtZSBudW1iZXIgYmVpbmcgc3RvcmVkIGluIG11bHRp cGxlIGZvcm1hdHMuIEkgZ3Vlc3MgaXQgY291bGQgYmUgbWVudGlvbmVkIGluIFNlY3Rpb24gNCDi gJxCZWhhdmlvciBvZiBTSVAgRW50aXRpZXPigJ0uDQoNClRoYW5rcywNClBldGVyDQo= --_000_CY1PR09MB063471AD54680D003F0E3EDEEA610CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWlu VGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwg ZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGhhdmUgYWRkZWQgYSBu b24tbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgNDQ3NGJpcyBjYW5vbmljYWxpemF0aW9uLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U2luY2UgYSBsb3Qgb2YgdGhlIHdv cmRpbmcgaGFzIGJlZW4gdHdlYWtlZCwgSSB3aWxsIHN1Ym1pdCBhIGRyYWZ0IG5ldyB2ZXJzaW9u IHNob3J0bHksIHNvIHRoYXQgZXZlcnlvbmUgY2FuIG1ha2Ugc3VyZSB0aGF0IEkgZGlkbuKAmXQg bWlzcyB0aGVpciBpbnRlbnQgb3Igc3VnZ2VzdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPkhlbm5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwIFttYWlsdG86 UGV0ZXIuRGF3ZXNAdm9kYWZvbmUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwg SmFudWFyeSAwNCwgMjAxNyA3OjEzIEFNPGJyPg0KPGI+VG86PC9iPiBIZW5uaW5nIFNjaHVsenJp bm5lICZsdDtIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3YmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBT SVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog W3NpcGNvcmVdIEFkb3B0ZWQgLyBXR0xDOiBkcmFmdC1zY2h1bHpyaW5uZS1kaXNwYXRjaC1zdGF0 dXMtdW53YW50ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLUdCIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBsaWtlIHlvdXIgc3VnZ2VzdGVk IHdvcmRpbmcNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+4oCcU0lQIGVudGl0 aWVzIG1heSB1c2UgdGhpcyBpbmZvcm1hdGlvbiB0byBhZGp1c3QgaG93IGZ1dHVyZSBjYWxscyBm cm9tIHRoaXMgY2FsbGluZyBwYXJ0eSBhcmUgaGFuZGxlZCBmb3IgdGhlIGNhbGxlZCBwYXJ0eSBv ciBtb3JlIGJyb2FkbHku4oCdIGZvciB0aGUgQWJzdHJhY3QgY2xhdXNlLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TXkgY29uY2VybnMgYWJvdXQgdGhlIG1lYW5pbmcgb2Yg 4oCcY2FsbGVy4oCdIGFyZSB0YWtlbiBjYXJlIG9mIGJ5IHRoZSByZXZpc2VkIHdvcmRpbmcgYWJv dmUgYW5kIGJ5IHRoZSBjb21tZW50IGZyb20gUGF1bCBLeXppdmF0IHRvDQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5jaGFuZ2UgdGhlIHdvcmRpbmcgaW4g U2VjdGlvbiAyIGZyb20g4oCcdGhhdCB0aGUgY2FsbGVyIGlzIHVud2FudGVk4oCdIHRvIOKAnCB0 aGF0IGNhbGxzIGZyb20gdGhpcyBjYWxsZXIgYXJlIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFy dHku4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1HQiIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+SSBhbSBub3QgYW4gaW1wbGVtZW50ZXIsIGJ1dCBpdCBtYWtlcyBzZW5z ZSB0byBtZSB0byBwb2ludCBvdXQgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJvY2VkdXJlIGluIFJG QzQ0NzRiaXMgU2VjdGlvbiA4LjMgdG8gdHJ5IHRvIGF2b2lkIHRoZSBzYW1lIG51bWJlciBiZWlu ZyBzdG9yZWQgaW4gbXVsdGlwbGUgZm9ybWF0cy4gSSBndWVzcyBpdA0KIGNvdWxkIGJlIG1lbnRp b25lZCBpbiBTZWN0aW9uIDQg4oCcQmVoYXZpb3Igb2YgU0lQIEVudGl0aWVz4oCdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tR0IiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QZXRlcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gbGFuZz0iRU4tR0IiPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR09MB063471AD54680D003F0E3EDEEA610CY1PR09MB0634namp_-- From nobody Wed Jan 4 08:46:11 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A115712999E for ; Wed, 4 Jan 2017 08:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bo2KDfSW_OxC for ; Wed, 4 Jan 2017 08:46:08 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 944CB12968A for ; Wed, 4 Jan 2017 08:40:29 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v04GdWL1014118; Wed, 4 Jan 2017 16:40:24 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p5uehyjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2017 16:40:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IHw4ocCk+gtFbkprbdpTrmxDMriTeGoMisj3W+T/THg=; b=pxpvuXkTO2Ok5TKJrmxUpGoLwM9YZC7pWYgGLS7rQkkvUue7dtbI108aP4qOQEJ3GLCt4LESTJGmiITizLxkQXN1J+52XCpHbjYGCZYg31wJbWpuwmeOXIcSSAK+jpOnb9u6a4envC+aq7fydzscix0sHXKjmYE997otPoGo4Pk= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 16:40:21 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 16:40:21 +0000 From: Henning Schulzrinne To: "Dale R. Worley" , Andy Hutton Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSZjabqMD8vRge80+2+9lpYnPuvKEohNCw Date: Wed, 4 Jan 2017 16:40:21 +0000 Message-ID: References: (andyhutton.ietf@gmail.com) <8737gzjzrw.fsf@hobgoblin.ariadne.com> In-Reply-To: <8737gzjzrw.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 18c4fe16-b885-4e52-d409-08d434c0603f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:Ujn4nVDGb7wtnkk5YJFmLOvoKJZqICHrx11Xx9pjqwMAA91O/3uVG75Fd0AvGxvkNNIBRAQZjvRhcjJxQPI0/E8SGM6lyxWNaYON/GC0o6MzkxN6A8MNyUp0zk56zG9yhrMDWDSslm9/w64V+gIoIIwxbnYf+O1tUTUQQL70dI1k3ThXY8aAsdSTudr45DEWdBaV4aRNF7dWLiKlBeOWOwqN495Q1Op+yK67lDjw4tqhXhKb0rDNpn/rS8FENVaoitx1wmVQ+snYjddyPbKvOskldGDTDmh12qSXrbZH9rJL+bSlY6DApsqRKqJgXxhxNuNtSbdYsHCe2kzRqQECBuOTyzlZVsNi0fNdoPf1AnZiZSdCLYzOWBWrIjWZI3RDM8q0hnJudPh91sKF8U44j5ccF8Jk+7ueE8D++EMXfoSfFXqa/SRFTxxMNR35VzFWtiralHZ3kBAjOMdCxZX5JA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(377454003)(189002)(13464003)(230783001)(6116002)(229853002)(50986999)(3846002)(9686002)(6436002)(97736004)(5660300001)(2906002)(5001770100001)(4326007)(2900100001)(106356001)(25786008)(66066001)(68736007)(76176999)(790700001)(122556002)(8936002)(2950100002)(3660700001)(74316002)(81166006)(105586002)(55016002)(101416001)(92566002)(8676002)(7696004)(7736002)(54356999)(33656002)(77096006)(102836003)(3280700002)(99286003)(39060400001)(38730400001)(86362001)(6506006)(81156014)(189998001)(106116001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634A9BC096F17EB274C7E76EA610CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 16:40:21.7161 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-04_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:46:09 -0000 --_000_CY1PR09MB0634A9BC096F17EB274C7E76EA610CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Tuesday, January 03, 2017 10:00 PM Andy Hutton > w= rites: > The abstract states "The terminating SIP entity may use this > information....". > > But this is not I believe referring to the actual terminating SIP > entity which is the called users device but is referring to some > preceding SIP entity probably the service provider. I suspect that a better wording would be "The terminating SIP service ...". The current wording is "SIP entities", simply because (on second thought) t= hat even the originating carrier may use the 666 response information, e.g.= , to determine that one of its customers is violating its terms of service. "Asveren, Tolga" > writ= es: > Is there a particular reason why 666 shouldn't be applicable to > MESSAGE method? It should be applicable to any out-of-dialog request (whether or not it is = dialog-forming). I can imagine a 666 response to SUBSCRIBE as well. Dale Added "out-of-dialogue" qualification. --_000_CY1PR09MB0634A9BC096F17EB274C7E76EA610CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Inline.

 

-----Original Message-= ----
From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley=
Sent: Tuesday, January 03, 2017 10:00 PM

Andy Hutton <andyhutton.ietf@gmail.com> writes:

> The abstract stat= es "The terminating SIP entity may use this

> information....&q= uot;.

> <= /p>

> But this is not I= believe referring to the actual terminating SIP

> entity which is t= he called users device but is referring to some

> preceding SIP ent= ity probably the service provider.

 

I suspect that a bette= r wording would be "The terminating SIP service ...".<= /p>

 

The current wording= is “SIP entities”, simply because (on second thought) that eve= n the originating carrier may use the 666 response information, e.g., to de= termine that one of its customers is violating its terms of service.

 

 

 

"Asveren, Tolga&q= uot; <tasveren@sonusnet.com> writes:

> Is there a partic= ular reason why 666 shouldn't be applicable to

> MESSAGE method?

 

It should be applicabl= e to any out-of-dialog request (whether or not it is dialog-forming).<= /o:p>

 

I can imagine a 666 re= sponse to SUBSCRIBE as well.

 

Dale

 

Added “out-of= -dialogue” qualification.

--_000_CY1PR09MB0634A9BC096F17EB274C7E76EA610CY1PR09MB0634namp_-- From nobody Wed Jan 4 09:12:38 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD3B129534; Wed, 4 Jan 2017 09:12:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 09:12:34 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:12:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : A SIP Response Code for Unwanted Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-status-unwanted-01.txt Pages : 6 Date : 2017-01-04 Abstract: This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 4 10:55:21 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3A129A31; Wed, 4 Jan 2017 10:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6B5a-y-r-_Hw; Wed, 4 Jan 2017 10:55:18 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D25B129A2F; Wed, 4 Jan 2017 10:55:18 -0800 (PST) Received: from Orochi.local (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v04ItGQn072877 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 4 Jan 2017 12:55:17 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Orochi.local To: internet-drafts@ietf.org, i-d-announce@ietf.org References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> Date: Wed, 4 Jan 2017 12:55:16 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 18:55:20 -0000 [as chair] I plan to request publication for this document next week. If you made comments during the WGLC, please check that they have been adequately represented in the current document in the next couple of days. /a On 1/4/17 11:12, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Session Initiation Protocol Core of the IETF. > > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > Filename : draft-ietf-sipcore-status-unwanted-01.txt > Pages : 6 > Date : 2017-01-04 > > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call was unwanted. SIP entities > may use this information to adjust how future calls from this calling > party are handled for the called party or more broadly. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jan 4 14:22:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B421295C7 for ; Wed, 4 Jan 2017 14:22:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36_U3n3aTRDh for ; Wed, 4 Jan 2017 14:22:26 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD8F1294A2 for ; Wed, 4 Jan 2017 14:22:26 -0800 (PST) Received: from resomta-ch2-20v.sys.comcast.net ([69.252.207.116]) by resqmta-ch2-11v.sys.comcast.net with SMTP id OtwkcMAh06nWCOtwvcwqtt; Wed, 04 Jan 2017 22:22:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483568545; bh=CuUCqsYw8clWyfsHITbehQqKPPCx1viOYx4Q34hZicQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=gy4zFxWOp/LDf2LmOdStLl6qLZapYvI4yvueFxa2PTd/84iBTgHmZRXnfWe0U1mMV BO3Aa/+hylSiFi1qI3xk8dLYYgB/AtVRHnGKuGX9G/l9E9xrz6Avi0lcZghaRwpJ35 Tc8JlG1o0oOcq2J8EyqRPjCWfv6YIXDB6aUZD3CtMDTKS3KTOV2hNnTqnfeWRdZEcD SF9QgpuiGyfzpOok8oFXMbjfNakeHyLvAPDZRi85PFwARj1oc0ARJK4+opyYlXMMMs 3P+fI2Gb14g9SjhKpXiTaJ8qAGIFoR+O5CCq/qIx/tTOl9swaoW5CbADTDVNSyhxzP 0ElAEQJk1/vHg== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-20v.sys.comcast.net with SMTP id OtwucYnEbEwWaOtwvczeoV; Wed, 04 Jan 2017 22:22:25 +0000 To: sipcore@ietf.org References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> From: Paul Kyzivat Message-ID: <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> Date: Wed, 4 Jan 2017 17:22:24 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHpYD8sYastqdL3+MadkMskyB0Xk5Htby9w3ZkCc2fROzIb7rUzR027kmGc4zKEJRFZFWExh82aNKZRhvd071eY+cpVAws7BIp4lL602kan3lpUU8cg9 DCppjPBelqdJKy4n4FtAzknPX1TBLA8Rto7cylzLdx4gvc24GaOTItP3zLn2KMVVt/YDuFe6EUMJFw== Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:22:28 -0000 I reviewed this latest version. IMO it has covered all the concerns I had. I have one new thought about it: Given the discussion that has occurred, it does seem like 666 might validly be used with other dialog-establishing requests - notably SUBSCRIBE. In that case, it is possible that the SUBSCRIBE itself might be accepted, and then the rejection indicated in-dialog. Then it wouldn't be BYE, but rather NOTIFY that would carry the 666 as a Reason. This is a little far fetched, but I would hate to see it excluded. I don't see anything that clearly does exclude this usage, so maybe nothing needs to be done. OTOH, it might be helpful to at least note that other usages, such as this, are possible and not excluded. What do others think? Thanks, Paul On 1/4/17 1:55 PM, Adam Roach wrote: > [as chair] > > I plan to request publication for this document next week. If you made > comments during the WGLC, please check that they have been adequately > represented in the current document in the next couple of days. > > /a > > On 1/4/17 11:12, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Session Initiation Protocol Core of >> the IETF. >> >> Title : A SIP Response Code for Unwanted Calls >> Author : Henning Schulzrinne >> Filename : draft-ietf-sipcore-status-unwanted-01.txt >> Pages : 6 >> Date : 2017-01-04 >> >> Abstract: >> This document defines the 666 (Unwanted) SIP response code, allowing >> called parties to indicate that the call was unwanted. SIP entities >> may use this information to adjust how future calls from this calling >> party are handled for the called party or more broadly. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-01 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-01 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Jan 4 14:30:09 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF25129670 for ; Wed, 4 Jan 2017 14:30:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYdq8XJNCqiy for ; Wed, 4 Jan 2017 14:30:06 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64121129648 for ; Wed, 4 Jan 2017 14:30:06 -0800 (PST) Received: from pps.filterd (m0049463.ppops.net [127.0.0.1]) by m0049463.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v04MOcX2037699; Wed, 4 Jan 2017 17:30:05 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049463.ppops.net-00191d01. with ESMTP id 27s8aa22dm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2017 17:30:04 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v04MU4X2007903; Wed, 4 Jan 2017 17:30:04 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v04MTuZN005174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 4 Jan 2017 17:30:00 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 4 Jan 2017 22:29:41 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0319.002; Wed, 4 Jan 2017 17:29:41 -0500 From: "DOLLY, MARTIN C" To: Paul Kyzivat Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZtkPt40qGHXtIECPdoNi8q++xKEo5mEw Date: Wed, 4 Jan 2017 22:29:40 +0000 Message-ID: <50991F9D-4A01-4F1D-859D-3D156F19E0DF@att.com> References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com>, <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> In-Reply-To: <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_50991F9D4A014F1D859D3D156F19E0DFattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-04_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701040329 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:30:08 -0000 --_000_50991F9D4A014F1D859D3D156F19E0DFattcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Paul, this applies to MESSAGE as well as SUB/NOT on the future Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Jan 4, 2017, at 5:22 PM, Paul Kyzivat > wrote: I reviewed this latest version. IMO it has covered all the concerns I had. = I have one new thought about it: Given the discussion that has occurred, it does seem like 666 might validly= be used with other dialog-establishing requests - notably SUBSCRIBE. In th= at case, it is possible that the SUBSCRIBE itself might be accepted, and th= en the rejection indicated in-dialog. Then it wouldn't be BYE, but rather N= OTIFY that would carry the 666 as a Reason. This is a little far fetched, but I would hate to see it excluded. I don't = see anything that clearly does exclude this usage, so maybe nothing needs t= o be done. OTOH, it might be helpful to at least note that other usages, su= ch as this, are possible and not excluded. What do others think? Thanks, Paul On 1/4/17 1:55 PM, Adam Roach wrote: [as chair] I plan to request publication for this document next week. If you made comments during the WGLC, please check that they have been adequately represented in the current document in the next couple of days. /a On 1/4/17 11:12, internet-drafts@ietf.org = wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : A SIP Response Code for Unwanted Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-status-unwanted-01.txt Pages : 6 Date : 2017-01-04 Abstract: This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-status-unwanted-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_50991F9D4A014F1D859D3D156F19E0DFattcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with Paul, this applies to MESSAGE as well as SUB/NOT on the f= uture

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Jan 4, 2017, at 5:22 PM, Paul Kyzivat <paul.kyzivat@comcast.net> wrote:

I reviewed this latest version. IMO it has covered all the conce= rns I had. I have one new thought about it:

Given the discussion that has occurred, it does seem like 666 might v= alidly be used with other dialog-establishing requests - notably SUBSCRIBE.= In that case, it is possible that the SUBSCRIBE itself might be accepted, = and then the rejection indicated in-dialog. Then it wouldn't be BYE, but rather NOTIFY that would carry the= 666 as a Reason.

This is a little far fetched, but I would hate to see it excluded. I = don't see anything that clearly does exclude this usage, so maybe nothing n= eeds to be done. OTOH, it might be helpful to at least note that other usag= es, such as this, are possible and not excluded. What do others think?

   Thanks,
   Paul

On 1/4/17 1:55 PM, Adam Roach wrote:
[as chair]

I plan to request publication for this docu= ment next week. If you made
comments during the WGLC, please check that= they have been adequately
represented in the current document in the = next couple of days.

/a

On 1/4/17 11:12, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the = on-line Internet-Drafts
directories.
This draft is a work item of the Session In= itiation Protocol Core of
the IETF.

       &= nbsp;Title           : A = SIP Response Code for Unwanted Calls
       &= nbsp;Author          : Henning= Schulzrinne
   Filename   &nbs= p;    : draft-ietf-sipcore-status-unwanted-01.txt
   Pages    &= nbsp;      : 6
   Date    &n= bsp;       : 2017-01-04

Abstract:
   This document defines the= 666 (Unwanted) SIP response code, allowing
   called parties to indicat= e that the call was unwanted.  SIP entities
   may use this information = to adjust how future calls from this calling
   party are handled for the= called party or more broadly.


The IETF datatracker status page for this d= raft is:
https://datatracker.ietf.org/doc/draf= t-ietf-sipcore-status-unwanted/

There's also a htmlized version available a= t:
https://tools.ietf.org/html/draft-ietf-s= ipcore-status-unwanted-01

A diff from the previous version is availab= le at:
https://www.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-sipcore-status-unwanted-01


Please note that it may take a couple of mi= nutes from the time of
submission
until the htmlized version and diff are ava= ilable at tools.ietf.org.

Internet-Drafts are also available by anony= mous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___________________________________________= ____
sipcore mailing list
sipcore= @ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


___________________________________________= ____
sipcore mailing list
sipcore= @ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_50991F9D4A014F1D859D3D156F19E0DFattcom_-- From nobody Wed Jan 4 14:35:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B5D12979D for ; Wed, 4 Jan 2017 14:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.019 X-Spam-Level: X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11IwuyAomsX8 for ; Wed, 4 Jan 2017 14:35:46 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B76F1129784 for ; Wed, 4 Jan 2017 14:35:46 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id DF939C07FA for ; Wed, 4 Jan 2017 23:35:44 +0100 (CET) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.83]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id CAD91180062 for ; Wed, 4 Jan 2017 23:35:44 +0100 (CET) Received: from OPEXCNORMAC.corporate.adroot.infra.ftgroup ([fe80::f9fb:6cba:1c64:7737]) by OPEXCNORMAF.corporate.adroot.infra.ftgroup ([fe80::e1dd:62fe:d378:e3f8%21]) with mapi id 14.03.0319.002; Wed, 4 Jan 2017 23:35:44 +0100 From: To: "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQA== Date: Wed, 4 Jan 2017 22:35:43 +0000 Message-ID: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:35:49 -0000 Hi,=20 I have the following comments on v01: -Section 4 - 4rd paragraph: The actions described here do not depend on the nature of the SIP URI, e.g., whether it describes a telephone number or not but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"?=20 -Section 4 - last paragraph: We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that the corresponding proxy supports this particular response code. I would suggest: "This document defines a new SIP feature-capability indica= tor [RFC6809] value, sip.666, that ... -Section 4 general: IMO, it would be good to have a paragraph addressing the question of the "c= alling party number" (mentioned several time in the document): indeed, this= calling party number can be identified by the telephone number/address in = the From header or the one in the P-Asserted-Identity header that may be di= fferent. Depending on the one displayed to the called UA, the 666 could con= cern only one or both addresses depending on service provider choices. If w= e take the example of a call-center or an IPBX having the head number and a= range of private numbers, the service provider could interpret the 666 fro= m the called user only for the private number (in the From header) or for t= he whole pool (P-Asserted-Identity). I suggest to have a paragraph to highl= ight this point.=20 -Section 6: calling party number / calling party address Best regards, Marianne ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed Jan 4 14:41:40 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31E631295C7 for ; Wed, 4 Jan 2017 14:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo_2j3zZ_z0z for ; Wed, 4 Jan 2017 14:41:37 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5875D12973D for ; Wed, 4 Jan 2017 14:41:36 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v04MfVsv005150; Wed, 4 Jan 2017 22:41:31 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0020.outbound.protection.outlook.com [23.103.198.20]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4n2a5xy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2017 22:41:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W+OvttIA4+8E5qpK1CNITJVk5Kfilt6Jw/BPT9VpgZY=; b=RW2YJH3OTcQeeuyG+6i07vv1bTGuqtTUWN3j69uVaaPnFkTVM8AhWhwMLDa+rHMMRUVc6xSNRLs6KzQtRKcFoqXO+Q7CFavFVT9YoaRViCXIkD5LQcsS0pVgSuVE6lxVfMXkVsC5bxGZCk7QSJ2xezxxAvm0HqdLUKMCf3V9Xcg= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 22:41:29 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 22:41:29 +0000 From: Henning Schulzrinne To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZtkNZBs4MySSekqJkBAojeGCU6Eo5mXA Date: Wed, 4 Jan 2017 22:41:29 +0000 Message-ID: References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> In-Reply-To: <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 46564c79-fb84-487a-8faf-08d434f2d342 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:LwAXPOnhMUmjvt+9nVjVmFZNdr3W0bPDHKmT18IbN1Lb8Lj0g7WFanJ/1td11ifReJDilQ/kGI8QkChieFBVhbpSOs9FfxtlLs5TQFkeAFf3wQD2+jSRL+mTvmSFeGT0SOjL4RI6CmG0GcZXr5dSnR0Z46iH0kW0VXl3Cx3Ls8EtQ46vKVx0cGF2xNGi94Fk+zaTng5L/cloHWdLWt82ISoQSrqey8It4V2AllJ6g4S5ZMfrZyLM9F3nHo4w7vQB3HAmcQEBOxtSoX/kHxwWWauFlsAhWQG3S2BNVRLPrzaNIcsj876moaw+N+lV2z26OwPQ17MgZwrRv1gYYF7QXgW+LPcvk1EJUaiEiGgYctV4GguTxFL/h1+a4RXoXCIKiPzoyEdthFfm/42BZ191U3fMGPdjK5ftlW3A66nVi1ty9jyF50PDd8CnShLFTD8M6tYXdpdDaYa0zEK75k2mIA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123560025)(20161123562025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(189002)(54094003)(13464003)(377454003)(6506006)(2900100001)(81156014)(50986999)(229853002)(8666007)(54356999)(107886002)(106356001)(2906002)(6116002)(7696004)(86362001)(102836003)(105586002)(97736004)(33656002)(189998001)(101416001)(3280700002)(99286003)(5660300001)(106116001)(38730400001)(77096006)(66066001)(92566002)(8676002)(76176999)(122556002)(81166006)(7736002)(5001770100001)(74316002)(9686002)(230783001)(2950100002)(3846002)(25786008)(6436002)(8936002)(3660700001)(2501003)(55016002)(305945005)(68736007)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 22:41:29.4705 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-04_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:41:39 -0000 Interesting corner case. Do you have a particular use case in mind? Would t= his be a consumer (subscriber) SUBSCRIBEing to a particular event and then = not liking the NOTIFYs that follow? In general, my sense is that we haven't been terribly specific about status= code usage, except where the code had a very specific and narrow scope (e.= g., on geolocation or resource-priority), and even there we have largely le= ft the method question open, even if the examples or text implied usage wit= h a small subset. For example, most of the status codes defined in 3261 pro= bably never appear in response to a BYE (or CANCEL or OPTIONS). Thus, I won= der if simply having an escape clause similar to the job description "and o= ther duties as assigned" avoids getting into the corner cases. Since an ent= ity getting a 666 acts on it like any 6xx status, in general, there shouldn= 't be interoperability issues. If you return 666 in response to a CANCEL (n= ot in a Reason), you shouldn't expect anything interesting to happen. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, January 04, 2017 5:22 PM To: sipcore@ietf.org Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-u= nwanted-01.txt I reviewed this latest version. IMO it has covered all the concerns I had. = I have one new thought about it: Given the discussion that has occurred, it does seem like 666 might validly= be used with other dialog-establishing requests - notably SUBSCRIBE. In th= at case, it is possible that the SUBSCRIBE itself might be accepted, and th= en the rejection indicated in-dialog. Then it wouldn't be BYE, but rather N= OTIFY that would carry the 666 as a Reason. This is a little far fetched, but I would hate to see it excluded. I don't = see anything that clearly does exclude this usage, so maybe nothing needs t= o be done. OTOH, it might be helpful to at least note that other usages, su= ch as this, are possible and not excluded. What do others think? Thanks, Paul =20 From nobody Wed Jan 4 14:50:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9EF129795 for ; Wed, 4 Jan 2017 14:50:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjM8zisq-f0J for ; Wed, 4 Jan 2017 14:50:09 -0800 (PST) Received: from mail-wj0-x230.google.com (mail-wj0-x230.google.com [IPv6:2a00:1450:400c:c01::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E340129497 for ; Wed, 4 Jan 2017 14:50:08 -0800 (PST) Received: by mail-wj0-x230.google.com with SMTP id tq7so243598276wjb.0 for ; Wed, 04 Jan 2017 14:50:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=qSCUPNax0TH0YaOQJW5EogYqsiJbOWC+YFLG1+ZrKfg=; b=koN1HUHOAv40y2LNkonhymHV+CC/DtPGNr/FukSmBLI3aWmwO57IwUH8717vRPsIh8 6G2rp6CktIfUGXFYvXRsQqPBy08sBofkjAPWaZjQCma6dghFI2gcP6td3I7l7hevOzcz Rl07Z2ZFBwasmiKxmlCUbL7y5Rmbwr1l2VDYHOiFhCd5mDoL9XA4QI1EJqdf63vaGt35 cvsHczUxHj6tPlfPM6j5jT2XUXtl76sQ/Bx4pV0/iym+bkbeVYnamyc0eDze2H6Q0Cp2 vnvIKfVjXx6jt334vjHtBDuD9waOD1KJLQC5QCbtqV6FGWoVDxnfUSQTUNrHAz0jgkBa MO5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=qSCUPNax0TH0YaOQJW5EogYqsiJbOWC+YFLG1+ZrKfg=; b=s1xaY57zyNuk5zQSf1Fi4jRxBuK0hjryGSsBabcd5YEPQynBvE/x5D/jUzrmBNPBEq YVxfN+Pqw7Yn7mhH9Ocl3x5UHleTjk6UW4tWzqiOgNAq1OL6UgtxdTBt6yAUu8xbtOL7 ysWgeSnc+iDymHo+sX4FeUIX1treIxztzYetGfOryv8kT1I7Vc7Ld4X0y5vyP5maUwjF VvX4JsnUTsj8jAmCmW5mQF90lz/d+pIC00HHTj1Eh6Qr3TYxjdnOFe38mT2sx1iMZKZR jiYCod8E1iRZigd2fVG3A2WS/W4440Oq3vTIfifthRbOM+i+eVJvl5kRR2zhNKwM+iqt WwAg== X-Gm-Message-State: AIkVDXIDTc8qd7FePsA9IWKc0eHsBU9BlLm4B+lUSbREk4PExgQ81J2mBLDlEikvS2q1njXjmU5Ip7iLGGzIaQ== X-Received: by 10.194.120.198 with SMTP id le6mr50526773wjb.22.1483570206961; Wed, 04 Jan 2017 14:50:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.173.98 with HTTP; Wed, 4 Jan 2017 14:50:06 -0800 (PST) From: Ranjit Avasarala Date: Wed, 4 Jan 2017 16:50:06 -0600 Message-ID: To: marianne.mohali@orange.com Content-Type: multipart/alternative; boundary=089e011600022f770205454c9b02 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 - related draft - https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 22:50:10 -0000 --089e011600022f770205454c9b02 Content-Type: text/plain; charset=UTF-8 Hi Sometime I had submitted an I-D based on a similar idea - to block a particular caller either temporarily or permanently - https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00 Here the SIP Reason header would be appended to the BYE request. Now using 666 response code - is the block permanent or time based? Regards Ranjit On Wed, Jan 4, 2017 at 4:35 PM, wrote: > Hi, > > I have the following comments on v01: > > -Section 4 - 4rd paragraph: > The actions described here do not depend on the nature of the SIP > URI, e.g., whether it describes a telephone number or not > but in the rest of the document only telephone numbers are mentioned. It > would be good to reflect this by using "telephone number or address"? > > -Section 4 - last paragraph: > We define a SIP feature-capability [RFC6809], sip.666, that allows > the registrar to indicate that the corresponding proxy supports > this > particular response code. > I would suggest: "This document defines a new SIP feature-capability > indicator [RFC6809] value, sip.666, that ... > > -Section 4 general: > IMO, it would be good to have a paragraph addressing the question of the > "calling party number" (mentioned several time in the document): indeed, > this calling party number can be identified by the telephone number/address > in the From header or the one in the P-Asserted-Identity header that may be > different. Depending on the one displayed to the called UA, the 666 could > concern only one or both addresses depending on service provider choices. > If we take the example of a call-center or an IPBX having the head number > and a range of private numbers, the service provider could interpret the > 666 from the called user only for the private number (in the From header) > or for the whole pool (P-Asserted-Identity). I suggest to have a paragraph > to highlight this point. > > -Section 6: > calling party number / calling party address > > > Best regards, > Marianne > > > ____________________________________________________________ > _____________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --089e011600022f770205454c9b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi
Sometime I had submitted an I-D= based on a similar idea - to block a particular caller either temporarily = or permanently -=C2=A0 https://tools.ietf.org/html/draft-= avasarala-sipping-reason-header-dynamic-icb-00

Here t= he SIP Reason header would be appended to the BYE request.=C2=A0=C2=A0
=
Now using 666 response code - is the block permanent or time= based?

Regards
Ranjit

On Wed, Jan 4, 2017 at= 4:35 PM, <marianne.mohali@orange.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Hi,

I have the following comments on v01:

-Section 4 - 4rd paragraph:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 The actions described here do not depend on the= nature of the SIP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 URI, e.g., whether it describes a telephone num= ber or not
but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"= ;?

-Section 4 - last paragraph:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 We define a SIP feature-capability [RFC6809], s= ip.666, that allows
=C2=A0 =C2=A0 =C2=A0 =C2=A0 the registrar to indicate that the correspondin= g proxy supports this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 particular response code.
I would suggest: "This document defines a new SIP feature-capability i= ndicator [RFC6809] value, sip.666, that ...

-Section 4 general:
IMO, it would be good to have a paragraph addressing the question of the &q= uot;calling party number" (mentioned several time in the document): in= deed, this calling party number can be identified by the telephone number/a= ddress in the From header or the one in the P-Asserted-Identity header that= may be different. Depending on the one displayed to the called UA, the 666= could concern only one or both addresses depending on service provider cho= ices. If we take the example of a call-center or an IPBX having the head nu= mber and a range of private numbers, the service provider could interpret t= he 666 from the called user only for the private number (in the From header= ) or for the whole pool (P-Asserted-Identity). I suggest to have a paragrap= h to highlight this point.

-Section 6:
calling party number / calling party address


Best regards,
Marianne


_________________________________________________________________= ________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--089e011600022f770205454c9b02-- From nobody Wed Jan 4 15:09:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 606FA1297DE for ; Wed, 4 Jan 2017 15:08:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hq1Em1u2CsnX for ; Wed, 4 Jan 2017 15:08:56 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B1E127076 for ; Wed, 4 Jan 2017 15:08:56 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v04N8t2b001514; Wed, 4 Jan 2017 23:08:55 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0047.outbound.protection.outlook.com [23.103.198.47]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4gu26c7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Jan 2017 23:08:54 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q3k+zDPpqONzYe/9Wm9vqxZL09yafnFF5QisCE/K6SE=; b=EwR4+IpK483xZbrLgbmx1rEYDeKpty2vKqrTdKPf7ET3IkW17EtLwhF+fVVg8pz2XFp1NacWrFA/adHi1N14juXiIz5rezBQm6YrfA4kxsOfkbGmAF6xzsYU6nJRPysQXEYMBVm5m2dSbd+C5Xxkb5OvFrBuQ+mKQ3/rapAdt0c= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Wed, 4 Jan 2017 23:08:52 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Wed, 4 Jan 2017 23:08:52 +0000 From: Henning Schulzrinne To: Ranjit Avasarala , "marianne.mohali@orange.com" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 - related draft - https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00 Thread-Index: AQHSZtzrfVSFHOEpJk2UOQ4NKBqomKEo7XuA Date: Wed, 4 Jan 2017 23:08:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 2873f106-c3fb-4514-d8fc-08d434f6a62e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:DNJdnDjeMqppDprt0E4zwoxdODtyXq0gbON9pQ9vn4/6rVIhwWs9af5kOG1iryPyCO7bNQMpu6mUon21hF9BgvZ7iWbeByCNtkxtkzUjDHPQP9wCzHDU/ZxLZiMuT4Aa6cnm74yv9f22Jsj3L1+/CL0G8Gb4kzmtlbvVY9PLhsSquJS2qHH0AzSq8YzSXg3jdxJlcmQBByyqVvlJ+A8HctSzUwbbigGF4r/wZqm93c0s10GJLI3qHvjqbwgMtlZjN1WxlO7CY+deiFvVODqFs+lWVewfLxykbOL882WNPOWIGqWppYBBOVoaaEJHBr6V0ReYAY/48Hs2o7pCf+MBEN1rCmECw+fh0UOYdx65p7uhHVX0n56ad1VVZd7Ulc9/TYKUMJth7BZJjnHDiMilvYCdG0iCOKZT7euSFxz/YGPFjYbcjGRHbyYyLphNnY+mhkLjZh1+qrG6kMXB6LlXaA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0177904E6B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(377454003)(189002)(24454002)(6116002)(229853002)(50986999)(230783001)(6436002)(3846002)(97736004)(9686002)(2906002)(5890100001)(5001770100001)(5660300001)(4326007)(25786008)(2900100001)(8936002)(790700001)(66066001)(54896002)(74316002)(76176999)(106356001)(122556002)(2950100002)(3660700001)(19609705001)(7906003)(81166006)(105586002)(101416001)(54356999)(6306002)(606005)(92566002)(8676002)(7736002)(7696004)(2501003)(68736007)(33656002)(55016002)(77096006)(102836003)(81156014)(39060400001)(3280700002)(99286003)(38730400001)(6506006)(86362001)(189998001)(106116001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634D172E3E1B31FD604EBA9EA610CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jan 2017 23:08:51.7687 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-04_18:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 - related draft - https://tools.ietf.org/html/draft-avasarala-sipping-reason-header-dynamic-icb-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 23:08:59 -0000 --_000_CY1PR09MB0634D172E3E1B31FD604EBA9EA610CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TXkgcmVhc29uaW5nIGlzIGluIGFuYWxvZ3kgd2l0aCBzcGFtIGZpbHRlcmluZyBmb3IgZW1haWwu IEkgZG9u4oCZdCB0aGluayBvZiBhbnkgZWZmZWN0cyBvZiBhIDY2NiByZXNwb25zZSBhcyBiZWlu ZyBlaXRoZXIgdGVtcG9yYXJ5IG9yIHBlcm1hbmVudC4gSWYgdGhlIHJlc3BvbnNlIGNvbnRyaWJ1 dGVzIHRvIGxpc3RpbmcgaXQgb24gYSBibGFjayBsaXN0IG9mIHNvbWUgc29ydCwgdGhlIGJsYWNr IGxpc3RlciBtaWdodCBtb25pdG9yIG90aGVyIHNvdXJjZXMgb2YgaW5mb3JtYXRpb24gKGUuZy4s IG51bWJlciBwb3J0aW5nIGluZm9ybWF0aW9uKSBhbmQgcmVtb3ZlIHRoZSBudW1iZXIgZnJvbSB0 aGUgbGlzdCB3aGVuIHRoZSBob2xkZXIgb2YgdGhlIG51bWJlciBoYXMgY2hhbmdlZC4gT3Igc29t ZSBtYXkgZGVjaWRlIHRoYXQgaWYgbm8gY2FsbGVyIHVzZXMgdGhlIG51bWJlciBhbnltb3JlLCB0 aGF0IHJlbW92aW5nIGl0IGZyb20gdGhlIGxpc3QgaXMgYSBnb29kIGlkZWEgKHRvIGxpbWl0IHRo ZSBkYW1hZ2UgaWYgcG9ydGluZyBhbmQgcmUtYXNzaWdubWVudCBjYW5ub3QgYmUgYWNjdXJhdGVs eSB0cmFja2VkKS4gT3IsIGFzIGZvciBlbWFpbCwgdGhlcmUgbWF5IGJlIG1lY2hhbmlzbXMgZm9y IHRoZSBudW1iZXIgaG9sZGVyIHRvIGdldCBvZmYgdGhlIGxpc3QuIFRodXMsIGluIG1hbnkgY2Fz ZXMsIHRoaXMgaXMgYm90aCwgYnV0IG5vdCBkcml2ZW4gYnkgYW4gaW5kaWNhdGlvbiBmcm9tIHRo ZSBjYWxsZWQgcGFydHksIGJ1dCBhZGRpdGlvbmFsIG91dHNpZGUgaW5mb3JtYXRpb24gb3IgaGV1 cmlzdGljcyB0aGF0IGFyZSBiZXlvbmQgc3RhbmRhcmRpemF0aW9uLg0KDQpJbiBhZGRpdGlvbiwg YXMgZGlzY3Vzc2VkLCBpbiBtYW55IGNhc2VzLCBhbnkgY3Jvd2Qtc291cmNlZCDigJxibGFja+KA nSBsaXN0IG1heSBoYXZlIG1hbnkgc2hhZGVzIG9mIGdyYXksIGZyb20gZmxhZ2dpbmcgdGhlIGNh bGwgKOKAnHBvc3NpYmxlIHNwYW3igJ0pIHRvIENBUFRDSEEtbGlrZSBtZWNoYW5pc21zICjigJxw cmVzcyA3IGlmIHlvdSBhcmUgYSBodW1hbuKAnSkgdG8gcmVkaXJlY3Rpb24gdG8gdm9pY2VtYWls IHRvIG91dHJpZ2h0IGNhbGwgcmVqZWN0aW9uLiBOdW1iZXJzIG1heSBldmVuIOKAnGZhZGXigJ0g ZnJvbSBibGFjayB0byBncmF5IHRvIHdoaXRlIG92ZXIgdGltZSwgb3Ig4oCcZGFya2Vu4oCdIGFz IG1vcmUgaW5mb3JtYXRpb24gYmVjb21lcyBrbm93bi4NCg0KSSBhZG1pdCB0aGF0IEkgZG9u4oCZ dCB0aGluayB0aGF0IGhhdmluZyB1c2VycyBzcGVjaWZ5IHRpbWUgZHVyYXRpb25zIGlzIGxpa2Vs eSB0byBiZSBoZWxwZnVsLiBBdCBiZXN0LCB0aGlzIGNvbW1pbmdsZXMg4oCcZG8gbm90IGRpc3R1 cmLigJ0gZmVhdHVyZXMgKHdoaWNoIHdlIGFscmVhZHkgaGF2ZSwgdmlhIFJldHJ5LUFmdGVyIGFu ZCB2YXJpb3VzIDR4eC82eHggY29kZXMsIHN1Y2ggYXMgNDg2IGFuZCA2MDApIHdpdGggdGhlIGtp bmQgb2Yg4oCcc3RvcCBhbm5veWluZyBtZeKAnSB0aGF04oCZcyBpbXBsaWVkIGluIHRoaXMgZHJh ZnQuDQoNCkhlbm5pbmcNCg0KRnJvbTogc2lwY29yZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJhbmppdCBBdmFzYXJhbGENClNlbnQ6IFdlZG5lc2RheSwg SmFudWFyeSAwNCwgMjAxNyA1OjUwIFBNDQpUbzogbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20N CkNjOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9u IGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDEgLSByZWxhdGVkIGRyYWZ0IC0g aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF2YXNhcmFsYS1zaXBwaW5nLXJlYXNv bi1oZWFkZXItZHluYW1pYy1pY2ItMDANCg0KSGkNClNvbWV0aW1lIEkgaGFkIHN1Ym1pdHRlZCBh biBJLUQgYmFzZWQgb24gYSBzaW1pbGFyIGlkZWEgLSB0byBibG9jayBhIHBhcnRpY3VsYXIgY2Fs bGVyIGVpdGhlciB0ZW1wb3JhcmlseSBvciBwZXJtYW5lbnRseSAtICBodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtYXZhc2FyYWxhLXNpcHBpbmctcmVhc29uLWhlYWRlci1keW5hbWlj LWljYi0wMA0KPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGF2YXNhcmFsYS0yRHNpcHBpbmctMkRy ZWFzb24tMkRoZWFkZXItMkRkeW5hbWljLTJEaWNiLTJEMDAmZD1EZ01GYVEmYz15MGgwb21DZTBq QVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1LNTlS RSZtPS15NkFDOFU2VHBnN1llcXo2ZS1qR28tWHYxdmhwTzVjTWRkdTVDSEJZMjAmcz1qcmduTGZM NUcwUTFkZWdxVjN6Z2N2ODcwWHZDWHdybFVLV3Zwa1d4c2dBJmU9Pg0KSGVyZSB0aGUgU0lQIFJl YXNvbiBoZWFkZXIgd291bGQgYmUgYXBwZW5kZWQgdG8gdGhlIEJZRSByZXF1ZXN0Lg0KTm93IHVz aW5nIDY2NiByZXNwb25zZSBjb2RlIC0gaXMgdGhlIGJsb2NrIHBlcm1hbmVudCBvciB0aW1lIGJh c2VkPw0KUmVnYXJkcw0KUmFuaml0DQoNCk9uIFdlZCwgSmFuIDQsIDIwMTcgYXQgNDozNSBQTSwg PG1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tPG1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3Jhbmdl LmNvbT4+IHdyb3RlOg0KSGksDQoNCkkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzIG9uIHYw MToNCg0KLVNlY3Rpb24gNCAtIDRyZCBwYXJhZ3JhcGg6DQogICAgICAgIFRoZSBhY3Rpb25zIGRl c2NyaWJlZCBoZXJlIGRvIG5vdCBkZXBlbmQgb24gdGhlIG5hdHVyZSBvZiB0aGUgU0lQDQogICAg ICAgIFVSSSwgZS5nLiwgd2hldGhlciBpdCBkZXNjcmliZXMgYSB0ZWxlcGhvbmUgbnVtYmVyIG9y IG5vdA0KYnV0IGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudCBvbmx5IHRlbGVwaG9uZSBudW1i ZXJzIGFyZSBtZW50aW9uZWQuIEl0IHdvdWxkIGJlIGdvb2QgdG8gcmVmbGVjdCB0aGlzIGJ5IHVz aW5nICJ0ZWxlcGhvbmUgbnVtYmVyIG9yIGFkZHJlc3MiPw0KDQotU2VjdGlvbiA0IC0gbGFzdCBw YXJhZ3JhcGg6DQogICAgICAgIFdlIGRlZmluZSBhIFNJUCBmZWF0dXJlLWNhcGFiaWxpdHkgW1JG QzY4MDldLCBzaXAuNjY2LCB0aGF0IGFsbG93cw0KICAgICAgICB0aGUgcmVnaXN0cmFyIHRvIGlu ZGljYXRlIHRoYXQgdGhlIGNvcnJlc3BvbmRpbmcgcHJveHkgc3VwcG9ydHMgdGhpcw0KICAgICAg ICBwYXJ0aWN1bGFyIHJlc3BvbnNlIGNvZGUuDQpJIHdvdWxkIHN1Z2dlc3Q6ICJUaGlzIGRvY3Vt ZW50IGRlZmluZXMgYSBuZXcgU0lQIGZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0b3IgW1JGQzY4 MDldIHZhbHVlLCBzaXAuNjY2LCB0aGF0IC4uLg0KDQotU2VjdGlvbiA0IGdlbmVyYWw6DQpJTU8s IGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIHBhcmFncmFwaCBhZGRyZXNzaW5nIHRoZSBxdWVz dGlvbiBvZiB0aGUgImNhbGxpbmcgcGFydHkgbnVtYmVyIiAobWVudGlvbmVkIHNldmVyYWwgdGlt ZSBpbiB0aGUgZG9jdW1lbnQpOiBpbmRlZWQsIHRoaXMgY2FsbGluZyBwYXJ0eSBudW1iZXIgY2Fu IGJlIGlkZW50aWZpZWQgYnkgdGhlIHRlbGVwaG9uZSBudW1iZXIvYWRkcmVzcyBpbiB0aGUgRnJv bSBoZWFkZXIgb3IgdGhlIG9uZSBpbiB0aGUgUC1Bc3NlcnRlZC1JZGVudGl0eSBoZWFkZXIgdGhh dCBtYXkgYmUgZGlmZmVyZW50LiBEZXBlbmRpbmcgb24gdGhlIG9uZSBkaXNwbGF5ZWQgdG8gdGhl IGNhbGxlZCBVQSwgdGhlIDY2NiBjb3VsZCBjb25jZXJuIG9ubHkgb25lIG9yIGJvdGggYWRkcmVz c2VzIGRlcGVuZGluZyBvbiBzZXJ2aWNlIHByb3ZpZGVyIGNob2ljZXMuIElmIHdlIHRha2UgdGhl IGV4YW1wbGUgb2YgYSBjYWxsLWNlbnRlciBvciBhbiBJUEJYIGhhdmluZyB0aGUgaGVhZCBudW1i ZXIgYW5kIGEgcmFuZ2Ugb2YgcHJpdmF0ZSBudW1iZXJzLCB0aGUgc2VydmljZSBwcm92aWRlciBj b3VsZCBpbnRlcnByZXQgdGhlIDY2NiBmcm9tIHRoZSBjYWxsZWQgdXNlciBvbmx5IGZvciB0aGUg cHJpdmF0ZSBudW1iZXIgKGluIHRoZSBGcm9tIGhlYWRlcikgb3IgZm9yIHRoZSB3aG9sZSBwb29s IChQLUFzc2VydGVkLUlkZW50aXR5KS4gSSBzdWdnZXN0IHRvIGhhdmUgYSBwYXJhZ3JhcGggdG8g aGlnaGxpZ2h0IHRoaXMgcG9pbnQuDQoNCi1TZWN0aW9uIDY6DQpjYWxsaW5nIHBhcnR5IG51bWJl ciAvIGNhbGxpbmcgcGFydHkgYWRkcmVzcw0KDQoNCkJlc3QgcmVnYXJkcywNCk1hcmlhbm5lDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmMNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVz IHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJl dXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBh aW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBl dGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Ow0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNv cGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBj aGFuZ2VkIG9yIGZhbHNpZmllZC4NClRoYW5rIHlvdS4NCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29y ZSZkPURnTUZhUSZjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1YwUmVY OGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJm09LXk2QUM4VTZUcGc3WWVxejZlLWpHby1YdjF2aHBP NWNNZGR1NUNIQlkyMCZzPWNocmM1Z0tyZTlWVjY4Y2R6eWVsR1BGTVp0QzJBQkhWbWRsVXhZYUFa RDQmZT0+DQoNCg== --_000_CY1PR09MB0634D172E3E1B31FD604EBA9EA610CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+TXkgcmVhc29uaW5nIGlzIGluIGFuYWxvZ3kgd2l0aCBzcGFtIGZpbHRlcmlu ZyBmb3IgZW1haWwuIEkgZG9u4oCZdCB0aGluayBvZiBhbnkgZWZmZWN0cyBvZiBhIDY2NiByZXNw b25zZSBhcyBiZWluZyBlaXRoZXIgdGVtcG9yYXJ5IG9yIHBlcm1hbmVudC4gSWYgdGhlIHJlc3Bv bnNlDQogY29udHJpYnV0ZXMgdG8gbGlzdGluZyBpdCBvbiBhIGJsYWNrIGxpc3Qgb2Ygc29tZSBz b3J0LCB0aGUgYmxhY2sgbGlzdGVyIG1pZ2h0IG1vbml0b3Igb3RoZXIgc291cmNlcyBvZiBpbmZv cm1hdGlvbiAoZS5nLiwgbnVtYmVyIHBvcnRpbmcgaW5mb3JtYXRpb24pIGFuZCByZW1vdmUgdGhl IG51bWJlciBmcm9tIHRoZSBsaXN0IHdoZW4gdGhlIGhvbGRlciBvZiB0aGUgbnVtYmVyIGhhcyBj aGFuZ2VkLiBPciBzb21lIG1heSBkZWNpZGUgdGhhdCBpZg0KIG5vIGNhbGxlciB1c2VzIHRoZSBu dW1iZXIgYW55bW9yZSwgdGhhdCByZW1vdmluZyBpdCBmcm9tIHRoZSBsaXN0IGlzIGEgZ29vZCBp ZGVhICh0byBsaW1pdCB0aGUgZGFtYWdlIGlmIHBvcnRpbmcgYW5kIHJlLWFzc2lnbm1lbnQgY2Fu bm90IGJlIGFjY3VyYXRlbHkgdHJhY2tlZCkuIE9yLCBhcyBmb3IgZW1haWwsIHRoZXJlIG1heSBi ZSBtZWNoYW5pc21zIGZvciB0aGUgbnVtYmVyIGhvbGRlciB0byBnZXQgb2ZmIHRoZSBsaXN0LiBU aHVzLCBpbg0KIG1hbnkgY2FzZXMsIHRoaXMgaXMgYm90aCwgYnV0IG5vdCBkcml2ZW4gYnkgYW4g aW5kaWNhdGlvbiBmcm9tIHRoZSBjYWxsZWQgcGFydHksIGJ1dCBhZGRpdGlvbmFsIG91dHNpZGUg aW5mb3JtYXRpb24gb3IgaGV1cmlzdGljcyB0aGF0IGFyZSBiZXlvbmQgc3RhbmRhcmRpemF0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SW4gYWRkaXRpb24s IGFzIGRpc2N1c3NlZCwgaW4gbWFueSBjYXNlcywgYW55IGNyb3dkLXNvdXJjZWQg4oCcYmxhY2vi gJ0gbGlzdCBtYXkgaGF2ZSBtYW55IHNoYWRlcyBvZiBncmF5LCBmcm9tIGZsYWdnaW5nIHRoZSBj YWxsICjigJxwb3NzaWJsZSBzcGFt4oCdKSB0byBDQVBUQ0hBLWxpa2UNCiBtZWNoYW5pc21zICji gJxwcmVzcyA3IGlmIHlvdSBhcmUgYSBodW1hbuKAnSkgdG8gcmVkaXJlY3Rpb24gdG8gdm9pY2Vt YWlsIHRvIG91dHJpZ2h0IGNhbGwgcmVqZWN0aW9uLiBOdW1iZXJzIG1heSBldmVuIOKAnGZhZGXi gJ0gZnJvbSBibGFjayB0byBncmF5IHRvIHdoaXRlIG92ZXIgdGltZSwgb3Ig4oCcZGFya2Vu4oCd IGFzIG1vcmUgaW5mb3JtYXRpb24gYmVjb21lcyBrbm93bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYWRtaXQgdGhhdCBJIGRvbuKAmXQgdGhpbmsgdGhhdCBo YXZpbmcgdXNlcnMgc3BlY2lmeSB0aW1lIGR1cmF0aW9ucyBpcyBsaWtlbHkgdG8gYmUgaGVscGZ1 bC4gQXQgYmVzdCwgdGhpcyBjb21taW5nbGVzIOKAnGRvIG5vdCBkaXN0dXJi4oCdIGZlYXR1cmVz ICh3aGljaCB3ZSBhbHJlYWR5DQogaGF2ZSwgdmlhIFJldHJ5LUFmdGVyIGFuZCB2YXJpb3VzIDR4 eC82eHggY29kZXMsIHN1Y2ggYXMgNDg2IGFuZCA2MDApIHdpdGggdGhlIGtpbmQgb2Yg4oCcc3Rv cCBhbm5veWluZyBtZeKAnSB0aGF04oCZcyBpbXBsaWVkIGluIHRoaXMgZHJhZnQuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IZW5uaW5nPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNpcGNv cmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9i PlJhbmppdCBBdmFzYXJhbGE8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDA0 LCAyMDE3IDU6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IG1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29t PGJyPg0KPGI+Q2M6PC9iPiBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRl ZC0wMSAtIHJlbGF0ZWQgZHJhZnQgLSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt YXZhc2FyYWxhLXNpcHBpbmctcmVhc29uLWhlYWRlci1keW5hbWljLWljYi0wMDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvbWV0aW1lIEkgaGFkIHN1 Ym1pdHRlZCBhbiBJLUQgYmFzZWQgb24gYSBzaW1pbGFyIGlkZWEgLSB0byBibG9jayBhIHBhcnRp Y3VsYXIgY2FsbGVyIGVpdGhlciB0ZW1wb3JhcmlseSBvciBwZXJtYW5lbnRseSAtJm5ic3A7DQo8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRhdmFzYXJhbGEtMkRzaXBwaW5nLTJEcmVh c29uLTJEaGVhZGVyLTJEZHluYW1pYy0yRGljYi0yRDAwJmFtcDtkPURnTUZhUSZhbXA7Yz15MGgw b21DZTBqQVVHcjRnQVEwMkZ3JmFtcDtyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERVMVhlSElZUkhm YXJwazRNSzU5UkUmYW1wO209LXk2QUM4VTZUcGc3WWVxejZlLWpHby1YdjF2aHBPNWNNZGR1NUNI QlkyMCZhbXA7cz1qcmduTGZMNUcwUTFkZWdxVjN6Z2N2ODcwWHZDWHdybFVLV3Zwa1d4c2dBJmFt cDtlPSI+DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXZhc2FyYWxhLXNpcHBp bmctcmVhc29uLWhlYWRlci1keW5hbWljLWljYi0wMDxicj4NCjwvYT48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+SGVyZSB0aGUgU0lQIFJlYXNvbiBoZWFkZXIgd291bGQgYmUgYXBwZW5kZWQgdG8g dGhlIEJZRSByZXF1ZXN0LiZuYnNwOyZuYnNwOw0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk5v dyB1c2luZyA2NjYgcmVzcG9uc2UgY29kZSAtIGlzIHRoZSBibG9jayBwZXJtYW5lbnQgb3IgdGlt ZSBiYXNlZD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlJlZ2FyZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJhbmppdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIEphbiA0LCAyMDE3IGF0IDQ6MzUgUE0sICZsdDs8YSBocmVmPSJt YWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJpYW5u ZS5tb2hhbGlAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxicj4NCjxicj4NCkkgaGF2ZSB0aGUgZm9s bG93aW5nIGNvbW1lbnRzIG9uIHYwMTo8YnI+DQo8YnI+DQotU2VjdGlvbiA0IC0gNHJkIHBhcmFn cmFwaDo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVGhlIGFjdGlvbnMgZGVzY3Jp YmVkIGhlcmUgZG8gbm90IGRlcGVuZCBvbiB0aGUgbmF0dXJlIG9mIHRoZSBTSVA8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgVVJJLCBlLmcuLCB3aGV0aGVyIGl0IGRlc2NyaWJlcyBh IHRlbGVwaG9uZSBudW1iZXIgb3Igbm90PGJyPg0KYnV0IGluIHRoZSByZXN0IG9mIHRoZSBkb2N1 bWVudCBvbmx5IHRlbGVwaG9uZSBudW1iZXJzIGFyZSBtZW50aW9uZWQuIEl0IHdvdWxkIGJlIGdv b2QgdG8gcmVmbGVjdCB0aGlzIGJ5IHVzaW5nICZxdW90O3RlbGVwaG9uZSBudW1iZXIgb3IgYWRk cmVzcyZxdW90Oz88YnI+DQo8YnI+DQotU2VjdGlvbiA0IC0gbGFzdCBwYXJhZ3JhcGg6PGJyPg0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFdlIGRlZmluZSBhIFNJUCBmZWF0dXJlLWNhcGFi aWxpdHkgW1JGQzY4MDldLCBzaXAuNjY2LCB0aGF0IGFsbG93czxicj4NCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyB0aGUgcmVnaXN0cmFyIHRvIGluZGljYXRlIHRoYXQgdGhlIGNvcnJlc3Bv bmRpbmcgcHJveHkgc3VwcG9ydHMgdGhpczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBwYXJ0aWN1bGFyIHJlc3BvbnNlIGNvZGUuPGJyPg0KSSB3b3VsZCBzdWdnZXN0OiAmcXVvdDtU aGlzIGRvY3VtZW50IGRlZmluZXMgYSBuZXcgU0lQIGZlYXR1cmUtY2FwYWJpbGl0eSBpbmRpY2F0 b3IgW1JGQzY4MDldIHZhbHVlLCBzaXAuNjY2LCB0aGF0IC4uLjxicj4NCjxicj4NCi1TZWN0aW9u IDQgZ2VuZXJhbDo8YnI+DQpJTU8sIGl0IHdvdWxkIGJlIGdvb2QgdG8gaGF2ZSBhIHBhcmFncmFw aCBhZGRyZXNzaW5nIHRoZSBxdWVzdGlvbiBvZiB0aGUgJnF1b3Q7Y2FsbGluZyBwYXJ0eSBudW1i ZXImcXVvdDsgKG1lbnRpb25lZCBzZXZlcmFsIHRpbWUgaW4gdGhlIGRvY3VtZW50KTogaW5kZWVk LCB0aGlzIGNhbGxpbmcgcGFydHkgbnVtYmVyIGNhbiBiZSBpZGVudGlmaWVkIGJ5IHRoZSB0ZWxl cGhvbmUgbnVtYmVyL2FkZHJlc3MgaW4gdGhlIEZyb20gaGVhZGVyIG9yIHRoZSBvbmUgaW4gdGhl DQogUC1Bc3NlcnRlZC1JZGVudGl0eSBoZWFkZXIgdGhhdCBtYXkgYmUgZGlmZmVyZW50LiBEZXBl bmRpbmcgb24gdGhlIG9uZSBkaXNwbGF5ZWQgdG8gdGhlIGNhbGxlZCBVQSwgdGhlIDY2NiBjb3Vs ZCBjb25jZXJuIG9ubHkgb25lIG9yIGJvdGggYWRkcmVzc2VzIGRlcGVuZGluZyBvbiBzZXJ2aWNl IHByb3ZpZGVyIGNob2ljZXMuIElmIHdlIHRha2UgdGhlIGV4YW1wbGUgb2YgYSBjYWxsLWNlbnRl ciBvciBhbiBJUEJYIGhhdmluZyB0aGUgaGVhZCBudW1iZXINCiBhbmQgYSByYW5nZSBvZiBwcml2 YXRlIG51bWJlcnMsIHRoZSBzZXJ2aWNlIHByb3ZpZGVyIGNvdWxkIGludGVycHJldCB0aGUgNjY2 IGZyb20gdGhlIGNhbGxlZCB1c2VyIG9ubHkgZm9yIHRoZSBwcml2YXRlIG51bWJlciAoaW4gdGhl IEZyb20gaGVhZGVyKSBvciBmb3IgdGhlIHdob2xlIHBvb2wgKFAtQXNzZXJ0ZWQtSWRlbnRpdHkp LiBJIHN1Z2dlc3QgdG8gaGF2ZSBhIHBhcmFncmFwaCB0byBoaWdobGlnaHQgdGhpcyBwb2ludC48 YnI+DQo8YnI+DQotU2VjdGlvbiA2Ojxicj4NCmNhbGxpbmcgcGFydHkgbnVtYmVyIC8gY2FsbGlu ZyBwYXJ0eSBhZGRyZXNzPGJyPg0KPGJyPg0KPGJyPg0KQmVzdCByZWdhcmRzLDxicj4NCk1hcmlh bm5lPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCjxicj4NCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxicj4NCnBhcyBldHJl IGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3Vz IGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPGJy Pg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiw8YnI+DQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPGJyPg0KPGJy Pg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzs8YnI+DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy48YnI+DQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuPGJyPg0KVGhhbmsgeW91Ljxicj4NCjxicj4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBp ZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NpcGNv cmUmYW1wO2Q9RGdNRmFRJmFtcDtjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmYW1wO3I9RkpjVm9E a1dNNUVpVmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZhbXA7bT0teTZBQzhVNlRwZzdZ ZXF6NmUtakdvLVh2MXZocE81Y01kZHU1Q0hCWTIwJmFtcDtzPWNocmM1Z0tyZTlWVjY4Y2R6eWVs R1BGTVp0QzJBQkhWbWRsVXhZYUFaRDQmYW1wO2U9IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR09MB0634D172E3E1B31FD604EBA9EA610CY1PR09MB0634namp_-- From nobody Wed Jan 4 16:51:26 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70291294A5 for ; Wed, 4 Jan 2017 16:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvpUf1B1Np4a for ; Wed, 4 Jan 2017 16:51:22 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 716F01294B0 for ; Wed, 4 Jan 2017 16:51:22 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-08v.sys.comcast.net with SMTP id OwGTcGqFPwySVOwH2cZLEI; Thu, 05 Jan 2017 00:51:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483577480; bh=Ro6odzJoUd9YbZux2XjMXmPsMEYzwvo/zQ7XaEnP2ZU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=Ny4ZKuPwsnK25qAkZFFimVYZwtRF9knMpnquccasIoRRyLODzeHbs91dPAnFkS3cV +ywkN9czDpvK4zAX8iZWAfb4q8h9raKxaIRYBqPMR4nEA/KBMYuCnPvdokLpBp9ZVm Xpupi3f6g8ipCNe2KHEqOMwaeg5gb21lqZby8r9FjR2oBjiyRqHkG08G3kGjMGXdem XJllSp/6XnnWDMPUXWNfSzf6YMEC5W2wXfjw8MpUcMZlzrbq3NTA+oZCfpMjmt1aT5 KoNXBB6jrklGvbwz4eGpT6Cx+PyNptgLQNfueMQGt2aB5D5XAZGs6m5oWWhEQsmgv9 Ba6mn0FLvPmmA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-10v.sys.comcast.net with SMTP id OwH2clC0omfxVOwH2cl8ar; Thu, 05 Jan 2017 00:51:21 +0000 To: sipcore@ietf.org References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> From: Paul Kyzivat Message-ID: <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> Date: Wed, 4 Jan 2017 19:51:20 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJadPTtoQvkjYahczpjcRLRvrpprm9gHmYICrirpkwY/mYgW6VDq2SKLIXKVC/uB38GOWtskhh+V45RQVHF6YTzOVbrOyufGM1gO+PZswx8Bngbz9tmo yM+IhQgw0rahMxtpNjlMeH2RsSOAQx/+/218+llGbppPm/ngzadAr6+AJBPdCD/jDkU8P+HH6GY8Xw== Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 00:51:25 -0000 On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > -Section 4 general: > IMO, it would be good to have a paragraph addressing the question of > the "calling party number" (mentioned several time in the document): > indeed, this calling party number can be identified by the telephone > number/address in the From header or the one in the P-Asserted-Identity > header that may be different. Depending on the one displayed to the > called UA, the 666 could concern only one or both addresses depending > on service provider choices. If we take the example of a call-center or > an IPBX having the head number and a range of private numbers, the > service provider could interpret the 666 from the called user only for > the private number (in the From header) or for the whole pool > (P-Asserted-Identity). I suggest to have a paragraph to highlight this > point. Interesting point. If the PAID is different from the number displayed to the callee, and the callee rejects the call without answering, how should "blame" be assigned? From the calllee's perspective the complaint is *about* the number he saw, regardless of what the identity of the actual caller was. Thanks, Paul From nobody Wed Jan 4 17:09:31 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3334012943B for ; Wed, 4 Jan 2017 17:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sglxhRlgn-qy for ; Wed, 4 Jan 2017 17:09:28 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F32D51270B4 for ; Wed, 4 Jan 2017 17:09:27 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D136D49E6296; Thu, 5 Jan 2017 01:09:25 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0519PLb012928 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2017 01:09:25 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id v0519FrJ006207 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jan 2017 01:09:23 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 02:09:18 +0100 From: "Drage, Keith (Nokia - GB)" To: Henning Schulzrinne , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZtkQiZgDsN6Pw0OK9+FGPHB/yaEo2OuAgAA12zA= Date: Thu, 5 Jan 2017 01:09:17 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 01:09:30 -0000 I do think the document should be clear as to whether there is consistent b= ehaviour on reception of this response code for all methods, or whether it = only applies to a subset (and treated as a 600 response in other methods). I think this is needed so that the end user knows the impact of generating = this response code in the first place. Obviously the actual impacts on a receiving SIP entity are pretty much info= rmational if specified at all, but I think we should know where those impac= ts are applied, be it only MESSAGE, BYE and INVITE, as the current introduc= tion would apply, or to SUBSCRIBE as well, or indeed to any other dialog fo= rming or stand alone transactions.=20 Further if it does appear in a subsequent transaction within a dialog what = is the action by the receiver in terms of dialog handling (unless we want t= o preclude it from subsequent transactions). Is it already covered by RFC 5= 057. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: 04 January 2017 22:41 To: Paul Kyzivat ; sipcore@ietf.org Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-u= nwanted-01.txt Interesting corner case. Do you have a particular use case in mind? Would t= his be a consumer (subscriber) SUBSCRIBEing to a particular event and then = not liking the NOTIFYs that follow? In general, my sense is that we haven't been terribly specific about status= code usage, except where the code had a very specific and narrow scope (e.= g., on geolocation or resource-priority), and even there we have largely le= ft the method question open, even if the examples or text implied usage wit= h a small subset. For example, most of the status codes defined in 3261 pro= bably never appear in response to a BYE (or CANCEL or OPTIONS). Thus, I won= der if simply having an escape clause similar to the job description "and o= ther duties as assigned" avoids getting into the corner cases. Since an ent= ity getting a 666 acts on it like any 6xx status, in general, there shouldn= 't be interoperability issues. If you return 666 in response to a CANCEL (n= ot in a Reason), you shouldn't expect anything interesting to happen. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Wednesday, January 04, 2017 5:22 PM To: sipcore@ietf.org Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-u= nwanted-01.txt I reviewed this latest version. IMO it has covered all the concerns I had. = I have one new thought about it: Given the discussion that has occurred, it does seem like 666 might validly= be used with other dialog-establishing requests - notably SUBSCRIBE. In th= at case, it is possible that the SUBSCRIBE itself might be accepted, and th= en the rejection indicated in-dialog. Then it wouldn't be BYE, but rather N= OTIFY that would carry the 666 as a Reason. This is a little far fetched, but I would hate to see it excluded. I don't = see anything that clearly does exclude this usage, so maybe nothing needs t= o be done. OTOH, it might be helpful to at least note that other usages, su= ch as this, are possible and not excluded. What do others think? Thanks, Paul =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed Jan 4 21:23:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D18A129A96 for ; Wed, 4 Jan 2017 21:23:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsCd33fIdsd8 for ; Wed, 4 Jan 2017 21:23:43 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A322129476 for ; Wed, 4 Jan 2017 21:23:43 -0800 (PST) Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-07v.sys.comcast.net with SMTP id P0WVcOqEq1yUhP0WccaKjf; Thu, 05 Jan 2017 05:23:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483593822; bh=C5W40Bu3k5f18tZfZzAncrWeC9ty0OIHo0lfi+w1cZw=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=QL6jCpm8QAR7XrfZXp9gas7NxgBmYJzDa4qhSo0DwMXFiWj7g/TxvWnEnAN1GiSaE gQxAvCPfiW2p2GBioi7U5mLp1emeVVxmllPFa4Lf/IGhNpgrSXYh0+YQg/U2x23jmF CFPGM/40WFJlHoWIcQs4oauAVNjsjtz9X4AT1ZZkfy0NeAl+kgRq/kuDnp03dZjr+B u4ObpJB07B5HD1F/EPJijYYkRk+taZ6HBEJ3nq/7b4Ub4W9qNXYkAOfjo65FzVpt50 taRnlBOAz83EP8rUCxuAW6ZKpZ6y7mb6kymYqNUhZvgLGtR01GZ6WCna2JdqRtlupU 6N9VVJPqilGeA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-17v.sys.comcast.net with SMTP id P0WbcXDvztSzeP0WccLTT2; Thu, 05 Jan 2017 05:23:42 +0000 To: sipcore@ietf.org References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> From: Paul Kyzivat Message-ID: Date: Thu, 5 Jan 2017 00:23:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAQ28z1xD/ryEClul+2CfUUxQ0+KhNuIdxYH1MnCel+T2MuE8yge2LyJ2N+5pTGznaxRVusxaqVWa1+SUzjJ46Zq70qp/T7tx1chwNalWOcCcWDtL4EW BNn1aK7GMxzKMiq9S4RkHdYjN7j+VPAtyzg3gQp+taUImsuDqXnW6RugUmL/A53be/mCsFZf1fRmow== Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 05:23:45 -0000 On 1/4/17 5:41 PM, Henning Schulzrinne wrote: > Interesting corner case. Do you have a particular use case in mind? Would this be a consumer (subscriber) SUBSCRIBEing to a particular event and then not liking the NOTIFYs that follow? I didn't have a particular case in mind. But thinking further... I guess this could only occur in a case where a human is somehow involved in processing the subscription. I'm not sure when that might be. > In general, my sense is that we haven't been terribly specific about status code usage, except where the code had a very specific and narrow scope (e.g., on geolocation or resource-priority), and even there we have largely left the method question open, even if the examples or text implied usage with a small subset. For example, most of the status codes defined in 3261 probably never appear in response to a BYE (or CANCEL or OPTIONS). Thus, I wonder if simply having an escape clause similar to the job description "and other duties as assigned" avoids getting into the corner cases. Since an entity getting a 666 acts on it like any 6xx status, in general, there shouldn't be interoperability issues. If you return 666 in response to a CANCEL (not in a Reason), you shouldn't expect anything interesting to happen. Agreed. Thanks, Paul > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, January 04, 2017 5:22 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt > > I reviewed this latest version. IMO it has covered all the concerns I had. I have one new thought about it: > > Given the discussion that has occurred, it does seem like 666 might validly be used with other dialog-establishing requests - notably SUBSCRIBE. In that case, it is possible that the SUBSCRIBE itself might be accepted, and then the rejection indicated in-dialog. Then it wouldn't be BYE, but rather NOTIFY that would carry the 666 as a Reason. > > This is a little far fetched, but I would hate to see it excluded. I don't see anything that clearly does exclude this usage, so maybe nothing needs to be done. OTOH, it might be helpful to at least note that other usages, such as this, are possible and not excluded. What do others think? > > Thanks, > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Thu Jan 5 01:39:08 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8991294A4 for ; Thu, 5 Jan 2017 01:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id relnKacwPFW3 for ; Thu, 5 Jan 2017 01:39:01 -0800 (PST) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7CB71204D9 for ; Thu, 5 Jan 2017 01:39:00 -0800 (PST) Received: from [85.158.136.83] by server-11.bemta-5.messagelabs.com id 8E/8E-14064-3341E685; Thu, 05 Jan 2017 09:38:59 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDKsWRWlGSWpSXmKPExsWi75nTo6svkhd hcKXb3OLnkd2sFl9/bGJzYPK4ffsNm8eSJT+ZApiiWDPzkvIrElgzdi7exl7QUlpx+EZ+A+OW 4i5GLg4hgW2MEn9//WaFcA4xSsxt38AC4RxmlLiy+BlTFyMnkDOHUeLdDcMuRg4ONgF7iRl7Y kDCIgKmEmcb37KB2MwCchLXP2wEs4UFgiQen5zBBFETLHF84it2CNtP4nr/bLA4i4CKxLkLM1 hBbF6BUIln+7ZDHbGPWeJu3zKwQZwCsRLvz05nAbEZBWQlvjSuZoZYJi5x68l8sEESAgISS/a cZ4awRSVePv7HClGTJ/HgUhcjxAJBiZMzn7BA/KIq8W/lIqYJjKKzkIyahaRlFpKWWUAvMwto SqzfpQ9RoigxpfshO4StIdE6Zy47svgCRvZVjBrFqUVlqUW6xgZ6SUWZ6RkluYmZObqGBqZ6u anFxYnpqTmJScV6yfm5mxiBsVjPwMC4g3HCKr9DjJIcTEqivNbfciOE+JLyUyozEosz4otKc1 KLDzHKcHAoSfC+FcqLEBIsSk1PrUjLzAEmBZi0BAePkgivnjBQmre4IDG3ODMdInWKUVFKnNc EJCEAksgozYNrgyWiS4yyUsK8jAwMDEI8BalFuZklqPKvGMU5GJWEeQ1ApvBk5pXATX8FtJgJ aPH2gGyQxSWJCCmpBsaA92VrrvrMuvr2Znp/8/oZbGz3eJb3+NSdZ/463f7bEjXDr7x50zQ66 q5n9fMWcqyalXFswkyhez4rs/cuvam4+e9Lzb9mXgq7U0Q4q5Xfa51bqxJ6W9dJfNNX4R61DT snJSS1KXzfU/no39d/KuxN8bfigxjZ43Y6NMc2Hnlr7MgbkP2y9YQSS3FGoqEWc1FxIgDDaJ4 EPwMAAA== X-Env-Sender: Peter.Dawes@vodafone.com X-Msg-Ref: server-16.tower-36.messagelabs.com!1483609135!80178885!2 X-Originating-IP: [47.73.108.140] X-StarScan-Received: X-StarScan-Version: 9.1.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29981 invoked from network); 5 Jan 2017 09:38:55 -0000 Received: from vgdpm14vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.140) by server-16.tower-36.messagelabs.com with AES256-SHA encrypted SMTP; 5 Jan 2017 09:38:55 -0000 Received: from VOEXH07W.internal.vodafone.com (47.73.211.205) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 5 Jan 2017 10:38:45 +0100 Received: from VOEXC04W.internal.vodafone.com (145.230.101.24) by VOEXH07W.internal.vodafone.com (47.73.211.211) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 5 Jan 2017 10:38:45 +0100 Received: from VOEXC24W.internal.vodafone.com (145.230.103.196) by VOEXC04W.internal.vodafone.com (145.230.101.24) with Microsoft SMTP Server (TLS) id 14.3.294.0; Thu, 5 Jan 2017 10:38:45 +0100 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.53]) by voexc24w ([145.230.103.196]) with mapi id 14.03.0294.000; Thu, 5 Jan 2017 10:38:44 +0100 From: "Dawes, Peter, Vodafone Group" To: Henning Schulzrinne Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSW549jON1XdNft0qMWj02oHw2Q6EmsFcwgACbjgCAAPZScIAASY6AgAEpxeA= Date: Thu, 5 Jan 2017 09:38:43 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710A@VOEXM31W.internal.vodafone.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022VOEXM31Winterna_" MIME-Version: 1.0 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 09:39:07 -0000 --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022VOEXM31Winterna_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBJIGhhdmUgcmVhZCByZXZpc2lvbiAtMDEgYW5kIG15IGNvbW1lbnRzIGFyZSByZXNv bHZlZC4gQXMgYSB3b3JkaW5nIHN1Z2dlc3Rpb24gZm9yIHRoZSBsYXN0IHBhcmFncmFwaCBpbiBz ZWN0aW9uIDYsIEkgdGhpbmsgYWRkaW5nIHRoZSB3b3JkcyDigJxvZiByZXNwb25zZSBjb2RlIDY2 NuKAnSBhcyBiZWxvdyBtYWtlcyB0aGUgbWVhbmluZyBjbGVhcmVyOg0KDQoNCuKAnEZvciBib3Ro IGluZGl2aWR1YWxseS1hdXRoZW50aWNhdGVkIGFuZCB1bmF1dGhlbnRpY2F0ZWQgY2FsbHMsDQoN CiAgIHJlY2lwaWVudHMgb2YgcmVzcG9uc2UgY29kZSA2NjYgbWF5IHdhbnQgdG8gZGlzdGluZ3Vp c2ggcmVzcG9uc2VzIHNlbnQgYmVmb3JlIGFuZCBhZnRlcg0KDQogICB0aGUgY2FsbCBoYXMgYmVl biBhbnN3ZXJlZCwgYXNjZXJ0YWluaW5nIHdoZXRoZXIgZWl0aGVyIHJlc3BvbnNlDQoNCiAgIHRp bWluZyBzdWZmZXJzIGZyb20gYSBsb3dlciBmYWxzZS1wb3NpdGl2ZSByYXRlLuKAnQ0KDQoNCg0K UmVnYXJkcywNCg0KUGV0ZXINCg0KDQoNCkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0 bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3ZdDQpTZW50OiAwNCBKYW51YXJ5IDIwMTcgMTY6 NDUNClRvOiBEYXdlcywgUGV0ZXIsIFZvZGFmb25lIEdyb3VwDQpDYzogU0lQQ09SRQ0KU3ViamVj dDogUkU6IFtzaXBjb3JlXSBBZG9wdGVkIC8gV0dMQzogZHJhZnQtc2NodWx6cmlubmUtZGlzcGF0 Y2gtc3RhdHVzLXVud2FudGVkDQoNCkkgaGF2ZSBhZGRlZCBhIG5vbi1ub3JtYXRpdmUgcmVmZXJl bmNlIHRvIFJGQyA0NDc0YmlzIGNhbm9uaWNhbGl6YXRpb24uDQoNClNpbmNlIGEgbG90IG9mIHRo ZSB3b3JkaW5nIGhhcyBiZWVuIHR3ZWFrZWQsIEkgd2lsbCBzdWJtaXQgYSBkcmFmdCBuZXcgdmVy c2lvbiBzaG9ydGx5LCBzbyB0aGF0IGV2ZXJ5b25lIGNhbiBtYWtlIHN1cmUgdGhhdCBJIGRpZG7i gJl0IG1pc3MgdGhlaXIgaW50ZW50IG9yIHN1Z2dlc3Rpb24uDQoNCkhlbm5pbmcNCg0KRnJvbTog RGF3ZXMsIFBldGVyLCBWb2RhZm9uZSBHcm91cCBbbWFpbHRvOlBldGVyLkRhd2VzQHZvZGFmb25l LmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAwNCwgMjAxNyA3OjEzIEFNDQpUbzogSGVu bmluZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PG1haWx0bzpIZW5u aW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+Pg0KQ2M6IFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtzaXBjb3JlXSBBZG9wdGVk IC8gV0dMQzogZHJhZnQtc2NodWx6cmlubmUtZGlzcGF0Y2gtc3RhdHVzLXVud2FudGVkDQoNCkkg bGlrZSB5b3VyIHN1Z2dlc3RlZCB3b3JkaW5nIOKAnFNJUCBlbnRpdGllcyBtYXkgdXNlIHRoaXMg aW5mb3JtYXRpb24gdG8gYWRqdXN0IGhvdyBmdXR1cmUgY2FsbHMgZnJvbSB0aGlzIGNhbGxpbmcg cGFydHkgYXJlIGhhbmRsZWQgZm9yIHRoZSBjYWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LuKA nSBmb3IgdGhlIEFic3RyYWN0IGNsYXVzZS4NCg0KTXkgY29uY2VybnMgYWJvdXQgdGhlIG1lYW5p bmcgb2Yg4oCcY2FsbGVy4oCdIGFyZSB0YWtlbiBjYXJlIG9mIGJ5IHRoZSByZXZpc2VkIHdvcmRp bmcgYWJvdmUgYW5kIGJ5IHRoZSBjb21tZW50IGZyb20gUGF1bCBLeXppdmF0IHRvIGNoYW5nZSB0 aGUgd29yZGluZyBpbiBTZWN0aW9uIDIgZnJvbSDigJx0aGF0IHRoZSBjYWxsZXIgaXMgdW53YW50 ZWTigJ0gdG8g4oCcIHRoYXQgY2FsbHMgZnJvbSB0aGlzIGNhbGxlciBhcmUgdW53YW50ZWQgYnkg dGhlIGNhbGxlZCBwYXJ0eS7igJ0NCg0KSSBhbSBub3QgYW4gaW1wbGVtZW50ZXIsIGJ1dCBpdCBt YWtlcyBzZW5zZSB0byBtZSB0byBwb2ludCBvdXQgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJvY2Vk dXJlIGluIFJGQzQ0NzRiaXMgU2VjdGlvbiA4LjMgdG8gdHJ5IHRvIGF2b2lkIHRoZSBzYW1lIG51 bWJlciBiZWluZyBzdG9yZWQgaW4gbXVsdGlwbGUgZm9ybWF0cy4gSSBndWVzcyBpdCBjb3VsZCBi ZSBtZW50aW9uZWQgaW4gU2VjdGlvbiA0IOKAnEJlaGF2aW9yIG9mIFNJUCBFbnRpdGllc+KAnS4N Cg0KVGhhbmtzLA0KUGV0ZXINCg0KDQo= --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022VOEXM31Winterna_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWlu VGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0K CW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QbGFpblRleHRDaGFy DQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFt ZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp ZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQg NzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5UaGFua3MsIEkgaGF2ZSByZWFkIHJldmlzaW9uIC0wMSBhbmQgbXkg Y29tbWVudHMgYXJlIHJlc29sdmVkLiBBcyBhIHdvcmRpbmcgc3VnZ2VzdGlvbiBmb3IgdGhlIGxh c3QgcGFyYWdyYXBoIGluIHNlY3Rpb24gNiwgSSB0aGluayBhZGRpbmcgdGhlIHdvcmRzIOKAnG9m IHJlc3BvbnNlIGNvZGUgNjY24oCdIGFzIGJlbG93IG1ha2VzIHRoZSBtZWFuaW5nIGNsZWFyZXI6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InBhZ2Ut YnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJw8L3NwYW4+PHNwYW4gbGFuZz0iRU4iPkZv ciBib3RoIGluZGl2aWR1YWxseS1hdXRoZW50aWNhdGVkIGFuZCB1bmF1dGhlbnRpY2F0ZWQgY2Fs bHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9y ZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgcmVjaXBpZW50cyBvZiByZXNw b25zZSBjb2RlIDY2NiBtYXkgd2FudCB0byBkaXN0aW5ndWlzaCByZXNwb25zZXMgc2VudCBiZWZv cmUgYW5kIGFmdGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgdGhlIGNhbGwg aGFzIGJlZW4gYW5zd2VyZWQsIGFzY2VydGFpbmluZyB3aGV0aGVyIGVpdGhlciByZXNwb25zZTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBsYW5nPSJFTiI+Jm5ic3A7Jm5ic3A7IHRpbWluZyBzdWZmZXJzIGZyb20gYSBs b3dlciBmYWxzZS1wb3NpdGl2ZSByYXRlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+UGV0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWst YmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVA ZmNjLmdvdl0NCjxicj4NCjxiPlNlbnQ6PC9iPiAwNCBKYW51YXJ5IDIwMTcgMTY6NDU8YnI+DQo8 Yj5Ubzo8L2I+IERhd2VzLCBQZXRlciwgVm9kYWZvbmUgR3JvdXA8YnI+DQo8Yj5DYzo8L2I+IFNJ UENPUkU8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzaXBjb3JlXSBBZG9wdGVkIC8gV0dMQzog ZHJhZnQtc2NodWx6cmlubmUtZGlzcGF0Y2gtc3RhdHVzLXVud2FudGVkPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5JIGhhdmUgYWRkZWQgYSBub24tbm9ybWF0aXZlIHJlZmVyZW5jZSB0 byBSRkMgNDQ3NGJpcyBjYW5vbmljYWxpemF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TaW5jZSBhIGxvdCBvZiB0aGUg d29yZGluZyBoYXMgYmVlbiB0d2Vha2VkLCBJIHdpbGwgc3VibWl0IGEgZHJhZnQgbmV3IHZlcnNp b24gc2hvcnRseSwgc28gdGhhdCBldmVyeW9uZSBjYW4gbWFrZSBzdXJlIHRoYXQgSSBkaWRu4oCZ dCBtaXNzIHRoZWlyIGludGVudCBvciBzdWdnZXN0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5IZW5uaW5nPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IERhd2VzLCBQ ZXRlciwgVm9kYWZvbmUgR3JvdXAgWzxhIGhyZWY9Im1haWx0bzpQZXRlci5EYXdlc0B2b2RhZm9u ZS5jb20iPm1haWx0bzpQZXRlci5EYXdlc0B2b2RhZm9uZS5jb208L2E+XQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgSmFudWFyeSAwNCwgMjAxNyA3OjEzIEFNPGJyPg0KPGI+VG86PC9i PiBIZW5uaW5nIFNjaHVsenJpbm5lICZsdDs8YSBocmVmPSJtYWlsdG86SGVubmluZy5TY2h1bHpy aW5uZUBmY2MuZ292Ij5IZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gU0lQQ09SRSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNp cGNvcmVAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NpcGNvcmVd IEFkb3B0ZWQgLyBXR0xDOiBkcmFmdC1zY2h1bHpyaW5uZS1kaXNwYXRjaC1zdGF0dXMtdW53YW50 ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5JIGxpa2UgeW91 ciBzdWdnZXN0ZWQgd29yZGluZyA8L3NwYW4+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPuKAnFNJUCBlbnRpdGllcyBtYXkgdXNlIHRoaXMgaW5mb3JtYXRpb24gdG8g YWRqdXN0IGhvdyBmdXR1cmUgY2FsbHMgZnJvbSB0aGlzIGNhbGxpbmcgcGFydHkgYXJlIGhhbmRs ZWQgZm9yIHRoZSBjYWxsZWQgcGFydHkgb3IgbW9yZSBicm9hZGx5LuKAnSBmb3IgdGhlIEFic3Ry YWN0IGNsYXVzZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+TXkgY29uY2VybnMgYWJvdXQgdGhlIG1lYW5pbmcgb2Yg4oCcY2Fs bGVy4oCdIGFyZSB0YWtlbiBjYXJlIG9mIGJ5IHRoZSByZXZpc2VkIHdvcmRpbmcgYWJvdmUgYW5k IGJ5IHRoZSBjb21tZW50IGZyb20gUGF1bCBLeXppdmF0IHRvDQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPmNoYW5nZSB0aGUgd29yZGluZyBpbiBTZWN0aW9uIDIgZnJvbSDigJx0 aGF0IHRoZSBjYWxsZXIgaXMgdW53YW50ZWTigJ0gdG8g4oCcIHRoYXQgY2FsbHMgZnJvbSB0aGlz IGNhbGxlciBhcmUgdW53YW50ZWQgYnkgdGhlIGNhbGxlZCBwYXJ0eS7igJ0NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SSBhbSBub3QgYW4gaW1wbGVtZW50ZXIsIGJ1dCBp dCBtYWtlcyBzZW5zZSB0byBtZSB0byBwb2ludCBvdXQgdGhlIGNhbm9uaWNhbGl6YXRpb24gcHJv Y2VkdXJlIGluIFJGQzQ0NzRiaXMgU2VjdGlvbiA4LjMgdG8gdHJ5IHRvIGF2b2lkIHRoZSBzYW1l IG51bWJlciBiZWluZyBzdG9yZWQgaW4gbXVsdGlwbGUgZm9ybWF0cy4gSSBndWVzcyBpdCBjb3Vs ZCBiZSBtZW50aW9uZWQNCiBpbiBTZWN0aW9uIDQg4oCcQmVoYXZpb3Igb2YgU0lQIEVudGl0aWVz 4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5QZXRlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022VOEXM31Winterna_-- From nobody Thu Jan 5 04:53:44 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BC7129500 for ; Thu, 5 Jan 2017 04:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czNO9fvm1c5h for ; Thu, 5 Jan 2017 04:53:41 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351A11293EC for ; Thu, 5 Jan 2017 04:53:41 -0800 (PST) Received: from pps.filterd (m0085114.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v05Cnw6G012920 for ; Thu, 5 Jan 2017 07:53:40 -0500 Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) by mx0b-001d8301.pphosted.com with ESMTP id 27p692b98v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 05 Jan 2017 07:53:40 -0500 Received: by mail-lf0-f71.google.com with SMTP id d16so150099570lfb.7 for ; Thu, 05 Jan 2017 04:53:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=twe4J6l7Td+V2aTkHPqUdu1tHj5QB+YuuGAkwp3wafc=; b=wRwKnPAGKoldU99OIbD5OIXzj5/Ef6qhMczg8BunBOG6iY34ruhdXJZIfrtCdKb47O BIB+UYkc8gKXZP8WSZD0/eqI5uuTZTQpPNuPyy3EpfEDXxznR5AcBhPJPMm2WrkDqFZS P87V8IROqHMUO4FXo5NLByle0llCf99KWND/SVE9shkTa8vUJrSYQAOPlCkqJ9TdCfFb R6abv0yHKRF20Veo0CjmOIRjwMCs4rqdXHZKGmk3524FfQ8DUqwuUJVH0wddAL3vRCTj 6F5KE77ZCQ3f56JXZLbSpwWUrkRDpTz3SAbmLHCDKM/b6hEa2Dy90xU9O3J6UG7IB/zf rpKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=twe4J6l7Td+V2aTkHPqUdu1tHj5QB+YuuGAkwp3wafc=; b=nrhKfIhYlu8a75iyBOG9abuEw/AOtPMuR4j7uOErqtJXp6eOR86NvnzbMYEIXD4Be5 aUcFj48ORF+9Jy77DWJewRkJeLtCcfmyqUWVi3dEhfC3oiEBpgE9T2nBDbEOxfYmEchZ CjMIcEW6g2nYAAinZDaURmVkAUxbmPwXDqAv9iQYXxuD9VTuGkdD0nL+G3G2qq+73y1D q4i/gW/B3F9h6XsoPMaY8Dl5rV6FtiChTjQBc40I5FEXjVdjVNdV3CC/PfWIOZzKaq1x GQwQuod2yx/VayFqKJTNBRahQvTyi8xLy9cHWGujeDe8LSXGOeczBe5+HSZxbFO4lnU9 q/VA== X-Gm-Message-State: AIkVDXIIjWnvSTqTqGBlhRAEuohIKJ4JBosdkHi+Nc0f3ZWhOC15hhDH3WXwsb95hC/1PFpAbH2N9DEpn+LJnkPjykSA5z/+IT+8TNXwYyjIaPFt9i4ElVq2XxsdngI2jUXtW7L8IVK8jlRs X-Received: by 10.25.56.18 with SMTP id f18mr474244lfa.164.1483620818259; Thu, 05 Jan 2017 04:53:38 -0800 (PST) X-Received: by 10.25.56.18 with SMTP id f18mr474231lfa.164.1483620817933; Thu, 05 Jan 2017 04:53:37 -0800 (PST) From: Brett Tate References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> In-Reply-To: <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpgyuovI3wswcTryY00OgOrmPmrgMSblVsoGLyttA= Date: Thu, 5 Jan 2017 07:53:36 -0500 Message-ID: To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 12:53:42 -0000 Hi, I also agree that adding such a paragraph would be useful. For instance if someone desires a service to forward all received spam calls to another set of victims, they would likely not use such a service if the forwarding party might also get flagged as part of the 666 handling. > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, January 04, 2017 7:51 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > -Section 4 general: > > IMO, it would be good to have a paragraph addressing the question of > > the "calling party number" (mentioned several time in the document): > > indeed, this calling party number can be identified by the telephone > > number/address in the From header or the one in the > > P-Asserted-Identity header that may be different. Depending on the one > > displayed to the called UA, the 666 could concern only one or both > > addresses depending on service provider choices. If we take the > > example of a call-center or an IPBX having the head number and a range > > of private numbers, the service provider could interpret the 666 from > > the called user only for the private number (in the From header) or > > for the whole pool (P-Asserted-Identity). I suggest to have a > > paragraph to highlight this point. > > Interesting point. If the PAID is different from the number displayed to the > callee, and the callee rejects the call without answering, how should "blame" > be assigned? From the calllee's perspective the complaint is *about* the > number he saw, regardless of what the identity of the actual caller was. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jan 5 05:30:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9D129450 for ; Thu, 5 Jan 2017 05:30:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gROKfgb-Sqdy for ; Thu, 5 Jan 2017 05:30:55 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F6AB129437 for ; Thu, 5 Jan 2017 05:30:55 -0800 (PST) Received: from pps.filterd (m0103510.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v05DTv2f018277 for ; Thu, 5 Jan 2017 08:30:55 -0500 Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by mx0a-001d8301.pphosted.com with ESMTP id 27pa9y2w2q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 05 Jan 2017 08:30:55 -0500 Received: by mail-lf0-f72.google.com with SMTP id l127so16876618lfl.3 for ; Thu, 05 Jan 2017 05:30:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=ICWFED5ZJ7uUG/I9AkAeZzlJZJG+kJ5e+TNjPPGF030=; b=eys77So42sHgS8MRWUbYw/FI5wkVlH/++s9QbXhwEF/GmIGRzL31rGaud81nOIHU7R Zz/+51udi5GiWJa0HQV+tQogaTRsfPABdNp5HEzsw54NUire1uH17ILjTWxIeikrtpta ioLRSAUb8EhmgXsOG9Mzj/mBKhcTzogsHEyzlgKx4Esps4DyuP0xhT57KtO5JBUiKeCe fvGhex+A3vWKQw4P6tFMCCEd6aTw3QrGfibPm4v+X68IhGZInfarhnLFrp8rsTicZOit 0z1EUxtiFlEn7v2RMOdpLQ36ruvGi6kloO4kEUDM61U8heTS49ZWRlAuGZD1YS8mSE8h sf5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=ICWFED5ZJ7uUG/I9AkAeZzlJZJG+kJ5e+TNjPPGF030=; b=GYpNM3s9BGBVvAZsVk5yKWhW97Z4FWIdQEzqGnSU9XBUITmv/ypOJB5D8HOZVN6AUZ 6PDB4a1RqyRLCpGN1mtpAQcgf5ms3gEQMMIIAdJ7GqJVUaMaIEUCi5r8mSn6m/KbN7EI p4xFc+ReKo2hm8YqMQ2Zau7G+hnj43WraCvBlV5GazcdUoLMc2q0IhR4bVGgBZHZM7tx qd7Sf9QAWE+Ubi+6Qigta4XIl8p2+TU3wKkOsesFdu+zxeHVRoQm958Qdv/gtLfPRcJ2 iHE25SP8KbAm3zITwJ5aQQb5/weNGYOectFaSaZh/J67dSONtEx6F9nEobE42N7qQ050 JxiQ== X-Gm-Message-State: AIkVDXLjLIcyZPhvPbUD1LAENutEPzWLyP7NoQk0KFoIppw2pKGrqaU5Ak+TaZn0d/I1ZN6YP3sbvevdd2hFm/CnUZdOoKEPfIg1vApYUPzwxZRWNWGdfo01Q5M9mwvYOx0wJj/1UZPquylu X-Received: by 10.25.56.18 with SMTP id f18mr537818lfa.164.1483623052456; Thu, 05 Jan 2017 05:30:52 -0800 (PST) X-Received: by 10.25.56.18 with SMTP id f18mr537810lfa.164.1483623052207; Thu, 05 Jan 2017 05:30:52 -0800 (PST) From: Brett Tate References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLWr6/Umd0J42L08fGbdPT+Ys7sSwKVRJLpArLVtFwCb+qG8wLLOoklns0xGeA= Date: Thu, 5 Jan 2017 08:30:50 -0500 Message-ID: <45a2dc35659238515f113beba22cf690@mail.gmail.com> To: "Drage, Keith (Nokia - GB)" , Henning Schulzrinne , sipcore@ietf.org Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_08:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 13:30:56 -0000 > Further if it does appear in a subsequent transaction within > a dialog what is the action by the receiver in terms of dialog > handling (unless we want to preclude it from subsequent > transactions). Is it already covered by RFC 5057. RFC 5057 does discuss 6xx handling. However since note 17 indicates "6xx unrecognized responses" and Table 1 indicates "unknown 6xx", I'm not positive if Table 2's 6xx impact (Transaction) was intended to also apply to known 6xx responses defined subsequent to RFC 5057. From nobody Thu Jan 5 06:39:24 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D2B12956E for ; Thu, 5 Jan 2017 06:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqKbWlSkRl4m for ; Thu, 5 Jan 2017 06:39:21 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1A51294C3 for ; Thu, 5 Jan 2017 06:39:21 -0800 (PST) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-11v.sys.comcast.net with SMTP id P9C7cN0oD6nWCP9CKcyaXf; Thu, 05 Jan 2017 14:39:20 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-12v.sys.comcast.net with SMTP id P9CJchqpKOYDyP9CKcYbbs; Thu, 05 Jan 2017 14:39:20 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v05EdIXU002355; Thu, 5 Jan 2017 09:39:18 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v05EdISC002352; Thu, 5 Jan 2017 09:39:18 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Henning Schulzrinne In-Reply-To: (Henning.Schulzrinne@fcc.gov) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 05 Jan 2017 09:39:18 -0500 Message-ID: <87mvf5h8q1.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGEz941WSWA55s7uAmmbF0rnaMaCcqZpBDE4C1jSjgBIyLFORQCRVoRNzo7iuO3XAwUkIrn/0sVzY7+1eCwf1owjYNkhneWB751b9JJJNeJ7RP7h50y2 S4sxB2Pk1ExhJsLfH23VILuV9fZkOfjo76rGbNZj4GQwH50OcPhtE0Hpr/Lnln6bgMoR3YKcWk2I2ByQLTRJkqA/D3woyjBDxH4= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 14:39:22 -0000 Henning Schulzrinne writes: > Interesting corner case. Do you have a particular use case in mind? > Would this be a consumer (subscriber) SUBSCRIBEing to a particular > event and then not liking the NOTIFYs that follow? The case that came immediately to mind is subscription to call-completion events -- that can be used as a way to snoop the status of a particular callee. See RFC 6910's Security Considerations and references to that within the RFC. So a 666 response code to such a SUBSCRIBE would be a sensible way to object to it as a potential privacy violation. Though now that I think about it, that response would almost certainly be generated by an automaton, not an end-user. Dale From nobody Thu Jan 5 07:19:18 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657B3129B53 for ; Thu, 5 Jan 2017 07:19:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7wNtRKbr-nZ for ; Thu, 5 Jan 2017 07:19:16 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CED1C129B51 for ; Thu, 5 Jan 2017 07:19:16 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-12v.sys.comcast.net with SMTP id P9oXcSs4on2TRP9oxco9Cu; Thu, 05 Jan 2017 15:19:15 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-03v.sys.comcast.net with SMTP id P9ovcTmbIO6NBP9oxcEt9e; Thu, 05 Jan 2017 15:19:15 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v05FJDwi006519; Thu, 5 Jan 2017 10:19:13 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v05FJDx8006514; Thu, 5 Jan 2017 10:19:13 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: In-Reply-To: <28332_1483548079_586D25AF_28332_2196_4_8B970F90C584EA4E97D5BAAC9172DBB81C890EB4@OPEXCLILMA4.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 05 Jan 2017 10:19:12 -0500 Message-ID: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMxUy5ZRmseitMNOq2dGn9nOBHIDco+fjs8yrRd8FdzqocWJojHcefq/RCmYZab2x2d+GOP3VwsYCpHlZGe7xEaa5ZU899YZtI0TAjOWBhfhBkn6hJpM 8yxkPlza7UjpoPTUehBik8b0d/u9QQN2CLGv9QfTTY7lEfPbhqRwRKndHWByIkmSWjZigJ6plKM0IkjHBb36o8zZNKb1jH3LnRc= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:19:17 -0000 writes: > I would like to submit an errata to RFC3261 on the following point: > > RFC 3261 (section 20 Table 2) states that Content-Type header is not > applicable to the CANCEL method (meaning that a CANCEL must not > contain a body). > "580 (Precondition Failure) responses and BYE and CANCEL requests, > indicating failure to meet certain preconditions, SHOULD contain an > SDP description, indicating which desired status triggered the > failure. Note that this SDP description is not an offer or an > answer, since it does not lead to the establishment of a session. > The format of such a description is based on the last SDP (an offer > or an answer) received from the remote UA." This isn't really an erratum for 3261 as a clarification that 3312 updates the table in 3261. But I remember there was a discussion some years ago about maintaining the tables in 3261 and there was some sort of decision to no longer do that, as almost every SIP RFC entailed modifying the tables. Does anyone remember the details of that discussion? Dale From nobody Thu Jan 5 07:23:04 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1582129586 for ; Thu, 5 Jan 2017 07:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyJACM8NThy4 for ; Thu, 5 Jan 2017 07:23:01 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9E2012953D for ; Thu, 5 Jan 2017 07:23:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YU/xtEO7WDF/tBHD5rUADOkZA3FhwMZ4QYLPf2g8y7Y=; b=abZCiNZbA13ivR8D+8zwBllSSMJm67P23FLNxyMBtjawE6zXWoXdSmmdekM67V5GpQaRj7jAaXjV/Tl8UgbA+maE7Bv9d+NNE4qD8d2rAG+ZtZIBhj3ah/K38DqtRPX6Y+a0dXCQw9SMfWuaivkTk5BB2DVAAwJNkNA49as3GIQ= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0177.outbound.protection.outlook.com [216.32.180.177]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-119-egPlq2WiPOysL9UEajZmhw-1; Thu, 05 Jan 2017 10:22:58 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 15:22:56 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 15:22:56 +0000 From: "Asveren, Tolga" To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AQHSZu3dGYJ0jtsz5EmPEreSyl8iJqEp15kAgAAldrA= Date: Thu, 5 Jan 2017 15:22:55 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 1160564d-ee99-49db-8b83-08d4357eb992 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:YRNe2zuzyTh+bhyYAi+dBzE3fWNU2VgNfhhNesdcZ72ZW9gULPn6C1VQl4VLc6IAACLNgRjkVB7A8ix1RvX/6c7+vas8t+oEYwDThlsKwPX3EmKqS/x87tpdNGFCyr8id+tVR5hKj9VbMPbia4xAcZNdP/mD+qVK8D8jeaNAFSjH60bxsZ8ULlYMz7IQOhfunwkfKN8azRtwl2b4mLBS43Yt2Y9dMCF38sXTYqJuWNQ+DogE/YpDB1qDEW5iHk0nRUk/lFzENjKdz2R4qRAEYDiQ5fCu4pYn2ca/N+kCohcsv4+D14fXACKGjS+TFn5m+yECNd1r1jpJBkUXrT+xT1F5VIC9AZaXkb9tTJE/eC8rCyQtMIwl/OAAHBinPVuPXFpYnMso2yWe1NK4Aqt/w7mUMeHYPQdfjBNRPmL8/YahxiSx3YbMUgV3e7Pk6mC9ZjmZgaqYD2Ugh5O5u1oU/g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(131327999870524)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(377454003)(13464003)(24454002)(199003)(3280700002)(230783001)(76176999)(6306002)(3846002)(33656002)(2950100002)(122556002)(305945005)(6506006)(106116001)(81156014)(7736002)(99286003)(25786008)(2501003)(77096006)(66066001)(106356001)(38730400001)(9686002)(7696004)(55016002)(3660700001)(102836003)(68736007)(97736004)(229853002)(2906002)(86362001)(189998001)(101416001)(105586002)(5001770100001)(54356999)(6436002)(107886002)(74316002)(50986999)(8676002)(81166006)(6116002)(92566002)(8936002)(2900100001)(5660300001)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 15:22:55.9611 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: egPlq2WiPOysL9UEajZmhw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:23:02 -0000 I agree that defining what a "call" is a good idea but I have a different t= ake on what it should say: i- A "call" in the context of this document is a communication session as = perceived by a human agent, e.g. as in "I received a call from my grandmoth= er.". It does not imply anything further as far as SIP information elements= which usually are used to carry calling party identification, e.g. P-Asser= ted-Id, From headers, are concerned. It is up to the operator/network polic= y how to make associate further calls with the information/decision derived= from unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls= from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing th= e actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 >=20 > Hi, >=20 > I also agree that adding such a paragraph would be useful. >=20 > For instance if someone desires a service to forward all received spam ca= lls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. >=20 >=20 > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller= was. > > > > =09Thanks, > > =09Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jan 5 07:37:37 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605AC12995C for ; Thu, 5 Jan 2017 07:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nsi49GTkFg-I for ; Thu, 5 Jan 2017 07:37:34 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 375A91294BC for ; Thu, 5 Jan 2017 07:37:34 -0800 (PST) Received: from resomta-po-02v.sys.comcast.net ([96.114.154.226]) by resqmta-po-05v.sys.comcast.net with SMTP id PA6UcpXKJMqbUPA6fcROHN; Thu, 05 Jan 2017 15:37:33 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483630653; bh=afFARDOHpVqLVThJ62JBm/EOlHMRSzrfKjTCPsc8BNo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=fnBfhY1AvI+S8Va6/olwSnhFGHRni63/EwrJjUbZVR50aDvELR8TPKTfG32FDrhzM 8eNUUeh1sd1BOmTADaHJe0IVi+eq6QuwzV7PZV5JwDaRTtkRPjEHAwJMVRELMGrnhf 5a8tMk3yH6YR7aXPm32wIQ6ZAJknV6Yc6hxIhMcNnSbZ8U1VKn7Gt689Sj0jWMXHmg ffPliANEdMcj68E2ET1gRc0FlzcuDkkc87EjgPnWsuHVUAIK8V9aHaPm2hSeQjYE78 egNvDEF2cu0EWPdkWD41L+xFTjePKPMUmLfvN3tQoCZfejrtzBC/qegGeKhIYSyv0b ZCkptmEu7En2A== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-02v.sys.comcast.net with SMTP id PA6fc7hpHyYdiPA6fcEnYQ; Thu, 05 Jan 2017 15:37:33 +0000 To: sipcore@ietf.org References: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> Date: Thu, 5 Jan 2017 10:37:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfGBua52EiAxBTDE5iLwJdXI7c43fHSUEDIK2WdbV2k+vCIVWduFTW7y0w0oMOtEWB4pHnDgWsbpzBguIoEeTcAQm6/3evtMtQkptDbKCJimqscjpeQvq Bo1o5CLPxVlDzcXgHi0vEkNGTbwUUqNN6xl9yyQ3bRdw+sxj4FRyoarq8Hri64AoA2a++HhmIEpieA== Archived-At: Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:37:36 -0000 On 1/5/17 10:19 AM, Dale R. Worley wrote: > writes: >> I would like to submit an errata to RFC3261 on the following point: >> >> RFC 3261 (section 20 Table 2) states that Content-Type header is not >> applicable to the CANCEL method (meaning that a CANCEL must not >> contain a body). > >> "580 (Precondition Failure) responses and BYE and CANCEL requests, >> indicating failure to meet certain preconditions, SHOULD contain an >> SDP description, indicating which desired status triggered the >> failure. Note that this SDP description is not an offer or an >> answer, since it does not lead to the establishment of a session. >> The format of such a description is based on the last SDP (an offer >> or an answer) received from the remote UA." > > This isn't really an erratum for 3261 as a clarification that 3312 > updates the table in 3261. > > But I remember there was a discussion some years ago about maintaining > the tables in 3261 and there was some sort of decision to no longer do > that, as almost every SIP RFC entailed modifying the tables. > > Does anyone remember the details of that discussion? I can't recall the *details*, but as I remember it the gist was that table 2 is insufficient to characterize the nuances that often need to be expressed. So, rather than attempt to maintain table 2 the conclusion was that documents should express the constraints individually, typically with text. Thanks, Paul From nobody Thu Jan 5 07:58:18 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D80129B41 for ; Thu, 5 Jan 2017 07:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbHc1573f81e for ; Thu, 5 Jan 2017 07:58:16 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21ABE1296DA for ; Thu, 5 Jan 2017 07:58:16 -0800 (PST) Received: from mutabilis.routerlogin.net (mobile-166-173-058-199.mycingular.net [166.173.58.199]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v05Fw3xc004454 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Jan 2017 09:58:04 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host mobile-166-173-058-199.mycingular.net [166.173.58.199] claimed to be mutabilis.routerlogin.net To: Paul Kyzivat , sipcore@ietf.org References: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> From: "A. Jean Mahoney" Message-ID: <3f8acabc-973c-f6c6-5460-f0a102279758@nostrum.com> Date: Thu, 5 Jan 2017 09:57:58 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 15:58:17 -0000 On 1/5/17 9:37 AM, Paul Kyzivat wrote: > On 1/5/17 10:19 AM, Dale R. Worley wrote: >> writes: >>> I would like to submit an errata to RFC3261 on the following point: >>> >>> RFC 3261 (section 20 Table 2) states that Content-Type header is not >>> applicable to the CANCEL method (meaning that a CANCEL must not >>> contain a body). >> >>> "580 (Precondition Failure) responses and BYE and CANCEL requests, >>> indicating failure to meet certain preconditions, SHOULD contain an >>> SDP description, indicating which desired status triggered the >>> failure. Note that this SDP description is not an offer or an >>> answer, since it does not lead to the establishment of a session. >>> The format of such a description is based on the last SDP (an offer >>> or an answer) received from the remote UA." >> >> This isn't really an erratum for 3261 as a clarification that 3312 >> updates the table in 3261. >> >> But I remember there was a discussion some years ago about maintaining >> the tables in 3261 and there was some sort of decision to no longer do >> that, as almost every SIP RFC entailed modifying the tables. >> >> Does anyone remember the details of that discussion? > > I can't recall the *details*, but as I remember it the gist was that > table 2 is insufficient to characterize the nuances that often need to > be expressed. So, rather than attempt to maintain table 2 the conclusion > was that documents should express the constraints individually, > typically with text. Here's where the Table 2 discussion is captured: https://www.ietf.org/mail-archive/web/sipcore/current/msg02230.html https://www.ietf.org/proceedings/77/minutes/sipcore.html Jean From nobody Thu Jan 5 08:04:18 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58D1B129B8C for ; Thu, 5 Jan 2017 08:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THbWnQNJZII8 for ; Thu, 5 Jan 2017 08:04:13 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A5E129B90 for ; Thu, 5 Jan 2017 08:04:10 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 68D5B746AB1CB; Thu, 5 Jan 2017 16:04:04 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v05G45XE027850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Jan 2017 16:04:06 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v05G3xPf028524 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 5 Jan 2017 16:04:04 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Thu, 5 Jan 2017 17:04:00 +0100 From: "Drage, Keith (Nokia - GB)" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Errata to RFC3261 Thread-Index: AQHSZ2cYPEYWqgjEB063rhhH0mngLaEp87AAgAAVJvA= Date: Thu, 5 Jan 2017 16:03:59 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFD17F6@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> In-Reply-To: <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 16:04:15 -0000 I think this is actually addressing the wrong document. RFC 3261 is correct in its own right. It is when it is used in conjunction with RFC 3312 that the problem occurs,= and therefore the correction should be made to RFC 3312 to update RFC 3261= in this respect. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 05 January 2017 15:38 To: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 On 1/5/17 10:19 AM, Dale R. Worley wrote: > writes: >> I would like to submit an errata to RFC3261 on the following point: >> >> RFC 3261 (section 20 Table 2) states that Content-Type header is not=20 >> applicable to the CANCEL method (meaning that a CANCEL must not=20 >> contain a body). > >> "580 (Precondition Failure) responses and BYE and CANCEL requests, >> indicating failure to meet certain preconditions, SHOULD contain an >> SDP description, indicating which desired status triggered the >> failure. Note that this SDP description is not an offer or an >> answer, since it does not lead to the establishment of a session. >> The format of such a description is based on the last SDP (an offer >> or an answer) received from the remote UA." > > This isn't really an erratum for 3261 as a clarification that 3312=20 > updates the table in 3261. > > But I remember there was a discussion some years ago about maintaining=20 > the tables in 3261 and there was some sort of decision to no longer do=20 > that, as almost every SIP RFC entailed modifying the tables. > > Does anyone remember the details of that discussion? I can't recall the *details*, but as I remember it the gist was that table = 2 is insufficient to characterize the nuances that often need to be express= ed. So, rather than attempt to maintain table 2 the conclusion was that doc= uments should express the constraints individually, typically with text. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu Jan 5 09:02:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C0771294F1 for ; Thu, 5 Jan 2017 09:01:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.019 X-Spam-Level: X-Spam-Status: No, score=-5.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_DdWTgzT1BU for ; Thu, 5 Jan 2017 09:01:57 -0800 (PST) Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB17C129496 for ; Thu, 5 Jan 2017 09:01:56 -0800 (PST) Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id B064F10070D; Thu, 5 Jan 2017 18:01:55 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id 8EB1C80062; Thu, 5 Jan 2017 18:01:55 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 18:01:55 +0100 From: To: "Drage, Keith (Nokia - GB)" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Errata to RFC3261 Thread-Index: AQHSZ2cVEej5XP83B0Gg5Vc+CwPIyKEp87AAgAAHZICAAB8fAA== Date: Thu, 5 Jan 2017 17:01:54 +0000 Message-ID: <19964_1483635715_586E7C03_19964_3476_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A34AE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD17F6@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADFD17F6@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 17:01:58 -0000 Hi, I don't want to re-open the discussion on the Tables (I also heard that the= y are now deprecated).=20 I agreed that RFC3261 comes first so it should have been stated in RFC3312 = that RFC3312 also update the 3261 table.=20 I would propose to have an errata to RFC3312 adding this clarification. Any other view? BR, Marianne=20 -----Message d'origine----- De=A0: sipcore [mailto:sipcore-bounces@ietf.org] De la part de Drage, Keith= (Nokia - GB) Envoy=E9=A0: jeudi 5 janvier 2017 17:04 =C0=A0: Paul Kyzivat; sipcore@ietf.org Objet=A0: Re: [sipcore] Errata to RFC3261 I think this is actually addressing the wrong document. RFC 3261 is correct in its own right. It is when it is used in conjunction with RFC 3312 that the problem occurs,= and therefore the correction should be made to RFC 3312 to update RFC 3261= in this respect. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 05 January 2017 15:38 To: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 On 1/5/17 10:19 AM, Dale R. Worley wrote: > writes: >> I would like to submit an errata to RFC3261 on the following point: >> >> RFC 3261 (section 20 Table 2) states that Content-Type header is not=20 >> applicable to the CANCEL method (meaning that a CANCEL must not=20 >> contain a body). > >> "580 (Precondition Failure) responses and BYE and CANCEL requests, >> indicating failure to meet certain preconditions, SHOULD contain an >> SDP description, indicating which desired status triggered the >> failure. Note that this SDP description is not an offer or an >> answer, since it does not lead to the establishment of a session. >> The format of such a description is based on the last SDP (an offer >> or an answer) received from the remote UA." > > This isn't really an erratum for 3261 as a clarification that 3312=20 > updates the table in 3261. > > But I remember there was a discussion some years ago about maintaining=20 > the tables in 3261 and there was some sort of decision to no longer do=20 > that, as almost every SIP RFC entailed modifying the tables. > > Does anyone remember the details of that discussion? I can't recall the *details*, but as I remember it the gist was that table = 2 is insufficient to characterize the nuances that often need to be express= ed. So, rather than attempt to maintain table 2 the conclusion was that doc= uments should express the constraints individually, typically with text. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu Jan 5 13:14:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F191295AF for ; Thu, 5 Jan 2017 13:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d1Z42BCdMes for ; Thu, 5 Jan 2017 13:14:35 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9973912944B for ; Thu, 5 Jan 2017 13:14:35 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-02v.sys.comcast.net with SMTP id PFLlcw6ZToagNPFMocbjdg; Thu, 05 Jan 2017 21:14:34 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-15v.sys.comcast.net with SMTP id PFMmc6RrSW0VBPFMncLD6Y; Thu, 05 Jan 2017 21:14:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v05LEWT6010417 for ; Thu, 5 Jan 2017 16:14:32 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v05LEVoZ010414; Thu, 5 Jan 2017 16:14:31 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 05 Jan 2017 16:14:31 -0500 Message-ID: <87eg0hfbuw.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEgzclixsU8N5Z8kZh/etXeKtqKfejLxBDM86174Ye5bGFKS0Tdi9HkR3NBbU+af8hf/SbXvqXPU9Gm3IM5k8G8uKh7KbpcdKj2L4pc37LX5+330TCWm KCd0FDhOyXuVdnCDfGmKLdyIIYkJmG1nVhnX8pMSIz4XofbuXQfC7VAj Archived-At: Subject: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 21:14:36 -0000 Given that 666 responses can cause later calls to be blocked by automated mechanisms, do we need a (different) response code to indicate "this call has been blocked by an automated spam-prevention system"? It seems to me that we need a mechanism to inform the caller that he may need to initiate an exception procedure to prevent his calls from being blocked. Dale From nobody Thu Jan 5 13:24:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4E7E1293FE for ; Thu, 5 Jan 2017 13:24:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdUhDd978bzU for ; Thu, 5 Jan 2017 13:24:38 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 847B31295AF for ; Thu, 5 Jan 2017 13:24:38 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v05LFRxR005068; Thu, 5 Jan 2017 16:24:34 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0048589.ppops.net-00191d01. with ESMTP id 27ssr16esf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 16:24:34 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v05LOX6M032231; Thu, 5 Jan 2017 16:24:33 -0500 Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v05LOM7L032068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 5 Jan 2017 16:24:26 -0500 Received: from MISOUT7MSGHUBAD.ITServices.sbc.com (MISOUT7MSGHUBAD.itservices.sbc.com [130.9.129.148]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Thu, 5 Jan 2017 21:24:10 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.99]) by MISOUT7MSGHUBAD.ITServices.sbc.com ([130.9.129.148]) with mapi id 14.03.0319.002; Thu, 5 Jan 2017 16:24:09 -0500 From: "DOLLY, MARTIN C" To: "Dale R. Worley" Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? Thread-Index: AQHSZ5i+leYQxhfOv0eWgMdIh5QrP6EqZOmI Date: Thu, 5 Jan 2017 21:24:09 +0000 Message-ID: <0FD9CCE3-2822-47B1-A7D9-88A8FECEABD1@att.com> References: <87eg0hfbuw.fsf@hobgoblin.ariadne.com> In-Reply-To: <87eg0hfbuw.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_0FD9CCE3282247B1A7D988A8FECEABD1attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701050307 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 21:24:40 -0000 --_000_0FD9CCE3282247B1A7D988A8FECEABD1attcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dale By automated mechanisms only with consumer consent. Consumer is in control Regards Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Jan 5, 2017, at 4:14 PM, Dale R. Worley > wrote: Given that 666 responses can cause later calls to be blocked by automated mechanisms, do we need a (different) response code to indicate "this call has been blocked by an automated spam-prevention system"? It seems to me that we need a mechanism to inform the caller that he may need to initiate an exception procedure to prevent his calls from being blocked. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_0FD9CCE3282247B1A7D988A8FECEABD1attcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dale

By automated mechanisms only with consumer c= onsent. Consumer is in control

Regards

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Jan 5, 2017, at 4:14 PM, Dale R. Worley <worley@ariadne.com> wrote:

Given that 666 responses can cause later calls to be blocked by<= /span>
automated mechanisms, do we need a (different) response code to indic= ate
"this call has been blocked by an automated spam-prevention syst= em"?  It
seems to me that we need a mechanism to inform the caller that he may=
need to initiate an exception procedure to prevent his calls from bei= ng
blocked.

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_0FD9CCE3282247B1A7D988A8FECEABD1attcom_-- From nobody Thu Jan 5 14:33:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0360129715 for ; Thu, 5 Jan 2017 14:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSmH7_j50e0n for ; Thu, 5 Jan 2017 14:33:49 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E0591296EC for ; Thu, 5 Jan 2017 14:33:48 -0800 (PST) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v05MUgAU026815; Thu, 5 Jan 2017 22:33:44 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p3qhubj2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 22:33:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FwQ9CArCu9WNM7ZqPI/2+h4p4U6IUVPehCV6zs1VOVE=; b=BkWMwQb+tXxsUj0ghppSKToLKXVi9ILRaz/dI5D4pQG2dy3ft1Iy61lU2yJPJXk9T6MeeqmsFFLvQfNN5+UqnoBSqfZeUOKC32VUYnHeRa5MR2VlGGWLkDU/vqD0Y3Sn/u+a7iD9yIm1eZN1WEROkaZcWe+eCoDiYjPqM0r1CjE= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 22:33:42 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 22:33:42 +0000 From: Henning Schulzrinne To: "Dale R. Worley" , "sipcore@ietf.org" Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? Thread-Index: AQHSZ5i7uX5AkvMHfEmS+B9NF8+2CqEqdAQK Date: Thu, 5 Jan 2017 22:33:42 +0000 Message-ID: References: <87eg0hfbuw.fsf@hobgoblin.ariadne.com> In-Reply-To: <87eg0hfbuw.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.39] x-ms-office365-filtering-correlation-id: 8271f949-54a8-4a1a-234b-08d435bae751 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:50gDKi1DjyowE/O2eFlBgrKWY9qG6Wiq68ZHEvsvJNYV9WtV2Ldp6B121tHiHdFVg49ikumRIbD+KKlVJ+1c0yLSwp2vXelyaV2g8azVcKjjf0Xkb1W9gVmtBVKwaBctNFSsTnJY976uvz4NOS5DwMzOA3Vxq/b4CYE5EPpKphtIajLUlJ4/JO8/VzcGLE6E+986upPsRECTUW3mX43tvbiv5dfvbOWP4BbxgeE8sbYkYO6Ovg8QlFjfnbdmBf6WrAdQhUZ0uCBbVDNi1Zqlw62TFNsApYuwcF3K0RBEbR8L7zs/e1Fca5D6OQutC6T48V4KF3sQ7I591jcWN0/nKPzmf/JRZomWvgyqEptkP6msA7Oh/uPdXaw5yNrtq8wWhCcxsxeO2YBOQLNXofCxgcHqtKN7IkvBZC0Tcp2kENXFWY+KuFSjrFwEhyLbq/Cl6xcgtkE9Hk+XbsYWD3jXcQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(377454003)(189002)(57704003)(54356999)(575784001)(8676002)(2906002)(8936002)(81156014)(76176999)(107886002)(2900100001)(19627405001)(122556002)(92566002)(105586002)(101416001)(86362001)(50986999)(106356001)(97736004)(6306002)(102836003)(74316002)(189998001)(106116001)(3660700001)(7736002)(229853002)(3280700002)(68736007)(25786008)(6606003)(81166006)(33656002)(5001770100001)(9686002)(54896002)(7696004)(66066001)(6436002)(5660300001)(2501003)(77096006)(2950100002)(7906003)(6506006)(230783001)(99286003)(55016002)(6116002)(3846002)(606005)(38730400001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634A6D970D0F6A78107C15EEA600CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 22:33:42.5554 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:33:52 -0000 --_000_CY1PR09MB0634A6D970D0F6A78107C15EEA600CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Are you talking about the case where the end system itself does the blockin= g, e.g., via an app (e.g., Hiya or Nomorobo)? Leaving aside Martin's concerns for a moment, I admit that I'm not convince= d that this distinction is meaningful. For example, an app or dialer may ha= ve a personal blacklist (I believe Android does). This is something done by= the user, not AI (so Martin may like it...), but the dialer would be respo= nding with a 666 on the next call to signal the reason for the rejection. I= s that a robot instead? What if the app just suggests that this is a "bad" = call and the user hits the spam button? I admit that I have a hard time dra= wing a firm line that would provide sufficient guidance to implementors to = choose one status code or the other. This seems like something we could discuss once we have a bit more operatio= nal experience. Maybe a "Warning" code would be the more appropriate means = of conveying such additional information, for example. Henning ________________________________ From: sipcore on behalf of Dale R. Worley Sent: Thursday, January 5, 2017 4:14:31 PM To: sipcore@ietf.org Subject: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another= response code? Given that 666 responses can cause later calls to be blocked by automated mechanisms, do we need a (different) response code to indicate "this call has been blocked by an automated spam-prevention system"? It seems to me that we need a mechanism to inform the caller that he may need to initiate an exception procedure to prevent his calls from being blocked. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DlUklkBNSKO8leDczj7XpUsgIjfeHd5JAaPgSZ1mkce= k&s=3Da5GMBGa2toS86AJ3-GyP_piMbHog9ESqx6zHiig5nTI&e=3D --_000_CY1PR09MB0634A6D970D0F6A78107C15EEA600CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


Are you talking about the case where the end system itself does the bloc= king, e.g., via an app (e.g., Hiya or Nomorobo)?


Leaving aside Martin's concerns for a moment, I admit that I'm not convinced that this distinction is meaning= ful. For example, an app or dialer may have a personal blacklist (I believe= Android does). This is something done by the user, not AI (so Martin may like it...), but the dialer would be re= sponding with a 666 on the next call to signal the reason for the rejection= . Is that a robot instead? What if the app just suggests that this is a &qu= ot;bad" call and the user hits the spam button? I admit that I have a hard time drawing a firm line that would pro= vide sufficient guidance to implementors to choose one status code or the o= ther.


This seems like something we could disc= uss once we have a bit more operational experience. Maybe a "Warning&q= uot; code would be the more appropriate means of conveying such additional = information, for example.


Henning


From: sipcore <sipcore= -bounces@ietf.org> on behalf of Dale R. Worley <worley@ariadne.com>= ;
Sent: Thursday, January 5, 2017 4:14:31 PM
To: sipcore@ietf.org
Subject: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need = another response code?
 
Given that 666 responses can cause later calls to = be blocked by
automated mechanisms, do we need a (different) response code to indicate "this call has been blocked by an automated spam-prevention system&quo= t;?  It
seems to me that we need a mechanism to inform the caller that he may
need to initiate an exception procedure to prevent his calls from being
blocked.

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefen= se.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_sipcor= e&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX= 8lDU1XeHIYRHfarpk4MK59RE&m=3DlUklkBNSKO8leDczj7XpUsgIjfeHd5JAaPgSZ1mkce= k&s=3Da5GMBGa2toS86AJ3-GyP_piMbHog9ESqx6zHiig5nTI&e=3D
--_000_CY1PR09MB0634A6D970D0F6A78107C15EEA600CY1PR09MB0634namp_-- From nobody Thu Jan 5 14:45:24 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5076712946C for ; Thu, 5 Jan 2017 14:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AkGo0XPr3th for ; Thu, 5 Jan 2017 14:45:19 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A44AE129460 for ; Thu, 5 Jan 2017 14:45:19 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v05MitrY005668; Thu, 5 Jan 2017 22:45:18 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0016.outbound.protection.outlook.com [23.103.198.16]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4gu2qaw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 22:45:18 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MYDbfDIa8EacCw3d6yr8PEZNGbOSSUbmz9vh1uNEq74=; b=aQ6935dmfYCx2sXFXRQ2a0VMVipLHLOZqaQ6SdgVeke155XS91TMaW58TT8ow6S4lVamfU7F6QalQowVxQ31dLT9K7p14uAm6TcUs5A/D1cARA3obCYoJyUpz+sX5lHD4bHaIcMQkiYESkL64AXfidTQNQ/BRiErWHa3avP5Zp0= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 22:45:16 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 22:45:16 +0000 From: Henning Schulzrinne To: "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAzSmHS Date: Thu, 5 Jan 2017 22:45:15 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> In-Reply-To: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.39] x-ms-office365-filtering-correlation-id: 118b34bd-3b81-4b8f-d955-08d435bc848d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:KCu8q1HvceFZmyCZYIrhPOIfG5UDMfW0ANXhdQZ/84ssN43fxxzVF1MhyBpuvxk96oVNYhyZWXQgCEhVYX9oO1CK9x5jbWl9CxngfmkAOBi1EExq12gX8Qa5owLZzRtbFOy/RZyd8VFMiVfqXYi97hiia4TIUyDPQu5wyk09qtm0/0ESMwvQGOvfOpEp03lg4n1/n/ZFP+XV+hCRclsNdZ+GCq6yJV6jyTLKuFfp5LtMbLtWPMgiv7py7iR3oONW04ih0+2hEd7oyWqEwA0sAiXNyzZoQ/YB/US9bDBDrAhC6H8m7XdVemowCOLQB613vxUvEp2rKAQe9zMAmtcnT+W2Lf6JiyXBhnCr+Nuiz9mW++Rd4Qf1zVISxK/lYqVjsf0kKIGgreKAObYS6Bj7cVVuen2kNyIpE9qpMqnX5BXhcJXWbMxYOaUCOyXTOzNudy0LXqsycqxA9xQdCmh9GA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(377454003)(199003)(189002)(229853002)(54896002)(86362001)(74316002)(66066001)(6116002)(81156014)(9686002)(2950100002)(19627405001)(5001770100001)(6606003)(107886002)(3280700002)(76176999)(2501003)(92566002)(2900100001)(3846002)(7696004)(81166006)(8676002)(55016002)(8936002)(101416001)(189998001)(7736002)(122556002)(68736007)(54356999)(2906002)(3660700001)(33656002)(102836003)(77096006)(7906003)(230783001)(38730400001)(105586002)(99286003)(6436002)(50986999)(6306002)(106356001)(6506006)(25786008)(97736004)(606005)(5660300001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634BE77F6B11F9A2F30EA2CEA600CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 22:45:15.8253 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:45:22 -0000 --_000_CY1PR09MB0634BE77F6B11F9A2F30EA2CEA600CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use the term "calle= r identity" or "calling party identity", defined as An identity, for the purposes of this document, is defined as either a canonical address-of-record (AoR) SIP URI employed to reach a user (such as 'sip:alice@atlanta.example.com'), or a telephone number, which commonly appears in either a TEL URI [RFC3966] or as the user portion of= a SIP URI. This avoids the awkward "number or address", particularly given that "addre= ss" isn't really a formal SIP term and "SIP URI" may not be generic enough. ________________________________ From: sipcore on behalf of marianne.mohali@orang= e.com Sent: Wednesday, January 4, 2017 5:35 PM To: sipcore@ietf.org Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, I have the following comments on v01: -Section 4 - 4rd paragraph: The actions described here do not depend on the nature of the SIP URI, e.g., whether it describes a telephone number or not but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"? -Section 4 - last paragraph: We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that the corresponding proxy supports th= is particular response code. I would suggest: "This document defines a new SIP feature-capability indica= tor [RFC6809] value, sip.666, that ... -Section 4 general: IMO, it would be good to have a paragraph addressing the question of the "c= alling party number" (mentioned several time in the document): indeed, this= calling party number can be identified by the telephone number/address in = the From header or the one in the P-Asserted-Identity header that may be di= fferent. Depending on the one displayed to the called UA, the 666 could con= cern only one or both addresses depending on service provider choices. If w= e take the example of a call-center or an IPBX having the head number and a= range of private numbers, the service provider could interpret the 666 fro= m the called user only for the private number (in the From header) or for t= he whole pool (P-Asserted-Identity). I suggest to have a paragraph to highl= ight this point. -Section 6: calling party number / calling party address Best regards, Marianne --_000_CY1PR09MB0634BE77F6B11F9A2F30EA2CEA600CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use t= he term "caller identity" or "calling party identity", = defined as


An identity, for the purposes of this =
document, is=0A=
   defined as either a canonical address-of-record (AoR) SIP URI=0A=
   employed to reach a user (such as 'sip:alice@atlanta.example.com'),=0A=
   or a telephone number, which commonly appears in either a TEL URI=0A=
   [RFC3966] or as the user portion of a S=
IP URI.


This avoids the awkward "number or address", particularly given t= hat "address" isn't really a formal SIP term and "SIP URI&qu= ot; may not be generic enough.
From: sipcore <sipcore= -bounces@ietf.org> on behalf of marianne.mohali@orange.com <marianne.= mohali@orange.com>
Sent: Wednesday, January 4, 2017 5:35 PM
To: sipcore@ietf.org
Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=
 
Hi,

I have the following comments on v01:

-Section 4 - 4rd paragraph:
        The actions described here do no= t depend on the nature of the SIP
         URI, e.g., whether it desc= ribes a telephone number or not
but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"= ;?

-Section 4 - last paragraph:
        We define a SIP feature-capabili= ty [RFC6809], sip.666, that allows
         the registrar to indicate = that the corresponding proxy supports this
         particular response code.<= br> I would suggest: "This document defines a new SIP feature-capability i= ndicator [RFC6809] value, sip.666, that ...

-Section 4 general:
IMO, it would be good to have a paragraph addressing the question of the &q= uot;calling party number" (mentioned several time in the document): in= deed, this calling party number can be identified by the telephone number/a= ddress in the From header or the one in the P-Asserted-Identity header that may be different. Depending on the one dis= played to the called UA, the 666 could concern only one or both addresses d= epending on service provider choices. If we take the example of a call-cent= er or an IPBX having the head number and a range of private numbers, the service provider could interpret the 6= 66 from the called user only for the private number (in the From header) or= for the whole pool (P-Asserted-Identity). I suggest to have a paragraph to= highlight this point.

-Section 6:
calling party number / calling party address


Best regards,
Marianne


--_000_CY1PR09MB0634BE77F6B11F9A2F30EA2CEA600CY1PR09MB0634namp_-- From nobody Thu Jan 5 15:17:31 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A80D81296F7 for ; Thu, 5 Jan 2017 15:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nb8Iu7J_xLrj for ; Thu, 5 Jan 2017 15:17:28 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCB312964E for ; Thu, 5 Jan 2017 15:17:28 -0800 (PST) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v05NEEkj017238; Thu, 5 Jan 2017 23:17:23 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0048.outbound.protection.outlook.com [23.103.198.48]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p3qhuc67-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 23:17:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nxe9T7yzQiliyS0hONv7TleqvakljxMKcjRcQV5fFvA=; b=YCEXotiLgAZKhrke60p8sGpdGNfQfimbS8RHLT5oQLfVgZkYoMvtajWygOZ0eV/LJEqxhyyKu5diNNV7rX5xJlKcnT6NSYuLO/aYBDFJw7PC6dhLiexs0YBQlYwe21pC9aUAH9ZpJntQvhCO1Op4VAtzpD479sjyTDDyxC0ekkQ= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 23:17:21 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 23:17:21 +0000 From: Henning Schulzrinne To: "Dale R. Worley" Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZ2F+ZBs4MySSekqJkBAojeGCU6EqhJe8 Date: Thu, 5 Jan 2017 23:17:21 +0000 Message-ID: References: (Henning.Schulzrinne@fcc.gov),<87mvf5h8q1.fsf@hobgoblin.ariadne.com> In-Reply-To: <87mvf5h8q1.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.39] x-ms-office365-filtering-correlation-id: d5dd89ac-9ee7-48f2-4bf3-08d435c10061 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:qHBOvJXrs+GUP0aJlxI7OYIepKElZLtMfN0OM75a5bUP7WMKxv8V95R+Et3uUA6iCwKy8Mki9NQHrwK5Ye4si3yY6EJhmqrlYjtMsJ37cSUEVdGeu4sQeHkC1Y/uP1NRtjmasKiAoecA15Mhh29l/Q4ykhERFAH9N44HtjkbT5BQqLNp63HB3Z0XZV7gpEUjuGiZBCxcmKjJFkKMtwO+070IdlNlL6aeR6LGTG15dpZ/CBr/dMMUE92Zo5+XvpCT1cBxfbuNP4iybvxfl4JDCDD7inGL5VdQZTRleKtaMnhFeI9QrR5Lu0wBCPgJe9zj/JggtJSra0MEijTXUhOTM6wAu5vGEbyR81QjlbJs3+ZauMlhWiLUpVXFEbkdAOANyn3lJp4r0dAxJ/qfgZzyovrKBi/cYllTuYNQYNLZ7luNdOVL4uY2aYC8wUWfrZXXsUu2XXC7uG50Lvul5mE1eA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(377454003)(199003)(7696004)(66066001)(9686002)(54896002)(33656002)(2950100002)(77096006)(6506006)(5660300001)(6436002)(6606003)(3900700001)(81166006)(3846002)(6116002)(38730400001)(6916009)(99286003)(230783001)(110136003)(55016002)(19627405001)(2900100001)(101416001)(105586002)(86362001)(4326007)(50986999)(122556002)(92566002)(8676002)(54356999)(8936002)(2906002)(76176999)(81156014)(229853002)(7736002)(106116001)(3660700001)(25786008)(3280700002)(68736007)(97736004)(74316002)(189998001)(106356001)(102836003)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063469B1C913464B6667B0E9EA600CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 23:17:21.4637 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:17:29 -0000 --_000_CY1PR09MB063469B1C913464B6667B0E9EA600CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Trying to wrap this up...] As written, SUBSCRIBE is mentioned, so hopefully your case is covered, leav= ing the Turing Test issue aside. Let me know if you think additional wording is needed. ________________________________ From: Dale R. Worley Sent: Thursday, January 5, 2017 9:39 AM To: Henning Schulzrinne Cc: sipcore@ietf.org Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-u= nwanted-01.txt Henning Schulzrinne writes: > Interesting corner case. Do you have a particular use case in mind? > Would this be a consumer (subscriber) SUBSCRIBEing to a particular > event and then not liking the NOTIFYs that follow? The case that came immediately to mind is subscription to call-completion events -- that can be used as a way to snoop the status of a particular callee. See RFC 6910's Security Considerations and references to that within the RFC. So a 666 response code to such a SUBSCRIBE would be a sensible way to object to it as a potential privacy violation. Though now that I think about it, that response would almost certainly be generated by an automaton, not an end-user. Dale --_000_CY1PR09MB063469B1C913464B6667B0E9EA600CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

[Trying to wrap this up...]


As written, SUBSCRIBE is mentioned, so hopefully your case is covered, l= eaving the Turing Test issue aside.


Let me know if you think additional wording is needed.


From: Dale R. Worley <= worley@ariadne.com>
Sent: Thursday, January 5, 2017 9:39 AM
To: Henning Schulzrinne
Cc: sipcore@ietf.org
Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-s= tatus-unwanted-01.txt
 
Henning Schulzrinne <Henning.Schulzrinne@fcc.go= v> writes:
> Interesting corner case. Do you have a particular use case in mind? > Would this be a consumer (subscriber) SUBSCRIBEing to a particular
> event and then not liking the NOTIFYs that follow?

The case that came immediately to mind is subscription to
call-completion events -- that can be used as a way to snoop the status
of a particular callee.  See RFC 6910's Security Considerations and references to that within the RFC.  So a 666 response code to such a SUBSCRIBE would be a sensible way to object to it as a potential privacy violation.

Though now that I think about it, that response would almost certainly
be generated by an automaton, not an end-user.

Dale
--_000_CY1PR09MB063469B1C913464B6667B0E9EA600CY1PR09MB0634namp_-- From nobody Thu Jan 5 15:21:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94CDB1295DC for ; Thu, 5 Jan 2017 15:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oA-XmnMmfs2y for ; Thu, 5 Jan 2017 15:21:08 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE7112953F for ; Thu, 5 Jan 2017 15:14:22 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v05NELaV021540; Thu, 5 Jan 2017 23:14:21 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0052.outbound.protection.outlook.com [23.103.198.52]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4gu2qrj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 23:14:21 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rHrJesCSl2gl5svaYf+AYAsdnR1fj0ysT1QDODuKA5E=; b=Y8V2J6BWeA70JakJPHv15XgnjnjGqqi+P8LcV+WK5w7eNIfOFnJVgTytUqMIk3l6TGRn6+t6mAkIzYlMGXLafEDNgb1wUqKuFimkMC2VNSIMXGIiZhUWuICMAjSA2cy4FcZJdDSYAZPbA4Fnrbul1XutAyJ4lGX6d6/6ZKi52Sk= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 23:14:19 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 23:14:19 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAFeq4AABk5kgAABTb+gAAQDLCS Date: Thu, 5 Jan 2017 23:14:18 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.39] x-ms-office365-filtering-correlation-id: d8b6336a-57ff-41fd-8982-08d435c0938b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:haSdlkpI0VeEY+zRvnUHuhncMZp6kx8Td4uM8ZjjKB3eKYoQFpXU28CtLHYyxZyg3jsKJ/7+ff35IGl9EA3xlYuy4UIwJIkXXkizCeKHpaDl7cY3iZJaw0tNthQj9cesnEg3XnCF6c30XS0pOP5q/k2yco1W+NrAaDMdzowuF4JTMcXK+kruLF86Heh47I4FlmNbbTdyBxLlZTXyXWUCqq+xzheqAcoImEKeHnAJGlzsMipyVvfQ/yjnQFwl9kUJodctSw/ORhvEjaXrxT4wu8iNSnXPd2ycKTy7hNZhFsv2Orkm9ueH4EhfN75fF9QC2tMTDctTZqpal+gPl+yQEY1NqUS4T1cHv4NZOyd9/HTDq6aMIa5/G7B/znToPFsQmPSp7SHHlOFrmWvqIpOafsAxdiNh8LUbnw+FEf3XAUwVuKzJS5rOLmbOMbwf7wi5RH3vBpJEi0V8nOerKU7v4g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(131327999870524)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(189002)(377454003)(199003)(13464003)(24454002)(7696004)(66066001)(9686002)(54896002)(33656002)(5001770100001)(7906003)(2950100002)(77096006)(6506006)(5660300001)(6436002)(2501003)(81166006)(93886004)(3846002)(6116002)(606005)(38730400001)(99286003)(230783001)(55016002)(2900100001)(101416001)(105586002)(86362001)(50986999)(122556002)(92566002)(8676002)(54356999)(575784001)(107886002)(8936002)(2906002)(76176999)(81156014)(229853002)(7736002)(3660700001)(25786008)(3280700002)(68736007)(6306002)(97736004)(74316002)(189998001)(106356001)(102836003)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E716E98650CE91D0C9DDEA600CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 23:14:18.9989 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:21:10 -0000 --_000_CY1PR09MB0634E716E98650CE91D0C9DDEA600CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On (i), I agree that we don't want to get into what information is being us= ed, given that the entity most likely to use the 666 information, i.e., the= terminating carrier, is also the one deciding how caller identity is being= presented to the user (PAI, From, etc.). Tastes may differ, but I don't see how we can say much that's useful to imp= lementors here, without getting into weeds that are already being explored = by (say) the SHAKEN effort. Also, I'm not convinced that defining "call" is needed here, given that we'= d probably not go much beyond what's in RFC 3261: Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Also, given the discussion of usage for non-INVITE, I'll change "call" to "= request" or "dialog" where the context is more than just an example of what= is likely to be the most common case - INVITE for a phone call. Henning ________________________________ From: sipcore on behalf of Asveren, Tolga Sent: Thursday, January 5, 2017 10:22:55 AM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I agree that defining what a "call" is a good idea but I have a different t= ake on what it should say: i- A "call" in the context of this document is a communication session as = perceived by a human agent, e.g. as in "I received a call from my grandmoth= er.". It does not imply anything further as far as SIP information elements= which usually are used to carry calling party identification, e.g. P-Asser= ted-Id, From headers, are concerned. It is up to the operator/network polic= y how to make associate further calls with the information/decision derived= from unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls= from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing th= e actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > Hi, > > I also agree that adding such a paragraph would be useful. > > For instance if someone desires a service to forward all received spam ca= lls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller= was. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh= 04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04= CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D --_000_CY1PR09MB0634E716E98650CE91D0C9DDEA600CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On (i), I agree that we don't want to get into what information is being= used, given that the entity most likely to use the 666 information, i.e., = the terminating carrier, is also the one deciding how caller identity is be= ing presented to the user (PAI, From, etc.).


Tastes may differ, but I don't see how we can say much that's useful to = implementors here, without getting into weeds that are already being explor= ed by (say) the SHAKEN effort.


Also, I'm not convinced that defining "call" is needed here, g= iven that we'd probably not go much beyond what's in RFC 3261:


Call: A call is a=
n informal term that refers to some communication=0A=
         between peers, generally set up for the purposes of a=0A=
         multimedia conversation.
Also, given the discussion of usage for non-INVITE, I'll change "call&= quot; to "request" or "dialog" where the context is mor= e than just an example of what is likely to be the most common case - INVIT= E for a phone call.


Henning

From: sipcore <sipcore= -bounces@ietf.org> on behalf of Asveren, Tolga <tasveren@sonusnet.com= >
Sent: Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01
 
I agree that defining what a "call" is a= good idea but I have a different take on what it should say:

i-  A "call" in the context of this document is a communicat= ion session as perceived by a human agent, e.g. as in "I received a ca= ll from my grandmother.". It does not imply anything further as far as= SIP information elements which usually are used to carry calling party identification, e.g. P-Asserted-Id, From headers, are concer= ned. It is up to the operator/network policy how to make associate further = calls with the information/decision derived from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx response codes signify that = calls from this caller are unwanted by the called party."
=3D=3D>
"None of the existing 4xx, 5xx or 6xx response codes signify that this= call is unwanted by the called party."

I think ii- is needed to relive the end user from the burden of "knowi= ng the actual caller".

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:sipc= ore-bounces@ietf.org] On Behalf Of Brett Tate
> Sent: Thursday, January 05, 2017 7:54 AM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-= 01
>
> Hi,
>
> I also agree that adding such a paragraph would be useful.
>
> For instance if someone desires a service to forward all received spam= calls to
> another set of victims, they would likely not use such a service if th= e
> forwarding party might also get flagged as part of the 666 handling. >
>
> > -----Original Message-----
> > From: sipcore [mailto= :sipcore-bounces@ietf.org] On Behalf Of Paul
> Kyzivat
> > Sent: Wednesday, January 04, 2017 7:51 PM
> > To: sipcore@ietf.org
> > Subject: Re: [sipcore] Comments on
> > draft-ietf-sipcore-status-unwanted-01
> >
> > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote:
> >
> > > -Section 4 general:
> > > IMO, it would be good to have a paragraph addressing the que= stion of
> > > the "calling party number" (mentioned several time= in the document):
> > > indeed, this calling party number can be identified by the t= elephone
> > > number/address in the From header or the one in the
> > > P-Asserted-Identity header that may be different. Depending = on the
> > > one displayed to the called UA, the 666 could concern only o= ne or
> > > both addresses depending on service provider choices. If we = take the
> > > example of a call-center or an IPBX having the head number a= nd a
> > > range of private numbers, the service provider could interpr= et the
> > > 666 from the called user only for the private number (in the= From
> > > header) or for the whole pool (P-Asserted-Identity). I sugge= st to
> > > have a paragraph to highlight this point.
> >
> > Interesting point. If the PAID is different from the number displ= ayed
> > to
> the
> > callee, and the callee rejects the call without answering, how sh= ould
> "blame"
> > be assigned? From the calllee's perspective the complaint is *abo= ut*
> > the number he saw, regardless of what the identity of the actual = caller was.
> >
> >      Thanks,
> >      Paul
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F= 0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e= =3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F= 0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e= =3D

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8b= cHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9= ko1LYaC5NY&e=3D
--_000_CY1PR09MB0634E716E98650CE91D0C9DDEA600CY1PR09MB0634namp_-- From nobody Thu Jan 5 15:24:12 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC741295D4 for ; Thu, 5 Jan 2017 15:24:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zyUM4kIOK913 for ; Thu, 5 Jan 2017 15:24:10 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDCB129491 for ; Thu, 5 Jan 2017 15:24:10 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v05NO9Ik010693; Thu, 5 Jan 2017 23:24:09 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0056.outbound.protection.outlook.com [23.103.198.56]) by mx0b-0024ed01.pphosted.com with ESMTP id 27p4n2aqqy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 23:24:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/EOhYlVbDeon7Pfnz1WpWfe+p9Da5M+fMK/BTG9DQLE=; b=dsbx+Fp89arH0M9YH65EmyLLJi/L50nmCkhwhiOkjMjPw5pcpGzY3r/GPgnIJ7G9We7BTw77fnKCxFgDf+2tZyMLuHsFqC20xv6dn44lCW+JBJRiykHI9CZD8ijImJ5gD1TpyBQuS59sHLtA++zAKOsS60rBs5lDJOqK54fCUnw= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 23:24:07 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 23:24:07 +0000 From: Henning Schulzrinne To: Brett Tate , "Drage, Keith (Nokia - GB)" , "sipcore@ietf.org" Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZtkNZBs4MySSekqJkBAojeGCU6Eo5mXAgAAslYCAAM8vAIAApDXO Date: Thu, 5 Jan 2017 23:24:07 +0000 Message-ID: References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <45a2dc35659238515f113beba22cf690@mail.gmail.com> In-Reply-To: <45a2dc35659238515f113beba22cf690@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.39] x-ms-office365-filtering-correlation-id: 609a40e3-b515-4b2a-21bf-08d435c1f22d x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:r+s16VzBI10+kZgUsWjUT/CcxCorbkFYAtzvH3fZiUGZhmigy5LYb0hyAreDMCZHGlHt5DNX+YUJGFy8EJFoWP6wc4bR5SQn5nblb4DMwrekNkDP7NmOd3v85gS/2A6f0VYjtFwqlCcyOT+QcqTJBszPHSbnL11xe8/dJjPL6Hx4qULvsJ4YokVTMbNTaXyBG+nlH2WvUcItaIzTEnt9CBQ3P51/3fYo6l8C4NcmfxaASuX36ymMSXdUjOzgSU7TV9zQIKiaDROAssPdYEs/H3iliGT9GIGDzzJT46zvU0qHPbU3YPb3hQqiS78Iwjwuoxex29ZyEThguP+liXKoPVFTuksx/1iVJeCJcIcAJpW2oNN4s+gC02wMYoewoanVL2ddY7/VyFVk9O2CXaMWz6J5b1IRGVJrsn062bDpfUAkAyUCPo7JVmrTppLVXPMJkdgd+MKRvTvI+tL75RnIzQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(199003)(189002)(3280700002)(551934003)(229853002)(50986999)(99286003)(6116002)(9686002)(230783001)(107886002)(6436002)(5001770100001)(97736004)(2906002)(5660300001)(25786008)(122556002)(2900100001)(54896002)(8936002)(76176999)(106356001)(66066001)(3846002)(2950100002)(3660700001)(33656002)(54356999)(81166006)(105586002)(92566002)(101416001)(74316002)(7696004)(8676002)(7736002)(68736007)(2501003)(55016002)(77096006)(81156014)(102836003)(86362001)(93886004)(189998001)(106116001)(6506006)(38730400001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06341E4F630B924645A40E4AEA600CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 23:24:07.1644 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:24:12 -0000 --_000_CY1PR09MB06341E4F630B924645A40E4AEA600CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would it be helpful to indicate that 666 should be treated as 604 (as that = seems most reasonable, given that 666 is probably a dialog killer. Tentativ= e wording: Following , the 666 response destroys the dialog. ________________________________ From: Brett Tate Sent: Thursday, January 5, 2017 8:30:50 AM To: Drage, Keith (Nokia - GB); Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-status-u= nwanted-01.txt > Further if it does appear in a subsequent transaction within > a dialog what is the action by the receiver in terms of dialog > handling (unless we want to preclude it from subsequent > transactions). Is it already covered by RFC 5057. RFC 5057 does discuss 6xx handling. However since note 17 indicates "6xx unrecognized responses" and Table 1 indicates "unknown 6xx", I'm not positive if Table 2's 6xx impact (Transaction) was intended to also apply to known 6xx responses defined subsequent to RFC 5057. --_000_CY1PR09MB06341E4F630B924645A40E4AEA600CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Would it be helpful to indicate that 666 should be treated as 604 (as th= at seems most reasonable, given that 666 is probably a dialog killer. Tenta= tive wording:


Following <xref=3D"RFC5057"/>= , the 666 response destroys the dialog.


From: Brett Tate <bret= t@broadsoft.com>
Sent: Thursday, January 5, 2017 8:30:50 AM
To: Drage, Keith (Nokia - GB); Henning Schulzrinne; sipcore@ietf.org=
Subject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-s= tatus-unwanted-01.txt
 
> Further if it does appear in a subsequent tra= nsaction within
> a dialog what is the action by the receiver in terms of dialog
> handling (unless we want to preclude it from subsequent
> transactions). Is it already covered by RFC 5057.

RFC 5057 does discuss 6xx handling.  However since note 17 indicates &= quot;6xx
unrecognized responses" and Table 1 indicates "unknown 6xx",= I'm not
positive if Table 2's 6xx impact (Transaction) was intended to also apply to known 6xx responses defined subsequent to RFC 5057.
 --_000_CY1PR09MB06341E4F630B924645A40E4AEA600CY1PR09MB0634namp_-- From nobody Thu Jan 5 15:26:19 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CBA21294A8 for ; Thu, 5 Jan 2017 15:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaRal81PZoIB for ; Thu, 5 Jan 2017 15:26:16 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA04129491 for ; Thu, 5 Jan 2017 15:26:16 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v05NOrBd017005; Thu, 5 Jan 2017 23:26:16 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0023.outbound.protection.outlook.com [23.103.198.23]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p5u23ays-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Jan 2017 23:26:16 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Woe+w6IC4Xq0MEHTNOYNtIrww+KhcJey4GYMzB151bw=; b=Yo3+V05M/324/oa19ecNfOzjbf0rey6p4icoZsNkDqvnNf6rA0uJaIKy+HCO3RY5HyqDpEi/GIEeMc0UkZrGK2qiSMGJeANCPYoUkbnxXYd58C5CIUjXr/1fdf4zTixFcGBiiPZ6m7Nd6vBt3HN9OeNm6r3DOvbUAdMS3CL/Qzk= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Thu, 5 Jan 2017 23:26:15 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Thu, 5 Jan 2017 23:26:15 +0000 From: Henning Schulzrinne To: "Dawes, Peter, Vodafone Group" Thread-Topic: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted Thread-Index: AQHSW548qMD8vRge80+2+9lpYnPuvKEmvKsAgACZRLCAAPq4gIAAS2QAgAEbuoCAAOcfuQ== Date: Thu, 5 Jan 2017 23:26:14 +0000 Message-ID: References: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C45CC6@VOEXM31W.internal.vodafone.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C4710A@VOEXM31W.internal.vodafone.com> , <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D99C8C48022@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [199.168.151.39] x-ms-office365-filtering-correlation-id: a749ad1f-49e0-4192-18f9-08d435c23e42 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:lWdsf7p5mEjVLwpUcC+C33ppY8nYRvS3toAxNDAXXDQF0FFtcuQX5fewc+PITwpLW5SQ1Ohu+HGIOGRiwtB+GFSv0J1xqAV2mahMvlGzXJCvf43qf+oxk3BwzWxJqoAPKnnJ0ULP3ZHQEV0DZzp9dF2bOZ0mFcVoABBD5oTvi5DDn+nvtV3it1qkPpiYQJp3YLFjkNzPT8hcrxwjO+AWCkoZ7bar2hjfANelDM8YpcF3O8v49a18I5ScI+J0rZ1Gms4Vr50C3ksT0Y6hCCt0Cii35/5asrUfd8gSEYKEaW8u7vurzWP0AbWUuWP5/cQSORLwRi4g78V9yffmefW9VsG4rw0PzYlXIauzK+A/1WmQ7El+Jq/dHuge9iqJYEADa/rjbpWkWizNW3QccTMHStDRQjriNEU9TeR4by3RuZnbcctYGEx3y/IKYRiMj1Lz3k28MRT/Vq/GBueGGUHg8A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(67444318432085); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(199003)(189002)(3280700002)(229853002)(50986999)(99286003)(6116002)(8656002)(9686002)(230783001)(6436002)(97736004)(2906002)(5660300001)(4326007)(25786008)(122556002)(2900100001)(54896002)(8936002)(76176999)(106356001)(66066001)(3846002)(2950100002)(6916009)(3900700001)(3660700001)(19627405001)(33656002)(54356999)(81166006)(105586002)(92566002)(101416001)(74316002)(7696004)(8676002)(7736002)(68736007)(6606003)(55016002)(77096006)(81156014)(102836003)(86362001)(93886004)(110136003)(189998001)(106116001)(6506006)(38730400001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063403BB499B5EC14AE5736DEA600CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jan 2017 23:26:14.8097 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-05_17:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-unwanted X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 23:26:18 -0000 --_000_CY1PR09MB063403BB499B5EC14AE5736DEA600CY1PR09MB0634namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Added the phrase. ________________________________ From: Dawes, Peter, Vodafone Group Sent: Thursday, January 5, 2017 4:38 AM To: Henning Schulzrinne Cc: SIPCORE Subject: RE: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-status-un= wanted Thanks, I have read revision -01 and my comments are resolved. As a wording= suggestion for the last paragraph in section 6, I think adding the words "= of response code 666" as below makes the meaning clearer: "For both individually-authenticated and unauthenticated calls, recipients of response code 666 may want to distinguish responses sent b= efore and after the call has been answered, ascertaining whether either response timing suffers from a lower false-positive rate." Regards, Peter --_000_CY1PR09MB063403BB499B5EC14AE5736DEA600CY1PR09MB0634namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Added the phrase.

From: Dawes, Peter, Vodafon= e Group <Peter.Dawes@vodafone.com>
Sent: Thursday, January 5, 2017 4:38 AM
To: Henning Schulzrinne
Cc: SIPCORE
Subject: RE: [sipcore] Adopted / WGLC: draft-schulzrinne-dispatch-st= atus-unwanted
 

Thanks, I have read revision -01 and my comme= nts are resolved. As a wording suggestion for the last paragraph in section= 6, I think adding the words “of response code 666” as below ma= kes the meaning clearer:

 

“For both individually-authenticated and unauthenticated calls,
   rec=
ipients of response code 666 may want to distinguish responses sent before =
and after
   the=
 call has been answered, ascertaining whether either response
   tim=
ing suffers from a lower false-positive rate.”
 
Regards,
Peter

--_000_CY1PR09MB063403BB499B5EC14AE5736DEA600CY1PR09MB0634namp_-- From nobody Fri Jan 6 00:55:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3252129C7B for ; Fri, 6 Jan 2017 00:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LByz6TcuDX0 for ; Fri, 6 Jan 2017 00:55:36 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D814129C78 for ; Fri, 6 Jan 2017 00:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3SfkkGBsR7UPfSQTCBzYUAYlmJT6tkOohV/7+TvYV18=; b=SSxIANjZlI9OZ+EsnCrGKdNjN0wEnUWbQsVy2CoUC6BgPuZqOQkisOC1iFhidITu2VoxGifXiAikfCnTThDMOHPcK5P5R86sVBRRaUrzMdJIfMFLDVzXnW+WdApeQN0sV27OvVMBv41GboG/iFntu6EAVXBr5fhA6HcaWl8ER+w= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0180.outbound.protection.outlook.com [216.32.180.180]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-145-5uMXBIqyNbGPfiWH9e68vQ-1; Fri, 06 Jan 2017 03:55:33 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 6 Jan 2017 08:55:29 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Fri, 6 Jan 2017 08:55:29 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AQHSZu3dGYJ0jtsz5EmPEreSyl8iJqEp15kAgAAldrCAAIf2AIAAmsaQ Date: Fri, 6 Jan 2017 08:55:29 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 8e7de36e-7585-4feb-aafe-08d43611c3e3 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:xyjYgZAm+9tbE99B7NHNj5qIeW+Y2RFrbP0xGogcHxOYXFF/NTM5IdCBIzeaZgjuH7RKVesr1gPd1WZxVePYSnGM6AdRq/DhdScaU3G8HQObymY04WC5Db5aWpG55pIXKl25LbLuoqtVT5RLS0LjKdbycDu+DG582Qs+zbH/3cR7WCmfgZ2dQfCeRREyicTqkYpwpg1hsmkdg0V3KMosuoHoO/IItYvZ/mwCx0+hWMl4c1B6Bubeh0LlXlnYpd3LEH9o1YrEOvZ7q3wojH5MnM0vVZFpn5Z+uTFLdlnSNF1tKVsc2hzchKfIA/pMn2WiKpIDAWAR3NW8zhIwwnBl4ADUnToqTyXubIlYldhMgvE6dSHw68OFC0vgCdHac1joceCB3fq/YtpTK8ZIvwA+fYeJZee+a2LfvJ3BFiufv0U8FZ7+eS616dT0jJj23LeJfFUJj3wBVTYfOAoXuNZ0DQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524)(18271650672692)(21748063052155)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(199003)(13464003)(189002)(24454002)(377454003)(5001770100001)(93886004)(6306002)(606005)(106356001)(66066001)(38730400001)(5660300001)(7906003)(229853002)(6116002)(7696004)(575784001)(2950100002)(3280700002)(6506006)(3846002)(74316002)(6436002)(77096006)(92566002)(19609705001)(102836003)(55016002)(8936002)(33656002)(105586002)(81166006)(7736002)(2900100001)(97736004)(790700001)(86362001)(106116001)(99286003)(81156014)(54356999)(189998001)(9686002)(2501003)(3660700001)(68736007)(107886002)(122556002)(101416001)(54896002)(230783001)(76176999)(8676002)(2906002)(50986999)(25786008)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 08:55:29.3402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: 5uMXBIqyNbGPfiWH9e68vQ-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350705B809DCDDC8B7553DBB2630SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 08:55:39 -0000 --_000_SN2PR03MB2350705B809DCDDC8B7553DBB2630SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I think there is a difference between what "a call" means for end-user and = for the network: For the human agent, it is really nothing more than "Grandma called me". Fo= r the network, all the aspects you mentioned would come into play, e.g . wh= ich SIP information elements to use to identify the calling party etc.. It = could be useful to state this clearly. I agree that the definition of "Call" from RFC3261" seems adequate as far a= s human agent is concerned. I also agree that there is no need to artificia= lly limit the applicability just to "calls" -although I believe this would = cover 99% [99.9% if I dare to say] of the use cases-. It could be good to = continue using the term "call", reference RFC3261 definition of a "call" an= d add aa sentence along the lines of: "It should be noted that "666 unwanted" response code can be used for any S= IP request as long as it results a human agent observable stimulus, e.g. au= dial, visual or otherwise, on which the human agent can express his decisio= n to classify it as "unwanted". I think the proper meaning of "666 unwanted" is "the human agent considers = this particular call as unwanted" rather than "the human agent does not wan= t any further calls from this caller". It will be the network decision what= actions will be taken based on this input. Therefore, I think the current = wording in the draft should be changed as indicated in ii- below: "None of the existing 4xx, 5xx or 6xx response codes signify that calls fro= m this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." On another note: Is there a need to supply additional information as far as= different session types are concerned, e.g. audio call v.s. video call v.s= . IM? There could be situations where this is useful, e.g. human agent is f= ine with IM but does not want voice calls from a certain calling party. OTO= H, I think this again should be handled by the network itself and the chang= e I suggested above would be helpful in this sense as well: 666 means that = human agent considers this particular session as unwanted. It does not tell= anything more as far as other sessions of the same type or of other sessio= n types are concerned. He would communicate his choices regarding how this = information needs to be treated by other means, e.g. via a Web Portal, if s= uch a a service is provided by the operator. Thanks, Tolga From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 05, 2017 6:14 PM To: Asveren, Tolga ; Brett Tate ; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 On (i), I agree that we don't want to get into what information is being us= ed, given that the entity most likely to use the 666 information, i.e., the= terminating carrier, is also the one deciding how caller identity is being= presented to the user (PAI, From, etc.). Tastes may differ, but I don't see how we can say much that's useful to imp= lementors here, without getting into weeds that are already being explored = by (say) the SHAKEN effort. Also, I'm not convinced that defining "call" is needed here, given that we'= d probably not go much beyond what's in RFC 3261: Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Also, given the discussion of usage for non-INVITE, I'll change "call" to "= request" or "dialog" where the context is more than just an example of what= is likely to be the most common case - INVITE for a phone call. Henning ________________________________ From: sipcore > o= n behalf of Asveren, Tolga > Sent: Thursday, January 5, 2017 10:22:55 AM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I agree that defining what a "call" is a good idea but I have a different t= ake on what it should say: i- A "call" in the context of this document is a communication session as = perceived by a human agent, e.g. as in "I received a call from my grandmoth= er.". It does not imply anything further as far as SIP information elements= which usually are used to carry calling party identification, e.g. P-Asser= ted-Id, From headers, are concerned. It is up to the operator/network polic= y how to make associate further calls with the information/decision derived= from unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls= from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing th= e actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > Hi, > > I also agree that adding such a paragraph would be useful. > > For instance if someone desires a service to forward all received spam ca= lls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller= was. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh= 04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04= CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D --_000_SN2PR03MB2350705B809DCDDC8B7553DBB2630SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I think there is a difference between what “a= call” means for end-user and for the network:

For the human agent, it is really nothing more than= “Grandma called me”. For the network, all the aspects you ment= ioned would come into play, e.g . which SIP information elements to use to identify the calling party etc.. It could be useful to state thi= s clearly.

 

I agree that the definition of “Call” f= rom RFC3261” seems adequate as far as human agent is concerned. I als= o agree that there is no need to artificially limit the applicability just to “calls” -although I believe this would cover 99%  = ;[99.9% if I dare to say] of the use cases-. It could be good to continue u= sing the term “call”, reference RFC3261 definition of a “= call” and add aa sentence along the lines of:

“It should be noted that “666 unwanted&= #8221; response code can be used for any SIP request as long as it results = a human agent observable stimulus, e.g. audial, visual or otherwise, on which the human agent can express his decision to classify it as “= ;unwanted”.

 

I think the proper meaning of “666 unwanted&#= 8221; is “the human agent considers this particular call as unwanted&= #8221; rather than “the human agent does not want any further calls f= rom this caller”. It will be the network decision what actions will be t= aken based on this input. Therefore, I think the current wording in the dra= ft should be changed as indicated in ii- below:

"None of the existing 4xx, 5xx or 6xx response= codes signify that calls from this caller are unwanted by the called party= ."

=3D=3D>

"None of the existing 4xx, 5xx or 6xx response= codes signify that this call is unwanted by the called party."

 

On another note: Is there a need to supply addition= al information as far as different session types are concerned, e.g. audio = call v.s. video call v.s. IM? There could be situations where this is useful, e.g. human agent is fine with IM but does not want v= oice calls from a certain calling party. OTOH, I think this again should be= handled by the network itself and the change I suggested above would be he= lpful in this sense as well: 666 means that human agent considers this particular session as unwanted. It d= oes not tell anything more as far as other sessions of the same type or of = other session types are concerned. He would communicate his choices regardi= ng how this information needs to be treated by other means, e.g. via a Web Portal, if such a a service is p= rovided by the operator.

 

Thanks,

Tolga

 

From: Henning Schulzrinne [mailto:He= nning.Schulzrinne@fcc.gov]
Sent: Thursday, January 05, 2017 6:14 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; Brett Tate <bre= tt@broadsoft.com>; sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

O= n (i), I agree that we don't want to get into what information is being use= d, given that the entity most likely to use the 666 information, i.e., the = terminating carrier, is also the one deciding how caller identity is being presented to the user (PAI, From, etc.).=

<= o:p> 

T= astes may differ, but I don't see how we can say much that's useful to impl= ementors here, without getting into weeds that are already being explored b= y (say) the SHAKEN effort.

<= o:p> 

A= lso, I'm not convinced that defining "call" is needed here, given= that we'd probably not go much beyond what's in RFC 3261:

<= o:p> 

Call: A call is an informal term that refers to some communicatio=
n
       =
  between peers, generally set up for the purposes of a
       =
  multimedia conversation.

Also, given the discussion of usage for non-INVITE, I'll= change "call" to "request" or "dialog" where= the context is more than just an example of what is likely to be the most = common case - INVITE for a phone call.

<= o:p> 

H= enning

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of Asveren, Tolga <t= asveren@sonusnet.com>
Sent: Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; sipcore@ietf.org=
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I agree that defini= ng what a "call" is a good idea but I have a different take on wh= at it should say:

i-  A "call" in the context of this document is a communicat= ion session as perceived by a human agent, e.g. as in "I received a ca= ll from my grandmother.". It does not imply anything further as far as= SIP information elements which usually are used to carry calling party identification, e.g. P-Asserted-Id, From headers, are concer= ned. It is up to the operator/network policy how to make associate further = calls with the information/decision derived from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx response codes signify that = calls from this caller are unwanted by the called party."
=3D=3D>
"None of the existing 4xx, 5xx or 6xx response codes signify that this= call is unwanted by the called party."

I think ii- is needed to relive the end user from the burden of "knowi= ng the actual caller".

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:sipc= ore-bounces@ietf.org] On Behalf Of Brett Tate
> Sent: Thursday, January 05, 2017 7:54 AM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-= 01
>
> Hi,
>
> I also agree that adding such a paragraph would be useful.
>
> For instance if someone desires a service to forward all received spam= calls to
> another set of victims, they would likely not use such a service if th= e
> forwarding party might also get flagged as part of the 666 handling. >
>
> > -----Original Message-----
> > From: sipcore [mailto= :sipcore-bounces@ietf.org] On Behalf Of Paul
> Kyzivat
> > Sent: Wednesday, January 04, 2017 7:51 PM
> > To: sipcore@ietf.org
> > Subject: Re: [sipcore] Comments on
> > draft-ietf-sipcore-status-unwanted-01
> >
> > On 1/4/17 5:35 PM, = marianne.mohali@orange.com wrote:
> >
> > > -Section 4 general:
> > > IMO, it would be good to have a paragraph addressing the que= stion of
> > > the "calling party number" (mentioned several time= in the document):
> > > indeed, this calling party number can be identified by the t= elephone
> > > number/address in the From header or the one in the
> > > P-Asserted-Identity header that may be different. Depending = on the
> > > one displayed to the called UA, the 666 could concern only o= ne or
> > > both addresses depending on service provider choices. If we = take the
> > > example of a call-center or an IPBX having the head number a= nd a
> > > range of private numbers, the service provider could interpr= et the
> > > 666 from the called user only for the private number (in the= From
> > > header) or for the whole pool (P-Asserted-Identity). I sugge= st to
> > > have a paragraph to highlight this point.
> >
> > Interesting point. If the PAID is different from the number displ= ayed
> > to
> the
> > callee, and the callee rejects the call without answering, how sh= ould
> "blame"
> > be assigned? From the calllee's perspective the complaint is *abo= ut*
> > the number he saw, regardless of what the identity of the actual = caller was.
> >
> >      Thanks,
> >      Paul
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F= 0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e= =3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F= 0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e= =3D

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8b= cHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9= ko1LYaC5NY&e=3D

--_000_SN2PR03MB2350705B809DCDDC8B7553DBB2630SN2PR03MB2350namp_-- From nobody Fri Jan 6 03:57:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840E5129AF2 for ; Fri, 6 Jan 2017 03:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48uDUF3gATjm for ; Fri, 6 Jan 2017 03:57:49 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 222FA12946E for ; Fri, 6 Jan 2017 03:57:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GePHAqIj3RIkX2JCC1EIkQn7hn9AKJ+B+vKf82muz2Y=; b=hCzJAgH9I3GPOFX2QGmZMfH9m9AVm/qzKE97H27cyNrnCh/kPQSeI3iBbS5bLp7fURcjHnp7V3WopEtJkEsklDJhfFYCsi7cIceJPIoUEDY8BImvR9fQDDJGKk0YOlpcb4QuW3zdPAixrbmALTGbSB5KVIUcEm6D4Hi+3HJGYqk= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-22-DRvZRAilOJGDfJVKWYYCdQ-1; Fri, 06 Jan 2017 06:57:44 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 6 Jan 2017 11:57:42 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Fri, 6 Jan 2017 11:57:42 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAzSmHSABhRyoA= Date: Fri, 6 Jan 2017 11:57:42 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 8e1d42db-492d-4909-5e1a-08d4362b38ac x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:1CznOA6ezVr46cJ6qWACPrl/ymuVintq5hRPkVltBrHfmkey9kSxAIAD45b+18LnMIcstNZijzFk4JvEPPiIFLDcs38yfI4faenmUftuC0EKAWPA6z7m1OkyaRCn/qxgOwJJU8nic0aod51BMYyRECoL12qW0aiTpSPLhELsFMaQy6tJEZagkN9Pii7lh8P37UTA43dsD+qD+8w3bm24A/QHfPeoz6OrxocSBKNYOKg+Bi6HYHV7cIwDFDusgw5hnNb9kqjgmZZGvsEtSHaLy36l1zJel6J+eV+RWj6ntd74AHAcmXQ3x3SmRYw/jdq9A1oZJiDeKutR0j70HSlONH6eUHYQQpXYx7meerDi7bpg1x81rTuYACFg4Ozu8aXt/zkbbXvS2BEtmhUEHcwI++g4a6IzBMbbWfDAWyGFKbaDcKlY0yxgJOdf9KXv7wCsqncpUgs0BJrT+Za5heotUA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123555025)(20161123558021)(20161123562025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(76176999)(6306002)(2201001)(230783001)(33656002)(3280700002)(122556002)(81156014)(7736002)(2950100002)(3846002)(99286003)(25786008)(19609705001)(106356001)(77096006)(38730400001)(2501003)(6506006)(66066001)(790700001)(7696004)(9686002)(7906003)(68736007)(55016002)(606005)(2906002)(3660700001)(229853002)(86362001)(97736004)(189998001)(101416001)(102836003)(5001770100001)(6436002)(74316002)(107886002)(8676002)(54896002)(81166006)(6116002)(92566002)(8936002)(5660300001)(2900100001)(54356999)(105586002)(50986999)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 11:57:42.5814 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: DRvZRAilOJGDfJVKWYYCdQ-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350730062B8ECF34FFB1B83B2630SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 11:57:51 -0000 --_000_SN2PR03MB2350730062B8ECF34FFB1B83B2630SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable As indicated on another thread, I don't think "technical" definition of a "= caller identity" is needed -and actually misleading IMHO considering the pu= rpose of "666 unwanted", but if it really goes through, Service-URN, 3GPP-U= RN (and possibly more) should be mentioned as well. But I really do hope that we won't end up there. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Thursday, January 05, 2017 5:45 PM To: marianne.mohali@orange.com; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use the term "calle= r identity" or "calling party identity", defined as An identity, for the purposes of this document, is defined as either a canonical address-of-record (AoR) SIP URI employed to reach a user (such as 'sip:alice@atlanta.example.com'), or a telephone number, which commonly appears in either a TEL URI [RFC3966] or as the user portion of= a SIP URI. This avoids the awkward "number or address", particularly given that "addre= ss" isn't really a formal SIP term and "SIP URI" may not be generic enough. ________________________________ From: sipcore > o= n behalf of marianne.mohali@orange.com <= marianne.mohali@orange.com> Sent: Wednesday, January 4, 2017 5:35 PM To: sipcore@ietf.org Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, I have the following comments on v01: -Section 4 - 4rd paragraph: The actions described here do not depend on the nature of the SIP URI, e.g., whether it describes a telephone number or not but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"? -Section 4 - last paragraph: We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that the corresponding proxy supports th= is particular response code. I would suggest: "This document defines a new SIP feature-capability indica= tor [RFC6809] value, sip.666, that ... -Section 4 general: IMO, it would be good to have a paragraph addressing the question of the "c= alling party number" (mentioned several time in the document): indeed, this= calling party number can be identified by the telephone number/address in = the From header or the one in the P-Asserted-Identity header that may be di= fferent. Depending on the one displayed to the called UA, the 666 could con= cern only one or both addresses depending on service provider choices. If w= e take the example of a call-center or an IPBX having the head number and a= range of private numbers, the service provider could interpret the 666 fro= m the called user only for the private number (in the From header) or for t= he whole pool (P-Asserted-Identity). I suggest to have a paragraph to highl= ight this point. -Section 6: calling party number / calling party address Best regards, Marianne --_000_SN2PR03MB2350730062B8ECF34FFB1B83B2630SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

As indicated on another thread, I don’t think= “technical” definition of a “caller identity” is n= eeded -and actually misleading IMHO considering the purpose of “666 u= nwanted”, but if it really goes through, Service-URN, 3GPP-URN (and possibly more) s= hould be mentioned as well.

 

But I really do hope that we won’t end up the= re.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Thursday, January 05, 2017 5:45 PM
To: marianne.mohali@orange.com; sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I= 'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use the term &q= uot;caller identity" or "calling party identity", defined as=

<= o:p> 

An identity, =
for the purposes of this document, is
   defined as either a canonical=
 address-of-record (AoR) SIP URI
   employed to reach a user (suc=
h as 'sip:alice@atlanta.example.com'),
   or a telephone number, which =
commonly appears in either a TEL URI
   [RFC3966] or as the user portion of a SIP URI.

 


This avoids the awkward "number or address", particularly given t= hat "address" isn't really a formal SIP term and "SIP URI&qu= ot; may not be generic enough.

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of marianne.mohali= @orange.com <marianne.= mohali@orange.com>
Sent: Wednesday, January 4, 2017 5:35 PM
To: sipcore@ietf.org
Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=

 

Hi,

I have the following comments on v01:

-Section 4 - 4rd paragraph:
        The actions described here do no= t depend on the nature of the SIP
         URI, e.g., whether it desc= ribes a telephone number or not
but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"= ;?

-Section 4 - last paragraph:
        We define a SIP feature-capabili= ty [RFC6809], sip.666, that allows
         the registrar to indicate = that the corresponding proxy supports this
         particular response code.<= br> I would suggest: "This document defines a new SIP feature-capability i= ndicator [RFC6809] value, sip.666, that ...

-Section 4 general:
IMO, it would be good to have a paragraph addressing the question of the &q= uot;calling party number" (mentioned several time in the document): in= deed, this calling party number can be identified by the telephone number/a= ddress in the From header or the one in the P-Asserted-Identity header that may be different. Depending on the one dis= played to the called UA, the 666 could concern only one or both addresses d= epending on service provider choices. If we take the example of a call-cent= er or an IPBX having the head number and a range of private numbers, the service provider could interpret the 6= 66 from the called user only for the private number (in the From header) or= for the whole pool (P-Asserted-Identity). I suggest to have a paragraph to= highlight this point.

-Section 6:
calling party number / calling party address


Best regards,
Marianne

--_000_SN2PR03MB2350730062B8ECF34FFB1B83B2630SN2PR03MB2350namp_-- From nobody Fri Jan 6 07:04:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3722612954B for ; Fri, 6 Jan 2017 07:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQGQAfo7H0X3 for ; Fri, 6 Jan 2017 07:04:36 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4798B129542 for ; Fri, 6 Jan 2017 07:04:36 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-11v.sys.comcast.net with SMTP id PW2McF3KyZxnDPW4IcjlJ6; Fri, 06 Jan 2017 15:04:34 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-14v.sys.comcast.net with SMTP id PW4Hc9NjWZ8INPW4Ichzxm; Fri, 06 Jan 2017 15:04:34 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v06F4Vt2026997; Fri, 6 Jan 2017 10:04:31 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v06F4VJX026994; Fri, 6 Jan 2017 10:04:31 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Henning Schulzrinne In-Reply-To: (Henning.Schulzrinne@fcc.gov) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 06 Jan 2017 10:04:31 -0500 Message-ID: <877f68dybk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfGVGxI7m6+JxCw++ltukWEyuzgD1cGCYjMvSrOK9ykDEvY84luT1/wjs/iwfz2nLWK1p8ZzuiIYP8umG7M2/LbfprkpIORAiDqPkWFmmA0ZQRoDW0YIp A6b9G9xyQ2NGIujORp4VHVx0QwHGOyZlyWd+66g4RAnZJS5mfGCdlLRxCuOuVWDkNK6DbdW9U7zWpw/FxcGDLWzjdx513MpVgXg= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:04:37 -0000 Henning Schulzrinne writes: > Are you talking about the case where the end system itself does the > blocking, e.g., via an app (e.g., Hiya or Nomorobo)? > > Leaving aside Martin's concerns for a moment, I admit that I'm not > convinced that this distinction is meaningful. For example, an app or > dialer may have a personal blacklist (I believe Android does). This is > something done by the user, not AI (so Martin may like it...), but the > dialer would be responding with a 666 on the next call to signal the > reason for the rejection. Is that a robot instead? What if the app > just suggests that this is a "bad" call and the user hits the spam > button? I admit that I have a hard time drawing a firm line that would > provide sufficient guidance to implementors to choose one status code > or the other. I'm using a model that resembles how I think spam filtering works: the user's SIP service monitors the calls for which the user triggers 666. Based on this, it constructs a filter for which calls will be presented to the user. The calls that are rejected aren't rejected specifically because the user has specified that they are to be rejected, but based on the filter. So there will be occasional mistakes. It seems like it would be useful to notify the caller that the call was rejected based on such a filter. > This seems like something we could discuss once we have a bit more > operational experience. Maybe a "Warning" code would be the more > appropriate means of conveying such additional information, for > example. Hmmm, looking at the drarft again, the specifics of blocking, or even whether blocking is done, are out of scope. But I like your proposal of a Warning code. And we might need more than one Warning code, if this situation turns out to be more complicated. Dale From nobody Fri Jan 6 07:28:35 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C737129568 for ; Fri, 6 Jan 2017 07:28:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcTqmAwX44O7 for ; Fri, 6 Jan 2017 07:28:27 -0800 (PST) Received: from relais-inet.orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46EFB129566 for ; Fri, 6 Jan 2017 07:28:27 -0800 (PST) Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 5B4E960A33; Fri, 6 Jan 2017 16:28:25 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.59]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 38F4E180040; Fri, 6 Jan 2017 16:28:25 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM43.corporate.adroot.infra.ftgroup ([fe80::ec23:902:c31f:731c%19]) with mapi id 14.03.0319.002; Fri, 6 Jan 2017 16:28:24 +0100 From: To: Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAzSmHSABZRBYA= Date: Fri, 6 Jan 2017 15:28:23 +0000 Message-ID: <25465_1483716505_586FB799_25465_5025_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923OPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:28:29 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923OPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I am in favor of terms "caller identity" or "calling party identity". BR, Marianne De : Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Envoy=E9 : jeudi 5 janvier 2017 23:45 =C0 : MOHALI Marianne IMT/OLN; sipcore@ietf.org Objet : Re: Comments on draft-ietf-sipcore-status-unwanted-01 I'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use the term "calle= r identity" or "calling party identity", defined as An identity, for the purposes of this document, is defined as either a canonical address-of-record (AoR) SIP URI employed to reach a user (such as 'sip:alice@atlanta.example.com'), or a telephone number, which commonly appears in either a TEL URI [RFC3966] or as the user portion of= a SIP URI. This avoids the awkward "number or address", particularly given that "addre= ss" isn't really a formal SIP term and "SIP URI" may not be generic enough. ________________________________ From: sipcore > o= n behalf of marianne.mohali@orange.com <= marianne.mohali@orange.com> Sent: Wednesday, January 4, 2017 5:35 PM To: sipcore@ietf.org Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, I have the following comments on v01: -Section 4 - 4rd paragraph: The actions described here do not depend on the nature of the SIP URI, e.g., whether it describes a telephone number or not but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"? -Section 4 - last paragraph: We define a SIP feature-capability [RFC6809], sip.666, that allows the registrar to indicate that the corresponding proxy supports th= is particular response code. I would suggest: "This document defines a new SIP feature-capability indica= tor [RFC6809] value, sip.666, that ... -Section 4 general: IMO, it would be good to have a paragraph addressing the question of the "c= alling party number" (mentioned several time in the document): indeed, this= calling party number can be identified by the telephone number/address in = the From header or the one in the P-Asserted-Identity header that may be di= fferent. Depending on the one displayed to the called UA, the 666 could con= cern only one or both addresses depending on service provider choices. If w= e take the example of a call-center or an IPBX having the head number and a= range of private numbers, the service provider could interpret the 666 fro= m the called user only for the private number (in the From header) or for t= he whole pool (P-Asserted-Identity). I suggest to have a paragraph to highl= ight this point. -Section 6: calling party number / calling party address Best regards, Marianne ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923OPEXCLILMA4corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I am in fa= vor of terms "caller identity" or "calling party identity&qu= ot;.

 

BR,

Marianne

 = ;

De : Henn= ing Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Envoy=E9 : jeudi 5 janvier 2017 23:45
=C0 : MOHALI Marianne IMT/OLN; sipcore@ietf.org
Objet : Re: Comments on draft-ietf-sipcore-status-unwanted-01

 

I'm tempted to follow draft-ietf-stir-rfc4474bis-15 and use= the term "caller identity" or "calling party identity"= , defined as

 

An identity, =
for the purposes of this document, is
   defined as either a canonical=
 address-of-record (AoR) SIP URI
   employed to reach a user (suc=
h as 'sip:alice@atlanta.example.com'),
   or a telephone number, which =
commonly appears in either a TEL URI
   [RFC3966] or as the user portion of a SIP URI.

 


This avoids the awkward "number or address", particularly given t= hat "address" isn't really a formal SIP term and "SIP URI&qu= ot; may not be generic enough.

From: sipcore <s= ipcore-bounces@ietf.org> on behalf of marianne.mohali= @orange.com <marianne.= mohali@orange.com>
Sent: Wednesday, January 4, 2017 5:35 PM
To: sipcore@ietf.org
Subject: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=

 

Hi,

I have the following comments on v01:

-Section 4 - 4rd paragraph:
        The actions described here do no= t depend on the nature of the SIP
         URI, e.g., whether it desc= ribes a telephone number or not
but in the rest of the document only telephone numbers are mentioned. It wo= uld be good to reflect this by using "telephone number or address"= ;?

-Section 4 - last paragraph:
        We define a SIP feature-capabili= ty [RFC6809], sip.666, that allows
         the registrar to indicate = that the corresponding proxy supports this
         particular response code.<= br> I would suggest: "This document defines a new SIP feature-capability i= ndicator [RFC6809] value, sip.666, that ...

-Section 4 general:
IMO, it would be good to have a paragraph addressing the question of the &q= uot;calling party number" (mentioned several time in the document): in= deed, this calling party number can be identified by the telephone number/a= ddress in the From header or the one in the P-Asserted-Identity header that may be different. Depending on the one dis= played to the called UA, the 666 could concern only one or both addresses d= epending on service provider choices. If we take the example of a call-cent= er or an IPBX having the head number and a range of private numbers, the service provider could interpret the 6= 66 from the called user only for the private number (in the From header) or= for the whole pool (P-Asserted-Identity). I suggest to have a paragraph to= highlight this point.

-Section 6:
calling party number / calling party address


Best regards,
Marianne

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923OPEXCLILMA4corp_-- From nobody Fri Jan 6 07:28:47 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA02812957D for ; Fri, 6 Jan 2017 07:28:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.018 X-Spam-Level: X-Spam-Status: No, score=-5.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JVT7ADBEWXdk for ; Fri, 6 Jan 2017 07:28:31 -0800 (PST) Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF2F129568 for ; Fri, 6 Jan 2017 07:28:30 -0800 (PST) Received: from opfedar07.francetelecom.fr (unknown [xx.xx.xx.9]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 5E63A60BCC; Fri, 6 Jan 2017 16:28:29 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfedar07.francetelecom.fr (ESMTP service) with ESMTP id 3D7BBC0052; Fri, 6 Jan 2017 16:28:29 +0100 (CET) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0319.002; Fri, 6 Jan 2017 16:28:28 +0100 From: To: Henning Schulzrinne , "Asveren, Tolga" , Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAADYj0AABk5kQAABTb/gAAQdn8AABdyLpA= Date: Fri, 6 Jan 2017 15:28:28 +0000 Message-ID: <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A492AOPEXCLILMA4corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:28:35 -0000 --_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A492AOPEXCLILMA4corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, To reflect the question of the interpretation of the 666 response interpret= ation when the caller has several identities used for this call (ie. From a= nd P-Asserted-Identity are different) or call forwarding/call transfer use = cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I = propose to add the following text: This document defines a mechanism by which a called party can reject an unw= anted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity ma= y be reflected in different way for a direct call or after a diverting serv= ice in P-Asserted-Identity, From, History-Info or any concurrent header fie= ld that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are= a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Henning Schulz= rinne Envoy=E9 : vendredi 6 janvier 2017 00:14 =C0 : Asveren, Tolga; Brett Tate; sipcore@ietf.org Objet : Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 On (i), I agree that we don't want to get into what information is being us= ed, given that the entity most likely to use the 666 information, i.e., the= terminating carrier, is also the one deciding how caller identity is being= presented to the user (PAI, From, etc.). Tastes may differ, but I don't see how we can say much that's useful to imp= lementors here, without getting into weeds that are already being explored = by (say) the SHAKEN effort. Also, I'm not convinced that defining "call" is needed here, given that we'= d probably not go much beyond what's in RFC 3261: Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Also, given the discussion of usage for non-INVITE, I'll change "call" to "= request" or "dialog" where the context is more than just an example of what= is likely to be the most common case - INVITE for a phone call. Henning ________________________________ From: sipcore > o= n behalf of Asveren, Tolga > Sent: Thursday, January 5, 2017 10:22:55 AM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I agree that defining what a "call" is a good idea but I have a different t= ake on what it should say: i- A "call" in the context of this document is a communication session as = perceived by a human agent, e.g. as in "I received a call from my grandmoth= er.". It does not imply anything further as far as SIP information elements= which usually are used to carry calling party identification, e.g. P-Asser= ted-Id, From headers, are concerned. It is up to the operator/network polic= y how to make associate further calls with the information/decision derived= from unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls= from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing th= e actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > Hi, > > I also agree that adding such a paragraph would be useful. > > For instance if someone desires a service to forward all received spam ca= lls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller= was. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh= 04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04= CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A492AOPEXCLILMA4corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,<= o:p>

 

To r= eflect the question of the interpretation of the 666 response interpretatio= n when the caller has several identities used for this call (ie. From and P= -Asserted-Identity are different) or call forwarding/call transfer use cases for which it has to be discussed which = party should be considered has a fraudulent (ie. the calling party or the d= iverting party or both ?) ; I propose to add the following text:=

This= document defines a mechanism by which a called party can reject an unwante= d call without consideration of the calling party identification that remai= n to the service provider policy. Indeed, the calling party identity may be reflected in different way for a direct = call or after a diverting service in P-Asserted-Identity, From, History-Inf= o or any concurrent header field that can be present at the same time in a = SIP message.

 

Thos= e questions are real issues for operators and implementors and they are a w= eakness that fraudulent callers could use to bypass the mechanism.

 

BR,<= o:p>

Mari= anne

 = ;

De : sipc= ore [mailto:sipcore-bounces@ietf.org] De la part de Henning Schulzrinne
Envoy=E9 : vendredi 6 janvier 2017 00:14
=C0 : Asveren, Tolga; Brett Tate; sipcore@ietf.org
Objet : Re: [sipcore] Comments on draft-ietf-sipcore-status-unw= anted-01

 

On (i), I agree that we don't want to get into what information = is being used, given that the entity most likely to use the 666 information= , i.e., the terminating carrier, is also the one deciding how caller identity is being presented to the user (PAI, From, etc.).=

 

Tastes may differ, but I don't see how we can say much that's us= eful to implementors here, without getting into weeds that are already bein= g explored by (say) the SHAKEN effort.

 

Also, I'm not convinced that defining "call" is needed= here, given that we'd probably not go much beyond what's in RFC 3261:=

 

Call: A call is an informal term that refers to some communicatio=
n
       =
  between peers, generally set up for the purposes of a
       =
  multimedia conversation.

Also, given the discussion of usage for non-= INVITE, I'll change "call" to "request" or "dialog= " where the context is more than just an example of what is likely to = be the most common case - INVITE for a phone call.

 

Henning

From: sipcore <sipcore-bounces@ietf.org> on behalf of Asveren, Tolga <tasveren@sonusnet.com>
Sent: Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I agree that defini= ng what a "call" is a good idea but I have a different take on wh= at it should say:

i-  A "call" in the context of this document is a communicat= ion session as perceived by a human agent, e.g. as in "I received a ca= ll from my grandmother.". It does not imply anything further as far as= SIP information elements which usually are used to carry calling party identification, e.g. P-Asserted-Id, From headers, are concer= ned. It is up to the operator/network policy how to make associate further = calls with the information/decision derived from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx response codes signify that = calls from this caller are unwanted by the called party."
=3D=3D>
"None of the existing 4xx, 5xx or 6xx response codes signify that this= call is unwanted by the called party."

I think ii- is needed to relive the end user from the burden of "knowi= ng the actual caller".

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:sipcore-bounces@ie= tf.org] O= n Behalf Of Brett Tate
> Sent: Thursday, January 05, 2017 7:54 AM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-= 01
>
> Hi,
>
> I also agree that adding such a paragraph would be useful.
>
> For instance if someone desires a service to forward all received spam= calls to
> another set of victims, they would likely not use such a service if th= e
> forwarding party might also get flagged as part of the 666 handling. >
>
> > -----Original Message-----
> > From: sipcore [mailto:sipcore-bounc= es@ietf.org] On Behalf Of Paul
> Kyzivat
> > Sent: Wednesday, January 04, 2017 7:51 PM
> > To: sipcore@ietf.org
> > Subject: Re: [sipcore] Comments on
> > draft-ietf-sipcore-status-unwanted-01
> >
> > On 1/4/17 5:35 PM, marianne.mohal= i@orange.com wrote:
> >
> > > -Section 4 general:
> > > IMO, it would be good to have a paragraph addressing the que= stion of
> > > the "calling party number" (mentioned several time= in the document):
> > > indeed, this calling party number can be identified by the t= elephone
> > > number/address in the From header or the one in the
> > > P-Asserted-Identity header that may be different. Depending on the
> > > one displayed to the called UA, the 666 could concern only o= ne or
> > > both addresses depending on service provider choices. If we = take the
> > > example of a call-center or an IPBX having the head number a= nd a
> > > range of private numbers, the service provider could interpr= et the
> > > 666 from the called user only for the private number (in the= From
> > > header) or for the whole pool (P-Asserted-Identity). I sugge= st to
> > > have a paragraph to highlight this point.
> >
> > Interesting point. If the PAID is different from the number displ= ayed
> > to
> the
> > callee, and the callee rejects the call without answering, how sh= ould
> "blame"
> > be assigned? From the calllee's perspective the complaint is *abo= ut*
> > the number he saw, regardless of what the identity of the actual = caller was.
> >
> >      Thanks,
> >      Paul
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf= .org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw= &r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB= 4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1L= YaC5NY&e=3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_= mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&= r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5s= gh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5N= Y&e=3D

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense= .proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_sipcore&= amp;d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8l= DU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&= amp;s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_8B970F90C584EA4E97D5BAAC9172DBB81C8A492AOPEXCLILMA4corp_-- From nobody Fri Jan 6 07:37:09 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C60E129B1A for ; Fri, 6 Jan 2017 07:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kWaUjklE3l8 for ; Fri, 6 Jan 2017 07:36:53 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0C65129B20 for ; Fri, 6 Jan 2017 07:36:51 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v06FabwG054262 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 6 Jan 2017 09:36:38 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: marianne.mohali@orange.com, "Drage, Keith (Nokia - GB)" , Paul Kyzivat , "sipcore@ietf.org" References: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD17F6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <19964_1483635715_586E7C03_19964_3476_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A34AE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Adam Roach Message-ID: <80d6f674-2ded-75be-bec3-2de9e1414e53@nostrum.com> Date: Fri, 6 Jan 2017 09:36:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <19964_1483635715_586E7C03_19964_3476_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A34AE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 15:36:55 -0000 [as individual] I think the error is in 3312, but it's not the flaw being discussed here. The error was in allowing 3312 to specify that a CANCEL can have a body. While it's not stated normatively in English prose, the line of Table 2 that you cite has been broadly interpreted to mean that CANCEL cannot contain a body. The description of CANCEL handling at proxies does not involve any steps that would copy the body from an incoming CANCEL to an outgoing one. This has been a long-standing interpretation, dating back to approximately the same era as RFC3261's own publication. See, for example: https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-January/021232.html and https://www.ietf.org/mail-archive/web/sip/current/msg07810.html What this means is: from a practical perspective, it is highly unlikely that a CANCEL body will survive the first proxy it hits. So I think the action here is to file an erratum that removes the text from 3312 that suggests putting a body in a CANCEL message. /a On 1/5/17 11:01, marianne.mohali@orange.com wrote: > Hi, > > I don't want to re-open the discussion on the Tables (I also heard that they are now deprecated). > I agreed that RFC3261 comes first so it should have been stated in RFC3312 that RFC3312 also update the 3261 table. > > I would propose to have an errata to RFC3312 adding this clarification. > Any other view? > > BR, > Marianne > > -----Message d'origine----- > De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Drage, Keith (Nokia - GB) > Envoyé : jeudi 5 janvier 2017 17:04 > À : Paul Kyzivat; sipcore@ietf.org > Objet : Re: [sipcore] Errata to RFC3261 > > I think this is actually addressing the wrong document. > > RFC 3261 is correct in its own right. > > It is when it is used in conjunction with RFC 3312 that the problem occurs, and therefore the correction should be made to RFC 3312 to update RFC 3261 in this respect. > > Keith > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 05 January 2017 15:38 > To: sipcore@ietf.org > Subject: Re: [sipcore] Errata to RFC3261 > > On 1/5/17 10:19 AM, Dale R. Worley wrote: >> writes: >>> I would like to submit an errata to RFC3261 on the following point: >>> >>> RFC 3261 (section 20 Table 2) states that Content-Type header is not >>> applicable to the CANCEL method (meaning that a CANCEL must not >>> contain a body). >>> "580 (Precondition Failure) responses and BYE and CANCEL requests, >>> indicating failure to meet certain preconditions, SHOULD contain an >>> SDP description, indicating which desired status triggered the >>> failure. Note that this SDP description is not an offer or an >>> answer, since it does not lead to the establishment of a session. >>> The format of such a description is based on the last SDP (an offer >>> or an answer) received from the remote UA." >> This isn't really an erratum for 3261 as a clarification that 3312 >> updates the table in 3261. >> >> But I remember there was a discussion some years ago about maintaining >> the tables in 3261 and there was some sort of decision to no longer do >> that, as almost every SIP RFC entailed modifying the tables. >> >> Does anyone remember the details of that discussion? > I can't recall the *details*, but as I remember it the gist was that table 2 is insufficient to characterize the nuances that often need to be expressed. So, rather than attempt to maintain table 2 the conclusion was that documents should express the constraints individually, typically with text. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jan 6 09:32:26 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3551A129B73 for ; Fri, 6 Jan 2017 09:32:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq0CardpMI8J for ; Fri, 6 Jan 2017 09:32:22 -0800 (PST) Received: from mx0b-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CFE8129D18 for ; Fri, 6 Jan 2017 09:32:22 -0800 (PST) Received: from pps.filterd (m0103508.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v06HOKrg012208 for ; Fri, 6 Jan 2017 12:32:21 -0500 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0b-001d8301.pphosted.com with ESMTP id 27sxgfhuk0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 06 Jan 2017 12:32:21 -0500 Received: by mail-lf0-f70.google.com with SMTP id b200so18233015lfe.0 for ; Fri, 06 Jan 2017 09:32:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=IdbV1dd5VhWovcdO08f4bj1sPUthU7/KF6xa4/1fE/Q=; b=qknxv5LI/j1eUxB3JhVPU90WlP1dvR1cHjrm3/MT9VCNbVeUeX8gUzhJfztDvZ3QJQ b/TSO8icllGUMo1HUtxiEtoQ2Y6rvXCT/sSF6DzIIQz//s2T1LzLIlLSB3kHFRM5zYrW dL5DY3IlK8cD/bV9JGD5x3/r7u6BsB1jeVckV67f6UsisZcSuxxwy8zZAjc6ZbAbSSXp crkzd45y2nRnd60Q6LcOe3/dEa/znGihgMClVxB0jnYBBytgNlDHm54x/x4viZHM9e2W UBGkN+EHtPTjMM2PSz2MDo3kazU1BlZLyKmS464vCYfQDC3TwELrfMFGKo7D/VhgQmyJ M/ZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=IdbV1dd5VhWovcdO08f4bj1sPUthU7/KF6xa4/1fE/Q=; b=rwnLEGZfVeIETiPvOkSPAF4YhPcn5nbuFid6JZkL3+peDMm9yg9B5Wdm16RTQSLn8u P1B6zveYzv5EY1ce4+hV7SHAvm7PQso/PQIPJVZAaDwz5SgcVmDCaTfP2mJXI1I4XO8W +fZvjWmtByGlBf+DG5mJJNkhYNVaqmt11W/Z+kodi2EWYPlezmF5yP3wKESlL9N/Ryka MECSQkv8jviJl56qXNST5E5u1IZ0gc20VkTd+kBAaBXTmQppkTUWzxB4q79gPwjAqCKh 11Rtcwy+HSMy3Ocenj63kzSxnU/epmOaq+vKiif02TLqH5zRPznwQ8V0FNiDPw1Za02t WRjg== X-Gm-Message-State: AIkVDXKcBrlnxKPWAGcMXLbDUaLgIe7fe+7hTXAyxO0j5xOje4GQG1W4zzzo99/g3Lwfo0KM8fg5+W675isLj/Me62qBnWvyD6zAW7L1Ciat7LuIBG0kEBUh2CrqRpv+O6g4u+DXZp1elN2h X-Received: by 10.25.56.18 with SMTP id f18mr2804987lfa.164.1483723939047; Fri, 06 Jan 2017 09:32:19 -0800 (PST) X-Received: by 10.25.56.18 with SMTP id f18mr2804973lfa.164.1483723938717; Fri, 06 Jan 2017 09:32:18 -0800 (PST) From: Brett Tate References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpgyuovI3wswcTryY00OgOrmPmrgMSblVsAg5JpWkCn4hFqgGX5fgFAqTDZSKgHY0fQA== Date: Fri, 6 Jan 2017 12:32:17 -0500 Message-ID: <87dbd0dcda36614df8860ad8eea6b84b@mail.gmail.com> To: marianne.mohali@orange.com, Henning Schulzrinne , sipcore@ietf.org Content-Type: multipart/alternative; boundary=f403045ea1084ffc2e054570661d X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-06_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:32:25 -0000 --f403045ea1084ffc2e054570661d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, The draft potentially should also discuss the potential for the connected party to change mid-dialog 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagged by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party indicating 666. Other than a way to attack someone, I=E2=80=99m not sure i= f are any 3PCC, transfer, or other service situations where it might actually be appropriate. *From:* marianne.mohali@orange.com [mailto:marianne.mohali@orange.com] *Sent:* Friday, January 06, 2017 10:28 AM *To:* Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpretation when the caller has several identities used for this call (ie. From and P-Asserted-Identity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be considered has a fraudulent (ie. the calling party or the diverting party or both ?) ; I propose to add the following text: This document defines a mechanism by which a called party can reject an unwanted call without consideration of the calling party identification that remain to the service provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or after a diverting service in P-Asserted-Identity, From, History-Info or any concurrent header field that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne *De :* sipcore [mailto:sipcore-bounces@ietf.org ]= *De la part de* Henning Schulzrinne *Envoy=C3=A9 :* vendredi 6 janvier 2017 00:14 *=C3=80 :* Asveren, Tolga; Brett Tate; sipcore@ietf.org *Objet :* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 On (i), I agree that we don't want to get into what information is being used, given that the entity most likely to use the 666 information, i.e., the terminating carrier, is also the one deciding how caller identity is being presented to the user (PAI, From, etc.). Tastes may differ, but I don't see how we can say much that's useful to implementors here, without getting into weeds that are already being explored by (say) the SHAKEN effort. Also, I'm not convinced that defining "call" is needed here, given that we'd probably not go much beyond what's in RFC 3261: Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Also, given the discussion of usage for non-INVITE, I'll change "call" to "request" or "dialog" where the context is more than just an example of what is likely to be the most common case - INVITE for a phone call. Henning ------------------------------ *From:* sipcore on behalf of Asveren, Tolga < tasveren@sonusnet.com> *Sent:* Thursday, January 5, 2017 10:22:55 AM *To:* Brett Tate; sipcore@ietf.org *Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I agree that defining what a "call" is a good idea but I have a different take on what it should say: i- A "call" in the context of this document is a communication session as perceived by a human agent, e.g. as in "I received a call from my grandmother.". It does not imply anything further as far as SIP information elements which usually are used to carry calling party identification, e.g. P-Asserted-Id, From headers, are concerned. It is up to the operator/network policy how to make associate further calls with the information/decision derived from unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing the actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org = ] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > Hi, > > I also agree that adding such a paragraph would be useful. > > For instance if someone desires a service to forward all received spam calls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org ] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller was. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. --f403045ea1084ffc2e054570661d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

The draft potentially= should also discuss the potential for the connected party to change mid-di= alog 1) without it being communicated and 2) with it being communicate by R= FC 4916, RFC 5876, et cetera.

=C2=A0

From a security considerations perspective, the wrong party might b= e flagged by the 666 when the connected party changes.

=C2=A0

The draft should potentially also discuss= the potential for calling party indicating 666.=C2=A0 Other than a way to = attack someone, I=E2=80=99m not sure if are any 3PCC, transfer, or other se= rvice situations where it might actually be appropriate.

=C2=A0

=C2=A0

<= p class=3D"MsoNormal">From: marianne.mohali@orange.com [mail= to:marianne.mohali@orange.com= ]
Sent: Friday, January 06, 2017 10:28 AM
To: Henn= ing Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on dra= ft-ietf-sipcore-status-unwanted-01

=C2=A0

Hi,<= /span>

=C2=A0

To reflect = the question of the interpretation of the 666 response interpretation when = the caller has several identities used for this call (ie. From and P-Assert= ed-Identity are different) or call forwarding/call transfer use cases for w= hich it has to be discussed which party should be considered has a fraudule= nt (ie. the calling party or the diverting party or both ?) ; I propose to = add the following text:

This document defines a mechanism by which a called party ca= n reject an unwanted call without consideration of the calling party identi= fication that remain to the service provider policy. Indeed, the calling pa= rty identity may be reflected in different way for a direct call or after a= diverting service in P-Asserted-Identity, From, History-Info or any concur= rent header field that can be present at the same time in a SIP message.

=C2=A0

Those questio= ns are real issues for operators and implementors and they are a weakness t= hat fraudulent callers could use to bypass the mechanism.

=C2=A0

BR,

Marianne

=C2= =A0

De=C2=A0: sipcore [mailto:sipcore-bounces@ietf.org] De= la part de Henning Schulzrinne
Envoy=C3=A9=C2=A0: vendredi 6= janvier 2017 00:14
=C3=80=C2=A0: Asveren, Tolga; Brett Tate; sipcore@ietf.org
Objet=C2=A0: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

=C2=A0

On (i), I agree = that we don't want to get into what information is being used, given th= at the entity most likely to use the 666 information, i.e., the terminating= carrier, is also the one deciding how caller identity is being presented t= o the user (PAI, From, etc.).

=C2=A0

Tastes may differ, but I don't see how we c= an say much that's useful to implementors here, without getting into we= eds that are already being explored by (say) the SHAKEN effort.

<= p>=C2=A0

Also, I'm= not convinced that defining "call" is needed here, given that we= 'd probably not go much beyond what's in RFC 3261:

=C2=A0

Call: A call is an =
informal term that refers to some communication
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 between peers, generally set up for the purposes of a
=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 multimedia conversation.

Also, given the discussion of usage for non-INVITE, I&= #39;ll change "call" to "request" or "dialog"= where the context is more than just an example of what is likely to be the= most common case - INVITE for a phone call.

=C2=A0

Henning

Fro= m: sipcore <sipcore-bounces@ietf.org> on behalf of Asveren, Tolga <tasv= eren@sonusnet.com>
Sent= : Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; = sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-statu= s-unwanted-01

=C2=A0

=

I agree that defining what a "call" is a good idea but I have= a different take on what it should say:

i-=C2=A0 A "call"= in the context of this document is a communication session as perceived by= a human agent, e.g. as in "I received a call from my grandmother.&quo= t;. It does not imply anything further as far as SIP information elements w= hich usually are used to carry calling party identification, e.g. P-Asserte= d-Id, From headers, are concerned. It is up to the operator/network policy = how to make associate further calls with the information/decision derived f= rom unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx r= esponse codes signify that calls from this caller are unwanted by the calle= d party."
=3D=3D>
"None of the existing 4xx, 5xx or 6xx = response codes signify that this call is unwanted by the called party."= ;

I think ii- is needed to relive the end user from the burden of &q= uot;knowing the actual caller".

Thanks,
Tolga

> -----Original Message-----
> Fr= om: sipcore [mailto:sipcore-bounc= es@ietf.org] On Behalf O= f Brett Tate
> Sent: Thursday, January 05, 2017 7:54 AM
> To: <= /span>sipcore@ietf.org
> Subject: Re: [sipcore] Comments on draft-= ietf-sipcore-status-unwanted-01
>
> Hi,
>
> I als= o agree that adding such a paragraph would be useful.
>
> For instance if someone de= sires a service to forward all received spam calls to
> another set o= f victims, they would likely not use such a service if the
> forwardi= ng party might also get flagged as part of the 666 handling.
>
>
> > -----Original Mess= age-----
> > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul
> Kyzivat
> > Sent: Wednesday= , January 04, 2017 7:51 PM
> > To: sipcore@ietf.org
= > > Subject: Re: [sipcore] Comments on
> > draft-ietf-sipcor= e-status-unwanted-01
> >
> > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote:
> >
> > >= -Section 4 general:
> > > IMO, it would be good to have a para= graph addressing the question of
> > > the "calling party = number" (mentioned several time in the document):
> > > in= deed, this calling party number can be identified by the telephone
> = > > number/address in the From header or the one in the
> > = > P-Asserted-Identity header that may be different. Depending on the
> > > one disp= layed to the called UA, the 666 could concern only one or
> > >= both addresses depending on service provider choices. If we take the
&g= t; > > example of a call-center or an IPBX having the head number and= a
> > > range of private numbers, the service provider could i= nterpret the
> > > 666 from the called user only for the privat= e number (in the From
> > > header) or for the whole pool (P-As= serted-Identity). I suggest to
> > > have a paragraph to highli= ght this point.
> >
> > Interesting point. If the PAID is= different from the number displayed
> > to
> the
> &g= t; callee, and the callee rejects the call without answering, how should> "blame"
> > be assigned? From the calllee's pe= rspective the complaint is *about*
> > the number he saw, regardle= ss of what the identity of the actual caller was.
> >
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Than= ks,
> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Paul
> >
> &g= t; _______________________________________________
> > sipcore mai= ling list
> > = sipcore@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3D= FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Q= x8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&am= p;e=3D
>
>= _______________________________________________
> sipcore mailing li= st
> sipcore@ietf.org
> https://urldefe= nse.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_sipco= re&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0Re= X8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04C= Po&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D<= /span>

___________________________= ____________________
sipcore mailing list
sipcore@ietf.org<= br>http= s://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_lis= tinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDk= WM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1z= EJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D<= /a> 

_________________________=
___________________________________________________________________________=
_____________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir d=
es informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans auto=
risation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que=
 les pieces jointes. Les messages electroniques etant susceptibles d'al=
teration,
Orange decline toute responsab=
ilite si ce message a ete altere, deforme ou falsifie. Merci.
<=
pre>=C2=A0
This messag=
e and its attachments may contain confidential or privileged information th=
at may be protected by law;
they should =
not be distributed, used or copied without authorisation.
=
If you have received this email in error, please notify t=
he sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or falsified.
Thank you.
--f403045ea1084ffc2e054570661d-- From nobody Fri Jan 6 09:43:31 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDC9129D28 for ; Fri, 6 Jan 2017 09:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnTYDT2h4SSa for ; Fri, 6 Jan 2017 09:43:29 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F20D0129B73 for ; Fri, 6 Jan 2017 09:43:28 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-07v.sys.comcast.net with SMTP id PYXbch8Q6j8tqPYY4cwvvt; Fri, 06 Jan 2017 17:43:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483724608; bh=bOcvOCbezkWuH8W2PRg1o/lxCqXhnbKDsrMXSHx0PYk=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=LNcJzF5mqAZWJv+EqxeRC4W5LwefyuN1Ufh7ei6Xra8iNpgC/J+DTnHVhbnHZ4ECV db8KXbAa52SNGMhm9gQqRJvF7Jdj5QXgnWY/j2bQTArdeS/5gO7zVjt+hyvuyDvYR1 qktF9rgRl37cGbgSm6tf8mqk935g+2MSJKwFU/N98FbTEx3vtpVsN0FULxjRstQpvd 252t40+kwU1+uFxb6IwG3RB0u6ECFRVmLI1cn541PHGuyNVXjaHJbOya7GhvZ2K7oM PA3bmL5QbFBj/yhBIkm/G+/65Wwv2oUD7Yi5DuZzwSRJWmDstLnHL/OCxczbrJx/d9 AAi06/5zMlxDw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-19v.sys.comcast.net with SMTP id PYY3cdjnWQdHJPYY3cyGQK; Fri, 06 Jan 2017 17:43:28 +0000 To: sipcore@ietf.org References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Paul Kyzivat Message-ID: Date: Fri, 6 Jan 2017 12:43:27 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfN+v3zYNannRAUHJxUELEUc6AmVq6pJfKg6oWvcw/CILVKCsHLR+rzptY+dbV4DKvCEnOaXw1P9zTd4LaK91BHewqqWcY0WkeVS5AHJMuH+bAS8Wolt7 b+hF2oirDbxH9Kpo1gzWZYLFYzflx1CQVeNwmDLQDZC5kie72V66S1TPayx6SfQgXAQHQG1VYfTUKw== Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:43:30 -0000 On 1/6/17 10:28 AM, marianne.mohali@orange.com wrote: > Hi, > > To reflect the question of the interpretation of the 666 response > interpretation when the caller has several identities used for this call > (ie. From and P-Asserted-Identity are different) or call forwarding/call > transfer use cases for which it has to be discussed which party should > be considered has a fraudulent (ie. the calling party or the diverting > party or both ?) ; I propose to add the following text: > > This document defines a mechanism by which a called party can reject an > unwanted call without consideration of the calling party identification > that remain to the service provider policy. Indeed, the calling party > identity may be reflected in different way for a direct call or after a > diverting service in P-Asserted-Identity, From, History-Info or any > concurrent header field that can be present at the same time in a SIP > message. > > Those questions are real issues for operators and implementors and they > are a weakness that fraudulent callers could use to bypass the mechanism. ISTM there are two different cases here, and the identity implications differ between them: 1) the callee rejects the call without consideration of the content of the call. Instead, the rejection is based solely on metadata about the call that is available to the callee - e.g., callerid information presented, classification information, possibly time of day. It might also include information provided locally by the phone (e.g. from the local address book). In this case the actual caller may be blameless. So care must be taken in associating the rejection with the caller. 2) the callee rejects the call after answering, based on the media content of the call. In this case the rejection clearly applies to the caller even if the callee doesn't know the caller's identity. It may be difficult to distinguish between these. Certainly using 666 as a response code must be case (1). But using 666 as a reason isn't necessarily case (2) - the callee may be slow and reject based on metadata after answering, or may use a combination of content and metadata in making that decision. This is not something that can be resolved in this document, but it may be worthwhile to identify that these issues exist and must be considered by those who act on 666 responses. Thanks, Paul From nobody Fri Jan 6 09:50:02 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4672129D2B for ; Fri, 6 Jan 2017 09:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46Y_VFWWmtRt for ; Fri, 6 Jan 2017 09:49:58 -0800 (PST) Received: from alum-mailsec-scanner-2.mit.edu (alum-mailsec-scanner-2.mit.edu [18.7.68.13]) by ietfa.amsl.com (Postfix) with ESMTP id B1AED1295A2 for ; Fri, 6 Jan 2017 09:49:58 -0800 (PST) X-AuditID: 1207440d-8b7ff700000009ba-f7-586fd8c48918 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 69.8E.02490.4C8DF685; Fri, 6 Jan 2017 12:49:58 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v06HntFR028074 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Jan 2017 12:49:56 -0500 To: Adam Roach , marianne.mohali@orange.com, "Drage, Keith (Nokia - GB)" , "sipcore@ietf.org" References: <87d1g1h6vj.fsf@hobgoblin.ariadne.com> <41a445e2-218e-12ec-5f61-0da27d5227d2@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD17F6@FR712WXCHMBA11.zeu.alcatel-lucent.com> <19964_1483635715_586E7C03_19964_3476_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A34AE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <80d6f674-2ded-75be-bec3-2de9e1414e53@nostrum.com> From: Paul Kyzivat Message-ID: Date: Fri, 6 Jan 2017 12:49:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <80d6f674-2ded-75be-bec3-2de9e1414e53@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFIsWRmVeSWpSXmKPExsUixO6iqHvsRn6Ewd2DLBZ7/i5it9iw5TiL xbbmfUwWX39sYnNg8Viy5CeTx91bl5g8Zu18wuLR8uwkWwBLFJdNSmpOZllqkb5dAlfGnrnB Bfe1KhY97GJqYLym1MXIySEhYCLxcuoe9i5GLg4hgcuMEpPmvWCBcK4xSZz6cZAVpEpYQEPi 7JldzCAJEYHVjBK/N3+GannHJDFr5h12kCo2AS2JOYf+s4DYvAL2EosnrASLswioSOxY+xZs kqhAmsSDk1sZIWoEJU7OfAJWzwlUv2b/S2YQm1nATGLe5odQtrxE89bZzBMY+WYhaZmFpGwW krIFjMyrGOUSc0pzdXMTM3OKU5N1i5MT8/JSi3SN9HIzS/RSU0o3MUKClHcH4/91MocYBTgY lXh4I7zyIoRYE8uKK3MPMUpyMCmJ8oY55kcI8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuHlugqU 401JrKxKLcqHSUlzsCiJ86otUfcTEkhPLEnNTk0tSC2CycpwcChJ8G65DtQoWJSanlqRlplT gpBm4uAEGc4DNHwbSA1vcUFibnFmOkT+FKOilDjvBJCEAEgiozQPrheWRF4xigO9IswbAlLF A0xAcN2vgAYzAQ0W9AQbXJKIkJJqYJy/8HDBh++nXnFv6kxhP9Y9KfaYZtzPF49PPNRU/sn8 w89qvhVP+52//qJx3CHh3JqVrzjNLG7kSPRJac53KpW9IvJq+azGzR0d03l/2vyb+nredP75 Z09EB8iw/mxQD3qTYnF1CiuXy8L4HqEr/ud7P1RHxZ56c25ex+YtDy/+z1G8diLHQEuJpTgj 0VCLuag4EQDnEX2C/QIAAA== Archived-At: Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:50:00 -0000 +1 On 1/6/17 10:36 AM, Adam Roach wrote: > [as individual] > > I think the error is in 3312, but it's not the flaw being discussed here. > > The error was in allowing 3312 to specify that a CANCEL can have a body. > While it's not stated normatively in English prose, the line of Table 2 > that you cite has been broadly interpreted to mean that CANCEL cannot > contain a body. The description of CANCEL handling at proxies does not > involve any steps that would copy the body from an incoming CANCEL to an > outgoing one. This has been a long-standing interpretation, dating back > to approximately the same era as RFC3261's own publication. > > See, for example: > > https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-January/021232.html > > > and > > https://www.ietf.org/mail-archive/web/sip/current/msg07810.html > > > What this means is: from a practical perspective, it is highly unlikely > that a CANCEL body will survive the first proxy it hits. So I think the > action here is to file an erratum that removes the text from 3312 that > suggests putting a body in a CANCEL message. > > /a > > On 1/5/17 11:01, marianne.mohali@orange.com wrote: >> Hi, >> >> I don't want to re-open the discussion on the Tables (I also heard >> that they are now deprecated). >> I agreed that RFC3261 comes first so it should have been stated in >> RFC3312 that RFC3312 also update the 3261 table. >> >> I would propose to have an errata to RFC3312 adding this clarification. >> Any other view? >> >> BR, >> Marianne >> >> -----Message d'origine----- >> De : sipcore [mailto:sipcore-bounces@ietf.org] De la part de Drage, >> Keith (Nokia - GB) >> Envoyé : jeudi 5 janvier 2017 17:04 >> À : Paul Kyzivat; sipcore@ietf.org >> Objet : Re: [sipcore] Errata to RFC3261 >> >> I think this is actually addressing the wrong document. >> >> RFC 3261 is correct in its own right. >> >> It is when it is used in conjunction with RFC 3312 that the problem >> occurs, and therefore the correction should be made to RFC 3312 to >> update RFC 3261 in this respect. >> >> Keith >> >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 05 January 2017 15:38 >> To: sipcore@ietf.org >> Subject: Re: [sipcore] Errata to RFC3261 >> >> On 1/5/17 10:19 AM, Dale R. Worley wrote: >>> writes: >>>> I would like to submit an errata to RFC3261 on the following point: >>>> >>>> RFC 3261 (section 20 Table 2) states that Content-Type header is not >>>> applicable to the CANCEL method (meaning that a CANCEL must not >>>> contain a body). >>>> "580 (Precondition Failure) responses and BYE and CANCEL requests, >>>> indicating failure to meet certain preconditions, SHOULD contain an >>>> SDP description, indicating which desired status triggered the >>>> failure. Note that this SDP description is not an offer or an >>>> answer, since it does not lead to the establishment of a session. >>>> The format of such a description is based on the last SDP (an offer >>>> or an answer) received from the remote UA." >>> This isn't really an erratum for 3261 as a clarification that 3312 >>> updates the table in 3261. >>> >>> But I remember there was a discussion some years ago about maintaining >>> the tables in 3261 and there was some sort of decision to no longer do >>> that, as almost every SIP RFC entailed modifying the tables. >>> >>> Does anyone remember the details of that discussion? >> I can't recall the *details*, but as I remember it the gist was that >> table 2 is insufficient to characterize the nuances that often need to >> be expressed. So, rather than attempt to maintain table 2 the >> conclusion was that documents should express the constraints >> individually, typically with text. >> >> Thanks, >> Paul >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> _________________________________________________________________________________________________________________________ >> >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez >> recu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. Les >> messages electroniques etant susceptibles d'alteration, >> Orange decline toute responsabilite si ce message a ete altere, >> deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; >> they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > > From nobody Fri Jan 6 10:00:07 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDBB91295B0 for ; Fri, 6 Jan 2017 10:00:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVaFrRywExu0 for ; Fri, 6 Jan 2017 10:00:04 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCE881295A5 for ; Fri, 6 Jan 2017 10:00:04 -0800 (PST) Received: from pps.filterd (m0103509.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v06HxbuI015201 for ; Fri, 6 Jan 2017 13:00:04 -0500 Received: from mail-lf0-f71.google.com (mail-lf0-f71.google.com [209.85.215.71]) by mx0a-001d8301.pphosted.com with ESMTP id 27p6usea9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 06 Jan 2017 13:00:04 -0500 Received: by mail-lf0-f71.google.com with SMTP id v186so2095430lfa.2 for ; Fri, 06 Jan 2017 10:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=+yJFq2Oxq3VgGZGmjuVPDlsn42ApQBKMabkhIZLO46c=; b=0aLy1qIm0004W7pUWk+NSa+svf/Xb+WYxbaoTwdZXAWyqMYB9U3ynYTllZcrCtCam/ htW+xoyRF4w2ogSiP2uSvy1+6Mn6wo9y5ax4LwjgBcuTQaqfP8wVDla5PuJ1ncJKtbve 9eQEIZvF0hnw4I0hs9fjBKU5HRJnZyGHBlb0PXNnumwtg5bGiuMOjlmi4GOOwmUpXPmj /GCuLI1FFwgzPL6/lASwh9EvZhtdfoSak9YalymdxWx5PQGgtcy0yG8yJe28o17zi7Q4 GhmJc+RKO+mfoRhwK7MwePSCJ7ovW/TPV41QjwW5HgIiJ6FZb+eq6wFoOu8qme35ueEx taXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=+yJFq2Oxq3VgGZGmjuVPDlsn42ApQBKMabkhIZLO46c=; b=B2H6ElkS6aVUZluoZR7QWpaa/ljrCioC1J83NgzzOQhJNF9aa5p1CEcjSCyAlz331B 79MclZTCRsSNhSnelzadCzKdXg4nx+gxXbMN2V8JspDMgUfEN3cZfegWekIiZTaX5LKJ zbjJKC2DYdrL79KqmdlAnYyVE5vDEkPavpHylRmFlxzOjpYImM22x2W4aqmMmfxspqC6 k9CxA65fD9kI1xgJ8WR3LdBGRe6vlC+8NUQp4vF8uOEFmgCt76qdBD3kpSelA9yXapHH 55TwdeCOOBfSZloSyjKhCGPnD0dfNk9r0ANvcCsYTg7WSSfT1IOWSz2rVNYKh796LpU6 iPYQ== X-Gm-Message-State: AIkVDXLVB4e6NU+f7dT8OV9RXIIM7OzPd3jYWwu5SIUMO/qIKI5OjJSn1uuOTOLWWkBlNuEwEOyZsD6NVNLeO7fZFIyTou/MJRkNiaVon33GOMi7yOhz855U9QdKhajMtgq5u9QU884ZjiRg X-Received: by 10.25.219.69 with SMTP id s66mr23247374lfg.116.1483725601255; Fri, 06 Jan 2017 10:00:01 -0800 (PST) X-Received: by 10.25.219.69 with SMTP id s66mr23247366lfg.116.1483725601008; Fri, 06 Jan 2017 10:00:01 -0800 (PST) From: Brett Tate References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <45a2dc35659238515f113beba22cf690@mail.gmail.com> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLWr6/Umd0J42L08fGbdPT+Ys7sSwKVRJLpArLVtFwCb+qG8wLLOoklAhDBBRABuGTcB56wnoMQ Date: Fri, 6 Jan 2017 12:59:59 -0500 Message-ID: <68978a4baccc71b511a42094bf9450c7@mail.gmail.com> To: Henning Schulzrinne , "Drage, Keith (Nokia - GB)" , sipcore@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07932464a3e2054570c98a X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-06_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:00:06 -0000 --94eb2c07932464a3e2054570c98a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Yes; I think that it would be beneficial to discuss mid-dialog 666 in relation to RFC 5057. I don=E2=80=99t have a strong opinion about if 666 impacts Transaction Only= , Destroys Usage, or Destroys Dialog. However even though I=E2=80=99m not su= re if/why someone would send a 666 response for mid-dialog request, it might be better to only impact the transaction. For example, media server might want to return 666 for some mid-dialog requests while continuing to play treatment associated with INVITE=E2=80=99s 666. *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Thursday, January 05, 2017 6:24 PM *To:* Brett Tate; Drage, Keith (Nokia - GB); sipcore@ietf.org *Subject:* Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Would it be helpful to indicate that 666 should be treated as 604 (as that seems most reasonable, given that 666 is probably a dialog killer. Tentative wording: Following , the 666 response destroys the dialog. ------------------------------ *From:* Brett Tate *Sent:* Thursday, January 5, 2017 8:30:50 AM *To:* Drage, Keith (Nokia - GB); Henning Schulzrinne; sipcore@ietf.org *Subject:* RE: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt > Further if it does appear in a subsequent transaction within > a dialog what is the action by the receiver in terms of dialog > handling (unless we want to preclude it from subsequent > transactions). Is it already covered by RFC 5057. RFC 5057 does discuss 6xx handling. However since note 17 indicates "6xx unrecognized responses" and Table 1 indicates "unknown 6xx", I'm not positive if Table 2's 6xx impact (Transaction) was intended to also apply to known 6xx responses defined subsequent to RFC 5057. --94eb2c07932464a3e2054570c98a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

Yes; I think that it = would be beneficial to discuss mid-dialog 666 in relation to RFC 5057.

=C2=A0

I don=E2=80=99t have a stro= ng opinion about if 666 impacts Transaction Only, Destroys Usage, or Destro= ys Dialog.=C2=A0 However even though I=E2=80=99m not sure if/why someone wo= uld send a 666 response for mid-dialog request, it might be better to only = impact the transaction.=C2=A0 For example, media server might want to retur= n 666 for some mid-dialog requests while continuing to play treatment assoc= iated with INVITE=E2=80=99s 666.

=C2=A0

=C2=A0

<= span style=3D"font-size:10.0pt;font-family:"Tahoma","sans-se= rif"">From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 05, 2017 6:24 PM
To: Brett Tate;= Drage, Keith (Nokia - GB); sipcore@iet= f.org
Subject: Re: [sipcore] Commenters, please check draft-i= etf-sipcore-status-unwanted-01.txt

=C2=A0

Would it = be helpful to indicate that 666 should be treated as 604 (as that seems mos= t reasonable, given that 666 is probably a dialog killer. Tentative wording= :

=C2=A0

Following <xref=3D"RFC5057&quo= t;/>, the 666 response= destroys the dialog.

=C2=A0

From:<= /b> Brett Tate <brett@broadsoft.com>
Sent: Thursday, January 5, 20= 17 8:30:50 AM
To: Drage, Keith (Nokia - GB); Henning Schulzrinne;= sipcore@ietf.org
Subject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted= -01.txt

=C2=A0

=

> Further i= f it does appear in a subsequent transaction within
> a dialog what i= s the action by the receiver in terms of dialog
> handling (unless we= want to preclude it from subsequent
> transactions). Is it already c= overed by RFC 5057.

RFC 5057 does discuss 6xx handling.=C2=A0 Howeve= r since note 17 indicates "6xx
unrecognized responses" and Tab= le 1 indicates "unknown 6xx", I'm not
positive if Table 2&= #39;s 6xx impact (Transaction) was intended to also apply
to known 6xx r= esponses defined subsequent to RFC 5057.

--94eb2c07932464a3e2054570c98a-- From nobody Fri Jan 6 11:30:25 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C7C5129DF1 for ; Fri, 6 Jan 2017 11:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcxH4DsKXvIY for ; Fri, 6 Jan 2017 11:30:23 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E605B129DE9 for ; Fri, 6 Jan 2017 11:30:22 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-11v.sys.comcast.net with SMTP id PaAIcFRKcZxnDPaDVckhw2; Fri, 06 Jan 2017 19:30:21 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-07v.sys.comcast.net with SMTP id PaDUc1N5KBLJ8PaDUcQKU3; Fri, 06 Jan 2017 19:30:21 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v06JUJDC022019; Fri, 6 Jan 2017 14:30:19 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v06JUJHH022016; Fri, 6 Jan 2017 14:30:19 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: In-Reply-To: <19964_1483635715_586E7C03_19964_3476_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A34AE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 06 Jan 2017 14:30:19 -0500 Message-ID: <87fukwc7g4.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCei1I380IsmbqvT+VlV9riiHPIj2U6zmqGdx5cM1bjV+oY0cpIK8pZi5w+kuITeAd5wss1/davCBHR0qGQpWXYZjdCp4xuLWOT7tbYKn4nHJC46lrsC bA9eJy5SYfolB/BCbb4dSk6L6eWVkIoWwNsbq+MvXRh9tr+NN0ze9Mkuhq0/62MJViIibHjCGQevhiFO9uJ1b6al6v3QfNSsLVdbDvzVTB6AgSCu4NmIcR4V 2C/aD+Kuv8cK1perEYVRKfRbHs1M27VAmJ1iVUBh4KE= Archived-At: Cc: paul.kyzivat@comcast.net, sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:30:23 -0000 writes: > I don't want to re-open the discussion on the Tables (I also heard > that they are now deprecated). I agreed that RFC3261 comes first so > it should have been stated in RFC3312 that RFC3312 also update the > 3261 table. > > I would propose to have an errata to RFC3312 adding this clarification. > Any other view? Relative to Jean Mahoney's message, the decision is to deprecate Table 2 in RFC 3261, and defer to text descriptions. As I understand it, the text description of the use of bodies in CANCEL given in RFC 3312 is clear, and clearly supersedes the discussion in RFC 3261, so there is no need for an erratum. Dale From nobody Fri Jan 6 11:52:01 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A28129610 for ; Fri, 6 Jan 2017 11:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pJds_ge1yJR for ; Fri, 6 Jan 2017 11:51:58 -0800 (PST) Received: from mail-wj0-x22f.google.com (mail-wj0-x22f.google.com [IPv6:2a00:1450:400c:c01::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15E5012960F for ; Fri, 6 Jan 2017 11:51:58 -0800 (PST) Received: by mail-wj0-x22f.google.com with SMTP id ew7so28397046wjc.3 for ; Fri, 06 Jan 2017 11:51:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cbq8s+0rsbCAr646Qe8hauPljBw0oE7ehA1KEsMb+u4=; b=eHDUI5wr2k4GnNmbb65idYuhalsTjOb97zXPXkArexkxUzPnwavZPAB69dNZeKeeNz GN6KqcCWYm2peUtEzofINrpqDmVikl2VFiJ4Z9V/oNzJ+uIwetrLAXfXKIOJ4LCs4rFa UrCY0kSa+5uH2yIE7PLe0OmC6YyinhHjiJehsDDFZCOMBOD6H/X5GjfZNn8qnCuLVwDJ X+aErjWN8G825K4OgyEI/SdDlUheqsr4plpLIwglpXn6/XRaYzov4/XpnZlRNNBiRbJY sheb61jkVl610t5DFs2V0fHlf9CZE4HpkyF6b9u2JNF3NH8Cf7fPZxKA/AYe3d814U8v KfSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cbq8s+0rsbCAr646Qe8hauPljBw0oE7ehA1KEsMb+u4=; b=QGtFDEwyxooJjF/ufezBzqPuGUd3kVjnfgl03Gp3EqyTG8lXm1nbSnEO1sE+SOyyqU suJd4EZJsrAwh9+XSdH9fL8vvxXPijuIgRNSsB0O20M3hKXFzuweW3EyhxDQplztgzlT N3CQ+1y6aCY9ul7hsxmYhPMSKp/i0Xr7DkwGYPt1LKwSFrXaImge6pZJbExGZD49no5Z e7y+Is3ctHdIVW3p7JvMgBFERLahkuw5a6LcPnH2KIyQOd1hFV9LCH61BDlNDjx6VpFR n+sVeFuShv0oDD88OW8GLXAUoo2HK1vtR3XarhpdRlP+fqTjZF+akuFY1UA9Y6wW7q6A gASQ== X-Gm-Message-State: AIkVDXI16FhD6Kjm7976QLX2G8lctAvarO6UBOa+R9eptjG83fpgXXop1lSVk7OsKGQZsXA+fORSX2IgttNapg== X-Received: by 10.194.120.198 with SMTP id le6mr53174636wjb.22.1483732316491; Fri, 06 Jan 2017 11:51:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.173.98 with HTTP; Fri, 6 Jan 2017 11:51:55 -0800 (PST) In-Reply-To: <68978a4baccc71b511a42094bf9450c7@mail.gmail.com> References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <45a2dc35659238515f113beba22cf690@mail.gmail.com> <68978a4baccc71b511a42094bf9450c7@mail.gmail.com> From: Ranjit Avasarala Date: Fri, 6 Jan 2017 13:51:55 -0600 Message-ID: To: Brett Tate Content-Type: multipart/alternative; boundary=089e01160002aa942b054572591c Archived-At: Cc: SIPCORE , Henning Schulzrinne Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:51:59 -0000 --089e01160002aa942b054572591c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable what if the caller is an automata - like a softphone, etc then how does 666 response help in blocking the caller (ip or port may keep changing) Regards Ranjit On Fri, Jan 6, 2017 at 11:59 AM, Brett Tate wrote: > Hi, > > > > Yes; I think that it would be beneficial to discuss mid-dialog 666 in > relation to RFC 5057. > > > > I don=E2=80=99t have a strong opinion about if 666 impacts Transaction On= ly, > Destroys Usage, or Destroys Dialog. However even though I=E2=80=99m not = sure > if/why someone would send a 666 response for mid-dialog request, it might > be better to only impact the transaction. For example, media server migh= t > want to return 666 for some mid-dialog requests while continuing to play > treatment associated with INVITE=E2=80=99s 666. > > > > > > *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > *Sent:* Thursday, January 05, 2017 6:24 PM > *To:* Brett Tate; Drage, Keith (Nokia - GB); sipcore@ietf.org > *Subject:* Re: [sipcore] Commenters, please check > draft-ietf-sipcore-status-unwanted-01.txt > > > > Would it be helpful to indicate that 666 should be treated as 604 (as tha= t > seems most reasonable, given that 666 is probably a dialog killer. > Tentative wording: > > > > Following , the 666 response destroys the dialog. > > > ------------------------------ > > *From:* Brett Tate > *Sent:* Thursday, January 5, 2017 8:30:50 AM > *To:* Drage, Keith (Nokia - GB); Henning Schulzrinne; sipcore@ietf.org > *Subject:* RE: [sipcore] Commenters, please check > draft-ietf-sipcore-status-unwanted-01.txt > > > > > Further if it does appear in a subsequent transaction within > > a dialog what is the action by the receiver in terms of dialog > > handling (unless we want to preclude it from subsequent > > transactions). Is it already covered by RFC 5057. > > RFC 5057 does discuss 6xx handling. However since note 17 indicates "6xx > unrecognized responses" and Table 1 indicates "unknown 6xx", I'm not > positive if Table 2's 6xx impact (Transaction) was intended to also apply > to known 6xx responses defined subsequent to RFC 5057. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --089e01160002aa942b054572591c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
what if the caller is an automata - like a softp= hone, etc then how does 666 response help in blocking the caller (ip or por= t may keep changing)

Regards
Ranjit

On Fri, Jan 6, 2017 at 11= :59 AM, Brett Tate <brett@broadsoft.com> wrote:
=

Hi,

=C2=A0

Yes; I think that it would be beneficial to discuss mid-dialog 666 = in relation to RFC 5057.

=C2=A0

=C2=A0

=C2=A0

From: Hen= ning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Thurs= day, January 05, 2017 6:24 PM
To: Brett Tate; Drage, Keith (Nokia= - GB); sipcore@ietf.= org
Subject: Re: [sipcore] Commenters, please check draft-iet= f-sipcore-status-unwanted-01.txt

=C2=A0

Would it be helpful to indicate that 666 should be treated = as 604 (as that seems most reasonable, given that 666 is probably a dialog = killer. Tentative wording:

=C2=A0

Following <xref=3D"RFC5057"/>, the 666 response destroys the dialog.

=C2=A0

From:= Brett Tate <br= ett@broadsoft.com>
Sent: Thursday, January 5, 2017 8:30:50= AM
To: Drage, Keith (Nokia - GB); Henning Schulzrinne; sipcore@ietf.org
S= ubject: RE: [sipcore] Commenters, please check draft-ietf-sipcore-statu= s-unwanted-01.txt

=C2=A0

> Further if it does appear in a subsequent transaction within
> = a dialog what is the action by the receiver in terms of dialog
> hand= ling (unless we want to preclude it from subsequent
> transactions). = Is it already covered by RFC 5057.

RFC 5057 does discuss 6xx handlin= g.=C2=A0 However since note 17 indicates "6xx
unrecognized response= s" and Table 1 indicates "unknown 6xx", I'm not
posit= ive if Table 2's 6xx impact (Transaction) was intended to also applyto known 6xx responses defined subsequent to RFC 5057.


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--089e01160002aa942b054572591c-- From nobody Fri Jan 6 11:57:08 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0456F129625 for ; Fri, 6 Jan 2017 11:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.089 X-Spam-Level: X-Spam-Status: No, score=0.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6pb_FvgDm3a for ; Fri, 6 Jan 2017 11:57:05 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A3D129407 for ; Fri, 6 Jan 2017 11:57:04 -0800 (PST) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v06JsiTw022636; Fri, 6 Jan 2017 19:57:03 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0a-0024ed01.pphosted.com with ESMTP id 27p3qhuvb7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Jan 2017 19:57:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Cj+ESWZJl9MBnctuoOm4Ymq1r9cbC9x1L5jnVCkdbdY=; b=SvSddAx8tkq3ZaXdQFeSmgMnKgDpBMkqxeJviJvsYmexZwj8vhEo5OfeSsqlDqI1Cp+v5fpoOWUeZcu7bQggWreBa3JPy1X082ZOpyYNtDG+1FcWzPvITELhM7o8PwqRZd3C4L2JXfK0n4kVKQf4tyHue+7jFOAy3pIQBHgYkuY= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Fri, 6 Jan 2017 19:57:00 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Fri, 6 Jan 2017 19:57:00 +0000 From: Henning Schulzrinne To: Ranjit Avasarala , Brett Tate Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZtkNZBs4MySSekqJkBAojeGCU6Eo5mXAgAAslYCAAM8vAIAApDXOgAE5U4CAAB9GgIAAANGw Date: Fri, 6 Jan 2017 19:57:00 +0000 Message-ID: References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com> <45a2dc35659238515f113beba22cf690@mail.gmail.com> <68978a4baccc71b511a42094bf9450c7@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: ec23aad8-cad4-48e3-11be-08d4366e2d8b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:k5Gh6Z1PUprj5ooUAJB6wR+Fjjo49bs+1+8dul4v+3kf/XvPYfBiqHs9QKXnAKdxlSOiR/ekA6uDkfwytolAhesJTGK995m+HugIu+jpIZqYmGyEP1DzgiSldhVBqYTSzNwTgonx6g3ttVEyHfmXYM1uvvvBEasI7KDzYrDFRKPvMA7UKPWk6aR5CL6qw+62wccmzw3yrNvRyWnR9+LbzD0YF7B7oIpLH3aHRyELdL9WfB5K/rEi1npafdF5hfwyxXN1Vwgi+3P0+G+qQZgM6M3lj92894cz6E22ar87vnX94Qbv0Bk6UsPhgkYXMLdkvPe4NKICp3aMCm4jjtG6XfUdWepN627O3zJsrfG3/7BKVBpr2oY4LgvccAyp+vks0wLeFKKle3vB2MSrQSfMkBEQaRb6BqINy6d85x8JIzewxKBKh+vhFFq1R57/xWpLOQQxiC7WhfoI3/XkFzFJMA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(377454003)(199003)(51444003)(189002)(24454002)(54906002)(3280700002)(4326007)(551934003)(229853002)(6116002)(5660300001)(99286003)(50986999)(97736004)(6436002)(5001770100001)(2906002)(230783001)(2900100001)(25786008)(122556002)(8936002)(54896002)(106356001)(76176999)(790700001)(66066001)(2950100002)(3846002)(3660700001)(81166006)(33656002)(54356999)(7906003)(19609705001)(105586002)(6306002)(92566002)(6506006)(101416001)(74316002)(38730400001)(8676002)(7696004)(7736002)(606005)(68736007)(39060400001)(55016002)(77096006)(81156014)(102836003)(86362001)(189998001)(106116001)(93886004)(9686003)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634BB88E5E2D0868322212EEA630CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2017 19:57:00.1711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-06_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: SIPCORE Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:57:08 -0000 --_000_CY1PR09MB0634BB88E5E2D0868322212EEA630CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QmxvY2tpbmcgd291bGQgbm90IGJlIGJhc2VkIG9uIElQIGFkZHJlc3NlcyBvciBwb3J0IG51bWJl cnMsIGZvciB0aGUgcmVhc29ucyB5b3UgaGludCBhdC4gVHJlYXRtZW50IGlzIGJhc2VkIG9uIGNh bGxpbmcgcGFydHkgbnVtYmVyIChob3dldmVyIGNhcnJpZWQpLCByZWNhbGxpbmcgdGhlIGRpc2N1 c3Npb24gZnJvbSBhIGZldyB3ZWVrcyBhZ28gKGFuZCByZWZsZWN0ZWQgaW4gdGhlIGRyYWZ0KSBh Ym91dCBwb3RlbnRpYWwgaW1wYWN0IG9mIHNwb29maW5nLg0KDQpGcm9tOiBSYW5qaXQgQXZhc2Fy YWxhIFttYWlsdG86cmFuaml0a2F2MDgxMUBnbWFpbC5jb21dDQpTZW50OiBGcmlkYXksIEphbnVh cnkgMDYsIDIwMTcgMjo1MiBQTQ0KVG86IEJyZXR0IFRhdGUgPGJyZXR0QGJyb2Fkc29mdC5jb20+ DQpDYzogSGVubmluZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Pjsg RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKSA8a2VpdGguZHJhZ2VAbm9raWEuY29tPjsgU0lQQ09S RSA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ29tbWVudGVycywg cGxlYXNlIGNoZWNrIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDEudHh0DQoN CndoYXQgaWYgdGhlIGNhbGxlciBpcyBhbiBhdXRvbWF0YSAtIGxpa2UgYSBzb2Z0cGhvbmUsIGV0 YyB0aGVuIGhvdyBkb2VzIDY2NiByZXNwb25zZSBoZWxwIGluIGJsb2NraW5nIHRoZSBjYWxsZXIg KGlwIG9yIHBvcnQgbWF5IGtlZXAgY2hhbmdpbmcpDQpSZWdhcmRzDQpSYW5qaXQNCg0KT24gRnJp LCBKYW4gNiwgMjAxNyBhdCAxMTo1OSBBTSwgQnJldHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNv bTxtYWlsdG86YnJldHRAYnJvYWRzb2Z0LmNvbT4+IHdyb3RlOg0KSGksDQoNClllczsgSSB0aGlu ayB0aGF0IGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gZGlzY3VzcyBtaWQtZGlhbG9nIDY2NiBp biByZWxhdGlvbiB0byBSRkMgNTA1Ny4NCg0KSSBkb27igJl0IGhhdmUgYSBzdHJvbmcgb3Bpbmlv biBhYm91dCBpZiA2NjYgaW1wYWN0cyBUcmFuc2FjdGlvbiBPbmx5LCBEZXN0cm95cyBVc2FnZSwg b3IgRGVzdHJveXMgRGlhbG9nLiAgSG93ZXZlciBldmVuIHRob3VnaCBJ4oCZbSBub3Qgc3VyZSBp Zi93aHkgc29tZW9uZSB3b3VsZCBzZW5kIGEgNjY2IHJlc3BvbnNlIGZvciBtaWQtZGlhbG9nIHJl cXVlc3QsIGl0IG1pZ2h0IGJlIGJldHRlciB0byBvbmx5IGltcGFjdCB0aGUgdHJhbnNhY3Rpb24u ICBGb3IgZXhhbXBsZSwgbWVkaWEgc2VydmVyIG1pZ2h0IHdhbnQgdG8gcmV0dXJuIDY2NiBmb3Ig c29tZSBtaWQtZGlhbG9nIHJlcXVlc3RzIHdoaWxlIGNvbnRpbnVpbmcgdG8gcGxheSB0cmVhdG1l bnQgYXNzb2NpYXRlZCB3aXRoIElOVklUReKAmXMgNjY2Lg0KDQoNCkZyb206IEhlbm5pbmcgU2No dWx6cmlubmUgW21haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8bWFpbHRvOkhlbm5p bmcuU2NodWx6cmlubmVAZmNjLmdvdj5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAwNSwgMjAx NyA2OjI0IFBNDQpUbzogQnJldHQgVGF0ZTsgRHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgc2lw Y29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lw Y29yZV0gQ29tbWVudGVycywgcGxlYXNlIGNoZWNrIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMt dW53YW50ZWQtMDEudHh0DQoNCg0KV291bGQgaXQgYmUgaGVscGZ1bCB0byBpbmRpY2F0ZSB0aGF0 IDY2NiBzaG91bGQgYmUgdHJlYXRlZCBhcyA2MDQgKGFzIHRoYXQgc2VlbXMgbW9zdCByZWFzb25h YmxlLCBnaXZlbiB0aGF0IDY2NiBpcyBwcm9iYWJseSBhIGRpYWxvZyBraWxsZXIuIFRlbnRhdGl2 ZSB3b3JkaW5nOg0KDQoNCg0KRm9sbG93aW5nIDx4cmVmPSJSRkM1MDU3Ii8+LCB0aGUgNjY2IHJl c3BvbnNlIGRlc3Ryb3lzIHRoZSBkaWFsb2cuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPG1haWx0bzpicmV0 dEBicm9hZHNvZnQuY29tPj4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDUsIDIwMTcgODozMDo1 MCBBTQ0KVG86IERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQik7IEhlbm5pbmcgU2NodWx6cmlubmU7 IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTog W3NpcGNvcmVdIENvbW1lbnRlcnMsIHBsZWFzZSBjaGVjayBkcmFmdC1pZXRmLXNpcGNvcmUtc3Rh dHVzLXVud2FudGVkLTAxLnR4dA0KDQo+IEZ1cnRoZXIgaWYgaXQgZG9lcyBhcHBlYXIgaW4gYSBz dWJzZXF1ZW50IHRyYW5zYWN0aW9uIHdpdGhpbg0KPiBhIGRpYWxvZyB3aGF0IGlzIHRoZSBhY3Rp b24gYnkgdGhlIHJlY2VpdmVyIGluIHRlcm1zIG9mIGRpYWxvZw0KPiBoYW5kbGluZyAodW5sZXNz IHdlIHdhbnQgdG8gcHJlY2x1ZGUgaXQgZnJvbSBzdWJzZXF1ZW50DQo+IHRyYW5zYWN0aW9ucyku IElzIGl0IGFscmVhZHkgY292ZXJlZCBieSBSRkMgNTA1Ny4NCg0KUkZDIDUwNTcgZG9lcyBkaXNj dXNzIDZ4eCBoYW5kbGluZy4gIEhvd2V2ZXIgc2luY2Ugbm90ZSAxNyBpbmRpY2F0ZXMgIjZ4eA0K dW5yZWNvZ25pemVkIHJlc3BvbnNlcyIgYW5kIFRhYmxlIDEgaW5kaWNhdGVzICJ1bmtub3duIDZ4 eCIsIEknbSBub3QNCnBvc2l0aXZlIGlmIFRhYmxlIDIncyA2eHggaW1wYWN0IChUcmFuc2FjdGlv bikgd2FzIGludGVuZGVkIHRvIGFsc28gYXBwbHkNCnRvIGtub3duIDZ4eCByZXNwb25zZXMgZGVm aW5lZCBzdWJzZXF1ZW50IHRvIFJGQyA1MDU3Lg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0 Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmU8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zaXBjb3JlJmQ9 RGdNRmFRJmM9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERV MVhlSElZUkhmYXJwazRNSzU5UkUmbT0ybFZxcDBmQkx5SjREcFI5Nmdwel9RbDkxTkFVaW9aQkdZ eEtpRnhtQ3Z3JnM9SmZ0MHIxckFvdnVITnBGR1JIMWRhQldBOVphYWFIWndOMHZCS1VxS25aOCZl PT4NCg0K --_000_CY1PR09MB0634BB88E5E2D0868322212EEA630CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6TWVubG87fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmxvY2tp bmcgd291bGQgbm90IGJlIGJhc2VkIG9uIElQIGFkZHJlc3NlcyBvciBwb3J0IG51bWJlcnMsIGZv ciB0aGUgcmVhc29ucyB5b3UgaGludCBhdC4gVHJlYXRtZW50IGlzIGJhc2VkIG9uIGNhbGxpbmcg cGFydHkgbnVtYmVyIChob3dldmVyIGNhcnJpZWQpLCByZWNhbGxpbmcNCiB0aGUgZGlzY3Vzc2lv biBmcm9tIGEgZmV3IHdlZWtzIGFnbyAoYW5kIHJlZmxlY3RlZCBpbiB0aGUgZHJhZnQpIGFib3V0 IHBvdGVudGlhbCBpbXBhY3Qgb2Ygc3Bvb2ZpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJhbmppdCBBdmFzYXJhbGEg W21haWx0bzpyYW5qaXRrYXYwODExQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEphbnVhcnkgMDYsIDIwMTcgMjo1MiBQTTxicj4NCjxiPlRvOjwvYj4gQnJldHQgVGF0ZSAm bHQ7YnJldHRAYnJvYWRzb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEhlbm5pbmcgU2NodWx6 cmlubmUgJmx0O0hlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiZndDs7IERyYWdlLCBLZWl0aCAo Tm9raWEgLSBHQikgJmx0O2tlaXRoLmRyYWdlQG5va2lhLmNvbSZndDs7IFNJUENPUkUgJmx0O3Np cGNvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gQ29t bWVudGVycywgcGxlYXNlIGNoZWNrIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQt MDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPndoYXQgaWYgdGhlIGNhbGxlciBpcyBhbiBh dXRvbWF0YSAtIGxpa2UgYSBzb2Z0cGhvbmUsIGV0YyB0aGVuIGhvdyBkb2VzIDY2NiByZXNwb25z ZSBoZWxwIGluIGJsb2NraW5nIHRoZSBjYWxsZXIgKGlwIG9yIHBvcnQgbWF5IGtlZXAgY2hhbmdp bmcpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHM8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmFuaml0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIEphbiA2LCAy MDE3IGF0IDExOjU5IEFNLCBCcmV0dCBUYXRlICZsdDs8YSBocmVmPSJtYWlsdG86YnJldHRAYnJv YWRzb2Z0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmJyZXR0QGJyb2Fkc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlllczsgSSB0aGluayB0aGF0 IGl0IHdvdWxkIGJlIGJlbmVmaWNpYWwgdG8gZGlzY3VzcyBtaWQtZGlhbG9nIDY2NiBpbiByZWxh dGlvbiB0byBSRkMgNTA1Ny48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JIGRvbuKAmXQgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGFib3V0IGlmIDY2NiBpbXBh Y3RzIFRyYW5zYWN0aW9uIE9ubHksIERlc3Ryb3lzIFVzYWdlLCBvciBEZXN0cm95cyBEaWFsb2cu Jm5ic3A7DQogSG93ZXZlciBldmVuIHRob3VnaCBJ4oCZbSBub3Qgc3VyZSBpZi93aHkgc29tZW9u ZSB3b3VsZCBzZW5kIGEgNjY2IHJlc3BvbnNlIGZvciBtaWQtZGlhbG9nIHJlcXVlc3QsIGl0IG1p Z2h0IGJlIGJldHRlciB0byBvbmx5IGltcGFjdCB0aGUgdHJhbnNhY3Rpb24uJm5ic3A7IEZvciBl eGFtcGxlLCBtZWRpYSBzZXJ2ZXIgbWlnaHQgd2FudCB0byByZXR1cm4gNjY2IGZvciBzb21lIG1p ZC1kaWFsb2cgcmVxdWVzdHMgd2hpbGUgY29udGludWluZyB0byBwbGF5IHRyZWF0bWVudA0KIGFz c29jaWF0ZWQgd2l0aCBJTlZJVEXigJlzIDY2Ni48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292IiB0YXJnZXQ9Il9ibGFuayI+SGVubmluZy5TY2h1 bHpyaW5uZUBmY2MuZ292PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFy eSAwNSwgMjAxNyA2OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBCcmV0dCBUYXRlOyBEcmFnZSwgS2Vp dGggKE5va2lhIC0gR0IpOyA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPg0Kc2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6 IFtzaXBjb3JlXSBDb21tZW50ZXJzLCBwbGVhc2UgY2hlY2sgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0 YXR1cy11bndhbnRlZC0wMS50eHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IGlkPSJtXy0zODAxMjg1NzMwODQ3MTI2NDA1eF9kaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8 cD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5Xb3VsZCBpdCBiZSBoZWxwZnVsIHRvIGluZGljYXRlIHRoYXQgNjY2IHNo b3VsZCBiZSB0cmVhdGVkIGFzIDYwNCAoYXMgdGhhdCBzZWVtcyBtb3N0IHJlYXNvbmFibGUsIGdp dmVuIHRoYXQgNjY2IGlzIHByb2JhYmx5IGEgZGlhbG9nIGtpbGxlci4gVGVudGF0aXZlIHdvcmRp bmc6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpNZW5sbztjb2xvcjpibGFjayI+Rm9sbG93aW5nIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMwNDMzRkYiPiZsdDt4cmVmPTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiNC NDI2MUEiPiZxdW90O1JGQzUwNTcmcXVvdDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjVwdDtmb250LWZhbWlseTpNZW5sbztjb2xvcjojMDQzM0ZGIj4vJmd0Ozwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOmJsYWNrIj4sDQog dGhlIDY2NiByZXNwb25zZSBkZXN0cm95cyB0aGUgZGlhbG9nLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIi IHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxp Z249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTM4MDEyODU3MzA4NDcxMjY0MDV4X2Rp dlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiBCcmV0dA0KIFRhdGUgJmx0OzxhIGhyZWY9Im1haWx0bzpicmV0dEBicm9hZHNvZnQuY29tIiB0 YXJnZXQ9Il9ibGFuayI+YnJldHRAYnJvYWRzb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8 L2I+IFRodXJzZGF5LCBKYW51YXJ5IDUsIDIwMTcgODozMDo1MCBBTTxicj4NCjxiPlRvOjwvYj4g RHJhZ2UsIEtlaXRoIChOb2tpYSAtIEdCKTsgSGVubmluZyBTY2h1bHpyaW5uZTsgPGEgaHJlZj0i bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCnNpcGNvcmVAaWV0Zi5v cmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2lwY29yZV0gQ29tbWVudGVycywgcGxl YXNlIGNoZWNrIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDEudHh0PC9zcGFu Pg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IEZ1cnRoZXIg aWYgaXQgZG9lcyBhcHBlYXIgaW4gYSBzdWJzZXF1ZW50IHRyYW5zYWN0aW9uIHdpdGhpbjxicj4N CiZndDsgYSBkaWFsb2cgd2hhdCBpcyB0aGUgYWN0aW9uIGJ5IHRoZSByZWNlaXZlciBpbiB0ZXJt cyBvZiBkaWFsb2c8YnI+DQomZ3Q7IGhhbmRsaW5nICh1bmxlc3Mgd2Ugd2FudCB0byBwcmVjbHVk ZSBpdCBmcm9tIHN1YnNlcXVlbnQ8YnI+DQomZ3Q7IHRyYW5zYWN0aW9ucykuIElzIGl0IGFscmVh ZHkgY292ZXJlZCBieSBSRkMgNTA1Ny48YnI+DQo8YnI+DQpSRkMgNTA1NyBkb2VzIGRpc2N1c3Mg Nnh4IGhhbmRsaW5nLiZuYnNwOyBIb3dldmVyIHNpbmNlIG5vdGUgMTcgaW5kaWNhdGVzICZxdW90 OzZ4eDxicj4NCnVucmVjb2duaXplZCByZXNwb25zZXMmcXVvdDsgYW5kIFRhYmxlIDEgaW5kaWNh dGVzICZxdW90O3Vua25vd24gNnh4JnF1b3Q7LCBJJ20gbm90PGJyPg0KcG9zaXRpdmUgaWYgVGFi bGUgMidzIDZ4eCBpbXBhY3QgKFRyYW5zYWN0aW9uKSB3YXMgaW50ZW5kZWQgdG8gYWxzbyBhcHBs eTxicj4NCnRvIGtub3duIDZ4eCByZXNwb25zZXMgZGVmaW5lZCBzdWJzZXF1ZW50IHRvIFJGQyA1 MDU3Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNp cGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmci PnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19zaXBjb3JlJmFtcDtkPURnTUZhUSZhbXA7Yz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JmFt cDtyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERVMVhlSElZUkhmYXJwazRNSzU5UkUmYW1wO209MmxW cXAwZkJMeUo0RHBSOTZncHpfUWw5MU5BVWlvWkJHWXhLaUZ4bUN2dyZhbXA7cz1KZnQwcjFyQW92 dUhOcEZHUkgxZGFCV0E5WmFhYUhad04wdkJLVXFLblo4JmFtcDtlPSIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTwvYT48bzpwPjwv bzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_CY1PR09MB0634BB88E5E2D0868322212EEA630CY1PR09MB0634namp_-- From nobody Fri Jan 6 12:55:39 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2160129EBC for ; Fri, 6 Jan 2017 12:55:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.301 X-Spam-Level: X-Spam-Status: No, score=-7.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSa0SDHJMRUz for ; Fri, 6 Jan 2017 12:55:36 -0800 (PST) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id 91135129EAB for ; Fri, 6 Jan 2017 12:55:36 -0800 (PST) X-AuditID: 1207440e-7dfff700000009ec-0b-58700445325b Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id D7.71.02540.54400785; Fri, 6 Jan 2017 15:55:35 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v06KtVJ8005980 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 6 Jan 2017 15:55:32 -0500 To: "Dale R. Worley" , marianne.mohali@orange.com References: <87fukwc7g4.fsf@hobgoblin.ariadne.com> From: Paul Kyzivat Message-ID: <55a800af-ed23-e4c2-d2cc-6ea0b495bd02@alum.mit.edu> Date: Fri, 6 Jan 2017 15:55:31 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <87fukwc7g4.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrEIsWRmVeSWpSXmKPExsUixO6iqOvOUhBhcG2mqcWGLcdZLLY172Oy +PpjE5vFyxNlDiwek/d/ZfZYsuQnk8fdW5eYPFqenWQLYInisklJzcksSy3St0vgyvjyfiN7 QRdHxc4Xp5kbGNewdTFyckgImEhsnPiRtYuRi0NI4DKjxIsZj5ghnGtMEuf2fAWrEhbQkDh7 ZhcziC0i4Cpx+HcnE4gtJGAkcf3fZ3YQm1lAW+L87A6wejYBLYk5h/6zdDFycPAK2Es8eJ8D YrIIqEgsPxkFUiEqkCbx4ORWRhCbV0BQ4uTMJywgNqeAscS8WeeYICbaStyZu5sZwpaX2P52 DvMERv5ZSFpmISmbhaRsASPzKka5xJzSXN3cxMyc4tRk3eLkxLy81CJdY73czBK91JTSTYyQ oOXbwdi+XuYQowAHoxIPr8aj/Agh1sSy4srcQ4ySHExKorz/XwCF+JLyUyozEosz4otKc1KL DzFKcDArifAm/gfK8aYkVlalFuXDpKQ5WJTEedWWqPsJCaQnlqRmp6YWpBbBZGU4OJQkeDuY CiKEBItS01Mr0jJzShDSTBycIMN5gIYbMQPV8BYXJOYWZ6ZD5E8xKkqJ8/KCJARAEhmleXC9 sKTyilEc6BVhXiGQKh5gQoLrfgU0mAlosKAnyNXFJYkIKakGRrmXm5880r1zpZhTh+F1zD8l 4VDO3fIRr71lVfd69rxc9eTOiTfz2b/ySGR+a9+6L8if+0ruxw/XRSuED2n+uRaw2eOLyqmn 5pEGew/NVaxO3PDn4t1fqzmOyE2fO2F5/LHZNlyHbHzztk30Lbu3+0x207lFO6/ULznAcXvz tQslnNbN5+a/5XuqxFKckWioxVxUnAgAHnOiKQUDAAA= Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 20:55:37 -0000 Dale, On 1/6/17 2:30 PM, Dale R. Worley wrote: > writes: >> I don't want to re-open the discussion on the Tables (I also heard >> that they are now deprecated). I agreed that RFC3261 comes first so >> it should have been stated in RFC3312 that RFC3312 also update the >> 3261 table. >> >> I would propose to have an errata to RFC3312 adding this clarification. >> Any other view? > > Relative to Jean Mahoney's message, the decision is to deprecate Table 2 > in RFC 3261, and defer to text descriptions. As I understand it, the > text description of the use of bodies in CANCEL given in RFC 3312 is > clear, and clearly supersedes the discussion in RFC 3261, so there is no > need for an erratum. I think you are missing Adam's point. Remember that CANCEL is hop-by-hop. If you were generate a CANCEL with SDP and pass it to a proxy that doesn't have specific support for 3312 then there is no reason to expect that the SDP would be passed on downstream. Thanks, Paul From nobody Sat Jan 7 11:53:58 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C58CD129697 for ; Sat, 7 Jan 2017 11:53:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0lcITHyAgsA for ; Sat, 7 Jan 2017 11:53:56 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE76F129694 for ; Sat, 7 Jan 2017 11:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=q37GrecQ2pxSfoQd3U0k9DBaBMlj3i4G3LWvYfLf8Qk=; b=SlHlOzOMCchgG0PmOBj3M6XYuGzSAekWpjDPTvhYar0ZgukyQS1/2OBYU5bF7c1zfp9Ao7ToQOcP1u59lpVM65kikVwzR39sWIPjpDEkmw2zMRu8fu86seJhf0cUoJs6movnxT4Wo3WUeYE1ajFp4+QMIfizQp3jJoUohgzHRSg= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0016.outbound.protection.outlook.com [207.46.163.16]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-87-dnfynJzfOYaqV_3ywT68Qg-1; Sat, 07 Jan 2017 14:53:52 -0500 Received: from CY1PR03MB2348.namprd03.prod.outlook.com (10.166.207.147) by CY1PR03MB2346.namprd03.prod.outlook.com (10.166.207.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sat, 7 Jan 2017 19:53:50 +0000 Received: from CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) by CY1PR03MB2348.namprd03.prod.outlook.com ([10.166.207.147]) with mapi id 15.01.0803.021; Sat, 7 Jan 2017 19:53:50 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AQHSZu3dGYJ0jtsz5EmPEreSyl8iJqEp15kAgAAldrCAAIf2AIABEC0AgAAlt4CAAbYfAA== Date: Sat, 7 Jan 2017 19:53:50 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 6cbed300-f027-46b8-022e-08d43736e69f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR03MB2346; x-microsoft-exchange-diagnostics: 1; CY1PR03MB2346; 7:XRowo5b0ueL57bFfVH8TmY2HQ3f/C9yS5LJNcT0xCFL5QIcgRjtfaaZb0arKYsOfmY7OKbOdkaVmBG7FOZDaukzOFHJa3hIeHEGEzK0F3RwzRVsoCK+oRAtcAne5grW0eeZBaeRaIyEHAZmps3gMr8Rbq8ke/5+fSwSFc5jA35OelVEm9jPGbPIUfDYaOBnWsoutdvC377QveKTaXc+4UDAIP294elgziqZznmnmiQy9/Wb7MZ31VWDhTNocZMYKvSZNJvPNO8srAQ4qBcaqoG9C5Pm9Z1nlPGoOjWnjPUrR+ZJlMa3ezabGJH8oYkPBGRgO7KFpjJ9jTk8IFCEwwYhe2w2Lg5kqmmeUFERPYBC1NNOziYBWZ88G4d62K9PWeHQ+MU9CnJaotwch04NBYVsqOCXeszLNJzH2Q+cOaD6Tb1L3RW4dRL0IvzrO0e+04HalzBRFc003hgfWw5hWcA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6047074)(6072148); SRVR:CY1PR03MB2346; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2346; x-forefront-prvs: 018093A9B5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(199003)(13464003)(24454002)(189002)(77096006)(6306002)(3846002)(8676002)(92566002)(97736004)(25786008)(33656002)(6506006)(81156014)(6436002)(81166006)(122556002)(2900100001)(102836003)(54356999)(2906002)(101416001)(74316002)(93886004)(76176999)(230783001)(50986999)(38730400001)(6116002)(9686003)(105586002)(106116001)(5660300001)(7696004)(3660700001)(2950100002)(229853002)(8936002)(305945005)(66066001)(106356001)(3280700002)(5001770100001)(68736007)(189998001)(107886002)(8666007)(2501003)(55016002)(7736002)(86362001)(99286003)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2346; H:CY1PR03MB2348.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2017 19:53:50.0562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2346 X-MC-Unique: dnfynJzfOYaqV_3ywT68Qg-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 19:53:58 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, January 06, 2017 12:43 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 >=20 > On 1/6/17 10:28 AM, marianne.mohali@orange.com wrote: > > Hi, > > > > To reflect the question of the interpretation of the 666 response > > interpretation when the caller has several identities used for this > > call (ie. From and P-Asserted-Identity are different) or call > > forwarding/call transfer use cases for which it has to be discussed > > which party should be considered has a fraudulent (ie. the calling > > party or the diverting party or both ?) ; I propose to add the followin= g text: > > > > This document defines a mechanism by which a called party can reject > > an unwanted call without consideration of the calling party > > identification that remain to the service provider policy. Indeed, the > > calling party identity may be reflected in different way for a direct > > call or after a diverting service in P-Asserted-Identity, From, > > History-Info or any concurrent header field that can be present at the > > same time in a SIP message. > > > > Those questions are real issues for operators and implementors and > > they are a weakness that fraudulent callers could use to bypass the > mechanism. >=20 > ISTM there are two different cases here, and the identity implications di= ffer > between them: >=20 > 1) the callee rejects the call without consideration of the content of th= e call. > Instead, the rejection is based solely on metadata about the call that is > available to the callee - e.g., callerid information presented, classific= ation > information, possibly time of day. It might also include information prov= ided > locally by the phone (e.g. from the local address book). >=20 > In this case the actual caller may be blameless. So care must be taken in > associating the rejection with the caller. >=20 > 2) the callee rejects the call after answering, based on the media conten= t of > the call. >=20 > In this case the rejection clearly applies to the caller even if the call= ee doesn't > know the caller's identity. >=20 > It may be difficult to distinguish between these. Certainly using 666 as = a > response code must be case (1). But using 666 as a reason isn't necessari= ly > case (2) - the callee may be slow and reject based on metadata after > answering, or may use a combination of content and metadata in making tha= t > decision. >=20 > This is not something that can be resolved in this document, but it may b= e > worthwhile to identify that these issues exist and must be considered by > those who act on 666 responses. [TOLGA] Even not that IMHO. It seems to me a better option to keep the docu= ment "clean" as far as its intention is used. >=20 > =09Thanks, > =09Paul >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Jan 8 09:46:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F81129557 for ; Sun, 8 Jan 2017 09:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOs80q7Vy-ED for ; Sun, 8 Jan 2017 09:46:43 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA8D129459 for ; Sun, 8 Jan 2017 09:46:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0fMlJUXSPFvw7uMUuyU6Ivm8Q7QG6yWoBhp3Da/eJvk=; b=j1yOglDF3hIIQBNZWKP9tSOG3UvEVsuniKPvNlO4rXkAOrlwyyS5Y/vK1cR/ErMIwD1aQPSFSfTOHbTg4D4yPxH8vlhGRGNebLZx0vCBDIUxLJo3uluTjaZNQSjlB8nMEpy68yIyuUVYOuS01KPZKtutm0YJCrbMuNjTnD4xnnE= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0050.outbound.protection.outlook.com [216.32.180.50]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-146-n2zEyP_5O8GKzhtZwM6QQw-1; Sun, 08 Jan 2017 12:46:39 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Sun, 8 Jan 2017 17:46:37 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Sun, 8 Jan 2017 17:46:37 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" , Henning Schulzrinne Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? Thread-Index: AQHSaC4uwYauUtiVP064EKv+66tWy6Eu3K0Q Date: Sun, 8 Jan 2017 17:46:36 +0000 Message-ID: References: (Henning.Schulzrinne@fcc.gov) <877f68dybk.fsf@hobgoblin.ariadne.com> In-Reply-To: <877f68dybk.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 86ce6876-2f30-4f75-7b07-08d437ee4b46 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:NMxxZnGzIAcAphglCIxHeNqQF9s/KeqSHUNAkMRNNb+ZaDRKWEbtucdY9rbM3yKW23165iB0+/lV0CCcRRIGOg4r8RBnbPiKaSsgFQ2yz9J9k6ippZNSQpX5JXJmPzj6hSVE8D7mY6MjbHR7h/ke9QDxVzumXOO3dXW2Nu2aKglnN7sdxJAtyONA3pcZL+npygO3bwt+sbhF+5W+D7O9szsf39hT2fIqoGnYD+iP6FbEEBIvCsKU0KECfUlEPwEXYpWL81GjBTN2oOATAjMf+0WG2SgvMk948jPupioYzhp4g4bAQJQxaOUj13IjPhOavGgkkYlrjg7iinW0cmWcOv6YvAGpzO86ji9wRrwrHyHvjtuynRyN9atOUYASpiaAGCnwyBhMFSh51zPN9pg2YUSxZCDMZjsGgjJIkUrmAehmYMmOm48zuRs091wHO2ZqFtKa7eBtMcVC70Zrq5nsLA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 0181F4652A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(377454003)(57704003)(13464003)(66066001)(77096006)(6506006)(6436002)(2900100001)(9686003)(122556002)(38730400001)(2950100002)(3280700002)(305945005)(86362001)(102836003)(6116002)(7696004)(25786008)(7736002)(74316002)(92566002)(3846002)(101416001)(5001770100001)(97736004)(68736007)(50986999)(76176999)(33656002)(3660700001)(5660300001)(54356999)(230783001)(189998001)(99286003)(2906002)(4326007)(229853002)(105586002)(8676002)(81156014)(81166006)(8936002)(55016002)(106116001)(561944003)(106356001)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jan 2017 17:46:36.9065 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: n2zEyP_5O8GKzhtZwM6QQw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 17:46:45 -0000 Inline... Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worl= ey > Sent: Friday, January 06, 2017 10:05 AM > To: Henning Schulzrinne > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need > another response code? >=20 > Henning Schulzrinne writes: > > Are you talking about the case where the end system itself does the > > blocking, e.g., via an app (e.g., Hiya or Nomorobo)? > > > > Leaving aside Martin's concerns for a moment, I admit that I'm not > > convinced that this distinction is meaningful. For example, an app or > > dialer may have a personal blacklist (I believe Android does). This is > > something done by the user, not AI (so Martin may like it...), but the > > dialer would be responding with a 666 on the next call to signal the > > reason for the rejection. Is that a robot instead? What if the app > > just suggests that this is a "bad" call and the user hits the spam > > button? I admit that I have a hard time drawing a firm line that would > > provide sufficient guidance to implementors to choose one status code > > or the other. >=20 > I'm using a model that resembles how I think spam filtering works: the u= ser's > SIP service monitors the calls for which the user triggers 666. > Based on this, it constructs a filter for which calls will be presented t= o the > user. The calls that are rejected aren't rejected specifically because t= he user > has specified that they are to be rejected, but based on the filter. So = there > will be occasional mistakes. It seems like it would be useful to notify = the > caller that the call was rejected based on such a filter. >=20 > > This seems like something we could discuss once we have a bit more > > operational experience. Maybe a "Warning" code would be the more > > appropriate means of conveying such additional information, for > > example. >=20 > Hmmm, looking at the drarft again, the specifics of blocking, or even whe= ther > blocking is done, are out of scope. But I like your proposal of a Warnin= g code. > And we might need more than one Warning code, if this situation turns out > to be more complicated. [TOLGA] I don't think there is a difference between a call being rejected b= y the user pushing the "Spam button" v.s. the call being auto-rejected beca= use of a list prepared by the user and residing *only* in the UE. Both of t= hem have the same meaning: The user does not want this call. And they would= should be treated the same as far as the logic in network is concerned. A = "blocking list" maintained by the user, e.g. through a Web Portal, and know= n by the network logic would be a different story: That probably would caus= e the call to be blocked before it is even sent to the UE. I am strongly in= favor of keeping "666 unwanted" consistent with the semantics of "This cal= l is unwanted by the user" rather than overloading it. From nobody Mon Jan 9 07:47:43 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37F0A129D82 for ; Mon, 9 Jan 2017 07:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eqG6K87qT6xo for ; Mon, 9 Jan 2017 07:47:37 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0561F129D87 for ; Mon, 9 Jan 2017 07:47:36 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-04v.sys.comcast.net with SMTP id QcAOcaiCuGIgtQcAacMLpE; Mon, 09 Jan 2017 15:47:36 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-14v.sys.comcast.net with SMTP id QcAYcl1Ob34MTQcAZciCF8; Mon, 09 Jan 2017 15:47:35 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v09FlSA5016948; Mon, 9 Jan 2017 10:47:28 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v09FlSCv016945; Mon, 9 Jan 2017 10:47:28 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 09 Jan 2017 10:47:27 -0500 Message-ID: <87r34cjkvk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMOimjcctGi5iLIJKnsEPOLKUPODBn8hlZSQWVJuxq+KKFq6znDnNAWRqKjUa1M159IRWyatynpkdWFIaj//FhwX/HTuD8C7MXfPa2fSK3ChZ5cVNz21 vfG+/sy++EVa5Go7KXkaU2gew8O8VP8tNzLz+hFupGOyleiqKPjShIqtL3O1bANMkL4JrdXwD7123w== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 15:47:41 -0000 "Asveren, Tolga" writes: > [TOLGA] I don't think there is a difference between a call being > rejected by the user pushing the "Spam button" v.s. the call being > auto-rejected because of a list prepared by the user and residing > *only* in the UE. Both of them have the same meaning: The user does > not want this call. And they would should be treated the same as far > as the logic in network is concerned. A "blocking list" maintained by > the user, e.g. through a Web Portal, and known by the network logic > would be a different story: That probably would cause the call to be > blocked before it is even sent to the UE. True, but my point is that in practice, a fraction of rejected calls will not be rejected based on absolute criteria specified by the user but by probabilistic mechanisms that are trained by past input from the user. In that case, it's worth telling the originator that the rejection was probabilistic rather than absolute. > I am strongly in favor of keeping "666 unwanted" consistent with the > semantics of "This call is unwanted by the user" rather than > overloading it. But as has been noted before, this draft isn't about the rejection mechanism, but how the user can communicate upstream his specific rejection of one call. Dale From nobody Mon Jan 9 08:02:23 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79BEE12950E for ; Mon, 9 Jan 2017 08:02:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32_CLqdx309t for ; Mon, 9 Jan 2017 08:02:19 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2DD129681 for ; Mon, 9 Jan 2017 08:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GVTl+YdtaV1g1QVVLhq7UYOpDQmXgY+5NyaPKjRtfWI=; b=DeSwp/goaIxzBadB6DaYSfsnI0HKC1IshDURW3qZES/+yKf5rHm2ZBQjN95fixGZScM51FCTXZDsOShEQBJD+hZ5wEXxvWDlFroWKCdmYcFcdbgtJXLZ1hPCWLq8wpI6gJznulnq/Fxpj5XIHoOBvyclaeoU76uJXWSwaiAZ5SY= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-35-XACzkUPsOJK3kPcTPzZt2w-1; Mon, 09 Jan 2017 11:02:13 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Mon, 9 Jan 2017 16:02:10 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0803.021; Mon, 9 Jan 2017 16:02:10 +0000 From: "Asveren, Tolga" To: "Dale R. Worley" Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? Thread-Index: AQHSao+twYauUtiVP064EKv+66tWy6EwTUyA Date: Mon, 9 Jan 2017 16:02:10 +0000 Message-ID: References: (tasveren@sonusnet.com) <87r34cjkvk.fsf@hobgoblin.ariadne.com> In-Reply-To: <87r34cjkvk.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 93ec7681-5a46-4622-844b-08d438a8de5a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:l4VD8CJ/tb6TcmX644pCj9JxXEKyFk8U3t/3qwa1lMe7EOC7o7cmz8zpZiCPwqSEWPy9PdUfh1KzbhZCMvJTDXVVuYK77PfCjSnCOEpbI2UX29yy061aqa4tdD6a/ZsqYcF1j2Givu+Gg0ML3d43Wdbl6B1FGiW5jfAuTwmKIzEOd9aLJ7VPdeSQdmYSWVzojvXNG/B3J4b3l9uwJcshaqhFyq6HlGKaBL8DW5aq78lZnqlbwr4TaEkqlWCORBTdyIbEOXkAmhh8GiDKD/44sI5NGc6UZn5IG5ytuPmMHeFe4lPwTqQllZQF+Pzcp+ieCQR8hVBmllIJUu98sZQVjmbgRIXwfA0k18Un8rOq5xH29NTvx03La5jSmUM5JmP3RHNm7GHvHmT59FAwDyUSX9vjTpbMKI1pdjzFA5uaLl74JGrtVVEMXMNV8f4GQ1VttJ3Vs+0GG92jceeAQHnNrA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 0182DBBB05 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(377454003)(13464003)(57704003)(199003)(189002)(33656002)(3660700001)(5660300001)(230783001)(101416001)(54356999)(68736007)(76176999)(50986999)(97736004)(8936002)(81166006)(81156014)(8676002)(106356001)(55016002)(189998001)(2906002)(99286003)(4326007)(105586002)(106116001)(2900100001)(9686003)(38730400001)(122556002)(229853002)(6506006)(6436002)(66066001)(77096006)(25786008)(110136003)(7696004)(92566002)(3846002)(102836003)(7736002)(74316002)(3280700002)(305945005)(2950100002)(6116002)(6916009)(86362001)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2017 16:02:10.0676 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: XACzkUPsOJK3kPcTPzZt2w-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 16:02:21 -0000 > -----Original Message----- > From: Dale R. Worley [mailto:worley@ariadne.com] > Sent: Monday, January 09, 2017 10:47 AM > To: Asveren, Tolga > Cc: sipcore@ietf.org > Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need > another response code? >=20 > "Asveren, Tolga" writes: > > [TOLGA] I don't think there is a difference between a call being > > rejected by the user pushing the "Spam button" v.s. the call being > > auto-rejected because of a list prepared by the user and residing > > *only* in the UE. Both of them have the same meaning: The user does > > not want this call. And they would should be treated the same as far > > as the logic in network is concerned. A "blocking list" maintained by > > the user, e.g. through a Web Portal, and known by the network logic > > would be a different story: That probably would cause the call to be > > blocked before it is even sent to the UE. >=20 > True, but my point is that in practice, a fraction of rejected calls will= not be > rejected based on absolute criteria specified by the user but by probabil= istic > mechanisms that are trained by past input from the user. In that case, i= t's > worth telling the originator that the rejection was probabilistic rather = than > absolute. [TOLGA] I think "666 unwanted" should cover only deterministic cases. And a= ctually I doubt any heuristic mechanism would reside in UE itself without k= nowledge from the network intelligence. I would think that heuristic analys= is is a functionality to be performed by network. >=20 > > I am strongly in favor of keeping "666 unwanted" consistent with the > > semantics of "This call is unwanted by the user" rather than > > overloading it. >=20 > But as has been noted before, this draft isn't about the rejection mechan= ism, > but how the user can communicate upstream his specific rejection of one > call. [TOLGA] Yes, and IMHO there is only one reason why such a rejection happens= -in the context of "666 unwanted": "The user considers this particular cal= l as spam/unwanted." >=20 > Dale From nobody Mon Jan 9 08:16:48 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A891294E4 for ; Mon, 9 Jan 2017 08:16:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.534 X-Spam-Level: X-Spam-Status: No, score=-0.534 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7DUWxXrdVHXA for ; Mon, 9 Jan 2017 08:16:46 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95C812944E for ; Mon, 9 Jan 2017 08:16:46 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-05v.sys.comcast.net with SMTP id Qcb6cvJHOMqbUQccncbZmi; Mon, 09 Jan 2017 16:16:45 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-11v.sys.comcast.net with SMTP id QcclcUxYCM7mdQccncshAu; Mon, 09 Jan 2017 16:16:45 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v09GGhhB019960; Mon, 9 Jan 2017 11:16:43 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v09GGgaR019952; Mon, 9 Jan 2017 11:16:42 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: <80d6f674-2ded-75be-bec3-2de9e1414e53@nostrum.com> (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 09 Jan 2017 11:16:41 -0500 Message-ID: <87k2a4jjiu.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfOm3eTdKng6KRdHz4xPJHDddIQgilA5xybFIQBhtSc1V/oBGXwTPkvneKNuusQHIx7s36RsRMQkxxVXzd7j9z7kkU2I4kqtloq1cfejUZxfyatCEa93K 2HZxD9epd5hLobRVdL3Oa8C/JLYDQKj02yt/BSxD3kbzFVG2bcEtGsZUXlC5asWTsDOMNbYxZRDcKA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 16:16:47 -0000 Adam Roach writes: > I think the error is in 3312, but it's not the flaw being discussed here. > > The error was in allowing 3312 to specify that a CANCEL can have a body. > While it's not stated normatively in English prose, the line of Table 2 > that you cite has been broadly interpreted to mean that CANCEL cannot > contain a body. The description of CANCEL handling at proxies does not > involve any steps that would copy the body from an incoming CANCEL to an > outgoing one. This has been a long-standing interpretation, dating back > to approximately the same era as RFC3261's own publication. Ugh. Though looking at 3312, I see this: 580 (Precondition Failure) responses and BYE and CANCEL requests, indicating failure to meet certain preconditions, SHOULD contain an SDP description, indicating which desired status triggered the failure. Note that this SDP description is not an offer or an answer, since it does not lead to the establishment of a session. The format of such a description is based on the last SDP (an offer or an answer) received from the remote UA. which suggests that SDP bodies should be put in 580 responses and BYE requests as well as CANCEL requests, and all of those would be unexpected in the prior technology. It sounds like the problem is that the mechanism proposed in that paragraph just won't work -- and that's more than an erratum, it needs a technical solution, if only to state that the recovery process (whatever it is) that the SDP description is supposed to enable won't happen. Dale From nobody Mon Jan 9 09:18:51 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE8AA1294C3 for ; Mon, 9 Jan 2017 09:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRvKbsJlDOX8 for ; Mon, 9 Jan 2017 09:18:48 -0800 (PST) Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085E512711D for ; Mon, 9 Jan 2017 09:18:48 -0800 (PST) Received: by mail-wj0-x22a.google.com with SMTP id ew7so55179425wjc.3 for ; Mon, 09 Jan 2017 09:18:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=J+HO/p0/IbZEOxFDJ52wS7FQu7aogdzy2SBMg8QLe9o=; b=apPBThGS2WJXrrxlPVxbIxSwlwL3PQbmAM7A8pkHIPUPgtnkaUI/2Ts6RNUalFrKY4 9cl+ruoeitp5ENM3w8nxakkYS6XdnaqGBbujAOJ44Z4pWflfVauztGDxBKTGRIp0pwgA FftvjFmijNgCG8/WcR76pgV90KiByGzbXOBYfUsiP5Tu3vqTNsoUbTY7opMj49lVfOa5 fp4y9G+2pB3y7+iCZpA40BpSDfZkHx4icxJvZ+Sftn6hshKWBYjEDkKsDrNqesaxn1G2 +ZRAEkfSRo6ltPIavlkFtru3qoOu4CpApNSsJqOM87dW7r1PNAgPj7demkOXU8OVwTaV FSEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=J+HO/p0/IbZEOxFDJ52wS7FQu7aogdzy2SBMg8QLe9o=; b=qnm4wr1U0f1IW4v68A+jcGJSzh6Y3XnQZAUoFGAtYlMrEqPqgGKxr+aPoBbEYEzE87 jSh6sr3NvB/ys4n2dLuwjcc2PdpJcH85QkM7FENz/fajz0KgSRmenDHcvpw9hLBewRvP Vc+tG9EnvsX1CWtTBDvWsJ5NuaN0YX9O/BybvTcB2siJdIZNsKsJh3TtExCT9E/a3le2 GDFbZjIIL3RtfbqZkNnm79KvRCl20mHag90Ul1+xB+bkCXtqCUQqM3lrb2tlkq99cSyK BGetwK3c6p9o6dpea/G7cuXl9sZ3kec/AMcGmhzuWZX8xTKIYVIxuadvl1Yx/IKdFCuY SMuA== X-Gm-Message-State: AIkVDXKrLznrMlbY990jfIE8g82KHy05JKlgRHCKwzHcNVVdWnPpfD75jwj9g7Dz3tSt6pblDqDkm2kS5Fhn3w== X-Received: by 10.194.81.169 with SMTP id b9mr2849937wjy.22.1483982326463; Mon, 09 Jan 2017 09:18:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.173.98 with HTTP; Mon, 9 Jan 2017 09:18:45 -0800 (PST) In-Reply-To: <87r34cjkvk.fsf@hobgoblin.ariadne.com> References: <87r34cjkvk.fsf@hobgoblin.ariadne.com> From: Ranjit Avasarala Date: Mon, 9 Jan 2017 11:18:45 -0600 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=047d7bea3afe6c00d90545ac8f05 Archived-At: Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 17:18:50 -0000 --047d7bea3afe6c00d90545ac8f05 Content-Type: text/plain; charset=UTF-8 Hi Dale true - this draft is about indication - but how do we ensure the unwanted caller is actually blocked? Thanks Ranjit On Mon, Jan 9, 2017 at 9:47 AM, Dale R. Worley wrote: > "Asveren, Tolga" writes: > > [TOLGA] I don't think there is a difference between a call being > > rejected by the user pushing the "Spam button" v.s. the call being > > auto-rejected because of a list prepared by the user and residing > > *only* in the UE. Both of them have the same meaning: The user does > > not want this call. And they would should be treated the same as far > > as the logic in network is concerned. A "blocking list" maintained by > > the user, e.g. through a Web Portal, and known by the network logic > > would be a different story: That probably would cause the call to be > > blocked before it is even sent to the UE. > > True, but my point is that in practice, a fraction of rejected calls > will not be rejected based on absolute criteria specified by the user > but by probabilistic mechanisms that are trained by past input from the > user. In that case, it's worth telling the originator that the > rejection was probabilistic rather than absolute. > > > I am strongly in favor of keeping "666 unwanted" consistent with the > > semantics of "This call is unwanted by the user" rather than > > overloading it. > > But as has been noted before, this draft isn't about the rejection > mechanism, but how the user can communicate upstream his specific > rejection of one call. > > Dale > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --047d7bea3afe6c00d90545ac8f05 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dale

true - this draft is a= bout indication - but how do we ensure the unwanted caller is actually bloc= ked?

Thanks
Ranjit

On Mon, Jan 9, 2017 at 9:47 AM, Dale R. Wo= rley <worley@ariadne.com> wrote:
"Asveren, Tolga" <tasveren@sonusnet.com> writes:
> [TOLGA] I don't think there is a difference between a call being > rejected by the user pushing the "Spam button" v.s. the call= being
> auto-rejected because of a list prepared by the user and residing
> *only* in the UE. Both of them have the same meaning: The user does > not want this call. And they would should be treated the same as far > as the logic in network is concerned. A "blocking list" main= tained by
> the user, e.g. through a Web Portal, and known by the network logic > would be a different story: That probably would cause the call to be > blocked before it is even sent to the UE.

True, but my point is that in practice, a fraction of rejected calls
will not be rejected based on absolute criteria specified by the user
but by probabilistic mechanisms that are trained by past input from the
user.=C2=A0 In that case, it's worth telling the originator that the rejection was probabilistic rather than absolute.

> I am strongly in favor of keeping "666 unwanted" consistent = with the
> semantics of "This call is unwanted by the user" rather than=
> overloading it.

But as has been noted before, this draft isn't about the rejection
mechanism, but how the user can communicate upstream his specific
rejection of one call.

Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--047d7bea3afe6c00d90545ac8f05-- From nobody Mon Jan 9 12:43:04 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15FC71294E7 for ; Mon, 9 Jan 2017 12:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR-OhIR5d0y8 for ; Mon, 9 Jan 2017 12:43:01 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7C5F1294B6 for ; Mon, 9 Jan 2017 12:43:01 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v09KgwCl086853 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 9 Jan 2017 14:42:59 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "Dale R. Worley" References: <87k2a4jjiu.fsf@hobgoblin.ariadne.com> From: Adam Roach Message-ID: <66ef794e-de09-da52-34ad-7abc8767ecd1@nostrum.com> Date: Mon, 9 Jan 2017 14:42:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <87k2a4jjiu.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:43:03 -0000 [as individual] On 1/9/17 10:16, Dale R. Worley wrote: > Adam Roach writes: >> I think the error is in 3312, but it's not the flaw being discussed here. >> >> The error was in allowing 3312 to specify that a CANCEL can have a body. >> While it's not stated normatively in English prose, the line of Table 2 >> that you cite has been broadly interpreted to mean that CANCEL cannot >> contain a body. The description of CANCEL handling at proxies does not >> involve any steps that would copy the body from an incoming CANCEL to an >> outgoing one. This has been a long-standing interpretation, dating back >> to approximately the same era as RFC3261's own publication. > Ugh. Though looking at 3312, I see this: > > 580 (Precondition Failure) responses and BYE and CANCEL requests, > indicating failure to meet certain preconditions, SHOULD contain an > SDP description, indicating which desired status triggered the > failure. Note that this SDP description is not an offer or an > answer, since it does not lead to the establishment of a session. > The format of such a description is based on the last SDP (an offer > or an answer) received from the remote UA. Right. That's the passage that is causing me some distress. > which suggests that SDP bodies should be put in 580 responses and BYE > requests as well as CANCEL requests, and all of those would be > unexpected in the prior technology. Well, bodies in BYEs and in error responses are accommodated by the base specification. Bodies in CANCEL are not. > It sounds like the problem is that the mechanism proposed in that > paragraph just won't work -- and that's more than an erratum, it needs a > technical solution, if only to state that the recovery process (whatever > it is) that the SDP description is supposed to enable won't happen. We've apparently made it over 14 years without this coming up at a SIPit or as a problem on the sip-implementors list. I'm not certain there's a need for some technical solution here -- I think a simple correction that removes the CANCEL body would clear up the confusion that Marianne identified. /a From nobody Mon Jan 9 14:10:24 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135E212960F for ; Mon, 9 Jan 2017 14:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.699 X-Spam-Level: X-Spam-Status: No, score=0.699 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkglkAnIZ9BE for ; Mon, 9 Jan 2017 14:10:19 -0800 (PST) Received: from qproxy1-pub.mail.unifiedlayer.com (qproxy1-pub.mail.unifiedlayer.com [173.254.64.10]) by ietfa.amsl.com (Postfix) with SMTP id 54F761295D5 for ; Mon, 9 Jan 2017 14:10:19 -0800 (PST) Received: (qmail 28700 invoked by uid 0); 9 Jan 2017 22:10:19 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy1.mail.unifiedlayer.com with SMTP; 9 Jan 2017 22:10:19 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id WN5F1u0111MNPNq01N5J1t; Mon, 09 Jan 2017 15:05:19 -0700 X-Authority-Analysis: v=2.1 cv=YpOcGeoX c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=IgFoBzBjUZAA:10 a=ZZnuYtJkoWoA:10 a=NvC-MaXgAAAA:8 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=Y253uYM9RvdnE9YcTIkA:9 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=KqrFWB7-IGoA:10 a=X5GqqM7ZcZwA:10 a=lCKLaNiBY0u9urARF_50:22 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:Message-ID: To:From:Subject:Date; bh=0A6lp9wqvgd45PYXYx0TtpA0jpUKoqvtbGf6KXuFWdA=; b=pRmb WsQJKdNTE0/gV2IEd1pH9YoFxemHldL+Lpj19gNohSBJXcjplOhSqFUWQQ6XBQLNfIGdpMWscfKky F6kjcOhgcljhhNu28x2VoLtB1P/mL39ngtIZQoD6LWBHZLR; Received: from pool-100-36-44-71.washdc.fios.verizon.net ([100.36.44.71]:63358 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1cQi43-00053j-Dp; Mon, 09 Jan 2017 15:05:15 -0700 User-Agent: Microsoft-MacOutlook/f.1d.0.161209 Date: Mon, 09 Jan 2017 17:05:13 -0500 From: Richard Shockey To: "stir@ietf.org" , Message-ID: <7F3DCD21-1085-4961-82D7-CE12DB308305@shockey.us> Thread-Topic: The Canadian Regulator has issued a Notice of Consultation on robocalls spoofing STIR/SHAKEN Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.71 X-Exim-ID: 1cQi43-00053j-Dp X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-71.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.71]:63358 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: [sipcore] The Canadian Regulator has issued a Notice of Consultation on robocalls spoofing STIR/SHAKEN X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 22:10:21 -0000 FYI=E2=80=A6=20 Here is the link to the CRTC NOC issued this morning. =20 http://www.crtc.gc.ca/eng/archive/2017/2017-4.htm =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 From nobody Mon Jan 9 15:21:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A311C129970 for ; Mon, 9 Jan 2017 15:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx-oDW9EoZd6 for ; Mon, 9 Jan 2017 15:20:57 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EDC312996F for ; Mon, 9 Jan 2017 15:20:57 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v09NKrKI099870 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 9 Jan 2017 17:20:53 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> To: Henning Schulzrinne From: Adam Roach Message-ID: Date: Mon, 9 Jan 2017 17:20:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------BA5C84394104D41D42160CB0" Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 23:20:58 -0000 This is a multi-part message in MIME format. --------------BA5C84394104D41D42160CB0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Quick comment on the draft based on my review of the changes: This version added the phrase "or CANCEL", resulting in the phrase: "UAS issues a BYE or CANCEL request terminating an incoming call." A funny story here... Back in the '90's, when I was involved in prototyping some mobile SIP clients, one of our prototype clients would actually display the reason phrase from any SIP error message it sent or received. Our call state machine had specific handling for every message type we could receive; and, when stepping through how we could *send* an INVITE and *receive* a CANCEL, we determined that it wasn't actually possible. So we added code to respond with a 481 and a distinctive reason code (to aid in debugging). But these were early days, and the implementation had some bugs to work out. Fast forward to our Pre-IMS system demo for our local executive team -- someone managed to take a sequence of actions that actually *did* coax the client that was receiving an incoming call into sending out a CANCEL. At which point both terminals displayed an error box reading "481 Called Party Apparently On Crack." They didn't appreciate the humor in the situation. Anyway, these many years later, I'm still pretty sure that a called party can't reject an incoming call by sending a CANCEL. And I'm more circumspect about how error conditions are communicated to users as well. /a --------------BA5C84394104D41D42160CB0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Quick comment on the draft based on my review of the changes:

This version added the phrase "or CANCEL", resulting in the phrase: "UAS issues a BYE or CANCEL request terminating an incoming call."

A funny story here... Back in the '90's, when I was involved in prototyping some mobile SIP clients, one of our prototype clients would actually display the reason phrase from any SIP error message it sent or received. Our call state machine had specific handling for every message type we could receive; and, when stepping through how we could *send* an INVITE and *receive* a CANCEL, we determined that it wasn't actually possible. So we added code to respond with a 481 and a distinctive reason code (to aid in debugging). But these were early days, and the implementation had some bugs to work out.

Fast forward to our Pre-IMS system demo for our local executive team -- someone managed to take a sequence of actions that actually *did* coax the client that was receiving an incoming call into sending out a CANCEL. At which point both terminals displayed an error box reading "481 Called Party Apparently On Crack."

They didn't appreciate the humor in the situation.

Anyway, these many years later, I'm still pretty sure that a called party can't reject an incoming call by sending a CANCEL. And I'm more circumspect about how error conditions are communicated to users as well.

/a
--------------BA5C84394104D41D42160CB0-- From nobody Tue Jan 10 06:13:43 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169C8129CBB for ; Tue, 10 Jan 2017 06:13:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYvQ2KfHOTZk for ; Tue, 10 Jan 2017 06:13:41 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E093129CB1 for ; Tue, 10 Jan 2017 06:13:41 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id i68so383453627uad.0 for ; Tue, 10 Jan 2017 06:13:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=vW1VjcqzysSf1xvUo/sjXMAL6Q745bxaWxuqvbPSxhQ=; b=eXDE8OOFqfCboR7fdGZ/bRleBS5qCcpF2ihigz939HYvYIcnDdgTdRYaA9qSNrQ0x1 /hlhnYN+tr4cz52Zb6NS0XgWvPbkfLZwlh/h7JDVN6mdGF4v55Ufp3cFppR3X4/JmWXW Ed/KIiPjqPgafWC+sy2cOQPf+2RD3iAtICH0CUdMzx4l7g9tyOrKZBYsP1Z1lRmtyQNF vPwzc8VfxF/o3naueIhsX5ddJ5Ixexw1IlhFVjbinqUleYmMLvY4nhxxWu5WYwoNjVqH nTVwCYGhss9r2pgVdAosSIJVHtf0Z1b0Dh5P9CxBWzJOj/tORjkMEAHt+km3bvCx19Rm ESvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vW1VjcqzysSf1xvUo/sjXMAL6Q745bxaWxuqvbPSxhQ=; b=TDL95NwsduQJKKIpgOLwHq60r+hvUdcQh5ssu1tWA51gs84Y3iYKbcSrMLclV7ruc4 i9aQENpSZDNU1w4srvPojWe6bwN3McpeplIQ2Vj6Ws2ZJLCIdyZ2mB4vFRBQpVgau7Sm ChghLAA+i92oxn7/OuQO5/m0IlO8z9iu8v3oX1WwgkSNqpzTOuG3hBDQhpjl013Abe6K A1fzLp6mczrO4YNJFpnCvKCQy0lO+vDia8cqUMbBzkn4BD99Xq75rgJ+LAcf3vx3ah7U 2uFvZIBPo+faiqwhQh1WDfGYqApbrQYPGICOu9CiW6udoxxqMhIzgzHyICKYxGJfSC1Y x1dQ== X-Gm-Message-State: AIkVDXKDOnjsPumDdjOFHr3ehvDQwLBCbxfFivcbWMCOiLCZtETMbrk9RsV4oL8nRGvQXbPLsulsEq0dGL21qg== X-Received: by 10.176.64.72 with SMTP id h66mr1648344uad.176.1484057619997; Tue, 10 Jan 2017 06:13:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Tue, 10 Jan 2017 06:13:39 -0800 (PST) From: Rifaat Shekh-Yusef Date: Tue, 10 Jan 2017 09:13:39 -0500 Message-ID: To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0485764428cb0545be1794 Archived-At: Subject: [sipcore] Third-Party Authentication for Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:13:43 -0000 --94eb2c0485764428cb0545be1794 Content-Type: text/plain; charset=UTF-8 Hi, Last year we had a long discussion on the mailing list about an AuthNZ mechanism for SIP. The AuthZ part seems to be controversial, while based on some offline discussion with Jon Peterson, the AuthN part seem *not* to be controversial. So, we decided to separate these discussions and first try to address the AuthN part, hence the following draft: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ The draft defines an authentication mechanism for SIP using OpenID Connect/OAuth 2.0 to enable the delegation of the user authentication to a dedicated third-party IdP entity that is separate from the SIP network elements that provide the SIP service. We would appreciate any review and feedback on the document. Regards, Rifaat --94eb2c0485764428cb0545be1794 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Last year we had a long = discussion on the mailing list about an AuthNZ mechanism for SIP.
The AuthZ part seems to be controversial, while based on some offline disc= ussion with Jon Peterson, the AuthN part seem not to be controversia= l.
So, we decided to separate these discussions and first try= to address the AuthN part, hence the following draft:

The draft defines an authentication mechanism f= or SIP using OpenID Connect/OAuth 2.0 to enable the delegation of the user = authentication to a=C2=A0
dedicated third-party IdP entity that i= s separate from the SIP network elements that provide the SIP service.

We would appreciate any review and feedback on the doc= ument.

Regards,
=C2=A0Rifaat
<= br>
--94eb2c0485764428cb0545be1794-- From nobody Tue Jan 10 08:14:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0471293E0 for ; Tue, 10 Jan 2017 08:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tOsqsrdr3cUm for ; Tue, 10 Jan 2017 08:14:42 -0800 (PST) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E60E3128AB0 for ; Tue, 10 Jan 2017 08:14:41 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-07v.sys.comcast.net with SMTP id Qz2kcmV3dj8tqQz4Lc65Nv; Tue, 10 Jan 2017 16:14:41 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-15v.sys.comcast.net with SMTP id Qz4JcCHCrwcMxQz4JcEnea; Tue, 10 Jan 2017 16:14:40 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0AGEcvE031820; Tue, 10 Jan 2017 11:14:38 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0AGEbnJ031813; Tue, 10 Jan 2017 11:14:37 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: <66ef794e-de09-da52-34ad-7abc8767ecd1@nostrum.com> (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 10 Jan 2017 11:14:37 -0500 Message-ID: <87k2a2j3iq.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEvawLQc43AhEt2WimRJVt45AqAETm8F+09m4ZcwtY7kEt5cetIU31t62oo/Ks0fTAsUlA5Sx98HkAwWTfeN4VGfyc86qpBE4rnfYkex3s7HU8QZqa6s mPV9s/JiquWhFgOjgwu2YZsSh2Fjpq8FPjhzGbO1M0RKTUYgxbxdHaVo2G0dLa6vPWTBwB35x0cfnA== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:14:45 -0000 Adam Roach writes: >> It sounds like the problem is that the mechanism proposed in that >> paragraph just won't work -- and that's more than an erratum, it needs a >> technical solution, if only to state that the recovery process (whatever >> it is) that the SDP description is supposed to enable won't happen. > > We've apparently made it over 14 years without this coming up at a SIPit > or as a problem on the sip-implementors list. I'm not certain there's a > need for some technical solution here -- I think a simple correction > that removes the CANCEL body would clear up the confusion that Marianne > identified. Heh -- "We don't need to solve that problem." is the simplest and most efficient solution to a problem. Though theoretically, deliberately reverting a feature isn't an erratum, an erratum sounds like the most effective way of *publishing* this change in practice. So let's call for consensus to amend 3312 to remove the specification of a body in CANCEL and, for the time being, to publish that amendment as an erratum... Dale From nobody Tue Jan 10 15:10:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651BB129611 for ; Tue, 10 Jan 2017 15:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YhX2NFH5av52 for ; Tue, 10 Jan 2017 15:10:25 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0626B12960D for ; Tue, 10 Jan 2017 15:10:24 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0AN9BSQ003423; Tue, 10 Jan 2017 23:10:24 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0021.outbound.protection.outlook.com [23.103.198.21]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tra29vkm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jan 2017 23:10:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WmU82ixcaJXCFk4mA8lcRv0kLXj+4Am5Q/MD58YsRsc=; b=kPzRc1Xcyf1CipmwGS8o+A6I9iaLONsQsNruB35Vejc3Gv2t00NPf7vlo7oj4wP6Tk9Mrp5FbJ/f0180ngwtgg4eY6Zz5uV7I2zXjnFD7doxd8IYTVVkd2B9o2+bccmW8DWZMklFJTts9l1gsC2CUth7QEg7n0hS/SkQU0cxKV4= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 10 Jan 2017 23:10:23 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 10 Jan 2017 23:10:23 +0000 From: Henning Schulzrinne To: Adam Roach Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZq3RayBYA4OJdkqIm+d2wXq+s6Ew0KiAgAGOjjA= Date: Tue, 10 Jan 2017 23:10:22 +0000 Message-ID: References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: db56aafb-9faa-4095-bc0a-08d439addae5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:HrlTNKalK16Un0MxaA62UjbYLARpABvXwxSht1wEjIcn3w+jCVs+z7stTNvldK32SO6R6bHZPSc33FqBhIklrGtdivv7PJ7gUBrBCZWFnas7THgFUawaX0bGqHTyryb4Vg5qBnQWm5Tl+/1nsD3amm51IR+zWsh7sHCOq5F2BKERBIdKK8qxn19eCp9YvJDCFg2yfgtEjWoRx+qRfXJSTwP+8t0cqSMFjv/5FpODI/q+1LuGEifJPbpVOmlUUbitJlxxHt9Wf1MqFxwuU7N6fPsKXitUbFadOYykMm22DRGbZc8UGIt3m1nDxcPXHQcuc4OGFkJH5TzKKaEV1MCzjHPYTsR9ZQUslaIjLnLPmsahf6uvPsWgl3seEsW9D0f+JGEKn/1VMVW87PIGVIveXMeThImrZ8jAFtS20fIXjO/XmGhzyv44IpCGeJ0uTM/QRTz2qcLRdqj1NX7JBWUkGw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(377454003)(52314003)(199003)(76176999)(5660300001)(54356999)(6916009)(74316002)(6436002)(122556002)(2900100001)(102836003)(110136003)(230783001)(50986999)(97736004)(7696004)(189998001)(25786008)(6506006)(54896002)(3280700002)(99286003)(6306002)(9686003)(86362001)(55016002)(4326007)(33656002)(106116001)(101416001)(2906002)(92566002)(38730400001)(77096006)(106356001)(7736002)(66066001)(81156014)(3660700001)(81166006)(8676002)(2950100002)(68736007)(6116002)(229853002)(8936002)(105586002)(790700001)(3846002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06349B8DCD1B31FAB4D2C31AEA670CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 23:10:23.0071 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-10_19:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:10:29 -0000 --_000_CY1PR09MB06349B8DCD1B31FAB4D2C31AEA670CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hhdCBJIHdhcyB0aGlua2luZyBvZiAoYnV0IGRpZG7igJl0IHdyaXRlKSBpcyB3aGV0aGVyIGl0 IG1ha2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBSZWFzb24gaW4gdGhlIENBTkNFTCB3aXRoIGEgNjY2 LCBpc3N1ZWQgYnkgdGhlIFVBQy4gQmFzaWNhbGx5LCB0aGUgY2FsbCBmb3Jrcywgb25lIG9mIHRo ZSBwaG9uZXMgcmluZ2luZyBnZXRzIHBpY2tlZCB1cCwgdGhlIHJlY2lwaWVudCBwcmVzc2VzIHRo ZSBiaWcgcmVkIHNwYW0gYnV0dG9uIGFuZCB0aGUgb3RoZXIgcGhvbmVzIHN0b3AgcmluZ2luZyB3 aXRoIHRoZSBpbmRpY2F0aW9uIHRoYXQgc29tZWJvZHkganVzdCBkZWVwLXNpeGVkIHRoZSBjYWxs Lg0KDQpJcyB0aGF0IHVzZWZ1bD8NCg0KRnJvbTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9z dHJ1bS5jb21dDQpTZW50OiBNb25kYXksIEphbnVhcnkgMDksIDIwMTcgNjoyMSBQTQ0KVG86IEhl bm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj4NCkNjOiBzaXBj b3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIEktRCBBY3Rpb246IGRyYWZ0LWll dGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDEudHh0DQoNClF1aWNrIGNvbW1lbnQgb24gdGhl IGRyYWZ0IGJhc2VkIG9uIG15IHJldmlldyBvZiB0aGUgY2hhbmdlczoNCg0KVGhpcyB2ZXJzaW9u IGFkZGVkIHRoZSBwaHJhc2UgIm9yIENBTkNFTCIsIHJlc3VsdGluZyBpbiB0aGUgcGhyYXNlOiAi VUFTIGlzc3VlcyBhIEJZRSBvciBDQU5DRUwgcmVxdWVzdCB0ZXJtaW5hdGluZyBhbiBpbmNvbWlu ZyBjYWxsLiINCg0KQSBmdW5ueSBzdG9yeSBoZXJlLi4uIEJhY2sgaW4gdGhlICc5MCdzLCB3aGVu IEkgd2FzIGludm9sdmVkIGluIHByb3RvdHlwaW5nIHNvbWUgbW9iaWxlIFNJUCBjbGllbnRzLCBv bmUgb2Ygb3VyIHByb3RvdHlwZSBjbGllbnRzIHdvdWxkIGFjdHVhbGx5IGRpc3BsYXkgdGhlIHJl YXNvbiBwaHJhc2UgZnJvbSBhbnkgU0lQIGVycm9yIG1lc3NhZ2UgaXQgc2VudCBvciByZWNlaXZl ZC4gT3VyIGNhbGwgc3RhdGUgbWFjaGluZSBoYWQgc3BlY2lmaWMgaGFuZGxpbmcgZm9yIGV2ZXJ5 IG1lc3NhZ2UgdHlwZSB3ZSBjb3VsZCByZWNlaXZlOyBhbmQsIHdoZW4gc3RlcHBpbmcgdGhyb3Vn aCBob3cgd2UgY291bGQgKnNlbmQqIGFuIElOVklURSBhbmQgKnJlY2VpdmUqIGEgQ0FOQ0VMLCB3 ZSBkZXRlcm1pbmVkIHRoYXQgaXQgd2Fzbid0IGFjdHVhbGx5IHBvc3NpYmxlLiBTbyB3ZSBhZGRl ZCBjb2RlIHRvIHJlc3BvbmQgd2l0aCBhIDQ4MSBhbmQgYSBkaXN0aW5jdGl2ZSByZWFzb24gY29k ZSAodG8gYWlkIGluIGRlYnVnZ2luZykuIEJ1dCB0aGVzZSB3ZXJlIGVhcmx5IGRheXMsIGFuZCB0 aGUgaW1wbGVtZW50YXRpb24gaGFkIHNvbWUgYnVncyB0byB3b3JrIG91dC4NCg0KRmFzdCBmb3J3 YXJkIHRvIG91ciBQcmUtSU1TIHN5c3RlbSBkZW1vIGZvciBvdXIgbG9jYWwgZXhlY3V0aXZlIHRl YW0gLS0gc29tZW9uZSBtYW5hZ2VkIHRvIHRha2UgYSBzZXF1ZW5jZSBvZiBhY3Rpb25zIHRoYXQg YWN0dWFsbHkgKmRpZCogY29heCB0aGUgY2xpZW50IHRoYXQgd2FzIHJlY2VpdmluZyBhbiBpbmNv bWluZyBjYWxsIGludG8gc2VuZGluZyBvdXQgYSBDQU5DRUwuIEF0IHdoaWNoIHBvaW50IGJvdGgg dGVybWluYWxzIGRpc3BsYXllZCBhbiBlcnJvciBib3ggcmVhZGluZyAiNDgxIENhbGxlZCBQYXJ0 eSBBcHBhcmVudGx5IE9uIENyYWNrLiINCg0KVGhleSBkaWRuJ3QgYXBwcmVjaWF0ZSB0aGUgaHVt b3IgaW4gdGhlIHNpdHVhdGlvbi4NCg0KQW55d2F5LCB0aGVzZSBtYW55IHllYXJzIGxhdGVyLCBJ J20gc3RpbGwgcHJldHR5IHN1cmUgdGhhdCBhIGNhbGxlZCBwYXJ0eSBjYW4ndCByZWplY3QgYW4g aW5jb21pbmcgY2FsbCBieSBzZW5kaW5nIGEgQ0FOQ0VMLiBBbmQgSSdtIG1vcmUgY2lyY3Vtc3Bl Y3QgYWJvdXQgaG93IGVycm9yIGNvbmRpdGlvbnMgYXJlIGNvbW11bmljYXRlZCB0byB1c2VycyBh cyB3ZWxsLg0KDQovYQ0K --_000_CY1PR09MB06349B8DCD1B31FAB4D2C31AEA670CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjsN Cgljb2xvcjpibGFjazt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu Lmluc2VydA0KCXttc28tc3R5bGUtbmFtZTppbnNlcnQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5XaGF0IEkgd2FzIHRoaW5raW5nIG9mIChidXQg ZGlkbuKAmXQgd3JpdGUpIGlzIHdoZXRoZXIgaXQgbWFrZXMgc2Vuc2UgdG8gaW5jbHVkZSBhIFJl YXNvbiBpbiB0aGUgQ0FOQ0VMIHdpdGggYSA2NjYsIGlzc3VlZCBieSB0aGUgVUFDLiBCYXNpY2Fs bHksIHRoZSBjYWxsIGZvcmtzLA0KIG9uZSBvZiB0aGUgcGhvbmVzIHJpbmdpbmcgZ2V0cyBwaWNr ZWQgdXAsIHRoZSByZWNpcGllbnQgcHJlc3NlcyB0aGUgYmlnIHJlZCBzcGFtIGJ1dHRvbiBhbmQg dGhlIG90aGVyIHBob25lcyBzdG9wIHJpbmdpbmcgd2l0aCB0aGUgaW5kaWNhdGlvbiB0aGF0IHNv bWVib2R5IGp1c3QgZGVlcC1zaXhlZCB0aGUgY2FsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPklzIHRoYXQgdXNlZnVsPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6d2luZG93dGV4dCI+IEFk YW0gUm9hY2ggW21haWx0bzphZGFtQG5vc3RydW0uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1v bmRheSwgSmFudWFyeSAwOSwgMjAxNyA2OjIxIFBNPGJyPg0KPGI+VG86PC9iPiBIZW5uaW5nIFNj aHVsenJpbm5lICZsdDtIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3YmZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0g SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMS50eHQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5RdWljayBjb21tZW50 IG9uIHRoZSBkcmFmdCBiYXNlZCBvbiBteSByZXZpZXcgb2YgdGhlIGNoYW5nZXM6PGJyPg0KPGJy Pg0KVGhpcyB2ZXJzaW9uIGFkZGVkIHRoZSBwaHJhc2UgJnF1b3Q7b3IgQ0FOQ0VMJnF1b3Q7LCBy ZXN1bHRpbmcgaW4gdGhlIHBocmFzZTogJnF1b3Q7VUFTIGlzc3VlcyBhIEJZRQ0KPHNwYW4gY2xh c3M9Imluc2VydCI+b3IgQ0FOQ0VMPC9zcGFuPiByZXF1ZXN0IHRlcm1pbmF0aW5nIGFuIGluY29t aW5nIGNhbGwuJnF1b3Q7PGJyPg0KPGJyPg0KQSBmdW5ueSBzdG9yeSBoZXJlLi4uIEJhY2sgaW4g dGhlICc5MCdzLCB3aGVuIEkgd2FzIGludm9sdmVkIGluIHByb3RvdHlwaW5nIHNvbWUgbW9iaWxl IFNJUCBjbGllbnRzLCBvbmUgb2Ygb3VyIHByb3RvdHlwZSBjbGllbnRzIHdvdWxkIGFjdHVhbGx5 IGRpc3BsYXkgdGhlIHJlYXNvbiBwaHJhc2UgZnJvbSBhbnkgU0lQIGVycm9yIG1lc3NhZ2UgaXQg c2VudCBvciByZWNlaXZlZC4gT3VyIGNhbGwgc3RhdGUgbWFjaGluZSBoYWQgc3BlY2lmaWMgaGFu ZGxpbmcNCiBmb3IgZXZlcnkgbWVzc2FnZSB0eXBlIHdlIGNvdWxkIHJlY2VpdmU7IGFuZCwgd2hl biBzdGVwcGluZyB0aHJvdWdoIGhvdyB3ZSBjb3VsZCAqc2VuZCogYW4gSU5WSVRFIGFuZCAqcmVj ZWl2ZSogYSBDQU5DRUwsIHdlIGRldGVybWluZWQgdGhhdCBpdCB3YXNuJ3QgYWN0dWFsbHkgcG9z c2libGUuIFNvIHdlIGFkZGVkIGNvZGUgdG8gcmVzcG9uZCB3aXRoIGEgNDgxIGFuZCBhIGRpc3Rp bmN0aXZlIHJlYXNvbiBjb2RlICh0byBhaWQgaW4gZGVidWdnaW5nKS4NCiBCdXQgdGhlc2Ugd2Vy ZSBlYXJseSBkYXlzLCBhbmQgdGhlIGltcGxlbWVudGF0aW9uIGhhZCBzb21lIGJ1Z3MgdG8gd29y ayBvdXQuPGJyPg0KPGJyPg0KRmFzdCBmb3J3YXJkIHRvIG91ciBQcmUtSU1TIHN5c3RlbSBkZW1v IGZvciBvdXIgbG9jYWwgZXhlY3V0aXZlIHRlYW0gLS0gc29tZW9uZSBtYW5hZ2VkIHRvIHRha2Ug YSBzZXF1ZW5jZSBvZiBhY3Rpb25zIHRoYXQgYWN0dWFsbHkgKmRpZCogY29heCB0aGUgY2xpZW50 IHRoYXQgd2FzIHJlY2VpdmluZyBhbiBpbmNvbWluZyBjYWxsIGludG8gc2VuZGluZyBvdXQgYSBD QU5DRUwuIEF0IHdoaWNoIHBvaW50IGJvdGggdGVybWluYWxzIGRpc3BsYXllZA0KIGFuIGVycm9y IGJveCByZWFkaW5nICZxdW90OzQ4MSBDYWxsZWQgUGFydHkgQXBwYXJlbnRseSBPbiBDcmFjay4m cXVvdDs8YnI+DQo8YnI+DQpUaGV5IGRpZG4ndCBhcHByZWNpYXRlIHRoZSBodW1vciBpbiB0aGUg c2l0dWF0aW9uLjxicj4NCjxicj4NCkFueXdheSwgdGhlc2UgbWFueSB5ZWFycyBsYXRlciwgSSdt IHN0aWxsIHByZXR0eSBzdXJlIHRoYXQgYSBjYWxsZWQgcGFydHkgY2FuJ3QgcmVqZWN0IGFuIGlu Y29taW5nIGNhbGwgYnkgc2VuZGluZyBhIENBTkNFTC4gQW5kIEknbSBtb3JlIGNpcmN1bXNwZWN0 IGFib3V0IGhvdyBlcnJvciBjb25kaXRpb25zIGFyZSBjb21tdW5pY2F0ZWQgdG8gdXNlcnMgYXMg d2VsbC48YnI+DQo8YnI+DQovYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_CY1PR09MB06349B8DCD1B31FAB4D2C31AEA670CY1PR09MB0634namp_-- From nobody Tue Jan 10 15:36:25 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55EE6129404 for ; Tue, 10 Jan 2017 15:36:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5ecfeBtUHuW for ; Tue, 10 Jan 2017 15:36:22 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0098E126D74 for ; Tue, 10 Jan 2017 15:36:21 -0800 (PST) Received: from pps.filterd (m0102173.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0ANZ9Yu008582; Tue, 10 Jan 2017 23:36:17 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0051.outbound.protection.outlook.com [23.103.198.51]) by mx0a-0024ed01.pphosted.com with ESMTP id 27ts4st98c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 10 Jan 2017 23:36:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PLTSmDwk50CeEGEFRiDtXAySIGGjbGJ0bl0EQ12DDg0=; b=X10EPrwa/iii+aNjMUm0G/N01bexVQk3xisRbIrhb7PwTl8L7ZZw/odkoo0hGuqNQBSnUT3pJC8GAPTKgmuAvyu48v9jr2RHyaivvyanFxTOCl7dLiM0jU3hy7C/ba74mtz8CBSMTeVrHyk6nuHUAukIMPvHY8Mj2FL8yO236ok= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.803.11; Tue, 10 Jan 2017 23:36:10 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0803.021; Tue, 10 Jan 2017 23:36:11 +0000 From: Henning Schulzrinne To: "Dale R. Worley" Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? Thread-Index: AQHSaC4uuX5AkvMHfEmS+B9NF8+2CqEyYBlQ Date: Tue, 10 Jan 2017 23:36:11 +0000 Message-ID: References: (Henning.Schulzrinne@fcc.gov) <877f68dybk.fsf@hobgoblin.ariadne.com> In-Reply-To: <877f68dybk.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 4250196b-0b79-4609-4a3c-08d439b175a4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:y7J+2NHZHbpPVfH7rt6KSOxlXJzgmI9ySFFOf3XF842Gk+io3KQa9V6faNmEqqeB5r4Vra5sK6xeD8RF3LGSA1Ke7635p6Q4bKN0vY+FI3nMd4QBgCWcKc8R6iO0g6/qKPCxsu8449Q02JirJda5ij9gdWBSzMxVzjEJps/dEIWW18Ye++H5WxXZ+h7Q8pZETsRnn2EgQdNRT9Scoev1ipUMH3ol6urhePr61E9RTCGUkkV6krlnbUFLOclecn1YgMAWdRoUps+ycZl/vIiPCbtkRTLPTOexcjRZhk5Zs/NlqIc8uTIePIEWOGgsWYcQfk0hNErcRNfzed2QlQRwfshcavwg9gjucTrFfiCOd9fEnhplW1JOiCTx2vSIivMb84IjJCPZ/HEcsjoSnyoGFiKq69WxZX8qFD3Vjtn18VlLI0/DKevIlI026YEmg2sQpfYrfObjgPxQtE10oUkwvQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(189002)(13464003)(377454003)(57704003)(6506006)(4326007)(229853002)(25786008)(6436002)(33656002)(86362001)(55016002)(99286003)(2906002)(9686003)(3280700002)(305945005)(6116002)(77096006)(97736004)(3660700001)(7736002)(3846002)(105586002)(5660300001)(68736007)(102836003)(8676002)(106356001)(2900100001)(81166006)(8936002)(76176999)(92566002)(122556002)(54356999)(101416001)(189998001)(110136003)(106116001)(561944003)(66066001)(81156014)(38730400001)(230783001)(6916009)(2950100002)(7696004)(74316002)(50986999)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 23:36:11.0372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-10_19:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need another response code? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:36:23 -0000 I think we have rough consensus that, for now, the 666 code is meant for th= e "don't want this call" user behavior. Longer term, I suspect we can revisit how to indicate that a network call f= ilter made the decision, recognizing that the boundaries are a bit fluid as= device capabilities and AI mature. Imagine an advanced machine learning bo= t trained on my personal preferences that I trust to make call decisions fo= r me (reject, voicemail, have a robot-to-robocaller conversation to see whe= ther the robocaller can tell, tell the caller that I'm driving). Is that a = human decision (I trained the bot!) or robot? I don't think we need to settle now whether this is 666 + Warning, some new= 6xx code or an existing 6xx (or even 4xx) + Warning. I think this is one aspect where email spam and VoIP robocall rejection dif= fer: Because of the asynchronous nature of email, a human user can't really= refuse and return the email once it's been delivered, so you can only indi= cate "spam!" for future filtering. Because of the real-time nature of calls= , the two aspects (hinting to the call filter and indication to the caller)= naturally blend a bit more than they would in email. In any event, unless somebody has a concrete proposal (preferably one that = doesn't double the draft size...), I think this is "beyond the scope of thi= s draft". Henning -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com]=20 Sent: Friday, January 06, 2017 10:05 AM To: Henning Schulzrinne Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted -- do we need ano= ther response code? Henning Schulzrinne writes: > Are you talking about the case where the end system itself does the=20 > blocking, e.g., via an app (e.g., Hiya or Nomorobo)? > > Leaving aside Martin's concerns for a moment, I admit that I'm not=20 > convinced that this distinction is meaningful. For example, an app or=20 > dialer may have a personal blacklist (I believe Android does). This is=20 > something done by the user, not AI (so Martin may like it...), but the=20 > dialer would be responding with a 666 on the next call to signal the=20 > reason for the rejection. Is that a robot instead? What if the app=20 > just suggests that this is a "bad" call and the user hits the spam=20 > button? I admit that I have a hard time drawing a firm line that would=20 > provide sufficient guidance to implementors to choose one status code=20 > or the other. I'm using a model that resembles how I think spam filtering works: the use= r's SIP service monitors the calls for which the user triggers 666. Based on this, it constructs a filter for which calls will be presented to = the user. The calls that are rejected aren't rejected specifically because= the user has specified that they are to be rejected, but based on the filt= er. So there will be occasional mistakes. It seems like it would be usefu= l to notify the caller that the call was rejected based on such a filter. > This seems like something we could discuss once we have a bit more=20 > operational experience. Maybe a "Warning" code would be the more=20 > appropriate means of conveying such additional information, for=20 > example. Hmmm, looking at the drarft again, the specifics of blocking, or even wheth= er blocking is done, are out of scope. But I like your proposal of a Warni= ng code. And we might need more than one Warning code, if this situation t= urns out to be more complicated. Dale From nobody Tue Jan 10 15:59:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 574D61293F9 for ; Tue, 10 Jan 2017 15:59:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.088 X-Spam-Level: X-Spam-Status: No, score=-5.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiuulaRnS3IY for ; Tue, 10 Jan 2017 15:59:13 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0A731293F4 for ; Tue, 10 Jan 2017 15:59:13 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0ANxAoh030398 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jan 2017 17:59:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Henning Schulzrinne References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <0a0cb12b-1a48-df12-924a-2701f01020f7@nostrum.com> Date: Tue, 10 Jan 2017 17:59:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------26CED11176B8A828263672AB" Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:59:15 -0000 This is a multi-part message in MIME format. --------------26CED11176B8A828263672AB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Ah, that does seem to make more sense. If you want to mention this case in the document, it seems congruent with the example given in section 3.1 of RFC3326. You'd need to describe the use case more clearly in the document, but I see no problems with adding that. If you do so, it's worth noting at the same time that the use of Reason in CANCEL is somewhat fragile due to the fact that RFC3261 places no requirement on proxies to copy it forward. Section 2 of RFC3326 does call this out at SHOULD strength, but this only reads on proxies that go out of their way to implement that RFC (which seems a little unlikely). /a On 1/10/17 17:10, Henning Schulzrinne wrote: > > What I was thinking of (but didn’t write) is whether it makes sense to > include a Reason in the CANCEL with a 666, issued by the UAC. > Basically, the call forks, one of the phones ringing gets picked up, > the recipient presses the big red spam button and the other phones > stop ringing with the indication that somebody just deep-sixed the call. > > Is that useful? > > *From:*Adam Roach [mailto:adam@nostrum.com] > *Sent:* Monday, January 09, 2017 6:21 PM > *To:* Henning Schulzrinne > *Cc:* sipcore@ietf.org > *Subject:* Re: [sipcore] I-D Action: > draft-ietf-sipcore-status-unwanted-01.txt > > Quick comment on the draft based on my review of the changes: > > This version added the phrase "or CANCEL", resulting in the phrase: > "UAS issues a BYE or CANCEL request terminating an incoming call." > > A funny story here... Back in the '90's, when I was involved in > prototyping some mobile SIP clients, one of our prototype clients > would actually display the reason phrase from any SIP error message it > sent or received. Our call state machine had specific handling for > every message type we could receive; and, when stepping through how we > could *send* an INVITE and *receive* a CANCEL, we determined that it > wasn't actually possible. So we added code to respond with a 481 and a > distinctive reason code (to aid in debugging). But these were early > days, and the implementation had some bugs to work out. > > Fast forward to our Pre-IMS system demo for our local executive team > -- someone managed to take a sequence of actions that actually *did* > coax the client that was receiving an incoming call into sending out a > CANCEL. At which point both terminals displayed an error box reading > "481 Called Party Apparently On Crack." > > They didn't appreciate the humor in the situation. > > Anyway, these many years later, I'm still pretty sure that a called > party can't reject an incoming call by sending a CANCEL. And I'm more > circumspect about how error conditions are communicated to users as well. > > /a > --------------26CED11176B8A828263672AB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Ah, that does seem to make more sense. If you want to mention this case in the document, it seems congruent with the example given in section 3.1 of RFC3326. You'd need to describe the use case more clearly in the document, but I see no problems with adding that.

If you do so, it's worth noting at the same time that the use of Reason in CANCEL is somewhat fragile due to the fact that RFC3261 places no requirement on proxies to copy it forward. Section 2 of RFC3326 does call this out at SHOULD strength, but this only reads on proxies that go out of their way to implement that RFC (which seems a little unlikely).

/a

On 1/10/17 17:10, Henning Schulzrinne wrote:

What I was thinking of (but didn’t write) is whether it makes sense to include a Reason in the CANCEL with a 666, issued by the UAC. Basically, the call forks, one of the phones ringing gets picked up, the recipient presses the big red spam button and the other phones stop ringing with the indication that somebody just deep-sixed the call.

 

Is that useful?

 

From: Adam Roach [mailto:adam@nostrum.com]
Sent: Monday, January 09, 2017 6:21 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt

 

Quick comment on the draft based on my review of the changes:

This version added the phrase "or CANCEL", resulting in the phrase: "UAS issues a BYE or CANCEL request terminating an incoming call."

A funny story here... Back in the '90's, when I was involved in prototyping some mobile SIP clients, one of our prototype clients would actually display the reason phrase from any SIP error message it sent or received. Our call state machine had specific handling for every message type we could receive; and, when stepping through how we could *send* an INVITE and *receive* a CANCEL, we determined that it wasn't actually possible. So we added code to respond with a 481 and a distinctive reason code (to aid in debugging). But these were early days, and the implementation had some bugs to work out.

Fast forward to our Pre-IMS system demo for our local executive team -- someone managed to take a sequence of actions that actually *did* coax the client that was receiving an incoming call into sending out a CANCEL. At which point both terminals displayed an error box reading "481 Called Party Apparently On Crack."

They didn't appreciate the humor in the situation.

Anyway, these many years later, I'm still pretty sure that a called party can't reject an incoming call by sending a CANCEL. And I'm more circumspect about how error conditions are communicated to users as well.

/a


--------------26CED11176B8A828263672AB-- From nobody Tue Jan 10 19:19:56 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFDF129446 for ; Tue, 10 Jan 2017 19:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.057 X-Spam-Level: X-Spam-Status: No, score=-8.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUzdDc2GbZX2 for ; Tue, 10 Jan 2017 19:19:52 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59E32127076 for ; Tue, 10 Jan 2017 19:19:52 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 2F0C9A35388FA; Wed, 11 Jan 2017 03:19:49 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0B3JnpY029987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 11 Jan 2017 03:19:49 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0B3Jct8031778 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 11 Jan 2017 03:19:46 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Wed, 11 Jan 2017 04:19:37 +0100 From: "Drage, Keith (Nokia - GB)" To: "Dale R. Worley" , "marianne.mohali@orange.com" Thread-Topic: [sipcore] Errata to RFC3261 Thread-Index: AQHSaFNQPEYWqgjEB063rhhH0mngLaEr8Tmg Date: Wed, 11 Jan 2017 03:19:36 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFD3060@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <19964_1483635715_586E7C03_19964_3476_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A34AE@OPEXCLILMA4.corporate.adroot.infra.ftgroup> (marianne.mohali@orange.com) <87fukwc7g4.fsf@hobgoblin.ariadne.com> In-Reply-To: <87fukwc7g4.fsf@hobgoblin.ariadne.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "paul.kyzivat@comcast.net" , "sipcore@ietf.org" Subject: Re: [sipcore] Errata to RFC3261 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 03:19:54 -0000 I do not believe the decision to deprecate the tables ever made its way int= o any formal documentation. As far as I remember the agreement only went as far as what to do for new h= eader fields and methods, and did not change existing material, which would= have had to wait for a revision of the original documents. Formally, RFC 3312 can only change normative requirements in RFC 3261 if it= updates it. Keith PS: The whole discussion above is irrelevant if we follow Adam's subsequent= mail. -----Original Message----- From: Dale R. Worley [mailto:worley@ariadne.com]=20 Sent: 06 January 2017 19:30 To: marianne.mohali@orange.com Cc: Drage, Keith (Nokia - GB) ; paul.kyzivat@comcast= .net; sipcore@ietf.org Subject: Re: [sipcore] Errata to RFC3261 writes: > I don't want to re-open the discussion on the Tables (I also heard=20 > that they are now deprecated). I agreed that RFC3261 comes first so=20 > it should have been stated in RFC3312 that RFC3312 also update the > 3261 table. > > I would propose to have an errata to RFC3312 adding this clarification. > Any other view? Relative to Jean Mahoney's message, the decision is to deprecate Table 2 in= RFC 3261, and defer to text descriptions. As I understand it, the text de= scription of the use of bodies in CANCEL given in RFC 3312 is clear, and cl= early supersedes the discussion in RFC 3261, so there is no need for an err= atum. Dale From nobody Tue Jan 10 21:10:08 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E61129722 for ; Tue, 10 Jan 2017 21:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pX1OTNY5PgOb for ; Tue, 10 Jan 2017 21:10:05 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E141294BA for ; Tue, 10 Jan 2017 21:10:05 -0800 (PST) Received: from resomta-po-01v.sys.comcast.net ([96.114.154.225]) by resqmta-po-04v.sys.comcast.net with SMTP id RBAJcqw1PrdcjRBAhcs7qq; Wed, 11 Jan 2017 05:10:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484111403; bh=1jMCmI2cMqBiVF+UYaA1oZGizub0Wc7BCLdN5lwN3p4=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=CJs34YEs9SNWLtqx0gF9w7S2l2Amn9RxNnDAPfGrLscubBcYCc/dZxKr8keT4I9mi 3+50Fkvj5bHqVBinBEsz7gjgA1i4+eJN+yoeLlydKupKq6t7BpaAFz+CyKbbosmKoN mZEYwz0hEt+Z22PdDygg1iNz2ajPdCOSDPq+8SavG7uoScwadiSqkfqtudNxbscswP nqs9otyp4XcOasK1qAncHo6pRpIAluNDcdTOmBAzRj2rxnjlanX24NKOBaDIY9QBwG KNBjFwyuKp/RfLEF3HiebYXynDJe9amri+PZVbqwlOoE6f4Zg4OPo73Y4cKgYuQzeP 3sfY7LNVAJYBQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-01v.sys.comcast.net with SMTP id RBAhcFnUXGwwqRBAhc2e96; Wed, 11 Jan 2017 05:10:03 +0000 To: sipcore@ietf.org References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <0a0cb12b-1a48-df12-924a-2701f01020f7@nostrum.com> From: Paul Kyzivat Message-ID: Date: Wed, 11 Jan 2017 00:10:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <0a0cb12b-1a48-df12-924a-2701f01020f7@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 05:10:07 -0000 On 1/10/17 6:59 PM, Adam Roach wrote: > Ah, that does seem to make more sense. If you want to mention this case > in the document, it seems congruent with the example given in section > 3.1 of RFC3326. You'd need to describe the use case more clearly in the > document, but I see no problems with adding that. > > If you do so, it's worth noting at the same time that the use of Reason > in CANCEL is somewhat fragile due to the fact that RFC3261 places no > requirement on proxies to copy it forward. Section 2 of RFC3326 does > call this out at SHOULD strength, but this only reads on proxies that go > out of their way to implement that RFC (which seems a little unlikely). While the fragility is a problem, it still seems like a good idea. We could *consider* whether it makes sense to update 3261 to recommend supporting this. (But it would take a long time to work its way through the ecosystem.) Note that this isn't only relevant for 666 - it would be relevant for other reason codes as well. Thanks, Paul > /a > > On 1/10/17 17:10, Henning Schulzrinne wrote: >> >> What I was thinking of (but didn’t write) is whether it makes sense to >> include a Reason in the CANCEL with a 666, issued by the UAC. >> Basically, the call forks, one of the phones ringing gets picked up, >> the recipient presses the big red spam button and the other phones >> stop ringing with the indication that somebody just deep-sixed the call. >> >> >> >> Is that useful? >> >> >> >> *From:*Adam Roach [mailto:adam@nostrum.com] >> *Sent:* Monday, January 09, 2017 6:21 PM >> *To:* Henning Schulzrinne >> *Cc:* sipcore@ietf.org >> *Subject:* Re: [sipcore] I-D Action: >> draft-ietf-sipcore-status-unwanted-01.txt >> >> >> >> Quick comment on the draft based on my review of the changes: >> >> This version added the phrase "or CANCEL", resulting in the phrase: >> "UAS issues a BYE or CANCEL request terminating an incoming call." >> >> A funny story here... Back in the '90's, when I was involved in >> prototyping some mobile SIP clients, one of our prototype clients >> would actually display the reason phrase from any SIP error message it >> sent or received. Our call state machine had specific handling for >> every message type we could receive; and, when stepping through how we >> could *send* an INVITE and *receive* a CANCEL, we determined that it >> wasn't actually possible. So we added code to respond with a 481 and a >> distinctive reason code (to aid in debugging). But these were early >> days, and the implementation had some bugs to work out. >> >> Fast forward to our Pre-IMS system demo for our local executive team >> -- someone managed to take a sequence of actions that actually *did* >> coax the client that was receiving an incoming call into sending out a >> CANCEL. At which point both terminals displayed an error box reading >> "481 Called Party Apparently On Crack." >> >> They didn't appreciate the humor in the situation. >> >> Anyway, these many years later, I'm still pretty sure that a called >> party can't reject an incoming call by sending a CANCEL. And I'm more >> circumspect about how error conditions are communicated to users as well. >> >> /a >> > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Wed Jan 11 00:11:59 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047D2129A87 for ; Wed, 11 Jan 2017 00:11:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FL8KcdIsG2k4 for ; Wed, 11 Jan 2017 00:11:55 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03C37129A7F for ; Wed, 11 Jan 2017 00:11:54 -0800 (PST) Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id E8C3C3CFA; Wed, 11 Jan 2017 09:11:34 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_3285767E-B39A-4B36-8FBA-0685B1383D77" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 11 Jan 2017 09:11:34 +0100 Message-Id: <396E65B1-602F-4486-892D-C233B0DAB55A@edvina.net> References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> To: Henning Schulzrinne X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:11:58 -0000 --Apple-Mail=_3285767E-B39A-4B36-8FBA-0685B1383D77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jan 2017, at 00:10, Henning Schulzrinne = wrote: >=20 > What I was thinking of (but didn=E2=80=99t write) is whether it makes = sense to include a Reason in the CANCEL with a 666, issued by the UAC. = Basically, the call forks, one of the phones ringing gets picked up, the = recipient presses the big red spam button and the other phones stop = ringing with the indication that somebody just deep-sixed the call. > =20 > Is that useful? > =20 Yes, because the other phones can delete the call - or not add it - from = the =E2=80=9Cmissed calls=E2=80=9D list. You don=E2=80=99t want to call = back to that number. /O > From: Adam Roach [mailto:adam@nostrum.com ]=20= > Sent: Monday, January 09, 2017 6:21 PM > To: Henning Schulzrinne > > Cc: sipcore@ietf.org > Subject: Re: [sipcore] I-D Action: = draft-ietf-sipcore-status-unwanted-01.txt > =20 > Quick comment on the draft based on my review of the changes: >=20 > This version added the phrase "or CANCEL", resulting in the phrase: = "UAS issues a BYE or CANCEL request terminating an incoming call." >=20 > A funny story here... Back in the '90's, when I was involved in = prototyping some mobile SIP clients, one of our prototype clients would = actually display the reason phrase from any SIP error message it sent or = received. Our call state machine had specific handling for every message = type we could receive; and, when stepping through how we could *send* an = INVITE and *receive* a CANCEL, we determined that it wasn't actually = possible. So we added code to respond with a 481 and a distinctive = reason code (to aid in debugging). But these were early days, and the = implementation had some bugs to work out. >=20 > Fast forward to our Pre-IMS system demo for our local executive team = -- someone managed to take a sequence of actions that actually *did* = coax the client that was receiving an incoming call into sending out a = CANCEL. At which point both terminals displayed an error box reading = "481 Called Party Apparently On Crack." >=20 > They didn't appreciate the humor in the situation. >=20 > Anyway, these many years later, I'm still pretty sure that a called = party can't reject an incoming call by sending a CANCEL. And I'm more = circumspect about how error conditions are communicated to users as = well. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_3285767E-B39A-4B36-8FBA-0685B1383D77 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 11 Jan 2017, at 00:10, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

What I was thinking of = (but didn=E2=80=99t write) is whether it makes sense to include a Reason = in the CANCEL with a 666, issued by the UAC. Basically, the call forks, = one of the phones ringing gets picked up, the recipient presses the big = red spam button and the other phones stop ringing with the indication = that somebody just deep-sixed the call.
 
Is that useful?
 
Yes, = because the other phones can delete the call - or not add it - from the = =E2=80=9Cmissed calls=E2=80=9D list. You don=E2=80=99t want to call back = to that number.

/O

From: Adam Roach [mailto:adam@nostrum.com] 
Sent: Monday, January 09, 2017 = 6:21 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: = draft-ietf-sipcore-status-unwanted-01.txt
 
Quick comment on the draft based on my review of the = changes:

This version added the phrase "or = CANCEL", resulting in the phrase: "UAS issues a BYE or = CANCEL request = terminating an incoming call."

A funny = story here... Back in the '90's, when I was involved in prototyping some = mobile SIP clients, one of our prototype clients would actually display = the reason phrase from any SIP error message it sent or received. Our = call state machine had specific handling for every message type we could = receive; and, when stepping through how we could *send* an INVITE and = *receive* a CANCEL, we determined that it wasn't actually possible. So = we added code to respond with a 481 and a distinctive reason code (to = aid in debugging). But these were early days, and the implementation had = some bugs to work out.

Fast forward to our = Pre-IMS system demo for our local executive team -- someone managed to = take a sequence of actions that actually *did* coax the client that was = receiving an incoming call into sending out a CANCEL. At which point = both terminals displayed an error box reading "481 Called Party = Apparently On Crack."

They didn't = appreciate the humor in the situation.

Anyway, these many years later, I'm still pretty sure that a = called party can't reject an incoming call by sending a CANCEL. And I'm = more circumspect about how error conditions are communicated to users as = well.

/a
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_3285767E-B39A-4B36-8FBA-0685B1383D77-- From nobody Wed Jan 11 00:15:30 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703AA120725 for ; Wed, 11 Jan 2017 00:15:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifHT_gMgN9r9 for ; Wed, 11 Jan 2017 00:15:27 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F80129A68 for ; Wed, 11 Jan 2017 00:15:26 -0800 (PST) Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id EEAB63CFA; Wed, 11 Jan 2017 09:15:08 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_F06E7214-D3F2-45DC-B2EA-7530EBE1D240" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <0a0cb12b-1a48-df12-924a-2701f01020f7@nostrum.com> Date: Wed, 11 Jan 2017 09:14:53 +0100 Message-Id: <4DC8018C-A1AA-4E6F-AF87-000490B2A644@edvina.net> References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <0a0cb12b-1a48-df12-924a-2701f01020f7@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "sipcore@ietf.org" , Olle E Johansson , Henning Schulzrinne Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 08:15:29 -0000 --Apple-Mail=_F06E7214-D3F2-45DC-B2EA-7530EBE1D240 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 11 Jan 2017, at 00:59, Adam Roach wrote: >=20 > Ah, that does seem to make more sense. If you want to mention this = case in the document, it seems congruent with the example given in = section 3.1 of RFC3326. You'd need to describe the use case more clearly = in the document, but I see no problems with adding that. >=20 > If you do so, it's worth noting at the same time that the use of = Reason in CANCEL is somewhat fragile due to the fact that RFC3261 places = no requirement on proxies to copy it forward. Section 2 of RFC3326 does = call this out at SHOULD strength, but this only reads on proxies that go = out of their way to implement that RFC (which seems a little unlikely). Many servers have implemented the =E2=80=9Ccall answered elsewhere=E2=80=9D= reason code just to manage the =E2=80=9Cmissed call=E2=80=9D lists on = the phones. I know that both Asterisk and Kamailio support this today, so adding this = reason would be very simple in those servers. /O >=20 > /a >=20 > On 1/10/17 17:10, Henning Schulzrinne wrote: >> What I was thinking of (but didn=E2=80=99t write) is whether it makes = sense to include a Reason in the CANCEL with a 666, issued by the UAC. = Basically, the call forks, one of the phones ringing gets picked up, the = recipient presses the big red spam button and the other phones stop = ringing with the indication that somebody just deep-sixed the call. >> =20 >> Is that useful? >> =20 >> From: Adam Roach [mailto:adam@nostrum.com ]=20= >> Sent: Monday, January 09, 2017 6:21 PM >> To: Henning Schulzrinne = >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] I-D Action: = draft-ietf-sipcore-status-unwanted-01.txt >> =20 >> Quick comment on the draft based on my review of the changes: >>=20 >> This version added the phrase "or CANCEL", resulting in the phrase: = "UAS issues a BYE or CANCEL request terminating an incoming call." >>=20 >> A funny story here... Back in the '90's, when I was involved in = prototyping some mobile SIP clients, one of our prototype clients would = actually display the reason phrase from any SIP error message it sent or = received. Our call state machine had specific handling for every message = type we could receive; and, when stepping through how we could *send* an = INVITE and *receive* a CANCEL, we determined that it wasn't actually = possible. So we added code to respond with a 481 and a distinctive = reason code (to aid in debugging). But these were early days, and the = implementation had some bugs to work out. >>=20 >> Fast forward to our Pre-IMS system demo for our local executive team = -- someone managed to take a sequence of actions that actually *did* = coax the client that was receiving an incoming call into sending out a = CANCEL. At which point both terminals displayed an error box reading = "481 Called Party Apparently On Crack." >>=20 >> They didn't appreciate the humor in the situation. >>=20 >> Anyway, these many years later, I'm still pretty sure that a called = party can't reject an incoming call by sending a CANCEL. And I'm more = circumspect about how error conditions are communicated to users as = well. >>=20 >> /a >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = --Apple-Mail=_F06E7214-D3F2-45DC-B2EA-7530EBE1D240 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 11 Jan 2017, at 00:59, Adam Roach <adam@nostrum.com> = wrote:

Ah, that does seem to make more = sense. If you want to mention this case in the document, it seems = congruent with the example given in section 3.1 of RFC3326. You'd need = to describe the use case more clearly in the document, but I see no = problems with adding that.

If you do so, = it's worth noting at the same time that the use of Reason in CANCEL is = somewhat fragile due to the fact that RFC3261 places no requirement on = proxies to copy it forward. Section 2 of RFC3326 does call this out at = SHOULD strength, but this only reads on proxies that go out of their way = to implement that RFC (which seems a little unlikely).
Many servers have implemented the = =E2=80=9Ccall answered elsewhere=E2=80=9D reason code just to manage the = =E2=80=9Cmissed call=E2=80=9D lists on the phones. I know
that = both Asterisk and Kamailio support this today, so adding this reason = would be very simple in those servers.

/O

/a

On 1/10/17 17:10, = Henning Schulzrinne wrote:
What I was thinking of = (but didn=E2=80=99t write) is whether it makes sense to include a Reason = in the CANCEL with a 666, issued by the UAC. Basically, the call forks, = one of the phones ringing gets picked up, the recipient presses the big = red spam button and the other phones stop ringing with the indication = that somebody just deep-sixed the call.
 
Is that useful?
 
From: Adam Roach [mailto:adam@nostrum.com] 
Sent: Monday, January 09, 2017 = 6:21 PM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>
Cc: sipcore@ietf.org
Subject: Re: [sipcore] I-D Action: = draft-ietf-sipcore-status-unwanted-01.txt
 
Quick comment on the draft based on my review of the = changes:

This version added the phrase "or = CANCEL", resulting in the phrase: "UAS issues a BYE or = CANCEL request = terminating an incoming call."

A funny = story here... Back in the '90's, when I was involved in prototyping some = mobile SIP clients, one of our prototype clients would actually display = the reason phrase from any SIP error message it sent or received. Our = call state machine had specific handling for every message type we could = receive; and, when stepping through how we could *send* an INVITE and = *receive* a CANCEL, we determined that it wasn't actually possible. So = we added code to respond with a 481 and a distinctive reason code (to = aid in debugging). But these were early days, and the implementation had = some bugs to work out.

Fast forward to our = Pre-IMS system demo for our local executive team -- someone managed to = take a sequence of actions that actually *did* coax the client that was = receiving an incoming call into sending out a CANCEL. At which point = both terminals displayed an error box reading "481 Called Party = Apparently On Crack."

They didn't = appreciate the humor in the situation.

Anyway, these many years later, I'm still pretty sure that a = called party can't reject an incoming call by sending a CANCEL. And I'm = more circumspect about how error conditions are communicated to users as = well.

/a


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_F06E7214-D3F2-45DC-B2EA-7530EBE1D240-- From nobody Thu Jan 12 05:33:11 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A5F12962E for ; Thu, 12 Jan 2017 05:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGpVTUXCz4ba for ; Thu, 12 Jan 2017 05:33:07 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3277312961A for ; Thu, 12 Jan 2017 05:33:07 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id t8so12274142vke.3 for ; Thu, 12 Jan 2017 05:33:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=qllb9HHe51Df24KI975TeYUWQtdcYkBZDHvVKAuA/ZY=; b=AENQ9mpfS4TU4zmD5y8ICzp0zzmNvQYergwoxfVepEWSY7yoxMKS/VLuGBzWUs3vPX JNyRhLKLRiNEeH9lskSCx5zqwwNRnbYKiQKyWVIV+9f/5yOqCIstkJ28BI5UGW1zEeFZ UzgWaOTTPiBC+Jn7v7Y77vThCGvogU3TXr9h95EHOG0CQ+SSg38jkAV/FS72+GUi3/dM hdC0lzfVXgUq0RxnK+914xD3gfRhk8F3Q1IghDVe4r3jotjzM0Y+kw4a75mw21YxjqiM bnAmUrxuXH9L6zrnoHAP28xeHmciMrLM+FHtSkiMMn6lNHlIIhxix2NhAbnR51GzDXux Sl+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qllb9HHe51Df24KI975TeYUWQtdcYkBZDHvVKAuA/ZY=; b=GSwGOBeEtJHwsRY0xYpD5gyPe+XzQxvfezca671/Z6Kb5jqdx4reTrYMk+PqiPz2NY HICkyvLd2AMtx5c+vDjN0uzAC6qaHUACQrgO1jOOLJbwnVtU/NyELNdW+2gN/9T6+IFO S5FCCLkihCwTMiI8KEV39mH1nwEzwxjVzbkenvQRBewNuMOJxdsJohJEQDPo2TY9e0MO LkUieNTBnOXJFiQOX19yIzEeDlW+dJdZ7DVcORGaoTIGfKV//cqe0p0xcjQLjfaW+ifW KAgTx7IsY9TnVLL3DFh/Sg7MR+fnAeVC7cqc8dMDiGglKSrxdYTrtZ+S+p2kNJaiZZ0s ipqg== X-Gm-Message-State: AIkVDXL/mmeEkP35DYtHwavop9yDoAlKLa/9ejAO84sTY5MV4h55lO7gY6mPoKr252ZrE/iO/irkWnpxNlftAg== X-Received: by 10.31.92.9 with SMTP id q9mr7255487vkb.88.1484227986215; Thu, 12 Jan 2017 05:33:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Thu, 12 Jan 2017 05:33:05 -0800 (PST) From: Rifaat Shekh-Yusef Date: Thu, 12 Jan 2017 08:33:05 -0500 Message-ID: To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=001a114e1702e2819e0545e5c1c1 Archived-At: Subject: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 13:33:09 -0000 --001a114e1702e2819e0545e5c1c1 Content-Type: text/plain; charset=UTF-8 Hi, RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA2* to replace the MD5 algorithm. I am trying to revolve this old draft that does the same for SIP: https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ I would appreciate any review and comments on the draft. Regards, Rifaat --001a114e1702e2819e0545e5c1c1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

RFC7617 updated the HTTP Digest<= /b> mechanism and added support for SHA2 to replace the MD5 algorith= m.

I am trying to revolve this old draft that does= the same for SIP:
I would appreciate any review and comments on the draft.
=

Regards,
=C2=A0Rifaat






--001a114e1702e2819e0545e5c1c1-- From nobody Thu Jan 12 07:57:45 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3289129469 for ; Thu, 12 Jan 2017 07:57:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaesRB_WSAxc for ; Thu, 12 Jan 2017 07:57:41 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 783941293FB for ; Thu, 12 Jan 2017 07:57:40 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CFnRMq004246; Thu, 12 Jan 2017 15:57:29 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tsgg2rdg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 15:57:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=C6cpaIwgBfGPyQANQ6WWqi+dZ97zYDWWHwf4q27OKtc=; b=tzytVR7Gt3bDt1bej41/el+sAS9XJ6hBv/SeOcqCvAFjc3YUFBoOsCoJDu6h1uyHbYtQxjCNCytYb/c341g7IKPEUiMqh07MTsNot5JRpM/VwczMJE1xZHmzw+ssWxvJBuqOZbSr1RabdA4rXZ0MysXQHVnj5YZwwkIhUTRbN/M= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 15:57:27 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 15:57:27 +0000 From: Henning Schulzrinne To: "Olle E. Johansson" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZq3RayBYA4OJdkqIm+d2wXq+s6Ew0KiAgAGOjjCAAJgTAIACFFhg Date: Thu, 12 Jan 2017 15:57:27 +0000 Message-ID: References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <396E65B1-602F-4486-892D-C233B0DAB55A@edvina.net> In-Reply-To: <396E65B1-602F-4486-892D-C233B0DAB55A@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: e319374c-b7bf-432c-ee29-08d43b03b505 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:guXSe11yBqeusB7zsvMkO7XnQ1CXQcpd//xkgiNPgjM/T4nnpxEwqLIuwXVhTtE/IKKeN05HZLaVDJRne5S6Z33cRQyXluazV6kJDRuX/SxdY8VVnLNSrMTFZali2baduElLlyUH8Tt6w1mGw5mrA4LvY/wfGZmYGxhNRsD2Okc56lmiMbrOZi5Siu6xXaJpVlJ52/J9b8BSOKA6MPMzxqxppInbIJk4HwceTC3MqnVyEcewga1lXqXOEyF1QxL4+zFXGSBNreoLD8dZONgfWvjL/5GOHiH0/5Rlvd/V1lxr2w2jVZNzeQszbRg2RXZ/021NTKfwixcYVeciMgZrnce4wfkz75pHEESfRAEZwHPlhi1xMd60wjbcNxTonf+H2x+PKyBHh+M3Fh1n8z25xfjylLfUcDHoqdaFxdmoA9BVW5BETK1CVO0RZ3/5+BaIzrR5acjLv+ARAoF1XO/h1w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(20161123558021)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(377454003)(24454002)(54896002)(55016002)(122556002)(6306002)(99286003)(81166006)(8676002)(54906002)(81156014)(38730400001)(9686003)(3846002)(102836003)(790700001)(92566002)(3660700001)(25786008)(66066001)(7696004)(110136003)(77096006)(6506006)(6916009)(8936002)(229853002)(2950100002)(6436002)(2900100001)(19609705001)(93886004)(6116002)(3280700002)(101416001)(4326007)(86362001)(5660300001)(2906002)(33656002)(68736007)(74316002)(54356999)(76176999)(105586002)(106356001)(106116001)(236005)(230783001)(50986999)(97736004)(7736002)(189998001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634E12C918D1B2C57A54443EA790CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 15:57:27.2176 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_12:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 15:57:44 -0000 --_000_CY1PR09MB0634E12C918D1B2C57A54443EA790CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIC0gIEkgaGF2ZSBhZGRlZCB0aGlzIGNhc2UgYW5kIHRoZSBleHBsYW5hdGlvbiB5b3Ug bWVudGlvbmVkLg0KDQpGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiBbbWFpbHRvOm9lakBlZHZpbmEu bmV0XQ0KU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IDM6MTIgQU0NClRvOiBIZW5u aW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+DQpDYzogT2xsZSBF IEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+OyBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29t Pjsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTAxLnR4dA0KDQoNCk9uIDExIEphbiAy MDE3LCBhdCAwMDoxMCwgSGVubmluZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBm Y2MuZ292PG1haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+PiB3cm90ZToNCg0KV2hh dCBJIHdhcyB0aGlua2luZyBvZiAoYnV0IGRpZG7igJl0IHdyaXRlKSBpcyB3aGV0aGVyIGl0IG1h a2VzIHNlbnNlIHRvIGluY2x1ZGUgYSBSZWFzb24gaW4gdGhlIENBTkNFTCB3aXRoIGEgNjY2LCBp c3N1ZWQgYnkgdGhlIFVBQy4gQmFzaWNhbGx5LCB0aGUgY2FsbCBmb3Jrcywgb25lIG9mIHRoZSBw aG9uZXMgcmluZ2luZyBnZXRzIHBpY2tlZCB1cCwgdGhlIHJlY2lwaWVudCBwcmVzc2VzIHRoZSBi aWcgcmVkIHNwYW0gYnV0dG9uIGFuZCB0aGUgb3RoZXIgcGhvbmVzIHN0b3AgcmluZ2luZyB3aXRo IHRoZSBpbmRpY2F0aW9uIHRoYXQgc29tZWJvZHkganVzdCBkZWVwLXNpeGVkIHRoZSBjYWxsLg0K DQpJcyB0aGF0IHVzZWZ1bD8NCg0KWWVzLCBiZWNhdXNlIHRoZSBvdGhlciBwaG9uZXMgY2FuIGRl bGV0ZSB0aGUgY2FsbCAtIG9yIG5vdCBhZGQgaXQgLSBmcm9tIHRoZSDigJxtaXNzZWQgY2FsbHPi gJ0gbGlzdC4gWW91IGRvbuKAmXQgd2FudCB0byBjYWxsIGJhY2sgdG8gdGhhdCBudW1iZXIuDQoN Ci9PDQoNCg0KDQo= --_000_CY1PR09MB0634E12C918D1B2C57A54443EA790CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLmFwcGxlLWNvbnZlcnRl ZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5p bnNlcnQNCgl7bXNvLXN0eWxlLW5hbWU6aW5zZXJ0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5UaGFua3MgLSZuYnNwOyBJIGhhdmUgYWRkZWQgdGhpcyBjYXNlIGFuZCB0aGUg ZXhwbGFuYXRpb24geW91IG1lbnRpb25lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IE9sbGUgRS4gSm9oYW5zc29uIFttYWlsdG86b2VqQGVkdmluYS5uZXRdDQo8 YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKYW51YXJ5IDExLCAyMDE3IDM6MTIgQU08YnI+ DQo8Yj5Ubzo8L2I+IEhlbm5pbmcgU2NodWx6cmlubmUgJmx0O0hlbm5pbmcuU2NodWx6cmlubmVA ZmNjLmdvdiZndDs8YnI+DQo8Yj5DYzo8L2I+IE9sbGUgRSBKb2hhbnNzb24gJmx0O29lakBlZHZp bmEubmV0Jmd0OzsgQWRhbSBSb2FjaCAmbHQ7YWRhbUBub3N0cnVtLmNvbSZndDs7IHNpcGNvcmVA aWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBJLUQgQWN0aW9uOiBk cmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTAxLnR4dDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDExIEphbiAyMDE3LCBhdCAwMDox MCwgSGVubmluZyBTY2h1bHpyaW5uZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhlbm5pbmcuU2NodWx6 cmlubmVAZmNjLmdvdiI+SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoYXQgSSB3YXMg dGhpbmtpbmcgb2YgKGJ1dCBkaWRu4oCZdCB3cml0ZSkgaXMgd2hldGhlciBpdCBtYWtlcyBzZW5z ZSB0byBpbmNsdWRlIGEgUmVhc29uIGluIHRoZSBDQU5DRUwgd2l0aCBhIDY2NiwgaXNzdWVkIGJ5 IHRoZSBVQUMuDQogQmFzaWNhbGx5LCB0aGUgY2FsbCBmb3Jrcywgb25lIG9mIHRoZSBwaG9uZXMg cmluZ2luZyBnZXRzIHBpY2tlZCB1cCwgdGhlIHJlY2lwaWVudCBwcmVzc2VzIHRoZSBiaWcgcmVk IHNwYW0gYnV0dG9uIGFuZCB0aGUgb3RoZXIgcGhvbmVzIHN0b3AgcmluZ2luZyB3aXRoIHRoZSBp bmRpY2F0aW9uIHRoYXQgc29tZWJvZHkganVzdCBkZWVwLXNpeGVkIHRoZSBjYWxsLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5JcyB0aGF0IHVzZWZ1bD88L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZXMsIGJlY2F1c2Ug dGhlIG90aGVyIHBob25lcyBjYW4gZGVsZXRlIHRoZSBjYWxsIC0gb3Igbm90IGFkZCBpdCAtIGZy b20gdGhlIOKAnG1pc3NlZCBjYWxsc+KAnSBsaXN0LiBZb3UgZG9u4oCZdCB3YW50IHRvIGNhbGwg YmFjayB0byB0aGF0IG51bWJlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+L088bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_CY1PR09MB0634E12C918D1B2C57A54443EA790CY1PR09MB0634namp_-- From nobody Thu Jan 12 08:08:43 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22D11293FB for ; Thu, 12 Jan 2017 08:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpgkIjbQ0jDw for ; Thu, 12 Jan 2017 08:08:40 -0800 (PST) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 796CA12948C for ; Thu, 12 Jan 2017 08:08:40 -0800 (PST) Received: by mail-ua0-x235.google.com with SMTP id i68so17488588uad.0 for ; Thu, 12 Jan 2017 08:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=psITMYvjo/yHn7C+GurydpYzOj0B73Rs+7mzwKDlehI=; b=VGmmo7JT0rAEaKqvBit/VX06xa1nwOamCtzS0i+SkDYCxgjR99UxBIqi5t7N8VTLv5 pypVOi+XsO2MgJCONrU+gu6Dy+hJG1q7OYUL9ejn+07bo8ypWUn46YuoHn7TAluCet2i grYn2TvEwA4bNLTvxBsVujw6ut20sil9naw9p81VaxEItZKIk65/8BUjbrMw/tITnqgh KaBO8I5aMBa83Gawy7BL40Fmy21Mz67UfnB3h4DaTmjZqwBBOJ0MC7tfGQu8VP/nGp0k NdJNFNSVdp68sagk+tLDkXStX/5XQuxPydWxXhjg73wRPW17f+sIdwPxYNnerUAf21sW bKkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=psITMYvjo/yHn7C+GurydpYzOj0B73Rs+7mzwKDlehI=; b=F0prplu3TmNqNA9wxUnewhihZCtDsgZ3PXil/CAlQOAtbgN5wBEVCX9EBiGZoD3B8C gtTxtpCigMJkKVkkNz4Lu0T9eF3lMMGAtGZm4r4/HiOUo4q8jOgI9I7uWhlrYUud60I0 1EHhvTH4BiRMiD1ooZ7PIYsGItu8QDkLv1hZVNChT1hjelVZgjvuf0/OoZDEgPk00wWi 4OvQ2dIWmjEBSVeRGR5Bd/nd2i/bMiayV9hpw1Ol93yefEo/cevVqvsl6WfrhdBITeHR xDT3AH7cxuykFRGsR5hSaGCRP1H9L6PKbw4tR2YKc6bkal7/ajPsVWKGNwUpYMBHgls/ gLQw== X-Gm-Message-State: AIkVDXJGHuQnrPg06VfdVcVe0NwnxbKbp2E7Go5o1pl6580R0v/GYXHw4EEc13D2C6ZqF/rFFQErFyk0K1qCng== X-Received: by 10.176.76.154 with SMTP id y26mr8188217uaf.68.1484237319392; Thu, 12 Jan 2017 08:08:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Thu, 12 Jan 2017 08:08:39 -0800 (PST) In-Reply-To: References: From: Rifaat Shekh-Yusef Date: Thu, 12 Jan 2017 11:08:39 -0500 Message-ID: To: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary=f403045f8a922f51390545e7eec6 Archived-At: Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 16:08:42 -0000 --f403045f8a922f51390545e7eec6 Content-Type: text/plain; charset=UTF-8 Sorry, it is RFC7616 that updated the HTTP Digest mechanism. https://tools.ietf.org/html/rfc7616 Regards, Rifaat On Thu, Jan 12, 2017 at 8:33 AM, Rifaat Shekh-Yusef wrote: > Hi, > > RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA2* > to replace the MD5 algorithm. > > I am trying to revolve this old draft that does the same for SIP: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > > I would appreciate any review and comments on the draft. > > Regards, > Rifaat > > > > > > > --f403045f8a922f51390545e7eec6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry, it is RFC7616 that updated the HTTP Digest mechanis= m.

Regards,
=C2=A0R= ifaat


<= br>
On Thu, Jan 12, 2017 at 8:33 AM, Rifaat Shekh= -Yusef <rifaat.ietf@gmail.com> wrote:
Hi,

RFC7617 updated the= HTTP Digest mechanism and added support for SHA2 to replace = the MD5 algorithm.

I am trying to revolve this old= draft that does the same for SIP:

I would appreciate any review and comments on = the draft.

Regards,
=C2=A0Rifaat







--f403045f8a922f51390545e7eec6-- From nobody Thu Jan 12 08:44:53 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AEB12949D for ; Thu, 12 Jan 2017 08:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFG6t9M-q7bd for ; Thu, 12 Jan 2017 08:44:51 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90E371294E9 for ; Thu, 12 Jan 2017 08:44:51 -0800 (PST) Received: from resomta-po-07v.sys.comcast.net ([96.114.154.231]) by resqmta-po-06v.sys.comcast.net with SMTP id RiTtclA6dmU9eRiUccZewL; Thu, 12 Jan 2017 16:44:50 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-07v.sys.comcast.net with SMTP id RiUacjZkTaRT1RiUbcBwlV; Thu, 12 Jan 2017 16:44:50 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0CGim34007945; Thu, 12 Jan 2017 11:44:48 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0CGilrm007942; Thu, 12 Jan 2017 11:44:47 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-Reply-To: (rifaat.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 12 Jan 2017 11:44:47 -0500 Message-ID: <87lgug6xds.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 16:44:53 -0000 Rifaat Shekh-Yusef writes: > RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA2* to > replace the MD5 algorithm. > > I am trying to revolve this old draft that does the same for SIP: > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ It makes sense to do this, of course, as MD-5 is thoroughly obsolete. As a matter of exposition, you say "This section does NOT maintain backward compatibility with RFC 2069." But of course as a consequence of that, it isn't compatible with RFC 3261 either. I'd like to see a description of how the draft's section 2.6 compares with the existing SIP authentication scheme -- is this just adding the new algorithms and making qop mandatory? Dale From nobody Thu Jan 12 10:07:29 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFE71294E9 for ; Thu, 12 Jan 2017 10:07:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EUu-yNQX6gXQ for ; Thu, 12 Jan 2017 10:07:26 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D29412950C for ; Thu, 12 Jan 2017 10:07:26 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id 137so17843793vkl.0 for ; Thu, 12 Jan 2017 10:07:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PPfADngdJt40Tu7aj05TbQ6VQWSoYrsE8vrBiuJD0nU=; b=Env+L9IpHFaJnvDH5f00RGITkrg9CA8l7jbGGB2KsWIrJyZnRP2haFvKVHaOMc7o6O cDdfLV+Nuwp8RpXw+V7vPhwWagd8mvSoxm3NV/91JAabALBhhsKvFogPMsG8zQ5OvG1I kNYsVkH3y7MGHUZnWuo3KjU7cMQ78g2h5K18XqvWqZJw9inA2/S7edc/fCnwLi2G1CgO VxRDEcRqTCokgcyVASX79DLcb+kLZ/w0z+H02BHTVqzMgkPFjvlOZRm0F0jLW01D+UVX OlYA3bjYA6fnYVvlu+3xr2128R3E6nmgHgmXP6OZcIukMfixNoyBOtmJk/i7aY7/xVsF kMcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PPfADngdJt40Tu7aj05TbQ6VQWSoYrsE8vrBiuJD0nU=; b=oujf1HB8GBXCw4TpRIQnjpGOqyQUBlgiFBMHi2cnrpSCCkFP0Qvt+p2YynveLwLvW7 G2TfD/AeAk3mJLy6qx3Ob1AFxihz/Y4Q3XUdlWSX2TGRff9DUtAkRS+2Khr5cKDyan2X azjYJzELn/dHkahnwqd9lcXWtj/6CL/mbEkW7D9AqTAUxYlmUxrnGx4ci8Zly6HvAeFg OSWU49P4mLpJZan0TKchN7I2FTsi9S/CVtzZNXuQ9wQ9Zp8xlxuDF4hX8grzICEJGxkB E9TqIclxfvZ/l7wEqFE3SEKFGAvF7CUDMZ0JWufn2eds5jNtDE0AlfuUpcz/9CHbkSpo ra5Q== X-Gm-Message-State: AIkVDXJ/y9SX+VzXNzh+3+mvZB6UI1pM9OLLoS18Bpw7irMlJhZAl38fjombxQSpBX5ZHta8sLtYu1iUeraATg== X-Received: by 10.31.92.9 with SMTP id q9mr7948076vkb.88.1484244445266; Thu, 12 Jan 2017 10:07:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Thu, 12 Jan 2017 10:07:24 -0800 (PST) In-Reply-To: <87lgug6xds.fsf@hobgoblin.ariadne.com> References: <87lgug6xds.fsf@hobgoblin.ariadne.com> From: Rifaat Shekh-Yusef Date: Thu, 12 Jan 2017 13:07:24 -0500 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a114e1702eb88f40545e99600 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:07:28 -0000 --001a114e1702eb88f40545e99600 Content-Type: text/plain; charset=UTF-8 Thanks Dale! Please, see my reply inline... Regards, Rifaat On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley wrote: > Rifaat Shekh-Yusef writes: > > RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA2* > to > > replace the MD5 algorithm. > > > > I am trying to revolve this old draft that does the same for SIP: > > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ > > It makes sense to do this, of course, as MD-5 is thoroughly obsolete. > > As a matter of exposition, you say "This section does NOT maintain > backward compatibility with RFC 2069." But of course as a consequence > of that, it isn't compatible with RFC 3261 either. The statement you quoted was in the previous version of the document, but not in v05. If I remember correctly, we discussed that and during one of the IETF meetings and it was deemed unnecessary to maintain that. We did the same with the new HTTP Digest mechanism defined in RFC7616. Is that a problem for SIP? > I'd like to see a description of how the draft's section 2.6 compares > with the existing SIP authentication scheme -- is this just adding the > new algorithms and making qop mandatory? > > Yes, the idea is that this draft will add the SHA2 algorithms as the recommended algorithms, and only keep the MD5 for backward compatibility. Regards, Rifaat > Dale > --001a114e1702eb88f40545e99600 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Dale!

Please, see my reply inlin= e...

Regards,
=C2=A0Rifaat

On Thu, Ja= n 12, 2017 at 11:44 AM, Dale R. Worley <worley@ariadne.com>= wrote:
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> writes:
> RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA= 2* to
> replace the MD5 algorithm.
>
> I am trying to revolve this old draft that does the same for SIP:
> https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/

It makes sense to do this, of course, as MD-5 is thoroughly obsolete= .

As a matter of exposition, you say "This section does NOT maintain
backward compatibility with RFC 2069."=C2=A0 But of course as a conseq= uence
of that, it isn't compatible with RFC 3261 either.
The statement you quoted was in the previous version of the doc= ument, but not in v05.
If I remember correctly, we discussed that= and during one of the IETF meetings and it was deemed unnecessary to maint= ain that.
We did the same with the new HTTP Digest mechanism defi= ned in RFC7616.

Is that a problem for SIP?


=C2=A0

I'd like to see a description of how the draft's section 2.6 compar= es
with the existing SIP authentication scheme -- is this just adding the
new algorithms and making qop mandatory?

Yes, the idea is that this draft will add the SHA2 algorithms as th= e recommended algorithms, and only keep the MD5 for backward compatibility.=

Regards,
=C2=A0Rifaat


=C2=A0
Dale

--001a114e1702eb88f40545e99600-- From nobody Thu Jan 12 12:22:06 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99ACC129451 for ; Thu, 12 Jan 2017 12:22:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sQJ3XJ3GIsT for ; Thu, 12 Jan 2017 12:22:01 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7271293F0 for ; Thu, 12 Jan 2017 12:21:59 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CKJd2d003672; Thu, 12 Jan 2017 20:21:58 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0052.outbound.protection.outlook.com [23.103.198.52]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tr5uawhs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 20:21:58 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JK6aoxe2wIMuogkZHioIgb50ZuoRHkx0cRGkqx2q4tI=; b=J2VRybpbAceowWmkbnu9cm8AwAO4zEssmVvwhaoPBxjmIpjbeau21mR1RT4Xq+RWZEphJmc2smjj8CPrfal8mXxNaC9tQXPdKoHvk0LggqgjEpZ3wvNZGFi9KMSPNks5IVvl+UMuGazD0D1nZyuhoFCJMh+zLEHlEYnCctLejPM= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 20:21:56 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 20:21:56 +0000 From: Henning Schulzrinne To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt Thread-Index: AQHSZtkNZBs4MySSekqJkBAojeGCU6Eo5mXAgAAslYCAAM8vAIAApDXOgAE5U4CACZTuYA== Date: Thu, 12 Jan 2017 20:21:56 +0000 Message-ID: References: <148354995482.12958.16879782015333412107.idtracker@ietfa.amsl.com> <88ba4e41-f9e2-cb7f-d118-43086db3034d@nostrum.com> <092a3e1f-f9c4-1023-8f02-88052c79457c@comcast.net> <949EF20990823C4C85C18D59AA11AD8BADFD135B@FR712WXCHMBA11.zeu.alcatel-lucent.com>, <45a2dc35659238515f113beba22cf690@mail.gmail.com> <68978a4baccc71b511a42094bf9450c7@mail.gmail.com> In-Reply-To: <68978a4baccc71b511a42094bf9450c7@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 0fcb56aa-dc7f-4fbb-9e49-08d43b28a7b0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:EmnmbrDrESqSMyRjJcDqVtb45XRJ6hoX5zEAUv5yN8qcjkk77h5anreOISUTvllhUV9oV7s9diH7UMX5yvuAuBilUZruE4X/I5Zxy+wfUTKlBRdtZ2OkPhsVZORC46WUFOFGPTHMMvFmkCPTFL2nSxWm5bWYJQXqWhUUn6YymraDG4mtEFPM098wt1+uoxwHKBiiHQ5fAQ3GoUUysWDSaxnTsOVUvvY7X3hr4MJ7dge4ZC0Ss6Vpp6l1KWyGUP2hcJdKg7Blvm3Zi2tNh3qRHA/9k1t2YeIhCybCZMHsdcYh4wqhBPdtQqz/SOlQBhVmF/E6HoCwKw6VwWRcY7vWe/J6NO+Kn2581aUtHFEbMtjLqCn2hTGub4q1O+XIdPfLghBJucNamVMKQLLjWifqAc/9pRX1xcjGiUi5GJyhO4v3M66XUF5UEtnIOOA3iGxn6TadhSzOcRkwcM1ogvY8Tw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(82608151540597)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(51444003)(377454003)(101416001)(6436002)(236005)(2950100002)(33656002)(25786008)(9686003)(7696004)(106356001)(55016002)(551934003)(2900100001)(99286003)(6506006)(92566002)(105586002)(76176999)(229853002)(54356999)(77096006)(38730400001)(66066001)(106116001)(50986999)(5660300001)(81166006)(230783001)(93886004)(2501003)(6306002)(81156014)(54896002)(6116002)(3660700001)(5001770100001)(3846002)(8936002)(97736004)(102836003)(2906002)(107886002)(790700001)(86362001)(68736007)(3280700002)(189998001)(19609705001)(122556002)(7736002)(74316002)(8676002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634A7C34396BB81ACAC8B3BEA790CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 20:21:56.1300 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Commenters, please check draft-ietf-sipcore-status-unwanted-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:22:04 -0000 --_000_CY1PR09MB0634A7C34396BB81ACAC8B3BEA790CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIG1hZGUgdGhlIHN1Z2dlc3RlZCBjaGFuZ2UgdG8g4oCcdHJhbnNhY3Rpb27igJ0uIFJh dGhlciB0aGFuIHJlcGVhdGluZyB0aGUgdGV4dCBpbiA1MDU3LCBJIGhhdmUgbm90ZWQgdGhhdCB0 aGlzIGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgNnh4IHByZWNlZGVudCBkZXNjcmliZWQgdGhl cmUuIElmIHlvdeKAmWQgcHJlZmVyIHRleHQsIHBsZWFzZSBzZW5kLiBJIHN1c3BlY3Qgd2UgYWdy ZWUgdGhhdCB0aGUgZXhhbXBsZSB5b3UgZ2l2ZSBpcyBzb21ld2hhdCBjb250cml2ZWQsIGJ1dCBt YXliZSBJ4oCZbSBtaXNzaW5nIHdoZW4gdGhpcyB3b3VsZCBvY2N1ciBpbiBwcmFjdGljZS4gKEFj Y29yZGluZyB0byB0aGUgZGlzY3Vzc2lvbiwgNjY2IHdvdWxkIGJlIGJhc2VkIG9uIHVzZXIgYWN0 aW9uLCBzbyBtZWRpYSBzZXJ2ZXJzIHByb2JhYmx5IHNob3VsZG7igJl0IHJldHVybiBvbmXigKYp DQoNCkZyb206IEJyZXR0IFRhdGUgW21haWx0bzpicmV0dEBicm9hZHNvZnQuY29tXQ0KU2VudDog RnJpZGF5LCBKYW51YXJ5IDA2LCAyMDE3IDE6MDAgUE0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5l IDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+OyBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0Ip IDxrZWl0aC5kcmFnZUBub2tpYS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTog W3NpcGNvcmVdIENvbW1lbnRlcnMsIHBsZWFzZSBjaGVjayBkcmFmdC1pZXRmLXNpcGNvcmUtc3Rh dHVzLXVud2FudGVkLTAxLnR4dA0KDQpIaSwNCg0KWWVzOyBJIHRoaW5rIHRoYXQgaXQgd291bGQg YmUgYmVuZWZpY2lhbCB0byBkaXNjdXNzIG1pZC1kaWFsb2cgNjY2IGluIHJlbGF0aW9uIHRvIFJG QyA1MDU3Lg0KDQpJIGRvbuKAmXQgaGF2ZSBhIHN0cm9uZyBvcGluaW9uIGFib3V0IGlmIDY2NiBp bXBhY3RzIFRyYW5zYWN0aW9uIE9ubHksIERlc3Ryb3lzIFVzYWdlLCBvciBEZXN0cm95cyBEaWFs b2cuICBIb3dldmVyIGV2ZW4gdGhvdWdoIEnigJltIG5vdCBzdXJlIGlmL3doeSBzb21lb25lIHdv dWxkIHNlbmQgYSA2NjYgcmVzcG9uc2UgZm9yIG1pZC1kaWFsb2cgcmVxdWVzdCwgaXQgbWlnaHQg YmUgYmV0dGVyIHRvIG9ubHkgaW1wYWN0IHRoZSB0cmFuc2FjdGlvbi4gIEZvciBleGFtcGxlLCBt ZWRpYSBzZXJ2ZXIgbWlnaHQgd2FudCB0byByZXR1cm4gNjY2IGZvciBzb21lIG1pZC1kaWFsb2cg cmVxdWVzdHMgd2hpbGUgY29udGludWluZyB0byBwbGF5IHRyZWF0bWVudCBhc3NvY2lhdGVkIHdp dGggSU5WSVRF4oCZcyA2NjYuDQoNCg0KRnJvbTogSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRv Okhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjxtYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBm Y2MuZ292Pl0NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDE3IDY6MjQgUE0NClRvOiBC cmV0dCBUYXRlOyBEcmFnZSwgS2VpdGggKE5va2lhIC0gR0IpOyBzaXBjb3JlQGlldGYub3JnPG1h aWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDb21tZW50ZXJz LCBwbGVhc2UgY2hlY2sgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMS50eHQN Cg0KDQpXb3VsZCBpdCBiZSBoZWxwZnVsIHRvIGluZGljYXRlIHRoYXQgNjY2IHNob3VsZCBiZSB0 cmVhdGVkIGFzIDYwNCAoYXMgdGhhdCBzZWVtcyBtb3N0IHJlYXNvbmFibGUsIGdpdmVuIHRoYXQg NjY2IGlzIHByb2JhYmx5IGEgZGlhbG9nIGtpbGxlci4gVGVudGF0aXZlIHdvcmRpbmc6DQoNCg0K DQpGb2xsb3dpbmcgPHhyZWY9IlJGQzUwNTciLz4sIHRoZSA2NjYgcmVzcG9uc2UgZGVzdHJveXMg dGhlIGRpYWxvZy4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEJy ZXR0IFRhdGUgPGJyZXR0QGJyb2Fkc29mdC5jb208bWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb20+ Pg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgNSwgMjAxNyA4OjMwOjUwIEFNDQpUbzogRHJhZ2Us IEtlaXRoIChOb2tpYSAtIEdCKTsgSGVubmluZyBTY2h1bHpyaW5uZTsgc2lwY29yZUBpZXRmLm9y ZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQ29tbWVu dGVycywgcGxlYXNlIGNoZWNrIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDEu dHh0DQoNCj4gRnVydGhlciBpZiBpdCBkb2VzIGFwcGVhciBpbiBhIHN1YnNlcXVlbnQgdHJhbnNh Y3Rpb24gd2l0aGluDQo+IGEgZGlhbG9nIHdoYXQgaXMgdGhlIGFjdGlvbiBieSB0aGUgcmVjZWl2 ZXIgaW4gdGVybXMgb2YgZGlhbG9nDQo+IGhhbmRsaW5nICh1bmxlc3Mgd2Ugd2FudCB0byBwcmVj bHVkZSBpdCBmcm9tIHN1YnNlcXVlbnQNCj4gdHJhbnNhY3Rpb25zKS4gSXMgaXQgYWxyZWFkeSBj b3ZlcmVkIGJ5IFJGQyA1MDU3Lg0KDQpSRkMgNTA1NyBkb2VzIGRpc2N1c3MgNnh4IGhhbmRsaW5n LiAgSG93ZXZlciBzaW5jZSBub3RlIDE3IGluZGljYXRlcyAiNnh4DQp1bnJlY29nbml6ZWQgcmVz cG9uc2VzIiBhbmQgVGFibGUgMSBpbmRpY2F0ZXMgInVua25vd24gNnh4IiwgSSdtIG5vdA0KcG9z aXRpdmUgaWYgVGFibGUgMidzIDZ4eCBpbXBhY3QgKFRyYW5zYWN0aW9uKSB3YXMgaW50ZW5kZWQg dG8gYWxzbyBhcHBseQ0KdG8ga25vd24gNnh4IHJlc3BvbnNlcyBkZWZpbmVkIHN1YnNlcXVlbnQg dG8gUkZDIDUwNTcuDQo= --_000_CY1PR09MB0634A7C34396BB81ACAC8B3BEA790CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6TWVubG87fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFy Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsc2Fucy1zZXJpZjt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWlscXVvdGUsIGRpdi5lbWFpbHF1 b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTow aW47DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+SSBoYXZlIG1hZGUgdGhlIHN1Z2dlc3RlZCBjaGFuZ2UgdG8g4oCc dHJhbnNhY3Rpb27igJ0uIFJhdGhlciB0aGFuIHJlcGVhdGluZyB0aGUgdGV4dCBpbiA1MDU3LCBJ IGhhdmUgbm90ZWQgdGhhdCB0aGlzIGlzIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgNnh4IHByZWNl ZGVudCBkZXNjcmliZWQNCiB0aGVyZS4gSWYgeW914oCZZCBwcmVmZXIgdGV4dCwgcGxlYXNlIHNl bmQuIEkgc3VzcGVjdCB3ZSBhZ3JlZSB0aGF0IHRoZSBleGFtcGxlIHlvdSBnaXZlIGlzIHNvbWV3 aGF0IGNvbnRyaXZlZCwgYnV0IG1heWJlIEnigJltIG1pc3Npbmcgd2hlbiB0aGlzIHdvdWxkIG9j Y3VyIGluIHByYWN0aWNlLiAoQWNjb3JkaW5nIHRvIHRoZSBkaXNjdXNzaW9uLCA2NjYgd291bGQg YmUgYmFzZWQgb24gdXNlciBhY3Rpb24sIHNvIG1lZGlhIHNlcnZlcnMgcHJvYmFibHkNCiBzaG91 bGRu4oCZdCByZXR1cm4gb25l4oCmKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4gQnJldHQgVGF0ZSBbbWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb21dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDA2LCAyMDE3IDE6MDAgUE08YnI+DQo8Yj5Ubzo8 L2I+IEhlbm5pbmcgU2NodWx6cmlubmUgJmx0O0hlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiZn dDs7IERyYWdlLCBLZWl0aCAoTm9raWEgLSBHQikgJmx0O2tlaXRoLmRyYWdlQG5va2lhLmNvbSZn dDs7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzaXBjb3JlXSBD b21tZW50ZXJzLCBwbGVhc2UgY2hlY2sgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRl ZC0wMS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5ZZXM7IEkgdGhpbmsgdGhhdCBpdCB3b3VsZCBiZSBiZW5lZmlj aWFsIHRvIGRpc2N1c3MgbWlkLWRpYWxvZyA2NjYgaW4gcmVsYXRpb24gdG8gUkZDIDUwNTcuPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQgaGF2ZSBh IHN0cm9uZyBvcGluaW9uIGFib3V0IGlmIDY2NiBpbXBhY3RzIFRyYW5zYWN0aW9uIE9ubHksIERl c3Ryb3lzIFVzYWdlLCBvciBEZXN0cm95cyBEaWFsb2cuJm5ic3A7IEhvd2V2ZXIgZXZlbiB0aG91 Z2ggSeKAmW0gbm90IHN1cmUgaWYvd2h5IHNvbWVvbmUgd291bGQNCiBzZW5kIGEgNjY2IHJlc3Bv bnNlIGZvciBtaWQtZGlhbG9nIHJlcXVlc3QsIGl0IG1pZ2h0IGJlIGJldHRlciB0byBvbmx5IGlt cGFjdCB0aGUgdHJhbnNhY3Rpb24uJm5ic3A7IEZvciBleGFtcGxlLCBtZWRpYSBzZXJ2ZXIgbWln aHQgd2FudCB0byByZXR1cm4gNjY2IGZvciBzb21lIG1pZC1kaWFsb2cgcmVxdWVzdHMgd2hpbGUg Y29udGludWluZyB0byBwbGF5IHRyZWF0bWVudCBhc3NvY2lhdGVkIHdpdGggSU5WSVRF4oCZcyA2 NjYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBIZW5uaW5nIFNjaHVsenJpbm5l IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiI+SGVu bmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgSmFudWFyeSAwNSwgMjAxNyA2OjI0IFBNPGJyPg0KPGI+VG86PC9iPiBCcmV0dCBUYXRlOyBE cmFnZSwgS2VpdGggKE5va2lhIC0gR0IpOyA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9y ZyI+DQpzaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNv cmVdIENvbW1lbnRlcnMsIHBsZWFzZSBjaGVjayBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVu d2FudGVkLTAxLnR4dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IGlkPSJ4 X2RpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPldvdWxkIGl0IGJlIGhlbHBm dWwgdG8gaW5kaWNhdGUgdGhhdCA2NjYgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgNjA0IChhcyB0aGF0 IHNlZW1zIG1vc3QgcmVhc29uYWJsZSwgZ2l2ZW4gdGhhdCA2NjYgaXMgcHJvYmFibHkgYSBkaWFs b2cga2lsbGVyLiBUZW50YXRpdmUgd29yZGluZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOmJsYWNrIj5Gb2xsb3dpbmcg PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVubG87Y29s b3I6IzA0MzNGRiI+Jmx0O3hyZWY9PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6TWVubG87Y29sb3I6I0I0MjYxQSI+JnF1b3Q7UkZDNTA1NyZxdW90Ozwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvO2NvbG9yOiMw NDMzRkYiPi8mZ3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6TWVubG87Y29sb3I6YmxhY2siPiwNCiB0aGUgNjY2IHJlc3BvbnNlIGRlc3Ryb3lzIHRoZSBk aWFsb2cuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJN c29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9Inhf ZGl2UnBseUZ3ZE1zZyI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PiBCcmV0dCBUYXRlICZsdDs8YSBocmVmPSJtYWlsdG86YnJldHRAYnJvYWRzb2Z0LmNvbSI+YnJl dHRAYnJvYWRzb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51 YXJ5IDUsIDIwMTcgODozMDo1MCBBTTxicj4NCjxiPlRvOjwvYj4gRHJhZ2UsIEtlaXRoIChOb2tp YSAtIEdCKTsgSGVubmluZyBTY2h1bHpyaW5uZTsgPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0 Zi5vcmciPg0Kc2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtz aXBjb3JlXSBDb21tZW50ZXJzLCBwbGVhc2UgY2hlY2sgZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1 cy11bndhbnRlZC0wMS50eHQ8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+Jmd0OyBGdXJ0aGVyIGlmIGl0IGRvZXMgYXBwZWFyIGluIGEgc3Vic2VxdWVudCB0cmFu c2FjdGlvbiB3aXRoaW48YnI+DQomZ3Q7IGEgZGlhbG9nIHdoYXQgaXMgdGhlIGFjdGlvbiBieSB0 aGUgcmVjZWl2ZXIgaW4gdGVybXMgb2YgZGlhbG9nPGJyPg0KJmd0OyBoYW5kbGluZyAodW5sZXNz IHdlIHdhbnQgdG8gcHJlY2x1ZGUgaXQgZnJvbSBzdWJzZXF1ZW50PGJyPg0KJmd0OyB0cmFuc2Fj dGlvbnMpLiBJcyBpdCBhbHJlYWR5IGNvdmVyZWQgYnkgUkZDIDUwNTcuPGJyPg0KPGJyPg0KUkZD IDUwNTcgZG9lcyBkaXNjdXNzIDZ4eCBoYW5kbGluZy4mbmJzcDsgSG93ZXZlciBzaW5jZSBub3Rl IDE3IGluZGljYXRlcyAmcXVvdDs2eHg8YnI+DQp1bnJlY29nbml6ZWQgcmVzcG9uc2VzJnF1b3Q7 IGFuZCBUYWJsZSAxIGluZGljYXRlcyAmcXVvdDt1bmtub3duIDZ4eCZxdW90OywgSSdtIG5vdDxi cj4NCnBvc2l0aXZlIGlmIFRhYmxlIDIncyA2eHggaW1wYWN0IChUcmFuc2FjdGlvbikgd2FzIGlu dGVuZGVkIHRvIGFsc28gYXBwbHk8YnI+DQp0byBrbm93biA2eHggcmVzcG9uc2VzIGRlZmluZWQg c3Vic2VxdWVudCB0byBSRkMgNTA1Ny48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY1PR09MB0634A7C34396BB81ACAC8B3BEA790CY1PR09MB0634namp_-- From nobody Thu Jan 12 12:31:29 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2789F12946A for ; Thu, 12 Jan 2017 12:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LTKNMl6woK37 for ; Thu, 12 Jan 2017 12:31:22 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E991293F0 for ; Thu, 12 Jan 2017 12:31:21 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CKSp1L014612; Thu, 12 Jan 2017 20:31:20 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0015.outbound.protection.outlook.com [23.103.198.15]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tra2ax1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 20:31:20 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bwfSEamQ9swZLaEGGsF5vhRy932EUOPob4ij57Su7io=; b=uuWvnYs5CBG8bQzvsQY0ej626U/pUJsg2TM011UqtlEH6v63teY6RWk5Am6qaskXm7w424jDQzHo4aKYtXwyNzvHMAa9R7o0WkG7JWE/IymDytbiN6HgPIi1loP/WWLS2fNeJpwTk112RtxyyoQ0kGON7ZeCSDAzdxR7FrdcYxQ= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 20:31:18 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 20:31:18 +0000 From: Henning Schulzrinne To: Brett Tate , "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAFeq4AABk5kgAABTb+gAAQDLCSACJvigAABFMCgAEzthYA Date: Thu, 12 Jan 2017 20:31:18 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <87dbd0dcda36614df8860ad8eea6b84b@mail.gmail.com> In-Reply-To: <87dbd0dcda36614df8860ad8eea6b84b@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 34c898c9-6a01-4398-14b1-08d43b29f6af x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:Yfauh0Ik4rEojQDlKp3eI14srVM265qG7xpyI4CruAEYAyizmaPNtTSSW+s3ahVAkOOUyWxS+p9qRS/M91TMJf1vd+H89WOhzsrGzDjB6SsBLiTWNidyGokgZ8la8OAW1QPrDUqWt45/kwyOWPj0eKM77eWkU4tydMn88ZZ53MgHeeVKLx421PNQ91z7lk86cOresfulX5a6c4gWE0w6AWFEAVZS3C26E9I3Km7HhqFbvRu8FSNIzxRrPNwvFAArKIijwX0PisRrZIDAvsISrlNuut/0GICUlc2Qg89UmzufUgjKXrXphK46ZT3f6BzkGqwmmb2UxuYZeRIFjohRQRQHGXL6m8h07YaOkf6iY1URvKwed32R3gK8VIral47LRLM06wN/3+/mBwIk0tOMWk5l11xhsrpjwAyjiYFxbce+DSdvYmjTH+VWLj7xLBGq0BxvymjkEOkHSKUdMGIFGA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(131327999870524)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(20161123558021)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(13464003)(377454003)(24454002)(55016002)(122556002)(99286003)(6306002)(54896002)(81156014)(38730400001)(81166006)(2501003)(3846002)(790700001)(102836003)(9686003)(5890100001)(92566002)(3660700001)(25786008)(66066001)(229853002)(77096006)(8676002)(6506006)(7696004)(8936002)(6436002)(606005)(2900100001)(19609705001)(2950100002)(86362001)(5660300001)(6116002)(101416001)(3280700002)(2906002)(575784001)(33656002)(74316002)(68736007)(76176999)(54356999)(107886002)(105586002)(106356001)(5001770100001)(236005)(230783001)(50986999)(2201001)(7906003)(97736004)(189998001)(7736002)(93886004)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06347595D9D61B759E752827EA790CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 20:31:18.2207 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:31:26 -0000 --_000_CY1PR09MB06347595D9D61B759E752827EA790CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gYWZyYWlkIEkgZG9u4oCZdCBxdWl0ZSBmb2xsb3cgd2hhdCB0ZXh0IHlvdSBhcmUgc3Vn Z2VzdGluZyBhbmQgSeKAmW0gc3VzcGVjdGluZyB3ZeKAmXJlIHdlbGwgaW50byB0aGUgd2VlZHMg YXQgdGhpcyBwb2ludC4gTXkgZ2VuZXJhbCBpbmNsaW5hdGlvbiBpcyB0byBvbmx5IHN0YXRlIHRo aW5ncyB3aGVyZSA2NjYgZGlmZmVycyBmcm9tIDZ4eCBoYW5kbGluZywgcmF0aGVyIHRoYW4gdHJ5 IHRvIGNhcHR1cmUgYWxsIHBvc3NpYmxlIHN0YXR1cyBjb2RlIGlzc3VlcyB0aGF0IGFyZSBnZW5l cmljIHRvIChtb3N0KSA2eHggY29kZXMuIFRoaXMgYXZvaWRzIGNyZWF0aW5nIGluYWR2ZXJ0ZW50 IGNvbnRyYWRpY3Rpb25zIG9yIHRoZSBuZWVkIHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQgc2hvdWxk IHRoZXJlIGJlIGNoYW5nZXMgaW4gdGhlIGdlbmVyaWMgaGFuZGxpbmcuIEluIG90aGVyIHdvcmRz LCA2NjYgc2hvdWxkIGJlIHRyZWF0ZWQgbGlrZSA2eHggdW5sZXNzIG90aGVyd2lzZSBub3RlZC4N Cg0KVGh1cywgY2FuIHlvdSBwcm92aWRlIHN1Z2dlc3RlZCB0ZXh0Pw0KDQpJ4oCZbSBub3Qgc3Vy ZSB3aHkgdGhlIGNhbGxpbmcgcGFydHkgd291bGQgaW5kaWNhdGUgNjY2LiBBZnRlciByZWNlaXZp bmcgYSByZS1JTlZJVEU/IEluIHJlc3BvbnNlIHRvIGEgQllFPyBJIGFkbWl0IHRoYXQgSSBsYWNr IHRoZSBpbWFnaW5hdGlvbiBhcyB0byBob3cgdGhpcyB3b3VsZCBvY2N1ciBhbmQgd2h5IHRoaXMg d291bGQgY2F1c2UgYW55dGhpbmcgb3RoZXIgdGhhbiB3aGF0IHdvdWxkIGhhcHBlbiBmb3IgYSBn ZW5lcmljIDZ4eCByZXNwb25zZSBpbiB0aG9zZSBjaXJjdW1zdGFuY2VzLg0KDQpTdHJldGNoaW5n IHRoZSBpbWFnaW5hdGlvbiwgSSBjb3VsZCBpbWFnaW5lIHRoZSBjYXNlIHdoZXJlIEnigJltIG1p c2xlZCBpbnRvIGRpYWxpbmcgYSBudW1iZXIgKGUuZy4sIGFzIHBhcnQgb2YgYSBzcGFtIGVtYWls KSB0aGF0IHR1cm5zIG91dCB0byBiZSBhIHJvYm90IHBlZGRsaW5nIHRpbWUgc2hhcmVzLiBJIGNv dWxkIHNlbmQgYSBCWUUsIHdpdGggYSA2NjYgUmVhc29uLg0KDQpJcyB0aGF0IHRoZSBjYXNlIHlv dSBoYXZlIGluIG1pbmQ/DQoNCkhlbm5pbmcNCg0KRnJvbTogQnJldHQgVGF0ZSBbbWFpbHRvOmJy ZXR0QGJyb2Fkc29mdC5jb21dDQpTZW50OiBGcmlkYXksIEphbnVhcnkgMDYsIDIwMTcgMTI6MzIg UE0NClRvOiBtYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTsgSGVubmluZyBTY2h1bHpyaW5uZSA8 SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Pjsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDog UkU6IFtzaXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2Fu dGVkLTAxDQoNCkhpLA0KDQpUaGUgZHJhZnQgcG90ZW50aWFsbHkgc2hvdWxkIGFsc28gZGlzY3Vz cyB0aGUgcG90ZW50aWFsIGZvciB0aGUgY29ubmVjdGVkIHBhcnR5IHRvIGNoYW5nZSBtaWQtZGlh bG9nIDEpIHdpdGhvdXQgaXQgYmVpbmcgY29tbXVuaWNhdGVkIGFuZCAyKSB3aXRoIGl0IGJlaW5n IGNvbW11bmljYXRlIGJ5IFJGQyA0OTE2LCBSRkMgNTg3NiwgZXQgY2V0ZXJhLg0KDQpGcm9tIGEg c2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcGVyc3BlY3RpdmUsIHRoZSB3cm9uZyBwYXJ0eSBtaWdo dCBiZSBmbGFnZ2VkIGJ5IHRoZSA2NjYgd2hlbiB0aGUgY29ubmVjdGVkIHBhcnR5IGNoYW5nZXMu DQoNClRoZSBkcmFmdCBzaG91bGQgcG90ZW50aWFsbHkgYWxzbyBkaXNjdXNzIHRoZSBwb3RlbnRp YWwgZm9yIGNhbGxpbmcgcGFydHkgaW5kaWNhdGluZyA2NjYuICBPdGhlciB0aGFuIGEgd2F5IHRv IGF0dGFjayBzb21lb25lLCBJ4oCZbSBub3Qgc3VyZSBpZiBhcmUgYW55IDNQQ0MsIHRyYW5zZmVy LCBvciBvdGhlciBzZXJ2aWNlIHNpdHVhdGlvbnMgd2hlcmUgaXQgbWlnaHQgYWN0dWFsbHkgYmUg YXBwcm9wcmlhdGUuDQoNCg0KRnJvbTogbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRv Om1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tPiBbbWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFu Z2UuY29tPG1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbT5dDQpTZW50OiBGcmlkYXks IEphbnVhcnkgMDYsIDIwMTcgMTA6MjggQU0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lOyBBc3Zl cmVuLCBUb2xnYTsgQnJldHQgVGF0ZTsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1z aXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KDQpIaSwNCg0KVG8gcmVmbGVjdCB0aGUgcXVlc3Rp b24gb2YgdGhlIGludGVycHJldGF0aW9uIG9mIHRoZSA2NjYgcmVzcG9uc2UgaW50ZXJwcmV0YXRp b24gd2hlbiB0aGUgY2FsbGVyIGhhcyBzZXZlcmFsIGlkZW50aXRpZXMgdXNlZCBmb3IgdGhpcyBj YWxsIChpZS4gRnJvbSBhbmQgUC1Bc3NlcnRlZC1JZGVudGl0eSBhcmUgZGlmZmVyZW50KSBvciBj YWxsIGZvcndhcmRpbmcvY2FsbCB0cmFuc2ZlciB1c2UgY2FzZXMgZm9yIHdoaWNoIGl0IGhhcyB0 byBiZSBkaXNjdXNzZWQgd2hpY2ggcGFydHkgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaGFzIGEgZnJh dWR1bGVudCAoaWUuIHRoZSBjYWxsaW5nIHBhcnR5IG9yIHRoZSBkaXZlcnRpbmcgcGFydHkgb3Ig Ym90aCA/KSA7IEkgcHJvcG9zZSB0byBhZGQgdGhlIGZvbGxvd2luZyB0ZXh0Og0KVGhpcyBkb2N1 bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGEgY2FsbGVkIHBhcnR5IGNhbiByZWpl Y3QgYW4gdW53YW50ZWQgY2FsbCB3aXRob3V0IGNvbnNpZGVyYXRpb24gb2YgdGhlIGNhbGxpbmcg cGFydHkgaWRlbnRpZmljYXRpb24gdGhhdCByZW1haW4gdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIg cG9saWN5LiBJbmRlZWQsIHRoZSBjYWxsaW5nIHBhcnR5IGlkZW50aXR5IG1heSBiZSByZWZsZWN0 ZWQgaW4gZGlmZmVyZW50IHdheSBmb3IgYSBkaXJlY3QgY2FsbCBvciBhZnRlciBhIGRpdmVydGlu ZyBzZXJ2aWNlIGluIFAtQXNzZXJ0ZWQtSWRlbnRpdHksIEZyb20sIEhpc3RvcnktSW5mbyBvciBh bnkgY29uY3VycmVudCBoZWFkZXIgZmllbGQgdGhhdCBjYW4gYmUgcHJlc2VudCBhdCB0aGUgc2Ft ZSB0aW1lIGluIGEgU0lQIG1lc3NhZ2UuDQoNClRob3NlIHF1ZXN0aW9ucyBhcmUgcmVhbCBpc3N1 ZXMgZm9yIG9wZXJhdG9ycyBhbmQgaW1wbGVtZW50b3JzIGFuZCB0aGV5IGFyZSBhIHdlYWtuZXNz IHRoYXQgZnJhdWR1bGVudCBjYWxsZXJzIGNvdWxkIHVzZSB0byBieXBhc3MgdGhlIG1lY2hhbmlz bS4NCg0KQlIsDQpNYXJpYW5uZQ0KDQpEZSA6IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgSGVubmluZyBTY2h1bHpyaW5uZQ0KRW52b3nDqSA6 IHZlbmRyZWRpIDYgamFudmllciAyMDE3IDAwOjE0DQrDgCA6IEFzdmVyZW4sIFRvbGdhOyBCcmV0 dCBUYXRlOyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KT2JqZXQg OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53 YW50ZWQtMDENCg0KDQpPbiAoaSksIEkgYWdyZWUgdGhhdCB3ZSBkb24ndCB3YW50IHRvIGdldCBp bnRvIHdoYXQgaW5mb3JtYXRpb24gaXMgYmVpbmcgdXNlZCwgZ2l2ZW4gdGhhdCB0aGUgZW50aXR5 IG1vc3QgbGlrZWx5IHRvIHVzZSB0aGUgNjY2IGluZm9ybWF0aW9uLCBpLmUuLCB0aGUgdGVybWlu YXRpbmcgY2FycmllciwgaXMgYWxzbyB0aGUgb25lIGRlY2lkaW5nIGhvdyBjYWxsZXIgaWRlbnRp dHkgaXMgYmVpbmcgcHJlc2VudGVkIHRvIHRoZSB1c2VyIChQQUksIEZyb20sIGV0Yy4pLg0KDQoN Cg0KVGFzdGVzIG1heSBkaWZmZXIsIGJ1dCBJIGRvbid0IHNlZSBob3cgd2UgY2FuIHNheSBtdWNo IHRoYXQncyB1c2VmdWwgdG8gaW1wbGVtZW50b3JzIGhlcmUsIHdpdGhvdXQgZ2V0dGluZyBpbnRv IHdlZWRzIHRoYXQgYXJlIGFscmVhZHkgYmVpbmcgZXhwbG9yZWQgYnkgKHNheSkgdGhlIFNIQUtF TiBlZmZvcnQuDQoNCg0KDQpBbHNvLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGRlZmluaW5nICJj YWxsIiBpcyBuZWVkZWQgaGVyZSwgZ2l2ZW4gdGhhdCB3ZSdkIHByb2JhYmx5IG5vdCBnbyBtdWNo IGJleW9uZCB3aGF0J3MgaW4gUkZDIDMyNjE6DQoNCg0KDQpDYWxsOiBBIGNhbGwgaXMgYW4gaW5m b3JtYWwgdGVybSB0aGF0IHJlZmVycyB0byBzb21lIGNvbW11bmljYXRpb24NCg0KICAgICAgICAg YmV0d2VlbiBwZWVycywgZ2VuZXJhbGx5IHNldCB1cCBmb3IgdGhlIHB1cnBvc2VzIG9mIGENCg0K ICAgICAgICAgbXVsdGltZWRpYSBjb252ZXJzYXRpb24uDQpBbHNvLCBnaXZlbiB0aGUgZGlzY3Vz c2lvbiBvZiB1c2FnZSBmb3Igbm9uLUlOVklURSwgSSdsbCBjaGFuZ2UgImNhbGwiIHRvICJyZXF1 ZXN0IiBvciAiZGlhbG9nIiB3aGVyZSB0aGUgY29udGV4dCBpcyBtb3JlIHRoYW4ganVzdCBhbiBl eGFtcGxlIG9mIHdoYXQgaXMgbGlrZWx5IHRvIGJlIHRoZSBtb3N0IGNvbW1vbiBjYXNlIC0gSU5W SVRFIGZvciBhIHBob25lIGNhbGwuDQoNCg0KDQpIZW5uaW5nDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+ Pg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgNSwgMjAxNyAxMDoyMjo1NSBBTQ0KVG86IEJyZXR0 IFRhdGU7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53 YW50ZWQtMDENCg0KSSBhZ3JlZSB0aGF0IGRlZmluaW5nIHdoYXQgYSAiY2FsbCIgaXMgYSBnb29k IGlkZWEgYnV0IEkgaGF2ZSBhIGRpZmZlcmVudCB0YWtlIG9uIHdoYXQgaXQgc2hvdWxkIHNheToN Cg0KaS0gIEEgImNhbGwiIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQgaXMgYSBjb21t dW5pY2F0aW9uIHNlc3Npb24gYXMgcGVyY2VpdmVkIGJ5IGEgaHVtYW4gYWdlbnQsIGUuZy4gYXMg aW4gIkkgcmVjZWl2ZWQgYSBjYWxsIGZyb20gbXkgZ3JhbmRtb3RoZXIuIi4gSXQgZG9lcyBub3Qg aW1wbHkgYW55dGhpbmcgZnVydGhlciBhcyBmYXIgYXMgU0lQIGluZm9ybWF0aW9uIGVsZW1lbnRz IHdoaWNoIHVzdWFsbHkgYXJlIHVzZWQgdG8gY2FycnkgY2FsbGluZyBwYXJ0eSBpZGVudGlmaWNh dGlvbiwgZS5nLiBQLUFzc2VydGVkLUlkLCBGcm9tIGhlYWRlcnMsIGFyZSBjb25jZXJuZWQuIEl0 IGlzIHVwIHRvIHRoZSBvcGVyYXRvci9uZXR3b3JrIHBvbGljeSBob3cgdG8gbWFrZSBhc3NvY2lh dGUgZnVydGhlciBjYWxscyB3aXRoIHRoZSBpbmZvcm1hdGlvbi9kZWNpc2lvbiBkZXJpdmVkIGZy b20gdW53YW50ZWQgY2FsbHMuDQoNCmlpLSAiTm9uZSBvZiB0aGUgZXhpc3RpbmcgNHh4LCA1eHgg b3IgNnh4IHJlc3BvbnNlIGNvZGVzIHNpZ25pZnkgdGhhdCBjYWxscyBmcm9tIHRoaXMgY2FsbGVy IGFyZSB1bndhbnRlZCBieSB0aGUgY2FsbGVkIHBhcnR5LiINCj09Pg0KIk5vbmUgb2YgdGhlIGV4 aXN0aW5nIDR4eCwgNXh4IG9yIDZ4eCByZXNwb25zZSBjb2RlcyBzaWduaWZ5IHRoYXQgdGhpcyBj YWxsIGlzIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFydHkuIg0KDQpJIHRoaW5rIGlpLSBpcyBu ZWVkZWQgdG8gcmVsaXZlIHRoZSBlbmQgdXNlciBmcm9tIHRoZSBidXJkZW4gb2YgImtub3dpbmcg dGhlIGFjdHVhbCBjYWxsZXIiLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmV0dCBUYXRlDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5 IDA1LCAyMDE3IDc6NTQgQU0NCj4gVG86IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0 Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KPg0KPiBIaSwNCj4NCj4gSSBhbHNvIGFncmVl IHRoYXQgYWRkaW5nIHN1Y2ggYSBwYXJhZ3JhcGggd291bGQgYmUgdXNlZnVsLg0KPg0KPiBGb3Ig aW5zdGFuY2UgaWYgc29tZW9uZSBkZXNpcmVzIGEgc2VydmljZSB0byBmb3J3YXJkIGFsbCByZWNl aXZlZCBzcGFtIGNhbGxzIHRvDQo+IGFub3RoZXIgc2V0IG9mIHZpY3RpbXMsIHRoZXkgd291bGQg bGlrZWx5IG5vdCB1c2Ugc3VjaCBhIHNlcnZpY2UgaWYgdGhlDQo+IGZvcndhcmRpbmcgcGFydHkg bWlnaHQgYWxzbyBnZXQgZmxhZ2dlZCBhcyBwYXJ0IG9mIHRoZSA2NjYgaGFuZGxpbmcuDQo+DQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBzaXBjb3JlIFttYWls dG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bA0KPiBLeXppdmF0 DQo+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA0LCAyMDE3IDc6NTEgUE0NCj4gPiBUbzog c2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uDQo+ID4gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11 bndhbnRlZC0wMQ0KPiA+DQo+ID4gT24gMS80LzE3IDU6MzUgUE0sIG1hcmlhbm5lLm1vaGFsaUBv cmFuZ2UuY29tPG1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4N Cj4gPiA+IC1TZWN0aW9uIDQgZ2VuZXJhbDoNCj4gPiA+IElNTywgaXQgd291bGQgYmUgZ29vZCB0 byBoYXZlIGEgcGFyYWdyYXBoIGFkZHJlc3NpbmcgdGhlIHF1ZXN0aW9uIG9mDQo+ID4gPiB0aGUg ImNhbGxpbmcgcGFydHkgbnVtYmVyIiAobWVudGlvbmVkIHNldmVyYWwgdGltZSBpbiB0aGUgZG9j dW1lbnQpOg0KPiA+ID4gaW5kZWVkLCB0aGlzIGNhbGxpbmcgcGFydHkgbnVtYmVyIGNhbiBiZSBp ZGVudGlmaWVkIGJ5IHRoZSB0ZWxlcGhvbmUNCj4gPiA+IG51bWJlci9hZGRyZXNzIGluIHRoZSBG cm9tIGhlYWRlciBvciB0aGUgb25lIGluIHRoZQ0KPiA+ID4gUC1Bc3NlcnRlZC1JZGVudGl0eSBo ZWFkZXIgdGhhdCBtYXkgYmUgZGlmZmVyZW50LiBEZXBlbmRpbmcgb24gdGhlDQo+ID4gPiBvbmUg ZGlzcGxheWVkIHRvIHRoZSBjYWxsZWQgVUEsIHRoZSA2NjYgY291bGQgY29uY2VybiBvbmx5IG9u ZSBvcg0KPiA+ID4gYm90aCBhZGRyZXNzZXMgZGVwZW5kaW5nIG9uIHNlcnZpY2UgcHJvdmlkZXIg Y2hvaWNlcy4gSWYgd2UgdGFrZSB0aGUNCj4gPiA+IGV4YW1wbGUgb2YgYSBjYWxsLWNlbnRlciBv ciBhbiBJUEJYIGhhdmluZyB0aGUgaGVhZCBudW1iZXIgYW5kIGENCj4gPiA+IHJhbmdlIG9mIHBy aXZhdGUgbnVtYmVycywgdGhlIHNlcnZpY2UgcHJvdmlkZXIgY291bGQgaW50ZXJwcmV0IHRoZQ0K PiA+ID4gNjY2IGZyb20gdGhlIGNhbGxlZCB1c2VyIG9ubHkgZm9yIHRoZSBwcml2YXRlIG51bWJl ciAoaW4gdGhlIEZyb20NCj4gPiA+IGhlYWRlcikgb3IgZm9yIHRoZSB3aG9sZSBwb29sIChQLUFz c2VydGVkLUlkZW50aXR5KS4gSSBzdWdnZXN0IHRvDQo+ID4gPiBoYXZlIGEgcGFyYWdyYXBoIHRv IGhpZ2hsaWdodCB0aGlzIHBvaW50Lg0KPiA+DQo+ID4gSW50ZXJlc3RpbmcgcG9pbnQuIElmIHRo ZSBQQUlEIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBudW1iZXIgZGlzcGxheWVkDQo+ID4gdG8NCj4g dGhlDQo+ID4gY2FsbGVlLCBhbmQgdGhlIGNhbGxlZSByZWplY3RzIHRoZSBjYWxsIHdpdGhvdXQg YW5zd2VyaW5nLCBob3cgc2hvdWxkDQo+ICJibGFtZSINCj4gPiBiZSBhc3NpZ25lZD8gRnJvbSB0 aGUgY2FsbGxlZSdzIHBlcnNwZWN0aXZlIHRoZSBjb21wbGFpbnQgaXMgKmFib3V0Kg0KPiA+IHRo ZSBudW1iZXIgaGUgc2F3LCByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGlkZW50aXR5IG9mIHRoZSBh Y3R1YWwgY2FsbGVyIHdhcy4NCj4gPg0KPiA+ICAgICAgVGhhbmtzLA0KPiA+ICAgICAgUGF1bA0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zaXBjb3JlJmQ9 RGdJQ0FnJmM9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERV MVhlSElZUkhmYXJwazRNSzU5UkUmbT1UeVEtWW1pTDhiY0hwQjRPQjVzZ2g1UXg4RjBTMXpFSmpQ WThIaDA0Q1BvJnM9T1pvdmR4RG1yaXhTS2JGSkNFd01IeVpvanBVOHVZZVU5a28xTFlhQzVOWSZl PQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3Jl QGlldGYub3JnPg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NpcGNvcmUmZD1EZ0lDQWcm Yz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlS SGZhcnBrNE1LNTlSRSZtPVR5US1ZbWlMOGJjSHBCNE9CNXNnaDVReDhGMFMxekVKalBZOEhoMDRD UG8mcz1PWm92ZHhEbXJpeFNLYkZKQ0V3TUh5Wm9qcFU4dVllVTlrbzFMWWFDNU5ZJmU9DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1h aWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZkPURnSUNBZyZjPXkwaDBvbUNlMGpBVUdy NGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJm09 VHlRLVltaUw4YmNIcEI0T0I1c2doNVF4OEYwUzF6RUpqUFk4SGgwNENQbyZzPU9ab3ZkeERtcml4 U0tiRkpDRXdNSHlab2pwVTh1WWVVOWtvMUxZYUM1TlkmZT0NCg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j DQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4N Cg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQg d2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3Nh Z2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFu Z2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNo YW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo= --_000_CY1PR09MB06347595D9D61B759E752827EA790CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0KcC5lbWFpbHF1b3RlLCBsaS5lbWFpbHF1 b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1b3RlOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0OjEuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcsOp Zm9ybWF0w6kgSFRNTCBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiUHLDqWZvcm1hdMOpIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuUHJm b3JtYXRIVE1MLCBsaS5QcmZvcm1hdEhUTUwsIGRpdi5QcmZvcm1hdEhUTUwNCgl7bXNvLXN0eWxl LW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7bXNvLXN0eWxl LW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToiVGFob21hIixz YW5zLXNlcmlmO30NCnAuVGV4dGVkZWJ1bGxlcywgbGkuVGV4dGVkZWJ1bGxlcywgZGl2LlRleHRl ZGVidWxsZXMNCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI3 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjgNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGlu Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4t VVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5J 4oCZbSBhZnJhaWQgSSBkb27igJl0IHF1aXRlIGZvbGxvdyB3aGF0IHRleHQgeW91IGFyZSBzdWdn ZXN0aW5nIGFuZCBJ4oCZbSBzdXNwZWN0aW5nIHdl4oCZcmUgd2VsbCBpbnRvIHRoZSB3ZWVkcyBh dCB0aGlzIHBvaW50LiBNeSBnZW5lcmFsIGluY2xpbmF0aW9uIGlzIHRvIG9ubHkgc3RhdGUNCiB0 aGluZ3Mgd2hlcmUgNjY2IGRpZmZlcnMgZnJvbSA2eHggaGFuZGxpbmcsIHJhdGhlciB0aGFuIHRy eSB0byBjYXB0dXJlIGFsbCBwb3NzaWJsZSBzdGF0dXMgY29kZSBpc3N1ZXMgdGhhdCBhcmUgZ2Vu ZXJpYyB0byAobW9zdCkgNnh4IGNvZGVzLiBUaGlzIGF2b2lkcyBjcmVhdGluZyBpbmFkdmVydGVu dCBjb250cmFkaWN0aW9ucyBvciB0aGUgbmVlZCB0byB1cGRhdGUgdGhlIGRvY3VtZW50IHNob3Vs ZCB0aGVyZSBiZSBjaGFuZ2VzIGluIHRoZSBnZW5lcmljDQogaGFuZGxpbmcuIEluIG90aGVyIHdv cmRzLCA2NjYgc2hvdWxkIGJlIHRyZWF0ZWQgbGlrZSA2eHggdW5sZXNzIG90aGVyd2lzZSBub3Rl ZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRodXMsIGNhbiB5 b3UgcHJvdmlkZSBzdWdnZXN0ZWQgdGV4dD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPknigJltIG5vdCBzdXJlIHdoeSB0aGUgY2FsbGluZyBwYXJ0eSB3b3VsZCBp bmRpY2F0ZSA2NjYuIEFmdGVyIHJlY2VpdmluZyBhIHJlLUlOVklURT8gSW4gcmVzcG9uc2UgdG8g YSBCWUU/IEkgYWRtaXQgdGhhdCBJIGxhY2sgdGhlIGltYWdpbmF0aW9uIGFzIHRvIGhvdyB0aGlz IHdvdWxkDQogb2NjdXIgYW5kIHdoeSB0aGlzIHdvdWxkIGNhdXNlIGFueXRoaW5nIG90aGVyIHRo YW4gd2hhdCB3b3VsZCBoYXBwZW4gZm9yIGEgZ2VuZXJpYyA2eHggcmVzcG9uc2UgaW4gdGhvc2Ug Y2lyY3Vtc3RhbmNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlN0cmV0Y2hpbmcgdGhlIGltYWdpbmF0aW9uLCBJIGNvdWxkIGltYWdpbmUgdGhlIGNhc2Ugd2hl cmUgSeKAmW0gbWlzbGVkIGludG8gZGlhbGluZyBhIG51bWJlciAoZS5nLiwgYXMgcGFydCBvZiBh IHNwYW0gZW1haWwpIHRoYXQgdHVybnMgb3V0IHRvIGJlIGEgcm9ib3QgcGVkZGxpbmcNCiB0aW1l IHNoYXJlcy4gSSBjb3VsZCBzZW5kIGEgQllFLCB3aXRoIGEgNjY2IFJlYXNvbi48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklzIHRoYXQgdGhlIGNhc2UgeW91IGhh dmUgaW4gbWluZD88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhl bm5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEJyZXR0IFRh dGUgW21haWx0bzpicmV0dEBicm9hZHNvZnQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgSmFudWFyeSAwNiwgMjAxNyAxMjozMiBQTTxicj4NCjxiPlRvOjwvYj4gbWFyaWFubmUubW9o YWxpQG9yYW5nZS5jb207IEhlbm5pbmcgU2NodWx6cmlubmUgJmx0O0hlbm5pbmcuU2NodWx6cmlu bmVAZmNjLmdvdiZndDs7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtzaXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVk LTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0IHBvdGVudGlhbGx5IHNob3VsZCBhbHNvIGRpc2N1c3Mg dGhlIHBvdGVudGlhbCBmb3IgdGhlIGNvbm5lY3RlZCBwYXJ0eSB0byBjaGFuZ2UgbWlkLWRpYWxv ZyAxKSB3aXRob3V0IGl0IGJlaW5nIGNvbW11bmljYXRlZCBhbmQgMikgd2l0aCBpdCBiZWluZyBj b21tdW5pY2F0ZQ0KIGJ5IFJGQyA0OTE2LCBSRkMgNTg3NiwgZXQgY2V0ZXJhLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RnJvbSBhIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zIHBlcnNwZWN0aXZlLCB0aGUgd3JvbmcgcGFydHkgbWlnaHQgYmUgZmxhZ2dlZCBieSB0 aGUgNjY2IHdoZW4gdGhlIGNvbm5lY3RlZCBwYXJ0eSBjaGFuZ2VzLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhlIGRyYWZ0IHNob3VsZCBwb3RlbnRpYWxseSBh bHNvIGRpc2N1c3MgdGhlIHBvdGVudGlhbCBmb3IgY2FsbGluZyBwYXJ0eSBpbmRpY2F0aW5nIDY2 Ni4mbmJzcDsgT3RoZXIgdGhhbiBhIHdheSB0byBhdHRhY2sgc29tZW9uZSwgSeKAmW0gbm90IHN1 cmUgaWYgYXJlIGFueSAzUENDLCB0cmFuc2ZlciwNCiBvciBvdGhlciBzZXJ2aWNlIHNpdHVhdGlv bnMgd2hlcmUgaXQgbWlnaHQgYWN0dWFsbHkgYmUgYXBwcm9wcmlhdGUuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPg0KPGEgaHJlZj0ibWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFu Z2UuY29tIj5tYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJt YWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iPm1hcmlhbm5lLm1vaGFsaUBvcmFuZ2Uu Y29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMDYsIDIwMTcgMTA6 MjggQU08YnI+DQo8Yj5Ubzo8L2I+IEhlbm5pbmcgU2NodWx6cmlubmU7IEFzdmVyZW4sIFRvbGdh OyBCcmV0dCBUYXRlOyA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+DQpzaXBjb3Jl QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NpcGNvcmVdIENvbW1lbnRz IG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UbyBy ZWZsZWN0IHRoZSBxdWVzdGlvbiBvZiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIDY2NiByZXNw b25zZSBpbnRlcnByZXRhdGlvbiB3aGVuIHRoZSBjYWxsZXIgaGFzIHNldmVyYWwgaWRlbnRpdGll cyB1c2VkIGZvciB0aGlzIGNhbGwgKGllLiBGcm9tIGFuZCBQLUFzc2VydGVkLUlkZW50aXR5IGFy ZSBkaWZmZXJlbnQpIG9yIGNhbGwgZm9yd2FyZGluZy9jYWxsDQogdHJhbnNmZXIgdXNlIGNhc2Vz IGZvciB3aGljaCBpdCBoYXMgdG8gYmUgZGlzY3Vzc2VkIHdoaWNoIHBhcnR5IHNob3VsZCBiZSBj b25zaWRlcmVkIGhhcyBhIGZyYXVkdWxlbnQgKGllLiB0aGUgY2FsbGluZyBwYXJ0eSBvciB0aGUg ZGl2ZXJ0aW5nIHBhcnR5IG9yIGJvdGggPykgOyBJIHByb3Bvc2UgdG8gYWRkIHRoZSBmb2xsb3dp bmcgdGV4dDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFu aXNtIGJ5IHdoaWNoIGEgY2FsbGVkIHBhcnR5IGNhbiByZWplY3QgYW4gdW53YW50ZWQgY2FsbCB3 aXRob3V0IGNvbnNpZGVyYXRpb24gb2YgdGhlIGNhbGxpbmcgcGFydHkgaWRlbnRpZmljYXRpb24g dGhhdCByZW1haW4gdG8gdGhlIHNlcnZpY2UgcHJvdmlkZXIgcG9saWN5LiBJbmRlZWQsIHRoZSBj YWxsaW5nDQogcGFydHkgaWRlbnRpdHkgbWF5IGJlIHJlZmxlY3RlZCBpbiBkaWZmZXJlbnQgd2F5 IGZvciBhIGRpcmVjdCBjYWxsIG9yIGFmdGVyIGEgZGl2ZXJ0aW5nIHNlcnZpY2UgaW4gUC1Bc3Nl cnRlZC1JZGVudGl0eSwgRnJvbSwgSGlzdG9yeS1JbmZvIG9yIGFueSBjb25jdXJyZW50IGhlYWRl ciBmaWVsZCB0aGF0IGNhbiBiZSBwcmVzZW50IGF0IHRoZSBzYW1lIHRpbWUgaW4gYSBTSVAgbWVz c2FnZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRob3NlIHF1 ZXN0aW9ucyBhcmUgcmVhbCBpc3N1ZXMgZm9yIG9wZXJhdG9ycyBhbmQgaW1wbGVtZW50b3JzIGFu ZCB0aGV5IGFyZSBhIHdlYWtuZXNzIHRoYXQgZnJhdWR1bGVudCBjYWxsZXJzIGNvdWxkIHVzZSB0 byBieXBhc3MgdGhlIG1lY2hhbmlzbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPkJSLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NYXJpYW5uZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1 b3Q7LHNhbnMtc2VyaWYiPiBzaXBjb3JlIFs8YSBocmVmPSJtYWlsdG86c2lwY29yZS1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRlIGxh IHBhcnQgZGU8L2I+IEhlbm5pbmcgU2NodWx6cmlubmU8YnI+DQo8Yj5FbnZvecOpJm5ic3A7Ojwv Yj4gdmVuZHJlZGkgNiBqYW52aWVyIDIwMTcgMDA6MTQ8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IEFz dmVyZW4sIFRvbGdhOyBCcmV0dCBUYXRlOyA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9y ZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBbc2lw Y29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgaWQ9InhfZGl2dGFnZGVmYXVsdHdyYXBwZXIiPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si Pk9uIChpKSwgSSBhZ3JlZSB0aGF0IHdlIGRvbid0IHdhbnQgdG8gZ2V0IGludG8gd2hhdCBpbmZv cm1hdGlvbiBpcyBiZWluZyB1c2VkLCBnaXZlbiB0aGF0IHRoZSBlbnRpdHkgbW9zdCBsaWtlbHkg dG8gdXNlIHRoZSA2NjYgaW5mb3JtYXRpb24sIGkuZS4sIHRoZSB0ZXJtaW5hdGluZyBjYXJyaWVy LCBpcyBhbHNvIHRoZSBvbmUNCiBkZWNpZGluZyBob3cgY2FsbGVyIGlkZW50aXR5IGlzIGJlaW5n IHByZXNlbnRlZCB0byB0aGUgdXNlciAoUEFJLCBGcm9tLCBldGMuKS48L3NwYW4+PG86cD48L286 cD48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlRhc3RlcyBtYXkgZGlmZmVyLCBidXQgSSBk b24ndCBzZWUgaG93IHdlIGNhbiBzYXkgbXVjaCB0aGF0J3MgdXNlZnVsIHRvIGltcGxlbWVudG9y cyBoZXJlLCB3aXRob3V0IGdldHRpbmcgaW50byB3ZWVkcyB0aGF0IGFyZSBhbHJlYWR5IGJlaW5n IGV4cGxvcmVkIGJ5IChzYXkpIHRoZSBTSEFLRU4gZWZmb3J0Ljwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QWxzbywgSSdtIG5vdCBjb252aW5jZWQgdGhhdCBk ZWZpbmluZyAmcXVvdDtjYWxsJnF1b3Q7IGlzIG5lZWRlZCBoZXJlLCBnaXZlbiB0aGF0IHdlJ2Qg cHJvYmFibHkgbm90IGdvIG11Y2ggYmV5b25kIHdoYXQncyBpbiBSRkMgMzI2MTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHByZSBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7d2hpdGUtc3BhY2U6 cHJlLXdyYXAiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPkNhbGw6IEEgY2Fs bCBpcyBhbiBpbmZvcm1hbCB0ZXJtIHRoYXQgcmVmZXJzIHRvIHNvbWUgY29tbXVuaWNhdGlvbjwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg YmV0d2VlbiBwZWVycywgZ2VuZXJhbGx5IHNldCB1cCBmb3IgdGhlIHB1cnBvc2VzIG9mIGE8L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG11 bHRpbWVkaWEgY29udmVyc2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkFsc28sIGdpdmVuIHRoZSBkaXNjdXNz aW9uIG9mIHVzYWdlIGZvciBub24tSU5WSVRFLCBJJ2xsIGNoYW5nZSAmcXVvdDtjYWxsJnF1b3Q7 IHRvICZxdW90O3JlcXVlc3QmcXVvdDsgb3IgJnF1b3Q7ZGlhbG9nJnF1b3Q7IHdoZXJlIHRoZSBj b250ZXh0IGlzIG1vcmUgdGhhbiBqdXN0IGFuIGV4YW1wbGUgb2Ygd2hhdCBpcyBsaWtlbHkgdG8g YmUNCiB0aGUgbW9zdCBjb21tb24gY2FzZSAtIElOVklURSBmb3IgYSBwaG9uZSBjYWxsLiA8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkhlbm5pbmc8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNl bnRlciIgc3R5bGU9InRleHQtYWxpZ246Y2VudGVyIj48c3BhbiBsYW5nPSJGUiI+DQo8aHIgc2l6 ZT0iMiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlk PSJ4X2RpdlJwbHlGd2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4gc2lwY29yZSAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxh bmc9IkVOLVVTIj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZndDsNCiBvbiBiZWhhbGYgb2YgQXN2ZXJlbiwgVG9s Z2EgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBo cmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj48c3BhbiBsYW5nPSJFTi1VUyI+dGFz dmVyZW5Ac29udXNuZXQuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDUsIDIwMTcg MTA6MjI6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyZXR0IFRhdGU7IDwvc3Bhbj48c3BhbiBsYW5n PSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRm Lm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQt MDE8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PkkgYWdyZWUgdGhhdCBkZWZpbmluZyB3aGF0IGEgJnF1b3Q7Y2FsbCZxdW90OyBpcyBhIGdvb2Qg aWRlYSBidXQgSSBoYXZlIGEgZGlmZmVyZW50IHRha2Ugb24gd2hhdCBpdCBzaG91bGQgc2F5Ojxi cj4NCjxicj4NCmktJm5ic3A7IEEgJnF1b3Q7Y2FsbCZxdW90OyBpbiB0aGUgY29udGV4dCBvZiB0 aGlzIGRvY3VtZW50IGlzIGEgY29tbXVuaWNhdGlvbiBzZXNzaW9uIGFzIHBlcmNlaXZlZCBieSBh IGh1bWFuIGFnZW50LCBlLmcuIGFzIGluICZxdW90O0kgcmVjZWl2ZWQgYSBjYWxsIGZyb20gbXkg Z3JhbmRtb3RoZXIuJnF1b3Q7LiBJdCBkb2VzIG5vdCBpbXBseSBhbnl0aGluZyBmdXJ0aGVyIGFz IGZhciBhcyBTSVAgaW5mb3JtYXRpb24gZWxlbWVudHMgd2hpY2ggdXN1YWxseSBhcmUgdXNlZCB0 byBjYXJyeQ0KIGNhbGxpbmcgcGFydHkgaWRlbnRpZmljYXRpb24sIGUuZy4gUC1Bc3NlcnRlZC1J ZCwgRnJvbSBoZWFkZXJzLCBhcmUgY29uY2VybmVkLiBJdCBpcyB1cCB0byB0aGUgb3BlcmF0b3Iv bmV0d29yayBwb2xpY3kgaG93IHRvIG1ha2UgYXNzb2NpYXRlIGZ1cnRoZXIgY2FsbHMgd2l0aCB0 aGUgaW5mb3JtYXRpb24vZGVjaXNpb24gZGVyaXZlZCBmcm9tIHVud2FudGVkIGNhbGxzLjxicj4N Cjxicj4NCmlpLSAmcXVvdDtOb25lIG9mIHRoZSBleGlzdGluZyA0eHgsIDV4eCBvciA2eHggcmVz cG9uc2UgY29kZXMgc2lnbmlmeSB0aGF0IGNhbGxzIGZyb20gdGhpcyBjYWxsZXIgYXJlIHVud2Fu dGVkIGJ5IHRoZSBjYWxsZWQgcGFydHkuJnF1b3Q7PGJyPg0KPT0mZ3Q7PGJyPg0KJnF1b3Q7Tm9u ZSBvZiB0aGUgZXhpc3RpbmcgNHh4LCA1eHggb3IgNnh4IHJlc3BvbnNlIGNvZGVzIHNpZ25pZnkg dGhhdCB0aGlzIGNhbGwgaXMgdW53YW50ZWQgYnkgdGhlIGNhbGxlZCBwYXJ0eS4mcXVvdDs8YnI+ DQo8YnI+DQpJIHRoaW5rIGlpLSBpcyBuZWVkZWQgdG8gcmVsaXZlIHRoZSBlbmQgdXNlciBmcm9t IHRoZSBidXJkZW4gb2YgJnF1b3Q7a25vd2luZyB0aGUgYWN0dWFsIGNhbGxlciZxdW90Oy48YnI+ DQo8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRoYW5rcyw8YnI+ DQpUb2xnYTxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQom Z3Q7IEZyb206IHNpcGNvcmUgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFu IGxhbmc9IkVOLVVTIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl0gT24gQmVoYWxmIE9mIEJyZXR0 IFRhdGU8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDE3IDc6NTQgQU08 YnI+DQomZ3Q7IFRvOiA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij48YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMi PnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+PGJyPg0KJmd0OyBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8YnI+DQomZ3Q7IDxicj4NCiZndDsg SGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYWxzbyBhZ3JlZSB0aGF0IGFkZGluZyBzdWNoIGEg cGFyYWdyYXBoIHdvdWxkIGJlIHVzZWZ1bC48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDxicj4NCiZndDsgRm9yIGluc3RhbmNlIGlmIHNv bWVvbmUgZGVzaXJlcyBhIHNlcnZpY2UgdG8gZm9yd2FyZCBhbGwgcmVjZWl2ZWQgc3BhbSBjYWxs cyB0bzxicj4NCiZndDsgYW5vdGhlciBzZXQgb2YgdmljdGltcywgdGhleSB3b3VsZCBsaWtlbHkg bm90IHVzZSBzdWNoIGEgc2VydmljZSBpZiB0aGU8YnI+DQomZ3Q7IGZvcndhcmRpbmcgcGFydHkg bWlnaHQgYWxzbyBnZXQgZmxhZ2dlZCBhcyBwYXJ0IG9mIHRoZSA2NjYgaGFuZGxpbmcuPGJyPg0K PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyAmZ3Q7IEZy b206IHNpcGNvcmUgWzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9 IkVOLVVTIj5tYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPl0gT24gQmVoYWxmIE9mIFBhdWw8YnI+DQom Z3Q7IEt5eml2YXQ8YnI+DQomZ3Q7ICZndDsgU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA0LCAy MDE3IDc6NTEgUE08YnI+DQomZ3Q7ICZndDsgVG86IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj48 c3BhbiBsYW5nPSJFTi1VUyI+c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtz aXBjb3JlXSBDb21tZW50cyBvbjxicj4NCiZndDsgJmd0OyBkcmFmdC1pZXRmLXNpcGNvcmUtc3Rh dHVzLXVud2FudGVkLTAxPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIDEvNC8xNyA1 OjM1IFBNLCA8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48 YSBocmVmPSJtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iPjxzcGFuIGxhbmc9IkVO LVVTIj5tYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7ICZndDsgLVNlY3Rpb24gNCBnZW5lcmFsOjxicj4NCiZndDsgJmd0OyAmZ3Q7IElNTywgaXQg d291bGQgYmUgZ29vZCB0byBoYXZlIGEgcGFyYWdyYXBoIGFkZHJlc3NpbmcgdGhlIHF1ZXN0aW9u IG9mPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhlICZxdW90O2NhbGxpbmcgcGFydHkgbnVtYmVyJnF1 b3Q7IChtZW50aW9uZWQgc2V2ZXJhbCB0aW1lIGluIHRoZSBkb2N1bWVudCk6PGJyPg0KJmd0OyAm Z3Q7ICZndDsgaW5kZWVkLCB0aGlzIGNhbGxpbmcgcGFydHkgbnVtYmVyIGNhbiBiZSBpZGVudGlm aWVkIGJ5IHRoZSB0ZWxlcGhvbmU8YnI+DQomZ3Q7ICZndDsgJmd0OyBudW1iZXIvYWRkcmVzcyBp biB0aGUgRnJvbSBoZWFkZXIgb3IgdGhlIG9uZSBpbiB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBQ LUFzc2VydGVkLUlkZW50aXR5IGhlYWRlciB0aGF0IG1heSBiZSBkaWZmZXJlbnQuIDwvc3Bhbj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkRlcGVuZGluZyBvbiB0aGU8 YnI+DQomZ3Q7ICZndDsgJmd0OyBvbmUgZGlzcGxheWVkIHRvIHRoZSBjYWxsZWQgVUEsIHRoZSA2 NjYgY291bGQgY29uY2VybiBvbmx5IG9uZSBvcjxicj4NCiZndDsgJmd0OyAmZ3Q7IGJvdGggYWRk cmVzc2VzIGRlcGVuZGluZyBvbiBzZXJ2aWNlIHByb3ZpZGVyIGNob2ljZXMuIElmIHdlIHRha2Ug dGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgZXhhbXBsZSBvZiBhIGNhbGwtY2VudGVyIG9yIGFuIElQ QlggaGF2aW5nIHRoZSBoZWFkIG51bWJlciBhbmQgYTxicj4NCiZndDsgJmd0OyAmZ3Q7IHJhbmdl IG9mIHByaXZhdGUgbnVtYmVycywgdGhlIHNlcnZpY2UgcHJvdmlkZXIgY291bGQgaW50ZXJwcmV0 IHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IDY2NiBmcm9tIHRoZSBjYWxsZWQgdXNlciBvbmx5IGZv ciB0aGUgcHJpdmF0ZSBudW1iZXIgKGluIHRoZSBGcm9tPGJyPg0KJmd0OyAmZ3Q7ICZndDsgaGVh ZGVyKSBvciBmb3IgdGhlIHdob2xlIHBvb2wgKFAtQXNzZXJ0ZWQtSWRlbnRpdHkpLiBJIHN1Z2dl c3QgdG88YnI+DQomZ3Q7ICZndDsgJmd0OyBoYXZlIGEgcGFyYWdyYXBoIHRvIGhpZ2hsaWdodCB0 aGlzIHBvaW50Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJbnRlcmVzdGluZyBwb2lu dC4gSWYgdGhlIFBBSUQgaXMgZGlmZmVyZW50IGZyb20gdGhlIG51bWJlciBkaXNwbGF5ZWQ8YnI+ DQomZ3Q7ICZndDsgdG88YnI+DQomZ3Q7IHRoZTxicj4NCiZndDsgJmd0OyBjYWxsZWUsIGFuZCB0 aGUgY2FsbGVlIHJlamVjdHMgdGhlIGNhbGwgd2l0aG91dCBhbnN3ZXJpbmcsIGhvdyBzaG91bGQ8 YnI+DQomZ3Q7ICZxdW90O2JsYW1lJnF1b3Q7PGJyPg0KJmd0OyAmZ3Q7IGJlIGFzc2lnbmVkPyBG cm9tIHRoZSBjYWxsbGVlJ3MgcGVyc3BlY3RpdmUgdGhlIGNvbXBsYWludCBpcyAqYWJvdXQqPGJy Pg0KJmd0OyAmZ3Q7IHRoZSBudW1iZXIgaGUgc2F3LCByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGlk ZW50aXR5IG9mIHRoZSBhY3R1YWwgY2FsbGVyIHdhcy48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgc2lw Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmci PjxzcGFuIGxhbmc9IkVOLVVTIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxicj4NCiZndDsgJmd0OyA8L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij48YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3NpcGNvcmUmYW1wO2Q9RGdJQ0FnJmFtcDtjPXkwaDBvbUNlMGpBVUdyNGdB UTAyRncmYW1wO3I9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZh bXA7bT1UeVEtWW1pTDhiY0hwQjRPQjVzZ2g1UXg4RjBTMXpFSmpQWThIaDA0Q1BvJmFtcDtzPU9a b3ZkeERtcml4U0tiRkpDRXdNSHlab2pwVTh1WWVVOWtvMUxZYUM1TlkmYW1wO2U9Ij48c3BhbiBs YW5nPSJFTi1VUyI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0 dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zaXBjb3JlJmFtcDtkPURnSUNB ZyZhbXA7Yz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JmFtcDtyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4 bERVMVhlSElZUkhmYXJwazRNSzU5UkUmYW1wO209VHlRLVltaUw4YmNIcEI0T0I1c2doNVF4OEYw UzF6RUpqUFk4SGgwNENQbyZhbXA7cz1PWm92ZHhEbXJpeFNLYkZKQ0V3TUh5Wm9qcFU4dVllVTlr bzFMWWFDNU5ZJmFtcDtlPTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij4NCjxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPjxh IGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+c2lwY29y ZUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij48YnI+DQomZ3Q7IDwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1o dHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZhbXA7ZD1EZ0lD QWcmYW1wO2M9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZhbXA7cj1GSmNWb0RrV001RWlWY1YwUmVY OGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJmFtcDttPVR5US1ZbWlMOGJjSHBCNE9CNXNnaDVReDhG MFMxekVKalBZOEhoMDRDUG8mYW1wO3M9T1pvdmR4RG1yaXhTS2JGSkNFd01IeVpvanBVOHVZZVU5 a28xTFlhQzVOWSZhbXA7ZT0iPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xp c3RpbmZvX3NpcGNvcmUmYW1wO2Q9RGdJQ0FnJmFtcDtjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncm YW1wO3I9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZhbXA7bT1U eVEtWW1pTDhiY0hwQjRPQjVzZ2g1UXg4RjBTMXpFSmpQWThIaDA0Q1BvJmFtcDtzPU9ab3ZkeERt cml4U0tiRkpDRXdNSHlab2pwVTh1WWVVOWtvMUxZYUM1TlkmYW1wO2U9PC9zcGFuPjwvYT48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPg0KPGJyPg0KPGJyPg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxp bmcgbGlzdDxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+ c2lwY29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0Ij48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NpcGNvcmUmYW1wO2Q9RGdJ Q0FnJmFtcDtjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmYW1wO3I9RkpjVm9Ea1dNNUVpVmNWMFJl WDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZhbXA7bT1UeVEtWW1pTDhiY0hwQjRPQjVzZ2g1UXg4 RjBTMXpFSmpQWThIaDA0Q1BvJmFtcDtzPU9ab3ZkeERtcml4U0tiRkpDRXdNSHlab2pwVTh1WWVV OWtvMUxZYUM1TlkmYW1wO2U9Ij5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NpcGNvcmUmYW1w O2Q9RGdJQ0FnJmFtcDtjPXkwaDBvbUNlMGpBVUdyNGdBUTAyRncmYW1wO3I9RkpjVm9Ea1dNNUVp VmNWMFJlWDhsRFUxWGVISVlSSGZhcnBrNE1LNTlSRSZhbXA7bT1UeVEtWW1pTDhiY0hwQjRPQjVz Z2g1UXg4RjBTMXpFSmpQWThIaDA0Q1BvJmFtcDtzPU9ab3ZkeERtcml4U0tiRkpDRXdNSHlab2pw VTh1WWVVOWtvMUxZYUM1TlkmYW1wO2U9PC9hPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PG86cD48L286 cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50 ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48 c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4g bGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZv ciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3Uu PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY1PR09MB06347595D9D61B759E752827EA790CY1PR09MB0634namp_-- From nobody Thu Jan 12 12:41:09 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1A21294C0 for ; Thu, 12 Jan 2017 12:41:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdizo-2IYYVY for ; Thu, 12 Jan 2017 12:41:05 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46781294B7 for ; Thu, 12 Jan 2017 12:41:05 -0800 (PST) Received: from pps.filterd (m0102176.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CKYAQ8008337; Thu, 12 Jan 2017 20:41:04 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0015.outbound.protection.outlook.com [23.103.198.15]) by mx0a-0024ed01.pphosted.com with ESMTP id 27tqchkkay-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 20:41:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8BDuEfb8msl9/Pya18o4e48xZ3ohTKQA1+T+AVN4wYQ=; b=DG0bUhbjvhCOzzon/0AC7fgx3cI8UH+T1nfohlbJNeexNwykGflo6+kaYar/DY63LZNonbJtDABuceEAgKBjNqFLpLWyDWf5A7ZegSQRduLn9GUyoTDG+nQL/TGaTqm/UisUl8KLpnPH0NCdQeTOp9CY+XEHQI26sTn4rgLA0PM= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 20:41:02 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 20:41:02 +0000 From: Henning Schulzrinne To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAFeq4AABk5kgAABTb+gAAQDLCSACJvigAABLbYgAEztYPQ Date: Thu, 12 Jan 2017 20:41:02 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: dd6cb70d-49d2-46d7-7e79-08d43b2b52c9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:guqZMngQB3Isj/kc6xLfjGBBCEsirNrRmECC1ULotMKXn365beygXF0FFv3BwsmvbbPisQnbWVi+8nCLL94Exf8gOpyLpeQo0HSnMyKjgoX0JObykLWZHXRYV6etkrzkpKl48/74yvPP51xGKIiyBlkg3TI5n8l7RgH1gKb8XuyfgcuJj2jZPKnAZn9m0vAV0rjkKGzcfKzjz2u6+I80ZubvcOKnut6ESCR39sx3MUWHE8U+Ih0TWunE5iZzqR7T0QNO6t/lgH6Cd7lH1OoXInIzBHLfv9oNX5eC859JRBYYwFnALjRlCui4rfOJ9PzlGe2HOSwjz7ZTBZzMKv8xeFkabzo1a59n8EjsiStj9FUQcjuFW788pQ1DCj4pdeX7OlTH66QFGmnOz28LCM6pRj1p+X5e55M1WXKQecs9oIKpt6Wmx9i7VpPL7XPOsH3k+r1VRrIW4Ea65w6/MCK3hw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(13464003)(24454002)(199003)(189002)(25786008)(122556002)(189998001)(107886002)(5001770100001)(97736004)(3280700002)(8666007)(229853002)(77096006)(99286003)(55016002)(86362001)(6436002)(575784001)(2501003)(38730400001)(2906002)(68736007)(6306002)(6506006)(3846002)(6116002)(101416001)(102836003)(2950100002)(5660300001)(7736002)(66066001)(3660700001)(305945005)(9686003)(54356999)(8936002)(2900100001)(33656002)(92566002)(230783001)(93886004)(7696004)(8676002)(50986999)(76176999)(105586002)(81156014)(74316002)(106356001)(81166006)(60054002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 20:41:02.2590 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:41:08 -0000 Any suggested wording? I think, in general, it will be impossible for the c= alled party's carrier to know what the decision is based on. Even content c= an be misleading - I might think it's a sales call, but it turns out to be = a product defect recall. (I suspect you've gotten calls starting with "This= is not a sales call.", which usually means that I definitely don't want to= talk to the non-sales-caller since it's most likely a scam instead...) If the 666 is used for statistical call filtering, we have to rely on the w= isdom of the crowd, and assume some fraction of both false negatives and po= sitives. As Martin has indicated earlier, maybe experience will indicate th= at mid-call 666's are better indicators, but that's all guesswork so far. Thus, to avoid too many "in some cases, but in other cases" sentences, plea= se send text if you have specific actionable implementer guidance. Note that the text currently already alludes to the difference ("Receiving = system could decide to treat..."), so I think the general angle has been co= vered. Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Friday, January 06, 2017 12:43 PM To: sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 On 1/6/17 10:28 AM, marianne.mohali@orange.com wrote: > Hi, > > To reflect the question of the interpretation of the 666 response=20 > interpretation when the caller has several identities used for this=20 > call (ie. From and P-Asserted-Identity are different) or call=20 > forwarding/call transfer use cases for which it has to be discussed=20 > which party should be considered has a fraudulent (ie. the calling=20 > party or the diverting party or both ?) ; I propose to add the following = text: > > This document defines a mechanism by which a called party can reject=20 > an unwanted call without consideration of the calling party=20 > identification that remain to the service provider policy. Indeed, the=20 > calling party identity may be reflected in different way for a direct=20 > call or after a diverting service in P-Asserted-Identity, From,=20 > History-Info or any concurrent header field that can be present at the=20 > same time in a SIP message. > > Those questions are real issues for operators and implementors and=20 > they are a weakness that fraudulent callers could use to bypass the mecha= nism. ISTM there are two different cases here, and the identity implications diff= er between them: 1) the callee rejects the call without consideration of the content of the = call. Instead, the rejection is based solely on metadata about the call tha= t is available to the callee - e.g., callerid information presented, classi= fication information, possibly time of day. It might also include informati= on provided locally by the phone (e.g. from the local address book). In this case the actual caller may be blameless. So care must be taken in a= ssociating the rejection with the caller. 2) the callee rejects the call after answering, based on the media content = of the call. In this case the rejection clearly applies to the caller even if the callee= doesn't know the caller's identity. It may be difficult to distinguish between these. Certainly using 666 as a = response code must be case (1). But using 666 as a reason isn't necessarily= case (2) - the callee may be slow and reject based on metadata after answe= ring, or may use a combination of content and metadata in making that decis= ion. This is not something that can be resolved in this document, but it may be = worthwhile to identify that these issues exist and must be considered by th= ose who act on 666 responses. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dw6-F-EQyZVD_u9zlhZF0qJKOYhLoEynLstyHM8ce6l= k&s=3Dx7kUOPzC2LyOOaY-S0KpNT5m0dU-lrQgNXq2eiQpWpE&e=3D=20 From nobody Thu Jan 12 12:43:34 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 658571294CF for ; Thu, 12 Jan 2017 12:43:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148425381341.2883.9930015504833748667.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 12:43:33 -0800 From: IETF Secretariat Archived-At: Subject: [sipcore] Milestones changed for sipcore WG X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:43:33 -0000 Changed milestone "Request publication of DNS look-up procedures for dual-stack client and server handling of SIP URIs", resolved as "Done". URL: https://datatracker.ietf.org/wg/sipcore/charter/ From nobody Thu Jan 12 12:48:50 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 172C612948C for ; Thu, 12 Jan 2017 12:48:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148425412909.2979.2619781661738572010.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 12:48:49 -0800 From: IETF Secretariat Archived-At: Subject: [sipcore] Milestones changed for sipcore WG X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:48:49 -0000 Changed milestone "Request publication of a SIP response code for unwanted communications ", set state to active from review, accepting new milestone. Changed milestone "Request publication of a mechanism for labeling the nature of SIP calls", set state to active from review, accepting new milestone. Changed milestone "Request publication of a clarification of the use of Content-ID as a SIP header field", set state to active from review, accepting new milestone. Changed milestone "Request publication of a clarification of the use of the "name-addr" production in SIP header fields", set state to active from review, accepting new milestone. Changed milestone "Request publication of mechanisms for rapid dual-stack protocol selection in SIP", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/sipcore/charter/ From nobody Thu Jan 12 13:02:10 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5162E1294F7 for ; Thu, 12 Jan 2017 13:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.098 X-Spam-Level: X-Spam-Status: No, score=-5.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwmce_HtNbv6 for ; Thu, 12 Jan 2017 13:02:02 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413BA1294B7 for ; Thu, 12 Jan 2017 13:02:02 -0800 (PST) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0CL20o9000115 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Jan 2017 15:02:00 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: "'SIPCORE'" From: Adam Roach Message-ID: Date: Thu, 12 Jan 2017 15:01:59 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------8F5CC7099A0E78D34CF2DD84" Archived-At: Subject: [sipcore] New SIPCORE Milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:02:08 -0000 This is a multi-part message in MIME format. --------------8F5CC7099A0E78D34CF2DD84 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit [as chair] Based on feedback from the working group, and in consultation with our area director, we have added five new milestones (including the one already implied by our adoption of draft-ietf-sipcore-status-unwanted) to our charter: Jan 2017 Request publication of a SIP response code for unwanted communications Apr 2017 Request publication of a mechanism for labeling the nature of SIP calls May 2017 Request publication of a clarification of the use of Content-ID as a SIP header field May 2017 Request publication of a clarification of the use of the "name-addr" production in SIP header fields Dec 2017 Request publication of mechanisms for rapid dual-stack protocol selection in SIP ("Happy Eyeballs for SIP") You can view these milestones, along with related (although not necessarily adopted) drafts on the SIPCORE charter page: https://datatracker.ietf.org/wg/sipcore/charter/ If you have any feedback about the milestones and their associated dates, please discuss them on this mailing list. Thanks! I'll note that the chairs are aware of and tracking discussions regarding SIP Authorization, SIP over DTLS, and "Half Outbound," but feel that the conversation is not yet far enough along to warrant milestones for this work. /a --------------8F5CC7099A0E78D34CF2DD84 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

[as chair]

Based on feedback from the working group, and in consultation with our area director, we have added five new milestones (including the one already implied by our adoption of draft-ietf-sipcore-status-unwanted) to our charter:

Jan 2017 Request publication of a SIP response code for unwanted communications
Apr 2017 Request publication of a mechanism for labeling the nature of SIP calls
May 2017 Request publication of a clarification of the use of Content-ID as a SIP header field
May 2017 Request publication of a clarification of the use of the "name-addr" production in SIP header fields
Dec 2017 Request publication of mechanisms for rapid dual-stack protocol selection in SIP ("Happy Eyeballs for SIP")

You can view these milestones, along with related (although not necessarily adopted) drafts on the SIPCORE charter page:

https://datatracker.ietf.org/wg/sipcore/charter/

If you have any feedback about the milestones and their associated dates, please discuss them on this mailing list. Thanks!

I'll note that the chairs are aware of and tracking discussions regarding SIP Authorization, SIP over DTLS, and "Half Outbound," but feel that the conversation is not yet far enough along to warrant milestones for this work.

/a

--------------8F5CC7099A0E78D34CF2DD84-- From nobody Thu Jan 12 13:35:20 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB5A129443 for ; Thu, 12 Jan 2017 13:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urzRh8M3JnUE for ; Thu, 12 Jan 2017 13:35:13 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 918E6129503 for ; Thu, 12 Jan 2017 13:35:02 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CLZ0tM031155; Thu, 12 Jan 2017 21:35:00 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0015.outbound.protection.outlook.com [23.103.198.15]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tsgg2x4m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 21:35:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=La62l+BKhil0SVgHRUvSt1Ohh3w+Xy7rwKaSy72nsvU=; b=GnclhoVz+vCl5ZmiRZkwTaJYevFh9ZdGsvCHdjJ8cbvn7zEeMM0FFATmGza/bu/XPgL7ApLA4pC8rZPBcLmkxqwNgpzhhpgp8T5q7gMNvnsws/ZscFIGMG1ekyUAE8z+fhVBbnzkodfySUPrP2PhI2C97wQEuPhyFbiuMB0LyUI= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 21:34:58 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 21:34:58 +0000 From: Henning Schulzrinne To: "marianne.mohali@orange.com" , "Asveren, Tolga" , Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAFeq4AABk5kgAABTb+gAAQDLCSACJvigABOmM5YA== Date: Thu, 12 Jan 2017 21:34:58 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 3b73eebf-27d0-4107-3e93-08d43b32db70 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:ffjgpLKcEQHS6EQ8sTZR+NZCjVWne6fd/BHnQj3zF+05wo0ihz7IEp26+lRgZXGxY3pWt/SZDWwVGi91vno7RMJNbFIB5odUq5TdSPwdhHw5BKMzBGTnrBd5+iqUwFkY3s3yV7KfovU7mRkTaLr/ZtdXuqgQ2CfVZTPKZ1yAB1Vwd2i35IbZFykvRH96V/iLbWa6kIqtl0qugNhdWFMl/HeK/iwe1L09DgJnedf0Pv46JQTz2PJByuf6Zf3W1TuKqlKo39+2Y5VT46w0d9LKwB+M5vkm1JcTLr2BEKHkSwwSoxkIfTcpQz3tQkK7SxALYGP1Tl3d4bFV+a4E71a/IuT2a19Tx0xacBoVYbVVSBoKXeYOg6aOxMm8LTXrpayJeW32yxEZNRxe70G17TZqCR9UHqGwIrDKUjlbU2hZACjc5EG0m6PeHu9vkzcGKaPFtVhBLKu5pTDzZPHF/Us+Dg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(199003)(189002)(107886002)(86362001)(790700001)(2906002)(3660700001)(5001770100001)(8936002)(3846002)(6116002)(102836003)(97736004)(7736002)(122556002)(8676002)(74316002)(19609705001)(189998001)(68736007)(3280700002)(99286003)(6506006)(2900100001)(76176999)(54356999)(229853002)(92566002)(105586002)(2950100002)(6436002)(101416001)(7696004)(106356001)(55016002)(33656002)(25786008)(9686003)(93886004)(230783001)(81166006)(50986999)(54896002)(81156014)(6306002)(2501003)(5660300001)(77096006)(66066001)(38730400001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634C491FF879A459BF0DB45EA790CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 21:34:58.0861 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:35:16 -0000 --_000_CY1PR09MB0634C491FF879A459BF0DB45EA790CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have added a sentence in the SIP URI paragraph: "The calling party may be identified in different locations in the SIP head= er, e.g., the From header field, P-Asserted-Identity or History-Info, and m= ay also be affected by diverting services." Henning From: marianne.mohali@orange.com [mailto:marianne.mohali@orange.com] Sent: Friday, January 06, 2017 10:28 AM To: Henning Schulzrinne ; Asveren, Tolga ; Brett Tate ; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpret= ation when the caller has several identities used for this call (ie. From a= nd P-Asserted-Identity are different) or call forwarding/call transfer use = cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I = propose to add the following text: This document defines a mechanism by which a called party can reject an unw= anted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity ma= y be reflected in different way for a direct call or after a diverting serv= ice in P-Asserted-Identity, From, History-Info or any concurrent header fie= ld that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are= a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --_000_CY1PR09MB0634C491FF879A459BF0DB45EA790CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have added a sentence in the SIP UR= I paragraph:

 

“The calling party may be ident= ified in different locations in the SIP header, e.g., the From header field= , P-Asserted-Identity or History-Info, and may also be affected by diverting services.”

 

Henning

 

From: marianne.mohali@orange.com [ma= ilto:marianne.mohali@orange.com]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; Asveren= , Tolga <tasveren@sonusnet.com>; Brett Tate <brett@broadsoft.com&g= t;; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

To reflect the ques= tion of the interpretation of the 666 response interpretation when the call= er has several identities used for this call (ie. From and P-Asserted-Ident= ity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be = considered has a fraudulent (ie. the calling party or the diverting party o= r both ?) ; I propose to add the following text:

This document defin= es a mechanism by which a called party can reject an unwanted call without = consideration of the calling party identification that remain to the servic= e provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or afte= r a diverting service in P-Asserted-Identity, From, History-Info or any con= current header field that can be present at the same time in a SIP message.=

 

Those questions are= real issues for operators and implementors and they are a weakness that fr= audulent callers could use to bypass the mechanism.

 

BR,

Marianne

 
--_000_CY1PR09MB0634C491FF879A459BF0DB45EA790CY1PR09MB0634namp_-- From nobody Thu Jan 12 13:38:43 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E00A1294B7 for ; Thu, 12 Jan 2017 13:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bBjDrTczSIU for ; Thu, 12 Jan 2017 13:38:40 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA69129443 for ; Thu, 12 Jan 2017 13:38:39 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CLYrLQ031146; Thu, 12 Jan 2017 21:38:38 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0019.outbound.protection.outlook.com [23.103.198.19]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tsgg2x6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 21:38:38 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BbJQz7k+jsK+guw8O5ZVvHiCLw1LfCXxSwmg3yjGreE=; b=LESX+VDUKEodgl4JOdGjExAMrx1qwGu/7s9+Ds4seSZ4tjV5TzGnIR+uv8EOTjaeL4YOGTSRr9F7GoDyT9Dy5xQ2HEEahbN98X6hYMrosYEoGFFpLwBFMUy551mlN6hIvKkDB5AVQLz/CkXfLPDvP1f7AJXx7tbcPVHoeZqnONA= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 21:38:37 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 21:38:37 +0000 From: Henning Schulzrinne To: "marianne.mohali@orange.com" , "sipcore@ietf.org" Thread-Topic: Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAzSmHSABZRBYABR3TWkA== Date: Thu, 12 Jan 2017 21:38:36 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <25465_1483716505_586FB799_25465_5025_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <25465_1483716505_586FB799_25465_5025_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A4923@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: ca088bdf-6f18-4aa9-4431-08d43b335de5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:keHrZu4vzPdbIRd7RWHU+7WdiIIRx9cvcRIVujnKnDvNVtmCqjVRdSfYQR+E/bgBiCDjRJEUOH5y+CGr54vnkSJ+2guprKyyQroQnRn+ZNfzouD2eHKh2KMLLvkIYcwmWWLyq8iKDGpVsEp0OfbtDUFTnkAaFZRaaEzHtO2lg8RVAQokRtV4GCfq/CLeVzCElwxoscizjYkB1dMp4gEOBVgUmKlldIH1KH2FDhrHLGOdi/UFy+rgsEtQiv4jRMQTGKZPUV4HpuSqzgAWs3SUgp56jTGN/6RpV3U0xKyuSQYIWQKNFnoMYuinDxHVOIT0/ZbKmpHlQuXk1kUCpNXhiiI8YqK7vVEP1R4aeP0SrNqMi/4irfPwK19Wgufb3gcdsM1XvdH2EkZvhAcbMjlWAtjqs0SJ/ytMi3jZw6XWQCssFWGlVAwwyKLwyDiUljobT0+oD7w/gWDfhpwTgdHvMA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(377454003)(199003)(189002)(107886002)(86362001)(790700001)(2906002)(3660700001)(5001770100001)(8936002)(3846002)(6116002)(102836003)(97736004)(7736002)(122556002)(8676002)(74316002)(19609705001)(189998001)(68736007)(3280700002)(99286003)(6506006)(2900100001)(76176999)(54356999)(229853002)(92566002)(105586002)(2950100002)(6436002)(101416001)(7696004)(106356001)(55016002)(33656002)(25786008)(9686003)(230783001)(81166006)(50986999)(54896002)(81156014)(6306002)(2501003)(5660300001)(77096006)(66066001)(38730400001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634C462589E289AE40AD209EA790CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 21:38:36.9668 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:38:42 -0000 --_000_CY1PR09MB0634C462589E289AE40AD209EA790CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The term "caller identity" is now used instead of "number". From: marianne.mohali@orange.com [mailto:marianne.mohali@orange.com] Sent: Friday, January 06, 2017 10:28 AM To: Henning Schulzrinne ; sipcore@ietf.org Subject: RE: Comments on draft-ietf-sipcore-status-unwanted-01 I am in favor of terms "caller identity" or "calling party identity". BR, Marianne --_000_CY1PR09MB0634C462589E289AE40AD209EA790CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The term “caller identity”= ; is now used instead of “number”.

 

From: marianne.mohali@orange.com [ma= ilto:marianne.mohali@orange.com]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore= @ietf.org
Subject: RE: Comments on draft-ietf-sipcore-status-unwanted-01<= /o:p>

 

I am in favor of terms "caller i= dentity" or "calling party identity".

 

BR,

Marianne

 
--_000_CY1PR09MB0634C462589E289AE40AD209EA790CY1PR09MB0634namp_-- From nobody Thu Jan 12 13:47:02 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848F1129443 for ; Thu, 12 Jan 2017 13:47:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dWbS7KpuO9sn for ; Thu, 12 Jan 2017 13:46:56 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 639381289C4 for ; Thu, 12 Jan 2017 13:46:56 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0CLYqiS017541; Thu, 12 Jan 2017 21:46:55 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0b-0024ed01.pphosted.com with ESMTP id 27tra2ay3u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 12 Jan 2017 21:46:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5Zc/dD86rTdXZckADUv06jl1JbWqKr73mWjBjlODIWs=; b=V6eVcwzX1+ZhrweWmOpNNlxJtD9yFajjwRw0cDf8PszI0KDg4CngRGxQQJug7zXOUgK1iOHXk49xdYdPDPp8Fe7dNqZ6gQohut2BKxIPTIoCrK1RewEK9PWqIZN0DojgfUCbuysPCdBjdguBcnAiWS+I+r8uuTt1Jc2mMbSOm1E= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 12 Jan 2017 21:46:53 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Thu, 12 Jan 2017 21:46:53 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJm1+lvDTTT21QxQfGC4OLjh1QSQAAFeq4AABk5kgAABTb+gAAQDLCSABS1/oABSIi5cA== Date: Thu, 12 Jan 2017 21:46:53 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 2f5bb6b3-bcb4-458a-bd5d-08d43b3485ac x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:CqQxmB1LSryZ9osn8V0LjADMYNv5e1jCxDTNftAEUaVEaiuItWQo7cmqpvXGEOdhgB1eyg4TJ38gbY2p46/lj3QCop5m/Lm54vz5lh0e5S8rwnAOa+i0HV+uMWKqtez7BQ0XcHBbePOo98O4f9xARXoISKSypLPqeH7zM7ne/PsD7AZI+FmtUmY/7EcKg2WNgf2Ald45Uii9702AbEFLbtjFg26SD/wtb4s0lEJt6Z2g1vT8Bl9ZybaQMGD7t42fd+Tl65ZSEbe3OgZ4/JalTxegA0nnPALXp1jcayfOaSWZaXc1OBI3Q4zYphg2C2nF2rZSgACrimOm7MnLKgQAEu2IAp/8c0N4JJI0F2OEIWXxvezbEvPCU4XeKMooBWiH+IKeMViUfbVT/Pf6BdVFxsOrNFp22I2LUT0nIedl1lwnhj4NiKjFuOkgRTIlQg0YNDymOP8pW0LUEKbqNekuLg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524)(18271650672692)(21748063052155)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 018577E36E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(24454002)(189002)(199003)(377454003)(13464003)(9686003)(54356999)(8936002)(7906003)(3660700001)(236005)(2950100002)(102836003)(5660300001)(7736002)(3846002)(6116002)(101416001)(66066001)(790700001)(76176999)(8676002)(50986999)(230783001)(7696004)(93886004)(81166006)(74316002)(106356001)(81156014)(105586002)(33656002)(2900100001)(92566002)(107886002)(122556002)(189998001)(5001770100001)(97736004)(25786008)(2906002)(68736007)(6306002)(54896002)(6506006)(575784001)(2501003)(6436002)(99286003)(55016002)(229853002)(86362001)(77096006)(3280700002)(38730400001)(19609705001)(606005)(478054002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634CD4233B27CB89422925EEA790CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jan 2017 21:46:53.1730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-12_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:47:00 -0000 --_000_CY1PR09MB0634CD4233B27CB89422925EEA790CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The suggested wording for the "None" sentence has been included (with the o= ther change that we're now talking about SIP requests). As to the IM vs. call, I admit that I find it hard to conjure up a realisti= c use case. I do sometimes tell charities to send me their pitch by postal = mail (to avoid being scammed by impostors, among other reasons), but I doub= t that a button would be useful, or that I'd want to hear from them by IM. On the other hand, a facility to only be contacted by IM and never by voice= will be welcomed by all teenagers, so maybe there's an opportunity here fo= r future work. Henning From: Asveren, Tolga [mailto:tasveren@sonusnet.com] Sent: Friday, January 06, 2017 3:55 AM To: Henning Schulzrinne ; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I think there is a difference between what "a call" means for end-user and = for the network: For the human agent, it is really nothing more than "Grandma called me". Fo= r the network, all the aspects you mentioned would come into play, e.g . wh= ich SIP information elements to use to identify the calling party etc.. It = could be useful to state this clearly. I agree that the definition of "Call" from RFC3261" seems adequate as far a= s human agent is concerned. I also agree that there is no need to artificia= lly limit the applicability just to "calls" -although I believe this would = cover 99% [99.9% if I dare to say] of the use cases-. It could be good to = continue using the term "call", reference RFC3261 definition of a "call" an= d add aa sentence along the lines of: "It should be noted that "666 unwanted" response code can be used for any S= IP request as long as it results a human agent observable stimulus, e.g. au= dial, visual or otherwise, on which the human agent can express his decisio= n to classify it as "unwanted". I think the proper meaning of "666 unwanted" is "the human agent considers = this particular call as unwanted" rather than "the human agent does not wan= t any further calls from this caller". It will be the network decision what= actions will be taken based on this input. Therefore, I think the current = wording in the draft should be changed as indicated in ii- below: "None of the existing 4xx, 5xx or 6xx response codes signify that calls fro= m this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." On another note: Is there a need to supply additional information as far as= different session types are concerned, e.g. audio call v.s. video call v.s= . IM? There could be situations where this is useful, e.g. human agent is f= ine with IM but does not want voice calls from a certain calling party. OTO= H, I think this again should be handled by the network itself and the chang= e I suggested above would be helpful in this sense as well: 666 means that = human agent considers this particular session as unwanted. It does not tell= anything more as far as other sessions of the same type or of other sessio= n types are concerned. He would communicate his choices regarding how this = information needs to be treated by other means, e.g. via a Web Portal, if s= uch a a service is provided by the operator. Thanks, Tolga From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 05, 2017 6:14 PM To: Asveren, Tolga >; B= rett Tate >; sipcore@ietf.o= rg Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 On (i), I agree that we don't want to get into what information is being us= ed, given that the entity most likely to use the 666 information, i.e., the= terminating carrier, is also the one deciding how caller identity is being= presented to the user (PAI, From, etc.). Tastes may differ, but I don't see how we can say much that's useful to imp= lementors here, without getting into weeds that are already being explored = by (say) the SHAKEN effort. Also, I'm not convinced that defining "call" is needed here, given that we'= d probably not go much beyond what's in RFC 3261: Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Also, given the discussion of usage for non-INVITE, I'll change "call" to "= request" or "dialog" where the context is more than just an example of what= is likely to be the most common case - INVITE for a phone call. Henning ________________________________ From: sipcore > o= n behalf of Asveren, Tolga > Sent: Thursday, January 5, 2017 10:22:55 AM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I agree that defining what a "call" is a good idea but I have a different t= ake on what it should say: i- A "call" in the context of this document is a communication session as = perceived by a human agent, e.g. as in "I received a call from my grandmoth= er.". It does not imply anything further as far as SIP information elements= which usually are used to carry calling party identification, e.g. P-Asser= ted-Id, From headers, are concerned. It is up to the operator/network polic= y how to make associate further calls with the information/decision derived= from unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls= from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing th= e actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > Hi, > > I also agree that adding such a paragraph would be useful. > > For instance if someone desires a service to forward all received spam ca= lls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller= was. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5E= iVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh= 04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiV= cV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04= CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CP= o&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D --_000_CY1PR09MB0634CD4233B27CB89422925EEA790CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The suggested wording for the “= None” sentence has been included (with the other change that we’= ;re now talking about SIP requests).

 

As to the IM vs. call, I admit that I= find it hard to conjure up a realistic use case. I do sometimes tell chari= ties to send me their pitch by postal mail (to avoid being scammed by impostors, among other reasons), but I doubt that a= button would be useful, or that I’d want to hear from them by IM.

 

On the other hand, a facility to only= be contacted by IM and never by voice will be welcomed by all teenagers, s= o maybe there’s an opportunity here for future work.

 

Henning

 

From: Asveren, Tolga [mailto:tasvere= n@sonusnet.com]
Sent: Friday, January 06, 2017 3:55 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore= @ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I think there is a difference between what “a= call” means for end-user and for the network:

For the human agent, it is really nothing more than= “Grandma called me”. For the network, all the aspects you ment= ioned would come into play, e.g . which SIP information elements to use to identify the calling party etc.. It could be useful to state thi= s clearly.

 

I agree that the definition of “Call” f= rom RFC3261” seems adequate as far as human agent is concerned. I als= o agree that there is no need to artificially limit the applicability just to “calls” -although I believe this would cover 99%  = ;[99.9% if I dare to say] of the use cases-. It could be good to continue u= sing the term “call”, reference RFC3261 definition of a “= call” and add aa sentence along the lines of:

“It should be noted that “666 unwanted&= #8221; response code can be used for any SIP request as long as it results = a human agent observable stimulus, e.g. audial, visual or otherwise, on which the human agent can express his decision to classify it as “= ;unwanted”.

 

I think the proper meaning of “666 unwanted&#= 8221; is “the human agent considers this particular call as unwanted&= #8221; rather than “the human agent does not want any further calls f= rom this caller”. It will be the network decision what actions will be t= aken based on this input. Therefore, I think the current wording in the dra= ft should be changed as indicated in ii- below:

"None of the existing 4xx, 5xx or 6xx response= codes signify that calls from this caller are unwanted by the called party= ."

=3D=3D>

"None of the existing 4xx, 5xx or 6xx response= codes signify that this call is unwanted by the called party."

 

On another note: Is there a need to supply addition= al information as far as different session types are concerned, e.g. audio = call v.s. video call v.s. IM? There could be situations where this is useful, e.g. human agent is fine with IM but does not want v= oice calls from a certain calling party. OTOH, I think this again should be= handled by the network itself and the change I suggested above would be he= lpful in this sense as well: 666 means that human agent considers this particular session as unwanted. It d= oes not tell anything more as far as other sessions of the same type or of = other session types are concerned. He would communicate his choices regardi= ng how this information needs to be treated by other means, e.g. via a Web Portal, if such a a service is p= rovided by the operator.

 

Thanks,

Tolga

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov<= /a>]
Sent: Thursday, January 05, 2017 6:14 PM
To: Asveren, Tolga <tasv= eren@sonusnet.com>; Brett Tate <brett@broadsoft.com>; sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

O= n (i), I agree that we don't want to get into what information is being use= d, given that the entity most likely to use the 666 information, i.e., the = terminating carrier, is also the one deciding how caller identity is being presented to the user (PAI, From, etc.).=

<= o:p> 

T= astes may differ, but I don't see how we can say much that's useful to impl= ementors here, without getting into weeds that are already being explored b= y (say) the SHAKEN effort.

<= o:p> 

A= lso, I'm not convinced that defining "call" is needed here, given= that we'd probably not go much beyond what's in RFC 3261:

<= o:p> 

Call: A call is an informal term that refers to some communicatio=
n
       =
  between peers, generally set up for the purposes of a
       =
  multimedia conversation.

Also, given the discussion of usage for non-INVITE, I'll= change "call" to "request" or "dialog" where= the context is more than just an example of what is likely to be the most = common case - INVITE for a phone call.

<= o:p> 

H= enning

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of Asveren, Tolga <t= asveren@sonusnet.com>
Sent: Thursday, January 5, 2017 10:22:55 AM
To: Brett Tate; sipcore@ietf.org=
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I agree that defini= ng what a "call" is a good idea but I have a different take on wh= at it should say:

i-  A "call" in the context of this document is a communicat= ion session as perceived by a human agent, e.g. as in "I received a ca= ll from my grandmother.". It does not imply anything further as far as= SIP information elements which usually are used to carry calling party identification, e.g. P-Asserted-Id, From headers, are concer= ned. It is up to the operator/network policy how to make associate further = calls with the information/decision derived from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx response codes signify that = calls from this caller are unwanted by the called party."
=3D=3D>
"None of the existing 4xx, 5xx or 6xx response codes signify that this= call is unwanted by the called party."

I think ii- is needed to relive the end user from the burden of "knowi= ng the actual caller".

Thanks,
Tolga

> -----Original Message-----
> From: sipcore [mailto:sipc= ore-bounces@ietf.org] On Behalf Of Brett Tate
> Sent: Thursday, January 05, 2017 7:54 AM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-= 01
>
> Hi,
>
> I also agree that adding such a paragraph would be useful.
>
> For instance if someone desires a service to forward all received spam= calls to
> another set of victims, they would likely not use such a service if th= e
> forwarding party might also get flagged as part of the 666 handling. >
>
> > -----Original Message-----
> > From: sipcore [mailto= :sipcore-bounces@ietf.org] On Behalf Of Paul
> Kyzivat
> > Sent: Wednesday, January 04, 2017 7:51 PM
> > To: sipcore@ietf.org
> > Subject: Re: [sipcore] Comments on
> > draft-ietf-sipcore-status-unwanted-01
> >
> > On 1/4/17 5:35 PM, = marianne.mohali@orange.com wrote:
> >
> > > -Section 4 general:
> > > IMO, it would be good to have a paragraph addressing the que= stion of
> > > the "calling party number" (mentioned several time= in the document):
> > > indeed, this calling party number can be identified by the t= elephone
> > > number/address in the From header or the one in the
> > > P-Asserted-Identity header that may be different. Depending = on the
> > > one displayed to the called UA, the 666 could concern only o= ne or
> > > both addresses depending on service provider choices. If we = take the
> > > example of a call-center or an IPBX having the head number a= nd a
> > > range of private numbers, the service provider could interpr= et the
> > > 666 from the called user only for the private number (in the= From
> > > header) or for the whole pool (P-Asserted-Identity). I sugge= st to
> > > have a paragraph to highlight this point.
> >
> > Interesting point. If the PAID is different from the number displ= ayed
> > to
> the
> > callee, and the callee rejects the call without answering, how sh= ould
> "blame"
> > be assigned? From the calllee's perspective the complaint is *abo= ut*
> > the number he saw, regardless of what the identity of the actual = caller was.
> >
> >      Thanks,
> >      Paul
> >
> > _______________________________________________
> > sipcore mailing list
> > sipcore@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F= 0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e= =3D
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJc= VoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F= 0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e= =3D

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8b= cHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9= ko1LYaC5NY&e=3D

--_000_CY1PR09MB0634CD4233B27CB89422925EEA790CY1PR09MB0634namp_-- From nobody Thu Jan 12 13:52:27 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B30DA124281; Thu, 12 Jan 2017 13:52:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> Date: Thu, 12 Jan 2017 13:52:20 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:52:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : A SIP Response Code for Unwanted Calls Author : Henning Schulzrinne Filename : draft-ietf-sipcore-status-unwanted-02.txt Pages : 7 Date : 2017-01-12 Abstract: This document defines the 666 (Unwanted) SIP response code, allowing called parties to indicate that the call or message was unwanted. SIP entities may use this information to adjust how future calls from this calling party are handled for the called party or more broadly. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 12 14:19:50 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF1C51293E0 for ; Thu, 12 Jan 2017 14:19:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEpPIJ4oise8 for ; Thu, 12 Jan 2017 14:19:45 -0800 (PST) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) by ietfa.amsl.com (Postfix) with SMTP id 837B5128824 for ; Thu, 12 Jan 2017 14:19:45 -0800 (PST) Received: (qmail 844 invoked by uid 0); 12 Jan 2017 22:19:42 -0000 Received: from unknown (HELO cmgw4) (10.0.90.85) by qproxy5.mail.unifiedlayer.com with SMTP; 12 Jan 2017 22:19:41 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw4 with id XaEd1u00r1MNPNq01aEgZV; Thu, 12 Jan 2017 15:14:42 -0700 X-Authority-Analysis: v=2.1 cv=YfouuWhf c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=1oJP67jkp3AA:10 a=IgFoBzBjUZAA:10 a=ZZnuYtJkoWoA:10 a=PeFO9FbFhS32YxYntvkA:9 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=kUVcWBOSAAAA:8 a=bUC8-HMnAAAA:8 a=z9tbli-vAAAA:8 a=RpNjiQI2AAAA:8 a=DdwhYJ_aYwNjQU07-5MA:9 a=fjOtSY_yelstCO4r:21 a=bD5Qwkewufd1RB9H:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=bhwKJZ1wGileOOdB:21 a=Ww4d5g5D8cpTI-Ud:21 a=xxAxYWbKZ3gcZiWy:21 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC7Yk6K0A:10 a=frz4AuCg-hUA:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=2fN0Ut44FUSjvWHL4tab:22 a=P8UDzumeU7_LHUXxyN9-:22 a=RmrFvp9qXTL7MAzcxlte:22 a=vJuR_VyAocOa-HWBgGQO:22 a=BKKCjISod1eDJeS0ORpz:22 a=zjWhRoSqWz9hl55Hdlzg:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-type:Mime-version:In-Reply-To:References:Message-ID:To: From:Subject:Date; bh=jscPh4t1L5QxmN5qDgCyAcNkj/yW4BnAlggenJ4mtnM=; b=c5h52q9 GhPjXib8m8dQOmYFm82vRiJBVD7fM1d7kEq0bK229UIs41Yp6O22Pr35fp6coerYfhLegl1IJpvyf n06xecx2T53SGwTk+pc7FRyRKTX+uKUumvcayA2sJ8W5; Received: from pool-100-36-44-71.washdc.fios.verizon.net ([100.36.44.71]:55543 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.86_1) (envelope-from ) id 1cRndl-0001U6-J3; Thu, 12 Jan 2017 15:14:37 -0700 User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Thu, 12 Jan 2017 17:14:35 -0500 From: Richard Shockey To: Henning Schulzrinne , "Asveren, Tolga" , "sipcore@ietf.org" Message-ID: <8E82E310-55EF-4842-ACFD-64E25AAE8567@shockey.us> Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3567086077_1903941195" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.71 X-Exim-ID: 1cRndl-0001U6-J3 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-71.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.71]:55543 X-Source-Auth: richard+shockey.us X-Email-Count: 1 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:19:49 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3567086077_1903941195 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable =20 +1 =20 It would be very helpful if we could get one simple thing actually done.=C2=A0=20 =20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 =20 From: sipcore on behalf of Henning Schulzrinne <= Henning.Schulzrinne@fcc.gov> Date: Thursday, January 12, 2017 at 4:46 PM To: "Asveren, Tolga" , "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 =20 The suggested wording for the =E2=80=9CNone=E2=80=9D sentence has been included (with t= he other change that we=E2=80=99re now talking about SIP requests). =20 As to the IM vs. call, I admit that I find it hard to conjure up a realisti= c use case. I do sometimes tell charities to send me their pitch by postal m= ail (to avoid being scammed by impostors, among other reasons), but I doubt = that a button would be useful, or that I=E2=80=99d want to hear from them by IM. =20 On the other hand, a facility to only be contacted by IM and never by voice= will be welcomed by all teenagers, so maybe there=E2=80=99s an opportunity here f= or future work. =20 Henning =20 From: Asveren, Tolga [mailto:tasveren@sonusnet.com]=20 Sent: Friday, January 06, 2017 3:55 AM To: Henning Schulzrinne ; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 =20 I think there is a difference between what =E2=80=9Ca call=E2=80=9D means for end-user = and for the network: For the human agent, it is really nothing more than =E2=80=9CGrandma called me=E2=80=9D= . For the network, all the aspects you mentioned would come into play, e.g .= which SIP information elements to use to identify the calling party etc.. I= t could be useful to state this clearly.=20 =20 I agree that the definition of =E2=80=9CCall=E2=80=9D from RFC3261=E2=80=9D seems adequate as= far as human agent is concerned. I also agree that there is no need to arti= ficially limit the applicability just to =E2=80=9Ccalls=E2=80=9D -although I believe thi= s would cover 99% [99.9% if I dare to say] of the use cases-. It could be g= ood to continue using the term =E2=80=9Ccall=E2=80=9D, reference RFC3261 definition of a= =E2=80=9Ccall=E2=80=9D and add aa sentence along the lines of: =E2=80=9CIt should be noted that =E2=80=9C666 unwanted=E2=80=9D response code can be used for= any SIP request as long as it results a human agent observable stimulus, e.= g. audial, visual or otherwise, on which the human agent can express his dec= ision to classify it as =E2=80=9Cunwanted=E2=80=9D.=20 =20 I think the proper meaning of =E2=80=9C666 unwanted=E2=80=9D is =E2=80=9Cthe human agent cons= iders this particular call as unwanted=E2=80=9D rather than =E2=80=9Cthe human agent doe= s not want any further calls from this caller=E2=80=9D. It will be the network dec= ision what actions will be taken based on this input. Therefore, I think the= current wording in the draft should be changed as indicated in ii- below: "None of the existing 4xx, 5xx or 6xx response codes signify that calls fro= m this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." =20 On another note: Is there a need to supply additional information as far as= different session types are concerned, e.g. audio call v.s. video call v.s.= IM? There could be situations where this is useful, e.g. human agent is fin= e with IM but does not want voice calls from a certain calling party. OTOH, = I think this again should be handled by the network itself and the change I = suggested above would be helpful in this sense as well: 666 means that human= agent considers this particular session as unwanted. It does not tell anyth= ing more as far as other sessions of the same type or of other session types= are concerned. He would communicate his choices regarding how this informat= ion needs to be treated by other means, e.g. via a Web Portal, if such a a s= ervice is provided by the operator. =20 Thanks, Tolga =20 From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 Sent: Thursday, January 05, 2017 6:14 PM To: Asveren, Tolga ; Brett Tate ; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 =20 On (i), I agree that we don't want to get into what information is being us= ed, given that the entity most likely to use the 666 information, i.e., the = terminating carrier, is also the one deciding how caller identity is being p= resented to the user (PAI, From, etc.). =20 Tastes may differ, but I don't see how we can say much that's useful to imp= lementors here, without getting into weeds that are already being explored b= y (say) the SHAKEN effort. =20 Also, I'm not convinced that defining "call" is needed here, given that we'= d probably not go much beyond what's in RFC 3261: =20 Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Also, given the discussion of usage for non-INVITE, I'll change "call" to "= request" or "dialog" where the context is more than just an example of what = is likely to be the most common case - INVITE for a phone call.=20 =20 Henning From: sipcore on behalf of Asveren, Tolga Sent: Thursday, January 5, 2017 10:22:55 AM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=20 =20 I agree that defining what a "call" is a good idea but I have a different t= ake on what it should say: i- A "call" in the context of this document is a communication session as = perceived by a human agent, e.g. as in "I received a call from my grandmothe= r.". It does not imply anything further as far as SIP information elements w= hich usually are used to carry calling party identification, e.g. P-Asserted= -Id, From headers, are concerned. It is up to the operator/network policy ho= w to make associate further calls with the information/decision derived from= unwanted calls. ii- "None of the existing 4xx, 5xx or 6xx response codes signify that calls= from this caller are unwanted by the called party." =3D=3D> "None of the existing 4xx, 5xx or 6xx response codes signify that this call= is unwanted by the called party." I think ii- is needed to relive the end user from the burden of "knowing th= e actual caller". Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Thursday, January 05, 2017 7:54 AM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 >=20 > Hi, >=20 > I also agree that adding such a paragraph would be useful. >=20 > For instance if someone desires a service to forward all received spam ca= lls to > another set of victims, they would likely not use such a service if the > forwarding party might also get flagged as part of the 666 handling. >=20 >=20 > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul > Kyzivat > > Sent: Wednesday, January 04, 2017 7:51 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Comments on > > draft-ietf-sipcore-status-unwanted-01 > > > > On 1/4/17 5:35 PM, marianne.mohali@orange.com wrote: > > > > > -Section 4 general: > > > IMO, it would be good to have a paragraph addressing the question of > > > the "calling party number" (mentioned several time in the document): > > > indeed, this calling party number can be identified by the telephone > > > number/address in the From header or the one in the > > > P-Asserted-Identity header that may be different. Depending on the > > > one displayed to the called UA, the 666 could concern only one or > > > both addresses depending on service provider choices. If we take the > > > example of a call-center or an IPBX having the head number and a > > > range of private numbers, the service provider could interpret the > > > 666 from the called user only for the private number (in the From > > > header) or for the whole pool (P-Asserted-Identity). I suggest to > > > have a paragraph to highlight this point. > > > > Interesting point. If the PAID is different from the number displayed > > to > the > > callee, and the callee rejects the call without answering, how should > "blame" > > be assigned? From the calllee's perspective the complaint is *about* > > the number he saw, regardless of what the identity of the actual caller= was. > > > > Thanks, > > Paul > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8= lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZov= dxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lD= U1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdx= DmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_l= istinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1= XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDm= rixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D=20 _______________________________________________ sipcore mailing list sipcor= e@ietf.org https://www.ietf.org/mailman/listinfo/sipcore=20 --B_3567086077_1903941195 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

 

+1

 

It would be very helpful if we could get one simple thing actually done.=C2=A0 =

 

— = ;

Rich= ard Shockey

Shockey Consulting LLC

Chairman of the Board SIP Forum

www.shock= ey.us

www.sipforum.org

richard<at>shockey.us

Skype-Linkedin-Facebook r= shockey101

PSTN +1 703-593-2683

 =

 

From: sipcore <sipcore-bounces@ietf.org> on behalf of Henn= ing Schulzrinne <Henning.Schulzrinne@fcc.gov>
Date: Thursday= , January 12, 2017 at 4:46 PM
To: "Asveren, Tolga" <t= asveren@sonusnet.com>, "sipcore@ietf.org" <sipcore@ietf.org&= gt;
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-u= nwanted-01

 

The suggested wording for the “None” senten= ce has been included (with the other change that we’re now talking abo= ut SIP requests).

 

<= p class=3DMsoNormal>As to the IM vs. call, I admit that I find it hard to conjure up a re= alistic use case. I do sometimes tell charities to send me their pitch by po= stal mail (to avoid being scammed by impostors, among other reasons), but I = doubt that a button would be useful, or that I’d want to hear from the= m by IM.

 

On= the other hand, a facility to only be contacted by IM and never by voice wi= ll be welcomed by all teenagers, so maybe there’s an opportunity here = for future work.

 

Henning

 

=

From: Asver= en, Tolga [mailto:tasveren@sonusnet.com]
Sent: Friday, January 06= , 2017 3:55 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc= .gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draf= t-ietf-sipcore-status-unwanted-01

 

I think there is a difference between what “a= call” means for end-user and for the network:

For the = human agent, it is really nothing more than “Grandma called me”.= For the network, all the aspects you mentioned would come into play, e.g . = which SIP information elements to use to identify the calling party etc.. It= could be useful to state this clearly.

 

I agree that the definition of “Call” from RFC3261” seem= s adequate as far as human agent is concerned. I also agree that there is no= need to artificially limit the applicability just to “calls” -a= lthough I believe this would cover 99%  [99.9% if I dare to say] of the= use cases-. It could be good to continue using the term “call”,= reference RFC3261 definition of a “call” and add aa sentence al= ong the lines of:

“It should be noted that “666 u= nwanted” response code can be used for any SIP request as long as it r= esults a human agent observable stimulus, e.g. audial, visual or otherwise, = on which the human agent can express his decision to classify it as “u= nwanted”.

 

I think the proper mea= ning of “666 unwanted” is “the human agent considers this = particular call as unwanted” rather than “the human agent does n= ot want any further calls from this caller”. It will be the network de= cision what actions will be taken based on this input. Therefore, I think th= e current wording in the draft should be changed as indicated in ii- below:<= /span>

"None of the existing 4xx, 5xx or 6xx response codes sig= nify that calls from this caller are unwanted by the called party."

=3D=3D>

"None of the existing 4xx, 5xx or 6xx= response codes signify that this call is unwanted by the called party."= ;

 

On another note: Is there a need to s= upply additional information as far as different session types are concerned= , e.g. audio call v.s. video call v.s. IM? There could be situations where t= his is useful, e.g. human agent is fine with IM but does not want voice call= s from a certain calling party. OTOH, I think this again should be handled b= y the network itself and the change I suggested above would be helpful in th= is sense as well: 666 means that human agent considers this particular sessi= on as unwanted. It does not tell anything more as far as other sessions of t= he same type or of other session types are concerned. He would communicate h= is choices regarding how this information needs to be treated by other means= , e.g. via a Web Portal, if such a a service is provided by the operator.

 

Thanks,

Tolga<= /o:p>

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent= : Thursday, January 05, 2017 6:14 PM
To: Asveren, Tolga <tasveren@sonusnet.com>; Brett Ta= te <brett@broadsoft.com>; sipcore@ietf.org
Subject: Re: [= sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=

 

On (i), I= agree that we don't want to get into what information is being used, given = that the entity most likely to use the 666 information, i.e., the terminatin= g carrier, is also the one deciding how caller identity is being presented t= o the user (PAI, From, etc.).

 

Tastes may differ, but I don't see how we can say m= uch that's useful to implementors here, without getting into weeds that are = already being explored by (say) the SHAKEN effort.

<= span style=3D'font-family:Calibri;color:black'> 

= Also, I'm not convinced that d= efining "call" is needed here, given that we'd probably not go muc= h beyond what's in RFC 3261:

 

Call: A call is an i=
nformal term that refers to some communication
<=
span style=3D'color:black'>         be=
tween peers, generally set up for the purposes of a
<= pre>       &nbs= p; multimedia conversation.

Also, given the discussion of usage = for non-INVITE, I'll change "call" to "request" or "= ;dialog" where the context is more than just an example of what is like= ly to be the most common case - INVITE for a phone call. <= /p>

 =

Henning

Fro= m:= sipcore <sipcore-bounces@ietf.= org> on behalf of Asveren, Tolga <tasveren@sonusnet.com>
Sent: Thursday, January 5, 20= 17 10:22:55 AM
To: Brett Tate; s= ipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-= sipcore-status-unwanted-01

&nb= sp;

I agree that defining what a "call" is a good idea = but I have a different take on what it should say:

i-  A "c= all" in the context of this document is a communication session as perc= eived by a human agent, e.g. as in "I received a call from my grandmoth= er.". It does not imply anything further as far as SIP information elem= ents which usually are used to carry calling party identification, e.g. P-As= serted-Id, From headers, are concerned. It is up to the operator/network pol= icy how to make associate further calls with the information/decision derive= d from unwanted calls.

ii- "None of the existing 4xx, 5xx or 6xx= response codes signify that calls from this caller are unwanted by the call= ed party."
=3D=3D>
"None of the existing 4xx, 5xx or 6xx resp= onse codes signify that this call is unwanted by the called party."
=
I think ii- is needed to relive the end user from the burden of "kn= owing the actual caller".

Thanks,
Tolga

> -----Orig= inal Message-----
> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Brett Tate
> = Sent: Thursday, January 05, 2017 7:54 AM
> To: sipcore@ietf.org
> Subject: Re: [sipcore] Comments on d= raft-ietf-sipcore-status-unwanted-01
>
> Hi,
>
> I= also agree that adding such a paragraph would be useful.
>
> F= or instance if someone desires a service to forward all received spam calls = to
> another set of victims, they would likely not use such a service = if the
> forwarding party might also get flagged as part of the 666 ha= ndling.
>
>
> > -----Original Message-----
> &g= t; From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Paul
> Kyzivat
> > Sent: We= dnesday, January 04, 2017 7:51 PM
> > To: sipcore@ietf.org
> > Subject: Re: [sipcore] Comments o= n
> > draft-ietf-sipcore-status-unwanted-01
> >
> &g= t; On 1/4/17 5:35 PM, marianne.m= ohali@orange.com wrote:
> >
> > > -Section 4 genera= l:
> > > IMO, it would be good to have a paragraph addressing th= e question of
> > > the "calling party number" (mentio= ned several time in the document):
> > > indeed, this calling pa= rty number can be identified by the telephone
> > > number/addre= ss in the From header or the one in the
> > > P-Asserted-Identit= y header that may be different. Depending on the
> > > one displ= ayed to the called UA, the 666 could concern only one or
> > > b= oth addresses depending on service provider choices. If we take the
> = > > example of a call-center or an IPBX having the head number and a> > > range of private numbers, the service provider could interp= ret the
> > > 666 from the called user only for the private numb= er (in the From
> > > header) or for the whole pool (P-Asserted-= Identity). I suggest to
> > > have a paragraph to highlight this= point.
> >
> > Interesting point. If the PAID is differen= t from the number displayed
> > to
> the
> > callee,= and the callee rejects the call without answering, how should
> "= ;blame"
> > be assigned? From the calllee's perspective the co= mplaint is *about*
> > the number he saw, regardless of what the id= entity of the actual caller was.
> >
> >   =    Thanks,
> >      Paul
>= >
> > _______________________________________________
> &= gt; sipcore mailing list
> > sipc= ore@ietf.org
> > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4g= AQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHp= B4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYa= C5NY&e=3D
>
> __________________________________________= _____
> sipcore mailing list
> sipcore@ietf.org
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3= A__www.ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4g= AQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHp= B4OB5sgh5Qx8F0S1zEJjPY8Hh04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYa= C5NY&e=3D

_______________________________________________
s= ipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_l= istinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5Ei= VcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3DTyQ-YmiL8bcHpB4OB5sgh5Qx8F0S1zEJjPY8Hh= 04CPo&s=3DOZovdxDmrixSKbFJCEwMHyZojpU8uYeU9ko1LYaC5NY&e=3D

________________________________= _______________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/m= ailman/listinfo/sipcore

--B_3567086077_1903941195-- From nobody Thu Jan 12 16:52:15 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F85412960A for ; Thu, 12 Jan 2017 16:52:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1Edfju3vMzU for ; Thu, 12 Jan 2017 16:52:11 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A21B31295C1 for ; Thu, 12 Jan 2017 16:52:11 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0D0qAAN021750 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 12 Jan 2017 18:52:11 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "'SIPCORE'" From: Adam Roach Message-ID: Date: Thu, 12 Jan 2017 18:52:05 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 00:52:13 -0000 [as chair] As I mentioned in an earlier message, we have new milestones for SIPCORE, many of which we hope to finish in the first half of the year. To that end, I'd like to call for adoption of the documents that prompted adding the milestones. To be specific: We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milestone "mechanism for labeling the nature of SIP calls" We propose adopting draft-holmberg-sipcore-content-id for the milestone "clarification of the use of Content-ID" We propose adopting draft-sparks-sipcore-name-addr-guidance for the milestone "clarification of the use of name-addr" I'll note that these document -- and in particular the last two -- have had significant discussion and feedback already. In particular, the author of draft-sparks-sipcore-name-addr-guidance indicates that he believes that document is "done" and basically ready for last call. Please provide feedback regarding adoption of these documents by Friday, January 27. Thanks! /a From nobody Thu Jan 12 22:25:52 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528D1129A9E for ; Thu, 12 Jan 2017 22:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3lzmZqR2sV4h for ; Thu, 12 Jan 2017 22:25:46 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E74E1129A9C for ; Thu, 12 Jan 2017 22:25:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=0/HnksbBe4un2o/UjmDI+o3hdtKSoMKKGTGwQIrFMBg=; b=mQiZlF78C5RGTYFQQPrDSjgOZFEiC//X9leAsy9r1/D0bOIf6qRvIgLcUrYfA6w+IKhvDfZbps0d8fWV3QPEV+v5nrOlOliAudMZcYCHrx68pQ2u/djJ2VC5JOgG31X1xMK4ivPJF96/xLBVNomh8QL/ToYA7i6rG4iaJ9odWog= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0018.outbound.protection.outlook.com [207.46.163.18]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-86-GmdwiWqeNU6ZbEdDmmjXbA-1; Fri, 13 Jan 2017 01:25:42 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 13 Jan 2017 06:25:40 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0845.013; Fri, 13 Jan 2017 06:25:40 +0000 From: "Asveren, Tolga" To: Richard Shockey , Henning Schulzrinne , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AQHSZu3dGYJ0jtsz5EmPEreSyl8iJqEp15kAgAAldrCAAIf2AIAAmsaQgApNH4CAAAe9gIAAiH9g Date: Fri, 13 Jan 2017 06:25:40 +0000 Message-ID: References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> <8E82E310-55EF-4842-ACFD-64E25AAE8567@shockey.us> In-Reply-To: <8E82E310-55EF-4842-ACFD-64E25AAE8567@shockey.us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 1ca8095c-fb9d-41b9-3ee8-08d43b7cfed9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:J0Yxt9GMHJEMxOGC298YFQ3+nYBlvK2AQTPNd4PLiFYR/IJEaKIOl5vMcB8qVur50mL0cnoRc6CDYkSd/Vz0cGP1h5n25fY9C3vJud0Ie+tsFGZG+VjWRTPzwayYBFZoRfiTDX15KPT+fnyaEVpDNteMKeyB57l+qGmy258eqZXlZ0rTMkQOlGgrBxyoGZ3NHfvH2mF9X8szY/xchOO3fBZr6wdrwl++fChEULMlZ9x+vk7MP+rEhj8WKi9NB5rtipw7J6fKWOum/AbHB0L7ffBvJjFCeRDtXcLdEn4+ke4OgySjNG9/rxpBnvhYO3gMVBOYJsSwY/ouUaPI0X1L27C9C8Cbg5HJuhfueARqLo/SkWb/dJaZlYhiVrHj9RjNv3alkknWJaCvyUoQ+3GgVnr7/gDMddHNW9rmCNNpxJqB8kCVdPb6rvjeLIWEhZdm+mumr10bIvlUBO2i/18w4g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(131327999870524)(18271650672692)(21748063052155)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(24454002)(13464003)(189998001)(3660700001)(106116001)(106356001)(93886004)(575784001)(86362001)(236005)(7696004)(2501003)(606005)(74316002)(2950100002)(9686003)(97736004)(6306002)(54896002)(5001770100001)(25786008)(5660300001)(2900100001)(55016002)(107886002)(99286003)(92566002)(7736002)(7906003)(54356999)(76176999)(1680700002)(50986999)(6116002)(790700001)(102836003)(3846002)(16601075003)(77096006)(3280700002)(6436002)(2906002)(6506006)(68736007)(8936002)(101416001)(33656002)(38730400001)(230783001)(229853002)(81156014)(81166006)(8676002)(122556002)(66066001)(105586002)(478054002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 06:25:40.2165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: GmdwiWqeNU6ZbEdDmmjXbA-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235036253E8B75E1138F1185B2780SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 06:25:50 -0000 --_000_SN2PR03MB235036253E8B75E1138F1185B2780SN2PR03MB2350namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 QWdyZWVkLg0KDQpBcmd1YWJseSB0aGVyZSBpcyBub3RoaW5nIHRvIGRvIGFueWhvdzogNjY2IHRl bGxzIHRoYXQgKnRoaXMgcGFydGljdWxhciogc2Vzc2lvbiBpcyB1bndhbnRlZC4gTmV0d29yayBs b2dpYyBjYW4gZGV0ZXJtaW5lIHdoYXQgdG8gZG8gYmFzZWQgb24gdGhpcyBpbmRpY2F0aW9uLCBl LmcuIHVzZSBpdCBhcyBpbnB1dCBvbmx5IGZvciB0aGlzIHBhcnRpY3VsYXIgc2Vzc2lvbiB0eXBl IHYucy4gZm9yIGFsbCBzZXNzaW9uIHR5cGVzLiBUaGlzIGlzIG5vdCBzb21ldGhpbmcgaW4gc2Nv cGUgb2Yg4oCcc3RhdHVzIHVud2FudGVk4oCdIC1hbmQgaXMgdGhlIHJpZ2h0IG1lbnRhbGl0eSBJ TUhPLS4NCg0KVGhhbmtzLA0KVG9sZ2ENCg0KRnJvbTogUmljaGFyZCBTaG9ja2V5IFttYWlsdG86 cmljaGFyZEBzaG9ja2V5LnVzXQ0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTIsIDIwMTcgNTox NSBQTQ0KVG86IEhlbm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdv dj47IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+OyBzaXBjb3JlQGlldGYu b3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29y ZS1zdGF0dXMtdW53YW50ZWQtMDENCg0KDQorMQ0KDQpJdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwg aWYgd2UgY291bGQgZ2V0IG9uZSBzaW1wbGUgdGhpbmcgYWN0dWFsbHkgZG9uZS4NCg0K4oCUDQoN ClJpY2hhcmQgU2hvY2tleQ0KDQpTaG9ja2V5IENvbnN1bHRpbmcgTExDDQoNCkNoYWlybWFuIG9m IHRoZSBCb2FyZCBTSVAgRm9ydW0NCg0Kd3d3LnNob2NrZXkudXM8aHR0cDovL3d3dy5zaG9ja2V5 LnVzPg0KDQp3d3cuc2lwZm9ydW0ub3JnPGh0dHA6Ly93d3cuc2lwZm9ydW0ub3JnPg0KDQpyaWNo YXJkPGF0PnNob2NrZXkudXMNCg0KU2t5cGUtTGlua2VkaW4tRmFjZWJvb2sgcnNob2NrZXkxMDEN Cg0KUFNUTiArMSA3MDMtNTkzLTI2ODMNCg0KDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBv ZiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8bWFpbHRv Okhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj4+DQpEYXRlOiBUaHVyc2RheSwgSmFudWFyeSAx MiwgMjAxNyBhdCA0OjQ2IFBNDQpUbzogIkFzdmVyZW4sIFRvbGdhIiA8dGFzdmVyZW5Ac29udXNu ZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+PiwgInNpcGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+IiA8c2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29y ZUBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDENCg0KVGhlIHN1Z2dlc3RlZCB3b3JkaW5nIGZv ciB0aGUg4oCcTm9uZeKAnSBzZW50ZW5jZSBoYXMgYmVlbiBpbmNsdWRlZCAod2l0aCB0aGUgb3Ro ZXIgY2hhbmdlIHRoYXQgd2XigJlyZSBub3cgdGFsa2luZyBhYm91dCBTSVAgcmVxdWVzdHMpLg0K DQpBcyB0byB0aGUgSU0gdnMuIGNhbGwsIEkgYWRtaXQgdGhhdCBJIGZpbmQgaXQgaGFyZCB0byBj b25qdXJlIHVwIGEgcmVhbGlzdGljIHVzZSBjYXNlLiBJIGRvIHNvbWV0aW1lcyB0ZWxsIGNoYXJp dGllcyB0byBzZW5kIG1lIHRoZWlyIHBpdGNoIGJ5IHBvc3RhbCBtYWlsICh0byBhdm9pZCBiZWlu ZyBzY2FtbWVkIGJ5IGltcG9zdG9ycywgYW1vbmcgb3RoZXIgcmVhc29ucyksIGJ1dCBJIGRvdWJ0 IHRoYXQgYSBidXR0b24gd291bGQgYmUgdXNlZnVsLCBvciB0aGF0IEnigJlkIHdhbnQgdG8gaGVh ciBmcm9tIHRoZW0gYnkgSU0uDQoNCk9uIHRoZSBvdGhlciBoYW5kLCBhIGZhY2lsaXR5IHRvIG9u bHkgYmUgY29udGFjdGVkIGJ5IElNIGFuZCBuZXZlciBieSB2b2ljZSB3aWxsIGJlIHdlbGNvbWVk IGJ5IGFsbCB0ZWVuYWdlcnMsIHNvIG1heWJlIHRoZXJl4oCZcyBhbiBvcHBvcnR1bml0eSBoZXJl IGZvciBmdXR1cmUgd29yay4NCg0KSGVubmluZw0KDQpGcm9tOiBBc3ZlcmVuLCBUb2xnYSBbbWFp bHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbV0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAwNiwgMjAx NyAzOjU1IEFNDQpUbzogSGVubmluZyBTY2h1bHpyaW5uZSA8SGVubmluZy5TY2h1bHpyaW5uZUBm Y2MuZ292PG1haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+Pjsgc2lwY29yZUBpZXRm Lm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQ29t bWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KDQpJIHRoaW5r IHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQg4oCcYSBjYWxs4oCdIG1lYW5zIGZv ciBlbmQtdXNlciBhbmQgZm9yIHRoZSBuZXR3b3JrOg0KRm9yIHRoZSBodW1hbiBhZ2VudCwgaXQg aXMgcmVhbGx5IG5vdGhpbmcgbW9yZSB0aGFuIOKAnEdyYW5kbWEgY2FsbGVkIG1l4oCdLiBGb3Ig dGhlIG5ldHdvcmssIGFsbCB0aGUgYXNwZWN0cyB5b3UgbWVudGlvbmVkIHdvdWxkIGNvbWUgaW50 byBwbGF5LCBlLmcgLiB3aGljaCBTSVAgaW5mb3JtYXRpb24gZWxlbWVudHMgdG8gdXNlIHRvIGlk ZW50aWZ5IHRoZSBjYWxsaW5nIHBhcnR5IGV0Yy4uIEl0IGNvdWxkIGJlIHVzZWZ1bCB0byBzdGF0 ZSB0aGlzIGNsZWFybHkuDQoNCkkgYWdyZWUgdGhhdCB0aGUgZGVmaW5pdGlvbiBvZiDigJxDYWxs 4oCdIGZyb20gUkZDMzI2MeKAnSBzZWVtcyBhZGVxdWF0ZSBhcyBmYXIgYXMgaHVtYW4gYWdlbnQg aXMgY29uY2VybmVkLiBJIGFsc28gYWdyZWUgdGhhdCB0aGVyZSBpcyBubyBuZWVkIHRvIGFydGlm aWNpYWxseSBsaW1pdCB0aGUgYXBwbGljYWJpbGl0eSBqdXN0IHRvIOKAnGNhbGxz4oCdIC1hbHRo b3VnaCBJIGJlbGlldmUgdGhpcyB3b3VsZCBjb3ZlciA5OSUgIFs5OS45JSBpZiBJIGRhcmUgdG8g c2F5XSBvZiB0aGUgdXNlIGNhc2VzLS4gSXQgY291bGQgYmUgZ29vZCB0byBjb250aW51ZSB1c2lu ZyB0aGUgdGVybSDigJxjYWxs4oCdLCByZWZlcmVuY2UgUkZDMzI2MSBkZWZpbml0aW9uIG9mIGEg 4oCcY2FsbOKAnSBhbmQgYWRkIGFhIHNlbnRlbmNlIGFsb25nIHRoZSBsaW5lcyBvZjoNCuKAnEl0 IHNob3VsZCBiZSBub3RlZCB0aGF0IOKAnDY2NiB1bndhbnRlZOKAnSByZXNwb25zZSBjb2RlIGNh biBiZSB1c2VkIGZvciBhbnkgU0lQIHJlcXVlc3QgYXMgbG9uZyBhcyBpdCByZXN1bHRzIGEgaHVt YW4gYWdlbnQgb2JzZXJ2YWJsZSBzdGltdWx1cywgZS5nLiBhdWRpYWwsIHZpc3VhbCBvciBvdGhl cndpc2UsIG9uIHdoaWNoIHRoZSBodW1hbiBhZ2VudCBjYW4gZXhwcmVzcyBoaXMgZGVjaXNpb24g dG8gY2xhc3NpZnkgaXQgYXMg4oCcdW53YW50ZWTigJ0uDQoNCkkgdGhpbmsgdGhlIHByb3BlciBt ZWFuaW5nIG9mIOKAnDY2NiB1bndhbnRlZOKAnSBpcyDigJx0aGUgaHVtYW4gYWdlbnQgY29uc2lk ZXJzIHRoaXMgcGFydGljdWxhciBjYWxsIGFzIHVud2FudGVk4oCdIHJhdGhlciB0aGFuIOKAnHRo ZSBodW1hbiBhZ2VudCBkb2VzIG5vdCB3YW50IGFueSBmdXJ0aGVyIGNhbGxzIGZyb20gdGhpcyBj YWxsZXLigJ0uIEl0IHdpbGwgYmUgdGhlIG5ldHdvcmsgZGVjaXNpb24gd2hhdCBhY3Rpb25zIHdp bGwgYmUgdGFrZW4gYmFzZWQgb24gdGhpcyBpbnB1dC4gVGhlcmVmb3JlLCBJIHRoaW5rIHRoZSBj dXJyZW50IHdvcmRpbmcgaW4gdGhlIGRyYWZ0IHNob3VsZCBiZSBjaGFuZ2VkIGFzIGluZGljYXRl ZCBpbiBpaS0gYmVsb3c6DQoiTm9uZSBvZiB0aGUgZXhpc3RpbmcgNHh4LCA1eHggb3IgNnh4IHJl c3BvbnNlIGNvZGVzIHNpZ25pZnkgdGhhdCBjYWxscyBmcm9tIHRoaXMgY2FsbGVyIGFyZSB1bndh bnRlZCBieSB0aGUgY2FsbGVkIHBhcnR5LiINCj09Pg0KIk5vbmUgb2YgdGhlIGV4aXN0aW5nIDR4 eCwgNXh4IG9yIDZ4eCByZXNwb25zZSBjb2RlcyBzaWduaWZ5IHRoYXQgdGhpcyBjYWxsIGlzIHVu d2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFydHkuIg0KDQpPbiBhbm90aGVyIG5vdGU6IElzIHRoZXJl IGEgbmVlZCB0byBzdXBwbHkgYWRkaXRpb25hbCBpbmZvcm1hdGlvbiBhcyBmYXIgYXMgZGlmZmVy ZW50IHNlc3Npb24gdHlwZXMgYXJlIGNvbmNlcm5lZCwgZS5nLiBhdWRpbyBjYWxsIHYucy4gdmlk ZW8gY2FsbCB2LnMuIElNPyBUaGVyZSBjb3VsZCBiZSBzaXR1YXRpb25zIHdoZXJlIHRoaXMgaXMg dXNlZnVsLCBlLmcuIGh1bWFuIGFnZW50IGlzIGZpbmUgd2l0aCBJTSBidXQgZG9lcyBub3Qgd2Fu dCB2b2ljZSBjYWxscyBmcm9tIGEgY2VydGFpbiBjYWxsaW5nIHBhcnR5LiBPVE9ILCBJIHRoaW5r IHRoaXMgYWdhaW4gc2hvdWxkIGJlIGhhbmRsZWQgYnkgdGhlIG5ldHdvcmsgaXRzZWxmIGFuZCB0 aGUgY2hhbmdlIEkgc3VnZ2VzdGVkIGFib3ZlIHdvdWxkIGJlIGhlbHBmdWwgaW4gdGhpcyBzZW5z ZSBhcyB3ZWxsOiA2NjYgbWVhbnMgdGhhdCBodW1hbiBhZ2VudCBjb25zaWRlcnMgdGhpcyBwYXJ0 aWN1bGFyIHNlc3Npb24gYXMgdW53YW50ZWQuIEl0IGRvZXMgbm90IHRlbGwgYW55dGhpbmcgbW9y ZSBhcyBmYXIgYXMgb3RoZXIgc2Vzc2lvbnMgb2YgdGhlIHNhbWUgdHlwZSBvciBvZiBvdGhlciBz ZXNzaW9uIHR5cGVzIGFyZSBjb25jZXJuZWQuIEhlIHdvdWxkIGNvbW11bmljYXRlIGhpcyBjaG9p Y2VzIHJlZ2FyZGluZyBob3cgdGhpcyBpbmZvcm1hdGlvbiBuZWVkcyB0byBiZSB0cmVhdGVkIGJ5 IG90aGVyIG1lYW5zLCBlLmcuIHZpYSBhIFdlYiBQb3J0YWwsIGlmIHN1Y2ggYSBhIHNlcnZpY2Ug aXMgcHJvdmlkZWQgYnkgdGhlIG9wZXJhdG9yLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQpGcm9tOiBI ZW5uaW5nIFNjaHVsenJpbm5lIFttYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292XQ0K U2VudDogVGh1cnNkYXksIEphbnVhcnkgMDUsIDIwMTcgNjoxNCBQTQ0KVG86IEFzdmVyZW4sIFRv bGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb208bWFpbHRvOnRhc3ZlcmVuQHNvbnVzbmV0LmNvbT4+ OyBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPG1haWx0bzpicmV0dEBicm9hZHNvZnQu Y29tPj47IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53 YW50ZWQtMDENCg0KDQpPbiAoaSksIEkgYWdyZWUgdGhhdCB3ZSBkb24ndCB3YW50IHRvIGdldCBp bnRvIHdoYXQgaW5mb3JtYXRpb24gaXMgYmVpbmcgdXNlZCwgZ2l2ZW4gdGhhdCB0aGUgZW50aXR5 IG1vc3QgbGlrZWx5IHRvIHVzZSB0aGUgNjY2IGluZm9ybWF0aW9uLCBpLmUuLCB0aGUgdGVybWlu YXRpbmcgY2FycmllciwgaXMgYWxzbyB0aGUgb25lIGRlY2lkaW5nIGhvdyBjYWxsZXIgaWRlbnRp dHkgaXMgYmVpbmcgcHJlc2VudGVkIHRvIHRoZSB1c2VyIChQQUksIEZyb20sIGV0Yy4pLg0KDQoN Cg0KVGFzdGVzIG1heSBkaWZmZXIsIGJ1dCBJIGRvbid0IHNlZSBob3cgd2UgY2FuIHNheSBtdWNo IHRoYXQncyB1c2VmdWwgdG8gaW1wbGVtZW50b3JzIGhlcmUsIHdpdGhvdXQgZ2V0dGluZyBpbnRv IHdlZWRzIHRoYXQgYXJlIGFscmVhZHkgYmVpbmcgZXhwbG9yZWQgYnkgKHNheSkgdGhlIFNIQUtF TiBlZmZvcnQuDQoNCg0KDQpBbHNvLCBJJ20gbm90IGNvbnZpbmNlZCB0aGF0IGRlZmluaW5nICJj YWxsIiBpcyBuZWVkZWQgaGVyZSwgZ2l2ZW4gdGhhdCB3ZSdkIHByb2JhYmx5IG5vdCBnbyBtdWNo IGJleW9uZCB3aGF0J3MgaW4gUkZDIDMyNjE6DQoNCg0KDQpDYWxsOiBBIGNhbGwgaXMgYW4gaW5m b3JtYWwgdGVybSB0aGF0IHJlZmVycyB0byBzb21lIGNvbW11bmljYXRpb24NCg0KICAgICAgICAg YmV0d2VlbiBwZWVycywgZ2VuZXJhbGx5IHNldCB1cCBmb3IgdGhlIHB1cnBvc2VzIG9mIGENCg0K ICAgICAgICAgbXVsdGltZWRpYSBjb252ZXJzYXRpb24uDQpBbHNvLCBnaXZlbiB0aGUgZGlzY3Vz c2lvbiBvZiB1c2FnZSBmb3Igbm9uLUlOVklURSwgSSdsbCBjaGFuZ2UgImNhbGwiIHRvICJyZXF1 ZXN0IiBvciAiZGlhbG9nIiB3aGVyZSB0aGUgY29udGV4dCBpcyBtb3JlIHRoYW4ganVzdCBhbiBl eGFtcGxlIG9mIHdoYXQgaXMgbGlrZWx5IHRvIGJlIHRoZSBtb3N0IGNvbW1vbiBjYXNlIC0gSU5W SVRFIGZvciBhIHBob25lIGNhbGwuDQoNCg0KDQpIZW5uaW5nDQoNCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBBc3ZlcmVuLCBU b2xnYSA8dGFzdmVyZW5Ac29udXNuZXQuY29tPG1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20+ Pg0KU2VudDogVGh1cnNkYXksIEphbnVhcnkgNSwgMjAxNyAxMDoyMjo1NSBBTQ0KVG86IEJyZXR0 IFRhdGU7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53 YW50ZWQtMDENCg0KSSBhZ3JlZSB0aGF0IGRlZmluaW5nIHdoYXQgYSAiY2FsbCIgaXMgYSBnb29k IGlkZWEgYnV0IEkgaGF2ZSBhIGRpZmZlcmVudCB0YWtlIG9uIHdoYXQgaXQgc2hvdWxkIHNheToN Cg0KaS0gIEEgImNhbGwiIGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9jdW1lbnQgaXMgYSBjb21t dW5pY2F0aW9uIHNlc3Npb24gYXMgcGVyY2VpdmVkIGJ5IGEgaHVtYW4gYWdlbnQsIGUuZy4gYXMg aW4gIkkgcmVjZWl2ZWQgYSBjYWxsIGZyb20gbXkgZ3JhbmRtb3RoZXIuIi4gSXQgZG9lcyBub3Qg aW1wbHkgYW55dGhpbmcgZnVydGhlciBhcyBmYXIgYXMgU0lQIGluZm9ybWF0aW9uIGVsZW1lbnRz IHdoaWNoIHVzdWFsbHkgYXJlIHVzZWQgdG8gY2FycnkgY2FsbGluZyBwYXJ0eSBpZGVudGlmaWNh dGlvbiwgZS5nLiBQLUFzc2VydGVkLUlkLCBGcm9tIGhlYWRlcnMsIGFyZSBjb25jZXJuZWQuIEl0 IGlzIHVwIHRvIHRoZSBvcGVyYXRvci9uZXR3b3JrIHBvbGljeSBob3cgdG8gbWFrZSBhc3NvY2lh dGUgZnVydGhlciBjYWxscyB3aXRoIHRoZSBpbmZvcm1hdGlvbi9kZWNpc2lvbiBkZXJpdmVkIGZy b20gdW53YW50ZWQgY2FsbHMuDQoNCmlpLSAiTm9uZSBvZiB0aGUgZXhpc3RpbmcgNHh4LCA1eHgg b3IgNnh4IHJlc3BvbnNlIGNvZGVzIHNpZ25pZnkgdGhhdCBjYWxscyBmcm9tIHRoaXMgY2FsbGVy IGFyZSB1bndhbnRlZCBieSB0aGUgY2FsbGVkIHBhcnR5LiINCj09Pg0KIk5vbmUgb2YgdGhlIGV4 aXN0aW5nIDR4eCwgNXh4IG9yIDZ4eCByZXNwb25zZSBjb2RlcyBzaWduaWZ5IHRoYXQgdGhpcyBj YWxsIGlzIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFydHkuIg0KDQpJIHRoaW5rIGlpLSBpcyBu ZWVkZWQgdG8gcmVsaXZlIHRoZSBlbmQgdXNlciBmcm9tIHRoZSBidXJkZW4gb2YgImtub3dpbmcg dGhlIGFjdHVhbCBjYWxsZXIiLg0KDQpUaGFua3MsDQpUb2xnYQ0KDQo+IC0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmV0dCBUYXRlDQo+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5 IDA1LCAyMDE3IDc6NTQgQU0NCj4gVG86IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0 Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KPg0KPiBIaSwNCj4NCj4gSSBhbHNvIGFncmVl IHRoYXQgYWRkaW5nIHN1Y2ggYSBwYXJhZ3JhcGggd291bGQgYmUgdXNlZnVsLg0KPg0KPiBGb3Ig aW5zdGFuY2UgaWYgc29tZW9uZSBkZXNpcmVzIGEgc2VydmljZSB0byBmb3J3YXJkIGFsbCByZWNl aXZlZCBzcGFtIGNhbGxzIHRvDQo+IGFub3RoZXIgc2V0IG9mIHZpY3RpbXMsIHRoZXkgd291bGQg bGlrZWx5IG5vdCB1c2Ugc3VjaCBhIHNlcnZpY2UgaWYgdGhlDQo+IGZvcndhcmRpbmcgcGFydHkg bWlnaHQgYWxzbyBnZXQgZmxhZ2dlZCBhcyBwYXJ0IG9mIHRoZSA2NjYgaGFuZGxpbmcuDQo+DQo+ DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBzaXBjb3JlIFttYWls dG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUGF1bA0KPiBLeXppdmF0 DQo+ID4gU2VudDogV2VkbmVzZGF5LCBKYW51YXJ5IDA0LCAyMDE3IDc6NTEgUE0NCj4gPiBUbzog c2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCj4gPiBTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uDQo+ID4gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11 bndhbnRlZC0wMQ0KPiA+DQo+ID4gT24gMS80LzE3IDU6MzUgUE0sIG1hcmlhbm5lLm1vaGFsaUBv cmFuZ2UuY29tPG1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbT4gd3JvdGU6DQo+ID4N Cj4gPiA+IC1TZWN0aW9uIDQgZ2VuZXJhbDoNCj4gPiA+IElNTywgaXQgd291bGQgYmUgZ29vZCB0 byBoYXZlIGEgcGFyYWdyYXBoIGFkZHJlc3NpbmcgdGhlIHF1ZXN0aW9uIG9mDQo+ID4gPiB0aGUg ImNhbGxpbmcgcGFydHkgbnVtYmVyIiAobWVudGlvbmVkIHNldmVyYWwgdGltZSBpbiB0aGUgZG9j dW1lbnQpOg0KPiA+ID4gaW5kZWVkLCB0aGlzIGNhbGxpbmcgcGFydHkgbnVtYmVyIGNhbiBiZSBp ZGVudGlmaWVkIGJ5IHRoZSB0ZWxlcGhvbmUNCj4gPiA+IG51bWJlci9hZGRyZXNzIGluIHRoZSBG cm9tIGhlYWRlciBvciB0aGUgb25lIGluIHRoZQ0KPiA+ID4gUC1Bc3NlcnRlZC1JZGVudGl0eSBo ZWFkZXIgdGhhdCBtYXkgYmUgZGlmZmVyZW50LiBEZXBlbmRpbmcgb24gdGhlDQo+ID4gPiBvbmUg ZGlzcGxheWVkIHRvIHRoZSBjYWxsZWQgVUEsIHRoZSA2NjYgY291bGQgY29uY2VybiBvbmx5IG9u ZSBvcg0KPiA+ID4gYm90aCBhZGRyZXNzZXMgZGVwZW5kaW5nIG9uIHNlcnZpY2UgcHJvdmlkZXIg Y2hvaWNlcy4gSWYgd2UgdGFrZSB0aGUNCj4gPiA+IGV4YW1wbGUgb2YgYSBjYWxsLWNlbnRlciBv ciBhbiBJUEJYIGhhdmluZyB0aGUgaGVhZCBudW1iZXIgYW5kIGENCj4gPiA+IHJhbmdlIG9mIHBy aXZhdGUgbnVtYmVycywgdGhlIHNlcnZpY2UgcHJvdmlkZXIgY291bGQgaW50ZXJwcmV0IHRoZQ0K PiA+ID4gNjY2IGZyb20gdGhlIGNhbGxlZCB1c2VyIG9ubHkgZm9yIHRoZSBwcml2YXRlIG51bWJl ciAoaW4gdGhlIEZyb20NCj4gPiA+IGhlYWRlcikgb3IgZm9yIHRoZSB3aG9sZSBwb29sIChQLUFz c2VydGVkLUlkZW50aXR5KS4gSSBzdWdnZXN0IHRvDQo+ID4gPiBoYXZlIGEgcGFyYWdyYXBoIHRv IGhpZ2hsaWdodCB0aGlzIHBvaW50Lg0KPiA+DQo+ID4gSW50ZXJlc3RpbmcgcG9pbnQuIElmIHRo ZSBQQUlEIGlzIGRpZmZlcmVudCBmcm9tIHRoZSBudW1iZXIgZGlzcGxheWVkDQo+ID4gdG8NCj4g dGhlDQo+ID4gY2FsbGVlLCBhbmQgdGhlIGNhbGxlZSByZWplY3RzIHRoZSBjYWxsIHdpdGhvdXQg YW5zd2VyaW5nLCBob3cgc2hvdWxkDQo+ICJibGFtZSINCj4gPiBiZSBhc3NpZ25lZD8gRnJvbSB0 aGUgY2FsbGxlZSdzIHBlcnNwZWN0aXZlIHRoZSBjb21wbGFpbnQgaXMgKmFib3V0Kg0KPiA+IHRo ZSBudW1iZXIgaGUgc2F3LCByZWdhcmRsZXNzIG9mIHdoYXQgdGhlIGlkZW50aXR5IG9mIHRoZSBh Y3R1YWwgY2FsbGVyIHdhcy4NCj4gPg0KPiA+ICAgICAgVGhhbmtzLA0KPiA+ICAgICAgUGF1bA0K PiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNp cGNvcmVAaWV0Zi5vcmc+DQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy L3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zaXBjb3JlJmQ9 RGdJQ0FnJmM9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERV MVhlSElZUkhmYXJwazRNSzU5UkUmbT1UeVEtWW1pTDhiY0hwQjRPQjVzZ2g1UXg4RjBTMXpFSmpQ WThIaDA0Q1BvJnM9T1pvdmR4RG1yaXhTS2JGSkNFd01IeVpvanBVOHVZZVU5a28xTFlhQzVOWSZl PQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3Jl QGlldGYub3JnPg0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NpcGNvcmUmZD1EZ0lDQWcm Yz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JnI9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlS SGZhcnBrNE1LNTlSRSZtPVR5US1ZbWlMOGJjSHBCNE9CNXNnaDVReDhGMFMxekVKalBZOEhoMDRD UG8mcz1PWm92ZHhEbXJpeFNLYkZKQ0V3TUh5Wm9qcFU4dVllVTlrbzFMWWFDNU5ZJmU9DQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1h aWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3Lmll dGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZkPURnSUNBZyZjPXkwaDBvbUNlMGpBVUdy NGdBUTAyRncmcj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJm09 VHlRLVltaUw4YmNIcEI0T0I1c2doNVF4OEYwUzF6RUpqUFk4SGgwNENQbyZzPU9ab3ZkeERtcml4 U0tiRkpDRXdNSHlab2pwVTh1WWVVOWtvMUxZYUM1TlkmZT0NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fIHNpcGNvcmUgbWFpbGluZyBsaXN0IHNpcGNvcmVA aWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K --_000_SN2PR03MB235036253E8B75E1138F1185B2780SN2PR03MB2350namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7 DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLmVtYWlscXVvdGUsIGxpLmVtYWlscXVv dGUsIGRpdi5lbWFpbHF1b3RlDQoJe21zby1zdHlsZS1uYW1lOmVtYWlscXVvdGU7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjUNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+QWdyZWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Bcmd1YWJseSB0aGVyZSBp cyBub3RoaW5nIHRvIGRvIGFueWhvdzogNjY2IHRlbGxzIHRoYXQgKjxiPnRoaXMgcGFydGljdWxh cjwvYj4qIHNlc3Npb24gaXMgdW53YW50ZWQuIE5ldHdvcmsgbG9naWMgY2FuIGRldGVybWluZSB3 aGF0IHRvIGRvIGJhc2VkIG9uIHRoaXMgaW5kaWNhdGlvbiwgZS5nLiB1c2UNCiBpdCBhcyBpbnB1 dCBvbmx5IGZvciB0aGlzIHBhcnRpY3VsYXIgc2Vzc2lvbiB0eXBlIHYucy4gZm9yIGFsbCBzZXNz aW9uIHR5cGVzLiBUaGlzIGlzIG5vdCBzb21ldGhpbmcgaW4gc2NvcGUgb2Yg4oCcc3RhdHVzIHVu d2FudGVk4oCdIC1hbmQgaXMgdGhlIHJpZ2h0IG1lbnRhbGl0eSBJTUhPLS48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VG9sZ2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4gUmljaGFyZCBTaG9ja2V5IFttYWlsdG86cmljaGFyZEBzaG9ja2V5 LnVzXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDEyLCAyMDE3IDU6MTUg UE08YnI+DQo8Yj5Ubzo8L2I+IEhlbm5pbmcgU2NodWx6cmlubmUgJmx0O0hlbm5pbmcuU2NodWx6 cmlubmVAZmNjLmdvdiZndDs7IEFzdmVyZW4sIFRvbGdhICZsdDt0YXN2ZXJlbkBzb251c25ldC5j b20mZ3Q7OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29y ZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mIzQzOzE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SXQgd291bGQgYmUgdmVyeSBoZWxw ZnVsIGlmIHdlIGNvdWxkIGdldCBvbmUgc2ltcGxlIHRoaW5nIGFjdHVhbGx5IGRvbmUuJm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21hcmdpbi1yaWdodDowaW47 bWFyZ2luLWJvdHRvbToxLjBwdDttYXJnaW4tbGVmdDowaW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPuKAlCZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsQ3hTcE1pZGRsZSIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxLjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MS4wcHQ7bWFyZ2luLWxlZnQ6MGluO21zby1h ZGQtc3BhY2U6YXV0byI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmljaGFyZCBTaG9j a2V5PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbEN4U3BNaWRkbGUiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjEuMHB0O21hcmdpbi1sZWZ0OjBpbjttc28tYWRkLXNwYWNl OmF1dG8iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNob2NrZXkgQ29uc3VsdGluZyBM TEM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsQ3hTcE1pZGRsZSIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxLjBwdDttYXJnaW4tcmln aHQ6MGluO21hcmdpbi1ib3R0b206MS4wcHQ7bWFyZ2luLWxlZnQ6MGluO21zby1hZGQtc3BhY2U6 YXV0byI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Q2hhaXJtYW4gb2YgdGhlIEJvYXJk IFNJUCBGb3J1bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWxDeFNwTWlkZGxlIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21h cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbToxLjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWFk ZC1zcGFjZTphdXRvIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRw Oi8vd3d3LnNob2NrZXkudXMiPnd3dy5zaG9ja2V5LnVzPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWxDeFNwTWlkZGxlIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjEuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTox LjBwdDttYXJnaW4tbGVmdDowaW47bXNvLWFkZC1zcGFjZTphdXRvIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8vd3d3LnNpcGZvcnVtLm9yZyI+d3d3LnNpcGZv cnVtLm9yZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsQ3hTcE1pZGRsZSIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxLjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MS4wcHQ7bWFyZ2luLWxlZnQ6MGluO21zby1h ZGQtc3BhY2U6YXV0byI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+cmljaGFyZCZsdDth dCZndDtzaG9ja2V5LnVzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbEN4U3BNaWRkbGUiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MS4w cHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEuMHB0O21hcmdpbi1sZWZ0OjBpbjtt c28tYWRkLXNwYWNlOmF1dG8iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlNreXBlLUxp bmtlZGluLUZhY2Vib29rIHJzaG9ja2V5MTAxPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbEN4U3BNaWRkbGUiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6MS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEuMHB0O21hcmdp bi1sZWZ0OjBpbjttc28tYWRkLXNwYWNlOmF1dG8iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPlBTVE4gJiM0MzsxIDcwMy01OTMtMjY4MzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+c2lwY29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZyI+c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEhl bm5pbmcgU2NodWx6cmlubmUgJmx0OzxhIGhyZWY9Im1haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5l QGZjYy5nb3YiPkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjwvYT4mZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPlRodXJzZGF5LCBKYW51YXJ5IDEyLCAyMDE3IGF0IDQ6NDYgUE08YnI+DQo8Yj5Ubzog PC9iPiZxdW90O0FzdmVyZW4sIFRvbGdhJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVy ZW5Ac29udXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OywgJnF1b3Q7PGEg aHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7 ICZsdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwv YT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJh ZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhlIHN1Z2dlc3RlZCB3b3JkaW5nIGZvciB0aGUg4oCcTm9uZeKAnSBzZW50ZW5jZSBo YXMgYmVlbiBpbmNsdWRlZCAod2l0aCB0aGUgb3RoZXIgY2hhbmdlIHRoYXQgd2XigJlyZSBub3cg dGFsa2luZyBhYm91dCBTSVAgcmVxdWVzdHMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+QXMgdG8gdGhlIElNIHZzLiBjYWxsLCBJIGFkbWl0IHRoYXQgSSBmaW5k IGl0IGhhcmQgdG8gY29uanVyZSB1cCBhIHJlYWxpc3RpYyB1c2UgY2FzZS4gSSBkbyBzb21ldGlt ZXMgdGVsbCBjaGFyaXRpZXMgdG8gc2VuZCBtZSB0aGVpciBwaXRjaCBieSBwb3N0YWwgbWFpbCAo dG8NCiBhdm9pZCBiZWluZyBzY2FtbWVkIGJ5IGltcG9zdG9ycywgYW1vbmcgb3RoZXIgcmVhc29u cyksIGJ1dCBJIGRvdWJ0IHRoYXQgYSBidXR0b24gd291bGQgYmUgdXNlZnVsLCBvciB0aGF0IEni gJlkIHdhbnQgdG8gaGVhciBmcm9tIHRoZW0gYnkgSU0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5PbiB0aGUgb3RoZXIgaGFuZCwgYSBmYWNpbGl0eSB0byBvbmx5 IGJlIGNvbnRhY3RlZCBieSBJTSBhbmQgbmV2ZXIgYnkgdm9pY2Ugd2lsbCBiZSB3ZWxjb21lZCBi eSBhbGwgdGVlbmFnZXJzLCBzbyBtYXliZSB0aGVyZeKAmXMgYW4gb3Bwb3J0dW5pdHkgaGVyZSBm b3IgZnV0dXJlDQogd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPkhlbm5pbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEFz dmVyZW4sIFRvbGdhIFs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29udXNuZXQuY29tIj5tYWls dG86dGFzdmVyZW5Ac29udXNuZXQuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXks IEphbnVhcnkgMDYsIDIwMTcgMzo1NSBBTTxicj4NCjxiPlRvOjwvYj4gSGVubmluZyBTY2h1bHpy aW5uZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiI+SGVu bmluZy5TY2h1bHpyaW5uZUBmY2MuZ292PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86c2lwY29y ZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6 IFtzaXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVk LTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JIHRoaW5rIHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIHdoYXQg4oCc YSBjYWxs4oCdIG1lYW5zIGZvciBlbmQtdXNlciBhbmQgZm9yIHRoZSBuZXR3b3JrOjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9y IHRoZSBodW1hbiBhZ2VudCwgaXQgaXMgcmVhbGx5IG5vdGhpbmcgbW9yZSB0aGFuIOKAnEdyYW5k bWEgY2FsbGVkIG1l4oCdLiBGb3IgdGhlIG5ldHdvcmssIGFsbCB0aGUgYXNwZWN0cyB5b3UgbWVu dGlvbmVkIHdvdWxkIGNvbWUgaW50byBwbGF5LCBlLmcgLiB3aGljaCBTSVAgaW5mb3JtYXRpb24g ZWxlbWVudHMNCiB0byB1c2UgdG8gaWRlbnRpZnkgdGhlIGNhbGxpbmcgcGFydHkgZXRjLi4gSXQg Y291bGQgYmUgdXNlZnVsIHRvIHN0YXRlIHRoaXMgY2xlYXJseS4NCjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J IGFncmVlIHRoYXQgdGhlIGRlZmluaXRpb24gb2Yg4oCcQ2FsbOKAnSBmcm9tIFJGQzMyNjHigJ0g c2VlbXMgYWRlcXVhdGUgYXMgZmFyIGFzIGh1bWFuIGFnZW50IGlzIGNvbmNlcm5lZC4gSSBhbHNv IGFncmVlIHRoYXQgdGhlcmUgaXMgbm8gbmVlZCB0byBhcnRpZmljaWFsbHkgbGltaXQgdGhlIGFw cGxpY2FiaWxpdHkNCiBqdXN0IHRvIOKAnGNhbGxz4oCdIC1hbHRob3VnaCBJIGJlbGlldmUgdGhp cyB3b3VsZCBjb3ZlciA5OSUgJm5ic3A7Wzk5LjklIGlmIEkgZGFyZSB0byBzYXldIG9mIHRoZSB1 c2UgY2FzZXMtLiBJdCBjb3VsZCBiZSBnb29kIHRvIGNvbnRpbnVlIHVzaW5nIHRoZSB0ZXJtIOKA nGNhbGzigJ0sIHJlZmVyZW5jZSBSRkMzMjYxIGRlZmluaXRpb24gb2YgYSDigJxjYWxs4oCdIGFu ZCBhZGQgYWEgc2VudGVuY2UgYWxvbmcgdGhlIGxpbmVzIG9mOjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+4oCcSXQgc2hvdWxkIGJl IG5vdGVkIHRoYXQg4oCcNjY2IHVud2FudGVk4oCdIHJlc3BvbnNlIGNvZGUgY2FuIGJlIHVzZWQg Zm9yIGFueSBTSVAgcmVxdWVzdCBhcyBsb25nIGFzIGl0IHJlc3VsdHMgYSBodW1hbiBhZ2VudCBv YnNlcnZhYmxlIHN0aW11bHVzLCBlLmcuIGF1ZGlhbCwgdmlzdWFsIG9yIG90aGVyd2lzZSwNCiBv biB3aGljaCB0aGUgaHVtYW4gYWdlbnQgY2FuIGV4cHJlc3MgaGlzIGRlY2lzaW9uIHRvIGNsYXNz aWZ5IGl0IGFzIOKAnHVud2FudGVk4oCdLiA8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIHRoaW5rIHRoZSBw cm9wZXIgbWVhbmluZyBvZiDigJw2NjYgdW53YW50ZWTigJ0gaXMg4oCcdGhlIGh1bWFuIGFnZW50 IGNvbnNpZGVycyB0aGlzIHBhcnRpY3VsYXIgY2FsbCBhcyB1bndhbnRlZOKAnSByYXRoZXIgdGhh biDigJx0aGUgaHVtYW4gYWdlbnQgZG9lcyBub3Qgd2FudCBhbnkgZnVydGhlciBjYWxscyBmcm9t DQogdGhpcyBjYWxsZXLigJ0uIEl0IHdpbGwgYmUgdGhlIG5ldHdvcmsgZGVjaXNpb24gd2hhdCBh Y3Rpb25zIHdpbGwgYmUgdGFrZW4gYmFzZWQgb24gdGhpcyBpbnB1dC4gVGhlcmVmb3JlLCBJIHRo aW5rIHRoZSBjdXJyZW50IHdvcmRpbmcgaW4gdGhlIGRyYWZ0IHNob3VsZCBiZSBjaGFuZ2VkIGFz IGluZGljYXRlZCBpbiBpaS0gYmVsb3c6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mcXVvdDtOb25lIG9mIHRoZSBleGlzdGluZyA0 eHgsIDV4eCBvciA2eHggcmVzcG9uc2UgY29kZXMgc2lnbmlmeSB0aGF0IGNhbGxzIGZyb20gdGhp cyBjYWxsZXIgYXJlIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQgcGFydHkuJnF1b3Q7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj49PSZn dDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZxdW90O05vbmUgb2YgdGhlIGV4aXN0aW5nIDR4eCwgNXh4IG9yIDZ4eCByZXNwb25z ZSBjb2RlcyBzaWduaWZ5IHRoYXQgdGhpcyBjYWxsIGlzIHVud2FudGVkIGJ5IHRoZSBjYWxsZWQg cGFydHkuJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIGFub3RoZXIgbm90ZTogSXMgdGhlcmUgYSBu ZWVkIHRvIHN1cHBseSBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIGFzIGZhciBhcyBkaWZmZXJlbnQg c2Vzc2lvbiB0eXBlcyBhcmUgY29uY2VybmVkLCBlLmcuIGF1ZGlvIGNhbGwgdi5zLiB2aWRlbyBj YWxsIHYucy4gSU0/IFRoZXJlIGNvdWxkIGJlIHNpdHVhdGlvbnMNCiB3aGVyZSB0aGlzIGlzIHVz ZWZ1bCwgZS5nLiBodW1hbiBhZ2VudCBpcyBmaW5lIHdpdGggSU0gYnV0IGRvZXMgbm90IHdhbnQg dm9pY2UgY2FsbHMgZnJvbSBhIGNlcnRhaW4gY2FsbGluZyBwYXJ0eS4gT1RPSCwgSSB0aGluayB0 aGlzIGFnYWluIHNob3VsZCBiZSBoYW5kbGVkIGJ5IHRoZSBuZXR3b3JrIGl0c2VsZiBhbmQgdGhl IGNoYW5nZSBJIHN1Z2dlc3RlZCBhYm92ZSB3b3VsZCBiZSBoZWxwZnVsIGluIHRoaXMgc2Vuc2Ug YXMgd2VsbDogNjY2DQogbWVhbnMgdGhhdCBodW1hbiBhZ2VudCBjb25zaWRlcnMgdGhpcyBwYXJ0 aWN1bGFyIHNlc3Npb24gYXMgdW53YW50ZWQuIEl0IGRvZXMgbm90IHRlbGwgYW55dGhpbmcgbW9y ZSBhcyBmYXIgYXMgb3RoZXIgc2Vzc2lvbnMgb2YgdGhlIHNhbWUgdHlwZSBvciBvZiBvdGhlciBz ZXNzaW9uIHR5cGVzIGFyZSBjb25jZXJuZWQuIEhlIHdvdWxkIGNvbW11bmljYXRlIGhpcyBjaG9p Y2VzIHJlZ2FyZGluZyBob3cgdGhpcyBpbmZvcm1hdGlvbiBuZWVkcyB0bw0KIGJlIHRyZWF0ZWQg Ynkgb3RoZXIgbWVhbnMsIGUuZy4gdmlhIGEgV2ViIFBvcnRhbCwgaWYgc3VjaCBhIGEgc2Vydmlj ZSBpcyBwcm92aWRlZCBieSB0aGUgb3BlcmF0b3IuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRvbGdhPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4g NC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IEhlbm5pbmcgU2NodWx6cmlubmUgWzxhIGhyZWY9Im1haWx0bzpIZW5uaW5nLlNjaHVsenJp bm5lQGZjYy5nb3YiPm1haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8L2E+XQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDE3IDY6MTQgUE08YnI+DQo8 Yj5Ubzo8L2I+IEFzdmVyZW4sIFRvbGdhICZsdDs8YSBocmVmPSJtYWlsdG86dGFzdmVyZW5Ac29u dXNuZXQuY29tIj50YXN2ZXJlbkBzb251c25ldC5jb208L2E+Jmd0OzsgQnJldHQgVGF0ZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb20iPmJyZXR0QGJyb2Fkc29mdC5jb208 L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBpZD0ieF9kaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5PbiAoaSksIEkgYWdyZWUgdGhhdCB3ZSBkb24ndCB3YW50IHRvIGdldCBpbnRvIHdoYXQg aW5mb3JtYXRpb24gaXMgYmVpbmcgdXNlZCwgZ2l2ZW4gdGhhdCB0aGUgZW50aXR5IG1vc3QgbGlr ZWx5IHRvIHVzZSB0aGUgNjY2IGluZm9ybWF0aW9uLCBpLmUuLCB0aGUgdGVybWluYXRpbmcgY2Fy cmllciwgaXMgYWxzbyB0aGUgb25lIGRlY2lkaW5nDQogaG93IGNhbGxlciBpZGVudGl0eSBpcyBi ZWluZyBwcmVzZW50ZWQgdG8gdGhlIHVzZXIgKFBBSSwgRnJvbSwgZXRjLikuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+VGFzdGVzIG1heSBkaWZmZXIsIGJ1dCBJIGRvbid0IHNlZSBob3cgd2Ug Y2FuIHNheSBtdWNoIHRoYXQncyB1c2VmdWwgdG8gaW1wbGVtZW50b3JzIGhlcmUsIHdpdGhvdXQg Z2V0dGluZyBpbnRvIHdlZWRzIHRoYXQgYXJlIGFscmVhZHkgYmVpbmcgZXhwbG9yZWQgYnkgKHNh eSkgdGhlIFNIQUtFTiBlZmZvcnQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QWxzbywgSSdt IG5vdCBjb252aW5jZWQgdGhhdCBkZWZpbmluZyAmcXVvdDtjYWxsJnF1b3Q7IGlzIG5lZWRlZCBo ZXJlLCBnaXZlbiB0aGF0IHdlJ2QgcHJvYmFibHkgbm90IGdvIG11Y2ggYmV5b25kIHdoYXQncyBp biBSRkMgMzI2MTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZDt3 aGl0ZS1zcGFjZTpwcmUtd3JhcCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5DYWxsOiBBIGNh bGwgaXMgYW4gaW5mb3JtYWwgdGVybSB0aGF0IHJlZmVycyB0byBzb21lIGNvbW11bmljYXRpb248 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYmV0d2VlbiBw ZWVycywgZ2VuZXJhbGx5IHNldCB1cCBmb3IgdGhlIHB1cnBvc2VzIG9mIGE8L3NwYW4+PG86cD48 L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGltZWRpYSBjb252ZXJzYXRp b24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5BbHNvLCBnaXZlbiB0aGUgZGlzY3Vzc2lvbiBvZiB1c2FnZSBmb3Igbm9uLUlOVklURSwg SSdsbCBjaGFuZ2UgJnF1b3Q7Y2FsbCZxdW90OyB0byAmcXVvdDtyZXF1ZXN0JnF1b3Q7IG9yICZx dW90O2RpYWxvZyZxdW90OyB3aGVyZSB0aGUgY29udGV4dCBpcyBtb3JlIHRoYW4ganVzdCBhbiBl eGFtcGxlIG9mIHdoYXQgaXMgbGlrZWx5IHRvIGJlIHRoZSBtb3N0IGNvbW1vbg0KIGNhc2UgLSBJ TlZJVEUgZm9yIGEgcGhvbmUgY2FsbC4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGVubmlu Zzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBh bGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdp ZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIiPg0KPC9kaXY+DQo8ZGl2IGlkPSJ4X2RpdlJwbHlGd2RN c2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gc2lwY29yZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+c2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYgb2YgQXN2ZXJlbiwgVG9sZ2EgJmx0Ozxh IGhyZWY9Im1haWx0bzp0YXN2ZXJlbkBzb251c25ldC5jb20iPnRhc3ZlcmVuQHNvbnVzbmV0LmNv bTwvYT4mZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDUsIDIwMTcgMTA6 MjI6NTUgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyZXR0IFRhdGU7IDxhIGhyZWY9Im1haWx0bzpzaXBj b3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50 ZWQtMDE8L3NwYW4+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SSBhZ3Jl ZSB0aGF0IGRlZmluaW5nIHdoYXQgYSAmcXVvdDtjYWxsJnF1b3Q7IGlzIGEgZ29vZCBpZGVhIGJ1 dCBJIGhhdmUgYSBkaWZmZXJlbnQgdGFrZSBvbiB3aGF0IGl0IHNob3VsZCBzYXk6PGJyPg0KPGJy Pg0KaS0mbmJzcDsgQSAmcXVvdDtjYWxsJnF1b3Q7IGluIHRoZSBjb250ZXh0IG9mIHRoaXMgZG9j dW1lbnQgaXMgYSBjb21tdW5pY2F0aW9uIHNlc3Npb24gYXMgcGVyY2VpdmVkIGJ5IGEgaHVtYW4g YWdlbnQsIGUuZy4gYXMgaW4gJnF1b3Q7SSByZWNlaXZlZCBhIGNhbGwgZnJvbSBteSBncmFuZG1v dGhlci4mcXVvdDsuIEl0IGRvZXMgbm90IGltcGx5IGFueXRoaW5nIGZ1cnRoZXIgYXMgZmFyIGFz IFNJUCBpbmZvcm1hdGlvbiBlbGVtZW50cyB3aGljaCB1c3VhbGx5IGFyZSB1c2VkIHRvIGNhcnJ5 DQogY2FsbGluZyBwYXJ0eSBpZGVudGlmaWNhdGlvbiwgZS5nLiBQLUFzc2VydGVkLUlkLCBGcm9t IGhlYWRlcnMsIGFyZSBjb25jZXJuZWQuIEl0IGlzIHVwIHRvIHRoZSBvcGVyYXRvci9uZXR3b3Jr IHBvbGljeSBob3cgdG8gbWFrZSBhc3NvY2lhdGUgZnVydGhlciBjYWxscyB3aXRoIHRoZSBpbmZv cm1hdGlvbi9kZWNpc2lvbiBkZXJpdmVkIGZyb20gdW53YW50ZWQgY2FsbHMuPGJyPg0KPGJyPg0K aWktICZxdW90O05vbmUgb2YgdGhlIGV4aXN0aW5nIDR4eCwgNXh4IG9yIDZ4eCByZXNwb25zZSBj b2RlcyBzaWduaWZ5IHRoYXQgY2FsbHMgZnJvbSB0aGlzIGNhbGxlciBhcmUgdW53YW50ZWQgYnkg dGhlIGNhbGxlZCBwYXJ0eS4mcXVvdDs8YnI+DQo9PSZndDs8YnI+DQomcXVvdDtOb25lIG9mIHRo ZSBleGlzdGluZyA0eHgsIDV4eCBvciA2eHggcmVzcG9uc2UgY29kZXMgc2lnbmlmeSB0aGF0IHRo aXMgY2FsbCBpcyB1bndhbnRlZCBieSB0aGUgY2FsbGVkIHBhcnR5LiZxdW90Ozxicj4NCjxicj4N CkkgdGhpbmsgaWktIGlzIG5lZWRlZCB0byByZWxpdmUgdGhlIGVuZCB1c2VyIGZyb20gdGhlIGJ1 cmRlbiBvZiAmcXVvdDtrbm93aW5nIHRoZSBhY3R1YWwgY2FsbGVyJnF1b3Q7Ljxicj4NCjxicj4N ClRoYW5rcyw8YnI+DQpUb2xnYTxicj4NCjxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS08YnI+DQomZ3Q7IEZyb206IHNpcGNvcmUgWzxhIGhyZWY9Im1haWx0bzpzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBC ZWhhbGYgT2YgQnJldHQgVGF0ZTxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDUs IDIwMTcgNzo1NCBBTTxicj4NCiZndDsgVG86IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYu b3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCiZndDsgU3ViamVjdDogUmU6IFtzaXBjb3Jl XSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTAxPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFsc28gYWdyZWUgdGhh dCBhZGRpbmcgc3VjaCBhIHBhcmFncmFwaCB3b3VsZCBiZSB1c2VmdWwuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEZvciBpbnN0YW5jZSBpZiBzb21lb25lIGRlc2lyZXMgYSBzZXJ2aWNlIHRvIGZvcndh cmQgYWxsIHJlY2VpdmVkIHNwYW0gY2FsbHMgdG88YnI+DQomZ3Q7IGFub3RoZXIgc2V0IG9mIHZp Y3RpbXMsIHRoZXkgd291bGQgbGlrZWx5IG5vdCB1c2Ugc3VjaCBhIHNlcnZpY2UgaWYgdGhlPGJy Pg0KJmd0OyBmb3J3YXJkaW5nIHBhcnR5IG1pZ2h0IGFsc28gZ2V0IGZsYWdnZWQgYXMgcGFydCBv ZiB0aGUgNjY2IGhhbmRsaW5nLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsg LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7ICZndDsgRnJvbTogc2lwY29yZSBb PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnNpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBQYXVsPGJyPg0KJmd0OyBLeXppdmF0 PGJyPg0KJmd0OyAmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgSmFudWFyeSAwNCwgMjAxNyA3OjUxIFBN PGJyPg0KJmd0OyAmZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lw Y29yZUBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7ICZndDsgU3ViamVjdDogUmU6IFtzaXBjb3JlXSBD b21tZW50cyBvbjxicj4NCiZndDsgJmd0OyBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2Fu dGVkLTAxPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIDEvNC8xNyA1OjM1IFBNLCA8 YSBocmVmPSJtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iPm1hcmlhbm5lLm1vaGFs aUBvcmFuZ2UuY29tPC9hPiB3cm90ZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgJmd0 OyAtU2VjdGlvbiA0IGdlbmVyYWw6PGJyPg0KJmd0OyAmZ3Q7ICZndDsgSU1PLCBpdCB3b3VsZCBi ZSBnb29kIHRvIGhhdmUgYSBwYXJhZ3JhcGggYWRkcmVzc2luZyB0aGUgcXVlc3Rpb24gb2Y8YnI+ DQomZ3Q7ICZndDsgJmd0OyB0aGUgJnF1b3Q7Y2FsbGluZyBwYXJ0eSBudW1iZXImcXVvdDsgKG1l bnRpb25lZCBzZXZlcmFsIHRpbWUgaW4gdGhlIGRvY3VtZW50KTo8YnI+DQomZ3Q7ICZndDsgJmd0 OyBpbmRlZWQsIHRoaXMgY2FsbGluZyBwYXJ0eSBudW1iZXIgY2FuIGJlIGlkZW50aWZpZWQgYnkg dGhlIHRlbGVwaG9uZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG51bWJlci9hZGRyZXNzIGluIHRoZSBG cm9tIGhlYWRlciBvciB0aGUgb25lIGluIHRoZTxicj4NCiZndDsgJmd0OyAmZ3Q7IFAtQXNzZXJ0 ZWQtSWRlbnRpdHkgaGVhZGVyIHRoYXQgbWF5IGJlIGRpZmZlcmVudC4gRGVwZW5kaW5nIG9uIHRo ZTxicj4NCiZndDsgJmd0OyAmZ3Q7IG9uZSBkaXNwbGF5ZWQgdG8gdGhlIGNhbGxlZCBVQSwgdGhl IDY2NiBjb3VsZCBjb25jZXJuIG9ubHkgb25lIG9yPGJyPg0KJmd0OyAmZ3Q7ICZndDsgYm90aCBh ZGRyZXNzZXMgZGVwZW5kaW5nIG9uIHNlcnZpY2UgcHJvdmlkZXIgY2hvaWNlcy4gSWYgd2UgdGFr ZSB0aGU8YnI+DQomZ3Q7ICZndDsgJmd0OyBleGFtcGxlIG9mIGEgY2FsbC1jZW50ZXIgb3IgYW4g SVBCWCBoYXZpbmcgdGhlIGhlYWQgbnVtYmVyIGFuZCBhPGJyPg0KJmd0OyAmZ3Q7ICZndDsgcmFu Z2Ugb2YgcHJpdmF0ZSBudW1iZXJzLCB0aGUgc2VydmljZSBwcm92aWRlciBjb3VsZCBpbnRlcnBy ZXQgdGhlPGJyPg0KJmd0OyAmZ3Q7ICZndDsgNjY2IGZyb20gdGhlIGNhbGxlZCB1c2VyIG9ubHkg Zm9yIHRoZSBwcml2YXRlIG51bWJlciAoaW4gdGhlIEZyb208YnI+DQomZ3Q7ICZndDsgJmd0OyBo ZWFkZXIpIG9yIGZvciB0aGUgd2hvbGUgcG9vbCAoUC1Bc3NlcnRlZC1JZGVudGl0eSkuIEkgc3Vn Z2VzdCB0bzxicj4NCiZndDsgJmd0OyAmZ3Q7IGhhdmUgYSBwYXJhZ3JhcGggdG8gaGlnaGxpZ2h0 IHRoaXMgcG9pbnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEludGVyZXN0aW5nIHBv aW50LiBJZiB0aGUgUEFJRCBpcyBkaWZmZXJlbnQgZnJvbSB0aGUgbnVtYmVyIGRpc3BsYXllZDxi cj4NCiZndDsgJmd0OyB0bzxicj4NCiZndDsgdGhlPGJyPg0KJmd0OyAmZ3Q7IGNhbGxlZSwgYW5k IHRoZSBjYWxsZWUgcmVqZWN0cyB0aGUgY2FsbCB3aXRob3V0IGFuc3dlcmluZywgaG93IHNob3Vs ZDxicj4NCiZndDsgJnF1b3Q7YmxhbWUmcXVvdDs8YnI+DQomZ3Q7ICZndDsgYmUgYXNzaWduZWQ/ IEZyb20gdGhlIGNhbGxsZWUncyBwZXJzcGVjdGl2ZSB0aGUgY29tcGxhaW50IGlzICphYm91dCo8 YnI+DQomZ3Q7ICZndDsgdGhlIG51bWJlciBoZSBzYXcsIHJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUg aWRlbnRpdHkgb2YgdGhlIGFjdHVhbCBjYWxsZXIgd2FzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MsPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhdWw8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQomZ3Q7ICZndDsgc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEg aHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZhbXA7 ZD1EZ0lDQWcmYW1wO2M9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZhbXA7cj1GSmNWb0RrV001RWlW Y1YwUmVYOGxEVTFYZUhJWVJIZmFycGs0TUs1OVJFJmFtcDttPVR5US1ZbWlMOGJjSHBCNE9CNXNn aDVReDhGMFMxekVKalBZOEhoMDRDUG8mYW1wO3M9T1pvdmR4RG1yaXhTS2JGSkNFd01IeVpvanBV OHVZZVU5a28xTFlhQzVOWSZhbXA7ZT0iPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19zaXBj b3JlJmFtcDtkPURnSUNBZyZhbXA7Yz15MGgwb21DZTBqQVVHcjRnQVEwMkZ3JmFtcDtyPUZKY1Zv RGtXTTVFaVZjVjBSZVg4bERVMVhlSElZUkhmYXJwazRNSzU5UkUmYW1wO209VHlRLVltaUw4YmNI cEI0T0I1c2doNVF4OEYwUzF6RUpqUFk4SGgwNENQbyZhbXA7cz1PWm92ZHhEbXJpeFNLYkZKQ0V3 TUh5Wm9qcFU4dVllVTlrbzFMWWFDNU5ZJmFtcDtlPTwvYT4NCjxicj4NCiZndDsgPGJyPg0KJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZn dDsgc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3Jl QGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5v cmdfbWFpbG1hbl9saXN0aW5mb19zaXBjb3JlJmFtcDtkPURnSUNBZyZhbXA7Yz15MGgwb21DZTBq QVVHcjRnQVEwMkZ3JmFtcDtyPUZKY1ZvRGtXTTVFaVZjVjBSZVg4bERVMVhlSElZUkhmYXJwazRN SzU5UkUmYW1wO209VHlRLVltaUw4YmNIcEI0T0I1c2doNVF4OEYwUzF6RUpqUFk4SGgwNENQbyZh bXA7cz1PWm92ZHhEbXJpeFNLYkZKQ0V3TUh5Wm9qcFU4dVllVTlrbzFMWWFDNU5ZJmFtcDtlPSI+ DQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NpcGNvcmUmYW1wO2Q9RGdJQ0FnJmFtcDtjPXkw aDBvbUNlMGpBVUdyNGdBUTAyRncmYW1wO3I9RkpjVm9Ea1dNNUVpVmNWMFJlWDhsRFUxWGVISVlS SGZhcnBrNE1LNTlSRSZhbXA7bT1UeVEtWW1pTDhiY0hwQjRPQjVzZ2g1UXg4RjBTMXpFSmpQWThI aDA0Q1BvJmFtcDtzPU9ab3ZkeERtcml4U0tiRkpDRXdNSHlab2pwVTh1WWVVOWtvMUxZYUM1Tlkm YW1wO2U9PC9hPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3 LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZhbXA7ZD1EZ0lDQWcmYW1wO2M9eTBo MG9tQ2UwakFVR3I0Z0FRMDJGdyZhbXA7cj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFYZUhJWVJI ZmFycGs0TUs1OVJFJmFtcDttPVR5US1ZbWlMOGJjSHBCNE9CNXNnaDVReDhGMFMxekVKalBZOEho MDRDUG8mYW1wO3M9T1pvdmR4RG1yaXhTS2JGSkNFd01IeVpvanBVOHVZZVU5a28xTFlhQzVOWSZh bXA7ZT0iPmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2lwY29yZSZhbXA7ZD1EZ0lDQWcmYW1w O2M9eTBoMG9tQ2UwakFVR3I0Z0FRMDJGdyZhbXA7cj1GSmNWb0RrV001RWlWY1YwUmVYOGxEVTFY ZUhJWVJIZmFycGs0TUs1OVJFJmFtcDttPVR5US1ZbWlMOGJjSHBCNE9CNXNnaDVReDhGMFMxekVK alBZOEhoMDRDUG8mYW1wO3M9T1pvdmR4RG1yaXhTS2JGSkNFd01IeVpvanBVOHVZZVU5a28xTFlh QzVOWSZhbXA7ZT08L2E+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18gc2lwY29yZSBtYWlsaW5nIGxpc3QNCjxhIGhyZWY9Im1haWx0bzpzaXBjb3Jl QGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN2PR03MB235036253E8B75E1138F1185B2780SN2PR03MB2350namp_-- From nobody Thu Jan 12 23:40:58 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDEF129495 for ; Thu, 12 Jan 2017 23:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vHh1lsrf1x6 for ; Thu, 12 Jan 2017 23:40:53 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8CF7129AEA for ; Thu, 12 Jan 2017 23:40:49 -0800 (PST) X-AuditID: c1b4fb25-3f77f980000042ea-45-5878847fe27f Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by (Symantec Mail Security) with SMTP id 7B.E8.17130.F7488785; Fri, 13 Jan 2017 08:40:48 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC020.ericsson.se ([153.88.183.78]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 08:40:46 +0100 From: Christer Holmberg To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdm0E02YJFp00GoTEcPhv1fDKE2F1AA Date: Fri, 13 Jan 2017 07:40:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.1.161129 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyM2K7n25DS0WEQcdGHos9fxexW3z9sYnN gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mq4u3A2a8FC7or1nz+zNzCu4+xi5OSQEDCR OLDrM2MXIxeHkMA6Rokrq6+xQThLGCXOtn1j6mLk4GATsJDo/qcN0iAiYC/x9utaVhBbWMBF Yl3DQhaIuKvEv45bULaRxMZ73WA2i4CqxMvPE9hBbF4Ba4nXC/aDxYUE7CT6/+8Ci3MCzVx3 Zy0jiM0oICbx/dQaJhCbWUBc4taT+UwQhwpILNlznhnCFpV4+fgf2A2iAnoSy5+vgYorSlyd vhyqV0diwe5PbBC2tcSExx2sELa2xLKFr5kh7hGUODnzCcsERrFZSNbNQtI+C0n7LCTts5C0 L2BkXcUoWpxanJSbbmSsl1qUmVxcnJ+nl5dasokRGFcHt/xW3cF4+Y3jIUYBDkYlHt4CrooI IdbEsuLK3EOMEhzMSiK8a5uAQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5N LUgtgskycXBKNTCGt7q75C3tM3lh8uIls7CETImH87UUt2/6dkcXvchgeP3h0Is/2T6/f388 aq38qV7d+E3ZxN6LjWdnM7x7znjxdtFzJb/+9Iv1UUtfnlZ9HHHS4/z+j7OLeLLSucUtjvHd qKt4FndcUWvzbN+rK4Vdbi2Y9lzoqEym65PtOrb2KrzSl97O3HxUiaU4I9FQi7moOBEAWWjE tKcCAAA= Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 07:40:55 -0000 Hi, I support the adoption of all 3 documents. I will author the second (draft-content-id). Regards, Christer On 13/01/17 02:52, "sipcore on behalf of Adam Roach" wrote: >[as chair] > >As I mentioned in an earlier message, we have new milestones for >SIPCORE, many of which we hope to finish in the first half of the year. >To that end, I'd like to call for adoption of the documents that >prompted adding the milestones. To be specific: > >We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the >milestone "mechanism for labeling the nature of SIP calls" > >We propose adopting draft-holmberg-sipcore-content-id for the milestone >"clarification of the use of Content-ID" > >We propose adopting draft-sparks-sipcore-name-addr-guidance for the >milestone "clarification of the use of name-addr" > >I'll note that these document -- and in particular the last two -- have >had significant discussion and feedback already. In particular, the >author of draft-sparks-sipcore-name-addr-guidance indicates that he >believes that document is "done" and basically ready for last call. > >Please provide feedback regarding adoption of these documents by Friday, >January 27. Thanks! > >/a > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jan 13 00:04:32 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E0C912947D for ; Fri, 13 Jan 2017 00:04:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E_Rypi_gj-Ox for ; Fri, 13 Jan 2017 00:04:29 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DAA1129409 for ; Fri, 13 Jan 2017 00:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Z74ctryThjdhCmy1YftbJrcIL/mbewKD8OwhWoEsgqk=; b=EwSlTBniI2TJObPt8RPibuk8ZeJiPbwIV/lluniUUhAI3xymOjNKqc99GwaseFjrlaVuf9CnwwJkzXRrzyrDU6QSuth1hxmQDsZ+rzUYyJjik53aPOFBgtvCz7r3OR8jNqR7eOOiC7GcYHdFAk0xq+UAcdV9XauHrC9xuQ9RfCg= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-143-qIcmpI_jP8-cgYnBHDG7mQ-1; Fri, 13 Jan 2017 03:04:25 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2352.namprd03.prod.outlook.com (10.166.210.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Fri, 13 Jan 2017 08:04:22 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0845.013; Fri, 13 Jan 2017 08:04:21 +0000 From: "Asveren, Tolga" To: Christer Holmberg , Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdQZ/4EoUfqQ0GSCqQgwoyVVaE2BkUAgAAGZKA= Date: Fri, 13 Jan 2017 08:04:21 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 7ac46242-44b8-43e9-04b9-08d43b8ac868 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2352; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2352; 7:kMNeFLaYYsajIGvEG7hXfkr7swn1/Fh/gUX0lTX0+AVFfx+XrpMOf0zmZyYOFoHgsNJ320Yfhq1VAX5Gt1Dr/zwHYMOoBCmeeRA5+BsrcFKZJEr2wXub5Fs5YH161bSuA/ge5GTRyBz/yw4Urh25omdpUWXO8Mq2zcOK2AgQkwGmtBBoawrxKnmvt672hUibdvDWfGz1EWNAOV5ZcsH91og2SnLaCXeIEoyRPnhk0ISLXGT+Dch/fONhi0ju+7cRmqC2cXn902kMO2qkisLK4P6KWHRLAeae45MDedZ28ObS3qOcyr1/hKaq3EsbzrcAccAtOA/BUWFiKWXF1FA/yMattR4tPyudkyLZf1/mIzRopa+n2Xy/zbTxGY8sIxperYINpUA63NqhdlR72oKpb/3TWZ0Mc9U/LJVXHwaqD0x6Om4lmTU64QpHl9LdIdSkJCiaqS/PR4rk4Lg/TCrNsg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123558021)(20161123555025)(20161123562025)(20161123564025)(6047074)(6072148); SRVR:SN2PR03MB2352; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2352; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(13464003)(199003)(377454003)(189002)(24454002)(2900100001)(33656002)(105586002)(66066001)(106356001)(106116001)(2906002)(5660300001)(3280700002)(7696004)(68736007)(229853002)(38730400001)(77096006)(25786008)(55016002)(99286003)(6306002)(81156014)(74316002)(6436002)(81166006)(6506006)(8676002)(305945005)(7736002)(2950100002)(102836003)(6116002)(8936002)(92566002)(3660700001)(9686003)(189998001)(107886002)(3846002)(122556002)(5001770100001)(97736004)(101416001)(54356999)(76176999)(50986999)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2352; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 08:04:21.7486 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2352 X-MC-Unique: qIcmpI_jP8-cgYnBHDG7mQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:04:31 -0000 I also support adoption for all of them and hope that discussions for other= items under consideration can continue so that a conclusion can be reached= . Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer > Holmberg > Sent: Friday, January 13, 2017 2:41 AM > To: Adam Roach ; 'SIPCORE' > Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones >=20 > Hi, >=20 > I support the adoption of all 3 documents. I will author the second (draf= t- > content-id). >=20 > Regards, >=20 > Christer >=20 >=20 >=20 > On 13/01/17 02:52, "sipcore on behalf of Adam Roach" > wrote: >=20 > >[as chair] > > > >As I mentioned in an earlier message, we have new milestones for > >SIPCORE, many of which we hope to finish in the first half of the year. > >To that end, I'd like to call for adoption of the documents that > >prompted adding the milestones. To be specific: > > > >We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the > >milestone "mechanism for labeling the nature of SIP calls" > > > >We propose adopting draft-holmberg-sipcore-content-id for the milestone > >"clarification of the use of Content-ID" > > > >We propose adopting draft-sparks-sipcore-name-addr-guidance for the > >milestone "clarification of the use of name-addr" > > > >I'll note that these document -- and in particular the last two -- have > >had significant discussion and feedback already. In particular, the > >author of draft-sparks-sipcore-name-addr-guidance indicates that he > >believes that document is "done" and basically ready for last call. > > > >Please provide feedback regarding adoption of these documents by > >Friday, January 27. Thanks! > > > >/a > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jan 13 00:14:48 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0F271294CA for ; Fri, 13 Jan 2017 00:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQFdimOf_RCk for ; Fri, 13 Jan 2017 00:14:44 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C360129B08 for ; Fri, 13 Jan 2017 00:14:44 -0800 (PST) Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 855403000; Fri, 13 Jan 2017 09:14:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jan 2017 09:14:30 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:14:47 -0000 > On 13 Jan 2017, at 01:52, Adam Roach wrote: >=20 > [as chair] >=20 > As I mentioned in an earlier message, we have new milestones for = SIPCORE, many of which we hope to finish in the first half of the year. = To that end, I'd like to call for adoption of the documents that = prompted adding the milestones. To be specific: >=20 > We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the = milestone "mechanism for labeling the nature of SIP calls=E2=80=9D Agree >=20 > We propose adopting draft-holmberg-sipcore-content-id for the = milestone "clarification of the use of Content-ID=E2=80=9D Agree >=20 > We propose adopting draft-sparks-sipcore-name-addr-guidance for the = milestone "clarification of the use of name-addr=E2=80=9D Agree >=20 > I'll note that these document -- and in particular the last two -- = have had significant discussion and feedback already. In particular, the = author of draft-sparks-sipcore-name-addr-guidance indicates that he = believes that document is "done" and basically ready for last call. >=20 > Please provide feedback regarding adoption of these documents by = Friday, January 27. Thanks! Go ahead. Cheers, /O= From nobody Fri Jan 13 00:29:29 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2AA129B23 for ; Fri, 13 Jan 2017 00:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shSMy9R1Mn80 for ; Fri, 13 Jan 2017 00:29:24 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC35129B1B for ; Fri, 13 Jan 2017 00:29:24 -0800 (PST) Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A76C73CFA; Fri, 13 Jan 2017 09:29:11 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_86741C5F-26FC-4438-8A00-46F0D6DA2082" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 13 Jan 2017 09:29:00 +0100 Message-Id: <0F8841CC-1F08-463E-8C61-4AB8FBF08A4D@edvina.net> References: <87lgug6xds.fsf@hobgoblin.ariadne.com> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:29:27 -0000 --Apple-Mail=_86741C5F-26FC-4438-8A00-46F0D6DA2082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Rifaat, THank you for your work on this and coming back. I feel we need to have some writing about how to migrate. There is a = significant risk of downgrade attacks if we have both mechanisms running, like you get two challenges or one = challenge with two algorithms (if that=E2=80=99s possible). The web has a simpler upgrade path, given = the small amount of browsers that operate a majority of the requests. We have many years of legacy software that = propably will not upgrade unless customers require it. And it will take some time to get new firmware out there = with support for this unless there=E2=80=99s significant customer demand. We definitiely need to get this done and move SIPconnect 2.x to require = this on public networks and forbid MD5 in those situations as a first step. Hopefully that can help = some customers to demand the right thing. How do an operator of a service upgrade to SHA2? Do we have to have a = cut-off date and stop accepting MD5, do we migrate somehow or do we mark =E2=80=9Cnew=E2=80=9D = phones for ONLY SHA2 and old clients for MD5 and SHA2 in some authentication service database? Implementors need to know how to handle this and I haven=E2=80=99t = figured out any good solution in my own head since we started this discussion five years ago or so=E2=80=A6. If we can solve this process now, we=E2=80=99re in better shape when = SHA2 becomes the algorithm that no one wants to use any more. /O =20 > On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef = wrote: >=20 > Thanks Dale! >=20 > Please, see my reply inline... >=20 > Regards, > Rifaat >=20 >=20 > On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley > wrote: > Rifaat Shekh-Yusef > writes: > > RFC7617 updated the *HTTP Digest* mechanism and added support for = *SHA2* to > > replace the MD5 algorithm. > > > > I am trying to revolve this old draft that does the same for SIP: > > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ = >=20 > It makes sense to do this, of course, as MD-5 is thoroughly obsolete. >=20 > As a matter of exposition, you say "This section does NOT maintain > backward compatibility with RFC 2069." But of course as a consequence > of that, it isn't compatible with RFC 3261 either. >=20 > The statement you quoted was in the previous version of the document, = but not in v05. > If I remember correctly, we discussed that and during one of the IETF = meetings and it was deemed unnecessary to maintain that. > We did the same with the new HTTP Digest mechanism defined in RFC7616. >=20 > Is that a problem for SIP? >=20 >=20 > =20 >=20 > I'd like to see a description of how the draft's section 2.6 compares > with the existing SIP authentication scheme -- is this just adding the > new algorithms and making qop mandatory? >=20 > Yes, the idea is that this draft will add the SHA2 algorithms as the = recommended algorithms, and only keep the MD5 for backward = compatibility. >=20 > Regards, > Rifaat >=20 >=20 > =20 > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_86741C5F-26FC-4438-8A00-46F0D6DA2082 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Rifaat,
THank you for your work on this and = coming back.

I = feel we need to have some writing about how to migrate. There is a = significant risk of downgrade attacks
if we have = both mechanisms running, like you get two challenges or one challenge = with two algorithms
(if that=E2=80=99s possible). = The web has a simpler upgrade path, given the small amount of browsers = that operate
a majority of the requests. We have = many years of legacy software that propably will not upgrade unless = customers
require it. And it will take some time to = get new firmware out there with support for this unless there=E2=80=99s = significant
customer demand.
We definitiely need to get this done = and move SIPconnect 2.x to require this on public networks and
forbid MD5 in those situations as a first step. Hopefully = that can help some customers to demand the right thing.

How do an operator of a = service upgrade to SHA2? Do we have to have a cut-off date and = stop
accepting MD5, do we migrate somehow or do we = mark =E2=80=9Cnew=E2=80=9D phones for ONLY SHA2 and old = clients
for MD5 and SHA2 in some authentication = service database?

Implementors need to know how to handle this and I haven=E2=80=99= t figured out any good solution in my own
head = since we started this discussion five years ago or so=E2=80=A6.

If we can solve this = process now, we=E2=80=99re in better shape when SHA2 becomes the = algorithm that no one
wants to use any = more.

/O


 
On = 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thanks Dale!

Please, see my reply inline...

Regards,
 Rifaat


On Thu, = Jan 12, 2017 at 11:44 AM, Dale R. Worley <worley@ariadne.com> wrote:
Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> writes:
> RFC7617 updated the *HTTP Digest* mechanism and added support for = *SHA2* to
> replace the MD5 algorithm.
>
> I am trying to revolve this old draft that does the same for = SIP:
> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/

It makes sense to do this, of course, as MD-5 is thoroughly = obsolete.

As a matter of exposition, you say "This section does NOT maintain
backward compatibility with RFC 2069."  But of course as a = consequence
of that, it isn't compatible with RFC 3261 either.

The statement you quoted = was in the previous version of the document, but not in v05.
If I remember correctly, we discussed that and during one of = the IETF meetings and it was deemed unnecessary to maintain = that.
We did the same with the new HTTP Digest = mechanism defined in RFC7616.

Is that a problem for SIP?


 

I'd like to see a description of how the draft's section 2.6 compares
with the existing SIP authentication scheme -- is this just adding = the
new algorithms and making qop mandatory?

Yes, the idea is = that this draft will add the SHA2 algorithms as the recommended = algorithms, and only keep the MD5 for backward compatibility.

Regards,
 Rifaat


 
Dale

_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_86741C5F-26FC-4438-8A00-46F0D6DA2082-- From nobody Fri Jan 13 09:49:35 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3CE1294FE for ; Fri, 13 Jan 2017 09:49:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blR6CiabN-Kh for ; Fri, 13 Jan 2017 09:49:18 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E37E129CE4 for ; Fri, 13 Jan 2017 09:49:17 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id 137so38214390vkl.0 for ; Fri, 13 Jan 2017 09:49:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xwcXw0846cEsGqTSDfW8Mzf7RKtN030PrmsHKodSAko=; b=qDj8Fa3CaLm/DQAuD1o7pDfgbIZJWPRqIEiDe/te6P4d354FYDIKx0z6wDYFynJ2xy WKbaYX7ieps2pDN7ERbrl04etZreGlP2qa8KhhGWJIpwtTlfyJq1vtCuKa7VSNPkhrub opfR6VlhISbJd+pd51IChg5auIoxlVIFArQpHo3JgOh5ktmSvy6F4keENv0axnyz2YHC MH3W61roSM77JrmZBLRGrAFN/uYnEfI/kIxQK4zQuIiFtX9fXXwyKhGfA4HrehkCqe45 QB2VhzSOY6h3IadPt/cpe77BbUoRZWdRkr1TNuv+v1MEZ9vOWffARfD2HtxPuM61kjXz H0Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xwcXw0846cEsGqTSDfW8Mzf7RKtN030PrmsHKodSAko=; b=Un5LBVymlDWrNy2ml+/PTWHe48qE56gpxfJ6tYzjGYeCYg3h0R0fEBtH/Ppfkoliom das5fM2jNXcWMDtlChMxhXKb1ncpAgomf8p+ihaj4L3AQ8i09/bHjaNX0Er/GRK+IrkE ateEhAhOm8A8aqdf0TYLWimbNBBxgJ99I69VFSB3tJDLbIA5xJmsrSXSgstCsF4AApsW XFMLTf2OmKGtodw24dNL6vlX4oWeW0lVQEO4ke3oPiBzQH1a9677sS/6P0WHBhiNq/7n QnR9PAfbb8g0jlN+OxfJINo7Wv9a8sA2gOLH4ABc8f3GKXE8cEkvmnkMPCz0PpoGJ80w tQrA== X-Gm-Message-State: AIkVDXKKsbE8FegHBKMa+jnJfQk88sPnl1gpGdDKnPshnYco5x+Pw1NobQ/lUGmDoIpp+eiTuOUdYTSnogLxDg== X-Received: by 10.31.165.202 with SMTP id o193mr9971289vke.95.1484329756873; Fri, 13 Jan 2017 09:49:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Fri, 13 Jan 2017 09:49:16 -0800 (PST) In-Reply-To: <0F8841CC-1F08-463E-8C61-4AB8FBF08A4D@edvina.net> References: <87lgug6xds.fsf@hobgoblin.ariadne.com> <0F8841CC-1F08-463E-8C61-4AB8FBF08A4D@edvina.net> From: Rifaat Shekh-Yusef Date: Fri, 13 Jan 2017 12:49:16 -0500 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a114163b8e35b0e0545fd7373 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 17:49:22 -0000 --001a114163b8e35b0e0545fd7373 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Olle, This document gives the operator the tools to migrate, but *migration policy *is probably be out of scope this document. What do others think? Regards, Rifaat On Fri, Jan 13, 2017 at 3:29 AM, Olle E. Johansson wrote: > Rifaat, > THank you for your work on this and coming back. > > I feel we need to have some writing about how to migrate. There is a > significant risk of downgrade attacks > if we have both mechanisms running, like you get two challenges or one > challenge with two algorithms > (if that=E2=80=99s possible). The web has a simpler upgrade path, given t= he small > amount of browsers that operate > a majority of the requests. We have many years of legacy software that > propably will not upgrade unless customers > require it. And it will take some time to get new firmware out there with > support for this unless there=E2=80=99s significant > customer demand. > > We definitiely need to get this done and move SIPconnect 2.x to require > this on public networks and > forbid MD5 in those situations as a first step. Hopefully that can help > some customers to demand the right thing. > > How do an operator of a service upgrade to SHA2? Do we have to have a > cut-off date and stop > accepting MD5, do we migrate somehow or do we mark =E2=80=9Cnew=E2=80=9D = phones for ONLY > SHA2 and old clients > for MD5 and SHA2 in some authentication service database? > > Implementors need to know how to handle this and I haven=E2=80=99t figure= d out any > good solution in my own > head since we started this discussion five years ago or so=E2=80=A6. > > If we can solve this process now, we=E2=80=99re in better shape when SHA2= becomes > the algorithm that no one > wants to use any more. > > /O > > > > > On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef > wrote: > > Thanks Dale! > > Please, see my reply inline... > > Regards, > Rifaat > > > On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley > wrote: > >> Rifaat Shekh-Yusef writes: >> > RFC7617 updated the *HTTP Digest* mechanism and added support for >> *SHA2* to >> > replace the MD5 algorithm. >> > >> > I am trying to revolve this old draft that does the same for SIP: >> > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ >> >> It makes sense to do this, of course, as MD-5 is thoroughly obsolete. >> >> As a matter of exposition, you say "This section does NOT maintain >> backward compatibility with RFC 2069." But of course as a consequence >> of that, it isn't compatible with RFC 3261 either. > > > The statement you quoted was in the previous version of the document, but > not in v05. > If I remember correctly, we discussed that and during one of the IETF > meetings and it was deemed unnecessary to maintain that. > We did the same with the new HTTP Digest mechanism defined in RFC7616. > > Is that a problem for SIP? > > > > > >> I'd like to see a description of how the draft's section 2.6 compares >> with the existing SIP authentication scheme -- is this just adding the >> new algorithms and making qop mandatory? >> >> Yes, the idea is that this draft will add the SHA2 algorithms as the > recommended algorithms, and only keep the MD5 for backward compatibility. > > Regards, > Rifaat > > > > >> Dale >> > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --001a114163b8e35b0e0545fd7373 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Olle,

This document gives the op= erator the tools to migrate, but migration policy is probably be out= of scope this document.


What do ot= hers think?

Regards,
=C2=A0Rifaat
<= div>


On Fri, Jan 13, 2017 at 3:29 AM, Olle E. Johansson <oej@edv= ina.net> wrote:
Rifaat,
THank you for your work on this and c= oming back.

I feel we need to have some writing ab= out how to migrate. There is a significant risk of downgrade attacks
<= div>if we have both mechanisms running, like you get two challenges or one = challenge with two algorithms
(if that=E2=80=99s possible). The w= eb has a simpler upgrade path, given the small amount of browsers that oper= ate
a majority of the requests. We have many years of legacy soft= ware that propably will not upgrade unless customers
require it. = And it will take some time to get new firmware out there with support for t= his unless there=E2=80=99s significant
customer demand.

We definitiely need to get this done and move SIPconnect 2.= x to require this on public networks and
forbid MD5 in those situ= ations as a first step. Hopefully that can help some customers to demand th= e right thing.

How do an operator of a service upg= rade to SHA2? Do we have to have a cut-off date and stop
acceptin= g MD5, do we migrate somehow or do we mark =E2=80=9Cnew=E2=80=9D phones for= ONLY SHA2 and old clients
for MD5 and SHA2 in some authenticatio= n service database?

Implementors need to know how = to handle this and I haven=E2=80=99t figured out any good solution in my ow= n
head since we started this discussion five years ago or so=E2= =80=A6.

If we can solve this process now, we=E2=80= =99re in better shape when SHA2 becomes the algorithm that no one
wants to use any more.

/O


=C2=A0
On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>= wrote:

<= /div>
Thanks Dale!
Please, see my reply inline...

Regard= s,
=C2=A0Rifaat

On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worl= ey <worley@ariadne.com> wrote:
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> writes:
> RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA= 2* to
> replace the MD5 algorithm.
>
> I am trying to revolve this old draft that does the same for SIP:
> https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/

It makes sense to do this, of course, as MD-5 is thoroughly obsolete= .

As a matter of exposition, you say "This section does NOT maintain
backward compatibility with RFC 2069."=C2=A0 But of course as a conseq= uence
of that, it isn't compatible with RFC 3261 either.
The statement you quoted was in the previous version of the doc= ument, but not in v05.
If I remember correctly, we discussed that= and during one of the IETF meetings and it was deemed unnecessary to maint= ain that.
We did the same with the new HTTP Digest mechanism defi= ned in RFC7616.

Is that a problem for SIP?


=C2=A0

I'd like to see a description of how the draft's section 2.6 compar= es
with the existing SIP authentication scheme -- is this just adding the
new algorithms and making qop mandatory?

Yes, the idea is that this draft will add the = SHA2 algorithms as the recommended algorithms, and only keep the MD5 for ba= ckward compatibility.

Regards,
=C2=A0Rif= aat


=C2=A0
Dale

_______________________________________________
sipcore mailing lis= t
sipcore@ietf.org=
https://www.ietf.org/mailman/listinfo/sipcore


_________________________________= ______________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore<= br>

--001a114163b8e35b0e0545fd7373-- From nobody Fri Jan 13 12:49:08 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3DD129C6F for ; Fri, 13 Jan 2017 12:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CSAQqRWzPpBf for ; Fri, 13 Jan 2017 12:49:03 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C162612949F for ; Fri, 13 Jan 2017 12:49:03 -0800 (PST) Received: from pps.filterd (m0103509.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0DKj7kd001236 for ; Fri, 13 Jan 2017 15:49:03 -0500 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0a-001d8301.pphosted.com with ESMTP id 27ttgtg5v6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 13 Jan 2017 15:49:03 -0500 Received: by mail-lf0-f70.google.com with SMTP id h65so25491111lfi.1 for ; Fri, 13 Jan 2017 12:49:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=9l2fklCaOQhVhruSXxTm8IGV2qSqK8elWyyoAuNuCv8=; b=n4bxXDN9tGKrHCnZwzrynSE03jniRU1tfP2E/8vzMRvPVw5/aH2DHmIwn6l0WFTkxz clWlo41TZHP4/Jc8QSQeAFv/RHm8OKh1xNs2W4+a5QkWZ3uRGF6dxCPCmgg7c1S20R/n 5RHbHuIiAfX9b7dMuuoLauPb+EYvBTk3/pxOTzF/jgdFbfezdwRkDjVtIqldNbB2nl5f IL22g5/zsf2nBQPISO3X0mUIgLrIZNBqqUt8eBkIWiWqpU1lc40Xl7cIVMMWQd+Coy3n /C6zGR0Fz//HJOgM1GXEGN5fOjs6Ogd4fHKQsHF3l1sacIFeC9DAXeh2iQn+5g9Lyg1d l0oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=9l2fklCaOQhVhruSXxTm8IGV2qSqK8elWyyoAuNuCv8=; b=HR0XBigdgCWAFb+ueV+g07AWtlKREukuwzAZ7hhZ1W95aYc+54TmSRWAbC5gfAExiu Re00kmqq8JK5ghMlPs/qAbs3R5Diqn0mkQ+3fwU7s0qMCZ/595YUlZBORVRIPOjDJ1zv kpmsgP6+exFAzSAeN7FMybgerHAInQuSka6WWYSdYIDV1207VHfZkYNsbr22BqPjX7Em j2XrXLJJgeX14oDJ2OAdQ+LGmR//9h0XS0Q+03VRcjr6KP43XAR6Jwo9l5awpqpQedL8 wtCy5+jZFEKHGMvy7CuyW6E1VIqC5dEJG/pH1PkmdehEUjNo1m3UKGT6I2mP08a1SF98 Xu9g== X-Gm-Message-State: AIkVDXIOtY5O3XZjI4tycHDHQLBCOKGFkYENHYqj8itdLeCBiefrLmoRWYp1N6Feg0lKZHEF34eUPK8U4VOTm8vFBhjSuXmaBKBMMbbGu6eZ05/yvCyWzGsdhYLy5cDxJbFPieKfg/ydagSP X-Received: by 10.46.14.9 with SMTP id 9mr7848188ljo.59.1484340540289; Fri, 13 Jan 2017 12:49:00 -0800 (PST) X-Received: by 10.46.14.9 with SMTP id 9mr7848182ljo.59.1484340540030; Fri, 13 Jan 2017 12:49:00 -0800 (PST) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdJt3jyCK2qfsd3kSo6lByIAVMok7g== Date: Fri, 13 Jan 2017 15:48:58 -0500 Message-ID: To: Henning Schulzrinne , sipcore@ietf.org Content-Type: multipart/alternative; boundary=f403045ea6de9d5cca0545fff667 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-13_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 20:49:06 -0000 --f403045ea6de9d5cca0545fff667 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Concerning calling party sending BYE with 666, I just thought that it potentially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a =E2=80=9Ccalling par= ty=E2=80=9D might get replaced by a =E2=80=9Ccalled party=E2=80=9D. Thus if the contro= ller doesn=E2=80=99t strip the Reason while relaying the BYE, it definitely would be possible since both are called parties. If the =E2=80=9Ccalling party=E2=80=9D gets replaced before =E2=80=9Ccalled= party=E2=80=9D sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party? Thanks, Brett *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Thursday, January 12, 2017 3:31 PM *To:* Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I=E2=80=99m afraid I don=E2=80=99t quite follow what text you are suggestin= g and I=E2=80=99m suspecting we=E2=80=99re well into the weeds at this point. My general incl= ination is to only state things where 666 differs from 6xx handling, rather than try to capture all possible status code issues that are generic to (most) 6xx codes. This avoids creating inadvertent contradictions or the need to update the document should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I=E2=80=99m not sure why the calling party would indicate 666. After receiv= ing a re-INVITE? In response to a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I=E2=80=99m misl= ed into dialing a number (e.g., as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning *From:* Brett Tate [mailto:brett@broadsoft.com ] *Sent:* Friday, January 06, 2017 12:32 PM *To:* marianne.mohali@orange.com; Henning Schulzrinne < Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected party to change mid-dialog 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagged by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party indicating 666. Other than a way to attack someone, I=E2=80=99m not sure i= f are any 3PCC, transfer, or other service situations where it might actually be appropriate. *From:* marianne.mohali@orange.com [mailto:marianne.mohali@orange.com] *Sent:* Friday, January 06, 2017 10:28 AM *To:* Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpretation when the caller has several identities used for this call (ie. From and P-Asserted-Identity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be considered has a fraudulent (ie. the calling party or the diverting party or both ?) ; I propose to add the following text: This document defines a mechanism by which a called party can reject an unwanted call without consideration of the calling party identification that remain to the service provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or after a diverting service in P-Asserted-Identity, From, History-Info or any concurrent header field that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --f403045ea6de9d5cca0545fff667 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

Concerning calling pa= rty sending BYE with 666, I just thought that it potentially should be disc= ussed.

=C2=A0

However, RFC 372= 5 figures 4 and figure 7 do show how a =E2=80=9Ccalling party=E2=80=9D migh= t get replaced by a =E2=80=9Ccalled party=E2=80=9D.=C2=A0 Thus if the contr= oller doesn=E2=80=99t strip the Reason while relaying the BYE, it definitel= y would be possible since both are called parties.

=C2=A0

If the =E2=80=9Ccalling party=E2=80=9D gets rep= laced before =E2=80=9Ccalled party=E2=80=9D sends BYE with 666, who should = be flagged: 1) calling party indicated within original INVITE or 2) newest = connected party?

Thanks= ,

Brett<= /p>

=C2=A0

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Thursday, January= 12, 2017 3:31 PM
To: Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org
Subject: RE: [sipcore] Comments on d= raft-ietf-sipcore-status-unwanted-01

=C2=A0

I=E2=80= =99m afraid I don=E2=80=99t quite follow what text you are suggesting and I= =E2=80=99m suspecting we=E2=80=99re well into the weeds at this point. My g= eneral inclination is to only state things where 666 differs from 6xx handl= ing, rather than try to capture all possible status code issues that are ge= neric to (most) 6xx codes. This avoids creating inadvertent contradictions = or the need to update the document should there be changes in the generic h= andling. In other words, 666 should be treated like 6xx unless otherwise no= ted.

=C2=A0

Thus, can you prov= ide suggested text?

=C2=A0

I= =E2=80=99m not sure why the calling party would indicate 666. After receivi= ng a re-INVITE? In response to a BYE? I admit that I lack the imagination a= s to how this would occur and why this would cause anything other than what= would happen for a generic 6xx response in those circumstances.

=

=C2=A0

Stretching the imagination, I cou= ld imagine the case where I=E2=80=99m misled into dialing a number (e.g., a= s part of a spam email) that turns out to be a robot peddling time shares. = I could send a BYE, with a 666 Reason.

=C2=A0

Is that the case you have in mind?

=C2=A0

Henning

=C2=A0

=C2=A0

Hi,

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

The draft potentially should also discuss the potential f= or the connected party to change mid-dialog 1) without it being communicate= d and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.=

=C2=A0

From a security consideration= s perspective, the wrong party might be flagged by the 666 when the connect= ed party changes.

=C2=A0

The d= raft should potentially also discuss the potential for calling party indica= ting 666.=C2=A0 Other than a way to attack someone, I=E2=80=99m not sure if= are any 3PCC, transfer, or other service situations where it might actuall= y be appropriate.

=C2=A0

=C2= =A0

Fr= om: marianne.mohali@orange.com [mailto:= marianne.m= ohali@orange.com]
Sent: Friday, January 0= 6, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett T= ate; sipcore@ietf.or= g
Subject: RE: [sipcore] Comments on draft= -ietf-sipcore-status-unwanted-01

=C2=A0

Hi,

=C2=A0

To reflect th= e question of the interpretation of the 666 response interpretation when th= e caller has several identities used for this call (ie. From and P-Asserted= -Identity are different) or call forwarding/call transfer use cases for whi= ch it has to be discussed which party should be considered has a fraudulent= (ie. the calling party or the diverting party or both ?) ; I propose to ad= d the following text:

This document defines a mechanism by which a called party can = reject an unwanted call without consideration of the calling party identifi= cation that remain to the service provider policy. Indeed, the calling part= y identity may be reflected in different way for a direct call or after a d= iverting service in P-Asserted-Identity, From, History-Info or any concurre= nt header field that can be present at the same time in a SIP message.

=C2=A0=

Those questions= are real issues for operators and implementors and they are a weakness tha= t fraudulent callers could use to bypass the mechanism.

=C2=A0

BR,

Marianne

=C2=A0

=C2=A0
--f403045ea6de9d5cca0545fff667-- From nobody Fri Jan 13 13:11:04 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C5D129464 for ; Fri, 13 Jan 2017 13:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0sQjddvS0gV for ; Fri, 13 Jan 2017 13:11:01 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B85EB1293F0 for ; Fri, 13 Jan 2017 13:11:00 -0800 (PST) X-AuditID: c1b4fb3a-aa56b98000004520-6f-58794262966f Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.183.66]) by (Symantec Mail Security) with SMTP id D4.14.17696.16249785; Fri, 13 Jan 2017 22:10:58 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.169]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0319.002; Fri, 13 Jan 2017 22:11:44 +0100 From: Christer Holmberg To: Adam Roach , 'SIPCORE' , "Rifaat Shekh-Yusef" Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdm0E02YJFp00GoTEcPhv1fDKE252Cw Date: Fri, 13 Jan 2017 21:10:55 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUyM2K7k26SU2WEwaU1ChZ7/i5it9j5opXN 4uuPTWwOzB47Z91l91iy5CeTx6ydT1gCmKO4bFJSczLLUov07RK4Mp58v8NWsJav4kbnf/YG xq/cXYycHBICJhJXDz9k72Lk4hASWMcocWn5bWYIZwmjxPZrs4EyHBxsAhYS3f+0QRpEBPIl 1tzexgpiCwu4SLxZOYUFIu4q8a/jFpRtJHF49XOwGhYBVYmpN66BxXkFfCXWn7nBCGILCdhJ 9P/fxQ5icwrYS6y7sxYsziggJvH91BomEJtZQFzi1pP5TBCHCkgs2XOeGcIWlXj5+B8rhK0k 0bjkCStEvY7Egt2f2CBsbYllC18zQ+wVlDg58wnLBEaRWUjGzkLSMgtJyywkLQsYWVYxihan FhfnphsZ6aUWZSYXF+fn6eWllmxiBMbIwS2/rXYwHnzueIhRgINRiYd3g3JlhBBrYllxZe4h RgkOZiURXgl7oBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXFes5X3w4UE0hNLUrNTUwtSi2CyTByc Ug2Mc1ityjb7XbqZv+rFYe/6qZnZ9+wdnRrV8hQzltw2Wb7jvdIun4T3p9Ktrm9jnsKjnG5x +m65aSvf/77PDEzKVW99nr0t6LRcWu0eoPh7H1/Oj6YnhwXS3+l+nbVoUrLU0wULl8z9LuOw QlXtdtX+jxsvlb5SN+gTkb2c+2NNU+Hvk6+9WQ5NV2Ipzkg01GIuKk4EAET2WCKNAgAA Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 21:11:03 -0000 Hi, In addition, I'd like to consider adopting: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ As indicated by Rifaat, while THIS draft was just submitted, it's related t= o an topic that we have already discussed in the past. Based on discussions= with e.g., Jon Peterson, the controversial parts of the previous suggestio= n has been removed from the new draft. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 13 January 2017 02:52 To: 'SIPCORE' Subject: [sipcore] Call for Adoptions: Drafts for new milestones [as chair] As I mentioned in an earlier message, we have new milestones for SIPCORE, m= any of which we hope to finish in the first half of the year.=20 To that end, I'd like to call for adoption of the documents that prompted a= dding the milestones. To be specific: We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milesto= ne "mechanism for labeling the nature of SIP calls" We propose adopting draft-holmberg-sipcore-content-id for the milestone "cl= arification of the use of Content-ID" We propose adopting draft-sparks-sipcore-name-addr-guidance for the milesto= ne "clarification of the use of name-addr" I'll note that these document -- and in particular the last two -- have had= significant discussion and feedback already. In particular, the author of = draft-sparks-sipcore-name-addr-guidance indicates that he believes that doc= ument is "done" and basically ready for last call. Please provide feedback regarding adoption of these documents by Friday, Ja= nuary 27. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jan 13 14:05:10 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAC92129E9D for ; Fri, 13 Jan 2017 14:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bbWRZvaOGf0r for ; Fri, 13 Jan 2017 14:05:07 -0800 (PST) Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CDA0129E9C for ; Fri, 13 Jan 2017 14:05:07 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-11v.sys.comcast.net with SMTP id S9wfcQ9I0ZxnDS9y6c55Kh; Fri, 13 Jan 2017 22:05:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484345106; bh=5BfgMmM8MgHD0x6Aex9UZ+TC04JAnonPjHTfPH2e6JU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=F/V/weYMey9LO7ni1zEBI5ybHuvTJ7X6lfaMiowF4ps8StexJR9OS8yDJgux7MzCf /GtATqyQHAaqHuf1Y/3Xsu9zFJ+Ispu0fT57qf5VjzhVZ2szFaRrAEGMrvsRkWxdcd qmSP+LYwRG/vOqUcSKN5v6LBsgaejtRLeUB3QUmzNPbutETFt9HlzMl8gbLQPTbHp4 sgcYR+dZQMGRvxKMIb7Eh33hng12bJI5RZ8OwOp2da01ucC7aOwTwdpYlnrKCsDUVC CJXT2khYkuaDY7cXcf0uNXwdA6pgLK+t0p6YKvsWvZtuZfmAvS7fFG8KWRuFrlLm/I WupjuVYG8z/NQ== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-12v.sys.comcast.net with SMTP id S9y5c4jkcTnqpS9y5c8mfP; Fri, 13 Jan 2017 22:05:06 +0000 To: SIPCORE References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> Date: Fri, 13 Jan 2017 17:05:05 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:05:08 -0000 While reviewing this version I got to thinking about the use of Reason: 666 in CANCEL. This could conceivably be abused: - Alice (bad actor) sends INVITE to Bob - Bob sends 180 back to Alice - Alice sends CANCEL with Reason 666 This allows Alice to probe for the presence of a device at the target address, while possibly preventing the attempt from being reported to the callee. (This is behavior I see almost every day. While annoying, I'd rather have the opportunity to know it happened.) The only reasonable work-around I see for it is for the proxy servicing Bob's AoR to strip the incoming reason code. That would probably be an ok thing to do in most cases. But it won't do the right thing if there was forking upstream of that proxy. (E.g., in a case where the call was originally to a different number and was diverted with forking.) So this isn't a reason to disallow 666 in CANCEL, but it suggests that the processing of this in the UAS be carefully considered. Otherwise the new version looks good. Thanks, Paul From nobody Fri Jan 13 14:07:17 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9289C129EA9 for ; Fri, 13 Jan 2017 14:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYJyU53jbfMr for ; Fri, 13 Jan 2017 14:07:13 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76722129EA4 for ; Fri, 13 Jan 2017 14:07:13 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-04v.sys.comcast.net with SMTP id S9zjcvGF9rdcjSA09c0jOl; Fri, 13 Jan 2017 22:07:13 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1484345233; bh=9oNKxxcIrOMVsP270tyORm9jOLLsQ5AYiM7Fcgs+DfU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=cgyjObmA6OuzmeiiojUw5Frhia4YguM+NTEq2HZ0nHCXeszVWXjRLWBvht0sV9cs4 2hKZtWXLnPVW/sgKbfgEN4tM8ffRdTbWMlnXyVzY0rPUO3SReSwxMML+J6wUyNNhAs J2IsGTkCH3QLh9NbGhjGvSZb6ydcERVW01UzFU/jvp1SKV3hK0K5tn3CXSjiSs9vD7 N6mZD2jInRs+HPJASsjXhrSOjU+6wSJd7fbaCMe+NZMjm/OdFQ0R2fDfs5JVF4WO4o 821/+a+PvNg5ChSLeQDn5pMUMW7+JhCBPDq1pfjmqzRSML1QslDNwgJtbZbKilGk+1 +0BVnPv9GkhlA== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-10v.sys.comcast.net with SMTP id SA08c98wJbEEOSA08ckzlw; Fri, 13 Jan 2017 22:07:13 +0000 To: Henning Schulzrinne , "sipcore@ietf.org" References: <29250_1483569344_586D78C0_29250_11232_1_8B970F90C584EA4E97D5BAAC9172DBB81C8936A9@OPEXCNORMAC.corporate.adroot.infra.ftgroup> <2bede008-3283-e0f1-3971-38342d04e88d@comcast.net> <3572_1483716509_586FB79D_3572_5322_1_8B970F90C584EA4E97D5BAAC9172DBB81C8A492A@OPEXCLILMA4.corporate.adroot.infra.ftgroup> From: Paul Kyzivat Message-ID: Date: Fri, 13 Jan 2017 17:07:11 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:07:15 -0000 On 1/12/17 3:41 PM, Henning Schulzrinne wrote: > Any suggested wording? I think, in general, it will be impossible for the called party's carrier to know what the decision is based on. Even content can be misleading - I might think it's a sales call, but it turns out to be a product defect recall. (I suspect you've gotten calls starting with "This is not a sales call.", which usually means that I definitely don't want to talk to the non-sales-caller since it's most likely a scam instead...) > > If the 666 is used for statistical call filtering, we have to rely on the wisdom of the crowd, and assume some fraction of both false negatives and positives. As Martin has indicated earlier, maybe experience will indicate that mid-call 666's are better indicators, but that's all guesswork so far. > > Thus, to avoid too many "in some cases, but in other cases" sentences, please send text if you have specific actionable implementer guidance. > > Note that the text currently already alludes to the difference ("Receiving system could decide to treat..."), so I think the general angle has been covered. Having talked this through, and after reading the latest version, I can't think of anything more to say that belongs in this document. Thanks, Paul > Henning > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, January 06, 2017 12:43 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > > On 1/6/17 10:28 AM, marianne.mohali@orange.com wrote: >> Hi, >> >> To reflect the question of the interpretation of the 666 response >> interpretation when the caller has several identities used for this >> call (ie. From and P-Asserted-Identity are different) or call >> forwarding/call transfer use cases for which it has to be discussed >> which party should be considered has a fraudulent (ie. the calling >> party or the diverting party or both ?) ; I propose to add the following text: >> >> This document defines a mechanism by which a called party can reject >> an unwanted call without consideration of the calling party >> identification that remain to the service provider policy. Indeed, the >> calling party identity may be reflected in different way for a direct >> call or after a diverting service in P-Asserted-Identity, From, >> History-Info or any concurrent header field that can be present at the >> same time in a SIP message. >> >> Those questions are real issues for operators and implementors and >> they are a weakness that fraudulent callers could use to bypass the mechanism. > > ISTM there are two different cases here, and the identity implications differ between them: > > 1) the callee rejects the call without consideration of the content of the call. Instead, the rejection is based solely on metadata about the call that is available to the callee - e.g., callerid information presented, classification information, possibly time of day. It might also include information provided locally by the phone (e.g. from the local address book). > > In this case the actual caller may be blameless. So care must be taken in associating the rejection with the caller. > > 2) the callee rejects the call after answering, based on the media content of the call. > > In this case the rejection clearly applies to the caller even if the callee doesn't know the caller's identity. > > It may be difficult to distinguish between these. Certainly using 666 as a response code must be case (1). But using 666 as a reason isn't necessarily case (2) - the callee may be slow and reject based on metadata after answering, or may use a combination of content and metadata in making that decision. > > This is not something that can be resolved in this document, but it may be worthwhile to identify that these issues exist and must be considered by those who act on 666 responses. > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_sipcore&d=DgICAg&c=y0h0omCe0jAUGr4gAQ02Fw&r=FJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=w6-F-EQyZVD_u9zlhZF0qJKOYhLoEynLstyHM8ce6lk&s=x7kUOPzC2LyOOaY-S0KpNT5m0dU-lrQgNXq2eiQpWpE&e= > From nobody Fri Jan 13 14:47:26 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 906BD129EF6 for ; Fri, 13 Jan 2017 14:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGjeykRky4mS for ; Fri, 13 Jan 2017 14:47:23 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72064129D43 for ; Fri, 13 Jan 2017 14:47:23 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-06v.sys.comcast.net with SMTP id SAbrcnI5emU9eSAczcdvhE; Fri, 13 Jan 2017 22:47:21 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-03v.sys.comcast.net with SMTP id SAcwcu8wFwJd1SAcxcF7WR; Fri, 13 Jan 2017 22:47:20 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0DMlIfk014838; Fri, 13 Jan 2017 17:47:18 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0DMlHb6014835; Fri, 13 Jan 2017 17:47:17 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Adam Roach In-Reply-To: (adam@nostrum.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 13 Jan 2017 17:47:16 -0500 Message-ID: <871sw6vaq3.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 22:47:24 -0000 Adam Roach writes: > We propose adopting draft-holmberg-sipcore-content-id for the milestone > "clarification of the use of Content-ID" > > We propose adopting draft-sparks-sipcore-name-addr-guidance for the > milestone "clarification of the use of name-addr" I support both of these, indeed, I consider them to be corrections that update the standards to what we have long since thought they should be. I also propose adding draft-yusef-sipcore-digest-scheme as a WG item so that we can start the transition away from using MD-5 for digest authentication. Dale From nobody Fri Jan 13 16:41:35 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D56129FDD for ; Fri, 13 Jan 2017 16:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qj-_6tjF0HxY for ; Fri, 13 Jan 2017 16:41:33 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4AE1294EA for ; Fri, 13 Jan 2017 16:41:33 -0800 (PST) Received: from resomta-po-13v.sys.comcast.net ([96.114.154.237]) by resqmta-po-06v.sys.comcast.net with SMTP id SCPLcnQxhmU9eSCPUceDcY; Sat, 14 Jan 2017 00:41:32 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-13v.sys.comcast.net with SMTP id SCPSc5lQPxumkSCPUc91ex; Sat, 14 Jan 2017 00:41:32 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0E0fTJt021526; Fri, 13 Jan 2017 19:41:29 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0E0fS0o021523; Fri, 13 Jan 2017 19:41:28 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Rifaat Shekh-Yusef In-Reply-To: (rifaat.ietf@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Fri, 13 Jan 2017 19:41:28 -0500 Message-ID: <87o9zatqvb.fsf@hobgoblin.ariadne.com> Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 00:41:34 -0000 Rifaat Shekh-Yusef writes: >> As a matter of exposition, you say "This section does NOT maintain >> backward compatibility with RFC 2069." But of course as a consequence >> of that, it isn't compatible with RFC 3261 either. > > The statement you quoted was in the previous version of the document, but > not in v05. Hmmm, for some reason I wasn't looking at the 05 version. >> I'd like to see a description of how the draft's section 2.6 compares >> with the existing SIP authentication scheme -- is this just adding the >> new algorithms and making qop mandatory? > > Yes, the idea is that this draft will add the SHA2 algorithms as the > recommended algorithms, and only keep the MD5 for backward compatibility. What I meant was a positive statement in the draft of what the differences are, so the reader doesn't have to correlate section 2.6 with the previous RFCs. "Olle E. Johansson" writes: > I feel we need to have some writing about how to migrate. There is a > significant risk of downgrade attacks if we have both mechanisms > running, like you get two challenges or one challenge with two > algorithms (if that's possible). Certainly we need to worry about avoiding downgrade attacks, and this should be included in the security considerations. (I can imagine techniques to prevent it, such as when digest-protecting a message, including in the protected information a list of ciphers that the sender is willing to support, so that the receiver can verify that no better cipher that it offered to use is also supported by the sender.) Forking in the general case ... gets ugly. I'm not sure how much it matters in practice. But if one fork returns a 401 for domain example.com that demands use of MD-5, and another fork returns a 401 for domain example.com with two Proxy-Authenticate headers that allow either MD-5 or SHA-256, the combined 401 returned to the UAC contains 3 Proxy-Authenticate headers for one domain, two of which use MD-5 and one SHA-256. Is there any way to prescribe behavior for the UAC that will cause successful operation? Dale From nobody Sat Jan 14 00:08:07 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2A6912945B for ; Sat, 14 Jan 2017 00:08:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faG5KFwKbRr3 for ; Sat, 14 Jan 2017 00:08:03 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 075FB12943D for ; Sat, 14 Jan 2017 00:08:01 -0800 (PST) Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id A927F3D02; Sat, 14 Jan 2017 09:07:47 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> Date: Sat, 14 Jan 2017 09:07:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.3124) Archived-At: Cc: SIPCORE , Olle E Johansson , Rifaat Shekh-Yusef Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 08:08:05 -0000 > On 13 Jan 2017, at 22:10, Christer Holmberg = wrote: >=20 > Hi, >=20 > In addition, I'd like to consider adopting: >=20 > https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ >=20 > As indicated by Rifaat, while THIS draft was just submitted, it's = related to an topic that we have already discussed in the past. Based on = discussions with e.g., Jon Peterson, the controversial parts of the = previous suggestion has been removed from the new draft. I agree on adopting this document. /O >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam = Roach > Sent: 13 January 2017 02:52 > To: 'SIPCORE' > Subject: [sipcore] Call for Adoptions: Drafts for new milestones >=20 > [as chair] >=20 > As I mentioned in an earlier message, we have new milestones for = SIPCORE, many of which we hope to finish in the first half of the year.=20= > To that end, I'd like to call for adoption of the documents that = prompted adding the milestones. To be specific: >=20 > We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the = milestone "mechanism for labeling the nature of SIP calls" >=20 > We propose adopting draft-holmberg-sipcore-content-id for the = milestone "clarification of the use of Content-ID" >=20 > We propose adopting draft-sparks-sipcore-name-addr-guidance for the = milestone "clarification of the use of name-addr" >=20 > I'll note that these document -- and in particular the last two -- = have had significant discussion and feedback already. In particular, the = author of draft-sparks-sipcore-name-addr-guidance indicates that he = believes that document is "done" and basically ready for last call. >=20 > Please provide feedback regarding adoption of these documents by = Friday, January 27. Thanks! >=20 > /a >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sat Jan 14 00:10:14 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC23912945C for ; Sat, 14 Jan 2017 00:10:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27sbnvUKUzVx for ; Sat, 14 Jan 2017 00:10:10 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E87012943D for ; Sat, 14 Jan 2017 00:10:10 -0800 (PST) Received: from [192.168.40.8] (h87-96-134-129.cust.se.alltele.net [87.96.134.129]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 947463D02; Sat, 14 Jan 2017 09:09:52 +0100 (CET) Content-Type: multipart/alternative; boundary="Apple-Mail=_32C59EEE-B392-4A2B-B1E4-5023F0CFC96F" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 14 Jan 2017 09:09:52 +0100 Message-Id: References: <87lgug6xds.fsf@hobgoblin.ariadne.com> <0F8841CC-1F08-463E-8C61-4AB8FBF08A4D@edvina.net> To: Rifaat Shekh-Yusef X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "Dale R. Worley" , Olle E Johansson , "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2017 08:10:13 -0000 --Apple-Mail=_32C59EEE-B392-4A2B-B1E4-5023F0CFC96F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 13 Jan 2017, at 18:49, Rifaat Shekh-Yusef = wrote: >=20 > Thanks Olle, >=20 > This document gives the operator the tools to migrate, but migration = policy is probably be out of scope this document. Agree that policy is out of scope, but advice to implementors should be = in scope so we do not cause security flaws in software. /O >=20 >=20 > What do others think? >=20 > Regards, > Rifaat >=20 >=20 >=20 > On Fri, Jan 13, 2017 at 3:29 AM, Olle E. Johansson > wrote: > Rifaat, > THank you for your work on this and coming back. >=20 > I feel we need to have some writing about how to migrate. There is a = significant risk of downgrade attacks > if we have both mechanisms running, like you get two challenges or one = challenge with two algorithms > (if that=E2=80=99s possible). The web has a simpler upgrade path, = given the small amount of browsers that operate > a majority of the requests. We have many years of legacy software that = propably will not upgrade unless customers > require it. And it will take some time to get new firmware out there = with support for this unless there=E2=80=99s significant > customer demand. >=20 > We definitiely need to get this done and move SIPconnect 2.x to = require this on public networks and > forbid MD5 in those situations as a first step. Hopefully that can = help some customers to demand the right thing. >=20 > How do an operator of a service upgrade to SHA2? Do we have to have a = cut-off date and stop > accepting MD5, do we migrate somehow or do we mark =E2=80=9Cnew=E2=80=9D= phones for ONLY SHA2 and old clients > for MD5 and SHA2 in some authentication service database? >=20 > Implementors need to know how to handle this and I haven=E2=80=99t = figured out any good solution in my own > head since we started this discussion five years ago or so=E2=80=A6. >=20 > If we can solve this process now, we=E2=80=99re in better shape when = SHA2 becomes the algorithm that no one > wants to use any more. >=20 > /O >=20 >=20 > =20 >> On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef > wrote: >>=20 >> Thanks Dale! >>=20 >> Please, see my reply inline... >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley > wrote: >> Rifaat Shekh-Yusef > writes: >> > RFC7617 updated the *HTTP Digest* mechanism and added support for = *SHA2* to >> > replace the MD5 algorithm. >> > >> > I am trying to revolve this old draft that does the same for SIP: >> > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ = >>=20 >> It makes sense to do this, of course, as MD-5 is thoroughly obsolete. >>=20 >> As a matter of exposition, you say "This section does NOT maintain >> backward compatibility with RFC 2069." But of course as a = consequence >> of that, it isn't compatible with RFC 3261 either. >>=20 >> The statement you quoted was in the previous version of the document, = but not in v05. >> If I remember correctly, we discussed that and during one of the IETF = meetings and it was deemed unnecessary to maintain that. >> We did the same with the new HTTP Digest mechanism defined in = RFC7616. >>=20 >> Is that a problem for SIP? >>=20 >>=20 >> =20 >>=20 >> I'd like to see a description of how the draft's section 2.6 compares >> with the existing SIP authentication scheme -- is this just adding = the >> new algorithms and making qop mandatory? >>=20 >> Yes, the idea is that this draft will add the SHA2 algorithms as the = recommended algorithms, and only keep the MD5 for backward = compatibility. >>=20 >> Regards, >> Rifaat >>=20 >>=20 >> =20 >> Dale >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore = >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore = >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_32C59EEE-B392-4A2B-B1E4-5023F0CFC96F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 13 Jan 2017, at 18:49, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thanks Olle,

This document gives the operator the tools to migrate, but migration policy is probably be out of scope this = document.
Agree that policy is out of = scope, but advice to implementors should be in scope so we do not = cause
security flaws in software.

/O

What do others think?

Regards,
 Rifaat



On Fri, Jan 13, 2017 at 3:29 AM, = Olle E. Johansson <oej@edvina.net> wrote:
Rifaat,
THank you for your work on this and = coming back.

I = feel we need to have some writing about how to migrate. There is a = significant risk of downgrade attacks
if we have = both mechanisms running, like you get two challenges or one challenge = with two algorithms
(if that=E2=80=99s possible). = The web has a simpler upgrade path, given the small amount of browsers = that operate
a majority of the requests. We have = many years of legacy software that propably will not upgrade unless = customers
require it. And it will take some time to = get new firmware out there with support for this unless there=E2=80=99s = significant
customer demand.
We definitiely need to get this done = and move SIPconnect 2.x to require this on public networks and
forbid MD5 in those situations as a first step. Hopefully = that can help some customers to demand the right thing.

How do an operator of a = service upgrade to SHA2? Do we have to have a cut-off date and = stop
accepting MD5, do we migrate somehow or do we = mark =E2=80=9Cnew=E2=80=9D phones for ONLY SHA2 and old = clients
for MD5 and SHA2 in some authentication = service database?

Implementors need to know how to handle this and I haven=E2=80=99= t figured out any good solution in my own
head = since we started this discussion five years ago or so=E2=80=A6.

If we can solve this = process now, we=E2=80=99re in better shape when SHA2 becomes the = algorithm that no one
wants to use any = more.

/O


 
On 12 Jan 2017, at 19:07, Rifaat = Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thanks Dale!

Please, see my reply inline...

Regards,
 Rifaat


On Thu, = Jan 12, 2017 at 11:44 AM, Dale R. Worley <worley@ariadne.com> wrote:
Rifaat Shekh-Yusef = <rifaat.ietf@gmail.com> writes:
> RFC7617 updated the *HTTP Digest* mechanism and added support for = *SHA2* to
> replace the MD5 algorithm.
>
> I am trying to revolve this old draft that does the same for = SIP:
> https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/

It makes sense to do this, of course, as MD-5 is thoroughly = obsolete.

As a matter of exposition, you say "This section does NOT maintain
backward compatibility with RFC 2069."  But of course as a = consequence
of that, it isn't compatible with RFC 3261 either.

The statement you quoted = was in the previous version of the document, but not in v05.
If I remember correctly, we discussed that and during one of = the IETF meetings and it was deemed unnecessary to maintain = that.
We did the same with the new HTTP Digest = mechanism defined in RFC7616.

Is that a problem for SIP?


 

I'd like to see a description of how the draft's section 2.6 compares
with the existing SIP authentication scheme -- is this just adding = the
new algorithms and making qop mandatory?

Yes, = the idea is that this draft will add the SHA2 algorithms as the = recommended algorithms, and only keep the MD5 for backward = compatibility.

Regards,
 Rifaat


 
Dale

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_32C59EEE-B392-4A2B-B1E4-5023F0CFC96F-- From nobody Sun Jan 15 11:33:27 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8C8129502 for ; Sun, 15 Jan 2017 11:33:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.157 X-Spam-Level: X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb4c03srgzy9 for ; Sun, 15 Jan 2017 11:33:25 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDDF129416 for ; Sun, 15 Jan 2017 11:33:24 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id B455B863E6018; Sun, 15 Jan 2017 19:33:18 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id v0FJXLXl030950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 15 Jan 2017 19:33:22 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id v0FJXG84025625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 15 Jan 2017 19:33:20 GMT Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.138]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Sun, 15 Jan 2017 20:33:15 +0100 From: "Drage, Keith (Nokia - GB)" To: Adam Roach , "'SIPCORE'" Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdNpvYVAjqd9ke/M1plw5iuZqE58W5A Date: Sun, 15 Jan 2017 19:33:14 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8BADFD4EDD@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 19:33:26 -0000 Fine for me. Keith -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 13 January 2017 00:52 To: 'SIPCORE' Subject: [sipcore] Call for Adoptions: Drafts for new milestones [as chair] As I mentioned in an earlier message, we have new milestones for SIPCORE, m= any of which we hope to finish in the first half of the year.=20 To that end, I'd like to call for adoption of the documents that prompted a= dding the milestones. To be specific: We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milesto= ne "mechanism for labeling the nature of SIP calls" We propose adopting draft-holmberg-sipcore-content-id for the milestone "cl= arification of the use of Content-ID" We propose adopting draft-sparks-sipcore-name-addr-guidance for the milesto= ne "clarification of the use of name-addr" I'll note that these document -- and in particular the last two -- have had= significant discussion and feedback already. In particular, the author of = draft-sparks-sipcore-name-addr-guidance indicates that he believes that doc= ument is "done" and basically ready for last call. Please provide feedback regarding adoption of these documents by Friday, Ja= nuary 27. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun Jan 15 12:49:03 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AF31296BC for ; Sun, 15 Jan 2017 12:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5xThxt_O1-G6 for ; Sun, 15 Jan 2017 12:48:59 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614F01294B1 for ; Sun, 15 Jan 2017 12:48:58 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0FKmuc0014053; Sun, 15 Jan 2017 20:48:56 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0047.outbound.protection.outlook.com [23.103.198.47]) by mx0b-0024ed01.pphosted.com with ESMTP id 27yehq0jtt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 15 Jan 2017 20:48:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=sJM8neXvdrD0Gtz3gRymYpJT8N8wzRHRu8wxag438LA=; b=G++rWZ/ZES5x638RusxQ8JGaS6kygf9Remz9ocMVy/jYHfWplRo9PxVAUAode5WRgr+6DmQmQttGmw7F1BI3542pJiqBXNcnp3+ndNGWSBLzwFN9RMdhbC2Zn7ILpH23ozf9dyu6gQYFZ4Bwv0WawzD3CAyMK3rbHhRnuEhvits= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Sun, 15 Jan 2017 20:48:54 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Sun, 15 Jan 2017 20:48:54 +0000 From: Henning Schulzrinne To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJt3jyCDTTT21QxQfGC4OLjh1QSQABkfEPT Date: Sun, 15 Jan 2017 20:48:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.8.248.19] x-ms-office365-filtering-correlation-id: e13c1720-fa28-4d00-f414-08d43d87eb1e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0634; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0634; 7:LCecw+39SiFoQOi2d7rCSFLmBPJ6wxujkzSBCvuQ4z1/8w8TqM8gzUTjnX0zu5kNpl88PwLVobIwS2H7NRB506/tfYpLA40OmnEqGPCKGzOx4WbmNQLCz8+kHCbA9dic7BQinKl0dUJ1GkblwIU9Jlm7UCWg/d4qJ7I8FQ9XS3jHkbimoirsZ+0ViBbbtsV7bc6FuAyaJSTTNlTgLOTN6Dhn4wcn/I0gKmnwNwEYrCVzQaIxxGSSgjkJP1l6PRvAWHnLDO9l6AegCmDVAiaRJM8uH57LcZE/hmsfp8dF2teCo2gtlnJawTtbePAhNu/A8MmajfD9FP5KTVZq8Fr1LSlwgjPaJ2DjF/LszU0Tt0pPZWzps8e5W+GfWYaZWKAw1SAem/q78G1xLJLvxCH4ciyKllbhdpaV4WgKIzfKLY27hlsF0IbQCeOt02n++dpqX8fW7ZufXPOKsxtWlZqsfQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0634; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0634; x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(189002)(199003)(377454003)(38730400001)(229853002)(68736007)(66066001)(5001770100001)(97736004)(5660300001)(7736002)(50986999)(236005)(76176999)(55016002)(54896002)(99286003)(101416001)(230783001)(7696004)(33656002)(6506006)(77096006)(107886002)(189998001)(86362001)(9686003)(25786008)(54356999)(2950100002)(19627405001)(105586002)(2501003)(6436002)(122556002)(2900100001)(8936002)(81166006)(102836003)(6116002)(81156014)(3846002)(3280700002)(92566002)(106356001)(3660700001)(2906002)(27001)(74316002)(8676002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0634; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634A773181700D2518FFFA8EA7A0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2017 20:48:53.9535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0634 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-15_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 20:49:02 -0000 --_000_CY1PR09MB0634A773181700D2518FFFA8EA7A0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How likely is any of this going to happen for unwanted robocalls? For figur= e 4, the one scenario I can think of is the "evil" controller leveraging a = service A to call B, and B 666'ing the call or sending a BYE with Reason(66= 6). But that would seem to be pretty standard, even if the final recipient = of the 666 or BYE is A (who is likely to ignore it). I think it would help if you could identify the roles of the third parties = and see if that causes the recipient of the unwanted call to do something t= hat's harmful to innocent bystanders. Henning ________________________________ From: Brett Tate Sent: Friday, January 13, 2017 3:48:58 PM To: Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning calling party sending BYE with 666, I just thought that it poten= tially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a =93calling party=94 = might get replaced by a =93called party=94. Thus if the controller doesn= =92t strip the Reason while relaying the BYE, it definitely would be possib= le since both are called parties. If the =93calling party=94 gets replaced before =93called party=94 sends BY= E with 666, who should be flagged: 1) calling party indicated within origin= al INVITE or 2) newest connected party? Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 12, 2017 3:31 PM To: Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I=92m afraid I don=92t quite follow what text you are suggesting and I=92m = suspecting we=92re well into the weeds at this point. My general inclinatio= n is to only state things where 666 differs from 6xx handling, rather than = try to capture all possible status code issues that are generic to (most) 6= xx codes. This avoids creating inadvertent contradictions or the need to up= date the document should there be changes in the generic handling. In other= words, 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I=92m not sure why the calling party would indicate 666. After receiving a = re-INVITE? In response to a BYE? I admit that I lack the imagination as to = how this would occur and why this would cause anything other than what woul= d happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I=92m misled int= o dialing a number (e.g., as part of a spam email) that turns out to be a r= obot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning From: Brett Tate [mailto:brett@broadsoft.com] Sent: Friday, January 06, 2017 12:32 PM To: marianne.mohali@orange.com; Henning = Schulzrinne >; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected p= arty to change mid-dialog 1) without it being communicated and 2) with it b= eing communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagge= d by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party i= ndicating 666. Other than a way to attack someone, I=92m not sure if are a= ny 3PCC, transfer, or other service situations where it might actually be a= ppropriate. From: marianne.mohali@orange.com [mailto= :marianne.mohali@orange.com] Sent: Friday, January 06, 2017 10:28 AM To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpret= ation when the caller has several identities used for this call (ie. From a= nd P-Asserted-Identity are different) or call forwarding/call transfer use = cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I = propose to add the following text: This document defines a mechanism by which a called party can reject an unw= anted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity ma= y be reflected in different way for a direct call or after a diverting serv= ice in P-Asserted-Identity, From, History-Info or any concurrent header fie= ld that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are= a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --_000_CY1PR09MB0634A773181700D2518FFFA8EA7A0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

How likely is any of this going to happen for unwanted robocalls? For fi= gure 4, the one scenario I can think of is the "evil" controller = leveraging a service A to call B, and B 666'ing the call or sending a BYE w= ith Reason(666). But that would seem to be pretty standard, even if the final recipient of the 666 or BYE is A (who i= s likely to ignore it).


I think it would help if you could identify the roles of the third parti= es and see if that causes the recipient of the unwanted call to do somethin= g that's harmful to innocent bystanders.


Henning

From: Brett Tate <brett@= broadsoft.com>
Sent: Friday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01
 

Hi,

 

Concerning calling party = sending BYE with 666, I just thought that it potentially should be discusse= d.

 

However, RFC 3725 figures= 4 and figure 7 do show how a =93calling party=94 might get replaced by a = =93called party=94.  Thus if the controller doesn=92t strip the Reason while relaying the BYE, it definitely would be possible since both are cal= led parties.

 

If the =93calling party= =94 gets replaced before =93called party=94 sends BYE with 666, who should = be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

 

Thanks,

Brett

 

From: Henning = Schulzrinne [mailto:Henning.= Schulzrinne@fcc.gov]
Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate; marian= ne.mohali@orange.com; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I=92m afraid I don=92t qu= ite follow what text you are suggesting and I=92m suspecting we=92re well i= nto the weeds at this point. My general inclination is to only state things where 666 differs from 6xx handling, rather than try to capture all= possible status code issues that are generic to (most) 6xx codes. This avo= ids creating inadvertent contradictions or the need to update the document = should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise = noted.

 

Thus, can you provide sug= gested text?

 

I=92m not sure why the ca= lling party would indicate 666. After receiving a re-INVITE? In response to= a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen= for a generic 6xx response in those circumstances.

 

Stretching the imaginatio= n, I could imagine the case where I=92m misled into dialing a number (e.g.,= as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason.

 

Is that the case you have= in mind?

 

Henning

 

From: Brett = Tate [mailto:bre= tt@broadsoft.com]
Sent: Friday, January 06, 2017 12:32 PM
To: marianne.mohali@orange.com; Henning Schulzrinne &= lt;Henni= ng.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

The draft potentially sho= uld also discuss the potential for the connected party to change mid-dialog= 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.

 

From a security considera= tions perspective, the wrong party might be flagged by the 666 when the con= nected party changes.

 

The draft should potentia= lly also discuss the potential for calling party indicating 666.  Othe= r than a way to attack someone, I=92m not sure if are any 3PCC, transfer, or other service situations where it might actually be appropria= te.

 

 

From: marianne.m= ohali@orange.com [mailto:marianne.mohali@orange.com= ]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

To reflect the ques= tion of the interpretation of the 666 response interpretation when the call= er has several identities used for this call (ie. From and P-Asserted-Ident= ity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be = considered has a fraudulent (ie. the calling party or the diverting party o= r both ?) ; I propose to add the following text:

This document defin= es a mechanism by which a called party can reject an unwanted call without = consideration of the calling party identification that remain to the servic= e provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or afte= r a diverting service in P-Asserted-Identity, From, History-Info or any con= current header field that can be present at the same time in a SIP message.=

 

Those questions are= real issues for operators and implementors and they are a weakness that fr= audulent callers could use to bypass the mechanism.

 

BR,

Marianne

 

 
--_000_CY1PR09MB0634A773181700D2518FFFA8EA7A0CY1PR09MB0634namp_-- From nobody Sun Jan 15 12:53:09 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 489031296C6 for ; Sun, 15 Jan 2017 12:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h1N1j1cRgCtG for ; Sun, 15 Jan 2017 12:53:06 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2B81296B1 for ; Sun, 15 Jan 2017 12:53:06 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0FKr56T007818; Sun, 15 Jan 2017 20:53:05 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0056.outbound.protection.outlook.com [23.103.198.56]) by mx0a-0024ed01.pphosted.com with ESMTP id 27yg57gku0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 15 Jan 2017 20:53:05 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mY19mxAGk31/AV6wZifxwBvRP79X5JmvCIITqcD99HE=; b=Pt25RqYA+C0mavbnxy5oByq8UEucxnhoXuxHHjlO460fCDfQKedtgMgLehKEtJH9O0O6gI24B9EgmUlBhj+WSyHef4qei/MkwRfbgx41dQHXGwnNtfVsBxsbUKUTIpDPQOQxpHed28McscVQfqInGLgcr+e7MQ9r5EoL/HATC1s= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Sun, 15 Jan 2017 20:53:03 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Sun, 15 Jan 2017 20:53:03 +0000 From: Henning Schulzrinne To: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbekfpzK9A/mMxEW2UXxc6qTie6E6Bhn4 Date: Sun, 15 Jan 2017 20:53:02 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com>, <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> In-Reply-To: <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [100.8.248.19] x-ms-office365-filtering-correlation-id: c55a642a-12b8-4f29-4263-08d43d887f8f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:VvXsZ5d3tW33X84MpLFc2ijtEfmFununzZR4Be4TeDhYjZ69qEkPOJa65hE+poxcj1eNgCXA5oRLdEIvlv+wBBHLrbroCEBFeLmUKA7X54A9xB+on3y0TaynRyQytnJVrITmCIynQ+XYZseMu5PDYj4eLvgmoXOtRvUfnaXaj0L+Ku0oy8PLbklSd88c1iEqPlJ7w8o5803zWKAFFKJ/nO1mQj3acduleLrF8DMiO0x72bvrN6/D61f0sYr6CEoH2F0vNFLi+wRY824ltuZMqrbC64RCJxPtLkywxINiDRCQA+kzFzs6y6pUYi1jiV2Ju4s5YvkMXjrnk5YUaJLWVugPPCTiu/iXZBKs16ybv7ZGpsmrjFI/ibpNADhUHIla78+ouhjQCSqQpAtjJ6QmVOEWRs6vH1QM2E1V1tCLYx/9c7olZKbdnbZoincbxkxyvm6p8wQMD0yJGE/7/Ao1Ug== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(68173958961439)(10436049006162)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123555025)(20161123558021)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0188D66E61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(189002)(199003)(377454003)(74316002)(122556002)(2906002)(3660700001)(8676002)(81156014)(8936002)(92566002)(3280700002)(2900100001)(102836003)(6116002)(66066001)(81166006)(3846002)(101416001)(50986999)(8666007)(7736002)(6436002)(6306002)(55016002)(99286003)(6506006)(25786008)(54896002)(54356999)(606005)(76176999)(77096006)(7906003)(230783001)(189998001)(106356001)(105586002)(9686003)(229853002)(38730400001)(7696004)(106116001)(107886002)(86362001)(575784001)(236005)(5660300001)(33656002)(5001770100001)(27001)(2950100002)(68736007)(97736004)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB063454C2ED3351AB6F6C41F2EA7A0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jan 2017 20:53:02.8272 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-15_14:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 20:53:08 -0000 --_000_CY1PR09MB063454C2ED3351AB6F6C41F2EA7A0CY1PR09MB0634namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Good point. Maybe the devices should keep a separate "bad call" list, simil= ar to the spam folder. However, that reporting is probably not going to hel= p Bob a whole lot - assuming Bob doesn't know Alice, what would it do with = the information? As you state, it's going to be very hard to distinguish le= gitimate upstream forking from malicious probing. ________________________________ From: sipcore on behalf of Paul Kyzivat Sent: Friday, January 13, 2017 5:05:05 PM To: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt While reviewing this version I got to thinking about the use of Reason: 666 in CANCEL. This could conceivably be abused: - Alice (bad actor) sends INVITE to Bob - Bob sends 180 back to Alice - Alice sends CANCEL with Reason 666 This allows Alice to probe for the presence of a device at the target address, while possibly preventing the attempt from being reported to the callee. (This is behavior I see almost every day. While annoying, I'd rather have the opportunity to know it happened.) The only reasonable work-around I see for it is for the proxy servicing Bob's AoR to strip the incoming reason code. That would probably be an ok thing to do in most cases. But it won't do the right thing if there was forking upstream of that proxy. (E.g., in a case where the call was originally to a different number and was diverted with forking.) So this isn't a reason to disallow 666 in CANCEL, but it suggests that the processing of this in the UAS be carefully considered. Otherwise the new version looks good. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dx6C_h7TZev8v8TlNDPl-QNQCHH6Stdtps3jqfVd3AM= k&s=3DyO7o9XY0u_fyn91L6BM8dYU_xw_BtUuq4LBc6IdMT60&e=3D --_000_CY1PR09MB063454C2ED3351AB6F6C41F2EA7A0CY1PR09MB0634namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Good point. Maybe the devices should keep a separate "bad call"= ; list, similar to the spam folder. However, that reporting is probably not= going to help Bob a whole lot - assuming Bob doesn't know Alice, what woul= d it do with the information? As you state, it's going to be very hard to distinguish legitimate upstream forking from= malicious probing.

From: sipcore <sipcore= -bounces@ietf.org> on behalf of Paul Kyzivat <paul.kyzivat@comcast.ne= t>
Sent: Friday, January 13, 2017 5:05:05 PM
To: SIPCORE
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt
 
While reviewing this version I got to thinking abo= ut the use of Reason:
666 in CANCEL. This could conceivably be abused:

- Alice (bad actor) sends INVITE to Bob
- Bob sends 180 back to Alice
- Alice sends CANCEL with Reason 666

This allows Alice to probe for the presence of a device at the target
address, while possibly preventing the attempt from being reported to
the callee.

(This is behavior I see almost every day. While annoying, I'd rather
have the opportunity to know it happened.)

The only reasonable work-around I see for it is for the proxy servicing Bob's AoR to strip the incoming reason code. That would probably be an
ok thing to do in most cases. But it won't do the right thing if there
was forking upstream of that proxy. (E.g., in a case where the call was originally to a different number and was diverted with forking.)

So this isn't a reason to disallow 666 in CANCEL, but it suggests that
the processing of this in the UAS be carefully considered.

Otherwise the new version looks good.

        Thanks,
        Paul


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dx6C_h7TZev= 8v8TlNDPl-QNQCHH6Stdtps3jqfVd3AMk&s=3DyO7o9XY0u_fyn91L6BM8dYU_xw_BtUuq4= LBc6IdMT60&e=3D
--_000_CY1PR09MB063454C2ED3351AB6F6C41F2EA7A0CY1PR09MB0634namp_-- From nobody Sun Jan 15 12:54:19 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAF571296B1 for ; Sun, 15 Jan 2017 12:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fmgJplxj6RvT for ; Sun, 15 Jan 2017 12:54:15 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E70A71294C5 for ; Sun, 15 Jan 2017 12:54:15 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id v0FKifL8047077; Sun, 15 Jan 2017 15:53:58 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 27yux5qc6s-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Jan 2017 15:53:57 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0FKruaw016955; Sun, 15 Jan 2017 15:53:56 -0500 Received: from mlpi408.sfdc.sbc.com (mlpi408.sfdc.sbc.com [130.9.128.240]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0FKrnHY016929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 15 Jan 2017 15:53:49 -0500 Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi408.sfdc.sbc.com (RSA Interceptor); Sun, 15 Jan 2017 20:53:39 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.18]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0319.002; Sun, 15 Jan 2017 15:53:38 -0500 From: "DOLLY, MARTIN C" To: Henning Schulzrinne Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJt3jyCDTTT21QxQfGC4OLjh1QSQABkfEPTAABRJmM= Date: Sun, 15 Jan 2017 20:53:38 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_A67541026D6B420885799C3622475633attcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-15_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701150309 Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2017 20:54:18 -0000 --_000_A67541026D6B420885799C3622475633attcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Action on the 666 will be at the called party end in the terminating carrie= r and not back at the calling party end Martin C. Dolly Lead Member of Technical Staff Core & Government/Regulatory Standards AT&T Cell: +1.609.903.3360 Email: md3135@att.com On Jan 15, 2017, at 3:49 PM, Henning Schulzrinne > wrote: How likely is any of this going to happen for unwanted robocalls? For figur= e 4, the one scenario I can think of is the "evil" controller leveraging a = service A to call B, and B 666'ing the call or sending a BYE with Reason(66= 6). But that would seem to be pretty standard, even if the final recipient = of the 666 or BYE is A (who is likely to ignore it). I think it would help if you could identify the roles of the third parties = and see if that causes the recipient of the unwanted call to do something t= hat's harmful to innocent bystanders. Henning ________________________________ From: Brett Tate > Sent: Friday, January 13, 2017 3:48:58 PM To: Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning calling party sending BYE with 666, I just thought that it poten= tially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a =93calling party=94 = might get replaced by a =93called party=94. Thus if the controller doesn= =92t strip the Reason while relaying the BYE, it definitely would be possib= le since both are called parties. If the =93calling party=94 gets replaced before =93called party=94 sends BY= E with 666, who should be flagged: 1) calling party indicated within origin= al INVITE or 2) newest connected party? Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 12, 2017 3:31 PM To: Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I=92m afraid I don=92t quite follow what text you are suggesting and I=92m = suspecting we=92re well into the weeds at this point. My general inclinatio= n is to only state things where 666 differs from 6xx handling, rather than = try to capture all possible status code issues that are generic to (most) 6= xx codes. This avoids creating inadvertent contradictions or the need to up= date the document should there be changes in the generic handling. In other= words, 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I=92m not sure why the calling party would indicate 666. After receiving a = re-INVITE? In response to a BYE? I admit that I lack the imagination as to = how this would occur and why this would cause anything other than what woul= d happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I=92m misled int= o dialing a number (e.g., as part of a spam email) that turns out to be a r= obot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning From: Brett Tate [mailto:brett@broadsoft.com] Sent: Friday, January 06, 2017 12:32 PM To: marianne.mohali@orange.com; Henning = Schulzrinne >; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected p= arty to change mid-dialog 1) without it being communicated and 2) with it b= eing communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagge= d by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party i= ndicating 666. Other than a way to attack someone, I=92m not sure if are a= ny 3PCC, transfer, or other service situations where it might actually be a= ppropriate. From: marianne.mohali@orange.com [mailto= :marianne.mohali@orange.com] Sent: Friday, January 06, 2017 10:28 AM To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpret= ation when the caller has several identities used for this call (ie. From a= nd P-Asserted-Identity are different) or call forwarding/call transfer use = cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I = propose to add the following text: This document defines a mechanism by which a called party can reject an unw= anted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity ma= y be reflected in different way for a direct call or after a diverting serv= ice in P-Asserted-Identity, From, History-Info or any concurrent header fie= ld that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are= a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_A67541026D6B420885799C3622475633attcom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Action on the 666 will be at the called party end in the terminating c= arrier and not back at the calling party end

Martin C. Dolly=

Lead Member of Technical Staff

Core & Government/Regulatory = Standards

AT&T

Cell: +1.609.9= 03.3360

Email: md3135@att.com

 


On Jan 15, 2017, at 3:49 PM, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov> wrote:

How likely is any of this going to happen for unwanted robocalls? For fi= gure 4, the one scenario I can think of is the "evil" controller = leveraging a service A to call B, and B 666'ing the call or sending a BYE w= ith Reason(666). But that would seem to be pretty standard, even if the final recipient of the 666 or BYE is A (who i= s likely to ignore it).


I think it would help if you could identify the roles of the third parti= es and see if that causes the recipient of the unwanted call to do somethin= g that's harmful to innocent bystanders.


Henning

From: Brett Tate <brett@broadsoft.com>
Sent: Friday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; sipcore= @ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01
 

Hi,

 

Concerning calling party = sending BYE with 666, I just thought that it potentially should be discusse= d.

 

However, RFC 3725 figures= 4 and figure 7 do show how a =93calling party=94 might get replaced by a = =93called party=94.  Thus if the controller doesn=92t strip the Reason while relaying the BYE, it definitely would be possible since both are cal= led parties.

 

If the =93calling party= =94 gets replaced before =93called party=94 sends BYE with 666, who should = be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

 

Thanks,

Brett

 

From: Henning = Schulzrinne [mailto:Henning.= Schulzrinne@fcc.gov]
Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate; marian= ne.mohali@orange.com; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I=92m afraid I don=92t qu= ite follow what text you are suggesting and I=92m suspecting we=92re well i= nto the weeds at this point. My general inclination is to only state things where 666 differs from 6xx handling, rather than try to capture all= possible status code issues that are generic to (most) 6xx codes. This avo= ids creating inadvertent contradictions or the need to update the document = should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise = noted.

 

Thus, can you provide sug= gested text?

 

I=92m not sure why the ca= lling party would indicate 666. After receiving a re-INVITE? In response to= a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen= for a generic 6xx response in those circumstances.

 

Stretching the imaginatio= n, I could imagine the case where I=92m misled into dialing a number (e.g.,= as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason.

 

Is that the case you have= in mind?

 

Henning

 

From: Brett = Tate [mailto:bre= tt@broadsoft.com]
Sent: Friday, January 06, 2017 12:32 PM
To: marianne.mohali@orange.com; Henning Schulzrinne &= lt;Henni= ng.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

The draft potentially sho= uld also discuss the potential for the connected party to change mid-dialog= 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.

 

From a security considera= tions perspective, the wrong party might be flagged by the 666 when the con= nected party changes.

 

The draft should potentia= lly also discuss the potential for calling party indicating 666.  Othe= r than a way to attack someone, I=92m not sure if are any 3PCC, transfer, or other service situations where it might actually be appropria= te.

 

 

From: marianne.m= ohali@orange.com [mailto:marianne.mohali@orange.com= ]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

To reflect the ques= tion of the interpretation of the 666 response interpretation when the call= er has several identities used for this call (ie. From and P-Asserted-Ident= ity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be = considered has a fraudulent (ie. the calling party or the diverting party o= r both ?) ; I propose to add the following text:

This document defin= es a mechanism by which a called party can reject an unwanted call without = consideration of the calling party identification that remain to the servic= e provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or afte= r a diverting service in P-Asserted-Identity, From, History-Info or any con= current header field that can be present at the same time in a SIP message.=

 

Those questions are= real issues for operators and implementors and they are a weakness that fr= audulent callers could use to bypass the mechanism.

 

BR,

Marianne

 

 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www= .ietf.org/mailman/listinfo/sipcore
--_000_A67541026D6B420885799C3622475633attcom_-- From nobody Mon Jan 16 08:38:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7317312959E for ; Mon, 16 Jan 2017 08:38:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2fL7ze8Fpbq for ; Mon, 16 Jan 2017 08:38:44 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1BD1294D6 for ; Mon, 16 Jan 2017 08:38:44 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.17/8.16.0.17) with SMTP id v0GGZY5K032146; Mon, 16 Jan 2017 11:38:41 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 280n4fjex2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Jan 2017 11:38:40 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0GGcdBM031784; Mon, 16 Jan 2017 11:38:40 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id v0GGcYeL031708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 16 Jan 2017 11:38:35 -0500 Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (MISOUT7MSGHUBAG.itservices.sbc.com [130.9.129.151]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 16 Jan 2017 16:38:21 GMT Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.18]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0319.002; Mon, 16 Jan 2017 11:38:20 -0500 From: "DOLLY, MARTIN C" To: Christer Holmberg , Adam Roach , "'SIPCORE'" , Rifaat Shekh-Yusef Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdm0E02YJFp00GoTEcPhv1fDKE252CwgARr+cA= Date: Mon, 16 Jan 2017 16:38:20 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.70.142.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-16_14:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1701160242 Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 16:38:45 -0000 I support its adoption. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Friday, January 13, 2017 4:11 PM To: Adam Roach ; 'SIPCORE' ; Rifaat She= kh-Yusef Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones Hi, In addition, I'd like to consider adopting: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ As indicated by Rifaat, while THIS draft was just submitted, it's related t= o an topic that we have already discussed in the past. Based on discussions= with e.g., Jon Peterson, the controversial parts of the previous suggestio= n has been removed from the new draft. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 13 January 2017 02:52 To: 'SIPCORE' Subject: [sipcore] Call for Adoptions: Drafts for new milestones [as chair] As I mentioned in an earlier message, we have new milestones for SIPCORE, m= any of which we hope to finish in the first half of the year.=20 To that end, I'd like to call for adoption of the documents that prompted a= dding the milestones. To be specific: We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milesto= ne "mechanism for labeling the nature of SIP calls" We propose adopting draft-holmberg-sipcore-content-id for the milestone "cl= arification of the use of Content-ID" We propose adopting draft-sparks-sipcore-name-addr-guidance for the milesto= ne "clarification of the use of name-addr" I'll note that these document -- and in particular the last two -- have had= significant discussion and feedback already. In particular, the author of = draft-sparks-sipcore-name-addr-guidance indicates that he believes that doc= ument is "done" and basically ready for last call. Please provide feedback regarding adoption of these documents by Friday, Ja= nuary 27. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Mon Jan 16 09:40:56 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A141295ED for ; Mon, 16 Jan 2017 09:40:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DJN_LxobDfMA for ; Mon, 16 Jan 2017 09:40:52 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E296129510 for ; Mon, 16 Jan 2017 09:40:52 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Jan 2017 12:40:50 -0500 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0319.002; Mon, 16 Jan 2017 12:40:50 -0500 From: Andrew Allen To: MARTIN DOLLY , Christer Holmberg , Adam Roach , 'SIPCORE' , Rifaat Shekh-Yusef Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdKp3pLrZIzz0qNkaCaATuI/6E3PHGAgARq1gD//72kIA== Date: Mon, 16 Jan 2017 17:40:49 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233A896F0BXMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 17:40:55 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233A896F0BXMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 Sent from my BlackBerry - the most secure mobile device From: md3135@att.com Sent: January 16, 2017 8:38 AM To: christer.holmberg@ericsson.com; adam@nostrum.com; sipcore@ietf.org; rif= aat.ietf@gmail.com Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones I support its adoption. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Friday, January 13, 2017 4:11 PM To: Adam Roach ; 'SIPCORE' ; Rifaat She= kh-Yusef Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones Hi, In addition, I'd like to consider adopting: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ As indicated by Rifaat, while THIS draft was just submitted, it's related t= o an topic that we have already discussed in the past. Based on discussions= with e.g., Jon Peterson, the controversial parts of the previous suggestio= n has been removed from the new draft. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 13 January 2017 02:52 To: 'SIPCORE' Subject: [sipcore] Call for Adoptions: Drafts for new milestones [as chair] As I mentioned in an earlier message, we have new milestones for SIPCORE, m= any of which we hope to finish in the first half of the year. To that end, I'd like to call for adoption of the documents that prompted a= dding the milestones. To be specific: We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milesto= ne "mechanism for labeling the nature of SIP calls" We propose adopting draft-holmberg-sipcore-content-id for the milestone "cl= arification of the use of Content-ID" We propose adopting draft-sparks-sipcore-name-addr-guidance for the milesto= ne "clarification of the use of name-addr" I'll note that these document -- and in particular the last two -- have had= significant discussion and feedback already. In particular, the author of = draft-sparks-sipcore-name-addr-guidance indicates that he believes that doc= ument is "done" and basically ready for last call. Please provide feedback regarding adoption of these documents by Friday, Ja= nuary 27. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_BBF5DDFE515C3946BC18D733B20DAD233A896F0BXMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

Sent from my BlackBerry - the most secure mobile device
From: md3135@att.com
Sent: January 16, 2017 8:38 AM
To: christer.holmberg@ericsson.com; adam@nostrum.co= m; sipcore@ietf.org; rifaat.ietf@gmail.com
Subject: Re: [sipcore] Call for Adoptions: Dra= fts for new milestones

I support its adoption.

-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Christer Holmberg
Sent: Friday, January 13, 2017 4:11 PM
To: Adam Roach <adam@nostrum.com>; 'SIPCORE' <sipcore@ietf.org>= ; Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones

Hi,

In addition, I'd like to consider adopting:

https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/

As indicated by Rifaat, while THIS draft was just submitted, it's related t= o an topic that we have already discussed in the past. Based on discussions= with e.g., Jon Peterson, the controversial parts of the previous suggestio= n has been removed from the new draft.

Regards,

Christer


-----Original Message-----
From: sipcore [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Adam Roach
Sent: 13 January 2017 02:52
To: 'SIPCORE' <sipcore@ietf.org>
Subject: [sipcore] Call for Adoptions: Drafts for new milestones

[as chair]

As I mentioned in an earlier message, we have new milestones for SIPCORE, m= any of which we hope to finish in the first half of the year.
To that end, I'd like to call for adoption of the documents that prompted a= dding the milestones. To be specific:

We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milesto= ne "mechanism for labeling the nature of SIP calls"

We propose adopting draft-holmberg-sipcore-content-id for the milestone &qu= ot;clarification of the use of Content-ID"

We propose adopting draft-sparks-sipcore-name-addr-guidance for the milesto= ne "clarification of the use of name-addr"

I'll note that these document -- and in particular the last two -- have had= significant discussion and feedback already. In particular, the author of = draft-sparks-sipcore-name-addr-guidance indicates that he believes that doc= ument is "done" and basically ready for last call.

Please provide feedback regarding adoption of these documents by Friday, Ja= nuary 27. Thanks!

/a

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
 --_000_BBF5DDFE515C3946BC18D733B20DAD233A896F0BXMB122CNCrimnet_-- From nobody Tue Jan 17 04:15:59 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C667129447 for ; Tue, 17 Jan 2017 04:15:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bLWVCDy6WwBo for ; Tue, 17 Jan 2017 04:15:56 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79B5D1293E9 for ; Tue, 17 Jan 2017 04:15:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bs3oThBXSBq8KCNOC7upcXJOEHAcbLEz1y66LulTK6c=; b=icnIgCvFUghqF1f6C/NA4RH+HpcR0he9OFlJ3ptMvfZCKdFrKz3CJ6Hh7gcKqWM5KktYYRCtenwXPBbDyk0K1XXwx+jXC7GNmCbOM/R00oZpcMxuunlVBpR4D8E4x40yLMZ2Nlks9eTedvRGI8qyCm+0D4LuusiuPiZ9pdl/FeA= Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0021.outbound.protection.outlook.com [216.32.181.21]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-80-QJtAk_ghOBSWaUhJ5BsbMw-1; Tue, 17 Jan 2017 07:15:50 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Tue, 17 Jan 2017 12:15:48 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0860.012; Tue, 17 Jan 2017 12:15:48 +0000 From: "Asveren, Tolga" To: "Olle E. Johansson" , Christer Holmberg Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdQZ/4EoUfqQ0GSCqQgwoyVVaE26J+AgAC3h4CABPwaMA== Date: Tue, 17 Jan 2017 12:15:47 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 85981a17-3c81-4dad-7ea5-08d43ed29209 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:dYtkeU6zOHqd+79aUYlBDr9nf6U1bAQJbLDiJjzcjBLao6rcsz/K5aDJp6QhF3eRn8buAspFE+KrEvDtDjlWu2WjfZK5FfmLSZmRFYFqEwhZli1x6oeD/clFADdekglbwkYnlq7dr+EwikHleKQAQVQM5HTSiBD6tDz1oaobe8G8NsEVN57NG1Prten7aPLRq0xsJTZBX+lAf49GrskIGw+KWFheakDaYpAwXW/ryRkSnpV07RWWg1IFP/Ss+yUIP6ThvtcLOfmNuytM8b44rKZVliC+Y5p7pVr6R+qf8wQ1C10/AqiGLk/+nQcN9qZY16JCDKOdLv9ZJn7/K1aeFoFGMcOhVNOnThs1Ldng5BCSyviQwhaSkun+QhKJVZALBCqKqmDwbbCToa9ROvbdiFbwuasreRGqDwwlYNDRnpPIhH8syQWctR7yZhz3w21xLFqe13qUdk/7pARou57ThA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(13464003)(189002)(377454003)(199003)(101416001)(2906002)(7736002)(54356999)(50986999)(2950100002)(68736007)(305945005)(86362001)(74316002)(76176999)(189998001)(7696004)(8936002)(122556002)(81166006)(3280700002)(8676002)(81156014)(97736004)(3660700001)(5001770100001)(99286003)(55016002)(54906002)(4326007)(6306002)(6116002)(102836003)(3846002)(106116001)(38730400001)(39060400001)(2900100001)(77096006)(66066001)(30001)(33656002)(106356001)(9686003)(229853002)(5660300001)(105586002)(6436002)(6506006)(25786008)(92566002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 12:15:47.8341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: QJtAk_ghOBSWaUhJ5BsbMw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: SIPCORE , Rifaat Shekh-Yusef Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 12:15:58 -0000 The same here. Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Olle E. > Johansson > Sent: Saturday, January 14, 2017 3:08 AM > To: Christer Holmberg > Cc: SIPCORE ; Olle E Johansson ; Rifaat > Shekh-Yusef > Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones >=20 >=20 > > On 13 Jan 2017, at 22:10, Christer Holmberg > wrote: > > > > Hi, > > > > In addition, I'd like to consider adopting: > > > > https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ > > > > As indicated by Rifaat, while THIS draft was just submitted, it's relat= ed to an > topic that we have already discussed in the past. Based on discussions wi= th > e.g., Jon Peterson, the controversial parts of the previous suggestion ha= s > been removed from the new draft. > I agree on adopting this document. >=20 > /O > > > > Regards, > > > > Christer > > > > > > -----Original Message----- > > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 13 January 2017 02:52 > > To: 'SIPCORE' > > Subject: [sipcore] Call for Adoptions: Drafts for new milestones > > > > [as chair] > > > > As I mentioned in an earlier message, we have new milestones for > SIPCORE, many of which we hope to finish in the first half of the year. > > To that end, I'd like to call for adoption of the documents that prompt= ed > adding the milestones. To be specific: > > > > We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the > milestone "mechanism for labeling the nature of SIP calls" > > > > We propose adopting draft-holmberg-sipcore-content-id for the milestone > "clarification of the use of Content-ID" > > > > We propose adopting draft-sparks-sipcore-name-addr-guidance for the > milestone "clarification of the use of name-addr" > > > > I'll note that these document -- and in particular the last two -- have= had > significant discussion and feedback already. In particular, the author of= draft- > sparks-sipcore-name-addr-guidance indicates that he believes that > document is "done" and basically ready for last call. > > > > Please provide feedback regarding adoption of these documents by Friday= , > January 27. Thanks! > > > > /a > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 17 08:37:33 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DB51129964 for ; Tue, 17 Jan 2017 08:37:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYRzQMYfVzPH for ; Tue, 17 Jan 2017 08:37:28 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F1E1129584 for ; Tue, 17 Jan 2017 08:37:23 -0800 (PST) Received: from pps.filterd (m0103510.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0HGUQLd004254 for ; Tue, 17 Jan 2017 11:37:23 -0500 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0a-001d8301.pphosted.com with ESMTP id 27yhky65h8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 17 Jan 2017 11:37:22 -0500 Received: by mail-lf0-f70.google.com with SMTP id z134so63276582lff.5 for ; Tue, 17 Jan 2017 08:37:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=39Deg8mba0eOgHFkIp/pHhHQMmgQhdgvrw9Qpaea7nE=; b=xUTLUKPqDtHsfsdBXCqLVMKPweY4jBkq9WDI6acz29TPQ4wHE97j7iufmUBudNi9kr PdCJLiU6WUOREMfkBZrvHihwknvpHV43mX/OZ9H6Psrv9r4GyIKY8k6rW/i5EYqebqNc TUs+GMG4iRHbaj4F69ECgwgYfkKvorf3SHuXJ6IHEAd0H0rseQUbhN7o8yutZh+Ajkn2 TTZ1mdG6Fx0Z2a6cXPhsPWXL2btC4LGrU0BIyoJwONJ2AdkpnYJL/aL86O5TndZ/L9Xo 1aOfSk1KlcFnzses63M5D1Bq5O5toAc/tF5i69Ey9IRgDbC5oVNrT3cSfCe7CoEDOWTe RKiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=39Deg8mba0eOgHFkIp/pHhHQMmgQhdgvrw9Qpaea7nE=; b=F3AZzixpiiZzfgtIlDUg+flcFhf6FxdgQGylQV9OIf3OdsD39EQfZIdf4dNEjqKMXp ZmCebhfgBtO/J7NX3ysmrlb1m+nLsccJmekBPEN+de6goJg11EovjBRd68PCFpjV4Dm+ 84Y8utte9dOnc9i9DO5fD0lM0L6C7XxTElnU3PgZMh2D6no7hWsB8Qbsv24oPLI/tDCk WcFtN2AyujyEicp/fQJ4B4tZtmmYWa1QMYohasr9Yuqktbd2SDKPwhFduhhfjPwMutHl E3Bw796AVa5TXC9Pn8fxCFutuiYxje/xGlyGp2Fy1UmhzKpUQhI7ZPCBzNTUv2GonP5m +B6A== X-Gm-Message-State: AIkVDXIKf+KNkkCi9xuQ2OubaYj5FipNRV59IKVcbytGWPLtGiZFLv+7v6PRufeRJU5A7sAA8iCDH3Cc8rIWNU81lOG1C/rWiQ4nZF8vf6uQDI5risOLWCtP0ygLq07UQXu8mYHr4Zt0Jwzx X-Received: by 10.46.7.26 with SMTP id 26mr6966819ljh.60.1484671039931; Tue, 17 Jan 2017 08:37:19 -0800 (PST) X-Received: by 10.46.7.26 with SMTP id 26mr6966805ljh.60.1484671039650; Tue, 17 Jan 2017 08:37:19 -0800 (PST) From: Brett Tate References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6CXui9W95VUBH0jmMtoymegvUCwBsOs1Nn+nx+4A= Date: Tue, 17 Jan 2017 11:37:18 -0500 Message-ID: To: Henning Schulzrinne , sipcore@ietf.org Content-Type: multipart/alternative; boundary=f403045ebc7aed52e005464ce9f2 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-17_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 16:37:30 -0000 --f403045ebc7aed52e005464ce9f2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Concerning the likelihood, I assume that it would depend upon if there is a convenience, business, or mischievous reason to do it. As I=E2=80=99ve mentioned, I find the concept of who gets impacted by 666 s= omewhat vague within the draft because of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity. However, I assume that the draft can proceed without needing to clarify that stuff. If anyone knows the answers to the following, please let me know. If the "calling party" gets replaced before "called party" sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party? Should the connected party be flagged if the "calling party" sends BYE with 666? Should the call forwarding party be flagged when flagging the "calling party"? I assume no since potentially innocent bystander. Should the call transferring party be flagged when flagging the "calling party"? Thanks, Brett *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Sunday, January 15, 2017 3:49 PM *To:* Brett Tate; sipcore@ietf.org *Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 How likely is any of this going to happen for unwanted robocalls? For figure 4, the one scenario I can think of is the "evil" controller leveraging a service A to call B, and B 666'ing the call or sending a BYE with Reason(666). But that would seem to be pretty standard, even if the final recipient of the 666 or BYE is A (who is likely to ignore it). I think it would help if you could identify the roles of the third parties and see if that causes the recipient of the unwanted call to do something that's harmful to innocent bystanders. Henning ------------------------------ *From:* Brett Tate *Sent:* Friday, January 13, 2017 3:48:58 PM *To:* Henning Schulzrinne; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning calling party sending BYE with 666, I just thought that it potentially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a =E2=80=9Ccalling par= ty=E2=80=9D might get replaced by a =E2=80=9Ccalled party=E2=80=9D. Thus if the contro= ller doesn=E2=80=99t strip the Reason while relaying the BYE, it definitely would be possible since both are called parties. If the =E2=80=9Ccalling party=E2=80=9D gets replaced before =E2=80=9Ccalled= party=E2=80=9D sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party? Thanks, Brett *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Thursday, January 12, 2017 3:31 PM *To:* Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I=E2=80=99m afraid I don=E2=80=99t quite follow what text you are suggestin= g and I=E2=80=99m suspecting we=E2=80=99re well into the weeds at this point. My general incl= ination is to only state things where 666 differs from 6xx handling, rather than try to capture all possible status code issues that are generic to (most) 6xx codes. This avoids creating inadvertent contradictions or the need to update the document should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I=E2=80=99m not sure why the calling party would indicate 666. After receiv= ing a re-INVITE? In response to a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I=E2=80=99m misl= ed into dialing a number (e.g., as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning *From:* Brett Tate [mailto:brett@broadsoft.com ] *Sent:* Friday, January 06, 2017 12:32 PM *To:* marianne.mohali@orange.com; Henning Schulzrinne < Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected party to change mid-dialog 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagged by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party indicating 666. Other than a way to attack someone, I=E2=80=99m not sure i= f are any 3PCC, transfer, or other service situations where it might actually be appropriate. *From:* marianne.mohali@orange.com [mailto:marianne.mohali@orange.com] *Sent:* Friday, January 06, 2017 10:28 AM *To:* Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpretation when the caller has several identities used for this call (ie. From and P-Asserted-Identity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be considered has a fraudulent (ie. the calling party or the diverting party or both ?) ; I propose to add the following text: This document defines a mechanism by which a called party can reject an unwanted call without consideration of the calling party identification that remain to the service provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or after a diverting service in P-Asserted-Identity, From, History-Info or any concurrent header field that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --f403045ebc7aed52e005464ce9f2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --f403045ebc7aed52e005464ce9f2-- From nobody Tue Jan 17 15:05:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABC341295DF for ; Tue, 17 Jan 2017 15:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eI56x0hSX6WW for ; Tue, 17 Jan 2017 15:05:33 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAA1B1295D4 for ; Tue, 17 Jan 2017 15:05:32 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0HMx2MQ015710; Tue, 17 Jan 2017 23:05:31 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0053.outbound.protection.outlook.com [23.103.198.53]) by mx0b-0024ed01.pphosted.com with ESMTP id 27yevv1gj3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Jan 2017 23:05:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CorIuqw6zNvHXtYzWxQwbIgjwNpht0DOpPARbT1+PNw=; b=htzTga8EZNWJU12mqTV9IUJ4z+Nz9KpXzHCs+MUQzgtG7PyznDhxAnS4kE93ifZSOmO3jydfBerH5ubrdHZlus/Wks3QhgsoW0/ptmyrFgnL5car40yp6eQRwTLIY/nIHmNUDAdevIws8mxQ7kF/TV16xNz3lkB4LV9SCWChtl4= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Tue, 17 Jan 2017 23:05:30 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Tue, 17 Jan 2017 23:05:29 +0000 From: Henning Schulzrinne To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJt3jyCDTTT21QxQfGC4OLjh1QSQABkfEPTAFvyfgAADUbgoA== Date: Tue, 17 Jan 2017 23:05:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 005efebf-85ce-4da6-9aef-08d43f2d5518 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:n9heeegR/03TeOhDW196xuovT+d64XCihEEjEgm6+/SIwBgjgxzq2qUehnjlsEh5dNCUuzi+gzt2DCpTeywlJfWgwaL88nGnqe3lmND4kGbVDCCrSKI5uAZyJr/re49JhEmTZ3xdUu7bOK7jEV0TOKqt90gok9O1nnsTKV+g9E/A4S+nM/2DJe+iN7ij/ObHHOOC+GrDiaY3W7XJlox643KdFXF1FXPMaULEPk9ESXUAU3ER3enb4IlsJlhu3IjRCOlcxMn/jK1qb1AEdBjLAhBS9T5andhNHPi1EA4hCHC7LyldKuMvx9Xj1b67579N//9iLAVAkLwaJ11ldMAm6EaUtlvaSwDM8TycgnwyWE8Vq78/QO3enFYF3O0RkfHrTOSS54pNA7xdHm1jVqCqLeTOPq3HbSTRQGXelcc9DNgK4ysh1SjQckaopr32NNmFHxuOVSuxPnjgkuRB9Jw2Gg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(377454003)(25786008)(7696004)(97736004)(236005)(2900100001)(99286003)(122556002)(5660300001)(8676002)(74316002)(81156014)(101416001)(81166006)(6436002)(77096006)(2950100002)(86362001)(66066001)(7736002)(6506006)(106356001)(189998001)(3280700002)(105586002)(38730400001)(229853002)(55016002)(107886002)(9686003)(92566002)(19609705001)(6306002)(2906002)(68736007)(2501003)(54896002)(3660700001)(102836003)(790700001)(5001770100001)(3846002)(8936002)(6116002)(50986999)(54356999)(76176999)(230783001)(33656002)(53936002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB0634D40E5EFC42E15861DE73EA7C0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 23:05:29.7224 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-17_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:05:36 -0000 --_000_CY1PR09MB0634D40E5EFC42E15861DE73EA7C0CY1PR09MB0634namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSBtZW50aW9uZWQgYmVmb3JlLCBpdCBzZWVtcyBzb21ld2hhdCB1bmxpa2VseSB0aGF0IDNQ Q0Mgc2NlbmFyaW9zIG9jY3VyIGZvciB1bndhbnRlZCBjYWxscywgZXhjZXB0IGJ5IGFjY2lkZW50 IG9yIGJlY2F1c2Ugb2YgZm9yd2FyZC1vbi1idXN5IG9yIGZvcndhcmQtb24tdmFjYXRpb24uIChB ZG1pbiBhc3Npc3RhbnQgdHJhbnNmZXJzIGEgY2FsbCBmcm9tIOKAnE1hcnJpb3R0IEhvdGVsc+KA nSB0byBoaXMgYm9zcywgdGhpbmtpbmcgdGhhdCB0aGlzIGlzIGFib3V0IGFuIHVwY29taW5nIGhv dGVsIHJlc2VydmF0aW9uLCBidXQgdGhlIGNhbGwgdHVybnMgb3V0IHRvIGJlIHNwYW0uKSBBcyB5 b3Ugbm90ZSwgdGhlIGZvcndhcmRpbmcgcGFydHkgc2hvdWxkIG5vdCBiZSBmbGFnZ2VkLg0KDQpC dXQgc2luY2UgaXTigJlzIHRoZSBjb250ZW50IG9mIHRoZSBjYWxsIGlzIGRlZW1lZCBvYmplY3Rp b25hYmxlICh1bndhbnRlZCkgYnkgdGhlIHJlY2lwaWVudCwgdGhlIGdvYWwgc2hvdWxkIGJlIHRv IGlkZW50aWZ5IHRoZSBwYXJ0eSB0aGF0IGlzIGdlbmVyYXRpbmcgdGhhdCBjb250ZW50LCBldmVu IGlmIHRoZXkgdHJ5IHRvIGhpZGUgYmVoaW5kIHNvbWVib2R5IGVsc2UuDQoNCknigJltIHByb2Jh Ymx5IGxhY2tpbmcgaW1hZ2luYXRpb24sIGJ1dCBjYW4geW91IGV4cGxhaW4gaG93IHRoZXNlIHNj ZW5hcmlvcyB3b3VsZCBvY2N1ciBpbiB0aGUgdHlwaWNhbCByb2JvY2FsbCwgYmV5b25kIHRoZSBh Y2NpZGVudGFsIGZvcndhcmRpbmcgY2FzZSBhYm92ZT8gSSBjYW4gc2VlIGluY2VudGl2ZXMgZm9y IGJhZCBhY3RvcnMgdG8gaGlkZSBiZWhpbmQgaW5ub2NlbnQgdGhpcmQgcGFydGllcywgYnV0IEni gJltIG5vdCBzdXJlIHRoYXTigJlzIHdoYXQgeW91IGhhdmUgaW4gbWluZCBmb3IgdGhlIHNjZW5h cmlvcyBiZWxvdy4NCg0KSXMgdGhlcmUgYSBkZWZpbmFibGUgbm90aW9uIG9mIHRoZSDigJxvcmln aW5hbOKAnSBjYWxsaW5nIHBhcnR5IHNpbmNlIHRoYXQgc2VlbXMgbW9zdCBsaWtlbHkgdG8gYmUg dGhlIGJhZCBhY3Rvcj8NCg0KSGVubmluZw0KDQpGcm9tOiBCcmV0dCBUYXRlIFttYWlsdG86YnJl dHRAYnJvYWRzb2Z0LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTcgMTE6Mzcg QU0NClRvOiBIZW5uaW5nIFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+ OyBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDENCg0KSGksDQoNCkNvbmNlcm5pbmcg dGhlIGxpa2VsaWhvb2QsIEkgYXNzdW1lIHRoYXQgaXQgd291bGQgZGVwZW5kIHVwb24gaWYgdGhl cmUgaXMgYSBjb252ZW5pZW5jZSwgYnVzaW5lc3MsIG9yIG1pc2NoaWV2b3VzIHJlYXNvbiB0byBk byBpdC4NCg0KQXMgSeKAmXZlIG1lbnRpb25lZCwgSSBmaW5kIHRoZSBjb25jZXB0IG9mIHdobyBn ZXRzIGltcGFjdGVkIGJ5IDY2NiBzb21ld2hhdCB2YWd1ZSB3aXRoaW4gdGhlIGRyYWZ0IGJlY2F1 c2Ugb2YgdGhlIHZhcmlldHkgb2YgY2FsbCBzZXJ2aWNlcyAoM1BDQywgY2FsbCBmb3J3YXJkaW5n LCB0cmFuc2ZlciwgZXQgY2V0ZXJhKSBhbmQgd2F5cyB0byB1cGRhdGUgdGhlIGNvbm5lY3RlZCBp ZGVudGl0eS4gIEhvd2V2ZXIsIEkgYXNzdW1lIHRoYXQgdGhlIGRyYWZ0IGNhbiBwcm9jZWVkIHdp dGhvdXQgbmVlZGluZyB0byBjbGFyaWZ5IHRoYXQgc3R1ZmYuDQoNCklmIGFueW9uZSBrbm93cyB0 aGUgYW5zd2VycyB0byB0aGUgZm9sbG93aW5nLCBwbGVhc2UgbGV0IG1lIGtub3cuDQoNCklmIHRo ZSAiY2FsbGluZyBwYXJ0eSIgZ2V0cyByZXBsYWNlZCBiZWZvcmUgImNhbGxlZCBwYXJ0eSIgc2Vu ZHMgQllFIHdpdGggNjY2LCB3aG8gc2hvdWxkIGJlIGZsYWdnZWQ6IDEpIGNhbGxpbmcgcGFydHkg aW5kaWNhdGVkIHdpdGhpbiBvcmlnaW5hbCBJTlZJVEUgb3IgMikgbmV3ZXN0IGNvbm5lY3RlZCBw YXJ0eT8NCg0KU2hvdWxkIHRoZSBjb25uZWN0ZWQgcGFydHkgYmUgZmxhZ2dlZCBpZiB0aGUgImNh bGxpbmcgcGFydHkiIHNlbmRzIEJZRSB3aXRoIDY2Nj8NCg0KU2hvdWxkIHRoZSBjYWxsIGZvcndh cmRpbmcgcGFydHkgYmUgZmxhZ2dlZCB3aGVuIGZsYWdnaW5nIHRoZSAiY2FsbGluZyBwYXJ0eSI/ ICBJIGFzc3VtZSBubyBzaW5jZSBwb3RlbnRpYWxseSBpbm5vY2VudCBieXN0YW5kZXIuDQoNClNo b3VsZCB0aGUgY2FsbCB0cmFuc2ZlcnJpbmcgcGFydHkgYmUgZmxhZ2dlZCB3aGVuIGZsYWdnaW5n IHRoZSAiY2FsbGluZyBwYXJ0eSI/DQoNClRoYW5rcywNCkJyZXR0DQoNCkZyb206IEhlbm5pbmcg U2NodWx6cmlubmUgW21haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8bWFpbHRvOkhl bm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj5dDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTUsIDIw MTcgMzo0OSBQTQ0KVG86IEJyZXR0IFRhdGU7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNv cmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDENCg0KDQpIb3cgbGlrZWx5IGlzIGFueSBvZiB0 aGlzIGdvaW5nIHRvIGhhcHBlbiBmb3IgdW53YW50ZWQgcm9ib2NhbGxzPyBGb3IgZmlndXJlIDQs IHRoZSBvbmUgc2NlbmFyaW8gSSBjYW4gdGhpbmsgb2YgaXMgdGhlICJldmlsIiBjb250cm9sbGVy IGxldmVyYWdpbmcgYSBzZXJ2aWNlIEEgdG8gY2FsbCBCLCBhbmQgQiA2NjYnaW5nIHRoZSBjYWxs IG9yIHNlbmRpbmcgYSBCWUUgd2l0aCBSZWFzb24oNjY2KS4gQnV0IHRoYXQgd291bGQgc2VlbSB0 byBiZSBwcmV0dHkgc3RhbmRhcmQsIGV2ZW4gaWYgdGhlIGZpbmFsIHJlY2lwaWVudCBvZiB0aGUg NjY2IG9yIEJZRSBpcyBBICh3aG8gaXMgbGlrZWx5IHRvIGlnbm9yZSBpdCkuDQoNCg0KDQpJIHRo aW5rIGl0IHdvdWxkIGhlbHAgaWYgeW91IGNvdWxkIGlkZW50aWZ5IHRoZSByb2xlcyBvZiB0aGUg dGhpcmQgcGFydGllcyBhbmQgc2VlIGlmIHRoYXQgY2F1c2VzIHRoZSByZWNpcGllbnQgb2YgdGhl IHVud2FudGVkIGNhbGwgdG8gZG8gc29tZXRoaW5nIHRoYXQncyBoYXJtZnVsIHRvIGlubm9jZW50 IGJ5c3RhbmRlcnMuDQoNCg0KDQpIZW5uaW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpGcm9tOiBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPG1haWx0bzpicmV0 dEBicm9hZHNvZnQuY29tPj4NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAxMywgMjAxNyAzOjQ4OjU4 IFBNDQpUbzogSGVubmluZyBTY2h1bHpyaW5uZTsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lw Y29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQt aWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KDQpIaSwNCg0KQ29uY2VybmluZyBjYWxs aW5nIHBhcnR5IHNlbmRpbmcgQllFIHdpdGggNjY2LCBJIGp1c3QgdGhvdWdodCB0aGF0IGl0IHBv dGVudGlhbGx5IHNob3VsZCBiZSBkaXNjdXNzZWQuDQoNCkhvd2V2ZXIsIFJGQyAzNzI1IGZpZ3Vy ZXMgNCBhbmQgZmlndXJlIDcgZG8gc2hvdyBob3cgYSDigJxjYWxsaW5nIHBhcnR54oCdIG1pZ2h0 IGdldCByZXBsYWNlZCBieSBhIOKAnGNhbGxlZCBwYXJ0eeKAnS4gIFRodXMgaWYgdGhlIGNvbnRy b2xsZXIgZG9lc27igJl0IHN0cmlwIHRoZSBSZWFzb24gd2hpbGUgcmVsYXlpbmcgdGhlIEJZRSwg aXQgZGVmaW5pdGVseSB3b3VsZCBiZSBwb3NzaWJsZSBzaW5jZSBib3RoIGFyZSBjYWxsZWQgcGFy dGllcy4NCg0KSWYgdGhlIOKAnGNhbGxpbmcgcGFydHnigJ0gZ2V0cyByZXBsYWNlZCBiZWZvcmUg 4oCcY2FsbGVkIHBhcnR54oCdIHNlbmRzIEJZRSB3aXRoIDY2Niwgd2hvIHNob3VsZCBiZSBmbGFn Z2VkOiAxKSBjYWxsaW5nIHBhcnR5IGluZGljYXRlZCB3aXRoaW4gb3JpZ2luYWwgSU5WSVRFIG9y IDIpIG5ld2VzdCBjb25uZWN0ZWQgcGFydHk/DQoNClRoYW5rcywNCkJyZXR0DQoNCkZyb206IEhl bm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8bWFp bHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdj5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFy eSAxMiwgMjAxNyAzOjMxIFBNDQpUbzogQnJldHQgVGF0ZTsgbWFyaWFubmUubW9oYWxpQG9yYW5n ZS5jb208bWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tPjsgc2lwY29yZUBpZXRmLm9y ZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQ29tbWVu dHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KDQpJ4oCZbSBhZnJh aWQgSSBkb27igJl0IHF1aXRlIGZvbGxvdyB3aGF0IHRleHQgeW91IGFyZSBzdWdnZXN0aW5nIGFu ZCBJ4oCZbSBzdXNwZWN0aW5nIHdl4oCZcmUgd2VsbCBpbnRvIHRoZSB3ZWVkcyBhdCB0aGlzIHBv aW50LiBNeSBnZW5lcmFsIGluY2xpbmF0aW9uIGlzIHRvIG9ubHkgc3RhdGUgdGhpbmdzIHdoZXJl IDY2NiBkaWZmZXJzIGZyb20gNnh4IGhhbmRsaW5nLCByYXRoZXIgdGhhbiB0cnkgdG8gY2FwdHVy ZSBhbGwgcG9zc2libGUgc3RhdHVzIGNvZGUgaXNzdWVzIHRoYXQgYXJlIGdlbmVyaWMgdG8gKG1v c3QpIDZ4eCBjb2Rlcy4gVGhpcyBhdm9pZHMgY3JlYXRpbmcgaW5hZHZlcnRlbnQgY29udHJhZGlj dGlvbnMgb3IgdGhlIG5lZWQgdG8gdXBkYXRlIHRoZSBkb2N1bWVudCBzaG91bGQgdGhlcmUgYmUg Y2hhbmdlcyBpbiB0aGUgZ2VuZXJpYyBoYW5kbGluZy4gSW4gb3RoZXIgd29yZHMsIDY2NiBzaG91 bGQgYmUgdHJlYXRlZCBsaWtlIDZ4eCB1bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkLg0KDQpUaHVzLCBj YW4geW91IHByb3ZpZGUgc3VnZ2VzdGVkIHRleHQ/DQoNCknigJltIG5vdCBzdXJlIHdoeSB0aGUg Y2FsbGluZyBwYXJ0eSB3b3VsZCBpbmRpY2F0ZSA2NjYuIEFmdGVyIHJlY2VpdmluZyBhIHJlLUlO VklURT8gSW4gcmVzcG9uc2UgdG8gYSBCWUU/IEkgYWRtaXQgdGhhdCBJIGxhY2sgdGhlIGltYWdp bmF0aW9uIGFzIHRvIGhvdyB0aGlzIHdvdWxkIG9jY3VyIGFuZCB3aHkgdGhpcyB3b3VsZCBjYXVz ZSBhbnl0aGluZyBvdGhlciB0aGFuIHdoYXQgd291bGQgaGFwcGVuIGZvciBhIGdlbmVyaWMgNnh4 IHJlc3BvbnNlIGluIHRob3NlIGNpcmN1bXN0YW5jZXMuDQoNClN0cmV0Y2hpbmcgdGhlIGltYWdp bmF0aW9uLCBJIGNvdWxkIGltYWdpbmUgdGhlIGNhc2Ugd2hlcmUgSeKAmW0gbWlzbGVkIGludG8g ZGlhbGluZyBhIG51bWJlciAoZS5nLiwgYXMgcGFydCBvZiBhIHNwYW0gZW1haWwpIHRoYXQgdHVy bnMgb3V0IHRvIGJlIGEgcm9ib3QgcGVkZGxpbmcgdGltZSBzaGFyZXMuIEkgY291bGQgc2VuZCBh IEJZRSwgd2l0aCBhIDY2NiBSZWFzb24uDQoNCklzIHRoYXQgdGhlIGNhc2UgeW91IGhhdmUgaW4g bWluZD8NCg0KSGVubmluZw0KDQpGcm9tOiBCcmV0dCBUYXRlIFttYWlsdG86YnJldHRAYnJvYWRz b2Z0LmNvbV0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAwNiwgMjAxNyAxMjozMiBQTQ0KVG86IG1h cmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tPG1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNv bT47IEhlbm5pbmcgU2NodWx6cmlubmUgPEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjxtYWls dG86SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Pj47IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRv OnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRy YWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDENCg0KSGksDQoNClRoZSBkcmFmdCBw b3RlbnRpYWxseSBzaG91bGQgYWxzbyBkaXNjdXNzIHRoZSBwb3RlbnRpYWwgZm9yIHRoZSBjb25u ZWN0ZWQgcGFydHkgdG8gY2hhbmdlIG1pZC1kaWFsb2cgMSkgd2l0aG91dCBpdCBiZWluZyBjb21t dW5pY2F0ZWQgYW5kIDIpIHdpdGggaXQgYmVpbmcgY29tbXVuaWNhdGUgYnkgUkZDIDQ5MTYsIFJG QyA1ODc2LCBldCBjZXRlcmEuDQoNCkZyb20gYSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwZXJz cGVjdGl2ZSwgdGhlIHdyb25nIHBhcnR5IG1pZ2h0IGJlIGZsYWdnZWQgYnkgdGhlIDY2NiB3aGVu IHRoZSBjb25uZWN0ZWQgcGFydHkgY2hhbmdlcy4NCg0KVGhlIGRyYWZ0IHNob3VsZCBwb3RlbnRp YWxseSBhbHNvIGRpc2N1c3MgdGhlIHBvdGVudGlhbCBmb3IgY2FsbGluZyBwYXJ0eSBpbmRpY2F0 aW5nIDY2Ni4gIE90aGVyIHRoYW4gYSB3YXkgdG8gYXR0YWNrIHNvbWVvbmUsIEnigJltIG5vdCBz dXJlIGlmIGFyZSBhbnkgM1BDQywgdHJhbnNmZXIsIG9yIG90aGVyIHNlcnZpY2Ugc2l0dWF0aW9u cyB3aGVyZSBpdCBtaWdodCBhY3R1YWxseSBiZSBhcHByb3ByaWF0ZS4NCg0KDQpGcm9tOiBtYXJp YW5uZS5tb2hhbGlAb3JhbmdlLmNvbTxtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20+ IFttYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1vaGFs aUBvcmFuZ2UuY29tPl0NClNlbnQ6IEZyaWRheSwgSmFudWFyeSAwNiwgMjAxNyAxMDoyOCBBTQ0K VG86IEhlbm5pbmcgU2NodWx6cmlubmU7IEFzdmVyZW4sIFRvbGdhOyBCcmV0dCBUYXRlOyBzaXBj b3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtzaXBj b3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTAxDQoN CkhpLA0KDQpUbyByZWZsZWN0IHRoZSBxdWVzdGlvbiBvZiB0aGUgaW50ZXJwcmV0YXRpb24gb2Yg dGhlIDY2NiByZXNwb25zZSBpbnRlcnByZXRhdGlvbiB3aGVuIHRoZSBjYWxsZXIgaGFzIHNldmVy YWwgaWRlbnRpdGllcyB1c2VkIGZvciB0aGlzIGNhbGwgKGllLiBGcm9tIGFuZCBQLUFzc2VydGVk LUlkZW50aXR5IGFyZSBkaWZmZXJlbnQpIG9yIGNhbGwgZm9yd2FyZGluZy9jYWxsIHRyYW5zZmVy IHVzZSBjYXNlcyBmb3Igd2hpY2ggaXQgaGFzIHRvIGJlIGRpc2N1c3NlZCB3aGljaCBwYXJ0eSBz aG91bGQgYmUgY29uc2lkZXJlZCBoYXMgYSBmcmF1ZHVsZW50IChpZS4gdGhlIGNhbGxpbmcgcGFy dHkgb3IgdGhlIGRpdmVydGluZyBwYXJ0eSBvciBib3RoID8pIDsgSSBwcm9wb3NlIHRvIGFkZCB0 aGUgZm9sbG93aW5nIHRleHQ6DQpUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZWNoYW5pc20gYnkg d2hpY2ggYSBjYWxsZWQgcGFydHkgY2FuIHJlamVjdCBhbiB1bndhbnRlZCBjYWxsIHdpdGhvdXQg Y29uc2lkZXJhdGlvbiBvZiB0aGUgY2FsbGluZyBwYXJ0eSBpZGVudGlmaWNhdGlvbiB0aGF0IHJl bWFpbiB0byB0aGUgc2VydmljZSBwcm92aWRlciBwb2xpY3kuIEluZGVlZCwgdGhlIGNhbGxpbmcg cGFydHkgaWRlbnRpdHkgbWF5IGJlIHJlZmxlY3RlZCBpbiBkaWZmZXJlbnQgd2F5IGZvciBhIGRp cmVjdCBjYWxsIG9yIGFmdGVyIGEgZGl2ZXJ0aW5nIHNlcnZpY2UgaW4gUC1Bc3NlcnRlZC1JZGVu dGl0eSwgRnJvbSwgSGlzdG9yeS1JbmZvIG9yIGFueSBjb25jdXJyZW50IGhlYWRlciBmaWVsZCB0 aGF0IGNhbiBiZSBwcmVzZW50IGF0IHRoZSBzYW1lIHRpbWUgaW4gYSBTSVAgbWVzc2FnZS4NCg0K VGhvc2UgcXVlc3Rpb25zIGFyZSByZWFsIGlzc3VlcyBmb3Igb3BlcmF0b3JzIGFuZCBpbXBsZW1l bnRvcnMgYW5kIHRoZXkgYXJlIGEgd2Vha25lc3MgdGhhdCBmcmF1ZHVsZW50IGNhbGxlcnMgY291 bGQgdXNlIHRvIGJ5cGFzcyB0aGUgbWVjaGFuaXNtLg0KDQpCUiwNCk1hcmlhbm5lDQoNCg0KDQo= --_000_CY1PR09MB0634D40E5EFC42E15861DE73EA7C0CY1PR09MB0634namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0KcC5lbWFpbHF1b3RlLCBsaS5lbWFpbHF1 b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1b3RlOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0OjEuMHB0Ow0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLHNlcmlmO30NCnNwYW4uUHJmb3JtYXRIVE1MQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcj9m b3JtYXQ/IEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlByP2Zvcm1hdD8gSFRNTCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0KcC5QcmZvcm1h dEhUTUwsIGxpLlByZm9ybWF0SFRNTCwgZGl2LlByZm9ybWF0SFRNTA0KCXttc28tc3R5bGUtbmFt ZToiUHI/Zm9ybWF0PyBIVE1MIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlByP2Zvcm1hdD8gSFRNTCBDYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJU ZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJp Zjt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRlZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVz DQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5 N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVt YWlsU3R5bGUzMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTMxDQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+QXMgSSBtZW50aW9uZWQgYmVmb3JlLCBpdCBzZWVtcyBzb21ld2hhdCB1bmxpa2Vs eSB0aGF0IDNQQ0Mgc2NlbmFyaW9zIG9jY3VyIGZvciB1bndhbnRlZCBjYWxscywgZXhjZXB0IGJ5 IGFjY2lkZW50IG9yIGJlY2F1c2Ugb2YgZm9yd2FyZC1vbi1idXN5IG9yIGZvcndhcmQtb24tdmFj YXRpb24uDQogKEFkbWluIGFzc2lzdGFudCB0cmFuc2ZlcnMgYSBjYWxsIGZyb20g4oCcTWFycmlv dHQgSG90ZWxz4oCdIHRvIGhpcyBib3NzLCB0aGlua2luZyB0aGF0IHRoaXMgaXMgYWJvdXQgYW4g dXBjb21pbmcgaG90ZWwgcmVzZXJ2YXRpb24sIGJ1dCB0aGUgY2FsbCB0dXJucyBvdXQgdG8gYmUg c3BhbS4pIEFzIHlvdSBub3RlLCB0aGUgZm9yd2FyZGluZyBwYXJ0eSBzaG91bGQgbm90IGJlIGZs YWdnZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5CdXQgc2lu Y2UgaXTigJlzIHRoZSBjb250ZW50IG9mIHRoZSBjYWxsIGlzIGRlZW1lZCBvYmplY3Rpb25hYmxl ICh1bndhbnRlZCkgYnkgdGhlIHJlY2lwaWVudCwgdGhlIGdvYWwgc2hvdWxkIGJlIHRvIGlkZW50 aWZ5IHRoZSBwYXJ0eSB0aGF0IGlzIGdlbmVyYXRpbmcgdGhhdCBjb250ZW50LA0KIGV2ZW4gaWYg dGhleSB0cnkgdG8gaGlkZSBiZWhpbmQgc29tZWJvZHkgZWxzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJltIHByb2JhYmx5IGxhY2tpbmcgaW1hZ2luYXRp b24sIGJ1dCBjYW4geW91IGV4cGxhaW4gaG93IHRoZXNlIHNjZW5hcmlvcyB3b3VsZCBvY2N1ciBp biB0aGUgdHlwaWNhbCByb2JvY2FsbCwgYmV5b25kIHRoZSBhY2NpZGVudGFsIGZvcndhcmRpbmcg Y2FzZSBhYm92ZT8gSQ0KIGNhbiBzZWUgaW5jZW50aXZlcyBmb3IgYmFkIGFjdG9ycyB0byBoaWRl IGJlaGluZCBpbm5vY2VudCB0aGlyZCBwYXJ0aWVzLCBidXQgSeKAmW0gbm90IHN1cmUgdGhhdOKA mXMgd2hhdCB5b3UgaGF2ZSBpbiBtaW5kIGZvciB0aGUgc2NlbmFyaW9zIGJlbG93LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXMgdGhlcmUgYSBkZWZpbmFibGUg bm90aW9uIG9mIHRoZSDigJxvcmlnaW5hbOKAnSBjYWxsaW5nIHBhcnR5IHNpbmNlIHRoYXQgc2Vl bXMgbW9zdCBsaWtlbHkgdG8gYmUgdGhlIGJhZCBhY3Rvcj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhlbm5pbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+IEJyZXR0IFRhdGUgW21haWx0bzpicmV0dEBicm9hZHNvZnQuY29tXQ0K PGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEphbnVhcnkgMTcsIDIwMTcgMTE6MzcgQU08YnI+ DQo8Yj5Ubzo8L2I+IEhlbm5pbmcgU2NodWx6cmlubmUgJmx0O0hlbm5pbmcuU2NodWx6cmlubmVA ZmNjLmdvdiZndDs7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtz aXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTAx PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+Q29uY2VybmluZyB0aGUgbGlrZWxpaG9vZCwgSSBhc3N1bWUgdGhhdCBpdCB3 b3VsZCBkZXBlbmQgdXBvbiBpZiB0aGVyZSBpcyBhIGNvbnZlbmllbmNlLCBidXNpbmVzcywgb3Ig bWlzY2hpZXZvdXMgcmVhc29uIHRvIGRvIGl0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+QXMgSeKAmXZlIG1lbnRpb25lZCwgSSBmaW5kIHRoZSBjb25jZXB0IG9m IHdobyBnZXRzIGltcGFjdGVkIGJ5IDY2NiBzb21ld2hhdCB2YWd1ZSB3aXRoaW4gdGhlIGRyYWZ0 IGJlY2F1c2Ugb2YgdGhlIHZhcmlldHkgb2YgY2FsbCBzZXJ2aWNlcyAoM1BDQywgY2FsbCBmb3J3 YXJkaW5nLA0KIHRyYW5zZmVyLCBldCBjZXRlcmEpIGFuZCB3YXlzIHRvIHVwZGF0ZSB0aGUgY29u bmVjdGVkIGlkZW50aXR5LiZuYnNwOyBIb3dldmVyLCBJIGFzc3VtZSB0aGF0IHRoZSBkcmFmdCBj YW4gcHJvY2VlZCB3aXRob3V0IG5lZWRpbmcgdG8gY2xhcmlmeSB0aGF0IHN0dWZmLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgYW55b25lIGtub3dzIHRoZSBh bnN3ZXJzIHRvIHRoZSBmb2xsb3dpbmcsIHBsZWFzZSBsZXQgbWUga25vdy48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHRoZSAmcXVvdDtjYWxsaW5nIHBhcnR5 JnF1b3Q7IGdldHMgcmVwbGFjZWQgYmVmb3JlICZxdW90O2NhbGxlZCBwYXJ0eSZxdW90OyBzZW5k cyBCWUUgd2l0aCA2NjYsIHdobyBzaG91bGQgYmUgZmxhZ2dlZDogMSkgY2FsbGluZyBwYXJ0eSBp bmRpY2F0ZWQgd2l0aGluIG9yaWdpbmFsIElOVklURSBvciAyKQ0KIG5ld2VzdCBjb25uZWN0ZWQg cGFydHk/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TaG91bGQg dGhlIGNvbm5lY3RlZCBwYXJ0eSBiZSBmbGFnZ2VkIGlmIHRoZSAmcXVvdDtjYWxsaW5nIHBhcnR5 JnF1b3Q7IHNlbmRzIEJZRSB3aXRoIDY2Nj88L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlNob3VsZCB0aGUgY2FsbCBmb3J3YXJkaW5nIHBhcnR5IGJlIGZsYWdnZWQg d2hlbiBmbGFnZ2luZyB0aGUgJnF1b3Q7Y2FsbGluZyBwYXJ0eSZxdW90Oz8mbmJzcDsgSSBhc3N1 bWUgbm8gc2luY2UgcG90ZW50aWFsbHkgaW5ub2NlbnQgYnlzdGFuZGVyLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2hvdWxkIHRoZSBjYWxsIHRyYW5zZmVycmlu ZyBwYXJ0eSBiZSBmbGFnZ2VkIHdoZW4gZmxhZ2dpbmcgdGhlICZxdW90O2NhbGxpbmcgcGFydHkm cXVvdDs/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3Ms PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPkJyZXR0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+IEhlbm5pbmcgU2NodWx6cmlubmUgW21h aWx0bzo8YSBocmVmPSJtYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Ij5IZW5uaW5n LlNjaHVsenJpbm5lQGZjYy5nb3Y8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFN1bmRheSwgSmFu dWFyeSAxNSwgMjAxNyAzOjQ5IFBNPGJyPg0KPGI+VG86PC9iPiBCcmV0dCBUYXRlOyA8YSBocmVm PSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzaXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUt c3RhdHVzLXVud2FudGVkLTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0iZGl2 dGFnZGVmYXVsdHdyYXBwZXIiPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Ib3cgbGlr ZWx5IGlzIGFueSBvZiB0aGlzIGdvaW5nIHRvIGhhcHBlbiBmb3IgdW53YW50ZWQgcm9ib2NhbGxz PyBGb3IgZmlndXJlIDQsIHRoZSBvbmUgc2NlbmFyaW8gSSBjYW4gdGhpbmsgb2YgaXMgdGhlICZx dW90O2V2aWwmcXVvdDsgY29udHJvbGxlciBsZXZlcmFnaW5nIGEgc2VydmljZSBBIHRvIGNhbGwg QiwgYW5kIEIgNjY2J2luZyB0aGUgY2FsbCBvciBzZW5kaW5nIGEgQllFIHdpdGggUmVhc29uKDY2 NikuDQogQnV0IHRoYXQgd291bGQgc2VlbSB0byBiZSBwcmV0dHkgc3RhbmRhcmQsIGV2ZW4gaWYg dGhlIGZpbmFsIHJlY2lwaWVudCBvZiB0aGUgNjY2IG9yIEJZRSBpcyBBICh3aG8gaXMgbGlrZWx5 IHRvIGlnbm9yZSBpdCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPkkgdGhpbmsgaXQgd291bGQgaGVscCBpZiB5b3UgY291bGQgaWRlbnRpZnkg dGhlIHJvbGVzIG9mIHRoZSB0aGlyZCBwYXJ0aWVzIGFuZCBzZWUgaWYgdGhhdCBjYXVzZXMgdGhl IHJlY2lwaWVudCBvZiB0aGUgdW53YW50ZWQgY2FsbCB0byBkbyBzb21ldGhpbmcgdGhhdCdzIGhh cm1mdWwgdG8gaW5ub2NlbnQgYnlzdGFuZGVycy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SGVubmluZzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4 dC1hbGlnbjpjZW50ZXIiPg0KPGhyIHNpemU9IjIiIHdpZHRoPSI5OCUiIGFsaWduPSJjZW50ZXIi Pg0KPC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+IEJyZXR0IFRhdGUgJmx0OzxhIGhyZWY9Im1haWx0bzpicmV0 dEBicm9hZHNvZnQuY29tIj5icmV0dEBicm9hZHNvZnQuY29tPC9hPiZndDs8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDEzLCAyMDE3IDM6NDg6NTggUE08YnI+DQo8Yj5Ubzo8L2I+ IEhlbm5pbmcgU2NodWx6cmlubmU7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5z aXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NpcGNvcmVdIENv bW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8L3NwYW4+DQo8 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Q29uY2VybmluZyBjYWxsaW5nIHBhcnR5IHNlbmRpbmcgQllFIHdp dGggNjY2LCBJIGp1c3QgdGhvdWdodCB0aGF0IGl0IHBvdGVudGlhbGx5IHNob3VsZCBiZSBkaXNj dXNzZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ib3dldmVy LCBSRkMgMzcyNSBmaWd1cmVzIDQgYW5kIGZpZ3VyZSA3IGRvIHNob3cgaG93IGEg4oCcY2FsbGlu ZyBwYXJ0eeKAnSBtaWdodCBnZXQgcmVwbGFjZWQgYnkgYSDigJxjYWxsZWQgcGFydHnigJ0uJm5i c3A7IFRodXMgaWYgdGhlIGNvbnRyb2xsZXIgZG9lc27igJl0IHN0cmlwIHRoZSBSZWFzb24NCiB3 aGlsZSByZWxheWluZyB0aGUgQllFLCBpdCBkZWZpbml0ZWx5IHdvdWxkIGJlIHBvc3NpYmxlIHNp bmNlIGJvdGggYXJlIGNhbGxlZCBwYXJ0aWVzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SWYgdGhlIOKAnGNhbGxpbmcgcGFydHnigJ0gZ2V0cyByZXBsYWNlZCBi ZWZvcmUg4oCcY2FsbGVkIHBhcnR54oCdIHNlbmRzIEJZRSB3aXRoIDY2Niwgd2hvIHNob3VsZCBi ZSBmbGFnZ2VkOiAxKSBjYWxsaW5nIHBhcnR5IGluZGljYXRlZCB3aXRoaW4gb3JpZ2luYWwgSU5W SVRFIG9yIDIpDQogbmV3ZXN0IGNvbm5lY3RlZCBwYXJ0eT88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnJldHQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj4gSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpIZW5uaW5n LlNjaHVsenJpbm5lQGZjYy5nb3YiPkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMTIsIDIwMTcgMzozMSBQTTxicj4N CjxiPlRvOjwvYj4gQnJldHQgVGF0ZTsgPGEgaHJlZj0ibWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBv cmFuZ2UuY29tIj5tYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvYT47DQo8YSBocmVmPSJtYWls dG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0 OjwvYj4gUkU6IFtzaXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVz LXVud2FudGVkLTAxPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPknigJltIGFmcmFpZCBJIGRvbuKAmXQg cXVpdGUgZm9sbG93IHdoYXQgdGV4dCB5b3UgYXJlIHN1Z2dlc3RpbmcgYW5kIEnigJltIHN1c3Bl Y3Rpbmcgd2XigJlyZSB3ZWxsIGludG8gdGhlIHdlZWRzIGF0IHRoaXMgcG9pbnQuIE15IGdlbmVy YWwgaW5jbGluYXRpb24gaXMgdG8gb25seSBzdGF0ZQ0KIHRoaW5ncyB3aGVyZSA2NjYgZGlmZmVy cyBmcm9tIDZ4eCBoYW5kbGluZywgcmF0aGVyIHRoYW4gdHJ5IHRvIGNhcHR1cmUgYWxsIHBvc3Np YmxlIHN0YXR1cyBjb2RlIGlzc3VlcyB0aGF0IGFyZSBnZW5lcmljIHRvIChtb3N0KSA2eHggY29k ZXMuIFRoaXMgYXZvaWRzIGNyZWF0aW5nIGluYWR2ZXJ0ZW50IGNvbnRyYWRpY3Rpb25zIG9yIHRo ZSBuZWVkIHRvIHVwZGF0ZSB0aGUgZG9jdW1lbnQgc2hvdWxkIHRoZXJlIGJlIGNoYW5nZXMgaW4g dGhlIGdlbmVyaWMNCiBoYW5kbGluZy4gSW4gb3RoZXIgd29yZHMsIDY2NiBzaG91bGQgYmUgdHJl YXRlZCBsaWtlIDZ4eCB1bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkLjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGh1cywgY2FuIHlvdSBwcm92aWRlIHN1Z2dlc3RlZCB0 ZXh0Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0gbm90 IHN1cmUgd2h5IHRoZSBjYWxsaW5nIHBhcnR5IHdvdWxkIGluZGljYXRlIDY2Ni4gQWZ0ZXIgcmVj ZWl2aW5nIGEgcmUtSU5WSVRFPyBJbiByZXNwb25zZSB0byBhIEJZRT8gSSBhZG1pdCB0aGF0IEkg bGFjayB0aGUgaW1hZ2luYXRpb24gYXMgdG8gaG93IHRoaXMgd291bGQNCiBvY2N1ciBhbmQgd2h5 IHRoaXMgd291bGQgY2F1c2UgYW55dGhpbmcgb3RoZXIgdGhhbiB3aGF0IHdvdWxkIGhhcHBlbiBm b3IgYSBnZW5lcmljIDZ4eCByZXNwb25zZSBpbiB0aG9zZSBjaXJjdW1zdGFuY2VzLjwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U3RyZXRjaGluZyB0aGUgaW1hZ2lu YXRpb24sIEkgY291bGQgaW1hZ2luZSB0aGUgY2FzZSB3aGVyZSBJ4oCZbSBtaXNsZWQgaW50byBk aWFsaW5nIGEgbnVtYmVyIChlLmcuLCBhcyBwYXJ0IG9mIGEgc3BhbSBlbWFpbCkgdGhhdCB0dXJu cyBvdXQgdG8gYmUgYSByb2JvdCBwZWRkbGluZw0KIHRpbWUgc2hhcmVzLiBJIGNvdWxkIHNlbmQg YSBCWUUsIHdpdGggYSA2NjYgUmVhc29uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SXMgdGhhdCB0aGUgY2FzZSB5b3UgaGF2ZSBpbiBtaW5kPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVubmluZzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJldHQgVGF0ZSBbPC9zcGFuPjxhIGhyZWY9Im1h aWx0bzpicmV0dEBicm9hZHNvZnQuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPm1haWx0bzpicmV0dEBi cm9hZHNvZnQuY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6 PC9iPiBGcmlkYXksIEphbnVhcnkgMDYsIDIwMTcgMTI6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IDwv c3Bhbj48YSBocmVmPSJtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+OyBIZW5uaW5nIFNjaHVsenJpbm5lICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOkhl bm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5IZW5uaW5nLlNjaHVs enJpbm5lQGZjYy5nb3Y8L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzsNCjwvc3Bhbj48 YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5zaXBjb3Jl QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53 YW50ZWQtMDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgcG90ZW50aWFsbHkgc2hvdWxkIGFsc28gZGlz Y3VzcyB0aGUgcG90ZW50aWFsIGZvciB0aGUgY29ubmVjdGVkIHBhcnR5IHRvIGNoYW5nZSBtaWQt ZGlhbG9nIDEpIHdpdGhvdXQgaXQgYmVpbmcgY29tbXVuaWNhdGVkIGFuZCAyKSB3aXRoIGl0IGJl aW5nIGNvbW11bmljYXRlDQogYnkgUkZDIDQ5MTYsIFJGQyA1ODc2LCBldCBjZXRlcmEuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Gcm9tIGEgc2VjdXJpdHkgY29u c2lkZXJhdGlvbnMgcGVyc3BlY3RpdmUsIHRoZSB3cm9uZyBwYXJ0eSBtaWdodCBiZSBmbGFnZ2Vk IGJ5IHRoZSA2NjYgd2hlbiB0aGUgY29ubmVjdGVkIHBhcnR5IGNoYW5nZXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgZHJhZnQgc2hvdWxkIHBvdGVudGlh bGx5IGFsc28gZGlzY3VzcyB0aGUgcG90ZW50aWFsIGZvciBjYWxsaW5nIHBhcnR5IGluZGljYXRp bmcgNjY2LiZuYnNwOyBPdGhlciB0aGFuIGEgd2F5IHRvIGF0dGFjayBzb21lb25lLCBJ4oCZbSBu b3Qgc3VyZSBpZiBhcmUgYW55IDNQQ0MsIHRyYW5zZmVyLA0KIG9yIG90aGVyIHNlcnZpY2Ugc2l0 dWF0aW9ucyB3aGVyZSBpdCBtaWdodCBhY3R1YWxseSBiZSBhcHByb3ByaWF0ZS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm1hcmlhbm5l Lm1vaGFsaUBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+bWFyaWFubmUubW9oYWxpQG9yYW5n ZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gW21haWx0bzo8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+bWFyaWFu bmUubW9oYWxpQG9yYW5nZS5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5dDQo8YnI+DQo8 Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDA2LCAyMDE3IDEwOjI4IEFNPGJyPg0KPGI+VG86 PC9iPiBIZW5uaW5nIFNjaHVsenJpbm5lOyBBc3ZlcmVuLCBUb2xnYTsgQnJldHQgVGF0ZTsgPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+c2lw Y29yZUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMt dW53YW50ZWQtMDE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UbyByZWZsZWN0IHRoZSBxdWVzdGlvbiBvZiB0aGUgaW50 ZXJwcmV0YXRpb24gb2YgdGhlIDY2NiByZXNwb25zZSBpbnRlcnByZXRhdGlvbiB3aGVuIHRoZSBj YWxsZXIgaGFzIHNldmVyYWwgaWRlbnRpdGllcyB1c2VkIGZvciB0aGlzIGNhbGwgKGllLiBGcm9t IGFuZCBQLUFzc2VydGVkLUlkZW50aXR5IGFyZSBkaWZmZXJlbnQpIG9yIGNhbGwgZm9yd2FyZGlu Zy9jYWxsDQogdHJhbnNmZXIgdXNlIGNhc2VzIGZvciB3aGljaCBpdCBoYXMgdG8gYmUgZGlzY3Vz c2VkIHdoaWNoIHBhcnR5IHNob3VsZCBiZSBjb25zaWRlcmVkIGhhcyBhIGZyYXVkdWxlbnQgKGll LiB0aGUgY2FsbGluZyBwYXJ0eSBvciB0aGUgZGl2ZXJ0aW5nIHBhcnR5IG9yIGJvdGggPykgOyBJ IHByb3Bvc2UgdG8gYWRkIHRoZSBmb2xsb3dpbmcgdGV4dDo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhp cyBkb2N1bWVudCBkZWZpbmVzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIGEgY2FsbGVkIHBhcnR5IGNh biByZWplY3QgYW4gdW53YW50ZWQgY2FsbCB3aXRob3V0IGNvbnNpZGVyYXRpb24gb2YgdGhlIGNh bGxpbmcgcGFydHkgaWRlbnRpZmljYXRpb24gdGhhdCByZW1haW4gdG8gdGhlIHNlcnZpY2UgcHJv dmlkZXIgcG9saWN5LiBJbmRlZWQsIHRoZSBjYWxsaW5nDQogcGFydHkgaWRlbnRpdHkgbWF5IGJl IHJlZmxlY3RlZCBpbiBkaWZmZXJlbnQgd2F5IGZvciBhIGRpcmVjdCBjYWxsIG9yIGFmdGVyIGEg ZGl2ZXJ0aW5nIHNlcnZpY2UgaW4gUC1Bc3NlcnRlZC1JZGVudGl0eSwgRnJvbSwgSGlzdG9yeS1J bmZvIG9yIGFueSBjb25jdXJyZW50IGhlYWRlciBmaWVsZCB0aGF0IGNhbiBiZSBwcmVzZW50IGF0 IHRoZSBzYW1lIHRpbWUgaW4gYSBTSVAgbWVzc2FnZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQiPlRob3NlIHF1ZXN0aW9ucyBhcmUgcmVhbCBpc3N1ZXMgZm9yIG9w ZXJhdG9ycyBhbmQgaW1wbGVtZW50b3JzIGFuZCB0aGV5IGFyZSBhIHdlYWtuZXNzIHRoYXQgZnJh dWR1bGVudCBjYWxsZXJzIGNvdWxkIHVzZSB0byBieXBhc3MgdGhlIG1lY2hhbmlzbS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkJSLDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 Ij5NYXJpYW5uZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxMC41cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CY1PR09MB0634D40E5EFC42E15861DE73EA7C0CY1PR09MB0634namp_-- From nobody Tue Jan 17 19:46:05 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D28128B37 for ; Tue, 17 Jan 2017 19:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tN2WctPCCf6P for ; Tue, 17 Jan 2017 19:46:02 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72D11127058 for ; Tue, 17 Jan 2017 19:46:02 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x75so709561vke.2 for ; Tue, 17 Jan 2017 19:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EqgqaPeP2G///cEPu7RK0K08Rm2jF7EEcZMv4x32v+w=; b=U6wE6xHH526J/FDPqoG69eceQSKl7PqUyeaHt5rl2VUj8NonZ5msiSC7jSl1rSOtQ6 /P7Ax94MzSMTNNCY9qNxdOfPEuzIu5tMgN7bd67q55mciLHWByA266Xh15AgXiZ30+eO JzQlNvJNQmoCAp7rjbyjyi9TtmUIC9CTbvFfF6xfkGHJdDKiMypxmXHkle6yTxmL94H5 8TG4ZKUmLTcJTMHAS/oezeex5hg2KRAwE3iI7KHwiHG2zMpIxuFHPYIJ8v3ZRPq+u77P HoWngUSNvS4mcCoCtDEd4XaBJVKyP73r+KoJzoK6VT959klzd0OHUfok8A6oPEnxMy49 +HuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EqgqaPeP2G///cEPu7RK0K08Rm2jF7EEcZMv4x32v+w=; b=Cr8M4EBMiRDsp0J1aXQWK8hbUlsW+4Zu8GgrZmrAPDp7t6JXDK+tqW37bbblNET3Bf hb3jL0JOnGdn9ss6HcqZhbNM/bDpSsE28Pjg9n2uDdpFg3OdsrHWo7pNXKbWTxJkKWlX KOL8u1uZm/fh6sokeJbdcJLzjATwbksg1k52anBoISVeCV9/aLQCZ96ArbZNiJ/SsuF0 Dl/ph56WCsxzax5NseXkC9YPsRwvLFqT0eC1u4AQ/g0gD5KtMYVCDk6FV782JvX1K1fx QNSnw3nEOCXkgVvNDs2vDtgLNObqd7nHfrxCVdRQ+FBzoC9etkpHd8fdsdVIF0hi3cB0 SEgw== X-Gm-Message-State: AIkVDXLc577Evu+C7kHSzfC6NL3lJ8og1d3INDnlggNkTWHefJ96mRV+Ka7Cs4MIsnmkjoFGXsKalTadWO6Taw== X-Received: by 10.31.92.9 with SMTP id q9mr643993vkb.88.1484711161539; Tue, 17 Jan 2017 19:46:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Tue, 17 Jan 2017 19:46:01 -0800 (PST) In-Reply-To: <87o9zatqvb.fsf@hobgoblin.ariadne.com> References: <87o9zatqvb.fsf@hobgoblin.ariadne.com> From: Rifaat Shekh-Yusef Date: Tue, 17 Jan 2017 22:46:01 -0500 Message-ID: To: "Dale R. Worley" Content-Type: multipart/alternative; boundary=001a114e170260b370054656414c Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:46:04 -0000 --001a114e170260b370054656414c Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 7:41 PM, Dale R. Worley wrote: > Rifaat Shekh-Yusef writes: > >> As a matter of exposition, you say "This section does NOT maintain > >> backward compatibility with RFC 2069." But of course as a consequence > >> of that, it isn't compatible with RFC 3261 either. > > > > The statement you quoted was in the previous version of the document, but > > not in v05. > > Hmmm, for some reason I wasn't looking at the 05 version. > > >> I'd like to see a description of how the draft's section 2.6 compares > >> with the existing SIP authentication scheme -- is this just adding the > >> new algorithms and making qop mandatory? > > > > Yes, the idea is that this draft will add the SHA2 algorithms as the > > recommended algorithms, and only keep the MD5 for backward compatibility. > > What I meant was a positive statement in the draft of what the > differences are, so the reader doesn't have to correlate section 2.6 > with the previous RFCs. > I see. ok. > > "Olle E. Johansson" writes: > > I feel we need to have some writing about how to migrate. There is a > > significant risk of downgrade attacks if we have both mechanisms > > running, like you get two challenges or one challenge with two > > algorithms (if that's possible). > > Certainly we need to worry about avoiding downgrade attacks, and this > should be included in the security considerations. Agree. > (I can imagine > techniques to prevent it, such as when digest-protecting a message, > including in the protected information a list of ciphers that the sender > is willing to support, so that the receiver can verify that no better > cipher that it offered to use is also supported by the sender.) > > I am not clear on this comment. Can you please elaborate on what you mean by this? > Forking in the general case ... gets ugly. I'm not sure how much it > matters in practice. Yeah, I agree. We need to simplify this and avoid the complexity that comes with forking. Regards, Rifaat > But if one fork returns a 401 for domain > example.com that demands use of MD-5, and another fork returns a 401 for > domain example.com with two Proxy-Authenticate headers that allow either > MD-5 or SHA-256, the combined 401 returned to the UAC contains 3 > Proxy-Authenticate headers for one domain, two of which use MD-5 and one > SHA-256. Is there any way to prescribe behavior for the UAC that will > cause successful operation? > > Dale > --001a114e170260b370054656414c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 7:41 PM, Dale R. Worley <<= a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
Rif= aat Shekh-Yusef <rifaat.ietf@gm= ail.com> writes:
>> As a matter of exposition, you say "This section does NOT mai= ntain
>> backward compatibility with RFC 2069."=C2=A0 But of course as= a consequence
>> of that, it isn't compatible with RFC 3261 either.
>
> The statement you quoted was in the previous version of the document, = but
> not in v05.

Hmmm, for some reason I wasn't looking at the 05 version.

>> I'd like to see a description of how the draft's section 2= .6 compares
>> with the existing SIP authentication scheme -- is this just adding= the
>> new algorithms and making qop mandatory?
>
> Yes, the idea is that this draft will add the SHA2 algorithms as the > recommended algorithms, and only keep the MD5 for backward compatibili= ty.

What I meant was a positive statement in the draft of what the
differences are, so the reader doesn't have to correlate section 2.6 with the previous RFCs.

I see. ok.

=C2=A0

"Olle E. Johansson" <oej@edv= ina.net> writes:
> I feel we need to have some writing about how to migrate. There is a > significant risk of downgrade attacks if we have both mechanisms
> running, like you get two challenges or one challenge with two
> algorithms (if that's possible).

Certainly we need to worry about avoiding downgrade attacks, and thi= s
should be included in the security considerations.=C2=A0
=
Agree.

=C2=A0
(I can imagine
techniques to prevent it, such as when digest-protecting a message,
including in the protected information a list of ciphers that the sender is willing to support, so that the receiver can verify that no better
cipher that it offered to use is also supported by the sender.)

I am not clear on this comment. Can you please elabor= ate on what you mean by this?

=C2=A0
Forking in the general case ... gets ugly.=C2=A0 I'm not sure how much = it
matters in practice.=C2=A0

Yeah, I agree.<= /div>
We need to simplify this and avoid the complexity that comes with= forking.

Regards,
=C2=A0Rifaat


=C2=A0
= But if one fork returns a 401 for domain
example= .com that demands use of MD-5, and another fork returns a 401 for
domain = example.com with two Proxy-Authenticate headers that allow either
MD-5 or SHA-256, the combined 401 returned to the UAC contains 3
Proxy-Authenticate headers for one domain, two of which use MD-5 and one SHA-256.=C2=A0 Is there any way to prescribe behavior for the UAC that will=
cause successful operation?

Dale

--001a114e170260b370054656414c-- From nobody Tue Jan 17 19:52:47 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071B81294B7 for ; Tue, 17 Jan 2017 19:52:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQpmN0ghjvi0 for ; Tue, 17 Jan 2017 19:52:44 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64F931294F9 for ; Tue, 17 Jan 2017 19:52:44 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x75so773036vke.2 for ; Tue, 17 Jan 2017 19:52:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sLNl5aze9M4QcwOefmLv66xnuIFu+7GzFhigg6F/ycs=; b=F36GoxQRIsqaRPQlSpfxwvhFmpfkiCGizlRnGyvKw8plsPPyGRtECspYD4sVAettY3 V8bNOXT+qcFswbcXELNWs105P5ECuWttVlD8ERtKjJwXMCIMkDyJnfIYkxh+5tLNXivG xwu29XRBu4i1EW57ZkCBrgLmi+ztXvPFlT2W9nwv0BMiDjaaycSc4dCAA9Q69c84dUDf dfvDewxeX+dHwTAz7YHJWCwjEAFq2yykGab6gkiODpPuR3w9hbPKoXiE5K3dJtwWsOA9 rAENj468+TkDpm3ZWfcOHj/IYE11Fbgh8Z7JE5IxBCTPcv6aSTZ4mnS5O6Rrzzz9qeVe LmSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sLNl5aze9M4QcwOefmLv66xnuIFu+7GzFhigg6F/ycs=; b=YH8lvF8wMqIIQZ/uwKQKkKnV5fSiORwCoDekPvNIiI2j5dN6GfoJ5abw0ySc8ArTkd 5ER++JiyStY7JPzAh4a/So1MUSj350V75uCFius4/RloS1QXJ7eBAfjR6EWaf1a7ZPY3 TAQD6ye7DXCY99G/KsRdIJuuC0wGqUPw/goO6ePaAo8rAmqe12q70HbcNupk6uMumeDV g+4jafDZ3eGZAXaSapA045R/sgjKRLo2R1pmbUP8nqGg4iW8DWc1fhaqcBxq5SRglu8C jiHXIBRpA6L7XUi39Jdr/9Uvvu3SkHIMz1imkJzQ4fVSVr66f69P0BdeM/dv1wM0jCk2 LehA== X-Gm-Message-State: AIkVDXL9gTR79Pp9hs8jKDBS1ziMzxMIcLE+e8Q2SYPC7El1XNDbN3MV5zziY/vQE4fzmZKIlz3THXxlVgeygg== X-Received: by 10.31.74.197 with SMTP id x188mr523046vka.120.1484711563505; Tue, 17 Jan 2017 19:52:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.33.169 with HTTP; Tue, 17 Jan 2017 19:52:43 -0800 (PST) In-Reply-To: References: <87lgug6xds.fsf@hobgoblin.ariadne.com> <0F8841CC-1F08-463E-8C61-4AB8FBF08A4D@edvina.net> From: Rifaat Shekh-Yusef Date: Tue, 17 Jan 2017 22:52:43 -0500 Message-ID: To: "Olle E. Johansson" Content-Type: multipart/alternative; boundary=001a114da7e456358e05465659e0 Archived-At: Cc: "Dale R. Worley" , "sipcore@ietf.org" Subject: Re: [sipcore] SIP Digest - SHA2 Support X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 03:52:47 -0000 --001a114da7e456358e05465659e0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable That is what the Security Consideration section for; or are you looking for something beyond that? Regards, Rifaat On Sat, Jan 14, 2017 at 3:09 AM, Olle E. Johansson wrote: > > On 13 Jan 2017, at 18:49, Rifaat Shekh-Yusef > wrote: > > Thanks Olle, > > This document gives the operator the tools to migrate, but *migration > policy *is probably be out of scope this document. > > Agree that policy is out of scope, but advice to implementors should be i= n > scope so we do not cause > security flaws in software. > > /O > > > > What do others think? > > Regards, > Rifaat > > > > On Fri, Jan 13, 2017 at 3:29 AM, Olle E. Johansson wrote= : > >> Rifaat, >> THank you for your work on this and coming back. >> >> I feel we need to have some writing about how to migrate. There is a >> significant risk of downgrade attacks >> if we have both mechanisms running, like you get two challenges or one >> challenge with two algorithms >> (if that=E2=80=99s possible). The web has a simpler upgrade path, given = the small >> amount of browsers that operate >> a majority of the requests. We have many years of legacy software that >> propably will not upgrade unless customers >> require it. And it will take some time to get new firmware out there wit= h >> support for this unless there=E2=80=99s significant >> customer demand. >> >> We definitiely need to get this done and move SIPconnect 2.x to require >> this on public networks and >> forbid MD5 in those situations as a first step. Hopefully that can help >> some customers to demand the right thing. >> >> How do an operator of a service upgrade to SHA2? Do we have to have a >> cut-off date and stop >> accepting MD5, do we migrate somehow or do we mark =E2=80=9Cnew=E2=80=9D= phones for ONLY >> SHA2 and old clients >> for MD5 and SHA2 in some authentication service database? >> >> Implementors need to know how to handle this and I haven=E2=80=99t figur= ed out >> any good solution in my own >> head since we started this discussion five years ago or so=E2=80=A6. >> >> If we can solve this process now, we=E2=80=99re in better shape when SHA= 2 becomes >> the algorithm that no one >> wants to use any more. >> >> /O >> >> >> >> >> On 12 Jan 2017, at 19:07, Rifaat Shekh-Yusef >> wrote: >> >> Thanks Dale! >> >> Please, see my reply inline... >> >> Regards, >> Rifaat >> >> >> On Thu, Jan 12, 2017 at 11:44 AM, Dale R. Worley >> wrote: >> >>> Rifaat Shekh-Yusef writes: >>> > RFC7617 updated the *HTTP Digest* mechanism and added support for >>> *SHA2* to >>> > replace the MD5 algorithm. >>> > >>> > I am trying to revolve this old draft that does the same for SIP: >>> > https://datatracker.ietf.org/doc/draft-yusef-sipcore-digest-scheme/ >>> >>> It makes sense to do this, of course, as MD-5 is thoroughly obsolete. >>> >>> As a matter of exposition, you say "This section does NOT maintain >>> backward compatibility with RFC 2069." But of course as a consequence >>> of that, it isn't compatible with RFC 3261 either. >> >> >> The statement you quoted was in the previous version of the document, bu= t >> not in v05. >> If I remember correctly, we discussed that and during one of the IETF >> meetings and it was deemed unnecessary to maintain that. >> We did the same with the new HTTP Digest mechanism defined in RFC7616. >> >> Is that a problem for SIP? >> >> >> >> >> >>> I'd like to see a description of how the draft's section 2.6 compares >>> with the existing SIP authentication scheme -- is this just adding the >>> new algorithms and making qop mandatory? >>> >>> Yes, the idea is that this draft will add the SHA2 algorithms as the >> recommended algorithms, and only keep the MD5 for backward compatibility= . >> >> Regards, >> Rifaat >> >> >> >> >>> Dale >>> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > > --001a114da7e456358e05465659e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That is what the Security Consideration section for; or ar= e you looking for something beyond that?

Regards,
<= div>=C2=A0Rifaat


<= div class=3D"gmail_quote">On Sat, Jan 14, 2017 at 3:09 AM, Olle E. Johansso= n <oej@edvina.net> wrote:

On 13 Jan 2017, at 18:49, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com&g= t; wrote:

=
Thanks Olle,

This document gives t= he operator the tools to migrate, but migration policy is probably b= e out of scope this document.
Agree th= at policy is out of scope, but advice to implementors should be in scope so= we do not cause
security flaws in software.

/O


<= br>
What do others think?

Regards,
=
=C2=A0Rifaat



On Fri, Jan 13, 2017 at 3:29 AM, = Olle E. Johansson <oej@edvina.net> wrote:
Rifaat,
THank you for= your work on this and coming back.

I feel we need= to have some writing about how to migrate. There is a significant risk of = downgrade attacks
if we have both mechanisms running, like you ge= t two challenges or one challenge with two algorithms
(if that=E2= =80=99s possible). The web has a simpler upgrade path, given the small amou= nt of browsers that operate
a majority of the requests. We have m= any years of legacy software that propably will not upgrade unless customer= s
require it. And it will take some time to get new firmware out = there with support for this unless there=E2=80=99s significant
cu= stomer demand.

We definitiely need to get this don= e and move SIPconnect 2.x to require this on public networks and
= forbid MD5 in those situations as a first step. Hopefully that can help som= e customers to demand the right thing.

How do an o= perator of a service upgrade to SHA2? Do we have to have a cut-off date and= stop
accepting MD5, do we migrate somehow or do we mark =E2=80= =9Cnew=E2=80=9D phones for ONLY SHA2 and old clients
for MD5 and = SHA2 in some authentication service database?

Impl= ementors need to know how to handle this and I haven=E2=80=99t figured out = any good solution in my own
head since we started this discussion= five years ago or so=E2=80=A6.

If we can solve th= is process now, we=E2=80=99re in better shape when SHA2 becomes the algorit= hm that no one
wants to use any more.

/O=


=C2=A0
On 12 Jan 2017, at 1= 9:07, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> wrote:

Thanks Dale!=

Please, see my reply inline...

Regards,
=C2=A0Rifaat


On Thu, Jan 12, 2017 at 11:44 AM, Dale = R. Worley <worley@ariadne.com> wrote:
Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> writes:
> RFC7617 updated the *HTTP Digest* mechanism and added support for *SHA= 2* to
> replace the MD5 algorithm.
>
> I am trying to revolve this old draft that does the same for SIP:
> https://datatracker.ietf.org= /doc/draft-yusef-sipcore-digest-scheme/

It makes sense to do this, of course, as MD-5 is thoroughly obsolete= .

As a matter of exposition, you say "This section does NOT maintain
backward compatibility with RFC 2069."=C2=A0 But of course as a conseq= uence
of that, it isn't compatible with RFC 3261 either.
The statement you quoted was in the previous version of the doc= ument, but not in v05.
If I remember correctly, we discussed that= and during one of the IETF meetings and it was deemed unnecessary to maint= ain that.
We did the same with the new HTTP Digest mechanism defi= ned in RFC7616.

Is that a problem for SIP?


=C2=A0

I'd like to see a description of how the draft's section 2.6 compar= es
with the existing SIP authentication scheme -- is this just adding the
new algorithms and making qop mandatory?

Yes, the idea is that this= draft will add the SHA2 algorithms as the recommended algorithms, and only= keep the MD5 for backward compatibility.

Regards,=
=C2=A0Rifaat


=C2=A0
Dale

_______________________________________________
sipcore mailing lis= t
sipcore@ietf.org=
https://www.ietf.org/mailman/listinfo/sipcore


_________________________________= ______________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore<= br>

_______________________________________________
sipcore mailing lis= t
sipcore@ietf.org=
https://www.ietf.org/mailman/listinfo/sipcore


--001a114da7e456358e05465659e0-- From nobody Wed Jan 18 02:14:09 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9154A129466 for ; Wed, 18 Jan 2017 02:14:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N42KBnswvlKq for ; Wed, 18 Jan 2017 02:14:05 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD8A3128B44 for ; Wed, 18 Jan 2017 02:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N2dymK9hB0v3sXng9uExOYT5S1/aah9N24pkHCWdMGY=; b=ZCZKHoflWt5P6750CK49OmlpXfr3x9WI+IW3dnz2PKj3Utij5Kc/Dc+ZXZZUDFph359aAsL1g6wYpPOMtlYpnOSNgyJJ3ar30U0QSW5RjSOO6JdcKOMBYp/X+WX6geF8b9ePPZmh0/i8ce3EdsC3x9db/ylAStd+ti4lExKDyTs= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0087.outbound.protection.outlook.com [207.46.163.87]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-139-N32Pl9dQPEeNBS0j10D47w-1; Wed, 18 Jan 2017 05:14:01 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 18 Jan 2017 10:13:57 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0860.012; Wed, 18 Jan 2017 10:13:57 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbeklUIfCp4Q0p061YwjEbBL+X6E6BuYAgAQB1vA= Date: Wed, 18 Jan 2017 10:13:57 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com>, <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: c279b6a9-b3f8-46a9-eb28-08d43f8ab704 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:/zZiseZIsJze3282/wrv5o8QixANnXhKzChzby4Mgm7OZQXlAyZXQGIZEGBN5Wjgfxdgv+M5I+8JALrK+t8yq1e4lPQRN2EPj373cXjWSxwaJ3WXTutUBKpNrm1jfC/v2h+PrE/d61HElnhYGjLzqK70vLshn/ZlKRcRoUO9jFk4kW5piT8pMqmjjwpPF6OKrT2dZhwLNpOwie7wnFLsflmIxs1OBsPf7bVKnmmDdZw164YpBxMyHqjuChs4MT2ngjbgA07umnR1c34gFUT/7j9X39w9KZDgDdwsGN6+V3xmSPr3rLCdjkx8naP3+K7+785Ew66RRfNsU5hNQHCnprAHsuq/+JEwss/NcYxAIe5LNwI661PH1P9DTyB//7tfgd9iou8ln58kU4uMF+6JC8y7Pi4oyMzMmuokk8RgiJTa22payBr6C6aSyzoKTaBffQd4bE/9w8PJAjV3n0vzgA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(68173958961439)(10436049006162)(21748063052155)(211171220733660); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(107886002)(7906003)(101416001)(50986999)(2906002)(54356999)(7736002)(189998001)(68736007)(2950100002)(575784001)(74316002)(76176999)(5001770100001)(122556002)(8936002)(3280700002)(8676002)(230783001)(3660700001)(81156014)(81166006)(97736004)(7696004)(236005)(8666007)(55016002)(54896002)(102836003)(6116002)(3846002)(790700001)(25786008)(2900100001)(33656002)(106116001)(38730400001)(66066001)(9686003)(77096006)(86362001)(19609705001)(106356001)(229853002)(6436002)(5660300001)(99286003)(606005)(53936002)(105586002)(92566002)(6506006)(6306002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 10:13:57.1928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: N32Pl9dQPEeNBS0j10D47w-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB235097AEC8E860C942198DA8B27F0SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 10:14:07 -0000 --_000_SN2PR03MB235097AEC8E860C942198DA8B27F0SN2PR03MB2350namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable How likely it is that that Bob's UE generates 180 but did not "ring" before= such an evil CANCEL is received? The entity making use of Reason header, e .g. an Application Server managin= g devices at a call center, can use Contact/Via headers to determine the or= igin of CANCEL (well, unless there is a B2BUA in-between; but then just as = a note: nowadays it is not uncommon that some B2BUAs can relay Via headers = between two legs). Overall, I don't think there is something here which should cause us to los= e sleep. Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Sunday, January 15, 2017 3:53 PM To: Paul Kyzivat ; SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Good point. Maybe the devices should keep a separate "bad call" list, simil= ar to the spam folder. However, that reporting is probably not going to hel= p Bob a whole lot - assuming Bob doesn't know Alice, what would it do with = the information? As you state, it's going to be very hard to distinguish le= gitimate upstream forking from malicious probing. ________________________________ From: sipcore > o= n behalf of Paul Kyzivat > Sent: Friday, January 13, 2017 5:05:05 PM To: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt While reviewing this version I got to thinking about the use of Reason: 666 in CANCEL. This could conceivably be abused: - Alice (bad actor) sends INVITE to Bob - Bob sends 180 back to Alice - Alice sends CANCEL with Reason 666 This allows Alice to probe for the presence of a device at the target address, while possibly preventing the attempt from being reported to the callee. (This is behavior I see almost every day. While annoying, I'd rather have the opportunity to know it happened.) The only reasonable work-around I see for it is for the proxy servicing Bob's AoR to strip the incoming reason code. That would probably be an ok thing to do in most cases. But it won't do the right thing if there was forking upstream of that proxy. (E.g., in a case where the call was originally to a different number and was diverted with forking.) So this isn't a reason to disallow 666 in CANCEL, but it suggests that the processing of this in the UAS be carefully considered. Otherwise the new version looks good. Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV= 0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dx6C_h7TZev8v8TlNDPl-QNQCHH6Stdtps3jqfVd3AM= k&s=3DyO7o9XY0u_fyn91L6BM8dYU_xw_BtUuq4LBc6IdMT60&e=3D --_000_SN2PR03MB235097AEC8E860C942198DA8B27F0SN2PR03MB2350namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

How likely it is that that Bob’s UE generates= 180 but did not “ring” before such an evil CANCEL is received?=

 

The entity making use of Reason header, e .g. an Ap= plication Server managing devices at a call center, can use Contact/Via hea= ders to determine the origin of CANCEL (well, unless there is a B2BUA in-between; but then just as a note: nowadays it i= s not uncommon that some B2BUAs can relay Via headers between two legs).

 

Overall, I don’t think there is something her= e which should cause us to lose sleep.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Sunday, January 15, 2017 3:53 PM
To: Paul Kyzivat <paul.kyzivat@comcast.net>; SIPCORE <sipco= re@ietf.org>
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

 

G= ood point. Maybe the devices should keep a separate "bad call" li= st, similar to the spam folder. However, that reporting is probably not goi= ng to help Bob a whole lot - assuming Bob doesn't know Alice, what would it do with the information? As you state, it's going to = be very hard to distinguish legitimate upstream forking from malicious prob= ing.

From: sipcor= e <sipcore-bounces@ietf.org<= /a>> on behalf of Paul Kyzivat <= paul.kyzivat@comcast.net>
Sent: Friday, January 13, 2017 5:05:05 PM
To: SIPCORE
Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt

 

While reviewing thi= s version I got to thinking about the use of Reason:
666 in CANCEL. This could conceivably be abused:

- Alice (bad actor) sends INVITE to Bob
- Bob sends 180 back to Alice
- Alice sends CANCEL with Reason 666

This allows Alice to probe for the presence of a device at the target
address, while possibly preventing the attempt from being reported to
the callee.

(This is behavior I see almost every day. While annoying, I'd rather
have the opportunity to know it happened.)

The only reasonable work-around I see for it is for the proxy servicing Bob's AoR to strip the incoming reason code. That would probably be an
ok thing to do in most cases. But it won't do the right thing if there
was forking upstream of that proxy. (E.g., in a case where the call was originally to a different number and was diverted with forking.)

So this isn't a reason to disallow 666 in CANCEL, but it suggests that
the processing of this in the UAS be carefully considered.

Otherwise the new version looks good.

        Thanks,
        Paul


_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.= ietf.org_mailman_listinfo_sipcore&d=3DDgICAg&c=3Dy0h0omCe0jAUGr4gAQ= 02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3Dx6C_h7TZev= 8v8TlNDPl-QNQCHH6Stdtps3jqfVd3AMk&s=3DyO7o9XY0u_fyn91L6BM8dYU_xw_BtUuq4= LBc6IdMT60&e=3D

--_000_SN2PR03MB235097AEC8E860C942198DA8B27F0SN2PR03MB2350namp_-- From nobody Wed Jan 18 03:40:00 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2ADA1294AB for ; Wed, 18 Jan 2017 03:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbaOHJN1NDno for ; Wed, 18 Jan 2017 03:39:55 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D80912941E for ; Wed, 18 Jan 2017 03:39:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6WnB4No8DnmOh5bZuXzaYA1fbxvPpOgmhVCpU0bXKbw=; b=badsLlq1wd94OLwBebyKj0cTBdWhL2wE1zB4LHcWlB4WtAdeLFfajwDWDKwMjHviXUYZDp3/MCz9v+vf9Ee8XC3vwV19jJwoOMkNMnZHo34LbOyQu6PoZL3Akp0dsIT4CKbQtV4u7gNijd1XGMxGUeB+4BdRyeND5kWvzzi+hLE= Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0021.outbound.protection.outlook.com [207.46.163.21]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-45-3liygVWYNWKICJFGmqGnxQ-1; Wed, 18 Jan 2017 06:39:49 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Wed, 18 Jan 2017 11:39:47 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0860.012; Wed, 18 Jan 2017 11:39:47 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJt3jyCGYJ0jtsz5EmPEreSyl8iJgBkouCAAFvL4QAADY6hgAAZ7zEw Date: Wed, 18 Jan 2017 11:39:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 1174f93b-d842-4396-88bd-08d43f96b46e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2350; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2350; 7:/ovP9rXuvgSXyvPLPWs8vQHXwo/MD2KSVGcfk7idpQ/4TbkINl5ypFBLe3tkPAtSXi5lcJQ9o3h68RDXQFU9kcD7ASOuynZP0YyIU+AeXG6oO9IsSe7cFSiizvBPMEe4dJp6GdnrHqfZ6nK4uIMcQrLWXFURKxuoHccAR0mvpNqmFUdwmKESg/yNxxs34/dfR3PAWxD4mas1ZQFYk8k1EpsVzhHG3uwK0Poi6I4TPYH4d+DjuR0K3uSJYjMejeeEoSlI+FZ3Gk7C504bFNdRW5wOWwwsejWLOtB0hHZUU7fQSiualEnhWuu3q2vNf6GnTW3NsC2ZnwfRsvxngRS3eyffZOFmyI+OJznF4jKH7DY98oC5JUlB2MF3KWVZ0Y4dxjSZ9eXU/2xZNIWbKk3bUb7RdUdG3Ex7ZCnUGwC4wNhiWuGNHrJNPcw8TePiuA73MJIdXReoA0Rms4FOTlCbzg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148)(6047074); SRVR:SN2PR03MB2350; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2350; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(377454003)(199003)(93886004)(3660700001)(230783001)(33656002)(2501003)(86362001)(229853002)(74316002)(50986999)(81156014)(101416001)(66066001)(2950100002)(7736002)(81166006)(7696004)(68736007)(54356999)(8676002)(8936002)(106356001)(105586002)(2900100001)(76176999)(6506006)(38730400001)(6436002)(236005)(55016002)(77096006)(3280700002)(97736004)(102836003)(5001770100001)(25786008)(6116002)(19609705001)(99286003)(92566002)(6306002)(5660300001)(122556002)(3846002)(107886002)(790700001)(9686003)(189998001)(2906002)(53936002)(54896002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2350; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 11:39:46.9729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2350 X-MC-Unique: 3liygVWYNWKICJFGmqGnxQ-1 Content-Type: multipart/alternative; boundary="_000_SN2PR03MB2350656220B7D65128F2952EB27F0SN2PR03MB2350namp_" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 11:39:59 -0000 --_000_SN2PR03MB2350656220B7D65128F2952EB27F0SN2PR03MB2350namp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 TG9va2luZyB0byB0aGlzIG9uIGEg4oCccGhpbG9zb3BoaWNhbOKAnSBsZXZlbDoNCg0KSSBkb27i gJl0IHRoaW5rIHRoZSByaWdodCBhcHByb2FjaCBpcyB0byB1c2UgY2FsbGluZy9jYWxsZWQgZGVm aW5pdGlvbnMgYXMgdXNlZCBpbiB0ZWNobmljYWwgc3BlY2lmaWNhdGlvbnMuIEluIHRoZSBjb250 ZXh0IG9mIOKAnDY2NiB1bndhbnRlZOKAnSwgSSBhbSB0aGUg4oCcY2FsbGVy4oCdIGlmIEkgZGlh bCBhIG51bWJlci4gSSBhbSB0aGUg4oCcY2FsbGVk4oCdIGlmIEkgcmVjZWl2ZSB0aGUgY2FsbCAo bWVhbmluZyBteSBVRSBhbGVydHMgbWUpICwgYW5kIHRoaXMgaXMgd2hlcmUgdGhpcyBuZXcgcmVz cG9uc2UgY29kZSBjb21lcyBpbnRvIHBsYXkuIEl0IGRvZXNu4oCZdCBtYXR0ZXIgd2hhdCAocG9z c2libHkgY29tcGxleCkgY2FsbCBzY2VuYXJpbyBjYXVzZWQgYWxlcnRpbmcuDQoNCkkgZG9u4oCZ dCB0aGluayB0aGVyZSBpcyBhbiBpc3N1ZSBwZXJ0YWluaW5nIHRvIGRyYWZ0LWlldGYtc2lwY29y ZS1zdGF0dXMtdW53YW50ZWQgb24gdGhpcyB0b3BpYywgYXQgbGVhc3Qgbm90IG9uIGEgbGV2ZWwg d2hlcmUgdGV4dCBuZWVkcyB0byBiZSBhZGRlZC9jaGFuZ2VkLg0KDQpUaGFua3MsDQpUb2xnYQ0K DQpGcm9tOiBzaXBjb3JlIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSGVubmluZyBTY2h1bHpyaW5uZQ0KU2VudDogVHVlc2RheSwgSmFudWFyeSAxNywgMjAx NyA2OjA1IFBNDQpUbzogQnJldHQgVGF0ZSA8YnJldHRAYnJvYWRzb2Z0LmNvbT47IHNpcGNvcmVA aWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1z aXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMQ0KDQpBcyBJIG1lbnRpb25lZCBiZWZvcmUsIGl0IHNl ZW1zIHNvbWV3aGF0IHVubGlrZWx5IHRoYXQgM1BDQyBzY2VuYXJpb3Mgb2NjdXIgZm9yIHVud2Fu dGVkIGNhbGxzLCBleGNlcHQgYnkgYWNjaWRlbnQgb3IgYmVjYXVzZSBvZiBmb3J3YXJkLW9uLWJ1 c3kgb3IgZm9yd2FyZC1vbi12YWNhdGlvbi4gKEFkbWluIGFzc2lzdGFudCB0cmFuc2ZlcnMgYSBj YWxsIGZyb20g4oCcTWFycmlvdHQgSG90ZWxz4oCdIHRvIGhpcyBib3NzLCB0aGlua2luZyB0aGF0 IHRoaXMgaXMgYWJvdXQgYW4gdXBjb21pbmcgaG90ZWwgcmVzZXJ2YXRpb24sIGJ1dCB0aGUgY2Fs bCB0dXJucyBvdXQgdG8gYmUgc3BhbS4pIEFzIHlvdSBub3RlLCB0aGUgZm9yd2FyZGluZyBwYXJ0 eSBzaG91bGQgbm90IGJlIGZsYWdnZWQuDQoNCkJ1dCBzaW5jZSBpdOKAmXMgdGhlIGNvbnRlbnQg b2YgdGhlIGNhbGwgaXMgZGVlbWVkIG9iamVjdGlvbmFibGUgKHVud2FudGVkKSBieSB0aGUgcmVj aXBpZW50LCB0aGUgZ29hbCBzaG91bGQgYmUgdG8gaWRlbnRpZnkgdGhlIHBhcnR5IHRoYXQgaXMg Z2VuZXJhdGluZyB0aGF0IGNvbnRlbnQsIGV2ZW4gaWYgdGhleSB0cnkgdG8gaGlkZSBiZWhpbmQg c29tZWJvZHkgZWxzZS4NCg0KSeKAmW0gcHJvYmFibHkgbGFja2luZyBpbWFnaW5hdGlvbiwgYnV0 IGNhbiB5b3UgZXhwbGFpbiBob3cgdGhlc2Ugc2NlbmFyaW9zIHdvdWxkIG9jY3VyIGluIHRoZSB0 eXBpY2FsIHJvYm9jYWxsLCBiZXlvbmQgdGhlIGFjY2lkZW50YWwgZm9yd2FyZGluZyBjYXNlIGFi b3ZlPyBJIGNhbiBzZWUgaW5jZW50aXZlcyBmb3IgYmFkIGFjdG9ycyB0byBoaWRlIGJlaGluZCBp bm5vY2VudCB0aGlyZCBwYXJ0aWVzLCBidXQgSeKAmW0gbm90IHN1cmUgdGhhdOKAmXMgd2hhdCB5 b3UgaGF2ZSBpbiBtaW5kIGZvciB0aGUgc2NlbmFyaW9zIGJlbG93Lg0KDQpJcyB0aGVyZSBhIGRl ZmluYWJsZSBub3Rpb24gb2YgdGhlIOKAnG9yaWdpbmFs4oCdIGNhbGxpbmcgcGFydHkgc2luY2Ug dGhhdCBzZWVtcyBtb3N0IGxpa2VseSB0byBiZSB0aGUgYmFkIGFjdG9yPw0KDQpIZW5uaW5nDQoN CkZyb206IEJyZXR0IFRhdGUgW21haWx0bzpicmV0dEBicm9hZHNvZnQuY29tXQ0KU2VudDogVHVl c2RheSwgSmFudWFyeSAxNywgMjAxNyAxMTozNyBBTQ0KVG86IEhlbm5pbmcgU2NodWx6cmlubmUg PEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjxtYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBm Y2MuZ292Pj47IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMt dW53YW50ZWQtMDENCg0KSGksDQoNCkNvbmNlcm5pbmcgdGhlIGxpa2VsaWhvb2QsIEkgYXNzdW1l IHRoYXQgaXQgd291bGQgZGVwZW5kIHVwb24gaWYgdGhlcmUgaXMgYSBjb252ZW5pZW5jZSwgYnVz aW5lc3MsIG9yIG1pc2NoaWV2b3VzIHJlYXNvbiB0byBkbyBpdC4NCg0KQXMgSeKAmXZlIG1lbnRp b25lZCwgSSBmaW5kIHRoZSBjb25jZXB0IG9mIHdobyBnZXRzIGltcGFjdGVkIGJ5IDY2NiBzb21l d2hhdCB2YWd1ZSB3aXRoaW4gdGhlIGRyYWZ0IGJlY2F1c2Ugb2YgdGhlIHZhcmlldHkgb2YgY2Fs bCBzZXJ2aWNlcyAoM1BDQywgY2FsbCBmb3J3YXJkaW5nLCB0cmFuc2ZlciwgZXQgY2V0ZXJhKSBh bmQgd2F5cyB0byB1cGRhdGUgdGhlIGNvbm5lY3RlZCBpZGVudGl0eS4gIEhvd2V2ZXIsIEkgYXNz dW1lIHRoYXQgdGhlIGRyYWZ0IGNhbiBwcm9jZWVkIHdpdGhvdXQgbmVlZGluZyB0byBjbGFyaWZ5 IHRoYXQgc3R1ZmYuDQoNCklmIGFueW9uZSBrbm93cyB0aGUgYW5zd2VycyB0byB0aGUgZm9sbG93 aW5nLCBwbGVhc2UgbGV0IG1lIGtub3cuDQoNCklmIHRoZSAiY2FsbGluZyBwYXJ0eSIgZ2V0cyBy ZXBsYWNlZCBiZWZvcmUgImNhbGxlZCBwYXJ0eSIgc2VuZHMgQllFIHdpdGggNjY2LCB3aG8gc2hv dWxkIGJlIGZsYWdnZWQ6IDEpIGNhbGxpbmcgcGFydHkgaW5kaWNhdGVkIHdpdGhpbiBvcmlnaW5h bCBJTlZJVEUgb3IgMikgbmV3ZXN0IGNvbm5lY3RlZCBwYXJ0eT8NCg0KU2hvdWxkIHRoZSBjb25u ZWN0ZWQgcGFydHkgYmUgZmxhZ2dlZCBpZiB0aGUgImNhbGxpbmcgcGFydHkiIHNlbmRzIEJZRSB3 aXRoIDY2Nj8NCg0KU2hvdWxkIHRoZSBjYWxsIGZvcndhcmRpbmcgcGFydHkgYmUgZmxhZ2dlZCB3 aGVuIGZsYWdnaW5nIHRoZSAiY2FsbGluZyBwYXJ0eSI/ICBJIGFzc3VtZSBubyBzaW5jZSBwb3Rl bnRpYWxseSBpbm5vY2VudCBieXN0YW5kZXIuDQoNClNob3VsZCB0aGUgY2FsbCB0cmFuc2ZlcnJp bmcgcGFydHkgYmUgZmxhZ2dlZCB3aGVuIGZsYWdnaW5nIHRoZSAiY2FsbGluZyBwYXJ0eSI/DQoN ClRoYW5rcywNCkJyZXR0DQoNCkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0bzpIZW5u aW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8bWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdv dj5dDQpTZW50OiBTdW5kYXksIEphbnVhcnkgMTUsIDIwMTcgMzo0OSBQTQ0KVG86IEJyZXR0IFRh dGU7IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50 ZWQtMDENCg0KDQpIb3cgbGlrZWx5IGlzIGFueSBvZiB0aGlzIGdvaW5nIHRvIGhhcHBlbiBmb3Ig dW53YW50ZWQgcm9ib2NhbGxzPyBGb3IgZmlndXJlIDQsIHRoZSBvbmUgc2NlbmFyaW8gSSBjYW4g dGhpbmsgb2YgaXMgdGhlICJldmlsIiBjb250cm9sbGVyIGxldmVyYWdpbmcgYSBzZXJ2aWNlIEEg dG8gY2FsbCBCLCBhbmQgQiA2NjYnaW5nIHRoZSBjYWxsIG9yIHNlbmRpbmcgYSBCWUUgd2l0aCBS ZWFzb24oNjY2KS4gQnV0IHRoYXQgd291bGQgc2VlbSB0byBiZSBwcmV0dHkgc3RhbmRhcmQsIGV2 ZW4gaWYgdGhlIGZpbmFsIHJlY2lwaWVudCBvZiB0aGUgNjY2IG9yIEJZRSBpcyBBICh3aG8gaXMg bGlrZWx5IHRvIGlnbm9yZSBpdCkuDQoNCg0KDQpJIHRoaW5rIGl0IHdvdWxkIGhlbHAgaWYgeW91 IGNvdWxkIGlkZW50aWZ5IHRoZSByb2xlcyBvZiB0aGUgdGhpcmQgcGFydGllcyBhbmQgc2VlIGlm IHRoYXQgY2F1c2VzIHRoZSByZWNpcGllbnQgb2YgdGhlIHVud2FudGVkIGNhbGwgdG8gZG8gc29t ZXRoaW5nIHRoYXQncyBoYXJtZnVsIHRvIGlubm9jZW50IGJ5c3RhbmRlcnMuDQoNCg0KDQpIZW5u aW5nDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tOiBCcmV0dCBUYXRl IDxicmV0dEBicm9hZHNvZnQuY29tPG1haWx0bzpicmV0dEBicm9hZHNvZnQuY29tPj4NClNlbnQ6 IEZyaWRheSwgSmFudWFyeSAxMywgMjAxNyAzOjQ4OjU4IFBNDQpUbzogSGVubmluZyBTY2h1bHpy aW5uZTsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6 IFJFOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndh bnRlZC0wMQ0KDQpIaSwNCg0KQ29uY2VybmluZyBjYWxsaW5nIHBhcnR5IHNlbmRpbmcgQllFIHdp dGggNjY2LCBJIGp1c3QgdGhvdWdodCB0aGF0IGl0IHBvdGVudGlhbGx5IHNob3VsZCBiZSBkaXNj dXNzZWQuDQoNCkhvd2V2ZXIsIFJGQyAzNzI1IGZpZ3VyZXMgNCBhbmQgZmlndXJlIDcgZG8gc2hv dyBob3cgYSDigJxjYWxsaW5nIHBhcnR54oCdIG1pZ2h0IGdldCByZXBsYWNlZCBieSBhIOKAnGNh bGxlZCBwYXJ0eeKAnS4gIFRodXMgaWYgdGhlIGNvbnRyb2xsZXIgZG9lc27igJl0IHN0cmlwIHRo ZSBSZWFzb24gd2hpbGUgcmVsYXlpbmcgdGhlIEJZRSwgaXQgZGVmaW5pdGVseSB3b3VsZCBiZSBw b3NzaWJsZSBzaW5jZSBib3RoIGFyZSBjYWxsZWQgcGFydGllcy4NCg0KSWYgdGhlIOKAnGNhbGxp bmcgcGFydHnigJ0gZ2V0cyByZXBsYWNlZCBiZWZvcmUg4oCcY2FsbGVkIHBhcnR54oCdIHNlbmRz IEJZRSB3aXRoIDY2Niwgd2hvIHNob3VsZCBiZSBmbGFnZ2VkOiAxKSBjYWxsaW5nIHBhcnR5IGlu ZGljYXRlZCB3aXRoaW4gb3JpZ2luYWwgSU5WSVRFIG9yIDIpIG5ld2VzdCBjb25uZWN0ZWQgcGFy dHk/DQoNClRoYW5rcywNCkJyZXR0DQoNCkZyb206IEhlbm5pbmcgU2NodWx6cmlubmUgW21haWx0 bzpIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8bWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVA ZmNjLmdvdj5dDQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMiwgMjAxNyAzOjMxIFBNDQpUbzog QnJldHQgVGF0ZTsgbWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1v aGFsaUBvcmFuZ2UuY29tPjsgc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9y Zz4NClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3Jl LXN0YXR1cy11bndhbnRlZC0wMQ0KDQpJ4oCZbSBhZnJhaWQgSSBkb27igJl0IHF1aXRlIGZvbGxv dyB3aGF0IHRleHQgeW91IGFyZSBzdWdnZXN0aW5nIGFuZCBJ4oCZbSBzdXNwZWN0aW5nIHdl4oCZ cmUgd2VsbCBpbnRvIHRoZSB3ZWVkcyBhdCB0aGlzIHBvaW50LiBNeSBnZW5lcmFsIGluY2xpbmF0 aW9uIGlzIHRvIG9ubHkgc3RhdGUgdGhpbmdzIHdoZXJlIDY2NiBkaWZmZXJzIGZyb20gNnh4IGhh bmRsaW5nLCByYXRoZXIgdGhhbiB0cnkgdG8gY2FwdHVyZSBhbGwgcG9zc2libGUgc3RhdHVzIGNv ZGUgaXNzdWVzIHRoYXQgYXJlIGdlbmVyaWMgdG8gKG1vc3QpIDZ4eCBjb2Rlcy4gVGhpcyBhdm9p ZHMgY3JlYXRpbmcgaW5hZHZlcnRlbnQgY29udHJhZGljdGlvbnMgb3IgdGhlIG5lZWQgdG8gdXBk YXRlIHRoZSBkb2N1bWVudCBzaG91bGQgdGhlcmUgYmUgY2hhbmdlcyBpbiB0aGUgZ2VuZXJpYyBo YW5kbGluZy4gSW4gb3RoZXIgd29yZHMsIDY2NiBzaG91bGQgYmUgdHJlYXRlZCBsaWtlIDZ4eCB1 bmxlc3Mgb3RoZXJ3aXNlIG5vdGVkLg0KDQpUaHVzLCBjYW4geW91IHByb3ZpZGUgc3VnZ2VzdGVk IHRleHQ/DQoNCknigJltIG5vdCBzdXJlIHdoeSB0aGUgY2FsbGluZyBwYXJ0eSB3b3VsZCBpbmRp Y2F0ZSA2NjYuIEFmdGVyIHJlY2VpdmluZyBhIHJlLUlOVklURT8gSW4gcmVzcG9uc2UgdG8gYSBC WUU/IEkgYWRtaXQgdGhhdCBJIGxhY2sgdGhlIGltYWdpbmF0aW9uIGFzIHRvIGhvdyB0aGlzIHdv dWxkIG9jY3VyIGFuZCB3aHkgdGhpcyB3b3VsZCBjYXVzZSBhbnl0aGluZyBvdGhlciB0aGFuIHdo YXQgd291bGQgaGFwcGVuIGZvciBhIGdlbmVyaWMgNnh4IHJlc3BvbnNlIGluIHRob3NlIGNpcmN1 bXN0YW5jZXMuDQoNClN0cmV0Y2hpbmcgdGhlIGltYWdpbmF0aW9uLCBJIGNvdWxkIGltYWdpbmUg dGhlIGNhc2Ugd2hlcmUgSeKAmW0gbWlzbGVkIGludG8gZGlhbGluZyBhIG51bWJlciAoZS5nLiwg YXMgcGFydCBvZiBhIHNwYW0gZW1haWwpIHRoYXQgdHVybnMgb3V0IHRvIGJlIGEgcm9ib3QgcGVk ZGxpbmcgdGltZSBzaGFyZXMuIEkgY291bGQgc2VuZCBhIEJZRSwgd2l0aCBhIDY2NiBSZWFzb24u DQoNCklzIHRoYXQgdGhlIGNhc2UgeW91IGhhdmUgaW4gbWluZD8NCg0KSGVubmluZw0KDQpGcm9t OiBCcmV0dCBUYXRlIFttYWlsdG86YnJldHRAYnJvYWRzb2Z0LmNvbV0NClNlbnQ6IEZyaWRheSwg SmFudWFyeSAwNiwgMjAxNyAxMjozMiBQTQ0KVG86IG1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29t PG1haWx0bzptYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbT47IEhlbm5pbmcgU2NodWx6cmlubmUg PEhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjxtYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBm Y2MuZ292Pj47IHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMt dW53YW50ZWQtMDENCg0KSGksDQoNClRoZSBkcmFmdCBwb3RlbnRpYWxseSBzaG91bGQgYWxzbyBk aXNjdXNzIHRoZSBwb3RlbnRpYWwgZm9yIHRoZSBjb25uZWN0ZWQgcGFydHkgdG8gY2hhbmdlIG1p ZC1kaWFsb2cgMSkgd2l0aG91dCBpdCBiZWluZyBjb21tdW5pY2F0ZWQgYW5kIDIpIHdpdGggaXQg YmVpbmcgY29tbXVuaWNhdGUgYnkgUkZDIDQ5MTYsIFJGQyA1ODc2LCBldCBjZXRlcmEuDQoNCkZy b20gYSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwZXJzcGVjdGl2ZSwgdGhlIHdyb25nIHBhcnR5 IG1pZ2h0IGJlIGZsYWdnZWQgYnkgdGhlIDY2NiB3aGVuIHRoZSBjb25uZWN0ZWQgcGFydHkgY2hh bmdlcy4NCg0KVGhlIGRyYWZ0IHNob3VsZCBwb3RlbnRpYWxseSBhbHNvIGRpc2N1c3MgdGhlIHBv dGVudGlhbCBmb3IgY2FsbGluZyBwYXJ0eSBpbmRpY2F0aW5nIDY2Ni4gIE90aGVyIHRoYW4gYSB3 YXkgdG8gYXR0YWNrIHNvbWVvbmUsIEnigJltIG5vdCBzdXJlIGlmIGFyZSBhbnkgM1BDQywgdHJh bnNmZXIsIG9yIG90aGVyIHNlcnZpY2Ugc2l0dWF0aW9ucyB3aGVyZSBpdCBtaWdodCBhY3R1YWxs eSBiZSBhcHByb3ByaWF0ZS4NCg0KDQpGcm9tOiBtYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTxt YWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20+IFttYWlsdG86bWFyaWFubmUubW9oYWxp QG9yYW5nZS5jb208bWFpbHRvOm1hcmlhbm5lLm1vaGFsaUBvcmFuZ2UuY29tPl0NClNlbnQ6IEZy aWRheSwgSmFudWFyeSAwNiwgMjAxNyAxMDoyOCBBTQ0KVG86IEhlbm5pbmcgU2NodWx6cmlubmU7 IEFzdmVyZW4sIFRvbGdhOyBCcmV0dCBUYXRlOyBzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFtzaXBjb3JlXSBDb21tZW50cyBvbiBkcmFmdC1p ZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVkLTAxDQoNCkhpLA0KDQpUbyByZWZsZWN0IHRoZSBx dWVzdGlvbiBvZiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgdGhlIDY2NiByZXNwb25zZSBpbnRlcnBy ZXRhdGlvbiB3aGVuIHRoZSBjYWxsZXIgaGFzIHNldmVyYWwgaWRlbnRpdGllcyB1c2VkIGZvciB0 aGlzIGNhbGwgKGllLiBGcm9tIGFuZCBQLUFzc2VydGVkLUlkZW50aXR5IGFyZSBkaWZmZXJlbnQp IG9yIGNhbGwgZm9yd2FyZGluZy9jYWxsIHRyYW5zZmVyIHVzZSBjYXNlcyBmb3Igd2hpY2ggaXQg aGFzIHRvIGJlIGRpc2N1c3NlZCB3aGljaCBwYXJ0eSBzaG91bGQgYmUgY29uc2lkZXJlZCBoYXMg YSBmcmF1ZHVsZW50IChpZS4gdGhlIGNhbGxpbmcgcGFydHkgb3IgdGhlIGRpdmVydGluZyBwYXJ0 eSBvciBib3RoID8pIDsgSSBwcm9wb3NlIHRvIGFkZCB0aGUgZm9sbG93aW5nIHRleHQ6DQpUaGlz IGRvY3VtZW50IGRlZmluZXMgYSBtZWNoYW5pc20gYnkgd2hpY2ggYSBjYWxsZWQgcGFydHkgY2Fu IHJlamVjdCBhbiB1bndhbnRlZCBjYWxsIHdpdGhvdXQgY29uc2lkZXJhdGlvbiBvZiB0aGUgY2Fs bGluZyBwYXJ0eSBpZGVudGlmaWNhdGlvbiB0aGF0IHJlbWFpbiB0byB0aGUgc2VydmljZSBwcm92 aWRlciBwb2xpY3kuIEluZGVlZCwgdGhlIGNhbGxpbmcgcGFydHkgaWRlbnRpdHkgbWF5IGJlIHJl ZmxlY3RlZCBpbiBkaWZmZXJlbnQgd2F5IGZvciBhIGRpcmVjdCBjYWxsIG9yIGFmdGVyIGEgZGl2 ZXJ0aW5nIHNlcnZpY2UgaW4gUC1Bc3NlcnRlZC1JZGVudGl0eSwgRnJvbSwgSGlzdG9yeS1JbmZv IG9yIGFueSBjb25jdXJyZW50IGhlYWRlciBmaWVsZCB0aGF0IGNhbiBiZSBwcmVzZW50IGF0IHRo ZSBzYW1lIHRpbWUgaW4gYSBTSVAgbWVzc2FnZS4NCg0KVGhvc2UgcXVlc3Rpb25zIGFyZSByZWFs IGlzc3VlcyBmb3Igb3BlcmF0b3JzIGFuZCBpbXBsZW1lbnRvcnMgYW5kIHRoZXkgYXJlIGEgd2Vh a25lc3MgdGhhdCBmcmF1ZHVsZW50IGNhbGxlcnMgY291bGQgdXNlIHRvIGJ5cGFzcyB0aGUgbWVj aGFuaXNtLg0KDQpCUiwNCk1hcmlhbm5lDQoNCg0KDQo= --_000_SN2PR03MB2350656220B7D65128F2952EB27F0SN2PR03MB2350namp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0K CXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4u TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0Zv bGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnByZQ0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1h cmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUs IGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlm O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l OiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7 fQ0KcC5lbWFpbHF1b3RlLCBsaS5lbWFpbHF1b3RlLCBkaXYuZW1haWxxdW90ZQ0KCXttc28tc3R5 bGUtbmFtZTplbWFpbHF1b3RlOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltYXJnaW4tdG9w OjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1s ZWZ0OjEuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uUHJmb3JtYXRIVE1M Q2FyDQoJe21zby1zdHlsZS1uYW1lOiJQcj9mb3JtYXQ/IEhUTUwgQ2FyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByP2Zvcm1hdD8gSFRNTCI7DQoJZm9udC1m YW1pbHk6Q29uc29sYXM7fQ0KcC5QcmZvcm1hdEhUTUwsIGxpLlByZm9ybWF0SFRNTCwgZGl2LlBy Zm9ybWF0SFRNTA0KCXttc28tc3R5bGUtbmFtZToiUHI/Zm9ybWF0PyBIVE1MIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByP2Zvcm1hdD8gSFRNTCBDYXIiOw0K CW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5UZXh0ZWRlYnVs bGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9u dC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpwLlRleHRlZGVidWxsZXMsIGxpLlRleHRl ZGVidWxsZXMsIGRpdi5UZXh0ZWRlYnVsbGVzDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBi dWxsZXMiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUg ZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUyOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxT dHlsZTI5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzMQ0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTMyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMzMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUzNA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAu ODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+TG9va2luZyB0byB0aGlzIG9uIGEg4oCccGhpbG9zb3BoaWNhbOKAnSBsZXZl bDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SSBkb27igJl0IHRoaW5rIHRoZSByaWdodCBhcHByb2FjaCBpcyB0 byB1c2UgY2FsbGluZy9jYWxsZWQgZGVmaW5pdGlvbnMgYXMgdXNlZCBpbiB0ZWNobmljYWwgc3Bl Y2lmaWNhdGlvbnMuIEluIHRoZSBjb250ZXh0IG9mIOKAnDY2NiB1bndhbnRlZOKAnSwgSSBhbSB0 aGUg4oCcY2FsbGVy4oCdIGlmIEkgZGlhbCBhIG51bWJlci4NCiBJIGFtIHRoZSDigJxjYWxsZWTi gJ0gaWYgSSByZWNlaXZlIHRoZSBjYWxsIChtZWFuaW5nIG15IFVFIGFsZXJ0cyBtZSkgLCBhbmQg dGhpcyBpcyB3aGVyZSB0aGlzIG5ldyByZXNwb25zZSBjb2RlIGNvbWVzIGludG8gcGxheS4gSXQg ZG9lc27igJl0IG1hdHRlciB3aGF0IChwb3NzaWJseSBjb21wbGV4KSBjYWxsIHNjZW5hcmlvIGNh dXNlZCBhbGVydGluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JIGRvbuKAmXQgdGhpbmsgdGhlcmUgaXMg YW4gaXNzdWUgcGVydGFpbmluZyB0byBkcmFmdC1pZXRmLXNpcGNvcmUtc3RhdHVzLXVud2FudGVk IG9uIHRoaXMgdG9waWMsIGF0IGxlYXN0IG5vdCBvbiBhIGxldmVsIHdoZXJlIHRleHQgbmVlZHMg dG8gYmUgYWRkZWQvY2hhbmdlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VG9sZ2E8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gc2lwY29y ZSBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ SGVubmluZyBTY2h1bHpyaW5uZTxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDE3 LCAyMDE3IDY6MDUgUE08YnI+DQo8Yj5Ubzo8L2I+IEJyZXR0IFRhdGUgJmx0O2JyZXR0QGJyb2Fk c29mdC5jb20mZ3Q7OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBb c2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0w MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBJIG1lbnRpb25lZCBiZWZvcmUsIGl0IHNlZW1zIHNv bWV3aGF0IHVubGlrZWx5IHRoYXQgM1BDQyBzY2VuYXJpb3Mgb2NjdXIgZm9yIHVud2FudGVkIGNh bGxzLCBleGNlcHQgYnkgYWNjaWRlbnQgb3IgYmVjYXVzZSBvZiBmb3J3YXJkLW9uLWJ1c3kgb3Ig Zm9yd2FyZC1vbi12YWNhdGlvbi4NCiAoQWRtaW4gYXNzaXN0YW50IHRyYW5zZmVycyBhIGNhbGwg ZnJvbSDigJxNYXJyaW90dCBIb3RlbHPigJ0gdG8gaGlzIGJvc3MsIHRoaW5raW5nIHRoYXQgdGhp cyBpcyBhYm91dCBhbiB1cGNvbWluZyBob3RlbCByZXNlcnZhdGlvbiwgYnV0IHRoZSBjYWxsIHR1 cm5zIG91dCB0byBiZSBzcGFtLikgQXMgeW91IG5vdGUsIHRoZSBmb3J3YXJkaW5nIHBhcnR5IHNo b3VsZCBub3QgYmUgZmxhZ2dlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPkJ1dCBzaW5jZSBpdOKAmXMgdGhlIGNvbnRlbnQgb2YgdGhlIGNhbGwgaXMgZGVlbWVk IG9iamVjdGlvbmFibGUgKHVud2FudGVkKSBieSB0aGUgcmVjaXBpZW50LCB0aGUgZ29hbCBzaG91 bGQgYmUgdG8gaWRlbnRpZnkgdGhlIHBhcnR5IHRoYXQgaXMgZ2VuZXJhdGluZyB0aGF0IGNvbnRl bnQsDQogZXZlbiBpZiB0aGV5IHRyeSB0byBoaWRlIGJlaGluZCBzb21lYm9keSBlbHNlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SeKAmW0gcHJvYmFibHkgbGFj a2luZyBpbWFnaW5hdGlvbiwgYnV0IGNhbiB5b3UgZXhwbGFpbiBob3cgdGhlc2Ugc2NlbmFyaW9z IHdvdWxkIG9jY3VyIGluIHRoZSB0eXBpY2FsIHJvYm9jYWxsLCBiZXlvbmQgdGhlIGFjY2lkZW50 YWwgZm9yd2FyZGluZyBjYXNlIGFib3ZlPyBJDQogY2FuIHNlZSBpbmNlbnRpdmVzIGZvciBiYWQg YWN0b3JzIHRvIGhpZGUgYmVoaW5kIGlubm9jZW50IHRoaXJkIHBhcnRpZXMsIGJ1dCBJ4oCZbSBu b3Qgc3VyZSB0aGF04oCZcyB3aGF0IHlvdSBoYXZlIGluIG1pbmQgZm9yIHRoZSBzY2VuYXJpb3Mg YmVsb3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JcyB0aGVy ZSBhIGRlZmluYWJsZSBub3Rpb24gb2YgdGhlIOKAnG9yaWdpbmFs4oCdIGNhbGxpbmcgcGFydHkg c2luY2UgdGhhdCBzZWVtcyBtb3N0IGxpa2VseSB0byBiZSB0aGUgYmFkIGFjdG9yPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGVubmluZzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQnJldHQgVGF0ZSBbPGEgaHJlZj0ibWFpbHRv OmJyZXR0QGJyb2Fkc29mdC5jb20iPm1haWx0bzpicmV0dEBicm9hZHNvZnQuY29tPC9hPl0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKYW51YXJ5IDE3LCAyMDE3IDExOjM3IEFNPGJyPg0K PGI+VG86PC9iPiBIZW5uaW5nIFNjaHVsenJpbm5lICZsdDs8YSBocmVmPSJtYWlsdG86SGVubmlu Zy5TY2h1bHpyaW5uZUBmY2MuZ292Ij5IZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y8L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9h Pjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NpcGNvcmVdIENvbW1lbnRzIG9uIGRyYWZ0LWll dGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25jZXJuaW5nIHRoZSBs aWtlbGlob29kLCBJIGFzc3VtZSB0aGF0IGl0IHdvdWxkIGRlcGVuZCB1cG9uIGlmIHRoZXJlIGlz IGEgY29udmVuaWVuY2UsIGJ1c2luZXNzLCBvciBtaXNjaGlldm91cyByZWFzb24gdG8gZG8gaXQu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5BcyBJ4oCZdmUgbWVu dGlvbmVkLCBJIGZpbmQgdGhlIGNvbmNlcHQgb2Ygd2hvIGdldHMgaW1wYWN0ZWQgYnkgNjY2IHNv bWV3aGF0IHZhZ3VlIHdpdGhpbiB0aGUgZHJhZnQgYmVjYXVzZSBvZiB0aGUgdmFyaWV0eSBvZiBj YWxsIHNlcnZpY2VzICgzUENDLCBjYWxsIGZvcndhcmRpbmcsDQogdHJhbnNmZXIsIGV0IGNldGVy YSkgYW5kIHdheXMgdG8gdXBkYXRlIHRoZSBjb25uZWN0ZWQgaWRlbnRpdHkuJm5ic3A7IEhvd2V2 ZXIsIEkgYXNzdW1lIHRoYXQgdGhlIGRyYWZ0IGNhbiBwcm9jZWVkIHdpdGhvdXQgbmVlZGluZyB0 byBjbGFyaWZ5IHRoYXQgc3R1ZmYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5JZiBhbnlvbmUga25vd3MgdGhlIGFuc3dlcnMgdG8gdGhlIGZvbGxvd2luZywgcGxl YXNlIGxldCBtZSBrbm93Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+SWYgdGhlICZxdW90O2NhbGxpbmcgcGFydHkmcXVvdDsgZ2V0cyByZXBsYWNlZCBiZWZvcmUg JnF1b3Q7Y2FsbGVkIHBhcnR5JnF1b3Q7IHNlbmRzIEJZRSB3aXRoIDY2Niwgd2hvIHNob3VsZCBi ZSBmbGFnZ2VkOiAxKSBjYWxsaW5nIHBhcnR5IGluZGljYXRlZCB3aXRoaW4gb3JpZ2luYWwgSU5W SVRFIG9yIDIpDQogbmV3ZXN0IGNvbm5lY3RlZCBwYXJ0eT88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNob3VsZCB0aGUgY29ubmVjdGVkIHBhcnR5IGJlIGZsYWdn ZWQgaWYgdGhlICZxdW90O2NhbGxpbmcgcGFydHkmcXVvdDsgc2VuZHMgQllFIHdpdGggNjY2Pzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2hvdWxkIHRoZSBjYWxs IGZvcndhcmRpbmcgcGFydHkgYmUgZmxhZ2dlZCB3aGVuIGZsYWdnaW5nIHRoZSAmcXVvdDtjYWxs aW5nIHBhcnR5JnF1b3Q7PyZuYnNwOyBJIGFzc3VtZSBubyBzaW5jZSBwb3RlbnRpYWxseSBpbm5v Y2VudCBieXN0YW5kZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5TaG91bGQgdGhlIGNhbGwgdHJhbnNmZXJyaW5nIHBhcnR5IGJlIGZsYWdnZWQgd2hlbiBmbGFn Z2luZyB0aGUgJnF1b3Q7Y2FsbGluZyBwYXJ0eSZxdW90Oz88L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnJldHQ8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj4gSGVubmluZyBTY2h1bHpyaW5uZSBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpIZW5uaW5n LlNjaHVsenJpbm5lQGZjYy5nb3YiPkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjwvYT5dDQo8 YnI+DQo8Yj5TZW50OjwvYj4gU3VuZGF5LCBKYW51YXJ5IDE1LCAyMDE3IDM6NDkgUE08YnI+DQo8 Yj5Ubzo8L2I+IEJyZXR0IFRhdGU7IDxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5z aXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NpcGNvcmVdIENv bW1lbnRzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8cD48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPkhvdyBsaWtlbHkgaXMgYW55IG9mIHRoaXMgZ29pbmcgdG8g aGFwcGVuIGZvciB1bndhbnRlZCByb2JvY2FsbHM/IEZvciBmaWd1cmUgNCwgdGhlIG9uZSBzY2Vu YXJpbyBJIGNhbiB0aGluayBvZiBpcyB0aGUgJnF1b3Q7ZXZpbCZxdW90OyBjb250cm9sbGVyIGxl dmVyYWdpbmcgYSBzZXJ2aWNlIEEgdG8gY2FsbCBCLCBhbmQgQiA2NjYnaW5nIHRoZSBjYWxsIG9y IHNlbmRpbmcgYSBCWUUgd2l0aCBSZWFzb24oNjY2KS4NCiBCdXQgdGhhdCB3b3VsZCBzZWVtIHRv IGJlIHByZXR0eSBzdGFuZGFyZCwgZXZlbiBpZiB0aGUgZmluYWwgcmVjaXBpZW50IG9mIHRoZSA2 NjYgb3IgQllFIGlzIEEgKHdobyBpcyBsaWtlbHkgdG8gaWdub3JlIGl0KS48L3NwYW4+PG86cD48 L286cD48L3A+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SSB0aGluayBpdCB3b3Vs ZCBoZWxwIGlmIHlvdSBjb3VsZCBpZGVudGlmeSB0aGUgcm9sZXMgb2YgdGhlIHRoaXJkIHBhcnRp ZXMgYW5kIHNlZSBpZiB0aGF0IGNhdXNlcyB0aGUgcmVjaXBpZW50IG9mIHRoZSB1bndhbnRlZCBj YWxsIHRvIGRvIHNvbWV0aGluZyB0aGF0J3MgaGFybWZ1bCB0byBpbm5vY2VudCBieXN0YW5kZXJz Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5I ZW5uaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3Jt YWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlciI+DQo8aHIgc2l6ZT0i MiIgd2lkdGg9Ijk4JSIgYWxpZ249ImNlbnRlciI+DQo8L2Rpdj4NCjxkaXYgaWQ9ImRpdlJwbHlG d2RNc2ciPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gQnJldHQg VGF0ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb20iPmJyZXR0QGJyb2Fk c29mdC5jb208L2E+Jmd0Ozxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkgMTMsIDIw MTcgMzo0ODo1OCBQTTxicj4NCjxiPlRvOjwvYj4gSGVubmluZyBTY2h1bHpyaW5uZTsgPGEgaHJl Zj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJFOiBbc2lwY29yZV0gQ29tbWVudHMgb24gZHJhZnQtaWV0Zi1zaXBjb3Jl LXN0YXR1cy11bndhbnRlZC0wMTwvc3Bhbj4NCjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ SGksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Db25jZXJuaW5n IGNhbGxpbmcgcGFydHkgc2VuZGluZyBCWUUgd2l0aCA2NjYsIEkganVzdCB0aG91Z2h0IHRoYXQg aXQgcG90ZW50aWFsbHkgc2hvdWxkIGJlIGRpc2N1c3NlZC48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIFJGQyAzNzI1IGZpZ3VyZXMgNCBhbmQgZmln dXJlIDcgZG8gc2hvdyBob3cgYSDigJxjYWxsaW5nIHBhcnR54oCdIG1pZ2h0IGdldCByZXBsYWNl ZCBieSBhIOKAnGNhbGxlZCBwYXJ0eeKAnS4mbmJzcDsgVGh1cyBpZiB0aGUgY29udHJvbGxlciBk b2VzbuKAmXQgc3RyaXAgdGhlIFJlYXNvbg0KIHdoaWxlIHJlbGF5aW5nIHRoZSBCWUUsIGl0IGRl ZmluaXRlbHkgd291bGQgYmUgcG9zc2libGUgc2luY2UgYm90aCBhcmUgY2FsbGVkIHBhcnRpZXMu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JZiB0aGUg4oCcY2Fs bGluZyBwYXJ0eeKAnSBnZXRzIHJlcGxhY2VkIGJlZm9yZSDigJxjYWxsZWQgcGFydHnigJ0gc2Vu ZHMgQllFIHdpdGggNjY2LCB3aG8gc2hvdWxkIGJlIGZsYWdnZWQ6IDEpIGNhbGxpbmcgcGFydHkg aW5kaWNhdGVkIHdpdGhpbiBvcmlnaW5hbCBJTlZJVEUgb3IgMikNCiBuZXdlc3QgY29ubmVjdGVk IHBhcnR5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhhbmtz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5CcmV0dDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBIZW5uaW5nIFNjaHVsenJpbm5lIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdiI+SGVubmlu Zy5TY2h1bHpyaW5uZUBmY2MuZ292PC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwg SmFudWFyeSAxMiwgMjAxNyAzOjMxIFBNPGJyPg0KPGI+VG86PC9iPiBCcmV0dCBUYXRlOyA8YSBo cmVmPSJtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iPm1hcmlhbm5lLm1vaGFsaUBv cmFuZ2UuY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3Jl QGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogW3NpcGNvcmVdIENvbW1lbnRz IG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zdGF0dXMtdW53YW50ZWQtMDE8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+SeKAmW0gYWZyYWlkIEkgZG9u4oCZdCBxdWl0ZSBmb2xsb3cgd2hhdCB0ZXh0IHlvdSBh cmUgc3VnZ2VzdGluZyBhbmQgSeKAmW0gc3VzcGVjdGluZyB3ZeKAmXJlIHdlbGwgaW50byB0aGUg d2VlZHMgYXQgdGhpcyBwb2ludC4gTXkgZ2VuZXJhbCBpbmNsaW5hdGlvbiBpcyB0byBvbmx5IHN0 YXRlDQogdGhpbmdzIHdoZXJlIDY2NiBkaWZmZXJzIGZyb20gNnh4IGhhbmRsaW5nLCByYXRoZXIg dGhhbiB0cnkgdG8gY2FwdHVyZSBhbGwgcG9zc2libGUgc3RhdHVzIGNvZGUgaXNzdWVzIHRoYXQg YXJlIGdlbmVyaWMgdG8gKG1vc3QpIDZ4eCBjb2Rlcy4gVGhpcyBhdm9pZHMgY3JlYXRpbmcgaW5h ZHZlcnRlbnQgY29udHJhZGljdGlvbnMgb3IgdGhlIG5lZWQgdG8gdXBkYXRlIHRoZSBkb2N1bWVu dCBzaG91bGQgdGhlcmUgYmUgY2hhbmdlcyBpbiB0aGUgZ2VuZXJpYw0KIGhhbmRsaW5nLiBJbiBv dGhlciB3b3JkcywgNjY2IHNob3VsZCBiZSB0cmVhdGVkIGxpa2UgNnh4IHVubGVzcyBvdGhlcndp c2Ugbm90ZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaHVz LCBjYW4geW91IHByb3ZpZGUgc3VnZ2VzdGVkIHRleHQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5J4oCZbSBub3Qgc3VyZSB3aHkgdGhlIGNhbGxpbmcgcGFydHkg d291bGQgaW5kaWNhdGUgNjY2LiBBZnRlciByZWNlaXZpbmcgYSByZS1JTlZJVEU/IEluIHJlc3Bv bnNlIHRvIGEgQllFPyBJIGFkbWl0IHRoYXQgSSBsYWNrIHRoZSBpbWFnaW5hdGlvbiBhcyB0byBo b3cgdGhpcyB3b3VsZA0KIG9jY3VyIGFuZCB3aHkgdGhpcyB3b3VsZCBjYXVzZSBhbnl0aGluZyBv dGhlciB0aGFuIHdoYXQgd291bGQgaGFwcGVuIGZvciBhIGdlbmVyaWMgNnh4IHJlc3BvbnNlIGlu IHRob3NlIGNpcmN1bXN0YW5jZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5TdHJldGNoaW5nIHRoZSBpbWFnaW5hdGlvbiwgSSBjb3VsZCBpbWFnaW5lIHRoZSBj YXNlIHdoZXJlIEnigJltIG1pc2xlZCBpbnRvIGRpYWxpbmcgYSBudW1iZXIgKGUuZy4sIGFzIHBh cnQgb2YgYSBzcGFtIGVtYWlsKSB0aGF0IHR1cm5zIG91dCB0byBiZSBhIHJvYm90IHBlZGRsaW5n DQogdGltZSBzaGFyZXMuIEkgY291bGQgc2VuZCBhIEJZRSwgd2l0aCBhIDY2NiBSZWFzb24uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JcyB0aGF0IHRoZSBjYXNl IHlvdSBoYXZlIGluIG1pbmQ/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj5IZW5uaW5nPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBC cmV0dCBUYXRlIFs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+bWFpbHRvOmJyZXR0QGJyb2Fkc29mdC5jb208L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgSmFudWFyeSAwNiwgMjAx NyAxMjozMiBQTTxicj4NCjxiPlRvOjwvYj4gPC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYXJpYW5u ZS5tb2hhbGlAb3JhbmdlLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5tYXJpYW5uZS5tb2hhbGlAb3Jh bmdlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj47IEhlbm5pbmcgU2NodWx6cmlubmUg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86SGVubmluZy5TY2h1bHpyaW5uZUBmY2MuZ292Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkhlbm5pbmcuU2NodWx6cmlubmVAZmNjLmdvdjwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7Ow0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnNpcGNvcmVAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2lwY29yZV0gQ29tbWVudHMgb24g ZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMTwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoZSBkcmFm dCBwb3RlbnRpYWxseSBzaG91bGQgYWxzbyBkaXNjdXNzIHRoZSBwb3RlbnRpYWwgZm9yIHRoZSBj b25uZWN0ZWQgcGFydHkgdG8gY2hhbmdlIG1pZC1kaWFsb2cgMSkgd2l0aG91dCBpdCBiZWluZyBj b21tdW5pY2F0ZWQgYW5kIDIpIHdpdGggaXQgYmVpbmcgY29tbXVuaWNhdGUNCiBieSBSRkMgNDkx NiwgUkZDIDU4NzYsIGV0IGNldGVyYS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkZyb20gYSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBwZXJzcGVjdGl2ZSwgdGhl IHdyb25nIHBhcnR5IG1pZ2h0IGJlIGZsYWdnZWQgYnkgdGhlIDY2NiB3aGVuIHRoZSBjb25uZWN0 ZWQgcGFydHkgY2hhbmdlcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoZSBkcmFmdCBzaG91bGQgcG90ZW50aWFsbHkgYWxzbyBkaXNjdXNzIHRoZSBwb3RlbnRp YWwgZm9yIGNhbGxpbmcgcGFydHkgaW5kaWNhdGluZyA2NjYuJm5ic3A7IE90aGVyIHRoYW4gYSB3 YXkgdG8gYXR0YWNrIHNvbWVvbmUsIEnigJltIG5vdCBzdXJlIGlmIGFyZSBhbnkgM1BDQywgdHJh bnNmZXIsDQogb3Igb3RoZXIgc2VydmljZSBzaXR1YXRpb25zIHdoZXJlIGl0IG1pZ2h0IGFjdHVh bGx5IGJlIGFwcHJvcHJpYXRlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4NCjwv c3Bhbj48YSBocmVmPSJtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5nZS5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5tYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2Vy aWYiPiBbbWFpbHRvOjwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWFyaWFubmUubW9oYWxpQG9yYW5n ZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rh aG9tYSZxdW90OyxzYW5zLXNlcmlmIj5tYXJpYW5uZS5tb2hhbGlAb3JhbmdlLmNvbTwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIEphbnVhcnkg MDYsIDIwMTcgMTA6MjggQU08YnI+DQo8Yj5Ubzo8L2I+IEhlbm5pbmcgU2NodWx6cmlubmU7IEFz dmVyZW4sIFRvbGdhOyBCcmV0dCBUYXRlOyA8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5zaXBjb3JlQGlldGYub3JnPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDss c2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc2lwY29yZV0gQ29tbWVudHMg b24gZHJhZnQtaWV0Zi1zaXBjb3JlLXN0YXR1cy11bndhbnRlZC0wMTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlRvIHJl ZmxlY3QgdGhlIHF1ZXN0aW9uIG9mIHRoZSBpbnRlcnByZXRhdGlvbiBvZiB0aGUgNjY2IHJlc3Bv bnNlIGludGVycHJldGF0aW9uIHdoZW4gdGhlIGNhbGxlciBoYXMgc2V2ZXJhbCBpZGVudGl0aWVz IHVzZWQgZm9yIHRoaXMgY2FsbCAoaWUuIEZyb20gYW5kIFAtQXNzZXJ0ZWQtSWRlbnRpdHkgYXJl IGRpZmZlcmVudCkgb3IgY2FsbCBmb3J3YXJkaW5nL2NhbGwNCiB0cmFuc2ZlciB1c2UgY2FzZXMg Zm9yIHdoaWNoIGl0IGhhcyB0byBiZSBkaXNjdXNzZWQgd2hpY2ggcGFydHkgc2hvdWxkIGJlIGNv bnNpZGVyZWQgaGFzIGEgZnJhdWR1bGVudCAoaWUuIHRoZSBjYWxsaW5nIHBhcnR5IG9yIHRoZSBk aXZlcnRpbmcgcGFydHkgb3IgYm90aCA/KSA7IEkgcHJvcG9zZSB0byBhZGQgdGhlIGZvbGxvd2lu ZyB0ZXh0Ojwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5UaGlzIGRvY3VtZW50IGRlZmluZXMgYSBtZWNoYW5p c20gYnkgd2hpY2ggYSBjYWxsZWQgcGFydHkgY2FuIHJlamVjdCBhbiB1bndhbnRlZCBjYWxsIHdp dGhvdXQgY29uc2lkZXJhdGlvbiBvZiB0aGUgY2FsbGluZyBwYXJ0eSBpZGVudGlmaWNhdGlvbiB0 aGF0IHJlbWFpbiB0byB0aGUgc2VydmljZSBwcm92aWRlciBwb2xpY3kuIEluZGVlZCwgdGhlIGNh bGxpbmcNCiBwYXJ0eSBpZGVudGl0eSBtYXkgYmUgcmVmbGVjdGVkIGluIGRpZmZlcmVudCB3YXkg Zm9yIGEgZGlyZWN0IGNhbGwgb3IgYWZ0ZXIgYSBkaXZlcnRpbmcgc2VydmljZSBpbiBQLUFzc2Vy dGVkLUlkZW50aXR5LCBGcm9tLCBIaXN0b3J5LUluZm8gb3IgYW55IGNvbmN1cnJlbnQgaGVhZGVy IGZpZWxkIHRoYXQgY2FuIGJlIHByZXNlbnQgYXQgdGhlIHNhbWUgdGltZSBpbiBhIFNJUCBtZXNz YWdlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+VGhvc2UgcXVl c3Rpb25zIGFyZSByZWFsIGlzc3VlcyBmb3Igb3BlcmF0b3JzIGFuZCBpbXBsZW1lbnRvcnMgYW5k IHRoZXkgYXJlIGEgd2Vha25lc3MgdGhhdCBmcmF1ZHVsZW50IGNhbGxlcnMgY291bGQgdXNlIHRv IGJ5cGFzcyB0aGUgbWVjaGFuaXNtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdCI+QlIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPk1hcmlhbm5lPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwLjVwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwcmU+Jm5ic3A7PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN2PR03MB2350656220B7D65128F2952EB27F0SN2PR03MB2350namp_-- From nobody Wed Jan 18 06:05:10 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C80EC1297BE for ; Wed, 18 Jan 2017 06:05:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNe5y9pm05SS for ; Wed, 18 Jan 2017 06:04:59 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0b-001d8301.pphosted.com [67.231.157.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E2D3129785 for ; Wed, 18 Jan 2017 06:04:59 -0800 (PST) Received: from pps.filterd (m0085114.ppops.net [127.0.0.1]) by mx0b-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0IE4YA4015641 for ; Wed, 18 Jan 2017 09:04:58 -0500 Received: from mail-lf0-f70.google.com (mail-lf0-f70.google.com [209.85.215.70]) by mx0b-001d8301.pphosted.com with ESMTP id 27ydk289b6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 18 Jan 2017 09:04:58 -0500 Received: by mail-lf0-f70.google.com with SMTP id k86so6440481lfi.4 for ; Wed, 18 Jan 2017 06:04:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=iHHnZ05bujcmKhW0271r1XcdRIy5r4S4ZEPgAl7ufjE=; b=yhO+IwGoCGxh6GpMo0YcBzaX1IzCcfUhMK5ANdmDdwWFBbz3JY44bzfS34NjyVtV67 xdPKJUGzldVZx9XsYHJi9qb0q5Lj6LFJNwCaCR+g/tqACNdfTHRr3UwRwwxwXW7K/wz5 eQNccHY6aCUYHoKBo81h2JzDJHVNJGaOmJm08XYNjwT6dEL90Q28oySUGJcCcjnsL/j2 hnNvCVzp0kAoKRBurIxNc3DH5V/AohhalJ5pRqPLyMv8haI5l/QAzj5l8F4Qmam1fDQX NDrZbLUePzQQBg7faYI8f4cJgAjyIFsWlihDf8LU9Hoe05KE21Dx/WlAp9jugXkNuZBw BXGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=iHHnZ05bujcmKhW0271r1XcdRIy5r4S4ZEPgAl7ufjE=; b=LZgFp7ow+Aon53CSw4t3WC3tE4YhZjD7GqfL/PpHqrUlOlN89KrfVBjjWivrfnBbT2 8M1uKODPBZbLgTIAvKfKt0SSCEmjadU9mfWQmM64R2IHzVxTZUv+Mw1PRkMCTFl+SrlP KRkbzElxc252yinS9lfIqACaz2k9aqr6aEDDGcMYVOwA6+Sa7XO7wWLYlEQgiLYgrSuU iHj534143OiV8+znzmFczPgIqkcMjvz6shQMhKwJqJANf6mWqWyroVbKPXIWynvQPHz5 OG4FiCsvjJi8NNuv6kaMf42Hb4sADKpLAWojyBMtRh1qIml/P0KAFkRoWzDr7wzoNqX8 ZX3w== X-Gm-Message-State: AIkVDXJwZdxob5z49hBlT2w+sr5H1TyK3oTC6eiqYSzUvzeBEQfjeErQYasVeN9hjERkMZw5Hnr04Omkjm5O9z+Is7eaCmT9qOYnowY+5qJlGxZ3bRDdc8Ootnzj4JsVbFbo+VpgB0PBl3f6 X-Received: by 10.25.15.199 with SMTP id 68mr1104421lfp.53.1484748296345; Wed, 18 Jan 2017 06:04:56 -0800 (PST) X-Received: by 10.25.15.199 with SMTP id 68mr1104412lfp.53.1484748296083; Wed, 18 Jan 2017 06:04:56 -0800 (PST) From: Brett Tate References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6CXui9W95VUBH0jmMtoymegvUCwBsOs1NAhVOAK4CExl1IgI+oy+kn7hqdnA= Date: Wed, 18 Jan 2017 09:04:54 -0500 Message-ID: To: "Asveren, Tolga" , sipcore@ietf.org Content-Type: multipart/alternative; boundary=001a113fa204c4eead05465ee68e X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-18_07:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:05:02 -0000 --001a113fa204c4eead05465ee68e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Sometimes those left within the call dialed no digits. For instance within RFC 5589 section 6.1=E2=80=99s basic transfer, the transferor could have or= iginally called transferee. If transfer target releases call with BYE containing 666, the transferee may or may not be an innocent victim being flagged. The same could be true concerning section 7.3=E2=80=99s attended transfer; = and there is potentially also race condition exposure concerning desire to send BYE with 666 on dialog 1 but replaces occurs which causes it to be sent on dialog 2. *From:* Asveren, Tolga [mailto:tasveren@sonusnet.com] *Sent:* Wednesday, January 18, 2017 6:40 AM *To:* Henning Schulzrinne; Brett Tate; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Looking to this on a =E2=80=9Cphilosophical=E2=80=9D level: I don=E2=80=99t think the right approach is to use calling/called definitio= ns as used in technical specifications. In the context of =E2=80=9C666 unwanted= =E2=80=9D, I am the =E2=80=9Ccaller=E2=80=9D if I dial a number. I am the =E2=80=9Ccalled= =E2=80=9D if I receive the call (meaning my UE alerts me) , and this is where this new response code comes into play. It doesn=E2=80=99t matter what (possibly complex) call scenario = caused alerting. I don=E2=80=99t think there is an issue pertaining to draft-ietf-sipcore-status-unwanted on this topic, at least not on a level where text needs to be added/changed. Thanks, Tolga *From:* sipcore [mailto:sipcore-bounces@ietf.org = ] *On Behalf Of *Henning Schulzrinne *Sent:* Tuesday, January 17, 2017 6:05 PM *To:* Brett Tate ; sipcore@ietf.org *Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur for unwanted calls, except by accident or because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from =E2=80=9CMarrio= tt Hotels=E2=80=9D to his boss, thinking that this is about an upcoming hotel reservation, but the call turns out to be spam.) As you note, the forwarding party should not be flagged. But since it=E2=80=99s the content of the call is deemed objectionable (unw= anted) by the recipient, the goal should be to identify the party that is generating that content, even if they try to hide behind somebody else. I=E2=80=99m probably lacking imagination, but can you explain how these sce= narios would occur in the typical robocall, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties, but I=E2=80=99m not sure that=E2=80=99s what you have in mind for = the scenarios below. Is there a definable notion of the =E2=80=9Coriginal=E2=80=9D calling party= since that seems most likely to be the bad actor? Henning *From:* Brett Tate [mailto:brett@broadsoft.com ] *Sent:* Tuesday, January 17, 2017 11:37 AM *To:* Henning Schulzrinne ; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning the likelihood, I assume that it would depend upon if there is a convenience, business, or mischievous reason to do it. As I=E2=80=99ve mentioned, I find the concept of who gets impacted by 666 s= omewhat vague within the draft because of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity. However, I assume that the draft can proceed without needing to clarify that stuff. If anyone knows the answers to the following, please let me know. If the "calling party" gets replaced before "called party" sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party? Should the connected party be flagged if the "calling party" sends BYE with 666? Should the call forwarding party be flagged when flagging the "calling party"? I assume no since potentially innocent bystander. Should the call transferring party be flagged when flagging the "calling party"? Thanks, Brett --001a113fa204c4eead05465ee68e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

Sometimes those left = within the call dialed no digits.=C2=A0 For instance within RFC 5589 sectio= n 6.1=E2=80=99s basic transfer, the transferor could have originally called= transferee.=C2=A0 If transfer target releases call with BYE containing 666= , the transferee may or may not be an innocent victim being flagged.=C2=A0 = The same could be true concerning section 7.3=E2=80=99s attended transfer; = and there is potentially also race condition exposure concerning desire to = send BYE with 666 on dialog 1 but replaces occurs which causes it to be sen= t on dialog 2.

= =C2=A0

=C2=A0

From: Asveren, Tolga [mailto:tasveren@sonusnet.com]
Sent: Wednesday, January 1= 8, 2017 6:40 AM
To: Henning Schulzrinne; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcor= e] Comments on draft-ietf-sipcore-status-unwanted-01

=

=C2=A0

Lookin= g to this on a =E2=80=9Cphilosophical=E2=80=9D level:

=C2=A0

I don=E2=80=99t think the right approach is to use calling/called defini= tions as used in technical specifications. In the context of =E2=80=9C666 u= nwanted=E2=80=9D, I am the =E2=80=9Ccaller=E2=80=9D if I dial a number. I a= m the =E2=80=9Ccalled=E2=80=9D if I receive the call (meaning my UE alerts = me) , and this is where this new response code comes into play. It doesn=E2= =80=99t matter what (possibly complex) call scenario caused alerting.

=C2=A0

I don=E2=80=99t think there is an issue pertaining to d= raft-ietf-sipcore-status-unwanted on this topic, at least not on a level wh= ere text needs to be added/changed.

=C2=A0

Thanks,<= /p>

Tolga

=C2=A0

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf= Of Henning Schulzrinne
Sent: Tuesday, January 17, 2017 6:05 = PM
To: Brett Tate <bret= t@broadsoft.com>; sipcore@ietf.o= rg
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-stat= us-unwanted-01

=C2=A0

As I mentioned before, it seem= s somewhat unlikely that 3PCC scenarios occur for unwanted calls, except by= accident or because of forward-on-busy or forward-on-vacation. (Admin assi= stant transfers a call from =E2=80=9CMarriott Hotels=E2=80=9D to his boss, = thinking that this is about an upcoming hotel reservation, but the call tur= ns out to be spam.) As you note, the forwarding party should not be flagged= .

=C2=A0=

But since it=E2=80=99= s the content of the call is deemed objectionable (unwanted) by the recipie= nt, the goal should be to identify the party that is generating that conten= t, even if they try to hide behind somebody else.

=C2=A0

= I=E2=80=99m probably lacking imagination, but ca= n you explain how these scenarios would occur in the typical robocall, beyo= nd the accidental forwarding case above? I can see incentives for bad actor= s to hide behind innocent third parties, but I=E2=80=99m not sure that=E2= =80=99s what you have in mind for the scenarios below.

=C2=A0

Is there a definable notion of the =E2=80= =9Coriginal=E2=80=9D calling party since that seems most likely to be the b= ad actor?

=C2= =A0

Henning

=C2=A0

<= div>

From: Brett Tate [mailto:brett@broa= dsoft.com]
Sent: Tuesday, January 17, 2017 11:37 AM
To= : Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; = sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-iet= f-sipcore-status-unwanted-01

= =C2=A0

Hi,

<= p class=3D"MsoNormal">=C2=A0

Concerning the likelihood, I assu= me that it would depend upon if there is a convenience, business, or mischi= evous reason to do it.

=C2=A0

= As I=E2=80=99ve mentioned, I find the concept of who gets impacted by 666 s= omewhat vague within the draft because of the variety of call services (3PC= C, call forwarding, transfer, et cetera) and ways to update the connected i= dentity.=C2=A0 However, I assume that the draft can proceed without needing= to clarify that stuff.

=C2=A0

If anyone knows the answers to the following, please let me know.

=C2=A0

If the "calling party"= ; gets replaced before "called party" sends BYE with 666, who sho= uld be flagged: 1) calling party indicated within original INVITE or 2) new= est connected party?

=C2=A0

Sh= ould the connected party be flagged if the "calling party" sends = BYE with 666?

= =C2=A0

Should t= he call forwarding party be flagged when flagging the "calling party&q= uot;?=C2=A0 I assume no since potentially innocent bystander.

=C2=A0

Should the call transferring party b= e flagged when flagging the "calling party"?

=C2=A0

Thanks,

Brett

--001a113fa204c4eead05465ee68e-- From nobody Wed Jan 18 08:04:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168B6129497 for ; Wed, 18 Jan 2017 08:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8s6ymJSy5md for ; Wed, 18 Jan 2017 08:04:39 -0800 (PST) Received: from alum-mailsec-scanner-3.mit.edu (alum-mailsec-scanner-3.mit.edu [18.7.68.14]) by ietfa.amsl.com (Postfix) with ESMTP id DC629129456 for ; Wed, 18 Jan 2017 08:04:38 -0800 (PST) X-AuditID: 1207440e-059ff70000000a39-69-587f92153ed3 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B0.15.02617.5129F785; Wed, 18 Jan 2017 11:04:38 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0IG4axc031217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 18 Jan 2017 11:04:37 -0500 To: "Asveren, Tolga" , Henning Schulzrinne , SIPCORE References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> From: Paul Kyzivat Message-ID: <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> Date: Wed, 18 Jan 2017 11:04:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrIIsWRmVeSWpSXmKPExsUixO6iqCs2qT7C4PV1IYufR3azWnz9sYnN YnbneyYHZo/bt9+weSxZ8pPJ49Ln/+wBzFFcNimpOZllqUX6dglcGV9WL2MqmM5fsWvqP/YG xm/cXYycHBICJhJLbsxh7WLk4hASuMwocercNWYI5zqTxNEZ/ewgVcICDhKNWw6ygyREBHoZ Jb71XGeBqFrBJHFq9WJWkCo2AS2JOYf+s4DYvAL2Eu3HdoN1swioSpw4uZwNxBYVSJN4cHIr I0SNoMTJmU/A6jkFYiUeXHoNFmcWsJW4M3c3M4QtL9G8dTbzBEa+WUhaZiEpm4WkbAEj8ypG ucSc0lzd3MTMnOLUZN3i5MS8vNQiXWO93MwSvdSU0k2MkJDk28HYvl7mEKMAB6MSD29HUX2E EGtiWXFl7iFGSQ4mJVFelx6gEF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHe+b1AOd6UxMqq1KJ8 mJQ0B4uSOK/aEnU/IYH0xJLU7NTUgtQimKwMB4eSBG/ERKBGwaLU9NSKtMycEoQ0EwcnyHAe oOENE0CGFxck5hZnpkPkTzEqSonzaoAkBEASGaV5cL2wlPGKURzoFWHeYpAVPMB0A9f9Cmgw E9BgK2WwwSWJCCmpBsaovpMNE29tkHoptuZrZNPTHc7PjljObjw5z29lvdS/o0dPF3/jv7Qr 6FDilLs7YiaU8tR56YXur510+6LkHbeKNqVtZ8K/y7u9e9SZNTPlbcU9vf3X7b8enbKYpSrg eWlN++PkH+y2Pbtigk49u6Eucf7Yup3bVq2N4Z+iuqhh74H9T3cFplsFKLEUZyQaajEXFScC ANgfzkb0AgAA Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 16:04:45 -0000 On 1/18/17 5:13 AM, Asveren, Tolga wrote: > How likely it is that that Bob’s UE generates 180 but did not “ring” > before such an evil CANCEL is received? Hard to say. But this sort of behavior is not just theoretical. I get calls like this nearly every day. Sometimes I hear (1) ring, sometimes none. The charitable interpretation is that someone dialed a wrong number and realized immediately. But in my experience this is almost never the cause. I often follow up these, by checking the call log and googling the number. Usually I find many reports of bad behavior from that number. > The entity making use of Reason header, e .g. an Application Server > managing devices at a call center, can use Contact/Via headers to > determine the origin of CANCEL (well, unless there is a B2BUA > in-between; but then just as a note: nowadays it is not uncommon that > some B2BUAs can relay Via headers between two legs). I presume that typically the entity making use of the reason header will be the called UAS and/or the home proxy for the callee's AoR (probably the callee's SP.) The use case mentioned in this thread is by the UAS, when managing its own log of incoming calls. It is unclear to me whether common deployments would preserve the Via headers that would allow deciphering whether the cancel was due to forking or an overt action by the UAC. > Overall, I don’t think there is something here which should cause us to > lose sleep. I'm not losing sleep over it. But the bad actors are not going to go away quietly once these new mechanisms are put in place. They will certainly seek out holes that can be exploited. So there is value in trying to close as many potential holes as we can. In any case I didn't see any obvious fix for this. But the consequence is the need to be careful not to ascribe too much meaning to the receipt of the 666 in cancel. Thanks, Paul From nobody Wed Jan 18 09:39:46 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9698A129512 for ; Wed, 18 Jan 2017 09:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.42 X-Spam-Level: X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tHNBqT_doFCx for ; Wed, 18 Jan 2017 09:39:39 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC068129546 for ; Wed, 18 Jan 2017 09:39:38 -0800 (PST) Received: from pps.filterd (m0103509.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0IHYksL009714 for ; Wed, 18 Jan 2017 12:39:38 -0500 Received: from mail-lf0-f72.google.com (mail-lf0-f72.google.com [209.85.215.72]) by mx0a-001d8301.pphosted.com with ESMTP id 27ye5tgtwd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Wed, 18 Jan 2017 12:39:38 -0500 Received: by mail-lf0-f72.google.com with SMTP id h65so8936907lfi.1 for ; Wed, 18 Jan 2017 09:39:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=CrGSVetFnu8jugHVPWhwgCoL8T3IdQU5eT/nC6bX5kc=; b=CneAad31DpwLtM2l2maUjHfaOvCTKpkd0UpdK501ifkthh8qf/2dKmW/HcnkCIRjCe ZvwWPpeIjgOOYzFhOFH5T31HdwpdY0LxgoEJfqAN4etG9X1CoHyotco7XvWnhCstx0JE jLiPqBjHtXVTN02qfs1RB8l0uL8CgqtMvHsY6kW28JHuwgDL7Tpptpkl2cWa4lcuu+PW umjKLAOIOexmwu7GFPWguI6vSltcLc1jt/qtZIHbNfyRl6f4YEbpDcp+m0mCmwcLIa90 Ms1xYtSikOijPtG+MDuuy7eXRMcT0zPaNQm3ylvAzoG/OMGNi1Kq+xM7GgRYn4Kdhswv hy8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=CrGSVetFnu8jugHVPWhwgCoL8T3IdQU5eT/nC6bX5kc=; b=PoAUkl+7Frh8zIW0jRd+xEfsDLXPgXssg/7MKQvN49o8IGWqcY2mLLDPyUGzPZ3SkQ xbMbROcJ48YyrFtGwsD2rwL8nk8S7GL4me2TV2QciWsv5tm0h6cemZYYCCBYXTT5D9RK x/FG/cFLIHLzZioKhYPeAgvE5X74w2JGu3ZC4YsaTZE8l6SboOdu2lJ0sTl18wUAz0QD IeZyDF9ADU430qwmCGuV/fF/Oh0YpSOvU4bMd9JB9y7g4NAvdVww075K4I9EfIKOiD12 lX6Sa58Xs0nQzkEGcAZeGd/IpRWmjmXfpJ6WHxYea/U6u3qj0dfbYS2UMf7otD9Jaxib 0SEA== X-Gm-Message-State: AIkVDXJ8KPL3Uc7/ge7T5Kn2GZklBqH1mDZeGgU/4fRMFtd7PSiqSGWgSaWA7ji4prYg2a5ayCuJYPahlTUFQo88IGghkrZkRXo1i90W9WuhpuFCSgkRYj09dPcSV3smNqZVF5mIbOrW3GGn X-Received: by 10.46.84.74 with SMTP id y10mr2224097ljd.40.1484761175129; Wed, 18 Jan 2017 09:39:35 -0800 (PST) X-Received: by 10.46.84.74 with SMTP id y10mr2224085ljd.40.1484761174796; Wed, 18 Jan 2017 09:39:34 -0800 (PST) From: Brett Tate References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ6CXui9W95VUBH0jmMtoymegvUCwBsOs1NAhVOAK4CExl1Ip/KcCEg Date: Wed, 18 Jan 2017 12:39:33 -0500 Message-ID: <868dcc0b0065d2ec06b3f796f961f481@mail.gmail.com> To: Henning Schulzrinne , sipcore@ietf.org Content-Type: multipart/alternative; boundary=f403045fb4ce667dac054661e663 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-18_10:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 17:39:42 -0000 --f403045fb4ce667dac054661e663 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I=E2=80=99m not sure if there is a definable notion of "original" calling p= arty. I=E2=80=99m also not sure if BYE 666 should impact connected party or origi= nal calling party. My questions were not necessarily associated with a typical robocall. They were just questions to help me/others understand who should, should not, or unintentionally might be flagged when receive the 666 within response or BYE. For instance, I=E2=80=99m working remotely at 9999 and missed a call from 8= 888. I use a 3PCC client to click-to-call number stored for missed call. The controller first uses 7777 (calling party) to call my remote number 9999; it then reconnects me so calling 8888. After they answer, I realize that it was a spam call. I release the call with BYE 666. Based upon the draft, I=E2=80=99m concerned that 7777 might unintentionally only/also get = flagged while attempting to flag 8888. However using a similar example, 3PCC fraudster robocaller (7777) first attempts to reach a live fish (9999). After fish answers, 3PCC reconnects fish to the fisherman (8888). Fish releases the call with BYE 666. This is a situation where it would be desirable to flag 7777 while attempting to flag 8888. Another example of 3PCC is the potential to send INVITE to answer an incoming call. The called party is notified of an incoming call. The called party sends INVITE to controller to answer the incoming unwanted call. The called party sends BYE 666 to controller (unless something prevents it). The controller can handle the 666 as desired (even though appears within dialog to be from caller) and potentially relay it. As an fyi, I don=E2=80=99t want to slow the draft progression. Thus unless= others think good enough as-is, adding something like the following to section 4 or 6 might be adequate. "Some call services such as 3PCC [RFC3725] and call transfer increase the complexity of identifying who (if anyone) should be impacted by the receipt of 666 within BYE. Such services might causes the wrong party to be flagged or prevent flagging the desired party." Thanks, Brett *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Tuesday, January 17, 2017 6:05 PM *To:* Brett Tate; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur for unwanted calls, except by accident or because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from =E2=80=9CMarrio= tt Hotels=E2=80=9D to his boss, thinking that this is about an upcoming hotel reservation, but the call turns out to be spam.) As you note, the forwarding party should not be flagged. But since it=E2=80=99s the content of the call is deemed objectionable (unw= anted) by the recipient, the goal should be to identify the party that is generating that content, even if they try to hide behind somebody else. I=E2=80=99m probably lacking imagination, but can you explain how these sce= narios would occur in the typical robocall, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties, but I=E2=80=99m not sure that=E2=80=99s what you have in mind for = the scenarios below. Is there a definable notion of the =E2=80=9Coriginal=E2=80=9D calling party= since that seems most likely to be the bad actor? Henning *From:* Brett Tate [mailto:brett@broadsoft.com ] *Sent:* Tuesday, January 17, 2017 11:37 AM *To:* Henning Schulzrinne ; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning the likelihood, I assume that it would depend upon if there is a convenience, business, or mischievous reason to do it. As I=E2=80=99ve mentioned, I find the concept of who gets impacted by 666 s= omewhat vague within the draft because of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity. However, I assume that the draft can proceed without needing to clarify that stuff. If anyone knows the answers to the following, please let me know. If the "calling party" gets replaced before "called party" sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party? Should the connected party be flagged if the "calling party" sends BYE with 666? Should the call forwarding party be flagged when flagging the "calling party"? I assume no since potentially innocent bystander. Should the call transferring party be flagged when flagging the "calling party"? Thanks, Brett *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Sunday, January 15, 2017 3:49 PM *To:* Brett Tate; sipcore@ietf.org *Subject:* Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 How likely is any of this going to happen for unwanted robocalls? For figure 4, the one scenario I can think of is the "evil" controller leveraging a service A to call B, and B 666'ing the call or sending a BYE with Reason(666). But that would seem to be pretty standard, even if the final recipient of the 666 or BYE is A (who is likely to ignore it). I think it would help if you could identify the roles of the third parties and see if that causes the recipient of the unwanted call to do something that's harmful to innocent bystanders. Henning ------------------------------ *From:* Brett Tate *Sent:* Friday, January 13, 2017 3:48:58 PM *To:* Henning Schulzrinne; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning calling party sending BYE with 666, I just thought that it potentially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a =E2=80=9Ccalling par= ty=E2=80=9D might get replaced by a =E2=80=9Ccalled party=E2=80=9D. Thus if the contro= ller doesn=E2=80=99t strip the Reason while relaying the BYE, it definitely would be possible since both are called parties. If the =E2=80=9Ccalling party=E2=80=9D gets replaced before =E2=80=9Ccalled= party=E2=80=9D sends BYE with 666, who should be flagged: 1) calling party indicated within original INVITE or 2) newest connected party? Thanks, Brett *From:* Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] *Sent:* Thursday, January 12, 2017 3:31 PM *To:* Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I=E2=80=99m afraid I don=E2=80=99t quite follow what text you are suggestin= g and I=E2=80=99m suspecting we=E2=80=99re well into the weeds at this point. My general incl= ination is to only state things where 666 differs from 6xx handling, rather than try to capture all possible status code issues that are generic to (most) 6xx codes. This avoids creating inadvertent contradictions or the need to update the document should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I=E2=80=99m not sure why the calling party would indicate 666. After receiv= ing a re-INVITE? In response to a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I=E2=80=99m misl= ed into dialing a number (e.g., as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning *From:* Brett Tate [mailto:brett@broadsoft.com ] *Sent:* Friday, January 06, 2017 12:32 PM *To:* marianne.mohali@orange.com; Henning Schulzrinne < Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected party to change mid-dialog 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagged by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party indicating 666. Other than a way to attack someone, I=E2=80=99m not sure i= f are any 3PCC, transfer, or other service situations where it might actually be appropriate. *From:* marianne.mohali@orange.com [mailto:marianne.mohali@orange.com] *Sent:* Friday, January 06, 2017 10:28 AM *To:* Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org *Subject:* RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpretation when the caller has several identities used for this call (ie. From and P-Asserted-Identity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be considered has a fraudulent (ie. the calling party or the diverting party or both ?) ; I propose to add the following text: This document defines a mechanism by which a called party can reject an unwanted call without consideration of the calling party identification that remain to the service provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or after a diverting service in P-Asserted-Identity, From, History-Info or any concurrent header field that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --f403045fb4ce667dac054661e663 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi= ,

=C2=A0=

I=E2=80=99m not sure = if there is a definable notion of "original" calling party.=C2=A0= I=E2=80=99m also not sure if BYE 666 should impact connected party or orig= inal calling party.

=C2=A0

My = questions were not necessarily associated with a typical robocall.=C2=A0 Th= ey were just questions to help me/others understand who should, should not,= or unintentionally might be flagged when receive the 666 within response o= r BYE.

=C2=A0

For instance, I= =E2=80=99m working remotely at 9999 and missed a call from 8888.=C2=A0 I us= e a 3PCC client to click-to-call number stored for missed call.=C2=A0 The c= ontroller first uses 7777 (calling party) to call my remote number 9999; it= then reconnects me so calling 8888.=C2=A0 After they answer, I realize tha= t it was a spam call.=C2=A0 I release the call with BYE 666.=C2=A0 Based up= on the draft, I=E2=80=99m concerned that 7777 might unintentionally only/al= so get flagged while attempting to flag 8888.

=C2=A0

However using a similar example, 3PCC fraudster robo= caller (7777) first attempts to reach a live fish (9999).=C2=A0 After fish = answers, 3PCC reconnects fish to the fisherman (8888).=C2=A0 Fish releases = the call with BYE 666.=C2=A0 This is a situation where it would be desirabl= e to flag 7777 while attempting to flag 8888.

=C2=A0

Another example of 3PCC is the potential to send INV= ITE to answer an incoming call.=C2=A0 The called party is notified of an in= coming call.=C2=A0 The called party sends INVITE to controller to answer th= e incoming unwanted call.=C2=A0 The called party sends BYE 666 to controlle= r (unless something prevents it).=C2=A0 The controller can handle the 666 a= s desired (even though appears within dialog to be from caller) and potenti= ally relay it.

= =C2=A0

As an fy= i, I don=E2=80=99t want to slow the draft progression.=C2=A0 Thus unless ot= hers think good enough as-is, adding something like the following to sectio= n 4 or 6 might be adequate.

=C2=A0

"Some call services such as 3PCC [RFC3725] and call transfer incr= ease the complexity of identifying who (if anyone) should be impacted by th= e receipt of 666 within BYE.=C2=A0 Such services might causes the wrong par= ty to be flagged or prevent flagging the desired party."

=C2=A0

Thanks,

Brett

=C2=A0

From: Henning Schulzrinne [m= ailto:Henning.Schulzrinne@fc= c.gov]
Sent: Tuesday, January 17, 2017 6:05 PM
To:= Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-= 01

=C2=A0

As I mentioned before, it seems somewhat u= nlikely that 3PCC scenarios occur for unwanted calls, except by accident or= because of forward-on-busy or forward-on-vacation. (Admin assistant transf= ers a call from =E2=80=9CMarriott Hotels=E2=80=9D to his boss, thinking tha= t this is about an upcoming hotel reservation, but the call turns out to be= spam.) As you note, the forwarding party should not be flagged.

=

=C2=A0

But since it=E2=80=99s the conten= t of the call is deemed objectionable (unwanted) by the recipient, the goal= should be to identify the party that is generating that content, even if t= hey try to hide behind somebody else.

=C2=A0

I=E2=80=99m probably lacking imagination, but can you expla= in how these scenarios would occur in the typical robocall, beyond the acci= dental forwarding case above? I can see incentives for bad actors to hide b= ehind innocent third parties, but I=E2=80=99m not sure that=E2=80=99s what = you have in mind for the scenarios below.

= =C2=A0

Is there a definable notion of the =E2=80=9Coriginal=E2= =80=9D calling party since that seems most likely to be the bad actor?

=C2=A0

Henning

=C2=A0

<= p class=3D"MsoNormal">From: Brett T= ate [mailto:brett@broadsoft.com]=
Sent: Tuesday, January 17, 2017 11:37 AM
To: Henning = Schulzrinne <Henning.Schu= lzrinne@fcc.gov>; sipcore@ietf.o= rg
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-stat= us-unwanted-01

=C2=A0

Hi,

=C2=A0

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">Concerning the likelihood, I assume that it would= depend upon if there is a convenience, business, or mischievous reason to = do it.

=C2=A0

As I=E2=80=99ve = mentioned, I find the concept of who gets impacted by 666 somewhat vague wi= thin the draft because of the variety of call services (3PCC, call forwardi= ng, transfer, et cetera) and ways to update the connected identity.=C2=A0 H= owever, I assume that the draft can proceed without needing to clarify that= stuff.

=C2=A0<= /span>

If anyone knows= the answers to the following, please let me know.

=C2=A0

If the "calling party" gets replaced = before "called party" sends BYE with 666, who should be flagged: = 1) calling party indicated within original INVITE or 2) newest connected pa= rty?

=C2=A0

Should the connect= ed party be flagged if the "calling party" sends BYE with 666?

=C2=A0

=

Should the call forwardin= g party be flagged when flagging the "calling party"?=C2=A0 I ass= ume no since potentially innocent bystander.

=C2=A0

Should the call transferring party be flagged when fl= agging the "calling party"?

=C2=A0

Thanks,

Brett

= =C2=A0

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent:= Sunday, January 15, 2017 3:49 PM
To: Brett Tate; sipcore@ietf.org
Subject: Re: [sipco= re] Comments on draft-ietf-sipcore-status-unwanted-01

=C2=A0

How likely is any of this going to happen for unwant= ed robocalls? For figure 4, the one scenario I can think of is the "ev= il" controller leveraging a service A to call B, and B 666'ing the= call or sending a BYE with Reason(666). But that would seem to be pretty s= tandard, even if the final recipient of the 666 or BYE is A (who is likely = to ignore it).

=C2=A0

I think it would help if you could identify th= e roles of the third parties and see if that causes the recipient of the un= wanted call to do something that's harmful to innocent bystanders.

=C2=A0

Henning

=

From: Brett Tate <brett@broadsoft.com>
Sent: Fr= iday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; sipcore@ietf.org
Subject: RE: [= sipcore] Comments on draft-ietf-sipcore-status-unwanted-01

=

=C2=A0

Hi,

=C2=A0

Concerning calling party sending BYE with 666, I just thought that = it potentially should be discussed.

=C2=A0

However, RFC 3725 figures 4 and figure 7 do show how a =E2=80= =9Ccalling party=E2=80=9D might get replaced by a =E2=80=9Ccalled party=E2= =80=9D.=C2=A0 Thus if the controller doesn=E2=80=99t strip the Reason while= relaying the BYE, it definitely would be possible since both are called pa= rties.

=C2=A0

If the =E2=80=9C= calling party=E2=80=9D gets replaced before =E2=80=9Ccalled party=E2=80=9D = sends BYE with 666, who should be flagged: 1) calling party indicated withi= n original INVITE or 2) newest connected party?

=C2=A0

Thanks,

Brett

=C2=A0

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate;= marianne.mohali@orange.com; sipcore@ietf.org
Subject:= RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=

=C2=A0

I=E2=80=99m afraid I don=E2=80=99t quite follow wha= t text you are suggesting and I=E2=80=99m suspecting we=E2=80=99re well int= o the weeds at this point. My general inclination is to only state things w= here 666 differs from 6xx handling, rather than try to capture all possible= status code issues that are generic to (most) 6xx codes. This avoids creat= ing inadvertent contradictions or the need to update the document should th= ere be changes in the generic handling. In other words, 666 should be treat= ed like 6xx unless otherwise noted.

=C2=A0

Thus, can you provide suggested text?

=C2=A0

I=E2=80=99m not sure why the calling party woul= d indicate 666. After receiving a re-INVITE? In response to a BYE? I admit = that I lack the imagination as to how this would occur and why this would c= ause anything other than what would happen for a generic 6xx response in th= ose circumstances.

=C2=A0

Stre= tching the imagination, I could imagine the case where I=E2=80=99m misled i= nto dialing a number (e.g., as part of a spam email) that turns out to be a= robot peddling time shares. I could send a BYE, with a 666 Reason.<= /p>

=C2=A0

Is that the case you have in m= ind?

=C2=A0

Henning

=

=C2=A0

From: = Brett Tate [mail= to:brett@broadsoft.com]
Sent: Friday, Ja= nuary 06, 2017 12:32 PM
To: marianne.mohali@orange.com; Henning Schulzrinne <Henning.Schulzrinne@fcc.gov&g= t;; sipcore@ietf.or= g
Subject: RE: [sipcore] Comments on draf= t-ietf-sipcore-status-unwanted-01

=C2=A0

Hi,<= /p>

=C2=A0

The draft potentially should a= lso discuss the potential for the connected party to change mid-dialog 1) w= ithout it being communicated and 2) with it being communicate by RFC 4916, = RFC 5876, et cetera.

=C2=A0

Fr= om a security considerations perspective, the wrong party might be flagged = by the 666 when the connected party changes.

=C2=A0

The draft should potentially also discuss the potenti= al for calling party indicating 666.=C2=A0 Other than a way to attack someo= ne, I=E2=80=99m not sure if are any 3PCC, transfer, or other service situat= ions where it might actually be appropriate.

=C2=A0

=C2=A0

From: marianne.mohali@orange.com= [mailto:marianne.mohali@orange.com]
Se= nt: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne= ; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [s= ipcore] Comments on draft-ietf-sipcore-status-unwanted-01

<= /div>

=C2=A0

Hi,

=C2=A0

To reflect the question of the interpretation of the 666 respon= se interpretation when the caller has several identities used for this call= (ie. From and P-Asserted-Identity are different) or call forwarding/call t= ransfer use cases for which it has to be discussed which party should be co= nsidered has a fraudulent (ie. the calling party or the diverting party or = both ?) ; I propose to add the following text:

This document defines a mechanism by = which a called party can reject an unwanted call without consideration of t= he calling party identification that remain to the service provider policy.= Indeed, the calling party identity may be reflected in different way for a= direct call or after a diverting service in P-Asserted-Identity, From, His= tory-Info or any concurrent header field that can be present at the same ti= me in a SIP message.

=C2=A0

Those questions are real issues for operators and implementors an= d they are a weakness that fraudulent callers could use to bypass the mecha= nism.

=C2= =A0

BR,

Marianne

=C2=A0

=C2=A0
--f403045fb4ce667dac054661e663-- From nobody Wed Jan 18 14:14:04 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6F01295B4 for ; Wed, 18 Jan 2017 14:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDIgHTrWalW4 for ; Wed, 18 Jan 2017 14:13:56 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D04861295B0 for ; Wed, 18 Jan 2017 14:13:55 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0IM9x2N031351; Wed, 18 Jan 2017 22:13:53 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0020.outbound.protection.outlook.com [23.103.198.20]) by mx0b-0024ed01.pphosted.com with ESMTP id 27yevv208q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Jan 2017 22:13:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xtvlHte5cg6rEs9UnWm9aHd4DqoUPEQCR3fwAkQLHhc=; b=M1vBzJHoNX1fqWb2uu94iVxJQGYgWi5VRzHeejtk2SvhF/H1kSTigotTvz0TzftEfgYnL3hXjRcXOj7rE2dL8RGeg14dEXcZ9xU8t1pr5W0g4Fb0Ti0HAmo6kFXGY5sv/cuwnshwEWEqcY2+RGN8lo0zOj6ERzrDrJilCkTLQfE= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Wed, 18 Jan 2017 22:13:50 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.013; Wed, 18 Jan 2017 22:13:50 +0000 From: Henning Schulzrinne To: Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJt3jyCDTTT21QxQfGC4OLjh1QSQABkfEPTAFvyfgAADUbgoAAnMEmAAAmIyL8= Date: Wed, 18 Jan 2017 22:13:50 +0000 Message-ID: References: , <868dcc0b0065d2ec06b3f796f961f481@mail.gmail.com> In-Reply-To: <868dcc0b0065d2ec06b3f796f961f481@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.59.13.10] x-ms-office365-filtering-correlation-id: b190bde2-e1b2-4724-0576-08d43fef483a x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:aI4UI6O9wXS1Wx7CxNXBYDC2oxEC15uTiRQ6hEpApSMGR1og+uz+EQMbRXpkYcavjv37ggwhlOW58yU8a9ana4Tsu2QOOyWuoVMyVEMAOx1bcRVvqITRlhSDUE48VAJs5R2YlRdGcESYT0gvInzZBbkIQhiMXLDRUJJMCMb0JUvgZW8GmGgm8hBjJPvCRyvm7AYRhIvHmBM9evS4aMNLTI1CA0IVrh1OEPqIvnNmeB6sA4/hm+JOQCnpMRy4KV/cNfENqdf6f4L8s+NljhTz0msx7VZFKW87GFx51nCrVuieGb4eGG8ne+gTCl0IaoZgZCOx0N3wyA5UnoM6bJspb5+XNuhccK+2tGtdSXWm/VqTxgYUMcWmylBaGe+KkQ5DZVe9jNadj60Jbda3YCdEET+mwmPKgRuCVQAUqM7axLnCnaDWgEjyC4CTbnr8bf2lwVkEm6mFv9KMbezp0Qpzzg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(199003)(189002)(377454003)(25786008)(7696004)(97736004)(81156014)(5660300001)(8676002)(81166006)(74316002)(6436002)(101416001)(77096006)(6506006)(105586002)(99286003)(122556002)(2950100002)(7736002)(66066001)(86362001)(236005)(189998001)(2900100001)(106356001)(3280700002)(229853002)(53946003)(55016002)(68736007)(107886002)(92566002)(9686003)(2906002)(19627405001)(2501003)(3660700001)(102836003)(54896002)(8936002)(3846002)(5001770100001)(54356999)(50986999)(76176999)(6116002)(38730400001)(53936002)(33656002)(93886004)(230783001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR09MB06347AAB4716D7F15C13266FEA7F0CY1PR09MB0634namp_" MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 22:13:50.4165 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-18_13:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 22:14:00 -0000 --_000_CY1PR09MB06347AAB4716D7F15C13266FEA7F0CY1PR09MB0634namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I will add the caveat to the Security Considerations, along with any other = IETF LC and IESG comments. ________________________________ From: Brett Tate Sent: Wednesday, January 18, 2017 12:39:33 PM To: Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, I=92m not sure if there is a definable notion of "original" calling party. = I=92m also not sure if BYE 666 should impact connected party or original c= alling party. My questions were not necessarily associated with a typical robocall. They= were just questions to help me/others understand who should, should not, o= r unintentionally might be flagged when receive the 666 within response or = BYE. For instance, I=92m working remotely at 9999 and missed a call from 8888. = I use a 3PCC client to click-to-call number stored for missed call. The co= ntroller first uses 7777 (calling party) to call my remote number 9999; it = then reconnects me so calling 8888. After they answer, I realize that it w= as a spam call. I release the call with BYE 666. Based upon the draft, I= =92m concerned that 7777 might unintentionally only/also get flagged while = attempting to flag 8888. However using a similar example, 3PCC fraudster robocaller (7777) first att= empts to reach a live fish (9999). After fish answers, 3PCC reconnects fis= h to the fisherman (8888). Fish releases the call with BYE 666. This is a= situation where it would be desirable to flag 7777 while attempting to fla= g 8888. Another example of 3PCC is the potential to send INVITE to answer an incomi= ng call. The called party is notified of an incoming call. The called par= ty sends INVITE to controller to answer the incoming unwanted call. The ca= lled party sends BYE 666 to controller (unless something prevents it). The= controller can handle the 666 as desired (even though appears within dialo= g to be from caller) and potentially relay it. As an fyi, I don=92t want to slow the draft progression. Thus unless other= s think good enough as-is, adding something like the following to section 4= or 6 might be adequate. "Some call services such as 3PCC [RFC3725] and call transfer increase the c= omplexity of identifying who (if anyone) should be impacted by the receipt = of 666 within BYE. Such services might causes the wrong party to be flagge= d or prevent flagging the desired party." Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Tuesday, January 17, 2017 6:05 PM To: Brett Tate; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur= for unwanted calls, except by accident or because of forward-on-busy or fo= rward-on-vacation. (Admin assistant transfers a call from =93Marriott Hotel= s=94 to his boss, thinking that this is about an upcoming hotel reservation= , but the call turns out to be spam.) As you note, the forwarding party sho= uld not be flagged. But since it=92s the content of the call is deemed objectionable (unwanted)= by the recipient, the goal should be to identify the party that is generat= ing that content, even if they try to hide behind somebody else. I=92m probably lacking imagination, but can you explain how these scenarios= would occur in the typical robocall, beyond the accidental forwarding case= above? I can see incentives for bad actors to hide behind innocent third p= arties, but I=92m not sure that=92s what you have in mind for the scenarios= below. Is there a definable notion of the =93original=94 calling party since that = seems most likely to be the bad actor? Henning From: Brett Tate [mailto:brett@broadsoft.com] Sent: Tuesday, January 17, 2017 11:37 AM To: Henning Schulzrinne >; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning the likelihood, I assume that it would depend upon if there is a= convenience, business, or mischievous reason to do it. As I=92ve mentioned, I find the concept of who gets impacted by 666 somewha= t vague within the draft because of the variety of call services (3PCC, cal= l forwarding, transfer, et cetera) and ways to update the connected identit= y. However, I assume that the draft can proceed without needing to clarify= that stuff. If anyone knows the answers to the following, please let me know. If the "calling party" gets replaced before "called party" sends BYE with 6= 66, who should be flagged: 1) calling party indicated within original INVIT= E or 2) newest connected party? Should the connected party be flagged if the "calling party" sends BYE with= 666? Should the call forwarding party be flagged when flagging the "calling part= y"? I assume no since potentially innocent bystander. Should the call transferring party be flagged when flagging the "calling pa= rty"? Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, January 15, 2017 3:49 PM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 How likely is any of this going to happen for unwanted robocalls? For figur= e 4, the one scenario I can think of is the "evil" controller leveraging a = service A to call B, and B 666'ing the call or sending a BYE with Reason(66= 6). But that would seem to be pretty standard, even if the final recipient = of the 666 or BYE is A (who is likely to ignore it). I think it would help if you could identify the roles of the third parties = and see if that causes the recipient of the unwanted call to do something t= hat's harmful to innocent bystanders. Henning ________________________________ From: Brett Tate > Sent: Friday, January 13, 2017 3:48:58 PM To: Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning calling party sending BYE with 666, I just thought that it poten= tially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a =93calling party=94 = might get replaced by a =93called party=94. Thus if the controller doesn= =92t strip the Reason while relaying the BYE, it definitely would be possib= le since both are called parties. If the =93calling party=94 gets replaced before =93called party=94 sends BY= E with 666, who should be flagged: 1) calling party indicated within origin= al INVITE or 2) newest connected party? Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 12, 2017 3:31 PM To: Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I=92m afraid I don=92t quite follow what text you are suggesting and I=92m = suspecting we=92re well into the weeds at this point. My general inclinatio= n is to only state things where 666 differs from 6xx handling, rather than = try to capture all possible status code issues that are generic to (most) 6= xx codes. This avoids creating inadvertent contradictions or the need to up= date the document should there be changes in the generic handling. In other= words, 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I=92m not sure why the calling party would indicate 666. After receiving a = re-INVITE? In response to a BYE? I admit that I lack the imagination as to = how this would occur and why this would cause anything other than what woul= d happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I=92m misled int= o dialing a number (e.g., as part of a spam email) that turns out to be a r= obot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning From: Brett Tate [mailto:brett@broadsoft.com] Sent: Friday, January 06, 2017 12:32 PM To: marianne.mohali@orange.com; Henning = Schulzrinne >; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected p= arty to change mid-dialog 1) without it being communicated and 2) with it b= eing communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagge= d by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party i= ndicating 666. Other than a way to attack someone, I=92m not sure if are a= ny 3PCC, transfer, or other service situations where it might actually be a= ppropriate. From: marianne.mohali@orange.com [mailto= :marianne.mohali@orange.com] Sent: Friday, January 06, 2017 10:28 AM To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpret= ation when the caller has several identities used for this call (ie. From a= nd P-Asserted-Identity are different) or call forwarding/call transfer use = cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I = propose to add the following text: This document defines a mechanism by which a called party can reject an unw= anted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity ma= y be reflected in different way for a direct call or after a diverting serv= ice in P-Asserted-Identity, From, History-Info or any concurrent header fie= ld that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are= a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --_000_CY1PR09MB06347AAB4716D7F15C13266FEA7F0CY1PR09MB0634namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I will add the caveat to the Security Considerations, along with any oth= er IETF LC and IESG comments.

From: Brett Tate <brett@= broadsoft.com>
Sent: Wednesday, January 18, 2017 12:39:33 PM
To: Henning Schulzrinne; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01
 

Hi,

 

I=92m not sure if there i= s a definable notion of "original" calling party.  I=92m als= o not sure if BYE 666 should impact connected party or original calling par= ty.

 

My questions were not nec= essarily associated with a typical robocall.  They were just questions= to help me/others understand who should, should not, or unintentionally might be flagged when receive the 666 within response or BYE.

 

For instance, I=92m worki= ng remotely at 9999 and missed a call from 8888.  I use a 3PCC client = to click-to-call number stored for missed call.  The controller first uses 7777 (calling party) to call my remote number 9999; it then rec= onnects me so calling 8888.  After they answer, I realize that it was = a spam call.  I release the call with BYE 666.  Based upon the dr= aft, I=92m concerned that 7777 might unintentionally only/also get flagged while attempting to flag 8888.

 

However using a similar e= xample, 3PCC fraudster robocaller (7777) first attempts to reach a live fis= h (9999).  After fish answers, 3PCC reconnects fish to the fisherman (8888).  Fish releases the call with BYE 666.  This is= a situation where it would be desirable to flag 7777 while attempting to f= lag 8888.

 

Another example of 3PCC i= s the potential to send INVITE to answer an incoming call.  The called= party is notified of an incoming call.  The called party sends INVITE to controller to answer the incoming unwanted call.  The calle= d party sends BYE 666 to controller (unless something prevents it).  T= he controller can handle the 666 as desired (even though appears within dia= log to be from caller) and potentially relay it.

 

As an fyi, I don=92t want= to slow the draft progression.  Thus unless others think good enough = as-is, adding something like the following to section 4 or 6 might be adequate.

 

"Some call services = such as 3PCC [RFC3725] and call transfer increase the complexity of identif= ying who (if anyone) should be impacted by the receipt of 666 within BYE.  Such services might causes the wrong party to be flagged= or prevent flagging the desired party."

 

Thanks,

Brett

 

From: Henning = Schulzrinne [mailto:Henning.= Schulzrinne@fcc.gov]
Sent: Tuesday, January 17, 2017 6:05 PM
To: Brett Tate; sipcore@ietf.org=
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

As I mentioned before, it= seems somewhat unlikely that 3PCC scenarios occur for unwanted calls, exce= pt by accident or because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from =93Marriott Hotels=94 to his boss, = thinking that this is about an upcoming hotel reservation, but the call tur= ns out to be spam.) As you note, the forwarding party should not be flagged= .

 

But since it=92s the cont= ent of the call is deemed objectionable (unwanted) by the recipient, the go= al should be to identify the party that is generating that content, even if they try to hide behind somebody else.

 

I=92m probably lacking im= agination, but can you explain how these scenarios would occur in the typic= al robocall, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties,= but I=92m not sure that=92s what you have in mind for the scenarios below.=

 

Is there a definable noti= on of the =93original=94 calling party since that seems most likely to be t= he bad actor?

 

Henning

 

From: Brett = Tate [mailto:brett@broadsoft.com= ]
Sent: Tuesday, January 17, 2017 11:37 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

Concerning the likelihood= , I assume that it would depend upon if there is a convenience, business, o= r mischievous reason to do it.

 

As I=92ve mentioned, I fi= nd the concept of who gets impacted by 666 somewhat vague within the draft = because of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity.  Howe= ver, I assume that the draft can proceed without needing to clarify that st= uff.

 

If anyone knows the answe= rs to the following, please let me know.

 

If the "calling part= y" gets replaced before "called party" sends BYE with 666, w= ho should be flagged: 1) calling party indicated within original INVITE or = 2) newest connected party?

 

Should the connected part= y be flagged if the "calling party" sends BYE with 666?

 

Should the call forwardin= g party be flagged when flagging the "calling party"?  I ass= ume no since potentially innocent bystander.

 

Should the call transferr= ing party be flagged when flagging the "calling party"?

 

Thanks,

Brett

 

From: Henning = Schulzrinne [mailto:Henning.= Schulzrinne@fcc.gov]
Sent: Sunday, January 15, 2017 3:49 PM
To: Brett Tate; sipcore@ietf.org=
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

How likely is any of this going to happen fo= r unwanted robocalls? For figure 4, the one scenario I can think of is the = "evil" controller leveraging a service A to call B, and B 666'ing= the call or sending a BYE with Reason(666). But that would seem to be pretty standard, even if the final recipient of = the 666 or BYE is A (who is likely to ignore it).

 

I think it would help if you could identify = the roles of the third parties and see if that causes the recipient of the = unwanted call to do something that's harmful to innocent bystanders.=

 

Henning

From: Brett Tate <bre= tt@broadsoft.com>
Sent: Friday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; sipcore= @ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

Concerning calling party = sending BYE with 666, I just thought that it potentially should be discusse= d.

 

However, RFC 3725 figures= 4 and figure 7 do show how a =93calling party=94 might get replaced by a = =93called party=94.  Thus if the controller doesn=92t strip the Reason while relaying the BYE, it definitely would be possible since both are cal= led parties.

 

If the =93calling party= =94 gets replaced before =93called party=94 sends BYE with 666, who should = be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

 

Thanks,

Brett

 

From: Henning = Schulzrinne [mailto:Henning.= Schulzrinne@fcc.gov]
Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate; marian= ne.mohali@orange.com; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I=92m afraid I don=92t qu= ite follow what text you are suggesting and I=92m suspecting we=92re well i= nto the weeds at this point. My general inclination is to only state things where 666 differs from 6xx handling, rather than try to capture all= possible status code issues that are generic to (most) 6xx codes. This avo= ids creating inadvertent contradictions or the need to update the document = should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise = noted.

 

Thus, can you provide sug= gested text?

 

I=92m not sure why the ca= lling party would indicate 666. After receiving a re-INVITE? In response to= a BYE? I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen= for a generic 6xx response in those circumstances.

 

Stretching the imaginatio= n, I could imagine the case where I=92m misled into dialing a number (e.g.,= as part of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason.

 

Is that the case you have= in mind?

 

Henning

 

From: Brett = Tate [mailto:bre= tt@broadsoft.com]
Sent: Friday, January 06, 2017 12:32 PM
To: marianne.mohali@orange.com; Henning Schulzrinne &= lt;Henni= ng.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

The draft potentially sho= uld also discuss the potential for the connected party to change mid-dialog= 1) without it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.

 

From a security considera= tions perspective, the wrong party might be flagged by the 666 when the con= nected party changes.

 

The draft should potentia= lly also discuss the potential for calling party indicating 666.  Othe= r than a way to attack someone, I=92m not sure if are any 3PCC, transfer, or other service situations where it might actually be appropria= te.

 

 

From: marianne.m= ohali@orange.com [mailto:marianne.mohali@orange.com= ]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

To reflect the ques= tion of the interpretation of the 666 response interpretation when the call= er has several identities used for this call (ie. From and P-Asserted-Ident= ity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be = considered has a fraudulent (ie. the calling party or the diverting party o= r both ?) ; I propose to add the following text:

This document defin= es a mechanism by which a called party can reject an unwanted call without = consideration of the calling party identification that remain to the servic= e provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or afte= r a diverting service in P-Asserted-Identity, From, History-Info or any con= current header field that can be present at the same time in a SIP message.=

 

Those questions are= real issues for operators and implementors and they are a weakness that fr= audulent callers could use to bypass the mechanism.

 

BR,

Marianne

 

 
--_000_CY1PR09MB06347AAB4716D7F15C13266FEA7F0CY1PR09MB0634namp_-- From nobody Thu Jan 19 03:58:44 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E16912948C for ; Thu, 19 Jan 2017 03:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kVQua3ZXTbJ9 for ; Thu, 19 Jan 2017 03:58:41 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2498A12007C for ; Thu, 19 Jan 2017 03:58:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ntQ6vWEhvRuKVGnakewluYAY04w8L1vRy6Sat9j5TI8=; b=n+M8etGNx3Xi7pDcRqcyzvRZG67dpA5mDKYOglNWUHF8BK/7yzJ6lLBFSPf6Lk45yRWtS8/aupT6iAL8IZTZgtNWhDWuOdktc8jI/nMm/7sTuXLKWKAT/OdbEaYPXAv04yI3Xvzl63P3p4BCdfwqTz5sV44UBrlLrxTvrRCTleE= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0052.outbound.protection.outlook.com [207.46.163.52]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-100-P9hKDHCqMi2eR36wgcQxzA-1; Thu, 19 Jan 2017 06:58:37 -0500 Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2343.namprd03.prod.outlook.com (10.166.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 19 Jan 2017 11:58:35 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0845.021; Thu, 19 Jan 2017 11:58:35 +0000 From: "Asveren, Tolga" To: Paul Kyzivat , Henning Schulzrinne , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbeklUIfCp4Q0p061YwjEbBL+X6E6BuYAgAQB1vCAAGSRgIABMONQ Date: Thu, 19 Jan 2017 11:58:35 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> In-Reply-To: <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 93d8e5f2-1192-41e9-2232-08d440627f6f x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2343; x-microsoft-exchange-diagnostics: 1; CO2PR03MB2343; 7:gGHSC69rngAlJGaPAucdKDK/jhxTC8nSaG18TILV33K8Q3BsM8k69sN2F8AQQBLCL5WkO5B0Iyf06qvdpvl1vZNUXasubH2gIylFVj4KjAikmw7gzFBk5VP5uCORaZFukk0EbbOzBbQWiZMVlycYi+omFGgRMb9b88aLtWo9XfeLxptO8ofOS+J3xSvJSHLkPs4zab4Ky42zIqJc8IL/zuNg7D2I58gsn8Af/AFC+Gs/+5a7EwK39uKnSd6IEoH/WwH/uZdlGFr4ciL1tmctd1Y4YdFbGVtjTmpQLpe+UyyLbpOP/tuENq6I0RrCJFo0wvQ0Y9TW/cGr/IbbTM1kU47SpLwOGfZ4Ia8JX97kNcKgVQAlo6iSc9Jaxa/xl/+/ChSFP+o/wZJoDVCvWz28kAIgeovY+v+aNHjOR5GgHWJA0vZ7v4Erp8qVvZcoThm57KkT8YhIgGk5iv6BhUsIrg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:CO2PR03MB2343; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2343; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(13464003)(189002)(199003)(24454002)(377454003)(3846002)(5660300001)(105586002)(81156014)(66066001)(2906002)(189998001)(81166006)(106356001)(68736007)(106116001)(8676002)(92566002)(122556002)(53936002)(2171001)(102836003)(9686003)(6116002)(86362001)(99286003)(55016002)(2900100001)(54356999)(76176999)(38730400001)(101416001)(50986999)(2950100002)(7696004)(33656002)(3280700002)(6506006)(93886004)(107886002)(7736002)(8936002)(74316002)(3660700001)(6436002)(25786008)(77096006)(230783001)(5001770100001)(229853002)(97736004)(305945005)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2343; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 11:58:35.3293 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2343 X-MC-Unique: P9hKDHCqMi2eR36wgcQxzA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 11:58:43 -0000 I am having a hard time to understand the attack vector on this scenario. W= hat is the attacker trying to achieve?=20 That a randomly chosen "number" is an actual DN? That information is alread= y available in Yellow Pages or can be obtained relatively easily through "r= andom walk". Invalid numbers will be rejected as "This number is not in ser= vice". Or is the attacker trying to figure out the core-network entity SIP address= (at least one of the many) associated with a DN? What would be the purpose= of doing so? If there really is an issue here, it can be mitigated by the operator provi= ding a portal/service number to report such numbers. This is not what 666 i= s intended for IMHO. Overall, I am happy that no text changes are foreseen = due to this scenario. Thanks, Tolga > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Wednesday, January 18, 2017 11:05 AM > To: Asveren, Tolga ; Henning Schulzrinne > ; SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >=20 > On 1/18/17 5:13 AM, Asveren, Tolga wrote: > > How likely it is that that Bob's UE generates 180 but did not "ring" > > before such an evil CANCEL is received? >=20 > Hard to say. But this sort of behavior is not just theoretical. I get cal= ls like this > nearly every day. Sometimes I hear (1) ring, sometimes none. The charitab= le > interpretation is that someone dialed a wrong number and realized > immediately. But in my experience this is almost never the cause. I often > follow up these, by checking the call log and googling the number. Usuall= y I > find many reports of bad behavior from that number. >=20 > > The entity making use of Reason header, e .g. an Application Server > > managing devices at a call center, can use Contact/Via headers to > > determine the origin of CANCEL (well, unless there is a B2BUA > > in-between; but then just as a note: nowadays it is not uncommon that > > some B2BUAs can relay Via headers between two legs). >=20 > I presume that typically the entity making use of the reason header will = be > the called UAS and/or the home proxy for the callee's AoR (probably the > callee's SP.) The use case mentioned in this thread is by the UAS, when > managing its own log of incoming calls. >=20 > It is unclear to me whether common deployments would preserve the Via > headers that would allow deciphering whether the cancel was due to forkin= g > or an overt action by the UAC. >=20 > > Overall, I don't think there is something here which should cause us > > to lose sleep. >=20 > I'm not losing sleep over it. But the bad actors are not going to go away > quietly once these new mechanisms are put in place. They will certainly s= eek > out holes that can be exploited. So there is value in trying to close as = many > potential holes as we can. >=20 > In any case I didn't see any obvious fix for this. But the consequence is= the > need to be careful not to ascribe too much meaning to the receipt of the = 666 > in cancel. >=20 > =09Thanks, > =09Paul From nobody Thu Jan 19 04:07:16 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFBB1293FB for ; Thu, 19 Jan 2017 04:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id auohCDnyFlnQ for ; Thu, 19 Jan 2017 04:07:11 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11F1E12007C for ; Thu, 19 Jan 2017 04:07:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=NS19OlXGr9f5eUu/B/Cxb+zIu6pNUH+pUAMfhLINFck=; b=jRWu3kOP8JTno5aHwDTBIltsqwo5fSghiwvvTxHBkg7yrC1cL3YaJLkVogQ64q5EMAXH1til3GH+d9kgftmEOkrQCjJggckaVmqryEp/z+0qHx33SaQ07HxrwJanEhBj7QPkGUr7rTHHOk00iXjH/oGKvgMEFmm8xuYMIDgJPOw= Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-20-3WC_UVTIPCWGUyS40JWe6w-1; Thu, 19 Jan 2017 07:07:07 -0500 Received: from CO2PR03MB2342.namprd03.prod.outlook.com (10.166.93.14) by CO2PR03MB2343.namprd03.prod.outlook.com (10.166.93.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 19 Jan 2017 12:07:06 +0000 Received: from CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) by CO2PR03MB2342.namprd03.prod.outlook.com ([10.166.93.14]) with mapi id 15.01.0845.021; Thu, 19 Jan 2017 12:07:06 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Brett Tate , "sipcore@ietf.org" Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Thread-Index: AdJt3jyCGYJ0jtsz5EmPEreSyl8iJgBkouCAAFvL4QAADY6hgAAm6IiAAAmUSQAAHNo9kA== Date: Thu, 19 Jan 2017 12:07:05 +0000 Message-ID: References: , <868dcc0b0065d2ec06b3f796f961f481@mail.gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 94fe20df-bd38-4a94-9853-08d44063afcd x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CO2PR03MB2343; x-microsoft-exchange-diagnostics: 1; CO2PR03MB2343; 7:zLfMQS/PdiZy+hRFPAADNW8VzJ4EBv6ncB/XNMCy7PAbOEA+bUrpnNGcivGnFBHeGUXd8RNWBz/f2WFxaXybAkBRNKyaLWX8jc2y2HCKct5hLoYHmfogohMPwcX3JKYzvaxkaZSLLmvMtWICgcBqlQeW8U4JxavgeRDOutz+7pa9P4FqIkqew0G6tph+6EmgS1wl6wkgc9GmEzrJJa8kRax/BVn4bEoDC2SBPwdH/ifTcPBrJjtdjib0mkbO65H/taFOd3yG43Cpz+HPGqlVrGqk6LveFNJylFEIWsUPc8BYlZmPrLi6f/ddz7jrjNzwjLjSrKryzLqyRHKAWgj3+e+m5wF6vtY9y8YtA8JaZYNORWbIU9egalqfykxaTHabehzLmmnFXytX2iHm3AHM0X95YXgSBsV4unntJjTY5Mj1WYpXF2yzUv8fHTPqPF7gYGN2VZnqCxuI/Plch2XQlQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(100405760836317)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:CO2PR03MB2343; BCL:0; PCL:0; RULEID:; SRVR:CO2PR03MB2343; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(377454003)(199003)(189002)(33656002)(3280700002)(7696004)(6506006)(93886004)(76176999)(54896002)(6306002)(99286003)(54356999)(2900100001)(55016002)(50986999)(2950100002)(38730400001)(101416001)(230783001)(5001770100001)(229853002)(6436002)(77096006)(25786008)(97736004)(3660700001)(7736002)(107886002)(74316002)(8936002)(68736007)(106356001)(8676002)(81166006)(189998001)(81156014)(105586002)(3846002)(5660300001)(2906002)(66066001)(236005)(53946003)(9686003)(102836003)(6116002)(86362001)(790700001)(92566002)(53936002)(19609705001)(2501003)(122556002)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR03MB2343; H:CO2PR03MB2342.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 12:07:05.9047 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2343 X-MC-Unique: 3WC_UVTIPCWGUyS40JWe6w-1 Content-Type: multipart/alternative; boundary="_000_CO2PR03MB2342F05876910AACA3EC77F2B27E0CO2PR03MB2342namp_" Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 12:07:16 -0000 --_000_CO2PR03MB2342F05876910AACA3EC77F2B27E0CO2PR03MB2342namp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable I am not denying such -and many other- complex scenarios, which may require= a carefully crafted analysis logic (analysis logic should be aware of the = actual flow -directly or indirectly-) in the network but it is not somethin= g directly concerning status-unwanted draft. I think we just should have ge= neric/short warning without going into details and it seems we are having a= consensus on that. FWIW, I even wouldn't specifically mention about 3PCC e= tc... and just would indicate that "some calls may require knowledge about = actual message flow for efficient interpretation of 666 response code". Thanks, Tolga From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulz= rinne Sent: Wednesday, January 18, 2017 5:14 PM To: Brett Tate ; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I will add the caveat to the Security Considerations, along with any other = IETF LC and IESG comments. ________________________________ From: Brett Tate > Sent: Wednesday, January 18, 2017 12:39:33 PM To: Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, I'm not sure if there is a definable notion of "original" calling party. I= 'm also not sure if BYE 666 should impact connected party or original calli= ng party. My questions were not necessarily associated with a typical robocall. They= were just questions to help me/others understand who should, should not, o= r unintentionally might be flagged when receive the 666 within response or = BYE. For instance, I'm working remotely at 9999 and missed a call from 8888. I = use a 3PCC client to click-to-call number stored for missed call. The cont= roller first uses 7777 (calling party) to call my remote number 9999; it th= en reconnects me so calling 8888. After they answer, I realize that it was= a spam call. I release the call with BYE 666. Based upon the draft, I'm = concerned that 7777 might unintentionally only/also get flagged while attem= pting to flag 8888. However using a similar example, 3PCC fraudster robocaller (7777) first att= empts to reach a live fish (9999). After fish answers, 3PCC reconnects fis= h to the fisherman (8888). Fish releases the call with BYE 666. This is a= situation where it would be desirable to flag 7777 while attempting to fla= g 8888. Another example of 3PCC is the potential to send INVITE to answer an incomi= ng call. The called party is notified of an incoming call. The called par= ty sends INVITE to controller to answer the incoming unwanted call. The ca= lled party sends BYE 666 to controller (unless something prevents it). The= controller can handle the 666 as desired (even though appears within dialo= g to be from caller) and potentially relay it. As an fyi, I don't want to slow the draft progression. Thus unless others = think good enough as-is, adding something like the following to section 4 o= r 6 might be adequate. "Some call services such as 3PCC [RFC3725] and call transfer increase the c= omplexity of identifying who (if anyone) should be impacted by the receipt = of 666 within BYE. Such services might causes the wrong party to be flagge= d or prevent flagging the desired party." Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Tuesday, January 17, 2017 6:05 PM To: Brett Tate; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occur= for unwanted calls, except by accident or because of forward-on-busy or fo= rward-on-vacation. (Admin assistant transfers a call from "Marriott Hotels"= to his boss, thinking that this is about an upcoming hotel reservation, bu= t the call turns out to be spam.) As you note, the forwarding party should = not be flagged. But since it's the content of the call is deemed objectionable (unwanted) b= y the recipient, the goal should be to identify the party that is generatin= g that content, even if they try to hide behind somebody else. I'm probably lacking imagination, but can you explain how these scenarios w= ould occur in the typical robocall, beyond the accidental forwarding case a= bove? I can see incentives for bad actors to hide behind innocent third par= ties, but I'm not sure that's what you have in mind for the scenarios below= . Is there a definable notion of the "original" calling party since that seem= s most likely to be the bad actor? Henning From: Brett Tate [mailto:brett@broadsoft.com] Sent: Tuesday, January 17, 2017 11:37 AM To: Henning Schulzrinne >; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning the likelihood, I assume that it would depend upon if there is a= convenience, business, or mischievous reason to do it. As I've mentioned, I find the concept of who gets impacted by 666 somewhat = vague within the draft because of the variety of call services (3PCC, call = forwarding, transfer, et cetera) and ways to update the connected identity.= However, I assume that the draft can proceed without needing to clarify t= hat stuff. If anyone knows the answers to the following, please let me know. If the "calling party" gets replaced before "called party" sends BYE with 6= 66, who should be flagged: 1) calling party indicated within original INVIT= E or 2) newest connected party? Should the connected party be flagged if the "calling party" sends BYE with= 666? Should the call forwarding party be flagged when flagging the "calling part= y"? I assume no since potentially innocent bystander. Should the call transferring party be flagged when flagging the "calling pa= rty"? Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Sunday, January 15, 2017 3:49 PM To: Brett Tate; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 How likely is any of this going to happen for unwanted robocalls? For figur= e 4, the one scenario I can think of is the "evil" controller leveraging a = service A to call B, and B 666'ing the call or sending a BYE with Reason(66= 6). But that would seem to be pretty standard, even if the final recipient = of the 666 or BYE is A (who is likely to ignore it). I think it would help if you could identify the roles of the third parties = and see if that causes the recipient of the unwanted call to do something t= hat's harmful to innocent bystanders. Henning ________________________________ From: Brett Tate > Sent: Friday, January 13, 2017 3:48:58 PM To: Henning Schulzrinne; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, Concerning calling party sending BYE with 666, I just thought that it poten= tially should be discussed. However, RFC 3725 figures 4 and figure 7 do show how a "calling party" migh= t get replaced by a "called party". Thus if the controller doesn't strip t= he Reason while relaying the BYE, it definitely would be possible since bot= h are called parties. If the "calling party" gets replaced before "called party" sends BYE with 6= 66, who should be flagged: 1) calling party indicated within original INVIT= E or 2) newest connected party? Thanks, Brett From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] Sent: Thursday, January 12, 2017 3:31 PM To: Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 I'm afraid I don't quite follow what text you are suggesting and I'm suspec= ting we're well into the weeds at this point. My general inclination is to = only state things where 666 differs from 6xx handling, rather than try to c= apture all possible status code issues that are generic to (most) 6xx codes= . This avoids creating inadvertent contradictions or the need to update the= document should there be changes in the generic handling. In other words, = 666 should be treated like 6xx unless otherwise noted. Thus, can you provide suggested text? I'm not sure why the calling party would indicate 666. After receiving a re= -INVITE? In response to a BYE? I admit that I lack the imagination as to ho= w this would occur and why this would cause anything other than what would = happen for a generic 6xx response in those circumstances. Stretching the imagination, I could imagine the case where I'm misled into = dialing a number (e.g., as part of a spam email) that turns out to be a rob= ot peddling time shares. I could send a BYE, with a 666 Reason. Is that the case you have in mind? Henning From: Brett Tate [mailto:brett@broadsoft.com] Sent: Friday, January 06, 2017 12:32 PM To: marianne.mohali@orange.com; Henning = Schulzrinne >; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, The draft potentially should also discuss the potential for the connected p= arty to change mid-dialog 1) without it being communicated and 2) with it b= eing communicate by RFC 4916, RFC 5876, et cetera. >From a security considerations perspective, the wrong party might be flagge= d by the 666 when the connected party changes. The draft should potentially also discuss the potential for calling party i= ndicating 666. Other than a way to attack someone, I'm not sure if are any= 3PCC, transfer, or other service situations where it might actually be app= ropriate. From: marianne.mohali@orange.com [mailto= :marianne.mohali@orange.com] Sent: Friday, January 06, 2017 10:28 AM To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 Hi, To reflect the question of the interpretation of the 666 response interpret= ation when the caller has several identities used for this call (ie. From a= nd P-Asserted-Identity are different) or call forwarding/call transfer use = cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I = propose to add the following text: This document defines a mechanism by which a called party can reject an unw= anted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity ma= y be reflected in different way for a direct call or after a diverting serv= ice in P-Asserted-Identity, From, History-Info or any concurrent header fie= ld that can be present at the same time in a SIP message. Those questions are real issues for operators and implementors and they are= a weakness that fraudulent callers could use to bypass the mechanism. BR, Marianne --_000_CO2PR03MB2342F05876910AACA3EC77F2B27E0CO2PR03MB2342namp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

I am not denying such -and many other- complex scen= arios, which may require a carefully crafted analysis logic (analysis logic= should be aware of the actual flow -directly or indirectly-) in the network but it is not something directly concerning= status-unwanted draft. I think we just should have generic/short warning w= ithout going into details and it seems we are having a consensus on that. F= WIW, I even wouldn’t specifically mention about 3PCC etc… and just would indicate that “some cal= ls may require knowledge about actual message flow for efficient interpreta= tion of 666 response code”.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounce= s@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Wednesday, January 18, 2017 5:14 PM
To: Brett Tate <brett@broadsoft.com>; sipcore@ietf.org
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I will add the caveat to the Security Consid= erations, along with any other IETF LC and IESG comments.

From: Brett = Tate <brett@broadsoft.com>=
Sent: Wednesday, January 18, 2017 12:39:33 PM
To: Henning Schulzrinne; sipcore= @ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

I’m not sure if there is a defi= nable notion of "original" calling party.  I’m also no= t sure if BYE 666 should impact connected party or original calling party.<= /span>

 

My questions were not necessarily ass= ociated with a typical robocall.  They were just questions to help me/= others understand who should, should not, or unintentionally might be flagged when receive the 666 within response or BYE.<= /o:p>

 

For instance, I’m working remot= ely at 9999 and missed a call from 8888.  I use a 3PCC client to click= -to-call number stored for missed call.  The controller first uses 7777 (calling party) to call my remote number 9999; it then reconnect= s me so calling 8888.  After they answer, I realize that it was a spam= call.  I release the call with BYE 666.  Based upon the draft, I= ’m concerned that 7777 might unintentionally only/also get flagged while attempting to flag 8888.

 

However using a similar example, 3PCC= fraudster robocaller (7777) first attempts to reach a live fish (9999).&nb= sp; After fish answers, 3PCC reconnects fish to the fisherman (8888).  Fish releases the call with BYE 666.  This is= a situation where it would be desirable to flag 7777 while attempting to f= lag 8888.

 

Another example of 3PCC is the potent= ial to send INVITE to answer an incoming call.  The called party is no= tified of an incoming call.  The called party sends INVITE to controller to answer the incoming unwanted call.  The calle= d party sends BYE 666 to controller (unless something prevents it).  T= he controller can handle the 666 as desired (even though appears within dia= log to be from caller) and potentially relay it.

 

As an fyi, I don’t want to slow= the draft progression.  Thus unless others think good enough as-is, a= dding something like the following to section 4 or 6 might be adequate.

 

"Some call services such as 3PCC= [RFC3725] and call transfer increase the complexity of identifying who (if= anyone) should be impacted by the receipt of 666 within BYE.  Such services might causes the wrong party to be flagged or pre= vent flagging the desired party."

 

Thanks,

Brett

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Tuesday, January 17, 2017 6:05 PM
To: Brett Tate; sipcore@ietf.org=
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

As I mentioned before, it seems somew= hat unlikely that 3PCC scenarios occur for unwanted calls, except by accide= nt or because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from “Marriott Hotels” to hi= s boss, thinking that this is about an upcoming hotel reservation, but the = call turns out to be spam.) As you note, the forwarding party should not be= flagged.

 

But since it’s the content of t= he call is deemed objectionable (unwanted) by the recipient, the goal shoul= d be to identify the party that is generating that content, even if they try to hide behind somebody else.

 

I’m probably lacking imaginatio= n, but can you explain how these scenarios would occur in the typical roboc= all, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties, b= ut I’m not sure that’s what you have in mind for the scenarios = below.

 

Is there a definable notion of the &#= 8220;original” calling party since that seems most likely to be the b= ad actor?

 

Henning

 

From: Brett Tate [mailto:brett@broadsoft.com]
Sent: Tuesday, January 17, 2017 11:37 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

Concerning the likelihood, I assume t= hat it would depend upon if there is a convenience, business, or mischievou= s reason to do it.

 

As I’ve mentioned, I find the c= oncept of who gets impacted by 666 somewhat vague within the draft because = of the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity.  Howe= ver, I assume that the draft can proceed without needing to clarify that st= uff.

 

If anyone knows the answers to the fo= llowing, please let me know.

 

If the "calling party" gets= replaced before "called party" sends BYE with 666, who should be= flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

 

Should the connected party be flagged= if the "calling party" sends BYE with 666?

 

Should the call forwarding party be f= lagged when flagging the "calling party"?  I assume no since= potentially innocent bystander.

 

Should the call transferring party be= flagged when flagging the "calling party"?

 

Thanks,

Brett

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Sunday, January 15, 2017 3:49 PM
To: Brett Tate; sipcore@ietf.org=
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

How likely is any of this going to happen fo= r unwanted robocalls? For figure 4, the one scenario I can think of is the = "evil" controller leveraging a service A to call B, and B 666'ing= the call or sending a BYE with Reason(666). But that would seem to be pretty standard, even if the final recipient of = the 666 or BYE is A (who is likely to ignore it).

 

I think it would help if you could identify = the roles of the third parties and see if that causes the recipient of the = unwanted call to do something that's harmful to innocent bystanders.=

 

Henning

From: Brett = Tate <brett@broadsoft.com>=
Sent: Friday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; sipcore= @ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

Concerning calling party sending BYE = with 666, I just thought that it potentially should be discussed.

 

However, RFC 3725 figures 4 and figur= e 7 do show how a “calling party” might get replaced by a ̶= 0;called party”.  Thus if the controller doesn’t strip the= Reason while relaying the BYE, it definitely would be possible since both are cal= led parties.

 

If the “calling party” ge= ts replaced before “called party” sends BYE with 666, who shoul= d be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

 

Thanks,

Brett

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate; marian= ne.mohali@orange.com; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

I’m afraid I don’t quite = follow what text you are suggesting and I’m suspecting we’re we= ll into the weeds at this point. My general inclination is to only state things where 666 differs from 6xx handling, rather than try to capture all= possible status code issues that are generic to (most) 6xx codes. This avo= ids creating inadvertent contradictions or the need to update the document = should there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise = noted.

 

Thus, can you provide suggested text?=

 

I’m not sure why the calling pa= rty would indicate 666. After receiving a re-INVITE? In response to a BYE? = I admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen for a= generic 6xx response in those circumstances.

 

Stretching the imagination, I could i= magine the case where I’m misled into dialing a number (e.g., as part= of a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason.

 

Is that the case you have in mind?

 

Henning

 

From: Brett Tate [mailto:brett@broadsoft.com]
Sent: Friday, January 06, 2017 12:32 PM
To: marianne.m= ohali@orange.com; Henning Schulzrinne <Henning.Schulzrinne@fcc.gov&g= t;; sipcore@ietf.org Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 

The draft potentially should also dis= cuss the potential for the connected party to change mid-dialog 1) without = it being communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.

 

From a security considerations perspe= ctive, the wrong party might be flagged by the 666 when the connected party= changes.

 

The draft should potentially also dis= cuss the potential for calling party indicating 666.  Other than a way= to attack someone, I’m not sure if are any 3PCC, transfer, or other service situations where it might actually be appropriate.=

 

 

From: marianne.mohali@orange= .com [mailto:marianne.mohali@orange.com]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwante= d-01

 

Hi,

 <= /o:p>

To reflect the ques= tion of the interpretation of the 666 response interpretation when the call= er has several identities used for this call (ie. From and P-Asserted-Ident= ity are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be = considered has a fraudulent (ie. the calling party or the diverting party o= r both ?) ; I propose to add the following text:

This document defin= es a mechanism by which a called party can reject an unwanted call without = consideration of the calling party identification that remain to the servic= e provider policy. Indeed, the calling party identity may be reflected in different way for a direct call or afte= r a diverting service in P-Asserted-Identity, From, History-Info or any con= current header field that can be present at the same time in a SIP message.=

 <= /o:p>

Those questions are= real issues for operators and implementors and they are a weakness that fr= audulent callers could use to bypass the mechanism.

 <= /o:p>

BR,

Marianne

 

 
--_000_CO2PR03MB2342F05876910AACA3EC77F2B27E0CO2PR03MB2342namp_-- From nobody Thu Jan 19 05:21:20 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E8B81294C1 for ; Thu, 19 Jan 2017 05:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH216Zc_3Z7M for ; Thu, 19 Jan 2017 05:21:17 -0800 (PST) Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [173.247.246.244]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC1F12946C for ; Thu, 19 Jan 2017 05:21:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:In-Reply-To:References:Message-Id: Subject:Date:Mime-Version:Content-Transfer-Encoding:Content-Type:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=gdsZTrgV1woIQ3dgQWVW6sqdZ+OD3QfihwpHgiZqrUI=; b=Tdi6D2KEOzYPufKxbJ98A6oDEf Hs6Xa2Hx6sWmhwK6g+u51Mw0V97vTW3tS/wI+vXAB8NgSWWqS9iZNfiUH7qr3jXTahuPGwytUcQgx P55GWpDmemxgFC8fJAhsjpizWYXCSUw2zulA2LT6XNd8Q9dyTUVaeIi1zY/hZ8Cn+v7o=; Received: from ip68-100-197-40.dc.dc.cox.net ([68.100.197.40]:55470 helo=[192.168.10.17]) by biz104.inmotionhosting.com with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.87) (envelope-from ) id 1cUB50-0001TQ-1m for sipcore@ietf.org; Thu, 19 Jan 2017 03:40:50 -0800 From: Eric Burger Content-Type: multipart/alternative; boundary=Apple-Mail-35DC2A4C-A28B-4144-9021-B8CD2090657F Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Thu, 19 Jan 2017 06:40:32 -0500 Message-Id: <60856247-4DC9-41E3-B456-F7644980923C@standardstrack.com> References: In-Reply-To: To: sipcore@ietf.org X-Mailer: iPad Mail (14C92) X-OutGoing-Spam-Status: No, score=0.3 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz104.inmotionhosting.com: acl_c_recent_authed_mail_ips_text_entry: eburger@standardstrack.com|standardstrack.com X-Authenticated-Sender: biz104.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 13:21:18 -0000 --Apple-Mail-35DC2A4C-A28B-4144-9021-B8CD2090657F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I would be very careful about solving today's problem and missing tomorrow's= if we can see it. If there is a way for bad actors to turn 666 into the nex= t ransomeware attack or make 666 useless because innocents get blocked, you c= an be guaranteed that in Internet time you will find Internet criminals taki= ng advantage of it. -- Sent from a mobile device. Thank LEMONDADE for that at http://www.standardst= rack.com/ietf/lemonade/index.html > On Jan 18, 2017, at 6:39 AM, Asveren, Tolga wrote:= >=20 > Looking to this on a =E2=80=9Cphilosophical=E2=80=9D level: > =20 > I don=E2=80=99t think the right approach is to use calling/called definiti= ons as used in technical specifications. In the context of =E2=80=9C666 unwa= nted=E2=80=9D, I am the =E2=80=9Ccaller=E2=80=9D if I dial a number. I am th= e =E2=80=9Ccalled=E2=80=9D if I receive the call (meaning my UE alerts me) ,= and this is where this new response code comes into play. It doesn=E2=80=99= t matter what (possibly complex) call scenario caused alerting. > =20 > I don=E2=80=99t think there is an issue pertaining to draft-ietf-sipcore-s= tatus-unwanted on this topic, at least not on a level where text needs to be= added/changed. > =20 > Thanks, > Tolga > =20 > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schul= zrinne > Sent: Tuesday, January 17, 2017 6:05 PM > To: Brett Tate ; sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > As I mentioned before, it seems somewhat unlikely that 3PCC scenarios occu= r for unwanted calls, except by accident or because of forward-on-busy or fo= rward-on-vacation. (Admin assistant transfers a call from =E2=80=9CMarriott H= otels=E2=80=9D to his boss, thinking that this is about an upcoming hotel re= servation, but the call turns out to be spam.) As you note, the forwarding p= arty should not be flagged. > =20 > But since it=E2=80=99s the content of the call is deemed objectionable (un= wanted) by the recipient, the goal should be to identify the party that is g= enerating that content, even if they try to hide behind somebody else. > =20 > I=E2=80=99m probably lacking imagination, but can you explain how these sc= enarios would occur in the typical robocall, beyond the accidental forwardin= g case above? I can see incentives for bad actors to hide behind innocent th= ird parties, but I=E2=80=99m not sure that=E2=80=99s what you have in mind f= or the scenarios below. > =20 > Is there a definable notion of the =E2=80=9Coriginal=E2=80=9D calling part= y since that seems most likely to be the bad actor? > =20 > Henning > =20 > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: Tuesday, January 17, 2017 11:37 AM > To: Henning Schulzrinne ; sipcore@ietf.org > Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > Hi, > =20 > Concerning the likelihood, I assume that it would depend upon if there is a= convenience, business, or mischievous reason to do it. > =20 > As I=E2=80=99ve mentioned, I find the concept of who gets impacted by 666 s= omewhat vague within the draft because of the variety of call services (3PCC= , call forwarding, transfer, et cetera) and ways to update the connected ide= ntity. However, I assume that the draft can proceed without needing to clar= ify that stuff. > =20 > If anyone knows the answers to the following, please let me know. > =20 > If the "calling party" gets replaced before "called party" sends BYE with 6= 66, who should be flagged: 1) calling party indicated within original INVITE= or 2) newest connected party? > =20 > Should the connected party be flagged if the "calling party" sends BYE wit= h 666? > =20 > Should the call forwarding party be flagged when flagging the "calling par= ty"? I assume no since potentially innocent bystander. > =20 > Should the call transferring party be flagged when flagging the "calling p= arty"? > =20 > Thanks, > Brett > =20 > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 > Sent: Sunday, January 15, 2017 3:49 PM > To: Brett Tate; sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > How likely is any of this going to happen for unwanted robocalls? For figu= re 4, the one scenario I can think of is the "evil" controller leveraging a s= ervice A to call B, and B 666'ing the call or sending a BYE with Reason(666)= . But that would seem to be pretty standard, even if the final recipient of t= he 666 or BYE is A (who is likely to ignore it). > =20 > I think it would help if you could identify the roles of the third parties= and see if that causes the recipient of the unwanted call to do something t= hat's harmful to innocent bystanders. > =20 > Henning > From: Brett Tate > Sent: Friday, January 13, 2017 3:48:58 PM > To: Henning Schulzrinne; sipcore@ietf.org > Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > Hi, > =20 > Concerning calling party sending BYE with 666, I just thought that it pote= ntially should be discussed. > =20 > However, RFC 3725 figures 4 and figure 7 do show how a =E2=80=9Ccalling pa= rty=E2=80=9D might get replaced by a =E2=80=9Ccalled party=E2=80=9D. Thus i= f the controller doesn=E2=80=99t strip the Reason while relaying the BYE, it= definitely would be possible since both are called parties. > =20 > If the =E2=80=9Ccalling party=E2=80=9D gets replaced before =E2=80=9Ccalle= d party=E2=80=9D sends BYE with 666, who should be flagged: 1) calling party= indicated within original INVITE or 2) newest connected party? > =20 > Thanks, > Brett > =20 > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]=20 > Sent: Thursday, January 12, 2017 3:31 PM > To: Brett Tate; marianne.mohali@orange.com; sipcore@ietf.org > Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > I=E2=80=99m afraid I don=E2=80=99t quite follow what text you are suggesti= ng and I=E2=80=99m suspecting we=E2=80=99re well into the weeds at this poin= t. My general inclination is to only state things where 666 differs from 6xx= handling, rather than try to capture all possible status code issues that a= re generic to (most) 6xx codes. This avoids creating inadvertent contradicti= ons or the need to update the document should there be changes in the generi= c handling. In other words, 666 should be treated like 6xx unless otherwise n= oted. > =20 > Thus, can you provide suggested text? > =20 > I=E2=80=99m not sure why the calling party would indicate 666. After recei= ving a re-INVITE? In response to a BYE? I admit that I lack the imagination a= s to how this would occur and why this would cause anything other than what w= ould happen for a generic 6xx response in those circumstances. > =20 > Stretching the imagination, I could imagine the case where I=E2=80=99m mis= led into dialing a number (e.g., as part of a spam email) that turns out to b= e a robot peddling time shares. I could send a BYE, with a 666 Reason. > =20 > Is that the case you have in mind? > =20 > Henning > =20 > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: Friday, January 06, 2017 12:32 PM > To: marianne.mohali@orange.com; Henning Schulzrinne ; sipcore@ietf.org > Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > Hi, > =20 > The draft potentially should also discuss the potential for the connected p= arty to change mid-dialog 1) without it being communicated and 2) with it be= ing communicate by RFC 4916, RFC 5876, et cetera. > =20 > =46rom a security considerations perspective, the wrong party might be fla= gged by the 666 when the connected party changes. > =20 > The draft should potentially also discuss the potential for calling party i= ndicating 666. Other than a way to attack someone, I=E2=80=99m not sure if a= re any 3PCC, transfer, or other service situations where it might actually b= e appropriate. > =20 > =20 > From: marianne.mohali@orange.com [mailto:marianne.mohali@orange.com]=20 > Sent: Friday, January 06, 2017 10:28 AM > To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org > Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01 > =20 > Hi, > =20 > To reflect the question of the interpretation of the 666 response interpre= tation when the caller has several identities used for this call (ie. =46rom= and P-Asserted-Identity are different) or call forwarding/call transfer use= cases for which it has to be discussed which party should be considered has= a fraudulent (ie. the calling party or the diverting party or both ?) ; I p= ropose to add the following text: > This document defines a mechanism by which a called party can reject an un= wanted call without consideration of the calling party identification that r= emain to the service provider policy. Indeed, the calling party identity may= be reflected in different way for a direct call or after a diverting servic= e in P-Asserted-Identity, From, History-Info or any concurrent header field t= hat can be present at the same time in a SIP message. > =20 > Those questions are real issues for operators and implementors and they ar= e a weakness that fraudulent callers could use to bypass the mechanism. > =20 > BR, > Marianne > =20 > =20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-35DC2A4C-A28B-4144-9021-B8CD2090657F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I would be very careful about solving t= oday's problem and missing tomorrow's if we can see it. If there is a way fo= r bad actors to turn 666 into the next ransomeware attack or make 666 useles= s because innocents get blocked, you can be guaranteed that in Internet time= you will find Internet criminals taking advantage of it.

--
Sent from a= mobile device. Thank LEMONDADE for that at http://ww= w.standardstrack.com/ietf/lemonade/index.html

On Jan= 18, 2017, at 6:39 AM, Asveren, Tolga <tasveren@sonusnet.com> wrote:

Looking to this on a =E2=80=9Cphilosophical=E2=80=9D l= evel:

 

I don=E2=80=99t think the right approach is to use ca= lling/called definitions as used in technical specifications. In the context= of =E2=80=9C666 unwanted=E2=80=9D, I am the =E2=80=9Ccaller=E2=80=9D if I d= ial a number. I am the =E2=80=9Ccalled=E2=80=9D if I receive the call (meaning my UE aler= ts me) , and this is where this new response code comes into play. It doesn=E2= =80=99t matter what (possibly complex) call scenario caused alerting.

 

I don=E2=80=99t think there is an issue pertaining to= draft-ietf-sipcore-status-unwanted on this topic, at least not on a level w= here text needs to be added/changed.

 

Thanks,

Tolga

 

From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Henning Schulzrinne
Sent: Tuesday, January 17, 2017 6:05 PM
To: Brett Tate <brett@broad= soft.com>; sipcore@ietf.org Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

As I mentioned before, it seems somewha= t unlikely that 3PCC scenarios occur for unwanted calls, except by accident o= r because of forward-on-busy or forward-on-vacation. (Admin assistant transfers a call from =E2=80=9CMarriott Hotels=E2=80=9D to= his boss, thinking that this is about an upcoming hotel reservation, but th= e call turns out to be spam.) As you note, the forwarding party should not b= e flagged.

 

But since it=E2=80=99s the content of t= he call is deemed objectionable (unwanted) by the recipient, the goal should= be to identify the party that is generating that content, even if they try to hide behind somebody else.

 

I=E2=80=99m probably lacking imaginatio= n, but can you explain how these scenarios would occur in the typical roboca= ll, beyond the accidental forwarding case above? I can see incentives for bad actors to hide behind innocent third parties, bu= t I=E2=80=99m not sure that=E2=80=99s what you have in mind for the scenario= s below.

 

Is there a definable notion of the =E2=80= =9Coriginal=E2=80=9D calling party since that seems most likely to be the ba= d actor?

 

Henning

 

From: Brett Tate [mailto:brett@broadsoft.com]
Sent: Tuesday, January 17, 2017 11:37 AM
To: Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

Hi,

 

Concerning the likelihood, I assume tha= t it would depend upon if there is a convenience, business, or mischievous r= eason to do it.

 

As I=E2=80=99ve mentioned, I find the c= oncept of who gets impacted by 666 somewhat vague within the draft because o= f the variety of call services (3PCC, call forwarding, transfer, et cetera) and ways to update the connected identity.  Howev= er, I assume that the draft can proceed without needing to clarify that stuf= f.

 

If anyone knows the answers to the foll= owing, please let me know.

 

If the "calling party" gets replaced be= fore "called party" sends BYE with 666, who should be flagged: 1) calling pa= rty indicated within original INVITE or 2) newest connected party?

 

Should the connected party be flagged i= f the "calling party" sends BYE with 666?

 

Should the call forwarding party be fla= gged when flagging the "calling party"?  I assume no since potentially i= nnocent bystander.

 

Should the call transferring party be f= lagged when flagging the "calling party"?

 

Thanks,

Brett

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Sunday, January 15, 2017 3:49 PM
To: Brett Tate; sipcore@ietf.org<= /a>
Subject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

How likely is any of this going to happen for= unwanted robocalls? For figure 4, the one scenario I can think of is the "e= vil" controller leveraging a service A to call B, and B 666'ing the call or s= ending a BYE with Reason(666). But that would seem to be pretty standard, even if the final recipient of t= he 666 or BYE is A (who is likely to ignore it).

 

I think it would help if you could identify t= he roles of the third parties and see if that causes the recipient of the un= wanted call to do something that's harmful to innocent bystanders.

 

Henning

From: Brett Tat= e <brett@broadsoft.com>
= Sent: Friday, January 13, 2017 3:48:58 PM
To: Henning Schulzrinne; sipcore@= ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

Hi,

 

Concerning calling party sending BYE wi= th 666, I just thought that it potentially should be discussed.<= /o:p>

 

However, RFC 3725 figures 4 and figure 7= do show how a =E2=80=9Ccalling party=E2=80=9D might get replaced by a =E2=80= =9Ccalled party=E2=80=9D.  Thus if the controller doesn=E2=80=99t strip= the Reason while relaying the BYE, it definitely would be possible since both are call= ed parties.

 

If the =E2=80=9Ccalling party=E2=80=9D g= ets replaced before =E2=80=9Ccalled party=E2=80=9D sends BYE with 666, who s= hould be flagged: 1) calling party indicated within original INVITE or 2) newest connected party?

 

Thanks,

Brett

 

From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov]
Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate; mariann= e.mohali@orange.com; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

I=E2=80=99m afraid I don=E2=80=99t quit= e follow what text you are suggesting and I=E2=80=99m suspecting we=E2=80=99= re well into the weeds at this point. My general inclination is to only stat= e things where 666 differs from 6xx handling, rather than try to capture all p= ossible status code issues that are generic to (most) 6xx codes. This avoids= creating inadvertent contradictions or the need to update the document shou= ld there be changes in the generic handling. In other words, 666 should be treated like 6xx unless otherwise n= oted.

 

Thus, can you provide suggested text?

 

I=E2=80=99m not sure why the calling pa= rty would indicate 666. After receiving a re-INVITE? In response to a BYE? I= admit that I lack the imagination as to how this would occur and why this would cause anything other than what would happen for a g= eneric 6xx response in those circumstances.

 

Stretching the imagination, I could ima= gine the case where I=E2=80=99m misled into dialing a number (e.g., as part o= f a spam email) that turns out to be a robot peddling time shares. I could send a BYE, with a 666 Reason.

 

Is that the case you have in mind?

 

Henning

 

From: Brett Tate [mailto:brett@broadsoft.com]
Sent: Friday, January 06, 2017 12:32 PM
To: marianne.mohal= i@orange.com; Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

Hi,

 

The draft potentially should also discu= ss the potential for the connected party to change mid-dialog 1) without it b= eing communicated and 2) with it being communicate by RFC 4916, RFC 5876, et cetera.

 

=46rom a security considerations perspe= ctive, the wrong party might be flagged by the 666 when the connected party c= hanges.

 

The draft should potentially also discu= ss the potential for calling party indicating 666.  Other than a way to= attack someone, I=E2=80=99m not sure if are any 3PCC, transfer, or other service situations where it might actually be appropriate.<= o:p>

 

 

From: marianne.mohali@orange.c= om [mailto:mar= ianne.mohali@orange.com]
Sent: Friday, January 06, 2017 10:28 AM
To: Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwanted= -01

 

Hi,

 

To reflect the quest= ion of the interpretation of the 666 response interpretation when the caller= has several identities used for this call (ie. =46rom and P-Asserted-Identi= ty are different) or call forwarding/call transfer use cases for which it has to be discussed which party should be c= onsidered has a fraudulent (ie. the calling party or the diverting party or b= oth ?) ; I propose to add the following text:

This document define= s a mechanism by which a called party can reject an unwanted call without co= nsideration of the calling party identification that remain to the service p= rovider policy. Indeed, the calling party identity may be reflected in different way for a direct call or after= a diverting service in P-Asserted-Identity, From, History-Info or any concu= rrent header field that can be present at the same time in a SIP message.

 

Those questions are r= eal issues for operators and implementors and they are a weakness that fraud= ulent callers could use to bypass the mechanism.

 

BR,

Marianne=

 

 
____________________= ___________________________
sipcore mailing list
<= span>sipcore@ietf.org
https://www.ietf= .org/mailman/listinfo/sipcore
= --Apple-Mail-35DC2A4C-A28B-4144-9021-B8CD2090657F-- From nobody Thu Jan 19 07:59:06 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94EF41296E1 for ; Thu, 19 Jan 2017 07:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcnnrKRMqYoU for ; Thu, 19 Jan 2017 07:58:59 -0800 (PST) Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DCE8129623 for ; Thu, 19 Jan 2017 07:58:59 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-01v.sys.comcast.net with SMTP id UF6UcgC9uRNZDUF74cmXD8; Thu, 19 Jan 2017 15:58:58 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-14v.sys.comcast.net with SMTP id UF73cRH9v34MTUF74c2rkE; Thu, 19 Jan 2017 15:58:58 +0000 To: "Asveren, Tolga" , Henning Schulzrinne , SIPCORE References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> From: Paul Kyzivat Message-ID: <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> Date: Thu, 19 Jan 2017 10:58:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfAnGOdVMd3Fj+gB6R8qKeNrAKPMrfXlzihvBj1LheEak2RaFNuGHb20w7HeAJHq8wrKMROsjuXH1Qgpve+Xpb3QoICEpy5SyXOzyxeQvmS+Ats+q4ABt wXRioAVgtbkXIGhwlsVRM3Qfyy7nZ6IITKxLW552BFfvW0T7qW171ixz6RNTDycrHZER4R16RhHu8a200KzsLimy4+q55uN6tPe23ioupGViIwDSY5JB82KP 0yuSgLGPMQ6bQBN/ZuAi+w== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:59:00 -0000 On 1/19/17 6:58 AM, Asveren, Tolga wrote: > I am having a hard time to understand the attack vector on this scenario. What is the attacker trying to achieve? > That a randomly chosen "number" is an actual DN? That information is already available in Yellow Pages or can be obtained relatively easily through "random walk". Invalid numbers will be rejected as "This number is not in service". > Or is the attacker trying to figure out the core-network entity SIP address (at least one of the many) associated with a DN? What would be the purpose of doing so? > > If there really is an issue here, it can be mitigated by the operator providing a portal/service number to report such numbers. This is not what 666 is intended for IMHO. Overall, I am happy that no text changes are foreseen due to this scenario. I don't know what the goal of the attack is. But there must be one, because it occurs with regularity. I get these multiple times per week, as do others I have asked about it. And querying the calling number typically turns up others who have received similar calls. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Wednesday, January 18, 2017 11:05 AM >> To: Asveren, Tolga ; Henning Schulzrinne >> ; SIPCORE >> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> On 1/18/17 5:13 AM, Asveren, Tolga wrote: >>> How likely it is that that Bob's UE generates 180 but did not "ring" >>> before such an evil CANCEL is received? >> >> Hard to say. But this sort of behavior is not just theoretical. I get calls like this >> nearly every day. Sometimes I hear (1) ring, sometimes none. The charitable >> interpretation is that someone dialed a wrong number and realized >> immediately. But in my experience this is almost never the cause. I often >> follow up these, by checking the call log and googling the number. Usually I >> find many reports of bad behavior from that number. >> >>> The entity making use of Reason header, e .g. an Application Server >>> managing devices at a call center, can use Contact/Via headers to >>> determine the origin of CANCEL (well, unless there is a B2BUA >>> in-between; but then just as a note: nowadays it is not uncommon that >>> some B2BUAs can relay Via headers between two legs). >> >> I presume that typically the entity making use of the reason header will be >> the called UAS and/or the home proxy for the callee's AoR (probably the >> callee's SP.) The use case mentioned in this thread is by the UAS, when >> managing its own log of incoming calls. >> >> It is unclear to me whether common deployments would preserve the Via >> headers that would allow deciphering whether the cancel was due to forking >> or an overt action by the UAC. >> >>> Overall, I don't think there is something here which should cause us >>> to lose sleep. >> >> I'm not losing sleep over it. But the bad actors are not going to go away >> quietly once these new mechanisms are put in place. They will certainly seek >> out holes that can be exploited. So there is value in trying to close as many >> potential holes as we can. >> >> In any case I didn't see any obvious fix for this. But the consequence is the >> need to be careful not to ascribe too much meaning to the receipt of the 666 >> in cancel. >> >> Thanks, >> Paul > > From nobody Thu Jan 19 08:02:40 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6281294A0 for ; Thu, 19 Jan 2017 08:02:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T47I7-kBVUA3 for ; Thu, 19 Jan 2017 08:02:37 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548461293E1 for ; Thu, 19 Jan 2017 08:02:37 -0800 (PST) Received: from pps.filterd (m0102171.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0JFrjx1016438; Thu, 19 Jan 2017 16:02:35 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0056.outbound.protection.outlook.com [23.103.198.56]) by mx0b-0024ed01.pphosted.com with ESMTP id 27yfp4jbbj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Jan 2017 16:02:35 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZrtRNf2Rosz3XrwkBPaBGgVeG3HTKwVbqCQI9XzZbCE=; b=m2WWl0CdzAdtX5VA6l7YUxokaWlkxPTd+l2GboSLbnYb+IgovGTbKul+uEckHbuRgf0xQlVKSGxeQLpgd6xxSHjaTuq7hSQ/gY55bH7fbP3lMs0EKX1WiQIz7RumaAz7c4CrtJ+qUidgQDYW3GGFpIv7pgtqRnJXX0TbHTQBxhk= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 19 Jan 2017 16:02:33 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.021; Thu, 19 Jan 2017 16:02:34 +0000 From: Henning Schulzrinne To: Paul Kyzivat , "Asveren, Tolga" , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbekfpzK9A/mMxEW2UXxc6qTie6E6Bhn4gAQFPYCAAGH3gIABTZqAgABDKICAAABKkA== Date: Thu, 19 Jan 2017 16:02:33 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> In-Reply-To: <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: b3de654c-79be-4fe0-b04e-08d4408494bc x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:fH6n0VN3xe/D0VMc9c27JO8WbAWCUcSsawhzU5R/5T/nIgO8G91RE3YueJd9FUAhNb7oZXoMjVuCP+dFVd1mX7QS/Bh4jG5IsgcD8i4SSjNTi1/nQCoepmsPTO5U59rsDrxY60o6EuOeVv45dOw2G/4/LZXo2ggitu/1x4xDultUe7+hv91MUVqLVxW9YJim5GFSyG0Jms2QhphGi5wYOFQ9LVaY1lLomTaZsxnafuC6YnCJxrk4s+y2LKcRRb+c1ZauRrLfiCwtqbkfad5HP2Eus7ow+hnKBU2wiD46bK/EQg1FNBfTy+BbcxFAFMihw1/NmNYW4+93QIV1jfaixpCzSFAeUKAzF0kcAzKW/aNvFIZrb0E4tFiEknfOFhcM0EiYTV3U3k2bvVMwdwREJYAB7cTTzgIqait9eidrse9RJThT3X/GSK8m6pPcrsFOE0dplwadrERUfJn7J2ybgw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(235228084354710)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(24454002)(199003)(377454003)(13464003)(189002)(2906002)(230783001)(7736002)(9686003)(92566002)(2171001)(105586002)(122556002)(6116002)(102836003)(3846002)(53936002)(8936002)(6306002)(33656002)(68736007)(106116001)(106356001)(66066001)(25786008)(5660300001)(5001770100001)(107886002)(189998001)(38730400001)(77096006)(6436002)(74316002)(81166006)(8676002)(81156014)(2950100002)(54356999)(1720100001)(50986999)(3660700001)(55016002)(15395725005)(305945005)(99286003)(93886004)(101416001)(229853002)(7696004)(6506006)(2900100001)(86362001)(3280700002)(97736004)(76176999)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 16:02:33.7984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-19_04:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:02:40 -0000 I have heard that these are simply scanning attacks - trying to find open S= IP proxies that can be used as intermediaries for hiding (DOS) attacks or s= pam, or to probe for poorly-secured systems to use for toll fraud. Google for "SIP scanner" and you'll find articles such as http://serverfault.com/questions/549134/how-can-i-stop-sipvicious-friendly-= scanner-from-flooding-my-sip-server -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Thursday, January 19, 2017 10:59 AM To: Asveren, Tolga ; Henning Schulzrinne ; SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt On 1/19/17 6:58 AM, Asveren, Tolga wrote: > I am having a hard time to understand the attack vector on this scenario.= What is the attacker trying to achieve? > That a randomly chosen "number" is an actual DN? That information is alre= ady available in Yellow Pages or can be obtained relatively easily through = "random walk". Invalid numbers will be rejected as "This number is not in s= ervice". > Or is the attacker trying to figure out the core-network entity SIP addre= ss (at least one of the many) associated with a DN? What would be the purpo= se of doing so? > > If there really is an issue here, it can be mitigated by the operator pro= viding a portal/service number to report such numbers. This is not what 666= is intended for IMHO. Overall, I am happy that no text changes are foresee= n due to this scenario. I don't know what the goal of the attack is. But there must be one, because= it occurs with regularity. I get these multiple times per week, as do othe= rs I have asked about it. And querying the calling number typically turns u= p others who have received similar calls. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Wednesday, January 18, 2017 11:05 AM >> To: Asveren, Tolga ; Henning Schulzrinne=20 >> ; SIPCORE >> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> On 1/18/17 5:13 AM, Asveren, Tolga wrote: >>> How likely it is that that Bob's UE generates 180 but did not "ring" >>> before such an evil CANCEL is received? >> >> Hard to say. But this sort of behavior is not just theoretical. I get=20 >> calls like this nearly every day. Sometimes I hear (1) ring,=20 >> sometimes none. The charitable interpretation is that someone dialed=20 >> a wrong number and realized immediately. But in my experience this is=20 >> almost never the cause. I often follow up these, by checking the call=20 >> log and googling the number. Usually I find many reports of bad behavior= from that number. >> >>> The entity making use of Reason header, e .g. an Application Server=20 >>> managing devices at a call center, can use Contact/Via headers to=20 >>> determine the origin of CANCEL (well, unless there is a B2BUA=20 >>> in-between; but then just as a note: nowadays it is not uncommon=20 >>> that some B2BUAs can relay Via headers between two legs). >> >> I presume that typically the entity making use of the reason header=20 >> will be the called UAS and/or the home proxy for the callee's AoR=20 >> (probably the callee's SP.) The use case mentioned in this thread is=20 >> by the UAS, when managing its own log of incoming calls. >> >> It is unclear to me whether common deployments would preserve the Via=20 >> headers that would allow deciphering whether the cancel was due to=20 >> forking or an overt action by the UAC. >> >>> Overall, I don't think there is something here which should cause us=20 >>> to lose sleep. >> >> I'm not losing sleep over it. But the bad actors are not going to go=20 >> away quietly once these new mechanisms are put in place. They will=20 >> certainly seek out holes that can be exploited. So there is value in=20 >> trying to close as many potential holes as we can. >> >> In any case I didn't see any obvious fix for this. But the=20 >> consequence is the need to be careful not to ascribe too much meaning=20 >> to the receipt of the 666 in cancel. >> >> Thanks, >> Paul > > From nobody Thu Jan 19 08:29:38 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47DB412948B for ; Thu, 19 Jan 2017 08:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J96H5q8_vDf for ; Thu, 19 Jan 2017 08:29:35 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [216.205.24.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA57C12949B for ; Thu, 19 Jan 2017 08:29:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FaTgVpv/I4zag0R8uwFpGso3tYmA2odm4vuDqM/6vQ0=; b=FYL5zBDxOVwKNzTZml87bae9c+Zxoh068S/8iT/mHnA6TX8HI3kMmeZlK+AjtuUo8Xcq2gb0lqfgGITvxGPMvErMOErY5syJOAmd3YBFmCdsAkt0Hg2+o1a43dMrXu1aCx8i9gMvjURRwH4p4VTlqpj0bouUGRZpFck1d39ykts= Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0079.outbound.protection.outlook.com [207.46.163.79]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-133-rVi7t50WPS2icJEpLD1AyA-1; Thu, 19 Jan 2017 11:29:30 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2351.namprd03.prod.outlook.com (10.166.210.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Thu, 19 Jan 2017 16:29:28 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0860.012; Thu, 19 Jan 2017 16:29:28 +0000 From: "Asveren, Tolga" To: Henning Schulzrinne , Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbeklUIfCp4Q0p061YwjEbBL+X6E6BuYAgAQB1vCAAGSRgIABMONQgABf34CAAAEBgIAABwSg Date: Thu, 19 Jan 2017 16:29:27 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: ce2ba553-8c32-4516-2dfd-08d4408856c0 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2351; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2351; 7:qXsoYkJwJHCBr/iNPJB2FJKgyeI1eyHirmgHHb1vn0uVgrhhI29rPuZMtRE2ceYJoj7ut0SFu5x8EjcjQwSXjn95megcpl3S9MIm3ePG5Bx9TNC3WeKxtB4N2U2W4iThpwrraCJ2IDM40XK0N9TVlaDkhhVshBqNsGjQc8Dfs9SF361rSRC74C1xmBnxu9eewDUqHEvxs00Pjub4inU/7mVa1CGWSuGEQvwAT7Eoxm7LnnVNuZElc2mELwodGgiNSuoNsXGnT2e4TvXQl/XaAsJgUV/fmJx51D+gbZ9fg9C26Uvxo6y+Ox1GTt6Q/QluaKRz2Pe4sRbhB2EE3t1nUke2VD203NVXtfQAFHCnOVhbcncn4+p2tL238rvOx0jrvOo9Fs11t23+TDZlsSFMj0dgszhK/rfWs55iZ4nDHf/8Cfi+4QJAbhljwFPFX0BRrMrQjRMKfVxOEQVFT8Qs4g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(235228084354710)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2351; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2351; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(199003)(13464003)(377454003)(24454002)(106356001)(105586002)(81166006)(8676002)(81156014)(92566002)(76176999)(54356999)(3846002)(102836003)(33656002)(101416001)(8936002)(3660700001)(15395725005)(50986999)(230783001)(6116002)(74316002)(93886004)(2900100001)(68736007)(122556002)(106116001)(7736002)(305945005)(1720100001)(66066001)(38730400001)(6306002)(2950100002)(107886002)(3280700002)(5001770100001)(53936002)(229853002)(2171001)(55016002)(5660300001)(97736004)(25786008)(9686003)(189998001)(7696004)(99286003)(6436002)(86362001)(6506006)(2906002)(77096006)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2351; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 16:29:28.0036 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2351 X-MC-Unique: rVi7t50WPS2icJEpLD1AyA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:29:37 -0000 Yes, that certainly there and is not something new but what is the rational= e behind "not ringing" and even trying a "legitimate DN"? Or in other words= , is there any additional concern arising from use of 666; AFAICS no. Thanks, Tolga > -----Original Message----- > From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] > Sent: Thursday, January 19, 2017 11:03 AM > To: Paul Kyzivat ; Asveren, Tolga > ; SIPCORE > Subject: RE: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >=20 > I have heard that these are simply scanning attacks - trying to find open= SIP > proxies that can be used as intermediaries for hiding (DOS) attacks or sp= am, > or to probe for poorly-secured systems to use for toll fraud. >=20 > Google for "SIP scanner" and you'll find articles such as > http://serverfault.com/questions/549134/how-can-i-stop-sipvicious- > friendly-scanner-from-flooding-my-sip-server >=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: Thursday, January 19, 2017 10:59 AM > To: Asveren, Tolga ; Henning Schulzrinne > ; SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >=20 > On 1/19/17 6:58 AM, Asveren, Tolga wrote: > > I am having a hard time to understand the attack vector on this scenari= o. > What is the attacker trying to achieve? > > That a randomly chosen "number" is an actual DN? That information is > already available in Yellow Pages or can be obtained relatively easily th= rough > "random walk". Invalid numbers will be rejected as "This number is not in > service". > > Or is the attacker trying to figure out the core-network entity SIP add= ress > (at least one of the many) associated with a DN? What would be the purpos= e > of doing so? > > > > If there really is an issue here, it can be mitigated by the operator p= roviding > a portal/service number to report such numbers. This is not what 666 is > intended for IMHO. Overall, I am happy that no text changes are foreseen > due to this scenario. >=20 > I don't know what the goal of the attack is. But there must be one, becau= se it > occurs with regularity. I get these multiple times per week, as do others= I > have asked about it. And querying the calling number typically turns up > others who have received similar calls. >=20 > =09Thanks, > =09Paul >=20 > > Thanks, > > Tolga > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > >> Sent: Wednesday, January 18, 2017 11:05 AM > >> To: Asveren, Tolga ; Henning Schulzrinne > >> ; SIPCORE > >> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt > >> > >> On 1/18/17 5:13 AM, Asveren, Tolga wrote: > >>> How likely it is that that Bob's UE generates 180 but did not "ring" > >>> before such an evil CANCEL is received? > >> > >> Hard to say. But this sort of behavior is not just theoretical. I get > >> calls like this nearly every day. Sometimes I hear (1) ring, > >> sometimes none. The charitable interpretation is that someone dialed > >> a wrong number and realized immediately. But in my experience this is > >> almost never the cause. I often follow up these, by checking the call > >> log and googling the number. Usually I find many reports of bad behavi= or > from that number. > >> > >>> The entity making use of Reason header, e .g. an Application Server > >>> managing devices at a call center, can use Contact/Via headers to > >>> determine the origin of CANCEL (well, unless there is a B2BUA > >>> in-between; but then just as a note: nowadays it is not uncommon > >>> that some B2BUAs can relay Via headers between two legs). > >> > >> I presume that typically the entity making use of the reason header > >> will be the called UAS and/or the home proxy for the callee's AoR > >> (probably the callee's SP.) The use case mentioned in this thread is > >> by the UAS, when managing its own log of incoming calls. > >> > >> It is unclear to me whether common deployments would preserve the Via > >> headers that would allow deciphering whether the cancel was due to > >> forking or an overt action by the UAC. > >> > >>> Overall, I don't think there is something here which should cause us > >>> to lose sleep. > >> > >> I'm not losing sleep over it. But the bad actors are not going to go > >> away quietly once these new mechanisms are put in place. They will > >> certainly seek out holes that can be exploited. So there is value in > >> trying to close as many potential holes as we can. > >> > >> In any case I didn't see any obvious fix for this. But the > >> consequence is the need to be careful not to ascribe too much meaning > >> to the receipt of the 666 in cancel. > >> > >> =09Thanks, > >> =09Paul > > > > From nobody Thu Jan 19 08:50:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5227B129448 for ; Thu, 19 Jan 2017 08:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LiTJ4i1wkzV for ; Thu, 19 Jan 2017 08:50:38 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5F112945A for ; Thu, 19 Jan 2017 08:50:38 -0800 (PST) Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-07v.sys.comcast.net with SMTP id UFuKcC7noebZfUFv3cLqa7; Thu, 19 Jan 2017 16:50:37 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-18v.sys.comcast.net with SMTP id UFv1c7lLq9HUeUFv2crriU; Thu, 19 Jan 2017 16:50:36 +0000 To: "Asveren, Tolga" , Henning Schulzrinne , SIPCORE References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Thu, 19 Jan 2017 11:50:35 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfH8p9lmAk7z6D21q1MLRnMK/qkqUcI7sEfZvrCuA/MmfLsH2XNDB9yEFa+PDykWbuFP3Kp2PmWvuyu23Ec5jQRsK6xUbEjOfPnOmENCdZsHKHC+xYRuM FlVAlJ8axfe+IOQIFz/pYPC9PZmSQUV3FUJsf5+4EuEba44xXcx36Ogw2MlTkWZ67IBQ3/AUwZJf9jcMhcitJHQ06imc15NsT2/aVxIG1Z93DADck2b6tBE6 I2WkzOKyiC0/wVSLC5pbwg== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 16:50:39 -0000 On 1/19/17 11:29 AM, Asveren, Tolga wrote: > Yes, that certainly there and is not something new but what is the rationale behind "not ringing" and even trying a "legitimate DN"? Or in other words, is there any additional concern arising from use of 666; AFAICS no. I guess it depends on what might happen on the 2nd and subsequent calls from that number. If there are no subsequent calls then it doesn't matter much. But the suggestion was for the recipient to use the receipt of 666 in cancel to suppress adding the number to the missed call list. If *these* calls are omitted from the missed call list then I won't know they occurred. Hence I won't be wary if I get subsequent calls. I don't know if this could be a threat or not. The point is that it is a use case that (with only local knowledge) is indistinguishable from the one that people have in mind. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >> Sent: Thursday, January 19, 2017 11:03 AM >> To: Paul Kyzivat ; Asveren, Tolga >> ; SIPCORE >> Subject: RE: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> I have heard that these are simply scanning attacks - trying to find open SIP >> proxies that can be used as intermediaries for hiding (DOS) attacks or spam, >> or to probe for poorly-secured systems to use for toll fraud. >> >> Google for "SIP scanner" and you'll find articles such as >> http://serverfault.com/questions/549134/how-can-i-stop-sipvicious- >> friendly-scanner-from-flooding-my-sip-server >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, January 19, 2017 10:59 AM >> To: Asveren, Tolga ; Henning Schulzrinne >> ; SIPCORE >> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> On 1/19/17 6:58 AM, Asveren, Tolga wrote: >>> I am having a hard time to understand the attack vector on this scenario. >> What is the attacker trying to achieve? >>> That a randomly chosen "number" is an actual DN? That information is >> already available in Yellow Pages or can be obtained relatively easily through >> "random walk". Invalid numbers will be rejected as "This number is not in >> service". >>> Or is the attacker trying to figure out the core-network entity SIP address >> (at least one of the many) associated with a DN? What would be the purpose >> of doing so? >>> >>> If there really is an issue here, it can be mitigated by the operator providing >> a portal/service number to report such numbers. This is not what 666 is >> intended for IMHO. Overall, I am happy that no text changes are foreseen >> due to this scenario. >> >> I don't know what the goal of the attack is. But there must be one, because it >> occurs with regularity. I get these multiple times per week, as do others I >> have asked about it. And querying the calling number typically turns up >> others who have received similar calls. >> >> Thanks, >> Paul >> >>> Thanks, >>> Tolga >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Wednesday, January 18, 2017 11:05 AM >>>> To: Asveren, Tolga ; Henning Schulzrinne >>>> ; SIPCORE >>>> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >>>> >>>> On 1/18/17 5:13 AM, Asveren, Tolga wrote: >>>>> How likely it is that that Bob's UE generates 180 but did not "ring" >>>>> before such an evil CANCEL is received? >>>> >>>> Hard to say. But this sort of behavior is not just theoretical. I get >>>> calls like this nearly every day. Sometimes I hear (1) ring, >>>> sometimes none. The charitable interpretation is that someone dialed >>>> a wrong number and realized immediately. But in my experience this is >>>> almost never the cause. I often follow up these, by checking the call >>>> log and googling the number. Usually I find many reports of bad behavior >> from that number. >>>> >>>>> The entity making use of Reason header, e .g. an Application Server >>>>> managing devices at a call center, can use Contact/Via headers to >>>>> determine the origin of CANCEL (well, unless there is a B2BUA >>>>> in-between; but then just as a note: nowadays it is not uncommon >>>>> that some B2BUAs can relay Via headers between two legs). >>>> >>>> I presume that typically the entity making use of the reason header >>>> will be the called UAS and/or the home proxy for the callee's AoR >>>> (probably the callee's SP.) The use case mentioned in this thread is >>>> by the UAS, when managing its own log of incoming calls. >>>> >>>> It is unclear to me whether common deployments would preserve the Via >>>> headers that would allow deciphering whether the cancel was due to >>>> forking or an overt action by the UAC. >>>> >>>>> Overall, I don't think there is something here which should cause us >>>>> to lose sleep. >>>> >>>> I'm not losing sleep over it. But the bad actors are not going to go >>>> away quietly once these new mechanisms are put in place. They will >>>> certainly seek out holes that can be exploited. So there is value in >>>> trying to close as many potential holes as we can. >>>> >>>> In any case I didn't see any obvious fix for this. But the >>>> consequence is the need to be careful not to ascribe too much meaning >>>> to the receipt of the 666 in cancel. >>>> >>>> Thanks, >>>> Paul >>> >>> > > From nobody Thu Jan 19 09:04:20 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC3612964D for ; Thu, 19 Jan 2017 09:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqTtQINz0Sno for ; Thu, 19 Jan 2017 09:04:12 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C901296AB for ; Thu, 19 Jan 2017 09:04:07 -0800 (PST) Received: from pps.filterd (m0102174.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0JH46KD027300; Thu, 19 Jan 2017 17:04:06 GMT Received: from gcc01-cy1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp0017.outbound.protection.outlook.com [23.103.198.17]) by mx0b-0024ed01.pphosted.com with ESMTP id 27yevv2cuk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Jan 2017 17:04:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=GooaY2TkPROLhO5JqLu24x/Ckxs4GikjBJIonCtoWiQ=; b=VxttI4Eu0hXk5QGJFqP5pmY55jASnoQyyO1Q2Twjcp2QlVuFsezhBbapTCKZx1te1GZ8f/dFVeBYpEm2U/4X8jVXDOpj7/XB7Y4/e9ZUDEWNo7DX+KjlNL9hiOaitp+68Oq40l+9XskVv2VTh7I+1FvzHFptiDqDIIfNyIOL+wg= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.12; Thu, 19 Jan 2017 17:04:03 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0845.021; Thu, 19 Jan 2017 17:04:04 +0000 From: Henning Schulzrinne To: Paul Kyzivat , "Asveren, Tolga" , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbekfpzK9A/mMxEW2UXxc6qTie6E6Bhn4gAQFPYCAAGH3gIABTZqAgABDKICAAABKkIAACDuAgAAF6ICAAAIg0A== Date: Thu, 19 Jan 2017 17:04:03 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: c9e10b67-cb56-442b-5290-08d4408d2c1e x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:Tmz8QKGRz0aFlUCWWo53LRYIAY+TnEHjblAZ0G0jkjv9iKEbOaDFHO94TzX4klB3NQA1dt38sZlCdWGpMxGg80yqycgoyYU8Qo59+ZOFqFv0bRD/UuLuJoyI8uDmjwfbwHdqeqa1MPycEhbZMVQdZfVIUco3I1HM2ZdwdGO+oho0S7nWBiI6qWNvkTDA3tFXKPZTOaOvFTj0ycarwxGvQjo3EX6isQGjHgw7ehwwXQdwO7bhBnDcIsOHALorWly5yKrSK1ws6a//Ow4+xrxb7aOhgl5FIeynLFhxCVc+ufGoRJCZxxpk0y4ss9vhG48Y4vmeb3tAEKOhCXjXwNxlAIKbQnzPFjKdMr+PYuhmtz+tjM/nw6EjNaCT0UR84RhcS7uGqhxbYpgO90FpRCjCzOslyhbheiORoJKRbSnaKioraJgD0TXAiKRiptiXGS6YUb5RteZTAbJlKy5t6AOX8g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(10436049006162)(275809806118684); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(24454002)(199003)(377454003)(13464003)(189002)(230783001)(7736002)(2906002)(9686003)(92566002)(2171001)(105586002)(122556002)(6116002)(102836003)(3846002)(53936002)(8936002)(33656002)(6306002)(68736007)(106356001)(106116001)(66066001)(25786008)(5660300001)(5001770100001)(107886002)(189998001)(77096006)(38730400001)(6436002)(74316002)(81166006)(8676002)(2950100002)(54356999)(81156014)(50986999)(3660700001)(55016002)(305945005)(99286003)(93886004)(7696004)(575784001)(229853002)(101416001)(6506006)(2900100001)(86362001)(97736004)(76176999)(3280700002)(26123001)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 17:04:03.8271 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-19_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 17:04:15 -0000 I think there's a difference between the average, non-technical user who wi= ll not be able to do anything useful with the bogus call information and wi= ll appreciate not having their calling list cluttered with robocalls, and t= he technical user, such as yourself and system administrators, who do need = this information. My sense is that logging and automated log analysis are b= etter suited to analyzing potential threats than small screens on desktop d= evices deployed on the desktop of administrative assistants. -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Thursday, January 19, 2017 11:51 AM To: Asveren, Tolga ; Henning Schulzrinne ; SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt On 1/19/17 11:29 AM, Asveren, Tolga wrote: > Yes, that certainly there and is not something new but what is the ration= ale behind "not ringing" and even trying a "legitimate DN"? Or in other wor= ds, is there any additional concern arising from use of 666; AFAICS no. I guess it depends on what might happen on the 2nd and subsequent calls fro= m that number. If there are no subsequent calls then it doesn't matter much= . But the suggestion was for the recipient to use the receipt of 666 in cance= l to suppress adding the number to the missed call list. If *these* calls a= re omitted from the missed call list then I won't know they occurred. Hence= I won't be wary if I get subsequent calls. I don't know if this could be a threat or not. The point is that it is a us= e case that (with only local knowledge) is indistinguishable from the one t= hat people have in mind. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >> Sent: Thursday, January 19, 2017 11:03 AM >> To: Paul Kyzivat ; Asveren, Tolga=20 >> ; SIPCORE >> Subject: RE: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> I have heard that these are simply scanning attacks - trying to find=20 >> open SIP proxies that can be used as intermediaries for hiding (DOS)=20 >> attacks or spam, or to probe for poorly-secured systems to use for toll = fraud. >> >> Google for "SIP scanner" and you'll find articles such as=20 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__serverfault.com_q >> uestions_549134_how-2Dcan-2Di-2Dstop-2Dsipvicious-2D&d=3DDwIC-g&c=3Dy0h0= o >> mCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D9A= G >> yoCJcrekSufonBTh9woDx8W9b3JlAz43e4Avy30c&s=3DGB-f66SfRxHY4yTRvGhaCTU7fs >> PaSh6CmxtuDRiWp-Q&e=3D friendly-scanner-from-flooding-my-sip-server >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, January 19, 2017 10:59 AM >> To: Asveren, Tolga ; Henning Schulzrinne=20 >> ; SIPCORE >> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> On 1/19/17 6:58 AM, Asveren, Tolga wrote: >>> I am having a hard time to understand the attack vector on this scenari= o. >> What is the attacker trying to achieve? >>> That a randomly chosen "number" is an actual DN? That information is >> already available in Yellow Pages or can be obtained relatively=20 >> easily through "random walk". Invalid numbers will be rejected as=20 >> "This number is not in service". >>> Or is the attacker trying to figure out the core-network entity SIP=20 >>> address >> (at least one of the many) associated with a DN? What would be the=20 >> purpose of doing so? >>> >>> If there really is an issue here, it can be mitigated by the=20 >>> operator providing >> a portal/service number to report such numbers. This is not what 666=20 >> is intended for IMHO. Overall, I am happy that no text changes are=20 >> foreseen due to this scenario. >> >> I don't know what the goal of the attack is. But there must be one,=20 >> because it occurs with regularity. I get these multiple times per=20 >> week, as do others I have asked about it. And querying the calling=20 >> number typically turns up others who have received similar calls. >> >> Thanks, >> Paul >> >>> Thanks, >>> Tolga >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Wednesday, January 18, 2017 11:05 AM >>>> To: Asveren, Tolga ; Henning Schulzrinne=20 >>>> ; SIPCORE >>>> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >>>> >>>> On 1/18/17 5:13 AM, Asveren, Tolga wrote: >>>>> How likely it is that that Bob's UE generates 180 but did not "ring" >>>>> before such an evil CANCEL is received? >>>> >>>> Hard to say. But this sort of behavior is not just theoretical. I=20 >>>> get calls like this nearly every day. Sometimes I hear (1) ring,=20 >>>> sometimes none. The charitable interpretation is that someone=20 >>>> dialed a wrong number and realized immediately. But in my=20 >>>> experience this is almost never the cause. I often follow up these,=20 >>>> by checking the call log and googling the number. Usually I find=20 >>>> many reports of bad behavior >> from that number. >>>> >>>>> The entity making use of Reason header, e .g. an Application=20 >>>>> Server managing devices at a call center, can use Contact/Via=20 >>>>> headers to determine the origin of CANCEL (well, unless there is a=20 >>>>> B2BUA in-between; but then just as a note: nowadays it is not=20 >>>>> uncommon that some B2BUAs can relay Via headers between two legs). >>>> >>>> I presume that typically the entity making use of the reason header=20 >>>> will be the called UAS and/or the home proxy for the callee's AoR=20 >>>> (probably the callee's SP.) The use case mentioned in this thread=20 >>>> is by the UAS, when managing its own log of incoming calls. >>>> >>>> It is unclear to me whether common deployments would preserve the=20 >>>> Via headers that would allow deciphering whether the cancel was due=20 >>>> to forking or an overt action by the UAC. >>>> >>>>> Overall, I don't think there is something here which should cause=20 >>>>> us to lose sleep. >>>> >>>> I'm not losing sleep over it. But the bad actors are not going to=20 >>>> go away quietly once these new mechanisms are put in place. They=20 >>>> will certainly seek out holes that can be exploited. So there is=20 >>>> value in trying to close as many potential holes as we can. >>>> >>>> In any case I didn't see any obvious fix for this. But the=20 >>>> consequence is the need to be careful not to ascribe too much=20 >>>> meaning to the receipt of the 666 in cancel. >>>> >>>> Thanks, >>>> Paul >>> >>> > > From nobody Thu Jan 19 10:46:13 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB59D1294BA for ; Thu, 19 Jan 2017 10:46:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=shockey.us Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tz7OQqKeqF6 for ; Thu, 19 Jan 2017 10:46:08 -0800 (PST) Received: from qproxy2.mail.unifiedlayer.com (qproxy2-pub.mail.unifiedlayer.com [69.89.16.161]) by ietfa.amsl.com (Postfix) with SMTP id 745B51294B5 for ; Thu, 19 Jan 2017 10:46:08 -0800 (PST) Received: (qmail 15303 invoked by uid 0); 19 Jan 2017 18:46:04 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by qproxy2.mail.unifiedlayer.com with SMTP; 19 Jan 2017 18:46:04 -0000 Received: from box462.bluehost.com ([74.220.219.62]) by cmgw3 with id aJh01u00j1MNPNq01Jh3Mh; Thu, 19 Jan 2017 11:41:04 -0700 X-Authority-Analysis: v=2.1 cv=YuCcGeoX c=1 sm=1 tr=0 a=jTEj1adHphCQ5SwrTAOQMg==:117 a=jTEj1adHphCQ5SwrTAOQMg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=1oJP67jkp3AA:10 a=IgFoBzBjUZAA:10 a=ZZnuYtJkoWoA:10 a=ll-iCDY8AAAA:8 a=M0OflfRGAAAA:8 a=48vgC7mUAAAA:8 a=kUVcWBOSAAAA:8 a=RpNjiQI2AAAA:8 a=RJ_VMX8EYEzh-XyB09QA:9 a=OmWhxRD8wIv4xy3S:21 a=9bkoSGGMGrZ6-3cS:21 a=QEXdDO2ut3YA:10 a=ivbTfD_dPm4A:10 a=VpyrLIdO_Ztbr3SWPBuH:22 a=6yl0mh0s51TKORVA8GqK:22 a=w1C3t2QeGrPiZgrLijVG:22 a=2fN0Ut44FUSjvWHL4tab:22 a=vJuR_VyAocOa-HWBgGQO:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=shockey.us; s=default; h=Content-transfer-encoding:Content-type:Mime-version:In-Reply-To :References:Message-ID:To:From:Subject:Date:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lpbCcq+YH8nHd9tq7rfq5UGR/QqcTONYJ5OO2J+IaYA=; b=KTzZ02Fw2G1pzBSEpd4YAhpq9G Yleys59xSKGU5UFc1dys5NJgFk4ME+VKZIS5ZIa037MTBx5ALT6R26aqSC7SHpZ5avGeuMa7UCWS8 gR8ErJN9bgeqeZ+PgCIh94A0t; Received: from pool-100-36-44-71.washdc.fios.verizon.net ([100.36.44.71]:57998 helo=[192.168.1.152]) by box462.bluehost.com with esmtpa (Exim 4.87) (envelope-from ) id 1cUHds-0001Ac-6K; Thu, 19 Jan 2017 11:41:00 -0700 User-Agent: Microsoft-MacOutlook/f.1e.0.170107 Date: Thu, 19 Jan 2017 13:40:58 -0500 From: Richard Shockey To: Henning Schulzrinne , Paul Kyzivat , "Asveren, Tolga" , SIPCORE Message-ID: <83237821-015C-49D3-9060-9E6A46B03880@shockey.us> Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box462.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - shockey.us X-BWhitelist: no X-Source-IP: 100.36.44.71 X-Exim-ID: 1cUHds-0001Ac-6K X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-36-44-71.washdc.fios.verizon.net ([192.168.1.152]) [100.36.44.71]:57998 X-Source-Auth: richard+shockey.us X-Email-Count: 3 X-Source-Cap: c2hvY2tleXU7c2hvY2tleXU7Ym94NDYyLmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:46:11 -0000 Big +1 to Henning=E2=80=99s observations here. In nearly all the discussions of = the SHAKEN framework there has been this concept of a data analytics engine = at the terminating service provider network that could compile data not just= from STIR validation but from a variety of sources such as 666 notification= s. Based on the clear consumer preference, the engine could take several ac= tions one of which might be to block the call or score the call and ultimate= ly present that data to the CUA under conditions that the consumer signs up = to.=20 I=E2=80=99m well aware of several companies developing these call analytics engin= es.=20 =E2=80=94=20 Richard Shockey Shockey Consulting LLC Chairman of the Board SIP Forum www.shockey.us www.sipforum.org richardshockey.us Skype-Linkedin-Facebook rshockey101 PSTN +1 703-593-2683 =20 On 1/19/17, 12:04 PM, "sipcore on behalf of Henning Schulzrinne" wrote: I think there's a difference between the average, non-technical user wh= o will not be able to do anything useful with the bogus call information and= will appreciate not having their calling list cluttered with robocalls, and= the technical user, such as yourself and system administrators, who do need= this information. My sense is that logging and automated log analysis are b= etter suited to analyzing potential threats than small screens on desktop de= vices deployed on the desktop of administrative assistants. =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: Thursday, January 19, 2017 11:51 AM To: Asveren, Tolga ; Henning Schulzrinne ; SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt =20 On 1/19/17 11:29 AM, Asveren, Tolga wrote: > Yes, that certainly there and is not something new but what is the ra= tionale behind "not ringing" and even trying a "legitimate DN"? Or in other = words, is there any additional concern arising from use of 666; AFAICS no. =20 I guess it depends on what might happen on the 2nd and subsequent calls= from that number. If there are no subsequent calls then it doesn't matter m= uch. =20 But the suggestion was for the recipient to use the receipt of 666 in c= ancel to suppress adding the number to the missed call list. If *these* call= s are omitted from the missed call list then I won't know they occurred. Hen= ce I won't be wary if I get subsequent calls. =20 I don't know if this could be a threat or not. The point is that it is = a use case that (with only local knowledge) is indistinguishable from the on= e that people have in mind. =20 Thanks, Paul =20 > Thanks, > Tolga > >> -----Original Message----- >> From: Henning Schulzrinne [mailto:Henning.Schulzrinne@fcc.gov] >> Sent: Thursday, January 19, 2017 11:03 AM >> To: Paul Kyzivat ; Asveren, Tolga=20 >> ; SIPCORE >> Subject: RE: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> I have heard that these are simply scanning attacks - trying to find= =20 >> open SIP proxies that can be used as intermediaries for hiding (DOS)= =20 >> attacks or spam, or to probe for poorly-secured systems to use for t= oll fraud. >> >> Google for "SIP scanner" and you'll find articles such as=20 >> https://urldefense.proofpoint.com/v2/url?u=3Dhttp-3A__serverfault.com_= q >> uestions_549134_how-2Dcan-2Di-2Dstop-2Dsipvicious-2D&d=3DDwIC-g&c=3Dy0h0= o >> mCe0jAUGr4gAQ02Fw&r=3DFJcVoDkWM5EiVcV0ReX8lDU1XeHIYRHfarpk4MK59RE&m=3D9A= G >> yoCJcrekSufonBTh9woDx8W9b3JlAz43e4Avy30c&s=3DGB-f66SfRxHY4yTRvGhaCTU7f= s >> PaSh6CmxtuDRiWp-Q&e=3D friendly-scanner-from-flooding-my-sip-server >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >> Sent: Thursday, January 19, 2017 10:59 AM >> To: Asveren, Tolga ; Henning Schulzrinne=20 >> ; SIPCORE >> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >> >> On 1/19/17 6:58 AM, Asveren, Tolga wrote: >>> I am having a hard time to understand the attack vector on this sce= nario. >> What is the attacker trying to achieve? >>> That a randomly chosen "number" is an actual DN? That information i= s >> already available in Yellow Pages or can be obtained relatively=20 >> easily through "random walk". Invalid numbers will be rejected as=20 >> "This number is not in service". >>> Or is the attacker trying to figure out the core-network entity SIP= =20 >>> address >> (at least one of the many) associated with a DN? What would be the=20 >> purpose of doing so? >>> >>> If there really is an issue here, it can be mitigated by the=20 >>> operator providing >> a portal/service number to report such numbers. This is not what 666= =20 >> is intended for IMHO. Overall, I am happy that no text changes are=20 >> foreseen due to this scenario. >> >> I don't know what the goal of the attack is. But there must be one,=20 >> because it occurs with regularity. I get these multiple times per=20 >> week, as do others I have asked about it. And querying the calling=20 >> number typically turns up others who have received similar calls. >> >> Thanks, >> Paul >> >>> Thanks, >>> Tolga >>> >>>> -----Original Message----- >>>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] >>>> Sent: Wednesday, January 18, 2017 11:05 AM >>>> To: Asveren, Tolga ; Henning Schulzrinne=20 >>>> ; SIPCORE >>>> Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt >>>> >>>> On 1/18/17 5:13 AM, Asveren, Tolga wrote: >>>>> How likely it is that that Bob's UE generates 180 but did not "ri= ng" >>>>> before such an evil CANCEL is received? >>>> >>>> Hard to say. But this sort of behavior is not just theoretical. I=20 >>>> get calls like this nearly every day. Sometimes I hear (1) ring,=20 >>>> sometimes none. The charitable interpretation is that someone=20 >>>> dialed a wrong number and realized immediately. But in my=20 >>>> experience this is almost never the cause. I often follow up these= ,=20 >>>> by checking the call log and googling the number. Usually I find=20 >>>> many reports of bad behavior >> from that number. >>>> >>>>> The entity making use of Reason header, e .g. an Application=20 >>>>> Server managing devices at a call center, can use Contact/Via=20 >>>>> headers to determine the origin of CANCEL (well, unless there is = a=20 >>>>> B2BUA in-between; but then just as a note: nowadays it is not=20 >>>>> uncommon that some B2BUAs can relay Via headers between two legs)= . >>>> >>>> I presume that typically the entity making use of the reason heade= r=20 >>>> will be the called UAS and/or the home proxy for the callee's AoR=20 >>>> (probably the callee's SP.) The use case mentioned in this thread=20 >>>> is by the UAS, when managing its own log of incoming calls. >>>> >>>> It is unclear to me whether common deployments would preserve the=20 >>>> Via headers that would allow deciphering whether the cancel was du= e=20 >>>> to forking or an overt action by the UAC. >>>> >>>>> Overall, I don't think there is something here which should cause= =20 >>>>> us to lose sleep. >>>> >>>> I'm not losing sleep over it. But the bad actors are not going to=20 >>>> go away quietly once these new mechanisms are put in place. They=20 >>>> will certainly seek out holes that can be exploited. So there is=20 >>>> value in trying to close as many potential holes as we can. >>>> >>>> In any case I didn't see any obvious fix for this. But the=20 >>>> consequence is the need to be careful not to ascribe too much=20 >>>> meaning to the receipt of the 666 in cancel. >>>> >>>> Thanks, >>>> Paul >>> >>> > > =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =20 From nobody Fri Jan 20 07:42:33 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF08E1295FB for ; Fri, 20 Jan 2017 07:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=sonusnetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adKp5vX5aeD5 for ; Fri, 20 Jan 2017 07:42:29 -0800 (PST) Received: from us-smtp-delivery-211.mimecast.com (us-smtp-delivery-211.mimecast.com [63.128.21.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9221C129418 for ; Fri, 20 Jan 2017 07:42:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=npyKWwoUg+CqW4BpoGj6ADxHmMP0RtT4xLVmWv2W3N8=; b=qdtdjS960+97QYfXs2Lkq7nN0n0b5UVzTs0kYz8hk49232si8LsjbwT8FERDWfSpO6TmdtAsCCaxFpKwbtQZktXTnJqWrq/3oRCqVDVEIlqkUT7IlohKAsHBWm6h4F0yTRvpSjwG5+5vRbqoGqxzg241XP/r1nDOD0vKGj4PQmg= Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0049.outbound.protection.outlook.com [207.46.163.49]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-68-E1TupI3EO5eL4I-w_5Jp2Q-1; Fri, 20 Jan 2017 10:42:24 -0500 Received: from SN2PR03MB2350.namprd03.prod.outlook.com (10.166.210.141) by SN2PR03MB2349.namprd03.prod.outlook.com (10.166.210.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Fri, 20 Jan 2017 15:42:22 +0000 Received: from SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) by SN2PR03MB2350.namprd03.prod.outlook.com ([10.166.210.141]) with mapi id 15.01.0860.012; Fri, 20 Jan 2017 15:42:22 +0000 From: "Asveren, Tolga" To: SIPCORE Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbR48ZXJuKW6cY06w++3U64zxKaFBizbg Date: Fri, 20 Jan 2017 15:42:21 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> In-Reply-To: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 037be8e8-c5ce-41b7-0b9c-08d4414aecca x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SN2PR03MB2349; x-microsoft-exchange-diagnostics: 1; SN2PR03MB2349; 7:wly6aTiFA02WImKk5y0hrJ7AAo4nOLe5wJryBA3keoCyAc0dSk6d36ygximBqDScNgkBUQGy7r26LrIfAN5qbnwjk4wj2uUl1REPKRtGNxS9rUCr36JgmHlcpAozY91ZSGCmhfPiW/gVrptM5OOJDNJD5QmUHsvKn5QvOTtxlrK35i++JZG3vqWNQga739/h5c1GmxGrh8jxQ8aC86V7ExHyMLu0fKE/P0jvekIWNmi8jhvBv7JMd+XQnP5vJdhGsPSuvzmGUHXzFz/l2kN1C4HC8hAiiHJIMlF3DOK20kndzH1ITRjFo/ZrW9RPnhrXsE/rOWK3R3aj1xIh1TsxuZMkpLt53emuTZHH5Ncd409elhIiRNfi3qaSVzrkmesYpxCP3YlAdIf5WxQnTOJ7UQymBIBoaZi9NQBNclAXs1pTo+Biy3d9yoHENlMzs0oYin8s0v71n+iRKizzycppsQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148)(6047074); SRVR:SN2PR03MB2349; BCL:0; PCL:0; RULEID:; SRVR:SN2PR03MB2349; x-forefront-prvs: 01930B2BA8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(13464003)(377424004)(199003)(377454003)(107886002)(97736004)(50986999)(3660700001)(76176999)(54356999)(101416001)(53936002)(189998001)(33656002)(7736002)(305945005)(74316002)(106356001)(105586002)(3280700002)(450100001)(106116001)(2906002)(122556002)(9686003)(230783001)(2900100001)(86362001)(3846002)(102836003)(6116002)(92566002)(25786008)(2950100002)(6916009)(7696004)(110136003)(66066001)(5660300001)(6306002)(229853002)(77096006)(55016002)(81166006)(81156014)(68736007)(8676002)(38730400001)(6506006)(6436002)(8936002)(99286003)(26123001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN2PR03MB2349; H:SN2PR03MB2350.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jan 2017 15:42:21.9830 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR03MB2349 X-MC-Unique: E1TupI3EO5eL4I-w_5Jp2Q-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:42:32 -0000 I reviewed this version and it looks ready for WGLC. I only have the following suggestion: The called user agent (UAS), based on input from the called party or some UA-internal logic, uses this to indicate that future calls from the same caller are also unwanted. =3D> The called user agent (UAS), based on input from the called party or some UA-internal logic, uses this to indicate that this call is unwanted. I know I keep harping on this -and will stop doing so after this time- but = this change IMHO would highlight a philosophically important point and not = being clear on this aspect has been the root cause of many discussions so f= ar AFAICS -and likely to cause confusing on future readers of the specifica= tion, who were not part of thereof-. Thanks, Tolga > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Thursday, January 12, 2017 4:52 PM > To: i-d-announce@ietf.org > Cc: sipcore@ietf.org > Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core of the = IETF. >=20 > Title : A SIP Response Code for Unwanted Calls > Author : Henning Schulzrinne > =09Filename : draft-ietf-sipcore-status-unwanted-02.txt > =09Pages : 7 > =09Date : 2017-01-12 >=20 > Abstract: > This document defines the 666 (Unwanted) SIP response code, allowing > called parties to indicate that the call or message was unwanted. > SIP entities may use this information to adjust how future calls from > this calling party are handled for the called party or more broadly. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-02 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-status-unwanted-02 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Fri Jan 20 10:29:25 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 733A71293F9 for ; Fri, 20 Jan 2017 10:29:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uviB2CFlhs-5 for ; Fri, 20 Jan 2017 10:29:22 -0800 (PST) Received: from alum-mailsec-scanner-5.mit.edu (alum-mailsec-scanner-5.mit.edu [18.7.68.17]) by ietfa.amsl.com (Postfix) with ESMTP id AF7AF1295C0 for ; Fri, 20 Jan 2017 10:29:22 -0800 (PST) X-AuditID: 12074411-fbbff700000009b7-b7-58825701a9d2 Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by alum-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id EC.C2.02487.10752885; Fri, 20 Jan 2017 13:29:21 -0500 (EST) Received: from [192.168.1.110] (c-73-186-127-100.hsd1.ma.comcast.net [73.186.127.100]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id v0KITKOx018897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Fri, 20 Jan 2017 13:29:20 -0500 To: sipcore@ietf.org References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: Date: Fri, 20 Jan 2017 13:29:19 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDIsWRmVeSWpSXmKPExsUixO6iqMsY3hRhsPuVscXXH5vYHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMW3eCcaCc1IVk7c9ZW9gnC3axcjJISFgInFs7R/2LkYuDiGB y4wSP39fYYVw3jFJTPn1nQ2kSljAR+L+vS1MILaIgIjEs+n/2CCKFjBKPJ3awgiSYBPQkphz 6D8LiM0rYC+xqW0OM4jNIqAq8f/LLVYQW1QgTeLBya2MEDWCEidnPgGr5xSIldjxbQaYzSxg K3Fn7m5mCFteYvvbOcwTGPlmIWmZhaRsFpKyBYzMqxjlEnNKc3VzEzNzilOTdYuTE/PyUot0 TfVyM0v0UlNKNzFCAk1wB+OMk3KHGAU4GJV4eC+ENEUIsSaWFVfmHmKU5GBSEuXd/bEhQogv KT+lMiOxOCO+qDQntfgQowQHs5II7yMvoHLelMTKqtSifJiUNAeLkjgv3xJ1PyGB9MSS1OzU 1ILUIpisDAeHkgTvvVCgRsGi1PTUirTMnBKENBMHJ8hwHqDhnSA1vMUFibnFmekQ+VOMilLi vExhQAkBkERGaR5cLywRvGIUB3pFmJcRpIoHmETgul8BDWYCGmylXA8yuCQRISXVwJggHPMo 9uyyagmr4sdbTx01PF/e9UDj08ONV3dyrjzX4WNS6eMZHSCU8OiJA0/m2mkGL4XTz0TmRa69 eiZ1zXrFSxWX1rguVtHft/TCtiu2ySt/TCzo7ntaY18Yd+LAOuXKH7YxhYdPCRRcPvnv2H/T e780GK8+F5J5by7zQ/9CS4rnrgU6E34qsRRnJBpqMRcVJwIAoYY/Q98CAAA= Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 18:29:24 -0000 On 1/20/17 10:42 AM, Asveren, Tolga wrote: > I reviewed this version and it looks ready for WGLC. > > I only have the following suggestion: > > The called user > agent (UAS), based on input from the called party or some UA-internal > logic, uses this to indicate that future calls from the same caller > are also unwanted. > => > The called user > agent (UAS), based on input from the called party or some UA-internal > logic, uses this to indicate that this call is unwanted. > > I know I keep harping on this -and will stop doing so after this time- but this change IMHO would highlight a philosophically important point and not being clear on this aspect has been the root cause of many discussions so far AFAICS -and likely to cause confusing on future readers of the specification, who were not part of thereof-. I support this. In principle this is a choice we can make. But it is important for the end user who is pushing the button to understand which meaning it is. Getting end users to internalize this distinction will be difficult. I'm inclined to think that it will be easier for people to grasp the meaning "I don't want this call". Of course we intend to use this feedback to identify callers whose calls are unwanted. But I think that is an inference rather than a consequence. Thanks, Paul > Thanks, > Tolga > >> -----Original Message----- >> From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Thursday, January 12, 2017 4:52 PM >> To: i-d-announce@ietf.org >> Cc: sipcore@ietf.org >> Subject: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Session Initiation Protocol Core of the IETF. >> >> Title : A SIP Response Code for Unwanted Calls >> Author : Henning Schulzrinne >> Filename : draft-ietf-sipcore-status-unwanted-02.txt >> Pages : 7 >> Date : 2017-01-12 >> >> Abstract: >> This document defines the 666 (Unwanted) SIP response code, allowing >> called parties to indicate that the call or message was unwanted. >> SIP entities may use this information to adjust how future calls from >> this calling party are handled for the called party or more broadly. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-sipcore-status-unwanted/ >> >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-ietf-sipcore-status-unwanted-02 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-status-unwanted-02 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sun Jan 22 18:22:13 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B30E129560 for ; Sun, 22 Jan 2017 18:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.035 X-Spam-Level: X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rXoBkykkfZRZ for ; Sun, 22 Jan 2017 18:22:11 -0800 (PST) Received: from resqmta-po-06v.sys.comcast.net (resqmta-po-06v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:165]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 153DB129559 for ; Sun, 22 Jan 2017 18:22:10 -0800 (PST) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-06v.sys.comcast.net with SMTP id VUFucqaTaFWWvVUGnc7B7c; Mon, 23 Jan 2017 02:22:09 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-09v.sys.comcast.net with SMTP id VUGlcvjyrcScxVUGmcYLjm; Mon, 23 Jan 2017 02:22:08 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v0N2M6YP002491; Sun, 22 Jan 2017 21:22:06 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v0N2M6bV002488; Sun, 22 Jan 2017 21:22:06 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Asveren\, Tolga" In-Reply-To: (tasveren@sonusnet.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 22 Jan 2017 21:22:06 -0500 Message-ID: <87bmuyldm9.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfMocdxZMphdTHan+IKvQNwaOmhGktuNC1CdWqS9E3Nese0tFfEnKYtQjRzXRK1Qon/JgDru7aGPHCzmx8A1keYy6vFOADaNY1+U+VhxTlHbgQgk6e2v0 R7ehtWHC+Y1T9/A+mIaISFxSe3xVuEv/mbVcwS49FtXfgWEzRAysDJUKBp+CHRfEEpbd1NArYz/d0g== Archived-At: Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 02:22:12 -0000 "Asveren, Tolga" writes: > I only have the following suggestion: > > The called user > agent (UAS), based on input from the called party or some UA-internal > logic, uses this to indicate that future calls from the same caller > are also unwanted. > => > The called user > agent (UAS), based on input from the called party or some UA-internal > logic, uses this to indicate that this call is unwanted. > > I know I keep harping on this -and will stop doing so after this time- > but this change IMHO would highlight a philosophically important point > and not being clear on this aspect has been the root cause of many > discussions so far AFAICS -and likely to cause confusing on future > readers of the specification, who were not part of thereof-. It seems to me that this is very important. We want to make sure the *meaning* of the 666 response is well-defined. Otherwise, we will have an interoperability nightmare. And the meaning that we can define and that the user can understand is "I don't like this call." But it's messy to go from that to any particular inference as to which future calls should be automatically rejected. The current text says "from the same caller", but we've discovered that it's impossible to provide a clear definition of that (at least at this time). I think it's a lot better to leave the decision-making process open to future research. Dale From nobody Mon Jan 23 08:53:40 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD7AF1295AE; Mon, 23 Jan 2017 08:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zu2hHWO588JF; Mon, 23 Jan 2017 08:53:37 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63DAD1295AD; Mon, 23 Jan 2017 08:53:37 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0NGrUVG030559 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 23 Jan 2017 10:53:31 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: SIPCORE Date: Mon, 23 Jan 2017 10:53:30 -0600 Message-ID: In-Reply-To: <20170123164212.40CBCB8261C@rfc-editor.org> References: <20170123164212.40CBCB8261C@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: msoroush@gmail.com, aamelnikov@fastmail.fm, alissa@cooperw.in, bliss@ietf.org, vvenkatar@gmail.com, shida@ntt-at.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC7463 (4915) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 16:53:38 -0000 (Adding SIPCORE) What do people think of this errata report? Has anyone experienced interop problems due to the described issue? Thanks! Ben. On 23 Jan 2017, at 10:42, RFC Errata System wrote: > The following errata report has been submitted for RFC7463, > "Shared Appearances of a Session Initiation Protocol (SIP) Address of > Record (AOR)". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7463&eid=4915 > > -------------------------------------- > Type: Editorial > Reported by: Brett Tate > > Section: GLOBAL > > Original Text > ------------- > To: ;tag=428765950880801 > > Corrected Text > -------------- > To: > > Notes > ----- > PUBLISH must not contain To tag unless sending within dialog. The To > tag (428765950880801) appears to be extraneous within the following > SIP messages since there is no explanation about which dialog is being > shared: section 11.7 F32, section 11.9 F32, section 11.10 F22, and > section 11.14 F48. The To/From URI values within section 11.7 F32 > also should be swapped since it does not appear to be intentional and > is different than the other examples indicating To tag value > 428765950880801. > > Section 11.4 F2 also has To tag issues since a To tag must be present > to comply with RFC 3261. Section 11.6 F28 also should not be missing > a To tag. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7463 (draft-ietf-bliss-shared-appearances-15) > -------------------------------------- > Title : Shared Appearances of a Session Initiation > Protocol (SIP) Address of Record (AOR) > Publication Date : March 2015 > Author(s) : A. Johnston, Ed., M. Soroushnejad, Ed., V. > Venkataramanan > Category : PROPOSED STANDARD > Source : Basic Level of Interoperability for SIP Services > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG From nobody Mon Jan 23 10:20:05 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C34B129735 for ; Mon, 23 Jan 2017 10:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aGTM4cYIpjW for ; Mon, 23 Jan 2017 10:20:01 -0800 (PST) Received: from mx0a-001d8301.pphosted.com (mx0a-001d8301.pphosted.com [67.231.149.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D081C129731 for ; Mon, 23 Jan 2017 10:20:01 -0800 (PST) Received: from pps.filterd (m0103509.ppops.net [127.0.0.1]) by mx0a-001d8301.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0NIESeS025130 for ; Mon, 23 Jan 2017 13:20:01 -0500 Received: from mail-lf0-f69.google.com (mail-lf0-f69.google.com [209.85.215.69]) by mx0a-001d8301.pphosted.com with ESMTP id 2843txkjww-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 23 Jan 2017 13:20:01 -0500 Received: by mail-lf0-f69.google.com with SMTP id x1so64690273lff.6 for ; Mon, 23 Jan 2017 10:20:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to:cc; bh=0wZGjeeJmfFX81fkR15n2YfHSLI4TdIdPMQEcxSTGRA=; b=oUakqZMyyKvnVxL+Pk1K4KyqAgkGeDDyOt82w0UZrRiK96zW/5LtX7LUlN6tBvgbeV s+XqF0lyOYw2+VTqQms1UUUiIxcwK6r+ZGJ0HYHEX5IqchS1/g0G6sOYP3A4hkrJK7w1 LQ5oaosZjtLLxgnXugVLVipDlHQGRb/LVjow3hjijIoeGT7rKZL5tpJ3SI/dTAo/DOXH HOq5It490IZAm2JgLFtLBTX0ytd9arttvBoe4c8WgLu4VzLp3+E2yD3DdpMzajhkyCaz le8WPY5x7p41ZK5Vd+gsQGWx3BkSE3nzzhOnXc+qfyyaeoV2s+JCzQBxtrkts6u74264 4Grg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to:cc; bh=0wZGjeeJmfFX81fkR15n2YfHSLI4TdIdPMQEcxSTGRA=; b=Yg4P+9GdbHUFeK0Bhux63kinM/TOGQDlZY0yoVDHBobSgfrLEOWq8FfMXGjqGkb7nm uXMVgMp7Kc2BFJ2VZF+XZA2RrLMJp0K4/cGRb4SYAyiAXX54BWFkmxnDwLg6mX0fqLsF sxPxyI4wCVZajwKpmmtKyXx08flwQRXwvLlWaD8SUb8og9TmSMcud53jMQunw7+fprFn IJSt0ydDTLVKuPjjjipksFc6+mkHqFFESMIxO4zuz/bPDUzQDn6vT4AIj4cbMEC+hJp3 Z0Jlr/5Hdbk/OhvTrDlzWGWgkjb1RxnME2HyUE7Z3UcyvVM6B0pLTRtvFKKgwHbmOYnr cSjg== X-Gm-Message-State: AIkVDXIN3KBh471Dso+rnCc83Hv44o8O3XK0OaZNqmsAcO3hOG39zXlWyBfmHwZfpYN99cb8s3Qnf1Zpd+8kcyzrIvDW5UkXqN2gkJNzyM7OGUb1bI+b3me29qqf9f2SEIsQRZ1NGmRWzk7g X-Received: by 10.46.14.26 with SMTP id 26mr8245487ljo.59.1485195598768; Mon, 23 Jan 2017 10:19:58 -0800 (PST) X-Received: by 10.46.14.26 with SMTP id 26mr8245481ljo.59.1485195598486; Mon, 23 Jan 2017 10:19:58 -0800 (PST) From: Brett Tate References: <20170123164212.40CBCB8261C@rfc-editor.org> In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIMcYhOT0q5/xkOiOD0pW6sTQ/YhwGffYLBoMVZ/cA= Date: Mon, 23 Jan 2017 13:19:56 -0500 Message-ID: <47691faf5fc0859886d2f6266bb9eea2@mail.gmail.com> To: Ben Campbell , SIPCORE Content-Type: text/plain; charset=UTF-8 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-23_15:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: msoroush@gmail.com, aamelnikov@fastmail.fm, alissa@cooperw.in, bliss@ietf.org, vvenkatar@gmail.com, shida@ntt-at.com Subject: Re: [sipcore] [Editorial Errata Reported] RFC7463 (4915) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 18:20:03 -0000 Hi, I'm not aware of interoperability issues due to what is reported within the errata. I've only seen it indirectly cause issues within related documentation (not code). After some discussion within sip-implementors, I reported the errata as editorial to help others and myself understand the examples and basic SIP. I also reported it to help ensure corrected within rfc7463bis (if ever actually needed). Sorry about not splitting up the report into multiple errata. However, it didn't seem worth the effort to report/discuss the items separately. Thanks, Brett > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: Monday, January 23, 2017 11:54 AM > To: SIPCORE > Cc: alan.b.johnston@gmail.com; msoroush@gmail.com; vvenkatar@gmail.com; > alissa@cooperw.in; aamelnikov@fastmail.fm; shida@ntt-at.com; > brett@broadsoft.com; bliss@ietf.org > Subject: Re: [Editorial Errata Reported] RFC7463 (4915) > > (Adding SIPCORE) > > What do people think of this errata report? Has anyone experienced interop > problems due to the described issue? > > Thanks! > > Ben. > > On 23 Jan 2017, at 10:42, RFC Errata System wrote: > > > The following errata report has been submitted for RFC7463, "Shared > > Appearances of a Session Initiation Protocol (SIP) Address of Record > > (AOR)". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata_search.php?rfc=7463&eid=4915 > > > > -------------------------------------- > > Type: Editorial > > Reported by: Brett Tate > > > > Section: GLOBAL > > > > Original Text > > ------------- > > To: ;tag=428765950880801 > > > > Corrected Text > > -------------- > > To: > > > > Notes > > ----- > > PUBLISH must not contain To tag unless sending within dialog. The To > > tag (428765950880801) appears to be extraneous within the following > > SIP messages since there is no explanation about which dialog is being > > shared: section 11.7 F32, section 11.9 F32, section 11.10 F22, and > > section 11.14 F48. The To/From URI values within section 11.7 F32 > > also should be swapped since it does not appear to be intentional and > > is different than the other examples indicating To tag value > > 428765950880801. > > > > Section 11.4 F2 also has To tag issues since a To tag must be present > > to comply with RFC 3261. Section 11.6 F28 also should not be missing > > a To tag. > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or rejected. > > When a decision is reached, the verifying party can log in to change > > the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC7463 (draft-ietf-bliss-shared-appearances-15) > > -------------------------------------- > > Title : Shared Appearances of a Session Initiation > > Protocol (SIP) Address of Record (AOR) > > Publication Date : March 2015 > > Author(s) : A. Johnston, Ed., M. Soroushnejad, Ed., V. > > Venkataramanan > > Category : PROPOSED STANDARD > > Source : Basic Level of Interoperability for SIP Services > > Area : Real-time Applications and Infrastructure > > Stream : IETF > > Verifying Party : IESG From nobody Mon Jan 23 14:13:29 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324FD12997D for ; Mon, 23 Jan 2017 14:13:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q0RWuxdogNDI for ; Mon, 23 Jan 2017 14:13:26 -0800 (PST) Received: from mx0b-0024ed01.pphosted.com (mx0b-0024ed01.pphosted.com [148.163.153.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068CA129979 for ; Mon, 23 Jan 2017 14:13:25 -0800 (PST) Received: from pps.filterd (m0102175.ppops.net [127.0.0.1]) by mx0b-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0NMADTJ011228; Mon, 23 Jan 2017 22:13:24 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0051.outbound.protection.outlook.com [23.103.198.51]) by mx0b-0024ed01.pphosted.com with ESMTP id 283yfuhb6j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Jan 2017 22:13:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BQEQ0fcP8igLp3pIwfIbbeDiMN1QiRpt5itU/Oa+8/g=; b=COqkTOZQklCotiSDOQL0mCaPgDLdqbmyLUoun6IPYvial5uI43B9FSfEst5SzmvCZAXvBBp2+zejbimgfeq1tGbJuT11JMpaKUTQHFVnTO/XbO1Tb3jbY42cjrbp1VKS4QzdMNo4XFf7/NfqfpVpq9pI0Kk73uA/6FacX1nbJUk= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0633.namprd09.prod.outlook.com (10.160.151.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 22:13:23 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 22:13:23 +0000 From: Henning Schulzrinne To: "Asveren, Tolga" , SIPCORE Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbR44Vm/4zmd4kkm6+6vQdT/20KFBjVaAgAUjT+A= Date: Mon, 23 Jan 2017 22:13:22 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 6c8156ef-5084-4900-2ebb-08d443dd0bda x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0633; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0633; 7:4zl2Mz6YmEwQulIad3EqgKPamfrtjAQM8sQw1VbtBOy8B9xDwDz/zg+L5mFzDe3ME4Y873j6WHa9JLU+rL9zYXq+JsZanRIS4TAdHDc+H4VT7Cgfy8EbQcMrq8Wvoj9zbIob+JHS50rQHp0NXGbgbshV9hkszPji39ubeMuNUP4jF3oZcBwv1s2rcYmslP5BAq5hJf5lzvRdQofVivG6y1eroIZPi2yN6b262CFfdMSv4kTuS32YlhvWmx7KIT90uJ4S+lkncW/EcdmliSqUcju7coYgbkTgglUL+vtO1yRDQAMf9uIpUf9MNuzo1VU0aDVVa5BEvtq9FbccQfLfU8BfxQD+VYuHRSeqTGZAKa5CBRPqFBGxpnxSL4xbnua+sB2XEVQE4bESHbRwnwVlrkIAlgngjjj0wxqcINyU1u3+H1wAGVx/FBLf6BSrT0/imcbJTVVVol73YbKH8+ylVQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558021)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR09MB0633; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0633; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(189002)(199003)(13464003)(377454003)(2906002)(68736007)(229853002)(101416001)(50986999)(3846002)(305945005)(6116002)(102836003)(54356999)(76176999)(105586002)(33656002)(3280700002)(7736002)(74316002)(7696004)(9686003)(106356001)(106116001)(86362001)(55016002)(6306002)(99286003)(2950100002)(66066001)(25786008)(5001770100001)(97736004)(107886002)(53936002)(5660300001)(8676002)(8936002)(81156014)(3660700001)(2900100001)(77096006)(81166006)(38730400001)(230783001)(92566002)(6506006)(6436002)(122556002)(189998001)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0633; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 22:13:23.0122 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0633 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-23_19:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:13:28 -0000 This will be updated in the next version. (I believe the WGLC concluded a = while ago: https://www.ietf.org/mail-archive/web/sipcore/current/msg07560.html That said, unless the user believes that this will improve behavior for fut= ure calls, they might as well just vent on Twitter or FB. Henning -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Asveren, Tolga Sent: Friday, January 20, 2017 10:42 AM To: SIPCORE Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.tx= t I reviewed this version and it looks ready for WGLC. I only have the following suggestion: The called user agent (UAS), based on input from the called party or some UA-internal logic, uses this to indicate that future calls from the same caller are also unwanted. =3D> The called user agent (UAS), based on input from the called party or some UA-internal logic, uses this to indicate that this call is unwanted. I know I keep harping on this -and will stop doing so after this time- but = this change IMHO would highlight a philosophically important point and not = being clear on this aspect has been the root cause of many discussions so f= ar AFAICS -and likely to cause confusing on future readers of the specifica= tion, who were not part of thereof-. =20 From nobody Mon Jan 23 14:19:09 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6C3129979 for ; Mon, 23 Jan 2017 14:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdqt-DV5058K for ; Mon, 23 Jan 2017 14:19:06 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FDA1129864 for ; Mon, 23 Jan 2017 14:19:06 -0800 (PST) Received: from pps.filterd (m0102173.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0NMIx91031655; Mon, 23 Jan 2017 22:19:02 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0048.outbound.protection.outlook.com [23.103.198.48]) by mx0a-0024ed01.pphosted.com with ESMTP id 2840erhhab-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 Jan 2017 22:19:02 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZblisSIpGd0iVYqLVNpedOsJJBNJXXIiUDXyjHoH/QM=; b=QXk71Avy15SJilLy0ZDF6pChG3xGmAOT8AKgoCNITLLRGncId76dR/W3OWjIbfVyIls7tuJAbJCH9bGZ2FgBsgoUE1eVu+RmLYQcW08AJdbb18dxUnTOTuXHl85PcRJPMJUZZEFhi2qxB1zdXCjQc6lFA/ngOiUDTwFRjf1Pmf0= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0635.namprd09.prod.outlook.com (10.160.151.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 22:18:59 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 22:18:59 +0000 From: Henning Schulzrinne To: "Dale R. Worley" , "Asveren, Tolga" Thread-Topic: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSdR99Vm/4zmd4kkm6+6vQdT/20KFGojyA Date: Mon, 23 Jan 2017 22:18:59 +0000 Message-ID: References: (tasveren@sonusnet.com) <87bmuyldm9.fsf@hobgoblin.ariadne.com> In-Reply-To: <87bmuyldm9.fsf@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: 06f18ead-8dd8-4e34-7ac2-08d443ddd432 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0635; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0635; 7:VLW57laRgpkmx7KHjEPQkw45mK9XCqRR/wtTiHrnYDrtcuaEkkQZ1WHePWhlfAf/jJVi2Z4xE7pXSQB9XnN8BxBkbd7vkCBuVj9gJRE7QpyIqJ1KrH0jZiQmCG661OhfMUyM0fEaAmhLKemoZl9/oIGm9m13M2qXSaoXU7JHEHe/1ocDNc8MdIdWZCrOTMVB64nfCUwBJPJObReyLPaAv7VsgNPSFvDUSYjsVAAmoJAHGRavRABJRTPHQNwXFuIpqH+pXK6eCMggcZrBWjhoSRmSOKHTFe9EtzYqWkJd8Vnbz0tmYQ4v/Z5+OWIUS3HahLQhulSbOzLyUFbOomV+qPJKqG2s3nqdyjdlJRCNmN7CfRfCF3hU9ebLQLLZs54WhrUbHXntDknOl9hsDaxWtPdDhJnFEqYTTOeztBcjBui/wgeVzAujWZ0XcAWKANj4b91ghVpaYUhWXBEcA2NRdA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148); SRVR:CY1PR09MB0635; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0635; x-forefront-prvs: 0196A226D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(13464003)(189002)(199003)(377454003)(74316002)(305945005)(105586002)(8676002)(8936002)(3660700001)(53936002)(106356001)(3280700002)(4326007)(106116001)(6116002)(81166006)(2906002)(81156014)(68736007)(102836003)(3846002)(7736002)(229853002)(97736004)(55016002)(5660300001)(77096006)(101416001)(54356999)(86362001)(76176999)(189998001)(230783001)(99286003)(92566002)(5001770100001)(50986999)(66066001)(33656002)(25786008)(9686003)(2950100002)(2900100001)(7696004)(6506006)(38730400001)(122556002)(6436002)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0635; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 22:18:59.0471 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0635 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-23_19:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Cc: "sipcore@ietf.org" Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2017 22:19:07 -0000 While there were *some* cases where there might be ambiguity who is really = calling, hopefully STIR will yield a fair and increasing fraction of calls = where this is pretty clear, particularly for the typical robocall (i.e., wi= thout forwarding and other special treatments). I suspect we all agree that the details as to the statistical handling of 6= 66 reports for blocking or other specialized call treatment is well beyond = the scope of this draft (or the IETF, most likely). -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Sunday, January 22, 2017 9:22 PM To: Asveren, Tolga Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-status-unwanted-02.tx= t "Asveren, Tolga" writes: > I only have the following suggestion: > > The called user > agent (UAS), based on input from the called party or some UA-internal > logic, uses this to indicate that future calls from the same caller > are also unwanted. > =3D> > The called user > agent (UAS), based on input from the called party or some UA-internal > logic, uses this to indicate that this call is unwanted. > > I know I keep harping on this -and will stop doing so after this time-=20 > but this change IMHO would highlight a philosophically important point=20 > and not being clear on this aspect has been the root cause of many=20 > discussions so far AFAICS -and likely to cause confusing on future=20 > readers of the specification, who were not part of thereof-. It seems to me that this is very important. We want to make sure the *meaning* of the 666 response is well-defined. Otherwise, we will have an = interoperability nightmare. And the meaning that we can define and that th= e user can understand is "I don't like this call." But it's messy to go from that to any particular inference as to which futu= re calls should be automatically rejected. The current text says "from the= same caller", but we've discovered that it's impossible to provide a clear= definition of that (at least at this time). I think it's a lot better to leave the decision-making process open to futu= re research. Dale From nobody Tue Jan 24 12:19:02 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 656361296F9 for ; Tue, 24 Jan 2017 12:19:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6A_xKv__TeW for ; Tue, 24 Jan 2017 12:18:59 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A22201296FC for ; Tue, 24 Jan 2017 12:18:58 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-d2-5887b6b05d0d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by (Symantec Mail Security) with SMTP id 09.6A.16488.0B6B7885; Tue, 24 Jan 2017 21:18:57 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 21:18:41 +0100 From: Christer Holmberg To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdm0E02YJFp00GoTEcPhv1fDKE252CwgARr+cCADNASAA== Date: Tue, 24 Jan 2017 20:18:40 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFB5888@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrALMWRmVeSWpSXmKPExsUyM2K7lu7Gbe0RBlunMVns+buI3eLrj01s DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAlfGppP32QuaxCoW/1nA0sC4S6iLkZNDQsBE 4uqn1+xdjFwcQgLrGCU2NxxhgXAWM0pcWN/D1MXIwcEmYCHR/U8bpEFEwF7i7de1rCC2sICL xJuVU1gg4q4S/zpuQdlOEufPr2ICsVkEVCXm7psBVs8r4CvxtHExWFxI4BKjxJb32SA2p0CU xOETzewgNqOAmMT3U2vAapgFxCVuPZnPBHGogMSSPeeZIWxRiZeP/7FC2EoSi25/hqrXkViw +xMbhK0tsWzha2aIvYISJ2c+YZnAKDILydhZSFpmIWmZhaRlASPLKkbR4tTi4tx0IyO91KLM 5OLi/Dy9vNSSTYzAeDi45bfVDsaDzx0PMQpwMCrx8H7Ibo8QYk0sK67MPcQowcGsJMLbNQso xJuSWFmVWpQfX1Sak1p8iFGag0VJnNds5f1wIYH0xJLU7NTUgtQimCwTB6dUA6NXJHeew/w0 WTdLHfmPk5inMDz6f4fhuP7CmO1Z77ITrrCy5kg+6RPM2hsu8HxL7y0rntMNsfdkxBnuPme7 KSHhEXtpUzC7r9mTN3d+W0dO3cEWLLBd/RG/YXGxpr+s1u2MdWksjy7HHuSsSPi1PbmmNro6 aNnz0su3eWW/zZaS+VWx861wrRJLcUaioRZzUXEiAIJbfpyDAgAA Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:19:00 -0000 Hi, What is the status of the new milestones? When can the draft-ietf-sicpore d= rafts be submitted? :) Regards, Christer -----Original Message----- From: DOLLY, MARTIN C [mailto:md3135@att.com]=20 Sent: 16 January 2017 18:38 To: Christer Holmberg ; Adam Roach ; 'SIPCORE' ; Rifaat Shekh-Yusef Subject: RE: [sipcore] Call for Adoptions: Drafts for new milestones I support its adoption. -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmb= erg Sent: Friday, January 13, 2017 4:11 PM To: Adam Roach ; 'SIPCORE' ; Rifaat She= kh-Yusef Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones Hi, In addition, I'd like to consider adopting: https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ As indicated by Rifaat, while THIS draft was just submitted, it's related t= o an topic that we have already discussed in the past. Based on discussions= with e.g., Jon Peterson, the controversial parts of the previous suggestio= n has been removed from the new draft. Regards, Christer -----Original Message----- From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach Sent: 13 January 2017 02:52 To: 'SIPCORE' Subject: [sipcore] Call for Adoptions: Drafts for new milestones [as chair] As I mentioned in an earlier message, we have new milestones for SIPCORE, m= any of which we hope to finish in the first half of the year.=20 To that end, I'd like to call for adoption of the documents that prompted a= dding the milestones. To be specific: We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milesto= ne "mechanism for labeling the nature of SIP calls" We propose adopting draft-holmberg-sipcore-content-id for the milestone "cl= arification of the use of Content-ID" We propose adopting draft-sparks-sipcore-name-addr-guidance for the milesto= ne "clarification of the use of name-addr" I'll note that these document -- and in particular the last two -- have had= significant discussion and feedback already. In particular, the author of = draft-sparks-sipcore-name-addr-guidance indicates that he believes that doc= ument is "done" and basically ready for last call. Please provide feedback regarding adoption of these documents by Friday, Ja= nuary 27. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 24 12:24:29 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7D351296FA for ; Tue, 24 Jan 2017 12:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kEWUCWnAkRt for ; Tue, 24 Jan 2017 12:24:26 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C60C1294F7 for ; Tue, 24 Jan 2017 12:24:26 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0OKOI03005557 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jan 2017 14:24:22 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Christer Holmberg , "'SIPCORE'" References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFB5888@ESESSMB209.ericsson.se> From: Adam Roach Message-ID: <1eaa626e-3274-ef82-1242-32a219c378d4@nostrum.com> Date: Tue, 24 Jan 2017 14:24:13 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <7594FB04B1934943A5C02806D1A2204B4BFB5888@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 20:24:28 -0000 [as chair] The milestones are approved and appear on the SIP charter page already. That action is separate from adoption of drafts for each milestone. This Call for Adoption that you're responding to extends through Friday, as indicated in the initial message below. You can expect the chairs to announce consensus (or lack thereof) for each draft early next week. /a On 1/24/17 14:18, Christer Holmberg wrote: > Hi, > > What is the status of the new milestones? When can the draft-ietf-sicpore drafts be submitted? :) > > Regards, > > Christer > > -----Original Message----- > From: DOLLY, MARTIN C [mailto:md3135@att.com] > Sent: 16 January 2017 18:38 > To: Christer Holmberg ; Adam Roach ; 'SIPCORE' ; Rifaat Shekh-Yusef > Subject: RE: [sipcore] Call for Adoptions: Drafts for new milestones > > I support its adoption. > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: Friday, January 13, 2017 4:11 PM > To: Adam Roach ; 'SIPCORE' ; Rifaat Shekh-Yusef > Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones > > Hi, > > In addition, I'd like to consider adopting: > > https://datatracker.ietf.org/doc/draft-yusef-sipcore-sip-authn/ > > As indicated by Rifaat, while THIS draft was just submitted, it's related to an topic that we have already discussed in the past. Based on discussions with e.g., Jon Peterson, the controversial parts of the previous suggestion has been removed from the new draft. > > Regards, > > Christer > > > -----Original Message----- > From: sipcore [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 13 January 2017 02:52 > To: 'SIPCORE' > Subject: [sipcore] Call for Adoptions: Drafts for new milestones > > [as chair] > > As I mentioned in an earlier message, we have new milestones for SIPCORE, many of which we hope to finish in the first half of the year. > To that end, I'd like to call for adoption of the documents that prompted adding the milestones. To be specific: > > We propose adopting draft-schulzrinne-sipcore-callinfo-spam for the milestone "mechanism for labeling the nature of SIP calls" > > We propose adopting draft-holmberg-sipcore-content-id for the milestone "clarification of the use of Content-ID" > > We propose adopting draft-sparks-sipcore-name-addr-guidance for the milestone "clarification of the use of name-addr" > > I'll note that these document -- and in particular the last two -- have had significant discussion and feedback already. In particular, the author of draft-sparks-sipcore-name-addr-guidance indicates that he believes that document is "done" and basically ready for last call. > > Please provide feedback regarding adoption of these documents by Friday, January 27. Thanks! > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Tue Jan 24 13:01:34 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BDDF1297AC for ; Tue, 24 Jan 2017 13:01:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1zJq3mO5cztg for ; Tue, 24 Jan 2017 13:01:31 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9D251297C4 for ; Tue, 24 Jan 2017 13:01:30 -0800 (PST) X-AuditID: c1b4fb3a-12eaf98000004068-06-5887c0a88f70 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id C5.BE.16488.8A0C7885; Tue, 24 Jan 2017 22:01:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.03.0319.002; Tue, 24 Jan 2017 22:01:19 +0100 From: Christer Holmberg To: Adam Roach , 'SIPCORE' Thread-Topic: [sipcore] Call for Adoptions: Drafts for new milestones Thread-Index: AQHSbTdm0E02YJFp00GoTEcPhv1fDKE252CwgARr+cCADNASAP//8QmAgAAa2pA= Date: Tue, 24 Jan 2017 21:01:18 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFB591E@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B4BF73276@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B4BFB5888@ESESSMB209.ericsson.se> <1eaa626e-3274-ef82-1242-32a219c378d4@nostrum.com> In-Reply-To: <1eaa626e-3274-ef82-1242-32a219c378d4@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM2K7q+7KA+0RBl/mMFvs+buI3eLrj01s DkweS5b8ZPKYtfMJSwBTFJdNSmpOZllqkb5dAlfGmlXLWAr2KVU8myzUwHhGsYuRk0NCwERi 1eXZLF2MXBxCAusYJZbPvcME4SxmlHi6fiJQhoODTcBCovufNkiDiIC9xNuva1lBbGEBF4k3 K6ewQMRdJf513AIrFxHwk1h3OBokzCKgKjHrXj9YCa+Ar0RH9xdWiPGnmSQ+rt/BBpLgBJq5 etZhdhCbUUBM4vupNUwgNrOAuMStJ/OZIA4VkFiy5zwzhC0q8fLxP1YIW0li0e3PTCB7mQU0 Jdbv0odoVZSY0v2QHWKvoMTJmU9YJjCKzEIydRZCxywkHbOQdCxgZFnFKFqcWlycm25kpJda lJlcXJyfp5eXWrKJERgJB7f8ttrBePC54yFGAQ5GJR7eD9ntEUKsiWXFlbmHGCU4mJVEeLtm AYV4UxIrq1KL8uOLSnNSiw8xSnOwKInzmq28Hy4kkJ5YkpqdmlqQWgSTZeLglGpg7F9/JtJ9 dvhfRlPBo4VqB9VDFbR/10Q1nl3NtOhuxUsTyxyOeY7Jfm8rfY3/pTZElggs2x3dZmzzgZ/t 2LJd8rczsu5qWf5VW/06gLNOJcyy5LBx/O9+uf+OVtHpS0LYbuvrOTOypWzY8q5A7uWGDbPv 7zdScz+6K4Y/bmHz8SfqCgLnZ15TYinOSDTUYi4qTgQAZ2fbL4ACAAA= Archived-At: Subject: Re: [sipcore] Call for Adoptions: Drafts for new milestones X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 21:01:32 -0000 SGksDQoNCj5UaGlzIENhbGwgZm9yIEFkb3B0aW9uIHRoYXQgeW91J3JlIHJlc3BvbmRpbmcgdG8g ZXh0ZW5kcyB0aHJvdWdoIEZyaWRheSwgYXMgaW5kaWNhdGVkIGluID50aGUgaW5pdGlhbCBtZXNz YWdlIGJlbG93LiBZb3UgY2FuIGV4cGVjdCB0aGUgY2hhaXJzIHRvIGFubm91bmNlIGNvbnNlbnN1 cyAob3IgbGFjayA+dGhlcmVvZikgZm9yIGVhY2ggZHJhZnQgZWFybHkgbmV4dCB3ZWVrLg0KDQpN aXNzZWQgdGhhdCBwYXJ0LiBTb3JyeS4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQpPbiAx LzI0LzE3IDE0OjE4LCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gSGksDQo+DQo+IFdoYXQg aXMgdGhlIHN0YXR1cyBvZiB0aGUgbmV3IG1pbGVzdG9uZXM/IFdoZW4gY2FuIHRoZSANCj4gZHJh ZnQtaWV0Zi1zaWNwb3JlIGRyYWZ0cyBiZSBzdWJtaXR0ZWQ/IDopDQo+DQo+IFJlZ2FyZHMsDQo+ DQo+IENocmlzdGVyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IERP TExZLCBNQVJUSU4gQyBbbWFpbHRvOm1kMzEzNUBhdHQuY29tXQ0KPiBTZW50OiAxNiBKYW51YXJ5 IDIwMTcgMTg6MzgNCj4gVG86IENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+OyBBZGFtIFJvYWNoIA0KPiA8YWRhbUBub3N0cnVtLmNvbT47ICdTSVBDT1JF JyA8c2lwY29yZUBpZXRmLm9yZz47IFJpZmFhdCBTaGVraC1ZdXNlZiANCj4gPHJpZmFhdC5pZXRm QGdtYWlsLmNvbT4NCj4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSBDYWxsIGZvciBBZG9wdGlvbnM6 IERyYWZ0cyBmb3IgbmV3IG1pbGVzdG9uZXMNCj4NCj4gSSBzdXBwb3J0IGl0cyBhZG9wdGlvbi4N Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2lwY29yZSBbbWFpbHRv OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENocmlzdGVyIA0KPiBIb2xt YmVyZw0KPiBTZW50OiBGcmlkYXksIEphbnVhcnkgMTMsIDIwMTcgNDoxMSBQTQ0KPiBUbzogQWRh bSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47ICdTSVBDT1JFJyA8c2lwY29yZUBpZXRmLm9yZz47 IA0KPiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT4NCj4gU3ViamVj dDogUmU6IFtzaXBjb3JlXSBDYWxsIGZvciBBZG9wdGlvbnM6IERyYWZ0cyBmb3IgbmV3IG1pbGVz dG9uZXMNCj4NCj4gSGksDQo+DQo+IEluIGFkZGl0aW9uLCBJJ2QgbGlrZSB0byBjb25zaWRlciBh ZG9wdGluZzoNCj4NCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQteXVz ZWYtc2lwY29yZS1zaXAtYXV0aG4vDQo+DQo+IEFzIGluZGljYXRlZCBieSBSaWZhYXQsIHdoaWxl IFRISVMgZHJhZnQgd2FzIGp1c3Qgc3VibWl0dGVkLCBpdCdzIHJlbGF0ZWQgdG8gYW4gdG9waWMg dGhhdCB3ZSBoYXZlIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoZSBwYXN0LiBCYXNlZCBvbiBkaXNj dXNzaW9ucyB3aXRoIGUuZy4sIEpvbiBQZXRlcnNvbiwgdGhlIGNvbnRyb3ZlcnNpYWwgcGFydHMg b2YgdGhlIHByZXZpb3VzIHN1Z2dlc3Rpb24gaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIHRoZSBuZXcg ZHJhZnQuDQo+DQo+IFJlZ2FyZHMsDQo+DQo+IENocmlzdGVyDQo+DQo+DQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBZGFtIA0KPiBSb2FjaA0KPiBTZW50OiAxMyBKYW51YXJ5 IDIwMTcgMDI6NTINCj4gVG86ICdTSVBDT1JFJyA8c2lwY29yZUBpZXRmLm9yZz4NCj4gU3ViamVj dDogW3NpcGNvcmVdIENhbGwgZm9yIEFkb3B0aW9uczogRHJhZnRzIGZvciBuZXcgbWlsZXN0b25l cw0KPg0KPiBbYXMgY2hhaXJdDQo+DQo+IEFzIEkgbWVudGlvbmVkIGluIGFuIGVhcmxpZXIgbWVz c2FnZSwgd2UgaGF2ZSBuZXcgbWlsZXN0b25lcyBmb3IgU0lQQ09SRSwgbWFueSBvZiB3aGljaCB3 ZSBob3BlIHRvIGZpbmlzaCBpbiB0aGUgZmlyc3QgaGFsZiBvZiB0aGUgeWVhci4NCj4gVG8gdGhh dCBlbmQsIEknZCBsaWtlIHRvIGNhbGwgZm9yIGFkb3B0aW9uIG9mIHRoZSBkb2N1bWVudHMgdGhh dCBwcm9tcHRlZCBhZGRpbmcgdGhlIG1pbGVzdG9uZXMuIFRvIGJlIHNwZWNpZmljOg0KPg0KPiBX ZSBwcm9wb3NlIGFkb3B0aW5nIGRyYWZ0LXNjaHVsenJpbm5lLXNpcGNvcmUtY2FsbGluZm8tc3Bh bSBmb3IgdGhlIG1pbGVzdG9uZSAibWVjaGFuaXNtIGZvciBsYWJlbGluZyB0aGUgbmF0dXJlIG9m IFNJUCBjYWxscyINCj4NCj4gV2UgcHJvcG9zZSBhZG9wdGluZyBkcmFmdC1ob2xtYmVyZy1zaXBj b3JlLWNvbnRlbnQtaWQgZm9yIHRoZSBtaWxlc3RvbmUgImNsYXJpZmljYXRpb24gb2YgdGhlIHVz ZSBvZiBDb250ZW50LUlEIg0KPg0KPiBXZSBwcm9wb3NlIGFkb3B0aW5nIGRyYWZ0LXNwYXJrcy1z aXBjb3JlLW5hbWUtYWRkci1ndWlkYW5jZSBmb3IgdGhlIG1pbGVzdG9uZSAiY2xhcmlmaWNhdGlv biBvZiB0aGUgdXNlIG9mIG5hbWUtYWRkciINCj4NCj4gSSdsbCBub3RlIHRoYXQgdGhlc2UgZG9j dW1lbnQgLS0gYW5kIGluIHBhcnRpY3VsYXIgdGhlIGxhc3QgdHdvIC0tIGhhdmUgaGFkIHNpZ25p ZmljYW50IGRpc2N1c3Npb24gYW5kIGZlZWRiYWNrIGFscmVhZHkuIEluIHBhcnRpY3VsYXIsIHRo ZSBhdXRob3Igb2YgZHJhZnQtc3BhcmtzLXNpcGNvcmUtbmFtZS1hZGRyLWd1aWRhbmNlIGluZGlj YXRlcyB0aGF0IGhlIGJlbGlldmVzIHRoYXQgZG9jdW1lbnQgaXMgImRvbmUiIGFuZCBiYXNpY2Fs bHkgcmVhZHkgZm9yIGxhc3QgY2FsbC4NCj4NCj4gUGxlYXNlIHByb3ZpZGUgZmVlZGJhY2sgcmVn YXJkaW5nIGFkb3B0aW9uIG9mIHRoZXNlIGRvY3VtZW50cyBieSBGcmlkYXksIEphbnVhcnkgMjcu IFRoYW5rcyENCj4NCj4gL2ENCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9y Zw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQo= From nobody Tue Jan 24 14:06:41 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0D8612940D; Tue, 24 Jan 2017 14:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BeXnZR7D_B2z; Tue, 24 Jan 2017 14:06:34 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52F7112940B; Tue, 24 Jan 2017 14:06:34 -0800 (PST) Received: from [10.0.1.39] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0OM6RRj014595 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Jan 2017 16:06:28 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.39] From: "Ben Campbell" To: "Brett Tate" Date: Tue, 24 Jan 2017 16:06:27 -0600 Message-ID: In-Reply-To: <47691faf5fc0859886d2f6266bb9eea2@mail.gmail.com> References: <20170123164212.40CBCB8261C@rfc-editor.org> <47691faf5fc0859886d2f6266bb9eea2@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5319) Archived-At: Cc: bliss@ietf.org, SIPCORE , alissa@cooperw.in, aamelnikov@fastmail.fm Subject: Re: [sipcore] [BLISS] [Editorial Errata Reported] RFC7463 (4915) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2017 22:06:37 -0000 Thanks for the comments. I plan to mark this "hold for update", as usual for non-urgent editorial errata. Thanks! Ben. On 23 Jan 2017, at 12:19, Brett Tate wrote: > Hi, > > I'm not aware of interoperability issues due to what is reported > within > the errata. I've only seen it indirectly cause issues within related > documentation (not code). > > After some discussion within sip-implementors, I reported the errata > as > editorial to help others and myself understand the examples and basic > SIP. > I also reported it to help ensure corrected within rfc7463bis (if ever > actually needed). > > Sorry about not splitting up the report into multiple errata. > However, it > didn't seem worth the effort to report/discuss the items separately. > > Thanks, > Brett > >> -----Original Message----- >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: Monday, January 23, 2017 11:54 AM >> To: SIPCORE >> Cc: alan.b.johnston@gmail.com; msoroush@gmail.com; >> vvenkatar@gmail.com; >> alissa@cooperw.in; aamelnikov@fastmail.fm; shida@ntt-at.com; >> brett@broadsoft.com; bliss@ietf.org >> Subject: Re: [Editorial Errata Reported] RFC7463 (4915) >> >> (Adding SIPCORE) >> >> What do people think of this errata report? Has anyone experienced > interop >> problems due to the described issue? >> >> Thanks! >> >> Ben. >> >> On 23 Jan 2017, at 10:42, RFC Errata System wrote: >> >>> The following errata report has been submitted for RFC7463, "Shared >>> Appearances of a Session Initiation Protocol (SIP) Address of Record >>> (AOR)". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=7463&eid=4915 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Brett Tate >>> >>> Section: GLOBAL >>> >>> Original Text >>> ------------- >>> To: ;tag=428765950880801 >>> >>> Corrected Text >>> -------------- >>> To: >>> >>> Notes >>> ----- >>> PUBLISH must not contain To tag unless sending within dialog. The >>> To >>> tag (428765950880801) appears to be extraneous within the following >>> SIP messages since there is no explanation about which dialog is >>> being >>> shared: section 11.7 F32, section 11.9 F32, section 11.10 F22, and >>> section 11.14 F48. The To/From URI values within section 11.7 F32 >>> also should be swapped since it does not appear to be intentional >>> and >>> is different than the other examples indicating To tag value >>> 428765950880801. >>> >>> Section 11.4 F2 also has To tag issues since a To tag must be >>> present >>> to comply with RFC 3261. Section 11.6 F28 also should not be >>> missing >>> a To tag. >>> >>> Instructions: >>> ------------- >>> This erratum is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. >>> When a decision is reached, the verifying party can log in to change >>> the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC7463 (draft-ietf-bliss-shared-appearances-15) >>> -------------------------------------- >>> Title : Shared Appearances of a Session Initiation >>> Protocol (SIP) Address of Record (AOR) >>> Publication Date : March 2015 >>> Author(s) : A. Johnston, Ed., M. Soroushnejad, Ed., V. >>> Venkataramanan >>> Category : PROPOSED STANDARD >>> Source : Basic Level of Interoperability for SIP >>> Services >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From nobody Mon Jan 30 13:21:35 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D88E1295CB for ; Mon, 30 Jan 2017 13:21:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZD9D09N0umi for ; Mon, 30 Jan 2017 13:21:32 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 106BB12956C for ; Mon, 30 Jan 2017 13:21:32 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0ULLOsj039727 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 30 Jan 2017 15:21:25 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: Paul Kyzivat , "Asveren, Tolga" , Henning Schulzrinne , SIPCORE References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> From: Adam Roach Message-ID: Date: Mon, 30 Jan 2017 15:21:19 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:21:34 -0000 [as individual] On 1/19/17 09:58, Paul Kyzivat wrote: > I don't know what the goal of the attack is. But there must be one, > because it occurs with regularity. I get these multiple times per > week, as do others I have asked about it. And querying the calling > number typically turns up others who have received similar calls. FWIW -- and this is a complete diversion -- but it's my understanding is that standard operating procedure for many dial-out solicitors is to have the system originate several outgoing calls simultaneously, frequently exceeding the number of phone agents available. This is based on the theory that only a small fraction of them will get answered. When the number of answered calls reaches the number of available agents, any pending outbound calls are canceled, since the system would have no agent to match them with. Times may have changed, but my understanding is that this practice was the reason for a vast majority of "one ring" calls from numbers associated with solicitors a decade or so ago. On 1/13/17 16:05, Paul Kyzivat wrote: > This allows Alice to probe for the presence of a device at the target > address, while possibly preventing the attempt from being reported to > the callee. If we're talking about SIP systems, the 666-based approach you describe seems quite overwrought when a simple OPTIONS request would accomplish the same goal. /a From nobody Mon Jan 30 13:37:53 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ADC3412956C; Mon, 30 Jan 2017 13:37:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148581226967.29908.8696849086704883118.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 13:37:49 -0800 Archived-At: Cc: ben@nostrum.com, aroach@mozilla.com, sipcore@ietf.org, sipcore-chairs@ietf.org Subject: [sipcore] sipcore - New Meeting Session Request for IETF 98 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:37:50 -0000 A new meeting session request has just been submitted by Adam Roach, a Chair of the sipcore working group. --------------------------------------------------------- Working Group Name: Session Initiation Protocol Core Area Name: Applications and Real-Time Area Session Requester: Adam Roach Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 40 Conflicts to Avoid: First Priority: netvc xrblock webpush stir mmusic rtcweb avtext perc avtcore dispatch ice sipbrandy Special Requests: --------------------------------------------------------- From nobody Mon Jan 30 13:51:42 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 828C6129637 for ; Mon, 30 Jan 2017 13:51:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgFuQHzjfmVh for ; Mon, 30 Jan 2017 13:51:40 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753A3129621 for ; Mon, 30 Jan 2017 13:51:40 -0800 (PST) Received: from Orochi.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id v0ULpdOe042903 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 30 Jan 2017 15:51:39 -0600 (CST) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Orochi.local To: "'SIPCORE'" , draft-schulzrinne-sipcore-callinfo-spam@tools.ietf.org, draft-holmberg-sipcore-content-id@tools.ietf.org, draft-sparks-sipcore-name-addr-guidance@tools.ietf.org, draft-yusef-sipcore-sip-authn@tools.ietf.org From: Adam Roach Message-ID: <4e554de7-3d33-04f6-85a8-28b52ebd8406@nostrum.com> Date: Mon, 30 Jan 2017 15:51:33 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [sipcore] Newly Adopted Drafts X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 21:51:41 -0000 [as chair] Thanks for everyone who participated in the call for adoption for our three milestones. Support for the suggested documents was unanimous, so we're declaring them adopted at this time. Draft authors: at your earliest convenience, please submit your documents with draft-ietf-sipcore-* filenames. The contents should otherwise match the exiting documents. The statements of support regarding draft-yusef-sipcore-sip-authn have been carefully noted by the chairs. Given the document's history to date, and given that we have a new slate of work to push through (with now four adopted documents in flight), we would like to see additional discussion on the revised document before setting a milestone and adopting it, as well as significant progress towards publishing our existing adopted work. To that end, we encourage the authors to foster conversation on the document -- its use cases and open issues -- on the SIPCORE list, and to request time to discuss the document and its use cases in Chicago. Based on the level of WG participation on the topic, we plan to evaluate whether we should add a new WG milestone near the end of March. Thanks! /a From nobody Mon Jan 30 14:31:42 2017 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5757A129579; Mon, 30 Jan 2017 14:31:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.41.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148581549631.29908.11634008821807861861.idtracker@ietfa.amsl.com> Date: Mon, 30 Jan 2017 14:31:36 -0800 Archived-At: Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 22:31:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core of the IETF. Title : Content ID header field in Session Initiation Protocol (SIP) Authors : Christer Holmberg Ivo Sedlacek Filename : draft-ietf-sipcore-content-id-00.txt Pages : 8 Date : 2017-01-30 Abstract: This document specifies the Content-ID header field for usage in the Session Initiation Protocol (SIP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-content-id/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-sipcore-content-id-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 30 14:39:57 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850FB12965B for ; Mon, 30 Jan 2017 14:39:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mncaUA0xwh-y for ; Mon, 30 Jan 2017 14:39:55 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A134129658 for ; Mon, 30 Jan 2017 14:39:55 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-c9-588fc0b9903a Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by (Symantec Mail Security) with SMTP id F2.0B.28805.9B0CF885; Mon, 30 Jan 2017 23:39:53 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.76]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0319.002; Mon, 30 Jan 2017 23:39:09 +0100 From: Christer Holmberg To: 'SIPCORE' Thread-Topic: Draft new version: draft-ietf-sipcore-content-id-00 Thread-Index: AdJ7SOOxRhIT4jlMQ3a3VcIJ0QTwhw== Date: Mon, 30 Jan 2017 22:39:08 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B4BFCE5DB@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDLMWRmVeSWpSXmKPExsUyM2K7ve7OA/0RBpcb5S2+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKUzn7MUvGOp+PPvOVsD43PmLkZODgkBE4n763cxgdhCAusY JQ7ecu1i5AKyFzNKPFn/grGLkYODTcBCovufNkiNiICCxOsfHewgtrCAjcT2h1OZIeKOEvvu zIey9SRm3d3FAtLKIqAq8em7KEiYV8BX4sKx7YwgNqOAmMT3U2vA1jILiEvcejKfCeIcAYkl e85DnSYq8fLxP1YIW0li7eHtLBD1OhILdn9ig7C1JZYtfM0MMV9Q4uTMJywTGIVmIRk7C0nL LCQts5C0LGBkWcUoWpxanJSbbmSkl1qUmVxcnJ+nl5dasokRGMYHt/w22MH48rnjIUYBDkYl Hl6D3v4IIdbEsuLK3EOMEhzMSiK8+nuBQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJI TyxJzU5NLUgtgskycXBKNTDm8nldlG6Y4L2mbp7PhVPO931PX2ZnKi+fW/piFr/2X/t/CYF7 7qQGvTdveMx/+8pzNp9tG0Uaat1YeVK5eyLOXFi6R/nmxBXa72LP/d844dRb+ZNyVTfXaQZN XO8sOaODNySb6/9t5SqpjXv3mhkv75xXd+GBelS9XM3hf/qm83Mnld/KPjpZiaU4I9FQi7mo OBEAYHtVq18CAAA= Archived-At: Subject: [sipcore] Draft new version: draft-ietf-sipcore-content-id-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 22:39:56 -0000 Hi, We've submitted the initial version of draft-ietf-sipcore-content-id. The draft is the outcome of discussions that took place in ECRIT, where it = was realized that the Content-ID header field had not been defined as a SIP= header field (it was only defined as a MIME body header field). The draft = defines it as a SIP header field. There are currently no open issues in the draft, and currently I see no nee= d to reserve agenda time in Chicago.=20 But, we ask the community to take a look, to see whether there are some iss= ues that require f2f discussions. Thanks! Regards, Christer From nobody Mon Jan 30 14:44:34 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D58129658 for ; Mon, 30 Jan 2017 14:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fccoffice.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r83O3S8ZVOJb for ; Mon, 30 Jan 2017 14:44:31 -0800 (PST) Received: from mx0a-0024ed01.pphosted.com (mx0a-0024ed01.pphosted.com [148.163.149.208]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0013A129579 for ; Mon, 30 Jan 2017 14:44:30 -0800 (PST) Received: from pps.filterd (m0102172.ppops.net [127.0.0.1]) by mx0a-0024ed01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v0UMd8A0013315; Mon, 30 Jan 2017 22:44:28 GMT Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01lp0054.outbound.protection.outlook.com [23.103.198.54]) by mx0a-0024ed01.pphosted.com with ESMTP id 288mf1h9rp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Jan 2017 22:44:28 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fccoffice.onmicrosoft.com; s=selector1-fcc-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=25EwxiFVc21qrsy7mRdZWs/IBjBd2gJAaD1faYKr+tc=; b=EgzugnsKfPAdeRyXiueNGqqbzpIp61KBTjy9HMXWt5V0hMSQfQ/K98wnT6e9E5MqqWLmeV8ozrrs/fjYyMKwLChhy4dlnXlAqMWwA4fAPq/AW6B234xxGDhz4Ie+/6/SDgRFkLvb13o5KR/HH81XSFgu2iQ+NEhI58YVHG+zDtU= Received: from CY1PR09MB0634.namprd09.prod.outlook.com (10.160.151.21) by CY1PR09MB0636.namprd09.prod.outlook.com (10.160.151.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 30 Jan 2017 22:44:27 +0000 Received: from CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) by CY1PR09MB0634.namprd09.prod.outlook.com ([10.160.151.21]) with mapi id 15.01.0860.026; Mon, 30 Jan 2017 22:44:26 +0000 From: Henning Schulzrinne To: Adam Roach , Paul Kyzivat , "Asveren, Tolga" , SIPCORE Thread-Topic: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt Thread-Index: AQHSbekfpzK9A/mMxEW2UXxc6qTie6E6Bhn4gAQFPYCAAGH3gIABTZqAgABDKICAEaO3gIAAFgiw Date: Mon, 30 Jan 2017 22:44:26 +0000 Message-ID: References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.104.54.21] x-ms-office365-filtering-correlation-id: e5cdbd50-24ff-40a5-d463-08d449618b90 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY1PR09MB0636; x-microsoft-exchange-diagnostics: 1; CY1PR09MB0636; 7:N6ATYbDv8C1I4+GoYBL4ooiDghb4GUfWQHCK4CNby5Y8e3M2HR2gjxH8bDuswdXr5Tfz6K5z+0Ho4mEAbwaAVxv9ClYEXTlGf5moHuIiAVcUAePhM+h4XQmXycyoJ03H967Jlwk3ctKY6epYQ/zR8Uv6iW9p5WDzVX913qKQQUopHeN/tcd/OG4TN4+XLndPE1xtrWuepvJ+yoCwDQkSNuzsTpTUbO5VsrqhIi8uuEzCDaYNBJnzWUdRFdphH5LIjYvmBEnQ/IHdpwf6fWicsh+Txlg6QgB8FIJB7auKR0ct1XmeDyHx0W5gPsuZfz06zlmPJHMyUMLutAFAlQaqY9BSflJ9v60OJCosOsYo2wadbmKX8LORHeB3E+4WPrxh6Xo7K9So+kacSfvX8OSSZcObK4UkG/UcXJtXkuYp/JdBTGI4nO6ZgGv6lfwPUoyNYCitcwwPY3ht3mN7KsPZGQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:CY1PR09MB0636; BCL:0; PCL:0; RULEID:; SRVR:CY1PR09MB0636; x-forefront-prvs: 0203C93D51 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(377454003)(13464003)(189002)(24454002)(54356999)(9686003)(6116002)(3846002)(102836003)(76176999)(6306002)(50986999)(55016002)(99286003)(38730400001)(33656002)(2906002)(93886004)(25786008)(229853002)(77096006)(53936002)(101416001)(6506006)(2171001)(68736007)(3280700002)(230783001)(6436002)(3660700001)(305945005)(7736002)(122556002)(5660300001)(189998001)(2950100002)(106356001)(105586002)(106116001)(74316002)(7696004)(107886002)(86362001)(92566002)(2900100001)(66066001)(8676002)(81166006)(81156014)(5001770100001)(8936002)(97736004)(26123001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR09MB0636; H:CY1PR09MB0634.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fcc.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: fcc.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2017 22:44:26.5170 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72970aed-3669-4ca8-b960-dd016bc72973 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR09MB0636 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-01-30_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jan 2017 22:44:33 -0000 VGhlcmUgYXJlIHJ1bGVzIGFib3V0ICJkZWFkIGFpciIsIHNvIHRoaXMgbWFrZXMgc2Vuc2UuIFNl ZSBhbHNvDQoNCmh0dHBzOi8vZXBpYy5vcmcvcHJpdmFjeS90ZWxlbWFya2V0aW5nLw0KDQpPbmUt cmluZyBjYWxscyBhcmUgYWxzbyB1c2VkIGZvciBpbmR1Y2luZyB0aGUgY2FsbGVkIHBhcnR5IHRv IGNhbGwgYmFjaywgcmFja2luZyB1cCBjaGFyZ2VzIHRvIHNvbWUgQ2FyaWJiZWFuIElzbGFuZCBp biB0aGUgKzEgY291bnRyeSBjb2RlLg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogQWRhbSBSb2FjaCBbbWFpbHRvOmFkYW1Abm9zdHJ1bS5jb21dIA0KU2VudDogTW9uZGF5LCBK YW51YXJ5IDMwLCAyMDE3IDQ6MjEgUE0NClRvOiBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0u bWl0LmVkdT47IEFzdmVyZW4sIFRvbGdhIDx0YXN2ZXJlbkBzb251c25ldC5jb20+OyBIZW5uaW5n IFNjaHVsenJpbm5lIDxIZW5uaW5nLlNjaHVsenJpbm5lQGZjYy5nb3Y+OyBTSVBDT1JFIDxzaXBj b3JlQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUt c3RhdHVzLXVud2FudGVkLTAyLnR4dA0KDQpbYXMgaW5kaXZpZHVhbF0NCg0KT24gMS8xOS8xNyAw OTo1OCwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPiBJIGRvbid0IGtub3cgd2hhdCB0aGUgZ29hbCBv ZiB0aGUgYXR0YWNrIGlzLiBCdXQgdGhlcmUgbXVzdCBiZSBvbmUsIA0KPiBiZWNhdXNlIGl0IG9j Y3VycyB3aXRoIHJlZ3VsYXJpdHkuIEkgZ2V0IHRoZXNlIG11bHRpcGxlIHRpbWVzIHBlciANCj4g d2VlaywgYXMgZG8gb3RoZXJzIEkgaGF2ZSBhc2tlZCBhYm91dCBpdC4gQW5kIHF1ZXJ5aW5nIHRo ZSBjYWxsaW5nIA0KPiBudW1iZXIgdHlwaWNhbGx5IHR1cm5zIHVwIG90aGVycyB3aG8gaGF2ZSBy ZWNlaXZlZCBzaW1pbGFyIGNhbGxzLg0KDQoNCkZXSVcgLS0gYW5kIHRoaXMgaXMgYSBjb21wbGV0 ZSBkaXZlcnNpb24gLS0gYnV0IGl0J3MgbXkgdW5kZXJzdGFuZGluZyBpcyANCnRoYXQgc3RhbmRh cmQgb3BlcmF0aW5nIHByb2NlZHVyZSBmb3IgbWFueSBkaWFsLW91dCBzb2xpY2l0b3JzIGlzIHRv IA0KaGF2ZSB0aGUgc3lzdGVtIG9yaWdpbmF0ZSBzZXZlcmFsIG91dGdvaW5nIGNhbGxzIHNpbXVs dGFuZW91c2x5LCANCmZyZXF1ZW50bHkgZXhjZWVkaW5nIHRoZSBudW1iZXIgb2YgcGhvbmUgYWdl bnRzIGF2YWlsYWJsZS4gVGhpcyBpcyBiYXNlZCANCm9uIHRoZSB0aGVvcnkgdGhhdCBvbmx5IGEg c21hbGwgZnJhY3Rpb24gb2YgdGhlbSB3aWxsIGdldCBhbnN3ZXJlZC4gV2hlbiANCnRoZSBudW1i ZXIgb2YgYW5zd2VyZWQgY2FsbHMgcmVhY2hlcyB0aGUgbnVtYmVyIG9mIGF2YWlsYWJsZSBhZ2Vu dHMsIGFueSANCnBlbmRpbmcgb3V0Ym91bmQgY2FsbHMgYXJlIGNhbmNlbGVkLCBzaW5jZSB0aGUg c3lzdGVtIHdvdWxkIGhhdmUgbm8gDQphZ2VudCB0byBtYXRjaCB0aGVtIHdpdGguDQoNClRpbWVz IG1heSBoYXZlIGNoYW5nZWQsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBwcmFj dGljZSB3YXMgDQp0aGUgcmVhc29uIGZvciBhIHZhc3QgbWFqb3JpdHkgb2YgIm9uZSByaW5nIiBj YWxscyBmcm9tIG51bWJlcnMgDQphc3NvY2lhdGVkIHdpdGggc29saWNpdG9ycyBhIGRlY2FkZSBv ciBzbyBhZ28uDQoNCg0KT24gMS8xMy8xNyAxNjowNSwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPiBU aGlzIGFsbG93cyBBbGljZSB0byBwcm9iZSBmb3IgdGhlIHByZXNlbmNlIG9mIGEgZGV2aWNlIGF0 IHRoZSB0YXJnZXQgDQo+IGFkZHJlc3MsIHdoaWxlIHBvc3NpYmx5IHByZXZlbnRpbmcgdGhlIGF0 dGVtcHQgZnJvbSBiZWluZyByZXBvcnRlZCB0byANCj4gdGhlIGNhbGxlZS4gDQpJZiB3ZSdyZSB0 YWxraW5nIGFib3V0IFNJUCBzeXN0ZW1zLCB0aGUgNjY2LWJhc2VkIGFwcHJvYWNoIHlvdSBkZXNj cmliZSANCnNlZW1zIHF1aXRlIG92ZXJ3cm91Z2h0IHdoZW4gYSBzaW1wbGUgT1BUSU9OUyByZXF1 ZXN0IHdvdWxkIGFjY29tcGxpc2ggDQp0aGUgc2FtZSBnb2FsLg0KDQoNCi9hDQoNCg== From nobody Tue Jan 31 07:20:52 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE02129484 for ; Tue, 31 Jan 2017 07:20:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig2AHMoCyXHS for ; Tue, 31 Jan 2017 07:20:49 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673191294A4 for ; Tue, 31 Jan 2017 07:20:47 -0800 (PST) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-10v.sys.comcast.net with SMTP id YaDpcUVkFuQ8yYaEgcBHBi; Tue, 31 Jan 2017 15:20:46 +0000 Received: from [192.168.1.110] ([73.186.127.100]) by resomta-ch2-01v.sys.comcast.net with SMTP id YaEfcUUbuFcbLYaEgcBbGD; Tue, 31 Jan 2017 15:20:46 +0000 To: Henning Schulzrinne , Adam Roach , "Asveren, Tolga" , SIPCORE References: <148425794072.2959.11416934811666562728.idtracker@ietfa.amsl.com> <4eea39b2-e55d-6bc4-c0bd-3e747f02c910@comcast.net> <3a3f8379-b72f-2afb-9827-be1a50a4eb3f@alum.mit.edu> <5f543cdb-3067-1c70-52e9-b426c36bc830@alum.mit.edu> From: Paul Kyzivat Message-ID: <69b0f56e-9792-3ca1-f811-d34317a6cd2b@alum.mit.edu> Date: Tue, 31 Jan 2017 10:20:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfJpx95imvCHfn+ZC4fSTnQtZ8vcMx8ox8SUF8DTdBH/A4+V9cPGyI19joj7fOZU572iuDFKxSAv+j1u1GoBVBlEsTvkQ2uT2LTtAMRjcm/0m9bZGGgPg ++h9we+msr0utvEg44KyJl+hjh1aN4wRVDfHNCwTkBa+JfPRgBeBw8I6Yj/VxOXfAPZSPPATN+EM7RYqJ99hmQIWpO8LqSX0AFSSNk9PnKK8eDtXmQkLJMlX uRQklU4X2j0RYhHsNZdvAQNCg+uQkwB6guCCoIgqBf0= Archived-At: Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 15:20:50 -0000 On 1/30/17 5:44 PM, Henning Schulzrinne wrote: > There are rules about "dead air", so this makes sense. See also > > https://epic.org/privacy/telemarketing/ I have heard of such but never encountered them. > One-ring calls are also used for inducing the called party to call back, racking up charges to some Caribbean Island in the +1 country code. Most of the ones I encounter are of this variety. Some I have confirmed first hand, others second hand. But there are a *lot* of them. I get multiples per day, to my mobile, and to a vonage number that is IIUC assigned from the mobile number pool. I don't know if they are of the sort that Adam described or are intentionally one-ring calls. But this discussion isn't going anywhere, so I'm happy to end it. Thanks, Paul > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Monday, January 30, 2017 4:21 PM > To: Paul Kyzivat ; Asveren, Tolga ; Henning Schulzrinne ; SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-status-unwanted-02.txt > > [as individual] > > On 1/19/17 09:58, Paul Kyzivat wrote: >> I don't know what the goal of the attack is. But there must be one, >> because it occurs with regularity. I get these multiple times per >> week, as do others I have asked about it. And querying the calling >> number typically turns up others who have received similar calls. > > > FWIW -- and this is a complete diversion -- but it's my understanding is > that standard operating procedure for many dial-out solicitors is to > have the system originate several outgoing calls simultaneously, > frequently exceeding the number of phone agents available. This is based > on the theory that only a small fraction of them will get answered. When > the number of answered calls reaches the number of available agents, any > pending outbound calls are canceled, since the system would have no > agent to match them with. > > Times may have changed, but my understanding is that this practice was > the reason for a vast majority of "one ring" calls from numbers > associated with solicitors a decade or so ago. > > > On 1/13/17 16:05, Paul Kyzivat wrote: >> This allows Alice to probe for the presence of a device at the target >> address, while possibly preventing the attempt from being reported to >> the callee. > If we're talking about SIP systems, the 666-based approach you describe > seems quite overwrought when a simple OPTIONS request would accomplish > the same goal. > > > /a > From nobody Tue Jan 31 15:18:07 2017 Return-Path: X-Original-To: sipcore@ietfa.amsl.com Delivered-To: sipcore@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40A0C12960A for ; Tue, 31 Jan 2017 15:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qN9iEUvf481t for ; Tue, 31 Jan 2017 15:18:05 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F466129606 for ; Tue, 31 Jan 2017 15:18:05 -0800 (PST) Received: from resomta-po-20v.sys.comcast.net ([96.114.154.244]) by resqmta-po-01v.sys.comcast.net with SMTP id Yhdscw2eL1QtgYhgZcVYXo; Tue, 31 Jan 2017 23:18:03 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1485904684; bh=Jfm7v3sq1qE/PRvlpPdC4Kz0DuLVm0xVfP434TrF/EI=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=KmniUO4Jlyed3fU9q7jYqEQpKC836fE7RHrvZQvdqrR0hHJnf5IQ+7uPB3x/nkkW7 a7NRw8RmLJgoXStmZ2w87Wkw/UVkZUs1VTguFyYlES5SmCIZedxrdktxdIHnW9x9HQ LBtWOo+bk4X5YzhfDkcWQvs5nOriDTle00F9xZ4236ukkIkgqaXHuByuoLqMxsVIOJ wHCAPK/j/mWeg1V/u+WyeFwqW94MJ0jZhrDH5M/M7B9YxWTkzmN8b2s5sPC82MiEUX MKI+I1YrVIAawEmaXSPbEU288Jwze9UyVJjxTrb47TdVRXMl44RDP+/D77oCXeEstu wksyk6Cz80CBw== Received: from [192.168.1.110] ([73.186.127.100]) by resomta-po-20v.sys.comcast.net with SMTP id YhgZclolIXdA8YhgZck0zS; Tue, 31 Jan 2017 23:18:03 +0000 To: sipcore@ietf.org References: <148581549631.29908.11634008821807861861.idtracker@ietfa.amsl.com> From: Paul Kyzivat Message-ID: <63750599-ba34-92f1-9828-f89d5797598f@comcast.net> Date: Tue, 31 Jan 2017 18:18:02 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <148581549631.29908.11634008821807861861.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfMPElm9/1YX/V/Qu9kWa9CbS31kW3oxkAlZTfbi8YNWujMBHvCc7FPvZ05egh9cPN7VU3pWlbsJcWkuXZ40H+eobxo6c6CnXKexOD74bYA8394Q3NHcG YxSFb1JcC6UqMN69lEk09ROi+WUGSLcPR30rjEnrVM69ou7vwt6tGkVlUU9PlrbOQJ4B9y1jcLdirw== Archived-At: Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-content-id-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:18:06 -0000 I support the objectives of this draft, and the draft itself is a good start. Things were looking good to me until I got to section 1.5. From then on I am confused - I don't know whether I misunderstand what is written or disagree with it. First, let me state my philosophical starting point: I have always considered SIP messages to be themselves be an instance of an extension to the basic MIME format. Hence the sip message itself *is* a mime message, starting with mime headers and then a mime body. All the sip-specific header fields can be considered to be specialized new MIME header fields. Viewed that way, all of the Content-* headers are simply inherited from MIME. If the definition of SIP had been written that way then we wouldn't be doing this now. But it wasn't. I consider this draft a step toward getting to that state in a round-about way. Now to my specific issues: I really don't understand section 1.5. It seems to make all of those header types mandatory. They are all *allowed* in sip messages except (currently) the Content-ID. But none of them is *required*. And I don't think this draft will change that. As I conceive it, the Content-ID in a sip message will identify the sip message itself as a referenced MIME message (that happens to contain some extension headers). (It may be necessary to exclude the initial line in the sip message, because it fails to conform to MIME syntax.) When resolving a Content-ID URL within a SIP message, you search for a matching Content-ID header starting with the SIP message itself and then continuing recursively through any contained body parts of type multipart/*. Thanks, Paul

= From: Brett Tate [mailto:brett@broadsoft.com= ]
Sent: Friday, January 06, 2017 12:32 PM
To: marianne.mohali@orange.com; Henning Schulzrinne &= lt;Henni= ng.Schulzrinne@fcc.gov>; sipcore@ietf.orgSubject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwan= ted-01

Hi= ,

=C2=A0=

Concerning the likeli= hood, I assume that it would depend upon if there is a convenience, busines= s, or mischievous reason to do it.

=C2=A0

As I=E2=80=99ve mentioned, I find the concept of who gets impac= ted by 666 somewhat vague within the draft because of the variety of call s= ervices (3PCC, call forwarding, transfer, et cetera) and ways to update the= connected identity.=C2=A0 However, I assume that the draft can proceed without ne= eding to clarify that stuff.

=C2=A0

If anyone knows the answers to the following, please let me know.

=C2=A0

If the "calling par= ty" gets replaced before "called party" sends BYE with 666, = who should be flagged: 1) calling party indicated within original INVITE or= 2) newest connected party?

=C2=A0

Should the connected party be flagged if the "calling party"= sends BYE with 666?

=C2=A0

Sh= ould the call forwarding party be flagged when flagging the "calling p= arty"?=C2=A0 I assume no since potentially innocent bystander.<= /p>

=C2=A0

Should the call transferring p= arty be flagged when flagging the "calling party"?

=C2=A0

Thanks,

Brett

=C2=A0

From: Henning Schulzrinne [ma= ilto:Henning.Schulzrinne@fcc= .gov]
Sent: Sunday, January 15, 2017 3:49 PM
To: B= rett Tate; sipcore@ietf.org
S= ubject: Re: [sipcore] Comments on draft-ietf-sipcore-status-unwanted-01=

=C2=A0

How likely is any of this goin= g to happen for unwanted robocalls? For figure 4, the one scenario I can th= ink of is the "evil" controller leveraging a service A to call B,= and B 666'ing the call or sending a BYE with Reason(666). But that wou= ld seem to be pretty standard, even if the final recipient of the 666 or BY= E is A (who is likely to ignore it).

=C2=A0

I think it would help if= you could identify the roles of the third parties and see if that causes t= he recipient of the unwanted call to do something that's harmful to inn= ocent bystanders.

=C2=A0

Henning

From: Bre= tt Tate <brett@broadsoft.com&= gt;
Sent: Friday, January 13, 2017 3:48:58 PM
To: Henni= ng Schulzrinne; sipcore@ietf.orgSubject: RE: [sipcore] Comments on draft-ietf-sipcore-status-unwant= ed-01

=C2=A0

Hi,

=C2=A0

Concerning calling party sending BYE with 666, = I just thought that it potentially should be discussed.

=C2=A0

However, RFC 3725 figures 4 and figure 7 = do show how a =E2=80=9Ccalling party=E2=80=9D might get replaced by a =E2= =80=9Ccalled party=E2=80=9D.=C2=A0 Thus if the controller doesn=E2=80=99t s= trip the Reason while relaying the BYE, it definitely would be possible sin= ce both are called parties.

=C2=A0

If the =E2=80=9Ccalling party=E2=80=9D gets replaced before =E2=80=9Cc= alled party=E2=80=9D sends BYE with 666, who should be flagged: 1) calling = party indicated within original INVITE or 2) newest connected party?=

=C2=A0

Thanks,

Brett

=C2=A0

From: Henning Schulzr= inne [mailto:Henning.Schulzr= inne@fcc.gov]
Sent: Thursday, January 12, 2017 3:31 PM
To: Brett Tate; marianne= .mohali@orange.com; sipcore@ietf.or= g
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-statu= s-unwanted-01

=C2=A0

I=E2=80=99m afraid I don=E2=80= =99t quite follow what text you are suggesting and I=E2=80=99m suspecting w= e=E2=80=99re well into the weeds at this point. My general inclination is t= o only state things where 666 differs from 6xx handling, rather than try to= capture all possible status code issues that are generic to (most) 6xx cod= es. This avoids creating inadvertent contradictions or the need to update t= he document should there be changes in the generic handling. In other words= , 666 should be treated like 6xx unless otherwise noted.

=C2=A0

Thus, can you provide suggested text?

=C2=A0

<= p class=3D"MsoNormal">I=E2=80=99m not sure why t= he calling party would indicate 666. After receiving a re-INVITE? In respon= se to a BYE? I admit that I lack the imagination as to how this would occur= and why this would cause anything other than what would happen for a gener= ic 6xx response in those circumstances.

=C2=A0

Stretching the imagination, I could imagine the case where= I=E2=80=99m misled into dialing a number (e.g., as part of a spam email) t= hat turns out to be a robot peddling time shares. I could send a BYE, with = a 666 Reason.

= =C2=A0

Is that = the case you have in mind?

=C2=A0

Henning

=C2= =A0

From: Brett Tate [mailto:brett@broadsoft.com]
<= b>Sent: Friday, January 06, 2017 12:32 PM
To: marianne.mohali@orange.= com; Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>; sipcore@ietf.org
Subject: RE: [si= pcore] Comments on draft-ietf-sipcore-status-unwanted-01

=C2=A0

Hi,

=C2=A0

The dra= ft potentially should also discuss the potential for the connected party to= change mid-dialog 1) without it being communicated and 2) with it being co= mmunicate by RFC 4916, RFC 5876, et cetera.

=C2=A0

From a security considerations perspective, the wrong = party might be flagged by the 666 when the connected party changes.<= /p>

=C2=A0

The draft should potentially a= lso discuss the potential for calling party indicating 666.=C2=A0 Other tha= n a way to attack someone, I=E2=80=99m not sure if are any 3PCC, transfer, = or other service situations where it might actually be appropriate.<= /p>

=C2=A0

=C2=A0

<= div style=3D"border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0= in 0in">

From: marianne= .mohali@orange.com [mailto:marianne.mohali@orange.com]
Sent: Friday, January 06, 2017 10:28 AM
To= : Henning Schulzrinne; Asveren, Tolga; Brett Tate; sipcore@ietf.org
Subject: RE: [sipcore] Comments on draft-ietf-sipcore-status-un= wanted-01

=C2=A0

Hi,

=C2=A0

To reflect the question of the int= erpretation of the 666 response interpretation when the caller has several = identities used for this call (ie. From and P-Asserted-Identity are differe= nt) or call forwarding/call transfer use cases for which it has to be discu= ssed which party should be considered has a fraudulent (ie. the calling par= ty or the diverting party or both ?) ; I propose to add the following text:=

This doc= ument defines a mechanism by which a called party can reject an unwanted ca= ll without consideration of the calling party identification that remain to= the service provider policy. Indeed, the calling party identity may be ref= lected in different way for a direct call or after a diverting service in P= -Asserted-Identity, From, History-Info or any concurrent header field that = can be present at the same time in a SIP message.

=C2=A0

Those questions are real issues for = operators and implementors and they are a weakness that fraudulent callers = could use to bypass the mechanism.

=C2=A0

BR,

Marianne

=C2=A0

=C2=A0