From nobody Mon Aug 2 11:43:34 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937153A15BC for ; Mon, 2 Aug 2021 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_DNSWL_NONE=-0.0001, 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=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 Xnx46iNEcxGw for ; Mon, 2 Aug 2021 11:43:20 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2055.outbound.protection.outlook.com [40.107.237.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 68A533A158E for ; Mon, 2 Aug 2021 11:43:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J1IOZ3ejvVUYEDPQEbM5+CcHufFHHmp36cwf2LcljmG9AOcl7gdg2E0L6lped5CutdttkmykAMUGpqzLVOtlrbeLvGrm9YpftdiFpaNIFI7XbC6vvvJ74yq/64xXNMLfdHq9AtqrApp7HEgKTeAuvaJePcj/LFVEMUZTx2uTCLDAbjsAwwvFoXNhRScGznX+KEmKUqaK1wwcJu2JiXgZa/sds5ZpgYp5qNVUYliXK7nZ1zRQYMgC31dQ/jcZ4ghYOcBWUWCrcM6b1mdUK/WdmIDrAh68ouex+Sk4AJZ6+VOi4pcot8bnCwqX8AyaZVzsbPUIyFghbc7tdQwMAenPKw== 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=3QgMPgs2XIHzr+JsT8KbarGfmmitTmJ41F7R1ZzLHA8=; b=D2xtnVwTkrHElmxymhS34vrEiObTty1+v6K4tG4jJK5LBqBaCXGRYdBCnUyi1nqoqeFB0gwS1PHZxC+KERnmWP7Fo4K/R+E6BIvez/WJWP5AjDn81kqQFNjfAgwvDFTeMvxYK9nPTTooAi+pRhgDVL4Z1Zxj2v6RE4zrYZTN+2d2tUJgOFnf3C5OaGkzAF7aBUPBnSZngDBv99wGdYt7tyqAMEl8Qc4hikqaS2UUlX9qse+9RyLyCFXVtBgGWLhV1Nmz1Erc7KfKeD88U0lbdHrdxghexEoMLgOQf5tzHtFTm1QbxCvN1Ew+4lCPu4cj+TwK8ahu/aU9luQwfKDD3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=3QgMPgs2XIHzr+JsT8KbarGfmmitTmJ41F7R1ZzLHA8=; b=iTBzZ/aRAmSWaekFmplcl0Qrr4S1y0O1lOLWfi7Bfb5xPuOUyIiO/t2fN8pHPMnosbCi7A1yToLpoRWCprYfWJUgEHDIJdP4aIx+Im0B/M4QWmtxhjwimi4sSdu0rXTiJZCEc0RJf8c7aZg+u8W3KKuwdjW0MxmxEokKm1/lTZY= Received: from DM5PR18CA0074.namprd18.prod.outlook.com (2603:10b6:3:3::12) by DM5PR12MB1468.namprd12.prod.outlook.com (2603:10b6:4:10::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.26; Mon, 2 Aug 2021 18:43:18 +0000 Received: from DM3NAM02FT049.eop-nam02.prod.protection.outlook.com (2603:10b6:3:3:cafe::8c) by DM5PR18CA0074.outlook.office365.com (2603:10b6:3:3::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.17 via Frontend Transport; Mon, 2 Aug 2021 18:43:18 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT049.mail.protection.outlook.com (10.13.5.68) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4373.18 via Frontend Transport; Mon, 2 Aug 2021 18:43:18 +0000 Received: from MacBook-Air.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 172IhGX0012996 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 Aug 2021 14:43:17 -0400 To: "rum@ietf.org" , Society for Science & the Public From: Paul Kyzivat Message-ID: Date: Mon, 2 Aug 2021 14:43:16 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fd81b765-eb24-4476-81f9-08d955e56562 X-MS-TrafficTypeDiagnostic: DM5PR12MB1468: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zRYToYj0Bq33Bx5m53ycM+0fC3di5OmeVeGt6lAQRCHLA3tyj2GzDYYbak6UqrDpMRZE+mso98f+RjKn2uO0KgNz2QEqZH70knF8zYjSWyoLCwD1YY+iEZuHP+Rir5GbwmkFqTayOhmb1BDC7IuJ1vieNBcRH53WV46YfokomMT3njGsYwCf9ljUIFlALej8GsGFWIoA1CJj62yL/uYFlw+BIXy+2ThZDJjoJNjKzqdxLl7abiVTfYdKqkoGAq8uH7CwpXzrzU/tGV63TVq5FkojMPpoVpzJ6VH5mPMQxTaOtrZ6uGGgLhpGF8mSw1mhndpEsmn+BUZ6sQvTYrjNvrQpK7pnp//VI5tH/5u+vPrQZuhy8fB7r6svO8pTXYWCwyDcKtiLod5S8Lgu48VXKgvgEDBBz6piyJDbP2SpME/N+Hotic3XyZaOy3zLgGrds7Rw8gaZ8U0ECuMttYbBVcDqevqT1OjHsEp3sIv51nL/gZl6C5A+AP87CR+7dvDFZOn27x7tjwVcLHw8M0mVY9pkw9EcTAtLu41aDYRGTvCNzYPwXkePhxFpv9vGVpYhhvfuXD/gRD5T5eAK+OUfSatS47KziqrxS7N9gq7UHpdduWEbJ+5UTG6zSxI+K/KL4u8gczjJ5movtyS4/pV0jVY1ag0XjKK3JG/LxSx/hROPUQE8uEvYNv9+9OWCueAWvB+uK+OtFTTX8jobbDfWL47o/icoZmfaY+m3foNqGl6SECcc+RibrB1qWY1waSxybrTARTHZqOyhF6KexRSnxoQ3eMZPtyY4CDGH28qf6TO4IigdvXCXGV2cYZcW8NG+ 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; SFS:(346002)(39860400002)(376002)(136003)(396003)(46966006)(36840700001)(8936002)(186003)(5660300002)(2616005)(8676002)(956004)(26005)(36860700001)(75432002)(31696002)(110136005)(316002)(31686004)(82310400003)(36906005)(478600001)(786003)(82740400003)(336012)(70586007)(2906002)(70206006)(86362001)(7596003)(4744005)(966005)(356005)(47076005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Aug 2021 18:43:18.5332 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fd81b765-eb24-4476-81f9-08d955e56562 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-AuthSource: DM3NAM02FT049.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1468 Archived-At: Subject: [Rum] DRAFT minutes for the rum session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2021 18:43:33 -0000 I've posted draft minutes for the meeting among the meeting materials, at: https://datatracker.ietf.org/meeting/111/materials/minutes-111-rum-01 Many thanks to Jonathan Lennox and Jim Malloy for taking notes. What I've posted is a merge of their work. Please review and reply back if you see anything that should be revised. Thank you, Paul From nobody Wed Aug 11 15:18:33 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D49893A2743 for ; Wed, 11 Aug 2021 15:18:30 -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=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wpczs_qoKKiS for ; Wed, 11 Aug 2021 15:18:26 -0700 (PDT) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B3553A2740 for ; Wed, 11 Aug 2021 15:18:25 -0700 (PDT) Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-05v.sys.comcast.net with ESMTP id DwUbmOeQCK3eXDwYKmW6Ac; Wed, 11 Aug 2021 22:18:24 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1628720304; bh=MkBTIUHkW3fDEcrlk/vDmogaanByLw+1OD2Kdx35dlA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GhvrAGD06CujQSxrEOihLfj4reiBrt9cBj/6dxL78YT6tynuRNehEYnjhJ0tS6qFp +G8zlWv5C6LpFB6Y++DLo2jm7ZZ/cYkFkw1YdIq6JDVIeSJA5S1eSrIsVHxpg7klw0 SvBRc5q5n/QogM4TVd1d3ihd6DKHM2dRres4yy8yynonLU5++SkQhRbXq8D1FAXnZ4 iExjJnSGw48V/QlaJomSxhgzMvuikOXuY5AnDIugoqtOoKvld9FF/ghmLyUgHUhjmv 9YIJyXY3OG/ObjvVsvA4qJf0PUvuT95f+f6fvYUJ03AM09pQwi6l8Cku3yQVCgeZlv oExMg/Sb065lw== Received: from MacBook-Air.localdomain ([24.62.227.142]) by resomta-ch2-12v.sys.comcast.net with ESMTPA id DwYImj8ztBmolDwYJmySsM; Wed, 11 Aug 2021 22:18:24 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvtddrkedvgddtjecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecunecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheprfgruhhlucfmhiiiihhvrghtuceophgruhhlrdhkhiiiihhvrghtsegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpeehleeijedtvddvjeekhefgteeivddttdelleduteffvdejfffhfeffvdeghffhgeenucffohhmrghinhepihgvthhfrdhorhhgnecukfhppedvgedriedvrddvvdejrddugedvnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehhvghlohepofgrtgeuohhokhdqtehirhdrlhhotggrlhguohhmrghinhdpihhnvghtpedvgedriedvrddvvdejrddugedvpdhmrghilhhfrhhomhepphgruhhlrdhkhiiiihhvrghtsegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheprhhumhesihgvthhfrdhorhhg X-Xfinity-VMeta: sc=0.00;st=legit To: rum@ietf.org References: From: Paul Kyzivat Message-ID: <41ef848f-fff9-f1b3-197b-6ce8620db658@comcast.net> Date: Wed, 11 Aug 2021 18:18:22 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.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 Archived-At: Subject: [Rum] Please review draft RUM meeting minutes X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 22:18:31 -0000 I got no responses to my earlier request for review of the meeting minutes. This is a second try. In particular, if you said anything during the session then please check that your position has been accurately captured. Please ack or nak. Thanks, Paul On 8/2/21 2:43 PM, Paul Kyzivat wrote: > I've posted draft minutes for the meeting among the meeting materials, at: > > https://datatracker.ietf.org/meeting/111/materials/minutes-111-rum-01 > > Many thanks to Jonathan Lennox and Jim Malloy for taking notes. What > I've posted is a merge of their work. > > Please review and reply back if you see anything that should be revised. > >     Thank you, >     Paul > From nobody Wed Aug 11 15:34:55 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DFF3A1B92 for ; Wed, 11 Aug 2021 15:34:53 -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 QDYylvgZu7Xf for ; Wed, 11 Aug 2021 15:34:49 -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 7AF9C3A27B4 for ; Wed, 11 Aug 2021 15:34:49 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id i7so5759837iow.1 for ; Wed, 11 Aug 2021 15:34:49 -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=SJ0a5B/WEPgqfliNlhjWTlHjOAYMj3XYZIyQeZh+REU=; b=L41khAyKdeneJFoqkJDS8Z6jwVxuvPt8fWzGkI0VTS18aF3ONJS1YodEtlq9BtUyyr 7hGKAwfdMFCh6FDT54bn4bpRIckkh21H7a7LPsW5BVNlnWs8x3UxZRwG8uwlR+ZXl4JH Lhq3FNVX7Ox7aVjiSz/NzoN5+o98/RbaW7e2Yesl1+GN4S8jLxLWcuusemBKQ+/ENTW7 ObX7wOC/RQ0vXVDFPoT/iHKc4XfQb5o0Ta0SCqxKKoC2LM/3RQY3AHExv2Pnwv4f5KUM 2y58NygVJzbF/gJZ8UKhVcNpDc9y5pHcymjYb0k/6kDli9KY0/b6V+cI3idbaqM9ugJP n1jQ== 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=SJ0a5B/WEPgqfliNlhjWTlHjOAYMj3XYZIyQeZh+REU=; b=qyUVfMqlrRcKVtkhxiihA6B7tH8+bEFziVzzt8fDHMWG7jltl9R8sKki9q7RNKQwZP KL/mKEWYxIUFfNE+Rmx4A436cX7zKVoFaS5h2vQtNId+bA2syy7hsc4Qq88kH8fQbQP3 DwRNZAIyHaGFBTjoBQpmQM7QKvgsWyM/BRhqFQC2BrvoyWW6ISeVWaUBL494eVuXq/gJ qtq8rU/oyf3+KeERprk2Uk4DLqB2cErlnYX1Qq9L+N2TQsuxYhgnMs7QcyOtGo+XnDzo OQicWJ0f0tNPRnh+9hKfwkeMpJmqmNzy/JRhjuJQfKYOiXqyFRpPOeRdUFWRQGLWI7vN r3UQ== X-Gm-Message-State: AOAM533USHhgEZsaJ96lYiMqXFVuU1UyzPWKNdcUxGlsOYoO3LHU6frK Ch9vVekaXzgMWUycEICaUs5O7A== X-Google-Smtp-Source: ABdhPJyGbE68NZD4nijdQqYmX9n+Zobj4noQdAiFmqbH6D7jgiykKN/yDTEoBFqkPBcfTK31rbaPRg== X-Received: by 2002:a5d:9f08:: with SMTP id q8mr662911iot.116.1628721287995; Wed, 11 Aug 2021 15:34:47 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id w8sm340503ill.50.2021.08.11.15.34.47 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Aug 2021 15:34:47 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <41ef848f-fff9-f1b3-197b-6ce8620db658@comcast.net> Date: Wed, 11 Aug 2021 18:34:46 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <10526DB2-307F-4755-B9B1-3017B224B677@brianrosen.net> References: <41ef848f-fff9-f1b3-197b-6ce8620db658@comcast.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] Please review draft RUM meeting minutes X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2021 22:34:54 -0000 I was on vacation. Came back yesterday (after delays in flights, = basically 24 hours traveling). Minutes look okay. Brian > On Aug 11, 2021, at 6:18 PM, Paul Kyzivat = wrote: >=20 > I got no responses to my earlier request for review of the meeting = minutes. This is a second try. >=20 > In particular, if you said anything during the session then please = check that your position has been accurately captured. Please ack or = nak. >=20 > Thanks, > Paul >=20 > On 8/2/21 2:43 PM, Paul Kyzivat wrote: >> I've posted draft minutes for the meeting among the meeting = materials, at: >> https://datatracker.ietf.org/meeting/111/materials/minutes-111-rum-01 >> Many thanks to Jonathan Lennox and Jim Malloy for taking notes. What = I've posted is a merge of their work. >> Please review and reply back if you see anything that should be = revised. >> Thank you, >> Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 19 08:14:22 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF233A1F2C for ; Thu, 19 Aug 2021 08:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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=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 0mxxxaUU1yiH for ; Thu, 19 Aug 2021 08:14:15 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2081.outbound.protection.outlook.com [40.107.237.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 B07923A1F26 for ; Thu, 19 Aug 2021 08:14:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BaQXKwTfUbXRPwV3jHXo1lGYhFnZkyPIA/ERSCwjpIVo5vTdiI8VUSDQ35D6xLFAGXB8OswZFner8BJaSUPqTe7V5bKOs6c9bq2/e0TyZmH4OPvij1AvGm8OXqma4Np9JpcTbo7P5jEcW/30iAOjDGbGNlsHEtfqHhBd9vgVp2XKxXniUtKBX0Ae/RuqwsuYjwfMvynwOsRU+H581Gh/6eIwKpzyZy8cfnoVd9bJgl0L3MR8XK6e3Ck6eDQG1+iLVvigxGzP5wn2P1gPsiGPBcsjYZCY33zNCwliG9/oUIXs1VaIFlJD+uJddgdmpVMdwwtUj4XvWBvxCbK+HtFSWQ== 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=kAX2FXkuvvUdxDAG8lnXqJ0ln3JEtXs5PUuo9K9gJG4=; b=LBD2Ga1M34z/Y5LrolR5zDlaeZni3hb5/8DXX0Nf2A3R55r4F+Deya4vgjlRy5lkxxtT/ihHPlqkrKWom3+Id3KXNwNo9B4MoVVX4QdzNCpPtan6bfS6dGo8ctHMjH49DqkmxA1ZTJg3MwfK2l6M65Mnjt71N5pK+2qWjqwsDdevmFeZ492JYKUEeDQ4LQUDeRCljlq5ANWM/9yJX+pML3b5L1v8cKRITAxckdFD2/kTBGcf3rEyIsOi+nPGXoXCd11x41v4ne4mEQU+QbRg6Qd+N/d9BjC8IA6WgBfKQciZSqF4XwSPe4wKJlJ064un2y4hqCKd2ALXw3lAVSn8+Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=kAX2FXkuvvUdxDAG8lnXqJ0ln3JEtXs5PUuo9K9gJG4=; b=OLpsflBI4xf/jt13xkxQkI65H692XferY0CE2QcdfbGfXAnV5pFvYGRgtvDuJnZ3zJZWYxDHTjLLS/RyB10UanpK6YneSOn6q6400UTnPj+quwKZrE52vnm5MbUUBQ3yFwJ1lAjFH+0J8f3CUCwut6Z3scS2OTOegpQgibc4eYA= Received: from SN7PR04CA0104.namprd04.prod.outlook.com (2603:10b6:806:122::19) by MN2PR12MB3360.namprd12.prod.outlook.com (2603:10b6:208:c7::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 19 Aug 2021 15:14:13 +0000 Received: from SN1NAM02FT0033.eop-nam02.prod.protection.outlook.com (2603:10b6:806:122:cafe::20) by SN7PR04CA0104.outlook.office365.com (2603:10b6:806:122::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Thu, 19 Aug 2021 15:14:12 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT0033.mail.protection.outlook.com (10.97.5.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Thu, 19 Aug 2021 15:14:12 +0000 Received: from MacBook-Air.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 17JFE9WL013219 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 19 Aug 2021 11:14:10 -0400 From: Paul Kyzivat To: rum@ietf.org References: Message-ID: <885be0c9-d1d7-0fe4-3030-67cd2e583de1@alum.mit.edu> Date: Thu, 19 Aug 2021 11:14:09 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.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-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9eb79a75-9556-49a5-0ca7-08d96324003c X-MS-TrafficTypeDiagnostic: MN2PR12MB3360: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: SrChgSA8LNwzbDptXZ72P3GlyieXf4pijh2WExDstXAiHms/y71+pSXcL1atIuif0TLQbA/bB0AWYfhzzwDGmR/D940YS5gMWCeelsBKpYKVRs5DkqiXbcqTfxViQ3hJrVwo52GWHD8/bNONC2tT5p7rNfDK6L8+LoNO47xVIUrqReWjWG0k8Rw5bCuYHxmMyJ5i47TeMe1Ta+nv0W1v0QJbusAlCLYEbpLlgnG/pPU+v1jPhjtYZ+Mi4bcrBqW+G/+jO2dploZJeyx5dV78aesoZ7fueuICW48qQI2B3Ky7vgc5pVlJMVmQB0UFmLu+doMTBvqCLJepIObMiTRUlPzXq3E7e9ze0N9wUy63MyubPPoGmRbe2c9u3U9hyIgATU1VUwLGZvyxRCH6pVPbsFQNWlI3JpIas2oFT+iQ/f5O6uZpAL/p1iLyjrAyzZcnFwQ2V4+/23A9nZOx18v8FpKZqEssFMEf+PqKWAPq/yAhwTgYA6r0aP1q9YUwYmK5MCfwlmVUFK3gOvinaXoXc80jdKc8XZX//qUvn3JHLev3XWdnvdYLqAdgj0lNN+BYirSVtPHtpslIMfLljq99I6xqnymmxDQoekpFPZLY8lxgodx9chy8T5DdnQZtxRACcdhyRYVLxFIC8kVll06cQ4F7+ajqjJcnINs1es8jeJgoGmmv/ave60d5Wejvq/9KMkRRv3byTexsLU/NuCa0Gsec94YnalhQRYCrTfFG/Z4dFrdFEaeIb+f3iicE8QD4wn/XGRKQuqZVxBFO1kaJpf53m0aQ1XIRgEtMk5Ag3xzGq03KQq0PiAwSqKbV5y+1 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; SFS:(46966006)(36840700001)(966005)(4744005)(75432002)(31696002)(956004)(336012)(70586007)(70206006)(36860700001)(82310400003)(86362001)(5660300002)(31686004)(47076005)(2906002)(2616005)(7596003)(8676002)(26005)(36906005)(356005)(508600001)(6916009)(186003)(316002)(786003)(53546011)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2021 15:14:12.1594 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 9eb79a75-9556-49a5-0ca7-08d96324003c 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-AuthSource: SN1NAM02FT0033.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3360 Archived-At: Subject: [Rum] Please review draft RUM meeting minutes X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 15:14:21 -0000 Brian indicated to me that he was satisfied with the minutes. I've asked for comments twice and had no other responses. So I have removed the DRAFT annotation from them and declare them final. Thanks, Paul On 8/2/21 2:43 PM, Paul Kyzivat wrote: > I've posted draft minutes for the meeting among the meeting materials, at: > > https://datatracker.ietf.org/meeting/111/materials/minutes-111-rum-01 > > Many thanks to Jonathan Lennox and Jim Malloy for taking notes. What > I've posted is a merge of their work. > > Please review and reply back if you see anything that should be revised. > >     Thank you, >     Paul > -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 19 09:04:03 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636E53A0127 for ; Thu, 19 Aug 2021 09:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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=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 8NINHQyxY-Rv for ; Thu, 19 Aug 2021 09:03:56 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2074.outbound.protection.outlook.com [40.107.236.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 2FAB93A0115 for ; Thu, 19 Aug 2021 09:03:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mAJgBi8cMRLZvMZm8hRXcqqRZSeN8Qow0OF/iCj7y+8Gg4oxtjyk76T3qW7SRMlkL4mZwC61sHVWzXJqHF7DtVBUh2m9SbqpJb13GcxULfSe0xc4lBVTjSO/xIyUHsgnqhE2RvKiQLSLBEOwUelAN0VIcOU6WzsrIAc9kFzQ1vtKx5KnzA7/FvaPCuqYvXQsGEY+A8vnlcbRZcrUKb0k1Us1/zsp+8BFAfcnc/Y4rfylD4jpi2qY2cxxbod6XC1vF6E6R51U3fYoWKzf5Kw5qikqcqyxz7RwW8GIwTBi1hIuj9V02GgEkk+0rGc0UX8Q0aszFINAFZ5TmJpERFbwXA== 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=6F6lqD3vWwIbXKLU5EPj1AI+0d2pMhOAF1WP8+Ero3s=; b=BabClWaeGK9wHIdxnXRP12QTh5xagxHn+mj2wfyH7NDhkzcI42bLYc6fiRDzturg8TmIXKyNyIuO0xBotreIjTGUx2HyFEWOX+/rj/4WpghLpM/NTNSldCFuQPMwgTypxYvc5Z34TTA20iLh8TfP1y37frTzElxWpMtkAssborDPCKGpxlLKz5lpiHr2tCk8IZ8ao9a4hOC2a5fYC+H/9kMUzSP15aLZsLcuQwI++irg0sc4Av4HnzLj3Eox5BDHaeKgGO5eO8Zwo/vwM6UDeZogk/gP17F5OoCB/Jzjzk3QP2huJ/l0s6OfP9hTYcR4fnXr8boL2vZu6Eu2bgP6ow== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=6F6lqD3vWwIbXKLU5EPj1AI+0d2pMhOAF1WP8+Ero3s=; b=XfgQJI5Dn5FUnxAX0v/kW7xrb9bSrvYlLiFZqGKLY9sPLrHBivhcGlqQcGEZyNUq3bfbNZYAzwF0pBDk4JI09QHuj84uhhzlBHROPsRTm1E421xiS7PJSdVFywbtv7QtqOahS95dVCzpTa1UtO60gAwGZ3h+QAPHYWGi4YB41Fc= Received: from DM6PR12CA0035.namprd12.prod.outlook.com (2603:10b6:5:1c0::48) by MN2PR12MB3453.namprd12.prod.outlook.com (2603:10b6:208:c3::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4415.24; Thu, 19 Aug 2021 16:03:54 +0000 Received: from DM3NAM02FT050.eop-nam02.prod.protection.outlook.com (2603:10b6:5:1c0:cafe::c1) by DM6PR12CA0035.outlook.office365.com (2603:10b6:5:1c0::48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Thu, 19 Aug 2021 16:03:54 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT050.mail.protection.outlook.com (10.13.5.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Thu, 19 Aug 2021 16:03:53 +0000 Received: from MacBook-Air.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 17JG3pjo016816 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 19 Aug 2021 12:03:52 -0400 From: Paul Kyzivat To: "rum@ietf.org" Cc: Brian Rosen , Isaac Roach , Alexander Ospina Message-ID: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> Date: Thu, 19 Aug 2021 12:03:51 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: b7df95c3-14bd-4914-9d64-08d9632af167 X-MS-TrafficTypeDiagnostic: MN2PR12MB3453: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: +XIMlI6Z+0hAwCp52Hj7HinYCWqGgtdWLFfEM3mzBYBXdaa26f1MB2gw3eZw2q66nj6JgxwfWGcWy0Tjpa+UfgcNXq6GDeyKhgC7E3A5gxW15DUjKoPFqpkPnQedreJRUSRyKGufynRJS3l3EUWRUB+13dLuJvGuZzjOfYg1tAjaZ4JyLnH2FjHmNoyOOtyAL6fTEeguRJL/q28tzUT3LzkjO/c9YnjQ+aV5HBdM8DARbyrao+FfmtSvtZH7Jtbv1eh2/AaLKIEgeWE+92GqRF++v9Eeq27y7+Q6Hxc1s3mouWXT0L40ejtfcx+0qro9VUPAx1tWbT9v/0fQ3+jg3CxBz7FN8OyxlvqEpgIPpacY2KNOQhrGCDYtJ41e9QqTF6r+LVcPvsOyHFtE+18QBsGIghKOmhH+Qrymwnuv8FXcBx16hM9KNSodxC00mwYaZSeMGDn8UQ/lIVFSQ65GOm+53PWQGb4Zj7RvvFl2JqDgOVUhE0Vo+4bF6hn3uUmRQcgobEIjBkHWRz/F5zRzpgBDBiNGYiuNzkJPAAbiAn6Zd3UMY4RsabGU/XRydx61WfHj0cl1X5ytWzhPdAESWpU2ZZ2NtUyfI51yGBirU6Wz9UC/wJYlfeZBSFpZPUo1Mjb7Hf95j066o1tF8MOwd/dJLXzVH+4oEeM0t7QqyPd4dF0yt0NmDFXAhnHwbRPibjFkZqYzdHVwpjBDKB7KzNOaWRKOKCqJKpED9xTVZBTixt890G0pBJzoH4MJWMxnsNIIR3vC5PaUbzJeI5kCL+32X8OtnhJrdkR0PRZqbpiaGJ4Y6se2jD78UUm4EA5n 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; SFS:(39860400002)(136003)(376002)(396003)(346002)(46966006)(36840700001)(478600001)(70206006)(70586007)(2906002)(786003)(8936002)(186003)(4744005)(31686004)(26005)(86362001)(8676002)(75432002)(47076005)(83380400001)(7596003)(316002)(966005)(6916009)(31696002)(5660300002)(4326008)(2616005)(956004)(336012)(82740400003)(82310400003)(36860700001)(36906005)(54906003)(356005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Aug 2021 16:03:53.8422 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: b7df95c3-14bd-4914-9d64-08d9632af167 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-AuthSource: DM3NAM02FT050.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3453 Archived-At: Subject: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2021 16:04:02 -0000 The minutes from the RUM session include a number of action items. Specifically, the following people made commitments: Brian Rosen Isaac Roach Alex Ospina Brian is working on an updated version, but it won't include the concerns of the others above if we don't hear from you. Rather than try to summarize those I refer you back to the minutes. You can find them at: https://datatracker.ietf.org/doc/minutes-111-rum/ I plan to issue WGLC on the document soon. I will wait one week (until Aug 26). If there hasn't been any followup by then I will ask Brian to issue a version that we can advance to WGLC. Thanks, Paul From nobody Wed Aug 25 11:59:03 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 780CF3A097E for ; Wed, 25 Aug 2021 11:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_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=sorenson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3fprvgE74VF6 for ; Wed, 25 Aug 2021 11:58:54 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2064.outbound.protection.outlook.com [40.107.92.64]) (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 4046E3A097A for ; Wed, 25 Aug 2021 11:58:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DhtIBYOZOycdVqWn+uAhvtVqwXkHBuaTj+uCHQU+sQGYvsetM5uz+1+beHhJ09EPShplNBU/PYJZrnECMN3MRb5GVhUXhNzZGCZOUg6IsiDZ7cyeaxLPEQXwTguJZlQZEc4j7rlK4kWO0tyozRO6yE8IsrKvLvvz4mu989+f2CjDFA7lXRrt5U4TTjiplWyh0Mv2fjoYVY5pKbZnt4ymHx6RXzXoZCKt44JhjAlkx9ar4BIY7IO60NqdtJx2cvpM0OHsht8HG5xxb2i1ZHmsf2ghv472rg13Trme4zQqRtwcio8KL6A+1bArix6qR24HIBgyNOzelWcSCilFm0ienA== 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=7z9QsceM9JJrzz8WYlWb5LoExn1NEJpL7zhNcGDUs2s=; b=UfUG0a4JRWXg//I5KPoqUQHxzF8NLF3A6ryhnq8y+rpmMRmXYJRFVSZDottmhc9gM4poD3LL2RJctBaYEOSmJs/POMjlH1RZ9Seb7rctqpDWMh3c2r9Nog57YSorTNL5I29SQ/GFWOgvmEtG697yKSrMWTtRJDsxdiE1L/CXIMuwEMLroS5hxPpsqpAhW0akQOc9Z3gwxdT6Me+9Z5FeBK/VIYPwBITDaGoqfxFFzX+CyhAKIgpU0KBy4svwe6tqmug8WPCtjWVAh0hyDtfq614pyEZO95+fuGcGru6EKbsawHpzDHO8hKCjIkbkF4spytWfnExpnQqH7kPTTih4tQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7z9QsceM9JJrzz8WYlWb5LoExn1NEJpL7zhNcGDUs2s=; b=waXJdGf0NdAlA8P+z5+I1uxfUtXdfZ6Tss6aBFSYqo6Xn5SIybggqGs1Q7GZUEP3ho4hYg4EloEyTaeCYtY/LQApQylSs+i+feQbEUBIQX2wNbMNhK6WCp4a73+x+/CtmyE02wGzk/hZ2c2nkXPK9o8l8kzc5juXScDGRLbBkh8= Received: from DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8::23) by DM8P223MB0141.NAMP223.PROD.OUTLOOK.COM (2603:10b6:5:316::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Wed, 25 Aug 2021 18:58:52 +0000 Received: from DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM ([fe80::3528:5280:95b3:be78]) by DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM ([fe80::3528:5280:95b3:be78%6]) with mapi id 15.20.4457.017; Wed, 25 Aug 2021 18:58:52 +0000 From: Eugene Christensen To: Paul Kyzivat , "rum@ietf.org" , Brian Rosen CC: Alexander Ospina , Isaac Roach Thread-Topic: [Rum] Action Items from RUM session at IETF 111 Thread-Index: AQHXlRPZt7hFqLzcF0KepaZkX2k/HquEmzFw Date: Wed, 25 Aug 2021 18:58:52 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> In-Reply-To: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@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=sorenson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba9ce4d6-9a66-4228-4ae9-08d967fa6156 x-ms-traffictypediagnostic: DM8P223MB0141: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UBMvBxiaUHbrZYVtODKqTdx3WuJuhbHj04AsBGUBlUd0UOmAk8SjO1mbySWKQ89RZC2iFA8jZAN+Oa9NACvQtcA6q9LHsJCH53HsnOnHohzZZQQqLFW7XWbyRiDUqzGBu1KU90dw20LDTGAMOUd8eZXBUgrnERvY7EAJrt5U1oc626kIgqqW78PD+lpi8WqHY4jjlr2RXDIkVKEouR3jnuZiYvE8By+zlj/KtjjWsLuyO8hYDRwSo58eYFR2ir4hq9mwZG06LNjONjuqyoJUVdmjZMlCcbR8FkmlNgzo2VwcGkYPB5tyECAKWyoDANGrXhxkpZhA1MKj88YysARhX/uR+/pcHyLVtuwwb0bnE4mIS7thcvXAtPO/jOhCfThaY0E5tjlwi+zcR6m093AXkAiOdxsF2pdXHmqa/nag3/k4KFBFQrzb90sD786muPQIEBsxzU3zsIkxatjbsxiBGMH7pIcgXGYlJZigcSyuUI7bBxsvDR+Nt6gtFSDRDF6zl3tdi6ZZGvdPqDq9CLl6hYsP1JDwdJUxmqHa3rUDcgA7DZ2Ru6rwwIMGhgae4FtkTKy4cgmXhIT6/JJwkpgVs1+3hraEIZHIqCk3XcVZ5Emp/mCw/4V8FsahJfU/wUmv5Ub6+75MPjUGp1+M5VLr4bPlEfKWnBUxQmQC0X1DWd1g9OtXNHjxuB4BfaWLvS3wX8zcQU19+4+jOR9qy78r0RzLHjVcPsoyk/fTzO4smGnwikJjjHpU2fz9rgUe9Z1w2YXPEToPFrec78zcHqxd4n2rgKRkrztxtHGcsc9o9Os= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(39850400004)(366004)(396003)(136003)(376002)(346002)(9686003)(186003)(38070700005)(316002)(8676002)(26005)(8936002)(55016002)(4326008)(2906002)(6506007)(53546011)(7696005)(83380400001)(64756008)(966005)(66476007)(76116006)(66946007)(478600001)(71200400001)(33656002)(54906003)(110136005)(5660300002)(52536014)(38100700002)(66556008)(66446008)(86362001)(107886003)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?fY3Bvw/pqjJZqWRV7d14t0HaKNaC+dh2BBa4S0ZCfu6kAi61YYuNxcrjUC4Y?= =?us-ascii?Q?Y4MwP3k9ahYZvbV1cBtkiQ8vTobf9OtltHBRwfnT3DfdTlgtC/NOAp1XcVZc?= =?us-ascii?Q?Lza94kYXhvGbaTEohfHyyfyXyNy0JbGv9vms4bcMetnOAi6PjQrLZeMEAZJW?= =?us-ascii?Q?qOty6X2whYa9lgKsf+cx4vjX7M0J+g3lBedQANK5SzPE+Hca83am130PlBSQ?= =?us-ascii?Q?RKPcyCPP4Au0QrVh0n3DvSvvABKy9avbQsR+ujVRFJGzMtKJKhcBvNFxP6de?= =?us-ascii?Q?MMX4R2nlWSKLR+IoK+/bxBDX5tCb5F1z9sQ7Q5NGItmenzleLSK1Yulxukwh?= =?us-ascii?Q?gmy1OptUXrW1TxdyzRcOg+GQE0jipSe/Kd3ChbkWej9v54ikGSMA67BDNcNw?= =?us-ascii?Q?Qr2aCIA60HDBh3YbQUrdDq8qrl2H0sfx1zgDQ2bbSGz5WRmuepvPgAlprlXU?= =?us-ascii?Q?uu/GnDHeqrRvcWtLiVUAyiimZbETrjqpybI0S1XfoPcZvr2pQpwXPP/1GCT8?= =?us-ascii?Q?TXjfDIdW2r3tWH1mBGeEMQYamVEcD78gyxm9BB5KuAQ5RM8Tpd7PcMJfSJId?= =?us-ascii?Q?O9nAJTJvUn76aPsaniz96QR8wHlViFZRfqwco3Yh/JZbZCVQj+dwMyHStkZ8?= =?us-ascii?Q?avoXlycZ1Sz5SzLRhjzOTw99p74hcRK+iZxDX7JHXM19fx64B3pBIl8v1N1z?= =?us-ascii?Q?QcBBefXbi4lU1I9+FY4K+4JR0ygDAiZUDp7+PCLgB1qH1LELa2PAUk75aJdz?= =?us-ascii?Q?pv8zGMno1MhccJTTKjbw2Dhswn5qhqiN5DwCCOSGTYYxJugiyu/NTpxSZKAt?= =?us-ascii?Q?HxKjN0cVZgbYKknHoztmPyC5k5Ie1yZaD7voGHACcc/Mc5lWG59FSZ/SfAts?= =?us-ascii?Q?V5x1POsB/zcb9F3aiuFILJai68kClPehRFHLCGcst11fWuLMRd4LeGTougMd?= =?us-ascii?Q?1hnUZ6Vr42vMH/hkXKo/PT9v4sbDEJyd9rBPdMc6tkstU4Ro6aBX/suqqLir?= =?us-ascii?Q?S3PPPVONtUYBiV5dcvo5b+ASza1hWD4SyOZ4IZiKy6CTH/pUP0nOyfxv/fDs?= =?us-ascii?Q?TT2cyuU1DYliMVEA/pXRa8eiB6XMWMb1rlT3C/dAFAs0qNpLhQp5LKaeZ3nV?= =?us-ascii?Q?IVg56lqt12l28sODXRJRxlSBHyB2Rb02Jhv8V+rA1fh11InWTsDx7wtOTZ7L?= =?us-ascii?Q?eqrL7MelJdIAzps/fUYqj7as50wMNfAb+LrKVMV6siWVTezpHUAUUQiaPnZX?= =?us-ascii?Q?CLgiN0N+wcf6ysjZPNIZG6h7REj2rCYarjqimqeehDXwD93aVIdXDn+v4BSR?= =?us-ascii?Q?+g9PoExDPL4rs9LOzBulIYwe?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: ba9ce4d6-9a66-4228-4ae9-08d967fa6156 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2021 18:58:52.0642 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: r7lo8CiogD3tEW36E/sK2f9mGHhEx7mJGk0de+9Go9dHkdDC96zaR1C+u1PkmrBFnOIwXUxuzu6+vdmIgq0UkVyrICfLnlVg0B3eyAgjhg8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8P223MB0141 Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 18:59:01 -0000 Brian, Paul thank you for considering the changes that have been brought up= to this point. Leaving things alone with the X-Card, the inclusion of the= instance-id for location, additions to support notification services for m= obile, etc. are all appreciated. =20 It is my opinion that we should not include requirements for the following = in the new RUM document. Here are the reasons that I believe this way. =20 WebRTC =20 * While there is an RFC for WebRTC, it doesn't appear that all browsers are= following it. For example, TMMBR is required for WebRTC but Chrome does n= ot signal it. * WebRTC is an audio first implementation. For VRS, video is the most impo= rtant media stream. It means everything to the deaf or hard of hearing use= r. If video is suffering first in a lossy network, that is a problem for V= RS. * Some of the VRS providers do not currently support the following items. = This could pose a significant impact on the VRS providers to get this imple= mented. o Encryption (DTLS) o ICE o RTP/RTCP Muxing =20 IPv6=20 * For those VRS providers whose current implementations do not support IPv6= , this can be a big jump to get their solution to support both IPv4 as well= as IPv6. Granted, it does not require being dual stacked but rather could= be two separate servers, each supporting their respective version of IP. = This could be a big undertaking just to get IPv6 into the mix. =20 * Another solution could be an IPv4 to IPv6 gateway but that doesn't work f= lawlessly. For example, the gateway can forward the IPv6 SIP message to th= e proper address on the IPv4 network, however, how does it resolve the embe= dded IPv6 addresses signaled in the SDP? So, for example, consider two RUE= s, one legacy RUE that is using IPv4 and one that is IPv6; the signaling is= possible for both once the servers for each support that or provide a IP g= ateway between the two. How is the media going to work? Each of the RUEs = is going to provide an IP address in their SDP, one will be IPv4 and the ot= her IPv6. How is this going to work without having to anchor all the media= somewhere? * Are there issues that we need to resolve with NAT64 and/or DNS64? =20 * As I understand it, some mobile devices are already IPv6 but do not follo= w the RFC for embedding an IPv4 address into an IPv6 address. This is goin= g to require special handling to get this to work with such devices on vend= ors that do not follow the RFC in this regard. =20 Message Waiting Indicator * Some, if not all, of the current implementations of RUE by VRS providers,= already include means to record video messages and are not all created the= same way. Proprietary methods have been used. The document states that M= WI is optional but if the ability to leave a message is provided then MWI i= s to be implemented. Since there are proprietary solutions, it seems appro= priate to me that this should be changed so that proprietary solutions and = indications can continue to be utilized. =20 =20 I don't believe I have enumerated all the reasons for not including require= ments for the above but I believe the examples given are sufficient to cons= ider. Regards, Eugene Christensen CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files = or previous e-mail messages attached to it, may contain confidential and pr= oprietary information. If you are not the intended recipient, or a person r= esponsible for delivering it to the intended recipient, you are hereby noti= fied that any disclosure, copying, distribution or use of any of the inform= ation contained in or attached to this message is STRICTLY PROHIBITED. If y= ou have received this transmission in error, please immediately notify me b= y reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287= -9419, and destroy the original transmission and its attachments without re= ading them or saving them to disk. -----Original Message----- From: Rum On Behalf Of Paul Kyzivat Sent: Thursday, August 19, 2021 10:04 AM To: rum@ietf.org Cc: Alexander Ospina ; Isaac Roach ; Brian Rosen Subject: [Rum] Action Items from RUM session at IETF 111 [EXTERNAL]=20 The minutes from the RUM session include a number of action items.=20 Specifically, the following people made commitments: Brian Rosen Isaac Roach Alex Ospina Brian is working on an updated version, but it won't include the=20 concerns of the others above if we don't hear from you. Rather than try=20 to summarize those I refer you back to the minutes. You can find them at: https://datatracker.ietf.org/doc/minutes-111-rum/ I plan to issue WGLC on the document soon. I will wait one week (until=20 Aug 26). If there hasn't been any followup by then I will ask Brian to=20 issue a version that we can advance to WGLC. Thanks, Paul --=20 Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Wed Aug 25 12:10:06 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A883A0029 for ; Wed, 25 Aug 2021 12:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 v1zkc-7yftVL for ; Wed, 25 Aug 2021 12:09:59 -0700 (PDT) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2087.outbound.protection.outlook.com [40.107.236.87]) (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 2BD8F3A00AE for ; Wed, 25 Aug 2021 12:09:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UBRANNhFPXScGoBBuQLqWkECTPg+9Nz8EYyOOl8vRKOvhJY1JJnZGAi5txme/65snmMBo7hONhXWJn6ebYYGHUYCdD/PIFj7SrTUrM+Rt6QfSRVkRbY9JDfb5hSwFI2Mbnb65u8EUsSvPZyNhSYYaST4SlBEJ4OFNcA6oIlbciJ7y+n4RFAIgX9ZAyvpzCRc7IrQ7u1KM+MHhyJgnQP27QoAiQol9DFZczS0i2xhcUlaeGo6SFoHdX4dMAN+7NUCrUAOwFv37v/jgDm4STGIZU5csIX1xFQOcQ6g+7TRX76uHRSCw0t/kM/6Mx4LKFhGKp4odjVEeEAjQyZvdnVVmw== 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=wn578FTTlyQ9RBaM1yK7edLsgW2qZJqN5PGNg//d0JA=; b=IZjgABn1gz3+JdMOyv+UXTuOhLjdf/7ZK9mRSLFXlEBVuWVMpWsoGB2nyLoJM64G0OVuGtMvkakaRzhKkfyId1y3kSx6PKy7HOqcYd0dNnMHGNDxAvdvBBx5/6IcyzMIJv3ZX5pyJWwf5zuoX+8Lk9RFPDs98Afwbl6jMPmYIFKRQwJlV5EVSOtUSmwjddbVBvAEU4xtl7Le5kUZkZdOWMsbyA3Dyg6EoeYYxU59VjkrhU7eSFwSiec3dzQP1X1zsmymeOz1f5tLvgxpTOjU7K42Z5ZcCNbaTb8Oy0Pl7TRRNIS5LraxXYOWb9Isz8l3ENMCLEimJ90OWFMpQ+DfSQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=sorenson.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=wn578FTTlyQ9RBaM1yK7edLsgW2qZJqN5PGNg//d0JA=; b=WYoeCx4rwp0waUvc4zcpg0LODKuBA7/tLG60XqCFqFuPREGXvtoGf3RU3F7DUFtaZc4EMFEWmUvwHt7Agz3UZKo01LVnhLa3CoKRAtZyeVQtwdXGwZazStGAh/Egkz2cmnRFp784lReAFC9ii4Fp5ik5uLip8ZfTzOI2e9+eivY= Received: from BN9PR03CA0209.namprd03.prod.outlook.com (2603:10b6:408:f9::34) by CH2PR12MB3750.namprd12.prod.outlook.com (2603:10b6:610:14::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Wed, 25 Aug 2021 19:09:56 +0000 Received: from BN1NAM02FT011.eop-nam02.prod.protection.outlook.com (2603:10b6:408:f9:cafe::84) by BN9PR03CA0209.outlook.office365.com (2603:10b6:408:f9::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19 via Frontend Transport; Wed, 25 Aug 2021 19:09:56 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; sorenson.com; dkim=none (message not signed) header.d=none;sorenson.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT011.mail.protection.outlook.com (10.13.2.129) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Wed, 25 Aug 2021 19:09:56 +0000 Received: from MacBook-Air.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 17PJ9ru3019927 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 25 Aug 2021 15:09:54 -0400 To: Eugene Christensen , "rum@ietf.org" , Brian Rosen Cc: Alexander Ospina , Isaac Roach References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> From: Paul Kyzivat Message-ID: <989151a1-d5b0-5bea-ecea-1e2567aa710d@alum.mit.edu> Date: Wed, 25 Aug 2021 15:09:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6be69165-68d9-4f43-7d75-08d967fbed53 X-MS-TrafficTypeDiagnostic: CH2PR12MB3750: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: RgB8fpR5lN263b00kdo75vm03vyaFDnLq9gJqf6iVyfzOM34DUxmzdcPXLrngmrkPsw4PUMIEUZXATDAbVsbruryau3567PxyvORxvNLXw5IJTNBKev6+BfTe8MN1ah4u9xBjsfwg2hFCBDl36VxNA7hoF8DZSs6VREFDEweWiRsVdwn2PLfMoyVOWdexUP7YQenVMJXk5CxGbBGNNTA5j0h9NWTggP5lotC/Vu52p3Q4QHijSnd1prD00hMGtq2oLQPDx855HOY7RpGeM3U9nlnYeuXZt75yCo1+OIU7CSttfIoo+PAIGUDzzv/TrKJqvn8l4dHhsEPSn8JdKaYksFI3+72N1AASINmRLy9yU4P9F2kP7A/MEMoWYvHgQgCs4JrFetsS0RlqdN+gdGoGJ9qjs37FnpwQECFtNxDYs4goByLSkMYRQnuSTJTtNdEv1OTTLYcLkSf0BDSbYNNm77cJgdjgoOkEOmlfQ8L2DmlMTdlBXlRSxOlVF4TtEC/Ko4XorSV36Ob4QlT2pPYfywYB0gSLcixmDP/qUsePS5z9sAOk4CCbtTr39HQ4+4FwX/e0MYmtcIf+DqaQ9o11rpkpt28pEhpLyPry+Q01N0CqZMt4HmBKoJiAMniL9PTWS1B0PVy+vWgdZSpNqyXQTg1PZN0ZWdouvJp/1Z82h/Mxs00OSh9v/InkW4/iZdfHCgjOFM6A2IEUOkN08s9QcZ4G+l7vYqhv6YLHpKkkQ+1oHNWea14LPeOW/4srinbYvCRZQDT/SD8QIvRRm8QlcSn0/8mX1tEayOggRQwweZk1J+B56OkXVcs8JJ8u6C5 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; SFS:(46966006)(36840700001)(86362001)(36906005)(356005)(36860700001)(70206006)(2906002)(70586007)(31696002)(966005)(26005)(5660300002)(8936002)(31686004)(508600001)(82310400003)(75432002)(47076005)(956004)(336012)(53546011)(8676002)(7596003)(316002)(786003)(83380400001)(54906003)(110136005)(2616005)(4326008)(186003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Aug 2021 19:09:56.4760 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6be69165-68d9-4f43-7d75-08d967fbed53 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-AuthSource: BN1NAM02FT011.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB3750 Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 19:10:06 -0000 Eugene, Thank you for following up. I will respond to your comments, but I first want to see what others have to say. It would be good to hear the other providers view on these things too. Thanks, Paul On 8/25/21 2:58 PM, Eugene Christensen wrote: > Brian, Paul thank you for considering the changes that have been brought up to this point. Leaving things alone with the X-Card, the inclusion of the instance-id for location, additions to support notification services for mobile, etc. are all appreciated. > > It is my opinion that we should not include requirements for the following in the new RUM document. Here are the reasons that I believe this way. > > WebRTC > > * While there is an RFC for WebRTC, it doesn't appear that all browsers are following it. For example, TMMBR is required for WebRTC but Chrome does not signal it. > * WebRTC is an audio first implementation. For VRS, video is the most important media stream. It means everything to the deaf or hard of hearing user. If video is suffering first in a lossy network, that is a problem for VRS. > * Some of the VRS providers do not currently support the following items. This could pose a significant impact on the VRS providers to get this implemented. > o Encryption (DTLS) > o ICE > o RTP/RTCP Muxing > > IPv6 > * For those VRS providers whose current implementations do not support IPv6, this can be a big jump to get their solution to support both IPv4 as well as IPv6. Granted, it does not require being dual stacked but rather could be two separate servers, each supporting their respective version of IP. This could be a big undertaking just to get IPv6 into the mix. > * Another solution could be an IPv4 to IPv6 gateway but that doesn't work flawlessly. For example, the gateway can forward the IPv6 SIP message to the proper address on the IPv4 network, however, how does it resolve the embedded IPv6 addresses signaled in the SDP? So, for example, consider two RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signaling is possible for both once the servers for each support that or provide a IP gateway between the two. How is the media going to work? Each of the RUEs is going to provide an IP address in their SDP, one will be IPv4 and the other IPv6. How is this going to work without having to anchor all the media somewhere? > * Are there issues that we need to resolve with NAT64 and/or DNS64? > * As I understand it, some mobile devices are already IPv6 but do not follow the RFC for embedding an IPv4 address into an IPv6 address. This is going to require special handling to get this to work with such devices on vendors that do not follow the RFC in this regard. > > Message Waiting Indicator > * Some, if not all, of the current implementations of RUE by VRS providers, already include means to record video messages and are not all created the same way. Proprietary methods have been used. The document states that MWI is optional but if the ability to leave a message is provided then MWI is to be implemented. Since there are proprietary solutions, it seems appropriate to me that this should be changed so that proprietary solutions and indications can continue to be utilized. > > > I don't believe I have enumerated all the reasons for not including requirements for the above but I believe the examples given are sufficient to consider. > > Regards, > Eugene Christensen > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk. > > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Thursday, August 19, 2021 10:04 AM > To: rum@ietf.org > Cc: Alexander Ospina ; Isaac Roach ; Brian Rosen > Subject: [Rum] Action Items from RUM session at IETF 111 > > [EXTERNAL] > > The minutes from the RUM session include a number of action items. > Specifically, the following people made commitments: > > Brian Rosen > Isaac Roach > Alex Ospina > > Brian is working on an updated version, but it won't include the > concerns of the others above if we don't hear from you. Rather than try > to summarize those I refer you back to the minutes. You can find them at: > https://datatracker.ietf.org/doc/minutes-111-rum/ > > I plan to issue WGLC on the document soon. I will wait one week (until > Aug 26). If there hasn't been any followup by then I will ask Brian to > issue a version that we can advance to WGLC. > > Thanks, > Paul > From nobody Wed Aug 25 12:40:32 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95F523A0EA2 for ; Wed, 25 Aug 2021 12:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 YdHJSrsrdfED for ; Wed, 25 Aug 2021 12:40:05 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 1D5743A106F for ; Wed, 25 Aug 2021 12:40:03 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id u7so703630ilk.7 for ; Wed, 25 Aug 2021 12:40:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=7LxZjdB7QnJ0icKW7Mt2bEcJa89jxFbLkQ6aey8uE70=; b=BtH80YHlBqmFfN3IqQhOSrxZhQL/VyNHhF+kkYU8IKSqdm/B4AaIAWooUlb4S/Ownn a9rfseU5n7oeHdKio7oYjepAk33kO72bYXPxhYW3bEYTMXhHu6YsCRbjeF8xzBihlwsF ClrXAlOVXDzDuaiiMuJti3BYTdfTURnVEw0F6lejFvhpCWbBZuIyORmmFt0T/nYtEMZj WfUAzTOZMjmbUZ7bwjGYf362YxiwX6v9WwBgaPV8iCgSxt7KZkUGS8bXidOAmJ60fdu5 hc+mTElf3/c71LD2fHE2DqMR+7s3BYLpbCy+hX+s4aF3xs7Nt/LK7aFBN17sRRGMvOCI ErXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=7LxZjdB7QnJ0icKW7Mt2bEcJa89jxFbLkQ6aey8uE70=; b=F5NvnuowoDjP2cuONm5P98WHaWfyPkhQ0zFMyh3KaYiQdci3j+1iBkfblsLwwUiefl a9dFd8V91yv6RGnf/flkNcY9HohTsBZe6WyVQuw0yqPjQag8A0RzthVEgsJDIzGgeIQ9 kEjNIVTmzwLjerKY47ZSoI0xgcg88RKdwFx3JKuCNi5ee3t99kkCbZYgXcvMIHv+scLw 23acrNb9z+6CQNYPvPkWk4tdkSQiuhUcxVw2QHR/Wse1Ciqs6Azd3bHfgstPxUhA8c39 a0uB6xQeQUbHG0hf+cRSVePdUQ2BAwCg9L1vgwPAlz4pTQSMVRVJrRC/Pz3KgAOW7hck I0iw== X-Gm-Message-State: AOAM531RPgUvCnSCm7rWcN8tGTKtPjAkavxVO5COHeLqZnQG6wS9Wq4W hgAADC2RgUc05pOwvOrMrmtv6UwIg3B6kBsX X-Google-Smtp-Source: ABdhPJz36fC9mauyAOzHdT4rucK5D2ny8v6SK4O+1KHdS7rpW28axaRM9htRc0rKf1JLwvOPJ8q4GA== X-Received: by 2002:a92:c601:: with SMTP id p1mr31467782ilm.284.1629920401190; Wed, 25 Aug 2021 12:40:01 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id k7sm362178iok.22.2021.08.25.12.40.00 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 25 Aug 2021 12:40:00 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Message-Id: <2BD57242-5412-40DD-B983-D927142DCF6E@brianrosen.net> Date: Wed, 25 Aug 2021 15:39:59 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: [Rum] RFC8599 (SIP Push) will support Subscribe/Notify X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2021 19:40:08 -0000 I have checked, and I believe RFC8599 supports Push Notifications for = SIP event notification, which is what MWI uses. Section 6 of 8599 = specifically addresses procedures for dealing with long lived dialogs = that event notification would have. Brian From nobody Thu Aug 26 04:16:27 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D37763A00D4 for ; Thu, 26 Aug 2021 04:16:25 -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 6Wb8TuWnRPFa for ; Thu, 26 Aug 2021 04:16:19 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 F2BD33A00DB for ; Thu, 26 Aug 2021 04:16:16 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 5C60C1900; Thu, 26 Aug 2021 13:16:10 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: "Olle E. Johansson" In-Reply-To: Date: Thu, 26 Aug 2021 13:16:04 +0200 Cc: Olle E Johansson , Paul Kyzivat , Brian Rosen , Isaac Roach , Alexander Ospina Content-Transfer-Encoding: quoted-printable Message-Id: <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> To: Eugene Christensen , "rum@ietf.org" X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 11:16:26 -0000 Friends, This is the IETF after all.=20 We can=E2=80=99t let any documents be published without IPv6. The = problems you outline here are surely solved in existing implementations = of SIP, propably since many years ago. If not, we have work to do. In addition, RUM services without SRTP/DTLS will be used over any = network, including the Internet, and it is a very bad solution that = feels like something we sold in the SIP world a long time ago. The world = has moved since then. I strongly urge that the RUM specs has to require mandatory IPv6 support = as well as SRTP/DTLS encryption. I would personally go as far as to say that SRTP/DTLS is a MUST and = nothing else is ok, very much like WebRTC. In regards to proprietary vs open standards, this is again the IETF. We = produce open standards and a RUM specification has to point to a SIP = SUBSCRIBE/NOTIFY package for MWI.=20 Remember that what I=E2=80=99m talking about is documents as specified = by the IETF. Industry profiles and various services may go other ways, = but the IETF standards has to be up to date with best current practise. Cheers, /O > On 25 Aug 2021, at 20:58, Eugene Christensen = wrote: >=20 > Brian, Paul thank you for considering the changes that have been = brought up to this point. Leaving things alone with the X-Card, the = inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated. >=20 > It is my opinion that we should not include requirements for the = following in the new RUM document. Here are the reasons that I believe = this way. >=20 > WebRTC >=20 > * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it. For example, TMMBR is required for WebRTC = but Chrome does not signal it. > * WebRTC is an audio first implementation. For VRS, video is the most = important media stream. It means everything to the deaf or hard of = hearing user. If video is suffering first in a lossy network, that is a = problem for VRS. > * Some of the VRS providers do not currently support the following = items. This could pose a significant impact on the VRS providers to get = this implemented. > o Encryption (DTLS) > o ICE > o RTP/RTCP Muxing >=20 > IPv6=20 > * For those VRS providers whose current implementations do not support = IPv6, this can be a big jump to get their solution to support both IPv4 = as well as IPv6. Granted, it does not require being dual stacked but = rather could be two separate servers, each supporting their respective = version of IP. This could be a big undertaking just to get IPv6 into = the mix. =20 > * Another solution could be an IPv4 to IPv6 gateway but that doesn't = work flawlessly. For example, the gateway can forward the IPv6 SIP = message to the proper address on the IPv4 network, however, how does it = resolve the embedded IPv6 addresses signaled in the SDP? So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two. How is the = media going to work? Each of the RUEs is going to provide an IP address = in their SDP, one will be IPv4 and the other IPv6. How is this going to = work without having to anchor all the media somewhere? > * Are there issues that we need to resolve with NAT64 and/or DNS64? =20= > * As I understand it, some mobile devices are already IPv6 but do not = follow the RFC for embedding an IPv4 address into an IPv6 address. This = is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard. >=20 > Message Waiting Indicator > * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way. Proprietary methods have been used. The = document states that MWI is optional but if the ability to leave a = message is provided then MWI is to be implemented. Since there are = proprietary solutions, it seems appropriate to me that this should be = changed so that proprietary solutions and indications can continue to be = utilized. >=20 >=20 > I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider. >=20 > Regards, > Eugene Christensen >=20 > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and = destroy the original transmission and its attachments without reading = them or saving them to disk. >=20 > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Thursday, August 19, 2021 10:04 AM > To: rum@ietf.org > Cc: Alexander Ospina ; Isaac Roach = ; Brian Rosen > Subject: [Rum] Action Items from RUM session at IETF 111 >=20 > [EXTERNAL]=20 >=20 > The minutes from the RUM session include a number of action items.=20 > Specifically, the following people made commitments: >=20 > Brian Rosen > Isaac Roach > Alex Ospina >=20 > Brian is working on an updated version, but it won't include the=20 > concerns of the others above if we don't hear from you. Rather than = try=20 > to summarize those I refer you back to the minutes. You can find them = at: > https://datatracker.ietf.org/doc/minutes-111-rum/ >=20 > I plan to issue WGLC on the document soon. I will wait one week (until=20= > Aug 26). If there hasn't been any followup by then I will ask Brian to=20= > issue a version that we can advance to WGLC. >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 26 05:46:19 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F16D83A0D4E for ; Thu, 26 Aug 2021 05:41:42 -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, 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=mitre.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 h7RSJvNVsW6K for ; Thu, 26 Aug 2021 05:41:37 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B71003A0D4D for ; Thu, 26 Aug 2021 05:41:34 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3D9C06C0023 for ; Thu, 26 Aug 2021 08:41:33 -0400 (EDT) Received: from smtprhmv1.mitre.org (unknown [10.20.200.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id F21E98BC006 for ; Thu, 26 Aug 2021 08:41:32 -0400 (EDT) Received: from mwfesmtp-mgt.mitre.org (mwfesmtp-in.mitre.org [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id 1C1A980D55D for ; Thu, 26 Aug 2021 08:41:33 -0400 (EDT) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4GwMsm5xvGz29pvV; Thu, 26 Aug 2021 12:38:44 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2101.outbound.protection.outlook.com [104.47.64.101]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4GwMpW005jz29pxM for ; Thu, 26 Aug 2021 12:38:41 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dg6C3GH1kkMKI77yxMWndZBUPiSYe6x/zs3wJ6HtWGdWOfOy5RT+XtJ04XH7ihJAznucx30GYMDWKnp6jTS8BUWqUV9EigjjACAWOotXclpvgRcu9KGPO1aHMq9z4kqGuuRtnvmsv0/pFG/rCSLoQ6EQXUNAMXwYh1DmuBLUMvoz7yWWIilGqYvcYp0n15km+BayI3HmGlhfYs/Mhu2AIMxfro8Bf0Ctc9uEdOtbf0mTAgW4nObUkJ1g7slCDymw5ow9mUPeGo9sQLXTcvexU5Wq7iDhAQfeW6TwhKIAm75L5KLs5O1IvC0+29Xgi1ZahgP/PUa9mIxZwz9fi0TnBA== 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=Xsl+kcvgFVOHN+9NAV1tEy0HVxvn7bOUC9L4XSM0rws=; b=FxM2+79xumc3GQ3ssgEYj37mYz1PDyrUHvQ7XfY3QzUbrd5qajHpo9xeI52dnoZMu8EdVZzO7AY9R0rs5Ejy113d9WT7yAfVzxUV/VrIJ6HpasMdAHhU/AxY4WSuDn5657Z31Vrpp4+IT4IvkDN98WIjTfZvLWj3n6ktvHtoX2AJYW/QM2b8Yd2Of+Tuo6th1behR/8iJG0DoVpeTbDpdCcSlcg3ZA971Di1m1ZJbPlIaX7fJleSQMNxIBGiDLmLyIAMCq0vmnAaMl9lJtsT2yWuElXyAYtNNTYJvoljmvy8/TOPGQ2ILXy60zAkybJAb0y9AF6XeUC6gU26HR6WuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from MN2PR09MB5979.namprd09.prod.outlook.com (2603:10b6:208:219::13) by MN2PR09MB4906.namprd09.prod.outlook.com (2603:10b6:208:217::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.21; Thu, 26 Aug 2021 12:38:40 +0000 Received: from MN2PR09MB5979.namprd09.prod.outlook.com ([fe80::d2:9ef2:376a:e94d]) by MN2PR09MB5979.namprd09.prod.outlook.com ([fe80::d2:9ef2:376a:e94d%2]) with mapi id 15.20.4436.027; Thu, 26 Aug 2021 12:38:40 +0000 From: Matthew H Garber To: "Rum@ietf.org" Thread-Topic: Release announcement: WebRTC VATRP v1.0 Thread-Index: AQHXmnV5lmYuxR3n50qcMACkrLFa3A== Date: Thu, 26 Aug 2021 12:38:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a697a92-8b56-4ddf-489d-08d9688e6ee6 x-ms-traffictypediagnostic: MN2PR09MB4906: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: iGAevN8NeHI9PlRo7mvjYhxcu+HOgjCroKSEz7q9GqkzhnHh3HOf9ofzOLYwxuh5sVLUDy1m04Z68uxkex/90/36c3CEPU5AGQq8omjWYudNco6FbraYsE2xQMRCAVy+8ndafN6dZL2yeizXXEQNHOj75SRzflqlXt10tuAXYliR7KLYI3O+PAxBEdefuAa5Cwv8CiMNk+OS0HRJ8PQ+Gi3uoEBAmTjEsb04VEi3w4UqWkZJOBR1BkYI6Tfo5eHYWGrzaKnj1m9KclFNyfSKBz6qEQfLbbuicMJJkZYQn/bm1h7T1zIRA1uRgbGHAKx1Fke0qVzdKKSglWiETeNyq42Lqq6I1BlRo4qJRj93bM7UzHMFaYYHe2TpbFUZz/6Vus7cfGVAKpDhovC/s+PXWTmuDLTFOKB7Qlg6na62YwtCH9733Vu7Y1CrzoEy062cbhecELJCmTsdoiVYFVSoppd05JWKaDJhT3yyOF0d3t+eQCwtKTnMlu/jE+xaB+VFlgU8BTD6RCcY8D2AqB3u8c+/Ny7u3GHn4pIITif2uFB3Eu8KIt3vxi1gLwH6Ahpm3N9ML8nASgmu4RmtOw5WTn2mj/a5ScnyKn0qEbIp9/A5nQaltgPLHVORDcA4KMTJHttxfddW/Usmne8AUL1sC0mGcbk3PrmMtdtY/wfjbwOK1BYrjrW1kG5qEhK3GJ0L2Q2aXv25+c9JlnPtgK1PmNLHRUNiNFzAkxRZ9VqQLyM7jLHobNy7qY5nw954XS9qnowNuxk+olrn2Jn8tsXKFkx8RvEXSG/P/n8k6kHUGqo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5979.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39860400002)(136003)(396003)(366004)(9686003)(86362001)(478600001)(6916009)(66556008)(66476007)(64756008)(66446008)(166002)(186003)(71200400001)(83380400001)(26005)(66946007)(2906002)(7696005)(76116006)(52536014)(966005)(5660300002)(6506007)(33656002)(8676002)(38070700005)(122000001)(55016002)(38100700002)(316002)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?+WMpB+gSz06hEwW0aozDGgY9ek/7LcbbL0TlnjuJVuB7Oy0FebG8ICVB?= =?Windows-1252?Q?UKesNJAmGHbQQ0Rjvys7JoRHc31G0l3Rd5SSEq4rqECM+2ZTFaT7FjEF?= =?Windows-1252?Q?waFnhPshKiTUge+RmzL5Jsh+LB04xghngyhJcN9EifnA2AY+rNq+b02K?= =?Windows-1252?Q?udFrs/xI+8E29uiNvCZiqCBEYRFv6ahi+xk3Y2U1f5e4mXGmiPwaMCdH?= =?Windows-1252?Q?XZ7oEerN2lKT2uqRDy6lTj2YnjQCl2RdVnlcop76/aBjth6dRyoX0XgC?= =?Windows-1252?Q?TRKKVrGJAt84DxyBBMINcifAMYZO9/RhZ6aIZ+986KpWSc65PcJ5ojlV?= =?Windows-1252?Q?WwAO/waDqM5RB8ay/IdR8jSR6xS9oHURjXdQfnn1hJe1aUVEDjnKpece?= =?Windows-1252?Q?GtLvGk6orJbzXC7wFgO9y1GR6D/zddfm/tg1H//+HsbfyOKE1wvKyj0s?= =?Windows-1252?Q?+JfsYGH2RzOH0kPQ++v54VSe4KYFBdDOyIPeJ1hADPFEbUgnF29ZprAT?= =?Windows-1252?Q?XQDZowTlUitHQ6y7ewcST9pgM12GmfLwmJI9ZKkHswD89j+LIFY6xHD+?= =?Windows-1252?Q?eFUEHGOQyUTlDMjHQzWPgcxH19k5f/CxSPSl/spNvwIcXvQEEuv+r1jh?= =?Windows-1252?Q?8tZNxEAv8C0mT2StTgFsE8wmUoY8qGpArjBUdD0/3HLJPheFBTNNzaR8?= =?Windows-1252?Q?mTBXr/1U27xc7c+raMlTOmNJjGH81SPmuIrfqto9OXdf6Q9FILJ5mzgr?= =?Windows-1252?Q?ScrcYL6P0Tm886IEnQwvFrZQfbT8ocypq9JB1ukXwVB/ntWlVksHPOLw?= =?Windows-1252?Q?IB3mMaPsLAkJfhLZF8JQ7V5i25dxrWYo3vlkIbhCq4lEUkR3aJZxr+Ne?= =?Windows-1252?Q?zeM7oKp9okQ96e7jGVkfpRM4vzUMIILm9F9iKzaYNfm5Z1aLAzD5xAxg?= =?Windows-1252?Q?Ezx85H9YQP5vOuGzAYO020C085ksqP0orb/bATAIy1TD+OgJI0cB3F8k?= =?Windows-1252?Q?dFxO9veOy0xn4TKGaRbAg5rhG4Wiz+qGdeIURZBpiWDnxo+4xZalU652?= =?Windows-1252?Q?W5Kh1bg+W3JhuuwgK/eUzyiFxcERaEuPfKC95t/Cq7EHSk0nHsJl5SC5?= =?Windows-1252?Q?tDwHXTxfiJuR09G+Phf3Q2ToBBr5smg63OeYGbpyBxdcXX1ew70MH0+q?= =?Windows-1252?Q?mc6+hKdRCpfof/VB/x/nwYhcV6xHpyJ9sFrHGrjsMJzvLgih93LKSDoK?= =?Windows-1252?Q?gICEZ/dwdrUbn1kE8bagTm/sbIhKVGv4qhebtOg2j3npXFnlhu86xBWm?= =?Windows-1252?Q?lI0R23x0dzWOk56O3KIsp8afKTHy1R81rDSSBzl905O0zSih3kN7Zk6R?= =?Windows-1252?Q?XwOLgiruhgxtB0wLqQXgVW2pE/LZbRT5xwoSXQfB2e6/3Svnm+czz6By?= =?Windows-1252?Q?WLVxdXxcazFqmlyWAEx/VA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR09MB5979CCD32DFD5DA6DF7E4658A5C79MN2PR09MB5979namp_" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5979.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a697a92-8b56-4ddf-489d-08d9688e6ee6 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 12:38:40.3711 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB4906 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:content-type:mime-version; s=BTxNELhf; bh=Xsl+kcvgFVOHN+9NAV1tEy0HVxvn7bOUC9L4XSM0rws=; b=SlUa5Wk7KzMROvEH/LORTsJZhkVzEhY//k/ALl4kMLrvoY+2dfPwYt2qZE6XyAIdxV8g/GFYZz9WNVUX7KqaHb9A3LGhWT5iatM2gwFNGfqHH/ASZobLja5DvCnw1fHjbrmcSC2WaDzPC7TA4FN2sZSPj3AKu9JC86JZty5rJhw= Archived-At: Subject: [Rum] Release announcement: WebRTC VATRP v1.0 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 12:41:43 -0000 --_000_MN2PR09MB5979CCD32DFD5DA6DF7E4658A5C79MN2PR09MB5979namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Good morning all, Note: This is a second notice of the WebRTC VATRP v1.0 release and is inten= ded for a broader audience than the previous email MITRE has released the 1.0 version of a WebRTC based RUE client to the publ= ic ACE Github, located at https://github.com/mitrefccace/fcc-vatrp-webrtc .= This client has a communications driver for using the Janus Media Server f= rom Meetecho as a gateway to convert WebRTC-based messages to RTP/SRTP. It = will also communicate with a SIP server configured to receive WebRTC messag= es directly. The release notes for this application are at https://github.com/mitrefccac= e/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx = . There are known defects that prevent full RUE compliance outlined in the = release notes, but MITRE is planning follow-on releases to address these an= d any other discrepancies with future revisions to the working draft. Our i= ntent is to deliver an open source client that is 100% compliant with the f= inal RUM-RUE language. A release build is available for Windows and Mac at https://github.com/mitr= efccace/fcc-vatrp-webrtc/releases/tag/v1.0. We are actively looking for partners for testing interoperability with this= client =96 if you have an implementation you=92d like to try out, please d= on=92t hesitate to reach out to me and we=92ll work out a timeframe. Thanks, Matt Garber Group Lead/Lead Software Engineer L178 Collaboration and Social Computing 571-326-7167 MITRE | Solving Problems for a Safer World=99 --_000_MN2PR09MB5979CCD32DFD5DA6DF7E4658A5C79MN2PR09MB5979namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Good morning all,

 

Note: This is a second notice of the WebRTC VAT= RP v1.0 release and is intended for a broader audience than the previous em= ail 

 

MITRE has released the 1.0 version of a WebRTC = based RUE client to the public ACE Github, located at https://github.com/mitrefccace/fcc-vatrp-webrtc<= /span> . This client has a communications driver for using the Janus Media Server f= rom Meetecho as a gateway to convert WebRTC-based messages to RTP/SRTP. It = will also communicate with a SIP server configured to receive WebRTC messag= es directly.

 

The release notes for this application are at https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC= _TRS_WebRTC_VATRPv1-0_PR_21-1891.docx . There are known defects that prevent full RUE compliance outlined in the r= elease notes, but MITRE is planning&n= bsp;follow-on releases to address these and any other discrepancies with future revision= s to the working draft. Our intent is to deliver an open source client that= is 100% compliant with the final RUM-RUE language.

 

A release build is available for Windows and Ma= c at https://git= hub.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0. 

 

We are ac= tively looking for partners for testing interoperability with this client = =96 if you have an implementation you=92d like to try out, please don=92t h= esitate to reach out to me and we=92ll work out a timeframe.

 

Thanks,

 

Matt Garber

Group Lead/Lead Software Engineer

L178 Collaboration and Social Computing

571-326-7167

MITRE | Solving Problems for a Safer World=99

 

 

--_000_MN2PR09MB5979CCD32DFD5DA6DF7E4658A5C79MN2PR09MB5979namp_-- From nobody Thu Aug 26 07:17:45 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6320A3A1873 for ; Thu, 26 Aug 2021 07:17:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 yTvP53jgc1rD for ; Thu, 26 Aug 2021 07:17:20 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 942733A186F for ; Thu, 26 Aug 2021 07:17:19 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id z10so4888944edb.6 for ; Thu, 26 Aug 2021 07:17:19 -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=SQcsxM2UtpFSayaIUcBcQLxSI+6J9iTqUbbqpmXZ9j0=; b=qr9SWE4+wx00PY1pVnKSqkb9ENa3Xnwgj72KNBlnFBx5RqwCq82VhyhNQCXyz0W0Nf F+bQ9lNkdHCx/qpAPhmwNx5tSRD8qXU7OvMNHdkPkvvs9i4vLxj0bvjzaNNU6F35FMPq LImdMiuNhMkJhW8n1KkQUx9Q419ZbNrC0tUtFsV6EEq5s+7aLY83O1Kf3ig8DWxtxKKC 1NzP9LMwxhot7RQ/f3eISaqbUS4OxNKe/Xv+Pwf1QoZMNTZgi7oJGpAdYCmZ8jP7z8lT fwB4EkVEvqSuS265Pi9eHYteW5lTThcjqvmeNL1OYCC9P+fak/7wX9kSRTjqSpOMhhJd NUNw== 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=SQcsxM2UtpFSayaIUcBcQLxSI+6J9iTqUbbqpmXZ9j0=; b=kuIg475ksai6OpSm9L6LCqJdlEW3bzQnisBXd8OBci0O8L1mOGhnuhbN0N4JfOhqOe /Rv+2Hoq3AQtDWM1fhTWWO1y2Cua01W76cGppWjOMGbKKGqqemv6w8ICK/HsTYNarbas cx1z3BOAJSrDLBdeWvx6nAvhaXDk5oeX9jmpLFFadS4/p4jgcpmSwwBwtIJPwSGIVnLP 72580+iz09yexFGAuvk9i7boDK75jPsjHLuup7+GV+rQqR1Kb1myL57TriAx0VEH7lk2 fN6ywDyNrOYslkPbwLTmv8UAg5qthfwVSBEEbpGWdWj5x8I4yS0tLBvg9voQ30wS6Ame BiRA== X-Gm-Message-State: AOAM531NVNTFyCwwputK/MD4QP8pBibIfPjBRsC5lmxNMCqqYQv23+1g rnYO6Nnwi1ZXzzHE1XvGJ0EGYWTVogDbVbbCM/E= X-Google-Smtp-Source: ABdhPJzPQvlyxvFJnsWbKnL35lgeMY0kkQoF4/TUW9UIMNa4SNtZqtZOsKuh0Rg9JlPhP+c6/IIWC0c+YqdJ5Z4ZmGI= X-Received: by 2002:a50:fd86:: with SMTP id o6mr4452883edt.312.1629987436440; Thu, 26 Aug 2021 07:17:16 -0700 (PDT) MIME-Version: 1.0 References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> In-Reply-To: <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> From: Roger Slusser Date: Thu, 26 Aug 2021 10:17:04 -0400 Message-ID: To: "Olle E. Johansson" Cc: Eugene Christensen , "rum@ietf.org" , Alexander Ospina , Isaac Roach , Paul Kyzivat , Brian Rosen Content-Type: multipart/alternative; boundary="000000000000232f0e05ca770666" Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 14:17:28 -0000 --000000000000232f0e05ca770666 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, First off these are personal comments and not as a spokesperson for the VRS provider I work for. I have to agree right down the line with Eugene Christensen. I have been a part of this from day one and have been directly involved in the setup and execution of the bi-annual Interop conferences and development of the Provider Interoperability Profile. It is obvious to me that this RUM RFC will be picked up by the FCC as the new spec for the VATRP. So let's not kid ourselves or mince words about implementations, industry profiles and various services. This endpoint spec will be terminated by a VRS provider Interpreter station or proprietary endpoint in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there are many, it will force the VRS providers to abandon current project plans and business goals to turn attention to implementing things in this RFC that have very little value to the Deaf and HH end users we support. Every provider already has a notification scheme for message waiting, most of which is much more elaborate and sophisticated than MWI, yet this RFC will force less desirable services... why? This is just an example that has been objected to since day one and yet it still has stuck like glue. Let's not lose focus of the driving force here, the betterment of the endpoint experience for the Deaf and HH user base. I understand this is IETF. I understand this must have the latest and greatest tech the industry has to offer, but I think the driving committee members of this RFC also need to understand the realities of implementation and the hardship this can and will bring to providers with the "MUSTs". The FCC denies funding for non compliance, the reality is these "MUSTs" could put providers out of business. I know there are heavy hitters in the IETF community on this project. But there are also founding members of the VRS industry who have offered comments with reasonable explanations that have been dismissed. After 18 year I believe we know our customer base. The Deaf employees in our companies in marketing and sales collectively drive our product offerings to best suit their needs because we eat our own dog food.. I would urge this committee to take long and hard consideration of the experience that in my opinion is being dismissed offhandedly for the sake of new tech that has very little to do with our customers needs or wants. Thanks for your consideration, Roger Slusser On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson wrote: > Friends, > This is the IETF after all. > > We can=E2=80=99t let any documents be published without IPv6. The problem= s you > outline here are surely solved in existing implementations of SIP, propab= ly > since many years ago. If not, we have work to do. > > In addition, RUM services without SRTP/DTLS will be used over any network= , > including the Internet, and it is a very bad solution that feels like > something we sold in the SIP world a long time ago. The world has moved > since then. > > I strongly urge that the RUM specs has to require mandatory IPv6 support > as well as SRTP/DTLS encryption. > > I would personally go as far as to say that SRTP/DTLS is a MUST and > nothing else is ok, very much like WebRTC. > > In regards to proprietary vs open standards, this is again the IETF. We > produce open standards and a RUM specification has to point to a SIP > SUBSCRIBE/NOTIFY package for MWI. > > Remember that what I=E2=80=99m talking about is documents as specified by= the > IETF. Industry profiles and various services may go other ways, but the > IETF standards has to be up to date with best current practise. > > Cheers, > /O > > > On 25 Aug 2021, at 20:58, Eugene Christensen > wrote: > > > > Brian, Paul thank you for considering the changes that have been brough= t > up to this point. Leaving things alone with the X-Card, the inclusion of > the instance-id for location, additions to support notification services > for mobile, etc. are all appreciated. > > > > It is my opinion that we should not include requirements for the > following in the new RUM document. Here are the reasons that I believe > this way. > > > > WebRTC > > > > * While there is an RFC for WebRTC, it doesn't appear that all browsers > are following it. For example, TMMBR is required for WebRTC but Chrome > does not signal it. > > * WebRTC is an audio first implementation. For VRS, video is the most > important media stream. It means everything to the deaf or hard of heari= ng > user. If video is suffering first in a lossy network, that is a problem > for VRS. > > * Some of the VRS providers do not currently support the following > items. This could pose a significant impact on the VRS providers to get > this implemented. > > o Encryption (DTLS) > > o ICE > > o RTP/RTCP Muxing > > > > IPv6 > > * For those VRS providers whose current implementations do not support > IPv6, this can be a big jump to get their solution to support both IPv4 a= s > well as IPv6. Granted, it does not require being dual stacked but rather > could be two separate servers, each supporting their respective version o= f > IP. This could be a big undertaking just to get IPv6 into the mix. > > * Another solution could be an IPv4 to IPv6 gateway but that doesn't > work flawlessly. For example, the gateway can forward the IPv6 SIP messa= ge > to the proper address on the IPv4 network, however, how does it resolve t= he > embedded IPv6 addresses signaled in the SDP? So, for example, consider t= wo > RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signali= ng > is possible for both once the servers for each support that or provide a = IP > gateway between the two. How is the media going to work? Each of the RU= Es > is going to provide an IP address in their SDP, one will be IPv4 and the > other IPv6. How is this going to work without having to anchor all the > media somewhere? > > * Are there issues that we need to resolve with NAT64 and/or DNS64? > > * As I understand it, some mobile devices are already IPv6 but do not > follow the RFC for embedding an IPv4 address into an IPv6 address. This = is > going to require special handling to get this to work with such devices o= n > vendors that do not follow the RFC in this regard. > > > > Message Waiting Indicator > > * Some, if not all, of the current implementations of RUE by VRS > providers, already include means to record video messages and are not all > created the same way. Proprietary methods have been used. The document > states that MWI is optional but if the ability to leave a message is > provided then MWI is to be implemented. Since there are proprietary > solutions, it seems appropriate to me that this should be changed so that > proprietary solutions and indications can continue to be utilized. > > > > > > I don't believe I have enumerated all the reasons for not including > requirements for the above but I believe the examples given are sufficien= t > to consider. > > > > Regards, > > Eugene Christensen > > > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain confidentia= l > and proprietary information. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any = of > the information contained in or attached to this message is STRICTLY > PROHIBITED. If you have received this transmission in error, please > immediately notify me by reply e-mail at echristensen@sorenson.com or by > telephone at +1 (801) 287-9419, and destroy the original transmission and > its attachments without reading them or saving them to disk. > > > > -----Original Message----- > > From: Rum On Behalf Of Paul Kyzivat > > Sent: Thursday, August 19, 2021 10:04 AM > > To: rum@ietf.org > > Cc: Alexander Ospina ; Isaac Roach < > IRoach@sorenson.com>; Brian Rosen > > Subject: [Rum] Action Items from RUM session at IETF 111 > > > > [EXTERNAL] > > > > The minutes from the RUM session include a number of action items. > > Specifically, the following people made commitments: > > > > Brian Rosen > > Isaac Roach > > Alex Ospina > > > > Brian is working on an updated version, but it won't include the > > concerns of the others above if we don't hear from you. Rather than try > > to summarize those I refer you back to the minutes. You can find them a= t: > > https://datatracker.ietf.org/doc/minutes-111-rum/ > > > > I plan to issue WGLC on the document soon. I will wait one week (until > > Aug 26). If there hasn't been any followup by then I will ask Brian to > > issue a version that we can advance to WGLC. > > > > Thanks, > > Paul > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > --000000000000232f0e05ca770666 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,
First off these are personal comments and n= ot as a spokesperson for the VRS provider I work for.=C2=A0

<= /div>
I have to agree right down the line with Eugene Christensen. I ha= ve been a part of this from day one and have been directly involved in the = setup and execution of the bi-annual Interop conferences and development of= the Provider Interoperability Profile.=C2=A0=C2=A0

It is obvious to me that this RUM RFC will be picked up by the FCC as the= new spec for the VATRP. So let's not kid ourselves or mince words abou= t implementations, industry profiles and various services. This endpoint sp= ec will be terminated by a VRS provider Interpreter station or proprietary = endpoint in 99% of the use cases. By mandating via "MUSTs" in thi= s RFC, and there are many, it will force the VRS providers to abandon curre= nt project plans and business=C2=A0goals to turn attention to implementing = things in this RFC that have very little value to the Deaf and HH end users= we support. Every provider already has a notification scheme for message w= aiting, most of which is much more elaborate and sophisticated than MWI, ye= t this RFC will force=C2=A0less desirable services... why? This is just an = example that has been objected to since day one and yet it still has stuck = like glue. Let's not lose focus of the driving force here, the betterme= nt of the endpoint experience=C2=A0for the Deaf and HH user base.=C2=A0=C2= =A0

I understand this is IETF. I understand this m= ust have the latest and greatest tech the industry has to offer, but I thin= k the driving committee members of this RFC also need to understand the rea= lities of implementation and the hardship this can and will bring to provid= ers with the "MUSTs". The FCC denies funding for non compliance, = the reality is these "MUSTs" could put providers out of business.= =C2=A0=C2=A0

I know there are heavy hitters in the= IETF community on this project. But there are also founding members of the= VRS industry who have offered comments with reasonable explanations=C2=A0t= hat have been dismissed. After 18 year I believe we know our customer base.= The Deaf employees in our companies in marketing and sales collectively dr= ive=C2=A0our product offerings to best suit their needs because we eat our = own dog food.. I would urge this committee to take long and hard considerat= ion of the experience that in my opinion is being dismissed offhandedly for= the sake of new tech that has very little to do with our customers needs o= r wants.

Thanks for your consideration,
= Roger Slusser=C2=A0

On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson = <oej@edvina.net&= gt; wrote:
Frien= ds,
This is the IETF after all.

We can=E2=80=99t let any documents be published without IPv6. The problems = you outline here are surely solved in existing implementations of SIP, prop= ably since many years ago. If not, we have work to do.

In addition, RUM services without SRTP/DTLS will be used over any network, = including the Internet, and it is a very bad solution that feels like somet= hing we sold in the SIP world a long time ago. The world has moved since th= en.

I strongly urge that the RUM specs has to require mandatory IPv6 support as= well as SRTP/DTLS encryption.

I would personally go as far as to say that SRTP/DTLS is a MUST and nothing= else is ok, very much like WebRTC.

In regards to proprietary vs open standards, this is again the IETF. We pro= duce open standards and a RUM specification has to point to a SIP SUBSCRIBE= /NOTIFY package for MWI.

Remember that what I=E2=80=99m talking about is documents as specified by t= he IETF. Industry profiles and various services may go other ways, but the = IETF standards has to be up to date with best current practise.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <echristensen@sorenson.com>= wrote:
>
> Brian, Paul thank you for considering the changes that have been broug= ht up to this point.=C2=A0 Leaving things alone with the X-Card, the inclus= ion of the instance-id for location, additions to support notification serv= ices for mobile, etc. are all appreciated.
>
> It is my opinion that we should not include requirements for the follo= wing in the new RUM document.=C2=A0 Here are the reasons that I believe thi= s way.
>
> WebRTC
>
> * While there is an RFC for WebRTC, it doesn't appear that all bro= wsers are following it.=C2=A0 For example, TMMBR is required for WebRTC but= Chrome does not signal it.
> * WebRTC is an audio first implementation.=C2=A0 For VRS, video is the= most important media stream.=C2=A0 It means everything to the deaf or hard= of hearing user.=C2=A0 If video is suffering first in a lossy network, tha= t is a problem for VRS.
> * Some of the VRS providers do not currently support the following ite= ms.=C2=A0 This could pose a significant impact on the VRS providers to get = this implemented.
> o Encryption (DTLS)
> o ICE
> o RTP/RTCP Muxing
>
> IPv6
> * For those VRS providers whose current implementations do not support= IPv6, this can be a big jump to get their solution to support both IPv4 as= well as IPv6.=C2=A0 Granted, it does not require being dual stacked but ra= ther could be two separate servers, each supporting their respective versio= n of IP.=C2=A0 This could be a big undertaking just to get IPv6 into the mi= x.=C2=A0
> * Another solution could be an IPv4 to IPv6 gateway but that doesn'= ;t work flawlessly.=C2=A0 For example, the gateway can forward the IPv6 SIP= message to the proper address on the IPv4 network, however, how does it re= solve the embedded IPv6 addresses signaled in the SDP?=C2=A0 So, for exampl= e, consider two RUEs, one legacy RUE that is using IPv4 and one that is IPv= 6; the signaling is possible for both once the servers for each support tha= t or provide a IP gateway between the two.=C2=A0 How is the media going to = work?=C2=A0 Each of the RUEs is going to provide an IP address in their SDP= , one will be IPv4 and the other IPv6.=C2=A0 How is this going to work with= out having to anchor all the media somewhere?
> * Are there issues that we need to resolve with NAT64 and/or DNS64?=C2= =A0
> * As I understand it, some mobile devices are already IPv6 but do not = follow the RFC for embedding an IPv4 address into an IPv6 address.=C2=A0 Th= is is going to require special handling to get this to work with such devic= es on vendors that do not follow the RFC in this regard.
>
> Message Waiting Indicator
> * Some, if not all, of the current implementations of RUE by VRS provi= ders, already include means to record video messages and are not all create= d the same way.=C2=A0 Proprietary methods have been used.=C2=A0 The documen= t states that MWI is optional but if the ability to leave a message is prov= ided then MWI is to be implemented.=C2=A0 Since there are proprietary solut= ions, it seems appropriate to me that this should be changed so that propri= etary solutions and indications can continue to be utilized.
>
>
> I don't believe I have enumerated all the reasons for not includin= g requirements for the above but I believe the examples given are sufficien= t to consider.
>
> Regards,
> Eugene Christensen
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, f= iles or previous e-mail messages attached to it, may contain confidential a= nd proprietary information. If you are not the intended recipient, or a per= son responsible for delivering it to the intended recipient, you are hereby= notified that any disclosure, copying, distribution or use of any of the i= nformation contained in or attached to this message is STRICTLY PROHIBITED.= If you have received this transmission in error, please immediately notify= me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9= 419, and destroy the original transmission and its attachments without read= ing them or saving them to disk.
>
> -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of Paul Kyzivat
> Sent: Thursday, August 19, 2021 10:04 AM
> To: rum@ietf.org=
> Cc: Alexander Ospina <aospina@aslservices.com>; Isaac Roach <IRoach@sorenson.com>;= Brian Rosen <br@= brianrosen.net>
> Subject: [Rum] Action Items from RUM session at IETF 111
>
> [EXTERNAL]
>
> The minutes from the RUM session include a number of action items. > Specifically, the following people made commitments:
>
> Brian Rosen
> Isaac Roach
> Alex Ospina
>
> Brian is working on an updated version, but it won't include the <= br> > concerns of the others above if we don't hear from you. Rather tha= n try
> to summarize those I refer you back to the minutes. You can find them = at:
> https://datatracker.ietf.org/doc/minutes-111-r= um/
>
> I plan to issue WGLC on the document soon. I will wait one week (until=
> Aug 26). If there hasn't been any followup by then I will ask Bria= n to
> issue a version that we can advance to WGLC.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--000000000000232f0e05ca770666-- From nobody Thu Aug 26 07:31:25 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D740B3A19AC for ; Thu, 26 Aug 2021 07:31:21 -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 bQ7Yx4y3N62y for ; Thu, 26 Aug 2021 07:31:13 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 D81F33A1990 for ; Thu, 26 Aug 2021 07:31:10 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 09A88217B; Thu, 26 Aug 2021 16:31:06 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_05B33826-5FBE-4841-A083-56B2BBCB6B67" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 16:31:05 +0200 In-Reply-To: Cc: Olle E Johansson , Eugene Christensen , "rum@ietf.org" , Paul Kyzivat , Alexander Ospina , Isaac Roach , Brian Rosen To: Roger Slusser References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 14:31:22 -0000 --Apple-Mail=_05B33826-5FBE-4841-A083-56B2BBCB6B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Aug 2021, at 16:17, Roger Slusser = wrote: >=20 > Hello all, > First off these are personal comments and not as a spokesperson for = the VRS provider I work for.=20 >=20 > I have to agree right down the line with Eugene Christensen. I have = been a part of this from day one and have been directly involved in the = setup and execution of the bi-annual Interop conferences and development = of the Provider Interoperability Profile. =20 >=20 > It is obvious to me that this RUM RFC will be picked up by the FCC as = the new spec for the VATRP. Roger, With all respect. There is a world outside the USA. RFCs are written = with global scope, not limited to a specific market or group of vendors. > So let's not kid ourselves or mince words about implementations, = industry profiles and various services. This endpoint spec will be = terminated by a VRS provider Interpreter station or proprietary endpoint = in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there = are many, it will force the VRS providers to abandon current project = plans and business goals to turn attention to implementing things in = this RFC that have very little value to the Deaf and HH end users we = support. Every provider already has a notification scheme for message = waiting, most of which is much more elaborate and sophisticated than = MWI, yet this RFC will force less desirable services... why? This is = just an example that has been objected to since day one and yet it still = has stuck like glue. Let's not lose focus of the driving force here, the = betterment of the endpoint experience for the Deaf and HH user base.=20 I think being able to get privacy and be able to use all networks, = including the old IPv4 networks, is a good experience. > =20 >=20 > I understand this is IETF. I understand this must have the latest and = greatest tech the industry has to offer, but I think the driving = committee members of this RFC also need to understand the realities of = implementation and the hardship this can and will bring to providers = with the "MUSTs". The FCC denies funding for non compliance, the reality = is these "MUSTs" could put providers out of business. =20 A MUST in an RFC points to an implementation. It doesn=E2=80=99t provide = a profile for a service. If a service provider only provides IPv4 = that=E2=80=99s ok (depending on the customer requirements of course). = But to be RFC compliant and interoperable, an implementation has to be = able to support what=E2=80=99s specified as MUSTs. >=20 > I know there are heavy hitters in the IETF community on this project. = But there are also founding members of the VRS industry who have offered = comments with reasonable explanations that have been dismissed. After 18 = year I believe we know our customer base. The Deaf employees in our = companies in marketing and sales collectively drive our product = offerings to best suit their needs because we eat our own dog food.. I = would urge this committee to take long and hard consideration of the = experience that in my opinion is being dismissed offhandedly for the = sake of new tech that has very little to do with our customers needs or = wants. IPv6 is not new tech at this point. SRTP/DTLS is implemented in millions = of web browsers out there, with many implementations in Open Source. = It=E2=80=99s not new tech, not at all. In fact I would be surprised if = the US FCC does not require IPv6. I have been working with social care alarms as well as telephony for = deaf and hearing impaired. The users don=E2=80=99t deserve old = technology or a lack of privacy. If you ask them it would be assumed = that you work on all kind of networks - mobile, wifi, fixed and they = trust you to give them privacy. They won=E2=80=99t specify that in = technichal terms, it=E2=80=99s just assumed. /O >=20 > Thanks for your consideration, > Roger Slusser=20 >=20 > On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson > wrote: > Friends, > This is the IETF after all.=20 >=20 > We can=E2=80=99t let any documents be published without IPv6. The = problems you outline here are surely solved in existing implementations = of SIP, propably since many years ago. If not, we have work to do. >=20 > In addition, RUM services without SRTP/DTLS will be used over any = network, including the Internet, and it is a very bad solution that = feels like something we sold in the SIP world a long time ago. The world = has moved since then. >=20 > I strongly urge that the RUM specs has to require mandatory IPv6 = support as well as SRTP/DTLS encryption. >=20 > I would personally go as far as to say that SRTP/DTLS is a MUST and = nothing else is ok, very much like WebRTC. >=20 > In regards to proprietary vs open standards, this is again the IETF. = We produce open standards and a RUM specification has to point to a SIP = SUBSCRIBE/NOTIFY package for MWI.=20 >=20 > Remember that what I=E2=80=99m talking about is documents as specified = by the IETF. Industry profiles and various services may go other ways, = but the IETF standards has to be up to date with best current practise. >=20 > Cheers, > /O >=20 > > On 25 Aug 2021, at 20:58, Eugene Christensen = > wrote: > >=20 > > Brian, Paul thank you for considering the changes that have been = brought up to this point. Leaving things alone with the X-Card, the = inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated. > >=20 > > It is my opinion that we should not include requirements for the = following in the new RUM document. Here are the reasons that I believe = this way. > >=20 > > WebRTC > >=20 > > * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it. For example, TMMBR is required for WebRTC = but Chrome does not signal it. > > * WebRTC is an audio first implementation. For VRS, video is the = most important media stream. It means everything to the deaf or hard of = hearing user. If video is suffering first in a lossy network, that is a = problem for VRS. > > * Some of the VRS providers do not currently support the following = items. This could pose a significant impact on the VRS providers to get = this implemented. > > o Encryption (DTLS) > > o ICE > > o RTP/RTCP Muxing > >=20 > > IPv6=20 > > * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6. Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP. This could be a big undertaking just to get = IPv6 into the mix. =20 > > * Another solution could be an IPv4 to IPv6 gateway but that doesn't = work flawlessly. For example, the gateway can forward the IPv6 SIP = message to the proper address on the IPv4 network, however, how does it = resolve the embedded IPv6 addresses signaled in the SDP? So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two. How is the = media going to work? Each of the RUEs is going to provide an IP address = in their SDP, one will be IPv4 and the other IPv6. How is this going to = work without having to anchor all the media somewhere? > > * Are there issues that we need to resolve with NAT64 and/or DNS64? =20= > > * As I understand it, some mobile devices are already IPv6 but do = not follow the RFC for embedding an IPv4 address into an IPv6 address. = This is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard. > >=20 > > Message Waiting Indicator > > * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way. Proprietary methods have been used. The = document states that MWI is optional but if the ability to leave a = message is provided then MWI is to be implemented. Since there are = proprietary solutions, it seems appropriate to me that this should be = changed so that proprietary solutions and indications can continue to be = utilized. > >=20 > >=20 > > I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider. > >=20 > > Regards, > > Eugene Christensen > >=20 > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by = telephone at +1 (801) 287-9419, and destroy the original transmission = and its attachments without reading them or saving them to disk. > >=20 > > -----Original Message----- > > From: Rum > On = Behalf Of Paul Kyzivat > > Sent: Thursday, August 19, 2021 10:04 AM > > To: rum@ietf.org > > Cc: Alexander Ospina >; Isaac Roach >; Brian Rosen > > > Subject: [Rum] Action Items from RUM session at IETF 111 > >=20 > > [EXTERNAL]=20 > >=20 > > The minutes from the RUM session include a number of action items.=20= > > Specifically, the following people made commitments: > >=20 > > Brian Rosen > > Isaac Roach > > Alex Ospina > >=20 > > Brian is working on an updated version, but it won't include the=20 > > concerns of the others above if we don't hear from you. Rather than = try=20 > > to summarize those I refer you back to the minutes. You can find = them at: > > https://datatracker.ietf.org/doc/minutes-111-rum/ = > >=20 > > I plan to issue WGLC on the document soon. I will wait one week = (until=20 > > Aug 26). If there hasn't been any followup by then I will ask Brian = to=20 > > issue a version that we can advance to WGLC. > >=20 > > Thanks, > > Paul > >=20 > > --=20 > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum = > >=20 > > --=20 > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum = >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_05B33826-5FBE-4841-A083-56B2BBCB6B67 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 26 Aug 2021, at 16:17, Roger Slusser <rslusser1096@gmail.com> wrote:

Hello all,
First off these are personal = comments and not as a spokesperson for the VRS provider I work = for. 

I = have to agree right down the line with Eugene Christensen. I have been a = part of this from day one and have been directly involved in the setup = and execution of the bi-annual Interop conferences and development of = the Provider Interoperability Profile.  

It is obvious to me that = this RUM RFC will be picked up by the FCC as the new spec for the VATRP. =
Roger,
With all respect. There = is a world outside the USA. RFCs are written with global scope, not = limited to a specific market or group of vendors.

So let's not kid ourselves or = mince words about implementations, industry profiles and various = services. This endpoint spec will be terminated by a VRS provider = Interpreter station or proprietary endpoint in 99% of the use cases. By = mandating via "MUSTs" in this RFC, and there are many, it will force the = VRS providers to abandon current project plans and business goals = to turn attention to implementing things in this RFC that have very = little value to the Deaf and HH end users we support. Every provider = already has a notification scheme for message waiting, most of which is = much more elaborate and sophisticated than MWI, yet this RFC will = force less desirable services... why? This is just an example that = has been objected to since day one and yet it still has stuck like glue. = Let's not lose focus of the driving force here, the betterment of the = endpoint experience for the Deaf and HH user = base. 
I think being able to get = privacy and be able to use all networks, including the old IPv4 = networks, is a good experience.
 

I understand this is IETF. I understand this must have the = latest and greatest tech the industry has to offer, but I think the = driving committee members of this RFC also need to understand the = realities of implementation and the hardship this can and will bring to = providers with the "MUSTs". The FCC denies funding for non compliance, = the reality is these "MUSTs" could put providers out of = business.  
A MUST in an RFC = points to an implementation. It doesn=E2=80=99t provide a profile for a = service. If a service provider only provides IPv4 that=E2=80=99s ok = (depending on the customer requirements of course). But to be RFC = compliant and interoperable, an implementation has to be able to support = what=E2=80=99s specified as MUSTs.

I know there are heavy = hitters in the IETF community on this project. But there are also = founding members of the VRS industry who have offered comments with = reasonable explanations that have been dismissed. After 18 year I = believe we know our customer base. The Deaf employees in our companies = in marketing and sales collectively drive our product offerings to = best suit their needs because we eat our own dog food.. I would urge = this committee to take long and hard consideration of the experience = that in my opinion is being dismissed offhandedly for the sake of new = tech that has very little to do with our customers needs or = wants.
IPv6 is not new tech at this point. = SRTP/DTLS is implemented in millions of web browsers out there, with = many implementations in Open Source. It=E2=80=99s not new tech, not at = all. In fact I would be surprised if the US FCC does not require = IPv6.

I have been working with = social care alarms as well as telephony for deaf and hearing impaired. = The users don=E2=80=99t deserve old technology or a lack of privacy. If = you ask them it would be assumed that you work on all kind of networks - = mobile, wifi, fixed and they trust you to give them privacy. They = won=E2=80=99t specify that in technichal terms, it=E2=80=99s just = assumed.

/O

Thanks for your = consideration,
Roger Slusser 

On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson = <oej@edvina.net> wrote:
Friends,
This is the IETF after all.

We can=E2=80=99t let any documents be published without IPv6. The = problems you outline here are surely solved in existing implementations = of SIP, propably since many years ago. If not, we have work to do.

In addition, RUM services without SRTP/DTLS will be used over any = network, including the Internet, and it is a very bad solution that = feels like something we sold in the SIP world a long time ago. The world = has moved since then.

I strongly urge that the RUM specs has to require mandatory IPv6 support = as well as SRTP/DTLS encryption.

I would personally go as far as to say that SRTP/DTLS is a MUST and = nothing else is ok, very much like WebRTC.

In regards to proprietary vs open standards, this is again the IETF. We = produce open standards and a RUM specification has to point to a SIP = SUBSCRIBE/NOTIFY package for MWI.

Remember that what I=E2=80=99m talking about is documents as specified = by the IETF. Industry profiles and various services may go other ways, = but the IETF standards has to be up to date with best current = practise.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <echristensen@sorenson.com> wrote:
>
> Brian, Paul thank you for considering the changes that have been = brought up to this point.  Leaving things alone with the X-Card, = the inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated.
= >
> It is my opinion that we should not include requirements for the = following in the new RUM document.  Here are the reasons that I = believe this way.
>
> WebRTC
>
> * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it.  For example, TMMBR is required for = WebRTC but Chrome does not signal it.
> * WebRTC is an audio first implementation.  For VRS, video is = the most important media stream.  It means everything to the deaf = or hard of hearing user.  If video is suffering first in a lossy = network, that is a problem for VRS.
> * Some of the VRS providers do not currently support the following = items.  This could pose a significant impact on the VRS providers = to get this implemented.
> o Encryption (DTLS)
> o ICE
> o RTP/RTCP Muxing
>
> IPv6
> * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6.  Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP.  This could be a big undertaking just to = get IPv6 into the mix. 
> * Another solution could be an IPv4 to IPv6 gateway but that = doesn't work flawlessly.  For example, the gateway can forward the = IPv6 SIP message to the proper address on the IPv4 network, however, how = does it resolve the embedded IPv6 addresses signaled in the SDP?  = So, for example, consider two RUEs, one legacy RUE that is using IPv4 = and one that is IPv6; the signaling is possible for both once the = servers for each support that or provide a IP gateway between the = two.  How is the media going to work?  Each of the RUEs is = going to provide an IP address in their SDP, one will be IPv4 and the = other IPv6.  How is this going to work without having to anchor all = the media somewhere?
> * Are there issues that we need to resolve with NAT64 and/or = DNS64? 
> * As I understand it, some mobile devices are already IPv6 but do = not follow the RFC for embedding an IPv4 address into an IPv6 = address.  This is going to require special handling to get this to = work with such devices on vendors that do not follow the RFC in this = regard.
>
> Message Waiting Indicator
> * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way.  Proprietary methods have been = used.  The document states that MWI is optional but if the ability = to leave a message is provided then MWI is to be implemented.  = Since there are proprietary solutions, it seems appropriate to me that = this should be changed so that proprietary solutions and indications can = continue to be utilized.
>
>
> I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider.
>
> Regards,
> Eugene Christensen
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any = documents, files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) = 287-9419, and destroy the original transmission and its attachments = without reading them or saving them to disk.
>
> -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of = Paul Kyzivat
> Sent: Thursday, August 19, 2021 10:04 AM
> To: rum@ietf.org
> Cc: Alexander Ospina <aospina@aslservices.com>; Isaac = Roach <IRoach@sorenson.com>; Brian Rosen <br@brianrosen.net>
> Subject: [Rum] Action Items from RUM session at IETF 111
>
> [EXTERNAL]
>
> The minutes from the RUM session include a number of action items. =
> Specifically, the following people made commitments:
>
> Brian Rosen
> Isaac Roach
> Alex Ospina
>
> Brian is working on an updated version, but it won't include the =
> concerns of the others above if we don't hear from you. Rather than = try
> to summarize those I refer you back to the minutes. You can find = them at:
> https://datatracker.ietf.org/doc/minutes-111-rum/
>
> I plan to issue WGLC on the document soon. I will wait one week = (until
> Aug 26). If there hasn't been any followup by then I will ask Brian = to
> issue a version that we can advance to WGLC.
>
>       Thanks,
>       Paul
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_05B33826-5FBE-4841-A083-56B2BBCB6B67-- From nobody Thu Aug 26 08:47:57 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A9253A10B8 for ; Thu, 26 Aug 2021 08:47:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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=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 N5vAQw09nlhx for ; Thu, 26 Aug 2021 08:47:49 -0700 (PDT) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2051.outbound.protection.outlook.com [40.107.212.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 01E313A109B for ; Thu, 26 Aug 2021 08:47:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eq9hDuMooD5Xl5LRcrGqF8ctMmjE0GSBs2HaO7gAS1Cp/ycAGZW4La93ZFykav6wvnWv8ilAzDVeUeqQDJo3BUMM+8djImMQWMDL1JLWt6FLKusR433TlFB1nJIxGEnaPZ5+J9qI//H9tMtTVdgVz4x6WXumyA5pzQDGGOhnmM0/z5w0e+Xmfmbv37MC7y4JYTaJaTzVeyZ22jY8cWyKt3kA97y4At2mS0GDqNlQkcmakxzxvf3xX0Zpbp0xArIpAVHRqRP0nSKXcsymJom/TnIX5TCuaH9IA6H45WvL1XB/Aip4Jk7jYNiI7VPK1km4o806KTEOB8alVJ9e+yj5vA== 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=nc1QdtxDUTk8N38PQfRprPwvGENm4dU6LAVl2vWD8Zc=; b=Ur1vfLH2XoHiCRGHnv0R+7YtfqFdkfWW+Pq9woMviCk6o12KVNf0dq4CT0Z+JiyF29I1HOwwnmepgyqYiRaGRuknOEYkPoLVhI+H3Nee+P9JddhC2bGPGa0Fog4L+TwOMqBS4AKBunmubZj7OHIL1IbVF/zB4P4c02Zcs1NbCczTMetvaYc/TrA39kjvTE5iF6TS5ZMopufVeC0e/8IWUnBrkr0e7PzlC7IPRrBXHnDJCe2QA7Xf+sW2gC6E0WgS3XH/BlE1M9rOBZPgXHKSkb/vwi/EtwR2R19q38sIa4JTFjnes12/hpkDlb8PpUiRA/dI+9QlmGDCF2R4etrkvQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=sorenson.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=nc1QdtxDUTk8N38PQfRprPwvGENm4dU6LAVl2vWD8Zc=; b=UmiK0icAM1x9T1/vyQrNK955wn6yIjm7eUSNRKAJX9j4jfHYCV37q9KLDwWqCRAscn9CjWbe2wNWGvLfQd01qwMLSi0sBdr6xEVwPoX2HjuVHsuKMHVtef6MbqQvcz2OCGDIsGoYzWQjlIsv8joT9kFoXxOImKlcBVsBThwtAFA= Received: from BN9PR03CA0322.namprd03.prod.outlook.com (2603:10b6:408:112::27) by BY5PR12MB4098.namprd12.prod.outlook.com (2603:10b6:a03:205::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.24; Thu, 26 Aug 2021 15:47:45 +0000 Received: from BN1NAM02FT040.eop-nam02.prod.protection.outlook.com (2603:10b6:408:112:cafe::50) by BN9PR03CA0322.outlook.office365.com (2603:10b6:408:112::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.21 via Frontend Transport; Thu, 26 Aug 2021 15:47:45 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; sorenson.com; dkim=none (message not signed) header.d=none;sorenson.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT040.mail.protection.outlook.com (10.13.2.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 15:47:45 +0000 Received: from MacBook-Air.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 17QFlgL5006581 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 26 Aug 2021 11:47:43 -0400 To: Eugene Christensen , "rum@ietf.org" , Brian Rosen Cc: Alexander Ospina , Isaac Roach References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> From: Paul Kyzivat Message-ID: <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> Date: Thu, 26 Aug 2021 11:47:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1abf6474-1609-4512-559b-08d968a8d8e5 X-MS-TrafficTypeDiagnostic: BY5PR12MB4098: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 20Ba5QMP595VZhs32trSLwLMZzsPkLaIhB8gIuCX5W7eUyMOxF3b+tqBkOyMrbLRz2lu5RmEezAwzJ7k8YOV6bjKXZRjqYXKfMBms6ccNGTiUdUOgKM7ORLzyZFS1XGJqDBdu8gYcf+V+4V1Lk5BWEHZQ/tc4G0BnwhVj79OKURPgGWlzQiJeK/Kll+d2VUsBbmLYcGXRTgvA18V0uZtLkY8QsbWHUVXAE//EVIZxjKQH00T6ZguKFlvndKMbq1fVdwsW0HQ9mwnuBSrpHUymEgyrvQygdC/V7Il2sgkHAXc9aztkKjJixDJBbfpHez/iFa6CA5loFetG2LZ5LMG+3AFwv9aoWfd97KM+mUUNxMsoaoTegUg2bLY5CiU10x5ld5GsxmC/1KzbmAczHXsp6/MFjQtbBXPN0ZXUXRPoBym1Y3UvBztB38yuSR46ld4p707tkzIeHFmkC5dQzDr7QPN3313EvRN+/5kTO+PcORc85MhAyIbupMXYSrRdV3VxEW37rMtudpNdeVK/7tvEFDb/teVevJM04gGkN5aK9q3XHFOVw2nuO/P7cvFqsbP+38NsBL+PqrrCe787yP+4/ffiDhu78J1owEH/12ztFHI/QPg+BGuKspQ+/hT9L60BmxAxAA2EvmxKxV9HduvVXLviBX0WTtnwfFwaXd0JU6Cc7Ol+4qjKR1UE0UP7w/yXqHEom/KlEqKpeHB1voN1binM9+YA8LU4wjK1rg5aNGx/6BDF67wC4nf4h5htXvsuxgerErXa/tYklsa7ADjrW0SL9I9iaHjYaiNMxPBleLZFH7fgrAQu9EXh7rKUNTW 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; SFS:(46966006)(36840700001)(508600001)(8936002)(356005)(47076005)(966005)(336012)(8676002)(5660300002)(4326008)(2906002)(316002)(36906005)(786003)(2616005)(75432002)(110136005)(53546011)(86362001)(70206006)(54906003)(956004)(7596003)(70586007)(36860700001)(26005)(186003)(83380400001)(31696002)(82310400003)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 15:47:45.1638 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1abf6474-1609-4512-559b-08d968a8d8e5 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-AuthSource: BN1NAM02FT040.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4098 Archived-At: Subject: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 15:47:56 -0000 I want to split off MWI as different from the other issues you have raised. If I understand, your point is that each provider has a proprietary way of indicating video mail is waiting and retrieving it, so there is no need to do something different. (Please correct me if I have gotten this wrong.) The problem with this is that it means for a RUE to be able to access video mail it needs to support the proprietary mechanism of each provider it aims to work with. But interoperability of the RUE with multiple providers is an explicit goal of this work group. So we need a mechanism that the RUE can implement that will work with any provider. In principle this mechanism need not use the MWI mechanism, but coming up with some other, presumably purpose built, mechanism will be a hard sell. IMO proposals that fail to address this need for interoperability are out of scope. (To go there would require a change to the charter.) So, please frame video mail and MWI issues with interoperability as a requirement. Thanks, Paul (With my RUM WG Chair hat ON) On 8/25/21 2:58 PM, Eugene Christensen wrote: > Brian, Paul thank you for considering the changes that haved been brought up to this point. Leaving things alone with the X-Card, the inclusion of the instance-id for location, additions to support notification services for mobile, etc. are all appreciated. > > It is my opinion that we should not include requirements for the following in the new RUM document. Here are the reasons that I believe this way. > > WebRTC > > * While there is an RFC for WebRTC, it doesn't appear that all browsers are following it. For example, TMMBR is required for WebRTC but Chrome does not signal it. > * WebRTC is an audio first implementation. For VRS, video is the most important media stream. It means everything to the deaf or hard of hearing user. If video is suffering first in a lossy network, that is a problem for VRS. > * Some of the VRS providers do not currently support the following items. This could pose a significant impact on the VRS providers to get this implemented. > o Encryption (DTLS) > o ICE > o RTP/RTCP Muxing > > IPv6 > * For those VRS providers whose current implementations do not support IPv6, this can be a big jump to get their solution to support both IPv4 as well as IPv6. Granted, it does not require being dual stacked but rather could be two separate servers, each supporting their respective version of IP. This could be a big undertaking just to get IPv6 into the mix. > * Another solution could be an IPv4 to IPv6 gateway but that doesn't work flawlessly. For example, the gateway can forward the IPv6 SIP message to the proper address on the IPv4 network, however, how does it resolve the embedded IPv6 addresses signaled in the SDP? So, for example, consider two RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signaling is possible for both once the servers for each support that or provide a IP gateway between the two. How is the media going to work? Each of the RUEs is going to provide an IP address in their SDP, one will be IPv4 and the other IPv6. How is this going to work without having to anchor all the media somewhere? > * Are there issues that we need to resolve with NAT64 and/or DNS64? > * As I understand it, some mobile devices are already IPv6 but do not follow the RFC for embedding an IPv4 address into an IPv6 address. This is going to require special handling to get this to work with such devices on vendors that do not follow the RFC in this regard. > > Message Waiting Indicator > * Some, if not all, of the current implementations of RUE by VRS providers, already include means to record video messages and are not all created the same way. Proprietary methods have been used. The document states that MWI is optional but if the ability to leave a message is provided then MWI is to be implemented. Since there are proprietary solutions, it seems appropriate to me that this should be changed so that proprietary solutions and indications can continue to be utilized. > > > I don't believe I have enumerated all the reasons for not including requirements for the above but I believe the examples given are sufficient to consider. > > Regards, > Eugene Christensen > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk. > > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Thursday, August 19, 2021 10:04 AM > To: rum@ietf.org > Cc: Alexander Ospina ; Isaac Roach ; Brian Rosen > Subject: [Rum] Action Items from RUM session at IETF 111 > > [EXTERNAL] > > The minutes from the RUM session include a number of action items. > Specifically, the following people made commitments: > > Brian Rosen > Isaac Roach > Alex Ospina > > Brian is working on an updated version, but it won't include the > concerns of the others above if we don't hear from you. Rather than try > to summarize those I refer you back to the minutes. You can find them at: > https://datatracker.ietf.org/doc/minutes-111-rum/ > > I plan to issue WGLC on the document soon. I will wait one week (until > Aug 26). If there hasn't been any followup by then I will ask Brian to > issue a version that we can advance to WGLC. > > Thanks, > Paul > From nobody Thu Aug 26 09:06:17 2021 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1023A0781; Thu, 26 Aug 2021 09:05:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.36.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rum@ietf.org Message-ID: <162999394987.8364.12786299587813953324@ietfa.amsl.com> Date: Thu, 26 Aug 2021 09:05:49 -0700 Archived-At: Subject: [Rum] I-D Action: draft-ietf-rum-rue-07.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 16:05:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Relay User Machine WG of the IETF. Title : Interoperability Profile for Relay User Equipment Author : Brian Rosen Filename : draft-ietf-rum-rue-07.txt Pages : 33 Date : 2021-08-26 Abstract: Video Relay Service (VRS) is a term used to describe a method by which a hearing persons can communicate with deaf/Hard of Hearing user using an interpreter ("Communications Assistant") connected via a videophone to the deaf/HoH user and an audio telephone call to the hearing user. The CA interprets using sign language on the videophone link and voice on the telephone link. Often the interpreters may be supplied by a company or agency termed a "provider" in this document. The provider also provides a video service that allows users to connect video devices to their service, and subsequently to CAs and other deaf/HoH users. It is desirable that the videophones used by the deaf/HoH/H-I user conform to a standard so that any device may be used with any provider and that video calls direct between deaf/HoH users work. This document describes the interface between a videophone and a provider. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Aug 26 09:09:38 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B733A081F for ; Thu, 26 Aug 2021 09:09:36 -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 vLpyncfPjUnk for ; Thu, 26 Aug 2021 09:09:31 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 D515F3A080F for ; Thu, 26 Aug 2021 09:09:24 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id j15so3859105ila.1 for ; Thu, 26 Aug 2021 09:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=yuP3HWRT3ZnhdXP8uQ3uOU5XDOsLDmcfIpQ4oqp1SoM=; b=yiD7yWsGCOYH6sDlHERDWO0jeuGsdcUc1kTdNgpPnVBlPn15Oyc1saKvGTjRo90aiD U6rNe+Br8cwOs/5A1eWkkU/xcGez26MvF6F9sytLPOYGgwmGsVcBWW+uS/iwHYecheS3 JW1AfiE/dEqGQSR1hFcqjmmT0XPrNdjbMP/w8ibO+HuMtDYbMzrn0cvQZu1eO9WOfbgf u/O8i4jdA7xZU4lbyUgHtrETVyoGeo9+LXP+McBgLUfOOKcRxd2Jn+VfasbiFGWhW9XK 6BF2+PaEX2MjHoI9z40XBJPkZUvsZ3IX//ZaVXXI5MTjuf3c/ClTjtFYCk1l44MTKpXA KD9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=yuP3HWRT3ZnhdXP8uQ3uOU5XDOsLDmcfIpQ4oqp1SoM=; b=cTi/hyy8WJ/Ma2O2F9DmObeXZuOxhD0s0QyZP6K+UzwGkZIrkFvnxngRhmB7fSoy4r v4ife9h9e06uXAb9+PW+gw6VzE1fYfkoidu4ToA3Riuy8MyCvHbCgJYQJ4xduqu7RIEx 5ha3x6D1f4MzdlU+Kup1YxJSsialMZjBaKnqdUYpGMy93YTlGHT0fMv03YxG3rTAfEfH /Up8q6a0AtUIAOqJL1m4JthugQYsDmcGiqrBcVVIW4Melua9p7rN9Yjb6T1SrCuePQSS YHIqN//zrcymSx1T6QIY71zMC5Q76OOaWUUfUz6S9CXIDc4N4XtpyEGfwimvmnF0Mi2s gNsQ== X-Gm-Message-State: AOAM532Gbg+wlPAI//OiNH65UaxTu8cW3FFRpUFt+HV6S1JARqGxQ2vJ uX/pM12rcf7JOId7PBrBdFcR6Vxlsn3hupBv X-Google-Smtp-Source: ABdhPJyQkUUZBOBoNQQTf4NoLEgMHVOHDVFMObwbk2t5dH765gk5NmODf6F09tDUEGO/H8hVGFsdog== X-Received: by 2002:a92:d70f:: with SMTP id m15mr3215074iln.162.1629994162764; Thu, 26 Aug 2021 09:09:22 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id f6sm1978175ilr.77.2021.08.26.09.09.22 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 09:09:22 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 12:09:21 -0400 References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> To: rum@ietf.org In-Reply-To: <162999394987.8364.12786299587813953324@ietfa.amsl.com> Message-Id: <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-07.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 16:09:36 -0000 This version: Changes jCard to xCard Says ICE candidates with specific IP versions is allowed Doesn=E2=80=99t require MWI support if voicemail is not supported = (actually, 06 said that). I think the document is ready for work group last call. Brian > On Aug 26, 2021, at 12:05 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Relay User Machine WG of the IETF. >=20 > Title : Interoperability Profile for Relay User = Equipment > Author : Brian Rosen > Filename : draft-ietf-rum-rue-07.txt > Pages : 33 > Date : 2021-08-26 >=20 > Abstract: > Video Relay Service (VRS) is a term used to describe a method by > which a hearing persons can communicate with deaf/Hard of Hearing > user using an interpreter ("Communications Assistant") connected via > a videophone to the deaf/HoH user and an audio telephone call to the > hearing user. The CA interprets using sign language on the > videophone link and voice on the telephone link. Often the > interpreters may be supplied by a company or agency termed a > "provider" in this document. The provider also provides a video > service that allows users to connect video devices to their service, > and subsequently to CAs and other deaf/HoH users. It is desirable > that the videophones used by the deaf/HoH/H-I user conform to a > standard so that any device may be used with any provider and that > video calls direct between deaf/HoH users work. This document > describes the interface between a videophone and a provider. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-07 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Aug 26 09:16:24 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6123A0912 for ; Thu, 26 Aug 2021 09:16:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.703 X-Spam-Level: X-Spam-Status: No, score=-1.703 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 y7YOhvkxhKOq for ; Thu, 26 Aug 2021 09:16:18 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2043.outbound.protection.outlook.com [40.107.244.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 6C3DF3A090B for ; Thu, 26 Aug 2021 09:16:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G7V5TCmUuGAEd+4tfEBQEnTOaX9pLGWgoZVfKsSqx9KsUW+2M6SlRit20nYmL0tlJf+I8lYUU0IzaupiHSRxnAxtWNz4E/esHW7w74FJPPXLQc/Gb93o7sq2Omj8TgxbUQ5MoaGb5IQweB46tm5jP6A+plUazYr0m7QLQ/JjYEUILhaGeN9GCsCsQ/JmQQUsg9/t0W4TQrJRuplyc3avQvO7PN3WBzSE0WhOm65ESTB2oIdKdtdMNlljgBfKPsfCR16i5M5zrq2Pk0KJQdlqGKdvn66TMtri6Ft5+5GglUUtUdQeo8AtY/6oVOrscrIzPiOJnc7LUpYNdtKWeVYN7A== 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=lBRK4JF4IjVDvZcMi7e6rh/mf2w8ldjyAvOOemB0his=; b=SqlsVtdNKtnSrlfo4upEl0Byf4LrQb779T56jI8loVJF6r97RbXHf15rk4Z1AZZl4434UI5B5yg+q6vqjX7UanZNP4IgTbcrGYMtjNh+44xnx6kZxOkLa+GSqRwuvyqTkQHflAOTunLOAUVomDJVrRDsGofWsKcI7oK7SmzitukW5z3uLgioZvN4lAnLohITPm9k5VbohlWULPUTOvhrwkIa3RBMjaH9woptjfELvCi0qyKaut9+jrGu07pR+mH7HTjqbsTFRteZKXez2odjrljWey6JqirrGQBYeMsemGRnxE0KfPzP4vhp9QQdenQqz8NDaOD+o3/6fTiv8v3ICg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=lBRK4JF4IjVDvZcMi7e6rh/mf2w8ldjyAvOOemB0his=; b=hmNrWDP6ySMjdu10uP1Khc+H5cL6/AUI+5Fnshh8cta4DgwekBKViw85LXijCChcD+2ZpThfR3X3OIpDLKyFn1LZ9Y8/smt/z+q7ATRIxpjEGBe8OcHQInsEImr7hz2a9vd5SnX8EajG75XWdOpc/YrPR2ZrYn4h9hy0DXQkKYs= Received: from SN4PR0601CA0023.namprd06.prod.outlook.com (2603:10b6:803:2f::33) by BN8PR12MB3426.namprd12.prod.outlook.com (2603:10b6:408:4a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 16:16:16 +0000 Received: from SN1NAM02FT0054.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2f:cafe::f3) by SN4PR0601CA0023.outlook.office365.com (2603:10b6:803:2f::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Thu, 26 Aug 2021 16:16:16 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT0054.mail.protection.outlook.com (10.97.4.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 16:16:14 +0000 Received: from MacBook-Air.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 17QGGD2M008562 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 26 Aug 2021 12:16:13 -0400 To: rum@ietf.org References: From: Paul Kyzivat Message-ID: Date: Thu, 26 Aug 2021 12:16:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.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 X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 33be7fae-045f-4874-b8ca-08d968acd3ec X-MS-TrafficTypeDiagnostic: BN8PR12MB3426: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: TC7xAlyQFv0EtmuGc0C99DJWqXki6G9XucU/vIAuin8ALIqsMgW+GwLRA3EHLRnAM4w/s4LZZ0Qi/C/7LIllZzyWXSR0PjQUzDDcmFTheE+7Fs8oZVdvAiNAIvm8ggQambH4398N/LTtyZFR9HtEDqrRH4GTyTbVis37QW++sKumqEm/pVqYTO/9pHFRLd/pFr7HIEKf4rKolyewXZq+q3KEhjclM4c0Nh/8KA4YzmABw392nwdg4aDLPXZKpzA1qbFxs7Uty66RsWXYnJ79siVDsD3Hn0EjHG9IgOL/eZoqx9aa0EjNzrdpQlNCaIN04VtnAJP1sb9OcdAf6A8NjSGSeIeQMqkV1c9eKMEDslg91kPr0Zg6+33K4PR4SKpEvt0AfcKiKwa8xHOCIE98KV6cNOdsQaerBOxqEttXrRt25nmBtQz8wJ7C9zmhdFy2xlb+Uqp+o8O2b+sE1U7NfYv3CdmbE2c1m6sbvEniNU9/tlWFMz+N+NLBgMnV8JFbegf9vBD4Ro+inMjJCyZIzo0/0mvRHfZr2i+57zE42GYe9oJge4Ox5hLmwylpdMDJqCg9/IiKnvD1E/9KnrjJrIbZWCoNPnPRCNlboUPxvNeSBO0ElHK8Rr0FIbTx08AfLddBBV1tB6DmpYeqYj/9kAqY4Krt+Qa2Gz1STZUnym+LrmtkilHYchCmty9mlVAq65wecUlD6RM0Jj1rZKihD27EwevIGuQ5USPisHoXCjU03hSCPBML2z2bXcZ4Fsed2F6zgTp9if5+Hi1Yy9vJk4QAnkdKNf19jY+AxYHf8NoAxRxNg6lpyrSVjebRAmCjAyuq3k/1Bp6agRTZ8ewmJ3AmUEUo4wjqQ4MpY2OWVWw= 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; SFS:(46966006)(36840700001)(8676002)(70586007)(8936002)(70206006)(6916009)(36860700001)(356005)(31696002)(47076005)(75432002)(186003)(5660300002)(82310400003)(336012)(7596003)(2906002)(36906005)(786003)(316002)(26005)(31686004)(956004)(53546011)(2616005)(86362001)(508600001)(83380400001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 16:16:14.6816 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 33be7fae-045f-4874-b8ca-08d968acd3ec 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-AuthSource: SN1NAM02FT0054.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3426 Archived-At: Subject: Re: [Rum] Release announcement: WebRTC VATRP v1.0 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 16:16:23 -0000 Matt, Welcome to the RUM WG! (I don't recall seeing you post here before.) On 8/26/21 8:38 AM, Matthew H Garber wrote: > Good morning all, > > Note: This is a second notice of the WebRTC VATRP v1.0 release and is > intended for a broader audience than the previous email Thank you for publicizing this. "Running Code" is huge in building support for publishing an RFC. Also, implementina a spec almost always ferrets out issues. > MITRE has released the 1.0 version of a WebRTC based RUE client to the > public ACE Github, located > athttps://github.com/mitrefccace/fcc-vatrp-webrtc > . This client has a > communications driver for using the Janus Media Server from Meetecho as > a gateway to convert WebRTC-based messages to RTP/SRTP. It will also > communicate with a SIP server configured to receive WebRTC messages > directly. > > The release notes for this application are > athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx > . > There are known defects that prevent full RUE compliance outlined in the > release notes,butMITRE isplanningfollow-on releases to address these and > any other discrepancies with future revisions to the working draft. Our > intent is to deliver an open source client that is 100% compliant with > the final RUM-RUE language. While building this implementation have you come across any places where you think changes to the spec would be advantageous? I see that the RTT presents difficulties. Do you have any thoughts on how to ease that? > A release build is available > forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1.0 > . > > We are actively looking for partners for testing interoperability with > this client if you have an implementation youd like to try out, > please dont hesitate to reach out to me and well work out a timeframe. I'm guessing that you can't yet interoperate with the existing US VRS providers production networks. Have you built your own provider server that accepts calls from your RUE? Can it connect to and interoperate with real providers? Thanks, Paul From nobody Thu Aug 26 09:48:33 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF73A3A12BE for ; Thu, 26 Aug 2021 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.992 X-Spam-Level: X-Spam-Status: No, score=-1.992 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, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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 kfLCdZ92tVnW for ; Thu, 26 Aug 2021 09:48:29 -0700 (PDT) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2040.outbound.protection.outlook.com [40.107.94.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 738CF3A12C6 for ; Thu, 26 Aug 2021 09:48:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hAhVZfvzHb2xu6hlJQ/i9F4hShKncyhiV+TxGdwicrOqGrSPJtZQ9m9AgntFxuyo1EtDTwhjGiKv6Lcbtg8mb9ZhxdQ48SUlN0pGfp6lt9J7Q38Pxlrs3she3VJbMSFftqD+BkKQX9ltJL3SnFI8+beMScU0md9Jmk64sEBdNJ/zkKAKoP0Wyi+vtsGrKPD+70qK38/c4uWWC9mWLqiHE2TvqAATqwyDSt/ZK3GXPb84cG9rJuRIHaV4ZNqcnTSco7+FicaEBqjxv0zRWGCHzdIeUmsnnGXiz8pYXkIFQQYiACov7FuRlpFvhn3jeT5b+gjRQb5YZLkXFv6ov1NKLA== 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=7mUyvWi3ouidArsyGzDOo+GEOK1EEiR9tW2aA9b3pL0=; b=Vm7oOBjWx9G5hD8GZiNxyTPWf3tzWd+c/b3nfgOImqZcKT19oGiIXZeuXtW+NMe0K9gi9qoHqWW6tFAUUSxp2KUPmJP0siL13bi1qP1890babMWHQEssYdGQ+rMdTGNVOc0fa9VePB774oqpM+rpuQkA/gfbsiY93XlNXwZbyCbFF56yd59i8Rek4r/qOw3qurIHCcZg9dfNu2UnTJ5JJKujQlxPefXtT3tkhSd0FvEJiLHz4q/j4njV6jVdWvJtQYA4aFGCpVWfJaIE5B4i0+uXY7ehdYUzcaHpZevke24DEnBRpLmCDHnQw9E0aEVlp8CEtO2u1OCXGVwdFw/h3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=edvina.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=7mUyvWi3ouidArsyGzDOo+GEOK1EEiR9tW2aA9b3pL0=; b=JQsXLtuxGo/j/cCWAeez1yWYlhj43zBH9Ck3/H1coYwnYix1xYAIYr/Qq0pmDRv1jnj3+q+bjWrzpi8Yiwf+uHRPN4thX+4AlhOudZpPRSWnnpop9tR1YsV6a99eDreEN+Ov5+JjEeydL2MBKCxEE+wSYHKsbk4vOfAmWQY2mn8= Received: from DM5PR18CA0063.namprd18.prod.outlook.com (2603:10b6:3:22::25) by DM6PR12MB5533.namprd12.prod.outlook.com (2603:10b6:5:1bc::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Thu, 26 Aug 2021 16:48:28 +0000 Received: from DM3NAM02FT031.eop-nam02.prod.protection.outlook.com (2603:10b6:3:22:cafe::82) by DM5PR18CA0063.outlook.office365.com (2603:10b6:3:22::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Thu, 26 Aug 2021 16:48:28 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT031.mail.protection.outlook.com (10.13.4.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 16:48:26 +0000 Received: from MacBook-Air.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 17QGmKvG011051 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 26 Aug 2021 12:48:21 -0400 To: "Olle E. Johansson" , Roger Slusser Cc: Eugene Christensen , "rum@ietf.org" , Alexander Ospina , Isaac Roach , Brian Rosen References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> From: Paul Kyzivat Message-ID: <753583f9-d0ca-4b61-efea-4e8daaf0541b@alum.mit.edu> Date: Thu, 26 Aug 2021 12:48:20 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 348d82ca-a871-4c34-bc31-08d968b15373 X-MS-TrafficTypeDiagnostic: DM6PR12MB5533: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YNPC01lMgIq/KiLDahhmD6BuMWimKfOA750+Sh1Kku+8HIhfR1/CM1qMDfKDkB9qTNldusCgOz+iUGF/9CQQHS1z+edYdfXXvUcyZLoE/J2q5RtgpWJYg82hTu9jMnxYmboowm1dI6MvKrKwASSbXaPlA0ZoPSdY4e8PRQmJFHmLsad+ES0BPySOoNbf1LwP4jNYT8K12p3gxCtLtLQyjbv3Zw4QRiUfqVWPQr78zBkMSokU8MXoE6Yu/BsNvYtqut01mbMPjkyjOccjQjOqOfD1rdKst2swIJkFKwTktszpNR3I2+k0+qAQumDyfg+dP1DCf4Yq57rUvsUGuQCHBLKj4+uZ/3Mx0qXx9aeesc/Vjan1HiqB+UyweJuJJqx9pUgUIDBnavytNWFWtgkuwbgQi5RMNNaV9nFD8yCD+VPSTpuzQ3AlmteKysUeEjLAl2NncH/7ZO1zoQP/UaV95q8J81Y4C0u+R3TmZqO1MZ1uVJfn5EUqLxYgnYa6MkXSc5rSTOwpHEPkKdzdNfAprn8o/QC1yOW3bh90JHVtdqErE4FB8cvAr8MKFx5Mx36T3ibQRlGhqewi2znrrmeDUV3JBUWvpVQgcbag/cNBCQtYaoKZsacVIzwd453aJCJ8RSXhjuX2pQv4k1u5wdEEYzo4ozUYksBGKBgDBmOjza2oR2HxNh9wxSy5Aqzk6LmJTR+5/jWRCdSpT6qoxAo28HSLc+qcsn9LHzd09o6IED0= 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; SFS:(136003)(346002)(39860400002)(376002)(396003)(46966006)(36840700001)(47076005)(478600001)(956004)(2616005)(54906003)(8676002)(186003)(356005)(82310400003)(7596003)(26005)(82740400003)(8936002)(75432002)(86362001)(316002)(53546011)(110136005)(31686004)(70586007)(5660300002)(36860700001)(2906002)(786003)(36906005)(70206006)(336012)(4326008)(31696002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 16:48:26.7000 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 348d82ca-a871-4c34-bc31-08d968b15373 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-AuthSource: DM3NAM02FT031.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB5533 Archived-At: Subject: [Rum] Modern standards vs. VRS implementation practicalities X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 16:48:32 -0000 On 8/26/21 10:31 AM, Olle E. Johansson wrote: > > >> On 26 Aug 2021, at 16:17, Roger Slusser > > wrote: ... >> It is obvious to me that this RUM RFC will be picked up by the FCC as >> the new spec for the VATRP. ... >> I understand this is IETF. I understand this must have the latest and >> greatest tech the industry has to offer, but I think the driving >> committee members of this RFC also need to understand the realities of >> implementation and the hardship this can and will bring to providers >> with the "MUSTs". The FCC denies funding for non compliance, the >> reality is these "MUSTs" could put providers out of business. > A MUST in an RFC points to an implementation. It doesn’t provide a > profile for a service. If a service provider only provides IPv4 that’s > ok (depending on the customer requirements of course). But to be RFC > compliant and interoperable, an implementation has to be able to support > what’s specified as MUSTs. >> >> I know there are heavy hitters in the IETF community on this project. >> But there are also founding members of the VRS industry who have >> offered comments with reasonable explanations that have been >> dismissed. After 18 year I believe we know our customer base. The Deaf >> employees in our companies in marketing and sales collectively >> drive our product offerings to best suit their needs because we eat >> our own dog food.. I would urge this committee to take long and hard >> consideration of the experience that in my opinion is being dismissed >> offhandedly for the sake of new tech that has very little to do with >> our customers needs or wants. > IPv6 is not new tech at this point. SRTP/DTLS is implemented in millions > of web browsers out there, with many implementations in Open Source. > It’s not new tech, not at all. In fact I would be surprised if the US > FCC does not require IPv6. ISTM the keys to a path forward are lurking in the above. Certainly in the US it will be the FCC that decides what it wants to require. While it could require full conformance to the RFC that comes out of RUM it can also choose to only require a profile. And it can adjust the profile it requires over time as a way to ease migration. I know the FCC prefers refer to specs generated by standards bodies rather than creating specs itself. If there is need of a profile it is certainly possible that such work could be done in the SIP Forum, potentially as an extension to the VRS Provider Profile. Thanks, Paul From nobody Thu Aug 26 10:05:29 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 541B33A1463 for ; Thu, 26 Aug 2021 10:05:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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=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 4vr8Jtm3TuR4 for ; Thu, 26 Aug 2021 10:05:21 -0700 (PDT) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2059.outbound.protection.outlook.com [40.107.102.59]) (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 550EA3A1458 for ; Thu, 26 Aug 2021 10:05:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ur0JDKI3LOA1H24yJgkW5NbHFK+2NF1stHKuLq/vPkz/LpNWjOr0LC2SGHm7pXzGd3BGohHCQleif7zd+IOKrCICl0CBwJf43KG1NXhmS7cF7VBQvzSu1TDZuPATzOGWgGq7F1RAc6MwFuRctdRpudcUjiCWhhWh4MP3r2aKdt1hyVNQRDS8E4WcElx59hz1YX7L/pqlaZe7kIo0RuhouNpRNph9CdmBLgb8QKWUfzvxVoAoWzVuFR+i8OMQ8B4tuxs48yt77zfx2Uhac0pCyfyQtMQMT5my9bl2ZUDkZhIPHcTYioIV5ggkjunK2JZR2R6z3x6vIvAGbpGTKDrTXg== 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=u4h/JnFwC2PNl4ZDg6T2ezqwHaO3K9Xd+YVAuZi1Mas=; b=FFvIS1pXJHd+juyAtjEFAKcqCB4zvvXn5e8zHCrMSY4M5b7xBdo4Db0PxIZqLUbw3vh/tl+QH4J7FCk4x50Ikgp2ZUfCPN7VcJ/TR9FlFKk+gLlzOxzz1r9Ao6ZnUE7XXu8sCYEDjLt/38loyL5LQKycJq4QUs0Fm2q+nuCeSFmfUYyiQGdiNldZlqHwU7yr9xtPdoiIftzcuR9dUbv/4RxiDZTrVFKmOfF2xzzNY0jJIGN4cqg7/+0pP/PnRuuGIGjfBomU5XPRGso2Er6S+GyXLwuPu5sAGuVqHua/1NB4k7p01BCZxz5/bI499dM/RgxJcF0m3zI22BjBHOA8fw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=u4h/JnFwC2PNl4ZDg6T2ezqwHaO3K9Xd+YVAuZi1Mas=; b=RZwwt34CgpTDLdssCYiX3LUSUKLPQ2WvY3Z3fB98qUovDHLZe6Xfx6jWOw97Z+hzYwioRtEU7HqGBz8Jcbz8QDjMSXrZDEDEusO+IP8P687XixKjUToX1oluHAi+2O5qPWA1w83DQVIOo78NdnLnONN3UjukAgQmm+zWPwixA10= Received: from DM5PR19CA0052.namprd19.prod.outlook.com (2603:10b6:3:116::14) by BN8PR12MB3332.namprd12.prod.outlook.com (2603:10b6:408:66::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 17:05:15 +0000 Received: from DM3NAM02FT020.eop-nam02.prod.protection.outlook.com (2603:10b6:3:116:cafe::46) by DM5PR19CA0052.outlook.office365.com (2603:10b6:3:116::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.19 via Frontend Transport; Thu, 26 Aug 2021 17:05:15 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT020.mail.protection.outlook.com (10.13.4.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 17:05:14 +0000 Received: from MacBook-Air.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 17QH5COg012464 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 26 Aug 2021 13:05:13 -0400 To: rum@ietf.org References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> From: Paul Kyzivat Message-ID: <4b6b9930-d582-f1ef-09f4-9ec5bd29d53d@alum.mit.edu> Date: Thu, 26 Aug 2021 13:05:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 42f07b2b-a848-4f8f-ab7c-08d968b3abe6 X-MS-TrafficTypeDiagnostic: BN8PR12MB3332: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Wey4a2q5Pyr5onqZdo0wgNIW9PerT4ouPinRORC2DEOUqRBeXid1XEXLIz/dYinUrPyPGNxyCubInSUvty4rHbzdTa2HgmHbqVWOGU9KdiOI2KF4ipusI5pSvg1k9VAAHnDEmrk1rYja6nvO4ELj6tU50xdh82W0GCXtaWmSjcekJC6O1KyTlCUx/sCyCmp/Ss9vOCpeDZwLmt99g9nDvrHyXChlhTgSr6iBOgXlqODEEee52OFDl5x4Ltf+KZsbvFlgw1dC6Rg7gYFFnvb5Pef4EeSlxX3fqwGNDBo1ZP9tmdg4bD2j0WiMKvd3Y/8BEKgcYafSfUKcLc8fZY4S8YzO9+8q5tHsywpAMxek60ZLDJVLyW2zJtLvJabJ6G0INaerX1Ey36Ua6EFAM91g5myMmAVq7HQKi4yNJgf0irr8If8fOnvG+jnGZRJqKTonP52nPveOyXZ2J3Y9w8UroSy31nfItCgiRxKGL6cmIp5TC8fDYHnd2ZO5MwJuPnOEeiUNVQcUSTD/DxSYl/f6KtOpOLpS+0bm0/0lhkNXTp4u45SHCt3yaO2hvOOpdIAZutt3pq3lbiRfeTj7q+0Qwzt2azQl+r3fSulb75zrNsV0ucc93IGb0Hhlr7qziJ8pB+6WxD3fN9MuSc87hU25qF4uYEXq8ncZAYWE6QidJ4ZGNXOnBeq9QeBfhEBVf4sy/KLtJB1N/KDTXWNoMzJiMYC0CLHmnTuOBkti/qE4QAJm+0eXUxuK4/BzZ0RMtlaeHXN9/RyUygLuNzcs/rS9GKWRwswthKNTf1wsie389e8y414E2MBIwa0708vnH+D9JI3TWEajmbQNd6Y6RVlkHcqrQEjD3ZpGtRw7sGhNhos= 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; SFS:(396003)(39860400002)(346002)(136003)(376002)(46966006)(36840700001)(786003)(70586007)(186003)(956004)(8676002)(8936002)(70206006)(82740400003)(66574015)(6916009)(316002)(7596003)(5660300002)(26005)(356005)(75432002)(82310400003)(336012)(36860700001)(966005)(31696002)(47076005)(53546011)(31686004)(86362001)(77540400001)(478600001)(2616005)(36906005)(83380400001)(2906002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 17:05:14.1032 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 42f07b2b-a848-4f8f-ab7c-08d968b3abe6 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-AuthSource: DM3NAM02FT020.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3332 Archived-At: Subject: [Rum] WGLC for draft-ietf-rum-rue-07 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:05:26 -0000 [Speaking as a RUM WG chair] This message announces the start of WGLC (Working Group Last Call) for draft-ietf-rum-rue-07. The end of this WGLC will be midnight UTC on September 12, 2021. (That is roughly two weeks, rounded up to a week boundary.) The energy level in the wg has been low. This WGLC is to help us move to wrap things up. The comments that have been posted for the last few days will be treated as WGLC comments. If you have made comments recently please review to see if they are impacted by the changes in -07 and if so update your comments. (I don't think any are.) Starting on Monday morning September 13 we will assess where we stand based on WGLC comments. If discussion has been robust but incomplete we MAY further extend the WGLC. Thank you, Paul Kyzivat On 8/26/21 12:09 PM, Brian Rosen wrote: > This version: > Changes jCard to xCard > Says ICE candidates with specific IP versions is allowed > Doesn’t require MWI support if voicemail is not supported (actually, 06 said that). > > I think the document is ready for work group last call. > > Brian > > >> On Aug 26, 2021, at 12:05 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Relay User Machine WG of the IETF. >> >> Title : Interoperability Profile for Relay User Equipment >> Author : Brian Rosen >> Filename : draft-ietf-rum-rue-07.txt >> Pages : 33 >> Date : 2021-08-26 >> >> Abstract: >> Video Relay Service (VRS) is a term used to describe a method by >> which a hearing persons can communicate with deaf/Hard of Hearing >> user using an interpreter ("Communications Assistant") connected via >> a videophone to the deaf/HoH user and an audio telephone call to the >> hearing user. The CA interprets using sign language on the >> videophone link and voice on the telephone link. Often the >> interpreters may be supplied by a company or agency termed a >> "provider" in this document. The provider also provides a video >> service that allows users to connect video devices to their service, >> and subsequently to CAs and other deaf/HoH users. It is desirable >> that the videophones used by the deaf/HoH/H-I user conform to a >> standard so that any device may be used with any provider and that >> video calls direct between deaf/HoH users work. This document >> describes the interface between a videophone and a provider. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-07 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > From nobody Thu Aug 26 10:09:49 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD77F3A14DD for ; Thu, 26 Aug 2021 10:09:47 -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 iij4ihol-y5R for ; Thu, 26 Aug 2021 10:09:39 -0700 (PDT) Received: from mail-il1-x133.google.com (mail-il1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 72F063A14D4 for ; Thu, 26 Aug 2021 10:09:39 -0700 (PDT) Received: by mail-il1-x133.google.com with SMTP id v2so3968289ilg.12 for ; Thu, 26 Aug 2021 10:09:39 -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=Fz44tHTPcQY6IfwuH+7BC/Y+8NQlfmo5MBlA0ZgjsFg=; b=K4eYI43de3zjvTuJF5IgIRA74OjZ6YIPnl7Q2uFMh/6VzE0lbnkXjyUv06wWECyxsW hovitkcfdksl3/FTwm8N6qCHr7yyHyOI5DvFa9gmEYS3jx9yfEXfLAjAd2pwryP5vH0q 9h0d5IaS+7RSMQQ97s0ykdkH4ilgBzzIsvF7Bu2ewe878P/ISeDYMEPb/mGheZTGpLnk t57rXlMFVBgyKMcxeGz+Z+fNoOS/NgQj/3JyqT3d4JJa+LVAKBv2g/T0/LQQZmM9uGYV SEE1ZMQEFnysjweBpqo2I5jfNK0SpPoZET/BxRZiUbRc9bic9lFocadW2576pqOJ6wps MBww== 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=Fz44tHTPcQY6IfwuH+7BC/Y+8NQlfmo5MBlA0ZgjsFg=; b=TZ/E3m9L+WhUAdbivGPKabWHqVwZkPPs3dThajY0ffBECsEYVT5FDZ7rMNXxcO9wdI bfzoe5DmJJqqKSwEGlVs1VAMhVsEUuSl0VIO2Q5/sNsrifddEd38cLefJ5QL1zgOw6xI hfs1og7KtFOu0AQ7NpQGIPc+1Y+CaKTJWNHeGWZTlBRLMygw7gT8znuKwUUZOMMT/iBF qx22Hu8b+sSxEZtJlR/NiB8yB1xcuU5ZFR4grmej6RJyzhIuvYIIscFzbwIjk5JizRgn kF0DwtToMjAti+kzMeom1VRHxy5klfOBFAZAMypR/qfVX/NsC/Z2FoMGgVFYGcdSctK1 LEJA== X-Gm-Message-State: AOAM532rT+vPbAbbGmPUKEqpp7TaIE3pIMahs1G7Fbw8kILAqlh+9rg9 rkmJ6sueWNkUm5PFMed6Tz+Hs6wBTrhnrY1q X-Google-Smtp-Source: ABdhPJyYiqdPe1al7h1qCDVRIi2J7zoMyCxWprPvz5YAbZwgE1hEjQN0kru8IdzpuyxBsbkRerIohA== X-Received: by 2002:a92:3012:: with SMTP id x18mr3438554ile.249.1629997776518; Thu, 26 Aug 2021 10:09:36 -0700 (PDT) Received: from smtpclient.apple ([24.154.121.237]) by smtp.gmail.com with ESMTPSA id s7sm1668116ioc.42.2021.08.26.10.09.35 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 10:09:36 -0700 (PDT) From: Brian Rosen Message-Id: <6DA02965-E156-4C95-AEA1-3A829766219F@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_711310B5-857E-4EC3-B908-70246004E1F4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 13:09:34 -0400 In-Reply-To: Cc: "Olle E. Johansson" , Eugene Christensen , "rum@ietf.org" , Alexander Ospina , Isaac Roach , Paul Kyzivat To: Roger Slusser References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:09:48 -0000 --Apple-Mail=_711310B5-857E-4EC3-B908-70246004E1F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Could we look at this using the easy target: IPv6? All implementations of just about any internet service is going to have = to support IPv6 in the future. We can argue about how far out it is, = but, increasingly, there are IPv6 only networks. IPv4 will be with us = with work arounds for some time, but we have to acknowledge that it=E2=80=99= s not optional any more. Implementation can be delayed, but it can=E2=80=99= t be dismissed. If you are supporting mobile clients, it=E2=80=99s = getting much harder over time to support IPv4 only. There are current = work arounds, but it=E2=80=99s getting harder. =20 When I was asked to start this effort, and venue was discussed, we = understood that whatever venue we did the work would impose some sort = effective constraints on what we did. When we discussed doing it in the = IETF, I was the one that pointed out that we would absolutely encounter = the sorts of things we are discussing now. I think I even mentioned = IPv6 as emblematic of the consequences of doing the work here. We have = to accept that wherever we tried to create a spec like this, the = organizations biases affect the outcome. We=E2=80=99re not going to be = able to get this doc through the IETF without IPv6. When we discussed chartering this effort, the discussion on WebRTC = occurred. The charter says we should do what we ended up doing. That = was because the people who looked at the work proposed pointed out that = we had just finished a rather difficult consensus gathering on what best = practice for real time multimedia over the Internet should be, and no = one wanted to start another discussion on what best practice was. We = decided, with a WHOLE lot of expert advice and opinions, and the people = who drove the charter language wanted to make sure that we used the = prior work as best we could. I think we have done that. I think you = will find that you will want to go the direction we have in this doc. = As an example, everyone else is moving away from video bridges, and = using SFUs. There are substantial advantages to VRS for using SFUs = instead of bridges. Yes, it=E2=80=99s a change, but it=E2=80=99s a = change that is good for users. Our doc doesn=E2=80=99t require either = end to support SFUs, but it gives you the basis for doing it. The same = is true of OPUS. Users who have some hearing ability see large = advantages to wideband codecs and OPUS is free, universal, and high = quality. Brian > On Aug 26, 2021, at 10:17 AM, Roger Slusser = wrote: >=20 > Hello all, > First off these are personal comments and not as a spokesperson for = the VRS provider I work for.=20 >=20 > I have to agree right down the line with Eugene Christensen. I have = been a part of this from day one and have been directly involved in the = setup and execution of the bi-annual Interop conferences and development = of the Provider Interoperability Profile. =20 >=20 > It is obvious to me that this RUM RFC will be picked up by the FCC as = the new spec for the VATRP. So let's not kid ourselves or mince words = about implementations, industry profiles and various services. This = endpoint spec will be terminated by a VRS provider Interpreter station = or proprietary endpoint in 99% of the use cases. By mandating via = "MUSTs" in this RFC, and there are many, it will force the VRS providers = to abandon current project plans and business goals to turn attention to = implementing things in this RFC that have very little value to the Deaf = and HH end users we support. Every provider already has a notification = scheme for message waiting, most of which is much more elaborate and = sophisticated than MWI, yet this RFC will force less desirable = services... why? This is just an example that has been objected to since = day one and yet it still has stuck like glue. Let's not lose focus of = the driving force here, the betterment of the endpoint experience for = the Deaf and HH user base. =20 >=20 > I understand this is IETF. I understand this must have the latest and = greatest tech the industry has to offer, but I think the driving = committee members of this RFC also need to understand the realities of = implementation and the hardship this can and will bring to providers = with the "MUSTs". The FCC denies funding for non compliance, the reality = is these "MUSTs" could put providers out of business. =20 >=20 > I know there are heavy hitters in the IETF community on this project. = But there are also founding members of the VRS industry who have offered = comments with reasonable explanations that have been dismissed. After 18 = year I believe we know our customer base. The Deaf employees in our = companies in marketing and sales collectively drive our product = offerings to best suit their needs because we eat our own dog food.. I = would urge this committee to take long and hard consideration of the = experience that in my opinion is being dismissed offhandedly for the = sake of new tech that has very little to do with our customers needs or = wants. >=20 > Thanks for your consideration, > Roger Slusser=20 >=20 > On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson > wrote: > Friends, > This is the IETF after all.=20 >=20 > We can=E2=80=99t let any documents be published without IPv6. The = problems you outline here are surely solved in existing implementations = of SIP, propably since many years ago. If not, we have work to do. >=20 > In addition, RUM services without SRTP/DTLS will be used over any = network, including the Internet, and it is a very bad solution that = feels like something we sold in the SIP world a long time ago. The world = has moved since then. >=20 > I strongly urge that the RUM specs has to require mandatory IPv6 = support as well as SRTP/DTLS encryption. >=20 > I would personally go as far as to say that SRTP/DTLS is a MUST and = nothing else is ok, very much like WebRTC. >=20 > In regards to proprietary vs open standards, this is again the IETF. = We produce open standards and a RUM specification has to point to a SIP = SUBSCRIBE/NOTIFY package for MWI.=20 >=20 > Remember that what I=E2=80=99m talking about is documents as specified = by the IETF. Industry profiles and various services may go other ways, = but the IETF standards has to be up to date with best current practise. >=20 > Cheers, > /O >=20 > > On 25 Aug 2021, at 20:58, Eugene Christensen = > wrote: > >=20 > > Brian, Paul thank you for considering the changes that have been = brought up to this point. Leaving things alone with the X-Card, the = inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated. > >=20 > > It is my opinion that we should not include requirements for the = following in the new RUM document. Here are the reasons that I believe = this way. > >=20 > > WebRTC > >=20 > > * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it. For example, TMMBR is required for WebRTC = but Chrome does not signal it. > > * WebRTC is an audio first implementation. For VRS, video is the = most important media stream. It means everything to the deaf or hard of = hearing user. If video is suffering first in a lossy network, that is a = problem for VRS. > > * Some of the VRS providers do not currently support the following = items. This could pose a significant impact on the VRS providers to get = this implemented. > > o Encryption (DTLS) > > o ICE > > o RTP/RTCP Muxing > >=20 > > IPv6=20 > > * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6. Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP. This could be a big undertaking just to get = IPv6 into the mix. =20 > > * Another solution could be an IPv4 to IPv6 gateway but that doesn't = work flawlessly. For example, the gateway can forward the IPv6 SIP = message to the proper address on the IPv4 network, however, how does it = resolve the embedded IPv6 addresses signaled in the SDP? So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two. How is the = media going to work? Each of the RUEs is going to provide an IP address = in their SDP, one will be IPv4 and the other IPv6. How is this going to = work without having to anchor all the media somewhere? > > * Are there issues that we need to resolve with NAT64 and/or DNS64? =20= > > * As I understand it, some mobile devices are already IPv6 but do = not follow the RFC for embedding an IPv4 address into an IPv6 address. = This is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard. > >=20 > > Message Waiting Indicator > > * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way. Proprietary methods have been used. The = document states that MWI is optional but if the ability to leave a = message is provided then MWI is to be implemented. Since there are = proprietary solutions, it seems appropriate to me that this should be = changed so that proprietary solutions and indications can continue to be = utilized. > >=20 > >=20 > > I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider. > >=20 > > Regards, > > Eugene Christensen > >=20 > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by = telephone at +1 (801) 287-9419, and destroy the original transmission = and its attachments without reading them or saving them to disk. > >=20 > > -----Original Message----- > > From: Rum > On = Behalf Of Paul Kyzivat > > Sent: Thursday, August 19, 2021 10:04 AM > > To: rum@ietf.org > > Cc: Alexander Ospina >; Isaac Roach >; Brian Rosen > > > Subject: [Rum] Action Items from RUM session at IETF 111 > >=20 > > [EXTERNAL]=20 > >=20 > > The minutes from the RUM session include a number of action items.=20= > > Specifically, the following people made commitments: > >=20 > > Brian Rosen > > Isaac Roach > > Alex Ospina > >=20 > > Brian is working on an updated version, but it won't include the=20 > > concerns of the others above if we don't hear from you. Rather than = try=20 > > to summarize those I refer you back to the minutes. You can find = them at: > > https://datatracker.ietf.org/doc/minutes-111-rum/ = > >=20 > > I plan to issue WGLC on the document soon. I will wait one week = (until=20 > > Aug 26). If there hasn't been any followup by then I will ask Brian = to=20 > > issue a version that we can advance to WGLC. > >=20 > > Thanks, > > Paul > >=20 > > --=20 > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum = > >=20 > > --=20 > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum = >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_711310B5-857E-4EC3-B908-70246004E1F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Could= we look at this using the easy target: IPv6?

All implementations of just about any = internet service is going to have to support IPv6 in the future. =  We can argue about how far out it is, but, increasingly, there are = IPv6 only networks.  IPv4 will be with us with work arounds for = some time, but we have to acknowledge that it=E2=80=99s not optional any = more.  Implementation can be delayed, but it can=E2=80=99t be = dismissed.  If you are supporting mobile clients, it=E2=80=99s = getting much harder over time to support IPv4 only.  There are = current work arounds, but it=E2=80=99s getting harder.  

When I was asked to = start this effort, and venue was discussed, we understood that whatever = venue we did the work would impose some sort effective constraints on = what we did.  When we discussed doing it in the IETF, I was the one = that pointed out that we would absolutely encounter the sorts of things = we are discussing now.  I think I even mentioned IPv6 as emblematic = of the consequences of doing the work here.  We have to accept that = wherever we tried to create a spec like this, the organizations biases = affect the outcome.  We=E2=80=99re not going to be able to get this = doc through the IETF without IPv6.

When we discussed chartering this = effort, the discussion on WebRTC occurred.  The charter says we = should do what we ended up doing.  That was because the people who = looked at the work proposed pointed out that we had just finished a = rather difficult consensus gathering on what best practice for real time = multimedia over the Internet should be, and no one wanted to start = another discussion on what best practice was.  We decided, with a = WHOLE lot of expert advice and opinions, and the people who drove the = charter language wanted to make sure that we used the prior work as best = we could.  I think we have done that.  I think you will find = that you will want to go the direction we have in this doc.  As an = example, everyone else is moving away from video bridges, and using = SFUs.  There are substantial advantages to VRS for using SFUs = instead of bridges.  Yes, it=E2=80=99s a change, but it=E2=80=99s a = change that is good for users.  Our doc doesn=E2=80=99t require = either end to support SFUs, but it gives you the basis for doing it. =  The same is true of OPUS.  Users who have some hearing = ability see large advantages to wideband codecs and OPUS is free, = universal, and high quality.


Brian

On Aug 26, 2021, at 10:17 AM, = Roger Slusser <rslusser1096@gmail.com> wrote:

Hello all,
First off these are personal = comments and not as a spokesperson for the VRS provider I work = for. 

I = have to agree right down the line with Eugene Christensen. I have been a = part of this from day one and have been directly involved in the setup = and execution of the bi-annual Interop conferences and development of = the Provider Interoperability Profile.  

It is obvious to me that = this RUM RFC will be picked up by the FCC as the new spec for the VATRP. = So let's not kid ourselves or mince words about implementations, = industry profiles and various services. This endpoint spec will be = terminated by a VRS provider Interpreter station or proprietary endpoint = in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there = are many, it will force the VRS providers to abandon current project = plans and business goals to turn attention to implementing things = in this RFC that have very little value to the Deaf and HH end users we = support. Every provider already has a notification scheme for message = waiting, most of which is much more elaborate and sophisticated than = MWI, yet this RFC will force less desirable services... why? This = is just an example that has been objected to since day one and yet it = still has stuck like glue. Let's not lose focus of the driving force = here, the betterment of the endpoint experience for the Deaf and HH = user base.  

I understand this is IETF. I understand this must have the = latest and greatest tech the industry has to offer, but I think the = driving committee members of this RFC also need to understand the = realities of implementation and the hardship this can and will bring to = providers with the "MUSTs". The FCC denies funding for non compliance, = the reality is these "MUSTs" could put providers out of = business.  

I know there are heavy hitters in the IETF community on this = project. But there are also founding members of the VRS industry who = have offered comments with reasonable explanations that have been = dismissed. After 18 year I believe we know our customer base. The Deaf = employees in our companies in marketing and sales collectively = drive our product offerings to best suit their needs because we eat = our own dog food.. I would urge this committee to take long and hard = consideration of the experience that in my opinion is being dismissed = offhandedly for the sake of new tech that has very little to do with our = customers needs or wants.

Thanks for your consideration,
Roger = Slusser 

On Thu, Aug 26, 2021 at 7:16 AM Olle E. = Johansson <oej@edvina.net> wrote:
Friends,
This is the IETF after all.

We can=E2=80=99t let any documents be published without IPv6. The = problems you outline here are surely solved in existing implementations = of SIP, propably since many years ago. If not, we have work to do.

In addition, RUM services without SRTP/DTLS will be used over any = network, including the Internet, and it is a very bad solution that = feels like something we sold in the SIP world a long time ago. The world = has moved since then.

I strongly urge that the RUM specs has to require mandatory IPv6 support = as well as SRTP/DTLS encryption.

I would personally go as far as to say that SRTP/DTLS is a MUST and = nothing else is ok, very much like WebRTC.

In regards to proprietary vs open standards, this is again the IETF. We = produce open standards and a RUM specification has to point to a SIP = SUBSCRIBE/NOTIFY package for MWI.

Remember that what I=E2=80=99m talking about is documents as specified = by the IETF. Industry profiles and various services may go other ways, = but the IETF standards has to be up to date with best current = practise.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <echristensen@sorenson.com> wrote:
>
> Brian, Paul thank you for considering the changes that have been = brought up to this point.  Leaving things alone with the X-Card, = the inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated.
= >
> It is my opinion that we should not include requirements for the = following in the new RUM document.  Here are the reasons that I = believe this way.
>
> WebRTC
>
> * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it.  For example, TMMBR is required for = WebRTC but Chrome does not signal it.
> * WebRTC is an audio first implementation.  For VRS, video is = the most important media stream.  It means everything to the deaf = or hard of hearing user.  If video is suffering first in a lossy = network, that is a problem for VRS.
> * Some of the VRS providers do not currently support the following = items.  This could pose a significant impact on the VRS providers = to get this implemented.
> o Encryption (DTLS)
> o ICE
> o RTP/RTCP Muxing
>
> IPv6
> * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6.  Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP.  This could be a big undertaking just to = get IPv6 into the mix. 
> * Another solution could be an IPv4 to IPv6 gateway but that = doesn't work flawlessly.  For example, the gateway can forward the = IPv6 SIP message to the proper address on the IPv4 network, however, how = does it resolve the embedded IPv6 addresses signaled in the SDP?  = So, for example, consider two RUEs, one legacy RUE that is using IPv4 = and one that is IPv6; the signaling is possible for both once the = servers for each support that or provide a IP gateway between the = two.  How is the media going to work?  Each of the RUEs is = going to provide an IP address in their SDP, one will be IPv4 and the = other IPv6.  How is this going to work without having to anchor all = the media somewhere?
> * Are there issues that we need to resolve with NAT64 and/or = DNS64? 
> * As I understand it, some mobile devices are already IPv6 but do = not follow the RFC for embedding an IPv4 address into an IPv6 = address.  This is going to require special handling to get this to = work with such devices on vendors that do not follow the RFC in this = regard.
>
> Message Waiting Indicator
> * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way.  Proprietary methods have been = used.  The document states that MWI is optional but if the ability = to leave a message is provided then MWI is to be implemented.  = Since there are proprietary solutions, it seems appropriate to me that = this should be changed so that proprietary solutions and indications can = continue to be utilized.
>
>
> I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider.
>
> Regards,
> Eugene Christensen
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any = documents, files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) = 287-9419, and destroy the original transmission and its attachments = without reading them or saving them to disk.
>
> -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of = Paul Kyzivat
> Sent: Thursday, August 19, 2021 10:04 AM
> To: rum@ietf.org
> Cc: Alexander Ospina <aospina@aslservices.com>; Isaac = Roach <IRoach@sorenson.com>; Brian Rosen <br@brianrosen.net>
> Subject: [Rum] Action Items from RUM session at IETF 111
>
> [EXTERNAL]
>
> The minutes from the RUM session include a number of action items. =
> Specifically, the following people made commitments:
>
> Brian Rosen
> Isaac Roach
> Alex Ospina
>
> Brian is working on an updated version, but it won't include the =
> concerns of the others above if we don't hear from you. Rather than = try
> to summarize those I refer you back to the minutes. You can find = them at:
> https://datatracker.ietf.org/doc/minutes-111-rum/
>
> I plan to issue WGLC on the document soon. I will wait one week = (until
> Aug 26). If there hasn't been any followup by then I will ask Brian = to
> issue a version that we can advance to WGLC.
>
>       Thanks,
>       Paul
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_711310B5-857E-4EC3-B908-70246004E1F4-- From nobody Thu Aug 26 10:11:20 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27C2C3A14EF for ; Thu, 26 Aug 2021 10:11:18 -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 h4-Uvp1HnULZ for ; Thu, 26 Aug 2021 10:11:13 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 156E83A14ED for ; Thu, 26 Aug 2021 10:11:13 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id b4so3989741ilr.11 for ; Thu, 26 Aug 2021 10:11:13 -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=CKsW09EubXAUYxe5oRlD+ObiXpRMHXlgIsvchyUUSRc=; b=yikCCt0VOsZWX5xI8kykOBlAuhckhDHpEmWQzdrclsDXlZm/qjHuRzT4rcHdOeuHgz jwQtQEorNxm3Juz2yGakcjXKBlXDQtVYtbym4At5Oo2xqqY+zwVEEbglAxZEJiL9p34K lNjcG3AyULkeDbEIQg59+7KHammogqyzhB+XwCyNcs6DLajemVihF5OSWhiL0+KYeo7C ltzsUR8fXIM4m/scy/USPiuYLgnOyjwQuf0h9oNOeTAPZvE7lnK0WlR9m93Mzqzqhm6w onLpAG9WZrpXqI+4Y4ba6E4F0oRHAMrfnC6LD//YyDuIUA7CPBCFnAqfdQwzifbXoyIp MYFg== 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=CKsW09EubXAUYxe5oRlD+ObiXpRMHXlgIsvchyUUSRc=; b=U+s73FIcZeSOlwCrluvSMgS9/Cq0VA/5d1I2nyapBrCxnrQhtH6kz+B5clpsyjuLM/ YtIMlRnpbV0ZokXj9S4BVc5tz6HQAtg0NrFlS+qZfTfzj8hBr0lQBtyRfEVvUcP1r+mh dmUlBh6EaMg5kj5CM7uXzSVzH2P8yzfL4Yvh2oOe1hwnUy7R50Bvor/TD03tU/f24i/w 6WG+Iw/qyPuFzNZGaE5SLVlnf/dgzapqARIey0rWsLv/a8lw2c50pLCGE6miqGRLzjIc fwgIwURFC5ElVVa9Nt1y3oDv41BTXJpUF+Q6l34Tt5nVel1h+nGWNa01srOfyL1CoI3+ mOrw== X-Gm-Message-State: AOAM532zZL2ptPyhxC49wNdEuIjpse0VHMuvJaEz9ojq5Y3V8pYk6C5N OkXI89PZlLqTRK+rZECMpuiRF/U6i7bkEVx3 X-Google-Smtp-Source: ABdhPJypP3PzEs4Dko04CNSgwivhjQT9I03OK5r71Yew4BLsNOr3CQslgirllhvBoMf3eW5WADpQ7A== X-Received: by 2002:a92:2002:: with SMTP id j2mr3356748ile.37.1629997868769; Thu, 26 Aug 2021 10:11:08 -0700 (PDT) Received: from smtpclient.apple ([24.154.121.237]) by smtp.gmail.com with ESMTPSA id v5sm2011543iln.42.2021.08.26.10.11.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 10:11:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <4b6b9930-d582-f1ef-09f4-9ec5bd29d53d@alum.mit.edu> Date: Thu, 26 Aug 2021 13:11:06 -0400 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <6D4C2615-4375-4228-812D-38FE0ACEBC41@brianrosen.net> References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> <4b6b9930-d582-f1ef-09f4-9ec5bd29d53d@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] WGLC for draft-ietf-rum-rue-07 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:11:19 -0000 It would be very helpful for anyone commenting during WGLC to state = where and why they are on the 3 issues raised (IPv6, MWI and RTCweb = media). Brian > On Aug 26, 2021, at 1:05 PM, Paul Kyzivat = wrote: >=20 > [Speaking as a RUM WG chair] >=20 > This message announces the start of WGLC (Working Group Last Call) for = draft-ietf-rum-rue-07. >=20 > The end of this WGLC will be midnight UTC on September 12, 2021. > (That is roughly two weeks, rounded up to a week boundary.) >=20 > The energy level in the wg has been low. This WGLC is to help us move = to wrap things up. The comments that have been posted for the last few = days will be treated as WGLC comments. If you have made comments = recently please review to see if they are impacted by the changes in -07 = and if so update your comments. (I don't think any are.) >=20 > Starting on Monday morning September 13 we will assess where we stand = based on WGLC comments. If discussion has been robust but incomplete we = MAY further extend the WGLC. >=20 > Thank you, > Paul Kyzivat >=20 > On 8/26/21 12:09 PM, Brian Rosen wrote: >> This version: >> Changes jCard to xCard >> Says ICE candidates with specific IP versions is allowed >> Doesn=E2=80=99t require MWI support if voicemail is not supported = (actually, 06 said that). >> I think the document is ready for work group last call. >> Brian >>> On Aug 26, 2021, at 12:05 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Relay User Machine WG of the IETF. >>>=20 >>> Title : Interoperability Profile for Relay User = Equipment >>> Author : Brian Rosen >>> Filename : draft-ietf-rum-rue-07.txt >>> Pages : 33 >>> Date : 2021-08-26 >>>=20 >>> Abstract: >>> Video Relay Service (VRS) is a term used to describe a method by >>> which a hearing persons can communicate with deaf/Hard of Hearing >>> user using an interpreter ("Communications Assistant") connected = via >>> a videophone to the deaf/HoH user and an audio telephone call to = the >>> hearing user. The CA interprets using sign language on the >>> videophone link and voice on the telephone link. Often the >>> interpreters may be supplied by a company or agency termed a >>> "provider" in this document. The provider also provides a video >>> service that allows users to connect video devices to their = service, >>> and subsequently to CAs and other deaf/HoH users. It is desirable >>> that the videophones used by the deaf/HoH/H-I user conform to a >>> standard so that any device may be used with any provider and that >>> video calls direct between deaf/HoH users work. This document >>> describes the interface between a videophone and a provider. >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >>>=20 >>> There is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-07 >>>=20 >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>>=20 >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 26 10:15:30 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74623A156A for ; Thu, 26 Aug 2021 10:15:29 -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, 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=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s46XCNRHRyun for ; Thu, 26 Aug 2021 10:15:23 -0700 (PDT) Received: from stmail1.purple.us (stmail1.purple.us [54.177.253.121]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEA953A1563 for ; Thu, 26 Aug 2021 10:15:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail1.purple.us (Postfix) with ESMTP id E91C419261E; Thu, 26 Aug 2021 12:15:35 -0500 (CDT) Authentication-Results: stmail1.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=TWZMmuNF header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail1.purple.us (Postfix) with ESMTPS id 7B929192607; Thu, 26 Aug 2021 12:15:35 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b9kxuLJ4fjIY7MN1pYiyAvFqNKaPeQg90+9k3Z4rT0moiWeYB69RBwuGOzC5qlyjhznVJyxpavHZspuHSY1CygMjLaXwQsBhRLHn3fQ1cbz+Gf2LUZxpevAZK73Iql0c75kgAxaqgDwvpmFnl5DmTN5mc9OfzVWfHP8xcGLN4a7PAFlfI6rXcj0trORZ8d1hZha6OHWx9EH4HeZyWIq73yojTLmvxC2X3X/I2Br/hUD6WE59ArDKEXpn+ng7gatnLr9BzYPrfD474RaC8TbijOlg+nHGKhkEAlc9Hscvfxs68WmzJFZDsBkxp1d9WauxVnQ92ZvBcGpxhr7Boio9jQ== 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=gfIyCxTpbkVIljDXFt2zxGUKhLQxIAoODe1aoiF7PqE=; b=Kn9vEJQaHuLyVWmVX5qu63avsrBwFMIy6cAPKICQoGpYbPeQ87+W9QdDRTOWNnohNueUoTMIYa3cP/Mv26kuH91sGAaPuN69OiA7yN7L/Osc+NXYf7WE2xfweTT5tX/8wR+7ZfG0GOWzZF1DR5AtWRM4GYGOiuMa8doFnS80aNxo1vWdcJgI7uGt8ZdCS+V5hQviXibaOF8EWqR7AV9GdshN1MH3eNv/pDWJMtlYQ0y0GAJ7OCo1PaWiSU0CC9lSiftuqiosa4gzCls3b21OKArbHMEn7Gl/p26r9a5zLJMnp8QM2MVxOEUF28tHYePQ3ydxll31NrCdM5n5rXMzKg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gfIyCxTpbkVIljDXFt2zxGUKhLQxIAoODe1aoiF7PqE=; b=TWZMmuNFz4yZVUff+X7wGElfzV7pzSj00GvbLMHY0LfdUWRmWlJgvfq1Gvovgo+tXLX9CGIZL7CAwU8XKZ5AeWV+T+2yJHakCmw9AYVdPQ3CYjZAS9xh3LttWAYI045FZMS6oiL9ZobSYj3vdLNBlZRLAXq95xAjkx85a1/3/bI= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM5PR1901MB2165.namprd19.prod.outlook.com (2603:10b6:4:a5::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.23; Thu, 26 Aug 2021 17:15:19 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4436.024; Thu, 26 Aug 2021 17:15:19 +0000 From: Ed Sayers To: Paul Kyzivat , Eugene Christensen , "rum@ietf.org" , Brian Rosen CC: Isaac Roach , Alexander Ospina Thread-Topic: [Rum] VRS Provider issues - MWI Thread-Index: AQHXmpHMjrK4SgewrUasBQeso54V1quF76zA Date: Thu, 26 Aug 2021 17:15:18 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> In-Reply-To: <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> Accept-Language: en-GB, 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=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 181a2e56-0a09-4ce0-a8cf-08d968b5146d x-ms-traffictypediagnostic: DM5PR1901MB2165: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: H2+oOf5FHzHjuvOYPY66r0TzgqvqFh7/kW80MidSJ6uWO7mUvxWHKKBf2zBjAnYEt/pgzvaZGvrKJCUrIk5jSABhXV507HpJnfgTsDV6Za7DPp218VPqJF3oUF8zA9fTqaO0s4krlVNWqNKkoyJyRiDFpgNe2NnyTFOC6dL7D6aeTrOVM9p5ztgdjqYjngIcYL4h3vN5xFuI6/4lFHwCtHSZkzWoO+gfeRpRLL088OaQqshGgmeZdtAB04/d9wAWrmqf/lKjGR2hX8x4Vo7clRa8S2vO8VX/t0YgWWcM8GrokDy2Mz3ZyJZ3FZkefpCdUYy1BYNTgmX2ypxVmSJekuRg6xvNPQU0orLm3UDRAJDGtapURJAvpggRfajHwLDid2D6Z6/0Wc549wkJCFgHdKk1DjZ589IAhG12ubtBvMZeThSdHrea13sFRH2tNur4oSAvKSSqNz8E1DYyfs8DVONLkA77LRB2G3skcHoZi7NRRRRBt2DSqsUi2inmabFTGWWoWeCgIWc0NOLyThmWivG4cx8UNlgRd3c0Ex47SLxYwk3LLMqez8WmTBOxxa43Xuuqw0jOdCYFGPKzfUQugFDWhpUd2Oubf/B2dKltWuSb3MgqZnhmMIhHy29xGEKpXzwknbpzc9vhdPTSq0hWLAOOIVFOHrkBeGW1QX4Fxfo1S1lpA7ImP/vhIa0+e9RX4itx7g8Uulyk6YXcMIc7grwZLT7nkG090gsXNvkqLIcGpaN7K9N3t5nU6kxf3HzC50b9JBjruFgtFUewYvjF5vsW00zeRfnMfE4rpJoxzzOgepMBgmMPZ1B0DbFUsiBM x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(7696005)(38100700002)(33656002)(5660300002)(8676002)(966005)(508600001)(8936002)(122000001)(186003)(26005)(4326008)(52536014)(38070700005)(2906002)(76116006)(316002)(44832011)(55236004)(66556008)(54906003)(83380400001)(66476007)(6506007)(66446008)(55016002)(86362001)(9686003)(53546011)(71200400001)(18074004)(110136005)(66946007)(64756008)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5S7XyFbFXGU6Ti80jRyd86Lx52xCQR1LjRrWh+y3J+n91PHcBDqXwiSYNzl1?= =?us-ascii?Q?HlTrB4YA2qtn6FAP5mwnwatYiXVz4+h+qzE+va7Ik3NWJ0XZ7P1wHlS2I9N5?= =?us-ascii?Q?bft9gFM2Kyqnr1bJV1tzoJ19e7e52QpBjIeAyndVa84Bw5o1t446L567qnoH?= =?us-ascii?Q?f8scYBwqstCxqHo2+Om53s6p3mzslv75D9yCZXnJtAPEx1FOYjCu95nKiHYY?= =?us-ascii?Q?ozqk5iea4emPH9Lefmi7Qvo2cXC7N9hUCma/hdpb57uw4d765g7DB/qvm4tD?= =?us-ascii?Q?IRSRpVxgGFex4nYl4kU4fKtbXhdgTrVTTQTdyBbQNryVnI1lE00rJ20cJhxa?= =?us-ascii?Q?xHfGpdfsf4yLCsCF15FRb4d7SLgOPPgqUjmS9xc/W2zTn238PBin4EHnBZuN?= =?us-ascii?Q?Eau0eYhBYJMuuPrGI7hW/qpFECvQCL6kxSeq5U3i9GIqLTSZjXLF57xfeGDO?= =?us-ascii?Q?EI05bRv/joDmz1N2fJAtY+YPYruuMM1G94uPI2hriy7yEEFhWWmxmbDkiy3m?= =?us-ascii?Q?MhKkY1DyY5awMaNRTmMJEytsJPzjByJK67WX99Y3I+SOjoqXsR/Y7qmbQnL4?= =?us-ascii?Q?qeU98Rh3RtIWBPMZSWeTEcLWBfjQPAR60N5fgVY/9wrnwPRTYs7yO85nUAdt?= =?us-ascii?Q?VNh8nhnDBfprcqBYCyimiAOd7DslGl2ljSnnqvoPZqiY8OOwJy6dsAr1Dttv?= =?us-ascii?Q?Dwj1CkdXn652b2OuxyQ5YYT4JehB1patIUt35IGisGIRAWePajt9TTSC9zr9?= =?us-ascii?Q?OtxP/neztqbmV+jRHdgCGYcD8jr0zFYxiAe+zC3XhpschjYInh87PhPRBsUz?= =?us-ascii?Q?ueAt3w+yITdySUU9bD45oMA4NvikDplYSqVIcToIfLpMHw+13QCIIaM5tIqn?= =?us-ascii?Q?jtsLro1WLi25JSHH0riVHw4ukJeUy5dTkrUP5upLmK7y4eV4GrjVRwcyQmlf?= =?us-ascii?Q?+6UKcWPK9skxJd7f1W6TAVFaADVBjUXjAQwzNCPN4pw312CMuyLgHGfDQtac?= =?us-ascii?Q?77YopgkkFNPp1MRO1dw1rO6YsBNHtA23n2Wxglc1um66PbF+W57hIfV6r2EI?= =?us-ascii?Q?g7IZqD4AtcjEkuh/e0plpLDGSNgJf+bI47cuYInGPoO3odAJ26hLkXeZXV74?= =?us-ascii?Q?F2YsyJU2m0r8kQ1ctaerhFfatlaPNvj9l9WGPc2igW1N1b0oNKRS5njXsUey?= =?us-ascii?Q?gjt/K8Rk7+nFpoKhCeeRMaxyYm7S7nhbNtsUlvSiJFAkgaaagSPeX51nrURG?= =?us-ascii?Q?uWXJ8ljS3i4qnW8Q5OKK/UnHrZER+XTFBlLjmis+y4g4qIaFVuKVm/pkdUmt?= =?us-ascii?Q?Qbl7RtAKrvtSIODA6HwDo8lW?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 181a2e56-0a09-4ce0-a8cf-08d968b5146d X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 17:15:18.8993 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ky+5ArC2j7GfOxLeXDSaCK8UBKX8rsVuJVMOKEx/zQz95CiE/5n43iGK3W/eadbjxyD40710vO9F44TRVUPp7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1901MB2165 Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:15:30 -0000 Hi Paul, The issue of MWI is far more the just mechanism of notifying the user. Whet= her that be push, email, SMS or anything else Provider can already support. In addition, VRS Providers each solved the SIP PUSH problem 10+ years ago -= long before the RFC was created - Following the needs of our customers an= d because RFCs like RFC8599 didn't exist, or because RFC-3482 was insuffici= ent and there were no other adequate alternatives. Providers also currently use their own RESTful APIs to stream and/or downlo= ad Video messages to the client for playback. This cannot be supported by RFC-3482. Even if it were possible using the RF= C-2822 message headers, section 3.5 states "Message headers MUST NOT be inc= luded in an initial NOTIFY, as new messages could be essentially unbounded = in size". This means that MWI cannot provide streaming URIs for any old or = initial new messages, and leaves a historical 'dial-up' mechanism as the on= ly complete option when using this RFC. Providers would thus need to go and re-implement that "old tech" that was t= hrown away years ago and provides a much poorer user experience; A call to = a Video IVR, to be navigated by DTMF tones. If nothing else, this requires = a customer to be online every single time they want to view a message (And = potentially incur data charges every time). Whereas any streamed message co= uld be cached and still be viewed when offline. We completely understand that there is no RFC that can currently support th= e way we provider video mail notifications and messages. We knew that a lon= g time ago. However, it needs to be made clear that this is a deficiency of the current= ly available RFCs, not one that VRS Providers are currently constrained by. However, the creation of the RUM specification will constrain the way that = Providers can provide features such as this, stifle innovation, and in case= s such as this certainly be a limiting and retrograde step. Many thanks, Ed Sayers Endpoint SDK Team Lead Purple, a Division of ZP Better Together, LLC purplevrs.com The information contained in this e-mail message is intended only for the p= ersonal and confidential use of the recipient(s) named above. If you have r= eceived this communication in error, please notify us immediately by e-mail= , and delete the original message. -----Original Message----- From: Rum On Behalf Of Paul Kyzivat Sent: 26 August 2021 16:48 To: Eugene Christensen ; rum@ietf.org; Brian Ros= en Cc: Isaac Roach ; Alexander Ospina Subject: [Rum] VRS Provider issues - MWI I want to split off MWI as different from the other issues you have raised.= If I understand, your point is that each provider has a proprietary way of= indicating video mail is waiting and retrieving it, so there is no need to= do something different. (Please correct me if I have gotten this wrong.) The problem with this is that it means for a RUE to be able to access video= mail it needs to support the proprietary mechanism of each provider it aim= s to work with. But interoperability of the RUE with multiple providers is = an explicit goal of this work group. So we need a mechanism that the RUE ca= n implement that will work with any provider. In principle this mechanism need not use the MWI mechanism, but coming up w= ith some other, presumably purpose built, mechanism will be a hard sell. IMO proposals that fail to address this need for interoperability are out o= f scope. (To go there would require a change to the charter.) So, please frame video mail and MWI issues with interoperability as a requi= rement. Thanks, Paul (With my RUM WG Chair hat ON) On 8/25/21 2:58 PM, Eugene Christensen wrote: > Brian, Paul thank you for considering the changes that haved been brought= up to this point. Leaving things alone with the X-Card, the inclusion of = the instance-id for location, additions to support notification services fo= r mobile, etc. are all appreciated. > =20 > It is my opinion that we should not include requirements for the followin= g in the new RUM document. Here are the reasons that I believe this way. > =20 > WebRTC > =20 > * While there is an RFC for WebRTC, it doesn't appear that all browsers a= re following it. For example, TMMBR is required for WebRTC but Chrome does= not signal it. > * WebRTC is an audio first implementation. For VRS, video is the most im= portant media stream. It means everything to the deaf or hard of hearing u= ser. If video is suffering first in a lossy network, that is a problem for= VRS. > * Some of the VRS providers do not currently support the following items.= This could pose a significant impact on the VRS providers to get this imp= lemented. > o Encryption (DTLS) > o ICE > o RTP/RTCP Muxing > =20 > IPv6 > * For those VRS providers whose current implementations do not support IP= v6, this can be a big jump to get their solution to support both IPv4 as we= ll as IPv6. Granted, it does not require being dual stacked but rather cou= ld be two separate servers, each supporting their respective version of IP.= This could be a big undertaking just to get IPv6 into the mix. > * Another solution could be an IPv4 to IPv6 gateway but that doesn't work= flawlessly. For example, the gateway can forward the IPv6 SIP message to = the proper address on the IPv4 network, however, how does it resolve the em= bedded IPv6 addresses signaled in the SDP? So, for example, consider two R= UEs, one legacy RUE that is using IPv4 and one that is IPv6; the signaling = is possible for both once the servers for each support that or provide a IP= gateway between the two. How is the media going to work? Each of the RUE= s is going to provide an IP address in their SDP, one will be IPv4 and the = other IPv6. How is this going to work without having to anchor all the med= ia somewhere? > * Are there issues that we need to resolve with NAT64 and/or DNS64? > * As I understand it, some mobile devices are already IPv6 but do not fol= low the RFC for embedding an IPv4 address into an IPv6 address. This is go= ing to require special handling to get this to work with such devices on ve= ndors that do not follow the RFC in this regard. > =20 > Message Waiting Indicator > * Some, if not all, of the current implementations of RUE by VRS provider= s, already include means to record video messages and are not all created t= he same way. Proprietary methods have been used. The document states that= MWI is optional but if the ability to leave a message is provided then MWI= is to be implemented. Since there are proprietary solutions, it seems app= ropriate to me that this should be changed so that proprietary solutions an= d indications can continue to be utilized. > =20 > =20 > I don't believe I have enumerated all the reasons for not including requi= rements for the above but I believe the examples given are sufficient to co= nsider. >=20 > Regards, > Eugene Christensen >=20 > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, file= s or previous e-mail messages attached to it, may contain confidential and = proprietary information. If you are not the intended recipient, or a person= responsible for delivering it to the intended recipient, you are hereby no= tified that any disclosure, copying, distribution or use of any of the info= rmation contained in or attached to this message is STRICTLY PROHIBITED. If= you have received this transmission in error, please immediately notify me= by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 2= 87-9419, and destroy the original transmission and its attachments without = reading them or saving them to disk. >=20 > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: Thursday, August 19, 2021 10:04 AM > To: rum@ietf.org > Cc: Alexander Ospina ; Isaac Roach=20 > ; Brian Rosen > Subject: [Rum] Action Items from RUM session at IETF 111 >=20 > [EXTERNAL] >=20 > The minutes from the RUM session include a number of action items. > Specifically, the following people made commitments: >=20 > Brian Rosen > Isaac Roach > Alex Ospina >=20 > Brian is working on an updated version, but it won't include the=20 > concerns of the others above if we don't hear from you. Rather than=20 > try to summarize those I refer you back to the minutes. You can find them= at: > https://datatracker.ietf.org/doc/minutes-111-rum/ >=20 > I plan to issue WGLC on the document soon. I will wait one week (until=20 > Aug 26). If there hasn't been any followup by then I will ask Brian to=20 > issue a version that we can advance to WGLC. >=20 > Thanks, > Paul >=20 -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 26 10:20:10 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F3683A1575 for ; Thu, 26 Aug 2021 10:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, 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=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 a86cuL8adpdk for ; Thu, 26 Aug 2021 10:20:02 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2045.outbound.protection.outlook.com [40.107.93.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 10B913A158C for ; Thu, 26 Aug 2021 10:20:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Y/8OO3Z4ZgU5Ntg9dAuw3OTwqjpbNyiDBOlK20JDxZR5oFDU2H3rgvPN0FfLVMm1HYy0R6mtd/YU/6Wl/tTUWeEdRGblv7tHbv6zYZRyDUE9xiXtj1CLYHyUNPB8xIU2DlrFaDG7QoGfElTXMm3lNm1HfkpDJ3boNTpwWGJBbrhopNYk9FuPTZFAT5SkU8Ah0tvDlE/0+WyDsIzl1T4TirCqnK0o5zVi+LrZEnETHqHDLRTm39XEfkXkEuy6CFZDcFsnfzPwOu2sopbh26VMbsJcRrOnY/gMRYfQFSEL8D94EjzimmC37HWjRKpSlvfl/Zw8/qba9W8DTA6pUOc7yw== 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=9b9dvBbVolO5HZsFAA0iop2a4rI5aszzHf13bNQ4qhw=; b=LM+cXsx2cAhJUesvoZid/3NklLHj/HgzIg9CvxGj6gegGIasEovLavs5Ez1CoSzXeJuIV1S5KNEghTVzE3fG6rEhL5m8y0nMS56XGIW7wg1o4+0CDV2/AtV18HG9McBEM38m6kE6h6P5Sm5nqJ9flthU05j34QRImr/FG+DMy3bhKlFiDlXnDEEb8O0uL96dNzeIA5e9q9UcpfptWgu3A0aeUjtRwHQYuXwIlrhKNeJDnP7RaXMQYpVdL0wzNT3U7JY7HfWfwHaDAy62raIEKvfdbSD5puN7OS/RM4PefjyXCd6VAD6wKfiHQz+YuXVv2MyMhH3SP6vXb7Eojm7/WA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=9b9dvBbVolO5HZsFAA0iop2a4rI5aszzHf13bNQ4qhw=; b=brOU97EHpVKTzNlWml886MfGaSdJfrm20TFENt/sJ/7wUak7rAsbTYWLxT9I4G04s4OE6exJsH85vxhFkpGn8wuxQqhPE3MKAeSKCaBPmGgaUJC40slXl1i4F4yZSvsdMaud+4i0a5qM1Y0INQOsO57vcKnVrc+nC45Wi6kIvdw= Received: from BN8PR15CA0007.namprd15.prod.outlook.com (2603:10b6:408:c0::20) by CY4PR12MB1399.namprd12.prod.outlook.com (2603:10b6:903:38::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 17:19:59 +0000 Received: from BN1NAM02FT061.eop-nam02.prod.protection.outlook.com (2603:10b6:408:c0:cafe::1) by BN8PR15CA0007.outlook.office365.com (2603:10b6:408:c0::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 17:19:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT061.mail.protection.outlook.com (10.13.3.184) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 17:19:59 +0000 Received: from MacBook-Air.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 17QHJvOq013592 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 26 Aug 2021 13:19:58 -0400 References: <6DA02965-E156-4C95-AEA1-3A829766219F@brianrosen.net> To: "rum@ietf.org" From: Paul Kyzivat X-Forwarded-Message-Id: <6DA02965-E156-4C95-AEA1-3A829766219F@brianrosen.net> Message-ID: <0c62fd4d-431f-b9c9-bfe8-92ad91de2ff1@alum.mit.edu> Date: Thu, 26 Aug 2021 13:19:57 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <6DA02965-E156-4C95-AEA1-3A829766219F@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: fef9567b-d8a1-40ec-505e-08d968b5bb7f X-MS-TrafficTypeDiagnostic: CY4PR12MB1399: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iVbYjKS37b9V4EgzLq014YSUR/NzKw8zCfPC+jgfMnylQhCYVx9fYtJ4rVttCVmr+TyNq0RpynIba4NLPmGMe8KpLJJAeszoF+E7cbaXqIlXfNfozrmV0CmVyetvy5DSrgRKCRyKZ+TXta2M59IfvKSZ0GNoXTZ1uTwEv3ev9YZqREXEsxilHkgdiTukJompdy51avh2VVEIWtx5ClHF4jjljC4A50IKg+Z8lJLkqXniGwg1IkcjgOzejj6krsVW5//NRR9sEO+ZR+hDnC/fpmHfx0HGuD/+E7aAgmOjMv1yoZnhWmbUenj0X+3WgSy+3rAh/JUwhLSzH8aWhXVqDEiTT+dcZZTQAo55lz5udSsMlBalFCxNKzewxSEnHY/IwRsS3KAfjHG5TRDgeNvbspTpiX4tUMT3jv5xGHDgOYHRzXuEJiNcU7ZAgIQPCH979Tgb8dgZcgS4377SePkjLH9l1vTC16f20Nt2NYNpQzMhbfwf2P8eFiUdcQHBFrQ/cqpqbdmIgAixbRqVLHEbgRnENGz+j3A+InJVCyXJR2w+n/oL9uQQoXuTGcnX3Iyh6awF2BRmFhCZA6ClsY4h0O6XhdI9jnPdQlSoH6JAGYXCDXaYztrkRd1XlEMuXY/pm3/s+hWb2RCQWgVsOcysDWlAjMYdXm8fopw1tm9UOtk2XbR7eTTI3gaVHqPeX0PeDRrBqd1TnS9oxuwXbcrLy7DAwWEqJv6ql4hFbThfflucK0C9FMEdqU2IApfifengeql1cl6OOP579mKKe8gupHuVWys4Co/w/fdfZL/P7AF2FPOHlqlxjgyccwYCxkb0 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; SFS:(376002)(346002)(136003)(39860400002)(396003)(36840700001)(46966006)(8936002)(86362001)(31686004)(7116003)(7596003)(316002)(30864003)(47076005)(8676002)(2906002)(82310400003)(31696002)(356005)(83380400001)(2616005)(66574015)(186003)(956004)(82740400003)(70586007)(70206006)(36906005)(5660300002)(336012)(75432002)(786003)(6916009)(966005)(478600001)(26005)(36860700001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 17:19:59.2378 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fef9567b-d8a1-40ec-505e-08d968b5bb7f 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-AuthSource: BN1NAM02FT061.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR12MB1399 Archived-At: Subject: [Rum] IPv6 discussion X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:20:10 -0000 Changing the subject to ease following the discussion. -------- Forwarded Message -------- Subject: Re: [Rum] Action Items from RUM session at IETF 111 Resent-From: pkyzivat@alum.mit.edu Date: Thu, 26 Aug 2021 13:09:34 -0400 From: Brian Rosen To: Roger Slusser CC: Olle E. Johansson , Eugene Christensen , rum@ietf.org , Alexander Ospina , Isaac Roach , Paul Kyzivat Could we look at this using the easy target: IPv6? All implementations of just about any internet service is going to have to support IPv6 in the future.  We can argue about how far out it is, but, increasingly, there are IPv6 only networks.  IPv4 will be with us with work arounds for some time, but we have to acknowledge that it’s not optional any more.  Implementation can be delayed, but it can’t be dismissed.  If you are supporting mobile clients, it’s getting much harder over time to support IPv4 only.  There are current work arounds, but it’s getting harder. When I was asked to start this effort, and venue was discussed, we understood that whatever venue we did the work would impose some sort effective constraints on what we did.  When we discussed doing it in the IETF, I was the one that pointed out that we would absolutely encounter the sorts of things we are discussing now.  I think I even mentioned IPv6 as emblematic of the consequences of doing the work here.  We have to accept that wherever we tried to create a spec like this, the organizations biases affect the outcome.  We’re not going to be able to get this doc through the IETF without IPv6. When we discussed chartering this effort, the discussion on WebRTC occurred.  The charter says we should do what we ended up doing.  That was because the people who looked at the work proposed pointed out that we had just finished a rather difficult consensus gathering on what best practice for real time multimedia over the Internet should be, and no one wanted to start another discussion on what best practice was.  We decided, with a WHOLE lot of expert advice and opinions, and the people who drove the charter language wanted to make sure that we used the prior work as best we could.  I think we have done that.  I think you will find that you will want to go the direction we have in this doc.  As an example, everyone else is moving away from video bridges, and using SFUs.  There are substantial advantages to VRS for using SFUs instead of bridges.  Yes, it’s a change, but it’s a change that is good for users.  Our doc doesn’t require either end to support SFUs, but it gives you the basis for doing it.  The same is true of OPUS.  Users who have some hearing ability see large advantages to wideband codecs and OPUS is free, universal, and high quality. Brian > On Aug 26, 2021, at 10:17 AM, Roger Slusser > wrote: > > Hello all, > First off these are personal comments and not as a spokesperson for > the VRS provider I work for. > > I have to agree right down the line with Eugene Christensen. I have > been a part of this from day one and have been directly involved in > the setup and execution of the bi-annual Interop conferences and > development of the Provider Interoperability Profile. > > It is obvious to me that this RUM RFC will be picked up by the FCC as > the new spec for the VATRP. So let's not kid ourselves or mince words > about implementations, industry profiles and various services. This > endpoint spec will be terminated by a VRS provider Interpreter station > or proprietary endpoint in 99% of the use cases. By mandating via > "MUSTs" in this RFC, and there are many, it will force the VRS > providers to abandon current project plans and business goals to turn > attention to implementing things in this RFC that have very little > value to the Deaf and HH end users we support. Every provider already > has a notification scheme for message waiting, most of which is much > more elaborate and sophisticated than MWI, yet this RFC will > force less desirable services... why? This is just an example that has > been objected to since day one and yet it still has stuck like glue. > Let's not lose focus of the driving force here, the betterment of the > endpoint experience for the Deaf and HH user base. > > I understand this is IETF. I understand this must have the latest and > greatest tech the industry has to offer, but I think the driving > committee members of this RFC also need to understand the realities of > implementation and the hardship this can and will bring to providers > with the "MUSTs". The FCC denies funding for non compliance, the > reality is these "MUSTs" could put providers out of business. > > I know there are heavy hitters in the IETF community on this project. > But there are also founding members of the VRS industry who have > offered comments with reasonable explanations that have been > dismissed. After 18 year I believe we know our customer base. The Deaf > employees in our companies in marketing and sales collectively > drive our product offerings to best suit their needs because we eat > our own dog food.. I would urge this committee to take long and hard > consideration of the experience that in my opinion is being dismissed > offhandedly for the sake of new tech that has very little to do with > our customers needs or wants. > > Thanks for your consideration, > Roger Slusser > > On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson > wrote: > > Friends, > This is the IETF after all. > > We can’t let any documents be published without IPv6. The problems > you outline here are surely solved in existing implementations of > SIP, propably since many years ago. If not, we have work to do. > > In addition, RUM services without SRTP/DTLS will be used over any > network, including the Internet, and it is a very bad solution > that feels like something we sold in the SIP world a long time > ago. The world has moved since then. > > I strongly urge that the RUM specs has to require mandatory IPv6 > support as well as SRTP/DTLS encryption. > > I would personally go as far as to say that SRTP/DTLS is a MUST > and nothing else is ok, very much like WebRTC. > > In regards to proprietary vs open standards, this is again the > IETF. We produce open standards and a RUM specification has to > point to a SIP SUBSCRIBE/NOTIFY package for MWI. > > Remember that what I’m talking about is documents as specified by > the IETF. Industry profiles and various services may go other > ways, but the IETF standards has to be up to date with best > current practise. > > Cheers, > /O > > > On 25 Aug 2021, at 20:58, Eugene Christensen > > wrote: > > > > Brian, Paul thank you for considering the changes that have been > brought up to this point.  Leaving things alone with the X-Card, > the inclusion of the instance-id for location, additions to > support notification services for mobile, etc. are all appreciated. > > > > It is my opinion that we should not include requirements for the > following in the new RUM document.  Here are the reasons that I > believe this way. > > > > WebRTC > > > > * While there is an RFC for WebRTC, it doesn't appear that all > browsers are following it.  For example, TMMBR is required for > WebRTC but Chrome does not signal it. > > * WebRTC is an audio first implementation.  For VRS, video is > the most important media stream.  It means everything to the deaf > or hard of hearing user.  If video is suffering first in a lossy > network, that is a problem for VRS. > > * Some of the VRS providers do not currently support the > following items.  This could pose a significant impact on the VRS > providers to get this implemented. > > o Encryption (DTLS) > > o ICE > > o RTP/RTCP Muxing > > > > IPv6 > > * For those VRS providers whose current implementations do not > support IPv6, this can be a big jump to get their solution to > support both IPv4 as well as IPv6.  Granted, it does not require > being dual stacked but rather could be two separate servers, each > supporting their respective version of IP.  This could be a big > undertaking just to get IPv6 into the mix. > > * Another solution could be an IPv4 to IPv6 gateway but that > doesn't work flawlessly.  For example, the gateway can forward the > IPv6 SIP message to the proper address on the IPv4 network, > however, how does it resolve the embedded IPv6 addresses signaled > in the SDP?  So, for example, consider two RUEs, one legacy RUE > that is using IPv4 and one that is IPv6; the signaling is possible > for both once the servers for each support that or provide a IP > gateway between the two.  How is the media going to work?  Each of > the RUEs is going to provide an IP address in their SDP, one will > be IPv4 and the other IPv6.  How is this going to work without > having to anchor all the media somewhere? > > * Are there issues that we need to resolve with NAT64 and/or DNS64? > > * As I understand it, some mobile devices are already IPv6 but > do not follow the RFC for embedding an IPv4 address into an IPv6 > address.  This is going to require special handling to get this to > work with such devices on vendors that do not follow the RFC in > this regard. > > > > Message Waiting Indicator > > * Some, if not all, of the current implementations of RUE by VRS > providers, already include means to record video messages and are > not all created the same way.  Proprietary methods have been > used.  The document states that MWI is optional but if the ability > to leave a message is provided then MWI is to be implemented. > Since there are proprietary solutions, it seems appropriate to me > that this should be changed so that proprietary solutions and > indications can continue to be utilized. > > > > > > I don't believe I have enumerated all the reasons for not > including requirements for the above but I believe the examples > given are sufficient to consider. > > > > Regards, > > Eugene Christensen > > > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any > documents, files or previous e-mail messages attached to it, may > contain confidential and proprietary information. If you are not > the intended recipient, or a person responsible for delivering it > to the intended recipient, you are hereby notified that any > disclosure, copying, distribution or use of any of the information > contained in or attached to this message is STRICTLY PROHIBITED. > If you have received this transmission in error, please > immediately notify me by reply e-mail at echristensen@sorenson.com > or by telephone at +1 (801) > 287-9419, and destroy the original transmission and its > attachments without reading them or saving them to disk. > > > > -----Original Message----- > > From: Rum > > On Behalf Of Paul Kyzivat > > Sent: Thursday, August 19, 2021 10:04 AM > > To: rum@ietf.org > > Cc: Alexander Ospina >; Isaac Roach > >; Brian Rosen > > > > Subject: [Rum] Action Items from RUM session at IETF 111 > > > > [EXTERNAL] > > > > The minutes from the RUM session include a number of action items. > > Specifically, the following people made commitments: > > > > Brian Rosen > > Isaac Roach > > Alex Ospina > > > > Brian is working on an updated version, but it won't include the > > concerns of the others above if we don't hear from you. Rather > than try > > to summarize those I refer you back to the minutes. You can find > them at: > > https://datatracker.ietf.org/doc/minutes-111-rum/ > > > > > I plan to issue WGLC on the document soon. I will wait one week > (until > > Aug 26). If there hasn't been any followup by then I will ask > Brian to > > issue a version that we can advance to WGLC. > > > >       Thanks, > >       Paul > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > From nobody Thu Aug 26 10:32:25 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D4A3A16EF for ; Thu, 26 Aug 2021 10:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 DOcSR44U4OaT for ; Thu, 26 Aug 2021 10:32:18 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2053.outbound.protection.outlook.com [40.107.220.53]) (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 F12393A16E9 for ; Thu, 26 Aug 2021 10:32:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iZDD7Rh+j3mlKdnuZFoklfMh+1eYyT8+I8z497D5l0XWhKFkm8PDedbbXn++VcBRXKrudK2qk8hVZ77kvoHqaMUejgl6pewi/cj6hDh1+SQ61qqhqYzc6msZ5QL2cYHy0Xcqv978ZTgFZFanFojvvtVqhv+VCWq1mV6ejCea1TCz2koF81od4DrgUWpVqcrZS01See2tif36LsGdqWoq2m12uPnoQHNRgFRh+16mO4HPcFfv9kt0Lv2Q//NaYbWjuvPZY5wWF/k2Le4Bf/ZT2wlnI1cebpxTdOjNZIPb1x6UkjH3WkdhzRSLw5CSuNBwaU3Dt+gwqmrkgtzhoxmwyQ== 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=BSV3W39XxAgGAjJ7/jWRrPzJCgdC/mJOOSQRBcFWIJY=; b=GZlTPLhPhwjBE1+k9gS+prfPUrtwQarZiZyfKefhYXH1SKd4oaIoRwuupYlLjMFK9rUPvuhiIGjFPmH/6kP9NT2PYPAwlJ7eTH6mIVGs3c1teog4WicWRTmMh9zDbrDTLWE/FssiMjafCzdJMUH7KTIPxQiAVf5HI1tHT1tIA6lUPJxV7rgWtyMs7qqfLFldc022ib0gCGW/04/D6iyAkpSfXMCxpkymVD+dddx1M8WgpGgIJPtE0HGgX1TG18A/tscdo0OZ8A634qGd/3xAplI9htp5a2cuG3as3f5y8KfE3UFPxcqIQrTdNmZoenJtSQxt0YvGCFmS6cBxZ7sszg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=purple.us smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=BSV3W39XxAgGAjJ7/jWRrPzJCgdC/mJOOSQRBcFWIJY=; b=X8gf+0pe9rOh9FHy1C44UmwELuHBCVrx4Me+mpezG6dZ7z3qqepyeBv9ydFobkNWKOhrt1U8LfDur95RH4alsEMDcL89zMHm04KDcSRgLvqeaufKgAvzeULmdp4bH6bSSjuTGCqhs9U0lkRjPtM3i8Y/pyM3AJJjPDcoJRtbtlk= Received: from SN7PR04CA0080.namprd04.prod.outlook.com (2603:10b6:806:121::25) by DM6PR12MB2714.namprd12.prod.outlook.com (2603:10b6:5:42::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 17:31:58 +0000 Received: from SN1NAM02FT0052.eop-nam02.prod.protection.outlook.com (2603:10b6:806:121:cafe::8d) by SN7PR04CA0080.outlook.office365.com (2603:10b6:806:121::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 17:31:58 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; purple.us; dkim=none (message not signed) header.d=none;purple.us; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT0052.mail.protection.outlook.com (10.97.5.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 17:31:57 +0000 Received: from MacBook-Air.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 17QHVrkJ014617 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 26 Aug 2021 13:31:53 -0400 To: Ed Sayers , Eugene Christensen , "rum@ietf.org" , Brian Rosen Cc: Isaac Roach , Alexander Ospina References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> From: Paul Kyzivat Message-ID: <72b016c0-6ffa-fb0e-ad3c-bbe687b8528b@alum.mit.edu> Date: Thu, 26 Aug 2021 13:31:53 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 7fc4b218-b138-45cb-31be-08d968b767dc X-MS-TrafficTypeDiagnostic: DM6PR12MB2714: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: jhhS9/EGs7YuUBlAHUFuZzU3b/2+wQbaR5jDhulG9mRph2l/i0FKNLq1VIHdhUcdfbjIDJ4Wcq78Z+P7wmX3l/weKIYHLwKp5l+1L9AEvqBlhOprUjCLUvT3EejHiBGK98u0LLBxJmykrykgDa/5uqSdndHFBGJb3a0sutIZLRWw3WaiInBRlwiXmfmx2h6QZ9BOTUIxHrQYK83yHYTCuOAw4NfZRc4HXGESPnPXr/UJY3kC9qTb8hOAziOzD+i8P5P5Av899CnTbpqeT/Bbbc6NaLVF+WHwy0BllgoX5FjJGvcY2TFyzT7OMX6NoNbWbL7sh1FOWKn7OYDX/yW0iMkd4VsZ2qKwQRhms3z0V9pGbfu4hn+pRhsqXeWpf2wVtsLzqpWUQHaqlMJU6iwauNVN3U/DY0HBS7qedNuquCVPNS1VSLOWpRZneTgQudn6J7prtriFdy2OjtZ0IIc0iQ6vm9okwWnnk/C6EiWEesBP0ZMmVJJeZzMMieQ/rtl3n1JlWCrW2/Xfe3148ZWrZ6TFDdVEU+ZDxG7YBZU3qTDpsHdU0DZEvqLlVMjqyUQqYX+xbFIblcKJdm0sliJd+0ge4Zql9uNu0p0Kp1I4gARHa9nT2ebdmCI9opcKsH1agjqE30P6vMqwPBiTJyFi28j3pTFZiayE0Wwaysy2yMY3qk4jHvmAT1Sd6/wEqUmVv3dXSgptITPr/b1CCnGHqv7djaRkVJHJIZjJOohb9DPuqUcLZW7NIqk0olLTXnlDWozjCRUfa6glp030IULcoDCzkqa+8XvD0u5bJMCU+Gloz+QyTr6apya9TocrJPZb 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; SFS:(396003)(39860400002)(376002)(346002)(136003)(36840700001)(46966006)(7596003)(83380400001)(70206006)(18074004)(54906003)(786003)(478600001)(2906002)(336012)(86362001)(356005)(47076005)(36860700001)(31696002)(5660300002)(82310400003)(966005)(82740400003)(8676002)(75432002)(36906005)(316002)(8936002)(110136005)(70586007)(4326008)(956004)(31686004)(186003)(26005)(53546011)(2616005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 17:31:57.6565 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 7fc4b218-b138-45cb-31be-08d968b767dc 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-AuthSource: SN1NAM02FT0052.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB2714 Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:32:24 -0000 Ed, One takeaway from your comments below is that the current spec doesn't say much about *retrieval* of video mail. Is there something we can specify that the RUE could use with all providers to retrieve video mail? E.g., could that simply be a https URL that will bring up a web page that the user will use to choose, play, and delete video mail? Once we find a standard way to retrieve video mail then we can revisit how to deliver a notification. Thanks, Paul On 8/26/21 1:15 PM, Ed Sayers wrote: > Hi Paul, > > The issue of MWI is far more the just mechanism of notifying the user. Whether that be push, email, SMS or anything else Provider can already support. > In addition, VRS Providers each solved the SIP PUSH problem 10+ years ago - long before the RFC was created - Following the needs of our customers and because RFCs like RFC8599 didn't exist, or because RFC-3482 was insufficient and there were no other adequate alternatives. > > Providers also currently use their own RESTful APIs to stream and/or download Video messages to the client for playback. > This cannot be supported by RFC-3482. Even if it were possible using the RFC-2822 message headers, section 3.5 states "Message headers MUST NOT be included in an initial NOTIFY, as new messages could be essentially unbounded in size". This means that MWI cannot provide streaming URIs for any old or initial new messages, and leaves a historical 'dial-up' mechanism as the only complete option when using this RFC. > > Providers would thus need to go and re-implement that "old tech" that was thrown away years ago and provides a much poorer user experience; A call to a Video IVR, to be navigated by DTMF tones. If nothing else, this requires a customer to be online every single time they want to view a message (And potentially incur data charges every time). Whereas any streamed message could be cached and still be viewed when offline. > > We completely understand that there is no RFC that can currently support the way we provider video mail notifications and messages. We knew that a long time ago. > > However, it needs to be made clear that this is a deficiency of the currently available RFCs, not one that VRS Providers are currently constrained by. > However, the creation of the RUM specification will constrain the way that Providers can provide features such as this, stifle innovation, and in cases such as this certainly be a limiting and retrograde step. > > > Many thanks, > > > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com > > The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. > > > > > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: 26 August 2021 16:48 > To: Eugene Christensen ; rum@ietf.org; Brian Rosen > Cc: Isaac Roach ; Alexander Ospina > Subject: [Rum] VRS Provider issues - MWI > > I want to split off MWI as different from the other issues you have raised. If I understand, your point is that each provider has a proprietary way of indicating video mail is waiting and retrieving it, so there is no need to do something different. (Please correct me if I have gotten this wrong.) > > The problem with this is that it means for a RUE to be able to access video mail it needs to support the proprietary mechanism of each provider it aims to work with. But interoperability of the RUE with multiple providers is an explicit goal of this work group. So we need a mechanism that the RUE can implement that will work with any provider. > > In principle this mechanism need not use the MWI mechanism, but coming up with some other, presumably purpose built, mechanism will be a hard sell. > > IMO proposals that fail to address this need for interoperability are out of scope. (To go there would require a change to the charter.) > > So, please frame video mail and MWI issues with interoperability as a requirement. > > Thanks, > Paul (With my RUM WG Chair hat ON) > > > On 8/25/21 2:58 PM, Eugene Christensen wrote: >> Brian, Paul thank you for considering the changes that haved been brought up to this point. Leaving things alone with the X-Card, the inclusion of the instance-id for location, additions to support notification services for mobile, etc. are all appreciated. >> >> It is my opinion that we should not include requirements for the following in the new RUM document. Here are the reasons that I believe this way. >> >> WebRTC >> >> * While there is an RFC for WebRTC, it doesn't appear that all browsers are following it. For example, TMMBR is required for WebRTC but Chrome does not signal it. >> * WebRTC is an audio first implementation. For VRS, video is the most important media stream. It means everything to the deaf or hard of hearing user. If video is suffering first in a lossy network, that is a problem for VRS. >> * Some of the VRS providers do not currently support the following items. This could pose a significant impact on the VRS providers to get this implemented. >> o Encryption (DTLS) >> o ICE >> o RTP/RTCP Muxing >> >> IPv6 >> * For those VRS providers whose current implementations do not support IPv6, this can be a big jump to get their solution to support both IPv4 as well as IPv6. Granted, it does not require being dual stacked but rather could be two separate servers, each supporting their respective version of IP. This could be a big undertaking just to get IPv6 into the mix. >> * Another solution could be an IPv4 to IPv6 gateway but that doesn't work flawlessly. For example, the gateway can forward the IPv6 SIP message to the proper address on the IPv4 network, however, how does it resolve the embedded IPv6 addresses signaled in the SDP? So, for example, consider two RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signaling is possible for both once the servers for each support that or provide a IP gateway between the two. How is the media going to work? Each of the RUEs is going to provide an IP address in their SDP, one will be IPv4 and the other IPv6. How is this going to work without having to anchor all the media somewhere? >> * Are there issues that we need to resolve with NAT64 and/or DNS64? >> * As I understand it, some mobile devices are already IPv6 but do not follow the RFC for embedding an IPv4 address into an IPv6 address. This is going to require special handling to get this to work with such devices on vendors that do not follow the RFC in this regard. >> >> Message Waiting Indicator >> * Some, if not all, of the current implementations of RUE by VRS providers, already include means to record video messages and are not all created the same way. Proprietary methods have been used. The document states that MWI is optional but if the ability to leave a message is provided then MWI is to be implemented. Since there are proprietary solutions, it seems appropriate to me that this should be changed so that proprietary solutions and indications can continue to be utilized. >> >> >> I don't believe I have enumerated all the reasons for not including requirements for the above but I believe the examples given are sufficient to consider. >> >> Regards, >> Eugene Christensen >> >> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain confidential and proprietary information. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this message is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and destroy the original transmission and its attachments without reading them or saving them to disk. >> >> -----Original Message----- >> From: Rum On Behalf Of Paul Kyzivat >> Sent: Thursday, August 19, 2021 10:04 AM >> To: rum@ietf.org >> Cc: Alexander Ospina ; Isaac Roach >> ; Brian Rosen >> Subject: [Rum] Action Items from RUM session at IETF 111 >> >> [EXTERNAL] >> >> The minutes from the RUM session include a number of action items. >> Specifically, the following people made commitments: >> >> Brian Rosen >> Isaac Roach >> Alex Ospina >> >> Brian is working on an updated version, but it won't include the >> concerns of the others above if we don't hear from you. Rather than >> try to summarize those I refer you back to the minutes. You can find them at: >> https://datatracker.ietf.org/doc/minutes-111-rum/ >> >> I plan to issue WGLC on the document soon. I will wait one week (until >> Aug 26). If there hasn't been any followup by then I will ask Brian to >> issue a version that we can advance to WGLC. >> >> Thanks, >> Paul >> > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > From nobody Thu Aug 26 10:33:36 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC7553A170A for ; Thu, 26 Aug 2021 10:33:33 -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 6qHc1bPxYuCt for ; Thu, 26 Aug 2021 10:33:27 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 42F883A1702 for ; Thu, 26 Aug 2021 10:33:27 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id j18so4715045ioj.8 for ; Thu, 26 Aug 2021 10:33:27 -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=de4y/Y7ztCTLivrZSIZE3x6+QdDZi8YvfipSExqR0AE=; b=Z3vFAg9VBdDqS1/jGCOCZYRWEO+k61g263UIMAlHY5vv15l+rgZGqYgDLBBzCQai/P LOg4mXJQ2U3bm/01MlqVHU5sGSJ6mZP0UtNjjkiBRny4ixg/7LL91syBpJvkSbrv8LeQ 2IEL1bZmN9pRuYWYlCPQXffjRX3iN6WT99xTOqoGcysp2mKbDHSA2v/o2pwZwl01Qn+K xJ4XZGLctqip2NiaXrG90VRic1vXI6rBFCgW0Y+jE4180BsjkizdfqqVmAF0miBR0Bv3 U9Xgk70M4FMitWwSlmC0PphCADWLrj3NUD3FiTzEBhBJeZYZ252893kOv6oRpu2puGod T9dA== 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=de4y/Y7ztCTLivrZSIZE3x6+QdDZi8YvfipSExqR0AE=; b=C4lABcVhO9AKAeTYjWG/2nuA98Whrcafx9Q9fqFbclJ+/aUs/7anRSrDqzn8NkITsx aPXlRtlGC9a1ZNUFqG/frhxaKYjmGhdhs9dWrN4UEKmaBsIqsUNCKyagbeT/Nrxmqua8 I0cu/48qpyNJUZ4cAppwpXoExsrBxAbGQCTMyVLlC4mAsm0pYTIlKmatLO3z8PDwt63G w5tYv2NqwYos712qmgqUBbrjxnPjSAhzeTytOoGCxo8CLugg02S/HU76vqIM7FMqYBX0 IwDzKYU5tyB0pEPcnkpzQhkoEq+Rz7lKwliRmqA1AeLO5DnSAtt6rn93oHGszNsdZoS5 /BhA== X-Gm-Message-State: AOAM5323ssUKa7S9ZKaw+kX4VsXSfBOU0zrWMbi+Iot0Q7Irwi3rnxgs agvnMTj/4PDMYnaZM7vKcuMbPw== X-Google-Smtp-Source: ABdhPJympZ01cQKMbW501CtB+i5hWqXw05UqbW0xZkWZDj6OhPiSezrhAcsLrbDmY3ti3Hew3vaBEg== X-Received: by 2002:a05:6638:33a9:: with SMTP id h41mr4499013jav.86.1629999205149; Thu, 26 Aug 2021 10:33:25 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id k6sm2068718ilu.41.2021.08.26.10.33.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 10:33:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Thu, 26 Aug 2021 13:33:23 -0400 Cc: Paul Kyzivat , Eugene Christensen , "rum@ietf.org" , Isaac Roach , Alexander Ospina Content-Transfer-Encoding: quoted-printable Message-Id: <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> To: Ed Sayers X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 17:33:34 -0000 I think this is not correct in most respects. This is a standard that allows a client conforming to the standard to = connect to a provider conforming to the standard (and, for a point to = point call, another client conforming to the standard. Anything that is = proprietary would not be acceptable, regardless of how it works. It has = to be standardized, or a client couldn=E2=80=99t be created that worked = with any conforming provider. =20 The doc only requires MWI, which is the notification of messages = waiting. It does not assume any specific mechanism to retrieve = messages. Only the notification to the user that there are messages = waiting to be retrieved. So discussion of how messages are streamed is = out of scope. The fact that each provider solved SIP PUSH is irrelevant: they each = solved it in a different way. Their proprietary clients can use that, = but a generic client couldn=E2=80=99t. =20 RFC3842 predates any SIP client created by VRS providers by many years. = They chose not to use the standards mechanism that existed years before = their implementation in favor of proprietary systems. There is no = deficiency of RFCs. You can imagine improvements on what 3842 does. = For example, you could want the number of outstanding messages. But the = fundamental, everyone needs it, indication that there is at least one = message available is universal, and needs a solution specified one way = or another in our document. I=E2=80=99m not aware of any other standard = for MWI. No one proposed an alternative to 3842, you have only = requested that this be proprietary, which is contrary to the basic goals = of the spec. Brian > On Aug 26, 2021, at 1:15 PM, Ed Sayers wrote: >=20 > Hi Paul, >=20 > The issue of MWI is far more the just mechanism of notifying the user. = Whether that be push, email, SMS or anything else Provider can already = support. > In addition, VRS Providers each solved the SIP PUSH problem 10+ years = ago - long before the RFC was created - Following the needs of our = customers and because RFCs like RFC8599 didn't exist, or because = RFC-3482 was insufficient and there were no other adequate alternatives. >=20 > Providers also currently use their own RESTful APIs to stream and/or = download Video messages to the client for playback. > This cannot be supported by RFC-3482. Even if it were possible using = the RFC-2822 message headers, section 3.5 states "Message headers MUST = NOT be included in an initial NOTIFY, as new messages could be = essentially unbounded in size". This means that MWI cannot provide = streaming URIs for any old or initial new messages, and leaves a = historical 'dial-up' mechanism as the only complete option when using = this RFC. >=20 > Providers would thus need to go and re-implement that "old tech" that = was thrown away years ago and provides a much poorer user experience; A = call to a Video IVR, to be navigated by DTMF tones. If nothing else, = this requires a customer to be online every single time they want to = view a message (And potentially incur data charges every time). Whereas = any streamed message could be cached and still be viewed when offline. >=20 > We completely understand that there is no RFC that can currently = support the way we provider video mail notifications and messages. We = knew that a long time ago. >=20 > However, it needs to be made clear that this is a deficiency of the = currently available RFCs, not one that VRS Providers are currently = constrained by. > However, the creation of the RUM specification will constrain the way = that Providers can provide features such as this, stifle innovation, and = in cases such as this certainly be a limiting and retrograde step. >=20 >=20 > Many thanks, >=20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com >=20 > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Rum On Behalf Of Paul Kyzivat > Sent: 26 August 2021 16:48 > To: Eugene Christensen ; rum@ietf.org; = Brian Rosen > Cc: Isaac Roach ; Alexander Ospina = > Subject: [Rum] VRS Provider issues - MWI >=20 > I want to split off MWI as different from the other issues you have = raised. If I understand, your point is that each provider has a = proprietary way of indicating video mail is waiting and retrieving it, = so there is no need to do something different. (Please correct me if I = have gotten this wrong.) >=20 > The problem with this is that it means for a RUE to be able to access = video mail it needs to support the proprietary mechanism of each = provider it aims to work with. But interoperability of the RUE with = multiple providers is an explicit goal of this work group. So we need a = mechanism that the RUE can implement that will work with any provider. >=20 > In principle this mechanism need not use the MWI mechanism, but coming = up with some other, presumably purpose built, mechanism will be a hard = sell. >=20 > IMO proposals that fail to address this need for interoperability are = out of scope. (To go there would require a change to the charter.) >=20 > So, please frame video mail and MWI issues with interoperability as a = requirement. >=20 > Thanks, > Paul (With my RUM WG Chair hat ON) >=20 >=20 > On 8/25/21 2:58 PM, Eugene Christensen wrote: >> Brian, Paul thank you for considering the changes that haved been = brought up to this point. Leaving things alone with the X-Card, the = inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated. >>=20 >> It is my opinion that we should not include requirements for the = following in the new RUM document. Here are the reasons that I believe = this way. >>=20 >> WebRTC >>=20 >> * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it. For example, TMMBR is required for WebRTC = but Chrome does not signal it. >> * WebRTC is an audio first implementation. For VRS, video is the = most important media stream. It means everything to the deaf or hard of = hearing user. If video is suffering first in a lossy network, that is a = problem for VRS. >> * Some of the VRS providers do not currently support the following = items. This could pose a significant impact on the VRS providers to get = this implemented. >> o Encryption (DTLS) >> o ICE >> o RTP/RTCP Muxing >>=20 >> IPv6 >> * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6. Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP. This could be a big undertaking just to get = IPv6 into the mix. >> * Another solution could be an IPv4 to IPv6 gateway but that doesn't = work flawlessly. For example, the gateway can forward the IPv6 SIP = message to the proper address on the IPv4 network, however, how does it = resolve the embedded IPv6 addresses signaled in the SDP? So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two. How is the = media going to work? Each of the RUEs is going to provide an IP address = in their SDP, one will be IPv4 and the other IPv6. How is this going to = work without having to anchor all the media somewhere? >> * Are there issues that we need to resolve with NAT64 and/or DNS64? >> * As I understand it, some mobile devices are already IPv6 but do not = follow the RFC for embedding an IPv4 address into an IPv6 address. This = is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard. >>=20 >> Message Waiting Indicator >> * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way. Proprietary methods have been used. The = document states that MWI is optional but if the ability to leave a = message is provided then MWI is to be implemented. Since there are = proprietary solutions, it seems appropriate to me that this should be = changed so that proprietary solutions and indications can continue to be = utilized. >>=20 >>=20 >> I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider. >>=20 >> Regards, >> Eugene Christensen >>=20 >> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and = destroy the original transmission and its attachments without reading = them or saving them to disk. >>=20 >> -----Original Message----- >> From: Rum On Behalf Of Paul Kyzivat >> Sent: Thursday, August 19, 2021 10:04 AM >> To: rum@ietf.org >> Cc: Alexander Ospina ; Isaac Roach=20 >> ; Brian Rosen >> Subject: [Rum] Action Items from RUM session at IETF 111 >>=20 >> [EXTERNAL] >>=20 >> The minutes from the RUM session include a number of action items. >> Specifically, the following people made commitments: >>=20 >> Brian Rosen >> Isaac Roach >> Alex Ospina >>=20 >> Brian is working on an updated version, but it won't include the=20 >> concerns of the others above if we don't hear from you. Rather than=20= >> try to summarize those I refer you back to the minutes. You can find = them at: >> https://datatracker.ietf.org/doc/minutes-111-rum/ >>=20 >> I plan to issue WGLC on the document soon. I will wait one week = (until=20 >> Aug 26). If there hasn't been any followup by then I will ask Brian = to=20 >> issue a version that we can advance to WGLC. >>=20 >> Thanks, >> Paul >>=20 >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Thu Aug 26 12:00:06 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3517A3A09B5 for ; Thu, 26 Aug 2021 12:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, 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 vgRIm182UjxG for ; Thu, 26 Aug 2021 11:59:59 -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 494E63A09AA for ; Thu, 26 Aug 2021 11:59:59 -0700 (PDT) Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-04v.sys.comcast.net with ESMTP id JEFQmNMb6x10yJKbTmn2Q7; Thu, 26 Aug 2021 18:59:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1630004395; bh=Oc5i1ctB7hQD0H64EifBNZNjkJjbTOqBVq7g1z/Tpzs=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=GWjPTbKOzWPxUD/AIIgZ0eL0THHseZGQqLZWCTHiEPTCj8Zr1IPBm7gnH17J2vlK0 8tZO1H1GXqXcA8ukuSVhkpVAk3a8AXppsYItIfQU9OxUVPKjVL+nyEby4pKpEsSb8E +n5xk8bStNGhNZgvZLAiyUSW55U+N+EKGH8vukJePB7pYeV1AG4frPnubO62ciCPbk 5zIBu/WQr1+taEiRbMX0/DDcrV3/56wmKu+QK7m6gmIqYCNDTWymcVxL4O9e2CGOc4 BYy68W1yVbUai6amkX5xNsLHz5K1l6KqrLPhD/fE/c0Jd6+ewn8IVGVGTqUlMorsgF bC1Vpmd1kqCvg== Received: from MacBook-Air.localdomain ([24.62.227.142]) by resomta-ch2-01v.sys.comcast.net with ESMTPA id JKbLmSiycnjRfJKbNmUDcY; Thu, 26 Aug 2021 18:59:55 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvtddrudduuddgudeftdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtjeertddtfeejnecuhfhrohhmpefrrghulhcumfihiihivhgrthcuoehpkhihiihivhgrthesrghluhhmrdhmihhtrdgvughuqeenucggtffrrghtthgvrhhnpeelgefhgfekheevffejteeuffejvdegveeitdevteetieffleffieekveelteejhfenucfkphepvdegrdeivddrvddvjedrudegvdenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopeforggtuehoohhkqdetihhrrdhlohgtrghlughomhgrihhnpdhinhgvthepvdegrdeivddrvddvjedrudegvddpmhgrihhlfhhrohhmpehpkhihiihivhgrthesrghluhhmrdhmihhtrdgvughupdhrtghpthhtoheprghoshhpihhnrgesrghslhhsvghrvhhitggvshdrtghomhdprhgtphhtthhopehirhhorggthhesshhorhgvnhhsohhnrdgtohhmpdhrtghpthhtoheprhhumhesihgvthhfrdhorhhgpdhrtghpthhtohepvggthhhrihhsthgvnhhsvghnsehsohhrvghnshhonhdrtghomhdprhgtphhtthhopegvugdrshgrhigvrhhssehpuhhrphhlvgdruhhspdhrtghpthhtohepsghrsegsrhhirg hnrhhoshgvnhdrnhgvth X-Xfinity-VMeta: sc=-100.00;st=legit To: Brian Rosen , Ed Sayers Cc: Eugene Christensen , "rum@ietf.org" , Isaac Roach , Alexander Ospina References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Thu, 26 Aug 2021 14:59:47 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:00:05 -0000 On 8/26/21 1:33 PM, Brian Rosen wrote: > The doc only requires MWI, which is the notification of messages waiting. It does not assume any specific mechanism to retrieve messages. Only the notification to the user that there are messages waiting to be retrieved. So discussion of how messages are streamed is out of scope. I don't think that makes sense. An interoperable RUE is a failure if the user still needs a proprietary mechanism to retrieve the video mail. The traditional SIP mechanism for voicemail is that the user establishes a sip dialog through which the user receives saved up voice mail. As Ed notes, it is archaic in that it typically doesn't provide a way to pick and choose what you want to hear. (Potentially it can, via some interaction over a media stream established by the call as long as the device doesn't have to do anything special.) I was thinking that there was an extension to RFC3842 that included an enumeration of individual messages with a URL to access each. But I haven't been able to find such so I may have been imagining it. I think we could allow configuration of either a SIP or an HTTPS URL for use in retrieving video mail. The HTTPS would provide a way to offer a provider-specific GUI for managing the video mail that can be accessed by a RUE that has no proprietary parts. Thanks, Paul From nobody Thu Aug 26 12:01:46 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B6A63A0BC4 for ; Thu, 26 Aug 2021 12:01:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 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] 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 SyKjDYWNu4dG for ; Thu, 26 Aug 2021 12:01:30 -0700 (PDT) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 7F21C3A0B05 for ; Thu, 26 Aug 2021 12:01:20 -0700 (PDT) Received: by mail-qt1-x82a.google.com with SMTP id x5so3340733qtq.13 for ; Thu, 26 Aug 2021 12:01:20 -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=o1bhyDkDkdbg9JvWE3CLNdguOEz33cQABR6oIke5GfA=; b=bqSlI4RV8alMJFaY9/E6NT2a43v6RpDMxnOU7LM5VZ11IjYrPV1XApeWGQpNn8Z9Dj VGn1zc6IC9BV0KHEsbgwXU8qCYsNs+eQCA7nSau16h2anDpAvKtJBleAD9/w6TDn6n84 C4jOgCGt6TvBWwsbcgVDl1t+UiX+A7Pod3dnn/wm2AHzvuP7f9GTa79we/8xugHgfqbC WcfGNLYnPZ6HslSWYdCzEKf9skvN7d7j6OxP1rsHNOEX7lEpsryLP/Titrv3XD3huJGS r8lUC5nltMjbjENvUF4hMMfTUmuurXahCQ2tRMWEfSYe45wEQ20IkxzHX++lhAkpgks/ x7HA== 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=o1bhyDkDkdbg9JvWE3CLNdguOEz33cQABR6oIke5GfA=; b=aMtdaNhzeJBzn8A6ihKngr1V+gLyhdMigMTGcE52srRxxVykjMJbNyIeemfTYpb8Jc p7U9b+tij1ZXDca9PCeNrAezL/XfZs12oFtnmXf9wRr+pIOxzOiNE0Q39BZlq2wa+tr7 QErwCBMH7J3Fkhb/Hlb3hqGDGhcee7irQz3F2uo2rPw9Ica9hWpwrdsBtOXWWOP1agMe cl4Y1PIVWycLX6giQFTTmW1N9mGzuZ6EZ2fY8Uo7aUyymtwfRWgY967qGgYmohuRxYdv kvAz399yZeZ3SkRPMDRTE0KcCEhqUWkfNqf1lNQu2T7sBtLihrULukHoaqWuwrQbRg2o ihBw== X-Gm-Message-State: AOAM531azoY+qIvjyi7zN1zGk+BOlz5TP1APlQAShFynXJ3xxEU5vzF9 H+uzMTkqCadZHTiaxJRyhI/ADQ== X-Google-Smtp-Source: ABdhPJzK5vunPx921g4JfErRwx29RMdpQNp6UkzcQ2i89ns38ZanOOkiF6DoMyHlCLLrwjMH/zYq4g== X-Received: by 2002:ac8:5a51:: with SMTP id o17mr4697396qta.386.1630004478190; Thu, 26 Aug 2021 12:01:18 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id x23sm3039437qkn.29.2021.08.26.12.01.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 12:01:17 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Thu, 26 Aug 2021 15:01:16 -0400 Cc: Ed Sayers , Eugene Christensen , "rum@ietf.org" , Isaac Roach , Alexander Ospina Content-Transfer-Encoding: quoted-printable Message-Id: <0D136565-27AA-4FD9-B372-EEFF5532C540@brianrosen.net> References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:01:44 -0000 I=E2=80=99m certainly willing to add a URL for retrieval to the config = data. Brian > On Aug 26, 2021, at 2:59 PM, Paul Kyzivat = wrote: >=20 > On 8/26/21 1:33 PM, Brian Rosen wrote: >=20 >> The doc only requires MWI, which is the notification of messages = waiting. It does not assume any specific mechanism to retrieve = messages. Only the notification to the user that there are messages = waiting to be retrieved. So discussion of how messages are streamed is = out of scope. >=20 > I don't think that makes sense. An interoperable RUE is a failure if = the user still needs a proprietary mechanism to retrieve the video mail. >=20 > The traditional SIP mechanism for voicemail is that the user = establishes a sip dialog through which the user receives saved up voice = mail. As Ed notes, it is archaic in that it typically doesn't provide a = way to pick and choose what you want to hear. (Potentially it can, via = some interaction over a media stream established by the call as long as = the device doesn't have to do anything special.) >=20 > I was thinking that there was an extension to RFC3842 that included an = enumeration of individual messages with a URL to access each. But I = haven't been able to find such so I may have been imagining it. >=20 > I think we could allow configuration of either a SIP or an HTTPS URL = for use in retrieving video mail. The HTTPS would provide a way to offer = a provider-specific GUI for managing the video mail that can be accessed = by a RUE that has no proprietary parts. >=20 > Thanks, > Paul >=20 From nobody Thu Aug 26 12:12:05 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1143A0A31 for ; Thu, 26 Aug 2021 12:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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 CgoTBrEyDsJJ for ; Thu, 26 Aug 2021 12:12:01 -0700 (PDT) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2055.outbound.protection.outlook.com [40.107.102.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 DF1B83A0A2E for ; Thu, 26 Aug 2021 12:12:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H2DgAhrsMPj6b9qlIb8uBS+JdTxyfW/EU406LvCg5lsNf9UItUzMr3tc3M5v/ePXB5r7Ur6OlRS3Pj6JLxsnNkA9Jnx60XTlwRnUdASIxRBs+1wu3Lt4vCuXrZDn/S2I1T2m2t4PMZRpERLElKe7FcfWZEUjJS4tTyPdA18iCxN7MDuBWflvQXtBxZWmS0Z2LLUdz9m2qoqRqlHCwXQl0iSl4aYc+nfFWGMaLLLjvZpDdWA54lvzYuQdHbX6Ni4zsZmZkB12M8KMgV0B62tAkkPIrjkWAT9vh6fCbjsK9kMdA/86ILAgZnosCGktDY040TsfBGPuD0h6xudSe9K1vw== 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=Oc5i1ctB7hQD0H64EifBNZNjkJjbTOqBVq7g1z/Tpzs=; b=iWaSo4bHlu7xjeRFDo/zvs8d2rdcu8TNXk5M1qU9EnbJcFFKnIseDOzd7jMASE+uu4U1gZQZiiEbr6Lnt77e2vtZH3UgPqKizqeELCXpbmuNderK8EQvnADsZ6bTl40VvQfZ7jcEUvirNic4agJXAivO1yIIEAgWgEwuxwAE6uTpTkRB96r7gJhZOd0/eQgBXurB2F0quqtyfmpWDh1kWM56SWXSoJLmLL6Un2K+IuAHUghCLXHuvnIDcqN3TExbVylgiiC9hMQm0LDDDieD4wjPzqJK9CcZsKA2rdnqBp+FeWnRIxgNZNuTL5IcmGfrz8DSEiwygc36aeaKl9pZ+A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=brianrosen.net smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=Oc5i1ctB7hQD0H64EifBNZNjkJjbTOqBVq7g1z/Tpzs=; b=JOLlUCymSwHog6LurMUHmBWp5cbPT8cZnB9K1cnxDpnjUqeGDcyjMT8m8blpn+mKs2Krdm/8ExBBsS3loWb0qfFlYDk8P0lULnFW5w4YjmcpijkEkVlzq/D43O8uPyuRTKfySpJHxOcASokIRasnb3dB+sEbdax8iqq7c7ckVKg= Received: from BN9PR03CA0541.namprd03.prod.outlook.com (2603:10b6:408:138::6) by MN2PR12MB3886.namprd12.prod.outlook.com (2603:10b6:208:16a::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Thu, 26 Aug 2021 19:11:59 +0000 Received: from BN1NAM02FT035.eop-nam02.prod.protection.outlook.com (2603:10b6:408:138:cafe::18) by BN9PR03CA0541.outlook.office365.com (2603:10b6:408:138::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Thu, 26 Aug 2021 19:11:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT035.mail.protection.outlook.com (10.13.2.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 19:11:58 +0000 Received: from MacBook-Air.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 17QJBq2x022385 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 26 Aug 2021 15:11:53 -0400 From: Paul Kyzivat To: Brian Rosen , Ed Sayers Cc: Eugene Christensen , "rum@ietf.org" , Isaac Roach , Alexander Ospina References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> Message-ID: <4fa476dd-2b2a-ba8b-01e7-36da1269aa5e@alum.mit.edu> Date: Thu, 26 Aug 2021 15:11:52 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 904994ca-0b67-4131-6cdb-08d968c560a9 X-MS-TrafficTypeDiagnostic: MN2PR12MB3886: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: GSTReEVj4cIBkKKbYOOPpIvdopj51cGMMKV/36iWj6JPVX4i+qi/gQcxLCKC2NETA+dNvM/Gtuzc9XTXh2K/GWJxC9i0Oj9l9hvsQwgIodHIItU0O7B97lTVjmNDny+/CE24zmJpcNyfZ6VvNPvTuyoTW+Srr0pgeLt3pNtPmqs8JMTpqZg82Z97Q7HjIyjbACpfRdgtsOXDZEE/VeueC2VQYBVv3rJFWKLVHKwng1/GEPyZTpouLkYn3+Bwt/mZL9cPVY+3QU2KV0epS0kDlJh+AqwIgwzJRHNZRi7JUIwZHYqBNefy8DYeGqovW+QJyubeFWI8FQ5/Bqn98aojW05a20CjYjaj4NdHVI8lew1if01mqvKSFx4E0FJOoHbRy9AmmhG/o9zGsbXCQRHjTV5Dj/XIL4mzCTXpgWiicx8oDOSmeiH6OatC7M68JCGHXt+Nz7M/JVV/HNiH0b3JCtvrRGAHPPo1QhVV5i1H10cbeGGZ/BK6Wq1MSmzAyBYLLXRBfXO2/udeWivcnHHazHccwLMHbor0qQPPId9gdH9vcrkmbiuclRx3w+IR79M5EoaBzEKF/IwBcpnLSnCEofYZSV2NOfLD/uSETTL6JfckVVOfpuCJtt/7C/P6dv/3pCx9QbD5kpdM9I+Us3cNj6dVrsJAq8zmNM0JOl92oOM6SSEFOP6IZsXjF0bGwpqGFMoizQdTtYXRAXT/2TLke/dhY8YESqOxQ2E5154hyRs= 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; SFS:(46966006)(36840700001)(5660300002)(26005)(31696002)(53546011)(36860700001)(110136005)(31686004)(77540400001)(86362001)(186003)(75432002)(4326008)(356005)(54906003)(336012)(83380400001)(316002)(82310400003)(2616005)(36906005)(7596003)(508600001)(956004)(8936002)(70206006)(8676002)(70586007)(47076005)(786003)(2906002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 19:11:58.8218 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 904994ca-0b67-4131-6cdb-08d968c560a9 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-AuthSource: BN1NAM02FT035.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3886 Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:12:04 -0000 On 8/26/21 1:33 PM, Brian Rosen wrote: > The doc only requires MWI, which is the notification of messages waiting. It does not assume any specific mechanism to retrieve messages. Only the notification to the user that there are messages waiting to be retrieved. So discussion of how messages are streamed is out of scope. I don't think that makes sense. An interoperable RUE is a failure if the user still needs a proprietary mechanism to retrieve the video mail. The traditional SIP mechanism for voicemail is that the user establishes a sip dialog through which the user receives saved up voice mail. As Ed notes, it is archaic in that it typically doesn't provide a way to pick and choose what you want to hear. (Potentially it can, via some interaction over a media stream established by the call as long as the device doesn't have to do anything special.) I was thinking that there was an extension to RFC3842 that included an enumeration of individual messages with a URL to access each. But I haven't been able to find such so I may have been imagining it. I think we could allow configuration of either a SIP or an HTTPS URL for use in retrieving video mail. The HTTPS would provide a way to offer a provider-specific GUI for managing the video mail that can be accessed by a RUE that has no proprietary parts. Thanks, Paul From nobody Thu Aug 26 12:16:48 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495693A0B19 for ; Thu, 26 Aug 2021 12:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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 oZb4QJQ5t6YY for ; Thu, 26 Aug 2021 12:16:42 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2075.outbound.protection.outlook.com [40.107.92.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 345633A0B18 for ; Thu, 26 Aug 2021 12:16:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BsrH5/FqzMAiMYEohdSj4w2pkJjyh4ALt+RZevZSokhfq88vXLXk0UvE7E3/1v/ldtUWrkN1Jav30ZYMvOtajPm33fTCnXa7PwBxALcIRvPlL+xGMgOmyO6+x/Hpue4uxU+RcltTKK/lRVvLB74Wbhj2Ewh3+Wwt15XDAhcUZG1KylTbLnk6K2xR2339Z8ZPj1FTxOK+zBCVFUsTCElHFnnbWKlNRKxZm7T714KhdIlmJ15KthU/Ddp1e+SfoyByJ5dy1kodmMptisepJunhmUN6lCLQ/eBcNhFC6DG84t1Cp9tMUsI/1Ru3kwtk3/9wZHmUcagKZMtknnBuUs0VVQ== 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=VLuFxRG8zozkbkU0u2XWnggvFZDoJ/Qk67mQuh96dCU=; b=Jpz2NLYoctDT/cAzfgGYkg94X7fv/RHL8U8o6ul9tyHre30zMLAv/FIP3FT10Ab88Ez30gkVPujDuPtcL2BUKadN98xQPgrhipOT3lFaWCUhCSDulVlVkZUCOEYjbEYQ6JZxfh3pQWsokfVdaFUsoL0bGepuBRg7+oGRXMKLL1TVUbRKrJ0GXTRSV0dO1O9sYUxUwKqEPb5e2fGTULEsA4OHxwtZs84GmUUMjNDwx31q/0eRa6fq0aVAfKO/o5D6no2XUj9MZsJssYq4byROl4sGD56WAuha4ymGlPWffiKbcv/t/WZmwTw40kP1ypR85PvBoIIaa0P2nPOn7eY0eA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=VLuFxRG8zozkbkU0u2XWnggvFZDoJ/Qk67mQuh96dCU=; b=QcBNyoSbFUHVreegjXN8Gji1dDHkkUdIHD8zq3+Ljm8NsqLft7n3ZJFXgzfuTle4eYGWwx4plIiVZeGvNTM2bPjMZqJUQl9Brw5m51RaZ4tlKnuhwx9nK3LxixvwT23xWZHV1qoo1SRrwuiz0N686lM0Puc1dGN2XZlp1yFwLMg= Received: from SN4PR0601CA0020.namprd06.prod.outlook.com (2603:10b6:803:2f::30) by BN8PR12MB3186.namprd12.prod.outlook.com (2603:10b6:408:9b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Thu, 26 Aug 2021 19:16:38 +0000 Received: from SN1NAM02FT0021.eop-nam02.prod.protection.outlook.com (2603:10b6:803:2f:cafe::50) by SN4PR0601CA0020.outlook.office365.com (2603:10b6:803:2f::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.21 via Frontend Transport; Thu, 26 Aug 2021 19:16:38 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by SN1NAM02FT0021.mail.protection.outlook.com (10.97.5.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 19:16:38 +0000 Received: from MacBook-Air.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 17QJGa71022587 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 26 Aug 2021 15:16:37 -0400 To: rum@ietf.org References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> <0D136565-27AA-4FD9-B372-EEFF5532C540@brianrosen.net> From: Paul Kyzivat Message-ID: <0fe6934a-fd70-ae55-3201-09c203f11684@alum.mit.edu> Date: Thu, 26 Aug 2021 15:16:36 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <0D136565-27AA-4FD9-B372-EEFF5532C540@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 309ad13e-9a0f-45ef-2a1d-08d968c60765 X-MS-TrafficTypeDiagnostic: BN8PR12MB3186: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KDiyXj6eeX4JQdaPPy4FNkT3UZDWQO6BSxzoZ0lVl3fYZkyyu7co3MZGF+D/e9jzTtTs4AMeUBOukoxy8ogGK28aOtlDcW3G4RAL5H1OxyssRwmyDuyG+iiU7Uh+8TgWMZ2RM3A2dqB7ICZTEEXBBBzP/xRsFBks3CC7gjae6yZMfXx5dVBeGHS5yhaQRSxHs+fUGczTw08GXnKglaZxRrxKKPfTSAEL+M/Qkx33izy1Bm0z3IJWiVRns6i6zERRC7C2JywIjr5DlvjKxYEvhME+Q7gvuw+Y7i2Kd5liXy+p8OT9EzGEYyhem6PmLrZ9jg4nht8Cn/Jgcou4tWWbjcQtW7rhFGOuTDqaZj3Wg1KjWa0X2LuMp1EBrYwiIidxpV65RrdOGJmJzj7vl2KyfEOOPdfCC57ujk/dU0+0l7ywEJnqb/649SzgCQR9htGA9L55hWUz6wXW2dE8ZsLBZdzm+G5XSXmMCxnjxmfTjEQl0UNaCA/BQv2zRdOuaBwBnUoEd9AJniVuE8pQO5S3q2ZQkT1dulOcRBQnz4mxgGtc56/fxF0b2onnRnx6Kk6kNyflMh1TqndhmuFxqGLec0u/2ysl6vrbYRIRCSbedN98V/Y6yppnYPkyU/NvBje8V+0bETcp7EtYH7YW29LHTwr/WmZDNlY/VXRfu0lTMPMy7VP154tApRHQtFNCMVBgFKpARTwIwQGPLjkMd3QJzuvaGN9Rpdwl0A4zByT7i/Q= 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; SFS:(136003)(396003)(346002)(376002)(39860400002)(46966006)(36840700001)(8676002)(77540400001)(7596003)(356005)(47076005)(31696002)(786003)(316002)(6916009)(5660300002)(83380400001)(186003)(478600001)(36860700001)(70206006)(70586007)(8936002)(86362001)(82310400003)(26005)(82740400003)(336012)(36906005)(2906002)(53546011)(31686004)(2616005)(956004)(75432002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 19:16:38.4590 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 309ad13e-9a0f-45ef-2a1d-08d968c60765 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-AuthSource: SN1NAM02FT0021.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR12MB3186 Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:16:47 -0000 On 8/26/21 3:01 PM, Brian Rosen wrote: > I’m certainly willing to add a URL for retrieval to the config data. There probably should be a section on retrieval/management of video mail - basically what the RUE is supposed to do with the URL. We need to see that the user will be able to fully manage video mail from the RUE without any proprietary implementation. Thanks, Paul > Brian > >> On Aug 26, 2021, at 2:59 PM, Paul Kyzivat wrote: >> >> On 8/26/21 1:33 PM, Brian Rosen wrote: >> >>> The doc only requires MWI, which is the notification of messages waiting. It does not assume any specific mechanism to retrieve messages. Only the notification to the user that there are messages waiting to be retrieved. So discussion of how messages are streamed is out of scope. >> >> I don't think that makes sense. An interoperable RUE is a failure if the user still needs a proprietary mechanism to retrieve the video mail. >> >> The traditional SIP mechanism for voicemail is that the user establishes a sip dialog through which the user receives saved up voice mail. As Ed notes, it is archaic in that it typically doesn't provide a way to pick and choose what you want to hear. (Potentially it can, via some interaction over a media stream established by the call as long as the device doesn't have to do anything special.) >> >> I was thinking that there was an extension to RFC3842 that included an enumeration of individual messages with a URL to access each. But I haven't been able to find such so I may have been imagining it. >> >> I think we could allow configuration of either a SIP or an HTTPS URL for use in retrieving video mail. The HTTPS would provide a way to offer a provider-specific GUI for managing the video mail that can be accessed by a RUE that has no proprietary parts. >> >> Thanks, >> Paul >> > From nobody Thu Aug 26 12:18:56 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 216873A0B40 for ; Thu, 26 Aug 2021 12:18:54 -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 YkJ1b8bmAgSo for ; Thu, 26 Aug 2021 12:18:49 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 1384B3A0B3C for ; Thu, 26 Aug 2021 12:18:49 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id a66so4668122qkc.1 for ; Thu, 26 Aug 2021 12:18:49 -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=W/3wUEaXxPssQ24kHn+bTpWEhuAs59E3pPuQMrIPFz0=; b=edRYb4UxNO2RrM5XvoE2zZy75/b9aS/2GCwPOo7m+ljJcSZd/svecoEGjJ9z7/VASj s7d71T2ub7iuL5YJ50uCf8aFl0iCzI6rPOG5xQKFZnBKjMfQMBkIxC3U+RFgsEVuFj9i /9AVVTBOS9KgKlkf+qkpnzRUEK9XcUeXSeAsOnLpzi1p9A/poN5vMhHYMG2cS4x1owYO I0eujijfvLaOlWrIywMwDCEjfq51hbrc/Q5s5nesKIy+jx0UKf8tYWzU5g6wNA/FMVIR GBBYGRlFfDuPqwY2btUuHwpdkQsQRgdx6nQPnlgceKlQEwJeaTKDNwmwoe6thKuiYVqK KzlQ== 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=W/3wUEaXxPssQ24kHn+bTpWEhuAs59E3pPuQMrIPFz0=; b=crC7HRjOesVZ8KtTtLwMei7JXC/a/yM9FVfuVMAg66Q5U0JrxK3AjC3nlEEMrnieMn ZxYEnT1vZMRJnAOaASXFXi2Imsb+UONbCIjBKjf4Rz14JCVzW9idnVBQSihi8bn9mD8z kQ71It1Gheq/p5oodXuTLwtH1PEmUAm6J+cDEoZceHMNnnNCVvnGeqHxJC+vWQj5Qz+t LL9ZNf1cujLjli8ZTaoKxe+L6xBvMIwBxwqdN2Gi+r4vm7lnuopgBFAglZ8hQ78BE3IT GlfOtUsz6AgFSx9o16/HPTL5STIuN/p72PZt9PQikzAUJU2ILkTrm+qK2/StUE46sXhV s35g== X-Gm-Message-State: AOAM533izVx/KVa8BZoeIFkx5z1GalNYZsLDUThh5lK4G8XOWO+28m1X hxhqlSU8QtjjFNCkwQEXuXR/3cXWiAXECxdh X-Google-Smtp-Source: ABdhPJyr3EROqYLz/r5s6wh4oyWUkG1QBNHJ3tCOT3CV/cSj/Gz6ZEfM8bvyzc+3+LnzK0um1Oo9Mw== X-Received: by 2002:a37:8a86:: with SMTP id m128mr5266007qkd.319.1630005526308; Thu, 26 Aug 2021 12:18:46 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id v145sm3265151qkb.132.2021.08.26.12.18.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 12:18:45 -0700 (PDT) From: Brian Rosen Message-Id: <7CD2F56C-BBFE-4112-8473-5529B3057FEB@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_BCB82742-8F68-48CA-9AC4-7F3C0B5F76A5" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 15:18:44 -0400 In-Reply-To: <0fe6934a-fd70-ae55-3201-09c203f11684@alum.mit.edu> Cc: rum@ietf.org To: Paul Kyzivat References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> <0D136565-27AA-4FD9-B372-EEFF5532C540@brianrosen.net> <0fe6934a-fd70-ae55-3201-09c203f11684@alum.mit.edu> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:18:54 -0000 --Apple-Mail=_BCB82742-8F68-48CA-9AC4-7F3C0B5F76A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Absolutely willing to do that. It wouldn=E2=80=99t be much text. =20 Brian > On Aug 26, 2021, at 3:16 PM, Paul Kyzivat = wrote: >=20 > On 8/26/21 3:01 PM, Brian Rosen wrote: >> I=E2=80=99m certainly willing to add a URL for retrieval to the = config data. >=20 > There probably should be a section on retrieval/management of video = mail - basically what the RUE is supposed to do with the URL. We need to = see that the user will be able to fully manage video mail from the RUE = without any proprietary implementation. >=20 > Thanks, > Paul >=20 >> Brian >>> On Aug 26, 2021, at 2:59 PM, Paul Kyzivat = wrote: >>>=20 >>> On 8/26/21 1:33 PM, Brian Rosen wrote: >>>=20 >>>> The doc only requires MWI, which is the notification of messages = waiting. It does not assume any specific mechanism to retrieve = messages. Only the notification to the user that there are messages = waiting to be retrieved. So discussion of how messages are streamed is = out of scope. >>>=20 >>> I don't think that makes sense. An interoperable RUE is a failure if = the user still needs a proprietary mechanism to retrieve the video mail. >>>=20 >>> The traditional SIP mechanism for voicemail is that the user = establishes a sip dialog through which the user receives saved up voice = mail. As Ed notes, it is archaic in that it typically doesn't provide a = way to pick and choose what you want to hear. (Potentially it can, via = some interaction over a media stream established by the call as long as = the device doesn't have to do anything special.) >>>=20 >>> I was thinking that there was an extension to RFC3842 that included = an enumeration of individual messages with a URL to access each. But I = haven't been able to find such so I may have been imagining it. >>>=20 >>> I think we could allow configuration of either a SIP or an HTTPS URL = for use in retrieving video mail. The HTTPS would provide a way to offer = a provider-specific GUI for managing the video mail that can be accessed = by a RUE that has no proprietary parts. >>>=20 >>> Thanks, >>> Paul >>>=20 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_BCB82742-8F68-48CA-9AC4-7F3C0B5F76A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Absolutely willing to do that.

It wouldn=E2=80=99t be much text. =  

Brian


On Aug = 26, 2021, at 3:16 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 8/26/21 3:01 PM, Brian Rosen wrote:
I=E2=80= =99m certainly willing to add a URL for retrieval to the config data.

There probably should be a section on retrieval/management of = video mail - basically what the RUE is supposed to do with the URL. We = need to see that the user will be able to fully manage video mail from = the RUE without any proprietary implementation.

Thanks,
= Paul

Brian
On = Aug 26, 2021, at 2:59 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

On 8/26/21 1:33 PM, Brian Rosen wrote:

The doc only requires = MWI, which is the notification of messages waiting.  It does not = assume any specific mechanism to retrieve messages.  Only the = notification to the user that there are messages waiting to be = retrieved. So discussion of how messages are streamed is out of = scope.

I don't think that = makes sense. An interoperable RUE is a failure if the user still needs a = proprietary mechanism to retrieve the video mail.

The traditional SIP mechanism for voicemail is that the user = establishes a sip dialog through which the user receives saved up voice = mail. As Ed notes, it is archaic in that it typically doesn't provide a = way to pick and choose what you want to hear. (Potentially it can, via = some interaction over a media stream established by the call as long as = the device doesn't have to do anything special.)

I was thinking that there was an extension to RFC3842 that = included an enumeration of individual messages with a URL to access = each. But I haven't been able to find such so I may have been imagining = it.

I think we could allow configuration of = either a SIP or an HTTPS URL for use in retrieving video mail. The HTTPS = would provide a way to offer a provider-specific GUI for managing the = video mail that can be accessed by a RUE that has no proprietary = parts.

Thanks,
Paul


-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_BCB82742-8F68-48CA-9AC4-7F3C0B5F76A5-- From nobody Thu Aug 26 12:30:39 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138E33A0DB4 for ; Thu, 26 Aug 2021 12:30:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 EfLU7ZaIt2sT for ; Thu, 26 Aug 2021 12:30:29 -0700 (PDT) Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) (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 508033A0DAE for ; Thu, 26 Aug 2021 12:30:28 -0700 (PDT) Received: by mail-ej1-x62c.google.com with SMTP id x11so8792924ejv.0 for ; Thu, 26 Aug 2021 12:30: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=a0p5aremBg25LjgKKyQKc/iD8a+RDuni+enUknt+nWM=; b=uK1RN34zZ48vZ7POEAL1yf2vInq7Ub1bB+zQFwqz3li0Jk5FcXcDJYQuB95orS3PlZ ctdehx6xZKXQpTOnXEljMV7sDvtzuQBl+T1zpmHyDlYWuhYqvKTkdA32zENl1/E8zJRv i2ymRJbkEqcxh80P90XjGfh01K3S5b9kzRCLnO8Rgc+ax/fPe308GtoP+xUNbuT9ijpt zeJDqrQGsEFAEH8ybC6w4OkB8zQEwPnshAlPUoqBsrOTy0ADQR+GoOnbbkFeoKu6MH0g vsJo/UOsXfDiPx8LIQTXtXjk5Q62guBZRmNhaqbhrxS5TO+bWc/IB455l7Zn1ZgdP5pG n8VA== 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=a0p5aremBg25LjgKKyQKc/iD8a+RDuni+enUknt+nWM=; b=l0WKnwdGqp0S0SJTU5WRKFy727m70BVpaKva2fXLFU0KE0bMZDoLa46e8SEsGkIZY2 Q9/JzKp44TId7RaG6lvRmMtVvQxCLiDO1C5tF5Se2BqUB1tOTFdOZqPK4Z+OAqYHxTbj k3Nvqu+82IIqDUyK4QZhZzljXkPUd/mKk+JaYRryCP2cZGjnLjw0KtIIsCcaQgUKQFgX o6Yu/2nljVNxKcYEgpEVyBAyN17GYfh5M0xGW8cpOPD5JYp6frP/3ifWYP9UVpFqXOB8 EPpBYqI1KkmWEvl2Up/Y9Fr/to8LwPZEoCzK4G/KRkrZ2Hkk6DDp+MamairVRzHiOGqE D64A== X-Gm-Message-State: AOAM532hhgvWS9wl8QqGDiuPtUNdr6kYe6p8RY5+KlH4XDjmLgP5T5xp 1HI1zGASq28biMHz/oWXxy0eDnwVsLl65IvHgjo= X-Google-Smtp-Source: ABdhPJxKdC7YGSuF+GiHBn0kjfCt+HtvWrE6IKohzGSbEkcFfXXGy9ondEf/5obdlKfMkRicxfHIu2PefagT7zoPS0o= X-Received: by 2002:a17:907:9688:: with SMTP id hd8mr6083764ejc.484.1630006225202; Thu, 26 Aug 2021 12:30:25 -0700 (PDT) MIME-Version: 1.0 References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> In-Reply-To: <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> From: Roger Slusser Date: Thu, 26 Aug 2021 15:30:13 -0400 Message-ID: To: "Olle E. Johansson" Cc: Eugene Christensen , "rum@ietf.org" , Paul Kyzivat , Alexander Ospina , Isaac Roach , Brian Rosen Content-Type: multipart/alternative; boundary="00000000000008f28805ca7b6661" Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:30:35 -0000 --00000000000008f28805ca7b6661 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson wrote: > > > On 26 Aug 2021, at 16:17, Roger Slusser wrote: > > Hello all, > First off these are personal comments and not as a spokesperson for the > VRS provider I work for. > > I have to agree right down the line with Eugene Christensen. I have been = a > part of this from day one and have been directly involved in the setup an= d > execution of the bi-annual Interop conferences and development of the > Provider Interoperability Profile. > > It is obvious to me that this RUM RFC will be picked up by the FCC as the > new spec for the VATRP. > > Roger, > With all respect. There is a world outside the USA. RFCs are written with > global scope, not limited to a specific market or group of vendors. > Olle, I think you may have missed my point about this targeting a specific industry, namely the VRS industry in the US. Also when the FCC mandates support of an RFC they do not specify custom profiles especially in this case. There may be other uses for this out there but none that are directly or possibly adversely affected. > > So let's not kid ourselves or mince words about implementations, industry > profiles and various services. This endpoint spec will be terminated by a > VRS provider Interpreter station or proprietary endpoint in 99% of the us= e > cases. By mandating via "MUSTs" in this RFC, and there are many, it will > force the VRS providers to abandon current project plans and business goa= ls > to turn attention to implementing things in this RFC that have very littl= e > value to the Deaf and HH end users we support. Every provider already has= a > notification scheme for message waiting, most of which is much more > elaborate and sophisticated than MWI, yet this RFC will force less > desirable services... why? This is just an example that has been objected > to since day one and yet it still has stuck like glue. Let's not lose foc= us > of the driving force here, the betterment of the endpoint experience for > the Deaf and HH user base. > > I think being able to get privacy and be able to use all networks, > including the old IPv4 networks, is a good experience. > Most providers already support encryption and IPV6 on a limited scope, not necessarily the way it is defined in RUM spec. Mandating compliance using MUST requires providers to discard sometimes huge amounts of development to change over to what RUM is specifying. The push back is not about doing these things it is about the loss of time, effort and money to do them in the way RUM mandates with MUSTs. > > > I understand this is IETF. I understand this must have the latest and > greatest tech the industry has to offer, but I think the driving committe= e > members of this RFC also need to understand the realities of implementati= on > and the hardship this can and will bring to providers with the "MUSTs". T= he > FCC denies funding for non compliance, the reality is these "MUSTs" could > put providers out of business. > > A MUST in an RFC points to an implementation. It doesn=E2=80=99t provide = a profile > for a service. If a service provider only provides IPv4 that=E2=80=99s ok > (depending on the customer requirements of course). But to be RFC complia= nt > and interoperable, an implementation has to be able to support what=E2=80= =99s > specified as MUSTs. > > > I know there are heavy hitters in the IETF community on this project. But > there are also founding members of the VRS industry who have offered > comments with reasonable explanations that have been dismissed. After 18 > year I believe we know our customer base. The Deaf employees in our > companies in marketing and sales collectively drive our product offerings > to best suit their needs because we eat our own dog food.. I would urge > this committee to take long and hard consideration of the experience that > in my opinion is being dismissed offhandedly for the sake of new tech tha= t > has very little to do with our customers needs or wants. > > IPv6 is not new tech at this point. SRTP/DTLS is implemented in millions > of web browsers out there, with many implementations in Open Source. It= =E2=80=99s > not new tech, not at all. In fact I would be surprised if the US FCC does > not require IPv6. > > I have been working with social care alarms as well as telephony for deaf > and hearing impaired. The users don=E2=80=99t deserve old technology or a= lack of > privacy. If you ask them it would be assumed that you work on all kind of > networks - mobile, wifi, fixed and they trust you to give them privacy. > They won=E2=80=99t specify that in technichal terms, it=E2=80=99s just as= sumed. > > /O > I already addressed this earlier. It is not that we don't provide encryption, we have settled on other methods. We have been supporting IPv6 for some time now on a limited basis. > > Thanks for your consideration, > Roger Slusser > > On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson wrote: > >> Friends, >> This is the IETF after all. >> >> We can=E2=80=99t let any documents be published without IPv6. The proble= ms you >> outline here are surely solved in existing implementations of SIP, propa= bly >> since many years ago. If not, we have work to do. >> >> In addition, RUM services without SRTP/DTLS will be used over any >> network, including the Internet, and it is a very bad solution that feel= s >> like something we sold in the SIP world a long time ago. The world has >> moved since then. >> >> I strongly urge that the RUM specs has to require mandatory IPv6 support >> as well as SRTP/DTLS encryption. >> >> I would personally go as far as to say that SRTP/DTLS is a MUST and >> nothing else is ok, very much like WebRTC. >> >> In regards to proprietary vs open standards, this is again the IETF. We >> produce open standards and a RUM specification has to point to a SIP >> SUBSCRIBE/NOTIFY package for MWI. >> >> Remember that what I=E2=80=99m talking about is documents as specified b= y the >> IETF. Industry profiles and various services may go other ways, but the >> IETF standards has to be up to date with best current practise. >> >> Cheers, >> /O >> >> > On 25 Aug 2021, at 20:58, Eugene Christensen >> wrote: >> > >> > Brian, Paul thank you for considering the changes that have been >> brought up to this point. Leaving things alone with the X-Card, the >> inclusion of the instance-id for location, additions to support >> notification services for mobile, etc. are all appreciated. >> > >> > It is my opinion that we should not include requirements for the >> following in the new RUM document. Here are the reasons that I believe >> this way. >> > >> > WebRTC >> > >> > * While there is an RFC for WebRTC, it doesn't appear that all browser= s >> are following it. For example, TMMBR is required for WebRTC but Chrome >> does not signal it. >> > * WebRTC is an audio first implementation. For VRS, video is the most >> important media stream. It means everything to the deaf or hard of hear= ing >> user. If video is suffering first in a lossy network, that is a problem >> for VRS. >> > * Some of the VRS providers do not currently support the following >> items. This could pose a significant impact on the VRS providers to get >> this implemented. >> > o Encryption (DTLS) >> > o ICE >> > o RTP/RTCP Muxing >> > >> > IPv6 >> > * For those VRS providers whose current implementations do not support >> IPv6, this can be a big jump to get their solution to support both IPv4 = as >> well as IPv6. Granted, it does not require being dual stacked but rathe= r >> could be two separate servers, each supporting their respective version = of >> IP. This could be a big undertaking just to get IPv6 into the mix. >> > * Another solution could be an IPv4 to IPv6 gateway but that doesn't >> work flawlessly. For example, the gateway can forward the IPv6 SIP mess= age >> to the proper address on the IPv4 network, however, how does it resolve = the >> embedded IPv6 addresses signaled in the SDP? So, for example, consider = two >> RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signal= ing >> is possible for both once the servers for each support that or provide a= IP >> gateway between the two. How is the media going to work? Each of the R= UEs >> is going to provide an IP address in their SDP, one will be IPv4 and the >> other IPv6. How is this going to work without having to anchor all the >> media somewhere? >> > * Are there issues that we need to resolve with NAT64 and/or DNS64? >> > * As I understand it, some mobile devices are already IPv6 but do not >> follow the RFC for embedding an IPv4 address into an IPv6 address. This= is >> going to require special handling to get this to work with such devices = on >> vendors that do not follow the RFC in this regard. >> > >> > Message Waiting Indicator >> > * Some, if not all, of the current implementations of RUE by VRS >> providers, already include means to record video messages and are not al= l >> created the same way. Proprietary methods have been used. The document >> states that MWI is optional but if the ability to leave a message is >> provided then MWI is to be implemented. Since there are proprietary >> solutions, it seems appropriate to me that this should be changed so tha= t >> proprietary solutions and indications can continue to be utilized. >> > >> > >> > I don't believe I have enumerated all the reasons for not including >> requirements for the above but I believe the examples given are sufficie= nt >> to consider. >> > >> > Regards, >> > Eugene Christensen >> > >> > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, >> files or previous e-mail messages attached to it, may contain confidenti= al >> and proprietary information. If you are not the intended recipient, or a >> person responsible for delivering it to the intended recipient, you are >> hereby notified that any disclosure, copying, distribution or use of any= of >> the information contained in or attached to this message is STRICTLY >> PROHIBITED. If you have received this transmission in error, please >> immediately notify me by reply e-mail at echristensen@sorenson.com or by >> telephone at +1 (801) 287-9419, and destroy the original transmission an= d >> its attachments without reading them or saving them to disk. >> > >> > -----Original Message----- >> > From: Rum On Behalf Of Paul Kyzivat >> > Sent: Thursday, August 19, 2021 10:04 AM >> > To: rum@ietf.org >> > Cc: Alexander Ospina ; Isaac Roach < >> IRoach@sorenson.com>; Brian Rosen >> > Subject: [Rum] Action Items from RUM session at IETF 111 >> > >> > [EXTERNAL] >> > >> > The minutes from the RUM session include a number of action items. >> > Specifically, the following people made commitments: >> > >> > Brian Rosen >> > Isaac Roach >> > Alex Ospina >> > >> > Brian is working on an updated version, but it won't include the >> > concerns of the others above if we don't hear from you. Rather than tr= y >> > to summarize those I refer you back to the minutes. You can find them >> at: >> > https://datatracker.ietf.org/doc/minutes-111-rum/ >> > >> > I plan to issue WGLC on the document soon. I will wait one week (until >> > Aug 26). If there hasn't been any followup by then I will ask Brian to >> > issue a version that we can advance to WGLC. >> > >> > Thanks, >> > Paul >> > >> > -- >> > Rum mailing list >> > Rum@ietf.org >> > https://www.ietf.org/mailman/listinfo/rum >> > >> > -- >> > Rum mailing list >> > Rum@ietf.org >> > https://www.ietf.org/mailman/listinfo/rum >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > > --00000000000008f28805ca7b6661 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Aug 26, 2021 at 10:31 AM Olle= E. Johansson <oej@e= dvina.net> wrote:


On 26 Aug 2021,= at 16:17, Roger Slusser <rslusser1096@gmail.com> wrote:

Hello all,
First off these are personal comments and not as a = spokesperson for the VRS provider I work for.=C2=A0

I have to agree right down the line with Eugene Christensen. I have been = a part of this from day one and have been directly involved in the setup an= d execution of the bi-annual Interop conferences and development of the Pro= vider Interoperability Profile.=C2=A0=C2=A0

It is = obvious to me that this RUM RFC will be picked up by the FCC as the new spe= c for the VATRP.
Roger,
With all r= espect. There is a world outside the USA. RFCs are written with global scop= e, not limited to a specific market or group of vendors.
Olle,=C2=A0
I think=C2=A0you may have missed my point = about this targeting=C2=A0a specific industry, namely the VRS industry in t= he US. Also when the FCC mandates support of an RFC they do not specify cus= tom profiles especially in this case. There may be other uses for this out = there but none that are directly or possibly adversely affected.

So let's not kid ourselves or minc= e words about implementations, industry profiles and various services. This= endpoint spec will be terminated by a VRS provider Interpreter station or = proprietary endpoint in 99% of the use cases. By mandating via "MUSTs&= quot; in this RFC, and there are many, it will force the VRS providers to a= bandon current project plans and business=C2=A0goals to turn attention to i= mplementing things in this RFC that have very little value to the Deaf and = HH end users we support. Every provider already has a notification scheme f= or message waiting, most of which is much more elaborate and sophisticated = than MWI, yet this RFC will force=C2=A0less desirable services... why? This= is just an example that has been objected to since day one and yet it stil= l has stuck like glue. Let's not lose focus of the driving force here, = the betterment of the endpoint experience=C2=A0for the Deaf and HH user bas= e.=C2=A0
I think being able to get privacy an= d be able to use all networks, including the old IPv4 networks, is a good e= xperience.

Most providers a= lready support encryption and IPV6 on a limited scope, not necessarily the = way it is defined in RUM spec. Mandating compliance using MUST requires pro= viders to discard sometimes huge amounts of development to change over to w= hat RUM is specifying. The push back is not about doing these things it is = about the loss of time, effort and money to do them in the way RUM mandates= with MUSTs.=C2=A0 =C2=A0
=C2=A0=

I understand this is IETF. I understand this must= have the latest and greatest tech the industry has to offer, but I think t= he driving committee members of this RFC also need to understand the realit= ies of implementation and the hardship this can and will bring to providers= with the "MUSTs". The FCC denies funding for non compliance, the= reality is these "MUSTs" could put providers out of business.=C2= =A0=C2=A0
A MUST in an RFC points to an imple= mentation. It doesn=E2=80=99t provide a profile for a service. If a service= provider only provides IPv4 that=E2=80=99s ok (depending on the customer r= equirements of course). But to be RFC compliant and interoperable, an imple= mentation has to be able to support what=E2=80=99s specified as MUSTs.
<= blockquote type=3D"cite">

I know t= here are heavy hitters in the IETF community on this project. But there are= also founding members of the VRS industry who have offered comments with r= easonable explanations=C2=A0that have been dismissed. After 18 year I belie= ve we know our customer base. The Deaf employees in our companies in market= ing and sales collectively drive=C2=A0our product offerings to best suit th= eir needs because we eat our own dog food.. I would urge this committee to = take long and hard consideration of the experience that in my opinion is be= ing dismissed offhandedly for the sake of new tech that has very little to = do with our customers needs or wants.
IPv6 is= not new tech at this point. SRTP/DTLS is implemented in millions of web br= owsers out there, with many implementations in Open Source. It=E2=80=99s no= t new tech, not at all. In fact I would be surprised if the US FCC does not= require IPv6.=C2=A0

I have been working with socia= l care alarms as well as telephony for deaf and hearing impaired. The users= don=E2=80=99t deserve old technology or a lack of privacy. If you ask them= it would be assumed that you work on all kind of networks - mobile, wifi, = fixed and they trust you to give them privacy. They won=E2=80=99t specify t= hat in technichal terms, it=E2=80=99s just assumed.

/O

I already addressed th= is earlier. It is not that we don't provide encryption, we have settled= on other methods. We have been supporting IPv6 for some time now on a limi= ted basis.=C2=A0=C2=A0

Thanks for your consideration,
Roger Slusser=C2=A0

On = Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson <oej@edvina.net> wrote:
Friends,
This is the IETF after all.

We can=E2=80=99t let any documents be published without IPv6. The problems = you outline here are surely solved in existing implementations of SIP, prop= ably since many years ago. If not, we have work to do.

In addition, RUM services without SRTP/DTLS will be used over any network, = including the Internet, and it is a very bad solution that feels like somet= hing we sold in the SIP world a long time ago. The world has moved since th= en.

I strongly urge that the RUM specs has to require mandatory IPv6 support as= well as SRTP/DTLS encryption.

I would personally go as far as to say that SRTP/DTLS is a MUST and nothing= else is ok, very much like WebRTC.

In regards to proprietary vs open standards, this is again the IETF. We pro= duce open standards and a RUM specification has to point to a SIP SUBSCRIBE= /NOTIFY package for MWI.

Remember that what I=E2=80=99m talking about is documents as specified by t= he IETF. Industry profiles and various services may go other ways, but the = IETF standards has to be up to date with best current practise.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <echristensen@sorenson.com>= wrote:
>
> Brian, Paul thank you for considering the changes that have been broug= ht up to this point.=C2=A0 Leaving things alone with the X-Card, the inclus= ion of the instance-id for location, additions to support notification serv= ices for mobile, etc. are all appreciated.
>
> It is my opinion that we should not include requirements for the follo= wing in the new RUM document.=C2=A0 Here are the reasons that I believe thi= s way.
>
> WebRTC
>
> * While there is an RFC for WebRTC, it doesn't appear that all bro= wsers are following it.=C2=A0 For example, TMMBR is required for WebRTC but= Chrome does not signal it.
> * WebRTC is an audio first implementation.=C2=A0 For VRS, video is the= most important media stream.=C2=A0 It means everything to the deaf or hard= of hearing user.=C2=A0 If video is suffering first in a lossy network, tha= t is a problem for VRS.
> * Some of the VRS providers do not currently support the following ite= ms.=C2=A0 This could pose a significant impact on the VRS providers to get = this implemented.
> o Encryption (DTLS)
> o ICE
> o RTP/RTCP Muxing
>
> IPv6
> * For those VRS providers whose current implementations do not support= IPv6, this can be a big jump to get their solution to support both IPv4 as= well as IPv6.=C2=A0 Granted, it does not require being dual stacked but ra= ther could be two separate servers, each supporting their respective versio= n of IP.=C2=A0 This could be a big undertaking just to get IPv6 into the mi= x.=C2=A0
> * Another solution could be an IPv4 to IPv6 gateway but that doesn'= ;t work flawlessly.=C2=A0 For example, the gateway can forward the IPv6 SIP= message to the proper address on the IPv4 network, however, how does it re= solve the embedded IPv6 addresses signaled in the SDP?=C2=A0 So, for exampl= e, consider two RUEs, one legacy RUE that is using IPv4 and one that is IPv= 6; the signaling is possible for both once the servers for each support tha= t or provide a IP gateway between the two.=C2=A0 How is the media going to = work?=C2=A0 Each of the RUEs is going to provide an IP address in their SDP= , one will be IPv4 and the other IPv6.=C2=A0 How is this going to work with= out having to anchor all the media somewhere?
> * Are there issues that we need to resolve with NAT64 and/or DNS64?=C2= =A0
> * As I understand it, some mobile devices are already IPv6 but do not = follow the RFC for embedding an IPv4 address into an IPv6 address.=C2=A0 Th= is is going to require special handling to get this to work with such devic= es on vendors that do not follow the RFC in this regard.
>
> Message Waiting Indicator
> * Some, if not all, of the current implementations of RUE by VRS provi= ders, already include means to record video messages and are not all create= d the same way.=C2=A0 Proprietary methods have been used.=C2=A0 The documen= t states that MWI is optional but if the ability to leave a message is prov= ided then MWI is to be implemented.=C2=A0 Since there are proprietary solut= ions, it seems appropriate to me that this should be changed so that propri= etary solutions and indications can continue to be utilized.
>
>
> I don't believe I have enumerated all the reasons for not includin= g requirements for the above but I believe the examples given are sufficien= t to consider.
>
> Regards,
> Eugene Christensen
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, f= iles or previous e-mail messages attached to it, may contain confidential a= nd proprietary information. If you are not the intended recipient, or a per= son responsible for delivering it to the intended recipient, you are hereby= notified that any disclosure, copying, distribution or use of any of the i= nformation contained in or attached to this message is STRICTLY PROHIBITED.= If you have received this transmission in error, please immediately notify= me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9= 419, and destroy the original transmission and its attachments without read= ing them or saving them to disk.
>
> -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of Paul Kyzivat
> Sent: Thursday, August 19, 2021 10:04 AM
> To: rum@ietf.org=
> Cc: Alexander Ospina <aospina@aslservices.com>; Isaac Roach <IRoach@sorenson.com>;= Brian Rosen <br@= brianrosen.net>
> Subject: [Rum] Action Items from RUM session at IETF 111
>
> [EXTERNAL]
>
> The minutes from the RUM session include a number of action items. > Specifically, the following people made commitments:
>
> Brian Rosen
> Isaac Roach
> Alex Ospina
>
> Brian is working on an updated version, but it won't include the <= br> > concerns of the others above if we don't hear from you. Rather tha= n try
> to summarize those I refer you back to the minutes. You can find them = at:
> https://datatracker.ietf.org/doc/minutes-111-r= um/
>
> I plan to issue WGLC on the document soon. I will wait one week (until=
> Aug 26). If there hasn't been any followup by then I will ask Bria= n to
> issue a version that we can advance to WGLC.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
<= /blockquote>
--00000000000008f28805ca7b6661-- From nobody Thu Aug 26 12:40:32 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47ECF3A1069 for ; Thu, 26 Aug 2021 12:40:28 -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 a3oi_jYhWWkR for ; Thu, 26 Aug 2021 12:40:21 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 90E003A1067 for ; Thu, 26 Aug 2021 12:40:21 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id e186so5166016iof.12 for ; Thu, 26 Aug 2021 12:40:21 -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=EuMfP65JFs+tK1TxZp6qCCtW0UJOZ7Qxcs9Eg6kWUa4=; b=KnwjlrA0l1O7Cc/fVjXTEkL2dWRMhPqywyNbuqwNWqwlwN0mv6wAEDFyZfiX4UyI7U Dh6POwOjWTC6ZXpMtqEmA5//JGhajJD8G5nRwYccHkF++/z7gM+LWxrw80O6VFWFNKGI yUUBhft4LIso0dexS92P0BHyrF3zaEHXP+RWhW2xCZPgelk3sdAf44wj3wWqHSR8an9h t/Wj4hoYaZhaKkweLL1tRz1f0ZScJ1Zf3Am4pLLA4eMm7uYlrAvOddwlX/oO+kf3gWvY hlpMMH3W7ZwLD8RdfZV+K1wq+7aycIEjqKIjNqEutcF8vPf55B05OtbfxTR7q+coX1v9 DxJg== 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=EuMfP65JFs+tK1TxZp6qCCtW0UJOZ7Qxcs9Eg6kWUa4=; b=IDq/Bo9uP09lFcRxBd4/8Yw3UnfAtrsfiR/Iq/751ShynfIWJeQy9f1+zQzcg+qelk 1xOzdL2TpCGEo7Z+dy1DCiXyR9P+YQdZlvjcPfrW1Zbju3F8ZbCzPqVlynkRbNantiMT jpY6l9D30mVMFEP+IZXtabztB3O7vCBsS+TeINaqfu4kOr/8/ULhS6NmD7nM4qZQa12P mFv0bt8EwO2NmetCVNIyDJdlw4xmP4Ufee6SUZj83YNjzSJKEPujSYw4bjxl8p5MIctz +9vptUcLYe6JXmMh0ON5GtQdfRYFgDUv2xZUZQR0ooN0t5N6/D+JmvJQVXjNHoXnBk+/ SsGA== X-Gm-Message-State: AOAM532wGhpdSAbxhAEhaKTm2GxW8KQL3gmC4Dk69NgMOKsV6NmuQMpE e2HaiHayjhbS5r2L9pnrq+6n0A== X-Google-Smtp-Source: ABdhPJx9JZGXH+nDcFK01FOuhv0H/sowksTgKE/RdXNltP0eDJKsAdA3z8bhj/bfsaiq6K/BEmQgPg== X-Received: by 2002:a02:5241:: with SMTP id d62mr4865224jab.143.1630006820158; Thu, 26 Aug 2021 12:40:20 -0700 (PDT) Received: from smtpclient.apple ([24.154.121.237]) by smtp.gmail.com with ESMTPSA id a14sm2141184iol.24.2021.08.26.12.40.19 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 12:40:19 -0700 (PDT) From: Brian Rosen Message-Id: <3FCB2E62-78B4-480A-BAF4-AE31FE6D6353@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_08DFD87D-7D1A-4C9E-8699-0659B6E169BC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 15:40:16 -0400 In-Reply-To: Cc: "Olle E. Johansson" , Eugene Christensen , "rum@ietf.org" , Paul Kyzivat , Alexander Ospina , Isaac Roach To: Roger Slusser References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 19:40:28 -0000 --Apple-Mail=_08DFD87D-7D1A-4C9E-8699-0659B6E169BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Roger The WHOLE IDEA of rum is a provider independent client. If we can=E2=80=99t build a client that works across any conforming = provider, then the whole project is a failure. That means that any proprietary way of doing something isn=E2=80=99t = acceptable. The spec has to specify a way to build a client that every = server supports. =20 Any standard that arrives when some pre-standard implementations exist = faces this problem. Of course it means changes to those = implementations. We choose to standardize for good reasons, but there = are costs to existing implementations. We shouldn=E2=80=99t make = choices that just make busy work for existing implementations. If it = was the case that all existing implementations did it one way, and the = spec requires another way, we have to have a good technical argument on = why we made a different choice. But when there is no common choice and = every implementation is different from every other one, then we can=E2=80=99= t do that.=20 Also, there are several participants on this list that are anticipating = uses beyond USA VRS. We=E2=80=99ll agree that is the impetus to start = the work, but the goal is a global standard. =20 Brian > On Aug 26, 2021, at 3:30 PM, Roger Slusser = wrote: >=20 >=20 >=20 > On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson > wrote: >=20 >=20 >> On 26 Aug 2021, at 16:17, Roger Slusser > wrote: >>=20 >> Hello all, >> First off these are personal comments and not as a spokesperson for = the VRS provider I work for.=20 >>=20 >> I have to agree right down the line with Eugene Christensen. I have = been a part of this from day one and have been directly involved in the = setup and execution of the bi-annual Interop conferences and development = of the Provider Interoperability Profile. =20 >>=20 >> It is obvious to me that this RUM RFC will be picked up by the FCC as = the new spec for the VATRP.=20 > Roger, > With all respect. There is a world outside the USA. RFCs are written = with global scope, not limited to a specific market or group of vendors. > Olle,=20 > I think you may have missed my point about this targeting a specific = industry, namely the VRS industry in the US. Also when the FCC mandates = support of an RFC they do not specify custom profiles especially in this = case. There may be other uses for this out there but none that are = directly or possibly adversely affected. >=20 >> So let's not kid ourselves or mince words about implementations, = industry profiles and various services. This endpoint spec will be = terminated by a VRS provider Interpreter station or proprietary endpoint = in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there = are many, it will force the VRS providers to abandon current project = plans and business goals to turn attention to implementing things in = this RFC that have very little value to the Deaf and HH end users we = support. Every provider already has a notification scheme for message = waiting, most of which is much more elaborate and sophisticated than = MWI, yet this RFC will force less desirable services... why? This is = just an example that has been objected to since day one and yet it still = has stuck like glue. Let's not lose focus of the driving force here, the = betterment of the endpoint experience for the Deaf and HH user base.=20 > I think being able to get privacy and be able to use all networks, = including the old IPv4 networks, is a good experience. >=20 > Most providers already support encryption and IPV6 on a limited scope, = not necessarily the way it is defined in RUM spec. Mandating compliance = using MUST requires providers to discard sometimes huge amounts of = development to change over to what RUM is specifying. The push back is = not about doing these things it is about the loss of time, effort and = money to do them in the way RUM mandates with MUSTs. =20 >> =20 >>=20 >> I understand this is IETF. I understand this must have the latest and = greatest tech the industry has to offer, but I think the driving = committee members of this RFC also need to understand the realities of = implementation and the hardship this can and will bring to providers = with the "MUSTs". The FCC denies funding for non compliance, the reality = is these "MUSTs" could put providers out of business. =20 > A MUST in an RFC points to an implementation. It doesn=E2=80=99t = provide a profile for a service. If a service provider only provides = IPv4 that=E2=80=99s ok (depending on the customer requirements of = course). But to be RFC compliant and interoperable, an implementation = has to be able to support what=E2=80=99s specified as MUSTs. >>=20 >> I know there are heavy hitters in the IETF community on this project. = But there are also founding members of the VRS industry who have offered = comments with reasonable explanations that have been dismissed. After 18 = year I believe we know our customer base. The Deaf employees in our = companies in marketing and sales collectively drive our product = offerings to best suit their needs because we eat our own dog food.. I = would urge this committee to take long and hard consideration of the = experience that in my opinion is being dismissed offhandedly for the = sake of new tech that has very little to do with our customers needs or = wants. > IPv6 is not new tech at this point. SRTP/DTLS is implemented in = millions of web browsers out there, with many implementations in Open = Source. It=E2=80=99s not new tech, not at all. In fact I would be = surprised if the US FCC does not require IPv6.=20 >=20 > I have been working with social care alarms as well as telephony for = deaf and hearing impaired. The users don=E2=80=99t deserve old = technology or a lack of privacy. If you ask them it would be assumed = that you work on all kind of networks - mobile, wifi, fixed and they = trust you to give them privacy. They won=E2=80=99t specify that in = technichal terms, it=E2=80=99s just assumed. >=20 > /O >=20 > I already addressed this earlier. It is not that we don't provide = encryption, we have settled on other methods. We have been supporting = IPv6 for some time now on a limited basis. =20 >>=20 >> Thanks for your consideration, >> Roger Slusser=20 >>=20 >> On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson > wrote: >> Friends, >> This is the IETF after all.=20 >>=20 >> We can=E2=80=99t let any documents be published without IPv6. The = problems you outline here are surely solved in existing implementations = of SIP, propably since many years ago. If not, we have work to do. >>=20 >> In addition, RUM services without SRTP/DTLS will be used over any = network, including the Internet, and it is a very bad solution that = feels like something we sold in the SIP world a long time ago. The world = has moved since then. >>=20 >> I strongly urge that the RUM specs has to require mandatory IPv6 = support as well as SRTP/DTLS encryption. >>=20 >> I would personally go as far as to say that SRTP/DTLS is a MUST and = nothing else is ok, very much like WebRTC. >>=20 >> In regards to proprietary vs open standards, this is again the IETF. = We produce open standards and a RUM specification has to point to a SIP = SUBSCRIBE/NOTIFY package for MWI.=20 >>=20 >> Remember that what I=E2=80=99m talking about is documents as = specified by the IETF. Industry profiles and various services may go = other ways, but the IETF standards has to be up to date with best = current practise. >>=20 >> Cheers, >> /O >>=20 >> > On 25 Aug 2021, at 20:58, Eugene Christensen = > wrote: >> >=20 >> > Brian, Paul thank you for considering the changes that have been = brought up to this point. Leaving things alone with the X-Card, the = inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated. >> >=20 >> > It is my opinion that we should not include requirements for the = following in the new RUM document. Here are the reasons that I believe = this way. >> >=20 >> > WebRTC >> >=20 >> > * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it. For example, TMMBR is required for WebRTC = but Chrome does not signal it. >> > * WebRTC is an audio first implementation. For VRS, video is the = most important media stream. It means everything to the deaf or hard of = hearing user. If video is suffering first in a lossy network, that is a = problem for VRS. >> > * Some of the VRS providers do not currently support the following = items. This could pose a significant impact on the VRS providers to get = this implemented. >> > o Encryption (DTLS) >> > o ICE >> > o RTP/RTCP Muxing >> >=20 >> > IPv6=20 >> > * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6. Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP. This could be a big undertaking just to get = IPv6 into the mix. =20 >> > * Another solution could be an IPv4 to IPv6 gateway but that = doesn't work flawlessly. For example, the gateway can forward the IPv6 = SIP message to the proper address on the IPv4 network, however, how does = it resolve the embedded IPv6 addresses signaled in the SDP? So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two. How is the = media going to work? Each of the RUEs is going to provide an IP address = in their SDP, one will be IPv4 and the other IPv6. How is this going to = work without having to anchor all the media somewhere? >> > * Are there issues that we need to resolve with NAT64 and/or DNS64? = =20 >> > * As I understand it, some mobile devices are already IPv6 but do = not follow the RFC for embedding an IPv4 address into an IPv6 address. = This is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard. >> >=20 >> > Message Waiting Indicator >> > * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way. Proprietary methods have been used. The = document states that MWI is optional but if the ability to leave a = message is provided then MWI is to be implemented. Since there are = proprietary solutions, it seems appropriate to me that this should be = changed so that proprietary solutions and indications can continue to be = utilized. >> >=20 >> >=20 >> > I don't believe I have enumerated all the reasons for not including = requirements for the above but I believe the examples given are = sufficient to consider. >> >=20 >> > Regards, >> > Eugene Christensen >> >=20 >> > CONFIDENTIALITY NOTICE. This e-mail transmission, and any = documents, files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by = telephone at +1 (801) 287-9419, and destroy the original transmission = and its attachments without reading them or saving them to disk. >> >=20 >> > -----Original Message----- >> > From: Rum > On = Behalf Of Paul Kyzivat >> > Sent: Thursday, August 19, 2021 10:04 AM >> > To: rum@ietf.org >> > Cc: Alexander Ospina >; Isaac Roach >; Brian Rosen > >> > Subject: [Rum] Action Items from RUM session at IETF 111 >> >=20 >> > [EXTERNAL]=20 >> >=20 >> > The minutes from the RUM session include a number of action items.=20= >> > Specifically, the following people made commitments: >> >=20 >> > Brian Rosen >> > Isaac Roach >> > Alex Ospina >> >=20 >> > Brian is working on an updated version, but it won't include the=20 >> > concerns of the others above if we don't hear from you. Rather than = try=20 >> > to summarize those I refer you back to the minutes. You can find = them at: >> > https://datatracker.ietf.org/doc/minutes-111-rum/ = >> >=20 >> > I plan to issue WGLC on the document soon. I will wait one week = (until=20 >> > Aug 26). If there hasn't been any followup by then I will ask Brian = to=20 >> > issue a version that we can advance to WGLC. >> >=20 >> > Thanks, >> > Paul >> >=20 >> > --=20 >> > Rum mailing list >> > Rum@ietf.org >> > https://www.ietf.org/mailman/listinfo/rum = >> >=20 >> > --=20 >> > Rum mailing list >> > Rum@ietf.org >> > https://www.ietf.org/mailman/listinfo/rum = >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum = >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_08DFD87D-7D1A-4C9E-8699-0659B6E169BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Roger

The = WHOLE IDEA of rum is a provider independent client.

If we can=E2=80=99t = build a client that works across any conforming provider, then the whole = project is a failure.

That means that any proprietary way of doing something = isn=E2=80=99t acceptable.  The spec has to specify a way to build a = client that every server supports.  

Any standard that arrives when some = pre-standard implementations exist faces this problem.  Of course = it means changes to those implementations.  We choose to = standardize for good reasons, but there are costs to existing = implementations.  We shouldn=E2=80=99t make choices that just make = busy work for existing implementations.  If it was the case that = all existing implementations did it one way, and the spec requires = another way, we have to have a good technical argument on why we made a = different choice.  But when there is no common choice and every = implementation is different from every other one, then we can=E2=80=99t = do that. 

Also, there are several participants on this list that are = anticipating uses beyond USA VRS.  We=E2=80=99ll agree that is the = impetus to start the work, but the goal is a global standard. =  

Brian


On Aug = 26, 2021, at 3:30 PM, Roger Slusser <rslusser1096@gmail.com> wrote:



On Thu, Aug 26, 2021 at = 10:31 AM Olle E. Johansson <oej@edvina.net> wrote:


On 26 Aug 2021, at 16:17, Roger = Slusser <rslusser1096@gmail.com> wrote:

Hello all,
First = off these are personal comments and not as a spokesperson for the VRS = provider I work for. 

I have to agree right down the line with Eugene Christensen. = I have been a part of this from day one and have been directly involved = in the setup and execution of the bi-annual Interop conferences and = development of the Provider Interoperability = Profile.  

It is obvious to me that this RUM RFC will be picked up by = the FCC as the new spec for the VATRP. 
Roger,
With all respect. There is a world outside = the USA. RFCs are written with global scope, not limited to a specific = market or group of vendors.
Olle, 
I think you may have = missed my point about this targeting a specific industry, namely = the VRS industry in the US. Also when the FCC mandates support of an RFC = they do not specify custom profiles especially in this case. There may = be other uses for this out there but none that are directly or possibly = adversely affected.

So let's not kid ourselves or = mince words about implementations, industry profiles and various = services. This endpoint spec will be terminated by a VRS provider = Interpreter station or proprietary endpoint in 99% of the use cases. By = mandating via "MUSTs" in this RFC, and there are many, it will force the = VRS providers to abandon current project plans and business goals = to turn attention to implementing things in this RFC that have very = little value to the Deaf and HH end users we support. Every provider = already has a notification scheme for message waiting, most of which is = much more elaborate and sophisticated than MWI, yet this RFC will = force less desirable services... why? This is just an example that = has been objected to since day one and yet it still has stuck like glue. = Let's not lose focus of the driving force here, the betterment of the = endpoint experience for the Deaf and HH user = base. 
I think being able to get = privacy and be able to use all networks, including the old IPv4 = networks, is a good experience.

Most providers already support = encryption and IPV6 on a limited scope, not necessarily the way it is = defined in RUM spec. Mandating compliance using MUST requires providers = to discard sometimes huge amounts of development to change over to what = RUM is specifying. The push back is not about doing these things it is = about the loss of time, effort and money to do them in the way RUM = mandates with MUSTs.   
 

I understand this is IETF. I understand this must have the = latest and greatest tech the industry has to offer, but I think the = driving committee members of this RFC also need to understand the = realities of implementation and the hardship this can and will bring to = providers with the "MUSTs". The FCC denies funding for non compliance, = the reality is these "MUSTs" could put providers out of = business.  
A MUST in an RFC = points to an implementation. It doesn=E2=80=99t provide a profile for a = service. If a service provider only provides IPv4 that=E2=80=99s ok = (depending on the customer requirements of course). But to be RFC = compliant and interoperable, an implementation has to be able to support = what=E2=80=99s specified as MUSTs.

I know there are heavy = hitters in the IETF community on this project. But there are also = founding members of the VRS industry who have offered comments with = reasonable explanations that have been dismissed. After 18 year I = believe we know our customer base. The Deaf employees in our companies = in marketing and sales collectively drive our product offerings to = best suit their needs because we eat our own dog food.. I would urge = this committee to take long and hard consideration of the experience = that in my opinion is being dismissed offhandedly for the sake of new = tech that has very little to do with our customers needs or = wants.
IPv6 is not new tech at this point. = SRTP/DTLS is implemented in millions of web browsers out there, with = many implementations in Open Source. It=E2=80=99s not new tech, not at = all. In fact I would be surprised if the US FCC does not require = IPv6. 

I have been working with social care = alarms as well as telephony for deaf and hearing impaired. The users = don=E2=80=99t deserve old technology or a lack of privacy. If you ask = them it would be assumed that you work on all kind of networks - mobile, = wifi, fixed and they trust you to give them privacy. They won=E2=80=99t = specify that in technichal terms, it=E2=80=99s just assumed.

/O

I already addressed this earlier. It is = not that we don't provide encryption, we have settled on other methods. = We have been supporting IPv6 for some time now on a limited = basis.  

Thanks for your = consideration,
Roger Slusser 

On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson = <oej@edvina.net> wrote:
Friends,
This is = the IETF after all. 

We can=E2=80=99t let any documents be = published without IPv6. The problems you outline here are surely solved = in existing implementations of SIP, propably since many years ago. If = not, we have work to do.

In addition, RUM = services without SRTP/DTLS will be used over any network, including the = Internet, and it is a very bad solution that feels like something we = sold in the SIP world a long time ago. The world has moved since = then.

I strongly urge that the RUM specs = has to require mandatory IPv6 support as well as SRTP/DTLS = encryption.

I would personally go as far as = to say that SRTP/DTLS is a MUST and nothing else is ok, very much like = WebRTC.

In regards to proprietary vs open = standards, this is again the IETF. We produce open standards and a RUM = specification has to point to a SIP SUBSCRIBE/NOTIFY package for = MWI. 

Remember that what I=E2=80=99m talking about is documents as = specified by the IETF. Industry profiles and various services may go = other ways, but the IETF standards has to be up to date with best = current practise.

Cheers,
/O
> On 25 Aug 2021, at 20:58, Eugene = Christensen <echristensen@sorenson.com> wrote:
> 
> Brian, Paul thank you for considering the changes that = have been brought up to this point.  Leaving things alone with the = X-Card, the inclusion of the instance-id for location, additions to = support notification services for mobile, etc. are all appreciated.
> 
> It is my opinion that we should not include requirements = for the following in the new RUM document.  Here are the reasons = that I believe this way.
> 
> = WebRTC
> 
> * While = there is an RFC for WebRTC, it doesn't appear that all browsers are = following it.  For example, TMMBR is required for WebRTC but Chrome = does not signal it.
> * WebRTC is an audio first = implementation.  For VRS, video is the most important media = stream.  It means everything to the deaf or hard of hearing = user.  If video is suffering first in a lossy network, that is a = problem for VRS.
> * Some of the VRS providers do not = currently support the following items.  This could pose a = significant impact on the VRS providers to get this implemented.
> o Encryption (DTLS)
> o ICE
> o RTP/RTCP Muxing
> 
> = IPv6 
>= * For those VRS providers whose current implementations do not support = IPv6, this can be a big jump to get their solution to support both IPv4 = as well as IPv6.  Granted, it does not require being dual stacked = but rather could be two separate servers, each supporting their = respective version of IP.  This could be a big undertaking just to = get IPv6 into the mix.  
> * = Another solution could be an IPv4 to IPv6 gateway but that doesn't work = flawlessly.  For example, the gateway can forward the IPv6 SIP = message to the proper address on the IPv4 network, however, how does it = resolve the embedded IPv6 addresses signaled in the SDP?  So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two.  How is = the media going to work?  Each of the RUEs is going to provide an = IP address in their SDP, one will be IPv4 and the other IPv6.  How = is this going to work without having to anchor all the media = somewhere?
> * Are there issues that we need to resolve = with NAT64 and/or DNS64?  
> * As I = understand it, some mobile devices are already IPv6 but do not follow = the RFC for embedding an IPv4 address into an IPv6 address.  This = is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard.
> 
> Message Waiting Indicator
> * Some, if = not all, of the current implementations of RUE by VRS providers, already = include means to record video messages and are not all created the same = way.  Proprietary methods have been used.  The document states = that MWI is optional but if the ability to leave a message is provided = then MWI is to be implemented.  Since there are proprietary = solutions, it seems appropriate to me that this should be changed so = that proprietary solutions and indications can continue to be = utilized.
> 
> 
> I don't = believe I have enumerated all the reasons for not including requirements = for the above but I believe the examples given are sufficient to = consider.
> 
> = Regards,
> Eugene Christensen
> 
> = CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail = at echristensen@sorenson.com or by telephone at +1 (801) = 287-9419, and destroy the original transmission and its attachments = without reading them or saving them to disk.
> 
> = -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of Paul Kyzivat
> Sent: Thursday, August 19, 2021 10:04 AM
> To: rum@ietf.org
> Cc: Alexander Ospina = <aospina@aslservices.com>; Isaac Roach <IRoach@sorenson.com>; Brian Rosen <br@brianrosen.net>
> Subject: [Rum] = Action Items from RUM session at IETF 111
> 
> = [EXTERNAL] 
> 
> The minutes from the RUM session include a number of = action items. 
> Specifically, the following people made commitments:
> 
> Brian Rosen
> Isaac Roach
> Alex Ospina
> 
> Brian = is working on an updated version, but it won't include the 
> = concerns of the others above if we don't hear from you. Rather than = try 
> = to summarize those I refer you back to the minutes. You can find them = at:
> https://datatracker.ietf.org/doc/minutes-111-rum/
> 
> I plan to issue WGLC on the document soon. I will wait = one week (until 
> Aug 26). If there hasn't been any followup by then I = will ask Brian to 
> issue a version that we can advance to WGLC.
> 
>       Thanks,
> =      Paul
> 
> -- 
> Rum = mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
> 
> -- 
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
-- 
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_08DFD87D-7D1A-4C9E-8699-0659B6E169BC-- From nobody Thu Aug 26 13:08:08 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8ED3A09A5 for ; Thu, 26 Aug 2021 13:08:05 -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, 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=mitre.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 Z60eEK1p9DBB for ; Thu, 26 Aug 2021 13:07:59 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 623B13A099E for ; Thu, 26 Aug 2021 13:07:59 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 6262D6C0004; Thu, 26 Aug 2021 16:07:56 -0400 (EDT) Received: from smtprhmv1.mitre.org (unknown [10.20.200.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id BA97B6C0005; Thu, 26 Aug 2021 16:07:55 -0400 (EDT) Received: from mwfesmtp-mgt.mitre.org (mwfesmtp-in.mitre.org [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id 2C7C580DCFE; Thu, 26 Aug 2021 16:07:55 -0400 (EDT) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4GwYmq4GkNz29ptK; Thu, 26 Aug 2021 20:04:14 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2109.outbound.protection.outlook.com [104.47.64.109]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4GwYhX67RMz29pxl; Thu, 26 Aug 2021 20:04:11 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=g5FlP0y32HFnBhN/3ETO7T9xk8j6qP9miVQA+uYYmoJqShr2bo8Ey/EBxkc1ine4El+6r5CnlpWItfj2oCKFCmsNHgh4/AfJUMFJ08r2ClkDSwhQXpYAexQS1LpmY1Bgj+TyiFLuq06cI3OAB21zhCRVrN1semKEsAAjVg8gUguiDzs25hUz6+p8t9lWjKuedYoaCkO/CJm/3HdLdOlz+B4kyb5cZ6NwwggVu+JXI2ATFx79ce0ng75Qek/2VpfsxKz04G+/RXL0DLF1tPhZRf/rzR3YwxRIDY3bYD1wEwJbJ+H21JlFOT/xlRJZd6BHDMFw7Qwtic0+qf9c/dptpw== 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=BalZWx01D+dF2KLRBgV7VT8YAk444eaE9JZZf/wW/7U=; b=PaLfpOE5ks3JlshjB1zs5J5fNGzw/Q55NsiYEBED0fULWqPFl56drPwM4Kym5epoQA51ZdZYbcw5OfDDzs4DTbdSnH6DGIwGzIKdZKD8tGIbZ/NAUg/g7b8w3xA2tq9jmckZPeaDPOHdtm2V/pzjeAfBS90+JRkdg+s5b7yWSUebLZE4ZtNPIJCuVpGJMVoRauqT7N9WD7uZMwk95bMbDbJxQLccbICJT08ytWzMB7ezM39G7/9X1+YRNhx0Yw38qIltGvzTluG4jkQRy5GyZbWfUuvljntB7xKTKfQvz+ZUIDm05gAnJq/yPgmDPwaRAqzz384+7M5mSPXshAdXXg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from MN2PR09MB5979.namprd09.prod.outlook.com (2603:10b6:208:219::13) by BLAPR09MB7297.namprd09.prod.outlook.com (2603:10b6:208:2ad::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 26 Aug 2021 20:04:11 +0000 Received: from MN2PR09MB5979.namprd09.prod.outlook.com ([fe80::d2:9ef2:376a:e94d]) by MN2PR09MB5979.namprd09.prod.outlook.com ([fe80::d2:9ef2:376a:e94d%2]) with mapi id 15.20.4436.027; Thu, 26 Aug 2021 20:04:11 +0000 From: Matthew H Garber To: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0 Thread-Index: AQHXmnV5lmYuxR3n50qcMACkrLFa3KuF9nQAgAAx5mg= Date: Thu, 26 Aug 2021 20:04:10 +0000 Message-ID: References: <2252_1629994592_6127BE5A_2252_276_1_f921b649-c77a-64df-6ece-644d905013e0@alum.mit.edu> In-Reply-To: <2252_1629994592_6127BE5A_2252_276_1_f921b649-c77a-64df-6ece-644d905013e0@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=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3e24c825-e189-44f8-0503-08d968ccab9b x-ms-traffictypediagnostic: BLAPR09MB7297: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fjom0pGgfOw8+xJ17uZwjauPcjiGRT4dFmieYlw8hePyTPy8c0k/fycQkUQ3ACW+XI83oyANgb+Vg3kEyVm+qUjYb4NWjFynQbsfyeqzlGPqNcC1lSAwmsaLLfKHjNNHc2IyJCpxAlelFjjpxm0GvKYDeHr2KuNXtJrNeBtmpe02j4+G0FCEPWKcdcKJMRWV7KZ83CjWtRvka6EQHZ8ThCxKC7ybJfoAJaDNfPW29ey5ZvLNbQLb8SjksQB3Mi0VILpy4NhmXmTmYoTzXTDNyvs9LPc8ZZfL/eLElkQCCe2Okf2PmQKpzSHNZ+XLODnWo6NlYOtmQNR19JdudxbNZIA4gE5cnkaPi+HZ+ONtKRC8y2rRDpcIhODcqdxBXbtbCiPYnzC8lk//Z5tjlD1MAgsi11doJhb7jbla1OrEtC1V9+tmKyltZktiITNcj8VRzs8xFhKqXLiBMTsj5SAtGzRkafwB2gzb7INRK2/f+SA2xV9dc0sX72daXZrZeRWf2C2kQQ5yvpmu1rrwNSDONeElaj1nPBUUL1E6M+4BKJU7Y1cSXwkphG19P3IMIpUSl6+bR4s2Y1mV40XSmxlWwE6lrFFVJnRwCtB/goV0+NlEuFEYIw2OYG2ZcCScT2p+x5NdfQtdq8YxZwgxaoR3+PKxAKA19H1/c3LFnO94nYjRnP6YwBtLxVATTGQlKePMkjqvr5LQBD9dKEIkCS0BHxPjmFH3ZxvE/9WV3kYLpXckTrs7Kxyw+Wu4OLl/V+VAbNWmm0ADRq6kKWF6SYZifE4JFGUVFSvmI2GXYFK4tko= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5979.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(136003)(376002)(39850400004)(346002)(122000001)(66476007)(478600001)(66556008)(38100700002)(86362001)(66946007)(66446008)(38070700005)(5660300002)(8936002)(52536014)(64756008)(966005)(76116006)(8676002)(7696005)(55016002)(186003)(71200400001)(166002)(26005)(9686003)(2906002)(110136005)(33656002)(83380400001)(316002)(53546011)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?SA7R89vOFNvoBADSQ1d4aAHwraHB2GgwN0KJF7PPRsSHo1bTGdP/h0hq?= =?Windows-1252?Q?46OmT+A4w0Mh0BxDnSe5gRCj7LlbxJzWK5PivdxC326tRfbTJk+09n3P?= =?Windows-1252?Q?f0khDQ+wMAyW5+dxYpb3mUA8U3DtEL7fySZAhqb/UVLyfDcZmcL+5BHF?= =?Windows-1252?Q?eKNtGeFSqOKJ7/DkSewDMwwRQC7fYbkooaFSu9CzpOQFy72t81HiRxzq?= =?Windows-1252?Q?OPgciYtUbMC9bfuBlxTvAWPgjnX5ba7ym6/aFljR1Cin2t1gJzRXnBXN?= =?Windows-1252?Q?NiUQM8XDlNxk2saj9PCBuZXChGVaen6ns6Vi4G0FREmgyQsv4R+8WqTV?= =?Windows-1252?Q?Jg4/XLsvEbgFWHilQQXNtMNtoG3RsnQtgP2Kgws6k6ZPa6nTsHZy6kUs?= =?Windows-1252?Q?bh0rAo8SEuaF09hIyllBJGsflIeFoBVKK2eqZmHYU1lGFx7hQ79N/0/o?= =?Windows-1252?Q?E89QfWsCdKFiTuHpl4WunQZuWcg84ECVI3/gcHIj5DZLJqtq3nU9HUmx?= =?Windows-1252?Q?dQAHhYWROH9olG/rsShVD4Gv95dKK/3+3iMii7GLQUfMcHbKTYC7h+gQ?= =?Windows-1252?Q?qqsl2sQztl/Nj3YticRLddwM41+Ujbe+ScTyqwZEeE9bSMJwdBhVGJth?= =?Windows-1252?Q?e5wJWEfLHlpauICJlQB7uskCrAuMjuLqA5JyWj6bTWaQq2/NVoO1O0gR?= =?Windows-1252?Q?tL+3LBLcULswn5ZxrsHpvg0QPHluJ1vc5P+Yu4G2O64SlYorLBwLY5j3?= =?Windows-1252?Q?hkmCHQUju50k0BQ9oh/5lOfUATeRYIfWBVW5Ow/k/B9141eyWUecBHWI?= =?Windows-1252?Q?hTMpte2vbQn8bbSbDhsVvcMXfXoEuwuS0hY1iNTXNEPttFE5QVAGELNQ?= =?Windows-1252?Q?l0wz89n75Gy0LIiiUDpRh3g+319GlS9hZ88LL1UiF+oEj+x9o3+iV9d6?= =?Windows-1252?Q?tPjEUTItnUYZtqBaLZouGwShkde3AohyRgcLeWt5BuidOkz4uw+kt32T?= =?Windows-1252?Q?JuM6YPupCUHHBiWT1Vxzj/f/Mixd7epLAtHTaokQNHWl3igjxfyOa+y3?= =?Windows-1252?Q?dnKH1k2q9f4BQJJ0MEmY1uJjBjS1wO4cYK9iq6tcp1eCWXphb2s+mnCN?= =?Windows-1252?Q?ps7CruEozQmWp0DOzx2yLl4bVcODo07K9+x7zyOQc0XrU4SHH+17DxAO?= =?Windows-1252?Q?91yBKKwI0huSPzL+t/ID1pzXcPokbi/hKHlRfTa2jOgoXc7QfpFjqpeX?= =?Windows-1252?Q?afCb3E0rjWWh41bV/BhSBzZG98Xf8eeVQu6o39cGpxQQFiStei7RwJXo?= =?Windows-1252?Q?uwmvp7AoxJfr1ZwqdchPbpUekzUE14p6faYiNVSrBRK5IPcoUmGPe/vS?= =?Windows-1252?Q?/9xy5EVoJiWjc2r2MyjY0hvziE85cSSwDh7gvSqpMCKXfnxBhcG+7U9T?= =?Windows-1252?Q?k5brreinysLeFiFuN97AKA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR09MB5979FFB4D4184FDB7AB5C12BA5C79MN2PR09MB5979namp_" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5979.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3e24c825-e189-44f8-0503-08d968ccab9b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 20:04:10.9663 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7297 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=BTxNELhf; bh=BalZWx01D+dF2KLRBgV7VT8YAk444eaE9JZZf/wW/7U=; b=cwkXPNnsKQIRC2h1ZMDNDcQ3nq2V5R2cvFwX/PY2tAXtQwUAxnbv+5HeWZ9C10BEH1Nz5uAWNo35pHoI49+KCKNU/O4E0QfoTP6G+iIj5xuelg9tP4KgNg0vDfbcc7SBuyTGPXgylfCWYGjPOV9YeiaQr7EZPXpJfg5qfFApbEI= Archived-At: Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 20:08:06 -0000 --_000_MN2PR09MB5979FFB4D4184FDB7AB5C12BA5C79MN2PR09MB5979namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Pulling out Paul=92s question (and thanks for the welcome!): >While building this implementation have you come across any places where >you think changes to the spec would be advantageous? MITRE is committed to supporting the spec however it comes out, so we=92ll = work to the final language, wherever it ends up. As an individual who is primarily a web developer/data engineer, I think al= lowing direct WebRTC connections would be very forward looking w.r.t. extan= t library support and the kind of software engineering talent available to = hire in the future, but I understand this group has reasons for not wanting= to do that at this time. >I see that the RTT presents difficulties. Do you have any thoughts on >how to ease that? This is due to our technology choice =96 web applications generally don=92t= know how to, nor need to, speak T.140; most folks would pick up a library = like socket.io to handle this unless they had a specific use case not to. T= he reason we selected the Janus gateway is that it=92s the only fully open = source server side component to attempt to currently support it (Asterisk d= eprecated this when they changed SIP libraries). Any solution I have person= ally would involve moving the transcoding to the data center, which I think= is outside the scope here =96 but that would allow more compatibility with= current web technology stacks. Other than that, a specialist in this could= try adding features to a websocket library and/or create a transcoding lib= rary, but those are both fairly heavy lifts. >I'm guessing that you can't yet interoperate with the existing US VRS >providers production networks. Have you built your own provider server >that accepts calls from your RUE? Can it connect to and interoperate >with real providers? We have a SIP server we=92ve used for interoperability in the past with our= Windows client, which has some inherited design choices that make full RUE= compliance difficult. We=92ve used this to make calls with the WebRTC clie= nt, though we have to work at reverse engineering Google=92s intentional de= cision to exclude the proprietary H.264 codec from Electron due to licensin= g concerns before we can expect a call to succeed (which should be fine for= non-commercial purposes, or we can try the openH264 codec and see how comp= atible it is). Calls with the optional VP8 client :should: work, though we= =92d have to try it to see if that was the case. -Matt From: Rum on behalf of Paul Kyzivat Date: Thursday, August 26, 2021 at 12:18 PM To: rum@ietf.org Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0 Matt, Welcome to the RUM WG! (I don't recall seeing you post here before.) On 8/26/21 8:38 AM, Matthew H Garber wrote: > Good morning all, > > Note: This is a second notice of the WebRTC VATRP v1.0 release and is > intended for a broader audience than the previous email Thank you for publicizing this. "Running Code" is huge in building support for publishing an RFC. Also, implementina a spec almost always ferrets out issues. > MITRE has released the 1.0 version of a WebRTC based RUE client to the > public ACE Github, located > athttps://github.com/mitrefccace/fcc-vatrp-webrtc > . This client has a > communications driver for using the Janus Media Server from Meetecho as > a gateway to convert WebRTC-based messages to RTP/SRTP. It will also > communicate with a SIP server configured to receive WebRTC messages > directly. > > The release notes for this application are > athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_= WebRTC_VATRPv1-0_PR_21-1891.docx > . > There are known defects that prevent full RUE compliance outlined in the > release notes,butMITRE isplanningfollow-on releases to address these and > any other discrepancies with future revisions to the working draft. Our > intent is to deliver an open source client that is 100% compliant with > the final RUM-RUE language. While building this implementation have you come across any places where you think changes to the spec would be advantageous? I see that the RTT presents difficulties. Do you have any thoughts on how to ease that? > A release build is available > forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/release= s/tag/v1.0 > . > > We are actively looking for partners for testing interoperability with > this client =96 if you have an implementation you=92d like to try out, > please don=92t hesitate to reach out to me and we=92ll work out a timefra= me. I'm guessing that you can't yet interoperate with the existing US VRS providers production networks. Have you built your own provider server that accepts calls from your RUE? Can it connect to and interoperate with real providers? Thanks, Paul -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum --_000_MN2PR09MB5979FFB4D4184FDB7AB5C12BA5C79MN2PR09MB5979namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Pulling out Paul=92s question (and thanks for the we= lcome!):

 

>While building this implementation have you come= across any places where
>you think changes to the spec would be advantageous?

MITRE is committed to supporting the spec however it= comes out, so we=92ll work to the final language, wherever it ends up.

 

As an individual who is primarily a web developer/da= ta engineer, I think allowing direct WebRTC connections would be very forwa= rd looking w.r.t. extant library support and the kind of software engineeri= ng talent available to hire in the future, but I understand this group has reasons for not wanting to do that= at this time.


>I see that the RTT presents difficulties. Do you have any thoughts on <= br> >how to ease that?

 

This is due to our technology choice =96 web applica= tions generally don=92t know how to, nor need to, speak T.140; most folks w= ould pick up a library like socket.io to handle this unless they had a spec= ific use case not to. The reason we selected the Janus gateway is that it=92s the only fully open source server side co= mponent to attempt to currently support it (Asterisk deprecated this when t= hey changed SIP libraries). Any solution I have personally would involve mo= ving the transcoding to the data center, which I think is outside the scope here =96 but that would allow more comp= atibility with current web technology stacks. Other than that, a specialist= in this could try adding features to a websocket library and/or create a t= ranscoding library, but those are both fairly heavy lifts.

 

>I'm guessing that you can't yet interoperate wit= h the existing US VRS
>providers production networks. Have you built your own provider server =
>that accepts calls from your RUE? Can it connect to and interoperate >with real providers?

 

We have a SIP server we=92ve used for interoperabili= ty in the past with our Windows client, which has some inherited design cho= ices that make full RUE compliance difficult. We=92ve used this to make cal= ls with the WebRTC client, though we have to work at reverse engineering Google=92s intentional decision to exclude = the proprietary H.264 codec from Electron due to licensing concerns before = we can expect a call to succeed (which should be fine for non-commercial pu= rposes, or we can try the openH264 codec and see how compatible it is). Calls with the optional VP8 client :s= hould: work, though we=92d have to try it to see if that was the case.=

 

-Matt

 

From: Rum <rum-bounces= @ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Thursday, August 26, 2021 at 12:18 PM
To: rum@ietf.org <rum@ietf.org>
Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0

Matt,

Welcome to the RUM WG! (I don't recall seeing you post here before.)

On 8/26/21 8:38 AM, Matthew H Garber wrote:
> Good morning all,
>
> Note: This is a second notice of the WebRTC VATRP v1.0 release and is =
> intended for a broader audience than the previous email

Thank you for publicizing this. "Running Code" is huge in buildin= g
support for publishing an RFC. Also, implementina a spec almost always
ferrets out issues.

> MITRE has released the 1.0 version of a WebRTC based RUE client to the=
> public ACE Github, located
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc
> <https:= //github.com/mitrefccace/fcc-vatrp-webrtc>. This client has a
> communications driver for using the Janus Media Server from Meetecho a= s
> a gateway to convert WebRTC-based messages to RTP/SRTP. It will also <= br> > communicate with a SIP server configured to receive WebRTC messages > directly.
>
> The release notes for this application are
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_T= RS_WebRTC_VATRPv1-0_PR_21-1891.docx
> <https://github.com/mitref= ccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.d= ocx>.
> There are known defects that prevent full RUE compliance outlined in t= he
> release notes,butMITRE isplanningfollow-on releases to address these a= nd
> any other discrepancies with future revisions to the working draft. Ou= r
> intent is to deliver an open source client that is 100% compliant with=
> the final RUM-RUE language.

While building this implementation have you come across any places where you think changes to the spec would be advantageous?

I see that the RTT presents difficulties. Do you have any thoughts on
how to ease that?

> A release build is available
> forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/rele= ases/tag/v1.0
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1= .0>.
>
> We are actively looking for partners for testing interoperability with=
> this client =96 if you have an implementation you=92d like to try out,=
> please don=92t hesitate to reach out to me and we=92ll work out a time= frame.

I'm guessing that you can't yet interoperate with the existing US VRS
providers production networks. Have you built your own provider server
that accepts calls from your RUE? Can it connect to and interoperate
with real providers?

        Thanks,
        Paul

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/= mailman/listinfo/rum

--_000_MN2PR09MB5979FFB4D4184FDB7AB5C12BA5C79MN2PR09MB5979namp_-- From nobody Thu Aug 26 13:16:20 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C7373A0AA0 for ; Thu, 26 Aug 2021 13:16:17 -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 2WNAdMWVMJ00 for ; Thu, 26 Aug 2021 13:16:11 -0700 (PDT) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 AA0CA3A0A9D for ; Thu, 26 Aug 2021 13:16:11 -0700 (PDT) Received: by mail-il1-x12f.google.com with SMTP id j15so4581717ila.1 for ; Thu, 26 Aug 2021 13:16:11 -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=k+71kH9KFYEOOtH3o9g/LIHxrk1l75QzCdUt2YTAluk=; b=f1QI+AtoPxzPEkBBznPeD7+w2L5WtDKc2uEU6piZTJzelq6A0Tx5vUV9NwY9er8io/ DaQ0eUY/Bgz0Z6zZiVTtmUeUxaIsjfmpIeKFocHxqYSgHXHKc9GtsUszWXyM4y8kCGFC nPzgOyb9IkAIv9kxKh6rxdur3jmOmf5F29FvmRCXeA2fwnteoVl0eZEges7sCXxTvv/L 3yZ7H281ol7T+W2TD4ab2gSi2s4z9yGr5RxgY1SIg0xcXPJ96qifEc9p/599TK/+TCuY bxxAGFsKbIniztsX6nlg10Jj0Xev/laMln80qezR8GtVxoQOK3gikRgs2N4CPy5ot7bQ g+Pw== 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=k+71kH9KFYEOOtH3o9g/LIHxrk1l75QzCdUt2YTAluk=; b=LGAerqtCZoYdZtc883bjyWdniX3KJOW37RLOa8lrmybiKHp0oCstnv6Fj3OafFik6h fQ8BjGPEmf8O41RrP+BHqX52YtY2RuC9Sn6HjckxnPMx0RdtfKWd2LfVdDY6Eh+ZXGHI tjeZ54Va/NyZS7SU9cpmi5bnE8ZKYhJQMtETSwxBd006L6AKrXQcTHS2Q/2ypC4wvba5 dTTTq0qbNJ6suCvmX1s94WEtw1JApe40dAjLCNhh2GXkOYemj+YhXur5//3Lh2E9mQK+ iUZTjgRXPdaL8/XAwYengimnW8BNtoKD2gQTAXEUKP6tE8FL/YzpIiF5uhtJewHHE/6o V6NQ== X-Gm-Message-State: AOAM532R66GTMAcUpqs9BQ+kv+T8dGen9Hj569XUlmrk4Z6GN1W90MLO j3OU5wWNoBI+0AOCpZ4muE7ZsA== X-Google-Smtp-Source: ABdhPJwK5hsp3x4s8bGMdugMWnUnjR6cosK0v/eTRo+x21q31mVfH5pwuvMCnU2ZSrWVs24W5YUzrw== X-Received: by 2002:a92:a801:: with SMTP id o1mr4049803ilh.128.1630008969521; Thu, 26 Aug 2021 13:16:09 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id s18sm2291849iov.53.2021.08.26.13.16.08 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 13:16:08 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_EE0D5BF9-D69D-4A0A-AC3B-B5E6129D623D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 16:16:08 -0400 In-Reply-To: Cc: Paul Kyzivat , "rum@ietf.org" To: Matthew H Garber References: <2252_1629994592_6127BE5A_2252_276_1_f921b649-c77a-64df-6ece-644d905013e0@alum.mit.edu> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 20:16:18 -0000 --Apple-Mail=_EE0D5BF9-D69D-4A0A-AC3B-B5E6129D623D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Far be it from me to try to interpret licensing issues, but I believe = there is an available zero cost license for H.264 when used with WebRTC = media. =20 But Google made a choice, and you have to deal with it. Brian > On Aug 26, 2021, at 4:04 PM, Matthew H Garber = wrote: >=20 > Pulling out Paul=E2=80=99s question (and thanks for the welcome!): > =20 > >While building this implementation have you come across any places = where=20 > >you think changes to the spec would be advantageous? >=20 > MITRE is committed to supporting the spec however it comes out, so = we=E2=80=99ll work to the final language, wherever it ends up. > =20 > As an individual who is primarily a web developer/data engineer, I = think allowing direct WebRTC connections would be very forward looking = w.r.t. extant library support and the kind of software engineering = talent available to hire in the future, but I understand this group has = reasons for not wanting to do that at this time. >=20 > >I see that the RTT presents difficulties. Do you have any thoughts on=20= > >how to ease that? > =20 > This is due to our technology choice =E2=80=93 web applications = generally don=E2=80=99t know how to, nor need to, speak T.140; most = folks would pick up a library like socket.io to = handle this unless they had a specific use case not to. The reason we = selected the Janus gateway is that it=E2=80=99s the only fully open = source server side component to attempt to currently support it = (Asterisk deprecated this when they changed SIP libraries). Any solution = I have personally would involve moving the transcoding to the data = center, which I think is outside the scope here =E2=80=93 but that would = allow more compatibility with current web technology stacks. Other than = that, a specialist in this could try adding features to a websocket = library and/or create a transcoding library, but those are both fairly = heavy lifts. > =20 > >I'm guessing that you can't yet interoperate with the existing US VRS=20= > >providers production networks. Have you built your own provider = server=20 > >that accepts calls from your RUE? Can it connect to and interoperate=20= > >with real providers? > =20 > We have a SIP server we=E2=80=99ve used for interoperability in the = past with our Windows client, which has some inherited design choices = that make full RUE compliance difficult. We=E2=80=99ve used this to make = calls with the WebRTC client, though we have to work at reverse = engineering Google=E2=80=99s intentional decision to exclude the = proprietary H.264 codec from Electron due to licensing concerns before = we can expect a call to succeed (which should be fine for non-commercial = purposes, or we can try the openH264 codec and see how compatible it = is). Calls with the optional VP8 client :should: work, though we=E2=80=99d= have to try it to see if that was the case. > =20 > -Matt > =20 > From: Rum > on = behalf of Paul Kyzivat > > Date: Thursday, August 26, 2021 at 12:18 PM > To: rum@ietf.org > > Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0 >=20 > Matt, >=20 > Welcome to the RUM WG! (I don't recall seeing you post here before.) >=20 > On 8/26/21 8:38 AM, Matthew H Garber wrote: > > Good morning all, > >=20 > > Note: This is a second notice of the WebRTC VATRP v1.0 release and = is=20 > > intended for a broader audience than the previous email >=20 > Thank you for publicizing this. "Running Code" is huge in building=20 > support for publishing an RFC. Also, implementina a spec almost always=20= > ferrets out issues. >=20 > > MITRE has released the 1.0 version of a WebRTC based RUE client to = the=20 > > public ACE Github, located=20 > > athttps://github.com/mitrefccace/fcc-vatrp-webrtc = =20 > > >. This client has a=20 > > communications driver for using the Janus Media Server from Meetecho = as=20 > > a gateway to convert WebRTC-based messages to RTP/SRTP. It will also=20= > > communicate with a SIP server configured to receive WebRTC messages=20= > > directly. > >=20 > > The release notes for this application are=20 > > = athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_W= ebRTC_VATRPv1-0_PR_21-1891.docx = =20 > > = >.=20 > > There are known defects that prevent full RUE compliance outlined in = the=20 > > release notes,butMITRE isplanningfollow-on releases to address these = and=20 > > any other discrepancies with future revisions to the working draft. = Our=20 > > intent is to deliver an open source client that is 100% compliant = with=20 > > the final RUM-RUE language. >=20 > While building this implementation have you come across any places = where=20 > you think changes to the spec would be advantageous? >=20 > I see that the RTT presents difficulties. Do you have any thoughts on=20= > how to ease that? >=20 > > A release build is available=20 > > = forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases= /tag/v1.0 = =20 > > >. > >=20 > > We are actively looking for partners for testing interoperability = with=20 > > this client =E2=80=93 if you have an implementation you=E2=80=99d = like to try out,=20 > > please don=E2=80=99t hesitate to reach out to me and we=E2=80=99ll = work out a timeframe. >=20 > I'm guessing that you can't yet interoperate with the existing US VRS=20= > providers production networks. Have you built your own provider server=20= > that accepts calls from your RUE? Can it connect to and interoperate=20= > with real providers? >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_EE0D5BF9-D69D-4A0A-AC3B-B5E6129D623D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Far = be it from me to try to interpret licensing issues, but I believe there = is an available zero cost license for H.264 when used with WebRTC media. =  

But Google = made a choice, and you have to deal with it.

Brian


On Aug 26, 2021, at 4:04 PM, Matthew H Garber <mgarber@mitre.org> = wrote:

Pulling out Paul=E2=80=99s question (and thanks = for the welcome!):
 
>While building this = implementation have you come across any places where 
>you = think changes to the spec would be advantageous?

MITRE is = committed to supporting the spec however it comes out, so we=E2=80=99ll = work to the final language, wherever it ends up.
 
As an individual who is = primarily a web developer/data engineer, I think allowing direct WebRTC = connections would be very forward looking w.r.t. extant library support = and the kind of software engineering talent available to hire in the = future, but I understand this group has reasons for not wanting to do = that at this time.

>I see that the RTT presents difficulties. Do you have any = thoughts on 
>how to ease that?
 
This is due to our technology choice =E2=80=93 = web applications generally don=E2=80=99t know how to, nor need to, speak = T.140; most folks would pick up a library like socket.io to handle this unless they = had a specific use case not to. The reason we selected the Janus gateway = is that it=E2=80=99s the only fully open source server side component to = attempt to currently support it (Asterisk deprecated this when they = changed SIP libraries). Any solution I have personally would involve = moving the transcoding to the data center, which I think is outside the = scope here =E2=80=93 but that would allow more compatibility with = current web technology stacks. Other than that, a specialist in this = could try adding features to a websocket library and/or create a = transcoding library, but those are both fairly heavy lifts.
 
>I'm guessing that you = can't yet interoperate with the existing US VRS 
>providers = production networks. Have you built your own provider server 
>that = accepts calls from your RUE? Can it connect to and interoperate 
>with = real providers?
 
We have a SIP server = we=E2=80=99ve used for interoperability in the past with our Windows = client, which has some inherited design choices that make full RUE = compliance difficult. We=E2=80=99ve used this to make calls with the = WebRTC client, though we have to work at reverse engineering Google=E2=80=99= s intentional decision to exclude the proprietary H.264 codec from = Electron due to licensing concerns before we can expect a call to = succeed (which should be fine for non-commercial purposes, or we can try = the openH264 codec and see how compatible it is). Calls with the = optional VP8 client :should: work, though we=E2=80=99d have to try it to = see if that was the case.
 
-Matt
 

From: Rum <rum-bounces@ietf.org> on = behalf of Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Thursday, August 26, = 2021 at 12:18 PM
To: rum@ietf.org <rum@ietf.org>
Subject: [EXT] Re: [Rum] Release = announcement: WebRTC VATRP v1.0

Matt,

Welcome to the RUM WG! (I don't recall seeing you post here = before.)

On 8/26/21 8:38 AM, Matthew H = Garber wrote:
> Good morning all,
> 
> Note: = This is a second notice of the WebRTC VATRP v1.0 release and is 
> = intended for a broader audience than the previous email

Thank you for publicizing this. "Running Code" is huge in = building 
support for publishing an RFC. Also, implementina a spec = almost always 
ferrets out issues.

> MITRE = has released the 1.0 version of a WebRTC based RUE client to the 
> public = ACE Github, located 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc>. This = client has a 
> communications driver for using the Janus Media Server = from Meetecho as 
> a gateway to convert WebRTC-based messages to RTP/SRTP. = It will also 
> communicate with a SIP server configured to receive = WebRTC messages 
> directly.
> 
> The = release notes for this application are 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/doc= s/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/= FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx>. 
> There = are known defects that prevent full RUE compliance outlined in the 
> release = notes,butMITRE isplanningfollow-on releases to address these and 
> any = other discrepancies with future revisions to the working draft. Our 
> intent = is to deliver an open source client that is 100% compliant with 
> the = final RUM-RUE language.

While building this = implementation have you come across any places where 
you think = changes to the spec would be advantageous?

I = see that the RTT presents difficulties. Do you have any thoughts on 
how to ease = that?

> A release build is = available 
> forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webr= tc/releases/tag/v1.0 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1= .0>.
> 
> We are = actively looking for partners for testing interoperability with 
> this = client =E2=80=93 if you have an implementation you=E2=80=99d like to try = out, 
>= please don=E2=80=99t hesitate to reach out to me and we=E2=80=99ll work = out a timeframe.

I'm guessing that you = can't yet interoperate with the existing US VRS 
providers = production networks. Have you built your own provider server 
that accepts = calls from your RUE? Can it connect to and interoperate 
with real = providers?

        Thanks,
        Paul

-- 
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
-- Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_EE0D5BF9-D69D-4A0A-AC3B-B5E6129D623D-- From nobody Thu Aug 26 13:28:42 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0AF3A0D4A for ; Thu, 26 Aug 2021 13:28:40 -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, 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=mitre.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 ucunWnAMEK46 for ; Thu, 26 Aug 2021 13:28:35 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F6733A0D36 for ; Thu, 26 Aug 2021 13:28:34 -0700 (PDT) Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 339A96C003E; Thu, 26 Aug 2021 16:28:33 -0400 (EDT) Received: from smtprhmv1.mitre.org (unknown [10.20.200.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id D51D26C0029; Thu, 26 Aug 2021 16:28:32 -0400 (EDT) Received: from mwfesmtp-mgt.mitre.org (mwfesmtp-in.mitre.org [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id 4851B80B254; Thu, 26 Aug 2021 16:28:32 -0400 (EDT) Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4GwZDc55Fpz29pwW; Thu, 26 Aug 2021 20:22:54 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2109.outbound.protection.outlook.com [104.47.64.109]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4GwZ642G80z29px4; Thu, 26 Aug 2021 20:22:52 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h6GGAJmZUFdZpx1GH/wlFmqk47iVJoqIeT+xRrUTYRdsIAypQ3Tv5f6KcJbvOdFKmR77A7wVHG07G1D9F+StjqYPqXezARj2SwQjChxIwQQwppPVt/nB2a2LgA89m2VPNp19HnJnPefI4J1B9zhOt7IkWDFLzIt6lQ8qx3RdbFuEdn3wSAtMqe2TbODxR8r3iMRl1+KV8UISWKEYwW613AJASFxcMDIrtbvL+LRIatpNS2JwgyBVK2yjd5TcabhRcES/hF+D4jPZfI2QQBJ1W/R5/Hswl84nFizLhpsmgh3P8y9nYr18TAjSPnR2fLOgNcTli80NCOwIO62FXjws5A== 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=UjYdUQ96a9i6gE6zXpj+pAJ3LnAW3A8dSHosBv4xRLA=; b=BZAB/Y9wvlyQ4Ruo6vX10pRNVRo4Up19fhaUtPpZ8/t0OaXEhZNskEUSp+/WycxC0UyWz7+M6Biy90W7hs8qiSnNRLv/t0UlMh2ufglQtdsFgQoa8F+A8lneh9FaOtbIGnWXT+HEwBsqqHR+nnmwc85syT5TUlW3uKHxVNYEt1H0EeoB8jaINcKaTK4FysEhgGoQ96Lj3EzbAYzMrTcoJMp2T7PdkeSKXKje2Cd2c9a3RX4yNYutmsHEIyEQqXRWSBMMeOHmrm38wmT5iaiyuU4dy673C7xEZ85zB3Wg5+4fWWpAILgT96Bn06TphuvW+w9cIilbXVnCdVqV4fS79g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from MN2PR09MB5979.namprd09.prod.outlook.com (2603:10b6:208:219::13) by MN2PR09MB5531.namprd09.prod.outlook.com (2603:10b6:208:21a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 26 Aug 2021 20:22:51 +0000 Received: from MN2PR09MB5979.namprd09.prod.outlook.com ([fe80::d2:9ef2:376a:e94d]) by MN2PR09MB5979.namprd09.prod.outlook.com ([fe80::d2:9ef2:376a:e94d%2]) with mapi id 15.20.4436.027; Thu, 26 Aug 2021 20:22:51 +0000 From: Matthew H Garber To: Brian Rosen CC: "Kyzivat, Paul" , "rum@ietf.org" Thread-Topic: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 Thread-Index: AQHXmrfb3cQ88G5zGkmFG0CgmN81lquGOo9M Date: Thu, 26 Aug 2021 20:22:51 +0000 Message-ID: References: <2252_1629994592_6127BE5A_2252_276_1_f921b649-c77a-64df-6ece-644d905013e0@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9960f766-aa62-469c-d716-08d968cf4759 x-ms-traffictypediagnostic: MN2PR09MB5531: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mqHx0QObSFQfNYZppifyxWxQU3J2pYbgS0F0Xsd7Pflq7buFuto8e4/t2P9A4A/7f06DUglFpRnV185IaPuW2ij10bfV+w+/H5zcUP5RyMVIKWQaJ9ZBAdEgRAYkDmahQ05H3n39KLih3KdNNVXK/pAFIQuMQMtiznsfbdN65uHf2SnbRVoeX/eyaj4b0aOwXjTO5OIewDAIaf0Jfb+raoAiWe1p/TYL3HEBsxup2i2mw2rhmQ5uqjmQ/a1sdXEQbXWAo90sq/oVjh4AhTBYEnOyGC16ywo5dhHOryvAZLJYKDwhss73H+nI44iag2UlFY40DqK28DxW7q76Z/Gequj4Ed/kC4MQ/R+UXWvsTFyHjUDl/KcNreUnW4ac3HgQcgSLAR9G8DoTwiuiGLD7IlBhhR3aQL3yziBki3HsI5XlI1GdVVGTg2CxerzC/Yk9X+qr2ylcOi5xxNy009akDgywXtvJJwsIxyx5ncRm1ytPcuqJ2u68trY1u+a5SWDkIpB+BV5nqs/ZO3wWyxnEtfbOXyuZbtENJDXF7CB0Fml4+AvDWt+AYzILq2Rprom643/9uOhrsyCQ+7JPG7vvdXR9dazs1p1fmRSz+74B8FE3jjDiutslbR68OstO56DsfzfqSQzcqLTreZ8saSVcJgS0rDs3HR1VdAbMaWKFHZHD3fQInrosMgzbZDlwExCf0q6yShVVdyweFqF0udBRWkwJeQyfo+yrq+MGr9ecV5AsFD87R7AckN49TliX2fA5uEp6mXZrgmg3iWXzF0ZHxFIfQ39YEyPNHTYmTMcTtik= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5979.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39860400002)(396003)(346002)(136003)(366004)(86362001)(55016002)(6916009)(83380400001)(53546011)(186003)(4326008)(38070700005)(54906003)(316002)(71200400001)(2906002)(8936002)(122000001)(38100700002)(478600001)(66556008)(6506007)(8676002)(76116006)(7696005)(166002)(966005)(26005)(33656002)(52536014)(66476007)(5660300002)(9686003)(66946007)(64756008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?RXdYuORGwF2/iDJwXGAXdMlDOkxBSMuFF+yOiVY0HTlgiE8r+B2fZM+a?= =?Windows-1252?Q?OQrGKOgqOdiON5tNVxw80rQtYmG08qucPNU5GldkigENwM8RQflzbnRw?= =?Windows-1252?Q?pVl8i2czlKArLwb/S8gk4Do/9/53nIROjU4V+65jDusNp+4xbzhsg8+c?= =?Windows-1252?Q?0XsNe0vu5xDvALVsarzOj6fMRqaeqNEodKApPQtR5cAzff/1W7hGM3re?= =?Windows-1252?Q?css+XjWGt0qCN08paDsCjtyUJ1rkhxUSlu0Xw3XtysJAHISI7TXeYzOc?= =?Windows-1252?Q?1QkwSfdGHp3PU+WlDTS7dhFshel61PZZguCICO/ow4t0ubv4+1d+sFZY?= =?Windows-1252?Q?M0FgHnY2jEgV47GHwafQ4wepRaMGq6VvSg8L5wN+2ZQW/LMlldCd/b68?= =?Windows-1252?Q?aeXawnjHfiKyPhEC5rbTC1z0Qu9nynYv1GytFZLVLoYHAWUPj/j7v+TI?= =?Windows-1252?Q?lKaBX5rr1EGG9+keAaNakwUETvqEEmK8irt1FN/LhygY7JDpv0/OPi8F?= =?Windows-1252?Q?piG4Y9py2sQHzyoOJ4n60tWFIpkH9AYCahzSRw9pY/I21u472KqOY1BH?= =?Windows-1252?Q?+fvxk/e2btvAeMCClErKyTkf5FN+cldsxCc7YxQIXclEyUmcRwXH3dkm?= =?Windows-1252?Q?wlFe03Yp8uDY1jl75q3y2ySF8kVl87Qh7VlkadkA2lu2rgMDCidgnpPo?= =?Windows-1252?Q?3DZrxKoLNum0huGwAOM3r/tjN25vzjzz/gtP/7v+M4wgq0gXiJTUx6iP?= =?Windows-1252?Q?9yKRkdUwpb4tHk1EPezbflmS8XDkcA9WgzXaIqVqcFsVRtAwVULhRbOS?= =?Windows-1252?Q?OUvUkTGwt9dHfAFKvrCinoiRHxB2mvnkfURasWEyRCWBHQvUav6In3fE?= =?Windows-1252?Q?q14IhCV2NswPlESYa5tukqJvGf8h1SEhdP6CCVIQu0wNHsPc6EMVl5L1?= =?Windows-1252?Q?8Bg1G6A5ii1x9h685mXiyBBQC5rxByIUzOvwo62dRe6DYJpHoap9OBV9?= =?Windows-1252?Q?OoCi+VDT0YflVVTxSUJb1KBrj20ApjsyXYgXQ28izmynMZTUifd4gdb0?= =?Windows-1252?Q?cXZ2Ce9UOi1A9V1TGpunvKpUKLqaEOBady/VO63W7aE5KIwslZluXFW3?= =?Windows-1252?Q?ciqjy+2uf3iSnbN+Z75FYmgjJ9mXEfKt6MyNuMYjFbXtdSzJvKrtLUdt?= =?Windows-1252?Q?N+EqaJG/C+cmUyyW6+ZA+BF6RHNoVS4o3Pq7OD+ObfZP6/89xADXmJgX?= =?Windows-1252?Q?h40LDFSY4lCWghzjivbGYzP20Pjj7jwMXyjvEjFqmc7UkLY+Qv0kA4PE?= =?Windows-1252?Q?bUDhh6kklS0gIV/Px4ZhTfti4HnzfZnHXdoW6yCXjxl9W+MT7B9X/695?= =?Windows-1252?Q?keRAFx9esiCPIFgVUa/1jeNbMgp+vjEvDFYk+W+Zu2ye9YLVS9yI7+Bi?= =?Windows-1252?Q?zOB4JEq4Sv9/3tLPIgfneg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR09MB5979FF219160A4D01C66BFC3A5C79MN2PR09MB5979namp_" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5979.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9960f766-aa62-469c-d716-08d968cf4759 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 20:22:51.3298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB5531 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=BTxNELhf; bh=UjYdUQ96a9i6gE6zXpj+pAJ3LnAW3A8dSHosBv4xRLA=; b=rv6b+NDIasXJCm5b2UmVx98+TWKHC74h+Cr0cJLY/e6nB8kWMJjk1mvDY+be65EoDLUSeKOPSL+dhYduR4YrYSCTBR+Zj8udHoWBB/LlxpuaokS9Jxk1Rfbxf7od+y2MCMFbNnJMgkeOR/xMKCS21ZSn1e/rrNsO6cqqRGdsomg= Archived-At: Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 20:28:41 -0000 --_000_MN2PR09MB5979FF219160A4D01C66BFC3A5C79MN2PR09MB5979namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yeah, we know and are. It=92s our #1 priority for the next release. From: Brian Rosen Date: Thursday, August 26, 2021 at 4:20 PM To: Matthew H Garber Cc: Kyzivat, Paul , rum@ietf.org Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 Far be it from me to try to interpret licensing issues, but I believe there= is an available zero cost license for H.264 when used with WebRTC media. But Google made a choice, and you have to deal with it. Brian On Aug 26, 2021, at 4:04 PM, Matthew H Garber > wrote: Pulling out Paul=92s question (and thanks for the welcome!): >While building this implementation have you come across any places where >you think changes to the spec would be advantageous? MITRE is committed to supporting the spec however it comes out, so we=92ll = work to the final language, wherever it ends up. As an individual who is primarily a web developer/data engineer, I think al= lowing direct WebRTC connections would be very forward looking w.r.t. extan= t library support and the kind of software engineering talent available to = hire in the future, but I understand this group has reasons for not wanting= to do that at this time. >I see that the RTT presents difficulties. Do you have any thoughts on >how to ease that? This is due to our technology choice =96 web applications generally don=92t= know how to, nor need to, speak T.140; most folks would pick up a library = like socket.io to handle this unless they had a specific= use case not to. The reason we selected the Janus gateway is that it=92s t= he only fully open source server side component to attempt to currently sup= port it (Asterisk deprecated this when they changed SIP libraries). Any sol= ution I have personally would involve moving the transcoding to the data ce= nter, which I think is outside the scope here =96 but that would allow more= compatibility with current web technology stacks. Other than that, a speci= alist in this could try adding features to a websocket library and/or creat= e a transcoding library, but those are both fairly heavy lifts. >I'm guessing that you can't yet interoperate with the existing US VRS >providers production networks. Have you built your own provider server >that accepts calls from your RUE? Can it connect to and interoperate >with real providers? We have a SIP server we=92ve used for interoperability in the past with our= Windows client, which has some inherited design choices that make full RUE= compliance difficult. We=92ve used this to make calls with the WebRTC clie= nt, though we have to work at reverse engineering Google=92s intentional de= cision to exclude the proprietary H.264 codec from Electron due to licensin= g concerns before we can expect a call to succeed (which should be fine for= non-commercial purposes, or we can try the openH264 codec and see how comp= atible it is). Calls with the optional VP8 client :should: work, though we= =92d have to try it to see if that was the case. -Matt From: Rum > on behalf of = Paul Kyzivat > Date: Thursday, August 26, 2021 at 12:18 PM To: rum@ietf.org > Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0 Matt, Welcome to the RUM WG! (I don't recall seeing you post here before.) On 8/26/21 8:38 AM, Matthew H Garber wrote: > Good morning all, > > Note: This is a second notice of the WebRTC VATRP v1.0 release and is > intended for a broader audience than the previous email Thank you for publicizing this. "Running Code" is huge in building support for publishing an RFC. Also, implementina a spec almost always ferrets out issues. > MITRE has released the 1.0 version of a WebRTC based RUE client to the > public ACE Github, located > athttps://github.com/mitrefccace/fcc-vatrp-webrtc > . This client has a > communications driver for using the Janus Media Server from Meetecho as > a gateway to convert WebRTC-based messages to RTP/SRTP. It will also > communicate with a SIP server configured to receive WebRTC messages > directly. > > The release notes for this application are > athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_= WebRTC_VATRPv1-0_PR_21-1891.docx > . > There are known defects that prevent full RUE compliance outlined in the > release notes,butMITRE isplanningfollow-on releases to address these and > any other discrepancies with future revisions to the working draft. Our > intent is to deliver an open source client that is 100% compliant with > the final RUM-RUE language. While building this implementation have you come across any places where you think changes to the spec would be advantageous? I see that the RTT presents difficulties. Do you have any thoughts on how to ease that? > A release build is available > forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/release= s/tag/v1.0 > . > > We are actively looking for partners for testing interoperability with > this client =96 if you have an implementation you=92d like to try out, > please don=92t hesitate to reach out to me and we=92ll work out a timefra= me. I'm guessing that you can't yet interoperate with the existing US VRS providers production networks. Have you built your own provider server that accepts calls from your RUE? Can it connect to and interoperate with real providers? Thanks, Paul -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum --_000_MN2PR09MB5979FF219160A4D01C66BFC3A5C79MN2PR09MB5979namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Yeah, we know and are. It=92s our #1 priority for th= e next release.

 

From: Brian Rosen <br@= brianrosen.net>
Date: Thursday, August 26, 2021 at 4:20 PM
To: Matthew H Garber <mgarber@mitre.org>
Cc: Kyzivat, Paul <pkyzivat@alum.mit.edu>, rum@ietf.org <ru= m@ietf.org>
Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0=

Far be it from me to try to interpret licensing issu= es, but I believe there is an available zero cost license for H.264 when us= ed with WebRTC media.  

 

But Google made a choice, and you have to deal with = it.

 

Brian

 



On Aug 26, 2021, at 4:04 PM, Matthew H Garber <mgarber@mitre.org> wrote:

 

Pulling out Paul=92s question (and thanks for the we= lcome!):

 

>While building this implementation have you come= across any places where =
>you think changes to the spec would be advantageous?


MITRE is committed to supporting the spec however it= comes out, so we=92ll work to the final language, wherever it ends up.

 

As an individual who is primarily a web developer/da= ta engineer, I think allowing direct WebRTC connections would be very forwa= rd looking w.r.t. extant library support and the kind of software engineeri= ng talent available to hire in the future, but I understand this group has reasons for not wanting to do that= at this time.


>I see that the RTT presents difficulties. Do you have any thoughts on 
>how to ease that?

 

This is due to our technology choice =96 web applica= tions generally don=92t know how to, nor need to, speak T.140; most folks w= ould pick up a library like socket.io to handle this unless they had a specific use case not to. The reason we sele= cted the Janus gateway is that it=92s the only fully open source server sid= e component to attempt to currently support it (Asterisk deprecated this wh= en they changed SIP libraries). Any solution I have personally would involve moving the transcoding to the dat= a center, which I think is outside the scope here =96 but that would allow = more compatibility with current web technology stacks. Other than that, a s= pecialist in this could try adding features to a websocket library and/or create a transcoding library, but t= hose are both fairly heavy lifts.

 

>I'm guessing that you can't yet interoperate wit= h the existing US VRS  >providers production networks. Have you built your own provider server<= span class=3D"apple-converted-space"> 
>that accepts calls from your RUE? Can it connect to and interoperate 
>with real providers?

 

We have a SIP server we=92ve used for interoperabili= ty in the past with our Windows client, which has some inherited design cho= ices that make full RUE compliance difficult. We=92ve used this to make cal= ls with the WebRTC client, though we have to work at reverse engineering Google=92s intentional decision to exclude = the proprietary H.264 codec from Electron due to licensing concerns before = we can expect a call to succeed (which should be fine for non-commercial pu= rposes, or we can try the openH264 codec and see how compatible it is). Calls with the optional VP8 client :s= hould: work, though we=92d have to try it to see if that was the case.=

 

-Matt

 

From: Rum <rum-bounces@ietf.org> on behalf of Paul Kyzivat <pkyzivat@alum.mi= t.edu>
Date: Thursday, Au= gust 26, 2021 at 12:18 PM
To: rum@ietf.org&nb= sp;<rum@ietf.org>
Subject: [EXT] Re:= [Rum] Release announcement: WebRTC VATRP v1.0

Matt,

Welcome to the RUM WG! (I don't recall seeing you post here before.)

On 8/26/21 8:38 AM, Matthew H Garber wrote:
> Good morning all,
> 
> Note: This is a second notice of the WebRTC VATRP v1.0 release and is<= span class=3D"apple-converted-space"> 
> intended for a broader audience than the previous email

Thank you for publicizing this. "Running Code" is huge in buildin= g 
support for publishing an RFC. Also, implementina a spec almost always 
ferrets out issues.

> MITRE has released the 1.0 version of a WebRTC based RUE client to the=  
> public ACE Github, located =
> athttps://github.com/mitrefccace/= fcc-vatrp-webrtc 
> <https:= //github.com/mitrefccace/fcc-vatrp-webrtc>. This client has a 
> communications driver for using the Janus Media Server from Meetecho a= s 
> a gateway to convert WebRTC-based messages to RTP/SRTP. It will also 
> communicate with a SIP server configured to receive WebRTC messages 
> directly.
> 
> The release notes for this application are 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc/bl= ob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx 
> <https://github.com/mitref= ccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.d= ocx>. 
> There are known defects that prevent full RUE compliance outlined in t= he 
> release notes,butMITRE isplanningfollow-on releases to address these a= nd 
> any other discrepancies with future revisions to the working draft. Ou= r 
> intent is to deliver an open source client that is 100% compliant with=  
> the final RUM-RUE language.

While building this implementation have you come across any places where 
you think changes to the spec would be advantageous?

I see that the RTT presents difficulties. Do you have any thoughts on 
how to ease that?

> A release build is available&nbs= p;
> forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases= /tag/v1.0 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1= .0>.
> 
> We are actively looking for partners for testing interoperability with=  
> this client =96 if you have an implementation you=92d like to try out,=  
> please don=92t hesitate to reach out to me and we=92ll work out a time= frame.

I'm guessing that you can't yet interoperate with the existing US VRS 
providers production networks. Have you built your own provider server 
that accepts calls from your RUE? Can it connect to and interoperate 
with real providers?

        Thanks,
        Paul

-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/= mailman/listinfo/rum

-- 
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listin= fo/rum

 

--_000_MN2PR09MB5979FF219160A4D01C66BFC3A5C79MN2PR09MB5979namp_-- From nobody Thu Aug 26 13:54:11 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABAB3A11A1 for ; Thu, 26 Aug 2021 13:54:09 -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 i6J5Cr1dlls0 for ; Thu, 26 Aug 2021 13:54:02 -0700 (PDT) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 AAF093A12B8 for ; Thu, 26 Aug 2021 13:53:52 -0700 (PDT) Received: by mail-il1-x12c.google.com with SMTP id h29so4692736ila.2 for ; Thu, 26 Aug 2021 13:53:52 -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=75ht0UMXuXRnBItAhC/mxxZCdFogy2j+pfcYVvau8WM=; b=V7oDxTi5qJF5isbTvM3HK4QtrxbZ+l2D4VmMXWNhD1WW+IK16fh7MK01Vu+wiUt5nv sqEBR6uhcK7L3RfFEUAzcsAjntTdYauO8XM1/FZ2yJ7DyRUZQp7gx4zsFQOR/RYn9Hox W7hHE56cN75IAhxL5UCkfVISvKhaWJSnXdvLyISs/6wcYRWODA1exyN87zNVpuXk/lt/ DG+IQm8G2epbJf/J8nKuWimzyowC632GW/9axFOZqarKlf05IJPXSgJUrU9a+Pkog0g5 gww/bwQhKtUNCVMnafuSQBfitQz5GB2e3Igdwfd64Ujo4qyh3Zssu0fQTTnY1pfRNI2O c6rg== 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=75ht0UMXuXRnBItAhC/mxxZCdFogy2j+pfcYVvau8WM=; b=nDvjENuX6R3iEAI4q/QLkBGvpFWnItoJUEhv9ax/mbb7gshk9+cmor5Uo5Il1jpc5z ZjM544/b8YlyIzCIj8zmnEyEzB8HJwTZ08oCb/codC82a1CqD6MR8xOS9gJaQl9spKrT Zvc9SvA5GYE3VVcr21/S2T3b/go3IDMdaWa4uED9ZVm4cmq9rOCZItJrca6kovq3FI+y 2psuEDj3aqaUciP+qHgGPWCbJhtxdXKkgAQ2pnLjFle8IrTK3MhP19BheduEUXXyIhbG sG6kT+vXF5vNVtCEh9hXqlVr7Pie1ScHnN5nA7m+XkhcmSirmg2odK9GLTs1wYN+Q961 6EUg== X-Gm-Message-State: AOAM530FeicOMCm6AyekXfBTRk1oIRS/Qp+qVBp9Hkr6fwKMIkeVizWf k/T7ClfRqrJJuzP4F5bBVkpe9Q== X-Google-Smtp-Source: ABdhPJzlSwllKplWtEF+NB4ciKA6YI/q8x7FvVH1syHmD7MxQ8OqPyTFLjd14XDyzCvgiAtZOHrecA== X-Received: by 2002:a05:6e02:174a:: with SMTP id y10mr4222602ill.121.1630011230735; Thu, 26 Aug 2021 13:53:50 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id p15sm2084960iop.15.2021.08.26.13.53.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 13:53:50 -0700 (PDT) From: Brian Rosen Message-Id: <6DF92F1E-2ADF-4755-8CC1-803756A9CB13@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_400A9B79-B32E-4D49-A853-1432C4C48BF3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 16:53:47 -0400 In-Reply-To: Cc: Paul Kyzivat , "rum@ietf.org" To: Matthew H Garber References: <2252_1629994592_6127BE5A_2252_276_1_f921b649-c77a-64df-6ece-644d905013e0@alum.mit.edu> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 20:54:09 -0000 --Apple-Mail=_400A9B79-B32E-4D49-A853-1432C4C48BF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I am reminded that there is no licensing costs for less than 100,000 = licenses per licensor per year. Doesn=E2=80=99t fix what is in the library, but there is no licensing = costs for all instances we can think of for this spec. Brian > On Aug 26, 2021, at 4:22 PM, Matthew H Garber = wrote: >=20 > Yeah, we know and are. It=E2=80=99s our #1 priority for the next = release. > =20 > From: Brian Rosen > Date: Thursday, August 26, 2021 at 4:20 PM > To: Matthew H Garber > Cc: Kyzivat, Paul , rum@ietf.org > Subject: Re: [Rum] [EXT] Re: Release announcement: WebRTC VATRP v1.0 >=20 > Far be it from me to try to interpret licensing issues, but I believe = there is an available zero cost license for H.264 when used with WebRTC = media. =20 > =20 > But Google made a choice, and you have to deal with it. > =20 > Brian > =20 >=20 >=20 > On Aug 26, 2021, at 4:04 PM, Matthew H Garber > wrote: > =20 > Pulling out Paul=E2=80=99s question (and thanks for the welcome!): > =20 > >While building this implementation have you come across any places = where=20 > >you think changes to the spec would be advantageous? >=20 >=20 > MITRE is committed to supporting the spec however it comes out, so = we=E2=80=99ll work to the final language, wherever it ends up. > =20 > As an individual who is primarily a web developer/data engineer, I = think allowing direct WebRTC connections would be very forward looking = w.r.t. extant library support and the kind of software engineering = talent available to hire in the future, but I understand this group has = reasons for not wanting to do that at this time. >=20 > >I see that the RTT presents difficulties. Do you have any thoughts on=20= > >how to ease that? > =20 > This is due to our technology choice =E2=80=93 web applications = generally don=E2=80=99t know how to, nor need to, speak T.140; most = folks would pick up a library like socket.io to = handle this unless they had a specific use case not to. The reason we = selected the Janus gateway is that it=E2=80=99s the only fully open = source server side component to attempt to currently support it = (Asterisk deprecated this when they changed SIP libraries). Any solution = I have personally would involve moving the transcoding to the data = center, which I think is outside the scope here =E2=80=93 but that would = allow more compatibility with current web technology stacks. Other than = that, a specialist in this could try adding features to a websocket = library and/or create a transcoding library, but those are both fairly = heavy lifts. > =20 > >I'm guessing that you can't yet interoperate with the existing US VRS=20= > >providers production networks. Have you built your own provider = server=20 > >that accepts calls from your RUE? Can it connect to and interoperate=20= > >with real providers? > =20 > We have a SIP server we=E2=80=99ve used for interoperability in the = past with our Windows client, which has some inherited design choices = that make full RUE compliance difficult. We=E2=80=99ve used this to make = calls with the WebRTC client, though we have to work at reverse = engineering Google=E2=80=99s intentional decision to exclude the = proprietary H.264 codec from Electron due to licensing concerns before = we can expect a call to succeed (which should be fine for non-commercial = purposes, or we can try the openH264 codec and see how compatible it = is). Calls with the optional VP8 client :should: work, though we=E2=80=99d= have to try it to see if that was the case. > =20 > -Matt > =20 > From: Rum > on = behalf of Paul Kyzivat > > Date: Thursday, August 26, 2021 at 12:18 PM > To: rum@ietf.org > > Subject: [EXT] Re: [Rum] Release announcement: WebRTC VATRP v1.0 >=20 > Matt, >=20 > Welcome to the RUM WG! (I don't recall seeing you post here before.) >=20 > On 8/26/21 8:38 AM, Matthew H Garber wrote: > > Good morning all, > >=20 > > Note: This is a second notice of the WebRTC VATRP v1.0 release and = is=20 > > intended for a broader audience than the previous email >=20 > Thank you for publicizing this. "Running Code" is huge in building=20 > support for publishing an RFC. Also, implementina a spec almost always=20= > ferrets out issues. >=20 > > MITRE has released the 1.0 version of a WebRTC based RUE client to = the=20 > > public ACE Github, located=20 > > athttps://github.com/mitrefccace/fcc-vatrp-webrtc = =20 > > >. This client has a=20 > > communications driver for using the Janus Media Server from Meetecho = as=20 > > a gateway to convert WebRTC-based messages to RTP/SRTP. It will also=20= > > communicate with a SIP server configured to receive WebRTC messages=20= > > directly. > >=20 > > The release notes for this application are=20 > > = athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/FCC_TRS_W= ebRTC_VATRPv1-0_PR_21-1891.docx = =20 > > = >.=20 > > There are known defects that prevent full RUE compliance outlined in = the=20 > > release notes,butMITRE isplanningfollow-on releases to address these = and=20 > > any other discrepancies with future revisions to the working draft. = Our=20 > > intent is to deliver an open source client that is 100% compliant = with=20 > > the final RUM-RUE language. >=20 > While building this implementation have you come across any places = where=20 > you think changes to the spec would be advantageous? >=20 > I see that the RTT presents difficulties. Do you have any thoughts on=20= > how to ease that? >=20 > > A release build is available=20 > > = forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webrtc/releases= /tag/v1.0 = =20 > > >. > >=20 > > We are actively looking for partners for testing interoperability = with=20 > > this client =E2=80=93 if you have an implementation you=E2=80=99d = like to try out,=20 > > please don=E2=80=99t hesitate to reach out to me and we=E2=80=99ll = work out a timeframe. >=20 > I'm guessing that you can't yet interoperate with the existing US VRS=20= > providers production networks. Have you built your own provider server=20= > that accepts calls from your RUE? Can it connect to and interoperate=20= > with real providers? >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_400A9B79-B32E-4D49-A853-1432C4C48BF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = am reminded that there is no licensing costs for less than 100,000 = licenses per licensor per year.


Doesn=E2=80=99t fix what is in the = library, but there is no licensing costs for all instances we can think = of for this spec.

Brian

On Aug = 26, 2021, at 4:22 PM, Matthew H Garber <mgarber@mitre.org> = wrote:

Yeah, we know and are. It=E2=80=99s our #1 = priority for the next release.
 
From: Brian Rosen <br@brianrosen.net>
Date: Thursday, August 26, = 2021 at 4:20 PM
To: Matthew H Garber <mgarber@mitre.org>
Cc: Kyzivat, Paul <pkyzivat@alum.mit.edu>, rum@ietf.org <rum@ietf.org>
Subject: Re: [Rum] [EXT] Re: = Release announcement: WebRTC VATRP v1.0

Far be it from me to = try to interpret licensing issues, but I believe there is an available = zero cost license for H.264 when used with WebRTC media.  
 
But = Google made a choice, and you have to deal with it.
 
Brian
 


On = Aug 26, 2021, at 4:04 PM, Matthew H Garber <mgarber@mitre.org> wrote:
 
Pulling out Paul=E2=80=99s question (and thanks = for the welcome!):
 
>While building this implementation = have you come across any places where 
>you = think changes to the spec would be advantageous?


MITRE is committed to supporting the = spec however it comes out, so we=E2=80=99ll work to the final language, = wherever it ends up.
 
As an individual who is primarily a web = developer/data engineer, I think allowing direct WebRTC connections = would be very forward looking w.r.t. extant library support and the kind = of software engineering talent available to hire in the future, but I = understand this group has reasons for not wanting to do that at this = time.

>I see that the RTT presents = difficulties. Do you have any thoughts on 
>how to = ease that?
 
This is due to our technology choice = =E2=80=93 web applications generally don=E2=80=99t know how to, nor need = to, speak T.140; most folks would pick up a library like socket.io to handle this unless they = had a specific use case not to. The reason we selected the Janus gateway = is that it=E2=80=99s the only fully open source server side component to = attempt to currently support it (Asterisk deprecated this when they = changed SIP libraries). Any solution I have personally would involve = moving the transcoding to the data center, which I think is outside the = scope here =E2=80=93 but that would allow more compatibility with = current web technology stacks. Other than that, a specialist in this = could try adding features to a websocket library and/or create a = transcoding library, but those are both fairly heavy lifts.
 
>I'm = guessing that you can't yet interoperate with the existing US VRS 
>providers = production networks. Have you built your own provider server 
>that = accepts calls from your RUE? Can it connect to and interoperate 
>with = real providers?
 
We have a SIP server we=E2=80=99ve used = for interoperability in the past with our Windows client, which has some = inherited design choices that make full RUE compliance difficult. = We=E2=80=99ve used this to make calls with the WebRTC client, though we = have to work at reverse engineering Google=E2=80=99s intentional = decision to exclude the proprietary H.264 codec from Electron due to = licensing concerns before we can expect a call to succeed (which should = be fine for non-commercial purposes, or we can try the openH264 codec = and see how compatible it is). Calls with the optional VP8 client = :should: work, though we=E2=80=99d have to try it to see if that was the = case.
 
-Matt
 

From: Rum <rum-bounces@ietf.org> on = behalf of Paul Kyzivat <pkyzivat@alum.mit.edu>
Date: Thursday, August 26, = 2021 at 12:18 PM
To: rum@ietf.org <rum@ietf.org>
Subject: [EXT] Re: [Rum] Release = announcement: WebRTC VATRP v1.0

Matt,

Welcome to the RUM WG! (I don't recall seeing you post here = before.)

On 8/26/21 8:38 AM, Matthew H = Garber wrote:
> Good morning all,
> 
> Note: = This is a second notice of the WebRTC VATRP v1.0 release and is 
> = intended for a broader audience than the previous email

Thank you for publicizing this. "Running Code" is huge in = building 
support for publishing an RFC. Also, implementina a spec = almost always 
ferrets out issues.

> MITRE = has released the 1.0 version of a WebRTC based RUE client to the 
> public = ACE Github, located 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc>. This = client has a 
> communications driver for using the Janus Media Server = from Meetecho as 
> a gateway to convert WebRTC-based messages to RTP/SRTP. = It will also 
> communicate with a SIP server configured to receive = WebRTC messages 
> directly.
> 
> The = release notes for this application are 
> athttps://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/doc= s/FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/blob/main/docs/= FCC_TRS_WebRTC_VATRPv1-0_PR_21-1891.docx>. 
> There = are known defects that prevent full RUE compliance outlined in the 
> release = notes,butMITRE isplanningfollow-on releases to address these and 
> any = other discrepancies with future revisions to the working draft. Our 
> intent = is to deliver an open source client that is 100% compliant with 
> the = final RUM-RUE language.

While building this = implementation have you come across any places where 
you think = changes to the spec would be advantageous?

I = see that the RTT presents difficulties. Do you have any thoughts on 
how to ease = that?

> A release build is = available 
> forWindowsandMacathttps://github.com/mitrefccace/fcc-vatrp-webr= tc/releases/tag/v1.0 
> <https://github.com/mitrefccace/fcc-vatrp-webrtc/releases/tag/v1= .0>.
> 
> We are = actively looking for partners for testing interoperability with 
> this = client =E2=80=93 if you have an implementation you=E2=80=99d like to try = out, 
>= please don=E2=80=99t hesitate to reach out to me and we=E2=80=99ll work = out a timeframe.

I'm guessing that you = can't yet interoperate with the existing US VRS 
providers = production networks. Have you built your own provider server 
that accepts = calls from your RUE? Can it connect to and interoperate 
with real = providers?

        Thanks,
        Paul

-- 
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
-- 
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_400A9B79-B32E-4D49-A853-1432C4C48BF3-- From nobody Thu Aug 26 14:09:38 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236EF3A1357 for ; Thu, 26 Aug 2021 14:09:37 -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, NICE_REPLY_A=-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 (1024-bit key) header.d=egensajt.se 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 KoVOEA5hf9YC for ; Thu, 26 Aug 2021 14:09:30 -0700 (PDT) Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83FFB3A1354 for ; Thu, 26 Aug 2021 14:09:29 -0700 (PDT) Received: from [192.168.2.136] (h79-138-72-140.cust.a3fiber.se [79.138.72.140]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id CD43E20F51 for ; Thu, 26 Aug 2021 23:09:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1630012167; bh=sh4oP47r1PDwSqPThQnuiFtkZV22nko0SQoK+gHDTJ4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CygAOdaJsZT8ODPjK7xh4FGhvUx40Ie9kQoSihy4cFw93avjgp7U7aA4XxfhoD1uu IG85WvURd3vsGNmChSyW3XhqIyDxD/voqIFZ4JK2v9WEuaKQogZBP2DTm3DBXi+NSr 7B+N09nsAfWgdu3oJzOdYcl5vHCjpQER3Tn0+njw= To: rum@ietf.org References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> <4b6b9930-d582-f1ef-09f4-9ec5bd29d53d@alum.mit.edu> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <11ed9f93-b04d-6577-ba00-86a55e0678b0@ghaccess.se> Date: Thu, 26 Aug 2021 23:09:26 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <4b6b9930-d582-f1ef-09f4-9ec5bd29d53d@alum.mit.edu> Content-Type: multipart/alternative; boundary="------------F26383AD2F41B9FC46CFB327" Content-Language: sv Archived-At: Subject: Re: [Rum] WGLC for draft-ietf-rum-rue-07 - words left out X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 21:09:37 -0000 This is a multi-part message in MIME format. --------------F26383AD2F41B9FC46CFB327 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Good to see rum-rue get to the wglc state. Before taking a deeper look, I just want to convey an observation of a couple of words left out between version -06 and -07. In section 5.2.3, 3rd line from the end,   "for an example ..." s.b.  "Please refer to [RFC6442] for an example ..." It seems to me that "Please refer to [RFC6442]" just happened to be dropped. Right? Gunnar -------------------------------- Den 2021-08-26 kl. 19:05, skrev Paul Kyzivat: > [Speaking as a RUM WG chair] > > This message announces the start of WGLC (Working Group Last Call) for > draft-ietf-rum-rue-07. > > The end of this WGLC will be midnight UTC on September 12, 2021. > (That is roughly two weeks, rounded up to a week boundary.) > > The energy level in the wg has been low. This WGLC is to help us move > to wrap things up. The comments that have been posted for the last few > days will be treated as WGLC comments. If you have made comments > recently please review to see if they are impacted by the changes in > -07 and if so update your comments. (I don't think any are.) > > Starting on Monday morning September 13 we will assess where we stand > based on WGLC comments. If discussion has been robust but incomplete > we MAY further extend the WGLC. > >     Thank you, >     Paul Kyzivat > > On 8/26/21 12:09 PM, Brian Rosen wrote: >> This version: >> Changes jCard to xCard >> Says ICE candidates with specific IP versions is allowed >> Doesn’t require MWI support if voicemail is not supported (actually, >> 06 said that). >> >> I think the document is ready for work group last call. >> >> Brian >> >> >>> On Aug 26, 2021, at 12:05 PM, internet-drafts@ietf.org wrote: >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Relay User Machine WG of the IETF. >>> >>>         Title           : Interoperability Profile for Relay User >>> Equipment >>>         Author          : Brian Rosen >>>     Filename        : draft-ietf-rum-rue-07.txt >>>     Pages           : 33 >>>     Date            : 2021-08-26 >>> >>> Abstract: >>>    Video Relay Service (VRS) is a term used to describe a method by >>>    which a hearing persons can communicate with deaf/Hard of Hearing >>>    user using an interpreter ("Communications Assistant") connected via >>>    a videophone to the deaf/HoH user and an audio telephone call to the >>>    hearing user.  The CA interprets using sign language on the >>>    videophone link and voice on the telephone link.  Often the >>>    interpreters may be supplied by a company or agency termed a >>>    "provider" in this document.  The provider also provides a video >>>    service that allows users to connect video devices to their service, >>>    and subsequently to CAs and other deaf/HoH users.  It is desirable >>>    that the videophones used by the deaf/HoH/H-I user conform to a >>>    standard so that any device may be used with any provider and that >>>    video calls direct between deaf/HoH users work.  This document >>>    describes the interface between a videophone and a provider. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >>> >>> There is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-07 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> > -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se --------------F26383AD2F41B9FC46CFB327 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PVVURi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eT4NCiAgICA8cD5IaSw8L3A+DQogICAgPHA+R29vZCB0byBzZWUgcnVtLXJ1ZSBnZXQgdG8g dGhlIHdnbGMgc3RhdGUuIDxicj4NCiAgICA8L3A+DQogICAgPHA+QmVmb3JlIHRha2luZyBh IGRlZXBlciBsb29rLCBJIGp1c3Qgd2FudCB0byBjb252ZXkgYW4gb2JzZXJ2YXRpb24NCiAg ICAgIG9mIGEgY291cGxlIG9mIHdvcmRzIGxlZnQgb3V0IGJldHdlZW4gdmVyc2lvbiAtMDYg YW5kIC0wNy48L3A+DQogICAgPHA+SW4gc2VjdGlvbiA1LjIuMywgM3JkIGxpbmUgZnJvbSB0 aGUgZW5kLMKgwqAgImZvciBhbiBleGFtcGxlIC4uLiLCoMKgDQogICAgICBzLmIuwqAgIlBs ZWFzZSByZWZlciB0byBbUkZDNjQ0Ml0gZm9yIGFuIGV4YW1wbGUgLi4uIjwvcD4NCiAgICA8 cD5JdCBzZWVtcyB0byBtZSB0aGF0ICJQbGVhc2UgcmVmZXIgdG8gW1JGQzY0NDJdIiBqdXN0 IGhhcHBlbmVkIHRvDQogICAgICBiZSBkcm9wcGVkLiBSaWdodD88L3A+DQogICAgPHA+R3Vu bmFyPC9wPg0KICAgIDxwPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0K ICAgICAgPHNwYW4gY2xhc3M9ImRlbGV0ZSIgc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJn YigxNzAsIDIwNCwgMjU1KTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IG1v bm9zcGFjZTsgZm9udC1zaXplOiAxMS4xOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IDQwMDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogMjsg dGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogcHJlOyB3aWRvd3M6IDI7IHdvcmQtc3BhY2luZzogMHB4OyAt d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbi10aGlja25l c3M6IGluaXRpYWw7IHRleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4dC1kZWNv cmF0aW9uLWNvbG9yOiBpbml0aWFsOyI+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogbW9ub3NwYWNlOyBmb250LXNpemU6IDExLjE4cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBm b250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogNDAwOyBsZXR0ZXItc3Bh Y2luZzogbm9ybWFsOyBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBwcmU7IHdpZG93 czogMjsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDE4NywgMjU1LCAxODcpOyB0ZXh0LWRlY29yYXRp b24tdGhpY2tuZXNzOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tc3R5bGU6IGluaXRpYWw7 IHRleHQtZGVjb3JhdGlvbi1jb2xvcjogaW5pdGlhbDsgZGlzcGxheTogaW5saW5lICFpbXBv cnRhbnQ7IGZsb2F0OiBub25lOyI+PC9zcGFuPjwvcD4NCiAgICA8ZGl2IGNsYXNzPSJtb3ot Y2l0ZS1wcmVmaXgiPkRlbiAyMDIxLTA4LTI2IGtsLiAxOTowNSwgc2tyZXYgUGF1bA0KICAg ICAgS3l6aXZhdDo8YnI+DQogICAgPC9kaXY+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSINCiAgICAgIGNpdGU9Im1pZDo0YjZiOTkzMC1kNTgyLWYxZWYtMDlmNC05ZWM1YmQyOWQ1 M2RAYWx1bS5taXQuZWR1Ij5bU3BlYWtpbmcNCiAgICAgIGFzIGEgUlVNIFdHIGNoYWlyXQ0K ICAgICAgPGJyPg0KICAgICAgPGJyPg0KICAgICAgVGhpcyBtZXNzYWdlIGFubm91bmNlcyB0 aGUgc3RhcnQgb2YgV0dMQyAoV29ya2luZyBHcm91cCBMYXN0IENhbGwpDQogICAgICBmb3Ig ZHJhZnQtaWV0Zi1ydW0tcnVlLTA3Lg0KICAgICAgPGJyPg0KICAgICAgPGJyPg0KICAgICAg VGhlIGVuZCBvZiB0aGlzIFdHTEMgd2lsbCBiZSBtaWRuaWdodCBVVEMgb24gU2VwdGVtYmVy IDEyLCAyMDIxLg0KICAgICAgPGJyPg0KICAgICAgKFRoYXQgaXMgcm91Z2hseSB0d28gd2Vl a3MsIHJvdW5kZWQgdXAgdG8gYSB3ZWVrIGJvdW5kYXJ5LikNCiAgICAgIDxicj4NCiAgICAg IDxicj4NCiAgICAgIFRoZSBlbmVyZ3kgbGV2ZWwgaW4gdGhlIHdnIGhhcyBiZWVuIGxvdy4g VGhpcyBXR0xDIGlzIHRvIGhlbHAgdXMNCiAgICAgIG1vdmUgdG8gd3JhcCB0aGluZ3MgdXAu IFRoZSBjb21tZW50cyB0aGF0IGhhdmUgYmVlbiBwb3N0ZWQgZm9yIHRoZQ0KICAgICAgbGFz dCBmZXcgZGF5cyB3aWxsIGJlIHRyZWF0ZWQgYXMgV0dMQyBjb21tZW50cy4gSWYgeW91IGhh dmUgbWFkZQ0KICAgICAgY29tbWVudHMgcmVjZW50bHkgcGxlYXNlIHJldmlldyB0byBzZWUg aWYgdGhleSBhcmUgaW1wYWN0ZWQgYnkgdGhlDQogICAgICBjaGFuZ2VzIGluIC0wNyBhbmQg aWYgc28gdXBkYXRlIHlvdXIgY29tbWVudHMuIChJIGRvbid0IHRoaW5rIGFueQ0KICAgICAg YXJlLikNCiAgICAgIDxicj4NCiAgICAgIDxicj4NCiAgICAgIFN0YXJ0aW5nIG9uIE1vbmRh eSBtb3JuaW5nIFNlcHRlbWJlciAxMyB3ZSB3aWxsIGFzc2VzcyB3aGVyZSB3ZQ0KICAgICAg c3RhbmQgYmFzZWQgb24gV0dMQyBjb21tZW50cy4gSWYgZGlzY3Vzc2lvbiBoYXMgYmVlbiBy b2J1c3QgYnV0DQogICAgICBpbmNvbXBsZXRlIHdlIE1BWSBmdXJ0aGVyIGV4dGVuZCB0aGUg V0dMQy4NCiAgICAgIDxicj4NCiAgICAgIDxicj4NCiAgICAgIMKgwqDCoMKgVGhhbmsgeW91 LA0KICAgICAgPGJyPg0KICAgICAgwqDCoMKgwqBQYXVsIEt5eml2YXQNCiAgICAgIDxicj4N CiAgICAgIDxicj4NCiAgICAgIE9uIDgvMjYvMjEgMTI6MDkgUE0sIEJyaWFuIFJvc2VuIHdy b3RlOg0KICAgICAgPGJyPg0KICAgICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+VGhpcyB2 ZXJzaW9uOg0KICAgICAgICA8YnI+DQogICAgICAgIENoYW5nZXMgakNhcmQgdG8geENhcmQN CiAgICAgICAgPGJyPg0KICAgICAgICBTYXlzIElDRSBjYW5kaWRhdGVzIHdpdGggc3BlY2lm aWMgSVAgdmVyc2lvbnMgaXMgYWxsb3dlZA0KICAgICAgICA8YnI+DQogICAgICAgIERvZXNu 4oCZdCByZXF1aXJlIE1XSSBzdXBwb3J0IGlmIHZvaWNlbWFpbCBpcyBub3Qgc3VwcG9ydGVk DQogICAgICAgIChhY3R1YWxseSwgMDYgc2FpZCB0aGF0KS4NCiAgICAgICAgPGJyPg0KICAg ICAgICA8YnI+DQogICAgICAgIEkgdGhpbmsgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciB3 b3JrIGdyb3VwIGxhc3QgY2FsbC4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQogICAg ICAgIEJyaWFuDQogICAgICAgIDxicj4NCiAgICAgICAgPGJyPg0KICAgICAgICA8YnI+DQog ICAgICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIEF1ZyAyNiwgMjAyMSwgYXQgMTI6 MDUgUE0sDQogICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIg aHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRz QGlldGYub3JnPC9hPiB3cm90ZToNCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGJyPg0K ICAgICAgICAgIDxicj4NCiAgICAgICAgICBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZQ0KICAgICAgICAgIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZQ0KICAgICAgICAg IElFVEYuDQogICAgICAgICAgPGJyPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICDCoMKg wqDCoMKgwqDCoCBUaXRsZcKgwqDCoMKgwqDCoMKgwqDCoMKgIDogSW50ZXJvcGVyYWJpbGl0 eSBQcm9maWxlIGZvciBSZWxheQ0KICAgICAgICAgIFVzZXIgRXF1aXBtZW50DQogICAgICAg ICAgPGJyPg0KICAgICAgICAgIMKgwqDCoMKgwqDCoMKgIEF1dGhvcsKgwqDCoMKgwqDCoMKg wqDCoCA6IEJyaWFuIFJvc2VuDQogICAgICAgICAgPGJyPg0KICAgICAgICAgIMKgwqDCoMKg RmlsZW5hbWXCoMKgwqDCoMKgwqDCoCA6IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNy50eHQNCiAg ICAgICAgICA8YnI+DQogICAgICAgICAgwqDCoMKgwqBQYWdlc8KgwqDCoMKgwqDCoMKgwqDC oMKgIDogMzMNCiAgICAgICAgICA8YnI+DQogICAgICAgICAgwqDCoMKgwqBEYXRlwqDCoMKg wqDCoMKgwqDCoMKgwqDCoCA6IDIwMjEtMDgtMjYNCiAgICAgICAgICA8YnI+DQogICAgICAg ICAgPGJyPg0KICAgICAgICAgIEFic3RyYWN0Og0KICAgICAgICAgIDxicj4NCiAgICAgICAg ICDCoMKgIFZpZGVvIFJlbGF5IFNlcnZpY2UgKFZSUykgaXMgYSB0ZXJtIHVzZWQgdG8gZGVz Y3JpYmUgYQ0KICAgICAgICAgIG1ldGhvZCBieQ0KICAgICAgICAgIDxicj4NCiAgICAgICAg ICDCoMKgIHdoaWNoIGEgaGVhcmluZyBwZXJzb25zIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGRl YWYvSGFyZCBvZg0KICAgICAgICAgIEhlYXJpbmcNCiAgICAgICAgICA8YnI+DQogICAgICAg ICAgwqDCoCB1c2VyIHVzaW5nIGFuIGludGVycHJldGVyICgiQ29tbXVuaWNhdGlvbnMgQXNz aXN0YW50IikNCiAgICAgICAgICBjb25uZWN0ZWQgdmlhDQogICAgICAgICAgPGJyPg0KICAg ICAgICAgIMKgwqAgYSB2aWRlb3Bob25lIHRvIHRoZSBkZWFmL0hvSCB1c2VyIGFuZCBhbiBh dWRpbyB0ZWxlcGhvbmUNCiAgICAgICAgICBjYWxsIHRvIHRoZQ0KICAgICAgICAgIDxicj4N CiAgICAgICAgICDCoMKgIGhlYXJpbmcgdXNlci7CoCBUaGUgQ0EgaW50ZXJwcmV0cyB1c2lu ZyBzaWduIGxhbmd1YWdlIG9uIHRoZQ0KICAgICAgICAgIDxicj4NCiAgICAgICAgICDCoMKg IHZpZGVvcGhvbmUgbGluayBhbmQgdm9pY2Ugb24gdGhlIHRlbGVwaG9uZSBsaW5rLsKgIE9m dGVuIHRoZQ0KICAgICAgICAgIDxicj4NCiAgICAgICAgICDCoMKgIGludGVycHJldGVycyBt YXkgYmUgc3VwcGxpZWQgYnkgYSBjb21wYW55IG9yIGFnZW5jeSB0ZXJtZWQNCiAgICAgICAg ICBhDQogICAgICAgICAgPGJyPg0KICAgICAgICAgIMKgwqAgInByb3ZpZGVyIiBpbiB0aGlz IGRvY3VtZW50LsKgIFRoZSBwcm92aWRlciBhbHNvIHByb3ZpZGVzIGENCiAgICAgICAgICB2 aWRlbw0KICAgICAgICAgIDxicj4NCiAgICAgICAgICDCoMKgIHNlcnZpY2UgdGhhdCBhbGxv d3MgdXNlcnMgdG8gY29ubmVjdCB2aWRlbyBkZXZpY2VzIHRvIHRoZWlyDQogICAgICAgICAg c2VydmljZSwNCiAgICAgICAgICA8YnI+DQogICAgICAgICAgwqDCoCBhbmQgc3Vic2VxdWVu dGx5IHRvIENBcyBhbmQgb3RoZXIgZGVhZi9Ib0ggdXNlcnMuwqAgSXQgaXMNCiAgICAgICAg ICBkZXNpcmFibGUNCiAgICAgICAgICA8YnI+DQogICAgICAgICAgwqDCoCB0aGF0IHRoZSB2 aWRlb3Bob25lcyB1c2VkIGJ5IHRoZSBkZWFmL0hvSC9ILUkgdXNlciBjb25mb3JtDQogICAg ICAgICAgdG8gYQ0KICAgICAgICAgIDxicj4NCiAgICAgICAgICDCoMKgIHN0YW5kYXJkIHNv IHRoYXQgYW55IGRldmljZSBtYXkgYmUgdXNlZCB3aXRoIGFueSBwcm92aWRlcg0KICAgICAg ICAgIGFuZCB0aGF0DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIMKgwqAgdmlkZW8gY2Fs bHMgZGlyZWN0IGJldHdlZW4gZGVhZi9Ib0ggdXNlcnMgd29yay7CoCBUaGlzDQogICAgICAg ICAgZG9jdW1lbnQNCiAgICAgICAgICA8YnI+DQogICAgICAgICAgwqDCoCBkZXNjcmliZXMg dGhlIGludGVyZmFjZSBiZXR3ZWVuIGEgdmlkZW9waG9uZSBhbmQgYQ0KICAgICAgICAgIHBy b3ZpZGVyLg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGJy Pg0KICAgICAgICAgIFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4 dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJ1bS1ydWUvIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLXJ1bS1ydWUvPC9hPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8 YnI+DQogICAgICAgICAgVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZhaWxhYmxl IGF0Og0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5r LWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0 LWlldGYtcnVtLXJ1ZS0wNy5odG1sIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lk L2RyYWZ0LWlldGYtcnVtLXJ1ZS0wNy5odG1sPC9hPg0KICAgICAgICAgIDxicj4NCiAgICAg ICAgICA8YnI+DQogICAgICAgICAgQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24g aXMgYXZhaWxhYmxlIGF0Og0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8YSBjbGFzcz0i bW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1ydW0tcnVlLTA3Ij5odHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydW0tcnVlLTA3PC9hPg0KICAgICAgICAgIDxicj4N CiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCiAgICAgICAg ICA8YnI+DQogICAgICAgICAgPGEgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCIgaHJl Zj0iZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iPmZ0cDovL2Z0cC5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvPC9hPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgICA8 YnI+DQogICAgICAgICAgPGJyPg0KICAgICAgICAgIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgICAgICAgPGJyPg0KICAgICAgICAgIEkt RC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCiAgICAgICAgICA8YnI+DQogICAgICAgICAgPGEg Y2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOkktRC1Bbm5v dW5jZUBpZXRmLm9yZyI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPg0KICAgICAgICAgIDxi cj4NCiAgICAgICAgICA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZSI+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2U8L2E+DQog ICAgICAgICAgPGJyPg0KICAgICAgICAgIEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8 YSBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vd3d3LmlldGYu b3JnL3NoYWRvdy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPg0K ICAgICAgICAgIDxicj4NCiAgICAgICAgICBvciA8YSBjbGFzcz0ibW96LXR4dC1saW5rLWZy ZWV0ZXh0IiBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4 dCI+ZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQ8L2E+DQogICAg ICAgICAgPGJyPg0KICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgIDxicj4NCiAgICAg IDwvYmxvY2txdW90ZT4NCiAgICAgIDxicj4NCiAgICA8L2Jsb2NrcXVvdGU+DQogICAgPHBy ZSBjbGFzcz0ibW96LXNpZ25hdHVyZSIgY29scz0iNzIiPi0tIA0KR3VubmFyIEhlbGxzdHLD tm0NCkdIQWNjZXNzDQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLWFiYnJldmlhdGVkIiBocmVm PSJtYWlsdG86Z3VubmFyLmhlbGxzdHJvbUBnaGFjY2Vzcy5zZSI+Z3VubmFyLmhlbGxzdHJv bUBnaGFjY2Vzcy5zZTwvYT48L3ByZT4NCiAgPC9ib2R5Pg0KPC9odG1sPg0K --------------F26383AD2F41B9FC46CFB327-- From nobody Thu Aug 26 14:11:23 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD593A1394 for ; Thu, 26 Aug 2021 14:11:13 -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 gaqRquGJ59XF for ; Thu, 26 Aug 2021 14:11:08 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 2A2BA3A136C for ; Thu, 26 Aug 2021 14:11:08 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id j18so5550502ioj.8 for ; Thu, 26 Aug 2021 14:11:08 -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=Visefp2ZxBv39OQA4w82gO58FUSn68k43TkaID+/1Qo=; b=hlV0kj0bNUUjyi5gI62HXr2B9Zus0AtmpqzHhEM5j3ialQvtVKVCNOIJX1AKXOzacA 2jyVX4Y1yj6LBkwzYGaaVyxgKLllnKbHp5MyV7UucCv26ZQ8mUEPHqJQLdSUyiDYzKA0 0o0lxdvct0FhFL6CG0rwzc30HUaWqrqYF3PmFYI7wAki2YDhtp4XMj/SCZN3pB1jz8Ty kXUrpPHHSZXIg3/aPwC+9XY9EX7t7BoezoAgL+O6PwQUvSaw0Y/gQ2xKI6UVUoNegS7x 9jH7z3vam1cBqQXb07Mw8tUKd3AEnzAGW2LQb4HyozEqhqLLUVSkctQrJ5zLfKJqQcTf Gdgg== 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=Visefp2ZxBv39OQA4w82gO58FUSn68k43TkaID+/1Qo=; b=TaBBzBTAJdtJ161Niy6bauTyw4+fVzj5o1kb6vuH7uPIkHvG0qBJlxKil9q4V7hUXG O/jG3gX8oCacIWp8Bt4pmtCi0EHS8FQnNvjUO93yXyWIkMr0Q60iHRpt6zrOHwY8wOj+ VzwLxG2ZEkoXICgR2zu87w5KrjrhkYo29O1QBhOSWY3Ro2fG2ggIBnVAG48f0Q/gR/dg kqe0rzN3Q8lu3VLk3ZO0E1ioQMX0p8kkQdRddnTXoj1I2BZUYdVEB3cCY6PDk9M/nWCU jNsWQzZ2TpIkNGEPO4b2HW1dIjqeRVKBRHOR9zExZuCQlI/FvZZ5ETBqVOEEDYfVhq/Y ZuqA== X-Gm-Message-State: AOAM532KllpI7MUZlYBbE4MA2LPubxZyoPi+/TzdeeWZ4wEjNkp9tO1q IqcYi/ZBTI+Z1ugspX2bzoHDpzWgGpmfIMlu X-Google-Smtp-Source: ABdhPJzyI1sVkzVbjCyW6dSnte8D7H0970sxO6bcG+3OqgF7ZcOAFpNxh+kDtIv4sw8GH+aQZle3Sg== X-Received: by 2002:a6b:fb0b:: with SMTP id h11mr4530465iog.59.1630012265943; Thu, 26 Aug 2021 14:11:05 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id b12sm2274475ios.0.2021.08.26.14.11.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Aug 2021 14:11:05 -0700 (PDT) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F1508CC0-FE5C-47CF-A3E5-4786E1258881" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 26 Aug 2021 17:11:03 -0400 In-Reply-To: <11ed9f93-b04d-6577-ba00-86a55e0678b0@ghaccess.se> Cc: rum@ietf.org To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> <4b6b9930-d582-f1ef-09f4-9ec5bd29d53d@alum.mit.edu> <11ed9f93-b04d-6577-ba00-86a55e0678b0@ghaccess.se> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] WGLC for draft-ietf-rum-rue-07 - words left out X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 21:11:22 -0000 --Apple-Mail=_F1508CC0-FE5C-47CF-A3E5-4786E1258881 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Yes. I will fix that. Thanks for spotting it. Brian > On Aug 26, 2021, at 5:09 PM, Gunnar Hellstr=C3=B6m = wrote: >=20 > Hi, >=20 > Good to see rum-rue get to the wglc state.=20 >=20 > Before taking a deeper look, I just want to convey an observation of a = couple of words left out between version -06 and -07. >=20 > In section 5.2.3, 3rd line from the end, "for an example ..." s.b. = "Please refer to [RFC6442] for an example ..." >=20 > It seems to me that "Please refer to [RFC6442]" just happened to be = dropped. Right? >=20 > Gunnar >=20 > -------------------------------- >=20 > Den 2021-08-26 kl. 19:05, skrev Paul Kyzivat: >> [Speaking as a RUM WG chair]=20 >>=20 >> This message announces the start of WGLC (Working Group Last Call) = for draft-ietf-rum-rue-07.=20 >>=20 >> The end of this WGLC will be midnight UTC on September 12, 2021.=20 >> (That is roughly two weeks, rounded up to a week boundary.)=20 >>=20 >> The energy level in the wg has been low. This WGLC is to help us move = to wrap things up. The comments that have been posted for the last few = days will be treated as WGLC comments. If you have made comments = recently please review to see if they are impacted by the changes in -07 = and if so update your comments. (I don't think any are.)=20 >>=20 >> Starting on Monday morning September 13 we will assess where we stand = based on WGLC comments. If discussion has been robust but incomplete we = MAY further extend the WGLC.=20 >>=20 >> Thank you,=20 >> Paul Kyzivat=20 >>=20 >> On 8/26/21 12:09 PM, Brian Rosen wrote:=20 >>> This version:=20 >>> Changes jCard to xCard=20 >>> Says ICE candidates with specific IP versions is allowed=20 >>> Doesn=E2=80=99t require MWI support if voicemail is not supported = (actually, 06 said that).=20 >>>=20 >>> I think the document is ready for work group last call.=20 >>>=20 >>> Brian=20 >>>=20 >>>=20 >>>> On Aug 26, 2021, at 12:05 PM, internet-drafts@ietf.org = wrote:=20 >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories.=20 >>>> This draft is a work item of the Relay User Machine WG of the IETF.=20= >>>>=20 >>>> Title : Interoperability Profile for Relay User = Equipment=20 >>>> Author : Brian Rosen=20 >>>> Filename : draft-ietf-rum-rue-07.txt=20 >>>> Pages : 33=20 >>>> Date : 2021-08-26=20 >>>>=20 >>>> Abstract:=20 >>>> Video Relay Service (VRS) is a term used to describe a method by=20= >>>> which a hearing persons can communicate with deaf/Hard of = Hearing=20 >>>> user using an interpreter ("Communications Assistant") connected = via=20 >>>> a videophone to the deaf/HoH user and an audio telephone call to = the=20 >>>> hearing user. The CA interprets using sign language on the=20 >>>> videophone link and voice on the telephone link. Often the=20 >>>> interpreters may be supplied by a company or agency termed a=20 >>>> "provider" in this document. The provider also provides a video=20= >>>> service that allows users to connect video devices to their = service,=20 >>>> and subsequently to CAs and other deaf/HoH users. It is = desirable=20 >>>> that the videophones used by the deaf/HoH/H-I user conform to a=20= >>>> standard so that any device may be used with any provider and = that=20 >>>> video calls direct between deaf/HoH users work. This document=20= >>>> describes the interface between a videophone and a provider.=20 >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is:=20 >>>> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ = =20 >>>>=20 >>>> There is also an HTML version available at:=20 >>>> https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html = =20 >>>>=20 >>>> A diff from the previous version is available at:=20 >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-07 = =20 >>>>=20 >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at:=20 >>>> ftp://ftp.ietf.org/internet-drafts/ = =20 >>>>=20 >>>>=20 >>>> _______________________________________________=20 >>>> I-D-Announce mailing list=20 >>>> I-D-Announce@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/i-d-announce = =20 >>>> Internet-Draft directories: http://www.ietf.org/shadow.html = =20 >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt = =20 >>>=20 >>=20 > --=20 > Gunnar Hellstr=C3=B6m > GHAccess > gunnar.hellstrom@ghaccess.se --=20= > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_F1508CC0-FE5C-47CF-A3E5-4786E1258881 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Yes. =  I will fix that.  Thanks for spotting it.

Brian


On Aug 26, 2021, at 5:09 PM, Gunnar Hellstr=C3=B6m <gunnar.hellstrom@ghaccess.se> wrote:

=20 =20

Hi,

Good to see rum-rue = get to the wglc state.

Before taking a deeper look, I just want to convey = an observation of a couple of words left out between version -06 and -07.

In section 5.2.3, 3rd line from the end,   "for an = example ..."   s.b.  "Please refer to [RFC6442] for an example ..."

It seems to me that "Please refer to [RFC6442]" just happened = to be dropped. Right?

Gunnar

--------------------------------

Den 2021-08-26 kl. 19:05, skrev Paul Kyzivat:
[Speaking as a RUM WG chair]

This message announces the start of WGLC (Working Group Last Call) for draft-ietf-rum-rue-07.

The end of this WGLC will be midnight UTC on September 12, 2021.
(That is roughly two weeks, rounded up to a week boundary.)

The energy level in the wg has been low. This WGLC is to help us move to wrap things up. The comments that have been posted for the last few days will be treated as WGLC comments. If you have made comments recently please review to see if they are impacted by the changes in -07 and if so update your comments. (I don't think any are.)

Starting on Monday morning September 13 we will assess where we stand based on WGLC comments. If discussion has been robust but incomplete we MAY further extend the WGLC.

    Thank you,
    Paul Kyzivat

On 8/26/21 12:09 PM, Brian Rosen wrote:
This version:
Changes jCard to xCard
Says ICE candidates with specific IP versions is allowed
Doesn=E2=80=99t require MWI support if voicemail is not = supported (actually, 06 said that).

I think the document is ready for work group last call.

Brian


On Aug 26, 2021, at 12:05 = PM, internet-drafts@ietf.org = wrote:


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Relay User Machine WG of the IETF.

        = Title           : = Interoperability Profile for Relay User Equipment
        = Author          : Brian = Rosen
=     Filename       = : draft-ietf-rum-rue-07.txt
=     Pages       &nb= sp;   : 33
=     Date       &nbs= p;    : 2021-08-26

Abstract:
   Video Relay Service (VRS) is a term used to = describe a method by
   which a hearing persons can communicate with = deaf/Hard of Hearing
   user using an interpreter ("Communications = Assistant") connected via
   a videophone to the deaf/HoH user and an audio = telephone call to the
   hearing user.  The CA interprets using sign = language on the
   videophone link and voice on the telephone = link.  Often the
   interpreters may be supplied by a company or = agency termed a
   "provider" in this document.  The provider = also provides a video
   service that allows users to connect video = devices to their service,
   and subsequently to CAs and other deaf/HoH = users.  It is desirable
   that the videophones used by the deaf/HoH/H-I = user conform to a
   standard so that any device may be used with any = provider and that
   video calls direct between deaf/HoH users = work.  This document
   describes the interface between a videophone and = a provider.


The IETF datatracker status page for this draft is:
https://data= tracker.ietf.org/doc/draft-ietf-rum-rue/

There is also an HTML version available at:
https:= //www.ietf.org/archive/id/draft-ietf-rum-rue-07.html

A diff from the previous version is available at:
https:/= /www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-07


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ie= tf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf= /1shadow-sites.txt 


--=20
Gunnar Hellstr=C3=B6m
GHAccess
gunnar.hellstrom@ghaccess.se<=
/a>
--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_F1508CC0-FE5C-47CF-A3E5-4786E1258881-- From nobody Thu Aug 26 14:25:43 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFCEA3A082F for ; Thu, 26 Aug 2021 14:25:36 -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, 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=mitre.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 fKk_hflBFVz1 for ; Thu, 26 Aug 2021 14:25:29 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 B81B63A0846 for ; Thu, 26 Aug 2021 14:25:29 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 29A3D42E007; Thu, 26 Aug 2021 17:25:28 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [10.20.0.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id B12B9336005; Thu, 26 Aug 2021 17:25:27 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 2A98B80C0E0; Thu, 26 Aug 2021 17:25:27 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4GwbVH4Q9zz3D4R6; Thu, 26 Aug 2021 21:20:25 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2102.outbound.protection.outlook.com [104.47.64.102]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4GwbNQ1rTzz3D4RB; Thu, 26 Aug 2021 21:20:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FtJLwyNcO8RYLFTGkGo61mEF507RSXKiKsxLwFBJeew4Mt958oN3wZ+aNdfr9caPyTBrGbADrfO3wBwi5g6YsBBuCK47iL/QYyAjgg6KYXqQ1vw8TXldRQT+pDT7kvP0dmdL6OOz+IND+6wsJ7LXfFll/0ZtUn0xfOrhQ2E2ijPupmd2+fQCv+YV/zTneNMhD2QL4JaFDK9EZe+OTH6GZvNeqImPrO6O+RXKMt2nBvCNB6EoOxHnPV5GZOw3FZvBj+fiPhqWbmE2lVLaADCp26cwX7u+TkdN/CZwhYMLIoEmMBPbQYMBw+ChlOc3J5puomoKJxk9bGEmsHKv3shjFw== 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=aqgfqI5reLLAvsZrNe44ZFkw+FXmM7w457oXyhLBQbA=; b=kRzCK4qfM+A/spZhtLg8m5TmSY85jJrbmXsdA/UwemfJ59YGvank92wznYDwNCT2/wbd3Ai5ZAm/cmPpCaAaxSRWeMPEFMaU1NDGUCA/N7sjze5f0cbaLbab55CIo+RYLRb6V+M2cQnKlZhw3kHuHzehxcpBsxtWKsCuKmnW6G5O516RXr4k54PwP9Vpe6mHtRlGvHn5ADUHYB8ILYfR13MAV/snzWd7z1sg1Gy/1FXprA23QE6aaYvep6y4s2OojzlUEYW/t0yS0BNqtr8vIou6J4ivah7xB2fAWnQSP9N5QqXfDnloHfPY6JpMEl7SE+DYq4Qm857C23snAkPHtw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BLAPR09MB6227.namprd09.prod.outlook.com (2603:10b6:208:2a8::17) by MN2PR09MB4972.namprd09.prod.outlook.com (2603:10b6:208:217::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 26 Aug 2021 21:20:20 +0000 Received: from BLAPR09MB6227.namprd09.prod.outlook.com ([fe80::3534:b411:1c35:7ef1]) by BLAPR09MB6227.namprd09.prod.outlook.com ([fe80::3534:b411:1c35:7ef1%7]) with mapi id 15.20.4436.027; Thu, 26 Aug 2021 21:20:20 +0000 From: Joe Gruessing To: Brian Rosen , "Kyzivat, Paul" CC: "rum@ietf.org" Thread-Topic: [Rum] VRS Provider issues - MWI Thread-Index: AQHXmq9DQWwJUffuVUK0JDe/5f8VbquGSKsg Date: Thu, 26 Aug 2021 21:20:20 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> <0D136565-27AA-4FD9-B372-EEFF5532C540@brianrosen.net> <0fe6934a-fd70-ae55-3201-09c203f11684@alum.mit.edu> <7CD2F56C-BBFE-4112-8473-5529B3057FEB@brianrosen.net> In-Reply-To: <7CD2F56C-BBFE-4112-8473-5529B3057FEB@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ec2b0bd9-a01a-40e2-eaa8-08d968d74f28 x-ms-traffictypediagnostic: MN2PR09MB4972: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gjMX8DpVET59UQkeTIVR8iL5kGR2pvuxCGptoOBeFGV/Vb+ZHGLpcAvvK0xgUag74oH+jfsQag+bMkPie5APmWeb6Wxhf8gJkfkwI2ZSSfCg/ITavAH6Mebd2wcOxczrwlJad209OgwclHhmEvQ7K3iUH7KiMqSESmVLIIyRqYF5zpmhDcxaP7614QUuNWlzok3r8DdAzUnmdPxKcELYYv6VcPVuyQQuxWwOP5Qh0MyQWSUH9vYBlEet5nFRV8C0nbh7xtFyDOYzRiHORMO/5a/EJlScf1vSKyj4q9P6cTGGdloqT40tBvAoT84J5f8xKLcfW985clh233OSCRMUezPyP2Avbe/u93tS5Ngc+e8lokUG+IdTx1R3o70F/SLl8ad0EQ0kPZBqdFOeZ7GmSbeKtNxeKXLV7Ll0eQTM8qScBvIS8F3sw933oXW7eOE9OZIjNfILj/1PwtgUSMDnVL8ZLKfI0nMjOGtYpk/Jj+Uga2ZDeoFHu8y1ESY77q/w+kTVh9Cr/3w/Ios8q/QGNMRb3XYBcPJ9Wl7dGECmXxbFokSBZR8X0JsOdAHTxRHngEXuZr8BP06EiXjMfzqqxw/Iv6qkDPELtZj5QfuqHM5MUWBOZ/MvvxVFnhC6nNipYsxDLqZUSVhb82RPM90pfCvt8hNTkvGWQjPsZlMIY0ZMfcm7wRCLecXdRt++VMEWM7kAyCRYg2Aim3fX0HsB2JAVwKcGguMuX06hdWW+ti2Ot1rjewETUrTdluvgVGbhs0aKP0qPaoGbAzXUFITEHX0YLA3YbRPBXvkkhsjp6LA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6227.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(39860400002)(366004)(346002)(376002)(76116006)(4326008)(66556008)(64756008)(66946007)(66476007)(38100700002)(166002)(66576008)(55016002)(53546011)(6506007)(122000001)(77540400001)(966005)(38070700005)(5660300002)(66446008)(26005)(86362001)(110136005)(33656002)(83380400001)(8936002)(316002)(9686003)(7696005)(52536014)(8676002)(71200400001)(186003)(478600001)(99936003)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RVhVZjNhS0NmbVBnQmhuZlhaVXpFdWxxc3dFWGVkY0RnMDJtNmZnMU1DclhC?= =?utf-8?B?cFdwTnJUeHRndXhPcVBhVmc2NW9GdlcyZk1OL2YwNE5uYlJtd0Qram1FU0d5?= =?utf-8?B?bGN6NWE1YVo0OTl0Qm9BTEhqeCs5Zk4wUEhRK2NaU21UK0QrMGQxK0dWTXpi?= =?utf-8?B?aURVRWRpVVlWM0kySHJPWjQrQzhrbHRENzcrQWxuZWZEMmJteWVaYmN2Rlgx?= =?utf-8?B?SG9ZZ1ZHVVhDLzJ4Ri95NExYZHcyOFFXWEVYcWVLRmtPM2o0QjdtZW1Xam0y?= =?utf-8?B?K3V1bWpHRnJQN3l6UUJMNVNqTVdYdW1xZTBwKy83R2U1UU5GcC8vblA5Nzh6?= =?utf-8?B?MWEyMFdiNUdCNlZGdnk2WUZTY1ZBamhxVmJwb2ljcTYrdCt6WktzMGgvR2Z6?= =?utf-8?B?a1VYVGdJVklIWHI4MEx4M01yVW9XVExkZ3BtblQra25Nd1RNd21YOGpwV282?= =?utf-8?B?V0FUdGFVSGZmaDViQlpvOUdobFJzc0x0Ylc1ak4vYkNobFVXNCtTV0QySllI?= =?utf-8?B?ZG5KZmd3eTNTdXp2elg1SjZHc01xWC96WVRZU0pMNUxnaWNodmFYTUx2Tmox?= =?utf-8?B?V0xaQk8yZFlLOHVZTWlPaFBWanVlYW1tZlVaUHQ3NTgyeGUvUGNGcC9qMXYx?= =?utf-8?B?MVlhU3JxZDNLNklROGtIbmFMWDlqL3BCQ1hBL05yQ3d3VWxwWUhkWCs4TURG?= =?utf-8?B?WE5zMnpCbkdNT0U0SWEzT0pGNnlMNTB0b0llQ1BHcDZxRlhHVHpLUDlMR3V5?= =?utf-8?B?UVJYWHd0aC9KaXVKSVUrdWx1cTlPZkZ2MStka0Zyd2ErZjN5OWZIRlVldlJ1?= =?utf-8?B?Z2xNTTZjOWovLytidE03SlQyZmtCR1dkR0pNSC9VMGRHTGhtc3k2WEEzMk5h?= =?utf-8?B?VU5ZOE5KRndTMDJEVkt5SDJjMWZ1bVo1QzJwZXduNGxWRHNlYWNSNTc2Q09w?= =?utf-8?B?WXFjN1lpK3U5cGVxK0JpODB0c05nNVRtUVh0T21oY1I2NGRIVndiOFFLMmNt?= =?utf-8?B?S2ZkYVc0clVnbm5ZYkJGbHhOSzRlM0ZLYTdtNS9jM2x5RUVydjZSZ3ZnRVJX?= =?utf-8?B?VFIwaU9lam1hN0lVRk85YUtoU0ZQbzVSb2xUTUVxWEtGTjlKRUZFSHFja2Fy?= =?utf-8?B?Zk5CK3NZdjRqTGFsRFJCUkJGa2k5WVliZld3VUREWkZtZFhBYTdCaWdsUWFq?= =?utf-8?B?MjA4LzluWVE0c2Q5c0grZ2FGSEx3Zk1zRWFJOEhnSVRkVWlSakt0YTgvU2lL?= =?utf-8?B?d3MvUEFpMm1PUHF6MW1KZ0tYZnFKcDhiL250c0dTaGdlK0ZaSmRiNkJLcUhy?= =?utf-8?B?Y29DalIwNnlOYUFsUGZEYzV3ZXQwN3NzYnVnSFZIcFZ0d0hmditjMHl1TTJX?= =?utf-8?B?Vi9veUVBRW1NeGo5WExHRnViOWZod1NjZjR3UzBvcmtKQzd3M2kyWktSbE1C?= =?utf-8?B?R1NKTUxJTURXRVNseFlCMHBtRUxpbVM3ZCt6U0VxVkptWCtPV0ZTWkFOaUY0?= =?utf-8?B?M3dyKzBjK2tLcG40VG5KUjlGNnJzTDlJU3IxQWJuSGptajNQVEZiajhzT3px?= =?utf-8?B?R2I4c2FQVE5OZ1ovV042UVJrajM1R254SU5sTmo3NUxldjhMdkFtb3VHNDlG?= =?utf-8?B?Y1o3NGVFT0l4Um11SjdMWDlyeGh0TkNUMU0xQ2pQV0ZjTTZoUWloOU1GVGVY?= =?utf-8?B?a0VxSElWYkhBVkZjR2xOS3g1dk1xV0pmbmcweWdVbGEvcE1Lb0MrSDJCUlR6?= =?utf-8?Q?wQUCpvMRHeRyFtqJ1OHRmboDD06MH5aNq27P+WA?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6227.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ec2b0bd9-a01a-40e2-eaa8-08d968d74f28 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 21:20:20.3575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR09MB4972 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=BTxNELhf; bh=aqgfqI5reLLAvsZrNe44ZFkw+FXmM7w457oXyhLBQbA=; b=otZ0rgwigpaaS9s+MwSOum14p/3rRiJGsc967OZb5pmhCyqfXONu10CCpdlff/3n+QD+5VbY64c0IuWKbDu9i9SxVHBS5kyipdvZ8zWfk3ZJKCCf/urOIV2AJUMvHS8oZULEoW3dtJuA2/zhW8iHfV+LthIB0bw3X1fAn78rlgU= Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 21:25:39 -0000 --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: multipart/alternative; boundary="_000_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_" --_000_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpGb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBOVEwgcm91dGluZWx5IGludGVyYWN0cyB3aXRo IHRoZSBjb21tdW5pdHkgKGluY2x1ZGluZyBhY2FkZW1pYSkgdG8gZ2V0IGZlZWRiYWNrIGFuZCB3 ZSBicmluZyBzdHVkZW50cyBmcm9tIHRoZSBjb21tdW5pdHkgaW4gdG8gcGVyZm9ybSB0ZXN0aW5n IHdpdGggdXMgb24gYSByZWd1bGFyIGJhc2lzLiBGb3IgdGhpcyBwYXJ0aWN1bGFyIGlzc3VlLCB0 aGUgZmVlZGJhY2sgZnJvbSB1c2VycyBvZiB0aGUgZXhpc3RpbmcgVlJTIGVjb3N5c3RlbSBpcyBj b25zaXN0ZW50IGFuZCByZXBlYXRlZDogdGhlcmUgaXMgYSBsYWNrIG9mIG1lc3NhZ2Ugbm90aWZp Y2F0aW9uLCBvciBvZiBjb25zaXN0ZW50IG5vdGlmaWNhdGlvbiBmcm9tIHdpdGhpbiB0aGUgY2xp ZW50IGFwcC4gSW1wbGVtZW50YXRpb24gdmFyaWVzIGZyb20gUHJvdmlkZXIgdG8gUHJvdmlkZXIg YW5kIGZyb20gY2xpZW50IHRvIGNsaWVudCBjdXJyZW50bHkuDQoNClRoZSBleGlzdGluZyBsYW5n dWFnZSBhbmQgdGhlIHByb3Bvc2FsIHRvIGFkZCBhIHByb3ZpZGVyLWJhc2VkIHJldHJpZXZhbCBV UkwgZm9yIGEgUlVFIG1ha2VzIGEgbG90IG9mIHNlbnNlIQ0KDQotLS0tLS0tLS0tDQpKb2UgR3J1 ZXNzaW5nDQpJbmZyYXN0cnVjdHVyZSBFbmdpbmVlcmluZywgUHJpbmNpcGFsDQpHcm91cCBMZWFk ZXIsIEwxMTQNCg0KT2ZmaWNlOiAoNzAzKSA5ODMtMjA3NQ0KTW9iaWxlOiAoNzAzKSAzNDctMjQw Mg0KDQogW0xpbmtlZEluXSA8aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvbWl0cmU+ ICBbVHdpdHRlcl0gPGh0dHBzOi8vdHdpdHRlci5jb20vTUlUUkVjb3JwPiAgW1lvdVR1YmVdIDxo dHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL21pdHJlY29ycD4gIFtGYWNlYm9va10gPGh0dHBz Oi8vd3d3LmZhY2Vib29rLmNvbS9NSVRSRWNvcnA+ICBbSW5zdGFncmFtXSA8aHR0cHM6Ly93d3cu aW5zdGFncmFtLmNvbS9taXRyZS5jb3JwLz9obD1lbj4NCg0KW01JVFJFIHwgU29sdmluZyBQcm9i bGVtcyBmb3IgYSBTYWZlciBXb3JsZF0NCg0KRnJvbTogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9z ZW4ubmV0Pg0KU2VudDogVGh1cnNkYXksIEF1Z3VzdCAyNiwgMjAyMSAzOjE5IFBNDQpUbzogS3l6 aXZhdCwgUGF1bCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KQ2M6IHJ1bUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtSdW1dIFZSUyBQcm92aWRlciBpc3N1ZXMgLSBNV0kNCg0KQWJzb2x1dGVseSB3 aWxsaW5nIHRvIGRvIHRoYXQuDQoNCkl0IHdvdWxkbuKAmXQgYmUgbXVjaCB0ZXh0Lg0KDQpCcmlh bg0KDQoNCg0KT24gQXVnIDI2LCAyMDIxLCBhdCAzOjE2IFBNLCBQYXVsIEt5eml2YXQgPHBreXpp dmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQoN Ck9uIDgvMjYvMjEgMzowMSBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6DQoNCknigJltIGNlcnRhaW5s eSB3aWxsaW5nIHRvIGFkZCBhIFVSTCBmb3IgcmV0cmlldmFsIHRvIHRoZSBjb25maWcgZGF0YS4N Cg0KVGhlcmUgcHJvYmFibHkgc2hvdWxkIGJlIGEgc2VjdGlvbiBvbiByZXRyaWV2YWwvbWFuYWdl bWVudCBvZiB2aWRlbyBtYWlsIC0gYmFzaWNhbGx5IHdoYXQgdGhlIFJVRSBpcyBzdXBwb3NlZCB0 byBkbyB3aXRoIHRoZSBVUkwuIFdlIG5lZWQgdG8gc2VlIHRoYXQgdGhlIHVzZXIgd2lsbCBiZSBh YmxlIHRvIGZ1bGx5IG1hbmFnZSB2aWRlbyBtYWlsIGZyb20gdGhlIFJVRSB3aXRob3V0IGFueSBw cm9wcmlldGFyeSBpbXBsZW1lbnRhdGlvbi4NCg0KICAgICAgICAgICAgICAgVGhhbmtzLA0KICAg ICAgICAgICAgICAgUGF1bA0KDQoNCkJyaWFuDQoNCk9uIEF1ZyAyNiwgMjAyMSwgYXQgMjo1OSBQ TSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFs dW0ubWl0LmVkdT4+IHdyb3RlOg0KDQpPbiA4LzI2LzIxIDE6MzMgUE0sIEJyaWFuIFJvc2VuIHdy b3RlOg0KDQoNClRoZSBkb2Mgb25seSByZXF1aXJlcyBNV0ksIHdoaWNoIGlzIHRoZSBub3RpZmlj YXRpb24gb2YgbWVzc2FnZXMgd2FpdGluZy4gIEl0IGRvZXMgbm90IGFzc3VtZSBhbnkgc3BlY2lm aWMgbWVjaGFuaXNtIHRvIHJldHJpZXZlIG1lc3NhZ2VzLiAgT25seSB0aGUgbm90aWZpY2F0aW9u IHRvIHRoZSB1c2VyIHRoYXQgdGhlcmUgYXJlIG1lc3NhZ2VzIHdhaXRpbmcgdG8gYmUgcmV0cmll dmVkLiBTbyBkaXNjdXNzaW9uIG9mIGhvdyBtZXNzYWdlcyBhcmUgc3RyZWFtZWQgaXMgb3V0IG9m IHNjb3BlLg0KDQpJIGRvbid0IHRoaW5rIHRoYXQgbWFrZXMgc2Vuc2UuIEFuIGludGVyb3BlcmFi bGUgUlVFIGlzIGEgZmFpbHVyZSBpZiB0aGUgdXNlciBzdGlsbCBuZWVkcyBhIHByb3ByaWV0YXJ5 IG1lY2hhbmlzbSB0byByZXRyaWV2ZSB0aGUgdmlkZW8gbWFpbC4NCg0KVGhlIHRyYWRpdGlvbmFs IFNJUCBtZWNoYW5pc20gZm9yIHZvaWNlbWFpbCBpcyB0aGF0IHRoZSB1c2VyIGVzdGFibGlzaGVz IGEgc2lwIGRpYWxvZyB0aHJvdWdoIHdoaWNoIHRoZSB1c2VyIHJlY2VpdmVzIHNhdmVkIHVwIHZv aWNlIG1haWwuIEFzIEVkIG5vdGVzLCBpdCBpcyBhcmNoYWljIGluIHRoYXQgaXQgdHlwaWNhbGx5 IGRvZXNuJ3QgcHJvdmlkZSBhIHdheSB0byBwaWNrIGFuZCBjaG9vc2Ugd2hhdCB5b3Ugd2FudCB0 byBoZWFyLiAoUG90ZW50aWFsbHkgaXQgY2FuLCB2aWEgc29tZSBpbnRlcmFjdGlvbiBvdmVyIGEg bWVkaWEgc3RyZWFtIGVzdGFibGlzaGVkIGJ5IHRoZSBjYWxsIGFzIGxvbmcgYXMgdGhlIGRldmlj ZSBkb2Vzbid0IGhhdmUgdG8gZG8gYW55dGhpbmcgc3BlY2lhbC4pDQoNCkkgd2FzIHRoaW5raW5n IHRoYXQgdGhlcmUgd2FzIGFuIGV4dGVuc2lvbiB0byBSRkMzODQyIHRoYXQgaW5jbHVkZWQgYW4g ZW51bWVyYXRpb24gb2YgaW5kaXZpZHVhbCBtZXNzYWdlcyB3aXRoIGEgVVJMIHRvIGFjY2VzcyBl YWNoLiBCdXQgSSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kIHN1Y2ggc28gSSBtYXkgaGF2ZSBi ZWVuIGltYWdpbmluZyBpdC4NCg0KSSB0aGluayB3ZSBjb3VsZCBhbGxvdyBjb25maWd1cmF0aW9u IG9mIGVpdGhlciBhIFNJUCBvciBhbiBIVFRQUyBVUkwgZm9yIHVzZSBpbiByZXRyaWV2aW5nIHZp ZGVvIG1haWwuIFRoZSBIVFRQUyB3b3VsZCBwcm92aWRlIGEgd2F5IHRvIG9mZmVyIGEgcHJvdmlk ZXItc3BlY2lmaWMgR1VJIGZvciBtYW5hZ2luZyB0aGUgdmlkZW8gbWFpbCB0aGF0IGNhbiBiZSBh Y2Nlc3NlZCBieSBhIFJVRSB0aGF0IGhhcyBubyBwcm9wcmlldGFyeSBwYXJ0cy4NCg0KICBUaGFu a3MsDQogICAgICAgUGF1bA0KDQotLQ0KUnVtIG1haWxpbmcgbGlzdA0KUnVtQGlldGYub3JnPG1h aWx0bzpSdW1AaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J1bQ0KDQo= --_000_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10 YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJY29s b3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZvciB3aGF0IGl04oCZcyB3 b3J0aCwgdGhlIE5UTCByb3V0aW5lbHkgaW50ZXJhY3RzIHdpdGggdGhlIGNvbW11bml0eSAoaW5j bHVkaW5nIGFjYWRlbWlhKSB0byBnZXQgZmVlZGJhY2sgYW5kIHdlIGJyaW5nIHN0dWRlbnRzIGZy b20gdGhlIGNvbW11bml0eSBpbiB0byBwZXJmb3JtIHRlc3Rpbmcgd2l0aCB1cyBvbiBhIHJlZ3Vs YXIgYmFzaXMuIEZvciB0aGlzIHBhcnRpY3VsYXINCiBpc3N1ZSwgdGhlIGZlZWRiYWNrIGZyb20g dXNlcnMgb2YgdGhlIGV4aXN0aW5nIFZSUyBlY29zeXN0ZW0gaXMgY29uc2lzdGVudCBhbmQgcmVw ZWF0ZWQ6IHRoZXJlIGlzIGEgbGFjayBvZiBtZXNzYWdlIG5vdGlmaWNhdGlvbiwgb3Igb2YgY29u c2lzdGVudCBub3RpZmljYXRpb24gZnJvbSB3aXRoaW4gdGhlIGNsaWVudCBhcHAuIEltcGxlbWVu dGF0aW9uIHZhcmllcyBmcm9tIFByb3ZpZGVyIHRvIFByb3ZpZGVyIGFuZCBmcm9tIGNsaWVudCB0 byBjbGllbnQNCiBjdXJyZW50bHkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5U aGUgZXhpc3RpbmcgbGFuZ3VhZ2UgYW5kIHRoZSBwcm9wb3NhbCB0byBhZGQgYSBwcm92aWRlci1i YXNlZCByZXRyaWV2YWwgVVJMIGZvciBhIFJVRSBtYWtlcyBhIGxvdCBvZiBzZW5zZSE8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206Mi4wcHQ7bGluZS1oZWlnaHQ6MTIuMHB0O21zby1saW5lLWhlaWdodC1ydWxlOmV4 YWN0bHkiPg0KPGI+PHNwYW4gc3R5bGU9ImNvbG9yOiMyRjU0OTYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToyLjBwdDtsaW5lLWhlaWdodDoxMi4wcHQ7bXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzJGNTQ5NiI+LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToy LjBwdDtsaW5lLWhlaWdodDoxMi4wcHQ7bXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 Yj48c3BhbiBzdHlsZT0iY29sb3I6IzJGNTQ5NiI+Sm9lIEdydWVzc2luZzxvOnA+PC9vOnA+PC9z cGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToy LjBwdDtsaW5lLWhlaWdodDoxMi4wcHQ7bXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkluZnJhc3RydWN0dXJlIEVuZ2luZWVyaW5nLCBQcmlu Y2lwYWw8Yj48bzpwPjwvbzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjBwdDttc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ij48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkdyb3VwIExlYWRlciwgTDExNDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7 bXNvLWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTMuMHB0O21zby1saW5lLWhlaWdodC1ydWxlOmV4YWN0bHkiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+T2ZmaWNlOiAoNzAzKSA5ODMtMjA3NTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7bXNv LWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Nb2Jp bGU6ICg3MDMpIDM0Ny0yNDAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtjb2xvcjojN0Y3RjdGIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdGIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0 cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvbWl0cmUiIHRpdGxlPSJodHRwczovL3d3dy5s aW5rZWRpbi5jb20vY29tcGFueS9taXRyZS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOiM3RjdGN0Y7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0 aD0iMjEiIGhlaWdodD0iMjEiIHN0eWxlPSJ3aWR0aDouMjIwOGluO2hlaWdodDouMjIwOGluIiBp ZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5wbmdAMDFENzlBOUUuQTQ2ODJE NDAiIGFsdD0iTGlua2VkSW4iPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6IzdGN0Y3RiI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vdHdpdHRlci5j b20vTUlUUkVjb3JwIiB0aXRsZT0iaHR0cHM6Ly90d2l0dGVyLmNvbS9NSVRSRWNvcnAiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3RjdGN0Y7dGV4dC1kZWNvcmF0aW9uOm5v bmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjMiIGhlaWdodD0iMTkiIHN0eWxlPSJ3aWR0aDou MjQxNmluO2hlaWdodDouMmluIiBpZD0iUGljdHVyZV94MDAyMF8yIiBzcmM9ImNpZDppbWFnZTAw Mi5wbmdAMDFENzlBOUUuQTQ2ODJENDAiIGFsdD0iVHdpdHRlciI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdGIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9taXRyZWNvcnAiIHRpdGxlPSJodHRwczov L3d3dy55b3V0dWJlLmNvbS91c2VyL21pdHJlY29ycCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6IzdGN0Y3Rjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAi IHdpZHRoPSIzMiIgaGVpZ2h0PSIyMSIgc3R5bGU9IndpZHRoOi4zMzMzaW47aGVpZ2h0Oi4yMjA4 aW4iIGlkPSJQaWN0dXJlX3gwMDIwXzMiIHNyYz0iY2lkOmltYWdlMDAzLnBuZ0AwMUQ3OUE5RS5B NDY4MkQ0MCIgYWx0PSJZb3VUdWJlIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOiM3RjdGN0YiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5m YWNlYm9vay5jb20vTUlUUkVjb3JwIiB0aXRsZT0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL01J VFJFY29ycCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzdGN0Y3Rjt0ZXh0 LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyMyIgaGVpZ2h0PSIyMyIg c3R5bGU9IndpZHRoOi4yNDE2aW47aGVpZ2h0Oi4yNDE2aW4iIGlkPSJQaWN0dXJlX3gwMDIwXzQi IHNyYz0iY2lkOmltYWdlMDA0LnBuZ0AwMUQ3OUE5RS5BNDY4MkQ0MCIgYWx0PSJGYWNlYm9vayI+ PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdGIj4m bmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaW5zdGFncmFtLmNvbS9taXRyZS5jb3Jw Lz9obD1lbiIgdGl0bGU9Imh0dHBzOi8vd3d3Lmluc3RhZ3JhbS5jb20vbWl0cmUuY29ycC8/aGw9 ZW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3RjdGN0Y7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjMiIGhlaWdodD0iMjMiIHN0eWxl PSJ3aWR0aDouMjQxNmluO2hlaWdodDouMjQxNmluIiBpZD0iUGljdHVyZV94MDAyMF81IiBzcmM9 ImNpZDppbWFnZTAwNS5wbmdAMDFENzlBOUUuQTQ2ODJENDAiIGFsdD0iSW5zdGFncmFtIj48L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iMTYwIiBoZWlnaHQ9IjIwIiBzdHlsZT0id2lkdGg6MS42NjY2aW47aGVpZ2h0 Oi4yMDgzaW4iIGlkPSJQaWN0dXJlX3gwMDIwXzYiIHNyYz0iY2lkOmltYWdlMDA2LnBuZ0AwMUQ3 OUE5RS5BNDY4MkQ0MCIgYWx0PSJNSVRSRSB8IFNvbHZpbmcgUHJvYmxlbXMgZm9yIGEgU2FmZXIg V29ybGQiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gQnJpYW4gUm9zZW4gJmx0O2JyQGJyaWFucm9zZW4ubmV0Jmd0OyA8YnI+DQo8Yj5TZW50 OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyNiwgMjAyMSAzOjE5IFBNPGJyPg0KPGI+VG86PC9iPiBL eXppdmF0LCBQYXVsICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7PGJyPg0KPGI+Q2M6PC9i PiBydW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdW1dIFZSUyBQcm92aWRl ciBpc3N1ZXMgLSBNV0k8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFi c29sdXRlbHkgd2lsbGluZyB0byBkbyB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SXQgd291bGRu4oCZdCBiZSBtdWNoIHRleHQuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccmlhbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBBdWcgMjYs IDIwMjEsIGF0IDM6MTYgUE0sIFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBreXpp dmF0QGFsdW0ubWl0LmVkdSI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9u IDgvMjYvMjEgMzowMSBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6PGJyIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFy dDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+ DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPknigJltIGNlcnRhaW5seSB3aWxsaW5nIHRvIGFkZCBhIFVSTCBmb3IgcmV0cmll dmFsIHRvIHRoZSBjb25maWcgZGF0YS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpUaGVyZSBw cm9iYWJseSBzaG91bGQgYmUgYSBzZWN0aW9uIG9uIHJldHJpZXZhbC9tYW5hZ2VtZW50IG9mIHZp ZGVvIG1haWwgLSBiYXNpY2FsbHkgd2hhdCB0aGUgUlVFIGlzIHN1cHBvc2VkIHRvIGRvIHdpdGgg dGhlIFVSTC4gV2UgbmVlZCB0byBzZWUgdGhhdCB0aGUgdXNlciB3aWxsIGJlIGFibGUgdG8gZnVs bHkgbWFuYWdlIHZpZGVvIG1haWwgZnJvbSB0aGUgUlVFIHdpdGhvdXQgYW55IHByb3ByaWV0YXJ5 IGltcGxlbWVudGF0aW9uLjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5UaGFua3MsPGJyPg0KPHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlBh dWw8YnI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7Zm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+QnJpYW48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPk9uIEF1ZyAyNiwgMjAyMSwgYXQgMjo1OSBQTSwgUGF1bCBLeXppdmF0ICZsdDs8YSBo cmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8 L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQpPbiA4LzI2LzIxIDE6MzMgUE0sIEJyaWFuIFJvc2Vu IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGRvYyBvbmx5IHJlcXVpcmVzIE1X SSwgd2hpY2ggaXMgdGhlIG5vdGlmaWNhdGlvbiBvZiBtZXNzYWdlcyB3YWl0aW5nLiAmbmJzcDtJ dCBkb2VzIG5vdCBhc3N1bWUgYW55IHNwZWNpZmljIG1lY2hhbmlzbSB0byByZXRyaWV2ZSBtZXNz YWdlcy4gJm5ic3A7T25seSB0aGUgbm90aWZpY2F0aW9uIHRvIHRoZSB1c2VyDQogdGhhdCB0aGVy ZSBhcmUgbWVzc2FnZXMgd2FpdGluZyB0byBiZSByZXRyaWV2ZWQuIFNvIGRpc2N1c3Npb24gb2Yg aG93IG1lc3NhZ2VzIGFyZSBzdHJlYW1lZCBpcyBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpJIGRvbid0IHRoaW5rIHRo YXQgbWFrZXMgc2Vuc2UuIEFuIGludGVyb3BlcmFibGUgUlVFIGlzIGEgZmFpbHVyZSBpZiB0aGUg dXNlciBzdGlsbCBuZWVkcyBhIHByb3ByaWV0YXJ5IG1lY2hhbmlzbSB0byByZXRyaWV2ZSB0aGUg dmlkZW8gbWFpbC48YnI+DQo8YnI+DQpUaGUgdHJhZGl0aW9uYWwgU0lQIG1lY2hhbmlzbSBmb3Ig dm9pY2VtYWlsIGlzIHRoYXQgdGhlIHVzZXIgZXN0YWJsaXNoZXMgYSBzaXAgZGlhbG9nIHRocm91 Z2ggd2hpY2ggdGhlIHVzZXIgcmVjZWl2ZXMgc2F2ZWQgdXAgdm9pY2UgbWFpbC4gQXMgRWQgbm90 ZXMsIGl0IGlzIGFyY2hhaWMgaW4gdGhhdCBpdCB0eXBpY2FsbHkgZG9lc24ndCBwcm92aWRlIGEg d2F5IHRvIHBpY2sgYW5kIGNob29zZSB3aGF0IHlvdSB3YW50IHRvIGhlYXIuIChQb3RlbnRpYWxs eQ0KIGl0IGNhbiwgdmlhIHNvbWUgaW50ZXJhY3Rpb24gb3ZlciBhIG1lZGlhIHN0cmVhbSBlc3Rh Ymxpc2hlZCBieSB0aGUgY2FsbCBhcyBsb25nIGFzIHRoZSBkZXZpY2UgZG9lc24ndCBoYXZlIHRv IGRvIGFueXRoaW5nIHNwZWNpYWwuKTxicj4NCjxicj4NCkkgd2FzIHRoaW5raW5nIHRoYXQgdGhl cmUgd2FzIGFuIGV4dGVuc2lvbiB0byBSRkMzODQyIHRoYXQgaW5jbHVkZWQgYW4gZW51bWVyYXRp b24gb2YgaW5kaXZpZHVhbCBtZXNzYWdlcyB3aXRoIGEgVVJMIHRvIGFjY2VzcyBlYWNoLiBCdXQg SSBoYXZlbid0IGJlZW4gYWJsZSB0byBmaW5kIHN1Y2ggc28gSSBtYXkgaGF2ZSBiZWVuIGltYWdp bmluZyBpdC48YnI+DQo8YnI+DQpJIHRoaW5rIHdlIGNvdWxkIGFsbG93IGNvbmZpZ3VyYXRpb24g b2YgZWl0aGVyIGEgU0lQIG9yIGFuIEhUVFBTIFVSTCBmb3IgdXNlIGluIHJldHJpZXZpbmcgdmlk ZW8gbWFpbC4gVGhlIEhUVFBTIHdvdWxkIHByb3ZpZGUgYSB3YXkgdG8gb2ZmZXIgYSBwcm92aWRl ci1zcGVjaWZpYyBHVUkgZm9yIG1hbmFnaW5nIHRoZSB2aWRlbyBtYWlsIHRoYXQgY2FuIGJlIGFj Y2Vzc2VkIGJ5IGEgUlVFIHRoYXQgaGFzIG5vIHByb3ByaWV0YXJ5IHBhcnRzLjxicj4NCjxicj4N CjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7IDwvc3Bhbj5UaGFua3MsPGJyPg0K PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9zcGFuPlBhdWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 YnI+DQotLTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48 YnI+DQpSdW0gbWFpbGluZyBsaXN0PGJyPg0KPC9zcGFuPjxhIGhyZWY9Im1haWx0bzpSdW1AaWV0 Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJ1bUBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcnVtIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J1bTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_-- --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=341; creation-date="Thu, 26 Aug 2021 21:20:19 GMT"; modification-date="Thu, 26 Aug 2021 21:20:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUSAAAFEgGIfCirAAAB AklEQVRIie1V2wnCMBQ9FUPyqRPYEeoE1g3cwBXqBOoEOoJOYJygIxg3cIR+pvRDSUnhGtOP2lZB PBCSexPOyYX7CBgXJwAL9ANpBO49kZcY9EleJ3ADcLB7awwdggzAtMh1xrgYAbgACLuMQBpyc7D7 sW0ErkBsf15h1lbAl0UKwNmSx30IdApfFs3JUiSqyr+yvi2AcZHrwOzWfoWJgC76gHGR2ruU+CLG hbfyGReJy9e40IpcqyLXsuZu79bPW5XMuNiQX+6ca0WNxgI2jdfElThPrq0EAEQe0dp0/kqz+wt8 VsCdB2WOE7OaBSHxTzw8S5JJTx34N2ayt690AkA+ALsWRF/Krkd1AAAAAElFTkSuQmCCAAAAAAA= --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=480; creation-date="Thu, 26 Aug 2021 21:20:19 GMT"; modification-date="Thu, 26 Aug 2021 21:20:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAUCAYAAACXtf2DAAAACXBIWXMAAAQ8AAAEPAEZaCRCAAAB jUlEQVQ4ja2UPXLCMBCFn5E0UpeUSQddSnKCcAS4AZQp6ZIq5AZQpoIbhJwgpEsHnACOQDppxE9m M2vGeGRsTXgzHkvy+lvtSrsgKW3qiBDZK23elTaHzDNX2rRSitKmq7RpJzyZAxh5ZydlbpQ2TQCf AK4LTGYAmjxupA4OvND3zg5LHKwAVIn4FcBV3gFpCqDnnd0E4C3efVV1agHDNoCV0magtMmnoVUR vOFNTgXNhJSUs7uMgWHYE30TUt4KKQ2npoqTb+9snwYJ77JecnCxmnpnO/RPjeFzDutSWqacmnd2 wfCoWijR+uiA36MLwsG18KckHShtxgC6F4AvvLP36UQcB1Iu+ZCbhb9W0/N+t12EIogtopDW3tlG dv0YwX63XQsp6/+MoEOcoAN28iGkTCIqNquhd/Ytv5iELLn4xtw2qmjine2F7JIAmKAvEXVRCAe3 igGABwbGFBvlmto7dd9Cif1uOxNS/gC4yTW8c2Dq9Y/cBc4qlCI64PQmUWRfGfDMO3tyS84KwC/b snjTWCpZ6gAAAABJRU5ErkJgggAAAAAA --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=295; creation-date="Thu, 26 Aug 2021 21:20:19 GMT"; modification-date="Thu, 26 Aug 2021 21:20:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAARCAYAAADHeGwwAAAACXBIWXMAAARkAAAEZAGL13mEAAAA 1ElEQVQ4jbWVvQ3CMBBGX/6UlIyQEaCjI4zABrABGyAmYAQYgRHCBGQDMkJKWy5Ah4yUBmGb+Gss y9a98/nzOQEoyqoGDoCMc2BGmAagA3rgaLTqExv8/kfQbxLYIsvy/AQsJw4uqiTp1JYllmop0TMi gNRxn1zcJSZgMFrt5NKANgbgLaNVZ7RaAxtrxWkBI9DVnuYnJAhQlNUeeLg4MPcM3ABnH2u72rSz L7PxScgHEKzU13aealNXuwUqfjcd/wdbYGUXZe7bBKUSn2rcpLUYrfoXGVA0JYXp1vUAAAAASUVO RK5CYIIAAAAAAA== --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=461; creation-date="Thu, 26 Aug 2021 21:20:19 GMT"; modification-date="Thu, 26 Aug 2021 21:20:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB eklEQVRIibWWMXKDMBBFv0EaKClTkhu4TGlO4BwhdGl9EvsG9hFCmQr7BjkCR6CEwXYyy6wYEEKD BvIrW5bfF7t/NWxgkQzCdwB7ADsAsbazAHAFkDV19TVFMRrIICTg2QCdEpmlTV1d9d89A/wIIHeA g/fm/N+BfA1Op/50AOt684WIn497ptY7A3Z3gVM5SgAv2vrWFyJ6Pu7fUD3gmuczoCXXetBUGYQ5 B6GvhHqienCeCU9sidHUMgVHcU5DL01d/fROHVE5+Gtk2B8TW3DO5+imwfOewZT2nqF2Uyp769sZ cNLOc8y7q+LRoK2tjQzCXwszMY2/Lhtj8RPIILT2wuOLaolsPSwEj/zHxIajDEKVnoOaAz61uths BlcyyCwG/cePtM9z4p15PPpLy2RSQWzV5PQfDFpma8BRPK0IP6l4dzFt6upAF9oK8AuzAH0OmrpK Fz4JnXxQ7tGgsXvi2HjaS1PfnVyJYjoS1+9Ve20xQe2vLQD+ALaKgDHuS7cwAAAAAElFTkSuQmCC AAAAAAA= --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=497; creation-date="Thu, 26 Aug 2021 21:20:19 GMT"; modification-date="Thu, 26 Aug 2021 21:20:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB nklEQVRIib1WwXHCMBDcMHjspzsIJZAOoIN0AKmApBQqAHeQDqAD6ABTgf20xw8yR/Y8hywRCE52 RjMgnfZOq5XkJxhEcTIBMAPwCiC1YzegBPAJIGvqaqvhbYIoTlYA5neShrBu6uqtTeCQayVHANsb CWXlz87Kv5OILFGcnNh2UZzcK00LmUsO5ZsMqLlWPm3qqvwF8UYIAbwLB7lw5o7ipGC21Q8kI65W 2sj0j03FJ/at+L8YGM2OAWIh3AE4ANiwHSjFpKmrPYA9w7cOVwqrl4d8bqsLtLmuxCnqHD+8Iokk VNlE06WpUMYWXL3IkVvvu0TeFRg3FLY6R3vdv51H1jPvIJBUNlFJl9T5Auxbsm9sN97CmwCADb52 2OzYXQl6QyhBbn533BUYy30B3gRNXeXG24vQJtNJgj3ndBC0KYAPHiqxolwFIZtqrB99HTRnntem nQRNXa15eXVsyr4pY1y0XEOe0pT3eQc8oS/0uVoxD2lOKFd5cfM98hYo+Ca0N7RIlHFMN/OhB8cY Q5D9+ZP5P4++SdLvZwuALwyUvZfl03noAAAAAElFTkSuQmCCAAAAAAA= --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=5361; creation-date="Thu, 26 Aug 2021 21:20:19 GMT"; modification-date="Thu, 26 Aug 2021 21:20:19 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAXEAAAAuCAYAAADeKCkyAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAAIdUAACHVAQSctJ0AABSDSURBVHhe7Z17kGN5Vcezr+5O7iMz3Unu7Udy MygoUJSUCFuAuIAiWLhsKTvOTHeatSxFKBQpRSgf1PherC2FeXR6sXzVAoUvEF1h/1AKEQEXRQXf YIEotWKxvpZlV9l119/59Tm/OfeX8/vdm04ynQz3U/WtyT3ne04607mnb27uo1ZRUVFRUVFRUVFR UVFRUVFRMRUap/deGO3uP+oS2g5NOBg+JPUF1Qd7f4A2J1IdqDEY7mnDC84tS/lpSPdXSLnDKNjZ vwNbikg1E2mw9wxsPTWa7a3/xYdTJ+70/+7Y+olHbWFaJOpk/yLVxMnW09CSg/K4OALlm63+gxji XMfqlyEQpSd+gMUMFLPjRFE+TrPf4R5So9VbR0shUj1XrbYWoVUjebiiNPsNtI7QTLOPSzVBkj0H LQbJxxUl2S+g1RCn/e+mPIa88H4uoVXjyxFxkt3GPc2kfxemiCWeJ8VJ/+cxPxtWTu/fKw4AFNoO jdSTC21OpBrQIg5xLmydQ/JNpAUa4tKbnwttOSQfV5T234tWA+VwcQRejyFD1O79s50rM8TjpPcP GDbwPIYMPCcp7PReilYvUq2tOOl+G9pL+UFoN0gerrDT/whaNZJHEto1l3uIqz+iP4Ipg+2xhrj5 A+8S+qaPuPIzNXaGf4jWsVnZ3n+m1JMLrU6kGtCiD3EQtjdInom0IEN8qbXxOHqjR2vdF2G4trSa Pt61EjTT/v9RPFzrfwHDtZXjG12r5rqDzAEsLqL6vs3loTjPlRnidg5w5Zpp724pFyW9F0pxHy6/ GlAvk3JSDAiSpMNzofq9YKoWr/UfpLjaGn8Iw7X6WneD16jQykHG83PFW6tWrnGQOfwQV3Ufgp9f Elo15OfClMHO8yHO4xjS8Hicdn8Jw9NFXPktoXVspF620OpEqgFdCUMchE+hkfITaUGGOH+jY8ig htftQdr/FC4afDWAK++rIcizcizNMKShON+yLDvE1R+HhzGl4TkMaVxxoNHqfTXlwqT3Ggw78fVS nw7eaed8foByYWvrnzBUuobnpRiHcmHSfwuGDj/EO9kfYcgL+bkwpWk2s2N2XhriQZp9HkMGiMdp 70dxcfqIK7+l2k1vOIb2sZB62UKrE6kGdKUMcRA+zZfsEI+S/l/QStBIe7sYdgK7E8hfU1tvGM5B ee1hSDEbsbbdDqXaoiGu/gi9kuXNliXFME6YfarB2uazMXZoHM+hiTrZ0+2czw/Y+aDTfR4tu/bV 809MGCr9PEGyYXb1HPUQj9v9v4WYej2PUL7MlvjsufGNibjyC8KK0gQ7ex+U+thqbA+9f6GkGtCV NcTPXj2T51mcfeJX8ZUAZG8Fc7gPQyPESf+PJU9RHUAe7oNdBVJt4ZZ42r/FPGYeKRanm5+1Y5Mg PQcBnwzsnM9/XXvjyZSLO71fhZjPT4Rp/622x1fHhySGNEcxxMNO9qeYNvmwvfliesyHuP0Fe5B2 78PUbAm2h3eJK78gLCmN1ENSODj/CJaISDUgM8QLkGpJaClEqgUtndl/LFq8NAa3v0Cq5wKfFCfp RnPArL7YDNu9Z/KVgNRsZx9Gi4HnMTRCM+k9V/IU1QHNdu81to+W7doyQ5wvx0n3VC6vBMtAs7X1 P3ZsEvhzwBEfIPXH6E4eB6E951fD9B4t9fvmcRDaxddgA0cJ+epcUrZrDtwHHHaIS1LD9wfRZuD5 qN19CT3GtMnzx3yIAxS3FXS2noSW6SMNC5eKtphzbN96XOrhElaJSH7QIg1xQupBKpOfB2Y1xAk1 OP5RWhFU6qoDR35lwdAIYZi2JU9RHXHJtxrzZTXgf00bkLJDPG71H+A+k8dlgA9MDGnU4P0E90se CanGlrLpT4GAlLelbEsHbvk1jNBsmn3JGCn1PFGavQftmss5xPkyPK53ui+ScvYQR66mvC3MTxdp WPiEZYXA1rVU7xKWiUh+UDXEj4ZZD3EibHWf5VoJpJiN2ur8MclTVEeQL+5031VbOd5z1ZUd4gDF 4iT7gMkrYdq5JT6LIQ5Hu6DNIPm40Gbw5Yig3XuF7fHVwZfGlAs6vVsxfFl3p/BleEy7eNSnO32o KOUcQ9xAPpL6vX8GU9NDGhY+YVkhUq1PWCYi+UGLOMQb2xd3pT4gyEtxkm4wB1yuIU6oLdh7aSVo tDeeDDG+ta5NApS3PUV1BK9vJO7nG2eIq63LXzdxJkzXgnTzU3YMUH9IXqaG0Q+DpDoX43gBl59i MMwwpInb/b+R/Bw4ksX20LKrTspf7iHewD+c6jXzL2b1Lh5aLhriBPmxxzQ5e7U0LHwKT537Nyx2 Emzv/7JU61NjZ29kq4CQ/KBFHOLB9t4pqQ8I8lKcpBvMAbMa4rBPfLnZeQwu5qAVQA2Nb4TllePr ZsvYdeIL5UEY0kgxCbUV+PW8h6tunCEOmDgTpjQUaybZJzCUw1UnMY4XcPnVQPs8i197ENWsUDzq 9H8GYzkoj7UaKcaR8pd7iEfRxhqPURygZXuIu56riUe28B5TIdy++F3SsCgSljuRasoIy0eQvKCF HOK7wwekPiDIS3GSbjAHzGKI0xtcfJNHkVmZasePdzHqrQnT7DzlQseXT7johbykKMl+ElOGcYd4 kGw+2+RQmNK44gDfZy7lbcbxAj6/K+eKA2Gnaz458GPrfTWAlL/cQxzgMSluhnhw6WSoeH3zszrG oBwIQ9NBGhRltPTtnsF1w3uvlWrKCDuMIHlB1T7xo2EWQzw4tvUk/kZXK+yHmusnvpNvwYDQrlle 23wOzwVp/37pOipoN9h5W7D/Ga3SSmy+XCXGHeKAyaEwrIHT4HkOXlec9D/DYyQscTKOF/D5Xbn6 6qWjT0DxWv+Bot+DnXMpTLqvxZLcEHcpSvu/iPZSz9FM+x9Au/j6eEx94jMHdlCMb4lzLyhOsh+K kr45R0DH0v5fo306SIOC1NgZvl+Kk7DFCJKXFJ4+/6AUJ2GLESQvaJGG+MqZC0+X6rnAJ8VJutEc MKvdKY321vP5G96WspijKIgo2XqT5CWhLYfk4+JDvJFu/hfPYTjHYYZ4rbZVN3mrDoALTfE8V9ja +jp6jHYnvA5DXnx+frSPnY/S7s/ynC20GSSPLTgBDO2aoxjicdp7nR0DKGbvTmm2N0cOx+RC2/SQ BgWpTF5C8pJqJ88uSXESthhB8oLmZYhH6ueQcuOo9pSX6ut7SDlS7Xm3BWNrBsxqiBONtHsLbH3C m149vk9t1X0/ppyoj+rvol0NzVb2ufrq5hamRojT7K+8Ur3QWguOJ0+keJT0PorhHA01pMmDIY2p 61y6FgyH8nYdB7bcaADAFR4xbGpx0UmZ5+AU+YvyavC+g46wabb69y63u1+GqRy8DxfscgmS5Ilo yxGmvZNSDVeQZD+Odudz5JRkb0a787X5YmqI72MoR5T2PkpfiOIlCkY2QKaCNChIRflwd3/kl1g/ vf8tkpcEHilOWj49fK5uZCF5QVfUEEek3CTCtlNl1kO8oqKiBCtn9m6QVnoSeOq7t3+vlCPpRgzJ QwoGF/4MPMHp4SelPCg8s/eXupGF5AVdKUMcn0Ij5ScRtp0q1RCvqJgDgp2Ld0srPUgNR7MDX8qT Vnbf1EObRvKQ0FJbunn/CVKehLYckg90JQxxbG+QPJMI206VaohXVMwB0gpPggtKoa1wqKCtFgyG H5HyJLRppDwJLTkkH2jRhzi2ziH5JhG2nSrVEK+omAOkFZ6EFs3Kqb2u5CGhzdsvOLP3fWjTSB4S WnJIPtCiDvHaLb9iLo5vI/knEbadKtUQr6iYA6QVnoQWg+QhNXaGb4cjK6QcCdsYJA+pdvJsiDaD 5AMtwhAPz1z8dGN3+M3YphCpByncGb5uXGHbqTJPQzxqbTwuTrLTzfTESbWYu4PPohAl3RvhNYxz 78yKS4Rp7wnw/xe2ey9Wi/xs0isbaUiApMvChmfOfUHyknwXuxL77Z5/WPKCgt3hn6DNIPlA8zLE fXmQSo+cIOJCqieh5ciZxRCnw+h8itdPvA/t5roWklbYWZ1AM+n/lOTjUrbSvyNC6DEWdj0p6nRf hZYRbC+Gc9geSREeuy7lbIXr2VeW9YKvCONNktwhsL4+Utx1AhQIzvJFm6aZ9n9P8nEpW+49YOU8 ZObSAy6hUUPLcL9W+Ff9bN5LcYs0ti/+ljQkQPXB/t+jLYfkLaPazutHjtetb1+8SfKS0GaQPKB5 GuKAlCehpRCploSWI+eoh3gj6f+nlOeqr6VfoxsrygxxENpLEXR63zBJvV1rq5n23obWHLZvOUlO YMpgeyTNaojDsdHg9UFeNYTfgSEN74MhDdxk2o7DPVW5X1IUbXwF2ksNcRDaNa74KMVDHIRm3Rf+ hSGuPkF8LGr3C+9kNUJ4+vwXpSEBQssIkreMsHwEyUtCi0HygOZtiNd3L7xK8pDQ5kWqI6HlyJn1 EMeQi2s93tzKhLHcEMeQIUqz36dc3OmKGzASVMOFqUIa7c2vYjW570e8/cKwxfMuny9nQ74g7X8S Q058fX05G8kbJf0hj4dp9+WYkvzmFnYspoGbH0s5PsQxZFDvgY9RTv1h+W0Mj/GaLg1xDBikM37p Xz3ED3savjQgSGgZIRjsv1vy+1QfDP8by0eQ/CS0GCQPaN6GOBAOhg9JPlA4OKc/PvmQ6khoOXKO cogX+eACVSbfaOl9zL4hDlDOlZcgf9zKPkeP4QxFTHtprmdvphoM2YhffFMNKOr0b3X14D4MOSHf pENcfTRJTK+kK55xSaiB+q92H1rmwpTJhe3up/ky93DCJHuLyYfrLYj5hjhAOZ6XYjLuIQ5YfaZz 5qY0IEhoEZH8PtXOHtw3UkLyk9BikDygeRzigOQjLe9c8N78VqohoeXImechDlCePtrPcojXVldj frEnTHsJVvO7YjBciF3jqrd9Psg38RCvrcamV8EQh8sN231oGS6X4MqF7exb+TL32FC+mW7pS2cf 5RAHKB+rrX4MTYL/GuJoEpH8PmGZSDhwf7lZ39l/K9o0kgc0r0O8dvPP1SUvCV0ikp+EliNn1kMc hq4ttLGVc/RynwTvBctQz5c5caf/bsrxm+L6aLIaWF6KNh/Ll8tAfq5w/WCr0QX5grVMbwjQsvoj 8pvagFAcZP8/gtCmIR98z2D74EYUaNPwvhgy+HIStpcv88fSLfZoGW5IgaERyEN13t0pSf/PKQdb 8Rge6eGm/BAv7lWC+uDi9dKAADV2Ln4cbSIrOxdukeokBWf2cl9a2AS7w9+V6kD2ES2SBzS3Q1xR 3774HslPQtsIkpeEliPnKL7YRNulFdizRWPXwUDiMZd0cQmkGloO060bMFQI78O1tLauv0jkqK3Q l1MeQ+LPAfC4JLRppDypmfbuRptG8thqJptfRLsX8kftnv5Sj5btx1GSvZ8vA7TM91/bkIfq+BD3 SRcjrvgol3mIS8OBFO7u34Q2J1KdJLR7kepIaNFIedA8D3FA8nOhLYfkI6HlyJmHIe66oiBg15UZ 4rqwJFQTpNmdGJpkJV3mtaSm9amA5zAE1x1/rR0DuFcS2jRSnjTuEA+S7CfQWgjVwCcA++gTk2N3 nKccQMtR0n07hkaw68oMcV3I8OXyzNEQR4sXqU4S2r1IdSS0aKQ8aN6HOCDVkILB6KcVyWe0vf/q cVU/fWEDW0+NedgnTl9ySdi9+BDXBsWyClJMDZE3YrgQOHTR7gXEaf8eKT4O/GO93aco3ljvPQVD pf8vAfIddp+4FCtD3Om9j9eCYrXVDTk4agOW4WeiHP99U8z+I8MhDwiWpd0p9bWtp1JMvQe+B8MG yvEamQUb4jU1FKRarvrOULx+so1US6rdcNaceSXlQYswxJe3h4+R6kgr27dlaNVInok02HsGtp4a V8oXmxSz4z6KLvoPUrZJzhw1N4uI0x6d+HYN7y9JDbz70TvW62L1h/5ik2LNVv9BDBWycnyjy/uB orVLx3Xbufrq5vWYKvX6KE/fnbj2iVPMjgO+XJ7CIX4V5e0bXRwKcUVHoaUQqZYLbYVItaSVwd5L 0Ob0LcIQB9TW8H1SLQltGik/kb7EhniY9N5g8sePNyHmGuIxu5NQkPR+GsNeyO8T7MdFuxM1VB5R W5734GIO6kP7/eN2Zu4o75MuVkgxF+SbxhC340XwOru2bA5DOYJ2dqfJt9v6Mh6uIa62wF9B8UZr 6zswrKG4XTOKf4iX71OCpZvPjX0ZWIng1PB+qR4UDs49jLZCgp29D0o9SGhb+CEOSLVcaKuGePEb PbdVijGDlHMNcUDye7iavEHSfyXGDGV7cR+c+INhTdhe/1rTA09L535tYoTt3s12zue3Id8kQ1xh fidwf02MFcL7gTCs8eUU5oQv+GOIsQPirVWpzjXEAckPuOKjuIc4fEIq36cEwc7wneKKrqQGauEt sDhSD1Dt5Ov11k8Z6jt7T5V6kNDmfK5FGuKAVM9VxjO2rrwhDiukOVnEJbitGtq9QzxIe3dTrp50 b8SwiHSkBAc+uvvyHPL5hFbjjZKu+FGc8mGS3cGXQdrggXt9sr26mOHLueA1dp0vBzTSrdyZkJLg ew+0e4d4vdP/D8qttLrPwnCp/5sD56Uh7tOBd0LElRzF90GXQeoBwnRppB4ktDg9izbEG2eGz5d6 kBqDvVdL8Yl0BQ5xgA9fW7UwbKNN4xviQK7WQwlfSPmotflNGHPSTLOHeE8utNQidoQGhkaw6+xl H9zrk+3VxYwwvfSJQMpL8JtBh+3swxjWhEnvLsrV29m/YzgHv/+oLZXOXQ3VN8QBq1bDYy4dOP1D PG6V/3RSzM652KlxGdwRTKWP1INESDnQDWed1+XOIdWSyiLVgmqPjnf1O6nHLHXy5DX4zFMDrk+B D4+cRjtLo6R/fZyceJpanPprvRwst7e+HF5DuJo9HkMVY1Bf627o90DahYuezeaGxBUVFRUVFRUV FRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRXzSq32/7zr0aZSsOu7AAAAAElFTkSuQmCC AAAA --_009_BLAPR09MB62278148AE8EC83B4E024E06C6C79BLAPR09MB6227namp_-- From nobody Thu Aug 26 14:40:11 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0387A3A09D5 for ; Thu, 26 Aug 2021 14:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, SPF_PASS=-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 95j-Kcuy4AJs for ; Thu, 26 Aug 2021 14:40:07 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2076.outbound.protection.outlook.com [40.107.93.76]) (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 3D5443A09D3 for ; Thu, 26 Aug 2021 14:40:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mrT8wQKTpuqSFN143QYnc7BYcutpQhJY2iCn8sEs1RJ+IAOmb1FcYF0LGyemKk/fAOtre6t/EwPZxmLELm7wgCTIqhcHGz4IVeMg8l/80aZYErTFmmlCeoX9w3a47CW30cT/EN224Jgi1+UmQsZd4MJJT/8KbjfjOtaqSxL2acfWVVRqjHOIL19xOHYFPejqUvcHtcqtl3ifXP34E8vIk37ie9gyfNnlXWGd3Mc8tiwtiWqq+6W0jEmw3y2+t/WYDTSL7KgLUQ5hqO3DpVeoWOjzT0m2tuQ4iwnXAMLHuyLHoSm8K6iiHSKu6DfUHFqmfN/zlpw9KTexMQtAUtQJeg== 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=+FI8Bhk1tYMEe7hWJpaXKrc0+aHBJbBI/Jje2jGKNX0=; b=YIP82VGNg7mQYi69EmGwVj2RVv9/XdcIZgrhIqOtwwgUkgH0QzLW5EjHnx9HsUx+nbgCCC4OvG2ygWyYN+7IUFhl/x3lIjx08WgGU3euTcHsEgoae+o7x8pua5+UgyYjVUcFS5QSJjCIyEvi8sqsloOivL6cdOFBPBOOBbrNIx6/fLgpQC5ZcDWicyvl4DATMiZDAlB8UizYxFuHSriHDnuAtnb0Hv6k4uY2MVaPwuMG+FK2tU+nyUIJ17DPKitySyKQkGV5wj44YNB4P3kGUrsQxgU6GWFBUH9ufWsCn9H6b7ZKu0qzCjzMLcQRIKxrZtnvcahMhBOBg9v/Gi8G9A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=zvrs.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=+FI8Bhk1tYMEe7hWJpaXKrc0+aHBJbBI/Jje2jGKNX0=; b=ZGsHLpshauKjOoEVELATmWmOaVaFhvKLF9Q+7Xy61WhrOamYANunDBVBb99XxxcpnGn8UIH9JKWn5wsP+Z7qMRG4x2wm84aH8j40PPTfjjLP6lckL6wXEP4DqKEHvCr2KVjQuk/3Ngh7mXjNuxglhls0NyH0op2Bvc9qNitf4PA= Received: from BN8PR04CA0006.namprd04.prod.outlook.com (2603:10b6:408:70::19) by BY5PR12MB3761.namprd12.prod.outlook.com (2603:10b6:a03:1af::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.20; Thu, 26 Aug 2021 21:40:04 +0000 Received: from BN1NAM02FT062.eop-nam02.prod.protection.outlook.com (2603:10b6:408:70:cafe::8c) by BN8PR04CA0006.outlook.office365.com (2603:10b6:408:70::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.19 via Frontend Transport; Thu, 26 Aug 2021 21:40:03 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; zvrs.com; dkim=none (message not signed) header.d=none;zvrs.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT062.mail.protection.outlook.com (10.13.2.168) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Thu, 26 Aug 2021 21:40:03 +0000 Received: from MacBook-Air.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 17QLe2qd000417 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Thu, 26 Aug 2021 17:40:02 -0400 To: Roger Slusser Cc: "rum@ietf.org" References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> From: Paul Kyzivat Message-ID: <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> Date: Thu, 26 Aug 2021 17:40:01 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 13ade0a5-fe62-4c14-120d-08d968da1069 X-MS-TrafficTypeDiagnostic: BY5PR12MB3761: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MbhhcGebMu7rH9nNcAzzs4oqr7O0vviFlpLqMXDlxhtYSpoy/LaUTKk/eBsIM7bW1SBDrQLvRrBpXXuCVz8Iqn0OED0kSyQZJVw8lRJW+U2XW3YbP8P0JsqMNTRje3Ij3SzOWKojtmGty/cQC4Y/e3VLxH2YbmNcF5Jl9iLXbRCMU+anqP6Ryj/ZBn6YNVh4BPLChwTeYRzNoXF4fJQsnoNhY+FPc6e7JGG/ss20PeszVGBACbeV5FVHPFC7Q4lh/UO99PeH+It8YFcN8ixRgApw9p7JBZpI3xOOZDRlafmOwzbEe69P/LH09cPHqrPO+LZNSWBwR6xKnILX9z8OfAuSOrTpK/iey+FLd9PRl+JOz7V3WWTpQ//VbhaAG731XJbGvb0GaCxiuBCrN/kMalgbsiQ06UlsVYIT9ytlrEdrp5AYA4Fb70nQ/Zur3O/+L31fYa7NRK4Ot/1xOa/XZOn4libSgMd9NTlA3ilCXTQmVtdowJbyQCmLMrfiMHqVWgtCY4vBFbHN+r52upbaOlfEk8Rz5ZDM9A6IShA3Nof3qWwVM0+OvATfc2I1x4b8qO3TP6DM94BokdRqb37J4cDF17me0ny8AhMF+1CzrkZCjzezl6Y0d8wFjD2i8OeET2zxnI1X5wY5d/kHoLk7Lx9Ij3d2JJYtJ3IvYWDnKwgK2q7PkkwVnrWwbxfHa/DZIHI/mXDv98C6mO9hBV49J2qc9ffkxRolIh7jmvq8hRU= 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; SFS:(136003)(39860400002)(346002)(376002)(396003)(36840700001)(46966006)(5660300002)(36906005)(8676002)(82310400003)(186003)(31696002)(7596003)(8936002)(36860700001)(70586007)(356005)(82740400003)(316002)(70206006)(47076005)(31686004)(2906002)(786003)(86362001)(7116003)(956004)(4744005)(2616005)(75432002)(53546011)(26005)(4326008)(336012)(478600001)(83380400001)(6916009)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Aug 2021 21:40:03.5717 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 13ade0a5-fe62-4c14-120d-08d968da1069 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-AuthSource: BN1NAM02FT062.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB3761 Archived-At: Subject: [Rum] IPv6 and encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 21:40:09 -0000 Roger, On 8/26/21 3:30 PM, Roger Slusser wrote: > Most providers already support encryption and IPV6 on a limited scope, > not necessarily the way it is defined in RUM spec. Mandating compliance > using MUST requires providers to discard sometimes huge amounts of > development to change over to what RUM is specifying. The push back is > not about doing these things it is about the loss of time, effort and > money to do them in the way RUM mandates with MUSTs. Do you think there is something else we could write in this spec that covers encryption and IPv6 in a way that is less burdensome for providers while remaining interoperable with all providers? If so, can you please spell it out? Thanks, Paul From nobody Thu Aug 26 14:49:04 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E82F3A003F for ; Thu, 26 Aug 2021 14:49:03 -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, 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=mitre.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 8fdGG4qdzSdq for ; Thu, 26 Aug 2021 14:48:56 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 4ECB13A0029 for ; Thu, 26 Aug 2021 14:48:56 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9D4C134E004; Thu, 26 Aug 2021 17:48:54 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [10.20.0.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id E6CFCB2E004; Thu, 26 Aug 2021 17:48:53 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 5EEF880C0C4; Thu, 26 Aug 2021 17:48:53 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4Gwc1K5q8Cz3D4WG; Thu, 26 Aug 2021 21:43:20 +0000 (UTC) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02lp2109.outbound.protection.outlook.com [104.47.64.109]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4Gwbtt13Ccz3D4R6; Thu, 26 Aug 2021 21:43:17 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BvGZcDJnkt0ZTLjGuCrIwXKjLSbCVtLK8NqWycqvgK+vGsNlDk82hKQAew6rP5CCBJ1cryZyp++6uFFuaPefAbBBCC2t4ahvDlO9+AcS2eIF2GW9Ekgp4KXLbcU8UBFLKfBiU0GZaTBzuW6hf9x8DrFCgO9YK37B4/UREAse+6DA8847pWXEOv2SbR0udy1CvqbQ8NR6TUlvy/+yC8CGlvSmqhK0pOuasTzUxNNp0KnMjOjQPpCsKZ3erbSR4QiKkpc0xzXUAl+BQ553efrOG7CjxOa//+jSIcS2zdZNp3WGah+U24lx/ClEbZESwgkq3X9/DqVDTxXEciiC4b2OUg== 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=eFQbg2//yI0oLtpOuIq7Nb+eG7gmZE1rEx7xWIiXTkw=; b=N2kzX+0dUS+TlpVbmHg9lyF8N3eYeE4nacl1Tq6YgUUas2qBjFR8/pszFJHYCl1H3oDMJxboB7YBz/7E5u4sWWrxkYxNymdaJeWs1vBTwcWA6JFoBk92HnMCftIrAa9vtst6LaGn3VRFF/b6z3TEw6TRssqcVcmRzNfOOy309jrqEX6qKdwoxYcLalQTqBQt7olJy4yM+9y4kU8OARWLf8CgK1u9T7cOBbkxzaLs9SLoBY+fk0u1WyiB2OoJOJND5+CSo6uFIX9wQ7z00leLe5BzxpPFjc0xg1PzBhACzs02nXV+VKtsmvor8ylJU9Hd+sZ++NDB8xiHZevvA9N+Og== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BLAPR09MB6227.namprd09.prod.outlook.com (2603:10b6:208:2a8::17) by BLAPR09MB7009.namprd09.prod.outlook.com (2603:10b6:208:2a2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 26 Aug 2021 21:43:16 +0000 Received: from BLAPR09MB6227.namprd09.prod.outlook.com ([fe80::3534:b411:1c35:7ef1]) by BLAPR09MB6227.namprd09.prod.outlook.com ([fe80::3534:b411:1c35:7ef1%7]) with mapi id 15.20.4436.027; Thu, 26 Aug 2021 21:43:16 +0000 From: Joe Gruessing To: Roger Slusser , "Olle E. Johansson" CC: "Christensen, Eugene" , "rum@ietf.org" , "Kyzivat, Paul" , Alexander Ospina , "Roach, Isaac" , Brian Rosen Thread-Topic: [Rum] Action Items from RUM session at IETF 111 Thread-Index: AQHXmsNfV4J67TTHNkK8aLXHH1loHQ== Date: Thu, 26 Aug 2021 21:43:15 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cec01970-f890-4647-fd60-08d968da830b x-ms-traffictypediagnostic: BLAPR09MB7009: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: bEOptf5p3D2juNxRTckkM7qGcUEUy6YWirKtKqdn9/1x99mg+nH+gynkz95+WDEid2RLuBm+RoJ9wGEFqVIuiPWBJOXhlJ7q6i5AL60d47kZc3XyexnqOIlI+u8jh23xHn47VeE0N7XNe8NWvR9eSXMfgq6fFdQy7sPGTFM6DIg4aGbss/t5G5EmjPUW8fllviVDJBK/ZuPzcyJ9uVUGVk7eTcQnZ4rZ6VHr/+YqGf0xyjcEZLGxb5Uo/G/tLMtMZ1eND+0s1sUxGuEiokUubF1vLj/oATsp1fHyrSe/Uk7bjWIxWXxE+gvJ+eNKJYKnkFUsutn9qY4rgPzXNjS1ffpE6/C4O5JM88Ong2MGK8AFkC1nKZp7kZCadp1JMAShFs4otFaMflRsC7VDYbfmUwVhdnXL5NDFvIVHpn++02GUERAttY7d5LtfwuinVqcqLb/PxCiEzYq8Am1SNY2131AnG8RMSeWRct8UjAJPRIZLH3Py5tZsfxigZY+a6mD4Tle4SouhYErRFFtdXRWYcH3JHa4s20VSb849spC5CratYYzgKum04FTyeTjZmxZVuBsiGXU25Z/OjLoIcFLM30CwAFYgCHWX+WXl1mJHUt79iaa9vAlQ1cd/CVA2cFk9by9Z9hHz06II3GrENrcbUNUJnL9a6XwoLDCaVMkamvqW6tPdhQlpnKfwVBhcRxmXy+AqFDGlzyT+B9LTgd/CM+HRdx4+FqKTB9dvyFO33X6pEA6hySY73rVFUA4/9e6vXZsMxOpdPb8s6Dwq7BRA/AuEkdapXr9+V0vlU2RMNSc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6227.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(136003)(346002)(366004)(39860400002)(396003)(6506007)(478600001)(53546011)(9686003)(55016002)(66574015)(966005)(30864003)(5660300002)(2906002)(122000001)(7696005)(38100700002)(83380400001)(71200400001)(4326008)(316002)(66946007)(76116006)(8936002)(99936003)(66446008)(64756008)(66556008)(66476007)(166002)(110136005)(66576008)(26005)(33656002)(86362001)(54906003)(186003)(8676002)(38070700005)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WXFmZk03UXUwcXliUlFzc1pPcENmc1FKa1Yvc1pxSmpyYTl3Q0g0OHErNFVa?= =?utf-8?B?TjNMQ09hb1VwNHh4YjZqckxlUEZaeEpCT0Zydk1IOXNTNGYydHRSdXBKV24v?= =?utf-8?B?d2xlQTllZytYSUhSc0RIYkFyMjl3dU9vQWxOcEVDcFFDWGI5ZWY2SXVvem40?= =?utf-8?B?K3ZIVXpWRTM2OGVoVnovVWs1WXh6TVJITWdNYXZvdDZqeWwxaTY0RHFsZG9F?= =?utf-8?B?MmRpcFpjUFdsWE9ZN0VUWnU3Zi83MktYUllvdEJldFhNZVcxNVNEaUttbHFn?= =?utf-8?B?NFFmL2FlRGlvclRIS0psUEdRbnJxWkhXdkl0bkdxbytmVWdmMFJwQU5xSlEv?= =?utf-8?B?ckxxV05GMjc5ZWxLYTdZdWRONlpxVzk0UzdJUzd4RUJXWUVCWU5KT2liYnhU?= =?utf-8?B?WjZzM3YvVjdQRnh4TTVzbUtBNEZuUEM3d2VlczVSckVCUFk0dHQ3NWZtWUQ0?= =?utf-8?B?TlpjMXlXakFGNW9mYWs5OThGWGVSRUJFTVoyMGtDTmtpckZzR0NLeFc2M3h1?= =?utf-8?B?eDlEMmx1ZnlqeEdvRkU4MDdHak5TYzMrU2V2OUtPelpudmtNczdEK0JrV1dK?= =?utf-8?B?MXdPZ0NOK1RuU2NrdVFZS3U0U3dPTHVBcFdIQWVmNzlnQW1vOWprWVJSeW5m?= =?utf-8?B?anJkbThhK0EyZ2g3TzQrR29HaFlERE5aSzBnU1F6MnIwbllDcDQvUHpyZXpE?= =?utf-8?B?d3o3WDZhSVk0blRlMmdtT1FJOEFLbytZR0pvTEE5VzJqUlZ6MW1CQWpZMGJX?= =?utf-8?B?R0FvSDJRZit3enhGeXNZUlZjYXVaTmkyWEk1cFh4NnRXRDM5cWpob3RBWnJq?= =?utf-8?B?MjRMa3AvcEYwbktTeG96NzNwazRFV3Q0VzdsSk55Q0JRZnlRZDlnTmhXUm80?= =?utf-8?B?VDBpQXcvZW05RCtNdnFYMitoZGJhZ0V2NkxHTTQvUW1ETFJDOVIyUHkyb0dR?= =?utf-8?B?VmI1Z0l1dmRETUhMbVJTaEJJalBHWks5SG5QdmFobE5lTXFueDdTQzVGalZl?= =?utf-8?B?Wk1GYWFTRDA4bkcrd0JMM0RDTnZkUHVDWjNidmREYkhnOE5XeDdZbGNKRDRa?= =?utf-8?B?TytmYnlDV0hmSkthUkVEbTk3d0Y5YWlYaHFxQ3hvZHFtWDNSNmhLTGtxWnly?= =?utf-8?B?SkZnTlJZNGlDVHZVaE9SLzJRTHdQRXpVU3lEaDVTOFN1MU42NFh6OEViNWNq?= =?utf-8?B?dGNZYTdxRWlkcmY3N3prVFJLTUxGbnpKUld5RTNMcnN0dDhGbW14MUV3eXNv?= =?utf-8?B?YXZ5bFZEUm91ZWFUeDdKc3FYbS8xWVhNSWl6RDQxOVpnd3RxZzMxQ1p0VDNZ?= =?utf-8?B?cFR4alVnMm1DSjZGbmVmblRXbzdVVEt2a2FsQ1NCZXJjNEplR0Z5S1dwbnNm?= =?utf-8?B?S3MvMUNkenIwS3hBZVNIWVZZVDYzeWNaZCtiRTZRTjdLS0xoNVpyMW0rVVV1?= =?utf-8?B?RFVtWWpWM0lZYlRmTFFFT2lFVURYenFLNFJPQTRBV3htV2l6d3Q0REp2WUps?= =?utf-8?B?eEN6SkduSkk3eU9KdHhKQTFXZEFrVE44MzRPTmxkOVdoS2lSOHE0Z1hyQUc5?= =?utf-8?B?SE9MZ1NEclFoVmFHMUpUbkdxdFpHMEtCbkp1amNzQmtvajlXN3o2L1FWNmsv?= =?utf-8?B?cWJSclIxOG80eXVMTGxZVjhOdU5LOWpKdUFGVFBHakpnUHdUeUxrVFYrZnV6?= =?utf-8?B?TEdxQ0JCcFREbXB4aGhqcHVyRHJLYzE4ZHk3S0ZaSTljTzdjMjEvOG55SWZU?= =?utf-8?Q?7Wmd3MoyY+wmELhImArb+7RvOiJTYJ5urIcpt53?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6227.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cec01970-f890-4647-fd60-08d968da830b X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 21:43:15.9699 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB7009 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=BTxNELhf; bh=eFQbg2//yI0oLtpOuIq7Nb+eG7gmZE1rEx7xWIiXTkw=; b=fdbPMst/AZTyfX1i1wP8lOw5in3iCKGYBLAny4Q36tYLDcovlWxcxnJ6Yrud4jtlhGoUEGXy+O4HuRy4ahHtR44cHAgFROkXHgm2aX1TxH2GO9GqS/LjY0PF09gga+u2L0SS5m6gtIDRcqG3uOq1GtF+rys3gJjxK7tsSXSAdfk= Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 21:49:03 -0000 --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: multipart/alternative; boundary="_000_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_" --_000_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJc27igJl0IGl0IGNvcnJlY3QgdGhhdCB0aGUgbW90aXZhdGlvbiBvZiB0aGlzIGRvY3VtZW50 ICggaS5lLiAgdG8gY3JlYXRlIHdpdGggYmVzdCBwcmFjdGljZSB0aGUg4oCccmlnaHTigJ0gdHlw ZSBvZiBjbGllbnQgZ3VpZGVsaW5lcyB0aHJvdWdoIGNvbnNlbnN1cyBhbmQgY3VycmVudCBhcnQp IGlzIGRpc3RpbmN0IGZyb20gd2hhdCB0aGUgRkNDIGRlY2lkZXMgdG8gZG8gd2l0aCB0aGUgd3Jp dHRlbiBwcm9kdWN0ICh3aG9sZSBvciBpbiBwYXJ0KSBhbmQgaG93IGl0IHJlbGF0ZXMgdG8gZXhp c3RpbmcgaW5kdXN0cnkgdGVjaD8gU2hvdWxkbuKAmXQgdGhlIHF1ZXN0aW9uIGF0IHRoaXMgcG9p bnQgYmUgZm9jdXNlZCBvbiB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgcHJvcGVybHkgY2FwdHVyZXMg dGhlIElFVEYgZ2xvYmFsICBpbnRlcnByZXRhdGlvbiBvZiBob3cgYSBSVUUgb3VnaHQgdG8gYmUg aW1wbGVtZW50ZWQgdG9kYXkgYW5kIG5vdCB3aGV0aGVyIHRoZSBnb3Zlcm5tZW50IGFnZW5jeSB3 aWxsIGVuZm9yY2UgbWFuZGF0ZXMgYW5kIGhvdz8gIFRob3NlIGFyZSByZWxhdGVkIGJ1dCBzZXBh cmF0ZSBpbml0aWF0aXZlcyBpbiBteSBvcGluaW9uLg0KDQotLS0tLS0tLS0tDQpKb2UgR3J1ZXNz aW5nDQpJbmZyYXN0cnVjdHVyZSBFbmdpbmVlcmluZywgUHJpbmNpcGFsDQpHcm91cCBMZWFkZXIs IEwxMTQNCg0KT2ZmaWNlOiAoNzAzKSA5ODMtMjA3NQ0KTW9iaWxlOiAoNzAzKSAzNDctMjQwMg0K DQogW0xpbmtlZEluXSA8aHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkvbWl0cmU+ICBb VHdpdHRlcl0gPGh0dHBzOi8vdHdpdHRlci5jb20vTUlUUkVjb3JwPiAgW1lvdVR1YmVdIDxodHRw czovL3d3dy55b3V0dWJlLmNvbS91c2VyL21pdHJlY29ycD4gIFtGYWNlYm9va10gPGh0dHBzOi8v d3d3LmZhY2Vib29rLmNvbS9NSVRSRWNvcnA+ICBbSW5zdGFncmFtXSA8aHR0cHM6Ly93d3cuaW5z dGFncmFtLmNvbS9taXRyZS5jb3JwLz9obD1lbj4NCg0KW01JVFJFIHwgU29sdmluZyBQcm9ibGVt cyBmb3IgYSBTYWZlciBXb3JsZF0NCg0KRnJvbTogUm9nZXIgU2x1c3NlciA8cnNsdXNzZXIxMDk2 QGdtYWlsLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMjYsIDIwMjEgMzozMCBQTQ0KVG86 IE9sbGUgRS4gSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD4NCkNjOiBDaHJpc3RlbnNlbiwgRXVn ZW5lIDxlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPjsgcnVtQGlldGYub3JnOyBLeXppdmF0LCBQ YXVsIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBBbGV4YW5kZXIgT3NwaW5hIDxhb3NwaW5hQGFz bHNlcnZpY2VzLmNvbT47IFJvYWNoLCBJc2FhYyA8aXJvYWNoQHNvcmVuc29uLmNvbT47IEJyaWFu IFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NClN1YmplY3Q6IFJlOiBbUnVtXSBBY3Rpb24gSXRl bXMgZnJvbSBSVU0gc2Vzc2lvbiBhdCBJRVRGIDExMQ0KDQoNCg0KT24gVGh1LCBBdWcgMjYsIDIw MjEgYXQgMTA6MzEgQU0gT2xsZSBFLiBKb2hhbnNzb24gPG9lakBlZHZpbmEubmV0PG1haWx0bzpv ZWpAZWR2aW5hLm5ldD4+IHdyb3RlOg0KDQoNCg0KT24gMjYgQXVnIDIwMjEsIGF0IDE2OjE3LCBS b2dlciBTbHVzc2VyIDxyc2x1c3NlcjEwOTZAZ21haWwuY29tPG1haWx0bzpyc2x1c3NlcjEwOTZA Z21haWwuY29tPj4gd3JvdGU6DQoNCkhlbGxvIGFsbCwNCkZpcnN0IG9mZiB0aGVzZSBhcmUgcGVy c29uYWwgY29tbWVudHMgYW5kIG5vdCBhcyBhIHNwb2tlc3BlcnNvbiBmb3IgdGhlIFZSUyBwcm92 aWRlciBJIHdvcmsgZm9yLg0KDQpJIGhhdmUgdG8gYWdyZWUgcmlnaHQgZG93biB0aGUgbGluZSB3 aXRoIEV1Z2VuZSBDaHJpc3RlbnNlbi4gSSBoYXZlIGJlZW4gYSBwYXJ0IG9mIHRoaXMgZnJvbSBk YXkgb25lIGFuZCBoYXZlIGJlZW4gZGlyZWN0bHkgaW52b2x2ZWQgaW4gdGhlIHNldHVwIGFuZCBl eGVjdXRpb24gb2YgdGhlIGJpLWFubnVhbCBJbnRlcm9wIGNvbmZlcmVuY2VzIGFuZCBkZXZlbG9w bWVudCBvZiB0aGUgUHJvdmlkZXIgSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlLg0KDQpJdCBpcyBv YnZpb3VzIHRvIG1lIHRoYXQgdGhpcyBSVU0gUkZDIHdpbGwgYmUgcGlja2VkIHVwIGJ5IHRoZSBG Q0MgYXMgdGhlIG5ldyBzcGVjIGZvciB0aGUgVkFUUlAuDQpSb2dlciwNCldpdGggYWxsIHJlc3Bl Y3QuIFRoZXJlIGlzIGEgd29ybGQgb3V0c2lkZSB0aGUgVVNBLiBSRkNzIGFyZSB3cml0dGVuIHdp dGggZ2xvYmFsIHNjb3BlLCBub3QgbGltaXRlZCB0byBhIHNwZWNpZmljIG1hcmtldCBvciBncm91 cCBvZiB2ZW5kb3JzLg0KT2xsZSwNCkkgdGhpbmsgeW91IG1heSBoYXZlIG1pc3NlZCBteSBwb2lu dCBhYm91dCB0aGlzIHRhcmdldGluZyBhIHNwZWNpZmljIGluZHVzdHJ5LCBuYW1lbHkgdGhlIFZS UyBpbmR1c3RyeSBpbiB0aGUgVVMuIEFsc28gd2hlbiB0aGUgRkNDIG1hbmRhdGVzIHN1cHBvcnQg b2YgYW4gUkZDIHRoZXkgZG8gbm90IHNwZWNpZnkgY3VzdG9tIHByb2ZpbGVzIGVzcGVjaWFsbHkg aW4gdGhpcyBjYXNlLiBUaGVyZSBtYXkgYmUgb3RoZXIgdXNlcyBmb3IgdGhpcyBvdXQgdGhlcmUg YnV0IG5vbmUgdGhhdCBhcmUgZGlyZWN0bHkgb3IgcG9zc2libHkgYWR2ZXJzZWx5IGFmZmVjdGVk Lg0KDQoNClNvIGxldCdzIG5vdCBraWQgb3Vyc2VsdmVzIG9yIG1pbmNlIHdvcmRzIGFib3V0IGlt cGxlbWVudGF0aW9ucywgaW5kdXN0cnkgcHJvZmlsZXMgYW5kIHZhcmlvdXMgc2VydmljZXMuIFRo aXMgZW5kcG9pbnQgc3BlYyB3aWxsIGJlIHRlcm1pbmF0ZWQgYnkgYSBWUlMgcHJvdmlkZXIgSW50 ZXJwcmV0ZXIgc3RhdGlvbiBvciBwcm9wcmlldGFyeSBlbmRwb2ludCBpbiA5OSUgb2YgdGhlIHVz ZSBjYXNlcy4gQnkgbWFuZGF0aW5nIHZpYSAiTVVTVHMiIGluIHRoaXMgUkZDLCBhbmQgdGhlcmUg YXJlIG1hbnksIGl0IHdpbGwgZm9yY2UgdGhlIFZSUyBwcm92aWRlcnMgdG8gYWJhbmRvbiBjdXJy ZW50IHByb2plY3QgcGxhbnMgYW5kIGJ1c2luZXNzIGdvYWxzIHRvIHR1cm4gYXR0ZW50aW9uIHRv IGltcGxlbWVudGluZyB0aGluZ3MgaW4gdGhpcyBSRkMgdGhhdCBoYXZlIHZlcnkgbGl0dGxlIHZh bHVlIHRvIHRoZSBEZWFmIGFuZCBISCBlbmQgdXNlcnMgd2Ugc3VwcG9ydC4gRXZlcnkgcHJvdmlk ZXIgYWxyZWFkeSBoYXMgYSBub3RpZmljYXRpb24gc2NoZW1lIGZvciBtZXNzYWdlIHdhaXRpbmcs IG1vc3Qgb2Ygd2hpY2ggaXMgbXVjaCBtb3JlIGVsYWJvcmF0ZSBhbmQgc29waGlzdGljYXRlZCB0 aGFuIE1XSSwgeWV0IHRoaXMgUkZDIHdpbGwgZm9yY2UgbGVzcyBkZXNpcmFibGUgc2VydmljZXMu Li4gd2h5PyBUaGlzIGlzIGp1c3QgYW4gZXhhbXBsZSB0aGF0IGhhcyBiZWVuIG9iamVjdGVkIHRv IHNpbmNlIGRheSBvbmUgYW5kIHlldCBpdCBzdGlsbCBoYXMgc3R1Y2sgbGlrZSBnbHVlLiBMZXQn cyBub3QgbG9zZSBmb2N1cyBvZiB0aGUgZHJpdmluZyBmb3JjZSBoZXJlLCB0aGUgYmV0dGVybWVu dCBvZiB0aGUgZW5kcG9pbnQgZXhwZXJpZW5jZSBmb3IgdGhlIERlYWYgYW5kIEhIIHVzZXIgYmFz ZS4NCkkgdGhpbmsgYmVpbmcgYWJsZSB0byBnZXQgcHJpdmFjeSBhbmQgYmUgYWJsZSB0byB1c2Ug YWxsIG5ldHdvcmtzLCBpbmNsdWRpbmcgdGhlIG9sZCBJUHY0IG5ldHdvcmtzLCBpcyBhIGdvb2Qg ZXhwZXJpZW5jZS4NCg0KTW9zdCBwcm92aWRlcnMgYWxyZWFkeSBzdXBwb3J0IGVuY3J5cHRpb24g YW5kIElQVjYgb24gYSBsaW1pdGVkIHNjb3BlLCBub3QgbmVjZXNzYXJpbHkgdGhlIHdheSBpdCBp cyBkZWZpbmVkIGluIFJVTSBzcGVjLiBNYW5kYXRpbmcgY29tcGxpYW5jZSB1c2luZyBNVVNUIHJl cXVpcmVzIHByb3ZpZGVycyB0byBkaXNjYXJkIHNvbWV0aW1lcyBodWdlIGFtb3VudHMgb2YgZGV2 ZWxvcG1lbnQgdG8gY2hhbmdlIG92ZXIgdG8gd2hhdCBSVU0gaXMgc3BlY2lmeWluZy4gVGhlIHB1 c2ggYmFjayBpcyBub3QgYWJvdXQgZG9pbmcgdGhlc2UgdGhpbmdzIGl0IGlzIGFib3V0IHRoZSBs b3NzIG9mIHRpbWUsIGVmZm9ydCBhbmQgbW9uZXkgdG8gZG8gdGhlbSBpbiB0aGUgd2F5IFJVTSBt YW5kYXRlcyB3aXRoIE1VU1RzLg0KDQoNCkkgdW5kZXJzdGFuZCB0aGlzIGlzIElFVEYuIEkgdW5k ZXJzdGFuZCB0aGlzIG11c3QgaGF2ZSB0aGUgbGF0ZXN0IGFuZCBncmVhdGVzdCB0ZWNoIHRoZSBp bmR1c3RyeSBoYXMgdG8gb2ZmZXIsIGJ1dCBJIHRoaW5rIHRoZSBkcml2aW5nIGNvbW1pdHRlZSBt ZW1iZXJzIG9mIHRoaXMgUkZDIGFsc28gbmVlZCB0byB1bmRlcnN0YW5kIHRoZSByZWFsaXRpZXMg b2YgaW1wbGVtZW50YXRpb24gYW5kIHRoZSBoYXJkc2hpcCB0aGlzIGNhbiBhbmQgd2lsbCBicmlu ZyB0byBwcm92aWRlcnMgd2l0aCB0aGUgIk1VU1RzIi4gVGhlIEZDQyBkZW5pZXMgZnVuZGluZyBm b3Igbm9uIGNvbXBsaWFuY2UsIHRoZSByZWFsaXR5IGlzIHRoZXNlICJNVVNUcyIgY291bGQgcHV0 IHByb3ZpZGVycyBvdXQgb2YgYnVzaW5lc3MuDQpBIE1VU1QgaW4gYW4gUkZDIHBvaW50cyB0byBh biBpbXBsZW1lbnRhdGlvbi4gSXQgZG9lc27igJl0IHByb3ZpZGUgYSBwcm9maWxlIGZvciBhIHNl cnZpY2UuIElmIGEgc2VydmljZSBwcm92aWRlciBvbmx5IHByb3ZpZGVzIElQdjQgdGhhdOKAmXMg b2sgKGRlcGVuZGluZyBvbiB0aGUgY3VzdG9tZXIgcmVxdWlyZW1lbnRzIG9mIGNvdXJzZSkuIEJ1 dCB0byBiZSBSRkMgY29tcGxpYW50IGFuZCBpbnRlcm9wZXJhYmxlLCBhbiBpbXBsZW1lbnRhdGlv biBoYXMgdG8gYmUgYWJsZSB0byBzdXBwb3J0IHdoYXTigJlzIHNwZWNpZmllZCBhcyBNVVNUcy4N Cg0KDQpJIGtub3cgdGhlcmUgYXJlIGhlYXZ5IGhpdHRlcnMgaW4gdGhlIElFVEYgY29tbXVuaXR5 IG9uIHRoaXMgcHJvamVjdC4gQnV0IHRoZXJlIGFyZSBhbHNvIGZvdW5kaW5nIG1lbWJlcnMgb2Yg dGhlIFZSUyBpbmR1c3RyeSB3aG8gaGF2ZSBvZmZlcmVkIGNvbW1lbnRzIHdpdGggcmVhc29uYWJs ZSBleHBsYW5hdGlvbnMgdGhhdCBoYXZlIGJlZW4gZGlzbWlzc2VkLiBBZnRlciAxOCB5ZWFyIEkg YmVsaWV2ZSB3ZSBrbm93IG91ciBjdXN0b21lciBiYXNlLiBUaGUgRGVhZiBlbXBsb3llZXMgaW4g b3VyIGNvbXBhbmllcyBpbiBtYXJrZXRpbmcgYW5kIHNhbGVzIGNvbGxlY3RpdmVseSBkcml2ZSBv dXIgcHJvZHVjdCBvZmZlcmluZ3MgdG8gYmVzdCBzdWl0IHRoZWlyIG5lZWRzIGJlY2F1c2Ugd2Ug ZWF0IG91ciBvd24gZG9nIGZvb2QuLiBJIHdvdWxkIHVyZ2UgdGhpcyBjb21taXR0ZWUgdG8gdGFr ZSBsb25nIGFuZCBoYXJkIGNvbnNpZGVyYXRpb24gb2YgdGhlIGV4cGVyaWVuY2UgdGhhdCBpbiBt eSBvcGluaW9uIGlzIGJlaW5nIGRpc21pc3NlZCBvZmZoYW5kZWRseSBmb3IgdGhlIHNha2Ugb2Yg bmV3IHRlY2ggdGhhdCBoYXMgdmVyeSBsaXR0bGUgdG8gZG8gd2l0aCBvdXIgY3VzdG9tZXJzIG5l ZWRzIG9yIHdhbnRzLg0KSVB2NiBpcyBub3QgbmV3IHRlY2ggYXQgdGhpcyBwb2ludC4gU1JUUC9E VExTIGlzIGltcGxlbWVudGVkIGluIG1pbGxpb25zIG9mIHdlYiBicm93c2VycyBvdXQgdGhlcmUs IHdpdGggbWFueSBpbXBsZW1lbnRhdGlvbnMgaW4gT3BlbiBTb3VyY2UuIEl04oCZcyBub3QgbmV3 IHRlY2gsIG5vdCBhdCBhbGwuIEluIGZhY3QgSSB3b3VsZCBiZSBzdXJwcmlzZWQgaWYgdGhlIFVT IEZDQyBkb2VzIG5vdCByZXF1aXJlIElQdjYuDQoNCkkgaGF2ZSBiZWVuIHdvcmtpbmcgd2l0aCBz b2NpYWwgY2FyZSBhbGFybXMgYXMgd2VsbCBhcyB0ZWxlcGhvbnkgZm9yIGRlYWYgYW5kIGhlYXJp bmcgaW1wYWlyZWQuIFRoZSB1c2VycyBkb27igJl0IGRlc2VydmUgb2xkIHRlY2hub2xvZ3kgb3Ig YSBsYWNrIG9mIHByaXZhY3kuIElmIHlvdSBhc2sgdGhlbSBpdCB3b3VsZCBiZSBhc3N1bWVkIHRo YXQgeW91IHdvcmsgb24gYWxsIGtpbmQgb2YgbmV0d29ya3MgLSBtb2JpbGUsIHdpZmksIGZpeGVk IGFuZCB0aGV5IHRydXN0IHlvdSB0byBnaXZlIHRoZW0gcHJpdmFjeS4gVGhleSB3b27igJl0IHNw ZWNpZnkgdGhhdCBpbiB0ZWNobmljaGFsIHRlcm1zLCBpdOKAmXMganVzdCBhc3N1bWVkLg0KDQov Tw0KDQpJIGFscmVhZHkgYWRkcmVzc2VkIHRoaXMgZWFybGllci4gSXQgaXMgbm90IHRoYXQgd2Ug ZG9uJ3QgcHJvdmlkZSBlbmNyeXB0aW9uLCB3ZSBoYXZlIHNldHRsZWQgb24gb3RoZXIgbWV0aG9k cy4gV2UgaGF2ZSBiZWVuIHN1cHBvcnRpbmcgSVB2NiBmb3Igc29tZSB0aW1lIG5vdyBvbiBhIGxp bWl0ZWQgYmFzaXMuDQoNClRoYW5rcyBmb3IgeW91ciBjb25zaWRlcmF0aW9uLA0KUm9nZXIgU2x1 c3Nlcg0KDQpPbiBUaHUsIEF1ZyAyNiwgMjAyMSBhdCA3OjE2IEFNIE9sbGUgRS4gSm9oYW5zc29u IDxvZWpAZWR2aW5hLm5ldDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+PiB3cm90ZToNCkZyaWVuZHMs DQpUaGlzIGlzIHRoZSBJRVRGIGFmdGVyIGFsbC4NCg0KV2UgY2Fu4oCZdCBsZXQgYW55IGRvY3Vt ZW50cyBiZSBwdWJsaXNoZWQgd2l0aG91dCBJUHY2LiBUaGUgcHJvYmxlbXMgeW91IG91dGxpbmUg aGVyZSBhcmUgc3VyZWx5IHNvbHZlZCBpbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgb2YgU0lQ LCBwcm9wYWJseSBzaW5jZSBtYW55IHllYXJzIGFnby4gSWYgbm90LCB3ZSBoYXZlIHdvcmsgdG8g ZG8uDQoNCkluIGFkZGl0aW9uLCBSVU0gc2VydmljZXMgd2l0aG91dCBTUlRQL0RUTFMgd2lsbCBi ZSB1c2VkIG92ZXIgYW55IG5ldHdvcmssIGluY2x1ZGluZyB0aGUgSW50ZXJuZXQsIGFuZCBpdCBp cyBhIHZlcnkgYmFkIHNvbHV0aW9uIHRoYXQgZmVlbHMgbGlrZSBzb21ldGhpbmcgd2Ugc29sZCBp biB0aGUgU0lQIHdvcmxkIGEgbG9uZyB0aW1lIGFnby4gVGhlIHdvcmxkIGhhcyBtb3ZlZCBzaW5j ZSB0aGVuLg0KDQpJIHN0cm9uZ2x5IHVyZ2UgdGhhdCB0aGUgUlVNIHNwZWNzIGhhcyB0byByZXF1 aXJlIG1hbmRhdG9yeSBJUHY2IHN1cHBvcnQgYXMgd2VsbCBhcyBTUlRQL0RUTFMgZW5jcnlwdGlv bi4NCg0KSSB3b3VsZCBwZXJzb25hbGx5IGdvIGFzIGZhciBhcyB0byBzYXkgdGhhdCBTUlRQL0RU TFMgaXMgYSBNVVNUIGFuZCBub3RoaW5nIGVsc2UgaXMgb2ssIHZlcnkgbXVjaCBsaWtlIFdlYlJU Qy4NCg0KSW4gcmVnYXJkcyB0byBwcm9wcmlldGFyeSB2cyBvcGVuIHN0YW5kYXJkcywgdGhpcyBp cyBhZ2FpbiB0aGUgSUVURi4gV2UgcHJvZHVjZSBvcGVuIHN0YW5kYXJkcyBhbmQgYSBSVU0gc3Bl Y2lmaWNhdGlvbiBoYXMgdG8gcG9pbnQgdG8gYSBTSVAgU1VCU0NSSUJFL05PVElGWSBwYWNrYWdl IGZvciBNV0kuDQoNClJlbWVtYmVyIHRoYXQgd2hhdCBJ4oCZbSB0YWxraW5nIGFib3V0IGlzIGRv Y3VtZW50cyBhcyBzcGVjaWZpZWQgYnkgdGhlIElFVEYuIEluZHVzdHJ5IHByb2ZpbGVzIGFuZCB2 YXJpb3VzIHNlcnZpY2VzIG1heSBnbyBvdGhlciB3YXlzLCBidXQgdGhlIElFVEYgc3RhbmRhcmRz IGhhcyB0byBiZSB1cCB0byBkYXRlIHdpdGggYmVzdCBjdXJyZW50IHByYWN0aXNlLg0KDQpDaGVl cnMsDQovTw0KDQo+IE9uIDI1IEF1ZyAyMDIxLCBhdCAyMDo1OCwgRXVnZW5lIENocmlzdGVuc2Vu IDxlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24u Y29tPj4gd3JvdGU6DQo+DQo+IEJyaWFuLCBQYXVsIHRoYW5rIHlvdSBmb3IgY29uc2lkZXJpbmcg dGhlIGNoYW5nZXMgdGhhdCBoYXZlIGJlZW4gYnJvdWdodCB1cCB0byB0aGlzIHBvaW50LiAgTGVh dmluZyB0aGluZ3MgYWxvbmUgd2l0aCB0aGUgWC1DYXJkLCB0aGUgaW5jbHVzaW9uIG9mIHRoZSBp bnN0YW5jZS1pZCBmb3IgbG9jYXRpb24sIGFkZGl0aW9ucyB0byBzdXBwb3J0IG5vdGlmaWNhdGlv biBzZXJ2aWNlcyBmb3IgbW9iaWxlLCBldGMuIGFyZSBhbGwgYXBwcmVjaWF0ZWQuDQo+DQo+IEl0 IGlzIG15IG9waW5pb24gdGhhdCB3ZSBzaG91bGQgbm90IGluY2x1ZGUgcmVxdWlyZW1lbnRzIGZv ciB0aGUgZm9sbG93aW5nIGluIHRoZSBuZXcgUlVNIGRvY3VtZW50LiAgSGVyZSBhcmUgdGhlIHJl YXNvbnMgdGhhdCBJIGJlbGlldmUgdGhpcyB3YXkuDQo+DQo+IFdlYlJUQw0KPg0KPiAqIFdoaWxl IHRoZXJlIGlzIGFuIFJGQyBmb3IgV2ViUlRDLCBpdCBkb2Vzbid0IGFwcGVhciB0aGF0IGFsbCBi cm93c2VycyBhcmUgZm9sbG93aW5nIGl0LiAgRm9yIGV4YW1wbGUsIFRNTUJSIGlzIHJlcXVpcmVk IGZvciBXZWJSVEMgYnV0IENocm9tZSBkb2VzIG5vdCBzaWduYWwgaXQuDQo+ICogV2ViUlRDIGlz IGFuIGF1ZGlvIGZpcnN0IGltcGxlbWVudGF0aW9uLiAgRm9yIFZSUywgdmlkZW8gaXMgdGhlIG1v c3QgaW1wb3J0YW50IG1lZGlhIHN0cmVhbS4gIEl0IG1lYW5zIGV2ZXJ5dGhpbmcgdG8gdGhlIGRl YWYgb3IgaGFyZCBvZiBoZWFyaW5nIHVzZXIuICBJZiB2aWRlbyBpcyBzdWZmZXJpbmcgZmlyc3Qg aW4gYSBsb3NzeSBuZXR3b3JrLCB0aGF0IGlzIGEgcHJvYmxlbSBmb3IgVlJTLg0KPiAqIFNvbWUg b2YgdGhlIFZSUyBwcm92aWRlcnMgZG8gbm90IGN1cnJlbnRseSBzdXBwb3J0IHRoZSBmb2xsb3dp bmcgaXRlbXMuICBUaGlzIGNvdWxkIHBvc2UgYSBzaWduaWZpY2FudCBpbXBhY3Qgb24gdGhlIFZS UyBwcm92aWRlcnMgdG8gZ2V0IHRoaXMgaW1wbGVtZW50ZWQuDQo+IG8gRW5jcnlwdGlvbiAoRFRM UykNCj4gbyBJQ0UNCj4gbyBSVFAvUlRDUCBNdXhpbmcNCj4NCj4gSVB2Ng0KPiAqIEZvciB0aG9z ZSBWUlMgcHJvdmlkZXJzIHdob3NlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBzdXBw b3J0IElQdjYsIHRoaXMgY2FuIGJlIGEgYmlnIGp1bXAgdG8gZ2V0IHRoZWlyIHNvbHV0aW9uIHRv IHN1cHBvcnQgYm90aCBJUHY0IGFzIHdlbGwgYXMgSVB2Ni4gIEdyYW50ZWQsIGl0IGRvZXMgbm90 IHJlcXVpcmUgYmVpbmcgZHVhbCBzdGFja2VkIGJ1dCByYXRoZXIgY291bGQgYmUgdHdvIHNlcGFy YXRlIHNlcnZlcnMsIGVhY2ggc3VwcG9ydGluZyB0aGVpciByZXNwZWN0aXZlIHZlcnNpb24gb2Yg SVAuICBUaGlzIGNvdWxkIGJlIGEgYmlnIHVuZGVydGFraW5nIGp1c3QgdG8gZ2V0IElQdjYgaW50 byB0aGUgbWl4Lg0KPiAqIEFub3RoZXIgc29sdXRpb24gY291bGQgYmUgYW4gSVB2NCB0byBJUHY2 IGdhdGV3YXkgYnV0IHRoYXQgZG9lc24ndCB3b3JrIGZsYXdsZXNzbHkuICBGb3IgZXhhbXBsZSwg dGhlIGdhdGV3YXkgY2FuIGZvcndhcmQgdGhlIElQdjYgU0lQIG1lc3NhZ2UgdG8gdGhlIHByb3Bl ciBhZGRyZXNzIG9uIHRoZSBJUHY0IG5ldHdvcmssIGhvd2V2ZXIsIGhvdyBkb2VzIGl0IHJlc29s dmUgdGhlIGVtYmVkZGVkIElQdjYgYWRkcmVzc2VzIHNpZ25hbGVkIGluIHRoZSBTRFA/ICBTbywg Zm9yIGV4YW1wbGUsIGNvbnNpZGVyIHR3byBSVUVzLCBvbmUgbGVnYWN5IFJVRSB0aGF0IGlzIHVz aW5nIElQdjQgYW5kIG9uZSB0aGF0IGlzIElQdjY7IHRoZSBzaWduYWxpbmcgaXMgcG9zc2libGUg Zm9yIGJvdGggb25jZSB0aGUgc2VydmVycyBmb3IgZWFjaCBzdXBwb3J0IHRoYXQgb3IgcHJvdmlk ZSBhIElQIGdhdGV3YXkgYmV0d2VlbiB0aGUgdHdvLiAgSG93IGlzIHRoZSBtZWRpYSBnb2luZyB0 byB3b3JrPyAgRWFjaCBvZiB0aGUgUlVFcyBpcyBnb2luZyB0byBwcm92aWRlIGFuIElQIGFkZHJl c3MgaW4gdGhlaXIgU0RQLCBvbmUgd2lsbCBiZSBJUHY0IGFuZCB0aGUgb3RoZXIgSVB2Ni4gIEhv dyBpcyB0aGlzIGdvaW5nIHRvIHdvcmsgd2l0aG91dCBoYXZpbmcgdG8gYW5jaG9yIGFsbCB0aGUg bWVkaWEgc29tZXdoZXJlPw0KPiAqIEFyZSB0aGVyZSBpc3N1ZXMgdGhhdCB3ZSBuZWVkIHRvIHJl c29sdmUgd2l0aCBOQVQ2NCBhbmQvb3IgRE5TNjQ/DQo+ICogQXMgSSB1bmRlcnN0YW5kIGl0LCBz b21lIG1vYmlsZSBkZXZpY2VzIGFyZSBhbHJlYWR5IElQdjYgYnV0IGRvIG5vdCBmb2xsb3cgdGhl IFJGQyBmb3IgZW1iZWRkaW5nIGFuIElQdjQgYWRkcmVzcyBpbnRvIGFuIElQdjYgYWRkcmVzcy4g IFRoaXMgaXMgZ29pbmcgdG8gcmVxdWlyZSBzcGVjaWFsIGhhbmRsaW5nIHRvIGdldCB0aGlzIHRv IHdvcmsgd2l0aCBzdWNoIGRldmljZXMgb24gdmVuZG9ycyB0aGF0IGRvIG5vdCBmb2xsb3cgdGhl IFJGQyBpbiB0aGlzIHJlZ2FyZC4NCj4NCj4gTWVzc2FnZSBXYWl0aW5nIEluZGljYXRvcg0KPiAq IFNvbWUsIGlmIG5vdCBhbGwsIG9mIHRoZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBvZiBSVUUg YnkgVlJTIHByb3ZpZGVycywgYWxyZWFkeSBpbmNsdWRlIG1lYW5zIHRvIHJlY29yZCB2aWRlbyBt ZXNzYWdlcyBhbmQgYXJlIG5vdCBhbGwgY3JlYXRlZCB0aGUgc2FtZSB3YXkuICBQcm9wcmlldGFy eSBtZXRob2RzIGhhdmUgYmVlbiB1c2VkLiAgVGhlIGRvY3VtZW50IHN0YXRlcyB0aGF0IE1XSSBp cyBvcHRpb25hbCBidXQgaWYgdGhlIGFiaWxpdHkgdG8gbGVhdmUgYSBtZXNzYWdlIGlzIHByb3Zp ZGVkIHRoZW4gTVdJIGlzIHRvIGJlIGltcGxlbWVudGVkLiAgU2luY2UgdGhlcmUgYXJlIHByb3By aWV0YXJ5IHNvbHV0aW9ucywgaXQgc2VlbXMgYXBwcm9wcmlhdGUgdG8gbWUgdGhhdCB0aGlzIHNo b3VsZCBiZSBjaGFuZ2VkIHNvIHRoYXQgcHJvcHJpZXRhcnkgc29sdXRpb25zIGFuZCBpbmRpY2F0 aW9ucyBjYW4gY29udGludWUgdG8gYmUgdXRpbGl6ZWQuDQo+DQo+DQo+IEkgZG9uJ3QgYmVsaWV2 ZSBJIGhhdmUgZW51bWVyYXRlZCBhbGwgdGhlIHJlYXNvbnMgZm9yIG5vdCBpbmNsdWRpbmcgcmVx dWlyZW1lbnRzIGZvciB0aGUgYWJvdmUgYnV0IEkgYmVsaWV2ZSB0aGUgZXhhbXBsZXMgZ2l2ZW4g YXJlIHN1ZmZpY2llbnQgdG8gY29uc2lkZXIuDQo+DQo+IFJlZ2FyZHMsDQo+IEV1Z2VuZSBDaHJp c3RlbnNlbg0KPg0KPiBDT05GSURFTlRJQUxJVFkgTk9USUNFLiBUaGlzIGUtbWFpbCB0cmFuc21p c3Npb24sIGFuZCBhbnkgZG9jdW1lbnRzLCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2Fn ZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRh cnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9y IGEgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNv cHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklU RUQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1lIGJ5IHJlcGx5IGUtbWFpbCBhdCBlY2hyaXN0ZW5zZW5A c29yZW5zb24uY29tPG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPiBvciBieSB0ZWxl cGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFu c21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZp bmcgdGhlbSB0byBkaXNrLg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2YXQNCj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxOSwg MjAyMSAxMDowNCBBTQ0KPiBUbzogcnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0Zi5vcmc+DQo+ IENjOiBBbGV4YW5kZXIgT3NwaW5hIDxhb3NwaW5hQGFzbHNlcnZpY2VzLmNvbTxtYWlsdG86YW9z cGluYUBhc2xzZXJ2aWNlcy5jb20+PjsgSXNhYWMgUm9hY2ggPElSb2FjaEBzb3JlbnNvbi5jb208 bWFpbHRvOklSb2FjaEBzb3JlbnNvbi5jb20+PjsgQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4u bmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQo+IFN1YmplY3Q6IFtSdW1dIEFjdGlvbiBJ dGVtcyBmcm9tIFJVTSBzZXNzaW9uIGF0IElFVEYgMTExDQo+DQo+IFtFWFRFUk5BTF0NCj4NCj4g VGhlIG1pbnV0ZXMgZnJvbSB0aGUgUlVNIHNlc3Npb24gaW5jbHVkZSBhIG51bWJlciBvZiBhY3Rp b24gaXRlbXMuDQo+IFNwZWNpZmljYWxseSwgdGhlIGZvbGxvd2luZyBwZW9wbGUgbWFkZSBjb21t aXRtZW50czoNCj4NCj4gQnJpYW4gUm9zZW4NCj4gSXNhYWMgUm9hY2gNCj4gQWxleCBPc3BpbmEN Cj4NCj4gQnJpYW4gaXMgd29ya2luZyBvbiBhbiB1cGRhdGVkIHZlcnNpb24sIGJ1dCBpdCB3b24n dCBpbmNsdWRlIHRoZQ0KPiBjb25jZXJucyBvZiB0aGUgb3RoZXJzIGFib3ZlIGlmIHdlIGRvbid0 IGhlYXIgZnJvbSB5b3UuIFJhdGhlciB0aGFuIHRyeQ0KPiB0byBzdW1tYXJpemUgdGhvc2UgSSBy ZWZlciB5b3UgYmFjayB0byB0aGUgbWludXRlcy4gWW91IGNhbiBmaW5kIHRoZW0gYXQ6DQo+IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTExLXJ1bS8NCj4NCj4gSSBw bGFuIHRvIGlzc3VlIFdHTEMgb24gdGhlIGRvY3VtZW50IHNvb24uIEkgd2lsbCB3YWl0IG9uZSB3 ZWVrICh1bnRpbA0KPiBBdWcgMjYpLiBJZiB0aGVyZSBoYXNuJ3QgYmVlbiBhbnkgZm9sbG93dXAg YnkgdGhlbiBJIHdpbGwgYXNrIEJyaWFuIHRvDQo+IGlzc3VlIGEgdmVyc2lvbiB0aGF0IHdlIGNh biBhZHZhbmNlIHRvIFdHTEMuDQo+DQo+ICAgICAgIFRoYW5rcywNCj4gICAgICAgUGF1bA0KPg0K PiAtLQ0KPiBSdW0gbWFpbGluZyBsaXN0DQo+IFJ1bUBpZXRmLm9yZzxtYWlsdG86UnVtQGlldGYu b3JnPg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0KPg0KPiAt LQ0KPiBSdW0gbWFpbGluZyBsaXN0DQo+IFJ1bUBpZXRmLm9yZzxtYWlsdG86UnVtQGlldGYub3Jn Pg0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0KDQotLQ0KUnVt IG1haWxpbmcgbGlzdA0KUnVtQGlldGYub3JnPG1haWx0bzpSdW1AaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0KLS0NClJ1bSBtYWlsaW5nIGxpc3QN ClJ1bUBpZXRmLm9yZzxtYWlsdG86UnVtQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydW0NCg0K --_000_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJY29sb3I6YmxhY2s7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5k aWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Jc27igJl0IGl0IGNvcnJlY3QgdGhhdCB0aGUg bW90aXZhdGlvbiBvZiB0aGlzIGRvY3VtZW50ICggaS5lLiAmbmJzcDt0byBjcmVhdGUgd2l0aCBi ZXN0IHByYWN0aWNlIHRoZSDigJxyaWdodOKAnSB0eXBlIG9mIGNsaWVudCBndWlkZWxpbmVzIHRo cm91Z2ggY29uc2Vuc3VzIGFuZCBjdXJyZW50IGFydCkgaXMgZGlzdGluY3QgZnJvbSB3aGF0IHRo ZSBGQ0MgZGVjaWRlcyB0byBkbyB3aXRoDQogdGhlIHdyaXR0ZW4gcHJvZHVjdCAod2hvbGUgb3Ig aW4gcGFydCkgYW5kIGhvdyBpdCByZWxhdGVzIHRvIGV4aXN0aW5nIGluZHVzdHJ5IHRlY2g/IFNo b3VsZG7igJl0IHRoZSBxdWVzdGlvbiBhdCB0aGlzIHBvaW50IGJlIGZvY3VzZWQgb24gd2hldGhl ciB0aGlzIGRvY3VtZW50IHByb3Blcmx5IGNhcHR1cmVzIHRoZSBJRVRGIGdsb2JhbCAmbmJzcDtp bnRlcnByZXRhdGlvbiBvZiBob3cgYSBSVUUgb3VnaHQgdG8gYmUgaW1wbGVtZW50ZWQgdG9kYXkg YW5kIG5vdA0KIHdoZXRoZXIgdGhlIGdvdmVybm1lbnQgYWdlbmN5IHdpbGwgZW5mb3JjZSBtYW5k YXRlcyBhbmQgaG93PyAmbmJzcDtUaG9zZSBhcmUgcmVsYXRlZCBidXQgc2VwYXJhdGUgaW5pdGlh dGl2ZXMgaW4gbXkgb3Bpbmlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToyLjBwdDtsaW5lLWhlaWdodDoxMi4wcHQ7bXNv LWxpbmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBzdHlsZT0iY29sb3I6IzJGNTQ5 NiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjIuMHB0O2xpbmUtaGVpZ2h0OjEyLjBwdDttc28tbGluZS1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NDk2Ij4tLS0t LS0tLS0tPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjIuMHB0O2xpbmUtaGVpZ2h0OjEyLjBwdDttc28tbGluZS1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxiPjxzcGFuIHN0eWxlPSJjb2xvcjojMkY1NDk2Ij5Kb2UgR3J1 ZXNzaW5nPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjIuMHB0O2xpbmUtaGVpZ2h0OjEyLjBwdDttc28tbGluZS1oZWln aHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW5mcmFzdHJ1Y3R1 cmUgRW5naW5lZXJpbmcsIFByaW5jaXBhbDxiPjxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTMuMHB0O21zby1saW5lLWhl aWdodC1ydWxlOmV4YWN0bHkiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+R3JvdXAgTGVhZGVy LCBMMTE0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEzLjBwdDttc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ij48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7bXNvLWxpbmUtaGVpZ2h0LXJ1 bGU6ZXhhY3RseSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PZmZpY2U6ICg3MDMpIDk4My0y MDc1PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Imxp bmUtaGVpZ2h0OjEzLjBwdDttc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ij48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPk1vYmlsZTogKDcwMykgMzQ3LTI0MDI8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Nv bG9yOiM3RjdGN0YiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3RjdGN0YiPiZuYnNw Ozwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9taXRyZSIg dGl0bGU9Imh0dHBzOi8vd3d3LmxpbmtlZGluLmNvbS9jb21wYW55L21pdHJlLyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzdGN0Y3Rjt0ZXh0LWRlY29yYXRpb246bm9uZSI+ PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyMSIgaGVpZ2h0PSIyMSIgc3R5bGU9IndpZHRoOi4yMjA4 aW47aGVpZ2h0Oi4yMjA4aW4iIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDAx LnBuZ0AwMUQ3OUFBMS5EODRBQzU3MCIgYWx0PSJMaW5rZWRJbiI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdGIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9NSVRSRWNvcnAiIHRpdGxlPSJodHRwczovL3R3aXR0ZXIu Y29tL01JVFJFY29ycCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzdGN0Y3 Rjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIyMyIgaGVpZ2h0 PSIxOSIgc3R5bGU9IndpZHRoOi4yNDE2aW47aGVpZ2h0Oi4yaW4iIGlkPSJQaWN0dXJlX3gwMDIw XzIiIHNyYz0iY2lkOmltYWdlMDAyLnBuZ0AwMUQ3OUFBMS5EODRBQzU3MCIgYWx0PSJUd2l0dGVy Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3RjdGN0Yi PiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL21pdHJl Y29ycCIgdGl0bGU9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIvbWl0cmVjb3JwIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdGO3RleHQtZGVjb3JhdGlvbjpu b25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMyIiBoZWlnaHQ9IjIxIiBzdHlsZT0id2lkdGg6 LjMzMzNpbjtoZWlnaHQ6LjIyMDhpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfMyIgc3JjPSJjaWQ6aW1h Z2UwMDMucG5nQDAxRDc5QUExLkQ4NEFDNTcwIiBhbHQ9IllvdVR1YmUiPjwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzdGN0Y3RiI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Imh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9NSVRSRWNvcnAiIHRpdGxlPSJodHRwczov L3d3dy5mYWNlYm9vay5jb20vTUlUUkVjb3JwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjojN0Y3RjdGO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lk dGg9IjIzIiBoZWlnaHQ9IjIzIiBzdHlsZT0id2lkdGg6LjI0MTZpbjtoZWlnaHQ6LjI0MTZpbiIg aWQ9IlBpY3R1cmVfeDAwMjBfNCIgc3JjPSJjaWQ6aW1hZ2UwMDQucG5nQDAxRDc5QUExLkQ4NEFD NTcwIiBhbHQ9IkZhY2Vib29rIj48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOiM3RjdGN0YiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pbnN0 YWdyYW0uY29tL21pdHJlLmNvcnAvP2hsPWVuIiB0aXRsZT0iaHR0cHM6Ly93d3cuaW5zdGFncmFt LmNvbS9taXRyZS5jb3JwLz9obD1lbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6IzdGN0Y3Rjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIy MyIgaGVpZ2h0PSIyMyIgc3R5bGU9IndpZHRoOi4yNDE2aW47aGVpZ2h0Oi4yNDE2aW4iIGlkPSJQ aWN0dXJlX3gwMDIwXzUiIHNyYz0iY2lkOmltYWdlMDA1LnBuZ0AwMUQ3OUFBMS5EODRBQzU3MCIg YWx0PSJJbnN0YWdyYW0iPjwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxNjAiIGhlaWdodD0iMjAiIHN0eWxlPSJ3 aWR0aDoxLjY2NjZpbjtoZWlnaHQ6LjIwODNpbiIgaWQ9IlBpY3R1cmVfeDAwMjBfNiIgc3JjPSJj aWQ6aW1hZ2UwMDYucG5nQDAxRDc5QUExLkQ4NEFDNTcwIiBhbHQ9Ik1JVFJFIHwgU29sdmluZyBQ cm9ibGVtcyBmb3IgYSBTYWZlciBXb3JsZCI+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBSb2dlciBTbHVzc2VyICZsdDtyc2x1c3NlcjEwOTZAZ21haWwuY29tJmd0OyA8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyNiwgMjAyMSAzOjMwIFBNPGJyPg0K PGI+VG86PC9iPiBPbGxlIEUuIEpvaGFuc3NvbiAmbHQ7b2VqQGVkdmluYS5uZXQmZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBDaHJpc3RlbnNlbiwgRXVnZW5lICZsdDtlY2hyaXN0ZW5zZW5Ac29yZW5zb24u Y29tJmd0OzsgcnVtQGlldGYub3JnOyBLeXppdmF0LCBQYXVsICZsdDtwa3l6aXZhdEBhbHVtLm1p dC5lZHUmZ3Q7OyBBbGV4YW5kZXIgT3NwaW5hICZsdDthb3NwaW5hQGFzbHNlcnZpY2VzLmNvbSZn dDs7IFJvYWNoLCBJc2FhYyAmbHQ7aXJvYWNoQHNvcmVuc29uLmNvbSZndDs7IEJyaWFuIFJvc2Vu ICZsdDtickBicmlhbnJvc2VuLm5ldCZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdW1d IEFjdGlvbiBJdGVtcyBmcm9tIFJVTSBzZXNzaW9uIGF0IElFVEYgMTExPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgQXVnIDI2LCAyMDIxIGF0IDEwOjMx IEFNIE9sbGUgRS4gSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86b2VqQGVkdmluYS5uZXQi IHRhcmdldD0iX2JsYW5rIj5vZWpAZWR2aW5hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjYg QXVnIDIwMjEsIGF0IDE2OjE3LCBSb2dlciBTbHVzc2VyICZsdDs8YSBocmVmPSJtYWlsdG86cnNs dXNzZXIxMDk2QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJzbHVzc2VyMTA5NkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhlbGxvIGFsbCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5GaXJzdCBvZmYgdGhlc2UgYXJlIHBlcnNvbmFsIGNvbW1lbnRzIGFuZCBub3QgYXMgYSBz cG9rZXNwZXJzb24gZm9yIHRoZSBWUlMgcHJvdmlkZXIgSSB3b3JrIGZvci4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZlIHRv IGFncmVlIHJpZ2h0IGRvd24gdGhlIGxpbmUgd2l0aCBFdWdlbmUgQ2hyaXN0ZW5zZW4uIEkgaGF2 ZSBiZWVuIGEgcGFydCBvZiB0aGlzIGZyb20gZGF5IG9uZSBhbmQgaGF2ZSBiZWVuIGRpcmVjdGx5 IGludm9sdmVkIGluIHRoZSBzZXR1cCBhbmQgZXhlY3V0aW9uIG9mIHRoZSBiaS1hbm51YWwgSW50 ZXJvcCBjb25mZXJlbmNlcyBhbmQgZGV2ZWxvcG1lbnQgb2YgdGhlIFByb3ZpZGVyIEludGVyb3Bl cmFiaWxpdHkNCiBQcm9maWxlLiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCBpcyBvYnZpb3VzIHRvIG1lIHRoYXQgdGhp cyBSVU0gUkZDIHdpbGwgYmUgcGlja2VkIHVwIGJ5IHRoZSBGQ0MgYXMgdGhlIG5ldyBzcGVjIGZv ciB0aGUgVkFUUlAuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvZ2VyLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCBhbGwgcmVzcGVjdC4gVGhl cmUgaXMgYSB3b3JsZCBvdXRzaWRlIHRoZSBVU0EuIFJGQ3MgYXJlIHdyaXR0ZW4gd2l0aCBnbG9i YWwgc2NvcGUsIG5vdCBsaW1pdGVkIHRvIGEgc3BlY2lmaWMgbWFya2V0IG9yIGdyb3VwIG9mIHZl bmRvcnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9sbGUsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rJm5ic3A7eW91IG1heSBoYXZl IG1pc3NlZCBteSBwb2ludCBhYm91dCB0aGlzIHRhcmdldGluZyZuYnNwO2Egc3BlY2lmaWMgaW5k dXN0cnksIG5hbWVseSB0aGUgVlJTIGluZHVzdHJ5IGluIHRoZSBVUy4gQWxzbyB3aGVuIHRoZSBG Q0MgbWFuZGF0ZXMgc3VwcG9ydCBvZiBhbiBSRkMgdGhleSBkbyBub3Qgc3BlY2lmeSBjdXN0b20g cHJvZmlsZXMgZXNwZWNpYWxseSBpbiB0aGlzIGNhc2UuIFRoZXJlIG1heSBiZSBvdGhlcg0KIHVz ZXMgZm9yIHRoaXMgb3V0IHRoZXJlIGJ1dCBub25lIHRoYXQgYXJlIGRpcmVjdGx5IG9yIHBvc3Np Ymx5IGFkdmVyc2VseSBhZmZlY3RlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNv IGxldCdzIG5vdCBraWQgb3Vyc2VsdmVzIG9yIG1pbmNlIHdvcmRzIGFib3V0IGltcGxlbWVudGF0 aW9ucywgaW5kdXN0cnkgcHJvZmlsZXMgYW5kIHZhcmlvdXMgc2VydmljZXMuIFRoaXMgZW5kcG9p bnQgc3BlYyB3aWxsIGJlIHRlcm1pbmF0ZWQgYnkgYSBWUlMgcHJvdmlkZXIgSW50ZXJwcmV0ZXIg c3RhdGlvbiBvciBwcm9wcmlldGFyeSBlbmRwb2ludCBpbiA5OSUgb2YgdGhlIHVzZSBjYXNlcy4g QnkgbWFuZGF0aW5nDQogdmlhICZxdW90O01VU1RzJnF1b3Q7IGluIHRoaXMgUkZDLCBhbmQgdGhl cmUgYXJlIG1hbnksIGl0IHdpbGwgZm9yY2UgdGhlIFZSUyBwcm92aWRlcnMgdG8gYWJhbmRvbiBj dXJyZW50IHByb2plY3QgcGxhbnMgYW5kIGJ1c2luZXNzJm5ic3A7Z29hbHMgdG8gdHVybiBhdHRl bnRpb24gdG8gaW1wbGVtZW50aW5nIHRoaW5ncyBpbiB0aGlzIFJGQyB0aGF0IGhhdmUgdmVyeSBs aXR0bGUgdmFsdWUgdG8gdGhlIERlYWYgYW5kIEhIIGVuZCB1c2VycyB3ZSBzdXBwb3J0LiBFdmVy eQ0KIHByb3ZpZGVyIGFscmVhZHkgaGFzIGEgbm90aWZpY2F0aW9uIHNjaGVtZSBmb3IgbWVzc2Fn ZSB3YWl0aW5nLCBtb3N0IG9mIHdoaWNoIGlzIG11Y2ggbW9yZSBlbGFib3JhdGUgYW5kIHNvcGhp c3RpY2F0ZWQgdGhhbiBNV0ksIHlldCB0aGlzIFJGQyB3aWxsIGZvcmNlJm5ic3A7bGVzcyBkZXNp cmFibGUgc2VydmljZXMuLi4gd2h5PyBUaGlzIGlzIGp1c3QgYW4gZXhhbXBsZSB0aGF0IGhhcyBi ZWVuIG9iamVjdGVkIHRvIHNpbmNlIGRheSBvbmUgYW5kIHlldA0KIGl0IHN0aWxsIGhhcyBzdHVj ayBsaWtlIGdsdWUuIExldCdzIG5vdCBsb3NlIGZvY3VzIG9mIHRoZSBkcml2aW5nIGZvcmNlIGhl cmUsIHRoZSBiZXR0ZXJtZW50IG9mIHRoZSBlbmRwb2ludCBleHBlcmllbmNlJm5ic3A7Zm9yIHRo ZSBEZWFmIGFuZCBISCB1c2VyIGJhc2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5r IGJlaW5nIGFibGUgdG8gZ2V0IHByaXZhY3kgYW5kIGJlIGFibGUgdG8gdXNlIGFsbCBuZXR3b3Jr cywgaW5jbHVkaW5nIHRoZSBvbGQgSVB2NCBuZXR3b3JrcywgaXMgYSBnb29kIGV4cGVyaWVuY2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TW9zdCBwcm92aWRlcnMgYWxyZWFkeSBzdXBwb3J0IGVuY3J5 cHRpb24gYW5kIElQVjYgb24gYSBsaW1pdGVkIHNjb3BlLCBub3QgbmVjZXNzYXJpbHkgdGhlIHdh eSBpdCBpcyBkZWZpbmVkIGluIFJVTSBzcGVjLiBNYW5kYXRpbmcgY29tcGxpYW5jZSB1c2luZyBN VVNUIHJlcXVpcmVzIHByb3ZpZGVycyB0byBkaXNjYXJkIHNvbWV0aW1lcyBodWdlIGFtb3VudHMg b2YgZGV2ZWxvcG1lbnQgdG8gY2hhbmdlIG92ZXINCiB0byB3aGF0IFJVTSBpcyBzcGVjaWZ5aW5n LiBUaGUgcHVzaCBiYWNrIGlzIG5vdCBhYm91dCBkb2luZyB0aGVzZSB0aGluZ3MgaXQgaXMgYWJv dXQgdGhlIGxvc3Mgb2YgdGltZSwgZWZmb3J0IGFuZCBtb25leSB0byBkbyB0aGVtIGluIHRoZSB3 YXkgUlVNIG1hbmRhdGVzIHdpdGggTVVTVHMuJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0 O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQgdGhpcyBpcyBJRVRGLiBJIHVu ZGVyc3RhbmQgdGhpcyBtdXN0IGhhdmUgdGhlIGxhdGVzdCBhbmQgZ3JlYXRlc3QgdGVjaCB0aGUg aW5kdXN0cnkgaGFzIHRvIG9mZmVyLCBidXQgSSB0aGluayB0aGUgZHJpdmluZyBjb21taXR0ZWUg bWVtYmVycyBvZiB0aGlzIFJGQyBhbHNvIG5lZWQgdG8gdW5kZXJzdGFuZCB0aGUgcmVhbGl0aWVz IG9mIGltcGxlbWVudGF0aW9uIGFuZCB0aGUgaGFyZHNoaXANCiB0aGlzIGNhbiBhbmQgd2lsbCBi cmluZyB0byBwcm92aWRlcnMgd2l0aCB0aGUgJnF1b3Q7TVVTVHMmcXVvdDsuIFRoZSBGQ0MgZGVu aWVzIGZ1bmRpbmcgZm9yIG5vbiBjb21wbGlhbmNlLCB0aGUgcmVhbGl0eSBpcyB0aGVzZSAmcXVv dDtNVVNUcyZxdW90OyBjb3VsZCBwdXQgcHJvdmlkZXJzIG91dCBvZiBidXNpbmVzcy4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgTVVTVCBpbiBhbiBSRkMgcG9pbnRzIHRvIGFuIGlt cGxlbWVudGF0aW9uLiBJdCBkb2VzbuKAmXQgcHJvdmlkZSBhIHByb2ZpbGUgZm9yIGEgc2Vydmlj ZS4gSWYgYSBzZXJ2aWNlIHByb3ZpZGVyIG9ubHkgcHJvdmlkZXMgSVB2NCB0aGF04oCZcyBvayAo ZGVwZW5kaW5nIG9uIHRoZSBjdXN0b21lciByZXF1aXJlbWVudHMgb2YgY291cnNlKS4gQnV0IHRv IGJlIFJGQyBjb21wbGlhbnQgYW5kIGludGVyb3BlcmFibGUsDQogYW4gaW1wbGVtZW50YXRpb24g aGFzIHRvIGJlIGFibGUgdG8gc3VwcG9ydCB3aGF04oCZcyBzcGVjaWZpZWQgYXMgTVVTVHMuPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSBrbm93IHRoZXJlIGFyZSBoZWF2eSBoaXR0ZXJzIGluIHRoZSBJRVRG IGNvbW11bml0eSBvbiB0aGlzIHByb2plY3QuIEJ1dCB0aGVyZSBhcmUgYWxzbyBmb3VuZGluZyBt ZW1iZXJzIG9mIHRoZSBWUlMgaW5kdXN0cnkgd2hvIGhhdmUgb2ZmZXJlZCBjb21tZW50cyB3aXRo IHJlYXNvbmFibGUgZXhwbGFuYXRpb25zJm5ic3A7dGhhdCBoYXZlIGJlZW4gZGlzbWlzc2VkLiBB ZnRlciAxOCB5ZWFyIEkgYmVsaWV2ZSB3ZSBrbm93DQogb3VyIGN1c3RvbWVyIGJhc2UuIFRoZSBE ZWFmIGVtcGxveWVlcyBpbiBvdXIgY29tcGFuaWVzIGluIG1hcmtldGluZyBhbmQgc2FsZXMgY29s bGVjdGl2ZWx5IGRyaXZlJm5ic3A7b3VyIHByb2R1Y3Qgb2ZmZXJpbmdzIHRvIGJlc3Qgc3VpdCB0 aGVpciBuZWVkcyBiZWNhdXNlIHdlIGVhdCBvdXIgb3duIGRvZyBmb29kLi4gSSB3b3VsZCB1cmdl IHRoaXMgY29tbWl0dGVlIHRvIHRha2UgbG9uZyBhbmQgaGFyZCBjb25zaWRlcmF0aW9uIG9mIHRo ZSBleHBlcmllbmNlDQogdGhhdCBpbiBteSBvcGluaW9uIGlzIGJlaW5nIGRpc21pc3NlZCBvZmZo YW5kZWRseSBmb3IgdGhlIHNha2Ugb2YgbmV3IHRlY2ggdGhhdCBoYXMgdmVyeSBsaXR0bGUgdG8g ZG8gd2l0aCBvdXIgY3VzdG9tZXJzIG5lZWRzIG9yIHdhbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SVB2NiBpcyBub3QgbmV3IHRlY2ggYXQgdGhpcyBwb2ludC4gU1JUUC9EVExTIGlzIGltcGxlbWVu dGVkIGluIG1pbGxpb25zIG9mIHdlYiBicm93c2VycyBvdXQgdGhlcmUsIHdpdGggbWFueSBpbXBs ZW1lbnRhdGlvbnMgaW4gT3BlbiBTb3VyY2UuIEl04oCZcyBub3QgbmV3IHRlY2gsIG5vdCBhdCBh bGwuIEluIGZhY3QgSSB3b3VsZCBiZSBzdXJwcmlzZWQgaWYgdGhlIFVTIEZDQyBkb2VzIG5vdCBy ZXF1aXJlIElQdjYuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGhhdmUgYmVlbiB3b3JraW5nIHdpdGggc29jaWFsIGNhcmUgYWxhcm1zIGFzIHdlbGwgYXMg dGVsZXBob255IGZvciBkZWFmIGFuZCBoZWFyaW5nIGltcGFpcmVkLiBUaGUgdXNlcnMgZG9u4oCZ dCBkZXNlcnZlIG9sZCB0ZWNobm9sb2d5IG9yIGEgbGFjayBvZiBwcml2YWN5LiBJZiB5b3UgYXNr IHRoZW0gaXQgd291bGQgYmUgYXNzdW1lZCB0aGF0IHlvdSB3b3JrIG9uIGFsbCBraW5kIG9mIG5l dHdvcmtzIC0gbW9iaWxlLA0KIHdpZmksIGZpeGVkIGFuZCB0aGV5IHRydXN0IHlvdSB0byBnaXZl IHRoZW0gcHJpdmFjeS4gVGhleSB3b27igJl0IHNwZWNpZnkgdGhhdCBpbiB0ZWNobmljaGFsIHRl cm1zLCBpdOKAmXMganVzdCBhc3N1bWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vTzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxyZWFkeSBh ZGRyZXNzZWQgdGhpcyBlYXJsaWVyLiBJdCBpcyBub3QgdGhhdCB3ZSBkb24ndCBwcm92aWRlIGVu Y3J5cHRpb24sIHdlIGhhdmUgc2V0dGxlZCBvbiBvdGhlciBtZXRob2RzLiBXZSBoYXZlIGJlZW4g c3VwcG9ydGluZyBJUHY2IGZvciBzb21lIHRpbWUgbm93IG9uIGEgbGltaXRlZCBiYXNpcy4mbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBm b3IgeW91ciBjb25zaWRlcmF0aW9uLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Um9nZXIgU2x1c3NlciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEF1ZyAyNiwgMjAyMSBh dCA3OjE2IEFNIE9sbGUgRS4gSm9oYW5zc29uICZsdDs8YSBocmVmPSJtYWlsdG86b2VqQGVkdmlu YS5uZXQiIHRhcmdldD0iX2JsYW5rIj5vZWpAZWR2aW5hLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RnJp ZW5kcyw8YnI+DQpUaGlzIGlzIHRoZSBJRVRGIGFmdGVyIGFsbC4gPGJyPg0KPGJyPg0KV2UgY2Fu 4oCZdCBsZXQgYW55IGRvY3VtZW50cyBiZSBwdWJsaXNoZWQgd2l0aG91dCBJUHY2LiBUaGUgcHJv YmxlbXMgeW91IG91dGxpbmUgaGVyZSBhcmUgc3VyZWx5IHNvbHZlZCBpbiBleGlzdGluZyBpbXBs ZW1lbnRhdGlvbnMgb2YgU0lQLCBwcm9wYWJseSBzaW5jZSBtYW55IHllYXJzIGFnby4gSWYgbm90 LCB3ZSBoYXZlIHdvcmsgdG8gZG8uPGJyPg0KPGJyPg0KSW4gYWRkaXRpb24sIFJVTSBzZXJ2aWNl cyB3aXRob3V0IFNSVFAvRFRMUyB3aWxsIGJlIHVzZWQgb3ZlciBhbnkgbmV0d29yaywgaW5jbHVk aW5nIHRoZSBJbnRlcm5ldCwgYW5kIGl0IGlzIGEgdmVyeSBiYWQgc29sdXRpb24gdGhhdCBmZWVs cyBsaWtlIHNvbWV0aGluZyB3ZSBzb2xkIGluIHRoZSBTSVAgd29ybGQgYSBsb25nIHRpbWUgYWdv LiBUaGUgd29ybGQgaGFzIG1vdmVkIHNpbmNlIHRoZW4uPGJyPg0KPGJyPg0KSSBzdHJvbmdseSB1 cmdlIHRoYXQgdGhlIFJVTSBzcGVjcyBoYXMgdG8gcmVxdWlyZSBtYW5kYXRvcnkgSVB2NiBzdXBw b3J0IGFzIHdlbGwgYXMgU1JUUC9EVExTIGVuY3J5cHRpb24uPGJyPg0KPGJyPg0KSSB3b3VsZCBw ZXJzb25hbGx5IGdvIGFzIGZhciBhcyB0byBzYXkgdGhhdCBTUlRQL0RUTFMgaXMgYSBNVVNUIGFu ZCBub3RoaW5nIGVsc2UgaXMgb2ssIHZlcnkgbXVjaCBsaWtlIFdlYlJUQy48YnI+DQo8YnI+DQpJ biByZWdhcmRzIHRvIHByb3ByaWV0YXJ5IHZzIG9wZW4gc3RhbmRhcmRzLCB0aGlzIGlzIGFnYWlu IHRoZSBJRVRGLiBXZSBwcm9kdWNlIG9wZW4gc3RhbmRhcmRzIGFuZCBhIFJVTSBzcGVjaWZpY2F0 aW9uIGhhcyB0byBwb2ludCB0byBhIFNJUCBTVUJTQ1JJQkUvTk9USUZZIHBhY2thZ2UgZm9yIE1X SS4NCjxicj4NCjxicj4NClJlbWVtYmVyIHRoYXQgd2hhdCBJ4oCZbSB0YWxraW5nIGFib3V0IGlz IGRvY3VtZW50cyBhcyBzcGVjaWZpZWQgYnkgdGhlIElFVEYuIEluZHVzdHJ5IHByb2ZpbGVzIGFu ZCB2YXJpb3VzIHNlcnZpY2VzIG1heSBnbyBvdGhlciB3YXlzLCBidXQgdGhlIElFVEYgc3RhbmRh cmRzIGhhcyB0byBiZSB1cCB0byBkYXRlIHdpdGggYmVzdCBjdXJyZW50IHByYWN0aXNlLjxicj4N Cjxicj4NCkNoZWVycyw8YnI+DQovTzxicj4NCjxicj4NCiZndDsgT24gMjUgQXVnIDIwMjEsIGF0 IDIwOjU4LCBFdWdlbmUgQ2hyaXN0ZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplY2hyaXN0ZW5z ZW5Ac29yZW5zb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNv bTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgPGJyPg0KJmd0OyBCcmlhbiwgUGF1bCB0aGFuayB5 b3UgZm9yIGNvbnNpZGVyaW5nIHRoZSBjaGFuZ2VzIHRoYXQgaGF2ZSBiZWVuIGJyb3VnaHQgdXAg dG8gdGhpcyBwb2ludC4mbmJzcDsgTGVhdmluZyB0aGluZ3MgYWxvbmUgd2l0aCB0aGUgWC1DYXJk LCB0aGUgaW5jbHVzaW9uIG9mIHRoZSBpbnN0YW5jZS1pZCBmb3IgbG9jYXRpb24sIGFkZGl0aW9u cyB0byBzdXBwb3J0IG5vdGlmaWNhdGlvbiBzZXJ2aWNlcyBmb3IgbW9iaWxlLCBldGMuIGFyZSBh bGwgYXBwcmVjaWF0ZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEl0IGlzIG15IG9waW5pb24gdGhh dCB3ZSBzaG91bGQgbm90IGluY2x1ZGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgZm9sbG93aW5nIGlu IHRoZSBuZXcgUlVNIGRvY3VtZW50LiZuYnNwOyBIZXJlIGFyZSB0aGUgcmVhc29ucyB0aGF0IEkg YmVsaWV2ZSB0aGlzIHdheS48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2ViUlRDPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICogV2hpbGUgdGhlcmUgaXMgYW4gUkZDIGZvciBXZWJSVEMsIGl0IGRvZXNuJ3Qg YXBwZWFyIHRoYXQgYWxsIGJyb3dzZXJzIGFyZSBmb2xsb3dpbmcgaXQuJm5ic3A7IEZvciBleGFt cGxlLCBUTU1CUiBpcyByZXF1aXJlZCBmb3IgV2ViUlRDIGJ1dCBDaHJvbWUgZG9lcyBub3Qgc2ln bmFsIGl0Ljxicj4NCiZndDsgKiBXZWJSVEMgaXMgYW4gYXVkaW8gZmlyc3QgaW1wbGVtZW50YXRp b24uJm5ic3A7IEZvciBWUlMsIHZpZGVvIGlzIHRoZSBtb3N0IGltcG9ydGFudCBtZWRpYSBzdHJl YW0uJm5ic3A7IEl0IG1lYW5zIGV2ZXJ5dGhpbmcgdG8gdGhlIGRlYWYgb3IgaGFyZCBvZiBoZWFy aW5nIHVzZXIuJm5ic3A7IElmIHZpZGVvIGlzIHN1ZmZlcmluZyBmaXJzdCBpbiBhIGxvc3N5IG5l dHdvcmssIHRoYXQgaXMgYSBwcm9ibGVtIGZvciBWUlMuPGJyPg0KJmd0OyAqIFNvbWUgb2YgdGhl IFZSUyBwcm92aWRlcnMgZG8gbm90IGN1cnJlbnRseSBzdXBwb3J0IHRoZSBmb2xsb3dpbmcgaXRl bXMuJm5ic3A7IFRoaXMgY291bGQgcG9zZSBhIHNpZ25pZmljYW50IGltcGFjdCBvbiB0aGUgVlJT IHByb3ZpZGVycyB0byBnZXQgdGhpcyBpbXBsZW1lbnRlZC48YnI+DQomZ3Q7IG8gRW5jcnlwdGlv biAoRFRMUyk8YnI+DQomZ3Q7IG8gSUNFPGJyPg0KJmd0OyBvIFJUUC9SVENQIE11eGluZzxicj4N CiZndDsgPGJyPg0KJmd0OyBJUHY2IDxicj4NCiZndDsgKiBGb3IgdGhvc2UgVlJTIHByb3ZpZGVy cyB3aG9zZSBjdXJyZW50IGltcGxlbWVudGF0aW9ucyBkbyBub3Qgc3VwcG9ydCBJUHY2LCB0aGlz IGNhbiBiZSBhIGJpZyBqdW1wIHRvIGdldCB0aGVpciBzb2x1dGlvbiB0byBzdXBwb3J0IGJvdGgg SVB2NCBhcyB3ZWxsIGFzIElQdjYuJm5ic3A7IEdyYW50ZWQsIGl0IGRvZXMgbm90IHJlcXVpcmUg YmVpbmcgZHVhbCBzdGFja2VkIGJ1dCByYXRoZXIgY291bGQgYmUgdHdvIHNlcGFyYXRlIHNlcnZl cnMsIGVhY2gNCiBzdXBwb3J0aW5nIHRoZWlyIHJlc3BlY3RpdmUgdmVyc2lvbiBvZiBJUC4mbmJz cDsgVGhpcyBjb3VsZCBiZSBhIGJpZyB1bmRlcnRha2luZyBqdXN0IHRvIGdldCBJUHY2IGludG8g dGhlIG1peC4mbmJzcDsNCjxicj4NCiZndDsgKiBBbm90aGVyIHNvbHV0aW9uIGNvdWxkIGJlIGFu IElQdjQgdG8gSVB2NiBnYXRld2F5IGJ1dCB0aGF0IGRvZXNuJ3Qgd29yayBmbGF3bGVzc2x5LiZu YnNwOyBGb3IgZXhhbXBsZSwgdGhlIGdhdGV3YXkgY2FuIGZvcndhcmQgdGhlIElQdjYgU0lQIG1l c3NhZ2UgdG8gdGhlIHByb3BlciBhZGRyZXNzIG9uIHRoZSBJUHY0IG5ldHdvcmssIGhvd2V2ZXIs IGhvdyBkb2VzIGl0IHJlc29sdmUgdGhlIGVtYmVkZGVkIElQdjYgYWRkcmVzc2VzIHNpZ25hbGVk IGluDQogdGhlIFNEUD8mbmJzcDsgU28sIGZvciBleGFtcGxlLCBjb25zaWRlciB0d28gUlVFcywg b25lIGxlZ2FjeSBSVUUgdGhhdCBpcyB1c2luZyBJUHY0IGFuZCBvbmUgdGhhdCBpcyBJUHY2OyB0 aGUgc2lnbmFsaW5nIGlzIHBvc3NpYmxlIGZvciBib3RoIG9uY2UgdGhlIHNlcnZlcnMgZm9yIGVh Y2ggc3VwcG9ydCB0aGF0IG9yIHByb3ZpZGUgYSBJUCBnYXRld2F5IGJldHdlZW4gdGhlIHR3by4m bmJzcDsgSG93IGlzIHRoZSBtZWRpYSBnb2luZyB0byB3b3JrPyZuYnNwOyBFYWNoDQogb2YgdGhl IFJVRXMgaXMgZ29pbmcgdG8gcHJvdmlkZSBhbiBJUCBhZGRyZXNzIGluIHRoZWlyIFNEUCwgb25l IHdpbGwgYmUgSVB2NCBhbmQgdGhlIG90aGVyIElQdjYuJm5ic3A7IEhvdyBpcyB0aGlzIGdvaW5n IHRvIHdvcmsgd2l0aG91dCBoYXZpbmcgdG8gYW5jaG9yIGFsbCB0aGUgbWVkaWEgc29tZXdoZXJl Pzxicj4NCiZndDsgKiBBcmUgdGhlcmUgaXNzdWVzIHRoYXQgd2UgbmVlZCB0byByZXNvbHZlIHdp dGggTkFUNjQgYW5kL29yIEROUzY0PyZuYnNwOyA8YnI+DQomZ3Q7ICogQXMgSSB1bmRlcnN0YW5k IGl0LCBzb21lIG1vYmlsZSBkZXZpY2VzIGFyZSBhbHJlYWR5IElQdjYgYnV0IGRvIG5vdCBmb2xs b3cgdGhlIFJGQyBmb3IgZW1iZWRkaW5nIGFuIElQdjQgYWRkcmVzcyBpbnRvIGFuIElQdjYgYWRk cmVzcy4mbmJzcDsgVGhpcyBpcyBnb2luZyB0byByZXF1aXJlIHNwZWNpYWwgaGFuZGxpbmcgdG8g Z2V0IHRoaXMgdG8gd29yayB3aXRoIHN1Y2ggZGV2aWNlcyBvbiB2ZW5kb3JzIHRoYXQgZG8gbm90 IGZvbGxvdyB0aGUgUkZDDQogaW4gdGhpcyByZWdhcmQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE1l c3NhZ2UgV2FpdGluZyBJbmRpY2F0b3I8YnI+DQomZ3Q7ICogU29tZSwgaWYgbm90IGFsbCwgb2Yg dGhlIGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG9mIFJVRSBieSBWUlMgcHJvdmlkZXJzLCBhbHJl YWR5IGluY2x1ZGUgbWVhbnMgdG8gcmVjb3JkIHZpZGVvIG1lc3NhZ2VzIGFuZCBhcmUgbm90IGFs bCBjcmVhdGVkIHRoZSBzYW1lIHdheS4mbmJzcDsgUHJvcHJpZXRhcnkgbWV0aG9kcyBoYXZlIGJl ZW4gdXNlZC4mbmJzcDsgVGhlIGRvY3VtZW50IHN0YXRlcyB0aGF0IE1XSSBpcyBvcHRpb25hbCBi dXQgaWYgdGhlIGFiaWxpdHkNCiB0byBsZWF2ZSBhIG1lc3NhZ2UgaXMgcHJvdmlkZWQgdGhlbiBN V0kgaXMgdG8gYmUgaW1wbGVtZW50ZWQuJm5ic3A7IFNpbmNlIHRoZXJlIGFyZSBwcm9wcmlldGFy eSBzb2x1dGlvbnMsIGl0IHNlZW1zIGFwcHJvcHJpYXRlIHRvIG1lIHRoYXQgdGhpcyBzaG91bGQg YmUgY2hhbmdlZCBzbyB0aGF0IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBhbmQgaW5kaWNhdGlvbnMg Y2FuIGNvbnRpbnVlIHRvIGJlIHV0aWxpemVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEkgZG9uJ3QgYmVsaWV2ZSBJIGhhdmUgZW51bWVyYXRlZCBhbGwgdGhlIHJlYXNvbnMgZm9y IG5vdCBpbmNsdWRpbmcgcmVxdWlyZW1lbnRzIGZvciB0aGUgYWJvdmUgYnV0IEkgYmVsaWV2ZSB0 aGUgZXhhbXBsZXMgZ2l2ZW4gYXJlIHN1ZmZpY2llbnQgdG8gY29uc2lkZXIuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFJlZ2FyZHMsPGJyPg0KJmd0OyBFdWdlbmUgQ2hyaXN0ZW5zZW48YnI+DQomZ3Q7 IDxicj4NCiZndDsgQ09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBlLW1haWwgdHJhbnNtaXNz aW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2Vz IGF0dGFjaGVkIHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBh IHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0bw0KIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNv cHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklU RUQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2UgaW1tZWRpYXRlbHkNCiBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0IDxhIGhyZWY9Im1h aWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+DQplY2hyaXN0 ZW5zZW5Ac29yZW5zb24uY29tPC9hPiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0 MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2ht ZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLjxicj4NCiZn dDsgPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTog UnVtICZsdDs8YSBocmVmPSJtYWlsdG86cnVtLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5ydW0tYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBQYXVsIEt5eml2 YXQ8YnI+DQomZ3Q7IFNlbnQ6IFRodXJzZGF5LCBBdWd1c3QgMTksIDIwMjEgMTA6MDQgQU08YnI+ DQomZ3Q7IFRvOiA8YSBocmVmPSJtYWlsdG86cnVtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ cnVtQGlldGYub3JnPC9hPjxicj4NCiZndDsgQ2M6IEFsZXhhbmRlciBPc3BpbmEgJmx0OzxhIGhy ZWY9Im1haWx0bzphb3NwaW5hQGFzbHNlcnZpY2VzLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFvc3Bp bmFAYXNsc2VydmljZXMuY29tPC9hPiZndDs7IElzYWFjIFJvYWNoICZsdDs8YSBocmVmPSJtYWls dG86SVJvYWNoQHNvcmVuc29uLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPklSb2FjaEBzb3JlbnNvbi5j b208L2E+Jmd0OzsgQnJpYW4gUm9zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpickBicmlhbnJvc2Vu Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmJyQGJyaWFucm9zZW4ubmV0PC9hPiZndDs8YnI+DQomZ3Q7 IFN1YmplY3Q6IFtSdW1dIEFjdGlvbiBJdGVtcyBmcm9tIFJVTSBzZXNzaW9uIGF0IElFVEYgMTEx PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtFWFRFUk5BTF0gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRo ZSBtaW51dGVzIGZyb20gdGhlIFJVTSBzZXNzaW9uIGluY2x1ZGUgYSBudW1iZXIgb2YgYWN0aW9u IGl0ZW1zLiA8YnI+DQomZ3Q7IFNwZWNpZmljYWxseSwgdGhlIGZvbGxvd2luZyBwZW9wbGUgbWFk ZSBjb21taXRtZW50czo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQnJpYW4gUm9zZW48YnI+DQomZ3Q7 IElzYWFjIFJvYWNoPGJyPg0KJmd0OyBBbGV4IE9zcGluYTxicj4NCiZndDsgPGJyPg0KJmd0OyBC cmlhbiBpcyB3b3JraW5nIG9uIGFuIHVwZGF0ZWQgdmVyc2lvbiwgYnV0IGl0IHdvbid0IGluY2x1 ZGUgdGhlIDxicj4NCiZndDsgY29uY2VybnMgb2YgdGhlIG90aGVycyBhYm92ZSBpZiB3ZSBkb24n dCBoZWFyIGZyb20geW91LiBSYXRoZXIgdGhhbiB0cnkgPGJyPg0KJmd0OyB0byBzdW1tYXJpemUg dGhvc2UgSSByZWZlciB5b3UgYmFjayB0byB0aGUgbWludXRlcy4gWW91IGNhbiBmaW5kIHRoZW0g YXQ6PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9t aW51dGVzLTExMS1ydW0vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvbWludXRlcy0xMTEtcnVtLzwvYT48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBwbGFu IHRvIGlzc3VlIFdHTEMgb24gdGhlIGRvY3VtZW50IHNvb24uIEkgd2lsbCB3YWl0IG9uZSB3ZWVr ICh1bnRpbCA8YnI+DQomZ3Q7IEF1ZyAyNikuIElmIHRoZXJlIGhhc24ndCBiZWVuIGFueSBmb2xs b3d1cCBieSB0aGVuIEkgd2lsbCBhc2sgQnJpYW4gdG8gPGJyPg0KJmd0OyBpc3N1ZSBhIHZlcnNp b24gdGhhdCB3ZSBjYW4gYWR2YW5jZSB0byBXR0xDLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1RoYW5rcyw8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7UGF1bDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLSA8YnI+DQomZ3Q7IFJ1bSBtYWls aW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpSdW1AaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5SdW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtPC9hPjxicj4NCiZndDsgPGJyPg0KJmd0OyAt LSA8YnI+DQomZ3Q7IFJ1bSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpS dW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5SdW1AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bSIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtPC9hPjxi cj4NCjxicj4NCi0tIDxicj4NClJ1bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 UnVtQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+UnVtQGlldGYub3JnPC9hPjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW08L2E+PG86cD48 L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0t IDxicj4NClJ1bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UnVtQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+UnVtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW08L2E+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_-- --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=341; creation-date="Thu, 26 Aug 2021 21:43:15 GMT"; modification-date="Thu, 26 Aug 2021 21:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUSAAAFEgGIfCirAAAB AklEQVRIie1V2wnCMBQ9FUPyqRPYEeoE1g3cwBXqBOoEOoJOYJygIxg3cIR+pvRDSUnhGtOP2lZB PBCSexPOyYX7CBgXJwAL9ANpBO49kZcY9EleJ3ADcLB7awwdggzAtMh1xrgYAbgACLuMQBpyc7D7 sW0ErkBsf15h1lbAl0UKwNmSx30IdApfFs3JUiSqyr+yvi2AcZHrwOzWfoWJgC76gHGR2ruU+CLG hbfyGReJy9e40IpcqyLXsuZu79bPW5XMuNiQX+6ca0WNxgI2jdfElThPrq0EAEQe0dp0/kqz+wt8 VsCdB2WOE7OaBSHxTzw8S5JJTx34N2ayt690AkA+ALsWRF/Krkd1AAAAAElFTkSuQmCCAAAAAAA= --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=480; creation-date="Thu, 26 Aug 2021 21:43:15 GMT"; modification-date="Thu, 26 Aug 2021 21:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAUCAYAAACXtf2DAAAACXBIWXMAAAQ8AAAEPAEZaCRCAAAB jUlEQVQ4ja2UPXLCMBCFn5E0UpeUSQddSnKCcAS4AZQp6ZIq5AZQpoIbhJwgpEsHnACOQDppxE9m M2vGeGRsTXgzHkvy+lvtSrsgKW3qiBDZK23elTaHzDNX2rRSitKmq7RpJzyZAxh5ZydlbpQ2TQCf AK4LTGYAmjxupA4OvND3zg5LHKwAVIn4FcBV3gFpCqDnnd0E4C3efVV1agHDNoCV0magtMmnoVUR vOFNTgXNhJSUs7uMgWHYE30TUt4KKQ2npoqTb+9snwYJ77JecnCxmnpnO/RPjeFzDutSWqacmnd2 wfCoWijR+uiA36MLwsG18KckHShtxgC6F4AvvLP36UQcB1Iu+ZCbhb9W0/N+t12EIogtopDW3tlG dv0YwX63XQsp6/+MoEOcoAN28iGkTCIqNquhd/Ytv5iELLn4xtw2qmjine2F7JIAmKAvEXVRCAe3 igGABwbGFBvlmto7dd9Cif1uOxNS/gC4yTW8c2Dq9Y/cBc4qlCI64PQmUWRfGfDMO3tyS84KwC/b snjTWCpZ6gAAAABJRU5ErkJgggAAAAAA --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image003.png" Content-Description: image003.png Content-Disposition: inline; filename="image003.png"; size=295; creation-date="Thu, 26 Aug 2021 21:43:15 GMT"; modification-date="Thu, 26 Aug 2021 21:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAARCAYAAADHeGwwAAAACXBIWXMAAARkAAAEZAGL13mEAAAA 1ElEQVQ4jbWVvQ3CMBBGX/6UlIyQEaCjI4zABrABGyAmYAQYgRHCBGQDMkJKWy5Ah4yUBmGb+Gss y9a98/nzOQEoyqoGDoCMc2BGmAagA3rgaLTqExv8/kfQbxLYIsvy/AQsJw4uqiTp1JYllmop0TMi gNRxn1zcJSZgMFrt5NKANgbgLaNVZ7RaAxtrxWkBI9DVnuYnJAhQlNUeeLg4MPcM3ABnH2u72rSz L7PxScgHEKzU13aealNXuwUqfjcd/wdbYGUXZe7bBKUSn2rcpLUYrfoXGVA0JYXp1vUAAAAASUVO RK5CYIIAAAAAAA== --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image004.png" Content-Description: image004.png Content-Disposition: inline; filename="image004.png"; size=461; creation-date="Thu, 26 Aug 2021 21:43:15 GMT"; modification-date="Thu, 26 Aug 2021 21:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB eklEQVRIibWWMXKDMBBFv0EaKClTkhu4TGlO4BwhdGl9EvsG9hFCmQr7BjkCR6CEwXYyy6wYEEKD BvIrW5bfF7t/NWxgkQzCdwB7ADsAsbazAHAFkDV19TVFMRrIICTg2QCdEpmlTV1d9d89A/wIIHeA g/fm/N+BfA1Op/50AOt684WIn497ptY7A3Z3gVM5SgAv2vrWFyJ6Pu7fUD3gmuczoCXXetBUGYQ5 B6GvhHqienCeCU9sidHUMgVHcU5DL01d/fROHVE5+Gtk2B8TW3DO5+imwfOewZT2nqF2Uyp769sZ cNLOc8y7q+LRoK2tjQzCXwszMY2/Lhtj8RPIILT2wuOLaolsPSwEj/zHxIajDEKVnoOaAz61uths BlcyyCwG/cePtM9z4p15PPpLy2RSQWzV5PQfDFpma8BRPK0IP6l4dzFt6upAF9oK8AuzAH0OmrpK Fz4JnXxQ7tGgsXvi2HjaS1PfnVyJYjoS1+9Ve20xQe2vLQD+ALaKgDHuS7cwAAAAAElFTkSuQmCC AAAAAAA= --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image005.png" Content-Description: image005.png Content-Disposition: inline; filename="image005.png"; size=497; creation-date="Thu, 26 Aug 2021 21:43:15 GMT"; modification-date="Thu, 26 Aug 2021 21:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB nklEQVRIib1WwXHCMBDcMHjspzsIJZAOoIN0AKmApBQqAHeQDqAD6ABTgf20xw8yR/Y8hywRCE52 RjMgnfZOq5XkJxhEcTIBMAPwCiC1YzegBPAJIGvqaqvhbYIoTlYA5neShrBu6uqtTeCQayVHANsb CWXlz87Kv5OILFGcnNh2UZzcK00LmUsO5ZsMqLlWPm3qqvwF8UYIAbwLB7lw5o7ipGC21Q8kI65W 2sj0j03FJ/at+L8YGM2OAWIh3AE4ANiwHSjFpKmrPYA9w7cOVwqrl4d8bqsLtLmuxCnqHD+8Iokk VNlE06WpUMYWXL3IkVvvu0TeFRg3FLY6R3vdv51H1jPvIJBUNlFJl9T5Auxbsm9sN97CmwCADb52 2OzYXQl6QyhBbn533BUYy30B3gRNXeXG24vQJtNJgj3ndBC0KYAPHiqxolwFIZtqrB99HTRnntem nQRNXa15eXVsyr4pY1y0XEOe0pT3eQc8oS/0uVoxD2lOKFd5cfM98hYo+Ca0N7RIlHFMN/OhB8cY Q5D9+ZP5P4++SdLvZwuALwyUvZfl03noAAAAAElFTkSuQmCCAAAAAAA= --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_ Content-Type: image/png; name="image006.png" Content-Description: image006.png Content-Disposition: inline; filename="image006.png"; size=5361; creation-date="Thu, 26 Aug 2021 21:43:15 GMT"; modification-date="Thu, 26 Aug 2021 21:43:15 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAXEAAAAuCAYAAADeKCkyAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAAIdUAACHVAQSctJ0AABSDSURBVHhe7Z17kGN5Vcezr+5O7iMz3Unu7Udy MygoUJSUCFuAuIAiWLhsKTvOTHeatSxFKBQpRSgf1PherC2FeXR6sXzVAoUvEF1h/1AKEQEXRQXf YIEotWKxvpZlV9l119/59Tm/OfeX8/vdm04ynQz3U/WtyT3ne04607mnb27uo1ZRUVFRUVFRUVFR UVFRUVFRMRUap/deGO3uP+oS2g5NOBg+JPUF1Qd7f4A2J1IdqDEY7mnDC84tS/lpSPdXSLnDKNjZ vwNbikg1E2mw9wxsPTWa7a3/xYdTJ+70/+7Y+olHbWFaJOpk/yLVxMnW09CSg/K4OALlm63+gxji XMfqlyEQpSd+gMUMFLPjRFE+TrPf4R5So9VbR0shUj1XrbYWoVUjebiiNPsNtI7QTLOPSzVBkj0H LQbJxxUl2S+g1RCn/e+mPIa88H4uoVXjyxFxkt3GPc2kfxemiCWeJ8VJ/+cxPxtWTu/fKw4AFNoO jdSTC21OpBrQIg5xLmydQ/JNpAUa4tKbnwttOSQfV5T234tWA+VwcQRejyFD1O79s50rM8TjpPcP GDbwPIYMPCcp7PReilYvUq2tOOl+G9pL+UFoN0gerrDT/whaNZJHEto1l3uIqz+iP4Ipg+2xhrj5 A+8S+qaPuPIzNXaGf4jWsVnZ3n+m1JMLrU6kGtCiD3EQtjdInom0IEN8qbXxOHqjR2vdF2G4trSa Pt61EjTT/v9RPFzrfwHDtZXjG12r5rqDzAEsLqL6vs3loTjPlRnidg5w5Zpp724pFyW9F0pxHy6/ GlAvk3JSDAiSpMNzofq9YKoWr/UfpLjaGn8Iw7X6WneD16jQykHG83PFW6tWrnGQOfwQV3Ufgp9f Elo15OfClMHO8yHO4xjS8Hicdn8Jw9NFXPktoXVspF620OpEqgFdCUMchE+hkfITaUGGOH+jY8ig htftQdr/FC4afDWAK++rIcizcizNMKShON+yLDvE1R+HhzGl4TkMaVxxoNHqfTXlwqT3Ggw78fVS nw7eaed8foByYWvrnzBUuobnpRiHcmHSfwuGDj/EO9kfYcgL+bkwpWk2s2N2XhriQZp9HkMGiMdp 70dxcfqIK7+l2k1vOIb2sZB62UKrE6kGdKUMcRA+zZfsEI+S/l/QStBIe7sYdgK7E8hfU1tvGM5B ee1hSDEbsbbdDqXaoiGu/gi9kuXNliXFME6YfarB2uazMXZoHM+hiTrZ0+2czw/Y+aDTfR4tu/bV 809MGCr9PEGyYXb1HPUQj9v9v4WYej2PUL7MlvjsufGNibjyC8KK0gQ7ex+U+thqbA+9f6GkGtCV NcTPXj2T51mcfeJX8ZUAZG8Fc7gPQyPESf+PJU9RHUAe7oNdBVJt4ZZ42r/FPGYeKRanm5+1Y5Mg PQcBnwzsnM9/XXvjyZSLO71fhZjPT4Rp/622x1fHhySGNEcxxMNO9qeYNvmwvfliesyHuP0Fe5B2 78PUbAm2h3eJK78gLCmN1ENSODj/CJaISDUgM8QLkGpJaClEqgUtndl/LFq8NAa3v0Cq5wKfFCfp RnPArL7YDNu9Z/KVgNRsZx9Gi4HnMTRCM+k9V/IU1QHNdu81to+W7doyQ5wvx0n3VC6vBMtAs7X1 P3ZsEvhzwBEfIPXH6E4eB6E951fD9B4t9fvmcRDaxddgA0cJ+epcUrZrDtwHHHaIS1LD9wfRZuD5 qN19CT3GtMnzx3yIAxS3FXS2noSW6SMNC5eKtphzbN96XOrhElaJSH7QIg1xQupBKpOfB2Y1xAk1 OP5RWhFU6qoDR35lwdAIYZi2JU9RHXHJtxrzZTXgf00bkLJDPG71H+A+k8dlgA9MDGnU4P0E90se CanGlrLpT4GAlLelbEsHbvk1jNBsmn3JGCn1PFGavQftmss5xPkyPK53ui+ScvYQR66mvC3MTxdp WPiEZYXA1rVU7xKWiUh+UDXEj4ZZD3EibHWf5VoJpJiN2ur8MclTVEeQL+5031VbOd5z1ZUd4gDF 4iT7gMkrYdq5JT6LIQ5Hu6DNIPm40Gbw5Yig3XuF7fHVwZfGlAs6vVsxfFl3p/BleEy7eNSnO32o KOUcQ9xAPpL6vX8GU9NDGhY+YVkhUq1PWCYi+UGLOMQb2xd3pT4gyEtxkm4wB1yuIU6oLdh7aSVo tDeeDDG+ta5NApS3PUV1BK9vJO7nG2eIq63LXzdxJkzXgnTzU3YMUH9IXqaG0Q+DpDoX43gBl59i MMwwpInb/b+R/Bw4ksX20LKrTspf7iHewD+c6jXzL2b1Lh5aLhriBPmxxzQ5e7U0LHwKT537Nyx2 Emzv/7JU61NjZ29kq4CQ/KBFHOLB9t4pqQ8I8lKcpBvMAbMa4rBPfLnZeQwu5qAVQA2Nb4TllePr ZsvYdeIL5UEY0kgxCbUV+PW8h6tunCEOmDgTpjQUaybZJzCUw1UnMY4XcPnVQPs8i197ENWsUDzq 9H8GYzkoj7UaKcaR8pd7iEfRxhqPURygZXuIu56riUe28B5TIdy++F3SsCgSljuRasoIy0eQvKCF HOK7wwekPiDIS3GSbjAHzGKI0xtcfJNHkVmZasePdzHqrQnT7DzlQseXT7johbykKMl+ElOGcYd4 kGw+2+RQmNK44gDfZy7lbcbxAj6/K+eKA2Gnaz458GPrfTWAlL/cQxzgMSluhnhw6WSoeH3zszrG oBwIQ9NBGhRltPTtnsF1w3uvlWrKCDuMIHlB1T7xo2EWQzw4tvUk/kZXK+yHmusnvpNvwYDQrlle 23wOzwVp/37pOipoN9h5W7D/Ga3SSmy+XCXGHeKAyaEwrIHT4HkOXlec9D/DYyQscTKOF/D5Xbn6 6qWjT0DxWv+Bot+DnXMpTLqvxZLcEHcpSvu/iPZSz9FM+x9Au/j6eEx94jMHdlCMb4lzLyhOsh+K kr45R0DH0v5fo306SIOC1NgZvl+Kk7DFCJKXFJ4+/6AUJ2GLESQvaJGG+MqZC0+X6rnAJ8VJutEc MKvdKY321vP5G96WspijKIgo2XqT5CWhLYfk4+JDvJFu/hfPYTjHYYZ4rbZVN3mrDoALTfE8V9ja +jp6jHYnvA5DXnx+frSPnY/S7s/ynC20GSSPLTgBDO2aoxjicdp7nR0DKGbvTmm2N0cOx+RC2/SQ BgWpTF5C8pJqJ88uSXESthhB8oLmZYhH6ueQcuOo9pSX6ut7SDlS7Xm3BWNrBsxqiBONtHsLbH3C m149vk9t1X0/ppyoj+rvol0NzVb2ufrq5hamRojT7K+8Ur3QWguOJ0+keJT0PorhHA01pMmDIY2p 61y6FgyH8nYdB7bcaADAFR4xbGpx0UmZ5+AU+YvyavC+g46wabb69y63u1+GqRy8DxfscgmS5Ilo yxGmvZNSDVeQZD+Odudz5JRkb0a787X5YmqI72MoR5T2PkpfiOIlCkY2QKaCNChIRflwd3/kl1g/ vf8tkpcEHilOWj49fK5uZCF5QVfUEEek3CTCtlNl1kO8oqKiBCtn9m6QVnoSeOq7t3+vlCPpRgzJ QwoGF/4MPMHp4SelPCg8s/eXupGF5AVdKUMcn0Ij5ScRtp0q1RCvqJgDgp2Ld0srPUgNR7MDX8qT Vnbf1EObRvKQ0FJbunn/CVKehLYckg90JQxxbG+QPJMI206VaohXVMwB0gpPggtKoa1wqKCtFgyG H5HyJLRppDwJLTkkH2jRhzi2ziH5JhG2nSrVEK+omAOkFZ6EFs3Kqb2u5CGhzdsvOLP3fWjTSB4S WnJIPtCiDvHaLb9iLo5vI/knEbadKtUQr6iYA6QVnoQWg+QhNXaGb4cjK6QcCdsYJA+pdvJsiDaD 5AMtwhAPz1z8dGN3+M3YphCpByncGb5uXGHbqTJPQzxqbTwuTrLTzfTESbWYu4PPohAl3RvhNYxz 78yKS4Rp7wnw/xe2ey9Wi/xs0isbaUiApMvChmfOfUHyknwXuxL77Z5/WPKCgt3hn6DNIPlA8zLE fXmQSo+cIOJCqieh5ciZxRCnw+h8itdPvA/t5roWklbYWZ1AM+n/lOTjUrbSvyNC6DEWdj0p6nRf hZYRbC+Gc9geSREeuy7lbIXr2VeW9YKvCONNktwhsL4+Utx1AhQIzvJFm6aZ9n9P8nEpW+49YOU8 ZObSAy6hUUPLcL9W+Ff9bN5LcYs0ti/+ljQkQPXB/t+jLYfkLaPazutHjtetb1+8SfKS0GaQPKB5 GuKAlCehpRCploSWI+eoh3gj6f+nlOeqr6VfoxsrygxxENpLEXR63zBJvV1rq5n23obWHLZvOUlO YMpgeyTNaojDsdHg9UFeNYTfgSEN74MhDdxk2o7DPVW5X1IUbXwF2ksNcRDaNa74KMVDHIRm3Rf+ hSGuPkF8LGr3C+9kNUJ4+vwXpSEBQssIkreMsHwEyUtCi0HygOZtiNd3L7xK8pDQ5kWqI6HlyJn1 EMeQi2s93tzKhLHcEMeQIUqz36dc3OmKGzASVMOFqUIa7c2vYjW570e8/cKwxfMuny9nQ74g7X8S Q058fX05G8kbJf0hj4dp9+WYkvzmFnYspoGbH0s5PsQxZFDvgY9RTv1h+W0Mj/GaLg1xDBikM37p Xz3ED3savjQgSGgZIRjsv1vy+1QfDP8by0eQ/CS0GCQPaN6GOBAOhg9JPlA4OKc/PvmQ6khoOXKO cogX+eACVSbfaOl9zL4hDlDOlZcgf9zKPkeP4QxFTHtprmdvphoM2YhffFMNKOr0b3X14D4MOSHf pENcfTRJTK+kK55xSaiB+q92H1rmwpTJhe3up/ky93DCJHuLyYfrLYj5hjhAOZ6XYjLuIQ5YfaZz 5qY0IEhoEZH8PtXOHtw3UkLyk9BikDygeRzigOQjLe9c8N78VqohoeXImechDlCePtrPcojXVldj frEnTHsJVvO7YjBciF3jqrd9Psg38RCvrcamV8EQh8sN231oGS6X4MqF7exb+TL32FC+mW7pS2cf 5RAHKB+rrX4MTYL/GuJoEpH8PmGZSDhwf7lZ39l/K9o0kgc0r0O8dvPP1SUvCV0ikp+EliNn1kMc hq4ttLGVc/RynwTvBctQz5c5caf/bsrxm+L6aLIaWF6KNh/Ll8tAfq5w/WCr0QX5grVMbwjQsvoj 8pvagFAcZP8/gtCmIR98z2D74EYUaNPwvhgy+HIStpcv88fSLfZoGW5IgaERyEN13t0pSf/PKQdb 8Rge6eGm/BAv7lWC+uDi9dKAADV2Ln4cbSIrOxdukeokBWf2cl9a2AS7w9+V6kD2ES2SBzS3Q1xR 3774HslPQtsIkpeEliPnKL7YRNulFdizRWPXwUDiMZd0cQmkGloO060bMFQI78O1tLauv0jkqK3Q l1MeQ+LPAfC4JLRppDypmfbuRptG8thqJptfRLsX8kftnv5Sj5btx1GSvZ8vA7TM91/bkIfq+BD3 SRcjrvgol3mIS8OBFO7u34Q2J1KdJLR7kepIaNFIedA8D3FA8nOhLYfkI6HlyJmHIe66oiBg15UZ 4rqwJFQTpNmdGJpkJV3mtaSm9amA5zAE1x1/rR0DuFcS2jRSnjTuEA+S7CfQWgjVwCcA++gTk2N3 nKccQMtR0n07hkaw68oMcV3I8OXyzNEQR4sXqU4S2r1IdSS0aKQ8aN6HOCDVkILB6KcVyWe0vf/q cVU/fWEDW0+NedgnTl9ySdi9+BDXBsWyClJMDZE3YrgQOHTR7gXEaf8eKT4O/GO93aco3ljvPQVD pf8vAfIddp+4FCtD3Om9j9eCYrXVDTk4agOW4WeiHP99U8z+I8MhDwiWpd0p9bWtp1JMvQe+B8MG yvEamQUb4jU1FKRarvrOULx+so1US6rdcNaceSXlQYswxJe3h4+R6kgr27dlaNVInok02HsGtp4a V8oXmxSz4z6KLvoPUrZJzhw1N4uI0x6d+HYN7y9JDbz70TvW62L1h/5ik2LNVv9BDBWycnyjy/uB orVLx3Xbufrq5vWYKvX6KE/fnbj2iVPMjgO+XJ7CIX4V5e0bXRwKcUVHoaUQqZYLbYVItaSVwd5L 0Ob0LcIQB9TW8H1SLQltGik/kb7EhniY9N5g8sePNyHmGuIxu5NQkPR+GsNeyO8T7MdFuxM1VB5R W5734GIO6kP7/eN2Zu4o75MuVkgxF+SbxhC340XwOru2bA5DOYJ2dqfJt9v6Mh6uIa62wF9B8UZr 6zswrKG4XTOKf4iX71OCpZvPjX0ZWIng1PB+qR4UDs49jLZCgp29D0o9SGhb+CEOSLVcaKuGePEb PbdVijGDlHMNcUDye7iavEHSfyXGDGV7cR+c+INhTdhe/1rTA09L535tYoTt3s12zue3Id8kQ1xh fidwf02MFcL7gTCs8eUU5oQv+GOIsQPirVWpzjXEAckPuOKjuIc4fEIq36cEwc7wneKKrqQGauEt sDhSD1Dt5Ov11k8Z6jt7T5V6kNDmfK5FGuKAVM9VxjO2rrwhDiukOVnEJbitGtq9QzxIe3dTrp50 b8SwiHSkBAc+uvvyHPL5hFbjjZKu+FGc8mGS3cGXQdrggXt9sr26mOHLueA1dp0vBzTSrdyZkJLg ew+0e4d4vdP/D8qttLrPwnCp/5sD56Uh7tOBd0LElRzF90GXQeoBwnRppB4ktDg9izbEG2eGz5d6 kBqDvVdL8Yl0BQ5xgA9fW7UwbKNN4xviQK7WQwlfSPmotflNGHPSTLOHeE8utNQidoQGhkaw6+xl H9zrk+3VxYwwvfSJQMpL8JtBh+3swxjWhEnvLsrV29m/YzgHv/+oLZXOXQ3VN8QBq1bDYy4dOP1D PG6V/3RSzM652KlxGdwRTKWP1INESDnQDWed1+XOIdWSyiLVgmqPjnf1O6nHLHXy5DX4zFMDrk+B D4+cRjtLo6R/fZyceJpanPprvRwst7e+HF5DuJo9HkMVY1Bf627o90DahYuezeaGxBUVFRUVFRUV FRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRXzSq32/7zr0aZSsOu7AAAAAElFTkSuQmCC AAAA --_009_BLAPR09MB622753FA5825DF6EF412F346C6C79BLAPR09MB6227namp_-- From nobody Thu Aug 26 15:08:01 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C81E53A0C60 for ; Thu, 26 Aug 2021 15:07:59 -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, 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=mitre.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 jVu0gX-VQq-z for ; Thu, 26 Aug 2021 15:07:53 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (smtpvbsrv1.mitre.org [198.49.146.234]) (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 BBC343A0C5D for ; Thu, 26 Aug 2021 15:07:53 -0700 (PDT) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0B19F336009; Thu, 26 Aug 2021 18:07:52 -0400 (EDT) Received: from smtprhbv1.mitre.org (unknown [10.20.0.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpvbsrv1.mitre.org (Postfix) with ESMTPS id B7E39336014; Thu, 26 Aug 2021 18:07:51 -0400 (EDT) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 36BE080C19D; Thu, 26 Aug 2021 18:07:51 -0400 (EDT) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4GwcRC4pd0z3D4RY; Thu, 26 Aug 2021 21:59:45 +0000 (UTC) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02lp2106.outbound.protection.outlook.com [104.47.65.106]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4GwcFn3LDFz3D4WR; Thu, 26 Aug 2021 21:59:40 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=arlPKwC+a6kgmFQHW9tsVT/HanIS8mLdjwVWQjHiqPQLdVuTqTPeTF5suJ+yMCjOvrRgbM07ob9YYf+rQHGWGEUSAgrO7LjyCCAHYod7w4T7KZwAO/VQZ2eGFAv+HP+CzQ7EuowMMurYieIxxaerfrDtEeOlybuzBqzfimBWKR8LvsfFaR7fDFz6zwIT63rwWriqB+5fDCVKL39gHPpnai/hqgm/CSCXVtZHA4H7VvUKHSDSxYnrOj8slLSlEEKcVk8M1nrInXHi46PPFFaLKEh7GRaTv5mNEIhr4JBrVTrFGhTBGuFI8qZkLB8fXuXEEyykEI+6H6M4W9yNEmSBXQ== 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=L0cGdjCd7NHjktRZRbpprJn5E0J69Vy3uSwomFsM/o0=; b=NmMBh22c1XimEzadQPu3KvjgVTbiJw7T8i1wZk/OdJPnFlGxs9RIBVng2/PRmKhisavB3NPTYD42SnvtYvv2+z0545Ok7K9b7ID6iVS/8uOeY3A/0TAYIPERLNQHF8HZy9pSM/2ZDmVtj3t/V2FwRCrAd1HK4WWmORydvPlLOoHvhfud6HlJ+YyJalgmbCOjULK+ckyT8D4OikYuDGg/JPCjvl6SGqhzNkK4GVcxUiOoha/O09kt8rKqwNW2UZYVV/xEDuO0n70sYyzVd3b9TP7PcQ704tlJUlOs/KGVqhgWJoArxs1QgX9l7lXFSCBrpnp5CAoOwdFzkjWinUpWFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=mitre.org; dmarc=pass action=none header.from=mitre.org; dkim=pass header.d=mitre.org; arc=none Received: from BLAPR09MB6227.namprd09.prod.outlook.com (2603:10b6:208:2a8::17) by BLAPR09MB6212.namprd09.prod.outlook.com (2603:10b6:208:2a0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Thu, 26 Aug 2021 21:59:38 +0000 Received: from BLAPR09MB6227.namprd09.prod.outlook.com ([fe80::3534:b411:1c35:7ef1]) by BLAPR09MB6227.namprd09.prod.outlook.com ([fe80::3534:b411:1c35:7ef1%7]) with mapi id 15.20.4436.027; Thu, 26 Aug 2021 21:59:38 +0000 From: Joe Gruessing To: "Kyzivat, Paul" , Roger Slusser CC: "rum@ietf.org" Thread-Topic: [Rum] IPv6 and encryption Thread-Index: AQHXmsQ+Bg1LyB0MOkWzcXyIqXLaeauGVAmw Date: Thu, 26 Aug 2021 21:59:38 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> In-Reply-To: <21b89f7f-11a3-95e4-dc31-233893a03b53@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=mitre.org; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c42aec7c-17bc-4658-f2ad-08d968dccc8c x-ms-traffictypediagnostic: BLAPR09MB6212: x-ld-processed: c620dc48-1d50-4952-8b39-df4d54d74d82,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xj7cIPqgvNervwSJyNQTmUG+sKsCfOsV7l8luAkKeehLrpPY/QfwDQMMX55Ua0pdY8Ry9Ni8c6+ITXAMiiZSvNG8tq9PzW43bOsVYY5GfBkIT6JRGXul7WeJFe+JxsUR5AmCD67f0Efd8lqGLkt0UdQXIX7NTxQqLWJMRZEfIFF2x9wD1lKNSPnhmQjVxynPVJgZ02+VO2DUr+5MIRLRw5SLQwAoZnOuywNhm/uaQ96JNpq4w0m2w0W8koMucnRn8eYjJraFlpfMkJXDwM91VFsIweZrbuxX+vQo/sidE7mpGPz+lb0tSxCkb/a98+Nw3ZBfdvraGh/BkKKG7odCM1W0CFwIRt3AhQeWSc2LvHxVMe53J2i8itNjz5yQBvpPPupbbxZDyOsCNe7PdMTAWMaIIT85MZnQYs2PedmwSYSSJK8TUngqZKddUiAA4cZlZspfA3lcLuovbIXSUJetdjSudrEbMJs0Bnmsnp+8vI7NTNnyW/HHBx0yoRhJk3uii9cZ7ui78C5axLhUoNY7lqtN/6ZAkGAcK5uIDsp/GF/nsD39CnBeHxPkoVX6dz6hJtC5FR3G6XHHdGl02JutEDhw8uL9SeIxOoyng5Dy4dsmu6NaoreLGU3XJh4b8GiySKvV3VnouZMwY0K5bWYzwI8fM2RCI0qlug2CkGHvfJu7rCVwnZZfxtcXuPQCWWaX9DfOv3jz5U6M61Gs5uWvhA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BLAPR09MB6227.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(8676002)(55016002)(83380400001)(8936002)(4326008)(9686003)(110136005)(186003)(33656002)(71200400001)(2906002)(76116006)(52536014)(316002)(86362001)(26005)(7696005)(508600001)(66556008)(66946007)(64756008)(5660300002)(38100700002)(66446008)(53546011)(122000001)(6506007)(38070700005)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?LzZjWXgrRVFWcktGbGM0L0RtT2ZPNWRwTnIrT1JCcDdUczdCQ2xmc2ZLRXR4?= =?utf-8?B?ejlBRkFuSFcyRWIwNDhON3RrekhGcC9nRjZjaE9OSnpEcU1EWjMrZWwzNjJ2?= =?utf-8?B?NUlmcUFJSmlsa0dXYjRSOUpFT3hCRE9nTmVMdDJ4ZFlleURwM3NGT0txdWU4?= =?utf-8?B?ODBrWDlvS3pxT2cwQ0R1UzZnRDFlK0l5Z3UveGdMc3EwTVdNMHhnRjdnU3M4?= =?utf-8?B?cUdsaHdkeFloNnQxRnhkajYyN0s1blU1aFdlRjB3RGIxeUFsRVFCVDhuZ0xF?= =?utf-8?B?aW53NU15Y3pkS0JwYmNlWko3dEVzMlpONHQ0VGZ4dDkyLy80NDMyN1h4V3hF?= =?utf-8?B?M3NnVUFwQ2tFMW1Ga3FZKy83QjdaZWRPbS8rRjBSUmpNdXhUbHNCbW9Ca2JF?= =?utf-8?B?cnBWb0ZSVkRDOFl1TDB3TWd0M0NHOU50em9hcTAxLzE2MTJOVTVRUFg2bWEr?= =?utf-8?B?TlcyUW14NzN3MklNZ0FzQW5zTnREUVREMklpUmNiZzNvaGhWaTZsaVdRS09m?= =?utf-8?B?V1ZtQkFZUmtDRldNbk5kY3JIbWVrQTBlUTFna0o4anJ4OGJ5dVNPT0NrS1hz?= =?utf-8?B?TUZTTHRxdkg4VElPREZ2RHhBcnBsU2RwSUtDZXFIeXg2SEtmQnJKVm9TcVZp?= =?utf-8?B?MVFLUm5EZlNGSUV2SklERk5UNUkxYmRpMUNYM2ZnTFFISXoyQzlWSzhaV3RQ?= =?utf-8?B?MlBWUDBOZnVwbkhUendYZGtFOTJXc2RtNWdMdmhBcDBNSUcweG04bjdpOG5S?= =?utf-8?B?WVpic21RUXBna3JlaWFtUENib1VEcWlpQjBERFFPbzJscHp4Q3BqOEdzRXJ2?= =?utf-8?B?N1pTUFk4SHlBNTA4YUt0SWsvd25UanFUVHZ2SFNCZk5vZTFKemNCSGpsS1Ux?= =?utf-8?B?NnpadU1VS2dXNjh6MUhPalBSQVF3MENUMk5FN0R1MytZZ0JkWnJVN2Faamow?= =?utf-8?B?ZjZtdElRMkZXMUtNc1VXOWFUeHNRZDkyRjNZRi9icytiYXlrcnZzMVJHYTZn?= =?utf-8?B?b2tHd1JvUzI4OXIwVFNGT3JEaHRqQ2w2NW14QTJTZUIzMVJzRGVxYmZkb1Iy?= =?utf-8?B?L0ZUU28yam9PUE13a2t4bytmK3luL3B0aXd3T3RwdWdxNi81RVFKbTR4aFJo?= =?utf-8?B?UjFqWFByOWFaRTVZN2VkK29jeldscnpRRGZ6NTd5WVNSZ2dremF6S0ZIamdi?= =?utf-8?B?RHFnT3lwWStteWM2SEhtNUQ3V1BxTndkL3ZMU04yUGI2U250d1dLbytyYndh?= =?utf-8?B?aEZyb3VvTUM2cVZPbi9rbXNSNjJNZE9iRFFJZGdIMWE4QzdKREJKYUlwV1RK?= =?utf-8?B?ZndpQmlqTGowMzh6dUMwUndHMGx6NFRsa0ZlS2MxM28vNTNyTVlDb3FLamE4?= =?utf-8?B?UHpNUjd1UnlBMjIxbGh4MkRSYzd4NkNVTlVEdnNOWDh5Qk1oa1AvQ0JsQmFJ?= =?utf-8?B?Qk1QcjlTK2hIcmt4ZTFldHluNmF0NXhDME9LWnRLTGthczNRaXJWeXRjVFdt?= =?utf-8?B?c2xQam1tM05CNFBlSG81ZEVRdUpUM0c3bzNyM3FLck4zd2UzWVptWWRQblls?= =?utf-8?B?MVNKNmNad256bHhCd1dReHl0NmdBU1ZxbmJneHh6QVk1TEhSOGVuY0R5Q0xW?= =?utf-8?B?dmZpVklZcTczcHpoUGltcmIwUlZ5eGtXUzViUHJEVkRxYWwrLzYyQ1cvb25q?= =?utf-8?B?Si9DN25rS3hQUlhES0F4M3doa1pZZE9sV2FQbUhJc085U2t2U1ZFOTNMMXY1?= =?utf-8?Q?13JrritFI0oo6nwFvZzbKCrFHpKExiFmNYCGXd+?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BLAPR09MB6227.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c42aec7c-17bc-4658-f2ad-08d968dccc8c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2021 21:59:38.2951 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6212 X-MITRE: 8GQsMWxq66rxk57w DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:cc:subject:date:message-id:references:in-reply-to:content-type:content-transfer-encoding:mime-version; s=BTxNELhf; bh=L0cGdjCd7NHjktRZRbpprJn5E0J69Vy3uSwomFsM/o0=; b=GhqxDjWeU8gQlGxP7I1IcnkxPlvKcjs2p68SxmwJ9QeTKVFFpGmbPgNGel430rDsuTRcsRa3QZd68ptO5N96MSldou2GTp6tePsLmT5EmALUG5SM0ib+tgCffrE/jccxRjKvdXNvWzB9KPuNlnsiRVZBUGqiBuj0m5RQ9IEcF2o= Archived-At: Subject: Re: [Rum] IPv6 and encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2021 22:08:00 -0000 DQpUaGUgcHJvdmlkZXJzIGhhdmUgYWxyZWFkeSBhZ3JlZWQgdGhhdCBlbmNyeXB0aW9uIGlzIGlt cG9ydGFudC4uLiB0aGF0J3Mgd2h5IGl0J3MgZGVzY3JpYmVkIGZvciB0aGUgc2VydmVyLXNlcnZl ciBsZWcgaW4gdGhlIFByb3ZpZGVycyBQcm9maWxlIGxhc3QgeWVhci4gVGhhdCBwcm90ZWN0cyB0 aGUgc2VydmVyIGluZnJhc3RydWN0dXJlLiBHcmVhdC4NCg0KVGhlIFJVRSBjbG9zZXMgdGhlIGdh cCBzbyB0aGF0IGNsaWVudC1zZXJ2ZXIgYW5kIHVsdGltYXRlbHkgZW5kLXRvLWVuZCBwcml2YWN5 IGlzIGVzdGFibGlzaGVkLiBUaGUgZW50aXJlIHdvcmxkIGV4cGVjdHMgdGhpcyBub3cuIFdoYXQg aXMgc28gdW5yZWFzb25hYmxlIGFib3V0IHRoaXMgcmVxdWlyZW1lbnQ/IFJld29yZCBpdCBpZiBp dCBuZWVkcyB0byBiZS4gIElmIEkgaGFkIHRvIHBpY2sganVzdCBvbmUgcmVxdWlyZW1lbnQgYXMg bWFuZGF0b3J5LCB0aGlzIHdvdWxkIGJlIGl0IHdpdGhvdXQgYSBkb3VidCENCg0KSm9lDQoNCg0K LS0tLS0tLS0tLQ0KSm9lIEdydWVzc2luZw0KSW5mcmFzdHJ1Y3R1cmUgRW5naW5lZXJpbmcsIFBy aW5jaXBhbA0KR3JvdXAgTGVhZGVyLCBMMTE0DQoNCk9mZmljZTogKDcwMykgOTgzLTIwNzUNCk1v YmlsZTogKDcwMykgMzQ3LTI0MDINCg0KwqDCoA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiANClNlbnQ6IFRodXJz ZGF5LCBBdWd1c3QgMjYsIDIwMjEgNTo0MCBQTQ0KVG86IFJvZ2VyIFNsdXNzZXIgPHJzbHVzc2Vy QHp2cnMuY29tPg0KQ2M6IHJ1bUBpZXRmLm9yZw0KU3ViamVjdDogW1J1bV0gSVB2NiBhbmQgZW5j cnlwdGlvbg0KDQpSb2dlciwNCg0KT24gOC8yNi8yMSAzOjMwIFBNLCBSb2dlciBTbHVzc2VyIHdy b3RlOg0KDQo+IE1vc3QgcHJvdmlkZXJzIGFscmVhZHkgc3VwcG9ydCBlbmNyeXB0aW9uIGFuZCBJ UFY2IG9uIGEgbGltaXRlZCBzY29wZSwgDQo+IG5vdCBuZWNlc3NhcmlseSB0aGUgd2F5IGl0IGlz IGRlZmluZWQgaW4gUlVNIHNwZWMuIE1hbmRhdGluZyANCj4gY29tcGxpYW5jZSB1c2luZyBNVVNU IHJlcXVpcmVzIHByb3ZpZGVycyB0byBkaXNjYXJkIHNvbWV0aW1lcyBodWdlIA0KPiBhbW91bnRz IG9mIGRldmVsb3BtZW50IHRvIGNoYW5nZSBvdmVyIHRvIHdoYXQgUlVNIGlzIHNwZWNpZnlpbmcu IFRoZSANCj4gcHVzaCBiYWNrIGlzIG5vdCBhYm91dCBkb2luZyB0aGVzZSB0aGluZ3MgaXQgaXMg YWJvdXQgdGhlIGxvc3Mgb2YgDQo+IHRpbWUsIGVmZm9ydCBhbmQgbW9uZXkgdG8gZG8gdGhlbSBp biB0aGUgd2F5IFJVTSBtYW5kYXRlcyB3aXRoIE1VU1RzLg0KDQpEbyB5b3UgdGhpbmsgdGhlcmUg aXMgc29tZXRoaW5nIGVsc2Ugd2UgY291bGQgd3JpdGUgaW4gdGhpcyBzcGVjIHRoYXQgY292ZXJz IGVuY3J5cHRpb24gYW5kIElQdjYgaW4gYSB3YXkgdGhhdCBpcyBsZXNzIGJ1cmRlbnNvbWUgZm9y IHByb3ZpZGVycyB3aGlsZSByZW1haW5pbmcgaW50ZXJvcGVyYWJsZSB3aXRoIGFsbCBwcm92aWRl cnM/DQoNCklmIHNvLCBjYW4geW91IHBsZWFzZSBzcGVsbCBpdCBvdXQ/DQoNCglUaGFua3MsDQoJ UGF1bA0KDQoNCg== From nobody Thu Aug 26 23:02:05 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACA663A1B26 for ; Thu, 26 Aug 2021 23:02:01 -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 7xnibQ4gwhWB for ; Thu, 26 Aug 2021 23:01:53 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 ADB903A1B22 for ; Thu, 26 Aug 2021 23:01:50 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 3F10D2171; Fri, 27 Aug 2021 08:01:45 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C6857080-EAF1-4126-BBBE-E9FB192F38C8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 27 Aug 2021 08:01:43 +0200 In-Reply-To: <72b016c0-6ffa-fb0e-ad3c-bbe687b8528b@alum.mit.edu> Cc: Ed Sayers , Eugene Christensen , "rum@ietf.org" , Brian Rosen , Isaac Roach , Alexander Ospina To: Paul Kyzivat References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <72b016c0-6ffa-fb0e-ad3c-bbe687b8528b@alum.mit.edu> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 06:02:02 -0000 --Apple-Mail=_C6857080-EAF1-4126-BBBE-E9FB192F38C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 26 aug. 2021 kl. 19:31 skrev Paul Kyzivat : >=20 > Ed, >=20 > One takeaway from your comments below is that the current spec doesn't = say much about *retrieval* of video mail. >=20 > Is there something we can specify that the RUE could use with all = providers to retrieve video mail? E.g., could that simply be a https URL = that will bring up a web page that the user will use to choose, play, = and delete video mail? Defining an extended subscribe/notify implementation with a list of = URI=E2=80=99s in addition to voicemail status seems fairly simple. You = could even ad an optional URI for a thumbnail of the video to help the = UI a bit. As well as the caller ID. All provided we have a secure = connection. /O >=20 > Once we find a standard way to retrieve video mail then we can revisit = how to deliver a notification. >=20 > Thanks, > Paul >=20 > On 8/26/21 1:15 PM, Ed Sayers wrote: >> Hi Paul, >> The issue of MWI is far more the just mechanism of notifying the = user. Whether that be push, email, SMS or anything else Provider can = already support. >> In addition, VRS Providers each solved the SIP PUSH problem 10+ years = ago - long before the RFC was created - Following the needs of our = customers and because RFCs like RFC8599 didn't exist, or because = RFC-3482 was insufficient and there were no other adequate alternatives. >> Providers also currently use their own RESTful APIs to stream and/or = download Video messages to the client for playback. >> This cannot be supported by RFC-3482. Even if it were possible using = the RFC-2822 message headers, section 3.5 states "Message headers MUST = NOT be included in an initial NOTIFY, as new messages could be = essentially unbounded in size". This means that MWI cannot provide = streaming URIs for any old or initial new messages, and leaves a = historical 'dial-up' mechanism as the only complete option when using = this RFC. >> Providers would thus need to go and re-implement that "old tech" that = was thrown away years ago and provides a much poorer user experience; A = call to a Video IVR, to be navigated by DTMF tones. If nothing else, = this requires a customer to be online every single time they want to = view a message (And potentially incur data charges every time). Whereas = any streamed message could be cached and still be viewed when offline. >> We completely understand that there is no RFC that can currently = support the way we provider video mail notifications and messages. We = knew that a long time ago. >> However, it needs to be made clear that this is a deficiency of the = currently available RFCs, not one that VRS Providers are currently = constrained by. >> However, the creation of the RUM specification will constrain the way = that Providers can provide features such as this, stifle innovation, and = in cases such as this certainly be a limiting and retrograde step. >> Many thanks, >> Ed Sayers >> Endpoint SDK Team Lead >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com >> The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >> -----Original Message----- >> From: Rum On Behalf Of Paul Kyzivat >> Sent: 26 August 2021 16:48 >> To: Eugene Christensen ; rum@ietf.org; = Brian Rosen >> Cc: Isaac Roach ; Alexander Ospina = >> Subject: [Rum] VRS Provider issues - MWI >> I want to split off MWI as different from the other issues you have = raised. If I understand, your point is that each provider has a = proprietary way of indicating video mail is waiting and retrieving it, = so there is no need to do something different. (Please correct me if I = have gotten this wrong.) >> The problem with this is that it means for a RUE to be able to access = video mail it needs to support the proprietary mechanism of each = provider it aims to work with. But interoperability of the RUE with = multiple providers is an explicit goal of this work group. So we need a = mechanism that the RUE can implement that will work with any provider. >> In principle this mechanism need not use the MWI mechanism, but = coming up with some other, presumably purpose built, mechanism will be a = hard sell. >> IMO proposals that fail to address this need for interoperability are = out of scope. (To go there would require a change to the charter.) >> So, please frame video mail and MWI issues with interoperability as a = requirement. >> Thanks, >> Paul (With my RUM WG Chair hat ON) >> On 8/25/21 2:58 PM, Eugene Christensen wrote: >>> Brian, Paul thank you for considering the changes that haved been = brought up to this point. Leaving things alone with the X-Card, the = inclusion of the instance-id for location, additions to support = notification services for mobile, etc. are all appreciated. >>> It is my opinion that we should not include requirements for the = following in the new RUM document. Here are the reasons that I believe = this way. >>> WebRTC >>> * While there is an RFC for WebRTC, it doesn't appear that all = browsers are following it. For example, TMMBR is required for WebRTC = but Chrome does not signal it. >>> * WebRTC is an audio first implementation. For VRS, video is the = most important media stream. It means everything to the deaf or hard of = hearing user. If video is suffering first in a lossy network, that is a = problem for VRS. >>> * Some of the VRS providers do not currently support the following = items. This could pose a significant impact on the VRS providers to get = this implemented. >>> o Encryption (DTLS) >>> o ICE >>> o RTP/RTCP Muxing >>> IPv6 >>> * For those VRS providers whose current implementations do not = support IPv6, this can be a big jump to get their solution to support = both IPv4 as well as IPv6. Granted, it does not require being dual = stacked but rather could be two separate servers, each supporting their = respective version of IP. This could be a big undertaking just to get = IPv6 into the mix. >>> * Another solution could be an IPv4 to IPv6 gateway but that doesn't = work flawlessly. For example, the gateway can forward the IPv6 SIP = message to the proper address on the IPv4 network, however, how does it = resolve the embedded IPv6 addresses signaled in the SDP? So, for = example, consider two RUEs, one legacy RUE that is using IPv4 and one = that is IPv6; the signaling is possible for both once the servers for = each support that or provide a IP gateway between the two. How is the = media going to work? Each of the RUEs is going to provide an IP address = in their SDP, one will be IPv4 and the other IPv6. How is this going to = work without having to anchor all the media somewhere? >>> * Are there issues that we need to resolve with NAT64 and/or DNS64? >>> * As I understand it, some mobile devices are already IPv6 but do = not follow the RFC for embedding an IPv4 address into an IPv6 address. = This is going to require special handling to get this to work with such = devices on vendors that do not follow the RFC in this regard. >>> Message Waiting Indicator >>> * Some, if not all, of the current implementations of RUE by VRS = providers, already include means to record video messages and are not = all created the same way. Proprietary methods have been used. The = document states that MWI is optional but if the ability to leave a = message is provided then MWI is to be implemented. Since there are = proprietary solutions, it seems appropriate to me that this should be = changed so that proprietary solutions and indications can continue to be = utilized. >>> I don't believe I have enumerated all the reasons for not = including requirements for the above but I believe the examples given = are sufficient to consider. >>>=20 >>> Regards, >>> Eugene Christensen >>>=20 >>> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and = destroy the original transmission and its attachments without reading = them or saving them to disk. >>>=20 >>> -----Original Message----- >>> From: Rum On Behalf Of Paul Kyzivat >>> Sent: Thursday, August 19, 2021 10:04 AM >>> To: rum@ietf.org >>> Cc: Alexander Ospina ; Isaac Roach >>> ; Brian Rosen >>> Subject: [Rum] Action Items from RUM session at IETF 111 >>>=20 >>> [EXTERNAL] >>>=20 >>> The minutes from the RUM session include a number of action items. >>> Specifically, the following people made commitments: >>>=20 >>> Brian Rosen >>> Isaac Roach >>> Alex Ospina >>>=20 >>> Brian is working on an updated version, but it won't include the >>> concerns of the others above if we don't hear from you. Rather than >>> try to summarize those I refer you back to the minutes. You can find = them at: >>> https://datatracker.ietf.org/doc/minutes-111-rum/ >>>=20 >>> I plan to issue WGLC on the document soon. I will wait one week = (until >>> Aug 26). If there hasn't been any followup by then I will ask Brian = to >>> issue a version that we can advance to WGLC. >>>=20 >>> Thanks, >>> Paul >>>=20 >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_C6857080-EAF1-4126-BBBE-E9FB192F38C8 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: http://edvina.net iQGzBAEBCAAdFiEEAsV9zKckq/QkNi1DMKLWpfU/lUYFAmEof8cACgkQMKLWpfU/ lUbVYgwAw9BG7yeVRYk1zBqR54xQnA+1+2QGo882+9V1TZdbTHN5vRAst8QlBMv3 w5YsQ44BIYJyj1J43N9hvPRXvgLwNVRsQQE7G5Hozp4B6uUU+X+NZh6W9A1YEz20 L2rTK+v5ac7CjvqBbHMhtpeD6Cy+VgW29gcUKqyHjj1lxs5C+SodoBWP4EHRWPnj ryalOSf8n4vPuJQkBuBnxlEQ96f0VAMMwzltTBRtl8E/EdRJ1mAfhSC0+5nS8X0y cc8Xtlcsedy+03bLguzbNt1UH+gQwmNjrQlXE5qdV7HvW2U+t16558k9MIiRoM/K QGV94r4a61NpM28p+948dbX4H/A5ibWpp2o4AMfNt62kW/VhrrR9AnEY+yzP/GeS bdP/kSDvaqXgS/lv4RU7+I/yUjKEujdBKN+1z6+v7a/PiCngiOJDoIItl6yCQE45 pawmgsuKyKf6nTT/gwf1MWDgU0t0DGqbTc0k445ncDuUjaRrVo2mbBJmrmiJdm9Q LAaDXNYC =4gaT -----END PGP SIGNATURE----- --Apple-Mail=_C6857080-EAF1-4126-BBBE-E9FB192F38C8-- From nobody Thu Aug 26 23:09:44 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1EEE3A1BA2 for ; Thu, 26 Aug 2021 23:09:42 -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 yjUErJ9-2zeD for ; Thu, 26 Aug 2021 23:09:36 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 F342D3A1B9F for ; Thu, 26 Aug 2021 23:09:35 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 A0BA92171; Fri, 27 Aug 2021 08:09:31 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B45323DD-795B-4217-8FC7-A02C743303F4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 27 Aug 2021 08:09:30 +0200 In-Reply-To: Cc: "Kyzivat, Paul" , Roger Slusser , "rum@ietf.org" To: Joe Gruessing References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] IPv6 and encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 06:09:43 -0000 --Apple-Mail=_B45323DD-795B-4217-8FC7-A02C743303F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > 26 aug. 2021 kl. 23:59 skrev Joe Gruessing : >=20 >=20 > The providers have already agreed that encryption is important... = that's why it's described for the server-server leg in the Providers = Profile last year. That protects the server infrastructure. Great. >=20 > The RUE closes the gap so that client-server and ultimately end-to-end = privacy is established.th There is no standard in SIP for end-to-end privacy. It=E2=80=99s = hop-by-hop. It=E2=80=99s a gaping hole that we have to solve. This means = that any SIP messaging and possibly also audio will be in the clear on = the provider=E2=80=99s server. Yes, there=E2=80=99s S/MIME in RFC 3261 but during all my years with SIP = I so far haven=E2=80=99t seen any interoperable implementations. > The entire world expects this now. What is so unreasonable about this = requirement? Reword it if it needs to be. If I had to pick just one = requirement as mandatory, this would be it without a doubt! Even without full end-to-end, protecting the first hop is important and = a big step forward. /O >=20 > Joe >=20 >=20 > ---------- > Joe Gruessing > Infrastructure Engineering, Principal > Group Leader, L114 >=20 > Office: (703) 983-2075 > Mobile: (703) 347-2402 >=20 >=20 > -----Original Message----- > From: Paul Kyzivat > Sent: Thursday, August 26, 2021 5:40 PM > To: Roger Slusser > Cc: rum@ietf.org > Subject: [Rum] IPv6 and encryption >=20 > Roger, >=20 > On 8/26/21 3:30 PM, Roger Slusser wrote: >=20 >> Most providers already support encryption and IPV6 on a limited = scope, >> not necessarily the way it is defined in RUM spec. Mandating >> compliance using MUST requires providers to discard sometimes huge >> amounts of development to change over to what RUM is specifying. The >> push back is not about doing these things it is about the loss of >> time, effort and money to do them in the way RUM mandates with MUSTs. >=20 > Do you think there is something else we could write in this spec that = covers encryption and IPv6 in a way that is less burdensome for = providers while remaining interoperable with all providers? >=20 > If so, can you please spell it out? >=20 > Thanks, > Paul >=20 >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_B45323DD-795B-4217-8FC7-A02C743303F4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: http://edvina.net iQGzBAEBCAAdFiEEAsV9zKckq/QkNi1DMKLWpfU/lUYFAmEogZoACgkQMKLWpfU/ lUY1rQv/dTtQzjS0b07++bDXOC+rBSBG28tY/V+og8cZ7+m7IdvVdCC6b4S/1kyP 4FjKBBteEGQa58LCrg6AXRGtv2OOOyaDTn13+VGyBMn25C4p+dFcmIEUZx/Rg/+a 2R1t6kSj6yhu9glfTioSngzxPVS83mcsXzLeXPfDzS2htZDbb3wE5EHgnV/FdTrJ cHJ+Eh7dz3k9EK8qhLaDaWPawBXFuxxDsxM6kpwn84Tyd98bWfvLQ1AmADh0Iwq8 hU/V2A5hEDDbT+MSD/K7MdE4BxwHHWnCjmZwIOZgcNN3CJ5tMTgd6K2grZKKDfVb sPtiIJr85Mrt8KxxMFPT9GT1JcyxDJFhywQbihKOjiYCv7/DB2PuuCqlol7EW7er RW3qAntAewH4Et/NlDWqNLjLI+eVqI3ovdVOyz4IvWoOAG5Aq6kkUmtNT019Ntvq dQrJeVtioWpwz0Jn+6Dbzt3o81K7+paUEdgzJ7t5a5jhYW2bmxdABb/bMb00rBj6 SnVHWde7 =e4F1 -----END PGP SIGNATURE----- --Apple-Mail=_B45323DD-795B-4217-8FC7-A02C743303F4-- From nobody Fri Aug 27 02:37:58 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BCC93A28CC for ; Fri, 27 Aug 2021 02:37:56 -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, 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=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQthUqJdgxYy for ; Fri, 27 Aug 2021 02:37:50 -0700 (PDT) Received: from stmail.purple.us (stmail.purple.us [54.177.79.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2183A28C6 for ; Fri, 27 Aug 2021 02:37:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail.purple.us (Postfix) with ESMTP id A57E71A1DC3; Fri, 27 Aug 2021 04:43:32 -0500 (CDT) Authentication-Results: stmail.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=aY19QOMY header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2171.outbound.protection.outlook.com [104.47.55.171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail.purple.us (Postfix) with ESMTPS id 323A11A1DC6; Fri, 27 Aug 2021 04:43:32 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N1rfgBF7KK4aTM8H5T0tZ+Pzak6PKHDT1ylJbqGvHq5CH+/D+XxSQW7mjqeksJNVDyxdb9MZsdozdURAsozyUzBX9l2ECZbTnyMDjxM3/wNuPgoKDCVL3eVkpiIZocukrDygP/pbwRLrXlXee9kqslVbmDvqIWxye/f+IEPubqYSPsN+CRbNNpIpXRSHzJj1lB+JzXbXbbLwc91i+1P5HXOuYxJDi4bH4C0pomxgYhCqMCfhPkm9o6nAoE7qNiLAq9wQKOT1lY8ENf7OV+wa8/n5tAxN/G3owVI8rWWOjeQcOY892WoZ65LbCUz6WfjJpZ5bOPlsK2SPkDWBL8XHYw== 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=YfuNIYBXbD7HvHG3JwPUYJ3HOU4uaAiKyfSDiJ+oZCs=; b=Ch/gc5xxgCAt13bFROz+eqEigT95UDsO+l/S+0KS9Y9uYctfi2INdmIN2FwyojbqAdf0xiCO5cA/ZCzPFPqrOLZKUBgZhqvgF2lAuNpWciS+PebYArz4SKkpOakHwOvbHCll1GivUp1oW8tNc0iI68KYDu+BSxf6WzlP67SEw7BCvTmBWJMVmauHS1nH265n/RTYFJ3VnfJQ3VWaG7O8cvXnT/8m5Vfk6RbcNqil/MbFDCrBKYD/FgvchUHDrNUAfI2uXkanJP5B5sywtV+obcwBm5//dEhTYJCisF4+GN1/sDw+i+hxO9HaASicT448Kh4IrD/lZa3yWRlml7ug5g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YfuNIYBXbD7HvHG3JwPUYJ3HOU4uaAiKyfSDiJ+oZCs=; b=aY19QOMY3I7bKCU/30FSTI2nL8Tla7c4HNcOCNxWmbELTCAtH5Y6Jmn6hZ1UqPN1UttyvnREl3iPNCgPC6ACoznFaNuagFlAVeA/uQEXNZXp+j1CLkt7Lp+XsHCocffL5uD6HK9LmvJvE4Ab+rR5vX3j629dnjYnWrhk459skUU= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM5PR19MB1130.namprd19.prod.outlook.com (2603:10b6:3:2f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Fri, 27 Aug 2021 09:37:41 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4436.027; Fri, 27 Aug 2021 09:37:40 +0000 From: Ed Sayers To: Brian Rosen CC: Paul Kyzivat , Eugene Christensen , "rum@ietf.org" , Isaac Roach , Alexander Ospina Thread-Topic: [Rum] VRS Provider issues - MWI Thread-Index: AQHXmpHMjrK4SgewrUasBQeso54V1quF76zAgAAcIICAAP+CEA== Date: Fri, 27 Aug 2021 09:37:40 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> In-Reply-To: <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa904907-0492-488d-5b83-08d9693e5083 x-ms-traffictypediagnostic: DM5PR19MB1130: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P/0zxORPBoozASiDrMXYVNXSrToC3XyponAODeaG731N/OiUfSe3zrKwfKXihmR/cfnxNxOBoYTIa+pRYeaMSl+dVmb3QUxmYaJ5P/IgTpQvpZctlQC1f8YUTpE93cy6BUTUHhBbcyvu7iTLx6/zgETaFMTzM/3ZRe4ggXZdk6nqGYuTQh+45sr1cqrsMMNCu9Vner8bNqA8tiLiHgkOUCt9xHfTp2Fv4VlgtUoCUzLG2VtK8Vlo/KvKMp1QtDoLiOb2YKZ2hqq05EouNfPg6qlLbTV+dzopgbJbi6hnlOGwRv/49OTlodRM3A0yuWWJa4madkDRIxUPjlASxkhpAX4INuyZycGgE3T/V3FHEEXsk63ngD596q60RN+pnJgVwlhcmrbjp1FjWRSa81W3v5EM60FKV6Dv9b9ej5mfh39pVUtL06nUokm2nsEVNQiSizaamrn6z2ntT1MyqEdEnwW6JMFb+6a5lSlLhvAuj6YB5L5sxJEUI5rJYCeYUjxStIpS8uXEe52SIWP3Khz9CkedO3OGaZcI2h6OhgDMY8E8N7lixS1jo5sbg+oLKTeqgqn/OkPrUS8fd5Rl8LC5/rNkMCA2V/yrwTsP6l+OY6gIZTqX5jCyQk6pRom+5HfvgS+SKHuHWSV34jXmYrLUAMAoKUJ++8Z+tqA7BXiaaXIneZsky7zWFbiYn5QLV8Jt18jSQLaZbEfb4Oj3QwuLzRd2NdrTHAB+jv05ZV/GRFeuqAOGngToUWJrN5m0cfclzfmPklTA+eKECCl6f/ktgbOH0SzAfOepgMPI8jMjiaaXSWzRg9vFoVEXWzRorZcS x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(136003)(396003)(376002)(366004)(346002)(86362001)(2906002)(26005)(30864003)(53546011)(38070700005)(44832011)(38100700002)(122000001)(33656002)(6506007)(186003)(76116006)(5660300002)(966005)(66446008)(52536014)(478600001)(66556008)(66476007)(66946007)(18074004)(64756008)(7696005)(4326008)(8936002)(6916009)(9686003)(55016002)(71200400001)(83380400001)(8676002)(316002)(54906003)(55236004)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cjZvUEUyOGN3MG5Nei9HMjQrekdsaXR1b3dBTnNERUVSUVkrdXloY0lBWGpT?= =?utf-8?B?SCs4dE9CUXd0WW5EenBVU0l5U3RWNXE0eCtNeEpzVUpRMlRCbDU3c3NxWlVW?= =?utf-8?B?bXUrRVRKVWdSNFA3cGlrb1JnVmVGNXBKZnFyejJLRVhjSWtlNjA2T0l1QVha?= =?utf-8?B?WEJKcVh6Q1pQeXFUWmpyTVU1TWJCUzFvT0FoNkFNRFNmaTQxY0Y3cm80SVZj?= =?utf-8?B?cVAzRjdwRjVSV0kzanNPYmZMU2dwemdabkFMeHRkSEZRNWRxekJHNjlVRmk0?= =?utf-8?B?RW1Tdm13aW5sWUo1THozamlzMWx6SzN3bmdub21pMmo0Vi9qdHJsVUtDeXhu?= =?utf-8?B?WlJuaGM0VTdySEM5QmQ3cWRENkttZ2NNTkxzU1BEa1RHL3Z6a0drcEthTnZu?= =?utf-8?B?WDh5ek9zUDdRcUVRQU9uVnM3bWN5Yi9USEdmRHZHS0RjUEZQWUhpaVBPK2JG?= =?utf-8?B?dWpYZlRZaC93ZWVIcEpRY1FEWFNaVXM5TFl4OWIvTktPTWdPbUZzYVNIYTdz?= =?utf-8?B?MjZIc0l6K09lVHJQVGU5WjQ1d0RhcmxjU01NNGQ0ang3ZGhmditiQUN3L2c0?= =?utf-8?B?dGMyZTBqcjRRNDVEQ1FiS25Nb1Zpb2M4MDNDYlUvS1RKVHpDYmg3bU9kSU9W?= =?utf-8?B?REcxOWtOMUFoa3g2WEJZREZmOFNZdEVRWXluTmp1T1RlK0t6Z3hFdGxrZXlM?= =?utf-8?B?Y3hieVVFMi9mVHRhbmpZeFJOb0ZjL2poWGhGcFhoMEJiNHlPODZ5TGpkVWFz?= =?utf-8?B?Zko4V3VnYWN3bFgwMjdaM2RHMzN6VjhITlZnU1ErakZwbHdROTRxc1hmSDJL?= =?utf-8?B?ejNENm5tam56VzZrVUNaaTg5R1ErV0t3cUI4djlLNWlNbVN4RnJUUk5ROGtl?= =?utf-8?B?SGxYcXFRUVArSTVqeDhrcGdPSFp1Q21jR0VzVG1CMEp2YmpGSm95bFZQb0FN?= =?utf-8?B?bjU0VFVYeXZxUjlxeVNtNS85VmJNSGxtclYydWMxbkVUT1gwb3lCNnFXU2My?= =?utf-8?B?NFA0YXVsc1QwdmJCTHFIclNJYTRNZVorWEZNa2I3dG9XUU5wc09Mc0tsOGN4?= =?utf-8?B?NFJYa0R5b0V2SUFqYW5XV1RDNTl5cUpGb05hYVRLSDJrcDVlbXBwMHdjbXcx?= =?utf-8?B?RUFMSFF1MllZWkoyZ2loaEpscUFVeHlOemdGd3JqeGVnSzNzTkZ1WVhJT205?= =?utf-8?B?cjdVeGtDSVZDVFR6RFdGR1VaYmE5bSs3d0gyS0s5c0RYMU5lTll1Q2tlSUpV?= =?utf-8?B?cjVqcEk2Wmk3M2t6cnh4cDN5VEtKRDZDM1dVWXk5S2d6dUZ6bndIR2ZFUXMw?= =?utf-8?B?cis0aFBranlFWlpkd2J1TXlZSldhQ21QWHhwd3lxZzBXTXQzNm9uQURuTEE1?= =?utf-8?B?RHVjSTRqalNmNUNpOW9yQkgxcEhPNDFJNzd2TWp3N29jY0hocGVYcldxMXF4?= =?utf-8?B?TWhOcXN0d3c3R3FxTGxEYzIzbWY2YThjbGw4KzRxUXU1aE95MmRUTjR6R1NR?= =?utf-8?B?Qjl1R3BjajFOSmFaTlBsdGFqQWVqa1c2ODhtREp4L1RRRm53TUwxaWhPcWlz?= =?utf-8?B?d2hVU1g4MEFtWlVJdkRSa2pGdUdIbFVmU29BU3A1ODRXMURwdmlwMUtSc1p5?= =?utf-8?B?eStBK01EVy9pSXBnbmtxVzV4cnlqU3RzbzlYU01IalJ0Y2VxRnRlbTE4K2Rp?= =?utf-8?B?NTRDWUtvSnRaZlg0bVhpL0ViTkNaTkUxczVyVmJRWDlUY0JJUUYxalVBcEFO?= =?utf-8?Q?rQtkhtk5eC9hD95ow38a9DVO2VFwmEoI3i45WNI?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa904907-0492-488d-5b83-08d9693e5083 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2021 09:37:40.7478 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: wGRoHdAIO6g3Dz1O6XLDAihbeCcBXXYQOb+O5roCRvNLAP3CQImnYsuvUGlR0okdaufmwsEpIceHp31O5x+1PQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR19MB1130 Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 09:37:57 -0000 SGkgQnJpYW4sDQoNClRvIGNsYXJpZnkgc29tZSBvZiB5b3VyIHBvaW50cyBiZWxvdy4uDQoNCldl IHdlcmUgdXNpbmcgU0lQIGZvciBWUlMgYXMgbG9uZyBhcyAxNSB5ZWFycyBhZ28gLSBqdXN0IG5v dCBpbi1iZXR3ZWVuIFVTIFZSUyBQcm92aWRlcnMgKEl0IHdhcyBzdGlsbCBJVFUtVCBILjMyMywg YXMgd2FzIG1hbmRhdGVkIGJ5IHRoZSBGQ0MgYXQgdGhlIHRpbWUpLg0KDQpXZSBkaWQgYWxzbyBp bXBsZW1lbnQgYW5kIHN1cHBvcnQgdGhlIE1XSSBSRkMgaW4gYXJvdW5kIDIwMDYuIEJ1dCwgaW4g dGhlIGZvbGxvd2luZyB5ZWFycyBhcyBTbWFydHBob25lcywgVGFibGV0cywgbGFwdG9wcyBhbmQg V2lyZWxlc3MgY29tbXVuaWNhdGlvbiBtb3ZlZCBvbiBhbmQgc28gZGlkIFZpZGVvbWFpbCBub3Rp ZmljYXRpb24gYW5kIHJldHJpZXZhbC4NCg0KVG8gYW5zd2VyIFBhdWwncyBxdWVzdGlvbiBhdCB0 aGlzIHBvaW50OyBQcm92aWRlcnMgaGF2ZSBBY2NvdW50IFBvcnRhbHMgd2hlcmUgdXNlcnMgY2Fu IG1hbmFnZSB0aGVpciBhY2NvdW50cywgY2FsbCBoaXN0b3J5LCBjb250YWN0cyBhbmQgdmlldyB0 aGVpciBtZXNzYWdlcy4NCg0KSSBoYWQgdGhvdWdodCBJIHdhcyBjbGVhciwgd2UgYXJlIG5vdCBw cm9wb3NpbmcgdGhlIGluY2x1c2lvbiBvZiBhbnl0aGluZyBwcm9wcmlldGFyeSBpbnRvIHRoaXMg UkZDLiAoQWx0aG91Z2ggaWYgc3VjaCBhIG1lY2hhbmlzbSB3ZXJlIGRlZmluZWQgaW4gYW4gUkZD LCBzdXJlbHkgaXQgc3RvcHMgYmVpbmcgcHJvcHJpZXRhcnk/KS4NCg0KQXMgSSBhbHJlYWR5IGhp Z2hsaWdodGVkIFJGQy0zODQyIGRvZXMgcHJvdmlkZSBhIG1lY2hhbmlzbSBmb3IgYWRkaXRpb25h bCBoZWFkZXJzIHRvIGJlIGluY2x1ZGVkIGluIHRoZSBOT1RJRlkgYm9keSB0aGF0IGFyZSBzcGVj aWZpYyB0byBlYWNoIG1lc3NhZ2UsIGluIHNlY3Rpb24gMy41LiBFeGFtcGxlcyBiZWluZyAnRnJv bScsICdUbycgaGVhZGVycy4NCkhvd2V2ZXIsIHRoZSBsaW1pdGF0aW9ucyBvbiB1c2UgdGhhdCBJ IHF1b3RlZCBtZWFucyB0aGF0IHRoZSBub3RpZmljYXRpb25zIGNhbm5vdCBzb2xlbHkgYmUgdXNl ZCB0byBsaXN0IG1lc3NhZ2VzIHdpdGggdGh1bWJuYWlscyBhbmQgc3RyZWFtaW5nIFVSTHMgYW5k IHJlc3VsdHMgaW4gdGhlIGluZmVyaW9yIGRpYWwtdXAgZXhwZXJpZW5jZSB0aGF0IHdlIGhhdmUg YWxsIGxlZnQgYmVoaW5kLg0KDQpXaGlsc3QgaXQgbWlnaHQgYmUgcG9zc2libGUgdG8gaW5jbHVk ZSBhbiB1cGRhdGUgdG8gdGhlIE1XSSBSRkMsIEknZCBhcmd1ZSB0aGF0IHRoZSBleGlzdGluZyBt ZWNoYW5pc21zIGFscmVhZHkgcHJvdmlkZWQgYXJlIHN1ZmZpY2llbnQuIChFLmcuIGVtYWlsIHdp dGggYXR0YWNoZWQgbWVzc2FnZSBvciBTTVMpLg0KRm9yIGEgUHJvdmlkZXIgdGhhdCBjYW4gc3Vw cGx5IHRoZXNlIGFsdGVybmF0aXZlIHN0YW5kYXJkIG1lY2hhbmlzbXMsIGl0IHNlZW1zIHRoYXQg TVdJIHNob3VsZCBiZSBvcHRpb25hbCBmb3IgdGhlIHByb3ZpZGVyLg0KDQoNCkNoZWVycywNCg0K DQpFZCBTYXllcnMNCkVuZHBvaW50IFNESyBUZWFtIExlYWQNClB1cnBsZSwgYSBEaXZpc2lvbiBv ZiBaUCBCZXR0ZXIgVG9nZXRoZXIsIExMQw0KcHVycGxldnJzLmNvbQ0KDQpUaGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3Ig dGhlIHBlcnNvbmFsIGFuZCBjb25maWRlbnRpYWwgdXNlIG9mIHRoZSByZWNpcGllbnQocykgbmFt ZWQgYWJvdmUuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwsIGFuZCBkZWxldGUgdGhl IG9yaWdpbmFsIG1lc3NhZ2UuDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpG cm9tOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+IA0KU2VudDogMjYgQXVndXN0IDIw MjEgMTg6MzMNClRvOiBFZCBTYXllcnMgPGVkLnNheWVyc0BwdXJwbGUudXM+DQpDYzogUGF1bCBL eXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJp c3RlbnNlbkBzb3JlbnNvbi5jb20+OyBydW1AaWV0Zi5vcmc7IElzYWFjIFJvYWNoIDxJUm9hY2hA c29yZW5zb24uY29tPjsgQWxleGFuZGVyIE9zcGluYSA8YW9zcGluYUBhc2xzZXJ2aWNlcy5jb20+ DQpTdWJqZWN0OiBSZTogW1J1bV0gVlJTIFByb3ZpZGVyIGlzc3VlcyAtIE1XSQ0KDQpJIHRoaW5r IHRoaXMgaXMgbm90IGNvcnJlY3QgaW4gbW9zdCByZXNwZWN0cy4NCg0KVGhpcyBpcyBhIHN0YW5k YXJkIHRoYXQgYWxsb3dzIGEgY2xpZW50IGNvbmZvcm1pbmcgdG8gdGhlIHN0YW5kYXJkIHRvIGNv bm5lY3QgdG8gYSBwcm92aWRlciBjb25mb3JtaW5nIHRvIHRoZSBzdGFuZGFyZCAoYW5kLCBmb3Ig YSBwb2ludCB0byBwb2ludCBjYWxsLCBhbm90aGVyIGNsaWVudCBjb25mb3JtaW5nIHRvIHRoZSBz dGFuZGFyZC4gIEFueXRoaW5nIHRoYXQgaXMgcHJvcHJpZXRhcnkgd291bGQgbm90IGJlIGFjY2Vw dGFibGUsIHJlZ2FyZGxlc3Mgb2YgaG93IGl0IHdvcmtzLiAgSXQgaGFzIHRvIGJlIHN0YW5kYXJk aXplZCwgb3IgYSBjbGllbnQgY291bGRu4oCZdCBiZSBjcmVhdGVkIHRoYXQgd29ya2VkIHdpdGgg YW55IGNvbmZvcm1pbmcgcHJvdmlkZXIuICANCg0KVGhlIGRvYyBvbmx5IHJlcXVpcmVzIE1XSSwg d2hpY2ggaXMgdGhlIG5vdGlmaWNhdGlvbiBvZiBtZXNzYWdlcyB3YWl0aW5nLiAgSXQgZG9lcyBu b3QgYXNzdW1lIGFueSBzcGVjaWZpYyBtZWNoYW5pc20gdG8gcmV0cmlldmUgbWVzc2FnZXMuICBP bmx5IHRoZSBub3RpZmljYXRpb24gdG8gdGhlIHVzZXIgdGhhdCB0aGVyZSBhcmUgbWVzc2FnZXMg d2FpdGluZyB0byBiZSByZXRyaWV2ZWQuICBTbyBkaXNjdXNzaW9uIG9mIGhvdyBtZXNzYWdlcyBh cmUgc3RyZWFtZWQgaXMgb3V0IG9mIHNjb3BlLg0KDQpUaGUgZmFjdCB0aGF0IGVhY2ggcHJvdmlk ZXIgc29sdmVkIFNJUCBQVVNIIGlzIGlycmVsZXZhbnQ6IHRoZXkgZWFjaCBzb2x2ZWQgaXQgaW4g YSBkaWZmZXJlbnQgd2F5LiAgVGhlaXIgcHJvcHJpZXRhcnkgY2xpZW50cyBjYW4gdXNlIHRoYXQs IGJ1dCBhIGdlbmVyaWMgY2xpZW50IGNvdWxkbuKAmXQuICANCg0KUkZDMzg0MiBwcmVkYXRlcyBh bnkgU0lQIGNsaWVudCBjcmVhdGVkIGJ5IFZSUyBwcm92aWRlcnMgYnkgbWFueSB5ZWFycy4gIFRo ZXkgY2hvc2Ugbm90IHRvIHVzZSB0aGUgc3RhbmRhcmRzIG1lY2hhbmlzbSAgdGhhdCBleGlzdGVk IHllYXJzIGJlZm9yZSB0aGVpciBpbXBsZW1lbnRhdGlvbiBpbiBmYXZvciBvZiBwcm9wcmlldGFy eSBzeXN0ZW1zLiAgVGhlcmUgaXMgbm8gZGVmaWNpZW5jeSBvZiBSRkNzLiAgWW91IGNhbiBpbWFn aW5lIGltcHJvdmVtZW50cyBvbiB3aGF0IDM4NDIgZG9lcy4gIEZvciBleGFtcGxlLCB5b3UgY291 bGQgd2FudCB0aGUgbnVtYmVyIG9mIG91dHN0YW5kaW5nIG1lc3NhZ2VzLiAgQnV0IHRoZSBmdW5k YW1lbnRhbCwgZXZlcnlvbmUgbmVlZHMgaXQsIGluZGljYXRpb24gdGhhdCB0aGVyZSBpcyBhdCBs ZWFzdCBvbmUgbWVzc2FnZSBhdmFpbGFibGUgaXMgdW5pdmVyc2FsLCBhbmQgbmVlZHMgYSBzb2x1 dGlvbiBzcGVjaWZpZWQgb25lIHdheSBvciBhbm90aGVyIGluIG91ciBkb2N1bWVudC4gIEnigJlt IG5vdCBhd2FyZSBvZiBhbnkgb3RoZXIgc3RhbmRhcmQgZm9yIE1XSS4gIE5vIG9uZSBwcm9wb3Nl ZCBhbiBhbHRlcm5hdGl2ZSB0byAzODQyLCB5b3UgaGF2ZSBvbmx5IHJlcXVlc3RlZCB0aGF0IHRo aXMgYmUgcHJvcHJpZXRhcnksIHdoaWNoIGlzIGNvbnRyYXJ5IHRvIHRoZSBiYXNpYyBnb2FscyBv ZiB0aGUgc3BlYy4NCg0KQnJpYW4NCg0KDQo+IE9uIEF1ZyAyNiwgMjAyMSwgYXQgMToxNSBQTSwg RWQgU2F5ZXJzIDxlZC5zYXllcnNAcHVycGxlLnVzPiB3cm90ZToNCj4gDQo+IEhpIFBhdWwsDQo+ IA0KPiBUaGUgaXNzdWUgb2YgTVdJIGlzIGZhciBtb3JlIHRoZSBqdXN0IG1lY2hhbmlzbSBvZiBu b3RpZnlpbmcgdGhlIHVzZXIuIFdoZXRoZXIgdGhhdCBiZSBwdXNoLCBlbWFpbCwgU01TIG9yIGFu eXRoaW5nIGVsc2UgUHJvdmlkZXIgY2FuIGFscmVhZHkgc3VwcG9ydC4NCj4gSW4gYWRkaXRpb24s IFZSUyBQcm92aWRlcnMgZWFjaCBzb2x2ZWQgdGhlIFNJUCBQVVNIIHByb2JsZW0gMTArIHllYXJz IGFnbyAtIGxvbmcgYmVmb3JlIHRoZSBSRkMgIHdhcyBjcmVhdGVkIC0gRm9sbG93aW5nIHRoZSBu ZWVkcyBvZiBvdXIgY3VzdG9tZXJzIGFuZCBiZWNhdXNlIFJGQ3MgbGlrZSBSRkM4NTk5IGRpZG4n dCBleGlzdCwgb3IgYmVjYXVzZSBSRkMtMzQ4MiB3YXMgaW5zdWZmaWNpZW50IGFuZCB0aGVyZSB3 ZXJlIG5vIG90aGVyIGFkZXF1YXRlIGFsdGVybmF0aXZlcy4NCj4gDQo+IFByb3ZpZGVycyBhbHNv IGN1cnJlbnRseSB1c2UgdGhlaXIgb3duIFJFU1RmdWwgQVBJcyB0byBzdHJlYW0gYW5kL29yIGRv d25sb2FkIFZpZGVvIG1lc3NhZ2VzIHRvIHRoZSBjbGllbnQgZm9yIHBsYXliYWNrLg0KPiBUaGlz IGNhbm5vdCBiZSBzdXBwb3J0ZWQgYnkgUkZDLTM0ODIuIEV2ZW4gaWYgaXQgd2VyZSBwb3NzaWJs ZSB1c2luZyB0aGUgUkZDLTI4MjIgbWVzc2FnZSBoZWFkZXJzLCBzZWN0aW9uIDMuNSBzdGF0ZXMg Ik1lc3NhZ2UgaGVhZGVycyBNVVNUIE5PVCBiZSBpbmNsdWRlZCBpbiBhbiBpbml0aWFsIE5PVElG WSwgYXMgbmV3IG1lc3NhZ2VzIGNvdWxkIGJlIGVzc2VudGlhbGx5IHVuYm91bmRlZCBpbiBzaXpl Ii4gVGhpcyBtZWFucyB0aGF0IE1XSSBjYW5ub3QgcHJvdmlkZSBzdHJlYW1pbmcgVVJJcyBmb3Ig YW55IG9sZCBvciBpbml0aWFsIG5ldyBtZXNzYWdlcywgYW5kIGxlYXZlcyBhIGhpc3RvcmljYWwg J2RpYWwtdXAnIG1lY2hhbmlzbSBhcyB0aGUgb25seSBjb21wbGV0ZSBvcHRpb24gd2hlbiB1c2lu ZyB0aGlzIFJGQy4NCj4gDQo+IFByb3ZpZGVycyB3b3VsZCB0aHVzIG5lZWQgdG8gZ28gYW5kIHJl LWltcGxlbWVudCB0aGF0ICJvbGQgdGVjaCIgdGhhdCB3YXMgdGhyb3duIGF3YXkgeWVhcnMgYWdv IGFuZCBwcm92aWRlcyBhIG11Y2ggcG9vcmVyIHVzZXIgZXhwZXJpZW5jZTsgQSBjYWxsIHRvIGEg VmlkZW8gSVZSLCB0byBiZSBuYXZpZ2F0ZWQgYnkgRFRNRiB0b25lcy4gSWYgbm90aGluZyBlbHNl LCB0aGlzIHJlcXVpcmVzIGEgY3VzdG9tZXIgdG8gYmUgb25saW5lIGV2ZXJ5IHNpbmdsZSB0aW1l IHRoZXkgd2FudCB0byB2aWV3IGEgbWVzc2FnZSAoQW5kIHBvdGVudGlhbGx5IGluY3VyIGRhdGEg Y2hhcmdlcyBldmVyeSB0aW1lKS4gV2hlcmVhcyBhbnkgc3RyZWFtZWQgbWVzc2FnZSBjb3VsZCBi ZSBjYWNoZWQgYW5kIHN0aWxsIGJlIHZpZXdlZCB3aGVuIG9mZmxpbmUuDQo+IA0KPiBXZSBjb21w bGV0ZWx5IHVuZGVyc3RhbmQgdGhhdCB0aGVyZSBpcyBubyBSRkMgdGhhdCBjYW4gY3VycmVudGx5 IHN1cHBvcnQgdGhlIHdheSB3ZSBwcm92aWRlciB2aWRlbyBtYWlsIG5vdGlmaWNhdGlvbnMgYW5k IG1lc3NhZ2VzLiBXZSBrbmV3IHRoYXQgYSBsb25nIHRpbWUgYWdvLg0KPiANCj4gSG93ZXZlciwg aXQgbmVlZHMgdG8gYmUgbWFkZSBjbGVhciB0aGF0IHRoaXMgaXMgYSBkZWZpY2llbmN5IG9mIHRo ZSBjdXJyZW50bHkgYXZhaWxhYmxlIFJGQ3MsIG5vdCBvbmUgdGhhdCBWUlMgUHJvdmlkZXJzIGFy ZSBjdXJyZW50bHkgY29uc3RyYWluZWQgYnkuDQo+IEhvd2V2ZXIsIHRoZSBjcmVhdGlvbiBvZiB0 aGUgUlVNIHNwZWNpZmljYXRpb24gd2lsbCBjb25zdHJhaW4gdGhlIHdheSB0aGF0IFByb3ZpZGVy cyBjYW4gcHJvdmlkZSBmZWF0dXJlcyBzdWNoIGFzIHRoaXMsIHN0aWZsZSBpbm5vdmF0aW9uLCBh bmQgaW4gY2FzZXMgc3VjaCBhcyB0aGlzIGNlcnRhaW5seSBiZSBhIGxpbWl0aW5nIGFuZCByZXRy b2dyYWRlIHN0ZXAuDQo+IA0KPiANCj4gTWFueSB0aGFua3MsDQo+IA0KPiANCj4gRWQgU2F5ZXJz DQo+IEVuZHBvaW50IFNESyBUZWFtIExlYWQNCj4gUHVycGxlLCBhIERpdmlzaW9uIG9mIFpQIEJl dHRlciBUb2dldGhlciwgTExDIHB1cnBsZXZycy5jb20NCj4gDQo+IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUg cGVyc29uYWwgYW5kIGNvbmZpZGVudGlhbCB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKSBuYW1lZCBh Ym92ZS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCwgYW5kIGRlbGV0ZSB0aGUgb3Jp Z2luYWwgbWVzc2FnZS4NCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IFJ1bSA8cnVtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBQYXVs IEt5eml2YXQNCj4gU2VudDogMjYgQXVndXN0IDIwMjEgMTY6NDgNCj4gVG86IEV1Z2VuZSBDaHJp c3RlbnNlbiA8ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbT47IHJ1bUBpZXRmLm9yZzsgDQo+IEJy aWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCj4gQ2M6IElzYWFjIFJvYWNoIDxJUm9hY2hA c29yZW5zb24uY29tPjsgQWxleGFuZGVyIE9zcGluYSANCj4gPGFvc3BpbmFAYXNsc2VydmljZXMu Y29tPg0KPiBTdWJqZWN0OiBbUnVtXSBWUlMgUHJvdmlkZXIgaXNzdWVzIC0gTVdJDQo+IA0KPiBJ IHdhbnQgdG8gc3BsaXQgb2ZmIE1XSSBhcyBkaWZmZXJlbnQgZnJvbSB0aGUgb3RoZXIgaXNzdWVz IHlvdSBoYXZlIA0KPiByYWlzZWQuIElmIEkgdW5kZXJzdGFuZCwgeW91ciBwb2ludCBpcyB0aGF0 IGVhY2ggcHJvdmlkZXIgaGFzIGEgDQo+IHByb3ByaWV0YXJ5IHdheSBvZiBpbmRpY2F0aW5nIHZp ZGVvIG1haWwgaXMgd2FpdGluZyBhbmQgcmV0cmlldmluZyBpdCwgDQo+IHNvIHRoZXJlIGlzIG5v IG5lZWQgdG8gZG8gc29tZXRoaW5nIGRpZmZlcmVudC4gKFBsZWFzZSBjb3JyZWN0IG1lIGlmIEkg DQo+IGhhdmUgZ290dGVuIHRoaXMgd3JvbmcuKQ0KPiANCj4gVGhlIHByb2JsZW0gd2l0aCB0aGlz IGlzIHRoYXQgaXQgbWVhbnMgZm9yIGEgUlVFIHRvIGJlIGFibGUgdG8gYWNjZXNzIHZpZGVvIG1h aWwgaXQgbmVlZHMgdG8gc3VwcG9ydCB0aGUgcHJvcHJpZXRhcnkgbWVjaGFuaXNtIG9mIGVhY2gg cHJvdmlkZXIgaXQgYWltcyB0byB3b3JrIHdpdGguIEJ1dCBpbnRlcm9wZXJhYmlsaXR5IG9mIHRo ZSBSVUUgd2l0aCBtdWx0aXBsZSBwcm92aWRlcnMgaXMgYW4gZXhwbGljaXQgZ29hbCBvZiB0aGlz IHdvcmsgZ3JvdXAuIFNvIHdlIG5lZWQgYSBtZWNoYW5pc20gdGhhdCB0aGUgUlVFIGNhbiBpbXBs ZW1lbnQgdGhhdCB3aWxsIHdvcmsgd2l0aCBhbnkgcHJvdmlkZXIuDQo+IA0KPiBJbiBwcmluY2lw bGUgdGhpcyBtZWNoYW5pc20gbmVlZCBub3QgdXNlIHRoZSBNV0kgbWVjaGFuaXNtLCBidXQgY29t aW5nIHVwIHdpdGggc29tZSBvdGhlciwgcHJlc3VtYWJseSBwdXJwb3NlIGJ1aWx0LCBtZWNoYW5p c20gd2lsbCBiZSBhIGhhcmQgc2VsbC4NCj4gDQo+IElNTyBwcm9wb3NhbHMgdGhhdCBmYWlsIHRv IGFkZHJlc3MgdGhpcyBuZWVkIGZvciBpbnRlcm9wZXJhYmlsaXR5IGFyZSANCj4gb3V0IG9mIHNj b3BlLiAoVG8gZ28gdGhlcmUgd291bGQgcmVxdWlyZSBhIGNoYW5nZSB0byB0aGUgY2hhcnRlci4p DQo+IA0KPiBTbywgcGxlYXNlIGZyYW1lIHZpZGVvIG1haWwgYW5kIE1XSSBpc3N1ZXMgd2l0aCBp bnRlcm9wZXJhYmlsaXR5IGFzIGEgcmVxdWlyZW1lbnQuDQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1 bCAoV2l0aCBteSBSVU0gV0cgQ2hhaXIgaGF0IE9OKQ0KPiANCj4gDQo+IE9uIDgvMjUvMjEgMjo1 OCBQTSwgRXVnZW5lIENocmlzdGVuc2VuIHdyb3RlOg0KPj4gQnJpYW4sIFBhdWwgdGhhbmsgeW91 IGZvciBjb25zaWRlcmluZyB0aGUgY2hhbmdlcyB0aGF0IGhhdmVkIGJlZW4gYnJvdWdodCB1cCB0 byB0aGlzIHBvaW50LiAgTGVhdmluZyB0aGluZ3MgYWxvbmUgd2l0aCB0aGUgWC1DYXJkLCB0aGUg aW5jbHVzaW9uIG9mIHRoZSBpbnN0YW5jZS1pZCBmb3IgbG9jYXRpb24sIGFkZGl0aW9ucyB0byBz dXBwb3J0IG5vdGlmaWNhdGlvbiBzZXJ2aWNlcyBmb3IgbW9iaWxlLCBldGMuIGFyZSBhbGwgYXBw cmVjaWF0ZWQuDQo+PiANCj4+IEl0IGlzIG15IG9waW5pb24gdGhhdCB3ZSBzaG91bGQgbm90IGlu Y2x1ZGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgZm9sbG93aW5nIGluIHRoZSBuZXcgUlVNIGRvY3Vt ZW50LiAgSGVyZSBhcmUgdGhlIHJlYXNvbnMgdGhhdCBJIGJlbGlldmUgdGhpcyB3YXkuDQo+PiAN Cj4+IFdlYlJUQw0KPj4gDQo+PiAqIFdoaWxlIHRoZXJlIGlzIGFuIFJGQyBmb3IgV2ViUlRDLCBp dCBkb2Vzbid0IGFwcGVhciB0aGF0IGFsbCBicm93c2VycyBhcmUgZm9sbG93aW5nIGl0LiAgRm9y IGV4YW1wbGUsIFRNTUJSIGlzIHJlcXVpcmVkIGZvciBXZWJSVEMgYnV0IENocm9tZSBkb2VzIG5v dCBzaWduYWwgaXQuDQo+PiAqIFdlYlJUQyBpcyBhbiBhdWRpbyBmaXJzdCBpbXBsZW1lbnRhdGlv bi4gIEZvciBWUlMsIHZpZGVvIGlzIHRoZSBtb3N0IGltcG9ydGFudCBtZWRpYSBzdHJlYW0uICBJ dCBtZWFucyBldmVyeXRoaW5nIHRvIHRoZSBkZWFmIG9yIGhhcmQgb2YgaGVhcmluZyB1c2VyLiAg SWYgdmlkZW8gaXMgc3VmZmVyaW5nIGZpcnN0IGluIGEgbG9zc3kgbmV0d29yaywgdGhhdCBpcyBh IHByb2JsZW0gZm9yIFZSUy4NCj4+ICogU29tZSBvZiB0aGUgVlJTIHByb3ZpZGVycyBkbyBub3Qg Y3VycmVudGx5IHN1cHBvcnQgdGhlIGZvbGxvd2luZyBpdGVtcy4gIFRoaXMgY291bGQgcG9zZSBh IHNpZ25pZmljYW50IGltcGFjdCBvbiB0aGUgVlJTIHByb3ZpZGVycyB0byBnZXQgdGhpcyBpbXBs ZW1lbnRlZC4NCj4+IG8gRW5jcnlwdGlvbiAoRFRMUykNCj4+IG8gSUNFDQo+PiBvIFJUUC9SVENQ IE11eGluZw0KPj4gDQo+PiBJUHY2DQo+PiAqIEZvciB0aG9zZSBWUlMgcHJvdmlkZXJzIHdob3Nl IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIGRvIG5vdCBzdXBwb3J0IElQdjYsIHRoaXMgY2FuIGJl IGEgYmlnIGp1bXAgdG8gZ2V0IHRoZWlyIHNvbHV0aW9uIHRvIHN1cHBvcnQgYm90aCBJUHY0IGFz IHdlbGwgYXMgSVB2Ni4gIEdyYW50ZWQsIGl0IGRvZXMgbm90IHJlcXVpcmUgYmVpbmcgZHVhbCBz dGFja2VkIGJ1dCByYXRoZXIgY291bGQgYmUgdHdvIHNlcGFyYXRlIHNlcnZlcnMsIGVhY2ggc3Vw cG9ydGluZyB0aGVpciByZXNwZWN0aXZlIHZlcnNpb24gb2YgSVAuICBUaGlzIGNvdWxkIGJlIGEg YmlnIHVuZGVydGFraW5nIGp1c3QgdG8gZ2V0IElQdjYgaW50byB0aGUgbWl4Lg0KPj4gKiBBbm90 aGVyIHNvbHV0aW9uIGNvdWxkIGJlIGFuIElQdjQgdG8gSVB2NiBnYXRld2F5IGJ1dCB0aGF0IGRv ZXNuJ3Qgd29yayBmbGF3bGVzc2x5LiAgRm9yIGV4YW1wbGUsIHRoZSBnYXRld2F5IGNhbiBmb3J3 YXJkIHRoZSBJUHY2IFNJUCBtZXNzYWdlIHRvIHRoZSBwcm9wZXIgYWRkcmVzcyBvbiB0aGUgSVB2 NCBuZXR3b3JrLCBob3dldmVyLCBob3cgZG9lcyBpdCByZXNvbHZlIHRoZSBlbWJlZGRlZCBJUHY2 IGFkZHJlc3NlcyBzaWduYWxlZCBpbiB0aGUgU0RQPyAgU28sIGZvciBleGFtcGxlLCBjb25zaWRl ciB0d28gUlVFcywgb25lIGxlZ2FjeSBSVUUgdGhhdCBpcyB1c2luZyBJUHY0IGFuZCBvbmUgdGhh dCBpcyBJUHY2OyB0aGUgc2lnbmFsaW5nIGlzIHBvc3NpYmxlIGZvciBib3RoIG9uY2UgdGhlIHNl cnZlcnMgZm9yIGVhY2ggc3VwcG9ydCB0aGF0IG9yIHByb3ZpZGUgYSBJUCBnYXRld2F5IGJldHdl ZW4gdGhlIHR3by4gIEhvdyBpcyB0aGUgbWVkaWEgZ29pbmcgdG8gd29yaz8gIEVhY2ggb2YgdGhl IFJVRXMgaXMgZ29pbmcgdG8gcHJvdmlkZSBhbiBJUCBhZGRyZXNzIGluIHRoZWlyIFNEUCwgb25l IHdpbGwgYmUgSVB2NCBhbmQgdGhlIG90aGVyIElQdjYuICBIb3cgaXMgdGhpcyBnb2luZyB0byB3 b3JrIHdpdGhvdXQgaGF2aW5nIHRvIGFuY2hvciBhbGwgdGhlIG1lZGlhIHNvbWV3aGVyZT8NCj4+ ICogQXJlIHRoZXJlIGlzc3VlcyB0aGF0IHdlIG5lZWQgdG8gcmVzb2x2ZSB3aXRoIE5BVDY0IGFu ZC9vciBETlM2ND8NCj4+ICogQXMgSSB1bmRlcnN0YW5kIGl0LCBzb21lIG1vYmlsZSBkZXZpY2Vz IGFyZSBhbHJlYWR5IElQdjYgYnV0IGRvIG5vdCBmb2xsb3cgdGhlIFJGQyBmb3IgZW1iZWRkaW5n IGFuIElQdjQgYWRkcmVzcyBpbnRvIGFuIElQdjYgYWRkcmVzcy4gIFRoaXMgaXMgZ29pbmcgdG8g cmVxdWlyZSBzcGVjaWFsIGhhbmRsaW5nIHRvIGdldCB0aGlzIHRvIHdvcmsgd2l0aCBzdWNoIGRl dmljZXMgb24gdmVuZG9ycyB0aGF0IGRvIG5vdCBmb2xsb3cgdGhlIFJGQyBpbiB0aGlzIHJlZ2Fy ZC4NCj4+IA0KPj4gTWVzc2FnZSBXYWl0aW5nIEluZGljYXRvcg0KPj4gKiBTb21lLCBpZiBub3Qg YWxsLCBvZiB0aGUgY3VycmVudCBpbXBsZW1lbnRhdGlvbnMgb2YgUlVFIGJ5IFZSUyBwcm92aWRl cnMsIGFscmVhZHkgaW5jbHVkZSBtZWFucyB0byByZWNvcmQgdmlkZW8gbWVzc2FnZXMgYW5kIGFy ZSBub3QgYWxsIGNyZWF0ZWQgdGhlIHNhbWUgd2F5LiAgUHJvcHJpZXRhcnkgbWV0aG9kcyBoYXZl IGJlZW4gdXNlZC4gIFRoZSBkb2N1bWVudCBzdGF0ZXMgdGhhdCBNV0kgaXMgb3B0aW9uYWwgYnV0 IGlmIHRoZSBhYmlsaXR5IHRvIGxlYXZlIGEgbWVzc2FnZSBpcyBwcm92aWRlZCB0aGVuIE1XSSBp cyB0byBiZSBpbXBsZW1lbnRlZC4gIFNpbmNlIHRoZXJlIGFyZSBwcm9wcmlldGFyeSBzb2x1dGlv bnMsIGl0IHNlZW1zIGFwcHJvcHJpYXRlIHRvIG1lIHRoYXQgdGhpcyBzaG91bGQgYmUgY2hhbmdl ZCBzbyB0aGF0IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBhbmQgaW5kaWNhdGlvbnMgY2FuIGNvbnRp bnVlIHRvIGJlIHV0aWxpemVkLg0KPj4gDQo+PiANCj4+IEkgZG9uJ3QgYmVsaWV2ZSBJIGhhdmUg ZW51bWVyYXRlZCBhbGwgdGhlIHJlYXNvbnMgZm9yIG5vdCBpbmNsdWRpbmcgcmVxdWlyZW1lbnRz IGZvciB0aGUgYWJvdmUgYnV0IEkgYmVsaWV2ZSB0aGUgZXhhbXBsZXMgZ2l2ZW4gYXJlIHN1ZmZp Y2llbnQgdG8gY29uc2lkZXIuDQo+PiANCj4+IFJlZ2FyZHMsDQo+PiBFdWdlbmUgQ2hyaXN0ZW5z ZW4NCj4+IA0KPj4gQ09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBlLW1haWwgdHJhbnNtaXNz aW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2Vz IGF0dGFjaGVkIHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5 IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBh IHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUgaW50ZW5kZWQgcmVj aXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5 aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIGFueSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIG9yIGF0dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBQUk9ISUJJVEVE LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl IGltbWVkaWF0ZWx5IG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQgZWNocmlzdGVuc2VuQHNv cmVuc29uLmNvbSBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksIGFuZCBkZXN0 cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50cyB3aXRob3V0 IHJlYWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KPj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIFBhdWwgS3l6aXZhdA0KPj4gU2VudDogVGh1cnNkYXksIEF1Z3VzdCAxOSwgMjAy MSAxMDowNCBBTQ0KPj4gVG86IHJ1bUBpZXRmLm9yZw0KPj4gQ2M6IEFsZXhhbmRlciBPc3BpbmEg PGFvc3BpbmFAYXNsc2VydmljZXMuY29tPjsgSXNhYWMgUm9hY2ggDQo+PiA8SVJvYWNoQHNvcmVu c29uLmNvbT47IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NCj4+IFN1YmplY3Q6IFtS dW1dIEFjdGlvbiBJdGVtcyBmcm9tIFJVTSBzZXNzaW9uIGF0IElFVEYgMTExDQo+PiANCj4+IFtF WFRFUk5BTF0NCj4+IA0KPj4gVGhlIG1pbnV0ZXMgZnJvbSB0aGUgUlVNIHNlc3Npb24gaW5jbHVk ZSBhIG51bWJlciBvZiBhY3Rpb24gaXRlbXMuDQo+PiBTcGVjaWZpY2FsbHksIHRoZSBmb2xsb3dp bmcgcGVvcGxlIG1hZGUgY29tbWl0bWVudHM6DQo+PiANCj4+IEJyaWFuIFJvc2VuDQo+PiBJc2Fh YyBSb2FjaA0KPj4gQWxleCBPc3BpbmENCj4+IA0KPj4gQnJpYW4gaXMgd29ya2luZyBvbiBhbiB1 cGRhdGVkIHZlcnNpb24sIGJ1dCBpdCB3b24ndCBpbmNsdWRlIHRoZSANCj4+IGNvbmNlcm5zIG9m IHRoZSBvdGhlcnMgYWJvdmUgaWYgd2UgZG9uJ3QgaGVhciBmcm9tIHlvdS4gUmF0aGVyIHRoYW4g DQo+PiB0cnkgdG8gc3VtbWFyaXplIHRob3NlIEkgcmVmZXIgeW91IGJhY2sgdG8gdGhlIG1pbnV0 ZXMuIFlvdSBjYW4gZmluZCB0aGVtIGF0Og0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvbWludXRlcy0xMTEtcnVtLw0KPj4gDQo+PiBJIHBsYW4gdG8gaXNzdWUgV0dMQyBvbiB0 aGUgZG9jdW1lbnQgc29vbi4gSSB3aWxsIHdhaXQgb25lIHdlZWsgDQo+PiAodW50aWwgQXVnIDI2 KS4gSWYgdGhlcmUgaGFzbid0IGJlZW4gYW55IGZvbGxvd3VwIGJ5IHRoZW4gSSB3aWxsIGFzayAN Cj4+IEJyaWFuIHRvIGlzc3VlIGEgdmVyc2lvbiB0aGF0IHdlIGNhbiBhZHZhbmNlIHRvIFdHTEMu DQo+PiANCj4+IAlUaGFua3MsDQo+PiAJUGF1bA0KPj4gDQo+IA0KPiAtLQ0KPiBSdW0gbWFpbGlu ZyBsaXN0DQo+IFJ1bUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3J1bQ0KDQo= From nobody Fri Aug 27 03:52:45 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF6C53A2DAA for ; Fri, 27 Aug 2021 03:52:43 -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 (1024-bit key) header.d=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvfBQ2qtjrCU for ; Fri, 27 Aug 2021 03:52:37 -0700 (PDT) Received: from stmail1.purple.us (stmail1.purple.us [54.177.253.121]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EBD53A2DA5 for ; Fri, 27 Aug 2021 03:52:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail1.purple.us (Postfix) with ESMTP id 7E456192540; Fri, 27 Aug 2021 05:52:46 -0500 (CDT) Authentication-Results: stmail1.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=5CRZ9ocd header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2174.outbound.protection.outlook.com [104.47.59.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail1.purple.us (Postfix) with ESMTPS id 170ED19253F; Fri, 27 Aug 2021 05:52:46 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XIcHNIzKfgqiS9qRzERvStJVJvLea1P/Qe3Ob7yfS5EhGPrkT826wmQdCsFCUuHeTEn3oPjIuBaF7He1ml29cahNxkjXqexo5VmMxPyCJcjJE8Etz3xIcCz3IKM2nxGWWRm8tgQGjSRUxFtP2esbOM5zvE65sc4kbfkSsC+yy8qwA+j6o0wHG/PLp4fe/9dGmdgtBiNPpumUAZGRr1su4/vTGstE3PYU0NoLigLT/iStEdHIBbSVDlwrezOiCwv2iNQ69sebQUPatLI+kw3o2w8IDRokeG36iFipkO2NHYtIs798Nxsnr/UnjAN/zx4owqDHLJ4SXievW4abX7lubg== 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=hW/cKuOgctVUNgV7VeA3A+uXsJ7rOrE/qBOop9WArhQ=; b=fqmcUm4KPD6lTB8TvkzYel67zvBu2zgm2pQi3XUc3EwIQSzBEwANncke2BHn5k4lDUG4qrrwnAexuSntbA438+YNuiqVqy0yFeqPMfIGlb5COrhXBZXBdTHpmI8/xhxNcXxHLmhcpD0/XHh8muyLUawYYFDIVdT8c2iHyKjP+5xFRkTwk0CFSHY/7+0wb4Ly0JHRw6oktVGIsCL5H9jmQETZFbG2c/WbLaoPYcxscH+nX1jFdKFpgSXlbRt4hugopBYaW2rCZeE6W4YwOml5rsD26z23Zej6IPifsK+Y4Mn2be4f1RXtYLiJ2Aq0PJKFwECD5zGlZzUK5/3In8xCIA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hW/cKuOgctVUNgV7VeA3A+uXsJ7rOrE/qBOop9WArhQ=; b=5CRZ9ocd7Q8QNTQ2p+4Z/jt/wqNh6tlKuEasD6mXeza8xde/FGvjWrD1Ketu73xGnbP3ajlp74pguiQ7T/+f93r6tEAfpkhqicFWZ4/NPHFgsJ0PZlSzdBB/PzgrfmtVCmvJ2qLoqAo+D4uioKhUCLxVdbU+m4/uV8OLcbwen2s= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM6PR19MB4197.namprd19.prod.outlook.com (2603:10b6:5:2b1::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.21; Fri, 27 Aug 2021 10:52:29 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4436.027; Fri, 27 Aug 2021 10:52:29 +0000 From: Ed Sayers To: Joe Gruessing , Brian Rosen , "Kyzivat, Paul" CC: "rum@ietf.org" Thread-Topic: [Rum] VRS Provider issues - MWI Thread-Index: AQHXmpHMjrK4SgewrUasBQeso54V1quF76zAgAAcIICAABgkgIAAAGoAgAAESQCAAACYAIAAIfoAgADSASA= Date: Fri, 27 Aug 2021 10:52:28 +0000 Message-ID: References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <40343a8a-d8f1-6924-9d47-a87276580bb9@alum.mit.edu> <9C0E0E00-0FFF-49B7-9A9A-E6F4CC2C477A@brianrosen.net> <0D136565-27AA-4FD9-B372-EEFF5532C540@brianrosen.net> <0fe6934a-fd70-ae55-3201-09c203f11684@alum.mit.edu> <7CD2F56C-BBFE-4112-8473-5529B3057FEB@brianrosen.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: mitre.org; dkim=none (message not signed) header.d=none;mitre.org; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0a681ca9-0241-440a-0cf9-08d96948c3a6 x-ms-traffictypediagnostic: DM6PR19MB4197: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Vsq28u7Ut/2rg4qK4faB6QImnW/n18cwvKH9X5VDg4bTo4SGc9jAG84y/wlmR1Y78ljYayMmwMhxQH9YC1Mf06kn43izHn6k0VObczH1H3KeoIauyiKQSpzYzTUtRLy0MB+UNMn6xu95qeJ7A439rDxoZfGo2A5+j5i/Yqaxp7H5A6QCRrnP9CZUASniNoBlwn4x6BVpTNaXOyX37TXQwpHx8ApgPyq0oRVXXPQHWoQvHfhzGcvjRWdqsMPE2oclW5l4ndDIozvT6WK1zNuThHDE3xd1iMqqeQPaYy9GibRxt1urOrzAis3HjdPMc2WI07fciHke25tBkGZrji8AyD4AostGKjqlHIWJdll/izgV49DuqHEvDd4zDIFu//HPrHe8KfW0L05otdAImSajMifejWlc24VFmN/ThVT1gMH/MVh2pY2nY/s4z7+kocG3QuiPvVLws0oSpzlRj4o2yVwgBnyaChM9+1xqqN4xPaU/CAads5wii9u3B8H7m+ngJ+VpF1QBVrLG1mYQq07Ws9kZqCZFKu49YjvKdPTilXq0562hUWaxAGnf1WDdeu6JCYaQ9LCeIik4FzwTF7Ryy0w3/xwQLpR7Jw4i6Kt1JAFjstEZlHAOKHb7t1MDhZg10znEB13auA38y7aq+e95rlhJqFLC0oxDypm9qIHUlb/++XrQ5XAORaTeJidyPienuhBPZI3e4FSfJr2Cp9BmL9QUS87zO7KAG10a2RyqB3ATSpdp61GJIa1nU7s0uuppmnUDmsgrJSlU7Qwn0NVdgqt5MD/qg5nmGelDwZmiHrpaOYsv3EWBGU8fqLn9n/Zl4MAqZpTTB22NZAVyY/EJpqliblFeDVjDiaa+AEpGWCM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39850400004)(366004)(376002)(396003)(136003)(71200400001)(7696005)(52536014)(33656002)(122000001)(316002)(9686003)(99936003)(83380400001)(55016002)(5660300002)(38100700002)(6506007)(53546011)(26005)(86362001)(8936002)(8676002)(4326008)(66946007)(66576008)(76116006)(77540400001)(44832011)(478600001)(66476007)(66446008)(9326002)(166002)(186003)(966005)(110136005)(38070700005)(64756008)(2906002)(55236004)(66556008)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cHl5SndwWklxZ3VpVWRnSFJ2dldRcTJRK1JEN283ckpzV0ZLRno0ejMzOUw0?= =?utf-8?B?czlrUHBtNzJTWmo4TXpiQ21zQmdBanI5cHlaV3VZUWNZMDdRWU9UeTNIa2xj?= =?utf-8?B?bm1OL3BteWh5cW5oQmdxK09lU2lWQTN2VlZTdGticUZKWCtwZmdLVEJXdHdM?= =?utf-8?B?b3BjVjZVcGtpMEpyN3lwNG1BRFlvU3FacEgrNm53bEpDdXV4aklHaVg3VUVV?= =?utf-8?B?M0J1OTRQN0JHRnpFdjVHVGtRbFlUTmxxb016bFJOTG11VFF0c3FkQmozRE9a?= =?utf-8?B?MWFjUndTK2VWZDZxRkF4VkNpUHhnMGRhNmkwOFZJUVV4WVJtZEFxT0g0MVp0?= =?utf-8?B?Z2ZjZmFqUTlWcit5clA3Q0ZtempkMklWeVUrdGozZ1BBaDVxUk1OYmEzaXJV?= =?utf-8?B?di92dHpTV3ZCQ3RGSHFzUWVMNHJLSmtVQ0psQ2EyektMUHJVTHA2L0FpTjM4?= =?utf-8?B?ZmpNaVl4RnlKUGNRS010YmRvWWFIVzdBeldNOHV0VXV0YlIxV2ZtdngrKzZM?= =?utf-8?B?OFhMcDRWbUhIVy9OcGhsRjZSTWhONVZOQjA1MXZoMk03dHI3N1lVeUpjUlE0?= =?utf-8?B?aEVNY1o5cEJFRnF5WUl0Q3p4eEdGbzVFbmczWCtYUEpoQnhZRkw3S29Kdm1M?= =?utf-8?B?UnhmS0hPb0ROMXA5TjRqUUkvTXdocGxCRHVmbGQ5RTNhNFZVbFVTKzJnQitK?= =?utf-8?B?azNoU3k5dlhDOWVKZnV2dy9KYmNrVG9PWWZWY1lYV3dWT3NMUHRCZHhOVUZx?= =?utf-8?B?a0duRDg0TmREY0xzRmJvNDZ1N254ZGdtSlNRSDZUUkhVS1E3ZXFnN0tKVERv?= =?utf-8?B?N3BBeEg0UjkrWkFhU0g5TjExZzFtM1lXSkpmMFNzc0tVRVp1L0RZUkk5S0RI?= =?utf-8?B?TzlLQVlsZEFHM0ZjVmlrNlFCVjFDNjd5V2Fla3grTStGN1hrdC90SXNLNndo?= =?utf-8?B?Z3JYRW5LVE42cm92ajE1ZDNmcmxrVVZiTWY2ZFo0bERYdnVOZ1dvT1BlMmdh?= =?utf-8?B?S1FvMGE4UnJkbjV1SnZjdHJjaG9CVy9PSFhUUFdPaXJFeVoycnZ4ZERQYXZn?= =?utf-8?B?SFFRUGNUQXVXdzZFVmxld0xXSWI2M1NCMXM4aHp2MDg3WStVazNFYTNIZUtG?= =?utf-8?B?cHd4QUtEclljdmMyVXl2UWVLOC96SGUxT1ZzYVBkUGVSazlFWEJvai9zdW1h?= =?utf-8?B?Mi9zeVZVTlBlMERQSk13cExWaE5KSnRMWFZHUzBETU9lU2dWTytUMnVFbWVy?= =?utf-8?B?OFpGSWQ0d0JGNnNzS0xPRktkaEZVaUpscmNNb2tPWTF6MXZqVjBDQjBvVVpZ?= =?utf-8?B?ZHZXK3Z2ZVR1aW9FbWhRVzg0NjM0M0lFdVlMNngrY1FxZ3VHMy9USGZ0dEpp?= =?utf-8?B?Zk9DOE9MVUZrSEgwSDV3VVlTNFhWM09scGJyZVdtd3pHVkJkQTErWDBrVXpu?= =?utf-8?B?TDc3bGhHUmpmN2hISWVNL2xYRE1Za0ZmczhhanhhS1JqZVpXWTJQMVU1YlRn?= =?utf-8?B?SEJOR3c1ZXVDNkg5UG5mZllDdS9BakpCSVdHN0hGNzBuMWdzdEYzMTFMTmdE?= =?utf-8?B?Z0d1dW01aXJhcmN0aEdrSHlVdlB6OWVZd1o1MTVMUTZUdUpGYTVnTWZoTHIr?= =?utf-8?B?UFR2MGZUeG95V2hLZTU4L0I0WmpvNFdrcEEzcU9QMHlvZjVIbG5NbG0zZTJO?= =?utf-8?B?OXpmbjExbEJ1UlFucm9tVFRoVjBuYjY5Tk1XSFdEZkM0Zmt4amZZOGNkV1o5?= =?utf-8?Q?no+qblRzCd5hmYWDd0JeV5NlO96lKnC2uN3sOiD?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a681ca9-0241-440a-0cf9-08d96948c3a6 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Aug 2021 10:52:28.9472 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FFvsC2NoZmNbPQUYpTl8ewT58ZOhPJVTZiYUiBwnSRutLhjHEHQ+uu5WtVghwe04dgPQp47vCZfjCXzcBJZLAA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB4197 Archived-At: Subject: Re: [Rum] VRS Provider issues - MWI X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 10:52:44 -0000 --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_" --_000_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSm9lLA0KDQpUaGUgcHJvcG9zYWwgdG8gdXNlIFNJUCBQVVNIIGFuZCBXTUkgZGVmaW5lcyBz dGFuZGFyZHMgdGhhdCBlY2hvIHRoZSBwcm9wcmlldGFyeSBtZWNoYW5pc21zIHRoYXQgVVMgUHJv dmlkZXJzIGFyZSBhbHJlYWR5IHVzaW5nLg0KDQpXaGF0IHRoaXMgc3BlY2lmaWNhdGlvbiBfZG9l c19ub3RfIGRvIGlzIHNvbWVob3cgbWFrZSBtZXNzYWdlIG5vdGlmaWNhdGlvbnMgbW9yZSBjb25z aXN0ZW50IG9yIHRpbWVseSBpbiBhbmQgb2YgaXRzZWxmLCBiZWNhdXNlIGl0IGlzIHVzaW5nIGVx dWl2YWxlbnQgdGVjaG5vbG9naWVzLg0KV2Ugd291bGQgYWxzbyB0ZW5kIG5vdCB0byBhZ3JlZSB0 aGF0IG5vdGlmaWNhdGlvbiBwcm9ibGVtcyBhcmUgZW5kZW1pYy4gVGhhdCBpcyBub3QgdGhlIGZl ZWRiYWNrIHdlIGdldCBmcm9tIG91ciBEZWFmIGVtcGxveWVlcywgY29tbXVuaXR5LCBhbmFseXRp Y3Mgb3IgdGhlIHJlZ3VsYXIgdGVzdGluZyB3ZSBwZXJmb3JtIGFib3ZlIGFuZCBiZXlvbmQgdGhl IHJlZ3VsYXIgVVMgVlJTIEludGVyT3AgY29uZmVyZW5jZXMuDQpUaGUgcXVhbGl0eSwgcmVsaWFi aWxpdHkgYW5kIGludGVyLW9wZXJhYmlsaXR5IG9mIG91ciBzZXJ2aWNlcyBpcyBzb21ldGhpbmcg d2UgaGF2ZSBhbGwgYWx3YXlzIHZlcnkgc2VyaW91c2x5Lg0KDQpDaGVlcnMsDQoNCg0KRWQgU2F5 ZXJzDQpFbmRwb2ludCBTREsgVGVhbSBMZWFkDQpQdXJwbGUsIGEgRGl2aXNpb24gb2YgWlAgQmV0 dGVyIFRvZ2V0aGVyLCBMTEMNCnB1cnBsZXZycy5jb208aHR0cHM6Ly9wdXJwbGV2cnMuY29tLz4N Cg0KW1B1cnBsZSBpcyBERUkgY2VydGlmaWVkIV0NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBlLW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uYWwg YW5kIGNvbmZpZGVudGlhbCB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCwgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVz c2FnZS4NCg0KDQoNCg0KRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxm IE9mIEpvZSBHcnVlc3NpbmcNClNlbnQ6IDI2IEF1Z3VzdCAyMDIxIDIyOjIwDQpUbzogQnJpYW4g Um9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PjsgS3l6aXZhdCwgUGF1bCA8cGt5eml2YXRAYWx1bS5t aXQuZWR1Pg0KQ2M6IHJ1bUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtSdW1dIFZSUyBQcm92aWRl ciBpc3N1ZXMgLSBNV0kNCg0KDQpGb3Igd2hhdCBpdOKAmXMgd29ydGgsIHRoZSBOVEwgcm91dGlu ZWx5IGludGVyYWN0cyB3aXRoIHRoZSBjb21tdW5pdHkgKGluY2x1ZGluZyBhY2FkZW1pYSkgdG8g Z2V0IGZlZWRiYWNrIGFuZCB3ZSBicmluZyBzdHVkZW50cyBmcm9tIHRoZSBjb21tdW5pdHkgaW4g dG8gcGVyZm9ybSB0ZXN0aW5nIHdpdGggdXMgb24gYSByZWd1bGFyIGJhc2lzLiBGb3IgdGhpcyBw YXJ0aWN1bGFyIGlzc3VlLCB0aGUgZmVlZGJhY2sgZnJvbSB1c2VycyBvZiB0aGUgZXhpc3Rpbmcg VlJTIGVjb3N5c3RlbSBpcyBjb25zaXN0ZW50IGFuZCByZXBlYXRlZDogdGhlcmUgaXMgYSBsYWNr IG9mIG1lc3NhZ2Ugbm90aWZpY2F0aW9uLCBvciBvZiBjb25zaXN0ZW50IG5vdGlmaWNhdGlvbiBm cm9tIHdpdGhpbiB0aGUgY2xpZW50IGFwcC4gSW1wbGVtZW50YXRpb24gdmFyaWVzIGZyb20gUHJv dmlkZXIgdG8gUHJvdmlkZXIgYW5kIGZyb20gY2xpZW50IHRvIGNsaWVudCBjdXJyZW50bHkuDQoN ClRoZSBleGlzdGluZyBsYW5ndWFnZSBhbmQgdGhlIHByb3Bvc2FsIHRvIGFkZCBhIHByb3ZpZGVy LWJhc2VkIHJldHJpZXZhbCBVUkwgZm9yIGEgUlVFIG1ha2VzIGEgbG90IG9mIHNlbnNlIQ0KDQot LS0tLS0tLS0tDQpKb2UgR3J1ZXNzaW5nDQpJbmZyYXN0cnVjdHVyZSBFbmdpbmVlcmluZywgUHJp bmNpcGFsDQpHcm91cCBMZWFkZXIsIEwxMTQNCg0KT2ZmaWNlOiAoNzAzKSA5ODMtMjA3NQ0KTW9i aWxlOiAoNzAzKSAzNDctMjQwMg0KDQogW0xpbmtlZEluXSA8aHR0cHM6Ly93d3cubGlua2VkaW4u Y29tL2NvbXBhbnkvbWl0cmU+ICBbVHdpdHRlcl0gPGh0dHBzOi8vdHdpdHRlci5jb20vTUlUUkVj b3JwPiAgW1lvdVR1YmVdIDxodHRwczovL3d3dy55b3V0dWJlLmNvbS91c2VyL21pdHJlY29ycD4g IFtGYWNlYm9va10gPGh0dHBzOi8vd3d3LmZhY2Vib29rLmNvbS9NSVRSRWNvcnA+ICBbSW5zdGFn cmFtXSA8aHR0cHM6Ly93d3cuaW5zdGFncmFtLmNvbS9taXRyZS5jb3JwLz9obD1lbj4NCg0KW01J VFJFIHwgU29sdmluZyBQcm9ibGVtcyBmb3IgYSBTYWZlciBXb3JsZF0NCg0KRnJvbTogQnJpYW4g Um9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2VuLm5ldD4+DQpTZW50 OiBUaHVyc2RheSwgQXVndXN0IDI2LCAyMDIxIDM6MTkgUE0NClRvOiBLeXppdmF0LCBQYXVsIDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+DQpDYzog cnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1J1bV0gVlJT IFByb3ZpZGVyIGlzc3VlcyAtIE1XSQ0KDQpBYnNvbHV0ZWx5IHdpbGxpbmcgdG8gZG8gdGhhdC4N Cg0KSXQgd291bGRu4oCZdCBiZSBtdWNoIHRleHQuDQoNCkJyaWFuDQoNCg0KT24gQXVnIDI2LCAy MDIxLCBhdCAzOjE2IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWls dG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQoNCk9uIDgvMjYvMjEgMzowMSBQTSwg QnJpYW4gUm9zZW4gd3JvdGU6DQpJ4oCZbSBjZXJ0YWlubHkgd2lsbGluZyB0byBhZGQgYSBVUkwg Zm9yIHJldHJpZXZhbCB0byB0aGUgY29uZmlnIGRhdGEuDQoNClRoZXJlIHByb2JhYmx5IHNob3Vs ZCBiZSBhIHNlY3Rpb24gb24gcmV0cmlldmFsL21hbmFnZW1lbnQgb2YgdmlkZW8gbWFpbCAtIGJh c2ljYWxseSB3aGF0IHRoZSBSVUUgaXMgc3VwcG9zZWQgdG8gZG8gd2l0aCB0aGUgVVJMLiBXZSBu ZWVkIHRvIHNlZSB0aGF0IHRoZSB1c2VyIHdpbGwgYmUgYWJsZSB0byBmdWxseSBtYW5hZ2Ugdmlk ZW8gbWFpbCBmcm9tIHRoZSBSVUUgd2l0aG91dCBhbnkgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRp b24uDQoNCiAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAgICAgICAgICAgIFBhdWwNCg0KQnJp YW4NCk9uIEF1ZyAyNiwgMjAyMSwgYXQgMjo1OSBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBh bHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KDQpPbiA4 LzI2LzIxIDE6MzMgUE0sIEJyaWFuIFJvc2VuIHdyb3RlOg0KDQpUaGUgZG9jIG9ubHkgcmVxdWly ZXMgTVdJLCB3aGljaCBpcyB0aGUgbm90aWZpY2F0aW9uIG9mIG1lc3NhZ2VzIHdhaXRpbmcuICBJ dCBkb2VzIG5vdCBhc3N1bWUgYW55IHNwZWNpZmljIG1lY2hhbmlzbSB0byByZXRyaWV2ZSBtZXNz YWdlcy4gIE9ubHkgdGhlIG5vdGlmaWNhdGlvbiB0byB0aGUgdXNlciB0aGF0IHRoZXJlIGFyZSBt ZXNzYWdlcyB3YWl0aW5nIHRvIGJlIHJldHJpZXZlZC4gU28gZGlzY3Vzc2lvbiBvZiBob3cgbWVz c2FnZXMgYXJlIHN0cmVhbWVkIGlzIG91dCBvZiBzY29wZS4NCg0KSSBkb24ndCB0aGluayB0aGF0 IG1ha2VzIHNlbnNlLiBBbiBpbnRlcm9wZXJhYmxlIFJVRSBpcyBhIGZhaWx1cmUgaWYgdGhlIHVz ZXIgc3RpbGwgbmVlZHMgYSBwcm9wcmlldGFyeSBtZWNoYW5pc20gdG8gcmV0cmlldmUgdGhlIHZp ZGVvIG1haWwuDQoNClRoZSB0cmFkaXRpb25hbCBTSVAgbWVjaGFuaXNtIGZvciB2b2ljZW1haWwg aXMgdGhhdCB0aGUgdXNlciBlc3RhYmxpc2hlcyBhIHNpcCBkaWFsb2cgdGhyb3VnaCB3aGljaCB0 aGUgdXNlciByZWNlaXZlcyBzYXZlZCB1cCB2b2ljZSBtYWlsLiBBcyBFZCBub3RlcywgaXQgaXMg YXJjaGFpYyBpbiB0aGF0IGl0IHR5cGljYWxseSBkb2Vzbid0IHByb3ZpZGUgYSB3YXkgdG8gcGlj ayBhbmQgY2hvb3NlIHdoYXQgeW91IHdhbnQgdG8gaGVhci4gKFBvdGVudGlhbGx5IGl0IGNhbiwg dmlhIHNvbWUgaW50ZXJhY3Rpb24gb3ZlciBhIG1lZGlhIHN0cmVhbSBlc3RhYmxpc2hlZCBieSB0 aGUgY2FsbCBhcyBsb25nIGFzIHRoZSBkZXZpY2UgZG9lc24ndCBoYXZlIHRvIGRvIGFueXRoaW5n IHNwZWNpYWwuKQ0KDQpJIHdhcyB0aGlua2luZyB0aGF0IHRoZXJlIHdhcyBhbiBleHRlbnNpb24g dG8gUkZDMzg0MiB0aGF0IGluY2x1ZGVkIGFuIGVudW1lcmF0aW9uIG9mIGluZGl2aWR1YWwgbWVz c2FnZXMgd2l0aCBhIFVSTCB0byBhY2Nlc3MgZWFjaC4gQnV0IEkgaGF2ZW4ndCBiZWVuIGFibGUg dG8gZmluZCBzdWNoIHNvIEkgbWF5IGhhdmUgYmVlbiBpbWFnaW5pbmcgaXQuDQoNCkkgdGhpbmsg d2UgY291bGQgYWxsb3cgY29uZmlndXJhdGlvbiBvZiBlaXRoZXIgYSBTSVAgb3IgYW4gSFRUUFMg VVJMIGZvciB1c2UgaW4gcmV0cmlldmluZyB2aWRlbyBtYWlsLiBUaGUgSFRUUFMgd291bGQgcHJv dmlkZSBhIHdheSB0byBvZmZlciBhIHByb3ZpZGVyLXNwZWNpZmljIEdVSSBmb3IgbWFuYWdpbmcg dGhlIHZpZGVvIG1haWwgdGhhdCBjYW4gYmUgYWNjZXNzZWQgYnkgYSBSVUUgdGhhdCBoYXMgbm8g cHJvcHJpZXRhcnkgcGFydHMuDQoNCiAgVGhhbmtzLA0KICAgICAgIFBhdWwNCg0KLS0NClJ1bSBt YWlsaW5nIGxpc3QNClJ1bUBpZXRmLm9yZzxtYWlsdG86UnVtQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0NCg0K --_000_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS10 YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLWNv bnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0K c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEpvZSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHByb3Bvc2FsIHRv IHVzZSBTSVAgUFVTSCBhbmQgV01JIGRlZmluZXMgc3RhbmRhcmRzIHRoYXQgZWNobyB0aGUgcHJv cHJpZXRhcnkgbWVjaGFuaXNtcyB0aGF0IFVTIFByb3ZpZGVycyBhcmUgYWxyZWFkeSB1c2luZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+V2hhdCB0aGlzIHNwZWNpZmljYXRpb24gXzxpPmRvZXM8L2k+X25vdF8gZG8gaXMgc29t ZWhvdyBtYWtlIG1lc3NhZ2Ugbm90aWZpY2F0aW9ucyBtb3JlIGNvbnNpc3RlbnQgb3IgdGltZWx5 IGluIGFuZCBvZiBpdHNlbGYsIGJlY2F1c2UgaXQgaXMgdXNpbmcgZXF1aXZhbGVudCB0ZWNobm9s b2dpZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSB3b3VsZCBhbHNvIHRlbmQgbm90 IHRvIGFncmVlIHRoYXQgbm90aWZpY2F0aW9uIHByb2JsZW1zIGFyZSBlbmRlbWljLiBUaGF0IGlz IG5vdCB0aGUgZmVlZGJhY2sgd2UgZ2V0IGZyb20gb3VyIERlYWYgZW1wbG95ZWVzLCBjb21tdW5p dHksIGFuYWx5dGljcyBvciB0aGUgcmVndWxhciB0ZXN0aW5nIHdlIHBlcmZvcm0gYWJvdmUgYW5k IGJleW9uZA0KIHRoZSByZWd1bGFyIFVTIFZSUyBJbnRlck9wIGNvbmZlcmVuY2VzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhlIHF1YWxpdHksIHJlbGlhYmlsaXR5IGFuZCBpbnRlci1v cGVyYWJpbGl0eSBvZiBvdXIgc2VydmljZXMgaXMgc29tZXRoaW5nIHdlIGhhdmUgYWxsIGFsd2F5 cyB2ZXJ5IHNlcmlvdXNseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNv Tm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3 aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTtib3JkZXItY29sbGFwc2U6Y29sbGFwc2UiPg0KPHRi b2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MzUuMjVwdCI+DQo8dGQgd2lkdGg9IjM4MSIgc3R5bGU9 IndpZHRoOjI4NS43NXB0O2JhY2tncm91bmQ6d2hpdGU7cGFkZGluZzowY20gMGNtIDBjbSAwY207 aGVpZ2h0OjM1LjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206Ny41cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bTo3LjVwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RWQgU2F5ZXJzPC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+RW5kcG9pbnQgU0RLIFRlYW0gTGVhZDxicj4NClB1cnBsZSwgYSBEaXZpc2lv biBvZiBaUCBCZXR0ZXIgVG9nZXRoZXIsIExMQzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3B1cnBsZXZycy5jb20vIj48c3BhbiBzdHls ZT0iY29sb3I6IzMzN0FCNyI+cHVycGxldnJzLmNvbTwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8dGQgc3R5 bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIiB3aWR0aD0iMzIiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9Imhl aWdodDozNS4yNXB0Ij4NCjx0ZCB3aWR0aD0iMzkwIiBjb2xzcGFuPSIyIiBzdHlsZT0id2lkdGg6 MjkyLjVwdDtiYWNrZ3JvdW5kOndoaXRlO3BhZGRpbmc6My43NXB0IDBjbSAwY20gMGNtO2hlaWdo dDozNS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzMDAiIGhlaWdodD0iNTQiIHN0eWxlPSJ3aWR0aDoz LjEyNWluO2hlaWdodDouNTYyNWluIiBpZD0iUGljdHVyZV94MDAyMF83IiBzcmM9ImNpZDppbWFn ZTAwNy5qcGdAMDFENzlCMzIuOTg5QjY1QjAiIGFsdD0iUHVycGxlIGlzIERFSSBjZXJ0aWZpZWQh Ij48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDozNS4yNXB0Ij4NCjx0ZCB3aWR0aD0i NTAwIiBjb2xzcGFuPSIyIiBzdHlsZT0id2lkdGg6Mzc1LjBwdDtiYWNrZ3JvdW5kOndoaXRlO3Bh ZGRpbmc6MzAuMHB0IDBjbSAwY20gMGNtO2hlaWdodDozNS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb25h bCBhbmQgY29uZmlkZW50aWFsIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpIG5hbWVkIGFib3ZlLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQogY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwsIGFuZCBkZWxldGUgdGhlIG9yaWdpbmFs IG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0K PC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IFJ1bSAmbHQ7cnVtLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkpvZSBHcnVlc3Npbmc8YnI+DQo8Yj5TZW50OjwvYj4gMjYgQXVndXN0IDIwMjEg MjI6MjA8YnI+DQo8Yj5Ubzo8L2I+IEJyaWFuIFJvc2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZn dDs7IEt5eml2YXQsIFBhdWwgJmx0O3BreXppdmF0QGFsdW0ubWl0LmVkdSZndDs8YnI+DQo8Yj5D Yzo8L2I+IHJ1bUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1J1bV0gVlJTIFBy b3ZpZGVyIGlzc3VlcyAtIE1XSTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkZvciB3aGF0IGl04oCZcyB3b3J0aCwgdGhlIE5UTCBy b3V0aW5lbHkgaW50ZXJhY3RzIHdpdGggdGhlIGNvbW11bml0eSAoaW5jbHVkaW5nIGFjYWRlbWlh KSB0byBnZXQgZmVlZGJhY2sgYW5kIHdlIGJyaW5nIHN0dWRlbnRzIGZyb20gdGhlIGNvbW11bml0 eSBpbiB0byBwZXJmb3JtIHRlc3Rpbmcgd2l0aCB1cyBvbiBhIHJlZ3VsYXIgYmFzaXMuIEZvcg0K IHRoaXMgcGFydGljdWxhciBpc3N1ZSwgdGhlIGZlZWRiYWNrIGZyb20gdXNlcnMgb2YgdGhlIGV4 aXN0aW5nIFZSUyBlY29zeXN0ZW0gaXMgY29uc2lzdGVudCBhbmQgcmVwZWF0ZWQ6IHRoZXJlIGlz IGEgbGFjayBvZiBtZXNzYWdlIG5vdGlmaWNhdGlvbiwgb3Igb2YgY29uc2lzdGVudCBub3RpZmlj YXRpb24gZnJvbSB3aXRoaW4gdGhlIGNsaWVudCBhcHAuIEltcGxlbWVudGF0aW9uIHZhcmllcyBm cm9tIFByb3ZpZGVyIHRvIFByb3ZpZGVyIGFuZA0KIGZyb20gY2xpZW50IHRvIGNsaWVudCBjdXJy ZW50bHkuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPlRoZSBleGlzdGluZyBsYW5ndWFnZSBhbmQgdGhlIHByb3Bvc2FsIHRvIGFkZCBh IHByb3ZpZGVyLWJhc2VkIHJldHJpZXZhbCBVUkwgZm9yIGEgUlVFIG1ha2VzIGEgbG90IG9mIHNl bnNlITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToyLjBwdDtsaW5lLWhlaWdodDoxMi4wcHQ7bXNvLWxpbmUtaGVp Z2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMy RjU0OTYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToyLjBwdDtsaW5lLWhlaWdodDoxMi4wcHQ7bXNvLWxp bmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMyRjU0OTYiPi0tLS0tLS0tLS08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206Mi4wcHQ7bGluZS1oZWlnaHQ6MTIu MHB0O21zby1saW5lLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMkY1NDk2Ij5Kb2UgR3J1ZXNzaW5nPG86cD48L286cD48L3NwYW4+PC9i PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjIuMHB0O2xp bmUtaGVpZ2h0OjEyLjBwdDttc28tbGluZS1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkluZnJhc3RydWN0dXJlIEVuZ2luZWVyaW5n LCBQcmluY2lwYWw8Yj48bzpwPjwvbzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEzLjBwdDttc28tbGluZS1oZWlnaHQtcnVsZTpleGFj dGx5Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5Hcm91cCBMZWFkZXIs IEwxMTQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTMuMHB0O21zby1saW5lLWhlaWdodC1ydWxlOmV4YWN0bHkiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7bXNvLWxp bmUtaGVpZ2h0LXJ1bGU6ZXhhY3RseSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+T2ZmaWNlOiAoNzAzKSA5ODMtMjA3NTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMy4wcHQ7bXNvLWxpbmUtaGVpZ2h0 LXJ1bGU6ZXhhY3RseSI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+TW9i aWxlOiAoNzAzKSAzNDctMjQwMjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiM3 RjdGN0YiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdG Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cubGlua2VkaW4uY29tL2NvbXBhbnkv bWl0cmUiIHRpdGxlPSJodHRwczovL3d3dy5saW5rZWRpbi5jb20vY29tcGFueS9taXRyZS8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdGO3Rl eHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjIxIiBoZWlnaHQ9IjIx IiBzdHlsZT0id2lkdGg6LjIxODdpbjtoZWlnaHQ6LjIxODdpbiIgaWQ9IlBpY3R1cmVfeDAwMjBf MSIgc3JjPSJjaWQ6aW1hZ2UwMDgucG5nQDAxRDc5QjMyLjk4OUI2NUIwIiBhbHQ9IkxpbmtlZElu Ij48L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjojN0Y3RjdGIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNvbS9N SVRSRWNvcnAiIHRpdGxlPSJodHRwczovL3R3aXR0ZXIuY29tL01JVFJFY29ycCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3RjdGN0Y7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjMiIGhlaWdodD0iMTkiIHN0eWxl PSJ3aWR0aDouMjM5NWluO2hlaWdodDouMTk3OWluIiBpZD0iUGljdHVyZV94MDAyMF8yIiBzcmM9 ImNpZDppbWFnZTAwOS5wbmdAMDFENzlCMzIuOTg5QjY1QjAiIGFsdD0iVHdpdHRlciI+PC9zcGFu PjwvYT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6IzdG N0Y3RiI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3VzZXIv bWl0cmVjb3JwIiB0aXRsZT0iaHR0cHM6Ly93d3cueW91dHViZS5jb20vdXNlci9taXRyZWNvcnAi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjojN0Y3RjdG O3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjMyIiBoZWlnaHQ9 IjIxIiBzdHlsZT0id2lkdGg6LjMzMzNpbjtoZWlnaHQ6LjIxODdpbiIgaWQ9IlBpY3R1cmVfeDAw MjBfMyIgc3JjPSJjaWQ6aW1hZ2UwMTAucG5nQDAxRDc5QjMyLjk4OUI2NUIwIiBhbHQ9IllvdVR1 YmUiPjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOiM3RjdGN0YiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5mYWNlYm9v ay5jb20vTUlUUkVjb3JwIiB0aXRsZT0iaHR0cHM6Ly93d3cuZmFjZWJvb2suY29tL01JVFJFY29y cCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOiM3RjdG N0Y7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMjMiIGhlaWdo dD0iMjMiIHN0eWxlPSJ3aWR0aDouMjM5NWluO2hlaWdodDouMjM5NWluIiBpZD0iUGljdHVyZV94 MDAyMF80IiBzcmM9ImNpZDppbWFnZTAxMS5wbmdAMDFENzlCMzIuOTg5QjY1QjAiIGFsdD0iRmFj ZWJvb2siPjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOiM3RjdGN0YiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5pbnN0 YWdyYW0uY29tL21pdHJlLmNvcnAvP2hsPWVuIiB0aXRsZT0iaHR0cHM6Ly93d3cuaW5zdGFncmFt LmNvbS9taXRyZS5jb3JwLz9obD1lbiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOiM3RjdGN0Y7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVy PSIwIiB3aWR0aD0iMjMiIGhlaWdodD0iMjMiIHN0eWxlPSJ3aWR0aDouMjM5NWluO2hlaWdodDou MjM5NWluIiBpZD0iUGljdHVyZV94MDAyMF81IiBzcmM9ImNpZDppbWFnZTAxMi5wbmdAMDFENzlC MzIuOTg5QjY1QjAiIGFsdD0iSW5zdGFncmFtIj48L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjpibGFjayI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMTYwIiBoZWlnaHQ9IjIwIiBzdHlsZT0id2lkdGg6 MS42NjY2aW47aGVpZ2h0Oi4yMDgzaW4iIGlkPSJQaWN0dXJlX3gwMDIwXzYiIHNyYz0iY2lkOmlt YWdlMDEzLnBuZ0AwMUQ3OUIzMi45ODlCNjVCMCIgYWx0PSJNSVRSRSB8IFNvbHZpbmcgUHJvYmxl bXMgZm9yIGEgU2FmZXIgV29ybGQiPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBCcmlhbiBSb3NlbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4mZ3Q7DQo8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEF1Z3VzdCAyNiwgMjAyMSAzOjE5IFBNPGJyPg0K PGI+VG86PC9iPiBLeXppdmF0LCBQYXVsICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1 bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4g PGEgaHJlZj0ibWFpbHRvOnJ1bUBpZXRmLm9yZyI+cnVtQGlldGYub3JnPC9hPjxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogW1J1bV0gVlJTIFByb3ZpZGVyIGlzc3VlcyAtIE1XSTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkFic29sdXRlbHkgd2lsbGluZyB0byBkbyB0aGF0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0IHdvdWxkbuKAmXQgYmUg bXVjaCB0ZXh0LiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkJyaWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gQXVn IDI2LCAyMDIxLCBhdCAzOjE2IFBNLCBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0bzpw a3l6aXZhdEBhbHVtLm1pdC5lZHUiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5PbiA4LzI2LzIxIDM6MDEgUE0sIEJyaWFuIFJvc2VuIHdyb3Rl Ojwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SeKAmW0gY2Vy dGFpbmx5IHdpbGxpbmcgdG8gYWRkIGEgVVJMIGZvciByZXRyaWV2YWwgdG8gdGhlIGNvbmZpZyBk YXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxicj4NClRoZXJlIHByb2JhYmx5IHNob3VsZCBiZSBhIHNlY3Rpb24gb24gcmV0 cmlldmFsL21hbmFnZW1lbnQgb2YgdmlkZW8gbWFpbCAtIGJhc2ljYWxseSB3aGF0IHRoZSBSVUUg aXMgc3VwcG9zZWQgdG8gZG8gd2l0aCB0aGUgVVJMLiBXZSBuZWVkIHRvIHNlZSB0aGF0IHRoZSB1 c2VyIHdpbGwgYmUgYWJsZSB0byBmdWxseSBtYW5hZ2UgdmlkZW8gbWFpbCBmcm9tIHRoZSBSVUUg d2l0aG91dCBhbnkgcHJvcHJpZXRhcnkgaW1wbGVtZW50YXRpb24uPGJyPg0KPGJyPg0KPHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu PlRoYW5rcyw8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8L3NwYW4+UGF1bDxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5C cmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24g QXVnIDI2LCAyMDIxLCBhdCAyOjU5IFBNLCBQYXVsIEt5eml2YXQgJmx0OzxhIGhyZWY9Im1haWx0 bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiPnBreXppdmF0QGFsdW0ubWl0LmVkdTwvYT4mZ3Q7IHdy b3RlOjxicj4NCjxicj4NCk9uIDgvMjYvMjEgMTozMyBQTSwgQnJpYW4gUm9zZW4gd3JvdGU6PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VGhlIGRvYyBvbmx5IHJlcXVpcmVzIE1XSSwg d2hpY2ggaXMgdGhlIG5vdGlmaWNhdGlvbiBvZiBtZXNzYWdlcyB3YWl0aW5nLiAmbmJzcDtJdCBk b2VzIG5vdCBhc3N1bWUgYW55IHNwZWNpZmljIG1lY2hhbmlzbSB0byByZXRyaWV2ZSBtZXNzYWdl cy4gJm5ic3A7T25seSB0aGUgbm90aWZpY2F0aW9uDQogdG8gdGhlIHVzZXIgdGhhdCB0aGVyZSBh cmUgbWVzc2FnZXMgd2FpdGluZyB0byBiZSByZXRyaWV2ZWQuIFNvIGRpc2N1c3Npb24gb2YgaG93 IG1lc3NhZ2VzIGFyZSBzdHJlYW1lZCBpcyBvdXQgb2Ygc2NvcGUuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KSSBkb24n dCB0aGluayB0aGF0IG1ha2VzIHNlbnNlLiBBbiBpbnRlcm9wZXJhYmxlIFJVRSBpcyBhIGZhaWx1 cmUgaWYgdGhlIHVzZXIgc3RpbGwgbmVlZHMgYSBwcm9wcmlldGFyeSBtZWNoYW5pc20gdG8gcmV0 cmlldmUgdGhlIHZpZGVvIG1haWwuPGJyPg0KPGJyPg0KVGhlIHRyYWRpdGlvbmFsIFNJUCBtZWNo YW5pc20gZm9yIHZvaWNlbWFpbCBpcyB0aGF0IHRoZSB1c2VyIGVzdGFibGlzaGVzIGEgc2lwIGRp YWxvZyB0aHJvdWdoIHdoaWNoIHRoZSB1c2VyIHJlY2VpdmVzIHNhdmVkIHVwIHZvaWNlIG1haWwu IEFzIEVkIG5vdGVzLCBpdCBpcyBhcmNoYWljIGluIHRoYXQgaXQgdHlwaWNhbGx5IGRvZXNuJ3Qg cHJvdmlkZSBhIHdheSB0byBwaWNrIGFuZCBjaG9vc2Ugd2hhdCB5b3Ugd2FudCB0byBoZWFyLiAo UG90ZW50aWFsbHkNCiBpdCBjYW4sIHZpYSBzb21lIGludGVyYWN0aW9uIG92ZXIgYSBtZWRpYSBz dHJlYW0gZXN0YWJsaXNoZWQgYnkgdGhlIGNhbGwgYXMgbG9uZyBhcyB0aGUgZGV2aWNlIGRvZXNu J3QgaGF2ZSB0byBkbyBhbnl0aGluZyBzcGVjaWFsLik8YnI+DQo8YnI+DQpJIHdhcyB0aGlua2lu ZyB0aGF0IHRoZXJlIHdhcyBhbiBleHRlbnNpb24gdG8gUkZDMzg0MiB0aGF0IGluY2x1ZGVkIGFu IGVudW1lcmF0aW9uIG9mIGluZGl2aWR1YWwgbWVzc2FnZXMgd2l0aCBhIFVSTCB0byBhY2Nlc3Mg ZWFjaC4gQnV0IEkgaGF2ZW4ndCBiZWVuIGFibGUgdG8gZmluZCBzdWNoIHNvIEkgbWF5IGhhdmUg YmVlbiBpbWFnaW5pbmcgaXQuPGJyPg0KPGJyPg0KSSB0aGluayB3ZSBjb3VsZCBhbGxvdyBjb25m aWd1cmF0aW9uIG9mIGVpdGhlciBhIFNJUCBvciBhbiBIVFRQUyBVUkwgZm9yIHVzZSBpbiByZXRy aWV2aW5nIHZpZGVvIG1haWwuIFRoZSBIVFRQUyB3b3VsZCBwcm92aWRlIGEgd2F5IHRvIG9mZmVy IGEgcHJvdmlkZXItc3BlY2lmaWMgR1VJIGZvciBtYW5hZ2luZyB0aGUgdmlkZW8gbWFpbCB0aGF0 IGNhbiBiZSBhY2Nlc3NlZCBieSBhIFJVRSB0aGF0IGhhcyBubyBwcm9wcmlldGFyeSBwYXJ0cy48 YnI+DQo8YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyA8L3NwYW4+VGhh bmtzLDxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5QYXVsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCi0tPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NClJ1bSBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Im1haWx0bzpSdW1AaWV0Zi5vcmciPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlJ1bUBpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj48YnI+DQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bTwvc3Bhbj48L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_-- --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/jpeg; name="image007.jpg" Content-Description: image007.jpg Content-Disposition: inline; filename="image007.jpg"; size=9730; creation-date="Fri, 27 Aug 2021 10:52:25 GMT"; modification-date="Fri, 27 Aug 2021 10:52:25 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABIAAD/4QMraHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA2LjAtYzAwNiA3OS5kYWJhY2JiLCAyMDIxLzA0LzE0LTAw OjM5OjQ0ICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4 bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnht cD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRp ZDo4MzE1Qzc5Q0UwMjExMUVCQUUwOURCOTBDNEU1RjQ1RiIgeG1wTU06SW5zdGFuY2VJRD0ieG1w LmlpZDo4MzE1Qzc5QkUwMjExMUVCQUUwOURCOTBDNEU1RjQ1RiIgeG1wOkNyZWF0b3JUb29sPSJB Y3JvYmF0IFBERk1ha2VyIDIwIGZvciBXb3JkIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmlu c3RhbmNlSUQ9InhtcC5paWQ6RTcwNDM2NUJEQzIwMTFFQUE4RjdCOTI2MkRBNzdBRkEiIHN0UmVm OmRvY3VtZW50SUQ9InhtcC5kaWQ6RTcwNDM2NUNEQzIwMTFFQUE4RjdCOTI2MkRBNzdBRkEiLz4g PC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9 InIiPz7/7gAOQWRvYmUAZMAAAAAB/9sAhAAEAwMDAwMEAwMEBQMDAwUGBQQEBQYHBgYGBgYHCQcI CAgIBwkJCwsMCwsJDAwMDAwMEBAQEBASEhISEhISEhISAQQEBAcHBw4JCQ4UDg0OFBQSEhISFBIS EhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhL/wAARCAA2ASwDAREAAhEB AxEB/8QAvQAAAQUBAQEBAAAAAAAAAAAAAAMFBgcIBAIJAQEBAAIDAQEAAAAAAAAAAAAAAAEEAgMF BgcQAAEDAgQDBAQHDAcGBwAAAAIBAwQFBgAREgchEwgxIhQVQXEyGFFhQtSVFlaBkaFSsiMzJLQ1 Fzeic6OzdHV2YnKSQ5Q4pCVlpSY2KBEAAQIDBQIKCQQCAwAAAAAAAQACEQMEITFREgVBgfBhcZGx wdFSExShIjJyMzQVBhbhQmIj8aLCJTX/2gAMAwEAAhEDEQA/ALy316omNqrhC0LfpDVx16Mw3Kqr kqQUaLEbeRSaazADI3DHv9iCI5cVVck7emaMahmdxyjZxqzJp8wiVVHv03n9iqV/10v5vjqfjcvv nmHat3lBivz36rxRMysykoidqrPloietVj4fjcvvnmHankxivQddF4uCht2dRnALsIalJVF9Soxi D9ty++eYdqeTGK9e/Len2Mo/0jJ+b4fjcrvnmHanlBij35b0+xlH+kZPzfD8bld88w7U8oMUe/Le n2Mo/wBIyfm+H43K755h2p5QYo9+W9PsZR/pGT83w/G5XfPMO1PKDFHvy3p9jKP9Iyfm+H43K755 h2p5QYo9+W9PsZR/pGT83w/G5XfPMO1PKDFHvy3p9jKP9Iyfm+H43K755h2p5QYpztzrE3Ku2vQL aoFi0abWqy4TMKOtVeaRwxbJ1UU3GREchAl4rjXO0GTLYXueYDiWLqVoEYp9vzqQ3t2yGnleu3NF pI1snggqNbWTzCYQScReQ2enJDH2sV6XSaWfHw5hMP49qwlyGuuKh/vy3p9jKP8ASMn5vi5+Nyu+ eYdq2+UGKPflvT7GUf6Rk/N8PxuV3zzDtTygxUo276zXrhu2m29eNuR6HTq9IahR6lCluSORJfJG 2uc260HcM1QdQr3c81TLsq1n29kllzHRItgQsJlLARBWuMebVNN8QiWoz0UlURVnSiquSZh6EwRO GCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRYE3DZZf60ILD7YvsvXLbqONGKE BJ4SOuRIvBezHs6Uw0w+67pKvs+DzraN63lZe3lGS4LylM0akLIbipJKO46nOez0DpZbMuOS8css eTp6eZOdlYIlUmtLjAKEU/qL2CrM1ikxrppyyaiYsMjJjSI7Rma6RBXH2QbTNVy7xJi3M0qraMxa bFsMh4tgq86men22qhalT3Cs2mM0W6LeZKbUY8JsWmKnDaTU+jjIZCjwAiuA4KZrkolnq4XtG1R7 ZglzDFrrBHYexbKecQYG5YYbmRHSQGpDThn7IiYqq+pEXHsi0roQSyqiIqquSCmaqvYiJjFEk3Li vKotPtOkiKSoJiSoidq8FxJaUghqVFfLQy828eWekDElyT4kXAtIRKtkjxKDCFINF06GhVwlL8VE BFVV+JOOINiL06D0cdclh+GHFdUhlxlFy7clcEc8vTlgDG5Ekr7QiJkWhtzgDhZiBZ/ikvBfuYmC Kzunr+eNjf5k9+xSMc/VflX8nWFqn+wVe/XZ+isD/EVj+6jY4v2zfM5G9ar0e1Y7N1ttRQzQSc4A KrxJfgRPTj1UFdQroIaNEvLdLiLZooEvqEslXCCJ7s//AO52x/n9J/bmcaaj4TvdPQsX3FfWzHzR cdN0P95VH1s/kLgibr4r0u17TqdegttPy6c2BttvIStkpOAC6kBRXsL0LivVzjLlFwvCpahUukSH TG2luPKqjp+8O6k+CNWi2kzUKUWr9YjRZhCSASiWRC4fYqKi8MchmpVLhmDIjkK85L1yuc3OJQLe IO7VO9u92aXfTrlMejlRq+wCmUMy1g6I8CVo8hVVH5QKmafHkuV6i1Fs45SIOXW0zWWVJykZXjZ2 KO1e/wDeGJVp8WnWeEunxpT7USQsSWXNZBwhbPMXURdQoi5omK8ysqg4gMiI4FUp+pag2Y4NlRAJ hY67nTvY147l1qvDBum2hotKJlwylpHkNKjgomkdTrhJx9WN1JU1D3weyA5CrOn11ZMm5ZsvK2F8 D1lQ6RvrdDG2t93osGmJPshqK5DaUJCsOc55Wz5qI7qXIUzTSQ4s6JPdVzSx9g4t/YmkapMqQ/OA MsLo8fYoI1vn1TPDTzCyLU5VainNiOq86geHbjNzCJxfMMxVGXgc05Z5Ll28Mek8nS2+s6z/ABgu t4j8Fzs9QXUw+NLcC0rMbauOYVPpLj0xWQlSUccZEW1cqI5o44ybbfpIkRMk1DnJoaa31nWX8IJ4 j8AkKb1HdSNZqFbpVHtOz6pULSkNw6ozGkG5+tvNuuhGjklR0vuqLLncbVVQgUV44l1BTAAlzgDw wUCa/BcUTqi6h594P2BCs62pN4QmDkyKcIysm2W4wTCJXVn8v9E4C+1xIkH2uGMjp1OGZy45eAwT xXxhBd1I6i+pWuxqRJpln2k59Z2gkUyK7IJmaUZ1t55qS5EcqSPNsuhHcVtwgyLT8aZ4uoaYRi51 nDBT4j8FzUvqd6gKzW6xbsCgWP5ta0cplWCTMOK01GBvmuPC7IqACYNB3nVH2E9rLEu0+na0OJdA 3cIKBNcTCxKSepPqQheTJKs+1GSuifEpUEOa6RtT6g2jsOPNEaiqxSkNkjjPO06gXPAUFMY+s6wR 3C+FlsE8R+C7A3+6oSAHnrHteBGJhuW5KmuOxWI8Zxl2RzpDr1QEWgBtklcU17iqKLxMcYmipe8e G5T4j8Eum+XVWqd6wrZad8WUJY7jjgPI4MoISny1qOatc5wBR0cxVDEkzFc8R5Ol7x4W4J4j8E0x +prqJk3S5ZIWnajd1RacdVm0103wKFEbbF01lEs/Sy4AGJkyS6xQkzTjjM6fThubM6EYcLFHivjC CcIu/nVBOCE5Dsq1JI1RwAjiD7imLbyvoxJeb8x1tRn1jO8h8xQHNPDtTPE0VKIxcbOGF6nxH4J4 sHqH3XrV316z7zpFsW9OotsSa9HfFx8IfBtp6K89KSU+CRnAczI0TNE+DsxhPoZTWBzSTEw4WXqW zHRgVatlXje91QHV81sqXVpkCFU6azS3JstkIrzzzLpPnrHVkbJNioL7YEhJinOlMYbnQjC2Cza4 nBWnimtiwRf3/erTv9TW7+yMY9nTf+Yfdd0ldFnwdxWhuqu0Lovfa4KLaNLer1VGtU+SsRgmxPlM qamebpgOSZp6ccLRaiXKn5nmAgVVp3hrolY8h9M++FbkDSitJ+khO/NOTp8mI3GYA+6Thq264aoK LnpEVVexMepdrFK0RzxhsEVdM9gF63DutUodgbDXIVVl89KTa79NCS4uk5EpyJ4NlOKqup10h+/j x9E0zapsBe6O6MVz2WvUI3htqg0/phq0uPSoEeoMWzAVJbUVkHUPKOikhiKKirmvFFxcoJzzXAEm GY7eVbZbj4u9YbtURO7bbAxFxs65ShMCRCEhKcyiiSLmioqcFRe3HsJ/w3ch6FfdcVtrqvoFBpth W+/TqVBgvOXlQWjcYistkTZunqBVAUVRXLinYuPH6LNe6a6JJ9U7VzpLjFWHult9tJULVJ2+49Ot 61aRKYqFQkALMEXRjqqiw46AiehwlRCAFQj9lO3FKjqqgTP6yS42DasGOdGxUi/uZtNd+5m0Ns7W MpEh2zccpxxlmmuU+NyTpj7Qk3rBvVmvxZ+lcdcUVRLkzXzry3GO1bjKeAS5XFvc7tBRgoF57t6J bFsvyPIqY4BSUkzJABqIYYIXPMBb7upNAZqS+hU5WnCodmZJ/deeLl2LVKDjY1cdg70bN70uP2dT 4qLJFgjSg1qntspIjjkhkyBcxpxBzTUIrqROOWWM6qgqab1yd4Kl8p7LVTFR2ag7T9Tm3Uu2wJmz rtnTHYMVSUkgy2Ib3OjARKqq2omJtZ9neHsRMdaXqBqKGYH+00Dfbet4nZpZjen7rMoNVuus7W2z Q2xfrFeqdThwxNVRsTdbjZuOKPFAbFFM/wDZRcavt+a2W2a91wA61jSuABJUyjW1sn0r2fHq9caC ZWZRAwdWdjDLq9Tl6VIhjt8eWCJmugFEAHLUufFabp1TXzMrbsLmgca1lz5hgi3N1tieot5+x6hS VfqD7JuM0yuQgZefbb4mcR9ozyNtMiXQ4JonFOCKuE6iqqP+wGzFp6VLpb5dqyvfu1r+0W91v20L zk6hz6xSKhQZjyorxxDqLQE06qcFcZNNBFw1Colkirj0lLWiopXOuIBB5YdatsmZ2Er6UY8GuYm6 H+8qj62fyFwRRrd3+XFf/qG/79vFLUfl3cNq5Wt/Jv5OsJv2M/ltTP66X+0uY16T8uN/StP298m3 lPSq+qyRfeIgeQoHO57Xj+Tlp5vILxGenhny/b+PPPjnjnTIeeGXfzWrjTsv1Zvh3xEea30XqR1f 3gfNp/lCxfKvFP8AgdXgM/D8wuVnr72enLt44szPPZjlhCNl1yvT/qviOyQyxMPZu2J3sf8AjJ56 P128P5FyXNXL8Hq5uSaP0HexupfN5/7PZ3Kzp/1Dxf74ZIfx6ln2oaP4C7w8xFJvw8DUiLkqp4ks 8lxn9p/MHlHQ5cz7a9mdu/5Jlpbe8csreplCui0KpPSm0EKzRzpEsH4VMuOIzT4MmSbhjz0FsW2X PCOAoqushXtx65zpMXRB2wtwJPCK9OI2KMVODunEtGzZNLqdrzvPrppEul0+kUt4mxqfmLr0Jspm bjBlGf1FLYVQfEVQHDcyxuBlF7og2A7dm39Nii2AXm29pd0ZtR3JsilXfCt/zOrUV+tVKnxphjVS riSJMR6K7EJCYiHz3EeVcxRPiTEzKmUAxxbGAO6EI70DTaIrnuqvbq2HRZG8zVStan1uZTqJGqM2 kUdGp8pmZLfFkHHJGpo1RaSguly01t5ImS9kypcp7vDgYRN54h2qCSLVIZy3xbAVu6J152TFuDa6 PT5FRIbVluzSh12K4VJpySBTiwqy3GGmwJOXkPMLQI41NDHEANdB/H3TaetZWgcir2v21c9ClM36 NZt0Y+87YW1RPBR3jaqdOuCExHnyGmDdcdjJGQxZeJ0lPm5onbi0yY1wyEH1LTxQNnLG/kWBBFuK mt5bY7zVegsxp1ZotQj0FypTJVRpsByNUKjVrNc8pp4VCQnFx51sFGE4SoCaS5nf44ryZ8lriQDb Dmdaf1WTmuIRV6huPUbgqtOev6z7uq9qw7sk3lba02T4YHBjMv1ODKjPoCSmC5AAy+2Yo24Koi8c AyVktYQHZQD0f4QkxvxXHRLu3rrdJti7G7oops3LRrpuWBBmQFJhkbYqDMtzmtiotK4LjADDcH9C yKtrwXGT5clriyBsLRziHXbxoC6EV2Vaxt2oVwv3JCuij1i85diz4j1YhU+VHkVSKhRIubE5EFuT JdSW02zUwNCRG++nBFxDZ0otykHLmuwv2bLrkgY7k62/Qd525MChWXeVr3FOtuTOtusVtaa+Epmq 2/EekMUaoSpaAUlppH3FjSB7vMBFJV0CmNT3SIlzmkRgdx2/pxqYOuTdY1NuCm7jXIxuTDdu+rSd pWZFVpEcHGahMjkxGBqJJNdRlNbRtOfITMlUNSIqpljbOc0yxkMBnsOzb6Fi0W24LRWwzlEnXPc9 VpsNhyfJhwG6jW6TUZVSpMt4DeRUccmRIZDOVMnZWgVFzWjhZGRZ8ytzBrQbrbCIHpNmC3S71fGO ctqwRf3/AHq07/U1u/sjGPZ03/mH3XdJXRZ8HcVqvfLdKRtBZI3bFpYV906jEg+EcfWMOUlSRT1o Dns6ezLHmtOohUTchMLCVTlS85gs7udc9eUCRqxoYu5dxTqriii/GiRkXHdH223vnm/VWfJjFUPv BvPfW7rRldEhmJR6eDj0GhQEIIbTvLIeaamqm64iKqCZr3c10imeOxQadKpz6l52m9WJUprLltne 9M+lyuZJn/8AGYKrl8CeHVV+5jyenfPN949aoSviDlWBLUVBu+2lXgiV6k9v+PZx7Sf8N3unoXRf cVuzq9/l5bn+tqD/AHp48ZofxXe65cyTeUl1oIi7MLmmeVepKp6+cuM/t75ncVnS+2sj7BfzvsP/ ADYv2ORj0+qfKv5OsK7O9gq/+uzLwlgKqcVnVVEXL4Y7K5Z/cxxPtq+ZyDrVaj2rPmxDFRk712IF LRwpTVYR53l55jEaYdWSRZfJ5aqhevHb1QtFK+OHp2KzOIyFbk3eOOl/bNtll4s7tlE18PLGjTeZ l91Rx4+h+FN93/kFzmXFJ7inFb3z2aWXpTX9bAjKWWXiCprOnLP0qKGiYmkj5WdD+HSVkz2Hbk3d Qk/YunPW8/vTRpFZ5yTGqI83GmSG2yyaN8F8KQoJEiCqauKoK5di4z0ttW7MJDoXRu61MnP+1VLQ 9xui21qxCuShUGbS6xRXPEQ5jdPqupo9JApd41Fe6SoupMsdObRalMaWucCDxtW50ucRAqP73bvW Hu3e21r9llLfk0GvsJOelRHYv5mTNh8sBV1EUu82q8OzG7TtPm08qb4kLW4x2FZSpTmNdHBbux5B UE3w/wB5VH1s/kLgibr5oEq6LUqdBguNR5VRbAG3HtSNiouAa6tKEvYPwYr1ckzJRYLyqWoUzp8h 0tthPaqigbPbq06CNKhXazT6YOrKPHlTAAUNVIshFse1VVe3HIZptS0ZQ+A5SvOS9DrmNyNmgN4i 7sU+282ppVim5UXHyrFekioOTXB0C2JZKQtBmWWa9pKua/FxxfotPbJtjF2K6+maMyl9YnM87exR qr7f7vy6tPlU+8BiQJMp92LH8XLHlMm4RAGQtKiaRVEyTFaZR1RcSHwEcSqM/TdQdMcWzYAkwtdd zJ3seztyaJXhnXRco1ulCy4BREkSHczJE0lpdbFOHrxupaaoY+L3xG9WdPoayXNzTZmZsLonrCh8 jYm5n9tr5stahTfHXu3EbiPan0Zb5DyuHzV5epM0XJNKLxxZ0SQaSaXvtHFv7U0nSplMHhxBzQu3 9qgybEdTQM0piPeVnwgt86YcY40Fxl2T5MOmnhOdCHrkgx7QNuFp1d7LPHpPOU0ScrrY+m+Fti63 hvxC/YGxPUxTGWGoF32ZHcimwazBpypKklEB0IiynkhIryxkeMmFJMwLSSqSimBrKY3tdz/rt2p4 b8QvcTY7qdiELrt42ZWZYt09tZtWpy1CUZUl11+A+bj0JdT8c3zVt3LUnD8VMQaulNmV3PjftU5H 4hIlsH1JPwH6ZUrpsi4IM6OxGkt1emlP5oxnJDrThc6Gqc1DlvFzctWZfFifO0wMQ1w5DDr4lHhv xCaap0vb/Vpm4GKndtrPtXuzR2K6gtSQV9ugZJT0BUiZtq3kmpR9v5WM26jTthBp9WMN9+1QZTjt Ta/0f7zyYltQXrmtgou3yulboIktFjq9MGoHzFSJm7m+KH3/AEcOzGY1STEnKfWv6MVHguxUim9P nUtUSqRSr3tn/wA+gTqZUBaaktC5GqU1yovqiDF7rqSHnDZdTvN6lQeGNQrqYQ9U2GPMIY4LLw34 rt/gf1OeKYmLd9lE7HSX4htaaqM1B2cwEWTIqLQwhGU84yCNq458nPhxXGPnKbuu57uS2xMj8QuN OnrqNCkzKHGuuzKbTqh4wQSFAKO7T2qigeNYprgQs4jMhWxJ1pvgRZr2rjLz1NGOV0eXC6NtsE8N +ISs/YTqVqEOVTyu6zadCqceWxNZpsAoCPnO5PiJZeHhCiSi8O3k+OSjkulEzXECtpgY5Xc/63J4 b8Qk6p0+9SVYBwJl4WiyEqPUo8wYcNyGks6vHGJNlyUYhjzJbrIoHiS7w/JyzXEtrqYXNds9F227 iQy34hPNr9P287N03BeN3XjS5Fz1y037chVynLJblxnURtIz65sNd4UAkN0S197UneyxrmV0nKGt aYB0YFSJboxJVtbdWHd1qV2dOrtdKsUWRSoMSmU05UqUVPcBx5+Syj0nvPti46osPOfnuUgg5noR Vpz5zHtAAgY8/DmWxrSCrKxUWa+f250+FSesZmq1N9uBTaZX6BJmSniQGmWW4bCk4ZLwQUTtXHtK NpdpsBaS13SV0ZYjJ51ZfVhuXt9d+1YUi17lpVwVQa3Tn1hwpTb7vKbI9Z6QVVyHPiuOfolFOlz4 vaQIG8LVTS3B1oWMcesV5eHmkfZcZJcheAgVU7UQkyxIMCi+hW0W9O2u423kK27oqFMgVpimN0yv 0GqutNC+gNIw4YI+oi608iak055IuS8Ux4av06fInF7ASIxBHC9cybKc10QonNDpD2crUKrUyLS6 tdIymUp0aLMcqpQidcRvnrzXnWY4MousnDVFFE7vHJMWW/UalpaSQ3bZCPWVn/a8W3JPqd3N28uu yKFAtq6KTW5sS7aLMfYiS23jbjMOmrrpCCqqCCLmS+jDSKOdLmOLmkDKdiiVLcDckuqzczb67tqS o9rXPSq/VPN6a/4OFLbfeVpp1VM9IKq5CnFVxnolHOl1GZ7SBA3hZU0twdEhZy2C/nfYf+bF+xyM d7VPlZnJ1hWp3sFbi3uuzaukt0K1d3oDEu17ydkg1NlN8yNElRBbMCdUfzjWpHFQXg9lfayRc8eN 06RPdmfIPrNhvjwuXPlNcbW3pstWL00bPQpVy25UrcoozGUF6qeZjNlOM56kbbM3XnVFVy/Nt9uS ZoqpjbONbUkNeHHihBZO8R9hiqCqW/NL3D6jbJuN6Qlv7dWVJlNQJE8uQhc+K6j0x9C/R8wkbbbE uKCnHJSVE7TNLdJontve6+HLcrAk5ZZG0p26rd0aDVqjt3Xtt7lp9XrVo1GdOF+A+3JSM6gx1aV0 QVe4agQqK+0maY16JRPaJjZrSA4AW2YrGnlm0OCsWg717Ib9Wm3a25fgKLVZGgplFq73hwGS2nB6 DMVQRclVdBCYuIi5EnbnQm6dVUkzPKiRiOsLW6S9hiFwRtsukbbSSNy1SrUucUQ0cjN1Ws+Zg2ac UVuIhnzFT0ZgX38ZurNQnjIARyNh6VJmTXWLK9Rl2fO3piT7AZlQ7OnXTSn6axKbRo21cmsE8gN9 oNc1SVkS7yBkionZj0ctswUpEz2g0x5j6cVbAOS2+C+pOPnq5Sb4f7yqPrZ/IXBF5uGlee0Gp0Xm Ex5rDfio6DjjRCrzZAiobJCY5Z9oqi4zluyuBwUERCgMXba5Ga5R6kdaAQpdCZprsoDk+JB5uC7E IWQU+WTZuuDJUnMz1tinHtGwahuUiF5j6eAWOUxTcztBXPqvEphVdKZWqfUXZcR2FKmrFYZejtsP AoukpO89WyMxPuiTx5Z5d7M1Tc0YWQ4uH+FGQwUnuW07kuKyKbRJUqA9W4kinSKigo/FgTEiPA46 zkyquADiDl6fjTLhjTLmta8m2FvKpIJCjru1VxHb7tIfrXmBuUBimAKypkcAkNVI5oqjmb5q02BC wiGhE42OlxVQlxtFS3NGG2PogoyGCdWLLvsLrt64Xa/DGBb1NYpUujx2HmY8tt1n9dfROYSNmrwt EwORaQb06u8uMDNl5C2F5jHoU5TFNdmbWXPb1JhU2oVwJBQ6i7McJtyUamDlEdppd5wkzUnzF/Sq ZDl2kffxnNqWuJIGzrioawhOjFhXDMokCnV2bGceh2vNoEgGHZRtPPu+F5EpSNQPNPDkpZ95FLgX bjAzmhxIG2PSpymCVp+2aQahZ8tJroMWpTUi1OG1IkoxPksiJRnzbI1QlacN80UuK8zvashyh1RE OELzzcLEDLkrV7HrNQv87qYqAxYDtE8sa0uOJIhv5S85DLaiTZKvPD0j7PHVwwbOaJeWG2PQhbbF RmibX3nSIMphqdTY7zL1BlQgYkVHlS5VIeVyQ9L5pGQFMFUF1Q1+ymrmcc9r6hhNx24bcORQGFdl P20vSDLs+UlzNqFjtojsdQkGM9ya8fmKOkTvsoyQhG1iaiSau7jF1Qwh3q+16MP1QNNicqPYlwMs 0GHWagxLh27PqxPC25JJZ8GoMSG2xeQ1TIwJ9MxVSHIe6qcMsXzm2kC8DcQpDSuKlbRrCoVpUt+e fPtia87VjYkSwbqMV5TdJhxCcJTRXgjH31/5aindIkXJ1VFzjC+7i4WqAywJ5viyardT8vwlR8BE n0R+lG1zH2yQ35cd5XUJok0ry2jBCTvIpfBnjXJnBl42xWTmxUPqu0d5VGGsd6vR6hJWqViSEqQ5 MaJtmc0yzDfRI5AnPii1qyTSBGqqiiqquN7apgN2wYbL9xWBYU8ubcV9ateE4psaojdlPZhwn5Ts gXWTbiRYxKYMiOnM2DezaMe8qcE4ljX5hsGiFx7VllNql1kUGoWzbsei1SWNVmw3H+ZUtTpOzNbp Gkh/mkSo65nqdRF06s9OQ5Immc8OdEWLJogFIsalKMEVFb1dNFtbt1EbkjVB61rtBgY7s5poZEeW 03nyxkMEoZqGeQuAYkg8FzTLLradq76cZSMzejkW+VPLLNizvWui3damoR0aoUG4xTPSKOvwXVT4 xdbcD+njvS/uGnd7Qc30q0Ktu2KgdW6et76KuUqyZ81E+XTnY00f7F1S/o4uy9VpXXPA5YhZiew7 VCKla910UybrFu1qlGHtJJpsttE9ZK3l+HFtk6W72XA7wtgcDcUxPvQS/NSia4L+je0oqL6jxuAO xZJRlYwhpjq2IehG9OX4MQY7USiIPoRMQiEFE4oiJgisPYd1pjemxXn3AYZaqpEbjhIACnhJHFSJ URMUdTEaZ/J1hap3sFXv1v1SmVGHYowJsecTE2pq6Md4HVBCjtIikgKuSLl6ccX7bY5pfEQsCr0g vWP0ahsmrqA004vaeQiv38epiVdR4yGS6EfaMvxUMVX7yLhlKJ0p9Cr1VJApNFqlTI+A+Fp8p5F+ 622qY1umMb7TgN4UFwG1TOm7C7zV1RajWJVgbcyyOeDMNvJfh8S4C/gxVfqdM2943W9C1mcwbVOK F0Y7uzF1TW6Baor2k7KKQ5l/uxWlRf8AjxSmfcNOLszt3atZqmcZVjWn042ztVd9s1S+ai/e1YkT mypcGKw3Cpsd9sk0SHyedI3VbNRIAzQc0RVReCLQn6s+oluEsZRC03nkC1unlwMLFsbHmFSTdD/e VR9bP5C4InHBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIoxW/4f ZF9Y/Icvl+YeD/DzsWJfjftzborIZtirSve6ZmXnf8PtXytPlur+x44vyvqH7c/pW0eLsioLM9xH WvO+qurPj4fxWX9hwxdH1X+XoWwePxrj/wDwT/6D/wC6Yn/tv5f6qf7+NeC9wjSuvyDR6c/NMsT/ ANt/L/VYnxtqWh+4Tq/Vvqvnwz5njcvu83h9/GB+q/y9Cxb4uxTehe59mHk31A1cNHM8Bn/4jjit M+o/uz+lD4u2KsuifwryH6ufVjLhp8v8B9zLk458zx/35t8VqObbFTEdOlNGWjJNOXZl6MssVVgv WCIwRccvy7Ux4/kauYnhufoz5no0a/lerjiRHYpXZiFC4Yook+aSOIZGrWoEFUUMg4ZqvBc/iwRd 2CIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRf/2Q== --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/png; name="image008.png" Content-Description: image008.png Content-Disposition: inline; filename="image008.png"; size=341; creation-date="Fri, 27 Aug 2021 10:52:26 GMT"; modification-date="Fri, 27 Aug 2021 10:52:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUSAAAFEgGIfCirAAAB AklEQVRIie1V2wnCMBQ9FUPyqRPYEeoE1g3cwBXqBOoEOoJOYJygIxg3cIR+pvRDSUnhGtOP2lZB PBCSexPOyYX7CBgXJwAL9ANpBO49kZcY9EleJ3ADcLB7awwdggzAtMh1xrgYAbgACLuMQBpyc7D7 sW0ErkBsf15h1lbAl0UKwNmSx30IdApfFs3JUiSqyr+yvi2AcZHrwOzWfoWJgC76gHGR2ruU+CLG hbfyGReJy9e40IpcqyLXsuZu79bPW5XMuNiQX+6ca0WNxgI2jdfElThPrq0EAEQe0dp0/kqz+wt8 VsCdB2WOE7OaBSHxTzw8S5JJTx34N2ayt690AkA+ALsWRF/Krkd1AAAAAElFTkSuQmCCAAAAAAA= --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/png; name="image009.png" Content-Description: image009.png Content-Disposition: inline; filename="image009.png"; size=480; creation-date="Fri, 27 Aug 2021 10:52:26 GMT"; modification-date="Fri, 27 Aug 2021 10:52:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAUCAYAAACXtf2DAAAACXBIWXMAAAQ8AAAEPAEZaCRCAAAB jUlEQVQ4ja2UPXLCMBCFn5E0UpeUSQddSnKCcAS4AZQp6ZIq5AZQpoIbhJwgpEsHnACOQDppxE9m M2vGeGRsTXgzHkvy+lvtSrsgKW3qiBDZK23elTaHzDNX2rRSitKmq7RpJzyZAxh5ZydlbpQ2TQCf AK4LTGYAmjxupA4OvND3zg5LHKwAVIn4FcBV3gFpCqDnnd0E4C3efVV1agHDNoCV0magtMmnoVUR vOFNTgXNhJSUs7uMgWHYE30TUt4KKQ2npoqTb+9snwYJ77JecnCxmnpnO/RPjeFzDutSWqacmnd2 wfCoWijR+uiA36MLwsG18KckHShtxgC6F4AvvLP36UQcB1Iu+ZCbhb9W0/N+t12EIogtopDW3tlG dv0YwX63XQsp6/+MoEOcoAN28iGkTCIqNquhd/Ytv5iELLn4xtw2qmjine2F7JIAmKAvEXVRCAe3 igGABwbGFBvlmto7dd9Cif1uOxNS/gC4yTW8c2Dq9Y/cBc4qlCI64PQmUWRfGfDMO3tyS84KwC/b snjTWCpZ6gAAAABJRU5ErkJgggAAAAAA --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/png; name="image010.png" Content-Description: image010.png Content-Disposition: inline; filename="image010.png"; size=295; creation-date="Fri, 27 Aug 2021 10:52:26 GMT"; modification-date="Fri, 27 Aug 2021 10:52:26 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAARCAYAAADHeGwwAAAACXBIWXMAAARkAAAEZAGL13mEAAAA 1ElEQVQ4jbWVvQ3CMBBGX/6UlIyQEaCjI4zABrABGyAmYAQYgRHCBGQDMkJKWy5Ah4yUBmGb+Gss y9a98/nzOQEoyqoGDoCMc2BGmAagA3rgaLTqExv8/kfQbxLYIsvy/AQsJw4uqiTp1JYllmop0TMi gNRxn1zcJSZgMFrt5NKANgbgLaNVZ7RaAxtrxWkBI9DVnuYnJAhQlNUeeLg4MPcM3ABnH2u72rSz L7PxScgHEKzU13aealNXuwUqfjcd/wdbYGUXZe7bBKUSn2rcpLUYrfoXGVA0JYXp1vUAAAAASUVO RK5CYIIAAAAAAA== --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/png; name="image011.png" Content-Description: image011.png Content-Disposition: inline; filename="image011.png"; size=461; creation-date="Fri, 27 Aug 2021 10:52:27 GMT"; modification-date="Fri, 27 Aug 2021 10:52:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB eklEQVRIibWWMXKDMBBFv0EaKClTkhu4TGlO4BwhdGl9EvsG9hFCmQr7BjkCR6CEwXYyy6wYEEKD BvIrW5bfF7t/NWxgkQzCdwB7ADsAsbazAHAFkDV19TVFMRrIICTg2QCdEpmlTV1d9d89A/wIIHeA g/fm/N+BfA1Op/50AOt684WIn497ptY7A3Z3gVM5SgAv2vrWFyJ6Pu7fUD3gmuczoCXXetBUGYQ5 B6GvhHqienCeCU9sidHUMgVHcU5DL01d/fROHVE5+Gtk2B8TW3DO5+imwfOewZT2nqF2Uyp769sZ cNLOc8y7q+LRoK2tjQzCXwszMY2/Lhtj8RPIILT2wuOLaolsPSwEj/zHxIajDEKVnoOaAz61uths BlcyyCwG/cePtM9z4p15PPpLy2RSQWzV5PQfDFpma8BRPK0IP6l4dzFt6upAF9oK8AuzAH0OmrpK Fz4JnXxQ7tGgsXvi2HjaS1PfnVyJYjoS1+9Ve20xQe2vLQD+ALaKgDHuS7cwAAAAAElFTkSuQmCC AAAAAAA= --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/png; name="image012.png" Content-Description: image012.png Content-Disposition: inline; filename="image012.png"; size=497; creation-date="Fri, 27 Aug 2021 10:52:27 GMT"; modification-date="Fri, 27 Aug 2021 10:52:27 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB nklEQVRIib1WwXHCMBDcMHjspzsIJZAOoIN0AKmApBQqAHeQDqAD6ABTgf20xw8yR/Y8hywRCE52 RjMgnfZOq5XkJxhEcTIBMAPwCiC1YzegBPAJIGvqaqvhbYIoTlYA5neShrBu6uqtTeCQayVHANsb CWXlz87Kv5OILFGcnNh2UZzcK00LmUsO5ZsMqLlWPm3qqvwF8UYIAbwLB7lw5o7ipGC21Q8kI65W 2sj0j03FJ/at+L8YGM2OAWIh3AE4ANiwHSjFpKmrPYA9w7cOVwqrl4d8bqsLtLmuxCnqHD+8Iokk VNlE06WpUMYWXL3IkVvvu0TeFRg3FLY6R3vdv51H1jPvIJBUNlFJl9T5Auxbsm9sN97CmwCADb52 2OzYXQl6QyhBbn533BUYy30B3gRNXeXG24vQJtNJgj3ndBC0KYAPHiqxolwFIZtqrB99HTRnntem nQRNXa15eXVsyr4pY1y0XEOe0pT3eQc8oS/0uVoxD2lOKFd5cfM98hYo+Ca0N7RIlHFMN/OhB8cY Q5D9+ZP5P4++SdLvZwuALwyUvZfl03noAAAAAElFTkSuQmCCAAAAAAA= --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_ Content-Type: image/png; name="image013.png" Content-Description: image013.png Content-Disposition: inline; filename="image013.png"; size=5361; creation-date="Fri, 27 Aug 2021 10:52:28 GMT"; modification-date="Fri, 27 Aug 2021 10:52:28 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAXEAAAAuCAYAAADeKCkyAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAAIdUAACHVAQSctJ0AABSDSURBVHhe7Z17kGN5Vcezr+5O7iMz3Unu7Udy MygoUJSUCFuAuIAiWLhsKTvOTHeatSxFKBQpRSgf1PherC2FeXR6sXzVAoUvEF1h/1AKEQEXRQXf YIEotWKxvpZlV9l119/59Tm/OfeX8/vdm04ynQz3U/WtyT3ne04607mnb27uo1ZRUVFRUVFRUVFR UVFRUVFRMRUap/deGO3uP+oS2g5NOBg+JPUF1Qd7f4A2J1IdqDEY7mnDC84tS/lpSPdXSLnDKNjZ vwNbikg1E2mw9wxsPTWa7a3/xYdTJ+70/+7Y+olHbWFaJOpk/yLVxMnW09CSg/K4OALlm63+gxji XMfqlyEQpSd+gMUMFLPjRFE+TrPf4R5So9VbR0shUj1XrbYWoVUjebiiNPsNtI7QTLOPSzVBkj0H LQbJxxUl2S+g1RCn/e+mPIa88H4uoVXjyxFxkt3GPc2kfxemiCWeJ8VJ/+cxPxtWTu/fKw4AFNoO jdSTC21OpBrQIg5xLmydQ/JNpAUa4tKbnwttOSQfV5T234tWA+VwcQRejyFD1O79s50rM8TjpPcP GDbwPIYMPCcp7PReilYvUq2tOOl+G9pL+UFoN0gerrDT/whaNZJHEto1l3uIqz+iP4Ipg+2xhrj5 A+8S+qaPuPIzNXaGf4jWsVnZ3n+m1JMLrU6kGtCiD3EQtjdInom0IEN8qbXxOHqjR2vdF2G4trSa Pt61EjTT/v9RPFzrfwHDtZXjG12r5rqDzAEsLqL6vs3loTjPlRnidg5w5Zpp724pFyW9F0pxHy6/ GlAvk3JSDAiSpMNzofq9YKoWr/UfpLjaGn8Iw7X6WneD16jQykHG83PFW6tWrnGQOfwQV3Ufgp9f Elo15OfClMHO8yHO4xjS8Hicdn8Jw9NFXPktoXVspF620OpEqgFdCUMchE+hkfITaUGGOH+jY8ig htftQdr/FC4afDWAK++rIcizcizNMKShON+yLDvE1R+HhzGl4TkMaVxxoNHqfTXlwqT3Ggw78fVS nw7eaed8foByYWvrnzBUuobnpRiHcmHSfwuGDj/EO9kfYcgL+bkwpWk2s2N2XhriQZp9HkMGiMdp 70dxcfqIK7+l2k1vOIb2sZB62UKrE6kGdKUMcRA+zZfsEI+S/l/QStBIe7sYdgK7E8hfU1tvGM5B ee1hSDEbsbbdDqXaoiGu/gi9kuXNliXFME6YfarB2uazMXZoHM+hiTrZ0+2czw/Y+aDTfR4tu/bV 809MGCr9PEGyYXb1HPUQj9v9v4WYej2PUL7MlvjsufGNibjyC8KK0gQ7ex+U+thqbA+9f6GkGtCV NcTPXj2T51mcfeJX8ZUAZG8Fc7gPQyPESf+PJU9RHUAe7oNdBVJt4ZZ42r/FPGYeKRanm5+1Y5Mg PQcBnwzsnM9/XXvjyZSLO71fhZjPT4Rp/622x1fHhySGNEcxxMNO9qeYNvmwvfliesyHuP0Fe5B2 78PUbAm2h3eJK78gLCmN1ENSODj/CJaISDUgM8QLkGpJaClEqgUtndl/LFq8NAa3v0Cq5wKfFCfp RnPArL7YDNu9Z/KVgNRsZx9Gi4HnMTRCM+k9V/IU1QHNdu81to+W7doyQ5wvx0n3VC6vBMtAs7X1 P3ZsEvhzwBEfIPXH6E4eB6E951fD9B4t9fvmcRDaxddgA0cJ+epcUrZrDtwHHHaIS1LD9wfRZuD5 qN19CT3GtMnzx3yIAxS3FXS2noSW6SMNC5eKtphzbN96XOrhElaJSH7QIg1xQupBKpOfB2Y1xAk1 OP5RWhFU6qoDR35lwdAIYZi2JU9RHXHJtxrzZTXgf00bkLJDPG71H+A+k8dlgA9MDGnU4P0E90se CanGlrLpT4GAlLelbEsHbvk1jNBsmn3JGCn1PFGavQftmss5xPkyPK53ui+ScvYQR66mvC3MTxdp WPiEZYXA1rVU7xKWiUh+UDXEj4ZZD3EibHWf5VoJpJiN2ur8MclTVEeQL+5031VbOd5z1ZUd4gDF 4iT7gMkrYdq5JT6LIQ5Hu6DNIPm40Gbw5Yig3XuF7fHVwZfGlAs6vVsxfFl3p/BleEy7eNSnO32o KOUcQ9xAPpL6vX8GU9NDGhY+YVkhUq1PWCYi+UGLOMQb2xd3pT4gyEtxkm4wB1yuIU6oLdh7aSVo tDeeDDG+ta5NApS3PUV1BK9vJO7nG2eIq63LXzdxJkzXgnTzU3YMUH9IXqaG0Q+DpDoX43gBl59i MMwwpInb/b+R/Bw4ksX20LKrTspf7iHewD+c6jXzL2b1Lh5aLhriBPmxxzQ5e7U0LHwKT537Nyx2 Emzv/7JU61NjZ29kq4CQ/KBFHOLB9t4pqQ8I8lKcpBvMAbMa4rBPfLnZeQwu5qAVQA2Nb4TllePr ZsvYdeIL5UEY0kgxCbUV+PW8h6tunCEOmDgTpjQUaybZJzCUw1UnMY4XcPnVQPs8i197ENWsUDzq 9H8GYzkoj7UaKcaR8pd7iEfRxhqPURygZXuIu56riUe28B5TIdy++F3SsCgSljuRasoIy0eQvKCF HOK7wwekPiDIS3GSbjAHzGKI0xtcfJNHkVmZasePdzHqrQnT7DzlQseXT7johbykKMl+ElOGcYd4 kGw+2+RQmNK44gDfZy7lbcbxAj6/K+eKA2Gnaz458GPrfTWAlL/cQxzgMSluhnhw6WSoeH3zszrG oBwIQ9NBGhRltPTtnsF1w3uvlWrKCDuMIHlB1T7xo2EWQzw4tvUk/kZXK+yHmusnvpNvwYDQrlle 23wOzwVp/37pOipoN9h5W7D/Ga3SSmy+XCXGHeKAyaEwrIHT4HkOXlec9D/DYyQscTKOF/D5Xbn6 6qWjT0DxWv+Bot+DnXMpTLqvxZLcEHcpSvu/iPZSz9FM+x9Au/j6eEx94jMHdlCMb4lzLyhOsh+K kr45R0DH0v5fo306SIOC1NgZvl+Kk7DFCJKXFJ4+/6AUJ2GLESQvaJGG+MqZC0+X6rnAJ8VJutEc MKvdKY321vP5G96WspijKIgo2XqT5CWhLYfk4+JDvJFu/hfPYTjHYYZ4rbZVN3mrDoALTfE8V9ja +jp6jHYnvA5DXnx+frSPnY/S7s/ynC20GSSPLTgBDO2aoxjicdp7nR0DKGbvTmm2N0cOx+RC2/SQ BgWpTF5C8pJqJ88uSXESthhB8oLmZYhH6ueQcuOo9pSX6ut7SDlS7Xm3BWNrBsxqiBONtHsLbH3C m149vk9t1X0/ppyoj+rvol0NzVb2ufrq5hamRojT7K+8Ur3QWguOJ0+keJT0PorhHA01pMmDIY2p 61y6FgyH8nYdB7bcaADAFR4xbGpx0UmZ5+AU+YvyavC+g46wabb69y63u1+GqRy8DxfscgmS5Ilo yxGmvZNSDVeQZD+Odudz5JRkb0a787X5YmqI72MoR5T2PkpfiOIlCkY2QKaCNChIRflwd3/kl1g/ vf8tkpcEHilOWj49fK5uZCF5QVfUEEek3CTCtlNl1kO8oqKiBCtn9m6QVnoSeOq7t3+vlCPpRgzJ QwoGF/4MPMHp4SelPCg8s/eXupGF5AVdKUMcn0Ij5ScRtp0q1RCvqJgDgp2Ld0srPUgNR7MDX8qT Vnbf1EObRvKQ0FJbunn/CVKehLYckg90JQxxbG+QPJMI206VaohXVMwB0gpPggtKoa1wqKCtFgyG H5HyJLRppDwJLTkkH2jRhzi2ziH5JhG2nSrVEK+omAOkFZ6EFs3Kqb2u5CGhzdsvOLP3fWjTSB4S WnJIPtCiDvHaLb9iLo5vI/knEbadKtUQr6iYA6QVnoQWg+QhNXaGb4cjK6QcCdsYJA+pdvJsiDaD 5AMtwhAPz1z8dGN3+M3YphCpByncGb5uXGHbqTJPQzxqbTwuTrLTzfTESbWYu4PPohAl3RvhNYxz 78yKS4Rp7wnw/xe2ey9Wi/xs0isbaUiApMvChmfOfUHyknwXuxL77Z5/WPKCgt3hn6DNIPlA8zLE fXmQSo+cIOJCqieh5ciZxRCnw+h8itdPvA/t5roWklbYWZ1AM+n/lOTjUrbSvyNC6DEWdj0p6nRf hZYRbC+Gc9geSREeuy7lbIXr2VeW9YKvCONNktwhsL4+Utx1AhQIzvJFm6aZ9n9P8nEpW+49YOU8 ZObSAy6hUUPLcL9W+Ff9bN5LcYs0ti/+ljQkQPXB/t+jLYfkLaPazutHjtetb1+8SfKS0GaQPKB5 GuKAlCehpRCploSWI+eoh3gj6f+nlOeqr6VfoxsrygxxENpLEXR63zBJvV1rq5n23obWHLZvOUlO YMpgeyTNaojDsdHg9UFeNYTfgSEN74MhDdxk2o7DPVW5X1IUbXwF2ksNcRDaNa74KMVDHIRm3Rf+ hSGuPkF8LGr3C+9kNUJ4+vwXpSEBQssIkreMsHwEyUtCi0HygOZtiNd3L7xK8pDQ5kWqI6HlyJn1 EMeQi2s93tzKhLHcEMeQIUqz36dc3OmKGzASVMOFqUIa7c2vYjW570e8/cKwxfMuny9nQ74g7X8S Q058fX05G8kbJf0hj4dp9+WYkvzmFnYspoGbH0s5PsQxZFDvgY9RTv1h+W0Mj/GaLg1xDBikM37p Xz3ED3savjQgSGgZIRjsv1vy+1QfDP8by0eQ/CS0GCQPaN6GOBAOhg9JPlA4OKc/PvmQ6khoOXKO cogX+eACVSbfaOl9zL4hDlDOlZcgf9zKPkeP4QxFTHtprmdvphoM2YhffFMNKOr0b3X14D4MOSHf pENcfTRJTK+kK55xSaiB+q92H1rmwpTJhe3up/ky93DCJHuLyYfrLYj5hjhAOZ6XYjLuIQ5YfaZz 5qY0IEhoEZH8PtXOHtw3UkLyk9BikDygeRzigOQjLe9c8N78VqohoeXImechDlCePtrPcojXVldj frEnTHsJVvO7YjBciF3jqrd9Psg38RCvrcamV8EQh8sN231oGS6X4MqF7exb+TL32FC+mW7pS2cf 5RAHKB+rrX4MTYL/GuJoEpH8PmGZSDhwf7lZ39l/K9o0kgc0r0O8dvPP1SUvCV0ikp+EliNn1kMc hq4ttLGVc/RynwTvBctQz5c5caf/bsrxm+L6aLIaWF6KNh/Ll8tAfq5w/WCr0QX5grVMbwjQsvoj 8pvagFAcZP8/gtCmIR98z2D74EYUaNPwvhgy+HIStpcv88fSLfZoGW5IgaERyEN13t0pSf/PKQdb 8Rge6eGm/BAv7lWC+uDi9dKAADV2Ln4cbSIrOxdukeokBWf2cl9a2AS7w9+V6kD2ES2SBzS3Q1xR 3774HslPQtsIkpeEliPnKL7YRNulFdizRWPXwUDiMZd0cQmkGloO060bMFQI78O1tLauv0jkqK3Q l1MeQ+LPAfC4JLRppDypmfbuRptG8thqJptfRLsX8kftnv5Sj5btx1GSvZ8vA7TM91/bkIfq+BD3 SRcjrvgol3mIS8OBFO7u34Q2J1KdJLR7kepIaNFIedA8D3FA8nOhLYfkI6HlyJmHIe66oiBg15UZ 4rqwJFQTpNmdGJpkJV3mtaSm9amA5zAE1x1/rR0DuFcS2jRSnjTuEA+S7CfQWgjVwCcA++gTk2N3 nKccQMtR0n07hkaw68oMcV3I8OXyzNEQR4sXqU4S2r1IdSS0aKQ8aN6HOCDVkILB6KcVyWe0vf/q cVU/fWEDW0+NedgnTl9ySdi9+BDXBsWyClJMDZE3YrgQOHTR7gXEaf8eKT4O/GO93aco3ljvPQVD pf8vAfIddp+4FCtD3Om9j9eCYrXVDTk4agOW4WeiHP99U8z+I8MhDwiWpd0p9bWtp1JMvQe+B8MG yvEamQUb4jU1FKRarvrOULx+so1US6rdcNaceSXlQYswxJe3h4+R6kgr27dlaNVInok02HsGtp4a V8oXmxSz4z6KLvoPUrZJzhw1N4uI0x6d+HYN7y9JDbz70TvW62L1h/5ik2LNVv9BDBWycnyjy/uB orVLx3Xbufrq5vWYKvX6KE/fnbj2iVPMjgO+XJ7CIX4V5e0bXRwKcUVHoaUQqZYLbYVItaSVwd5L 0Ob0LcIQB9TW8H1SLQltGik/kb7EhniY9N5g8sePNyHmGuIxu5NQkPR+GsNeyO8T7MdFuxM1VB5R W5734GIO6kP7/eN2Zu4o75MuVkgxF+SbxhC340XwOru2bA5DOYJ2dqfJt9v6Mh6uIa62wF9B8UZr 6zswrKG4XTOKf4iX71OCpZvPjX0ZWIng1PB+qR4UDs49jLZCgp29D0o9SGhb+CEOSLVcaKuGePEb PbdVijGDlHMNcUDye7iavEHSfyXGDGV7cR+c+INhTdhe/1rTA09L535tYoTt3s12zue3Id8kQ1xh fidwf02MFcL7gTCs8eUU5oQv+GOIsQPirVWpzjXEAckPuOKjuIc4fEIq36cEwc7wneKKrqQGauEt sDhSD1Dt5Ov11k8Z6jt7T5V6kNDmfK5FGuKAVM9VxjO2rrwhDiukOVnEJbitGtq9QzxIe3dTrp50 b8SwiHSkBAc+uvvyHPL5hFbjjZKu+FGc8mGS3cGXQdrggXt9sr26mOHLueA1dp0vBzTSrdyZkJLg ew+0e4d4vdP/D8qttLrPwnCp/5sD56Uh7tOBd0LElRzF90GXQeoBwnRppB4ktDg9izbEG2eGz5d6 kBqDvVdL8Yl0BQ5xgA9fW7UwbKNN4xviQK7WQwlfSPmotflNGHPSTLOHeE8utNQidoQGhkaw6+xl H9zrk+3VxYwwvfSJQMpL8JtBh+3swxjWhEnvLsrV29m/YzgHv/+oLZXOXQ3VN8QBq1bDYy4dOP1D PG6V/3RSzM652KlxGdwRTKWP1INESDnQDWed1+XOIdWSyiLVgmqPjnf1O6nHLHXy5DX4zFMDrk+B D4+cRjtLo6R/fZyceJpanPprvRwst7e+HF5DuJo9HkMVY1Bf627o90DahYuezeaGxBUVFRUVFRUV FRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRXzSq32/7zr0aZSsOu7AAAAAElFTkSuQmCC AAAA --_010_DM6PR19MB393037F556C69BDA24410C15FCC89DM6PR19MB3930namp_-- From nobody Fri Aug 27 06:40:00 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0723C3A181F for ; Fri, 27 Aug 2021 06:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 pHvL3m2NDv5E for ; Fri, 27 Aug 2021 06:39:51 -0700 (PDT) Received: from mail-ej1-x62a.google.com (mail-ej1-x62a.google.com [IPv6:2a00:1450:4864:20::62a]) (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 8969F3A1817 for ; Fri, 27 Aug 2021 06:39:50 -0700 (PDT) Received: by mail-ej1-x62a.google.com with SMTP id ia27so13893568ejc.10 for ; Fri, 27 Aug 2021 06:39: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=iics9+RpAV4zHXrYgvC8uUMRMSqGRPaYitfyzfGX/3o=; b=bsqEA4tXaeaV6tBh2fyRP78/KB9PrWxq7YOkUFZ7ZQ0IvfGVTi3CMTCahzdSpkc/Ae q7r9ttN6UpJplHzvzGofbbO17L5vEMCDq9aTOAh42VXHcJnYx9C58W8SYAA9gkx+F4iz dimpd8cKiQS5yQQ7fJrcgQeX7zCaQ85otAVail4nimOau+HpA5q1CXGUnMIBr544vUC8 VTLUteDTJt3oN+1Pol1i/ieHALg55i6Zp9IPdAJBuX2e4YyP71aY9XoTBSktlsQT6nKj RFGuf6rS4vEYO7Buz+3FrFf6KK9BszuZeXXfvaByKWKon2zm5tJosfjNFIsUkaXWbnON Z/Dw== 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=iics9+RpAV4zHXrYgvC8uUMRMSqGRPaYitfyzfGX/3o=; b=uBdM/PfQR9akYUo033cqNBBJaSdC/bJWku0D/hL5haa5TApTROReTrHHrdccQZTh+p F0HRbS+Bx8RRxgO0y/0n61aI1BITISdtDLwqhFNrV8LDUy+ohnYeJLdWQXU8lfli68Dm qRWcMCahAzipYv90Vo+lnK5ew02xKy6s+KfGgzs1AHy20YYr6iIijGnmIuX/4fZFhVXa 0GDLIDZq26P5/qHd/zY8pJzwu/ShcTI8wFh4AaqGIcNAdEm43LWVqvmNMoWQJmnyKNQ3 M4/H2VeEhMI2MT2ihyM/rlc1QbmD3D9VBECGfNPZMU875LDb7h645VDEZbhW+/pNlzOg PZUQ== X-Gm-Message-State: AOAM532vV51/hOkppJPHD23cJxMxS58m/67nUOree3nEpZ6C09vHRiwd lij1yw+qYw18nwAuSSNzBxCRxDm1vQpc7Kxmq9Y= X-Google-Smtp-Source: ABdhPJzNo/R/iKPraQSKqPHAI5v5ITRym3vBcc1yw9/hbNfIF5wkRh7QuSE2VG5yJSLMgW39TzJE90srqa+xbZ7CDB8= X-Received: by 2002:a17:906:7fc4:: with SMTP id r4mr9451062ejs.75.1630071586828; Fri, 27 Aug 2021 06:39:46 -0700 (PDT) MIME-Version: 1.0 References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> In-Reply-To: From: Roger Slusser Date: Fri, 27 Aug 2021 09:39:35 -0400 Message-ID: To: Joe Gruessing Cc: "Olle E. Johansson" , "Christensen, Eugene" , "rum@ietf.org" , "Kyzivat, Paul" , Alexander Ospina , "Roach, Isaac" , Brian Rosen Content-Type: multipart/related; boundary="000000000000e4aeab05ca8a9df4" Archived-At: Subject: Re: [Rum] Action Items from RUM session at IETF 111 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 13:39:58 -0000 --000000000000e4aeab05ca8a9df4 Content-Type: multipart/alternative; boundary="000000000000e4aeaa05ca8a9df3" --000000000000e4aeaa05ca8a9df3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Joe, In a pure and perfect world yes this would be the case, we have been at this long enough to know this is not the reality of how this will play out. I have read ahead, I see that Ed Sayers addressed this much better than I could. Roger On Thu, Aug 26, 2021 at 5:48 PM Joe Gruessing wrote: > > > Isn=E2=80=99t it correct that the motivation of this document ( i.e. to = create > with best practice the =E2=80=9Cright=E2=80=9D type of client guidelines = through consensus > and current art) is distinct from what the FCC decides to do with the > written product (whole or in part) and how it relates to existing industr= y > tech? Shouldn=E2=80=99t the question at this point be focused on whether = this > document properly captures the IETF global interpretation of how a RUE > ought to be implemented today and not whether the government agency will > enforce mandates and how? Those are related but separate initiatives in = my > opinion. > > > > *----------* > > *Joe Gruessing* > > Infrastructure Engineering, Principal > > Group Leader, L114 > > > > Office: (703) 983-2075 > > Mobile: (703) 347-2402 > > > > [image: LinkedIn] [image: > Twitter] [image: YouTube] > [image: Facebook] > [image: Instagram] > > > > [image: MITRE | Solving Problems for a Safer World] > > > > *From:* Roger Slusser > *Sent:* Thursday, August 26, 2021 3:30 PM > *To:* Olle E. Johansson > *Cc:* Christensen, Eugene ; rum@ietf.org; > Kyzivat, Paul ; Alexander Ospina < > aospina@aslservices.com>; Roach, Isaac ; Brian Rosen > > *Subject:* Re: [Rum] Action Items from RUM session at IETF 111 > > > > > > > > On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson wrote= : > > > > > > On 26 Aug 2021, at 16:17, Roger Slusser wrote: > > > > Hello all, > > First off these are personal comments and not as a spokesperson for the > VRS provider I work for. > > > > I have to agree right down the line with Eugene Christensen. I have been = a > part of this from day one and have been directly involved in the setup an= d > execution of the bi-annual Interop conferences and development of the > Provider Interoperability Profile. > > > > It is obvious to me that this RUM RFC will be picked up by the FCC as the > new spec for the VATRP. > > Roger, > > With all respect. There is a world outside the USA. RFCs are written with > global scope, not limited to a specific market or group of vendors. > > Olle, > > I think you may have missed my point about this targeting a specific > industry, namely the VRS industry in the US. Also when the FCC mandates > support of an RFC they do not specify custom profiles especially in this > case. There may be other uses for this out there but none that are direct= ly > or possibly adversely affected. > > > > So let's not kid ourselves or mince words about implementations, industry > profiles and various services. This endpoint spec will be terminated by a > VRS provider Interpreter station or proprietary endpoint in 99% of the us= e > cases. By mandating via "MUSTs" in this RFC, and there are many, it will > force the VRS providers to abandon current project plans and business goa= ls > to turn attention to implementing things in this RFC that have very littl= e > value to the Deaf and HH end users we support. Every provider already has= a > notification scheme for message waiting, most of which is much more > elaborate and sophisticated than MWI, yet this RFC will force less > desirable services... why? This is just an example that has been objected > to since day one and yet it still has stuck like glue. Let's not lose foc= us > of the driving force here, the betterment of the endpoint experience for > the Deaf and HH user base. > > I think being able to get privacy and be able to use all networks, > including the old IPv4 networks, is a good experience. > > > > Most providers already support encryption and IPV6 on a limited scope, no= t > necessarily the way it is defined in RUM spec. Mandating compliance using > MUST requires providers to discard sometimes huge amounts of development = to > change over to what RUM is specifying. The push back is not about doing > these things it is about the loss of time, effort and money to do them in > the way RUM mandates with MUSTs. > > > > > > I understand this is IETF. I understand this must have the latest and > greatest tech the industry has to offer, but I think the driving committe= e > members of this RFC also need to understand the realities of implementati= on > and the hardship this can and will bring to providers with the "MUSTs". T= he > FCC denies funding for non compliance, the reality is these "MUSTs" could > put providers out of business. > > A MUST in an RFC points to an implementation. It doesn=E2=80=99t provide = a profile > for a service. If a service provider only provides IPv4 that=E2=80=99s ok > (depending on the customer requirements of course). But to be RFC complia= nt > and interoperable, an implementation has to be able to support what=E2=80= =99s > specified as MUSTs. > > > > I know there are heavy hitters in the IETF community on this project. But > there are also founding members of the VRS industry who have offered > comments with reasonable explanations that have been dismissed. After 18 > year I believe we know our customer base. The Deaf employees in our > companies in marketing and sales collectively drive our product offerings > to best suit their needs because we eat our own dog food.. I would urge > this committee to take long and hard consideration of the experience that > in my opinion is being dismissed offhandedly for the sake of new tech tha= t > has very little to do with our customers needs or wants. > > IPv6 is not new tech at this point. SRTP/DTLS is implemented in millions > of web browsers out there, with many implementations in Open Source. It= =E2=80=99s > not new tech, not at all. In fact I would be surprised if the US FCC does > not require IPv6. > > > > I have been working with social care alarms as well as telephony for deaf > and hearing impaired. The users don=E2=80=99t deserve old technology or a= lack of > privacy. If you ask them it would be assumed that you work on all kind of > networks - mobile, wifi, fixed and they trust you to give them privacy. > They won=E2=80=99t specify that in technichal terms, it=E2=80=99s just as= sumed. > > > > /O > > > > I already addressed this earlier. It is not that we don't provide > encryption, we have settled on other methods. We have been supporting IPv= 6 > for some time now on a limited basis. > > > > Thanks for your consideration, > > Roger Slusser > > > > On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson wrote: > > Friends, > This is the IETF after all. > > We can=E2=80=99t let any documents be published without IPv6. The problem= s you > outline here are surely solved in existing implementations of SIP, propab= ly > since many years ago. If not, we have work to do. > > In addition, RUM services without SRTP/DTLS will be used over any network= , > including the Internet, and it is a very bad solution that feels like > something we sold in the SIP world a long time ago. The world has moved > since then. > > I strongly urge that the RUM specs has to require mandatory IPv6 support > as well as SRTP/DTLS encryption. > > I would personally go as far as to say that SRTP/DTLS is a MUST and > nothing else is ok, very much like WebRTC. > > In regards to proprietary vs open standards, this is again the IETF. We > produce open standards and a RUM specification has to point to a SIP > SUBSCRIBE/NOTIFY package for MWI. > > Remember that what I=E2=80=99m talking about is documents as specified by= the > IETF. Industry profiles and various services may go other ways, but the > IETF standards has to be up to date with best current practise. > > Cheers, > /O > > > On 25 Aug 2021, at 20:58, Eugene Christensen > wrote: > > > > Brian, Paul thank you for considering the changes that have been brough= t > up to this point. Leaving things alone with the X-Card, the inclusion of > the instance-id for location, additions to support notification services > for mobile, etc. are all appreciated. > > > > It is my opinion that we should not include requirements for the > following in the new RUM document. Here are the reasons that I believe > this way. > > > > WebRTC > > > > * While there is an RFC for WebRTC, it doesn't appear that all browsers > are following it. For example, TMMBR is required for WebRTC but Chrome > does not signal it. > > * WebRTC is an audio first implementation. For VRS, video is the most > important media stream. It means everything to the deaf or hard of heari= ng > user. If video is suffering first in a lossy network, that is a problem > for VRS. > > * Some of the VRS providers do not currently support the following > items. This could pose a significant impact on the VRS providers to get > this implemented. > > o Encryption (DTLS) > > o ICE > > o RTP/RTCP Muxing > > > > IPv6 > > * For those VRS providers whose current implementations do not support > IPv6, this can be a big jump to get their solution to support both IPv4 a= s > well as IPv6. Granted, it does not require being dual stacked but rather > could be two separate servers, each supporting their respective version o= f > IP. This could be a big undertaking just to get IPv6 into the mix. > > * Another solution could be an IPv4 to IPv6 gateway but that doesn't > work flawlessly. For example, the gateway can forward the IPv6 SIP messa= ge > to the proper address on the IPv4 network, however, how does it resolve t= he > embedded IPv6 addresses signaled in the SDP? So, for example, consider t= wo > RUEs, one legacy RUE that is using IPv4 and one that is IPv6; the signali= ng > is possible for both once the servers for each support that or provide a = IP > gateway between the two. How is the media going to work? Each of the RU= Es > is going to provide an IP address in their SDP, one will be IPv4 and the > other IPv6. How is this going to work without having to anchor all the > media somewhere? > > * Are there issues that we need to resolve with NAT64 and/or DNS64? > > * As I understand it, some mobile devices are already IPv6 but do not > follow the RFC for embedding an IPv4 address into an IPv6 address. This = is > going to require special handling to get this to work with such devices o= n > vendors that do not follow the RFC in this regard. > > > > Message Waiting Indicator > > * Some, if not all, of the current implementations of RUE by VRS > providers, already include means to record video messages and are not all > created the same way. Proprietary methods have been used. The document > states that MWI is optional but if the ability to leave a message is > provided then MWI is to be implemented. Since there are proprietary > solutions, it seems appropriate to me that this should be changed so that > proprietary solutions and indications can continue to be utilized. > > > > > > I don't believe I have enumerated all the reasons for not including > requirements for the above but I believe the examples given are sufficien= t > to consider. > > > > Regards, > > Eugene Christensen > > > > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, > files or previous e-mail messages attached to it, may contain confidentia= l > and proprietary information. If you are not the intended recipient, or a > person responsible for delivering it to the intended recipient, you are > hereby notified that any disclosure, copying, distribution or use of any = of > the information contained in or attached to this message is STRICTLY > PROHIBITED. If you have received this transmission in error, please > immediately notify me by reply e-mail at echristensen@sorenson.com or by > telephone at +1 (801) 287-9419, and destroy the original transmission and > its attachments without reading them or saving them to disk. > > > > -----Original Message----- > > From: Rum On Behalf Of Paul Kyzivat > > Sent: Thursday, August 19, 2021 10:04 AM > > To: rum@ietf.org > > Cc: Alexander Ospina ; Isaac Roach < > IRoach@sorenson.com>; Brian Rosen > > Subject: [Rum] Action Items from RUM session at IETF 111 > > > > [EXTERNAL] > > > > The minutes from the RUM session include a number of action items. > > Specifically, the following people made commitments: > > > > Brian Rosen > > Isaac Roach > > Alex Ospina > > > > Brian is working on an updated version, but it won't include the > > concerns of the others above if we don't hear from you. Rather than try > > to summarize those I refer you back to the minutes. You can find them a= t: > > https://datatracker.ietf.org/doc/minutes-111-rum/ > > > > I plan to issue WGLC on the document soon. I will wait one week (until > > Aug 26). If there hasn't been any followup by then I will ask Brian to > > issue a version that we can advance to WGLC. > > > > Thanks, > > Paul > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > > > --000000000000e4aeaa05ca8a9df3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joe,=C2=A0
In a pure and perfect world yes this would = be the case, we have been at this long enough=C2=A0to know this is not the = reality of how this will play out. I have read ahead, I see that Ed Sayers = addressed this much better than I could.
Roger=C2=A0
<= br>
On Thu,= Aug 26, 2021 at 5:48 PM Joe Gruessing <jgruessing@mitre.org> wrote:

=C2=A0

Isn=E2=80=99t it correct= that the motivation of this document ( i.e. =C2=A0to create with best prac= tice the =E2=80=9Cright=E2=80=9D type of client guidelines through consensu= s and current art) is distinct from what the FCC decides to do with the written product (whole or in part) and how it relates to existing indu= stry tech? Shouldn=E2=80=99t the question at this point be focused on wheth= er this document properly captures the IETF global =C2=A0interpretation of = how a RUE ought to be implemented today and not whether the government agency will enforce mandates and how?=C2=A0 Those a= re related but separate initiatives in my opinion.

=C2=A0

----------=

Joe Gruessing<= /b>

Infrastructure Engineering, Principal=

Group Leader, L114

=C2=A0

Office: (703) 983-2075

Mobile: (703) 347-2402

=C2=A0

=C2=A03D"LinkedIn"=C2=A0=3D"Twitter"=C2=A03D"YouTube"=C2=A03D"Facebook"=C2=A03D"Instagram"


3D"MITRE

=C2=A0

From: Roger Slusser <rslusser1096@gmail.com>
Sent: Thursday, August 26, 2021 3:30 PM
To: Olle E. Johansson <oej@edvina.net>
Cc: Christensen, Eugene <echristensen@sorenson.com>; rum@ietf.org; Kyzivat, Paul <pkyzivat@alum.mit.edu<= /a>>; Alexander Ospina <aospina@aslservices.com>; Roach, Isaac <iroach@sorenson.com&g= t;; Brian Rosen <= br@brianrosen.net>
Subject: Re: [Rum] Action Items from RUM session at IETF 111<= u>

=C2=A0

=C2=A0

=C2=A0

On Thu, Aug 26, 2021 at 10:31 AM Olle E. Johansson &= lt;oej@edvina.net&g= t; wrote:

=C2=A0



On 26 Aug 2021, at 16:17, Roger Slusser <rslusser1096@gmail.com= > wrote:

=C2=A0

Hello all,

First off these are personal comments and not as a s= pokesperson for the VRS provider I work for.=C2=A0

=C2=A0

I have to agree right down the line with Eugene Chri= stensen. I have been a part of this from day one and have been directly inv= olved in the setup and execution of the bi-annual Interop conferences and d= evelopment of the Provider Interoperability Profile.=C2=A0=C2=A0

=C2=A0

It is obvious to me that this RUM RFC will be picked= up by the FCC as the new spec for the VATRP.

Roger,

With all respect. There is a world outside the USA. = RFCs are written with global scope, not limited to a specific market or gro= up of vendors.

Olle,=C2=A0

I think=C2=A0you may have missed my point about this= targeting=C2=A0a specific industry, namely the VRS industry in the US. Als= o when the FCC mandates support of an RFC they do not specify custom profil= es especially in this case. There may be other uses for this out there but none that are directly or possibly adversely a= ffected.



So let's not kid ourselves or mince words about = implementations, industry profiles and various services. This endpoint spec= will be terminated by a VRS provider Interpreter station or proprietary en= dpoint in 99% of the use cases. By mandating via "MUSTs" in this RFC, and there are many, it will force the V= RS providers to abandon current project plans and business=C2=A0goals to tu= rn attention to implementing things in this RFC that have very little value= to the Deaf and HH end users we support. Every provider already has a notification scheme for message waiting, most of wh= ich is much more elaborate and sophisticated than MWI, yet this RFC will fo= rce=C2=A0less desirable services... why? This is just an example that has b= een objected to since day one and yet it still has stuck like glue. Let's not lose focus of the driving forc= e here, the betterment of the endpoint experience=C2=A0for the Deaf and HH = user base.=C2=A0

I think being able to get privacy and be able to use= all networks, including the old IPv4 networks, is a good experience.

=C2=A0

Most providers already support encryption and IPV6 o= n a limited scope, not necessarily the way it is defined in RUM spec. Manda= ting compliance using MUST requires providers to discard sometimes huge amo= unts of development to change over to what RUM is specifying. The push back is not about doing these things i= t is about the loss of time, effort and money to do them in the way RUM man= dates with MUSTs.=C2=A0 =C2=A0

=C2=A0

=C2=A0

I understand this is IETF. I understand this must ha= ve the latest and greatest tech the industry has to offer, but I think the = driving committee members of this RFC also need to understand the realities= of implementation and the hardship this can and will bring to providers with the "MUSTs". The FCC d= enies funding for non compliance, the reality is these "MUSTs" co= uld put providers out of business.=C2=A0=C2=A0

A MUST in an RFC points to an implementation. It doe= sn=E2=80=99t provide a profile for a service. If a service provider only pr= ovides IPv4 that=E2=80=99s ok (depending on the customer requirements of co= urse). But to be RFC compliant and interoperable, an implementation has to be able to support what=E2=80=99s specified as MU= STs.

=C2=A0

I know there are heavy hitters in the IETF community= on this project. But there are also founding members of the VRS industry w= ho have offered comments with reasonable explanations=C2=A0that have been d= ismissed. After 18 year I believe we know our customer base. The Deaf employees in our companies in marketing and sa= les collectively drive=C2=A0our product offerings to best suit their needs = because we eat our own dog food.. I would urge this committee to take long = and hard consideration of the experience that in my opinion is being dismissed offhandedly for the sake of new tech= that has very little to do with our customers needs or wants.

IPv6 is not new tech at this point. SRTP/DTLS is imp= lemented in millions of web browsers out there, with many implementations i= n Open Source. It=E2=80=99s not new tech, not at all. In fact I would be su= rprised if the US FCC does not require IPv6.=C2=A0

=C2=A0

I have been working with social care alarms as well = as telephony for deaf and hearing impaired. The users don=E2=80=99t deserve= old technology or a lack of privacy. If you ask them it would be assumed t= hat you work on all kind of networks - mobile, wifi, fixed and they trust you to give them privacy. They won=E2=80=99t sp= ecify that in technichal terms, it=E2=80=99s just assumed.

=C2=A0

/O

=C2=A0

I already addressed this earlier. It is not that we = don't provide encryption, we have settled on other methods. We have bee= n supporting IPv6 for some time now on a limited basis.=C2=A0=C2=A0<= u>

=C2=A0

Thanks for your consideration,

Roger Slusser=C2=A0

=C2=A0

On Thu, Aug 26, 2021 at 7:16 AM Olle E. Johansson &l= t;oej@edvina.net>= ; wrote:

Friends,
This is the IETF after all.

We can=E2=80=99t let any documents be published without IPv6. The problems = you outline here are surely solved in existing implementations of SIP, prop= ably since many years ago. If not, we have work to do.

In addition, RUM services without SRTP/DTLS will be used over any network, = including the Internet, and it is a very bad solution that feels like somet= hing we sold in the SIP world a long time ago. The world has moved since th= en.

I strongly urge that the RUM specs has to require mandatory IPv6 support as= well as SRTP/DTLS encryption.

I would personally go as far as to say that SRTP/DTLS is a MUST and nothing= else is ok, very much like WebRTC.

In regards to proprietary vs open standards, this is again the IETF. We pro= duce open standards and a RUM specification has to point to a SIP SUBSCRIBE= /NOTIFY package for MWI.

Remember that what I=E2=80=99m talking about is documents as specified by t= he IETF. Industry profiles and various services may go other ways, but the = IETF standards has to be up to date with best current practise.

Cheers,
/O

> On 25 Aug 2021, at 20:58, Eugene Christensen <echristensen@sorenson.com>= wrote:
>
> Brian, Paul thank you for considering the changes that have been broug= ht up to this point.=C2=A0 Leaving things alone with the X-Card, the inclus= ion of the instance-id for location, additions to support notification serv= ices for mobile, etc. are all appreciated.
>
> It is my opinion that we should not include requirements for the follo= wing in the new RUM document.=C2=A0 Here are the reasons that I believe thi= s way.
>
> WebRTC
>
> * While there is an RFC for WebRTC, it doesn't appear that all bro= wsers are following it.=C2=A0 For example, TMMBR is required for WebRTC but= Chrome does not signal it.
> * WebRTC is an audio first implementation.=C2=A0 For VRS, video is the= most important media stream.=C2=A0 It means everything to the deaf or hard= of hearing user.=C2=A0 If video is suffering first in a lossy network, tha= t is a problem for VRS.
> * Some of the VRS providers do not currently support the following ite= ms.=C2=A0 This could pose a significant impact on the VRS providers to get = this implemented.
> o Encryption (DTLS)
> o ICE
> o RTP/RTCP Muxing
>
> IPv6
> * For those VRS providers whose current implementations do not support= IPv6, this can be a big jump to get their solution to support both IPv4 as= well as IPv6.=C2=A0 Granted, it does not require being dual stacked but ra= ther could be two separate servers, each supporting their respective version of IP.=C2=A0 This could be a big under= taking just to get IPv6 into the mix.=C2=A0
> * Another solution could be an IPv4 to IPv6 gateway but that doesn'= ;t work flawlessly.=C2=A0 For example, the gateway can forward the IPv6 SIP= message to the proper address on the IPv4 network, however, how does it re= solve the embedded IPv6 addresses signaled in the SDP?=C2=A0 So, for example, consider two RUEs, one legacy RUE that is = using IPv4 and one that is IPv6; the signaling is possible for both once th= e servers for each support that or provide a IP gateway between the two.=C2= =A0 How is the media going to work?=C2=A0 Each of the RUEs is going to provide an IP address in their SDP, one will be IP= v4 and the other IPv6.=C2=A0 How is this going to work without having to an= chor all the media somewhere?
> * Are there issues that we need to resolve with NAT64 and/or DNS64?=C2= =A0
> * As I understand it, some mobile devices are already IPv6 but do not = follow the RFC for embedding an IPv4 address into an IPv6 address.=C2=A0 Th= is is going to require special handling to get this to work with such devic= es on vendors that do not follow the RFC in this regard.
>
> Message Waiting Indicator
> * Some, if not all, of the current implementations of RUE by VRS provi= ders, already include means to record video messages and are not all create= d the same way.=C2=A0 Proprietary methods have been used.=C2=A0 The documen= t states that MWI is optional but if the ability to leave a message is provided then MWI is to be implemented.=C2=A0 Since = there are proprietary solutions, it seems appropriate to me that this shoul= d be changed so that proprietary solutions and indications can continue to = be utilized.
>
>
> I don't believe I have enumerated all the reasons for not includin= g requirements for the above but I believe the examples given are sufficien= t to consider.
>
> Regards,
> Eugene Christensen
>
> CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, f= iles or previous e-mail messages attached to it, may contain confidential a= nd proprietary information. If you are not the intended recipient, or a per= son responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copyi= ng, distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this transmiss= ion in error, please immediately notify me by reply e-mail at echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and des= troy the original transmission and its attachments without reading them or = saving them to disk.
>
> -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of Paul Kyzivat
> Sent: Thursday, August 19, 2021 10:04 AM
> To: rum@ietf.org=
> Cc: Alexander Ospina <aospina@aslservices.com>; Isaac Roach <IRoach@sorenson.com>;= Brian Rosen <br@= brianrosen.net>
> Subject: [Rum] Action Items from RUM session at IETF 111
>
> [EXTERNAL]
>
> The minutes from the RUM session include a number of action items. > Specifically, the following people made commitments:
>
> Brian Rosen
> Isaac Roach
> Alex Ospina
>
> Brian is working on an updated version, but it won't include the <= br> > concerns of the others above if we don't hear from you. Rather tha= n try
> to summarize those I refer you back to the minutes. You can find them = at:
> https://datatracker.ietf.org/doc/minutes-111-rum/
>
> I plan to issue WGLC on the document soon. I will wait one week (until=
> Aug 26). If there hasn't been any followup by then I will ask Bria= n to
> issue a version that we can advance to WGLC.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Paul
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/rum

=C2=A0

--000000000000e4aeaa05ca8a9df3-- --000000000000e4aeab05ca8a9df4 Content-Type: image/png; name="image001.png" Content-Disposition: inline; filename="image001.png" Content-Transfer-Encoding: base64 Content-ID: <17b87bb2e5f4cff311> X-Attachment-Id: 17b87bb2e5f4cff311 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUSAAAFEgGIfCirAAAB AklEQVRIie1V2wnCMBQ9FUPyqRPYEeoE1g3cwBXqBOoEOoJOYJygIxg3cIR+pvRDSUnhGtOP2lZB PBCSexPOyYX7CBgXJwAL9ANpBO49kZcY9EleJ3ADcLB7awwdggzAtMh1xrgYAbgACLuMQBpyc7D7 sW0ErkBsf15h1lbAl0UKwNmSx30IdApfFs3JUiSqyr+yvi2AcZHrwOzWfoWJgC76gHGR2ruU+CLG hbfyGReJy9e40IpcqyLXsuZu79bPW5XMuNiQX+6ca0WNxgI2jdfElThPrq0EAEQe0dp0/kqz+wt8 VsCdB2WOE7OaBSHxTzw8S5JJTx34N2ayt690AkA+ALsWRF/Krkd1AAAAAElFTkSuQmCCAAAAAAA= --000000000000e4aeab05ca8a9df4 Content-Type: image/png; name="image002.png" Content-Disposition: inline; filename="image002.png" Content-Transfer-Encoding: base64 Content-ID: <17b87bb2e5f5b16b22> X-Attachment-Id: 17b87bb2e5f5b16b22 iVBORw0KGgoAAAANSUhEUgAAABgAAAAUCAYAAACXtf2DAAAACXBIWXMAAAQ8AAAEPAEZaCRCAAAB jUlEQVQ4ja2UPXLCMBCFn5E0UpeUSQddSnKCcAS4AZQp6ZIq5AZQpoIbhJwgpEsHnACOQDppxE9m M2vGeGRsTXgzHkvy+lvtSrsgKW3qiBDZK23elTaHzDNX2rRSitKmq7RpJzyZAxh5ZydlbpQ2TQCf AK4LTGYAmjxupA4OvND3zg5LHKwAVIn4FcBV3gFpCqDnnd0E4C3efVV1agHDNoCV0magtMmnoVUR vOFNTgXNhJSUs7uMgWHYE30TUt4KKQ2npoqTb+9snwYJ77JecnCxmnpnO/RPjeFzDutSWqacmnd2 wfCoWijR+uiA36MLwsG18KckHShtxgC6F4AvvLP36UQcB1Iu+ZCbhb9W0/N+t12EIogtopDW3tlG dv0YwX63XQsp6/+MoEOcoAN28iGkTCIqNquhd/Ytv5iELLn4xtw2qmjine2F7JIAmKAvEXVRCAe3 igGABwbGFBvlmto7dd9Cif1uOxNS/gC4yTW8c2Dq9Y/cBc4qlCI64PQmUWRfGfDMO3tyS84KwC/b snjTWCpZ6gAAAABJRU5ErkJgggAAAAAA --000000000000e4aeab05ca8a9df4 Content-Type: image/png; name="image003.png" Content-Disposition: inline; filename="image003.png" Content-Transfer-Encoding: base64 Content-ID: <17b87bb2e5f692e333> X-Attachment-Id: 17b87bb2e5f692e333 iVBORw0KGgoAAAANSUhEUgAAABgAAAARCAYAAADHeGwwAAAACXBIWXMAAARkAAAEZAGL13mEAAAA 1ElEQVQ4jbWVvQ3CMBBGX/6UlIyQEaCjI4zABrABGyAmYAQYgRHCBGQDMkJKWy5Ah4yUBmGb+Gss y9a98/nzOQEoyqoGDoCMc2BGmAagA3rgaLTqExv8/kfQbxLYIsvy/AQsJw4uqiTp1JYllmop0TMi gNRxn1zcJSZgMFrt5NKANgbgLaNVZ7RaAxtrxWkBI9DVnuYnJAhQlNUeeLg4MPcM3ABnH2u72rSz L7PxScgHEKzU13aealNXuwUqfjcd/wdbYGUXZe7bBKUSn2rcpLUYrfoXGVA0JYXp1vUAAAAASUVO RK5CYIIAAAAAAA== --000000000000e4aeab05ca8a9df4 Content-Type: image/png; name="image004.png" Content-Disposition: inline; filename="image004.png" Content-Transfer-Encoding: base64 Content-ID: <17b87bb2e5f7745b44> X-Attachment-Id: 17b87bb2e5f7745b44 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB eklEQVRIibWWMXKDMBBFv0EaKClTkhu4TGlO4BwhdGl9EvsG9hFCmQr7BjkCR6CEwXYyy6wYEEKD BvIrW5bfF7t/NWxgkQzCdwB7ADsAsbazAHAFkDV19TVFMRrIICTg2QCdEpmlTV1d9d89A/wIIHeA g/fm/N+BfA1Op/50AOt684WIn497ptY7A3Z3gVM5SgAv2vrWFyJ6Pu7fUD3gmuczoCXXetBUGYQ5 B6GvhHqienCeCU9sidHUMgVHcU5DL01d/fROHVE5+Gtk2B8TW3DO5+imwfOewZT2nqF2Uyp769sZ cNLOc8y7q+LRoK2tjQzCXwszMY2/Lhtj8RPIILT2wuOLaolsPSwEj/zHxIajDEKVnoOaAz61uths BlcyyCwG/cePtM9z4p15PPpLy2RSQWzV5PQfDFpma8BRPK0IP6l4dzFt6upAF9oK8AuzAH0OmrpK Fz4JnXxQ7tGgsXvi2HjaS1PfnVyJYjoS1+9Ve20xQe2vLQD+ALaKgDHuS7cwAAAAAElFTkSuQmCC AAAAAAA= --000000000000e4aeab05ca8a9df4 Content-Type: image/png; name="image005.png" Content-Disposition: inline; filename="image005.png" Content-Transfer-Encoding: base64 Content-ID: <17b87bb2e5f855d355> X-Attachment-Id: 17b87bb2e5f855d355 iVBORw0KGgoAAAANSUhEUgAAABgAAAAYCAYAAADgdz34AAAACXBIWXMAAAUEAAAFBAFBa3z6AAAB nklEQVRIib1WwXHCMBDcMHjspzsIJZAOoIN0AKmApBQqAHeQDqAD6ABTgf20xw8yR/Y8hywRCE52 RjMgnfZOq5XkJxhEcTIBMAPwCiC1YzegBPAJIGvqaqvhbYIoTlYA5neShrBu6uqtTeCQayVHANsb CWXlz87Kv5OILFGcnNh2UZzcK00LmUsO5ZsMqLlWPm3qqvwF8UYIAbwLB7lw5o7ipGC21Q8kI65W 2sj0j03FJ/at+L8YGM2OAWIh3AE4ANiwHSjFpKmrPYA9w7cOVwqrl4d8bqsLtLmuxCnqHD+8Iokk VNlE06WpUMYWXL3IkVvvu0TeFRg3FLY6R3vdv51H1jPvIJBUNlFJl9T5Auxbsm9sN97CmwCADb52 2OzYXQl6QyhBbn533BUYy30B3gRNXeXG24vQJtNJgj3ndBC0KYAPHiqxolwFIZtqrB99HTRnntem nQRNXa15eXVsyr4pY1y0XEOe0pT3eQc8oS/0uVoxD2lOKFd5cfM98hYo+Ca0N7RIlHFMN/OhB8cY Q5D9+ZP5P4++SdLvZwuALwyUvZfl03noAAAAAElFTkSuQmCCAAAAAAA= --000000000000e4aeab05ca8a9df4 Content-Type: image/png; name="image006.png" Content-Disposition: inline; filename="image006.png" Content-Transfer-Encoding: base64 Content-ID: <17b87bb2e5f9374b66> X-Attachment-Id: 17b87bb2e5f9374b66 iVBORw0KGgoAAAANSUhEUgAAAXEAAAAuCAYAAADeKCkyAAAAAXNSR0IArs4c6QAAAARnQU1BAACx jwv8YQUAAAAJcEhZcwAAIdUAACHVAQSctJ0AABSDSURBVHhe7Z17kGN5Vcezr+5O7iMz3Unu7Udy MygoUJSUCFuAuIAiWLhsKTvOTHeatSxFKBQpRSgf1PherC2FeXR6sXzVAoUvEF1h/1AKEQEXRQXf YIEotWKxvpZlV9l119/59Tm/OfeX8/vdm04ynQz3U/WtyT3ne04607mnb27uo1ZRUVFRUVFRUVFR UVFRUVFRMRUap/deGO3uP+oS2g5NOBg+JPUF1Qd7f4A2J1IdqDEY7mnDC84tS/lpSPdXSLnDKNjZ vwNbikg1E2mw9wxsPTWa7a3/xYdTJ+70/+7Y+olHbWFaJOpk/yLVxMnW09CSg/K4OALlm63+gxji XMfqlyEQpSd+gMUMFLPjRFE+TrPf4R5So9VbR0shUj1XrbYWoVUjebiiNPsNtI7QTLOPSzVBkj0H LQbJxxUl2S+g1RCn/e+mPIa88H4uoVXjyxFxkt3GPc2kfxemiCWeJ8VJ/+cxPxtWTu/fKw4AFNoO jdSTC21OpBrQIg5xLmydQ/JNpAUa4tKbnwttOSQfV5T234tWA+VwcQRejyFD1O79s50rM8TjpPcP GDbwPIYMPCcp7PReilYvUq2tOOl+G9pL+UFoN0gerrDT/whaNZJHEto1l3uIqz+iP4Ipg+2xhrj5 A+8S+qaPuPIzNXaGf4jWsVnZ3n+m1JMLrU6kGtCiD3EQtjdInom0IEN8qbXxOHqjR2vdF2G4trSa Pt61EjTT/v9RPFzrfwHDtZXjG12r5rqDzAEsLqL6vs3loTjPlRnidg5w5Zpp724pFyW9F0pxHy6/ GlAvk3JSDAiSpMNzofq9YKoWr/UfpLjaGn8Iw7X6WneD16jQykHG83PFW6tWrnGQOfwQV3Ufgp9f Elo15OfClMHO8yHO4xjS8Hicdn8Jw9NFXPktoXVspF620OpEqgFdCUMchE+hkfITaUGGOH+jY8ig htftQdr/FC4afDWAK++rIcizcizNMKShON+yLDvE1R+HhzGl4TkMaVxxoNHqfTXlwqT3Ggw78fVS nw7eaed8foByYWvrnzBUuobnpRiHcmHSfwuGDj/EO9kfYcgL+bkwpWk2s2N2XhriQZp9HkMGiMdp 70dxcfqIK7+l2k1vOIb2sZB62UKrE6kGdKUMcRA+zZfsEI+S/l/QStBIe7sYdgK7E8hfU1tvGM5B ee1hSDEbsbbdDqXaoiGu/gi9kuXNliXFME6YfarB2uazMXZoHM+hiTrZ0+2czw/Y+aDTfR4tu/bV 809MGCr9PEGyYXb1HPUQj9v9v4WYej2PUL7MlvjsufGNibjyC8KK0gQ7ex+U+thqbA+9f6GkGtCV NcTPXj2T51mcfeJX8ZUAZG8Fc7gPQyPESf+PJU9RHUAe7oNdBVJt4ZZ42r/FPGYeKRanm5+1Y5Mg PQcBnwzsnM9/XXvjyZSLO71fhZjPT4Rp/622x1fHhySGNEcxxMNO9qeYNvmwvfliesyHuP0Fe5B2 78PUbAm2h3eJK78gLCmN1ENSODj/CJaISDUgM8QLkGpJaClEqgUtndl/LFq8NAa3v0Cq5wKfFCfp RnPArL7YDNu9Z/KVgNRsZx9Gi4HnMTRCM+k9V/IU1QHNdu81to+W7doyQ5wvx0n3VC6vBMtAs7X1 P3ZsEvhzwBEfIPXH6E4eB6E951fD9B4t9fvmcRDaxddgA0cJ+epcUrZrDtwHHHaIS1LD9wfRZuD5 qN19CT3GtMnzx3yIAxS3FXS2noSW6SMNC5eKtphzbN96XOrhElaJSH7QIg1xQupBKpOfB2Y1xAk1 OP5RWhFU6qoDR35lwdAIYZi2JU9RHXHJtxrzZTXgf00bkLJDPG71H+A+k8dlgA9MDGnU4P0E90se CanGlrLpT4GAlLelbEsHbvk1jNBsmn3JGCn1PFGavQftmss5xPkyPK53ui+ScvYQR66mvC3MTxdp WPiEZYXA1rVU7xKWiUh+UDXEj4ZZD3EibHWf5VoJpJiN2ur8MclTVEeQL+5031VbOd5z1ZUd4gDF 4iT7gMkrYdq5JT6LIQ5Hu6DNIPm40Gbw5Yig3XuF7fHVwZfGlAs6vVsxfFl3p/BleEy7eNSnO32o KOUcQ9xAPpL6vX8GU9NDGhY+YVkhUq1PWCYi+UGLOMQb2xd3pT4gyEtxkm4wB1yuIU6oLdh7aSVo tDeeDDG+ta5NApS3PUV1BK9vJO7nG2eIq63LXzdxJkzXgnTzU3YMUH9IXqaG0Q+DpDoX43gBl59i MMwwpInb/b+R/Bw4ksX20LKrTspf7iHewD+c6jXzL2b1Lh5aLhriBPmxxzQ5e7U0LHwKT537Nyx2 Emzv/7JU61NjZ29kq4CQ/KBFHOLB9t4pqQ8I8lKcpBvMAbMa4rBPfLnZeQwu5qAVQA2Nb4TllePr ZsvYdeIL5UEY0kgxCbUV+PW8h6tunCEOmDgTpjQUaybZJzCUw1UnMY4XcPnVQPs8i197ENWsUDzq 9H8GYzkoj7UaKcaR8pd7iEfRxhqPURygZXuIu56riUe28B5TIdy++F3SsCgSljuRasoIy0eQvKCF HOK7wwekPiDIS3GSbjAHzGKI0xtcfJNHkVmZasePdzHqrQnT7DzlQseXT7johbykKMl+ElOGcYd4 kGw+2+RQmNK44gDfZy7lbcbxAj6/K+eKA2Gnaz458GPrfTWAlL/cQxzgMSluhnhw6WSoeH3zszrG oBwIQ9NBGhRltPTtnsF1w3uvlWrKCDuMIHlB1T7xo2EWQzw4tvUk/kZXK+yHmusnvpNvwYDQrlle 23wOzwVp/37pOipoN9h5W7D/Ga3SSmy+XCXGHeKAyaEwrIHT4HkOXlec9D/DYyQscTKOF/D5Xbn6 6qWjT0DxWv+Bot+DnXMpTLqvxZLcEHcpSvu/iPZSz9FM+x9Au/j6eEx94jMHdlCMb4lzLyhOsh+K kr45R0DH0v5fo306SIOC1NgZvl+Kk7DFCJKXFJ4+/6AUJ2GLESQvaJGG+MqZC0+X6rnAJ8VJutEc MKvdKY321vP5G96WspijKIgo2XqT5CWhLYfk4+JDvJFu/hfPYTjHYYZ4rbZVN3mrDoALTfE8V9ja +jp6jHYnvA5DXnx+frSPnY/S7s/ynC20GSSPLTgBDO2aoxjicdp7nR0DKGbvTmm2N0cOx+RC2/SQ BgWpTF5C8pJqJ88uSXESthhB8oLmZYhH6ueQcuOo9pSX6ut7SDlS7Xm3BWNrBsxqiBONtHsLbH3C m149vk9t1X0/ppyoj+rvol0NzVb2ufrq5hamRojT7K+8Ur3QWguOJ0+keJT0PorhHA01pMmDIY2p 61y6FgyH8nYdB7bcaADAFR4xbGpx0UmZ5+AU+YvyavC+g46wabb69y63u1+GqRy8DxfscgmS5Ilo yxGmvZNSDVeQZD+Odudz5JRkb0a787X5YmqI72MoR5T2PkpfiOIlCkY2QKaCNChIRflwd3/kl1g/ vf8tkpcEHilOWj49fK5uZCF5QVfUEEek3CTCtlNl1kO8oqKiBCtn9m6QVnoSeOq7t3+vlCPpRgzJ QwoGF/4MPMHp4SelPCg8s/eXupGF5AVdKUMcn0Ij5ScRtp0q1RCvqJgDgp2Ld0srPUgNR7MDX8qT Vnbf1EObRvKQ0FJbunn/CVKehLYckg90JQxxbG+QPJMI206VaohXVMwB0gpPggtKoa1wqKCtFgyG H5HyJLRppDwJLTkkH2jRhzi2ziH5JhG2nSrVEK+omAOkFZ6EFs3Kqb2u5CGhzdsvOLP3fWjTSB4S WnJIPtCiDvHaLb9iLo5vI/knEbadKtUQr6iYA6QVnoQWg+QhNXaGb4cjK6QcCdsYJA+pdvJsiDaD 5AMtwhAPz1z8dGN3+M3YphCpByncGb5uXGHbqTJPQzxqbTwuTrLTzfTESbWYu4PPohAl3RvhNYxz 78yKS4Rp7wnw/xe2ey9Wi/xs0isbaUiApMvChmfOfUHyknwXuxL77Z5/WPKCgt3hn6DNIPlA8zLE fXmQSo+cIOJCqieh5ciZxRCnw+h8itdPvA/t5roWklbYWZ1AM+n/lOTjUrbSvyNC6DEWdj0p6nRf hZYRbC+Gc9geSREeuy7lbIXr2VeW9YKvCONNktwhsL4+Utx1AhQIzvJFm6aZ9n9P8nEpW+49YOU8 ZObSAy6hUUPLcL9W+Ff9bN5LcYs0ti/+ljQkQPXB/t+jLYfkLaPazutHjtetb1+8SfKS0GaQPKB5 GuKAlCehpRCploSWI+eoh3gj6f+nlOeqr6VfoxsrygxxENpLEXR63zBJvV1rq5n23obWHLZvOUlO YMpgeyTNaojDsdHg9UFeNYTfgSEN74MhDdxk2o7DPVW5X1IUbXwF2ksNcRDaNa74KMVDHIRm3Rf+ hSGuPkF8LGr3C+9kNUJ4+vwXpSEBQssIkreMsHwEyUtCi0HygOZtiNd3L7xK8pDQ5kWqI6HlyJn1 EMeQi2s93tzKhLHcEMeQIUqz36dc3OmKGzASVMOFqUIa7c2vYjW570e8/cKwxfMuny9nQ74g7X8S Q058fX05G8kbJf0hj4dp9+WYkvzmFnYspoGbH0s5PsQxZFDvgY9RTv1h+W0Mj/GaLg1xDBikM37p Xz3ED3savjQgSGgZIRjsv1vy+1QfDP8by0eQ/CS0GCQPaN6GOBAOhg9JPlA4OKc/PvmQ6khoOXKO cogX+eACVSbfaOl9zL4hDlDOlZcgf9zKPkeP4QxFTHtprmdvphoM2YhffFMNKOr0b3X14D4MOSHf pENcfTRJTK+kK55xSaiB+q92H1rmwpTJhe3up/ky93DCJHuLyYfrLYj5hjhAOZ6XYjLuIQ5YfaZz 5qY0IEhoEZH8PtXOHtw3UkLyk9BikDygeRzigOQjLe9c8N78VqohoeXImechDlCePtrPcojXVldj frEnTHsJVvO7YjBciF3jqrd9Psg38RCvrcamV8EQh8sN231oGS6X4MqF7exb+TL32FC+mW7pS2cf 5RAHKB+rrX4MTYL/GuJoEpH8PmGZSDhwf7lZ39l/K9o0kgc0r0O8dvPP1SUvCV0ikp+EliNn1kMc hq4ttLGVc/RynwTvBctQz5c5caf/bsrxm+L6aLIaWF6KNh/Ll8tAfq5w/WCr0QX5grVMbwjQsvoj 8pvagFAcZP8/gtCmIR98z2D74EYUaNPwvhgy+HIStpcv88fSLfZoGW5IgaERyEN13t0pSf/PKQdb 8Rge6eGm/BAv7lWC+uDi9dKAADV2Ln4cbSIrOxdukeokBWf2cl9a2AS7w9+V6kD2ES2SBzS3Q1xR 3774HslPQtsIkpeEliPnKL7YRNulFdizRWPXwUDiMZd0cQmkGloO060bMFQI78O1tLauv0jkqK3Q l1MeQ+LPAfC4JLRppDypmfbuRptG8thqJptfRLsX8kftnv5Sj5btx1GSvZ8vA7TM91/bkIfq+BD3 SRcjrvgol3mIS8OBFO7u34Q2J1KdJLR7kepIaNFIedA8D3FA8nOhLYfkI6HlyJmHIe66oiBg15UZ 4rqwJFQTpNmdGJpkJV3mtaSm9amA5zAE1x1/rR0DuFcS2jRSnjTuEA+S7CfQWgjVwCcA++gTk2N3 nKccQMtR0n07hkaw68oMcV3I8OXyzNEQR4sXqU4S2r1IdSS0aKQ8aN6HOCDVkILB6KcVyWe0vf/q cVU/fWEDW0+NedgnTl9ySdi9+BDXBsWyClJMDZE3YrgQOHTR7gXEaf8eKT4O/GO93aco3ljvPQVD pf8vAfIddp+4FCtD3Om9j9eCYrXVDTk4agOW4WeiHP99U8z+I8MhDwiWpd0p9bWtp1JMvQe+B8MG yvEamQUb4jU1FKRarvrOULx+so1US6rdcNaceSXlQYswxJe3h4+R6kgr27dlaNVInok02HsGtp4a V8oXmxSz4z6KLvoPUrZJzhw1N4uI0x6d+HYN7y9JDbz70TvW62L1h/5ik2LNVv9BDBWycnyjy/uB orVLx3Xbufrq5vWYKvX6KE/fnbj2iVPMjgO+XJ7CIX4V5e0bXRwKcUVHoaUQqZYLbYVItaSVwd5L 0Ob0LcIQB9TW8H1SLQltGik/kb7EhniY9N5g8sePNyHmGuIxu5NQkPR+GsNeyO8T7MdFuxM1VB5R W5734GIO6kP7/eN2Zu4o75MuVkgxF+SbxhC340XwOru2bA5DOYJ2dqfJt9v6Mh6uIa62wF9B8UZr 6zswrKG4XTOKf4iX71OCpZvPjX0ZWIng1PB+qR4UDs49jLZCgp29D0o9SGhb+CEOSLVcaKuGePEb PbdVijGDlHMNcUDye7iavEHSfyXGDGV7cR+c+INhTdhe/1rTA09L535tYoTt3s12zue3Id8kQ1xh fidwf02MFcL7gTCs8eUU5oQv+GOIsQPirVWpzjXEAckPuOKjuIc4fEIq36cEwc7wneKKrqQGauEt sDhSD1Dt5Ov11k8Z6jt7T5V6kNDmfK5FGuKAVM9VxjO2rrwhDiukOVnEJbitGtq9QzxIe3dTrp50 b8SwiHSkBAc+uvvyHPL5hFbjjZKu+FGc8mGS3cGXQdrggXt9sr26mOHLueA1dp0vBzTSrdyZkJLg ew+0e4d4vdP/D8qttLrPwnCp/5sD56Uh7tOBd0LElRzF90GXQeoBwnRppB4ktDg9izbEG2eGz5d6 kBqDvVdL8Yl0BQ5xgA9fW7UwbKNN4xviQK7WQwlfSPmotflNGHPSTLOHeE8utNQidoQGhkaw6+xl H9zrk+3VxYwwvfSJQMpL8JtBh+3swxjWhEnvLsrV29m/YzgHv/+oLZXOXQ3VN8QBq1bDYy4dOP1D PG6V/3RSzM652KlxGdwRTKWP1INESDnQDWed1+XOIdWSyiLVgmqPjnf1O6nHLHXy5DX4zFMDrk+B D4+cRjtLo6R/fZyceJpanPprvRwst7e+HF5DuJo9HkMVY1Bf627o90DahYuezeaGxBUVFRUVFRUV FRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRUVFRXzSq32/7zr0aZSsOu7AAAAAElFTkSuQmCC AAAA --000000000000e4aeab05ca8a9df4-- From nobody Fri Aug 27 13:16:16 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448E53A153F for ; Fri, 27 Aug 2021 13:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.993 X-Spam-Level: X-Spam-Status: No, score=-1.993 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_SPF_HELO_TEMPERROR=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 n5F5L3Gh8nCD for ; Fri, 27 Aug 2021 13:15:59 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2056.outbound.protection.outlook.com [40.107.92.56]) (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 C1F0C3A154D for ; Fri, 27 Aug 2021 13:15:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ymat0weT4O9W9P35IrND4eAWt5Z5OWQeAfgmOepTqA9hEhNd6AljQxnuBkQudXDrLM8Bt4kIcII4TXHhFo27r/4UQmovB1HL99cXwEOA6cKdow/gxEjqi72uq7LpDgsjRsYVUKiobyatUlVha7e1xiMH2p+5vnvJtyJzD5+QcRNFxG/YZxT35aZ8O0mPgX9QV8QW1d9bkat92/iBrOqtzvCzwjbHbgo7xWLvLHw9wapheo13CIOgtnsmeAtibZqd6TSIVK0C/ts3NLned/+ctqas2d45oQB0eYapI8W1HJitGY/tP3dJ6O/b6mfSNwpR106kdXopt2X1ox3Z70dhgA== 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=MMOk+vzfEav9KlP4q+hKrwsUBAM/jM3DWKq+kRJ4+xU=; b=aQw7Si0yjHAOOGw5ZHgdbBvTGVtUv+32zC5Md6gLFsJbS2D6ZcNP5+VBU+B6loZX07CMT3K4VPUABKijrWV/Rmbhm9ane4QbW5gPPeYeOOh3FVvvgqsJsVF/xrivWi3A6/uCdBe0hfRtNcAQQf3DVwQvrtmSjYFRqvK9Do9TPSc+92BQsg9PwVOROwbOEm/huiFxjRJC+eFAu8t/6xPZ7Bt2s7rgvM7oj827zBz8hrbeWDnbfzy6rrJfC9nK/ZjifgRHDxGx2Kw6VL+4nIf0CbtH+SJH3QRGEFmvUr79m3X2kfiTooWBbGPUGsiLHh1ZtrY3RQKyogTSnY6c//akvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=MMOk+vzfEav9KlP4q+hKrwsUBAM/jM3DWKq+kRJ4+xU=; b=R7kct2k/b/iLvQbH91XSlo/M6qqkxi1n44htHxcEo5HqrJxZrtdZHc2srHlipL36gWf+xXvAi96MIHCn/Dpi2DY95E1RcDNi79zEFS+a0VDtSYf8yZkEtgNiIi6SuQc4rLDaVSdAflW2LzRltoCyi7+uu+f3Kr7M0Fw4tim6No8= Received: from DM5PR07CA0160.namprd07.prod.outlook.com (2603:10b6:3:ee::26) by BYAPR12MB3512.namprd12.prod.outlook.com (2603:10b6:a03:134::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.22; Fri, 27 Aug 2021 20:15:51 +0000 Received: from DM3NAM02FT024.eop-nam02.prod.protection.outlook.com (2603:10b6:3:ee:cafe::24) by DM5PR07CA0160.outlook.office365.com (2603:10b6:3:ee::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Fri, 27 Aug 2021 20:15:51 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT024.mail.protection.outlook.com (10.13.5.128) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Fri, 27 Aug 2021 20:15:51 +0000 Received: from MacBook-Air.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 17RKFnVt027699 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 27 Aug 2021 16:15:50 -0400 To: rum@ietf.org References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 27 Aug 2021 16:15:49 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4ac1a975-664f-407f-7fc3-08d96997775b X-MS-TrafficTypeDiagnostic: BYAPR12MB3512: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2/e7SQo96yCRy8hfvSOk6QpA7kOsEL4kTvemYUGgZwp44DdMMkyl4wrXMdPp6PhiknorjKhRlJYSmoNaCSFqiplcfMpMiZC6qhKL9P7Sxf3DcxAHrGzTXryyFYSkqcUwbcd41V0yImXBlV6vYftHwkdtLfuBslVW4JxKBjWcGAHruDLmZRFmsishv8KTTQV2cAtilsBT38jvmFDzta1+E3rvf0O2/N7mVqsH8FSN8AiH54mdEACEHKwIxjmzl9v8G96PoOKdYTxvtW2GmMpkmKP55YfTAiKYY7t4HFJu6p3LrTg1CHpKLSYA55FK6B83a9GV1JAYBnxuji1oIVxWsRYoW1yECH6qo6Wh/5CyBYr0Bn1GCg4gHe8xV7BXS7jhvCilD5jYfjBSTy5atyUoWf/FHGoWmmrCCtedao1wDNXNuSKQemHauRDUhQQNyOxxWZ7A+3GzYGfBShQK0zFKVruGkuY2hVfAVrg9xFKiWyGixNBQL9U6KJ9qzUUGwe/DHbrWsZ7lZxf6Mv9cUo3YGZbGhsUW55VWrJVe2jFYt8+RVTiVs1Yi9IGtZYaT2/dqbrgGvtBA0NZt4Y+/0d7F8Mkw3OS9xdcsR4njsyRGCNwL+FXa1t4LGPWnnPQH4Npd501uNEJi0d6jDUPo4qQKjfuHmUzaUq29sfYaUz4AAFjs5xsYRGVMfomn/GAxF3IbOqk46QVs7esb10yLYEXQkib3hOlio7MOhoNYNiPDLWs= 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; SFS:(39860400002)(376002)(346002)(136003)(396003)(46966006)(36840700001)(5660300002)(75432002)(70586007)(956004)(36906005)(356005)(2616005)(186003)(83380400001)(316002)(82740400003)(786003)(336012)(26005)(6916009)(478600001)(7596003)(31686004)(36860700001)(53546011)(86362001)(31696002)(82310400003)(47076005)(2906002)(8676002)(70206006)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2021 20:15:51.1399 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4ac1a975-664f-407f-7fc3-08d96997775b 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-AuthSource: DM3NAM02FT024.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3512 Archived-At: Subject: Re: [Rum] IPv6 and encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2021 20:16:13 -0000 Providers, My request below to Roger should have been broader. You all seem to have the same issue. I encourage any/all of you to make an alternative proposal here. Just saying "we don't like what is there" isn't helpful without an alternative. Thanks, Paul On 8/26/21 5:40 PM, Paul Kyzivat wrote: > Roger, > > On 8/26/21 3:30 PM, Roger Slusser wrote: > >> Most providers already support encryption and IPV6 on a limited scope, >> not necessarily the way it is defined in RUM spec. Mandating >> compliance using MUST requires providers to discard sometimes huge >> amounts of development to change over to what RUM is specifying. The >> push back is not about doing these things it is about the loss of >> time, effort and money to do them in the way RUM mandates with MUSTs. > > Do you think there is something else we could write in this spec that > covers encryption and IPv6 in a way that is less burdensome for > providers while remaining interoperable with all providers? > > If so, can you please spell it out? From nobody Mon Aug 30 08:39:11 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFAC3A16E2 for ; Mon, 30 Aug 2021 08:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_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=sorenson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 417-8TxZTbV0 for ; Mon, 30 Aug 2021 08:39:02 -0700 (PDT) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2044.outbound.protection.outlook.com [40.107.244.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 A231D3A16F7 for ; Mon, 30 Aug 2021 08:39:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YQu8+6l0jmYEGisv5H1D84jitKdkC1fXugRG9wa1daSRZotumnE9N4WC7BwRKOjnwA8aq6iAVwaBmHiMHhPm3/lRfqtQZ4L8A28mk6bB6Kl+u//kDPhw9osVIEAFh60GciZ9L/RREQ/EzANli8MMA9vS8GAdBsdBWUeUWqE44/pkpk+uTgJO04LhSdXxgJLGRLi2TRBAzaAHuFacZ/kP5OGzUXuS72tcnfsH+1rxKLhkfsDfigdOdtS/H9C/lJFBeTVpMUPoJHOQtfcpJMzXYmFM4fxwtf9WqOuTXOD65kmSBWDSZUogJb3jjJ9ZmnykQ2xmtERwu5b/g+bP1ZM6+w== 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=bf/PLAt1cUBASPg76xxV3ppss5OOU4sOxLrorNovFn0=; b=jA90hWTwe/qJMDRp44jQiJaDUNJG1bW9SqI32T46tRqxJFuu2eoLU2I9tBwHc4RtLZXVGeeZB3p66mEPV+QV15bbuqbvRgHiDKSeVxhk8xIfqGve7MIGpXRbMtIcMI3VnlmN/MlnTg3seqjvveCbKAzYPUutj79wDHT7krgQx86Y/mgivn0Jro1+zNAU/DQs4qmgBkCXCegxnSa92X0JfpcAKBBQF1F5NNyxNH5jeed+VMJDINV29tdqhDz40SwwcsdHxeEVJAjraz8K3Xw8CxOOxU0jsOqLUpsluQBz/apKR79EqC0Xncm9LieXas1g//tC1sHrkhibnzV/z4F6GA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sorenson.com; dmarc=pass action=none header.from=sorenson.com; dkim=pass header.d=sorenson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sorenson.onmicrosoft.com; s=selector2-sorenson-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bf/PLAt1cUBASPg76xxV3ppss5OOU4sOxLrorNovFn0=; b=yHjWM7M8Z6lH9B9IiJ/quMOOiHZFWJYlvvbeyuIELG7EcPdAp8B1PkEr65rwMaOFyftgPqjGRFwKMUHMt1IVtlUxDkCYpAlcqi+pzTHzhdhqa7/vNusF4QsgC0znfaK6MnHk2Q2/jgsVxeFclgJd1ZLKeefPv4ijtNHJGPvdyPU= Received: from DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8::23) by DM8P223MB0335.NAMP223.PROD.OUTLOOK.COM (2603:10b6:8:5::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Mon, 30 Aug 2021 15:38:57 +0000 Received: from DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM ([fe80::3528:5280:95b3:be78]) by DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM ([fe80::3528:5280:95b3:be78%6]) with mapi id 15.20.4457.024; Mon, 30 Aug 2021 15:38:57 +0000 From: Eugene Christensen To: Brian Rosen , "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-07.txt Thread-Index: AQHXmpRRvB/jgpCCsEKclJ9vp/K/wKuF9EyAgAZAj3A= Date: Mon, 30 Aug 2021 15:38:56 +0000 Message-ID: References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> In-Reply-To: <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=sorenson.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c906dfa0-b6c4-4f17-bacb-08d96bcc47b5 x-ms-traffictypediagnostic: DM8P223MB0335: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5797; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GKUDLB67CNJ1UXUiD78qcTIHNAkazqOSuzt8szrRvwQz/p2K6vtKkv/H7hb/w6WBXjU3UmabNH7Ut7sP/AeQdvX7WzXK9uCea3kMwQnFdvwmj6jWlkQ2BBKw17etIUP1K9ld+SEBasD9d91vT62cUFBpBt5DID/OnOjzqKe9U+hoapSY4RTF0uYDwH0OOdA4MlWecAWxK8lFjHFfap1cB6wwNjQNhXKKRvT5E9HMfcQLArqvG/2X3rX98bl2KQ/6D6CcgNDJPNshZQDP17WhLTEvZWaWv9o+xH7hURG/WFp5hnuBDRFcH4BHNi2CVfSsqApPFh7KWjtBdfti+yGD3+VBAqQGAhEgkugIozqQAGhC+9APWfYycq71Esl/CiHBIHmT/J0BbjQhlsZ8lQdtf6YQgQqGLH1w723cpqO0XOaLXz7y9OtwIy6v522tFwftKGRfPtpT80hJUU3A6x56eoBE6kjjF0lwJuZwsvP1j638uBzwe/B2eLFQ7izftL3uxCu93WDLXRaxUvhcG2qCeiDls1rnOUS0yVtlVwpnhSNeW1+Yj5WpTcbFbBf23FTo9Wl+QvyWlr3IR/Uw8AI+ylaSEU/7Ai8AzeP4fvuDhtv8IBZ953VcEQpKsFcpmpGYvcudpZmYb9MaXUrtp4v6eO5IhD5wEjG1V+0LcnGLIRMjG5HYJBPqWnzoeGPVILsbg7CbuhwJ52/4a/feOSihjSKJ4xyw+lad5BIONTDmYpxzaPhyGfHklcbyZsRaS04WvBIpJK+38UhRwnB4YeIWD10UYuS+iFIiX7pU4uI84aE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(396003)(366004)(376002)(39850400004)(346002)(110136005)(478600001)(52536014)(83380400001)(316002)(76116006)(7696005)(66556008)(86362001)(66574015)(71200400001)(66446008)(66946007)(64756008)(66476007)(5660300002)(26005)(77540400001)(53546011)(6506007)(966005)(186003)(38100700002)(2906002)(55016002)(8676002)(33656002)(122000001)(9686003)(38070700005)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YVBuVTFUYm9YWEZKK0h3MWZUUXJyUVFHbTBvb0VyckMrajRrMERJZTZveFkx?= =?utf-8?B?QWpYZjlKRjE3Unp5ZHFnOFZDUUREVVhyOUNQVXFDNk13MWJVaVNzZTFqa2t6?= =?utf-8?B?QWdQbTNBeW42UURkM1FHdmNLR0JUT0RuKzF1RVB4VzZBdk5ac3hsSmsvY1c1?= =?utf-8?B?ZjdISys1SWdoR0c5bzlocTRyOVhXWlVkV0Y1UjBtRkxHc2lRRmM1VTZ5OS9M?= =?utf-8?B?QVNQWEk4OHdwZFFkU0ZNV1VXbDJEaHdMc1NNRnRCZUpNbkRPRVVMVjlBQ1Mx?= =?utf-8?B?ODRwVHVjY1JaUElWVHAvQ28vdEVnS2gxS250c3VzcmprVElnZUlVdTJaUEE3?= =?utf-8?B?ekRRM1hiUWZMcTY4c3NmYkxvZjJtRmVmMm1zSTZjS2NWN1RQQjIrbzkzcjg3?= =?utf-8?B?enB4azFTbEVrYUNJOXpMZGxFaGNvQTVpN2lFREZIS05PV1RXV0xSbFVQc1Bp?= =?utf-8?B?MDYxckt5U2pvaERNeDNUYm5PbEgrUUVFL2JKWVZQc3BqUWxvYkUzbmx5Q2Fw?= =?utf-8?B?VVFIYTBYUHB2NXlNM2pRVG1mMlhEUC9pNDFUR1I4enM2YlgwaGluZXBjQW1u?= =?utf-8?B?clZ3WnplaTltZHZvRkVwTGV3L1p5bEI4TUlHeStQQU94aUhRRGRYeWNOaTQ3?= =?utf-8?B?YWVDNnFSMXNsaUUvSlJIZkE3U0pmOU9vakpVTm9LdTVxUGJ0YVhVRHFFU0xH?= =?utf-8?B?UFVYYk82elpsWThKRmZCVnlKL0FQejA0Y2NnejViZmpINFZObWdpcEs2S0d1?= =?utf-8?B?UXA3YlRiSERiY3U4WU5hTXhoczg5anhjYWJ0NEVoemZyYmdrUFFYQTQ5blU2?= =?utf-8?B?KzRqbE1pK2c0TSszZGpmMEtjY3pwOStSRzY1SVJESHBRd0tXdlJxd01KZjVi?= =?utf-8?B?T1dUYmNHcU1LOFZSRE02L0JDZHpSR3pxNmlISlRPaXN3NnEwZjd5NDAyRDgx?= =?utf-8?B?d0ZSYjVhOWZVK0Q5bU80MjhNYjg2MlNIeWpnaHgvYnczYyt5TTIzRDBmTStC?= =?utf-8?B?amNJUXRvQVQ4OFR1ZllieHNMMVlCUWhJTFd5VWVydTV3WUZWNlBYbVRmZVVh?= =?utf-8?B?VGF2cm1SZENNditkU2oxS29xa1VPOVNvbUlhOS9GWDF4STRGU2VMSHdBQVVI?= =?utf-8?B?dEJnUk9HTjRzT3oydy9xMVlCZkV6WENyYUhKZ2RlYklTbDExSlBVRmpFZ3Vl?= =?utf-8?B?VUZCeUpFWlVMMUZlMzVOU0psYURaMndkMzh3S0dUejlpOFRIK0dtTGs1c0NX?= =?utf-8?B?ZUM1WGw4L2JMR2dKdXU3anFveWNwQzNla0NBZmFkWmNCUHhyQitnTXdGVUgw?= =?utf-8?B?RGl3am9iWUMwZ3JiUWN0UXFSYnp4bW50YUVQbkJObVB0TVROcW5obE0zd2sw?= =?utf-8?B?bk5UazBGUnhjT3FMTmpSazRYa2NmdEswUnljdVQxbEpMT0NRbmRxTG9hcjNi?= =?utf-8?B?ZS96NlJ6d05KMFpNcGNpWnJPdG85M1pQM0twWG9vbXkxNEFLUTRXRkFKL0hH?= =?utf-8?B?ZHd3ODRaR0RpQkpxdVR5TWtycFpNeFl6UlVIclQrVHlqRnh6QVdxV2lFdDZm?= =?utf-8?B?RG9aZWJWQzVSeTB0ODZEVHFkUmF1V1dEbzdQdlZjaG5qRnFoZ2o1NXpscGRn?= =?utf-8?B?NVg5VXlLaWpETWpvOVlDc1IxNnh2UHF2cVFZVkpvMFBLTjYyKzlqU0U5U2NR?= =?utf-8?B?NWo2UzBwd3BZNE53S1BXMEZFdlVNcVJ6NXZuNnY4M1BZb2ViNnRLT29VZ3pp?= =?utf-8?Q?mkpxK28Lz+9EBd0HiSXHe0tIIISASYrgEU9JA3h?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8P223MB0125.NAMP223.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: c906dfa0-b6c4-4f17-bacb-08d96bcc47b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2021 15:38:56.9123 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6b03ef08-a104-48c4-a951-f18d295428d5 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: KSADj5BRGxcDRsGTCC5sT5Ds0TqTQJFgqlh02/GN63460e99TR/jUXOqC8W6AOJLQFpS+xgMeMnuot5x1FY6Jz+Lyj9LpcBY0AQvifoQyLg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8P223MB0335 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-07.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 15:39:09 -0000 QnJpYW4sDQoNCkluIHNlY3Rpb24gNy4yIG9mIHRoaXMgZG9jdW1lbnQsIGl0IHN0aWxsIHJlZmVy cyB0byB0aGUgdXNlIG9mIGpDYXJkLg0KDQpUaGFua3MsDQoNCkV1Z2VuZS4NCg0KDQoNCkNPTkZJ REVOVElBTElUWSBOT1RJQ0UuIFRoaXMgZS1tYWlsIHRyYW5zbWlzc2lvbiwgYW5kIGFueSBkb2N1 bWVudHMsIGZpbGVzIG9yIHByZXZpb3VzIGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hlZCB0byBpdCwg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYg eW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVzcG9uc2li bGUgZm9yIGRlbGl2ZXJpbmcgaXQgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9u IG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBhdHRhY2hl ZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3Rp ZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0IGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20gb3IgYnkg dGVsZXBob25lIGF0ICsxICg4MDEpIDI4Ny05NDE5LCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwg dHJhbnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Ig c2F2aW5nIHRoZW0gdG8gZGlzay4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IFJ1bSA8cnVtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2Vu dDogVGh1cnNkYXksIEF1Z3VzdCAyNiwgMjAyMSAxMDowOSBBTQ0KVG86IHJ1bUBpZXRmLm9yZw0K U3ViamVjdDogUmU6IFtSdW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNy50eHQN Cg0KW0VYVEVSTkFMXSANCg0KVGhpcyB2ZXJzaW9uOg0KQ2hhbmdlcyBqQ2FyZCB0byB4Q2FyZA0K U2F5cyBJQ0UgY2FuZGlkYXRlcyB3aXRoIHNwZWNpZmljIElQIHZlcnNpb25zIGlzIGFsbG93ZWQg RG9lc27igJl0IHJlcXVpcmUgTVdJIHN1cHBvcnQgaWYgdm9pY2VtYWlsIGlzIG5vdCBzdXBwb3J0 ZWQgKGFjdHVhbGx5LCAwNiBzYWlkIHRoYXQpLg0KDQpJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBy ZWFkeSBmb3Igd29yayBncm91cCBsYXN0IGNhbGwuDQoNCkJyaWFuDQoNCg0KPiBPbiBBdWcgMjYs IDIwMjEsIGF0IDEyOjA1IFBNLCBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgd3JvdGU6DQo+IA0K PiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KPiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBSZWxheSBVc2VyIE1hY2hpbmUgV0cgb2YgdGhlIElFVEYuDQo+IA0KPiAgICAgICAg VGl0bGUgICAgICAgICAgIDogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2Vy IEVxdWlwbWVudA0KPiAgICAgICAgQXV0aG9yICAgICAgICAgIDogQnJpYW4gUm9zZW4NCj4gCUZp bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNy50eHQNCj4gCVBhZ2VzICAgICAg ICAgICA6IDMzDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDIxLTA4LTI2DQo+IA0KPiBBYnN0cmFj dDoNCj4gICBWaWRlbyBSZWxheSBTZXJ2aWNlIChWUlMpIGlzIGEgdGVybSB1c2VkIHRvIGRlc2Ny aWJlIGEgbWV0aG9kIGJ5DQo+ICAgd2hpY2ggYSBoZWFyaW5nIHBlcnNvbnMgY2FuIGNvbW11bmlj YXRlIHdpdGggZGVhZi9IYXJkIG9mIEhlYXJpbmcNCj4gICB1c2VyIHVzaW5nIGFuIGludGVycHJl dGVyICgiQ29tbXVuaWNhdGlvbnMgQXNzaXN0YW50IikgY29ubmVjdGVkIHZpYQ0KPiAgIGEgdmlk ZW9waG9uZSB0byB0aGUgZGVhZi9Ib0ggdXNlciBhbmQgYW4gYXVkaW8gdGVsZXBob25lIGNhbGwg dG8gdGhlDQo+ICAgaGVhcmluZyB1c2VyLiAgVGhlIENBIGludGVycHJldHMgdXNpbmcgc2lnbiBs YW5ndWFnZSBvbiB0aGUNCj4gICB2aWRlb3Bob25lIGxpbmsgYW5kIHZvaWNlIG9uIHRoZSB0ZWxl cGhvbmUgbGluay4gIE9mdGVuIHRoZQ0KPiAgIGludGVycHJldGVycyBtYXkgYmUgc3VwcGxpZWQg YnkgYSBjb21wYW55IG9yIGFnZW5jeSB0ZXJtZWQgYQ0KPiAgICJwcm92aWRlciIgaW4gdGhpcyBk b2N1bWVudC4gIFRoZSBwcm92aWRlciBhbHNvIHByb3ZpZGVzIGEgdmlkZW8NCj4gICBzZXJ2aWNl IHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3QgdmlkZW8gZGV2aWNlcyB0byB0aGVpciBzZXJ2 aWNlLA0KPiAgIGFuZCBzdWJzZXF1ZW50bHkgdG8gQ0FzIGFuZCBvdGhlciBkZWFmL0hvSCB1c2Vy cy4gIEl0IGlzIGRlc2lyYWJsZQ0KPiAgIHRoYXQgdGhlIHZpZGVvcGhvbmVzIHVzZWQgYnkgdGhl IGRlYWYvSG9IL0gtSSB1c2VyIGNvbmZvcm0gdG8gYQ0KPiAgIHN0YW5kYXJkIHNvIHRoYXQgYW55 IGRldmljZSBtYXkgYmUgdXNlZCB3aXRoIGFueSBwcm92aWRlciBhbmQgdGhhdA0KPiAgIHZpZGVv IGNhbGxzIGRpcmVjdCBiZXR3ZWVuIGRlYWYvSG9IIHVzZXJzIHdvcmsuICBUaGlzIGRvY3VtZW50 DQo+ICAgZGVzY3JpYmVzIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBhIHZpZGVvcGhvbmUgYW5kIGEg cHJvdmlkZXIuDQo+IA0KPiANCj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcnVtLXJ1ZS8NCj4gDQo+IFRoZXJlIGlzIGFsc28gYW4gSFRNTCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLXJ1 bS1ydWUtMDcuaHRtbA0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMg YXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1ydW0tcnVlLTA3DQo+IA0KPiANCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWls YWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLw0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IEktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gSS1ELUFubm91bmNlQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91 bmNlDQo+IEludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sIG9yIA0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4 dA0KDQotLQ0KUnVtIG1haWxpbmcgbGlzdA0KUnVtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0K From nobody Mon Aug 30 08:40:48 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6F83A1718 for ; Mon, 30 Aug 2021 08:40:46 -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 SMO9fbAiLLqp for ; Mon, 30 Aug 2021 08:40:40 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 BB00C3A1715 for ; Mon, 30 Aug 2021 08:40:40 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id g9so20466980ioq.11 for ; Mon, 30 Aug 2021 08:40:40 -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=jRy2qHgAAzH7G+LEoMKNwEU8+U5tHIoGHwPZqfqXZQs=; b=QRs1f0QTh74i+H1DbrZWGPwZ5wH/mzxgsm7N6nHa/f+P7ijuoPO3a7Om1EDcsYBDzb k3DnrWbRLm3aSdezg+rpEU3Nl88w2hCreNLKyT0grl3KqA5tWk3YQPu1/wHojvRVBb4f Wt1qgVkqke54259gs4uyUb182Hru+Qg9eVwDSu5aWExNKzi4TF/jeh+NieK30Kw9dYJ1 9EW+tHRq+D2Y+etHW42NMsYJlKoayLEtOepGGGFjMbGos+j7Me+qBTQpoIviIoqq88K3 KVoNz8/aaodWM9FzdHvVCEx/UIBqWv6zVL+NtYOyUslgluWQrZshUlWkOwzYZ3NTk4bF 08Iw== 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=jRy2qHgAAzH7G+LEoMKNwEU8+U5tHIoGHwPZqfqXZQs=; b=sSFZnA5m0JbhuoDjNuaRIzIyYNmRWZeBfbfSCEeql7Vezgh5Rw2gcWCUUq9pBl05qF mFkpE+uRtdI3BFDqC8epzdU2qVooWs/BCxWUgHahOcQ5k0laD8OIy6YFAFTytvXQDGm1 fF/GLHFwueTOlEABSx90/TQlu71ojqKmgwc5mZlvodaIxDnh0/IZ2ZdE2y3xEagKYD+t L6CgVAJ86Qp+QLORXubSEaWnYjwme4GE9ksVPgYV4a8QqeUUvsmHLIAz9zU6Hahqs3t2 utIJzTPoOc6FVnlwsGbXuir2k25hXVTfy9ZoCed8IGBoTxepUZVrsIfoXzf3KJpi2avF p0mA== X-Gm-Message-State: AOAM530G1ZWfQGvxiaUDtcIXvaaLLPP4QNb9pPYODmdNokOML4MHCbd4 +HXCOBCAQvGBZ/XvUwZsJRjkCQ== X-Google-Smtp-Source: ABdhPJwyDrvRyWfMVa/GAKlorosJHGXVAUyISMvP10ciBCLq1zmOnYK0C4SfCURfZ26lprHylwcg5Q== X-Received: by 2002:a05:6638:521:: with SMTP id j1mr20614294jar.122.1630338038949; Mon, 30 Aug 2021 08:40:38 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id m10sm8705539ilg.20.2021.08.30.08.40.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Aug 2021 08:40:38 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: Date: Mon, 30 Aug 2021 11:40:36 -0400 Cc: "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <162999394987.8364.12786299587813953324@ietfa.amsl.com> <2FF112A2-C501-4D0F-8DBE-7E5D12E860E4@brianrosen.net> To: Eugene Christensen X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-07.txt X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 15:40:47 -0000 Sorry about that, I will fix it. Brian > On Aug 30, 2021, at 11:38 AM, Eugene Christensen = wrote: >=20 > Brian, >=20 > In section 7.2 of this document, it still refers to the use of jCard. >=20 > Thanks, >=20 > Eugene. >=20 >=20 >=20 > CONFIDENTIALITY NOTICE. This e-mail transmission, and any documents, = files or previous e-mail messages attached to it, may contain = confidential and proprietary information. If you are not the intended = recipient, or a person responsible for delivering it to the intended = recipient, you are hereby notified that any disclosure, copying, = distribution or use of any of the information contained in or attached = to this message is STRICTLY PROHIBITED. If you have received this = transmission in error, please immediately notify me by reply e-mail at = echristensen@sorenson.com or by telephone at +1 (801) 287-9419, and = destroy the original transmission and its attachments without reading = them or saving them to disk. >=20 > -----Original Message----- > From: Rum On Behalf Of Brian Rosen > Sent: Thursday, August 26, 2021 10:09 AM > To: rum@ietf.org > Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-07.txt >=20 > [EXTERNAL]=20 >=20 > This version: > Changes jCard to xCard > Says ICE candidates with specific IP versions is allowed Doesn=E2=80=99t= require MWI support if voicemail is not supported (actually, 06 said = that). >=20 > I think the document is ready for work group last call. >=20 > Brian >=20 >=20 >> On Aug 26, 2021, at 12:05 PM, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Relay User Machine WG of the IETF. >>=20 >> Title : Interoperability Profile for Relay User = Equipment >> Author : Brian Rosen >> Filename : draft-ietf-rum-rue-07.txt >> Pages : 33 >> Date : 2021-08-26 >>=20 >> Abstract: >> Video Relay Service (VRS) is a term used to describe a method by >> which a hearing persons can communicate with deaf/Hard of Hearing >> user using an interpreter ("Communications Assistant") connected via >> a videophone to the deaf/HoH user and an audio telephone call to the >> hearing user. The CA interprets using sign language on the >> videophone link and voice on the telephone link. Often the >> interpreters may be supplied by a company or agency termed a >> "provider" in this document. The provider also provides a video >> service that allows users to connect video devices to their service, >> and subsequently to CAs and other deaf/HoH users. It is desirable >> that the videophones used by the deaf/HoH/H-I user conform to a >> standard so that any device may be used with any provider and that >> video calls direct between deaf/HoH users work. This document >> describes the interface between a videophone and a provider. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-rum-rue/ >>=20 >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-rum-rue-07.html >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-07 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html or=20 >> ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Aug 30 14:07:03 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C106A3A2269 for ; Mon, 30 Aug 2021 14:07:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 GzYAmNeKIKim for ; Mon, 30 Aug 2021 14:06:57 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2063.outbound.protection.outlook.com [40.107.237.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 22D663A2266 for ; Mon, 30 Aug 2021 14:06:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UaBm+M1CW0/nqVqVosZDln8beGWA+5EdrBlAe3zYifSMm0770C00gtfPtX7q48U6YArKbFBbgDuE04wffygweSnbpFfXi6ARvxZqtd023dKCRQHmFiUl/RJD+eCDo6cA+fXMsG29B499JZH4b6SxiD0TY9tyHVozKhHg+OPa19zhDXyNimV0rrOZqgrhMpw1Cf8wAxZaAtzeWafFfg4LPS2/phhSV61cW4IKFFKOsqFfL0zeaNWvBtYhZcrlOVSr5Lx9wnX1BlRISNDZuVlQXZ5EJfDWvh/zOFuUBDWDYqdtW09ozMHswiaqV2jHkf6pxDRtWXOG1w+1p9ccU6Lw5w== 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=9YjTRAW5qsGQhXeJoc4f4MILntpjt+C6rCnla4y+meA=; b=MxUnAbYo9gfMJrCOKNZqPenc8OwrB62STEqU0u/ntCvmQQd+JZvmjojqYFLlL+ejXb6cEorjmULHzIoV++zL0TegphDOxCyMIJMDPxYpTPKRVWB0s4yvgQ84f4MK7TiE5jHZbVb11UwUhJHr4zVVzdQ+HKeTknIeeUMnl/HSavZco3+x9+7z5E7U0KWqzQLAo6A7mZMYx0sd8FQ5/PnhhNPruxnn4xPrPcMY766HS/3jRW+p/fUwqd2TYDR2e1A8G6jjmiurg6Wt0rq/DhrUKdL/Il+k3npfwlZgp6RodHBrR+XRPErm66XAEKKHlx/MC5Fwp7rWG5vmNrFTbpTpzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=convorelay.com smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=9YjTRAW5qsGQhXeJoc4f4MILntpjt+C6rCnla4y+meA=; b=Ragds/YkLN3qIbm4nW8NWFwX5u/gOlTCVtDkPvB5Q/MIxWPwnIZGDwuRwwZqmypmlg87GTspzdj1iZJR7R93a0mw5TiJKV2uo/T6efYiHyOaCcSyOt/7KU87rkojaP5AcRpHq/GoCR7trVByCoa6spYVzAcO3kq8HrdmLPY99lc= Received: from DM5PR18CA0057.namprd18.prod.outlook.com (2603:10b6:3:22::19) by DM5PR12MB1482.namprd12.prod.outlook.com (2603:10b6:4:a::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17; Mon, 30 Aug 2021 21:06:53 +0000 Received: from DM3NAM02FT052.eop-nam02.prod.protection.outlook.com (2603:10b6:3:22:cafe::a2) by DM5PR18CA0057.outlook.office365.com (2603:10b6:3:22::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.18 via Frontend Transport; Mon, 30 Aug 2021 21:06:53 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; convorelay.com; dkim=none (message not signed) header.d=none;convorelay.com; dmarc=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT052.mail.protection.outlook.com (10.13.5.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Mon, 30 Aug 2021 21:06:52 +0000 Received: from MacBook-Air.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 17UL6o10020092 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 30 Aug 2021 17:06:51 -0400 To: Chad Leeper Cc: rum@ietf.org References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> From: Paul Kyzivat Message-ID: <365d7a64-e552-7f88-11c0-d47e26ece467@alum.mit.edu> Date: Mon, 30 Aug 2021 17:06:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.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-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 405d98e2-7d9b-4273-b8d3-08d96bfa1775 X-MS-TrafficTypeDiagnostic: DM5PR12MB1482: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 8XzTGQGXLq4qhkNvSI+zOLOAtU3uU5V4OwfqUoZsBGlO2vg56nXbCdyW9y60rEMdRZejZschh74x4J642JuqrMESxls6qPmRveUtWtXz1ww8ILQTQLaqPz1GiEHH2c5GsmtTYZPopx+0TY0XeePMdshr7sXzC/OAC5Blwgyzmpaw/PTnl3H21SPysM2hFCzDjlYnCVGiyPn5jHMKr1k6alLGLgbMzrLYmrbFedYcyXRxMOROX+OYOaPOWJ8SgO8YW+umR6wYRpXGj3f4dCr6FWiXSYZiULg4IPF3uKs/yGBLyL6FxYVq1tNZ3nwuKKPHETxBkWWSPJnN9pDCuzBwh8GgcMc7SzRQfz3mS9d2z7qc0himeeF3Zkp9HnweLOsz0h7LybtPbBj3QyU1hwKDxzfndhxKiL9yGzkFFB8Jw+Byrlj/KfRJKtmvQVSlq+swBXbbdaMzYbuljaF0gM1fPBaeg1kXcpL7QPppo8ncjw/O7fSLO+nVyp2HmglJahMZASaxBxE3yM7tuifHrSV1oxBfjRTgR6wzSQP6r7kCr0eI49j8rvytIJbC+LXzOuW+bKEEjWVZGTCbMqQ8ABGkq3FWk8QG5Sozere7PdRKtEyb3ddgQEtTwMZo+2po3/Mt07soUfwhM2at6HNdii5Cpf8ytpNbsj/Nlc1qyljENv9MTzZ6xbXFAvf3oRwvaS0yzRjxsq/RoXrLFW7wtPxeN1hfQJPHyWyHQ7nIxSnC3dnNBdL3ef4yVBE+TOol4WxDeVWKa387S8QxDupC+Xez2mbPHPy+CXsv6jYamOuc2qhNN9EJiH6rK6nI9/pm3T8K 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; SFS:(346002)(396003)(39860400002)(376002)(136003)(46966006)(36840700001)(5660300002)(66574015)(31696002)(26005)(53546011)(47076005)(956004)(7596003)(8936002)(478600001)(2616005)(4326008)(356005)(86362001)(75432002)(82310400003)(36860700001)(36906005)(8676002)(6916009)(786003)(186003)(316002)(82740400003)(70586007)(83380400001)(31686004)(2906002)(336012)(966005)(70206006)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 30 Aug 2021 21:06:52.7603 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 405d98e2-7d9b-4273-b8d3-08d96bfa1775 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-AuthSource: DM3NAM02FT052.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1482 Archived-At: Subject: Re: [Rum] IPv6 and encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 21:07:02 -0000 Chad, Welcome to the RUM WG! On 8/30/21 11:51 AM, Chad Leeper wrote: > - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going > forward, it can't be a "MUST" requirement.  I agree with Roger Slusser > that mandating compliance using MUST requires providers to implement > significant development to change over to what RUM is specifying. The requirements in this doc will apply only to devices that claim to conform to it. Presumably you could continue to support your existing devices using whatever mechanisms they currently use. So the implementation burden is only on the server side, not the legacy device side. (Of course the FCC will have a say in this.) One motivation for the webrtc requirement is so that a RUE can be built on top of WebRTC. E.g., it can be a server that supports deaf users using any device with a browser. Such a server is effectively just signaling gateway that can establish a p2p link between the browser and the VRS provider server. (It does have to transcode RTT, but that is less of a burden.) When defining a specification for an interface that is to be implemented by independent parties it is necessary for essential functions to have at least one mandatory to implement mechanism. Currently there are no standards for connecting a RUE to a provider, so we need to pick *something* to be mandatory to implement. If you have an alternative for the media you would prefer, then please make a specific proposal. > - We should keep any new privacy requirements very minimal at this > time.  While companies in the EU have already created their systems in > compliance with the GDPR, most of the world hasn't created an equivalent > yet.  So what may look like an easy change to EU implementers may be a > dramatic change for others. I don't think we have said much about privacy of retained data. But we are concerned that the media and signaling be private between the RUE and the provider. That is a low bar these days. It is unlikely that anything less could be approved. I expect the FCC will agree. If you have an alternate proposal that achieves that then make a proposal we can discuss. Thanks, Paul > On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > wrote: > > Providers, > > My request below to Roger should have been broader. You all seem to > have > the same issue. I encourage any/all of you to make an alternative > proposal here. Just saying "we don't like what is there" isn't helpful > without an alternative. > >         Thanks, >         Paul > > On 8/26/21 5:40 PM, Paul Kyzivat wrote: > > Roger, > > > > On 8/26/21 3:30 PM, Roger Slusser wrote: > > > >> Most providers already support encryption and IPV6 on a limited > scope, > >> not necessarily the way it is defined in RUM spec. Mandating > >> compliance using MUST requires providers to discard sometimes huge > >> amounts of development to change over to what RUM is specifying. > The > >> push back is not about doing these things it is about the loss of > >> time, effort and money to do them in the way RUM mandates with > MUSTs. > > > > Do you think there is something else we could write in this spec > that > > covers encryption and IPv6 in a way that is less burdensome for > > providers while remaining interoperable with all providers? > > > > If so, can you please spell it out? > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > From nobody Mon Aug 30 14:24:33 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50EC3A232E for ; Mon, 30 Aug 2021 14:24:23 -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 Y92fzD7ljPxl for ; Mon, 30 Aug 2021 14:24:18 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 89EBC3A233C for ; Mon, 30 Aug 2021 14:24:14 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id h29so17827514ila.2 for ; Mon, 30 Aug 2021 14:24:14 -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=LuL5Jfh8/vzDVksTzbvK7fIED9ypRQG47zrFQQ4iiTU=; b=O3eSx6e/LEpzimp7rZkgzo8WmigzMr8dZ0T2y1EhGhBQhxvFgafktknfx4jxydsQhQ LM8h4r2Sxh/u2Uwi7d1UkssPlkBDCPdNQdMz2oAc3L1FPxYJShGYoXi+e3kQGgUMfreF EVxY/OxoseZZNQw8fZvyesdZh6Frs+xOTahS80M+FbeSkSlNSaDQO+89VpSPsepkx8CM ng7aZWDLtYHQxJqaVJiE50GYuZ/eIHwtxY8jAehi36t7jhQc+T8V5GSVvqyRe0Mx9663 FxbZ61M1wgxR4VzymJBCz56xT22Lyx5ltfT29Pyk9xEGRziK3narfTv50VXcIFpp1ecJ 37+A== 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=LuL5Jfh8/vzDVksTzbvK7fIED9ypRQG47zrFQQ4iiTU=; b=IIIgXfekUFlLRcuf7k0iLjgjbbuReRJ64r+d6EPPanrpU7ZqxkYOmTjfzqMJr0R6ZS vD5UqE4LNiTJnmiIgVqw/Fp1NebXiwuis6YRqsrGQJ7wcY9MpHozuvxn4jWyVKBRBkrO xt59XQlc0ZR6HMjc/+W6LuhVVsqF6DmU7bQZRktHALNC6Bu3qfZ+y6OCihDghjtAQE1G cGoEKsrgXiECpHoSQk/zssWpCrLz4QmHfo1w7SLhJ0qGZmZ3MRll1qb0NCXyQ7SOdXPR anYbbzaXIO8dRaemg669MX61jrOGmiu5VCzK7QA7uwylwWAgcopKVPR1VCT5xyKYescT suDw== X-Gm-Message-State: AOAM532m0uRkGB++vuWqR0VzJaeoJTQrLUOmFXz5bm78LxVLy2N+bKtW 2bHGeJ8jciyJEVxunIyabvGXiA== X-Google-Smtp-Source: ABdhPJwCnS+IPknD4vGNagSGKcp/NSR4Fjcao2eNQsoe8+AvdnL9eIqbZPHCrCHFPgDbjmXzuinMJA== X-Received: by 2002:a05:6e02:b4b:: with SMTP id f11mr17479069ilu.3.1630358652903; Mon, 30 Aug 2021 14:24:12 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id p13sm9274052ils.69.2021.08.30.14.24.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Aug 2021 14:24:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) From: Brian Rosen In-Reply-To: <365d7a64-e552-7f88-11c0-d47e26ece467@alum.mit.edu> Date: Mon, 30 Aug 2021 17:24:11 -0400 Cc: Chad Leeper , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <4C5606A6-7137-43C5-8404-D712B716962E@brianrosen.net> References: <53784b11-70ec-8161-a2b2-01fce0cf2e2a@alum.mit.edu> <8E3107E9-FBEB-4145-8B64-A7527D7C1C2B@edvina.net> <90447B5D-43C9-4967-90D1-521C9EFB1244@edvina.net> <21b89f7f-11a3-95e4-dc31-233893a03b53@alum.mit.edu> <365d7a64-e552-7f88-11c0-d47e26ece467@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3654.100.0.2.22) Archived-At: Subject: Re: [Rum] IPv6 and encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2021 21:24:32 -0000 I don=E2=80=99t think there are ANY alternatives to SRTP. There are = alternatives to DTLS-SRTP. There are moves within the IETF to deprecate = SDES, specifically. There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. Since all = providers I know about anchor media, this only affects the initial hop. = Users really want to hear that their media is protected end to end (at = least hop by hop) but our document doesn=E2=80=99t require that. Again, = we need a STANDARDS based solution, and we have to live within the = constraints the IETF has for new standards with respect to security. = Like nearly every organization, the IETF is much more security conscious = than it was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism. =20 I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. = We=E2=80=99ve spent lots of time and cycles implementing things that = turn out not to be secure enough, and we have to move forward on things = that are. DTLS-SRTP is one of those things, as is IPv6. Brian > On Aug 30, 2021, at 5:06 PM, Paul Kyzivat = wrote: >=20 > Chad, >=20 > Welcome to the RUM WG! >=20 > On 8/30/21 11:51 AM, Chad Leeper wrote: >> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going = forward, it can't be a "MUST" requirement. I agree with Roger Slusser = that mandating compliance using MUST requires providers to implement = significant development to change over to what RUM is specifying. >=20 > The requirements in this doc will apply only to devices that claim to = conform to it. Presumably you could continue to support your existing = devices using whatever mechanisms they currently use. So the = implementation burden is only on the server side, not the legacy device = side. (Of course the FCC will have a say in this.) >=20 > One motivation for the webrtc requirement is so that a RUE can be = built on top of WebRTC. E.g., it can be a server that supports deaf = users using any device with a browser. Such a server is effectively just = signaling gateway that can establish a p2p link between the browser and = the VRS provider server. (It does have to transcode RTT, but that is = less of a burden.) >=20 > When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal. >=20 >> - We should keep any new privacy requirements very minimal at this = time. While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet. So what may look like an easy change to EU implementers may be a = dramatic change for others. >=20 > I don't think we have said much about privacy of retained data. But we = are concerned that the media and signaling be private between the RUE = and the provider. That is a low bar these days. It is unlikely that = anything less could be approved. I expect the FCC will agree. >=20 > If you have an alternate proposal that achieves that then make a = proposal we can discuss. >=20 > Thanks, > Paul >=20 >> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > wrote: >> Providers, >> My request below to Roger should have been broader. You all seem = to >> have >> the same issue. I encourage any/all of you to make an alternative >> proposal here. Just saying "we don't like what is there" isn't = helpful >> without an alternative. >> Thanks, >> Paul >> On 8/26/21 5:40 PM, Paul Kyzivat wrote: >> > Roger, >> > >> > On 8/26/21 3:30 PM, Roger Slusser wrote: >> > >> >> Most providers already support encryption and IPV6 on a = limited >> scope, >> >> not necessarily the way it is defined in RUM spec. Mandating >> >> compliance using MUST requires providers to discard sometimes = huge >> >> amounts of development to change over to what RUM is = specifying. >> The >> >> push back is not about doing these things it is about the loss = of >> >> time, effort and money to do them in the way RUM mandates with >> MUSTs. >> > >> > Do you think there is something else we could write in this = spec >> that >> > covers encryption and IPv6 in a way that is less burdensome for >> > providers while remaining interoperable with all providers? >> > >> > If so, can you please spell it out? >> -- Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Tue Aug 31 02:30:12 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1140D3A3CAB for ; Tue, 31 Aug 2021 02:30:10 -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, 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=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9nQkSEbH8iE for ; Tue, 31 Aug 2021 02:30:04 -0700 (PDT) Received: from stmail.purple.us (stmail.purple.us [54.177.79.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 241E43A3CA2 for ; Tue, 31 Aug 2021 02:30:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail.purple.us (Postfix) with ESMTP id D3F5D1A1C01; Tue, 31 Aug 2021 04:35:48 -0500 (CDT) Authentication-Results: stmail.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=BmS3iN74 header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2168.outbound.protection.outlook.com [104.47.58.168]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail.purple.us (Postfix) with ESMTPS id 687641A1C02; Tue, 31 Aug 2021 04:35:48 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ofgvrpK8kOLQiAF4CtQhlPTJQqAD1hj4xOtsSJCSPWKzyrB+DxJZdLKq0bGppWLCFXbuLuiXUwZvlAj4Bh/MDBZoF+adgcKv8YXfyLilay6d/mx5i9/iJjx7hnCmtEqidFN/zfJUSVqpBOS28pqrRc2SskDsMxFK+Xtrmpvupo9CEA/JqcHreSWAZQItsqEnV6eymoubrQklUc2vcoVBg8VAVB2wARQcI8yTDlFBOUlWhhd0TbYE2E3nPKU9JCskN3grduvnlsAJQsWKfEw3UoHVKlSYYzSMqem03GRmBgi3h1cH8GcaTIkI8SzQv0olkepX3BKwMkKYDD3iFupwvw== 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=tO3HS4/vA3TPF7TGfTTvSccTNNSalWOmfCj76Up10R8=; b=USrBGlLXWFW7Y3avgfsRN9idwLkOG+wNAO6l5IoLHQMnqTTpSg/reMFAEMFXw3A1CBLlvuwn4vaIiCBdVtdClxIY3JmN4crGzONbcQiVpFvJgsglQ44NDU3IiAkz1WkmL3JTPQjTZikX/gU4K7gTClmkZKMOlPP1onCUUX07dSxt88Bk0P8o4oIGGlfS2axrDER434C1OsCYVjgRaCOdiZW/xEFIpCbd6U1geys48Bwwl7MWOJ7+rIFOroU71atz2MPxyUX5oZ/0ihwSFcap6ZXnTbq35R02k8KPJUW/zWWnD+1P+qtxjNPvGcn1kzlK2ZpB6BoNX+89cG9Awkvdzw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tO3HS4/vA3TPF7TGfTTvSccTNNSalWOmfCj76Up10R8=; b=BmS3iN74NHD+fxGyNA92F76MBicIX2gyP37NWfe/f81ALy8aizMCeNhGcv+guegaRsYTQKAHuF00fvE/PdDmo1NL9uOGRHyC7h7Kd+BxB8rNyUmlZV4ibwox5mB5Cxb7wWKp/L1d7+D4zB8Kv7jq1tJ88mAtdfPnfTaclBcargI= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM6PR19MB2586.namprd19.prod.outlook.com (2603:10b6:5:183::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.24; Tue, 31 Aug 2021 09:29:59 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 09:29:59 +0000 From: Ed Sayers To: Brian Rosen , Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] encryption Thread-Index: AdeeR7wCxTV6yTDtS7ecSm7HwjQ0zQ== Date: Tue, 31 Aug 2021 09:29:59 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 637fcdeb-234f-48d1-7723-08d96c61e743 x-ms-traffictypediagnostic: DM6PR19MB2586: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fJoT5wlsochBMPt3vmyjdyyFN6nskOE7VD9BczDKWpcehIBoIaBD8mDf/AauLYS9b212xhNaH9q3AtyE8xrC9vw6+z5AtTy6ZbyXF0yg3HYO9+mWG5HSN3swpcLXfwxmW4BRlF246DDWa/h3uf61tAUumO/kn5Ycz+QMFBp5wSn0LPOhQdXnpJPPS/Vp6nRLfu29zx0uzoSe0bD4bhgqBXaF3u5Dy5dCLwODfJyk9wdVmr5Nh02xFn8f3KEPB4Mho+Zc9pzWw6VhRHVyTN7vPycM8Re9IPEnvA5OLT8tUMpCTrO+n9ZcxPc/WZ5xlRJ3x3mfNKoKFl5nhyxQ8jckPANVP0DdSfMmEHwh8XffunwpIc1IKRhYu2YnrbMSuRYF0ozirE8ZehkR6lfjLDzCEMgKS18rBJDV7qEGHnmyj+HwAjMd+NwdmzrCiZvyQqhLk889fYVyO6WWaPTwjlZq7nmncxrSvk7++dpKr2XBIWdukExjjyDdaVQcXoije3LhKx9cMV3CpxDKA9bYwLNN9RjFaTrGPc89wPYmBePF9iCmrg5jJ/Qar3HBZP1lhTcFZKxvWy5HsAKDavL3iU+ukWFf7p8lw6Lrr5klynZYvJ/iDyhLsZu2lRbYmIrnJc8JEDG1pBwfP5ROqT0+VNCIcB/r0uDbF8BFtYIw7ga5BpC0rfmmCzuVrmfuvB33u94Vpead0MyMQICQTRmfS4ByjnXB3XSBg2JQBwzufjfZzfYV+V/RofP3xEQI7m2Phi+MzpaN8LN7nG+XmXj/+HTArGivfZm54gEX8WERAWEGIhKjAeVMBF3Fdiku5mZkSBJP x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(396003)(346002)(136003)(39850400004)(366004)(966005)(86362001)(8936002)(2906002)(26005)(6506007)(53546011)(33656002)(9686003)(55236004)(7696005)(8676002)(110136005)(316002)(66946007)(44832011)(478600001)(5660300002)(64756008)(186003)(71200400001)(38100700002)(52536014)(66556008)(55016002)(66476007)(76116006)(66574015)(38070700005)(66446008)(83380400001)(4326008)(122000001)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eWpsWkRyVFlLNmdhWTZmWitNeHh0dWRTTzVMMnRCbmFSL1hJbElpcE1FOXI1?= =?utf-8?B?RWNsRXY4NGhHeFQxODlnK1llbjQwa2ZBZnc5UDBFKzArREtNdTF1UVJ0UUVU?= =?utf-8?B?MGNJRUtZSytOY2RKUXBlekZUMzM5bVBxUk9ldDdYb1VDTUZyVjM3YnNvTDA2?= =?utf-8?B?RnRPMlBWMHdDU3pOclNXNWhXeWxxcUd1MmowUDg4akVHNSs0SFNBZzIxalo3?= =?utf-8?B?UGExcWRSZUsxYVdTQTd6ZWcrVlFDQXBNeklkaVU1Q3BVR3ZZc3M1MVh6OGxM?= =?utf-8?B?dUNOOG1BeElkdkRlSTBpbnVDNG5lM29oZ2JHaFFFMDNrRXFPY1hHbzVvNlBG?= =?utf-8?B?N2VZc1hFeThtblJ0SzU4d1NzVXpTcDZUYnNiMDAwNlBwRUJrTExJcGRHWW5Y?= =?utf-8?B?Z3JFKzNKUUoraWtmZlhaZHB4TzNVR2lNSitZMDgremVpcE05Q0NvaUIwVUYz?= =?utf-8?B?b3Jtc2t5UnJEam91N094aE85NWtQT2V2eXhxemRRTnluL2FVOExzWTVMMjZi?= =?utf-8?B?UTRXNEFXOHhDbjZLc2lWYnVURkVHWlE0ZVlnMWdGK29DNlBSdXVHanRDSmlZ?= =?utf-8?B?dFdDcHNyOHNwSzUwVVhJNGw3M1lqaHo1Mm10c0ZiQXRpZFhnUmNRcXNleElh?= =?utf-8?B?dmJtMHNxVW9oNEw2NnlBMUtKU01nN0IzMzdlZ0srMmtxNmh2RjJBaGgyRTJh?= =?utf-8?B?RjRYcEVkRS9CTDdQb0hTMEZwSjY4KzlibjY0Qk9Lek05ckY4UVkvdTM1WUVJ?= =?utf-8?B?TUNhWmtyQWQ1RlNQNWRpM25GOGx5TDBENU1PWHR6TTRNTGhwajdOeHBlMFl2?= =?utf-8?B?WW5idERXQjluUVRYQzc4NUdDZ1FSSE5wMWZ2WGFFY1lSbFFmVWNJbkxVcmxY?= =?utf-8?B?YUR4TVNtckdVeXZNZ2RwNXNiOVVmSDRyalZEcEFqaVBMb2xuUVE5Ry9qcHlr?= =?utf-8?B?NGNiL3YzU0hRTmNsb2lhQ25sd1hZejNhajVqRTlRSHlhdkgzK0NrQkxZNkVN?= =?utf-8?B?Z3hhQUczOVFHRnIzd21LOWZ5T1BQR2hLR3RLQ3VncmZUUXl2c25sOXNXTXlq?= =?utf-8?B?UjU2bW1BOFFCU0FIVVArcUEyMng5d3ZOeEJNWGFnNFdQZi9LSFI5Y25jbEly?= =?utf-8?B?V2RBdEdKcG1MMnFXZlBuMnhKYWxaSTR1Ly9naEZkeVhZc2dBTmZhZWFQUVV1?= =?utf-8?B?Mm5JaE1iTmt4QTlLQy9pem1GbC9pOWpvU3JoUGRVVmJvdXBidEtXbXhLUFZa?= =?utf-8?B?dWlkeDgrMWNYc1BSWGlSeWVaOEo1c3k5SVFrT0NRNXlMODRQMitJUFAvcGVk?= =?utf-8?B?L0RHaVBJZlVIems2MDJ5OFJTczZrcjkyQ25FV1NMb0x6bzhldkF1U3R4Y3Y0?= =?utf-8?B?Z2Fvbm5hclUwWnJ5ekJ5UFF0clFjOWlaWUhUTFlYRmpvZjlKVzR5SWR2Rzd5?= =?utf-8?B?UDJFd1YvdWxJVXRPZ3M4Vm5YNDRQa0l6MmdJLzhCN2crUFh4MzJpSWF0NTcx?= =?utf-8?B?RXZjblZjaXJLMCtURjNtelg1bG94aFB5RWdLdmo0QkNnendEWkFNdW5qbEQw?= =?utf-8?B?T2FsY2V6VHBFZG9rUWRqUTBVQ3cxVkxmUDFLdTRudlUzSmhhbzk3eklEaDF0?= =?utf-8?B?amY3NFlRTnRKcDJsM1BPbEo0TUFlZjlaWnN5cHBEd1V3bnhhMkhoRUpyd2ZP?= =?utf-8?B?SG5yR2ZnM2d1SkF4MTRmeHlVTnJ2Y1l1OVRMa2YxY2t3aDlkUk12a2E2UUlS?= =?utf-8?Q?JYKxM3fuQjEauykux/NzmQLtuDuiX8fu4LDb/EH?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 637fcdeb-234f-48d1-7723-08d96c61e743 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2021 09:29:59.5399 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uAhOnN4oxRgQOpQcPBM79sfhwPY5fCczz//tAzj3k0N06ra2+cRumcrPLg3adb/uzbo2ds0N9+kVICy05/mSkA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB2586 Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 09:30:10 -0000 SGksDQoNClRob3VnaHQgSSdkIHNwbGl0IG91dCBJUHY2IGFuZCBlbmNyeXB0aW9uIGFzIHNlcGFy YXRlIHBvaW50cy4uDQoNCkZvciBlbmNyeXB0aW9uLCB0aGUgVVMgVlJTIFByb3ZpZGVycyByZWNl bnRseSBjcmVhdGVkIGEgbmV3IFByb3ZpZGVyIEludGVyLU9wZXJhYmlsaXR5IFByb2ZpbGUgdGhh dCBub3cgc3BlY2lmaWNhbGx5IGFsbG93cyBmb3IgZW5jcnlwdGlvbiBhbmQgSUNFLCBhbW9uZ3N0 IG90aGVyIHRoaW5ncy4NCg0KV2hpbHN0IHdlIGFsbCBhZ3JlZWQgdGhhdCBTUlRQLURUTFMgaXMg dGhlIHJpZ2h0IHdheSB0byBnbywgd2UgZGVjaWRlZCB0byBzcGVjaWZpY2FsbHkgYWRvcHQgUkZD LTg2NDMgT1NSVFAsIGJlY2F1c2UgdGhpcyBhbGxvd3MgZm9yIHRoZSBncmVhdGVzdCBmbGV4aWJp bGl0eSBhbmQgZ3JlYXRlc3QgY2hhbmNlIG9mIHN1cHBvcnRpbmcgZW5kLXRvLWVuZCBlbmNyeXB0 aW9uLCB3aGlsZSBzdGlsbCBzdXBwb3J0aW5nIGEgaGV0ZXJvZ2Vub3VzIHJhbmdlIG9mIGRldmlj ZXMuDQoNCldoaWxzdCBpdCBpcyB0cnVlIHRoYXQgZW5jcnlwdGlvbiBjb3VsZCBiZSB0ZXJtaW5h dGVkIG9uIHRoZSBSVUUgaW50ZXJmYWNlIHByb3h5LCBhbnkgUHJvdmlkZXIgdGhhdCB3YW50cyB0 byBhbGxvdyBlbmNyeXB0aW9uIGZ1cnRoZXIgaW50byB0aGVpciBJbmZyYXN0cnVjdHVyZSBpcyBn ZW5lcmFsbHkgZmFjZWQgd2l0aCB0aGUgcG90ZW50aWFsIG5lZWQgdG8gZm9yayBjYWxscyB0byB2 YXJpb3VzIGRldmljZXMsIHBvc3NpYmx5IG9ubHkgc29tZSBvZiB3aGljaCBzdXBwb3J0IGVuY3J5 cHRpb24uIFVzaW5nIFJGQy01NjczIGFsb25lIHdvdWxkIG1lYW4gdGhhdCBvbGRlciBkZXZpY2Vz IHRoYXQgZG8gbm90IHN1cHBvcnQgZW5jcnlwdGlvbiB3b3VsZCByZWplY3QgdGhlIGNhbGwgYXMg dW5zdXBwb3J0ZWQuDQoNClVzaW5nIE9TUlRQIGlzIGJ5IGZhciB0aGUgc2ltcGxlc3QgYW5kIG1v c3QgY29udmVuaWVudCB3YXkgdG8gZm9yayB0aGUgY2FsbCBhbmQgc3RpbGwgZW5zdXJlIHRoYXQg dGhlIHdpZGVzdCByYW5nZSBvZiBlbmRwb2ludHMgY2FuIHJpbmcuDQoNCkNoZWVycywNCg0KDQpF ZCBTYXllcnMNCkVuZHBvaW50IFNESyBUZWFtIExlYWQNClB1cnBsZSwgYSBEaXZpc2lvbiBvZiBa UCBCZXR0ZXIgVG9nZXRoZXIsIExMQw0KcHVycGxldnJzLmNvbQ0KDQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhl IHBlcnNvbmFsIGFuZCBjb25maWRlbnRpYWwgdXNlIG9mIHRoZSByZWNpcGllbnQocykgbmFtZWQg YWJvdmUuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwg cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwsIGFuZCBkZWxldGUgdGhlIG9y aWdpbmFsIG1lc3NhZ2UuDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NClNl bnQ6IDMwIEF1Z3VzdCAyMDIxIDIyOjI0DQpUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVt Lm1pdC5lZHU+DQpDYzogQ2hhZCBMZWVwZXIgPGNoYWQubGVlcGVyQGNvbnZvcmVsYXkuY29tPjsg cnVtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1J1bV0gSVB2NiBhbmQgZW5jcnlwdGlvbg0KDQpJ IGRvbuKAmXQgdGhpbmsgdGhlcmUgYXJlIEFOWSBhbHRlcm5hdGl2ZXMgdG8gU1JUUC4gIFRoZXJl IGFyZSBhbHRlcm5hdGl2ZXMgdG8gRFRMUy1TUlRQLiAgVGhlcmUgYXJlIG1vdmVzIHdpdGhpbiB0 aGUgSUVURiB0byBkZXByZWNhdGUgU0RFUywgc3BlY2lmaWNhbGx5LiAgVGhlcmUgaXMgcHVzaCBi YWNrIG9uIHRoYXQsIGJ1dCBpdOKAmXMgYW4gb25nb2luZyBkaXNjdXNzaW9uIGJlY2F1c2UgU0RF UyBpc27igJl0IHNlY3VyZSBlbm91Z2guICAgU2luY2UgYWxsIHByb3ZpZGVycyBJIGtub3cgYWJv dXQgYW5jaG9yIG1lZGlhLCB0aGlzIG9ubHkgYWZmZWN0cyB0aGUgaW5pdGlhbCBob3AuICBVc2Vy cyByZWFsbHkgd2FudCB0byBoZWFyIHRoYXQgdGhlaXIgbWVkaWEgaXMgcHJvdGVjdGVkIGVuZCB0 byBlbmQgKGF0IGxlYXN0IGhvcCBieSBob3ApIGJ1dCBvdXIgZG9jdW1lbnQgZG9lc27igJl0IHJl cXVpcmUgdGhhdC4gIEFnYWluLCB3ZSBuZWVkIGEgU1RBTkRBUkRTIGJhc2VkIHNvbHV0aW9uLCBh bmQgd2UgaGF2ZSB0byBsaXZlIHdpdGhpbiB0aGUgY29uc3RyYWludHMgdGhlIElFVEYgaGFzIGZv ciBuZXcgc3RhbmRhcmRzIHdpdGggcmVzcGVjdCB0byBzZWN1cml0eS4gIExpa2UgbmVhcmx5IGV2 ZXJ5IG9yZ2FuaXphdGlvbiwgdGhlIElFVEYgaXMgbXVjaCBtb3JlIHNlY3VyaXR5IGNvbnNjaW91 cyB0aGFuIGl0IHdhcywgYW5kIHdvbuKAmXQgdG9sZXJhdGUgYmFkIHNlY3VyaXR5IGFsdGhvdWdo IGl0IG9mdGVuIHJlY29nbml6ZXMgdGhlIG5lY2Vzc2l0eSBmb3IgYmFja3dhcmRzIGNvbXBhdGli aWxpdHkgYXMgbG9uZyBhcyBpdOKAmXMgbm90IHRvIGEga25vd24gaW5zZWN1cmUgbWVjaGFuaXNt LiAgDQoNCkkgcmVhbGx5IHRoaW5rIHRoaXMgaXMgYSDigJxzdGVwIHVwIHRvIHRoZSBiYXLigJ0g dGhpbmcuICBXZeKAmXZlIHNwZW50IGxvdHMgb2YgdGltZSBhbmQgY3ljbGVzIGltcGxlbWVudGlu ZyB0aGluZ3MgdGhhdCB0dXJuIG91dCBub3QgdG8gYmUgc2VjdXJlIGVub3VnaCwgYW5kIHdlIGhh dmUgdG8gbW92ZSBmb3J3YXJkIG9uIHRoaW5ncyB0aGF0IGFyZS4gIERUTFMtU1JUUCBpcyBvbmUg b2YgdGhvc2UgdGhpbmdzLCBhcyBpcyBJUHY2Lg0KDQpCcmlhbg0KDQoNCj4gT24gQXVnIDMwLCAy MDIxLCBhdCA1OjA2IFBNLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4gd3Jv dGU6DQo+IA0KPiBDaGFkLA0KPiANCj4gV2VsY29tZSB0byB0aGUgUlVNIFdHIQ0KPiANCj4gT24g OC8zMC8yMSAxMTo1MSBBTSwgQ2hhZCBMZWVwZXIgd3JvdGU6DQo+PiAtIFdoaWxlIFdlYlJUQyB3 LyBTUlRQL0RUTFMgKGVuY3J5cHRpb24pIGlzIGFuIGV4Y2VsbGVudCBpZGVhIGdvaW5nIGZvcndh cmQsIGl0IGNhbid0IGJlIGEgIk1VU1QiIHJlcXVpcmVtZW50LiAgSSBhZ3JlZSB3aXRoIFJvZ2Vy IFNsdXNzZXIgdGhhdCBtYW5kYXRpbmcgY29tcGxpYW5jZSB1c2luZyBNVVNUIHJlcXVpcmVzIHBy b3ZpZGVycyB0byBpbXBsZW1lbnQgc2lnbmlmaWNhbnQgZGV2ZWxvcG1lbnQgdG8gY2hhbmdlIG92 ZXIgdG8gd2hhdCBSVU0gaXMgc3BlY2lmeWluZy4NCj4gDQo+IFRoZSByZXF1aXJlbWVudHMgaW4g dGhpcyBkb2Mgd2lsbCBhcHBseSBvbmx5IHRvIGRldmljZXMgdGhhdCBjbGFpbSB0byBjb25mb3Jt IHRvIGl0LiBQcmVzdW1hYmx5IHlvdSBjb3VsZCBjb250aW51ZSB0byBzdXBwb3J0IHlvdXIgZXhp c3RpbmcgZGV2aWNlcyB1c2luZyB3aGF0ZXZlciBtZWNoYW5pc21zIHRoZXkgY3VycmVudGx5IHVz ZS4gU28gdGhlIGltcGxlbWVudGF0aW9uIGJ1cmRlbiBpcyBvbmx5IG9uIHRoZSBzZXJ2ZXIgc2lk ZSwgbm90IHRoZSBsZWdhY3kgZGV2aWNlIHNpZGUuIChPZiBjb3Vyc2UgdGhlIEZDQyB3aWxsIGhh dmUgYSBzYXkgaW4gdGhpcy4pDQo+IA0KPiBPbmUgbW90aXZhdGlvbiBmb3IgdGhlIHdlYnJ0YyBy ZXF1aXJlbWVudCBpcyBzbyB0aGF0IGEgUlVFIGNhbiBiZSBidWlsdCBvbiB0b3Agb2YgV2ViUlRD LiBFLmcuLCBpdCBjYW4gYmUgYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBkZWFmIHVzZXJzIHVzaW5n IGFueSBkZXZpY2Ugd2l0aCBhIGJyb3dzZXIuIFN1Y2ggYSBzZXJ2ZXIgaXMgZWZmZWN0aXZlbHkg anVzdCBzaWduYWxpbmcgZ2F0ZXdheSB0aGF0IGNhbiBlc3RhYmxpc2ggYSBwMnAgbGluayBiZXR3 ZWVuIHRoZSBicm93c2VyIGFuZCB0aGUgVlJTIHByb3ZpZGVyIHNlcnZlci4gKEl0IGRvZXMgaGF2 ZSB0byB0cmFuc2NvZGUgUlRULCBidXQgdGhhdCBpcyBsZXNzIG9mIGEgYnVyZGVuLikNCj4gDQo+ IFdoZW4gZGVmaW5pbmcgYSBzcGVjaWZpY2F0aW9uIGZvciBhbiBpbnRlcmZhY2UgdGhhdCBpcyB0 byBiZSBpbXBsZW1lbnRlZCBieSBpbmRlcGVuZGVudCBwYXJ0aWVzIGl0IGlzIG5lY2Vzc2FyeSBm b3IgZXNzZW50aWFsIGZ1bmN0aW9ucyB0byBoYXZlIGF0IGxlYXN0IG9uZSBtYW5kYXRvcnkgdG8g aW1wbGVtZW50IG1lY2hhbmlzbS4gQ3VycmVudGx5IHRoZXJlIGFyZSBubyBzdGFuZGFyZHMgZm9y IGNvbm5lY3RpbmcgYSBSVUUgdG8gYSBwcm92aWRlciwgc28gd2UgbmVlZCB0byBwaWNrICpzb21l dGhpbmcqIHRvIGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQuIElmIHlvdSBoYXZlIGFuIGFsdGVy bmF0aXZlIGZvciB0aGUgbWVkaWEgeW91IHdvdWxkIHByZWZlciwgdGhlbiBwbGVhc2UgbWFrZSBh IHNwZWNpZmljIHByb3Bvc2FsLg0KPiANCj4+IC0gV2Ugc2hvdWxkIGtlZXAgYW55IG5ldyBwcml2 YWN5IHJlcXVpcmVtZW50cyB2ZXJ5IG1pbmltYWwgYXQgdGhpcyB0aW1lLiAgV2hpbGUgY29tcGFu aWVzIGluIHRoZSBFVSBoYXZlIGFscmVhZHkgY3JlYXRlZCB0aGVpciBzeXN0ZW1zIGluIGNvbXBs aWFuY2Ugd2l0aCB0aGUgR0RQUiwgbW9zdCBvZiB0aGUgd29ybGQgaGFzbid0IGNyZWF0ZWQgYW4g ZXF1aXZhbGVudCB5ZXQuICBTbyB3aGF0IG1heSBsb29rIGxpa2UgYW4gZWFzeSBjaGFuZ2UgdG8g RVUgaW1wbGVtZW50ZXJzIG1heSBiZSBhIGRyYW1hdGljIGNoYW5nZSBmb3Igb3RoZXJzLg0KPiAN Cj4gSSBkb24ndCB0aGluayB3ZSBoYXZlIHNhaWQgbXVjaCBhYm91dCBwcml2YWN5IG9mIHJldGFp bmVkIGRhdGEuIEJ1dCB3ZSBhcmUgY29uY2VybmVkIHRoYXQgdGhlIG1lZGlhIGFuZCBzaWduYWxp bmcgYmUgcHJpdmF0ZSBiZXR3ZWVuIHRoZSBSVUUgYW5kIHRoZSBwcm92aWRlci4gVGhhdCBpcyBh IGxvdyBiYXIgdGhlc2UgZGF5cy4gSXQgaXMgdW5saWtlbHkgdGhhdCBhbnl0aGluZyBsZXNzIGNv dWxkIGJlIGFwcHJvdmVkLiBJIGV4cGVjdCB0aGUgRkNDIHdpbGwgYWdyZWUuDQo+IA0KPiBJZiB5 b3UgaGF2ZSBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgdGhhdCBhY2hpZXZlcyB0aGF0IHRoZW4gbWFr ZSBhIHByb3Bvc2FsIHdlIGNhbiBkaXNjdXNzLg0KPiANCj4gCVRoYW5rcywNCj4gCVBhdWwNCj4g DQo+PiBPbiBGcmksIEF1ZyAyNywgMjAyMSBhdCAzOjE2IFBNIFBhdWwgS3l6aXZhdCA8cGt5eml2 YXRAYWx1bS5taXQuZWR1IDxtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Pj4gd3JvdGU6DQo+ PiAgICBQcm92aWRlcnMsDQo+PiAgICBNeSByZXF1ZXN0IGJlbG93IHRvIFJvZ2VyIHNob3VsZCBo YXZlIGJlZW4gYnJvYWRlci4gWW91IGFsbCBzZWVtIHRvDQo+PiAgICBoYXZlDQo+PiAgICB0aGUg c2FtZSBpc3N1ZS4gSSBlbmNvdXJhZ2UgYW55L2FsbCBvZiB5b3UgdG8gbWFrZSBhbiBhbHRlcm5h dGl2ZQ0KPj4gICAgcHJvcG9zYWwgaGVyZS4gSnVzdCBzYXlpbmcgIndlIGRvbid0IGxpa2Ugd2hh dCBpcyB0aGVyZSIgaXNuJ3QgaGVscGZ1bA0KPj4gICAgd2l0aG91dCBhbiBhbHRlcm5hdGl2ZS4N Cj4+ICAgICAgICAgICAgIFRoYW5rcywNCj4+ICAgICAgICAgICAgIFBhdWwNCj4+ICAgIE9uIDgv MjYvMjEgNTo0MCBQTSwgUGF1bCBLeXppdmF0IHdyb3RlOg0KPj4gICAgID4gUm9nZXIsDQo+PiAg ICAgPg0KPj4gICAgID4gT24gOC8yNi8yMSAzOjMwIFBNLCBSb2dlciBTbHVzc2VyIHdyb3RlOg0K Pj4gICAgID4NCj4+ICAgICA+PiBNb3N0IHByb3ZpZGVycyBhbHJlYWR5IHN1cHBvcnQgZW5jcnlw dGlvbiBhbmQgSVBWNiBvbiBhIGxpbWl0ZWQNCj4+ICAgIHNjb3BlLA0KPj4gICAgID4+IG5vdCBu ZWNlc3NhcmlseSB0aGUgd2F5IGl0IGlzIGRlZmluZWQgaW4gUlVNIHNwZWMuIE1hbmRhdGluZw0K Pj4gICAgID4+IGNvbXBsaWFuY2UgdXNpbmcgTVVTVCByZXF1aXJlcyBwcm92aWRlcnMgdG8gZGlz Y2FyZCBzb21ldGltZXMgaHVnZQ0KPj4gICAgID4+IGFtb3VudHMgb2YgZGV2ZWxvcG1lbnQgdG8g Y2hhbmdlIG92ZXIgdG8gd2hhdCBSVU0gaXMgc3BlY2lmeWluZy4NCj4+ICAgIFRoZQ0KPj4gICAg ID4+IHB1c2ggYmFjayBpcyBub3QgYWJvdXQgZG9pbmcgdGhlc2UgdGhpbmdzIGl0IGlzIGFib3V0 IHRoZSBsb3NzIG9mDQo+PiAgICAgPj4gdGltZSwgZWZmb3J0IGFuZCBtb25leSB0byBkbyB0aGVt IGluIHRoZSB3YXkgUlVNIG1hbmRhdGVzIHdpdGgNCj4+ICAgIE1VU1RzLg0KPj4gICAgID4NCj4+ ICAgICA+IERvIHlvdSB0aGluayB0aGVyZSBpcyBzb21ldGhpbmcgZWxzZSB3ZSBjb3VsZCB3cml0 ZSBpbiB0aGlzIHNwZWMNCj4+ICAgIHRoYXQNCj4+ICAgICA+IGNvdmVycyBlbmNyeXB0aW9uIGFu ZCBJUHY2IGluIGEgd2F5IHRoYXQgaXMgbGVzcyBidXJkZW5zb21lIGZvcg0KPj4gICAgID4gcHJv dmlkZXJzIHdoaWxlIHJlbWFpbmluZyBpbnRlcm9wZXJhYmxlIHdpdGggYWxsIHByb3ZpZGVycz8N Cj4+ICAgICA+DQo+PiAgICAgPiBJZiBzbywgY2FuIHlvdSBwbGVhc2Ugc3BlbGwgaXQgb3V0Pw0K Pj4gICAgLS0gICAgIFJ1bSBtYWlsaW5nIGxpc3QNCj4+ICAgIFJ1bUBpZXRmLm9yZyA8bWFpbHRv OlJ1bUBpZXRmLm9yZz4NCj4+ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnVtDQo+PiAgICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0+ DQo+IA0KPiAtLSANCj4gUnVtIG1haWxpbmcgbGlzdA0KPiBSdW1AaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0NCg0KLS0gDQpSdW0gbWFpbGluZyBs aXN0DQpSdW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnVtDQo= From nobody Tue Aug 31 02:53:44 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936843A3DC7 for ; Tue, 31 Aug 2021 02:53:43 -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, 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=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4OoMAycZfio for ; Tue, 31 Aug 2021 02:53:37 -0700 (PDT) Received: from stmail.purple.us (stmail.purple.us [54.177.79.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D693A3DC5 for ; Tue, 31 Aug 2021 02:53:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail.purple.us (Postfix) with ESMTP id B2FDA1A1C01; Tue, 31 Aug 2021 04:59:20 -0500 (CDT) Authentication-Results: stmail.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=yKRi2Dul header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2173.outbound.protection.outlook.com [104.47.57.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail.purple.us (Postfix) with ESMTPS id 58AF31A1BFE; Tue, 31 Aug 2021 04:59:20 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l2RrE7wlFLsWnJfdlnEu3H+ndnqdvwhnx5diqWOejkGkfygMGIA4oMCeH9puIvBiMO1HgAmNCmneyiJuftZ9T0ul3Y2C8ZoiqKEwE6zb6k5bZ/RE9F6b7w+UEGOTygdrPZgG4N7jqYifDRBkV4lGlMa2DC1BUVJZ0hM3Vn2JVZS8SPIPMsJ32Exaf+Qj02IPhMySRvhpoKpMYaLT3+4/MIqT01APf4kGOacdbJ85Q6ppcVGxie5gKHUsPa9Wp5Auab2dx6iVFOnM5WmfLJ9t1httfCY7DOL7GsAF57bMDN79gYtvcXiru2LM6HI/YNDuyDJpI02mZVfpBs/6Cqz8VQ== 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=laoEBah0XUU22J7iVn+ufy0iq4Ba8s+w+Si7Fh6ZQRk=; b=iPjDrL+ZtVm8ZxdwTpdUk5OftR2l/bURFM8yefnVJGuwTnh6urJ690JvU5JcIvqux3o2jd1LEKa4PwdGOxAneirBgxODE6ZoNHJNpW2SeyjOY+v23aZe1uhidlpKg/Wda3A370iNh8sTJN2uc7Iyct7VSf9oECRkSw5L7rB8VK5apQc9nsES2LnTA7lKtVKYARE7if8VZfa/wa8vhSUDdgtlp7KwEuV+EXPkT9G2/DwEXMDzP+jm9Yd14TSWX6OEO9CoIE9w7aYUXVKNp5EahwlpUz1neQdsP2ZgXeeCmGHgWLxaEHdAP7Ef3SJ9A9l4itT6b+Qw4Dcc3nnSgqg6Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=laoEBah0XUU22J7iVn+ufy0iq4Ba8s+w+Si7Fh6ZQRk=; b=yKRi2Dulo2lRvHlGTfy2EvX+XfS1w0rasOG4G9JDGgRF7//0j52u1+RXm9JDfF1/CsmJx2aygj8aNZWBib3E2YfYjHv5j8PEvMaX4AJIcU57TUOJ4DUHul50HWsrRwU9PDwxlhLs5334HHNAFvx+vo45NjeqXLo8GsOvWS4uX90= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM5PR19MB0137.namprd19.prod.outlook.com (2603:10b6:4:64::39) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.24; Tue, 31 Aug 2021 09:53:31 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 09:53:31 +0000 From: Ed Sayers To: Brian Rosen , Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] IPv6 Thread-Index: AdeeSsUbffPyNERDROeDyEupIDr9gw== Date: Tue, 31 Aug 2021 09:53:31 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b69c3a8e-17bd-4394-5e56-08d96c6530c3 x-ms-traffictypediagnostic: DM5PR19MB0137: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eHiQZ0klQfeX4n77SeUzXl9MbKM5J8iXQFLxZPi/9jog/lf1qhjgJH4s3s8ediW+cXkFOxbVeojFujv+QsUMyfd3KBNE5YFqgZ8NjxFxXB5Xwmz7H4NlgLY4N8MxktC7GChkIJ/XtsWvQN1m2PAYK1t8ykfBso2AsHWLfdwKPsDMBok2MHDVhy9AV11awVDTOACXlNO8FaS4O71V/tH16trNItlHnYbmEqcvgWOb8fFv9b3PuTK4OlK0nrzIyJb2n98w+D3M82Acv6JNRj33OesPBpqanHXIduwM4MDd/ivAd/i34B1wrU/O7YoyUuzX4sENQe3W9WKA+TKQT2zHT6+Due5XouLVO9lQt/IfKwKLSu8KI36Mx9/CYquwvy7gQvJKnSrlVJX8b3EmIgAFr39YlXDEvGMHmlxah+QXiQqqnhpXeNHwfGaDQALuBRs8N4H8E65kq4OV2Wmbgi5gVa7ZzE3R9WRUE/DDzrffyvazalaAhD3FsZk0iUmcGnnkxCgdYbOoAALfeqnRFoLLb68bHtEMEVy7JSfdkSacZok1f8/36ZkTqwteKm+VJ0Bz2LXYkXmb+LS6fWNEc9WpsG/b67x29g0eOe3kkBWXUAA7Rb7bWclGBubvpZouEKZd+7ISH4JmbkA87gjqXtw2Zv69fdVfBhiFl8NU4FOOu1Gqq+SdXwq0UX3bRpFvwldowTi5b1UzrQvVyjxkd1lbyDY2JaK4aFix+fO4cpeVZ18trKpi5LKATac/mxw3/J4wZzxVfCTb7KcB7KnccOkm0AwmaOENAK/oJe0MYUYGK06p6OOzgiX+iYR7w8PEpnfb x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(316002)(8676002)(66574015)(66946007)(83380400001)(52536014)(2906002)(8936002)(86362001)(71200400001)(122000001)(38100700002)(5660300002)(76116006)(26005)(44832011)(66446008)(38070700005)(7696005)(9686003)(33656002)(66476007)(6506007)(64756008)(55236004)(53546011)(966005)(66556008)(186003)(55016002)(4326008)(508600001)(110136005)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UzlZV3RXQm5JRXVKRW5ZTDFaNlJKVm9WcU9nVzc3dGZKZUljU3l2ZVN5NlpG?= =?utf-8?B?M1hXTlc2UE40MnVwalgwMzJodk9MdTIyejJUQXo0L3lnell0ajI4MFNHRjJ4?= =?utf-8?B?YXFheHpmUndsV1VLZUtxUU5laU9rdDZ6eHFHTXFIMHBDNHFNb0tQM1NOQWVZ?= =?utf-8?B?c2hzODYwWno2VTZuVVBGdHRBck80cFBNOTlyckh3aGszWTNVTlZkeXpNZ1lU?= =?utf-8?B?U0Mrdk1pWk14eUljYWNXZHo5eEl5RWVSbWZwYTJRc1pWTlY5ek5DbmN5Y1lz?= =?utf-8?B?ZnV6dEJTSnoyZkJnbnE0cFF2RTR5RnNJZksyVXljemU2LzR0MlQrYko3aHhV?= =?utf-8?B?Z3NQbjhCT2xPOWtjSlN6MTMvdXBoR3d6VUZNY0hQcnlmaWNBazRKRWEyMGdI?= =?utf-8?B?Vi9qTlBCbzhvdE83S0FNRmM2YW9GY2VlVWVMUnJZUjkrZkpIMWFPSzJkM2lZ?= =?utf-8?B?UjNMVkFTRU5VTXptRUptU0c5bEExa25JSEhWb2Rlb2hhTFEySStRRGwzWE00?= =?utf-8?B?SWQvR2dUZUtRMTdkbUwyeTZ6MHFzelJrWVZySy9GVXN4OEh3SEFSNHovNzBY?= =?utf-8?B?S2w3M21xcjBuREFYT093bngwdVp2S1BIeEJXYVBqSHhTZVl5ZUYrVDVhc0Fp?= =?utf-8?B?bFlOc2xLMmdDckl2K25kWmk0bVJ1bjM3OVJKbXd2bG5lQmpqYVAxS2g2M1Vr?= =?utf-8?B?UXlpMytGaTlpZXR4SFlYMWplaWR4Nm1vaVB5bHgzR0p2OUgxaTl2YVZDYkNE?= =?utf-8?B?RjZNSGJPeWxaR0lxU3RKU0kwMTZVMGhkUXlLa2pmYWYzREp2aEZqUWR5OVph?= =?utf-8?B?UU93Tkp6MnlKRW5pTHFqYmVlR21ITGJtQkdWUnJLcWxSejJwTEM4R3JIKzM5?= =?utf-8?B?UUJFbnYvRkZKSCs1R08za2pETjhCb0hxZEd0Sk9MaTFxTkhjQTBFU2dZaTFC?= =?utf-8?B?aXNZYnJMV1lsdlRqS2ZXTmkyWmdWVzBpc0xBNHZSZ0Z0Q2ZuNHJubDd0MlUy?= =?utf-8?B?ZWhIR3ZVRGR4OXNRTjRxVmJjVWpQSkxTd01hK3dBMldJeDlRcndlMXZ0Mzhm?= =?utf-8?B?dzdsQ1ptQThvQXI1bkhwWWtVdE0zZG5YYVFyNTNWOWdKWGFtUmtnQ0NsbnZw?= =?utf-8?B?ZzVZZU1laEJMVlNkSG55TzJtZDdrNDlzcHFwM0xSanQrdzMxVEJ1ckc5Q2E0?= =?utf-8?B?a3VyK2thejZHM0xuRVY0Sm01Q3MzL2RFYlNjMzQ0UExNbnErV08yVjVzNjVQ?= =?utf-8?B?eTJYZUx0UUlGOUh1dUs4ZDc2d2VCY2FUTGU5c2ZYYm9oellheDdZYzBQQUZI?= =?utf-8?B?eWE3bHJoby9temdVTUVXNXNhUWtxVGg5Tm8xak01aW1zY1B0NWlPdVp5T1NB?= =?utf-8?B?cDA4N2tKTlpNNmQxN0J5S2ViVTBEK1Fkditsckc0NkxWU3NVRmcxME8zL2Vs?= =?utf-8?B?OUdFYjlFYWhiOW5la1dBY2hxRENiZkpSZ1dIQ2oxYSt4TEhjbjArcldxUDk4?= =?utf-8?B?NUY0aEFnN0hJbjBJczFJaEhDaTMvU0xJRWFDR2ZGNDB1ZXF6OHpnR3BMd1R1?= =?utf-8?B?ZzNZeS9UWEdLUGlTSFJGZzlLYVJHdWY4b2VrcjZPV3pXYVVSK1dnV1F0Z3hI?= =?utf-8?B?QmFWeDV1WVRPWnlJNlZEVzNxKzRvVDFhMXRqSEFkUDVwT2xtRkxHVThoNHhX?= =?utf-8?B?OFV3eEZaZlpJS0lvb1VwTTJDRXl2dEQrZEdCejRSdTN4SmhzUWdTdCt3c3dh?= =?utf-8?Q?VIwB+UJK/d6FOJ2GmqLNAucLpyExIZOV5jZ8EX6?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b69c3a8e-17bd-4394-5e56-08d96c6530c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2021 09:53:31.3510 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: dpnyW6oX41bIWvX7M8th0ujb85BBAiMn2zHotfT6TC6TLI/Qq/7poljkS+D/dfhvuoVsfGkO4cMFzVVj3ShI2w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR19MB0137 Archived-At: Subject: Re: [Rum] IPv6 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 09:53:44 -0000 SGksDQoNCkkgaGF2ZSBzZXBhcmF0ZWQgb3V0IElQdjYgYXMgYSB0b3BpYy4NCg0KV2UgYWxsIGtu b3cgdGhhdCBJUHY2IGlzIHRoZSB3YXkgdG8gZ28sIGFuZCBhbHNvIG5lY2Vzc2FyeSBhcyB0aGUg SVB2NCBhZGRyZXNzIHJhbmdlIGhhcyBhbGwgYnV0IGRyaWVkIHVwLg0KSG93ZXZlciwgdGhlIHRy YW5zaXRpb24gdG8gSVB2NiBhY3Jvc3MgdGhlIFdvcmxkIGhhcyBub3QgYmVlbiBhbiBlYXN5IG9u ZSBhbmQgaXMgZGVmaW5pdGVseSBub3QgJ2p1c3QgU0lQJy4NCg0KSXQgaXMgYWxzbyB2ZXJ5IHRy dWUgdG8gc2F5IHRoYXQgSVB2NiBuZWVkcyB0byBiZSBlbWJyYWNlZCBvbiBlbmRwb2ludHM7IFVT IG1vYmlsZSBwaG9uZSBjYXJyaWVycyB3ZXJlIGZvcmNlZCB0byBzdGFydCB1c2luZyBJUHY2IGZv ciBoYW5kc2V0cyBhIGxvbmcgdGltZSBhZ28uDQpIb3dldmVyLCBodWdlIHN3YXRoZXMgb2YgdGhl IEludGVybmV0IHJlbWFpbiBJUHY0LCBiZWNhdXNlIGFkZGluZyBJUHY2IHRvIEluZnJhc3RydWN0 dXJlIGlzIG5vdCBzdWNoIGFzIGVhc3kgdGFzayB0byB0YWNrbGUsIGFuZCBiZWNhdXNlIHRob3Nl IElQIGFkZHJlc3NlcyByYXJlbHkgY2hhbmdlIGNvbXBhcmVkIHRvIGVuZHBvaW50cy4NCg0KQWdh aW4sIHdlIGFsbCBhZ3JlZSAtIElQdjYgaXMgdGhlIHdheSB0byBnby4gQnV0LCBJUHY0LCBOQVQ2 NCBhbmQgRE5TNjQgYXJlIGdvaW5nIHRvIGJlIG5lZWRlZCBmb3IgYSBsb25nIHRpbWUgdG8gY29t ZS4NCkZvciBtYW55IHVzZS1jYXNlcywgRE5TNjQgYW5kIE5BVDY0IGhpZGUgdGhlIHRyYW5zaXRp b24gYmFjayB0byB0aGUgSVB2NCBJbnRlcm5ldCB3aGVuIG5vdCBzdXBwb3J0ZWQgYnkgSW5mcmFz dHJ1Y3R1cmUuDQpCdXQsIGFzIHdlIGtub3csIFNEUCBpbmNsdWRlIElQIGFkZHJlc3NlcyB0aGF0 IEROUzY0IGFuZCBOQVQ2NCBjYW5ub3Qgc2VlIGFuZCB3aWxsIG5vdCB0cmFuc2xhdGUuDQoNClRo ZXJlZm9yZSwgd2UnZCBsaWtlIHRvIHByb3Bvc2UgZm9yIGNvbnNpZGVyYXRpb24gdGhhdCBhIFJV TSBlbmRwb2ludCBtdXN0IGFsc28gc3VwcG9ydCB0aGUgZm9sbG93aW5nIFJGQ3MgYXMgYSBwb3Nz aWJsZSBmYWxsIGJhY2sgdG8gYWlkIHRoZSBuZWNlc3NhcnkgdHJhbnNpdGlvbiB0byBJUHY2IG92 ZXIgdGltZToNCiogUkZDLTYwNTIgLSBJUHY2IEFkZHJlc3Npbmcgb2YgSVB2NC9JUHY2IFRyYW5z bGF0b3JzDQoqIFJGQy03MDUwIC0gRGlzY292ZXJ5IG9mIHRoZSBJUHY2IFByZWZpeCBVc2VkIGZv ciBJUHY2IEFkZHJlc3MgU3ludGhlc2lzDQoNCg0KRWQgU2F5ZXJzDQpFbmRwb2ludCBTREsgVGVh bSBMZWFkDQpQdXJwbGUsIGEgRGl2aXNpb24gb2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEMNCnB1 cnBsZXZycy5jb20NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBt ZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb25hbCBhbmQgY29uZmlkZW50aWFs IHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRl bHkgYnkgZS1tYWlsLCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KDQoNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9y Zz4gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQpTZW50OiAzMCBBdWd1c3QgMjAyMSAyMjoyNA0K VG86IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KQ2M6IENoYWQgTGVlcGVy IDxjaGFkLmxlZXBlckBjb252b3JlbGF5LmNvbT47IHJ1bUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtSdW1dIElQdjYgYW5kIGVuY3J5cHRpb24NCg0KSSBkb27igJl0IHRoaW5rIHRoZXJlIGFyZSBB TlkgYWx0ZXJuYXRpdmVzIHRvIFNSVFAuICBUaGVyZSBhcmUgYWx0ZXJuYXRpdmVzIHRvIERUTFMt U1JUUC4gIFRoZXJlIGFyZSBtb3ZlcyB3aXRoaW4gdGhlIElFVEYgdG8gZGVwcmVjYXRlIFNERVMs IHNwZWNpZmljYWxseS4gIFRoZXJlIGlzIHB1c2ggYmFjayBvbiB0aGF0LCBidXQgaXTigJlzIGFu IG9uZ29pbmcgZGlzY3Vzc2lvbiBiZWNhdXNlIFNERVMgaXNu4oCZdCBzZWN1cmUgZW5vdWdoLiAg IFNpbmNlIGFsbCBwcm92aWRlcnMgSSBrbm93IGFib3V0IGFuY2hvciBtZWRpYSwgdGhpcyBvbmx5 IGFmZmVjdHMgdGhlIGluaXRpYWwgaG9wLiAgVXNlcnMgcmVhbGx5IHdhbnQgdG8gaGVhciB0aGF0 IHRoZWlyIG1lZGlhIGlzIHByb3RlY3RlZCBlbmQgdG8gZW5kIChhdCBsZWFzdCBob3AgYnkgaG9w KSBidXQgb3VyIGRvY3VtZW50IGRvZXNu4oCZdCByZXF1aXJlIHRoYXQuICBBZ2Fpbiwgd2UgbmVl ZCBhIFNUQU5EQVJEUyBiYXNlZCBzb2x1dGlvbiwgYW5kIHdlIGhhdmUgdG8gbGl2ZSB3aXRoaW4g dGhlIGNvbnN0cmFpbnRzIHRoZSBJRVRGIGhhcyBmb3IgbmV3IHN0YW5kYXJkcyB3aXRoIHJlc3Bl Y3QgdG8gc2VjdXJpdHkuICBMaWtlIG5lYXJseSBldmVyeSBvcmdhbml6YXRpb24sIHRoZSBJRVRG IGlzIG11Y2ggbW9yZSBzZWN1cml0eSBjb25zY2lvdXMgdGhhbiBpdCB3YXMsIGFuZCB3b27igJl0 IHRvbGVyYXRlIGJhZCBzZWN1cml0eSBhbHRob3VnaCBpdCBvZnRlbiByZWNvZ25pemVzIHRoZSBu ZWNlc3NpdHkgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFzIGxvbmcgYXMgaXTigJlzIG5v dCB0byBhIGtub3duIGluc2VjdXJlIG1lY2hhbmlzbS4gIA0KDQpJIHJlYWxseSB0aGluayB0aGlz IGlzIGEg4oCcc3RlcCB1cCB0byB0aGUgYmFy4oCdIHRoaW5nLiAgV2XigJl2ZSBzcGVudCBsb3Rz IG9mIHRpbWUgYW5kIGN5Y2xlcyBpbXBsZW1lbnRpbmcgdGhpbmdzIHRoYXQgdHVybiBvdXQgbm90 IHRvIGJlIHNlY3VyZSBlbm91Z2gsIGFuZCB3ZSBoYXZlIHRvIG1vdmUgZm9yd2FyZCBvbiB0aGlu Z3MgdGhhdCBhcmUuICBEVExTLVNSVFAgaXMgb25lIG9mIHRob3NlIHRoaW5ncywgYXMgaXMgSVB2 Ni4NCg0KQnJpYW4NCg0KDQo+IE9uIEF1ZyAzMCwgMjAyMSwgYXQgNTowNiBQTSwgUGF1bCBLeXpp dmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPiANCj4gQ2hhZCwNCj4gDQo+IFdl bGNvbWUgdG8gdGhlIFJVTSBXRyENCj4gDQo+IE9uIDgvMzAvMjEgMTE6NTEgQU0sIENoYWQgTGVl cGVyIHdyb3RlOg0KPj4gLSBXaGlsZSBXZWJSVEMgdy8gU1JUUC9EVExTIChlbmNyeXB0aW9uKSBp cyBhbiBleGNlbGxlbnQgaWRlYSBnb2luZyBmb3J3YXJkLCBpdCBjYW4ndCBiZSBhICJNVVNUIiBy ZXF1aXJlbWVudC4gIEkgYWdyZWUgd2l0aCBSb2dlciBTbHVzc2VyIHRoYXQgbWFuZGF0aW5nIGNv bXBsaWFuY2UgdXNpbmcgTVVTVCByZXF1aXJlcyBwcm92aWRlcnMgdG8gaW1wbGVtZW50IHNpZ25p ZmljYW50IGRldmVsb3BtZW50IHRvIGNoYW5nZSBvdmVyIHRvIHdoYXQgUlVNIGlzIHNwZWNpZnlp bmcuDQo+IA0KPiBUaGUgcmVxdWlyZW1lbnRzIGluIHRoaXMgZG9jIHdpbGwgYXBwbHkgb25seSB0 byBkZXZpY2VzIHRoYXQgY2xhaW0gdG8gY29uZm9ybSB0byBpdC4gUHJlc3VtYWJseSB5b3UgY291 bGQgY29udGludWUgdG8gc3VwcG9ydCB5b3VyIGV4aXN0aW5nIGRldmljZXMgdXNpbmcgd2hhdGV2 ZXIgbWVjaGFuaXNtcyB0aGV5IGN1cnJlbnRseSB1c2UuIFNvIHRoZSBpbXBsZW1lbnRhdGlvbiBi dXJkZW4gaXMgb25seSBvbiB0aGUgc2VydmVyIHNpZGUsIG5vdCB0aGUgbGVnYWN5IGRldmljZSBz aWRlLiAoT2YgY291cnNlIHRoZSBGQ0Mgd2lsbCBoYXZlIGEgc2F5IGluIHRoaXMuKQ0KPiANCj4g T25lIG1vdGl2YXRpb24gZm9yIHRoZSB3ZWJydGMgcmVxdWlyZW1lbnQgaXMgc28gdGhhdCBhIFJV RSBjYW4gYmUgYnVpbHQgb24gdG9wIG9mIFdlYlJUQy4gRS5nLiwgaXQgY2FuIGJlIGEgc2VydmVy IHRoYXQgc3VwcG9ydHMgZGVhZiB1c2VycyB1c2luZyBhbnkgZGV2aWNlIHdpdGggYSBicm93c2Vy LiBTdWNoIGEgc2VydmVyIGlzIGVmZmVjdGl2ZWx5IGp1c3Qgc2lnbmFsaW5nIGdhdGV3YXkgdGhh dCBjYW4gZXN0YWJsaXNoIGEgcDJwIGxpbmsgYmV0d2VlbiB0aGUgYnJvd3NlciBhbmQgdGhlIFZS UyBwcm92aWRlciBzZXJ2ZXIuIChJdCBkb2VzIGhhdmUgdG8gdHJhbnNjb2RlIFJUVCwgYnV0IHRo YXQgaXMgbGVzcyBvZiBhIGJ1cmRlbi4pDQo+IA0KPiBXaGVuIGRlZmluaW5nIGEgc3BlY2lmaWNh dGlvbiBmb3IgYW4gaW50ZXJmYWNlIHRoYXQgaXMgdG8gYmUgaW1wbGVtZW50ZWQgYnkgaW5kZXBl bmRlbnQgcGFydGllcyBpdCBpcyBuZWNlc3NhcnkgZm9yIGVzc2VudGlhbCBmdW5jdGlvbnMgdG8g aGF2ZSBhdCBsZWFzdCBvbmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudCBtZWNoYW5pc20uIEN1cnJl bnRseSB0aGVyZSBhcmUgbm8gc3RhbmRhcmRzIGZvciBjb25uZWN0aW5nIGEgUlVFIHRvIGEgcHJv dmlkZXIsIHNvIHdlIG5lZWQgdG8gcGljayAqc29tZXRoaW5nKiB0byBiZSBtYW5kYXRvcnkgdG8g aW1wbGVtZW50LiBJZiB5b3UgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBmb3IgdGhlIG1lZGlhIHlvdSB3 b3VsZCBwcmVmZXIsIHRoZW4gcGxlYXNlIG1ha2UgYSBzcGVjaWZpYyBwcm9wb3NhbC4NCj4gDQo+ PiAtIFdlIHNob3VsZCBrZWVwIGFueSBuZXcgcHJpdmFjeSByZXF1aXJlbWVudHMgdmVyeSBtaW5p bWFsIGF0IHRoaXMgdGltZS4gIFdoaWxlIGNvbXBhbmllcyBpbiB0aGUgRVUgaGF2ZSBhbHJlYWR5 IGNyZWF0ZWQgdGhlaXIgc3lzdGVtcyBpbiBjb21wbGlhbmNlIHdpdGggdGhlIEdEUFIsIG1vc3Qg b2YgdGhlIHdvcmxkIGhhc24ndCBjcmVhdGVkIGFuIGVxdWl2YWxlbnQgeWV0LiAgU28gd2hhdCBt YXkgbG9vayBsaWtlIGFuIGVhc3kgY2hhbmdlIHRvIEVVIGltcGxlbWVudGVycyBtYXkgYmUgYSBk cmFtYXRpYyBjaGFuZ2UgZm9yIG90aGVycy4NCj4gDQo+IEkgZG9uJ3QgdGhpbmsgd2UgaGF2ZSBz YWlkIG11Y2ggYWJvdXQgcHJpdmFjeSBvZiByZXRhaW5lZCBkYXRhLiBCdXQgd2UgYXJlIGNvbmNl cm5lZCB0aGF0IHRoZSBtZWRpYSBhbmQgc2lnbmFsaW5nIGJlIHByaXZhdGUgYmV0d2VlbiB0aGUg UlVFIGFuZCB0aGUgcHJvdmlkZXIuIFRoYXQgaXMgYSBsb3cgYmFyIHRoZXNlIGRheXMuIEl0IGlz IHVubGlrZWx5IHRoYXQgYW55dGhpbmcgbGVzcyBjb3VsZCBiZSBhcHByb3ZlZC4gSSBleHBlY3Qg dGhlIEZDQyB3aWxsIGFncmVlLg0KPiANCj4gSWYgeW91IGhhdmUgYW4gYWx0ZXJuYXRlIHByb3Bv c2FsIHRoYXQgYWNoaWV2ZXMgdGhhdCB0aGVuIG1ha2UgYSBwcm9wb3NhbCB3ZSBjYW4gZGlzY3Vz cy4NCj4gDQo+IAlUaGFua3MsDQo+IAlQYXVsDQo+IA0KPj4gT24gRnJpLCBBdWcgMjcsIDIwMjEg YXQgMzoxNiBQTSBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdSA8bWFpbHRvOnBr eXppdmF0QGFsdW0ubWl0LmVkdT4+IHdyb3RlOg0KPj4gICAgUHJvdmlkZXJzLA0KPj4gICAgTXkg cmVxdWVzdCBiZWxvdyB0byBSb2dlciBzaG91bGQgaGF2ZSBiZWVuIGJyb2FkZXIuIFlvdSBhbGwg c2VlbSB0bw0KPj4gICAgaGF2ZQ0KPj4gICAgdGhlIHNhbWUgaXNzdWUuIEkgZW5jb3VyYWdlIGFu eS9hbGwgb2YgeW91IHRvIG1ha2UgYW4gYWx0ZXJuYXRpdmUNCj4+ICAgIHByb3Bvc2FsIGhlcmUu IEp1c3Qgc2F5aW5nICJ3ZSBkb24ndCBsaWtlIHdoYXQgaXMgdGhlcmUiIGlzbid0IGhlbHBmdWwN Cj4+ICAgIHdpdGhvdXQgYW4gYWx0ZXJuYXRpdmUuDQo+PiAgICAgICAgICAgICBUaGFua3MsDQo+ PiAgICAgICAgICAgICBQYXVsDQo+PiAgICBPbiA4LzI2LzIxIDU6NDAgUE0sIFBhdWwgS3l6aXZh dCB3cm90ZToNCj4+ICAgICA+IFJvZ2VyLA0KPj4gICAgID4NCj4+ICAgICA+IE9uIDgvMjYvMjEg MzozMCBQTSwgUm9nZXIgU2x1c3NlciB3cm90ZToNCj4+ICAgICA+DQo+PiAgICAgPj4gTW9zdCBw cm92aWRlcnMgYWxyZWFkeSBzdXBwb3J0IGVuY3J5cHRpb24gYW5kIElQVjYgb24gYSBsaW1pdGVk DQo+PiAgICBzY29wZSwNCj4+ICAgICA+PiBub3QgbmVjZXNzYXJpbHkgdGhlIHdheSBpdCBpcyBk ZWZpbmVkIGluIFJVTSBzcGVjLiBNYW5kYXRpbmcNCj4+ICAgICA+PiBjb21wbGlhbmNlIHVzaW5n IE1VU1QgcmVxdWlyZXMgcHJvdmlkZXJzIHRvIGRpc2NhcmQgc29tZXRpbWVzIGh1Z2UNCj4+ICAg ICA+PiBhbW91bnRzIG9mIGRldmVsb3BtZW50IHRvIGNoYW5nZSBvdmVyIHRvIHdoYXQgUlVNIGlz IHNwZWNpZnlpbmcuDQo+PiAgICBUaGUNCj4+ICAgICA+PiBwdXNoIGJhY2sgaXMgbm90IGFib3V0 IGRvaW5nIHRoZXNlIHRoaW5ncyBpdCBpcyBhYm91dCB0aGUgbG9zcyBvZg0KPj4gICAgID4+IHRp bWUsIGVmZm9ydCBhbmQgbW9uZXkgdG8gZG8gdGhlbSBpbiB0aGUgd2F5IFJVTSBtYW5kYXRlcyB3 aXRoDQo+PiAgICBNVVNUcy4NCj4+ICAgICA+DQo+PiAgICAgPiBEbyB5b3UgdGhpbmsgdGhlcmUg aXMgc29tZXRoaW5nIGVsc2Ugd2UgY291bGQgd3JpdGUgaW4gdGhpcyBzcGVjDQo+PiAgICB0aGF0 DQo+PiAgICAgPiBjb3ZlcnMgZW5jcnlwdGlvbiBhbmQgSVB2NiBpbiBhIHdheSB0aGF0IGlzIGxl c3MgYnVyZGVuc29tZSBmb3INCj4+ICAgICA+IHByb3ZpZGVycyB3aGlsZSByZW1haW5pbmcgaW50 ZXJvcGVyYWJsZSB3aXRoIGFsbCBwcm92aWRlcnM/DQo+PiAgICAgPg0KPj4gICAgID4gSWYgc28s IGNhbiB5b3UgcGxlYXNlIHNwZWxsIGl0IG91dD8NCj4+ICAgIC0tICAgICBSdW0gbWFpbGluZyBs aXN0DQo+PiAgICBSdW1AaWV0Zi5vcmcgPG1haWx0bzpSdW1AaWV0Zi5vcmc+DQo+PiAgICBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0KPj4gICAgPGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtPg0KPiANCj4gLS0gDQo+IFJ1bSBtYWlsaW5n IGxpc3QNCj4gUnVtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnVtDQoNCi0tIA0KUnVtIG1haWxpbmcgbGlzdA0KUnVtQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0K From nobody Tue Aug 31 03:05:56 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CC783A3E4A for ; Tue, 31 Aug 2021 03:05:51 -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 RGN1kjX-vy7p for ; Tue, 31 Aug 2021 03:05:40 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 5F2C33A3E44 for ; Tue, 31 Aug 2021 03:05:37 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 776701900; Tue, 31 Aug 2021 12:05:33 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 31 Aug 2021 12:05:32 +0200 Cc: Brian Rosen , Paul Kyzivat , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Sayers X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rum] IPv6 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 10:05:52 -0000 > On 31 Aug 2021, at 11:53, Ed Sayers wrote: >=20 > Hi, >=20 > I have separated out IPv6 as a topic. >=20 > We all know that IPv6 is the way to go, and also necessary as the IPv4 = address range has all but dried up. > However, the transition to IPv6 across the World has not been an easy = one and is definitely not 'just SIP'. >=20 > It is also very true to say that IPv6 needs to be embraced on = endpoints; US mobile phone carriers were forced to start using IPv6 for = handsets a long time ago. > However, huge swathes of the Internet remain IPv4, because adding IPv6 = to Infrastructure is not such as easy task to tackle, and because those = IP addresses rarely change compared to endpoints. >=20 > Again, we all agree - IPv6 is the way to go. But, IPv4, NAT64 and = DNS64 are going to be needed for a long time to come. > For many use-cases, DNS64 and NAT64 hide the transition back to the = IPv4 Internet when not supported by Infrastructure. > But, as we know, SDP include IP addresses that DNS64 and NAT64 cannot = see and will not translate. >=20 > Therefore, we'd like to propose for consideration that a RUM endpoint = must also support the following RFCs as a possible fall back to aid the = necessary transition to IPv6 over time: > * RFC-6052 - IPv6 Addressing of IPv4/IPv6 Translators > * RFC-7050 - Discovery of the IPv6 Prefix Used for IPv6 Address = Synthesis What makes this special for RUM? Isn=E2=80=99t this support needed for = all SIP implementations? If this is needed for transition, I would love = to see these in a generic document for SIP - how to implement it, = considerations for SIP and offer/answer as well as security = considerations. /O >=20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com >=20 > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Rum On Behalf Of Brian Rosen > Sent: 30 August 2021 22:24 > To: Paul Kyzivat > Cc: Chad Leeper ; rum@ietf.org > Subject: Re: [Rum] IPv6 and encryption >=20 > I don=E2=80=99t think there are ANY alternatives to SRTP. There are = alternatives to DTLS-SRTP. There are moves within the IETF to deprecate = SDES, specifically. There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. Since all = providers I know about anchor media, this only affects the initial hop. = Users really want to hear that their media is protected end to end (at = least hop by hop) but our document doesn=E2=80=99t require that. Again, = we need a STANDARDS based solution, and we have to live within the = constraints the IETF has for new standards with respect to security. = Like nearly every organization, the IETF is much more security conscious = than it was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism. =20 >=20 > I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. = We=E2=80=99ve spent lots of time and cycles implementing things that = turn out not to be secure enough, and we have to move forward on things = that are. DTLS-SRTP is one of those things, as is IPv6. >=20 > Brian >=20 >=20 >> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat = wrote: >>=20 >> Chad, >>=20 >> Welcome to the RUM WG! >>=20 >> On 8/30/21 11:51 AM, Chad Leeper wrote: >>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going = forward, it can't be a "MUST" requirement. I agree with Roger Slusser = that mandating compliance using MUST requires providers to implement = significant development to change over to what RUM is specifying. >>=20 >> The requirements in this doc will apply only to devices that claim to = conform to it. Presumably you could continue to support your existing = devices using whatever mechanisms they currently use. So the = implementation burden is only on the server side, not the legacy device = side. (Of course the FCC will have a say in this.) >>=20 >> One motivation for the webrtc requirement is so that a RUE can be = built on top of WebRTC. E.g., it can be a server that supports deaf = users using any device with a browser. Such a server is effectively just = signaling gateway that can establish a p2p link between the browser and = the VRS provider server. (It does have to transcode RTT, but that is = less of a burden.) >>=20 >> When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal. >>=20 >>> - We should keep any new privacy requirements very minimal at this = time. While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet. So what may look like an easy change to EU implementers may be a = dramatic change for others. >>=20 >> I don't think we have said much about privacy of retained data. But = we are concerned that the media and signaling be private between the RUE = and the provider. That is a low bar these days. It is unlikely that = anything less could be approved. I expect the FCC will agree. >>=20 >> If you have an alternate proposal that achieves that then make a = proposal we can discuss. >>=20 >> Thanks, >> Paul >>=20 >>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > wrote: >>> Providers, >>> My request below to Roger should have been broader. You all seem = to >>> have >>> the same issue. I encourage any/all of you to make an alternative >>> proposal here. Just saying "we don't like what is there" isn't = helpful >>> without an alternative. >>> Thanks, >>> Paul >>> On 8/26/21 5:40 PM, Paul Kyzivat wrote: >>>> Roger, >>>>=20 >>>> On 8/26/21 3:30 PM, Roger Slusser wrote: >>>>=20 >>>>> Most providers already support encryption and IPV6 on a limited >>> scope, >>>>> not necessarily the way it is defined in RUM spec. Mandating >>>>> compliance using MUST requires providers to discard sometimes huge >>>>> amounts of development to change over to what RUM is specifying. >>> The >>>>> push back is not about doing these things it is about the loss of >>>>> time, effort and money to do them in the way RUM mandates with >>> MUSTs. >>>>=20 >>>> Do you think there is something else we could write in this spec >>> that >>>> covers encryption and IPv6 in a way that is less burdensome for >>>> providers while remaining interoperable with all providers? >>>>=20 >>>> If so, can you please spell it out? >>> -- Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >>> >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Tue Aug 31 03:12:03 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37473A3E8E for ; Tue, 31 Aug 2021 03:11:59 -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 BETL9fpjsC8F for ; Tue, 31 Aug 2021 03:11:54 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 AC77A3A3E89 for ; Tue, 31 Aug 2021 03:11:53 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 A27B61900; Tue, 31 Aug 2021 12:11:49 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 31 Aug 2021 12:11:49 +0200 Cc: Brian Rosen , Paul Kyzivat , "rum@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ed Sayers X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 10:12:00 -0000 > On 31 Aug 2021, at 11:29, Ed Sayers wrote: >=20 > Hi, >=20 > Thought I'd split out IPv6 and encryption as separate points.. >=20 > For encryption, the US VRS Providers recently created a new Provider = Inter-Operability Profile that now specifically allows for encryption = and ICE, amongst other things. >=20 > Whilst we all agreed that SRTP-DTLS is the right way to go, we decided = to specifically adopt RFC-8643 OSRTP, because this allows for the = greatest flexibility and greatest chance of supporting end-to-end = encryption, while still supporting a heterogenous range of devices. OSRTP supports SRTP-DTLS. It=E2=80=99s not an alternative. And it=E2=80=99= s just an informational RFC, not a standards RFC.You still have to = implement SRTP-DTLS so you can use that fully in a situation where all = devices has support. There are other ways to construct the SDP if you want to offer both = RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so one need serious consideration. >=20 > Whilst it is true that encryption could be terminated on the RUE = interface proxy, Aren=E2=80=99t you mixing signalling and media now? > any Provider that wants to allow encryption further into their = Infrastructure is generally faced with the potential need to fork calls = to various devices, possibly only some of which support encryption. = Using RFC-5673 alone would mean that older devices that do not support = encryption would reject the call as unsupported. Isn=E2=80=99t that one of the benefits? A user needs to be assured that = the call is protected. As a provider you may need to have gateways to = the old world if you need that, but still keep the first call leg = encrypted at all times. >=20 > Using OSRTP is by far the simplest and most convenient way to fork the = call and still ensure that the widest range of endpoints can ring. But it doesn=E2=80=99t deliver any guarantee of any kind to the user. /O >=20 > Cheers, >=20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com >=20 > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Rum On Behalf Of Brian Rosen > Sent: 30 August 2021 22:24 > To: Paul Kyzivat > Cc: Chad Leeper ; rum@ietf.org > Subject: Re: [Rum] IPv6 and encryption >=20 > I don=E2=80=99t think there are ANY alternatives to SRTP. There are = alternatives to DTLS-SRTP. There are moves within the IETF to deprecate = SDES, specifically. There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. Since all = providers I know about anchor media, this only affects the initial hop. = Users really want to hear that their media is protected end to end (at = least hop by hop) but our document doesn=E2=80=99t require that. Again, = we need a STANDARDS based solution, and we have to live within the = constraints the IETF has for new standards with respect to security. = Like nearly every organization, the IETF is much more security conscious = than it was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism. =20 >=20 > I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. = We=E2=80=99ve spent lots of time and cycles implementing things that = turn out not to be secure enough, and we have to move forward on things = that are. DTLS-SRTP is one of those things, as is IPv6. >=20 > Brian >=20 >=20 >> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat = wrote: >>=20 >> Chad, >>=20 >> Welcome to the RUM WG! >>=20 >> On 8/30/21 11:51 AM, Chad Leeper wrote: >>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going = forward, it can't be a "MUST" requirement. I agree with Roger Slusser = that mandating compliance using MUST requires providers to implement = significant development to change over to what RUM is specifying. >>=20 >> The requirements in this doc will apply only to devices that claim to = conform to it. Presumably you could continue to support your existing = devices using whatever mechanisms they currently use. So the = implementation burden is only on the server side, not the legacy device = side. (Of course the FCC will have a say in this.) >>=20 >> One motivation for the webrtc requirement is so that a RUE can be = built on top of WebRTC. E.g., it can be a server that supports deaf = users using any device with a browser. Such a server is effectively just = signaling gateway that can establish a p2p link between the browser and = the VRS provider server. (It does have to transcode RTT, but that is = less of a burden.) >>=20 >> When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal. >>=20 >>> - We should keep any new privacy requirements very minimal at this = time. While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet. So what may look like an easy change to EU implementers may be a = dramatic change for others. >>=20 >> I don't think we have said much about privacy of retained data. But = we are concerned that the media and signaling be private between the RUE = and the provider. That is a low bar these days. It is unlikely that = anything less could be approved. I expect the FCC will agree. >>=20 >> If you have an alternate proposal that achieves that then make a = proposal we can discuss. >>=20 >> Thanks, >> Paul >>=20 >>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > wrote: >>> Providers, >>> My request below to Roger should have been broader. You all seem = to >>> have >>> the same issue. I encourage any/all of you to make an alternative >>> proposal here. Just saying "we don't like what is there" isn't = helpful >>> without an alternative. >>> Thanks, >>> Paul >>> On 8/26/21 5:40 PM, Paul Kyzivat wrote: >>>> Roger, >>>>=20 >>>> On 8/26/21 3:30 PM, Roger Slusser wrote: >>>>=20 >>>>> Most providers already support encryption and IPV6 on a limited >>> scope, >>>>> not necessarily the way it is defined in RUM spec. Mandating >>>>> compliance using MUST requires providers to discard sometimes huge >>>>> amounts of development to change over to what RUM is specifying. >>> The >>>>> push back is not about doing these things it is about the loss of >>>>> time, effort and money to do them in the way RUM mandates with >>> MUSTs. >>>>=20 >>>> Do you think there is something else we could write in this spec >>> that >>>> covers encryption and IPv6 in a way that is less burdensome for >>>> providers while remaining interoperable with all providers? >>>>=20 >>>> If so, can you please spell it out? >>> -- Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >>> >>=20 >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Tue Aug 31 03:23:02 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A47D3A3EFC for ; Tue, 31 Aug 2021 03:23:00 -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 VVQRxvBZ31_U for ; Tue, 31 Aug 2021 03:22:53 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 644AD3A3EF9 for ; Tue, 31 Aug 2021 03:22:53 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id g8so19343988ilc.5 for ; Tue, 31 Aug 2021 03:22:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NxJOh+XV2cbu2SXgUD4WZEuLceAkuAqWJe8qmDpacY8=; b=c5RnRz8ZQnDcTR9cP60gDNA61e8OTCTDjfoqgC7UMEzT5qi+wgM3n6hOlyIPgUbHad AD6iGbmgIK9y3U2CteVM5dBtsk2vYmRe6Sfn90yQ3ECPvr+rEX8bfwxlx1DYfFj+Dg9r cGOjZ0AsKSveGkKYXNmy5bfO9NUVycvKg1sSXt3d8P+pLnEy5ZGDRUXnidd5GLHtekQ4 H/CvL0+SGSr7MpNUnTa3YlHwGnQ2qxG1AZ6bIY6l8uGK+liuMuzjBOe9HTYBdid+Vqnu rN5eo5qtrrJg0vm6VkqF6JVzQwUMNCLdH5l0cA83Wbk4Ief+U3wYU/tg9S3KVpzJOVkt c10Q== 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=NxJOh+XV2cbu2SXgUD4WZEuLceAkuAqWJe8qmDpacY8=; b=U26fYWXNFAYigDrbH7w1dMOrIqHyXEkRC9qW43iUkIxE8Si1rAp+I1eKN1bD+sI4FT ewn9xW2VQmR5ZPRAD6RKw4DkikQzqHVdkMIDBFbLsZd5i/uYBeI6FDqisENM5/Z/Zhrd xnEOZszy4CDPjIA1BoBOu7baaUnxcdzJxD1skpZZzHm3acr6UlhKqmiG3bbIVJbrcFnZ Nhjm+d1PIjmf5LecgWAdLgxhrIvAMesbGlKdHs7DEOOJVfYp39V6eLD+LAmAKmm5twJI znYmh74TKMa7ZGtJFKp3SotsKJyi3bTtEwvKARJx6Devu/ogcc3i+ZgvhnxjM9nyg6Rg aBVA== X-Gm-Message-State: AOAM533dIdMa7p+LmFDqyfhVXwa1+F1/wWlpgKHgJzZoxTz+Xxz5O6Pq ZeQv+4Jusr7AGfvPuUqtFda3/kyIxTO2kwPbWrfdbg== X-Google-Smtp-Source: ABdhPJzPrP0GXQ9nDVSvwutOjngciPd6IxyvvOvYGEzudHa4t619uWlEmTTWeJxscvU43L0JaWWrAp71ZJhv2Zf1KJM= X-Received: by 2002:a05:6e02:547:: with SMTP id i7mr19750193ils.102.1630405371239; Tue, 31 Aug 2021 03:22:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Brian Rosen Date: Tue, 31 Aug 2021 06:22:40 -0400 Message-ID: To: "Olle E. Johansson" Cc: Ed Sayers , Paul Kyzivat , "rum@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fe348405cad85441" Archived-At: Subject: Re: [Rum] IPv6 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 10:23:00 -0000 --000000000000fe348405cad85441 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable While I would be willing to work on such a document and as sipvore chair I sure it would be a welcome draft, as author and co-chit here I don=E2=80=99= t want a mis ref to it holding up our document. So, I am happy to include those RFCs as requirements. If you want to suggest any text beyond just making them required, I=E2=80=99d be happy to = include it, and we can then work on a more general draft. Brian On Tue, Aug 31, 2021 at 6:05 AM Olle E. Johansson wrote: > > > > On 31 Aug 2021, at 11:53, Ed Sayers wrote: > > > > Hi, > > > > I have separated out IPv6 as a topic. > > > > We all know that IPv6 is the way to go, and also necessary as the IPv4 > address range has all but dried up. > > However, the transition to IPv6 across the World has not been an easy > one and is definitely not 'just SIP'. > > > > It is also very true to say that IPv6 needs to be embraced on endpoints= ; > US mobile phone carriers were forced to start using IPv6 for handsets a > long time ago. > > However, huge swathes of the Internet remain IPv4, because adding IPv6 > to Infrastructure is not such as easy task to tackle, and because those I= P > addresses rarely change compared to endpoints. > > > > Again, we all agree - IPv6 is the way to go. But, IPv4, NAT64 and DNS64 > are going to be needed for a long time to come. > > For many use-cases, DNS64 and NAT64 hide the transition back to the IPv= 4 > Internet when not supported by Infrastructure. > > But, as we know, SDP include IP addresses that DNS64 and NAT64 cannot > see and will not translate. > > > > Therefore, we'd like to propose for consideration that a RUM endpoint > must also support the following RFCs as a possible fall back to aid the > necessary transition to IPv6 over time: > > * RFC-6052 - IPv6 Addressing of IPv4/IPv6 Translators > > * RFC-7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthes= is > > What makes this special for RUM? Isn=E2=80=99t this support needed for al= l SIP > implementations? If this is needed for transition, I would love to see > these in a generic document for SIP - how to implement it, consideration= s > for SIP and offer/answer as well as security considerations. > > /O > > > > > > Ed Sayers > > Endpoint SDK Team Lead > > Purple, a Division of ZP Better Together, LLC > > purplevrs.com > > > > The information contained in this e-mail message is intended only for > the personal and confidential use of the recipient(s) named above. If you > have received this communication in error, please notify us immediately b= y > e-mail, and delete the original message. > > > > > > > > > > -----Original Message----- > > From: Rum On Behalf Of Brian Rosen > > Sent: 30 August 2021 22:24 > > To: Paul Kyzivat > > Cc: Chad Leeper ; rum@ietf.org > > Subject: Re: [Rum] IPv6 and encryption > > > > I don=E2=80=99t think there are ANY alternatives to SRTP. There are > alternatives to DTLS-SRTP. There are moves within the IETF to deprecate > SDES, specifically. There is push back on that, but it=E2=80=99s an ongo= ing > discussion because SDES isn=E2=80=99t secure enough. Since all provider= s I know > about anchor media, this only affects the initial hop. Users really want > to hear that their media is protected end to end (at least hop by hop) bu= t > our document doesn=E2=80=99t require that. Again, we need a STANDARDS ba= sed > solution, and we have to live within the constraints the IETF has for new > standards with respect to security. Like nearly every organization, the > IETF is much more security conscious than it was, and won=E2=80=99t toler= ate bad > security although it often recognizes the necessity for backwards > compatibility as long as it=E2=80=99s not to a known insecure mechanism. > > > > I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. W= e=E2=80=99ve spent lots > of time and cycles implementing things that turn out not to be secure > enough, and we have to move forward on things that are. DTLS-SRTP is one > of those things, as is IPv6. > > > > Brian > > > > > >> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat > wrote: > >> > >> Chad, > >> > >> Welcome to the RUM WG! > >> > >> On 8/30/21 11:51 AM, Chad Leeper wrote: > >>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going > forward, it can't be a "MUST" requirement. I agree with Roger Slusser th= at > mandating compliance using MUST requires providers to implement significa= nt > development to change over to what RUM is specifying. > >> > >> The requirements in this doc will apply only to devices that claim to > conform to it. Presumably you could continue to support your existing > devices using whatever mechanisms they currently use. So the implementati= on > burden is only on the server side, not the legacy device side. (Of course > the FCC will have a say in this.) > >> > >> One motivation for the webrtc requirement is so that a RUE can be buil= t > on top of WebRTC. E.g., it can be a server that supports deaf users using > any device with a browser. Such a server is effectively just signaling > gateway that can establish a p2p link between the browser and the VRS > provider server. (It does have to transcode RTT, but that is less of a > burden.) > >> > >> When defining a specification for an interface that is to be > implemented by independent parties it is necessary for essential function= s > to have at least one mandatory to implement mechanism. Currently there ar= e > no standards for connecting a RUE to a provider, so we need to pick > *something* to be mandatory to implement. If you have an alternative for > the media you would prefer, then please make a specific proposal. > >> > >>> - We should keep any new privacy requirements very minimal at this > time. While companies in the EU have already created their systems in > compliance with the GDPR, most of the world hasn't created an equivalent > yet. So what may look like an easy change to EU implementers may be a > dramatic change for others. > >> > >> I don't think we have said much about privacy of retained data. But we > are concerned that the media and signaling be private between the RUE and > the provider. That is a low bar these days. It is unlikely that anything > less could be approved. I expect the FCC will agree. > >> > >> If you have an alternate proposal that achieves that then make a > proposal we can discuss. > >> > >> Thanks, > >> Paul > >> > >>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > wrote: > >>> Providers, > >>> My request below to Roger should have been broader. You all seem to > >>> have > >>> the same issue. I encourage any/all of you to make an alternative > >>> proposal here. Just saying "we don't like what is there" isn't > helpful > >>> without an alternative. > >>> Thanks, > >>> Paul > >>> On 8/26/21 5:40 PM, Paul Kyzivat wrote: > >>>> Roger, > >>>> > >>>> On 8/26/21 3:30 PM, Roger Slusser wrote: > >>>> > >>>>> Most providers already support encryption and IPV6 on a limited > >>> scope, > >>>>> not necessarily the way it is defined in RUM spec. Mandating > >>>>> compliance using MUST requires providers to discard sometimes huge > >>>>> amounts of development to change over to what RUM is specifying. > >>> The > >>>>> push back is not about doing these things it is about the loss of > >>>>> time, effort and money to do them in the way RUM mandates with > >>> MUSTs. > >>>> > >>>> Do you think there is something else we could write in this spec > >>> that > >>>> covers encryption and IPv6 in a way that is less burdensome for > >>>> providers while remaining interoperable with all providers? > >>>> > >>>> If so, can you please spell it out? > >>> -- Rum mailing list > >>> Rum@ietf.org > >>> https://www.ietf.org/mailman/listinfo/rum > >>> > >> > >> -- > >> Rum mailing list > >> Rum@ietf.org > >> https://www.ietf.org/mailman/listinfo/rum > > > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > -- > > Rum mailing list > > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > > --000000000000fe348405cad85441 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
While I would be willing to work on such a document and a= s sipvore chair I sure it would be a welcome draft, as author and co-chit h= ere I don=E2=80=99t want a mis ref to it holding up our document.=C2=A0

So, I am happy to include t= hose RFCs as requirements. If you want to suggest any text beyond just maki= ng them required, I=E2=80=99d be happy to include it, and we can then work = on a more general draft.=C2=A0

Brian

On Tue, Aug 31, 2021 at 6:05 AM Olle E. Johansson <oej@edvina.net> wrote:


> On 31 Aug 2021, at 11:53, Ed Sayers <ed.sayers@purple.us> wrote:
>
> Hi,
>
> I have separated out IPv6 as a topic.
>
> We all know that IPv6 is the way to go, and also necessary as the IPv4= address range has all but dried up.
> However, the transition to IPv6 across the World has not been an easy = one and is definitely not 'just SIP'.
>
> It is also very true to say that IPv6 needs to be embraced on endpoint= s; US mobile phone carriers were forced to start using IPv6 for handsets a = long time ago.
> However, huge swathes of the Internet remain IPv4, because adding IPv6= to Infrastructure is not such as easy task to tackle, and because those IP= addresses rarely change compared to endpoints.
>
> Again, we all agree - IPv6 is the way to go. But, IPv4, NAT64 and DNS6= 4 are going to be needed for a long time to come.
> For many use-cases, DNS64 and NAT64 hide the transition back to the IP= v4 Internet when not supported by Infrastructure.
> But, as we know, SDP include IP addresses that DNS64 and NAT64 cannot = see and will not translate.
>
> Therefore, we'd like to propose for consideration that a RUM endpo= int must also support the following RFCs as a possible fall back to aid the= necessary transition to IPv6 over time:
> * RFC-6052 - IPv6 Addressing of IPv4/IPv6 Translators
> * RFC-7050 - Discovery of the IPv6 Prefix Used for IPv6 Address Synthe= sis

What makes this special for RUM? Isn=E2=80=99t this support needed for all = SIP implementations? If this is needed for transition, I would love to see = these in a=C2=A0 generic document for SIP - how to implement it, considerat= ions for SIP and offer/answer as well as security considerations.

/O
>
>
> Ed Sayers
> Endpoint SDK Team Lead
> Purple, a Division of ZP Better Together, LLC
> = purplevrs.com
>
> The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If you h= ave received this communication in error, please notify us immediately by e= -mail, and delete the original message.
>
>
>
>
> -----Original Message-----
> From: Rum <rum-bounces@ietf.org> On Behalf Of Brian Rosen
> Sent: 30 August 2021 22:24
> To: Paul Kyzivat <pkyzivat@alum.mit.edu>
> Cc: Chad Leeper <chad.leeper@convorelay.com>; rum@ietf.org
> Subject: Re: [Rum] IPv6 and encryption
>
> I don=E2=80=99t think there are ANY alternatives to SRTP.=C2=A0 There = are alternatives to DTLS-SRTP.=C2=A0 There are moves within the IETF to dep= recate SDES, specifically.=C2=A0 There is push back on that, but it=E2=80= =99s an ongoing discussion because SDES isn=E2=80=99t secure enough.=C2=A0 = =C2=A0Since all providers I know about anchor media, this only affects the = initial hop.=C2=A0 Users really want to hear that their media is protected = end to end (at least hop by hop) but our document doesn=E2=80=99t require t= hat.=C2=A0 Again, we need a STANDARDS based solution, and we have to live w= ithin the constraints the IETF has for new standards with respect to securi= ty.=C2=A0 Like nearly every organization, the IETF is much more security co= nscious than it was, and won=E2=80=99t tolerate bad security although it of= ten recognizes the necessity for backwards compatibility as long as it=E2= =80=99s not to a known insecure mechanism.=C2=A0
>
> I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing.= =C2=A0 We=E2=80=99ve spent lots of time and cycles implementing things that= turn out not to be secure enough, and we have to move forward on things th= at are.=C2=A0 DTLS-SRTP is one of those things, as is IPv6.
>
> Brian
>
>
>> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:=
>>
>> Chad,
>>
>> Welcome to the RUM WG!
>>
>> On 8/30/21 11:51 AM, Chad Leeper wrote:
>>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea = going forward, it can't be a "MUST" requirement.=C2=A0 I agre= e with Roger Slusser that mandating compliance using MUST requires provider= s to implement significant development to change over to what RUM is specif= ying.
>>
>> The requirements in this doc will apply only to devices that claim= to conform to it. Presumably you could continue to support your existing d= evices using whatever mechanisms they currently use. So the implementation = burden is only on the server side, not the legacy device side. (Of course t= he FCC will have a say in this.)
>>
>> One motivation for the webrtc requirement is so that a RUE can be = built on top of WebRTC. E.g., it can be a server that supports deaf users u= sing any device with a browser. Such a server is effectively just signaling= gateway that can establish a p2p link between the browser and the VRS prov= ider server. (It does have to transcode RTT, but that is less of a burden.)=
>>
>> When defining a specification for an interface that is to be imple= mented by independent parties it is necessary for essential functions to ha= ve at least one mandatory to implement mechanism. Currently there are no st= andards for connecting a RUE to a provider, so we need to pick *something* = to be mandatory to implement. If you have an alternative for the media you = would prefer, then please make a specific proposal.
>>
>>> - We should keep any new privacy requirements very minimal at = this time.=C2=A0 While companies in the EU have already created their syste= ms in compliance with the GDPR, most of the world hasn't created an equ= ivalent yet.=C2=A0 So what may look like an easy change to EU implementers = may be a dramatic change for others.
>>
>> I don't think we have said much about privacy of retained data= . But we are concerned that the media and signaling be private between the = RUE and the provider. That is a low bar these days. It is unlikely that any= thing less could be approved. I expect the FCC will agree.
>>
>> If you have an alternate proposal that achieves that then make a p= roposal we can discuss.
>>
>>=C2=A0 =C2=A0 =C2=A0 Thanks,
>>=C2=A0 =C2=A0 =C2=A0 Paul
>>
>>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat <pkyzivat@alum.mit.edu <= ;mailto:pkyzivat= @alum.mit.edu>> wrote:
>>>=C2=A0 =C2=A0Providers,
>>>=C2=A0 =C2=A0My request below to Roger should have been broader= . You all seem to
>>>=C2=A0 =C2=A0have
>>>=C2=A0 =C2=A0the same issue. I encourage any/all of you to make= an alternative
>>>=C2=A0 =C2=A0proposal here. Just saying "we don't like= what is there" isn't helpful
>>>=C2=A0 =C2=A0without an alternative.
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul
>>>=C2=A0 =C2=A0On 8/26/21 5:40 PM, Paul Kyzivat wrote:
>>>> Roger,
>>>>
>>>> On 8/26/21 3:30 PM, Roger Slusser wrote:
>>>>
>>>>> Most providers already support encryption and IPV6 on = a limited
>>>=C2=A0 =C2=A0scope,
>>>>> not necessarily the way it is defined in RUM spec. Man= dating
>>>>> compliance using MUST requires providers to discard so= metimes huge
>>>>> amounts of development to change over to what RUM is s= pecifying.
>>>=C2=A0 =C2=A0The
>>>>> push back is not about doing these things it is about = the loss of
>>>>> time, effort and money to do them in the way RUM manda= tes with
>>>=C2=A0 =C2=A0MUSTs.
>>>>
>>>> Do you think there is something else we could write in thi= s spec
>>>=C2=A0 =C2=A0that
>>>> covers encryption and IPv6 in a way that is less burdensom= e for
>>>> providers while remaining interoperable with all providers= ?
>>>>
>>>> If so, can you please spell it out?
>>>=C2=A0 =C2=A0--=C2=A0 =C2=A0 =C2=A0Rum mailing list
>>>=C2=A0 =C2=A0= Rum@ietf.org <mailto:Rum@ietf.org>
>>>=C2=A0 =C2=A0https://www.ietf.org/mailman/listi= nfo/rum
>>>=C2=A0 =C2=A0<https://www.ietf.org/mailman/l= istinfo/rum>
>>
>> --
>> Rum mailing list
>> Rum@ietf.org=
>> https://www.ietf.org/mailman/listinfo/rum
>
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum
> --
> Rum mailing list
> Rum@ietf.org
> https://www.ietf.org/mailman/listinfo/rum

--000000000000fe348405cad85441-- From nobody Tue Aug 31 03:30:39 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6EBD3A3F49 for ; Tue, 31 Aug 2021 03:30:36 -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, 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=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JQCt129Zrj04 for ; Tue, 31 Aug 2021 03:30:30 -0700 (PDT) Received: from stmail1.purple.us (stmail1.purple.us [54.177.253.121]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3569C3A3F3F for ; Tue, 31 Aug 2021 03:30:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail1.purple.us (Postfix) with ESMTP id F1FF219254F; Tue, 31 Aug 2021 05:30:35 -0500 (CDT) Authentication-Results: stmail1.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=k2BCvicu header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail1.purple.us (Postfix) with ESMTPS id 9BF71192559; Tue, 31 Aug 2021 05:30:35 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dIPUZLDSRYvad/GPGZaXsy0r7r0PrEBq/f6r5wlySc0ITD3ytwWc8hwqSaJHXurlvYRl6G5zsspwL7hqAW50EXnVC9d7335KhnVblJhfOkSP4LPU60ibM4Wgnn3+ZbzgS0UQktKFBgdmdMfY2/IM1EgP5ekvasygLPthHN1gFCcpn7jJfnXXjxumvjVLPIosX+NATfhNmcEDHeYu/VPSrqsh3UJXiswHYUsUK6L/8ZuhaeLRnfwvgX2/jtQmg7CYojUgvPWeVTKbmFpey3K273qmObnu4ld3pKYFtppVgVsjQMAdOj7C8FDLGRKaKXzKEDSWpwir/20K5VbqXqxxEw== 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=Q5No3d8wK1BYRYXUB0cghg8Ly6i9deyLmNML1b+nFwY=; b=XmuuqYTzg4t5bPfya5/m7zjjCz8yIDb/sbZdgDAap4zNiTenIAhxI7mg1CXkh+G3s31MD2bWEd012SIbusb141kqkuK+tdhosL2Ww1OhE+XvYHr/bgn0gHmJVGaTmqEsk+YcXvu/qQokR5hO13Kr30HfbTm6n0iKSGInRk3wJRg4W7ifJK8g1+hEdyQzBdtXOGa3Lupa0zG+YcHrZG2j59adhTRAwddySHZNlYHxaF9EeRN4sT4JhijNr9cVk6VF0mMe+ypJV5m6k7YzSMBHzsVXD3MczKWIzk21CEHe3AQIvYj3EbfCpamo2bJqeU726D0lwNIusfHAfjXBZp+tUA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Q5No3d8wK1BYRYXUB0cghg8Ly6i9deyLmNML1b+nFwY=; b=k2BCvicu+zJbCOaYqPeKcCpCT8Nt3DKTvCHPFDYdbgOehkXjJ533pCFuPz4z4Tb1R8BvmC8DKiBFVaGSzAtfrn0wJLLkouqFufr+zmTKBjzP8+05eCf+ux0xsrsRqMUL2DzpZpJwEQnNTt9Cw+AqTAlRjZIZTVlcaJNXv82ilXQ= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM5PR19MB1081.namprd19.prod.outlook.com (2603:10b6:3:26::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4436.19; Tue, 31 Aug 2021 10:30:19 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 10:30:19 +0000 From: Ed Sayers To: "Olle E. Johansson" CC: Brian Rosen , Paul Kyzivat , "rum@ietf.org" Thread-Topic: [Rum] encryption Thread-Index: AdeeR7wCxTV6yTDtS7ecSm7HwjQ0zQACOBuAAABKTTA= Date: Tue, 31 Aug 2021 10:30:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ea444af9-1afa-46ce-0c12-08d96c6a54e2 x-ms-traffictypediagnostic: DM5PR19MB1081: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: y5E6qWWzuE65yQukzs6WQqAGupwXNZWKEhscclk2oP4t4cInQN5a5UusXKMwudAwxq0gV0mDbhZNzvrArUvenR5EtUkJ/3/LNsogn3F36LLce8ljws4GOPNnRvuFNB+PcGl5neBwU82bHo5UDJsp/V4qSgQZ1QdbFoEZd+PcluGohn3IKnu19v/wxD4K/S+J2Jyi+MzDPNhNceZ7A3WlRYnAsSCsHQ2pUF3bqa+b1P0ynx+ei+J33LzALeoMnYoybX1Ue73zIc8PDNgZJzEYUxcyiXcLv9+aG4lhxnO0bjEMuLsOfOrrkuaBAdjTsgoMvmqL6NvkNd39NFWnOMI6kxpKW+0vUEu703uhoKmnQu7A30ESF3OoDUeV9LB26H3ZgypiYJQfDJ4eFqMuzV47trSIfwMSC3OOQ9UIdMGY9oaAk4VZ74bCguI9ddD0Ibq2UYk6EK2G4BiD0wnO77IGPYJ7cM3NLoNIDzfL5WKZhltTvY4/o79hRYgzcOXDuOy+eKFhcmYu05gktBi9Zg6DMX3FburIoQLm/DMidHnLH06bVRyz5836mWCcfkShb5oqrJEO6+uqQYkUgjWLlc+hAxFWWCWQlSoPs52oh/wdbStYDya3OqmBDyILqR1p55PBSuWuUb82EaFK9ha9DcnN1VgM0iOU0zFi0VpZj4xDWrcenI6JQUP7I24ZNrg8Hsj2WlZMMy/EfuoJJeX0s/4xSW7i+EvqGmduGdW12LNyiiKEndbfo3CnOe8IRZfORIQ39JVc5muqckotbp/zPLrvDkbu9fgmH0PSsoOTV5THSsYS/R0Q/95gXeqoEzmdmKwS x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39850400004)(136003)(376002)(396003)(366004)(66476007)(66446008)(38100700002)(33656002)(7696005)(6506007)(55236004)(8936002)(53546011)(66946007)(64756008)(55016002)(4326008)(122000001)(186003)(316002)(478600001)(26005)(966005)(71200400001)(9686003)(52536014)(86362001)(54906003)(38070700005)(6916009)(66556008)(2906002)(8676002)(76116006)(44832011)(83380400001)(66574015)(5660300002)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?M1JBRS9kTWl1bVZLWWFoRjJHNEJTZXhaOU03UmFtTE1IeGZ2WkhPUUkwUi8x?= =?utf-8?B?ZlRUZG8xU0FNRkdpQjZPdEhxZnh5MEtKcnd4N3JqaHp6RFNLZ1V1dlpLdnJC?= =?utf-8?B?eE8vOUN0emFmNTRQMkkwb0RKNURQRkVHR2FEVjBIaUFEK2U0L3VxVWF3ZE9M?= =?utf-8?B?enU1djZRR1k3bm1wbFptOUE3VG9lRk1aS29ISFRnNk9pUGVtTzF0TW9LUXJm?= =?utf-8?B?M2ZZUVgzcUI1T1E2SWdSTE93ampLSjJ6Ymlwck9ZRThHaGs4UnBwMUxNWUo1?= =?utf-8?B?ZU9tai9QNnVYTmtUbEU2MFhibVBqOVR1MWtoaThkVzE4TmYvelg4bnkwUEZR?= =?utf-8?B?enJlcnpMV3pHZEFFRlRMQjNVb3JkQXFiQmxpVzdJK1VtSVJSWlpCYzhSclRQ?= =?utf-8?B?aXJNazNBZ3NBOU5GdDZqcGRwTCtwTllXRlJvWW5ENDlZWkdpdFVRbDI4Qmhj?= =?utf-8?B?NDEzb3hwMlB1TTlvUktyVzM3SmliVEtKK0tsTnpNMDdzTUpFcG00Mlo2YUxz?= =?utf-8?B?TmxJbGJCUFkvVWZKMWFnUkNTSjI2YXJWVVFZemNXRmhNT3hGUnhJZFFVSmZz?= =?utf-8?B?MGRYclB4eWphN1FSR3NsY09XNHlkODBsclk3eGpraEQ2ZkJZS09aOFA1Q2tW?= =?utf-8?B?VTgxY3Y3Y0FuM2lTakRORmFFQm92Y0NYSTNoVHUvWTRnYWYyZVlySEh2WXJU?= =?utf-8?B?ZCtoTWVrSXZFelU1NmVFdXB0UlhuZ2xrUjI5K0RkWHhlMkFsQVB4SzVrVWhu?= =?utf-8?B?SzRTbjFqc0d1YnZQejdMT2U4dGxUR01rQ3gvcVByMmRQVHR2NGtoNGo4ZXFk?= =?utf-8?B?Kys4N3JTc01HZ01nMzFQRzBUaFNjVUJnUzRVSjVsZkJ5SGJXbUdFZ1pUWDBk?= =?utf-8?B?VUlFV09vK1ZpWm8ycEFUQS9wK2F1RjBBUDdZcytoR2FaajcycFdDYTJ6OGw0?= =?utf-8?B?SUJwZzJaZmQ1Wk0rYnRBMjlvNXl1L3crSm13cDhpcWh3Ry9XQys3YWx6TFRY?= =?utf-8?B?ZmhJM0kreDIxbXEzTSthUDFiQ0tTSk95N1Z6Zkt0M3QwdTdRR3JoSHZVS0hX?= =?utf-8?B?cjF1emh5TDlMMUFDWUd6WVNBSUk3UHRIL1RlMTM5K3ArTHJLODJsMHY5dGJG?= =?utf-8?B?YytXQ3E4dWhZTmpyR0hFMWZoQ2lnWXdSR1NQd1MvcmpEZHhHQ29BRll2Qyt4?= =?utf-8?B?bEtMUTFVVFVZM1ZLZ2huaG1XOE5xaVB3TW1rZnlHeW1udmZiMmpSaDF1c0Zv?= =?utf-8?B?TmRJc2lOZnVidk9ZSTdnVXlBN1JVOUdqOWJZT0dlb3dBQjV2anZqeERNbXRz?= =?utf-8?B?VmM0VnA5eEVLa1lLRS9mTlQrWXZwaUxzR0d6M2krakNqL0tpREg1T0gxQUpn?= =?utf-8?B?WmUrR1o2dzA3dERuRXJjTUxkWnh1ZEx1dTh2dDJNdWd2cGFZUjF5WnpXVTFT?= =?utf-8?B?VHJpODhRL3U4ZFdRZXFUaWtQdHN4LzM1V2tUKzNscGpzbk5uZTlpZ05MSVBH?= =?utf-8?B?elhYYkNBaG9PNks0bXY0OEFpWlV3Q2hBeGxVekJQVzFhcnZhcURTemhZTjRh?= =?utf-8?B?aWhmZWN1UkdYc0lERjU0eHdFaFg2RjVuWFp1VVlZZUdXVDlCa3hXZmxnWjVL?= =?utf-8?B?Y0hyK00waVZuRUp2Z3RaRW4zNllEZ0FBK0dWdGRrT2NnZ1VST2pJdFRHKzJQ?= =?utf-8?B?ZDVnWlpOb2JiMjhTUGJ0b0RuSEhrWGViUzhXcHZBOVhpT1phTXc4NlJ1L1Ni?= =?utf-8?Q?w3KI//gvDXFqGnOrg/wpooI9i2M+LPHozCaYY9G?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ea444af9-1afa-46ce-0c12-08d96c6a54e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2021 10:30:19.4147 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: NZzv+pkbxMQYnklwTJgv8JsbZQxxRvYP10ULOb6foRE0dhnPybvW9XPLWpcjJzTnwIr1Q3Jsa/pS4ifenONCGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR19MB1081 Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 10:30:37 -0000 SGksDQoNCklubGluZSBiZWxvdy4uDQoNCg0KRWQgU2F5ZXJzDQpFbmRwb2ludCBTREsgVGVhbSBM ZWFkDQpQdXJwbGUsIGEgRGl2aXNpb24gb2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEMNCnB1cnBs ZXZycy5jb20NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNz YWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb25hbCBhbmQgY29uZmlkZW50aWFsIHVz ZSBvZiB0aGUgcmVjaXBpZW50KHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkg YnkgZS1tYWlsLCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogT2xsZSBFLiBKb2hhbnNzb24gPG9lakBlZHZp bmEubmV0PiANClNlbnQ6IDMxIEF1Z3VzdCAyMDIxIDExOjEyDQpUbzogRWQgU2F5ZXJzIDxlZC5z YXllcnNAcHVycGxlLnVzPg0KQ2M6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD47IFBh dWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PjsgcnVtQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW1J1bV0gZW5jcnlwdGlvbg0KDQoNCg0KPiBPbiAzMSBBdWcgMjAyMSwgYXQgMTE6Mjks IEVkIFNheWVycyA8ZWQuc2F5ZXJzQHB1cnBsZS51cz4gd3JvdGU6DQo+IA0KPiBIaSwNCj4gDQo+ IFRob3VnaHQgSSdkIHNwbGl0IG91dCBJUHY2IGFuZCBlbmNyeXB0aW9uIGFzIHNlcGFyYXRlIHBv aW50cy4uDQo+IA0KPiBGb3IgZW5jcnlwdGlvbiwgdGhlIFVTIFZSUyBQcm92aWRlcnMgcmVjZW50 bHkgY3JlYXRlZCBhIG5ldyBQcm92aWRlciBJbnRlci1PcGVyYWJpbGl0eSBQcm9maWxlIHRoYXQg bm93IHNwZWNpZmljYWxseSBhbGxvd3MgZm9yIGVuY3J5cHRpb24gYW5kIElDRSwgYW1vbmdzdCBv dGhlciB0aGluZ3MuDQo+IA0KPiBXaGlsc3Qgd2UgYWxsIGFncmVlZCB0aGF0IFNSVFAtRFRMUyBp cyB0aGUgcmlnaHQgd2F5IHRvIGdvLCB3ZSBkZWNpZGVkIHRvIHNwZWNpZmljYWxseSBhZG9wdCBS RkMtODY0MyBPU1JUUCwgYmVjYXVzZSB0aGlzIGFsbG93cyBmb3IgdGhlIGdyZWF0ZXN0IGZsZXhp YmlsaXR5IGFuZCBncmVhdGVzdCBjaGFuY2Ugb2Ygc3VwcG9ydGluZyBlbmQtdG8tZW5kIGVuY3J5 cHRpb24sIHdoaWxlIHN0aWxsIHN1cHBvcnRpbmcgYSBoZXRlcm9nZW5vdXMgcmFuZ2Ugb2YgZGV2 aWNlcy4NCg0KDQpPU1JUUCBzdXBwb3J0cyBTUlRQLURUTFMuIEl04oCZcyBub3QgYW4gYWx0ZXJu YXRpdmUuIEFuZCBpdOKAmXMganVzdCBhbiBpbmZvcm1hdGlvbmFsIFJGQywgbm90IGEgc3RhbmRh cmRzIFJGQy5Zb3Ugc3RpbGwgaGF2ZSB0byBpbXBsZW1lbnQgU1JUUC1EVExTIHNvIHlvdSBjYW4g dXNlIHRoYXQgZnVsbHkgaW4gYSBzaXR1YXRpb24gd2hlcmUgYWxsIGRldmljZXMgaGFzIHN1cHBv cnQuDQoNCkVkUyAtIFdlIGtub3cgaXQgaXMgbm90IGFuIGFsdGVybmF0aXZlLiBJdCBzaW1wbHkg cmV2ZXJ0IHRoZSBwcm9maWxlIHRvIFJUUC9BVlAsIHdoaWxlIGtlZXBpbmcgdGhlIGZpbmdlcnBy aW50IGFuZCBzZXR1cCBhdHRyaWJ1dGVzLiBUaGlzIG1lYW5zIHRoYXQgYW4gZW5kcG9pbnQgdGhh dCBzZWVzIHRoZSBhdHRyaWJ1dGVzIGNhbiByZXBsYXkgbGlrZXdpc2UgYW5kIGFncmVlIFNSVFAt RFRMUy4gT2xkIGVuZHBvaW50cyBpZ25vcmUgdGhlIGF0dHJpYnV0ZXMgYW5kIGNhbiBzdGlsbCBh bnN3ZXIgdGhlIGNhbGwuDQoNClRoZXJlIGFyZSBvdGhlciB3YXlzIHRvIGNvbnN0cnVjdCB0aGUg U0RQIGlmIHlvdSB3YW50IHRvIG9mZmVyIGJvdGggUlRQL1NBVlAgYW5kIFJUUC9BVlAsIGJ1dCB0 aGF0IG9wZW5zIHVwIGZvciBkb3duZ3JhZGUgYXR0YWNrcywgc28gb25lIG5lZWQgc2VyaW91cyBj b25zaWRlcmF0aW9uLg0KDQpFZFMgLSBUeXBpY2FsbHksIG9sZGVyIGVuZHBvaW50cyBhbHNvIHdv dWxkIG5vdCBzdXBwb3J0IHRoaXMsIHdoaWNoIGlzIHRoZSBiZW5lZml0IG9mIE9TUlRQIC0gSXQg aXMgYmFja3dhcmRseSBjb21wYXRpYmxlLg0KDQo+IA0KPiBXaGlsc3QgaXQgaXMgdHJ1ZSB0aGF0 IGVuY3J5cHRpb24gY291bGQgYmUgdGVybWluYXRlZCBvbiB0aGUgUlVFIA0KPiBpbnRlcmZhY2Ug cHJveHksDQoNCkFyZW7igJl0IHlvdSBtaXhpbmcgc2lnbmFsbGluZyBhbmQgbWVkaWEgbm93Pw0K DQpFZFMgLSBJIGFtIG1pc3Npbmcgd2hhdCB5b3UgbWVhbiBoZXJlLg0KDQo+IGFueSBQcm92aWRl ciB0aGF0IHdhbnRzIHRvIGFsbG93IGVuY3J5cHRpb24gZnVydGhlciBpbnRvIHRoZWlyIEluZnJh c3RydWN0dXJlIGlzIGdlbmVyYWxseSBmYWNlZCB3aXRoIHRoZSBwb3RlbnRpYWwgbmVlZCB0byBm b3JrIGNhbGxzIHRvIHZhcmlvdXMgZGV2aWNlcywgcG9zc2libHkgb25seSBzb21lIG9mIHdoaWNo IHN1cHBvcnQgZW5jcnlwdGlvbi4gVXNpbmcgUkZDLTU2NzMgYWxvbmUgd291bGQgbWVhbiB0aGF0 IG9sZGVyIGRldmljZXMgdGhhdCBkbyBub3Qgc3VwcG9ydCBlbmNyeXB0aW9uIHdvdWxkIHJlamVj dCB0aGUgY2FsbCBhcyB1bnN1cHBvcnRlZC4NCg0KSXNu4oCZdCB0aGF0IG9uZSBvZiB0aGUgYmVu ZWZpdHM/IEEgdXNlciBuZWVkcyB0byBiZSBhc3N1cmVkIHRoYXQgdGhlIGNhbGwgaXMgcHJvdGVj dGVkLiBBcyBhIHByb3ZpZGVyIHlvdSBtYXkgbmVlZCB0byBoYXZlIGdhdGV3YXlzIHRvIHRoZSBv bGQgd29ybGQgaWYgeW91IG5lZWQgdGhhdCwgYnV0IHN0aWxsIGtlZXAgdGhlIGZpcnN0IGNhbGwg bGVnIGVuY3J5cHRlZCBhdCBhbGwgdGltZXMuDQoNCkVkUyAtIEZyb20gYSBjdXN0b21lciBzdGFu ZHBvaW50LCBoYXZpbmcgYSByYW5nZSBvZiBkZXZpY2VzIG5vIGxvbmdlciByaW5nIGlzIG5vdCBh IGJlbmVmaXQuIFVzaW5nIE9TUlRQIGFzIGEgbWlncmF0aW9uIHBhdGggdG8gc3VwcG9ydCBlbmQt dG8tZW5kIGVuY3J5cHRpb24gd2hpbGUgb2xkZXIgZGV2aWNlcyBjYW4gYmUgZ3JhZHVhbGx5ICdh Z2VkIG91dCcuDQpUaGUgdXNlciBtaWdodCBvdGhlcndpc2UgaGF2ZSBhbiBpbGx1c2lvbiBvZiBz ZWN1cml0eSAtIHRlcm1pbmF0ZWQgYXQgdGhlIFJVTSBwcm94eSwgd2hpbGUgdGhlIGVuZHBvaW50 IG9uIHRoZSBvdGhlciBlbmQgaXMgbm90IGVuY3J5cHRlZCAoYmVjYXVzZSBpdCBjYW5ub3Qgc3Vw cG9ydCBpdCkuDQoNCj4gDQo+IFVzaW5nIE9TUlRQIGlzIGJ5IGZhciB0aGUgc2ltcGxlc3QgYW5k IG1vc3QgY29udmVuaWVudCB3YXkgdG8gZm9yayB0aGUgY2FsbCBhbmQgc3RpbGwgZW5zdXJlIHRo YXQgdGhlIHdpZGVzdCByYW5nZSBvZiBlbmRwb2ludHMgY2FuIHJpbmcuDQoNCkJ1dCBpdCBkb2Vz buKAmXQgZGVsaXZlciBhbnkgZ3VhcmFudGVlIG9mIGFueSBraW5kIHRvIHRoZSB1c2VyLg0KDQpF ZFMgLSBJdCBwcm92aWRlcyBhIHByb2dyZXNzaW9uIHdoZXJlIG1vcmUgYW5kIG1vcmUgZW5kcG9p bnRzIG92ZXIgdGltZSBjYW4gYmUgZW5jcnlwdGVkLiBQcmVjaXNlbHkgd2h5IHdlIGFkb3B0ZWQg aXQgb24gdGhlIEludGVyLVByb3ZpZGVyIGludGVyZmFjZS4NCg0KDQovTw0KPiANCj4gQ2hlZXJz LA0KPiANCj4gDQo+IEVkIFNheWVycw0KPiBFbmRwb2ludCBTREsgVGVhbSBMZWFkDQo+IFB1cnBs ZSwgYSBEaXZpc2lvbiBvZiBaUCBCZXR0ZXIgVG9nZXRoZXIsIExMQyBwdXJwbGV2cnMuY29tDQo+ IA0KPiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMg aW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbmFsIGFuZCBjb25maWRlbnRpYWwgdXNlIG9mIHRo ZSByZWNpcGllbnQocykgbmFtZWQgYWJvdmUuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1h aWwsIGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo+IA0KPiANCj4gDQo+IA0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCj4gU2VudDogMzAgQXVndXN0IDIwMjEgMjI6 MjQNCj4gVG86IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1Pg0KPiBDYzogQ2hh ZCBMZWVwZXIgPGNoYWQubGVlcGVyQGNvbnZvcmVsYXkuY29tPjsgcnVtQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbUnVtXSBJUHY2IGFuZCBlbmNyeXB0aW9uDQo+IA0KPiBJIGRvbuKAmXQgdGhp bmsgdGhlcmUgYXJlIEFOWSBhbHRlcm5hdGl2ZXMgdG8gU1JUUC4gIFRoZXJlIGFyZSBhbHRlcm5h dGl2ZXMgdG8gRFRMUy1TUlRQLiAgVGhlcmUgYXJlIG1vdmVzIHdpdGhpbiB0aGUgSUVURiB0byBk ZXByZWNhdGUgU0RFUywgc3BlY2lmaWNhbGx5LiAgVGhlcmUgaXMgcHVzaCBiYWNrIG9uIHRoYXQs IGJ1dCBpdOKAmXMgYW4gb25nb2luZyBkaXNjdXNzaW9uIGJlY2F1c2UgU0RFUyBpc27igJl0IHNl Y3VyZSBlbm91Z2guICAgU2luY2UgYWxsIHByb3ZpZGVycyBJIGtub3cgYWJvdXQgYW5jaG9yIG1l ZGlhLCB0aGlzIG9ubHkgYWZmZWN0cyB0aGUgaW5pdGlhbCBob3AuICBVc2VycyByZWFsbHkgd2Fu dCB0byBoZWFyIHRoYXQgdGhlaXIgbWVkaWEgaXMgcHJvdGVjdGVkIGVuZCB0byBlbmQgKGF0IGxl YXN0IGhvcCBieSBob3ApIGJ1dCBvdXIgZG9jdW1lbnQgZG9lc27igJl0IHJlcXVpcmUgdGhhdC4g IEFnYWluLCB3ZSBuZWVkIGEgU1RBTkRBUkRTIGJhc2VkIHNvbHV0aW9uLCBhbmQgd2UgaGF2ZSB0 byBsaXZlIHdpdGhpbiB0aGUgY29uc3RyYWludHMgdGhlIElFVEYgaGFzIGZvciBuZXcgc3RhbmRh cmRzIHdpdGggcmVzcGVjdCB0byBzZWN1cml0eS4gIExpa2UgbmVhcmx5IGV2ZXJ5IG9yZ2FuaXph dGlvbiwgdGhlIElFVEYgaXMgbXVjaCBtb3JlIHNlY3VyaXR5IGNvbnNjaW91cyB0aGFuIGl0IHdh cywgYW5kIHdvbuKAmXQgdG9sZXJhdGUgYmFkIHNlY3VyaXR5IGFsdGhvdWdoIGl0IG9mdGVuIHJl Y29nbml6ZXMgdGhlIG5lY2Vzc2l0eSBmb3IgYmFja3dhcmRzIGNvbXBhdGliaWxpdHkgYXMgbG9u ZyBhcyBpdOKAmXMgbm90IHRvIGEga25vd24gaW5zZWN1cmUgbWVjaGFuaXNtLiAgDQo+IA0KPiBJ IHJlYWxseSB0aGluayB0aGlzIGlzIGEg4oCcc3RlcCB1cCB0byB0aGUgYmFy4oCdIHRoaW5nLiAg V2XigJl2ZSBzcGVudCBsb3RzIG9mIHRpbWUgYW5kIGN5Y2xlcyBpbXBsZW1lbnRpbmcgdGhpbmdz IHRoYXQgdHVybiBvdXQgbm90IHRvIGJlIHNlY3VyZSBlbm91Z2gsIGFuZCB3ZSBoYXZlIHRvIG1v dmUgZm9yd2FyZCBvbiB0aGluZ3MgdGhhdCBhcmUuICBEVExTLVNSVFAgaXMgb25lIG9mIHRob3Nl IHRoaW5ncywgYXMgaXMgSVB2Ni4NCj4gDQo+IEJyaWFuDQo+IA0KPiANCj4+IE9uIEF1ZyAzMCwg MjAyMSwgYXQgNTowNiBQTSwgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdy b3RlOg0KPj4gDQo+PiBDaGFkLA0KPj4gDQo+PiBXZWxjb21lIHRvIHRoZSBSVU0gV0chDQo+PiAN Cj4+IE9uIDgvMzAvMjEgMTE6NTEgQU0sIENoYWQgTGVlcGVyIHdyb3RlOg0KPj4+IC0gV2hpbGUg V2ViUlRDIHcvIFNSVFAvRFRMUyAoZW5jcnlwdGlvbikgaXMgYW4gZXhjZWxsZW50IGlkZWEgZ29p bmcgZm9yd2FyZCwgaXQgY2FuJ3QgYmUgYSAiTVVTVCIgcmVxdWlyZW1lbnQuICBJIGFncmVlIHdp dGggUm9nZXIgU2x1c3NlciB0aGF0IG1hbmRhdGluZyBjb21wbGlhbmNlIHVzaW5nIE1VU1QgcmVx dWlyZXMgcHJvdmlkZXJzIHRvIGltcGxlbWVudCBzaWduaWZpY2FudCBkZXZlbG9wbWVudCB0byBj aGFuZ2Ugb3ZlciB0byB3aGF0IFJVTSBpcyBzcGVjaWZ5aW5nLg0KPj4gDQo+PiBUaGUgcmVxdWly ZW1lbnRzIGluIHRoaXMgZG9jIHdpbGwgYXBwbHkgb25seSB0byBkZXZpY2VzIHRoYXQgY2xhaW0g dG8gDQo+PiBjb25mb3JtIHRvIGl0LiBQcmVzdW1hYmx5IHlvdSBjb3VsZCBjb250aW51ZSB0byBz dXBwb3J0IHlvdXIgZXhpc3RpbmcgDQo+PiBkZXZpY2VzIHVzaW5nIHdoYXRldmVyIG1lY2hhbmlz bXMgdGhleSBjdXJyZW50bHkgdXNlLiBTbyB0aGUgDQo+PiBpbXBsZW1lbnRhdGlvbiBidXJkZW4g aXMgb25seSBvbiB0aGUgc2VydmVyIHNpZGUsIG5vdCB0aGUgbGVnYWN5IA0KPj4gZGV2aWNlIHNp ZGUuIChPZiBjb3Vyc2UgdGhlIEZDQyB3aWxsIGhhdmUgYSBzYXkgaW4gdGhpcy4pDQo+PiANCj4+ IE9uZSBtb3RpdmF0aW9uIGZvciB0aGUgd2VicnRjIHJlcXVpcmVtZW50IGlzIHNvIHRoYXQgYSBS VUUgY2FuIGJlIA0KPj4gYnVpbHQgb24gdG9wIG9mIFdlYlJUQy4gRS5nLiwgaXQgY2FuIGJlIGEg c2VydmVyIHRoYXQgc3VwcG9ydHMgZGVhZiANCj4+IHVzZXJzIHVzaW5nIGFueSBkZXZpY2Ugd2l0 aCBhIGJyb3dzZXIuIFN1Y2ggYSBzZXJ2ZXIgaXMgZWZmZWN0aXZlbHkgDQo+PiBqdXN0IHNpZ25h bGluZyBnYXRld2F5IHRoYXQgY2FuIGVzdGFibGlzaCBhIHAycCBsaW5rIGJldHdlZW4gdGhlIA0K Pj4gYnJvd3NlciBhbmQgdGhlIFZSUyBwcm92aWRlciBzZXJ2ZXIuIChJdCBkb2VzIGhhdmUgdG8g dHJhbnNjb2RlIFJUVCwgDQo+PiBidXQgdGhhdCBpcyBsZXNzIG9mIGEgYnVyZGVuLikNCj4+IA0K Pj4gV2hlbiBkZWZpbmluZyBhIHNwZWNpZmljYXRpb24gZm9yIGFuIGludGVyZmFjZSB0aGF0IGlz IHRvIGJlIGltcGxlbWVudGVkIGJ5IGluZGVwZW5kZW50IHBhcnRpZXMgaXQgaXMgbmVjZXNzYXJ5 IGZvciBlc3NlbnRpYWwgZnVuY3Rpb25zIHRvIGhhdmUgYXQgbGVhc3Qgb25lIG1hbmRhdG9yeSB0 byBpbXBsZW1lbnQgbWVjaGFuaXNtLiBDdXJyZW50bHkgdGhlcmUgYXJlIG5vIHN0YW5kYXJkcyBm b3IgY29ubmVjdGluZyBhIFJVRSB0byBhIHByb3ZpZGVyLCBzbyB3ZSBuZWVkIHRvIHBpY2sgKnNv bWV0aGluZyogdG8gYmUgbWFuZGF0b3J5IHRvIGltcGxlbWVudC4gSWYgeW91IGhhdmUgYW4gYWx0 ZXJuYXRpdmUgZm9yIHRoZSBtZWRpYSB5b3Ugd291bGQgcHJlZmVyLCB0aGVuIHBsZWFzZSBtYWtl IGEgc3BlY2lmaWMgcHJvcG9zYWwuDQo+PiANCj4+PiAtIFdlIHNob3VsZCBrZWVwIGFueSBuZXcg cHJpdmFjeSByZXF1aXJlbWVudHMgdmVyeSBtaW5pbWFsIGF0IHRoaXMgdGltZS4gIFdoaWxlIGNv bXBhbmllcyBpbiB0aGUgRVUgaGF2ZSBhbHJlYWR5IGNyZWF0ZWQgdGhlaXIgc3lzdGVtcyBpbiBj b21wbGlhbmNlIHdpdGggdGhlIEdEUFIsIG1vc3Qgb2YgdGhlIHdvcmxkIGhhc24ndCBjcmVhdGVk IGFuIGVxdWl2YWxlbnQgeWV0LiAgU28gd2hhdCBtYXkgbG9vayBsaWtlIGFuIGVhc3kgY2hhbmdl IHRvIEVVIGltcGxlbWVudGVycyBtYXkgYmUgYSBkcmFtYXRpYyBjaGFuZ2UgZm9yIG90aGVycy4N Cj4+IA0KPj4gSSBkb24ndCB0aGluayB3ZSBoYXZlIHNhaWQgbXVjaCBhYm91dCBwcml2YWN5IG9m IHJldGFpbmVkIGRhdGEuIEJ1dCB3ZSBhcmUgY29uY2VybmVkIHRoYXQgdGhlIG1lZGlhIGFuZCBz aWduYWxpbmcgYmUgcHJpdmF0ZSBiZXR3ZWVuIHRoZSBSVUUgYW5kIHRoZSBwcm92aWRlci4gVGhh dCBpcyBhIGxvdyBiYXIgdGhlc2UgZGF5cy4gSXQgaXMgdW5saWtlbHkgdGhhdCBhbnl0aGluZyBs ZXNzIGNvdWxkIGJlIGFwcHJvdmVkLiBJIGV4cGVjdCB0aGUgRkNDIHdpbGwgYWdyZWUuDQo+PiAN Cj4+IElmIHlvdSBoYXZlIGFuIGFsdGVybmF0ZSBwcm9wb3NhbCB0aGF0IGFjaGlldmVzIHRoYXQg dGhlbiBtYWtlIGEgcHJvcG9zYWwgd2UgY2FuIGRpc2N1c3MuDQo+PiANCj4+IAlUaGFua3MsDQo+ PiAJUGF1bA0KPj4gDQo+Pj4gT24gRnJpLCBBdWcgMjcsIDIwMjEgYXQgMzoxNiBQTSBQYXVsIEt5 eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdSA8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVk dT4+IHdyb3RlOg0KPj4+ICAgUHJvdmlkZXJzLA0KPj4+ICAgTXkgcmVxdWVzdCBiZWxvdyB0byBS b2dlciBzaG91bGQgaGF2ZSBiZWVuIGJyb2FkZXIuIFlvdSBhbGwgc2VlbSB0bw0KPj4+ICAgaGF2 ZQ0KPj4+ICAgdGhlIHNhbWUgaXNzdWUuIEkgZW5jb3VyYWdlIGFueS9hbGwgb2YgeW91IHRvIG1h a2UgYW4gYWx0ZXJuYXRpdmUNCj4+PiAgIHByb3Bvc2FsIGhlcmUuIEp1c3Qgc2F5aW5nICJ3ZSBk b24ndCBsaWtlIHdoYXQgaXMgdGhlcmUiIGlzbid0IGhlbHBmdWwNCj4+PiAgIHdpdGhvdXQgYW4g YWx0ZXJuYXRpdmUuDQo+Pj4gICAgICAgICAgICBUaGFua3MsDQo+Pj4gICAgICAgICAgICBQYXVs DQo+Pj4gICBPbiA4LzI2LzIxIDU6NDAgUE0sIFBhdWwgS3l6aXZhdCB3cm90ZToNCj4+Pj4gUm9n ZXIsDQo+Pj4+IA0KPj4+PiBPbiA4LzI2LzIxIDM6MzAgUE0sIFJvZ2VyIFNsdXNzZXIgd3JvdGU6 DQo+Pj4+IA0KPj4+Pj4gTW9zdCBwcm92aWRlcnMgYWxyZWFkeSBzdXBwb3J0IGVuY3J5cHRpb24g YW5kIElQVjYgb24gYSBsaW1pdGVkDQo+Pj4gICBzY29wZSwNCj4+Pj4+IG5vdCBuZWNlc3Nhcmls eSB0aGUgd2F5IGl0IGlzIGRlZmluZWQgaW4gUlVNIHNwZWMuIE1hbmRhdGluZyANCj4+Pj4+IGNv bXBsaWFuY2UgdXNpbmcgTVVTVCByZXF1aXJlcyBwcm92aWRlcnMgdG8gZGlzY2FyZCBzb21ldGlt ZXMgaHVnZSANCj4+Pj4+IGFtb3VudHMgb2YgZGV2ZWxvcG1lbnQgdG8gY2hhbmdlIG92ZXIgdG8g d2hhdCBSVU0gaXMgc3BlY2lmeWluZy4NCj4+PiAgIFRoZQ0KPj4+Pj4gcHVzaCBiYWNrIGlzIG5v dCBhYm91dCBkb2luZyB0aGVzZSB0aGluZ3MgaXQgaXMgYWJvdXQgdGhlIGxvc3Mgb2YgDQo+Pj4+ PiB0aW1lLCBlZmZvcnQgYW5kIG1vbmV5IHRvIGRvIHRoZW0gaW4gdGhlIHdheSBSVU0gbWFuZGF0 ZXMgd2l0aA0KPj4+ICAgTVVTVHMuDQo+Pj4+IA0KPj4+PiBEbyB5b3UgdGhpbmsgdGhlcmUgaXMg c29tZXRoaW5nIGVsc2Ugd2UgY291bGQgd3JpdGUgaW4gdGhpcyBzcGVjDQo+Pj4gICB0aGF0DQo+ Pj4+IGNvdmVycyBlbmNyeXB0aW9uIGFuZCBJUHY2IGluIGEgd2F5IHRoYXQgaXMgbGVzcyBidXJk ZW5zb21lIGZvciANCj4+Pj4gcHJvdmlkZXJzIHdoaWxlIHJlbWFpbmluZyBpbnRlcm9wZXJhYmxl IHdpdGggYWxsIHByb3ZpZGVycz8NCj4+Pj4gDQo+Pj4+IElmIHNvLCBjYW4geW91IHBsZWFzZSBz cGVsbCBpdCBvdXQ/DQo+Pj4gICAtLSAgICAgUnVtIG1haWxpbmcgbGlzdA0KPj4+ICAgUnVtQGll dGYub3JnIDxtYWlsdG86UnVtQGlldGYub3JnPg0KPj4+ICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydW0NCj4+PiAgIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3J1bT4NCj4+IA0KPj4gLS0NCj4+IFJ1bSBtYWlsaW5nIGxpc3QNCj4+IFJ1bUBp ZXRmLm9yZw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0NCj4g DQo+IC0tDQo+IFJ1bSBtYWlsaW5nIGxpc3QNCj4gUnVtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQo+IC0tDQo+IFJ1bSBtYWlsaW5nIGxpc3QN Cj4gUnVtQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnVtDQoNCg== From nobody Tue Aug 31 03:41:18 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B5713A079A for ; Tue, 31 Aug 2021 03:41:16 -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, 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=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ag_2mNtI6cec for ; Tue, 31 Aug 2021 03:41:09 -0700 (PDT) Received: from stmail.purple.us (stmail.purple.us [54.177.79.196]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4DFA3A0798 for ; Tue, 31 Aug 2021 03:41:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail.purple.us (Postfix) with ESMTP id 6F7601A1D97; Tue, 31 Aug 2021 05:46:51 -0500 (CDT) Authentication-Results: stmail.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=HwWz65XX header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2104.outbound.protection.outlook.com [104.47.55.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail.purple.us (Postfix) with ESMTPS id F3A2C1A1DA4; Tue, 31 Aug 2021 05:46:50 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R5Ii44+gIrO4fXPdQt0veLar1tYbGVxBe+6PuZwlDCDrmo1DIqSHcfYOKrVHwCYx4tpkhbF1AWO8COa6xzgy5+bU5dPzz4HVPR6PK/oq4P76KgOUq3N6gUtCzxsB1qpHqjL+HGiszl46ExGxynk8N1otgJsXiJvqwjn+3Jrf04iPveNlGSDDBqBDNFr35+cN6bwtH4DBliSu4hEDqhXd0DwLZHz5MPzvMMSKbQFq59DGIk4qvpwMGgtRhLadVt/lStmRaFQQkEGEkJq255a7/+Dny6qYctszcySA8LTPLSxoTa9XrENtLQlEgYcTQ9/NFpSE3ozkbtM1/ZvHHC1fZA== 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; bh=KzbNzJ8D/48uAsnnJb46TTpKXSECePTk0j2f7+7bFew=; b=CqQQ0Ho6NCG3/javyzmzoI4Aak/CXeHM049GQU4c3mmPBiC7rut3ad9SqGCSu2wbi5VtmPsH+jD5WEo/Ac0VvcWvAb1HEVxEWmO4TmJkMGGRaSSf0nWU21T02X+BJrKa75razmFDuvlczYCPiHLWpp/WG39kBiV6kdQSGuusDkhR910GbSnq0WnkzAWN9GQ9ubSQSqFIezBJQxtLfo6cBae4lN3pLt+pREpDpGL5U9MxEpICWDLZG3SzMBTbChraTqxSYMegTRIQdn3AT5y96Fo8q0HxMQwnUW4FzlNPfc/Ik9H7mHOJGwOKHDgYRU6tRi2cvRlE+bq3q76iUWmk8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KzbNzJ8D/48uAsnnJb46TTpKXSECePTk0j2f7+7bFew=; b=HwWz65XX8XUPgAdYkEqjw4sMeJJDT2JqNgsJqk4q/dZCWRAUMl0KcNYp4lKxaeh+V10hd1SBCe1UE6sNj+qFkurD6yTJvPZ5yPqXlZLlhfPLIpY18k+ySGVpyWhnB9Nu+XgmVsOC7HOo7ci0VrbzqNnmgWbKSz8iZlAaic6tsVo= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM5PR19MB1563.namprd19.prod.outlook.com (2603:10b6:3:149::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.17; Tue, 31 Aug 2021 10:41:01 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 10:41:01 +0000 From: Ed Sayers To: "Olle E. Johansson" , Brian Rosen CC: Paul Kyzivat , "rum@ietf.org" Thread-Topic: [Rum] IPv6 Thread-Index: AdeeSsUbffPyNERDROeDyEupIDr9gwABPagAAAEGLxA= Date: Tue, 31 Aug 2021 10:41:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: edvina.net; dkim=none (message not signed) header.d=none;edvina.net; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b795cba4-b711-474c-27c9-08d96c6bd39f x-ms-traffictypediagnostic: DM5PR19MB1563: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f5EWm20PhvFlY4N4bjBCpLVCWUpP90LLlDcBdm+9cxlTghz826vO8Yrt1DI4Z/hjmgxBxMsdqiZUrATyIdObqcccZEeJzo1LHFukHram7zTIJ2gZWpcFVntHmp4qiY2dC313MFSgq2o2fUHFzm3eRJo56SNZznKNiGFFxbU2kkwU9ryyOwBGR54IzX5ErjtBbB3nMZJiNRBRjSdtZdMMQve42pxCVv1VcEN+gtbmVBkGmAs7TnT/22UV36hTKrq/JP+8l5Qk+pvmToMUB9Nyx+KPuwMi9HvUjJVeeR2brclzJ7HZS8EPPZM15KsTphSqa0woSW8o1mVWF/kxuYXK46JDvLosRnFEBAsQsKRgR+nB/Epub2nyE3axMIR+6fGpXEvUJ5jlFkcxa0l5s2sF+8kuyhA/1NtivH7BgPi4dbyIZVY4QLcWk7zJQvwENignfePJQzqUJTfNDBgTx5h0IHWT7zGKxF5yDHQE7MqcvMSczOlC6nA6HT/dGeGYE4Rq3K+fqgwUlyyYAneo2GThr0gZbzM4FbmwxXV6n4TY/n4Fap1gS0gNB4iAZ5k0GPJEaXKTkZB9eErD7aIdmY8fx3Q/3wS9L9WCO8IOQJF46cs5M40L/NzDHUaTFGwBAOKqq5q3f6DgPFgorna022gqYGSXoreMbQO2ppnDyKm3wBIi+coks37/J+1jlwCxROtu05u7zmz4RQ4eE3DcsgfYqRacWw0370ELQ+TuVq21cGA9o/qElBD+7jnWwYZv6fit08I3KeIMxzqQ7gMFPL0VN1FJuE6PX0BcYk+uSuMqIgcuIpg4kosdNE1ta6qsBTag x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(366004)(376002)(346002)(39850400004)(83380400001)(8676002)(86362001)(5660300002)(8936002)(33656002)(2906002)(71200400001)(7696005)(316002)(110136005)(54906003)(55016002)(4326008)(44832011)(9686003)(66946007)(66556008)(38070700005)(66574015)(6506007)(966005)(64756008)(66446008)(186003)(52536014)(53546011)(76116006)(66476007)(55236004)(122000001)(38100700002)(26005)(478600001)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Sng4UUl4MVk3M21zNVJBSmFPZUptendEMzgxMXlmNVRUamNrN0hWb1JEZ0lW?= =?utf-8?B?TjRJQ093NTI1MUJvWWYxZkp1bUhUajNIK3RvSzFUSS9GM0ZUbXJZNEtsVFhL?= =?utf-8?B?WlZ2cWZsTjg2MnR1U3hXVjUrTUxjcXRBWFFEeGlxckhkZVdTQ01tMnBMTUZ4?= =?utf-8?B?RFhrR2RlV1VuL2JBZGRhRWF3YnVpb0ovYW1EbGNFRTIxQXJqUUdwN1Fydnlo?= =?utf-8?B?Q1pKWnVlUTFodUZZTS9ITEYwY0pEekhsYnpZNW1xNEQ1NzF1OVRuNkJRc3Mv?= =?utf-8?B?UDNjQmFjS2FiNTh2N1lrY3l1L1RMcUh1SXAzY3NSWmpiSTFUZCsyd1RpSFNS?= =?utf-8?B?T29nLzE3UHp6TVRTUURqalc0WWM3OHZxZ0IwUmF6ZTliR3dEdmF4Z3AvNHUx?= =?utf-8?B?dmQ4WGxZLzFIc1NhQ1N2RVZZdnU2VmZkYm1HTVBsNFJ3WU9kZlZFdzZBZ0JW?= =?utf-8?B?QWFBMndSb1BGNHk2OWhGVkNjd0JiYlhzQ20ydXgxWTR5NHdMYU0wSEt5cnZq?= =?utf-8?B?dk81SG9pM2RYa2NxUnVxWnN2LzFmTU9SZGlnZkFNcU9ldkZKU0dHUVNzQW0z?= =?utf-8?B?Wm9jazRSRGI5Y2s5Sy8wdFNwL2FFNktWVEcyeHdlOUFiQVJlOEJ2TUQzNVhV?= =?utf-8?B?Ym1jdXVaR3hSY1RSTjFSaW1tdTRoWUNHSW1SRHNGcUlqN2Zma0JrNWtiZk1P?= =?utf-8?B?OVU3cUliR2p3MEVSeVl0RCtnSnZneXRBZnBTQlR0cHlIZm03dTJMcDJEejlk?= =?utf-8?B?WWx5VWIwbXd3N0phTnM0UytYenVlZlpob0toY3NkUHU3YWtMOXRBWS9Qb21k?= =?utf-8?B?NG02NlduR1cvcEhIMVlzR0dWTXpaQndqdHNTbTdlQzE3N2RaT21Ja1lRMFpt?= =?utf-8?B?cWpjSXpmbVZ0WFViOFM5ckFzK1VGSXJ1OVlIaDFPNzBtU2RCQzlOTkFybE1s?= =?utf-8?B?OUJZN3JmSytsb2l5OFY3cHRlWDhJMmZNeVNiMXJaem9PSEYxWVdvVitPQTdk?= =?utf-8?B?NDFWNU0zSVVXbHIxcFFOaVVKU1VZOE5EVE0wa21iTGxRUDlFMHFKMUMzQzRm?= =?utf-8?B?Q051MFhqOFYvNmZTODBCdlUzVG5FRXpFaStPMTVpNWVOQ3dIR3NYT1Zib0ZD?= =?utf-8?B?SmdwUEo1QlFjS2RwK0NWRUR3UzErR0RUUzdlbW5xNzdadDlYQnNkdU1keDUx?= =?utf-8?B?VTlsc1BQNG8wVmhVdzBrYkR1K2Z5d2VmV2xHRDF3V0xTYk1vMjdnYStWeGJW?= =?utf-8?B?RW43WFRQL2xXRmF1RExpNXpEUlUyeTcvdlNWemgxUHJDL1BKWXRVZ1FQcFZJ?= =?utf-8?B?WWhWbG1IeHFGUWFFTThiQnpMWkFTOFNmcDg0SHEzdFo0L1pRYWFaNDR3dHhH?= =?utf-8?B?emtRVXBoMkl5UjByem5vRmpTYzhhbTZ6cU9TL2hZWDVYTEYwdG1qS0U5UUVj?= =?utf-8?B?YkVSY0VVRWRwOHJ3djNIK2pzR2Y5cGtrVURBTC9uSGpkdytaWFRiZDdoajE2?= =?utf-8?B?Z3Y2c08zbzZRakdiZ0tiYUVIa2s0SjdSUUcxTFdmcnpRaTFxUUpJMG1mK0NL?= =?utf-8?B?MkN3Vy9pUkY2eEJwZUVDNDRBbzZUaTNMY0ZXajZrWGlsQ3QrWldCMEwvWDBa?= =?utf-8?B?bEtucldGRG02N1V4bkdZb01pYUFkNm85dGZWY1N3eEo3aFo2eWZwYTlBczlw?= =?utf-8?B?bkNBRDdjNk0vY0kyUnIyVDkrNEdVUkoxYkJ5Mi9ZMG1wTVJmT21YUUU5ZXpW?= =?utf-8?Q?RXnoehSAT2qx5ZZsQsQgEbDwSC0J1E7uB1SrOd7?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b795cba4-b711-474c-27c9-08d96c6bd39f X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2021 10:41:01.6194 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1EBE1nH69AVNz0qqPXj6fb+4L7bcEWeoubCld8EaeMLxtTFD0wwhH5fUMEmQ7BmlJME6vqrAFe8/wSa/BzkBYg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR19MB1563 Archived-At: Subject: Re: [Rum] IPv6 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 10:41:17 -0000 SGkgT2xsZSwNCg0KSSBhZ3JlZSB0aGF0IHRoZXNlIFJGQ3MgYXJlIHR5cGljYWxseSBuZWNlc3Nh cnkgaW4gU0lQIGNsaWVudHMgZm9yIGV4YWN0bHkgdGhlIHJlYXNvbnMgSSBoYXZlIGdpdmVuLg0K DQpCdXQsIG9uIHRoZSBiYXNpcyB0aGF0IHRoZXNlIGFyZSBub3QgcXVvdGVkIGFueXdoZXJlIGVs c2UgdG8gbXkga25vd2xlZGdlLCBpdCBzZWVtcyB0byBtYWtlIHNlbnNlIHRvIGluY2x1ZGUgdGhl bSBoZXJlIHRvIGNsYXJpZnkgdGhhdCBkdWFsIElQdjQvSVB2NiBJbmZyYXN0cnVjdHVyZSBpcyBu b3QgbmVjZXNzYXJpbHkgYSBwcmVyZXF1aXNpdGUgZm9yIHN1cHBvcnRpbmcgYSBSVU0gY2xpZW50 Lg0KDQpCcmlhbiwNCg0KSSB3aWxsIHRyeSB0byBwdXQgc29tZSB3b3JkcyB0b2dldGhlci4uDQoN Cg0KRWQgU2F5ZXJzDQpFbmRwb2ludCBTREsgVGVhbSBMZWFkDQpQdXJwbGUsIGEgRGl2aXNpb24g b2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEMNClA6ICs0NCA3NTgtNDQ4LTQxNTkgfMKgcHVycGxl dnJzLmNvbQ0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgZS1tYWlsIG1lc3Nh Z2UgaXMgaW50ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbmFsIGFuZCBjb25maWRlbnRpYWwgdXNl IG9mIHRoZSByZWNpcGllbnQocykgbmFtZWQgYWJvdmUuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBi eSBlLW1haWwsIGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQoNCg0KDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmlu YS5uZXQ+IA0KU2VudDogMzEgQXVndXN0IDIwMjEgMTE6MDYNClRvOiBFZCBTYXllcnMgPGVkLnNh eWVyc0BwdXJwbGUudXM+DQpDYzogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PjsgUGF1 bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+OyBydW1AaWV0Zi5vcmcNClN1YmplY3Q6 IFJlOiBbUnVtXSBJUHY2DQoNCg0KDQo+IE9uIDMxIEF1ZyAyMDIxLCBhdCAxMTo1MywgRWQgU2F5 ZXJzIDxlZC5zYXllcnNAcHVycGxlLnVzPiB3cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gSSBoYXZl IHNlcGFyYXRlZCBvdXQgSVB2NiBhcyBhIHRvcGljLg0KPiANCj4gV2UgYWxsIGtub3cgdGhhdCBJ UHY2IGlzIHRoZSB3YXkgdG8gZ28sIGFuZCBhbHNvIG5lY2Vzc2FyeSBhcyB0aGUgSVB2NCBhZGRy ZXNzIHJhbmdlIGhhcyBhbGwgYnV0IGRyaWVkIHVwLg0KPiBIb3dldmVyLCB0aGUgdHJhbnNpdGlv biB0byBJUHY2IGFjcm9zcyB0aGUgV29ybGQgaGFzIG5vdCBiZWVuIGFuIGVhc3kgb25lIGFuZCBp cyBkZWZpbml0ZWx5IG5vdCAnanVzdCBTSVAnLg0KPiANCj4gSXQgaXMgYWxzbyB2ZXJ5IHRydWUg dG8gc2F5IHRoYXQgSVB2NiBuZWVkcyB0byBiZSBlbWJyYWNlZCBvbiBlbmRwb2ludHM7IFVTIG1v YmlsZSBwaG9uZSBjYXJyaWVycyB3ZXJlIGZvcmNlZCB0byBzdGFydCB1c2luZyBJUHY2IGZvciBo YW5kc2V0cyBhIGxvbmcgdGltZSBhZ28uDQo+IEhvd2V2ZXIsIGh1Z2Ugc3dhdGhlcyBvZiB0aGUg SW50ZXJuZXQgcmVtYWluIElQdjQsIGJlY2F1c2UgYWRkaW5nIElQdjYgdG8gSW5mcmFzdHJ1Y3R1 cmUgaXMgbm90IHN1Y2ggYXMgZWFzeSB0YXNrIHRvIHRhY2tsZSwgYW5kIGJlY2F1c2UgdGhvc2Ug SVAgYWRkcmVzc2VzIHJhcmVseSBjaGFuZ2UgY29tcGFyZWQgdG8gZW5kcG9pbnRzLg0KPiANCj4g QWdhaW4sIHdlIGFsbCBhZ3JlZSAtIElQdjYgaXMgdGhlIHdheSB0byBnby4gQnV0LCBJUHY0LCBO QVQ2NCBhbmQgRE5TNjQgYXJlIGdvaW5nIHRvIGJlIG5lZWRlZCBmb3IgYSBsb25nIHRpbWUgdG8g Y29tZS4NCj4gRm9yIG1hbnkgdXNlLWNhc2VzLCBETlM2NCBhbmQgTkFUNjQgaGlkZSB0aGUgdHJh bnNpdGlvbiBiYWNrIHRvIHRoZSBJUHY0IEludGVybmV0IHdoZW4gbm90IHN1cHBvcnRlZCBieSBJ bmZyYXN0cnVjdHVyZS4NCj4gQnV0LCBhcyB3ZSBrbm93LCBTRFAgaW5jbHVkZSBJUCBhZGRyZXNz ZXMgdGhhdCBETlM2NCBhbmQgTkFUNjQgY2Fubm90IHNlZSBhbmQgd2lsbCBub3QgdHJhbnNsYXRl Lg0KPiANCj4gVGhlcmVmb3JlLCB3ZSdkIGxpa2UgdG8gcHJvcG9zZSBmb3IgY29uc2lkZXJhdGlv biB0aGF0IGEgUlVNIGVuZHBvaW50IG11c3QgYWxzbyBzdXBwb3J0IHRoZSBmb2xsb3dpbmcgUkZD cyBhcyBhIHBvc3NpYmxlIGZhbGwgYmFjayB0byBhaWQgdGhlIG5lY2Vzc2FyeSB0cmFuc2l0aW9u IHRvIElQdjYgb3ZlciB0aW1lOg0KPiAqIFJGQy02MDUyIC0gSVB2NiBBZGRyZXNzaW5nIG9mIElQ djQvSVB2NiBUcmFuc2xhdG9ycw0KPiAqIFJGQy03MDUwIC0gRGlzY292ZXJ5IG9mIHRoZSBJUHY2 IFByZWZpeCBVc2VkIGZvciBJUHY2IEFkZHJlc3MgDQo+IFN5bnRoZXNpcw0KDQpXaGF0IG1ha2Vz IHRoaXMgc3BlY2lhbCBmb3IgUlVNPyBJc27igJl0IHRoaXMgc3VwcG9ydCBuZWVkZWQgZm9yIGFs bCBTSVAgaW1wbGVtZW50YXRpb25zPyBJZiB0aGlzIGlzIG5lZWRlZCBmb3IgdHJhbnNpdGlvbiwg SSB3b3VsZCBsb3ZlIHRvIHNlZSB0aGVzZSBpbiBhICBnZW5lcmljIGRvY3VtZW50IGZvciBTSVAg LSBob3cgdG8gaW1wbGVtZW50IGl0LCBjb25zaWRlcmF0aW9ucyBmb3IgU0lQIGFuZCBvZmZlci9h bnN3ZXIgYXMgd2VsbCBhcyBzZWN1cml0eSBjb25zaWRlcmF0aW9ucy4NCg0KL08NCj4gDQo+IA0K PiBFZCBTYXllcnMNCj4gRW5kcG9pbnQgU0RLIFRlYW0gTGVhZA0KPiBQdXJwbGUsIGEgRGl2aXNp b24gb2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEMgcHVycGxldnJzLmNvbQ0KPiANCj4gVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIG9u bHkgZm9yIHRoZSBwZXJzb25hbCBhbmQgY29uZmlkZW50aWFsIHVzZSBvZiB0aGUgcmVjaXBpZW50 KHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24g aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1tYWlsLCBhbmQgZGVs ZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KPiANCj4gDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVo YWxmIE9mIEJyaWFuIFJvc2VuDQo+IFNlbnQ6IDMwIEF1Z3VzdCAyMDIxIDIyOjI0DQo+IFRvOiBQ YXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT4NCj4gQ2M6IENoYWQgTGVlcGVyIDxj aGFkLmxlZXBlckBjb252b3JlbGF5LmNvbT47IHJ1bUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTog W1J1bV0gSVB2NiBhbmQgZW5jcnlwdGlvbg0KPiANCj4gSSBkb27igJl0IHRoaW5rIHRoZXJlIGFy ZSBBTlkgYWx0ZXJuYXRpdmVzIHRvIFNSVFAuICBUaGVyZSBhcmUgYWx0ZXJuYXRpdmVzIHRvIERU TFMtU1JUUC4gIFRoZXJlIGFyZSBtb3ZlcyB3aXRoaW4gdGhlIElFVEYgdG8gZGVwcmVjYXRlIFNE RVMsIHNwZWNpZmljYWxseS4gIFRoZXJlIGlzIHB1c2ggYmFjayBvbiB0aGF0LCBidXQgaXTigJlz IGFuIG9uZ29pbmcgZGlzY3Vzc2lvbiBiZWNhdXNlIFNERVMgaXNu4oCZdCBzZWN1cmUgZW5vdWdo LiAgIFNpbmNlIGFsbCBwcm92aWRlcnMgSSBrbm93IGFib3V0IGFuY2hvciBtZWRpYSwgdGhpcyBv bmx5IGFmZmVjdHMgdGhlIGluaXRpYWwgaG9wLiAgVXNlcnMgcmVhbGx5IHdhbnQgdG8gaGVhciB0 aGF0IHRoZWlyIG1lZGlhIGlzIHByb3RlY3RlZCBlbmQgdG8gZW5kIChhdCBsZWFzdCBob3AgYnkg aG9wKSBidXQgb3VyIGRvY3VtZW50IGRvZXNu4oCZdCByZXF1aXJlIHRoYXQuICBBZ2Fpbiwgd2Ug bmVlZCBhIFNUQU5EQVJEUyBiYXNlZCBzb2x1dGlvbiwgYW5kIHdlIGhhdmUgdG8gbGl2ZSB3aXRo aW4gdGhlIGNvbnN0cmFpbnRzIHRoZSBJRVRGIGhhcyBmb3IgbmV3IHN0YW5kYXJkcyB3aXRoIHJl c3BlY3QgdG8gc2VjdXJpdHkuICBMaWtlIG5lYXJseSBldmVyeSBvcmdhbml6YXRpb24sIHRoZSBJ RVRGIGlzIG11Y2ggbW9yZSBzZWN1cml0eSBjb25zY2lvdXMgdGhhbiBpdCB3YXMsIGFuZCB3b27i gJl0IHRvbGVyYXRlIGJhZCBzZWN1cml0eSBhbHRob3VnaCBpdCBvZnRlbiByZWNvZ25pemVzIHRo ZSBuZWNlc3NpdHkgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IGFzIGxvbmcgYXMgaXTigJlz IG5vdCB0byBhIGtub3duIGluc2VjdXJlIG1lY2hhbmlzbS4gIA0KPiANCj4gSSByZWFsbHkgdGhp bmsgdGhpcyBpcyBhIOKAnHN0ZXAgdXAgdG8gdGhlIGJhcuKAnSB0aGluZy4gIFdl4oCZdmUgc3Bl bnQgbG90cyBvZiB0aW1lIGFuZCBjeWNsZXMgaW1wbGVtZW50aW5nIHRoaW5ncyB0aGF0IHR1cm4g b3V0IG5vdCB0byBiZSBzZWN1cmUgZW5vdWdoLCBhbmQgd2UgaGF2ZSB0byBtb3ZlIGZvcndhcmQg b24gdGhpbmdzIHRoYXQgYXJlLiAgRFRMUy1TUlRQIGlzIG9uZSBvZiB0aG9zZSB0aGluZ3MsIGFz IGlzIElQdjYuDQo+IA0KPiBCcmlhbg0KPiANCj4gDQo+PiBPbiBBdWcgMzAsIDIwMjEsIGF0IDU6 MDYgUE0sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4+IA0K Pj4gQ2hhZCwNCj4+IA0KPj4gV2VsY29tZSB0byB0aGUgUlVNIFdHIQ0KPj4gDQo+PiBPbiA4LzMw LzIxIDExOjUxIEFNLCBDaGFkIExlZXBlciB3cm90ZToNCj4+PiAtIFdoaWxlIFdlYlJUQyB3LyBT UlRQL0RUTFMgKGVuY3J5cHRpb24pIGlzIGFuIGV4Y2VsbGVudCBpZGVhIGdvaW5nIGZvcndhcmQs IGl0IGNhbid0IGJlIGEgIk1VU1QiIHJlcXVpcmVtZW50LiAgSSBhZ3JlZSB3aXRoIFJvZ2VyIFNs dXNzZXIgdGhhdCBtYW5kYXRpbmcgY29tcGxpYW5jZSB1c2luZyBNVVNUIHJlcXVpcmVzIHByb3Zp ZGVycyB0byBpbXBsZW1lbnQgc2lnbmlmaWNhbnQgZGV2ZWxvcG1lbnQgdG8gY2hhbmdlIG92ZXIg dG8gd2hhdCBSVU0gaXMgc3BlY2lmeWluZy4NCj4+IA0KPj4gVGhlIHJlcXVpcmVtZW50cyBpbiB0 aGlzIGRvYyB3aWxsIGFwcGx5IG9ubHkgdG8gZGV2aWNlcyB0aGF0IGNsYWltIHRvIA0KPj4gY29u Zm9ybSB0byBpdC4gUHJlc3VtYWJseSB5b3UgY291bGQgY29udGludWUgdG8gc3VwcG9ydCB5b3Vy IGV4aXN0aW5nIA0KPj4gZGV2aWNlcyB1c2luZyB3aGF0ZXZlciBtZWNoYW5pc21zIHRoZXkgY3Vy cmVudGx5IHVzZS4gU28gdGhlIA0KPj4gaW1wbGVtZW50YXRpb24gYnVyZGVuIGlzIG9ubHkgb24g dGhlIHNlcnZlciBzaWRlLCBub3QgdGhlIGxlZ2FjeSANCj4+IGRldmljZSBzaWRlLiAoT2YgY291 cnNlIHRoZSBGQ0Mgd2lsbCBoYXZlIGEgc2F5IGluIHRoaXMuKQ0KPj4gDQo+PiBPbmUgbW90aXZh dGlvbiBmb3IgdGhlIHdlYnJ0YyByZXF1aXJlbWVudCBpcyBzbyB0aGF0IGEgUlVFIGNhbiBiZSAN Cj4+IGJ1aWx0IG9uIHRvcCBvZiBXZWJSVEMuIEUuZy4sIGl0IGNhbiBiZSBhIHNlcnZlciB0aGF0 IHN1cHBvcnRzIGRlYWYgDQo+PiB1c2VycyB1c2luZyBhbnkgZGV2aWNlIHdpdGggYSBicm93c2Vy LiBTdWNoIGEgc2VydmVyIGlzIGVmZmVjdGl2ZWx5IA0KPj4ganVzdCBzaWduYWxpbmcgZ2F0ZXdh eSB0aGF0IGNhbiBlc3RhYmxpc2ggYSBwMnAgbGluayBiZXR3ZWVuIHRoZSANCj4+IGJyb3dzZXIg YW5kIHRoZSBWUlMgcHJvdmlkZXIgc2VydmVyLiAoSXQgZG9lcyBoYXZlIHRvIHRyYW5zY29kZSBS VFQsIA0KPj4gYnV0IHRoYXQgaXMgbGVzcyBvZiBhIGJ1cmRlbi4pDQo+PiANCj4+IFdoZW4gZGVm aW5pbmcgYSBzcGVjaWZpY2F0aW9uIGZvciBhbiBpbnRlcmZhY2UgdGhhdCBpcyB0byBiZSBpbXBs ZW1lbnRlZCBieSBpbmRlcGVuZGVudCBwYXJ0aWVzIGl0IGlzIG5lY2Vzc2FyeSBmb3IgZXNzZW50 aWFsIGZ1bmN0aW9ucyB0byBoYXZlIGF0IGxlYXN0IG9uZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50 IG1lY2hhbmlzbS4gQ3VycmVudGx5IHRoZXJlIGFyZSBubyBzdGFuZGFyZHMgZm9yIGNvbm5lY3Rp bmcgYSBSVUUgdG8gYSBwcm92aWRlciwgc28gd2UgbmVlZCB0byBwaWNrICpzb21ldGhpbmcqIHRv IGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQuIElmIHlvdSBoYXZlIGFuIGFsdGVybmF0aXZlIGZv ciB0aGUgbWVkaWEgeW91IHdvdWxkIHByZWZlciwgdGhlbiBwbGVhc2UgbWFrZSBhIHNwZWNpZmlj IHByb3Bvc2FsLg0KPj4gDQo+Pj4gLSBXZSBzaG91bGQga2VlcCBhbnkgbmV3IHByaXZhY3kgcmVx dWlyZW1lbnRzIHZlcnkgbWluaW1hbCBhdCB0aGlzIHRpbWUuICBXaGlsZSBjb21wYW5pZXMgaW4g dGhlIEVVIGhhdmUgYWxyZWFkeSBjcmVhdGVkIHRoZWlyIHN5c3RlbXMgaW4gY29tcGxpYW5jZSB3 aXRoIHRoZSBHRFBSLCBtb3N0IG9mIHRoZSB3b3JsZCBoYXNuJ3QgY3JlYXRlZCBhbiBlcXVpdmFs ZW50IHlldC4gIFNvIHdoYXQgbWF5IGxvb2sgbGlrZSBhbiBlYXN5IGNoYW5nZSB0byBFVSBpbXBs ZW1lbnRlcnMgbWF5IGJlIGEgZHJhbWF0aWMgY2hhbmdlIGZvciBvdGhlcnMuDQo+PiANCj4+IEkg ZG9uJ3QgdGhpbmsgd2UgaGF2ZSBzYWlkIG11Y2ggYWJvdXQgcHJpdmFjeSBvZiByZXRhaW5lZCBk YXRhLiBCdXQgd2UgYXJlIGNvbmNlcm5lZCB0aGF0IHRoZSBtZWRpYSBhbmQgc2lnbmFsaW5nIGJl IHByaXZhdGUgYmV0d2VlbiB0aGUgUlVFIGFuZCB0aGUgcHJvdmlkZXIuIFRoYXQgaXMgYSBsb3cg YmFyIHRoZXNlIGRheXMuIEl0IGlzIHVubGlrZWx5IHRoYXQgYW55dGhpbmcgbGVzcyBjb3VsZCBi ZSBhcHByb3ZlZC4gSSBleHBlY3QgdGhlIEZDQyB3aWxsIGFncmVlLg0KPj4gDQo+PiBJZiB5b3Ug aGF2ZSBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgdGhhdCBhY2hpZXZlcyB0aGF0IHRoZW4gbWFrZSBh IHByb3Bvc2FsIHdlIGNhbiBkaXNjdXNzLg0KPj4gDQo+PiAJVGhhbmtzLA0KPj4gCVBhdWwNCj4+ IA0KPj4+IE9uIEZyaSwgQXVnIDI3LCAyMDIxIGF0IDM6MTYgUE0gUGF1bCBLeXppdmF0IDxwa3l6 aXZhdEBhbHVtLm1pdC5lZHUgPG1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToN Cj4+PiAgIFByb3ZpZGVycywNCj4+PiAgIE15IHJlcXVlc3QgYmVsb3cgdG8gUm9nZXIgc2hvdWxk IGhhdmUgYmVlbiBicm9hZGVyLiBZb3UgYWxsIHNlZW0gdG8NCj4+PiAgIGhhdmUNCj4+PiAgIHRo ZSBzYW1lIGlzc3VlLiBJIGVuY291cmFnZSBhbnkvYWxsIG9mIHlvdSB0byBtYWtlIGFuIGFsdGVy bmF0aXZlDQo+Pj4gICBwcm9wb3NhbCBoZXJlLiBKdXN0IHNheWluZyAid2UgZG9uJ3QgbGlrZSB3 aGF0IGlzIHRoZXJlIiBpc24ndCBoZWxwZnVsDQo+Pj4gICB3aXRob3V0IGFuIGFsdGVybmF0aXZl Lg0KPj4+ICAgICAgICAgICAgVGhhbmtzLA0KPj4+ICAgICAgICAgICAgUGF1bA0KPj4+ICAgT24g OC8yNi8yMSA1OjQwIFBNLCBQYXVsIEt5eml2YXQgd3JvdGU6DQo+Pj4+IFJvZ2VyLA0KPj4+PiAN Cj4+Pj4gT24gOC8yNi8yMSAzOjMwIFBNLCBSb2dlciBTbHVzc2VyIHdyb3RlOg0KPj4+PiANCj4+ Pj4+IE1vc3QgcHJvdmlkZXJzIGFscmVhZHkgc3VwcG9ydCBlbmNyeXB0aW9uIGFuZCBJUFY2IG9u IGEgbGltaXRlZA0KPj4+ICAgc2NvcGUsDQo+Pj4+PiBub3QgbmVjZXNzYXJpbHkgdGhlIHdheSBp dCBpcyBkZWZpbmVkIGluIFJVTSBzcGVjLiBNYW5kYXRpbmcgDQo+Pj4+PiBjb21wbGlhbmNlIHVz aW5nIE1VU1QgcmVxdWlyZXMgcHJvdmlkZXJzIHRvIGRpc2NhcmQgc29tZXRpbWVzIGh1Z2UgDQo+ Pj4+PiBhbW91bnRzIG9mIGRldmVsb3BtZW50IHRvIGNoYW5nZSBvdmVyIHRvIHdoYXQgUlVNIGlz IHNwZWNpZnlpbmcuDQo+Pj4gICBUaGUNCj4+Pj4+IHB1c2ggYmFjayBpcyBub3QgYWJvdXQgZG9p bmcgdGhlc2UgdGhpbmdzIGl0IGlzIGFib3V0IHRoZSBsb3NzIG9mIA0KPj4+Pj4gdGltZSwgZWZm b3J0IGFuZCBtb25leSB0byBkbyB0aGVtIGluIHRoZSB3YXkgUlVNIG1hbmRhdGVzIHdpdGgNCj4+ PiAgIE1VU1RzLg0KPj4+PiANCj4+Pj4gRG8geW91IHRoaW5rIHRoZXJlIGlzIHNvbWV0aGluZyBl bHNlIHdlIGNvdWxkIHdyaXRlIGluIHRoaXMgc3BlYw0KPj4+ICAgdGhhdA0KPj4+PiBjb3ZlcnMg ZW5jcnlwdGlvbiBhbmQgSVB2NiBpbiBhIHdheSB0aGF0IGlzIGxlc3MgYnVyZGVuc29tZSBmb3Ig DQo+Pj4+IHByb3ZpZGVycyB3aGlsZSByZW1haW5pbmcgaW50ZXJvcGVyYWJsZSB3aXRoIGFsbCBw cm92aWRlcnM/DQo+Pj4+IA0KPj4+PiBJZiBzbywgY2FuIHlvdSBwbGVhc2Ugc3BlbGwgaXQgb3V0 Pw0KPj4+ICAgLS0gICAgIFJ1bSBtYWlsaW5nIGxpc3QNCj4+PiAgIFJ1bUBpZXRmLm9yZyA8bWFp bHRvOlJ1bUBpZXRmLm9yZz4NCj4+PiAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcnVtDQo+Pj4gICA8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9y dW0+DQo+PiANCj4+IC0tDQo+PiBSdW0gbWFpbGluZyBsaXN0DQo+PiBSdW1AaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQo+IA0KPiAtLQ0KPiBS dW0gbWFpbGluZyBsaXN0DQo+IFJ1bUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J1bQ0KPiAtLQ0KPiBSdW0gbWFpbGluZyBsaXN0DQo+IFJ1bUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bQ0KDQo= From nobody Tue Aug 31 05:30:31 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F8BD3A08DB for ; Tue, 31 Aug 2021 05:30:26 -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 2g8lEkzrG09j for ; Tue, 31 Aug 2021 05:30:19 -0700 (PDT) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (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 250B93A124B for ; Tue, 31 Aug 2021 05:30:19 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id a13so24416743iol.5 for ; Tue, 31 Aug 2021 05:30:19 -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=FJYb453ijh0bkU4/4TcE5P+gmiGpwtfZmkmTjMakoOo=; b=dLj5DSJgMuaAdwAyGdBjlQKDDnAeXPytA7PT/utacvPRRMBcsnE3Suu5lAfYHFyuI6 DniAGcCwbqMCd4r3UfXgh8Fl670G6JPmHp4UiYcwE52aTtDVtsIIXZNhyH67BkZcIn7d w+dPQ6Nwpwaxu8kT33pTjtfqA/pwKFARt17d8F+gd+6wbj1RfWq1OB4oSfgEbA5MHvnW cMI8+btYWe77Ok4Xb4FRZE6550TUXj2sveZt1FyEZAwD1K3fhQIVDaE9mVddh+cvQaaw jrGwsxngwPDt4eTRutmpucQkZGIOELMpmjlqGS/Tj2rQ/DNTiEcP94PWL5DsNnad947M PXrw== 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=FJYb453ijh0bkU4/4TcE5P+gmiGpwtfZmkmTjMakoOo=; b=lj/IyDCE4gXmjReVix5fB952WX27T6g7m4YZCX/pNr9z9q1YZTr1De9ZoffL96CeGo I6Z0ADhC4fO6ODGaD10l9g6erVTx145K8OfPCkXHKE16howSOK47vi9IkaHyLYP22d/P 6ATS9s+3wKVnujcWRgiM/91Qnka2qcaQvLp7EyAg4H6GyceTZKKyghexl7bI0lH4R89y AOYZrtK6o1hkjH7Yyujer2qS/td0OZF1DN4WlSgkxiQdX8wd6C1oYrwjsc4JBf3sYVhe /exLZ6J7geWxNtpfeHnBP2WBVlVEZlIyK3Fn54OfsWfHXNSIJnaB+IRJ+Qyov8ubLGqE RYgQ== X-Gm-Message-State: AOAM533cTnnyvuu9fMwr/RtOqLmnjpNmXrQXUJaFfGtRyOjN6lCQ8sKT wM7x/tBYyV88GPyuo5YeZN/YpxkPpJKCqvtN X-Google-Smtp-Source: ABdhPJy9vZOr0/nt1Y2gilyIj/1TLvzvuBSRklNwYcb/XxZQPM9Kk7+OIiuOc+80DtvbtKICo9cA3w== X-Received: by 2002:a5d:9e49:: with SMTP id i9mr22533334ioi.125.1630413018459; Tue, 31 Aug 2021 05:30:18 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id l15sm9567715iow.4.2021.08.31.05.30.17 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 05:30:17 -0700 (PDT) From: Brian Rosen Message-Id: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_F3CEBF81-5B11-48F0-A421-8A3F7AE238B2" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 08:30:16 -0400 In-Reply-To: Cc: "Olle E. Johansson" , Paul Kyzivat , "rum@ietf.org" To: Ed Sayers References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 12:30:27 -0000 --Apple-Mail=_F3CEBF81-5B11-48F0-A421-8A3F7AE238B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Are you proposing this in addition to requiring DTLS-STRP or instead of = it? Would two users doing point to point calling through typical providers = that anchor media reliably get a secure connection hop-by-hop if both = users and both providers had conforming implementations and the = providers implemented the new inter-provider spec? User 1 Provider 1 Provider 2 User 2 DTLS- DTLS=3D DTLS- SRTP SRTP SRTP =20 > On Aug 31, 2021, at 6:30 AM, Ed Sayers wrote: >=20 > Hi, >=20 > Inline below.. >=20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com >=20 > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Olle E. Johansson >=20 > Sent: 31 August 2021 11:12 > To: Ed Sayers > > Cc: Brian Rosen >; Paul = Kyzivat >; = rum@ietf.org > Subject: Re: [Rum] encryption >=20 >=20 >=20 >> On 31 Aug 2021, at 11:29, Ed Sayers wrote: >>=20 >> Hi, >>=20 >> Thought I'd split out IPv6 and encryption as separate points.. >>=20 >> For encryption, the US VRS Providers recently created a new Provider = Inter-Operability Profile that now specifically allows for encryption = and ICE, amongst other things. >>=20 >> Whilst we all agreed that SRTP-DTLS is the right way to go, we = decided to specifically adopt RFC-8643 OSRTP, because this allows for = the greatest flexibility and greatest chance of supporting end-to-end = encryption, while still supporting a heterogenous range of devices. >=20 >=20 > OSRTP supports SRTP-DTLS. It=E2=80=99s not an alternative. And it=E2=80=99= s just an informational RFC, not a standards RFC.You still have to = implement SRTP-DTLS so you can use that fully in a situation where all = devices has support. >=20 > EdS - We know it is not an alternative. It simply revert the profile = to RTP/AVP, while keeping the fingerprint and setup attributes. This = means that an endpoint that sees the attributes can replay likewise and = agree SRTP-DTLS. Old endpoints ignore the attributes and can still = answer the call. >=20 > There are other ways to construct the SDP if you want to offer both = RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so one = need serious consideration. >=20 > EdS - Typically, older endpoints also would not support this, which is = the benefit of OSRTP - It is backwardly compatible. >=20 >>=20 >> Whilst it is true that encryption could be terminated on the RUE=20 >> interface proxy, >=20 > Aren=E2=80=99t you mixing signalling and media now? >=20 > EdS - I am missing what you mean here. >=20 >> any Provider that wants to allow encryption further into their = Infrastructure is generally faced with the potential need to fork calls = to various devices, possibly only some of which support encryption. = Using RFC-5673 alone would mean that older devices that do not support = encryption would reject the call as unsupported. >=20 > Isn=E2=80=99t that one of the benefits? A user needs to be assured = that the call is protected. As a provider you may need to have gateways = to the old world if you need that, but still keep the first call leg = encrypted at all times. >=20 > EdS - =46rom a customer standpoint, having a range of devices no = longer ring is not a benefit. Using OSRTP as a migration path to support = end-to-end encryption while older devices can be gradually 'aged out'. > The user might otherwise have an illusion of security - terminated at = the RUM proxy, while the endpoint on the other end is not encrypted = (because it cannot support it). >=20 >>=20 >> Using OSRTP is by far the simplest and most convenient way to fork = the call and still ensure that the widest range of endpoints can ring. >=20 > But it doesn=E2=80=99t deliver any guarantee of any kind to the user. >=20 > EdS - It provides a progression where more and more endpoints over = time can be encrypted. Precisely why we adopted it on the Inter-Provider = interface. >=20 >=20 > /O >>=20 >> Cheers, >>=20 >>=20 >> Ed Sayers >> Endpoint SDK Team Lead >> Purple, a Division of ZP Better Together, LLC purplevrs.com >>=20 >> The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Rum On Behalf Of Brian Rosen >> Sent: 30 August 2021 22:24 >> To: Paul Kyzivat >> Cc: Chad Leeper ; rum@ietf.org >> Subject: Re: [Rum] IPv6 and encryption >>=20 >> I don=E2=80=99t think there are ANY alternatives to SRTP. There are = alternatives to DTLS-SRTP. There are moves within the IETF to deprecate = SDES, specifically. There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. Since all = providers I know about anchor media, this only affects the initial hop. = Users really want to hear that their media is protected end to end (at = least hop by hop) but our document doesn=E2=80=99t require that. Again, = we need a STANDARDS based solution, and we have to live within the = constraints the IETF has for new standards with respect to security. = Like nearly every organization, the IETF is much more security conscious = than it was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism. =20 >>=20 >> I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. = We=E2=80=99ve spent lots of time and cycles implementing things that = turn out not to be secure enough, and we have to move forward on things = that are. DTLS-SRTP is one of those things, as is IPv6. >>=20 >> Brian >>=20 >>=20 >>> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat = wrote: >>>=20 >>> Chad, >>>=20 >>> Welcome to the RUM WG! >>>=20 >>> On 8/30/21 11:51 AM, Chad Leeper wrote: >>>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going = forward, it can't be a "MUST" requirement. I agree with Roger Slusser = that mandating compliance using MUST requires providers to implement = significant development to change over to what RUM is specifying. >>>=20 >>> The requirements in this doc will apply only to devices that claim = to=20 >>> conform to it. Presumably you could continue to support your = existing=20 >>> devices using whatever mechanisms they currently use. So the=20 >>> implementation burden is only on the server side, not the legacy=20 >>> device side. (Of course the FCC will have a say in this.) >>>=20 >>> One motivation for the webrtc requirement is so that a RUE can be=20 >>> built on top of WebRTC. E.g., it can be a server that supports deaf=20= >>> users using any device with a browser. Such a server is effectively=20= >>> just signaling gateway that can establish a p2p link between the=20 >>> browser and the VRS provider server. (It does have to transcode RTT,=20= >>> but that is less of a burden.) >>>=20 >>> When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal. >>>=20 >>>> - We should keep any new privacy requirements very minimal at this = time. While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet. So what may look like an easy change to EU implementers may be a = dramatic change for others. >>>=20 >>> I don't think we have said much about privacy of retained data. But = we are concerned that the media and signaling be private between the RUE = and the provider. That is a low bar these days. It is unlikely that = anything less could be approved. I expect the FCC will agree. >>>=20 >>> If you have an alternate proposal that achieves that then make a = proposal we can discuss. >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > wrote: >>>> Providers, >>>> My request below to Roger should have been broader. You all seem = to >>>> have >>>> the same issue. I encourage any/all of you to make an alternative >>>> proposal here. Just saying "we don't like what is there" isn't = helpful >>>> without an alternative. >>>> Thanks, >>>> Paul >>>> On 8/26/21 5:40 PM, Paul Kyzivat wrote: >>>>> Roger, >>>>>=20 >>>>> On 8/26/21 3:30 PM, Roger Slusser wrote: >>>>>=20 >>>>>> Most providers already support encryption and IPV6 on a limited >>>> scope, >>>>>> not necessarily the way it is defined in RUM spec. Mandating=20 >>>>>> compliance using MUST requires providers to discard sometimes = huge=20 >>>>>> amounts of development to change over to what RUM is specifying. >>>> The >>>>>> push back is not about doing these things it is about the loss of=20= >>>>>> time, effort and money to do them in the way RUM mandates with >>>> MUSTs. >>>>>=20 >>>>> Do you think there is something else we could write in this spec >>>> that >>>>> covers encryption and IPv6 in a way that is less burdensome for=20 >>>>> providers while remaining interoperable with all providers? >>>>>=20 >>>>> If so, can you please spell it out? >>>> -- Rum mailing list >>>> Rum@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rum >>>> >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >>=20 >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum --Apple-Mail=_F3CEBF81-5B11-48F0-A421-8A3F7AE238B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Are = you proposing this in addition to requiring DTLS-STRP or instead of = it?

Would two users = doing point to point calling through typical providers that anchor media = reliably get a secure connection hop-by-hop if both users and both = providers had conforming implementations and the providers implemented = the new inter-provider spec?

User 1   Provider 1     Provider 2   =   User 2
     DTLS-         DTLS=3D =          DTLS-
     SRTP     =      SRTP           SRTP   =    

On Aug 31, 2021, at 6:30 AM, Ed = Sayers <ed.sayers@purple.us> wrote:

Hi,

Inline below..


Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information contained in = this e-mail message is intended only for the personal and confidential = use of the recipient(s) named above. If you have received this = communication in error, please notify us immediately by e-mail, and = delete the original message.




-----Original Message-----
From: Olle E. Johansson <oej@edvina.net> 
Sent: 31 August 2021 = 11:12
To: Ed Sayers = <ed.sayers@purple.us>
Cc: Brian Rosen <br@brianrosen.net>; Paul Kyzivat <pkyzivat@alum.mit.edu>; rum@ietf.org
Subject: Re: [Rum] = encryption



On 31 = Aug 2021, at 11:29, Ed Sayers <ed.sayers@purple.us> wrote:

Hi,

Thought I'd split out IPv6 = and encryption as separate points..

For = encryption, the US VRS Providers recently created a new Provider = Inter-Operability Profile that now specifically allows for encryption = and ICE, amongst other things.

Whilst we = all agreed that SRTP-DTLS is the right way to go, we decided to = specifically adopt RFC-8643 OSRTP, because this allows for the greatest = flexibility and greatest chance of supporting end-to-end encryption, = while still supporting a heterogenous range of devices.


OSRTP supports SRTP-DTLS. It=E2=80=99s not an alternative. = And it=E2=80=99s just an informational RFC, not a standards RFC.You = still have to implement SRTP-DTLS so you can use that fully in a = situation where all devices has support.

EdS - We know it is not an alternative. It simply revert the = profile to RTP/AVP, while keeping the fingerprint and setup attributes. = This means that an endpoint that sees the attributes can replay likewise = and agree SRTP-DTLS. Old endpoints ignore the attributes and can still = answer the call.

There are other ways to construct the SDP if you want to = offer both RTP/SAVP and RTP/AVP, but that opens up for downgrade = attacks, so one need serious consideration.

EdS - Typically, older endpoints = also would not support this, which is the benefit of OSRTP - It is = backwardly compatible.


Whilst it is true that = encryption could be terminated on the RUE 
interface = proxy,

Aren=E2=80=99t you mixing signalling and media now?

EdS - I am missing what you mean = here.

any = Provider that wants to allow encryption further into their = Infrastructure is generally faced with the potential need to fork calls = to various devices, possibly only some of which support encryption. = Using RFC-5673 alone would mean that older devices that do not support = encryption would reject the call as unsupported.

Isn=E2=80=99t that one of the benefits? A user needs to be = assured that the call is protected. As a provider you may need to have = gateways to the old world if you need that, but still keep the first = call leg encrypted at all times.

EdS - =46rom a customer standpoint, having a range of devices = no longer ring is not a benefit. Using OSRTP as a migration path to = support end-to-end encryption while older devices can be gradually 'aged = out'.
The user = might otherwise have an illusion of security - terminated at the RUM = proxy, while the endpoint on the other end is not encrypted (because it = cannot support it).


Using OSRTP is by far = the simplest and most convenient way to fork the call and still ensure = that the widest range of endpoints can ring.

But it doesn=E2=80=99t deliver any guarantee of any kind to = the user.

EdS - It = provides a progression where more and more endpoints over time can be = encrypted. Precisely why we adopted it on the Inter-Provider = interface.


/O

Cheers,


Ed = Sayers
Endpoint SDK Team Lead
Purple, a = Division of ZP Better Together, LLC purplevrs.com

The = information contained in this e-mail message is intended only for the = personal and confidential use of the recipient(s) named above. If you = have received this communication in error, please notify us immediately = by e-mail, and delete the original message.




-----Original = Message-----
From: Rum <rum-bounces@ietf.org> On Behalf Of Brian Rosen
Sent: 30 August 2021 22:24
To: Paul Kyzivat = <pkyzivat@alum.mit.edu>
Cc: Chad Leeper = <chad.leeper@convorelay.com>; rum@ietf.org
Subject: Re: [Rum] IPv6 and encryption

I don=E2=80=99t think there are ANY alternatives to SRTP. =  There are alternatives to DTLS-SRTP.  There are moves within = the IETF to deprecate SDES, specifically.  There is push back on = that, but it=E2=80=99s an ongoing discussion because SDES isn=E2=80=99t = secure enough.   Since all providers I know about anchor = media, this only affects the initial hop.  Users really want to = hear that their media is protected end to end (at least hop by hop) but = our document doesn=E2=80=99t require that.  Again, we need a = STANDARDS based solution, and we have to live within the constraints the = IETF has for new standards with respect to security.  Like nearly = every organization, the IETF is much more security conscious than it = was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism.  

I= really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. =  We=E2=80=99ve spent lots of time and cycles implementing things = that turn out not to be secure enough, and we have to move forward on = things that are.  DTLS-SRTP is one of those things, as is IPv6.

Brian


On Aug 30, 2021, at 5:06 = PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Chad,

Welcome to the RUM WG!

On 8/30/21 11:51 AM, Chad Leeper wrote:
- While WebRTC w/ = SRTP/DTLS (encryption) is an excellent idea going forward, it can't be a = "MUST" requirement. I agree with Roger Slusser that mandating compliance = using MUST requires providers to implement significant development to = change over to what RUM is specifying.

The requirements in this doc will apply only to devices that = claim to 
conform to it. Presumably you could continue to support your = existing 
devices using whatever mechanisms they currently use. So = the 
implementation burden is only on the server side, not the = legacy 
device side. (Of course the FCC will have a say in this.)

One motivation for the webrtc requirement is = so that a RUE can be built on top of WebRTC. E.g., it can be a server that = supports deaf 
users using any device with a browser. Such a server is = effectively 
just signaling gateway that can establish a p2p link between = the 
browser and the VRS provider server. (It does have to = transcode RTT, 
but that is less of a burden.)

When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal.

- We should keep any new privacy requirements very minimal at = this time.  While companies in the EU have already created their = systems in compliance with the GDPR, most of the world hasn't created an = equivalent yet.  So what may look like an easy change to EU = implementers may be a dramatic change for others.

I don't think we have said much = about privacy of retained data. But we are concerned that the media and = signaling be private between the RUE and the provider. That is a low bar = these days. It is unlikely that anything less could be approved. I = expect the FCC will agree.

If you have an = alternate proposal that achieves that then make a proposal we can = discuss.

Thanks,
Paul

On Fri, = Aug 27, 2021 at 3:16 PM Paul Kyzivat <pkyzivat@alum.mit.edu= <mailto:pkyzivat@alum.mit.edu>> wrote:
 Providers,
 My request below to = Roger should have been broader. You all seem to
 have
 the same issue. I encourage = any/all of you to make an alternative
 proposal here. = Just saying "we don't like what is there" isn't helpful
 without an alternative.
          Tha= nks,
          Pau= l
 On 8/26/21 5:40 PM, Paul Kyzivat wrote:
Roger,

On 8/26/21 3:30 PM, Roger Slusser wrote:

Most providers already = support encryption and IPV6 on a limited
 scope,
not necessarily the way it is defined in RUM spec. = Mandating 
compliance using MUST requires providers to discard sometimes = huge 
amounts of development to change over to what RUM is = specifying.
 The
push back is not about doing these things it is about the = loss of 
time, effort and money to do them in the way RUM mandates = with
 MUSTs.

Do you = think there is something else we could write in this spec
 that
covers encryption and IPv6 in a way that is less burdensome = for 
providers while remaining interoperable with all = providers?

If so, can you please spell it = out?
 --     Rum = mailing list
 Rum@ietf.org <mailto:Rum@ietf.org>
 https://www.ietf.org/mailman/listinfo/rum
 <https://www.ietf.org/mailman/listinfo/rum>

--
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_F3CEBF81-5B11-48F0-A421-8A3F7AE238B2-- From nobody Tue Aug 31 06:06:28 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 413393A1404 for ; Tue, 31 Aug 2021 06:06:26 -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 (1024-bit key) header.d=purplenetwork.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GZ-M6OGDwMI8 for ; Tue, 31 Aug 2021 06:06:19 -0700 (PDT) Received: from stmail1.purple.us (stmail1.purple.us [54.177.253.121]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4F83A0ED3 for ; Tue, 31 Aug 2021 06:06:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by stmail1.purple.us (Postfix) with ESMTP id 786A2192559; Tue, 31 Aug 2021 08:06:30 -0500 (CDT) Authentication-Results: stmail1.purple.us; dkim=pass (1024-bit rsa key sha256) header.d=purplenetwork.onmicrosoft.com header.i=@purplenetwork.onmicrosoft.com header.b=JjUXfI4M header.a=rsa-sha256 header.s=selector2-PurpleNetwork-onmicrosoft-com x-bits=1024; x-trusted-ip=pass Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by stmail1.purple.us (Postfix) with ESMTPS id 1A675192553; Tue, 31 Aug 2021 08:06:30 -0500 (CDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eq+Uo1JATpwRj+DVyoYpNudFLIGwPy6hwxv7K2X6LXEllijsw0CokKYi6gJIgmFpLHbVZb8QKNsjNnx37PuMIQoEnALCQtorNd145VoU3DTW5Tom0yZFgB38Wb0Q52mz8XyQW+CBS026dEZaGYLbN+AmvWp+JSbSDRwuLHs4558H7u8wQX6FDmnPC+mLBrkYtnf3Mdl4psEPL4c++B/UfRb2cJKa5fQK/sCXu9WMy2mQTRXJLfKulUjVx/R5Om4m33stxVprDAk7u33pyz/TBA/+LAmLZ6K3QxNM52CjlI+2Ql7acK6kkduavZsaaTjIZNLE/LPm+utD+Wbu6p4J7g== 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=7oLElLXFmvT7XYy1Nh7WoPYOjF2ramFhpmcLg8V6XrU=; b=EzdE2aKeR6+7KytvWfY9lwcspmXRs3ACieR3J2u5IQGLbe/5Y+sky6FYUUvVu1awayTc7AScQ330Fbt8293IG0TWftZUirCa93ozmkqpvNYo6pRQCLWfTx5cYQRk8czuVspFmD8V0/k5nDE2RMc3i6tb99jI/6/TRV/hyv9n4+cfyNYmUiDhwwM0mkwTCgA9lUWxSmCRTQ4AceJj3jXVYPrLk8nMdh2MYuLwVK4fSLftGMiPI8Rl0XfEWheYyoKKf/6uQ9HYuUhJQhy4eBAPMoCEB948hkxlXELE29uWJ0/ooxkgqMnVC0ySzDoKU8vZ6Clt0XnHAMug+ADMaWGcRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=purple.us; dmarc=pass action=none header.from=purple.us; dkim=pass header.d=purple.us; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=PurpleNetwork.onmicrosoft.com; s=selector2-PurpleNetwork-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7oLElLXFmvT7XYy1Nh7WoPYOjF2ramFhpmcLg8V6XrU=; b=JjUXfI4Mr/UiPueyoQVZPazz+NDqRgjTkn6pK9k462R77ALbKqeps/5pqHl2J/z66rSpz2lKVjmqL6znKKuwZIyg8zSphJJv7iKr34cDyZHTY8yaGkZ0g7HioDySyH/2udPYW2h/XpO5o6izmDOUXf6uJzo507CTfofeQcJ1ZvE= Received: from DM6PR19MB3930.namprd19.prod.outlook.com (2603:10b6:5:241::9) by DM6PR19MB3801.namprd19.prod.outlook.com (2603:10b6:5:22b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Tue, 31 Aug 2021 13:06:14 +0000 Received: from DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b]) by DM6PR19MB3930.namprd19.prod.outlook.com ([fe80::b868:13d2:5289:cf4b%9]) with mapi id 15.20.4457.024; Tue, 31 Aug 2021 13:06:14 +0000 From: Ed Sayers To: Brian Rosen CC: "Olle E. Johansson" , Paul Kyzivat , "rum@ietf.org" Thread-Topic: [Rum] encryption Thread-Index: AdeeR7wCxTV6yTDtS7ecSm7HwjQ0zQACOBuAAABKTTAABIuKAAAAY8Tw Date: Tue, 31 Aug 2021 13:06:14 +0000 Message-ID: References: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> In-Reply-To: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=purple.us; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df410abe-800c-49a2-4a51-08d96c801cc3 x-ms-traffictypediagnostic: DM6PR19MB3801: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ioEaRaM3TYTCBmGi9bj+r+SmGVpg4PGwh+d07YzDzls7q8EmnnC0PthIx4Mdii/Y+6oJA5bbW4HZAP0bPV8wz/yx9+0PHDtC18x/yUDoIZ7kUWQLwrBZancOq7ZHIPuogOrlX801ntscHWN6Z4xcO9Wpl3JrZ2ZPNaK5QVbzcZ8yUtZXbYhWhc9eooT3+hidZy9xsH1qdS2YdjHvXe+C/OvIbnmQvJbYLHP54tSWOkJvIq490XY+uR7h8KHYo69iA7Ied9ZAzdvZjN+MGqIxy0kbRllOAIJr9ldegKhsBBg87rgVcHBT+U1hyCa8sGaBzB5xmyyluZGbQctHNEhLRy2M6r1D9R5KDFp/nQL9r/iQpwB6cTbbb/VRAhlFJyODwGfrJz2v8LUylZ6HGzuaVptnor+MnIgznLQVdv6VaHYp0D1TdtNQQqxuKTRuSkqIpGNdxWw9zMPs0PrBm0nJB5teTCTKfTK+rI9LaCcgAQioUnLHn47k/ZLUMyznxLsb1L3z+dw0uqDZ/txi3gd7QcRheq5XjetxpQ0uD3AWxgUL+DPHlyPZ4/aT7Fb/NWPj6pobNq0IN58QAgpWW1UJbJH/flnsofhYiA/z0CrtuK/3xU+UQa4zVmkBe57b15R8rVC5NmFO0K/IDnhDUOHSaFoGTtoM6C2Zgo9rJiVkx+Iep6hf/Z6p1l5U0ibIdiliGqazrpz6jprt+oBtTRLcjO2ay40PMWRBWaO6YsceeZE8FlaAMaANJA7WdQHmFGPNXKU1tM5D07IV6oKjshbySDZ59DvBF+T/jdJjSnlgmAh00mnTA9yhkOHUwC1F64py x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR19MB3930.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(39850400004)(136003)(366004)(346002)(396003)(9326002)(166002)(33656002)(53546011)(9686003)(316002)(8936002)(186003)(7696005)(71200400001)(26005)(30864003)(76116006)(55236004)(99936003)(8676002)(5660300002)(54906003)(52536014)(44832011)(55016002)(66946007)(478600001)(4326008)(66446008)(66556008)(83380400001)(6916009)(64756008)(66616009)(66476007)(6506007)(38100700002)(966005)(38070700005)(2906002)(122000001)(86362001)(66574015)(80162008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eFoyS3M4aGlDbmpRZnluREFtK1QxQVNCc2F4QnpSWGJvL211QkI1Wk5pdG5W?= =?utf-8?B?eW1CQUlOZW5GY21paURtcktpUVlXejZ5dyt6UGFKSEFncDVuc2VzSjAxN1JZ?= =?utf-8?B?cVQ5V2h5YzNBUVI2emVzbE1wakJDeE1iWWlzQXhTb3cwb25lREExS1N6ZHhT?= =?utf-8?B?dGk2cTd6U2FTcFZUWGQ4cGRjYTdkaE5NMWc3eVlSNk1rTXZUUlJNVzB5MFpk?= =?utf-8?B?K01SSDFUNXd3QmpmdGJqL0syYkw2QXdycitMLzJjY2xrWUZMd2JPcDVYUllJ?= =?utf-8?B?emNuQ1V3MHJTMDhVeC9IL05nNkw2N1lFb2wxL09TVkUySHhkNEVKb2VLQnNj?= =?utf-8?B?NFdzaGpBVUlOZDVSaVIrdnJmUHBTQVJzZnJEQkZkeDFiWXZuVlNzNzVqWnRV?= =?utf-8?B?Q3laNmlRVVBOZjFNc09YL2dUN3YvOWlaS0VHTGxUdWNCbnY5cEM0dDEwcW5T?= =?utf-8?B?czFISi9ZZ0dtVXFUV2o4UkRZNjBCTjZNZW5odlBZZE1tUUxBOFJ6cWJ3REZH?= =?utf-8?B?VDNTUVJ5NmlQV2pXM0kzSjhvdE96alJqaXlZQ1VNdE9YTVA1OWQ3d1R6UVky?= =?utf-8?B?emNEYlhPYXYrSmhNTG0xQkhjWDZGQjc4T2NTbjdKZmNJbzY3c2JteWJmUnRE?= =?utf-8?B?Y0Y4ZU9vc3ZLU1gzWk9wNGdFYjZ1UGZOUkcyNjVZbFpMMURFOC9LbTV3a3ln?= =?utf-8?B?eDNUajk4aUNiOXVUZGVJNmVPazdCRmJtanFZREordFk3T3MvUWdlU21oWVdi?= =?utf-8?B?VlVRTlZzb1E4dlFLUEN1SXVkOG1lNGZNVTNiR3JXaUwwWnJLWGxxT00rSlJK?= =?utf-8?B?NEVvUXczKysxYUw1NVFPNUxjWG45MlJhNXphMFBkWHhUWFlvOGhvTFhOVjV1?= =?utf-8?B?Y1J4SmYvUjh1ekhlcERKRVVrWHUvd3k2WVBJK1Y3ZS9ydmlWRDNqK0FHdE10?= =?utf-8?B?enp3NEdRVXh3amhMOEFiTUV0Ujd6Wm56YW1ZMlBIbmMzNzY5VjJYQXFNN2hZ?= =?utf-8?B?NFN6N29yTVBDU2RMM3F2OXNXZTdzRGc1VEJGZDJrcklWbkNJYzRkZmJoT201?= =?utf-8?B?cWZMZHhmZnVFQUppVXl0SWI2aEREOUFQNlYxckFZY1NnLzdTTGlDa3VON3du?= =?utf-8?B?RGNYOGJoTFB3U3dIYVI5SVM3ZVNhNkVxK0h6Rmd0ZG80RE9QT2RudGwzOGk4?= =?utf-8?B?OUZDTWNSMkxvN1ZEbDk4NFZMemx4aytUQi8xWnRodHlSSWIzRjhsa0dQT2Ir?= =?utf-8?B?TjdldmZXcXl2QTkzYkU5SU9oM3FpRnNnYmdSVnNycTgyOVdNV1VReUdLUU5Q?= =?utf-8?B?UjJIVWVFVGhDK2s5Q1E4SkpZaWd1L3hRc0Y1cm42cTJkSVF4SzNQVHgyUUI5?= =?utf-8?B?S2k0YUdKNk5nK05CYXA4c2tzMzIyT0hoWVJ4VFRGTDB6cE4wRFA2YTExd0JK?= =?utf-8?B?bE5tU1pKc1BOYTRyTkFzUTdyaG1PNGdVdnlQSTNXVG9lZ0pZSzFPQitvMklH?= =?utf-8?B?U2lsT2g0SS90aE9KdTJQa3d0Y0RwNlQ2bXk0NFBpdWJIb0hrU3dvN3VpUWQz?= =?utf-8?B?eUFBc1NHQk1HSzdBb2NUMnJtSkczN1hYeE9KYlV4QlhPTkx4QmFCQ0I0UDRK?= =?utf-8?B?czhvUkNNK2Z5TW8zc1B6eFE0NW9jbHMzN2xJS0VGL2ZBYVcyU1JKUGtXWHgx?= =?utf-8?B?SUNlZTJmV2kzaysvZHFTaFp0TEZsbVdlMlR0akpuVi8yMUY2clBHZXpnbEpr?= =?utf-8?Q?NQCH4R3oTHk7QES6VqAaue2ge/r08REsB4Rdb+o?= x-ms-exchange-transport-forked: True Content-Type: multipart/related; boundary="_004_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: purple.us X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR19MB3930.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: df410abe-800c-49a2-4a51-08d96c801cc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2021 13:06:14.2436 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0041a4e6-62ee-427c-beeb-e6aa18257d91 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fJ9ShdB19qhZnk1lpJikUQW7nGNI1Klaezgt5USC/cFNefPa6IC3GaKiT/Rchm3+dRuB0l1mY2ItxytraQxllg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR19MB3801 Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 13:06:26 -0000 --_004_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_ Content-Type: multipart/alternative; boundary="_000_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_" --_000_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCkkgd291bGQgc2F5IHRoYXQgT1NSVFAgaXMgbW9yZSBhIHdheSBvZiBuZWdv dGlhdGluZyBTUlRQLiBJdCBhbGxvd3Mgb2xkZXIgZW5kcG9pbnRzIHRoYXQgY2Fu4oCZdC9kb27i gJl0IHN1cHBvcnQgZW5jcnlwdGlvbiB0byBzdGlsbCBwb3RlbnRpYWxseSBwYXJ0aWNpcGF0ZSBp biBhIGNhbGwuDQoNClllcywgdGhlIGludGVudGlvbiBvZiBhZGRpbmcgT1NSVFAgdG8gdGhlIHVw ZGF0ZWQgSW50ZXItUHJvdmlkZXIgc3BlY2lmaWNhdGlvbiB3YXMgdG8gYWxsb3cgdGhlIHBvc3Np YmlsaXR5IG9mIGVuZC10by1lbmQgU1JUUC1EVExTIGVuY3J5cHRpb24gYmV0d2VlbiB0aGUgZW5k cG9pbnRzIG9mIHR3byBkaWZmZXJlbnQgUHJvdmlkZXJzIG9uY2Ugc3VwcG9ydGVkIChvciBwYXNz ZWQgb24pIHdoZXJlIHBvc3NpYmxlLg0KDQpXZSB0aG91Z2h0IHRoaXMgdG8gYmUgdGhlIGJlc3Qg YmFsYW5jZSBiZXR3ZWVuIGFkZGluZyBidXJkZW5zb21lIGNvbXBsZXhpdHksIGNhbGxzIGZhaWxp bmcgb3V0LXJpZ2h0IG9yIHNvbWUgZGV2aWNlcyBub3QgcmluZ2luZywgd2hpbHN0IHN0aWxsIGFs bG93aW5nIGVuY3J5cHRpb24gd2hlbmV2ZXIgaXQgcG9zc2libHkgY291bGQgYmUuDQoNCkNoZWVy cywNCg0KDQpFZCBTYXllcnMNCkVuZHBvaW50IFNESyBUZWFtIExlYWQNClB1cnBsZSwgYSBEaXZp c2lvbiBvZiBaUCBCZXR0ZXIgVG9nZXRoZXIsIExMQw0KcHVycGxldnJzLmNvbTxodHRwczovL3B1 cnBsZXZycy5jb20vPg0KDQpbUHVycGxlIGlzIERFSSBjZXJ0aWZpZWQhXQ0KVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9y IHRoZSBwZXJzb25hbCBhbmQgY29uZmlkZW50aWFsIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpIG5h bWVkIGFib3ZlLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJy b3IsIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1tYWlsLCBhbmQgZGVsZXRlIHRo ZSBvcmlnaW5hbCBtZXNzYWdlLg0KDQoNCg0KDQpGcm9tOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5y b3Nlbi5uZXQ+DQpTZW50OiAzMSBBdWd1c3QgMjAyMSAxMzozMA0KVG86IEVkIFNheWVycyA8ZWQu c2F5ZXJzQHB1cnBsZS51cz4NCkNjOiBPbGxlIEUuIEpvaGFuc3NvbiA8b2VqQGVkdmluYS5uZXQ+ OyBQYXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdT47IHJ1bUBpZXRmLm9yZw0KU3Vi amVjdDogUmU6IFtSdW1dIGVuY3J5cHRpb24NCg0KQXJlIHlvdSBwcm9wb3NpbmcgdGhpcyBpbiBh ZGRpdGlvbiB0byByZXF1aXJpbmcgRFRMUy1TVFJQIG9yIGluc3RlYWQgb2YgaXQ/DQoNCldvdWxk IHR3byB1c2VycyBkb2luZyBwb2ludCB0byBwb2ludCBjYWxsaW5nIHRocm91Z2ggdHlwaWNhbCBw cm92aWRlcnMgdGhhdCBhbmNob3IgbWVkaWEgcmVsaWFibHkgZ2V0IGEgc2VjdXJlIGNvbm5lY3Rp b24gaG9wLWJ5LWhvcCBpZiBib3RoIHVzZXJzIGFuZCBib3RoIHByb3ZpZGVycyBoYWQgY29uZm9y bWluZyBpbXBsZW1lbnRhdGlvbnMgYW5kIHRoZSBwcm92aWRlcnMgaW1wbGVtZW50ZWQgdGhlIG5l dyBpbnRlci1wcm92aWRlciBzcGVjPw0KDQpVc2VyIDEgICBQcm92aWRlciAxICAgICBQcm92aWRl ciAyICAgICBVc2VyIDINCiAgICAgRFRMUy0gICAgICAgICBEVExTPSAgICAgICAgICBEVExTLQ0K ICAgICBTUlRQICAgICAgICAgIFNSVFAgICAgICAgICAgIFNSVFANCg0KDQpPbiBBdWcgMzEsIDIw MjEsIGF0IDY6MzAgQU0sIEVkIFNheWVycyA8ZWQuc2F5ZXJzQHB1cnBsZS51czxtYWlsdG86ZWQu c2F5ZXJzQHB1cnBsZS51cz4+IHdyb3RlOg0KDQpIaSwNCg0KSW5saW5lIGJlbG93Li4NCg0KDQpF ZCBTYXllcnMNCkVuZHBvaW50IFNESyBUZWFtIExlYWQNClB1cnBsZSwgYSBEaXZpc2lvbiBvZiBa UCBCZXR0ZXIgVG9nZXRoZXIsIExMQw0KcHVycGxldnJzLmNvbTxodHRwOi8vcHVycGxldnJzLmNv bS8+DQoNClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgbWVzc2FnZSBp cyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uYWwgYW5kIGNvbmZpZGVudGlhbCB1c2Ugb2Yg dGhlIHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBj b21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUt bWFpbCwgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg0KDQoNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE9sbGUgRS4gSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5l dDxtYWlsdG86b2VqQGVkdmluYS5uZXQ+Pg0KU2VudDogMzEgQXVndXN0IDIwMjEgMTE6MTINClRv OiBFZCBTYXllcnMgPGVkLnNheWVyc0BwdXJwbGUudXM8bWFpbHRvOmVkLnNheWVyc0BwdXJwbGUu dXM+Pg0KQ2M6IEJyaWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5y b3Nlbi5uZXQ+PjsgUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBr eXppdmF0QGFsdW0ubWl0LmVkdT4+OyBydW1AaWV0Zi5vcmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbUnVtXSBlbmNyeXB0aW9uDQoNCg0KDQoNCk9uIDMxIEF1ZyAyMDIxLCBh dCAxMToyOSwgRWQgU2F5ZXJzIDxlZC5zYXllcnNAcHVycGxlLnVzPG1haWx0bzplZC5zYXllcnNA cHVycGxlLnVzPj4gd3JvdGU6DQoNCkhpLA0KDQpUaG91Z2h0IEknZCBzcGxpdCBvdXQgSVB2NiBh bmQgZW5jcnlwdGlvbiBhcyBzZXBhcmF0ZSBwb2ludHMuLg0KDQpGb3IgZW5jcnlwdGlvbiwgdGhl IFVTIFZSUyBQcm92aWRlcnMgcmVjZW50bHkgY3JlYXRlZCBhIG5ldyBQcm92aWRlciBJbnRlci1P cGVyYWJpbGl0eSBQcm9maWxlIHRoYXQgbm93IHNwZWNpZmljYWxseSBhbGxvd3MgZm9yIGVuY3J5 cHRpb24gYW5kIElDRSwgYW1vbmdzdCBvdGhlciB0aGluZ3MuDQoNCldoaWxzdCB3ZSBhbGwgYWdy ZWVkIHRoYXQgU1JUUC1EVExTIGlzIHRoZSByaWdodCB3YXkgdG8gZ28sIHdlIGRlY2lkZWQgdG8g c3BlY2lmaWNhbGx5IGFkb3B0IFJGQy04NjQzIE9TUlRQLCBiZWNhdXNlIHRoaXMgYWxsb3dzIGZv ciB0aGUgZ3JlYXRlc3QgZmxleGliaWxpdHkgYW5kIGdyZWF0ZXN0IGNoYW5jZSBvZiBzdXBwb3J0 aW5nIGVuZC10by1lbmQgZW5jcnlwdGlvbiwgd2hpbGUgc3RpbGwgc3VwcG9ydGluZyBhIGhldGVy b2dlbm91cyByYW5nZSBvZiBkZXZpY2VzLg0KDQoNCk9TUlRQIHN1cHBvcnRzIFNSVFAtRFRMUy4g SXTigJlzIG5vdCBhbiBhbHRlcm5hdGl2ZS4gQW5kIGl04oCZcyBqdXN0IGFuIGluZm9ybWF0aW9u YWwgUkZDLCBub3QgYSBzdGFuZGFyZHMgUkZDLllvdSBzdGlsbCBoYXZlIHRvIGltcGxlbWVudCBT UlRQLURUTFMgc28geW91IGNhbiB1c2UgdGhhdCBmdWxseSBpbiBhIHNpdHVhdGlvbiB3aGVyZSBh bGwgZGV2aWNlcyBoYXMgc3VwcG9ydC4NCg0KRWRTIC0gV2Uga25vdyBpdCBpcyBub3QgYW4gYWx0 ZXJuYXRpdmUuIEl0IHNpbXBseSByZXZlcnQgdGhlIHByb2ZpbGUgdG8gUlRQL0FWUCwgd2hpbGUg a2VlcGluZyB0aGUgZmluZ2VycHJpbnQgYW5kIHNldHVwIGF0dHJpYnV0ZXMuIFRoaXMgbWVhbnMg dGhhdCBhbiBlbmRwb2ludCB0aGF0IHNlZXMgdGhlIGF0dHJpYnV0ZXMgY2FuIHJlcGxheSBsaWtl d2lzZSBhbmQgYWdyZWUgU1JUUC1EVExTLiBPbGQgZW5kcG9pbnRzIGlnbm9yZSB0aGUgYXR0cmli dXRlcyBhbmQgY2FuIHN0aWxsIGFuc3dlciB0aGUgY2FsbC4NCg0KVGhlcmUgYXJlIG90aGVyIHdh eXMgdG8gY29uc3RydWN0IHRoZSBTRFAgaWYgeW91IHdhbnQgdG8gb2ZmZXIgYm90aCBSVFAvU0FW UCBhbmQgUlRQL0FWUCwgYnV0IHRoYXQgb3BlbnMgdXAgZm9yIGRvd25ncmFkZSBhdHRhY2tzLCBz byBvbmUgbmVlZCBzZXJpb3VzIGNvbnNpZGVyYXRpb24uDQoNCkVkUyAtIFR5cGljYWxseSwgb2xk ZXIgZW5kcG9pbnRzIGFsc28gd291bGQgbm90IHN1cHBvcnQgdGhpcywgd2hpY2ggaXMgdGhlIGJl bmVmaXQgb2YgT1NSVFAgLSBJdCBpcyBiYWNrd2FyZGx5IGNvbXBhdGlibGUuDQoNCg0KDQpXaGls c3QgaXQgaXMgdHJ1ZSB0aGF0IGVuY3J5cHRpb24gY291bGQgYmUgdGVybWluYXRlZCBvbiB0aGUg UlVFDQppbnRlcmZhY2UgcHJveHksDQoNCkFyZW7igJl0IHlvdSBtaXhpbmcgc2lnbmFsbGluZyBh bmQgbWVkaWEgbm93Pw0KDQpFZFMgLSBJIGFtIG1pc3Npbmcgd2hhdCB5b3UgbWVhbiBoZXJlLg0K DQoNCmFueSBQcm92aWRlciB0aGF0IHdhbnRzIHRvIGFsbG93IGVuY3J5cHRpb24gZnVydGhlciBp bnRvIHRoZWlyIEluZnJhc3RydWN0dXJlIGlzIGdlbmVyYWxseSBmYWNlZCB3aXRoIHRoZSBwb3Rl bnRpYWwgbmVlZCB0byBmb3JrIGNhbGxzIHRvIHZhcmlvdXMgZGV2aWNlcywgcG9zc2libHkgb25s eSBzb21lIG9mIHdoaWNoIHN1cHBvcnQgZW5jcnlwdGlvbi4gVXNpbmcgUkZDLTU2NzMgYWxvbmUg d291bGQgbWVhbiB0aGF0IG9sZGVyIGRldmljZXMgdGhhdCBkbyBub3Qgc3VwcG9ydCBlbmNyeXB0 aW9uIHdvdWxkIHJlamVjdCB0aGUgY2FsbCBhcyB1bnN1cHBvcnRlZC4NCg0KSXNu4oCZdCB0aGF0 IG9uZSBvZiB0aGUgYmVuZWZpdHM/IEEgdXNlciBuZWVkcyB0byBiZSBhc3N1cmVkIHRoYXQgdGhl IGNhbGwgaXMgcHJvdGVjdGVkLiBBcyBhIHByb3ZpZGVyIHlvdSBtYXkgbmVlZCB0byBoYXZlIGdh dGV3YXlzIHRvIHRoZSBvbGQgd29ybGQgaWYgeW91IG5lZWQgdGhhdCwgYnV0IHN0aWxsIGtlZXAg dGhlIGZpcnN0IGNhbGwgbGVnIGVuY3J5cHRlZCBhdCBhbGwgdGltZXMuDQoNCkVkUyAtIEZyb20g YSBjdXN0b21lciBzdGFuZHBvaW50LCBoYXZpbmcgYSByYW5nZSBvZiBkZXZpY2VzIG5vIGxvbmdl ciByaW5nIGlzIG5vdCBhIGJlbmVmaXQuIFVzaW5nIE9TUlRQIGFzIGEgbWlncmF0aW9uIHBhdGgg dG8gc3VwcG9ydCBlbmQtdG8tZW5kIGVuY3J5cHRpb24gd2hpbGUgb2xkZXIgZGV2aWNlcyBjYW4g YmUgZ3JhZHVhbGx5ICdhZ2VkIG91dCcuDQpUaGUgdXNlciBtaWdodCBvdGhlcndpc2UgaGF2ZSBh biBpbGx1c2lvbiBvZiBzZWN1cml0eSAtIHRlcm1pbmF0ZWQgYXQgdGhlIFJVTSBwcm94eSwgd2hp bGUgdGhlIGVuZHBvaW50IG9uIHRoZSBvdGhlciBlbmQgaXMgbm90IGVuY3J5cHRlZCAoYmVjYXVz ZSBpdCBjYW5ub3Qgc3VwcG9ydCBpdCkuDQoNCg0KDQpVc2luZyBPU1JUUCBpcyBieSBmYXIgdGhl IHNpbXBsZXN0IGFuZCBtb3N0IGNvbnZlbmllbnQgd2F5IHRvIGZvcmsgdGhlIGNhbGwgYW5kIHN0 aWxsIGVuc3VyZSB0aGF0IHRoZSB3aWRlc3QgcmFuZ2Ugb2YgZW5kcG9pbnRzIGNhbiByaW5nLg0K DQpCdXQgaXQgZG9lc27igJl0IGRlbGl2ZXIgYW55IGd1YXJhbnRlZSBvZiBhbnkga2luZCB0byB0 aGUgdXNlci4NCg0KRWRTIC0gSXQgcHJvdmlkZXMgYSBwcm9ncmVzc2lvbiB3aGVyZSBtb3JlIGFu ZCBtb3JlIGVuZHBvaW50cyBvdmVyIHRpbWUgY2FuIGJlIGVuY3J5cHRlZC4gUHJlY2lzZWx5IHdo eSB3ZSBhZG9wdGVkIGl0IG9uIHRoZSBJbnRlci1Qcm92aWRlciBpbnRlcmZhY2UuDQoNCg0KL08N Cg0KDQpDaGVlcnMsDQoNCg0KRWQgU2F5ZXJzDQpFbmRwb2ludCBTREsgVGVhbSBMZWFkDQpQdXJw bGUsIGEgRGl2aXNpb24gb2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEMgcHVycGxldnJzLmNvbTxo dHRwOi8vcHVycGxldnJzLmNvbT4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb25hbCBhbmQgY29u ZmlkZW50aWFsIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpIG5hbWVkIGFib3ZlLiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdXMg aW1tZWRpYXRlbHkgYnkgZS1tYWlsLCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0K DQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVtIDxydW0tYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86cnVtLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQnJp YW4gUm9zZW4NClNlbnQ6IDMwIEF1Z3VzdCAyMDIxIDIyOjI0DQpUbzogUGF1bCBLeXppdmF0IDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4+DQpDYzog Q2hhZCBMZWVwZXIgPGNoYWQubGVlcGVyQGNvbnZvcmVsYXkuY29tPG1haWx0bzpjaGFkLmxlZXBl ckBjb252b3JlbGF5LmNvbT4+OyBydW1AaWV0Zi5vcmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbUnVtXSBJUHY2IGFuZCBlbmNyeXB0aW9uDQoNCkkgZG9u4oCZdCB0aGluayB0 aGVyZSBhcmUgQU5ZIGFsdGVybmF0aXZlcyB0byBTUlRQLiAgVGhlcmUgYXJlIGFsdGVybmF0aXZl cyB0byBEVExTLVNSVFAuICBUaGVyZSBhcmUgbW92ZXMgd2l0aGluIHRoZSBJRVRGIHRvIGRlcHJl Y2F0ZSBTREVTLCBzcGVjaWZpY2FsbHkuICBUaGVyZSBpcyBwdXNoIGJhY2sgb24gdGhhdCwgYnV0 IGl04oCZcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gYmVjYXVzZSBTREVTIGlzbuKAmXQgc2VjdXJl IGVub3VnaC4gICBTaW5jZSBhbGwgcHJvdmlkZXJzIEkga25vdyBhYm91dCBhbmNob3IgbWVkaWEs IHRoaXMgb25seSBhZmZlY3RzIHRoZSBpbml0aWFsIGhvcC4gIFVzZXJzIHJlYWxseSB3YW50IHRv IGhlYXIgdGhhdCB0aGVpciBtZWRpYSBpcyBwcm90ZWN0ZWQgZW5kIHRvIGVuZCAoYXQgbGVhc3Qg aG9wIGJ5IGhvcCkgYnV0IG91ciBkb2N1bWVudCBkb2VzbuKAmXQgcmVxdWlyZSB0aGF0LiAgQWdh aW4sIHdlIG5lZWQgYSBTVEFOREFSRFMgYmFzZWQgc29sdXRpb24sIGFuZCB3ZSBoYXZlIHRvIGxp dmUgd2l0aGluIHRoZSBjb25zdHJhaW50cyB0aGUgSUVURiBoYXMgZm9yIG5ldyBzdGFuZGFyZHMg d2l0aCByZXNwZWN0IHRvIHNlY3VyaXR5LiAgTGlrZSBuZWFybHkgZXZlcnkgb3JnYW5pemF0aW9u LCB0aGUgSUVURiBpcyBtdWNoIG1vcmUgc2VjdXJpdHkgY29uc2Npb3VzIHRoYW4gaXQgd2FzLCBh bmQgd29u4oCZdCB0b2xlcmF0ZSBiYWQgc2VjdXJpdHkgYWx0aG91Z2ggaXQgb2Z0ZW4gcmVjb2du aXplcyB0aGUgbmVjZXNzaXR5IGZvciBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBhcyBsb25nIGFz IGl04oCZcyBub3QgdG8gYSBrbm93biBpbnNlY3VyZSBtZWNoYW5pc20uDQoNCkkgcmVhbGx5IHRo aW5rIHRoaXMgaXMgYSDigJxzdGVwIHVwIHRvIHRoZSBiYXLigJ0gdGhpbmcuICBXZeKAmXZlIHNw ZW50IGxvdHMgb2YgdGltZSBhbmQgY3ljbGVzIGltcGxlbWVudGluZyB0aGluZ3MgdGhhdCB0dXJu IG91dCBub3QgdG8gYmUgc2VjdXJlIGVub3VnaCwgYW5kIHdlIGhhdmUgdG8gbW92ZSBmb3J3YXJk IG9uIHRoaW5ncyB0aGF0IGFyZS4gIERUTFMtU1JUUCBpcyBvbmUgb2YgdGhvc2UgdGhpbmdzLCBh cyBpcyBJUHY2Lg0KDQpCcmlhbg0KDQoNCg0KT24gQXVnIDMwLCAyMDIxLCBhdCA1OjA2IFBNLCBQ YXVsIEt5eml2YXQgPHBreXppdmF0QGFsdW0ubWl0LmVkdTxtYWlsdG86cGt5eml2YXRAYWx1bS5t aXQuZWR1Pj4gd3JvdGU6DQoNCkNoYWQsDQoNCldlbGNvbWUgdG8gdGhlIFJVTSBXRyENCg0KT24g OC8zMC8yMSAxMTo1MSBBTSwgQ2hhZCBMZWVwZXIgd3JvdGU6DQoNCi0gV2hpbGUgV2ViUlRDIHcv IFNSVFAvRFRMUyAoZW5jcnlwdGlvbikgaXMgYW4gZXhjZWxsZW50IGlkZWEgZ29pbmcgZm9yd2Fy ZCwgaXQgY2FuJ3QgYmUgYSAiTVVTVCIgcmVxdWlyZW1lbnQuIEkgYWdyZWUgd2l0aCBSb2dlciBT bHVzc2VyIHRoYXQgbWFuZGF0aW5nIGNvbXBsaWFuY2UgdXNpbmcgTVVTVCByZXF1aXJlcyBwcm92 aWRlcnMgdG8gaW1wbGVtZW50IHNpZ25pZmljYW50IGRldmVsb3BtZW50IHRvIGNoYW5nZSBvdmVy IHRvIHdoYXQgUlVNIGlzIHNwZWNpZnlpbmcuDQoNClRoZSByZXF1aXJlbWVudHMgaW4gdGhpcyBk b2Mgd2lsbCBhcHBseSBvbmx5IHRvIGRldmljZXMgdGhhdCBjbGFpbSB0bw0KY29uZm9ybSB0byBp dC4gUHJlc3VtYWJseSB5b3UgY291bGQgY29udGludWUgdG8gc3VwcG9ydCB5b3VyIGV4aXN0aW5n DQpkZXZpY2VzIHVzaW5nIHdoYXRldmVyIG1lY2hhbmlzbXMgdGhleSBjdXJyZW50bHkgdXNlLiBT byB0aGUNCmltcGxlbWVudGF0aW9uIGJ1cmRlbiBpcyBvbmx5IG9uIHRoZSBzZXJ2ZXIgc2lkZSwg bm90IHRoZSBsZWdhY3kNCmRldmljZSBzaWRlLiAoT2YgY291cnNlIHRoZSBGQ0Mgd2lsbCBoYXZl IGEgc2F5IGluIHRoaXMuKQ0KDQpPbmUgbW90aXZhdGlvbiBmb3IgdGhlIHdlYnJ0YyByZXF1aXJl bWVudCBpcyBzbyB0aGF0IGEgUlVFIGNhbiBiZQ0KYnVpbHQgb24gdG9wIG9mIFdlYlJUQy4gRS5n LiwgaXQgY2FuIGJlIGEgc2VydmVyIHRoYXQgc3VwcG9ydHMgZGVhZg0KdXNlcnMgdXNpbmcgYW55 IGRldmljZSB3aXRoIGEgYnJvd3Nlci4gU3VjaCBhIHNlcnZlciBpcyBlZmZlY3RpdmVseQ0KanVz dCBzaWduYWxpbmcgZ2F0ZXdheSB0aGF0IGNhbiBlc3RhYmxpc2ggYSBwMnAgbGluayBiZXR3ZWVu IHRoZQ0KYnJvd3NlciBhbmQgdGhlIFZSUyBwcm92aWRlciBzZXJ2ZXIuIChJdCBkb2VzIGhhdmUg dG8gdHJhbnNjb2RlIFJUVCwNCmJ1dCB0aGF0IGlzIGxlc3Mgb2YgYSBidXJkZW4uKQ0KDQpXaGVu IGRlZmluaW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgYW4gaW50ZXJmYWNlIHRoYXQgaXMgdG8gYmUg aW1wbGVtZW50ZWQgYnkgaW5kZXBlbmRlbnQgcGFydGllcyBpdCBpcyBuZWNlc3NhcnkgZm9yIGVz c2VudGlhbCBmdW5jdGlvbnMgdG8gaGF2ZSBhdCBsZWFzdCBvbmUgbWFuZGF0b3J5IHRvIGltcGxl bWVudCBtZWNoYW5pc20uIEN1cnJlbnRseSB0aGVyZSBhcmUgbm8gc3RhbmRhcmRzIGZvciBjb25u ZWN0aW5nIGEgUlVFIHRvIGEgcHJvdmlkZXIsIHNvIHdlIG5lZWQgdG8gcGljayAqc29tZXRoaW5n KiB0byBiZSBtYW5kYXRvcnkgdG8gaW1wbGVtZW50LiBJZiB5b3UgaGF2ZSBhbiBhbHRlcm5hdGl2 ZSBmb3IgdGhlIG1lZGlhIHlvdSB3b3VsZCBwcmVmZXIsIHRoZW4gcGxlYXNlIG1ha2UgYSBzcGVj aWZpYyBwcm9wb3NhbC4NCg0KDQotIFdlIHNob3VsZCBrZWVwIGFueSBuZXcgcHJpdmFjeSByZXF1 aXJlbWVudHMgdmVyeSBtaW5pbWFsIGF0IHRoaXMgdGltZS4gIFdoaWxlIGNvbXBhbmllcyBpbiB0 aGUgRVUgaGF2ZSBhbHJlYWR5IGNyZWF0ZWQgdGhlaXIgc3lzdGVtcyBpbiBjb21wbGlhbmNlIHdp dGggdGhlIEdEUFIsIG1vc3Qgb2YgdGhlIHdvcmxkIGhhc24ndCBjcmVhdGVkIGFuIGVxdWl2YWxl bnQgeWV0LiAgU28gd2hhdCBtYXkgbG9vayBsaWtlIGFuIGVhc3kgY2hhbmdlIHRvIEVVIGltcGxl bWVudGVycyBtYXkgYmUgYSBkcmFtYXRpYyBjaGFuZ2UgZm9yIG90aGVycy4NCg0KSSBkb24ndCB0 aGluayB3ZSBoYXZlIHNhaWQgbXVjaCBhYm91dCBwcml2YWN5IG9mIHJldGFpbmVkIGRhdGEuIEJ1 dCB3ZSBhcmUgY29uY2VybmVkIHRoYXQgdGhlIG1lZGlhIGFuZCBzaWduYWxpbmcgYmUgcHJpdmF0 ZSBiZXR3ZWVuIHRoZSBSVUUgYW5kIHRoZSBwcm92aWRlci4gVGhhdCBpcyBhIGxvdyBiYXIgdGhl c2UgZGF5cy4gSXQgaXMgdW5saWtlbHkgdGhhdCBhbnl0aGluZyBsZXNzIGNvdWxkIGJlIGFwcHJv dmVkLiBJIGV4cGVjdCB0aGUgRkNDIHdpbGwgYWdyZWUuDQoNCklmIHlvdSBoYXZlIGFuIGFsdGVy bmF0ZSBwcm9wb3NhbCB0aGF0IGFjaGlldmVzIHRoYXQgdGhlbiBtYWtlIGEgcHJvcG9zYWwgd2Ug Y2FuIGRpc2N1c3MuDQoNCiAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAgICAgICAg UGF1bA0KDQoNCk9uIEZyaSwgQXVnIDI3LCAyMDIxIGF0IDM6MTYgUE0gUGF1bCBLeXppdmF0IDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU8bWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdT4gPG1haWx0 bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHU+PiB3cm90ZToNCiBQcm92aWRlcnMsDQogTXkgcmVxdWVz dCBiZWxvdyB0byBSb2dlciBzaG91bGQgaGF2ZSBiZWVuIGJyb2FkZXIuIFlvdSBhbGwgc2VlbSB0 bw0KIGhhdmUNCiB0aGUgc2FtZSBpc3N1ZS4gSSBlbmNvdXJhZ2UgYW55L2FsbCBvZiB5b3UgdG8g bWFrZSBhbiBhbHRlcm5hdGl2ZQ0KIHByb3Bvc2FsIGhlcmUuIEp1c3Qgc2F5aW5nICJ3ZSBkb24n dCBsaWtlIHdoYXQgaXMgdGhlcmUiIGlzbid0IGhlbHBmdWwNCiB3aXRob3V0IGFuIGFsdGVybmF0 aXZlLg0KICAgICAgICAgIFRoYW5rcywNCiAgICAgICAgICBQYXVsDQogT24gOC8yNi8yMSA1OjQw IFBNLCBQYXVsIEt5eml2YXQgd3JvdGU6DQoNClJvZ2VyLA0KDQpPbiA4LzI2LzIxIDM6MzAgUE0s IFJvZ2VyIFNsdXNzZXIgd3JvdGU6DQoNCg0KTW9zdCBwcm92aWRlcnMgYWxyZWFkeSBzdXBwb3J0 IGVuY3J5cHRpb24gYW5kIElQVjYgb24gYSBsaW1pdGVkDQogc2NvcGUsDQoNCm5vdCBuZWNlc3Nh cmlseSB0aGUgd2F5IGl0IGlzIGRlZmluZWQgaW4gUlVNIHNwZWMuIE1hbmRhdGluZw0KY29tcGxp YW5jZSB1c2luZyBNVVNUIHJlcXVpcmVzIHByb3ZpZGVycyB0byBkaXNjYXJkIHNvbWV0aW1lcyBo dWdlDQphbW91bnRzIG9mIGRldmVsb3BtZW50IHRvIGNoYW5nZSBvdmVyIHRvIHdoYXQgUlVNIGlz IHNwZWNpZnlpbmcuDQogVGhlDQoNCnB1c2ggYmFjayBpcyBub3QgYWJvdXQgZG9pbmcgdGhlc2Ug dGhpbmdzIGl0IGlzIGFib3V0IHRoZSBsb3NzIG9mDQp0aW1lLCBlZmZvcnQgYW5kIG1vbmV5IHRv IGRvIHRoZW0gaW4gdGhlIHdheSBSVU0gbWFuZGF0ZXMgd2l0aA0KIE1VU1RzLg0KDQoNCkRvIHlv dSB0aGluayB0aGVyZSBpcyBzb21ldGhpbmcgZWxzZSB3ZSBjb3VsZCB3cml0ZSBpbiB0aGlzIHNw ZWMNCiB0aGF0DQoNCmNvdmVycyBlbmNyeXB0aW9uIGFuZCBJUHY2IGluIGEgd2F5IHRoYXQgaXMg bGVzcyBidXJkZW5zb21lIGZvcg0KcHJvdmlkZXJzIHdoaWxlIHJlbWFpbmluZyBpbnRlcm9wZXJh YmxlIHdpdGggYWxsIHByb3ZpZGVycz8NCg0KSWYgc28sIGNhbiB5b3UgcGxlYXNlIHNwZWxsIGl0 IG91dD8NCiAtLSAgICAgUnVtIG1haWxpbmcgbGlzdA0KIFJ1bUBpZXRmLm9yZzxtYWlsdG86UnVt QGlldGYub3JnPiA8bWFpbHRvOlJ1bUBpZXRmLm9yZz4NCiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3J1bQ0KIDxodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3J1bT4NCg0KLS0NClJ1bSBtYWlsaW5nIGxpc3QNClJ1bUBpZXRmLm9yZzxtYWlsdG86UnVt QGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0NCg0K LS0NClJ1bSBtYWlsaW5nIGxpc3QNClJ1bUBpZXRmLm9yZzxtYWlsdG86UnVtQGlldGYub3JnPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW0NCi0tDQpSdW0gbWFpbGlu ZyBsaXN0DQpSdW1AaWV0Zi5vcmc8bWFpbHRvOlJ1bUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQoNCg== --_000_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow Y207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIEJyaWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIHdvdWxkIHNheSB0 aGF0IE9TUlRQIGlzIG1vcmUgYSB3YXkgb2YgbmVnb3RpYXRpbmcgU1JUUC4gSXQgYWxsb3dzIG9s ZGVyIGVuZHBvaW50cyB0aGF0IGNhbuKAmXQvZG9u4oCZdCBzdXBwb3J0IGVuY3J5cHRpb24gdG8g c3RpbGwgcG90ZW50aWFsbHkgcGFydGljaXBhdGUgaW4gYSBjYWxsLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5ZZXMsIHRoZSBp bnRlbnRpb24gb2YgYWRkaW5nIE9TUlRQIHRvIHRoZSB1cGRhdGVkIEludGVyLVByb3ZpZGVyIHNw ZWNpZmljYXRpb24gd2FzIHRvIGFsbG93IHRoZSBwb3NzaWJpbGl0eSBvZiBlbmQtdG8tZW5kIFNS VFAtRFRMUyBlbmNyeXB0aW9uIGJldHdlZW4gdGhlIGVuZHBvaW50cyBvZiB0d28gZGlmZmVyZW50 IFByb3ZpZGVycyBvbmNlDQogc3VwcG9ydGVkIChvciBwYXNzZWQgb24pIHdoZXJlIHBvc3NpYmxl LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdl OkVOLVVTIj5XZSB0aG91Z2h0IHRoaXMgdG8gYmUgdGhlIGJlc3QgYmFsYW5jZSBiZXR3ZWVuIGFk ZGluZyBidXJkZW5zb21lIGNvbXBsZXhpdHksIGNhbGxzIGZhaWxpbmcgb3V0LXJpZ2h0IG9yIHNv bWUgZGV2aWNlcyBub3QgcmluZ2luZywgd2hpbHN0IHN0aWxsIGFsbG93aW5nIGVuY3J5cHRpb24g d2hlbmV2ZXIgaXQgcG9zc2libHkgY291bGQgYmUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjx0 YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNl bGxwYWRkaW5nPSIwIiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjBjbTtib3JkZXItY29sbGFwc2U6 Y29sbGFwc2UiPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJoZWlnaHQ6MzUuMjVwdCI+DQo8dGQgd2lk dGg9IjM4MSIgc3R5bGU9IndpZHRoOjI4NS43NXB0O2JhY2tncm91bmQ6d2hpdGU7cGFkZGluZzow Y20gMGNtIDBjbSAwY207aGVpZ2h0OjM1LjI1cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206Ny41cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbTo3LjVwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RWQg U2F5ZXJzPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEzLjVwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YnI+DQo8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RW5kcG9pbnQgU0RLIFRlYW0gTGVhZDxicj4NClB1 cnBsZSwgYSBEaXZpc2lvbiBvZiBaUCBCZXR0ZXIgVG9nZXRoZXIsIExMQzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjcuNXB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3B1cnBsZXZycy5j b20vIj48c3BhbiBzdHlsZT0iY29sb3I6IzMzN0FCNyI+cHVycGxldnJzLmNvbTwvc3Bhbj48L2E+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvdGQ+DQo8dGQgc3R5bGU9ImJvcmRlcjpub25lO3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtIiB3 aWR0aD0iMzIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPC90ZD4NCjwvdHI+ DQo8dHIgc3R5bGU9ImhlaWdodDozNS4yNXB0Ij4NCjx0ZCB3aWR0aD0iMzkwIiBjb2xzcGFuPSIy IiBzdHlsZT0id2lkdGg6MjkyLjVwdDtiYWNrZ3JvdW5kOndoaXRlO3BhZGRpbmc6My43NXB0IDBj bSAwY20gMGNtO2hlaWdodDozNS4yNXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIzMDAiIGhlaWdodD0iNTQi IHN0eWxlPSJ3aWR0aDozLjEyNWluO2hlaWdodDouNTYyNWluIiBpZD0iUGljdHVyZV94MDAyMF8x IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFENzlFNkUuNjQ1MTI2NzAiIGFsdD0iUHVycGxlIGlz IERFSSBjZXJ0aWZpZWQhIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHIgc3R5bGU9ImhlaWdodDozNS4yNXB0 Ij4NCjx0ZCB3aWR0aD0iNTAwIiBjb2xzcGFuPSIyIiBzdHlsZT0id2lkdGg6Mzc1LjBwdDtiYWNr Z3JvdW5kOndoaXRlO3BhZGRpbmc6MzAuMHB0IDBjbSAwY20gMGNtO2hlaWdodDozNS4yNXB0Ij4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+VGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkIG9ubHkg Zm9yIHRoZSBwZXJzb25hbCBhbmQgY29uZmlkZW50aWFsIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMp IG5hbWVkIGFib3ZlLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzDQogY29tbXVuaWNhdGlvbiBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBieSBlLW1haWwsIGFuZCBkZWxl dGUgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwv dHI+DQo8L3Rib2R5Pg0KPC90YWJsZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IEJyaWFuIFJvc2VuICZsdDtickBicmlhbnJvc2Vu Lm5ldCZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAzMSBBdWd1c3QgMjAyMSAxMzozMDxicj4NCjxi PlRvOjwvYj4gRWQgU2F5ZXJzICZsdDtlZC5zYXllcnNAcHVycGxlLnVzJmd0Ozxicj4NCjxiPkNj OjwvYj4gT2xsZSBFLiBKb2hhbnNzb24gJmx0O29lakBlZHZpbmEubmV0Jmd0OzsgUGF1bCBLeXpp dmF0ICZsdDtwa3l6aXZhdEBhbHVtLm1pdC5lZHUmZ3Q7OyBydW1AaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtSdW1dIGVuY3J5cHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcmUgeW91IHByb3Bvc2luZyB0aGlzIGluIGFkZGl0aW9u IHRvIHJlcXVpcmluZyBEVExTLVNUUlAgb3IgaW5zdGVhZCBvZiBpdD88bzpwPjwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldvdWxkIHR3byB1c2VycyBkb2luZyBwb2lu dCB0byBwb2ludCBjYWxsaW5nIHRocm91Z2ggdHlwaWNhbCBwcm92aWRlcnMgdGhhdCBhbmNob3Ig bWVkaWEgcmVsaWFibHkgZ2V0IGEgc2VjdXJlIGNvbm5lY3Rpb24gaG9wLWJ5LWhvcCBpZiBib3Ro IHVzZXJzIGFuZCBib3RoIHByb3ZpZGVycyBoYWQgY29uZm9ybWluZyBpbXBsZW1lbnRhdGlvbnMg YW5kIHRoZSBwcm92aWRlcnMgaW1wbGVtZW50ZWQgdGhlIG5ldyBpbnRlci1wcm92aWRlcg0KIHNw ZWM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+VXNlciAx ICZuYnNwOyBQcm92aWRlciAxICZuYnNwOyAmbmJzcDsgUHJvdmlkZXIgMiAmbmJzcDsgJm5ic3A7 IFVzZXIgMjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 OyI+Jm5ic3A7ICZuYnNwOyAmbmJzcDtEVExTLSAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg RFRMUz0gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0RUTFMtPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsgJm5ic3A7ICZu YnNwO1NSVFAgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NSVFAgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBTUlRQICZuYnNwOyAmbmJzcDsgJm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gQXVnIDMx LCAyMDIxLCBhdCA2OjMwIEFNLCBFZCBTYXllcnMgJmx0OzxhIGhyZWY9Im1haWx0bzplZC5zYXll cnNAcHVycGxlLnVzIj5lZC5zYXllcnNAcHVycGxlLnVzPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpLDxicj4N Cjxicj4NCklubGluZSBiZWxvdy4uPGJyPg0KPGJyPg0KPGJyPg0KRWQgU2F5ZXJzPGJyPg0KRW5k cG9pbnQgU0RLIFRlYW0gTGVhZDxicj4NClB1cnBsZSwgYSBEaXZpc2lvbiBvZiBaUCBCZXR0ZXIg VG9nZXRoZXIsIExMQzxicj4NCjwvc3Bhbj48YSBocmVmPSJodHRwOi8vcHVycGxldnJzLmNvbS8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPnB1cnBsZXZycy5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwg bWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uYWwgYW5kIGNvbmZpZGVudGlh bCB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0 ZWx5IGJ5IGUtbWFpbCwgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZS48YnI+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206 IE9sbGUgRS4gSm9oYW5zc29uICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOm9lakBlZHZpbmEu bmV0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5vZWpAZWR2aW5hLm5ldDwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQpTZW50OiAzMSBBdWd1c3QgMjAyMSAxMToxMjxicj4NClRvOiBFZCBTYXllcnMg Jmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWQuc2F5ZXJzQHB1cnBsZS51cyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+ZWQuc2F5ZXJzQHB1cnBsZS51czwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0Ozxicj4NCkNjOiBCcmlhbiBSb3NlbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpickBi cmlhbnJvc2VuLm5ldCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+YnJAYnJpYW5yb3Nlbi5uZXQ8L3NwYW4+ PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs7IFBhdWwgS3l6aXZhdCAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpwa3l6aXZhdEBhbHVtLm1pdC5lZHUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnBreXpp dmF0QGFsdW0ubWl0LmVkdTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozs8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpydW1AaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnJ1bUBpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KU3ViamVjdDogUmU6IFtSdW1dIGVuY3J5cHRp b248YnI+DQo8YnI+DQo8YnI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMzEg QXVnIDIwMjEsIGF0IDExOjI5LCBFZCBTYXllcnMgJmx0OzxhIGhyZWY9Im1haWx0bzplZC5zYXll cnNAcHVycGxlLnVzIj5lZC5zYXllcnNAcHVycGxlLnVzPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJy Pg0KSGksPGJyPg0KPGJyPg0KVGhvdWdodCBJJ2Qgc3BsaXQgb3V0IElQdjYgYW5kIGVuY3J5cHRp b24gYXMgc2VwYXJhdGUgcG9pbnRzLi48YnI+DQo8YnI+DQpGb3IgZW5jcnlwdGlvbiwgdGhlIFVT IFZSUyBQcm92aWRlcnMgcmVjZW50bHkgY3JlYXRlZCBhIG5ldyBQcm92aWRlciBJbnRlci1PcGVy YWJpbGl0eSBQcm9maWxlIHRoYXQgbm93IHNwZWNpZmljYWxseSBhbGxvd3MgZm9yIGVuY3J5cHRp b24gYW5kIElDRSwgYW1vbmdzdCBvdGhlciB0aGluZ3MuPGJyPg0KPGJyPg0KV2hpbHN0IHdlIGFs bCBhZ3JlZWQgdGhhdCBTUlRQLURUTFMgaXMgdGhlIHJpZ2h0IHdheSB0byBnbywgd2UgZGVjaWRl ZCB0byBzcGVjaWZpY2FsbHkgYWRvcHQgUkZDLTg2NDMgT1NSVFAsIGJlY2F1c2UgdGhpcyBhbGxv d3MgZm9yIHRoZSBncmVhdGVzdCBmbGV4aWJpbGl0eSBhbmQgZ3JlYXRlc3QgY2hhbmNlIG9mIHN1 cHBvcnRpbmcgZW5kLXRvLWVuZCBlbmNyeXB0aW9uLCB3aGlsZSBzdGlsbCBzdXBwb3J0aW5nIGEg aGV0ZXJvZ2Vub3VzIHJhbmdlDQogb2YgZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQo8YnI+DQpPU1JUUCBzdXBwb3J0cyBTUlRQLURUTFMuIEl04oCZcyBub3QgYW4gYWx0ZXJuYXRp dmUuIEFuZCBpdOKAmXMganVzdCBhbiBpbmZvcm1hdGlvbmFsIFJGQywgbm90IGEgc3RhbmRhcmRz IFJGQy5Zb3Ugc3RpbGwgaGF2ZSB0byBpbXBsZW1lbnQgU1JUUC1EVExTIHNvIHlvdSBjYW4gdXNl IHRoYXQgZnVsbHkgaW4gYSBzaXR1YXRpb24gd2hlcmUgYWxsIGRldmljZXMgaGFzIHN1cHBvcnQu PGJyPg0KPGJyPg0KRWRTIC0gV2Uga25vdyBpdCBpcyBub3QgYW4gYWx0ZXJuYXRpdmUuIEl0IHNp bXBseSByZXZlcnQgdGhlIHByb2ZpbGUgdG8gUlRQL0FWUCwgd2hpbGUga2VlcGluZyB0aGUgZmlu Z2VycHJpbnQgYW5kIHNldHVwIGF0dHJpYnV0ZXMuIFRoaXMgbWVhbnMgdGhhdCBhbiBlbmRwb2lu dCB0aGF0IHNlZXMgdGhlIGF0dHJpYnV0ZXMgY2FuIHJlcGxheSBsaWtld2lzZSBhbmQgYWdyZWUg U1JUUC1EVExTLiBPbGQgZW5kcG9pbnRzIGlnbm9yZSB0aGUgYXR0cmlidXRlcw0KIGFuZCBjYW4g c3RpbGwgYW5zd2VyIHRoZSBjYWxsLjxicj4NCjxicj4NClRoZXJlIGFyZSBvdGhlciB3YXlzIHRv IGNvbnN0cnVjdCB0aGUgU0RQIGlmIHlvdSB3YW50IHRvIG9mZmVyIGJvdGggUlRQL1NBVlAgYW5k IFJUUC9BVlAsIGJ1dCB0aGF0IG9wZW5zIHVwIGZvciBkb3duZ3JhZGUgYXR0YWNrcywgc28gb25l IG5lZWQgc2VyaW91cyBjb25zaWRlcmF0aW9uLjxicj4NCjxicj4NCkVkUyAtIFR5cGljYWxseSwg b2xkZXIgZW5kcG9pbnRzIGFsc28gd291bGQgbm90IHN1cHBvcnQgdGhpcywgd2hpY2ggaXMgdGhl IGJlbmVmaXQgb2YgT1NSVFAgLSBJdCBpcyBiYWNrd2FyZGx5IGNvbXBhdGlibGUuPGJyPg0KPGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z cGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCldoaWxzdCBpdCBpcyB0cnVlIHRoYXQg ZW5jcnlwdGlvbiBjb3VsZCBiZSB0ZXJtaW5hdGVkIG9uIHRoZSBSVUU8c3BhbiBjbGFzcz0iYXBw bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KaW50ZXJmYWNlIHByb3h5LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkFyZW7igJl0IHlvdSBtaXhpbmcgc2lnbmFsbGluZyBh bmQgbWVkaWEgbm93Pzxicj4NCjxicj4NCkVkUyAtIEkgYW0gbWlzc2luZyB3aGF0IHlvdSBtZWFu IGhlcmUuPGJyPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmFueSBQcm92aWRlciB0 aGF0IHdhbnRzIHRvIGFsbG93IGVuY3J5cHRpb24gZnVydGhlciBpbnRvIHRoZWlyIEluZnJhc3Ry dWN0dXJlIGlzIGdlbmVyYWxseSBmYWNlZCB3aXRoIHRoZSBwb3RlbnRpYWwgbmVlZCB0byBmb3Jr IGNhbGxzIHRvIHZhcmlvdXMgZGV2aWNlcywgcG9zc2libHkgb25seSBzb21lDQogb2Ygd2hpY2gg c3VwcG9ydCBlbmNyeXB0aW9uLiBVc2luZyBSRkMtNTY3MyBhbG9uZSB3b3VsZCBtZWFuIHRoYXQg b2xkZXIgZGV2aWNlcyB0aGF0IGRvIG5vdCBzdXBwb3J0IGVuY3J5cHRpb24gd291bGQgcmVqZWN0 IHRoZSBjYWxsIGFzIHVuc3VwcG9ydGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCklzbuKA mXQgdGhhdCBvbmUgb2YgdGhlIGJlbmVmaXRzPyBBIHVzZXIgbmVlZHMgdG8gYmUgYXNzdXJlZCB0 aGF0IHRoZSBjYWxsIGlzIHByb3RlY3RlZC4gQXMgYSBwcm92aWRlciB5b3UgbWF5IG5lZWQgdG8g aGF2ZSBnYXRld2F5cyB0byB0aGUgb2xkIHdvcmxkIGlmIHlvdSBuZWVkIHRoYXQsIGJ1dCBzdGls bCBrZWVwIHRoZSBmaXJzdCBjYWxsIGxlZyBlbmNyeXB0ZWQgYXQgYWxsIHRpbWVzLjxicj4NCjxi cj4NCkVkUyAtIEZyb20gYSBjdXN0b21lciBzdGFuZHBvaW50LCBoYXZpbmcgYSByYW5nZSBvZiBk ZXZpY2VzIG5vIGxvbmdlciByaW5nIGlzIG5vdCBhIGJlbmVmaXQuIFVzaW5nIE9TUlRQIGFzIGEg bWlncmF0aW9uIHBhdGggdG8gc3VwcG9ydCBlbmQtdG8tZW5kIGVuY3J5cHRpb24gd2hpbGUgb2xk ZXIgZGV2aWNlcyBjYW4gYmUgZ3JhZHVhbGx5ICdhZ2VkIG91dCcuPGJyPg0KVGhlIHVzZXIgbWln aHQgb3RoZXJ3aXNlIGhhdmUgYW4gaWxsdXNpb24gb2Ygc2VjdXJpdHkgLSB0ZXJtaW5hdGVkIGF0 IHRoZSBSVU0gcHJveHksIHdoaWxlIHRoZSBlbmRwb2ludCBvbiB0aGUgb3RoZXIgZW5kIGlzIG5v dCBlbmNyeXB0ZWQgKGJlY2F1c2UgaXQgY2Fubm90IHN1cHBvcnQgaXQpLjxicj4NCjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3Rl eHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2lu ZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQpVc2luZyBPU1JUUCBpcyBieSBmYXIgdGhlIHNp bXBsZXN0IGFuZCBtb3N0IGNvbnZlbmllbnQgd2F5IHRvIGZvcmsgdGhlIGNhbGwgYW5kIHN0aWxs IGVuc3VyZSB0aGF0IHRoZSB3aWRlc3QgcmFuZ2Ugb2YgZW5kcG9pbnRzIGNhbiByaW5nLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkJ1dCBpdCBkb2VzbuKAmXQgZGVsaXZlciBhbnkgZ3VhcmFu dGVlIG9mIGFueSBraW5kIHRvIHRoZSB1c2VyLjxicj4NCjxicj4NCkVkUyAtIEl0IHByb3ZpZGVz IGEgcHJvZ3Jlc3Npb24gd2hlcmUgbW9yZSBhbmQgbW9yZSBlbmRwb2ludHMgb3ZlciB0aW1lIGNh biBiZSBlbmNyeXB0ZWQuIFByZWNpc2VseSB3aHkgd2UgYWRvcHRlZCBpdCBvbiB0aGUgSW50ZXIt UHJvdmlkZXIgaW50ZXJmYWNlLjxicj4NCjxicj4NCjxicj4NCi9PPGJyIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpz dGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxicj4NCkNoZWVycyw8YnI+DQo8YnI+DQo8YnI+DQpFZCBTYXllcnM8YnI+ DQpFbmRwb2ludCBTREsgVGVhbSBMZWFkPGJyPg0KUHVycGxlLCBhIERpdmlzaW9uIG9mIFpQIEJl dHRlciBUb2dldGhlciwgTExDIDxhIGhyZWY9Imh0dHA6Ly9wdXJwbGV2cnMuY29tIj5wdXJwbGV2 cnMuY29tPC9hPjxicj4NCjxicj4NClRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBl LW1haWwgbWVzc2FnZSBpcyBpbnRlbmRlZCBvbmx5IGZvciB0aGUgcGVyc29uYWwgYW5kIGNvbmZp ZGVudGlhbCB1c2Ugb2YgdGhlIHJlY2lwaWVudChzKSBuYW1lZCBhYm92ZS4gSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGlt bWVkaWF0ZWx5IGJ5IGUtbWFpbCwgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwgbWVzc2FnZS48YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4N CkZyb206IFJ1bSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ1bS1ib3VuY2VzQGlldGYub3JnIj5ydW0t Ym91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbjxicj4NClNl bnQ6IDMwIEF1Z3VzdCAyMDIxIDIyOjI0PGJyPg0KVG86IFBhdWwgS3l6aXZhdCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBreXppdmF0QGFsdW0ubWl0LmVkdSI+cGt5eml2YXRAYWx1bS5taXQuZWR1PC9h PiZndDs8YnI+DQpDYzogQ2hhZCBMZWVwZXIgJmx0OzxhIGhyZWY9Im1haWx0bzpjaGFkLmxlZXBl ckBjb252b3JlbGF5LmNvbSI+Y2hhZC5sZWVwZXJAY29udm9yZWxheS5jb208L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzpydW1AaWV0Zi5vcmciPnJ1bUBpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0 OiBSZTogW1J1bV0gSVB2NiBhbmQgZW5jcnlwdGlvbjxicj4NCjxicj4NCkkgZG9u4oCZdCB0aGlu ayB0aGVyZSBhcmUgQU5ZIGFsdGVybmF0aXZlcyB0byBTUlRQLiAmbmJzcDtUaGVyZSBhcmUgYWx0 ZXJuYXRpdmVzIHRvIERUTFMtU1JUUC4gJm5ic3A7VGhlcmUgYXJlIG1vdmVzIHdpdGhpbiB0aGUg SUVURiB0byBkZXByZWNhdGUgU0RFUywgc3BlY2lmaWNhbGx5LiAmbmJzcDtUaGVyZSBpcyBwdXNo IGJhY2sgb24gdGhhdCwgYnV0IGl04oCZcyBhbiBvbmdvaW5nIGRpc2N1c3Npb24gYmVjYXVzZSBT REVTIGlzbuKAmXQgc2VjdXJlIGVub3VnaC4gJm5ic3A7Jm5ic3A7U2luY2UgYWxsDQogcHJvdmlk ZXJzIEkga25vdyBhYm91dCBhbmNob3IgbWVkaWEsIHRoaXMgb25seSBhZmZlY3RzIHRoZSBpbml0 aWFsIGhvcC4gJm5ic3A7VXNlcnMgcmVhbGx5IHdhbnQgdG8gaGVhciB0aGF0IHRoZWlyIG1lZGlh IGlzIHByb3RlY3RlZCBlbmQgdG8gZW5kIChhdCBsZWFzdCBob3AgYnkgaG9wKSBidXQgb3VyIGRv Y3VtZW50IGRvZXNu4oCZdCByZXF1aXJlIHRoYXQuICZuYnNwO0FnYWluLCB3ZSBuZWVkIGEgU1RB TkRBUkRTIGJhc2VkIHNvbHV0aW9uLCBhbmQgd2UgaGF2ZQ0KIHRvIGxpdmUgd2l0aGluIHRoZSBj b25zdHJhaW50cyB0aGUgSUVURiBoYXMgZm9yIG5ldyBzdGFuZGFyZHMgd2l0aCByZXNwZWN0IHRv IHNlY3VyaXR5LiAmbmJzcDtMaWtlIG5lYXJseSBldmVyeSBvcmdhbml6YXRpb24sIHRoZSBJRVRG IGlzIG11Y2ggbW9yZSBzZWN1cml0eSBjb25zY2lvdXMgdGhhbiBpdCB3YXMsIGFuZCB3b27igJl0 IHRvbGVyYXRlIGJhZCBzZWN1cml0eSBhbHRob3VnaCBpdCBvZnRlbiByZWNvZ25pemVzIHRoZSBu ZWNlc3NpdHkgZm9yIGJhY2t3YXJkcw0KIGNvbXBhdGliaWxpdHkgYXMgbG9uZyBhcyBpdOKAmXMg bm90IHRvIGEga25vd24gaW5zZWN1cmUgbWVjaGFuaXNtLiAmbmJzcDs8YnI+DQo8YnI+DQpJIHJl YWxseSB0aGluayB0aGlzIGlzIGEg4oCcc3RlcCB1cCB0byB0aGUgYmFy4oCdIHRoaW5nLiAmbmJz cDtXZeKAmXZlIHNwZW50IGxvdHMgb2YgdGltZSBhbmQgY3ljbGVzIGltcGxlbWVudGluZyB0aGlu Z3MgdGhhdCB0dXJuIG91dCBub3QgdG8gYmUgc2VjdXJlIGVub3VnaCwgYW5kIHdlIGhhdmUgdG8g bW92ZSBmb3J3YXJkIG9uIHRoaW5ncyB0aGF0IGFyZS4gJm5ic3A7RFRMUy1TUlRQIGlzIG9uZSBv ZiB0aG9zZSB0aGluZ3MsIGFzIGlzIElQdjYuPGJyPg0KPGJyPg0KQnJpYW48YnI+DQo8YnI+DQo8 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPk9uIEF1ZyAzMCwgMjAyMSwgYXQgNTowNiBQTSwgUGF1bCBLeXpp dmF0ICZsdDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBh bHVtLm1pdC5lZHU8L2E+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQpDaGFkLDxicj4NCjxicj4NCldl bGNvbWUgdG8gdGhlIFJVTSBXRyE8YnI+DQo8YnI+DQpPbiA4LzMwLzIxIDExOjUxIEFNLCBDaGFk IExlZXBlciB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPi0gV2hpbGUgV2ViUlRDIHcvIFNSVFAv RFRMUyAoZW5jcnlwdGlvbikgaXMgYW4gZXhjZWxsZW50IGlkZWEgZ29pbmcgZm9yd2FyZCwgaXQg Y2FuJ3QgYmUgYSAmcXVvdDtNVVNUJnF1b3Q7IHJlcXVpcmVtZW50LiBJIGFncmVlIHdpdGggUm9n ZXIgU2x1c3NlciB0aGF0IG1hbmRhdGluZyBjb21wbGlhbmNlIHVzaW5nIE1VU1QNCiByZXF1aXJl cyBwcm92aWRlcnMgdG8gaW1wbGVtZW50IHNpZ25pZmljYW50IGRldmVsb3BtZW50IHRvIGNoYW5n ZSBvdmVyIHRvIHdoYXQgUlVNIGlzIHNwZWNpZnlpbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJy Pg0KVGhlIHJlcXVpcmVtZW50cyBpbiB0aGlzIGRvYyB3aWxsIGFwcGx5IG9ubHkgdG8gZGV2aWNl cyB0aGF0IGNsYWltIHRvPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxicj4NCmNvbmZvcm0gdG8gaXQuIFByZXN1bWFibHkgeW91IGNvdWxkIGNvbnRpbnVl IHRvIHN1cHBvcnQgeW91ciBleGlzdGluZzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpkZXZpY2VzIHVzaW5nIHdoYXRldmVyIG1lY2hhbmlzbXMg dGhleSBjdXJyZW50bHkgdXNlLiBTbyB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KaW1wbGVtZW50YXRpb24gYnVyZGVuIGlzIG9ubHkgb24g dGhlIHNlcnZlciBzaWRlLCBub3QgdGhlIGxlZ2FjeTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpkZXZpY2Ugc2lkZS4gKE9mIGNvdXJzZSB0aGUg RkNDIHdpbGwgaGF2ZSBhIHNheSBpbiB0aGlzLik8YnI+DQo8YnI+DQpPbmUgbW90aXZhdGlvbiBm b3IgdGhlIHdlYnJ0YyByZXF1aXJlbWVudCBpcyBzbyB0aGF0IGEgUlVFIGNhbiBiZTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQpidWlsdCBvbiB0 b3Agb2YgV2ViUlRDLiBFLmcuLCBpdCBjYW4gYmUgYSBzZXJ2ZXIgdGhhdCBzdXBwb3J0cyBkZWFm PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCnVz ZXJzIHVzaW5nIGFueSBkZXZpY2Ugd2l0aCBhIGJyb3dzZXIuIFN1Y2ggYSBzZXJ2ZXIgaXMgZWZm ZWN0aXZlbHk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PGJyPg0KanVzdCBzaWduYWxpbmcgZ2F0ZXdheSB0aGF0IGNhbiBlc3RhYmxpc2ggYSBwMnAgbGlu ayBiZXR3ZWVuIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48YnI+DQpicm93c2VyIGFuZCB0aGUgVlJTIHByb3ZpZGVyIHNlcnZlci4gKEl0IGRvZXMg aGF2ZSB0byB0cmFuc2NvZGUgUlRULDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48YnI+DQpidXQgdGhhdCBpcyBsZXNzIG9mIGEgYnVyZGVuLik8YnI+DQo8 YnI+DQpXaGVuIGRlZmluaW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgYW4gaW50ZXJmYWNlIHRoYXQg aXMgdG8gYmUgaW1wbGVtZW50ZWQgYnkgaW5kZXBlbmRlbnQgcGFydGllcyBpdCBpcyBuZWNlc3Nh cnkgZm9yIGVzc2VudGlhbCBmdW5jdGlvbnMgdG8gaGF2ZSBhdCBsZWFzdCBvbmUgbWFuZGF0b3J5 IHRvIGltcGxlbWVudCBtZWNoYW5pc20uIEN1cnJlbnRseSB0aGVyZSBhcmUgbm8gc3RhbmRhcmRz IGZvciBjb25uZWN0aW5nIGEgUlVFIHRvIGEgcHJvdmlkZXIsDQogc28gd2UgbmVlZCB0byBwaWNr ICpzb21ldGhpbmcqIHRvIGJlIG1hbmRhdG9yeSB0byBpbXBsZW1lbnQuIElmIHlvdSBoYXZlIGFu IGFsdGVybmF0aXZlIGZvciB0aGUgbWVkaWEgeW91IHdvdWxkIHByZWZlciwgdGhlbiBwbGVhc2Ug bWFrZSBhIHNwZWNpZmljIHByb3Bvc2FsLjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+LSBXZSBz aG91bGQga2VlcCBhbnkgbmV3IHByaXZhY3kgcmVxdWlyZW1lbnRzIHZlcnkgbWluaW1hbCBhdCB0 aGlzIHRpbWUuICZuYnNwO1doaWxlIGNvbXBhbmllcyBpbiB0aGUgRVUgaGF2ZSBhbHJlYWR5IGNy ZWF0ZWQgdGhlaXIgc3lzdGVtcyBpbiBjb21wbGlhbmNlIHdpdGggdGhlIEdEUFIsIG1vc3Qgb2YN CiB0aGUgd29ybGQgaGFzbid0IGNyZWF0ZWQgYW4gZXF1aXZhbGVudCB5ZXQuICZuYnNwO1NvIHdo YXQgbWF5IGxvb2sgbGlrZSBhbiBlYXN5IGNoYW5nZSB0byBFVSBpbXBsZW1lbnRlcnMgbWF5IGJl IGEgZHJhbWF0aWMgY2hhbmdlIGZvciBvdGhlcnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K SSBkb24ndCB0aGluayB3ZSBoYXZlIHNhaWQgbXVjaCBhYm91dCBwcml2YWN5IG9mIHJldGFpbmVk IGRhdGEuIEJ1dCB3ZSBhcmUgY29uY2VybmVkIHRoYXQgdGhlIG1lZGlhIGFuZCBzaWduYWxpbmcg YmUgcHJpdmF0ZSBiZXR3ZWVuIHRoZSBSVUUgYW5kIHRoZSBwcm92aWRlci4gVGhhdCBpcyBhIGxv dyBiYXIgdGhlc2UgZGF5cy4gSXQgaXMgdW5saWtlbHkgdGhhdCBhbnl0aGluZyBsZXNzIGNvdWxk IGJlIGFwcHJvdmVkLiBJIGV4cGVjdCB0aGUgRkNDDQogd2lsbCBhZ3JlZS48YnI+DQo8YnI+DQpJ ZiB5b3UgaGF2ZSBhbiBhbHRlcm5hdGUgcHJvcG9zYWwgdGhhdCBhY2hpZXZlcyB0aGF0IHRoZW4g bWFrZSBhIHByb3Bvc2FsIHdlIGNhbiBkaXNjdXNzLjxicj4NCjxicj4NCjxzcGFuIGNsYXNzPSJh cHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5U aGFua3MsPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlBhdWw8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9u IEZyaSwgQXVnIDI3LCAyMDIxIGF0IDM6MTYgUE0gUGF1bCBLeXppdmF0ICZsdDs8YSBocmVmPSJt YWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5wa3l6aXZhdEBhbHVtLm1pdC5lZHU8L2E+ICZs dDs8YSBocmVmPSJtYWlsdG86cGt5eml2YXRAYWx1bS5taXQuZWR1Ij5tYWlsdG86cGt5eml2YXRA YWx1bS5taXQuZWR1PC9hPiZndDsmZ3Q7DQogd3JvdGU6PGJyPg0KJm5ic3A7UHJvdmlkZXJzLDxi cj4NCiZuYnNwO015IHJlcXVlc3QgYmVsb3cgdG8gUm9nZXIgc2hvdWxkIGhhdmUgYmVlbiBicm9h ZGVyLiBZb3UgYWxsIHNlZW0gdG88YnI+DQombmJzcDtoYXZlPGJyPg0KJm5ic3A7dGhlIHNhbWUg aXNzdWUuIEkgZW5jb3VyYWdlIGFueS9hbGwgb2YgeW91IHRvIG1ha2UgYW4gYWx0ZXJuYXRpdmU8 YnI+DQombmJzcDtwcm9wb3NhbCBoZXJlLiBKdXN0IHNheWluZyAmcXVvdDt3ZSBkb24ndCBsaWtl IHdoYXQgaXMgdGhlcmUmcXVvdDsgaXNuJ3QgaGVscGZ1bDxicj4NCiZuYnNwO3dpdGhvdXQgYW4g YWx0ZXJuYXRpdmUuPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhhbmtzLDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1BhdWw8YnI+DQombmJzcDtPbiA4 LzI2LzIxIDU6NDAgUE0sIFBhdWwgS3l6aXZhdCB3cm90ZTo8YnI+DQo8YnI+DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJv Z2VyLDxicj4NCjxicj4NCk9uIDgvMjYvMjEgMzozMCBQTSwgUm9nZXIgU2x1c3NlciB3cm90ZTo8 YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1vc3QgcHJvdmlkZXJzIGFscmVhZHkgc3VwcG9ydCBl bmNyeXB0aW9uIGFuZCBJUFY2IG9uIGEgbGltaXRlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv YmxvY2txdW90ZT4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPiZuYnNwO3Njb3BlLDxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5ub3QgbmVjZXNzYXJp bHkgdGhlIHdheSBpdCBpcyBkZWZpbmVkIGluIFJVTSBzcGVjLiBNYW5kYXRpbmc8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KY29tcGxpYW5jZSB1 c2luZyBNVVNUIHJlcXVpcmVzIHByb3ZpZGVycyB0byBkaXNjYXJkIHNvbWV0aW1lcyBodWdlPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCmFtb3Vu dHMgb2YgZGV2ZWxvcG1lbnQgdG8gY2hhbmdlIG92ZXIgdG8gd2hhdCBSVU0gaXMgc3BlY2lmeWlu Zy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Jsb2NrcXVvdGU+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDtUaGU8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+cHVzaCBiYWNrIGlzIG5vdCBhYm91dCBkb2luZyB0aGVzZSB0aGluZ3MgaXQg aXMgYWJvdXQgdGhlIGxvc3Mgb2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m bmJzcDs8L3NwYW4+PGJyPg0KdGltZSwgZWZmb3J0IGFuZCBtb25leSB0byBkbyB0aGVtIGluIHRo ZSB3YXkgUlVNIG1hbmRhdGVzIHdpdGg8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij4mbmJzcDtNVVNUcy48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCkRvIHlvdSB0aGluayB0aGVy ZSBpcyBzb21ldGhpbmcgZWxzZSB3ZSBjb3VsZCB3cml0ZSBpbiB0aGlzIHNwZWM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj4mbmJzcDt0aGF0PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5jb3ZlcnMgZW5jcnlwdGlv biBhbmQgSVB2NiBpbiBhIHdheSB0aGF0IGlzIGxlc3MgYnVyZGVuc29tZSBmb3I8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KcHJvdmlkZXJzIHdo aWxlIHJlbWFpbmluZyBpbnRlcm9wZXJhYmxlIHdpdGggYWxsIHByb3ZpZGVycz88YnI+DQo8YnI+ DQpJZiBzbywgY2FuIHlvdSBwbGVhc2Ugc3BlbGwgaXQgb3V0PzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PiZuYnNwOy0tICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1J1bSBtYWlsaW5nIGxpc3Q8YnI+DQom bmJzcDs8YSBocmVmPSJtYWlsdG86UnVtQGlldGYub3JnIj5SdW1AaWV0Zi5vcmc8L2E+ICZsdDs8 YSBocmVmPSJtYWlsdG86UnVtQGlldGYub3JnIj5tYWlsdG86UnVtQGlldGYub3JnPC9hPiZndDs8 YnI+DQombmJzcDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3J1bSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ydW08L2E+PGJyPg0K Jm5ic3A7Jmx0OzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cnVtIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bTwvYT4mZ3Q7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KLS08YnI+DQpSdW0gbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOlJ1bUBpZXRmLm9yZyI+UnVtQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bTwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+ DQotLTxicj4NClJ1bSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86UnVtQGlldGYu b3JnIj5SdW1AaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydW0iPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcnVtPC9hPjxicj4NCi0tPGJyPg0KUnVtIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpSdW1AaWV0Zi5vcmciPlJ1bUBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3J1bSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9ydW08L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_-- --_004_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=9730; creation-date="Tue, 31 Aug 2021 13:06:13 GMT"; modification-date="Tue, 31 Aug 2021 13:06:13 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4QAYRXhpZgAASUkqAAgAAAAAAAAAAAAAAP/sABFEdWNreQABAAQAAABIAAD/4QMraHR0cDov L25zLmFkb2JlLmNvbS94YXAvMS4wLwA8P3hwYWNrZXQgYmVnaW49Iu+7vyIgaWQ9Ilc1TTBNcENl aGlIenJlU3pOVGN6a2M5ZCI/PiA8eDp4bXBtZXRhIHhtbG5zOng9ImFkb2JlOm5zOm1ldGEvIiB4 OnhtcHRrPSJBZG9iZSBYTVAgQ29yZSA2LjAtYzAwNiA3OS5kYWJhY2JiLCAyMDIxLzA0LzE0LTAw OjM5OjQ0ICAgICAgICAiPiA8cmRmOlJERiB4bWxuczpyZGY9Imh0dHA6Ly93d3cudzMub3JnLzE5 OTkvMDIvMjItcmRmLXN5bnRheC1ucyMiPiA8cmRmOkRlc2NyaXB0aW9uIHJkZjphYm91dD0iIiB4 bWxuczp4bXBNTT0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wL21tLyIgeG1sbnM6c3RSZWY9 Imh0dHA6Ly9ucy5hZG9iZS5jb20veGFwLzEuMC9zVHlwZS9SZXNvdXJjZVJlZiMiIHhtbG5zOnht cD0iaHR0cDovL25zLmFkb2JlLmNvbS94YXAvMS4wLyIgeG1wTU06RG9jdW1lbnRJRD0ieG1wLmRp ZDo4MzE1Qzc5Q0UwMjExMUVCQUUwOURCOTBDNEU1RjQ1RiIgeG1wTU06SW5zdGFuY2VJRD0ieG1w LmlpZDo4MzE1Qzc5QkUwMjExMUVCQUUwOURCOTBDNEU1RjQ1RiIgeG1wOkNyZWF0b3JUb29sPSJB Y3JvYmF0IFBERk1ha2VyIDIwIGZvciBXb3JkIj4gPHhtcE1NOkRlcml2ZWRGcm9tIHN0UmVmOmlu c3RhbmNlSUQ9InhtcC5paWQ6RTcwNDM2NUJEQzIwMTFFQUE4RjdCOTI2MkRBNzdBRkEiIHN0UmVm OmRvY3VtZW50SUQ9InhtcC5kaWQ6RTcwNDM2NUNEQzIwMTFFQUE4RjdCOTI2MkRBNzdBRkEiLz4g PC9yZGY6RGVzY3JpcHRpb24+IDwvcmRmOlJERj4gPC94OnhtcG1ldGE+IDw/eHBhY2tldCBlbmQ9 InIiPz7/7gAOQWRvYmUAZMAAAAAB/9sAhAAEAwMDAwMEAwMEBQMDAwUGBQQEBQYHBgYGBgYHCQcI CAgIBwkJCwsMCwsJDAwMDAwMEBAQEBASEhISEhISEhISAQQEBAcHBw4JCQ4UDg0OFBQSEhISFBIS EhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhISEhL/wAARCAA2ASwDAREAAhEB AxEB/8QAvQAAAQUBAQEBAAAAAAAAAAAAAAMFBgcIBAIJAQEBAAIDAQEAAAAAAAAAAAAAAAEEAgMF BgcQAAEDAgQDBAQHDAcGBwAAAAIBAwQFBgAREgchEwgxIhQVQXEyGFFhQtSVFlaBkaFSsiMzJLQ1 Fzeic6OzdHV2YnKSQ5Q4pCVlpSY2KBEAAQIDBQIKCQQCAwAAAAAAAQACEQMEITFREgVBgfBhcZGx wdFSExShIjJyMzQVBhbhQmIj8aLCJTX/2gAMAwEAAhEDEQA/ALy316omNqrhC0LfpDVx16Mw3Kqr kqQUaLEbeRSaazADI3DHv9iCI5cVVck7emaMahmdxyjZxqzJp8wiVVHv03n9iqV/10v5vjqfjcvv nmHat3lBivz36rxRMysykoidqrPloietVj4fjcvvnmHankxivQddF4uCht2dRnALsIalJVF9Soxi D9ty++eYdqeTGK9e/Len2Mo/0jJ+b4fjcrvnmHanlBij35b0+xlH+kZPzfD8bld88w7U8oMUe/Le n2Mo/wBIyfm+H43K755h2p5QYo9+W9PsZR/pGT83w/G5XfPMO1PKDFHvy3p9jKP9Iyfm+H43K755 h2p5QYo9+W9PsZR/pGT83w/G5XfPMO1PKDFHvy3p9jKP9Iyfm+H43K755h2p5QYpztzrE3Ku2vQL aoFi0abWqy4TMKOtVeaRwxbJ1UU3GREchAl4rjXO0GTLYXueYDiWLqVoEYp9vzqQ3t2yGnleu3NF pI1snggqNbWTzCYQScReQ2enJDH2sV6XSaWfHw5hMP49qwlyGuuKh/vy3p9jKP8ASMn5vi5+Nyu+ eYdq2+UGKPflvT7GUf6Rk/N8PxuV3zzDtTygxUo276zXrhu2m29eNuR6HTq9IahR6lCluSORJfJG 2uc260HcM1QdQr3c81TLsq1n29kllzHRItgQsJlLARBWuMebVNN8QiWoz0UlURVnSiquSZh6EwRO GCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRYE3DZZf60ILD7YvsvXLbqONGKE BJ4SOuRIvBezHs6Uw0w+67pKvs+DzraN63lZe3lGS4LylM0akLIbipJKO46nOez0DpZbMuOS8css eTp6eZOdlYIlUmtLjAKEU/qL2CrM1ikxrppyyaiYsMjJjSI7Rma6RBXH2QbTNVy7xJi3M0qraMxa bFsMh4tgq86men22qhalT3Cs2mM0W6LeZKbUY8JsWmKnDaTU+jjIZCjwAiuA4KZrkolnq4XtG1R7 ZglzDFrrBHYexbKecQYG5YYbmRHSQGpDThn7IiYqq+pEXHsi0roQSyqiIqquSCmaqvYiJjFEk3Li vKotPtOkiKSoJiSoidq8FxJaUghqVFfLQy828eWekDElyT4kXAtIRKtkjxKDCFINF06GhVwlL8VE BFVV+JOOINiL06D0cdclh+GHFdUhlxlFy7clcEc8vTlgDG5Ekr7QiJkWhtzgDhZiBZ/ikvBfuYmC Kzunr+eNjf5k9+xSMc/VflX8nWFqn+wVe/XZ+isD/EVj+6jY4v2zfM5G9ar0e1Y7N1ttRQzQSc4A KrxJfgRPTj1UFdQroIaNEvLdLiLZooEvqEslXCCJ7s//AO52x/n9J/bmcaaj4TvdPQsX3FfWzHzR cdN0P95VH1s/kLgibr4r0u17TqdegttPy6c2BttvIStkpOAC6kBRXsL0LivVzjLlFwvCpahUukSH TG2luPKqjp+8O6k+CNWi2kzUKUWr9YjRZhCSASiWRC4fYqKi8MchmpVLhmDIjkK85L1yuc3OJQLe IO7VO9u92aXfTrlMejlRq+wCmUMy1g6I8CVo8hVVH5QKmafHkuV6i1Fs45SIOXW0zWWVJykZXjZ2 KO1e/wDeGJVp8WnWeEunxpT7USQsSWXNZBwhbPMXURdQoi5omK8ysqg4gMiI4FUp+pag2Y4NlRAJ hY67nTvY147l1qvDBum2hotKJlwylpHkNKjgomkdTrhJx9WN1JU1D3weyA5CrOn11ZMm5ZsvK2F8 D1lQ6RvrdDG2t93osGmJPshqK5DaUJCsOc55Wz5qI7qXIUzTSQ4s6JPdVzSx9g4t/YmkapMqQ/OA MsLo8fYoI1vn1TPDTzCyLU5VainNiOq86geHbjNzCJxfMMxVGXgc05Z5Ll28Mek8nS2+s6z/ABgu t4j8Fzs9QXUw+NLcC0rMbauOYVPpLj0xWQlSUccZEW1cqI5o44ybbfpIkRMk1DnJoaa31nWX8IJ4 j8AkKb1HdSNZqFbpVHtOz6pULSkNw6ozGkG5+tvNuuhGjklR0vuqLLncbVVQgUV44l1BTAAlzgDw wUCa/BcUTqi6h594P2BCs62pN4QmDkyKcIysm2W4wTCJXVn8v9E4C+1xIkH2uGMjp1OGZy45eAwT xXxhBd1I6i+pWuxqRJpln2k59Z2gkUyK7IJmaUZ1t55qS5EcqSPNsuhHcVtwgyLT8aZ4uoaYRi51 nDBT4j8FzUvqd6gKzW6xbsCgWP5ta0cplWCTMOK01GBvmuPC7IqACYNB3nVH2E9rLEu0+na0OJdA 3cIKBNcTCxKSepPqQheTJKs+1GSuifEpUEOa6RtT6g2jsOPNEaiqxSkNkjjPO06gXPAUFMY+s6wR 3C+FlsE8R+C7A3+6oSAHnrHteBGJhuW5KmuOxWI8Zxl2RzpDr1QEWgBtklcU17iqKLxMcYmipe8e G5T4j8Eum+XVWqd6wrZad8WUJY7jjgPI4MoISny1qOatc5wBR0cxVDEkzFc8R5Ol7x4W4J4j8E0x +prqJk3S5ZIWnajd1RacdVm0103wKFEbbF01lEs/Sy4AGJkyS6xQkzTjjM6fThubM6EYcLFHivjC CcIu/nVBOCE5Dsq1JI1RwAjiD7imLbyvoxJeb8x1tRn1jO8h8xQHNPDtTPE0VKIxcbOGF6nxH4J4 sHqH3XrV316z7zpFsW9OotsSa9HfFx8IfBtp6K89KSU+CRnAczI0TNE+DsxhPoZTWBzSTEw4WXqW zHRgVatlXje91QHV81sqXVpkCFU6azS3JstkIrzzzLpPnrHVkbJNioL7YEhJinOlMYbnQjC2Cza4 nBWnimtiwRf3/erTv9TW7+yMY9nTf+Yfdd0ldFnwdxWhuqu0Lovfa4KLaNLer1VGtU+SsRgmxPlM qamebpgOSZp6ccLRaiXKn5nmAgVVp3hrolY8h9M++FbkDSitJ+khO/NOTp8mI3GYA+6Thq264aoK LnpEVVexMepdrFK0RzxhsEVdM9gF63DutUodgbDXIVVl89KTa79NCS4uk5EpyJ4NlOKqup10h+/j x9E0zapsBe6O6MVz2WvUI3htqg0/phq0uPSoEeoMWzAVJbUVkHUPKOikhiKKirmvFFxcoJzzXAEm GY7eVbZbj4u9YbtURO7bbAxFxs65ShMCRCEhKcyiiSLmioqcFRe3HsJ/w3ch6FfdcVtrqvoFBpth W+/TqVBgvOXlQWjcYistkTZunqBVAUVRXLinYuPH6LNe6a6JJ9U7VzpLjFWHult9tJULVJ2+49Ot 61aRKYqFQkALMEXRjqqiw46AiehwlRCAFQj9lO3FKjqqgTP6yS42DasGOdGxUi/uZtNd+5m0Ns7W MpEh2zccpxxlmmuU+NyTpj7Qk3rBvVmvxZ+lcdcUVRLkzXzry3GO1bjKeAS5XFvc7tBRgoF57t6J bFsvyPIqY4BSUkzJABqIYYIXPMBb7upNAZqS+hU5WnCodmZJ/deeLl2LVKDjY1cdg70bN70uP2dT 4qLJFgjSg1qntspIjjkhkyBcxpxBzTUIrqROOWWM6qgqab1yd4Kl8p7LVTFR2ag7T9Tm3Uu2wJmz rtnTHYMVSUkgy2Ib3OjARKqq2omJtZ9neHsRMdaXqBqKGYH+00Dfbet4nZpZjen7rMoNVuus7W2z Q2xfrFeqdThwxNVRsTdbjZuOKPFAbFFM/wDZRcavt+a2W2a91wA61jSuABJUyjW1sn0r2fHq9caC ZWZRAwdWdjDLq9Tl6VIhjt8eWCJmugFEAHLUufFabp1TXzMrbsLmgca1lz5hgi3N1tieot5+x6hS VfqD7JuM0yuQgZefbb4mcR9ozyNtMiXQ4JonFOCKuE6iqqP+wGzFp6VLpb5dqyvfu1r+0W91v20L zk6hz6xSKhQZjyorxxDqLQE06qcFcZNNBFw1Colkirj0lLWiopXOuIBB5YdatsmZ2Er6UY8GuYm6 H+8qj62fyFwRRrd3+XFf/qG/79vFLUfl3cNq5Wt/Jv5OsJv2M/ltTP66X+0uY16T8uN/StP298m3 lPSq+qyRfeIgeQoHO57Xj+Tlp5vILxGenhny/b+PPPjnjnTIeeGXfzWrjTsv1Zvh3xEea30XqR1f 3gfNp/lCxfKvFP8AgdXgM/D8wuVnr72enLt44szPPZjlhCNl1yvT/qviOyQyxMPZu2J3sf8AjJ56 P128P5FyXNXL8Hq5uSaP0HexupfN5/7PZ3Kzp/1Dxf74ZIfx6ln2oaP4C7w8xFJvw8DUiLkqp4ks 8lxn9p/MHlHQ5cz7a9mdu/5Jlpbe8csreplCui0KpPSm0EKzRzpEsH4VMuOIzT4MmSbhjz0FsW2X PCOAoqushXtx65zpMXRB2wtwJPCK9OI2KMVODunEtGzZNLqdrzvPrppEul0+kUt4mxqfmLr0Jspm bjBlGf1FLYVQfEVQHDcyxuBlF7og2A7dm39Nii2AXm29pd0ZtR3JsilXfCt/zOrUV+tVKnxphjVS riSJMR6K7EJCYiHz3EeVcxRPiTEzKmUAxxbGAO6EI70DTaIrnuqvbq2HRZG8zVStan1uZTqJGqM2 kUdGp8pmZLfFkHHJGpo1RaSguly01t5ImS9kypcp7vDgYRN54h2qCSLVIZy3xbAVu6J152TFuDa6 PT5FRIbVluzSh12K4VJpySBTiwqy3GGmwJOXkPMLQI41NDHEANdB/H3TaetZWgcir2v21c9ClM36 NZt0Y+87YW1RPBR3jaqdOuCExHnyGmDdcdjJGQxZeJ0lPm5onbi0yY1wyEH1LTxQNnLG/kWBBFuK mt5bY7zVegsxp1ZotQj0FypTJVRpsByNUKjVrNc8pp4VCQnFx51sFGE4SoCaS5nf44ryZ8lriQDb Dmdaf1WTmuIRV6huPUbgqtOev6z7uq9qw7sk3lba02T4YHBjMv1ODKjPoCSmC5AAy+2Yo24Koi8c AyVktYQHZQD0f4QkxvxXHRLu3rrdJti7G7oops3LRrpuWBBmQFJhkbYqDMtzmtiotK4LjADDcH9C yKtrwXGT5clriyBsLRziHXbxoC6EV2Vaxt2oVwv3JCuij1i85diz4j1YhU+VHkVSKhRIubE5EFuT JdSW02zUwNCRG++nBFxDZ0otykHLmuwv2bLrkgY7k62/Qd525MChWXeVr3FOtuTOtusVtaa+Epmq 2/EekMUaoSpaAUlppH3FjSB7vMBFJV0CmNT3SIlzmkRgdx2/pxqYOuTdY1NuCm7jXIxuTDdu+rSd pWZFVpEcHGahMjkxGBqJJNdRlNbRtOfITMlUNSIqpljbOc0yxkMBnsOzb6Fi0W24LRWwzlEnXPc9 VpsNhyfJhwG6jW6TUZVSpMt4DeRUccmRIZDOVMnZWgVFzWjhZGRZ8ytzBrQbrbCIHpNmC3S71fGO ctqwRf3/AHq07/U1u/sjGPZ03/mH3XdJXRZ8HcVqvfLdKRtBZI3bFpYV906jEg+EcfWMOUlSRT1o Dns6ezLHmtOohUTchMLCVTlS85gs7udc9eUCRqxoYu5dxTqriii/GiRkXHdH223vnm/VWfJjFUPv BvPfW7rRldEhmJR6eDj0GhQEIIbTvLIeaamqm64iKqCZr3c10imeOxQadKpz6l52m9WJUprLltne 9M+lyuZJn/8AGYKrl8CeHVV+5jyenfPN949aoSviDlWBLUVBu+2lXgiV6k9v+PZx7Sf8N3unoXRf cVuzq9/l5bn+tqD/AHp48ZofxXe65cyTeUl1oIi7MLmmeVepKp6+cuM/t75ncVnS+2sj7BfzvsP/ ADYv2ORj0+qfKv5OsK7O9gq/+uzLwlgKqcVnVVEXL4Y7K5Z/cxxPtq+ZyDrVaj2rPmxDFRk712IF LRwpTVYR53l55jEaYdWSRZfJ5aqhevHb1QtFK+OHp2KzOIyFbk3eOOl/bNtll4s7tlE18PLGjTeZ l91Rx4+h+FN93/kFzmXFJ7inFb3z2aWXpTX9bAjKWWXiCprOnLP0qKGiYmkj5WdD+HSVkz2Hbk3d Qk/YunPW8/vTRpFZ5yTGqI83GmSG2yyaN8F8KQoJEiCqauKoK5di4z0ttW7MJDoXRu61MnP+1VLQ 9xui21qxCuShUGbS6xRXPEQ5jdPqupo9JApd41Fe6SoupMsdObRalMaWucCDxtW50ucRAqP73bvW Hu3e21r9llLfk0GvsJOelRHYv5mTNh8sBV1EUu82q8OzG7TtPm08qb4kLW4x2FZSpTmNdHBbux5B UE3w/wB5VH1s/kLgibr5oEq6LUqdBguNR5VRbAG3HtSNiouAa6tKEvYPwYr1ckzJRYLyqWoUzp8h 0tthPaqigbPbq06CNKhXazT6YOrKPHlTAAUNVIshFse1VVe3HIZptS0ZQ+A5SvOS9DrmNyNmgN4i 7sU+282ppVim5UXHyrFekioOTXB0C2JZKQtBmWWa9pKua/FxxfotPbJtjF2K6+maMyl9YnM87exR qr7f7vy6tPlU+8BiQJMp92LH8XLHlMm4RAGQtKiaRVEyTFaZR1RcSHwEcSqM/TdQdMcWzYAkwtdd zJ3seztyaJXhnXRco1ulCy4BREkSHczJE0lpdbFOHrxupaaoY+L3xG9WdPoayXNzTZmZsLonrCh8 jYm5n9tr5stahTfHXu3EbiPan0Zb5DyuHzV5epM0XJNKLxxZ0SQaSaXvtHFv7U0nSplMHhxBzQu3 9qgybEdTQM0piPeVnwgt86YcY40Fxl2T5MOmnhOdCHrkgx7QNuFp1d7LPHpPOU0ScrrY+m+Fti63 hvxC/YGxPUxTGWGoF32ZHcimwazBpypKklEB0IiynkhIryxkeMmFJMwLSSqSimBrKY3tdz/rt2p4 b8QvcTY7qdiELrt42ZWZYt09tZtWpy1CUZUl11+A+bj0JdT8c3zVt3LUnD8VMQaulNmV3PjftU5H 4hIlsH1JPwH6ZUrpsi4IM6OxGkt1emlP5oxnJDrThc6Gqc1DlvFzctWZfFifO0wMQ1w5DDr4lHhv xCaap0vb/Vpm4GKndtrPtXuzR2K6gtSQV9ugZJT0BUiZtq3kmpR9v5WM26jTthBp9WMN9+1QZTjt Ta/0f7zyYltQXrmtgou3yulboIktFjq9MGoHzFSJm7m+KH3/AEcOzGY1STEnKfWv6MVHguxUim9P nUtUSqRSr3tn/wA+gTqZUBaaktC5GqU1yovqiDF7rqSHnDZdTvN6lQeGNQrqYQ9U2GPMIY4LLw34 rt/gf1OeKYmLd9lE7HSX4htaaqM1B2cwEWTIqLQwhGU84yCNq458nPhxXGPnKbuu57uS2xMj8QuN OnrqNCkzKHGuuzKbTqh4wQSFAKO7T2qigeNYprgQs4jMhWxJ1pvgRZr2rjLz1NGOV0eXC6NtsE8N +ISs/YTqVqEOVTyu6zadCqceWxNZpsAoCPnO5PiJZeHhCiSi8O3k+OSjkulEzXECtpgY5Xc/63J4 b8Qk6p0+9SVYBwJl4WiyEqPUo8wYcNyGks6vHGJNlyUYhjzJbrIoHiS7w/JyzXEtrqYXNds9F227 iQy34hPNr9P287N03BeN3XjS5Fz1y037chVynLJblxnURtIz65sNd4UAkN0S197UneyxrmV0nKGt aYB0YFSJboxJVtbdWHd1qV2dOrtdKsUWRSoMSmU05UqUVPcBx5+Syj0nvPti46osPOfnuUgg5noR Vpz5zHtAAgY8/DmWxrSCrKxUWa+f250+FSesZmq1N9uBTaZX6BJmSniQGmWW4bCk4ZLwQUTtXHtK NpdpsBaS13SV0ZYjJ51ZfVhuXt9d+1YUi17lpVwVQa3Tn1hwpTb7vKbI9Z6QVVyHPiuOfolFOlz4 vaQIG8LVTS3B1oWMcesV5eHmkfZcZJcheAgVU7UQkyxIMCi+hW0W9O2u423kK27oqFMgVpimN0yv 0GqutNC+gNIw4YI+oi608iak055IuS8Ux4av06fInF7ASIxBHC9cybKc10QonNDpD2crUKrUyLS6 tdIymUp0aLMcqpQidcRvnrzXnWY4MousnDVFFE7vHJMWW/UalpaSQ3bZCPWVn/a8W3JPqd3N28uu yKFAtq6KTW5sS7aLMfYiS23jbjMOmrrpCCqqCCLmS+jDSKOdLmOLmkDKdiiVLcDckuqzczb67tqS o9rXPSq/VPN6a/4OFLbfeVpp1VM9IKq5CnFVxnolHOl1GZ7SBA3hZU0twdEhZy2C/nfYf+bF+xyM d7VPlZnJ1hWp3sFbi3uuzaukt0K1d3oDEu17ydkg1NlN8yNElRBbMCdUfzjWpHFQXg9lfayRc8eN 06RPdmfIPrNhvjwuXPlNcbW3pstWL00bPQpVy25UrcoozGUF6qeZjNlOM56kbbM3XnVFVy/Nt9uS ZoqpjbONbUkNeHHihBZO8R9hiqCqW/NL3D6jbJuN6Qlv7dWVJlNQJE8uQhc+K6j0x9C/R8wkbbbE uKCnHJSVE7TNLdJontve6+HLcrAk5ZZG0p26rd0aDVqjt3Xtt7lp9XrVo1GdOF+A+3JSM6gx1aV0 QVe4agQqK+0maY16JRPaJjZrSA4AW2YrGnlm0OCsWg717Ib9Wm3a25fgKLVZGgplFq73hwGS2nB6 DMVQRclVdBCYuIi5EnbnQm6dVUkzPKiRiOsLW6S9hiFwRtsukbbSSNy1SrUucUQ0cjN1Ws+Zg2ac UVuIhnzFT0ZgX38ZurNQnjIARyNh6VJmTXWLK9Rl2fO3piT7AZlQ7OnXTSn6axKbRo21cmsE8gN9 oNc1SVkS7yBkionZj0ctswUpEz2g0x5j6cVbAOS2+C+pOPnq5Sb4f7yqPrZ/IXBF5uGlee0Gp0Xm Ex5rDfio6DjjRCrzZAiobJCY5Z9oqi4zluyuBwUERCgMXba5Ga5R6kdaAQpdCZprsoDk+JB5uC7E IWQU+WTZuuDJUnMz1tinHtGwahuUiF5j6eAWOUxTcztBXPqvEphVdKZWqfUXZcR2FKmrFYZejtsP AoukpO89WyMxPuiTx5Z5d7M1Tc0YWQ4uH+FGQwUnuW07kuKyKbRJUqA9W4kinSKigo/FgTEiPA46 zkyquADiDl6fjTLhjTLmta8m2FvKpIJCjru1VxHb7tIfrXmBuUBimAKypkcAkNVI5oqjmb5q02BC wiGhE42OlxVQlxtFS3NGG2PogoyGCdWLLvsLrt64Xa/DGBb1NYpUujx2HmY8tt1n9dfROYSNmrwt EwORaQb06u8uMDNl5C2F5jHoU5TFNdmbWXPb1JhU2oVwJBQ6i7McJtyUamDlEdppd5wkzUnzF/Sq ZDl2kffxnNqWuJIGzrioawhOjFhXDMokCnV2bGceh2vNoEgGHZRtPPu+F5EpSNQPNPDkpZ95FLgX bjAzmhxIG2PSpymCVp+2aQahZ8tJroMWpTUi1OG1IkoxPksiJRnzbI1QlacN80UuK8zvashyh1RE OELzzcLEDLkrV7HrNQv87qYqAxYDtE8sa0uOJIhv5S85DLaiTZKvPD0j7PHVwwbOaJeWG2PQhbbF RmibX3nSIMphqdTY7zL1BlQgYkVHlS5VIeVyQ9L5pGQFMFUF1Q1+ymrmcc9r6hhNx24bcORQGFdl P20vSDLs+UlzNqFjtojsdQkGM9ya8fmKOkTvsoyQhG1iaiSau7jF1Qwh3q+16MP1QNNicqPYlwMs 0GHWagxLh27PqxPC25JJZ8GoMSG2xeQ1TIwJ9MxVSHIe6qcMsXzm2kC8DcQpDSuKlbRrCoVpUt+e fPtia87VjYkSwbqMV5TdJhxCcJTRXgjH31/5aindIkXJ1VFzjC+7i4WqAywJ5viyardT8vwlR8BE n0R+lG1zH2yQ35cd5XUJok0ry2jBCTvIpfBnjXJnBl42xWTmxUPqu0d5VGGsd6vR6hJWqViSEqQ5 MaJtmc0yzDfRI5AnPii1qyTSBGqqiiqquN7apgN2wYbL9xWBYU8ubcV9ateE4psaojdlPZhwn5Ts gXWTbiRYxKYMiOnM2DezaMe8qcE4ljX5hsGiFx7VllNql1kUGoWzbsei1SWNVmw3H+ZUtTpOzNbp Gkh/mkSo65nqdRF06s9OQ5Immc8OdEWLJogFIsalKMEVFb1dNFtbt1EbkjVB61rtBgY7s5poZEeW 03nyxkMEoZqGeQuAYkg8FzTLLradq76cZSMzejkW+VPLLNizvWui3damoR0aoUG4xTPSKOvwXVT4 xdbcD+njvS/uGnd7Qc30q0Ktu2KgdW6et76KuUqyZ81E+XTnY00f7F1S/o4uy9VpXXPA5YhZiew7 VCKla910UybrFu1qlGHtJJpsttE9ZK3l+HFtk6W72XA7wtgcDcUxPvQS/NSia4L+je0oqL6jxuAO xZJRlYwhpjq2IehG9OX4MQY7USiIPoRMQiEFE4oiJgisPYd1pjemxXn3AYZaqpEbjhIACnhJHFSJ URMUdTEaZ/J1hap3sFXv1v1SmVGHYowJsecTE2pq6Md4HVBCjtIikgKuSLl6ccX7bY5pfEQsCr0g vWP0ahsmrqA004vaeQiv38epiVdR4yGS6EfaMvxUMVX7yLhlKJ0p9Cr1VJApNFqlTI+A+Fp8p5F+ 622qY1umMb7TgN4UFwG1TOm7C7zV1RajWJVgbcyyOeDMNvJfh8S4C/gxVfqdM2943W9C1mcwbVOK F0Y7uzF1TW6Baor2k7KKQ5l/uxWlRf8AjxSmfcNOLszt3atZqmcZVjWn042ztVd9s1S+ai/e1YkT mypcGKw3Cpsd9sk0SHyedI3VbNRIAzQc0RVReCLQn6s+oluEsZRC03nkC1unlwMLFsbHmFSTdD/e VR9bP5C4InHBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIjBEYIoxW/4f ZF9Y/Icvl+YeD/DzsWJfjftzborIZtirSve6ZmXnf8PtXytPlur+x44vyvqH7c/pW0eLsioLM9xH WvO+qurPj4fxWX9hwxdH1X+XoWwePxrj/wDwT/6D/wC6Yn/tv5f6qf7+NeC9wjSuvyDR6c/NMsT/ ANt/L/VYnxtqWh+4Tq/Vvqvnwz5njcvu83h9/GB+q/y9Cxb4uxTehe59mHk31A1cNHM8Bn/4jjit M+o/uz+lD4u2KsuifwryH6ufVjLhp8v8B9zLk458zx/35t8VqObbFTEdOlNGWjJNOXZl6MssVVgv WCIwRccvy7Ux4/kauYnhufoz5no0a/lerjiRHYpXZiFC4Yook+aSOIZGrWoEFUUMg4ZqvBc/iwRd 2CIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRGCIwRf/2Q== --_004_DM6PR19MB3930B65E9C6CF902DF8C50C7FCCC9DM6PR19MB3930namp_-- From nobody Tue Aug 31 07:16:07 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10CD73A10CF for ; Tue, 31 Aug 2021 07:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 2CEqF2CxNMPR for ; Tue, 31 Aug 2021 07:15:58 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2074.outbound.protection.outlook.com [40.107.93.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 722CC3A167F for ; Tue, 31 Aug 2021 07:15:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=l/zyX9B8Y8q8ryw9dYF8qs+obTujlaFZ1dRMm9Al38Q3Kga1WNCneYuxKCh8KeAChYjMumUp0B+e53Ql3no6+Gwisu5oB9oImjshX7+NEspIXs7HIZgRjTIfvuKYFi9K8xWQDpYY2w7wlTPJCi0d96FupUaxk0YvJoLZvRs9S1YA9bx4ltOlLdlVaKoArdYlHYV5dXN0SrHvjxSINa9o7rUUkHt/8kf51bltva4Wy5yDPDI0uk/e4aHZZIHmTDBuF5ZU4EnUg+UWfgiZ/uFyOmDoaY1irwIBNJVrddcOcXNPziu6/WhODIWzT5z9HgUEY23j5t9hrVZMnF/5tZi3XA== 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=bsUcxQ3RD97kk7jCszbmstRdrKXYlmcjwKBCgeDOYbE=; b=kRcfYBj37z/09Bh2SdckZxgus6jr6K1fkGsp9vVa4MTK5bloaQLvN+V+mtVEzEL8CCDuFAROZv11S5+fVDkWxn9CysTeK2WhA/o2LknR56uTYuSEsxiJ9P0ArXiaLOgAHo8/SMH/Z8YkBdWKyGV+b0OsBCgWll3yyBA7bTLJGH2nWSDYdqxyBRnN3awUOXNvFo3p23J++0LpoVHYNdctOxLfMEafGmBLVWiZiSm0uYR1TZF0+8dImle3Fs4FWz1oyCBnQIfumLfua0A7Ajy7ylhzb/oCLgTH+Gz1ueS46XrxYaHBX1A/U2vhURWZBrzdmtBJ86wKehL51B5THVNHhA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=bsUcxQ3RD97kk7jCszbmstRdrKXYlmcjwKBCgeDOYbE=; b=BGArbcRugbnAoVtokQ3fiKqjgEmBm0IoNdiqNkSS4qeZjKvyAu/MH7YIXvOLgXVBygTDTxhdszlaxh32nsRs/k6hUD4dfizCgRjlokhVAP3WFpW+xm0QQX/pGlznbQto0wAv6aEXr7lZ6DToY+oAoAWVj1S3W4m1jc0vn0nbBKU= Received: from DS7PR03CA0186.namprd03.prod.outlook.com (2603:10b6:5:3b6::11) 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.4457.24; Tue, 31 Aug 2021 14:15:42 +0000 Received: from DM3NAM02FT048.eop-nam02.prod.protection.outlook.com (2603:10b6:5:3b6:cafe::39) by DS7PR03CA0186.outlook.office365.com (2603:10b6:5:3b6::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4478.17 via Frontend Transport; Tue, 31 Aug 2021 14:15:42 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by DM3NAM02FT048.mail.protection.outlook.com (10.13.4.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Tue, 31 Aug 2021 14:15:41 +0000 Received: from MacBook-Air.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 17VEFdM8024454 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 31 Aug 2021 10:15:40 -0400 To: rum@ietf.org References: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Tue, 31 Aug 2021 10:15:39 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.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-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 46c4a8b8-f269-4bb3-2896-08d96c89d0a8 X-MS-TrafficTypeDiagnostic: DM6PR12MB4452: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4941; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hQh6hPkNZedfngVA/DYnXLNGI5H73iRPPuh/QsX+LY/ABjjYGsz5neiLkLWLOb8Itoe+Ws26vdnZ0hO9O1DCN02xmSoj0sLRxQY/zDTc7JU57UgwYfAKr94IVWloMHEepHrizq9H3yLSGaDOTsWEyiTeoXSTYuncpqkqgnsKVr+EN0X5aRaq8zDPHBKx6bESGkjqtmB23HtcWx0/iO+nRBfwlO31PbH+lO6tYTB1AW04A08EzGtQV0+4rj3XDlv0tkx3epu7FkkmV4x1VWaSt4PJDgEDL39UxWnFuKrYGzjZmx1CpSJE969cnQfnVlc+K3HAkj+pURxpBMo1VnKF5q3fKSF97TmZP/qRaZ0k6cz/YrikX9OVBUZuqE/uouhZTdZ6vFXIzMgAodoK2Gg4P8QtVeVFAnY4XtfZA8RV1+W3fpZ9xVWFd+jsZUvxDEndFNO6HJ0AtFSuBAqz15dOZ9X6ioPw7QL2J2O4MR/bPVQXUuTMd0UJEcBEMIlNyC2BptDyGzx+I6bk8TLw1xxcKM5MsukAWKO++kkqoWCPvUGof1oF/fSM6KpyGUQlDb6LlnV9KchCOkJijVU3AtOTQ29DAwOhWmkXmOa1x/IdKIjxEcrYiAsgSTJQb3BxPEOHQQgCx/7gKYqvZ03XsFl+ueaIX5Fc7KgKfl9pXE1kJRjCkmohLXXDDXSLIDHtTAM39zdPVAdzpgsyKUWwRG9aqN6A7v/Vfu7AsaizENTcXLQ3cqvTmWF4U5xDp2QXUEEjRms2/0Z7n4bW3P4vOUbiNGnJWhntqnj/Yet+5TXWvVu5nsOz3IrXWySZ+K6HMZs8 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; SFS:(39860400002)(396003)(346002)(376002)(136003)(46966006)(36840700001)(786003)(36906005)(31686004)(2906002)(83380400001)(70586007)(7596003)(5660300002)(82310400003)(26005)(66574015)(956004)(47076005)(478600001)(36860700001)(31696002)(53546011)(2616005)(70206006)(82740400003)(356005)(186003)(30864003)(6916009)(75432002)(336012)(316002)(8936002)(966005)(86362001)(8676002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2021 14:15:41.4357 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 46c4a8b8-f269-4bb3-2896-08d96c89d0a8 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-AuthSource: DM3NAM02FT048.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR12MB4452 Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 14:16:06 -0000 I was involved in adding OSRTP to the VRS Provider Profile. This was an upgrade from the prior version that had no security. The bid down risk was understood. The point was to provide a mechanism to phase in the secure mechanisms while not requiring a flag day for all providers to upgrade. It is important to understand that the connections between providers is a small closed community regulated by the FCC. It was my expectation (and I think also the providers) that this was a transition step, and that once all providers had upgraded to it then a subsequent version will remove the optionality. But that is the private world of provider interconnection. The situation with RUEs connecting to providers has quite different constraints. For one, it is a new interface being implemented for the first time by both provider servers and RUE developers. So the need to phase it in is different. It will be realized as users migrate from proprietary devices to standard RUEs. Also, these connections are over the wild and woolly internet and so more concerning for attacks. Thanks, Paul On 8/31/21 9:06 AM, Ed Sayers wrote: > Hi Brian, > > I would say that OSRTP is more a way of negotiating SRTP. It allows > older endpoints that can’t/don’t support encryption to still potentially > participate in a call. > > Yes, the intention of adding OSRTP to the updated Inter-Provider > specification was to allow the possibility of end-to-end SRTP-DTLS > encryption between the endpoints of two different Providers once > supported (or passed on) where possible. > > We thought this to be the best balance between adding burdensome > complexity, calls failing out-right or some devices not ringing, whilst > still allowing encryption whenever it possibly could be. > > Cheers, > > ** > > *Ed Sayers* > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > > purplevrs.com > > > > Purple is DEI certified! > > The information contained in this e-mail message is intended only for > the personal and confidential use of the recipient(s) named above. If > you have received this communication in error, please notify us > immediately by e-mail, and delete the original message. > > *From:*Brian Rosen > *Sent:* 31 August 2021 13:30 > *To:* Ed Sayers > *Cc:* Olle E. Johansson ; Paul Kyzivat > ; rum@ietf.org > *Subject:* Re: [Rum] encryption > > Are you proposing this in addition to requiring DTLS-STRP or instead of it? > > Would two users doing point to point calling through typical providers > that anchor media reliably get a secure connection hop-by-hop if both > users and both providers had conforming implementations and the > providers implemented the new inter-provider spec? > > User 1   Provider 1     Provider 2     User 2 > >      DTLS-         DTLS=          DTLS- > >      SRTP          SRTP           SRTP > > > > On Aug 31, 2021, at 6:30 AM, Ed Sayers > wrote: > > Hi, > > Inline below.. > > > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com > > The information contained in this e-mail message is intended only > for the personal and confidential use of the recipient(s) named > above. If you have received this communication in error, please > notify us immediately by e-mail, and delete the original message. > > > > > -----Original Message----- > From: Olle E. Johansson > > Sent: 31 August 2021 11:12 > To: Ed Sayers > > Cc: Brian Rosen >; Paul > Kyzivat >;rum@ietf.org > Subject: Re: [Rum] encryption > > > > > On 31 Aug 2021, at 11:29, Ed Sayers > wrote: > > Hi, > > Thought I'd split out IPv6 and encryption as separate points.. > > For encryption, the US VRS Providers recently created a new > Provider Inter-Operability Profile that now specifically allows > for encryption and ICE, amongst other things. > > Whilst we all agreed that SRTP-DTLS is the right way to go, we > decided to specifically adopt RFC-8643 OSRTP, because this > allows for the greatest flexibility and greatest chance of > supporting end-to-end encryption, while still supporting a > heterogenous range of devices. > > > > OSRTP supports SRTP-DTLS. It’s not an alternative. And it’s just an > informational RFC, not a standards RFC.You still have to implement > SRTP-DTLS so you can use that fully in a situation where all devices > has support. > > EdS - We know it is not an alternative. It simply revert the profile > to RTP/AVP, while keeping the fingerprint and setup attributes. This > means that an endpoint that sees the attributes can replay likewise > and agree SRTP-DTLS. Old endpoints ignore the attributes and can > still answer the call. > > There are other ways to construct the SDP if you want to offer both > RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so > one need serious consideration. > > EdS - Typically, older endpoints also would not support this, which > is the benefit of OSRTP - It is backwardly compatible. > > > > Whilst it is true that encryption could be terminated on the RUE > interface proxy, > > > Aren’t you mixing signalling and media now? > > EdS - I am missing what you mean here. > > > any Provider that wants to allow encryption further into their > Infrastructure is generally faced with the potential need to > fork calls to various devices, possibly only some of which > support encryption. Using RFC-5673 alone would mean that older > devices that do not support encryption would reject the call as > unsupported. > > > Isn’t that one of the benefits? A user needs to be assured that the > call is protected. As a provider you may need to have gateways to > the old world if you need that, but still keep the first call leg > encrypted at all times. > > EdS - From a customer standpoint, having a range of devices no > longer ring is not a benefit. Using OSRTP as a migration path to > support end-to-end encryption while older devices can be gradually > 'aged out'. > The user might otherwise have an illusion of security - terminated > at the RUM proxy, while the endpoint on the other end is not > encrypted (because it cannot support it). > > > > Using OSRTP is by far the simplest and most convenient way to > fork the call and still ensure that the widest range of > endpoints can ring. > > > But it doesn’t deliver any guarantee of any kind to the user. > > EdS - It provides a progression where more and more endpoints over > time can be encrypted. Precisely why we adopted it on the > Inter-Provider interface. > > > /O > > > Cheers, > > > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC purplevrs.com > > > The information contained in this e-mail message is intended > only for the personal and confidential use of the recipient(s) > named above. If you have received this communication in error, > please notify us immediately by e-mail, and delete the original > message. > > > > > -----Original Message----- > From: Rum > > On Behalf Of Brian Rosen > Sent: 30 August 2021 22:24 > To: Paul Kyzivat > > Cc: Chad Leeper >; rum@ietf.org > > Subject: Re: [Rum] IPv6 and encryption > > I don’t think there are ANY alternatives to SRTP.  There are > alternatives to DTLS-SRTP.  There are moves within the IETF to > deprecate SDES, specifically.  There is push back on that, but > it’s an ongoing discussion because SDES isn’t secure enough. >   Since all providers I know about anchor media, this only > affects the initial hop.  Users really want to hear that their > media is protected end to end (at least hop by hop) but our > document doesn’t require that.  Again, we need a STANDARDS based > solution, and we have to live within the constraints the IETF > has for new standards with respect to security.  Like nearly > every organization, the IETF is much more security conscious > than it was, and won’t tolerate bad security although it often > recognizes the necessity for backwards compatibility as long as > it’s not to a known insecure mechanism. > > I really think this is a “step up to the bar” thing.  We’ve > spent lots of time and cycles implementing things that turn out > not to be secure enough, and we have to move forward on things > that are.  DTLS-SRTP is one of those things, as is IPv6. > > Brian > > > > On Aug 30, 2021, at 5:06 PM, Paul Kyzivat > > wrote: > > Chad, > > Welcome to the RUM WG! > > On 8/30/21 11:51 AM, Chad Leeper wrote: > > - While WebRTC w/ SRTP/DTLS (encryption) is an excellent > idea going forward, it can't be a "MUST" requirement. I > agree with Roger Slusser that mandating compliance using > MUST requires providers to implement significant > development to change over to what RUM is specifying. > > > The requirements in this doc will apply only to devices that > claim to > conform to it. Presumably you could continue to support your > existing > devices using whatever mechanisms they currently use. So the > implementation burden is only on the server side, not the legacy > device side. (Of course the FCC will have a say in this.) > > One motivation for the webrtc requirement is so that a RUE > can be > built on top of WebRTC. E.g., it can be a server that > supports deaf > users using any device with a browser. Such a server is > effectively > just signaling gateway that can establish a p2p link between the > browser and the VRS provider server. (It does have to > transcode RTT, > but that is less of a burden.) > > When defining a specification for an interface that is to be > implemented by independent parties it is necessary for > essential functions to have at least one mandatory to > implement mechanism. Currently there are no standards for > connecting a RUE to a provider, so we need to pick > *something* to be mandatory to implement. If you have an > alternative for the media you would prefer, then please make > a specific proposal. > > > - We should keep any new privacy requirements very > minimal at this time.  While companies in the EU have > already created their systems in compliance with the > GDPR, most of the world hasn't created an equivalent > yet.  So what may look like an easy change to EU > implementers may be a dramatic change for others. > > > I don't think we have said much about privacy of retained > data. But we are concerned that the media and signaling be > private between the RUE and the provider. That is a low bar > these days. It is unlikely that anything less could be > approved. I expect the FCC will agree. > > If you have an alternate proposal that achieves that then > make a proposal we can discuss. > > Thanks, > Paul > > > On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat > > >> wrote: >  Providers, >  My request below to Roger should have been broader. > You all seem to >  have >  the same issue. I encourage any/all of you to make an > alternative >  proposal here. Just saying "we don't like what is > there" isn't helpful >  without an alternative. >           Thanks, >           Paul >  On 8/26/21 5:40 PM, Paul Kyzivat wrote: > > Roger, > > On 8/26/21 3:30 PM, Roger Slusser wrote: > > > Most providers already support encryption and > IPV6 on a limited > >  scope, > > not necessarily the way it is defined in RUM > spec. Mandating > compliance using MUST requires providers to > discard sometimes huge > amounts of development to change over to what > RUM is specifying. > >  The > > push back is not about doing these things it is > about the loss of > time, effort and money to do them in the way RUM > mandates with > >  MUSTs. > > > Do you think there is something else we could write > in this spec > >  that > > covers encryption and IPv6 in a way that is less > burdensome for > providers while remaining interoperable with all > providers? > > If so, can you please spell it out? > >  --     Rum mailing list > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum > >   > > > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > > > From nobody Tue Aug 31 07:20:02 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA6B3A16C2 for ; Tue, 31 Aug 2021 07:20:00 -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 mwY2LyfxFX9j for ; Tue, 31 Aug 2021 07:19:53 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 5F0103A16C5 for ; Tue, 31 Aug 2021 07:19:53 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id a15so24993551iot.2 for ; Tue, 31 Aug 2021 07:19:53 -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=8N9IPKJ1yhS+ZQ1kc9FZIf76AECgMNDOTw/+BsCASdU=; b=0HtXTSq4OQjYORgW4NnJDgOefVG2K6D3W0QGLbr/me2fLNDcJV9t8+OmrU8LeMEPuG XrSo5qMXU/8/tny2/gla3Pgx5ieDKTc+hMFxtSS78jqbw0nXzXkbF8bg2YrRxetbzcHX lxGM5halhMaE3j/oqF9TB4MmRHIdm0uWeWqjqQv4WktmNeJEHtK1YdZJl4k43UXH4k7C 0sq/AmMsVE4ghXCWUqEd6BtMk4zC/UdlHYObE7y+l87bLrz7XwMQuvtOu6/WGrvjLHxU hiFscuM985vaEdXQOsJiYiZb0CwtmVAP0iYIZXvmx4jzMZLgDajz/wWAKwImp+7+ZIB9 jpbA== 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=8N9IPKJ1yhS+ZQ1kc9FZIf76AECgMNDOTw/+BsCASdU=; b=gIGPzrhJjNPU1WmiPIosnwaaJsAUQvnCvXBs2wQ0t2E+vXsjLnBT93cJs6QwX0uu54 QkPM7Lr7An5JAWa8EDvi5b2mE2dje+mnqoLPIrhIkd6ILh22e1URSL6Fel5HO0BkBbtM JwXEjAueG0DpA9vybuAK3qUW2MLvnRmngwVwYrugvGP0ZLQWIidoq2rKUWwWzFXazV9h aSCFxcFgCdMd9XXTKorII9oX9GFmXkc+AyBlv2BGewBd6Gvydtsx/13Pc+fQ4YtsEZXx FEsf5Q6dZ86urNURJOHXwlpQSNCu5kszvokXvI/3pb3AXdwXKb0OFUgblXGOPUeIPLzz /GTw== X-Gm-Message-State: AOAM530rUEoylbFmyU7GjURcT/cRGKoIcJMJVfAhMHfF7weNxEtzKTgt xpTDE+app6Q1gWAs+WxvGsBWhg== X-Google-Smtp-Source: ABdhPJxNGkA7TVyO8dSseAEJpqDtXeJaz5dE8dqeS9d0DTDHLOhJONFiE4J3HbKseEq6l0wPlu3AAQ== X-Received: by 2002:a05:6638:38aa:: with SMTP id b42mr3121969jav.6.1630419591013; Tue, 31 Aug 2021 07:19:51 -0700 (PDT) Received: from smtpclient.apple (dynamic-acs-24-154-121-237.zoominternet.net. [24.154.121.237]) by smtp.gmail.com with ESMTPSA id d12sm9549866iow.16.2021.08.31.07.19.48 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Aug 2021 07:19:49 -0700 (PDT) From: Brian Rosen Message-Id: <5D81F416-13D1-4CC2-BC07-4A319B62E32F@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_0949F8F5-9BE8-46E4-82E8-2506CF1688D4" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 10:19:47 -0400 In-Reply-To: Cc: "Olle E. Johansson" , Paul Kyzivat , "rum@ietf.org" To: Ed Sayers References: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 14:20:00 -0000 --Apple-Mail=_0949F8F5-9BE8-46E4-82E8-2506CF1688D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay. First, let me say that I am VERY willing to add a requirement to support = OSRTP if it means we get consensus on this issue. Full stop. But I want to ask if, on the RUE interface, it has any actual meaning. If, as I understand it, providers world wide universally have a media = anchor and B2BUA connecting to a user for all calls, then the = provider=E2=80=99s RUE interface is there, at that B2BUA/media anchor. = If the provider upgrades to a conforming RUE interface, it supports = DTLS-SRTP. If a client RUE implements a conforming interface, it = supports DTLS-SRTP, and the client can make a call to/through that = provider with the first leg encrypted. Same for a call received by the = RUE. So, if both sides conform, we don=E2=80=99t need OSRTP. The only thing this seems to help is allowing a RUE to connect to a = provider that doesn=E2=80=99t yet support our document. Then you = don=E2=80=99t fail the call. I=E2=80=99m not clear if that should be a = requirement on the client. SHOULD maybe. Again, very willing to add a MUST requirement to support 5673 if that = gets us consensus on this issue. Brian > On Aug 31, 2021, at 9:06 AM, Ed Sayers wrote: >=20 > Hi Brian, > =20 > I would say that OSRTP is more a way of negotiating SRTP. It allows = older endpoints that can=E2=80=99t/don=E2=80=99t support encryption to = still potentially participate in a call. > =20 > Yes, the intention of adding OSRTP to the updated Inter-Provider = specification was to allow the possibility of end-to-end SRTP-DTLS = encryption between the endpoints of two different Providers once = supported (or passed on) where possible. > =20 > We thought this to be the best balance between adding burdensome = complexity, calls failing out-right or some devices not ringing, whilst = still allowing encryption whenever it possibly could be. > =20 > Cheers, > =20 > =20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC >=20 > purplevrs.com =09 > =20 > > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. > =20 > =20 > =20 > =20 > From: Brian Rosen =20 > Sent: 31 August 2021 13:30 > To: Ed Sayers > Cc: Olle E. Johansson ; Paul Kyzivat = ; rum@ietf.org > Subject: Re: [Rum] encryption > =20 > Are you proposing this in addition to requiring DTLS-STRP or instead = of it? > =20 > Would two users doing point to point calling through typical providers = that anchor media reliably get a secure connection hop-by-hop if both = users and both providers had conforming implementations and the = providers implemented the new inter-provider spec? > =20 > User 1 Provider 1 Provider 2 User 2 > DTLS- DTLS=3D DTLS- > SRTP SRTP SRTP =20 >=20 >=20 > On Aug 31, 2021, at 6:30 AM, Ed Sayers > wrote: > =20 > Hi, >=20 > Inline below.. >=20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC > purplevrs.com >=20 > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Olle E. Johansson >=20 > Sent: 31 August 2021 11:12 > To: Ed Sayers > > Cc: Brian Rosen >; Paul = Kyzivat >; = rum@ietf.org > Subject: Re: [Rum] encryption >=20 >=20 >=20 >=20 > On 31 Aug 2021, at 11:29, Ed Sayers > wrote: >=20 > Hi, >=20 > Thought I'd split out IPv6 and encryption as separate points.. >=20 > For encryption, the US VRS Providers recently created a new Provider = Inter-Operability Profile that now specifically allows for encryption = and ICE, amongst other things. >=20 > Whilst we all agreed that SRTP-DTLS is the right way to go, we decided = to specifically adopt RFC-8643 OSRTP, because this allows for the = greatest flexibility and greatest chance of supporting end-to-end = encryption, while still supporting a heterogenous range of devices. >=20 >=20 > OSRTP supports SRTP-DTLS. It=E2=80=99s not an alternative. And it=E2=80=99= s just an informational RFC, not a standards RFC.You still have to = implement SRTP-DTLS so you can use that fully in a situation where all = devices has support. >=20 > EdS - We know it is not an alternative. It simply revert the profile = to RTP/AVP, while keeping the fingerprint and setup attributes. This = means that an endpoint that sees the attributes can replay likewise and = agree SRTP-DTLS. Old endpoints ignore the attributes and can still = answer the call. >=20 > There are other ways to construct the SDP if you want to offer both = RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so one = need serious consideration. >=20 > EdS - Typically, older endpoints also would not support this, which is = the benefit of OSRTP - It is backwardly compatible. >=20 >=20 >=20 > Whilst it is true that encryption could be terminated on the RUE=20 > interface proxy, >=20 > Aren=E2=80=99t you mixing signalling and media now? >=20 > EdS - I am missing what you mean here. >=20 >=20 > any Provider that wants to allow encryption further into their = Infrastructure is generally faced with the potential need to fork calls = to various devices, possibly only some of which support encryption. = Using RFC-5673 alone would mean that older devices that do not support = encryption would reject the call as unsupported. >=20 > Isn=E2=80=99t that one of the benefits? A user needs to be assured = that the call is protected. As a provider you may need to have gateways = to the old world if you need that, but still keep the first call leg = encrypted at all times. >=20 > EdS - =46rom a customer standpoint, having a range of devices no = longer ring is not a benefit. Using OSRTP as a migration path to support = end-to-end encryption while older devices can be gradually 'aged out'. > The user might otherwise have an illusion of security - terminated at = the RUM proxy, while the endpoint on the other end is not encrypted = (because it cannot support it). >=20 >=20 >=20 > Using OSRTP is by far the simplest and most convenient way to fork the = call and still ensure that the widest range of endpoints can ring. >=20 > But it doesn=E2=80=99t deliver any guarantee of any kind to the user. >=20 > EdS - It provides a progression where more and more endpoints over = time can be encrypted. Precisely why we adopted it on the Inter-Provider = interface. >=20 >=20 > /O >=20 >=20 > Cheers, >=20 >=20 > Ed Sayers > Endpoint SDK Team Lead > Purple, a Division of ZP Better Together, LLC purplevrs.com = >=20 > The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >=20 >=20 >=20 >=20 > -----Original Message----- > From: Rum > On = Behalf Of Brian Rosen > Sent: 30 August 2021 22:24 > To: Paul Kyzivat > > Cc: Chad Leeper >; rum@ietf.org > Subject: Re: [Rum] IPv6 and encryption >=20 > I don=E2=80=99t think there are ANY alternatives to SRTP. There are = alternatives to DTLS-SRTP. There are moves within the IETF to deprecate = SDES, specifically. There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. Since all = providers I know about anchor media, this only affects the initial hop. = Users really want to hear that their media is protected end to end (at = least hop by hop) but our document doesn=E2=80=99t require that. Again, = we need a STANDARDS based solution, and we have to live within the = constraints the IETF has for new standards with respect to security. = Like nearly every organization, the IETF is much more security conscious = than it was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism. =20 >=20 > I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. = We=E2=80=99ve spent lots of time and cycles implementing things that = turn out not to be secure enough, and we have to move forward on things = that are. DTLS-SRTP is one of those things, as is IPv6. >=20 > Brian >=20 >=20 >=20 > On Aug 30, 2021, at 5:06 PM, Paul Kyzivat > wrote: >=20 > Chad, >=20 > Welcome to the RUM WG! >=20 > On 8/30/21 11:51 AM, Chad Leeper wrote: >=20 > - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea going = forward, it can't be a "MUST" requirement. I agree with Roger Slusser = that mandating compliance using MUST requires providers to implement = significant development to change over to what RUM is specifying. >=20 > The requirements in this doc will apply only to devices that claim to=20= > conform to it. Presumably you could continue to support your existing=20= > devices using whatever mechanisms they currently use. So the=20 > implementation burden is only on the server side, not the legacy=20 > device side. (Of course the FCC will have a say in this.) >=20 > One motivation for the webrtc requirement is so that a RUE can be=20 > built on top of WebRTC. E.g., it can be a server that supports deaf=20 > users using any device with a browser. Such a server is effectively=20 > just signaling gateway that can establish a p2p link between the=20 > browser and the VRS provider server. (It does have to transcode RTT,=20= > but that is less of a burden.) >=20 > When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal. >=20 >=20 > - We should keep any new privacy requirements very minimal at this = time. While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet. So what may look like an easy change to EU implementers may be a = dramatic change for others. >=20 > I don't think we have said much about privacy of retained data. But we = are concerned that the media and signaling be private between the RUE = and the provider. That is a low bar these days. It is unlikely that = anything less could be approved. I expect the FCC will agree. >=20 > If you have an alternate proposal that achieves that then make a = proposal we can discuss. >=20 > Thanks, > Paul >=20 >=20 > On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat >> wrote: > Providers, > My request below to Roger should have been broader. You all seem to > have > the same issue. I encourage any/all of you to make an alternative > proposal here. Just saying "we don't like what is there" isn't = helpful > without an alternative. > Thanks, > Paul > On 8/26/21 5:40 PM, Paul Kyzivat wrote: >=20 > Roger, >=20 > On 8/26/21 3:30 PM, Roger Slusser wrote: >=20 >=20 > Most providers already support encryption and IPV6 on a limited > scope, >=20 > not necessarily the way it is defined in RUM spec. Mandating=20 > compliance using MUST requires providers to discard sometimes huge=20 > amounts of development to change over to what RUM is specifying. > The >=20 > push back is not about doing these things it is about the loss of=20 > time, effort and money to do them in the way RUM mandates with > MUSTs. >=20 >=20 > Do you think there is something else we could write in this spec > that >=20 > covers encryption and IPv6 in a way that is less burdensome for=20 > providers while remaining interoperable with all providers? >=20 > If so, can you please spell it out? > -- Rum mailing list > Rum@ietf.org > > https://www.ietf.org/mailman/listinfo/rum = > > >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_0949F8F5-9BE8-46E4-82E8-2506CF1688D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay.

First, let me say that I am VERY willing to add a requirement = to support OSRTP if it means we get consensus on this issue.  Full = stop.

But I = want to ask if, on the RUE interface, it has any actual = meaning.

If, = as I understand it, providers world wide universally have a media anchor = and B2BUA connecting to a user for all calls, then the provider=E2=80=99s = RUE interface is there, at that B2BUA/media anchor.  If the = provider upgrades to a conforming RUE interface, it supports DTLS-SRTP. =  If a client RUE implements a conforming interface, it supports = DTLS-SRTP, and the client can make a call to/through that provider with = the first leg encrypted.  Same for a call received by the RUE. =  So, if both sides conform, we don=E2=80=99t need OSRTP.

The only thing this = seems to help is allowing a RUE to connect to a provider that doesn=E2=80=99= t yet support our document.  Then you don=E2=80=99t fail the call. =  I=E2=80=99m not clear if that should be a requirement on the = client.  SHOULD maybe.

Again, very willing to add a MUST requirement to support = 5673 if that gets us consensus on this issue.

Brian


On Aug 31, 2021, at 9:06 AM, Ed Sayers <ed.sayers@purple.us>= wrote:

Hi Brian,
 
I would say that OSRTP is more a way of negotiating SRTP. It = allows older endpoints that can=E2=80=99t/don=E2=80=99t support = encryption to still potentially participate in a call.
 
Yes, the intention of adding OSRTP to the updated = Inter-Provider specification was to allow the possibility of end-to-end = SRTP-DTLS encryption between the endpoints of two different Providers = once supported (or passed on) where possible.
 
We thought this to be the best balance between adding = burdensome complexity, calls failing out-right or some devices not = ringing, whilst still allowing encryption whenever it possibly could = be.
 
Cheers,
 

 

Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC

purplevrs.com

 

<image001.jpg>
The information = contained in this e-mail message is intended only for the personal and = confidential use of the recipient(s) named above. If you have received = this communication in error, please notify us immediately by e-mail, and = delete the original message.
 
 
 
 
From: Brian Rosen <br@brianrosen.net> 
Sent: 31 = August 2021 13:30
To: Ed Sayers <ed.sayers@purple.us>
Cc: Olle = E. Johansson <oej@edvina.net>; Paul Kyzivat <pkyzivat@alum.mit.edu>; rum@ietf.org
Subject: Re: [Rum] encryption
 
Are you proposing this in = addition to requiring DTLS-STRP or instead of it?
 
Would = two users doing point to point calling through typical providers that = anchor media reliably get a secure connection hop-by-hop if both users = and both providers had conforming implementations and the providers = implemented the new inter-provider spec?
 
User 1   = Provider 1     Provider 2     User 2
    =  DTLS-         DTLS=3D       =    DTLS-
     SRTP   =        SRTP           SRTP =      


On = Aug 31, 2021, at 6:30 AM, Ed Sayers <ed.sayers@purple.us> = wrote:
 
Hi,

Inline below..


Ed Sayers
Endpoint = SDK Team Lead
Purple, a Division of ZP Better Together, = LLC
purplevrs.com

The information contained in this e-mail message is intended = only for the personal and confidential use of the recipient(s) named = above. If you have received this communication in error, please notify = us immediately by e-mail, and delete the original message.




-----Original Message-----
From: Olle E. = Johansson <oej@edvina.net> 
Sent: 31 = August 2021 11:12
To: Ed Sayers <ed.sayers@purple.us>
Cc: = Brian Rosen <br@brianrosen.net>; Paul Kyzivat = <pkyzivat@alum.mit.edu>; rum@ietf.org
Subject: Re: [Rum] encryption




On 31 Aug 2021, at 11:29, Ed Sayers <ed.sayers@purple.us> = wrote:

Hi,

Thought I'd split out IPv6 and encryption as separate = points..

For encryption, the US VRS = Providers recently created a new Provider Inter-Operability Profile that = now specifically allows for encryption and ICE, amongst other things.

Whilst we all agreed that SRTP-DTLS is the = right way to go, we decided to specifically adopt RFC-8643 OSRTP, = because this allows for the greatest flexibility and greatest chance of = supporting end-to-end encryption, while still supporting a heterogenous = range of devices.


OSRTP = supports SRTP-DTLS. It=E2=80=99s not an alternative. And it=E2=80=99s = just an informational RFC, not a standards RFC.You still have to = implement SRTP-DTLS so you can use that fully in a situation where all = devices has support.

EdS - We know it is = not an alternative. It simply revert the profile to RTP/AVP, while = keeping the fingerprint and setup attributes. This means that an = endpoint that sees the attributes can replay likewise and agree = SRTP-DTLS. Old endpoints ignore the attributes and can still answer the = call.

There are other ways to construct the = SDP if you want to offer both RTP/SAVP and RTP/AVP, but that opens up = for downgrade attacks, so one need serious consideration.

EdS - Typically, older endpoints also would = not support this, which is the benefit of OSRTP - It is backwardly = compatible.



Whilst it is true that encryption could be = terminated on the RUE 
interface = proxy,

Aren=E2=80=99t you = mixing signalling and media now?

EdS - I am = missing what you mean here.


any Provider that wants to allow = encryption further into their Infrastructure is generally faced with the = potential need to fork calls to various devices, possibly only some of = which support encryption. Using RFC-5673 alone would mean that older = devices that do not support encryption would reject the call as = unsupported.

Isn=E2=80=99t that one = of the benefits? A user needs to be assured that the call is protected. = As a provider you may need to have gateways to the old world if you need = that, but still keep the first call leg encrypted at all times.

EdS - =46rom a customer standpoint, having a = range of devices no longer ring is not a benefit. Using OSRTP as a = migration path to support end-to-end encryption while older devices can = be gradually 'aged out'.
The user might otherwise have an = illusion of security - terminated at the RUM proxy, while the endpoint = on the other end is not encrypted (because it cannot support it).



Using OSRTP is by far the simplest and most = convenient way to fork the call and still ensure that the widest range = of endpoints can ring.

But it doesn=E2=80=99t = deliver any guarantee of any kind to the user.

EdS - It provides a progression where more and more endpoints = over time can be encrypted. Precisely why we adopted it on the = Inter-Provider interface.


/O


Cheers,


Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC purplevrs.com

The = information contained in this e-mail message is intended only for the = personal and confidential use of the recipient(s) named above. If you = have received this communication in error, please notify us immediately = by e-mail, and delete the original message.




-----Original = Message-----
From: Rum <rum-bounces@ietf.org> On = Behalf Of Brian Rosen
Sent: 30 August 2021 22:24
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: Chad Leeper = <chad.leeper@convorelay.com>; rum@ietf.org
Subject: Re: [Rum] = IPv6 and encryption

I don=E2=80=99t think = there are ANY alternatives to SRTP.  There are alternatives to = DTLS-SRTP.  There are moves within the IETF to deprecate SDES, = specifically.  There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. =   Since all providers I know about anchor media, this only = affects the initial hop.  Users really want to hear that their = media is protected end to end (at least hop by hop) but our document = doesn=E2=80=99t require that.  Again, we need a STANDARDS based = solution, and we have to live within the constraints the IETF has for = new standards with respect to security.  Like nearly every = organization, the IETF is much more security conscious than it was, and = won=E2=80=99t tolerate bad security although it often recognizes the = necessity for backwards compatibility as long as it=E2=80=99s not to a = known insecure mechanism.  

I really = think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. =  We=E2=80=99ve spent lots of time and cycles implementing things = that turn out not to be secure enough, and we have to move forward on = things that are.  DTLS-SRTP is one of those things, as is IPv6.

Brian



On Aug 30, 2021, at 5:06 PM, Paul = Kyzivat <pkyzivat@alum.mit.edu> wrote:

Chad,

Welcome to the RUM WG!

On 8/30/21 11:51 AM, Chad Leeper wrote:

- While WebRTC w/ SRTP/DTLS = (encryption) is an excellent idea going forward, it can't be a "MUST" = requirement. I agree with Roger Slusser that mandating compliance using = MUST requires providers to implement significant development to change = over to what RUM is specifying.

The requirements in this doc will apply only = to devices that claim to 
conform to = it. Presumably you could continue to support your existing 
devices = using whatever mechanisms they currently use. So the 
implementation= burden is only on the server side, not the legacy 
device side. = (Of course the FCC will have a say in this.)

One motivation for the webrtc requirement is so that a RUE = can be 
built on top of WebRTC. E.g., it can be a server that = supports deaf 
users using any device with a browser. Such a server is = effectively 
just signaling gateway that can establish a p2p link between = the 
browser and the VRS provider server. (It does have to = transcode RTT, 
but that is less of a burden.)

When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal.


-= We should keep any new privacy requirements very minimal at this time. =  While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet.  So what may look like an easy change to EU implementers may = be a dramatic change for others.

I don't think we have said much about privacy = of retained data. But we are concerned that the media and signaling be = private between the RUE and the provider. That is a low bar these days. = It is unlikely that anything less could be approved. I expect the FCC = will agree.

If you have an alternate = proposal that achieves that then make a proposal we can discuss.

        &= nbsp;       Thanks,
        &= nbsp;       Paul

On Fri, Aug 27, 2021 at 3:16 PM Paul = Kyzivat <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu>> wrote:
 Providers,
 My request below to = Roger should have been broader. You all seem to
 have
 the same issue. I encourage = any/all of you to make an alternative
 proposal here. = Just saying "we don't like what is there" isn't helpful
 without an alternative.
          Tha= nks,
          Pau= l
 On 8/26/21 5:40 PM, Paul Kyzivat wrote:

Roger,

On = 8/26/21 3:30 PM, Roger Slusser wrote:


Most providers already support = encryption and IPV6 on a limited
 scope,

not necessarily the way it is defined = in RUM spec. Mandating 
compliance = using MUST requires providers to discard sometimes huge 
amounts of = development to change over to what RUM is specifying.
 The

push back is not about doing these = things it is about the loss of 
time, effort = and money to do them in the way RUM mandates with
 MUSTs.


Do you think there is = something else we could write in this spec
 that

covers encryption and IPv6 in a way that is less burdensome = for 
providers while remaining interoperable with all = providers?

If so, can you please spell it = out?
 --     Rum mailing list
 Rum@ietf.org <mailto:Rum@ietf.org>
 https://www.ietf.org/mailman/listinfo/rum
 <https://www.ietf.org/mailman/listinfo/rum>

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

= --Apple-Mail=_0949F8F5-9BE8-46E4-82E8-2506CF1688D4-- From nobody Tue Aug 31 07:42:10 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891AC3A1781 for ; Tue, 31 Aug 2021 07:42:07 -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 sVjy1BaXiYzs for ; Tue, 31 Aug 2021 07:42:01 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::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 B2E543A177B for ; Tue, 31 Aug 2021 07:41:59 -0700 (PDT) Received: from smtpclient.apple (h-176-10-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 B41261900; Tue, 31 Aug 2021 16:41:55 +0200 (CEST) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_41D997C5-4F12-4B6E-9506-E4D92793BBBA" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Tue, 31 Aug 2021 16:41:55 +0200 In-Reply-To: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> Cc: Ed Sayers , Paul Kyzivat , "rum@ietf.org" To: Brian Rosen References: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 14:42:08 -0000 --Apple-Mail=_41D997C5-4F12-4B6E-9506-E4D92793BBBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I propose that all RUE devices need to support DTLS-SRTP and not = anything else. Gateway to old devices has to be seen as a service = provider problem.=20 Oppurtunistic crypto doesn=E2=80=99t guarantee privacy at all and is = wide open for middlemen to downgrade the call and listen in. I do agree that it is simpler for a service provider to say =E2=80=9Coh, = some calls randomly will be encrypted=E2=80=9D. But we can surely expect = better.=20 All of these discussions where part of the WebRTC standardization = process. The documents ended up with DTLS-SRTP as a requirement. I = don=E2=80=99t expect the IETF to move backwards here. /O > On 31 Aug 2021, at 14:30, Brian Rosen wrote: >=20 > Are you proposing this in addition to requiring DTLS-STRP or instead = of it? >=20 > Would two users doing point to point calling through typical providers = that anchor media reliably get a secure connection hop-by-hop if both = users and both providers had conforming implementations and the = providers implemented the new inter-provider spec? >=20 > User 1 Provider 1 Provider 2 User 2 > DTLS- DTLS=3D DTLS- > SRTP SRTP SRTP =20 >=20 >> On Aug 31, 2021, at 6:30 AM, Ed Sayers > wrote: >>=20 >> Hi, >>=20 >> Inline below.. >>=20 >>=20 >> Ed Sayers >> Endpoint SDK Team Lead >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com >>=20 >> The information contained in this e-mail message is intended only for = the personal and confidential use of the recipient(s) named above. If = you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >>=20 >>=20 >>=20 >>=20 >> -----Original Message----- >> From: Olle E. Johansson >=20 >> Sent: 31 August 2021 11:12 >> To: Ed Sayers > >> Cc: Brian Rosen >; Paul = Kyzivat >; = rum@ietf.org >> Subject: Re: [Rum] encryption >>=20 >>=20 >>=20 >>> On 31 Aug 2021, at 11:29, Ed Sayers > wrote: >>>=20 >>> Hi, >>>=20 >>> Thought I'd split out IPv6 and encryption as separate points.. >>>=20 >>> For encryption, the US VRS Providers recently created a new Provider = Inter-Operability Profile that now specifically allows for encryption = and ICE, amongst other things. >>>=20 >>> Whilst we all agreed that SRTP-DTLS is the right way to go, we = decided to specifically adopt RFC-8643 OSRTP, because this allows for = the greatest flexibility and greatest chance of supporting end-to-end = encryption, while still supporting a heterogenous range of devices. >>=20 >>=20 >> OSRTP supports SRTP-DTLS. It=E2=80=99s not an alternative. And it=E2=80= =99s just an informational RFC, not a standards RFC.You still have to = implement SRTP-DTLS so you can use that fully in a situation where all = devices has support. >>=20 >> EdS - We know it is not an alternative. It simply revert the profile = to RTP/AVP, while keeping the fingerprint and setup attributes. This = means that an endpoint that sees the attributes can replay likewise and = agree SRTP-DTLS. Old endpoints ignore the attributes and can still = answer the call. >>=20 >> There are other ways to construct the SDP if you want to offer both = RTP/SAVP and RTP/AVP, but that opens up for downgrade attacks, so one = need serious consideration. >>=20 >> EdS - Typically, older endpoints also would not support this, which = is the benefit of OSRTP - It is backwardly compatible. >>=20 >>>=20 >>> Whilst it is true that encryption could be terminated on the RUE=20 >>> interface proxy, >>=20 >> Aren=E2=80=99t you mixing signalling and media now? >>=20 >> EdS - I am missing what you mean here. >>=20 >>> any Provider that wants to allow encryption further into their = Infrastructure is generally faced with the potential need to fork calls = to various devices, possibly only some of which support encryption. = Using RFC-5673 alone would mean that older devices that do not support = encryption would reject the call as unsupported. >>=20 >> Isn=E2=80=99t that one of the benefits? A user needs to be assured = that the call is protected. As a provider you may need to have gateways = to the old world if you need that, but still keep the first call leg = encrypted at all times. >>=20 >> EdS - =46rom a customer standpoint, having a range of devices no = longer ring is not a benefit. Using OSRTP as a migration path to support = end-to-end encryption while older devices can be gradually 'aged out'. >> The user might otherwise have an illusion of security - terminated at = the RUM proxy, while the endpoint on the other end is not encrypted = (because it cannot support it). >>=20 >>>=20 >>> Using OSRTP is by far the simplest and most convenient way to fork = the call and still ensure that the widest range of endpoints can ring. >>=20 >> But it doesn=E2=80=99t deliver any guarantee of any kind to the user. >>=20 >> EdS - It provides a progression where more and more endpoints over = time can be encrypted. Precisely why we adopted it on the Inter-Provider = interface. >>=20 >>=20 >> /O >>>=20 >>> Cheers, >>>=20 >>>=20 >>> Ed Sayers >>> Endpoint SDK Team Lead >>> Purple, a Division of ZP Better Together, LLC purplevrs.com = >>>=20 >>> The information contained in this e-mail message is intended only = for the personal and confidential use of the recipient(s) named above. = If you have received this communication in error, please notify us = immediately by e-mail, and delete the original message. >>>=20 >>>=20 >>>=20 >>>=20 >>> -----Original Message----- >>> From: Rum > On = Behalf Of Brian Rosen >>> Sent: 30 August 2021 22:24 >>> To: Paul Kyzivat > >>> Cc: Chad Leeper >; rum@ietf.org >>> Subject: Re: [Rum] IPv6 and encryption >>>=20 >>> I don=E2=80=99t think there are ANY alternatives to SRTP. There are = alternatives to DTLS-SRTP. There are moves within the IETF to deprecate = SDES, specifically. There is push back on that, but it=E2=80=99s an = ongoing discussion because SDES isn=E2=80=99t secure enough. Since all = providers I know about anchor media, this only affects the initial hop. = Users really want to hear that their media is protected end to end (at = least hop by hop) but our document doesn=E2=80=99t require that. Again, = we need a STANDARDS based solution, and we have to live within the = constraints the IETF has for new standards with respect to security. = Like nearly every organization, the IETF is much more security conscious = than it was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism. =20 >>>=20 >>> I really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. = We=E2=80=99ve spent lots of time and cycles implementing things that = turn out not to be secure enough, and we have to move forward on things = that are. DTLS-SRTP is one of those things, as is IPv6. >>>=20 >>> Brian >>>=20 >>>=20 >>>> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat > wrote: >>>>=20 >>>> Chad, >>>>=20 >>>> Welcome to the RUM WG! >>>>=20 >>>> On 8/30/21 11:51 AM, Chad Leeper wrote: >>>>> - While WebRTC w/ SRTP/DTLS (encryption) is an excellent idea = going forward, it can't be a "MUST" requirement. I agree with Roger = Slusser that mandating compliance using MUST requires providers to = implement significant development to change over to what RUM is = specifying. >>>>=20 >>>> The requirements in this doc will apply only to devices that claim = to=20 >>>> conform to it. Presumably you could continue to support your = existing=20 >>>> devices using whatever mechanisms they currently use. So the=20 >>>> implementation burden is only on the server side, not the legacy=20 >>>> device side. (Of course the FCC will have a say in this.) >>>>=20 >>>> One motivation for the webrtc requirement is so that a RUE can be=20= >>>> built on top of WebRTC. E.g., it can be a server that supports deaf=20= >>>> users using any device with a browser. Such a server is effectively=20= >>>> just signaling gateway that can establish a p2p link between the=20 >>>> browser and the VRS provider server. (It does have to transcode = RTT,=20 >>>> but that is less of a burden.) >>>>=20 >>>> When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal. >>>>=20 >>>>> - We should keep any new privacy requirements very minimal at this = time. While companies in the EU have already created their systems in = compliance with the GDPR, most of the world hasn't created an equivalent = yet. So what may look like an easy change to EU implementers may be a = dramatic change for others. >>>>=20 >>>> I don't think we have said much about privacy of retained data. But = we are concerned that the media and signaling be private between the RUE = and the provider. That is a low bar these days. It is unlikely that = anything less could be approved. I expect the FCC will agree. >>>>=20 >>>> If you have an alternate proposal that achieves that then make a = proposal we can discuss. >>>>=20 >>>> Thanks, >>>> Paul >>>>=20 >>>>> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat = = >> wrote: >>>>> Providers, >>>>> My request below to Roger should have been broader. You all seem = to >>>>> have >>>>> the same issue. I encourage any/all of you to make an alternative >>>>> proposal here. Just saying "we don't like what is there" isn't = helpful >>>>> without an alternative. >>>>> Thanks, >>>>> Paul >>>>> On 8/26/21 5:40 PM, Paul Kyzivat wrote: >>>>>> Roger, >>>>>>=20 >>>>>> On 8/26/21 3:30 PM, Roger Slusser wrote: >>>>>>=20 >>>>>>> Most providers already support encryption and IPV6 on a limited >>>>> scope, >>>>>>> not necessarily the way it is defined in RUM spec. Mandating=20 >>>>>>> compliance using MUST requires providers to discard sometimes = huge=20 >>>>>>> amounts of development to change over to what RUM is specifying. >>>>> The >>>>>>> push back is not about doing these things it is about the loss = of=20 >>>>>>> time, effort and money to do them in the way RUM mandates with >>>>> MUSTs. >>>>>>=20 >>>>>> Do you think there is something else we could write in this spec >>>>> that >>>>>> covers encryption and IPv6 in a way that is less burdensome for=20= >>>>>> providers while remaining interoperable with all providers? >>>>>>=20 >>>>>> If so, can you please spell it out? >>>>> -- Rum mailing list >>>>> Rum@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/rum = >>>>> > >>>>=20 >>>> -- >>>> Rum mailing list >>>> Rum@ietf.org >>>> https://www.ietf.org/mailman/listinfo/rum >>>=20 >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >>> -- >>> Rum mailing list >>> Rum@ietf.org >>> https://www.ietf.org/mailman/listinfo/rum >=20 --Apple-Mail=_41D997C5-4F12-4B6E-9506-E4D92793BBBA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = propose that all RUE devices need to support DTLS-SRTP and not anything = else. Gateway to old devices has to be seen as a service provider = problem. 

Oppurtunistic crypto doesn=E2=80=99t guarantee privacy at all = and is wide open for middlemen to downgrade the call and listen = in.

I do agree = that it is simpler for a service provider to say =E2=80=9Coh, some calls = randomly will be encrypted=E2=80=9D. But we can surely expect = better. 

All of these discussions where part of the WebRTC = standardization process. The documents ended up with DTLS-SRTP as a = requirement. I don=E2=80=99t expect the IETF to move backwards = here.

/O

On 31 Aug 2021, at 14:30, Brian = Rosen <br@brianrosen.net> wrote:

Are you proposing this = in addition to requiring DTLS-STRP or instead of it?

Would two users doing point to point = calling through typical providers that anchor media reliably get a = secure connection hop-by-hop if both users and both providers had = conforming implementations and the providers implemented the new = inter-provider spec?

User 1   Provider = 1     Provider 2     User 2
    =  DTLS-         DTLS=3D       =    DTLS-
     SRTP         =  SRTP           SRTP     =  

On Aug 31, 2021, at 6:30 AM, Ed = Sayers <ed.sayers@purple.us> wrote:

Hi,

Inline below..


Ed Sayers
Endpoint SDK Team Lead
Purple, a Division of ZP Better Together, LLC
purplevrs.com

The information contained in = this e-mail message is intended only for the personal and confidential = use of the recipient(s) named above. If you have received this = communication in error, please notify us immediately by e-mail, and = delete the original message.




-----Original Message-----
From: Olle E. Johansson <oej@edvina.net> 
Sent: 31 August 2021 = 11:12
To: Ed Sayers = <ed.sayers@purple.us>
Cc: Brian Rosen <br@brianrosen.net>; Paul Kyzivat <pkyzivat@alum.mit.edu>; rum@ietf.org
Subject: Re: [Rum] = encryption



On 31 = Aug 2021, at 11:29, Ed Sayers <ed.sayers@purple.us> wrote:

Hi,

Thought I'd split out IPv6 = and encryption as separate points..

For = encryption, the US VRS Providers recently created a new Provider = Inter-Operability Profile that now specifically allows for encryption = and ICE, amongst other things.

Whilst we = all agreed that SRTP-DTLS is the right way to go, we decided to = specifically adopt RFC-8643 OSRTP, because this allows for the greatest = flexibility and greatest chance of supporting end-to-end encryption, = while still supporting a heterogenous range of devices.


OSRTP supports SRTP-DTLS. It=E2=80=99s not an alternative. = And it=E2=80=99s just an informational RFC, not a standards RFC.You = still have to implement SRTP-DTLS so you can use that fully in a = situation where all devices has support.

EdS - We know it is not an alternative. It simply revert the = profile to RTP/AVP, while keeping the fingerprint and setup attributes. = This means that an endpoint that sees the attributes can replay likewise = and agree SRTP-DTLS. Old endpoints ignore the attributes and can still = answer the call.

There are other ways to construct the SDP if you want to = offer both RTP/SAVP and RTP/AVP, but that opens up for downgrade = attacks, so one need serious consideration.

EdS - Typically, older endpoints = also would not support this, which is the benefit of OSRTP - It is = backwardly compatible.


Whilst it is true that = encryption could be terminated on the RUE 
interface = proxy,

Aren=E2=80=99t you mixing signalling and media now?

EdS - I am missing what you mean = here.

any = Provider that wants to allow encryption further into their = Infrastructure is generally faced with the potential need to fork calls = to various devices, possibly only some of which support encryption. = Using RFC-5673 alone would mean that older devices that do not support = encryption would reject the call as unsupported.

Isn=E2=80=99t that one of the benefits? A user needs to be = assured that the call is protected. As a provider you may need to have = gateways to the old world if you need that, but still keep the first = call leg encrypted at all times.

EdS - =46rom a customer standpoint, having a range of devices = no longer ring is not a benefit. Using OSRTP as a migration path to = support end-to-end encryption while older devices can be gradually 'aged = out'.
The user = might otherwise have an illusion of security - terminated at the RUM = proxy, while the endpoint on the other end is not encrypted (because it = cannot support it).


Using OSRTP is by far = the simplest and most convenient way to fork the call and still ensure = that the widest range of endpoints can ring.

But it doesn=E2=80=99t deliver any guarantee of any kind to = the user.

EdS - It = provides a progression where more and more endpoints over time can be = encrypted. Precisely why we adopted it on the Inter-Provider = interface.


/O

Cheers,


Ed = Sayers
Endpoint SDK Team Lead
Purple, a = Division of ZP Better Together, LLC purplevrs.com

The = information contained in this e-mail message is intended only for the = personal and confidential use of the recipient(s) named above. If you = have received this communication in error, please notify us immediately = by e-mail, and delete the original message.




-----Original = Message-----
From: Rum <rum-bounces@ietf.org> On Behalf Of Brian Rosen
Sent: 30 August 2021 22:24
To: Paul Kyzivat = <pkyzivat@alum.mit.edu>
Cc: Chad Leeper = <chad.leeper@convorelay.com>; rum@ietf.org
Subject: Re: [Rum] IPv6 and encryption

I don=E2=80=99t think there are ANY alternatives to SRTP. =  There are alternatives to DTLS-SRTP.  There are moves within = the IETF to deprecate SDES, specifically.  There is push back on = that, but it=E2=80=99s an ongoing discussion because SDES isn=E2=80=99t = secure enough.   Since all providers I know about anchor = media, this only affects the initial hop.  Users really want to = hear that their media is protected end to end (at least hop by hop) but = our document doesn=E2=80=99t require that.  Again, we need a = STANDARDS based solution, and we have to live within the constraints the = IETF has for new standards with respect to security.  Like nearly = every organization, the IETF is much more security conscious than it = was, and won=E2=80=99t tolerate bad security although it often = recognizes the necessity for backwards compatibility as long as it=E2=80=99= s not to a known insecure mechanism.  

I= really think this is a =E2=80=9Cstep up to the bar=E2=80=9D thing. =  We=E2=80=99ve spent lots of time and cycles implementing things = that turn out not to be secure enough, and we have to move forward on = things that are.  DTLS-SRTP is one of those things, as is IPv6.

Brian


On Aug 30, 2021, at 5:06 = PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Chad,

Welcome to the RUM WG!

On 8/30/21 11:51 AM, Chad Leeper wrote:
- While WebRTC w/ = SRTP/DTLS (encryption) is an excellent idea going forward, it can't be a = "MUST" requirement. I agree with Roger Slusser that mandating compliance = using MUST requires providers to implement significant development to = change over to what RUM is specifying.

The requirements in this doc will apply only to devices that = claim to 
conform to it. Presumably you could continue to support your = existing 
devices using whatever mechanisms they currently use. So = the 
implementation burden is only on the server side, not the = legacy 
device side. (Of course the FCC will have a say in this.)

One motivation for the webrtc requirement is = so that a RUE can be built on top of WebRTC. E.g., it can be a server that = supports deaf 
users using any device with a browser. Such a server is = effectively 
just signaling gateway that can establish a p2p link between = the 
browser and the VRS provider server. (It does have to = transcode RTT, 
but that is less of a burden.)

When defining a specification for an interface that is to be = implemented by independent parties it is necessary for essential = functions to have at least one mandatory to implement mechanism. = Currently there are no standards for connecting a RUE to a provider, so = we need to pick *something* to be mandatory to implement. If you have an = alternative for the media you would prefer, then please make a specific = proposal.

- We should keep any new privacy requirements very minimal at = this time.  While companies in the EU have already created their = systems in compliance with the GDPR, most of the world hasn't created an = equivalent yet.  So what may look like an easy change to EU = implementers may be a dramatic change for others.

I don't think we have said much = about privacy of retained data. But we are concerned that the media and = signaling be private between the RUE and the provider. That is a low bar = these days. It is unlikely that anything less could be approved. I = expect the FCC will agree.

If you have an = alternate proposal that achieves that then make a proposal we can = discuss.

Thanks,
Paul

On Fri, = Aug 27, 2021 at 3:16 PM Paul Kyzivat <pkyzivat@alum.mit.edu= <mailto:pkyzivat@alum.mit.edu>> wrote:
 Providers,
 My request below to = Roger should have been broader. You all seem to
 have
 the same issue. I encourage = any/all of you to make an alternative
 proposal here. = Just saying "we don't like what is there" isn't helpful
 without an alternative.
          Tha= nks,
          Pau= l
 On 8/26/21 5:40 PM, Paul Kyzivat wrote:
Roger,

On 8/26/21 3:30 PM, Roger Slusser wrote:

Most providers already = support encryption and IPV6 on a limited
 scope,
not necessarily the way it is defined in RUM spec. = Mandating 
compliance using MUST requires providers to discard sometimes = huge 
amounts of development to change over to what RUM is = specifying.
 The
push back is not about doing these things it is about the = loss of 
time, effort and money to do them in the way RUM mandates = with
 MUSTs.

Do you = think there is something else we could write in this spec
 that
covers encryption and IPv6 in a way that is less burdensome = for 
providers while remaining interoperable with all = providers?

If so, can you please spell it = out?
 --     Rum = mailing list
 Rum@ietf.org <mailto:Rum@ietf.org>
 https://www.ietf.org/mailman/listinfo/rum
 <https://www.ietf.org/mailman/listinfo/rum>

--
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum

--
Rum mailing = list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--
Rum mailing list
Rum@ietf.orghttps://www.ietf.org/mailman/listinfo/rum


= --Apple-Mail=_41D997C5-4F12-4B6E-9506-E4D92793BBBA-- From nobody Tue Aug 31 09:15:41 2021 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC2123A1ADC for ; Tue, 31 Aug 2021 09:15:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-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=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 qyOf091z8bHo for ; Tue, 31 Aug 2021 09:15:32 -0700 (PDT) Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam07on2060.outbound.protection.outlook.com [40.107.212.60]) (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 541203A1AD5 for ; Tue, 31 Aug 2021 09:15:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GDTwVqqY9mHTmyrjodBjz6GK3gDrDAsmK43fZYOaYKu5JfXc4dB1Psod0P3bbyekK1FKlA6IrLCVMOeW4Smvvcixl0YGn0+Rr0fRoMghb3KcKbk1rNgK0cCtb9+cMbX2imimCJ6XTdYz+erqXHqaTGVBs3SIk8ckzUBaahK4OOyTUr1Sh4v7CT+XFF+ZaWQJAq5C55zo1moXSeWjTrYzKM5aqDn7i346cDNZjjkXP2wXauES277nQR/nHAXhj5yOtc5dyn92B3hbmRNbh/uwhrgmWwYphfGYV/dWqQBZ4YO+0Gd2U8pq4GkEj1TEFXgGhckobH1mKKGfHm9MwYRBfQ== 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=OxhkPcZg4KtKzShKwoJHeqvnbEgaswmzTIhX+dY1oRs=; b=oXt5hnCTsyLxz4o+31pSxzQHBqydao6Cnn9EIqAATACdMGnjAKDPWHi0+psA8Va6mJtsLcCAM7KI/skdgRNkWc/hcs5N/utGg4kwr5qaG6qC0DLS7RD2owG176cZ05fBB0EYb48EWoWmJDBmJOpljq7SVuDnhFpmF02K1FNqqu4oPxQwoVr4EVvSPsuPUfaC+q1IF7P8a52bY4Dpl0FGSeJKJfNM+3gKkGF2yJTGqwNXy9GZAFESWdJQhfvo6Nh7BnbgFLUClm7lTreR/51+61ucGmOTb0nUazumspbCxG/9vzgU34sU2UwdtLKHlxJQTAhli+6ZohSihV8E/8isGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=ietf.org smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass 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=OxhkPcZg4KtKzShKwoJHeqvnbEgaswmzTIhX+dY1oRs=; b=ZSxlalQEN4sq3G/ZVYhC+CrDCLUd9fU8Kck0Y3iFGmQbZ/nUvov5tEVd5b+KA45yyAUctjPqLOw1fjG2A1ovVi23veCtNrHKmYHYAh+o0Tmgjqh+ImG2tZhVWdlb2KvYBu/a+4TJZAdukZ8Hx3k+cKBsR6ZJBx3mIKlMwHbBRRY= Received: from BN6PR14CA0041.namprd14.prod.outlook.com (2603:10b6:404:13f::27) by CH2PR12MB4954.namprd12.prod.outlook.com (2603:10b6:610:63::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.23; Tue, 31 Aug 2021 16:15:27 +0000 Received: from BN1NAM02FT046.eop-nam02.prod.protection.outlook.com (2603:10b6:404:13f:cafe::ec) by BN6PR14CA0041.outlook.office365.com (2603:10b6:404:13f::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.20 via Frontend Transport; Tue, 31 Aug 2021 16:15:27 +0000 X-MS-Exchange-Authentication-Results: spf=pass (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=bestguesspass action=none header.from=alum.mit.edu; Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu; Received: from outgoing-alum.mit.edu (18.7.68.33) by BN1NAM02FT046.mail.protection.outlook.com (10.13.3.181) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend Transport; Tue, 31 Aug 2021 16:15:27 +0000 Received: from MacBook-Air.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 17VGFPOY000936 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 31 Aug 2021 12:15:26 -0400 To: rum@ietf.org References: <57FEAFC6-119B-4D68-A671-FC4F3112A8ED@brianrosen.net> <5D81F416-13D1-4CC2-BC07-4A319B62E32F@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Tue, 31 Aug 2021 12:15:25 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <5D81F416-13D1-4CC2-BC07-4A319B62E32F@brianrosen.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 489d43bb-0e0a-42d0-96e3-08d96c9a8b96 X-MS-TrafficTypeDiagnostic: CH2PR12MB4954: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:4303; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: NLuekcc6tmRA5Jgi41jPooH7dsvfTfkKcdtZcZ4j8WCYfmkoNlBBrQCoGG4JZMoVagKXHuOpFF/QgkgBmWKYnwU5NJ9UMVbv5kFuU61ZSQUkzHhAPM4CE/v3jWMEEZ+fBBAcgO+rdt09l6LqzdT3/60RJOrGDjDHefxFpNOT4QTzcTOsUolZ8Tz4fWLGGu8DsDjfZE8dCTMhx9wxJKvg4Aki/9af9BLZPgF03BXljMh00d2OxqADoq9L6OMcY2M73rxWs0o1Q5kkNjtGg1MOsGTBv7FB9zArJTldDyH+VBACqLJXjUTqUYXubu7RJ66vwuue79cuZgpiQZdTTpuNmUmfyaS/fzJhb6drCtvCP732wSLREtXuGqAEYJgK9ty/xp9dacRis8NXegkaOUKoIVVs+CcR5CWb7ZfVKnIwrsA9xnsQkswb7PzPWdYVJI0vzEAr4Au7NrjlkdptTQp1bDourOMYYEeZXpcLPBgx8kOZnF7ZMwRlEQBwi99XXzTEEBnk3GTJqu7v2Cf/HU361VHJrEjivkEJuCIRZnEi9AjEoIQjCmMayqhI4Xgd1gtOvEjH/Xqd9QPMPrUxTYxrEBR4vU6fKqZBWKWUdqlGN48px+99gw8sXDPzGCVe+bSHv4f5jihjRyFs2DSSf/PVIJZdUcFbOof2ErBNrCWBiamb2o87or2MELxCjW5N3IQ3TXcSevnTGSMnI6a/dTcFoglz1D6D32iI9hrxEwrwLqxcq9aDChH1JtVAFehOJfFNBjcHRuiz5x5D8GsudgY+JBfXjfc1YeCaTYBErDsw+GOHx/8rKlVHU8NFcNwo1Kd2 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; SFS:(376002)(346002)(136003)(396003)(39860400002)(36840700001)(46966006)(956004)(70206006)(478600001)(786003)(5660300002)(86362001)(6916009)(8676002)(36860700001)(2616005)(316002)(356005)(2906002)(82740400003)(26005)(966005)(186003)(83380400001)(75432002)(31696002)(47076005)(53546011)(82310400003)(70586007)(30864003)(66574015)(7596003)(31686004)(36906005)(336012)(8936002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Aug 2021 16:15:27.0741 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 489d43bb-0e0a-42d0-96e3-08d96c9a8b96 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-AuthSource: BN1NAM02FT046.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR12MB4954 Archived-At: Subject: Re: [Rum] encryption X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2021 16:15:39 -0000 On 8/31/21 10:19 AM, Brian Rosen wrote: > Okay. > > First, let me say that I am VERY willing to add a requirement to support > OSRTP if it means we get consensus on this issue.  Full stop. > > But I want to ask if, on the RUE interface, it has any actual meaning. > > If, as I understand it, providers world wide universally have a media > anchor and B2BUA connecting to a user for all calls, then the provider’s > RUE interface is there, at that B2BUA/media anchor.  If the provider > upgrades to a conforming RUE interface, it supports DTLS-SRTP.  If a > client RUE implements a conforming interface, it supports DTLS-SRTP, and > the client can make a call to/through that provider with the first leg > encrypted.  Same for a call received by the RUE.  So, if both sides > conform, we don’t need OSRTP. > > The only thing this seems to help is allowing a RUE to connect to a > provider that doesn’t yet support our document.  Then you don’t fail the > call.  I’m not clear if that should be a requirement on the client. IIUC the interface that providers currently provide to currently deployed devices is substantially different than the RUE spec as it stands today. So to support the RUE spec the provider servers will need some new implementations work. They will probably want to support their old devices for awhile, so there will be two interfaces running side by side on those servers. I don't see how OSRTP would help in this environment. The new interface only needs to support DTLS/SRTP, while the old one does whatever it does. Or is the problem around migration of existing deployed devices to support the RUE spec? Are you concerned that some devices won't be capable of being upgraded to support DTLS/SRTP? Thanks, Paul >  SHOULD maybe. > > Again, very willing to add a MUST requirement to support 5673 if that > gets us consensus on this issue. > > Brian > > >> On Aug 31, 2021, at 9:06 AM, Ed Sayers > > wrote: >> >> Hi Brian, >> I would say that OSRTP is more a way of negotiating SRTP. It allows >> older endpoints that can’t/don’t support encryption to still >> potentially participate in a call. >> Yes, the intention of adding OSRTP to the updated Inter-Provider >> specification was to allow the possibility of end-to-end SRTP-DTLS >> encryption between the endpoints of two different Providers once >> supported (or passed on) where possible. >> We thought this to be the best balance between adding burdensome >> complexity, calls failing out-right or some devices not ringing, >> whilst still allowing encryption whenever it possibly could be. >> Cheers, >> >> ** >> >> *Ed Sayers* >> Endpoint SDK Team Lead >> Purple, a Division of ZP Better Together, LLC >> >> purplevrs.com >> >> >> >> >> The information contained in this e-mail message is intended only for >> the personal and confidential use of the recipient(s) named above. If >> you have received this communication in error, please notify us >> immediately by e-mail, and delete the original message. >> >> *From:*Brian Rosen > >> *Sent:*31 August 2021 13:30 >> *To:*Ed Sayers > >> *Cc:*Olle E. Johansson >; Paul >> Kyzivat >; >> rum@ietf.org >> *Subject:*Re: [Rum] encryption >> Are you proposing this in addition to requiring DTLS-STRP or instead >> of it? >> Would two users doing point to point calling through typical providers >> that anchor media reliably get a secure connection hop-by-hop if both >> users and both providers had conforming implementations and the >> providers implemented the new inter-provider spec? >> User 1   Provider 1     Provider 2     User 2 >>      DTLS-         DTLS=          DTLS- >>      SRTP          SRTP           SRTP >> >> >> On Aug 31, 2021, at 6:30 AM, Ed Sayers > > wrote: >> Hi, >> >> Inline below.. >> >> >> Ed Sayers >> Endpoint SDK Team Lead >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com >> >> The information contained in this e-mail message is intended only >> for the personal and confidential use of the recipient(s) named >> above. If you have received this communication in error, please >> notify us immediately by e-mail, and delete the original message. >> >> >> >> >> -----Original Message----- >> From: Olle E. Johansson > >> Sent: 31 August 2021 11:12 >> To: Ed Sayers > >> Cc: Brian Rosen >; >> Paul Kyzivat > >;rum@ietf.org >> Subject: Re: [Rum] encryption >> >> >> >> >> On 31 Aug 2021, at 11:29, Ed Sayers > > wrote: >> >> Hi, >> >> Thought I'd split out IPv6 and encryption as separate points.. >> >> For encryption, the US VRS Providers recently created a new >> Provider Inter-Operability Profile that now specifically >> allows for encryption and ICE, amongst other things. >> >> Whilst we all agreed that SRTP-DTLS is the right way to go, we >> decided to specifically adopt RFC-8643 OSRTP, because this >> allows for the greatest flexibility and greatest chance of >> supporting end-to-end encryption, while still supporting a >> heterogenous range of devices. >> >> >> >> OSRTP supports SRTP-DTLS. It’s not an alternative. And it’s just >> an informational RFC, not a standards RFC.You still have to >> implement SRTP-DTLS so you can use that fully in a situation where >> all devices has support. >> >> EdS - We know it is not an alternative. It simply revert the >> profile to RTP/AVP, while keeping the fingerprint and setup >> attributes. This means that an endpoint that sees the attributes >> can replay likewise and agree SRTP-DTLS. Old endpoints ignore the >> attributes and can still answer the call. >> >> There are other ways to construct the SDP if you want to offer >> both RTP/SAVP and RTP/AVP, but that opens up for downgrade >> attacks, so one need serious consideration. >> >> EdS - Typically, older endpoints also would not support this, >> which is the benefit of OSRTP - It is backwardly compatible. >> >> >> >> Whilst it is true that encryption could be terminated on the RUE >> interface proxy, >> >> >> Aren’t you mixing signalling and media now? >> >> EdS - I am missing what you mean here. >> >> >> any Provider that wants to allow encryption further into their >> Infrastructure is generally faced with the potential need to >> fork calls to various devices, possibly only some of which >> support encryption. Using RFC-5673 alone would mean that older >> devices that do not support encryption would reject the call >> as unsupported. >> >> >> Isn’t that one of the benefits? A user needs to be assured that >> the call is protected. As a provider you may need to have gateways >> to the old world if you need that, but still keep the first call >> leg encrypted at all times. >> >> EdS - From a customer standpoint, having a range of devices no >> longer ring is not a benefit. Using OSRTP as a migration path to >> support end-to-end encryption while older devices can be gradually >> 'aged out'. >> The user might otherwise have an illusion of security - terminated >> at the RUM proxy, while the endpoint on the other end is not >> encrypted (because it cannot support it). >> >> >> >> Using OSRTP is by far the simplest and most convenient way to >> fork the call and still ensure that the widest range of >> endpoints can ring. >> >> >> But it doesn’t deliver any guarantee of any kind to the user. >> >> EdS - It provides a progression where more and more endpoints over >> time can be encrypted. Precisely why we adopted it on the >> Inter-Provider interface. >> >> >> /O >> >> >> Cheers, >> >> >> Ed Sayers >> Endpoint SDK Team Lead >> Purple, a Division of ZP Better Together, LLCpurplevrs.com >> >> >> The information contained in this e-mail message is intended >> only for the personal and confidential use of the recipient(s) >> named above. If you have received this communication in error, >> please notify us immediately by e-mail, and delete the >> original message. >> >> >> >> >> -----Original Message----- >> From: Rum > >> On Behalf Of Brian Rosen >> Sent: 30 August 2021 22:24 >> To: Paul Kyzivat > > >> Cc: Chad Leeper > >;rum@ietf.org >> >> Subject: Re: [Rum] IPv6 and encryption >> >> I don’t think there are ANY alternatives to SRTP.  There are >> alternatives to DTLS-SRTP.  There are moves within the IETF to >> deprecate SDES, specifically.  There is push back on that, but >> it’s an ongoing discussion because SDES isn’t secure enough. >>   Since all providers I know about anchor media, this only >> affects the initial hop.  Users really want to hear that their >> media is protected end to end (at least hop by hop) but our >> document doesn’t require that.  Again, we need a STANDARDS >> based solution, and we have to live within the constraints the >> IETF has for new standards with respect to security.  Like >> nearly every organization, the IETF is much more security >> conscious than it was, and won’t tolerate bad security >> although it often recognizes the necessity for backwards >> compatibility as long as it’s not to a known insecure mechanism. >> >> I really think this is a “step up to the bar” thing.  We’ve >> spent lots of time and cycles implementing things that turn >> out not to be secure enough, and we have to move forward on >> things that are.  DTLS-SRTP is one of those things, as is IPv6. >> >> Brian >> >> >> >> On Aug 30, 2021, at 5:06 PM, Paul Kyzivat >> > wrote: >> >> Chad, >> >> Welcome to the RUM WG! >> >> On 8/30/21 11:51 AM, Chad Leeper wrote: >> >> - While WebRTC w/ SRTP/DTLS (encryption) is an >> excellent idea going forward, it can't be a "MUST" >> requirement. I agree with Roger Slusser that mandating >> compliance using MUST requires providers to implement >> significant development to change over to what RUM is >> specifying. >> >> >> The requirements in this doc will apply only to devices >> that claim to >> conform to it. Presumably you could continue to support >> your existing >> devices using whatever mechanisms they currently use. So the >> implementation burden is only on the server side, not the >> legacy >> device side. (Of course the FCC will have a say in this.) >> >> One motivation for the webrtc requirement is so that a RUE >> can be >> built on top of WebRTC. E.g., it can be a server that >> supports deaf >> users using any device with a browser. Such a server is >> effectively >> just signaling gateway that can establish a p2p link >> between the >> browser and the VRS provider server. (It does have to >> transcode RTT, >> but that is less of a burden.) >> >> When defining a specification for an interface that is to >> be implemented by independent parties it is necessary for >> essential functions to have at least one mandatory to >> implement mechanism. Currently there are no standards for >> connecting a RUE to a provider, so we need to pick >> *something* to be mandatory to implement. If you have an >> alternative for the media you would prefer, then please >> make a specific proposal. >> >> >> - We should keep any new privacy requirements very >> minimal at this time.  While companies in the EU have >> already created their systems in compliance with the >> GDPR, most of the world hasn't created an equivalent >> yet.  So what may look like an easy change to EU >> implementers may be a dramatic change for others. >> >> >> I don't think we have said much about privacy of retained >> data. But we are concerned that the media and signaling be >> private between the RUE and the provider. That is a low >> bar these days. It is unlikely that anything less could be >> approved. I expect the FCC will agree. >> >> If you have an alternate proposal that achieves that then >> make a proposal we can discuss. >> >> Thanks, >> Paul >> >> >> On Fri, Aug 27, 2021 at 3:16 PM Paul Kyzivat >> > > >> wrote: >>  Providers, >>  My request below to Roger should have been broader. >> You all seem to >>  have >>  the same issue. I encourage any/all of you to make an >> alternative >>  proposal here. Just saying "we don't like what is >> there" isn't helpful >>  without an alternative. >>           Thanks, >>           Paul >>  On 8/26/21 5:40 PM, Paul Kyzivat wrote: >> >> Roger, >> >> On 8/26/21 3:30 PM, Roger Slusser wrote: >> >> >> Most providers already support encryption and >> IPV6 on a limited >> >>  scope, >> >> not necessarily the way it is defined in RUM >> spec. Mandating >> compliance using MUST requires providers to >> discard sometimes huge >> amounts of development to change over to what >> RUM is specifying. >> >>  The >> >> push back is not about doing these things it >> is about the loss of >> time, effort and money to do them in the way >> RUM mandates with >> >>  MUSTs. >> >> >> Do you think there is something else we could >> write in this spec >> >>  that >> >> covers encryption and IPv6 in a way that is less >> burdensome for >> providers while remaining interoperable with all >> providers? >> >> If so, can you please spell it out? >> >>  --     Rum mailing list >> Rum@ietf.org > > >> https://www.ietf.org/mailman/listinfo/rum >> >>  > > >> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> >> >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> >> -- >> Rum mailing list >> Rum@ietf.org >> https://www.ietf.org/mailman/listinfo/rum >> > >