From nobody Sat May 2 06:33:15 2020 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 5B0253A1293 for ; Sat, 2 May 2020 06:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.809 X-Spam-Level: X-Spam-Status: No, score=-2.809 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.82, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 jiGJitBobGKX for ; Sat, 2 May 2020 06:33:04 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2068.outbound.protection.outlook.com [40.107.236.68]) (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 86C263A123E for ; Sat, 2 May 2020 06:32:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IQ6GdKRzp00HMwQ9NPBhrAkQtzq+S4F/6oolqt58quN7zBrXAlsl3s6pUnMZEhQJdGA2Ycl0y4tys95xJt3g56qmLZTsgoVmrUw3i9Y+omnE3vctYAhjDoH+qWM5kcqr7JHHEjlboEBEWT8Vkg5o6d3jPdkE8Cl6ScIPj/LRcdx3c93zOvJ21bZ9Vr4sNMti9gC/vMogPtfQV4IFgjNFKG1n+m5Mnxp5I69w9br3q7a4U1mb/COf0ItUyYjhdAYk/VauS+IMJdnB4pvWjpOJoRy4xlDr6RnRWyJxNY2jRQ51Jgqg08QvOGxVRBZsV/9UxSju17s8yk3mfv+qDBGgmQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3A6WznA7nE2JQrH9plxlYuBKX1ZLGaUPuwfRBWD82Ww=; b=GI1zlbp3FwJYdQjmv7iuNpOUKnmJdWlth51jJ/mK1QKZcqpFVP+jI89di9hpCT3jZJJFx4twIobmlEs9t84NVks4QdF1hm8OwtCEayV0X7RjMK5BseLqqF+QNbBrsZFvZOL+CP5+WcfMrkc+qqlZVOSMT4L9e6dsSVybUpJKIzk0Lhgl6SzzPW2v5gxhNm7o6qbpCXdcoh+c3iGbva8tvQHcEyaJug1equltlSR0hhYVq70KFj4P3g4HEL336d2QKAFDWr3e3C068cXsb4uR5U25+iWIgzoC6T1XlyzWk23tP/X+HerfAdkzBE2X3xWva96RoKEjg9ajJYUfiwu5cg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3A6WznA7nE2JQrH9plxlYuBKX1ZLGaUPuwfRBWD82Ww=; b=Lri509J/Ld0ApZldMwoMF7AyimlcaABCV+HxWVKXCnQzV+QerURxeztV1skhR121vuAVBcz5sW+nnkVXQTWEtSHHYIfVrvStkugnIeLMIW6AdpzewOqiUUngZbwzvsCdFF2dvMWWsA8e9u/dEVsVtX1Jl8sy6YY0WZLn4buM5ds= Received: from SN4PR0801CA0004.namprd08.prod.outlook.com (2603:10b6:803:29::14) by CY4PR12MB1272.namprd12.prod.outlook.com (2603:10b6:903:3e::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.27; Sat, 2 May 2020 13:32:53 +0000 Received: from SN1NAM02FT008.eop-nam02.prod.protection.outlook.com (2603:10b6:803:29:cafe::dd) by SN4PR0801CA0004.outlook.office365.com (2603:10b6:803:29::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.20 via Frontend Transport; Sat, 2 May 2020 13:32:53 +0000 Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT008.mail.protection.outlook.com (10.152.72.119) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2958.27 via Frontend Transport; Sat, 2 May 2020 13:32:52 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 042DWoee016270 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 2 May 2020 09:32:50 -0400 To: sipcore@ietf.org References: <27C3E7FD-D540-4846-9805-08358F39713A@ericsson.com> From: Paul Kyzivat Message-ID: Date: Sat, 2 May 2020 09:32:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <27C3E7FD-D540-4846-9805-08358F39713A@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(396003)(346002)(376002)(136003)(39860400002)(46966005)(6916009)(75432002)(966005)(478600001)(53546011)(70206006)(82740400003)(7596003)(2906002)(356005)(26005)(5660300002)(47076004)(70586007)(186003)(31686004)(36906005)(8936002)(786003)(8676002)(316002)(336012)(82310400002)(956004)(86362001)(31696002)(2616005); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1dc95562-88dc-49cd-f473-08d7ee9d50ac X-MS-TrafficTypeDiagnostic: CY4PR12MB1272: X-LD-Processed: 3326b102-c043-408b-a990-b89e477d582f,ExtAddr,ExtFwd X-MS-Exchange-Transport-Forked: True X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:5797; X-Forefront-PRVS: 039178EF4A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rrpAAk+GBrf2+hZts5g1/rcwfzt9zXWcGNK6jfZnW1JISysbvtI/KY+wadLKtYu5YfArDrXfXXUTYwA7cC9yMmcBGJiioax+lOUdnvvsWQnyC+Njkm5Deews980BHdTsHmlMC9lakM4GvXw1LESDY+EjLt44Dii7RMNJf7zLV8/rh95wHnzua4Vyh3psGGyKwUWswYcNf58aswRnYPF8Ju9Ew6LCy/57e511Cc6PaWJ0ZRZkh598dyfIGYJtPHXlWDDCCI+tjcWoADt/WmDfpM/XJUreWd+hL4Q0IgMuRvRNN3zUycxbwRSYRbjiyjszD8FwHPdmJSr+2cVBzbGEM34MFTbXCCEgxpm9WVRl82+kqccn4iy9W7GOucy+022Rg+3Mak1PlHzW/jND6Oq1/OsasIf6Z2FdrFse9t/JCyEWmYyy5WoY6HU/AW6N0j3USeoCg1GBV4zQlZ0WzEoxguVY9OU4zoqgYRRSwG63YLvU+C6q7ojOFpnNc2SsgvGHLYuXviAdGdh8L88xBvpeiwsxKicCe6UUIPma+uRf8D1kK2Tu8MNqdAy8gvbwpQjej2Ri+HaUbBtAX4a9fKBDqA== X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2020 13:32:52.4294 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc95562-88dc-49cd-f473-08d7ee9d50ac X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1272 Archived-At: Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 13:33:13 -0000 Christer, I scanned the diff for this and noted a few things: * In section 2.1.1 the edit to the 3rd paragraph has some mis-edits: In "the UAC uses it to to request", s/to to/to/ In "before the currently used access token expires token", s/expires token/expires/ * In section 2.1.2 some more mis-editing: s/makes have use of/makes use of/ * Section 2.1.2 also says "TLS can still be used for protecting traffic between SIP endpoints and the AS." This is only true if there is a direct TLS connection between the endpoint and the AS. How can that be assured? Isn't the general point that TLS can be used to secure the content if the connection is direct between the UAC and the UAS? (But I don't know how you can assure that other than by knowledge about the network architecture in which the UAC is operating. I didn't notice any other issues. Thanks, Paul On 4/30/20 8:08 AM, Christer Holmberg wrote: > Hi, > > Based on the IESG reviews, we have submitted a new version (-14) of draft-ietf-sipcore-sip-token-authnz. > > We believe and hope that all issues raised in the IESG reviews have been addressed, but please take a look. > > A big Thank You for all the comments and suggestions! :) > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From nobody Sat May 2 06:46:56 2020 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 90D5A3A1207 for ; Sat, 2 May 2020 06:46:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.921 X-Spam-Level: X-Spam-Status: No, score=-2.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, 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=ericsson.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 flVvdMVQdqf3 for ; Sat, 2 May 2020 06:46:51 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130055.outbound.protection.outlook.com [40.107.13.55]) (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 04FD53A1205 for ; Sat, 2 May 2020 06:46:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QssZairv9mDpRZaKhKZOd7ZVBVEVU5l4qxRXCa1hgBhHRWCNvNDf6OEOdJAsIK5+FX8hDHGjAqGEfJu4E69aVRvD7Ca1z8Zyad3l0oP62cjECqJykFRTR2f5WHbqoqprPpKxX2W4AdaYt3fPWbv0jmIMBzqnuu9ZlI5wa97dZZbLOmPT5L1lOm/HFARYe+E/byZR3ptmBfMCG+7qYevRD0EUH/Xw17P6mQ0D+GSZDepzCzvN2EQUu9Mx/KG9wbxyaVQGzIOnQxMvBD4qSj0yn/NhTxIKtu23KCf0BJWZFdbG01oKVNSwW/HyN46tDZPHVArlDgcyu/e1rDzszco6HA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NtR3gQG2a5p3NPUHb5hSs87b9seK+sT3ZJ8S1zqQlX8=; b=TpEbDRdllZ+7XYFQmsx3Yx4x8TfV5lS4WdDwBlHFTYREN3j7cRLbvvBn7FfDqXNAQVuRrFwTZQTuQdO2T74mlbB8MxZq6XOFMTweWtsUCtv/49gr8LO/7SDjszV12J00dg13ZwCzaBPJbRnSRcYlLjzLjaS+5RsKj5X6J1Dyvk04zsBI7Xsdh/WSCYo+h3QyyHooANDu8cAouPFoA5o97c9ug3e+qvlayggMsa+oETP1TbtEuu3yX9rsi4X5nbO7pw+4a0KHNqa8z2j/qZujQzX7IEvGZuwenyqAwIAsi4lnxHEHmZjY+rrHvAGeCpZrfXaPT1wWVqXwg6NMIq6gxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NtR3gQG2a5p3NPUHb5hSs87b9seK+sT3ZJ8S1zqQlX8=; b=jwSbwoIYnrgrAMG4C4F0cF3nTdd4450IKMkjus2DNs/mgrhM5eSNCTMPxCVPK7je12rYoePDKbJT5gs8iC+og8Mn+smSyJPuKh90lOka9+mSDnXlWlBHT1MR//8F6AjMokAo0Dmg02YeyHnjtxNeqIa7jFGgUzBGrdQXoLXs3ww= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6531.eurprd07.prod.outlook.com (2603:10a6:20b:1ab::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.14; Sat, 2 May 2020 13:46:48 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2979.022; Sat, 2 May 2020 13:46:48 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) Thread-Index: AQHWHugd3GnIoSQ2kUWAEgk7QKROLaiUzoeAgAA2MwA= Date: Sat, 2 May 2020 13:46:48 +0000 Message-ID: <2E6C8481-0A60-4409-90BC-5717A5353AAB@ericsson.com> References: <27C3E7FD-D540-4846-9805-08358F39713A@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f70f511-a8a4-48c9-a6de-08d7ee9f42e7 x-ms-traffictypediagnostic: AM7PR07MB6531: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 039178EF4A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5/7wRJneQDmmAeS9p2o0/1rIm5J8D2vpBUWkjEMIe76iyfQ/ubyRlHLgde4dBmkFQNChGuK1Kr0DTG9fErwpZUEOHfKZsMB1Nbes0zamIQjQQs09AR4vAmcPkQix3ZEgpf534QxzpgBdy9eLcXa0lQ+CE9FIwGyZ04Vz9A2M/d2nopkYmtUc5CkKsVelCrytwVKvOmNsaMY78z0g5MgY3ySqeIItBHIVphz0OhQMprxOnnwKByIK2cTBpEVGjZ+61xMvmTJssk0VplTvTgc8m059425VThMD0oqkZoOHqX/Cgf60KkVN6fuGNdJyaMblhO5u4OwLfHBS8nuCJGL2KusIkwDNKfRQ8WeWVHj0vvs3/rd9Vo+zJh7by0k53FSvf35MELnLQE0Bt9b8F4wdOF6DT5Az4sDdb35LdMsmiaCmdPkJHcwxqKqtdOtO1ropnYT+RPo6FjL6/nepbbwC1sToqNR6pzW2QWs6k71LPpojJe4xGOfDVJ09scg9y80AvowoOnMhDmByj0Lb7umALw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(396003)(39860400002)(346002)(376002)(110136005)(186003)(6512007)(53546011)(6506007)(316002)(26005)(6486002)(36756003)(33656002)(5660300002)(2906002)(66446008)(64756008)(44832011)(2616005)(66476007)(478600001)(86362001)(966005)(8676002)(8936002)(66946007)(76116006)(71200400001)(91956017)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ChE4pKooqK0JwQneHfQ9zy1umwhi+p5qHhNMkFK70OhbAIfJr2w5DWy5uj8psOkr4NHb0x06GKTl5uumC0htBZTaNGjiofk407Asz2NSpKMOhdw6BfhdV6L1n5OiNdqXUOihy2VmJ33nu3jciflYBZBlEtDx6y68d/bFbhAcFKblzW2ImvB+C2OyFE9jGvjhwbeSB+Df6s98m/ZrpsFTaD3F438pq3rpV62LYYC+3DRZJXV9M+iUDNy3Q7daE6VHqbn3XP5erCyV/F/leEWS4img6lH6V5I5UZcU9416Uo1jT0h+s57iupJaXbDKv+XWDGWcwaSq3CtStwMRzc7edfwJ4XAvHW8rzdwo4hdJibKvTPE639z0S5tVNRfA3bSjHjke3PGC+RuQMsXok1Zc2iEjeZwZs7xBPnpagHavJCM5Cw0T3qIvVxZVhrwhnRzupoHKouZRKKwMecaDjjxninDikh2e4Dxc8dJIKm8Lsbz85oSG/gt7pSmnQkacfrB1rNwllKvaC2XkISps877tjn6J9saNzA58L71hKsKst7rRNobYvqBUbvvk0NvFaEvbh4YPnfOKXUSr3VdFqeA45WGqLE+yxSQle2ke5K2NtMz5neLaBGgQEkmU4oh7Eqrv1zr2XzGYNVVe/XCdoHOXr6TzcnwEbYid+4xLekQEeXjw5dK8p6OtJAXWXSAud7Htsf6hEdyKX0UwmbU7b572nAEuBZ+4XtK+kIz/1VE0rW50uJDQOIKjcavTyiQqSmZeikIPM+HGxrMDe0Rtmu9i+ZNuL+JAn6mWZyzDafNzVoMyKH9KNyIEf6utPs4yRNPs x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <101BDCA6F032AB44910391A23B65CFAC@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5f70f511-a8a4-48c9-a6de-08d7ee9f42e7 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 May 2020 13:46:48.4459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fzqhfJ41Ye52YTfiC1hjeqpdtLkcHL58I6YqSWJFoSXEbB6qBscDdqeZeAo76sPB9gv5SOWMp8vik2B8LElXnKyFgm/nlaI552A0JX/FwG4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6531 Archived-At: Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 May 2020 13:46:54 -0000 SGkgUGF1bCwNCiAgICANCj4gICAgKiBJbiBzZWN0aW9uIDIuMS4xIHRoZSBlZGl0IHRvIHRoZSAz cmQgcGFyYWdyYXBoIGhhcyBzb21lIG1pcy1lZGl0czoNCj4gICAgDQo+ICAgIEluICJ0aGUgVUFD IHVzZXMgaXQgdG8gdG8gcmVxdWVzdCIsIHMvdG8gdG8vdG8vDQo+DQo+ICAgIEluICJiZWZvcmUg dGhlIGN1cnJlbnRseSB1c2VkIGFjY2VzcyB0b2tlbiBleHBpcmVzIHRva2VuIiwgcy9leHBpcmVz IA0KPiAgICB0b2tlbi9leHBpcmVzLw0KPg0KPiAgICAqIEluIHNlY3Rpb24gMi4xLjIgc29tZSBt b3JlIG1pcy1lZGl0aW5nOiBzL21ha2VzIGhhdmUgdXNlIG9mL21ha2VzIHVzZSBvZi8NCiAgDQpX aWxsIGZpeCBldmVyeXRoaW5nIGFib3ZlLg0KDQo+ICAgICogU2VjdGlvbiAyLjEuMiBhbHNvIHNh eXMgIlRMUyBjYW4gc3RpbGwgYmUgdXNlZCBmb3IgcHJvdGVjdGluZyB0cmFmZmljIA0KPiAgICBi ZXR3ZWVuIFNJUCBlbmRwb2ludHMgYW5kIHRoZSBBUy4iIFRoaXMgaXMgb25seSB0cnVlIGlmIHRo ZXJlIGlzIGEgDQo+ICAgIGRpcmVjdCBUTFMgY29ubmVjdGlvbiBiZXR3ZWVuIHRoZSBlbmRwb2lu dCBhbmQgdGhlIEFTLiAgSG93IGNhbiB0aGF0IGJlIA0KPiAgICBhc3N1cmVkPw0KPiAgICANCj4g ICAgSXNuJ3QgdGhlIGdlbmVyYWwgcG9pbnQgdGhhdCBUTFMgY2FuIGJlIHVzZWQgdG8gc2VjdXJl IHRoZSBjb250ZW50IGlmIA0KPiAgICB0aGUgY29ubmVjdGlvbiBpcyBkaXJlY3QgYmV0d2VlbiB0 aGUgVUFDIGFuZCB0aGUgVUFTPyAoQnV0IEkgZG9uJ3Qga25vdyANCj4gICAgaG93IHlvdSBjYW4g YXNzdXJlIHRoYXQgb3RoZXIgdGhhbiBieSBrbm93bGVkZ2UgYWJvdXQgdGhlIG5ldHdvcmsgDQo+ ICAgIGFyY2hpdGVjdHVyZSBpbiB3aGljaCB0aGUgVUFDIGlzIG9wZXJhdGluZy4NCiAgDQpOb3Rl IHRoYXQgdGhlIHRyYWZmaWMgYmV0d2VlbiB0aGUgU0lQIGVuZHBvaW50cyBhbmQgdGhlIEFTIHVz ZXMgSFRUUFMgKHBlcmhhcHMgdGhhdCBjb3VsZCBiZSBjbGFyaWZpZWQpLCB3aGljaCB1c2VzIFRM Uy4gDQogIA0KPiAgICBJIGRpZG4ndCBub3RpY2UgYW55IG90aGVyIGlzc3Vlcy4NCiAgDQpUaGFu a3MgZm9yIGFsbCB5b3VyIGNvbW1lbnRzIGFuZCBmZWVkYmFjayENCg0KUmVnYXJkcywNCg0KQ2hy aXN0ZXINCg0KICAgIA0KICAgIE9uIDQvMzAvMjAgODowOCBBTSwgQ2hyaXN0ZXIgSG9sbWJlcmcg d3JvdGU6DQogICAgPiBIaSwNCiAgICA+IA0KICAgID4gQmFzZWQgb24gdGhlIElFU0cgcmV2aWV3 cywgd2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lvbiAoLTE0KSBvZiBkcmFmdC1pZXRmLXNp cGNvcmUtc2lwLXRva2VuLWF1dGhuei4NCiAgICA+IA0KICAgID4gV2UgYmVsaWV2ZSBhbmQgaG9w ZSB0aGF0IGFsbCBpc3N1ZXMgcmFpc2VkIGluIHRoZSBJRVNHIHJldmlld3MgaGF2ZSBiZWVuIGFk ZHJlc3NlZCwgYnV0IHBsZWFzZSB0YWtlIGEgbG9vay4NCiAgICA+IA0KICAgID4gQSBiaWcgVGhh bmsgWW91IGZvciBhbGwgdGhlIGNvbW1lbnRzIGFuZCBzdWdnZXN0aW9ucyEgOikNCiAgICA+IA0K ICAgID4gUmVnYXJkcywNCiAgICA+IA0KICAgID4gQ2hyaXN0ZXINCiAgICA+IA0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IHNpcGNv cmUgbWFpbGluZyBsaXN0DQogICAgPiBzaXBjb3JlQGlldGYub3JnDQogICAgPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCiAgICA+IA0KICAgIA0KICAgIF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgc2lwY29y ZSBtYWlsaW5nIGxpc3QNCiAgICBzaXBjb3JlQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQogICAgDQoNCg== From nobody Mon May 4 01:13:41 2020 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 D5F463A0101 for ; Mon, 4 May 2020 01:13:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 w5PEOGKDlIFc for ; Mon, 4 May 2020 01:13:38 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80058.outbound.protection.outlook.com [40.107.8.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 BF2EF3A005F for ; Mon, 4 May 2020 01:13:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c6zCNAjR1jsq/fcu5YZZe8qHbL2Hwku4bkh0U+kBi6qWQ54oDmqO862JzEBvDCU+zi6WGObHLjMlOKoWXRIusQ67LX15+gapXR8k4T9GQGmLyBYU/IvqZEV/htBXtT0fTZeV2vK0b0ou7KniJLpJop/KGcluCkxb17eX31hP7CDEgXHDXLBHdcRDEE0r9v+WuWiPN9xtdUuhlEhQhbzsS6IeHErxdXsZPZ2BEUa0buVW8FfKSPYI+btxy1N9OUY6qEYcL6BCxsw2Lre0zCxFHe0i4L/sxHcgPSrT+VXtBx8VtB9FOHFcRKBAlTfmCXjChctRNRi8arNP00g5ludsBw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jz2x7RsNp4SdbU/Wo+lLuegTdfTHF45+sO3NTmPm+C4=; b=VdKIp8nmLyN9i42esHKqWZo83Paf4uhA9+KPrNJUgiRECjHdIGxo+1s6NqSn91iFVh5MVYR5rhfrAd8PyzajZb/prxYF+L/I2oFNBxQU1do+Z315yAqBysQT4d/9AjH/6t43sFMC8i3LnDD/edUn2XvMUfAYX75BWoXy50g0xxoq4hCH9ATTPdSbh86y9e9yoJW5PyULM5qNHdv8uucAMrl2Z40r82TCOeYd0YTrbVycniyqeqHk7kUrsmS4SxBebRDHmv6j2nLtFnLZNw1M2LWL4IXLsdkUec11tRhM+Cb64TPd7vJCxU3mE2P1LD0ztTjU7PJO4ZfoYRJOhHWIqA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jz2x7RsNp4SdbU/Wo+lLuegTdfTHF45+sO3NTmPm+C4=; b=pE+l/FA2D/R/8/+bC8yiOo0neiRWrCo0w0BK8pJp9QV+kLtoaLFkraQJzfSjuS/gOnp7JsK7rjUqcOlarO4mTgvYZh0OENwwh6NFmmHDju2CiihXhNZdv4JbWFCAOYAxL7ADopbO7ZkkLeP/+857Dw5fW1eBh/TYLC5Wh6PzMVY= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB7011.eurprd07.prod.outlook.com (2603:10a6:20b:1b3::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Mon, 4 May 2020 08:13:34 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2979.024; Mon, 4 May 2020 08:13:34 +0000 From: Christer Holmberg To: Christer Holmberg , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) - the pull request Thread-Index: AQHWIevn9I+qhLfMvUOgm/JewsP9Pg== Date: Mon, 4 May 2020 08:13:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a28a349b-f62c-47aa-c168-08d7f0030a2a x-ms-traffictypediagnostic: AM7PR07MB7011: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-forefront-prvs: 03932714EB x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4/bmE9IQMxBhCegCw7UvDiyXyw7xljHFxC7iKhbfiF+8VPfeKnhxiE3usve2HCQ1OakREwrWC6UYW6zzfL5JE1VtDp0WFQ1YP/JxW9FpJPjlv7mLvme5mu2uKOtbEwpsQCcfrWaOyubcPBFnQwFoEhAa2BvWoCxdNSQW2dRenxL2Qzf6vmPXCa0vKDhOz1zFitTXqrmzIud6W9ReFoPPpxKKdjrV1+IMqUDovB1HAi4mdjt6WXQom9tEN8pY10yqINewK70f//a5Qf1GzjE/CRckMhL6/SnxBcs2/eI0bDxn3bXTsbU1fQwVHB2KTqqvQ4CDx3NIU5ogYVDOoJUXSTET4HmmP7thz3h4Cch4MQyta8XV5nXsCMkFldgpBXCkgqsE3G5LlGpn9l4S+8pkkXFe+SAJFiCtx4yd2GDIrhcX4iqZQV8upAN34akNgmT79XDrJoGvVZi94PimGCZVLf+yZOfTMm91igt5A6FACi2W69HjEPURsSeqQucmcbE9LtY2Kln9eNNdxHEoq6i2GA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(366004)(346002)(966005)(8936002)(8676002)(5660300002)(66946007)(66446008)(316002)(2906002)(44832011)(110136005)(76116006)(64756008)(66556008)(66476007)(53546011)(86362001)(6506007)(36756003)(71200400001)(2616005)(6486002)(186003)(33656002)(6512007)(26005)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: XPUNRWgxZZbkc6ndNNFaxZz9GYuaAiH/R+oQiSZcM9rJuHQPbIxExiOYAfGoV9k07Bj6SJthMqP55hsI1UTTqn85Q5rmJXH0xAquZ8/I+xjVj6aqCnbQPlKjwMpv0C5CboA5UVkB5YVZlGCT3DpI/885QSxKIWnQjpDIWPQBeeFVc2kypze0WirYR9M0t5aQL+1WXxs1Vt5hrdHKh3NicyQBil1PWqv99CgOFJiSECzfEIJRQCmdRcm6Q6XbwswQDlnA5SWRg7gxw4B52UQOWJFwkc4nICk2Nk0OlTV8rmExxUEQQG0vCgYdKq3khLvEVNxKVxid3QbS5NZ75zA5BTYmsCwP5n4Uuz3YiEnDc9/A5Ovc9LzzaQSaWwMwvIKaNw7GBBJH0tZXC5wFpulIZON4Sogugfr57wpySzwIKAqo8NI5+pG/pVdjNw1zGMMDMfGtlUW2PWyxImm7wLvpy4sq8LGzmK4V+5DWUfmGi1NiMbh2IYNiMNN/Jm5uTD4+7VSwUxXZWJM1RcSk/ixSniJrWb34dtyAEyuaRIdVAb0thAPSuUlR2pkhZV6EcG5RVrKiRir+uxxWSCDmKgTLbyiCsIRcWLH7Xc1J0pZisMVA8Se2IiXOM8MTePDpgc/mXvOBiT1nok4NNJX2rWyBZ6tLnKCWy/XNwFARHvmp8NNe6QfkLpCJUhVRxMdXL2r65/XNZ6C0LZqBGZ4pXw7ucgNW+wiZyARd1D/SNQfSu5Xtv+vmaJ2M0xew2WX4tC6KLMNeWr3OmEcEv7ISq5YJhQ8Q2ZHCwbfel/DEtWRwjXYNwQJdoIRQHq9oKdc4sPMG x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <44E9EA0E0157C243BE66404AE99AC236@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: a28a349b-f62c-47aa-c168-08d7f0030a2a X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2020 08:13:34.1868 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wHPMdEADgtWlXgVe2ej43Vg1wTtVvqmvCJxRuJejzkIxGp9kLpLDnU7mb10VKHH3Abf1fmf0npTGcHDEoZUe+dtIxh2K0t5fb0I6PfqJOE8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB7011 Archived-At: Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-sip-token-authnz-14 (was: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-13) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 May 2020 08:13:40 -0000 SGksDQoNCkkgY3JlYXRlZCBhIHB1bGwgcmVxdWVzdCBiYXNlZCBvbiBQYXVsJ3MgY29tbWVudHM6 DQoNCmh0dHBzOi8vZ2l0aHViLmNvbS9yaWZhYXQtaWV0Zi9kcmFmdC1pZXRmLXNpcGNvcmUtc2lw LXRva2VuLWF1dGhuei9wdWxsLzgNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQrvu79PbiAw Mi8wNS8yMDIwLCAxNi40NywgInNpcGNvcmUgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJn IiA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaHJpc3Rlci5ob2xtYmVy Zz00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBIaSBQYXVsLA0K ICAgICAgICANCiAgICA+ICAgICogSW4gc2VjdGlvbiAyLjEuMSB0aGUgZWRpdCB0byB0aGUgM3Jk IHBhcmFncmFwaCBoYXMgc29tZSBtaXMtZWRpdHM6DQogICAgPiAgICANCiAgICA+ICAgIEluICJ0 aGUgVUFDIHVzZXMgaXQgdG8gdG8gcmVxdWVzdCIsIHMvdG8gdG8vdG8vDQogICAgPg0KICAgID4g ICAgSW4gImJlZm9yZSB0aGUgY3VycmVudGx5IHVzZWQgYWNjZXNzIHRva2VuIGV4cGlyZXMgdG9r ZW4iLCBzL2V4cGlyZXMgDQogICAgPiAgICB0b2tlbi9leHBpcmVzLw0KICAgID4NCiAgICA+ICAg ICogSW4gc2VjdGlvbiAyLjEuMiBzb21lIG1vcmUgbWlzLWVkaXRpbmc6IHMvbWFrZXMgaGF2ZSB1 c2Ugb2YvbWFrZXMgdXNlIG9mLw0KICAgICAgDQogICAgV2lsbCBmaXggZXZlcnl0aGluZyBhYm92 ZS4NCiAgICANCiAgICA+ICAgICogU2VjdGlvbiAyLjEuMiBhbHNvIHNheXMgIlRMUyBjYW4gc3Rp bGwgYmUgdXNlZCBmb3IgcHJvdGVjdGluZyB0cmFmZmljIA0KICAgID4gICAgYmV0d2VlbiBTSVAg ZW5kcG9pbnRzIGFuZCB0aGUgQVMuIiBUaGlzIGlzIG9ubHkgdHJ1ZSBpZiB0aGVyZSBpcyBhIA0K ICAgID4gICAgZGlyZWN0IFRMUyBjb25uZWN0aW9uIGJldHdlZW4gdGhlIGVuZHBvaW50IGFuZCB0 aGUgQVMuICBIb3cgY2FuIHRoYXQgYmUgDQogICAgPiAgICBhc3N1cmVkPw0KICAgID4gICAgDQog ICAgPiAgICBJc24ndCB0aGUgZ2VuZXJhbCBwb2ludCB0aGF0IFRMUyBjYW4gYmUgdXNlZCB0byBz ZWN1cmUgdGhlIGNvbnRlbnQgaWYgDQogICAgPiAgICB0aGUgY29ubmVjdGlvbiBpcyBkaXJlY3Qg YmV0d2VlbiB0aGUgVUFDIGFuZCB0aGUgVUFTPyAoQnV0IEkgZG9uJ3Qga25vdyANCiAgICA+ICAg IGhvdyB5b3UgY2FuIGFzc3VyZSB0aGF0IG90aGVyIHRoYW4gYnkga25vd2xlZGdlIGFib3V0IHRo ZSBuZXR3b3JrIA0KICAgID4gICAgYXJjaGl0ZWN0dXJlIGluIHdoaWNoIHRoZSBVQUMgaXMgb3Bl cmF0aW5nLg0KICAgICAgDQogICAgTm90ZSB0aGF0IHRoZSB0cmFmZmljIGJldHdlZW4gdGhlIFNJ UCBlbmRwb2ludHMgYW5kIHRoZSBBUyB1c2VzIEhUVFBTIChwZXJoYXBzIHRoYXQgY291bGQgYmUg Y2xhcmlmaWVkKSwgd2hpY2ggdXNlcyBUTFMuIA0KICAgICAgDQogICAgPiAgICBJIGRpZG4ndCBu b3RpY2UgYW55IG90aGVyIGlzc3Vlcy4NCiAgICAgIA0KICAgIFRoYW5rcyBmb3IgYWxsIHlvdXIg Y29tbWVudHMgYW5kIGZlZWRiYWNrIQ0KICAgIA0KICAgIFJlZ2FyZHMsDQogICAgDQogICAgQ2hy aXN0ZXINCiAgICANCiAgICAgICAgDQogICAgICAgIE9uIDQvMzAvMjAgODowOCBBTSwgQ2hyaXN0 ZXIgSG9sbWJlcmcgd3JvdGU6DQogICAgICAgID4gSGksDQogICAgICAgID4gDQogICAgICAgID4g QmFzZWQgb24gdGhlIElFU0cgcmV2aWV3cywgd2UgaGF2ZSBzdWJtaXR0ZWQgYSBuZXcgdmVyc2lv biAoLTE0KSBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei4NCiAgICAgICAg PiANCiAgICAgICAgPiBXZSBiZWxpZXZlIGFuZCBob3BlIHRoYXQgYWxsIGlzc3VlcyByYWlzZWQg aW4gdGhlIElFU0cgcmV2aWV3cyBoYXZlIGJlZW4gYWRkcmVzc2VkLCBidXQgcGxlYXNlIHRha2Ug YSBsb29rLg0KICAgICAgICA+IA0KICAgICAgICA+IEEgYmlnIFRoYW5rIFlvdSBmb3IgYWxsIHRo ZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMhIDopDQogICAgICAgID4gDQogICAgICAgID4gUmVn YXJkcywNCiAgICAgICAgPiANCiAgICAgICAgPiBDaHJpc3Rlcg0KICAgICAgICA+IA0KICAgICAg ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAg ICAgID4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCiAgICAgICAgPiBzaXBjb3JlQGlldGYub3JnDQog ICAgICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQog ICAgICAgID4gDQogICAgICAgIA0KICAgICAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgICAgICBzaXBjb3JlIG1haWxpbmcgbGlzdA0KICAgICAg ICBzaXBjb3JlQGlldGYub3JnDQogICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZQ0KICAgICAgICANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIHNpcGNvcmUgbWFpbGluZyBsaXN0DQog ICAgc2lwY29yZUBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZQ0KICAgIA0KDQo= From nobody Tue May 5 01:46:15 2020 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 E01DD3A15D9 for ; Tue, 5 May 2020 01:46:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 jm2ObtmVUiFB for ; Tue, 5 May 2020 01:46:11 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 42F483A15DA for ; Tue, 5 May 2020 01:46:11 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id k110so1024204otc.2 for ; Tue, 05 May 2020 01:46:11 -0700 (PDT) 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=XjSXbQv8ZXKQWUvcB5mFAPBIg/InFOkSp5b6spXKMCI=; b=n4e0FcrDvrry8Mo1+IOlv8IC1nUl62G52krzTRDdAjQFx+LVyBs5ynz8ZD8bJMRtwn KTAzkYyuaTdvI49NjlPBg884AC4EzqwMTAefQcpMl57VHO+H4Ue8gG1CMbEflcxj/gNr Ce/0lNDevlSuRmW9mSTY+DvlZobhejwz+9C/DCQhdmRM0lgn6EHw9Vdtl2NtoN9PRzFR sXacvgXEJIecuSQk3FK8tZ7wvF09RWeDoFF0rvu1YZS1hFrfBNYf/VcppMSlDc/GvKqy boTHYSoMmgsOfpvUYotSIc27Jgi/+jA2GVK+SIegHIPRyfpoGUEsTb0cyQoq/gJQN6f5 K7oA== 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=XjSXbQv8ZXKQWUvcB5mFAPBIg/InFOkSp5b6spXKMCI=; b=M4BTh/hz+o6oSk8xpiwZZ7FnQNa8d2AF+yhjmft8E3mY/HkQiNeOVtEmIP9e5YautE x/ePps1lL3FKl+SGbHneYBz8j7A6ZQDymIHi9QHM+ry/xGRD1mnmIWuqDTpeS6BJfAuR GOjqV20humqPa0VtXq5FRgHjzTk7gBOy0gGJQcy2lZrAn4rxGwb6sm7jJ6gkAU+/HwXQ drHnvXtT8aW2N5hLByqb+ujvQI1YGEraD7e37ftw0Z8azJudwmMoRiveOpz1ru0ERQ31 yy69LX05UYP8GU1NpwRqYzzGJGAO9Bh1LpvJ+pDxti4gvYpdIpeEz38DaMeHjQ8fsR+b /rhA== X-Gm-Message-State: AGi0Pub9rff54AP7HZemAxxPE9yqEoiCZCpL1TZRGB6kG2nJKyRBuZVP AewNlBXMv/SiTNsY4cktKj3OEEyaP3Ee6HxHNGDLhWjLwbw= X-Google-Smtp-Source: APiQypL3gZYicGzVFo+NTOn4xEJ4Wbjm7BY8XwvixBNDFbU02D1Z0FbuYJqneyEgUyd67LH0RoQ9l9nKQDqX8q4NJqM= X-Received: by 2002:a05:6830:1dda:: with SMTP id a26mr1641581otj.29.1588668370207; Tue, 05 May 2020 01:46:10 -0700 (PDT) MIME-Version: 1.0 From: Filippos Vasilakis Date: Tue, 5 May 2020 10:45:59 +0200 Message-ID: To: sipcore@ietf.org Content-Type: multipart/alternative; boundary="000000000000df487d05a4e2adf1" Archived-At: Subject: [sipcore] SIP Federation, authentication and interoperability with WebRTC X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 08:46:14 -0000 --000000000000df487d05a4e2adf1 Content-Type: text/plain; charset="UTF-8" Hello everyone, I first sent this email to sip-implementers mailing list as I was pointed out by @sobomax and @oej, but that mailing list told me that the things I ask are more related to this group, so here I am. I started looking into SIP over the past months because I find it quite interesting protocol. I have went through various RFCs and technical documents and I have some questions that might be naive, but due to lack of experience I need some guidance and clarifications. Also, I hope I am in the right place asking those questions. 1) What's the status of SIP Federation? It seems like there is no official standard in there, but do we need it in order to achieve it ? The Secure Telephone Identity Revisited IETF group [0] has done some amazing work over the past years regarding SIP authentication (especially from the callee side). Is that enough for having secure SIP Federation, or are there missing pieces in the puzzle? 2) The WebRTC seems like it's taking a completely different road regarding federation [1]. There, it seems like the signaling protocol (which is not defined yet, but SIP is a major candidate), is used only for passing over the user identities, and then the actual federation checks take place inside the browser. I guess that's needed in case you don't trust the site you are sitting on, like a poker site, but still need to communicate with your friends, and verify that these are your friends, whose identity might belong to a completely different server/domain from yours and different from the poker site you are sitting on. Actually that scenario is explained by [1]. But still, that's quite different with SIP, so how is SIP interoperability is going to work with that? Has anyone give a thought? Feels super important to me that these 2 don't divert. 3) Olle Johannson, in a talk in Kamailio conference, said that SIP still hasn't solved the end-to-end encryption and integrity, mostly because, at some point the route might go through a non TLS connection. Well that's not an easy problem to solve, but I think that [0] has solved most of that (the integrity part), or am I wrong ? I mean, sure the SIP request might be come with the headers stripped off, but that's something that the callee SIP server shouldn't trust much. If it has the necessary headers though (the passport), then the caller should be who says it is. Of course the encryption is still remaining open, but is this solvable at all? Anyone working on that that ? 4) How people do authentication mostly in SIP, when some kind of federation is needed? Is RFCs from [0] a common practice now? Is DANE (which from what I understand depends on DNSSEC) something that is used at all ? Something else ? I guess I fired too many questions, but I would love to get back some clarifications. [0] https://datatracker.ietf.org/wg/stir/documents/ [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 [2] https://www.youtube.com/watch?v=FO1N6gEjxUo --000000000000df487d05a4e2adf1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

I first sent this email= to sip-implementers mailing list as I was pointed out by @sobomax and @oej= , but that mailing list told me that the things I ask are more related to t= his group, so here I am.

I started looking into SIP over the = past months because I find it quite interesting protocol. I have went throu= gh various RFCs and technical documents and I have some questions that migh= t be naive, but due to lack of experience I need some guidance and clarific= ations. Also, I hope I am in the right place asking those questions.
1) What's the status of SIP Federation? It seems like there is no offi= cial standard in there, but do we need it in order to achieve it ? The Secu= re Telephone Identity Revisited IETF group [0] has done some amazing work o= ver the past years regarding SIP authentication (especially from the callee= side). Is that enough for having secure SIP Federation, or are there missi= ng pieces in the puzzle?

2) The WebRTC seems like it's taking a = completely different road regarding federation [1]. There, it seems like th= e signaling protocol (which is not defined yet, but SIP is a major candidat= e), is used only for passing over the user identities, and then the actual = federation checks take place inside the browser. I guess that's needed = in case you don't trust the site you are sitting on, like a poker site,= but still need to communicate with your friends, and verify that these are= your friends, whose identity might belong to a completely different server= /domain from yours and different from the poker site you are sitting on. Ac= tually that scenario is explained by [1]. But still, that's quite diffe= rent with SIP, so how is SIP interoperability is going to work with that? H= as anyone give a thought? Feels super important to me that these 2 don'= t divert.

3) Olle Johannson, in a talk in Kamailio conference, said = that SIP still hasn't solved the end-to-end encryption and integrity, m= ostly because, at some point the route might go through a non TLS connectio= n. Well that's not an easy problem to solve, but I think that [0] has s= olved most of that (the integrity part), or am I wrong ? I mean, sure the S= IP request might be come with the headers stripped off, but that's some= thing that the callee SIP server shouldn't trust much. If it has the ne= cessary headers though (the passport), then the caller should be who says i= t is. Of course the encryption is still remaining open, but is this solvabl= e at all? Anyone working on that that ?

4) How people do authenticat= ion mostly in SIP, when some kind of federation is needed? Is RFCs from [0]= a common practice now? Is DANE (which from what I understand depends on DN= SSEC) something that is used at all ? Something else ?

I guess I fir= ed too many questions, but I would love to get back some clarifications.
[0] https:= //datatracker.ietf.org/wg/stir/documents/
[1] https://tools.ietf.org= /html/draft-ietf-rtcweb-security-arch-20
[2] https://www.youtube.com/watch?v=3DFO1N6g= EjxUo
--000000000000df487d05a4e2adf1-- From nobody Tue May 5 02:07:40 2020 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 1580B3A15ED for ; Tue, 5 May 2020 02:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 lg4Ce_ZmenRe for ; Tue, 5 May 2020 02:07:33 -0700 (PDT) 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 A628C3A15EB for ; Tue, 5 May 2020 02:07:31 -0700 (PDT) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 5C3B4C0A; Tue, 5 May 2020 11:07:28 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <28F8308B-9275-4E0C-8011-3317D07E38C9@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_FD40E82B-9F13-4F44-99B7-8A1965B37DFC" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 5 May 2020 11:07:27 +0200 In-Reply-To: Cc: Olle E Johansson , sipcore@ietf.org To: Filippos Vasilakis References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] SIP Federation, authentication and interoperability with WebRTC X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 09:07:39 -0000 --Apple-Mail=_FD40E82B-9F13-4F44-99B7-8A1965B37DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 May 2020, at 10:45, Filippos Vasilakis = wrote: >=20 > Hello everyone, >=20 > I first sent this email to sip-implementers mailing list as I was = pointed out by @sobomax and @oej, but that mailing list told me that the = things I ask are more related to this group, so here I am. >=20 > I started looking into SIP over the past months because I find it = quite interesting protocol. I have went through various RFCs and = technical documents and I have some questions that might be naive, but = due to lack of experience I need some guidance and clarifications. Also, = I hope I am in the right place asking those questions. >=20 > 1) What's the status of SIP Federation? It seems like there is no = official standard in there, but do we need it in order to achieve it ? = The Secure Telephone Identity Revisited IETF group [0] has done some = amazing work over the past years regarding SIP authentication = (especially from the callee side). Is that enough for having secure SIP = Federation, or are there missing pieces in the puzzle? There=E2=80=99s no official definition of =E2=80=9CFederation=E2=80=9D = in the world of SIP. The protocol was designed for open internet calls = like email, based on DNS. The question is how we can open up for that and stiil trust each other - as well as being able to have = black lists. We want no spam/spit problem. I have enough calls trying to = sell me mobile phone services as it is ;-) >=20 > 2) The WebRTC seems like it's taking a completely different road = regarding federation [1]. There, it seems like the signaling protocol = (which is not defined yet, but SIP is a major candidate), is used only = for passing over the user identities, and then the actual federation = checks take place inside the browser. I guess that's needed in case you = don't trust the site you are sitting on, like a poker site, but still = need to communicate with your friends, and verify that these are your = friends, whose identity might belong to a completely different = server/domain from yours and different from the poker site you are = sitting on. Actually that scenario is explained by [1]. But still, = that's quite different with SIP, so how is SIP interoperability is going = to work with that? Has anyone give a thought? Feels super important to = me that these 2 don't divert. WebRTC doesn=E2=80=99t really take other roads, but the signalling = behind webrtc may have different approaches. XMPP has a federation much = like SIP, but from start separated server2server connections from = client2server connections, which may make life easier. Most of the WebRTC islands seems to build = their own signalling, so there=E2=80=99s no much hope unless they can = use an open protocol like SIP or XMPP for federation. If you want federation with WebRTC, for me XMPP is the choice right now = (even though there=E2=80=99s a huge spam problem there). >=20 > 3) Olle Johannson, in a talk in Kamailio conference, said that SIP = still hasn't solved the end-to-end encryption and integrity, mostly = because, at some point the route might go through a non TLS connection. = Well that's not an easy problem to solve, but I think that [0] has = solved most of that (the integrity part), or am I wrong ? I mean, sure = the SIP request might be come with the headers stripped off, but that's = something that the callee SIP server shouldn't trust much. If it has the = necessary headers though (the passport), then the caller should be who = says it is. Of course the encryption is still remaining open, but is = this solvable at all? Anyone working on that that ? STIR is handling one problem - securing the identity and making it = trustworthy between domains. It aimed to solve the problem with phone = number spoofing, but I=E2=80=99m pretty sure we can use the PassPort in = other creative ways if we stir up some interest for it :-) If so, we = need to find out the underlying trust infrastructure for something = STIR-like on the internet. We still need to solve the TLS end to end dilemma to protect metadata in = the call - like the SDP, the DTLS fingerprint, the target of the call = and much more.=20 >=20 > 4) How people do authentication mostly in SIP, when some kind of = federation is needed? Is RFCs from [0] a common practice now? Is DANE = (which from what I understand depends on DNSSEC) something that is used = at all ? Something else ? I think one needs to separate the SIP client authentication to a service = from how different domains trust each other. SIP identity (which STIR = got inspiration from) was focused on domain to domain trust.=20 The SIP client authentication is changing quickly, as we add stronger = hash algorithms and hopefully soon Oauth2/OpenID connect. =20 To summarize: My view is that a missing bit is how =E2=80=9Cedvina.net = =E2=80=9D trustfully can call you in your domain. = How will your domain trust that the call really originates in = =E2=80=9Cedvina.net =E2=80=9D and how can you trust my identity when I call you? How can I trust that you = are the right person to answer my call? I think - if I remember = correctly - that was left as out of scope in =E2=80=9CSIP Identity=E2=80=9D= . I have recently done a lot of tests of TLS in a range of SIP desktop = phones and so far I have found no phone that can give me a decent level = of security, or a working implementation that is up to date with the TLS = standards.Unless customers stop sending them money, the vendors won=E2=80=99= t change and make it better, but there seems to be little demand for security in the = enterprise market.=20 Thank you for starting this discussion.=20 /O >=20 > I guess I fired too many questions, but I would love to get back some = clarifications. >=20 > [0] https://datatracker.ietf.org/wg/stir/documents/ = > [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 = > [2] https://www.youtube.com/watch?v=3DFO1N6gEjxUo = > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_FD40E82B-9F13-4F44-99B7-8A1965B37DFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5 May 2020, at 10:45, Filippos Vasilakis <vasilakisfil@gmail.com> wrote:

Hello everyone,

I first sent this email to sip-implementers mailing list as I = was pointed out by @sobomax and @oej, but that mailing list told me that = the things I ask are more related to this group, so here I am.

I started looking into SIP over the past = months because I find it quite interesting protocol. I have went through = various RFCs and technical documents and I have some questions that = might be naive, but due to lack of experience I need some guidance and = clarifications. Also, I hope I am in the right place asking those = questions.

1) What's the status of SIP = Federation? It seems like there is no official standard in there, but do = we need it in order to achieve it ? The Secure Telephone Identity = Revisited IETF group [0] has done some amazing work over the past years = regarding SIP authentication (especially from the callee side). Is that = enough for having secure SIP Federation, or are there missing pieces in = the puzzle?
There=E2=80=99s = no official definition of =E2=80=9CFederation=E2=80=9D in the world of = SIP. The protocol was designed for open internet calls like email, based = on DNS. The question is how we can open up
for that and stiil = trust each other - as well as being able to have black lists. We = want no spam/spit problem. I have enough calls trying to sell me mobile = phone services as it is ;-)


2) The WebRTC seems like it's taking a = completely different road regarding federation [1]. There, it seems like = the signaling protocol (which is not defined yet, but SIP is a major = candidate), is used only for passing over the user identities, and then = the actual federation checks take place inside the browser. I guess = that's needed in case you don't trust the site you are sitting on, like = a poker site, but still need to communicate with your friends, and = verify that these are your friends, whose identity might belong to a = completely different server/domain from yours and different from the = poker site you are sitting on. Actually that scenario is explained by = [1]. But still, that's quite different with SIP, so how is SIP = interoperability is going to work with that? Has anyone give a thought? = Feels super important to me that these 2 don't divert.
WebRTC doesn=E2=80=99t really = take other roads, but the signalling behind webrtc may have different = approaches. XMPP has a federation much like SIP, but from start = separated server2server connections from client2server = connections,
which may make life easier. Most of the WebRTC = islands seems to build their own signalling, so there=E2=80=99s no much = hope unless they can use an open protocol like SIP or XMPP for = federation.
If you want federation with WebRTC, for me XMPP is = the choice right now (even though there=E2=80=99s a huge spam problem = there).


3) = Olle Johannson, in a talk in Kamailio conference, said that SIP still = hasn't solved the end-to-end encryption and integrity, mostly because, = at some point the route might go through a non TLS connection. Well = that's not an easy problem to solve, but I think that [0] has solved = most of that (the integrity part), or am I wrong ? I mean, sure the SIP = request might be come with the headers stripped off, but that's = something that the callee SIP server shouldn't trust much. If it has the = necessary headers though (the passport), then the caller should be who = says it is. Of course the encryption is still remaining open, but is = this solvable at all? Anyone working on that that ?
STIR is handling one problem - = securing the identity and making it trustworthy between domains. It = aimed to solve the problem with phone number spoofing, but I=E2=80=99m = pretty sure we can use the PassPort in other creative ways if we stir up = some interest for it :-) If so, we need to find out the underlying trust = infrastructure for something STIR-like on the internet.

We still need to solve the TLS end to end dilemma = to protect metadata in the call - like the SDP, the DTLS fingerprint, = the target of the call and much more. 

4) How people do authentication mostly in SIP, = when some kind of federation is needed? Is RFCs from [0] a common = practice now? Is DANE (which from what I understand depends on DNSSEC) = something that is used at all ? Something else ?
I think one needs to = separate the SIP client authentication to a service from how different = domains trust each other. SIP identity (which STIR got inspiration from) = was focused on domain to domain trust. 
The SIP client = authentication is changing quickly, as we add stronger hash algorithms = and hopefully soon Oauth2/OpenID connect.  

To summarize: My view is that a missing bit is how = =E2=80=9Cedvina.net=E2=80=9D = trustfully can call you in your domain. How will your domain trust that = the call really originates in =E2=80=9Cedvina.net=E2=80=9D and
how can you trust my = identity when I call you? How can I trust that you are the right person = to answer my call? I think - if I remember correctly - that was left as = out of scope in =E2=80=9CSIP Identity=E2=80=9D.

I have recently done a lot of tests of TLS in a = range of SIP desktop phones and so far I have found no phone that can = give me a decent level of security,
or a working = implementation that is up to date with the TLS standards.Unless = customers stop sending them money, the vendors won=E2=80=99t change and = make
it better, but there seems to be little demand for = security in the enterprise market. 

Thank you for starting this = discussion. 

/O


I guess I fired = too many questions, but I would love to get back some clarifications.

[0] https://datatracker.ietf.org/wg/stir/documents/
[1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20<= /a>
[2] https://www.youtube.com/watch?v=3DFO1N6gEjxUo
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_FD40E82B-9F13-4F44-99B7-8A1965B37DFC-- From nobody Tue May 5 05:42:59 2020 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 437C33A0365; Tue, 5 May 2020 05:42:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <158868252119.22560.16454369977290480721@ietfa.amsl.com> Date: Tue, 05 May 2020 05:42:01 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-15.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 12:42:04 -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 WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-15.txt Pages : 17 Date : 2020-05-05 Abstract: This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-15 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-15 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 Tue May 5 05:46:18 2020 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 21DBE3A0404 for ; Tue, 5 May 2020 05:46:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 jWHZ5WKg0s3m for ; Tue, 5 May 2020 05:46:13 -0700 (PDT) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (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 D2F5B3A0408 for ; Tue, 5 May 2020 05:46:12 -0700 (PDT) Received: by mail-qk1-x744.google.com with SMTP id k81so2061241qke.5 for ; Tue, 05 May 2020 05:46:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3OPwnE7AHniDsYIKNM124UQRQ6vg2LJE0B3hRDSw6hU=; b=iaRDXnQYttVXPpAfats/1RfqqF40xKAKV3MA7ndmmAvnYjpKNm7iUgCUKe7A7GvuDX dnS2xrfAk/qqLCkUyu2lmXb7Fhh6K4Nf2ObtMRd96Ke7a7qNzhb+OF2gZ0ujGIztGNMX ri4U759wQZB/TMmQRJW1kmuQXCJd1YvkV/nGaXGlQO0UxQWPYqRiMGTKMDEdhApyVxay fTMsf5FF6/QW3Gu1hJkdxmvZfShxrdZ0dK+Wle/m9Rpxk7JAreoeh1vOD4JgZAmVXlgG iOt1/zotx2eja7kJGoM9epE4aohw0uvuydELJGNat+NqOOxvl06tybWj5uz04sbRK08P ocLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3OPwnE7AHniDsYIKNM124UQRQ6vg2LJE0B3hRDSw6hU=; b=Zw0ta8FmkvjRiY+mEy8fCXlpgwvtBNa4qHrNm2xarkeZYvmzF7rfmOUikVscRNukP+ VsIQtUGRX+qtnbwRNYG0kg/N9UV87n4+lwc3X+jDvuG5kM/ZIfaEtqrjf1MsPN3x0xh4 9wBsZuNMlz2Yhq5DMYfjklgY4bTeptEiKuXN2McFMHZe6n41A8TiwPQ4E1Ds8jyokiQf hUR3Qt1BGvWHXFdk2Yb9Tf2eWDYA2PnNCZ6Fr8hR6erwhJLZkcB02swtNz5JmQfKBXTL N6yHcNPtT84NIp48F21JcdkKWGgrPw/EqDPHooNF/R/Dup2vGfV30b+MhFHP752iNTj9 Ezbw== X-Gm-Message-State: AGi0PuZSWTOqxnwOLQNWjZuTFvrlndkqbpHk2V0VUdGch8fEn+6k3GlR WqGPOdYENIr+fPB3unoK+404JQ== X-Google-Smtp-Source: APiQypLFhbdUllYE8VNJDIC8xvQ00q6PYZJNI/7CFUkfcfRAPVrk5TZP50d6saqqzy9dGEtjNrs+4w== X-Received: by 2002:a37:47c3:: with SMTP id u186mr3021936qka.117.1588682771731; Tue, 05 May 2020 05:46:11 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id m7sm1712273qke.124.2020.05.05.05.46.10 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 May 2020 05:46:11 -0700 (PDT) From: Brian Rosen Message-Id: <75951579-9835-449A-BC2F-B3DEFCDC127C@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_2D86F974-107A-4BDA-B3E1-834A22488733" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Date: Tue, 5 May 2020 08:46:07 -0400 In-Reply-To: Cc: sipcore@ietf.org To: Filippos Vasilakis References: X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] SIP Federation, authentication and interoperability with WebRTC X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 12:46:16 -0000 --Apple-Mail=_2D86F974-107A-4BDA-B3E1-834A22488733 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This email list is for discussions of work in the IETF on core SIP, = mostly extensions and bug fixes for SIP. It=E2=80=99s not a general SIP = discussion forum. But, to answer your questions: > On May 5, 2020, at 4:45 AM, Filippos Vasilakis = wrote: >=20 > Hello everyone, >=20 > I first sent this email to sip-implementers mailing list as I was = pointed out by @sobomax and @oej, but that mailing list told me that the = things I ask are more related to this group, so here I am. >=20 > I started looking into SIP over the past months because I find it = quite interesting protocol. I have went through various RFCs and = technical documents and I have some questions that might be naive, but = due to lack of experience I need some guidance and clarifications. Also, = I hope I am in the right place asking those questions. >=20 > 1) What's the status of SIP Federation? It seems like there is no = official standard in there, but do we need it in order to achieve it ? = The Secure Telephone Identity Revisited IETF group [0] has done some = amazing work over the past years regarding SIP authentication = (especially from the callee side). Is that enough for having secure SIP = Federation, or are there missing pieces in the puzzle? Depends on what you mean by =E2=80=9CFederation=E2=80=9D. Reliable = authentication <> federation but it=E2=80=99s a piece. As deployed, SIP = either uses telephone numbers (or extensions) as identity, or SIP URIs = within a domain. Stir addresses authentication for telephone numbers. = It certainly can also be used to secure identity with other forms of SIP = URIs. What else do you think you need for federation? Of course SIP is = successfully used in IMS networks which power virtually all of the = worldwide mobile networks, and it=E2=80=99s also used in most VoIP, = cable and enterprise phone systems. =20 >=20 > 2) The WebRTC seems like it's taking a completely different road = regarding federation [1]. There, it seems like the signaling protocol = (which is not defined yet, but SIP is a major candidate), is used only = for passing over the user identities, and then the actual federation = checks take place inside the browser. I guess that's needed in case you = don't trust the site you are sitting on, like a poker site, but still = need to communicate with your friends, and verify that these are your = friends, whose identity might belong to a completely different = server/domain from yours and different from the poker site you are = sitting on. Actually that scenario is explained by [1]. But still, = that's quite different with SIP, so how is SIP interoperability is going = to work with that? Has anyone give a thought? Feels super important to = me that these 2 don't divert. As deployed, virtually all WebRTC is within a single domain. There just = aren=E2=80=99t any large cross domain instances. There is work in = something called =E2=80=9CIVC=E2=80=9D that is trying to encourage cross = domain video conferencing, which would use telephone numbers as = identities, and thus can also use stir. But there is no work on = federation between WebRTC domains. =20 >=20 > 3) Olle Johannson, in a talk in Kamailio conference, said that SIP = still hasn't solved the end-to-end encryption and integrity, mostly = because, at some point the route might go through a non TLS connection. = Well that's not an easy problem to solve, but I think that [0] has = solved most of that (the integrity part), or am I wrong ? I mean, sure = the SIP request might be come with the headers stripped off, but that's = something that the callee SIP server shouldn't trust much. If it has the = necessary headers though (the passport), then the caller should be who = says it is. Of course the encryption is still remaining open, but is = this solvable at all? Anyone working on that that ? The end to end problem comes about because SIP signaling is hop by hop. = If you use TLS on every hop, that=E2=80=99s good but a) the endpoints = don=E2=80=99t know if that happened or not, and (b) that isn=E2=80=99t = end-to-end encryption. There was early work that used S/MIME which = would be end-to-end, but it was never implemented. We aren't currently = motivated to deal with that. >=20 > 4) How people do authentication mostly in SIP, when some kind of = federation is needed? Is RFCs from [0] a common practice now? Is DANE = (which from what I understand depends on DNSSEC) something that is used = at all ? Something else ? stir is being implemented widely in some places (the United States PSTN = for example). It=E2=80=99s being implemented to stop robocalling, but = it=E2=80=99s also going to stop things like SWATing. There isn=E2=80=99t = much else going on. No one I know uses DANE with SIP except = accidentally, and while secure DNS is always desirable, it=E2=80=99s = only a small part of authenticating sip. >=20 > I guess I fired too many questions, but I would love to get back some = clarifications. Those are mine. You should probably drop sipcore from any reply you = have to this. Brian sipcore co-chair >=20 > [0] https://datatracker.ietf.org/wg/stir/documents/ = > [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 = > [2] https://www.youtube.com/watch?v=3DFO1N6gEjxUo = > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail=_2D86F974-107A-4BDA-B3E1-834A22488733 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 This = email list is for discussions of work in the IETF on core SIP, mostly = extensions and bug fixes for SIP.  It=E2=80=99s not a general SIP = discussion forum.  But, to answer your questions:

On May 5, 2020, at 4:45 AM, Filippos Vasilakis <vasilakisfil@gmail.com> wrote:

Hello everyone,

I first sent this email to sip-implementers mailing list as I = was pointed out by @sobomax and @oej, but that mailing list told me that = the things I ask are more related to this group, so here I am.

I started looking into SIP over the past = months because I find it quite interesting protocol. I have went through = various RFCs and technical documents and I have some questions that = might be naive, but due to lack of experience I need some guidance and = clarifications. Also, I hope I am in the right place asking those = questions.

1) What's the status of SIP = Federation? It seems like there is no official standard in there, but do = we need it in order to achieve it ? The Secure Telephone Identity = Revisited IETF group [0] has done some amazing work over the past years = regarding SIP authentication (especially from the callee side). Is that = enough for having secure SIP Federation, or are there missing pieces in = the puzzle?
Depends on what = you mean by =E2=80=9CFederation=E2=80=9D.  Reliable authentication = <> federation but it=E2=80=99s a piece. As deployed, SIP either = uses telephone numbers (or extensions) as identity, or SIP URIs within a = domain.  Stir addresses authentication for telephone numbers. =  It certainly can also be used to secure identity with other forms = of SIP URIs.  What else do you think you need for federation? =  Of course SIP is successfully used in IMS networks which power = virtually all of the worldwide mobile networks, and it=E2=80=99s also = used in most VoIP, cable and enterprise phone systems.  

2) The WebRTC = seems like it's taking a completely different road regarding federation = [1]. There, it seems like the signaling protocol (which is not defined = yet, but SIP is a major candidate), is used only for passing over the = user identities, and then the actual federation checks take place inside = the browser. I guess that's needed in case you don't trust the site you = are sitting on, like a poker site, but still need to communicate with = your friends, and verify that these are your friends, whose identity = might belong to a completely different server/domain from yours and = different from the poker site you are sitting on. Actually that scenario = is explained by [1]. But still, that's quite different with SIP, so how = is SIP interoperability is going to work with that? Has anyone give a = thought? Feels super important to me that these 2 don't divert.
As deployed, virtually all = WebRTC is within a single domain.  There just aren=E2=80=99t any = large cross domain instances.  There is work in something called = =E2=80=9CIVC=E2=80=9D that is trying to encourage cross domain video = conferencing, which would use telephone numbers as identities, and thus = can also use stir.  But there is no work on federation between = WebRTC domains.  
3) Olle Johannson, in a talk in Kamailio conference, said = that SIP still hasn't solved the end-to-end encryption and integrity, = mostly because, at some point the route might go through a non TLS = connection. Well that's not an easy problem to solve, but I think that = [0] has solved most of that (the integrity part), or am I wrong ? I = mean, sure the SIP request might be come with the headers stripped off, = but that's something that the callee SIP server shouldn't trust much. If = it has the necessary headers though (the passport), then the caller = should be who says it is. Of course the encryption is still remaining = open, but is this solvable at all? Anyone working on that that = ?
The end to end problem comes about = because SIP signaling is hop by hop.  If you use TLS on every hop, = that=E2=80=99s good but a) the endpoints don=E2=80=99t know if that = happened or not, and (b) that isn=E2=80=99t end-to-end encryption. =  There was early work that used S/MIME which would be end-to-end, = but it was never implemented.  We aren't currently motivated to = deal with that.

4) How people do authentication mostly in SIP, when some = kind of federation is needed? Is RFCs from [0] a common practice now? Is = DANE (which from what I understand depends on DNSSEC) something that is = used at all ? Something else ?
stir is being implemented = widely in some places (the United States PSTN for example).  It=E2=80= =99s being implemented to stop robocalling, but it=E2=80=99s also going = to stop things like SWATing.  There isn=E2=80=99t much else going = on.  No one I know uses DANE with SIP except accidentally, and = while secure DNS is always desirable, it=E2=80=99s only a small part of = authenticating sip.

I guess I fired too many questions, but I would love to get = back some clarifications.
Those are mine.  You = should probably drop sipcore from any reply you have to = this.

Brian
sipcore = co-chair

[0] = https://datatracker.ietf.org/wg/stir/documents/
[1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20<= /a>
[2] https://www.youtube.com/watch?v=3DFO1N6gEjxUo
_______________________________________________
sipcore = mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

= --Apple-Mail=_2D86F974-107A-4BDA-B3E1-834A22488733-- From nobody Tue May 5 06:15:24 2020 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 7F55A3A064A; Tue, 5 May 2020 06:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, 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=cert.org 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 NMsGWBk2McDV; Tue, 5 May 2020 06:15:17 -0700 (PDT) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 8E6903A0765; Tue, 5 May 2020 06:15:17 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 045DFC5P024734; Tue, 5 May 2020 09:15:12 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 045DFC5P024734 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1588684512; bh=Vg3IFjGu922lQOxe1B/qL+Vw9w8U1jFIWBOrRrolAkw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ATWILbtRl7/xSjrjY6R+s+44LEwDig6rDLnBGZIVLZ2n3ZYD/Tru6UNir+NLQPK2G QdOIGQJsq5XXhFRV1PvxyckL3rtXQG39dIOmNUdajkh7UltdkBdVR2kwIYjydNRAfD l9mkKvfsy4XbiEzHRuK3OipCaj2rt5q3vIhVIA20= Received: from CASSINA.ad.sei.cmu.edu (cassina.ad.sei.cmu.edu [10.64.28.249]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 045DFAUP020888; Tue, 5 May 2020 09:15:10 -0400 Received: from MURIEL.ad.sei.cmu.edu (147.72.252.47) by CASSINA.ad.sei.cmu.edu (10.64.28.249) with Microsoft SMTP Server (TLS) id 14.3.487.0; Tue, 5 May 2020 09:15:09 -0400 Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Tue, 5 May 2020 09:15:09 -0400 Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%22]) with mapi id 15.01.1847.007; Tue, 5 May 2020 09:15:09 -0400 From: Roman Danyliw To: Rifaat Shekh-Yusef , Christer Holmberg CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , "Jean Mahoney" Thread-Topic: Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT Thread-Index: AQHWGMMOtxZIT3jHHk6raCfflxfIDqiFsLAAgBPb28A= Date: Tue, 5 May 2020 13:15:09 +0000 Message-ID: <650304eeff354140bdfe6e7dd20fa4b8@cert.org> References: <469529BD-F254-4B45-9000-E1F5B8463A08@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.202.196] Content-Type: multipart/alternative; boundary="_000_650304eeff354140bdfe6e7dd20fa4b8certorg_" MIME-Version: 1.0 Archived-At: Subject: Re: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 13:15:21 -0000 --_000_650304eeff354140bdfe6e7dd20fa4b8certorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUmlmYWF0IGFuZCBDaHJpc3RlciENCg0KVGhhbmtzIGZvciB0aGUgdXBkYXRlcyBtYWRlIGlu IC0xNCBhbmQgLTE1LiAgVGhleSBhZGRyZXNzIGJvdGggbXkgRElTQ1VTUyBhbmQgQ09NTUVOVCBp dGVtcy4gIEnigJl2ZSBjbGVhcmVkIG15IGJhbGxvdC4NCg0KUmVnYXJkcywNClJvbWFuDQoNCkZy b206IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KU2VudDogV2Vk bmVzZGF5LCBBcHJpbCAyMiwgMjAyMCAxOjU4IFBNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNo cmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiBSb21hbiBEYW55bGl3IDxyZGRAY2Vy dC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtc2lwY29yZS1zaXAt dG9rZW4tYXV0aG56QGlldGYub3JnOyBzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZzsgc2lwY29yZUBp ZXRmLm9yZzsgSmVhbiBNYWhvbmV5IDxtYWhvbmV5QG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6 IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4t YXV0aG56LTEzOiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKSAtIENPTU1FTlQNCg0KSGkgUm9t YW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmlldyENCg0KUmVnYXJkaW5nIHRoZSBESVNDVVNTOg0K DQpTZWN0aW9uIDIuMS4xLCAzcmQgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLCBoYXMgYSBiaXQg bW9yZSBhYm91dCB0aGUgdXNhZ2Ugb2YgdGhlIElEIFRva2VuLiBIb3cgYWJvdXQgZXh0ZW5kaW5n IHRoYXQgYXMgZm9sbG93czoNCkFuIE9wZW5JRCBDb25uZWN0IHNlcnZlciByZXR1cm5zIGFuIGFk ZGl0aW9uYWwgSUQgVG9rZW4gdGhhdCBjb250YWlucyBjbGFpbXMgYWJvdXQNCnRoZSBhdXRoZW50 aWNhdGlvbiBvZiB0aGUgdXNlciBieSBhbiBBdXRob3JpemF0aW9uIFNlcnZlci4gVGhlIElEIFRv a2VuIGNhbiBwb3RlbnRpYWxseQ0KaW5jbHVkZSBvdGhlciBvcHRpb25hbCBjbGFpbXMgYWJvdXQg dGhlIHVzZXIsIGUuZy4gdGhlIFNJUCBVUkksIHRoYXQgd2lsbCBiZSBjb25zdW1lZCBieQ0KdGhl IFVBQyBhbmQgbGF0ZXIgdXNlZCB0byByZWdpc3RlciB3aXRoIHRoZSBTSVAgUmVnaXN0cmFyLg0K DQpNb3JlIGlubGluZSByZWdhcmRpbmcgc29tZSBvZiB0aGUgY29tbWVudHMuDQoNClJlZ2FyZHMs DQogUmlmYWF0DQoNCg0KDQpPbiBXZWQsIEFwciAyMiwgMjAyMCBhdCAxMjoyOCBQTSBDaHJpc3Rl ciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rl ci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3cm90ZToNCkhJIFJvbWFuLA0KDQpUaGFuayBZb3Ug Zm9yIHRoZSByZXZpZXchIEluIHRoaXMgcmVwbHkgSSB3aWxsIGFkZHJlc3MgbW9zdCBvZiB5b3Vy IENPTU1FTlQgaXNzdWVzLiBUaGUgRElTQ1VTUyBpc3N1ZSwgYW5kIGEgY291cGxlIG9mIENPTU1F TlQgaXNzdWVzLCB3aWxsIGJlIGFkZHJlc3NlZCBpbiBhIHNlcGFyYXRlIHJlcGx5Lg0KDQogICAg LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgPioq IFNlY3Rpb24gMS4zLiAgUGVyIOKAnEFjY2VzcyBUb2tlbnMgY291bGQgYmUgcmVwcmVzZW50ZWQg aW4gb25lIG9mIHRoZSBhYm92ZQ0KICAgID50d28gZm9ybWF0cy7igJ0sIGlmIG5vdCBvbmUgb2Yg dGhlc2UgdHdvIGZvcm1hdHMsIHRoZW4gd2hpY2ggb3RoZXIgb25lcz8NCg0KICAgIEkgc3VnZ2Vz dCB0byBjaGFuZ2UgImNvdWxkIiB0byAiY2FuIi4NCg0KSG93IGFib3V0IHJlcGxhY2luZyAiY291 bGQgYmUiIHdpdGggImFyZSI/DQoNCg0KLS0tDQoNCiAgICA+ICoqIFNlY3Rpb24gMi4xLjEuICBQ ZXIg4oCcQW4gT3BlbklEIENvbm5lY3Qgc2VydmVyIOKApuKAnSwgYmFzZWQgb24gdGhlIGZsb3dz DQogICAgPiBkZXBpY3RlZCBpbiBGaWd1cmUgMSBhbmQgMiwgaG93IHRoZSBPcGVuSUQgQ29ubmVj dCBzZXJ2ZXIgZml0cyBpc27igJl0IGNsZWFyLg0KDQpXZSB3aWxsIGFkZHJlc3MgdGhpcyBpbiB0 aGUgcmVwbHkgdGhhdCBhZGRyZXNzZXMgdGhlIERJU0NVU1MsIGFzIHRoZSBpc3N1ZXMgYXJlIHJl bGF0ZWQuDQpUaGUgQVMgY291bGQgYmUgYSB0eXBpY2FsIE9BdXRoIEF1dGhvcml6YXRpb24gU2Vy dmVyIG9yIGFuIE9wZW5JRCBQcm92aWRlciAoT1ApLg0KV291bGQgY2hhbmdpbmcgdGhlICJBUyIg Y29sdW1uIGluIHRoZSBmaWd1cmVzIHRvICJBUy9PUCIgaGVscD8NCg0KDQotLS0NCg0KICAgID4g KiogU2VjdGlvbiAyLjEuMi4gIFBlciDigJxFbmRwb2ludHMgdGhhdCBzdXBwb3J0IHRoaXMgc3Bl Y2lmaWNhdGlvbiBNVVNUIHN1cHBvcnQNCiAgICA+IGVuY3J5cHRlZCBKU09OIFdlYiBUb2tlbnMg KEpXVCkgW1JGQzc1MTldIGZvciBlbmNvZGluZyBhbmQgcHJvdGVjdGluZyBhY2Nlc3MNCiAgICA+ IHRva2VucyB3aGVuIHRoZXkgYXJlIGluY2x1ZGVkIGluIFNJUCByZXF1ZXN0cywgdW5sZXNzIHNv bWUgb3RoZXIgbWVjaGFuaXNtIGlzDQogICAgPiB1c2VkIHRvIGd1YXJhbnRlZSB0aGF0IG9ubHkg YXV0aG9yaXplZCBTSVAgZW5kcG9pbnRzIGhhdmUgYWNjZXNzIHRvIHRoZSBhY2Nlc3MNCiAgICA+ IHRva2VuLuKAnSAtLSBpcyBpdCB0aGUg4oCcdXNlIG9m4oCdIG9yIOKAnHN1cHBvcnQgZm9y4oCd IEpXVCB0aGF0IGlzIHJlcXVpcmVkIGlmIHRoZXJlDQogICAgPiBpc27igJl0IGFuIGFsdGVybmF0 aXZlPyAgU2VjdGlvbiA1IHVzZXMgc2ltaWxhciBsYW5ndWFnZS4NCg0KIk1VU1QgdXNlIiBpcyBt b3JlIGNvcnJlY3QuDQoNCi0tLQ0KDQogICAgPiAqKiBTZWN0aW9uIDIuMS4zLiAgUGVyIOKAnE5v dGUgdGhhdCwgaWYgdGhlcmUgd2VyZSBtdWx0aXBsZSBjaGFsbGVuZ2VzIHdpdGgNCiAgICA+IGRp ZmZlcmVudCBzY2hlbWVzLCB0aGVuIHRoZSBVQUMgbWF5IGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5 IHJldHJ5IHRoZSByZXF1ZXN0DQogICAgPiB1c2luZyBub24tQmVhcmVyIGNyZWRlbnRpYWxzLuKA nSwgd291bGQgdGhhdCBkZWNpc2lvbiBiZSBtYWRlIGJhc2VkIG9uIGxvY2FsDQogICAgPiBwb2xp Y3k/DQoNClllcy4gVGhhdCBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiAyLjEuMS48aHR0cDovLzIu MS4xLj46DQoNCiAgICJJZiB0aGUgVUFDIHJlY2VpdmVzIGEgNDAxLzQwNyByZXNwb25zZSB3aXRo IG11bHRpcGxlIFdXVy0NCiAgIEF1dGhlbnRpY2F0ZS9Qcm94eS1BdXRoZW50aWNhdGUgaGVhZGVy IGZpZWxkcywgcHJvdmlkaW5nIGNoYWxsZW5nZXMNCiAgIHVzaW5nIGRpZmZlcmVudCBhdXRoZW50 aWNhdGlvbiBzY2hlbWVzIGZvciB0aGUgc2FtZSByZWFsbSwgdGhlIFVBQw0KICAgc2VsZWN0cyBv bmUgb3IgbW9yZSBvZiB0aGUgcHJvdmlkZWQgc2NoZW1lcyAoYmFzZWQgb24gbG9jYWwgcG9saWN5 KQ0KICAgYW5kIHByb3ZpZGVzIGNyZWRlbnRpYWxzIGZvciB0aG9zZSBzY2hlbWVzLiINCg0KLS0t DQoNCiAgICA+ICoqIFNlY3Rpb24gNS4gIFNob3VsZCB0aGUgdXNlIG9mIHRoZSBzY29wZSBwYXJh bWV0ZXIgYmUgbm90ZWQgKG9yIFJFQ09NTUVOREVEKQ0KICAgID4gdG8gbmFycm93IHRoZSB1dGls aXR5IG9mIHRoZSB0b2tlbj8NCg0KICAgIEkgd2lsbCByZWZlciB0aGlzIHRvIFJpZmFhdC4NCg0K SG93IGFib3V0IGFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIHRoaXMgc2VjdGlvbjoN Cg0KVGhlIFNJUCBSZWdpc3RyYXIgU0hPVUxEIGluY2x1ZGUgYSBTY29wZSBwYXJhbWV0ZXIgdG8g Y29udHJvbCB0aGUgbWluaW11bSBsZXZlbCBvZiBzZXJ2aWNlIGFjY2Vzcw0KdGhlIGNsaWVudCBp cyByZXF1aXJlZCB0byBvYnRhaW4gZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2ZXIgdG8gYmUg YWJsZSB0byByZWdpc3RlciB3aXRoIHRoZSBTSVAgUmVnaXN0cmFyLg0KDQpSZWdhcmRzLA0KIFJp ZmFhdA0KDQoNCi0tLQ0KDQogICAgPiAqKiBFZGl0b3JpYWwgTml0czoNCiAgICA+IFNlY3Rpb24g MS4zLiAgVHlwby4gcy91c3VhbHkvdXN1YWxseS8NCg0KICAgIFdpbGwgZml4Lg0KDQogICAgPiBT ZWN0aW9uIDcuICBUeXBvLiAgcy9jb3ZlcnNpb24vY29udmVyc2lvbi8NCg0KICAgIFdpbGwgZml4 Lg0KDQotLS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQo= --_000_650304eeff354140bdfe6e7dd20fa4b8certorg_ 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 bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aSBSaWZhYXQgYW5kIENocmlzdGVyITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9y IHRoZSB1cGRhdGVzIG1hZGUgaW4gLTE0IGFuZCAtMTUuJm5ic3A7IFRoZXkgYWRkcmVzcyBib3Ro IG15IERJU0NVU1MgYW5kIENPTU1FTlQgaXRlbXMuJm5ic3A7IEnigJl2ZSBjbGVhcmVkIG15IGJh bGxvdC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlJvbWFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBSaWZhYXQgU2hla2gtWXVzZWYgJmx0O3JpZmFhdC5pZXRmQGdtYWlsLmNvbSZndDsgPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgQXByaWwgMjIsIDIwMjAgMTo1OCBQTTxicj4NCjxi PlRvOjwvYj4gQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29u LmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvbWFuIERhbnlsaXcgJmx0O3JkZEBjZXJ0Lm9yZyZn dDs7IFRoZSBJRVNHICZsdDtpZXNnQGlldGYub3JnJmd0OzsgZHJhZnQtaWV0Zi1zaXBjb3JlLXNp cC10b2tlbi1hdXRobnpAaWV0Zi5vcmc7IHNpcGNvcmUtY2hhaXJzQGlldGYub3JnOyBzaXBjb3Jl QGlldGYub3JnOyBKZWFuIE1haG9uZXkgJmx0O21haG9uZXlAbm9zdHJ1bS5jb20mZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBSb21hbiBEYW55bGl3J3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRm LXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuei0xMzogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkg LSBDT01NRU5UPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9tYW4s PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9y IHRoZSByZXZpZXchPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlJlZ2FyZGluZyB0aGUgRElTQ1VTUzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5TZWN0aW9uIDIuMS4xLCAzcmQgcGFyYWdyYXBoLCBsYXN0IHNlbnRlbmNlLCBoYXMgYSBiaXQg bW9yZSBhYm91dCB0aGUgdXNhZ2Ugb2YgdGhlIElEIFRva2VuLiBIb3cgYWJvdXQgZXh0ZW5kaW5n IHRoYXQgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbiBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXIgcmV0 dXJucyBhbiBhZGRpdGlvbmFsIElEIFRva2VuIHRoYXQgY29udGFpbnMgY2xhaW1zIGFib3V0DQo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnRoZSBhdXRoZW50aWNhdGlvbiBvZiB0aGUgdXNlciBieSBhbiBBdXRob3JpemF0 aW9uIFNlcnZlci4gVGhlIElEIFRva2VuIGNhbiBwb3RlbnRpYWxseQ0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbmNs dWRlIG90aGVyIG9wdGlvbmFsIGNsYWltcyBhYm91dCB0aGUgdXNlciwgZS5nLiB0aGUgU0lQIFVS SSwgdGhhdCB3aWxsIGJlIGNvbnN1bWVkIGJ5DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBVQUMgYW5kIGxhdGVy IHVzZWQgdG8gcmVnaXN0ZXIgd2l0aCB0aGUgU0lQIFJlZ2lzdHJhci48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+TW9yZSBpbmxpbmUgcmVnYXJkaW5nIHNvbWUgb2YgdGhlIGNvbW1lbnRzLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdh cmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7UmlmYWF0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBXZWQsIEFwciAyMiwgMjAyMCBhdCAxMjoyOCBQTSBDaHJpc3RlciBI b2xtYmVyZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bSI+Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ISSBSb21h biw8YnI+DQo8YnI+DQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXchIEluIHRoaXMgcmVwbHkgSSB3 aWxsIGFkZHJlc3MgbW9zdCBvZiB5b3VyIENPTU1FTlQgaXNzdWVzLiBUaGUgRElTQ1VTUyBpc3N1 ZSwgYW5kIGEgY291cGxlIG9mIENPTU1FTlQgaXNzdWVzLCB3aWxsIGJlIGFkZHJlc3NlZCBpbiBh IHNlcGFyYXRlIHJlcGx5Ljxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxi cj4NCiZuYnNwOyAmbmJzcDsgQ09NTUVOVDo8YnI+DQombmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsqKiBTZWN0aW9uIDEuMy4mbmJzcDsgUGVy IOKAnEFjY2VzcyBUb2tlbnMgY291bGQgYmUgcmVwcmVzZW50ZWQgaW4gb25lIG9mIHRoZSBhYm92 ZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0O3R3byBmb3JtYXRzLuKAnSwgaWYgbm90IG9uZSBvZiB0 aGVzZSB0d28gZm9ybWF0cywgdGhlbiB3aGljaCBvdGhlciBvbmVzPzxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgSSBzdWdnZXN0IHRvIGNoYW5nZSAmcXVvdDtjb3VsZCZxdW90OyB0byAmcXVvdDtj YW4mcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Ib3cgYWJvdXQgcmVwbGFjaW5nICZxdW90O2NvdWxkIGJlJnF1b3Q7IHdp dGggJnF1b3Q7YXJlJnF1b3Q7PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi Pjxicj4NCi0tLTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAqKiBTZWN0aW9uIDIuMS4x LiZuYnNwOyBQZXIg4oCcQW4gT3BlbklEIENvbm5lY3Qgc2VydmVyIOKApuKAnSwgYmFzZWQgb24g dGhlIGZsb3dzPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGRlcGljdGVkIGluIEZpZ3VyZSAxIGFu ZCAyLCBob3cgdGhlIE9wZW5JRCBDb25uZWN0IHNlcnZlciBmaXRzIGlzbuKAmXQgY2xlYXIuPGJy Pg0KPGJyPg0KV2Ugd2lsbCBhZGRyZXNzIHRoaXMgaW4gdGhlIHJlcGx5IHRoYXQgYWRkcmVzc2Vz IHRoZSBESVNDVVNTLCBhcyB0aGUgaXNzdWVzIGFyZSByZWxhdGVkLjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIEFTIGNvdWxkIGJlIGEgdHlw aWNhbCBPQXV0aCBBdXRob3JpemF0aW9uIFNlcnZlciBvciBhbiBPcGVuSUQgUHJvdmlkZXIgKE9Q KS48YnI+DQpXb3VsZCBjaGFuZ2luZyB0aGUgJnF1b3Q7QVMmcXVvdDsgY29sdW1uIGluIHRoZSBm aWd1cmVzIHRvICZxdW90O0FTL09QJnF1b3Q7IGhlbHA/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+LS0tPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICoqIFNlY3Rpb24gMi4xLjIuJm5i c3A7IFBlciDigJxFbmRwb2ludHMgdGhhdCBzdXBwb3J0IHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNU IHN1cHBvcnQ8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgZW5jcnlwdGVkIEpTT04gV2ViIFRva2Vu cyAoSldUKSBbUkZDNzUxOV0gZm9yIGVuY29kaW5nIGFuZCBwcm90ZWN0aW5nIGFjY2Vzczxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyB0b2tlbnMgd2hlbiB0aGV5IGFyZSBpbmNsdWRlZCBpbiBTSVAg cmVxdWVzdHMsIHVubGVzcyBzb21lIG90aGVyIG1lY2hhbmlzbSBpczxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyB1c2VkIHRvIGd1YXJhbnRlZSB0aGF0IG9ubHkgYXV0aG9yaXplZCBTSVAgZW5kcG9p bnRzIGhhdmUgYWNjZXNzIHRvIHRoZSBhY2Nlc3M8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgdG9r ZW4u4oCdIC0tIGlzIGl0IHRoZSDigJx1c2Ugb2bigJ0gb3Ig4oCcc3VwcG9ydCBmb3LigJ0gSldU IHRoYXQgaXMgcmVxdWlyZWQgaWYgdGhlcmU8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgaXNu4oCZ dCBhbiBhbHRlcm5hdGl2ZT8mbmJzcDsgU2VjdGlvbiA1IHVzZXMgc2ltaWxhciBsYW5ndWFnZS48 YnI+DQo8YnI+DQomcXVvdDtNVVNUIHVzZSZxdW90OyBpcyBtb3JlIGNvcnJlY3QuPGJyPg0KPGJy Pg0KLS0tPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICoqIFNlY3Rpb24gMi4xLjMuJm5i c3A7IFBlciDigJxOb3RlIHRoYXQsIGlmIHRoZXJlIHdlcmUgbXVsdGlwbGUgY2hhbGxlbmdlcyB3 aXRoPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IGRpZmZlcmVudCBzY2hlbWVzLCB0aGVuIHRoZSBV QUMgbWF5IGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHJldHJ5IHRoZSByZXF1ZXN0PGJyPg0KJm5i c3A7ICZuYnNwOyAmZ3Q7IHVzaW5nIG5vbi1CZWFyZXIgY3JlZGVudGlhbHMu4oCdLCB3b3VsZCB0 aGF0IGRlY2lzaW9uIGJlIG1hZGUgYmFzZWQgb24gbG9jYWw8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgcG9saWN5Pzxicj4NCjxicj4NClllcy4gVGhhdCBpcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA8 YSBocmVmPSJodHRwOi8vMi4xLjEuIiB0YXJnZXQ9Il9ibGFuayI+Mi4xLjEuPC9hPjo8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7JnF1b3Q7SWYgdGhlIFVBQyByZWNlaXZlcyBhIDQwMS80MDcgcmVz cG9uc2Ugd2l0aCBtdWx0aXBsZSBXV1ctPGJyPg0KJm5ic3A7ICZuYnNwO0F1dGhlbnRpY2F0ZS9Q cm94eS1BdXRoZW50aWNhdGUgaGVhZGVyIGZpZWxkcywgcHJvdmlkaW5nIGNoYWxsZW5nZXM8YnI+ DQombmJzcDsgJm5ic3A7dXNpbmcgZGlmZmVyZW50IGF1dGhlbnRpY2F0aW9uIHNjaGVtZXMgZm9y IHRoZSBzYW1lIHJlYWxtLCB0aGUgVUFDPGJyPg0KJm5ic3A7ICZuYnNwO3NlbGVjdHMgb25lIG9y IG1vcmUgb2YgdGhlIHByb3ZpZGVkIHNjaGVtZXMgKGJhc2VkIG9uIGxvY2FsIHBvbGljeSk8YnI+ DQombmJzcDsgJm5ic3A7YW5kIHByb3ZpZGVzIGNyZWRlbnRpYWxzIGZvciB0aG9zZSBzY2hlbWVz LiZxdW90Ozxicj4NCjxicj4NCi0tLTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAqKiBT ZWN0aW9uIDUuJm5ic3A7IFNob3VsZCB0aGUgdXNlIG9mIHRoZSBzY29wZSBwYXJhbWV0ZXIgYmUg bm90ZWQgKG9yIFJFQ09NTUVOREVEKTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB0byBuYXJyb3cg dGhlIHV0aWxpdHkgb2YgdGhlIHRva2VuPzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSB3aWxs IHJlZmVyIHRoaXMgdG8gUmlmYWF0LjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IGFib3V0IGFkZGluZyB0aGUgZm9sbG93aW5n IHNlbnRlbmNlIHRvIHRoaXMgc2VjdGlvbjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tbGVmdDozMC4wcHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBTSVAgUmVnaXN0cmFy IFNIT1VMRCBpbmNsdWRlIGEgU2NvcGUgcGFyYW1ldGVyIHRvIGNvbnRyb2wgdGhlIG1pbmltdW0g bGV2ZWwgb2Ygc2VydmljZSBhY2Nlc3MmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBjbGllbnQgaXMgcmVx dWlyZWQgdG8gb2J0YWluIGZyb20gdGhlIEF1dGhvcml6YXRpb24gU2VydmVyIHRvIGJlIGFibGUg dG8gcmVnaXN0ZXIgd2l0aCB0aGUgU0lQIFJlZ2lzdHJhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ LS0tPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICoqIEVkaXRvcmlhbCBOaXRzOjxicj4N CiZuYnNwOyAmbmJzcDsgJmd0OyBTZWN0aW9uIDEuMy4mbmJzcDsgVHlwby4gcy91c3VhbHkvdXN1 YWxseS88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFdpbGwgZml4Ljxicj4NCjxicj4NCiZuYnNw OyAmbmJzcDsgJmd0OyBTZWN0aW9uIDcuJm5ic3A7IFR5cG8uJm5ic3A7IHMvY292ZXJzaW9uL2Nv bnZlcnNpb24vPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBXaWxsIGZpeC48YnI+DQo8YnI+DQot LS08YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0KPGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_650304eeff354140bdfe6e7dd20fa4b8certorg_-- From nobody Tue May 5 07:05:48 2020 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 E35AC3A0407; Tue, 5 May 2020 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.855 X-Spam-Level: X-Spam-Status: No, score=-0.855 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NUMERIC_HTTP_ADDR=1.242, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 DT0KfOG2lslh; Tue, 5 May 2020 07:05:34 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 D9E633A0823; Tue, 5 May 2020 07:05:26 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id w4so2047482ioc.6; Tue, 05 May 2020 07:05:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6zRQMRc8CgXesC9O9wWvU0HLlPRIgi/pRiTMRkpVnVw=; b=had6jLm3xhXuThlhYlSdHdmdRl4YsQYPtOZjVYIwmKnFyG7sd5q8V74Uk0YDR0E9pn CBaSF5GRN7jB5j8Gnq2Q1JUwXu/rMMjRBzmBnkCVMpPy/ZHOr6oVV3M2BsIf07bnL3O8 4K+v56QB+OtWuYcH+C0VoVNlWNZNGlmllQftYxHO1w7HSyUXTsMUA1LAotWRkecpuJi0 dlGqgx6nFNYDVqthV+x8+Um2ruLfCGAIiqbijNlONlINxESe3Gt+mt5GYDdY4oxbctGT PNWX+dVxhP0sYsXRw4seqyOrVmHKeHQ/nwlzOyVeoyMpCUpHbLiqLNXLPUsmbTblTm/R 6WyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6zRQMRc8CgXesC9O9wWvU0HLlPRIgi/pRiTMRkpVnVw=; b=iB1uqxgSjSfOMO/mnYbt+ndwnjhwzr5yal/t8jsiNQLKNqn2TpK0lymmcWSZ5Y215Z fLzQG5u/Gn3TbPAuTYGy2PVnuKrDAOSZTW/tBy9q/mZTVSDRUVM9F+jt7B8EhNNRhK8Q JJE8DZoGXcJ8nActPrvG0hmIO+nnQo4g7A497rx4Ox0ggLlC8XFkcvswKoHlizVs0EKQ nxZDaIb3skbd3QCNgHrHpXnWkdydglCMXkquau3EnwuQ+iVsoqlRM3zop0uMWz+gCp4j elVpaKXLbGg1McNmw5lYWBTf8TbBXTsW8ICrH6vqZFDeL0u6zvLrz7b6ZE/Q3DpU3nTA VYOg== X-Gm-Message-State: AGi0Puaks2iHA6exwpN6LMTaxzp8U8u/A6wnDBkcpN2UIMx17yJcBGNV LpDvlqSeZqEsp5tSlK0G9BmmVog7WTHcZ7YItLI= X-Google-Smtp-Source: APiQypLmX4GUvdFlsfa8M9Rgp7gt3x4BPy+gkw0oApJp7udwD270lpRUFRL9mpNURikIE3czDpQnfMuVHBmYQea2YkQ= X-Received: by 2002:a05:6602:15ca:: with SMTP id f10mr3446241iow.51.1588687524634; Tue, 05 May 2020 07:05:24 -0700 (PDT) MIME-Version: 1.0 References: <469529BD-F254-4B45-9000-E1F5B8463A08@ericsson.com> <650304eeff354140bdfe6e7dd20fa4b8@cert.org> In-Reply-To: <650304eeff354140bdfe6e7dd20fa4b8@cert.org> From: Rifaat Shekh-Yusef Date: Tue, 5 May 2020 10:05:12 -0400 Message-ID: To: Roman Danyliw Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Content-Type: multipart/alternative; boundary="00000000000090a60805a4e723d0" Archived-At: Subject: Re: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 14:05:39 -0000 --00000000000090a60805a4e723d0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Roman! On Tue, May 5, 2020 at 9:15 AM Roman Danyliw wrote: > Hi Rifaat and Christer! > > > > Thanks for the updates made in -14 and -15. They address both my DISCUSS > and COMMENT items. I=E2=80=99ve cleared my ballot. > > > > Regards, > > Roman > > > > *From:* Rifaat Shekh-Yusef > *Sent:* Wednesday, April 22, 2020 1:58 PM > *To:* Christer Holmberg > *Cc:* Roman Danyliw ; The IESG ; > draft-ietf-sipcore-sip-token-authnz@ietf.org; sipcore-chairs@ietf.org; > sipcore@ietf.org; Jean Mahoney > *Subject:* Re: Roman Danyliw's Discuss on > draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMM= ENT > > > > Hi Roman, > > > > Thanks for the review! > > > > Regarding the DISCUSS: > > > > Section 2.1.1, 3rd paragraph, last sentence, has a bit more about the > usage of the ID Token. How about extending that as follows: > > An OpenID Connect server returns an additional ID Token that contains > claims about > > the authentication of the user by an Authorization Server. The ID Token > can potentially > > include other optional claims about the user, e.g. the SIP URI, that will > be consumed by > > the UAC and later used to register with the SIP Registrar. > > > > More inline regarding some of the comments. > > > > Regards, > > Rifaat > > > > > > > > On Wed, Apr 22, 2020 at 12:28 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > HI Roman, > > Thank You for the review! In this reply I will address most of your > COMMENT issues. The DISCUSS issue, and a couple of COMMENT issues, will b= e > addressed in a separate reply. > > ---------------------------------------------------------------------= - > COMMENT: > ---------------------------------------------------------------------= - > > >** Section 1.3. Per =E2=80=9CAccess Tokens could be represented in = one of > the above > >two formats.=E2=80=9D, if not one of these two formats, then which o= ther ones? > > I suggest to change "could" to "can". > > > > How about replacing "could be" with "are"? > > > > > --- > > > ** Section 2.1.1. Per =E2=80=9CAn OpenID Connect server =E2=80=A6= =E2=80=9D, based on the > flows > > depicted in Figure 1 and 2, how the OpenID Connect server fits isn= =E2=80=99t > clear. > > We will address this in the reply that addresses the DISCUSS, as the > issues are related. > > The AS could be a typical OAuth Authorization Server or an OpenID Provide= r > (OP). > Would changing the "AS" column in the figures to "AS/OP" help? > > > > > > --- > > > ** Section 2.1.2. Per =E2=80=9CEndpoints that support this specifi= cation > MUST support > > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding and > protecting access > > tokens when they are included in SIP requests, unless some other > mechanism is > > used to guarantee that only authorized SIP endpoints have access to > the access > > token.=E2=80=9D -- is it the =E2=80=9Cuse of=E2=80=9D or =E2=80=9Cs= upport for=E2=80=9D JWT that is required > if there > > isn=E2=80=99t an alternative? Section 5 uses similar language. > > "MUST use" is more correct. > > --- > > > ** Section 2.1.3. Per =E2=80=9CNote that, if there were multiple c= hallenges > with > > different schemes, then the UAC may be able to successfully retry > the request > > using non-Bearer credentials.=E2=80=9D, would that decision be made= based on > local > > policy? > > Yes. That is described in Section 2.1.1.: > > "If the UAC receives a 401/407 response with multiple WWW- > Authenticate/Proxy-Authenticate header fields, providing challenges > using different authentication schemes for the same realm, the UAC > selects one or more of the provided schemes (based on local policy) > and provides credentials for those schemes." > > --- > > > ** Section 5. Should the use of the scope parameter be noted (or > RECOMMENDED) > > to narrow the utility of the token? > > I will refer this to Rifaat. > > > > How about adding the following sentence to this section: > > > > The SIP Registrar SHOULD include a Scope parameter to control the minimum > level of service access > > the client is required to obtain from the Authorization Server to be able > to register with the SIP Registrar. > > > > Regards, > > Rifaat > > > > > > --- > > > ** Editorial Nits: > > Section 1.3. Typo. s/usualy/usually/ > > Will fix. > > > Section 7. Typo. s/coversion/conversion/ > > Will fix. > > --- > > Regards, > > Christer > > > --00000000000090a60805a4e723d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Roman!


On Tue, May 5, 2020 at 9:15 AM= Roman Danyliw <rdd@cert.org> wro= te:

Hi Rifaat and Christer!

=C2=A0

Thanks for the updates made in -14 and -15.=C2=A0 Th= ey address both my DISCUSS and COMMENT items.=C2=A0 I=E2=80=99ve cleared my= ballot.

=C2=A0

Regards,

Roman

=C2=A0

From: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com> Sent: Wednesday, April 22, 2020 1:58 PM
To: Christer Holmberg <christer.holmberg@ericsson.com>
Cc: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>; draft-ietf-sipcore-sip-token-a= uthnz@ietf.org; sipcore-chairs@ietf.org; sipcore@ietf.org; Jean Mahoney <mahoney@nostrum.com>
Subject: Re: Roman Danyliw's Discuss on draft-ietf-sipcore-sip-t= oken-authnz-13: (with DISCUSS and COMMENT) - COMMENT

=C2=A0

Hi Roman,

=C2=A0

Thanks for the review!

=C2=A0

Regarding the DISCUSS:

=C2=A0

Section 2.1.1, 3rd para= graph, last sentence, has a bit more about the usage of the ID Token. How a= bout extending that as follows:

An OpenID Connect server returns an additional ID To= ken that contains claims about

the authentication of the user by an Authorization S= erver. The ID Token can potentially

include other optional claims about the user, e.g. t= he SIP URI, that will be consumed by

the UAC and later used to register with the SIP Regi= strar.

=C2=A0

More inline regarding some of the comments.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

=C2=A0

On Wed, Apr 22, 2020 at 12:28 PM Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com> wrote:

HI Roman,

Thank You for the review! In this reply I will address most of your COMMENT= issues. The DISCUSS issue, and a couple of COMMENT issues, will be address= ed in a separate reply.

=C2=A0 =C2=A0 -------------------------------------------------------------= ---------
=C2=A0 =C2=A0 COMMENT:
=C2=A0 =C2=A0 -------------------------------------------------------------= ---------

=C2=A0 =C2=A0 >** Section 1.3.=C2=A0 Per =E2=80=9CAccess Tokens could be= represented in one of the above
=C2=A0 =C2=A0 >two formats.=E2=80=9D, if not one of these two formats, t= hen which other ones?

=C2=A0 =C2=A0 I suggest to change "could" to "can".<= /u>

=C2=A0

How about replacing "could be" with "= are"?=C2=A0

=C2=A0


---

=C2=A0 =C2=A0 > ** Section 2.1.1.=C2=A0 Per =E2=80=9CAn OpenID Connect s= erver =E2=80=A6=E2=80=9D, based on the flows
=C2=A0 =C2=A0 > depicted in Figure 1 and 2, how the OpenID Connect serve= r fits isn=E2=80=99t clear.

We will address this in the reply that addresses the DISCUSS, as the issues= are related.

The AS could be a typical OAuth Authorization Server= or an OpenID Provider (OP).
Would changing the "AS" column in the figures to "AS/OP"= ; help?

=C2=A0

=C2=A0

---

=C2=A0 =C2=A0 > ** Section 2.1.2.=C2=A0 Per =E2=80=9CEndpoints that supp= ort this specification MUST support
=C2=A0 =C2=A0 > encrypted JSON Web Tokens (JWT) [RFC7519] for encoding a= nd protecting access
=C2=A0 =C2=A0 > tokens when they are included in SIP requests, unless so= me other mechanism is
=C2=A0 =C2=A0 > used to guarantee that only authorized SIP endpoints hav= e access to the access
=C2=A0 =C2=A0 > token.=E2=80=9D -- is it the =E2=80=9Cuse of=E2=80=9D or= =E2=80=9Csupport for=E2=80=9D JWT that is required if there
=C2=A0 =C2=A0 > isn=E2=80=99t an alternative?=C2=A0 Section 5 uses simil= ar language.

"MUST use" is more correct.

---

=C2=A0 =C2=A0 > ** Section 2.1.3.=C2=A0 Per =E2=80=9CNote that, if there= were multiple challenges with
=C2=A0 =C2=A0 > different schemes, then the UAC may be able to successfu= lly retry the request
=C2=A0 =C2=A0 > using non-Bearer credentials.=E2=80=9D, would that decis= ion be made based on local
=C2=A0 =C2=A0 > policy?

Yes. That is described in Section 2.1.1.:

=C2=A0 =C2=A0"If the UAC receives a 401/407 response with multiple WWW= -
=C2=A0 =C2=A0Authenticate/Proxy-Authenticate header fields, providing chall= enges
=C2=A0 =C2=A0using different authentication schemes for the same realm, the= UAC
=C2=A0 =C2=A0selects one or more of the provided schemes (based on local po= licy)
=C2=A0 =C2=A0and provides credentials for those schemes."

---

=C2=A0 =C2=A0 > ** Section 5.=C2=A0 Should the use of the scope paramete= r be noted (or RECOMMENDED)
=C2=A0 =C2=A0 > to narrow the utility of the token?

=C2=A0 =C2=A0 I will refer this to Rifaat.

=C2=A0

How about adding the following sentence to this sect= ion:

=C2=A0

The SIP Registrar SHOULD include a Scope parameter t= o control the minimum level of service access=C2=A0

the client is required to obtain from the Authorizat= ion Server to be able to register with the SIP Registrar.

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

=C2=A0

---

=C2=A0 =C2=A0 > ** Editorial Nits:
=C2=A0 =C2=A0 > Section 1.3.=C2=A0 Typo. s/usualy/usually/

=C2=A0 =C2=A0 Will fix.

=C2=A0 =C2=A0 > Section 7.=C2=A0 Typo.=C2=A0 s/coversion/conversion/

=C2=A0 =C2=A0 Will fix.

---

Regards,

Christer


--00000000000090a60805a4e723d0-- From nobody Tue May 5 08:48:18 2020 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 2208A3A0912; Tue, 5 May 2020 08:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 nqoGD2O57Dak; Tue, 5 May 2020 08:47:46 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2066.outbound.protection.outlook.com [40.107.22.66]) (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 0181D3A0911; Tue, 5 May 2020 08:47:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YHAeOhrHu5OYx+93mb6hB8URTGGFSvfx7nwlxtYoyZCKO+VUDf4Q7NpPzYZExTOP+3bhKJjJ8ZuQkXmub4KE1w5gXIXZ0uvTt2BRw1Flj8T6bb1MLjAyChKEprSL2Yse1qkcjAXrou3HymiPAMfk4rW/ky4FSt75GbW9QeckM1YSDRqEdiHqv2byg46pQdf0u088pYRaiALghpwmZon3Ks+k/OSvSyPEL5qJUvE7B5kJMcoboRgAgW25IyXs+VG8VNhRAZZco9sDQ/L7x0b9XjATRdHPXHFVMsy7qHv6gKUgRfHnYQKquc8L/Gn27JqnQYRBJ9136v5ZEveJ/ZYB5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ASrY+Hx+mlCMlVaj27eZoTYj7HXnc8Uhmiu/lb6PMC4=; b=UKKc4lgEZMyuW4XUJHLXRMJpcl2IKrfzdrPY+q/Jm7rDqMOk9tLN/AblIxMMSkcERDm+Se+jFw4RdITI/juZ3AZD60bVTmBPSB1LpvtOsby8UsgPa67wFQJXefs//C0LFJ5ZSNNdifV7fLql7ePu3+EhPAHnBvmFlGRmNGDxRWhkGgZqEOQ4UgW9LyDH7x5mlKww3azFt5dnUnu3j5dRhXjOBs3kWbfsWteo71FKOU3lTgyHUiU0j5B/PDTKk370FYT9BXoMwELmMnDmEfGEwyBkSgqjlWbp1TX77y4JdxTK6f8M+6TdCROmmZAftRJDZj5HSgVX+YTiKSeu2hAXMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ASrY+Hx+mlCMlVaj27eZoTYj7HXnc8Uhmiu/lb6PMC4=; b=JAYsMQ/eVlPZMMVCUuXLal+aB9CT+mn3YtSWnzQlifoebOhl+nI17z1ijNb+Hs8IZbDjDeaGUAAT/NOFUnnG4oo4/DhlMGLK+se26X1J03SYcBQhbtHLF8wrGHY7gxDnORiGcva+Upwx7HW+YEvIK4OZWgmatqiEo7Ru/l4jr+c= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6578.eurprd07.prod.outlook.com (2603:10a6:20b:1a1::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.16; Tue, 5 May 2020 15:47:43 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2979.025; Tue, 5 May 2020 15:47:43 +0000 From: Christer Holmberg To: Roman Danyliw , Rifaat Shekh-Yusef CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT Thread-Index: AQHWGMMOtxZIT3jHHk6raCfflxfIDqiFbaIAgBQfPoCAAFzrgA== Date: Tue, 5 May 2020 15:47:43 +0000 Message-ID: <62091570-02AF-4DEC-AACB-3EC46D70B83E@ericsson.com> References: <469529BD-F254-4B45-9000-E1F5B8463A08@ericsson.com> <650304eeff354140bdfe6e7dd20fa4b8@cert.org> In-Reply-To: <650304eeff354140bdfe6e7dd20fa4b8@cert.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: cert.org; dkim=none (message not signed) header.d=none;cert.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.216.230.200] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9782fcb6-fb59-456f-ea08-08d7f10ba686 x-ms-traffictypediagnostic: AM7PR07MB6578: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ui2StokCRlGGTvSIv23pTNvoGuyoar6O69hq+1Egd/7tnju888qCMJuN7AsGXtp2oPTyIkZlqJvS9h+L8JJ1fptl3Yzq4gdpu0c5VqsRncSirSmgZmWvtThuocAC8OfQwhUpxH4lOPNxfAXg2C4VTJyiWhaDlkNX18RvTC1hNGPh/CZfBn/hlfo1516kC54Zi4sLxoTRrzbb2f/t0XjYTmqAreGXX5ikVQFoebswlGPZJlREaKj4SJbQoUGT1sqgxFAGq+n/01ZfDzkzFAxUmBjH5aD7drzBiThRxqA2kYkvbzH8X2R69jAolQpnZ181+RbaG3GeQqgphRMUwhtDnSy3a42PAFjyoJ1MrMfmRvInzFvnPbMZ0nDAMHFPlQTBvWke9I8mqqMvaPYJF27WD8eLNpg+ThNDVJItjA5m4ZNDFqx7wEWvVVZLyVMeqD6SQ9RT44xnW1BxLoNOhtWjCYlxtTv4tIP5VpAFnT0XTaLWwKYnvr/XRPBcBiZKQx0caTEs9DS5ZK4bXFMlBJ8Ajk+1M1KYGJtKt632mszNN3/xhr7iKHkR1teVyXjXWEt+soS7CWy6++odh0FDF0MY9hvVymwBIG2dL6KeJEAYz1c= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(346002)(376002)(396003)(33430700001)(71200400001)(6506007)(53546011)(8676002)(36756003)(33440700001)(4326008)(8936002)(66946007)(76116006)(478600001)(66476007)(66556008)(91956017)(86362001)(6512007)(186003)(5660300002)(6486002)(33656002)(64756008)(66446008)(2616005)(44832011)(110136005)(83080400001)(316002)(2906002)(26005)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /OpXIx8JM27IozpPrPS+SJleZ9MxVqNAUsA9whzsMKv867UtoynWaH4aDGVMOnp+7rcik5LDS/ZdXblXxdTQM9Ufr2+NR+BdisTNa9i5ytoDRNO6cGe7ro1jBL7e/kj3ZMap3POHFRsbTm5vvVHHEl+cI5jo2U/V8mozLpTM0EyYQftyaZhaQkDw69a9ScNf3NNumAX2IdsZDvA/Hs8dLWflKjAm06znyAYfZgBnBE6ZyPm94oYXNd/BPYLUnFpukzc6xHHkuIsyX+BVOOWsaE7i1DEwKZFPSlKkJ3PUDkhBJyQb4+4iS2172LO46PikIhXbUIPt386o7dH2vsypk9s9nYs04w6KVMgias+txtUBKIMEijM/p9L9D5x/PgZ9JK7sNqP0xcJpFa14Qwqe2Ro4XUorPqGlPikwlx+g6FNdwYHtzTWhZodmkxzBG0VsQfE1QGIlgzjJ6VVYPCjhkAKFoTgvTXaw7U1crZw9owJkzEjMDIroGEpMWnKk4tGqGxatGT5kpKZpLx+56Ju3rj+KcviCDIf2hSo8qfIzkZiO0xpCfyH6otjUyd+cdh0bavPynf7oJKkrdU4y81UA5dU9rRNJc9WER3cSICVg3AY/aNLgsQbA5ZE6DIKgFDM3HbC57UI1CH4gOTmaNK4+8ZIziP7vDJ5FpfwoYmOB5OGvkWKOrtt/jj1JLlnxMDUV3jjV6d9xCgtY1MOs+q6FYAoRP0h/gJPdcj8TChjpZiH9rSCMjcc7LY24n/0pBXhgqUEIfZPQI584DbZIyZFg2EUzlpu17qTi9JEeEXO+BS/AmW72Djd0Sz8dWHnSrCkt x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_6209157002AF4DECAACB3EC46D70B83Eericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9782fcb6-fb59-456f-ea08-08d7f10ba686 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 15:47:43.5933 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3rGjlpnjKRXC/14bQACWOvtz6yrIVR3HQiDgVit30zmXiAHQTKu3CQ/zd5aYQUWP7I7hCIqXHdPZLYL2+SSvDu7hmFvhHukVLpd83ZOYdH0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6578 Archived-At: Subject: Re: [sipcore] Roman Danyliw's Discuss on draft-ietf-sipcore-sip-token-authnz-13: (with DISCUSS and COMMENT) - COMMENT X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 15:47:50 -0000 --_000_6209157002AF4DECAACB3EC46D70B83Eericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgWW91LCBSb21hbiEgOikNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KRnJvbTogUm9t YW4gRGFueWxpdyA8cmRkQGNlcnQub3JnPg0KRGF0ZTogVHVlc2RheSwgNSBNYXkgMjAyMCBhdCAx Ni4xNQ0KVG86IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPiwgQ2hy aXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4NCkNjOiAiaWVz Z0BpZXRmLm9yZyIgPGllc2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tl bi1hdXRobnpAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuekBp ZXRmLm9yZz4sICJzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZyIgPHNpcGNvcmUtY2hhaXJzQGlldGYu b3JnPiwgInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYub3JnPiwgIkEuIE1haG9uZXki IDxtYWhvbmV5QG5vc3RydW0uY29tPg0KU3ViamVjdDogUkU6IFJvbWFuIERhbnlsaXcncyBEaXNj dXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTEzOiAod2l0aCBESVND VVNTIGFuZCBDT01NRU5UKSAtIENPTU1FTlQNCg0KSGkgUmlmYWF0IGFuZCBDaHJpc3RlciENCg0K VGhhbmtzIGZvciB0aGUgdXBkYXRlcyBtYWRlIGluIC0xNCBhbmQgLTE1LiAgVGhleSBhZGRyZXNz IGJvdGggbXkgRElTQ1VTUyBhbmQgQ09NTUVOVCBpdGVtcy4gIEnigJl2ZSBjbGVhcmVkIG15IGJh bGxvdC4NCg0KUmVnYXJkcywNClJvbWFuDQoNCkZyb206IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlm YWF0LmlldGZAZ21haWwuY29tPg0KU2VudDogV2VkbmVzZGF5LCBBcHJpbCAyMiwgMjAyMCAxOjU4 IFBNDQpUbzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNv bT4NCkNjOiBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+OyBUaGUgSUVTRyA8aWVzZ0BpZXRm Lm9yZz47IGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56QGlldGYub3JnOyBzaXBj b3JlLWNoYWlyc0BpZXRmLm9yZzsgc2lwY29yZUBpZXRmLm9yZzsgSmVhbiBNYWhvbmV5IDxtYWhv bmV5QG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNzIG9u IGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTEzOiAod2l0aCBESVNDVVNTIGFu ZCBDT01NRU5UKSAtIENPTU1FTlQNCg0KSGkgUm9tYW4sDQoNClRoYW5rcyBmb3IgdGhlIHJldmll dyENCg0KUmVnYXJkaW5nIHRoZSBESVNDVVNTOg0KDQpTZWN0aW9uIDIuMS4xLCAzcmQgcGFyYWdy YXBoLCBsYXN0IHNlbnRlbmNlLCBoYXMgYSBiaXQgbW9yZSBhYm91dCB0aGUgdXNhZ2Ugb2YgdGhl IElEIFRva2VuLiBIb3cgYWJvdXQgZXh0ZW5kaW5nIHRoYXQgYXMgZm9sbG93czoNCkFuIE9wZW5J RCBDb25uZWN0IHNlcnZlciByZXR1cm5zIGFuIGFkZGl0aW9uYWwgSUQgVG9rZW4gdGhhdCBjb250 YWlucyBjbGFpbXMgYWJvdXQNCnRoZSBhdXRoZW50aWNhdGlvbiBvZiB0aGUgdXNlciBieSBhbiBB dXRob3JpemF0aW9uIFNlcnZlci4gVGhlIElEIFRva2VuIGNhbiBwb3RlbnRpYWxseQ0KaW5jbHVk ZSBvdGhlciBvcHRpb25hbCBjbGFpbXMgYWJvdXQgdGhlIHVzZXIsIGUuZy4gdGhlIFNJUCBVUkks IHRoYXQgd2lsbCBiZSBjb25zdW1lZCBieQ0KdGhlIFVBQyBhbmQgbGF0ZXIgdXNlZCB0byByZWdp c3RlciB3aXRoIHRoZSBTSVAgUmVnaXN0cmFyLg0KDQpNb3JlIGlubGluZSByZWdhcmRpbmcgc29t ZSBvZiB0aGUgY29tbWVudHMuDQoNClJlZ2FyZHMsDQogUmlmYWF0DQoNCg0KDQpPbiBXZWQsIEFw ciAyMiwgMjAyMCBhdCAxMjoyOCBQTSBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJl cmdAZXJpY3Nzb24uY29tPG1haWx0bzpjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20+PiB3 cm90ZToNCkhJIFJvbWFuLA0KDQpUaGFuayBZb3UgZm9yIHRoZSByZXZpZXchIEluIHRoaXMgcmVw bHkgSSB3aWxsIGFkZHJlc3MgbW9zdCBvZiB5b3VyIENPTU1FTlQgaXNzdWVzLiBUaGUgRElTQ1VT UyBpc3N1ZSwgYW5kIGEgY291cGxlIG9mIENPTU1FTlQgaXNzdWVzLCB3aWxsIGJlIGFkZHJlc3Nl ZCBpbiBhIHNlcGFyYXRlIHJlcGx5Lg0KDQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIENPTU1FTlQ6 DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQogICAgPioqIFNlY3Rpb24gMS4zLiAgUGVyIOKAnEFjY2Vz cyBUb2tlbnMgY291bGQgYmUgcmVwcmVzZW50ZWQgaW4gb25lIG9mIHRoZSBhYm92ZQ0KICAgID50 d28gZm9ybWF0cy7igJ0sIGlmIG5vdCBvbmUgb2YgdGhlc2UgdHdvIGZvcm1hdHMsIHRoZW4gd2hp Y2ggb3RoZXIgb25lcz8NCg0KICAgIEkgc3VnZ2VzdCB0byBjaGFuZ2UgImNvdWxkIiB0byAiY2Fu Ii4NCg0KSG93IGFib3V0IHJlcGxhY2luZyAiY291bGQgYmUiIHdpdGggImFyZSI/DQoNCg0KLS0t DQoNCiAgICA+ICoqIFNlY3Rpb24gMi4xLjEuICBQZXIg4oCcQW4gT3BlbklEIENvbm5lY3Qgc2Vy dmVyIOKApuKAnSwgYmFzZWQgb24gdGhlIGZsb3dzDQogICAgPiBkZXBpY3RlZCBpbiBGaWd1cmUg MSBhbmQgMiwgaG93IHRoZSBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXIgZml0cyBpc27igJl0IGNsZWFy Lg0KDQpXZSB3aWxsIGFkZHJlc3MgdGhpcyBpbiB0aGUgcmVwbHkgdGhhdCBhZGRyZXNzZXMgdGhl IERJU0NVU1MsIGFzIHRoZSBpc3N1ZXMgYXJlIHJlbGF0ZWQuDQpUaGUgQVMgY291bGQgYmUgYSB0 eXBpY2FsIE9BdXRoIEF1dGhvcml6YXRpb24gU2VydmVyIG9yIGFuIE9wZW5JRCBQcm92aWRlciAo T1ApLg0KV291bGQgY2hhbmdpbmcgdGhlICJBUyIgY29sdW1uIGluIHRoZSBmaWd1cmVzIHRvICJB Uy9PUCIgaGVscD8NCg0KDQotLS0NCg0KICAgID4gKiogU2VjdGlvbiAyLjEuMi4gIFBlciDigJxF bmRwb2ludHMgdGhhdCBzdXBwb3J0IHRoaXMgc3BlY2lmaWNhdGlvbiBNVVNUIHN1cHBvcnQNCiAg ICA+IGVuY3J5cHRlZCBKU09OIFdlYiBUb2tlbnMgKEpXVCkgW1JGQzc1MTldIGZvciBlbmNvZGlu ZyBhbmQgcHJvdGVjdGluZyBhY2Nlc3MNCiAgICA+IHRva2VucyB3aGVuIHRoZXkgYXJlIGluY2x1 ZGVkIGluIFNJUCByZXF1ZXN0cywgdW5sZXNzIHNvbWUgb3RoZXIgbWVjaGFuaXNtIGlzDQogICAg PiB1c2VkIHRvIGd1YXJhbnRlZSB0aGF0IG9ubHkgYXV0aG9yaXplZCBTSVAgZW5kcG9pbnRzIGhh dmUgYWNjZXNzIHRvIHRoZSBhY2Nlc3MNCiAgICA+IHRva2VuLuKAnSAtLSBpcyBpdCB0aGUg4oCc dXNlIG9m4oCdIG9yIOKAnHN1cHBvcnQgZm9y4oCdIEpXVCB0aGF0IGlzIHJlcXVpcmVkIGlmIHRo ZXJlDQogICAgPiBpc27igJl0IGFuIGFsdGVybmF0aXZlPyAgU2VjdGlvbiA1IHVzZXMgc2ltaWxh ciBsYW5ndWFnZS4NCg0KIk1VU1QgdXNlIiBpcyBtb3JlIGNvcnJlY3QuDQoNCi0tLQ0KDQogICAg PiAqKiBTZWN0aW9uIDIuMS4zLiAgUGVyIOKAnE5vdGUgdGhhdCwgaWYgdGhlcmUgd2VyZSBtdWx0 aXBsZSBjaGFsbGVuZ2VzIHdpdGgNCiAgICA+IGRpZmZlcmVudCBzY2hlbWVzLCB0aGVuIHRoZSBV QUMgbWF5IGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHJldHJ5IHRoZSByZXF1ZXN0DQogICAgPiB1 c2luZyBub24tQmVhcmVyIGNyZWRlbnRpYWxzLuKAnSwgd291bGQgdGhhdCBkZWNpc2lvbiBiZSBt YWRlIGJhc2VkIG9uIGxvY2FsDQogICAgPiBwb2xpY3k/DQoNClllcy4gVGhhdCBpcyBkZXNjcmli ZWQgaW4gU2VjdGlvbiAyLjEuMS48aHR0cHM6Ly9wcm90ZWN0Mi5maXJlZXllLmNvbS92MS91cmw/ az04ODYzOGY0MS1kNmMzMzUyZi04ODYzY2ZkYS04NjlhMTRmNGIwOGMtYjVjZjk5NTYyZGM4ZjZl YyZxPTEmZT04YTEzYTgyZi03YWI1LTQ1OTEtYmZiZC05MDQ4NzJkZmQ2YzUmdT1odHRwJTNBJTJG JTJGMi4xLjAuMSUyRj46DQoNCiAgICJJZiB0aGUgVUFDIHJlY2VpdmVzIGEgNDAxLzQwNyByZXNw b25zZSB3aXRoIG11bHRpcGxlIFdXVy0NCiAgIEF1dGhlbnRpY2F0ZS9Qcm94eS1BdXRoZW50aWNh dGUgaGVhZGVyIGZpZWxkcywgcHJvdmlkaW5nIGNoYWxsZW5nZXMNCiAgIHVzaW5nIGRpZmZlcmVu dCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGZvciB0aGUgc2FtZSByZWFsbSwgdGhlIFVBQw0KICAg c2VsZWN0cyBvbmUgb3IgbW9yZSBvZiB0aGUgcHJvdmlkZWQgc2NoZW1lcyAoYmFzZWQgb24gbG9j YWwgcG9saWN5KQ0KICAgYW5kIHByb3ZpZGVzIGNyZWRlbnRpYWxzIGZvciB0aG9zZSBzY2hlbWVz LiINCg0KLS0tDQoNCiAgICA+ICoqIFNlY3Rpb24gNS4gIFNob3VsZCB0aGUgdXNlIG9mIHRoZSBz Y29wZSBwYXJhbWV0ZXIgYmUgbm90ZWQgKG9yIFJFQ09NTUVOREVEKQ0KICAgID4gdG8gbmFycm93 IHRoZSB1dGlsaXR5IG9mIHRoZSB0b2tlbj8NCg0KICAgIEkgd2lsbCByZWZlciB0aGlzIHRvIFJp ZmFhdC4NCg0KSG93IGFib3V0IGFkZGluZyB0aGUgZm9sbG93aW5nIHNlbnRlbmNlIHRvIHRoaXMg c2VjdGlvbjoNCg0KVGhlIFNJUCBSZWdpc3RyYXIgU0hPVUxEIGluY2x1ZGUgYSBTY29wZSBwYXJh bWV0ZXIgdG8gY29udHJvbCB0aGUgbWluaW11bSBsZXZlbCBvZiBzZXJ2aWNlIGFjY2Vzcw0KdGhl IGNsaWVudCBpcyByZXF1aXJlZCB0byBvYnRhaW4gZnJvbSB0aGUgQXV0aG9yaXphdGlvbiBTZXJ2 ZXIgdG8gYmUgYWJsZSB0byByZWdpc3RlciB3aXRoIHRoZSBTSVAgUmVnaXN0cmFyLg0KDQpSZWdh cmRzLA0KIFJpZmFhdA0KDQoNCi0tLQ0KDQogICAgPiAqKiBFZGl0b3JpYWwgTml0czoNCiAgICA+ IFNlY3Rpb24gMS4zLiAgVHlwby4gcy91c3VhbHkvdXN1YWxseS8NCg0KICAgIFdpbGwgZml4Lg0K DQogICAgPiBTZWN0aW9uIDcuICBUeXBvLiAgcy9jb3ZlcnNpb24vY29udmVyc2lvbi8NCg0KICAg IFdpbGwgZml4Lg0KDQotLS0NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCg== --_000_6209157002AF4DECAACB3EC46D70B83Eericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUx OQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhhbmsgWW91LCBS b21hbiEgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Sb21hbiBEYW55bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7 PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDUgTWF5IDIwMjAgYXQgMTYuMTU8YnI+DQo8Yj5U bzogPC9iPlJpZmFhdCBTaGVraC1ZdXNlZiAmbHQ7cmlmYWF0LmlldGZAZ21haWwuY29tJmd0Oywg Q2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbSZndDs8 YnI+DQo8Yj5DYzogPC9iPiZxdW90O2llc2dAaWV0Zi5vcmcmcXVvdDsgJmx0O2llc2dAaWV0Zi5v cmcmZ3Q7LCAmcXVvdDtkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuekBpZXRmLm9y ZyZxdW90OyAmbHQ7ZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnpAaWV0Zi5vcmcm Z3Q7LCAmcXVvdDtzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAmbHQ7c2lwY29yZS1jaGFp cnNAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3Jl QGlldGYub3JnJmd0OywgJnF1b3Q7QS4gTWFob25leSZxdW90OyAmbHQ7bWFob25leUBub3N0cnVt LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFJvbWFuIERhbnlsaXcncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTEzOiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKSAtIENPTU1FTlQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUmlmYWF0IGFuZCBDaHJpc3RlciE8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgdXBkYXRlcyBtYWRlIGluIC0xNCBhbmQgLTE1LiZu YnNwOyBUaGV5IGFkZHJlc3MgYm90aCBteSBESVNDVVNTIGFuZCBDT01NRU5UIGl0ZW1zLiZuYnNw OyBJ4oCZdmUgY2xlYXJlZCBteSBiYWxsb3QuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb21hbjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQu aWV0ZkBnbWFpbC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEFwcmlsIDIy LCAyMDIwIDE6NTggUE08YnI+DQo8Yj5Ubzo8L2I+IENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJp c3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBSb21hbiBEYW55 bGl3ICZsdDtyZGRAY2VydC5vcmcmZ3Q7OyBUaGUgSUVTRyAmbHQ7aWVzZ0BpZXRmLm9yZyZndDs7 IGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56QGlldGYub3JnOyBzaXBjb3JlLWNo YWlyc0BpZXRmLm9yZzsgc2lwY29yZUBpZXRmLm9yZzsgSmVhbiBNYWhvbmV5ICZsdDttYWhvbmV5 QG5vc3RydW0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogUm9tYW4gRGFueWxpdydz IERpc2N1c3Mgb24gZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnotMTM6ICh3aXRo IERJU0NVU1MgYW5kIENPTU1FTlQpIC0gQ09NTUVOVDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkhpIFJvbWFuLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIGZvciB0aGUgcmV2aWV3ITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgdGhlIERJU0NVU1M6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U2VjdGlvbiAyLjEuMSwgM3JkIHBhcmFncmFwaCwgbGFz dCBzZW50ZW5jZSwgaGFzIGEgYml0IG1vcmUgYWJvdXQgdGhlIHVzYWdlIG9mIHRoZSBJRCBUb2tl bi4gSG93IGFib3V0IGV4dGVuZGluZyB0aGF0IGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0OjMwLjBwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuIE9wZW5JRCBDb25uZWN0IHNlcnZlciBy ZXR1cm5zIGFuIGFkZGl0aW9uYWwgSUQgVG9rZW4gdGhhdCBjb250YWlucyBjbGFpbXMgYWJvdXQN CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dGhlIGF1dGhlbnRpY2F0aW9uIG9mIHRoZSB1c2VyIGJ5IGFuIEF1dGhvcml6 YXRpb24gU2VydmVyLiBUaGUgSUQgVG9rZW4gY2FuIHBvdGVudGlhbGx5DQo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlu Y2x1ZGUgb3RoZXIgb3B0aW9uYWwgY2xhaW1zIGFib3V0IHRoZSB1c2VyLCBlLmcuIHRoZSBTSVAg VVJJLCB0aGF0IHdpbGwgYmUgY29uc3VtZWQgYnkNCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIFVBQyBhbmQgbGF0 ZXIgdXNlZCB0byByZWdpc3RlciB3aXRoIHRoZSBTSVAgUmVnaXN0cmFyLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Nb3JlIGlubGluZSByZWdhcmRpbmcgc29tZSBvZiB0aGUgY29tbWVudHMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJl Z2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDtSaWZhYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk9uIFdlZCwgQXByIDIyLCAyMDIwIGF0IDEyOjI4IFBNIENocmlzdGVy IEhvbG1iZXJnICZsdDs8YSBocmVmPSJtYWlsdG86Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24u Y29tIj5jaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ISSBSb21hbiw8YnI+DQo8YnI+DQpUaGFu ayBZb3UgZm9yIHRoZSByZXZpZXchIEluIHRoaXMgcmVwbHkgSSB3aWxsIGFkZHJlc3MgbW9zdCBv ZiB5b3VyIENPTU1FTlQgaXNzdWVzLiBUaGUgRElTQ1VTUyBpc3N1ZSwgYW5kIGEgY291cGxlIG9m IENPTU1FTlQgaXNzdWVzLCB3aWxsIGJlIGFkZHJlc3NlZCBpbiBhIHNlcGFyYXRlIHJlcGx5Ljxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZuYnNwOyAmbmJzcDsg Q09NTUVOVDo8YnI+DQombmJzcDsgJm5ic3A7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7ICZndDsqKiBTZWN0aW9uIDEuMy4mbmJzcDsgUGVyIOKAnEFjY2VzcyBUb2tlbnMg Y291bGQgYmUgcmVwcmVzZW50ZWQgaW4gb25lIG9mIHRoZSBhYm92ZTxicj4NCiZuYnNwOyAmbmJz cDsgJmd0O3R3byBmb3JtYXRzLuKAnSwgaWYgbm90IG9uZSBvZiB0aGVzZSB0d28gZm9ybWF0cywg dGhlbiB3aGljaCBvdGhlciBvbmVzPzxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgSSBzdWdnZXN0 IHRvIGNoYW5nZSAmcXVvdDtjb3VsZCZxdW90OyB0byAmcXVvdDtjYW4mcXVvdDsuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cg YWJvdXQgcmVwbGFjaW5nICZxdW90O2NvdWxkIGJlJnF1b3Q7IHdpdGggJnF1b3Q7YXJlJnF1b3Q7 PyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6 MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQotLS08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZn dDsgKiogU2VjdGlvbiAyLjEuMS4mbmJzcDsgUGVyIOKAnEFuIE9wZW5JRCBDb25uZWN0IHNlcnZl ciDigKbigJ0sIGJhc2VkIG9uIHRoZSBmbG93czxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBkZXBp Y3RlZCBpbiBGaWd1cmUgMSBhbmQgMiwgaG93IHRoZSBPcGVuSUQgQ29ubmVjdCBzZXJ2ZXIgZml0 cyBpc27igJl0IGNsZWFyLjxicj4NCjxicj4NCldlIHdpbGwgYWRkcmVzcyB0aGlzIGluIHRoZSBy ZXBseSB0aGF0IGFkZHJlc3NlcyB0aGUgRElTQ1VTUywgYXMgdGhlIGlzc3VlcyBhcmUgcmVsYXRl ZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo ZSBBUyBjb3VsZCBiZSBhIHR5cGljYWwgT0F1dGggQXV0aG9yaXphdGlvbiBTZXJ2ZXIgb3IgYW4g T3BlbklEIFByb3ZpZGVyIChPUCkuPGJyPg0KV291bGQgY2hhbmdpbmcgdGhlICZxdW90O0FTJnF1 b3Q7IGNvbHVtbiBpbiB0aGUgZmlndXJlcyB0byAmcXVvdDtBUy9PUCZxdW90OyBoZWxwPzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij4tLS08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgKiogU2VjdGlvbiAyLjEuMi4mbmJz cDsgUGVyIOKAnEVuZHBvaW50cyB0aGF0IHN1cHBvcnQgdGhpcyBzcGVjaWZpY2F0aW9uIE1VU1Qg c3VwcG9ydDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBlbmNyeXB0ZWQgSlNPTiBXZWIgVG9rZW5z IChKV1QpIFtSRkM3NTE5XSBmb3IgZW5jb2RpbmcgYW5kIHByb3RlY3RpbmcgYWNjZXNzPGJyPg0K Jm5ic3A7ICZuYnNwOyAmZ3Q7IHRva2VucyB3aGVuIHRoZXkgYXJlIGluY2x1ZGVkIGluIFNJUCBy ZXF1ZXN0cywgdW5sZXNzIHNvbWUgb3RoZXIgbWVjaGFuaXNtIGlzPGJyPg0KJm5ic3A7ICZuYnNw OyAmZ3Q7IHVzZWQgdG8gZ3VhcmFudGVlIHRoYXQgb25seSBhdXRob3JpemVkIFNJUCBlbmRwb2lu dHMgaGF2ZSBhY2Nlc3MgdG8gdGhlIGFjY2Vzczxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyB0b2tl bi7igJ0gLS0gaXMgaXQgdGhlIOKAnHVzZSBvZuKAnSBvciDigJxzdXBwb3J0IGZvcuKAnSBKV1Qg dGhhdCBpcyByZXF1aXJlZCBpZiB0aGVyZTxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBpc27igJl0 IGFuIGFsdGVybmF0aXZlPyZuYnNwOyBTZWN0aW9uIDUgdXNlcyBzaW1pbGFyIGxhbmd1YWdlLjxi cj4NCjxicj4NCiZxdW90O01VU1QgdXNlJnF1b3Q7IGlzIG1vcmUgY29ycmVjdC48YnI+DQo8YnI+ DQotLS08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgKiogU2VjdGlvbiAyLjEuMy4mbmJz cDsgUGVyIOKAnE5vdGUgdGhhdCwgaWYgdGhlcmUgd2VyZSBtdWx0aXBsZSBjaGFsbGVuZ2VzIHdp dGg8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgZGlmZmVyZW50IHNjaGVtZXMsIHRoZW4gdGhlIFVB QyBtYXkgYmUgYWJsZSB0byBzdWNjZXNzZnVsbHkgcmV0cnkgdGhlIHJlcXVlc3Q8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgdXNpbmcgbm9uLUJlYXJlciBjcmVkZW50aWFscy7igJ0sIHdvdWxkIHRo YXQgZGVjaXNpb24gYmUgbWFkZSBiYXNlZCBvbiBsb2NhbDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0 OyBwb2xpY3k/PGJyPg0KPGJyPg0KWWVzLiBUaGF0IGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDxh IGhyZWY9Imh0dHBzOi8vcHJvdGVjdDIuZmlyZWV5ZS5jb20vdjEvdXJsP2s9ODg2MzhmNDEtZDZj MzM1MmYtODg2M2NmZGEtODY5YTE0ZjRiMDhjLWI1Y2Y5OTU2MmRjOGY2ZWMmYW1wO3E9MSZhbXA7 ZT04YTEzYTgyZi03YWI1LTQ1OTEtYmZiZC05MDQ4NzJkZmQ2YzUmYW1wO3U9aHR0cCUzQSUyRiUy RjIuMS4wLjElMkYiIHRhcmdldD0iX2JsYW5rIj4NCjIuMS4xLjwvYT46PGJyPg0KPGJyPg0KJm5i c3A7ICZuYnNwOyZxdW90O0lmIHRoZSBVQUMgcmVjZWl2ZXMgYSA0MDEvNDA3IHJlc3BvbnNlIHdp dGggbXVsdGlwbGUgV1dXLTxicj4NCiZuYnNwOyAmbmJzcDtBdXRoZW50aWNhdGUvUHJveHktQXV0 aGVudGljYXRlIGhlYWRlciBmaWVsZHMsIHByb3ZpZGluZyBjaGFsbGVuZ2VzPGJyPg0KJm5ic3A7 ICZuYnNwO3VzaW5nIGRpZmZlcmVudCBhdXRoZW50aWNhdGlvbiBzY2hlbWVzIGZvciB0aGUgc2Ft ZSByZWFsbSwgdGhlIFVBQzxicj4NCiZuYnNwOyAmbmJzcDtzZWxlY3RzIG9uZSBvciBtb3JlIG9m IHRoZSBwcm92aWRlZCBzY2hlbWVzIChiYXNlZCBvbiBsb2NhbCBwb2xpY3kpPGJyPg0KJm5ic3A7 ICZuYnNwO2FuZCBwcm92aWRlcyBjcmVkZW50aWFscyBmb3IgdGhvc2Ugc2NoZW1lcy4mcXVvdDs8 YnI+DQo8YnI+DQotLS08YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgKiogU2VjdGlvbiA1 LiZuYnNwOyBTaG91bGQgdGhlIHVzZSBvZiB0aGUgc2NvcGUgcGFyYW1ldGVyIGJlIG5vdGVkIChv ciBSRUNPTU1FTkRFRCk8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgdG8gbmFycm93IHRoZSB1dGls aXR5IG9mIHRoZSB0b2tlbj88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IEkgd2lsbCByZWZlciB0 aGlzIHRvIFJpZmFhdC48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dCBhZGRpbmcgdGhlIGZvbGxvd2luZyBzZW50ZW5j ZSB0byB0aGlzIHNlY3Rpb246PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhlIFNJUCBSZWdpc3RyYXIgU0hPVUxEIGluY2x1ZGUgYSBTY29wZSBwYXJh bWV0ZXIgdG8gY29udHJvbCB0aGUgbWluaW11bSBsZXZlbCBvZiBzZXJ2aWNlIGFjY2VzcyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dGhlIGNsaWVudCBpcyByZXF1aXJlZCB0byBvYnRhaW4gZnJvbSB0aGUgQXV0 aG9yaXphdGlvbiBTZXJ2ZXIgdG8gYmUgYWJsZSB0byByZWdpc3RlciB3aXRoIHRoZSBTSVAgUmVn aXN0cmFyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7UmlmYWF0PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+LS0tPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7ICoqIEVkaXRvcmlhbCBO aXRzOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTZWN0aW9uIDEuMy4mbmJzcDsgVHlwby4gcy91 c3VhbHkvdXN1YWxseS88YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFdpbGwgZml4Ljxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBTZWN0aW9uIDcuJm5ic3A7IFR5cG8uJm5ic3A7IHMvY292 ZXJzaW9uL2NvbnZlcnNpb24vPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwOyBXaWxsIGZpeC48YnI+ DQo8YnI+DQotLS08YnI+DQo8YnI+DQpSZWdhcmRzLDxicj4NCjxicj4NCkNocmlzdGVyPGJyPg0K PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6209157002AF4DECAACB3EC46D70B83Eericssoncom_-- From nobody Tue May 5 11:47:07 2020 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 9D9773A0C37; Tue, 5 May 2020 11:46:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158870439650.25526.11019219125541236895@ietfa.amsl.com> Date: Tue, 05 May 2020 11:46:36 -0700 Archived-At: Subject: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 18:46:37 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-15: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for the updates in the -14 (and -15); they cover most of my points. Unfortunately, the new security considerations text seems to introduce a problematic recommendation: Because of that, it is critical to make sure that extra security measures be taken to safeguard credentials used for Single Sign-On. Examples of such measures include long passphrase instead of a password, enabling multi-factor factor authentication, and the use of embedded browser when possible, as defined in [RFC8252]. Looking at RFC 8252 (Section 8.12), it seems to be rather strongly recommending to *not* use an embedded browser, which is the opposite of the apparent recommendation here. Are we missing a word "avoiding" or similar? Also, I am not 100% sure my note about refresh tokens was fully addressed; in Section 2.1.1 we see: The refresh token is only used between the UAC and the AS. If the AS provides a refresh token to the UAC, the UAC uses it to request a new access token and refresh token from the AS before the currently used access token expires ([RFC6749], Section 1.5). If the AS does not Is it accurate to say that the refresh token is used "to request a new access token and refresh token" (specifically the "and refresh token" part)? I know that it is not always returned, but am less sure about whether the semantics always include an (implicit) request for a new one. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Some other comments on the new text that do not rise to Discuss-level. Thanks for adding the mention of a whitelist of trusted ASes; I would consider also mentioning it in Section 4 for the authz_server parameter, and/or in the security considerations. I also would have liked to see some guidance about when one should/shouldn't include the realm parameter in a challenge. Section 2.1.1 UAC contacts the AS in order to obtain tokens, and includes the requested scopes, based on a local configuration (Figure 1). The UAC MUST check the AS URL received in the 401/407 response against a list of trusted ASs configured on the UAC, in order to prevent several classes of possible vulnerabilities when a client blindly attempt to use any provided authorization. nits: "attempts", and maybe "any provided authorization server". Section 3 nit: s/claimes/claims/ Section 5 When a registrar chooses to challenge a REGISTER request, if the registrar can provide access to different levels of services, it is RECOMMENDED that the registrar includes a scope in the response in order to indicate the minimum scope needed to register and access basic services. The access token might include an extended scope that gives the user access to more advanced features beyond basic services. Is there anything to say about how the broader scope value might be learned? From nobody Tue May 5 12:10:45 2020 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 0FECF3A07A0; Tue, 5 May 2020 12:10:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 erjlm0FLVmmE; Tue, 5 May 2020 12:10:41 -0700 (PDT) Received: from mail-io1-xd44.google.com (mail-io1-xd44.google.com [IPv6:2607:f8b0:4864:20::d44]) (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 91EA33A079D; Tue, 5 May 2020 12:10:40 -0700 (PDT) Received: by mail-io1-xd44.google.com with SMTP id k6so2771472iob.3; Tue, 05 May 2020 12:10:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xnFiorE3MVA2uTxZPbUvwTqOYWSraO7dilmV9HkvIsk=; b=n4CcmBJnhIqP2mt0VfH30GKH1VEetEZQz9b4Ci5BVmW6n2WYAc7HM4JMBCepNgzzNP p1WPvZ+We4wvuHNhyZ4H/S8XU+n99PY7eiSxURP/gJOaExdORYsxK3xTfEdAHLH7KWbm W2te/iQ2k1W6Wo03FsGAvOTKscqs3sA1xjhHiIdsCsCsKmfHu6u7r/2KPhuc4VKRBNXc fnmk75OQVvdvlBF1kEexu2+n9ImJvi4wQ6j4Zd0lb12BFpWlEjZ8QmRV7JB30zMhI/gW XSVzSaLwodwUid7F+yMDPJJIFF57hrXcFjVG8yzztPlWt//5YSSER76rjyXATNZEBOZM jA4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=xnFiorE3MVA2uTxZPbUvwTqOYWSraO7dilmV9HkvIsk=; b=Q0Yzk/lcG2jCnuu6M123inPhJTiXMqw4a0rx3J1vx2wcs/ZBj3rHipSAg28EE9t56E QQ1O3fwuX4K6Hgo4eH6OVMvKI5veeL1Mqz9qw3RpI0BDY+EIh5Frf6LtQRtXtcACQand Sk5bBl31gBaZw4aS8Jchaq6GnymDmln6XyeijzBw/b9Pl0YpJWbAI7/QYkwHtiLyLh9I z25vNENdDzrT5IzNmfKuQg6/dnKoYjmNEIkZ+9Cdf2GsNiDIJ4wAjr4fv2MoaYVoLf+C FYG0ziot0EFGpGPP1jOEx8iEqEfTF63ldYt9B9c9mxzzuohnREqRsAj2taAZwC8zkI8L 0cCw== X-Gm-Message-State: AGi0PubBjM4D8e8BcHERHoxZGQrhvRroJu6Irf5Ky6Ee6v98GNPVQnxX 5J+CrdHAySvQSiWC8MQDEhzqEAeuvUSMSxnzo9M= X-Google-Smtp-Source: APiQypKFlTzGMN1mDyrLmeq38D29hm+uuPXPH9BEPnXDErQlsfiJTr6gmKuMP7RC42fr3GgEP2fbUtLZrhg66GJND8I= X-Received: by 2002:a05:6602:15ca:: with SMTP id f10mr4880199iow.51.1588705839920; Tue, 05 May 2020 12:10:39 -0700 (PDT) MIME-Version: 1.0 References: <158870439650.25526.11019219125541236895@ietfa.amsl.com> In-Reply-To: <158870439650.25526.11019219125541236895@ietfa.amsl.com> From: Rifaat Shekh-Yusef Date: Tue, 5 May 2020 15:10:28 -0400 Message-ID: To: Benjamin Kaduk Cc: The IESG , draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="0000000000003dbac905a4eb6742" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 19:10:43 -0000 --0000000000003dbac905a4eb6742 Content-Type: text/plain; charset="UTF-8" Inline... On Tue, May 5, 2020 at 2:46 PM Benjamin Kaduk via Datatracker < noreply@ietf.org> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sipcore-sip-token-authnz-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for the updates in the -14 (and -15); they cover most of my points. > > Unfortunately, the new security considerations text seems to introduce a > problematic recommendation: > > Because of that, it is critical to make sure that extra security > measures be taken to safeguard credentials used for Single Sign-On. > Examples of such measures include long passphrase instead of a > password, enabling multi-factor factor authentication, and the use of > embedded browser when possible, as defined in [RFC8252]. > > Looking at RFC 8252 (Section 8.12), it seems to be rather strongly > recommending > to *not* use an embedded browser, which is the opposite of the apparent > recommendation here. Are we missing a word "avoiding" or similar? > > Yeah, this should have been "browser" not "embedded browser". We will remove the "embedded browser" and replace it with "the native platform browser". > Also, I am not 100% sure my note about refresh tokens was fully addressed; > in Section 2.1.1 we see: > > The refresh token is only used between the UAC and the AS. If the AS > provides a refresh token to the UAC, the UAC uses it to request a new > access token and refresh token from the AS before the currently used > access token expires ([RFC6749], Section 1.5). If the AS does not > > Is it accurate to say that the refresh token is used "to request a new > access > token and refresh token" (specifically the "and refresh token" part)? I > know that > it is not always returned, but am less sure about whether the semantics > always > include an (implicit) request for a new one. > Returning a refresh token is based on AS policy. We will remove the "and refresh token". > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some other comments on the new text that do not rise to Discuss-level. > > Thanks for adding the mention of a whitelist of trusted ASes; I would > consider > also mentioning it in Section 4 for the authz_server parameter, and/or in > the > security considerations. > > We will add that to the security consideration section. > I also would have liked to see some guidance about when one > should/shouldn't > include the realm parameter in a challenge. > > I think this is out of scope, as we are not updating or changing the existing SIP behavior on this issue. Section 2.1.1 > > UAC contacts the AS in order to obtain tokens, and includes the > requested scopes, based on a local configuration (Figure 1). The UAC > MUST check the AS URL received in the 401/407 response against a list > of trusted ASs configured on the UAC, in order to prevent several > classes of possible vulnerabilities when a client blindly attempt to > use any provided authorization. > > nits: "attempts", and maybe "any provided authorization server". > > Will fix it > Section 3 > > nit: s/claimes/claims/ > > Will fix it > Section 5 > > When a registrar chooses to challenge a REGISTER request, if the > registrar can provide access to different levels of services, it is > RECOMMENDED that the registrar includes a scope in the response in > order to indicate the minimum scope needed to register and access > basic services. The access token might include an extended scope > that gives the user access to more advanced features beyond basic > services. > > Is there anything to say about how the broader scope value might be > learned? > > In SIP, it is typically controlled by the admin, that controls the AS, and dictates the level of access for the user. We will add a sentence to that extent. Regards, Rifaat --0000000000003dbac905a4eb6742 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Inline...

On Tue, May 5, 2020 at 2:46 PM Benjamin Kadu= k via Datatracker <noreply@ietf.org<= /a>> wrote:
B= enjamin Kaduk has entered the following ballot position for
draft-ietf-sipcore-sip-token-authnz-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/s= tatement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/do= c/draft-ietf-sipcore-sip-token-authnz/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the updates in the -14 (and -15); they cover most of my points.<= br>
Unfortunately, the new security considerations text seems to introduce a problematic recommendation:

=C2=A0 =C2=A0Because of that, it is critical to make sure that extra securi= ty
=C2=A0 =C2=A0measures be taken to safeguard credentials used for Single Sig= n-On.
=C2=A0 =C2=A0Examples of such measures include long passphrase instead of a=
=C2=A0 =C2=A0password, enabling multi-factor factor authentication, and the= use of
=C2=A0 =C2=A0embedded browser when possible, as defined in [RFC8252].

Looking at RFC 8252 (Section 8.12), it seems to be rather strongly recommen= ding
to *not* use an embedded browser, which is the opposite of the apparent
recommendation here.=C2=A0 Are we missing a word "avoiding" or si= milar?


Yeah, this should have been "brow= ser" not "embedded browser".
We will remove the &q= uot;embedded browser" and replace it with "the native platform br= owser".

=C2=A0
Also, I am not 100% sure my note about refresh tokens was fully addressed;<= br> in Section 2.1.1 we see:

=C2=A0 =C2=A0The refresh token is only used between the UAC and the AS.=C2= =A0 If the AS
=C2=A0 =C2=A0provides a refresh token to the UAC, the UAC uses it to reques= t a new
=C2=A0 =C2=A0access token and refresh token from the AS before the currentl= y used
=C2=A0 =C2=A0access token expires ([RFC6749], Section 1.5).=C2=A0 If the AS= does not

Is it accurate to say that the refresh token is used "to request a new= access
token and refresh token" (specifically the "and refresh token&quo= t; part)?=C2=A0 I know that
it is not always returned, but am less sure about whether the semantics alw= ays
include an (implicit) request for a new one.=C2=A0
=C2= =A0
Returning a refresh token is based on AS policy.
We= will remove the "and refresh token".

= =C2=A0

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some other comments on the new text that do not rise to Discuss-level.

Thanks for adding the mention of a whitelist of trusted ASes; I would consi= der
also mentioning it in Section 4 for the authz_server parameter, and/or in t= he
security considerations.

We will add that to the security consideration sectio= n.

=C2=A0
I also would have liked to see some guidance about when one should/shouldn&= #39;t
include the realm parameter in a challenge.

I think this is out of scope, as we are not updating = or changing the existing SIP behavior on this issue.
=C2=A0
=

Section 2.1.1

=C2=A0 =C2=A0UAC contacts the AS in order to obtain tokens, and includes th= e
=C2=A0 =C2=A0requested scopes, based on a local configuration (Figure 1).= =C2=A0 The UAC
=C2=A0 =C2=A0MUST check the AS URL received in the 401/407 response against= a list
=C2=A0 =C2=A0of trusted ASs configured on the UAC, in order to prevent seve= ral
=C2=A0 =C2=A0classes of possible vulnerabilities when a client blindly atte= mpt to
=C2=A0 =C2=A0use any provided authorization.

nits: "attempts", and maybe "any provided authorization serv= er".

Will fix it
=C2=A0
Section 3

nit: s/claimes/claims/

Will fix it

=C2=A0
Section 5

=C2=A0 =C2=A0When a registrar chooses to challenge a REGISTER request, if t= he
=C2=A0 =C2=A0registrar can provide access to different levels of services, = it is
=C2=A0 =C2=A0RECOMMENDED that the registrar includes a scope in the respons= e in
=C2=A0 =C2=A0order to indicate the minimum scope needed to register and acc= ess
=C2=A0 =C2=A0basic services.=C2=A0 The access token might include an extend= ed scope
=C2=A0 =C2=A0that gives the user access to more advanced features beyond ba= sic
=C2=A0 =C2=A0services.

Is there anything to say about how the broader scope value might be learned= ?

In SIP, it is typically controlled by the admin, that= controls the AS, and dictates the level of access for the user.
= We will add a sentence to that extent.

Regards,
=C2=A0Rifaat
=C2=A0
--0000000000003dbac905a4eb6742-- From nobody Tue May 5 12:18:11 2020 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 EBD693A083A; Tue, 5 May 2020 12:18:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 nifvNOzzse4H; Tue, 5 May 2020 12:18:07 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60050.outbound.protection.outlook.com [40.107.6.50]) (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 EAECE3A0835; Tue, 5 May 2020 12:18:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CIP+lDILtlhrEGrasCM0ZuWWBGt83q01JeHJcZtvjpUsL8A2waOsmfVL2b0NvzS4gBMy3Z/TMoabrZw6n7ms92jQo26kyC30uX82rmdyebfiZqjldmXWcl3l8SRLOqRU7QLLyRjgvu/AOJeuzbpSjA4id5pjew/rcK1BueXyXs14mKXX4gONSwiUVuLZjzGyh7wZJtUDYkbqmEW82IZI5m/Hm5gIACCjVGjKI2o/+dBMlmjVe7l6DkV9dKEA7fFj8TtGKWRebX3kKYoV4P+9cuD1qpw4BsOjjtvN+3FVSIpe7Ejn8b74js9OCipmssT3SYDXiqpOJtMbRfOS/k2bpQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q1iipTM+QorViBxeswDXXMmExx1yS4MMNMEBm1o5zBc=; b=Qw7MIvjV/1WP4EG4XFUibcFiPCb5frNGDfNK4dGgubIiBbyHGYd6ekaCIr8huew9Ns6sHkpuKeYiRg48H5pcFef/qVG3UODpZwiWWvfjHPwvJtfAGI35aQg3X+MTCKX/k5l+axjtXOeJCK8pAe0IylncUvwnE3ueek6pOD3SdS5aTFpgcyE1OZ3bNsykP1U5Iyo0ns6WJEdh9zUaqTEo54cDihSsQao2CwuNDqDagaIAWs2+kSPcL6qIwvr18SGIKLKCVXuy4Don9yHc1gXD25TqCxjvIxhvly8h1OrDUclgo0mNkAQR3nyHa3htWruawIXihHoZ+MDDLL0xXgvUTg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=q1iipTM+QorViBxeswDXXMmExx1yS4MMNMEBm1o5zBc=; b=kK6lASD9hoUCAqaFhBtkh1T3M5HjM4mTeaMIG7yj1984G8HcHfpvlWSsop+no1j7ouipQUF2x3ckLZAfjBfnjVQDVc5A35m6FkwkLz1SFxiKUTCPwZT2ZPBnCq3NsoIJcbnuzZ5jzke4CNdi7vMzuYXUzojskD0P8Soot0BGqVQ= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6946.eurprd07.prod.outlook.com (2603:10a6:20b:1b8::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Tue, 5 May 2020 19:17:58 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2979.025; Tue, 5 May 2020 19:17:58 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Benjamin Kaduk CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) Thread-Index: AQHWIw2GyckcWhEga0GXDfMI9v/T+qiZ25IAgAA0YYA= Date: Tue, 5 May 2020 19:17:57 +0000 Message-ID: <4B261B27-F866-4EE6-9DA6-18BE24D34FB6@ericsson.com> References: <158870439650.25526.11019219125541236895@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.216.230.200] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6319491b-f422-4a85-fdd4-08d7f1290547 x-ms-traffictypediagnostic: AM7PR07MB6946: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: k2rTacTIBHDE7lpgh69LByzmEhjIvBYuPUyER/YD0EQAVDIPvn+ZLnh3DyrDELuklZA1kTr358wsGTVHwJCTf/cxmqwF31XzdICb/2lpVLD7BHpeszPcCx7zDzSeoLqhbwWgH67+Po7EbUaIkoRljuMXEzSi+BsmxiTSytV4DOaW+mUbjbTdU/NFS575syK2/XzEPUHHm0HIpM7N2vlIF/DJzdOqXq4aQiyLhz5R9stNrx2SXPlMmyDat9JT3/C5SDTIf8VO1uAch/k8lrylb/wcqjgUXMfqWHCEHMGuPYEnBzuOUlM4mnsc2vLxvL1RmS+qXRW8CAYCvhOLomudEwlriAcoIMyDKP3xpAe0jSyn8U3d5PyLziYe/aYdPT+xyQ6uK/pm8SWsqhujHq6fPzGLzbubIBbE87vQQXhinRVxVDguwfdIT3XXSoFWm8GFQ+x2NP7PF2x7hX7Z7nMEhqBSXX8sqkFESDhKEYbfl4e48Js/SKCN2xZlnbJJAAIC8JyYap/cJJgV1OFJCfN6gqbcn3/BCbmmG+SWBfXEQZKcim4/XDiQOsGvW78JxCj2uQExVbRFILz6FRDdSEDA+E6nbsw/pwhF6GEf6vP1g9g= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(33430700001)(44832011)(110136005)(54906003)(86362001)(6486002)(33440700001)(66574012)(186003)(21615005)(2906002)(26005)(2616005)(33656002)(53546011)(6512007)(66446008)(66476007)(66556008)(91956017)(66946007)(64756008)(8676002)(6506007)(498600001)(966005)(8936002)(36756003)(76116006)(5660300002)(4326008)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Go91NW0DZp/q6C58DG3Xixu99GPykBwGCL37sTUaI8cYcNvMgaLjM4aUI+2XanPOc9Yt6NhvDMtaHOGzYWu5wMVEjAuGqkBWMJQyZ8nIoEGHohCnAoWlCLai2Fw6lDQn3xB4X8GDFlgyUyRwrcn8CAWSzkpfEh0VTPuuaK9YNCm00iVs4SSpW0x2t8xIdMmz31loAm3Am77zcAJWHS2pXQD/2N4zElmLklGfm8jGqWjFfsNrQA/FVeU6A6WBGv8pLMU68p1Ss9l6xWHrvhFK2JEy0m290ECNtO30I+GeBZoeZF+n4UQSXWNuQi3AQ0PvEAqIaaIFb/KC6/e5f/6LfwWEyrdFNCZmj/Q/gJU66VjYOVDxQ/oWmj/+W2aA+rtEtSyLWmtv+tINNxPYbwNnUKc8l6/UTARYrW5QFifRfpmQxeI/ccshPy+yV1Rc8K49v+EHNsa1ybEnUz9Nubm3/NrSMsqYeCXAZSS97Jqrq7KlrsNINf3D8KPU0NSfUlpxYciQUWi6D7TrqdRfzFCFGyo7LeKPeY7HWX9aYG4z8KNWcB/O587TnfB3qtJpC8vlzM3CKw85eepHg3t3QKdqoBvENudo0c9NuCZ9B9hW6qK6j84DzmnS2tt/Hw4cSZHydVqtEtQ7ERZxhve6x0VL9cjt/sBfiFOzzzXiSUzUEXxhXF6o4btYCxZs+JFMmMb7k+FmQQZ6CXaU8ubN2NeSLHdue0YcVpEMTIqsrgd2XLOcOO0gepazY6uA0u0F8QQbN0YsMk3AVjneBe84deDV8UyfMN6zR2S83b+tQmZrADk6LDXnH9FnRCAS3dFYvVeg x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4B261B27F8664EE69DA618BE24D34FB6ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6319491b-f422-4a85-fdd4-08d7f1290547 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 19:17:58.0204 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 0qyJxQU8vrDpTJsTmfoIeAK4A4ZVEdikBipkyJt0LQFMbcResTHxghF1WsmShtcFYC9Pw84grdj4lciXZV2tyGdUQgu5AyiJzJmj226fMcA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6946 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 19:18:10 -0000 --_000_4B261B27F8664EE69DA618BE24D34FB6ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgd2FzIGp1c3QgYWJvdXQgdG8gcHJlc3MgdGhlIFNFTkQgYnV0dG9uIHdpdGggbXkg Y29tbWVudHMgb24gdGhlIENPTU1FTlQsIHdoZW4gSSBzYXcgUmlmYWF04oCZcyByZXBseSBzaG93 aW5nIHVwLCBhbmQgdGhhdCBoZSBtb3JlIG9yIGxlc3MgaGFzIHNhaWQgd2hhdCBJIHdhcyBnb2lu ZyB0byBzYXkgOikNCg0KUmVnYXJkaW5nIHRoZSBjb21tZW50IG9uIHRoZSDigJxyZWFsbeKAnSwg YXMgUmlmYWF0IHNhaWQgaXQgaXMgbm90IHNwZWNpZmljIHRvIHRoaXMgc3BlY2lmaWNhdGlvbi4g VGhlIGdlbmVyaWMgU0lQIHByb2NlZHVyZXMgYXBwbHkuDQoNCg0KDQpBbmQsIHdoZW4gcmVhZGlu ZyBSRkMgMzI2MSwgd2hpbGUgSSBjYW4ndCBmaW5kIGFueSB0ZXh0IGV4cGxpY2l0bHkgc2F5aW5n ICJNVVNUIGluY2x1ZGUgcmVhbG0iLCBteSByZWFkaW5nIGlzIHRoYXQgaXQgaXMgaW1wbGljaXRs eSBtYW5kYXRlZDogbWFueSBvZiB0aGUgcHJvY2VkdXJlcyBhc3N1bWUgdGhlIHByZXNlbmNlIG9m IHRoZSByZWFsbSBwYXJhbWV0ZXIuDQoNCg0KDQpSZWdhcmRzLA0KDQoNCg0KQ2hyaXN0ZXINCg0K DQpGcm9tOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFhdC5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6 IFR1ZXNkYXksIDUgTWF5IDIwMjAgYXQgMjIuMTANClRvOiBCZW5qYW1pbiBLYWR1ayA8a2FkdWtA bWl0LmVkdT4NCkNjOiAiaWVzZ0BpZXRmLm9yZyIgPGllc2dAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0 Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnpAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXNpcGNvcmUt c2lwLXRva2VuLWF1dGhuekBpZXRmLm9yZz4sICJzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZyIgPHNp cGNvcmUtY2hhaXJzQGlldGYub3JnPiwgInNpcGNvcmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYu b3JnPiwgIkEuIE1haG9uZXkiIDxtYWhvbmV5QG5vc3RydW0uY29tPg0KU3ViamVjdDogUmU6IEJl bmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbiBkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1 dGhuei0xNTogKHdpdGggRElTQ1VTUyBhbmQgQ09NTUVOVCkNClJlc2VudCBmcm9tOiA8YWxpYXMt Ym91bmNlc0BpZXRmLm9yZz4NClJlc2VudCB0bzogUmlmYWF0IFNoZWtoLVl1c2VmIDxyaWZhYXQu aWV0ZkBnbWFpbC5jb20+LCBDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPiwgVmljdG9yIFBhc2N1YWwgPHZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNv bT4NClJlc2VudCBkYXRlOiBUdWVzZGF5LCA1IE1heSAyMDIwIGF0IDIyLjEwDQoNCklubGluZS4u Lg0KDQpPbiBUdWUsIE1heSA1LCAyMDIwIGF0IDI6NDYgUE0gQmVuamFtaW4gS2FkdWsgdmlhIERh dGF0cmFja2VyIDxub3JlcGx5QGlldGYub3JnPG1haWx0bzpub3JlcGx5QGlldGYub3JnPj4gd3Jv dGU6DQpCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3Np dGlvbiBmb3INCmRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTE1OiBEaXNjdXNz DQoNCldoZW4gcmVzcG9uZGluZywgcGxlYXNlIGtlZXAgdGhlIHN1YmplY3QgbGluZSBpbnRhY3Qg YW5kIHJlcGx5IHRvIGFsbA0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQg Q0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMNCmludHJvZHVjdG9yeSBwYXJhZ3JhcGgs IGhvd2V2ZXIuKQ0KDQoNClBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCmZvciBtb3JlIGluZm9ybWF0aW9uIGFi b3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQoNCg0KVGhlIGRvY3VtZW50 LCBhbG9uZyB3aXRoIG90aGVyIGJhbGxvdCBwb3NpdGlvbnMsIGNhbiBiZSBmb3VuZCBoZXJlOg0K aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10 b2tlbi1hdXRobnovDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpESVNDVVNTOg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KDQpUaGFua3MgZm9yIHRoZSB1cGRhdGVzIGluIHRoZSAtMTQgKGFuZCAtMTUpOyB0aGV5IGNv dmVyIG1vc3Qgb2YgbXkgcG9pbnRzLg0KDQpVbmZvcnR1bmF0ZWx5LCB0aGUgbmV3IHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zIHRleHQgc2VlbXMgdG8gaW50cm9kdWNlIGENCnByb2JsZW1hdGljIHJl Y29tbWVuZGF0aW9uOg0KDQogICBCZWNhdXNlIG9mIHRoYXQsIGl0IGlzIGNyaXRpY2FsIHRvIG1h a2Ugc3VyZSB0aGF0IGV4dHJhIHNlY3VyaXR5DQogICBtZWFzdXJlcyBiZSB0YWtlbiB0byBzYWZl Z3VhcmQgY3JlZGVudGlhbHMgdXNlZCBmb3IgU2luZ2xlIFNpZ24tT24uDQogICBFeGFtcGxlcyBv ZiBzdWNoIG1lYXN1cmVzIGluY2x1ZGUgbG9uZyBwYXNzcGhyYXNlIGluc3RlYWQgb2YgYQ0KICAg cGFzc3dvcmQsIGVuYWJsaW5nIG11bHRpLWZhY3RvciBmYWN0b3IgYXV0aGVudGljYXRpb24sIGFu ZCB0aGUgdXNlIG9mDQogICBlbWJlZGRlZCBicm93c2VyIHdoZW4gcG9zc2libGUsIGFzIGRlZmlu ZWQgaW4gW1JGQzgyNTJdLg0KDQpMb29raW5nIGF0IFJGQyA4MjUyIChTZWN0aW9uIDguMTIpLCBp dCBzZWVtcyB0byBiZSByYXRoZXIgc3Ryb25nbHkgcmVjb21tZW5kaW5nDQp0byAqbm90KiB1c2Ug YW4gZW1iZWRkZWQgYnJvd3Nlciwgd2hpY2ggaXMgdGhlIG9wcG9zaXRlIG9mIHRoZSBhcHBhcmVu dA0KcmVjb21tZW5kYXRpb24gaGVyZS4gIEFyZSB3ZSBtaXNzaW5nIGEgd29yZCAiYXZvaWRpbmci IG9yIHNpbWlsYXI/DQoNClllYWgsIHRoaXMgc2hvdWxkIGhhdmUgYmVlbiAiYnJvd3NlciIgbm90 ICJlbWJlZGRlZCBicm93c2VyIi4NCldlIHdpbGwgcmVtb3ZlIHRoZSAiZW1iZWRkZWQgYnJvd3Nl ciIgYW5kIHJlcGxhY2UgaXQgd2l0aCAidGhlIG5hdGl2ZSBwbGF0Zm9ybSBicm93c2VyIi4NCg0K DQpBbHNvLCBJIGFtIG5vdCAxMDAlIHN1cmUgbXkgbm90ZSBhYm91dCByZWZyZXNoIHRva2VucyB3 YXMgZnVsbHkgYWRkcmVzc2VkOw0KaW4gU2VjdGlvbiAyLjEuMSB3ZSBzZWU6DQoNCiAgIFRoZSBy ZWZyZXNoIHRva2VuIGlzIG9ubHkgdXNlZCBiZXR3ZWVuIHRoZSBVQUMgYW5kIHRoZSBBUy4gIElm IHRoZSBBUw0KICAgcHJvdmlkZXMgYSByZWZyZXNoIHRva2VuIHRvIHRoZSBVQUMsIHRoZSBVQUMg dXNlcyBpdCB0byByZXF1ZXN0IGEgbmV3DQogICBhY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9r ZW4gZnJvbSB0aGUgQVMgYmVmb3JlIHRoZSBjdXJyZW50bHkgdXNlZA0KICAgYWNjZXNzIHRva2Vu IGV4cGlyZXMgKFtSRkM2NzQ5XSwgU2VjdGlvbiAxLjUpLiAgSWYgdGhlIEFTIGRvZXMgbm90DQoN CklzIGl0IGFjY3VyYXRlIHRvIHNheSB0aGF0IHRoZSByZWZyZXNoIHRva2VuIGlzIHVzZWQgInRv IHJlcXVlc3QgYSBuZXcgYWNjZXNzDQp0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiIgKHNwZWNpZmlj YWxseSB0aGUgImFuZCByZWZyZXNoIHRva2VuIiBwYXJ0KT8gIEkga25vdyB0aGF0DQppdCBpcyBu b3QgYWx3YXlzIHJldHVybmVkLCBidXQgYW0gbGVzcyBzdXJlIGFib3V0IHdoZXRoZXIgdGhlIHNl bWFudGljcyBhbHdheXMNCmluY2x1ZGUgYW4gKGltcGxpY2l0KSByZXF1ZXN0IGZvciBhIG5ldyBv bmUuDQoNClJldHVybmluZyBhIHJlZnJlc2ggdG9rZW4gaXMgYmFzZWQgb24gQVMgcG9saWN5Lg0K V2Ugd2lsbCByZW1vdmUgdGhlICJhbmQgcmVmcmVzaCB0b2tlbiIuDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpDT01NRU5UOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpTb21lIG90aGVyIGNvbW1lbnRzIG9uIHRo ZSBuZXcgdGV4dCB0aGF0IGRvIG5vdCByaXNlIHRvIERpc2N1c3MtbGV2ZWwuDQoNClRoYW5rcyBm b3IgYWRkaW5nIHRoZSBtZW50aW9uIG9mIGEgd2hpdGVsaXN0IG9mIHRydXN0ZWQgQVNlczsgSSB3 b3VsZCBjb25zaWRlcg0KYWxzbyBtZW50aW9uaW5nIGl0IGluIFNlY3Rpb24gNCBmb3IgdGhlIGF1 dGh6X3NlcnZlciBwYXJhbWV0ZXIsIGFuZC9vciBpbiB0aGUNCnNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLg0KV2Ugd2lsbCBhZGQgdGhhdCB0byB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0 aW9uLg0KDQoNCkkgYWxzbyB3b3VsZCBoYXZlIGxpa2VkIHRvIHNlZSBzb21lIGd1aWRhbmNlIGFi b3V0IHdoZW4gb25lIHNob3VsZC9zaG91bGRuJ3QNCmluY2x1ZGUgdGhlIHJlYWxtIHBhcmFtZXRl ciBpbiBhIGNoYWxsZW5nZS4NCkkgdGhpbmsgdGhpcyBpcyBvdXQgb2Ygc2NvcGUsIGFzIHdlIGFy ZSBub3QgdXBkYXRpbmcgb3IgY2hhbmdpbmcgdGhlIGV4aXN0aW5nIFNJUCBiZWhhdmlvciBvbiB0 aGlzIGlzc3VlLg0KDQoNClNlY3Rpb24gMi4xLjENCg0KICAgVUFDIGNvbnRhY3RzIHRoZSBBUyBp biBvcmRlciB0byBvYnRhaW4gdG9rZW5zLCBhbmQgaW5jbHVkZXMgdGhlDQogICByZXF1ZXN0ZWQg c2NvcGVzLCBiYXNlZCBvbiBhIGxvY2FsIGNvbmZpZ3VyYXRpb24gKEZpZ3VyZSAxKS4gIFRoZSBV QUMNCiAgIE1VU1QgY2hlY2sgdGhlIEFTIFVSTCByZWNlaXZlZCBpbiB0aGUgNDAxLzQwNyByZXNw b25zZSBhZ2FpbnN0IGEgbGlzdA0KICAgb2YgdHJ1c3RlZCBBU3MgY29uZmlndXJlZCBvbiB0aGUg VUFDLCBpbiBvcmRlciB0byBwcmV2ZW50IHNldmVyYWwNCiAgIGNsYXNzZXMgb2YgcG9zc2libGUg dnVsbmVyYWJpbGl0aWVzIHdoZW4gYSBjbGllbnQgYmxpbmRseSBhdHRlbXB0IHRvDQogICB1c2Ug YW55IHByb3ZpZGVkIGF1dGhvcml6YXRpb24uDQoNCm5pdHM6ICJhdHRlbXB0cyIsIGFuZCBtYXli ZSAiYW55IHByb3ZpZGVkIGF1dGhvcml6YXRpb24gc2VydmVyIi4NCldpbGwgZml4IGl0DQoNClNl Y3Rpb24gMw0KDQpuaXQ6IHMvY2xhaW1lcy9jbGFpbXMvDQpXaWxsIGZpeCBpdA0KDQoNClNlY3Rp b24gNQ0KDQogICBXaGVuIGEgcmVnaXN0cmFyIGNob29zZXMgdG8gY2hhbGxlbmdlIGEgUkVHSVNU RVIgcmVxdWVzdCwgaWYgdGhlDQogICByZWdpc3RyYXIgY2FuIHByb3ZpZGUgYWNjZXNzIHRvIGRp ZmZlcmVudCBsZXZlbHMgb2Ygc2VydmljZXMsIGl0IGlzDQogICBSRUNPTU1FTkRFRCB0aGF0IHRo ZSByZWdpc3RyYXIgaW5jbHVkZXMgYSBzY29wZSBpbiB0aGUgcmVzcG9uc2UgaW4NCiAgIG9yZGVy IHRvIGluZGljYXRlIHRoZSBtaW5pbXVtIHNjb3BlIG5lZWRlZCB0byByZWdpc3RlciBhbmQgYWNj ZXNzDQogICBiYXNpYyBzZXJ2aWNlcy4gIFRoZSBhY2Nlc3MgdG9rZW4gbWlnaHQgaW5jbHVkZSBh biBleHRlbmRlZCBzY29wZQ0KICAgdGhhdCBnaXZlcyB0aGUgdXNlciBhY2Nlc3MgdG8gbW9yZSBh ZHZhbmNlZCBmZWF0dXJlcyBiZXlvbmQgYmFzaWMNCiAgIHNlcnZpY2VzLg0KDQpJcyB0aGVyZSBh bnl0aGluZyB0byBzYXkgYWJvdXQgaG93IHRoZSBicm9hZGVyIHNjb3BlIHZhbHVlIG1pZ2h0IGJl IGxlYXJuZWQ/DQpJbiBTSVAsIGl0IGlzIHR5cGljYWxseSBjb250cm9sbGVkIGJ5IHRoZSBhZG1p biwgdGhhdCBjb250cm9scyB0aGUgQVMsIGFuZCBkaWN0YXRlcyB0aGUgbGV2ZWwgb2YgYWNjZXNz IGZvciB0aGUgdXNlci4NCldlIHdpbGwgYWRkIGEgc2VudGVuY2UgdG8gdGhhdCBleHRlbnQuDQoN ClJlZ2FyZHMsDQogUmlmYWF0DQoNCg== --_000_4B261B27F8664EE69DA618BE24D34FB6ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5 bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3MC44NXB0IDIuMGNtIDcwLjg1cHQgMi4wY207fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRkkiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkkgd2FzIGp1c3QgYWJvdXQgdG8gcHJlc3MgdGhlIFNFTkQgYnV0dG9uIHdpdGggbXkg Y29tbWVudHMgb24gdGhlIENPTU1FTlQsIHdoZW4gSSBzYXcgUmlmYWF04oCZcyByZXBseSBzaG93 aW5nIHVwLCBhbmQgdGhhdCBoZSBtb3JlIG9yIGxlc3MgaGFzIHNhaWQgd2hhdCBJIHdhcyBnb2lu ZyB0byBzYXkgOik8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRpbmcgdGhl IGNvbW1lbnQgb24gdGhlIOKAnHJlYWxt4oCdLCBhcyBSaWZhYXQgc2FpZCBpdCBpcyBub3Qgc3Bl Y2lmaWMgdG8gdGhpcyBzcGVjaWZpY2F0aW9uLiBUaGUgZ2VuZXJpYyBTSVAgcHJvY2VkdXJlcyBh cHBseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZCwgd2hlbiByZWFkaW5nIFJGQyAzMjYx LCB3aGlsZSBJIGNhbid0IGZpbmQgYW55IHRleHQgZXhwbGljaXRseSBzYXlpbmcgJnF1b3Q7TVVT VCBpbmNsdWRlIHJlYWxtJnF1b3Q7LCBteSByZWFkaW5nIGlzIHRoYXQgaXQgaXMgaW1wbGljaXRs eSBtYW5kYXRlZDogbWFueSBvZiB0aGUgcHJvY2VkdXJlcyBhc3N1bWUgdGhlIHByZXNlbmNlIG9m IHRoZSByZWFsbSBwYXJhbWV0ZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U ZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+UmlmYWF0IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBn bWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDUgTWF5IDIwMjAgYXQgMjIu MTA8YnI+DQo8Yj5UbzogPC9iPkJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQuZWR1Jmd0Ozxi cj4NCjxiPkNjOiA8L2I+JnF1b3Q7aWVzZ0BpZXRmLm9yZyZxdW90OyAmbHQ7aWVzZ0BpZXRmLm9y ZyZndDssICZxdW90O2RyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56QGlldGYub3Jn JnF1b3Q7ICZsdDtkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuekBpZXRmLm9yZyZn dDssICZxdW90O3NpcGNvcmUtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlLWNoYWly c0BpZXRmLm9yZyZndDssICZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVvdDsgJmx0O3NpcGNvcmVA aWV0Zi5vcmcmZ3Q7LCAmcXVvdDtBLiBNYWhvbmV5JnF1b3Q7ICZsdDttYWhvbmV5QG5vc3RydW0u Y29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogQmVuamFtaW4gS2FkdWsncyBEaXNjdXNz IG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTE1OiAod2l0aCBESVNDVVNT IGFuZCBDT01NRU5UKTxicj4NCjxiPlJlc2VudCBmcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50IHRvOiA8L2I+UmlmYWF0IFNoZWtoLVl1c2VmICZs dDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0 ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywgVmljdG9yIFBhc2N1YWwgJmx0O3ZpY3Rvci5w YXNjdWFsLmF2aWxhQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQgZGF0ZTogPC9iPlR1ZXNk YXksIDUgTWF5IDIwMjAgYXQgMjIuMTA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmxpbmUuLi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTWF5IDUsIDIwMjAgYXQg Mjo0NiBQTSBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgJmx0OzxhIGhyZWY9Im1haWx0 bzpub3JlcGx5QGlldGYub3JnIj5ub3JlcGx5QGlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBm b2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWlldGYtc2lwY29yZS1zaXAt dG9rZW4tYXV0aG56LTE1OiBEaXNjdXNzPGJyPg0KPGJyPg0KV2hlbiByZXNwb25kaW5nLCBwbGVh c2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsPGJyPg0KZW1h aWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUg dG8gY3V0IHRoaXM8YnI+DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLik8YnI+DQo8 YnI+DQo8YnI+DQpQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv aWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiB0YXJnZXQ9Il9ibGFuayI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWw8 L2E+PGJyPg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01N RU5UIHBvc2l0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGgg b3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10 b2tlbi1hdXRobnovIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnovPC9hPjxicj4NCjxicj4N Cjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpESVNDVVNTOjxicj4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS08YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSB1cGRhdGVzIGluIHRoZSAtMTQgKGFuZCAtMTUp OyB0aGV5IGNvdmVyIG1vc3Qgb2YgbXkgcG9pbnRzLjxicj4NCjxicj4NClVuZm9ydHVuYXRlbHks IHRoZSBuZXcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dCBzZWVtcyB0byBpbnRyb2R1Y2Ug YTxicj4NCnByb2JsZW1hdGljIHJlY29tbWVuZGF0aW9uOjxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtCZWNhdXNlIG9mIHRoYXQsIGl0IGlzIGNyaXRpY2FsIHRvIG1ha2Ugc3VyZSB0aGF0IGV4dHJh IHNlY3VyaXR5PGJyPg0KJm5ic3A7ICZuYnNwO21lYXN1cmVzIGJlIHRha2VuIHRvIHNhZmVndWFy ZCBjcmVkZW50aWFscyB1c2VkIGZvciBTaW5nbGUgU2lnbi1Pbi48YnI+DQombmJzcDsgJm5ic3A7 RXhhbXBsZXMgb2Ygc3VjaCBtZWFzdXJlcyBpbmNsdWRlIGxvbmcgcGFzc3BocmFzZSBpbnN0ZWFk IG9mIGE8YnI+DQombmJzcDsgJm5ic3A7cGFzc3dvcmQsIGVuYWJsaW5nIG11bHRpLWZhY3RvciBm YWN0b3IgYXV0aGVudGljYXRpb24sIGFuZCB0aGUgdXNlIG9mPGJyPg0KJm5ic3A7ICZuYnNwO2Vt YmVkZGVkIGJyb3dzZXIgd2hlbiBwb3NzaWJsZSwgYXMgZGVmaW5lZCBpbiBbUkZDODI1Ml0uPGJy Pg0KPGJyPg0KTG9va2luZyBhdCBSRkMgODI1MiAoU2VjdGlvbiA4LjEyKSwgaXQgc2VlbXMgdG8g YmUgcmF0aGVyIHN0cm9uZ2x5IHJlY29tbWVuZGluZzxicj4NCnRvICpub3QqIHVzZSBhbiBlbWJl ZGRlZCBicm93c2VyLCB3aGljaCBpcyB0aGUgb3Bwb3NpdGUgb2YgdGhlIGFwcGFyZW50PGJyPg0K cmVjb21tZW5kYXRpb24gaGVyZS4mbmJzcDsgQXJlIHdlIG1pc3NpbmcgYSB3b3JkICZxdW90O2F2 b2lkaW5nJnF1b3Q7IG9yIHNpbWlsYXI/PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCB0aGlzIHNob3VsZCBoYXZlIGJlZW4g JnF1b3Q7YnJvd3NlciZxdW90OyBub3QgJnF1b3Q7ZW1iZWRkZWQgYnJvd3NlciZxdW90Oy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIHdpbGwg cmVtb3ZlIHRoZSAmcXVvdDtlbWJlZGRlZCBicm93c2VyJnF1b3Q7IGFuZCByZXBsYWNlIGl0IHdp dGggJnF1b3Q7dGhlIG5hdGl2ZSBwbGF0Zm9ybSBicm93c2VyJnF1b3Q7LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIEkg YW0gbm90IDEwMCUgc3VyZSBteSBub3RlIGFib3V0IHJlZnJlc2ggdG9rZW5zIHdhcyBmdWxseSBh ZGRyZXNzZWQ7PGJyPg0KaW4gU2VjdGlvbiAyLjEuMSB3ZSBzZWU6PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwO1RoZSByZWZyZXNoIHRva2VuIGlzIG9ubHkgdXNlZCBiZXR3ZWVuIHRoZSBVQUMgYW5k IHRoZSBBUy4mbmJzcDsgSWYgdGhlIEFTPGJyPg0KJm5ic3A7ICZuYnNwO3Byb3ZpZGVzIGEgcmVm cmVzaCB0b2tlbiB0byB0aGUgVUFDLCB0aGUgVUFDIHVzZXMgaXQgdG8gcmVxdWVzdCBhIG5ldzxi cj4NCiZuYnNwOyAmbmJzcDthY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2ggdG9rZW4gZnJvbSB0aGUg QVMgYmVmb3JlIHRoZSBjdXJyZW50bHkgdXNlZDxicj4NCiZuYnNwOyAmbmJzcDthY2Nlc3MgdG9r ZW4gZXhwaXJlcyAoW1JGQzY3NDldLCBTZWN0aW9uIDEuNSkuJm5ic3A7IElmIHRoZSBBUyBkb2Vz IG5vdDxicj4NCjxicj4NCklzIGl0IGFjY3VyYXRlIHRvIHNheSB0aGF0IHRoZSByZWZyZXNoIHRv a2VuIGlzIHVzZWQgJnF1b3Q7dG8gcmVxdWVzdCBhIG5ldyBhY2Nlc3M8YnI+DQp0b2tlbiBhbmQg cmVmcmVzaCB0b2tlbiZxdW90OyAoc3BlY2lmaWNhbGx5IHRoZSAmcXVvdDthbmQgcmVmcmVzaCB0 b2tlbiZxdW90OyBwYXJ0KT8mbmJzcDsgSSBrbm93IHRoYXQ8YnI+DQppdCBpcyBub3QgYWx3YXlz IHJldHVybmVkLCBidXQgYW0gbGVzcyBzdXJlIGFib3V0IHdoZXRoZXIgdGhlIHNlbWFudGljcyBh bHdheXM8YnI+DQppbmNsdWRlIGFuIChpbXBsaWNpdCkgcmVxdWVzdCBmb3IgYSBuZXcgb25lLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+UmV0dXJuaW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBiYXNlZCBvbiBBUyBwb2xpY3ku PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSB3 aWxsIHJlbW92ZSB0aGUgJnF1b3Q7YW5kIHJlZnJlc2ggdG9rZW4mcXVvdDsuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1s ZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KQ09NTUVOVDo8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KU29tZSBvdGhlciBjb21tZW50cyBvbiB0aGUg bmV3IHRleHQgdGhhdCBkbyBub3QgcmlzZSB0byBEaXNjdXNzLWxldmVsLjxicj4NCjxicj4NClRo YW5rcyBmb3IgYWRkaW5nIHRoZSBtZW50aW9uIG9mIGEgd2hpdGVsaXN0IG9mIHRydXN0ZWQgQVNl czsgSSB3b3VsZCBjb25zaWRlcjxicj4NCmFsc28gbWVudGlvbmluZyBpdCBpbiBTZWN0aW9uIDQg Zm9yIHRoZSBhdXRoel9zZXJ2ZXIgcGFyYW1ldGVyLCBhbmQvb3IgaW4gdGhlPGJyPg0Kc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCBhZGQgdGhhdCB0byB0aGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbiBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSBh bHNvIHdvdWxkIGhhdmUgbGlrZWQgdG8gc2VlIHNvbWUgZ3VpZGFuY2UgYWJvdXQgd2hlbiBvbmUg c2hvdWxkL3Nob3VsZG4ndDxicj4NCmluY2x1ZGUgdGhlIHJlYWxtIHBhcmFtZXRlciBpbiBhIGNo YWxsZW5nZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgaXMgb3V0IG9mIHNjb3BlLCBhcyB3ZSBhcmUgbm90IHVw ZGF0aW5nIG9yIGNoYW5naW5nIHRoZSBleGlzdGluZyBTSVAgYmVoYXZpb3Igb24gdGhpcyBpc3N1 ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNlY3Rpb24gMi4xLjE8YnI+DQo8 YnI+DQombmJzcDsgJm5ic3A7VUFDIGNvbnRhY3RzIHRoZSBBUyBpbiBvcmRlciB0byBvYnRhaW4g dG9rZW5zLCBhbmQgaW5jbHVkZXMgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3JlcXVlc3RlZCBzY29w ZXMsIGJhc2VkIG9uIGEgbG9jYWwgY29uZmlndXJhdGlvbiAoRmlndXJlIDEpLiZuYnNwOyBUaGUg VUFDPGJyPg0KJm5ic3A7ICZuYnNwO01VU1QgY2hlY2sgdGhlIEFTIFVSTCByZWNlaXZlZCBpbiB0 aGUgNDAxLzQwNyByZXNwb25zZSBhZ2FpbnN0IGEgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDtvZiB0 cnVzdGVkIEFTcyBjb25maWd1cmVkIG9uIHRoZSBVQUMsIGluIG9yZGVyIHRvIHByZXZlbnQgc2V2 ZXJhbDxicj4NCiZuYnNwOyAmbmJzcDtjbGFzc2VzIG9mIHBvc3NpYmxlIHZ1bG5lcmFiaWxpdGll cyB3aGVuIGEgY2xpZW50IGJsaW5kbHkgYXR0ZW1wdCB0bzxicj4NCiZuYnNwOyAmbmJzcDt1c2Ug YW55IHByb3ZpZGVkIGF1dGhvcml6YXRpb24uPGJyPg0KPGJyPg0Kbml0czogJnF1b3Q7YXR0ZW1w dHMmcXVvdDssIGFuZCBtYXliZSAmcXVvdDthbnkgcHJvdmlkZWQgYXV0aG9yaXphdGlvbiBzZXJ2 ZXImcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+V2lsbCBmaXggaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5T ZWN0aW9uIDM8YnI+DQo8YnI+DQpuaXQ6IHMvY2xhaW1lcy9jbGFpbXMvPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2lsbCBmaXggaXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNlY3Rpb24gNTxicj4NCjxicj4NCiZu YnNwOyAmbmJzcDtXaGVuIGEgcmVnaXN0cmFyIGNob29zZXMgdG8gY2hhbGxlbmdlIGEgUkVHSVNU RVIgcmVxdWVzdCwgaWYgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3JlZ2lzdHJhciBjYW4gcHJvdmlk ZSBhY2Nlc3MgdG8gZGlmZmVyZW50IGxldmVscyBvZiBzZXJ2aWNlcywgaXQgaXM8YnI+DQombmJz cDsgJm5ic3A7UkVDT01NRU5ERUQgdGhhdCB0aGUgcmVnaXN0cmFyIGluY2x1ZGVzIGEgc2NvcGUg aW4gdGhlIHJlc3BvbnNlIGluPGJyPg0KJm5ic3A7ICZuYnNwO29yZGVyIHRvIGluZGljYXRlIHRo ZSBtaW5pbXVtIHNjb3BlIG5lZWRlZCB0byByZWdpc3RlciBhbmQgYWNjZXNzPGJyPg0KJm5ic3A7 ICZuYnNwO2Jhc2ljIHNlcnZpY2VzLiZuYnNwOyBUaGUgYWNjZXNzIHRva2VuIG1pZ2h0IGluY2x1 ZGUgYW4gZXh0ZW5kZWQgc2NvcGU8YnI+DQombmJzcDsgJm5ic3A7dGhhdCBnaXZlcyB0aGUgdXNl ciBhY2Nlc3MgdG8gbW9yZSBhZHZhbmNlZCBmZWF0dXJlcyBiZXlvbmQgYmFzaWM8YnI+DQombmJz cDsgJm5ic3A7c2VydmljZXMuPGJyPg0KPGJyPg0KSXMgdGhlcmUgYW55dGhpbmcgdG8gc2F5IGFi b3V0IGhvdyB0aGUgYnJvYWRlciBzY29wZSB2YWx1ZSBtaWdodCBiZSBsZWFybmVkPzxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIFNJ UCwgaXQgaXMgdHlwaWNhbGx5IGNvbnRyb2xsZWQgYnkgdGhlIGFkbWluLCB0aGF0IGNvbnRyb2xz IHRoZSBBUywgYW5kIGRpY3RhdGVzIHRoZSBsZXZlbCBvZiBhY2Nlc3MgZm9yIHRoZSB1c2VyLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2ls bCBhZGQgYSBzZW50ZW5jZSB0byB0aGF0IGV4dGVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1JpZmFhdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_4B261B27F8664EE69DA618BE24D34FB6ericssoncom_-- From nobody Tue May 5 12:31:49 2020 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 34E863A093B; Tue, 5 May 2020 12:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 hQzv1gndxqwp; Tue, 5 May 2020 12:31:41 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2051.outbound.protection.outlook.com [40.107.20.51]) (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 2AD413A0934; Tue, 5 May 2020 12:31:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EhidC39RA7R28mOp/3o73M3tpcr1ypYCF1CqHehLqD/oU+msqwGAS//P4wWIqTinbWoKnkTAOhAY8Zb8wAoBMFJ7VQkMn+H5a8V4zSxtqFbp9gniMe5ik4WvnATG2HGOaAXI8tEsjQ8u2Bu10vp1ARAnOfw8NMfN2b1zgxLU47upuItN5dTkdo3foO/LIZEGaO0gpdZLk76sd2AY+uGh8FZnjTSIDkO1Xt08hT6WliOQ0OQihUzamwv+LVh0cqW6Pu7nFkY5uUM56jr5KCqDwlTPbS2SuS2Af8wA1O/0wgs9FKBOIvRApDbDMVlJBKpNYjHT30Rd1eBLL5Hl4iG4mQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BvtQvm87Q+kFEeFBwucIhrW2Kw4HgVivUiGaNJUk4t8=; b=jnrerhYNHdEkFk1cn8EwJ2JQ4sGzPGLFao6ZgMCMUbWpkIIu/6hUHM5cF/iI9ol4rbRz6oUmOYUnCKxGBTlJuCXtqCYdDnXzDucfwaWxht5oZpGs2bIEvyr6EVq/zpQ14Spbi5eA3UIPb8iDZ/Luuec0M64ju1ceiVF/vGNH9OOg4aafBCjernzF5Qgady7bQ9h8B1hxb9ymMGlNVLq0H30C/wPMs310mIXCEg5FYfM8fx+kAUs8Ur2WGeSto80qkQVzPTBI4ee7f+E3rrvs1ft74l0ymqBeeT0YNqiC1TuwBkOgzJ4vog7BhdhDfdGBO5IYjBWA+DbGEJlJRVL3lQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BvtQvm87Q+kFEeFBwucIhrW2Kw4HgVivUiGaNJUk4t8=; b=pWdTlwxuBImdzsRa1mX9fQFLb8zC9yWD4lqy4yX9N8YQ7dBp/4TYt8OIgQzkkoaf+WiC4Bz0cJv33u4m5+lWaJz7jHrWhMpIogCMZt5cyj6XZ8VG3u/hUMvT7kB2m2hCWU/RVAjZc2/iaeqwQdIESFRfl9/9o/6kF15OVBNTYW0= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6754.eurprd07.prod.outlook.com (2603:10a6:20b:1b4::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Tue, 5 May 2020 19:31:37 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::4c:e502:13cf:87a8%4]) with mapi id 15.20.2979.025; Tue, 5 May 2020 19:31:37 +0000 From: Christer Holmberg To: Rifaat Shekh-Yusef , Benjamin Kaduk CC: The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Thread-Topic: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) - the pull request Thread-Index: AQHWIxPLPYWUKpnVIEeXm15v0L16bA== Date: Tue, 5 May 2020 19:31:37 +0000 Message-ID: <70D8F1BE-9596-4407-9C20-550449863330@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.216.230.200] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a7ac823-8e4e-4e76-0be9-08d7f12aedb0 x-ms-traffictypediagnostic: AM7PR07MB6754: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PkzowKGQzIgG0ch8BAnmHiffrVbJ6efIopeKg9f5Wpprxzm5ixwuaFiE2i52dpNRzlIEq9DT+M8Vb0zRQxPlUi5ftHlrsdHGHNMVDta8XoLD61kato0ZZRtWtbz91iUjx6nSQIoBIfYP9fjjVGIxQuZXPRhXcBp2qnRtEDnBgdp5QxHui+IWWHcpLh0Y5nffcmYlaw/a3KoUZDpVjxpql4up+KtX9m7kdLuJ/CGh1KGZFQ+/5d1pYXvNwwCO6HFp56ZnPgcxeKIcxtQyQpT36Zuctfa6GN1biEJq1mw3PbXKV5lys/j67wBeDt236FTNgxMJI+1FjGkLjN2AwPrnA4KM1X14jvb5h4lYdc39zDJa88chFgemjvquADjWFxilVceWGV8v8FlALg+zpSFrNFWLnFIu0GzoZVcDnbtg4GmTt7R8Y3LWnRd15zdrcVX2Qb8MDsSFvT4gtIViFcollMLC8Ry86n1XoWBEtG/Fhy5y5WNm97A3zbHDhhYEXiZ7YGCEg9WW7FrpFAlduNkUurC4+/g+7GsCTOyrVnR1zI/1ZYwLcNaGflRadzUxwyDaPbD/WPmkDsf2JUratkteLK8MW6Tf6h9pMxTqGLLRvfk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(33430700001)(71200400001)(6486002)(91956017)(2906002)(166002)(33440700001)(6506007)(53546011)(8676002)(66556008)(66446008)(76116006)(66476007)(64756008)(66946007)(8936002)(966005)(33656002)(498600001)(6512007)(36756003)(26005)(186003)(4326008)(66574012)(5660300002)(21615005)(44832011)(86362001)(2616005)(54906003)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: f1Neg1NdXp6YwttleRXCR/PnTW4GjAQh7vWSfIeKqvJ3z3cb7vkKCDrK+jkJk3iafUjEpaiuikV/pnFMxObqHrOboD2JRwFV7FP8PqKmdx5DyMFHtQ8Goxp3uXYwgk+9v3HACbpRb/GHrYjh4/XKL+5vgFsMpkaOtmSZhBHoQv2YkAYMe3WrxOlXW8uMf9FRo2YWZnAZjk35UCQIBsW3PoRwVMLMJ+QxRAgNBNpDom+4Uuvls3kLqkF3vEnG9ckjVHf9hK3fxA9+2/apL8EUN0Ep8J3vikzuFfOlYOIo5eHmN7YFNWS6W6JA5+xN2Dvy4lMKtJUKzDk2dqf7ED2dcQxndznLQYxokNwF4XiCC0DWmZgAriS2xQE5dmO68DjHHrCT+u0ia4L0VBlMK7QTAd1Fiu6AcQjZIeMK+Daq39q3P/A4u+/f3yfOSs8lQfcCgQlfgOp3S/ac6qUQ4kSdOShwirREoJJTR2JKAcZVlk4HsQ1XnqjbDUoqrA6Yttws9OnrDM7XPC1eNFpzfXlwYSLpeYcfrmGu70w6WuZP4n8c7aI3k3kDl80c9jzMJTw0l33OsB1pDiMfh9RApHOOKDzrdWzFA2KmFJ9nQtB0BKErEldjBt//4I/qi5bWo2gh0yH+td1lTM/fVCtqQ2rqKWyocF+eeWtWb2iAAkx+InDqyFTSNIhVjoLbbN9k9ssct/fp6DQGvEjSvZ6E5/JC9Q5ysZNq6W+dkUDIgp8sjSFxS5Dtp6XsIipegwdCutdc6fJAKK/N/w+Src0uY1nAGSLWD4uNjSbCJ9WumAN/CUUf07aOHkinCft5bxx5A0u7 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_70D8F1BE959644079C20550449863330ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a7ac823-8e4e-4e76-0be9-08d7f12aedb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 19:31:37.3817 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Ay2zmwiTgYvWfFz+Ecic9DsBECXoTntNUS7QbXKPn03S5MJTCi4cAbXFfpyzQ4cn3JEfi7le5CIgZkY/6lPiZYddyogfgVYeZCD/ZhBsac0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6754 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 19:31:46 -0000 --_000_70D8F1BE959644079C20550449863330ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJhc2VkIG9uIEJlbmphbWlu4oCZcyBjb21tZW50cywgSSBjcmVhdGVkIGEgbmV3IHB1 bGwgcmVxdWVzdDoNCg0KaHR0cHM6Ly9naXRodWIuY29tL3JpZmFhdC1pZXRmL2RyYWZ0LWlldGYt c2lwY29yZS1zaXAtdG9rZW4tYXV0aG56L3B1bGwvOQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCkZyb206IFJpZmFhdCBTaGVraC1ZdXNlZiA8cmlmYWF0LmlldGZAZ21haWwuY29tPg0KRGF0 ZTogVHVlc2RheSwgNSBNYXkgMjAyMCBhdCAyMi4xMA0KVG86IEJlbmphbWluIEthZHVrIDxrYWR1 a0BtaXQuZWR1Pg0KQ2M6ICJpZXNnQGlldGYub3JnIiA8aWVzZ0BpZXRmLm9yZz4sICJkcmFmdC1p ZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1dGhuekBpZXRmLm9yZyIgPGRyYWZ0LWlldGYtc2lwY29y ZS1zaXAtdG9rZW4tYXV0aG56QGlldGYub3JnPiwgInNpcGNvcmUtY2hhaXJzQGlldGYub3JnIiA8 c2lwY29yZS1jaGFpcnNAaWV0Zi5vcmc+LCAic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVAaWV0 Zi5vcmc+LCAiQS4gTWFob25leSIgPG1haG9uZXlAbm9zdHJ1bS5jb20+DQpTdWJqZWN0OiBSZTog QmVuamFtaW4gS2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4t YXV0aG56LTE1OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKQ0KUmVzZW50IGZyb206IDxhbGlh cy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50IHRvOiBSaWZhYXQgU2hla2gtWXVzZWYgPHJpZmFh dC5pZXRmQGdtYWlsLmNvbT4sIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZ0Bl cmljc3Nvbi5jb20+LCBWaWN0b3IgUGFzY3VhbCA8dmljdG9yLnBhc2N1YWwuYXZpbGFAZ21haWwu Y29tPg0KUmVzZW50IGRhdGU6IFR1ZXNkYXksIDUgTWF5IDIwMjAgYXQgMjIuMTANCg0KSW5saW5l Li4uDQoNCk9uIFR1ZSwgTWF5IDUsIDIwMjAgYXQgMjo0NiBQTSBCZW5qYW1pbiBLYWR1ayB2aWEg RGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc8bWFpbHRvOm5vcmVwbHlAaWV0Zi5vcmc+PiB3 cm90ZToNCkJlbmphbWluIEthZHVrIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBv c2l0aW9uIGZvcg0KZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnotMTU6IERpc2N1 c3MNCg0KV2hlbiByZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFj dCBhbmQgcmVwbHkgdG8gYWxsDQplbWFpbCBhZGRyZXNzZXMgaW5jbHVkZWQgaW4gdGhlIFRvIGFu ZCBDQyBsaW5lcy4gKEZlZWwgZnJlZSB0byBjdXQgdGhpcw0KaW50cm9kdWN0b3J5IHBhcmFncmFw aCwgaG93ZXZlci4pDQoNCg0KUGxlYXNlIHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2ll c2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KZm9yIG1vcmUgaW5mb3JtYXRpb24g YWJvdXQgSUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCg0KDQpUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXNpcGNvcmUtc2lw LXRva2VuLWF1dGhuei8NCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NVU1M6DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNClRoYW5rcyBmb3IgdGhlIHVwZGF0ZXMgaW4gdGhlIC0xNCAoYW5kIC0xNSk7IHRoZXkg Y292ZXIgbW9zdCBvZiBteSBwb2ludHMuDQoNClVuZm9ydHVuYXRlbHksIHRoZSBuZXcgc2VjdXJp dHkgY29uc2lkZXJhdGlvbnMgdGV4dCBzZWVtcyB0byBpbnRyb2R1Y2UgYQ0KcHJvYmxlbWF0aWMg cmVjb21tZW5kYXRpb246DQoNCiAgIEJlY2F1c2Ugb2YgdGhhdCwgaXQgaXMgY3JpdGljYWwgdG8g bWFrZSBzdXJlIHRoYXQgZXh0cmEgc2VjdXJpdHkNCiAgIG1lYXN1cmVzIGJlIHRha2VuIHRvIHNh ZmVndWFyZCBjcmVkZW50aWFscyB1c2VkIGZvciBTaW5nbGUgU2lnbi1Pbi4NCiAgIEV4YW1wbGVz IG9mIHN1Y2ggbWVhc3VyZXMgaW5jbHVkZSBsb25nIHBhc3NwaHJhc2UgaW5zdGVhZCBvZiBhDQog ICBwYXNzd29yZCwgZW5hYmxpbmcgbXVsdGktZmFjdG9yIGZhY3RvciBhdXRoZW50aWNhdGlvbiwg YW5kIHRoZSB1c2Ugb2YNCiAgIGVtYmVkZGVkIGJyb3dzZXIgd2hlbiBwb3NzaWJsZSwgYXMgZGVm aW5lZCBpbiBbUkZDODI1Ml0uDQoNCkxvb2tpbmcgYXQgUkZDIDgyNTIgKFNlY3Rpb24gOC4xMiks IGl0IHNlZW1zIHRvIGJlIHJhdGhlciBzdHJvbmdseSByZWNvbW1lbmRpbmcNCnRvICpub3QqIHVz ZSBhbiBlbWJlZGRlZCBicm93c2VyLCB3aGljaCBpcyB0aGUgb3Bwb3NpdGUgb2YgdGhlIGFwcGFy ZW50DQpyZWNvbW1lbmRhdGlvbiBoZXJlLiAgQXJlIHdlIG1pc3NpbmcgYSB3b3JkICJhdm9pZGlu ZyIgb3Igc2ltaWxhcj8NCg0KWWVhaCwgdGhpcyBzaG91bGQgaGF2ZSBiZWVuICJicm93c2VyIiBu b3QgImVtYmVkZGVkIGJyb3dzZXIiLg0KV2Ugd2lsbCByZW1vdmUgdGhlICJlbWJlZGRlZCBicm93 c2VyIiBhbmQgcmVwbGFjZSBpdCB3aXRoICJ0aGUgbmF0aXZlIHBsYXRmb3JtIGJyb3dzZXIiLg0K DQoNCkFsc28sIEkgYW0gbm90IDEwMCUgc3VyZSBteSBub3RlIGFib3V0IHJlZnJlc2ggdG9rZW5z IHdhcyBmdWxseSBhZGRyZXNzZWQ7DQppbiBTZWN0aW9uIDIuMS4xIHdlIHNlZToNCg0KICAgVGhl IHJlZnJlc2ggdG9rZW4gaXMgb25seSB1c2VkIGJldHdlZW4gdGhlIFVBQyBhbmQgdGhlIEFTLiAg SWYgdGhlIEFTDQogICBwcm92aWRlcyBhIHJlZnJlc2ggdG9rZW4gdG8gdGhlIFVBQywgdGhlIFVB QyB1c2VzIGl0IHRvIHJlcXVlc3QgYSBuZXcNCiAgIGFjY2VzcyB0b2tlbiBhbmQgcmVmcmVzaCB0 b2tlbiBmcm9tIHRoZSBBUyBiZWZvcmUgdGhlIGN1cnJlbnRseSB1c2VkDQogICBhY2Nlc3MgdG9r ZW4gZXhwaXJlcyAoW1JGQzY3NDldLCBTZWN0aW9uIDEuNSkuICBJZiB0aGUgQVMgZG9lcyBub3QN Cg0KSXMgaXQgYWNjdXJhdGUgdG8gc2F5IHRoYXQgdGhlIHJlZnJlc2ggdG9rZW4gaXMgdXNlZCAi dG8gcmVxdWVzdCBhIG5ldyBhY2Nlc3MNCnRva2VuIGFuZCByZWZyZXNoIHRva2VuIiAoc3BlY2lm aWNhbGx5IHRoZSAiYW5kIHJlZnJlc2ggdG9rZW4iIHBhcnQpPyAgSSBrbm93IHRoYXQNCml0IGlz IG5vdCBhbHdheXMgcmV0dXJuZWQsIGJ1dCBhbSBsZXNzIHN1cmUgYWJvdXQgd2hldGhlciB0aGUg c2VtYW50aWNzIGFsd2F5cw0KaW5jbHVkZSBhbiAoaW1wbGljaXQpIHJlcXVlc3QgZm9yIGEgbmV3 IG9uZS4NCg0KUmV0dXJuaW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBiYXNlZCBvbiBBUyBwb2xpY3ku DQpXZSB3aWxsIHJlbW92ZSB0aGUgImFuZCByZWZyZXNoIHRva2VuIi4NCg0KDQoNCi0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCkNPTU1FTlQ6DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClNvbWUgb3RoZXIgY29tbWVudHMgb24g dGhlIG5ldyB0ZXh0IHRoYXQgZG8gbm90IHJpc2UgdG8gRGlzY3Vzcy1sZXZlbC4NCg0KVGhhbmtz IGZvciBhZGRpbmcgdGhlIG1lbnRpb24gb2YgYSB3aGl0ZWxpc3Qgb2YgdHJ1c3RlZCBBU2VzOyBJ IHdvdWxkIGNvbnNpZGVyDQphbHNvIG1lbnRpb25pbmcgaXQgaW4gU2VjdGlvbiA0IGZvciB0aGUg YXV0aHpfc2VydmVyIHBhcmFtZXRlciwgYW5kL29yIGluIHRoZQ0Kc2VjdXJpdHkgY29uc2lkZXJh dGlvbnMuDQpXZSB3aWxsIGFkZCB0aGF0IHRvIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl Y3Rpb24uDQoNCg0KSSBhbHNvIHdvdWxkIGhhdmUgbGlrZWQgdG8gc2VlIHNvbWUgZ3VpZGFuY2Ug YWJvdXQgd2hlbiBvbmUgc2hvdWxkL3Nob3VsZG4ndA0KaW5jbHVkZSB0aGUgcmVhbG0gcGFyYW1l dGVyIGluIGEgY2hhbGxlbmdlLg0KSSB0aGluayB0aGlzIGlzIG91dCBvZiBzY29wZSwgYXMgd2Ug YXJlIG5vdCB1cGRhdGluZyBvciBjaGFuZ2luZyB0aGUgZXhpc3RpbmcgU0lQIGJlaGF2aW9yIG9u IHRoaXMgaXNzdWUuDQoNCg0KU2VjdGlvbiAyLjEuMQ0KDQogICBVQUMgY29udGFjdHMgdGhlIEFT IGluIG9yZGVyIHRvIG9idGFpbiB0b2tlbnMsIGFuZCBpbmNsdWRlcyB0aGUNCiAgIHJlcXVlc3Rl ZCBzY29wZXMsIGJhc2VkIG9uIGEgbG9jYWwgY29uZmlndXJhdGlvbiAoRmlndXJlIDEpLiAgVGhl IFVBQw0KICAgTVVTVCBjaGVjayB0aGUgQVMgVVJMIHJlY2VpdmVkIGluIHRoZSA0MDEvNDA3IHJl c3BvbnNlIGFnYWluc3QgYSBsaXN0DQogICBvZiB0cnVzdGVkIEFTcyBjb25maWd1cmVkIG9uIHRo ZSBVQUMsIGluIG9yZGVyIHRvIHByZXZlbnQgc2V2ZXJhbA0KICAgY2xhc3NlcyBvZiBwb3NzaWJs ZSB2dWxuZXJhYmlsaXRpZXMgd2hlbiBhIGNsaWVudCBibGluZGx5IGF0dGVtcHQgdG8NCiAgIHVz ZSBhbnkgcHJvdmlkZWQgYXV0aG9yaXphdGlvbi4NCg0Kbml0czogImF0dGVtcHRzIiwgYW5kIG1h eWJlICJhbnkgcHJvdmlkZWQgYXV0aG9yaXphdGlvbiBzZXJ2ZXIiLg0KV2lsbCBmaXggaXQNCg0K U2VjdGlvbiAzDQoNCm5pdDogcy9jbGFpbWVzL2NsYWltcy8NCldpbGwgZml4IGl0DQoNCg0KU2Vj dGlvbiA1DQoNCiAgIFdoZW4gYSByZWdpc3RyYXIgY2hvb3NlcyB0byBjaGFsbGVuZ2UgYSBSRUdJ U1RFUiByZXF1ZXN0LCBpZiB0aGUNCiAgIHJlZ2lzdHJhciBjYW4gcHJvdmlkZSBhY2Nlc3MgdG8g ZGlmZmVyZW50IGxldmVscyBvZiBzZXJ2aWNlcywgaXQgaXMNCiAgIFJFQ09NTUVOREVEIHRoYXQg dGhlIHJlZ2lzdHJhciBpbmNsdWRlcyBhIHNjb3BlIGluIHRoZSByZXNwb25zZSBpbg0KICAgb3Jk ZXIgdG8gaW5kaWNhdGUgdGhlIG1pbmltdW0gc2NvcGUgbmVlZGVkIHRvIHJlZ2lzdGVyIGFuZCBh Y2Nlc3MNCiAgIGJhc2ljIHNlcnZpY2VzLiAgVGhlIGFjY2VzcyB0b2tlbiBtaWdodCBpbmNsdWRl IGFuIGV4dGVuZGVkIHNjb3BlDQogICB0aGF0IGdpdmVzIHRoZSB1c2VyIGFjY2VzcyB0byBtb3Jl IGFkdmFuY2VkIGZlYXR1cmVzIGJleW9uZCBiYXNpYw0KICAgc2VydmljZXMuDQoNCklzIHRoZXJl IGFueXRoaW5nIHRvIHNheSBhYm91dCBob3cgdGhlIGJyb2FkZXIgc2NvcGUgdmFsdWUgbWlnaHQg YmUgbGVhcm5lZD8NCkluIFNJUCwgaXQgaXMgdHlwaWNhbGx5IGNvbnRyb2xsZWQgYnkgdGhlIGFk bWluLCB0aGF0IGNvbnRyb2xzIHRoZSBBUywgYW5kIGRpY3RhdGVzIHRoZSBsZXZlbCBvZiBhY2Nl c3MgZm9yIHRoZSB1c2VyLg0KV2Ugd2lsbCBhZGQgYSBzZW50ZW5jZSB0byB0aGF0IGV4dGVudC4N Cg0KUmVnYXJkcywNCiBSaWZhYXQNCg0K --_000_70D8F1BE959644079C20550449863330ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgMi4wY20gNzAuODVw dCAyLjBjbTt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPkJhc2VkIG9uIEJlbmphbWlu4oCZcyBjb21tZW50cywgSSBjcmVhdGVkIGEgbmV3IHB1bGwg cmVxdWVzdDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vcmlmYWF0LWlldGYvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1h dXRobnovcHVsbC85Ij48c3BhbiBsYW5nPSJFTi1VUyI+aHR0cHM6Ly9naXRodWIuY29tL3JpZmFh dC1pZXRmL2RyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56L3B1bGwvOTwvc3Bhbj48 L2E+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJl Z2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+UmlmYWF0IFNoZWtoLVl1c2VmICZs dDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlR1ZXNkYXksIDUg TWF5IDIwMjAgYXQgMjIuMTA8YnI+DQo8Yj5UbzogPC9iPkJlbmphbWluIEthZHVrICZsdDtrYWR1 a0BtaXQuZWR1Jmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7aWVzZ0BpZXRmLm9yZyZxdW90OyAm bHQ7aWVzZ0BpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4t YXV0aG56QGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1 dGhuekBpZXRmLm9yZyZndDssICZxdW90O3NpcGNvcmUtY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZs dDtzaXBjb3JlLWNoYWlyc0BpZXRmLm9yZyZndDssICZxdW90O3NpcGNvcmVAaWV0Zi5vcmcmcXVv dDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtBLiBNYWhvbmV5JnF1b3Q7ICZsdDtt YWhvbmV5QG5vc3RydW0uY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogQmVuamFtaW4g S2FkdWsncyBEaXNjdXNzIG9uIGRyYWZ0LWlldGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTE1 OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5UKTxicj4NCjxiPlJlc2VudCBmcm9tOiA8L2I+Jmx0 O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+UmVzZW50IHRvOiA8L2I+UmlmYWF0 IFNoZWtoLVl1c2VmICZsdDtyaWZhYXQuaWV0ZkBnbWFpbC5jb20mZ3Q7LCBDaHJpc3RlciBIb2xt YmVyZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmdAZXJpY3Nzb24uY29tJmd0OywgVmljdG9yIFBhc2N1 YWwgJmx0O3ZpY3Rvci5wYXNjdWFsLmF2aWxhQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQg ZGF0ZTogPC9iPlR1ZXNkYXksIDUgTWF5IDIwMjAgYXQgMjIuMTA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmxpbmUu Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg TWF5IDUsIDIwMjAgYXQgMjo0NiBQTSBCZW5qYW1pbiBLYWR1ayB2aWEgRGF0YXRyYWNrZXIgJmx0 OzxhIGhyZWY9Im1haWx0bzpub3JlcGx5QGlldGYub3JnIj5ub3JlcGx5QGlldGYub3JnPC9hPiZn dDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkJlbmphbWluIEthZHVrIGhh cyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcjxicj4NCmRyYWZ0LWll dGYtc2lwY29yZS1zaXAtdG9rZW4tYXV0aG56LTE1OiBEaXNjdXNzPGJyPg0KPGJyPg0KV2hlbiBy ZXNwb25kaW5nLCBwbGVhc2Uga2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkg dG8gYWxsPGJyPg0KZW1haWwgYWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGlu ZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXM8YnI+DQppbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBo b3dldmVyLik8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2UgcmVmZXIgdG8gPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1lbnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sIiB0YXJn ZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVudC9kaXNjdXNz LWNyaXRlcmlhLmh0bWw8L2E+PGJyPg0KZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQgSUVTRyBE SVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgZG9jdW1l bnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6 PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0 Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnovIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1zaXBjb3JlLXNpcC10b2tlbi1hdXRobnov PC9hPjxicj4NCjxicj4NCjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpESVNDVVNTOjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpUaGFua3MgZm9yIHRoZSB1cGRhdGVzIGluIHRo ZSAtMTQgKGFuZCAtMTUpOyB0aGV5IGNvdmVyIG1vc3Qgb2YgbXkgcG9pbnRzLjxicj4NCjxicj4N ClVuZm9ydHVuYXRlbHksIHRoZSBuZXcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgdGV4dCBzZWVt cyB0byBpbnRyb2R1Y2UgYTxicj4NCnByb2JsZW1hdGljIHJlY29tbWVuZGF0aW9uOjxicj4NCjxi cj4NCiZuYnNwOyAmbmJzcDtCZWNhdXNlIG9mIHRoYXQsIGl0IGlzIGNyaXRpY2FsIHRvIG1ha2Ug c3VyZSB0aGF0IGV4dHJhIHNlY3VyaXR5PGJyPg0KJm5ic3A7ICZuYnNwO21lYXN1cmVzIGJlIHRh a2VuIHRvIHNhZmVndWFyZCBjcmVkZW50aWFscyB1c2VkIGZvciBTaW5nbGUgU2lnbi1Pbi48YnI+ DQombmJzcDsgJm5ic3A7RXhhbXBsZXMgb2Ygc3VjaCBtZWFzdXJlcyBpbmNsdWRlIGxvbmcgcGFz c3BocmFzZSBpbnN0ZWFkIG9mIGE8YnI+DQombmJzcDsgJm5ic3A7cGFzc3dvcmQsIGVuYWJsaW5n IG11bHRpLWZhY3RvciBmYWN0b3IgYXV0aGVudGljYXRpb24sIGFuZCB0aGUgdXNlIG9mPGJyPg0K Jm5ic3A7ICZuYnNwO2VtYmVkZGVkIGJyb3dzZXIgd2hlbiBwb3NzaWJsZSwgYXMgZGVmaW5lZCBp biBbUkZDODI1Ml0uPGJyPg0KPGJyPg0KTG9va2luZyBhdCBSRkMgODI1MiAoU2VjdGlvbiA4LjEy KSwgaXQgc2VlbXMgdG8gYmUgcmF0aGVyIHN0cm9uZ2x5IHJlY29tbWVuZGluZzxicj4NCnRvICpu b3QqIHVzZSBhbiBlbWJlZGRlZCBicm93c2VyLCB3aGljaCBpcyB0aGUgb3Bwb3NpdGUgb2YgdGhl IGFwcGFyZW50PGJyPg0KcmVjb21tZW5kYXRpb24gaGVyZS4mbmJzcDsgQXJlIHdlIG1pc3Npbmcg YSB3b3JkICZxdW90O2F2b2lkaW5nJnF1b3Q7IG9yIHNpbWlsYXI/PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ZZWFoLCB0aGlzIHNo b3VsZCBoYXZlIGJlZW4gJnF1b3Q7YnJvd3NlciZxdW90OyBub3QgJnF1b3Q7ZW1iZWRkZWQgYnJv d3NlciZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPldlIHdpbGwgcmVtb3ZlIHRoZSAmcXVvdDtlbWJlZGRlZCBicm93c2VyJnF1b3Q7IGFu ZCByZXBsYWNlIGl0IHdpdGggJnF1b3Q7dGhlIG5hdGl2ZSBwbGF0Zm9ybSBicm93c2VyJnF1b3Q7 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFsc28sIEkgYW0gbm90IDEwMCUgc3VyZSBteSBub3RlIGFib3V0IHJlZnJlc2ggdG9r ZW5zIHdhcyBmdWxseSBhZGRyZXNzZWQ7PGJyPg0KaW4gU2VjdGlvbiAyLjEuMSB3ZSBzZWU6PGJy Pg0KPGJyPg0KJm5ic3A7ICZuYnNwO1RoZSByZWZyZXNoIHRva2VuIGlzIG9ubHkgdXNlZCBiZXR3 ZWVuIHRoZSBVQUMgYW5kIHRoZSBBUy4mbmJzcDsgSWYgdGhlIEFTPGJyPg0KJm5ic3A7ICZuYnNw O3Byb3ZpZGVzIGEgcmVmcmVzaCB0b2tlbiB0byB0aGUgVUFDLCB0aGUgVUFDIHVzZXMgaXQgdG8g cmVxdWVzdCBhIG5ldzxicj4NCiZuYnNwOyAmbmJzcDthY2Nlc3MgdG9rZW4gYW5kIHJlZnJlc2gg dG9rZW4gZnJvbSB0aGUgQVMgYmVmb3JlIHRoZSBjdXJyZW50bHkgdXNlZDxicj4NCiZuYnNwOyAm bmJzcDthY2Nlc3MgdG9rZW4gZXhwaXJlcyAoW1JGQzY3NDldLCBTZWN0aW9uIDEuNSkuJm5ic3A7 IElmIHRoZSBBUyBkb2VzIG5vdDxicj4NCjxicj4NCklzIGl0IGFjY3VyYXRlIHRvIHNheSB0aGF0 IHRoZSByZWZyZXNoIHRva2VuIGlzIHVzZWQgJnF1b3Q7dG8gcmVxdWVzdCBhIG5ldyBhY2Nlc3M8 YnI+DQp0b2tlbiBhbmQgcmVmcmVzaCB0b2tlbiZxdW90OyAoc3BlY2lmaWNhbGx5IHRoZSAmcXVv dDthbmQgcmVmcmVzaCB0b2tlbiZxdW90OyBwYXJ0KT8mbmJzcDsgSSBrbm93IHRoYXQ8YnI+DQpp dCBpcyBub3QgYWx3YXlzIHJldHVybmVkLCBidXQgYW0gbGVzcyBzdXJlIGFib3V0IHdoZXRoZXIg dGhlIHNlbWFudGljcyBhbHdheXM8YnI+DQppbmNsdWRlIGFuIChpbXBsaWNpdCkgcmVxdWVzdCBm b3IgYSBuZXcgb25lLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmV0dXJuaW5nIGEgcmVmcmVzaCB0b2tlbiBpcyBiYXNl ZCBvbiBBUyBwb2xpY3kuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5XZSB3aWxsIHJlbW92ZSB0aGUgJnF1b3Q7YW5kIHJlZnJlc2ggdG9rZW4mcXVv dDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNt IDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQotLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPg0KQ09NTUVOVDo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KPGJyPg0KU29tZSBvdGhlciBj b21tZW50cyBvbiB0aGUgbmV3IHRleHQgdGhhdCBkbyBub3QgcmlzZSB0byBEaXNjdXNzLWxldmVs Ljxicj4NCjxicj4NClRoYW5rcyBmb3IgYWRkaW5nIHRoZSBtZW50aW9uIG9mIGEgd2hpdGVsaXN0 IG9mIHRydXN0ZWQgQVNlczsgSSB3b3VsZCBjb25zaWRlcjxicj4NCmFsc28gbWVudGlvbmluZyBp dCBpbiBTZWN0aW9uIDQgZm9yIHRoZSBhdXRoel9zZXJ2ZXIgcGFyYW1ldGVyLCBhbmQvb3IgaW4g dGhlPGJyPg0Kc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ugd2lsbCBhZGQgdGhhdCB0byB0 aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SSBhbHNvIHdvdWxkIGhhdmUgbGlrZWQgdG8gc2VlIHNvbWUgZ3VpZGFuY2Ug YWJvdXQgd2hlbiBvbmUgc2hvdWxkL3Nob3VsZG4ndDxicj4NCmluY2x1ZGUgdGhlIHJlYWxtIHBh cmFtZXRlciBpbiBhIGNoYWxsZW5nZS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgaXMgb3V0IG9mIHNjb3BlLCBh cyB3ZSBhcmUgbm90IHVwZGF0aW5nIG9yIGNoYW5naW5nIHRoZSBleGlzdGluZyBTSVAgYmVoYXZp b3Igb24gdGhpcyBpc3N1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNlY3Rp b24gMi4xLjE8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VUFDIGNvbnRhY3RzIHRoZSBBUyBpbiBv cmRlciB0byBvYnRhaW4gdG9rZW5zLCBhbmQgaW5jbHVkZXMgdGhlPGJyPg0KJm5ic3A7ICZuYnNw O3JlcXVlc3RlZCBzY29wZXMsIGJhc2VkIG9uIGEgbG9jYWwgY29uZmlndXJhdGlvbiAoRmlndXJl IDEpLiZuYnNwOyBUaGUgVUFDPGJyPg0KJm5ic3A7ICZuYnNwO01VU1QgY2hlY2sgdGhlIEFTIFVS TCByZWNlaXZlZCBpbiB0aGUgNDAxLzQwNyByZXNwb25zZSBhZ2FpbnN0IGEgbGlzdDxicj4NCiZu YnNwOyAmbmJzcDtvZiB0cnVzdGVkIEFTcyBjb25maWd1cmVkIG9uIHRoZSBVQUMsIGluIG9yZGVy IHRvIHByZXZlbnQgc2V2ZXJhbDxicj4NCiZuYnNwOyAmbmJzcDtjbGFzc2VzIG9mIHBvc3NpYmxl IHZ1bG5lcmFiaWxpdGllcyB3aGVuIGEgY2xpZW50IGJsaW5kbHkgYXR0ZW1wdCB0bzxicj4NCiZu YnNwOyAmbmJzcDt1c2UgYW55IHByb3ZpZGVkIGF1dGhvcml6YXRpb24uPGJyPg0KPGJyPg0Kbml0 czogJnF1b3Q7YXR0ZW1wdHMmcXVvdDssIGFuZCBtYXliZSAmcXVvdDthbnkgcHJvdmlkZWQgYXV0 aG9yaXphdGlvbiBzZXJ2ZXImcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2lsbCBmaXggaXQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij5TZWN0aW9uIDM8YnI+DQo8YnI+DQpuaXQ6IHMvY2xhaW1lcy9jbGFpbXMv PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2lsbCBmaXggaXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlNlY3Rpb24g NTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtXaGVuIGEgcmVnaXN0cmFyIGNob29zZXMgdG8gY2hh bGxlbmdlIGEgUkVHSVNURVIgcmVxdWVzdCwgaWYgdGhlPGJyPg0KJm5ic3A7ICZuYnNwO3JlZ2lz dHJhciBjYW4gcHJvdmlkZSBhY2Nlc3MgdG8gZGlmZmVyZW50IGxldmVscyBvZiBzZXJ2aWNlcywg aXQgaXM8YnI+DQombmJzcDsgJm5ic3A7UkVDT01NRU5ERUQgdGhhdCB0aGUgcmVnaXN0cmFyIGlu Y2x1ZGVzIGEgc2NvcGUgaW4gdGhlIHJlc3BvbnNlIGluPGJyPg0KJm5ic3A7ICZuYnNwO29yZGVy IHRvIGluZGljYXRlIHRoZSBtaW5pbXVtIHNjb3BlIG5lZWRlZCB0byByZWdpc3RlciBhbmQgYWNj ZXNzPGJyPg0KJm5ic3A7ICZuYnNwO2Jhc2ljIHNlcnZpY2VzLiZuYnNwOyBUaGUgYWNjZXNzIHRv a2VuIG1pZ2h0IGluY2x1ZGUgYW4gZXh0ZW5kZWQgc2NvcGU8YnI+DQombmJzcDsgJm5ic3A7dGhh dCBnaXZlcyB0aGUgdXNlciBhY2Nlc3MgdG8gbW9yZSBhZHZhbmNlZCBmZWF0dXJlcyBiZXlvbmQg YmFzaWM8YnI+DQombmJzcDsgJm5ic3A7c2VydmljZXMuPGJyPg0KPGJyPg0KSXMgdGhlcmUgYW55 dGhpbmcgdG8gc2F5IGFib3V0IGhvdyB0aGUgYnJvYWRlciBzY29wZSB2YWx1ZSBtaWdodCBiZSBs ZWFybmVkPzxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkluIFNJUCwgaXQgaXMgdHlwaWNhbGx5IGNvbnRyb2xsZWQgYnkgdGhlIGFkbWlu LCB0aGF0IGNvbnRyb2xzIHRoZSBBUywgYW5kIGRpY3RhdGVzIHRoZSBsZXZlbCBvZiBhY2Nlc3Mg Zm9yIHRoZSB1c2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2Ugd2lsbCBhZGQgYSBzZW50ZW5jZSB0byB0aGF0IGV4dGVudC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwO1Jp ZmFhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_70D8F1BE959644079C20550449863330ericssoncom_-- From nobody Tue May 5 14:11:55 2020 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 68F8C3A0B35; Tue, 5 May 2020 14:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 CP1-oIpZVLfu; Tue, 5 May 2020 14:11:50 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 69DBB3A0B33; Tue, 5 May 2020 14:11:50 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id b18so208349ilf.2; Tue, 05 May 2020 14:11:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=39hqFcZbtS6JbxtL8wK7PMDOLohMhiNTe1Q9ygDjQLc=; b=ck7N05NuiTGcLahg48oMVAgXFQN5EcEJ43wX7N8JXHZD8VOOWnY/ZgBHeVIo8N/hkB ftnBXcUmC9IavW//FbJW0HJ1H2/++k+8g2mkzigzbMv9M+BNobaSKvO1eEEeY/0CnZEo DZefwWz0HhB/9/vqVf3qa8NJva5qD47R5HvGxzLVQdMglrYihlh4xOPS1YMYZeTWWXS9 7eIvcw3bzztKGPLGErQrtBhlJKi1KE8v52dqK5VTLuW/qCAV8f9qJ5xi82kLndJf+znF BV5i5yhY3Y4NK/RDcRGahoR9ZIuXelRXA+y+ga4unTtG3U+edlqqdMzLsWdzg/rRNFYw ttfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=39hqFcZbtS6JbxtL8wK7PMDOLohMhiNTe1Q9ygDjQLc=; b=aNWxt4UVALB+8cTKTzGt2Vx/EKz7iEAyHQGwxzWLae2RJ9iIw/ILQEaBsdS6OWOWJ3 HI1m5eabJpRDQXuQMubskoc8pLvM8Tms3CIKm/BnmSPgMQgLt3Bk60d8gMtY0rXWAk9/ 25cFS6XL+mkXEaV5rGrByS98AaqWWrXTRVhK2j6SIeoPEJCUWOGIpLkxQ4umVsEazW5R ETRZfxlSEo2Vg1LVOtOdvE9okTj6GC7zSD1OLMOWYeco+z8eiTlYsVfoCp0De6U6I/k0 HIpEYkiajppvhtVk3Kx0e5XUD1rKmiJ9t7znQW2rGxIJu6qh+ZMTwPOh6pgmsAnB/HtG cC8A== X-Gm-Message-State: AGi0PuYc9IC2pTLfs9TQwfDjnsjQ6pGezkJ7WMSn80TsD6Cem+dqjWV2 kzmaMTszwfyrKQkNCzvgRovplvbOtuXmxJLrVgnxTPO6fauukg== X-Google-Smtp-Source: APiQypLMVhYCGqYPLDeJ+7JuwmBVTfHfkDPhXgTzQ7UJjnF76YFNSgxfJNpafGQy+2oW3BtFdIWpVyJTAK52dSZ7HMs= X-Received: by 2002:a92:c8d0:: with SMTP id c16mr5395480ilq.278.1588713109545; Tue, 05 May 2020 14:11:49 -0700 (PDT) MIME-Version: 1.0 References: <70D8F1BE-9596-4407-9C20-550449863330@ericsson.com> In-Reply-To: <70D8F1BE-9596-4407-9C20-550449863330@ericsson.com> From: Rifaat Shekh-Yusef Date: Tue, 5 May 2020 17:11:38 -0400 Message-ID: To: Christer Holmberg Cc: Benjamin Kaduk , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="0000000000008b692105a4ed1859" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:11:54 -0000 --0000000000008b692105a4ed1859 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ben, Does this pull request address your latest DISCUSS and comments? Regards, Rifaat On Tue, May 5, 2020 at 3:31 PM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > > > Based on Benjamin=E2=80=99s comments, I created a new pull request: > > > > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/9 > > > > Regards, > > > > Christer > > > > > > *From: *Rifaat Shekh-Yusef > *Date: *Tuesday, 5 May 2020 at 22.10 > *To: *Benjamin Kaduk > *Cc: *"iesg@ietf.org" , " > draft-ietf-sipcore-sip-token-authnz@ietf.org" < > draft-ietf-sipcore-sip-token-authnz@ietf.org>, "sipcore-chairs@ietf.org" = < > sipcore-chairs@ietf.org>, "sipcore@ietf.org" , "A. > Mahoney" > *Subject: *Re: Benjamin Kaduk's Discuss on > draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) > *Resent from: * > *Resent to: *Rifaat Shekh-Yusef , Christer > Holmberg , Victor Pascual < > victor.pascual.avila@gmail.com> > *Resent date: *Tuesday, 5 May 2020 at 22.10 > > > > Inline... > > > > On Tue, May 5, 2020 at 2:46 PM Benjamin Kaduk via Datatracker < > noreply@ietf.org> wrote: > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-sipcore-sip-token-authnz-15: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thanks for the updates in the -14 (and -15); they cover most of my points= . > > Unfortunately, the new security considerations text seems to introduce a > problematic recommendation: > > Because of that, it is critical to make sure that extra security > measures be taken to safeguard credentials used for Single Sign-On. > Examples of such measures include long passphrase instead of a > password, enabling multi-factor factor authentication, and the use of > embedded browser when possible, as defined in [RFC8252]. > > Looking at RFC 8252 (Section 8.12), it seems to be rather strongly > recommending > to *not* use an embedded browser, which is the opposite of the apparent > recommendation here. Are we missing a word "avoiding" or similar? > > > > Yeah, this should have been "browser" not "embedded browser". > > We will remove the "embedded browser" and replace it with "the native > platform browser". > > > > > > Also, I am not 100% sure my note about refresh tokens was fully addressed= ; > in Section 2.1.1 we see: > > The refresh token is only used between the UAC and the AS. If the AS > provides a refresh token to the UAC, the UAC uses it to request a new > access token and refresh token from the AS before the currently used > access token expires ([RFC6749], Section 1.5). If the AS does not > > Is it accurate to say that the refresh token is used "to request a new > access > token and refresh token" (specifically the "and refresh token" part)? I > know that > it is not always returned, but am less sure about whether the semantics > always > include an (implicit) request for a new one. > > > > Returning a refresh token is based on AS policy. > > We will remove the "and refresh token". > > > > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Some other comments on the new text that do not rise to Discuss-level. > > Thanks for adding the mention of a whitelist of trusted ASes; I would > consider > also mentioning it in Section 4 for the authz_server parameter, and/or in > the > security considerations. > > We will add that to the security consideration section. > > > > > > I also would have liked to see some guidance about when one > should/shouldn't > include the realm parameter in a challenge. > > I think this is out of scope, as we are not updating or changing the > existing SIP behavior on this issue. > > > > > > Section 2.1.1 > > UAC contacts the AS in order to obtain tokens, and includes the > requested scopes, based on a local configuration (Figure 1). The UAC > MUST check the AS URL received in the 401/407 response against a list > of trusted ASs configured on the UAC, in order to prevent several > classes of possible vulnerabilities when a client blindly attempt to > use any provided authorization. > > nits: "attempts", and maybe "any provided authorization server". > > Will fix it > > > > Section 3 > > nit: s/claimes/claims/ > > Will fix it > > > > > > Section 5 > > When a registrar chooses to challenge a REGISTER request, if the > registrar can provide access to different levels of services, it is > RECOMMENDED that the registrar includes a scope in the response in > order to indicate the minimum scope needed to register and access > basic services. The access token might include an extended scope > that gives the user access to more advanced features beyond basic > services. > > Is there anything to say about how the broader scope value might be > learned? > > In SIP, it is typically controlled by the admin, that controls the AS, an= d > dictates the level of access for the user. > > We will add a sentence to that extent. > > > > Regards, > > Rifaat > > > --0000000000008b692105a4ed1859 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Does this pul= l request address your latest DISCUSS and comments?

Regards,
=C2=A0Rifaat


On Tue, May 5, 2020 = at 3:31 PM Christer Holmberg <christer.holmberg@ericsson.com> wrote:

Hi,

=C2=A0

Based on Benjamin=E2=80=99s com= ments, I created a new pull request:

=C2=A0

ht= tps://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/9

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = Rifaat Shekh-Yusef &l= t;rifaat.ietf@gm= ail.com>
Date: Tuesday, 5 May 2020 at 22.10
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "iesg@ie= tf.org" <ies= g@ietf.org>, "draft-ietf-sipcore-sip-token-authnz@ietf.o= rg" <draft-ietf-sipcore-sip-token-authnz@ietf.org>= ;, "sipco= re-chairs@ietf.org" <sipcore-chairs@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>, &q= uot;A. Mahoney" <mahoney@nostrum.com>
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-= token-authnz-15: (with DISCUSS and COMMENT)
Resent from: <alias-bounces@ietf.org>
Resent to: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Christer Holmberg &= lt;chri= ster.holmberg@ericsson.com>, Victor Pascual <victor.pascual.avila@gmail.= com>
Resent date: Tuesday, 5 May 2020 at 22.10

=C2=A0

Inline...

=C2=A0

On Tue, May 5, 2020 at 2:46 PM Benjamin Kaduk via Da= tatracker <noreply= @ietf.org> wrote:

Benjamin Kaduk has ente= red the following ballot position for
draft-ietf-sipcore-sip-token-authnz-15: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sipcor= e-sip-token-authnz/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the updates in the -14 (and -15); they cover most of my points.<= br>
Unfortunately, the new security considerations text seems to introduce a problematic recommendation:

=C2=A0 =C2=A0Because of that, it is critical to make sure that extra securi= ty
=C2=A0 =C2=A0measures be taken to safeguard credentials used for Single Sig= n-On.
=C2=A0 =C2=A0Examples of such measures include long passphrase instead of a=
=C2=A0 =C2=A0password, enabling multi-factor factor authentication, and the= use of
=C2=A0 =C2=A0embedded browser when possible, as defined in [RFC8252].

Looking at RFC 8252 (Section 8.12), it seems to be rather strongly recommen= ding
to *not* use an embedded browser, which is the opposite of the apparent
recommendation here.=C2=A0 Are we missing a word "avoiding" or si= milar?

=C2=A0

Yeah, this should have been "browser" not = "embedded browser".

We will remove the "embedded browser" and = replace it with "the native platform browser".

=C2=A0

=C2=A0

Also, I am not 100% sure my note about refresh token= s was fully addressed;
in Section 2.1.1 we see:

=C2=A0 =C2=A0The refresh token is only used between the UAC and the AS.=C2= =A0 If the AS
=C2=A0 =C2=A0provides a refresh token to the UAC, the UAC uses it to reques= t a new
=C2=A0 =C2=A0access token and refresh token from the AS before the currentl= y used
=C2=A0 =C2=A0access token expires ([RFC6749], Section 1.5).=C2=A0 If the AS= does not

Is it accurate to say that the refresh token is used "to request a new= access
token and refresh token" (specifically the "and refresh token&quo= t; part)?=C2=A0 I know that
it is not always returned, but am less sure about whether the semantics alw= ays
include an (implicit) request for a new one.=C2=A0

=C2=A0

Returning a refresh token is based on AS policy.<= /u>

We will remove the "and refresh token".=

=C2=A0

=C2=A0


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Some other comments on the new text that do not rise to Discuss-level.

Thanks for adding the mention of a whitelist of trusted ASes; I would consi= der
also mentioning it in Section 4 for the authz_server parameter, and/or in t= he
security considerations.

We will add that to the security consideration secti= on.

=C2=A0

=C2=A0

I also would have liked= to see some guidance about when one should/shouldn't
include the realm parameter in a challenge.

I think this is out of scope, as we are not updating= or changing the existing SIP behavior on this issue.

=C2=A0

=C2=A0

Section 2.1.1

=C2=A0 =C2=A0UAC contacts the AS in order to obtain tokens, and includes th= e
=C2=A0 =C2=A0requested scopes, based on a local configuration (Figure 1).= =C2=A0 The UAC
=C2=A0 =C2=A0MUST check the AS URL received in the 401/407 response against= a list
=C2=A0 =C2=A0of trusted ASs configured on the UAC, in order to prevent seve= ral
=C2=A0 =C2=A0classes of possible vulnerabilities when a client blindly atte= mpt to
=C2=A0 =C2=A0use any provided authorization.

nits: "attempts", and maybe "any provided authorization serv= er".

Will fix it

=C2=A0

Section 3

nit: s/claimes/claims/

Will fix it

=C2=A0

=C2=A0

Section 5

=C2=A0 =C2=A0When a registrar chooses to challenge a REGISTER request, if t= he
=C2=A0 =C2=A0registrar can provide access to different levels of services, = it is
=C2=A0 =C2=A0RECOMMENDED that the registrar includes a scope in the respons= e in
=C2=A0 =C2=A0order to indicate the minimum scope needed to register and acc= ess
=C2=A0 =C2=A0basic services.=C2=A0 The access token might include an extend= ed scope
=C2=A0 =C2=A0that gives the user access to more advanced features beyond ba= sic
=C2=A0 =C2=A0services.

Is there anything to say about how the broader scope value might be learned= ?

In SIP, it is typically controlled by the admin, tha= t controls the AS, and dictates the level of access for the user.=

We will add a sentence to that extent.=

=C2=A0

Regards,

=C2=A0Rifaat

=C2=A0

--0000000000008b692105a4ed1859-- From nobody Tue May 5 14:31:32 2020 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 0FE923A0BB0; Tue, 5 May 2020 14:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 dWa6dFf__TDh; Tue, 5 May 2020 14:31:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 AB77E3A0BAA; Tue, 5 May 2020 14:31:03 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 045LUrkx004434 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 5 May 2020 17:30:55 -0400 Date: Tue, 5 May 2020 14:30:53 -0700 From: Benjamin Kaduk To: Rifaat Shekh-Yusef Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Message-ID: <20200505213053.GU27494@kduck.mit.edu> References: <70D8F1BE-9596-4407-9C20-550449863330@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:31:06 -0000 I think so, yes. -Ben On Tue, May 05, 2020 at 05:11:38PM -0400, Rifaat Shekh-Yusef wrote: > Ben, > > Does this pull request address your latest DISCUSS and comments? > > Regards, > Rifaat > > > On Tue, May 5, 2020 at 3:31 PM Christer Holmberg < > christer.holmberg@ericsson.com> wrote: > > > Hi, > > > > > > > > Based on Benjamin’s comments, I created a new pull request: > > > > > > > > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/9 > > > > > > > > Regards, > > > > > > > > Christer > > > > > > > > > > > > *From: *Rifaat Shekh-Yusef > > *Date: *Tuesday, 5 May 2020 at 22.10 > > *To: *Benjamin Kaduk > > *Cc: *"iesg@ietf.org" , " > > draft-ietf-sipcore-sip-token-authnz@ietf.org" < > > draft-ietf-sipcore-sip-token-authnz@ietf.org>, "sipcore-chairs@ietf.org" < > > sipcore-chairs@ietf.org>, "sipcore@ietf.org" , "A. > > Mahoney" > > *Subject: *Re: Benjamin Kaduk's Discuss on > > draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) > > *Resent from: * > > *Resent to: *Rifaat Shekh-Yusef , Christer > > Holmberg , Victor Pascual < > > victor.pascual.avila@gmail.com> > > *Resent date: *Tuesday, 5 May 2020 at 22.10 > > > > > > > > Inline... > > > > > > > > On Tue, May 5, 2020 at 2:46 PM Benjamin Kaduk via Datatracker < > > noreply@ietf.org> wrote: > > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-sipcore-sip-token-authnz-15: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for the updates in the -14 (and -15); they cover most of my points. > > > > Unfortunately, the new security considerations text seems to introduce a > > problematic recommendation: > > > > Because of that, it is critical to make sure that extra security > > measures be taken to safeguard credentials used for Single Sign-On. > > Examples of such measures include long passphrase instead of a > > password, enabling multi-factor factor authentication, and the use of > > embedded browser when possible, as defined in [RFC8252]. > > > > Looking at RFC 8252 (Section 8.12), it seems to be rather strongly > > recommending > > to *not* use an embedded browser, which is the opposite of the apparent > > recommendation here. Are we missing a word "avoiding" or similar? > > > > > > > > Yeah, this should have been "browser" not "embedded browser". > > > > We will remove the "embedded browser" and replace it with "the native > > platform browser". > > > > > > > > > > > > Also, I am not 100% sure my note about refresh tokens was fully addressed; > > in Section 2.1.1 we see: > > > > The refresh token is only used between the UAC and the AS. If the AS > > provides a refresh token to the UAC, the UAC uses it to request a new > > access token and refresh token from the AS before the currently used > > access token expires ([RFC6749], Section 1.5). If the AS does not > > > > Is it accurate to say that the refresh token is used "to request a new > > access > > token and refresh token" (specifically the "and refresh token" part)? I > > know that > > it is not always returned, but am less sure about whether the semantics > > always > > include an (implicit) request for a new one. > > > > > > > > Returning a refresh token is based on AS policy. > > > > We will remove the "and refresh token". > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Some other comments on the new text that do not rise to Discuss-level. > > > > Thanks for adding the mention of a whitelist of trusted ASes; I would > > consider > > also mentioning it in Section 4 for the authz_server parameter, and/or in > > the > > security considerations. > > > > We will add that to the security consideration section. > > > > > > > > > > > > I also would have liked to see some guidance about when one > > should/shouldn't > > include the realm parameter in a challenge. > > > > I think this is out of scope, as we are not updating or changing the > > existing SIP behavior on this issue. > > > > > > > > > > > > Section 2.1.1 > > > > UAC contacts the AS in order to obtain tokens, and includes the > > requested scopes, based on a local configuration (Figure 1). The UAC > > MUST check the AS URL received in the 401/407 response against a list > > of trusted ASs configured on the UAC, in order to prevent several > > classes of possible vulnerabilities when a client blindly attempt to > > use any provided authorization. > > > > nits: "attempts", and maybe "any provided authorization server". > > > > Will fix it > > > > > > > > Section 3 > > > > nit: s/claimes/claims/ > > > > Will fix it > > > > > > > > > > > > Section 5 > > > > When a registrar chooses to challenge a REGISTER request, if the > > registrar can provide access to different levels of services, it is > > RECOMMENDED that the registrar includes a scope in the response in > > order to indicate the minimum scope needed to register and access > > basic services. The access token might include an extended scope > > that gives the user access to more advanced features beyond basic > > services. > > > > Is there anything to say about how the broader scope value might be > > learned? > > > > In SIP, it is typically controlled by the admin, that controls the AS, and > > dictates the level of access for the user. > > > > We will add a sentence to that extent. > > > > > > > > Regards, > > > > Rifaat > > > > > > From nobody Tue May 5 14:35:33 2020 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 706103A0BB0; Tue, 5 May 2020 14:35:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 r4-3Gg6sNoRL; Tue, 5 May 2020 14:35:28 -0700 (PDT) Received: from mail-il1-x144.google.com (mail-il1-x144.google.com [IPv6:2607:f8b0:4864:20::144]) (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 A98E33A0BAC; Tue, 5 May 2020 14:35:28 -0700 (PDT) Received: by mail-il1-x144.google.com with SMTP id i16so3718040ils.12; Tue, 05 May 2020 14:35:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9yCTuVRytqa5jzitPf4OruN9i/UWCulYgac6IyQk0C0=; b=EolVceC8sLNyxcWue/TGTJmKpbfjt4aSYRW7we5Uu/ntZScxiCgxco5h6nfURIU4oy 7C1L3Q1RCLbcVOkFqAAn/02jwP0cLLYReiI3uEGBeRXZUcKV6M91t8zgbI4Md6gV4PoY /rfUIKDr0lCTM5HbLUMy3c2sOoTO6bzTRlniqPDj0Wgwlf6xdUovas9j0g+LcYLCg/OP x5eyMmUSSPksdl4YPV+ZCDezKPj12MRnejGce3nRPMkjDlaRFkqKf31k9djOxsp1gGMO bq77qyTyP+MAM7Eci7MkxSeA8cBKSn2adSCGnc7+GkHBdt85wfblaPF5KltFh97qo/lt IZUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9yCTuVRytqa5jzitPf4OruN9i/UWCulYgac6IyQk0C0=; b=IcfYBpkOQLpj11Oby8k6hb7uTAOFVy1evpjViG4FXDDWk8lV6eO2s8EvnR6WTrfAxe iMrMDmfE7U6K64mqpEdRbrvQORaiqyI1i7fQMOnLgXpPW3SzXw6RX4Kcug9h+N9mVn6x 9IoJmlHbRRqvLCRiio7BFhltVEAnbo58WNTX54eG6ahluhHbOLEkvSQJ61F0fAakKCGp oceCiIHwAgz+9A3gBepuv5i6kP2GNUwxviYC7ffV2Kd3YTO08EyY17cLwl2tyh/PfRLs M8CTqQc8bYo5ayT6qwcN7HcIksXfs4OnE6ngxFP9rgYsE/npUzFTVhnLZaHbAOJIMhU7 epxg== X-Gm-Message-State: AGi0PuZ9ZO7kgPalYGH80dlWjr2itscjX57og4PoNBcJ0XfPWuyXgOf5 /PkJQ3vTnl49joVFKgaCbDyysZx42FG6FIqxv/E= X-Google-Smtp-Source: APiQypL4unJY5ITo7RJaQLBGaPEaGxV2007oHpgA653AuawjNqFe6+5mZ9lizbEnR/Slr1Y6SBRAjyyHhZLxfpwgCpQ= X-Received: by 2002:a92:d182:: with SMTP id z2mr5438090ilz.36.1588714528024; Tue, 05 May 2020 14:35:28 -0700 (PDT) MIME-Version: 1.0 References: <70D8F1BE-9596-4407-9C20-550449863330@ericsson.com> <20200505213053.GU27494@kduck.mit.edu> In-Reply-To: <20200505213053.GU27494@kduck.mit.edu> From: Rifaat Shekh-Yusef Date: Tue, 5 May 2020 17:35:16 -0400 Message-ID: To: Benjamin Kaduk Cc: Christer Holmberg , The IESG , "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , SIPCORE , Jean Mahoney Content-Type: multipart/alternative; boundary="00000000000017abfb05a4ed6df5" Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's Discuss on draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) - the pull request X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:35:32 -0000 --00000000000017abfb05a4ed6df5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Ben! We appreciate all your reviews and feedback. This document is in a much better shape because of your detailed and comprehensive reviews. Regards, Rifaat On Tue, May 5, 2020 at 5:31 PM Benjamin Kaduk wrote: > I think so, yes. > > -Ben > > On Tue, May 05, 2020 at 05:11:38PM -0400, Rifaat Shekh-Yusef wrote: > > Ben, > > > > Does this pull request address your latest DISCUSS and comments? > > > > Regards, > > Rifaat > > > > > > On Tue, May 5, 2020 at 3:31 PM Christer Holmberg < > > christer.holmberg@ericsson.com> wrote: > > > > > Hi, > > > > > > > > > > > > Based on Benjamin=E2=80=99s comments, I created a new pull request: > > > > > > > > > > > > > https://github.com/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/9 > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > *From: *Rifaat Shekh-Yusef > > > *Date: *Tuesday, 5 May 2020 at 22.10 > > > *To: *Benjamin Kaduk > > > *Cc: *"iesg@ietf.org" , " > > > draft-ietf-sipcore-sip-token-authnz@ietf.org" < > > > draft-ietf-sipcore-sip-token-authnz@ietf.org>, " > sipcore-chairs@ietf.org" < > > > sipcore-chairs@ietf.org>, "sipcore@ietf.org" , "A. > > > Mahoney" > > > *Subject: *Re: Benjamin Kaduk's Discuss on > > > draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT) > > > *Resent from: * > > > *Resent to: *Rifaat Shekh-Yusef , Christer > > > Holmberg , Victor Pascual < > > > victor.pascual.avila@gmail.com> > > > *Resent date: *Tuesday, 5 May 2020 at 22.10 > > > > > > > > > > > > Inline... > > > > > > > > > > > > On Tue, May 5, 2020 at 2:46 PM Benjamin Kaduk via Datatracker < > > > noreply@ietf.org> wrote: > > > > > > Benjamin Kaduk has entered the following ballot position for > > > draft-ietf-sipcore-sip-token-authnz-15: Discuss > > > > > > When responding, please keep the subject line intact and reply to all > > > email addresses included in the To and CC lines. (Feel free to cut th= is > > > introductory paragraph, however.) > > > > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > > > > The document, along with other ballot positions, can be found here: > > > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > DISCUSS: > > > ---------------------------------------------------------------------= - > > > > > > Thanks for the updates in the -14 (and -15); they cover most of my > points. > > > > > > Unfortunately, the new security considerations text seems to introduc= e > a > > > problematic recommendation: > > > > > > Because of that, it is critical to make sure that extra security > > > measures be taken to safeguard credentials used for Single Sign-On= . > > > Examples of such measures include long passphrase instead of a > > > password, enabling multi-factor factor authentication, and the use > of > > > embedded browser when possible, as defined in [RFC8252]. > > > > > > Looking at RFC 8252 (Section 8.12), it seems to be rather strongly > > > recommending > > > to *not* use an embedded browser, which is the opposite of the appare= nt > > > recommendation here. Are we missing a word "avoiding" or similar? > > > > > > > > > > > > Yeah, this should have been "browser" not "embedded browser". > > > > > > We will remove the "embedded browser" and replace it with "the native > > > platform browser". > > > > > > > > > > > > > > > > > > Also, I am not 100% sure my note about refresh tokens was fully > addressed; > > > in Section 2.1.1 we see: > > > > > > The refresh token is only used between the UAC and the AS. If the > AS > > > provides a refresh token to the UAC, the UAC uses it to request a > new > > > access token and refresh token from the AS before the currently us= ed > > > access token expires ([RFC6749], Section 1.5). If the AS does not > > > > > > Is it accurate to say that the refresh token is used "to request a ne= w > > > access > > > token and refresh token" (specifically the "and refresh token" part)? > I > > > know that > > > it is not always returned, but am less sure about whether the semanti= cs > > > always > > > include an (implicit) request for a new one. > > > > > > > > > > > > Returning a refresh token is based on AS policy. > > > > > > We will remove the "and refresh token". > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > COMMENT: > > > ---------------------------------------------------------------------= - > > > > > > Some other comments on the new text that do not rise to Discuss-level= . > > > > > > Thanks for adding the mention of a whitelist of trusted ASes; I would > > > consider > > > also mentioning it in Section 4 for the authz_server parameter, and/o= r > in > > > the > > > security considerations. > > > > > > We will add that to the security consideration section. > > > > > > > > > > > > > > > > > > I also would have liked to see some guidance about when one > > > should/shouldn't > > > include the realm parameter in a challenge. > > > > > > I think this is out of scope, as we are not updating or changing the > > > existing SIP behavior on this issue. > > > > > > > > > > > > > > > > > > Section 2.1.1 > > > > > > UAC contacts the AS in order to obtain tokens, and includes the > > > requested scopes, based on a local configuration (Figure 1). The > UAC > > > MUST check the AS URL received in the 401/407 response against a > list > > > of trusted ASs configured on the UAC, in order to prevent several > > > classes of possible vulnerabilities when a client blindly attempt = to > > > use any provided authorization. > > > > > > nits: "attempts", and maybe "any provided authorization server". > > > > > > Will fix it > > > > > > > > > > > > Section 3 > > > > > > nit: s/claimes/claims/ > > > > > > Will fix it > > > > > > > > > > > > > > > > > > Section 5 > > > > > > When a registrar chooses to challenge a REGISTER request, if the > > > registrar can provide access to different levels of services, it i= s > > > RECOMMENDED that the registrar includes a scope in the response in > > > order to indicate the minimum scope needed to register and access > > > basic services. The access token might include an extended scope > > > that gives the user access to more advanced features beyond basic > > > services. > > > > > > Is there anything to say about how the broader scope value might be > > > learned? > > > > > > In SIP, it is typically controlled by the admin, that controls the AS= , > and > > > dictates the level of access for the user. > > > > > > We will add a sentence to that extent. > > > > > > > > > > > > Regards, > > > > > > Rifaat > > > > > > > > > > --00000000000017abfb05a4ed6df5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ben!

We appreciate all your revi= ews and feedback.
This document is in a much better shape because= =C2=A0of your detailed and comprehensive reviews.

= Regards,
=C2=A0Rifaat


On Tue, May 5, 2020 at = 5:31 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
I = think so, yes.

-Ben

On Tue, May 05, 2020 at 05:11:38PM -0400, Rifaat Shekh-Yusef wrote:
> Ben,
>
> Does this pull request address your latest DISCUSS and comments?
>
> Regards,
>=C2=A0 Rifaat
>
>
> On Tue, May 5, 2020 at 3:31 PM Christer Holmberg <
> ch= rister.holmberg@ericsson.com> wrote:
>
> > Hi,
> >
> >
> >
> > Based on Benjamin=E2=80=99s comments, I created a new pull reques= t:
> >
> >
> >
> > https://github.co= m/rifaat-ietf/draft-ietf-sipcore-sip-token-authnz/pull/9
> >
> >
> >
> > Regards,
> >
> >
> >
> > Christer
> >
> >
> >
> >
> >
> > *From: *Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
> > *Date: *Tuesday, 5 May 2020 at 22.10
> > *To: *Benjamin Kaduk <kaduk@mit.edu>
> > *Cc: *"ie= sg@ietf.org" <iesg@ietf.org>, "
> > draft-ietf-sipcore-sip-token-authnz@ietf.org" <= ;
> > draft-ietf-sipcore-sip-token-authnz@ietf.org>, &quo= t;sipcore-chai= rs@ietf.org" <
> > sipc= ore-chairs@ietf.org>, "sipcore@ietf.org" <sipcore@ietf.org>, "A.
> > Mahoney" <mahoney@nostrum.com>
> > *Subject: *Re: Benjamin Kaduk's Discuss on
> > draft-ietf-sipcore-sip-token-authnz-15: (with DISCUSS and COMMENT= )
> > *Resent from: *<alias-bounces@ietf.org>
> > *Resent to: *Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Christer
> > Holmberg <christer.holmberg@ericsson.com>, Victor Pascual <=
> > victor.pascual.avila@gmail.com>
> > *Resent date: *Tuesday, 5 May 2020 at 22.10
> >
> >
> >
> > Inline...
> >
> >
> >
> > On Tue, May 5, 2020 at 2:46 PM Benjamin Kaduk via Datatracker <= ;
> > noreply@iet= f.org> wrote:
> >
> > Benjamin Kaduk has entered the following ballot position for
> > draft-ietf-sipcore-sip-token-authnz-15: Discuss
> >
> > When responding, please keep the subject line intact and reply to= all
> > email addresses included in the To and CC lines. (Feel free to cu= t this
> > introductory paragraph, however.)
> >
> >
> > Please refer to https://www.ietf.= org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions. > >
> >
> > The document, along with other ballot positions, can be found her= e:
> > https://datatracker.i= etf.org/doc/draft-ietf-sipcore-sip-token-authnz/
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > DISCUSS:
> > -----------------------------------------------------------------= -----
> >
> > Thanks for the updates in the -14 (and -15); they cover most of m= y points.
> >
> > Unfortunately, the new security considerations text seems to intr= oduce a
> > problematic recommendation:
> >
> >=C2=A0 =C2=A0 Because of that, it is critical to make sure that ex= tra security
> >=C2=A0 =C2=A0 measures be taken to safeguard credentials used for = Single Sign-On.
> >=C2=A0 =C2=A0 Examples of such measures include long passphrase in= stead of a
> >=C2=A0 =C2=A0 password, enabling multi-factor factor authenticatio= n, and the use of
> >=C2=A0 =C2=A0 embedded browser when possible, as defined in [RFC82= 52].
> >
> > Looking at RFC 8252 (Section 8.12), it seems to be rather strongl= y
> > recommending
> > to *not* use an embedded browser, which is the opposite of the ap= parent
> > recommendation here.=C2=A0 Are we missing a word "avoiding&q= uot; or similar?
> >
> >
> >
> > Yeah, this should have been "browser" not "embedde= d browser".
> >
> > We will remove the "embedded browser" and replace it wi= th "the native
> > platform browser".
> >
> >
> >
> >
> >
> > Also, I am not 100% sure my note about refresh tokens was fully a= ddressed;
> > in Section 2.1.1 we see:
> >
> >=C2=A0 =C2=A0 The refresh token is only used between the UAC and t= he AS.=C2=A0 If the AS
> >=C2=A0 =C2=A0 provides a refresh token to the UAC, the UAC uses it= to request a new
> >=C2=A0 =C2=A0 access token and refresh token from the AS before th= e currently used
> >=C2=A0 =C2=A0 access token expires ([RFC6749], Section 1.5).=C2=A0= If the AS does not
> >
> > Is it accurate to say that the refresh token is used "to req= uest a new
> > access
> > token and refresh token" (specifically the "and refresh= token" part)?=C2=A0 I
> > know that
> > it is not always returned, but am less sure about whether the sem= antics
> > always
> > include an (implicit) request for a new one.
> >
> >
> >
> > Returning a refresh token is based on AS policy.
> >
> > We will remove the "and refresh token".
> >
> >
> >
> >
> >
> >
> > -----------------------------------------------------------------= -----
> > COMMENT:
> > -----------------------------------------------------------------= -----
> >
> > Some other comments on the new text that do not rise to Discuss-l= evel.
> >
> > Thanks for adding the mention of a whitelist of trusted ASes; I w= ould
> > consider
> > also mentioning it in Section 4 for the authz_server parameter, a= nd/or in
> > the
> > security considerations.
> >
> > We will add that to the security consideration section.
> >
> >
> >
> >
> >
> > I also would have liked to see some guidance about when one
> > should/shouldn't
> > include the realm parameter in a challenge.
> >
> > I think this is out of scope, as we are not updating or changing = the
> > existing SIP behavior on this issue.
> >
> >
> >
> >
> >
> > Section 2.1.1
> >
> >=C2=A0 =C2=A0 UAC contacts the AS in order to obtain tokens, and i= ncludes the
> >=C2=A0 =C2=A0 requested scopes, based on a local configuration (Fi= gure 1).=C2=A0 The UAC
> >=C2=A0 =C2=A0 MUST check the AS URL received in the 401/407 respon= se against a list
> >=C2=A0 =C2=A0 of trusted ASs configured on the UAC, in order to pr= event several
> >=C2=A0 =C2=A0 classes of possible vulnerabilities when a client bl= indly attempt to
> >=C2=A0 =C2=A0 use any provided authorization.
> >
> > nits: "attempts", and maybe "any provided authoriz= ation server".
> >
> > Will fix it
> >
> >
> >
> > Section 3
> >
> > nit: s/claimes/claims/
> >
> > Will fix it
> >
> >
> >
> >
> >
> > Section 5
> >
> >=C2=A0 =C2=A0 When a registrar chooses to challenge a REGISTER req= uest, if the
> >=C2=A0 =C2=A0 registrar can provide access to different levels of = services, it is
> >=C2=A0 =C2=A0 RECOMMENDED that the registrar includes a scope in t= he response in
> >=C2=A0 =C2=A0 order to indicate the minimum scope needed to regist= er and access
> >=C2=A0 =C2=A0 basic services.=C2=A0 The access token might include= an extended scope
> >=C2=A0 =C2=A0 that gives the user access to more advanced features= beyond basic
> >=C2=A0 =C2=A0 services.
> >
> > Is there anything to say about how the broader scope value might = be
> > learned?
> >
> > In SIP, it is typically controlled by the admin, that controls th= e AS, and
> > dictates the level of access for the user.
> >
> > We will add a sentence to that extent.
> >
> >
> >
> > Regards,
> >
> >=C2=A0 Rifaat
> >
> >
> >
--00000000000017abfb05a4ed6df5-- From nobody Tue May 5 14:59:54 2020 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 688FC3A0BE0; Tue, 5 May 2020 14:59:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <158871598537.612.9793923566031210109@ietfa.amsl.com> Date: Tue, 05 May 2020 14:59:45 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-16.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 21:59:46 -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 WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-16.txt Pages : 17 Date : 2020-05-05 Abstract: This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-16 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-16 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 Tue May 5 15:13:15 2020 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 CE2603A0BCC; Tue, 5 May 2020 15:13:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-sipcore-sip-token-authnz@ietf.org, sipcore-chairs@ietf.org, sipcore@ietf.org, Jean Mahoney , mahoney@nostrum.com X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <158871678979.16766.16226793106603618370@ietfa.amsl.com> Date: Tue, 05 May 2020 15:13:11 -0700 Archived-At: Subject: [sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-sip-token-authnz-16: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 22:13:12 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-sipcore-sip-token-authnz-16: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for addressing my comments! From nobody Tue May 5 15:20:05 2020 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 82CF13A0BE1; Tue, 5 May 2020 15:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 UYMg8fzuYt5D; Tue, 5 May 2020 15:20:01 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40062.outbound.protection.outlook.com [40.107.4.62]) (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 47ED33A0BDF; Tue, 5 May 2020 15:20:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T/UjCGvzg++B3SswOkAkl7kj8T67Mh7WItc3AdozLiIYH5U7Zw35pWMDQ7sGmt0EvVGZI8VmH3BPbiny1NBHz9FEth8phWC/yAMXvFGrjNvS4l+lmAoEZdOQZfCGbPyuFl98kOzMEaQ8jTGHYb/6+m59cdQsBhKqhjc0vkoYT3dR2MkDqd5AC1nhBEyVb4FhdO9l7DrFCsXUE0PnvulDY7NjhsxhA0U267hQX9/wY0zZZJTJ8eKct+2zubAbWzIS7iccLz8TtFKpDZgwAkgAC2eEeXdLNxSw8fuFv57GLeHfY9KbQmWcLXfE40nB4xen+mghIsIjHPP/M2d0F3wU2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oX6cmIqIxiTGExX6sGTHSW8We8F0uo0P3L+cvmcbMPs=; b=S2KDvyq1JdYRYnfhGhA6f2TTzDl5tIXrD/eP5+x8HZy+jHlpwzshMwNb0Ko/pXZMenJNP/q1sb0riy3PQ9OnroprXc+Dru7lKFeiS/Bk5JKd6Axv3PmcpRR78rnyWCJV7uqL/g5QfsxF/J3j2ZaHrlTFHIWCHeNOnDc4jElj56wxuZ23WQN60z0GCMF9M7dqbbojLIiLlUsK06Bq8TejrplRmevQdJKlsyHgaDbVTRgXgPLtnbJXeDAPRnxnscFZqkTgskyuhjllnh/wzCWNmUcA8iwOHhb46s2WYq6f5mMrQIWJ4wpfSrrcLrLQnUC9VrvExwFRdBlXcBE0BPQEFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oX6cmIqIxiTGExX6sGTHSW8We8F0uo0P3L+cvmcbMPs=; b=HpOV2anbbpg+cB1dD6/vpQLEqIbMjeeHfjWL+wJXpN1swrkess7ArvOa2SoSX3CHGOeXVI32sf9x9hDy9R+DLykL5yEy5N9VleR3P/qOPKwjTqQkMDdf/fKbbmNqETjk2Py2eRdLISbsZbwhUtDocSPA+o8XJ/dXJ9fHFwm2vOg= Received: from VI1PR0701MB7023.eurprd07.prod.outlook.com (2603:10a6:800:19f::8) by VI1PR0701MB7040.eurprd07.prod.outlook.com (2603:10a6:800:195::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.18; Tue, 5 May 2020 22:19:59 +0000 Received: from VI1PR0701MB7023.eurprd07.prod.outlook.com ([fe80::a061:9559:79be:7ebd]) by VI1PR0701MB7023.eurprd07.prod.outlook.com ([fe80::a061:9559:79be:7ebd%5]) with mapi id 15.20.2979.025; Tue, 5 May 2020 22:19:59 +0000 From: Christer Holmberg To: Benjamin Kaduk , The IESG CC: "draft-ietf-sipcore-sip-token-authnz@ietf.org" , "sipcore-chairs@ietf.org" , "sipcore@ietf.org" , Jean Mahoney Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-sipcore-sip-token-authnz-16: (with COMMENT) Thread-Index: AQHWIypuqXaDdmmmBkWI8sKmBW0UZqiaQpQA Date: Tue, 5 May 2020 22:19:58 +0000 Message-ID: References: <158871678979.16766.16226793106603618370@ietfa.amsl.com> In-Reply-To: <158871678979.16766.16226793106603618370@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.216.230.200] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 43089b59-53a4-4a7a-99e2-08d7f14272aa x-ms-traffictypediagnostic: VI1PR0701MB7040: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0394259C80 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G3kHxYkDvnk3vXTPpbaiw6PrNk6Me/95i8KrPKrUN76FK8KFrnXI8o+GaSYTNwdQJxpiS1/nXJHfiuK1cTOuQhhkti/SjNGu1y1FjU1eGFUjAA9rdxWRxpTcHRnbSL/dRjmSRVkZmAaBASYm/lF1WtNzJtNSnxmmLgLMZfkTdwJ8olDF2YNGawUxCkWsFExmTiIijdAL3/P+IOk1ri+8jG87J2Oj8jLNGOAzORzt7d3lfzyiD2mx2pELsSjQ+esqt4uwolX4B7jnn6SB2jAe2QPJC0DHoe2Ok3Eu4ML6N2e6bGO1ld5UcUxR6hNeInXJOvoalKOxXdZvZwlIzAiVKZEHL4iq21nAIJ7dHzWJCCBrjYdknSMT4VftpH63z3G7d2KZVqLdtF+fM3K8ZMl6vz9QkofJnjj9fFl4/UzcgCYvVQMkiF9FNarexFfvkZdKnhEdTjKHY8GXyh5IXl8k1Bm2FmJ9fnQzBlGx/V1gjalEYTYigRs3x16eiiTnSZXU/0i1F9L5mWLkiaPj2gz3ZlWz/KVSTXoKDPTh7rVzm1Aj42I3WECMxme97fRwm13BpXm/dmnHKDRUFmW+vXe2taCOGbLBWHg5yPPZfuNdgEg= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR0701MB7023.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(366004)(346002)(39860400002)(136003)(376002)(33430700001)(478600001)(6486002)(966005)(71200400001)(33656002)(44832011)(8936002)(2906002)(2616005)(66946007)(86362001)(91956017)(8676002)(316002)(66476007)(66446008)(66556008)(64756008)(6506007)(33440700001)(5660300002)(26005)(76116006)(36756003)(186003)(6512007)(54906003)(4326008)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: OGQTtkFsGU0Tfi75QD4oDTYsIO10u05lzDn22fgLOfwpIoPl3EE6F5PQptCIB3m0sFLgPZzTF7f0MCTaJ7NCdbSiSMyqbSr+RnU5iUN9okaVTu507SWpxETKw+XNg+cXMiMR1plahdpTYfpuhpwa5J7p1uRo5GmdiF9GPm+S2v4K0YjRBA4Hx5nrDB7s4Ci38U2Cc1kbDkaYLP9PY+ibxJ14Sq9BhGzdSb1/b5ExwWuOXyffDG9dSpmUurExTqCKLj+74eVP6ODchvAr6UKTYm7VjH0ZmQJO2lFLdKIrGnRwuRndZAmsJ8/YmFrsB4sWQZS5iwIE6yb6rgtjWLObs7g2Ny6S60H5sHblZQYgHw2BdA+fucNUQcyjcxTMS1Q0yFNK78YDF+8yQtwDmw2dsybxrGH3N9RpIs45ENh6VKGPQdeIQWqUKcMj1ZzGaBGAOF2PAGrbr5Y+QgcFSp4R2qFv+Yh4fBrfn3TAWZKX8Enm1KVfHTFYw4nNONll/i99l636u4lumsEJPTPjm6Wq9bfrxLGMvbEsFhNox16TAhs4MhVMUrHJUq5Jc5RUmtYsYFxCgGycTFAQPbtrYcvUXb63gyV4gYZT7phZvy1wHFsIKng1esINRAhdRa7W8/8jYYq7H8oGOjIxkJmt8cz9c9K/4Id7hntNUHiRWaNbJxwStZKiZpqAhk/2HPeashfZPh6NZoIUyEqhs/32DWEIaROp+A+iPgBr4WrMbPr7CnGQon4D7dhMBQKKzKqiPnthRXYmANNuvqJMB+A42dUfotiQBO1HJ7HZyz9ub/dgAyOFPLXt2vES3uvivB5Ld8Us x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 43089b59-53a4-4a7a-99e2-08d7f14272aa X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2020 22:19:58.8570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: VXoJjr3HgmZgPJvTieuLEP5XBM5XaH1slH7FG4X0Vr1NIpf3iFI3ek2iDMfue+wCFq8P7mfnljtk+GCXp1/5WsJuPznHo6y959eDtvO64H4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB7040 Archived-At: Subject: Re: [sipcore] Benjamin Kaduk's No Objection on draft-ietf-sipcore-sip-token-authnz-16: (with COMMENT) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 22:20:04 -0000 VGhhbmsgWW91LCBCZW5qYW1pbiENCg0KQlRXLCB3ZSBmb3Jnb3QgdG8gZml4IHRoZSBtaW5vciAi dHlwaWNhbGwiIG5pdCB0aGF0IHlvdSBmb3VuZCBhbmQgaW5kaWNhdGVkIGluIEdpdEh1Yi4gV2Ug d2lsbCBkbyB0aGF0LCBhbmQgc3VibWl0IGEgbmV3IHZlcnNpb24sIHNvIHdlIGRvbid0IGZvcmdl dCBhYm91dCBpdCA6KQ0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQrvu79PbiAwNi8wNS8yMDIw LCAxLjEzLCAiQmVuamFtaW4gS2FkdWsgdmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9y Zz4gd3JvdGU6DQoNCiAgICBCZW5qYW1pbiBLYWR1ayBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5n IGJhbGxvdCBwb3NpdGlvbiBmb3INCiAgICBkcmFmdC1pZXRmLXNpcGNvcmUtc2lwLXRva2VuLWF1 dGhuei0xNjogTm8gT2JqZWN0aW9uDQogICAgDQogICAgV2hlbiByZXNwb25kaW5nLCBwbGVhc2Ug a2VlcCB0aGUgc3ViamVjdCBsaW5lIGludGFjdCBhbmQgcmVwbHkgdG8gYWxsDQogICAgZW1haWwg YWRkcmVzc2VzIGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8g Y3V0IHRoaXMNCiAgICBpbnRyb2R1Y3RvcnkgcGFyYWdyYXBoLCBob3dldmVyLikNCiAgICANCiAg ICANCiAgICBQbGVhc2UgcmVmZXIgdG8gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWVzZy9zdGF0ZW1l bnQvZGlzY3Vzcy1jcml0ZXJpYS5odG1sDQogICAgZm9yIG1vcmUgaW5mb3JtYXRpb24gYWJvdXQg SUVTRyBESVNDVVNTIGFuZCBDT01NRU5UIHBvc2l0aW9ucy4NCiAgICANCiAgICANCiAgICBUaGUg ZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5k IGhlcmU6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1z aXBjb3JlLXNpcC10b2tlbi1hdXRobnovDQogICAgDQogICAgDQogICAgDQogICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgIENPTU1FTlQ6DQogICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIA0KICAgIFRoYW5rIHlv dSBmb3IgYWRkcmVzc2luZyBteSBjb21tZW50cyENCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Tue May 5 15:29:13 2020 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 715BD3A0BC7; Tue, 5 May 2020 15:29:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: sipcore@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: sipcore@ietf.org Message-ID: <158871774641.7429.16588992392028447838@ietfa.amsl.com> Date: Tue, 05 May 2020 15:29:06 -0700 Archived-At: Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-token-authnz-17.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 22:29:07 -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 WG of the IETF. Title : Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP) Authors : Rifaat Shekh-Yusef Christer Holmberg Victor Pascual Filename : draft-ietf-sipcore-sip-token-authnz-17.txt Pages : 17 Date : 2020-05-05 Abstract: This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-sipcore-sip-token-authnz-17 https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-token-authnz-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-token-authnz-17 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 Tue May 5 16:37:17 2020 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 D14713A0C57; Tue, 5 May 2020 16:37:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.129.0 Auto-Submitted: auto-generated Precedence: bulk Cc: mahoney@nostrum.com, rfc-editor@rfc-editor.org, sipcore@ietf.org, sipcore-chairs@ietf.org, draft-ietf-sipcore-sip-token-authnz@ietf.org, Jean Mahoney , The IESG , superuser@gmail.com MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <158872182651.27061.11752625067518441535@ietfa.amsl.com> Date: Tue, 05 May 2020 16:37:06 -0700 Archived-At: Subject: [sipcore] Protocol Action: 'Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)' to Proposed Standard (draft-ietf-sipcore-sip-token-authnz-17.txt) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2020 23:37:07 -0000 The IESG has approved the following document: - 'Third-Party Token-based Authentication and Authorization for Session Initiation Protocol (SIP)' (draft-ietf-sipcore-sip-token-authnz-17.txt) as Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Murray Kucherawy and Barry Leiba. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-token-authnz/ Technical Summary This document defines the "Bearer" authentication scheme for the Session Initiation Protocol (SIP), and a mechanism by which user authentication and SIP registration authorization is delegated to a third party, using the OAuth 2.0 framework and OpenID Connect Core 1.0. This document updates RFC 3261 to provide guidance on how a SIP User Agent Client (UAC) responds to a SIP 401/407 response that contains multiple WWW-Authenticate/Proxy-Authenticate header fields. Working Group Summary This work has been discussed the sipcore working group for a while. It is much scaled down from its original scope, and contains the core of what the working group had consensus on. No contention was noted. Document Quality The authors indicated that there was at least one implementation of this. It's assumed that it will be deployed in 3GPP networks. During WGLC, the chairs asked if there were any other implementation plans, but no reviewers chose to share that info. General review quality based on mailing list activity seems to be satisfactory. Personnel Jean Mahoney is the Document Shepherd. Murray Kucherawy is the responsible Area Director. From nobody Wed May 6 05:34:43 2020 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 091733A0E57 for ; Wed, 6 May 2020 05:34:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.078 X-Spam-Level: X-Spam-Status: No, score=-2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 RQjq99hIo4zJ for ; Wed, 6 May 2020 05:34:31 -0700 (PDT) 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 B87A23A0D62 for ; Wed, 6 May 2020 05:33:43 -0700 (PDT) Received: from mutabilis-2.local ([47.186.30.41]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 046CXgSd030143 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Wed, 6 May 2020 07:33:43 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1588768423; bh=v+8qD+Yh2Ee8/FvEKoMF3NIOgExQfucG8sBptM1TyHM=; h=Subject:References:To:From:Date:In-Reply-To; b=tX+zAJXhbZ4StEDKiwYono+TiHeln85wRUlM5DVN1D25+zNklWXIdjDyGQbdAzQNj 3OLQj69BFqpylk42lzcGX2Om070rzKJSKJRwHa40ck0iBwqFlPYvGhAyhMu1ZiA+rD uuFaksjjFysQohjyKQeVC029KZL8A40DtEwwO+yQ= X-Authentication-Warning: raven.nostrum.com: Host [47.186.30.41] claimed to be mutabilis-2.local References: To: SIPCORE From: "A. Jean Mahoney" X-Forwarded-Message-Id: Message-ID: Date: Wed, 6 May 2020 07:33:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [sipcore] Fwd: Fwd: Reminder: Survey on planning for possible online IETF meetings X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 May 2020 12:34:41 -0000 Hi all, Please take the time to fill out the survey (link below) regarding online IETF meetings. Thanks! Jean -------- Forwarded Message -------- Subject: Fwd: Reminder: Survey on planning for possible online IETF meetings Date: Tue, 5 May 2020 07:48:03 -0400 From: Alissa Cooper To: IETF WG Chairs Please circulate this to your working group lists. The survey data will be very important as we plan future IETF meetings. Thanks, Alissa > Begin forwarded message: > > *From: *IETF Executive Director > > *Subject: **Reminder: Survey on planning for possible online IETF > meetings* > *Date: *May 4, 2020 at 3:03:35 AM EDT > *To: *"IETF Announcement List" > > *Reply-To: *ietf108planning@ietf.org > > This is a reminder that we need the IETF community to help us plan for > the possibility that one or more upcoming IETF meetings in 2020 and > possibly 2021 may not be able to go ahead in person. You can help us > with this by filling out the following survey: > > https://www.surveymonkey.com/r/5328FFJ > > So far we have 114 responses and we would ideally like 500 or more. > > The survey contains the following pages and will take 15-20 minutes to > complete: > > 1. Welcome > 2. Online IETF 107 and the subsequent virtual interims > 3. Replacing a cancelled in-person meeting > 4. Online meeting format and timezone > 5. Replicating humming > 6. Replicating the hallway environment > 7. Fees > 8. Thanks and anything else > > We run the survey in anonymous mode which means that we only see data > that you explicitly provide. > > Thank you in advance for your help. > > -- > Alissa Cooper, IETF Chair > Jay Daley, IETF Executive Director > Colin Perkins, IRTF Chair > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Thu May 7 04:49:26 2020 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 92AFA3A0522 for ; Thu, 7 May 2020 04:49:24 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details. Content previ[...] 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, SPF_HELO_NONE=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 w1GKPZweu1s6 for ; Thu, 7 May 2020 04:49:22 -0700 (PDT) Received: from mail.opensips.org (opensips.org [136.243.23.236]) (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 9709B3A04BB for ; Thu, 7 May 2020 04:49:20 -0700 (PDT) Received: from [89.45.16.83] (helo=[192.168.0.199]) by mail.opensips.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1jWf0l-000486-PK for sipcore@ietf.org; Thu, 07 May 2020 11:48:20 +0000 To: sipcore@ietf.org From: Liviu Chircu Message-ID: <225394ea-1a37-d3e1-48f6-a89567b82e98@opensips.org> Date: Thu, 7 May 2020 14:49:12 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [sipcore] RFC 8599 (SIP PN): Feedback & Nitpicking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 11:49:25 -0000 Hi! Following an apparently functional implementation of RFC 8599 within some open-source SIP proxy, I would first like to thank everyone who worked on the document for all of their careful considerations and restless reviewing.  The instructions were clear at all times and any lingering questions would eventually get answered on a 2nd, 3rd or 4th walk-through of the text. Cheers! Here are all the issues which I could still spot in the published version of the text: 1. [Question/Nitpick] given that "+sip.pnspurr" is a unique Feature-Caps indicator and that there can only be a maximum of 1 Feature-Caps header fields per unique PNS (e.g. "fcm") in a SIP REGISTER, it then logically follows that a PN SIP REGISTER can only hold max 1 x Contact header field values pointing to a given PNS (using the ";pn-provider=fcm" URI parameter). So the question is: should the text mention this extra SIP-level, logical restriction?  Because, coming into this RFC, there were no restrictions on the number of contacts that a single SIP REGISTER request may advertise. 2. [Typo] throughout § 4.1.4, there are three (!!!) incorrect mentions of the "sip.pnsreq" feature-capability indicator (notice it ends with a "q", not a "g"!).  It was confusing at first, until I realized it's a typo.  Fixing it would definitely be a time saver for everyone implementing the RFC. 3. [Typo] § 6.2.1: "even if 'pn-*'parameters"     notice a missing space " " before "parameters" 4. [Typo] § 4.1.5:         "... if the UA inserted a 'pn-provider' SIP URI parameter [value!!] ..."         "If the UA did not insert a 'pn-provider' parameter [value!!] ..." Both of these statements are correct with "parameter value", not "parameter".  If we take a look at the paragraph above, it actually talks about inserting a "parameter value".  Given that "pn-provider" is syntactically correct with or without a value, it is quite important to be non-ambiguous here. 5. [Typo] § 5.4: "A proxy MUST use a separate Feature-Cap[s!!] header field"     missing "s" 6. [Typo] § 7: "make sure that the initial request for dialog[s??]" extra "s" 7. [Typo] § 13: "Unless the PNS authenticates and authorizes the [PNS??]" Most likely, the authors meant "proxy" Thank you, Liviu From nobody Thu May 7 07:11:26 2020 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 7E1723A0412 for ; Thu, 7 May 2020 07:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.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 44-y74awKSg2 for ; Thu, 7 May 2020 07:11:23 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 352F43A0410 for ; Thu, 7 May 2020 07:11:23 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id f83so6113836qke.13 for ; Thu, 07 May 2020 07:11:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hD++MxWwm/FJQBWW5RsrNiKQGM04UiuzZhVcv1MVqw4=; b=D5J3Z7A7/llK4TvmgGYFvmMdmFqhm7bJ763HfKgFHAkj9j7JY4y+GGCN5Y9+u0lcgn KUjVBXrzLFi8vv1urNJUnf3nEQ9ZNtCbBzz80j+2A0tHyvH+NZlYOn8fh7hJhGOGovxe ZvmDTgrgwqcpRELuDT73Me63WNafVtmTwcYxiDt7MNvJjhlqDhShlf/scJ4gT9YAsAjw EUWYOdl4j/tABN0XZxbAyCEOCt4p5eWAiXieSsUEoeCK0JWjE9AtxjkHj+b93rDEuSF5 SRmjjAIwtK+C3kgx4rB249hOxEOhIFpBHIYnihVgpHk4B2ZWIDXiepbM/VagsJEtT/8W uTtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=hD++MxWwm/FJQBWW5RsrNiKQGM04UiuzZhVcv1MVqw4=; b=uOh4v8VxvmutTQwZNSWa2EGhJSMZk3hiiEjiHDJjlXh/zoN5jVUik4xndjcLKexM4H O+RYAcvW0BFUI/LshhqD/mhUBbrt8Gn8LTZ3XF2j4A4tvmKEzG4R0b5Dl4Ii5rcwmLRE QbR0v5AMEKOf30F5yAEcG4015mbinV8AnpFmPOJ4JcKcfOc2dRCEAzSCUeYTzrn5wVBC +/Sa5aq8bOlnEeeHLgEQCC4UfHfUWhqYVEBFvKFbX3P8Lc7hFhhdbC/NgqyXstVVpsRV 7wu8uWlrEMha+hFu7gQzw7HjjHYs3sg0+T2hUk1ZNFlxNPMKgWNvYoosBjdRIM+f73r3 vowg== X-Gm-Message-State: AGi0PubkzDwdKXxiuHnKLiAfmK22WQdZFE+t6ZFauCwKD50it7+JB8kX EbeO5/5KskpWX/v9CvqxpeyqnpsstwA= X-Google-Smtp-Source: APiQypK7cGsMUZnGh7LPTiOLoow6bn58ryR26PmKDi6oqOxa4iancGGvafmKfY4xNv7lgE7dsjD+8A== X-Received: by 2002:a05:620a:81b:: with SMTP id s27mr15200302qks.351.1588860682090; Thu, 07 May 2020 07:11:22 -0700 (PDT) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id z126sm4551883qka.61.2020.05.07.07.11.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 May 2020 07:11:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Brian Rosen In-Reply-To: <225394ea-1a37-d3e1-48f6-a89567b82e98@opensips.org> Date: Thu, 7 May 2020 10:11:20 -0400 Cc: SIPCORE Content-Transfer-Encoding: quoted-printable Message-Id: References: <225394ea-1a37-d3e1-48f6-a89567b82e98@opensips.org> To: Liviu Chircu X-Mailer: Apple Mail (2.3608.80.23.2.2) Archived-At: Subject: Re: [sipcore] RFC 8599 (SIP PN): Feedback & Nitpicking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 14:11:26 -0000 We should get the meaningful errors (2,4, 7) captured in an errata if = authors agree with Liviu. > On May 7, 2020, at 7:49 AM, Liviu Chircu wrote: >=20 > Hi! >=20 > Following an apparently functional implementation of RFC 8599 within = some open-source SIP proxy, I would first like to thank everyone who = worked on the document for all of their careful considerations and = restless reviewing. The instructions were clear at all times and any = lingering questions would eventually get answered on a 2nd, 3rd or 4th = walk-through of the text. Cheers! >=20 > Here are all the issues which I could still spot in the published = version of the text: >=20 > 1. [Question/Nitpick] given that "+sip.pnspurr" is a unique = Feature-Caps indicator and that there can only be a maximum of 1 = Feature-Caps header fields per unique PNS (e.g. "fcm") in a SIP = REGISTER, it then logically follows that a PN SIP REGISTER can only hold = max 1 x Contact header field values pointing to a given PNS (using the = ";pn-provider=3Dfcm" URI parameter). >=20 > So the question is: should the text mention this extra SIP-level, = logical restriction? Because, coming into this RFC, there were no = restrictions on the number of contacts that a single SIP REGISTER = request may advertise. >=20 > 2. [Typo] throughout =C2=A7 4.1.4, there are three (!!!) incorrect = mentions of the "sip.pnsreq" feature-capability indicator (notice it = ends with a "q", not a "g"!). It was confusing at first, until I = realized it's a typo. Fixing it would definitely be a time saver for = everyone implementing the RFC. >=20 > 3. [Typo] =C2=A7 6.2.1: "even if 'pn-*'parameters" >=20 > notice a missing space " " before "parameters" >=20 > 4. [Typo] =C2=A7 4.1.5: >=20 > "... if the UA inserted a 'pn-provider' SIP URI parameter = [value!!] ..." >=20 > "If the UA did not insert a 'pn-provider' parameter [value!!] = ..." >=20 > Both of these statements are correct with "parameter value", not = "parameter". If we take a look at the paragraph above, it actually = talks about inserting a "parameter value". Given that "pn-provider" is = syntactically correct with or without a value, it is quite important to = be non-ambiguous here. >=20 > 5. [Typo] =C2=A7 5.4: "A proxy MUST use a separate Feature-Cap[s!!] = header field" >=20 > missing "s" >=20 > 6. [Typo] =C2=A7 7: "make sure that the initial request for = dialog[s??]" >=20 > extra "s" >=20 > 7. [Typo] =C2=A7 13: "Unless the PNS authenticates and authorizes the = [PNS??]" >=20 > Most likely, the authors meant "proxy" >=20 > Thank you, > Liviu >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu May 7 07:14:41 2020 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 502403A0412 for ; Thu, 7 May 2020 07:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 Kt4c_7Z4IKKM for ; Thu, 7 May 2020 07:14:36 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10044.outbound.protection.outlook.com [40.107.1.44]) (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 0128C3A00C0 for ; Thu, 7 May 2020 07:14:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mu5NH8Yc8YrEwhkq/wa9pdvvzDQ9egdkV9ckivVrBKa64M540Y4zwwKVRJ+FxttAzh73ZCPsthogkG7l7CHV74gNpClVtcntL/PSW4BGj9nCVQHcfwBPJQB0JBHY4uaWJ6Uhx1RdjJ/34XMrXlNziRNZD83WnEgaXAucSvoyAXQXT69cMsx0LRDTNbGRscEDNG+oKNLIQ4RUBJ8htiYzImT9jhMbNVG1mT9Vp65FuvkX2KADN8xZFUpqsqYuQQgmQmqD+ibG2SgLz45AFaOI4LmlsoiVItjMr5AAyMBNirxqR28NubAvOB3c1LkvhtwowxFOOW6kUaPI1c4rq/D9TQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=14GD0q28UFu+/mUMHhIlSJB1cHZoB4QWnqgJOpCw/ug=; b=XFfK6wC7yTUmNOUgN8GZ+cYhqtFQC3OarjQNtC/oS1Oh5Y9YS+9QibU5MxFzd1b9x4rJbVZQrjIzuh5HlzG4S+hvOlEwLRj9mcHsO4DBCLgC8UlcLsm5YUrVOiTYNmwZ/prONB1JW9sXNtadwdpooEDKV+XHtOeAjrXR5tEzrrsipFGS+Wrd/ECleu3n2F96frf5zd1/yZbU/llY1s/rxkQKwXFAkpMelp78t2DFMtSsr7qxCYXYK3D2Neo009mrCyB9QCqc/HcJctuZlzPsyTcB6cfGZdqCSTJSmRatcdut4R6VoDAyHNRX53WUr/8Vd5KDsGr+IJ52uIyiY740LA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=14GD0q28UFu+/mUMHhIlSJB1cHZoB4QWnqgJOpCw/ug=; b=eFW3Z0Asw9tr78L+VCgoz+5vZ/kO8LGNt6zqdIzg8Zp1CafYp5a2iMj0VqsDfp08OWDTpq1ynhEEWa8791PFZM5oBmydamvxZjXxSKxL/U69+HXRzTdgj+9ca3w+xtskRiYBaS+LuwKKGyixjhrA04L0iWJ6YBin45rTN/mW/ZI= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6229.eurprd07.prod.outlook.com (2603:10a6:20b:138::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Thu, 7 May 2020 14:14:33 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.011; Thu, 7 May 2020 14:14:33 +0000 From: Christer Holmberg To: Liviu Chircu , "sipcore@ietf.org" Thread-Topic: [sipcore] RFC 8599 (SIP PN): Feedback & Nitpicking Thread-Index: AQHWJGWivkFqFV5og0q3eISLcgoclaic3ScA Date: Thu, 7 May 2020 14:14:33 +0000 Message-ID: References: <225394ea-1a37-d3e1-48f6-a89567b82e98@opensips.org> In-Reply-To: <225394ea-1a37-d3e1-48f6-a89567b82e98@opensips.org> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 authentication-results: opensips.org; dkim=none (message not signed) header.d=none;opensips.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [85.131.104.168] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d6f29c1-71ab-4a8d-9723-08d7f290f76d x-ms-traffictypediagnostic: AM7PR07MB6229: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714; x-forefront-prvs: 03965EFC76 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Nckq7jbgFGb3bH3xwOkVxmMo2piXke9uI8cqgzObFJ+WDDYi9pGAz1zCenYbHlKaydaQY8flO3nidwak+VqkjdW6nTpXxga1edHkszsOR9WafgsvZsqawl2RjXJz0bSPB0VvqVRGHoif0KpDmGPwpQajZSmMvHNQO4TIOFTOu5JQtVozkYtrAS/qxw5vFyejRSO3nwISX9w3XjFPwv5hqCHmy7gJ7vJ4ryTZo7TYgUt2CSiUWQiO8T7eGFwlyCIyBwtkaRo6rg4JEKTDrm875NBvh5TvBJZrJwrVsxwZ9TbAhDD6Igta2VoRIRUsqhYKR0A3X5JTFeg8i7X2mUaWEJDTrA8x24GNeV6tIS2jnyYt4u6KmtzSU0lPEAiWglNq0+7y7Z8Y0i/cKvO7ifG6P0eWYELLEwcPzcfM4jRvnaNVhm9yaohLkQVWQa42oPl8eiFv3+N1yMZjYjELCO5INkZcchM7MQz8/Qt0S4+peRBiZoWSMTM6Pf1r2lXb+KxWxXzTwy1BidN9Nj6BG48f9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(376002)(366004)(136003)(396003)(33430700001)(5660300002)(66946007)(33440700001)(316002)(86362001)(6512007)(44832011)(2906002)(83300400001)(6506007)(2616005)(83320400001)(83280400001)(83310400001)(83290400001)(110136005)(8936002)(33656002)(71200400001)(66556008)(478600001)(66476007)(64756008)(36756003)(91956017)(66446008)(76116006)(26005)(8676002)(186003)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: tv6qpWyWM/Z7mkWXjDpQIpifIcJe+pcLmBhJ1f2HT6XT41RWMB6pTDCXl0fkpryYIpWNC1WFrBC40Zq4risDeesK+EzKl8cbBZIroYCjpWkDScpph5WRehaTCctTDJ3aD8te89Y/FW2vUJKH6kxehnhUpVwrwYhWPd7b5uI9/Rc9JHgSaJt1gVjo5/XLcRxJv98LaNq1d3yGMDILsxLB5nyaP+oY/7sW1s53eOTRlmv1cXVC4NUSg50uj6x5F81Jlsgfb5enMNFCY/yGkpSywDHVvAaW1L4P8EeKMYHH/l2b80hx0mmSFjNUeL1ML0cpd61uSpTr3aRbieJh24GVsTgUL0ndLxfNnPQOgclYUgANpRggjY0dradRRPtPx3AWH3GN83hL+hKJZk0lMLClQf+z1dm71z04IhnYjoyOmZgBHV5WEINs8UwDRvrR1nsZ10d1V2JgVfOPi/Na6wYpr0RS0lJQdyPCzauu1Cv4bMUDrpau+P+X3w1Fb7IhDdYC88AAxz8vnIEh7xtY2QSDyeeltKiN7qpJqOVZBDzF8MPla5svMLlqTp5jXjrpp3nqrR57OO/kNERgr12Fwnnd6FTBoLkMfJpriStvsnryFWyzhhiRCwN4XpgIyyofEy6Q4dHLVmpBzA88xH2zcVHBHW4sW6hgsHLJOrzBqCDo+unYPVW8dv2f6Ag0C9fKWJ2nnALHgq271Wzf0ZeEJK1VGlFXRRc8ftSaaFCijSTUDGY60jG+VOst4i6i8Xywltv/GEbKeuXO/QT5rI1ckqm8CezxW5Qw9oY6Foe+xbGFkCU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d6f29c1-71ab-4a8d-9723-08d7f290f76d X-MS-Exchange-CrossTenant-originalarrivaltime: 07 May 2020 14:14:33.5506 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zL7d0oqmUZzigzmg7ygIhpbhuIRvD8ehzmYrafrs216RRRHzyZSehtvXfeeVIFWsrfQ0A1jRNJyCx1EW/oia29Yle577FExj4EmaOSTvVOk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6229 Archived-At: Subject: Re: [sipcore] RFC 8599 (SIP PN): Feedback & Nitpicking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 14:14:39 -0000 SGkgTGl2aXUsDQoNClRoYW5rIFlvdSBmb3IgdGhlIGNvbW1lbnRzISBQbGVhc2Ugc2VlIGlubGlu ZS4NCiAgICANCj4gICAgMS4gW1F1ZXN0aW9uL05pdHBpY2tdIGdpdmVuIHRoYXQgIitzaXAucG5z cHVyciIgaXMgYSB1bmlxdWUgRmVhdHVyZS1DYXBzIA0KPiAgICBpbmRpY2F0b3IgYW5kIHRoYXQg dGhlcmUgY2FuIG9ubHkgYmUgYSBtYXhpbXVtIG9mIDEgRmVhdHVyZS1DYXBzIGhlYWRlciANCj4g ICAgZmllbGRzIHBlciB1bmlxdWUgUE5TIChlLmcuICJmY20iKSBpbiBhIFNJUCBSRUdJU1RFUiwg aXQgdGhlbiBsb2dpY2FsbHkgDQo+ICAgIGZvbGxvd3MgdGhhdCBhIFBOIFNJUCBSRUdJU1RFUiBj YW4gb25seSBob2xkIG1heCAxIHggQ29udGFjdCBoZWFkZXIgDQo+ICAgIGZpZWxkIHZhbHVlcyBw b2ludGluZyB0byBhIGdpdmVuIFBOUyAodXNpbmcgdGhlICI7cG4tcHJvdmlkZXI9ZmNtIiBVUkkg DQo+ICAgIHBhcmFtZXRlcikuDQo+ICAgIA0KPiAgICBTbyB0aGUgcXVlc3Rpb24gaXM6IHNob3Vs ZCB0aGUgdGV4dCBtZW50aW9uIHRoaXMgZXh0cmEgU0lQLWxldmVsLCANCj4gICAgbG9naWNhbCBy ZXN0cmljdGlvbj8gIEJlY2F1c2UsIGNvbWluZyBpbnRvIHRoaXMgUkZDLCB0aGVyZSB3ZXJlIG5v IA0KPiAgICByZXN0cmljdGlvbnMgb24gdGhlIG51bWJlciBvZiBjb250YWN0cyB0aGF0IGEgc2lu Z2xlIFNJUCBSRUdJU1RFUiANCj4gICAgcmVxdWVzdCBtYXkgYWR2ZXJ0aXNlLg0KICANCkkgYW0g bm90IHN1cmUgSSB1bmRlcnN0YW5kIHRoZSB1c2UtY2FzZS4gIA0KDQotLS0NCg0KPiAgICAyLiBb VHlwb10gdGhyb3VnaG91dCDCpyA0LjEuNCwgdGhlcmUgYXJlIHRocmVlICghISEpIGluY29ycmVj dCBtZW50aW9ucyANCj4gICAgb2YgdGhlICJzaXAucG5zcmVxIiBmZWF0dXJlLWNhcGFiaWxpdHkg aW5kaWNhdG9yIChub3RpY2UgaXQgZW5kcyB3aXRoIGEgDQo+ICAgICJxIiwgbm90IGEgImciISku ICBJdCB3YXMgY29uZnVzaW5nIGF0IGZpcnN0LCB1bnRpbCBJIHJlYWxpemVkIGl0J3MgYSANCj4g ICAgdHlwby4gIEZpeGluZyBpdCB3b3VsZCBkZWZpbml0ZWx5IGJlIGEgdGltZSBzYXZlciBmb3Ig ZXZlcnlvbmUgDQo+ICAgIGltcGxlbWVudGluZyB0aGUgUkZDLg0KICANCkNvcnJlY3QuIA0KDQpX ZSBhbHdheXMgdHJ5IHRvIGF2b2lkIHRoZXNlIGtpbmQgb2YgdHlwb3MgdG8gaGFwcGVuLCBidXQg dW5mb3J0dW5hdGVseSB0aGV5IGRvIG9jY3VyIGZyb20gdGltZSB0byB0aW1lLg0KDQotLS0NCg0K PiAgICAzLiBbVHlwb10gwqcgNi4yLjE6ICJldmVuIGlmICdwbi0qJ3BhcmFtZXRlcnMiDQo+ICAg IA0KPiAgICAgICAgIG5vdGljZSBhIG1pc3Npbmcgc3BhY2UgIiAiIGJlZm9yZSAicGFyYW1ldGVy cyINCiANCkNvcnJlY3QuIA0KDQotLS0NCiAgIA0KPiAgICA0LiBbVHlwb10gwqcgNC4xLjU6DQo+ ICAgIA0KPiAgICAgICAgICAgICAiLi4uIGlmIHRoZSBVQSBpbnNlcnRlZCBhICdwbi1wcm92aWRl cicgU0lQIFVSSSBwYXJhbWV0ZXIgDQo+ICAgIFt2YWx1ZSEhXSAuLi4iDQo+ICAgIA0KPiAgICAg ICAgICAgICAiSWYgdGhlIFVBIGRpZCBub3QgaW5zZXJ0IGEgJ3BuLXByb3ZpZGVyJyBwYXJhbWV0 ZXIgW3ZhbHVlISFdIC4uLiINCj4gICAgDQo+ICAgIEJvdGggb2YgdGhlc2Ugc3RhdGVtZW50cyBh cmUgY29ycmVjdCB3aXRoICJwYXJhbWV0ZXIgdmFsdWUiLCBub3QgDQo+ICAgICJwYXJhbWV0ZXIi LiAgSWYgd2UgdGFrZSBhIGxvb2sgYXQgdGhlIHBhcmFncmFwaCBhYm92ZSwgaXQgYWN0dWFsbHkg DQo+ICAgIHRhbGtzIGFib3V0IGluc2VydGluZyBhICJwYXJhbWV0ZXIgdmFsdWUiLiAgR2l2ZW4g dGhhdCAicG4tcHJvdmlkZXIiIGlzIA0KPiAgICBzeW50YWN0aWNhbGx5IGNvcnJlY3Qgd2l0aCBv ciB3aXRob3V0IGEgdmFsdWUsIGl0IGlzIHF1aXRlIGltcG9ydGFudCB0byANCj4gICAgYmUgbm9u LWFtYmlndW91cyBoZXJlLg0KDQpDb3JyZWN0LiAicGFyYW1ldGVyIHZhbHVlIiB3b3VsZCBoYXZl IGJlZW4gY29ycmVjdC4NCg0KLS0tDQogIA0KPiAgICA1LiBbVHlwb10gwqcgNS40OiAiQSBwcm94 eSBNVVNUIHVzZSBhIHNlcGFyYXRlIEZlYXR1cmUtQ2FwW3MhIV0gaGVhZGVyIGZpZWxkIg0KPiAg ICANCj4gICAgICAgICBtaXNzaW5nICJzIg0KICANCkNvcnJlY3QuDQoNCi0tLQ0KICANCj4gICAg Ni4gW1R5cG9dIMKnIDc6ICJtYWtlIHN1cmUgdGhhdCB0aGUgaW5pdGlhbCByZXF1ZXN0IGZvciBk aWFsb2dbcz8/XSINCj4gICANCj4gICAgZXh0cmEgInMiDQoNCkkgZ3Vlc3MgaXQgc2hvdWxkIGJl ICJmb3IgYSBkaWFsb2ciLg0KDQotLS0NCiAgICANCj4gICAgNy4gW1R5cG9dIMKnIDEzOiAiVW5s ZXNzIHRoZSBQTlMgYXV0aGVudGljYXRlcyBhbmQgYXV0aG9yaXplcyB0aGUgW1BOUz8/XSINCj4g ICAgDQo+ICAgIE1vc3QgbGlrZWx5LCB0aGUgYXV0aG9ycyBtZWFudCAicHJveHkiDQoNClllcy4N Cg0KLS0tDQoNClRoYW5rIFlvdSBmb3IgdGhlIGNvbW1lbnRzISBVbmZvcnR1bmF0ZWx5IHdlIGFy ZSBub3QgYWJsZSB0byBmaXggdGhlbSBpbiB0aGUgYWN0dWFsIGRvY3VtZW50ICh3ZSB3b3VsZCBo YXZlIHRvIHN0YXJ0IHdvcmtpbmcgb24gYSBuZXcgdmVyc2lvbiBvZiB0aGUgc3BlY2lmaWNhdGlv bikuIA0KDQpCdXQsIGl0IElTIHBvc3NpYmxlIHRvIGNyZWF0ZSBhbiBlcnJhdGEsIHdoZXJlIHRo ZSBlcnJvciBhbmQgc3VnZ2VzdGVkIGZpeCBhcmUgZGVzY3JpYmVkLg0KDQpOb3Qgc3VyZSBpZiB3 ZSB3b3VsZCBvcGVuIGFuIGVycmF0YSBqdXN0IGZvciBmaXhpbmcgMywgNSBhbmQgNi4gQnV0LCBi dXQgMiwgNCBhbmQgNyB3b3VsZCBwcm9iYWJseSBiZSB3b3J0aCBmaXhpbmcuIEkgc3RpbGwgbmVl ZCB0byB1bmRlcnN0YW5kIDEgYmV0dGVyIDopDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQogDQoN Cg== From nobody Thu May 7 07:41:09 2020 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 6BEB93A00B2 for ; Thu, 7 May 2020 07:41:08 -0700 (PDT) X-Quarantine-ID: <7FIoKc7U8-XJ> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Improper folded header field made up entirely of whitespace (char 20 hex): X-Spam-Report: ...that system for details. Content previ[...] X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 7FIoKc7U8-XJ for ; Thu, 7 May 2020 07:41:05 -0700 (PDT) Received: from mail.opensips.org (opensips.org [136.243.23.236]) (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 527803A003D for ; Thu, 7 May 2020 07:41:05 -0700 (PDT) Received: from [89.45.16.83] (helo=[192.168.0.199]) by mail.opensips.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1jWhgy-0006c1-Bp for sipcore@ietf.org; Thu, 07 May 2020 14:40:05 +0000 To: "sipcore@ietf.org" References: <225394ea-1a37-d3e1-48f6-a89567b82e98@opensips.org> From: Liviu Chircu Message-ID: Date: Thu, 7 May 2020 17:40:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------442B21F75AB4B88FC95FC092" Content-Language: en-US Archived-At: Subject: Re: [sipcore] RFC 8599 (SIP PN): Feedback & Nitpicking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 May 2020 14:41:09 -0000 This is a multi-part message in MIME format. --------------442B21F75AB4B88FC95FC092 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07.05.2020 17:14, Christer Holmberg wrote: >> 1. [Question/Nitpick] given that "+sip.pnspurr" is a unique Feature-Caps >> indicator and that there can only be a maximum of 1 Feature-Caps header >> fields per unique PNS (e.g. "fcm") in a SIP REGISTER, it then logically >> follows that a PN SIP REGISTER can only hold max 1 x Contact header >> field values pointing to a given PNS (using the ";pn-provider=fcm" URI >> parameter). >> >> So the question is: should the text mention this extra SIP-level, >> logical restriction? Because, coming into this RFC, there were no >> restrictions on the number of contacts that a single SIP REGISTER >> request may advertise. > > I am not sure I understand the use-case. The only use-case that I see here would be a device which registers both an UDP and a TLS Contact by including them into the same REGISTER.  If each of these contacts is parameterized using "pn-provider=fcm", for example, the PN proxy has no way of returning 2 x "+sip.pnspurr" Feature-Caps values for each newly created binding, since RFC 8599 seems to restrict it in a way that a maximum of 1 PURR per PNS can be returned at a time inside a Feature-Caps.  Please correct me if I'm wrong here! I have no idea how realistic the above is, nor do I care, frankly (I am quite OK with the restriction).  My opinion is coming from the implementation standpoint, where I aim to capture all the edge-cases and implement the spec with maximal acceptance for the input SIP format. Thank you, Liviu --------------442B21F75AB4B88FC95FC092 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 07.05.2020 17:14, Christer Holmberg wrote:
   1. [Question/Nitpick] given that "+sip.pnspurr" is a unique Feature-Caps 
   indicator and that there can only be a maximum of 1 Feature-Caps header 
   fields per unique PNS (e.g. "fcm") in a SIP REGISTER, it then logically 
   follows that a PN SIP REGISTER can only hold max 1 x Contact header 
   field values pointing to a given PNS (using the ";pn-provider=fcm" URI 
   parameter).
   
   So the question is: should the text mention this extra SIP-level, 
   logical restriction?  Because, coming into this RFC, there were no 
   restrictions on the number of contacts that a single SIP REGISTER 
   request may advertise.

  
I am not sure I understand the use-case.

The only use-case that I see here would be a device which registers both an UDP and a TLS Contact by including them into the same REGISTER.  If each of these contacts is parameterized using "pn-provider=fcm", for example, the PN proxy has no way of returning 2 x "+sip.pnspurr" Feature-Caps values for each newly created binding, since RFC 8599 seems to restrict it in a way that a maximum of 1 PURR per PNS can be returned at a time inside a Feature-Caps.  Please correct me if I'm wrong here!

I have no idea how realistic the above is, nor do I care, frankly (I am quite OK with the restriction).  My opinion is coming from the implementation standpoint, where I aim to capture all the edge-cases and implement the spec with maximal acceptance for the input SIP format.

Thank you,
Liviu

--------------442B21F75AB4B88FC95FC092-- From nobody Sun May 10 06:12:44 2020 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 41C0C3A096E for ; Sun, 10 May 2020 06:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 WaD7o9fdXEQL for ; Sun, 10 May 2020 06:12:37 -0700 (PDT) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) (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 51CC33A096C for ; Sun, 10 May 2020 06:12:37 -0700 (PDT) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id EBE82E0112 for ; Sun, 10 May 2020 13:12:35 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=HX6zy6yPJU3dL/92c1055ljjLz7wynkXpu47rr9pWoo=; b=iaV0Hrvn3ko8CbKFmoFiG0YptQ4nZB2S0Z/p/eXjfYUUFCMa7oBao4uDUXzghAM/CVfJiAosD0vZKzQE47MPPN4Mb08n03j7ZTo3MtwO9Glbr1pnEasdcSm24LlDSQNrIEG1fXSvCRW2k8IKVujIpNx9ElG7Qny2xxvSD6nXeGeL71A33Ic/CrFoes+WktucgOmoXJlqWs2B3zRqzJLL4/FSUP2BLQBTIQ1Og5kls4FyjdJMT1CUgZ72W6a3FldaqRzjUTn0QAbzNpUC4l5tbNlqLddr3bL+s3Pmpp9B+hby96kAEXfn608QWYr2s7jbpVmBlXjfqmBkxDaiIpwrdQ== Received: from smtp.hushmail.com (w1.hushmail.com [65.39.178.83]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS for ; Sun, 10 May 2020 13:12:35 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 8E2A6C0171; Sun, 10 May 2020 13:12:35 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 10 May 2020 19:12:35 +0600 To: sipcore@ietf.org From: "Samir Srivastava" Content-Type: multipart/alternative; boundary="=_a22f43deb24f90205e232109ea8b70df" Message-Id: <20200510131235.8E2A6C0171@smtp.hushmail.com> Archived-At: Subject: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 13:12:42 -0000 --=_a22f43deb24f90205e232109ea8b70df Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, The table mentioned in Section 4 in RFC 4028 does not contain entries for REFER, PUBLISH and MESSAGE methods Below is the table from Section 4 +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ They are not applicable for these, but it would have been better if it is said categorically. ThanksSamir Srivastava https://samirsrivastava.typepad.com/ --=_a22f43deb24f90205e232109ea8b70df Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,=

  The table mentioned in Section 4 in RFC 4028 doe= s not contain entries for REFER, PUBLISH and MESSAGE methods Below is the t= able from Section 4


   +---------------+-----+-----+---+---+---+---+---+---+---+-=
--+---+---+
   |     Header    |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
   +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
   |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - | - |
   |               |     |     |   |   |   |   |   |   |   |   |   |   |
   |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - | - |
   |               |     |     |   |   |   |   |   |   |   |   |   |   |
   |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - | - |
   |               |     |     |   |   |   |   |   |   |   |   |   |   |
   |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - | - |
   +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
  They are not applicable for these, but it would have b= een better if it is said categorically.

Thanks
Samir Srivastava

--=_a22f43deb24f90205e232109ea8b70df-- From nobody Sun May 10 06:35:56 2020 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 EC62D3A0990 for ; Sun, 10 May 2020 06:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 7fotUk_PAtnk for ; Sun, 10 May 2020 06:35:51 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70077.outbound.protection.outlook.com [40.107.7.77]) (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 79BA33A098E for ; Sun, 10 May 2020 06:35:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LelouahjoETsVdUOiy/I31TebmVrW25lh01SfKDws2IYeooI1PTi4vXQfQAZZ5SkgLo73dMcwCIaXpXnxUtpUTU1v60y0Dd8lB3MlQTMICClDVf6N+jaHj0x+cGVTahmHy2C3bHYbP4UO0QRisoaZN3F4Ybumqv6pdT//k0305L3yvCuajGFL/i0ISGwIzea0aYPjawT//cxLDW+7w1ON3p0+TpQ3ZsYLrS9Z4zfrQnVdkhYo6U8Tx+z6B0q/uQsx9PYiV++iXK2ews0wwkz0fdw3LncS0vw4X+VswxZJSSDLSxl5td+fcKydEtOKAiZ/xgAMYY90Rno/7h4MN7row== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cb2rq2uyXmCVDNso/vAN02Qr6YZ8hlxCOLPGs9RhBzU=; b=UTPMrKetkW8TxSrWhbk8+5L73Z2G3sKeT3lUy1mTMigNv4dzXUOfm/65W4GT0YGbsfys+8HJkiouYgvCuDtT3+kBX3S+CZyD4aTVVGpIRw/oPVvZSebMD120bDTZJin7ltMphj0nECXK0cd7ZsUjhx9ZQjr3Z+yGTU1yx28ppIDIBr9EFhI9Ez9NcDCDbdpLAcdorn0/7sca+8LJUe5RJyuHa1vwyXv3nG2Z2r4WEobM6413cQDa8X8yzakWhRsNuc3JCqm6L0Xf45f5aIPtkZxDvJqrUFOYU8MRWOQ88yOIUfu9xgBEv/l4jzMC8K1s5gCljgrWcfj8qNMCaRxPfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Cb2rq2uyXmCVDNso/vAN02Qr6YZ8hlxCOLPGs9RhBzU=; b=O164OYDGKBogxUaUO9tnpbUTN1T33LwyeFJlYh127O4MlAeylxFUwcx3R61TfAj7OZXZ0rK6XBlRF59VLv8ovz6eSay2uK+n7XAJfBPAqLqwbcw+XsZMwQI6dbLJrwCO4fsIV3wtJxfhzNk/KdM1yMCGnKD2odvjUNybioMMpbo= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6833.eurprd07.prod.outlook.com (2603:10a6:20b:1b8::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.15; Sun, 10 May 2020 13:35:48 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Sun, 10 May 2020 13:35:48 +0000 From: Christer Holmberg To: Samir Srivastava , "sipcore@ietf.org" Thread-Topic: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined Thread-Index: AQHWJsy7Tb3AmLI5VEauNVgVXU0GX6ihUf7I Date: Sun, 10 May 2020 13:35:48 +0000 Message-ID: References: <20200510131235.8E2A6C0171@smtp.hushmail.com> In-Reply-To: <20200510131235.8E2A6C0171@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 08f0873f-3dbd-4ff1-368e-08d7f4e70cde x-ms-traffictypediagnostic: AM7PR07MB6833: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 039975700A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eMnH8KOnJH77Je9sL3b4smSPRNZCZJrZPL/9nDT5y2g9hNbDTgKK7wTy9svvPZKDlkAVUN1k6Ka1YjrpjCdPdV8AJADp7mmRXISl/0xukhFigeQ1ubJye3o843YeFFUMLQ6LDCRqVM0PPhcH33OjHrtu4jg891OFalDh5o9cwEvojeNYX3plJa913ap26gXC3o1aXlQRiRdA/u/Go45+XjhCnuVNOpcXgILQlnn0dCLhbLj3yTVfPvmMV1H7mwGrwZD3GCRPF3FVe0wD6lGiDLw6QYxy2kxYfLpJPNW3pL9N+aVcfhzN0C/NCM1bbkwLozYQ0wALQzRi9TllyJd9N8v8Xkgmuu3RtAsMP8tvhJ+RFhhs2hV8WQ1UkdHeG++/gAFHWpiESSPahTFFAQg7loKmj/8PBDx3irNmtwFKeBYGdHnNBOJVrciDMVSOthmdLVfbEZG94tYjG2QxZRlufm05mS1reT0kiY4+E58YsqyYcA1C/iZvB5ihr1VorNTaFxokrHD/3JwtWZZFyVws6cSR+gZMVPmTZbJ8i7L+U7qVkefxbuIK13iQnoCVRAHU x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(346002)(396003)(39860400002)(366004)(376002)(33430700001)(66476007)(66556008)(66446008)(6506007)(64756008)(26005)(52536014)(186003)(2906002)(71200400001)(15650500001)(33656002)(66946007)(478600001)(110136005)(53546011)(966005)(316002)(9686003)(5660300002)(7696005)(8936002)(19627405001)(33440700001)(8676002)(86362001)(166002)(44832011)(55016002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: as9Nbh4CXA1C7+tkAuK82fBry4o/faTvKiglKfWxxV6yeoDd8MVosETrpsPIWFHu/k+GXaw72E6Z3TwRTyO8Vc+IXzxRbEQ9zXV/8nuuW6rq/qaB89Lht+GqvAL89XrI+purEBadUqJf3/xUjPu2w/m8RW+4zuXGAQHYEYLElKFyn7SaR/hlhgDGn5XM/s8+/0kiUNKBbkmPKuBWjufRxPHzNsLFIrUbF0/gKUztllpTMerJXkvdntUDsuyZzQfAKc59gE6YHpuID8PieeG2N5UCqIMh9X1wTL9xIEiJDd3xPBp1cwhGZOvivNF7fvx2VZq5mZNB66NUkHw/Y4HXmgTEssMildolcURUBgS33pY988jIeBufG0+zJILpDOqJjea0aLmlInECNzCoIiwQt7Es5ptd1t1PCUcHLjNKeAn/hvjJFpnBaxaedX7XkZqqdblga4kIfwruqkFwXDSSCekmBw6fMxaGZ8jcpqGi0C6EE8qVW+/76h4L7vmvl07g x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR07MB70125BF158F1B14DA58C4B3D93A00AM7PR07MB7012eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 08f0873f-3dbd-4ff1-368e-08d7f4e70cde X-MS-Exchange-CrossTenant-originalarrivaltime: 10 May 2020 13:35:48.5970 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4mBOfeJLeYwYSsLaDfOqFcS1cDU9nH7RHggGvMsdTpm7/ldwTiq8yDr+luJKIViDhl/iRppXPZwlEtHchqoBadITFvzSuM6Dv6C0slXBJAI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6833 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 13:35:54 -0000 --_000_AM7PR07MB70125BF158F1B14DA58C4B3D93A00AM7PR07MB7012eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Samir, Note that there is work ongoing to create a new version of the session-time= r specification, so this is one thing that could be clarified in the new sp= ec. Regards, Christer ________________________________ From: sipcore on behalf of Samir Srivastava Sent: Sunday, May 10, 2020 4:12 PM To: sipcore@ietf.org Subject: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE no= t defined Hi, The table mentioned in Section 4 in RFC 4028 does not contain entries for= REFER, PUBLISH and MESSAGE methods Below is the table from Section 4 +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | | | | | | | | | | | | | | | |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ They are not applicable for these, but it would have been better if it is= said categorically. Thanks Samir Srivastava https://samirsrivastava.typepad.com/ --_000_AM7PR07MB70125BF158F1B14DA58C4B3D93A00AM7PR07MB7012eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Samir,

Note that there is work ongoing to create a new version of the session-time= r specification, so this is one thing that could be clarified in the new sp= ec.

Regards,

Christer

From: sipcore <sipcore-b= ounces@ietf.org> on behalf of Samir Srivastava <srivastava_samir=3D40= hush.com@dmarc.ietf.org>
Sent: Sunday, May 10, 2020 4:12 PM
To: sipcore@ietf.org <sipcore@ietf.org>
Subject: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MES= SAGE not defined
 
Hi= ,

  The table mentioned in Section 4 in RFC 4028 does not contain e= ntries for REFER, PUBLISH and MESSAGE methods Below is the table from Secti= on 4


   +--------=
-------+-----+-----+---+---+---+---+---+---=
+---+---+---+---+=0A=
   |     Header    |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|=0A=
   +---------------+-----+-----+---+---+---+---=
+---+---+---+---+---+---+=0A=
   |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - | - |=0A=
   |               |     |     |   |   |   |   |   |   |   |   |   |   |=0A=
   |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - | - |=0A=
   |               |     |     |   |   |   |   |   |   |   |   |   |   |=0A=
   |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - | - |=0A=
   |               |     |     |   |   |   |   |   |   |   |   |   |   |=0A=
   |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - | - |=0A=
   +---------------+-----+-----+---+---+---+---=
+---+---+---+---+---+---+
  They are not applicable for these, but it would have been bette= r if it is said categorically.

Thanks
Samir Srivastava

--_000_AM7PR07MB70125BF158F1B14DA58C4B3D93A00AM7PR07MB7012eurp_-- From nobody Sun May 10 10:00:06 2020 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 B161C3A0A9F for ; Sun, 10 May 2020 10:00:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 SHeAAuydmcVC for ; Sun, 10 May 2020 10:00:00 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690047.outbound.protection.outlook.com [40.107.69.47]) (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 AC9A73A0AA3 for ; Sun, 10 May 2020 10:00:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mOKnwf4Q32U49+sJVEO+NCzLzALcSHdsVMjxUL2FIwoQrYTMSCrfvH3nU17dx9S3gvnn8WI4jCppZaKsZ/fQUnR2h/D0LVDM7PjeTeG893Ojn/33lsq9r4WME/j0HuDREaAc4LGdybBVRyziY/hb4sdrWb9u1HC/JkD3I7w01GwVzupA5mtS3YhBVVfxVzgVU6wivdOASGEgx2QIqd+QV64uqHFvnEfpstt4DLTtCgM3REz8x1he7K11Je4eicaahAbJEaoYZrhCgyizVxR2LKHVcfmLIKTO8r2RG1OWopp8ZfzEzgCLhptUsF4g+tMWncMILfjgtSAKY0C+d1B0JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lYSwJchWGLx2vdjtt0fblQONgjNRwdM1KR9kutfeCAk=; b=oHL3FTKXndAqkg3/XLl/80xyI3BLT2ohesC21VCDjHrjo4kFVjUana6waq3i/NVFiB7PkLYC4cIpjQE7XTuHBD8bXRS3opPa2Z3Om4QOyCW/LIduPny/QgSsjSDBRTW1Y6xXo0YVxLyqlc4Kh3sh+3pjboP/snCGd2mm1LoEereThN5AvioQZjiilaQYNcNNxIfe626PQxOUBaVwman8jnCaUS+tksLOQSUF5yVL7+H6d4wOCH3/peeXLmPJ620wfJYQmBo+m+4dKDmfE8uS7QOU986nT56p8VGbd6xVnGTegYxvoyXFW21k9XJSZs3D29Yom/Hy2FuYOfZaFyy4/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lYSwJchWGLx2vdjtt0fblQONgjNRwdM1KR9kutfeCAk=; b=d31RJSv9T38hQziM/3m5f51w5NjvyW9EbOmaySnDv5oPauKw4WpogVUVGSyPcN+QU2QHLsZaO68vXvBaED5vg/eA3t4q9tws9iFzvHCa51mCy7AmZV6WWZ/cLBPGe1yLnYubuyX25sZLbTq9WHs3unLcPAsxYrQ68Nt5pCKYryQ= Received: from BL0PR05CA0016.namprd05.prod.outlook.com (2603:10b6:208:91::26) by DM6PR12MB2666.namprd12.prod.outlook.com (2603:10b6:5:4d::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.35; Sun, 10 May 2020 16:59:58 +0000 Received: from BL2NAM02FT019.eop-nam02.prod.protection.outlook.com (2603:10b6:208:91:cafe::16) by BL0PR05CA0016.outlook.office365.com (2603:10b6:208:91::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11 via Frontend Transport; Sun, 10 May 2020 16:59:58 +0000 Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT019.mail.protection.outlook.com (10.152.77.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Sun, 10 May 2020 16:59:57 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 04AGxtKK001537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 10 May 2020 12:59:57 -0400 To: sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> From: Paul Kyzivat Message-ID: <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> Date: Sun, 10 May 2020 12:59:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200510131235.8E2A6C0171@smtp.hushmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(136003)(396003)(39860400002)(376002)(346002)(46966005)(33430700001)(53546011)(956004)(2616005)(75432002)(356005)(316002)(786003)(36906005)(478600001)(82310400002)(33440700001)(7596003)(186003)(70586007)(26005)(15650500001)(6916009)(31696002)(70206006)(82740400003)(8676002)(336012)(2906002)(5660300002)(47076004)(86362001)(8936002)(31686004)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7715aec4-bcd8-40da-8658-08d7f50391eb X-MS-TrafficTypeDiagnostic: DM6PR12MB2666: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-Forefront-PRVS: 039975700A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: o5HzdYl3gzC+3JXox1ry0fEJ2nnZfBBYvTfas8oas4xUbX0/EtESRTFasp0LYZhP1+gPCyhl/hECtzuqzKeA27d5mMoAF3J7DabeuxZiYmGKOeF1Cuk6mOJk1Q/2gLGqbxMFB/Di2+T410vYY/NyZKfKet+NH3zncJVhQj/3rzgjDPSLFsbZF+Q5BUabq1FqcLDymJRKMQ1DQxL42kNynzAKEg/nBk1jSgtfGqGlKVV9vI/MfcthtnM2FlZVnhA5Q65OCCk2Rv+MSA8jrZX4MCvO5yzazHaYmFh8o+3la9L59pi2Wk+0Y9qRFKS4DpJcxqTEsOKox8gtaD2l87/UjsoKgrqfGdAKrwn7Uu9G0iRBccJW5797j4zm9rilZMWR7ViPvF1N19HzqtSIfwl8WO11MmwPI4O1vPescfUlpENjeSTJpsID0JTUvOSJZjXG+W5rGXE1a9kdkOS4CLEv1BI9Hfw0Ouh4uMdlM/CdXjGzP4cZsI4c3R311F4giVoJoggvq9N7xgAb3/QNNkUzTtYnsJ/DuluiE2TnwDWIGXNARiR3Bf4rk5780OY4spxv5gOAyCAKfZvvicd7PmEdOCGakMOkiCu0utGBDy2IMUw= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2020 16:59:57.7483 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7715aec4-bcd8-40da-8658-08d7f50391eb X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2666 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 17:00:03 -0000 On 5/10/20 9:12 AM, Samir Srivastava wrote: > Hi, > >   The table mentioned in Section 4 in RFC 4028 does not contain entries > for REFER, PUBLISH and MESSAGE methods Below is the table from Section 4 > > > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | - | > | | | | | | | | | | | | | | > |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | - | > | | | | | | | | | | | | | | > |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | - | > | | | | | | | | | | | | | | > |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | - | > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >   They are not applicable for these, but it would have been better if > it is said categorically. IIRC, quite a long time ago it was decided that this table in 3261 was a bad idea, because it is essentially a summary of normative language in other sections of the document and is necessarily an approximation. After that, other work that updates and extends 3261 has been inconsistent it whether it updates the table or not. What we should be careful of is that the in progress update to session timers is clear, normatively and expositively, one way or another. Thanks, Paul From nobody Sun May 10 14:29:27 2020 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 E92533A0BDA for ; Sun, 10 May 2020 14:29:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 KfDSRz9ugpm9 for ; Sun, 10 May 2020 14:29:24 -0700 (PDT) Received: from know-smtprelay-omc-9.server.virginmedia.net (know-smtprelay-omc-9.server.virginmedia.net [80.0.253.73]) (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 B11B33A0BE8 for ; Sun, 10 May 2020 14:29:23 -0700 (PDT) Received: from [192.168.0.17] ([81.97.229.170]) by cmsmtp with ESMTPA id XtVhjO94lf1r6XtVhjYiU2; Sun, 10 May 2020 22:29:21 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=DOmhHRFb c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=RYBTwSCaLHl9b7ab2XwA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1589146161; bh=JUF6rfdXyDPRVV9rXeaifWBVa+yGuUTAQSnbTNRUwgU=; h=Subject:To:References:From:Date:In-Reply-To; b=M8+ihtAEe1xUga9ngBZ3Nf7WbXQwXMroRNis4XJW5YLu+xg8Ey6ODemiALAUaueFT PCdVuwzQRq+lHND0708ByVS+gLDscVaInMk6HlViGoCkmOXl6ywaxU/isSH+VjCXD8 9D9+Ttft7twHNXUolgPiYEvriC2593uc0jb0RKkA5ABNOqDXDeSxqZ20vUSfL3axRu GZNYlz4Andt6GDx91hffS2ftLZATALyc2VV5H8+9j09GEcRl77g/O2TCtQP67F14H8 eWsd77cV63dhq0GtSP07Dz+VsP04rMzDAx/e3yj1eiw1UoMVD1Wqj39aPi7y31X9ih uB9D6sLaVyXgQ== To: sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> From: Keith Drage Message-ID: <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> Date: Sun, 10 May 2020 22:29:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-CMAE-Envelope: MS4wfPMieHrFR9XiOxj/bmMjZVZG9QNSAeJ5hcVMRHeoaRlFKMa5XjbS1axSRCSQ0E7qg29OQ1enqCOpfBgfRkELkioIfANPTahiMvn7/HQjAO1XKJBnhccF Ee/dqCadWGZSxUUI8hQ5zZ+eEcvNTZy8jBChqrCe3L7WoAozhqnqra9h Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 21:29:26 -0000 I dont know whether we reached something we can formally describe as a decision, but the overall opion was that it should be the text that should normatively describe what the requirements were for the actions in respect of inclusion in messages. If these tables were included, they should be clearly described as informative. Further, the normative text should be adequately worded to encompass the understanding what happened when new messages were invented - so rather than specifically listing messages, it should probably talk about messages that create a dialog, etc. Keith On 10/05/2020 17:59, Paul Kyzivat wrote: > On 5/10/20 9:12 AM, Samir Srivastava wrote: >> Hi, >> >>    The table mentioned in Section 4 in RFC 4028 does not contain >> entries for REFER, PUBLISH and MESSAGE methods Below is the table >> from Section 4 >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>     |     Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - | >> - | >>     |               |     |     |   |   |   |   |   |   |   | |   |   | >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - | >> - | >>     |               |     |     |   |   |   |   |   |   |   | |   |   | >>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - | >> - | >>     |               |     |     |   |   |   |   |   |   |   | |   |   | >>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - | >> - | >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >>    They are not applicable for these, but it would have been better >> if it is said categorically. > > IIRC, quite a long time ago it was decided that this table in 3261 was > a bad idea, because it is essentially a summary of normative language > in other sections of the document and is necessarily an approximation. > > After that, other work that updates and extends 3261 has been > inconsistent it whether it updates the table or not. > > What we should be careful of is that the in progress update to session > timers is clear, normatively and expositively,  one way or another. > >     Thanks, >     Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Sun May 10 14:57:57 2020 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 D63A33A0BF7 for ; Sun, 10 May 2020 14:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 QAjNU6J_47pJ for ; Sun, 10 May 2020 14:57:51 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2063.outbound.protection.outlook.com [40.107.243.63]) (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 B27C93A0BF4 for ; Sun, 10 May 2020 14:57:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BTHm2+IpOVJZ0BqRR2WMn3H9jxk5ZaN0ZF8GSa7nHAjqdqP5NpjuDMnTrunYLzQWcyzWjhBgnzetxZ5zYd3gYb52gKCPgg+V/ZeqpdQBldfCU2XmOHm68tKdtSKhUA0Gd9NOZCheORwGAIOtJXvyYdNR2H35wujFYMFCGpUNpnBKvimDHxmwCA33CVCxLagMritMBqp5fsX/4nhSfmu0a/oxj+XaP/85psUlllcLPc5Xd0VztMSSpMnSBFOsZXqDcXW5lhTyfXE7UlpKATBx3y3ZLX+ENIcH3xss725PMAzJ5BaW7DCRE/U47nH0q1yC69mwyPbIIg0EdeManL/XPA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f6UQBaH+izwNLF1fNtzGYwgEeKhIlAPNk0aXkWiS1TE=; b=Ux07wLP5M/Q6yrRu08GbQ4CWtZOwDVLO3eXT2+YrR5oLhxcBqWrArfCzU4xWQG0cNl0U6tiug71n27qf2vzTywkNFFIk8bhGLb1JKHMjRm9EkHJ7acR7CSSFL3AhL9GRlhLrLjA8l3CUV7NYqHn2eputdvlC0MlUEeWgG6VIvVIZpdrszNy22EU6MmvY+B72h9CzOXuwVc4PIDvu8lng/0rzonuB/oLCR3UfcplVyNgBL3McMmEF3B3lye/i5HOw8Ib+Z5t5fvlQa663eIiEFS6CAGqTVFSL2yEqnrCBCsi7KXmJy6ak559yzUgHuzFRy0GD1MMA3U08/2XXrZ0mrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f6UQBaH+izwNLF1fNtzGYwgEeKhIlAPNk0aXkWiS1TE=; b=QgsdjYGcuz8sa1PkRaKnrRikQCSJZPAy6EBdmfRR6pEE9GiyBwZnOZRe1xwPc4532Qmf02l0sLo2L7Cl7HdDzTOFvpr/UsP3y7BTmUZvk3Wru9sGzsKvj46PNFTt6/9FanW6XJzPU207LyhrhnRG9qXWAml5X4oXg9rWcwlJCtM= Received: from SN4PR0601CA0007.namprd06.prod.outlook.com (2603:10b6:803:2f::17) by DM6PR12MB2699.namprd12.prod.outlook.com (2603:10b6:5:4a::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.34; Sun, 10 May 2020 21:57:48 +0000 Received: from SN1NAM02FT060.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2f:cafe::eb) by SN4PR0601CA0007.outlook.office365.com (2603:10b6:803:2f::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.27 via Frontend Transport; Sun, 10 May 2020 21:57:47 +0000 Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT060.mail.protection.outlook.com (10.152.72.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Sun, 10 May 2020 21:57:47 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 04ALvjEO022064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Sun, 10 May 2020 17:57:45 -0400 To: sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> From: Paul Kyzivat Message-ID: <78ac39f5-9689-27e1-9025-02d76ed01460@alum.mit.edu> Date: Sun, 10 May 2020 17:57:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(396003)(376002)(346002)(136003)(39860400002)(46966005)(33430700001)(8936002)(336012)(31696002)(75432002)(70206006)(70586007)(478600001)(26005)(5660300002)(186003)(966005)(956004)(31686004)(53546011)(8676002)(316002)(82310400002)(2616005)(356005)(2906002)(82740400003)(7596003)(33440700001)(6916009)(47076004)(86362001)(786003)(15650500001)(36906005)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d959b04e-9aa0-45c7-9807-08d7f52d2cf3 X-MS-TrafficTypeDiagnostic: DM6PR12MB2699: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 039975700A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 783IgE68Brz5GsrUE3IDI6neQ9wxcKitZn4ZdEWbd5vGKfjSKRfTe+Q4ZrLTx093kNEZ9ywrgEBuHK0EDCVsaJocsaR06l8C6cO/nwzgTE2tKoGgON+zhEW6hyARYTWO1CWpwFm6mv2QSBsolTVcPkmDyJbvP9mnLf1DE6XYCg6ZoiG1wGBNZic4AEcEJHE6fTHaZ2RvUP6v3/WEh+kSFeDfdfJPo0qX7jkM1V9/Dd7yu3Bv1SSsEsao7gcxFC3ECfV5kY6HMke5N+0KDJiUfQl3bomVBVpu4Bpuc1Y/hLneuYafy/Stri98NkxGBhb1bu7a0yH4gyLJK5zGGsUaGEwn/nMpFqYEZgFWTV1CpkrVurM83YG4lBe4ey6sLUZmQjRrMeAATi6qUL0ieoFjEr64hPyMqj3YD4uePKAa78qs+bfmMriGxjH2WhsmzNvk2KnvZ6SERwO3+EqV0sdlg6Ax1NEwIvgVr1qrvYRt7fMHcgWgFst9+QHDkYQQSW/Ak7Qe/03wwyUuMV9ash7SPw6049Jggas32C7ixFvaAVSmBTeAEoyF0Vmzh875PafmiegZvKRboNQOIoJJlXHhTfrfTavAu61am167aLA8M44JFL/d9At55imNDNdWOBU1Vjgf1PiQ/KcG3V4K6ov1ADmWFTqBel7APYXvSbcS0uwWovWBlQyMKl/wgzUFpP/q X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 May 2020 21:57:47.0900 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d959b04e-9aa0-45c7-9807-08d7f52d2cf3 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2699 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 May 2020 21:57:54 -0000 On 5/10/20 5:29 PM, Keith Drage wrote: > I dont know whether we reached something we can formally describe as a > decision, but the overall opion was that it should be the text that > should normatively describe what the requirements were for the actions > in respect of inclusion in messages. If these tables were included, they > should be clearly described as informative. > > Further, the normative text should be adequately worded to encompass the > understanding what happened when new messages were invented - so rather > than specifically listing messages, it should probably talk about > messages that create a dialog, etc. Thanks Keith! I don't have a clear memory, but what you say is consistent with my vague recollection. Thanks, Paul > Keith > > > On 10/05/2020 17:59, Paul Kyzivat wrote: >> On 5/10/20 9:12 AM, Samir Srivastava wrote: >>> Hi, >>> >>>    The table mentioned in Section 4 in RFC 4028 does not contain >>> entries for REFER, PUBLISH and MESSAGE methods Below is the table >>> from Section 4 >>> >>> >>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>>     |     Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - | >>> - | >>>     |               |     |     |   |   |   |   |   |   |   | |   |   | >>>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - | >>> - | >>>     |               |     |     |   |   |   |   |   |   |   | |   |   | >>>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - | >>> - | >>>     |               |     |     |   |   |   |   |   |   |   | |   |   | >>>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - | >>> - | >>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>> >>>    They are not applicable for these, but it would have been better >>> if it is said categorically. >> >> IIRC, quite a long time ago it was decided that this table in 3261 was >> a bad idea, because it is essentially a summary of normative language >> in other sections of the document and is necessarily an approximation. >> >> After that, other work that updates and extends 3261 has been >> inconsistent it whether it updates the table or not. >> >> What we should be careful of is that the in progress update to session >> timers is clear, normatively and expositively,  one way or another. >> >>     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 From nobody Sun May 10 23:34:43 2020 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 443E03A0781 for ; Sun, 10 May 2020 23:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 toB1FND7pAeH for ; Sun, 10 May 2020 23:34:37 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2044.outbound.protection.outlook.com [40.107.22.44]) (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 B57B63A07A0 for ; Sun, 10 May 2020 23:34:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LSEnKC+npNV+30ObPhzl9TuMw0aZjii+BXecnv1ugwIKuQyNkU6aile12YAxXoxS8mRXSqPMmGlgEtACEaY3Qce+PC+w4Sn4y+TivRe3G6YUDQwpDOupPuqlAgE5Z4GCcXJq98XdKLaqbmW8aL7WPPaDH0LcA+7VKccBbfh83LRhW2bdIYhUyiNrEwWhuRDcmO+WAxcr25tuFt16ON4n/VPofsPNeChlWyQ6mgo4cBrDAli1K7b0Ex79yFZLanquSOZ2+vRsezg2SaHO0qREOvQ3hHhSD0V6ra20M4v9n5djSDgDsGPaUJuwYX7NnDGFp5mCf4rY/DHawC6B+/DOKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WjQNmnt/o7gkdTRa/BojgUPuXfaRuDetrFtMT7wS3X0=; b=AKUGYuRxgGQwsIid8rKqHaNoTpdLf08y2f3JeYYQIP9bJEHybPUx+M17dH50hdPzk4PdTVy0kxlFN5K7vb4G83m08RiefL6BFqzZNx+1D0rjypn+fTu6uf0uBvwJh9VQVZPx9gAAsGjyfXB4PfainI/1xDQkySObvdXzjDek+JmKIlaC+kOgBDvmnZGSlw7AgdqoLQuCms+emwFzAgX0Mv9sdDtFHfp1tZ3ka7lTkphcMVgw+UkxBXPm4Qj9mZks+NevnYQDqeNttIAEhefEB0SAFepd/So0QKfIkHx7AOzBdvgQlxY1yDyT6aScMCpTVfGZTl1H+WtE6SoR2FkAPQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WjQNmnt/o7gkdTRa/BojgUPuXfaRuDetrFtMT7wS3X0=; b=Ovc3cNb67XxzcWK8yTZwtEeOnG/8GMv5t0bPMCDkvjThqsG9rb9q+uAsB7z2je0v6gUvEiFPEk6U5osNy1cXJQXejzLf53HzK4LHaY6YSiNXfJVpOtUu2qjhitX96UAOHJaVV3BL7BUBV6p198GZnC/lF8Y01c7ke/ZIug8E/1M= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6456.eurprd07.prod.outlook.com (2603:10a6:20b:13a::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.22; Mon, 11 May 2020 06:34:34 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Mon, 11 May 2020 06:34:34 +0000 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined Thread-Index: AQHWJsy7Tb3AmLI5VEauNVgVXU0GX6ihi0KAgABLRgCAAAfwgIAAkDpc Date: Mon, 11 May 2020 06:34:34 +0000 Message-ID: References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com>, <78ac39f5-9689-27e1-9025-02d76ed01460@alum.mit.edu> In-Reply-To: <78ac39f5-9689-27e1-9025-02d76ed01460@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 19ceeafb-68d9-4d4a-29f1-08d7f5755eae x-ms-traffictypediagnostic: AM7PR07MB6456: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04004D94E2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WrYB8VdOxc/WCZTMKkUvkUtLK0HnjDd2Yhf2zW/+SMlbXdmyySCrbo7oschnsNCIU3gusvL6mu22NXzQMEnPgniZQBQEVSY6zy9QSXU3BfRjAs+Zkssc/3R3oZ2wos4VjpzfMIOwDhd5bwU7QmKeh+sHNQc3YP/MB9ZdZcMhPdskIBjo20FFWaluaQF6711tKCqYkH5D9Cos8cY5RNvMguGwX1H85tjPEBShIjFScQko+RbEO5n0N84GzZZbs3DUNOWv3y3+GzrPhKSzzghlfH+++k2A/waksWcjU0hyuDv7LD3E8sDyZN+TngUN6f2YeLLHC50gK8nA+kzHCfgz88u0EaytMCfZyO4SOuu744P8Uj4YTjN9I4GbIAjjdZrtA0I0UpTPykxtOajexQc3YvtgTE1TYkhyoGN/9MjsOjmZ9V/+FgVtqqT+dQHiZzTHS80Q7cuoLzhEjbJr1RSYPDzrPRvden9Yr/PrigcgWJ+4gpw6Kh+CVEKj1tsF85NS5D2uUrOYd7hQ6SzAT4GlmXvP9J6nmUNs4cNC8PhQk1Etvp67wUk/ERhexzbSof1dfjIPyA7g7iNj/0Jtq5vd9B5d1NOpllH49FR8EAyxuFs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(396003)(346002)(366004)(376002)(136003)(33430700001)(19627405001)(7696005)(15650500001)(76116006)(9686003)(66946007)(55016002)(66476007)(66556008)(64756008)(66446008)(86362001)(316002)(110136005)(6506007)(53546011)(52536014)(2906002)(186003)(26005)(44832011)(33656002)(966005)(478600001)(71200400001)(8676002)(166002)(33440700001)(5660300002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: QKxk/kzPCy3kZrd50T96AK/V/o8bym67Y/NFj06RHsZUeEaO9DR6daeDd942aDH8SQsDWG1S5Q4sjHGrrCXNoCMYVON9zbs5LcP4NMDyHM6yrgGI4yIwrwzIwFBmib95a01E8CeH6Jxh9CGE1IJnangYnzTz1i38Wl5ZegCJZRdra6j9hOnXJKiuMcERrZJHUdYYVnIZyYu8deNh/4jGFgn+cY+K1YeVcJ0R4mxtZ0Si/gmY9BHOn3Pdha5hJtbyk7AXaGKCrNmE7F9sgEnSJrD+LFdkW2MvU+pR05GHrKum4JFlddldMtEJOduZSyDigJWvonFzbRmbOIOoetOShUYz1R/oc39n5K1EGGW/dAzVN4rch1wM3Pv+2v8Ls1MzjvRcU9re8MLUYcmfLBdvr7bLKrCVRcNIpOHFC6eJWofqNYYYRrwHDhu01LuUy/TjNCSsdpkfEQq9xPG8tgvBEAPKfhchnm/w9qU8DZ8LRIZg79C3Bnv3jfE3T8KM7+Zw x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM7PR07MB70120643D08C846A0A38C65A93A10AM7PR07MB7012eurp_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 19ceeafb-68d9-4d4a-29f1-08d7f5755eae X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 06:34:34.4028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: v23E78L6h96VgpNlgLX8X10kN7zpC28WmjScMxuB4uRcCaSQgLdi38UAOLxubc1URRn3JyT6/1SGNG1rVQD5W2kB3gh8jvVDMSSEfusM+Ig= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6456 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 06:34:42 -0000 --_000_AM7PR07MB70120643D08C846A0A38C65A93A10AM7PR07MB7012eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Correct. I think the idea to not use tables to begin with, unless there is = a very good reason for doing so. Regards, Christer ________________________________ From: sipcore on behalf of Paul Kyzivat Sent: Monday, May 11, 2020 12:57 AM To: sipcore@ietf.org Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAG= E not defined On 5/10/20 5:29 PM, Keith Drage wrote: > I dont know whether we reached something we can formally describe as a > decision, but the overall opion was that it should be the text that > should normatively describe what the requirements were for the actions > in respect of inclusion in messages. If these tables were included, they > should be clearly described as informative. > > Further, the normative text should be adequately worded to encompass the > understanding what happened when new messages were invented - so rather > than specifically listing messages, it should probably talk about > messages that create a dialog, etc. Thanks Keith! I don't have a clear memory, but what you say is consistent with my vague recollection. Thanks, Paul > Keith > > > On 10/05/2020 17:59, Paul Kyzivat wrote: >> On 5/10/20 9:12 AM, Samir Srivastava wrote: >>> Hi, >>> >>> The table mentioned in Section 4 in RFC 4028 does not contain >>> entries for REFER, PUBLISH and MESSAGE methods Below is the table >>> from Section 4 >>> >>> >>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>> | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>> |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | >>> - | >>> | | | | | | | | | | | | | | >>> |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | >>> - | >>> | | | | | | | | | | | | | | >>> |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | >>> - | >>> | | | | | | | | | | | | | | >>> |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | >>> - | >>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >>> >>> They are not applicable for these, but it would have been better >>> if it is said categorically. >> >> IIRC, quite a long time ago it was decided that this table in 3261 was >> a bad idea, because it is essentially a summary of normative language >> in other sections of the document and is necessarily an approximation. >> >> After that, other work that updates and extends 3261 has been >> inconsistent it whether it updates the table or not. >> >> What we should be careful of is that the in progress update to session >> timers is clear, normatively and expositively, one way or another. >> >> 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_AM7PR07MB70120643D08C846A0A38C65A93A10AM7PR07MB7012eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Correct. I think the idea to not use tables to begin with, unless there is = a very good reason for doing so.

Regards,

Christer

From: sipcore <sipcore-b= ounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu>=
Sent: Monday, May 11, 2020 12:57 AM
To: sipcore@ietf.org <sipcore@ietf.org>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH,= MESSAGE not defined
 
On 5/10/20 5:29 PM, Keith Drage wrote:
> I dont know whether we reached something we can formally describe as a=
> decision, but the overall opion was that it should be the text that > should normatively describe what the requirements were for the actions=
> in respect of inclusion in messages. If these tables were included, th= ey
> should be clearly described as informative.
>
> Further, the normative text should be adequately worded to encompass t= he
> understanding what happened when new messages were invented - so rathe= r
> than specifically listing messages, it should probably talk about
> messages that create a dialog, etc.

Thanks Keith! I don't have a clear memory, but what you say is
consistent with my vague recollection.

        Thanks,
        Paul

> Keith
>
>
> On 10/05/2020 17:59, Paul Kyzivat wrote:
>> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>>> Hi,
>>>
>>>    The table mentioned in Section 4 in RFC 4028 does= not contain
>>> entries for REFER, PUBLISH and MESSAGE methods Below is the ta= ble
>>> from Section 4
>>>
>>>
>>> +---------------+-----+-----+---+---+-= --+---+---+---+---+---+---+---+
>>>     |     Header |where|pro= xy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>>> +---------------+-----+-----+---+---+-= --+---+---+---+---+---+---+---+
>>>     |Session-Expires|  R  | amr | - |= - | - | o | - | - | - | o | - |
>>> - |
>>>     |       =         |     | = ;    |   |   |   |  = |   |   |   | |   |   |<= br> >>>     |Session-Expires| 2xx | ar  | - | - | = - | o | - | - | - | o | - |
>>> - |
>>>     |       =         |     | = ;    |   |   |   |  = |   |   |   | |   |   |<= br> >>>     |Min-SE      =    |  R  | amr | - | - | - | o | - | - | - | o | - | >>> - |
>>>     |       =         |     | = ;    |   |   |   |  = |   |   |   | |   |   |<= br> >>>     |Min-SE      =    | 422 |     | - | - | - | m | - | - | - | = m | - |
>>> - |
>>> +---------------+-----+-----+---+---+-= --+---+---+---+---+---+---+---+
>>>
>>>    They are not applicable for these, but it would h= ave been better
>>> if it is said categorically.
>>
>> IIRC, quite a long time ago it was decided that this table in 3261= was
>> a bad idea, because it is essentially a summary of normative langu= age
>> in other sections of the document and is necessarily an approximat= ion.
>>
>> After that, other work that updates and extends 3261 has been
>> inconsistent it whether it updates the table or not.
>>
>> What we should be careful of is that the in progress update to ses= sion
>> timers is clear, normatively and expositively,  one way or an= other.
>>
>>     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

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
--_000_AM7PR07MB70120643D08C846A0A38C65A93A10AM7PR07MB7012eurp_-- From nobody Mon May 11 04:36:36 2020 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 45B633A09F9 for ; Mon, 11 May 2020 04:36:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 iyQKi2iMPpAS for ; Mon, 11 May 2020 04:36:31 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70040.outbound.protection.outlook.com [40.107.7.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 C0C383A09F8 for ; Mon, 11 May 2020 04:36:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fT/fdMJClCYVfffMuLOojVT8/8CRtuP3p0oBGZPIbSlWPBZF25e52Hlml9V2tN2vIl6TAP5qz6bP+iEjafHEXPQC8ybfC/5vkRtRD5+1RePuMPp0SHGElPziwYdiGzAn9jHg24iWkKg8k5s8SzAvHuVeQ3MHR/oUP6xtw8RJ60qYpbjDn41Vxq3qBDGAUyZZaRpEhlR+mrVOq0RaDM7YeaGQ0T3IQIntdlBNs5gidn9k6Z14NgxMKywTT8dUcgL9RXz9mpZQxMe+nbi4MlQjcOHm6Dygy0fSAyZhgxE9NG+OPIcBUbXhrpmj1cFZNDLX0Tog8paM/T08zZlFmOL9Mw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g8+yObv/z8/NRvhIYStubLF7hpCsQ9vRyEtHBQEkRGg=; b=NEa3Gpm9k9h1qp51Di/lR0txX+eoC+L0d7EqovN1+m9iIbAHRdCG3qRSxMDtwBPAjZTyV/enQIp0FlCLbR3fkONBNliGHdBN50joNc/+Rfy4HIM8T/UmMe98WDlpafNQg1MCgvb50nIxJehRb6fkP/TxRkW1BuO4E98EmOuoWSG/VlvtTGi947gffuBnPlNFjIM8h1AktmVGLMJDsPCAFqGTzUZg83jaLcETRcJE8tChwzLS1xfXcplo4UEJOoPVXnk+usfyZEMiBNkOWDR3Uo3TmVsMWrnTjuvY/5/X6ao6XP4huGPIKwWpHsPj0WrWR4gXQWxPJa35EJvb80sp8A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=g8+yObv/z8/NRvhIYStubLF7hpCsQ9vRyEtHBQEkRGg=; b=kstnw98bZxPCo8Cf/RTD1GUAavBhHW+G0yTxFBOmSpLWFIaa2T9+nHk0kD9p6P6gAOrPX5LZqtiKPdK5fGkBILLXfZiqTxOzPjurIC9GxlpblfINiA1y02PTzNiuhX+9tuDtcO+FDtEynSclDL8YbnW+vAQpXAnTNdzcg1EA3OM= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6423.eurprd07.prod.outlook.com (2603:10a6:20b:132::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Mon, 11 May 2020 11:36:28 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Mon, 11 May 2020 11:36:28 +0000 From: Christer Holmberg To: "sipcore@ietf.org" Thread-Topic: 4028bis: memory refresh Thread-Index: AQHWJ4hoBAIXqjuyIkyXKiS7M/GbTg== Date: Mon, 11 May 2020 11:36:27 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 673aba87-83cd-436c-d07a-08d7f59f8b43 x-ms-traffictypediagnostic: AM7PR07MB6423: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04004D94E2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7+2L8svRHGwdDW2FQBjNues9Ufrov/yIvujdZ52cdEqdL4VYjqvNud1u+DbSA0WZm5G4jaekj9VyBGaEBMBVsbxaW12UhT73uVeeDjyTYt7BmuLfVBfKEDLlloZDUnjKLO7X4cqk8c0nPqsV+6EIzVmzGwUWDJiIapMO8pQExXQ0NNSW9OaQBZvdAqtAPs5hfV6IB0oF5BpAnowpxJaQXLAo1C/6reIvsI4YJNpNIXvYdSsOTWxCfr926VfE8wN8SU5uBNOqUETjVgHYPi+EcBdOTevEwPSVDfxhaxilSGQadFqEYNCu0SMrCjTAO5UxSxhhcYlCH3JmzLbY99scEOZNLr05DvdpCNcAV1/Nn7wgcI9s5zrnx8VbtDJSG83imju4oauTQwa2W7ATZ0thDKWeBQ8BrKExMCFCHTEyhIRrJ2S4IgA8y+xutumORp6sBztzFtT0saR7mhR2eecwL9M52jojIdeREVWjujO4mNcOJaYciiAcHQZD7T3a6KOrKhhgZQZeU631pSeLHKZvgQRZxUrNdXDSFb3N6RQaq6zGH5KpwyywrLzxhoebUuFMicqJ284YT9N44pAFnQSDTbx2yMBx03tjQWJCi24hdxY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(366004)(136003)(376002)(396003)(39860400002)(33430700001)(6506007)(64756008)(66946007)(66556008)(66446008)(5660300002)(33440700001)(4744005)(8936002)(8676002)(76116006)(6486002)(2616005)(91956017)(36756003)(33656002)(66476007)(44832011)(966005)(86362001)(2906002)(166002)(6512007)(316002)(6916009)(478600001)(71200400001)(186003)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: qQZqI1vLmV7qygriPJmXvfhZqqm1PK9s//mKETDLOba8kEhoVyoO4vsPQkaalt8UBJjfgtHKyHXGzVmWFekfkk5SIc5pRUBubmF1Hhs9rUanIOsNGUTWgBs3ClvmhMeE2gr3s6Cm0zG5gNYYacZica/+3l7LTyMFRxekIbMXrlLlgEQDrkvrurZ47JbdTLBdbfqhluZaS+wtX5zy2eOBrbgsmatoIP6e09q/BF7kVAC1O5glPCMwZdq5jumow2AW/y/9+bXm5b3UHiXwJpedT5aGZn0W7UpT1iP47hKddA3s8TicGC6MFbYyLMUQIR5IovhMVs1ndA4ZnQtvhvMCDNhNWkPOFQkAo5rkou83yNBHTkG4ComtGthlamZaKteSkWOpxlALrZYqU5QuIeDTZEKyuPr26/VHcXCvyfq3GLXubpU30dwfnxn+wPFtm1bzBZaFEB/nN3BckH7DpK5JuFE7UwiFNBDfgPbPkh4hTh5kOtYRvstkLhBekf5yEBRv x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_ECC5FF0908C24801B8706B7E226C1C13ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 673aba87-83cd-436c-d07a-08d7f59f8b43 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 11:36:28.0610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4RQM4YvK8uTTdZF2No+Vw24EKmZQXfx/AdvVHPVw73fUuvlb0WY5voJxqXBrTRaXehkD8nmON4b3saOrdy5U7JloRtCozyILJoCabv22uGA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6423 Archived-At: Subject: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 11:36:34 -0000 --_000_ECC5FF0908C24801B8706B7E226C1C13ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vdywgd2hlbiB0aGUgc2lwLW9hdXRoIGRyYWZ0IGlzIG1vcmUgb3IgbGVzcyBkb25l IChpbiB0aGUgUkZDIGVkaXRvcuKAmXMgcXVldWUpLCBJIGludGVuZCB0byB0YWtlIHVwIHRoZSB3 b3JrIG9uIDQwMjhiaXMgKHNlc3Npb24tdGltZXIpIGFnYWluLg0KDQpXZSBwcmV2aW91c2x5IGhh ZCBlLW1haWwgZGlzY3Vzc2lvbnMgYW5kIHBob25lIGNhbGxzLCB0aGVyZSBpcyBhbiBpc3N1ZSB0 cmFja2VyIG9uIEdpdEh1YiwgYW5kIHdlIGRpc2N1c3NlZCB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9u cyBhdCBJRVRGIzEwMy4gVG8gcmVmcmVzaCB5b3VyIG1lbW9yeSwgcGxlYXNlIHRha2UgYSBsb29r IGF0IHRoZSB2aWRlbzogaHR0cHM6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1DMnllY2tCbWdQ ZyAodGhlIHNlc3Npb24tdGltZXIgcHJlc2VudGF0aW9uIGJlZ2lucyBhdCBhcm91bmQgNzozMCBt aW51dGVzKS4NCg0KVGhlIGRlY2lzaW9uIHRvIG1ha2UgYSBiaXMgKGluc3RlYWQgb2YgYW4gdXBk YXRlIGRyYWZ0KSBoYXMgYWxyZWFkeSBiZWVuIG1hZGUsIGJ1dCBwbGVhc2UgdGFrZSBhIGxvb2sg YXQgdGhlIHRlY2huaWNhbCBzdWdnZXN0aW9ucyBmb3IgZml4aW5nIHRoZSBnbGFyZSBzaXR1YXRp b24uDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQo= --_000_ECC5FF0908C24801B8706B7E226C1C13ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7 DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iZW4tRkkiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJGSSI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRkkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3csIHdoZW4gdGhlIHNpcC1vYXV0aCBkcmFm dCBpcyBtb3JlIG9yIGxlc3MgZG9uZSAoaW4gdGhlIFJGQyBlZGl0b3LigJlzIHF1ZXVlKSwgSSBp bnRlbmQgdG8gdGFrZSB1cCB0aGUgd29yayBvbiA0MDI4YmlzIChzZXNzaW9uLXRpbWVyKSBhZ2Fp bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPldlIHByZXZpb3VzbHkgaGFkIGUtbWFpbCBkaXNjdXNzaW9u cyBhbmQgcGhvbmUgY2FsbHMsIHRoZXJlIGlzIGFuIGlzc3VlIHRyYWNrZXIgb24gR2l0SHViLCBh bmQgd2UgZGlzY3Vzc2VkIHRoZSBzdWdnZXN0ZWQgc29sdXRpb25zIGF0IElFVEYjMTAzLiBUbyBy ZWZyZXNoIHlvdXIgbWVtb3J5LCBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIHZpZGVvOg0KPC9z cGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9QzJ5ZWNrQm1nUGci Pmh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9QzJ5ZWNrQm1nUGc8L2E+DQo8c3BhbiBs YW5nPSJFTi1VUyI+KHRoZSBzZXNzaW9uLXRpbWVyIHByZXNlbnRhdGlvbiBiZWdpbnMgYXQgYXJv dW5kIDc6MzAgbWludXRlcykuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZGVjaXNpb24gdG8gbWFr ZSBhIGJpcyAoaW5zdGVhZCBvZiBhbiB1cGRhdGUgZHJhZnQpIGhhcyBhbHJlYWR5IGJlZW4gbWFk ZSwgYnV0IHBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgdGVjaG5pY2FsIHN1Z2dlc3Rpb25zIGZv ciBmaXhpbmcgdGhlIGdsYXJlIHNpdHVhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_ECC5FF0908C24801B8706B7E226C1C13ericssoncom_-- From nobody Mon May 11 08:39:49 2020 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 ED9E33A0786 for ; Mon, 11 May 2020 08:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.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 FHAhp3Zb2GXs for ; Mon, 11 May 2020 08:39:45 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (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 2B73E3A07A5 for ; Mon, 11 May 2020 08:39:45 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 7BABFA022A for ; Mon, 11 May 2020 15:39:44 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=hj0aTA0BMs8Zdg1Q7+5XwGvkPyqgPClU7PTlkuSEGJY=; b=bap5j/ipn1GmeD+8fHAVvLYshGUnJY8smm7+iq1MStOKQQpN01h0QqFgSbW0eclXHXniGvRt2Ce1q0IWKtnKLLbYifiGghC9pef+0567v3Ekb02jiTgwCAlRJTrVAzRzO/N2QRteCZXLKP4rX6yvvgahdfdZsa5USBcybCux7/ZfPLHHLWzi1c8tBeKZUsmDDQSb+PMtmm7I8T1878HOFLR7qWwK+caNBlZf16fz0BqnnU4igX0Nkl3ohAdAaQ1BpbkJ/B10a2ZJjv3jujUGAsq7gBCvge5gUCpkH3AflUE6pXFbnIYs2iwljfrPg9KwqJl2UKFbI07QvoqSxwxCZg== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Mon, 11 May 2020 15:39:43 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 792F620111; Mon, 11 May 2020 15:39:43 +0000 (UTC) MIME-Version: 1.0 Date: Mon, 11 May 2020 21:39:42 +0600 To: "Keith Drage" , sipcore@ietf.org From: "Samir Srivastava" In-Reply-To: <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> Content-Type: multipart/alternative; boundary="=_9b1253e5b209ab0fcae7f871a1412390" Message-Id: <20200511153943.792F620111@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 15:39:47 -0000 --=_9b1253e5b209ab0fcae7f871a1412390 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, Please find my replies Inline below prefixed with SS>> ThanksSamir Srivastava https://samirsrivastava.typepad.com/ On 5/11/2020 at 2:59 AM, "Keith Drage" wrote:I dont know whether we reached something we can formally describe as a decision, but the overall opion was that it should be the text that should normatively describe what the requirements were for the actions in respect of inclusion in messages. If these tables were included, they should be clearly described as informative. SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format? Further, the normative text should be adequately worded to encompass the understanding what happened when new messages were invented - so rather than specifically listing messages, it should probably talk about messages that create a dialog, etc. SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 REFER RFC https://tools.ietf.org/html/rfc3515 MESSAGE RFC https://tools.ietf.org/html/rfc3428 They all were invented before RFC 4028. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance? Keith On 10/05/2020 17:59, Paul Kyzivat wrote: > On 5/10/20 9:12 AM, Samir Srivastava wrote: >> Hi, >> >> The table mentioned in Section 4 in RFC 4028 does not contain >> entries for REFER, PUBLISH and MESSAGE methods Below is the table >> from Section 4 >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | >> - | >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >> They are not applicable for these, but it would have been better >> if it is said categorically. > > IIRC, quite a long time ago it was decided that this table in 3261 was > a bad idea, because it is essentially a summary of normative language > in other sections of the document and is necessarily an approximation. > > After that, other work that updates and extends 3261 has been > inconsistent it whether it updates the table or not. > > What we should be careful of is that the in progress update to session > timers is clear, normatively and expositively, one way or another. > > 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 --=_9b1253e5b209ab0fcae7f871a1412390 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,

  Please find my replies Inline below prefix= ed with SS>>

Thanks

On 5/11/2020 at 2:59 AM, "Keith Drage" &= lt;drageke=3D40ntlworld.com@dmarc.ietf.org> wrote:
I dont know = whether we reached something we can formally describe as a
decision, bu= t the overall opion was that it should be the text that
should normativ= ely describe what the requirements were for the actions
in respect of i= nclusion in messages. If these tables were included, they
should be cle= arly described as informative.
SS>> I am of the opinion that we ne= ed header, message etc in the tabulated form. SIP Parser developers cannot = be expected to know the minute details of applicability of the messages and= headers etc. SIP architect in the vendor comapnies might be required to gi= ve the headers and messages in the tabulated form to SIP Parser developers.= If we all agree in the tabulated form as SPEC Writers, it will be good ser= vice to the community. What are the difficulties considered which made us t= o deprecate the table format?

Further, the normative text should be = adequately worded to encompass the
understanding what happened when new= messages were invented - so rather
than specifically listing messages,= it should probably talk about
messages that create a dialog, etc.
S= S>> PUBLISH RFC = https://tools.ietf.org/html/rfc3903
        &nbs= p;REFER RFC https://to= ols.ietf.org/html/rfc3515
          MESSAGE= RFC https://tools.iet= f.org/html/rfc3428

  They all were invented before RFC 4028= . They were NOT developed after Session Timers. So it is left because of mi= stake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text= anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only def= ined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Ex= pires are found in these message should be reject the REQUEST or accept the= by following "be lenient what one accepts". Some guideline needs to be spe= cified. 
  Developer of new method need to look each header, m= essage etc in their respective RFC. What one can specify for method foo for= header foobar in advance? 




Keith


On 10/= 05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivas= tava wrote:
>> Hi,
>>
>>    The table = mentioned in Section 4 in RFC 4028 does not contain
>> entries fo= r REFER, PUBLISH and MESSAGE methods Below is the table
>> from S= ection 4
>>
>>
>> +---------------+-----+-----+-= --+---+---+---+---+---+---+---+---+---+
>>     |&nb= sp;    Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|S= UB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+--= -+---+---+---+
>>     |Session-Expires|  R&nbs= p; | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>=     |         =       |     |   = ;  |   |   |   |   | &nbs= p; |   |   | |   |   |
>> =     |Session-Expires| 2xx | ar  | - | - | - | o | - | -= | - | o | - |
>> - |
>>     |  = ;             |=      |     |   | &nb= sp; |   |   |   |   |   |= |   |   |
>>     |Min-SE =         |  R  | amr | - | - | = - | o | - | - | - | o | - |
>> - |
>>    = |            &= nbsp;  |     |     | &nbs= p; |   |   |   |   |   |&= nbsp;  | |   |   |
>>     = |Min-SE         | 422 |  =    | - | - | - | m | - | - | - | m | - |
>> - |
>= > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+<= br>>>
>>    They are not applicable for these, but= it would have been better
>> if it is said categorically.
>= ;
> IIRC, quite a long time ago it was decided that this table in 326= 1 was
> a bad idea, because it is essentially a summary of normative= language
> in other sections of the document and is necessarily an = approximation.
>
> After that, other work that updates and exte= nds 3261 has been
> inconsistent it whether it updates the table or = not.
>
> What we should be careful of is that the in progress u= pdate to session
> timers is clear, normatively and expositively,&nb= sp; one way or another.
>
>     Thanks,
= >     Paul
>
> _________________________= ______________________
> sipcore mailing list
> sipcore@ietf.or= g
> https:/= /www.ietf.org/mailman/listinfo/sipcore

_________________________= ______________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/m= ailman/listinfo/sipcore
 --=_9b1253e5b209ab0fcae7f871a1412390-- From nobody Mon May 11 08:52:02 2020 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 E45EF3A07C2 for ; Mon, 11 May 2020 08:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jqzDgcVxcuCT for ; Mon, 11 May 2020 08:51:57 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00057.outbound.protection.outlook.com [40.107.0.57]) (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 8AA963A07C6 for ; Mon, 11 May 2020 08:51:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ni35jW4i9tI6MEkitamO4LayOdnTDSa7tAFVXc/YCve4yWjBsSDRvbmMxkfmR6pCx/mkmBLs4DKCTLjRZbxETPlreFH+FGRBbVfdsQqtgCMALc7G950n4MtqKxm0oNL/xwvIET5r6pCtq1koMx/HEXDY/9yY5ORSfigcn4GhkjcyOkazDxkrm3hEUa1SWIAvDd27M1Rtgb79ME3X7yWXVUS/0tL0Rp+xyNStSG4ZfFERVTTKEeLnM5N2CG1kF4Yh79+j4RZje9E6jN+Bm/LSSnjwNvNAzx4XVUbWWbSzgXkEA8KcrG2AKOovifHC3tegm0OC4kBcu8PAyibQO3McDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=izCaMz1RgrwGI8Cp5AaeI6hoJmMQ9LHZOf3o6UwpejI=; b=kMQH6ogvtV0H/e5PRCD9Q+GAllgKReEwXs2RQO7SpfVl3mDj06TJ537bGFXtebq1W3V9/5fgy4RCnOz15oet8MBPupxuwedbzJcIlFfN4Xwv0MJjP5/OHV+Vq4/pkqfzwjS6Oe56OVDqt+clOdhWeg7U7XfwHZ6cqtmnBr5mcDLJibRfjVydcpbrHdJhJsJM74MttMOBWaDyhCx12qUTTWU0gpRd9WQgOOCkY7//WD25uyIGdIRA8kY/dfYATtNNHVLs9bSCKI9LFN8TIKZgHXtrWys/9/yEyaEg8ZcSnPwJLebQ8Ip57lYm5l6V89Ncn9B2Mqxy23vyAg9Q84gDIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=izCaMz1RgrwGI8Cp5AaeI6hoJmMQ9LHZOf3o6UwpejI=; b=EJJ5OFZu94IGkWuuy/5fjaIQ3vjrNI0+CJN3KAVS2W1w2D7Pcdkwr9LkDPRNZpRLXpKHN4XCL7S8/cpJek7lCKts0nKBJELvSUTFlASa7CD9eu2JfbsQ/vS30Cjm38yPCLGu5vRfDfQ64Sd5JhUYVbDAKsYuhG4NY+W8wPK8xL8= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6483.eurprd07.prod.outlook.com (2603:10a6:20b:1a1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Mon, 11 May 2020 15:51:54 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Mon, 11 May 2020 15:51:54 +0000 From: Christer Holmberg To: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] 4028bis: memory refresh Thread-Index: AQHWJ6wXHMVHOyLTxUOyiBxMgD7Rvw== Date: Mon, 11 May 2020 15:51:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 042b0517-7aaa-4cc8-f251-08d7f5c33a51 x-ms-traffictypediagnostic: AM7PR07MB6483: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04004D94E2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: caQIxtkjkvscTIUANi9WE3sizMo6I9gwpu0mE+EY495QL5o1dceb+1/rajSTxd8DoVv73DxImsJZFi0SYkkljgdsU1aFxSLQpc1dh4bH2wfzdaSLuB/Y2xlC/u41ZoF8VxSr3K0XMlMjXYsx3chaa2jDYO9ezPu+he05r8+BFmHeLgeot9UaVINBpBhvb7QEvkivhtJ5B9JUMb5X0KmDhT+QD/zh0G/NnF2irrJBDPZOCEbrfV25wsUdx69/XUbeclEK7oOlA/HbuuNuzfnayCSq4mJTSe6WjSYX3sOTViQXPOxTTpA10DYeN+TTaNTo5z+0aF8p4uyz8WYOgl83HoskadYXF+c4ScOGZ+iBltjGl0eYsuy8oMDEpYHtFZ3dK6K4dM0AkxqUAcNR1jo9efjslNL/84hdCbS586ZVw4rxtdZBRy++anJHoaSuedquKdiye6lFhEdJlHtrUJZ+DRWpZrPlZScMQiYggqdZ6SRsjfYsUM8bvwZqF9kwDQ2rl4D92KViudls9PHXNShMKIzRUOMNNqlkZYcPYAqrDKwCx7Pn4fVrq/tPs9uasS9ncs4boqgslDSNaAHUaJ4QWbS0WYe8vRyx6rrJhwgOQmU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(376002)(136003)(366004)(346002)(33430700001)(166002)(478600001)(6506007)(44832011)(966005)(86362001)(316002)(186003)(26005)(6512007)(110136005)(71200400001)(66476007)(33440700001)(8676002)(8936002)(5660300002)(2906002)(2616005)(66446008)(66556008)(64756008)(66946007)(36756003)(33656002)(76116006)(91956017)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /dcR6uG1eWGlaen70NFryvBtJpRcMrmxy/K+pAm0SHq0zaFxlQ0NnK42dkYJHKufuQmrML2ZFPkRS1GY9bCerG6n6soHOozC7OufF3Vf7ZWBSAs+7alrH3HmPjBLBwTbUIsoV1nl/FX3IQcY1iExSZX29BaB2H4ALRdBkI94tNocjd2i2S04u/Oie+9L7eSjg5QlU/I4Pck6CKF/Cwui3lohGefDDI0kTLxiv6hDppIgnWIfdCYY5vMeoYVhnPhcAGq3+1eRmw0g+8JLtX+QwFXorBxVo5In3keE6apSm7t53AiiKRaJYtRd7y46FCWtn3VeEA5GQHA3Gne+bTMatJmS2+PdukTPpfhOG+spyPBTJwvrsdMTXFMrHIcqrBKydq8wq36RpnXU6+oKYNozbJynhVUBBqPjNPpb6S0uGaEXSMeUnRYtykfmpvDJ9O70rIApmpG1AxewwInH47/9kc9bIRWuWkd/tqbIEm4fJ5yhqOT7fyCdrfBwby8aBylW x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_C3B21DCEAFB64312B681ED38CF9E1FA3ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 042b0517-7aaa-4cc8-f251-08d7f5c33a51 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 15:51:54.0787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1qfZzEzcvp5wpitvClGX/q3dCfMQjD/YjZCHds1sN8m3hnnM57n0Tdm54/RZq2MJTf72A/4+oV9a70WdXxFhvV33/kxSFjW4iXs+B1g+zok= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6483 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 15:52:00 -0000 --_000_C3B21DCEAFB64312B681ED38CF9E1FA3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFuZCwgaWYgeW91IGZvciB3aGF0ZXZlciByZWFzb24gcmF0aGVyIHdhdGNoIFRpZ2Vy IEtpbmcgdGhhbiB0aGUgSUVURiAxMDIgU0lQQ09SRSBzZXNzaW9uLCBiZWxvdyBpcyBiYXNpY2Fs bHkgd2hhdCB3YXMgc3VnZ2VzdGVkIGluIG9yZGVyIHRvIHNvbHZlIHRoZSBzZXNzaW9uLXRpbWVy IGdsYXJlIHNpdHVhdGlvbjoNCg0KDQpVQUM6DQoNCg0KLSAgICAgICAgICBJZiBhIFVBIGluc2Vy dHMgUy1FIGluIGFuIElOVklURSByZXF1ZXN0IHRoZSBVQSBNVVNUIGluc2VydCB0aGUgc2FtZSBT LUUgaW4gYW55IFVQREFURSByZXF1ZXN0IGl0IHNlbmRzIHdoaWxlIHRoZSBJTlZJVEUgdHJhbnNh Y3Rpb24gaXMgb25nb2luZw0KDQotICAgICAgICAgIElmIGEgVUEgaGFzIGNvbmZsaWN0aW5nIFMt RSBpbmZvcm1hdGlvbiBvbmNlIHRoZSBJTlZJVEUgYW5kIFVQREFURSB0cmFuc2FjdGlvbiBoYXZl IGNvbXBsZXRlZCwgaXQgTVVTVCBzZW5kIGEgbmV3IFVQREFURSB3aXRoIFMtRSwgaW4gb3JkZXIg dG8g4oCcc3luY+KAnSB0aGUgUy1FIHN0YXRlIGFtb25nIGFsbCBlbnRpdGllcw0KDQoNClBST1hZ Og0KDQpSZXF1ZXN0IGhhbmRsaW5nOg0KDQotICAgICAgICAgIE1VU1QgcmVqZWN0IHRoZSByZXF1 ZXN0IGlmIHRoZSBTLUUgdmFsdWUgaXMgdG9vIHNtYWxsDQoNCm8gICBObyBtYXR0ZXIgaWYgdGhl IHJlcXVlc3QgY29udGFpbnMgU3VwcG9ydGVkOnRpbWVyIG9yIG5vdA0KDQotICAgICAgICAgIElm IHRoZSBwcm94eSBpbnNlcnRzL2ZvcndhcmRzL21vZGlmaWVzIHRoZSBTLUUgaW4gYW4gSU5WSVRF IHJlcXVlc3QgdGhlIHByb3h5IE1VU1QgaWRlbnRpY2FsbHkgaW5zZXJ0L2ZvcndhcmQvbW9kaWZ5 IHRoZSBzYW1lIFMtRSBpbiBhbnkgVVBEQVRFIHJlcXVlc3QNCg0KbyAgIFRoZSBwcm94eSBNQVkg aW5zZXJ0L21vZGlmeSB0aGUgUy1FIGlmIGl0IGtub3dzIHRoYXQgdGhlcmUgaXMgbm8gYWN0aXZl IElOVklURSB0cmFuc2FjdGlvbg0KDQpSZXNwb25zZSBoYW5kbGluZzoNCg0KLSAgICAgICAgICBJ ZiByZXNwb25zZSBjb250YWlucyBTLUUsIHRoZSBwcm94eSBNVVNUIE5PVCBtb2RpZnkgaXQNCg0K LSAgICAgICAgICBJZiByZXNwb25zZSBkb2VzIG5vdCBjb250YWluIFMtRSwgdGhlIHByb3h5IE1B WSBpbnNlcnQgUy1FIGlmIGl0IHJlbWVtYmVycyB0aGF0IHRoZSBhc3NvY2lhdGVkIHJlcXVlc3Qg Y29udGFpbmVkIFN1cHBvcnRlZDp0aW1lcg0KDQpVQVM6DQoNCg0KLSAgICAgICAgICBJZiByZXF1 ZXN0IGNvbnRhaW5zIFMtRToNCg0KbyAgIFRoZSBVQVMgY29waWVzIHRoZSBTLUUgdmFsdWUgb2Yg dGhlIHJlcXVlc3QgaW50byB0aGUgcmVzcG9uc2UNCg0KbyAgIFRoZSBVQVMgTVVTVCBOT1QgcmVk dWNlIHRoZSBTLUUgdmFsdWUgaW4gdGhlIHJlc3BvbnNlDQoNCsKnICBJZiB0aGUgVUFTIHdhbnRz IHRvIGNoYW5nZSB0aGUgUy1FIHZhbHVlLCBpdCBsYXRlciBzZW5kcyBhIHJlcXVlc3QgYnkgaXRz IG93bg0KDQotICAgICAgICAgIElmIHRoZSByZXF1ZXN0IGRvZXMgbm90IGNvbnRhaW4gUy1FOg0K DQpvICAgSWYgdGhlIHJlcXVlc3QgY29udGFpbnMgU3VwcG9ydGVkOnRpbWVyLCB0aGUgVUFTIE1B WSBpbmNsdWRlIFMtRSBpbiB0aGUgcmVzcG9uc2UNCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0K DQpGcm9tOiBzaXBjb3JlIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBD aHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmc9NDBlcmljc3Nvbi5jb21AZG1hcmMu aWV0Zi5vcmc+DQpEYXRlOiBNb25kYXksIDExIE1heSAyMDIwIGF0IDE0LjM2DQpUbzogInNpcGNv cmVAaWV0Zi5vcmciIDxzaXBjb3JlQGlldGYub3JnPg0KU3ViamVjdDogW3NpcGNvcmVdIDQwMjhi aXM6IG1lbW9yeSByZWZyZXNoDQoNCkhpLA0KDQpOb3csIHdoZW4gdGhlIHNpcC1vYXV0aCBkcmFm dCBpcyBtb3JlIG9yIGxlc3MgZG9uZSAoaW4gdGhlIFJGQyBlZGl0b3LigJlzIHF1ZXVlKSwgSSBp bnRlbmQgdG8gdGFrZSB1cCB0aGUgd29yayBvbiA0MDI4YmlzIChzZXNzaW9uLXRpbWVyKSBhZ2Fp bi4NCg0KV2UgcHJldmlvdXNseSBoYWQgZS1tYWlsIGRpc2N1c3Npb25zIGFuZCBwaG9uZSBjYWxs cywgdGhlcmUgaXMgYW4gaXNzdWUgdHJhY2tlciBvbiBHaXRIdWIsIGFuZCB3ZSBkaXNjdXNzZWQg dGhlIHN1Z2dlc3RlZCBzb2x1dGlvbnMgYXQgSUVURiMxMDMuIFRvIHJlZnJlc2ggeW91ciBtZW1v cnksIHBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgdmlkZW86IGh0dHBzOi8vd3d3LnlvdXR1YmUu Y29tL3dhdGNoP3Y9QzJ5ZWNrQm1nUGcgKHRoZSBzZXNzaW9uLXRpbWVyIHByZXNlbnRhdGlvbiBi ZWdpbnMgYXQgYXJvdW5kIDc6MzAgbWludXRlcykuDQoNClRoZSBkZWNpc2lvbiB0byBtYWtlIGEg YmlzIChpbnN0ZWFkIG9mIGFuIHVwZGF0ZSBkcmFmdCkgaGFzIGFscmVhZHkgYmVlbiBtYWRlLCBi dXQgcGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSB0ZWNobmljYWwgc3VnZ2VzdGlvbnMgZm9yIGZp eGluZyB0aGUgZ2xhcmUgc2l0dWF0aW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K --_000_C3B21DCEAFB64312B681ED38CF9E1FA3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <33549D67968C4C42936C38EF1A1904F0@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCmE6bGluaywgc3Bhbi5N c29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xp c3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eToz NDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWluZGVudDoy MS4wcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDo4NzM5MjY4MDM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE2MzY2OTk2MDYgMjE2NTcwNTU0IDEzNDgwNzU1NSAxMzQ4MDc1 NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4 MDc1NTc7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0KCW1zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1z by1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXtt YXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1GSSIgbGluaz0i IzA1NjNDMSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QW5k LCBpZiB5b3UgZm9yIHdoYXRldmVyIHJlYXNvbiByYXRoZXIgd2F0Y2ggVGlnZXIgS2luZyB0aGFu IHRoZSBJRVRGIDEwMiBTSVBDT1JFIHNlc3Npb24sIGJlbG93IGlzIGJhc2ljYWxseSB3aGF0IHdh cyBzdWdnZXN0ZWQgaW4gb3JkZXIgdG8gc29sdmUgdGhlIHNlc3Npb24tdGltZXIgZ2xhcmUgc2l0 dWF0aW9uOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiPlVBQzo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGSSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv MSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9 Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0i RU4tVVMiPklmIGEgVUEgaW5zZXJ0cyBTLUUgaW4gYW4gSU5WSVRFIHJlcXVlc3QgdGhlIFVBIE1V U1QgaW5zZXJ0IHRoZSBzYW1lIFMtRSBpbiBhbnkgVVBEQVRFIHJlcXVlc3QgaXQgc2VuZHMgd2hp bGUgdGhlIElOVklURSB0cmFuc2FjdGlvbiBpcyBvbmdvaW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7 dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3Vw cG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8 L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPklmIGEgVUEg aGFzIGNvbmZsaWN0aW5nIFMtRSBpbmZvcm1hdGlvbiBvbmNlIHRoZSBJTlZJVEUgYW5kIFVQREFU RSB0cmFuc2FjdGlvbiBoYXZlIGNvbXBsZXRlZCwgaXQgTVVTVCBzZW5kIGEgbmV3IFVQREFURSB3 aXRoIFMtRSwgaW4gb3JkZXIgdG8g4oCcc3luY+KAnSB0aGUgUy1FIHN0YXRlIGFtb25nIGFsbCBl bnRpdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBST1hZOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idGV4 dC1pbmRlbnQ6MTguMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+UmVxdWVzdCBoYW5kbGluZzo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMg TmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyI+TVVTVCByZWplY3QgdGhlIHJlcXVlc3QgaWYgdGhlIFMtRSB2YWx1ZSBpcyB0b28g c21hbGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0Omww IGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcg Um9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIj5ObyBtYXR0ZXIgaWYgdGhlIHJlcXVlc3QgY29udGFpbnMgU3Vw cG9ydGVkOnRpbWVyIG9yIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g bGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgcHJveHkgaW5zZXJ0cy9mb3J3 YXJkcy9tb2RpZmllcyB0aGUgUy1FIGluIGFuIElOVklURSByZXF1ZXN0IHRoZSBwcm94eSBNVVNU IGlkZW50aWNhbGx5IGluc2VydC9mb3J3YXJkL21vZGlmeSB0aGUgc2FtZSBTLUUgaW4gYW55IFVQ REFURSByZXF1ZXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHByb3h5IE1BWSBpbnNlcnQvbW9kaWZ5IHRo ZSBTLUUgaWYgaXQga25vd3MgdGhhdCB0aGVyZSBpcyBubyBhY3RpdmUgSU5WSVRFIHRyYW5zYWN0 aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5SZXNwb25z ZSBoYW5kbGluZzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVO LVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4tPHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2Vu ZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+SWYgcmVzcG9uc2UgY29udGFpbnMgUy1FLCB0aGUgcHJv eHkgTVVTVCBOT1QgbW9kaWZ5IGl0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxl PSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHJlc3BvbnNlIGRvZXMgbm90IGNv bnRhaW4gUy1FLCB0aGUgcHJveHkgTUFZIGluc2VydCBTLUUgaWYgaXQgcmVtZW1iZXJzIHRoYXQg dGhlIGFzc29jaWF0ZWQgcmVxdWVzdCBjb250YWluZWQgU3VwcG9ydGVkOnRpbWVyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj5VQVM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5k ZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0 c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiByZXF1ZXN0IGNvbnRh aW5zIFMtRTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwwIGxldmVsMiBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgVUFTIGNvcGllcyB0aGUgUy1FIHZhbHVlIG9mIHRo ZSByZXF1ZXN0IGludG8gdGhlIHJlc3BvbnNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5vPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFVBUyBNVVNUIE5P VCByZWR1Y2UgdGhlIFMtRSB2YWx1ZSBpbiB0aGUgcmVzcG9uc2U8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4w cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDMgbGZvMSI+DQo8IVtpZiAh c3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Oldpbmdk aW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgVUFTIHdhbnRzIHRvIGNo YW5nZSB0aGUgUy1FIHZhbHVlLCBpdCBsYXRlciBzZW5kcyBhIHJlcXVlc3QgYnkgaXRzIG93bjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxh bmc9IkVOLVVTIj5JZiB0aGUgcmVxdWVzdCBkb2VzIG5vdCBjb250YWluIFMtRTo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMiBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi Pm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVO LVVTIj5JZiB0aGUgcmVxdWVzdCBjb250YWlucyBTdXBwb3J0ZWQ6dGltZXIsIHRoZSBVQVMgTUFZ IGluY2x1ZGUgUy1FIGluIHRoZSByZXNwb25zZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNpcGNvcmUgJmx0O3NpcGNvcmUtYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJp c3Rlci5ob2xtYmVyZz00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+TW9uZGF5LCAxMSBNYXkgMjAyMCBhdCAxNC4zNjxicj4NCjxiPlRvOiA8L2I+JnF1 b3Q7c2lwY29yZUBpZXRmLm9yZyZxdW90OyAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8YnI+DQo8 Yj5TdWJqZWN0OiA8L2I+W3NpcGNvcmVdIDQwMjhiaXM6IG1lbW9yeSByZWZyZXNoPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLUdCIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Tm93LCB3aGVuIHRo ZSBzaXAtb2F1dGggZHJhZnQgaXMgbW9yZSBvciBsZXNzIGRvbmUgKGluIHRoZSBSRkMgZWRpdG9y 4oCZcyBxdWV1ZSksIEkgaW50ZW5kIHRvIHRha2UgdXAgdGhlIHdvcmsgb24gNDAyOGJpcyAoc2Vz c2lvbi10aW1lcikgYWdhaW4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBwcmV2aW91c2x5IGhhZCBl LW1haWwgZGlzY3Vzc2lvbnMgYW5kIHBob25lIGNhbGxzLCB0aGVyZSBpcyBhbiBpc3N1ZSB0cmFj a2VyIG9uIEdpdEh1YiwgYW5kIHdlIGRpc2N1c3NlZCB0aGUgc3VnZ2VzdGVkIHNvbHV0aW9ucyBh dCBJRVRGIzEwMy4gVG8gcmVmcmVzaCB5b3VyIG1lbW9yeSwgcGxlYXNlIHRha2UgYSBsb29rIGF0 IHRoZSB2aWRlbzoNCjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRj aD92PUMyeWVja0JtZ1BnIj5odHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PUMyeWVja0Jt Z1BnPC9hPg0KPHNwYW4gbGFuZz0iRU4tVVMiPih0aGUgc2Vzc2lvbi10aW1lciBwcmVzZW50YXRp b24gYmVnaW5zIGF0IGFyb3VuZCA3OjMwIG1pbnV0ZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IGRlY2lzaW9uIHRvIG1ha2UgYSBiaXMgKGluc3RlYWQgb2YgYW4gdXBkYXRlIGRyYWZ0KSBoYXMg YWxyZWFkeSBiZWVuIG1hZGUsIGJ1dCBwbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIHRlY2huaWNh bCBzdWdnZXN0aW9ucyBmb3IgZml4aW5nIHRoZSBnbGFyZSBzaXR1YXRpb24uPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C3B21DCEAFB64312B681ED38CF9E1FA3ericssoncom_-- From nobody Mon May 11 08:55:30 2020 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 7C0EB3A0841 for ; Mon, 11 May 2020 08:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.801 X-Spam-Level: X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 CDGBf2Z7UEbN for ; Mon, 11 May 2020 08:55:24 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80044.outbound.protection.outlook.com [40.107.8.44]) (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 F2D823A07F7 for ; Mon, 11 May 2020 08:55:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G8+QWfrh3IpCJwtk7K3N+9Al4kB59zEUV9201mU0hj08p03gVFAxZ3wMc+wKOoPUpy4POPAP8YGQtGsool8FWPvYOPxuwFQHgU9k60BKl4ndjcaOU+hejd/Mwp9Ano79TIVrbjTbOwh/cQLABW9P0/umvuBLx/uoma3war9JqsACY6i42mmCD79/6i8Z2Y6KSiyxOGx1aUV9lfXpv8irG6YwfcBn9KhvCG3HWi1vjG2Bo8aoN89G8EJSncRkaV9Y6c1hf6WB1q4PATjvWpbbO+2pL79ukFdyiz1Kg7B1rgXXRc4Suxgx6A/OzXnVtqKZq5X2R/ss1oCxUEgEsz95Mg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NRJYXby5aotOsawqO3AE3apuGRXkapt5xIJXkwxelLo=; b=HTZnX8OBanTzeK/x8PMSE5usxh3sGu2k6d6MuwoEzBbnKzBQ+3JNaRraVx+LcOTmVK9t39GIdSsoiqdK1fyII6RMXxcCVyjzNCc7f1g/k3xNLcYMhPilFw8ggtlki2hCJihzUyxjXJGZmCucj8CvQ6GEqbcD0+vpbkaXNiKysB0ywY5o0lw2+x1k+mkIYzJ0BwKtfGnSmpXjWcUIAS8YxE5q3dZGaXwfWchRh/mTLjHXVXVuAUv5Wcl9oA/EsP3vhtvbboIOCNiXRClAL2cxtLZw+GGm6tYQryr3Y2UbCbfMnAcamV5EFiPMYjWMLJZ6pOBEQWb53UBMgDlqll9N5Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NRJYXby5aotOsawqO3AE3apuGRXkapt5xIJXkwxelLo=; b=WA0IzJl3yYRsowZztCQJGv+crGhcIWWHHbsx7xvwroYdyxalAzW35VNhKF39Z7dDSAteLKv6G1aIxaMMjKUpzveOuihCVKWxZSw5xmjAtP9UmQZHHK8P5lZAYM1OfcppFTzsd0PSgRzLtE8K3CITpRz68jGuSIuZkdMxzmGEwnk= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6376.eurprd07.prod.outlook.com (2603:10a6:20b:131::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Mon, 11 May 2020 15:55:21 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Mon, 11 May 2020 15:55:21 +0000 From: Christer Holmberg To: Samir Srivastava , Keith Drage , "sipcore@ietf.org" Thread-Topic: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined Thread-Index: AQHWJsy7Tb3AmLI5VEauNVgVXU0GX6ihi0KAgABLRgCAATClAIAANqkA Date: Mon, 11 May 2020 15:55:21 +0000 Message-ID: <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> In-Reply-To: <20200511153943.792F620111@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e764fee0-aa65-40a4-1cf4-08d7f5c3b5c8 x-ms-traffictypediagnostic: AM7PR07MB6376: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04004D94E2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MwHDUBNM470TAXFP3fGszWw1PiOzXwBcRrNJ11LgiMl8JlfDcR2Nea9kI0H3e74e+pcdcLqRR2tI5wC/hjpY1zLhVAhoGQFAjHVakQUGkB4xHtjMFrtJPwdhE8GF9x+rPBTl6DAN1egPRwWGRsu1sDUHR3u9GiTcYBQtXMu5u5X50d51XmvnFL/1WDFuozr60pJHOAlgDD1YzCXbWLqA77/rRFsKCegUTf6eXzfuPQ5F0nanWklD22BVttYsbbIvHTaqJU9Njlvp+xMNtr6nHeEQ9rAVI3e5OSRkWRQ0bwL7lZlERZ/xA6zOT9Q7eUW9T5RLv2x+Y5FtU+mDXKxEhOFW6dFy3IMtwVdSztrRki+JKFSwZkzDvTmUuw//YLb7dFrskZgf3AGa3J/tCc1nUNduEAuNaUxK10rrY8SjKNK2O2vg2HCF/hJy3nXPz9gqmGRS8+1JAMHm1+ZTgLC2vi6E2M4nkFNMZMK+SSKbSqd/Ojlu1a4/na98RAC3N9GuGCeNZ8vqHegwxJP5d3EPs4Av7AHFLFuarT3i3oPqlCVm82xMb6DEMNdQhlbl54PPNPboztzIkJNIQ2GAchpqy0bPTEuIPoWPOarZ2rRSpHY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(396003)(376002)(366004)(136003)(33430700001)(478600001)(6512007)(26005)(186003)(6486002)(316002)(110136005)(15650500001)(6506007)(53546011)(76116006)(91956017)(36756003)(86362001)(66446008)(66556008)(66946007)(64756008)(66476007)(2906002)(33656002)(8676002)(33440700001)(166002)(44832011)(966005)(8936002)(5660300002)(2616005)(71200400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: xh4E2Inc1XsrfS/tQnNLA9mbl+VE59XurDLzgPuGmhwkyu+RnvnvuT9+X0y7EBz2W/2gQep8EKTdWGYn6y8g+dobcOd6+AZ9ziBY46k3/8qJN1DRxf/HSqa/CVF53f/hPg5AF9zTo/bLbkr22jSHicPx4DBkNFmjB+2WtjzgS15pEzlaBmFa6CAaDs2vcUKAv3xMx0onpO+TcFc58LSiZju7s6pl0HDtKP/V+GRVHi9ACPQ34o9trE/h0kXA28nS7JVL4Y13ZAFg/j1eDC1wmSi37NudhM5n7OAXSY11mzZKr6G4EfWGnAqjysTq+YoIiUvR+PmQgCXuTWfYvS9C3FC2g2Rkdl8XsDutRIUu4owtWxF4UJiiMpRHHxU6dTY/PzMKXjyf3lJnISFcg40WC0zej5AS2OvOt+0Y/DFyMvYIVfVqe8rBx4mMKmcDsVwkLkhYd6O50cgz2hE2ukgMbBDS+IXVrTEEe8bUixpH9fxQpZoaQ184/PzPK6v7L8R/ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_2348C80CC28F424280971DC85D3C99D3ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e764fee0-aa65-40a4-1cf4-08d7f5c3b5c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 May 2020 15:55:21.2686 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6HWL8wg53PZYmPJFSGMuOYnBQiJ7FKtg19q5MIvAm8NHecscIQ/43M3ytzPVKT91ZX9jOodFlrl0QZLYbEbb6knkm9brfW3iR6uUW06zUZA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6376 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 15:55:28 -0000 --_000_2348C80CC28F424280971DC85D3C99D3ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgc3VnZ2VzdCBjaGFuZ2luZyB0aGUgc3ViamVjdCBvZiB0aGlzIHRocmVhZCwgYmVj YXVzZSBpdCBpcyBub3Qgc3BlY2lmaWMgdG8gc2Vzc2lvbiB0aW1lcnMuDQoNClJlZ2FyZHMsDQoN CkNocmlzdGVyDQoNCkZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gb24g YmVoYWxmIG9mIFNhbWlyIFNyaXZhc3RhdmEgPHNyaXZhc3RhdmFfc2FtaXI9NDBodXNoLmNvbUBk bWFyYy5pZXRmLm9yZz4NCkRhdGU6IE1vbmRheSwgMTEgTWF5IDIwMjAgYXQgMTguNDANClRvOiBL ZWl0aCBEcmFnZSA8ZHJhZ2VrZT00MG50bHdvcmxkLmNvbUBkbWFyYy5pZXRmLm9yZz4sICJzaXBj b3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0g U2Vzc2lvbiBUaW1lcnMgKFJGQyA0MDI4KSBmb3IgUkVGRVIsIFBVQkxJU0gsIE1FU1NBR0Ugbm90 IGRlZmluZWQNCg0KSGksDQoNCiAgUGxlYXNlIGZpbmQgbXkgcmVwbGllcyBJbmxpbmUgYmVsb3cg cHJlZml4ZWQgd2l0aCBTUz4+DQoNClRoYW5rcw0KU2FtaXIgU3JpdmFzdGF2YQ0KaHR0cHM6Ly9z YW1pcnNyaXZhc3RhdmEudHlwZXBhZC5jb20vDQoNCk9uIDUvMTEvMjAyMCBhdCAyOjU5IEFNLCAi S2VpdGggRHJhZ2UiIDxkcmFnZWtlPTQwbnRsd29ybGQuY29tQGRtYXJjLmlldGYub3JnPiB3cm90 ZToNCkkgZG9udCBrbm93IHdoZXRoZXIgd2UgcmVhY2hlZCBzb21ldGhpbmcgd2UgY2FuIGZvcm1h bGx5IGRlc2NyaWJlIGFzIGENCmRlY2lzaW9uLCBidXQgdGhlIG92ZXJhbGwgb3Bpb24gd2FzIHRo YXQgaXQgc2hvdWxkIGJlIHRoZSB0ZXh0IHRoYXQNCnNob3VsZCBub3JtYXRpdmVseSBkZXNjcmli ZSB3aGF0IHRoZSByZXF1aXJlbWVudHMgd2VyZSBmb3IgdGhlIGFjdGlvbnMNCmluIHJlc3BlY3Qg b2YgaW5jbHVzaW9uIGluIG1lc3NhZ2VzLiBJZiB0aGVzZSB0YWJsZXMgd2VyZSBpbmNsdWRlZCwg dGhleQ0Kc2hvdWxkIGJlIGNsZWFybHkgZGVzY3JpYmVkIGFzIGluZm9ybWF0aXZlLg0KU1M+PiBJ IGFtIG9mIHRoZSBvcGluaW9uIHRoYXQgd2UgbmVlZCBoZWFkZXIsIG1lc3NhZ2UgZXRjIGluIHRo ZSB0YWJ1bGF0ZWQgZm9ybS4gU0lQIFBhcnNlciBkZXZlbG9wZXJzIGNhbm5vdCBiZSBleHBlY3Rl ZCB0byBrbm93IHRoZSBtaW51dGUgZGV0YWlscyBvZiBhcHBsaWNhYmlsaXR5IG9mIHRoZSBtZXNz YWdlcyBhbmQgaGVhZGVycyBldGMuIFNJUCBhcmNoaXRlY3QgaW4gdGhlIHZlbmRvciBjb21hcG5p ZXMgbWlnaHQgYmUgcmVxdWlyZWQgdG8gZ2l2ZSB0aGUgaGVhZGVycyBhbmQgbWVzc2FnZXMgaW4g dGhlIHRhYnVsYXRlZCBmb3JtIHRvIFNJUCBQYXJzZXIgZGV2ZWxvcGVycy4gSWYgd2UgYWxsIGFn cmVlIGluIHRoZSB0YWJ1bGF0ZWQgZm9ybSBhcyBTUEVDIFdyaXRlcnMsIGl0IHdpbGwgYmUgZ29v ZCBzZXJ2aWNlIHRvIHRoZSBjb21tdW5pdHkuIFdoYXQgYXJlIHRoZSBkaWZmaWN1bHRpZXMgY29u c2lkZXJlZCB3aGljaCBtYWRlIHVzIHRvIGRlcHJlY2F0ZSB0aGUgdGFibGUgZm9ybWF0Pw0KDQpG dXJ0aGVyLCB0aGUgbm9ybWF0aXZlIHRleHQgc2hvdWxkIGJlIGFkZXF1YXRlbHkgd29yZGVkIHRv IGVuY29tcGFzcyB0aGUNCnVuZGVyc3RhbmRpbmcgd2hhdCBoYXBwZW5lZCB3aGVuIG5ldyBtZXNz YWdlcyB3ZXJlIGludmVudGVkIC0gc28gcmF0aGVyDQp0aGFuIHNwZWNpZmljYWxseSBsaXN0aW5n IG1lc3NhZ2VzLCBpdCBzaG91bGQgcHJvYmFibHkgdGFsayBhYm91dA0KbWVzc2FnZXMgdGhhdCBj cmVhdGUgYSBkaWFsb2csIGV0Yy4NClNTPj4gUFVCTElTSCBSRkMgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL3JmYzM5MDMNCiAgICAgICAgIFJFRkVSIFJGQyBodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzUxNQ0KICAgICAgICAgIE1FU1NBR0UgUkZDIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmMzNDI4DQoNCiAgVGhleSBhbGwgd2VyZSBpbnZlbnRlZCBiZWZvcmUgUkZD IDQwMjguLiBUaGV5IHdlcmUgTk9UIGRldmVsb3BlZCBhZnRlciBTZXNzaW9uIFRpbWVycy4gU28g aXQgaXMgbGVmdCBiZWNhdXNlIG9mIG1pc3Rha2UuIDQwMjhiaXMgYW5kIFJGQyBkb2VzIG5vdCBt ZW50aW9uIFBVQkxJU0gsIFJFRkVSLCBNRVNTQUdFIGluIHRoZSB0ZXh0IGFueXdoZXJlLiBTVUJT Q1JJQkUsIE5PVElGWSwgUFJBQ0ssIENBTkNFTCwgUkVHSVNURVIsIE9QVElPTlMgYXJlIG9ubHkg ZGVmaW5lZCBpbiB0aGUgdGFibGUgbm93aGVyZSBpbiB0ZXh0LiBJZiB0aGUgYWRkZWQgaGVhZGVy cyAoTUlOLVNFLCBTRXNzaW9uLUV4cGlyZXMgYXJlIGZvdW5kIGluIHRoZXNlIG1lc3NhZ2Ugc2hv dWxkIGJlIHJlamVjdCB0aGUgUkVRVUVTVCBvciBhY2NlcHQgdGhlIGJ5IGZvbGxvd2luZyAiYmUg bGVuaWVudCB3aGF0IG9uZSBhY2NlcHRzIi4gU29tZSBndWlkZWxpbmUgbmVlZHMgdG8gYmUgc3Bl Y2lmaWVkLg0KICBEZXZlbG9wZXIgb2YgbmV3IG1ldGhvZCBuZWVkIHRvIGxvb2sgZWFjaCBoZWFk ZXIsIG1lc3NhZ2UgZXRjIGluIHRoZWlyIHJlc3BlY3RpdmUgUkZDLiBXaGF0IG9uZSBjYW4gc3Bl Y2lmeSBmb3IgbWV0aG9kIGZvbyBmb3IgaGVhZGVyIGZvb2JhciBpbiBhZHZhbmNlPw0KDQoNCg0K DQpLZWl0aA0KDQoNCk9uIDEwLzA1LzIwMjAgMTc6NTksIFBhdWwgS3l6aXZhdCB3cm90ZToNCj4g T24gNS8xMC8yMCA5OjEyIEFNLCBTYW1pciBTcml2YXN0YXZhIHdyb3RlOg0KPj4gSGksDQo+Pg0K Pj4gICAgVGhlIHRhYmxlIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQgaW4gUkZDIDQwMjggZG9lcyBu b3QgY29udGFpbg0KPj4gZW50cmllcyBmb3IgUkVGRVIsIFBVQkxJU0ggYW5kIE1FU1NBR0UgbWV0 aG9kcyBCZWxvdyBpcyB0aGUgdGFibGUNCj4+IGZyb20gU2VjdGlvbiA0DQo+Pg0KPj4NCj4+ICst LS0tLS0tLS0tLS0tLS0rLS0tLS0rLS0tLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0t LSstLS0rLS0tKw0KPj4gICAgIHwgICAgIEhlYWRlciB8d2hlcmV8cHJveHl8QUNLfEJZRXxDQU58 SU5WfE9QVHxSRUd8UFJBfFVQRHxTVUJ8Tk9UfA0KPj4gKy0tLS0tLS0tLS0tLS0tLSstLS0tLSst LS0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rDQo+PiAgICAgfFNl c3Npb24tRXhwaXJlc3wgIFIgIHwgYW1yIHwgLSB8IC0gfCAtIHwgbyB8IC0gfCAtIHwgLSB8IG8g fCAtIHwNCj4+IC0gfA0KPj4gICAgIHwgICAgICAgICAgICAgICB8ICAgICB8ICAgICB8ICAgfCAg IHwgICB8ICAgfCAgIHwgICB8ICAgfCB8ICAgfCAgIHwNCj4+ICAgICB8U2Vzc2lvbi1FeHBpcmVz fCAyeHggfCBhciAgfCAtIHwgLSB8IC0gfCBvIHwgLSB8IC0gfCAtIHwgbyB8IC0gfA0KPj4gLSB8 DQo+PiAgICAgfCAgICAgICAgICAgICAgIHwgICAgIHwgICAgIHwgICB8ICAgfCAgIHwgICB8ICAg fCAgIHwgICB8IHwgICB8ICAgfA0KPj4gICAgIHxNaW4tU0UgICAgICAgICB8ICBSICB8IGFtciB8 IC0gfCAtIHwgLSB8IG8gfCAtIHwgLSB8IC0gfCBvIHwgLSB8DQo+PiAtIHwNCj4+ICAgICB8ICAg ICAgICAgICAgICAgfCAgICAgfCAgICAgfCAgIHwgICB8ICAgfCAgIHwgICB8ICAgfCAgIHwgfCAg IHwgICB8DQo+PiAgICAgfE1pbi1TRSAgICAgICAgIHwgNDIyIHwgICAgIHwgLSB8IC0gfCAtIHwg bSB8IC0gfCAtIHwgLSB8IG0gfCAtIHwNCj4+IC0gfA0KPj4gKy0tLS0tLS0tLS0tLS0tLSstLS0t LSstLS0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rLS0tKy0tLSstLS0rDQo+Pg0KPj4g ICAgVGhleSBhcmUgbm90IGFwcGxpY2FibGUgZm9yIHRoZXNlLCBidXQgaXQgd291bGQgaGF2ZSBi ZWVuIGJldHRlcg0KPj4gaWYgaXQgaXMgc2FpZCBjYXRlZ29yaWNhbGx5Lg0KPg0KPiBJSVJDLCBx dWl0ZSBhIGxvbmcgdGltZSBhZ28gaXQgd2FzIGRlY2lkZWQgdGhhdCB0aGlzIHRhYmxlIGluIDMy NjEgd2FzDQo+IGEgYmFkIGlkZWEsIGJlY2F1c2UgaXQgaXMgZXNzZW50aWFsbHkgYSBzdW1tYXJ5 IG9mIG5vcm1hdGl2ZSBsYW5ndWFnZQ0KPiBpbiBvdGhlciBzZWN0aW9ucyBvZiB0aGUgZG9jdW1l bnQgYW5kIGlzIG5lY2Vzc2FyaWx5IGFuIGFwcHJveGltYXRpb24uDQo+DQo+IEFmdGVyIHRoYXQs IG90aGVyIHdvcmsgdGhhdCB1cGRhdGVzIGFuZCBleHRlbmRzIDMyNjEgaGFzIGJlZW4NCj4gaW5j b25zaXN0ZW50IGl0IHdoZXRoZXIgaXQgdXBkYXRlcyB0aGUgdGFibGUgb3Igbm90Lg0KPg0KPiBX aGF0IHdlIHNob3VsZCBiZSBjYXJlZnVsIG9mIGlzIHRoYXQgdGhlIGluIHByb2dyZXNzIHVwZGF0 ZSB0byBzZXNzaW9uDQo+IHRpbWVycyBpcyBjbGVhciwgbm9ybWF0aXZlbHkgYW5kIGV4cG9zaXRp dmVseSwgIG9uZSB3YXkgb3IgYW5vdGhlci4NCj4NCj4gICAgIFRoYW5rcywNCj4gICAgIFBhdWwN Cj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g c2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg== --_000_2348C80CC28F424280971DC85D3C99D3ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <8CE6948B59AA5C4FA7160C178E46DFE4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tRkki IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc3VnZ2Vz dCBjaGFuZ2luZyB0aGUgc3ViamVjdCBvZiB0aGlzIHRocmVhZCwgYmVjYXVzZSBpdCBpcyBub3Qg c3BlY2lmaWMgdG8gc2Vzc2lvbiB0aW1lcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJpc3RlcjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNpcGNvcmUgJmx0O3NpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFNhbWlyIFNyaXZhc3RhdmEgJmx0O3Ny aXZhc3RhdmFfc2FtaXI9NDBodXNoLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+TW9uZGF5LCAxMSBNYXkgMjAyMCBhdCAxOC40MDxicj4NCjxiPlRvOiA8L2I+S2VpdGgg RHJhZ2UgJmx0O2RyYWdla2U9NDBudGx3b3JsZC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7LCAmcXVv dDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW3NpcGNvcmVdIFNlc3Npb24gVGltZXJzIChSRkMgNDAyOCkgZm9y IFJFRkVSLCBQVUJMSVNILCBNRVNTQUdFIG5vdCBkZWZpbmVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSw8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGlu ZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6 MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNTAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtsaW5lLWhlaWdo dDoxNTAlO2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOyBQ bGVhc2UgZmluZCBteSByZXBsaWVzIElubGluZSBiZWxvdyBwcmVmaXhlZCB3aXRoIFNTJmd0OyZn dDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGlu ZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5TYW1pciBTcml2YXN0YXZhJm5ic3A7PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly9zYW1pcnNyaXZhc3RhdmEudHlwZXBhZC5jb20vIj5odHRwczovL3NhbWlyc3JpdmFzdGF2 YS50eXBlcGFkLmNvbS88L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KT24gNS8xMS8yMDIwIGF0IDI6NTkgQU0sICZxdW90 O0tlaXRoIERyYWdlJnF1b3Q7ICZsdDtkcmFnZWtlPTQwbnRsd29ybGQuY29tQGRtYXJjLmlldGYu b3JnJmd0OyB3cm90ZToNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNt IDBjbSAwY20gOC4wcHQ7bWFyZ2luLWxlZnQ6Ny41cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDox NTAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtsaW5lLWhlaWdodDoxNTAlO2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkgZG9udCBrbm93IHdoZXRoZXIg d2UgcmVhY2hlZCBzb21ldGhpbmcgd2UgY2FuIGZvcm1hbGx5IGRlc2NyaWJlIGFzIGENCjxicj4N CmRlY2lzaW9uLCBidXQgdGhlIG92ZXJhbGwgb3Bpb24gd2FzIHRoYXQgaXQgc2hvdWxkIGJlIHRo ZSB0ZXh0IHRoYXQgPGJyPg0Kc2hvdWxkIG5vcm1hdGl2ZWx5IGRlc2NyaWJlIHdoYXQgdGhlIHJl cXVpcmVtZW50cyB3ZXJlIGZvciB0aGUgYWN0aW9ucyA8YnI+DQppbiByZXNwZWN0IG9mIGluY2x1 c2lvbiBpbiBtZXNzYWdlcy4gSWYgdGhlc2UgdGFibGVzIHdlcmUgaW5jbHVkZWQsIHRoZXkgPGJy Pg0Kc2hvdWxkIGJlIGNsZWFybHkgZGVzY3JpYmVkIGFzIGluZm9ybWF0aXZlLjxicj4NClNTJmd0 OyZndDsgSSBhbSBvZiB0aGUgb3BpbmlvbiB0aGF0IHdlIG5lZWQgaGVhZGVyLCBtZXNzYWdlIGV0 YyBpbiB0aGUgdGFidWxhdGVkIGZvcm0uIFNJUCBQYXJzZXIgZGV2ZWxvcGVycyBjYW5ub3QgYmUg ZXhwZWN0ZWQgdG8ga25vdyB0aGUgbWludXRlIGRldGFpbHMgb2YgYXBwbGljYWJpbGl0eSBvZiB0 aGUgbWVzc2FnZXMgYW5kIGhlYWRlcnMgZXRjLiBTSVAgYXJjaGl0ZWN0IGluIHRoZSB2ZW5kb3Ig Y29tYXBuaWVzIG1pZ2h0IGJlIHJlcXVpcmVkIHRvDQogZ2l2ZSB0aGUgaGVhZGVycyBhbmQgbWVz c2FnZXMgaW4gdGhlIHRhYnVsYXRlZCBmb3JtIHRvIFNJUCBQYXJzZXIgZGV2ZWxvcGVycy4gSWYg d2UgYWxsIGFncmVlIGluIHRoZSB0YWJ1bGF0ZWQgZm9ybSBhcyBTUEVDIFdyaXRlcnMsIGl0IHdp bGwgYmUgZ29vZCBzZXJ2aWNlIHRvIHRoZSBjb21tdW5pdHkuIFdoYXQgYXJlIHRoZSBkaWZmaWN1 bHRpZXMgY29uc2lkZXJlZCB3aGljaCBtYWRlIHVzIHRvIGRlcHJlY2F0ZSB0aGUgdGFibGUgZm9y bWF0Pzxicj4NCjxicj4NCkZ1cnRoZXIsIHRoZSBub3JtYXRpdmUgdGV4dCBzaG91bGQgYmUgYWRl cXVhdGVseSB3b3JkZWQgdG8gZW5jb21wYXNzIHRoZSA8YnI+DQp1bmRlcnN0YW5kaW5nIHdoYXQg aGFwcGVuZWQgd2hlbiBuZXcgbWVzc2FnZXMgd2VyZSBpbnZlbnRlZCAtIHNvIHJhdGhlciA8YnI+ DQp0aGFuIHNwZWNpZmljYWxseSBsaXN0aW5nIG1lc3NhZ2VzLCBpdCBzaG91bGQgcHJvYmFibHkg dGFsayBhYm91dCA8YnI+DQptZXNzYWdlcyB0aGF0IGNyZWF0ZSBhIGRpYWxvZywgZXRjLjxicj4N ClNTJmd0OyZndDsgUFVCTElTSCBSRkMmbmJzcDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjMzkwMyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzM5MDM8YnI+ DQo8L2E+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1JFRkVSIFJGQyZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNTE1Ij5odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvcmZjMzUxNTxicj4NCjwvYT4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IE1FU1NBR0UgUkZDJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzM0MjgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmMzNDI4PGJyPg0K PGJyPg0KPC9hPiZuYnNwOyBUaGV5IGFsbCB3ZXJlIGludmVudGVkIGJlZm9yZSBSRkMgNDAyOC4u IFRoZXkgd2VyZSBOT1QgZGV2ZWxvcGVkIGFmdGVyIFNlc3Npb24gVGltZXJzLiBTbyBpdCBpcyBs ZWZ0IGJlY2F1c2Ugb2YgbWlzdGFrZS4gNDAyOGJpcyBhbmQgUkZDIGRvZXMgbm90IG1lbnRpb24g UFVCTElTSCwgUkVGRVIsIE1FU1NBR0UgaW4gdGhlIHRleHQgYW55d2hlcmUuIFNVQlNDUklCRSwg Tk9USUZZLCBQUkFDSywgQ0FOQ0VMLCBSRUdJU1RFUiwgT1BUSU9OUw0KIGFyZSBvbmx5IGRlZmlu ZWQgaW4gdGhlIHRhYmxlIG5vd2hlcmUgaW4gdGV4dC4gSWYgdGhlIGFkZGVkIGhlYWRlcnMgKE1J Ti1TRSwgU0Vzc2lvbi1FeHBpcmVzIGFyZSBmb3VuZCBpbiB0aGVzZSBtZXNzYWdlIHNob3VsZCBi ZSByZWplY3QgdGhlIFJFUVVFU1Qgb3IgYWNjZXB0IHRoZSBieSBmb2xsb3dpbmcgJnF1b3Q7YmUg bGVuaWVudCB3aGF0IG9uZSBhY2NlcHRzJnF1b3Q7LiBTb21lIGd1aWRlbGluZSBuZWVkcyB0byBi ZSBzcGVjaWZpZWQuJm5ic3A7PGJyPg0KJm5ic3A7IERldmVsb3BlciBvZiBuZXcgbWV0aG9kIG5l ZWQgdG8gbG9vayBlYWNoIGhlYWRlciwgbWVzc2FnZSBldGMgaW4gdGhlaXIgcmVzcGVjdGl2ZSBS RkMuIFdoYXQgb25lIGNhbiBzcGVjaWZ5IGZvciBtZXRob2QgZm9vIGZvciBoZWFkZXIgZm9vYmFy IGluIGFkdmFuY2U/Jm5ic3A7PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KS2VpdGg8YnI+ DQo8YnI+DQo8YnI+DQpPbiAxMC8wNS8yMDIwIDE3OjU5LCBQYXVsIEt5eml2YXQgd3JvdGU6PGJy Pg0KJmd0OyBPbiA1LzEwLzIwIDk6MTIgQU0sIFNhbWlyIFNyaXZhc3RhdmEgd3JvdGU6PGJyPg0K Jmd0OyZndDsgSGksPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsmbmJzcDsgVGhl IHRhYmxlIG1lbnRpb25lZCBpbiBTZWN0aW9uIDQgaW4gUkZDIDQwMjggZG9lcyBub3QgY29udGFp biA8YnI+DQomZ3Q7Jmd0OyBlbnRyaWVzIGZvciBSRUZFUiwgUFVCTElTSCBhbmQgTUVTU0FHRSBt ZXRob2RzIEJlbG93IGlzIHRoZSB0YWJsZSA8YnI+DQomZ3Q7Jmd0OyBmcm9tIFNlY3Rpb24gNDxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmIzQzOy0tLS0tLS0tLS0t LS0tLSYjNDM7LS0tLS0mIzQzOy0tLS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0m IzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOzxicj4N CiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhl YWRlciB8d2hlcmV8cHJveHl8QUNLfEJZRXxDQU58SU5WfE9QVHxSRUd8UFJBfFVQRHxTVUJ8Tk9U fDxicj4NCiZndDsmZ3Q7ICYjNDM7LS0tLS0tLS0tLS0tLS0tJiM0MzstLS0tLSYjNDM7LS0tLS0m IzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0tLSYj NDM7LS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5i c3A7IHxTZXNzaW9uLUV4cGlyZXN8Jm5ic3A7IFImbmJzcDsgfCBhbXIgfCAtIHwgLSB8IC0gfCBv IHwgLSB8IC0gfCAtIHwgbyB8IC0gfCA8YnI+DQomZ3Q7Jmd0OyAtIHw8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHwm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8IHwmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8 PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IHxTZXNzaW9uLUV4cGlyZXN8IDJ4eCB8 IGFyJm5ic3A7IHwgLSB8IC0gfCAtIHwgbyB8IC0gfCAtIHwgLSB8IG8gfCAtIHwgPGJyPg0KJmd0 OyZndDsgLSB8PGJyPg0KJmd0OyZndDsgJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHwmbmJz cDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgfCB8Jm5i c3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgfDxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNw OyB8TWluLVNFJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwmbmJzcDsgUiZuYnNwOyB8IGFtciB8IC0gfCAtIHwgLSB8IG8gfCAtIHwgLSB8IC0gfCBvIHwg LSB8IDxicj4NCiZndDsmZ3Q7IC0gfDxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgfCZuYnNw OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyB8Jm5ic3A7 Jm5ic3A7IHwgfCZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7IHw8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsmbmJzcDsmbmJzcDsgfE1pbi1TRSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB8IDQyMiB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgLSB8IC0gfCAt IHwgbSB8IC0gfCAtIHwgLSB8IG0gfCAtIHwgPGJyPg0KJmd0OyZndDsgLSB8PGJyPg0KJmd0OyZn dDsgJiM0MzstLS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tJiM0MzstLS0tLSYjNDM7LS0tJiM0Mzst LS0mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0tLSYjNDM7LS0tJiM0MzstLS0mIzQzOy0t LSYjNDM7LS0tJiM0Mzs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7ICZuYnNwOyZuYnNwOyBU aGV5IGFyZSBub3QgYXBwbGljYWJsZSBmb3IgdGhlc2UsIGJ1dCBpdCB3b3VsZCBoYXZlIGJlZW4g YmV0dGVyIDxicj4NCiZndDsmZ3Q7IGlmIGl0IGlzIHNhaWQgY2F0ZWdvcmljYWxseS48YnI+DQom Z3Q7PGJyPg0KJmd0OyBJSVJDLCBxdWl0ZSBhIGxvbmcgdGltZSBhZ28gaXQgd2FzIGRlY2lkZWQg dGhhdCB0aGlzIHRhYmxlIGluIDMyNjEgd2FzIDxicj4NCiZndDsgYSBiYWQgaWRlYSwgYmVjYXVz ZSBpdCBpcyBlc3NlbnRpYWxseSBhIHN1bW1hcnkgb2Ygbm9ybWF0aXZlIGxhbmd1YWdlIDxicj4N CiZndDsgaW4gb3RoZXIgc2VjdGlvbnMgb2YgdGhlIGRvY3VtZW50IGFuZCBpcyBuZWNlc3Nhcmls eSBhbiBhcHByb3hpbWF0aW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IEFmdGVyIHRoYXQsIG90aGVy IHdvcmsgdGhhdCB1cGRhdGVzIGFuZCBleHRlbmRzIDMyNjEgaGFzIGJlZW4gPGJyPg0KJmd0OyBp bmNvbnNpc3RlbnQgaXQgd2hldGhlciBpdCB1cGRhdGVzIHRoZSB0YWJsZSBvciBub3QuPGJyPg0K Jmd0Ozxicj4NCiZndDsgV2hhdCB3ZSBzaG91bGQgYmUgY2FyZWZ1bCBvZiBpcyB0aGF0IHRoZSBp biBwcm9ncmVzcyB1cGRhdGUgdG8gc2Vzc2lvbiA8YnI+DQomZ3Q7IHRpbWVycyBpcyBjbGVhciwg bm9ybWF0aXZlbHkgYW5kIGV4cG9zaXRpdmVseSwmbmJzcDsgb25lIHdheSBvciBhbm90aGVyLjxi cj4NCiZndDs8YnI+DQomZ3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RoYW5rcyw8YnI+DQom Z3Q7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1BhdWw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2lw Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxicj4NCjxicj4N Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lw Y29yZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_2348C80CC28F424280971DC85D3C99D3ericssoncom_-- From nobody Mon May 11 09:03:15 2020 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 289493A0954 for ; Mon, 11 May 2020 09:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 KPf2tB7Vpdaq for ; Mon, 11 May 2020 09:01:49 -0700 (PDT) Received: from know-smtprelay-omc-9.server.virginmedia.net (know-smtprelay-omc-9.server.virginmedia.net [80.0.253.73]) (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 28DC63A091A for ; Mon, 11 May 2020 09:01:48 -0700 (PDT) Received: from [192.168.0.17] ([81.97.229.170]) by cmsmtp with ESMTPA id YAsEjSlbzf1r6YAsEjZKxZ; Mon, 11 May 2020 17:01:47 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=DOmhHRFb c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=283K6oDNAAAA:8 a=48vgC7mUAAAA:8 a=rjCgbG3JMJD6-E-pxw4A:9 a=QEXdDO2ut3YA:10 a=8c8-Wn2gAAAA:8 a=bxg1CBVd4W2hIA9LovAA:9 a=LMmogGgL3NFYM_0e:21 a=_W_S_7VecoQA:10 a=jdmypcmVXt6yuKJ2GOTk:22 a=w1C3t2QeGrPiZgrLijVG:22 a=4UqCWT6cI65jMZUUGvaY:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1589212907; bh=HxVbuM5rfOerx/06G1+BK4IBhTWJ64mTtBd0e/Vx0Mc=; h=Subject:To:References:From:Date:In-Reply-To; b=3zML+yJ/Sh9eP8HumKcelS+V2PRWrNTXK0XdqneN0dd3rGYLfkApxiERCbGzcRjtq Rt8aizPE+NW6qiffF6TpsisDPjIgn6vISXvsMiZXJPtKwwf491Pl88jBzksYYmrSJU MxnZauPGucmXL4gFgIqRzrYWI4LD22/+0S7HuEna6QIijF9DyKMqnNQrfaOa1/hkP2 mNt17/88StaNQrL43hL/c+crs24oCxWyf4p1//nYkXkOJSw+RfvIRavHkq3CaUqICY QnxX6cUdnZPYVfEUYGSWf5Iz0SgsBNVnuiMgnJTmREkKmkxQCTHD4pHToddlwRU74D lzmatcwS6b7cQ== To: sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> From: Keith Drage Message-ID: <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> Date: Mon, 11 May 2020 17:01:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200511153943.792F620111@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="------------22157A676125CE1BF0507433" Content-Language: en-GB X-CMAE-Envelope: MS4wfBk40/Xlp7KXnX8bcCZIOM77C4m1vFiTgRNRJ58MsmIeuT0xwqPRxUqlORLYR24LyW2tfpoxSGxjtsffZ/8L6oENyHRJf/QQYG8+FwVbu9j2f+Lea5iV fi23YgTHN79kJeYngNRxeWC1NSzg0joc5uHELou8ArEB9pnJ2aRHJeiD Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 16:02:01 -0000 This is a multi-part message in MIME format. --------------22157A676125CE1BF0507433 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Most header fields are included for a specific purpose entirely unassociated with what mesage it is in. i.e. things like -    included because this message creates a dialog -    included because this message ends a dialog -    included becases this message is the request in a transaction -    included because this message responds to a transaction -    included because I can include it in any request etc. Those concepts have existed since RFC 3261. The exceptions tend to be header fields that are defined along with a MESSAGE to carry them, i.e. in the same RFC. I am not suggesting the definers of new messages should not give due consideration, only that in most cases they will not need to add any extra requirements to their new RFC, because all the considerations could already be in the header field defining RFC. Keith P.S. I would note that you cannot go on the date of publication - many RFCs take years to get through publication request to published while others proceed quicker. On 11/05/2020 16:39, Samir Srivastava wrote: > Hi, > >   Please find my replies Inline below prefixed with SS>> > > Thanks > Samir Srivastava > https://samirsrivastava.typepad.com/ > > On 5/11/2020 at 2:59 AM, "Keith Drage" > wrote: > > I dont know whether we reached something we can formally describe > as a > decision, but the overall opion was that it should be the text that > should normatively describe what the requirements were for the > actions > in respect of inclusion in messages. If these tables were > included, they > should be clearly described as informative. > SS>> I am of the opinion that we need header, message etc in the > tabulated form. SIP Parser developers cannot be expected to know > the minute details of applicability of the messages and headers > etc. SIP architect in the vendor comapnies might be required to > give the headers and messages in the tabulated form to SIP Parser > developers. If we all agree in the tabulated form as SPEC Writers, > it will be good service to the community. What are the > difficulties considered which made us to deprecate the table format? > > Further, the normative text should be adequately worded to > encompass the > understanding what happened when new messages were invented - so > rather > than specifically listing messages, it should probably talk about > messages that create a dialog, etc. > SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 >          REFER RFC https://tools.ietf.org/html/rfc3515 >           MESSAGE RFC https://tools.ietf.org/html/rfc3428 > >   They all were invented before RFC 4028.. They were NOT developed > after Session Timers. So it is left because of mistake. 4028bis > and RFC does not mention PUBLISH, REFER, MESSAGE in the text > anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are > only defined in the table nowhere in text. If the added headers > (MIN-SE, SEssion-Expires are found in these message should be > reject the REQUEST or accept the by following "be lenient what one > accepts". Some guideline needs to be specified. >   Developer of new method need to look each header, message etc in > their respective RFC. What one can specify for method foo for > header foobar in advance? > > > > > Keith > > > On 10/05/2020 17:59, Paul Kyzivat wrote: > > On 5/10/20 9:12 AM, Samir Srivastava wrote: > >> Hi, > >> > >>    The table mentioned in Section 4 in RFC 4028 does not contain > >> entries for REFER, PUBLISH and MESSAGE methods Below is the table > >> from Section 4 > >> > >> > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >>     |     Header > |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o > | - | > >> - | > >>     |               |     |     |   |   |   |   | |   |   | |   > |   | > >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o > | - | > >> - | > >>     |               |     |     |   |   |   |   | |   |   | |   > |   | > >>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o > | - | > >> - | > >>     |               |     |     |   |   |   |   | |   |   | |   > |   | > >>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m > | - | > >> - | > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >> > >>    They are not applicable for these, but it would have been > better > >> if it is said categorically. > > > > IIRC, quite a long time ago it was decided that this table in > 3261 was > > a bad idea, because it is essentially a summary of normative > language > > in other sections of the document and is necessarily an > approximation. > > > > After that, other work that updates and extends 3261 has been > > inconsistent it whether it updates the table or not. > > > > What we should be careful of is that the in progress update to > session > > timers is clear, normatively and expositively,  one way or another. > > > >     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 > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --------------22157A676125CE1BF0507433 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Most header fields are included for a specific purpose entirely unassociated with what mesage it is in.

i.e. things like

-    included because this message creates a dialog

-    included because this message ends a dialog

-    included becases this message is the request in a transaction

-    included because this message responds to a transaction

-    included because I can include it in any request

etc.

Those concepts have existed since RFC 3261.

The exceptions tend to be header fields that are defined along with a MESSAGE to carry them, i.e. in the same RFC.

I am not suggesting the definers of new messages should not give due consideration, only that in most cases they will not need to add any extra requirements to their new RFC, because all the considerations could already be in the header field defining RFC.


Keith

P.S. I would note that you cannot go on the date of publication - many RFCs take years to get through publication request to published while others proceed quicker.



On 11/05/2020 16:39, Samir Srivastava wrote:
Hi,

  Please find my replies Inline below prefixed with SS>>

Thanks

On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=40ntlworld.com@dmarc.ietf.org> wrote:
I dont know whether we reached something we can formally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they
should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format?

Further, the normative text should be adequately worded to encompass the
understanding what happened when new messages were invented - so rather
than specifically listing messages, it should probably talk about
messages that create a dialog, etc.
SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
         REFER RFC https://tools.ietf.org/html/rfc3515
          MESSAGE RFC https://tools.ietf.org/html/rfc3428

  They all were invented before RFC 4028.. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. 
  Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance? 




Keith


On 10/05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>> Hi,
>>
>>    The table mentioned in Section 4 in RFC 4028 does not contain
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table
>> from Section 4
>>
>>
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>     |     Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - |
>> - |
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>
>>    They are not applicable for these, but it would have been better
>> if it is said categorically.
>
> IIRC, quite a long time ago it was decided that this table in 3261 was
> a bad idea, because it is essentially a summary of normative language
> in other sections of the document and is necessarily an approximation.
>
> After that, other work that updates and extends 3261 has been
> inconsistent it whether it updates the table or not.
>
> What we should be careful of is that the in progress update to session
> timers is clear, normatively and expositively,  one way or another.
>
>     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
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--------------22157A676125CE1BF0507433-- From nobody Mon May 11 14:18:27 2020 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 68D8B3A0D1D for ; Mon, 11 May 2020 14:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 10hThS6FCFfZ for ; Mon, 11 May 2020 14:18:23 -0700 (PDT) Received: from mail-oo1-xc2a.google.com (mail-oo1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (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 746473A0D1A for ; Mon, 11 May 2020 14:18:23 -0700 (PDT) Received: by mail-oo1-xc2a.google.com with SMTP id i9so2269805ool.5 for ; Mon, 11 May 2020 14:18:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wfnAANMQzrt4FH4kNtyLf+scPS/64F0qsiDWnP8E9+Y=; b=pB4Ucd0DgYUJQW/s7FpbzVymtNb5K1P2Qc3ejUOHuFUVE3MbfKJLn2smGEoPSZrWhj AIaMSU6BRyKjaR5bSfS8w4KaeD89QH1UhdOEztfXxvcohAjraYTA2qAh5jnipFhO5e2a mAN/ciwD7PNpzDKOn/YN+9Ko2iiJyMwhjdjM7t4YsokH3VDA2+tz+9gCCxBg2Vr6YTp4 XzuNntDoRKPYMZOxHD2G7YMesbK6U54hc8OyEV4KxDSjvnx2RM3ii+wDF0k53kEzcFQd O0LWqhR2bSTq0t/C18JhtpgQemchL0u3cm3Pf7lgTYKB1FdYEW/A3PPY0MgJXIvTtGH0 OAsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wfnAANMQzrt4FH4kNtyLf+scPS/64F0qsiDWnP8E9+Y=; b=XY6+1h0drAw9jbcj2KuiLKdj2pzvvNEOX1KhqED19AhpoZSqShjFTypnIEnBnqXsQF P23qM/d8gLZD0SVx/d4giGO+Zfm3VmkRuReKFWlwbny8/JwFQw21R9CzdVrtbszP0YXW FC9tonFqpvehRCkQ02ivWdEh/cs65DJKXYCd2JNGO5I/rBRNbdt4MDT4g23Xy2yQ48Vt 5TvS+mxV50oFI3N6YlmZz3kEfeHHD0fD/m8d/wjmG74SE6teWugBiF7i8CB/jQu5NiR/ t4oOB0Hm57VGW7n4UkpZh9mhIwQZcbvwml5Ar5+ODCTlhzIxQu6b3EBXRJcuA04m6Duq VLvA== X-Gm-Message-State: AGi0PuYYbEopQdSGzirebbkRyTCtb6O9urVni67/iD9lmTNna4towQjV jom5BKI6k3mqW6SokAppQUdxwsG/we8= X-Google-Smtp-Source: APiQypIAj5nkpcFfsyDmMY4hnTweZVJOGDwAukOfIltm6c2pOyho+Vh4LzxM52hzLLHBWAR9EuHijA== X-Received: by 2002:a4a:d204:: with SMTP id c4mr3590635oos.1.1589231902044; Mon, 11 May 2020 14:18:22 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com. [209.85.167.182]) by smtp.gmail.com with ESMTPSA id t140sm2776692oif.13.2020.05.11.14.18.20 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2020 14:18:21 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id t199so16453083oif.7 for ; Mon, 11 May 2020 14:18:20 -0700 (PDT) X-Received: by 2002:aca:1007:: with SMTP id 7mr21706467oiq.139.1589231900495; Mon, 11 May 2020 14:18:20 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Roman Shpount Date: Mon, 11 May 2020 17:18:09 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e51e4005a565e20d" Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 21:18:25 -0000 --000000000000e51e4005a565e20d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Christer, I have two issues with this proposal: 1. Defining proxy behavior based on having a transaction in progress: This is hard to implement in practice since initial INVITE and UPDATE might not even go over the same path and the same proxies. 2. Not allowing UAS to reduce the S-E: UAS can be just a half of the B2BUA and might not have a choice in this matter. I do not think these requirements are necessary. All we need to require is consistent behavior for both proxies and UAS, i.e. that they always should insert or reduce S-E to the same value. Also, even with these requirements we need provisions for both UAC and UAS to deal with race conditions when S-E value is ambiguous. When dealing with legacy implementations which do not follow this newly propose specifications both races are possible. _____________ Roman Shpount On Mon, May 11, 2020 at 11:52 AM Christer Holmberg wrote: > Hi, > > > > And, if you for whatever reason rather watch Tiger King than the IETF 102 > SIPCORE session, below is basically what was suggested in order to solve > the session-timer glare situation: > > > > > > UAC: > > > > - If a UA inserts S-E in an INVITE request the UA MUST insert > the same S-E in any UPDATE request it sends while the INVITE transaction = is > ongoing > > - If a UA has conflicting S-E information once the INVITE and > UPDATE transaction have completed, it MUST send a new UPDATE with S-E, in > order to =E2=80=9Csync=E2=80=9D the S-E state among all entities > > > > > > PROXY: > > > > Request handling: > > - MUST reject the request if the S-E value is too small > > o No matter if the request contains Supported:timer or not > > - If the proxy inserts/forwards/modifies the S-E in an INVITE > request the proxy MUST identically insert/forward/modify the same S-E in > any UPDATE request > > o The proxy MAY insert/modify the S-E if it knows that there is no > active INVITE transaction > > > > Response handling: > > - If response contains S-E, the proxy MUST NOT modify it > > - If response does not contain S-E, the proxy MAY insert S-E if > it remembers that the associated request contained Supported:timer > > > > UAS: > > > > - If request contains S-E: > > o The UAS copies the S-E value of the request into the response > > o The UAS MUST NOT reduce the S-E value in the response > > =C2=A7 If the UAS wants to change the S-E value, it later sends a reques= t by > its own > > - If the request does not contain S-E: > > o If the request contains Supported:timer, the UAS MAY include S-E in > the response > > > > Regards, > > > > Christer > > > > > > *From: *sipcore on behalf of Christer Holmberg > > *Date: *Monday, 11 May 2020 at 14.36 > *To: *"sipcore@ietf.org" > *Subject: *[sipcore] 4028bis: memory refresh > > > > Hi, > > > > Now, when the sip-oauth draft is more or less done (in the RFC editor=E2= =80=99s > queue), I intend to take up the work on 4028bis (session-timer) again. > > > > We previously had e-mail discussions and phone calls, there is an issue > tracker on GitHub, and we discussed the suggested solutions at IETF#103. = To > refresh your memory, please take a look at the video: > https://www.youtube.com/watch?v=3DC2yeckBmgPg (the session-timer > presentation begins at around 7:30 minutes). > > > > The decision to make a bis (instead of an update draft) has already been > made, but please take a look at the technical suggestions for fixing the > glare situation. > > > > Regards, > > > > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --000000000000e51e4005a565e20d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Christer,

I have two issues with thi= s proposal:

1. Defining proxy behavior based on ha= ving a transaction in progress: This is hard to implement in practice since= initial INVITE and UPDATE might not even go over the same path and the sam= e proxies.

2. Not allowing UAS to reduce the S-E: = UAS can be just a half of the B2BUA and might not have a choice=C2=A0in thi= s matter.

I do not think these requirements are ne= cessary. All we need to require=C2=A0is consistent behavior for both proxie= s and UAS, i.e. that they always should insert or reduce S-E to the same va= lue.

Also, even with these requirements we need pr= ovisions=C2=A0for both UAC and UAS to deal with race conditions when S-E va= lue is ambiguous. When dealing with legacy implementations which do not fol= low this newly propose specifications both races=C2=A0are possible.
_____________
Roman Shpount


On Mo= n, May 11, 2020 at 11:52 AM Christer Holmberg <christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote:

Hi,

=C2=A0

And, if you for whatever reason= rather watch Tiger King than the IETF 102 SIPCORE session, below is basica= lly what was suggested in order to solve the session-timer glare situation:=

=C2=A0

=C2=A0

UAC:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a UA inserts S-E in an = INVITE request the UA MUST insert the same S-E in any UPDATE request it sen= ds while the INVITE transaction is ongoing

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If a UA has conflicting S-= E information once the INVITE and UPDATE transaction have completed, it MUS= T send a new UPDATE with S-E, in order to =E2=80=9Csync=E2=80=9D the S-E st= ate among all entities

=C2=A0

=C2=A0

PROXY:

=C2=A0

Requ= est handling:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 MUST reject the request if= the S-E value is too small

<= span>o=C2=A0=C2=A0 No matter if the request c= ontains Supported:timer or not

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the proxy inserts/forwa= rds/modifies the S-E in an INVITE request the proxy MUST identically insert= /forward/modify the same S-E in any UPDATE request

<= span>o=C2=A0=C2=A0 The proxy MAY insert/modif= y the S-E if it knows that there is no active INVITE transaction<= /u>

=C2=A0

Resp= onse handling:

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If response contains S-E, = the proxy MUST NOT modify it

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If response does not conta= in S-E, the proxy MAY insert S-E if it remembers that the associated reques= t contained Supported:timer

=C2=A0

UAS:

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If request contains S-E:

<= span>o=C2=A0=C2=A0 The UAS copies the S-E val= ue of the request into the response

<= span>o=C2=A0=C2=A0 The UAS MUST NOT reduce th= e S-E value in the response

=C2=A7=C2=A0 If the UAS wants to change= the S-E value, it later sends a request by its own

-=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the request does not co= ntain S-E:

<= span>o=C2=A0=C2=A0 If the request contains Su= pported:timer, the UAS MAY include S-E in the response=

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

=C2=A0

From: = sipcore <sipcore-bounces@ietf= .org> on behalf of Christer Holmberg <christer.holmberg=3D40ericsson.com@= dmarc.ietf.org>
Date: Monday, 11 May 2020 at 14.36
To: "sipc= ore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] 4028bis: memory refresh

=C2=A0

Hi,

=C2=A0

Now, when the sip-oauth draft i= s more or less done (in the RFC editor=E2=80=99s queue), I intend to take u= p the work on 4028bis (session-timer) again.

=C2=A0

We previously had e-mail discus= sions and phone calls, there is an issue tracker on GitHub, and we discusse= d the suggested solutions at IETF#103. To refresh your memory, please take = a look at the video: https://www.youtube.com/watch?v=3DC2yeckBmgPg (the session-timer presentation begins at around 7:30 = minutes).

=C2=A0

The decision to make a bis (ins= tead of an update draft) has already been made, but please take a look at t= he technical suggestions for fixing the glare situation.

=C2=A0

Regards,

=C2=A0

Christer

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--000000000000e51e4005a565e20d-- From nobody Tue May 12 00:18:33 2020 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 1804E3A0CA0 for ; Tue, 12 May 2020 00:18:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 6CHfTjScdJoM for ; Tue, 12 May 2020 00:18:28 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20075.outbound.protection.outlook.com [40.107.2.75]) (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 DE42F3A0C9F for ; Tue, 12 May 2020 00:18:27 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WZf+S/vljXRk8eDjlaVX8IUCRct6UcqH3FEt4QcQ3849W36F+MRDO62xsamHVoSD68zi6PZAcyK9qg8DpOweWSvILuf/degET8hzXiNwP8V1spXndlIRnf77L2psKU8IDZ1x7KoRHjbxA9PX7SE04/czUS4oRAuRBkU5aCYtcwUsk50SjreOhx1k7fuOB94/a7eNUJtZuzoISXhpVvA1Q9LG0cerZViJgihHxkRC32CFwFFXhfnWwPr4ATLdzeYWc0Yac401i22aUjUReSHyT6mslJL3jkN/SSUk6Dssqgd38mtDthSgsaYW2l7nGHskXvoysi1rZEhlsR4TJ3g/ZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5cqNBY9VBty8KtSAzDE+T0vTm79wG/cj0C8tHep9IlY=; b=fv+DQciKZJfwooj+SRDKRwA4S5K8QUFzKkymkjk/bKi9YZglzAZflTlN5h3wFjn1ntMvh1Rdo5wrnfTYv+PGN64HLPkwLwXmVFSLUDXbbrvlvF8skjQ93nnnf1+swIBH6QOyjGMZLKyUNkGeDw60t+KSERHJiJT56TH4bkWYLp2mOEch9/8bqQeJmFhuMe6zglZABtBJLQ6veywK6BIpiTN0Ub3WkH8YmWbXBjHdQtZcsKs4+73f/80SbTnfC3egBwxNJapBMi4BvstIG4mJ+2x6QCUN0cbJlEbKkn7E3l/lCeZhXSZG8BRc+5Xj3joPyo6w7qRZI+e8VvUbEmD2uQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5cqNBY9VBty8KtSAzDE+T0vTm79wG/cj0C8tHep9IlY=; b=ATbA3b7jhErDqy0TzTMjWzvWPePjjL8a6AJwMz3VG/BYlMLd068x/SVRKJDbkWjpPIsE8lTq7NLuLKbrT+FKts8gMEm4PZx5e6EmWqgkeOpbKrj4zSKIaQe9vhxRdSv4bb9LiTjGxN2Sgz86tluMIVg529df3HGaYPwf22NNGs0= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6231.eurprd07.prod.outlook.com (2603:10a6:20b:133::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Tue, 12 May 2020 07:18:24 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Tue, 12 May 2020 07:18:24 +0000 From: Christer Holmberg To: Roman Shpount , Christer Holmberg CC: "sipcore@ietf.org" Thread-Topic: [sipcore] 4028bis: memory refresh Thread-Index: AQHWJ6wXHMVHOyLTxUOyiBxMgD7Rv6ijY/6AgADaAAA= Date: Tue, 12 May 2020 07:18:24 +0000 Message-ID: <42075766-84EB-412E-8AF6-B6C8BF11DBD2@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b0f56a8-b4d6-4dcd-1a61-08d7f644a8d2 x-ms-traffictypediagnostic: AM7PR07MB6231: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0401647B7F x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /fpMDROZugBQLy1ZgzkfHTr6ZpjwLz34TXF/9uz1Wf/d21WazW1Lk1fjcwHcXMiO2Pf2rY0B1bGQ+c7YfOB6wTElWO2I7wg0paQeykatXVLvKMOOJsy71LdY4qZ6p1RAoAZumVLMq6514D+WAW/tEiuuLePcL+ZI/fDWD7J2XCGQ8zR+/NZTEEtBH5xecht4sfY7+YN+P+y2es0Fn2nuhNJCj0iLL3IXRDmMBLPRZl3CwfEA8EyRaIM+DnvzsvVULFXDYgC5ABmKniYvlZm86dXglfioHoM5zuzh/GjM7fRHL4dvp489pV1C5orxbrioKBLwkRJc9z6wHFbRzQv6zKENWAjIZFq833L6+GFVBVxY5lj8JZ/omtqdA/WUz8GBrCQiq1IpsLGLe90k0prXI2IUmZiHpBc/RngNDuZstuMgeipL+dIX3JjxE5t2zTCdD4Tcej0RmJlT2q6ZjghUJDkRwAOUDB8rwte2JJAaIctYNt/QQIbReJKX8yqTQGyZ2uNZBykJ97EGUXJWDOaG7rB4UvXeNb4SPfXbNrxY8YosPzlI8qWq8WZUb70lHe+Bsm8GyeGxqm1AjNhrmay3YLsRaZqcxycrOqPzca5vlR4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(39860400002)(376002)(136003)(366004)(33430700001)(5660300002)(33440700001)(26005)(166002)(966005)(66946007)(33656002)(86362001)(66446008)(478600001)(186003)(66476007)(6506007)(91956017)(53546011)(64756008)(76116006)(66556008)(36756003)(316002)(110136005)(2906002)(6512007)(4326008)(2616005)(8676002)(8936002)(6486002)(71200400001)(44832011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PdQN0nx9wIw2/s5Z+1swMsNZN4Z43EaReOYBJeWlZcYRm8j4ka8IGjHmDYRWTCyMZja+lOaqkDloysIfd1ffei/rl/Cn25wW3qnNcIZSrSUcMTiZ1WlLAQ+AWWMjgTG2xMYANJWM1PXVEuolml/p1ccIak7jPBATmSiui6OgmKIucfALHEB9/n15XddidjEwb4mHn5K6daYgXT7jx3qCUTOlCCrHJpiFwJxRU35jVAX/jX2NU+MKcP7tH9uWfvwr/nrqcFpAxoJyZ1iLXyXagdOzuROxpzm4Waot5hXj2lFapNkYYm6Qxl73OvgGu9Sokak+eqUAibEDMusPDROQEWq/n+cudhCe3s4bURhp/dPj9vehRecyoFSW457q9WZH4b8me2y+fybU5L5uP4HbyZvTLwtlWn8gy42dmENZdnoQHfG30DMxOAx37o/fJYP1odz5ree9rKYL6RBzU0gVbBbx7XVCDRlggsHVOOefNLJ/mRZ4GpOQEMFLGF1pDnpQ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4207576684EB412E8AF6B6C8BF11DBD2ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9b0f56a8-b4d6-4dcd-1a61-08d7f644a8d2 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 May 2020 07:18:24.5580 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wBygaKhdKj+wk8c0nejH5U4uumXNJXyDPPsro5f+vXDCc/4t4TqHOzALYMjP2diU3WriZIRlIwwlGQPIcAiuEBvzZWWQu9OU7ZfeW3y8/V4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6231 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 07:18:31 -0000 --_000_4207576684EB412E8AF6B6C8BF11DBD2ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9tYW4sDQoNCj5JIGhhdmUgdHdvIGlzc3VlcyB3aXRoIHRoaXMgcHJvcG9zYWw6DQo+DQo+ MS4gRGVmaW5pbmcgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2aW5nIGEgdHJhbnNhY3Rpb24g aW4gcHJvZ3Jlc3M6IFRoaXMgaXMgaGFyZCB0byBpbXBsZW1lbnQgaW4gcHJhY3RpY2Ugc2luY2Ug aW5pdGlhbCBJTlZJVEUgYW5kIFVQREFURSBtaWdodCA+bm90IGV2ZW4gZ28gb3ZlciB0aGUgc2Ft ZSBwYXRoIGFuZCB0aGUgc2FtZSBwcm94aWVzLg0KPg0KPjIuIE5vdCBhbGxvd2luZyBVQVMgdG8g cmVkdWNlIHRoZSBTLUU6IFVBUyBjYW4gYmUganVzdCBhIGhhbGYgb2YgdGhlIEIyQlVBIGFuZCBt aWdodCBub3QgaGF2ZSBhIGNob2ljZSBpbiB0aGlzIG1hdHRlci4NCj4NCj5JIGRvIG5vdCB0aGlu ayB0aGVzZSByZXF1aXJlbWVudHMgYXJlIG5lY2Vzc2FyeS4gQWxsIHdlIG5lZWQgdG8gcmVxdWly ZSBpcyBjb25zaXN0ZW50IGJlaGF2aW9yIGZvciBib3RoIHByb3hpZXMgYW5kIFVBUywgaS5lLiB0 aGF0IHRoZXkgYWx3YXlzID5zaG91bGQgaW5zZXJ0IG9yIHJlZHVjZSBTLUUgdG8gdGhlIHNhbWUg dmFsdWUuDQo+DQo+QWxzbywgZXZlbiB3aXRoIHRoZXNlIHJlcXVpcmVtZW50cyB3ZSBuZWVkIHBy b3Zpc2lvbnMgZm9yIGJvdGggVUFDIGFuZCBVQVMgdG8gZGVhbCB3aXRoIHJhY2UgY29uZGl0aW9u cyB3aGVuIFMtRSB2YWx1ZSBpcyBhbWJpZ3VvdXMuIFdoZW4gPmRlYWxpbmcgd2l0aCBsZWdhY3kg aW1wbGVtZW50YXRpb25zIHdoaWNoIGRvIG5vdCBmb2xsb3cgdGhpcyBuZXdseSBwcm9wb3NlIHNw ZWNpZmljYXRpb25zIGJvdGggcmFjZXMgYXJlIHBvc3NpYmxlLg0KVGhlIHRleHQgc2F5cyB0aGF0 LCBpZiB0aGUgdmFsdWUgaXMgYW1iaWd1b3VzLCB0aGUgVUFDIHdpbGwgc2VuZCBhIG5ldyBTLUUg b25jZSB0aGUgSU5WSVRFIHRyYW5zYWN0aW9uIGhhcyBjb21wbGV0ZWQuIEkgZ3Vlc3Mgd2UgY291 bGQgc2F5IHRoZSBzYW1lIHRoaW5nIGZvciB0aGUgVUFTLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rl cg0KDQoNCg0KT24gTW9uLCBNYXkgMTEsIDIwMjAgYXQgMTE6NTIgQU0gQ2hyaXN0ZXIgSG9sbWJl cmcgPGNocmlzdGVyLmhvbG1iZXJnPTQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPG1haWx0 bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSGksDQoNCkFuZCwgaWYg eW91IGZvciB3aGF0ZXZlciByZWFzb24gcmF0aGVyIHdhdGNoIFRpZ2VyIEtpbmcgdGhhbiB0aGUg SUVURiAxMDIgU0lQQ09SRSBzZXNzaW9uLCBiZWxvdyBpcyBiYXNpY2FsbHkgd2hhdCB3YXMgc3Vn Z2VzdGVkIGluIG9yZGVyIHRvIHNvbHZlIHRoZSBzZXNzaW9uLXRpbWVyIGdsYXJlIHNpdHVhdGlv bjoNCg0KDQpVQUM6DQoNCg0KLSAgICAgICAgICBJZiBhIFVBIGluc2VydHMgUy1FIGluIGFuIElO VklURSByZXF1ZXN0IHRoZSBVQSBNVVNUIGluc2VydCB0aGUgc2FtZSBTLUUgaW4gYW55IFVQREFU RSByZXF1ZXN0IGl0IHNlbmRzIHdoaWxlIHRoZSBJTlZJVEUgdHJhbnNhY3Rpb24gaXMgb25nb2lu Zw0KDQotICAgICAgICAgIElmIGEgVUEgaGFzIGNvbmZsaWN0aW5nIFMtRSBpbmZvcm1hdGlvbiBv bmNlIHRoZSBJTlZJVEUgYW5kIFVQREFURSB0cmFuc2FjdGlvbiBoYXZlIGNvbXBsZXRlZCwgaXQg TVVTVCBzZW5kIGEgbmV3IFVQREFURSB3aXRoIFMtRSwgaW4gb3JkZXIgdG8g4oCcc3luY+KAnSB0 aGUgUy1FIHN0YXRlIGFtb25nIGFsbCBlbnRpdGllcw0KDQoNClBST1hZOg0KDQpSZXF1ZXN0IGhh bmRsaW5nOg0KDQotICAgICAgICAgIE1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IGlmIHRoZSBTLUUg dmFsdWUgaXMgdG9vIHNtYWxsDQoNCm8gICBObyBtYXR0ZXIgaWYgdGhlIHJlcXVlc3QgY29udGFp bnMgU3VwcG9ydGVkOnRpbWVyIG9yIG5vdA0KDQotICAgICAgICAgIElmIHRoZSBwcm94eSBpbnNl cnRzL2ZvcndhcmRzL21vZGlmaWVzIHRoZSBTLUUgaW4gYW4gSU5WSVRFIHJlcXVlc3QgdGhlIHBy b3h5IE1VU1QgaWRlbnRpY2FsbHkgaW5zZXJ0L2ZvcndhcmQvbW9kaWZ5IHRoZSBzYW1lIFMtRSBp biBhbnkgVVBEQVRFIHJlcXVlc3QNCg0KbyAgIFRoZSBwcm94eSBNQVkgaW5zZXJ0L21vZGlmeSB0 aGUgUy1FIGlmIGl0IGtub3dzIHRoYXQgdGhlcmUgaXMgbm8gYWN0aXZlIElOVklURSB0cmFuc2Fj dGlvbg0KDQpSZXNwb25zZSBoYW5kbGluZzoNCg0KLSAgICAgICAgICBJZiByZXNwb25zZSBjb250 YWlucyBTLUUsIHRoZSBwcm94eSBNVVNUIE5PVCBtb2RpZnkgaXQNCg0KLSAgICAgICAgICBJZiBy ZXNwb25zZSBkb2VzIG5vdCBjb250YWluIFMtRSwgdGhlIHByb3h5IE1BWSBpbnNlcnQgUy1FIGlm IGl0IHJlbWVtYmVycyB0aGF0IHRoZSBhc3NvY2lhdGVkIHJlcXVlc3QgY29udGFpbmVkIFN1cHBv cnRlZDp0aW1lcg0KDQpVQVM6DQoNCg0KLSAgICAgICAgICBJZiByZXF1ZXN0IGNvbnRhaW5zIFMt RToNCg0KbyAgIFRoZSBVQVMgY29waWVzIHRoZSBTLUUgdmFsdWUgb2YgdGhlIHJlcXVlc3QgaW50 byB0aGUgcmVzcG9uc2UNCg0KbyAgIFRoZSBVQVMgTVVTVCBOT1QgcmVkdWNlIHRoZSBTLUUgdmFs dWUgaW4gdGhlIHJlc3BvbnNlDQoNCuKAoiAgSWYgdGhlIFVBUyB3YW50cyB0byBjaGFuZ2UgdGhl IFMtRSB2YWx1ZSwgaXQgbGF0ZXIgc2VuZHMgYSByZXF1ZXN0IGJ5IGl0cyBvd24NCg0KLSAgICAg ICAgICBJZiB0aGUgcmVxdWVzdCBkb2VzIG5vdCBjb250YWluIFMtRToNCg0KbyAgIElmIHRoZSBy ZXF1ZXN0IGNvbnRhaW5zIFN1cHBvcnRlZDp0aW1lciwgdGhlIFVBUyBNQVkgaW5jbHVkZSBTLUUg aW4gdGhlIHJlc3BvbnNlDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0KRnJvbTogc2lwY29y ZSA8c2lwY29yZS1ib3VuY2VzQGlldGYuLm9yZzxtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYu b3JnPj4gb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1iZXJnIDxjaHJpc3Rlci5ob2xtYmVyZz00 MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBlcmljc3Nvbi5jb21AZG1hcmMu aWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCAxMSBNYXkgMjAyMCBhdCAxNC4zNg0KVG86ICJzaXBj b3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPiIgPHNpcGNvcmVAaWV0Zi5vcmc8 bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NpcGNvcmVdIDQwMjhiaXM6IG1l bW9yeSByZWZyZXNoDQoNCkhpLA0KDQpOb3csIHdoZW4gdGhlIHNpcC1vYXV0aCBkcmFmdCBpcyBt b3JlIG9yIGxlc3MgZG9uZSAoaW4gdGhlIFJGQyBlZGl0b3LigJlzIHF1ZXVlKSwgSSBpbnRlbmQg dG8gdGFrZSB1cCB0aGUgd29yayBvbiA0MDI4YmlzIChzZXNzaW9uLXRpbWVyKSBhZ2Fpbi4NCg0K V2UgcHJldmlvdXNseSBoYWQgZS1tYWlsIGRpc2N1c3Npb25zIGFuZCBwaG9uZSBjYWxscywgdGhl cmUgaXMgYW4gaXNzdWUgdHJhY2tlciBvbiBHaXRIdWIsIGFuZCB3ZSBkaXNjdXNzZWQgdGhlIHN1 Z2dlc3RlZCBzb2x1dGlvbnMgYXQgSUVURiMxMDMuIFRvIHJlZnJlc2ggeW91ciBtZW1vcnksIHBs ZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgdmlkZW86IGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dh dGNoP3Y9QzJ5ZWNrQm1nUGcgKHRoZSBzZXNzaW9uLXRpbWVyIHByZXNlbnRhdGlvbiBiZWdpbnMg YXQgYXJvdW5kIDc6MzAgbWludXRlcykuDQoNClRoZSBkZWNpc2lvbiB0byBtYWtlIGEgYmlzIChp bnN0ZWFkIG9mIGFuIHVwZGF0ZSBkcmFmdCkgaGFzIGFscmVhZHkgYmVlbiBtYWRlLCBidXQgcGxl YXNlIHRha2UgYSBsb29rIGF0IHRoZSB0ZWNobmljYWwgc3VnZ2VzdGlvbnMgZm9yIGZpeGluZyB0 aGUgZ2xhcmUgc2l0dWF0aW9uLg0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0 DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo= --_000_4207576684EB412E8AF6B6C8BF11DBD2ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <0B613A872E6FEF42A973760148404F87@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuZ21haWwtbTYxOTUzMDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBo LCBsaS5nbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFp bC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtbV82MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1GSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRkkiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGkgUm9tYW4sPG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PC9zcGFuPkkgaGF2ZSB0d28gaXNzdWVzIHdpdGggdGhp cyBwcm9wb3NhbDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PiZndDs8L3NwYW4+MS4gRGVmaW5pbmcgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2aW5nIGEg dHJhbnNhY3Rpb24gaW4gcHJvZ3Jlc3M6IFRoaXMgaXMgaGFyZCB0byBpbXBsZW1lbnQgaW4gcHJh Y3RpY2Ugc2luY2UgaW5pdGlhbCBJTlZJVEUgYW5kIFVQREFURSBtaWdodA0KPHNwYW4gbGFuZz0i RU4tVVMiPiZndDs8L3NwYW4+bm90IGV2ZW4gZ28gb3ZlciB0aGUgc2FtZSBwYXRoIGFuZCB0aGUg c2FtZSBwcm94aWVzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+Jmd0Ozwvc3Bhbj4yLiBOb3QgYWxsb3dpbmcgVUFTIHRvIHJlZHVjZSB0aGUgUy1FOiBVQVMg Y2FuIGJlIGp1c3QgYSBoYWxmIG9mIHRoZSBCMkJVQSBhbmQgbWlnaHQgbm90IGhhdmUgYSBjaG9p Y2UmbmJzcDtpbiB0aGlzIG1hdHRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPiZndDs8L3NwYW4+SSBkbyBub3QgdGhpbmsgdGhlc2UgcmVxdWlyZW1lbnRz IGFyZSBuZWNlc3NhcnkuIEFsbCB3ZSBuZWVkIHRvIHJlcXVpcmUmbmJzcDtpcyBjb25zaXN0ZW50 IGJlaGF2aW9yIGZvciBib3RoIHByb3hpZXMgYW5kIFVBUywgaS5lLiB0aGF0IHRoZXkgYWx3YXlz DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jmd0Ozwvc3Bhbj5zaG91bGQgaW5zZXJ0IG9yIHJlZHVjZSBT LUUgdG8gdGhlIHNhbWUgdmFsdWUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj4mZ3Q7PC9zcGFuPkFsc28sIGV2ZW4gd2l0aCB0aGVzZSByZXF1aXJlbWVudHMg d2UgbmVlZCBwcm92aXNpb25zJm5ic3A7Zm9yIGJvdGggVUFDIGFuZCBVQVMgdG8gZGVhbCB3aXRo IHJhY2UgY29uZGl0aW9ucyB3aGVuIFMtRSB2YWx1ZSBpcyBhbWJpZ3VvdXMuIFdoZW4NCjxzcGFu IGxhbmc9IkVOLVVTIj4mZ3Q7PC9zcGFuPmRlYWxpbmcgd2l0aCBsZWdhY3kgaW1wbGVtZW50YXRp b25zIHdoaWNoIGRvIG5vdCBmb2xsb3cgdGhpcyBuZXdseSBwcm9wb3NlIHNwZWNpZmljYXRpb25z IGJvdGggcmFjZXMmbmJzcDthcmUgcG9zc2libGUuPGJyIGNsZWFyPSJhbGwiPg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHRleHQg c2F5cyB0aGF0LCBpZiB0aGUgdmFsdWUgaXMgYW1iaWd1b3VzLCB0aGUgVUFDIHdpbGwgc2VuZCBh IG5ldyBTLUUgb25jZSB0aGUgSU5WSVRFIHRyYW5zYWN0aW9uIGhhcyBjb21wbGV0ZWQuIEkgZ3Vl c3Mgd2UgY291bGQgc2F5IHRoZSBzYW1lIHRoaW5nIGZvciB0aGUgVUFTLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1h eSAxMSwgMjAyMCBhdCAxMTo1MiBBTSBDaHJpc3RlciBIb2xtYmVyZyAmbHQ7Y2hyaXN0ZXIuaG9s bWJlcmc9PGEgaHJlZj0ibWFpbHRvOjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnIj40MGVy aWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkZJIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmQsIGlmIHlvdSBmb3Ig d2hhdGV2ZXIgcmVhc29uIHJhdGhlciB3YXRjaCBUaWdlciBLaW5nIHRoYW4gdGhlIElFVEYgMTAy IFNJUENPUkUgc2Vzc2lvbiwgYmVsb3cgaXMgYmFzaWNhbGx5IHdoYXQgd2FzIHN1Z2dlc3RlZCBp biBvcmRlciB0byBzb2x2ZSB0aGUgc2Vzc2lvbi10aW1lcg0KIGdsYXJlIHNpdHVhdGlvbjo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj5VQUM6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj5JZiBhIFVBIGluc2VydHMgUy1FIGluIGFuIElOVklURSByZXF1ZXN0IHRoZSBV QSBNVVNUIGluc2VydCB0aGUgc2FtZSBTLUUgaW4gYW55IFVQREFURSByZXF1ZXN0IGl0IHNlbmRz IHdoaWxlIHRoZSBJTlZJVEUgdHJhbnNhY3Rpb24gaXMgb25nb2luZzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPi08L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+SWYgYSBVQSBoYXMgY29uZmxpY3RpbmcgUy1FIGluZm9ybWF0aW9uIG9uY2UgdGhlIElOVklU RSBhbmQgVVBEQVRFIHRyYW5zYWN0aW9uIGhhdmUgY29tcGxldGVkLCBpdCBNVVNUIHNlbmQgYSBu ZXcgVVBEQVRFIHdpdGggUy1FLCBpbiBvcmRlciB0byDigJxzeW5j4oCdIHRoZSBTLUUgc3RhdGUg YW1vbmcgYWxsIGVudGl0aWVzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ UFJPWFk6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO3RleHQtaW5kZW50OjE4LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+UmVxdWVz dCBoYW5kbGluZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYxOTUz MDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPk1VU1QgcmVqZWN0IHRoZSByZXF1ZXN0IGlm IHRoZSBTLUUgdmFsdWUgaXMgdG9vIHNtYWxsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPk5vIG1hdHRl ciBpZiB0aGUgcmVxdWVzdCBjb250YWlucyBTdXBwb3J0ZWQ6dGltZXIgb3Igbm90PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj5JZiB0aGUgcHJveHkgaW5zZXJ0cy9mb3J3YXJkcy9tb2RpZmllcyB0aGUgUy1F IGluIGFuIElOVklURSByZXF1ZXN0IHRoZSBwcm94eSBNVVNUIGlkZW50aWNhbGx5IGluc2VydC9m b3J3YXJkL21vZGlmeSB0aGUgc2FtZSBTLUUgaW4gYW55IFVQREFURSByZXF1ZXN0PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlz dHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPlRoZSBwcm94eSBNQVkgaW5zZXJ0L21vZGlmeSB0aGUgUy1FIGlmIGl0IGtu b3dzIHRoYXQgdGhlcmUgaXMgbm8gYWN0aXZlIElOVklURSB0cmFuc2FjdGlvbjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxOC4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPlJlc3BvbnNlIGhhbmRsaW5nOjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0i RU4tVVMiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+SWYgcmVzcG9uc2UgY29udGFpbnMgUy1FLCB0aGUgcHJveHkgTVVTVCBO T1QgbW9kaWZ5IGl0PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1 MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss c2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiByZXNwb25zZSBkb2VzIG5vdCBjb250 YWluIFMtRSwgdGhlIHByb3h5IE1BWSBpbnNlcnQgUy1FIGlmIGl0IHJlbWVtYmVycyB0aGF0IHRo ZSBhc3NvY2lhdGVkIHJlcXVlc3QgY29udGFpbmVkIFN1cHBvcnRlZDp0aW1lcjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPlVBUzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iZ21haWwtbTYxOTUzMDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4tPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHJl cXVlc3QgY29udGFpbnMgUy1FOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgVUFTIGNvcGllcyB0 aGUgUy1FIHZhbHVlIG9mIHRoZSByZXF1ZXN0IGludG8gdGhlIHJlc3BvbnNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5vPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoZSBVQVMgTVVTVCBOT1QgcmVkdWNlIHRoZSBTLUUgdmFsdWUgaW4gdGhlIHJl c3BvbnNlPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0 MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQiPg0K PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTpXaW5nZGluZ3MiPsKnPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPklmIHRoZSBVQVMgd2FudHMgdG8gY2hhbmdlIHRoZSBTLUUgdmFsdWUsIGl0IGxh dGVyIHNlbmRzIGEgcmVxdWVzdCBieSBpdHMgb3duPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+LTwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUg cmVxdWVzdCBkb2VzIG5vdCBjb250YWluIFMtRTo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iZ21haWwtbTYxOTUzMDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1 b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhl IHJlcXVlc3QgY29udGFpbnMgU3VwcG9ydGVkOnRpbWVyLCB0aGUgVUFTIE1BWSBpbmNsdWRlIFMt RSBpbiB0aGUgcmVzcG9uc2U8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SZWdhcmRzLDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPkNocmlzdGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zaXBjb3JlICZsdDs8YSBocmVm PSJtYWlsdG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c2lwY29y ZS1ib3VuY2VzQGlldGYuLm9yZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBDaHJpc3RlciBIb2xtYmVy ZyAmbHQ7Y2hyaXN0ZXIuaG9sbWJlcmc9PGEgaHJlZj0ibWFpbHRvOjQwZXJpY3Nzb24uY29tQGRt YXJjLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIDExIE1heSAyMDIwIGF0IDE0LjM2 PGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86c2lwY29yZUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmVAaWV0Zi5vcmc8 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc2lwY29yZV0gNDAyOGJpczogbWVtb3J5IHJl ZnJlc2g8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZJIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ob3csIHdoZW4g dGhlIHNpcC1vYXV0aCBkcmFmdCBpcyBtb3JlIG9yIGxlc3MgZG9uZSAoaW4gdGhlIFJGQyBlZGl0 b3LigJlzIHF1ZXVlKSwgSSBpbnRlbmQgdG8gdGFrZSB1cCB0aGUgd29yayBvbiA0MDI4YmlzIChz ZXNzaW9uLXRpbWVyKSBhZ2Fpbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5XZSBwcmV2aW91c2x5 IGhhZCBlLW1haWwgZGlzY3Vzc2lvbnMgYW5kIHBob25lIGNhbGxzLCB0aGVyZSBpcyBhbiBpc3N1 ZSB0cmFja2VyIG9uIEdpdEh1YiwgYW5kIHdlIGRpc2N1c3NlZCB0aGUgc3VnZ2VzdGVkIHNvbHV0 aW9ucyBhdCBJRVRGIzEwMy4gVG8gcmVmcmVzaCB5b3VyDQogbWVtb3J5LCBwbGVhc2UgdGFrZSBh IGxvb2sgYXQgdGhlIHZpZGVvOiA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cueW91dHViZS5j b20vd2F0Y2g/dj1DMnllY2tCbWdQZyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnlvdXR1 YmUuY29tL3dhdGNoP3Y9QzJ5ZWNrQm1nUGc8L2E+DQo8c3BhbiBsYW5nPSJFTi1VUyI+KHRoZSBz ZXNzaW9uLXRpbWVyIHByZXNlbnRhdGlvbiBiZWdpbnMgYXQgYXJvdW5kIDc6MzAgbWludXRlcyku PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5n PSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRlY2lzaW9uIHRvIG1ha2UgYSBiaXMgKGluc3Rl YWQgb2YgYW4gdXBkYXRlIGRyYWZ0KSBoYXMgYWxyZWFkeSBiZWVuIG1hZGUsIGJ1dCBwbGVhc2Ug dGFrZSBhIGxvb2sgYXQgdGhlIHRlY2huaWNhbCBzdWdnZXN0aW9ucyBmb3IgZml4aW5nIHRoZSBn bGFyZSBzaXR1YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj5DaHJpc3Rlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0i bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYub3Jn PC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZTwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4207576684EB412E8AF6B6C8BF11DBD2ericssoncom_-- From nobody Tue May 12 03:54:42 2020 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 9088B3A0D7C for ; Tue, 12 May 2020 03:54:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 RwUXez0SfEWQ for ; Tue, 12 May 2020 03:54:32 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (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 042B63A0D7F for ; Tue, 12 May 2020 03:54:31 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 891D3A03DC for ; Tue, 12 May 2020 10:54:31 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=FOrs+WNctbKdnum93jAAMa7vl9a8rLRx1h/MpZSAR9g=; b=O9vMe6Bz14ahHSl/69T2Jx/1f4ydgvaoG3s2230OuQMsxgmQBAlsW7/xyFb7p98XNXt6FavKfJ8UBFiVBC5s+2ByymhIwkQU0sm0wJ5hHQkxUXd/duoAWsF+xFu0bVRiLdjPB0j2K0PsJDoGNsw8Z5bPQewV+lbWucCUCtxwH6GOExQ+A/dOTOxQ9iXgl6MADf350jQXRPTxA1TkmwQdLXOYHQSa9r6PW/IAenR1Tr9sLLqTv3ET+5QbJ+l/nffQrOdWwJRx3tNw4la5kboy2axr4BU6HUuJ1H0cLoMfMWPE1qMbRjawDj1jBioPDs9HTaDtNPH1jM91Mfm7Zpcbsg== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Tue, 12 May 2020 10:54:30 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 7F9542011C; Tue, 12 May 2020 10:54:30 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 12 May 2020 16:54:29 +0600 To: "Keith Drage" , sipcore@ietf.org From: "Samir Srivastava" In-Reply-To: <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> Content-Type: multipart/alternative; boundary="=_b851b8de7f9cd9b761d99a1183754d7a" Message-Id: <20200512105430.7F9542011C@smtp.hushmail.com> Archived-At: Subject: [sipcore] Deprecation of tabular format of header fields || Was Re: Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 10:54:35 -0000 --=_b851b8de7f9cd9b761d99a1183754d7a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Keith Drage, The below does not answer reason for deprecating tabular format i.e. what are things which cannot be captured in tabular format. ThanksSamir Srivastavahttps://samirsrivastava.typepad.com/ On 5/11/2020 at 9:32 PM, "Keith Drage" wrote: Most header fields are included for a specific purpose entirely unassociated with what mesage it is in. i.e. things like - included because this message creates a dialog - included because this message ends a dialog - included becases this message is the request in a transaction - included because this message responds to a transaction - included because I can include it in any request etc. Those concepts have existed since RFC 3261. The exceptions tend to be header fields that are defined along with a MESSAGE to carry them, i.e. in the same RFC. I am not suggesting the definers of new messages should not give due consideration, only that in most cases they will not need to add any extra requirements to their new RFC, because all the considerations could already be in the header field defining RFC. Keith P.S. I would note that you cannot go on the date of publication - many RFCs take years to get through publication request to published while others proceed quicker. On 11/05/2020 16:39, Samir Srivastava wrote: Hi, Please find my replies Inline below prefixed with SS>> Thanks Samir Srivastava https://samirsrivastava.typepad.com/ On 5/11/2020 at 2:59 AM, "Keith Drage" wrote: I dont know whether we reached something we can formally describe as a decision, but the overall opion was that it should be the text that should normatively describe what the requirements were for the actions in respect of inclusion in messages. If these tables were included, they should be clearly described as informative. SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format? Further, the normative text should be adequately worded to encompass the understanding what happened when new messages were invented - so rather than specifically listing messages, it should probably talk about messages that create a dialog, etc. SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 REFER RFC https://tools.ietf.org/html/rfc3515 MESSAGE RFC https://tools.ietf.org/html/rfc3428 They all were invented before RFC 4028.. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance? Keith On 10/05/2020 17:59, Paul Kyzivat wrote: > On 5/10/20 9:12 AM, Samir Srivastava wrote: >> Hi, >> >> The table mentioned in Section 4 in RFC 4028 does not contain >> entries for REFER, PUBLISH and MESSAGE methods Below is the table >> from Section 4 >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | >> - | >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >> They are not applicable for these, but it would have been better >> if it is said categorically. > > IIRC, quite a long time ago it was decided that this table in 3261 was > a bad idea, because it is essentially a summary of normative language > in other sections of the document and is necessarily an approximation. > > After that, other work that updates and extends 3261 has been > inconsistent it whether it updates the table or not. > > What we should be careful of is that the in progress update to session > timers is clear, normatively and expositively, one way or another. > > 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --=_b851b8de7f9cd9b761d99a1183754d7a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi = Keith Drage,

  The below does not answer reason for= deprecating tabular format i.e. what are things which cannot be captured i= n tabular format.

 Thanks
Samir Sri= vastava

On 5/11/2020 at 9:32 PM, "Keith Drage" <d= rageke=3D40ntlworld.com@dmarc.ietf.org> wrote:
=20

Most header fields are included for a specific purpose entirely unassociated with what mesage it is in.

i.e. things like

-    included because this message creates a dialog

-    included because this message ends a dialog

-    included becases this message is the request in = a transaction

-    included because this message responds to a tran= saction

-    included because I can include it in any request=

etc.

Those concepts have existed since RFC 3261.

The exceptions tend to be header fields that are defined along with a MESSAGE to carry them, i.e. in the same RFC.

I am not suggesting the definers of new messages should not give due consideration, only that in most cases they will not need to add any extra requirements to their new RFC, because all the considerations could already be in the header field defining RFC.


Keith

P.S. I would note that you cannot go on the date of publication - many RFCs take years to get through publication request to published while others proceed quicker.



On 11/05/2020 16:39, Samir Srivastava wrote:
=20
Hi,

  Please find my replies Inline below prefixed with SS>>

Thanks

On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=3D40ntlworld.com@d= marc.ietf.org> wrote:
I dont know whether we reached something we can formally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they
should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format?

Further, the normative text should be adequately worded to encompass the
understanding what happened when new messages were invented - so rather
than specifically listing messages, it should probably talk about
messages that create a dialog, etc.
SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
         REFER RFC https://tools.ie= tf.org/html/rfc3515
          MESSAGE RFC https://tools.= ietf.org/html/rfc3428

  They all were invented before RFC 4028.. They were N= OT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. 
  Developer of new method need to look each header, messag= e etc in their respective RFC. What one can specify for method foo for header foobar in advance? 




Keith


On 10/05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>> Hi,
>>
>>    The table mentioned in Section 4 in RFC 4= 028 does not contain
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table
>> from Section 4
>>
>>
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+--= -+---+
>>     |     Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+--= -+---+
>>     |Session-Expires|  R  | a= mr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |     &nbs= p;         |    = ; |     |   |   |   |&nbs= p;  |   |   |   | |   |   |
>>     |Session-Expires| 2xx | ar  | = - | - | - | o | - | - | - | o | - |
>> - |
>>     |     &nbs= p;         |    = ; |     |   |   |   |&nbs= p;  |   |   |   | |   |   |
>>     |Min-SE    &nbs= p;    |  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |     &nbs= p;         |    = ; |     |   |   |   |&nbs= p;  |   |   |   | |   |   |
>>     |Min-SE    &nbs= p;    | 422 |     | - | - | - | m | - | - | - | m | - |
>> - |
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+--= -+---+
>>
>>    They are not applicable for these, but it= would have been better
>> if it is said categorically.
>
> IIRC, quite a long time ago it was decided that this table in 3261 was
> a bad idea, because it is essentially a summary of normative language
> in other sections of the document and is necessarily an approximation.
>
> After that, other work that updates and extends 3261 has been
> inconsistent it whether it updates the table or not.
>
> What we should be careful of is that the in progress update to session
> timers is clear, normatively and expositively,  one w= ay or another.
>
>     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<= /blockquote> 

________________________________________=
_______
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/l=
istinfo/sipcore
--=_b851b8de7f9cd9b761d99a1183754d7a-- From nobody Tue May 12 04:06:06 2020 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 C26F63A0D7D for ; Tue, 12 May 2020 04:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.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 FDOLdZ4ll3Kx for ; Tue, 12 May 2020 04:06:02 -0700 (PDT) Received: from smtp3.hushmail.com (smtp3a.hushmail.com [65.39.178.201]) (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 E1E913A0D7B for ; Tue, 12 May 2020 04:06:01 -0700 (PDT) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 88020E03AE for ; Tue, 12 May 2020 11:06:01 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=jA6f2HZLgiVj2DBICbK594E+G8ljNTwfHhC2odGELSE=; b=PKtwIRywJNNQILV/b1eCr1r2E5EFsUW9g6Hnjy78oU/EeD1d6CrBriLav4gRVMVpbj0gdvk3AGHi/GKP4/ucUf+YslGiRaBdIc1p5CdOGem2OrsxgYtRtNP9XENiS9Z+z6Jhb9xPEfPHt2a0d/5Jhxb2QTgD/E0Tk8uzB1xpMWDFQwMg6YQ6CFFHS8mN+Q11nTJUgpfw8VAw9JJ/Avg94StpQHZxTFqQRenolEtVjan5R+E+pHzlJZ32gn+l+1ytodZpws7sZtCQk40BBnMW57ZRERMreCXzpf8w/4/10PP6NjNEPIgqtNrGtRbxSHYOuNKjuht2sBftT0FGM12+PA== Received: from smtp.hushmail.com (w9.hushmail.com [65.39.178.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS; Tue, 12 May 2020 11:06:00 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 9497C2011C; Tue, 12 May 2020 11:06:00 +0000 (UTC) MIME-Version: 1.0 Date: Tue, 12 May 2020 17:06:00 +0600 To: "Christer Holmberg" , "Keith Drage" , sipcore@ietf.org From: "Samir Srivastava" In-Reply-To: <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> Content-Type: multipart/alternative; boundary="=_4c2ccc5a2e512cf1a214fe5f84640441" Message-Id: <20200512110600.9497C2011C@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 11:06:04 -0000 --=_4c2ccc5a2e512cf1a214fe5f84640441 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Christer, I am hoping that in the next version 4028bis, The Min-SE, Session-Expires header field will have consideration for REFER, PUBLISH, MESSAGE methods, in tabular format or in text. Tabular format or text will depend on the agreement on another thread discussion which is started today. ThanksSamir Srivastavahttps://samirsrivastava.typepad.com/ On 5/11/2020 at 9:25 PM, "Christer Holmberg" wrote: Hi, I suggest changing the subject of this thread, because it is not specific to session timers. Regards, Christer From: sipcore on behalf of Samir Srivastava Date: Monday, 11 May 2020 at 18.40 To: Keith Drage , "sipcore@ietf.org" Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined Hi, Please find my replies Inline below prefixed with SS>> Thanks Samir Srivastava https://samirsrivastava.typepad.com/ On 5/11/2020 at 2:59 AM, "Keith Drage" wrote: I dont know whether we reached something we can formally describe as a decision, but the overall opion was that it should be the text that should normatively describe what the requirements were for the actions in respect of inclusion in messages. If these tables were included, they should be clearly described as informative. SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format? Further, the normative text should be adequately worded to encompass the understanding what happened when new messages were invented - so rather than specifically listing messages, it should probably talk about messages that create a dialog, etc. SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 REFER RFC https://tools.ietf.org/html/rfc3515 MESSAGE RFC https://tools.ietf.org/html/rfc3428 They all were invented before RFC 4028.. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance? Keith On 10/05/2020 17:59, Paul Kyzivat wrote: > On 5/10/20 9:12 AM, Samir Srivastava wrote: >> Hi, >> >> The table mentioned in Section 4 in RFC 4028 does not contain >> entries for REFER, PUBLISH and MESSAGE methods Below is the table >> from Section 4 >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | >> - | >> | | | | | | | | | | | | | | >> |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | >> - | >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >> They are not applicable for these, but it would have been better >> if it is said categorically. > > IIRC, quite a long time ago it was decided that this table in 3261 was > a bad idea, because it is essentially a summary of normative language > in other sections of the document and is necessarily an approximation. > > After that, other work that updates and extends 3261 has been > inconsistent it whether it updates the table or not. > > What we should be careful of is that the in progress update to session > timers is clear, normatively and expositively, one way or another. > > 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 --=_4c2ccc5a2e512cf1a214fe5f84640441 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi = Christer,

  I am hoping that in the next version 40= 28bis, The Min-SE, Session-Expires header field will have consideration for= REFER, PUBLISH, MESSAGE methods, in tabular format or in text. Tabular for= mat or text will depend on the agreement on another thread discussion which= is started today.

Thanks
Samir Srivasta= va

On 5/11/2020 at 9:25 PM, "Christe= r Holmberg" <christer.holmberg=3D40ericsson.com@dmarc.ietf.org> wrote= :

Hi,

 

I suggest changing t= he subject of this thread, because it is not specific to session timers.

 

Regards,

 

Christer

 

From: = sipcore <sipcore-b= ounces@ietf.org> on behalf of Samir Srivastava <srivastava_samir=3D40= hush.com@dmarc.ietf.org>
Date: Monday, 11 May 2020 at 18.40
To: Keith Drage <drageke=3D40ntlworld.com@dmarc.ietf.org>, "si= pcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH,= MESSAGE not defined

 

Hi,

 

  Please find my replies Inline below prefi= xed with SS>>

 

Thanks


On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=3D40ntlworld.com@dmarc.i= etf.org> wrote:

I dont know whether we reached something we can = formally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabu= lated form. SIP Parser developers cannot be expected to know the minute det= ails of applicability of the messages and headers etc. SIP architect in the= vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser develope= rs. If we all agree in the tabulated form as SPEC Writers, it will be good = service to the community. What are the difficulties considered which made u= s to deprecate the table format?

Further, the normative text should be adequately worded to encompass the understanding what happened when new messages were invented - so rather than specifically listing messages, it should probably talk about
messages that create a dialog, etc.
SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
         REFER RFC https://tools.ietf.org/html/r= fc3515
          MESSAGE RFC https://tools.ietf.org/htm= l/rfc3428

  They all were invented before RFC 4028.. They were NOT developed= after Session Timers. So it is left because of mistake. 4028bis and RFC do= es not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOT= IFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-S= E, SEssion-Expires are found in these message should be reject the REQUEST = or accept the by following "be lenient what one accepts". Some guideline ne= eds to be specified. 
  Developer of new method need to look each header, message etc in the= ir respective RFC. What one can specify for method foo for header foobar in= advance? 




Keith


On 10/05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>> Hi,
>>
>>    The table mentioned in Section 4 in RFC 4028 does not= contain
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table =
>> from Section 4
>>
>>
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+-= --+
>>     |     Header |where|proxy|A= CK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+-= --+
>>     |Session-Expires|  R  | amr | - | - |= - | o | - | - | - | o | - |
>> - |
>>     |       &nbs= p;       |     | &nb= sp;   |   |   |   |   |&n= bsp;  |   |   | |   |   |
>>     |Session-Expires| 2xx | ar  | - | - | - | = o | - | - | - | o | - |
>> - |
>>     |       &nbs= p;       |     | &nb= sp;   |   |   |   |   |&n= bsp;  |   |   | |   |   |
>>     |Min-SE      &nbs= p;  |  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |       &nbs= p;       |     | &nb= sp;   |   |   |   |   |&n= bsp;  |   |   | |   |   |
>>     |Min-SE      &nbs= p;  | 422 |     | - | - | - | m | - | - | - | m | = - |
>> - |
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+-= --+
>>
>>    They are not applicable for these, but it would have = been better
>> if it is said categorically.
>
> IIRC, quite a long time ago it was decided that this table in 3261 was=
> a bad idea, because it is essentially a summary of normative language =
> in other sections of the document and is necessarily an approximation.=
>
> After that, other work that updates and extends 3261 has been
> inconsistent it whether it updates the table or not.
>
> What we should be careful of is that the in progress update to session=
> timers is clear, normatively and expositively,  one way or anothe= r.
>
>     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

 --=_4c2ccc5a2e512cf1a214fe5f84640441-- From nobody Tue May 12 09:51:00 2020 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 D81923A0659 for ; Tue, 12 May 2020 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 Zck-2bv96vil for ; Tue, 12 May 2020 09:50:57 -0700 (PDT) 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 EA10C3A05AA for ; Tue, 12 May 2020 09:50:56 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04CGoraK045774 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 12 May 2020 11:50:54 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589302254; bh=VxwVggAIAXWU5fTJ5XFUUBZfUrJlwUyXZAYQJWJiOW0=; h=Subject:To:References:From:Date:In-Reply-To; b=cD3T/l5A+9BiXMZ/eEYYWSafru5/Ljc0rUPG2gl/Xvkilok/m0Ros/trcm5tvdEGl 0N/DngiW2aU2/RgTkOIx4fy/myfFYzp8UUcvWSC4RexPYfWTds6GYsU8S7PZnyjDbU YaPJZlYTqeRZCeytLvGuyj5bgXWjuRBHlcKunWhc= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Samir Srivastava , Keith Drage , sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> From: Adam Roach Message-ID: <1169dae0-f8dc-506d-f242-d274b2f438b4@nostrum.com> Date: Tue, 12 May 2020 11:50:46 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200512105430.7F9542011C@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="------------8F7C058F2E72D3D5B61FFC4D" Content-Language: en-US Archived-At: Subject: Re: [sipcore] Deprecation of tabular format of header fields || Was Re: Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 16:50:59 -0000 This is a multi-part message in MIME format. --------------8F7C058F2E72D3D5B61FFC4D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The executive summary is that there was strong consensus not to attempt to maintain Tables 2 and 3 in RFC 3261, and many of the reasons for not doing so have become even stronger as the protocol has grown. If you're interested in the details, you can find the mailing list discussion by reading the messages from February through April 2010 here: https://mailarchive.ietf.org/arch/search/?q=%22table%202%22&f_list=sipcore There was substantial discussion of the topic at the in-person meeting in Anaheim; you can listen to the audio recordings here: http://www.softarmor.com/sipcore/IETF77/audio/table2-sipcore1.mp3 http://www.softarmor.com/sipcore/IETF77/audio/table2-sipcore2.mp3 ...and examine the slides here: https://www.ietf.org/proceedings/10mar/slides/sipcore-2.pdf /a On 5/12/2020 5:54 AM, Samir Srivastava wrote: > Hi Keith Drage, > >   The below does not answer reason for deprecating tabular format i.e. > what are things which cannot be captured in tabular format. > >  Thanks > Samir Srivastava > https://samirsrivastava.typepad.com/ > > On 5/11/2020 at 9:32 PM, "Keith Drage" > wrote: > > Most header fields are included for a specific purpose entirely > unassociated with what mesage it is in. > > i.e. things like > > -    included because this message creates a dialog > > -    included because this message ends a dialog > > -    included becases this message is the request in a transaction > > -    included because this message responds to a transaction > > -    included because I can include it in any request > > etc. > > Those concepts have existed since RFC 3261. > > The exceptions tend to be header fields that are defined along > with a MESSAGE to carry them, i.e. in the same RFC. > > I am not suggesting the definers of new messages should not give > due consideration, only that in most cases they will not need to > add any extra requirements to their new RFC, because all the > considerations could already be in the header field defining RFC. > > > Keith > > P.S. I would note that you cannot go on the date of publication - > many RFCs take years to get through publication request to > published while others proceed quicker. > > > > On 11/05/2020 16:39, Samir Srivastava wrote: > > Hi, > >   Please find my replies Inline below prefixed with SS>> > > Thanks > Samir Srivastava > https://samirsrivastava.typepad.com/ > > On 5/11/2020 at 2:59 AM, "Keith Drage" > wrote: > > I dont know whether we reached something we can formally > describe as a > decision, but the overall opion was that it should be the > text that > should normatively describe what the requirements were for > the actions > in respect of inclusion in messages. If these tables were > included, they > should be clearly described as informative. > SS>> I am of the opinion that we need header, message etc > in the tabulated form. SIP Parser developers cannot be > expected to know the minute details of applicability of > the messages and headers etc. SIP architect in the vendor > comapnies might be required to give the headers and > messages in the tabulated form to SIP Parser developers. > If we all agree in the tabulated form as SPEC Writers, it > will be good service to the community. What are the > difficulties considered which made us to deprecate the > table format? > > Further, the normative text should be adequately worded to > encompass the > understanding what happened when new messages were > invented - so rather > than specifically listing messages, it should probably > talk about > messages that create a dialog, etc. > SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 >          REFER RFC https://tools.ietf.org/html/rfc3515 >           MESSAGE RFC https://tools.ietf.org/html/rfc3428 > >   They all were invented before RFC 4028.. They were NOT > developed after Session Timers. So it is left because of > mistake. 4028bis and RFC does not mention PUBLISH, REFER, > MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, > CANCEL, REGISTER, OPTIONS are only defined in the table > nowhere in text. If the added headers (MIN-SE, > SEssion-Expires are found in these message should be > reject the REQUEST or accept the by following "be lenient > what one accepts". Some guideline needs to be specified. >   Developer of new method need to look each header, > message etc in their respective RFC. What one can specify > for method foo for header foobar in advance? > > > > > Keith > > > On 10/05/2020 17:59, Paul Kyzivat wrote: > > On 5/10/20 9:12 AM, Samir Srivastava wrote: > >> Hi, > >> > >>    The table mentioned in Section 4 in RFC 4028 does > not contain > >> entries for REFER, PUBLISH and MESSAGE methods Below is > the table > >> from Section 4 > >> > >> > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >>     |     Header > |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >>     |Session-Expires|  R  | amr | - | - | - | o | - | - > | - | o | - | > >> - | > >>     |               |     |     |   | |   |   |   |   > |   | |   |   | > >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - > | - | o | - | > >> - | > >>     |               |     |     |   | |   |   |   |   > |   | |   |   | > >>     |Min-SE         |  R  | amr | - | - | - | o | - | - > | - | o | - | > >> - | > >>     |               |     |     |   | |   |   |   |   > |   | |   |   | > >>     |Min-SE         | 422 |     | - | - | - | m | - | - > | - | m | - | > >> - | > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >> > >>    They are not applicable for these, but it would have > been better > >> if it is said categorically. > > > > IIRC, quite a long time ago it was decided that this > table in 3261 was > > a bad idea, because it is essentially a summary of > normative language > > in other sections of the document and is necessarily an > approximation. > > > > After that, other work that updates and extends 3261 has > been > > inconsistent it whether it updates the table or not. > > > > What we should be careful of is that the in progress > update to session > > timers is clear, normatively and expositively,  one way > or another. > > > >     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 > > > _______________________________________________ > 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 --------------8F7C058F2E72D3D5B61FFC4D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
The executive summary is that there was strong consensus not to attempt to maintain Tables 2 and 3 in RFC 3261, and many of the reasons for not doing so have become even stronger as the protocol has grown. If you're interested in the details, you can find the mailing list discussion by reading the messages from February through April 2010 here:

https://mailarchive.ietf.org/arch/search/?q=%22table%202%22&f_list=sipcore

There was substantial discussion of the topic at the in-person meeting in Anaheim; you can listen to the audio recordings here:

http://www.softarmor.com/sipcore/IETF77/audio/table2-sipcore1.mp3
http://www.softarmor.com/sipcore/IETF77/audio/table2-sipcore2.mp3

...and examine the slides here:

https://www.ietf.org/proceedings/10mar/slides/sipcore-2.pdf

/a

On 5/12/2020 5:54 AM, Samir Srivastava wrote:
Hi Keith Drage,

  The below does not answer reason for deprecating tabular format i.e. what are things which cannot be captured in tabular format.

 Thanks
Samir Srivastava

On 5/11/2020 at 9:32 PM, "Keith Drage" <drageke=40ntlworld.com@dmarc.ietf.org> wrote:

Most header fields are included for a specific purpose entirely unassociated with what mesage it is in.

i.e. things like

-    included because this message creates a dialog

-    included because this message ends a dialog

-    included becases this message is the request in a transaction

-    included because this message responds to a transaction

-    included because I can include it in any request

etc.

Those concepts have existed since RFC 3261.

The exceptions tend to be header fields that are defined along with a MESSAGE to carry them, i.e. in the same RFC.

I am not suggesting the definers of new messages should not give due consideration, only that in most cases they will not need to add any extra requirements to their new RFC, because all the considerations could already be in the header field defining RFC.


Keith

P.S. I would note that you cannot go on the date of publication - many RFCs take years to get through publication request to published while others proceed quicker.



On 11/05/2020 16:39, Samir Srivastava wrote:
Hi,

  Please find my replies Inline below prefixed with SS>>

Thanks

On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=40ntlworld.com@dmarc.ietf.org> wrote:
I dont know whether we reached something we can formally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they
should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format?

Further, the normative text should be adequately worded to encompass the
understanding what happened when new messages were invented - so rather
than specifically listing messages, it should probably talk about
messages that create a dialog, etc.
SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
         REFER RFC https://tools.ietf.org/html/rfc3515
          MESSAGE RFC https://tools.ietf.org/html/rfc3428

  They all were invented before RFC 4028.. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. 
  Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance? 




Keith


On 10/05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>> Hi,
>>
>>    The table mentioned in Section 4 in RFC 4028 does not contain
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table
>> from Section 4
>>
>>
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>     |     Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - |
>> - |
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>
>>    They are not applicable for these, but it would have been better
>> if it is said categorically.
>
> IIRC, quite a long time ago it was decided that this table in 3261 was
> a bad idea, because it is essentially a summary of normative language
> in other sections of the document and is necessarily an approximation.
>
> After that, other work that updates and extends 3261 has been
> inconsistent it whether it updates the table or not.
>
> What we should be careful of is that the in progress update to session
> timers is clear, normatively and expositively,  one way or another.
>
>     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
 
_______________________________________________
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


--------------8F7C058F2E72D3D5B61FFC4D-- From nobody Tue May 12 14:31:09 2020 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 C27EB3A0C09 for ; Tue, 12 May 2020 14:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 632xLht1myt4 for ; Tue, 12 May 2020 14:31:04 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::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 E05223A0BF2 for ; Tue, 12 May 2020 14:31:03 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id v128so2764210oia.7 for ; Tue, 12 May 2020 14:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cy2eu4JPPrDhPu4I+Hqo2xtEDkub6tjOEo87zi8ooUw=; b=JjrDSIvds47ZO1c4pzFh4TVOzZY73QOXhHoDvv1RzoARhYQ0Drpo3g+C61m8cTcaii ekQEtT6MLP03obmbNoMc9DjqxPMLYZp6C4ZWfGi8ijH0uzT542PCSPFdD5KAG+ll2vLO hopoe94jHiEmHT6/gKlHv4b38oRbvP+nMY/0qmQd+QZzOz0JigAwvUkGWIMbB27F1X6B TUkI/mQAP7Z0fZJ66wgRMuD2CHUkmcsKygReNVkoFJWRg6qXFLQnztaLmSR7MJtZnAWD KRKwHLzQ2Ldh6FRUEdEuYYBhuc5oV17yieT3+2sau+0tgLJ3hL06KMaR7aqPdk8TujXx pOYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cy2eu4JPPrDhPu4I+Hqo2xtEDkub6tjOEo87zi8ooUw=; b=qJnClz1nPa2QdOktOszyMhH9abkoYNC5egcrJceycgKNvNjAVyp/pr9p3meTRGRZC7 Zt4jiKS2SNuhEo6k8TrnKfGKc8Lw91lvNCpPY9zEF9qU114RboxERr6IPL2ZwxyH0X/Z wW5ms/KSJrgROxFwz7t7qv45zyF8pWEX//ZiltKzeWgZb3L1DrUq8+CvhVLJoIyCKfi0 Q0avJsXnVfviBc/z4TMosfw2+qG0Lf/df/fDSamcIA/gEM6VmOZIi4SZkxDA+22jCSer 2xNPcVawL2tDXtEapLU2MtrC/UtAdo8zGu3WeMBBVrWYtSnHPRO/qghxe+XCL3YzwN5/ KFeQ== X-Gm-Message-State: AGi0PuZATKeUIXf74B8MtLqasfJqQgc2T/xLCvJbFEgpWBBCSHF4Z8YP taWAl9kymBhZHqS3e4Q6z5/FojUD+XY= X-Google-Smtp-Source: APiQypINKb809qzrb1LD++WFjVPSFKJ6ssYsoJ/LgyjWhqdu+eIDHy0k2EKmvd+b/ROOW8LScR23JA== X-Received: by 2002:aca:4b90:: with SMTP id y138mr23921482oia.74.1589319062640; Tue, 12 May 2020 14:31:02 -0700 (PDT) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com. [209.85.210.46]) by smtp.gmail.com with ESMTPSA id h6sm3965600oov.10.2020.05.12.14.31.01 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 14:31:01 -0700 (PDT) Received: by mail-ot1-f46.google.com with SMTP id v17so3820557ote.0 for ; Tue, 12 May 2020 14:31:01 -0700 (PDT) X-Received: by 2002:a9d:194:: with SMTP id e20mr17487952ote.13.1589319061221; Tue, 12 May 2020 14:31:01 -0700 (PDT) MIME-Version: 1.0 References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> In-Reply-To: <20200512110600.9497C2011C@smtp.hushmail.com> From: Roman Shpount Date: Tue, 12 May 2020 17:30:49 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Samir Srivastava Cc: Christer Holmberg , Keith Drage , SIPCORE Content-Type: multipart/alternative; boundary="00000000000014360a05a57a2e90" Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:31:07 -0000 --00000000000014360a05a57a2e90 Content-Type: text/plain; charset="UTF-8" Samir, Most likely Min-SE and Session-Expires headers in REFER, PUBLISH, MESSAGE would be out of scope for 4028bis. So far there was an agreement to limit the scope of 4028bis to fixing handling of multiple transactions which modify Session-Expiration at the same time and associated race conditions. Any other changes would need to go into another RFC. P.S. Why would you put Min-SE and Session-Expires into REFER, PUBLISH, MESSAGE? These header fields are only defined for INVITE/UPDATE messages and not applicable for any other messages. _____________ Roman Shpount On Tue, May 12, 2020 at 7:06 AM Samir Srivastava wrote: > Hi Christer, > > I am hoping that in the next version 4028bis, The Min-SE, > Session-Expires header field will have consideration for REFER, PUBLISH, > MESSAGE methods, in tabular format or in text. Tabular format or text will > depend on the agreement on another thread discussion which is started today. > > Thanks > Samir Srivastava > https://samirsrivastava.typepad.com/ > > On 5/11/2020 at 9:25 PM, "Christer Holmberg" 40ericsson.com@dmarc.ietf.org> wrote: > > Hi, > > > > I suggest changing the subject of this thread, because it is not specific > to session timers. > > > > Regards, > > > > Christer > > > > *From: *sipcore on behalf of Samir Srivastava > > *Date: *Monday, 11 May 2020 at 18.40 > *To: *Keith Drage , " > sipcore@ietf.org" > *Subject: *Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, > MESSAGE not defined > > > > Hi, > > > > Please find my replies Inline below prefixed with SS>> > > > > Thanks > > Samir Srivastava > https://samirsrivastava.typepad.com/ > > > On 5/11/2020 at 2:59 AM, "Keith Drage" 40ntlworld.com@dmarc.ietf.org> wrote: > > I dont know whether we reached something we can formally describe as a > decision, but the overall opion was that it should be the text that > should normatively describe what the requirements were for the actions > in respect of inclusion in messages. If these tables were included, they > should be clearly described as informative. > SS>> I am of the opinion that we need header, message etc in the tabulated > form. SIP Parser developers cannot be expected to know the minute details > of applicability of the messages and headers etc. SIP architect in the > vendor comapnies might be required to give the headers and messages in the > tabulated form to SIP Parser developers. If we all agree in the tabulated > form as SPEC Writers, it will be good service to the community. What are > the difficulties considered which made us to deprecate the table format? > > Further, the normative text should be adequately worded to encompass the > understanding what happened when new messages were invented - so rather > than specifically listing messages, it should probably talk about > messages that create a dialog, etc. > SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 > REFER RFC > https://tools.ietf.org/html/rfc3515 > MESSAGE RFC https://tools.ietf.org/html/rfc3428 > > They all were invented before RFC 4028.. They were NOT developed after > Session Timers. So it is left because of mistake. 4028bis and RFC does not > mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, > PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in > text. If the added headers (MIN-SE, SEssion-Expires are found in these > message should be reject the REQUEST or accept the by following "be lenient > what one accepts". Some guideline needs to be specified. > Developer of new method need to look each header, message etc in their > respective RFC. What one can specify for method foo for header foobar in > advance? > > > > > Keith > > > On 10/05/2020 17:59, Paul Kyzivat wrote: > > On 5/10/20 9:12 AM, Samir Srivastava wrote: > >> Hi, > >> > >> The table mentioned in Section 4 in RFC 4028 does not contain > >> entries for REFER, PUBLISH and MESSAGE methods Below is the table > >> from Section 4 > >> > >> > >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >> | Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| > >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >> |Session-Expires| R | amr | - | - | - | o | - | - | - | o | - | > >> - | > >> | | | | | | | | | | | | | | > >> |Session-Expires| 2xx | ar | - | - | - | o | - | - | - | o | - | > >> - | > >> | | | | | | | | | | | | | | > >> |Min-SE | R | amr | - | - | - | o | - | - | - | o | - | > >> - | > >> | | | | | | | | | | | | | | > >> |Min-SE | 422 | | - | - | - | m | - | - | - | m | - | > >> - | > >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >> > >> They are not applicable for these, but it would have been better > >> if it is said categorically. > > > > IIRC, quite a long time ago it was decided that this table in 3261 was > > a bad idea, because it is essentially a summary of normative language > > in other sections of the document and is necessarily an approximation. > > > > After that, other work that updates and extends 3261 has been > > inconsistent it whether it updates the table or not. > > > > What we should be careful of is that the in progress update to session > > timers is clear, normatively and expositively, one way or another. > > > > 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 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00000000000014360a05a57a2e90 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Samir,

Most likely Min-SE and Session-E= xpires headers in =C2=A0REFER, PUBLISH, MESSAGE would be out of scope for 4= 028bis. So far there was an agreement to limit the scope of=C2=A04028bis to= fixing handling of multiple transactions which modify Session-Expiration a= t the same time and associated race conditions.

An= y other changes would need to go into another RFC.

P.S. Why would you put=C2=A0 Min-SE and Session-Expires into REFER, PUBLISH, MESSAGE? These header fiel= ds are only defined for INVITE/UPDATE messages and not applicable for any o= ther messages.
_____________
Roman Shpount


On Tue, May 12, 2020 at 7:06 AM Samir Srivastava <sriva= stava_samir=3D40hush.com@dmarc= .ietf.org> wrote:
Hi Christer,

=C2=A0 I am hoping that in the next versi= on 4028bis, The Min-SE, Session-Expires header field will have consideratio= n for REFER, PUBLISH, MESSAGE methods, in tabular format or in text. Tabula= r format or text will depend on the agreement on another thread discussion = which is started today.

Thanks
Samir Sri= vastava

On 5/11/= 2020 at 9:25 PM, "Christer Holmberg" <christer.holmberg=3D40ericsson.c= om@dmarc.ietf.org> wrote:

Hi,

=C2=A0

I suggest changing the subject = of this thread, because it is not specific to session timers.

=C2=A0

Regards,

=C2=A0

Christer

=C2=A0

F= rom: sipcore <= ;sipcore-boun= ces@ietf.org> on behalf of Samir Srivastava <srivastava_samir=3D<= a href=3D"mailto:40hush.com@dmarc.ietf.org" target=3D"_blank">40hush.com@dm= arc.ietf.org>
Date: Monday, 11 May 2020 at 18.40
To: Keith Drage <drageke=3D40ntlworld.com@dmarc.ietf.org>, "<= a href=3D"mailto:sipcore@ietf.org" target=3D"_blank">sipcore@ietf.org&q= uot; <sipcore@ietf= .org>
Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH,= MESSAGE not defined

=C2=A0

Hi,

=C2=A0

=C2=A0 Please find my replies Inline below prefixe= d with SS>>

=C2=A0

Thanks


On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=3D40ntlworld.com@dmarc= .ietf.org> wrote:

I dont know whether we reached something we can fo= rmally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabu= lated form. SIP Parser developers cannot be expected to know the minute det= ails of applicability of the messages and headers etc. SIP architect in the= vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser develope= rs. If we all agree in the tabulated form as SPEC Writers, it will be good = service to the community. What are the difficulties considered which made u= s to deprecate the table format?

Further, the normative text should be adequately worded to encompass the understanding what happened when new messages were invented - so rather than specifically listing messages, it should probably talk about
messages that create a dialog, etc.
SS>> PUBLISH RFC=C2=A0https://tools.ietf.org/html/rfc3903
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0REFER RFC=C2=A0https://tools.ietf.org/html/rfc= 3515
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MESSAGE RFC=C2=A0https://tools.ietf.org/html/= rfc3428

=C2=A0 They all were invented before RFC 4028.. They were NOT developed= after Session Timers. So it is left because of mistake. 4028bis and RFC do= es not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOT= IFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-S= E, SEssion-Expires are found in these message should be reject the REQUEST = or accept the by following "be lenient what one accepts". Some gu= ideline needs to be specified.=C2=A0
=C2=A0 Developer of new method need to look each header, message etc in the= ir respective RFC. What one can specify for method foo for header foobar in= advance?=C2=A0




Keith


On 10/05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>> Hi,
>>
>> =C2=A0=C2=A0 The table mentioned in Section 4 in RFC 4028 does not= contain
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table =
>> from Section 4
>>
>>
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+-= --+
>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 Header |where|proxy|A= CK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+-= --+
>> =C2=A0=C2=A0=C2=A0 |Session-Expires|=C2=A0 R=C2=A0 | amr | - | - |= - | o | - | - | - | o | - |
>> - |
>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 = |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 | |=C2=A0=C2=A0 |=C2=A0=C2=A0 | >> =C2=A0=C2=A0=C2=A0 |Session-Expires| 2xx | ar=C2=A0 | - | - | - | = o | - | - | - | o | - |
>> - |
>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 = |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 | |=C2=A0=C2=A0 |=C2=A0=C2=A0 | >> =C2=A0=C2=A0=C2=A0 |Min-SE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |=C2=A0 R=C2=A0 | amr | - | - | - | o | - | - | - | o | - |
>> - |
>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 = |=C2=A0=C2=A0 |=C2=A0=C2=A0 |=C2=A0=C2=A0 | |=C2=A0=C2=A0 |=C2=A0=C2=A0 | >> =C2=A0=C2=A0=C2=A0 |Min-SE=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | 422 |=C2=A0=C2=A0=C2=A0=C2=A0 | - | - | - | m | - | - | - | m |= - |
>> - |
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+-= --+
>>
>> =C2=A0=C2=A0 They are not applicable for these, but it would have = been better
>> if it is said categorically.
>
> IIRC, quite a long time ago it was decided that this table in 3261 was=
> a bad idea, because it is essentially a summary of normative language =
> in other sections of the document and is necessarily an approximation.=
>
> After that, other work that updates and extends 3261 has been
> inconsistent it whether it updates the table or not.
>
> What we should be careful of is that the in progress update to session=
> timers is clear, normatively and expositively,=C2=A0 one way or anothe= r.
>
> =C2=A0=C2=A0=C2=A0=C2=A0Thanks,
> =C2=A0=C2=A0=C2=A0=C2=A0Paul
>
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org=
> https://www.ietf.org/mailman/listinfo/sipcore

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

___________________________________________= ____
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--00000000000014360a05a57a2e90-- From nobody Tue May 12 14:45:54 2020 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 801883A0C1E for ; Tue, 12 May 2020 14:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.991 X-Spam-Level: X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 mZkjM0q4ArbE for ; Tue, 12 May 2020 14:45:50 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2081.outbound.protection.outlook.com [40.107.223.81]) (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 453853A0C1B for ; Tue, 12 May 2020 14:45:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hToYUYmOAQDkt09+nTEbIvLZa62bcX8NIAvWy5SRonJelDluICswxktRwfiSeH8KFFTbrvDMb6ctjifbLfhzkmeA59iCJJKjH9sVRhzaOJ9q/iRMkdjMKq/Wo6NomrLb7hJ+YYxwAzRlI47yzAa+qWYlGtOi3WyvXFLecOf7bJ6tBkljCGLelUwBfGCWJiR17tbowIFs98dae+bA2YZ9K+Cf18mTxLlcrapbT8kg6hdPrx0d1b0WwFpNjI07TQ5I7g2SsihdA4OZ2LLkmA0/NYWABABVEIrzlb1bHTPpXDd4I4ujKlRHZyldh/zNn5joJE7RBoGC4QcEXg9XqWEIUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JoRYyrCCyBDNBEK85zL8qPBkkBxdPMq6Be99f8Cumj8=; b=EabfTsimuXUr9pMmDW1s3vYQZ8F00wIFHhbSUc6kTnJdcJh9tMJdVcjbxfvoEVJpLo8ck7sPXsCh4qDkLG5TXM3lig2gFp7k2zV3FhY9Tqusb2+eQFNDYxrOBGvfEzVcKwplYcmHDxdgdNLMepysl+eKPepUutZyVpFNR68ug5+tgJYbyGljLRQlySbD9sRC0c4/H78A9Iy0DfYIkXi6FkQvMrInsVbryX/jyaXhm6RYMk067e03HXYXsSRVoPmSAs5XWSVaFQOb8BQcls/6PfUACl9nLxiRarF7vBXS/pYXjxCpXs/XergoYhP2pKETMrXSx0Bx+GiodCF7V25qiA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=telurix.com smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JoRYyrCCyBDNBEK85zL8qPBkkBxdPMq6Be99f8Cumj8=; b=OfL+i3nucGROglqTwk5FD6vjR+M10YL74LRMMEYU+LlOHcl/i4yb0Vi0BhG01H2GZWB7AhmhOXKj83k3I3s0JSRfuehdb5ErbXCqnYeUy5x1LkaUkHot/t2YD2Aj+MB+wawY7FHDHBYSuqshl5nwRFbxdA+2F8b/V8jln7NlyIE= Received: from SN4PR0201CA0013.namprd02.prod.outlook.com (2603:10b6:803:2b::23) by CH2PR12MB4085.namprd12.prod.outlook.com (2603:10b6:610:79::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29; Tue, 12 May 2020 21:45:48 +0000 Received: from SN1NAM02FT057.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2b:cafe::c1) by SN4PR0201CA0013.outlook.office365.com (2603:10b6:803:2b::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20 via Frontend Transport; Tue, 12 May 2020 21:45:48 +0000 Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT057.mail.protection.outlook.com (10.152.73.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Tue, 12 May 2020 21:45:48 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 04CLjj2J032421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 12 May 2020 17:45:46 -0400 To: Roman Shpount , Samir Srivastava Cc: SIPCORE , Christer Holmberg References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> From: Paul Kyzivat Message-ID: <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> Date: Tue, 12 May 2020 17:45:45 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(376002)(346002)(396003)(136003)(39860400002)(46966005)(33430700001)(2906002)(478600001)(786003)(54906003)(70206006)(26005)(82740400003)(186003)(70586007)(86362001)(31696002)(336012)(110136005)(82310400002)(2616005)(8676002)(36906005)(316002)(7596003)(47076004)(53546011)(4744005)(33440700001)(956004)(31686004)(8936002)(75432002)(4326008)(356005)(15650500001)(5660300002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1b1b9f2b-f59f-43d2-0363-08d7f6bdd533 X-MS-TrafficTypeDiagnostic: CH2PR12MB4085: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-Forefront-PRVS: 0401647B7F X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YtLLEZb3Z8RP2NmR78UkB3lvdQDipc7oMCRIxSUt2ZUTZh4QZ3Xm0O76j8u2NoFBJTP0T7rLZpDTXEfpjHmfhcjFUj11oMB2gHVCSE2kd4KSpuGtNWcnSiuzjpjkbQqTaCcNM64g2fWYRp1toWHfxBBp282fyvrvbC5mFD8q2XXhaAyi5aK/B9RzJcPMWKoANLIpPdCZEIj6hsJCMmf0axJuzAQ2Jt0IImFo5AmNcaUauM35xNJ7GPm8HGc5utb8dxYJZQ8yS2OVpdTc0FF56zlRDaRBLfOXyYIraNsohnKahv0j419P7m3R1GcStrRVfx2lxDXhwxrWXwlVJQaREcYYQ/dxBh7GQllTRSl9EiH1l7RzawaZbgnPTjwHuzD4xDX3XoRo7Oc8+2cXuFC3od+OlprnZTbedG0IjVwu5YDlqAmqNqlnpmxJg3RYuH7JvCQ8j472NgaR6W/lugPOLmfR17AZ6UYDADU/2Cpip48AKO1Y5wauEHHJuFdaS9AJI9Q0KJbREWa+h/8liECfIsBnk/qpcTbrwcp3w+C7fq/XNSYkj0BZQfA58rQMYClneD+cOeYXqNlFx5icEAmzYZr/Y0SNv6IzPfKzdQsGaos= X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2020 21:45:48.0517 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1b1b9f2b-f59f-43d2-0363-08d7f6bdd533 X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4085 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:45:52 -0000 On 5/12/20 5:30 PM, Roman Shpount wrote: > Samir, > > Most likely Min-SE and Session-Expires headers in  REFER, PUBLISH, > MESSAGE would be out of scope for 4028bis. So far there was an agreement > to limit the scope of 4028bis to fixing handling of multiple > transactions which modify Session-Expiration at the same time and > associated race conditions. > > Any other changes would need to go into another RFC. > > P.S. Why would you put Min-SE and Session-Expires into REFER, PUBLISH, > MESSAGE? These header fields are only defined for INVITE/UPDATE messages > and not applicable for any other messages. Putting them in *these* messages would be nonsensical because they are neither dialog establishing nor dialog refreshing. OTOH, it would make perfect sense to use them in SUBSCRIBE/NOTIFY because they *are*. Session Timer is about maintaining the dialog. I would think it would be equally applicable to these kinds of dialog usages. But that is probably deserving of discussion. Thanks, Paul From nobody Tue May 12 14:57:28 2020 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 2C5BF3A0C74 for ; Tue, 12 May 2020 14:57:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 rJPdsKXLo2vS for ; Tue, 12 May 2020 14:57:24 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::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 053953A0C2B for ; Tue, 12 May 2020 14:57:23 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id c12so18647260oic.1 for ; Tue, 12 May 2020 14:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bYA6pcbsxUI8zEd1hE41RePpPGrP2SNUjhIFeOeUzdQ=; b=VK5KqH6aohS52bKGwWoqZ6xKfPE/M8wK/IFjMph+TEbqp5DpIa/K+pXovqvlndRea6 ghfqkzLzHI99u1cJp40ATuVzfgRZlu0zzkaGuUG0u2Gm90Qvg8igwSFdQoSm3E240dbA vrFtu13k/OPHofiysgQw3s3pudhJaEwuf9yHvoDVgVIeMHIMI5E9JAm7ig4S0ngiE4/W aG2hgLu1XMcjH0qTrOfYg4LyjC+fwG4sPhHbzEiEQ0j6I4K7a22iUtSW+RsCa75a2he7 Mbht+U1PEB0ml2ZtGyJ45Vp7gVpipz/XEv+z/9k/DB5JeSPDLBWv9bUD9rGTrK9vvGjN 6d2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bYA6pcbsxUI8zEd1hE41RePpPGrP2SNUjhIFeOeUzdQ=; b=l+bT1i13v/55eQgliF2eUnYTyrl7Lo0horBUbk6pX5ezKGL63oSwzCW/NyFVLgIXEc j92yzdeEOefpA9LRNikyy8Sol2NcEzIsq1aS8E6zU9d/VA7g7ytsXCIrfdbaYU8FFGe3 nICbgw7pgvpDawHebMuNu/g0FhNLvbS7Eb+etR4SRC47/bKTNSypr8HbHgOF0TGxzYJC DW9SDOH/bkQN5PVZLur/dj0KNBhgGTwZqcO/pFAcivTQTpPbVH07eNFfr7Cyp6TB1Enp rhE46Ky1wSy4uzWe/j5EH84Vxxmof5LpofALwE6g67+enP6ErTnj/5CAUeYn/3u5su/q EBcQ== X-Gm-Message-State: AGi0PubcPcnC0OOm+4xUsTaYtJprSUS1Plx148csVHtWySLebkbgNs0O sywgguU1NLZykFwRIDfbDmbWJq0XMXA= X-Google-Smtp-Source: APiQypJcm4qkRb+FPNMe3kaJ8zwrg/2alYpEyXKxyJ/XHpUv52/jgag79pNQB/DdQuH+2SWi8Dj30w== X-Received: by 2002:aca:2801:: with SMTP id 1mr23780886oix.141.1589320642945; Tue, 12 May 2020 14:57:22 -0700 (PDT) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com. [209.85.210.41]) by smtp.gmail.com with ESMTPSA id h7sm1573674ool.35.2020.05.12.14.57.21 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 14:57:22 -0700 (PDT) Received: by mail-ot1-f41.google.com with SMTP id t3so11817841otp.3 for ; Tue, 12 May 2020 14:57:21 -0700 (PDT) X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr18453270otq.39.1589320641415; Tue, 12 May 2020 14:57:21 -0700 (PDT) MIME-Version: 1.0 References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> In-Reply-To: <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> From: Roman Shpount Date: Tue, 12 May 2020 17:57:10 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Paul Kyzivat Cc: Samir Srivastava , SIPCORE , Christer Holmberg Content-Type: multipart/alternative; boundary="00000000000044104c05a57a8ce7" Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 May 2020 21:57:26 -0000 --00000000000044104c05a57a8ce7 Content-Type: text/plain; charset="UTF-8" On Tue, May 12, 2020 at 5:45 PM Paul Kyzivat wrote: > OTOH, it would make perfect sense to use them in SUBSCRIBE/NOTIFY because > they *are*. > Session Timer is about maintaining the dialog. I would think it would be > equally applicable to these kinds of dialog usages. But that is probably > deserving of discussion. > > SUBSCRIBE/NOTIFY messages have a mandatory built-in dialog expiration support (Expires/Min-Expires headers), so Session Timer in these message would be redundant. I've never seen anybody using Session Timers with SIP Events, but as you have said this can be discussed. Best Regards, _____________ Roman Shpount --00000000000044104c05a57a8ce7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, May 12, 2020 at 5:45 PM Paul Kyzi= vat <pkyzivat@alum.mit.edu&= gt; wrote:
OTOH, it would make perfect sense to use them in SUBS= CRIBE/NOTIFY because they *are*.
Session Timer is about maintaining the dialog. I would think it would be equally applicable to these kinds of dialog usages. But that is probably deserving of discussion.


SUBSCRIBE/= NOTIFY messages have a mandatory built-in dialog expiration support (Expire= s/Min-Expires headers), so Session Timer in these message would be redundan= t. I've never seen anybody using Session Timers with SIP Events, but as= you have said this can be discussed.

Best Regards= ,
___= __________
Roman Shpount

=C2=A0
--00000000000044104c05a57a8ce7-- From nobody Tue May 12 22:43:11 2020 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 DAEF23A0DB4 for ; Tue, 12 May 2020 22:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 raMGBVQAa1wH for ; Tue, 12 May 2020 22:43:08 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) (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 527DB3A0D3B for ; Tue, 12 May 2020 22:43:08 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id 9ECF3C0303 for ; Wed, 13 May 2020 05:43:07 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=KBu2ZiGJGwPN7p6NK9DFQMVucmA+25Yorm0/okGPTqI=; b=J82bhDq9xpk/DIrkQmlT8pjYj0ySj1LEuJSaDDH3i1BCf2c/80RMMxlPxXbYxdkpe1lOY7MX7LtOvEno1HVLxWbdWPw5ivTUMgLijZifnHITmkIzYFrhZVRCVP3It/UI6KcnAqRVEUR53D4a5sL++EqFFpmyf7rX9Klohprj4IsKWwbzSL5X4OTk536GjtxDgXrjBm92e7sqkr1A1KWlIf1plfB1u0iXpMOVs2JYHYF0p0SvSTqVcxV1sKK9+oWXOiTz+FGgQ9JFHkpJY5XhBlJAO+uA6OdA5M74rhm9kgWqfFj4rLjclJ59SOwYoFEx1tMjCIK+nA8N9SYUJiw/Mg== Received: from smtp.hushmail.com (w3.hushmail.com [65.39.178.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Wed, 13 May 2020 05:43:06 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 8A2EEC06FF; Wed, 13 May 2020 05:43:06 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 13 May 2020 11:43:06 +0600 To: "Paul Kyzivat" , "Roman Shpount" Cc: "SIPCORE" , "Christer Holmberg" From: "Samir Srivastava" In-Reply-To: <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> Content-Type: multipart/alternative; boundary="=_af9eaccc8a5654e33fbd201741d4ca60" Message-Id: <20200513054306.8A2EEC06FF@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 05:43:10 -0000 --=_af9eaccc8a5654e33fbd201741d4ca60 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" In-line prefixed with SS>> ThanksSamir Srivastavahttp://samirsrivastava.typepad.com On 5/13/2020 at 3:15 AM, "Paul Kyzivat" wrote:On 5/12/20 5:30 PM, Roman Shpount wrote: > Samir, > > Most likely Min-SE and Session-Expires headers in REFER, PUBLISH, > MESSAGE would be out of scope for 4028bis. So far there was an agreement > to limit the scope of 4028bis to fixing handling of multiple > transactions which modify Session-Expiration at the same time and > associated race conditions. > > Any other changes would need to go into another RFC. > > P.S. Why would you put Min-SE and Session-Expires into REFER, PUBLISH, > MESSAGE? These header fields are only defined for INVITE/UPDATE messages > and not applicable for any other messages. Putting them in *these* messages would be nonsensical because they are neither dialog establishing nor dialog refreshing. OTOH, it would make perfect sense to use them in SUBSCRIBE/NOTIFY because they *are*. Session Timer is about maintaining the dialog. I would think it would be equally applicable to these kinds of dialog usages. But that is probably deserving of discussion. SS>> There are other messages in the table for which these headers are not applicable. On the same line mention these headers are not applicable for REFER, PUBLISH, MESSAGE methods. Messages apart from (re)Inv and UPD are only mentioned in the table in 4028bis and RFC 4028. 4028bis mentions in the table that these headers are not applicable for SUBSCRIBE / NOTIFY also. Thanks, Paul --=_af9eaccc8a5654e33fbd201741d4ca60 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" In-= line prefixed with SS>>

Thanks
Samir Sri= vastava
http://sam= irsrivastava.typepad.com


On 5/13/2020 at 3:15 AM, "Paul Kyzi= vat" <pkyzivat@alum.mit.edu> wrote:
On 5/12/20 5:30 PM, Roma= n Shpount wrote:
> Samir,
>
> Most likely Min-SE and Ses= sion-Expires headers in  REFER, PUBLISH,
> MESSAGE would be out= of scope for 4028bis. So far there was an agreement
> to limit the = scope of 4028bis to fixing handling of multiple
> transactions = which modify Session-Expiration at the same time and
> associated ra= ce conditions.
>
> Any other changes would need to go into ano= ther RFC.
>
> P.S. Why would you put Min-SE and Session-Expire= s into REFER, PUBLISH,
> MESSAGE? These header fields are only defin= ed for INVITE/UPDATE messages
> and not applicable for any other mes= sages.

Putting them in *these* messages would be nonsensical because= they are
neither dialog establishing nor dialog refreshing. OTOH, it w= ould make
perfect sense to use them in SUBSCRIBE/NOTIFY because they *a= re*.
Session Timer is about maintaining the dialog. I would think it wo= uld be
equally applicable to these kinds of dialog usages. But that is = probably
deserving of discussion.

SS>>  There are oth= er messages in the table for which these headers are not applicable. On the= same line mention these headers are not applicable for REFER, PUBLISH, MES= SAGE methods. Messages apart from (re)Inv and UPD are only mentioned in the= table in 4028bis and RFC 4028. 4028bis mentions in the table that these he= aders are not applicable for SUBSCRIBE / NOTIFY also.  

T= hanks,
Paul
 --=_af9eaccc8a5654e33fbd201741d4ca60-- From nobody Tue May 12 22:53:50 2020 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 2AC353A0C94 for ; Tue, 12 May 2020 22:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 ydOokuqTvO9R for ; Tue, 12 May 2020 22:53:46 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 A64CD3A0AC9 for ; Tue, 12 May 2020 22:53:46 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id a68so4023794otb.10 for ; Tue, 12 May 2020 22:53:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VELs/QdOroUADiJk/uzMybX+F7G5+JzWeRxFjmmXW70=; b=ldj+w+5xEsbabzgJ4UTwYBdidFrPTZztaKwBSvof8VeoMtDyHF0syKUvyvuA21IK2P yqELt9G0+qNxC3NlaFIFRzGKUazLtvi9fFt70xh0Uvrc05mRT/Kzw2oVlhy7LuK3wPqS aCj4oH/y+ENLwnR29LpxyVO5oMCA3fVLLQUpSmTJUYF0RUUNzglFIGNZm5V3CqE+kP2T NvdbUWj7eJa7T4Lv3zmEK7p36oIMOiPKYq5tuQUu2E+HN5m9l9kPMrlK8JB/8ByNAPp+ As1T3wYD0qddMHyYcpIWxkhs/cgNrC2Xb/Fdxrb/U4RwyLapJHmhM+hZlQyWWqiJxIcI CzFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VELs/QdOroUADiJk/uzMybX+F7G5+JzWeRxFjmmXW70=; b=twG3R5VxpDyZ0PAVJlZ2HcLUd7IlL07r6rRwaGo/ctdjDXuy9mzSRgdM2XZx2BzJwd BoVea/S8FQv4poEbWK+xsYmewA6ezCE+eejBZgEbv05dWsWxmheZcCoB6SS6v5jHTs95 cyZel4+F7Q9VsYiF+x8OG5VhGIxfrbPbnucwjNXYIDdXPnWRJC9b0St5voPbN0QmZCCU yeIffMIA2Awwbs0tFZRBhT8kDHx9xc/IyQb28izeeRJyzBccyJJ26L1ZrOg5D7FQqaWp 64MeptmumFAkBQ4egIawiYlrJe8lJaC4t1CZ7yfEABsDTDrGeXZ5VyGEQK52LBA/UNgp lhPw== X-Gm-Message-State: AGi0Pub96NhC7SsiMod9+8kWsH3HfOzJxMTMnRv8vZtgYua/tuXsXS8T hgxYjJMVpiH99/UcaryBeGtq3MuBWRA= X-Google-Smtp-Source: APiQypJUaWHBYe1TqcpuYTASf86b8sJGwT4FP6RHxmJ/t9Whl21v0ugvaqui0bc3JdaBontBJsMFTA== X-Received: by 2002:a9d:7dc7:: with SMTP id k7mr3532384otn.50.1589349225427; Tue, 12 May 2020 22:53:45 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com. [209.85.167.182]) by smtp.gmail.com with ESMTPSA id c191sm6266oib.23.2020.05.12.22.53.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 May 2020 22:53:44 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id c12so19450256oic.1 for ; Tue, 12 May 2020 22:53:44 -0700 (PDT) X-Received: by 2002:aca:eb88:: with SMTP id j130mr26131655oih.12.1589349223829; Tue, 12 May 2020 22:53:43 -0700 (PDT) MIME-Version: 1.0 References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> <20200513054306.8A2EEC06FF@smtp.hushmail.com> In-Reply-To: <20200513054306.8A2EEC06FF@smtp.hushmail.com> From: Roman Shpount Date: Wed, 13 May 2020 01:53:32 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Samir Srivastava Cc: Paul Kyzivat , SIPCORE , Christer Holmberg Content-Type: multipart/alternative; boundary="000000000000e917f005a5813350" Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 05:53:49 -0000 --000000000000e917f005a5813350 Content-Type: text/plain; charset="UTF-8" On Wed, May 13, 2020 at 1:43 AM Samir Srivastava wrote: > There are other messages in the table for which these headers are not > applicable. On the same line mention these headers are not applicable for > REFER, PUBLISH, MESSAGE methods. Messages apart from (re)Inv and UPD are > only mentioned in the table in 4028bis and RFC 4028. 4028bis mentions in > the table that these headers are not applicable for SUBSCRIBE / NOTIFY > also. Samir, Since this change is purely editorial, serves no real purpose, and does not address any real implementation issues, it is out of scope for the 4028bis. There is a good argument to be made, that that entire table should be removed to avoid any future queries like this in the future, but since this is editorial as well, it is likely out of scope too. Best Regards, _____________ Roman Shpount --000000000000e917f005a5813350 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, May 13, 2020 at 1:43 AM Samir Sri= vastava <srivastava_samir@h= ush.com> wrote:
There are other = messages in the table for which these headers are not applicable. On the sa= me line mention these headers are not applicable for REFER, PUBLISH, MESSAG= E methods. Messages apart from (re)Inv and UPD are only mentioned in the ta= ble in 4028bis and RFC 4028. 4028bis mentions in the table that these heade= rs are not applicable for SUBSCRIBE / NOTIFY also.=C2=A0=C2=A0

Samir,

Since this chang= e is purely editorial, serves no real purpose, and does not address any rea= l implementation=C2=A0issues, it is out of scope for the=C2=A04028bis.

There is a good argument to be made,=C2=A0that that en= tire table should be removed to avoid any future queries like this in the= =C2=A0future, but since this is editorial as well, it is likely out of scop= e too.

Best Regards,
_____________
Roman Shpount=C2= =A0
--000000000000e917f005a5813350-- From nobody Wed May 13 00:43:25 2020 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 72AC23A0F8A for ; Wed, 13 May 2020 00:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 0CohGdm0jxyY for ; Wed, 13 May 2020 00:43:21 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60054.outbound.protection.outlook.com [40.107.6.54]) (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 460C73A0884 for ; Wed, 13 May 2020 00:43:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cuAnNKxP7XhJie1NS8le8cmoKbeNbe6g+ebkys3hcPxCjT7WISWKjAz0oJ1ZJthev9Qh4l8BW0P3a6jEmw4cvJmXFZE9VErse3CXaOq3dffqT/ERmR/ALNP5W8QmYn+C7zpk4Nk6NRxu4iTIhsI4tvFS1UrXk0e2j5fUC274IyvyYoq1Zfs2cVV1L75Ar8YdjawYgHZUr3dKW/bsn4G8RRHhq++LCURzWovwjshGZdhHH4X836GXRm8Vm38PZ4x7MLYGaqR1Xj3sKzFv81UK1yCzkD1a0+eHGxfMu1cn9orbKPHrrubSVGSs9Dxp+WRGcqWArAQt9fyTn1DRmNY1RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fNF9Y8IHGpQTS++UUQb2Zd8W06eGkc5Iycbnazepdzg=; b=fxFqV9ntEQehk75aGhcqQOGe+7ngu6dpeszEn+ca4Dk3VU2e50miIFOQyDoIoukbXDybsP8NhGcNZC/0UkdSCJYadcQK7fKNOJK1+YdrOzF0CRhaIKp2H4hNxmElIpoBW2oQVjvcoMIPfhGHhgGNWCK1zXYFgsCKoB91L1/wz8mbk+0WH4C1V8ifZh50+5OOsSRshCqT71+Tm8fPgxCsBDAzTvQbxn6Y5YSLSpi0pbCnaeK/fTcFz0UQwRzKUA2tUXFHYL3iJ7A/ICrQV5HV5ek/QUWbJuNoKqwDW7diUHSdQ0Rn+vF6PJdd0iM0zkmp4rBTFoEB0SklZOCB6nwhjA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fNF9Y8IHGpQTS++UUQb2Zd8W06eGkc5Iycbnazepdzg=; b=ftcRyFhetlWzxAw8DM9FhmpYqGMc+IvYRqNLI4QJOgIjbQ76n/8RcFCO4f0jbl4o0MmcMfrF5NUFdYchiWThxsLI9Cai4ULwuaT5zJ7HTcL8cEQLINcDYIOFvQBM4V9zt2p+NEF25Y+5lvu5cVgfqYB8PQgI0NicXTdH4dbE8z0= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6691.eurprd07.prod.outlook.com (2603:10a6:20b:1ac::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.11; Wed, 13 May 2020 07:43:19 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Wed, 13 May 2020 07:43:19 +0000 From: Christer Holmberg To: Roman Shpount , Samir Srivastava CC: Paul Kyzivat , SIPCORE Thread-Topic: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined Thread-Index: AQHWJsy7Tb3AmLI5VEauNVgVXU0GX6ihi0KAgABLRgCAATClAIAANqkAgAEPMwCAAK6TgIAABCyAgACFXgCAAALrAIAAUPUA Date: Wed, 13 May 2020 07:43:18 +0000 Message-ID: References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> <20200513054306.8A2EEC06FF@smtp.hushmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3837b469-02b9-4ca4-66ff-08d7f7114ded x-ms-traffictypediagnostic: AM7PR07MB6691: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-forefront-prvs: 0402872DA1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zRH/XsWv9/0pBfNYlDzMVyuMzxaFTnFJjT/V++EEHrjbs4BQ6xB9FIk9tqlyCd06rahnJu31kHo1hsU4so/oQnupzZVdekHyfcgep0EhVWssNMXhd+haB8UyQpco8rqAX1GYuPdXQVd8oTZTz9lIYGsSaA2Q8PKuvkw0aHq25oME2bNRgAdsEyaozEsDa3c1ZgpZl8HDeSrID1fk1nMxwVT0C0sds+V0l4+6w5JENUqvRiKEy9HG7qusVPDds7JFmp2dX+BrMvzneP4nIxbq7ZREVatp2JXZvaqCqGxldfXHZipFyrzg4ewNM+3E+lzhGw1WnVzpsYMaraneTygItEQIn4i8xQdIKMc/HAZ2mJgtVn9FCOanfKLG7moKvXoGNClumWWJrr+R9mDx7cC8Rx3H+0v5L0dK0EsaK1oqYqy3KOUqGh2mrIcp4/2YU3h/BnO+LA1/mPcAqgRU4+b/9GHUmY4UcXiE74/irpA1CPHIv8Eo+EUjRCK2sAb19poS1fw+/DMu+ktqh3pAicFcUw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(33430700001)(478600001)(86362001)(6512007)(186003)(71200400001)(26005)(4326008)(110136005)(44832011)(316002)(54906003)(33440700001)(5660300002)(8676002)(8936002)(6506007)(53546011)(66446008)(66476007)(66556008)(91956017)(2906002)(6486002)(76116006)(2616005)(64756008)(66946007)(15650500001)(36756003)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 5nvgIaVhORqc+SYHnXX5UJ+mu7QQqHxfzqAbZ/hRxceB9ABSDMqZJQzTrXziS8pRgiFpUN/vc1aZq/GsKZ+h5d4f1TWW+DkAF3uUVH5haG29cCkiexgw5bSwB/EPpkDsRY1LQzyHxiO+0mpcE8pVDpz313dAbZOctFOn8nl7Dv5ile4LUCBNuKbu5mJ/mJFOV4M/CWz3iUC/tUrBp564yQvrJ/FE2YG/iFp3wrWycfuGlqMmjt4iB9FG6r4Qp0cX3osB8T48Ylkuq4DpqufqR8QFDacLURmgMJ4fUbA7tUU+Ppt3WODCs1VNpBPeeZAbTLfyYGKTtOW3oRCZXjmoY/IfRDlDSEQTaseoLOPQOzik9UxUF5jkfc/eFN+c7niTizm6U08cFuYMqES2q3eCx/NCtcLgt7RKtOtt5YvGrfL829I8z7mrIC04j2jXTgi6LjPbkqOqqAXXRBCzZBRcZnDjWpzwcZwKDw4Ase/eOH5IJvUkFUWai4p6e7vxJI6c x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BD2386DB868C494E9433B16BFF478434ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3837b469-02b9-4ca4-66ff-08d7f7114ded X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 07:43:18.9276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /5SjCCAirWGxi2SfYHqt2ttP0EV3L8kzy8akRdDLGawR6hLAOLzB9ChlYgr0kYeGNRaYPebWOijD7+A+w3qirM4YS4Biad2JiXlwM00X81c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6691 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 07:43:23 -0000 --_000_BD2386DB868C494E9433B16BFF478434ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCk5vdGUgdGhhdCBlZGl0b3JpYWwgY2hhbmdlcyBBUkUgZmluZSwgaWYgdGhleSBhcmUg ZG9uZSBpbiBvcmRlciB0byBhdm9pZCBjb25mdXNpb24sIG9yIHRvIGNsYXJpZnkgdGhpbmdzLiBC dXQsIHdlIGFyZSBub3QgZ29pbmcgdG8gZG8gdGhpbmdzIHRoYXQgYXJlIGFnYWluc3QgcHJldmlv dXNseSBhZ3JlZW1lbnRzIChzZWUgQWRhbeKAmXMgcmVwbHkpLg0KDQpJbiB0aGUgdmlkZW8gSSBt ZW50aW9uZWQgc29tZSB0aGluZ3MgdGhhdCBuZWVkIHRvIGJlIGNsYXJpZmllZCwgZS5nLiB0aGUg bWVhbmluZyBvZiDigJxpbml0aWFsIHNlc3Npb24gcmVmcmVzaCByZXF1ZXN04oCdIGV0Yy4NCg0K UmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KDQoNCkZyb206IFJvbWFuIFNocG91bnQgPHJvbWFuQHRl bHVyaXguY29tPg0KRGF0ZTogV2VkbmVzZGF5LCAxMyBNYXkgMjAyMCBhdCA4LjUzDQpUbzogU2Ft aXIgU3JpdmFzdGF2YSA8c3JpdmFzdGF2YV9zYW1pckBodXNoLmNvbT4NCkNjOiAicGt5eml2YXRA YWx1bS5taXQuZWR1IiA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiwgInNpcGNvcmVAaWV0Zi5vcmci IDxzaXBjb3JlQGlldGYub3JnPiwgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gU2Vzc2lvbiBUaW1lcnMgKFJG QyA0MDI4KSBmb3IgUkVGRVIsIFBVQkxJU0gsIE1FU1NBR0Ugbm90IGRlZmluZWQNCg0KT24gV2Vk LCBNYXkgMTMsIDIwMjAgYXQgMTo0MyBBTSBTYW1pciBTcml2YXN0YXZhIDxzcml2YXN0YXZhX3Nh bWlyQGh1c2guY29tPG1haWx0bzpzcml2YXN0YXZhX3NhbWlyQGh1c2guY29tPj4gd3JvdGU6DQpU aGVyZSBhcmUgb3RoZXIgbWVzc2FnZXMgaW4gdGhlIHRhYmxlIGZvciB3aGljaCB0aGVzZSBoZWFk ZXJzIGFyZSBub3QgYXBwbGljYWJsZS4gT24gdGhlIHNhbWUgbGluZSBtZW50aW9uIHRoZXNlIGhl YWRlcnMgYXJlIG5vdCBhcHBsaWNhYmxlIGZvciBSRUZFUiwgUFVCTElTSCwgTUVTU0FHRSBtZXRo b2RzLiBNZXNzYWdlcyBhcGFydCBmcm9tIChyZSlJbnYgYW5kIFVQRCBhcmUgb25seSBtZW50aW9u ZWQgaW4gdGhlIHRhYmxlIGluIDQwMjhiaXMgYW5kIFJGQyA0MDI4LiA0MDI4YmlzIG1lbnRpb25z IGluIHRoZSB0YWJsZSB0aGF0IHRoZXNlIGhlYWRlcnMgYXJlIG5vdCBhcHBsaWNhYmxlIGZvciBT VUJTQ1JJQkUgLyBOT1RJRlkgYWxzby4NCg0KU2FtaXIsDQoNClNpbmNlIHRoaXMgY2hhbmdlIGlz IHB1cmVseSBlZGl0b3JpYWwsIHNlcnZlcyBubyByZWFsIHB1cnBvc2UsIGFuZCBkb2VzIG5vdCBh ZGRyZXNzIGFueSByZWFsIGltcGxlbWVudGF0aW9uIGlzc3VlcywgaXQgaXMgb3V0IG9mIHNjb3Bl IGZvciB0aGUgNDAyOGJpcy4NCg0KVGhlcmUgaXMgYSBnb29kIGFyZ3VtZW50IHRvIGJlIG1hZGUs IHRoYXQgdGhhdCBlbnRpcmUgdGFibGUgc2hvdWxkIGJlIHJlbW92ZWQgdG8gYXZvaWQgYW55IGZ1 dHVyZSBxdWVyaWVzIGxpa2UgdGhpcyBpbiB0aGUgZnV0dXJlLCBidXQgc2luY2UgdGhpcyBpcyBl ZGl0b3JpYWwgYXMgd2VsbCwgaXQgaXMgbGlrZWx5IG91dCBvZiBzY29wZSB0b28uDQoNCkJlc3Qg UmVnYXJkcywNCl9fX19fX19fX19fX18NClJvbWFuIFNocG91bnQNCg== --_000_BD2386DB868C494E9433B16BFF478434ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <5E579A481D40854D81190DE2CAC3B4BA@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tRkki IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPk5vdGUgdGhh dCBlZGl0b3JpYWwgY2hhbmdlcyBBUkUgZmluZSwgaWYgdGhleSBhcmUgZG9uZSBpbiBvcmRlciB0 byBhdm9pZCBjb25mdXNpb24sIG9yIHRvIGNsYXJpZnkgdGhpbmdzLiBCdXQsIHdlIGFyZSBub3Qg Z29pbmcgdG8gZG8gdGhpbmdzIHRoYXQgYXJlIGFnYWluc3QgcHJldmlvdXNseSBhZ3JlZW1lbnRz IChzZWUNCiBBZGFt4oCZcyByZXBseSkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkluIHRoZSB2aWRlbyBJIG1lbnRpb25lZCBzb21lIHRoaW5ncyB0aGF0IG5lZWQgdG8gYmUgY2xh cmlmaWVkLCBlLmcuIHRoZSBtZWFuaW5nIG9mIOKAnGluaXRpYWwgc2Vzc2lvbiByZWZyZXNoIHJl cXVlc3TigJ0gZXRjLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hyaXN0ZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Sb21hbiBTaHBvdW50ICZsdDtyb21hbkB0ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5EYXRl OiA8L2I+V2VkbmVzZGF5LCAxMyBNYXkgMjAyMCBhdCA4LjUzPGJyPg0KPGI+VG86IDwvYj5TYW1p ciBTcml2YXN0YXZhICZsdDtzcml2YXN0YXZhX3NhbWlyQGh1c2guY29tJmd0Ozxicj4NCjxiPkNj OiA8L2I+JnF1b3Q7cGt5eml2YXRAYWx1bS5taXQuZWR1JnF1b3Q7ICZsdDtwa3l6aXZhdEBhbHVt Lm1pdC5lZHUmZ3Q7LCAmcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGll dGYub3JnJmd0OywgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzaXBjb3JlXSBTZXNzaW9uIFRp bWVycyAoUkZDIDQwMjgpIGZvciBSRUZFUiwgUFVCTElTSCwgTUVTU0FHRSBub3QgZGVmaW5lZDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPk9uIFdlZCwgTWF5IDEzLCAyMDIwIGF0IDE6NDMgQU0gU2FtaXIgU3JpdmFzdGF2 YSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNyaXZhc3RhdmFfc2FtaXJAaHVzaC5jb20iPnNyaXZhc3Rh dmFfc2FtaXJAaHVzaC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5U aGVyZSBhcmUgb3RoZXIgbWVzc2FnZXMgaW4gdGhlIHRhYmxlIGZvciB3aGljaCB0aGVzZSBoZWFk ZXJzIGFyZSBub3QgYXBwbGljYWJsZS4gT24gdGhlIHNhbWUgbGluZSBtZW50aW9uIHRoZXNlIGhl YWRlcnMgYXJlIG5vdCBhcHBsaWNhYmxlIGZvciBSRUZFUiwgUFVCTElTSCwgTUVTU0FHRSBtZXRo b2RzLg0KIE1lc3NhZ2VzIGFwYXJ0IGZyb20gKHJlKUludiBhbmQgVVBEIGFyZSBvbmx5IG1lbnRp b25lZCBpbiB0aGUgdGFibGUgaW4gNDAyOGJpcyBhbmQgUkZDIDQwMjguIDQwMjhiaXMgbWVudGlv bnMgaW4gdGhlIHRhYmxlIHRoYXQgdGhlc2UgaGVhZGVycyBhcmUgbm90IGFwcGxpY2FibGUgZm9y IFNVQlNDUklCRSAvIE5PVElGWSBhbHNvLiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNhbWlyLDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TaW5j ZSB0aGlzIGNoYW5nZSBpcyBwdXJlbHkgZWRpdG9yaWFsLCBzZXJ2ZXMgbm8gcmVhbCBwdXJwb3Nl LCBhbmQgZG9lcyBub3QgYWRkcmVzcyBhbnkgcmVhbCBpbXBsZW1lbnRhdGlvbiZuYnNwO2lzc3Vl cywgaXQgaXMgb3V0IG9mIHNjb3BlIGZvciB0aGUmbmJzcDs0MDI4YmlzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBpcyBhIGdvb2Qg YXJndW1lbnQgdG8gYmUgbWFkZSwmbmJzcDt0aGF0IHRoYXQgZW50aXJlIHRhYmxlIHNob3VsZCBi ZSByZW1vdmVkIHRvIGF2b2lkIGFueSBmdXR1cmUgcXVlcmllcyBsaWtlIHRoaXMgaW4gdGhlJm5i c3A7ZnV0dXJlLCBidXQgc2luY2UgdGhpcyBpcyBlZGl0b3JpYWwgYXMgd2VsbCwgaXQgaXMgbGlr ZWx5IG91dCBvZiBzY29wZSB0b28uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvbWFu IFNocG91bnQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BD2386DB868C494E9433B16BFF478434ericssoncom_-- From nobody Wed May 13 05:25:34 2020 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 3582F3A0D97 for ; Wed, 13 May 2020 05:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ntlworld.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 zrX2Y1zLo7NE for ; Wed, 13 May 2020 05:25:28 -0700 (PDT) Received: from know-smtprelay-omc-4.server.virginmedia.net (know-smtprelay-omc-4.server.virginmedia.net [80.0.253.68]) (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 095EF3A10A2 for ; Wed, 13 May 2020 05:25:27 -0700 (PDT) Received: from [192.168.0.17] ([81.97.229.170]) by cmsmtp with ESMTPA id YqRwjIlxUlYjAYqRwjinh1; Wed, 13 May 2020 13:25:25 +0100 X-Originating-IP: [81.97.229.170] X-Authenticated-User: drageke@ntlworld.com X-Spam: 0 X-Authority: v=2.3 cv=d6TbNyrE c=1 sm=1 tr=0 a=uMkRna9mZ6QJhuoPpEZIww==:117 a=uMkRna9mZ6QJhuoPpEZIww==:17 a=r77TgQKjGQsHNAKrUKIA:9 a=283K6oDNAAAA:8 a=48vgC7mUAAAA:8 a=dRqFMkKFnnnXGC19Oh8A:9 a=QEXdDO2ut3YA:10 a=8c8-Wn2gAAAA:8 a=WjmIRXxJcTImafgfJNgA:9 a=VhMpQWFZPWSI2hSO:21 a=_W_S_7VecoQA:10 a=jdmypcmVXt6yuKJ2GOTk:22 a=w1C3t2QeGrPiZgrLijVG:22 a=4UqCWT6cI65jMZUUGvaY:22 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ntlworld.com; s=meg.feb2017; t=1589372725; bh=mXuPyd2jVQ24SrVbRygoSG7t3uMCtuc5UMSW9vBKjbk=; h=Subject:To:References:From:Date:In-Reply-To; b=TygXiYdDLH1YoQJrfNKUZsDqoALk33vpZrMIxJZJI9LRIYXfnZiDTS/1lhcatGSo+ Y7sxb/8k2gD4ace9NxzovF11EePygO6OTazpn6T/be7FTdpOC6nhpMQKpQWIBpTYYk p1Bh2bUqTqUNK6Ro/0fo3UNk0snESNpN92k6hb3UoLDTMww/JFZv1cxhNNW4i3QcRg 87vjvN38DQN+LmGLQzWnijJWZbnHvUsmkyAgvYVoLpwxyiUTppVOQ0uOdge1R7zYkP cNb+kJmLv5dBpS2XggfoH+x2BBmZWQ8FlUdUlFFwDL0Qh+knl98sDM+mWvhwIPf3Ik OHZAGHjA8qNgg== To: Samir Srivastava , sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> From: Keith Drage Message-ID: Date: Wed, 13 May 2020 13:25:23 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <20200512105430.7F9542011C@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="------------6B7FB7FBEC28EDD3C6DD119D" Content-Language: en-GB X-CMAE-Envelope: MS4wfApRG/U99Hx4Fsit/OvWzRBXysEPfTbJw5KY1OdNxCNXckgJX2Di5yxGcSOoIKJ6d6R0T7RP9RUKyDynodAZcLOiz+Zxp/MXigh7ER0SGa2KlfgrXkjT djlj+KH6/lnC5Amkb5OiM4j1s9kJqI6sSagTXk7+tV5kdSNOxNCmWRIPd7p/CQQbSPrcbN0gNxISEOZRFLX6V4J986qVUbi6apY5SAk59pIMDPonM33G2X1f Archived-At: Subject: Re: [sipcore] Deprecation of tabular format of header fields || Was Re: Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:25:32 -0000 This is a multi-part message in MIME format. --------------6B7FB7FBEC28EDD3C6DD119D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit To answer your question from my perspective (and others may have further reasons) 1)    Maintainability. Every new header field and every new message would require some representation of the table, which either needs to reproduce the entire table, or explain the extension part relates to the existing table. If the entire table is not reproduced, then obviously there is not just the RFC 3261 table, but every other table in every other specification. If the tables were also made normative, this would also raise the question of how many other specifications would need to be updated by creating a new specification with a table. 2)    Double specification. The tables are in themselves insufficient. In RFC 3261 we have tables, the notes to the tables, and the main text all providing data on the use of the headers. I hate double specification; right of the start of my standardisation career, in order to obtain consensus on a specification, we were forced to change the normative part of a specification to align with an incorrect informative annex. It is far better to state something clearly only once. 3)    Incomplete specification. The tables are insufficient to adequately define the usage. Reliance on the tables therefore encourages incomplete specification. Keith On 12/05/2020 11:54, Samir Srivastava wrote: > Hi Keith Drage, > >   The below does not answer reason for deprecating tabular format i.e. > what are things which cannot be captured in tabular format. > >  Thanks > Samir Srivastava > https://samirsrivastava.typepad.com/ > > On 5/11/2020 at 9:32 PM, "Keith Drage" > wrote: > > Most header fields are included for a specific purpose entirely > unassociated with what mesage it is in. > > i.e. things like > > -    included because this message creates a dialog > > -    included because this message ends a dialog > > -    included becases this message is the request in a transaction > > -    included because this message responds to a transaction > > -    included because I can include it in any request > > etc. > > Those concepts have existed since RFC 3261. > > The exceptions tend to be header fields that are defined along > with a MESSAGE to carry them, i.e. in the same RFC. > > I am not suggesting the definers of new messages should not give > due consideration, only that in most cases they will not need to > add any extra requirements to their new RFC, because all the > considerations could already be in the header field defining RFC. > > > Keith > > P.S. I would note that you cannot go on the date of publication - > many RFCs take years to get through publication request to > published while others proceed quicker. > > > > On 11/05/2020 16:39, Samir Srivastava wrote: > > Hi, > >   Please find my replies Inline below prefixed with SS>> > > Thanks > Samir Srivastava > https://samirsrivastava.typepad.com/ > > On 5/11/2020 at 2:59 AM, "Keith Drage" > wrote: > > I dont know whether we reached something we can formally > describe as a > decision, but the overall opion was that it should be the > text that > should normatively describe what the requirements were for > the actions > in respect of inclusion in messages. If these tables were > included, they > should be clearly described as informative. > SS>> I am of the opinion that we need header, message etc > in the tabulated form. SIP Parser developers cannot be > expected to know the minute details of applicability of > the messages and headers etc. SIP architect in the vendor > comapnies might be required to give the headers and > messages in the tabulated form to SIP Parser developers. > If we all agree in the tabulated form as SPEC Writers, it > will be good service to the community. What are the > difficulties considered which made us to deprecate the > table format? > > Further, the normative text should be adequately worded to > encompass the > understanding what happened when new messages were > invented - so rather > than specifically listing messages, it should probably > talk about > messages that create a dialog, etc. > SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 >          REFER RFC https://tools.ietf.org/html/rfc3515 >           MESSAGE RFC https://tools.ietf.org/html/rfc3428 > >   They all were invented before RFC 4028.. They were NOT > developed after Session Timers. So it is left because of > mistake. 4028bis and RFC does not mention PUBLISH, REFER, > MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, > CANCEL, REGISTER, OPTIONS are only defined in the table > nowhere in text. If the added headers (MIN-SE, > SEssion-Expires are found in these message should be > reject the REQUEST or accept the by following "be lenient > what one accepts". Some guideline needs to be specified. >   Developer of new method need to look each header, > message etc in their respective RFC. What one can specify > for method foo for header foobar in advance? > > > > > Keith > > > On 10/05/2020 17:59, Paul Kyzivat wrote: > > On 5/10/20 9:12 AM, Samir Srivastava wrote: > >> Hi, > >> > >>    The table mentioned in Section 4 in RFC 4028 does > not contain > >> entries for REFER, PUBLISH and MESSAGE methods Below is > the table > >> from Section 4 > >> > >> > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >>     |     Header > |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >>     |Session-Expires|  R  | amr | - | - | - | o | - | - > | - | o | - | > >> - | > >>     |               |     |     |   | |   |   |   |   > |   | |   |   | > >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - > | - | o | - | > >> - | > >>     |               |     |     |   | |   |   |   |   > |   | |   |   | > >>     |Min-SE         |  R  | amr | - | - | - | o | - | - > | - | o | - | > >> - | > >>     |               |     |     |   | |   |   |   |   > |   | |   |   | > >>     |Min-SE         | 422 |     | - | - | - | m | - | - > | - | m | - | > >> - | > >> > +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ > >> > >>    They are not applicable for these, but it would have > been better > >> if it is said categorically. > > > > IIRC, quite a long time ago it was decided that this > table in 3261 was > > a bad idea, because it is essentially a summary of > normative language > > in other sections of the document and is necessarily an > approximation. > > > > After that, other work that updates and extends 3261 has > been > > inconsistent it whether it updates the table or not. > > > > What we should be careful of is that the in progress > update to session > > timers is clear, normatively and expositively,  one way > or another. > > > >     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 > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --------------6B7FB7FBEC28EDD3C6DD119D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

To answer your question from my perspective (and others may have further reasons)

1)    Maintainability. Every new header field and every new message would require some representation of the table, which either needs to reproduce the entire table, or explain the extension part relates to the existing table. If the entire table is not reproduced, then obviously there is not just the RFC 3261 table, but every other table in every other specification. If the tables were also made normative, this would also raise the question of how many other specifications would need to be updated by creating a new specification with a table.

2)    Double specification. The tables are in themselves insufficient. In RFC 3261 we have tables, the notes to the tables, and the main text all providing data on the use of the headers. I hate double specification; right of the start of my standardisation career, in order to obtain consensus on a specification, we were forced to change the normative part of a specification to align with an incorrect informative annex. It is far better to state something clearly only once.

3)    Incomplete specification. The tables are insufficient to adequately define the usage. Reliance on the tables therefore encourages incomplete specification.

Keith

On 12/05/2020 11:54, Samir Srivastava wrote:
Hi Keith Drage,

  The below does not answer reason for deprecating tabular format i.e. what are things which cannot be captured in tabular format.

 Thanks
Samir Srivastava

On 5/11/2020 at 9:32 PM, "Keith Drage" <drageke=40ntlworld.com@dmarc.ietf.org> wrote:

Most header fields are included for a specific purpose entirely unassociated with what mesage it is in.

i.e. things like

-    included because this message creates a dialog

-    included because this message ends a dialog

-    included becases this message is the request in a transaction

-    included because this message responds to a transaction

-    included because I can include it in any request

etc.

Those concepts have existed since RFC 3261.

The exceptions tend to be header fields that are defined along with a MESSAGE to carry them, i.e. in the same RFC.

I am not suggesting the definers of new messages should not give due consideration, only that in most cases they will not need to add any extra requirements to their new RFC, because all the considerations could already be in the header field defining RFC.


Keith

P.S. I would note that you cannot go on the date of publication - many RFCs take years to get through publication request to published while others proceed quicker.



On 11/05/2020 16:39, Samir Srivastava wrote:
Hi,

  Please find my replies Inline below prefixed with SS>>

Thanks

On 5/11/2020 at 2:59 AM, "Keith Drage" <drageke=40ntlworld.com@dmarc.ietf.org> wrote:
I dont know whether we reached something we can formally describe as a
decision, but the overall opion was that it should be the text that
should normatively describe what the requirements were for the actions
in respect of inclusion in messages. If these tables were included, they
should be clearly described as informative.
SS>> I am of the opinion that we need header, message etc in the tabulated form. SIP Parser developers cannot be expected to know the minute details of applicability of the messages and headers etc. SIP architect in the vendor comapnies might be required to give the headers and messages in the tabulated form to SIP Parser developers. If we all agree in the tabulated form as SPEC Writers, it will be good service to the community. What are the difficulties considered which made us to deprecate the table format?

Further, the normative text should be adequately worded to encompass the
understanding what happened when new messages were invented - so rather
than specifically listing messages, it should probably talk about
messages that create a dialog, etc.
SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903
         REFER RFC https://tools.ietf.org/html/rfc3515
          MESSAGE RFC https://tools.ietf.org/html/rfc3428

  They all were invented before RFC 4028.. They were NOT developed after Session Timers. So it is left because of mistake. 4028bis and RFC does not mention PUBLISH, REFER, MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, CANCEL, REGISTER, OPTIONS are only defined in the table nowhere in text. If the added headers (MIN-SE, SEssion-Expires are found in these message should be reject the REQUEST or accept the by following "be lenient what one accepts". Some guideline needs to be specified. 
  Developer of new method need to look each header, message etc in their respective RFC. What one can specify for method foo for header foobar in advance? 




Keith


On 10/05/2020 17:59, Paul Kyzivat wrote:
> On 5/10/20 9:12 AM, Samir Srivastava wrote:
>> Hi,
>>
>>    The table mentioned in Section 4 in RFC 4028 does not contain
>> entries for REFER, PUBLISH and MESSAGE methods Below is the table
>> from Section 4
>>
>>
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>     |     Header |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT|
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>     |Session-Expires|  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Min-SE         |  R  | amr | - | - | - | o | - | - | - | o | - |
>> - |
>>     |               |     |     |   |   |   |   |   |   |   | |   |   |
>>     |Min-SE         | 422 |     | - | - | - | m | - | - | - | m | - |
>> - |
>> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+
>>
>>    They are not applicable for these, but it would have been better
>> if it is said categorically.
>
> IIRC, quite a long time ago it was decided that this table in 3261 was
> a bad idea, because it is essentially a summary of normative language
> in other sections of the document and is necessarily an approximation.
>
> After that, other work that updates and extends 3261 has been
> inconsistent it whether it updates the table or not.
>
> What we should be careful of is that the in progress update to session
> timers is clear, normatively and expositively,  one way or another.
>
>     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
 
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--------------6B7FB7FBEC28EDD3C6DD119D-- From nobody Wed May 13 05:46:12 2020 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 F14D13A10E1 for ; Wed, 13 May 2020 05:46:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 64OPW28bO_iU for ; Wed, 13 May 2020 05:46:02 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2042.outbound.protection.outlook.com [40.107.237.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 F34003A10E3 for ; Wed, 13 May 2020 05:46:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CZ6x5cfpFTHQB5xEi5y5nNytgnjDkaR8lQ4qZv/DiCPwtoPOczGPywaKFYPLPZ0MyaGaQuZ36+ihQdzCuIdyHLJIX2SPPvNOs27RS5N74chz37RgL4f5h3TxHrY6U4VpGgFo0UaNYtLH+mISvhwYrYFgSgpeBZl4x3uonnDuzLE4SDe/szDkbV0GETenrm56Fw9ywCVV68vS41owVODTjY809N/JDE3BOV3muVU0jJWSFEZg4DYafGuiUGAGCE7WYw8U5KCHLZmBzRylCzvuovRs111p0kenlGmhmcKzJ5hgsEpDL8kSDKfImkLZ6wuVl2BjE3tIX34ExhITwAg6OA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ve/wJwrroCnhoNJAWsGBPh03alx/NbQfk+tVY+rlojU=; b=UMXHvMUsQlg5uO6TiVYPMbm0y/iRsmR2uQ0OTWShE2rMeOkxH6Th0H+0mfXCOdVTVKColw4T5Wydue7Wp4LPtPbkXYnhWlGSk9KaVlLpwXtTngBHVyfOIMDNDk3dDe+M6/iAkpuOqdgH+SiJnMfQHA41x6j97cCDiGVTjpwpZMkJLG7Qhy96KqxbWYa6WAbQIWhCkWlh6ixXhv7IkgkHnpLhFxAsd7jHoIFcVBiuMVK5kFjVS09tqKvYCmkNz0z2dxUY3fKQj8/hd5cdXjqtOIbyR4ZRK8uGihxa2Bct1r/bznDdRWtOh4FGnefuH2/xlHDMSyuAe+JTiEay2mkvyA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=dmarc.ietf.org smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ve/wJwrroCnhoNJAWsGBPh03alx/NbQfk+tVY+rlojU=; b=FCL+CCRMUwuGQ3v8DSLdk/YMo6zmDswM48l8iME0whv37jgywuayCx0Uoc4l4Tk7hINPrDKjTm3jpvysIz2c5qplEY/mtzDH7IhXN20gKbHHtvhMDvMu/Xqt9Axxzk4+CiFX273i/TlR7inHCjzmpco4IefCoocGKwa3UJw10/s= Received: from DM6PR01CA0020.prod.exchangelabs.com (2603:10b6:5:296::25) by MWHPR12MB1326.namprd12.prod.outlook.com (2603:10b6:300:10::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20; Wed, 13 May 2020 12:45:59 +0000 Received: from CY1NAM02FT031.eop-nam02.prod.protection.outlook.com (2603:10b6:5:296:cafe::22) by DM6PR01CA0020.outlook.office365.com (2603:10b6:5:296::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.20 via Frontend Transport; Wed, 13 May 2020 12:45:59 +0000 Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by CY1NAM02FT031.mail.protection.outlook.com (10.152.75.180) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2979.29 via Frontend Transport; Wed, 13 May 2020 12:45:58 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 04DCjuRM029481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 13 May 2020 08:45:56 -0400 To: Keith Drage , Samir Srivastava , sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> From: Paul Kyzivat Message-ID: Date: Wed, 13 May 2020 08:45:55 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(346002)(376002)(136003)(396003)(46966005)(33430700001)(8676002)(5660300002)(26005)(336012)(53546011)(110136005)(786003)(956004)(186003)(47076004)(2616005)(36906005)(356005)(316002)(75432002)(8936002)(70586007)(31686004)(478600001)(82310400002)(86362001)(33440700001)(966005)(2906002)(82740400003)(70206006)(15650500001)(7596003)(31696002)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 089c4ee6-4e7e-475f-f1e0-08d7f73b95ee X-MS-TrafficTypeDiagnostic: MWHPR12MB1326: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-Forefront-PRVS: 0402872DA1 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vCKsGI/ydfqTUqOpcE98lYIrgNI5rwAXllKhZbp0fRpOXPW5pFO3gl84MQcj0fEru2gl00daJIPJMp6umJq/p/kEOwH9Cf81KhPHmDwIsH1fF0Y8IDADeeWgBTFsvR53ST0l/8ha3WpAEu4uHW6oXkppA0Njolybk5AfNeRUXYWBqsmgwJyk3DDVS7lisNrszn8Fc2w0wJU95E8NVAbhFNPOpxVw0jJMxOOWj/kQIK/Yk2JE0jVghtho/R/xcvKYgXD7qKPcEBZ0DhVral5kp5bSmCd/Q42eZribUdu4CnpYtE8f1UVTb3vKqluPpynlJmzfcABBrFimIP1pDn9XBNMdDOKx4oCQcT+dB/eXUXisNrcnrcPtLdtKzlZSyRyf4fRAOAJc7qy4Hv7DUb8qAv0KLhZqivJcyVZaUvDuLDgW3V3DuIjASwdcyrGMsLkgognYmyruxmPOF1v1iOweMaqFfHMtTptRBg8p+08/8gtUhJnXj1FtZMwV+/WHDpMBoBjreu6b/9Oxj/Mgc8YB2p5etP/xfMIvt1xV40KavTxC1vwsRF+BlHjKkGKN4oaz3uMImcJU8Ei/DTKi/3ZZb0Q/Die6DewuSPgqP20ZVrpqvPI8kZZPi4/Sa+gRQZM8FVsQMsppo4trP+h7DPxAzjmqSEg43bksebOCk0ROWWNS3NxGB80oPE4Iv7IlxDFK X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 May 2020 12:45:58.4001 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 089c4ee6-4e7e-475f-f1e0-08d7f73b95ee X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR12MB1326 Archived-At: Subject: Re: [sipcore] Deprecation of tabular format of header fields || Was Re: Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 12:46:05 -0000 Keith, I agree with all your points. The only sticky issue is that 3261 contains normative language about the table. This could be fixed in a bis, but I don't foresee a bis coming any time soon. Thanks, Paul On 5/13/20 8:25 AM, Keith Drage wrote: > To answer your question from my perspective (and others may have further > reasons) > > 1)    Maintainability. Every new header field and every new message > would require some representation of the table, which either needs to > reproduce the entire table, or explain the extension part relates to the > existing table. If the entire table is not reproduced, then obviously > there is not just the RFC 3261 table, but every other table in every > other specification. If the tables were also made normative, this would > also raise the question of how many other specifications would need to > be updated by creating a new specification with a table. > > 2)    Double specification. The tables are in themselves insufficient. > In RFC 3261 we have tables, the notes to the tables, and the main text > all providing data on the use of the headers. I hate double > specification; right of the start of my standardisation career, in order > to obtain consensus on a specification, we were forced to change the > normative part of a specification to align with an incorrect informative > annex. It is far better to state something clearly only once. > > 3)    Incomplete specification. The tables are insufficient to > adequately define the usage. Reliance on the tables therefore encourages > incomplete specification. > > Keith > > On 12/05/2020 11:54, Samir Srivastava wrote: >> Hi Keith Drage, >> >>   The below does not answer reason for deprecating tabular format i.e. >> what are things which cannot be captured in tabular format. >> >>  Thanks >> Samir Srivastava >> https://samirsrivastava.typepad.com/ >> >> On 5/11/2020 at 9:32 PM, "Keith Drage" >> wrote: >> >> Most header fields are included for a specific purpose entirely >> unassociated with what mesage it is in. >> >> i.e. things like >> >> -    included because this message creates a dialog >> >> -    included because this message ends a dialog >> >> -    included becases this message is the request in a transaction >> >> -    included because this message responds to a transaction >> >> -    included because I can include it in any request >> >> etc. >> >> Those concepts have existed since RFC 3261. >> >> The exceptions tend to be header fields that are defined along >> with a MESSAGE to carry them, i.e. in the same RFC. >> >> I am not suggesting the definers of new messages should not give >> due consideration, only that in most cases they will not need to >> add any extra requirements to their new RFC, because all the >> considerations could already be in the header field defining RFC. >> >> >> Keith >> >> P.S. I would note that you cannot go on the date of publication - >> many RFCs take years to get through publication request to >> published while others proceed quicker. >> >> >> >> On 11/05/2020 16:39, Samir Srivastava wrote: >> >> Hi, >> >>   Please find my replies Inline below prefixed with SS>> >> >> Thanks >> Samir Srivastava >> https://samirsrivastava.typepad.com/ >> >> On 5/11/2020 at 2:59 AM, "Keith Drage" >> wrote: >> >> I dont know whether we reached something we can formally >> describe as a >> decision, but the overall opion was that it should be the >> text that >> should normatively describe what the requirements were for >> the actions >> in respect of inclusion in messages. If these tables were >> included, they >> should be clearly described as informative. >> SS>> I am of the opinion that we need header, message etc >> in the tabulated form. SIP Parser developers cannot be >> expected to know the minute details of applicability of >> the messages and headers etc. SIP architect in the vendor >> comapnies might be required to give the headers and >> messages in the tabulated form to SIP Parser developers. >> If we all agree in the tabulated form as SPEC Writers, it >> will be good service to the community. What are the >> difficulties considered which made us to deprecate the >> table format? >> >> Further, the normative text should be adequately worded to >> encompass the >> understanding what happened when new messages were >> invented - so rather >> than specifically listing messages, it should probably >> talk about >> messages that create a dialog, etc. >> SS>> PUBLISH RFC https://tools.ietf.org/html/rfc3903 >>          REFER RFC https://tools.ietf.org/html/rfc3515 >>           MESSAGE RFC https://tools.ietf.org/html/rfc3428 >> >>   They all were invented before RFC 4028.. They were NOT >> developed after Session Timers. So it is left because of >> mistake. 4028bis and RFC does not mention PUBLISH, REFER, >> MESSAGE in the text anywhere. SUBSCRIBE, NOTIFY, PRACK, >> CANCEL, REGISTER, OPTIONS are only defined in the table >> nowhere in text. If the added headers (MIN-SE, >> SEssion-Expires are found in these message should be >> reject the REQUEST or accept the by following "be lenient >> what one accepts". Some guideline needs to be specified. >>   Developer of new method need to look each header, >> message etc in their respective RFC. What one can specify >> for method foo for header foobar in advance? >> >> >> >> >> Keith >> >> >> On 10/05/2020 17:59, Paul Kyzivat wrote: >> > On 5/10/20 9:12 AM, Samir Srivastava wrote: >> >> Hi, >> >> >> >>    The table mentioned in Section 4 in RFC 4028 does >> not contain >> >> entries for REFER, PUBLISH and MESSAGE methods Below is >> the table >> >> from Section 4 >> >> >> >> >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >>     |     Header >> |where|proxy|ACK|BYE|CAN|INV|OPT|REG|PRA|UPD|SUB|NOT| >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >>     |Session-Expires|  R  | amr | - | - | - | o | - | - >> | - | o | - | >> >> - | >> >>     |               |     |     |   | |   |   |   | >> |   | |   |   | >> >>     |Session-Expires| 2xx | ar  | - | - | - | o | - | - >> | - | o | - | >> >> - | >> >>     |               |     |     |   | |   |   |   | >> |   | |   |   | >> >>     |Min-SE         |  R  | amr | - | - | - | o | - | - >> | - | o | - | >> >> - | >> >>     |               |     |     |   | |   |   |   | >> |   | |   |   | >> >>     |Min-SE         | 422 |     | - | - | - | m | - | - >> | - | m | - | >> >> - | >> >> >> +---------------+-----+-----+---+---+---+---+---+---+---+---+---+---+ >> >> >> >>    They are not applicable for these, but it would have >> been better >> >> if it is said categorically. >> > >> > IIRC, quite a long time ago it was decided that this >> table in 3261 was >> > a bad idea, because it is essentially a summary of >> normative language >> > in other sections of the document and is necessarily an >> approximation. >> > >> > After that, other work that updates and extends 3261 has >> been >> > inconsistent it whether it updates the table or not. >> > >> > What we should be careful of is that the in progress >> update to session >> > timers is clear, normatively and expositively,  one way >> or another. >> > >> >     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 >> >> >> _______________________________________________ >> 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 May 13 06:50:51 2020 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 8794E3A0B60 for ; Wed, 13 May 2020 06:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (body has been altered)" header.d=hush.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 zxInbhyPQ0QX for ; Wed, 13 May 2020 06:50:48 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (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 0849C3A0B5A for ; Wed, 13 May 2020 06:50:48 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id A17DAA022C for ; Wed, 13 May 2020 13:50:47 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=vvDCg8CeajKbebHYa70oaqAOEF8M69KcKa+0N1XYsA0=; b=jlP/dNFyupKMJoVN6Jq+CSbWyVMiTnOQT74rY5nuxDJFtToM/5mhE6hGxRXsWbKeK4dQ8D2ILAMhlNHU0+h9WANggGcygMbYyvfpJTSe3LYYAmkTbMrhy6Z3qwoUiYabmLWeAAYgeUDtt2CtUiNhtvFb1O+sRarPbWzexOGD1bcOQfOWw5WTiBztFNMBmWm+9lRj1PqGgg0aiSmfjD4BLiXr261SXJyUoS2JvKlnFCq6yB1TDtPiC5kzT8d1WQ4CNrbywvQiSzNsD5r4mtZEygNtIO9J2y9MJ+10Jc8k6+xY8qgyyDu6h7YtKLUBqqjNFNNzX0eyDf0hO+QhUVlTng== Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS; Wed, 13 May 2020 13:50:46 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 4B0C040620; Wed, 13 May 2020 13:50:46 +0000 (UTC) MIME-Version: 1.0 Date: Wed, 13 May 2020 19:50:45 +0600 To: "Samir Srivastava" , "Paul Kyzivat" , "Roman Shpount" Cc: "SIPCORE" From: "Samir Srivastava" In-Reply-To: <20200513054306.8A2EEC06FF@smtp.hushmail.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> <20200513054306.8A2EEC06FF@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="=_890322f241b3dfc76354d046b40dacd7" Message-Id: <20200513135046.4B0C040620@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 13:50:50 -0000 --=_890322f241b3dfc76354d046b40dacd7 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi Paul, SUBSCRIBE / NOTIFY have headers Expires, Min-Expire to handle dialog clearing. ThanksSamir Srivastava http://samirsrivastava.typepad.com On 5/13/2020 at 11:13 AM, "Samir Srivastava" wrote:In-line prefixed with SS>> ThanksSamir Srivastavahttp://samirsrivastava.typepad.com On 5/13/2020 at 3:15 AM, "Paul Kyzivat" wrote:On 5/12/20 5:30 PM, Roman Shpount wrote: > Samir, > > Most likely Min-SE and Session-Expires headers in REFER, PUBLISH, > MESSAGE would be out of scope for 4028bis. So far there was an agreement > to limit the scope of 4028bis to fixing handling of multiple > transactions which modify Session-Expiration at the same time and > associated race conditions. > > Any other changes would need to go into another RFC. > > P.S. Why would you put Min-SE and Session-Expires into REFER, PUBLISH, > MESSAGE? These header fields are only defined for INVITE/UPDATE messages > and not applicable for any other messages. Putting them in *these* messages would be nonsensical because they are neither dialog establishing nor dialog refreshing. OTOH, it would make perfect sense to use them in SUBSCRIBE/NOTIFY because they *are*. Session Timer is about maintaining the dialog. I would think it would be equally applicable to these kinds of dialog usages. But that is probably deserving of discussion. SS>> There are other messages in the table for which these headers are not applicable. On the same line mention these headers are not applicable for REFER, PUBLISH, MESSAGE methods. Messages apart from (re)Inv and UPD are only mentioned in the table in 4028bis and RFC 4028. 4028bis mentions in the table that these headers are not applicable for SUBSCRIBE / NOTIFY also. Thanks, Paul --=_890322f241b3dfc76354d046b40dacd7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi = Paul,

  SUBSCRIBE / NOTIFY have headers Expires, Mi= n-Expire to handle dialog clearing. 

Thanks
Samir Srivastava

http://samirsrivastava.typepad.com

On 5/1= 3/2020 at 11:13 AM, "Samir Srivastava" <srivastava_samir=3D40hush.com@dm= arc.ietf.org> wrote:
In-line prefixed with SS>>

Thanks
Samir Srivastava
http://samirsrivastava.typepad.com=


On 5/13/2020 at 3:15 AM, "Paul Kyzivat" <pkyzivat@alum.mit.e= du> wrote:
On 5/12/20 5:30 PM, Roman Shpount wrote:
> Sam= ir,
>
> Most likely Min-SE and Session-Expires headers in &nbs= p;REFER, PUBLISH,
> MESSAGE would be out of scope for 4028bis. So fa= r there was an agreement
> to limit the scope of 4028bis to fix= ing handling of multiple
> transactions which modify Session-Expirat= ion at the same time and
> associated race conditions.
>
&= gt; Any other changes would need to go into another RFC.
>
> P= .S. Why would you put Min-SE and Session-Expires into REFER, PUBLISH,
&= gt; MESSAGE? These header fields are only defined for INVITE/UPDATE message= s
> and not applicable for any other messages.

Putting them i= n *these* messages would be nonsensical because they are
neither dialog= establishing nor dialog refreshing. OTOH, it would make
perfect sense = to use them in SUBSCRIBE/NOTIFY because they *are*.
Session Timer is ab= out maintaining the dialog. I would think it would be
equally applicabl= e to these kinds of dialog usages. But that is probably
deserving of di= scussion.

SS>>  There are other messages in the table for= which these headers are not applicable. On the same line mention these hea= ders are not applicable for REFER, PUBLISH, MESSAGE methods. Messages apart= from (re)Inv and UPD are only mentioned in the table in 4028bis and RFC 40= 28. 4028bis mentions in the table that these headers are not applicable for= SUBSCRIBE / NOTIFY also.  

Thanks,
Paul
=
--=_890322f241b3dfc76354d046b40dacd7-- From nobody Wed May 13 11:46:10 2020 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 4EDF23A0898 for ; Wed, 13 May 2020 11:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 Q6tN_1OIho0J for ; Wed, 13 May 2020 11:45:59 -0700 (PDT) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-eopbgr20079.outbound.protection.outlook.com [40.107.2.79]) (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 4A33E3A07C5 for ; Wed, 13 May 2020 11:45:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U1pcp12WR8teJ2qPr6HZep4Gz75jYxGfiImqqlWN6S85v2U7Md0D/rkRCwnAa2sKiZiF3ImWRZ8ZszpASStutNWRtX5WmCH4cN1W16E64KNbfNajxQ9lpOJSmJaLkoR42cYZbrO5Jk4MgI5lVD+nVlafp5SCnaPiiuJ8AMzbYicQ6ANMPyGTt07/63FSO6UgnRHbDt9a2iyxcmmgN22zQilTjNmUG0mwi5JLzWCMaIJzxsVNeVNxV3sXKYd1ZAS9FBJ5t53u6OtoyHIpj7fbutRNwp76AzKLRo6yu5NjotFpuy0/D1rFt7kl/hByDVItmH1la+ERdgmZvjB5Izy31A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1wC4z6r/XdKw9zrBtG7klInBRvkD36W5vmytQbQmGyc=; b=Lnipo43nwmzc2URrMP3OEDeOU9SiPonCnCIn/VaWU54BiaF2WlmY++5Cvo6qbhmqlFSnsIgRJHA+wOQXgOmzWbrxa/3kvoo2z7PEYrL7FHIQbsBeRtw1MB/0cA2wc1JNS9AEqMOhEdYcLuc1BNDJIZQpZTcbiUMBf6Os4SRgVcBPA7ZpQJNrCwRoL57pqysgZFnOyZdSO8Ds6voKPdzGAwLhL2XxKC7aRTJA/GUAU1MXO1+m1qaTNtC0RkU7n/PQmESMKnjm76k3yyYk0kZRHbu52/mpOKN5JP/EboZmcW3vHO2C8M82WwV3aufmCeHIfCndhYzh2i6bgI22Jp9aoA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1wC4z6r/XdKw9zrBtG7klInBRvkD36W5vmytQbQmGyc=; b=hfNFHQjj8KP6GRxhTtEsfJpT7mVSyOCaWSzRreiO4PYtKhbQ9IUBJJsoVXilVF5Vr+e8mbTGMlQEp4chY//kEh/eVmt5mHz1wY9W2CP2qxOB1wylnENUHIvTSotvrU3Gs+DVHgC8+DPpXd2lz4I3CaUwCU8sR5Rzlb61codDW/w= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6564.eurprd07.prod.outlook.com (2603:10a6:20b:1a1::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.13; Wed, 13 May 2020 18:45:54 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Wed, 13 May 2020 18:45:54 +0000 From: Christer Holmberg To: Samir Srivastava , Paul Kyzivat , Roman Shpount CC: SIPCORE Thread-Topic: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined Thread-Index: AQHWJsy7Tb3AmLI5VEauNVgVXU0GX6ihi0KAgABLRgCAATClAIAANqkAgAEPMwCAAK6TgIAABCyAgACFXgCAAIhAgIAAhMCA Date: Wed, 13 May 2020 18:45:54 +0000 Message-ID: <7A2F0025-4898-402B-8CF3-3BE2DA14E492@ericsson.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <2348C80C-C28F-4242-8097-1DC85D3C99D3@ericsson.com> <20200512110600.9497C2011C@smtp.hushmail.com> <56f10b9c-03aa-c9ea-8b23-a149c606aabf@alum.mit.edu> <20200513054306.8A2EEC06FF@smtp.hushmail.com> <20200513135046.4B0C040620@smtp.hushmail.com> In-Reply-To: <20200513135046.4B0C040620@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03cced28-f5fc-4651-822a-08d7f76dde1a x-ms-traffictypediagnostic: AM7PR07MB6564: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0402872DA1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RzrZYGPwHgbq7JxHA5+Zjv0DfZcACU1n6VEBMWQfk9sdvxvEDoQ6d156TfdhDkwLRTCjpPngl0XmQkj0954TV5RJTjRz+6oZvCefkCx6jMkp5VEp5jdVeOGdSu7eey8eqPXtPUJtqyUNsdw1ykOKOxjKR0DBng2xHrzm1XuS8pdbIKpPlXV/b6WsFQm8F34gkAFOjYYpf+oGTKlnsIMPxvH5c6dkuex7L9wO0sqMvc6QIa5gF/R7frIuEIJHrxVNdpZeduETi4xjlPT+YrhlP0/u2L9EEiAbTc8aC2Y89rWEEWB5/hY+lZiO52ekTMOV3s/5lftSwme1G2IPpCK2tTPOE7roahSvPd3ItYPNnytZT+WLuq9f7olm84cMak+ebUGBgVVWeGRQNkdMIApgZqzzIrZsfdTmgG7Nwm8xX/pwKtlTyrMx30U6Cg949/ZeZjCH6gCG5nEt9HfHTYReOvvUh6ss/egmOJ54nDvJd7dzkzKTZhcigXsZcsZGBJbgXuCsJqyk7IR4s6S44664B03xoBaI5a3U9U7a5hS+EDdOL59RnMYWWgE5ZWyVHJBsBMmT/bEnFUoK294wgGDOTnA6HSdpm497YaxYi+f0t/Q= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(136003)(346002)(39860400002)(376002)(396003)(33430700001)(5660300002)(8676002)(186003)(64756008)(66476007)(53546011)(76116006)(15650500001)(66556008)(33656002)(6506007)(66446008)(66946007)(8936002)(86362001)(71200400001)(478600001)(316002)(2906002)(966005)(110136005)(6512007)(4326008)(26005)(91956017)(44832011)(2616005)(36756003)(6486002)(166002)(33440700001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PbPEUTiGU5OUU6XQSL4ZDQQsajoh/CA5Hpsd0sPwp3ugoSxWp4ujtUbuZ9Os8Mc+9h6ujPy6P2KR5kdcQgOa2TIcixO6z6Abxz0gPGVhiDE2CNWLase9/OFfw89wceBQVRw8AQo4B0jaYeeUFihjsJnP6wIY6TlGgH03QPz8ZHM8U93xjl/1genJhErPadq+UV0v4mt5skgGNoEkgkVWjJFFVbYMJSg2G5vl8lB/Of+DGQlTrYKIgs4QSEHZcwdtnuFpG35ma/9CjC8ZuvT4CdXqfsd6Yfhj0kZT/VkD8RxLEhLEkz0c8g+4gQNshdtpNzCMc7yq6FkNCjOXzgm8K3Sldq6UiTgfkTbS4vthJQsDeWTp23vjMAftc403AjFrK78uWMq3Ue937H/a12G6ie4eQcuiyQnZ0PB5IaVIjA73x0efSwcB+5ukW6alSpWMBh060QoGX22cAhkJOJm/0sfo/lDupn4FoNWcQa9eE+5qPTs9zKz4uOyLKrON8QNX x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_7A2F00254898402B8CF33BE2DA14E492ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 03cced28-f5fc-4651-822a-08d7f76dde1a X-MS-Exchange-CrossTenant-originalarrivaltime: 13 May 2020 18:45:54.4536 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YKEHaHryqqTwK/HULqf8I1AvFWvvd7Hhkk06j/JWbpoS2pS4PEh952mwi2VnKWbYtRd6FIqXHQQ5PeH+AehGdy/dJBwN4iOWe5mxaY5Sv2w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6564 Archived-At: Subject: Re: [sipcore] Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 18:46:06 -0000 --_000_7A2F00254898402B8CF33BE2DA14E492ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClNpbmNlIFJGQyA0MDI4IHdhcyBwdWJsaXNoZWQgd2UgZ290IFJGQyA1MDU3LCB3aGlj aCBkZWZpbmVzIGRpZmZlcmVudCDigJxkaWFsb2cgdXNhZ2Vz4oCdLg0KDQpTbywgSSBndWVzcyB3 ZSBpbiA0MDI4YmlzIGNhbiBjbGFyaWZ5IHRoYXQgdGhlIHNlc3Npb24tdGltZXIgaXMgZm9yIOKA nGludml0ZSB1c2FnZXPigJ0sIGFuZCB0aGF0IHRoZSBwcm9jZWR1cmVzIGFwcGx5IGZvciBtZXRo b2RzIGFzc29jaWF0ZWQgd2l0aCBzdWNoIHVzYWdlcy4gVGhhdCB3b3VsZCBleGNsdWRlIFNVQlND UklCRSwgTk9USUZZLCBSRUZFUiBhbmQgUFVCTElTSC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yg U2FtaXIgU3JpdmFzdGF2YSA8c3JpdmFzdGF2YV9zYW1pcj00MGh1c2guY29tQGRtYXJjLmlldGYu b3JnPg0KRGF0ZTogV2VkbmVzZGF5LCAxMyBNYXkgMjAyMCBhdCAxNi41MQ0KVG86IFNhbWlyIFNy aXZhc3RhdmEgPHNyaXZhc3RhdmFfc2FtaXI9NDBodXNoLmNvbUBkbWFyYy5pZXRmLm9yZz4sICJw a3l6aXZhdEBhbHVtLm1pdC5lZHUiIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+LCBSb21hbiBTaHBv dW50IDxyb21hbkB0ZWx1cml4LmNvbT4NCkNjOiAic2lwY29yZUBpZXRmLm9yZyIgPHNpcGNvcmVA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFNlc3Npb24gVGltZXJzIChSRkMgNDAy OCkgZm9yIFJFRkVSLCBQVUJMSVNILCBNRVNTQUdFIG5vdCBkZWZpbmVkDQoNCkhpIFBhdWwsDQoN CiAgU1VCU0NSSUJFIC8gTk9USUZZIGhhdmUgaGVhZGVycyBFeHBpcmVzLCBNaW4tRXhwaXJlIHRv IGhhbmRsZSBkaWFsb2cgY2xlYXJpbmcuDQoNClRoYW5rcw0KU2FtaXIgU3JpdmFzdGF2YQ0KDQpo dHRwOi8vc2FtaXJzcml2YXN0YXZhLnR5cGVwYWQuY29tDQoNCk9uIDUvMTMvMjAyMCBhdCAxMTox MyBBTSwgIlNhbWlyIFNyaXZhc3RhdmEiIDxzcml2YXN0YXZhX3NhbWlyPTQwaHVzaC5jb21AZG1h cmMuaWV0Zi5vcmc+IHdyb3RlOg0KSW4tbGluZSBwcmVmaXhlZCB3aXRoIFNTPj4NCg0KVGhhbmtz DQpTYW1pciBTcml2YXN0YXZhDQpodHRwOi8vc2FtaXJzcml2YXN0YXZhLnR5cGVwYWQuY29tDQoN Cg0KT24gNS8xMy8yMDIwIGF0IDM6MTUgQU0sICJQYXVsIEt5eml2YXQiIDxwa3l6aXZhdEBhbHVt Lm1pdC5lZHU+IHdyb3RlOg0KT24gNS8xMi8yMCA1OjMwIFBNLCBSb21hbiBTaHBvdW50IHdyb3Rl Og0KPiBTYW1pciwNCj4NCj4gTW9zdCBsaWtlbHkgTWluLVNFIGFuZCBTZXNzaW9uLUV4cGlyZXMg aGVhZGVycyBpbiAgUkVGRVIsIFBVQkxJU0gsDQo+IE1FU1NBR0Ugd291bGQgYmUgb3V0IG9mIHNj b3BlIGZvciA0MDI4YmlzLiBTbyBmYXIgdGhlcmUgd2FzIGFuIGFncmVlbWVudA0KPiB0byBsaW1p dCB0aGUgc2NvcGUgb2YgNDAyOGJpcyB0byBmaXhpbmcgaGFuZGxpbmcgb2YgbXVsdGlwbGUNCj4g dHJhbnNhY3Rpb25zIHdoaWNoIG1vZGlmeSBTZXNzaW9uLUV4cGlyYXRpb24gYXQgdGhlIHNhbWUg dGltZSBhbmQNCj4gYXNzb2NpYXRlZCByYWNlIGNvbmRpdGlvbnMuDQo+DQo+IEFueSBvdGhlciBj aGFuZ2VzIHdvdWxkIG5lZWQgdG8gZ28gaW50byBhbm90aGVyIFJGQy4NCj4NCj4gUC4uUy4gV2h5 IHdvdWxkIHlvdSBwdXQgTWluLVNFIGFuZCBTZXNzaW9uLUV4cGlyZXMgaW50byBSRUZFUiwgUFVC TElTSCwNCj4gTUVTU0FHRT8gVGhlc2UgaGVhZGVyIGZpZWxkcyBhcmUgb25seSBkZWZpbmVkIGZv ciBJTlZJVEUvVVBEQVRFIG1lc3NhZ2VzDQo+IGFuZCBub3QgYXBwbGljYWJsZSBmb3IgYW55IG90 aGVyIG1lc3NhZ2VzLg0KDQpQdXR0aW5nIHRoZW0gaW4gKnRoZXNlKiBtZXNzYWdlcyB3b3VsZCBi ZSBub25zZW5zaWNhbCBiZWNhdXNlIHRoZXkgYXJlDQpuZWl0aGVyIGRpYWxvZyBlc3RhYmxpc2hp bmcgbm9yIGRpYWxvZyByZWZyZXNoaW5nLiBPVE9ILCBpdCB3b3VsZCBtYWtlDQpwZXJmZWN0IHNl bnNlIHRvIHVzZSB0aGVtIGluIFNVQlNDUklCRS9OT1RJRlkgYmVjYXVzZSB0aGV5ICphcmUqLg0K U2Vzc2lvbiBUaW1lciBpcyBhYm91dCBtYWludGFpbmluZyB0aGUgZGlhbG9nLiBJIHdvdWxkIHRo aW5rIGl0IHdvdWxkIGJlDQplcXVhbGx5IGFwcGxpY2FibGUgdG8gdGhlc2Uga2luZHMgb2YgZGlh bG9nIHVzYWdlcy4gQnV0IHRoYXQgaXMgcHJvYmFibHkNCmRlc2VydmluZyBvZiBkaXNjdXNzaW9u Lg0KDQpTUz4+ICBUaGVyZSBhcmUgb3RoZXIgbWVzc2FnZXMgaW4gdGhlIHRhYmxlIGZvciB3aGlj aCB0aGVzZSBoZWFkZXJzIGFyZSBub3QgYXBwbGljYWJsZS4gT24gdGhlIHNhbWUgbGluZSBtZW50 aW9uIHRoZXNlIGhlYWRlcnMgYXJlIG5vdCBhcHBsaWNhYmxlIGZvciBSRUZFUiwgUFVCTElTSCwg TUVTU0FHRSBtZXRob2RzLiBNZXNzYWdlcyBhcGFydCBmcm9tIChyZSlJbnYgYW5kIFVQRCBhcmUg b25seSBtZW50aW9uZWQgaW4gdGhlIHRhYmxlIGluIDQwMjhiaXMgYW5kIFJGQyA0MDI4LiA0MDI4 YmlzIG1lbnRpb25zIGluIHRoZSB0YWJsZSB0aGF0IHRoZXNlIGhlYWRlcnMgYXJlIG5vdCBhcHBs aWNhYmxlIGZvciBTVUJTQ1JJQkUgLyBOT1RJRlkgYWxzby4NCg0KVGhhbmtzLA0KUGF1bA0K --_000_7A2F00254898402B8CF33BE2DA14E492ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <6CEFEB95FE9D9A419680055620077624@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tRkki IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkZJIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlNpbmNlIFJG QyA0MDI4IHdhcyBwdWJsaXNoZWQgd2UgZ290IFJGQyA1MDU3LCB3aGljaCBkZWZpbmVzIGRpZmZl cmVudCDigJxkaWFsb2cgdXNhZ2Vz4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PlNvLCBJIGd1ZXNzIHdlIGluIDQwMjhiaXMgY2FuIGNsYXJpZnkgdGhhdCB0aGUgc2Vzc2lvbi10 aW1lciBpcyBmb3Ig4oCcaW52aXRlIHVzYWdlc+KAnSwgYW5kIHRoYXQgdGhlIHByb2NlZHVyZXMg YXBwbHkgZm9yIG1ldGhvZHMgYXNzb2NpYXRlZCB3aXRoIHN1Y2ggdXNhZ2VzLiBUaGF0IHdvdWxk IGV4Y2x1ZGUgU1VCU0NSSUJFLA0KIE5PVElGWSwgUkVGRVIgYW5kIFBVQkxJU0guPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZy b206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2si PnNpcGNvcmUgJmx0O3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFNh bWlyIFNyaXZhc3RhdmEgJmx0O3NyaXZhc3RhdmFfc2FtaXI9NDBodXNoLmNvbUBkbWFyYy5pZXRm Lm9yZyZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCAxMyBNYXkgMjAyMCBhdCAxNi41 MTxicj4NCjxiPlRvOiA8L2I+U2FtaXIgU3JpdmFzdGF2YSAmbHQ7c3JpdmFzdGF2YV9zYW1pcj00 MGh1c2guY29tQGRtYXJjLmlldGYub3JnJmd0OywgJnF1b3Q7cGt5eml2YXRAYWx1bS5taXQuZWR1 JnF1b3Q7ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7LCBSb21hbiBTaHBvdW50ICZsdDty b21hbkB0ZWx1cml4LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NpcGNvcmVAaWV0Zi5v cmcmcXVvdDsgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbc2lwY29yZV0gU2Vzc2lvbiBUaW1lcnMgKFJGQyA0MDI4KSBmb3IgUkVGRVIsIFBVQkxJU0gs IE1FU1NBR0Ugbm90IGRlZmluZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+SGkgUGF1bCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDsgU1VCU0NSSUJFIC8gTk9USUZZ IGhhdmUgaGVhZGVycyBFeHBpcmVzLCBNaW4tRXhwaXJlIHRvIGhhbmRsZSBkaWFsb2cgY2xlYXJp bmcuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+U2FtaXIgU3JpdmFzdGF2YTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJs aW5lLWhlaWdodDoxNTAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtsaW5lLWhlaWdo dDoxNTAlO2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJsaW5lLWhlaWdodDoxNTAlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDts aW5lLWhlaWdodDoxNTAlO2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PjxhIGhyZWY9Imh0dHA6Ly9zYW1pcnNyaXZhc3RhdmEudHlwZXBhZC5jb20iPmh0dHA6Ly9zYW1p cnNyaXZhc3RhdmEudHlwZXBhZC5jb208L2E+PGJyPg0KPGJyPg0KT24gNS8xMy8yMDIwIGF0IDEx OjEzIEFNLCAmcXVvdDtTYW1pciBTcml2YXN0YXZhJnF1b3Q7ICZsdDtzcml2YXN0YXZhX3NhbWly PTQwaHVzaC5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7IHdyb3RlOg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4tbGVmdDo3LjVwdDtt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+SW4tbGluZSBwcmVmaXhlZCB3aXRoIFNTJmd0OyZndDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWln aHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3M8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWln aHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TYW1pciBT cml2YXN0YXZhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cDovL3NhbWlyc3JpdmFzdGF2YS50eXBlcGFkLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmh0dHA6Ly9zYW1pcnNyaXZhc3RhdmEudHlwZXBhZC5jb208L2E+PGJy Pg0KPGJyPg0KPGJyPg0KT24gNS8xMy8yMDIwIGF0IDM6MTUgQU0sICZxdW90O1BhdWwgS3l6aXZh dCZxdW90OyAmbHQ7cGt5eml2YXRAYWx1bS5taXQuZWR1Jmd0OyB3cm90ZTogPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA4LjBwdDttYXJnaW4tbGVmdDo3 LjVwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+T24gNS8xMi8yMCA1OjMwIFBNLCBSb21hbiBTaHBvdW50IHdyb3RlOjxicj4NCiZn dDsgU2FtaXIsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1vc3QgbGlrZWx5IE1pbi1TRSBhbmQgU2Vz c2lvbi1FeHBpcmVzIGhlYWRlcnMgaW4gJm5ic3A7UkVGRVIsIFBVQkxJU0gsIDxicj4NCiZndDsg TUVTU0FHRSB3b3VsZCBiZSBvdXQgb2Ygc2NvcGUgZm9yIDQwMjhiaXMuIFNvIGZhciB0aGVyZSB3 YXMgYW4gYWdyZWVtZW50IDxicj4NCiZndDsgdG8gbGltaXQgdGhlIHNjb3BlIG9mJm5ic3A7NDAy OGJpcyB0byBmaXhpbmcgaGFuZGxpbmcgb2YgbXVsdGlwbGUgPGJyPg0KJmd0OyB0cmFuc2FjdGlv bnMgd2hpY2ggbW9kaWZ5IFNlc3Npb24tRXhwaXJhdGlvbiBhdCB0aGUgc2FtZSB0aW1lIGFuZCA8 YnI+DQomZ3Q7IGFzc29jaWF0ZWQgcmFjZSBjb25kaXRpb25zLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBBbnkgb3RoZXIgY2hhbmdlcyB3b3VsZCBuZWVkIHRvIGdvIGludG8gYW5vdGhlciBSRkMuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFAuLlMuIFdoeSB3b3VsZCB5b3UgcHV0IE1pbi1TRSBhbmQgU2Vz c2lvbi1FeHBpcmVzIGludG8gUkVGRVIsIFBVQkxJU0gsIDxicj4NCiZndDsgTUVTU0FHRT8gVGhl c2UgaGVhZGVyIGZpZWxkcyBhcmUgb25seSBkZWZpbmVkIGZvciBJTlZJVEUvVVBEQVRFIG1lc3Nh Z2VzIDxicj4NCiZndDsgYW5kIG5vdCBhcHBsaWNhYmxlIGZvciBhbnkgb3RoZXIgbWVzc2FnZXMu PGJyPg0KPGJyPg0KUHV0dGluZyB0aGVtIGluICp0aGVzZSogbWVzc2FnZXMgd291bGQgYmUgbm9u c2Vuc2ljYWwgYmVjYXVzZSB0aGV5IGFyZSA8YnI+DQpuZWl0aGVyIGRpYWxvZyBlc3RhYmxpc2hp bmcgbm9yIGRpYWxvZyByZWZyZXNoaW5nLiBPVE9ILCBpdCB3b3VsZCBtYWtlIDxicj4NCnBlcmZl Y3Qgc2Vuc2UgdG8gdXNlIHRoZW0gaW4gU1VCU0NSSUJFL05PVElGWSBiZWNhdXNlIHRoZXkgKmFy ZSouIDxicj4NClNlc3Npb24gVGltZXIgaXMgYWJvdXQgbWFpbnRhaW5pbmcgdGhlIGRpYWxvZy4g SSB3b3VsZCB0aGluayBpdCB3b3VsZCBiZSA8YnI+DQplcXVhbGx5IGFwcGxpY2FibGUgdG8gdGhl c2Uga2luZHMgb2YgZGlhbG9nIHVzYWdlcy4gQnV0IHRoYXQgaXMgcHJvYmFibHkgPGJyPg0KZGVz ZXJ2aW5nIG9mIGRpc2N1c3Npb24uPGJyPg0KPGJyPg0KU1MmZ3Q7Jmd0OyZuYnNwOyBUaGVyZSBh cmUgb3RoZXIgbWVzc2FnZXMgaW4gdGhlIHRhYmxlIGZvciB3aGljaCB0aGVzZSBoZWFkZXJzIGFy ZSBub3QgYXBwbGljYWJsZS4gT24gdGhlIHNhbWUgbGluZSBtZW50aW9uIHRoZXNlIGhlYWRlcnMg YXJlIG5vdCBhcHBsaWNhYmxlIGZvciBSRUZFUiwgUFVCTElTSCwgTUVTU0FHRSBtZXRob2RzLiBN ZXNzYWdlcyBhcGFydCBmcm9tIChyZSlJbnYgYW5kIFVQRCBhcmUgb25seSBtZW50aW9uZWQgaW4g dGhlIHRhYmxlIGluIDQwMjhiaXMNCiBhbmQgUkZDIDQwMjguIDQwMjhiaXMgbWVudGlvbnMgaW4g dGhlIHRhYmxlIHRoYXQgdGhlc2UgaGVhZGVycyBhcmUgbm90IGFwcGxpY2FibGUgZm9yIFNVQlND UklCRSAvIE5PVElGWSBhbHNvLiZuYnNwOyZuYnNwOzxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpQ YXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_7A2F00254898402B8CF33BE2DA14E492ericssoncom_-- From nobody Wed May 13 12:25:29 2020 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 F1E373A0834 for ; Wed, 13 May 2020 12:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.4, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.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 xIyvrohv46SR for ; Wed, 13 May 2020 12:25:27 -0700 (PDT) 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 C09EE3A082B for ; Wed, 13 May 2020 12:25:26 -0700 (PDT) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id 04DJPLWi022822 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 13 May 2020 14:25:22 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1589397923; bh=RzBh4ayl+c3IAWVr8+dTVQ7Ll2WmzPnZL7qAoF6OpR4=; h=Subject:To:References:From:Date:In-Reply-To; b=kzzfkx2n82PM5vNEWnhfsoO2pJs6KLs+Ie97dtLw++vlc8XQJMaphBVO0i8ET3dxc PB5aqTUBAnKEGijAjDb0CdQ1i0HAu6uNi6J57hcsXo5pyY15UfWXAM985Ygane8aRl YeZ7q7AzsyFPy0paRWrIjnmup3tFv6VC1OnYy3sk= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Paul Kyzivat , Keith Drage , Samir Srivastava , sipcore@ietf.org References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> From: Adam Roach Message-ID: <078c4ae9-216b-a84c-de2d-ae7412e32947@nostrum.com> Date: Wed, 13 May 2020 14:25:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [sipcore] Deprecation of tabular format of header fields || Was Re: Session Timers (RFC 4028) for REFER, PUBLISH, MESSAGE not defined X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 May 2020 19:25:29 -0000 On 5/13/2020 7:45 AM, Paul Kyzivat wrote: > > Keith, > > I agree with all your points. The only sticky issue is that 3261 > contains normative language about the table. This could be fixed in a > bis, but I don't foresee a bis coming any time soon. Yep. That's why the conclusion in 2010 was to stop maintaining it, but not to go back and try to "fix" it for existing documents. The normativity in 3261 is worse than it seems at first: there is behavior that is normatively specified in Tables 2 & 3, and nowhere else -- so any fix would involve going through the table with a fine-toothed comb and ensuring that everything is specified in prose before removing it. /a From nobody Thu May 14 05:03:57 2020 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 DAF023A09AC for ; Thu, 14 May 2020 05:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 1vRJi2GDy4PE for ; Thu, 14 May 2020 05:03:53 -0700 (PDT) Received: from smtp2.hushmail.com (smtp2a.hushmail.com [65.39.178.237]) (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 2D8E63A09A9 for ; Thu, 14 May 2020 05:03:53 -0700 (PDT) Received: from smtp2.hushmail.com (localhost [127.0.0.1]) by smtp2.hushmail.com (Postfix) with SMTP id 6940EA0213 for ; Thu, 14 May 2020 12:03:52 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=1B5/mjP7ntKCTM7ThP45eMMrT1VR4PWvIVAvV3TicU0=; b=FJnrf+Ask+ma3Wz2WFta9lmhSSqeh4a96BaLNrArLPMmtnRcZr6UqYHoCVVNZQWyeJlN56s/sQZtLWcxN3qnck7jDtnV8ujTYjasEKvdJvZgZtJIW4QCkJiqb1tuGfMsD3V/W8BxRLLRGDjNXlYWLvZPWcr3ZfzwR603LeznFPKWJdVK1StJYXGu9kub19P6cDVVm0HsRiXXhld1ybBB8zQLCDXzCWl+zSKRPVg3fwEUql9Zaz1y7Cp+sXbnaCyAelIcWt0yf+jKVfXqvLnwnjKDCKqKyv8lfmVJ3f/IWf9laArJ+PeSMD0q6yQDoAYpOk7QLo0eVDm/Z5jMAn0O0A== Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp2.hushmail.com (Postfix) with ESMTPS for ; Thu, 14 May 2020 12:03:52 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id EEBD6406C0; Thu, 14 May 2020 12:03:51 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 14 May 2020 18:03:51 +0600 To: sipcore@ietf.org From: "Samir Srivastava" In-Reply-To: References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="=_4a8c48031f7d939d232e34517a1f4407" Message-Id: <20200514120351.EEBD6406C0@smtp.hushmail.com> Archived-At: Subject: [sipcore] Change log for 4028bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 12:03:55 -0000 --=_4a8c48031f7d939d232e34517a1f4407 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, 4028bis should provide the changes done with respect to RFC 4028. Like RFC 3261 provide changes done with respect 2543. Thanks Samir Srivastava http://samirsrivastava.typepad.com --=_4a8c48031f7d939d232e34517a1f4407 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,=

  4028bis should provide the changes done with res= pect to RFC 4028. Like RFC 3261 provide changes done with respect 2543.

Thanks 

Samir Srivastav= a

--=_4a8c48031f7d939d232e34517a1f4407-- From nobody Thu May 14 06:54:11 2020 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 B88543A07E9 for ; Thu, 14 May 2020 06:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 ggEmJ8aa1WZo for ; Thu, 14 May 2020 06:54:07 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.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 8FDF73A0810 for ; Thu, 14 May 2020 06:54:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QnGKjiPYrG07WmTva//tLmU0Lgjy8K8kQYRd1ngqG6cZXb3iX8sKZId+pv3aGI9y/64MJrwgserDMeYx/4T+w7xO1aor+Do/1s/SuO4jXdaggNR8H9qBYj4IXimbrei+npMNcf1sQJmi4lav6I6nAm3JW/5fFuXMRCIQ5OaRwt9BCf1ox2TVM4nkfLHz1Yr5MYfE1k2ywBVKMiSBjdqmDWhcRoaaE46j99yWqSR4e3u6tTT2Mo4a6OdISOeuU9uES1CT7GKDQJV/DOcKkKh/ujO6JsQeazd+KIG/YoC+SUB8mDjcbxodi9tMoUSFb0UxWuLhG+RGjMQfEqX6fJHYwg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PI+f6MegG0gB/WF5YqsEjVKlLD/Kw7eUqN1qEhVa/Z4=; b=W6GqgSIp1cI87ZTrx5f6RT6InCo14PaaMaMDR1flYajJDl25yWrzKdOnbONBs1pY/PbYt983nslYYPUGyHVRhAXAGfdNnJnuXGxbDux7OERqJItYk2stBb4mSKs2/v7IBsyFb7YQguaB6FVgya5cJMNeK8h1sR7Vd59kAZv7Axc4xE9SrNZhaAAgW++PhByC+IqAxW6+/KdxCfjEFaFyHdcLBTvDfpuPIskcHkjpnDmkgDrTGE+lNUMVFHQQhn6teBl0J+iWTGYGVE2G6RkpKcWUnd0tOLBiLUd+pTPZOxgQid2zvrKoyHRzMp7zuqjAsl489J2imlSZO6WBikDVYQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PI+f6MegG0gB/WF5YqsEjVKlLD/Kw7eUqN1qEhVa/Z4=; b=qyD1iCTej+dcBzINfmJizorwbAM5VhNmr4iJmLGCdpwNS7icgqzojgOFZ4Wgx0K5FXYLE15MV+O2IBVczBtSgsfdM167MSs0P2H2ZgUwSae2DfJhmenUWIXwAm4++/ZbtHi2Ja/2HK1ZuZ3SOFHzs4UKX4qiNtyRvySUoHhu6VE= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6961.eurprd07.prod.outlook.com (2603:10a6:20b:1b4::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.12; Thu, 14 May 2020 13:54:04 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Thu, 14 May 2020 13:54:04 +0000 From: Christer Holmberg To: Samir Srivastava , "sipcore@ietf.org" Thread-Topic: [sipcore] Change log for 4028bis Thread-Index: AQHWKefIMUSYEYIrAkGNVkv8xrNGBqinzLuA Date: Thu, 14 May 2020 13:54:03 +0000 Message-ID: <0251C7EB-240A-4F8E-A510-E5884ADE6265@ericsson.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> <20200514120351.EEBD6406C0@smtp.hushmail.com> In-Reply-To: <20200514120351.EEBD6406C0@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e258570b-4a97-4243-5cbb-08d7f80e436b x-ms-traffictypediagnostic: AM7PR07MB6961: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QKJ/B8ZZbgjb6hiQv859KXAjmVih7pjDjFB35OW0M3D4+vBrDYaCgNcHVGHmgBcsXBJjjUQdAKAKfqL3I/W9bXQiGeaC46GeYOU+hr1ILaPtRde0vxVXv0ONGTsNDhlYx/o4f1LDkjFq780eT2XnBdCYcvcVwXz5Lh5AYRZI7MKYOP/CZnB7aRuW+QZ2a3MF9XLYC3X6cUw4mgINVDOuS07GqRcYvW3WHn2Tty1MnPoLtQNc8l4j86ElaIJH0EIH5678EfMg+n/PdsTvM/2Vf8pXN6JE5VF9SGRTzuAMzwdSZgLYr6eGQSk/gCi1gm2Gci8e6sIZVvhFJPUfu7pNznif+1M1Kz54iW6XdznMQ5yTLGwbXVWdBtdp0uroFxyDniaA4QV1kIJjEFrp1ObcSg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(376002)(136003)(396003)(346002)(39860400002)(2616005)(6512007)(2906002)(4744005)(166002)(44832011)(316002)(110136005)(66446008)(36756003)(66946007)(6486002)(76116006)(66476007)(64756008)(66556008)(91956017)(5660300002)(8936002)(71200400001)(186003)(26005)(6506007)(86362001)(966005)(8676002)(33656002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: ywPE3LhKewXt6SMJ3YiiyUX/qTs4x/+d8/z3KSWymuXshembOJqv8ME/EVwJk2pEIJEkKbFcDGWKeLwJ6JTib8E+cnJxDsd9IAeM6wEZbriR4RCwB4rj5UKFBIW/KdK76pQv+xcsu3+qXeQoiZsaz7l/9p8E5ZFkyXk1seUi7+lwhiCrG8JcYuFUjDrgqo1uXZE7HzIjA+GLMt7Utxh/hyijYpoik2xsbYYdVMLHihUeqouO8l/g+jGZGswem+AxvmuF5fTWtDcZ3W9ZOrCzYZqQfrO1NjHDc/fUCTrBBX3WafF+EPUWgjFVkrn6qaxQYQ2SImp0qucABZXWNi94Cg03ZNzwZYchAmcfFgUbaDF9Z60eresfmYt4P9cecf+WXRGcluNPXApwGvmGDh3wYukS+7iY9Swml5heyIn/CrlC4WWvsO2BQMTKEoocuvaHkM+P/8ej5EFPBKkecfnvoaU2M5nbe/TTbvkT2I71L5P54i/VlShu/ljzDrXmoeU4 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_0251C7EB240A4F8EA510E5884ADE6265ericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: e258570b-4a97-4243-5cbb-08d7f80e436b X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 13:54:03.9857 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Z+kQPkjFyvgQHBCd/azsTGm+wPH+uzGmLk2dunH1U9RXXPOTh34a45YpxVfiwLeM5oTRp95jVYmpcqmopYrc6gDcwP5uOQWtoWieXQJ1l9k= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6961 Archived-At: Subject: Re: [sipcore] Change log for 4028bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 13:54:10 -0000 --_000_0251C7EB240A4F8EA510E5884ADE6265ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gYnkg4oCccHJv dmlkZSB0aGUgY2hhbmdlcyB3aXRoIHJlc3BlY3QgdG8gUkZDIDQwMjjigJ0uDQoNClJlZ2FyZHMs DQoNCkNocmlzdGVyDQoNCkZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4g b24gYmVoYWxmIG9mIFNhbWlyIFNyaXZhc3RhdmEgPHNyaXZhc3RhdmFfc2FtaXI9NDBodXNoLmNv bUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCAxNCBNYXkgMjAyMCBhdCAxNS4wNA0K VG86ICJzaXBjb3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4NClN1YmplY3Q6IFtzaXBj b3JlXSBDaGFuZ2UgbG9nIGZvciA0MDI4YmlzDQoNCkhpLA0KDQogIDQwMjhiaXMgc2hvdWxkIHBy b3ZpZGUgdGhlIGNoYW5nZXMgZG9uZSB3aXRoIHJlc3BlY3QgdG8gUkZDIDQwMjguIExpa2UgUkZD IDMyNjEgcHJvdmlkZSBjaGFuZ2VzIGRvbmUgd2l0aCByZXNwZWN0IDI1NDMuDQoNClRoYW5rcw0K DQpTYW1pciBTcml2YXN0YXZhDQoNCmh0dHA6Ly9zYW1pcnNyaXZhc3RhdmEudHlwZXBhZC5jb20N Cg== --_000_0251C7EB240A4F8EA510E5884ADE6265ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <7A5D8507978F1240A4B1E275132628ED@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tRkki IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkg YW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gYnkg4oCccHJvdmlkZSB0aGUg Y2hhbmdlcyB3aXRoIHJlc3BlY3QgdG8gUkZDIDQwMjjigJ0uPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5DaHJp c3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNpcGNvcmUgJmx0 O3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFNhbWlyIFNyaXZhc3Rh dmEgJmx0O3NyaXZhc3RhdmFfc2FtaXI9NDBodXNoLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+ DQo8Yj5EYXRlOiA8L2I+VGh1cnNkYXksIDE0IE1heSAyMDIwIGF0IDE1LjA0PGJyPg0KPGI+VG86 IDwvYj4mcXVvdDtzaXBjb3JlQGlldGYub3JnJnF1b3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc2lwY29yZV0gQ2hhbmdlIGxvZyBmb3IgNDAyOGJpczxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1o ZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5IaSwN CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1o ZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj4mbmJzcDsgNDAyOGJpcyBzaG91bGQgcHJvdmlkZSB0aGUgY2hhbmdlcyBkb25lIHdpdGgg cmVzcGVjdCB0byBSRkMgNDAyOC4gTGlrZSBSRkMgMzI2MSBwcm92aWRlIGNoYW5nZXMgZG9uZSB3 aXRoIHJlc3BlY3QgMjU0My48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUwJTtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1o ZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1oZWlnaHQ6MTUw JTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibGluZS1oZWlnaHQ6MTUwJSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7bGluZS1o ZWlnaHQ6MTUwJTtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TYW1p ciBTcml2YXN0YXZhPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1MCUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2xpbmUtaGVpZ2h0OjE1MCU7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0iaHR0cDovL3NhbWlyc3JpdmFzdGF2YS50 eXBlcGFkLmNvbSI+aHR0cDovL3NhbWlyc3JpdmFzdGF2YS50eXBlcGFkLmNvbTwvYT48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0251C7EB240A4F8EA510E5884ADE6265ericssoncom_-- From nobody Thu May 14 07:05:41 2020 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 C116F3A0A63 for ; Thu, 14 May 2020 07:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 089wFl6_LalT for ; Thu, 14 May 2020 07:05:35 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) (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 4C2AA3A0A67 for ; Thu, 14 May 2020 07:05:35 -0700 (PDT) Received: from smtp10.hushmail.com (localhost [127.0.0.1]) by smtp10.hushmail.com (Postfix) with SMTP id DC5B0C032A for ; Thu, 14 May 2020 14:05:34 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=FnMLuvnBykrRGQl3HaDXqzSYW+J/N0rChbL8NCG3syY=; b=A/NCKMlpJe3tlLapoR8LMpb8RkZNtJGx8/jcCFSPE0pNVCb12MQCwrGEqtMmW00NsU7IuL3spWuAXMi4F2JKyXjUYlMT+VMCC3E0uUTMQAvgB6C/9gFD1xbYlYFyyDSnjAV8DEeRwvxKzaaKU9mB2zaKnn5zyDEmi35eF373AMtwSkh+O7OHD6Eg7IbFlJh9uH33iOxxFxB/RCY7XQl1HiE67uzRq87IVmnAEb+OJhc7CJ7PhewDCCMjkS+6SrLE2MgcidgHCrjQ0woRaUsT7f3xlBNnjNq/Y56deCwbzAiDujj4/i3jamJCeE5CwLlr45Ymsv+0u5MVuEWfpE/rIQ== Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp10.hushmail.com (Postfix) with ESMTPS; Thu, 14 May 2020 14:05:34 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 2BE5640685; Thu, 14 May 2020 14:05:34 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 14 May 2020 20:05:33 +0600 To: "Christer Holmberg" , sipcore@ietf.org From: "Samir Srivastava" In-Reply-To: <0251C7EB-240A-4F8E-A510-E5884ADE6265@ericsson.com> References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> <20200514120351.EEBD6406C0@smtp.hushmail.com> <0251C7EB-240A-4F8E-A510-E5884ADE6265@ericsson.com> Content-Type: multipart/alternative; boundary="=_ef9b3ad61e87bed205b9273d40ff0666" Message-Id: <20200514140534.2BE5640685@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] Change log for 4028bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:05:39 -0000 --=_ef9b3ad61e87bed205b9273d40ff0666 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, Suppose I support RFC 4028, And I want to support your new RFC which is in bis form now. Instead of going through the minute details of your new RFC as a whole, I focus on the changes done in the new RFC with respect to 4028. I am looking something similar to Chapter 28 of RFC 3261. Where it lists the details of changes done with respect earlier SIP RFC 2543. Thanks Samir Srivastava http://samirsrivastava.typepad.com On 5/14/2020 at 7:24 PM, "Christer Holmberg" wrote: Hi, I am not sure I understand what you mean by “provide the changes with respect to RFC 4028”. Regards, Christer From: sipcore on behalf of Samir Srivastava Date: Thursday, 14 May 2020 at 15.04 To: "sipcore@ietf.org" Subject: [sipcore] Change log for 4028bis Hi, 4028bis should provide the changes done with respect to RFC 4028. Like RFC 3261 provide changes done with respect 2543. Thanks Samir Srivastava http://samirsrivastava.typepad.com --=_ef9b3ad61e87bed205b9273d40ff0666 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,=

  Suppose I support RFC 4028, And I want to suppor= t your new RFC which is in bis form now. Instead of going through the = minute details of your new RFC as a whole, I focus on the changes done in = the new RFC with respect to 4028. 

  I a= m looking something similar to Chapter 28 of RFC 3261. Where it lists the d= etails of changes done with respect earlier SIP RFC 2543.

  Thanks

   Samir Srivastav= a




On 5/14/2020 at 7:24 PM, "Christer Holmberg" <christer.holmberg= =3D40ericsson.com@dmarc.ietf.org> wrote:

Hi,

 

I am not sure I unde= rstand what you mean by =E2=80=9Cprovide the changes with respect to RFC 40= 28=E2=80=9D.

 

Regards,

 

Christer

 

From: = sipcore <sipcore-b= ounces@ietf.org> on behalf of Samir Srivastava <srivastava_samir=3D40= hush.com@dmarc.ietf.org>
Date: Thursday, 14 May 2020 at 15.04
To: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [sipcore] Change log for 4028bis

 

Hi,

 

  4028bis should provide the changes done w= ith respect to RFC 4028. Like RFC 3261 provide changes done with respect 25= 43.

 

Thanks 

 

Samir Srivastava

 

 --=_ef9b3ad61e87bed205b9273d40ff0666-- From nobody Thu May 14 07:08:32 2020 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 50E6F3A0ACE for ; Thu, 14 May 2020 07:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 4KlZmbd_Z6O0 for ; Thu, 14 May 2020 07:08:29 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70043.outbound.protection.outlook.com [40.107.7.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 2F20E3A0AC8 for ; Thu, 14 May 2020 07:08:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c9NoI/OKA2/N4YvBeGZMWo5nD16+qc+y0ISniMFRHF/7imbMhYLk2Fz19vB2mBnrZWNoyUsm7JcXJwBT899S5bAXdtXKaGz+tRpK09I8oF/8CMjdJHQp+JPmKr+UTaU8z7ttEIlzkhhx8nMsS1JFQtRI3cq3f9T9Nc2RwqrbxZiXUJcOsxz253YyB08F/hsO+JG8HUzKCUmleSFg0wtxRu7/RbA4CG1OwHXEDOoUfIvvf9VjuuUf1TIHmNSWFoH/CNiUXLiQZlOl4QCjUsLlkEm3wMIWKGzgLMCU5Y7HXop1ELGJKmzo/ZXFJQkkM5aw4v7vrQG9T+uBo5MuY1N7kQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dVZmgHh8bRQ2UYYCusPMznyEwxhUXGzoiQnFwPAsNd0=; b=mxpVtWTc0LF+pId5QSzlQpzovv9WY9xesQL8wZdCFLvmLVGM1SIOdI4JsFaK8jhko9CfVWq2jQMtgB9sRZCOdtdXmeQg1GF0VgrqNKtDF2U2YbjyI0qrwejgAiLV+R0gNWNiOgAGGVv1F4IDKetDB8FByrbmfuOzcYvYnPAaQfEl/Xx9ruqlDS43NiAMKBu2kuItgeaIUYlW3gIT0hLZfJzVYJ/xCIXoIAhRgq52TQJNLNG940SJaXkRsBg0QfGxzZG3M146xjoqaB2mmCiDRLnU+2UNHUg8+q/SrBOq9TydlVYmdIJjbcgJmq7AZYmHbxoPiZsM+GOZvDKTUYpXxA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dVZmgHh8bRQ2UYYCusPMznyEwxhUXGzoiQnFwPAsNd0=; b=GatMGywVwILJwe8Yh87SbT8N2aK9GM4FQQ0L+IpA0hIl5NTiK18Ikmz3aXa8wYJ+3sCKf6GeS8/SY23ikQKBnU9UzIg2k3imPz2xPPYWgkG7i/2ZC5kqJOvBaugAt5zD7rjTJDdSVhq/SBZfzrCO57e3Gu60edQgR0ugeEE1Su4= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6596.eurprd07.prod.outlook.com (2603:10a6:20b:1a3::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.12; Thu, 14 May 2020 14:08:22 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Thu, 14 May 2020 14:08:22 +0000 From: Christer Holmberg To: Roman Shpount , Christer Holmberg CC: "sipcore@ietf.org" Thread-Topic: [sipcore] 4028bis: memory refresh - proxy assumptions Thread-Index: AQHWKfkgEYFa8+7770udXBuctBvBEg== Date: Thu, 14 May 2020 14:08:22 +0000 Message-ID: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4584b2f2-029c-44b9-fd66-08d7f8104328 x-ms-traffictypediagnostic: AM7PR07MB6596: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1X5Ej5FbCXSMc/viJi+RFpkOP/X2f5NHytIemlgRBmDPMTIcbsqy47/U3s6RRU/vFU0qgi+gRxh+KW/SKTOS1tjoEgs3AH16N0z3p8EeanoLaiUBd1DaGrs9+1o0OdYpGobmFztKY2wOB6DCRRMgZTgEtxnqy62nFMLQz2PBL9T5BIaUzorYk3r1xDFmTnX5tILOp9HvGQ9sDUyPBTx3/Z7mKcsU++zIYvjxjkDR2ZktZBUWSJhoQp/5a8QqEjANrfM9/7VQKNO6NaHXYKOeYF81Hzeq3Y7k8mT2T6rAvhGLFcfqY5OzR3MLCr9Ov46Mbn0MDqp4LRlpmJQ9J8pWRNFkjNIbSugrf5tWlfe+R5bWqv2/PnLR7URRrU300dvVFvcqYEAV2koWSsqV2RCXEg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(376002)(136003)(366004)(6512007)(4326008)(36756003)(91956017)(6486002)(33656002)(8676002)(166002)(86362001)(8936002)(5660300002)(2906002)(478600001)(6506007)(53546011)(966005)(2616005)(44832011)(66476007)(64756008)(66446008)(66556008)(26005)(71200400001)(316002)(76116006)(186003)(66946007)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: d/BaMhekd3VdM+LWCFbhngLL1V13sAiXrbYrd7uDkPtRsEuGFZXVyEHx68BrDyMeQzReSSW7OmxIGl/ZsDqLlQQKShZOuEiLdmbO039NnDImM4wLXotNYvdmqVIWPtYg2IawzsuDwFIzDSTH7BsewX/f/PEJr0iWO3fwGyov+0X+gQ6yEomnZzyZ9TLCJa24jQysv562eNaTLlo1L2EciSqJKO2rFBxF8t1eaLgGUoyMlpEGe2JppRcT6Bs5yAXmSeIRLkTlCCItBNvPcOIHOEo49ySa0+FEn9/jasAjRghbwmFWqWkR6HViZ6LwKulprUuf0jaBrTD0XKxbjL8s/zOajMjzkdvUva+G8p4d0FvFDDY1OADhme9SnnfsyPYsviecXJmaA52IfVkJBp7rpoODg98ydnQT0X74i6vPxytBrOhquV78tu9i8yf/wo40+mzLMVlc/AgC7S/bhrkOWz2acsQrwr4DOXH4NQyAJ0fHz931VQnZiIOQMPoYXbMc x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_3A3E112FC60F43EBA2ADAA89597674AAericssoncom_" MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4584b2f2-029c-44b9-fd66-08d7f8104328 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 14:08:22.5333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ozwk78mPvkIB/PjCmGQNWIoVDPkNNok0PuPCxqlufGy2xCmKmqSg/Zrn26nOKqD/afvBk5MSics38E3LZqD8OPDZdtFhBS0/UDtfWltO4cE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6596 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:08:31 -0000 --_000_3A3E112FC60F43EBA2ADAA89597674AAericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCj5JIGhhdmUgdHdvIGlzc3VlcyB3aXRoIHRoaXMgcHJvcG9zYWw6DQo+DQo+MS4gRGVm aW5pbmcgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2aW5nIGEgdHJhbnNhY3Rpb24gaW4gcHJv Z3Jlc3M6IFRoaXMgaXMgaGFyZCB0byBpbXBsZW1lbnQgaW4gcHJhY3RpY2Ugc2luY2UgaW5pdGlh bCBJTlZJVEUgYW5kIFVQREFURQ0KPm1pZ2h0IG5vdCBldmVuIGdvIG92ZXIgdGhlIHNhbWUgcGF0 aCBhbmQgdGhlIHNhbWUgcHJveGllcy4NCg0KU2VjdGlvbiA4IG9mIFJGQyA0MDI4IHNheXM6DQoN CiAgIOKAnFByb3hpZXMgdGhhdCBhc2sgZm9yIHNlc3Npb24gdGltZXJzIFNIT1VMRCByZWNvcmQt cm91dGUsIGFzIHRoZXkNCiAgIHdvbid0IHJlY2VpdmUgcmVmcmVzaGVzIGlmIHRoZXkgZG9uJ3Qu 4oCdDQoNCkluIG15IG9waW5pb24gaXQgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIG1hbmRhdGUgdGhh dCBhIHByb3h5IHRoYXQgYXNrcyBmb3Igc2Vzc2lvbiB0aW1lcnMsIG9yIG1vZGlmaWVzIGEgc2Vz c2lvbiB0aW1lciB2YWx1ZSAoUy1FIG9yIE1pbi1TRSksIGFsc28gcmVjb3JkLXJvdXRlLg0KDQpS ZWdhcmRzLA0KDQpDaHJpc3Rlcg0KDQoNCg0KDQoNCg0KT24gTW9uLCBNYXkgMTEsIDIwMjAgYXQg MTE6NTIgQU0gQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnPTQwZXJpY3Nzb24u Y29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZz4+ IHdyb3RlOg0KSGksDQoNCkFuZCwgaWYgeW91IGZvciB3aGF0ZXZlciByZWFzb24gcmF0aGVyIHdh dGNoIFRpZ2VyIEtpbmcgdGhhbiB0aGUgSUVURiAxMDIgU0lQQ09SRSBzZXNzaW9uLCBiZWxvdyBp cyBiYXNpY2FsbHkgd2hhdCB3YXMgc3VnZ2VzdGVkIGluIG9yZGVyIHRvIHNvbHZlIHRoZSBzZXNz aW9uLXRpbWVyIGdsYXJlIHNpdHVhdGlvbjoNCg0KDQpVQUM6DQoNCg0KLSAgICAgICAgICBJZiBh IFVBIGluc2VydHMgUy1FIGluIGFuIElOVklURSByZXF1ZXN0IHRoZSBVQSBNVVNUIGluc2VydCB0 aGUgc2FtZSBTLUUgaW4gYW55IFVQREFURSByZXF1ZXN0IGl0IHNlbmRzIHdoaWxlIHRoZSBJTlZJ VEUgdHJhbnNhY3Rpb24gaXMgb25nb2luZw0KDQotICAgICAgICAgIElmIGEgVUEgaGFzIGNvbmZs aWN0aW5nIFMtRSBpbmZvcm1hdGlvbiBvbmNlIHRoZSBJTlZJVEUgYW5kIFVQREFURSB0cmFuc2Fj dGlvbiBoYXZlIGNvbXBsZXRlZCwgaXQgTVVTVCBzZW5kIGEgbmV3IFVQREFURSB3aXRoIFMtRSwg aW4gb3JkZXIgdG8g4oCcc3luY+KAnSB0aGUgUy1FIHN0YXRlIGFtb25nIGFsbCBlbnRpdGllcw0K DQoNClBST1hZOg0KDQpSZXF1ZXN0IGhhbmRsaW5nOg0KDQotICAgICAgICAgIE1VU1QgcmVqZWN0 IHRoZSByZXF1ZXN0IGlmIHRoZSBTLUUgdmFsdWUgaXMgdG9vIHNtYWxsDQoNCm8gICBObyBtYXR0 ZXIgaWYgdGhlIHJlcXVlc3QgY29udGFpbnMgU3VwcG9ydGVkOnRpbWVyIG9yIG5vdA0KDQotICAg ICAgICAgIElmIHRoZSBwcm94eSBpbnNlcnRzL2ZvcndhcmRzL21vZGlmaWVzIHRoZSBTLUUgaW4g YW4gSU5WSVRFIHJlcXVlc3QgdGhlIHByb3h5IE1VU1QgaWRlbnRpY2FsbHkgaW5zZXJ0L2Zvcndh cmQvbW9kaWZ5IHRoZSBzYW1lIFMtRSBpbiBhbnkgVVBEQVRFIHJlcXVlc3QNCg0KbyAgIFRoZSBw cm94eSBNQVkgaW5zZXJ0L21vZGlmeSB0aGUgUy1FIGlmIGl0IGtub3dzIHRoYXQgdGhlcmUgaXMg bm8gYWN0aXZlIElOVklURSB0cmFuc2FjdGlvbg0KDQpSZXNwb25zZSBoYW5kbGluZzoNCg0KLSAg ICAgICAgICBJZiByZXNwb25zZSBjb250YWlucyBTLUUsIHRoZSBwcm94eSBNVVNUIE5PVCBtb2Rp ZnkgaXQNCg0KLSAgICAgICAgICBJZiByZXNwb25zZSBkb2VzIG5vdCBjb250YWluIFMtRSwgdGhl IHByb3h5IE1BWSBpbnNlcnQgUy1FIGlmIGl0IHJlbWVtYmVycyB0aGF0IHRoZSBhc3NvY2lhdGVk IHJlcXVlc3QgY29udGFpbmVkIFN1cHBvcnRlZDp0aW1lcg0KDQpVQVM6DQoNCg0KLSAgICAgICAg ICBJZiByZXF1ZXN0IGNvbnRhaW5zIFMtRToNCg0KbyAgIFRoZSBVQVMgY29waWVzIHRoZSBTLUUg dmFsdWUgb2YgdGhlIHJlcXVlc3QgaW50byB0aGUgcmVzcG9uc2UNCg0KbyAgIFRoZSBVQVMgTVVT VCBOT1QgcmVkdWNlIHRoZSBTLUUgdmFsdWUgaW4gdGhlIHJlc3BvbnNlDQoNCuKAoiAgSWYgdGhl IFVBUyB3YW50cyB0byBjaGFuZ2UgdGhlIFMtRSB2YWx1ZSwgaXQgbGF0ZXIgc2VuZHMgYSByZXF1 ZXN0IGJ5IGl0cyBvd24NCg0KLSAgICAgICAgICBJZiB0aGUgcmVxdWVzdCBkb2VzIG5vdCBjb250 YWluIFMtRToNCg0KbyAgIElmIHRoZSByZXF1ZXN0IGNvbnRhaW5zIFN1cHBvcnRlZDp0aW1lciwg dGhlIFVBUyBNQVkgaW5jbHVkZSBTLUUgaW4gdGhlIHJlc3BvbnNlDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KRnJvbTogc2lwY29yZSA8c2lwY29yZS1ib3VuY2VzQGlldGYuLm9yZzxtYWls dG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIENocmlzdGVyIEhvbG1i ZXJnIDxjaHJpc3Rlci5ob2xtYmVyZz00MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCAxMSBNYXkg MjAyMCBhdCAxNC4zNg0KVG86ICJzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYu b3JnPiIgPHNpcGNvcmVAaWV0Zi5vcmc8bWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmc+Pg0KU3ViamVj dDogW3NpcGNvcmVdIDQwMjhiaXM6IG1lbW9yeSByZWZyZXNoDQoNCkhpLA0KDQpOb3csIHdoZW4g dGhlIHNpcC1vYXV0aCBkcmFmdCBpcyBtb3JlIG9yIGxlc3MgZG9uZSAoaW4gdGhlIFJGQyBlZGl0 b3LigJlzIHF1ZXVlKSwgSSBpbnRlbmQgdG8gdGFrZSB1cCB0aGUgd29yayBvbiA0MDI4YmlzIChz ZXNzaW9uLXRpbWVyKSBhZ2Fpbi4NCg0KV2UgcHJldmlvdXNseSBoYWQgZS1tYWlsIGRpc2N1c3Np b25zIGFuZCBwaG9uZSBjYWxscywgdGhlcmUgaXMgYW4gaXNzdWUgdHJhY2tlciBvbiBHaXRIdWIs IGFuZCB3ZSBkaXNjdXNzZWQgdGhlIHN1Z2dlc3RlZCBzb2x1dGlvbnMgYXQgSUVURiMxMDMuIFRv IHJlZnJlc2ggeW91ciBtZW1vcnksIHBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUgdmlkZW86IGh0 dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9QzJ5ZWNrQm1nUGcgKHRoZSBzZXNzaW9uLXRp bWVyIHByZXNlbnRhdGlvbiBiZWdpbnMgYXQgYXJvdW5kIDc6MzAgbWludXRlcykuDQoNClRoZSBk ZWNpc2lvbiB0byBtYWtlIGEgYmlzIChpbnN0ZWFkIG9mIGFuIHVwZGF0ZSBkcmFmdCkgaGFzIGFs cmVhZHkgYmVlbiBtYWRlLCBidXQgcGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSB0ZWNobmljYWwg c3VnZ2VzdGlvbnMgZm9yIGZpeGluZyB0aGUgZ2xhcmUgc2l0dWF0aW9uLg0KDQpSZWdhcmRzLA0K DQpDaHJpc3Rlcg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3Jl QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQo= --_000_3A3E112FC60F43EBA2ADAA89597674AAericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <093386145BD24348AB798CCB00584B80@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnAuZ21haWwtbTYxOTUzMDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBo LCBsaS5nbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFp bC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6 Z21haWwtbV82MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFwaDsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1GSSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRkkiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRkkiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jmd0Ozwvc3Bhbj5JIGhhdmUgdHdvIGlzc3VlcyB3aXRoIHRoaXMgcHJvcG9zYWw6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PC9zcGFuPjEuIERlZmlu aW5nIHByb3h5IGJlaGF2aW9yIGJhc2VkIG9uIGhhdmluZyBhIHRyYW5zYWN0aW9uIGluIHByb2dy ZXNzOiBUaGlzIGlzIGhhcmQgdG8gaW1wbGVtZW50IGluIHByYWN0aWNlIHNpbmNlIGluaXRpYWwg SU5WSVRFIGFuZCBVUERBVEU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PC9zcGFuPm1pZ2h0IG5vdCBldmVuIGdvIG92ZXIgdGhlIHNh bWUgcGF0aCBhbmQgdGhlIHNhbWUgcHJveGllcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+U2VjdGlvbiA4IG9mIFJG QyA0MDI4IHNheXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7IOKAnDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+UHJveGllcyB0aGF0IGFzayBmb3Ig c2Vzc2lvbiB0aW1lcnMgU0hPVUxEIHJlY29yZC1yb3V0ZSwgYXMgdGhleTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJz cDsmbmJzcDsgd29uJ3QgcmVjZWl2ZSByZWZyZXNoZXMgaWYgdGhleSBkb24ndC48L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBteSBvcGluaW9uIGl0IHNob3VsZCBiZSBw b3NzaWJsZSB0byBtYW5kYXRlIHRoYXQgYSBwcm94eSB0aGF0IGFza3MgZm9yIHNlc3Npb24gdGlt ZXJzLCBvciBtb2RpZmllcyBhIHNlc3Npb24gdGltZXIgdmFsdWUgKFMtRSBvciBNaW4tU0UpLCBh bHNvIHJlY29yZC1yb3V0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlJlZ2FyZHMsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5DaHJpc3RlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBNYXkgMTEsIDIwMjAgYXQgMTE6NTIgQU0gQ2hyaXN0 ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnPTxhIGhyZWY9Im1haWx0bzo0MGVyaWNz c29uLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+SGksPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+QW5kLCBpZiB5b3UgZm9yIHdoYXRldmVyIHJlYXNvbiByYXRoZXIgd2F0Y2gg VGlnZXIgS2luZyB0aGFuIHRoZSBJRVRGIDEwMiBTSVBDT1JFIHNlc3Npb24sIGJlbG93IGlzIGJh c2ljYWxseSB3aGF0IHdhcyBzdWdnZXN0ZWQgaW4gb3JkZXIgdG8gc29sdmUgdGhlIHNlc3Npb24t dGltZXINCiBnbGFyZSBzaXR1YXRpb246PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG SSI+VUFDOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRkkiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgYSBVQSBpbnNlcnRzIFMt RSBpbiBhbiBJTlZJVEUgcmVxdWVzdCB0aGUgVUEgTVVTVCBpbnNlcnQgdGhlIHNhbWUgUy1FIGlu IGFueSBVUERBVEUgcmVxdWVzdCBpdCBzZW5kcyB3aGlsZSB0aGUgSU5WSVRFIHRyYW5zYWN0aW9u IGlzIG9uZ29pbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYxOTUz MDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oyxz ZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPklmIGEgVUEgaGFzIGNvbmZsaWN0aW5nIFMt RSBpbmZvcm1hdGlvbiBvbmNlIHRoZSBJTlZJVEUgYW5kIFVQREFURSB0cmFuc2FjdGlvbiBoYXZl IGNvbXBsZXRlZCwgaXQgTVVTVCBzZW5kIGEgbmV3IFVQREFURSB3aXRoIFMtRSwgaW4gb3JkZXIg dG8g4oCcc3luY+KAnSB0aGUgUy1FIHN0YXRlIGFtb25nIGFsbCBlbnRpdGllczwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlBST1hZOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDoxOC4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPlJlcXVlc3QgaGFuZGxpbmc6PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3Nzc4bXNvbGlzdHBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+LTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTom cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij5NVVNUIHJlamVjdCB0aGUgcmVxdWVzdCBpZiB0aGUgUy1FIHZhbHVlIGlzIHRvbyBzbWFsbDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3 OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+bzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZuYnNwOyZuYnNwOw0KPC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj5ObyBtYXR0ZXIgaWYgdGhlIHJlcXVlc3QgY29udGFpbnMgU3Vw cG9ydGVkOnRpbWVyIG9yIG5vdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlIHByb3h5IGluc2Vy dHMvZm9yd2FyZHMvbW9kaWZpZXMgdGhlIFMtRSBpbiBhbiBJTlZJVEUgcmVxdWVzdCB0aGUgcHJv eHkgTVVTVCBpZGVudGljYWxseSBpbnNlcnQvZm9yd2FyZC9tb2RpZnkgdGhlIHNhbWUgUy1FIGlu IGFueSBVUERBVEUgcmVxdWVzdDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFp bC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDo3Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYi PiZuYnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgcHJveHkgTUFZIGlu c2VydC9tb2RpZnkgdGhlIFMtRSBpZiBpdCBrbm93cyB0aGF0IHRoZXJlIGlzIG5vIGFjdGl2ZSBJ TlZJVEUgdHJhbnNhY3Rpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTguMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIj5SZXNwb25zZSBoYW5kbGluZzo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i Z21haWwtbTYxOTUzMDkwNDQwMjM5OTc3Nzhtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4tPC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHJlc3BvbnNlIGNv bnRhaW5zIFMtRSwgdGhlIHByb3h5IE1VU1QgTk9UIG1vZGlmeSBpdDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPi08L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+SWYgcmVzcG9uc2UgZG9lcyBub3QgY29udGFpbiBTLUUsIHRoZSBwcm94eSBNQVkgaW5zZXJ0 IFMtRSBpZiBpdCByZW1lbWJlcnMgdGhhdCB0aGUgYXNzb2NpYXRlZCByZXF1ZXN0IGNvbnRhaW5l ZCBTdXBwb3J0ZWQ6dGltZXI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5VQVM6PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIz OTk3Nzc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3Bh biBsYW5nPSJFTi1VUyI+LTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiByZXF1ZXN0IGNvbnRhaW5zIFMtRTo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iZ21haWwtbTYxOTUzMDkwNDQwMjM5OTc3Nzhtc29saXN0 cGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPm88L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJzcDsmbmJzcDsNCjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIFVBUyBjb3BpZXMgdGhlIFMtRSB2YWx1ZSBvZiB0aGUgcmVxdWVzdCBp bnRvIHRoZSByZXNwb25zZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1t NjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+bzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPiZu YnNwOyZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgVUFTIE1VU1QgTk9UIHJl ZHVjZSB0aGUgUy1FIHZhbHVlIGluIHRoZSByZXNwb25zZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJnbWFpbC1tNjE5NTMwOTA0NDAyMzk5Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDoxMDguMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1mYW1pbHk6V2luZ2RpbmdzIj7Cpzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2Vy aWYiPiZuYnNwOw0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGUgVUFTIHdhbnRzIHRv IGNoYW5nZSB0aGUgUy1FIHZhbHVlLCBpdCBsYXRlciBzZW5kcyBhIHJlcXVlc3QgYnkgaXRzIG93 bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJnbWFpbC1tNjE5NTMwOTA0NDAyMzk5 Nzc3OG1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4g bGFuZz0iRU4tVVMiPi08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 Ny4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhlIHJlcXVlc3QgZG9lcyBub3QgY29udGFpbiBTLUU6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9ImdtYWlsLW02MTk1MzA5MDQ0MDIzOTk3 Nzc4bXNvbGlzdHBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdCI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij5v PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoZSByZXF1ZXN0IGNvbnRhaW5zIFN1cHBvcnRlZDp0 aW1lciwgdGhlIFVBUyBNQVkgaW5jbHVkZSBTLUUgaW4gdGhlIHJlc3BvbnNlPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+UmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5DaHJpc3Rlcjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+c2lwY29yZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNpcGNvcmUtYm91bmNlc0BpZXRmLi5vcmc8L2E+Jmd0OyBv biBiZWhhbGYgb2YgQ2hyaXN0ZXIgSG9sbWJlcmcgJmx0O2NocmlzdGVyLmhvbG1iZXJnPTxhIGhy ZWY9Im1haWx0bzo0MGVyaWNzc29uLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PjQwZXJpY3Nzb24uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ TW9uZGF5LCAxMSBNYXkgMjAyMCBhdCAxNC4zNjxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJl Zj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zaXBjb3JlQGlldGYu b3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zaXBjb3JlQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ W3NpcGNvcmVdIDQwMjhiaXM6IG1lbW9yeSByZWZyZXNoPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGSSI+SGksPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJG SSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Tm93LCB3aGVuIHRoZSBzaXAtb2F1dGggZHJhZnQgaXMgbW9yZSBv ciBsZXNzIGRvbmUgKGluIHRoZSBSRkMgZWRpdG9y4oCZcyBxdWV1ZSksIEkgaW50ZW5kIHRvIHRh a2UgdXAgdGhlIHdvcmsgb24gNDAyOGJpcyAoc2Vzc2lvbi10aW1lcikgYWdhaW4uPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+V2UgcHJldmlvdXNseSBoYWQgZS1tYWlsIGRpc2N1c3Npb25zIGFuZCBw aG9uZSBjYWxscywgdGhlcmUgaXMgYW4gaXNzdWUgdHJhY2tlciBvbiBHaXRIdWIsIGFuZCB3ZSBk aXNjdXNzZWQgdGhlIHN1Z2dlc3RlZCBzb2x1dGlvbnMgYXQgSUVURiMxMDMuIFRvIHJlZnJlc2gg eW91cg0KIG1lbW9yeSwgcGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSB2aWRlbzogPC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9QzJ5ZWNrQm1nUGciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PUMyeWVja0JtZ1BnPC9h Pg0KPHNwYW4gbGFuZz0iRU4tVVMiPih0aGUgc2Vzc2lvbi10aW1lciBwcmVzZW50YXRpb24gYmVn aW5zIGF0IGFyb3VuZCA3OjMwIG1pbnV0ZXMpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBk ZWNpc2lvbiB0byBtYWtlIGEgYmlzIChpbnN0ZWFkIG9mIGFuIHVwZGF0ZSBkcmFmdCkgaGFzIGFs cmVhZHkgYmVlbiBtYWRlLCBidXQgcGxlYXNlIHRha2UgYSBsb29rIGF0IHRoZSB0ZWNobmljYWwg c3VnZ2VzdGlvbnMgZm9yIGZpeGluZyB0aGUgZ2xhcmUgc2l0dWF0aW9uLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPlJlZ2FyZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q2hyaXN0ZXI8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3Jl IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUiIHRhcmdldD0iX2JsYW5rIj5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PG86cD48L286cD48 L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_3A3E112FC60F43EBA2ADAA89597674AAericssoncom_-- From nobody Thu May 14 07:10:56 2020 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 8C8A93A0AE6 for ; Thu, 14 May 2020 07:10:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 dE3keYWyr7sk for ; Thu, 14 May 2020 07:10:54 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2074.outbound.protection.outlook.com [40.107.22.74]) (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 C94103A0B03 for ; Thu, 14 May 2020 07:10:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bWwqoWkGV2NjwrGm08YR6cOH64O3D9UMAqlDqCFJQkHDZp1/4SNxWqVS3kkOylbrMhKx7/KzMs/EN/kBoT3wiQQJt1fKCrGXscNmqmTwaAaKA1PPHcfFYuehVGK6y+5x11O2I0nipN9YMeO7QahOCDC+GR4TzTzEUv+fVlISvf6zT8nE8vWBIJihfTLwrfsD6SUawnOly4TCt+9qlDO2pVD0z7Tkm3NDIOftnKi/fLM6k/P/CaxJM/FjD+dmUg1Jz08HviyUiKmdGB0ulVLEcnoagH6cXSJTFUnIA+nFGeV18FufkQZubr9rEJmSIiQd6LqHG91P2GG9y3Awu0IRCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aeZfJVpTg6j2w2/3Lploikj1idBcgNFRfjlHrWqsqpk=; b=BWHey6AI9T4xs9OhxEHyaAni0c27HL54/+hrIbkU4YP5doVlDvKHhP/sAeYXU9seiO0Bfk4/mO9EvWFnbwkK18QeroC5F7R8RRBbsKd615ZXTnrAq7+5B7dXQUd3i5lsW2S+PQlW62DbFtPaHRLUCUnMWibKaY/uPIZc6P2EqhDZkU32OUDoGv4uGFSyKmHQmTGAj14kzj4ZiukmXi0i+7Y5qZ7gG5zQscQKnI7wg5UGz0u9iEhWyUrTIBSk4A70G0jY8AcfC6RPAfzqJcXlJ2ILBFMl1+mQ/QhCk9Esp2J75kKXKulvxgcScOpXkBbC53Nm5Ix998co7ImsndAYjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aeZfJVpTg6j2w2/3Lploikj1idBcgNFRfjlHrWqsqpk=; b=u2j6V1KygaUon4dCj7t9cDhcZD0T0cYfBV4laEQqlXJZedOlHe+Q8pLypjDdyCdy2c2qV072TmpO1IpLGzuwC/PkijbxOvme8amXT2RmMR5bjsQ6vIIrDx3gVcOzO7O/FXvW4a4k/cjUvOs7coG6i2w4puwoXkSy3OmUcpE0dfU= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6293.eurprd07.prod.outlook.com (2603:10a6:20b:133::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3000.14; Thu, 14 May 2020 14:10:51 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Thu, 14 May 2020 14:10:51 +0000 From: Christer Holmberg To: Samir Srivastava , "sipcore@ietf.org" Thread-Topic: [sipcore] Change log for 4028bis Thread-Index: AQHWKefIMUSYEYIrAkGNVkv8xrNGBqinzLuA///Q7ICAADPGgA== Date: Thu, 14 May 2020 14:10:51 +0000 Message-ID: References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> <20200514120351.EEBD6406C0@smtp.hushmail.com> <0251C7EB-240A-4F8E-A510-E5884ADE6265@ericsson.com> <20200514140534.2BE5640685@smtp.hushmail.com> In-Reply-To: <20200514140534.2BE5640685@smtp.hushmail.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff0c4539-343b-455a-725e-08d7f8109bf3 x-ms-traffictypediagnostic: AM7PR07MB6293: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 040359335D x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Zbxm4gOQ4AgYyIRuQg+YlwIuvPtnxqrTupoY5wgYk7t0kZYNnNBr29wUoHRrdZJutmm+nG6HPbznJ0wjT1CEaxUZC0BofM3Ar3xOa4evTLySREEZ9OS+OTe57by98GsiodZdzbS+RXUf1sIMW37HDdbJvDC4CyXkiaTS1/I2b/4JxUSQuWqyYeAlFg2rxI4Yo6NnCI6sAWZMZqMNUgMIXOtHGVnsP6Z74CIOdg1IBK9mR8H2uXoOX8MlPH8Fj8iktUDxB1iwgFtM8+XsYo6zOEKqTPLyET9X/UXX6gTXpt4gkhklgWY6wKzrvjfGFHFjxVJfVRRWOFOjGYqWJCOjk/LVF/r1LU9dvgkZAoBXg90yc18wWfM2FtE5K7z/9b/k0DdljAL/9SdDPUh9R08G86YdVUEs3BPUuwEI7p9gTWNKPrDyb7Lxcu2/uVZ3faiVGMp7a92/HoTfp51S4sPjwQde3lgyjEvWtg3Y1nWtA9JFBEL2Cthle2wy2ULCvcUM749nVuWC+AYf+fP0CYzmmA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(366004)(39860400002)(376002)(136003)(6512007)(316002)(66446008)(66556008)(36756003)(66946007)(2616005)(76116006)(478600001)(5660300002)(91956017)(966005)(33656002)(66476007)(64756008)(2906002)(71200400001)(6486002)(110136005)(8936002)(53546011)(44832011)(86362001)(26005)(6506007)(186003)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: PIN46yyS9W6UyvJGH3b9b8hAfGKc1QwkTRUBkxy38uqbhcNPYvINMamyojyxawyxhj3tQiqkYz9UZr8GF8C19+dIZbutWA/AROEcLYrJLdu02ORLNGczCop2LJNeo44gWYh9lyMkE3IeC5bETQwdzfoIwAPRVJLtrPUa4WJJnVG1nkzr9rqawUjbrngh4/vvrtW/DWMbM4DvzJ+/pBCnbyCxFhnI8ZwSLToagvd3IRDcgnTVAXtW80MzNInBEubCcAlaeXzjCYgaGYAEJusbzYKU3D/WlLxgi53zOUR9jIcmBzJCHLpTov4944S7OGd2+3vJ9OR6lunKjg0IRaLpqrr5bZ5q0smJvyrKnFO77vPKRjpyCGMyyr3tLlqHwa8pXNV+tON5mSytNQkTYuuEOy6qKZda2xLVIVA0UMBN5XyUk2ADAczRwtq16whWxt5TUyOlc0a9YN2sq4oaTMrBI7LtIC5+0Ysa9pU1NKEwnCXozqukbolSbbkjjRgt5ddC x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: ff0c4539-343b-455a-725e-08d7f8109bf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 May 2020 14:10:51.5304 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Tj1Pp4KBRHMCLFzbjM+ZebNaAHIMsST/XMmJXHtbCLdHmNrpwKI7rAxhrOqVaca9BmcVuQFQ5SN+caTqkMerRvmdI7qnDIMZgefs58JdX1A= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6293 Archived-At: Subject: Re: [sipcore] Change log for 4028bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2020 14:10:56 -0000 SGksDQoNCj7CoFN1cHBvc2UgSSBzdXBwb3J0IFJGQyA0MDI4LCBBbmQgSSB3YW50IHRvIHN1cHBv cnQgeW91ciBuZXcgUkZDIHdoaWNoIGlzIGluIGJpcyBmb3JtIG5vdy4gSW5zdGVhZCBvZiBnb2lu ZyB0aHJvdWdoIHRoZcKgIG1pbnV0ZQ0KPiBkZXRhaWxzIG9mIHlvdXIgbmV3IFJGQyBhcyBhIHdo b2xlLCBJIGZvY3VzIG9uIHRoZSBjaGFuZ2VzIGRvbmUgaW4gdGhlIG5ldyBSRkMgd2l0aCByZXNw ZWN0IHRvIDQwMjguwqANCg0KVGhlIGFpbSBpcyB0byBjaGFuZ2UgYXMgbGl0dGxlIGFzIHBvc3Np YmxlLCBidXQgdGltZSB3aWxsIHNob3cgaG93IG1hbnkgY2hhbmdlcyB3ZSB3aWxsIGhhdmUgdG8g ZG8uDQoNCj7CoCBJIGFtIGxvb2tpbmcgc29tZXRoaW5nIHNpbWlsYXIgdG8gQ2hhcHRlciAyOCBv ZiBSRkMgMzI2MS4gV2hlcmUgaXQgbGlzdHMgdGhlIGRldGFpbHMgb2YgY2hhbmdlcyBkb25lIHdp dGggcmVzcGVjdCBlYXJsaWVyIFNJUCBSRkMgMjU0My4NCg0KV2UgYXJlIGdvaW5nIHRvIGxpc3Qv ZGVzY3JpYmUgdGhlIGNoYW5nZXMgaW4gNDAyOGJpcy4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXIN Cg0KDQoNCg0KDQpPbiA1LzE0LzIwMjAgYXQgNzoyNCBQTSwgIkNocmlzdGVyIEhvbG1iZXJnIiA8 Y2hyaXN0ZXIuaG9sbWJlcmc9NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOiAN CkhpLA0KwqANCkkgYW0gbm90IHN1cmUgSSB1bmRlcnN0YW5kIHdoYXQgeW91IG1lYW4gYnkg4oCc cHJvdmlkZSB0aGUgY2hhbmdlcyB3aXRoIHJlc3BlY3QgdG8gUkZDIDQwMjjigJ0uDQrCoA0KUmVn YXJkcywNCsKgDQpDaHJpc3Rlcg0KwqANCkZyb206IHNpcGNvcmUgPHNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mIFNhbWlyIFNyaXZhc3RhdmEgPHNyaXZhc3RhdmFfc2FtaXI9 NDBodXNoLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkRhdGU6IFRodXJzZGF5LCAxNCBNYXkgMjAyMCBh dCAxNS4wNA0KVG86ICJzaXBjb3JlQGlldGYub3JnIiA8c2lwY29yZUBpZXRmLm9yZz4NClN1Ympl Y3Q6IFtzaXBjb3JlXSBDaGFuZ2UgbG9nIGZvciA0MDI4YmlzDQrCoA0KSGksIA0KwqANCsKgIDQw MjhiaXMgc2hvdWxkIHByb3ZpZGUgdGhlIGNoYW5nZXMgZG9uZSB3aXRoIHJlc3BlY3QgdG8gUkZD IDQwMjguIExpa2UgUkZDIDMyNjEgcHJvdmlkZSBjaGFuZ2VzIGRvbmUgd2l0aCByZXNwZWN0IDI1 NDMuDQrCoA0KVGhhbmtzwqANCsKgDQpTYW1pciBTcml2YXN0YXZhDQrCoA0KaHR0cDovL3NhbWly c3JpdmFzdGF2YS50eXBlcGFkLmNvbQ0KDQo= From nobody Thu May 14 23:50:21 2020 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 B09D33A0407 for ; Thu, 14 May 2020 23:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 lKasRlngRQX9 for ; Thu, 14 May 2020 23:50:18 -0700 (PDT) Received: from mail-oi1-x22c.google.com (mail-oi1-x22c.google.com [IPv6:2607:f8b0:4864:20::22c]) (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 01A403A0406 for ; Thu, 14 May 2020 23:50:17 -0700 (PDT) Received: by mail-oi1-x22c.google.com with SMTP id r25so1345727oij.4 for ; Thu, 14 May 2020 23:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fJoEU1ApBx8popVAItcb3hEPwzKoyKhLe9N+lpHZZdU=; b=JtQJd7g6oEjoD71zzkEQKD9OR/FtR6/qbmYyJBTg/D2x8s2Lox4cod4lKPu4jMilpX ZD0Lvl85bCHwnDJtduOxKyyh+aXxLWHuhUtsDTDIA33+zH8j4QkmqDCWFFUV+fC2GO9N 16oBYAr4ktfKprfLVX1c1nBbuEQKpMPkFr4bHZbKgQx7a2twfgSWtQ2KCgiATonfZJV7 NYX2ctwWBd1xqXOkESx9JMQTNnkUAn3mJOMhmjzcshyzqAKubMz8cAE6KPOhbBfxpEVW yTmc3Yf/bX+M+COnfSFXLCR+0cbKFDTJqiP8ahmoNyfxYUbf2uiAXSmU5ZengGV1Hf1Q 654w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fJoEU1ApBx8popVAItcb3hEPwzKoyKhLe9N+lpHZZdU=; b=L0dx3U9E9Gtw70jHP+spwzOzdiparSbrj8IRFERZF3WOeKdN1+Y7tmLvzDPdKFDI1c dknLzZK2yLNSJhk9VIvJJFirKN5i+w3LYkafyKwWjRZYWA6U4Y8krEIMokxSj4AHHGA+ sd0IEdlHoV5JS5vXzjkKeBTNF/HQyH6cdCl9WBrz0n9NANc3/AMojWjTl+WEAW+OEnko sT/GSRLuuodFb/bLghUf8I3mK+TdKO3rt3jrLbS4hI8S9xKN68786YkUaq4xz2ehZFbX DUBxu4aBZC3FL1EkzFZo31X7tNxNmp2+WNoVW95pmol7ETCc5aBf5Ktbhya0e/fWFcNx sG6Q== X-Gm-Message-State: AOAM530aUsHP1BSFahlFyE2/J9xoKHXHFl7ajl1uKOplKnX9Rzz9S36U 58sR7zQHLFBelZ+bxsYi1GmyNkkXv6k= X-Google-Smtp-Source: ABdhPJyR+nkhewKoUaYgIsJM6NUZR4UNkcmGUXrTR6tgoP3mOkv7K7X83lPKNMdjPHyAzcgjCRUyZg== X-Received: by 2002:aca:4cc9:: with SMTP id z192mr493329oia.159.1589525416696; Thu, 14 May 2020 23:50:16 -0700 (PDT) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com. [209.85.167.182]) by smtp.gmail.com with ESMTPSA id o17sm360936otp.79.2020.05.14.23.50.15 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 May 2020 23:50:15 -0700 (PDT) Received: by mail-oi1-f182.google.com with SMTP id i22so1314241oik.10 for ; Thu, 14 May 2020 23:50:15 -0700 (PDT) X-Received: by 2002:aca:40c2:: with SMTP id n185mr316123oia.12.1589525414961; Thu, 14 May 2020 23:50:14 -0700 (PDT) MIME-Version: 1.0 References: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> In-Reply-To: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> From: Roman Shpount Date: Fri, 15 May 2020 02:50:04 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b866ac05a5aa3990" Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 06:50:20 -0000 --000000000000b866ac05a5aa3990 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 14, 2020 at 10:08 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >1. Defining proxy behavior based on having a transaction in progress: > This is hard to implement in practice since initial INVITE and UPDATE > > >might not even go over the same path and the same proxies. > > > > Section 8 of RFC 4028 says: > > > > =E2=80=9CProxies that ask for session timers SHOULD record-route, as t= hey > > won't receive refreshes if they don't.=E2=80=9D > > > > In my opinion it should be possible to mandate that a proxy that asks for > session timers, or modifies a session timer value (S-E or Min-SE), also > record-route. > > > I have mentioned before that even requiring record-route would be insufficient. First of all, having a transaction in progress for a proxy is something that can be ambiguous due to network delays or message re-ordering even if it is always on the dialog path. Second, the amount of state maintained by proxy, if it needs to track transactions vs dialogs increases significantly. Third, even if the proxy can be the same "logical proxy", it can actually be multiple physical servers sharing an address behind a load balancer, so UPDATE and INVITE transactions can end up on the different servers. Best Regards, _____________ Roman Shpount --000000000000b866ac05a5aa3990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, May 14, 2020 at 10:08 AM Christer= Holmberg <christer.ho= lmberg@ericsson.com> wrote:

>1. Defining proxy be= havior based on having a transaction in progress: This is hard to implement= in practice since initial INVITE and UPDATE

>might not even go ov= er the same path and the same proxies.

=C2=A0

Section 8 of RFC 4028 says:<= /u>

=C2=A0

=C2=A0=C2=A0 =E2=80=9C= Proxies that ask for session timers SHOULD record-route, as they<= /u>

=C2=A0=C2=A0 won't receive refreshes if they= don't.=E2=80=9D

=C2=A0

In my opinion it should be poss= ible to mandate that a proxy that asks for session timers, or modifies a se= ssion timer value (S-E or Min-SE), also record-route.<= /p>



I have mentioned before that even requiring record-route would be in= sufficient. First of all, having a transaction in progress for a proxy is s= omething that can be ambiguous due to network delays or message re-ordering= even if it is always on the dialog path. Second, the amount of state maint= ained by proxy, if it needs to track transactions vs dialogs increases sign= ificantly. Third, even if the proxy can be the same "logical proxy&quo= t;, it can actually be multiple physical=C2=A0servers sharing an address be= hind a load balancer, so UPDATE and INVITE transactions can end up on the d= ifferent servers.

Best Regards,
_____________
Roman = Shpount=C2=A0
--000000000000b866ac05a5aa3990-- From nobody Thu May 14 23:58:37 2020 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 736513A0443 for ; Thu, 14 May 2020 23:58:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 nhBDaYtUeQ-E for ; Thu, 14 May 2020 23:58:35 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2070.outbound.protection.outlook.com [40.107.20.70]) (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 D61CD3A0405 for ; Thu, 14 May 2020 23:58:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QuAwvCLK5YwrY+V4/UPhQ25bTNfg6b6x+1/q3/rbaGGY7/xXgoGrAWsMrSb8YvT2tgqLZIVUlE3QsgfOommDFSBan/jJBrvM0UqgPucR6DQExUecUU0PVbg6SGg/CCsVlohGyDhqTsX4yJcB2Slvz/+sQKnaskLGsBLL/BT6UGac8GjdZUuXR8zVml3bKRPpTLHZoxhXjBWzjeSEp6r7dh77b/MlTjlHVQBm8SKiUG+GIe9j9FPR5czmH7Y3EntxzxZDUwUJp00xWCQ+EuJ0QqMPyqbSk9NC2141MXsYqyEeeT2FSDgqlE9UJKXTrnc+V17Lr9/JpC7V/WAvZp3gIw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LqCSI+64CABApeDopFkbFc9+hfhPIhRXOteTjxsDJCM=; b=esc+khI6u7KiNeXFkrrRCYIVZEKIqmqozpkbXZEQg8lmV0oldlYnLJDtXiHKrninCO7Lk9OG6HH1+DS32L4vATTET4b0Ix7IDuSxtUuC/3Bbtb2IWOpaQKQrnV6wqcvgyY8e9ZfhNx3JFas0gJ1HfO3gw+nXS4I93xUFdkODwt9+xj6aaKi9YjuHcATkPP3R2TdicCaLpyL/qFMv1bUE8mAyR7fEMQ3St7Hx6TnlbGLHTZhR5Us/ZQwKpva5NQadu0ZUx/UOxIQNTRpJcqBbPPcc1Ht58mIc3e/2R7QuaZjFfI7xx/4FG48/EbQQRvReY7s0T3Y99xxG0whtX9GMig== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LqCSI+64CABApeDopFkbFc9+hfhPIhRXOteTjxsDJCM=; b=IVT8eEQ3s3kVUs1eu6x/cw4Xtb2qo+Xqxa499/c4w4aF1sDDmuBJDMpiUo30b8yVJ3j44TFxM7Nx3449zsPQ0MvsRpMpeDgc2JX5poMLrbeG4I0GTw13K5T1A3tnN4jRxZPosfVfzd9C5nEAx5cqIGi/Mm7v9HcMJVw6rvppFuk= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6546.eurprd07.prod.outlook.com (2603:10a6:20b:1a2::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.12; Fri, 15 May 2020 06:58:32 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Fri, 15 May 2020 06:58:32 +0000 From: Christer Holmberg To: Roman Shpount CC: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] 4028bis: memory refresh - proxy assumptions Thread-Index: AQHWKfkgEYFa8+7770udXBuctBvBEqioti0AgAA0qAA= Date: Fri, 15 May 2020 06:58:32 +0000 Message-ID: <36E38B07-F79B-4AD3-B7A9-764FF92F987D@ericsson.com> References: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.210.17.188] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2a593ba9-0fb9-4fad-6e6b-08d7f89d618d x-ms-traffictypediagnostic: AM7PR07MB6546: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04041A2886 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XD4G18iALvF3mV8PN1dQ18cRwm5RM9JH/gwVIruezDcOwCOqZBLo8hgnyOFnTybEHS8aX6a8VAgRKZzI7GdJi/ufZ8rJZjJC+Xuq+P6G/sb4bkIqHEqD8Y7H1dxnTQm8Z6n4YQWI77PwhKQiEdsornd9Yfst6oIAijCRb0Ye0BtVlll2yrzHSrLJayIAorkUOr5sMvx43wH23AUNxlzw+v27zP7pcnpz/SEYwOusIPhIQ7UmMOrOeBb7zf+cvriWuKItD8pKnXXL5+JD4DqGf10Cv5lInQ1DPlJ3iU//o7pc8TuN0kIgX452/RU56rKebj/47Q/Or/7Req//uYFmwA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(346002)(136003)(366004)(376002)(86362001)(6506007)(8936002)(478600001)(71200400001)(5660300002)(26005)(186003)(33656002)(8676002)(6916009)(54906003)(2906002)(4326008)(6512007)(2616005)(66946007)(6486002)(36756003)(91956017)(66446008)(64756008)(76116006)(316002)(44832011)(66476007)(66556008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 6jlvUM+Yz9mvkMg2Odvvbk9Q9xd1bs3MFt/HEONoS9U1eBySlaih+xmqqAVuxs0EMI7rA9bj06f1paowDRVFrqQtJoMMZZYHs3WTdDRKJxji9Bukq5T1eBnStRrtNfEyEKE/oC2ndp+A4hdxUV5rXi5D7K7PfGfcwEmXh+r5S3fKYpklZ5GmHuz7GD4WlrR44gO8ShNihCg4LINFGCCnwvyD+5E3lwqqAb/dZO7xmFG/g2I5dy5y3LfA6yfGfo9mHq5EO5clVqlye+ZhQE/CGOBy2khRy3MEAuPTdWAHcRgluUUUDxU60FjMfYCdTimpEswMtwFFsXqd5aB5nG8K75m7/MUj8ZM+DxAHWDGFagP1d6VyTb+A+QNhC5pX+ErcufMySYQGgeIEGvkQ1A9nsgLLqz+htd0Ou8TDOi7r8LtKgyjhZMpDYvmZjidJf5YCxsmUGAJyAnBo8gN3lmZZh7lP/GQ7PUq7EBvSswm3hyrc5An95pLjT0bymrqQ/Is6 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <29F7218FC9462748BA411278C2ABEFB8@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a593ba9-0fb9-4fad-6e6b-08d7f89d618d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 06:58:32.5073 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1IC+bIrbim4VRZlPvaNB3oOtjNrha3FO87UHtsLyQUxIx0Uut1XpH6L9+f0PrlObYfQ459p3igdlxLNeRHc2j750U+XD3bcsP1794u+15eU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6546 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 06:58:36 -0000 SGksDQoNCj4+PjEuIERlZmluaW5nIHByb3h5IGJlaGF2aW9yIGJhc2VkIG9uIGhhdmluZyBhIHRy YW5zYWN0aW9uIGluIHByb2dyZXNzOiBUaGlzIGlzIGhhcmQgdG8gaW1wbGVtZW50IGluIHByYWN0 aWNlIHNpbmNlIGluaXRpYWwgSU5WSVRFIGFuZCBVUERBVEUNCj4+Pm1pZ2h0IG5vdCBldmVuIGdv IG92ZXIgdGhlIHNhbWUgcGF0aCBhbmQgdGhlIHNhbWUgcHJveGllcy4NCj4+wqANCj4+IFNlY3Rp b24gOCBvZiBSRkMgNDAyOCBzYXlzOg0KPj7CoA0KPj7CoMKgIOKAnFByb3hpZXMgdGhhdCBhc2sg Zm9yIHNlc3Npb24gdGltZXJzIFNIT1VMRCByZWNvcmQtcm91dGUsIGFzIHRoZXkNCj4+wqDCoCB3 b24ndCByZWNlaXZlIHJlZnJlc2hlcyBpZiB0aGV5IGRvbid0LuKAnQ0KPj7CoA0KPj4gSW4gbXkg b3BpbmlvbiBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gbWFuZGF0ZSB0aGF0IGEgcHJveHkgdGhh dCBhc2tzIGZvciBzZXNzaW9uIHRpbWVycywgb3IgbW9kaWZpZXMgYSBzZXNzaW9uIHRpbWVyIHZh bHVlIChTLUUgb3IgTWluLVNFKSwgYWxzbyByZWNvcmQtcm91dGUuDQo+Pg0KPiBJIGhhdmUgbWVu dGlvbmVkIGJlZm9yZSB0aGF0IGV2ZW4gcmVxdWlyaW5nIHJlY29yZC1yb3V0ZSB3b3VsZCBiZSBp bnN1ZmZpY2llbnQuIEZpcnN0IG9mIGFsbCwgaGF2aW5nIGEgdHJhbnNhY3Rpb24gaW4gcHJvZ3Jl c3MgZm9yIGEgcHJveHkgaXMgc29tZXRoaW5nDQo+IHRoYXQgY2FuIGJlIGFtYmlndW91cyBkdWUg dG8gbmV0d29yayBkZWxheXMgb3IgbWVzc2FnZSByZS1vcmRlcmluZyBldmVuIGlmIGl0IGlzIGFs d2F5cyBvbiB0aGUgZGlhbG9nIHBhdGguIFNlY29uZCwgdGhlIGFtb3VudCBvZiBzdGF0ZSBtYWlu dGFpbmVkDQo+IGJ5IHByb3h5LCBpZiBpdCBuZWVkcyB0byB0cmFjayB0cmFuc2FjdGlvbnMgdnMg ZGlhbG9ncyBpbmNyZWFzZXMgc2lnbmlmaWNhbnRseS4gVGhpcmQsIGV2ZW4gaWYgdGhlIHByb3h5 IGNhbiBiZSB0aGUgc2FtZSAibG9naWNhbCBwcm94eSIsIGl0IGNhbiBhY3R1YWxseSBiZQ0KPiBt dWx0aXBsZSBwaHlzaWNhbMKgc2VydmVycyBzaGFyaW5nIGFuIGFkZHJlc3MgYmVoaW5kIGEgbG9h ZCBiYWxhbmNlciwgc28gVVBEQVRFIGFuZCBJTlZJVEUgdHJhbnNhY3Rpb25zIGNhbiBlbmQgdXAg b24gdGhlIGRpZmZlcmVudCBzZXJ2ZXJzLg0KDQpZb3UgY291bGQgc3RpbGwgY29uZmlndXJlIHRo b3NlIHByb3hpZXMgdG8gYmVoYXZlIGluIHRoZSBzYW1lIHdheSAoaW5zZXJ0L21vZGlmeSB0aGUg Uy1FIGFuZCBNaW4tU0UgaGVhZGVyIGZpZWxkIHZhbHVlcyBpbiB0aGUgc2FtZSB3YXkpIHdoZW4g aXQgY29tZXMgdG8gdGhlIHNlc3Npb24tdGltZXIuIA0KDQpSZWdhcmRzLA0KDQpDaHJpc3Rlcg0K DQoNCg0K From nobody Fri May 15 00:21:27 2020 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 237B33A07BD for ; Fri, 15 May 2020 00:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 kM0kvjMEIbLc for ; Fri, 15 May 2020 00:21:17 -0700 (PDT) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 636EA3A07BB for ; Fri, 15 May 2020 00:21:17 -0700 (PDT) Received: by mail-oi1-x236.google.com with SMTP id s198so1394458oie.6 for ; Fri, 15 May 2020 00:21:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iYUrJ1g/WoTiF+0Ey6heNGvvkWe6bYh2WIqsubSZrN0=; b=T7g6/AQFWxEE62MpU6b6epiPgpZTM5Un27UvuDxogIxPb8m6igPmcqbkbLHjRfeof7 EQPsyKf8uhcHM3c0AvRZDR5w7dsXE3zpSd5vVRFiijiY1kSvVSyzRz0Q61hiD0+g6K6k rtdUeDtqIpUwByvO7eFSbt4hlsNOhNDqN0Q4+9AmDqhwW6Se8utEl3R/3vwbRePQYRPk QO8A7fs+sxdvyjfeVbGRHyXGCVZnbBEBus0sSbMc+SO6ay2HSpoioER2+6bHvu6hsWSJ x3EeOzIyGUKDrNpKi1mbwgRL4qRv2gtRW4f2hmR0DOnAbR1mp+4vjSGKKzRmYlyNk+yb 85Fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iYUrJ1g/WoTiF+0Ey6heNGvvkWe6bYh2WIqsubSZrN0=; b=JdOv+95CdIUT5D/b8RB9pq+bsZm+METvNd+intJ3GkxQyfsQ8D5XtlYCnSZpBXTG9u UyEeiJ5++1W5zHjKiI42ITqlludlnbt2yJAI6e4H3R+294xcA6Gm86H9i+EUUnOqXLSg SQazCEF6ajIvAhf4DIpFw2asymIUmP+ur2VvGMAO047/xPg7QHcapoOxhQXKNiatGrQX Wkt82tWlMVh9TNqNK0SrNTodYVWEHdBWZR5M8OnVHsZ4vp1IkTJslBlteqfdqxZY0r7e 1wiPCmAda9MyHoU+FOYjvAdddPYj+4Y7DdlXxSmb/nHIcN7KVcSYyvl0m5ICyQwxdPzF spPQ== X-Gm-Message-State: AOAM531c4StYXdbvtYi2rgN/XDOGo7ppA9aPFbmrfxYSEzG0nj699uOm DE7gyOZRwzro9gyDuBufivSAWzDa0pM= X-Google-Smtp-Source: ABdhPJz1qN4uSxmDdLIp05QgxfY/3g/52v4AlSJkUs5B6OT3OLTBmPmuCE3Bg8ctKhQOHd6wrra4xg== X-Received: by 2002:aca:54d8:: with SMTP id i207mr1110687oib.118.1589527276109; Fri, 15 May 2020 00:21:16 -0700 (PDT) Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com. [209.85.210.47]) by smtp.gmail.com with ESMTPSA id q19sm392786ooh.11.2020.05.15.00.21.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 00:21:15 -0700 (PDT) Received: by mail-ot1-f47.google.com with SMTP id w22so1166999otp.5 for ; Fri, 15 May 2020 00:21:14 -0700 (PDT) X-Received: by 2002:a05:6830:148c:: with SMTP id s12mr1296939otq.39.1589527274427; Fri, 15 May 2020 00:21:14 -0700 (PDT) MIME-Version: 1.0 References: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> <36E38B07-F79B-4AD3-B7A9-764FF92F987D@ericsson.com> In-Reply-To: <36E38B07-F79B-4AD3-B7A9-764FF92F987D@ericsson.com> From: Roman Shpount Date: Fri, 15 May 2020 03:21:04 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="0000000000008d9dbe05a5aaa8fa" Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 07:21:26 -0000 --0000000000008d9dbe05a5aaa8fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2020 at 2:58 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >>>1. Defining proxy behavior based on having a transaction in progress: > This is hard to implement in practice since initial INVITE and UPDATE > >>>might not even go over the same path and the same proxies. > >> > >> Section 8 of RFC 4028 says: > >> > >> =E2=80=9CProxies that ask for session timers SHOULD record-route, as= they > >> won't receive refreshes if they don't.=E2=80=9D > >> > >> In my opinion it should be possible to mandate that a proxy that asks > for session timers, or modifies a session timer value (S-E or Min-SE), al= so > record-route. > >> > > I have mentioned before that even requiring record-route would be > insufficient. First of all, having a transaction in progress for a proxy = is > something > > that can be ambiguous due to network delays or message re-ordering even > if it is always on the dialog path. Second, the amount of state maintaine= d > > by proxy, if it needs to track transactions vs dialogs increases > significantly. Third, even if the proxy can be the same "logical proxy", = it > can actually be > > multiple physical servers sharing an address behind a load balancer, so > UPDATE and INVITE transactions can end up on the different servers. > > You could still configure those proxies to behave in the same way > (insert/modify the S-E and Min-SE header field values in the same way) wh= en > it comes to the session-timer. > > Absolutely correct. Having proxies use the same consistent rules should be sufficient. My point is that we cannot define proxy behavior based on having a transaction in progress. This is only non-ambiguous and implementable for a UA. _____________ Roman Shpount --0000000000008d9dbe05a5aaa8fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri,= May 15, 2020 at 2:58 AM Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>>1. Defining= proxy behavior based on having a transaction in progress: This is hard to = implement in practice since initial INVITE and UPDATE
>>>might not even go over the same path and the same proxies.
>>=C2=A0
>> Section 8 of RFC 4028 says:
>>=C2=A0
>>=C2=A0=C2=A0 =E2=80=9CProxies that ask for session timers SHOULD re= cord-route, as they
>>=C2=A0=C2=A0 won't receive refreshes if they don't.=E2=80= =9D
>>=C2=A0
>> In my opinion it should be possible to mandate that a proxy that a= sks for session timers, or modifies a session timer value (S-E or Min-SE), = also record-route.
>>
> I have mentioned before that even requiring record-route would be insu= fficient. First of all, having a transaction in progress for a proxy is som= ething
> that can be ambiguous due to network delays or message re-ordering eve= n if it is always on the dialog path. Second, the amount of state maintaine= d
> by proxy, if it needs to track transactions vs dialogs increases signi= ficantly. Third, even if the proxy can be the same "logical proxy"= ;, it can actually be
> multiple physical=C2=A0servers sharing an address behind a load balanc= er, so UPDATE and INVITE transactions can end up on the different servers.<= br>
You could still configure those proxies to behave in the same way (insert/m= odify the S-E and Min-SE header field values in the same way) when it comes= to the session-timer.


Absolutely = correct. Having proxies use=C2=A0the=C2=A0same consistent=C2=A0rules should= be sufficient.

My point is that we cannot define = proxy behavior based on having a transaction in progress. This is only=C2= =A0non-ambiguous and implementable for a UA.
_____________
Roman Shpount

=C2=A0
--0000000000008d9dbe05a5aaa8fa-- From nobody Fri May 15 00:30:29 2020 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 78A4C3A07C5 for ; Fri, 15 May 2020 00:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 BadFeEpzVhZu for ; Fri, 15 May 2020 00:30:25 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60069.outbound.protection.outlook.com [40.107.6.69]) (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 EBFB13A07C6 for ; Fri, 15 May 2020 00:30:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MeEt/Y15Tt7C4eQqlTSDyyOXOIQ1H9zpRIdZkCS1DXV9nR0hx73thK7HFsuJklESyFdFJc/8ZeFZL9jPP3aztVEthrmMTfD/2X8oB9IMNkcfkiUE876I2UNPuIltSr2ABLOiwzbV6KFRZYQ+8v+Fer5XWHgjBoXioBAdqCxNRDT9vIfP7Pli02nlu9XB7BdsWy67ovJS2+u5+paLxmGT7mcZh+5u6Q3pzMdA62N/VGGA0Qosu8+5SeC+lSaUoHVd3VC7p8J2kp6hEnmYy8C1w3y8F8GXXZ3O0EfRy3GEDycx0SqTSbiK24cvB93aH3QLVRifpGn9baDKn4eR/6XNag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z62GxUgTIVC7eWMdce9ppj75npC0QnCtpkdPXKXq7YY=; b=iVv+W1pHCqAmq6GvIDvB9j37K8U/b3LrMhB1r8wwjqrpDujMfLBzSVNm5gBpbVCnv031oHl21ItzRwZaoIL2iCyG8OBML9JF0cAoKoKjkp3DwsSIPs7s0yQr4oIQUkX7SuBNRprZQu/4+Cnjr2dq+VfvwPXsLC5dwWTE5KMBLbVzgyFDpOY6GfMgymqUBlXETO9qys39PiXBU/MhXtKD2E1/BEF5CpbXcq/Kjd8JygPvsdH4FA/mmH/ZVwq+pi0/yJ+cqMJxAC21mYMnKgJcq3Cj6w0VSEZg8EtmWbezAwE9u+BBF5P2vF0qbxOk3vp3Mrbk7PBlwQW8uqyqMUIdeA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Z62GxUgTIVC7eWMdce9ppj75npC0QnCtpkdPXKXq7YY=; b=F1vEoeENA1My81dUGOW6EJE4JWdiurdcqB/WzZ6S2Jy2KUtl/Nc0FsvV1bjFU+SJDqC+fsl6j+awz2MsJUNx6/mDREU3cyfjrZw/ZAKdZilFCM8V7taKevJdmPwOiq8FVLCsJE9gqexwSr5v1Kbcnd/atwH+by9kqrBZ1tR+spM= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6484.eurprd07.prod.outlook.com (2603:10a6:20b:1aa::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.12; Fri, 15 May 2020 07:30:22 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Fri, 15 May 2020 07:30:22 +0000 From: Christer Holmberg To: Roman Shpount CC: Christer Holmberg , "sipcore@ietf.org" Thread-Topic: [sipcore] 4028bis: memory refresh - proxy assumptions Thread-Index: AQHWKfkgEYFa8+7770udXBuctBvBEqioti0AgAA0qAD//9QBAIAANOOA Date: Fri, 15 May 2020 07:30:22 +0000 Message-ID: <32348831-8C73-4A1C-BEFA-294FBAF2A224@ericsson.com> References: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> <36E38B07-F79B-4AD3-B7A9-764FF92F987D@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [193.210.17.188] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f0d9805c-da49-4068-50e8-08d7f8a1d41b x-ms-traffictypediagnostic: AM7PR07MB6484: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04041A2886 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aRlYU0QWo1gfTF2sxoY5tZNbc+ANnN1K5tEY/NoYwRujYNd5ST/GLg7lkwFdXN0k27E4NTBQ00o0AbZ0kyRtxFVyFfT4YjSodqZ9qGvkPFWOqNEB3RcctpMeo6sYq2+UM2oYjNHrUYwSFOgw2cm3Xi58+GLH63PJUP3QGYFYV+WtSSF+frTstBNQ3K832u3NcS5/4khMsm4ejBZb07PaKYLjVwtK0+3scL2QM+74mxtfPMHfQnnsP6Rn6tMhElXlMiVmXgAm1H0EmTqtmRMZOVthb1dydQie21D01RNZka5x8aeG/+DW7z1xpKzyRJhk8CWiYZg4bckOkb7c6d6JmQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(346002)(396003)(366004)(2906002)(6512007)(36756003)(6916009)(478600001)(186003)(76116006)(66476007)(66446008)(4326008)(66946007)(2616005)(66556008)(91956017)(64756008)(44832011)(5660300002)(6486002)(71200400001)(6506007)(8936002)(8676002)(86362001)(316002)(26005)(54906003)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: G9YL64XQCg81hxosmwiZWM0jlVSwt5kjh2se+g2fhIG41tXXx8PMesBnZL7oh0+8uQrIyoLL1giSCbPoOrp+RhvS+8/JVy4TnjSgwu4VPDqxiEIjHe9z+K3QDvB2l210nNhnmn0L0wZP7bZbKYQltgphnNbRI6Uma92tA2oQ0laLeRy/jaXygGT9A09UhyrW0zeZ2HipW+/CQzjfk82pbwEN+kyQ7tUYweFO4NyzilPQRNcLRtZNbOsO02XH/1vCMnlA/GFMKz2I028gEg+/9XvDE0mSaVMcMkSIdfnUE4T6MhPdPX3FIj9XdSUbv6PTpFXCM0fuKoqNiAV+hIev8W1+fmUc+RN8r2p9ndtNg5V85DVQHX10PoN4cnY7dgrqn+0eX5wWisWERNU4WJKDNXIE2WeDYOq/ViWTq7b9W+XqqRLuE0iR7lBY7ePeFh2c6rqZJL3a4zb3nftmdoOctosJlweXS1lmXFI+SCgdm+1fn/yp4GrDMFSuFfRIQCvq x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: f0d9805c-da49-4068-50e8-08d7f8a1d41b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 07:30:22.7042 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YokBhsLeRsL0ieSasY8+JosOqmadOFD0XZDMS2ocja2Uof3yaNftZvaNplIePtjJrlLz5nCTYc3C7vjnaQu5FjTbpyO38bQ00oGrUNdFCYI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6484 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 07:30:27 -0000 SGksDQoNCj4+Pj4+MS4gRGVmaW5pbmcgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2aW5nIGEg dHJhbnNhY3Rpb24gaW4gcHJvZ3Jlc3M6IFRoaXMgaXMgaGFyZCB0byBpbXBsZW1lbnQgaW4gcHJh Y3RpY2Ugc2luY2UgaW5pdGlhbCBJTlZJVEUgYW5kIFVQREFURQ0KPj4+Pj5taWdodCBub3QgZXZl biBnbyBvdmVyIHRoZSBzYW1lIHBhdGggYW5kIHRoZSBzYW1lIHByb3hpZXMuDQo+Pj4+wqANCj4+ Pj4gU2VjdGlvbiA4IG9mIFJGQyA0MDI4IHNheXM6DQo+Pj4+wqANCj4+Pj7CoMKgIOKAnFByb3hp ZXMgdGhhdCBhc2sgZm9yIHNlc3Npb24gdGltZXJzIFNIT1VMRCByZWNvcmQtcm91dGUsIGFzIHRo ZXkNCj4+Pj7CoMKgIHdvbid0IHJlY2VpdmUgcmVmcmVzaGVzIGlmIHRoZXkgZG9uJ3Qu4oCdDQo+ Pj4+wqANCj4+Pj4gSW4gbXkgb3BpbmlvbiBpdCBzaG91bGQgYmUgcG9zc2libGUgdG8gbWFuZGF0 ZSB0aGF0IGEgcHJveHkgdGhhdCBhc2tzIGZvciBzZXNzaW9uIHRpbWVycywgb3IgbW9kaWZpZXMg YSBzZXNzaW9uIHRpbWVyIHZhbHVlIChTLUUgb3IgTWluLVNFKSwgYWxzbyByZWNvcmQtcm91dGUu DQo+Pj4+DQo+Pj4gSSBoYXZlIG1lbnRpb25lZCBiZWZvcmUgdGhhdCBldmVuIHJlcXVpcmluZyBy ZWNvcmQtcm91dGUgd291bGQgYmUgaW5zdWZmaWNpZW50LiBGaXJzdCBvZiBhbGwsIGhhdmluZyBh IHRyYW5zYWN0aW9uIGluIHByb2dyZXNzIGZvciBhIHByb3h5IGlzIHNvbWV0aGluZw0KPj4+IHRo YXQgY2FuIGJlIGFtYmlndW91cyBkdWUgdG8gbmV0d29yayBkZWxheXMgb3IgbWVzc2FnZSByZS1v cmRlcmluZyBldmVuIGlmIGl0IGlzIGFsd2F5cyBvbiB0aGUgZGlhbG9nIHBhdGguIFNlY29uZCwg dGhlIGFtb3VudCBvZiBzdGF0ZSBtYWludGFpbmVkDQo+Pj4gYnkgcHJveHksIGlmIGl0IG5lZWRz IHRvIHRyYWNrIHRyYW5zYWN0aW9ucyB2cyBkaWFsb2dzIGluY3JlYXNlcyBzaWduaWZpY2FudGx5 LiBUaGlyZCwgZXZlbiBpZiB0aGUgcHJveHkgY2FuIGJlIHRoZSBzYW1lICJsb2dpY2FsIHByb3h5 IiwgaXQgY2FuIGFjdHVhbGx5IGJlDQo+Pj4gbXVsdGlwbGUgcGh5c2ljYWzCoHNlcnZlcnMgc2hh cmluZyBhbiBhZGRyZXNzIGJlaGluZCBhIGxvYWQgYmFsYW5jZXIsIHNvIFVQREFURSBhbmQgSU5W SVRFIHRyYW5zYWN0aW9ucyBjYW4gZW5kIHVwIG9uIHRoZSBkaWZmZXJlbnQgc2VydmVycy4NCj4+ DQo+PiBZb3UgY291bGQgc3RpbGwgY29uZmlndXJlIHRob3NlIHByb3hpZXMgdG8gYmVoYXZlIGlu IHRoZSBzYW1lIHdheSAoaW5zZXJ0L21vZGlmeSB0aGUgUy1FIGFuZCBNaW4tU0UgaGVhZGVyIGZp ZWxkIHZhbHVlcyBpbiB0aGUgc2FtZSB3YXkpIHdoZW4gaXQgY29tZXMgdG8gdGhlIHNlc3Npb24t dGltZXIuIA0KPg0KPiBBYnNvbHV0ZWx5IGNvcnJlY3QuIEhhdmluZyBwcm94aWVzIHVzZcKgdGhl wqBzYW1lIGNvbnNpc3RlbnTCoHJ1bGVzIHNob3VsZCBiZSBzdWZmaWNpZW50Lg0KPg0KPiBNeSBw b2ludCBpcyB0aGF0IHdlIGNhbm5vdCBkZWZpbmUgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2 aW5nIGEgdHJhbnNhY3Rpb24gaW4gcHJvZ3Jlc3MuIFRoaXMgaXMgb25secKgbm9uLWFtYmlndW91 cyBhbmQgaW1wbGVtZW50YWJsZSBmb3IgYSBVQS4NCg0KSWYgdGhlIHByb3h5IGlzIG5vdCBhd2Fy ZSBvZiB0cmFuc2FjdGlvbnMsIGl0IGNvdWxkIGFsd2F5cyBiZWhhdmUgaW4gdGhlIHNhbWUgd2F5 LCBpLmUuLCBhbHdheXMgaW5zZXJ0L21vZGlmeSB0aGUgc2FtZSBTLUUgYW5kIE1pbi1TRSBoZWFk ZXIgZmllbGQgdmFsdWVzIGluIElOVklURXMgYW5kIFVQREFURXMuDQoNCkkgcmVhbGx5IHNlZSBu byByZWFzb24gd2h5IGEgcHJveHkgc2hvdWxkIHN1ZGRlbmx5IGNoYW5nZSBzZXNzaW9uIHRpbWVy IGJlaGF2aW9yIC0gZXNwZWNpYWxseSBhIHByb3h5IHRoYXQgaXMgbm90IHNlc3Npb24gYXdhcmUs IG9yIGF3YXJlIG9mIG90aGVyIG9uZ29pbmcgdHJhbnNhY3Rpb25zLg0KDQpSZWdhcmRzLA0KDQpD aHJpc3Rlcg0KDQrCoA0KDQo= From nobody Fri May 15 01:09:50 2020 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 C3B7C3A0841 for ; Fri, 15 May 2020 01:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 2zrq6VvCxumo for ; Fri, 15 May 2020 01:09:45 -0700 (PDT) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (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 325743A0843 for ; Fri, 15 May 2020 01:09:45 -0700 (PDT) Received: by mail-oo1-xc31.google.com with SMTP id z6so263991ooz.3 for ; Fri, 15 May 2020 01:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Jti0+POJVBpG2fl9II47bHtkujXf1gPm6speimoFbpE=; b=wusU8pHn2yHMn3P/yCtAKiOP2gYoYr3KjC0lPZeXaDmJ2wliR5zEEDsCAVHyrg2cQ5 0Tb1FiYfRlKtbJu/eAM9NYH3Ew4PlTHK/WuL+qBbknGwT9BNgJf26SLEAgFxkPfCTUzw YSTZdaDlCRWoWiRTjaf0NSLpD3JzdLJlpWXp6e0oxTZZoTrKXwmmJ1k65xb3ftfdMOv+ FiDcEQihNn/W3MhFQnRikAno86vnvcnLwx2YGyvdIcgrU7yG4s6DHpObqWQireE/wbDW OkYcZiWpgWMbhuXIVc4J5wx5MHhsnQSsMNSkIC3H58bXGhg9pmUsKGVwq33wx3BD03I9 VrgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jti0+POJVBpG2fl9II47bHtkujXf1gPm6speimoFbpE=; b=gQgtCiBrAkpQuYXzgfXa5FDVa/Sf4Mpa18CrMyFVPMK6r8stjs733lXYN1ewwzfFvG Qs4bh9/KQ8sifGuLz9KJRmWE4oVvU1DXe60BBrwwhbIkmmCMpu6aM6uOF5Qh/IGoAbg+ BJGKZsza6Q7qf+hq+CJ2HxAWc+l5PKuKF3kCWrUSBz4adeIPHrFylmuG/VXlbkH6A3w1 QW+Xs5W9Fu0x1TEx7MN5CitwNU5ybMO0JYqxWJnLlsyixez8V40/K5OqdnpkE1WVMiKZ dkNsUPC4dIvzYZ7WZiyVdWa+hRtkPFFslebhvffGgfct/toAzHkxVL7jeNEQUiz4ToBL TO6w== X-Gm-Message-State: AOAM531WdnoP0zU7YRS/jrwQdvq6r3wEvyZgLNV0VLqX1krUt9zHSfc+ t//FIg9L3a7vlW+6XpyaIFox5hfSqi8= X-Google-Smtp-Source: ABdhPJxntb5ZVXcHtQjCwTIgKNSgD+HfGJWZ7pOU1o5x9uzSVWqp61rADZh7grP+CDyztHfXwkNSJw== X-Received: by 2002:a4a:2c58:: with SMTP id o85mr1498688ooo.71.1589530183865; Fri, 15 May 2020 01:09:43 -0700 (PDT) Received: from mail-ot1-f46.google.com (mail-ot1-f46.google.com. [209.85.210.46]) by smtp.gmail.com with ESMTPSA id d10sm407705ote.10.2020.05.15.01.09.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 01:09:42 -0700 (PDT) Received: by mail-ot1-f46.google.com with SMTP id j4so1222550otr.11 for ; Fri, 15 May 2020 01:09:42 -0700 (PDT) X-Received: by 2002:a05:6830:c2:: with SMTP id x2mr971766oto.19.1589530182329; Fri, 15 May 2020 01:09:42 -0700 (PDT) MIME-Version: 1.0 References: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> <36E38B07-F79B-4AD3-B7A9-764FF92F987D@ericsson.com> <32348831-8C73-4A1C-BEFA-294FBAF2A224@ericsson.com> In-Reply-To: <32348831-8C73-4A1C-BEFA-294FBAF2A224@ericsson.com> From: Roman Shpount Date: Fri, 15 May 2020 04:09:32 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Christer Holmberg Cc: Christer Holmberg , "sipcore@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e0be9105a5ab5509" Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 08:09:49 -0000 --000000000000e0be9105a5ab5509 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, May 15, 2020 at 3:30 AM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > >>>>>1. Defining proxy behavior based on having a transaction in progress= : > This is hard to implement in practice since initial INVITE and UPDATE > >>>>>might not even go over the same path and the same proxies. > >>>> > >>>> Section 8 of RFC 4028 says: > >>>> > >>>> =E2=80=9CProxies that ask for session timers SHOULD record-route, = as they > >>>> won't receive refreshes if they don't.=E2=80=9D > >>>> > >>>> In my opinion it should be possible to mandate that a proxy that ask= s > for session timers, or modifies a session timer value (S-E or Min-SE), al= so > record-route. > >>>> > >>> I have mentioned before that even requiring record-route would be > insufficient. First of all, having a transaction in progress for a proxy = is > something > >>> that can be ambiguous due to network delays or message re-ordering > even if it is always on the dialog path. Second, the amount of state > maintained > >>> by proxy, if it needs to track transactions vs dialogs increases > significantly. Third, even if the proxy can be the same "logical proxy", = it > can actually be > >>> multiple physical servers sharing an address behind a load balancer, > so UPDATE and INVITE transactions can end up on the different servers. > >> > >> You could still configure those proxies to behave in the same way > (insert/modify the S-E and Min-SE header field values in the same way) wh= en > it comes to the session-timer. > > > > Absolutely correct. Having proxies use the same consistent rules should > be sufficient. > > > > My point is that we cannot define proxy behavior based on having a > transaction in progress. This is only non-ambiguous and implementable for= a > UA. > > If the proxy is not aware of transactions, it could always behave in the > same way, i.e., always insert/modify the same S-E and Min-SE header field > values in INVITEs and UPDATEs. > > I really see no reason why a proxy should suddenly change session timer > behavior - especially a proxy that is not session aware, or aware of othe= r > ongoing transactions. > > Proxy can be dialog aware but not aware of all the transactions in the dialog. Proxy behavior most likely must be defined in a way that the rules by which it inserts S-E and Min-SE headers should be consistent throughout the dialog. I do not see there is a reason for a proxy to suddenly change session timer behavior during the dialog. Behavior of UA should be defined in such a way that they can change S-E and Min-SE headers, since B2BUA scenarios can cause such behavior. Doing this can be limited in scope since UA are obviously both transaction and dialog aware. _____________ Roman Shpount --000000000000e0be9105a5ab5509 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, May 15, 2020 at 3:30 AM Christer = Holmberg <christer.hol= mberg@ericsson.com> wrote:
>>>>>1. Definin= g proxy behavior based on having a transaction in progress: This is hard to= implement in practice since initial INVITE and UPDATE
>>>>>might not even go over the same path and the same proxi= es.
>>>>=C2=A0
>>>> Section 8 of RFC 4028 says:
>>>>=C2=A0
>>>>=C2=A0=C2=A0 =E2=80=9CProxies that ask for session timers S= HOULD record-route, as they
>>>>=C2=A0=C2=A0 won't receive refreshes if they don't.= =E2=80=9D
>>>>=C2=A0
>>>> In my opinion it should be possible to mandate that a prox= y that asks for session timers, or modifies a session timer value (S-E or M= in-SE), also record-route.
>>>>
>>> I have mentioned before that even requiring record-route would= be insufficient. First of all, having a transaction in progress for a prox= y is something
>>> that can be ambiguous due to network delays or message re-orde= ring even if it is always on the dialog path. Second, the amount of state m= aintained
>>> by proxy, if it needs to track transactions vs dialogs increas= es significantly. Third, even if the proxy can be the same "logical pr= oxy", it can actually be
>>> multiple physical=C2=A0servers sharing an address behind a loa= d balancer, so UPDATE and INVITE transactions can end up on the different s= ervers.
>>
>> You could still configure those proxies to behave in the same way = (insert/modify the S-E and Min-SE header field values in the same way) when= it comes to the session-timer.
>
> Absolutely correct. Having proxies use=C2=A0the=C2=A0same consistent= =C2=A0rules should be sufficient.
>
> My point is that we cannot define proxy behavior based on having a tra= nsaction in progress. This is only=C2=A0non-ambiguous and implementable for= a UA.

If the proxy is not aware of transactions, it could always behave in the sa= me way, i.e., always insert/modify the same S-E and Min-SE header field val= ues in INVITEs and UPDATEs.

I really see no reason why a proxy should suddenly change session timer beh= avior - especially a proxy that is not session aware, or aware of other ong= oing transactions.


Proxy can be dia= log aware but not aware of all the transactions in the dialog. Proxy behavi= or most likely must be defined in a way that the rules by which it inserts = S-E and Min-SE headers should be consistent throughout=C2=A0the dialog. I d= o not see there is a reason for a proxy to suddenly change session timer be= havior during the dialog.

Behavior of UA should be= defined in such a way that they can change S-E and Min-SE headers, since B= 2BUA scenarios can cause such behavior. Doing this can be limited in scope = since UA are obviously both transaction and dialog aware.
_____________
Roman= Shpount=C2=A0
--000000000000e0be9105a5ab5509-- From nobody Fri May 15 06:45:28 2020 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 CC1823A0A06 for ; Fri, 15 May 2020 06:45:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.173, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 i_ABtOClnWoS for ; Fri, 15 May 2020 06:45:25 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150045.outbound.protection.outlook.com [40.107.15.45]) (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 584613A0A05 for ; Fri, 15 May 2020 06:45:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=idjS4xsQ1fJrsOPa/rPyeM+RVkbJPtdWG5Lwbpw9S12gs0w831Jdwp9zaJSTiYlX+dRXL5mxG0QwJZf3tBm4euEALJkX5/JQTt5JIQ+103jqqEg63HHAI0NWqsKoVo1+Azxa+XAysCUp7ve9X2vpLXJqdlnQefqhPGobSr4q/epOODzOkjQaswtlFSB3IngAy22vJDkgrtfR0kHmvOjM8oiryS6CvQDAGUm5Y37k/yoB1FZfptbvY03MaXVJhHHpRzv89fqDC7/bOhOsAtnqzBL7OsFCzV5dF/yi7Tmm0SufpEkovHdLwbQuSnhAhXDvUSi32jM5XWU5TGPhXTlUBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vu2hkbyV1YqVMSCfEYIrbhVVNDscXQrPHNxDkvIofdA=; b=djCyLJwKC7EiuFGSI2M+2QUeUjBx36fnlDITLlVV0DgdSxlOuR802qAg6JefFPVKHjK7FTZB3pMhwRKoztaNDJvGGRaPQJTtihH3dr6a5pro4UOIbde7Yull2zNTB+bvqkbYBI51wga8zSdcPFVTdczM2ejCL0ao+I2Jai/63Y9NYaFDvtpE7z91xCJlQo5lvJtyZDlt6CM9Y+jUhItmw/a7JH1e2jlo/wZ9yhDw5UdYd6gSsIjXXGKzeSDfG8+6pe8mlop0G2n705SZsBrwZA0oB7neNDLoU9UQgigEdpKDvTflgViOsRvjiL/qqtBgmd6c0AanG1G9sUXWrYj36g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vu2hkbyV1YqVMSCfEYIrbhVVNDscXQrPHNxDkvIofdA=; b=O9nknVW+J0gyqczR5LaiFRjXYYHlf265ekq5SMijUPWxtXcEJrBnUK2EIa2gBzbFIWxOtcmy637BorDY4SKvgoDG6IkpMDoVLBxu0lHdqnwI0RoJB9e63u/SvGEBfkE1M7JdJSE00iV+Dg7Pfrd9n6GZJ2h3urgpI40IFCY9DuA= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6690.eurprd07.prod.outlook.com (2603:10a6:20b:1a2::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3021.13; Fri, 15 May 2020 13:45:22 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3000.016; Fri, 15 May 2020 13:45:22 +0000 From: Christer Holmberg To: Roman Shpount CC: "sipcore@ietf.org" Thread-Topic: [sipcore] 4028bis: memory refresh - proxy assumptions Thread-Index: AQHWKfkgEYFa8+7770udXBuctBvBEqioti0AgAA0qAD//9QBAIAANOOA///YqACAAJAegA== Date: Fri, 15 May 2020 13:45:22 +0000 Message-ID: <0C9FFCAC-F663-4646-B20A-615BD1BA427B@ericsson.com> References: <3A3E112F-C60F-43EB-A2AD-AA89597674AA@ericsson.com> <36E38B07-F79B-4AD3-B7A9-764FF92F987D@ericsson.com> <32348831-8C73-4A1C-BEFA-294FBAF2A224@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: telurix.com; dkim=none (message not signed) header.d=none;telurix.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1909243-c1a0-4815-68c6-08d7f8d6373a x-ms-traffictypediagnostic: AM7PR07MB6690: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 04041A2886 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zLY9o1s1aTGdVxs8WgvrUf6BNoZyWn1GkO9kFQpLOff9bgwLBMj/8cgP19yNLR82ih5jnwCRUhzO+8QEi5sV3UgO12e+5+OS9M74wRgXb2jJUSRrrMMmoHHNLAoNNMxBK9fUOlgSmmaoIFBJrfT69hdWyqnbwWqAWE8knQYIkD+wgHuvewTYOWEwt1ea9gOL9H3krvNz2q9vNI6wX8rb7JpNYqJoz6qTLu/KONLNeVJxpjIAWA32KeSzk0kfjeeLDLeE8NjYvRNe6P9flpcdjui533GSwiznu29oDfXPAKJ5zJn+uz6qTEG9Z1GtrECObMNZD7e0Lug8nkHYrOG53w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(396003)(366004)(346002)(376002)(86362001)(6916009)(71200400001)(2906002)(8936002)(6512007)(44832011)(33656002)(64756008)(6486002)(66556008)(66446008)(66476007)(478600001)(91956017)(26005)(66946007)(5660300002)(316002)(186003)(6506007)(36756003)(4326008)(76116006)(8676002)(2616005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: VbdU7D/m19WD9BRG6378GecOl0ifhVF04O/MMs7oR5UiyhvPeDPO4ufNSuwk4cvAi3Jdxy2mqCI7aM4n6HP7UXanbv3m4xrDlT83e4nU4zPPisCiByU659ii2HhXIwxQe/WosoIl8IHIacWXsefTwG6vxSRi2TKh3+/ZNQTL0qbpkvLfr7JmFQFmFDweoWkVLgckWJh4psL2RZo9dHJVaGYSiwEyK+zF0WM8oM5NsuBA9AXygRh8BjkmpLvJVmvOCY1SPpsa917TUeM+XgNR5eNjDsLVo8KQxn527dpAo18/DzPwUz/mNVONMGWWMR3DsL041ou6ISjZdw8wZWti/qutA8w7nkLZoO4z8l1onDYii8mEzbJ8txE78ilu44pMNON+f9NIVMgkDI9uEC0twMCl/iPl/7g+pHr5k2cE8KuXTWYCUG9qe4hyX2PDBvUM+wLxbnLe39H9j/TdNxQqIOctLt9NqSoQFJgzMPcukfCM9vsDuRJCNdXh5dvrnX5N x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: b1909243-c1a0-4815-68c6-08d7f8d6373a X-MS-Exchange-CrossTenant-originalarrivaltime: 15 May 2020 13:45:22.8105 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rPr5PjNfx1Qe/nxKc4nFblxUeM+ob9cJoNbbJWzgkCuIhBYRKW5y8CCZ+IqmsgtZ/31NO/4jyauF9KKMy8sprvkATRBz8OiSsMvoe32QAfA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6690 Archived-At: Subject: Re: [sipcore] 4028bis: memory refresh - proxy assumptions X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2020 13:45:27 -0000 SGksDQoNCj4+Pj4+Pj4gMS4gRGVmaW5pbmcgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2aW5n IGEgdHJhbnNhY3Rpb24gaW4gcHJvZ3Jlc3M6IFRoaXMgaXMgaGFyZCB0byBpbXBsZW1lbnQgaW4g cHJhY3RpY2Ugc2luY2UgaW5pdGlhbCBJTlZJVEUgYW5kIFVQREFURQ0KPj4+Pj4+PiBtaWdodCBu b3QgZXZlbiBnbyBvdmVyIHRoZSBzYW1lIHBhdGggYW5kIHRoZSBzYW1lIHByb3hpZXMuDQo+Pj4+ Pj7CoA0KPj4+Pj4+IFNlY3Rpb24gOCBvZiBSRkMgNDAyOCBzYXlzOg0KPj4+Pj4+wqANCj4+Pj4+ PsKgwqAg4oCcUHJveGllcyB0aGF0IGFzayBmb3Igc2Vzc2lvbiB0aW1lcnMgU0hPVUxEIHJlY29y ZC1yb3V0ZSwgYXMgdGhleQ0KPj4+Pj4+wqDCoCB3b24ndCByZWNlaXZlIHJlZnJlc2hlcyBpZiB0 aGV5IGRvbid0LuKAnQ0KPj4+Pj4+wqANCj4+Pj4+PiBJbiBteSBvcGluaW9uIGl0IHNob3VsZCBi ZSBwb3NzaWJsZSB0byBtYW5kYXRlIHRoYXQgYSBwcm94eSB0aGF0IGFza3MgZm9yIHNlc3Npb24g dGltZXJzLCBvciBtb2RpZmllcyBhIHNlc3Npb24gdGltZXIgdmFsdWUgKFMtRSBvciBNaW4tU0Up LCBhbHNvIHJlY29yZC1yb3V0ZS4NCj4+Pj4+Pg0KPj4+Pj4gSSBoYXZlIG1lbnRpb25lZCBiZWZv cmUgdGhhdCBldmVuIHJlcXVpcmluZyByZWNvcmQtcm91dGUgd291bGQgYmUgaW5zdWZmaWNpZW50 LiBGaXJzdCBvZiBhbGwsIGhhdmluZyBhIHRyYW5zYWN0aW9uIGluIHByb2dyZXNzIGZvciBhIHBy b3h5IGlzIHNvbWV0aGluZw0KPj4+Pj4gdGhhdCBjYW4gYmUgYW1iaWd1b3VzIGR1ZSB0byBuZXR3 b3JrIGRlbGF5cyBvciBtZXNzYWdlIHJlLW9yZGVyaW5nIGV2ZW4gaWYgaXQgaXMgYWx3YXlzIG9u IHRoZSBkaWFsb2cgcGF0aC4gU2Vjb25kLCB0aGUgYW1vdW50IG9mIHN0YXRlIG1haW50YWluZWQN Cj4+Pj4+IGJ5IHByb3h5LCBpZiBpdCBuZWVkcyB0byB0cmFjayB0cmFuc2FjdGlvbnMgdnMgZGlh bG9ncyBpbmNyZWFzZXMgc2lnbmlmaWNhbnRseS4gVGhpcmQsIGV2ZW4gaWYgdGhlIHByb3h5IGNh biBiZSB0aGUgc2FtZSAibG9naWNhbCBwcm94eSIsIGl0IGNhbiBhY3R1YWxseSBiZQ0KPj4+Pj4g bXVsdGlwbGUgcGh5c2ljYWzCoHNlcnZlcnMgc2hhcmluZyBhbiBhZGRyZXNzIGJlaGluZCBhIGxv YWQgYmFsYW5jZXIsIHNvIFVQREFURSBhbmQgSU5WSVRFIHRyYW5zYWN0aW9ucyBjYW4gZW5kIHVw IG9uIHRoZSBkaWZmZXJlbnQgc2VydmVycy4NCj4+Pj4NCj4+Pj4gWW91IGNvdWxkIHN0aWxsIGNv bmZpZ3VyZSB0aG9zZSBwcm94aWVzIHRvIGJlaGF2ZSBpbiB0aGUgc2FtZSB3YXkgKGluc2VydC9t b2RpZnkgdGhlIFMtRSBhbmQgTWluLVNFIGhlYWRlciBmaWVsZCB2YWx1ZXMgaW4gdGhlIHNhbWUg d2F5KSB3aGVuIGl0IGNvbWVzIHRvIHRoZSBzZXNzaW9uLXRpbWVyLiANCj4+Pg0KPj4+IEFic29s dXRlbHkgY29ycmVjdC4gSGF2aW5nIHByb3hpZXMgdXNlwqB0aGXCoHNhbWUgY29uc2lzdGVudMKg cnVsZXMgc2hvdWxkIGJlIHN1ZmZpY2llbnQuDQo+Pj4NCj4+PiBNeSBwb2ludCBpcyB0aGF0IHdl IGNhbm5vdCBkZWZpbmUgcHJveHkgYmVoYXZpb3IgYmFzZWQgb24gaGF2aW5nIGEgdHJhbnNhY3Rp b24gaW4gcHJvZ3Jlc3MuIFRoaXMgaXMgb25secKgbm9uLWFtYmlndW91cyBhbmQgaW1wbGVtZW50 YWJsZSBmb3IgYSBVQS4NCj4+DQo+PiBJZiB0aGUgcHJveHkgaXMgbm90IGF3YXJlIG9mIHRyYW5z YWN0aW9ucywgaXQgY291bGQgYWx3YXlzIGJlaGF2ZSBpbiB0aGUgc2FtZSB3YXksIGkuZS4sIGFs d2F5cyBpbnNlcnQvbW9kaWZ5IHRoZSBzYW1lIFMtRSBhbmQgTWluLVNFIGhlYWRlciBmaWVsZCB2 YWx1ZXMgaW4gSU5WSVRFcyBhbmQgVVBEQVRFcy4NCj4+DQo+PiBJIHJlYWxseSBzZWUgbm8gcmVh c29uIHdoeSBhIHByb3h5IHNob3VsZCBzdWRkZW5seSBjaGFuZ2Ugc2Vzc2lvbiB0aW1lciBiZWhh dmlvciAtIGVzcGVjaWFsbHkgYSBwcm94eQ0KPj4gdGhhdCBpcyBub3Qgc2Vzc2lvbiBhd2FyZSwg b3IgYXdhcmUgb2Ygb3RoZXIgb25nb2luZyB0cmFuc2FjdGlvbnMuDQo+Pg0KPj4gUHJveHkgY2Fu IGJlIGRpYWxvZyBhd2FyZSBidXQgbm90IGF3YXJlIG9mIGFsbCB0aGUgdHJhbnNhY3Rpb25zIGlu IHRoZSBkaWFsb2cuIFByb3h5IGJlaGF2aW9yIG1vc3QgbGlrZWx5IG11c3QgYmUgZGVmaW5lZCBp biBhIHdheSB0aGF0IHRoZSBydWxlcyBieSB3aGljaCBpdCBpbnNlcnRzIFMtRSBhbmQNCj4+IE1p bi1TRSBoZWFkZXJzIHNob3VsZCBiZSBjb25zaXN0ZW50IHRocm91Z2hvdXTCoHRoZSBkaWFsb2cu IEkgZG8gbm90IHNlZSB0aGVyZSBpcyBhIHJlYXNvbiBmb3IgYSBwcm94eSB0byBzdWRkZW5seSBj aGFuZ2Ugc2Vzc2lvbiB0aW1lciBiZWhhdmlvciBkdXJpbmcgdGhlIGRpYWxvZy4NCj4NCj4gQmVo YXZpb3Igb2YgVUEgc2hvdWxkIGJlIGRlZmluZWQgaW4gc3VjaCBhIHdheSB0aGF0IHRoZXkgY2Fu IGNoYW5nZSBTLUUgYW5kIE1pbi1TRSBoZWFkZXJzLCBzaW5jZSBCMkJVQSBzY2VuYXJpb3MgY2Fu IGNhdXNlIHN1Y2ggYmVoYXZpb3IuIA0KPiBEb2luZyB0aGlzIGNhbiBiZSBsaW1pdGVkIGluIHNj b3BlIHNpbmNlIFVBIGFyZSBvYnZpb3VzbHkgYm90aCB0cmFuc2FjdGlvbiBhbmQgZGlhbG9nIGF3 YXJlLg0KDQpDb3VsZCB5b3UgcGxlYXNlIHN0YXJ0IGEgc2VwYXJhdGUgdGhyZWFkICgiNDAyOGJp czogQjJCVUEgYXNzdW1wdGlvbiIsIG9yIHNvbWV0aGluZykgYW5kIGRlc2NyaWJlIHN1Y2ggQjJC VUEgdXNlLWNhc2UocykuIEkgdGhpbmsgaXQgd291bGQgYmUgdXNlZnVsLCBhbmQgcGVyaGFwcyBz b21ldGhpbmcgd2Ugc2hvdWxkIGRvY3VtZW50IGluIHRoZSBiaXMuDQoNClJlZ2FyZHMsDQoNCkNo cmlzdGVyDQoNCg0KDQo= From nobody Wed May 20 01:24:19 2020 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 668F33A3B62 for ; Wed, 20 May 2020 01:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 O3EHCJLCL-x9 for ; Wed, 20 May 2020 01:24:15 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (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 4FE693A3B65 for ; Wed, 20 May 2020 01:24:15 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id w19so1009447ply.11 for ; Wed, 20 May 2020 01:24:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=QaNzl6UiQT4lsrRqsbARzdXxB4PWqAeT2AMupgFWszA=; b=bDY7xsg+259POsS5+eUbOfLQu8xb7YnKDfevmf1ugPlUEhPG1/Cd6E1dvBmEbT8sFH hYi+VxwsZMTiMqUWhDuE+EWgyOpw5ZnIpLVVQrmUpUqMEDlM6XBDXU9H5yjELQCP3rFl lpgvZnPT7S31ETNFBmwpTJ58iDcgQgzEu8SAf006P6DPIkGmqwvl3kA7ZcE1+gBwCJwE sdoBlFpakWopgUlyxQmLrz3eUZwWreLPXxAaB5CHNWvKP0L6ZaDtKX5vaTuD9XszCiBg mj5KpdL6P/EKA8xHhOM1KJZk3zbhXuD7FXSnvNjMEpVRRhSBiuxz0k8axg3T6iiBFRmi ggMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QaNzl6UiQT4lsrRqsbARzdXxB4PWqAeT2AMupgFWszA=; b=LcspCfapby8WNjwnm/ZLXruYYkQaItf2DZ8kiYPCWiL1K0eqe4eSI3baQm4+32fYgA c70SFlFsElAZvEBDApayMJqMWTACSGxj832rciM4T/5/VSOL+LfM3uGcNaMxRNiaJvi7 fRiu/c0EvJd2Or1yVarvw+YgU1iPR8UI26YK50nc1Z2qoYHebXyG1U62yTT3r1/FRMAA 4aPbRAGxHWDr8yqXt9WR31dYf8pxU/L21x0QcqCOY47VCL7gWzzwgBT9FFM9AG0yIdSI hSwYBw9gnkMGgP/n6Dg5kkzFUlSElC/TJG7iZhxRS1rpExTQdQf8A3fAUZ0IV2W/jyeM pbUg== X-Gm-Message-State: AOAM533KZ5jRgJoLQGQt6fkRY9Jm84cB4lQ5Yu6y/b/576kn+GrH1CGp UWgPuo83cok191D6x+fgZ7VtOD/C X-Google-Smtp-Source: ABdhPJzPyyFGflK25dwQKF+SQw4Y65f4rKbgdsTZi/5wWq3ROF1V7C+9p0yHc6HG2PW5P9LgRrEAfg== X-Received: by 2002:a17:90a:7d07:: with SMTP id g7mr4277120pjl.216.1589963054444; Wed, 20 May 2020 01:24:14 -0700 (PDT) Received: from [192.168.1.126] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id e19sm1488155pfn.17.2020.05.20.01.24.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 May 2020 01:24:13 -0700 (PDT) To: sipcore@ietf.org References: From: OKUMURA Shinji Message-ID: <2317cce7-581f-cfb6-b779-c8106dbfdfe8@gmail.com> Date: Wed, 20 May 2020 17:24:11 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [sipcore] proxy's behavior when uac does not support timer X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 May 2020 08:24:18 -0000 Hi, > PROXY: > > Request handling: > > -MUST reject the request if the S-E value is too small > > oNo matter if the request contains Supported:timer or not > If the request does not contain Supported:timer, the S-E was inserted by one of the proxies in the path. In this case, RFC4028 says "the proxy cannot usefully reject the request," In my interpretation, this "usefully" means that the rejection(422) is unreasonable for the UAC. Because it is the proxy that created the cause of the rejection, and UAC can not recognize the cause for the rejection. I have two solutions. 1. If the request does not contain Supported:timer, a proxy MAY insert Min-SE header, SHOULD NOT insert S-E header and SHOULD NOT reject by 422. 2. A proxy MAY reject this request by 422, and the proxy that inserted the S-E header MUST send new INVITE that has a bigger S-E value. Regards, Shinji On 2020/05/12 0:51, Christer Holmberg wrote: > > Hi, > > And, if you for whatever reason rather watch Tiger King than the IETF > 102 SIPCORE session, below is basically what was suggested in order to > solve the session-timer glare situation: > > UAC: > > -If a UA inserts S-E in an INVITE request the UA MUST insert the same > S-E in any UPDATE request it sends while the INVITE transaction is ongoing > > -If a UA has conflicting S-E information once the INVITE and UPDATE > transaction have completed, it MUST send a new UPDATE with S-E, in > order to “sync” the S-E state among all entities > > PROXY: > > Request handling: > > -MUST reject the request if the S-E value is too small > > oNo matter if the request contains Supported:timer or not > > -If the proxy inserts/forwards/modifies the S-E in an INVITE request > the proxy MUST identically insert/forward/modify the same S-E in any > UPDATE request > > oThe proxy MAY insert/modify the S-E if it knows that there is no > active INVITE transaction > > Response handling: > > -If response contains S-E, the proxy MUST NOT modify it > > -If response does not contain S-E, the proxy MAY insert S-E if it > remembers that the associated request contained Supported:timer > > UAS: > > -If request contains S-E: > > oThe UAS copies the S-E value of the request into the response > > oThe UAS MUST NOT reduce the S-E value in the response > > §If the UAS wants to change the S-E value, it later sends a request by > its own > > -If the request does not contain S-E: > > oIf the request contains Supported:timer, the UAS MAY include S-E in > the response > > Regards, > > Christer > > *From: *sipcore on behalf of Christer > Holmberg > *Date: *Monday, 11 May 2020 at 14.36 > *To: *"sipcore@ietf.org" > *Subject: *[sipcore] 4028bis: memory refresh > > Hi, > > Now, when the sip-oauth draft is more or less done (in the RFC > editor’s queue), I intend to take up the work on 4028bis > (session-timer) again. > > We previously had e-mail discussions and phone calls, there is an > issue tracker on GitHub, and we discussed the suggested solutions at > IETF#103. To refresh your memory, please take a look at the video: > https://www.youtube.com/watch?v=C2yeckBmgPg (the session-timer > presentation begins at around 7:30 minutes). > > The decision to make a bis (instead of an update draft) has already > been made, but please take a look at the technical suggestions for > fixing the glare situation. > > Regards, > > Christer > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Thu May 21 10:11:49 2020 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 400F03A0A19 for ; Thu, 21 May 2020 10:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 WaViLjyKAWJI for ; Thu, 21 May 2020 10:11:45 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1.hushmail.com [65.39.178.135]) (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 230B33A09DB for ; Thu, 21 May 2020 10:11:44 -0700 (PDT) Received: from smtp1.hushmail.com (localhost [127.0.0.1]) by smtp1.hushmail.com (Postfix) with SMTP id 7A8E2404F8 for ; Thu, 21 May 2020 17:11:44 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=FRN6m8wJNRaCHRDvlXGhpZDPNHA7PT0962W5ICvnKSM=; b=Y1dcsH90rwUTM9pmr5x4kRxVjG50ySC1HtigjKhHJv5gN8di57MciEKXjAPoh9DBJeFVdoTdPPDdfO8COGulvTJHZ3VBK0oSDtWCmI9+BOPkg2UU0ZzXISRNhMfI75/gmu/SudeP2p57tugV4dls+r2+t7qGObl+wuU9zc96YaaLUl40FOQKPTQ0HiTQE2GGNEMLV21LizLNqJeEkA4rdcvw2qu8qrSAzNmRO7qzY1qh7K1AEus/+lpKH6DV3jmfibzqndRW8sLBMD5Biuhij/3kScwaRr+1bCg4HcmwhWMuNvVUqhm6iofl8x79Byp6LSML9pyEKanbhv82u412fw== Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.hushmail.com (Postfix) with ESMTPS; Thu, 21 May 2020 17:11:43 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id AF1F9E0793; Thu, 21 May 2020 17:11:43 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 21 May 2020 23:11:43 +0600 To: sipcore@ietf.org, hgs@cs.columbia.edu From: "Samir Srivastava" References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="=_03acecc46ae6a3861220ebef60ffc86b" Message-Id: <20200521171143.AF1F9E0793@smtp.hushmail.com> Archived-At: Subject: [sipcore] Comment on https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/?include_text=1 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 17:11:47 -0000 --=_03acecc46ae6a3861220ebef60ffc86b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, Chapter 9, Para 3 states Thus, a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446]. What about protection from DTLS? There may be hops which may be protected by IPSEC tunnel. BTW how many deployments of SIPS, we have?? We need to modify the statement. ThanksSamir Srivastava https://samirsrivastava.typepad.com - End of Unfairness --=_03acecc46ae6a3861220ebef60ffc86b Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,=

  Chapter 9, Para 3 states

   =
Thus, a UAS SHOULD NOT trust the information in the "Call-Info"
   header field unless the SIP session between the entity inserting the
   header field and the UAS is protected by TLS [RFC8446].
=
  What about protection from DTLS? There may be hops wh= ich may be protected by IPSEC tunnel.

  BTW h= ow many deployments of SIPS, we have??  We need to modify the statemen= t.

Thanks
Samir Srivastava


https://samirsrivastava.typepad.com      =  -    End of Unfairness
 --=_03acecc46ae6a3861220ebef60ffc86b-- From nobody Thu May 21 10:14:56 2020 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 9B98D3A0A7B for ; Thu, 21 May 2020 10:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 xXgxztTNus8t for ; Thu, 21 May 2020 10:14:53 -0700 (PDT) Received: from mail-oi1-x233.google.com (mail-oi1-x233.google.com [IPv6:2607:f8b0:4864:20::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 D1C453A0A78 for ; Thu, 21 May 2020 10:14:52 -0700 (PDT) Received: by mail-oi1-x233.google.com with SMTP id y85so6789802oie.11 for ; Thu, 21 May 2020 10:14:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pgSbcqan1CmcqtpLjagV0Czx2D9gb3cu9k/LqaWkTjw=; b=D7Zs6NDroTnth22BhsVKi/h4RPAi0AZiMr2BnQWda6DElHScaFu2C4541S1mBhsBRj BraJAjNe1ZpEFyb5KfUJk7e8Z3EkpiX41EOlKYE5lAbv9OvGuqvPx5KdZe0CV6bttW7k sAekI214dgl7Oor9bxgcwVXA6Of1xUQrsW/qprxtruVjOUE7l48embNh5d8kdnlRdF+3 IUm7yavF7SYNWuNCl4NGlTNaMWnLj9PNsVII0gboc7C6HfzXsdLpyg31mS/fxKH5ZGHT sHHYnVI3Cmu0fXgY6nWOHYACwjWmNn3WOLRziJuLdC8CfgMRWj2tOwGImqivN+4DOn7h GX6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pgSbcqan1CmcqtpLjagV0Czx2D9gb3cu9k/LqaWkTjw=; b=sVmoqoTCI6oKezZppb35I4Pp+Ulhq1Z12xQiA0ZGXKxSzMC6J//OZcNDHcfj+aGa6N M8314uKsNYUrwOt3xkVvzmvGFmTFZR7GKnUIKveoQ8nRnFCYrlFOfMarZQsmQhReJvu1 aP3zb6eGBHj5QVm0EgAtJs4MkttU4k2JIUNR4R2a8O5WhCn8EHHo457+0FEyctPKbofj OnAZoYwcDqGQQ3WaTjLKZsKNJmBHD8cp42/VlBGWwPX2/rRJ26p5ALR5eXkDMMa+2OYU 6FHmNDkO7K684hlTJQCJYzn4mdIMmf4xfNy9fvluRMEET/AQ5iFHTS+/2tRbCqJwvFzR Kr3g== X-Gm-Message-State: AOAM532yxk5JZbnqqFh7gX1Q3/8n2mbbYIrlwauTZMrQRBjzryzm1/0V 9ZRIQqk5A3m0dSjYSYvon7+kS1j5JcQ= X-Google-Smtp-Source: ABdhPJxPka6UnxsUaeJO3m89uopM9lvP9O5B9FiHUJfx96smJqYVnPJWr/jZnuPh6XnysQRhgd8A7w== X-Received: by 2002:aca:d496:: with SMTP id l144mr7692943oig.72.1590081291630; Thu, 21 May 2020 10:14:51 -0700 (PDT) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com. [209.85.167.179]) by smtp.gmail.com with ESMTPSA id z12sm1818648oor.0.2020.05.21.10.14.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 10:14:50 -0700 (PDT) Received: by mail-oi1-f179.google.com with SMTP id d191so6804694oib.12 for ; Thu, 21 May 2020 10:14:50 -0700 (PDT) X-Received: by 2002:aca:4747:: with SMTP id u68mr7644016oia.139.1590081290190; Thu, 21 May 2020 10:14:50 -0700 (PDT) MIME-Version: 1.0 References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> <20200521171143.AF1F9E0793@smtp.hushmail.com> In-Reply-To: <20200521171143.AF1F9E0793@smtp.hushmail.com> From: Roman Shpount Date: Thu, 21 May 2020 13:14:39 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Samir Srivastava Cc: SIPCORE , Henning Schulzrinne Content-Type: multipart/alternative; boundary="0000000000007743d705a62ba67d" Archived-At: Subject: Re: [sipcore] Comment on https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/?include_text=1 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 17:14:55 -0000 --0000000000007743d705a62ba67d Content-Type: text/plain; charset="UTF-8" There is no SIP over DTLS. _____________ Roman Shpount On Thu, May 21, 2020 at 1:11 PM Samir Srivastava wrote: > Hi, > > Chapter 9, Para 3 states > > Thus, a UAS SHOULD NOT trust the information in the "Call-Info" > header field unless the SIP session between the entity inserting the > header field and the UAS is protected by TLS [RFC8446]. > > > What about protection from DTLS? There may be hops which may be > protected by IPSEC tunnel. > > BTW how many deployments of SIPS, we have?? We need to modify the > statement. > > Thanks > Samir Srivastava > > > > https://samirsrivastava.typepad.com - End of Unfairness > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0000000000007743d705a62ba67d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There is no SIP over DTLS.
_____= ________
Roman Shpount


On Thu, May 21, 2020 at 1:11 PM Sa= mir Srivastava <srivastava_samir=3D40hush.com@dmarc.ietf.org> wrote:
Hi,

=C2=A0 Chapter 9, Para 3 sta= tes

   Thus, a UAS SHOULD NOT trust the infor=
mation in the "Call-Info"
   header field unless the SIP session between the entity inserting the
   header field and the UAS is protected by TLS [RFC8446].
=
=C2=A0 What about protection from DTLS? There may be hops wh= ich may be protected by IPSEC tunnel.

=C2=A0 BTW h= ow many deployments of SIPS, we have??=C2=A0 We need to modify the statemen= t.

Thanks
Samir Srivastava


https://samirsrivastava.typepad.com=C2= =A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 End of Unfairness
______= _________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
--0000000000007743d705a62ba67d-- From nobody Thu May 21 10:34:08 2020 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 D468F3A0AAB for ; Thu, 21 May 2020 10:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hush.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 OEBYpZIgMXC5 for ; Thu, 21 May 2020 10:34:02 -0700 (PDT) Received: from smtp5.hushmail.com (smtp5.hushmail.com [65.39.178.142]) (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 AE9C93A0ACB for ; Thu, 21 May 2020 10:34:00 -0700 (PDT) Received: from smtp5.hushmail.com (localhost [127.0.0.1]) by smtp5.hushmail.com (Postfix) with SMTP id 5502620252 for ; Thu, 21 May 2020 17:34:00 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=rLzXJd0yNcmdld4aOO5XZhrRYSYT8y9d3Uu+aDQZOsE=; b=aZWtq7IqlC+5GkKLoElY9OpM5yP5IL4L14l9Ah4sdOQcomzqKazqd8fTWvlYSQAsQZN7WJ/nRO1YufC6SjAmuQIl3+1f2C6vX2JYkl4rV3CYH8FBzMR0w/3U47gHMzJy8f/WTfAzf7ZUk3DFjx76ztAwJclR8Z4a4PCFjWNCh9EfBKSDb/h/k7uXNaAzfz9k499UBLFfkxlp1/g2vZscCFpY1nJ220/YFU+UzTE/DUp5Tugqy9xSF9f4db4FIyYPdSTMWoyZmhD7RFtJaRF2x56igi+sRISWu0O7oS6w43e1ur4B7LxFtv00iJIAWi7S15WXrTSlC2rTJnyXCJuL+w== Received: from smtp.hushmail.com (w2.hushmail.com [65.39.178.46]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp5.hushmail.com (Postfix) with ESMTPS; Thu, 21 May 2020 17:33:59 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id C3973E0794; Thu, 21 May 2020 17:33:59 +0000 (UTC) MIME-Version: 1.0 Date: Thu, 21 May 2020 23:33:59 +0600 To: "Roman Shpount" , "Samir Srivastava" Cc: "SIPCORE" From: "Samir Srivastava" In-Reply-To: References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> <20200521171143.AF1F9E0793@smtp.hushmail.com> Content-Type: multipart/alternative; boundary="=_9141b76cc78c8b3a148c88107febc591" Message-Id: <20200521173359.C3973E0794@smtp.hushmail.com> Archived-At: Subject: Re: [sipcore] Comment on https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/?include_text=1 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 17:34:06 -0000 --=_9141b76cc78c8b3a148c88107febc591 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, Long time back when I wrote ciphersuite draft, I mention DTLS in SIP too in the email discussion.IMHO SIPS No momentum, We need to take this statement out.If we do not take this out, then mention DTLS here and write one draft for SIP Over DTLS. Thanks Samir Srivastava http://samirsrivastava.typepad.com - End of unfairness On 5/21/2020 at 10:45 PM, "Roman Shpount" wrote:There is no SIP over DTLS. _____________ Roman Shpount On Thu, May 21, 2020 at 1:11 PM Samir Srivastava wrote: Hi, Chapter 9, Para 3 states Thus, a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446]. What about protection from DTLS? There may be hops which may be protected by IPSEC tunnel. BTW how many deployments of SIPS, we have?? We need to modify the statement. ThanksSamir Srivastava https://samirsrivastava.typepad.com - End of Unfairness_______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --=_9141b76cc78c8b3a148c88107febc591 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8" Hi,

Long time back when I wrote ciphersuite draft, I = mention DTLS in SIP too in the email discussion.
IMHO SIPS No momentum,= We need to take this statement out.
If we do not take this out, = then mention DTLS here and write one draft for SIP Over DTLS.
Thanks

Samir Srivastava

=

ht= tp://samirsrivastava.typepad.com    - End of unfairness

On 5/21/2020 at 10:45 PM, "Roman Shpount" <roman@telurix.com> w= rote:
There is no SIP over DTLS.
_____________
Roman Shp= ount


On Thu, May 21, 2020 at 1:11 PM Samir Srivastava <sr= ivastava_samir=3D40hush.com@dmarc.ietf.org> wrote:
Hi,

  Chapter 9, Para 3 states

Thus, a UAS SHOULD NOT trust the information in the "Call-Info" header field unless the SIP session between the entity inserting the header field and the UAS is protected by TLS [RFC8446].
=
  What about protection from DTLS? There may be hops wh= ich may be protected by IPSEC tunnel.

  BTW h= ow many deployments of SIPS, we have??  We need to modify the statemen= t.

Thanks
Samir Srivastava


https://samirsrivastava.typepad.com&= nbsp;      -    End of Unfairness
____= ___________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--=_9141b76cc78c8b3a148c88107febc591-- From nobody Thu May 21 10:43:50 2020 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 721C73A0ACD for ; Thu, 21 May 2020 10:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telurix-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 goHudtVjQSyV for ; Thu, 21 May 2020 10:43:46 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 A11973A0ACB for ; Thu, 21 May 2020 10:43:46 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id y85so6868246oie.11 for ; Thu, 21 May 2020 10:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telurix-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cNMzqD3lGpERZMuWuBEQMufC+ykfIyjbMYLq9Sf57I4=; b=xb9s6npebudHv6JRQyPTvi0GqRxGbf23oEpWoBOsdYTlVa2vx7o1LGGEN06+ZZdPn5 F0FHPnlfzDv7zajQfofbcBiQD1z/gu/AisUc34q5k8KfGtxgBdEarnvOOTg1HnN2l9tL oF3T4IRQ6gfnRonWpDMXa0cA2qhDjA6iyFqB8ubxA62o7zoHE930md40f4Atu3UPEv3L 5eaD9jJyAsqYGfbZKcf2ddRf0iEhXMDcf0OxzWfPZPWGGuYTPempflnHqV4Jo/D94XuS jmnhF/seAqqMzPZ5A7ZsLieOPUq+BZk4WFLtM6C+KviwT4ufzkpKasphco75AxJu8IBH cQ3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cNMzqD3lGpERZMuWuBEQMufC+ykfIyjbMYLq9Sf57I4=; b=Izn7KyNTf2EBdAmNvp4dqAkZ9cMEsRCzx4Qr1De2gf0riV78sdHLwwJpiIk1jhQ3NH BNxXxv9C+6eBtin3XpszxcPMywYTTXNxdxbu3ZF+hQwTi9rBRm70jl0MmkJAymnQnRJf SbmEW9boi4Ir9f+2FvsKygHhECMlYXdI2POHG9N+oqcFe8++m6Bz/3z9IRkB3I+7xwhr keVTevaBy6j8489cNvy6TnmHa+Q65XcsKJemK9AjrDpZkP84D86xO+H/pH8TRs2lnU2g vlt+MCInK87X812z3c5gdIMoh1gB90TZPb/rIz3CHTNuJ6+yJGqM4A+l5p7vIwtVl0sr Acng== X-Gm-Message-State: AOAM532y6CkeOuRarFVf2HMucyjIzdY80Rj65pngUl415HX+5ran5bLh GJTjjUSaEMs7GufMa5aP+iVRQjIbgqg= X-Google-Smtp-Source: ABdhPJwI+bVyfiN0yjm3FVnYbEEwmhbSmdQLX+y+GWG/nKKq+mKBztEe6XaWX0UkySOGRWREc44Hgw== X-Received: by 2002:aca:d493:: with SMTP id l141mr7959305oig.20.1590083025280; Thu, 21 May 2020 10:43:45 -0700 (PDT) Received: from mail-ot1-f44.google.com (mail-ot1-f44.google.com. [209.85.210.44]) by smtp.gmail.com with ESMTPSA id z12sm1839650oor.0.2020.05.21.10.43.43 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 21 May 2020 10:43:44 -0700 (PDT) Received: by mail-ot1-f44.google.com with SMTP id o13so6172038otl.5 for ; Thu, 21 May 2020 10:43:43 -0700 (PDT) X-Received: by 2002:a9d:5d08:: with SMTP id b8mr7926244oti.19.1590083023614; Thu, 21 May 2020 10:43:43 -0700 (PDT) MIME-Version: 1.0 References: <20200510131235.8E2A6C0171@smtp.hushmail.com> <854d7cef-03eb-8974-9159-c493df015996@alum.mit.edu> <8414733e-a5d9-2502-6a89-d6460d931be9@ntlworld.com> <20200511153943.792F620111@smtp.hushmail.com> <32547453-1350-b8a2-d7a5-fc253cf3eaf4@ntlworld.com> <20200512105430.7F9542011C@smtp.hushmail.com> <20200521171143.AF1F9E0793@smtp.hushmail.com> <20200521173359.C3973E0794@smtp.hushmail.com> In-Reply-To: <20200521173359.C3973E0794@smtp.hushmail.com> From: Roman Shpount Date: Thu, 21 May 2020 13:43:32 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Samir Srivastava Cc: Samir Srivastava , SIPCORE Content-Type: multipart/alternative; boundary="000000000000c93f0805a62c0de5" Archived-At: Subject: Re: [sipcore] Comment on https://datatracker.ietf.org/doc/draft-ietf-sipcore-callinfo-spam/?include_text=1 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 May 2020 17:43:49 -0000 --000000000000c93f0805a62c0de5 Content-Type: text/plain; charset="UTF-8" Samir, DTLS needs to be fixed first to allow multiplexing multiple DTLS connections over the same source/destination address/port pairs. If this is done, I am willing to write a SIP-over-DTLS draft. Until DTLS multiplexing is added, SIP-over-DTLS is not very useful since it cannot be used in a manner similar to SIP-over-UDP and provides no benefits to SIPS (SIP-over-TLS). I do agree that TLS sentence in draft-ietf-sipcore-callinfo-spam needs to be relaxed and does not reflect common operating procedures for SIP with telecom operators, which are SIP-over-UDP over private links or IPSEC, and not SIPS over TLS. SIPS over TLS is mostly used to connect calls from service providers to end users over public internet. Best Regards, _____________ Roman Shpount On Thu, May 21, 2020 at 1:34 PM Samir Srivastava wrote: > Hi, > > Long time back when I wrote ciphersuite draft, I mention DTLS in SIP too > in the email discussion. > IMHO SIPS No momentum, We need to take this statement out. > If we do not take this out, then mention DTLS here and write one draft for > SIP Over DTLS. > > Thanks > > Samir Srivastava > > > http://samirsrivastava.typepad.com - End of unfairness > > > On 5/21/2020 at 10:45 PM, "Roman Shpount" wrote: > > There is no SIP over DTLS. > _____________ > Roman Shpount > > > On Thu, May 21, 2020 at 1:11 PM Samir Srivastava 40hush.com@dmarc.ietf.org> wrote: > >> Hi, >> >> Chapter 9, Para 3 states >> >> Thus, a UAS SHOULD NOT trust the information in the "Call-Info" >> header field unless the SIP session between the entity inserting the >> header field and the UAS is protected by TLS [RFC8446]. >> >> >> What about protection from DTLS? There may be hops which may be >> protected by IPSEC tunnel. >> >> BTW how many deployments of SIPS, we have?? We need to modify the >> statement. >> >> Thanks >> Samir Srivastava >> >> >> >> https://samirsrivastava.typepad.com - End of Unfairness >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > --000000000000c93f0805a62c0de5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Samir,

DTLS needs to be fixed first to = allow multiplexing multiple DTLS connections over the same source/destinati= on address/port pairs. If this is done, I am willing to write a SIP-over-DT= LS draft.

Until DTLS multiplexing is added, SIP-ov= er-DTLS is not very useful since it cannot be used in a manner similar to S= IP-over-UDP and provides no benefits to SIPS (SIP-over-TLS).

=
I do agree that TLS sentence=C2=A0in=C2=A0draft-ietf-sipcore-cal= linfo-spam=C2=A0needs to be relaxed and does not reflect common operating p= rocedures for SIP with telecom operators, which are SIP-over-UDP over priva= te links or IPSEC, and not SIPS over TLS. SIPS over TLS is mostly used to c= onnect calls from service providers to end users over public internet.

Best Regards,
_____________Roman Shpount


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, May 21, 2020 at 1:34 PM Samir = Srivastava <srivastava_sami= r@hush.com> wrote:
Hi,

Long time back when I wrote ciphersuite draf= t, I mention DTLS in SIP too in the email discussion.
IMHO SIPS No mome= ntum, We need to take this statement out.
If we do not take this = out, then mention DTLS here and write one draft for SIP Over DTLS.

Thanks

Samir Srivastava


http://samirsrivastava.typepad.com=C2=A0 =C2=A0 - = End of unfairness


On 5/21/2020 at 10:45 PM, "Roman Shpount&= quot; <roman@telu= rix.com> wrote:
There is no SIP= over DTLS.
_____________
Roman S= hpount


On Thu, May 21, 2020 at 1:11 PM Samir Srivastava <= srivastava_samir=3D40hush.com@dmarc.ietf.org> wrote:
Hi,

=C2=A0 Chapter= 9, Para 3 states

   Thus, a UAS SHO=
ULD NOT trust the information in the "Call-Info"
   header field unless the SIP session between the entity inserting the
   header field and the UAS is protected by TLS [RFC8446].
=
=C2=A0 What about protection from DTLS? There may be hops wh= ich may be protected by IPSEC tunnel.

=C2=A0 BTW h= ow many deployments of SIPS, we have??=C2=A0 We need to modify the statemen= t.

Thanks
Samir Srivastava


https://samirsrivastava.typepad.com=C2= =A0 =C2=A0 =C2=A0 =C2=A0-=C2=A0 =C2=A0 End of Unfairness
______= _________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--000000000000c93f0805a62c0de5-- From nobody Wed May 27 01:12:08 2020 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 7145E3A0B59 for ; Wed, 27 May 2020 01:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 9VPvGtYk2ZgZ for ; Wed, 27 May 2020 01:12:06 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (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 894BD3A0B5A for ; Wed, 27 May 2020 01:12:06 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id p30so11412316pgl.11 for ; Wed, 27 May 2020 01:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=a321YoP8It022vxgcFPnbEPWeVTFVylzSd2xh8vMoy0=; b=GY1McsFFImXPgHTP72ikidmvcr0lhAoj3OT6W7o01CMWkhf6rZUm5Q7iFXqALS/yGC 0ze93P6xOYEHtVdK1aDcCuzRiK/iQ9xChryQjUcL1qqOAtmnQIBbRaYHhZnNTCOzPKiH Hdy5/2IbcPjWVjG9kMEXF68rRwRqPhmvbQH3Tqysx7JM0zpWCh/TNwJQGsrLzsm4S7bw ebSQ8kORxoZfjs+TFNvSD5WI1JgCuUeZXUrxxW+T6TgvAbunJzWvtvlyipXPIJ74QdQj Zj4Q9MmYe7ZmF9nb+H8LH+JIFDN9lfuWxK9aOKqY/BNUcvqiLJyiAyr7rpWa8sM4fV2J nWXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=a321YoP8It022vxgcFPnbEPWeVTFVylzSd2xh8vMoy0=; b=ZPFvynZGWone1e0zqw9Ys4XaaPm7exOkzSHqGpkSy+BuGfxhldm6bS9yK1EAbMCxFu CQd1c2+OCK2aIcTIVQsbtMpRaJO/wtny8k0s4pZqaXFSkwZZcYCBGtxXvZHf/sPVvsJI MnKea2yeGEw3ChpBWEmjJDRHQ9Cx+SwymBxjoGrKOo4rteq1oeJ80AyCWrKp+Hq8eiZU C1ob8tzpOU0LL/rKF9TC8+BeW2s3jfcMouVXCH+yIwOW+eMG3ge7yqy5QUpIQwOdhZ3A sl1y072HBMc28TVTDxExxu6RbhGSWYrC1fO5kLxTB5Xzo3mAhEaTTO+vTjP9u5CN83Ct 9iYg== X-Gm-Message-State: AOAM532ShP6uJlW6oN035OJntJRf5judb+NfHQeq5G/TUsYGR0Yu4Y+U ZMTgnfSJmHFDS0yONOSIfykPo6au X-Google-Smtp-Source: ABdhPJw3jkmnzFfEspjdyPRZ1n59PZmfraNd/oZ+cKV2HEBVguOuXio/njWtsaFwRq3UcqPHUPZP9A== X-Received: by 2002:a62:a50d:: with SMTP id v13mr2650837pfm.153.1590567124896; Wed, 27 May 2020 01:12:04 -0700 (PDT) Received: from [192.168.1.127] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id nl8sm1951855pjb.13.2020.05.27.01.12.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 01:12:03 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Cc: Christer Holmberg Message-ID: Date: Wed, 27 May 2020 17:12:00 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 08:12:07 -0000 Hi, In following scenario, (1) Alice sends INVITE. (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol. (4) Proxy2 rejects INVITE by 422. (6) Carol accepts INVITE by 200. Eventually Bob never receive INVITE.        Alice        Proxy1    Proxy2(->Bob) Carol          |(1) INVITE  |            | ||          |SE:1800     |            | ||          |----------->|            | ||          |            |(2) INVITE  | ||          |            |SE:1800     | ||          | |------------------------>|          |            |(3) INVITE  | ||          |            |SE:1800     | ||          |            |===========>| ||          |            |(4) 422     |       |          |            |MSE:3600    |       |          | |<===========|            |          |            |(5) ACK     | |          | |===========>|            |          |            |(6) 200 OK |          |            |SE:1800 |          | |<------------------------|          |(7) 200 OK  | |          |SE:1800     | | |<-----------|                         |          |(8) ACK     | | |----------->|                         |          |            |(9) ACK |          | |------------------------>| I hope that 4028bis addresses this issue. Regards, Shinji From nobody Wed May 27 03:16:31 2020 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 DBC6B3A0CAE for ; Wed, 27 May 2020 03:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 ajv9L2SsYKRp for ; Wed, 27 May 2020 03:16:28 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80047.outbound.protection.outlook.com [40.107.8.47]) (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 699E23A0CAA for ; Wed, 27 May 2020 03:16:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nJjYFMJZbgKImTZMSHKFkyc8k6cirkFKdv1EdPyGvBcG53HQthzuvx882fwmtqTfrl4ERL5g0Po/x/WGlkZ2X2mUJTat7OdwMZ+mQRHlUZXA4fVQm6Y9nIcNqKq9FUM0Q2/UcldNHBMP/+rQwdgtpZe+K9ICruFOIfziaDjf5J4377Ka1sE1f8LFdJ6lhr4zj0I/koSq3mRLLe6zQZmkZWLa65Ni7OgYJeWjJiWBNXtWtL1rj6QqyRXR/x4WHAtQXYYjn8Y3vGdhsq3eeJHADubW9A3dLayi20hcbiAKEJKF211+edm3fC5aqaS5raDxFXB6GRmb8yA31FtAOvMgHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=He9XcCooUCCpwG0BiU24MBLXJAOCeA/0ErWMJH0Vn78=; b=aEK3A/m7auBO+H2FPM7QWOVRUDx0oQksW4/tRCEhfYEb1JfQM2j28jOPeXvH+cZAAvEDXAreOJfApicBMP7PjSBPZBjChj4B23h2sS1Zu+x3JJn1GLfSisRjQrXxMrlCUInU+f1ah7QeuZdCjqmOqc0msrM+Pk+ZgYby0obHtq3a0rIorYt6wNW02DlE4DufPY3gppTn1gF0iSATZWUP8YJkKFlOO96sD5AXXTA4L0K6vBQKdd/LkPw0ksCSJzllp5Uj1jn2dhM6KNLEmj3X2WvFKIk/0NBXqhthVt01ZvTK3mLhJdfjixpwnlQSUe50FHas4XzIUHBkKmlZlPEtEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=He9XcCooUCCpwG0BiU24MBLXJAOCeA/0ErWMJH0Vn78=; b=OwEpsdEzWl5KwFv4OQzCEZOdMTPS8oQiQ775mdrS78QdK4lIe1b7ZHDslvlmxJ01lVIt1+yK5KtzOVSRN3ELFgltvA5DtNWjmIJ+BRUkh1xGQpsO6NwSxfvRiqtUVPK5pb7Nj82Nm9cRKRYsa7wfb3onnM+8enMCQNuNtdpw6uk= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6471.eurprd07.prod.outlook.com (2603:10a6:20b:135::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Wed, 27 May 2020 10:16:24 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3066.007; Wed, 27 May 2020 10:16:24 +0000 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: 4028bis: forking Thread-Index: AQHWM/6HmaOdA74mGkCkKN9wxcQ7i6i76gsA Date: Wed, 27 May 2020 10:16:24 +0000 Message-ID: <6BD34002-7DC1-445B-94ED-3F3C7F5944C2@ericsson.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.36.20041300 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: de0ee185-de4e-416a-ddb4-08d802270285 x-ms-traffictypediagnostic: AM7PR07MB6471: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 04163EF38A x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ELmrSFv5cjsIKI8H1sHslmVPXNIAUGS0a3PmQsB8P3VKQP6CB2q5ESp8uF7cokpV/3UnXxD/qFiM3z8j3yn0ZGtBMAY5M8pC5DftjlJNOBotwJ2XVXEU7/pXk5aPSCyCJmDNRPMsNgkXHPNzO75CRjAB9dfRTFz/JHURAu5bF8pokCGHm16hxXJBQzn9EqycL/GtX4A/onP3/uQ8Jt5i9JRM9hpSFEhcyZtxPmpr8lYCjKcYN4R+yt8UiNN3heBhMNK3MY4koAqX5aFUYsNTX+d0Z81x6VO6DVdmCz/v04gr3AstAuSlRYkEO4TxN/wCruMZCWzpIQcOsneYkgfQjA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(376002)(136003)(366004)(346002)(39860400002)(6486002)(6512007)(71200400001)(44832011)(4744005)(5660300002)(2906002)(2616005)(316002)(91956017)(76116006)(186003)(66946007)(110136005)(478600001)(33656002)(6506007)(66556008)(8936002)(36756003)(26005)(64756008)(86362001)(66476007)(83380400001)(8676002)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: W4MUSG6kkWbALmEel/61PLaXNtCaxfW/crdU5/j7cPo5PiiTKfH0nJGoeEg/oBa6iGZYKpBB8pJU5wEZr58uq1zqWMhj64xL636lvGOB5yLYmsKsUPJgRjSFN553L5Hy2Nbi0TBrr8u7y4iqx8Qg9gvkKwT1c/g4nfuVWphIBMHgs8DxYarv0GF5Vw+TxxGbtNH6aZd3DLjhDF7NSxVbO7BeVFGDLHCnjZoQ86iCL7uWvS6ablXF9UHQlM9ku0IgaD1GOI6Bz13RvY/lQGksPdp2PEt7GdVcjoXsHhqGyY2fObZF9JSHaBg/19eoKvFSqc6H3ykBcPVl4ZSLBbKC9vtYcMmU/UU9jZqwi6uy90ByLL/4htSz5tExf5wfPFC72rpDmVZfGr6HR5swm4GQ1wHBQ37VE4/pn0+yGqxHErJdDoA9txbfDFUBVducElDkFxdM6d4UzJiXgW7vGXUX8KlLe/3++LhUhezlPxR4NpKH8nZ7Uijkf8GwCcLW8CJU x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <95F877D0ECEAE34FA9EAB081B9687E7A@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: de0ee185-de4e-416a-ddb4-08d802270285 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 May 2020 10:16:24.1366 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: k1MorVkfggL0FInUvRHBIecWpGqfocYkGcgvW/rE0h46MTXIGZQt/3LMlmMxQPd0oG3eIuIfXUd6hG+fdM85uzDv9R4cLvpLIWsdcsjFEJY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6471 Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 10:16:30 -0000 SGksDQoNCkEgcHJveHkgcmVqZWN0aW5nIGEgcmVxdWVzdCBpcyBub3QgdW5pcXVlIHRvIHRoZSBz ZXNzaW9uLXRpbWVyLg0KDQpJZiBBbGljZSByZWNlaXZlcyBhIDQyMiBzaGUgY2FuIHNlbmQgYSBD QU5DRUwgKGlmIG90aGVyIGVhcmx5IGRpYWxvZ3MgaGF2ZSBiZWVuIGVzdGFibGlzaGVkKSwgYW5k IHRoZW4gYSBuZXcgaW5pdGlhbCBJTlZJVEUuDQoNClJlZ2FyZHMsDQoNCkNocmlzdGVyDQoNCg0K 77u/T24gMjcvMDUvMjAyMCwgMTEuMTIsICJPS1VNVVJBIFNoaW5qaSIgPGlldGYuc2hpbmppQGdt YWlsLmNvbT4gd3JvdGU6DQoNCiAgICBIaSwNCg0KICAgIEluIGZvbGxvd2luZyBzY2VuYXJpbywN CiAgICAoMSkgQWxpY2Ugc2VuZHMgSU5WSVRFLg0KICAgICgyKSBQcm94eTEgZm9ya3MgSU5WSVRF IHRvIFByb3h5Mihmb3IgQm9iKSBhbmQgQ2Fyb2wuDQogICAgKDQpIFByb3h5MiByZWplY3RzIElO VklURSBieSA0MjIuDQogICAgKDYpIENhcm9sIGFjY2VwdHMgSU5WSVRFIGJ5IDIwMC4NCg0KICAg IEV2ZW50dWFsbHkgQm9iIG5ldmVyIHJlY2VpdmUgSU5WSVRFLg0KDQogICAgICAgICAgICBBbGlj ZSAgICAgICAgUHJveHkxICAgIFByb3h5MigtPkJvYikgQ2Fyb2wNCiAgICAgICAgICAgICAgfCgx KSBJTlZJVEUgIHwgICAgICAgICAgICB8IHx8DQogICAgICAgICAgICAgIHxTRToxODAwICAgICB8 ICAgICAgICAgICAgfCB8fA0KICAgICAgICAgICAgICB8LS0tLS0tLS0tLS0+fCAgICAgICAgICAg IHwgfHwNCiAgICAgICAgICAgICAgfCAgICAgICAgICAgIHwoMikgSU5WSVRFICB8IHx8DQogICAg ICAgICAgICAgIHwgICAgICAgICAgICB8U0U6MTgwMCAgICAgfCB8fA0KICAgICAgICAgICAgICB8 IHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KICAgICAgICAgICAgICB8ICAgICAgICAgICAg fCgzKSBJTlZJVEUgIHwgfHwNCiAgICAgICAgICAgICAgfCAgICAgICAgICAgIHxTRToxODAwICAg ICB8IHx8DQogICAgICAgICAgICAgIHwgICAgICAgICAgICB8PT09PT09PT09PT0+fCB8fA0KICAg ICAgICAgICAgICB8ICAgICAgICAgICAgfCg0KSA0MjIgICAgIHwgICAgICAgfA0KICAgICAgICAg ICAgICB8ICAgICAgICAgICAgfE1TRTozNjAwICAgIHwgICAgICAgfA0KICAgICAgICAgICAgICB8 IHw8PT09PT09PT09PT18ICAgICAgICAgICAgfA0KICAgICAgICAgICAgICB8ICAgICAgICAgICAg fCg1KSBBQ0sgICAgIHwgfA0KICAgICAgICAgICAgICB8IHw9PT09PT09PT09PT58ICAgICAgICAg ICAgfA0KICAgICAgICAgICAgICB8ICAgICAgICAgICAgfCg2KSAyMDAgT0sgfA0KICAgICAgICAg ICAgICB8ICAgICAgICAgICAgfFNFOjE4MDAgfA0KICAgICAgICAgICAgICB8IHw8LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tfA0KICAgICAgICAgICAgICB8KDcpIDIwMCBPSyAgfCB8DQogICAgICAg ICAgICAgIHxTRToxODAwICAgICB8IHwNCiAgICB8PC0tLS0tLS0tLS0tfCAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgICAgICAgICAgIHwoOCkgQUNLICAgICB8IHwNCiAgICB8LS0tLS0t LS0tLS0+fCAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgICAgIHwgICAgICAg ICAgICB8KDkpIEFDSyB8DQogICAgICAgICAgICAgIHwgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LT58DQoNCiAgICBJIGhvcGUgdGhhdCA0MDI4YmlzIGFkZHJlc3NlcyB0aGlzIGlzc3VlLg0KDQog ICAgUmVnYXJkcywNCiAgICBTaGluamkNCg0KDQoNCg== From nobody Wed May 27 10:48:11 2020 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 945B63A0788 for ; Wed, 27 May 2020 10:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu 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 zUK0oV9MZEL3 for ; Wed, 27 May 2020 10:48:08 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760052.outbound.protection.outlook.com [40.107.76.52]) (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 5A66C3A064C for ; Wed, 27 May 2020 10:48:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UhLJZXjDxbAUiemVC6STNy0vblig/8TCmtSWts3PNiZd+f5oLw4/hWhGXDVWPX6i7UZodZRyhzo6jKy2BuoTybZSSSSFmXsH+RxhtHULyPmYc6vxKY35modnKDeA36xOUj350RG3Rqz1QGnUOBxqkvmTD2SxwS7DHPzObB4HhMQfRjWR4AwRk7LX24skRG3FIJ4XrkNXvySD42M2oU2F7UxRHpDYGjTVHWW7OTGSryULXJzak6+tv6l+PwA5nY2LCG2gDZger46jDZ7nUR9WXAJKD+xz3YB9cgYtzQ+XZMpDLn6XQjGN5d4Dp1u4yEvAnu4SnXoDdhWVS+YL1yTInA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J4f9+NcFfmdiNBDS9ydEX2dUUozxfCfQixD9yqUBxWw=; b=DPXt0XjPvd78ZqIc6dTaAeRGSLnuQRupzXjqqPrbDC2r0bTHd5z12j4O/xbRhU8kfyh6ClrS20zYyB1vnRHCp8ZPI3sRmQboNHijqTDfMbLtV0sYcnXWjwueWizSA1Q2tPKYv+kHAe95osPHSfdcNHynDnFkn9QMUNdpx0v4OhexHJpa/PMa43fRfIZRiviLxjzD2o5euW9NC32hplSUVt1jog9GD0imJaBOYVheWgG0Bbw9d1E2Kp3FVC6klkaY6X7bJT21iRR2sGr9oPEaV8OklJpteGmOFHML+VMN+cspJ5kZsmV3AfUamEA8pk7GJwCMWQdz+dXSDhuXCVS9oQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=permerror (sender ip is 18.7.68.33) smtp.rcpttodomain=gmail.com smtp.mailfrom=alum.mit.edu; dmarc=none action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J4f9+NcFfmdiNBDS9ydEX2dUUozxfCfQixD9yqUBxWw=; b=VkIKjup335LqFbO0W7o5kCiwKzaZ26lTGdBiRs3XEu8hl521By9tczBwSlxqmDorLBB6UQdm5Pb1NcVIiMxtS6pS5DCuy1qrKPTXp667GJUkL5nlSk1QcxQQLOsUtO6Agq/YQIrexkxYA48FNrq+apydKdQ+ejRAQJrQShl9n7U= Received: from MN2PR02CA0015.namprd02.prod.outlook.com (2603:10b6:208:fc::28) by DM6PR12MB4452.namprd12.prod.outlook.com (2603:10b6:5:2a4::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.19; Wed, 27 May 2020 17:48:07 +0000 Received: from BL2NAM02FT012.eop-nam02.prod.protection.outlook.com (2603:10b6:208:fc:cafe::1) by MN2PR02CA0015.outlook.office365.com (2603:10b6:208:fc::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.18 via Frontend Transport; Wed, 27 May 2020 17:48:07 +0000 X-MS-Exchange-Authentication-Results: spf=permerror (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=alum.mit.edu; Received-SPF: PermError (protection.outlook.com: domain of alum.mit.edu used an invalid SPF mechanism) Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT012.mail.protection.outlook.com (10.152.77.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.17 via Frontend Transport; Wed, 27 May 2020 17:48:06 +0000 Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 04RHm4Mo020374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Wed, 27 May 2020 13:48:05 -0400 To: OKUMURA Shinji , sipcore@ietf.org Cc: Christer Holmberg References: From: Paul Kyzivat Message-ID: <51de720d-638b-bd7a-6655-8cd950a2d2ef@alum.mit.edu> Date: Wed, 27 May 2020 13:48:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFTY:; SFS:(39860400002)(136003)(346002)(376002)(396003)(46966005)(31696002)(47076004)(31686004)(86362001)(82740400003)(356005)(7596003)(4326008)(5660300002)(336012)(82310400002)(8936002)(2906002)(786003)(36906005)(8676002)(478600001)(966005)(316002)(26005)(75432002)(70586007)(2616005)(53546011)(186003)(956004)(70206006)(43740500002); DIR:OUT; SFP:1101; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6f2ac755-f77f-46b8-6d02-08d802661cdb X-MS-TrafficTypeDiagnostic: DM6PR12MB4452: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:2201; X-Forefront-PRVS: 04163EF38A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KCGwUmV22CWQNpIpDkJweKjPHjgQFdN1C+SMp+VJaZvmMhtrkF9vLJkx0TzVQHOqhSuK58ILj46bDMxDuUM9TDZnjNnu4R5yCeOrGrfCzXJUD526/LukXzY+IM5VryX4mIjeuMwk+WASqETAaQfS3fvNV4tJiybThFEhpoefZQUGtfhewCA7pFzH0vUBxm8Ea6Jghyrsl/3eXP8mdGEDFSW7DaR2RTYN3HW06gYrbRJ5I2oNfwbTsnFSUUX6qB+4Dpk/gSeBDeZIuWaM2G7LccHsW36MxOOgtCQ2hwRubAar5igIuQAQUsOu3MHR4Uo2NgAhw6OtC9ABPanJlLYN3/Ql+TSSOa7dc4MvABfnyTn4FiZ/Pyxr/pKupbp2tuJx4FNBFZ4mQUFbiyj9KVGstQsEyZh+bJHe/OrAg30sGEJ2j0KVO5PTiQ8iIcc0DLJlyNKkZIvpqW9r+18vF6EMo8TrRMrvB8p/YS/FLiE10v3El0evlGyQgYcNZGnFSfcp X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 May 2020 17:48:06.6367 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6f2ac755-f77f-46b8-6d02-08d802661cdb X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4452 Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 May 2020 17:48:10 -0000 Shinji, On 5/27/20 4:12 AM, OKUMURA Shinji wrote: > Hi, > > In following scenario, > (1) Alice sends INVITE. > (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol. > (4) Proxy2 rejects INVITE by 422. > (6) Carol accepts INVITE by 200. > > Eventually Bob never receive INVITE. > >        Alice        Proxy1    Proxy2(->Bob) Carol >          |(1) INVITE  |            | || >          |SE:1800     |            | || >          |----------->|            | || >          |            |(2) INVITE  | || >          |            |SE:1800     | || >          | |------------------------>| >          |            |(3) INVITE  | || >          |            |SE:1800     | || >          |            |===========>| || >          |            |(4) 422     |       | >          |            |MSE:3600    |       | >          | |<===========|            | >          |            |(5) ACK     | | >          | |===========>|            | >          |            |(6) 200 OK | >          |            |SE:1800 | >          | |<------------------------| >          |(7) 200 OK  | | >          |SE:1800     | | > |<-----------|                         | >          |(8) ACK     | | > |----------->|                         | >          |            |(9) ACK | >          | |------------------------>| > > I hope that 4028bis addresses this issue. What do you think *should* happen? Thanks, Paul > Regards, > Shinji > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From nobody Wed May 27 18:59:35 2020 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 E09BE3A0A39 for ; Wed, 27 May 2020 18:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 4RqcerWb99ir for ; Wed, 27 May 2020 18:59:32 -0700 (PDT) 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 9C6EF3A0A34 for ; Wed, 27 May 2020 18:59:32 -0700 (PDT) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id e7f6jhvT4EK7se7pSjEaB6; Thu, 28 May 2020 01:59:30 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1590631170; bh=Ni3wdmrp5fQ/ed1BIBTEFr3GZsEvM3yAxp62m2H2OuY=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=gvCf5EPso008/mX8jl4u/TfQE6jGKFWRoYbiOARnG9ACwQV/epI+bLHcrHfSJUfoo 4qt+tYSx+37r0QKR4ioBqzTRNVBTJ0Cwgb9dWRAr3mtIA0FFOlQekHJ5VQocpKOUFr dFy16pFMFl5I+421GMYf8x98I8IC5gNzXXLGd6v/RzJpdWqf/nuOcrI5Na51XDOd3/ v5ft3wJwHE12xhdCQyUjzkgZc/V5RMN/22Mu4ua66K0+ZP6jgkedaktWHp2XKRDBWw lRcChDHpsd+gbnUrRuzr00cBdrlAwQnAqLcsKlklOaJFz3g1oHs3Zm0oNKeSaDHCnX +pMXVa5WfvqTQ== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with ESMTPA id e7pQjxCwoNezde7pRjQk9F; Thu, 28 May 2020 01:59:30 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit 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 04S1xRwM017691; Wed, 27 May 2020 21:59:27 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 04S1xP0W017677; Wed, 27 May 2020 21:59:25 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: OKUMURA Shinji Cc: sipcore@ietf.org, christer.holmberg=40ericsson.com@dmarc.ietf.org In-Reply-To: (ietf.shinji@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Wed, 27 May 2020 21:59:25 -0400 Message-ID: <87wo4wizuq.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 01:59:34 -0000 OKUMURA Shinji writes: > In following scenario, > (1) Alice sends INVITE. > (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol. > (4) Proxy2 rejects INVITE by 422. > (6) Carol accepts INVITE by 200. > > Eventually Bob never receive INVITE. True ... but that's acceptable. Alice sent an INVITE and connected with one if its destinations. A more interesting issue is if Carol does not accept the INVITE, and her UA responds with 487. Then Proxy1 sees a 422 response from Proxy2 and a 487 from Carol. If it returns the 487 to Alice, Alice won't update the session timer. RFC 3261 sectoin 16.7 item 6 says The proxy SHOULD give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen. which suggests that 422 should be returned to the UAC, because the UAC can adjust the request based on it. Dale From nobody Wed May 27 23:34:51 2020 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 C02B93A0404 for ; Wed, 27 May 2020 23:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 GpPOm1Y3VZW5 for ; Wed, 27 May 2020 23:34:48 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 84C8F3A03F6 for ; Wed, 27 May 2020 23:34:48 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id p21so12935161pgm.13 for ; Wed, 27 May 2020 23:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=n3xfDEVXvfe6/GjQOMZDOkHcEkaq5G6jChSUtwJhswk=; b=eGlLTx3Cg6WWafZ8M07lA4TynnTnCwYYfxfy3U1uATiKrUCH0RhWgmg1kU7YeV/ySg PE4L8hKWbd+MIrgaJEz2N4IL8dz4YnffxUsz3pdLCZxBvLPbd27T9hqbVEs8yykAG18v QWRbCEyxI1LjkSj9jfH8QR+Ub7Z64CA2fVeED5AFVC+h1orpLpVG63j5o9xSw+JYFk4s 610DuxVAU/H+sY+UmYFDEMVC67jbDg2R+5RizSJZ/UMnp7oriq4mxyOL6lDdpTUPfRlj UHnyD/NQ8C//IxaBzueXhYKzlvi068kvpuYUog/Hb/W07haHr6fDt6M01p10NDMsTWPC +Yog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=n3xfDEVXvfe6/GjQOMZDOkHcEkaq5G6jChSUtwJhswk=; b=nDUa2i55uHZvp2/7uheO9gCBepkrIW8lB1RMB0bcyCsUyUgn6XgNWAzIw8l/pFIYac ewbhkeLkcV99QJDZ0d8yTmo63fLgZMf2qjXp9indzOEKgW7aE0AT27Rs8fgbYvdyCb0T MR5Recdtz0Bcre2ZCleIO/5OPT8xDuxS59d/nsDmdXOB2C4QwH1OueI4PWlQx8ZmWzq+ 82kqtZsGsFesrBu3OZrIjrw3PkK96yYvSCN0JCHnLk+2gICi/uWiIvwQc1RCEXrm1ndN 6Io60gVLtq8dVZSd4guBFJD64fCg8ZN3D59dJEmsuO2Vn7Mruxj20Q3pxi7nwGHM+bvW VsPQ== X-Gm-Message-State: AOAM533DY/90eDt9j2wRJFXJGUfjmSQ66SJCbVlbZ8wDvua6SNN8X+b9 9QoVlVI+XoijM9mDqfBqC50= X-Google-Smtp-Source: ABdhPJxCjpxqPNdIFLuZx0kkG6WZkBqYU/MzbJp8zDJG8ew3hs5rqZw4ngAiYhFiPM+heUjuGXHL1Q== X-Received: by 2002:a63:63c6:: with SMTP id x189mr1499270pgb.36.1590647688043; Wed, 27 May 2020 23:34:48 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id 136sm3831155pfa.152.2020.05.27.23.34.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 23:34:47 -0700 (PDT) From: OKUMURA Shinji To: "sipcore@ietf.org" References: <6BD34002-7DC1-445B-94ED-3F3C7F5944C2@ericsson.com> Message-ID: <6d5b0b50-0d12-e23a-0228-4fd30ebd5f14@gmail.com> Date: Thu, 28 May 2020 15:34:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <6BD34002-7DC1-445B-94ED-3F3C7F5944C2@ericsson.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 06:34:50 -0000 Hi, As you point out, the other responses(407, 420, ...) cause the same problem. But session-timer is essentially a kind of pre-condition, so I'd like to avoid incoming calls to fail because of it. And I'd like to sort out also the rules in early dialog. Regards, Shinji On 2020/05/27 19:16, Christer Holmberg wrote: > Hi, > > A proxy rejecting a request is not unique to the session-timer. > > If Alice receives a 422 she can send a CANCEL (if other early dialogs have been established), and then a new initial INVITE. > > Regards, > > Christer > > > On 27/05/2020, 11.12, "OKUMURA Shinji" wrote: > > Hi, > > In following scenario, > (1) Alice sends INVITE. > (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol. > (4) Proxy2 rejects INVITE by 422. > (6) Carol accepts INVITE by 200. > > Eventually Bob never receive INVITE. > > Alice Proxy1 Proxy2(->Bob) Carol > |(1) INVITE | | | | > |SE:1800 | | | | > |----------->| | | | > | |(2) INVITE | | | > | |SE:1800 | | | > | |------------------------>| > | |(3) INVITE | | | > | |SE:1800 | | | > | |===========>| | | > | |(4) 422 | | > | |MSE:3600 | | > | |<===========| | > | |(5) ACK | | > | |===========>| | > | |(6) 200 OK | > | |SE:1800 | > | |<------------------------| > |(7) 200 OK | | > |SE:1800 | | > |<-----------| | > |(8) ACK | | > |----------->| | > | |(9) ACK | > | |------------------------>| > > I hope that 4028bis addresses this issue. > > Regards, > Shinji From nobody Wed May 27 23:35:27 2020 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 8BF7A3A0414 for ; Wed, 27 May 2020 23:35:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, 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 dFASl89zlWD8 for ; Wed, 27 May 2020 23:35:24 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 5BB423A0404 for ; Wed, 27 May 2020 23:35:24 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id s10so12951078pgm.0 for ; Wed, 27 May 2020 23:35:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZyXLaPcUdAdclc+0zr6iytQ+8ig/m0jRcl3TuZZ+1+o=; b=ZTolCgnbK8GuPJusVVOxcTTDfUFoNun+qPiUM7OwW19CqAMG3wrjKayn5kVHjooa9S txjtNvKA7NuY542DahCNZx8MQwxpDDiz0Vy7UHX22lmPhsOocV4axvVjKpL2BI445bM+ o0O7Vi/h78j9w/Qfqi53vlT/OqUmvo9yCuj3y/lqN8mnC8zhM2ula6muAXRrvyKOPTMD 3IRjjHuIQ6xNSfE1qJ7wALA+kHaBo6rqCt94nC6tmg6v1QLmrR5CVN48zr6o88rvEOsi L+Ot9kDNvA/omxNdgAupdQ270k+sqP9IK6TOJR5cItfTI+2QcF7kaDJli6tQg/gpq/ac QUCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZyXLaPcUdAdclc+0zr6iytQ+8ig/m0jRcl3TuZZ+1+o=; b=TFwjLiFcQXklce755F0TnO5jGKAtuRvCvHhL3X3XlsEtPCM6FM+SXUh5uqGFyWD6wh YaLkDXTPZFCBXwIpu5LxQcmTcIsqEuKSHyZLjDn6KFgdvWbW3JHa0FZeKMMz9eTdTkpi TF5a4Fpq1ySTPCEf/wYC6DcEsnVwWegPF8MCNikSKEmKxg/urpNTRnjaDRooF6RycrJd vuW2qyCR4yVZdRE7cruBV2/O7nY5aZ1rfIDYI9rgimO61zzWw6dprNaBh9coEvhsYxgT Ck8EJ8bbKAzYQFMqNmRadOGf/voqVkYys4jNVJN07xQwoctyT1rr5rZ4atHWoX5W48F3 BeCQ== X-Gm-Message-State: AOAM53182UDMUzDSWoVhIgriHD8fZKhAMadiFT2UYKS1zBJ+INmv6y+B fiC3uEYDWs4VhLYyeMM4wrLftu1G X-Google-Smtp-Source: ABdhPJw7UWHxrmd6+xz1+DuzvGMxuMNw2259Vye9+qVzHZMoz8LePPVXW4HpjTpDJdkOitS0EbXN9Q== X-Received: by 2002:a63:6dc7:: with SMTP id i190mr1459376pgc.171.1590647723445; Wed, 27 May 2020 23:35:23 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id j10sm3961936pjf.9.2020.05.27.23.35.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 23:35:22 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Cc: Paul Kyzivat , Christer Holmberg References: <51de720d-638b-bd7a-6655-8cd950a2d2ef@alum.mit.edu> Message-ID: <7fadcff5-f3fd-647a-4361-2ab46b2163be@gmail.com> Date: Thu, 28 May 2020 15:35:19 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <51de720d-638b-bd7a-6655-8cd950a2d2ef@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 06:35:26 -0000 Hi, The cause of the issue is the 422 response and the cause of the 422 response is the SE header. I think the simple solution is to allow the proxy to increase the value of SE-header. RFC4028 also conditionally allows the proxy to increase the SE-value. Honestly writing, INVITE request doesn't need a SE-header, I think it's enough for UAS to copy the MSE value into SE-header of 200 response. Regards, Shinji On 2020/05/28 2:48, Paul Kyzivat wrote: > Shinji, > > On 5/27/20 4:12 AM, OKUMURA Shinji wrote: >> Hi, >> >> In following scenario, >> (1) Alice sends INVITE. >> (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol. >> (4) Proxy2 rejects INVITE by 422. >> (6) Carol accepts INVITE by 200. >> >> Eventually Bob never receive INVITE. >> >> Alice Proxy1 Proxy2(->Bob) Carol >> |(1) INVITE | | | | >> |SE:1800 | | | | >> |----------->| | | | >> | |(2) INVITE | | | >> | |SE:1800 | | | >> | |------------------------>| >> | |(3) INVITE | | | >> | |SE:1800 | | | >> | |===========>| | | >> | |(4) 422 | | >> | |MSE:3600 | | >> | |<===========| | >> | |(5) ACK | | >> | |===========>| | >> | |(6) 200 OK | >> | |SE:1800 | >> | |<------------------------| >> |(7) 200 OK | | >> |SE:1800 | | >> |<-----------| | >> |(8) ACK | | >> |----------->| | >> | |(9) ACK | >> | |------------------------>| >> >> I hope that 4028bis addresses this issue. > > What do you think *should* happen? > >     Thanks, >     Paul From nobody Wed May 27 23:35:59 2020 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 EE1E33A040C for ; Wed, 27 May 2020 23:35:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 LP1nJuhAgvIi for ; Wed, 27 May 2020 23:35:57 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (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 036713A0404 for ; Wed, 27 May 2020 23:35:56 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id p21so12936449pgm.13 for ; Wed, 27 May 2020 23:35:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hMksNrOMdwXg15OQ58lIwZWcNTbFFyM33yRzHka4N+E=; b=iB+FbEPdeijtvHQobDjc1BOLUON9KDTsEIaMurcmEIQZzxFQ6FT/obkMy50uvm67cU zXQdxdMGiapVFkWKDPYDd1zTDsIqvw9njCJpo4cRlXlBkAwq+XVdfrP4CMWa8WxbWISk 7Eg+SmfWRXZiHNEEr7++nM0x2qX92gXLvXucjfLDGQ+tOW1ChgjIpFilc8Y2+c9aFp6e antFpx04y+jW217dpsOGi+HQIzIpo4nJi//qmp0hHRlxdnMpT60trVrN2MIFm6Ma3Fpj 7KNJA7N/2KFZaQ3JvAc1gYF4uyA9KTfWtnaom8BL5s7rQs3vYsxA9+ajG4QwOFqniIab Sm7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hMksNrOMdwXg15OQ58lIwZWcNTbFFyM33yRzHka4N+E=; b=h0az/2L1EKH1CFsu71kE34vOtJoJcYzuq9Damgc9vzU7sFAd/z+PqIn61OrAuG25qH r6oRqFcAYUd2Vwr/zY/PHX0DjjDSgibxV59+SH+BUYBw7Log0tgCr3eIaCz4DCiNAxoI Py5JhwY9xOHqNs9EEQq0NXQDiUXkhca7n11+WfBZktUQCnQlRfLKB+58AQg3lNISUmyp i3Zi+8YmaXqK0Yj5mtF0j2ITugsL4LShRL210GbsOBwRZpRhxqpaEVrVYq8X23GDc2E0 PrhcBD3VzNP06y2K75ltp9+uGe9mlzyzC0LWWJrU7066dmKQAWRleJh/h/fkemOdiZ9p tAjw== X-Gm-Message-State: AOAM531SSszj7gm7vRJsVPGjGtLWxd9HTVWpx5tlos80qRYrFzaRGsQK pmDK4yvkyJEeCviRAwLdi8Nrduxt X-Google-Smtp-Source: ABdhPJwYiG84XJ0IWmTJqCvHgMRE21lyMLdaT0RcARLGv2WofN68eZloWUBqLp/4cQLqlr7QM6Nd3g== X-Received: by 2002:a65:518c:: with SMTP id h12mr1445905pgq.17.1590647755831; Wed, 27 May 2020 23:35:55 -0700 (PDT) Received: from [192.168.1.10] (x156176.ppp.asahi-net.or.jp. [122.249.156.176]) by smtp.gmail.com with ESMTPSA id w7sm3817735pfu.117.2020.05.27.23.35.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 May 2020 23:35:55 -0700 (PDT) From: OKUMURA Shinji To: sipcore@ietf.org Cc: "Dale R. Worley" , christer.holmberg=40ericsson.com@dmarc.ietf.org References: <87wo4wizuq.fsf@hobgoblin.ariadne.com> Message-ID: Date: Thu, 28 May 2020 15:35:52 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.1 MIME-Version: 1.0 In-Reply-To: <87wo4wizuq.fsf@hobgoblin.ariadne.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 06:35:58 -0000 Hi, If Bob is a call center operator, I think that's a problem for him. If Carol responds 401, which is the "best" final response? At least for session-timer, I think it should be handled within the early dialog as well as the pre-condition. (If we didn't have to consider backward compatibility.) Regards, Shinji On 2020/05/28 10:59, Dale R. Worley wrote: > OKUMURA Shinji writes: >> In following scenario, >> (1) Alice sends INVITE. >> (2) Proxy1 forks INVITE to Proxy2(for Bob) and Carol. >> (4) Proxy2 rejects INVITE by 422. >> (6) Carol accepts INVITE by 200. >> >> Eventually Bob never receive INVITE. > > True ... but that's acceptable. Alice sent an INVITE and connected with > one if its destinations. > > A more interesting issue is if Carol does not accept the INVITE, and her > UA responds with 487. Then Proxy1 sees a 422 response from Proxy2 and a > 487 from Carol. If it returns the 487 to Alice, Alice won't update > the session timer. RFC 3261 sectoin 16.7 item 6 says > > The proxy SHOULD > give preference to responses that provide information affecting > resubmission of this request, such as 401, 407, 415, 420, and > 484 if the 4xx class is chosen. > > which suggests that 422 should be returned to the UAC, because the UAC > can adjust the request based on it. > > Dale > From nobody Thu May 28 02:15:54 2020 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 E08DD3A0C81 for ; Thu, 28 May 2020 02:15:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, 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=ericsson.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 M4L1YYe9w0ow for ; Thu, 28 May 2020 02:15:52 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70051.outbound.protection.outlook.com [40.107.7.51]) (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 A8D353A0C7C for ; Thu, 28 May 2020 02:15:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eUvHGsiUniVdOPeEnwvXHaflDXuLCOwC4mO5Ag5iRQf0hZWauD1jw86JnDYV0Iph+fQChs/JXwNk3Cfcw7iruw4c8oW9cTY5UqVzVBcJ9Er0EajKtazfiP+FisjRWqmDDmJouSwU+wQxvlxsPByvHwdJAfhjwb/sadAzZB3Yvaqz0NRcL0yLz/ErVY4cMefR5epGd7qQQ88sod/1NP8MGha6wyEhb+RTE/PU66FoXkgViH05pIapKThvItdGnwI0M3BilemDjdfYgfbqugEG6blk4FO3w8rac7ZGisIN30M9N+PAXodKjMv/ba/QUY5brCkOV1xr20zqSqu63CH1Gw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vu2XJdsvk1galmttzMG4gh7WkFFjkjJGd15IDaYprms=; b=VPbh6rftWoUWHzYpR30PbUB7F0W+mAYLrYzSuQZwAXarmnKLMSB1XqTN1xd/yArdjLCZHDjaXE7Bu1z+8ePkKlu6qB1t7qAjzQJJFyDG1oJ2xx7guFgQag+wsSs9r5MjIprSqGVmET41YM6jzc0n8iBzlnV66kN2oSKiWjmNL+PZ6Ij20P6t098Q/2fdisIqFb/n4J7fVzfJcf+dWnpRRkIlgLlXacvK1m1WozGVSkFgohA6KZtSlWqtJSKED/g1qe2uue6RB1HjjkjAQf428Hx8TTQwdAbq9aiPzOHeQk/jQ0Y66pg3b7poqy1cpNAF38iS/eq5W3iZV27hVMwGDg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Vu2XJdsvk1galmttzMG4gh7WkFFjkjJGd15IDaYprms=; b=lZ0MZcOe7aK2EFSdUM0/9404OeEsaZgLslKdOB4fiPZPslVfW0t8QzzbFp6rjadDMW5tlgw7z6N3Ji1t2Ral3fiNRcLjFt6GA4c4y58gwiglECp7mqRtIJ/8jaNkmDX0xIt55qlJH1/zmzJtPYuDOZ8Oz5PXRooYDKKF7fajnDc= Received: from AM7PR07MB7012.eurprd07.prod.outlook.com (2603:10a6:20b:1bc::19) by AM7PR07MB6804.eurprd07.prod.outlook.com (2603:10a6:20b:1b4::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.7; Thu, 28 May 2020 09:15:49 +0000 Received: from AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9]) by AM7PR07MB7012.eurprd07.prod.outlook.com ([fe80::7529:b51f:5fb4:62b9%5]) with mapi id 15.20.3066.007; Thu, 28 May 2020 09:15:49 +0000 From: Christer Holmberg To: OKUMURA Shinji , "sipcore@ietf.org" Thread-Topic: 4028bis: forking Thread-Index: AQHWM/6HmaOdA74mGkCkKN9wxcQ7i6i76gsAgAEiHQCAACxOAA== Date: Thu, 28 May 2020 09:15:49 +0000 Message-ID: References: <6BD34002-7DC1-445B-94ED-3F3C7F5944C2@ericsson.com> <6d5b0b50-0d12-e23a-0228-4fd30ebd5f14@gmail.com> In-Reply-To: <6d5b0b50-0d12-e23a-0228-4fd30ebd5f14@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [188.127.223.154] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: be0bad3e-88e9-42a7-909f-08d802e7b644 x-ms-traffictypediagnostic: AM7PR07MB6804: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0417A3FFD2 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: r46hzHJ9bETdi/EftGcXWUjpKo4crSU2jkYFQ/WlwsqNcjOO/PtMJ6U0sUgGWonOc+xdCzUHD/UF5KlEujTe4e2ufbSTa/No/dBfxTlQXjhmHbX0uplA2et0gnkt1wlbZWb07u0HzfTAoP2KaFnSqHGcRJ8eBYxrwZotAZT9HqtmgkE5Iw+mNFo5gxPcS065M1begKbmU4CHzKmOq4wBEEdN/HxT6YWRatUqFHODedBjFxfCwUjjeB+6Lt9SBKw10dl0khAFezxnN2q454oweltn2IVhalSJcrC9rHQqe7NBwDpWrguLplD3VnizETHCT/lVQeu4Col9SflziEU1Eg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM7PR07MB7012.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(39860400002)(366004)(346002)(396003)(376002)(2906002)(8936002)(52536014)(71200400001)(186003)(44832011)(478600001)(110136005)(26005)(9686003)(83380400001)(55016002)(86362001)(64756008)(66446008)(66556008)(66946007)(8676002)(7696005)(66476007)(5660300002)(6506007)(33656002)(76116006)(316002)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bqnXoOOxg8XJyCfff6g4JlTSay0w6bFqjmgtcBSKxRLCkqjd+WHWwg1AppbYV84ic/BjXyNWGUxi5bgVml9cnTE2G03jPIBIiiByKOBg+Mu9t1CgRQn3sHBq946KoB/5vvjXejq86KOokXElkN1MXj4jITWU/BmJPu88OIQx/gwkwk3Sev+kY3J7LzRlLBidQT1lWCN18k0dFtfJ20hoLID023wZWL8Q/XkUAj4Z1hpwhj/xowgqlU2aBS6X6y22X8PZaYEpQ+5/ExOUNrZDo+oae4/TI5uHXsmsUOD0mGILoFR56Z2J3/7KXzdEGKFhTVM69KsfuzYlF7QnIiX3lhdZhIrCif3yiDiLj90FuTxIkCRUEXZW7uHzCK/t5tTtRQbJ0li/Z0JRgQu5MpHXxrWw5TVja8oaF/AjPJgy6YyzkKLMJIGB8bD4QjFRiOOJjqFAjbY/KSHlqzRvV5AmvxUJ+F1ha6fgFS6kHq5xfSXx8OpKZcTFvEi7fLrsZ7Vz x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: be0bad3e-88e9-42a7-909f-08d802e7b644 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 May 2020 09:15:49.0557 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wL3Htq6Uv64wCrvgWEPufWJFgsUXU5bS3iJ4rZNOJeyeBLCmG3hAebrN5AZqaRHpbygLQNcAOpgKfsSdQldjE1u+j4ZpE5jTq8ug/RxgLBE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR07MB6804 Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2020 09:15:54 -0000 SGksDQoNCk5vdGUgdGhhdCB0aGUgdGVjaG5pY2FsIHNjb3BlIG9mIDQwMjhiaXMgaXMgdG8gc29s dmUgdGhlIGdsYXJlIGlzc3VlIHRoYXQgaGFzIGJlZW4gaWRlbnRpZmllZC4gT3RoZXIgd291bGQt YmUtbmljZS10by1oYXZlcyBhcmUgbm90IHdpdGhpbiB0aGUgc2NvcGUuDQoNCllvdXIgaXNzdWUg Y2FuIGJlIHNvbHZlZCBiZSBwcm9wZXIgY29uZmlndXJhdGlvbiAtIHRoZXJlIGlzIG5vIHRlY2hu aWNhbCB3b3JrIG5lZWRlZC4NCg0KUmVnYXJkcywNCg0KQ2hyaXN0ZXINCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE9LVU1VUkEgU2hpbmppIDxpZXRmLnNoaW5qaUBnbWFpbC5j b20+IA0KU2VudDogdG9yc3RhaSAyOC4gdG91a29rdXV0YSAyMDIwIDkuMzUNClRvOiBzaXBjb3Jl QGlldGYub3JnDQpDYzogQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNz c29uLmNvbT4NClN1YmplY3Q6IFJlOiA0MDI4YmlzOiBmb3JraW5nDQoNCkhpLA0KDQpBcyB5b3Ug cG9pbnQgb3V0LCB0aGUgb3RoZXIgcmVzcG9uc2VzKDQwNywgNDIwLCAuLi4pIGNhdXNlIHRoZSBz YW1lIHByb2JsZW0uDQpCdXQgc2Vzc2lvbi10aW1lciBpcyBlc3NlbnRpYWxseSBhIGtpbmQgb2Yg cHJlLWNvbmRpdGlvbiwgc28gSSdkIGxpa2UgdG8gYXZvaWQgaW5jb21pbmcgY2FsbHMgdG8gZmFp bCBiZWNhdXNlIG9mIGl0LiBBbmQgSSdkIGxpa2UgdG8gc29ydCBvdXQgYWxzbyB0aGUgcnVsZXMg aW4gZWFybHkgZGlhbG9nLg0KDQpSZWdhcmRzLA0KU2hpbmppDQoNCk9uIDIwMjAvMDUvMjcgMTk6 MTYsIENocmlzdGVyIEhvbG1iZXJnIHdyb3RlOg0KPiBIaSwNCj4gDQo+IEEgcHJveHkgcmVqZWN0 aW5nIGEgcmVxdWVzdCBpcyBub3QgdW5pcXVlIHRvIHRoZSBzZXNzaW9uLXRpbWVyLg0KPiANCj4g SWYgQWxpY2UgcmVjZWl2ZXMgYSA0MjIgc2hlIGNhbiBzZW5kIGEgQ0FOQ0VMIChpZiBvdGhlciBl YXJseSBkaWFsb2dzIGhhdmUgYmVlbiBlc3RhYmxpc2hlZCksIGFuZCB0aGVuIGEgbmV3IGluaXRp YWwgSU5WSVRFLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IENocmlzdGVyDQo+IA0KPiANCj4g77u/ T24gMjcvMDUvMjAyMCwgMTEuMTIsICJPS1VNVVJBIFNoaW5qaSIgPGlldGYuc2hpbmppQGdtYWls LmNvbT4gd3JvdGU6DQo+IA0KPiAgICAgIEhpLA0KPiANCj4gICAgICBJbiBmb2xsb3dpbmcgc2Nl bmFyaW8sDQo+ICAgICAgKDEpIEFsaWNlIHNlbmRzIElOVklURS4NCj4gICAgICAoMikgUHJveHkx IGZvcmtzIElOVklURSB0byBQcm94eTIoZm9yIEJvYikgYW5kIENhcm9sLg0KPiAgICAgICg0KSBQ cm94eTIgcmVqZWN0cyBJTlZJVEUgYnkgNDIyLg0KPiAgICAgICg2KSBDYXJvbCBhY2NlcHRzIElO VklURSBieSAyMDAuDQo+IA0KPiAgICAgIEV2ZW50dWFsbHkgQm9iIG5ldmVyIHJlY2VpdmUgSU5W SVRFLg0KPiANCj4gICAgICAgIEFsaWNlICAgICAgICBQcm94eTEgICAgUHJveHkyKC0+Qm9iKSAg IENhcm9sDQo+ICAgICAgICAgIHwoMSkgSU5WSVRFICB8ICAgICAgICAgICAgfCAgICB8ICAgICAg IHwNCj4gICAgICAgICAgfFNFOjE4MDAgICAgIHwgICAgICAgICAgICB8ICAgIHwgICAgICAgfA0K PiAgICAgICAgICB8LS0tLS0tLS0tLS0+fCAgICAgICAgICAgIHwgICAgfCAgICAgICB8DQo+ICAg ICAgICAgIHwgICAgICAgICAgICB8KDIpIElOVklURSAgfCAgICB8ICAgICAgIHwNCj4gICAgICAg ICAgfCAgICAgICAgICAgIHxTRToxODAwICAgICB8ICAgIHwgICAgICAgfA0KPiAgICAgICAgICB8 ICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+ICAgICAgICAgIHwgICAg ICAgICAgICB8KDMpIElOVklURSAgfCAgICB8ICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAg ICAgIHxTRToxODAwICAgICB8ICAgIHwgICAgICAgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAg fD09PT09PT09PT09PnwgICAgfCAgICAgICB8DQo+ICAgICAgICAgIHwgICAgICAgICAgICB8KDQp IDQyMiAgICAgfCAgICAgICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgICAgIHxNU0U6MzYw MCAgICB8ICAgICAgICAgICAgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAgfDw9PT09PT09PT09 PXwgICAgICAgICAgICB8DQo+ICAgICAgICAgIHwgICAgICAgICAgICB8KDUpIEFDSyAgICAgfCAg ICAgICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgICAgIHw9PT09PT09PT09PT58ICAgICAg ICAgICAgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAgfCg2KSAyMDAgT0sgICAgICAgICAgICAg ICB8DQo+ICAgICAgICAgIHwgICAgICAgICAgICB8U0U6MTgwMCAgICAgICAgICAgICAgICAgIHwN Cj4gICAgICAgICAgfCAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfA0KPiAg ICAgICAgICB8KDcpIDIwMCBPSyAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAg ICAgIHxTRToxODAwICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAg fDwtLS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICB8KDgp IEFDSyAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgIHwtLS0tLS0t LS0tLT58ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgICAg IHwoOSkgQUNLICAgICAgICAgICAgICAgICAgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAgfC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58DQo+IA0KPiAgICAgIEkgaG9wZSB0aGF0IDQwMjhiaXMg YWRkcmVzc2VzIHRoaXMgaXNzdWUuDQo+IA0KPiAgICAgIFJlZ2FyZHMsDQo+ICAgICAgU2hpbmpp DQo= From nobody Thu May 28 19:30:49 2020 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 163C73A00C4 for ; Thu, 28 May 2020 19:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.639 X-Spam-Level: X-Spam-Status: No, score=-1.639 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcastmailservice.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 pkytPxxEg_2x for ; Thu, 28 May 2020 19:30:46 -0700 (PDT) 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 886DB3A0A0B for ; Thu, 28 May 2020 19:30:25 -0700 (PDT) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id eUZsjjJxeEK7seUmujHa4S; Fri, 29 May 2020 02:30:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1590719424; bh=fD4SJDUegCcqosfrjcCNYM1bdpaeQHZMwFVECDqhODM=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=HFDFLBROWP6xaVpTIHtwEUP1fqW0prPbJ2FWhBG8mk4m7Acm6ykqo3y9UNPeWQ3a7 ugxo5Fgun1+R70KPtEhLLGMQSce7IFUa/7/QwAAoNIIrV4lv5aWEhRZX+Y0bX7zlhK u3mVZ4Ae7S9D7Pl6m6Yit6GOKHz8AGOfbYysAMRnY/ETpWPtz3WNCTlvHHHsnupmLT vpb5Om3l58yqL5pvO+dUmPzKmmlQ/BmBUvWRq57gnuqx+tRKiTej7iVXZbEPu0iUiW 3AKoM4EigrSsrQTHWOI+/4d6YY5hqrT342Ugb6NraZ18rRyPs8KUQva9Nyy5wP+wEl s4H7biya5TrEA== Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4a00:430:222:fbff:fe91:d396]) by resomta-ch2-07v.sys.comcast.net with ESMTPA id eUmsjsjemD1LzeUmtjHJ17; Fri, 29 May 2020 02:30:24 +0000 X-Xfinity-VMeta: sc=-100.00;st=legit 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 04T2UM72017376; Thu, 28 May 2020 22:30:22 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id 04T2ULLB017373; Thu, 28 May 2020 22:30:21 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: OKUMURA Shinji Cc: sipcore@ietf.org In-Reply-To: <6d5b0b50-0d12-e23a-0228-4fd30ebd5f14@gmail.com> (ietf.shinji@gmail.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Thu, 28 May 2020 22:30:21 -0400 Message-ID: <87zh9rh3r6.fsf@hobgoblin.ariadne.com> Archived-At: Subject: Re: [sipcore] 4028bis: forking X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2020 02:30:48 -0000 OKUMURA Shinji writes: > As you point out, the other responses(407, 420, ...) cause the same problem. > But session-timer is essentially a kind of pre-condition, so I'd like > to avoid incoming calls to fail because of it. And I'd like to sort > out also the rules in early dialog. > On 2020/05/27 19:16, Christer Holmberg wrote: >> A proxy rejecting a request is not unique to the session-timer. >> >> If Alice receives a 422 she can send a CANCEL (if other early dialogs >> have been established), and then a new initial INVITE. (This has a larger scope than just session-timers.) I don't know if the above writers intended this point, but reading what they have said suggests to me this possible behavior for proxies (which I don't recall seeing suggested): Note that 422 is one of a number of "pre-condition failure" response codes. Those have the properties (1) when they are generated, they are generated nearly immediately from the INVITE, and (2) the UAC can adjust the INVITE to prevent them. Suppose that if a proxy receives one of these "pre-condition failure" responses, it immediately (or with short delay on a human scale) cancels all remaining forks of the transaction and returns the failure response upstream. The effect is to split the "early dialog" phase into two sub-phases, (1) a very short phase where the forking of the INVITE effectively probes for proxies and UASs that object to the the INVITE for "pre-condition" reasons, and (2) a longer phase which resembles the current early dialog phase. There are probably refinements needed to make this work in all cases. Dale From nobody Sun May 31 13:59:40 2020 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 759F53A0CD1; Sun, 31 May 2020 13:59:36 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 NnCN_ErO_oSx; Sun, 31 May 2020 13:59:34 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDD853A0CCB; Sun, 31 May 2020 13:59:34 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C16FBF406F6; Sun, 31 May 2020 13:59:18 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, sipcore@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20200531205918.C16FBF406F6@rfc-editor.org> Date: Sun, 31 May 2020 13:59:18 -0700 (PDT) Archived-At: Subject: [sipcore] =?utf-8?q?RFC_8787_on_Location_Source_Parameter_for_th?= =?utf-8?q?e_SIP_Geolocation_Header_Field?= X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2020 20:59:37 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8787 Title: Location Source Parameter for the SIP Geolocation Header Field Author: J. Winterbottom, R. Jesske, B. Chatras, A. Hutton Status: Standards Track Stream: IETF Date: May 2020 Mailbox: a.james.winterbottom@gmail.com, r.jesske@telekom.de, bruno.chatras@orange.com, andrew.hutton@atos.net Pages: 8 Updates: RFC 6442 I-D Tag: draft-ietf-sipcore-locparam-06.txt URL: https://www.rfc-editor.org/info/rfc8787 DOI: 10.17487/RFC8787 There are some circumstances where a Geolocation header field may contain more than one locationValue. Knowing the identity of the node adding the locationValue allows the recipient more freedom in selecting the value to look at first rather than relying solely on the order of the locationValues. This document defines the "loc-src" parameter so that the entity adding the locationValue to the Geolocation header field can identify itself using its hostname. This document updates RFC 6442. This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC