From nobody Fri Feb 5 14:17:21 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 A739D3A0C7E; Fri, 5 Feb 2021 14:17:15 -0800 (PST) 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.25.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: rum@ietf.org Message-ID: <161256343562.29866.6213353287492521738@ietfa.amsl.com> Date: Fri, 05 Feb 2021 14:17:15 -0800 Archived-At: Subject: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 05 Feb 2021 22:17:16 -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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 5 14:26: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 224DF3A0C9D for ; Fri, 5 Feb 2021 14:26:40 -0800 (PST) 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 KDwI3hvd_k_H for ; Fri, 5 Feb 2021 14:26:37 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 977323A0C9A for ; Fri, 5 Feb 2021 14:26:37 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id f8so8817251ion.4 for ; Fri, 05 Feb 2021 14:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:references:to:date; bh=NMsaujrgOC2wnfrUBEmUq3+yCudvey2Hi7Sczbct7m0=; b=vbsbeFRb3Lj6S7ISF38l18D23JENN4BjaCfp/8p1NKYKSBOgZ4/M/cTbxQ+FD0fkp0 R5/bSPrcDpLaGg+tk3A6kthVfLCodvg8q7ZGu56pzMZ5vEXAnv/ZyFSWZF+mHId2VnGa i8h4ptneSBt3F7ePkP5EttQz62DjwzBUZApg8NiN/j+X21sj2wfXU+wo2joWXR8z3VGs blzFFlKl2vKnI/zgK+6v3ShseOM5lxkMOS28fhyjoqaldXyooVlP4NWDASbLN6wa7q5P xnN8M9t78bi3sT0mN1XUo+hioitpNdEdrPSA5KssKIp7oShMM6eEoYNXYhu0x8gCFbfr 6mNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=NMsaujrgOC2wnfrUBEmUq3+yCudvey2Hi7Sczbct7m0=; b=qTdGEIBHTbb8t9lTBho2iHT7J5KRDKDAHF6Ny4TI6CYPqmd12CvsrvZg0BFyaykVqk pNoXy3PHNeYWHEfL5XEU9ex41G4r49hSaXYoEL6Pl+nF9QUJMtURaTDZwD2tajT7P7PQ RlamaaEKFB050LEUuOzKmRIxYzWNsb6biOazdL/FGplpOrCsQnsP6ZAi3lW/W0zHx3kt NeARaUtNETWMo/QVUcdnF/M3K17/HpbHHxF7P/F0PUhIaBKWfELc99F6Ki0NyEaAAJXA sDjwOrpNyUZX8uDCIM+0QRfgMdrUVVsFx5iIwbFJLCpB7k89XFnOEEgOrG5uC9CQdpbQ 8Phg== X-Gm-Message-State: AOAM532sZFKTb4vD+Wt+wunw/m16FVgxdqLBSqAc1g3YQHpxJTy7vyVA 1yguSxYz7c12RvGIVlySdFpdyPskLTCYzIgv X-Google-Smtp-Source: ABdhPJzkCqyuKiOsmBz3xrkcKaPP3cibyAcVxg8bkAmjPhXBSgIRkcHfIyAXyCayXg0+cNvrpp9Qiw== X-Received: by 2002:a05:6602:1303:: with SMTP id h3mr6056429iov.149.1612563996477; Fri, 05 Feb 2021 14:26:36 -0800 (PST) Received: from brians-mbp.lan ([24.154.119.158]) by smtp.gmail.com with ESMTPSA id f9sm4658990ilu.36.2021.02.05.14.26.35 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2021 14:26:35 -0800 (PST) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_98F39EA6-BA42-4B46-8B45-82F749186DB0" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> To: rum@ietf.org Date: Fri, 5 Feb 2021 17:26:33 -0500 X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Fri, 05 Feb 2021 22:26:40 -0000 --Apple-Mail=_98F39EA6-BA42-4B46-8B45-82F749186DB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I have posted a -04 revision. This should handle all comments received = so far, please let me know if I forgot something. This version reworks the provider list and configuration sections along = the lines we have been discussing. I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-rum-rue-04.txt > Date: February 5, 2021 at 5:17:15 PM EST > To: > Cc: rum@ietf.org > Reply-To: internet-drafts@ietf.org, rum@ietf.org >=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-04.txt > Pages : 33 > Date : 2021-02-05 >=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-04.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=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 --Apple-Mail=_98F39EA6-BA42-4B46-8B45-82F749186DB0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.

This version reworks the = provider list and configuration sections along the lines we have been = discussing.

I = do not have a way to download a username/password from a new signup. =  I=E2=80=99m having trouble thinking about a secure way to do that. =  If anyone has an idea, I=E2=80=99m very willing to write text for = it.  I=E2=80=99ve considered things like javascript that stashes it = in a file or somewhere else, having some web page function that triggers = a local display of an entry form for username and password, and a couple = of other things.

One note on the configuration mechanism - because the only = thing the local RUE device needs to keep is the username password = against a provider ID of some kind, there isn=E2=80=99t any need to = standardize how that works, and so it=E2=80=99s completely absent in the = text.  

For= now, I=E2=80=99ve removed the step by step diagram that showed how the = config mechanism is used.  I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with.  I can bring back the diagram if that is = needed.

Brian


Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = I-D Action: = draft-ietf-rum-rue-04.txt
Date: = February 5, 2021 at 5:17:15 PM = EST
To: = <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: = internet-drafts@ietf.org, rum@ietf.org


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-04.txt
Pages =           : 33
= Date =            : = 2021-02-05

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-04.html

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


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

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


_______________________________________________
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

= --Apple-Mail=_98F39EA6-BA42-4B46-8B45-82F749186DB0-- From nobody Sat Feb 6 11:04:53 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 933B53A0ECB for ; Sat, 6 Feb 2021 11:04:47 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 CdxsgWbFwOpp for ; Sat, 6 Feb 2021 11:04:45 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2072.outbound.protection.outlook.com [40.107.236.72]) (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 2AE753A0EA4 for ; Sat, 6 Feb 2021 11:04:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WsnKBbxc7gEooTHg97xP7KbXi3lymhdrIkcS60GSJVQ5vV9IjywXrIbVHhjn94fXOnyQnhPcYUVbwjdlcItR6zgO1+jCyYH2OE18aKr62n4Qd55Id+eTEZnqPybr68hX+7G2choMN/9PuiB5ODEc+f24RjxXy1jqw/CIsN1pM0eeE+YRCT21BU8bHuDfd7EgIp7sX/0NzqqbsPWNKog+D61I3jdfx29adrpFNTIW9HTeG9tyJjisjW6Dfj4LHRrQGmjQhtgLQ4cog5mZz+fkAga80c+KrLjdRIkn6d2bNjTYt1+IvLp+MFbWG93WoF0U8dAV8qeOgtKPClt6BoilYw== 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=ZNnUIuLLvZ6MWuAf+9awZz5ltzYxaxDIwy7xUlUKqwU=; b=KMudn/LmLXjEkLLc78uQTss+jLfuOcoAsym4wUxDcbInDMabkhUGlqcSp0tLvHQu7X8g6i/GrvemrbWXydRAzX+rcI6nL/kdBL8FbUlfIOkeGzdZbtZ3qyp+OWmpOg+MQJLKGckAauK17ULbipuZZcu1OMJvFO1xJfQk3WccmH9bTAgcmDW7KwDTcnOJnER1n13iQPNiAUqpL5iTGACXBeK1Z60Uc5RyrMNRMRdYRuVu+YT/yxN4JzmN6TX5DV9wdgdFyh+QWRNxg2hYmQbY5WOGtXhF5aWqCCwNPuoberIAMPMUKN3hnLzR8CaH8I7lM3ABQkGRoS5ky7BP9ozSEg== 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=ZNnUIuLLvZ6MWuAf+9awZz5ltzYxaxDIwy7xUlUKqwU=; b=T8uvZpiDDi6dXwrq9PnIH8wO9Tu2eqKhZwQiC/gb4ZFYewm0ORjODgEamtzmdit3flCMrsZ0YCuF22+5LZm6Zo1ajoA2tTUqAjnT4yi1iF6Gt6Sra7xWwJcLpXbZ41LxA83fd8t+NJJB7s2zElc7Shzp8FgXbf2It0HJ8NzkN/w= Received: from SN7PR04CA0034.namprd04.prod.outlook.com (2603:10b6:806:120::9) by SN6PR12MB2766.namprd12.prod.outlook.com (2603:10b6:805:78::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.25; Sat, 6 Feb 2021 19:04:41 +0000 Received: from SN1NAM02FT015.eop-nam02.prod.protection.outlook.com (2603:10b6:806:120:cafe::b0) by SN7PR04CA0034.outlook.office365.com (2603:10b6:806:120::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.19 via Frontend Transport; Sat, 6 Feb 2021 19:04:41 +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 SN1NAM02FT015.mail.protection.outlook.com (10.152.72.109) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Sat, 6 Feb 2021 19:04:40 +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 116J4cfV013354 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 6 Feb 2021 14:04:39 -0500 To: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Sat, 6 Feb 2021 14:04:38 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@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: 383d0a11-dddb-4b21-aaaf-08d8cad20e77 X-MS-TrafficTypeDiagnostic: SN6PR12MB2766: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: K8tkwMeDq8hO9rv++QMok4+x6TvByKLN10MZZDNecvzM6iO5WaWJibeuJLLedCWWILrk28IQV+lGj1VvX3y+a1kOYvNPTJXYsABa3MHwUiUkiVBapZYbZn4S9W+37S7DTpOJ6PheuJLr+AKqfE0zKZbyXn81H3Xc3zS/wsRg6E9EZlGxTgbAOaCEgwkuXaAXLV5WgDmzy2A9RyDAJM+qL8bkV3kDYD8qV7eAVqkGOWdOMx/M/3H5xWmqoWL+pdDSDr/ntUhMUE4W30VgkILIO3F45xnJbGJsXar7Qrc/CSbPzAkhNV1UJhTXPH9+V0rh8NMxglBIDlB42kDd+H+hQSXmVeAUhVzQCexkB5HwJummtjsntz8zd+sTuiXOA9/pjHbpmEV/AczjnwLzuSKSVUh1vg84r1reP4/2Uc6DSCEC1iSKN7WvAH7owOz3asuCde4KwLieMoo8NPbzN2rl0y39H0gUm/2tPTcj5QXXRK09gfUnPNGN/Jp3/QrtBV9z+g6S/qUMvWNEr5XbH39uOvcRKt1mkjewg73nCT07+WI2mwB27YeaMfNX5PelK6vEvFnhbtTy1TnSx2qgEc/hLmBzRYjO11XUpbGL7U7BuL4HZrTnKd9+iSb20V5mq+mjy3OHoYKoAldOofJ86iFtGFSU91/ZPhCfdE8xpgsMcbUNwgWn//IVzkJ9Mr6bc1TJmhGTJ4aE2Sw2U29REpPNBn2jnrVn5XkJMuwy8kFt4+Q2H/tmQXki8SGSgl/N6RF8ghMzNpftP3SdbYGX2B4CLw== 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)(46966006)(36840700001)(83380400001)(31696002)(2616005)(478600001)(956004)(86362001)(966005)(31686004)(5660300002)(53546011)(66574015)(316002)(786003)(36906005)(82740400003)(82310400003)(8676002)(336012)(7596003)(356005)(70206006)(47076005)(8936002)(70586007)(75432002)(186003)(6916009)(36860700001)(26005)(2906002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2021 19:04:40.5672 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 383d0a11-dddb-4b21-aaaf-08d8cad20e77 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: SN1NAM02FT015.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR12MB2766 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Sat, 06 Feb 2021 19:04:52 -0000 On 2/5/21 5:26 PM, Brian Rosen wrote: > I have posted a -04 revision.  This should handle all comments received > so far, please let me know if I forgot something. > > This version reworks the provider list and configuration sections along > the lines we have been discussing. > > I do not have a way to download a username/password from a new signup. >  I’m having trouble thinking about a secure way to do that.  If anyone > has an idea, I’m very willing to write text for it.  I’ve considered > things like javascript that stashes it in a file or somewhere else, > having some web page function that triggers a local display of an entry > form for username and password, and a couple of other things. IMO it is ok for the RUE, when attempting to connect to the provider for the first time, to do a normal authentication prompt to the user. (I think it is reasonable to expect the user to be present at the first attempt to connect. This does have an implication on the interface. Right now an attempt to connect without a userid acts differently from one with a userid. It would be necessary to change this so that these are distinguished in some other way. Then a "normal" attempt to connect without a userid would result in an authentication challenge that the user can respond to. One reason I think this is ok is because we can't really assume that the user does the signup using a browser controlled by the RUE. The user might do this separately from a computer or phone, and perhaps even before obtaining the RUE. (In above, "attempt to connect" applies to sip register, mwi subscription, and request for configuration.) Thanks, Paul > One note on the configuration mechanism - because the only thing the > local RUE device needs to keep is the username password against a > provider ID of some kind, there isn’t any need to standardize how that > works, and so it’s completely absent in the text. > > For now, I’ve removed the step by step diagram that showed how the > config mechanism is used.  I think what is there is dead simple and > needs no explanation: it’s a straightforward REST/JSON web service using > username/password authentication for providers the user has accounts > with.  I can bring back the diagram if that is needed. > > Brian > > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **I-D Action: draft-ietf-rum-rue-04.txt* >> *Date: *February 5, 2021 at 5:17:15 PM EST >> *To: *> >> *Cc: *rum@ietf.org >> *Reply-To: *internet-drafts@ietf.org >> , rum@ietf.org >> >> >> 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-04.txt >> Pages           : 33 >> Date            : 2021-02-05 >> >> 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-04.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> 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 Sat Feb 6 14:08: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 B15663A2C88 for ; Sat, 6 Feb 2021 14:08:33 -0800 (PST) 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 InQprPZo_Opg for ; Sat, 6 Feb 2021 14:08:31 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2063.outbound.protection.outlook.com [40.107.92.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 35B6E3A0B12 for ; Sat, 6 Feb 2021 14:08:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YDze60DIU8dyCAa3vnpNW8D9d+1YeSyoLHA3+dlPPvIQwBSrp/zGqKj9Gpn5i2freeq8H9EpZscTCzL8/US+1MYE0A0e+swwlFc90Iwm2L72FUvd7YhiANo1Sy0KCg8lQNoop2rwiitnreJNqwx7uJg45ywkxt4Cu6xkHeowFueymk7cIXDkWu4hZ7QSKqRZyclSmWUe8GnqIEY7aYFSZB/z95OPRHkvcjZ41CchWGndZnm6ssc7uTeOPzP1PZ7YcEVhk8rPPjmWOB3piAUwtElv4Vq9tyIjizbrZ2BfxuiOkXGuVMS7Z8doB0mtz4eUFeym7+FqEUTYQGx262W+OQ== 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=3rOgJKohacpRlQGpm3Lx5bs7+832ir2Rz7Yr2m9wlXc=; b=BS7wcZPcUjzWJBlsCutmpXM4X8QUVrDPaN2aa87Qg3kAkSNK0lz/fKWlgbHI+GjqZU/NExbniIM/DcXieFu22brTZ7HgsdxXmKHKDi9NPKOCQgo5+T1qVAtngxuoS9oerCtv6MLb6SV1x1T/KbbHqBfn39Sg/Nu5Qv5LViE3LzCSbgthzszWLblUKEeiqgTZm9OOM9JvRtCSj1gNaOqf/Ic20AIyE39O4RMdKzXxVzT3JXJfCM4SzE8aio9t+jkwGKXyFpcLI/pek6c3/is6RhwThAk4u2EkIbUJpmjvHJDBKSpFGCpCweCa6fXs9D11B7ecnZyZtzEM6hz6bpdQcg== 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=3rOgJKohacpRlQGpm3Lx5bs7+832ir2Rz7Yr2m9wlXc=; b=Ld1K+Fl5kIeaVCuFt/SZtpHrlKdonKZwRDLlw/skP8Zd27yNAsj/DkDF0uZv0faHtOhyygI2gOq5iknlDuV0Mh5DXg3s6sh6gCtS5KQbiTlCPwpts7qMB59mosCW2WFsO9Ahap/0sUtXAlf842Tsnkj5cIE+Vzj5BwhYniDWKvI= Received: from SA9PR13CA0034.namprd13.prod.outlook.com (2603:10b6:806:22::9) by BL0PR12MB2545.namprd12.prod.outlook.com (2603:10b6:207:4e::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.16; Sat, 6 Feb 2021 22:08:29 +0000 Received: from SN1NAM02FT028.eop-nam02.prod.protection.outlook.com (2603:10b6:806:22:cafe::c1) by SA9PR13CA0034.outlook.office365.com (2603:10b6:806:22::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.10 via Frontend Transport; Sat, 6 Feb 2021 22:08:29 +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 SN1NAM02FT028.mail.protection.outlook.com (10.152.72.105) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Sat, 6 Feb 2021 22:08:28 +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 116M8QIc025851 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 6 Feb 2021 17:08:27 -0500 To: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Sat, 6 Feb 2021 17:08:26 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@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: 453b4564-961f-4de2-b396-08d8caebbbcd X-MS-TrafficTypeDiagnostic: BL0PR12MB2545: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5vzz2csTy8ywcVcO4o9Z9Muh9JbPoQYERcEmBAnXBvnlwh7JntbNhA8AOZtyGOWJpIn8gpslRArXZAD0sC2ZZ9fA3neBqKDUH7AZ4IqS5La6G/PAavQ9aNm2VlOdSxccqJugw0MOeprm4V6DUEQv1SYFx4sOyID8JBF/AaOj6ouT4ACcS1yluM3YoTVpwmsXaTzDzika7Y8K2M0YMtBlySwdlgN/QPYHwcRh1rvTooe9JAyepc/VjlXKpox0Be6m70XGzQJ4zShFijlxPmh32QjPZVq9RWOM3nTK6+t7IAIIys2ghxDE9FgAK1Rzq6gD9cVzXki/adKRU30FK2bKRjfKXdaDfqodJUh0/WCzrpC2ky1y+BxbloDbx64iUfMAcQC5p9vWN46CZSErQ5B/o/QupHuIAIwBrLAztFt32koTGqMc9Boz81/QUZdXdK7Lxtge+s2jeb3kE4V2B5JsLo3Zz+FT+67E8ClFk0hQ98JDTfXWdpLLzmhhWxFnWe9ar6cXf19RPj3y0y0vd/Wv1QDfRcziq/zjWkCbISQ2NcnBvhxLZFWLcbtzcATXkbZCGYqtYJ0xzFg0YAv9NxarSoljUukIE/LoK/9UNcxI6I9S52cusUKy7UYvYcFROp7fS+hGXy9t5WI2jm0scGcygPN3pChGmff8hjAcRtXUcz/HWGrcwfud/mzGUmWM6fCcjrwjtNPIG7T22bHYP70S66IXOtf4oH/0pfvllldndr7SEIRUoIdktANqWXJEiLqAB10PD0UgrWwZzLXMO4R5Yg== 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)(396003)(346002)(136003)(36840700001)(46966006)(53546011)(5660300002)(31686004)(956004)(786003)(82740400003)(70586007)(8936002)(47076005)(478600001)(966005)(36860700001)(7596003)(8676002)(2906002)(2616005)(83380400001)(316002)(336012)(26005)(82310400003)(66574015)(86362001)(31696002)(75432002)(36906005)(6916009)(356005)(186003)(70206006)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Feb 2021 22:08:28.6512 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 453b4564-961f-4de2-b396-08d8caebbbcd 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: SN1NAM02FT028.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR12MB2545 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Sat, 06 Feb 2021 22:08:34 -0000 Brian, Comments on this posted version: * "Dial-around call": what about inbound dial-around calls? Is there anything meaningful that we can say about them? IIUC the only way to achieve that is for the hearing user to dial the front door number of the provider he wants to handle the call. If that is the only way then the RUE and its user are not involved and so nothing can/should be said. * "RUE Interface": s/the VRS provider/a VRS provider/ * 5.2.4 Incoming Calls: This says: The RUE MUST only accept inbound calls sent to it by the proxy mentioned in the configuration. First, there can be multiple configured proxies, so s/the proxy/a proxy/. But IIUC if proxies are configured then the RUE is require to use [RFC5626] (Outbound). But the provider isn't required to support/use outbound. What is to happen with a provider that doesn't? Perhaps we need to separate the configuration of proxies from configuring the use of outbound with those proxies. If outbound *is* used then it is easy to determine that incoming calls arrive from the proxy. But if outbound *isn't* used then there isn't any obvious way for the RUE to figure this out. ISTM we either must *require* use of outbound, or remove this requirement to only accept calls from the configured proxy, or detail how to do this verification in the absence of outbound. (I think there may be some resistance to use of outbound in mobile RUEs because it can significantly increase the power demand.) * 9.1 RUE Provider Selection This section talks about backward compatibility without defining it. While people may have an intuitive understanding of it, they may not all understand it the same way. It may be better to define this as a requirement that if you advertise support for M.N you are also implicitly promising that you support M.i for 0<=i I have posted a -04 revision.  This should handle all comments received > so far, please let me know if I forgot something. > > This version reworks the provider list and configuration sections along > the lines we have been discussing. > > I do not have a way to download a username/password from a new signup. >  I’m having trouble thinking about a secure way to do that.  If anyone > has an idea, I’m very willing to write text for it.  I’ve considered > things like javascript that stashes it in a file or somewhere else, > having some web page function that triggers a local display of an entry > form for username and password, and a couple of other things. > > One note on the configuration mechanism - because the only thing the > local RUE device needs to keep is the username password against a > provider ID of some kind, there isn’t any need to standardize how that > works, and so it’s completely absent in the text. > > For now, I’ve removed the step by step diagram that showed how the > config mechanism is used.  I think what is there is dead simple and > needs no explanation: it’s a straightforward REST/JSON web service using > username/password authentication for providers the user has accounts > with.  I can bring back the diagram if that is needed. I still think that we need to discuss the flows that can occur *after* enrollment and initial use. Of particular note: passwords eventually must be changed, for a variety of reasons. E.g., user preference, provider age-out of a password, compromise of provider credential storage. In each case the RUE will need to discover this and update its credential store. The user will need to enter the password into the RUE, which means the user must be present at the RUE and either respond to a prompt to make the change or actively request to change it. If the need for a new password occurs when the user is not present at the RUE, then it probably means that the user will no longer have incoming phone service until he notices. That is potentially a safety problem. So we should consider how to minimize this case. For instance, a few days/weeks before the provider ages out the password, it should notify the user, so the user can actively change the password and update the RUE. Of course the provider can do this out-of-band via email, but it would be nice to have a way to cause the RUE to inform the user. E.g., perhaps a MESSAGE sent from the provider to the RUE, that the RUE can then display. (And when the provider does invalidate a password the RUE should have enough information so it can take action to alert the user that action is required on his part to restore service. But 401 or 404 responses are probably sufficient to trigger this.) Thanks, Paul > Brian > > >> Begin forwarded message: >> >> *From: *internet-drafts@ietf.org >> *Subject: **I-D Action: draft-ietf-rum-rue-04.txt* >> *Date: *February 5, 2021 at 5:17:15 PM EST >> *To: *> >> *Cc: *rum@ietf.org >> *Reply-To: *internet-drafts@ietf.org >> , rum@ietf.org >> >> >> 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-04.txt >> Pages           : 33 >> Date            : 2021-02-05 >> >> 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-04.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04 >> >> >> Please note that it may take a couple of minutes from the time of >> submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> 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 Mon Feb 8 16:48: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 560463A1033 for ; Mon, 8 Feb 2021 16:48:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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] 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 nBny2TCTUij8 for ; Mon, 8 Feb 2021 16:48:14 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2068.outbound.protection.outlook.com [40.107.243.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A0AC3A0E7F for ; Mon, 8 Feb 2021 16:48:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Iy3/jsAfBL2c2LN5iwjqwbGY/4e6zfHiB3VrEH1he/lrGyVjeRqxrxR6Pg5RYk/oUqOkhDmVlEi5hJZSkyWfsqctBvB4xpWETE6mFVKeYMSYJKQB1UXQ61ls+NhFd94NknZID6dyWf7ljhJmUUWDuqChAyjgaRrGfK9H/KnjDPbuFzUd4XRibxjNFi11lhSSczuO3PMTy0CIpAsnymOY+aq5NJmFOIqkZYhoXWlaTu31cR0jL7QXSiP+QSi6fVYmOKvs8+cKntBOxwsv6UGCpZVHBIXRbf3w9ZKXmGftGIAqcPTvDxZTRH4zqPoKcfiBqA5s/LA0wQDDabflQMTeHg== 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=LdcpGegyUuOeZm6hM5jn86LDrsI2Jcljos/mY5JMcN4=; b=YPrzruouOoHGkxAT/dXYO+/rzV45/6crUC+CmzlzQ+O2mu0vvN/te8YX7H3UANi8F+qzTg+OsTpjDmg2mda86igfCGNtr5iX/CjrddXGGhHgD5PcDm9CUZfxbTLVluJ5hOqyMSIpXGnemdtmrMPQG9169qZbG88Dw0YtODtYpX9Ltpnz8cPOLXxKLIURu0BzHlHgleoZ2B9QUJIvFduvFVVfi2Db2smo2xDdokEsLrmTfoK54ALj7jjtpTwQwD0OKrX7R3i3q1LZLXHLPrOwRYEkB2jH3ONHg6cTcOOseJFYZkA5WZdxSB40JzbP8B2SRJ0wBv7lc489Qam4/LL/1w== 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=LdcpGegyUuOeZm6hM5jn86LDrsI2Jcljos/mY5JMcN4=; b=IJ3Xaaw82nnW3ISC+KAn9FYfrJjpTDo1ywCTNFZCq/fnGWsW1nK9EaMXECVpw71RlxpukDnR+wHwVi0flAA+Y4ogiIK40wvtm2geeXtklhp5DifbzIi9F10UoNKOzY7SMZ2fQ2eZkgPwkBFmGcTiv29iFoX75dVy3CfcEXt5sCU= Received: from SN4PR0501CA0099.namprd05.prod.outlook.com (2603:10b6:803:42::16) by SA0PR12MB4381.namprd12.prod.outlook.com (2603:10b6:806:70::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.30; Tue, 9 Feb 2021 00:48:12 +0000 Received: from SN1NAM02FT041.eop-nam02.prod.protection.outlook.com (2603:10b6:803:42:cafe::7a) by SN4PR0501CA0099.outlook.office365.com (2603:10b6:803:42::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.11 via Frontend Transport; Tue, 9 Feb 2021 00:48: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 SN1NAM02FT041.mail.protection.outlook.com (10.152.72.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Tue, 9 Feb 2021 00:48:11 +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 1190m9wc031175 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 8 Feb 2021 19:48:10 -0500 To: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> From: Paul Kyzivat Message-ID: <2f782643-cd9d-0b37-6347-d01d5e759ad3@alum.mit.edu> Date: Mon, 8 Feb 2021 19:48:09 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.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: cd0625c4-52b8-4035-f194-08d8cc946092 X-MS-TrafficTypeDiagnostic: SA0PR12MB4381: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XFiHjq5YzpWDvxT60JfnC2wcbZkvYFqkS7UaAqUATqPNRgEqfAuIEHiuW2+lAlgAQnvw4jRRbgurntEIHkm8wyFm3G5+6DRbXZbKaoIHouW4qDBj1yXFzecpmSNKdTPa8ayLFdP55YdJ1/gt0kdiXvrU4wEeJKiYIkEDpnH11m8jGBcNk3TxH7796IxKopxLujX+hapTzVItZYtk7wDXQ6XXcPe8R6Y6KvYOXZ/7Zv3DQ8q4vETtj5MK1/hRlkXMbNSTreCGP7pyD7KbqbCKxAwzS/FJ3wv3O/uwz2BdOf2HHvgx7sm6QxCzkFHeYUC9iVOfAgC5ShBmBHC0BscPT0C1fz91o8rN0WtVDtAGESvTejZ+jXL44yOsWgS3tS3u5T/J0qo452s5aohjBbSwqL8nO2xIL39aQhM71DrDwneLX+T7KUcI7yLsgyi1OeN1zfZeWgGuPoxNd6Bt+3ihANg4Pxp6pgTyyiLjxEVrI2VBMxAQ93vx6RoAH91mTGo/mq1c0M3x40/Fo1GI8QoCYDYc7DMhquBzQxY25LJywoVBNqcd8WSe73104Q7WgInUnQsftOT/djYLXOLQF3rJh+9FxqO0sT3vyBBiduIINSVIWwjsrw4YVP4UMLeNrXdYQ0kURBWQ5ui2LpVk7KzyQIkYJTmsedYIttyGMNjO8A17Gw97hXBZrgyY1aFoViDn 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)(376002)(39860400002)(346002)(136003)(36840700001)(46966006)(956004)(336012)(5660300002)(26005)(186003)(36860700001)(70206006)(478600001)(86362001)(2906002)(8936002)(356005)(2616005)(82740400003)(8676002)(70586007)(31686004)(53546011)(7596003)(82310400003)(31696002)(83380400001)(36906005)(47076005)(6916009)(786003)(75432002)(316002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2021 00:48:11.7435 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: cd0625c4-52b8-4035-f194-08d8cc946092 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: SN1NAM02FT041.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA0PR12MB4381 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 00:48:17 -0000 Replying to myself with further thoughts... On 2/6/21 5:08 PM, Paul Kyzivat wrote: > I still think that we need to discuss the flows that can occur *after* > enrollment and initial use. > > Of particular note: passwords eventually must be changed, for a variety > of reasons. E.g., user preference, provider age-out of a password, > compromise of provider credential storage. > > In each case the RUE will need to discover this and update its > credential store. The user will need to enter the password into the RUE, > which means the user must be present at the RUE and either respond to a > prompt to make the change or actively request to change it. > > If the need for a new password occurs when the user is not present at > the RUE, then it probably means that the user will no longer have > incoming phone service until he notices. That is potentially a safety > problem. So we should consider how to minimize this case. > > For instance, a few days/weeks before the provider ages out the > password, it should notify the user, so the user can actively change the > password and update the RUE. Of course the provider can do this > out-of-band via email, but it would be nice to have a way to cause the > RUE to inform the user. E.g., perhaps a MESSAGE sent from the provider > to the RUE, that the RUE can then display. I realized that we already have a mechanism that providers could use to deliver this sort of notification: video mail. Given that, I will drop this concern. Thanks, Paul > (And when the provider does invalidate a password the RUE should have > enough information so it can take action to alert the user that action > is required on his part to restore service. But 401 or 404 responses are > probably sufficient to trigger this.) From nobody Mon Feb 8 16:49: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 11A533A1033 for ; Mon, 8 Feb 2021 16:49:00 -0800 (PST) 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 jatWrX_Jqb69 for ; Mon, 8 Feb 2021 16:48:56 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (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 4629F3A0EFA for ; Mon, 8 Feb 2021 16:48:56 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id q5so14586010ilc.10 for ; Mon, 08 Feb 2021 16:48:56 -0800 (PST) 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=wfz40183LUn1lYOWAvccQyb3EMB9VkNMTABnaSDtc9I=; b=Gw1o13FgjmUFCIFr2GdhmjW6FRjKbftARYux5dqkca23uGpswVJrZPqUT/mLi8l5Fp zM/GhzdHZySYSxhHYCRXk9T7XLZAZl5vt0c9yLcS4cSXI28rcouZfXpF/2Mi/g7Ty4u6 AQ0+I6OyLTsrwlAxF5DB6HqgCol70vUNoDwYRdFcs7rmHZxKTqCGpM/5DhKaktk0Jfo6 rcdMjGbFkm33fCTlLCk+d8wUf6KC3lru1fwFwkIjr8dAyxvFgVf4jGbTYZyPrA5z4JjB 2J5EB6bviqf/EYkfHdfqmQ9syVFI4oNhqHBuXAFON6x+a3DqhiSTxI51X6OvJQ+nnaTB vYiw== 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=wfz40183LUn1lYOWAvccQyb3EMB9VkNMTABnaSDtc9I=; b=FVoBYsvHCR68y5GSTOTMw6aX6cZ8zJy4bcSvKl0fj98Gop5MyEggYHIpoEepw/3LjX M+Fm6WoPd8f1E5mVd+xH/HcWalrokLNUs/oI7xj/9WVNPVe4qPernBr89jt5KBohrGO+ 8Luu6wR40jw1oFySebwUuvbsJ+15nNwZN1U6wUFR4k3a17T1UHfuVQY4CXRgwaySvXAu ii0ankEKpSQwFdZVWj6D7RWozxOKqbAmFzkknN5d+PdzeV9+kltRAwwaZriKk1A+73ZX o3Fa5YCrwqzIwtfL1GwfOX9atiIWY7JIOu7fiSBai4CWCxqE10zOanRTmBNYSnJZ93h9 hEgQ== X-Gm-Message-State: AOAM532ulg0aZALEgrkqhorI/KFjnNXo5XOrQ4DeKHSWOMxBkIkl4Sg4 W5nCPKbbKbXqeRskaBkaFJmpPgEUEr10X0Pw X-Google-Smtp-Source: ABdhPJzK15YU/WJ7PVwndcWhvSuOzHxmovhYqm0eq0UyLeKYOfFILF2UFL3JS6AYdK6zmUlQmDE2Aw== X-Received: by 2002:a05:6e02:20e8:: with SMTP id q8mr17507206ilv.205.1612831733951; Mon, 08 Feb 2021 16:48:53 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id i5sm9611466ilk.85.2021.02.08.16.48.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Feb 2021 16:48:53 -0800 (PST) From: Brian Rosen Message-Id: <3F27DC25-DED9-4669-BE8A-332F4C432824@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_B34EA3FE-F7EF-4628-896B-C6DE87F6DC5F" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 8 Feb 2021 19:48:51 -0500 In-Reply-To: Cc: rum@ietf.org To: Paul Kyzivat References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 00:49:00 -0000 --Apple-Mail=_B34EA3FE-F7EF-4628-896B-C6DE87F6DC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for the comments. Responses inline > On Feb 6, 2021, at 5:08 PM, Paul Kyzivat = wrote: >=20 > Brian, >=20 > Comments on this posted version: >=20 > * "Dial-around call": what about inbound dial-around calls? Is there = anything meaningful that we can say about them? IIUC the only way to = achieve that is for the hearing user to dial the front door number of = the provider he wants to handle the call. If that is the only way then = the RUE and its user are not involved and so nothing can/should be said. Yeah, the RUE doesn=E2=80=99t directly deal with them. They go to the = default provider, who forwards them to the RUE. Do we need to say that? >=20 > * "RUE Interface": s/the VRS provider/a VRS provider/ Fixed >=20 > * 5.2.4 Incoming Calls: >=20 > This says: >=20 > The RUE MUST only accept inbound calls sent to it by the proxy > mentioned in the configuration. >=20 > First, there can be multiple configured proxies, so s/the proxy/a = proxy/. Fixed >=20 > But IIUC if proxies are configured then the RUE is require to use = [RFC5626] (Outbound). But the provider isn't required to support/use = outbound. What is to happen with a provider that doesn't? Perhaps we = need to separate the configuration of proxies from configuring the use = of outbound with those proxies. Can we say that if multiple proxies are mentioned the provider MUST = support Outbound? >=20 > If outbound *is* used then it is easy to determine that incoming calls = arrive from the proxy. But if outbound *isn't* used then there isn't any = obvious way for the RUE to figure this out >=20 > ISTM we either must *require* use of outbound, or remove this = requirement to only accept calls from the configured proxy, or detail = how to do this verification in the absence of outbound. >=20 > (I think there may be some resistance to use of outbound in mobile = RUEs because it can significantly increase the power demand.) >=20 > * 9.1 RUE Provider Selection >=20 > This section talks about backward compatibility without defining it. = While people may have an intuitive understanding of it, they may not all = understand it the same way. >=20 > It may be better to define this as a requirement that if you advertise = support for M.N you are also implicitly promising that you support M.i = for 0<=3Di=20 > The phrase "The provider list is a json object" should perhaps say: = "The v1.0 provider list is a json object=E2=80=9D. Fixed >=20 > This way of handling versioning has one limitation: The manner of = retrieving the version list must remain supported for all future = versions. Alternatively, we might instead put some or all of this = version info into the IANA registry, so that future versions might = require some other sort of interface. Yes, the version mechanism has to remain available and at least = backwards compatible to V1. I don=E2=80=99t think that is a problem, = and there are no protocol police if some future work group breaks the = assumption. >=20 > * 9.2 RUE Configuration Service: >=20 > What is the intended purpose/use of the language tags? Should this = indicate the spoken language supported by the interpreter for = interacting with hearing people? Or the written language on a web = interface? Or the language used in finger spelling? Or different = versions of sign language? Sign language for interacting with the RUE user >=20 > For dialAround and helpDesk, should there be a URI or phone number or = both? How would the RUE and deaf user use the URI to initiate a call? = (Currently the spec constrains the To URI in a call to be based on an = E164 number.) We don't specify the UI, but presumably the RUE might = offer special UI for these, or not. If not then I guess it would have to = make this configuration info available somehow. Else these things could = be pre-populated in the address book. (I think that is how providers do = it today.) For the help desk, I wanted this to not require an existing relationship = with any provider. So it=E2=80=99s a SIP URI that doesn=E2=80=99t need = a proxy that establishes a video call to a sign-language capable helper. For dial around, it=E2=80=99s whatever it takes to video call = point-to-point using the default provider. In the US that would be a 10 = digit number that was in the iTRS Directory, but that might be different = in some other country Suggestions on wording? >=20 > Re "outbound-proxy": this needs to be a list/array to allow multiple = values. The example shows this (and calls the key "outbound-proxies") = but the description is singular and doesn't mention an array. I can fix that, but I want to ask if there is an actual use case for it? = Why would a provider have more than one URI for a particular user/phone = number? Happy to fix it, but we would need to say how the RUE uses it. = Incoming is clear (accept calls from any configured proxy). >=20 > The following: >=20 > The configuration API also provides the same version mechanism as > specified above in Section 9.1. The version of the configuration > service MAY be different than the version of the configuration > service. >=20 > has a problem. s/configuration service./provider list service./ Fixed >=20 > Finally, a style issue: The keywords are named in a mixture of = camelCase and hyphenated words. (Like snake-case but with hyphens = instead of underscores. I don't know of a name for this.) I think we = need to pick a consistent style. Pick one and I=E2=80=99ll fix everything to be consistent. I like = camelCase, but don=E2=80=99t care >=20 > * 9.4 OpenAPI Interface Descriptions >=20 > I don't know yaml, so I'm not going to attempt to comment on this now. = I'll aim to come back after studying up on it. >=20 > More inline below. >=20 > On 2/5/21 5:26 PM, Brian Rosen wrote: >> I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >> This version reworks the provider list and configuration sections = along the lines we have been discussing. >> I do not have a way to download a username/password from a new = signup. I=E2=80=99m having trouble thinking about a secure way to do = that. If anyone has an idea, I=E2=80=99m very willing to write text for = it. I=E2=80=99ve considered things like javascript that stashes it in a = file or somewhere else, having some web page function that triggers a = local display of an entry form for username and password, and a couple = of other things. >> One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. >> For now, I=E2=80=99ve removed the step by step diagram that showed = how the config mechanism is used. I think what is there is dead simple = and needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >=20 > I still think that we need to discuss the flows that can occur *after* = enrollment and initial use. >=20 > Of particular note: passwords eventually must be changed, for a = variety of reasons. E.g., user preference, provider age-out of a = password, compromise of provider credential storage. >=20 > In each case the RUE will need to discover this and update its = credential store. The user will need to enter the password into the RUE, = which means the user must be present at the RUE and either respond to a = prompt to make the change or actively request to change it. >=20 > If the need for a new password occurs when the user is not present at = the RUE, then it probably means that the user will no longer have = incoming phone service until he notices. That is potentially a safety = problem. So we should consider how to minimize this case. >=20 > For instance, a few days/weeks before the provider ages out the = password, it should notify the user, so the user can actively change the = password and update the RUE. Of course the provider can do this = out-of-band via email, but it would be nice to have a way to cause the = RUE to inform the user. E.g., perhaps a MESSAGE sent from the provider = to the RUE, that the RUE can then display. >=20 > (And when the provider does invalidate a password the RUE should have = enough information so it can take action to alert the user that action = is required on his part to restore service. But 401 or 404 responses are = probably sufficient to trigger this.) Since, at the moment, there is no mechanism other than manual entry for = the RUE to learn the username and password, I think all of this is also = manual. We could add mechanism for a password update if that=E2=80=99s = helpful without the initial password capture, but that would only be = secure if it used the old password to authenticate to update to a new = one. =20 >=20 > Thanks, > Paul >=20 >> Brian >>> Begin forwarded message: >>>=20 >>> *From: *internet-drafts@ietf.org = > >>> *Subject: **I-D Action: draft-ietf-rum-rue-04.txt* >>> *Date: *February 5, 2021 at 5:17:15 PM EST >>> *To: * = >> >>> *Cc: *rum@ietf.org > >>> *Reply-To: *internet-drafts@ietf.org = >, rum@ietf.org = > >>>=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-04.txt >>> Pages : 33 >>> Date : 2021-02-05 >>>=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-04.html >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org. >>>=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 = --Apple-Mail=_B34EA3FE-F7EF-4628-896B-C6DE87F6DC5F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for the comments.  Responses inline

On Feb 6, 2021, at 5:08 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

Brian,

Comments on this posted version:

* "Dial-around call": what about = inbound dial-around calls? Is there anything meaningful that we can say = about them? IIUC the only way to achieve that is for the hearing user to = dial the front door number of the provider he wants to handle the call. = If that is the only way then the RUE and its user are not involved and = so nothing can/should be said.
Yeah, the RUE = doesn=E2=80=99t directly deal with them.  They go to the default = provider, who forwards them to the RUE.  Do we need to say = that?


* "RUE = Interface": s/the VRS provider/a VRS provider/
Fixed

*  5.2.4 Incoming Calls:

This says:

  The RUE MUST only accept inbound calls sent to it = by the proxy
  mentioned in the configuration.

First, there can be multiple = configured proxies, so s/the proxy/a proxy/.
Fixed

But IIUC if proxies are configured then the RUE is require to = use [RFC5626] (Outbound). But the provider isn't required to support/use = outbound. What is to happen with a provider that doesn't? Perhaps we = need to separate the configuration of proxies from configuring the use = of outbound with those proxies.
Can we say that if = multiple proxies are mentioned the provider MUST support = Outbound?


If outbound *is* used then it is easy to determine that = incoming calls arrive from the proxy. But if outbound *isn't* used then = there isn't any obvious way for the RUE to figure this = out

ISTM we = either must *require* use of outbound, or remove this requirement to = only accept calls from the configured proxy, or detail how to do this = verification in the absence of outbound.

(I think there may be some resistance to use of outbound in = mobile RUEs because it can significantly increase the power = demand.)

* 9.1 RUE = Provider Selection

This section talks about backward compatibility without = defining it. While people may have an intuitive understanding of it, = they may not all understand it the same way.

It may be better to define this = as a requirement that if you advertise support for M.N you are also = implicitly promising that you support M.i for 0<=3Di<N. (There = will be implications on how the spec for a new minor version is defined = in order to make it feasible for implementations to make this guarantee, = but we need not go into that.)
I reworded it to = say:
To achieve backwards compatibility, implementations MUST = ignore any object members they do not implement and minor version = definitions SHALL only add objects, non-required members of existing = objects, and non-mandatory-to use functions and SHALL NOT delete any = objects, members of objects or functions.  This means an = implementation of a specific major version and minor version is = backwards compatible with all minor versions of the major = version. 



The phrase "The provider list is = a json object" should perhaps say: "The v1.0 provider list is a json = object=E2=80=9D.
Fixed


This way of handling versioning = has one limitation: The manner of retrieving the version list must = remain supported for all future versions. Alternatively, we might = instead put some or all of this version info into the IANA registry, so = that future versions might require some other sort of = interface.
Yes, the version mechanism has to = remain available and at least backwards compatible to V1.  I = don=E2=80=99t think that is a problem, and there are no protocol police = if some future work group breaks the assumption.


* 9.2 RUE Configuration = Service:

What is the = intended purpose/use of the language tags? Should this indicate the = spoken language supported by the interpreter for interacting with = hearing people? Or the written language on a web interface? Or the = language used in finger spelling? Or different versions of sign = language?
Sign language for interacting with = the RUE user


For dialAround and helpDesk, should there be a URI or phone = number or both? How would the RUE and deaf user use the URI to initiate = a call? (Currently the spec constrains the To URI in a call to be based = on an E164 number.) We don't specify the UI, but presumably the RUE = might offer special UI for these, or not. If not then I guess it would = have to make this configuration info available somehow. Else these = things could be pre-populated in the address book. (I think that is how = providers do it today.)
For the help desk, = I wanted this to not require an existing relationship with any provider. =  So it=E2=80=99s a SIP URI that doesn=E2=80=99t need a proxy that = establishes a video call to a sign-language capable = helper.

For dial around, it=E2=80=99s = whatever it takes to video call point-to-point using the default = provider.  In the US that would be a 10 digit number that was in = the iTRS Directory, but that might be different in some other = country

Suggestions on = wording?


Re "outbound-proxy": this needs to be a list/array to allow = multiple values. The example shows this (and calls the key = "outbound-proxies") but the description is singular and doesn't mention = an array.
I can fix that, but I want to ask = if there is an actual use case for it?  Why would a provider have = more than one URI for a particular user/phone number?  Happy to fix = it, but we would need to say how the RUE uses it.  Incoming is = clear (accept calls from any configured proxy).

The following:

  The configuration API also provides the same = version mechanism as
  specified above in Section 9.1.  The version = of the configuration
  service MAY be different than the version of the = configuration
  service.

has a problem. s/configuration service./provider list = service./
Fixed

Finally, a style issue: The keywords are named in a mixture = of camelCase and hyphenated words. (Like snake-case but with hyphens = instead of underscores. I don't know of a name for this.) I think we = need to pick a consistent style.
Pick one and = I=E2=80=99ll fix everything to be consistent.  I like camelCase, = but don=E2=80=99t care

* 9.4 OpenAPI Interface Descriptions

I don't know yaml, so I'm not = going to attempt to comment on this now. I'll aim to come back after = studying up on it.

More inline below.

On 2/5/21 5:26 PM, Brian Rosen wrote:
I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.
This version reworks the provider list and configuration = sections along the lines we have been discussing.
I do not = have a way to download a username/password from a new signup. =   I=E2=80=99m having trouble thinking about a secure way to do = that.  If anyone has an idea, I=E2=80=99m very willing to write = text for it.  I=E2=80=99ve considered things like javascript that = stashes it in a file or somewhere else, having some web page function = that triggers a local display of an entry form for username and = password, and a couple of other things.
One note on the = configuration mechanism - because the only thing the local RUE device = needs to keep is the username password against a provider ID of some = kind, there isn=E2=80=99t any need to standardize how that works, and so = it=E2=80=99s completely absent in the text.
For now, = I=E2=80=99ve removed the step by step diagram that showed how the config = mechanism is used.  I think what is there is dead simple and needs = no explanation: it=E2=80=99s a straightforward REST/JSON web service = using username/password authentication for providers the user has = accounts with.  I can bring back the diagram if that is needed.

I still think that we need to discuss the flows that can = occur *after* enrollment and initial use.

Of particular note: passwords eventually must be changed, for = a variety of reasons. E.g., user preference, provider age-out of a = password, compromise of provider credential storage.

In each case the RUE will need = to discover this and update its credential store. The user will need to = enter the password into the RUE, which means the user must be present at = the RUE and either respond to a prompt to make the change or actively = request to change it.

If the need for a new password occurs when the user is not = present at the RUE, then it probably means that the user will no longer = have incoming phone service until he notices. That is potentially a = safety problem. So we should consider how to minimize this = case.

For instance, = a few days/weeks before the provider ages out the password, it should = notify the user, so the user can actively change the password and update = the RUE. Of course the provider can do this out-of-band via email, but = it would be nice to have a way to cause the RUE to inform the user. = E.g., perhaps a MESSAGE sent from the provider to the RUE, that the RUE = can then display.

(And when the provider does invalidate a password the RUE = should have enough information so it can take action to alert the user = that action is required on his part to restore service. But 401 or 404 = responses are probably sufficient to trigger this.)
Since, at the moment, there is no = mechanism other than manual entry for the RUE to learn the username and = password, I think all of this is also manual.  We could add = mechanism for a password update if that=E2=80=99s helpful without the = initial password capture, but that would only be secure if it used the = old password to authenticate to update to a new one. =   


= Thanks,
= Paul

Brian
Begin = forwarded message:

*From: *internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>
*Subject:= **I-D Action: draft-ietf-rum-rue-04.txt*
*Date: *February = 5, 2021 at 5:17:15 PM EST
*To: *<i-d-announce@ietf.org <mailto:i-d-announce@ietf.org>>
*Cc: = *rum@ietf.org <mailto:rum@ietf.org>
*Reply-To: *internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>, rum@ietf.org <mailto:rum@ietf.org>


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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/ <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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04


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

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


_______________________________________________
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

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

= --Apple-Mail=_B34EA3FE-F7EF-4628-896B-C6DE87F6DC5F-- From nobody Tue Feb 9 01:42: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 976573A1382 for ; Tue, 9 Feb 2021 01:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYt57nGIS3YB for ; Tue, 9 Feb 2021 01:42:42 -0800 (PST) Received: from outbound-ip1b.ess.barracuda.com (outbound-ip1b.ess.barracuda.com [209.222.82.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04B6F3A1315 for ; Tue, 9 Feb 2021 01:42:41 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx-outbound45-75.us-east-2c.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 09 Feb 2021 09:42:37 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 Feb 2021 01:42:34 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Tue, 9 Feb 2021 01:42:34 -0800 From: James Hamlin To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/A3/JZJYiPUG8kiCihuriWBBqKpPkw0X Date: Tue, 9 Feb 2021 09:42:33 +0000 Message-ID: <1612863753040.41656@purple.us> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com>, <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> In-Reply-To: <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_161286375304041656purpleus_" MIME-Version: 1.0 X-BESS-ID: 1612863754-111595-5565-50624-1 X-BESS-VER: 2019.1_20210208.2004 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230166 [from cloudscan11-52.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 09:42:45 -0000 --_000_161286375304041656purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian Section 5.1 Registration says that "The credentials to be used (username an= d password) MUST be supplied within the credentials section of the configur= ation and identified by the realm the registrar uses in a digest challenge.= This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 draft, password= s are no longer returned in the configuration. I think we need to avoid the= RUM RUE caching the user's main account password, which this draft seems t= o require. Best regards James James Hamlin Contractor 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: Rum on behalf of Brian Rosen Sent: 05 February 2021 22:26 To: rum@ietf.org Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt I have posted a -04 revision. This should handle all comments received so = far, please let me know if I forgot something. This version reworks the provider list and configuration sections along the= lines we have been discussing. I do not have a way to download a username/password from a new signup. I= =92m having trouble thinking about a secure way to do that. If anyone has = an idea, I=92m very willing to write text for it. I=92ve considered things= like javascript that stashes it in a file or somewhere else, having some w= eb page function that triggers a local display of an entry form for usernam= e and password, and a couple of other things. One note on the configuration mechanism - because the only thing the local = RUE device needs to keep is the username password against a provider ID of = some kind, there isn=92t any need to standardize how that works, and so it= =92s completely absent in the text. For now, I=92ve removed the step by step diagram that showed how the config= mechanism is used. I think what is there is dead simple and needs no expl= anation: it=92s a straightforward REST/JSON web service using username/pass= word authentication for providers the user has accounts with. I can bring = back the diagram if that is needed. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-rum-rue-04.txt Date: February 5, 2021 at 5:17:15 PM EST To: > Cc: rum@ietf.org Reply-To: internet-drafts@ietf.org, rum@ie= tf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_161286375304041656purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Brian


Section 5.1 Registration says that "The credentials to be used (use= rname and password) MUST be supplied within the credentials section of the = configuration and identified by the realm the registrar uses in a digest ch= allenge. This username/password combination SHOULD NOT be the same as that used for other purposes, such as retrieving= the RUE configuration or logging into the Provider's customer service port= al.". However, in the 04 draft, passwords are no longer retu= rned in the configuration. I think we need to avoid the RUM RUE caching the user's main account password, which this draft see= ms to require.


Best regards


James





James Hamlin
Contractor
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 <= /div>
message.


From: Rum <rum-bounces= @ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt
 
I have posted a -04 revision.  This should handle all comments re= ceived so far, please let me know if I forgot something.

This version reworks the provider list and configuration se= ctions along the lines we have been discussing.

I do not have a way to download a username/password from a = new signup.  I=92m having trouble thinking about a secure way to do th= at.  If anyone has an idea, I=92m very willing to write text for it. &= nbsp;I=92ve considered things like javascript that stashes it in a file or somewhere else, having some web page function that trigger= s a local display of an entry form for username and password, and a couple = of other things.

One note on the configuration mechanism - because the only = thing the local RUE device needs to keep is the username password against a= provider ID of some kind, there isn=92t any need to standardize how that w= orks, and so it=92s completely absent in the text.  

For now, I=92ve removed the step by step diagram that showe= d how the config mechanism is used.  I think what is there is dead sim= ple and needs no explanation: it=92s a straightforward REST/JSON web servic= e using username/password authentication for providers the user has accounts with.  I can bring back the diagram i= f that is needed.

Brian


Begin forwarded message:

From: internet= -drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-annou= nce@ietf.org>
Cc: rum@ietf.org
Reply-To: int= ernet-drafts@ietf.org, rum@ietf.org


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

       Title     &nb= sp;     : Interoperability Profile for Relay User = Equipment
       Author     &n= bsp;    : Brian Rosen
Filename &n= bsp;      : draft-ietf-rum-rue-04.txt
Pages  = ;         : 33
Date  =           : 2021-02-05
Abstract:
  Video Relay Service (VRS) is a term used to describe a method b= y
  which a hearing persons can communicate with deaf/Hard of Heari= ng
  user using an interpreter ("Communications Assistant"= ) connected via
  a videophone to the deaf/HoH user and an audio telephone call t= o the
  hearing user.  The CA interprets using sign language on th= e
  videophone link and voice on the telephone link.  Often th= e
  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 ser= vice,
  and subsequently to CAs and other deaf/HoH users.  It is d= esirable
  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 t= hat
  video calls direct between deaf/HoH users work.  This docu= ment
  describes the interface between a videophone and a provider.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.o= rg/doc/draft-ietf-rum-rue/

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


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

--_000_161286375304041656purpleus_-- From nobody Tue Feb 9 05:43:50 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 2D5A83A0BC5 for ; Tue, 9 Feb 2021 05:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 2FeP4i_xzteR for ; Tue, 9 Feb 2021 05:43:45 -0800 (PST) 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 48C5F3A0BA0 for ; Tue, 9 Feb 2021 05:43:45 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id m17so8225084ioy.4 for ; Tue, 09 Feb 2021 05:43:45 -0800 (PST) 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=x3PA4AYgGZUe2Ls5qKYtiIGa3aRVKrtnQ7sCPVPnicQ=; b=FcDFaVoKaHjxR9Ht+DT1v/8oAumobv3CgymIBxbwX0dc7J+QoEN4gJvjuo3+PVfFUc cuQdYoEDel9VyF4iY/cIaORYM7N/+EDdQJYYO9cAz2dJk6qFNEJBUPVjYZ3hPF0GkEmp +XZJdq6Q7t5G8idMk1FUI33C+2wKW+Zk8eU2IU9jY4fRNcOpdDG6a1WW6bLZ+nyJe0Wm oUsd8yctEmyo7a2APm3PV9L+ZoPtLBiwgkVMg01Q9EoBHj49lRt8V1oW07APrcHwecKh 7MzWc7w0rICPsxlzK8KosgxMAMWwFBH7nwS9lBu6o7XsqoFgpVRsGobjSFQohHBFXO8w A5Rg== 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=x3PA4AYgGZUe2Ls5qKYtiIGa3aRVKrtnQ7sCPVPnicQ=; b=H8fAjlcvHUeFsyKpyVLhBHPsQKkVlcMUdKg+hlUnXH1D1OC9oZ6/vTN2hLVdHCjHxO 5aWYnwMfNE61BAywxg6pYKCuyjlmkq8vKRaFWEkOL83cl8rKRBbkDCUqzz393JMzLacl nwijJEpaEBUrYjaU8QB9QI5cK+676JIRaeNwSHGyIM/CmTx7eWWh8BpIKXz7T2aX63RV NeNwUIor0dOVP0iGRz+e22+cuZykJR9FL7mOjIsihqPErbmvYDNpqjo3Yp4VL8wbPLVV /q0phrY+DCjBeLMJzjXe0SfCAKrEG6bAwfkWU+k9fcTtZd3FpnDIIuKoSav2H3R2y3b7 E7Kw== X-Gm-Message-State: AOAM532QlL9/DiaGjEWha0IEf9n/tczDJXPCRjjEuYMnpCAJUGmBooWm Tm5V4GPi1v+2yzsI1yDjnHsKZDzWuujryDe8 X-Google-Smtp-Source: ABdhPJzsmu2x1waTDuEkQ8/zbTXL1LYB6YVB7cSCxxEc5zm8Re0Rj/QBEKlGZkfSnmYuYpnFxo4V9w== X-Received: by 2002:a6b:e006:: with SMTP id z6mr19349763iog.110.1612878224564; Tue, 09 Feb 2021 05:43:44 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id d2sm10613442ilr.66.2021.02.09.05.43.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 05:43:42 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_197A18CC-F20D-4910-9AC2-350FDE3E98D8" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 9 Feb 2021 08:43:41 -0500 In-Reply-To: <1612863753040.41656@purple.us> Cc: "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 13:43:48 -0000 --Apple-Mail=_197A18CC-F20D-4910-9AC2-350FDE3E98D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I=E2=80=99ll delete the text in registration. =20 Every VoIP phone I=E2=80=99ve ever seen or used caches username and = passwords for stand alone use. Every one. They do that for a simple = reason - so incoming calls work after a power loss. Most also are = effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? The text currently uses the same credentials for the HTTP service and = the SIP service, but that=E2=80=99s it. I think that=E2=80=99s pretty = reasonable. If you have another proposal for how we can maintain the config data = securely, please suggest one. Brian > On Feb 9, 2021, at 4:42 AM, James Hamlin = wrote: >=20 > Brian >=20 > Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >=20 > Best regards >=20 > James >=20 >=20 >=20 >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Rum on behalf of Brian Rosen = > Sent: 05 February 2021 22:26 > To: rum@ietf.org > Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt > =20 > I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >=20 > This version reworks the provider list and configuration sections = along the lines we have been discussing. >=20 > I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. >=20 > One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >=20 > For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >=20 > Brian >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-ietf-rum-rue-04.txt >> Date: February 5, 2021 at 5:17:15 PM EST >> To: > >> Cc: rum@ietf.org >> Reply-To: internet-drafts@ietf.org , = rum@ietf.org >>=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-04.txt >> Pages : 33 >> Date : 2021-02-05 >>=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-04.html = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=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 --Apple-Mail=_197A18CC-F20D-4910-9AC2-350FDE3E98D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I=E2=80=99ll delete the text in registration.  
Every VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use.  Every one.  They = do that for a simple reason - so incoming calls work after a power loss. =  Most also are effectively set and forget, which is what you want = in a phone.  Why would we require manual entry for the = RUE?

The text = currently uses the same credentials for the HTTP service and the SIP = service, but that=E2=80=99s it.  I think that=E2=80=99s pretty = reasonable.

If = you have another proposal for how we can maintain the config data = securely, please suggest one.

Brian

On Feb = 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> wrote:

Brian

Section 5.1 = Registration says that "The credentials to be used (username and = password) MUST be supplied within the credentials section of the = configuration and identified by the realm the registrar uses in a digest = challenge. This username/password combination SHOULD NOT be the same as = that used for other purposes, such as retrieving the RUE configuration = or logging into the Provider's customer service portal.". However, = in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require.

Best regards

James




James Hamlin
Contractor
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: Rum= <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt
 
I have posted a -04 revision.  This should handle all = comments received so far, please let me know if I forgot something.

This version reworks the = provider list and configuration sections along the lines we have been = discussing.

I = do not have a way to download a username/password from a new signup. =  I=E2=80=99m having trouble thinking about a secure way to do that. =  If anyone has an idea, I=E2=80=99m very willing to write text for = it.  I=E2=80=99ve considered things like javascript that stashes it = in a file or somewhere else, having some web page function that triggers = a local display of an entry form for username and password, and a couple = of other things.

One note on the configuration mechanism - because the only = thing the local RUE device needs to keep is the username password = against a provider ID of some kind, there isn=E2=80=99t any need to = standardize how that works, and so it=E2=80=99s completely absent in the = text.  

For= now, I=E2=80=99ve removed the step by step diagram that showed how the = config mechanism is used.  I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with.  I can bring back the diagram if that is = needed.

Brian


Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04

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

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


_______________________________________________
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



= --Apple-Mail=_197A18CC-F20D-4910-9AC2-350FDE3E98D8-- From nobody Tue Feb 9 06:18: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 D29733A0D3A for ; Tue, 9 Feb 2021 06:18:55 -0800 (PST) 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 cHd1mzVj4tnF for ; Tue, 9 Feb 2021 06:18:51 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2083.outbound.protection.outlook.com [40.107.93.83]) (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 6C0F23A0D3C for ; Tue, 9 Feb 2021 06:18:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=br+byjVmpanMNHLf5NsymKItCRtamXuKaGNrmH13ZuUOsCfe9ovXqkLzy5PXXAji+PoUnS2c/Nm0rjpmC1WG0HHAMpECE4S78e7dCE2iCZv9jjWdZoWCvpAauaP3l5He+7yRkn8qCW9Oe5VT4KQzqxivZdk/n7Twq29PsH3G7B42Gmz4GymUoyqMO9YHwqJ0CyMgndDZIPkafGFExWt99WkWfmCsdVGe8kmJr4CoJILJNIZHMXJUeB2ghBVBGDHWk0eAMIOAtuwtnm3rl1OvpEF9rxiPtIbzuI1CYDxqjY37Wdz9YbclSA52Mu7zjZiZBmgsa/CtNwZBSFl/yFR2zg== 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=pTritHF0b3GsPqcwP/pBSyJkt+pq531R0CIXwVQCqso=; b=azU5OyD0l4bSHBNdyIy6B9mDSaCsALCygAdGF+wjdV5TUba8Lt3K3RQ1tRIjIbuwbrqMfPtQQVHA0vvdDBBxQVwqBrFgusDcjpdZ+KB0j/7FoXHZaPkjIvATbBx40wtbhcFK6V6W+TzzXUc+hHhula+v0t8kcwUHMe/GZ1mWW7HF+dSBQhMbKACMJhPmxFNKrYWzM57Ikro9ZR5nyoMZz327IOnyIaGldYBe2L/uEq8O5p4SiQ8J5puYTcfQntMg6McLgOqZU0jILDWwy/wQB0i/bKvSNJjH/JtEiu3n8PNwz5mQrPrikBE9RLD2PrYUu68qY0E10AAsRvL5nNC5Mg== 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=pTritHF0b3GsPqcwP/pBSyJkt+pq531R0CIXwVQCqso=; b=hJn8V+ffDJqQ3c8k2xC8/kV5BkPnzvnD9kKpmYXmbg9TQ6Rbb2dkHuewTHkAhio6+6EuUJFWIgxs+f7Y4GuBdKrh/+fsTSMACZrhOsCye0LEO5l5h4yKCnjdsCYK+gnWw+fGHjPpAdf+flgeUgHBHrVqL7oT2E0ihANaosFkrC8= Received: from BL0PR0102CA0036.prod.exchangelabs.com (2603:10b6:207:18::49) by MN2PR12MB3887.namprd12.prod.outlook.com (2603:10b6:208:168::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.30; Tue, 9 Feb 2021 14:18:49 +0000 Received: from BL2NAM02FT057.eop-nam02.prod.protection.outlook.com (2603:10b6:207:18:cafe::4) by BL0PR0102CA0036.outlook.office365.com (2603:10b6:207:18::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.21 via Frontend Transport; Tue, 9 Feb 2021 14:18:49 +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 BL2NAM02FT057.mail.protection.outlook.com (10.152.77.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Tue, 9 Feb 2021 14:18:48 +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 119EIkAE021567 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 9 Feb 2021 09:18:47 -0500 To: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> From: Paul Kyzivat Message-ID: Date: Tue, 9 Feb 2021 09:18:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.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: fb1e2413-e076-4c4d-0549-08d8cd059e30 X-MS-TrafficTypeDiagnostic: MN2PR12MB3887: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 5kmVwXw4CGGpehOB2u4QDaQCUcP99LZteC74BCpT2ClghWH+yuS5HVul88HdLXXM7iz+nM2NjTtQq1TWFRkaxyGbvAza1jSKjZOegE83nEBVp2xaxp/le5dseiT6KX6Txz4cHb5uw6XfyBDzW0Pa//UokAYqK+cJF+ZmZ5Wv77H+Wu/wHeB6rrzjlGgBHQRmYDPnt8efPHS/ERZeKW4nvX0xIBtt2G4wl4lYpUgKjykT/oLN1We95ULY4PjHx/kWTzmUkUihpiIeZafEdHYPQlBT2H4vvQWzAANsgcsfDbUlrW/lnfisRq8D4tLra8GFaVS14biE5etx+ULm/TpUlOyq+9w9h5EEs6T/lUyV583j+NYKu242ZGt81VYYhAafv212+PAzMfE1kMlIa3hSVfCAD32g7XzAZ1ukWdPL4Z9sYDupcljHmFreRgM5DmUiaAIhjHehxwX3BExJz8rVATm/Xe2IZGrk5BUx9LeikN/LqhLoOSk09NmknFdOb1PA9lrpqlY8k5DCPQStQx9koQdRVdRW1/BpL8MOoOuPmJZV89P54uxf1VtuG/dF4jhFnO4hs1uHITEsBTssAEaucJO/thO8zEajCVCOdYB1v2bFpQf+qClR3NAWypwB/F7lbHNn7ZTyArbYjCiJtgPSIrXXHYwBs0F1119mle1mTMP2Fzt+g2vnvVfjkHtNxU85wWL6fvTIAMy7SbTGgMMre9idhpf0Ma20rI9RQ858pB6FoGA8c33c2gwHiyNAUc8wgq9U4kGVf2+pV4i30JNXZA== 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)(46966006)(36840700001)(316002)(18074004)(786003)(53546011)(336012)(36906005)(70586007)(5660300002)(2616005)(70206006)(186003)(8936002)(956004)(36860700001)(7596003)(83380400001)(6916009)(356005)(31696002)(86362001)(82740400003)(478600001)(82310400003)(2906002)(26005)(47076005)(8676002)(966005)(66574015)(31686004)(75432002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2021 14:18:48.4203 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: fb1e2413-e076-4c4d-0549-08d8cd059e30 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: BL2NAM02FT057.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB3887 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 14:18:56 -0000 On 2/9/21 8:43 AM, Brian Rosen wrote: > I’ll delete the text in registration. > Every VoIP phone I’ve ever seen or used caches username and passwords > for stand alone use.  Every one.  They do that for a simple reason - so > incoming calls work after a power loss.  Most also are effectively set > and forget, which is what you want in a phone.  Why would we require > manual entry for the RUE? > > The text currently uses the same credentials for the HTTP service and > the SIP service, but that’s it.  I think that’s pretty reasonable. > > If you have another proposal for how we can maintain the config data > securely, please suggest one. I've been asking about this for awhile. As currently structured, it is up to the provider to agree with the user on which id/pw to be used by the RUE. That *could* be the same as the user uses to access the provider's web site for general administration, or it could be different. I agree with Brian that it makes sense to me to use the same credentials for sip and the configuration service. I have a little more doubt about the credentials for CardDAV. There are public implementations of this (e.g., Gooogle Contacts) that might be used, and could be configured. It probably wouldn't make sense to share credentials here. OTOH, maybe the *configured* CardDAV service would only apply for one managed by the provider. If the user wants to use a public CardDAV service perhaps he would independently configure that on the RUE, independent of provider configuration. We should perhaps talk further about this. Thanks, Paul > Brian > >> On Feb 9, 2021, at 4:42 AM, James Hamlin > > wrote: >> >> Brian >> >> Section 5.1 Registration says that "The credentials to be used >> (username and password) MUST be supplied within the credentials >> section of the configuration and identified by the realm the registrar >> uses in a digest challenge. This username/password combination SHOULD >> NOT be the same as that used for other purposes, such as retrieving >> the RUE configuration or logging into the Provider's customer service >> portal.". However, in the 04 draft, passwords are no longer returned >> in the configuration. I think we need to avoid the RUM RUE caching the >> user's main account password, which this draft seems to require. >> >> Best regards >> >> James >> >> >> >> >> James Hamlin >> Contractor >> 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:*Rum > on >> behalf of Brian Rosen > >> *Sent:*05 February 2021 22:26 >> *To:*rum@ietf.org >> *Subject:*[Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >> I have posted a -04 revision.  This should handle all comments >> received so far, please let me know if I forgot something. >> >> This version reworks the provider list and configuration sections >> along the lines we have been discussing. >> >> I do not have a way to download a username/password from a new signup. >>  I’m having trouble thinking about a secure way to do that.  If anyone >> has an idea, I’m very willing to write text for it.  I’ve considered >> things like javascript that stashes it in a file or somewhere else, >> having some web page function that triggers a local display of an >> entry form for username and password, and a couple of other things. >> >> One note on the configuration mechanism - because the only thing the >> local RUE device needs to keep is the username password against a >> provider ID of some kind, there isn’t any need to standardize how that >> works, and so it’s completely absent in the text. >> >> For now, I’ve removed the step by step diagram that showed how the >> config mechanism is used.  I think what is there is dead simple and >> needs no explanation: it’s a straightforward REST/JSON web service >> using username/password authentication for providers the user has >> accounts with.  I can bring back the diagram if that is needed. >> >> Brian >> >> >>> Begin forwarded message: >>> >>> *From:*internet-drafts@ietf.org >>> *Subject:**I-D Action: draft-ietf-rum-rue-04.txt* >>> *Date:*February 5, 2021 at 5:17:15 PM EST >>> *To:*> >>> *Cc:*rum@ietf.org >>> *Reply-To:*internet-drafts@ietf.org >>> ,rum@ietf.org >>> >>> >>> 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-04.txt >>> Pages           : 33 >>> Date            : 2021-02-05 >>> >>> 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-04.html >>> >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04 >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org >>> . >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> > > From nobody Tue Feb 9 06:21: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 DBF0D3A0D41 for ; Tue, 9 Feb 2021 06:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=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 1v_LLYIqlp6d for ; Tue, 9 Feb 2021 06:21:00 -0800 (PST) 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 BE6273A0D40 for ; Tue, 9 Feb 2021 06:20:59 -0800 (PST) Received: from smtpvbsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A7DD11BE07F; Tue, 9 Feb 2021 09:20:58 -0500 (EST) 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 47ACF1BE027; Tue, 9 Feb 2021 09:20:58 -0500 (EST) Received: from mbfesmtp-mgt.mitre.org (unknown [198.49.146.235]) by smtprhbv1.mitre.org (Postfix) with ESMTP id 3337880C907; Tue, 9 Feb 2021 09:20:58 -0500 (EST) Received: by mbfesmtp-mgt.mitre.org (Postfix, from userid 600) id 4DZlRt1MX8z3D4Jw; Tue, 9 Feb 2021 14:20:38 +0000 (UTC) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02lp2108.outbound.protection.outlook.com [104.47.65.108]) by mbfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 4DZlRS3jXCz3D4KN; Tue, 9 Feb 2021 14:20:35 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=avZlErQ1rxb6lc+WrOjU8bQA47YJMdG0+eBRr1n9WVMBkdr+W8ycMda3JQVdk2SX0gxdCrKAW5NeTDWKVfaH5C8bvRSYLwF+zEw9eethlR10nO3LyzpWsY18TXz5K4W3+H/cTHowCM93gBmj3Um5aeS01sF3XD0L2L/kDrYbXpkHORKkqr25+XAIUp7B3kOnU4ZrrIIQLnY0pLlhrP67+fw2bU/rwIGMFOG1C6IJ4NihSTOCP4+B/8c88nl5uVhMWx1fy6bW2lQ7fJ0oxRsBvzZ5uBNh83vY6Q5jsfj/vdVsGW6l2aymnfKkiRugERLGGp60vRv3Wzfg8HgznUWRiQ== 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=XL6EZij2gjVaR7qDr2EJhWXKVjDOkjt4WTykPbO42hk=; b=BXGRrNfYkH/xnv3UDJ2zr7KjFyVCIRRUNeZtVltFIMyebt51ouhXcrfizlgH8ZOiRgOmJ9KeRHz5HyMmKgKg6aB5CG6tnix0C7s3EV4sypjskG8yl6PiFpw163iiRHsmfT9Hjn/zt1vNgIHJMO5bq7gtgWGv18yMYx8uhPnVTbLgZtS5r7csVkAv7tpYSe6oaCfe6qQfWZdU7KrP1OGfYJdKDl5FP7S4Whf8kzY/672qj5lcCNUJEoO85w2wtAfXWvAjGGenocqCpveAE7Q+IWhLF0sMVBjeQewu+mPFjM4VP8ddyERObBELASrKjS3xLMOIvSqLIFffILfPcjx3Yg== 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 MN2PR09MB5948.namprd09.prod.outlook.com (2603:10b6:208:21f::14) by BLAPR09MB6115.namprd09.prod.outlook.com (2603:10b6:208:2a6::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.20; Tue, 9 Feb 2021 14:20:34 +0000 Received: from MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::80f8:5aa8:90dd:1c25]) by MN2PR09MB5948.namprd09.prod.outlook.com ([fe80::80f8:5aa8:90dd:1c25%3]) with mapi id 15.20.3825.030; Tue, 9 Feb 2021 14:20:34 +0000 From: Jim Malloy To: Brian Rosen , "Hamlin, James" CC: "rum@ietf.org" Thread-Topic: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/umTgPRkvm0D6UKcgWuXV94xvqpP3h7w Date: Tue, 9 Feb 2021 14:20:34 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> In-Reply-To: <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@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=mitre.org; x-originating-ip: [192.80.55.88] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 8b23f74c-6e0c-4228-d5ac-08d8cd05dd3d x-ms-traffictypediagnostic: BLAPR09MB6115: 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-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fx3OpcU+4m718aYylM3usxH/cfo/nnuGlCYRUnz44sNNuMrRMafcTMBMgfTvv7qzOlgmd6VDz+9d/dK0QiEIODCSwLKFY5UyMOz8kLvdhfjihxNYwomnsWHfPP9PHfpuL6epY6v3OemzY6jIVqytv0hX5Wtc6qxkU1bB7s72sbug6DoyibeiGzsfCJlMJDUW7C9bpWYP8AqTosc6dz3JsxfYUtYjURfbytBvQXE02DK94rE59gsFJBliF4TZ/yNS5VrMmg3tFr55c7QpKF4iUUYeC0rA8JapoMKH97ik0m59EnavUacC7jVUXOB21iOjU45q3grGUo4Xy+6IkIEZfgUhNvs2XHIO/LMnLbj4Cc84NH80dGEg47cqfKc2dUXgoJYgXU6cPRkXF9DwnrMDo6AG9peyUXcUYDy8F0nzwu0yT5ZB3gw6gAyQCZhgyCPlN77WzJ7j+9Ver1lJUOt1lgEelsph7suaZOH3XNBPwopashzQ6SLpGB3bsItEn59C8KCf9uxSsYcZrm4Ls1f0FsZC96yEFApTqiLCEb9C0IwRlj3UCjQkeXzqCET3FOeMyHACZYqAHULBJ8QmwskNkjYznMP9i1qh0yI0Duh6Kzw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR09MB5948.namprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(136003)(376002)(366004)(39860400002)(346002)(966005)(5660300002)(478600001)(110136005)(4326008)(33656002)(7696005)(8936002)(71200400001)(186003)(26005)(6506007)(53546011)(18074004)(316002)(9686003)(8676002)(86362001)(66574015)(66946007)(166002)(83380400001)(66446008)(52536014)(64756008)(2906002)(76116006)(66556008)(55016002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?Q2ROUVp5Tld5dHBjNW5Rd1k5MHJNamlmazNQSmxpeS9GME5qUDZ0NWxKcGJR?= =?utf-8?B?dlMvZXFUZDh5Wlc5ZXJtU1NOR3NIVHB4UUVmTnZCaXo5emE3T2l0VExLMFF3?= =?utf-8?B?cDZKeU10cnBsNmQ2ZHhFSXYxL1dFQTBEbHVoQ2V2OWJaS3BVWFYxWlJjbEZE?= =?utf-8?B?UGFzU2srZ0hLVmF5d1czWlNBMXBpOVRldEZ4YzVyaXZXdG4vZHQ0aENKZDV4?= =?utf-8?B?SkUxRy9ra2R1QU9YMXFscHYvRHJoUjdiMDNNbTJWTWVWdDQrY1VvTkpyQVVV?= =?utf-8?B?RGxsRnN5TlQ0VGppMmdITGZVM0ZRRGdHQkRhbVJHaVk1SDlZVzd3dDFtNjJr?= =?utf-8?B?dU0wL2h2TEttaWdwNXRzY2RUaW8rb0RPL3FnRURNSzJqYXVvb1VhMFNzVnZM?= =?utf-8?B?TDZVc0VnUzRTMytKelJrK1BzckF1dnF2UlJGdUZLQWZ6R2VCeUZlZkNqeCsv?= =?utf-8?B?bVoyY3ZhdzZwTHFmUmVJc0VSODNMeFpoaUhzZ3VPMWp4L2ZVQ0xxM04zZVRE?= =?utf-8?B?T1RFMjEzQis3emxIZFhOMFAxWGs1dG9rQUluK052eWhlN2hMNCsvaGtibGpZ?= =?utf-8?B?c2hNV1dvVVB1b0hDaWlNSFJJR0JDWDlYcTBNVGdpNEpYcXd2bERrQzM5M0ts?= =?utf-8?B?UnFjMFN2UEdvYzhEUElHV3h2SWFpMU5sSzVjMFRSNFN6c2RrQkttMUh2RGpq?= =?utf-8?B?LzVvdkNLeFpBYmdoV21TU2h2WndvZWVGbFJJTit4bVl6Z3JvN1J2QmVvb1I5?= =?utf-8?B?cW1rRjJBWUZnQU5GQnFFL085Y0cvYTlEekloVE51Sll0aVA0WnhUNWY4MnQv?= =?utf-8?B?R3ZVQS9MYVdndnI5RjZueWVxYWZMaEU1Mis0aEJma0VZeDRkTHRzbk1mR3Zn?= =?utf-8?B?WXpmc05JUkx2V0Jnbm92bEhSRXlRVG1abzhuTTh5bG1PS09zRnpGSU1oOXZN?= =?utf-8?B?NXdlRnRLeldPc2o0V1MwTGRYd2V6UkVMSlJYeDdMby9QK1BQK25SUGF3OU4w?= =?utf-8?B?TDdHaDhVcHVQQkZSYWppclAvQ0xCMUt5YzN0ZXBxbmZhWDRFaTNTMjg1ejda?= =?utf-8?B?MTdNUU5hL1JFUkRwOUxHcUNoNTZMWCsyNjNwRExXSVJTT3Y1cThvMCtVMDNp?= =?utf-8?B?MUtTUHJVOW10L2JPL1VSUEMxMzd0cDdzMTRLNUFRNVBCNHB4WWhPcFI2VUJq?= =?utf-8?B?RksvejBudmF1ZVhENGVTaXBnSVJvLy91VHI0Nld3a2dTei9oOC9KV2pFWjEy?= =?utf-8?B?aXl1TmVvSDk4cEk0empvZG53Y0cyUjk4NXRJemZXOXB6WWF5OGN1cWg1bXI5?= =?utf-8?B?bi9RYllPR1YyeW1kdzZ2V2IraHBrQTlTNGhZTmpmYVl3NFhuQlZodVU4TzlV?= =?utf-8?B?WXdsMmlRVm02TDhCOXNZbjhac2RVSWZMVmlBMUErVitVcHV6eTNMRG1CTStI?= =?utf-8?B?a3ZKN2dmN1FaRzVpTHFyRzNSNE9tcVpEdnFxN2J0c01pQkR6RE9GYlVKSVpJ?= =?utf-8?B?MU4vbjdEMnVhQVlmUk42aFUveGdEMDQxK2x6VFpYRHlNQThvWC9iSGxRdE90?= =?utf-8?B?RjJGZktOWmdGM1RUajE3SDQrUlFwT2F1MVNPeW1TZ0I2WklKQ0ZRS0h5NW9Z?= =?utf-8?B?YnhHVmNNeUhGYTNsQ2lKd0dyN3ptcnVNeFpNR2k4NVJUUE9GVGhTY0drcUFs?= =?utf-8?B?TDNjTlVLQWNzdDUxai8wUndNUnNnSWFBRHdWOTFEMElhOGZmMkc0VkpwR3U5?= =?utf-8?Q?/VIq33kz/T3NhT9ROI=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR09MB5948653747A3D4E2399AB499B98E9MN2PR09MB5948namp_" MIME-Version: 1.0 X-OriginatorOrg: mitre.org X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR09MB5948.namprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b23f74c-6e0c-4228-d5ac-08d8cd05dd3d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2021 14:20:34.2336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: owZIGWr2qFCM7qn87ARAOgT9MVEJhgXrEZVptyoPMVT9C1gil7XaQIWpdrvE/6auvTL4dmP67TritgaG7Y1GSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR09MB6115 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=selector1; bh=XL6EZij2gjVaR7qDr2EJhWXKVjDOkjt4WTykPbO42hk=; b=LqSDtyNvoJcNWH4ztRLIcgj/uR8GzqzOmRU+apQwI2EF6MewkRzCLM4HMKC3b9mneD8hp2FEQxNsb0x8dyg6fZBIfrv5aRYO5QqMk12dOJs7iFYUcssQ+Oa7k3H3SmxAw7FD18JEsGVTlxJwDy2w5h6lXgB4VYOT/o9pl3wLkLo= Archived-At: Subject: Re: [Rum] [EXT] Re: I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 14:21:03 -0000 --_000_MN2PR09MB5948653747A3D4E2399AB499B98E9MN2PR09MB5948namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 4oCcRXZlcnkgVm9JUCBwaG9uZSBJ4oCZdmUgZXZlciBzZWVuIG9yIHVzZWQgY2FjaGVzIHVzZXJu YW1lIGFuZCBwYXNzd29yZHMgZm9yIHN0YW5kIGFsb25lIHVzZeKAnQ0KDQpKYW1lcyDigJMNCg0K RG8gZXhpc3RpbmcgWlZSUy9QdXJwbGUgZGV2aWNlcyBvciBtb2JpbGUgYXBwbGljYXRpb25zIGNh Y2hlIGF1dGhlbnRpY2F0aW9uIGNyZWRlbnRpYWxzPyAgKE1vYmlsZSBhcHBsaWNhdGlvbnMgbWF5 IGRvIHNvIGF0IHRoZSBPUyBsZXZlbCBldmVuIGlmIHRoZSBhcHBsaWNhdGlvbiBkb2VzbuKAmXQg ZXhwbGljaXRseSBkbyBzby4pICBJZiBzbywgaXMgdGhlcmUgYSByZWFzb24gdG8gdHJlYXQgdGhl IFJVRSBEaWZmZXJlbnRseT8NCg0KVGhhbmtzLA0KDQpKaW0gTWFsbG95DQpQcmluY2lwYWwgSW5m b3JtYXRpb24gU3lzdGVtIEVuZ2luZWVyDQpUaGUgTUlUUkUgQ29ycC4NCjcwMyA5ODMgMjgzNQ0K DQpGcm9tOiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gUm9z ZW4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDksIDIwMjEgODo0NCBBTQ0KVG86IEhhbWxpbiwg SmFtZXMgPGphbWVzLmhhbWxpbkBwdXJwbGUudXM+DQpDYzogcnVtQGlldGYub3JnDQpTdWJqZWN0 OiBbRVhUXSBSZTogW1J1bV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0K DQpJ4oCZbGwgZGVsZXRlIHRoZSB0ZXh0IGluIHJlZ2lzdHJhdGlvbi4NCkV2ZXJ5IFZvSVAgcGhv bmUgSeKAmXZlIGV2ZXIgc2VlbiBvciB1c2VkIGNhY2hlcyB1c2VybmFtZSBhbmQgcGFzc3dvcmRz IGZvciBzdGFuZCBhbG9uZSB1c2UuICBFdmVyeSBvbmUuICBUaGV5IGRvIHRoYXQgZm9yIGEgc2lt cGxlIHJlYXNvbiAtIHNvIGluY29taW5nIGNhbGxzIHdvcmsgYWZ0ZXIgYSBwb3dlciBsb3NzLiAg TW9zdCBhbHNvIGFyZSBlZmZlY3RpdmVseSBzZXQgYW5kIGZvcmdldCwgd2hpY2ggaXMgd2hhdCB5 b3Ugd2FudCBpbiBhIHBob25lLiAgV2h5IHdvdWxkIHdlIHJlcXVpcmUgbWFudWFsIGVudHJ5IGZv ciB0aGUgUlVFPw0KDQpUaGUgdGV4dCBjdXJyZW50bHkgdXNlcyB0aGUgc2FtZSBjcmVkZW50aWFs cyBmb3IgdGhlIEhUVFAgc2VydmljZSBhbmQgdGhlIFNJUCBzZXJ2aWNlLCBidXQgdGhhdOKAmXMg aXQuICBJIHRoaW5rIHRoYXTigJlzIHByZXR0eSByZWFzb25hYmxlLg0KDQpJZiB5b3UgaGF2ZSBh bm90aGVyIHByb3Bvc2FsIGZvciBob3cgd2UgY2FuIG1haW50YWluIHRoZSBjb25maWcgZGF0YSBz ZWN1cmVseSwgcGxlYXNlIHN1Z2dlc3Qgb25lLg0KDQpCcmlhbg0KDQoNCk9uIEZlYiA5LCAyMDIx LCBhdCA0OjQyIEFNLCBKYW1lcyBIYW1saW4gPGphbWVzLmhhbWxpbkBwdXJwbGUudXM8bWFpbHRv OmphbWVzLmhhbWxpbkBwdXJwbGUudXM+PiB3cm90ZToNCg0KQnJpYW4NCg0KU2VjdGlvbiA1LjEg UmVnaXN0cmF0aW9uIHNheXMgdGhhdCAiVGhlIGNyZWRlbnRpYWxzIHRvIGJlIHVzZWQgKHVzZXJu YW1lIGFuZCBwYXNzd29yZCkgTVVTVCBiZSBzdXBwbGllZCB3aXRoaW4gdGhlIGNyZWRlbnRpYWxz IHNlY3Rpb24gb2YgdGhlIGNvbmZpZ3VyYXRpb24gYW5kIGlkZW50aWZpZWQgYnkgdGhlIHJlYWxt IHRoZSByZWdpc3RyYXIgdXNlcyBpbiBhIGRpZ2VzdCBjaGFsbGVuZ2UuIFRoaXMgdXNlcm5hbWUv cGFzc3dvcmQgY29tYmluYXRpb24gU0hPVUxEIE5PVCBiZSB0aGUgc2FtZSBhcyB0aGF0IHVzZWQg Zm9yIG90aGVyIHB1cnBvc2VzLCBzdWNoIGFzIHJldHJpZXZpbmcgdGhlIFJVRSBjb25maWd1cmF0 aW9uIG9yIGxvZ2dpbmcgaW50byB0aGUgUHJvdmlkZXIncyBjdXN0b21lciBzZXJ2aWNlIHBvcnRh bC4iLiBIb3dldmVyLCBpbiB0aGUgMDQgZHJhZnQsIHBhc3N3b3JkcyBhcmUgbm8gbG9uZ2VyIHJl dHVybmVkIGluIHRoZSBjb25maWd1cmF0aW9uLiBJIHRoaW5rIHdlIG5lZWQgdG8gYXZvaWQgdGhl IFJVTSBSVUUgY2FjaGluZyB0aGUgdXNlcidzIG1haW4gYWNjb3VudCBwYXNzd29yZCwgd2hpY2gg dGhpcyBkcmFmdCBzZWVtcyB0byByZXF1aXJlLg0KDQpCZXN0IHJlZ2FyZHMNCg0KSmFtZXMNCg0K DQoNCg0KSmFtZXMgSGFtbGluDQpDb250cmFjdG9yDQpQdXJwbGUsIGEgRGl2aXNpb24gb2YgWlAg QmV0dGVyIFRvZ2V0aGVyLCBMTEMNCnB1cnBsZXZycy5jb208aHR0cDovL3B1cnBsZXZycy5jb20v Pg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGlu dGVuZGVkDQpvbmx5IGZvciB0aGUgcGVyc29uYWwgYW5kIGNvbmZpZGVudGlhbCB1c2Ugb2YgdGhl IHJlY2lwaWVudChzKQ0KbmFtZWQgYWJvdmUuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29t bXVuaWNhdGlvbiBpbiBlcnJvciwNCnBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1t YWlsLCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbA0KbWVzc2FnZS4NCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkZyb206IFJ1bSA8cnVtLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnJ1bS1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEJyaWFuIFJvc2VuIDxickBicmlh bnJvc2VuLm5ldDxtYWlsdG86YnJAYnJpYW5yb3Nlbi5uZXQ+Pg0KU2VudDogMDUgRmVicnVhcnkg MjAyMSAyMjoyNg0KVG86IHJ1bUBpZXRmLm9yZzxtYWlsdG86cnVtQGlldGYub3JnPg0KU3ViamVj dDogW1J1bV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQoNCkkg aGF2ZSBwb3N0ZWQgYSAtMDQgcmV2aXNpb24uICBUaGlzIHNob3VsZCBoYW5kbGUgYWxsIGNvbW1l bnRzIHJlY2VpdmVkIHNvIGZhciwgcGxlYXNlIGxldCBtZSBrbm93IGlmIEkgZm9yZ290IHNvbWV0 aGluZy4NCg0KVGhpcyB2ZXJzaW9uIHJld29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZp Z3VyYXRpb24gc2VjdGlvbnMgYWxvbmcgdGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5n Lg0KDQpJIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGRvd25sb2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQg ZnJvbSBhIG5ldyBzaWdudXAuICBJ4oCZbSBoYXZpbmcgdHJvdWJsZSB0aGlua2luZyBhYm91dCBh IHNlY3VyZSB3YXkgdG8gZG8gdGhhdC4gIElmIGFueW9uZSBoYXMgYW4gaWRlYSwgSeKAmW0gdmVy eSB3aWxsaW5nIHRvIHdyaXRlIHRleHQgZm9yIGl0LiAgSeKAmXZlIGNvbnNpZGVyZWQgdGhpbmdz IGxpa2UgamF2YXNjcmlwdCB0aGF0IHN0YXNoZXMgaXQgaW4gYSBmaWxlIG9yIHNvbWV3aGVyZSBl bHNlLCBoYXZpbmcgc29tZSB3ZWIgcGFnZSBmdW5jdGlvbiB0aGF0IHRyaWdnZXJzIGEgbG9jYWwg ZGlzcGxheSBvZiBhbiBlbnRyeSBmb3JtIGZvciB1c2VybmFtZSBhbmQgcGFzc3dvcmQsIGFuZCBh IGNvdXBsZSBvZiBvdGhlciB0aGluZ3MuDQoNCk9uZSBub3RlIG9uIHRoZSBjb25maWd1cmF0aW9u IG1lY2hhbmlzbSAtIGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgdGhlIGxvY2FsIFJVRSBkZXZpY2Ug bmVlZHMgdG8ga2VlcCBpcyB0aGUgdXNlcm5hbWUgcGFzc3dvcmQgYWdhaW5zdCBhIHByb3ZpZGVy IElEIG9mIHNvbWUga2luZCwgdGhlcmUgaXNu4oCZdCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBo b3cgdGhhdCB3b3JrcywgYW5kIHNvIGl04oCZcyBjb21wbGV0ZWx5IGFic2VudCBpbiB0aGUgdGV4 dC4NCg0KRm9yIG5vdywgSeKAmXZlIHJlbW92ZWQgdGhlIHN0ZXAgYnkgc3RlcCBkaWFncmFtIHRo YXQgc2hvd2VkIGhvdyB0aGUgY29uZmlnIG1lY2hhbmlzbSBpcyB1c2VkLiAgSSB0aGluayB3aGF0 IGlzIHRoZXJlIGlzIGRlYWQgc2ltcGxlIGFuZCBuZWVkcyBubyBleHBsYW5hdGlvbjogaXTigJlz IGEgc3RyYWlnaHRmb3J3YXJkIFJFU1QvSlNPTiB3ZWIgc2VydmljZSB1c2luZyB1c2VybmFtZS9w YXNzd29yZCBhdXRoZW50aWNhdGlvbiBmb3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhhcyBhY2NvdW50 cyB3aXRoLiAgSSBjYW4gYnJpbmcgYmFjayB0aGUgZGlhZ3JhbSBpZiB0aGF0IGlzIG5lZWRlZC4N Cg0KQnJpYW4NCg0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1Ympl Y3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNC50eHQNCkRhdGU6IEZlYnJ1YXJ5 IDUsIDIwMjEgYXQgNToxNzoxNSBQTSBFU1QNClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1h aWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6IHJ1bUBpZXRmLm9yZzxtYWlsdG86cnVt QGlldGYub3JnPg0KUmVwbHktVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPiwgcnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0Zi5vcmc+ DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUg SW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBv ZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgVGl0bGUg ICAgICAgICAgIDogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVxdWlw bWVudA0KICAgICAgIEF1dGhvciAgICAgICAgICA6IEJyaWFuIFJvc2VuDQpGaWxlbmFtZSAgICAg ICAgOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQpQYWdlcyAgICAgICAgICAgOiAzMw0KRGF0 ZSAgICAgICAgICAgIDogMjAyMS0wMi0wNQ0KDQpBYnN0cmFjdDoNCiAgVmlkZW8gUmVsYXkgU2Vy dmljZSAoVlJTKSBpcyBhIHRlcm0gdXNlZCB0byBkZXNjcmliZSBhIG1ldGhvZCBieQ0KICB3aGlj aCBhIGhlYXJpbmcgcGVyc29ucyBjYW4gY29tbXVuaWNhdGUgd2l0aCBkZWFmL0hhcmQgb2YgSGVh cmluZw0KICB1c2VyIHVzaW5nIGFuIGludGVycHJldGVyICgiQ29tbXVuaWNhdGlvbnMgQXNzaXN0 YW50IikgY29ubmVjdGVkIHZpYQ0KICBhIHZpZGVvcGhvbmUgdG8gdGhlIGRlYWYvSG9IIHVzZXIg YW5kIGFuIGF1ZGlvIHRlbGVwaG9uZSBjYWxsIHRvIHRoZQ0KICBoZWFyaW5nIHVzZXIuICBUaGUg Q0EgaW50ZXJwcmV0cyB1c2luZyBzaWduIGxhbmd1YWdlIG9uIHRoZQ0KICB2aWRlb3Bob25lIGxp bmsgYW5kIHZvaWNlIG9uIHRoZSB0ZWxlcGhvbmUgbGluay4gIE9mdGVuIHRoZQ0KICBpbnRlcnBy ZXRlcnMgbWF5IGJlIHN1cHBsaWVkIGJ5IGEgY29tcGFueSBvciBhZ2VuY3kgdGVybWVkIGENCiAg InByb3ZpZGVyIiBpbiB0aGlzIGRvY3VtZW50LiAgVGhlIHByb3ZpZGVyIGFsc28gcHJvdmlkZXMg YSB2aWRlbw0KICBzZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3QgdmlkZW8gZGV2 aWNlcyB0byB0aGVpciBzZXJ2aWNlLA0KICBhbmQgc3Vic2VxdWVudGx5IHRvIENBcyBhbmQgb3Ro ZXIgZGVhZi9Ib0ggdXNlcnMuICBJdCBpcyBkZXNpcmFibGUNCiAgdGhhdCB0aGUgdmlkZW9waG9u ZXMgdXNlZCBieSB0aGUgZGVhZi9Ib0gvSC1JIHVzZXIgY29uZm9ybSB0byBhDQogIHN0YW5kYXJk IHNvIHRoYXQgYW55IGRldmljZSBtYXkgYmUgdXNlZCB3aXRoIGFueSBwcm92aWRlciBhbmQgdGhh dA0KICB2aWRlbyBjYWxscyBkaXJlY3QgYmV0d2VlbiBkZWFmL0hvSCB1c2VycyB3b3JrLiAgVGhp cyBkb2N1bWVudA0KICBkZXNjcmliZXMgdGhlIGludGVyZmFjZSBiZXR3ZWVuIGEgdmlkZW9waG9u ZSBhbmQgYSBwcm92aWRlci4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtcnVtLXJ1ZS88aHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw/YT1odHRw cyUzYSUyZiUyZmRhdGF0cmFja2VyLmlldGYub3JnJTJmZG9jJTJmZHJhZnQtaWV0Zi1ydW0tcnVl JTJmJmM9RSwxLG1VZnpaU3ZUMFI1UGxJVUxPQWhHWHhLbnhWZUNRRUVISGE5Q2NQVDMtSHFOYVQ5 aE01SkszYmo2R3N5RTVaN3JTNEUwQWc2Sy1uejF6T2FTU0V4X1o1YWw2YTkzSEpNTG9XUkxsQkw0 S1NscDBYWDY1NXNCZzFzLCZ0eXBvPTE+DQoNClRoZXJlIGlzIGFsc28gYW4gSFRNTCB2ZXJzaW9u IGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0 Zi1ydW0tcnVlLTA0Lmh0bWw8aHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw/YT1o dHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZmFyY2hpdmUlMmZpZCUyZmRyYWZ0LWlldGYtcnVt LXJ1ZS0wNC5odG1sJmM9RSwxLE1qUFp6TlBVTTdYMWxpaHhuQm9kWTVXbWQ3SloxQ2x4RDNpNEgw Vmk2cG8zazRKRVFSTWo5bV85aXRPYnJ0QzBVS2dNa2ljcVBtaUtvTGpSRk12bjk3d0dMcG5wakJB dUotY0k4M1FzZXVWNkhtZHJmOUZnRGF4cUxKUzgmdHlwbz0xJmFuY3JfYWRkPTE+DQoNCkEgZGlm ZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3 LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUtMDQ8aHR0cHM6Ly9saW5r cHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw/YT1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZnJm Y2RpZmYlM2Z1cmwyJTNkZHJhZnQtaWV0Zi1ydW0tcnVlLTA0JmM9RSwxLDh0UW5FdGxlZ1lpS09r RU90N1NJaEw4SjZVc01VMHFpN0xMalVYRzM5aXJqbUZYNlRNbkhaZVVhaVJGNjdBeDNOQ21yYkkw RGFUYnhkbVZvRWdtandiZkxoUUpDUk95OXM5WUVzUHVyd0F0Q0lWLVI3R1Ffb3R3U0VRLCwmdHlw bz0xJmFuY3JfYWRkPTE+DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRw Oi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz LzxodHRwczovL2xpbmtwcm90ZWN0LmN1ZGFzdmMuY29tL3VybD9hPWZ0cCUzYSUyZiUyZmZ0cC5p ZXRmLm9yZyUyZmludGVybmV0LWRyYWZ0cyUyZiZjPUUsMSxxREI0U2EyQzYtUFV5LURkS2tPT05i YXVnWFl6XzhJZXFyUzAxSUpZcDVBSlpNRHN2MGo4LTdPRjh3VnlyUjFjNGdlX1Z3NUp0bGU4NkEy RDNFQmFRbXh2dFZ3dU5tLW40cWhna012RWwxUVJHNEdyJnR5cG89MSZhbmNyX2FkZD0xPg0KDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJLUQtQW5u b3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOkktRC1Bbm5v dW5jZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1k LWFubm91bmNlPGh0dHBzOi8vbGlua3Byb3RlY3QuY3VkYXN2Yy5jb20vdXJsP2E9aHR0cHMlM2El MmYlMmZ3d3cuaWV0Zi5vcmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZpLWQtYW5ub3VuY2UmYz1F LDEsZ01YV0lJdG8wQWxYU2xrLVo4V0Qza3VlWUZPcFB6ZkE3aXdXWHJQa1c4SWlWMy1Wcm8zNUNm QlJfUkZnRURueklUT0xXbFVzOFFaY3pIRXZOaWVYbGxuazIzU01GU3NjTjdjamNLYlhpc1BwM0lB Qmg3ZWp6ZURIJnR5cG89MSZhbmNyX2FkZD0xPg0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6 IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8aHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRh c3ZjLmNvbS91cmw/YT1odHRwJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmc2hhZG93Lmh0bWwmYz1F LDEsSFJfQzhWZDFxcGFmY0l2V21Ic1ZrQ1ltYXdCNFpWSndmcGVSS05BRGlmQkZwUkZBc2UyUk9S S3hMNG1uX0xBV2VZVDRLdXpmU0ttb3J4OGtvZEFvejJ4VzZvaDdLYXlqY3dMWThPZGI1USwsJnR5 cG89MSZhbmNyX2FkZD0xPg0Kb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRl cy50eHQ8aHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91cmw/YT1mdHAlM2ElMmYlMmZm dHAuaWV0Zi5vcmclMmZpZXRmJTJmMXNoYWRvdy1zaXRlcy50eHQmYz1FLDEsdU5IVUgza3BINWh2 ZzZuN3cwWXZTQ1BxNm4xZkd2T1FKTE9QR3pEUU9FZFV4YWFfbnhjTGFoclU4bThicEZVWFBxb0xZ akhxRHlPQkdSanBHTVF6bEl2dEJaWXJzaE5FRWZjOEs4NnhRQSwsJnR5cG89MSZhbmNyX2FkZD0x Pg0KDQoNCg0K --_000_MN2PR09MB5948653747A3D4E2399AB499B98E9MN2PR09MB5948namp_ 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 CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHls ZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0 eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcRXZlcnkgVm9JUCBwaG9uZSBJ4oCZdmUgZXZlciBzZWVu IG9yIHVzZWQgY2FjaGVzIHVzZXJuYW1lIGFuZCBwYXNzd29yZHMgZm9yIHN0YW5kIGFsb25lIHVz ZeKAnTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KYW1lcyDigJMgPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkRvIGV4aXN0aW5nIFpWUlMvUHVycGxlIGRldmljZXMgb3IgbW9iaWxlIGFwcGxpY2F0 aW9ucyBjYWNoZSBhdXRoZW50aWNhdGlvbiBjcmVkZW50aWFscz8mbmJzcDsgKE1vYmlsZSBhcHBs aWNhdGlvbnMgbWF5IGRvIHNvIGF0IHRoZSBPUyBsZXZlbCBldmVuIGlmIHRoZSBhcHBsaWNhdGlv biBkb2VzbuKAmXQgZXhwbGljaXRseSBkbyBzby4pJm5ic3A7IElmIHNvLCBpcyB0aGVyZSBhIHJl YXNvbiB0byB0cmVhdCB0aGUgUlVFIERpZmZlcmVudGx5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6Ni4wcHQiPlRoYW5rcyw8YnI+DQo8YnI+DQpKaW0g TWFsbG95PGJyPg0KUHJpbmNpcGFsIEluZm9ybWF0aW9uIFN5c3RlbSBFbmdpbmVlcjxicj4NClRo ZSBNSVRSRSBDb3JwLjxicj4NCjcwMyA5ODMgMjgzNTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUnVt ICZsdDtydW0tYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkJyaWFu IFJvc2VuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDksIDIwMjEgODo0NCBB TTxicj4NCjxiPlRvOjwvYj4gSGFtbGluLCBKYW1lcyAmbHQ7amFtZXMuaGFtbGluQHB1cnBsZS51 cyZndDs8YnI+DQo8Yj5DYzo8L2I+IHJ1bUBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBb RVhUXSBSZTogW1J1bV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWxsIGRlbGV0ZSB0aGUgdGV4 dCBpbiByZWdpc3RyYXRpb24uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkV2ZXJ5IFZvSVAgcGhvbmUgSeKAmXZlIGV2ZXIgc2VlbiBvciB1c2VkIGNh Y2hlcyB1c2VybmFtZSBhbmQgcGFzc3dvcmRzIGZvciBzdGFuZCBhbG9uZSB1c2UuICZuYnNwO0V2 ZXJ5IG9uZS4gJm5ic3A7VGhleSBkbyB0aGF0IGZvciBhIHNpbXBsZSByZWFzb24gLSBzbyBpbmNv bWluZyBjYWxscyB3b3JrIGFmdGVyIGEgcG93ZXIgbG9zcy4gJm5ic3A7TW9zdCBhbHNvIGFyZSBl ZmZlY3RpdmVseSBzZXQgYW5kIGZvcmdldCwgd2hpY2ggaXMgd2hhdA0KIHlvdSB3YW50IGluIGEg cGhvbmUuICZuYnNwO1doeSB3b3VsZCB3ZSByZXF1aXJlIG1hbnVhbCBlbnRyeSBmb3IgdGhlIFJV RT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHRleHQgY3VycmVudGx5IHVzZXMgdGhlIHNhbWUgY3JlZGVudGlhbHMgZm9yIHRoZSBIVFRQ IHNlcnZpY2UgYW5kIHRoZSBTSVAgc2VydmljZSwgYnV0IHRoYXTigJlzIGl0LiAmbmJzcDtJIHRo aW5rIHRoYXTigJlzIHByZXR0eSByZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgaGF2ZSBhbm90aGVyIHByb3Bvc2Fs IGZvciBob3cgd2UgY2FuIG1haW50YWluIHRoZSBjb25maWcgZGF0YSBzZWN1cmVseSwgcGxlYXNl IHN1Z2dlc3Qgb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gRmViIDksIDIwMjEsIGF0IDQ6NDIgQU0sIEphbWVzIEhhbWxpbiAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmphbWVzLmhhbWxpbkBwdXJwbGUudXMiPmphbWVzLmhhbWxpbkBwdXJwbGUudXM8 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+QnJpYW48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TZWN0aW9uIDUuMSBSZWdpc3RyYXRpb24gc2F5cyB0aGF0 ICZxdW90O1RoZSBjcmVkZW50aWFscyB0byBiZSB1c2VkICh1c2VybmFtZSBhbmQgcGFzc3dvcmQp IE1VU1QgYmUgc3VwcGxpZWQgd2l0aGluIHRoZSBjcmVkZW50aWFscyBzZWN0aW9uIG9mIHRoZSBj b25maWd1cmF0aW9uIGFuZCBpZGVudGlmaWVkDQogYnkgdGhlIHJlYWxtIHRoZSByZWdpc3RyYXIg dXNlcyBpbiBhIGRpZ2VzdCBjaGFsbGVuZ2UuIFRoaXMgdXNlcm5hbWUvcGFzc3dvcmQgY29tYmlu YXRpb24gU0hPVUxEIE5PVCBiZSB0aGUgc2FtZSBhcyB0aGF0IHVzZWQgZm9yIG90aGVyIHB1cnBv c2VzLCBzdWNoIGFzIHJldHJpZXZpbmcgdGhlIFJVRSBjb25maWd1cmF0aW9uIG9yIGxvZ2dpbmcg aW50byB0aGUgUHJvdmlkZXIncyBjdXN0b21lciBzZXJ2aWNlIHBvcnRhbC4mcXVvdDsuJm5ic3A7 SG93ZXZlciwgaW4NCiB0aGUmbmJzcDswNCBkcmFmdCwgcGFzc3dvcmRzIGFyZSBubyBsb25nZXIg cmV0dXJuZWQgaW4gdGhlIGNvbmZpZ3VyYXRpb24uIEkgdGhpbmsgd2UgbmVlZCB0byBhdm9pZCB0 aGUgUlVNIFJVRSBjYWNoaW5nIHRoZSB1c2VyJ3MgbWFpbiBhY2NvdW50IHBhc3N3b3JkLCB3aGlj aCB0aGlzIGRyYWZ0IHNlZW1zIHRvIHJlcXVpcmUuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QmVzdCByZWdhcmRzPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+SmFtZXM8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndo aXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tn cm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJTaWduYXR1 cmUiPg0KPGRpdiBuYW1lPSJkaXZ0YWdkZWZhdWx0d3JhcHBlciI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPkphbWVzIEhhbWxpbjxicj4NCkNvbnRyYWN0b3I8YnI+DQpQdXJwbGUs IGEgRGl2aXNpb24gb2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEM8YnI+DQo8YSBocmVmPSJodHRw Oi8vcHVycGxldnJzLmNvbS8iPnB1cnBsZXZycy5jb208L2E+PGJyPg0KVGhlIGluZm9ybWF0aW9u IGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNzYWdlIGlzIGludGVuZGVkPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCm9ubHkgZm9yIHRoZSBw ZXJzb25hbCBhbmQgY29uZmlkZW50aWFsIHVzZSBvZiB0aGUgcmVjaXBpZW50KHMpPHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCm5hbWVkIGFib3Zl LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IsPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+cGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVs eSBieSBlLW1haWwsIGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsJm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPm1lc3NhZ2UuPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtiYWNrZ3JvdW5kOndoaXRlIj4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4NCjxociBzaXplPSIy IiB3aWR0aD0iNjMwIiBzdHlsZT0id2lkdGg6NDcyLjZwdCIgYWxpZ249ImNlbnRlciI+DQo8L3Nw YW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNnIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkZy b206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5SdW0gJmx0OzxhIGhyZWY9Im1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZyI+cnVt LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KIG9uIGJlaGFsZiBvZiBCcmlhbiBSb3NlbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwvYT4m Z3Q7PGJyPg0KPGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjA1IEZlYnJ1YXJ5IDIwMjEgMjI6MjY8YnI+DQo8Yj5Ubzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpydW1AaWV0Zi5vcmciPnJ1bUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3Bh biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W1J1bV0gRndkOiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5JIGhhdmUgcG9zdGVkIGEgLTA0IHJldmlz aW9uLiAmbmJzcDtUaGlzIHNob3VsZCBoYW5kbGUgYWxsIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZh ciwgcGxlYXNlIGxldCBtZSBrbm93IGlmIEkgZm9yZ290IHNvbWV0aGluZy48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VGhpcyB2ZXJzaW9uIHJld29y a3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZpZ3VyYXRpb24gc2VjdGlvbnMgYWxvbmcgdGhl IGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkkgZG8gbm90IGhhdmUgYSB3YXkgdG8g ZG93bmxvYWQgYSB1c2VybmFtZS9wYXNzd29yZCBmcm9tIGEgbmV3IHNpZ251cC4gJm5ic3A7SeKA mW0gaGF2aW5nIHRyb3VibGUgdGhpbmtpbmcgYWJvdXQgYSBzZWN1cmUgd2F5IHRvIGRvIHRoYXQu ICZuYnNwO0lmIGFueW9uZSBoYXMgYW4gaWRlYSwgSeKAmW0gdmVyeSB3aWxsaW5nDQogdG8gd3Jp dGUgdGV4dCBmb3IgaXQuICZuYnNwO0nigJl2ZSBjb25zaWRlcmVkIHRoaW5ncyBsaWtlIGphdmFz Y3JpcHQgdGhhdCBzdGFzaGVzIGl0IGluIGEgZmlsZSBvciBzb21ld2hlcmUgZWxzZSwgaGF2aW5n IHNvbWUgd2ViIHBhZ2UgZnVuY3Rpb24gdGhhdCB0cmlnZ2VycyBhIGxvY2FsIGRpc3BsYXkgb2Yg YW4gZW50cnkgZm9ybSBmb3IgdXNlcm5hbWUgYW5kIHBhc3N3b3JkLCBhbmQgYSBjb3VwbGUgb2Yg b3RoZXIgdGhpbmdzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Y29sb3I6YmxhY2siPk9uZSBub3RlIG9uIHRoZSBjb25maWd1cmF0aW9uIG1lY2hhbmlzbSAt IGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgdGhlIGxvY2FsIFJVRSBkZXZpY2UgbmVlZHMgdG8ga2Vl cCBpcyB0aGUgdXNlcm5hbWUgcGFzc3dvcmQgYWdhaW5zdCBhIHByb3ZpZGVyIElEIG9mIHNvbWUg a2luZCwgdGhlcmUgaXNu4oCZdA0KIGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIGhvdyB0aGF0IHdv cmtzLCBhbmQgc28gaXTigJlzIGNvbXBsZXRlbHkgYWJzZW50IGluIHRoZSB0ZXh0LiAmbmJzcDs8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gb3Igbm93LCBJ4oCZdmUgcmVtb3ZlZCB0aGUgc3RlcCBieSBzdGVwIGRpYWdyYW0gdGhhdCBz aG93ZWQgaG93IHRoZSBjb25maWcgbWVjaGFuaXNtIGlzIHVzZWQuICZuYnNwO0kgdGhpbmsgd2hh dCBpcyB0aGVyZSBpcyBkZWFkIHNpbXBsZSBhbmQgbmVlZHMgbm8gZXhwbGFuYXRpb246IGl04oCZ cyBhIHN0cmFpZ2h0Zm9yd2FyZA0KIFJFU1QvSlNPTiB3ZWIgc2VydmljZSB1c2luZyB1c2VybmFt ZS9wYXNzd29yZCBhdXRoZW50aWNhdGlvbiBmb3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhhcyBhY2Nv dW50cyB3aXRoLiAmbmJzcDtJIGNhbiBicmluZyBiYWNrIHRoZSBkaWFncmFtIGlmIHRoYXQgaXMg bmVlZGVkLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPkJyaWFuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlN1YmplY3Q6PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVt LXJ1ZS0wNC50eHQ8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Y29sb3I6YmxhY2siPkRhdGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZlYnJ1YXJ5IDUsIDIwMjEgYXQgNToxNzoxNSBQTSBFU1Q8L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+VG86PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DYzo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOnJ1bUBp ZXRmLm9yZyI+cnVtQGlldGYub3JnPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5SZXBseS1Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPiw8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJ1bUBpZXRmLm9yZyI+ cnVtQGlldGYub3JnPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBp cyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZSBJRVRGLjxi cj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxl ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVxdWlwbWVudDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvciAmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEJyaWFu IFJvc2VuPGJyPg0KRmlsZW5hbWUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0PGJyPg0KUGFnZXMgJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAzMzxicj4N CkRhdGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiAyMDIxLTAyLTA1PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i c3A7Jm5ic3A7VmlkZW8gUmVsYXkgU2VydmljZSAoVlJTKSBpcyBhIHRlcm0gdXNlZCB0byBkZXNj cmliZSBhIG1ldGhvZCBieTxicj4NCiZuYnNwOyZuYnNwO3doaWNoIGEgaGVhcmluZyBwZXJzb25z IGNhbiBjb21tdW5pY2F0ZSB3aXRoIGRlYWYvSGFyZCBvZiBIZWFyaW5nPGJyPg0KJm5ic3A7Jm5i c3A7dXNlciB1c2luZyBhbiBpbnRlcnByZXRlciAoJnF1b3Q7Q29tbXVuaWNhdGlvbnMgQXNzaXN0 YW50JnF1b3Q7KSBjb25uZWN0ZWQgdmlhPGJyPg0KJm5ic3A7Jm5ic3A7YSB2aWRlb3Bob25lIHRv IHRoZSBkZWFmL0hvSCB1c2VyIGFuZCBhbiBhdWRpbyB0ZWxlcGhvbmUgY2FsbCB0byB0aGU8YnI+ DQombmJzcDsmbmJzcDtoZWFyaW5nIHVzZXIuICZuYnNwO1RoZSBDQSBpbnRlcnByZXRzIHVzaW5n IHNpZ24gbGFuZ3VhZ2Ugb24gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7dmlkZW9waG9uZSBsaW5rIGFu ZCB2b2ljZSBvbiB0aGUgdGVsZXBob25lIGxpbmsuICZuYnNwO09mdGVuIHRoZTxicj4NCiZuYnNw OyZuYnNwO2ludGVycHJldGVycyBtYXkgYmUgc3VwcGxpZWQgYnkgYSBjb21wYW55IG9yIGFnZW5j eSB0ZXJtZWQgYTxicj4NCiZuYnNwOyZuYnNwOyZxdW90O3Byb3ZpZGVyJnF1b3Q7IGluIHRoaXMg ZG9jdW1lbnQuICZuYnNwO1RoZSBwcm92aWRlciBhbHNvIHByb3ZpZGVzIGEgdmlkZW88YnI+DQom bmJzcDsmbmJzcDtzZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3QgdmlkZW8gZGV2 aWNlcyB0byB0aGVpciBzZXJ2aWNlLDxicj4NCiZuYnNwOyZuYnNwO2FuZCBzdWJzZXF1ZW50bHkg dG8gQ0FzIGFuZCBvdGhlciBkZWFmL0hvSCB1c2Vycy4gJm5ic3A7SXQgaXMgZGVzaXJhYmxlPGJy Pg0KJm5ic3A7Jm5ic3A7dGhhdCB0aGUgdmlkZW9waG9uZXMgdXNlZCBieSB0aGUgZGVhZi9Ib0gv SC1JIHVzZXIgY29uZm9ybSB0byBhPGJyPg0KJm5ic3A7Jm5ic3A7c3RhbmRhcmQgc28gdGhhdCBh bnkgZGV2aWNlIG1heSBiZSB1c2VkIHdpdGggYW55IHByb3ZpZGVyIGFuZCB0aGF0PGJyPg0KJm5i c3A7Jm5ic3A7dmlkZW8gY2FsbHMgZGlyZWN0IGJldHdlZW4gZGVhZi9Ib0ggdXNlcnMgd29yay4g Jm5ic3A7VGhpcyBkb2N1bWVudDxicj4NCiZuYnNwOyZuYnNwO2Rlc2NyaWJlcyB0aGUgaW50ZXJm YWNlIGJldHdlZW4gYSB2aWRlb3Bob25lIGFuZCBhIHByb3ZpZGVyLjxicj4NCjxicj4NCjxicj4N ClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vbGlua3Byb3RlY3QuY3VkYXN2Yy5jb20vdXJsP2E9aHR0cHMlM2El MmYlMmZkYXRhdHJhY2tlci5pZXRmLm9yZyUyZmRvYyUyZmRyYWZ0LWlldGYtcnVtLXJ1ZSUyZiZh bXA7Yz1FLDEsbVVmelpTdlQwUjVQbElVTE9BaEdYeEtueFZlQ1FFRUhIYTlDY1BUMy1IcU5hVDlo TTVKSzNiajZHc3lFNVo3clM0RTBBZzZLLW56MXpPYVNTRXhfWjVhbDZhOTNISk1Mb1dSTGxCTDRL U2xwMFhYNjU1c0JnMXMsJmFtcDt0eXBvPTEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcnVtLXJ1ZS88L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgYWxzbyBhbiBI VE1MIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vbGlua3Byb3Rl Y3QuY3VkYXN2Yy5jb20vdXJsP2E9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZhcmNoaXZl JTJmaWQlMmZkcmFmdC1pZXRmLXJ1bS1ydWUtMDQuaHRtbCZhbXA7Yz1FLDEsTWpQWnpOUFVNN1gx bGloeG5Cb2RZNVdtZDdKWjFDbHhEM2k0SDBWaTZwbzNrNEpFUVJNajltXzlpdE9icnRDMFVLZ01r aWNxUG1pS29MalJGTXZuOTd3R0xwbnBqQkF1Si1jSTgzUXNldVY2SG1kcmY5RmdEYXhxTEpTOCZh bXA7dHlwbz0xJmFtcDthbmNyX2FkZD0xIj5odHRwczovL3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lk L2RyYWZ0LWlldGYtcnVtLXJ1ZS0wNC5odG1sPC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRo ZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczov L2xpbmtwcm90ZWN0LmN1ZGFzdmMuY29tL3VybD9hPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3Jn JTJmcmZjZGlmZiUzZnVybDIlM2RkcmFmdC1pZXRmLXJ1bS1ydWUtMDQmYW1wO2M9RSwxLDh0UW5F dGxlZ1lpS09rRU90N1NJaEw4SjZVc01VMHFpN0xMalVYRzM5aXJqbUZYNlRNbkhaZVVhaVJGNjdB eDNOQ21yYkkwRGFUYnhkbVZvRWdtandiZkxoUUpDUk95OXM5WUVzUHVyd0F0Q0lWLVI3R1Ffb3R3 U0VRLCwmYW1wO3R5cG89MSZhbXA7YW5jcl9hZGQ9MSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZj ZGlmZj91cmwyPWRyYWZ0LWlldGYtcnVtLXJ1ZS0wNDwvYT48YnI+DQo8YnI+DQo8YnI+DQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYg YXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciPg0KdG9vbHMu aWV0Zi5vcmc8L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFi bGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL2xpbmtwcm90ZWN0 LmN1ZGFzdmMuY29tL3VybD9hPWZ0cCUzYSUyZiUyZmZ0cC5pZXRmLm9yZyUyZmludGVybmV0LWRy YWZ0cyUyZiZhbXA7Yz1FLDEscURCNFNhMkM2LVBVeS1EZEtrT09OYmF1Z1hZel84SWVxclMwMUlK WXA1QUpaTURzdjBqOC03T0Y4d1Z5clIxYzRnZV9WdzVKdGxlODZBMkQzRUJhUW14dnRWd3VObS1u NHFoZ2tNdkVsMVFSRzRHciZhbXA7dHlwbz0xJmFtcDthbmNyX2FkZD0xIj5mdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBtYWls aW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIj5JLUQt QW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9saW5rcHJvdGVjdC5j dWRhc3ZjLmNvbS91cmw/YT1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZs aXN0aW5mbyUyZmktZC1hbm5vdW5jZSZhbXA7Yz1FLDEsZ01YV0lJdG8wQWxYU2xrLVo4V0Qza3Vl WUZPcFB6ZkE3aXdXWHJQa1c4SWlWMy1Wcm8zNUNmQlJfUkZnRURueklUT0xXbFVzOFFaY3pIRXZO aWVYbGxuazIzU01GU3NjTjdjamNLYlhpc1BwM0lBQmg3ZWp6ZURIJmFtcDt0eXBvPTEmYW1wO2Fu Y3JfYWRkPTEiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91 bmNlPC9hPjxicj4NCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOjxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL2xpbmtwcm90 ZWN0LmN1ZGFzdmMuY29tL3VybD9hPWh0dHAlM2ElMmYlMmZ3d3cuaWV0Zi5vcmclMmZzaGFkb3cu aHRtbCZhbXA7Yz1FLDEsSFJfQzhWZDFxcGFmY0l2V21Ic1ZrQ1ltYXdCNFpWSndmcGVSS05BRGlm QkZwUkZBc2UyUk9SS3hMNG1uX0xBV2VZVDRLdXpmU0ttb3J4OGtvZEFvejJ4VzZvaDdLYXlqY3dM WThPZGI1USwsJmFtcDt0eXBvPTEmYW1wO2FuY3JfYWRkPTEiPmh0dHA6Ly93d3cuaWV0Zi5vcmcv c2hhZG93Lmh0bWw8L2E+PGJyPg0Kb3I8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9saW5rcHJvdGVjdC5jdWRhc3ZjLmNvbS91 cmw/YT1mdHAlM2ElMmYlMmZmdHAuaWV0Zi5vcmclMmZpZXRmJTJmMXNoYWRvdy1zaXRlcy50eHQm YW1wO2M9RSwxLHVOSFVIM2twSDVodmc2bjd3MFl2U0NQcTZuMWZHdk9RSkxPUEd6RFFPRWRVeGFh X254Y0xhaHJVOG04YnBGVVhQcW9MWWpIcUR5T0JHUmpwR01RemxJdnRCWllyc2hORUVmYzhLODZ4 UUEsLCZhbXA7dHlwbz0xJmFtcDthbmNyX2FkZD0xIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8x c2hhZG93LXNpdGVzLnR4dDwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_MN2PR09MB5948653747A3D4E2399AB499B98E9MN2PR09MB5948namp_-- From nobody Tue Feb 9 06:41:35 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 BA85B3A0D9B for ; Tue, 9 Feb 2021 06:41:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.818 X-Spam-Level: X-Spam-Status: No, score=-1.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 rmLMkohw4KBn for ; Tue, 9 Feb 2021 06:41:32 -0800 (PST) Received: from outbound-ip25b.ess.barracuda.com (outbound-ip25b.ess.barracuda.com [209.222.82.222]) (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 A70EB3A0D9A for ; Tue, 9 Feb 2021 06:41:31 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx-outbound46-159.us-east-2c.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 09 Feb 2021 14:41:27 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 9 Feb 2021 06:41:24 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Tue, 9 Feb 2021 06:41:24 -0800 From: James Hamlin To: Jim Malloy CC: "rum@ietf.org" , Brian Rosen Thread-Topic: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/u7L+L8Bzh7VNUe/3kqFSgvmaapP4JCR Date: Tue, 9 Feb 2021 14:41:24 +0000 Message-ID: <1612881684171.60834@purple.us> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_161288168417160834purpleus_" MIME-Version: 1.0 X-BESS-ID: 1612881685-111935-5484-13410-1 X-BESS-VER: 2019.1_20210208.2004 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230171 [from cloudscan21-80.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] [EXT] Re: I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 14:41:35 -0000 --_000_161288168417160834purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Jim Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater fle= xibility in how a user's use of different RUE's can be isolated. I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= . Best Regards James James Hamlin Contractor 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: Jim Malloy Sent: 09 February 2021 14:20 To: Brian Rosen; James Hamlin Cc: rum@ietf.org Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt =93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94 James =96 Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials? (Mobile applications may do so at the OS level even if the a= pplication doesn=92t explicitly do so.) If so, is there a reason to treat = the RUE Differently? Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 From: Rum On Behalf Of Brian Rosen Sent: Tuesday, February 9, 2021 8:44 AM To: Hamlin, James Cc: rum@ietf.org Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt I=92ll delete the text in registration. Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use. Every one. They do that for a simple reason - so incomi= ng calls work after a power loss. Most also are effectively set and forget= , which is what you want in a phone. Why would we require manual entry for= the RUE? The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it. I think that=92s pretty reasonable. If you have another proposal for how we can maintain the config data secure= ly, please suggest one. Brian On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: Brian Section 5.1 Registration says that "The credentials to be used (username an= d password) MUST be supplied within the credentials section of the configur= ation and identified by the realm the registrar uses in a digest challenge.= This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 draft, password= s are no longer returned in the configuration. I think we need to avoid the= RUM RUE caching the user's main account password, which this draft seems t= o require. Best regards James James Hamlin Contractor 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: Rum > on behalf of = Brian Rosen > Sent: 05 February 2021 22:26 To: rum@ietf.org Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt I have posted a -04 revision. This should handle all comments received so = far, please let me know if I forgot something. This version reworks the provider list and configuration sections along the= lines we have been discussing. I do not have a way to download a username/password from a new signup. I= =92m having trouble thinking about a secure way to do that. If anyone has = an idea, I=92m very willing to write text for it. I=92ve considered things= like javascript that stashes it in a file or somewhere else, having some w= eb page function that triggers a local display of an entry form for usernam= e and password, and a couple of other things. One note on the configuration mechanism - because the only thing the local = RUE device needs to keep is the username password against a provider ID of = some kind, there isn=92t any need to standardize how that works, and so it= =92s completely absent in the text. For now, I=92ve removed the step by step diagram that showed how the config= mechanism is used. I think what is there is dead simple and needs no expl= anation: it=92s a straightforward REST/JSON web service using username/pass= word authentication for providers the user has accounts with. I can bring = back the diagram if that is needed. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-rum-rue-04.txt Date: February 5, 2021 at 5:17:15 PM EST To: > Cc: rum@ietf.org Reply-To: internet-drafts@ietf.org, rum@ie= tf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_161288168417160834purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Jim


Yes credentials have to be cached, but not necessarily the user's primar= y account credentials. The previous text allowed the configuration service = to send back separate credentials for SIP/STUN/TURN which could have a shor= ter validity period than the main account credentials. This offers greater flexibility in how a us= er's use of different RUE's can be isolated.


I'll accept that the provider could offer a separate password for use wi= th each RUE type; we'd need to think about the logistical implications of t= hat.


Best Regards


James



James Hamlin
Contractor
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 <= /div>
message.


From: Jim Malloy <jmal= loy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 

=93Every VoIP phone I=92ve ever seen or used caches = username and passwords for stand alone use=94

 

James =96

 

Do existing ZVRS/Purple devices or mobile applicatio= ns cache authentication credentials?  (Mobile applications may do so a= t the OS level even if the application doesn=92t explicitly do so.)  I= f so, is there a reason to treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

 

From: Rum <rum-bounces@ietf.org> On = Behalf Of Brian Rosen
Sent: Tuesday, February 9, 2021 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

 

I=92ll delete the text in registration.  

Every VoIP phone I=92ve ever seen or used caches use= rname and passwords for stand alone use.  Every one.  They do tha= t for a simple reason - so incoming calls work after a power loss.  Mo= st also are effectively set and forget, which is what you want in a phone.  Why would we require manual entry for the RUE?<= /p>

 

The text currently uses the same credentials for the= HTTP service and the SIP service, but that=92s it.  I think that=92s = pretty reasonable.

 

If you have another proposal for how we can maintain= the config data securely, please suggest one.

 

Brian



On Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> wrote:

 

Brian

 

Section 5.1 Registration says that "The credentia= ls to be used (username and password) MUST be supplied within the credentia= ls section of the configuration and identified by the realm the registrar uses in a digest challenge. This username/passw= ord combination SHOULD NOT be the same as that used for other purposes, suc= h as retrieving the RUE configuration or logging into the Provider's custom= er service portal.". However, in the 04 draft, passwords are no longer returned in the configuration. = I think we need to avoid the RUM RUE caching the user's main account passwo= rd, which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brian= rosen.net>
Sent: 05 February = 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd= : I-D Action: draft-ietf-rum-rue-04.txt

 <= /p>

I have posted a -04 revision.  This should handle= all comments received so far, please let me know if I forgot something.

 

This version reworks the provider list and configurati= on sections along the lines we have been discussing.

 

I do not have a way to download a username/password fr= om a new signup.  I=92m having trouble thinking about a secure way to = do that.  If anyone has an idea, I=92m very willing to write text for it.  I=92ve considered things like javascript that = stashes it in a file or somewhere else, having some web page function that = triggers a local display of an entry form for username and password, and a = couple of other things.

 

One note on the configuration mechanism - because the = only thing the local RUE device needs to keep is the username password agai= nst a provider ID of some kind, there isn=92t any need to standardize how that works, and so it=92s completely a= bsent in the text.  

 

For now, I=92ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is dea= d simple and needs no explanation: it=92s a straightforward REST/JSON web service using username/password authentication for providers= the user has accounts with.  I can bring back the diagram if that is = needed.

 

Brian

 



Begin forwarded message:

 

Subject: = ;I-D Action: draft-ietf-rum-rue-04.txt

Date: February 5, 2= 021 at 5:17:15 PM EST

 


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

       Title     &nb= sp;     : Interoperability Profile for Relay User = Equipment
       Author     &n= bsp;    : Brian Rosen
Filename        : draft-ietf-rum-rue-04.= txt
Pages           : 33
Date            : 20= 21-02-05

Abstract:
  Video Relay Service (VRS) is a term used to describe a method b= y
  which a hearing persons can communicate with deaf/Hard of Heari= ng
  user using an interpreter ("Communications Assistant"= ) connected via
  a videophone to the deaf/HoH user and an audio telephone call t= o the
  hearing user.  The CA interprets using sign language on th= e
  videophone link and voice on the telephone link.  Often th= e
  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 ser= vice,
  and subsequently to CAs and other deaf/HoH users.  It is d= esirable
  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 t= hat
  video calls direct between deaf/HoH users work.  This docu= ment
  describes the interface between a videophone and a provider.

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

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


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

 

 

 

--_000_161288168417160834purpleus_-- From nobody Tue Feb 9 08:28: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 A0A693A0F13 for ; Tue, 9 Feb 2021 08:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 SsPAl1RgA1-Y for ; Tue, 9 Feb 2021 08:27:57 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2046.outbound.protection.outlook.com [40.107.223.46]) (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 92D603A0F0E for ; Tue, 9 Feb 2021 08:27:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SXEvH18Fjk05w4EBLhPndXmUZUoWBhhgXoz0CvM878EylHJOrJr/ThqMjamPazZVuDuGt+4MzpHIjPHUiX0IWOM18Lhzz35l4bEzU3YHyvcFe5vS2OSFvJbWeXDiUsKbZ+PuAK1GOKA03YpM4mkb5Fu/e+GqamSXIr0FLDZGL6B5/qOLVrlyldPYl+xhl4JBpzgEJ56zBGONlfZrDSP/zKn16dH10Bi6DoYFpi4v3Q1c/t/GTkB9SH/mZfLxLMKxQBYfcgArPBDCbd4RnimhV4RAeAn0uO2IDT/Jw7R12Z7/2zSYvHOP3zJsF8LqyoYk1oL1MPrgmen3Z+KjHp41Uw== 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=l1iB0THaV5/9GKeQWDL8GwkoV/Voss3RZj6Zaq7Fxo8=; b=ZdbRpPSGD9aAtie0OA7gtDE9I+iUcWJzgU9i0DehDTXWEKBcwmYk1Gyt/NOT8Aaz6D9WvhtdyuyjuI7nouUMJQjOM5R0N5jUGkPxmvaLr/QB0gAqpbOAiY/z32ldY1PUKPTqf9x+oXSJ1wd3I77Pcf8JWjDbPdJCG9KL0kqmgN4wf83C8AGvTP4+XAO3kTfmQOWf82xudgn+9kMgIz0UOl+wZJJr/YfN240KBSFm+/ss1auAxCMD4upphJYc2KzEAqabpGzVOiLfWReh/VZppqSg5FxoJ5eTzG7Ml2xaZlvkWuC4tcYpS1DVstjp8NlOAWyH4BIsyG2kyd9OpBB7wA== 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=l1iB0THaV5/9GKeQWDL8GwkoV/Voss3RZj6Zaq7Fxo8=; b=wVuAzrzhnTQiTcG2gS20PJfnk1VGc5Kd/sBXDj+4Kozfr4EJv3VLBm3n22LjWprXBROf+29gcfx3CfFEzau7JSzhQaWvKD5+kXMJ9ZvaqNWLM8OR1z8MvDRAKGCrn8OJMiEgvA7wBIV9TeuS8Q0i1iCqarX4MEIFCmfbcPQWnD4= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by SJ0PR04MB7453.namprd04.prod.outlook.com (2603:10b6:a03:290::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.25; Tue, 9 Feb 2021 16:27:52 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681%6]) with mapi id 15.20.3846.025; Tue, 9 Feb 2021 16:27:52 +0000 From: Eugene Christensen To: Brian Rosen , "rum@ietf.org" Thread-Topic: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/A4SODw/7X3ac0aP3CLF9a5ZCapQB/WA Date: Tue, 9 Feb 2021 16:27:51 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> In-Reply-To: <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@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-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 15a03dff-141f-4a5d-fd4a-08d8cd17a5b4 x-ms-traffictypediagnostic: SJ0PR04MB7453: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: G+prAYTnCRTF9lgTHuJFGVT7kDZDIjaxpcqu1vDS0dA+K4lV5NhIMW2FGFaOt9Mc4GCODm5KdTR2Q3uB0ZFsFbqOm9O6cvhFnlzDdOVk/aECyX2rqJPeT5teVm2Fk9bE/S4VQ2e0cttS+coWR0SKCnNDjv2IyQBbbbs3wNsxKWNng6mnjGACWJvCxKfmz6sOQHKAQI5cKaJjmiPCeuID8f0BgsNS5IbZBy5hXvI8JoB6hfgGvHtDBGN1zexRKcAEIbqYhvt6xhfX4R8bIZV5WHMPYXojWXMER3LfBYM5azV/r4a4lARMGAoqqi3twF87KHSEBhiNANekKOnl+L8PTX6JLSMADZcHhExU+OrQXMIjYuyedKKVn/Iul/4w4KOTCzQnQrUV2DCIaPhPitLjf+UL91bqc3YGDDcNS10cstOlsoxtiNhRcqnouYFBWVDyDT0cYnDsIIXsbxaSFNSchABDwBcmSKdUITBT86De7iNZ9DtQlkqF+SLO2IPz46DwNh5GbZjXy6pUhArzRULdZha7lbIJ1TfXuBqrGvWLBgeKjWVxqDQSQpRY2Hne7aFWfDjDNe/gURv0LG/dJPd3xGfQKkgvKRWgOFE9phKR7fE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(136003)(366004)(39850400004)(376002)(86362001)(186003)(966005)(26005)(166002)(83380400001)(9326002)(2906002)(66574015)(6506007)(76116006)(33656002)(316002)(66556008)(64756008)(66446008)(9686003)(66946007)(18074004)(71200400001)(66476007)(5660300002)(53546011)(8676002)(7696005)(52536014)(8936002)(55016002)(478600001)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RXM1ZTNqYm5ZSEpWK3JUTjYybGVBSlpIQmQ5UzVDNjFBYzlLU0RlYkRLR2Q0?= =?utf-8?B?amQ0K0JPYkExYUdFcHVrdTJSUWU1NERxY2Q2b1RMSENhSnl5VFNHY2dVb2Ju?= =?utf-8?B?NmpyakFvelBkZ01BWDVzNzRKTUtnVEJ6b0NXcmdmSjd0eHA4NlYyZWRURkpo?= =?utf-8?B?YnMvYU14ZlNBeWFOZG5weTl4cXMwNW95VytaMFZ5MG5WZmtudG9ML3RxU1Rv?= =?utf-8?B?S0FmVHlkVWFuOVVCb0hWTm12NUg0b2puRHRXZ2JpSFAvNzFqZmZ1TUpiRDh4?= =?utf-8?B?cW5maVFQcHBzcHBwSS9rNGxSdDNvcVZQUE9VMW1sUE1yVE0rWjJOSHdIdnVi?= =?utf-8?B?T1p0cTVpYTRxWE9tc1l2SXFRSVJMdnNaNG5VcVN0OEVKemphSzI5Lzl6SXpM?= =?utf-8?B?MWVxK05uUFFYMGVqTTczbzFVTVhZT2xaa2Vud2JNOE81ZDRjencxeFovWmRZ?= =?utf-8?B?NysvcjJvWmRMdklrWnFtTGVCSnZSWnI2UTg2RENyejBXeGhlejZjcHVSTG9W?= =?utf-8?B?N2sxeDJRN09mUHJHWEJkK1FHQ1pwZlRxZHR1TThqUi93Y1hPMnU2ck5zNENX?= =?utf-8?B?OFlQS1JrL0szOHd0Vmw5SVJyaWhoMDdoOHpveEU0U0hNZmpzVFZ4UnFFZERC?= =?utf-8?B?SWRBb1Uvb2pMbEZEK3g5MVpZK0NDSnlYWFJJbDNzQ0pNY0toOThJSnFIN2Iy?= =?utf-8?B?VWVKVXlMTG9LVWZ0R0tHWWdiYnhGdFh1SnBQN3g2c0NYQXl2bmtoWXFHVzds?= =?utf-8?B?YkJpOEVWSHFzclMyMlE4a1cyYjg3Sk1vMUphN1J5SVJmUU94eExyb0xHS1R3?= =?utf-8?B?d2wxZVRyTDZhSDhmNW1sMzZTeVdydm84ZDRsMWM2TTFRWmE3UW50UXV1ay9i?= =?utf-8?B?VUpXL0pMMjU1UUFSQ1lzbGpreUo1aHBqVjgxTzJQZmVpYk9HZE92VlFVUU1p?= =?utf-8?B?Vnh6eC9YYjIxN0pNSnRZVlhNL0ZlYUJpNDFCK2h0NU5TcW92WW55L0hsYk5K?= =?utf-8?B?dmYzY3g3MXFUQ2F1V2FiUnNiRHlJV0hlUTBqTHRiUVh5Zm1UTk9yemRYQ0pi?= =?utf-8?B?TTB1NjB4LzlINkkvVnB6dFFGUHdPZ3VHYWpXTzYvRjVVTDVGTjUzSTFHbXhZ?= =?utf-8?B?UmpnNzkwVzdqdWdiQTVwajRXRldWc09VVy9lTVR3ekpqdW1jcVlQditzQmVv?= =?utf-8?B?Q3dpNGJCakgwdjRRdUoxYnpYWElOa0dqM2hvN1pzMGN5UitBekNLTU1USnhJ?= =?utf-8?B?dVZZT1pRRHRia2Z3UEZOM0FiaTZVSEQ1MkRxalEwSmRsSGF0N2RhcXA2YWRp?= =?utf-8?B?TXBoZHpuQW1iOEdtQ29yNldhajI4WW9NM3pjQWhxQU9zK2oxVUhlRmI0bjVI?= =?utf-8?B?WUV0YjFiYzdEZFNnYkU4UGFsYm9JaGRSVW5EZFY3c2lOTGd3VW9UbkVFQmtV?= =?utf-8?B?UnVTVjFRWGZYMDU4TWxqRFJFbU1WOW5PYU9TUHdyWHF5S2I2MkRwaFJMb1hi?= =?utf-8?B?VlZBemFxLzV0d1lHUTFIS2s5MHBJNHl5OWpZRER5clllT2ZkZHhhdjF6SzJw?= =?utf-8?B?QlEzWHpJVnhWeS9PNVNCaGVpUUVrdDk4eEV6SDlIZzJjQVUvQWhtTlAxa1JU?= =?utf-8?B?ZkVSQkxiTFVPOUx0dmFQS1hIdkdrYTBJR2VrbHZFb21nOHV4TEdxaCtmbUo2?= =?utf-8?B?L1R4OUFSSUlaUm9JTGQ5MHo1c0RENGlrZ3hCT0ZPVXNpalBFZEFSa2VsY3Qy?= =?utf-8?Q?yP3gOf6nWOY4GzrILAn18vSJf60A7OyfR3NRGnG?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR04MB4983DB2972C7C70F0E1BDF2EA38E9BYAPR04MB4983namp_" MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 15a03dff-141f-4a5d-fd4a-08d8cd17a5b4 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2021 16:27:52.0189 (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: 9i1+axdgYJP1XhnczMQB2o1LDlFEhIrEbZamQTx46MMijtCbW5TyHl5lLPiheMIIkC5Q40VZIdolYPcI8Aj9WPOP3vjjGeUwdmce96N6Mug= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR04MB7453 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 16:28:01 -0000 --_000_BYAPR04MB4983DB2972C7C70F0E1BDF2EA38E9BYAPR04MB4983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4sDQoNCkkgaGF2ZSBhIGZldyB0aG91Z2h0cyBvbiB0aGlzIGFuZCBhIGZldyB0eXBv cyB0aGF0IEnigJlsbCBwb2ludCBvdXQuDQoNCg0KU3Vic3RhbmNlIENvbW1lbnRzDQoNCiAgKiAg IFNlY3Rpb24gNDogUmVxdWlyZW1lbnQgZm9yIElQdjQgYW5kIElQdjYuICBXaHkgaXMgSVB2NiBu b3cgYSByZXF1aXJlbWVudD8gIFdoeSBub3Qgb3B0aW9uYWw/DQogICogICBTZWN0aW9uIDkuMiAt IFRoZSB2ZXR0aW5nIHByb2Nlc3MgZm9yIGEgcG90ZW50aWFsIGN1c3RvbWVyIGRvZXMgbm90IGxl bmQgaXRzZWxmIHRvIGEgcGVyc29uIGJlaW5nIGFibGUgdG8gc2ltcGx5IHNpZ24gdXAgbGlrZSB0 aGlzLiAgVGhlIGN1c3RvbWVyIHdpbGwgYmUgcmVxdWlyZWQgdG8gaGF2ZSBhbiBhY2NvdW50IGJl Zm9yZSBiZWluZyBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHByb3ZpZGVyIHNlcnZpY2Uu ICBJIHRoZXJlZm9yZSBiZWxpZXZlIHdlIHNob3VsZCByZW1vdmUgdGhlIGFiaWxpdHkgZm9yIHRo ZSBSVUUgZGV2aWNlIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHByb3ZpZGVyIHdpdGhvdXQgYSB1 c2VyaWQvcGFzc3dvcmQuDQogICogICBTZWN0aW9uIDkuMiAtIEluIHRoZSBzZWN0aW9uIGZvciB0 aGUgcGF5bG9hZCwgaXQgaXMgbWlzc2luZyB0aGUgcHJvdmlkZXItZG9tYWluIGluIHRoZSB0ZXh0 IHNlY3Rpb24gYnV0IGl0IGlzIGluY2x1ZGVkIGluIHRoZSBleGFtcGxlLiAgSSBleHBlY3QgdGhp cyBpcyBzaW1wbHkgYW4gb3ZlcnNpZ2h0Lg0KDQoNCg0KVHlwbyBDb21tZW50cw0KDQogICogICBT ZWN0aW9uIDUuNSwgIFJlbW92ZSByZWR1bmRhbnQgInRoYXQiIGZyb20gZmlyc3Qgc2VudGVuY2Ug InRoYXQgdGhhdCINCiAgKiAgIFNlY3Rpb24gOSwgIDJuZCBzZW50ZW5jZSByZWFkcyBhd2t3YXJk bHkuICBQZXJoYXBzIGNoYW5nZSB0byAiT25lIHByb3ZpZGVzIGEgZGlyZWN0b3J5IG9mIHByb3Zp ZGVycyBzbyB0aGF0IGEgdXNlciBpbnRlcmZhY2UgYWxsb3dzIGVhc3kgcHJvdmlkZXIgc2VsZWN0 aW9uIC4uLiINCiAgKiAgIFNlY3Rpb24gOS4xLCBnZXQgcmlkIG9mIGV4dHJhICJhIiBpbiB0aGUg c2VjdGlvbiAiLi4uYSBjb3VudHJ5IGNvZGUgc3VpdGFibGUgZm9yIGRpc3BsYXksIHdpdGggYSBj b3JyZXNwb25kaW5nICJhIiBVUkkgLi4uDQogICogICBTZWN0aW9uIDkuMiwgZ2V0IHJpZCBvZiBl eHRyYSAidGhlIiBpbiB0aGUgZmlyc3Qgc2VudGVuY2UgIi4uLnByb3ZpZGVyIGNvbmZpZ3VyYXRp b24gInRoZSIgdXNpbmcgYSBzaW1wbGUuLi4iDQogICogICBTZWN0aW9uIDkuNCAtIEdldCByaWQg b2YgdGhlIHJlZHVuZGFudCB3b3JkICJTZWN0aW9ucyIgaW4gdGhlIGZpcnN0IHNlbnRlbmNlICJU aGUgaW50ZXJmYWNlcyBpbiAiU2VjdGlvbnMiIFNlY3Rpb24gOS4xIC4uLiINCg0KDQpUaGFua3Mu DQoNCkV1Z2VuZSBDaHJpc3RlbnNlbi4NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBl LW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMg ZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVkIHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg YW5kIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0 aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBk aXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIGFueSBvZiB0aGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIG9yIGF0dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJ Q1RMWSBQUk9ISUJJVEVELiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBp biBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQg ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTxtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNv bT4gb3IgYnkgdGVsZXBob25lIGF0ICsxICg4MDEpIDI4Ny05NDE5LCBhbmQgZGVzdHJveSB0aGUg b3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5n IHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlzay4NCg0KRnJvbTogUnVtIDxydW0tYm91bmNlc0Bp ZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIFJvc2VuDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5 IDUsIDIwMjEgMzoyNyBQTQ0KVG86IHJ1bUBpZXRmLm9yZw0KU3ViamVjdDogW1J1bV0gRndkOiBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQoNCltFWFRFUk5BTF0gSSBoYXZl IHBvc3RlZCBhIC0wNCByZXZpc2lvbi4gIFRoaXMgc2hvdWxkIGhhbmRsZSBhbGwgY29tbWVudHMg cmVjZWl2ZWQgc28gZmFyLCBwbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBmb3Jnb3Qgc29tZXRoaW5n Lg0KDQpUaGlzIHZlcnNpb24gcmV3b3JrcyB0aGUgcHJvdmlkZXIgbGlzdCBhbmQgY29uZmlndXJh dGlvbiBzZWN0aW9ucyBhbG9uZyB0aGUgbGluZXMgd2UgaGF2ZSBiZWVuIGRpc2N1c3NpbmcuDQoN CkkgZG8gbm90IGhhdmUgYSB3YXkgdG8gZG93bmxvYWQgYSB1c2VybmFtZS9wYXNzd29yZCBmcm9t IGEgbmV3IHNpZ251cC4gIEnigJltIGhhdmluZyB0cm91YmxlIHRoaW5raW5nIGFib3V0IGEgc2Vj dXJlIHdheSB0byBkbyB0aGF0LiAgSWYgYW55b25lIGhhcyBhbiBpZGVhLCBJ4oCZbSB2ZXJ5IHdp bGxpbmcgdG8gd3JpdGUgdGV4dCBmb3IgaXQuICBJ4oCZdmUgY29uc2lkZXJlZCB0aGluZ3MgbGlr ZSBqYXZhc2NyaXB0IHRoYXQgc3Rhc2hlcyBpdCBpbiBhIGZpbGUgb3Igc29tZXdoZXJlIGVsc2Us IGhhdmluZyBzb21lIHdlYiBwYWdlIGZ1bmN0aW9uIHRoYXQgdHJpZ2dlcnMgYSBsb2NhbCBkaXNw bGF5IG9mIGFuIGVudHJ5IGZvcm0gZm9yIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5kIGEgY291 cGxlIG9mIG90aGVyIHRoaW5ncy4NCg0KT25lIG5vdGUgb24gdGhlIGNvbmZpZ3VyYXRpb24gbWVj aGFuaXNtIC0gYmVjYXVzZSB0aGUgb25seSB0aGluZyB0aGUgbG9jYWwgUlVFIGRldmljZSBuZWVk cyB0byBrZWVwIGlzIHRoZSB1c2VybmFtZSBwYXNzd29yZCBhZ2FpbnN0IGEgcHJvdmlkZXIgSUQg b2Ygc29tZSBraW5kLCB0aGVyZSBpc27igJl0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIGhvdyB0 aGF0IHdvcmtzLCBhbmQgc28gaXTigJlzIGNvbXBsZXRlbHkgYWJzZW50IGluIHRoZSB0ZXh0Lg0K DQpGb3Igbm93LCBJ4oCZdmUgcmVtb3ZlZCB0aGUgc3RlcCBieSBzdGVwIGRpYWdyYW0gdGhhdCBz aG93ZWQgaG93IHRoZSBjb25maWcgbWVjaGFuaXNtIGlzIHVzZWQuICBJIHRoaW5rIHdoYXQgaXMg dGhlcmUgaXMgZGVhZCBzaW1wbGUgYW5kIG5lZWRzIG5vIGV4cGxhbmF0aW9uOiBpdOKAmXMgYSBz dHJhaWdodGZvcndhcmQgUkVTVC9KU09OIHdlYiBzZXJ2aWNlIHVzaW5nIHVzZXJuYW1lL3Bhc3N3 b3JkIGF1dGhlbnRpY2F0aW9uIGZvciBwcm92aWRlcnMgdGhlIHVzZXIgaGFzIGFjY291bnRzIHdp dGguICBJIGNhbiBicmluZyBiYWNrIHRoZSBkaWFncmFtIGlmIHRoYXQgaXMgbmVlZGVkLg0KDQpC cmlhbg0KDQoNCg0KQmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRy YWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDog SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0KRGF0ZTogRmVicnVhcnkgNSwg MjAyMSBhdCA1OjE3OjE1IFBNIEVTVA0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRv OmktZC1hbm5vdW5jZUBpZXRmLm9yZz4+DQpDYzogcnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0 Zi5vcmc+DQpSZXBseS1UbzogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5l dC1kcmFmdHNAaWV0Zi5vcmc+LCBydW1AaWV0Zi5vcmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NCg0K DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRl cm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo ZSBSZWxheSBVc2VyIE1hY2hpbmUgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRsZSAgICAg ICAgICAgOiBJbnRlcm9wZXJhYmlsaXR5IFByb2ZpbGUgZm9yIFJlbGF5IFVzZXIgRXF1aXBtZW50 DQogICAgICAgQXV0aG9yICAgICAgICAgIDogQnJpYW4gUm9zZW4NCiAgICAgICAgICAgICAgICBG aWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQogICAgICAgICAgICAg ICAgUGFnZXMgICAgICAgICAgIDogMzMNCiAgICAgICAgICAgICAgICBEYXRlICAgICAgICAgICAg OiAyMDIxLTAyLTA1DQoNCkFic3RyYWN0Og0KICBWaWRlbyBSZWxheSBTZXJ2aWNlIChWUlMpIGlz IGEgdGVybSB1c2VkIHRvIGRlc2NyaWJlIGEgbWV0aG9kIGJ5DQogIHdoaWNoIGEgaGVhcmluZyBw ZXJzb25zIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGRlYWYvSGFyZCBvZiBIZWFyaW5nDQogIHVzZXIg dXNpbmcgYW4gaW50ZXJwcmV0ZXIgKCJDb21tdW5pY2F0aW9ucyBBc3Npc3RhbnQiKSBjb25uZWN0 ZWQgdmlhDQogIGEgdmlkZW9waG9uZSB0byB0aGUgZGVhZi9Ib0ggdXNlciBhbmQgYW4gYXVkaW8g dGVsZXBob25lIGNhbGwgdG8gdGhlDQogIGhlYXJpbmcgdXNlci4gIFRoZSBDQSBpbnRlcnByZXRz IHVzaW5nIHNpZ24gbGFuZ3VhZ2Ugb24gdGhlDQogIHZpZGVvcGhvbmUgbGluayBhbmQgdm9pY2Ug b24gdGhlIHRlbGVwaG9uZSBsaW5rLiAgT2Z0ZW4gdGhlDQogIGludGVycHJldGVycyBtYXkgYmUg c3VwcGxpZWQgYnkgYSBjb21wYW55IG9yIGFnZW5jeSB0ZXJtZWQgYQ0KICAicHJvdmlkZXIiIGlu IHRoaXMgZG9jdW1lbnQuICBUaGUgcHJvdmlkZXIgYWxzbyBwcm92aWRlcyBhIHZpZGVvDQogIHNl cnZpY2UgdGhhdCBhbGxvd3MgdXNlcnMgdG8gY29ubmVjdCB2aWRlbyBkZXZpY2VzIHRvIHRoZWly IHNlcnZpY2UsDQogIGFuZCBzdWJzZXF1ZW50bHkgdG8gQ0FzIGFuZCBvdGhlciBkZWFmL0hvSCB1 c2Vycy4gIEl0IGlzIGRlc2lyYWJsZQ0KICB0aGF0IHRoZSB2aWRlb3Bob25lcyB1c2VkIGJ5IHRo ZSBkZWFmL0hvSC9ILUkgdXNlciBjb25mb3JtIHRvIGENCiAgc3RhbmRhcmQgc28gdGhhdCBhbnkg ZGV2aWNlIG1heSBiZSB1c2VkIHdpdGggYW55IHByb3ZpZGVyIGFuZCB0aGF0DQogIHZpZGVvIGNh bGxzIGRpcmVjdCBiZXR3ZWVuIGRlYWYvSG9IIHVzZXJzIHdvcmsuICBUaGlzIGRvY3VtZW50DQog IGRlc2NyaWJlcyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gYSB2aWRlb3Bob25lIGFuZCBhIHByb3Zp ZGVyLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0 IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydW0tcnVl Lw0KDQpUaGVyZSBpcyBhbHNvIGFuIEhUTUwgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczov L3d3dy5pZXRmLm9yZy9hcmNoaXZlL2lkL2RyYWZ0LWlldGYtcnVtLXJ1ZS0wNC5odG1sDQoNCkEg ZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8v d3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUtMDQNCg0KDQpQbGVh c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt ZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzLw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlDQpJbnRl cm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbA0K b3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQNCg0K --_000_BYAPR04MB4983DB2972C7C70F0E1BDF2EA38E9BYAPR04MB4983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpz cGFuLmFwcGxlLXRhYi1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXRhYi1zcGFuO30NCnNw YW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5Q bGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZp bml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTA5Njg2NTk3Ow0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyOTIwNDYxMzAgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxp c3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6ODkwMzg0MzA2Ow0KCW1zby1saXN0LXR5 cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMjg3MTIzNTM2IDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4 NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0 IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl O2xpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIEJyaWFuLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBoYXZlIGEgZmV3IHRob3VnaHRzIG9uIHRoaXMgYW5kIGEgZmV3IHR5cG9zIHRoYXQgSeKA mWxsIHBvaW50IG91dC4mbmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48Yj5TdWJz dGFuY2UgQ29tbWVudHM8bzpwPjwvbzpwPjwvYj48L3A+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzEiPlNlY3Rpb24gNDogUmVxdWlyZW1lbnQgZm9yIElQdjQgYW5kIElQ djYuJm5ic3A7IFdoeSBpcyBJUHY2IG5vdyBhIHJlcXVpcmVtZW50PyZuYnNwOyBXaHkgbm90IG9w dGlvbmFsPzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1z by1saXN0OmwxIGxldmVsMSBsZm8xIj5TZWN0aW9uIDkuMiAtIFRoZSB2ZXR0aW5nIHByb2Nlc3Mg Zm9yIGEgcG90ZW50aWFsIGN1c3RvbWVyIGRvZXMgbm90IGxlbmQgaXRzZWxmIHRvIGEgcGVyc29u IGJlaW5nIGFibGUgdG8gc2ltcGx5IHNpZ24gdXAgbGlrZSB0aGlzLiZuYnNwOyBUaGUgY3VzdG9t ZXIgd2lsbCBiZSByZXF1aXJlZCB0byBoYXZlIGFuIGFjY291bnQgYmVmb3JlIGJlaW5nIGFibGUN CiB0byBjb21tdW5pY2F0ZSB3aXRoIHRoZSBwcm92aWRlciBzZXJ2aWNlLiZuYnNwOyBJIHRoZXJl Zm9yZSBiZWxpZXZlIHdlIHNob3VsZCByZW1vdmUgdGhlIGFiaWxpdHkgZm9yIHRoZSBSVUUgZGV2 aWNlIHRvIGNvbW11bmljYXRlIHdpdGggdGhlIHByb3ZpZGVyIHdpdGhvdXQgYSB1c2VyaWQvcGFz c3dvcmQuPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPlNlY3Rpb24gOS4yIC0gSW4gdGhlIHNlY3Rpb24gZm9yIHRo ZSBwYXlsb2FkLCBpdCBpcyBtaXNzaW5nIHRoZSBwcm92aWRlci1kb21haW4gaW4gdGhlIHRleHQg c2VjdGlvbiBidXQgaXQgaXMgaW5jbHVkZWQgaW4gdGhlIGV4YW1wbGUuJm5ic3A7IEkgZXhwZWN0 IHRoaXMgaXMgc2ltcGx5IGFuIG92ZXJzaWdodC48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PGI+VHlwbyBDb21tZW50czxvOnA+PC9vOnA+PC9iPjwvcD4NCjx1bCBzdHlsZT0i bWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+U2VjdGlvbiA1LjUsJm5ic3A7IFJlbW92ZSBy ZWR1bmRhbnQgJnF1b3Q7dGhhdCZxdW90OyBmcm9tIGZpcnN0IHNlbnRlbmNlICZxdW90O3RoYXQg dGhhdCZxdW90OzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1zby1saXN0OmwwIGxldmVsMSBsZm8yIj5TZWN0aW9uIDksJm5ic3A7IDJuZCBzZW50ZW5jZSBy ZWFkcyBhd2t3YXJkbHkuJm5ic3A7IFBlcmhhcHMgY2hhbmdlIHRvICZxdW90O09uZSBwcm92aWRl cyBhIGRpcmVjdG9yeSBvZiBwcm92aWRlcnMgc28gdGhhdCBhIHVzZXIgaW50ZXJmYWNlIGFsbG93 cyBlYXN5IHByb3ZpZGVyIHNlbGVjdGlvbiAuLi4mcXVvdDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+U2VjdGlv biA5LjEsIGdldCByaWQgb2YgZXh0cmEgJnF1b3Q7YSZxdW90OyBpbiB0aGUgc2VjdGlvbiAmcXVv dDsuLi5hIGNvdW50cnkgY29kZSBzdWl0YWJsZSBmb3IgZGlzcGxheSwgd2l0aCBhIGNvcnJlc3Bv bmRpbmcgJnF1b3Q7YSZxdW90OyBVUkkgLi4uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv UGxhaW5UZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPlNlY3Rpb24gOS4yLCBn ZXQgcmlkIG9mIGV4dHJhICZxdW90O3RoZSZxdW90OyBpbiB0aGUgZmlyc3Qgc2VudGVuY2UgJnF1 b3Q7Li4ucHJvdmlkZXIgY29uZmlndXJhdGlvbiAmcXVvdDt0aGUmcXVvdDsgdXNpbmcgYSBzaW1w bGUuLi4mcXVvdDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxl PSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+U2VjdGlvbiA5LjQgLSBHZXQgcmlkIG9mIHRoZSBy ZWR1bmRhbnQgd29yZCAmcXVvdDtTZWN0aW9ucyZxdW90OyBpbiB0aGUgZmlyc3Qgc2VudGVuY2Ug JnF1b3Q7VGhlIGludGVyZmFjZXMgaW4gJnF1b3Q7U2VjdGlvbnMmcXVvdDsgU2VjdGlvbiA5LjEg Li4uJnF1b3Q7PG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5FdWdlbmUgQ2hyaXN0ZW5zZW4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6bmF2eSI+Q09ORklERU5USUFMSVRZIE5PVElDRS48L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpuYXZ5Ij4gVGhpcyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQg YW55IGRvY3VtZW50cywgZmlsZXMgb3INCiBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNo ZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3Jt YXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29u IHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQs IHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQog ZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1l ZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0DQo8L3NwYW4+PGEgaHJlZj0ibWFp bHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZWNocmlzdGVuc2Vu QHNvcmVuc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnkiPiBvciBieSB0 ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksDQogYW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFs IHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGluZyB0aGVtIG9y IHNhdmluZyB0aGVtIHRvIGRpc2suPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJ1bSAmbHQ7cnVtLWJvdW5jZXNAaWV0Zi5v cmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZiA8L2I+DQpCcmlhbiBSb3Nlbjxicj4NCjxiPlNlbnQ6PC9i PiBGcmlkYXksIEZlYnJ1YXJ5IDUsIDIwMjEgMzoyNyBQTTxicj4NCjxiPlRvOjwvYj4gcnVtQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtSdW1dIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1ydW0tcnVlLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+W0VYVEVSTkFMXTwvc3Bhbj4mbmJzcDtJIGhhdmUg cG9zdGVkIGEgLTA0IHJldmlzaW9uLiAmbmJzcDtUaGlzIHNob3VsZCBoYW5kbGUgYWxsIGNvbW1l bnRzIHJlY2VpdmVkIHNvIGZhciwgcGxlYXNlIGxldCBtZSBrbm93IGlmIEkgZm9yZ290IHNvbWV0 aGluZy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMg dmVyc2lvbiByZXdvcmtzIHRoZSBwcm92aWRlciBsaXN0IGFuZCBjb25maWd1cmF0aW9uIHNlY3Rp b25zIGFsb25nIHRoZSBsaW5lcyB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyBub3QgaGF2ZSBh IHdheSB0byBkb3dubG9hZCBhIHVzZXJuYW1lL3Bhc3N3b3JkIGZyb20gYSBuZXcgc2lnbnVwLiAm bmJzcDtJ4oCZbSBoYXZpbmcgdHJvdWJsZSB0aGlua2luZyBhYm91dCBhIHNlY3VyZSB3YXkgdG8g ZG8gdGhhdC4gJm5ic3A7SWYgYW55b25lIGhhcyBhbiBpZGVhLCBJ4oCZbSB2ZXJ5IHdpbGxpbmcg dG8gd3JpdGUgdGV4dCBmb3IgaXQuICZuYnNwO0nigJl2ZSBjb25zaWRlcmVkIHRoaW5ncyBsaWtl IGphdmFzY3JpcHQgdGhhdA0KIHN0YXNoZXMgaXQgaW4gYSBmaWxlIG9yIHNvbWV3aGVyZSBlbHNl LCBoYXZpbmcgc29tZSB3ZWIgcGFnZSBmdW5jdGlvbiB0aGF0IHRyaWdnZXJzIGEgbG9jYWwgZGlz cGxheSBvZiBhbiBlbnRyeSBmb3JtIGZvciB1c2VybmFtZSBhbmQgcGFzc3dvcmQsIGFuZCBhIGNv dXBsZSBvZiBvdGhlciB0aGluZ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBub3RlIG9uIHRoZSBjb25maWd1cmF0aW9uIG1lY2hhbmlz bSAtIGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgdGhlIGxvY2FsIFJVRSBkZXZpY2UgbmVlZHMgdG8g a2VlcCBpcyB0aGUgdXNlcm5hbWUgcGFzc3dvcmQgYWdhaW5zdCBhIHByb3ZpZGVyIElEIG9mIHNv bWUga2luZCwgdGhlcmUgaXNu4oCZdCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBob3cgdGhhdCB3 b3JrcywgYW5kIHNvIGl04oCZcyBjb21wbGV0ZWx5DQogYWJzZW50IGluIHRoZSB0ZXh0LiAmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Rm9yIG5vdywgSeKAmXZlIHJlbW92ZWQgdGhlIHN0ZXAgYnkgc3RlcCBkaWFncmFtIHRoYXQgc2hv d2VkIGhvdyB0aGUgY29uZmlnIG1lY2hhbmlzbSBpcyB1c2VkLiAmbmJzcDtJIHRoaW5rIHdoYXQg aXMgdGhlcmUgaXMgZGVhZCBzaW1wbGUgYW5kIG5lZWRzIG5vIGV4cGxhbmF0aW9uOiBpdOKAmXMg YSBzdHJhaWdodGZvcndhcmQgUkVTVC9KU09OIHdlYiBzZXJ2aWNlIHVzaW5nIHVzZXJuYW1lL3Bh c3N3b3JkIGF1dGhlbnRpY2F0aW9uDQogZm9yIHByb3ZpZGVycyB0aGUgdXNlciBoYXMgYWNjb3Vu dHMgd2l0aC4gJm5ic3A7SSBjYW4gYnJpbmcgYmFjayB0aGUgZGlhZ3JhbSBpZiB0aGF0IGlzIG5l ZWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6 NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0 LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3Vi amVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dDwvc3Bhbj48L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkRh dGU6IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPkZlYnJ1YXJ5IDUsIDIwMjEgYXQgNToxNzoxNSBQTSBFU1Q8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPlRvOiA8L3NwYW4+DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmktZC1hbm5vdW5jZUBp ZXRmLm9yZyI+aS1kLWFubm91bmNlQGlldGYub3JnPC9hPiZndDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkNjOiA8L3NwYW4+ DQo8L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj48YSBocmVmPSJtYWlsdG86cnVtQGlldGYub3JnIj5ydW1AaWV0Zi5vcmc8L2E+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5SZXBseS1UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+LA0KPGEgaHJlZj0ibWFp bHRvOnJ1bUBpZXRmLm9yZyI+cnVtQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkEgTmV3IEludGVybmV0LURyYWZ0 IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmll cy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBSZWxheSBVc2VyIE1hY2hp bmUgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7VGl0bGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBJbnRlcm9wZXJhYmlsaXR5IFByb2ZpbGUgZm9yIFJl bGF5IFVzZXIgRXF1aXBtZW50PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7QXV0aG9yICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzogQnJpYW4gUm9zZW48YnI+DQo8c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNw YW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+RmlsZW5hbWUgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBkcmFmdC1pZXRmLXJ1bS1y dWUtMDQudHh0PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPlBhZ2VzICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogMzM8YnI+DQo8c3BhbiBjbGFz cz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+RGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs6IDIwMjEtMDItMDU8YnI+DQo8YnI+DQpBYnN0cmFjdDo8YnI+DQom bmJzcDsmbmJzcDtWaWRlbyBSZWxheSBTZXJ2aWNlIChWUlMpIGlzIGEgdGVybSB1c2VkIHRvIGRl c2NyaWJlIGEgbWV0aG9kIGJ5PGJyPg0KJm5ic3A7Jm5ic3A7d2hpY2ggYSBoZWFyaW5nIHBlcnNv bnMgY2FuIGNvbW11bmljYXRlIHdpdGggZGVhZi9IYXJkIG9mIEhlYXJpbmc8YnI+DQombmJzcDsm bmJzcDt1c2VyIHVzaW5nIGFuIGludGVycHJldGVyICgmcXVvdDtDb21tdW5pY2F0aW9ucyBBc3Np c3RhbnQmcXVvdDspIGNvbm5lY3RlZCB2aWE8YnI+DQombmJzcDsmbmJzcDthIHZpZGVvcGhvbmUg dG8gdGhlIGRlYWYvSG9IIHVzZXIgYW5kIGFuIGF1ZGlvIHRlbGVwaG9uZSBjYWxsIHRvIHRoZTxi cj4NCiZuYnNwOyZuYnNwO2hlYXJpbmcgdXNlci4gJm5ic3A7VGhlIENBIGludGVycHJldHMgdXNp bmcgc2lnbiBsYW5ndWFnZSBvbiB0aGU8YnI+DQombmJzcDsmbmJzcDt2aWRlb3Bob25lIGxpbmsg YW5kIHZvaWNlIG9uIHRoZSB0ZWxlcGhvbmUgbGluay4gJm5ic3A7T2Z0ZW4gdGhlPGJyPg0KJm5i c3A7Jm5ic3A7aW50ZXJwcmV0ZXJzIG1heSBiZSBzdXBwbGllZCBieSBhIGNvbXBhbnkgb3IgYWdl bmN5IHRlcm1lZCBhPGJyPg0KJm5ic3A7Jm5ic3A7JnF1b3Q7cHJvdmlkZXImcXVvdDsgaW4gdGhp cyBkb2N1bWVudC4gJm5ic3A7VGhlIHByb3ZpZGVyIGFsc28gcHJvdmlkZXMgYSB2aWRlbzxicj4N CiZuYnNwOyZuYnNwO3NlcnZpY2UgdGhhdCBhbGxvd3MgdXNlcnMgdG8gY29ubmVjdCB2aWRlbyBk ZXZpY2VzIHRvIHRoZWlyIHNlcnZpY2UsPGJyPg0KJm5ic3A7Jm5ic3A7YW5kIHN1YnNlcXVlbnRs eSB0byBDQXMgYW5kIG90aGVyIGRlYWYvSG9IIHVzZXJzLiAmbmJzcDtJdCBpcyBkZXNpcmFibGU8 YnI+DQombmJzcDsmbmJzcDt0aGF0IHRoZSB2aWRlb3Bob25lcyB1c2VkIGJ5IHRoZSBkZWFmL0hv SC9ILUkgdXNlciBjb25mb3JtIHRvIGE8YnI+DQombmJzcDsmbmJzcDtzdGFuZGFyZCBzbyB0aGF0 IGFueSBkZXZpY2UgbWF5IGJlIHVzZWQgd2l0aCBhbnkgcHJvdmlkZXIgYW5kIHRoYXQ8YnI+DQom bmJzcDsmbmJzcDt2aWRlbyBjYWxscyBkaXJlY3QgYmV0d2VlbiBkZWFmL0hvSCB1c2VycyB3b3Jr LiAmbmJzcDtUaGlzIGRvY3VtZW50PGJyPg0KJm5ic3A7Jm5ic3A7ZGVzY3JpYmVzIHRoZSBpbnRl cmZhY2UgYmV0d2VlbiBhIHZpZGVvcGhvbmUgYW5kIGEgcHJvdmlkZXIuPGJyPg0KPGJyPg0KPGJy Pg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y dW0tcnVlLyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydW0t cnVlLzwvYT48YnI+DQo8YnI+DQpUaGVyZSBpcyBhbHNvIGFuIEhUTUwgdmVyc2lvbiBhdmFpbGFi bGUgYXQ6PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLXJ1 bS1ydWUtMDQuaHRtbDxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9u IGlzIGF2YWlsYWJsZSBhdDo8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1ydW0tcnVlLTA0PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBp dCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lv bjxicj4NCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2 YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ojxicj4NCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpJLUQtQW5ub3VuY2UgbWFpbGluZyBsaXN0PGJyPg0K SS1ELUFubm91bmNlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pLWQtYW5ub3VuY2U8YnI+DQpJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0 cDovL3d3dy5pZXRmLm9yZy9zaGFkb3cuaHRtbDxicj4NCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9p ZXRmLzFzaGFkb3ctc2l0ZXMudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR04MB4983DB2972C7C70F0E1BDF2EA38E9BYAPR04MB4983namp_-- From nobody Tue Feb 9 08:54: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 ED1E53A0FEB for ; Tue, 9 Feb 2021 08:54:01 -0800 (PST) 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 7IA-xpWYCWxe for ; Tue, 9 Feb 2021 08:53:58 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 C4D1C3A0FE8 for ; Tue, 9 Feb 2021 08:53:58 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id y5so16715112ilg.4 for ; Tue, 09 Feb 2021 08:53:58 -0800 (PST) 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=+Wiia1p7KA2LnNO2kRIUs3IDXpl7vTTg/Wre2NzuOwA=; b=P7FtS3/hfXTPUk6qmLVVeNmgWPE/elaB57UXnSDf7rf+tBCqQfBRcgp1ioOcMhDgBM kO+cEgxfL+yEMtPnXlOsrQl9rwLdTpjyejfS+kEilJPuP2+5fsNssZfqnPvDpCGpOW+m ARyF3rICX3Ajqx/PJeuwSAD4cthhWngDxwzmor3sxPVt7v3LtiReppko4dAUzcahju2A rU7xops6UL03f8T0N2M6/MIff5V6AeopRgKYw0eGvX/0warG9KNYi3jVzRzrcGfE9hKW YdDfk4ErVVsVxY8klZkVsFJASQGuUNy/IkgC+XQyKDOuacFO/fYz3Otvhr6QQVtsmilP at/A== 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=+Wiia1p7KA2LnNO2kRIUs3IDXpl7vTTg/Wre2NzuOwA=; b=HyZlfhmnrsu1pyZbkYbCLdQ4Hl3dDAHhWBaO2avAqV1Mu38ww4YJd2/d8zl1ybBZHh LmQz+7myZX7IjJD7KljoZPmQfCdVglVkXRnXgg+pkOGfP0GPd7gDE4d6cbW1fyWuoYG0 UImx+1wT4KTDti63ugErmoydzybnOM16dLnMB6unHT2Zreg6O2JFH5A3svI9eKpSZSw5 MMc8GpxlW0CHHiGXDgYkISzVmGpMKj8PlLJKvxIsvpXY2kggvRtPY01X9ozQMII0tVD2 HNxO28Ftw/AVGM8mMozI+glKIa754kcUFtP3hE4Y+xLcP5hIazU5jenVJqOei0nKRbmb z/Jw== X-Gm-Message-State: AOAM530riAQm26ppnWQIq2jOF1u1rjDii3k7zs7QQOtjGLAbMLIRLnvw Isditlk7tGbhJ0HrKWfYBIBjRQ== X-Google-Smtp-Source: ABdhPJzlI3OHDpNeZBkd8bYuDgXvqLJlBFVuVZDro+CV2SXY6kVChM7lOHGl6sbxHEbmV2mAs7TyLA== X-Received: by 2002:a05:6e02:1a25:: with SMTP id g5mr21171565ile.2.1612889637946; Tue, 09 Feb 2021 08:53:57 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id e23sm9481850ioc.34.2021.02.09.08.53.56 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Feb 2021 08:53:57 -0800 (PST) From: Brian Rosen Message-Id: <61A511CA-5EF9-4938-B77E-B9A4CB8FCA77@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_181BFD04-8F7D-4C43-AD9B-73FFE2B857EC" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 9 Feb 2021 11:53:55 -0500 In-Reply-To: Cc: "rum@ietf.org" To: Eugene Christensen References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 16:54:02 -0000 --Apple-Mail=_181BFD04-8F7D-4C43-AD9B-73FFE2B857EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 9, 2021, at 11:27 AM, Eugene Christensen = wrote: >=20 > Hi Brian,=20 > =20 > I have a few thoughts on this and a few typos that I=E2=80=99ll point = out.=20 > =20 > Substance Comments > Section 4: Requirement for IPv4 and IPv6. Why is IPv6 now a = requirement? Why not optional? Because the world has moved on, there are no more IPv4 addresses, many = networks are IPv6 only now, and we need a good reason to not require it = in the IETF. > Section 9.2 - The vetting process for a potential customer does not = lend itself to a person being able to simply sign up like this. The = customer will be required to have an account before being able to = communicate with the provider service. I therefore believe we should = remove the ability for the RUE device to communicate with the provider = without a userid/password. The process has to start some how that doesn=E2=80=99t involve a phone = call. Take a really simple example: I=E2=80=99m deaf, I have an account = with provider X, I want to establish another account with provider Y. = Can=E2=80=99t I do that with a website? Can I get help via a = videophone? The way it=E2=80=99s currently defined all that happens is = you get a URI for the website and another for a help desk. You don=E2=80=99= t get anything out of it. When all the vetting is finished, you end up = with a userid and password, and you manually enter that into the RUE. = What am I missing? > Section 9.2 - In the section for the payload, it is missing the = provider-domain in the text section but it is included in the example. = I expect this is simply an oversight. It=E2=80=99s the domain in the provider-list. I can make that clearer > =20 > Typo Comments Thanks for these, I=E2=80=99ll fix them > Section 5.5, Remove redundant "that" from first sentence "that that" > Section 9, 2nd sentence reads awkwardly. Perhaps change to "One = provides a directory of providers so that a user interface allows easy = provider selection ..." > Section 9.1, get rid of extra "a" in the section "...a country code = suitable for display, with a corresponding "a" URI ... > Section 9.2, get rid of extra "the" in the first sentence "...provider = configuration "the" using a simple..." > Section 9.4 - Get rid of the redundant word "Sections" in the first = sentence "The interfaces in "Sections" Section 9.1 ..." > =20 > =20 > Thanks. > =20 > 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 > From: Rum > On = Behalf Of Brian Rosen > Sent: Friday, February 5, 2021 3:27 PM > To: rum@ietf.org > Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt > =20 > [EXTERNAL] I have posted a -04 revision. This should handle all = comments received so far, please let me know if I forgot something. > =20 > This version reworks the provider list and configuration sections = along the lines we have been discussing. > =20 > I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. > =20 > One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 > =20 > For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. > =20 > Brian > =20 >=20 >=20 > Begin forwarded message: > =20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-rum-rue-04.txt > Date: February 5, 2021 at 5:17:15 PM EST > To: > > Cc: rum@ietf.org > Reply-To: internet-drafts@ietf.org , = rum@ietf.org > =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-04.txt > Pages : 33 > Date : 2021-02-05 >=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-04.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=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 --Apple-Mail=_181BFD04-8F7D-4C43-AD9B-73FFE2B857EC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8



On Feb 9, 2021, at 11:27 AM, Eugene Christensen <echristensen@sorenson.com> wrote:

Hi Brian, 
 
I have a few thoughts on = this and a few typos that I=E2=80=99ll point out. 
 
Substance = Comments
  • Section 4: Requirement for IPv4 and = IPv6.  Why is IPv6 now a requirement?  Why not = optional?
Because the world has moved = on, there are no more IPv4 addresses, many networks are IPv6 only now, = and we need a good reason to not require it in the IETF.
  • Section 9.2 - The = vetting process for a potential customer does not lend itself to a = person being able to simply sign up like this.  The customer will = be required to have an account before being able to communicate with the = provider service.  I therefore believe we should remove the ability = for the RUE device to communicate with the provider without a = userid/password.
The process has to = start some how that doesn=E2=80=99t involve a phone call.  Take a = really simple example: I=E2=80=99m deaf, I have an account with provider = X, I want to establish another account with provider Y.  Can=E2=80=99= t I do that with a website?  Can I get help via a videophone? =  The way it=E2=80=99s currently defined all that happens is you get = a URI for the website and another for a help desk.  You don=E2=80=99t= get anything out of it.  When all the vetting is finished, you end = up with a userid and password, and you manually enter that into the RUE. =  What am I missing?

  • Section 9.2 - In the section for the = payload, it is missing the provider-domain in the text section but it is = included in the example.  I expect this is simply an = oversight.
It=E2=80=99s the domain in = the provider-list.  I can make that clearer
 
Typo = Comments
Thanks for these, I=E2=80=99ll = fix them
  • Section 5.5,  Remove = redundant "that" from first sentence "that that"
  • Section 9,  2nd = sentence reads awkwardly.  Perhaps change to "One provides a = directory of providers so that a user interface allows easy provider = selection ..."
  • Section 9.1, get rid of extra "a" in the section "...a = country code suitable for display, with a corresponding "a" URI ...
  • Section 9.2, get rid = of extra "the" in the first sentence "...provider configuration "the" = using a simple..."
  • Section 9.4 - Get rid of the redundant word "Sections" in = the first sentence "The interfaces in "Sections" Section 9.1 ..."
 
 
Thanks.
 
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.
 
From: Rum= <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Friday, February 5, 2021 = 3:27 PM
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt
 
[EXTERNAL] I have posted a -04 revision. =  This should handle all comments received so far, please let me = know if I forgot something.
 
This = version reworks the provider list and configuration sections along the = lines we have been discussing.
 
I do = not have a way to download a username/password from a new signup. =  I=E2=80=99m having trouble thinking about a secure way to do that. =  If anyone has an idea, I=E2=80=99m very willing to write text for = it.  I=E2=80=99ve considered things like javascript that stashes it = in a file or somewhere else, having some web page function that triggers = a local display of an entry form for username and password, and a couple = of other things.
 
One note on the configuration mechanism = - because the only thing the local RUE device needs to keep is the = username password against a provider ID of some kind, there isn=E2=80=99t = any need to standardize how that works, and so it=E2=80=99s completely = absent in the text.  
 
For = now, I=E2=80=99ve removed the step by step diagram that showed how the = config mechanism is used.  I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with.  I can bring back the diagram if that is = needed.
 
Brian
 


Begin forwarded message:
 
From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.txt
Date: February 5, = 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org
 

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
        &= nbsp;       Filename =        : draft-ietf-rum-rue-04.txt
        &= nbsp;       Pages =           : 33
        &= nbsp;       Date =            : = 2021-02-05

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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04


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

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


_______________________________________________
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

= --Apple-Mail=_181BFD04-8F7D-4C43-AD9B-73FFE2B857EC-- From nobody Tue Feb 9 12:03: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 7C01C3A11DD for ; Tue, 9 Feb 2021 12:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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] 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 TBE4EHRsEslO for ; Tue, 9 Feb 2021 12:02:58 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2069.outbound.protection.outlook.com [40.107.243.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D2223A11ED for ; Tue, 9 Feb 2021 12:02:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OOhMUo9H65HuYqSmwOTuUCvgl6UIXu3kCMaex44AWt6syOFA0OR9VmTQs3q2AdDwJ82gYusiUltvz+z3mGP35Bj3bU3YxO3h/TdZflLk1dKaNPy0SnffXax1RFqzHMhLz23PdTnJg83Y0TkXWJq55cN2Al4FFXLqsncJ9m2OFzq76wDDQyBjfehUoDgUiDmMWp1aqvV6XAxyWzr+nCQFEHCWofITOF9eYg4ysbejbGvAIXAhYUMYilT30wq4n0VEF92rwSV/hPqnOwWyLlaxhYEREpn0lhjS+1C16KABQ7WzK7huvJE/egxCS9+qsVUuigXdyRWzSBSGEAJTAtEEqQ== 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=/Updb7Z0cfT2c71KiQERET6Pc/gOi5Gl0qDAl9HM2z4=; b=gAyjXxmOqWkvSPEJmBzcMek5UWQJUcuTt2CfkKfjrWwmn2zvc/creRp6+1MxGXeL9iyiKQ9rv8CZoAHlU2ewEeyO6g3ry7vwRr1xKgrky1OSAQeWlmA1JKzOUY331neV5m+hcyxxeyk+PQpgsydmoXFzolZi4hdV4b0iXwI/tPYGR1lGMN5GE25XEVOwT0a6NmnvnnLQOqwnRk7p/eBuk0wHpiEBfCFjLaZSIgJGO6/UcFPCLkuEydn3iXUSbQALEIrKXrECwrmRcqRoI+BN03gqWStc6I1QsvXcNxKJh0uep3vQDrHCKz9MftRc1gFHXrGpbMMtfvLNzDdTXwIuRw== 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=/Updb7Z0cfT2c71KiQERET6Pc/gOi5Gl0qDAl9HM2z4=; b=eAKQQSGVCmo7omTUepE+UdLxfn8PcazQ8BpPxIvEkQ/QuLejAv6r6rJ1DZuPHrIOIwzu3xpI5Fm86jB2kLHAZ7Y5hLcui9YmNaIVSN/3UVtAImLyHfz3bW6lHzONChyIPuVd2nDoQfhJV2lW7gYNJ9zm5Np30lklJiV9mPJBuAE= Received: from BLAPR03CA0167.namprd03.prod.outlook.com (2603:10b6:208:32c::22) by CY4PR1201MB2550.namprd12.prod.outlook.com (2603:10b6:903:ce::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3825.23; Tue, 9 Feb 2021 20:02:48 +0000 Received: from BL2NAM02FT060.eop-nam02.prod.protection.outlook.com (2603:10b6:208:32c:cafe::f1) by BLAPR03CA0167.outlook.office365.com (2603:10b6:208:32c::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3846.26 via Frontend Transport; Tue, 9 Feb 2021 20:02:48 +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 BL2NAM02FT060.mail.protection.outlook.com (10.152.76.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.12 via Frontend Transport; Tue, 9 Feb 2021 20:02:47 +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 119K2kWk018138 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 9 Feb 2021 15:02:46 -0500 To: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Tue, 9 Feb 2021 15:02:46 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.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: 8278396d-132b-4edc-971d-08d8cd35ac3e X-MS-TrafficTypeDiagnostic: CY4PR1201MB2550: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LUhnocAeltdgiQVljpmiMTn9ljOIWMfEKmNFSAP2TFlEflpTFakvmgf/CtGD+vZJ8c6G5lFZF6t7eF4JhfzbYuUQQd1TisXnymHVitFuF30jSeNh35bmG4KmeMbWFLP6t7NbiqAvaiC45Myp1QyXIrmRdNwb8q6wwF9JTAGKBMq45TUQOflhU3nAlWNiJ/gAkVglNzLyil+2tdYhDmSAqfL4bVP6y/OSZXu+khlm1CtSYl1QF6VNXDvR3U5DRjTqCDJ4qZ0m2nqhNbt2ZofyLLfVL14qMGoMldtGxsIjY3anr/8Bz40FjRFaE4r5TWr4HyTPepmOAyJJVpQJN9kxrL2VdHdo10LDo1P3OJYLp59PZuGbKMdkPryBSWEFewj+DHf/xGa45D39yo5O7WpLNx1wXsG15EeQ3mhiv2W4ZaD4dCi5sKZw5gWiCair9HEJ8+odZ5SVcxo7BNNnV9/ElPfzR7RF16dcWgAXzxB3sFc7odqX+hCYSTOAfDV8vimVQeU2z2EeMmqqwDX9xgPqambVD02w5dtwk1wQK2L7+AtbTMIsn9f2tuZEybxLuyPbPvOPWHJLjyj9AS6mdDrSBtCCbTwrOdwfI3UPlp+HY3K34v7L3pbqAigzN/s3v6Dvm+I+RD4LljGqPxK0utb+NcKCHb1ZjOGY3hdR4glBMwSCj2xuUtOcFGZXH5naWKUT 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)(396003)(376002)(36840700001)(46966006)(2616005)(956004)(336012)(478600001)(8936002)(31696002)(82310400003)(6916009)(7596003)(5660300002)(186003)(2906002)(47076005)(36906005)(70206006)(26005)(31686004)(75432002)(4744005)(8676002)(316002)(70586007)(86362001)(786003)(82740400003)(36860700001)(53546011)(356005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2021 20:02:47.8349 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 8278396d-132b-4edc-971d-08d8cd35ac3e 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: BL2NAM02FT060.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1201MB2550 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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: Tue, 09 Feb 2021 20:03:00 -0000 Hi Eugene, On 2/9/21 11:27 AM, Eugene Christensen wrote: > Hi Brian, > > I have a few thoughts on this and a few typos that I’ll point out. > > *Substance Comments* > > * Section 4: Requirement for IPv4 and IPv6.  Why is IPv6 now a > requirement?  Why not optional? Brian and I discussed this and I was the one proposing this. This is a requirement on the RUE, not the provider. It puts the decision of which to use on the provider side. It provides a way forward to a future world where not everybody has v4. Since this is a spec for devices that don't yet exist it makes sense to me to do it. Thanks, Paul From nobody Fri Feb 12 16:36:07 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 E968D3A120A; Fri, 12 Feb 2021 16:33:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: rum@ietf.org, superuser@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.25.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161317640593.31337.9437268351600108968@ietfa.amsl.com> Date: Fri, 12 Feb 2021 16:33:25 -0800 Archived-At: Subject: [Rum] rum - Requested session has been scheduled for IETF 110 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: Sat, 13 Feb 2021 00:33:35 -0000 Dear Paul Kyzivat, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rum Session 1 (1:00 requested) Wednesday, 10 March 2021, Session II 1530-1630 Room Name: Room 3 size: 503 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/110/sessions/rum.ics Request Information: --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Paul Kyzivat Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: avtcore dispatch sipcore ecrit mmusic Technology Overlap: quic People who must be present: Brian Rosen Murray Kucherawy Paul Kyzivat Resources Requested: Special Requests: Can't do Thursday after 1400 UTC. --------------------------------------------------------- From nobody Mon Feb 22 10:41: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 24C473A1E99 for ; Mon, 22 Feb 2021 10:41:57 -0800 (PST) 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 SMhYHBF0pNj5 for ; Mon, 22 Feb 2021 10:41:55 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 6F8E33A1EDC for ; Mon, 22 Feb 2021 10:41:55 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id 81so13649500qkf.4 for ; Mon, 22 Feb 2021 10:41:55 -0800 (PST) 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=snl32oWb0gRS1WCdwqnEEdSJlzQ3+T6IqNpy0kLC1Zc=; b=ihrCQ0qnItBFw5F2H/66jL7Y6NXPJVTir3x1X/TuF+xyjrX5Vvbn5hvQLnzBwLZ/Lk 5kYKZGELMPFkqBhFxcUT8HQbam7V9tlsbgGDk9nb1xzK/f2t8yTNlaZ6Ivl0/eQIt1rd G9IkhrmZpQlrGYq5jcGL8IPfH9Vbi31G4ECEpZqgjPqvX5g65STmlylBuw7eP5RuKF9f Zr1bBCnj9yRaQhQNIQFrCBPeQUzXN0iI48NCZSJdSA3bnvqV6LjEmQ9zYm/46gYtAf2I JKqrlzR1HvDf5CX/MCqykObKP6f/+JHTlYtUcxs8kgXxuRkl9TnMmW7L5OgNsslPjXmL fRGA== 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=snl32oWb0gRS1WCdwqnEEdSJlzQ3+T6IqNpy0kLC1Zc=; b=GCpZPt+5LcLPk4kWH8BbJTeYudd3ZQfKT7tISsqBrF2YVl11Y/CLmX0bdF7urkKDGo KeNT4GuxU/p4TSXsx4MFVACTaA3t+o4w7wWRGZF0hLdLexsAfdsa6vzTCC8WEQP0zqab ZNEwRdowAP6r0m4ikCetSxLCqmoRTwK/elMduNAbBttwDWC/DP90d71aKUtujo3pFNKg 53kFxdvDXhAYiB3eWR1L8gl5FiYFB4EJyZY7k4UQt1Bdt3jLOlY2BdQd2/Nk/bNZbC+f lR8pmW5yLgF9MnW/x05gwH0drhRY16yKYhZbN4zJTUo7Q5szjJGhqm2UfVusdRob1Oh5 NKRQ== X-Gm-Message-State: AOAM530wVwno0g5Hg86COfBzK6lipZuSQ/3hoTy4/csZKwYrDrbzhmOC zk2+f2syzlJ8ep+7m3+NSHpXLA== X-Google-Smtp-Source: ABdhPJwoI22jw8gG7jMztuH8Bl33lnP36KW+CgCm1HWStUd8KgDtXipGcT+/8xoZUlC3qIKGUlAY2A== X-Received: by 2002:a05:620a:22e2:: with SMTP id p2mr21543235qki.308.1614019314512; Mon, 22 Feb 2021 10:41:54 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id p12sm11346337qtw.27.2021.02.22.10.41.53 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2021 10:41:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) From: Brian Rosen In-Reply-To: Date: Mon, 22 Feb 2021 13:41:52 -0500 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <11D07A23-B8B3-41CD-ADAD-D13C9E629A66@brianrosen.net> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> To: Paul Kyzivat X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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, 22 Feb 2021 18:41:57 -0000 Eugene Did these answers satisfy you? Do you have any open issues? Brian > On Feb 9, 2021, at 3:02 PM, Paul Kyzivat = wrote: >=20 > Hi Eugene, >=20 > On 2/9/21 11:27 AM, Eugene Christensen wrote: >> Hi Brian, >> I have a few thoughts on this and a few typos that I=E2=80=99ll point = out. >> *Substance Comments* >> * Section 4: Requirement for IPv4 and IPv6. Why is IPv6 now a >> requirement? Why not optional? >=20 > Brian and I discussed this and I was the one proposing this. This is a = requirement on the RUE, not the provider. It puts the decision of which = to use on the provider side. It provides a way forward to a future world = where not everybody has v4. Since this is a spec for devices that don't = yet exist it makes sense to me to do it. >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Feb 22 10:46: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 D67583A1F43 for ; Mon, 22 Feb 2021 10:46:21 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UG4Rw7RLiIhC for ; Mon, 22 Feb 2021 10:46:18 -0800 (PST) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 A25673A1EF7 for ; Mon, 22 Feb 2021 10:46:17 -0800 (PST) Received: by mail-qt1-x82c.google.com with SMTP id o21so10033373qtr.3 for ; Mon, 22 Feb 2021 10:46:17 -0800 (PST) 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=AP6MxVZqKrkFC/Sq2s4xidP48TI2BgFbVIq/LQ4IjIQ=; b=RC5YqXlZFqtr1AoBxlVaTOuVadzpZ1eMagvjCFuFdrmsnfPebPQuKaXKkLFpTtAP/Q b05OCCvuK8FrgyH+PMzDyg8laJEMGz9PgP8jbEIMBvJHsS/M33K4RwEjyClWbdtRQFKE SI8aJmq+7edfyi4DUSTXdla5YP8kC1q5vGAZ7bhuqfuOeEqjdgtYYvx4CuFee0ENF7X1 21i9nlkc5tvuaY8ZtZ3imiEnEhziExcpjIuv48BhRdFiltoeCSCf2vZNm2V/NIdifDb3 eJIcs/VjXHHU/CWeZgNI8v/ssSlZdtXnoknIk0ZSNggjI40P5wNZyxzozy3Wlr25oEeB d1Gw== 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=AP6MxVZqKrkFC/Sq2s4xidP48TI2BgFbVIq/LQ4IjIQ=; b=Q1Dm6J88UgPcBp5Tlrjw21rUL4yXTvFqViJLEvYMDDNUXhOJ3EW1imhi05xGDeFX0z E00NIlp5RMMur/2JyU1lTZN1frcL+97Wrh0JXpXHi+k0ZDpVVKyEj7p5ME1yBpHMpe2C 4MH5UQ9mhxT2343zmzUL6sP2OBsgaD8vQJT0Yd1qJ/0WHrSSLCdyutFi4M4XhEft701T 63D9A1w+z/vbzQo3M1RI9OdkZvCSdnVozSN72N6qb+mCNNeYy9ARTmJlwDbvJI+wX1F0 1+0FvHlbWKMFwwDY1mvSECUrbMYi2CegCAlkIK1mjPOJZxAZSanTsuQVt4beC24JPl2v FEWw== X-Gm-Message-State: AOAM531RQ0cfFKn00QYaoKIsZLbPPsq6vE9l29DGRvbegB3E75KmTHBy 4tEjvBwOi2c4cCWMajTkBj0jKQ== X-Google-Smtp-Source: ABdhPJwLqYSC1WW244w7ldBG+XGxT+Jn1WBeFzTTBCT2Gs52kldi8BxC9kTTrbSfBUzin7+wp3N7PQ== X-Received: by 2002:ac8:4b56:: with SMTP id e22mr16466476qts.311.1614019576590; Mon, 22 Feb 2021 10:46:16 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g2sm12992922qkd.124.2021.02.22.10.46.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2021 10:46:15 -0800 (PST) From: Brian Rosen Message-Id: <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_6C5BB962-B29D-4845-B314-669357949B5C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 22 Feb 2021 13:46:14 -0500 In-Reply-To: <1612881684171.60834@purple.us> Cc: Jim Malloy , "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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, 22 Feb 2021 18:46:28 -0000 --Apple-Mail=_6C5BB962-B29D-4845-B314-669357949B5C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Can we figure out how to converge on this?=20 There are: a) Actual user login credentials b) SIP credentials c) STUN/TURN credentials The current draft treats them all as identical. Is there a reason to = make them separate? My VoIP accounts have only one set. I=E2=80=99m = okay adding a separate SIP/STUN/TURN credential returned in the config = file, protected by the actual user login credentials, if that is really = useful. Maybe it could be optional, and if not provided, the = userid/password is used for everything. Brian > On Feb 9, 2021, at 9:41 AM, James Hamlin = wrote: >=20 > Jim >=20 > Yes credentials have to be cached, but not necessarily the user's = primary account credentials. The previous text allowed the configuration = service to send back separate credentials for SIP/STUN/TURN which could = have a shorter validity period than the main account credentials. This = offers greater flexibility in how a user's use of different RUE's can be = isolated. >=20 > I'll accept that the provider could offer a separate password for use = with each RUE type; we'd need to think about the logistical implications = of that. >=20 > Best Regards >=20 > James >=20 >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Jim Malloy > Sent: 09 February 2021 14:20 > To: Brian Rosen; James Hamlin > Cc: rum@ietf.org > Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > =E2=80=9CEvery VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use=E2=80=9D > =20 > James =E2=80=93=20 > =20 > Do existing ZVRS/Purple devices or mobile applications cache = authentication credentials? (Mobile applications may do so at the OS = level even if the application doesn=E2=80=99t explicitly do so.) If so, = is there a reason to treat the RUE Differently? > =20 > Thanks, >=20 > Jim Malloy > Principal Information System Engineer > The MITRE Corp. > 703 983 2835 > =20 > From: Rum On Behalf Of Brian Rosen > Sent: Tuesday, February 9, 2021 8:44 AM > To: Hamlin, James > Cc: rum@ietf.org > Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > I=E2=80=99ll delete the text in registration. =20 > Every VoIP phone I=E2=80=99ve ever seen or used caches username and = passwords for stand alone use. Every one. They do that for a simple = reason - so incoming calls work after a power loss. Most also are = effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? > =20 > The text currently uses the same credentials for the HTTP service and = the SIP service, but that=E2=80=99s it. I think that=E2=80=99s pretty = reasonable. > =20 > If you have another proposal for how we can maintain the config data = securely, please suggest one. > =20 > Brian >=20 >=20 > On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: > =20 > Brian > =20 > Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. > =20 > Best regards > =20 > James > =20 > =20 > =20 > =20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com = > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. > =20 > From: Rum > on = behalf of Brian Rosen > > Sent: 05 February 2021 22:26 > To: rum@ietf.org > Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt > =20 > I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. > =20 > This version reworks the provider list and configuration sections = along the lines we have been discussing. > =20 > I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. > =20 > One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 > =20 > For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. > =20 > Brian > =20 >=20 >=20 > Begin forwarded message: > =20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-rum-rue-04.txt > Date: February 5, 2021 at 5:17:15 PM EST > To: > > Cc: rum@ietf.org > Reply-To: internet-drafts@ietf.org , = rum@ietf.org > =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-04.txt > Pages : 33 > Date : 2021-02-05 >=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-04.html = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org = . >=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 > =20 --Apple-Mail=_6C5BB962-B29D-4845-B314-669357949B5C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Can = we figure out how to converge on this? 

There are:
a) = Actual user login credentials
b) SIP = credentials
c) STUN/TURN credentials

The current draft treats = them all as identical.  Is there a reason to make them separate? =  My VoIP accounts have only one set.  I=E2=80=99m okay adding = a separate SIP/STUN/TURN credential returned in the config file, = protected by the actual user login credentials, if that is really = useful.  Maybe it could be optional, and if not provided, the = userid/password is used for everything.

Brian

On Feb = 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote:

Jim

Yes credentials = have to be cached, but not necessarily the user's primary account = credentials. The previous text allowed the configuration service to send = back separate credentials for SIP/STUN/TURN which could have a shorter = validity period than the main account credentials. This offers greater = flexibility in how a user's use of = different RUE's can be isolated.

I'll accept that the provider could offer a separate password = for use with each RUE type; we'd need to think about the logistical = implications of that.

Best Regards

James


James Hamlin
Contractor
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: Jim Malloy <jmalloy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James = Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D = Action: draft-ietf-rum-rue-04.txt
 
=E2=80=9CEvery VoIP phone = I=E2=80=99ve ever seen or used caches username and passwords for stand = alone use=E2=80=9D

 

James =E2=80=93 

 

Do existing ZVRS/Purple = devices or mobile applications cache authentication credentials?  = (Mobile applications may do so at the OS level even if the application = doesn=E2=80=99t explicitly do so.)  If so, is there a reason to = treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information = System Engineer
The MITRE Corp.
703 983 = 2835

 

From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Tuesday, February 9, 2021 = 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt

 

I=E2=80=99ll delete the = text in registration.  
Every = VoIP phone I=E2=80=99ve ever seen or used caches username and passwords = for stand alone use.  Every one.  They do that for a simple = reason - so incoming calls work after a power loss.  Most also are = effectively set and forget, which is what you want in a phone.  Why = would we require manual entry for the RUE?

 

The text currently uses the same credentials for = the HTTP service and the SIP service, but that=E2=80=99s it.  I = think that=E2=80=99s pretty reasonable.

 

If you have another proposal for how we can = maintain the config data securely, please suggest one.

 

Brian


On = Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> = wrote:

 

Brian

 

Section 5.1 Registration says that "The credentials to be = used (username and password) MUST be supplied within the credentials = section of the configuration and identified by the realm the registrar = uses in a digest challenge. This username/password combination SHOULD = NOT be the same as that used for other purposes, such as retrieving the = RUE configuration or logging into the Provider's customer service = portal.". However, in the 04 draft, passwords are no longer = returned in the configuration. I think we need to avoid the RUM RUE = caching the user's main account password, which this draft seems to = require.

 

Best regards

 

James

 

 

 

 

James = Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on = behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 = February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt

 

I have posted a -04 revision.  This should handle all = comments received so far, please let me know if I forgot = something.

 

This version reworks the provider list and configuration = sections along the lines we have been discussing.

 

I do not have a way to download a username/password from a = new signup.  I=E2=80=99m having trouble thinking about a secure way = to do that.  If anyone has an idea, I=E2=80=99m very willing to = write text for it.  I=E2=80=99ve considered things like javascript = that stashes it in a file or somewhere else, having some web page = function that triggers a local display of an entry form for username and = password, and a couple of other things.

 

One note on the configuration = mechanism - because the only thing the local RUE device needs to keep is = the username password against a provider ID of some kind, there isn=E2=80=99= t any need to standardize how that works, and so it=E2=80=99s completely = absent in the text.  

 

For now, I=E2=80=99ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is = dead simple and needs no explanation: it=E2=80=99s a straightforward = REST/JSON web service using username/password authentication for = providers the user has accounts with.  I can bring back the diagram = if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM = EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

 


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04

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

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


_______________________________________________
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

 

 

 

= --Apple-Mail=_6C5BB962-B29D-4845-B314-669357949B5C-- From nobody Mon Feb 22 10:50: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 05E753A1EFE for ; Mon, 22 Feb 2021 10:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ftB2JsiQxR5Q for ; Mon, 22 Feb 2021 10:50:18 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 53ED73A1EFD for ; Mon, 22 Feb 2021 10:50:18 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id z128so9143126qkc.12 for ; Mon, 22 Feb 2021 10:50:18 -0800 (PST) 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=yX5VExiX478siL8ojO1xc4BLDccK54Yt551tcbAvFMc=; b=LDqwFnnZDLQnvRujPowwDyHVYuv6pVK5dFPoBSJWnXFnrH2rh414x+bfdU2A3wxvDV 5TKkLRrvpmONekJjq9VIs4SYXSNXEmtTr+Ojq94NX0TIItyVVz3Hd1LsDHBaEQluQWt+ orsfPdVNDx1RzzJqwm/g6P/joDdpFXY7RrKE7PToBvVGBXTIL5iPmwULfEVlrc5yx/ji 6OvVGk5fDWNuvUkvCvQ3hGN/HV8B0IFQ23mzcNLs9A3v8NgK1VUipwKZBa55aWqc6Ip2 MI1+z5l25ux4jYRlWWtR9USBpmI4e+6h1ZeDyrhohCMFtEe07bJ4hPiEqxUWrP9jP3us 6yqw== 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=yX5VExiX478siL8ojO1xc4BLDccK54Yt551tcbAvFMc=; b=HGYMCcUvhv3ayLEL9+cbmFql8bXcmpil1iazCgknp0HV0HMUgz+Gasm+RjhMTcU2tr 30mTm6m1wq3erm6AJXEUNsv1AX2gxzp+Z+L7MJvaT0aNTMxuuAu6NI7eEZqWY+hiXVqk gq4vTvJMfbRyZT+d2+tpXTSsUwvs4kGPo9p4xMwf1wDHLrUkVSXsZzpoCTxPkyy6Iw/i yEyaXaKSG9v8vTiBnZMCyT//KxpG3Vt/aUZufM14e0e54yR+bq1UfeAZGIrnrezPLGNv r9zidFw+VThw5H0hKbIE9SKl6R9k/g75lDJHOdWLt2itefYZkTTYO9QIyQSN0Bs9ro9n X8Sw== X-Gm-Message-State: AOAM532H4qXeCZxCKsC5Cj3OFN95kK2tTY4ZuYf2J/g92A+UY7cfQWiP InU5LH/pdvXk/uzUoIhQ1nN2mg== X-Google-Smtp-Source: ABdhPJy/koyKFuxJGSvdlM8kGgPZakAPjyDsbhfKlzzMDGAn6BgQk37SLa9lK0MZ+R+z3RMb700JsA== X-Received: by 2002:a37:d247:: with SMTP id f68mr22982104qkj.187.1614019817476; Mon, 22 Feb 2021 10:50:17 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id u126sm12703407qkc.107.2021.02.22.10.50.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2021 10:50:16 -0800 (PST) From: Brian Rosen Message-Id: <87FC3B9D-52CC-496E-B0EE-2358C4FB6E13@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_A0561B70-909D-4A4E-853E-5E4000B62549" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 22 Feb 2021 13:50:14 -0500 In-Reply-To: <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> Cc: "rum@ietf.org" To: Paul Kyzivat References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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, 22 Feb 2021 18:50:21 -0000 --Apple-Mail=_A0561B70-909D-4A4E-853E-5E4000B62549 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Paul, you wanted to talk about separate credentials for CardDAV. If = that=E2=80=99s useful, I can have them (optionally) returned in the = provider config file. It wasn=E2=80=99t clear to me how useful that is, = but it=E2=80=99s not hard, and if it=E2=80=99s optional, it=E2=80=99s = pretty easy to implement. Brian > On Feb 22, 2021, at 1:46 PM, Brian Rosen wrote: >=20 > Brian >=20 > Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >=20 > Best regards >=20 > James >=20 >=20 >=20 >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Rum on behalf of Brian Rosen = > Sent: 05 February 2021 22:26 > To: rum@ietf.org > Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt > =20 > I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >=20 > This version reworks the provider list and configuration sections = along the lines we have been discussing. >=20 > I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. >=20 > One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >=20 > For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >=20 > Brian >=20 >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-ietf-rum-rue-04.txt >> Date: February 5, 2021 at 5:17:15 PM EST >> To: > >> Cc: rum@ietf.org >> Reply-To: internet-drafts@ietf.org , = rum@ietf.org >>=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-04.txt >> Pages : 33 >> Date : 2021-02-05 >>=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-04.html = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=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 --Apple-Mail=_A0561B70-909D-4A4E-853E-5E4000B62549 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Paul,= you wanted to talk about separate credentials for CardDAV.  If = that=E2=80=99s useful, I can have them (optionally) returned in the = provider config file.  It wasn=E2=80=99t clear to me how useful = that is, but it=E2=80=99s not hard, and if it=E2=80=99s optional, it=E2=80= =99s pretty easy to implement.

Brian

On Feb 22, 2021, at 1:46 PM, = Brian Rosen <br@brianrosen.net> wrote:

Brian

Section 5.1 = Registration says that "The credentials to be used (username and = password) MUST be supplied within the credentials section of the = configuration and identified by the realm the registrar uses in a digest = challenge. This username/password combination SHOULD NOT be the same as = that used for other purposes, such as retrieving the RUE configuration = or logging into the Provider's customer service portal.". However, = in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require.

Best regards

James




James Hamlin
Contractor
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: Rum= <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt
 
I have posted a -04 revision.  This should handle all = comments received so far, please let me know if I forgot something.

This version reworks the = provider list and configuration sections along the lines we have been = discussing.

I = do not have a way to download a username/password from a new signup. =  I=E2=80=99m having trouble thinking about a secure way to do that. =  If anyone has an idea, I=E2=80=99m very willing to write text for = it.  I=E2=80=99ve considered things like javascript that stashes it = in a file or somewhere else, having some web page function that triggers = a local display of an entry form for username and password, and a couple = of other things.

One note on the configuration mechanism - because the only = thing the local RUE device needs to keep is the username password = against a provider ID of some kind, there isn=E2=80=99t any need to = standardize how that works, and so it=E2=80=99s completely absent in the = text.  

For= now, I=E2=80=99ve removed the step by step diagram that showed how the = config mechanism is used.  I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with.  I can bring back the diagram if that is = needed.

Brian


Begin = forwarded message:

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04

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

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


_______________________________________________
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



= --Apple-Mail=_A0561B70-909D-4A4E-853E-5E4000B62549-- From nobody Mon Feb 22 14:24: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 79F9C3A210A for ; Mon, 22 Feb 2021 14:24:40 -0800 (PST) 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_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 z6hpEKWnZr5Y for ; Mon, 22 Feb 2021 14:24:38 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2062.outbound.protection.outlook.com [40.107.93.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3663A2106 for ; Mon, 22 Feb 2021 14:24:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VccdLC3BLr0aBKHoqVjTMROWorj9tCXyvsaYZQahmPePmLMQ/Y8SkfUAicvwN9ulEZgdzU4wK42xy/L7LVXona552NQbYiAr2dao3qQq5wset5OC5nNfJllyYit0/KPzbMwreoabs0VNW0xbY26R81YT3DL6WsRV96Z/XihlffCFD7Sw3240T0ZfSIYnecN8nuc0zt4PaeCT1bii2cep0A0LGcKBPrF/aKLBxwDNXQfJMDuWEW7c/8EqxhUEKAdSyEnKjubZBn6/OP9XvBgOhubyeosR6wEK4eh4jQZQ2bkuwuxa8qfB5CW96jgWG3PGZRKckht4y9iUeaWXL5nAPg== 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=WzLr4F89jTOAVHANAYlwhnSpEKuDI5EcWRC6OSXZRkw=; b=n9X5X+6L613wRhB5Qn5jaABzb6Z/2cq2ZL1s5+7FFZqEv5/eVTM2+TkyowO6M2kKknnn9GfHd6vweIZ5h/CoORUuMY4LmhbGmxHHRmx/eJalX0ZF0yuUUm7sNMHIesWZ/UnvaQBY2hsgVVG06bT0CKtN+RK5JhGP2X/qTvop+wIry4k9mn3QSK6EyZrGFL7CPeeMrpoU+40hBpo51Zqzk9i1Yc6ObwcNaSzcSo9SXxDhqYPKelc4j/exGUf93YlI/r7FKwgeBf/Uz+aGANA3wCEbwwMRFVFS7ndEL6cl2I/i0I/EoBMcMBAm4hOG2w9qjxfcSSrUEC6D/ix5s5QPHw== 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=WzLr4F89jTOAVHANAYlwhnSpEKuDI5EcWRC6OSXZRkw=; b=YrNVs+V2bEErjUEc3qp67bCtTPRnMrp2wUB5q/wCYVxTOfmyLdqaOkGworZx5b9yxRIdzMPVdsvGihPBgztIcrdRft/dVLElB+qGYVX81h2rXBjkXU9OEtfPu1Nds14BWWA8u4kGz/Ozg7htdp4QsAPkALgLjGZKN9fwuKaOfsI= Received: from DM5PR11CA0021.namprd11.prod.outlook.com (2603:10b6:3:115::31) by MWHPR1201MB0063.namprd12.prod.outlook.com (2603:10b6:301:4d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.33; Mon, 22 Feb 2021 22:24:35 +0000 Received: from CY1NAM02FT019.eop-nam02.prod.protection.outlook.com (2603:10b6:3:115:cafe::ff) by DM5PR11CA0021.outlook.office365.com (2603:10b6:3:115::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Mon, 22 Feb 2021 22:24:34 +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 CY1NAM02FT019.mail.protection.outlook.com (10.152.75.177) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27 via Frontend Transport; Mon, 22 Feb 2021 22:24:34 +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 11MMOWM3010172 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Feb 2021 17:24:32 -0500 To: Brian Rosen Cc: "rum@ietf.org" References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <87FC3B9D-52CC-496E-B0EE-2358C4FB6E13@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Mon, 22 Feb 2021 17:24:32 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 MIME-Version: 1.0 In-Reply-To: <87FC3B9D-52CC-496E-B0EE-2358C4FB6E13@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: 5870c91d-36d0-4f3f-63e9-08d8d780a1ec X-MS-TrafficTypeDiagnostic: MWHPR1201MB0063: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KMRvFvoJyvXtlbMLj0aPEnSY8Y1Ro/uWrWwe9Oe8squ5Qc1iI1wCgxCFNEAshneY7M0D7zDHP8h47yPhceDM2ELclQPGGe6AmeWScYpdaFEaNWgN+QIt0AdqHJK5ZdmMknYjR8LBs6VyzqPCPnSX998y2kayjp9cWKE41pw03c4SJYur03VIqnjxQaHlHsWaDXvOB0f+Nz757Mgyf88H9jRPWuR4DkUmqxzb9KpQDZDOHoCjRfBckw4hgUrhw3sUGZzDhhVAJoMEsAvOooOWaK3QQTWbj9x+xvDmQcxWBS79De7sCdYeX/gwZVmehp8/JRAaOQ01mqNzBNZGtFi4nOTlr96s3sp+bnuyj539Xm+NHH1Se7JqkY5ylvge4kkeWaIkZZymSYXbdksoPG+g63Xsq5FtM5xtyJTC/FV+bp229gEgXKpBfGOUFtudz/QwKb9CvhNSxDVytj51XBmHSe6QAcRn98HLICRqYtwQW55B1Nz2apwNMkdy7hkteFVqqqv5TVy78JsNfZUJw1u/Flr1oXDOJP0cWGGF0iUQEHZLm0UNtOuEak+zYNBdvMwIm6StvGsTc/RlXKx/If9cgDopPVIUIM8E1VsqcZRtqh8yXmJE4u19plMyNRs7nbcW0ALPF1XJgcQSqz3aQHkkCF/bl8agbWUpLJOBpWu9cvv1H1F/VfZ24MBUGlg32wstOWs9hcbN2PJ7/3VDObGfPRHqXDeBF3cPjuLaxftgccveCx0kn0mGeJUCWUSI59o4ZJluBDXweC2WXdWHMjHmrQ== 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)(136003)(376002)(46966006)(36840700001)(47076005)(86362001)(31696002)(36860700001)(8936002)(4326008)(6916009)(75432002)(8676002)(31686004)(53546011)(2906002)(356005)(18074004)(316002)(82740400003)(2616005)(478600001)(956004)(966005)(70586007)(70206006)(83380400001)(786003)(7596003)(82310400003)(186003)(66574015)(5660300002)(26005)(336012)(36906005)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2021 22:24:34.3897 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 5870c91d-36d0-4f3f-63e9-08d8d780a1ec 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: CY1NAM02FT019.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0063 Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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, 22 Feb 2021 22:24:40 -0000 On 2/22/21 1:50 PM, Brian Rosen wrote: > Paul, you wanted to talk about separate credentials for CardDAV.  If > that’s useful, I can have them (optionally) returned in the provider > config file.  It wasn’t clear to me how useful that is, but it’s not > hard, and if it’s optional, it’s pretty easy to implement. I think there are two distinct cases here: 1) carddav server administered by the provider. separately configured per provider, as part of the configuration. In this case I can see no reason why it would need to be separate credentials from sip, etc. 2) an independent carddav server (e.g., Google) associated with the RUE, and used across providers. The credentials for this would need to be distinct. Also, probably totally out of scope for this spec. But if I were implementing a RUE I would want to include this. Thanks, Paul > Brian > >> On Feb 22, 2021, at 1:46 PM, Brian Rosen > > wrote: >> >> Brian >> >> Section 5.1 Registration says that "The credentials to be used >> (username and password) MUST be supplied within the credentials >> section of the configuration and identified by the realm the registrar >> uses in a digest challenge. This username/password combination SHOULD >> NOT be the same as that used for other purposes, such as retrieving >> the RUE configuration or logging into the Provider's customer service >> portal.". However, in the 04 draft, passwords are no longer returned >> in the configuration. I think we need to avoid the RUM RUE caching the >> user's main account password, which this draft seems to require. >> >> Best regards >> >> James >> >> >> >> >> James Hamlin >> Contractor >> 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:*Rum > on >> behalf of Brian Rosen > >> *Sent:*05 February 2021 22:26 >> *To:*rum@ietf.org >> *Subject:*[Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >> I have posted a -04 revision.  This should handle all comments >> received so far, please let me know if I forgot something. >> >> This version reworks the provider list and configuration sections >> along the lines we have been discussing. >> >> I do not have a way to download a username/password from a new signup. >>  I’m having trouble thinking about a secure way to do that.  If anyone >> has an idea, I’m very willing to write text for it.  I’ve considered >> things like javascript that stashes it in a file or somewhere else, >> having some web page function that triggers a local display of an >> entry form for username and password, and a couple of other things. >> >> One note on the configuration mechanism - because the only thing the >> local RUE device needs to keep is the username password against a >> provider ID of some kind, there isn’t any need to standardize how that >> works, and so it’s completely absent in the text. >> >> For now, I’ve removed the step by step diagram that showed how the >> config mechanism is used.  I think what is there is dead simple and >> needs no explanation: it’s a straightforward REST/JSON web service >> using username/password authentication for providers the user has >> accounts with.  I can bring back the diagram if that is needed. >> >> Brian >> >> >>> Begin forwarded message: >>> >>> *From:*internet-drafts@ietf.org >>> *Subject:**I-D Action: draft-ietf-rum-rue-04.txt* >>> *Date:*February 5, 2021 at 5:17:15 PM EST >>> *To:*> >>> *Cc:*rum@ietf.org >>> *Reply-To:*internet-drafts@ietf.org >>> ,rum@ietf.org >>> >>> >>> 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-04.txt >>> Pages           : 33 >>> Date            : 2021-02-05 >>> >>> 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-04.html >>> >>> >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=draft-ietf-rum-rue-04 >>> >>> >>> >>> Please note that it may take a couple of minutes from the time of >>> submission >>> until the htmlized version and diff are available at tools.ietf.org >>> . >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> >>> _______________________________________________ >>> 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 >>> >>> orftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> >> >> > From nobody Tue Feb 23 06:58: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 B484E3A2C34 for ; Tue, 23 Feb 2021 06:58:28 -0800 (PST) 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 WUgAA9xuhHAR for ; Tue, 23 Feb 2021 06:58:25 -0800 (PST) Received: from outbound-ip1a.ess.barracuda.com (outbound-ip1a.ess.barracuda.com [209.222.82.168]) (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 044BA3A2C33 for ; Tue, 23 Feb 2021 06:58:24 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx-outbound47-146.us-east-2c.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 23 Feb 2021 14:58:20 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 Feb 2021 06:58:17 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Tue, 23 Feb 2021 06:58:17 -0800 From: James Hamlin To: Brian Rosen CC: Jim Malloy , "rum@ietf.org" Thread-Topic: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHXCUsDkPazAWu3o0uzeatovVjWl6pl1NTp Date: Tue, 23 Feb 2021 14:58:17 +0000 Message-ID: <1614092297144.68835@purple.us> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us>, <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> In-Reply-To: <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_161409229714468835purpleus_" MIME-Version: 1.0 X-BESS-ID: 1614092298-112178-5635-7476-1 X-BESS-VER: 2019.1_20210219.2020 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230405 [from cloudscan8-153.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 14:58:29 -0000 --_000_161409229714468835purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a refresh token which the= RUE would hold in place of the user login password would also be useful, a= s it would mean the login password would not have to be stored after the fi= rst configuration; refreshing an expired configuration would be done with t= he refresh token. James James Hamlin Contractor 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: 22 February 2021 18:46 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Can we figure out how to converge on this? There are: a) Actual user login credentials b) SIP credentials c) STUN/TURN credentials The current draft treats them all as identical. Is there a reason to make = them separate? My VoIP accounts have only one set. I=92m okay adding a se= parate SIP/STUN/TURN credential returned in the config file, protected by t= he actual user login credentials, if that is really useful. Maybe it could= be optional, and if not provided, the userid/password is used for everythi= ng. Brian On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: Jim Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater fle= xibility in how a user's use of different RUE's can be isolated. I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= . Best Regards James James Hamlin Contractor 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: Jim Malloy > Sent: 09 February 2021 14:20 To: Brian Rosen; James Hamlin Cc: rum@ietf.org Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt =93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94 James =96 Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials? (Mobile applications may do so at the OS level even if the a= pplication doesn=92t explicitly do so.) If so, is there a reason to treat = the RUE Differently? Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 From: Rum > On Behalf Of = Brian Rosen Sent: Tuesday, February 9, 2021 8:44 AM To: Hamlin, James > Cc: rum@ietf.org Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt I=92ll delete the text in registration. Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use. Every one. They do that for a simple reason - so incomi= ng calls work after a power loss. Most also are effectively set and forget= , which is what you want in a phone. Why would we require manual entry for= the RUE? The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it. I think that=92s pretty reasonable. If you have another proposal for how we can maintain the config data secure= ly, please suggest one. Brian On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: Brian Section 5.1 Registration says that "The credentials to be used (username an= d password) MUST be supplied within the credentials section of the configur= ation and identified by the realm the registrar uses in a digest challenge.= This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 draft, password= s are no longer returned in the configuration. I think we need to avoid the= RUM RUE caching the user's main account password, which this draft seems t= o require. Best regards James James Hamlin Contractor 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: Rum > on behalf of = Brian Rosen > Sent: 05 February 2021 22:26 To: rum@ietf.org Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt I have posted a -04 revision. This should handle all comments received so = far, please let me know if I forgot something. This version reworks the provider list and configuration sections along the= lines we have been discussing. I do not have a way to download a username/password from a new signup. I= =92m having trouble thinking about a secure way to do that. If anyone has = an idea, I=92m very willing to write text for it. I=92ve considered things= like javascript that stashes it in a file or somewhere else, having some w= eb page function that triggers a local display of an entry form for usernam= e and password, and a couple of other things. One note on the configuration mechanism - because the only thing the local = RUE device needs to keep is the username password against a provider ID of = some kind, there isn=92t any need to standardize how that works, and so it= =92s completely absent in the text. For now, I=92ve removed the step by step diagram that showed how the config= mechanism is used. I think what is there is dead simple and needs no expl= anation: it=92s a straightforward REST/JSON web service using username/pass= word authentication for providers the user has accounts with. I can bring = back the diagram if that is needed. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-rum-rue-04.txt Date: February 5, 2021 at 5:17:15 PM EST To: > Cc: rum@ietf.org Reply-To: internet-drafts@ietf.org, rum@ie= tf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_161409229714468835purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian


I think having the flexibility to optionally return separate SIP/STUN/TU= RN credentials could be useful. Optionally returning a = refresh token which the RUE would hold in pla= ce of the user login password would also be u= seful, as it would mean the login password wo= uld not have to be stored after the first configuration; refre= shing an expired configuration would be done with the refres= h token.


James



James Hamlin
Contractor
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 <= /div>
message.


From: Brian Rosen <br@= brianrosen.net>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP credentials
c) STUN/TURN credentials

The current draft treats them all as identical.  Is th= ere a reason to make them separate?  My VoIP accounts have only one se= t.  I=92m okay adding a separate SIP/STUN/TURN credential returned in = the config file, protected by the actual user login credentials, if that is really useful.  Maybe it could be optional, a= nd if not provided, the userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote= :

Jim

Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater flexibility in how a user's use=  of different RUE's can be isolated.

I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= .

Best Regards

James


James Hamlin
Contractor
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 orig= inal 
message.


From: Jim Malloy <jmalloy@mitre.org>
Sent: 0= 9 February 2021 14:20
To: Bri= an Rosen; James Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
=93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94

 

James =96 

 

Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials?  (Mobile applications may do so at the OS level even if = the application doesn=92t explicitly do so.)  If so, is there a reason= to treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

 

From: R= um <rum-bounces@ietf.= org> On Behalf Of Brian Rosen
Sent: T= uesday, February 9, 2021 8:44 AM
To: Ham= lin, James <james.h= amlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

 

I=92ll delete the text in registration.  
Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use.  Every one.  They do that for a simple reason -= so incoming calls work after a power loss.  Most also are effectively= set and forget, which is what you want in a phone.  Why would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it.  I think that=92s pretty reasonable.

 

If you have another proposal for how we can maintain the config data secure= ly, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <jame= s.hamlin@purple.us> wrote:

 

Brian

 

Section 5.1 Registration says tha= t "The credentials to be used (username and password) MUST be supplied= within the credentials section of the configuration and identified by the = realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we need to avoid the RUM RUE caching the user's mai= n account password, which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org<= /a>> on behalf of Brian Rosen <br@brianrosen.net>= ;
Sent: 0= 5 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

 

I have posted a -04 revision. &nb= sp;This should handle all comments received so far, please let me know if I= forgot something.<= /div>

 

This version reworks the provider= list and configuration sections along the lines we have been discussing.

 

I do not have a way to download a= username/password from a new signup.  I=92m having trouble thinking a= bout a secure way to do that.  If anyone has an idea, I=92m very willi= ng to write text for it.  I=92ve considered things like javascript that stashes it in a file or somewhere else, having some web pa= ge function that triggers a local display of an entry form for username and= password, and a couple of other things.

 

One note on the configuration mec= hanism - because the only thing the local RUE device needs to keep is the u= sername password against a provider ID of some kind, there isn=92t any need= to standardize how that works, and so it=92s completely absent in the text.  

 

For now, I=92ve removed the step = by step diagram that showed how the config mechanism is used.  I think= what is there is dead simple and needs no explanation: it=92s a straightfo= rward REST/JSON web service using username/password authentication for providers the user has accounts with.  I can bring= back the diagram if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.t= xt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ie= tf.org

 


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

       Title     &nb= sp;     : Interoperability Profile for Relay User = Equipment
       Author     &n= bsp;    : Brian Rosen
Filename        : draft-ietf-rum-rue-04.= txt
Pages           : 33
Date            : 20= 21-02-05

Abstract:
  Video Relay Service (VRS) is a term used to describe a method b= y
  which a hearing persons can communicate with deaf/Hard of Heari= ng
  user using an interpreter ("Communications Assistant"= ) connected via
  a videophone to the deaf/HoH user and an audio telephone call t= o the
  hearing user.  The CA interprets using sign language on th= e
  videophone link and voice on the telephone link.  Often th= e
  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 ser= vice,
  and subsequently to CAs and other deaf/HoH users.  It is d= esirable
  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 t= hat
  video calls direct between deaf/HoH users work.  This docu= ment
  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/<= /a>

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


_______________________________________________
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://ft= p.ietf.org/ietf/1shadow-sites.txt

 

 

 


--_000_161409229714468835purpleus_-- From nobody Tue Feb 23 07:09: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 AAA6F3A2C15 for ; Tue, 23 Feb 2021 07:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.886 X-Spam-Level: X-Spam-Status: No, score=-1.886 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 7FuM7zm4un6k for ; Tue, 23 Feb 2021 07:09:51 -0800 (PST) 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 930583A281C for ; Tue, 23 Feb 2021 07:09:05 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id 204so11449379qke.11 for ; Tue, 23 Feb 2021 07:09:05 -0800 (PST) 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=uczxJQ08oXP0r5L2Bb4fgbDpOHRXmCTUPqyPudt1QJE=; b=pn0xPDruVrSkDdb40CEagZ31vOOSwVEGYKa+jKzpGkx0DZfTmfhVIYQmYm1wfKvymM SkJRXZ784E4TwvJhgHwYkMt457KHLaDm3WIEC6FJZ8aZcz5z7V09Bu9vQ2jxYZ5Gpwmo IYny57Q/1I5X8RAZLd4STwazWnAh18YcaY8D133aMOnd5NpqDsFZWaucFuMtsJWSv6Ad 0EiVcCNx0m/9jdfA5o6Gz2Hb3qP4n2QExTnaPwn8uxCwp05jWc4k7DAclQ3zaPi5gk3d p5hwR15yHULKe22DrHpKs4GL5Zo/YLRlOahag+ox5A56pTiesPiy4Rc5qx/6LTz4FgmJ VWsA== 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=uczxJQ08oXP0r5L2Bb4fgbDpOHRXmCTUPqyPudt1QJE=; b=nuWcSNsEvIPVvN0Cxw88aqcnKhJlukUrG8mLXmrZ6PnozzFqBWIaqJcdF009PZ4oWw sfG7/iOrvUrGUu5A+2/E1u3CO1RslUSAg0fJrag6q1lcFjD03d5O47qSAkgNCjofXpAB 1H5funfCtNoRCMxoIvKRI8WygpbEodprlG/xnCYuJsLm1tGZSz1YYpkcnfHICOgvlsPy GWT52adJK7ZeArAAIxCuwO01eMymOZLRmC+Xe6Jq//sgQk2gaawst1OKwsoikCxAUkI+ VHezRK38fBlgY5zMtRQ3IWzbnQQ6lB+AT9e5+/p9VMNh/OZfmSlvuQYjNqki+AjqFDfi kzGQ== X-Gm-Message-State: AOAM533AjIJqs+hND3WiubjLo4EExYDq9SPzijEXmDgiVqTqXSCURs6s 7H0Ztbksw4YlGNsPy8Zplfrj7Q== X-Google-Smtp-Source: ABdhPJxZEXRooJdnpc87m/TvtDhxHqKZwz6SL5fsMTG0O9fmEIRaQTyfQ00smX5qbnmHre9iOUzzsQ== X-Received: by 2002:a05:620a:141:: with SMTP id e1mr23555704qkn.413.1614092944559; Tue, 23 Feb 2021 07:09:04 -0800 (PST) Received: from brians-mbp.lan ([24.154.119.158]) by smtp.gmail.com with ESMTPSA id t54sm13457880qte.8.2021.02.23.07.09.03 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 07:09:04 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C244BE24-A8AD-4AEA-A06C-48E5F29DAEC3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 23 Feb 2021 10:09:01 -0500 In-Reply-To: <1614092297144.68835@purple.us> Cc: Jim Malloy , "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 15:09:56 -0000 --Apple-Mail=_C244BE24-A8AD-4AEA-A06C-48E5F29DAEC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =20 Tell me a little more about how you think the refresh token would work. = Would it allow a device to have a power failure, come back, and accept = incoming calls? Brian > On Feb 23, 2021, at 9:58 AM, James Hamlin = wrote: >=20 > Brian >=20 > I think having the flexibility to optionally return separate = SIP/STUN/TURN credentials could be useful. Optionally returning a = refresh token which the RUE would hold in place of the user login = password would also be useful, as it would mean the login password would = not have to be stored after the first configuration; refreshing an = expired configuration would be done with the refresh token. >=20 > James >=20 >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Brian Rosen > Sent: 22 February 2021 18:46 > To: James Hamlin > Cc: Jim Malloy; rum@ietf.org > Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > Can we figure out how to converge on this?=20 >=20 > There are: > a) Actual user login credentials > b) SIP credentials > c) STUN/TURN credentials >=20 > The current draft treats them all as identical. Is there a reason to = make them separate? My VoIP accounts have only one set. I=E2=80=99m = okay adding a separate SIP/STUN/TURN credential returned in the config = file, protected by the actual user login credentials, if that is really = useful. Maybe it could be optional, and if not provided, the = userid/password is used for everything. >=20 > Brian >=20 >> On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: >>=20 >> Jim >>=20 >> Yes credentials have to be cached, but not necessarily the user's = primary account credentials. The previous text allowed the configuration = service to send back separate credentials for SIP/STUN/TURN which could = have a shorter validity period than the main account credentials. This = offers greater flexibility in how a user's use of different RUE's can be = isolated. >>=20 >> I'll accept that the provider could offer a separate password for use = with each RUE type; we'd need to think about the logistical implications = of that. >>=20 >> Best Regards >>=20 >> James >>=20 >>=20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com = >> The information contained in this e-mail message is intended=20 >> only for the personal and confidential use of the recipient(s)=20 >> named above. If you have received this communication in error,=20 >> please notify us immediately by e-mail, and delete the original=20 >> message. >>=20 >> =20 >> From: Jim Malloy > >> Sent: 09 February 2021 14:20 >> To: Brian Rosen; James Hamlin >> Cc: rum@ietf.org >> Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> =E2=80=9CEvery VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use=E2=80=9D >> =20 >> James =E2=80=93=20 >> =20 >> Do existing ZVRS/Purple devices or mobile applications cache = authentication credentials? (Mobile applications may do so at the OS = level even if the application doesn=E2=80=99t explicitly do so.) If so, = is there a reason to treat the RUE Differently? >> =20 >> Thanks, >>=20 >> Jim Malloy >> Principal Information System Engineer >> The MITRE Corp. >> 703 983 2835 >> =20 >> From: Rum > On = Behalf Of Brian Rosen >> Sent: Tuesday, February 9, 2021 8:44 AM >> To: Hamlin, James > >> Cc: rum@ietf.org >> Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> I=E2=80=99ll delete the text in registration. =20 >> Every VoIP phone I=E2=80=99ve ever seen or used caches username and = passwords for stand alone use. Every one. They do that for a simple = reason - so incoming calls work after a power loss. Most also are = effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? >> =20 >> The text currently uses the same credentials for the HTTP service and = the SIP service, but that=E2=80=99s it. I think that=E2=80=99s pretty = reasonable. >> =20 >> If you have another proposal for how we can maintain the config data = securely, please suggest one. >> =20 >> Brian >>=20 >>=20 >> On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: >> =20 >> Brian >> =20 >> Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >> =20 >> Best regards >> =20 >> James >> =20 >> =20 >> =20 >> =20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com = >> The information contained in this e-mail message is intended=20 >> only for the personal and confidential use of the recipient(s)=20 >> named above. If you have received this communication in error,=20 >> please notify us immediately by e-mail, and delete the original=20 >> message. >> =20 >> From: Rum > on = behalf of Brian Rosen > >> Sent: 05 February 2021 22:26 >> To: rum@ietf.org >> Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >> =20 >> This version reworks the provider list and configuration sections = along the lines we have been discussing. >> =20 >> I do not have a way to download a username/password from a new = signup. I=E2=80=99m having trouble thinking about a secure way to do = that. If anyone has an idea, I=E2=80=99m very willing to write text for = it. I=E2=80=99ve considered things like javascript that stashes it in a = file or somewhere else, having some web page function that triggers a = local display of an entry form for username and password, and a couple = of other things. >> =20 >> One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >> =20 >> For now, I=E2=80=99ve removed the step by step diagram that showed = how the config mechanism is used. I think what is there is dead simple = and needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >> =20 >> Brian >> =20 >>=20 >>=20 >> Begin forwarded message: >> =20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-ietf-rum-rue-04.txt >> Date: February 5, 2021 at 5:17:15 PM EST >> To: > >> Cc: rum@ietf.org >> Reply-To: internet-drafts@ietf.org , = rum@ietf.org >> =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-04.txt >> Pages : 33 >> Date : 2021-02-05 >>=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-04.html = >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org = . >>=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 >> =20 >=20 >=20 --Apple-Mail=_C244BE24-A8AD-4AEA-A06C-48E5F29DAEC3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay,= I=E2=80=99ll add optional SIP/STUN/TURN credentials.  

Tell me a little more = about how you think the refresh token would work.  Would it allow a = device to have a power failure, come back, and accept incoming = calls?

Brian



On Feb 23, 2021, at 9:58 AM, James Hamlin = <james.hamlin@purple.us> wrote:

Brian

I think having = the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a = refresh token which the RUE would hold in = place of the user = login password would also be useful, as it = would mean the login password would not = have to be stored after the = first configuration; refreshing an expired configuration = would be done with the refresh token.

James


James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP = credentials
c) STUN/TURN credentials

The current draft treats = them all as identical.  Is there a reason to make them separate? =  My VoIP accounts have only one set.  I=E2=80=99m okay adding = a separate SIP/STUN/TURN credential returned in the config file, = protected by the actual user login credentials, if that is really = useful.  Maybe it could be optional, and if not provided, the = userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote:

Jim

Yes = credentials have to be cached, but not necessarily the user's primary = account credentials. The previous text allowed the configuration service = to send back separate credentials for SIP/STUN/TURN which could have a = shorter validity period than the main account credentials. This offers = greater flexibility in how a user's use of = different RUE's can be isolated.

I'll accept that the provider could offer a = separate password for use with each RUE type; we'd need to think about = the logistical implications of that.

Best Regards

James


James = Hamlin
Contractor
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: Jim Malloy <jmalloy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James = Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D = Action: draft-ietf-rum-rue-04.txt
 
=E2=80=9CEvery VoIP phone = I=E2=80=99ve ever seen or used caches username and passwords for stand = alone use=E2=80=9D

 

James =E2=80=93 

 

Do existing ZVRS/Purple devices = or mobile applications cache authentication credentials?  (Mobile = applications may do so at the OS level even if the application doesn=E2=80= =99t explicitly do so.)  If so, is there a reason to treat the RUE = Differently?

 

Thanks,

Jim Malloy
Principal Information = System Engineer
The MITRE Corp.
703 983 = 2835

 

From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Tuesday, February 9, 2021 = 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt

 

I=E2=80=99ll delete the text in = registration.  
Every VoIP = phone I=E2=80=99ve ever seen or used caches username and passwords for = stand alone use.  Every one.  They do that for a simple reason = - so incoming calls work after a power loss.  Most also are = effectively set and forget, which is what you want in a phone.  Why = would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP = service and the SIP service, but that=E2=80=99s it.  I think = that=E2=80=99s pretty reasonable.

 

If you have another proposal for how we can maintain the = config data securely, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> = wrote:

 

Brian

 

Section 5.1 Registration says that = "The credentials to be used (username and password) MUST be supplied = within the credentials section of the configuration and identified by = the realm the registrar uses in a digest challenge. This = username/password combination SHOULD NOT be the same as that used for = other purposes, such as retrieving the RUE configuration or logging into = the Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we = need to avoid the RUM RUE caching the user's main account password, = which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 = February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt

 

I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.

 

This version reworks the provider list and configuration = sections along the lines we have been discussing.

 

I do not have a way to download a username/password from a new = signup.  I=E2=80=99m having trouble thinking about a secure way to = do that.  If anyone has an idea, I=E2=80=99m very willing to write = text for it.  I=E2=80=99ve considered things like javascript that = stashes it in a file or somewhere else, having some web page function = that triggers a local display of an entry form for username and = password, and a couple of other things.

 

One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =  

 

For now, I=E2=80=99ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is = dead simple and needs no explanation: it=E2=80=99s a straightforward = REST/JSON web service using username/password authentication for = providers the user has accounts with.  I can bring back the diagram = if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM = EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

 


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html=

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04<= br class=3D"">

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

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


_______________________________________________
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

 

 

 



= --Apple-Mail=_C244BE24-A8AD-4AEA-A06C-48E5F29DAEC3-- From nobody Tue Feb 23 09:11:15 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 B66AE3A0B54 for ; Tue, 23 Feb 2021 09:11:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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 3NKXkz5cMFB4 for ; Tue, 23 Feb 2021 09:11:10 -0800 (PST) Received: from outbound-ip25b.ess.barracuda.com (outbound-ip25b.ess.barracuda.com [209.222.82.222]) (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 BE4513A0B55 for ; Tue, 23 Feb 2021 09:11:09 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx-outbound16-193.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 23 Feb 2021 17:11:05 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 Feb 2021 09:06:54 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Tue, 23 Feb 2021 09:06:54 -0800 From: James Hamlin To: Brian Rosen CC: Jim Malloy , "rum@ietf.org" Thread-Topic: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHXCUsDkPazAWu3o0uzeatovVjWl6pl1NTpgACKVID//5fEjw== Date: Tue, 23 Feb 2021 17:06:54 +0000 Message-ID: <1614100014388.54843@purple.us> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_161410001438854843purpleus_" MIME-Version: 1.0 X-BESS-ID: 1614100261-104289-13073-17628-5 X-BESS-VER: 2019.1_20210219.2020 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230407 [from cloudscan17-108.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 17:11:14 -0000 --_000_161410001438854843purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable It's been a while since the refresh token was discussed; but if it is retur= ned in the configuration, the RUE should replace/overwrite it's stored copy= of the user password with the token. The token would then be valid where t= he user password was valid initially. Similarly, in further refreshes of th= e config, if a refresh token is returned, it replaces the previous token. T= hat wouldn't have any effect on the ability to recover from power failure. James James Hamlin Contractor 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: 23 February 2021 15:09 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Okay, I=92ll add optional SIP/STUN/TURN credentials. Tell me a little more about how you think the refresh token would work. Wo= uld it allow a device to have a power failure, come back, and accept incomi= ng calls? Brian On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: Brian I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a refresh token which the= RUE would hold in place of the user login password would also be useful, a= s it would mean the login password would not have to be stored after the fi= rst configuration; refreshing an expired configuration would be done with t= he refresh token. James James Hamlin Contractor 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: 22 February 2021 18:46 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Can we figure out how to converge on this? There are: a) Actual user login credentials b) SIP credentials c) STUN/TURN credentials The current draft treats them all as identical. Is there a reason to make = them separate? My VoIP accounts have only one set. I=92m okay adding a se= parate SIP/STUN/TURN credential returned in the config file, protected by t= he actual user login credentials, if that is really useful. Maybe it could= be optional, and if not provided, the userid/password is used for everythi= ng. Brian On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: Jim Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater fle= xibility in how a user's use of different RUE's can be isolated. I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= . Best Regards James James Hamlin Contractor 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: Jim Malloy > Sent: 09 February 2021 14:20 To: Brian Rosen; James Hamlin Cc: rum@ietf.org Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt =93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94 James =96 Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials? (Mobile applications may do so at the OS level even if the a= pplication doesn=92t explicitly do so.) If so, is there a reason to treat = the RUE Differently? Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 From: Rum > On Behalf Of = Brian Rosen Sent: Tuesday, February 9, 2021 8:44 AM To: Hamlin, James > Cc: rum@ietf.org Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt I=92ll delete the text in registration. Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use. Every one. They do that for a simple reason - so incomi= ng calls work after a power loss. Most also are effectively set and forget= , which is what you want in a phone. Why would we require manual entry for= the RUE? The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it. I think that=92s pretty reasonable. If you have another proposal for how we can maintain the config data secure= ly, please suggest one. Brian On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: Brian Section 5.1 Registration says that "The credentials to be used (username an= d password) MUST be supplied within the credentials section of the configur= ation and identified by the realm the registrar uses in a digest challenge.= This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 draft, password= s are no longer returned in the configuration. I think we need to avoid the= RUM RUE caching the user's main account password, which this draft seems t= o require. Best regards James James Hamlin Contractor 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: Rum > on behalf of = Brian Rosen > Sent: 05 February 2021 22:26 To: rum@ietf.org Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt I have posted a -04 revision. This should handle all comments received so = far, please let me know if I forgot something. This version reworks the provider list and configuration sections along the= lines we have been discussing. I do not have a way to download a username/password from a new signup. I= =92m having trouble thinking about a secure way to do that. If anyone has = an idea, I=92m very willing to write text for it. I=92ve considered things= like javascript that stashes it in a file or somewhere else, having some w= eb page function that triggers a local display of an entry form for usernam= e and password, and a couple of other things. One note on the configuration mechanism - because the only thing the local = RUE device needs to keep is the username password against a provider ID of = some kind, there isn=92t any need to standardize how that works, and so it= =92s completely absent in the text. For now, I=92ve removed the step by step diagram that showed how the config= mechanism is used. I think what is there is dead simple and needs no expl= anation: it=92s a straightforward REST/JSON web service using username/pass= word authentication for providers the user has accounts with. I can bring = back the diagram if that is needed. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-rum-rue-04.txt Date: February 5, 2021 at 5:17:15 PM EST To: > Cc: rum@ietf.org Reply-To: internet-drafts@ietf.org, rum@ie= tf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_161410001438854843purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


It's been a while since the refresh token was discussed; but if it is re= turned in the configuration, the RUE should replace/overwrit= e it's stored copy of the user password with the token. = ;The token would then be valid where the user pass= word was valid initially. Similarly, in further refreshes of the config, if a refresh token is return= ed, it replaces the previous token. That wouldn't have any effect=  on the ability to recover from power failure.

 

James


James Hamlin
Contractor
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 <= /div>
message.


From: Brian Rosen <br@= brianrosen.net>
Sent: 23 February 2021 15:09
To: James Hamlin
Cc: Jim Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Okay, I=92ll add optional SIP/STUN/TURN credentials.  

Tell me a little more about how you think the refresh token= would work.  Would it allow a device to have a power failure, come ba= ck, and accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, James Hamlin <james.hamlin@purple.us> wrot= e:

Brian

I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a ref= resh token which the RUE would hold in place&= nbsp;of the user login password would also be usef= ul, as it would mean the login password would=  not have to be stored after the first configuration; refre= shing an expired configuration would be done with the refres= h token.

James


James Hamlin
Contractor
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 orig= inal 
message.


From: Brian Rosen <br@brianrosen.net>
Sent: 2= 2 February 2021 18:46
To: Jam= es Hamlin
Cc: Jim= Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP credentials
c) STUN/TURN credentials

The current draft treats them all as identical.  Is th= ere a reason to make them separate?  My VoIP accounts have only one se= t.  I=92m okay adding a separate SIP/STUN/TURN credential returned in = the config file, protected by the actual user login credentials, if that is really useful.  Maybe it could be optional, a= nd if not provided, the userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote= :

Jim

Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater flexibility in how a user's use=  of different RUE's can be isolated.

I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= .

Best Regards

James


James Hamlin
Contractor
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 orig= inal 
message.


 
From: Jim Malloy <jmalloy@mitre.org>
Sent: 0= 9 February 2021 14:20
To: Bri= an Rosen; James Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
=93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94

 

James =96 

 

Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials?  (Mobile applications may do so at the OS level even if = the application doesn=92t explicitly do so.)  If so, is there a reason= to treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

 

From: R= um <rum-bounces@ietf.= org> On Behalf Of Brian Rosen
Sent: T= uesday, February 9, 2021 8:44 AM
To: Ham= lin, James <james.h= amlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

 

I=92ll delete the text in registration.  
Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use.  Every one.  They do that for a simple reason -= so incoming calls work after a power loss.  Most also are effectively= set and forget, which is what you want in a phone.  Why would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it.  I think that=92s pretty reasonable.

 

If you have another proposal for how we can maintain the config data secure= ly, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <jame= s.hamlin@purple.us> wrote:

 

Brian

 

Section 5.1 Registration says tha= t "The credentials to be used (username and password) MUST be supplied= within the credentials section of the configuration and identified by the = realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we need to avoid the RUM RUE caching the user's mai= n account password, which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 0= 5 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

 

I have posted a -04 revision. &nb= sp;This should handle all comments received so far, please let me know if I= forgot something.<= /div>

 

This version reworks the provider= list and configuration sections along the lines we have been discussing.

 

I do not have a way to download a= username/password from a new signup.  I=92m having trouble thinking a= bout a secure way to do that.  If anyone has an idea, I=92m very willi= ng to write text for it.  I=92ve considered things like javascript that stashes it in a file or somewhere else, having some web pa= ge function that triggers a local display of an entry form for username and= password, and a couple of other things.

 

One note on the configuration mec= hanism - because the only thing the local RUE device needs to keep is the u= sername password against a provider ID of some kind, there isn=92t any need= to standardize how that works, and so it=92s completely absent in the text.  

 

For now, I=92ve removed the step = by step diagram that showed how the config mechanism is used.  I think= what is there is dead simple and needs no explanation: it=92s a straightfo= rward REST/JSON web service using username/password authentication for providers the user has accounts with.  I can bring= back the diagram if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.t= xt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ie= tf.org

 


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

       Title     &nb= sp;     : Interoperability Profile for Relay User = Equipment
       Author     &n= bsp;    : Brian Rosen
Filename        : draft-ietf-rum-rue-04.= txt
Pages           : 33
Date            : 20= 21-02-05

Abstract:
  Video Relay Service (VRS) is a term used to describe a method b= y
  which a hearing persons can communicate with deaf/Hard of Heari= ng
  user using an interpreter ("Communications Assistant"= ) connected via
  a videophone to the deaf/HoH user and an audio telephone call t= o the
  hearing user.  The CA interprets using sign language on th= e
  videophone link and voice on the telephone link.  Often th= e
  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 ser= vice,
  and subsequently to CAs and other deaf/HoH users.  It is d= esirable
  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 t= hat
  video calls direct between deaf/HoH users work.  This docu= ment
  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/<= /a>

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


_______________________________________________
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://ft= p.ietf.org/ietf/1shadow-sites.txt

 

 

 




--_000_161410001438854843purpleus_-- From nobody Tue Feb 23 09:21: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 396E63A0BF6 for ; Tue, 23 Feb 2021 09:21:29 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 3C9hdeHDEf-Z for ; Tue, 23 Feb 2021 09:21:25 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B853A0BF5 for ; Tue, 23 Feb 2021 09:21:24 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id z128so12384818qkc.12 for ; Tue, 23 Feb 2021 09:21:24 -0800 (PST) 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=k4DwX7w4k1FLzSLBv8BOhfHLufX92WViGyWayXqHTYU=; b=aJbatEFyPThiT0yii02ZMN8BuKIh75OY3Yfxov5ckCmSUeO5fDAQaWBBpo2fD2u95G Lgny0pELEoVnNGHBj2C57E+NwgDVYFxFCOpJHMQT9pfaavVYDQXBynL9EU011SPQQj0P HyGyG871ZpIGFcPNpFOeS5UlgSywC+XqQK8gIfnRsvmBCBShns1WmKHcK9mPD4kqvhjb s0Z057zQcjM+Pdqgk7qGnh/SEY2xb/sNUvLAbql7fB8U6bEOBmP0TVGPLGqWB0hY+8m/ Wb0H/lymfVNxQwuY8BkWz+g4uezzyRHp7+yrtNRTDQfG0Vbh6zuZYwXAvtimIpZKPmh+ /3vw== 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=k4DwX7w4k1FLzSLBv8BOhfHLufX92WViGyWayXqHTYU=; b=Ui/xyD1L/mNvINXRklbHimzyJ+fJR8jwVlp3Q+PqU6sE85aHs+Dzcck3+tM55mAabC UfaGuOJJkZl5pOc49elacS/5fF0GElWRIctLyToosNp1qIgjC6TvQiUMpAHPsnvnDcqQ M3zjHyvZOYoiEF70KVYHagCTSgi3yKLM6xb+vPyhX4Z7qpgksfyW1ebb26mACHMqoshK LXAXny5MCugFThFj44SGFMU7ueJjG4oaG8f59LKROAAVbgiRfFzyu8bP2eIShwFSfre/ Rc0JyFzC2gdAXUPX3BSZTxhPDrvaLihBbC4ARZYAmYVJswF7xzALhh8mdL1a7qIi1siz RbRw== X-Gm-Message-State: AOAM532DB6HEwDg5o2GwaCSFOCuo2ifJlLu6xxLRP1ZvkdFk6yYJNcab 1GhS2FtN1N5lHx97ZvbjKh0R8w== X-Google-Smtp-Source: ABdhPJxrjnaezaai8S0cQcL5GZeT8SoaLaMAqHCpdsmPS8/gaijo4bukGY0unDXSMPY+OveNMpqEUQ== X-Received: by 2002:a37:a7c9:: with SMTP id q192mr26185536qke.299.1614100883876; Tue, 23 Feb 2021 09:21:23 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g10sm13359690qto.90.2021.02.23.09.21.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 09:21:23 -0800 (PST) From: Brian Rosen Message-Id: <7AB4E72F-09B8-4016-A2CE-49C6B12EAA48@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_7F481D75-5258-4CC7-BD78-2DFC3FC6925C" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 23 Feb 2021 12:21:20 -0500 In-Reply-To: <1614100014388.54843@purple.us> Cc: Jim Malloy , "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> <1614100014388.54843@purple.us> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 17:21:29 -0000 --Apple-Mail=_7F481D75-5258-4CC7-BD78-2DFC3FC6925C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is the token a username/password equivalent (meaning, does it use the = normal SIP REGISTER authentication)? As long as it=E2=80=99s valid until replaced, that=E2=80=99s OK with me. Brian > On Feb 23, 2021, at 12:06 PM, James Hamlin = wrote: >=20 >=20 > It's been a while since the refresh token was discussed; but if it is = returned in the configuration, the RUE should replace/overwrite it's = stored copy of the user password with the token. The token would then be = valid where the user password was valid initially. Similarly, in further = refreshes of the config, if a refresh token is returned, it replaces the = previous token. That wouldn't have any effect on the ability to recover = from power failure.=20 > =20 > James >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Brian Rosen > Sent: 23 February 2021 15:09 > To: James Hamlin > Cc: Jim Malloy; rum@ietf.org > Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =20 >=20 > Tell me a little more about how you think the refresh token would = work. Would it allow a device to have a power failure, come back, and = accept incoming calls? >=20 > Brian >=20 >=20 >=20 >> On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: >>=20 >> Brian >>=20 >> I think having the flexibility to optionally return separate = SIP/STUN/TURN credentials could be useful. Optionally returning a = refresh token which the RUE would hold in place of the user login = password would also be useful, as it would mean the login password would = not have to be stored after the first configuration; refreshing an = expired configuration would be done with the refresh token. >>=20 >> James >>=20 >>=20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com = >> The information contained in this e-mail message is intended=20 >> only for the personal and confidential use of the recipient(s)=20 >> named above. If you have received this communication in error,=20 >> please notify us immediately by e-mail, and delete the original=20 >> message. >>=20 >> =20 >> From: Brian Rosen > >> Sent: 22 February 2021 18:46 >> To: James Hamlin >> Cc: Jim Malloy; rum@ietf.org >> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> Can we figure out how to converge on this?=20 >>=20 >> There are: >> a) Actual user login credentials >> b) SIP credentials >> c) STUN/TURN credentials >>=20 >> The current draft treats them all as identical. Is there a reason to = make them separate? My VoIP accounts have only one set. I=E2=80=99m = okay adding a separate SIP/STUN/TURN credential returned in the config = file, protected by the actual user login credentials, if that is really = useful. Maybe it could be optional, and if not provided, the = userid/password is used for everything. >>=20 >> Brian >>=20 >>> On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: >>>=20 >>> Jim >>>=20 >>> Yes credentials have to be cached, but not necessarily the user's = primary account credentials. The previous text allowed the configuration = service to send back separate credentials for SIP/STUN/TURN which could = have a shorter validity period than the main account credentials. This = offers greater flexibility in how a user's use of different RUE's can be = isolated. >>>=20 >>> I'll accept that the provider could offer a separate password for = use with each RUE type; we'd need to think about the logistical = implications of that. >>>=20 >>> Best Regards >>>=20 >>> James >>>=20 >>>=20 >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com = >>> The information contained in this e-mail message is intended=20 >>> only for the personal and confidential use of the recipient(s)=20 >>> named above. If you have received this communication in error,=20 >>> please notify us immediately by e-mail, and delete the original=20 >>> message. >>>=20 >>> =20 >>> From: Jim Malloy > >>> Sent: 09 February 2021 14:20 >>> To: Brian Rosen; James Hamlin >>> Cc: rum@ietf.org >>> Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> =E2=80=9CEvery VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use=E2=80=9D >>> =20 >>> James =E2=80=93=20 >>> =20 >>> Do existing ZVRS/Purple devices or mobile applications cache = authentication credentials? (Mobile applications may do so at the OS = level even if the application doesn=E2=80=99t explicitly do so.) If so, = is there a reason to treat the RUE Differently? >>> =20 >>> Thanks, >>>=20 >>> Jim Malloy >>> Principal Information System Engineer >>> The MITRE Corp. >>> 703 983 2835 >>> =20 >>> From: Rum > On = Behalf Of Brian Rosen >>> Sent: Tuesday, February 9, 2021 8:44 AM >>> To: Hamlin, James > >>> Cc: rum@ietf.org >>> Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> I=E2=80=99ll delete the text in registration. =20 >>> Every VoIP phone I=E2=80=99ve ever seen or used caches username and = passwords for stand alone use. Every one. They do that for a simple = reason - so incoming calls work after a power loss. Most also are = effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? >>> =20 >>> The text currently uses the same credentials for the HTTP service = and the SIP service, but that=E2=80=99s it. I think that=E2=80=99s = pretty reasonable. >>> =20 >>> If you have another proposal for how we can maintain the config data = securely, please suggest one. >>> =20 >>> Brian >>>=20 >>>=20 >>> On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: >>> =20 >>> Brian >>> =20 >>> Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >>> =20 >>> Best regards >>> =20 >>> James >>> =20 >>> =20 >>> =20 >>> =20 >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com = >>> The information contained in this e-mail message is intended=20 >>> only for the personal and confidential use of the recipient(s)=20 >>> named above. If you have received this communication in error,=20 >>> please notify us immediately by e-mail, and delete the original=20 >>> message. >>> =20 >>> From: Rum > on = behalf of Brian Rosen > >>> Sent: 05 February 2021 22:26 >>> To: rum@ietf.org >>> Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >>> =20 >>> This version reworks the provider list and configuration sections = along the lines we have been discussing. >>> =20 >>> I do not have a way to download a username/password from a new = signup. I=E2=80=99m having trouble thinking about a secure way to do = that. If anyone has an idea, I=E2=80=99m very willing to write text for = it. I=E2=80=99ve considered things like javascript that stashes it in a = file or somewhere else, having some web page function that triggers a = local display of an entry form for username and password, and a couple = of other things. >>> =20 >>> One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >>> =20 >>> For now, I=E2=80=99ve removed the step by step diagram that showed = how the config mechanism is used. I think what is there is dead simple = and needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >>> =20 >>> Brian >>> =20 >>>=20 >>>=20 >>> Begin forwarded message: >>> =20 >>> From: internet-drafts@ietf.org >>> Subject: I-D Action: draft-ietf-rum-rue-04.txt >>> Date: February 5, 2021 at 5:17:15 PM EST >>> To: > >>> Cc: rum@ietf.org >>> Reply-To: internet-drafts@ietf.org = , rum@ietf.org >>> =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-04.txt >>> Pages : 33 >>> Date : 2021-02-05 >>>=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-04.html = >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=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 >>> =20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_7F481D75-5258-4CC7-BD78-2DFC3FC6925C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Is = the token a username/password equivalent (meaning, does it use the = normal SIP REGISTER authentication)?
As long as it=E2=80=99= s valid until replaced, that=E2=80=99s OK with me.

Brian


On Feb 23, 2021, at 12:06 PM, James Hamlin = <james.hamlin@purple.us> wrote:


It's been a while = since the refresh token was discussed; but if it is returned in the = configuration, the RUE should replace/overwrite = it's stored copy of the user password with the = token. The token would then be valid where the = user password was valid initially. Similarly, in = further refreshes of the config, if a refresh token is = returned, it replaces the previous token. That wouldn't have = any effect on the ability to recover from power failure. 
 
James

James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 15:09
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =  

Tell me a = little more about how you think the refresh token would work. =  Would it allow a device to have a power failure, come back, and = accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, = James Hamlin <james.hamlin@purple.us> wrote:

Brian

I think = having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a = refresh token which the RUE would hold in = place of the user = login password would also be useful, as it = would mean the login password would not = have to be stored after the = first configuration; refreshing an expired configuration = would be done with the refresh token.

James


James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP = credentials
c) STUN/TURN credentials

The current draft treats = them all as identical.  Is there a reason to make them separate? =  My VoIP accounts have only one set.  I=E2=80=99m okay adding = a separate SIP/STUN/TURN credential returned in the config file, = protected by the actual user login credentials, if that is really = useful.  Maybe it could be optional, and if not provided, the = userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote:

Jim

Yes = credentials have to be cached, but not necessarily the user's primary = account credentials. The previous text allowed the configuration service = to send back separate credentials for SIP/STUN/TURN which could have a = shorter validity period than the main account credentials. This offers = greater flexibility in how a user's use of = different RUE's can be isolated.

I'll accept that the provider could offer a = separate password for use with each RUE type; we'd need to think about = the logistical implications of that.

Best Regards

James


James = Hamlin
Contractor
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: Jim Malloy <jmalloy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James = Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D = Action: draft-ietf-rum-rue-04.txt
 
=E2=80=9CEvery VoIP phone = I=E2=80=99ve ever seen or used caches username and passwords for stand = alone use=E2=80=9D

 

James =E2=80=93 

 

Do existing ZVRS/Purple devices = or mobile applications cache authentication credentials?  (Mobile = applications may do so at the OS level even if the application doesn=E2=80= =99t explicitly do so.)  If so, is there a reason to treat the RUE = Differently?

 

Thanks,

Jim Malloy
Principal Information = System Engineer
The MITRE Corp.
703 983 = 2835

 

From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Tuesday, February 9, 2021 = 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt

 

I=E2=80=99ll delete the text in = registration.  
Every VoIP = phone I=E2=80=99ve ever seen or used caches username and passwords for = stand alone use.  Every one.  They do that for a simple reason = - so incoming calls work after a power loss.  Most also are = effectively set and forget, which is what you want in a phone.  Why = would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP = service and the SIP service, but that=E2=80=99s it.  I think = that=E2=80=99s pretty reasonable.

 

If you have another proposal for how we can maintain the = config data securely, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> = wrote:

 

Brian

 

Section 5.1 Registration says that = "The credentials to be used (username and password) MUST be supplied = within the credentials section of the configuration and identified by = the realm the registrar uses in a digest challenge. This = username/password combination SHOULD NOT be the same as that used for = other purposes, such as retrieving the RUE configuration or logging into = the Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we = need to avoid the RUM RUE caching the user's main account password, = which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 = February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt

 

I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.

 

This version reworks the provider list and configuration = sections along the lines we have been discussing.

 

I do not have a way to download a username/password from a new = signup.  I=E2=80=99m having trouble thinking about a secure way to = do that.  If anyone has an idea, I=E2=80=99m very willing to write = text for it.  I=E2=80=99ve considered things like javascript that = stashes it in a file or somewhere else, having some web page function = that triggers a local display of an entry form for username and = password, and a couple of other things.

 

One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =  

 

For now, I=E2=80=99ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is = dead simple and needs no explanation: it=E2=80=99s a straightforward = REST/JSON web service using username/password authentication for = providers the user has accounts with.  I can bring back the diagram = if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM = EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

 


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html=

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04<= br class=3D"">

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

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


_______________________________________________
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

 

 

 





= --Apple-Mail=_7F481D75-5258-4CC7-BD78-2DFC3FC6925C-- From nobody Tue Feb 23 09:49: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 81FCC3A0CA2 for ; Tue, 23 Feb 2021 09:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNIsjx7agnBP for ; Tue, 23 Feb 2021 09:49:01 -0800 (PST) Received: from outbound-ip1a.ess.barracuda.com (outbound-ip1a.ess.barracuda.com [209.222.82.168]) (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 A70213A0C8F for ; Tue, 23 Feb 2021 09:48:55 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx-outbound45-228.us-east-2c.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 23 Feb 2021 17:48:51 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 23 Feb 2021 09:48:50 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Tue, 23 Feb 2021 09:48:50 -0800 From: James Hamlin To: Brian Rosen CC: Jim Malloy , "rum@ietf.org" Thread-Topic: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHXCUsDkPazAWu3o0uzeatovVjWl6pl1NTpgACKVID//5fEj4AAjTQA//96TRw= Date: Tue, 23 Feb 2021 17:48:49 +0000 Message-ID: <1614102529543.36715@purple.us> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> <1614100014388.54843@purple.us>, <7AB4E72F-09B8-4016-A2CE-49C6B12EAA48@brianrosen.net> In-Reply-To: <7AB4E72F-09B8-4016-A2CE-49C6B12EAA48@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_161410252954336715purpleus_" MIME-Version: 1.0 X-BESS-ID: 1614102531-111748-5758-38478-1 X-BESS-VER: 2019.1_20210219.2020 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230407 [from cloudscan18-87.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 17:49:05 -0000 --_000_161410252954336715purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I was assuming the refresh token would simply stand in for the password lit= erally. That said, when the idea was previously discussed, the token would = have solely been used in authentication for config retrieval, as SIP would = use the password set by configuration. It has been a long time since the re= fresh token was discussed so others might remember more. I think the provider needs to keep one token valid until the next is first = used or make it valid for much longer than the configuration lifetime. James James Hamlin Contractor 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: 23 February 2021 17:21 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Is the token a username/password equivalent (meaning, does it use the norma= l SIP REGISTER authentication)? As long as it=92s valid until replaced, that=92s OK with me. Brian On Feb 23, 2021, at 12:06 PM, James Hamlin > wrote: It's been a while since the refresh token was discussed; but if it is retur= ned in the configuration, the RUE should replace/overwrite it's stored copy= of the user password with the token. The token would then be valid where t= he user password was valid initially. Similarly, in further refreshes of th= e config, if a refresh token is returned, it replaces the previous token. T= hat wouldn't have any effect on the ability to recover from power failure. James James Hamlin Contractor 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: 23 February 2021 15:09 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Okay, I=92ll add optional SIP/STUN/TURN credentials. Tell me a little more about how you think the refresh token would work. Wo= uld it allow a device to have a power failure, come back, and accept incomi= ng calls? Brian On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: Brian I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a refresh token which the= RUE would hold in place of the user login password would also be useful, a= s it would mean the login password would not have to be stored after the fi= rst configuration; refreshing an expired configuration would be done with t= he refresh token. James James Hamlin Contractor 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: 22 February 2021 18:46 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Can we figure out how to converge on this? There are: a) Actual user login credentials b) SIP credentials c) STUN/TURN credentials The current draft treats them all as identical. Is there a reason to make = them separate? My VoIP accounts have only one set. I=92m okay adding a se= parate SIP/STUN/TURN credential returned in the config file, protected by t= he actual user login credentials, if that is really useful. Maybe it could= be optional, and if not provided, the userid/password is used for everythi= ng. Brian On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: Jim Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater fle= xibility in how a user's use of different RUE's can be isolated. I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= . Best Regards James James Hamlin Contractor 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: Jim Malloy > Sent: 09 February 2021 14:20 To: Brian Rosen; James Hamlin Cc: rum@ietf.org Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt =93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94 James =96 Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials? (Mobile applications may do so at the OS level even if the a= pplication doesn=92t explicitly do so.) If so, is there a reason to treat = the RUE Differently? Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 From: Rum > On Behalf Of = Brian Rosen Sent: Tuesday, February 9, 2021 8:44 AM To: Hamlin, James > Cc: rum@ietf.org Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt I=92ll delete the text in registration. Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use. Every one. They do that for a simple reason - so incomi= ng calls work after a power loss. Most also are effectively set and forget= , which is what you want in a phone. Why would we require manual entry for= the RUE? The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it. I think that=92s pretty reasonable. If you have another proposal for how we can maintain the config data secure= ly, please suggest one. Brian On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: Brian Section 5.1 Registration says that "The credentials to be used (username an= d password) MUST be supplied within the credentials section of the configur= ation and identified by the realm the registrar uses in a digest challenge.= This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 draft, password= s are no longer returned in the configuration. I think we need to avoid the= RUM RUE caching the user's main account password, which this draft seems t= o require. Best regards James James Hamlin Contractor 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: Rum > on behalf of = Brian Rosen > Sent: 05 February 2021 22:26 To: rum@ietf.org Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt I have posted a -04 revision. This should handle all comments received so = far, please let me know if I forgot something. This version reworks the provider list and configuration sections along the= lines we have been discussing. I do not have a way to download a username/password from a new signup. I= =92m having trouble thinking about a secure way to do that. If anyone has = an idea, I=92m very willing to write text for it. I=92ve considered things= like javascript that stashes it in a file or somewhere else, having some w= eb page function that triggers a local display of an entry form for usernam= e and password, and a couple of other things. One note on the configuration mechanism - because the only thing the local = RUE device needs to keep is the username password against a provider ID of = some kind, there isn=92t any need to standardize how that works, and so it= =92s completely absent in the text. For now, I=92ve removed the step by step diagram that showed how the config= mechanism is used. I think what is there is dead simple and needs no expl= anation: it=92s a straightforward REST/JSON web service using username/pass= word authentication for providers the user has accounts with. I can bring = back the diagram if that is needed. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-rum-rue-04.txt Date: February 5, 2021 at 5:17:15 PM EST To: > Cc: rum@ietf.org Reply-To: internet-drafts@ietf.org, rum@ie= tf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_161410252954336715purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


I was assuming the refresh token would simply stand in for the pass= word literally. That said, when the idea was previously discussed, the toke= n would have solely been used in authentication for config retrieval, as SI= P would use the password set by configuration. It has been a long time since the refresh token was discussed so others mi= ght remember more.


I think the provider needs to keep one token valid until = the next is first used or make it valid for much longer than= the configuration lifetime.



James




James Hamlin
Contractor
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 <= /div>
message.


From: Brian Rosen <br@= brianrosen.net>
Sent: 23 February 2021 17:21
To: James Hamlin
Cc: Jim Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Is the token a username/password equivalent (meaning, does it use the = normal SIP REGISTER authentication)?
As long as it=92s valid until replaced, that=92s OK with me= .

Brian


On Feb 23, 2021, at 12:06 PM, James Hamlin <james.hamlin@purple.us> wro= te:


It's been a while since the refresh token was discussed; but if it is retur= ned in the configuration, the RUE should replace/overwrite i= t's stored copy of the user password with the token. Th= e token would then be valid where the user passwor= d was valid initially. Similarly, in further refreshes of the config, if a refresh token is return= ed, it replaces the previous token. That wouldn't have any effect=  on the ability to recover from power failure. 
 
James

James Hamlin
Contractor
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 orig= inal 
message.


From: Brian Rosen <br@brianrosen.net>
Sent: 2= 3 February 2021 15:09
To: Jam= es Hamlin
Cc: Jim= Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Okay, I=92ll add optional SIP/STUN/TURN credentials.  

Tell me a little more about how you think the refresh token= would work.  Would it allow a device to have a power failure, come ba= ck, and accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, James Hamlin <james.hamlin@purple.us> wrot= e:

Brian

I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a ref= resh token which the RUE would hold in place&= nbsp;of the user login password would also be usef= ul, as it would mean the login password would=  not have to be stored after the first configuration; refre= shing an expired configuration would be done with the refres= h token.

James


James Hamlin
Contractor
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 orig= inal 
message.


 
From: Brian Rosen <br@brianrosen.net>
Sent: 2= 2 February 2021 18:46
To: Jam= es Hamlin
Cc: Jim= Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP credentials
c) STUN/TURN credentials

The current draft treats them all as identical.  Is th= ere a reason to make them separate?  My VoIP accounts have only one se= t.  I=92m okay adding a separate SIP/STUN/TURN credential returned in = the config file, protected by the actual user login credentials, if that is really useful.  Maybe it could be optional, a= nd if not provided, the userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote= :

Jim

Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater flexibility in how a user's use=  of different RUE's can be isolated.

I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= .

Best Regards

James


James Hamlin
Contractor
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 orig= inal 
message.


 
From: Jim Malloy <jmalloy@mitre.org>
Sent: 0= 9 February 2021 14:20
To: Bri= an Rosen; James Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
=93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94

 

James =96 

 

Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials?  (Mobile applications may do so at the OS level even if = the application doesn=92t explicitly do so.)  If so, is there a reason= to treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

 

From: R= um <rum-bounces@ietf.= org> On Behalf Of Brian Rosen
Sent: T= uesday, February 9, 2021 8:44 AM
To: Ham= lin, James <james.h= amlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

 

I=92ll delete the text in registration.  
Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use.  Every one.  They do that for a simple reason -= so incoming calls work after a power loss.  Most also are effectively= set and forget, which is what you want in a phone.  Why would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it.  I think that=92s pretty reasonable.

 

If you have another proposal for how we can maintain the config data secure= ly, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <jame= s.hamlin@purple.us> wrote:

 

Brian

 

Section 5.1 Registration says tha= t "The credentials to be used (username and password) MUST be supplied= within the credentials section of the configuration and identified by the = realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we need to avoid the RUM RUE caching the user's mai= n account password, which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 0= 5 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

 

I have posted a -04 revision. &nb= sp;This should handle all comments received so far, please let me know if I= forgot something.<= /div>

 

This version reworks the provider= list and configuration sections along the lines we have been discussing.

 

I do not have a way to download a= username/password from a new signup.  I=92m having trouble thinking a= bout a secure way to do that.  If anyone has an idea, I=92m very willi= ng to write text for it.  I=92ve considered things like javascript that stashes it in a file or somewhere else, having some web pa= ge function that triggers a local display of an entry form for username and= password, and a couple of other things.

 

One note on the configuration mec= hanism - because the only thing the local RUE device needs to keep is the u= sername password against a provider ID of some kind, there isn=92t any need= to standardize how that works, and so it=92s completely absent in the text.  

 

For now, I=92ve removed the step = by step diagram that showed how the config mechanism is used.  I think= what is there is dead simple and needs no explanation: it=92s a straightfo= rward REST/JSON web service using username/password authentication for providers the user has accounts with.  I can bring= back the diagram if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.t= xt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ie= tf.org

 


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

       Title     &nb= sp;     : Interoperability Profile for Relay User = Equipment
       Author     &n= bsp;    : Brian Rosen
Filename        : draft-ietf-rum-rue-04.= txt
Pages           : 33
Date            : 20= 21-02-05

Abstract:
  Video Relay Service (VRS) is a term used to describe a method b= y
  which a hearing persons can communicate with deaf/Hard of Heari= ng
  user using an interpreter ("Communications Assistant"= ) connected via
  a videophone to the deaf/HoH user and an audio telephone call t= o the
  hearing user.  The CA interprets using sign language on th= e
  videophone link and voice on the telephone link.  Often th= e
  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 ser= vice,
  and subsequently to CAs and other deaf/HoH users.  It is d= esirable
  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 t= hat
  video calls direct between deaf/HoH users work.  This docu= ment
  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/<= /a>

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


_______________________________________________
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://ft= p.ietf.org/ietf/1shadow-sites.txt

 

 

 






--_000_161410252954336715purpleus_-- From nobody Tue Feb 23 10:39:17 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 BC2C33A0E1B for ; Tue, 23 Feb 2021 10:39:14 -0800 (PST) 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 ZbfGvQC54Ml9 for ; Tue, 23 Feb 2021 10:39:10 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 C233B3A0E19 for ; Tue, 23 Feb 2021 10:39:09 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id h8so17191857qkk.6 for ; Tue, 23 Feb 2021 10:39:09 -0800 (PST) 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=SORtxt9OmMTGKJzGU4GthkR7ZH74+/V+AecdWY48RRk=; b=jwHei5gKswwrDPnFtq0Mr+wK+bbkZekDiMzUmiIWfKRNvMkF4oVLONpM2h2eaazl3f allapfu7lvATGV8Fg9n/Bmf5+JHnzR6IaxdxQbHv4EfoukIuHFlcViPA+qZWJy3HsR2c Xm1OdTpdbm7NXOYAQfOlYgRx7S8DIdoNWqeZIT+XmExGLcGRncVXlbVAsJnFRko+xYI+ azq0rZvwb6oYim6yMyuhaYvPzfsJVfPk1GTEkBac1SdtzBRGvvrwkUyqAZ3s7FX6gKs5 o+G+p8KMHlLO3o/ME+NptfQkCx6bDSOrilhMHgW2OPDObIpEOVIYsejNQj1Y20zIz0zc xgZA== 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=SORtxt9OmMTGKJzGU4GthkR7ZH74+/V+AecdWY48RRk=; b=IYPLrulF8ErYt4+pIJ18JmcOzO2cTU+RNIWjCV4M/0J+2N6Fvw8MbvIt63oxl5l2vY WU6Z+Swg2j7DtdoVIyI6teHhBlHQmeR3OKRFE7GBvCpu+Tg8CMdkmPshunrU+FHnG/s0 JAdJgn2HrVmP1+z2VYgn6yv9izncNETx16opG8njjr+PjoVgrFDB7ob7xkqNzDhiUH5R cXWbLVPEnKfbtiN5I0VhywgeVOz5/0Q+KIm1ZkJg2rzC1spBa4sSyzL0SEJP+fLuDZ5R jXgDc09t5RUvrEdEjfsZoRMBqFk8r1FTRnoF3dtsQcDAd5gk1KwsmtCvB23D2Ngj42rU 671Q== X-Gm-Message-State: AOAM533mO86pXQOVaH8xOXgM2rmIpnrlR/30f7fnkxLbi6ScRvqWQu2G PLkK6Wq/wNTKeiNx1tHm8nnZvQ== X-Google-Smtp-Source: ABdhPJw3XfM5oQ4jedVw9aHLEOkpAYkPcDKvRUHDWNAI4JnhuNUQVJ8YJ/YFCcOBFptEKtyPLan0UQ== X-Received: by 2002:a37:4a56:: with SMTP id x83mr27507209qka.205.1614105548630; Tue, 23 Feb 2021 10:39:08 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id g2sm15413593qkd.124.2021.02.23.10.39.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 10:39:07 -0800 (PST) From: Brian Rosen Message-Id: <2271089B-063E-4EAD-A508-4B5963D4E772@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_A0EB2D87-7DDB-49AA-B3BE-5A5AC6006628" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 23 Feb 2021 13:39:06 -0500 In-Reply-To: <1614102529543.36715@purple.us> Cc: Jim Malloy , "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> <1614100014388.54843@purple.us> <7AB4E72F-09B8-4016-A2CE-49C6B12EAA48@brianrosen.net> <1614102529543.36715@purple.us> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 18:39:15 -0000 --Apple-Mail=_A0EB2D87-7DDB-49AA-B3BE-5A5AC6006628 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Okay, let=E2=80=99s walk through how this is used: 1. The user creates a new account. They create a username/password for = the account. That is stored in the device 2. The device retrieves configuration using the username/password 3. Configuration may contain a refresh token. This is a password. The = token is used instead if the actual password, but with the actual = username, to do SIP/STUN/TURN authentication. 4. The refresh token is used until the config retrieval changes it. Is that right? Can you explain why this is better than just using the = account username/password? Brian > On Feb 23, 2021, at 12:48 PM, James Hamlin = wrote: >=20 >=20 > I was assuming the refresh token would simply stand in for the = password literally. That said, when the idea was previously discussed, = the token would have solely been used in authentication for config = retrieval, as SIP would use the password set by configuration. It has = been a long time since the refresh token was discussed so others might = remember more. >=20 > I think the provider needs to keep one token valid until the next is = first used or make it valid for much longer than the configuration = lifetime. >=20 >=20 > James >=20 >=20 >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Brian Rosen > Sent: 23 February 2021 17:21 > To: James Hamlin > Cc: Jim Malloy; rum@ietf.org > Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > Is the token a username/password equivalent (meaning, does it use the = normal SIP REGISTER authentication)? > As long as it=E2=80=99s valid until replaced, that=E2=80=99s OK with = me. >=20 > Brian >=20 >=20 >> On Feb 23, 2021, at 12:06 PM, James Hamlin > wrote: >>=20 >>=20 >> It's been a while since the refresh token was discussed; but if it is = returned in the configuration, the RUE should replace/overwrite it's = stored copy of the user password with the token. The token would then be = valid where the user password was valid initially. Similarly, in further = refreshes of the config, if a refresh token is returned, it replaces the = previous token. That wouldn't have any effect on the ability to recover = from power failure.=20 >> =20 >> James >>=20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com = >> The information contained in this e-mail message is intended=20 >> only for the personal and confidential use of the recipient(s)=20 >> named above. If you have received this communication in error,=20 >> please notify us immediately by e-mail, and delete the original=20 >> message. >>=20 >> =20 >> From: Brian Rosen > >> Sent: 23 February 2021 15:09 >> To: James Hamlin >> Cc: Jim Malloy; rum@ietf.org >> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =20 >>=20 >> Tell me a little more about how you think the refresh token would = work. Would it allow a device to have a power failure, come back, and = accept incoming calls? >>=20 >> Brian >>=20 >>=20 >>=20 >>> On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: >>>=20 >>> Brian >>>=20 >>> I think having the flexibility to optionally return separate = SIP/STUN/TURN credentials could be useful. Optionally returning a = refresh token which the RUE would hold in place of the user login = password would also be useful, as it would mean the login password would = not have to be stored after the first configuration; refreshing an = expired configuration would be done with the refresh token. >>>=20 >>> James >>>=20 >>>=20 >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com = >>> The information contained in this e-mail message is intended=20 >>> only for the personal and confidential use of the recipient(s)=20 >>> named above. If you have received this communication in error,=20 >>> please notify us immediately by e-mail, and delete the original=20 >>> message. >>>=20 >>> =20 >>> From: Brian Rosen > >>> Sent: 22 February 2021 18:46 >>> To: James Hamlin >>> Cc: Jim Malloy; rum@ietf.org >>> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> Can we figure out how to converge on this?=20 >>>=20 >>> There are: >>> a) Actual user login credentials >>> b) SIP credentials >>> c) STUN/TURN credentials >>>=20 >>> The current draft treats them all as identical. Is there a reason = to make them separate? My VoIP accounts have only one set. I=E2=80=99m = okay adding a separate SIP/STUN/TURN credential returned in the config = file, protected by the actual user login credentials, if that is really = useful. Maybe it could be optional, and if not provided, the = userid/password is used for everything. >>>=20 >>> Brian >>>=20 >>>> On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: >>>>=20 >>>> Jim >>>>=20 >>>> Yes credentials have to be cached, but not necessarily the user's = primary account credentials. The previous text allowed the configuration = service to send back separate credentials for SIP/STUN/TURN which could = have a shorter validity period than the main account credentials. This = offers greater flexibility in how a user's use of different RUE's can be = isolated. >>>>=20 >>>> I'll accept that the provider could offer a separate password for = use with each RUE type; we'd need to think about the logistical = implications of that. >>>>=20 >>>> Best Regards >>>>=20 >>>> James >>>>=20 >>>>=20 >>>> James Hamlin >>>> Contractor >>>> Purple, a Division of ZP Better Together, LLC >>>> purplevrs.com = >>>> The information contained in this e-mail message is intended=20 >>>> only for the personal and confidential use of the recipient(s)=20 >>>> named above. If you have received this communication in error,=20 >>>> please notify us immediately by e-mail, and delete the original=20 >>>> message. >>>>=20 >>>> =20 >>>> From: Jim Malloy > >>>> Sent: 09 February 2021 14:20 >>>> To: Brian Rosen; James Hamlin >>>> Cc: rum@ietf.org >>>> Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>>> =20 >>>> =E2=80=9CEvery VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use=E2=80=9D >>>> =20 >>>> James =E2=80=93=20 >>>> =20 >>>> Do existing ZVRS/Purple devices or mobile applications cache = authentication credentials? (Mobile applications may do so at the OS = level even if the application doesn=E2=80=99t explicitly do so.) If so, = is there a reason to treat the RUE Differently? >>>> =20 >>>> Thanks, >>>>=20 >>>> Jim Malloy >>>> Principal Information System Engineer >>>> The MITRE Corp. >>>> 703 983 2835 >>>> =20 >>>> From: Rum > On = Behalf Of Brian Rosen >>>> Sent: Tuesday, February 9, 2021 8:44 AM >>>> To: Hamlin, James > >>>> Cc: rum@ietf.org >>>> Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>>> =20 >>>> I=E2=80=99ll delete the text in registration. =20 >>>> Every VoIP phone I=E2=80=99ve ever seen or used caches username and = passwords for stand alone use. Every one. They do that for a simple = reason - so incoming calls work after a power loss. Most also are = effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? >>>> =20 >>>> The text currently uses the same credentials for the HTTP service = and the SIP service, but that=E2=80=99s it. I think that=E2=80=99s = pretty reasonable. >>>> =20 >>>> If you have another proposal for how we can maintain the config = data securely, please suggest one. >>>> =20 >>>> Brian >>>>=20 >>>>=20 >>>> On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: >>>> =20 >>>> Brian >>>> =20 >>>> Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >>>> =20 >>>> Best regards >>>> =20 >>>> James >>>> =20 >>>> =20 >>>> =20 >>>> =20 >>>> James Hamlin >>>> Contractor >>>> Purple, a Division of ZP Better Together, LLC >>>> purplevrs.com = >>>> The information contained in this e-mail message is intended=20 >>>> only for the personal and confidential use of the recipient(s)=20 >>>> named above. If you have received this communication in error,=20 >>>> please notify us immediately by e-mail, and delete the original=20 >>>> message. >>>> =20 >>>> From: Rum > on = behalf of Brian Rosen > >>>> Sent: 05 February 2021 22:26 >>>> To: rum@ietf.org >>>> Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >>>> =20 >>>> I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >>>> =20 >>>> This version reworks the provider list and configuration sections = along the lines we have been discussing. >>>> =20 >>>> I do not have a way to download a username/password from a new = signup. I=E2=80=99m having trouble thinking about a secure way to do = that. If anyone has an idea, I=E2=80=99m very willing to write text for = it. I=E2=80=99ve considered things like javascript that stashes it in a = file or somewhere else, having some web page function that triggers a = local display of an entry form for username and password, and a couple = of other things. >>>> =20 >>>> One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >>>> =20 >>>> For now, I=E2=80=99ve removed the step by step diagram that showed = how the config mechanism is used. I think what is there is dead simple = and needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >>>> =20 >>>> Brian >>>> =20 >>>>=20 >>>>=20 >>>> Begin forwarded message: >>>> =20 >>>> From: internet-drafts@ietf.org >>>> Subject: I-D Action: draft-ietf-rum-rue-04.txt >>>> Date: February 5, 2021 at 5:17:15 PM EST >>>> To: > >>>> Cc: rum@ietf.org >>>> Reply-To: internet-drafts@ietf.org = , rum@ietf.org >>>> =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-04.txt >>>> Pages : 33 >>>> Date : 2021-02-05 >>>>=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-04.html = >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at tools.ietf.org = . >>>>=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 >>>> =20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_A0EB2D87-7DDB-49AA-B3BE-5A5AC6006628 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Okay,= let=E2=80=99s walk through how this is used:
1. The user = creates a new account.  They create a username/password for the = account.  That is stored in the device
2. The = device retrieves configuration using the username/password
3. Configuration may contain a refresh token.  This is a = password.  The token is used instead if the actual password, but = with the actual username, to do SIP/STUN/TURN authentication.
4. The refresh token is used until the config retrieval = changes it.

Is = that right?  Can you explain why this is better than just using the = account username/password?

Brian


On Feb 23, 2021, at 12:48 PM, James Hamlin <james.hamlin@purple.us> wrote:


I was assuming the = refresh token would simply stand in for the password literally. = That said, when the idea was previously discussed, the token would have = solely been used in authentication for config retrieval, as SIP would = use the password set by configuration. It has been a long time since the = refresh token was discussed so others might remember more.

I think the provider needs to = keep one token valid until the next is first used or = make it valid for much longer than the configuration = lifetime.


James



James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 17:21
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Is the token a username/password equivalent (meaning, does it = use the normal SIP REGISTER authentication)?
As long as = it=E2=80=99s valid until replaced, that=E2=80=99s OK with me.

Brian


On Feb 23, 2021, at 12:06 PM, = James Hamlin <james.hamlin@purple.us> wrote:


It's = been a while since the refresh token was discussed; but if it is = returned in the configuration, the RUE should = replace/overwrite it's stored copy of the user = password with the token. The token would = then be valid where the user password was = valid initially. Similarly, in further refreshes of the = config, if a refresh token is returned, it replaces the = previous token. That wouldn't have any effect on the = ability to recover from power failure. 
 
James

James = Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 15:09
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =  

Tell me a = little more about how you think the refresh token would work. =  Would it allow a device to have a power failure, come back, and = accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, = James Hamlin <james.hamlin@purple.us> wrote:

Brian

I think = having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a = refresh token which the RUE would hold in = place of the user = login password would also be useful, as it = would mean the login password would not = have to be stored after the = first configuration; refreshing an expired configuration = would be done with the refresh token.

James


James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP = credentials
c) STUN/TURN credentials

The current draft treats = them all as identical.  Is there a reason to make them separate? =  My VoIP accounts have only one set.  I=E2=80=99m okay adding = a separate SIP/STUN/TURN credential returned in the config file, = protected by the actual user login credentials, if that is really = useful.  Maybe it could be optional, and if not provided, the = userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote:

Jim

Yes = credentials have to be cached, but not necessarily the user's primary = account credentials. The previous text allowed the configuration service = to send back separate credentials for SIP/STUN/TURN which could have a = shorter validity period than the main account credentials. This offers = greater flexibility in how a user's use of = different RUE's can be isolated.

I'll accept that the provider could offer a = separate password for use with each RUE type; we'd need to think about = the logistical implications of that.

Best Regards

James


James = Hamlin
Contractor
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: Jim Malloy <jmalloy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James = Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D = Action: draft-ietf-rum-rue-04.txt
 
=E2=80=9CEvery VoIP phone = I=E2=80=99ve ever seen or used caches username and passwords for stand = alone use=E2=80=9D

 

James =E2=80=93 

 

Do existing ZVRS/Purple devices = or mobile applications cache authentication credentials?  (Mobile = applications may do so at the OS level even if the application doesn=E2=80= =99t explicitly do so.)  If so, is there a reason to treat the RUE = Differently?

 

Thanks,

Jim Malloy
Principal Information = System Engineer
The MITRE Corp.
703 983 = 2835

 

From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Tuesday, February 9, 2021 = 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt

 

I=E2=80=99ll delete the text in = registration.  
Every VoIP = phone I=E2=80=99ve ever seen or used caches username and passwords for = stand alone use.  Every one.  They do that for a simple reason = - so incoming calls work after a power loss.  Most also are = effectively set and forget, which is what you want in a phone.  Why = would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP = service and the SIP service, but that=E2=80=99s it.  I think = that=E2=80=99s pretty reasonable.

 

If you have another proposal for how we can maintain the = config data securely, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> = wrote:

 

Brian

 

Section 5.1 Registration says that = "The credentials to be used (username and password) MUST be supplied = within the credentials section of the configuration and identified by = the realm the registrar uses in a digest challenge. This = username/password combination SHOULD NOT be the same as that used for = other purposes, such as retrieving the RUE configuration or logging into = the Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we = need to avoid the RUM RUE caching the user's main account password, = which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 = February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt

 

I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.

 

This version reworks the provider list and configuration = sections along the lines we have been discussing.

 

I do not have a way to download a username/password from a new = signup.  I=E2=80=99m having trouble thinking about a secure way to = do that.  If anyone has an idea, I=E2=80=99m very willing to write = text for it.  I=E2=80=99ve considered things like javascript that = stashes it in a file or somewhere else, having some web page function = that triggers a local display of an entry form for username and = password, and a couple of other things.

 

One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =  

 

For now, I=E2=80=99ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is = dead simple and needs no explanation: it=E2=80=99s a straightforward = REST/JSON web service using username/password authentication for = providers the user has accounts with.  I can bring back the diagram = if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM = EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

 


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html=

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04<= br class=3D"">

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

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


_______________________________________________
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

 

 

 







= --Apple-Mail=_A0EB2D87-7DDB-49AA-B3BE-5A5AC6006628-- From nobody Tue Feb 23 13:40:13 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 911E93A0C8A for ; Tue, 23 Feb 2021 13:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LNNJsid-1paG for ; Tue, 23 Feb 2021 13:40:09 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2088.outbound.protection.outlook.com [40.107.92.88]) (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 E35943A0C87 for ; Tue, 23 Feb 2021 13:40:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YuosJuj0Ine19kJ3NJSeUlk7eBnwf/8g8zhUhQS2B3AqLwZYnsWRHp9P/Rr0DiHeRH3oGAtmWbz3Wh4aAP5IWDIEsxCNdQva9zruI7ImDjeN4xcC27b59LHJfKK26JLn9niuPBJHrSkQXFjdHoo8PN0cMemiHck6705gV0ZNzML1nk31OmgBompJJyJeXtRVfjJ3+GnBCiqTmVW5C0c1yQ8tpiG6dhHlYVTAbg26e3rQzBJjFI/tmgra9N6/IHCtUweJa8Lzjs+JkZ2bZS19dWmGQHqx3cYRnSXIUWWCdEwePVTCN6WaWdKdL5qRHuE4a8Q4M907VaiL9n9OBJRkwA== 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=HbjswZGaaiYh759ZCB4usucPC739F0wTPLNvCw/IDC0=; b=a+iJ/WqwGQxbxxotgcOZlEdah8I9agzJDXoGyW241wq/1uIGnJB7upD8NQDj8V7O7q4LAs78gJSF/qs9NrPe3ZyewYTo6/lCkc3gu1cS5O2B/XzGlnBSUzcSBDwXeEY3yl1F8NWujvm7/LGB+KjiMO5upfJekXF1QBZwIw2vMBA+cyA/e37eYHR24m2BMVnc1Y6QqlXu/W3neVLaTA+D8CiBL8GyJ72qpBQvjFKe/ioMcRgFALBfmBcLkNZ0Ij4vxVS6HN/3APRhjOuKPeh4c5MbKq3gqXYlHlh8FerO4iKCmIz5GvFcJGr6Flhvt2zj+0TGuoo3Y/6zFH67M3DsCA== 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=HbjswZGaaiYh759ZCB4usucPC739F0wTPLNvCw/IDC0=; b=ueIUykOKe0lQnM9vcOwn1zxke4JBU8rcWZGxVged6wHDSAWzXR3E3EEhVijl91MDF/0pmt081r1fs3r2BUYsLu2A4TFfHYNUvYHC1vtmZIDt0BCK52dBlVAQnNA9wWbAIRkLjKLQ7Xce4Uw2yXDa5crbUhp458+bOH7LbP6qlMk= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BYAPR04MB6247.namprd04.prod.outlook.com (2603:10b6:a03:ea::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.29; Tue, 23 Feb 2021 21:40:00 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681%6]) with mapi id 15.20.3868.033; Tue, 23 Feb 2021 21:40:00 +0000 From: Eugene Christensen To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/wQsHqqNWyK+TUibK61/n15TnKpmSlEg Date: Tue, 23 Feb 2021 21:40:00 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <61A511CA-5EF9-4938-B77E-B9A4CB8FCA77@brianrosen.net> In-Reply-To: <61A511CA-5EF9-4938-B77E-B9A4CB8FCA77@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-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3b7f2ca3-b3cc-49be-e004-08d8d843929c x-ms-traffictypediagnostic: BYAPR04MB6247: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aGiMdZNQWlBG7nT+YnlK4lyMwCmeSJur0eoo1htpQBpoFrHJJ9d/o9ROBSI0igcdhUuYQvNF3H2LzOHy3RkIKWxtrsDqapqzGpfOoYDmky1dmLUAhvvQXMm6Eu1rHuxzgXUf+YVCd7wD2LNJldLKlgLBrhChGTOZlNEOAzI4Vbj5GxgzoCOvITigAXU0T9Q23TgYoSaXAZWvw1eZfm4Nzgl6dTYzGcz5oneN1lwYzrWTL1sO6Kqc3uPUIcowvEm1f1sde0cWt5MkfNiytAW53lOU+kXNhZp9oLT/pT3Nadx262bIkqDubqfsJ4UhJfFKgRkM5YfN6JEXz44QBkIbpHcQGw2K22bGC/rThkxgzHXe7BaG15SpBMNRaDjY1ekHCZVryXvXAQYNRx9JDkZ21OaDqxQ621n94Th7QEUToeU/R0Z+HHVR57y1zM8KqYQ6AwvIvbJMWgVY9MADnxwjtHybtXuFdeq/Az+1hw0pb94R02CyydTnJFmgP1heuay1VqMing4vBUeNcMA8/v1I26j6pFPmt0JOKuErflukA0FMSuNU5LBUeWPNaUC47NfWgYfpg8j3EaYDSb6vh5t9NpezPSr1zuC83J7I29VoagQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(376002)(346002)(39850400004)(136003)(55016002)(9686003)(71200400001)(6916009)(33656002)(316002)(4326008)(53546011)(6506007)(478600001)(83380400001)(966005)(2906002)(66574015)(5660300002)(7696005)(166002)(52536014)(76116006)(8936002)(8676002)(26005)(66446008)(66946007)(64756008)(186003)(66556008)(66476007)(18074004)(21615005)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?eWJjMEJzNHQ5a1ZWdGRIeVQ4bUhvellNUitGcU5zZlY4SFV0Vk1FbGl2bDhF?= =?utf-8?B?RTcyQmtkcnc3ckN4bFd0UDZSeFpDVWJQSE1wQ2hRbldMNml4VG1YTjc4V0tX?= =?utf-8?B?QlJmNnBjMlllcUUxcHlxUXBnazFLTUZoRE8yb1ZHRUF2NW1ZUytJOGcyY1lt?= =?utf-8?B?UjQ0S29Hc25wakx3c294SDU2QmpSUS9GZEZvRzBGL1FjQmJ4ODVydFUwaTZn?= =?utf-8?B?WDhCclNYZDBxRXprNFhJVEZrc0E2dWhKbTBaM1ZMOGwyVlNhZnpwQnBMamo0?= =?utf-8?B?U2JYS0ZhSERyQTZqR2RvaW5BZ0lpeWFWUEliTkdUZlRpdHdqODZzOXF2Tm5J?= =?utf-8?B?OEtmVTFQR2lISDIyaTROQitNZ2NqUUlkNk15bzIxblpGc1V6TzdPYlBhb0pU?= =?utf-8?B?QlQ4VG5icmJSaEZPMjdnTFEyekJkdXViQnlobWx2a1h5YzZiNFU0dHdhVFN3?= =?utf-8?B?VENIc3RQOStSa2REaU11aThMSkRiK1BtYlZiS2g3L09yNENzNVArTjFMVEF4?= =?utf-8?B?bFZOamd3bDkvQW42a0lCSDhyWFFPenJ6dVpoMVZLbC8xMnVtOVY3QWMxL1lS?= =?utf-8?B?S2N5RnlZWG9hc3dqZEF4VjhxWnNkZTFTWHFON2dIMGRQSUpOMHBGL2ZxYTdS?= =?utf-8?B?M1U4V3FJbmtyNXRQMHd4QnYrNDlvUDBnWlMxOHVyWmpkUVR6K1NXd2svY081?= =?utf-8?B?QmM3NStZMjIrbi90cmVZMFhicy9nZmF6cTZFV3l4VXNYNFZISEJjSEhEc1Ji?= =?utf-8?B?d2tpeGliaC83RmoxcHVFN3JSeXlUbjgvdEZ5bitCL2tGWG0xd05OTjJrRDds?= =?utf-8?B?WnpHUDlQcTM3N2RaMDR2MUJDWWc0L0NOUmJva20zckM2ejJ3NXhDOHJsbTBG?= =?utf-8?B?eGhuclNjWGRZdXoxOEZJUVU2aVk2V3lXc0tWVFd3VHA4RzBjaEQvMTBjTmFW?= =?utf-8?B?OFE0VTBGUW9aSm5YV2VOcXkvajhpcGUzaDNkVU9YcVlhNVRsUGlzU3FMNG5l?= =?utf-8?B?MmM0L01Rd3paTUJkTnhmMWJ5VDdXbC9veVRRYUp1NmkyNmYxQ2lMOUIxZlpK?= =?utf-8?B?WVovK3JIRHRad1M2TDB4S2hPZEdOVUxRQ3VmR3RtRHZRRzk1ZFRhb2ZUNjRi?= =?utf-8?B?RTZ4K21UeFBQNGNTdktTcHhjWm9HSlFrWlN2ZXlldmFkd2U2ZC9rdHdYNlRk?= =?utf-8?B?R1FpVjMzNjUzVFhUQlE1b25pdTBNc0tWRjlycnY2Q0tpYWZnejFDYlI0Smp5?= =?utf-8?B?M0lSc1dTQmovOXZaZ0QvZnhTaWFXeXNiWjQwb0NPeURIb2pQMS9BUDBOWU14?= =?utf-8?B?SG1ySDV5a01rV0RsVzBic3ZneHozS1EzTHN0b1Myc29VcTg0bjdKK1djVW9D?= =?utf-8?B?WmFIYXBHNktCV25XTVdDdC9VWUdKMlprUkl5TlZKUDV4T01jSldpMlZXSkpN?= =?utf-8?B?Z3JBamtrQ0FDMEY4djRJV05iRHE4cmQ5c1hhdm9rSnoxakpFdVlUdHhWUHFy?= =?utf-8?B?K05FeW9OZEU4TGtOVG9WRnJRZGZ4U3NydGVDcWtSbkdlUHJzSC9FdkdJTG5o?= =?utf-8?B?T2Juck51aXJqZm5ISk54MmFVN1VGU1k3dktQbHRVZ1VvdjBDMnE3OTl4aVdk?= =?utf-8?B?b1hwcHlCT0k4U1VpZ3dJektYQ3VlOTZqRmNwUkU4ZGIrWjdWOURyT1djYjdv?= =?utf-8?B?VkV3ZWxJd2tSb0VxNGZudXhRdHlVU3ZVbHB6amlqSWhGcy81ZnBncEV0THJ0?= =?utf-8?Q?nPzqFUZeC2xEw3JAjuJbF52yGNKaH4TFtDg5asV?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR04MB4983BAF92D02082D6D0ACF86A3809BYAPR04MB4983namp_" MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b7f2ca3-b3cc-49be-e004-08d8d843929c X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 21:40:00.6388 (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: P/DU2ltUic4o3f6IOWziLFlpPQguU9FzTCXmj69aZ9Etg3YtRgJTmCpTTSQJAODn33iI6YBqZ3p0Ii0iVPcplJQn2ubwPYV5qrjuBwKpz9Y= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB6247 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 21:40:13 -0000 --_000_BYAPR04MB4983BAF92D02082D6D0ACF86A3809BYAPR04MB4983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmsgeW91IEJyaWFuIGFuZCBQYXVsIGZvciB5b3VyIHJlc3BvbnNlcy4NCg0KUmVnYXJkaW5n IElQdjQvSVB2NiwgSSBjYW4gc2VlIHlvdXIgcG9pbnQgdGhhdCBhIHBhdGggZm9yd2FyZCBpcyBu ZWVkZWQgZHVlIHRvIHRoZSBkaW1pbmlzaGluZyBhdmFpbGFiaWxpdHkgb2YgSVB2NCBhZGRyZXNz ZXMuICBUaGFua3MgUGF1bCBmb3IgcG9pbnRpbmcgb3V0IHRoYXQgdGhlIElQdjYgcmVxdWlyZW1l bnQgd291bGQgYmUgb24gdGhlIFJVRSBvbmx5IGFuZCBzZXJ2ZXJzIGNhbiBjb250aW51ZSB0byBy dW4gb24gZWl0aGVyL2JvdGggKHdpdGggYSBnYXRld2F5IGlmIG5lY2Vzc2FyeSkuICBUaGlzIHNv dW5kcyBsaWtlIGFuIGFwcHJvcHJpYXRlIGFwcHJvYWNoLg0KDQpSZWdhcmRpbmcgc2VjdGlvbiA5 LjIgYW5kIHRoZSB2ZXR0aW5nIG9mIG5ldyB1c2Vycywgd2hlbiBJIHJlYWQgdGhyb3VnaCBpdCBp bml0aWFsbHksIG15IGFzc3VtcHRpb24gd2FzIHRoYXQgdGhlIHByb2Nlc3Mgd2FzIG9uZSB0aGF0 IHdvdWxkIGJlIGNvbXBsZXRlZCBpbiByZWFsIHRpbWUuICBJdCBzb3VuZHMgbGlrZSB0aGF0IG11 c3Qgbm90IGJlIHRoZSBpbnRlbnQuICBJIHdvbmRlciBpZiBpdCBtaWdodCBiZSBoZWxwZnVsIHRv IGhhdmUgc29tZXRoaW5nIHRoYXQgY2FsbHMgdGhhdCBvdXQ7IHRoYXQgaXQgaXNu4oCZdCBpbnRl bmRlZCB0byBiZSBzeW5jaHJvbm91cyBmb3IgYSBuZXcgdXNlciBidXQgcmF0aGVyIHRoYXQgaXQg cHJvdmlkZXMgYSBzdGFydGluZyBwb2ludCBmb3IgZ2V0dGluZyByZWdpc3RlcmVkIHdpdGggdGhl IHByb3ZpZGVyPw0KDQpCVFcsIHRoYW5rIHlvdSBmb3IgYWRkaW5nIHRoYXQgYW4gQVBJIGtleSBN QVkgYmUgdXNlZC4NCg0KRXVnZW5lLg0KDQoNCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFLiBU aGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBhbnkgZG9jdW1lbnRzLCBmaWxlcyBvciBwcmV2 aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0 IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlz IFNUUklDVExZIFBST0hJQklURUQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNz aW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1lIGJ5IHJlcGx5IGUtbWFp bCBhdCBlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5z b24uY29tPiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksIGFuZCBkZXN0cm95 IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50cyB3aXRob3V0IHJl YWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KDQpGcm9tOiBCcmlhbiBSb3NlbiA8 YnJAYnJpYW5yb3Nlbi5uZXQ+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA5LCAyMDIxIDk6NTQg QU0NClRvOiBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20+DQpD YzogcnVtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1J1bV0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1ydW0tcnVlLTA0LnR4dA0KDQpbRVhURVJOQUxdDQoNCg0KDQoNCk9uIEZlYiA5LCAyMDIxLCBh dCAxMToyNyBBTSwgRXVnZW5lIENocmlzdGVuc2VuIDxlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29t PG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPj4gd3JvdGU6DQoNCkhpIEJyaWFuLA0K DQpJIGhhdmUgYSBmZXcgdGhvdWdodHMgb24gdGhpcyBhbmQgYSBmZXcgdHlwb3MgdGhhdCBJ4oCZ bGwgcG9pbnQgb3V0Lg0KDQpTdWJzdGFuY2UgQ29tbWVudHMNCg0KICAqICAgU2VjdGlvbiA0OiBS ZXF1aXJlbWVudCBmb3IgSVB2NCBhbmQgSVB2Ni4gIFdoeSBpcyBJUHY2IG5vdyBhIHJlcXVpcmVt ZW50PyAgV2h5IG5vdCBvcHRpb25hbD8NCkJlY2F1c2UgdGhlIHdvcmxkIGhhcyBtb3ZlZCBvbiwg dGhlcmUgYXJlIG5vIG1vcmUgSVB2NCBhZGRyZXNzZXMsIG1hbnkgbmV0d29ya3MgYXJlIElQdjYg b25seSBub3csIGFuZCB3ZSBuZWVkIGEgZ29vZCByZWFzb24gdG8gbm90IHJlcXVpcmUgaXQgaW4g dGhlIElFVEYuDQoNCg0KICAqDQogICogICBTZWN0aW9uIDkuMiAtIFRoZSB2ZXR0aW5nIHByb2Nl c3MgZm9yIGEgcG90ZW50aWFsIGN1c3RvbWVyIGRvZXMgbm90IGxlbmQgaXRzZWxmIHRvIGEgcGVy c29uIGJlaW5nIGFibGUgdG8gc2ltcGx5IHNpZ24gdXAgbGlrZSB0aGlzLiAgVGhlIGN1c3RvbWVy IHdpbGwgYmUgcmVxdWlyZWQgdG8gaGF2ZSBhbiBhY2NvdW50IGJlZm9yZSBiZWluZyBhYmxlIHRv IGNvbW11bmljYXRlIHdpdGggdGhlIHByb3ZpZGVyIHNlcnZpY2UuICBJIHRoZXJlZm9yZSBiZWxp ZXZlIHdlIHNob3VsZCByZW1vdmUgdGhlIGFiaWxpdHkgZm9yIHRoZSBSVUUgZGV2aWNlIHRvIGNv bW11bmljYXRlIHdpdGggdGhlIHByb3ZpZGVyIHdpdGhvdXQgYSB1c2VyaWQvcGFzc3dvcmQuDQpU aGUgcHJvY2VzcyBoYXMgdG8gc3RhcnQgc29tZSBob3cgdGhhdCBkb2VzbuKAmXQgaW52b2x2ZSBh IHBob25lIGNhbGwuICBUYWtlIGEgcmVhbGx5IHNpbXBsZSBleGFtcGxlOiBJ4oCZbSBkZWFmLCBJ IGhhdmUgYW4gYWNjb3VudCB3aXRoIHByb3ZpZGVyIFgsIEkgd2FudCB0byBlc3RhYmxpc2ggYW5v dGhlciBhY2NvdW50IHdpdGggcHJvdmlkZXIgWS4gIENhbuKAmXQgSSBkbyB0aGF0IHdpdGggYSB3 ZWJzaXRlPyAgQ2FuIEkgZ2V0IGhlbHAgdmlhIGEgdmlkZW9waG9uZT8gIFRoZSB3YXkgaXTigJlz IGN1cnJlbnRseSBkZWZpbmVkIGFsbCB0aGF0IGhhcHBlbnMgaXMgeW91IGdldCBhIFVSSSBmb3Ig dGhlIHdlYnNpdGUgYW5kIGFub3RoZXIgZm9yIGEgaGVscCBkZXNrLiAgWW91IGRvbuKAmXQgZ2V0 IGFueXRoaW5nIG91dCBvZiBpdC4gIFdoZW4gYWxsIHRoZSB2ZXR0aW5nIGlzIGZpbmlzaGVkLCB5 b3UgZW5kIHVwIHdpdGggYSB1c2VyaWQgYW5kIHBhc3N3b3JkLCBhbmQgeW91IG1hbnVhbGx5IGVu dGVyIHRoYXQgaW50byB0aGUgUlVFLiAgV2hhdCBhbSBJIG1pc3Npbmc/DQoNCg0KICAqDQogICog ICBTZWN0aW9uIDkuMiAtIEluIHRoZSBzZWN0aW9uIGZvciB0aGUgcGF5bG9hZCwgaXQgaXMgbWlz c2luZyB0aGUgcHJvdmlkZXItZG9tYWluIGluIHRoZSB0ZXh0IHNlY3Rpb24gYnV0IGl0IGlzIGlu Y2x1ZGVkIGluIHRoZSBleGFtcGxlLiAgSSBleHBlY3QgdGhpcyBpcyBzaW1wbHkgYW4gb3ZlcnNp Z2h0Lg0KSXTigJlzIHRoZSBkb21haW4gaW4gdGhlIHByb3ZpZGVyLWxpc3QuICBJIGNhbiBtYWtl IHRoYXQgY2xlYXJlcg0KDQoNCiAgKg0KDQpUeXBvIENvbW1lbnRzDQpUaGFua3MgZm9yIHRoZXNl LCBJ4oCZbGwgZml4IHRoZW0NCg0KDQogICogICBTZWN0aW9uIDUuNSwgIFJlbW92ZSByZWR1bmRh bnQgInRoYXQiIGZyb20gZmlyc3Qgc2VudGVuY2UgInRoYXQgdGhhdCINCiAgKiAgIFNlY3Rpb24g OSwgIDJuZCBzZW50ZW5jZSByZWFkcyBhd2t3YXJkbHkuICBQZXJoYXBzIGNoYW5nZSB0byAiT25l IHByb3ZpZGVzIGEgZGlyZWN0b3J5IG9mIHByb3ZpZGVycyBzbyB0aGF0IGEgdXNlciBpbnRlcmZh Y2UgYWxsb3dzIGVhc3kgcHJvdmlkZXIgc2VsZWN0aW9uIC4uLiINCiAgKiAgIFNlY3Rpb24gOS4x LCBnZXQgcmlkIG9mIGV4dHJhICJhIiBpbiB0aGUgc2VjdGlvbiAiLi4uYSBjb3VudHJ5IGNvZGUg c3VpdGFibGUgZm9yIGRpc3BsYXksIHdpdGggYSBjb3JyZXNwb25kaW5nICJhIiBVUkkgLi4uDQog ICogICBTZWN0aW9uIDkuMiwgZ2V0IHJpZCBvZiBleHRyYSAidGhlIiBpbiB0aGUgZmlyc3Qgc2Vu dGVuY2UgIi4uLnByb3ZpZGVyIGNvbmZpZ3VyYXRpb24gInRoZSIgdXNpbmcgYSBzaW1wbGUuLi4i DQogICogICBTZWN0aW9uIDkuNCAtIEdldCByaWQgb2YgdGhlIHJlZHVuZGFudCB3b3JkICJTZWN0 aW9ucyIgaW4gdGhlIGZpcnN0IHNlbnRlbmNlICJUaGUgaW50ZXJmYWNlcyBpbiAiU2VjdGlvbnMi IFNlY3Rpb24gOS4xIC4uLiINCg0KDQpUaGFua3MuDQoNCkV1Z2VuZSBDaHJpc3RlbnNlbi4NCg0K Q09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55 IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVkIHRv IGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9u LiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBhIHBlcnNvbiByZXNw b25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3Ug YXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLCBkaXN0cmli dXRpb24gb3IgdXNlIG9mIGFueSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIG9yIGF0 dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBQUk9ISUJJVEVELiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5 IG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQgZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTxt YWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbT4gb3IgYnkgdGVsZXBob25lIGF0ICsxICg4 MDEpIDI4Ny05NDE5LCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBp dHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlz ay4NCg0KRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnVtLWJvdW5jZXNA aWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NClNlbnQ6IEZyaWRheSwgRmVicnVh cnkgNSwgMjAyMSAzOjI3IFBNDQpUbzogcnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbUnVtXSBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNC50 eHQNCg0KW0VYVEVSTkFMXSBJIGhhdmUgcG9zdGVkIGEgLTA0IHJldmlzaW9uLiAgVGhpcyBzaG91 bGQgaGFuZGxlIGFsbCBjb21tZW50cyByZWNlaXZlZCBzbyBmYXIsIHBsZWFzZSBsZXQgbWUga25v dyBpZiBJIGZvcmdvdCBzb21ldGhpbmcuDQoNClRoaXMgdmVyc2lvbiByZXdvcmtzIHRoZSBwcm92 aWRlciBsaXN0IGFuZCBjb25maWd1cmF0aW9uIHNlY3Rpb25zIGFsb25nIHRoZSBsaW5lcyB3ZSBo YXZlIGJlZW4gZGlzY3Vzc2luZy4NCg0KSSBkbyBub3QgaGF2ZSBhIHdheSB0byBkb3dubG9hZCBh IHVzZXJuYW1lL3Bhc3N3b3JkIGZyb20gYSBuZXcgc2lnbnVwLiAgSeKAmW0gaGF2aW5nIHRyb3Vi bGUgdGhpbmtpbmcgYWJvdXQgYSBzZWN1cmUgd2F5IHRvIGRvIHRoYXQuICBJZiBhbnlvbmUgaGFz IGFuIGlkZWEsIEnigJltIHZlcnkgd2lsbGluZyB0byB3cml0ZSB0ZXh0IGZvciBpdC4gIEnigJl2 ZSBjb25zaWRlcmVkIHRoaW5ncyBsaWtlIGphdmFzY3JpcHQgdGhhdCBzdGFzaGVzIGl0IGluIGEg ZmlsZSBvciBzb21ld2hlcmUgZWxzZSwgaGF2aW5nIHNvbWUgd2ViIHBhZ2UgZnVuY3Rpb24gdGhh dCB0cmlnZ2VycyBhIGxvY2FsIGRpc3BsYXkgb2YgYW4gZW50cnkgZm9ybSBmb3IgdXNlcm5hbWUg YW5kIHBhc3N3b3JkLCBhbmQgYSBjb3VwbGUgb2Ygb3RoZXIgdGhpbmdzLg0KDQpPbmUgbm90ZSBv biB0aGUgY29uZmlndXJhdGlvbiBtZWNoYW5pc20gLSBiZWNhdXNlIHRoZSBvbmx5IHRoaW5nIHRo ZSBsb2NhbCBSVUUgZGV2aWNlIG5lZWRzIHRvIGtlZXAgaXMgdGhlIHVzZXJuYW1lIHBhc3N3b3Jk IGFnYWluc3QgYSBwcm92aWRlciBJRCBvZiBzb21lIGtpbmQsIHRoZXJlIGlzbuKAmXQgYW55IG5l ZWQgdG8gc3RhbmRhcmRpemUgaG93IHRoYXQgd29ya3MsIGFuZCBzbyBpdOKAmXMgY29tcGxldGVs eSBhYnNlbnQgaW4gdGhlIHRleHQuDQoNCkZvciBub3csIEnigJl2ZSByZW1vdmVkIHRoZSBzdGVw IGJ5IHN0ZXAgZGlhZ3JhbSB0aGF0IHNob3dlZCBob3cgdGhlIGNvbmZpZyBtZWNoYW5pc20gaXMg dXNlZC4gIEkgdGhpbmsgd2hhdCBpcyB0aGVyZSBpcyBkZWFkIHNpbXBsZSBhbmQgbmVlZHMgbm8g ZXhwbGFuYXRpb246IGl04oCZcyBhIHN0cmFpZ2h0Zm9yd2FyZCBSRVNUL0pTT04gd2ViIHNlcnZp Y2UgdXNpbmcgdXNlcm5hbWUvcGFzc3dvcmQgYXV0aGVudGljYXRpb24gZm9yIHByb3ZpZGVycyB0 aGUgdXNlciBoYXMgYWNjb3VudHMgd2l0aC4gIEkgY2FuIGJyaW5nIGJhY2sgdGhlIGRpYWdyYW0g aWYgdGhhdCBpcyBuZWVkZWQuDQoNCkJyaWFuDQoNCg0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNz YWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0w NC50eHQNCkRhdGU6IEZlYnJ1YXJ5IDUsIDIwMjEgYXQgNToxNzoxNSBQTSBFU1QNClRvOiA8aS1k LWFubm91bmNlQGlldGYub3JnPG1haWx0bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6IHJ1 bUBpZXRmLm9yZzxtYWlsdG86cnVtQGlldGYub3JnPg0KUmVwbHktVG86IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPiwgcnVtQGlldGYub3Jn PG1haWx0bzpydW1AaWV0Zi5vcmc+DQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxh YmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBk cmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZSBJ RVRGLg0KDQogICAgICAgVGl0bGUgICAgICAgICAgIDogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxl IGZvciBSZWxheSBVc2VyIEVxdWlwbWVudA0KICAgICAgIEF1dGhvciAgICAgICAgICA6IEJyaWFu IFJvc2VuDQogICAgICAgICAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1ydW0t cnVlLTA0LnR4dA0KICAgICAgICAgICAgICAgIFBhZ2VzICAgICAgICAgICA6IDMzDQogICAgICAg ICAgICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAyMS0wMi0wNQ0KDQpBYnN0cmFjdDoNCiAgVmlk ZW8gUmVsYXkgU2VydmljZSAoVlJTKSBpcyBhIHRlcm0gdXNlZCB0byBkZXNjcmliZSBhIG1ldGhv ZCBieQ0KICB3aGljaCBhIGhlYXJpbmcgcGVyc29ucyBjYW4gY29tbXVuaWNhdGUgd2l0aCBkZWFm L0hhcmQgb2YgSGVhcmluZw0KICB1c2VyIHVzaW5nIGFuIGludGVycHJldGVyICgiQ29tbXVuaWNh dGlvbnMgQXNzaXN0YW50IikgY29ubmVjdGVkIHZpYQ0KICBhIHZpZGVvcGhvbmUgdG8gdGhlIGRl YWYvSG9IIHVzZXIgYW5kIGFuIGF1ZGlvIHRlbGVwaG9uZSBjYWxsIHRvIHRoZQ0KICBoZWFyaW5n IHVzZXIuICBUaGUgQ0EgaW50ZXJwcmV0cyB1c2luZyBzaWduIGxhbmd1YWdlIG9uIHRoZQ0KICB2 aWRlb3Bob25lIGxpbmsgYW5kIHZvaWNlIG9uIHRoZSB0ZWxlcGhvbmUgbGluay4gIE9mdGVuIHRo ZQ0KICBpbnRlcnByZXRlcnMgbWF5IGJlIHN1cHBsaWVkIGJ5IGEgY29tcGFueSBvciBhZ2VuY3kg dGVybWVkIGENCiAgInByb3ZpZGVyIiBpbiB0aGlzIGRvY3VtZW50LiAgVGhlIHByb3ZpZGVyIGFs c28gcHJvdmlkZXMgYSB2aWRlbw0KICBzZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5l Y3QgdmlkZW8gZGV2aWNlcyB0byB0aGVpciBzZXJ2aWNlLA0KICBhbmQgc3Vic2VxdWVudGx5IHRv IENBcyBhbmQgb3RoZXIgZGVhZi9Ib0ggdXNlcnMuICBJdCBpcyBkZXNpcmFibGUNCiAgdGhhdCB0 aGUgdmlkZW9waG9uZXMgdXNlZCBieSB0aGUgZGVhZi9Ib0gvSC1JIHVzZXIgY29uZm9ybSB0byBh DQogIHN0YW5kYXJkIHNvIHRoYXQgYW55IGRldmljZSBtYXkgYmUgdXNlZCB3aXRoIGFueSBwcm92 aWRlciBhbmQgdGhhdA0KICB2aWRlbyBjYWxscyBkaXJlY3QgYmV0d2VlbiBkZWFmL0hvSCB1c2Vy cyB3b3JrLiAgVGhpcyBkb2N1bWVudA0KICBkZXNjcmliZXMgdGhlIGludGVyZmFjZSBiZXR3ZWVu IGEgdmlkZW9waG9uZSBhbmQgYSBwcm92aWRlci4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBz dGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtcnVtLXJ1ZS8NCg0KVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNp b24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1p ZXRmLXJ1bS1ydWUtMDQuaHRtbA0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBp cyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt aWV0Zi1ydW0tcnVlLTA0DQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlz dA0KSS1ELUFubm91bmNlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFk b3ctc2l0ZXMudHh0DQoNCg== --_000_BYAPR04MB4983BAF92D02082D6D0ACF86A3809BYAPR04MB4983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo3MTU3NDA5NzU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIzNTI2NzMwO30NCkBsaXN0 IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6ODYwNzc5MTI5Ow0KCW1zby1saXN0LXRlbXBsYXRl LWlkczotOTU2NzgyMTg2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MTQzOTEw ODIyMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE1MDQyNDY4MDt9DQpAbGlzdCBsMjpsZXZl bDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwzDQoJe21zby1saXN0LWlkOjE3NDUyOTU3OTM7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x MTQ0ODc0NDk4O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MjA4OTQ1MDU4MjsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTY4NDAzMTEwODt9DQpAbGlzdCBsNDpsZXZlbDENCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDox LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9s O30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVs Nw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdp bi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlk bWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0 YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxi b2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQ7LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlO2xpbmUtYnJlYWs6YWZ0ZXIt d2hpdGUtc3BhY2UiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoYW5rIHlvdSBCcmlhbiBhbmQgUGF1bCBmb3IgeW91ciByZXNwb25zZXMuJm5ic3A7 IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgSVB2NC9JUHY2LCBJIGNhbiBzZWUg eW91ciBwb2ludCB0aGF0IGEgcGF0aCBmb3J3YXJkIGlzIG5lZWRlZCBkdWUgdG8gdGhlIGRpbWlu aXNoaW5nIGF2YWlsYWJpbGl0eSBvZiBJUHY0IGFkZHJlc3Nlcy4mbmJzcDsgVGhhbmtzIFBhdWwg Zm9yIHBvaW50aW5nIG91dCB0aGF0IHRoZSBJUHY2IHJlcXVpcmVtZW50IHdvdWxkIGJlIG9uIHRo ZSBSVUUgb25seSBhbmQgc2VydmVycyBjYW4gY29udGludWUgdG8NCiBydW4gb24gZWl0aGVyL2Jv dGggKHdpdGggYSBnYXRld2F5IGlmIG5lY2Vzc2FyeSkuJm5ic3A7IFRoaXMgc291bmRzIGxpa2Ug YW4gYXBwcm9wcmlhdGUgYXBwcm9hY2guPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZGlu ZyBzZWN0aW9uIDkuMiBhbmQgdGhlIHZldHRpbmcgb2YgbmV3IHVzZXJzLCB3aGVuIEkgcmVhZCB0 aHJvdWdoIGl0IGluaXRpYWxseSwgbXkgYXNzdW1wdGlvbiB3YXMgdGhhdCB0aGUgcHJvY2VzcyB3 YXMgb25lIHRoYXQgd291bGQgYmUgY29tcGxldGVkIGluIHJlYWwgdGltZS4mbmJzcDsgSXQgc291 bmRzIGxpa2UgdGhhdCBtdXN0IG5vdCBiZSB0aGUgaW50ZW50LiZuYnNwOyBJIHdvbmRlciBpZiBp dCBtaWdodCBiZQ0KIGhlbHBmdWwgdG8gaGF2ZSBzb21ldGhpbmcgdGhhdCBjYWxscyB0aGF0IG91 dDsgdGhhdCBpdCBpc27igJl0IGludGVuZGVkIHRvIGJlIHN5bmNocm9ub3VzIGZvciBhIG5ldyB1 c2VyIGJ1dCByYXRoZXIgdGhhdCBpdCBwcm92aWRlcyBhIHN0YXJ0aW5nIHBvaW50IGZvciBnZXR0 aW5nIHJlZ2lzdGVyZWQgd2l0aCB0aGUgcHJvdmlkZXI/PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJUVywgdGhhbmsgeW91IGZvciBhZGRpbmcgdGhhdCBhbiBBUEkga2V5IE1BWSBiZSB1c2VkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdWdlbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6bmF2eSI+Q09ORklE RU5USUFMSVRZIE5PVElDRS48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpuYXZ5Ij4gVGhp cyBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3INCiBwcmV2 aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0 IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQg YW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQogZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2Yg dGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2Ug aXMgU1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1t YWlsIGF0DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZiI+ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOm5hdnkiPiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTks DQogYW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1l bnRzIHdpdGhvdXQgcmVhZGluZyB0aGVtIG9yIHNhdmluZyB0aGVtIHRvIGRpc2suPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+ IEJyaWFuIFJvc2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDsgPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIEZlYnJ1YXJ5IDksIDIwMjEgOTo1NCBBTTxicj4NCjxiPlRvOjwvYj4gRXVnZW5l IENocmlzdGVuc2VuICZsdDtlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gcnVtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUnVtXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bRVhURVJOQUxdPC9zcGFuPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0K PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGZWIgOSwg MjAyMSwgYXQgMTE6MjcgQU0sIEV1Z2VuZSBDaHJpc3RlbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iPmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkhpIEJyaWFuLDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBoYXZlIGEgZmV3IHRob3VnaHRzIG9uIHRoaXMgYW5kIGEgZmV3IHR5cG9zIHRoYXQgSeKAmWxs IHBvaW50IG91dC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+U3Vic3RhbmNlIENvbW1lbnRzPC9iPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEiPg0KU2VjdGlvbiA0OiBSZXF1aXJlbWVudCBmb3IgSVB2 NCBhbmQgSVB2Ni4mbmJzcDsgV2h5IGlzIElQdjYgbm93IGEgcmVxdWlyZW1lbnQ/Jm5ic3A7IFdo eSBub3Qgb3B0aW9uYWw/PG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2UgdGhlIHdvcmxkIGhhcyBtb3ZlZCBvbiwg dGhlcmUgYXJlIG5vIG1vcmUgSVB2NCBhZGRyZXNzZXMsIG1hbnkgbmV0d29ya3MgYXJlIElQdjYg b25seSBub3csIGFuZCB3ZSBuZWVkIGEgZ29vZCByZWFzb24gdG8gbm90IHJlcXVpcmUgaXQgaW4g dGhlIElFVEYuPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDMgbGV2ZWwx IGxmbzIiPg0KPG86cD4mbmJzcDs8L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibWFyZ2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDMgbGV2ZWwx IGxmbzIiPg0KU2VjdGlvbiA5LjIgLSBUaGUgdmV0dGluZyBwcm9jZXNzIGZvciBhIHBvdGVudGlh bCBjdXN0b21lciBkb2VzIG5vdCBsZW5kIGl0c2VsZiB0byBhIHBlcnNvbiBiZWluZyBhYmxlIHRv IHNpbXBseSBzaWduIHVwIGxpa2UgdGhpcy4mbmJzcDsgVGhlIGN1c3RvbWVyIHdpbGwgYmUgcmVx dWlyZWQgdG8gaGF2ZSBhbiBhY2NvdW50IGJlZm9yZSBiZWluZyBhYmxlIHRvIGNvbW11bmljYXRl IHdpdGggdGhlIHByb3ZpZGVyIHNlcnZpY2UuJm5ic3A7IEkgdGhlcmVmb3JlIGJlbGlldmUNCiB3 ZSBzaG91bGQgcmVtb3ZlIHRoZSBhYmlsaXR5IGZvciB0aGUgUlVFIGRldmljZSB0byBjb21tdW5p Y2F0ZSB3aXRoIHRoZSBwcm92aWRlciB3aXRob3V0IGEgdXNlcmlkL3Bhc3N3b3JkLjxvOnA+PC9v OnA+PC9saT48L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGUgcHJvY2VzcyBoYXMgdG8gc3RhcnQgc29tZSBob3cgdGhhdCBkb2VzbuKAmXQgaW52b2x2 ZSBhIHBob25lIGNhbGwuICZuYnNwO1Rha2UgYSByZWFsbHkgc2ltcGxlIGV4YW1wbGU6IEnigJlt IGRlYWYsIEkgaGF2ZSBhbiBhY2NvdW50IHdpdGggcHJvdmlkZXIgWCwgSSB3YW50IHRvIGVzdGFi bGlzaCBhbm90aGVyIGFjY291bnQgd2l0aCBwcm92aWRlciBZLiAmbmJzcDtDYW7igJl0IEkgZG8g dGhhdCB3aXRoIGEgd2Vic2l0ZT8gJm5ic3A7Q2FuDQogSSBnZXQgaGVscCB2aWEgYSB2aWRlb3Bo b25lPyAmbmJzcDtUaGUgd2F5IGl04oCZcyBjdXJyZW50bHkgZGVmaW5lZCBhbGwgdGhhdCBoYXBw ZW5zIGlzIHlvdSBnZXQgYSBVUkkgZm9yIHRoZSB3ZWJzaXRlIGFuZCBhbm90aGVyIGZvciBhIGhl bHAgZGVzay4gJm5ic3A7WW91IGRvbuKAmXQgZ2V0IGFueXRoaW5nIG91dCBvZiBpdC4gJm5ic3A7 V2hlbiBhbGwgdGhlIHZldHRpbmcgaXMgZmluaXNoZWQsIHlvdSBlbmQgdXAgd2l0aCBhIHVzZXJp ZCBhbmQgcGFzc3dvcmQsIGFuZCB5b3UNCiBtYW51YWxseSBlbnRlciB0aGF0IGludG8gdGhlIFJV RS4gJm5ic3A7V2hhdCBhbSBJIG1pc3Npbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w cHQiPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxp IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjttYXJnaW4tYm90dG9t OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjttYXJnaW4tYm90dG9t OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQpTZWN0aW9uIDkuMiAtIEluIHRoZSBzZWN0 aW9uIGZvciB0aGUgcGF5bG9hZCwgaXQgaXMgbWlzc2luZyB0aGUgcHJvdmlkZXItZG9tYWluIGlu IHRoZSB0ZXh0IHNlY3Rpb24gYnV0IGl0IGlzIGluY2x1ZGVkIGluIHRoZSBleGFtcGxlLiZuYnNw OyBJIGV4cGVjdCB0aGlzIGlzIHNpbXBseSBhbiBvdmVyc2lnaHQuPG86cD48L286cD48L2xpPjwv dWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl04oCZcyB0 aGUgZG9tYWluIGluIHRoZSBwcm92aWRlci1saXN0LiAmbmJzcDtJIGNhbiBtYWtlIHRoYXQgY2xl YXJlcjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi10b3A6MGluO21hcmdpbi1ib3R0b206MGluO21zby1saXN0Omw0IGxldmVsMSBsZm80 Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+VHlwbyBDb21tZW50czwvYj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZXNlLCBJ 4oCZbGwgZml4IHRoZW08YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjx1bCBz dHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRl eHQiIHN0eWxlPSJtYXJnaW4tdG9wOjBpbjttYXJnaW4tYm90dG9tOjBpbjttc28tbGlzdDpsMiBs ZXZlbDEgbGZvNSI+DQpTZWN0aW9uIDUuNSwmbmJzcDsgUmVtb3ZlIHJlZHVuZGFudCAmcXVvdDt0 aGF0JnF1b3Q7IGZyb20gZmlyc3Qgc2VudGVuY2UgJnF1b3Q7dGhhdCB0aGF0JnF1b3Q7PG86cD48 L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDowaW47 bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzUiPg0KU2VjdGlvbiA5LCZu YnNwOyAybmQgc2VudGVuY2UgcmVhZHMgYXdrd2FyZGx5LiZuYnNwOyBQZXJoYXBzIGNoYW5nZSB0 byAmcXVvdDtPbmUgcHJvdmlkZXMgYSBkaXJlY3Rvcnkgb2YgcHJvdmlkZXJzIHNvIHRoYXQgYSB1 c2VyIGludGVyZmFjZSBhbGxvd3MgZWFzeSBwcm92aWRlciBzZWxlY3Rpb24gLi4uJnF1b3Q7PG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDow aW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzUiPg0KU2VjdGlvbiA5 LjEsIGdldCByaWQgb2YgZXh0cmEgJnF1b3Q7YSZxdW90OyBpbiB0aGUgc2VjdGlvbiAmcXVvdDsu Li5hIGNvdW50cnkgY29kZSBzdWl0YWJsZSBmb3IgZGlzcGxheSwgd2l0aCBhIGNvcnJlc3BvbmRp bmcgJnF1b3Q7YSZxdW90OyBVUkkgLi4uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzUiPg0KU2VjdGlvbiA5LjIsIGdldCByaWQgb2YgZXh0cmEgJnF1b3Q7dGhl JnF1b3Q7IGluIHRoZSBmaXJzdCBzZW50ZW5jZSAmcXVvdDsuLi5wcm92aWRlciBjb25maWd1cmF0 aW9uICZxdW90O3RoZSZxdW90OyB1c2luZyBhIHNpbXBsZS4uLiZxdW90OzxvOnA+PC9vOnA+PC9s aT48bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6MGluO21hcmdpbi1i b3R0b206MGluO21zby1saXN0OmwyIGxldmVsMSBsZm81Ij4NClNlY3Rpb24gOS40IC0gR2V0IHJp ZCBvZiB0aGUgcmVkdW5kYW50IHdvcmQgJnF1b3Q7U2VjdGlvbnMmcXVvdDsgaW4gdGhlIGZpcnN0 IHNlbnRlbmNlICZxdW90O1RoZSBpbnRlcmZhY2VzIGluICZxdW90O1NlY3Rpb25zJnF1b3Q7IFNl Y3Rpb24gOS4xIC4uLiZxdW90OzxvOnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkV1Z2VuZSBDaHJpc3RlbnNlbi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpuYXZ5Ij5DT05GSURFTlRJQUxJVFkgTk9USUNFLjwvc3Bhbj48L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnkiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnkiPlRoaXMNCiBlLW1haWwg dHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWls IG1lc3NhZ2VzIGF0dGFjaGVkIHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UNCiBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Ns b3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZ IFBST0hJQklURUQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVy cm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1lIGJ5IHJlcGx5IGUtbWFpbCBhdDxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ZWNocmlz dGVuc2VuQHNvcmVuc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOm5hdnkiPm9yDQogYnkgdGVsZXBob25lIGF0ICsxICg4MDEpIDI4Ny05 NDE5LCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNo bWVudHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5nIHRoZW0gdG8gZGlzay48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SdW0gJmx0OzxhIGhy ZWY9Im1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZyI+cnVtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5P biBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3Nw YW4+PC9iPkJyaWFuDQogUm9zZW48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBGZWJydWFyeSA1LCAyMDIxIDM6 MjcgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydW1AaWV0Zi5vcmciPnJ1bUBpZXRmLm9yZzwv YT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+W1J1bV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUt MDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bRVhURVJOQUxdPC9z cGFuPiZuYnNwO0kgaGF2ZSBwb3N0ZWQgYSAtMDQgcmV2aXNpb24uICZuYnNwO1RoaXMgc2hvdWxk IGhhbmRsZSBhbGwgY29tbWVudHMgcmVjZWl2ZWQgc28gZmFyLCBwbGVhc2UgbGV0IG1lIGtub3cg aWYgSSBmb3Jnb3Qgc29tZXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB2ZXJzaW9uIHJl d29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZpZ3VyYXRpb24gc2VjdGlvbnMgYWxvbmcg dGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGRvd25sb2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQg ZnJvbSBhIG5ldyBzaWdudXAuICZuYnNwO0nigJltIGhhdmluZyB0cm91YmxlIHRoaW5raW5nIGFi b3V0IGEgc2VjdXJlIHdheSB0byBkbyB0aGF0LiAmbmJzcDtJZiBhbnlvbmUgaGFzIGFuIGlkZWEs IEnigJltIHZlcnkgd2lsbGluZyB0byB3cml0ZSB0ZXh0IGZvciBpdC4gJm5ic3A7SeKAmXZlIGNv bnNpZGVyZWQgdGhpbmdzIGxpa2UgamF2YXNjcmlwdCB0aGF0DQogc3Rhc2hlcyBpdCBpbiBhIGZp bGUgb3Igc29tZXdoZXJlIGVsc2UsIGhhdmluZyBzb21lIHdlYiBwYWdlIGZ1bmN0aW9uIHRoYXQg dHJpZ2dlcnMgYSBsb2NhbCBkaXNwbGF5IG9mIGFuIGVudHJ5IGZvcm0gZm9yIHVzZXJuYW1lIGFu ZCBwYXNzd29yZCwgYW5kIGEgY291cGxlIG9mIG90aGVyIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T25lIG5vdGUgb24gdGhlIGNvbmZpZ3VyYXRpb24gbWVjaGFuaXNtIC0gYmVj YXVzZSB0aGUgb25seSB0aGluZyB0aGUgbG9jYWwgUlVFIGRldmljZSBuZWVkcyB0byBrZWVwIGlz IHRoZSB1c2VybmFtZSBwYXNzd29yZCBhZ2FpbnN0IGEgcHJvdmlkZXIgSUQgb2Ygc29tZSBraW5k LCB0aGVyZSBpc27igJl0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIGhvdyB0aGF0IHdvcmtzLCBh bmQgc28gaXTigJlzIGNvbXBsZXRlbHkNCiBhYnNlbnQgaW4gdGhlIHRleHQuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igbm93LCBJ4oCZdmUgcmVtb3ZlZCB0aGUgc3RlcCBi eSBzdGVwIGRpYWdyYW0gdGhhdCBzaG93ZWQgaG93IHRoZSBjb25maWcgbWVjaGFuaXNtIGlzIHVz ZWQuICZuYnNwO0kgdGhpbmsgd2hhdCBpcyB0aGVyZSBpcyBkZWFkIHNpbXBsZSBhbmQgbmVlZHMg bm8gZXhwbGFuYXRpb246IGl04oCZcyBhIHN0cmFpZ2h0Zm9yd2FyZCBSRVNUL0pTT04gd2ViIHNl cnZpY2UgdXNpbmcgdXNlcm5hbWUvcGFzc3dvcmQgYXV0aGVudGljYXRpb24NCiBmb3IgcHJvdmlk ZXJzIHRoZSB1c2VyIGhhcyBhY2NvdW50cyB3aXRoLiAmbmJzcDtJIGNhbiBicmluZyBiYWNrIHRo ZSBkaWFncmFtIGlmIHRoYXQgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5C cmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRv OmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRp Y2EmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0t cnVlLTA0LnR4dDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkRhdGU6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5GZWJydWFyeSA1 LCAyMDIxIGF0IDU6MTc6MTUgUE0gRVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZs dDs8YSBocmVmPSJtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3VuY2VAaWV0 Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWls dG86cnVtQGlldGYub3JnIj5ydW1AaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5S ZXBseS1Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4sPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydW1AaWV0Zi5vcmciPnJ1bUBpZXRm Lm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBN YWNoaW5lIFdHIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZv ciBSZWxheSBVc2VyIEVxdWlwbWVudDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0F1dGhvciAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs6IEJyaWFuIFJvc2VuPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0 LnR4dDxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj5QYWdlcyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDMzPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1z cGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkRhdGUgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMDIx LTAyLTA1PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VmlkZW8gUmVsYXkg U2VydmljZSAoVlJTKSBpcyBhIHRlcm0gdXNlZCB0byBkZXNjcmliZSBhIG1ldGhvZCBieTxicj4N CiZuYnNwOyZuYnNwO3doaWNoIGEgaGVhcmluZyBwZXJzb25zIGNhbiBjb21tdW5pY2F0ZSB3aXRo IGRlYWYvSGFyZCBvZiBIZWFyaW5nPGJyPg0KJm5ic3A7Jm5ic3A7dXNlciB1c2luZyBhbiBpbnRl cnByZXRlciAoJnF1b3Q7Q29tbXVuaWNhdGlvbnMgQXNzaXN0YW50JnF1b3Q7KSBjb25uZWN0ZWQg dmlhPGJyPg0KJm5ic3A7Jm5ic3A7YSB2aWRlb3Bob25lIHRvIHRoZSBkZWFmL0hvSCB1c2VyIGFu ZCBhbiBhdWRpbyB0ZWxlcGhvbmUgY2FsbCB0byB0aGU8YnI+DQombmJzcDsmbmJzcDtoZWFyaW5n IHVzZXIuICZuYnNwO1RoZSBDQSBpbnRlcnByZXRzIHVzaW5nIHNpZ24gbGFuZ3VhZ2Ugb24gdGhl PGJyPg0KJm5ic3A7Jm5ic3A7dmlkZW9waG9uZSBsaW5rIGFuZCB2b2ljZSBvbiB0aGUgdGVsZXBo b25lIGxpbmsuICZuYnNwO09mdGVuIHRoZTxicj4NCiZuYnNwOyZuYnNwO2ludGVycHJldGVycyBt YXkgYmUgc3VwcGxpZWQgYnkgYSBjb21wYW55IG9yIGFnZW5jeSB0ZXJtZWQgYTxicj4NCiZuYnNw OyZuYnNwOyZxdW90O3Byb3ZpZGVyJnF1b3Q7IGluIHRoaXMgZG9jdW1lbnQuICZuYnNwO1RoZSBw cm92aWRlciBhbHNvIHByb3ZpZGVzIGEgdmlkZW88YnI+DQombmJzcDsmbmJzcDtzZXJ2aWNlIHRo YXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3QgdmlkZW8gZGV2aWNlcyB0byB0aGVpciBzZXJ2aWNl LDxicj4NCiZuYnNwOyZuYnNwO2FuZCBzdWJzZXF1ZW50bHkgdG8gQ0FzIGFuZCBvdGhlciBkZWFm L0hvSCB1c2Vycy4gJm5ic3A7SXQgaXMgZGVzaXJhYmxlPGJyPg0KJm5ic3A7Jm5ic3A7dGhhdCB0 aGUgdmlkZW9waG9uZXMgdXNlZCBieSB0aGUgZGVhZi9Ib0gvSC1JIHVzZXIgY29uZm9ybSB0byBh PGJyPg0KJm5ic3A7Jm5ic3A7c3RhbmRhcmQgc28gdGhhdCBhbnkgZGV2aWNlIG1heSBiZSB1c2Vk IHdpdGggYW55IHByb3ZpZGVyIGFuZCB0aGF0PGJyPg0KJm5ic3A7Jm5ic3A7dmlkZW8gY2FsbHMg ZGlyZWN0IGJldHdlZW4gZGVhZi9Ib0ggdXNlcnMgd29yay4gJm5ic3A7VGhpcyBkb2N1bWVudDxi cj4NCiZuYnNwOyZuYnNwO2Rlc2NyaWJlcyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gYSB2aWRlb3Bo b25lIGFuZCBhIHByb3ZpZGVyLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnVtLXJ1ZS8iPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnVtLXJ1ZS88L2E+PGJyPg0KPGJyPg0KVGhl cmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0bWwi Pmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0 bWw8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZh aWxhYmxlIGF0Ojxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1p ZXRmLXJ1bS1ydWUtMDQ8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPGJyPg0K dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxl IGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQpJLUQtQW5u b3VuY2VAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2ktZC1hbm5vdW5jZTxicj4NCkludGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3 LmlldGYub3JnL3NoYWRvdy5odG1sPGJyPg0Kb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNo YWRvdy1zaXRlcy50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR04MB4983BAF92D02082D6D0ACF86A3809BYAPR04MB4983namp_-- From nobody Tue Feb 23 13:45:09 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 874173A0CB8 for ; Tue, 23 Feb 2021 13:45:08 -0800 (PST) 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 Q6aW979GZEMQ for ; Tue, 23 Feb 2021 13:45:05 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 BABC33A0C23 for ; Tue, 23 Feb 2021 13:45:04 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id b14so290062qkk.0 for ; Tue, 23 Feb 2021 13:45:04 -0800 (PST) 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=C12O4WDlkqW+d4C8oVXh/jeDyOeXPHi1mDh3zY7amr4=; b=zUYeayH3TY6c5PH8bSJ9WR9klrR83MVQW0l5A3RTIsTbaU08vTTs13tQshaOHlSnY1 2ysz98R4Elu0ertAkF241feRmWfAF+GhSOAE5L670XWK9HK8201pKMaHaa/21lstCsXG vmvDqgOF1ZTPGvF7gXicYOzjgzHr6QRwGmrRWt/yJC/zdP69WhRsPrZjhUSdNNV1Q+6i 4DuifbVXz4G3hwi/2aEkyzXKKCjIoDXsx9f38QRT8WvDY5rpi0ijoUT67uZsOJMzKiW2 KTQP+4ItVIm5QPm/CAFeeIOETXJUzPpz1LLrOPTpnL0EhCBCBknDRGyAhfwv17K8uYMn cHFw== 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=C12O4WDlkqW+d4C8oVXh/jeDyOeXPHi1mDh3zY7amr4=; b=Ji/lh0hAXG9HKdumC7MRlAuCVOP+rVnRl469PvwkstJ3+WvrtEq4g9wR7uKrvE9oNw nJI7Vy5yo406LGghCQPmYCUONIJfkRgp4BhYBeJ1668b1zGU3jtlth2uAapZ88p2zjwQ tVl1JaZ/jzA5g3gtN/r850E7L9ld8wgn4OmemMd2SvlRBUz07EYRbKM6xDAGhoqmhUPz fE9we6wI+QIgsPed6ORqlvCJPB2yejgGIVCfI2x+95OPmizYs+9lSnhuDuJ4buGLjbFK nvElgBcxmaj4iwuangCQB2JWjkmHsxDr/qvDf7NRUaZLGlsctmjNegZltDwqbydz210D L1vA== X-Gm-Message-State: AOAM530SHEtmMIwf3GrouYIFlPSXzMRE4uyuUUORe5RRzQIWRuaQ3JRW 7vyw7Y0N0iy5c14PkKfzL2ipwA== X-Google-Smtp-Source: ABdhPJw5wzMrEMKzSbK6oFEf72he1hkYTYsM94OurNqy1Jtnf1T3D89ZRNEou9Z36xNIixmsTJBngQ== X-Received: by 2002:a37:9b07:: with SMTP id d7mr27454321qke.497.1614116703627; Tue, 23 Feb 2021 13:45:03 -0800 (PST) Received: from brians-mbp.lan ([24.154.119.158]) by smtp.gmail.com with ESMTPSA id a145sm50415qkc.125.2021.02.23.13.45.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Feb 2021 13:45:03 -0800 (PST) From: Brian Rosen Message-Id: <3BE296CB-4CA6-4E15-83E4-53C91BA78079@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_079E3F99-E671-406E-AF94-9BE75BF7991D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 23 Feb 2021 16:45:00 -0500 In-Reply-To: Cc: "rum@ietf.org" To: Eugene Christensen References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <61A511CA-5EF9-4938-B77E-B9A4CB8FCA77@brianrosen.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 21:45:09 -0000 --Apple-Mail=_079E3F99-E671-406E-AF94-9BE75BF7991D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 How about: The new user signup contact URI may only initiate creation of a new = account. Various vetting, approval and other processes may be needed, = which could take time, before the account is established. The result of = creating a new account would be a username and password, which would be = manually entered into the RUE device to allow connection to the = Provider. > On Feb 23, 2021, at 4:40 PM, Eugene Christensen = wrote: >=20 > Thank you Brian and Paul for your responses. =20 > =20 > Regarding IPv4/IPv6, I can see your point that a path forward is = needed due to the diminishing availability of IPv4 addresses. Thanks = Paul for pointing out that the IPv6 requirement would be on the RUE only = and servers can continue to run on either/both (with a gateway if = necessary). This sounds like an appropriate approach. > =20 > Regarding section 9.2 and the vetting of new users, when I read = through it initially, my assumption was that the process was one that = would be completed in real time. It sounds like that must not be the = intent. I wonder if it might be helpful to have something that calls = that out; that it isn=E2=80=99t intended to be synchronous for a new = user but rather that it provides a starting point for getting registered = with the provider? > =20 > BTW, thank you for adding that an API key MAY be used. > =20 > Eugene. > =20 > =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 > From: Brian Rosen >=20 > Sent: Tuesday, February 9, 2021 9:54 AM > To: Eugene Christensen > > Cc: rum@ietf.org > Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > [EXTERNAL]=20 > =20 > =20 >=20 >=20 > On Feb 9, 2021, at 11:27 AM, Eugene Christensen = > wrote: > =20 > Hi Brian,=20 > =20 > I have a few thoughts on this and a few typos that I=E2=80=99ll point = out.=20 > =20 > Substance Comments > Section 4: Requirement for IPv4 and IPv6. Why is IPv6 now a = requirement? Why not optional? > Because the world has moved on, there are no more IPv4 addresses, many = networks are IPv6 only now, and we need a good reason to not require it = in the IETF. >=20 > =20 > Section 9.2 - The vetting process for a potential customer does not = lend itself to a person being able to simply sign up like this. The = customer will be required to have an account before being able to = communicate with the provider service. I therefore believe we should = remove the ability for the RUE device to communicate with the provider = without a userid/password. > The process has to start some how that doesn=E2=80=99t involve a phone = call. Take a really simple example: I=E2=80=99m deaf, I have an account = with provider X, I want to establish another account with provider Y. = Can=E2=80=99t I do that with a website? Can I get help via a = videophone? The way it=E2=80=99s currently defined all that happens is = you get a URI for the website and another for a help desk. You don=E2=80=99= t get anything out of it. When all the vetting is finished, you end up = with a userid and password, and you manually enter that into the RUE. = What am I missing? > =20 > =20 > Section 9.2 - In the section for the payload, it is missing the = provider-domain in the text section but it is included in the example. = I expect this is simply an oversight. > It=E2=80=99s the domain in the provider-list. I can make that clearer >=20 > =20 > =20 > Typo Comments > Thanks for these, I=E2=80=99ll fix them >=20 > Section 5.5, Remove redundant "that" from first sentence "that that" > Section 9, 2nd sentence reads awkwardly. Perhaps change to "One = provides a directory of providers so that a user interface allows easy = provider selection ..." > Section 9.1, get rid of extra "a" in the section "...a country code = suitable for display, with a corresponding "a" URI ... > Section 9.2, get rid of extra "the" in the first sentence "...provider = configuration "the" using a simple..." > Section 9.4 - Get rid of the redundant word "Sections" in the first = sentence "The interfaces in "Sections" Section 9.1 ..." > =20 > =20 > Thanks. > =20 > 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 > From: Rum > On = Behalf Of Brian Rosen > Sent: Friday, February 5, 2021 3:27 PM > To: rum@ietf.org > Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt > =20 > [EXTERNAL] I have posted a -04 revision. This should handle all = comments received so far, please let me know if I forgot something. > =20 > This version reworks the provider list and configuration sections = along the lines we have been discussing. > =20 > I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. > =20 > One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 > =20 > For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. > =20 > Brian > =20 >=20 >=20 >=20 > Begin forwarded message: > =20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-rum-rue-04.txt > Date: February 5, 2021 at 5:17:15 PM EST > To: > > Cc: rum@ietf.org > Reply-To: internet-drafts@ietf.org , = rum@ietf.org > =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-04.txt > Pages : 33 > Date : 2021-02-05 >=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-04.html = >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=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 --Apple-Mail=_079E3F99-E671-406E-AF94-9BE75BF7991D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 How = about:

The new user = signup contact URI may only initiate creation of a new account. =  Various vetting, approval and other processes may be needed, which = could take time, before the account is established.  The result of = creating a new account would be a username and password, which would be = manually entered into the RUE device to allow connection to the = Provider.

On Feb 23, 2021, at 4:40 PM, = Eugene Christensen <echristensen@sorenson.com> wrote:

Thank you Brian and Paul for your = responses.  
 
Regarding IPv4/IPv6, I can = see your point that a path forward is needed due to the diminishing = availability of IPv4 addresses.  Thanks Paul for pointing out that = the IPv6 requirement would be on the RUE only and servers can continue = to run on either/both (with a gateway if necessary).  This sounds = like an appropriate approach.
 
Regarding section 9.2 and the vetting of new = users, when I read through it initially, my assumption was that the = process was one that would be completed in real time.  It sounds = like that must not be the intent.  I wonder if it might be helpful = to have something that calls that out; that it isn=E2=80=99t intended to = be synchronous for a new user but rather that it provides a starting = point for getting registered with the provider?
 
BTW, thank you for adding = that an API key MAY be used.
 
Eugene.
 
 
 
 
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.
 
From: Brian Rosen <br@brianrosen.net> 
Sent: Tuesday, February 9, 2021 = 9:54 AM
To: Eugene Christensen <echristensen@sorenson.com>
Cc: rum@ietf.org
Subject: Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
[EXTERNAL] 
 
 


On Feb 9, 2021, at 11:27 AM, Eugene = Christensen <echristensen@sorenson.com> wrote:
 
Hi Brian, 
 
I have a = few thoughts on this and a few typos that I=E2=80=99ll point = out. 
 
Substance = Comments
  • Section 4: Requirement for IPv4 and = IPv6.  Why is IPv6 now a requirement?  Why not optional?
Because = the world has moved on, there are no more IPv4 addresses, many networks = are IPv6 only now, and we need a good reason to not require it in the = IETF.

  •  
  • Section 9.2 - = The vetting process for a potential customer does not lend itself to a = person being able to simply sign up like this.  The customer will = be required to have an account before being able to communicate with the = provider service.  I therefore believe we should remove the ability = for the RUE device to communicate with the provider without a = userid/password.
The process has to start some how that doesn=E2=80= =99t involve a phone call.  Take a really simple example: I=E2=80=99m= deaf, I have an account with provider X, I want to establish another = account with provider Y.  Can=E2=80=99t I do that with a website? =  Can I get help via a videophone?  The way it=E2=80=99s = currently defined all that happens is you get a URI for the website and = another for a help desk.  You don=E2=80=99t get anything out of it. =  When all the vetting is finished, you end up with a userid and = password, and you manually enter that into the RUE.  What am I = missing?
 
  •  
  • Section 9.2 - In the section for the payload, it is missing = the provider-domain in the text section but it is included in the = example.  I expect this is simply an oversight.
It=E2=80=99= s the domain in the provider-list.  I can make that clearer

  •  
 
Typo Comments
Thanks= for these, I=E2=80=99ll fix them

  • Section 5.5,  Remove redundant = "that" from first sentence "that that"
  • Section 9,  2nd sentence reads = awkwardly.  Perhaps change to "One provides a directory of = providers so that a user interface allows easy provider selection = ..."
  • Section 9.1, = get rid of extra "a" in the section "...a country code suitable for = display, with a corresponding "a" URI ...
  • Section 9.2, get rid of extra "the" = in the first sentence "...provider configuration "the" using a = simple..."
  • Section 9.4 - Get rid of the redundant word "Sections" in = the first sentence "The interfaces in "Sections" Section 9.1 ..."
 
 
Thanks.
 
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.
 
From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Friday, February 5, 2021 = 3:27 PM
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt
 
[EXTERNAL] I have posted a -04 revision. =  This should handle all comments received so far, please let me = know if I forgot something.
 
This version reworks the provider list and = configuration sections along the lines we have been discussing.
 
I do not have a way to = download a username/password from a new signup.  I=E2=80=99m having = trouble thinking about a secure way to do that.  If anyone has an = idea, I=E2=80=99m very willing to write text for it.  I=E2=80=99ve = considered things like javascript that stashes it in a file or somewhere = else, having some web page function that triggers a local display of an = entry form for username and password, and a couple of other things.
 
One note on the = configuration mechanism - because the only thing the local RUE device = needs to keep is the username password against a provider ID of some = kind, there isn=E2=80=99t any need to standardize how that works, and so = it=E2=80=99s completely absent in the text.  
 
For now, I=E2=80=99ve = removed the step by step diagram that showed how the config mechanism is = used.  I think what is there is dead simple and needs no = explanation: it=E2=80=99s a straightforward REST/JSON web service using = username/password authentication for providers the user has accounts = with.  I can bring back the diagram if that is needed.
 
Brian
 



Begin forwarded = message:
 
From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, = 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org
 

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
        &= nbsp;       Filename =        : draft-ietf-rum-rue-04.txt
        &= nbsp;       Pages =           : 33
        &= nbsp;       Date =            : = 2021-02-05

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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04

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

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


_______________________________________________
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

= --Apple-Mail=_079E3F99-E671-406E-AF94-9BE75BF7991D-- From nobody Tue Feb 23 13:50: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 E20353A0CE3 for ; Tue, 23 Feb 2021 13:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 gJBhyESOr3PY for ; Tue, 23 Feb 2021 13:50:22 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-eopbgr760073.outbound.protection.outlook.com [40.107.76.73]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EE723A0CE2 for ; Tue, 23 Feb 2021 13:50:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YvAAoJikgIxAw/dTN8VuuGkaJSpiwED6/v0IeVUmTD4d9Jqx5p4fEkmTH2/cH99+ihWlGx2+oixZ2QHLWpI0Qcz91u7g0veyoXraOnKBmExHuVkoWXLMrR4qGP1B39fQDxzm6+JAIZWsg58SGfbo02Y+p4Z03aGCpxt9THZTGuhnBnl4qFOFzeO+X5ZDhsqDlZy1rkUKpTkS6HSBqnMZAcclX2J7j11mRemlbhj66hp1gW+DprqFbG1OLlvhrOFOC5M78D2XrBu/j0W8pNUqGNXm06a0mD+Ts2jbe+kJQPN2fVVaF+aA3EivfcyP7cfGL5JDYSe3mCwavMipWXOcyw== 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=s6Lkq41HAfKm6j98hZKPknc5sCW84i0hqSPNC8sdY5g=; b=Uk5zTvutXvQd7sJWWbCcf3qeBFCJcu3fTcTcdUxKVG2Oq7knfp0mCHSXPaei2/mOgR5efHsq0LC9Hfj4cMHTPBo8iCXAVigmTSLE8Sz3B1upDWRtsC68O2bZT40+SCoVXmU4ocgQfR4MrCobRyXNVEcF1BllpAsjy1/Uj9uG3SqzSm0U80jVr8sj3m8cMwRJwcrfAvDF2qP3Pj6hk/RjNHtlMmUPYvguOK1EoD5Wo+Ez4d01IDxSGmlAcf95gVAItu7Cnq+Ll4+K7J2jLKZ7dpLjkm5ASD6khGfvglZhuJv4Eo7HSEExWfdLJa7TrRnV5YS4EkxFUhjFYgUj2hw6Sw== 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=s6Lkq41HAfKm6j98hZKPknc5sCW84i0hqSPNC8sdY5g=; b=j+SZbg/DgnAk6Qr+K+EnZyzWjw2wEtNChdHf6ctSc5Ud+zN1KXsV4f4JdGWSXYx/hONETs619rFAhXFIhaaSK71sCLBDnQ/SVH6y+bAFFkTGXeK9dPnq6HaUm8hnrRoovNsKedZBe+c66A4EERoWV1vW+Sd6BstIdUsh/uMQIUY= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BYAPR04MB5688.namprd04.prod.outlook.com (2603:10b6:a03:104::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.31; Tue, 23 Feb 2021 21:50:19 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681%6]) with mapi id 15.20.3868.033; Tue, 23 Feb 2021 21:50:19 +0000 From: Eugene Christensen To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/wQsHqqNWyK+TUibK61/n15TnKpmSlEggAAR6wCAAAEZEA== Date: Tue, 23 Feb 2021 21:50:19 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <61A511CA-5EF9-4938-B77E-B9A4CB8FCA77@brianrosen.net> <3BE296CB-4CA6-4E15-83E4-53C91BA78079@brianrosen.net> In-Reply-To: <3BE296CB-4CA6-4E15-83E4-53C91BA78079@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-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 47d36c9b-3a3b-4c65-11f5-08d8d8450397 x-ms-traffictypediagnostic: BYAPR04MB5688: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +B5J0tyQ4aDDlSJZEuoS0QXKn99kLKaRmphzdUKUH8YirsIZac/nDI+74c/gXkQxoG6j8Kw0SeisiBpeBE3e2suMpf2HIaFyBRmucPPFfw8cCpzQJIklqjkUn4tnou4G0d6RuWbVcy9D7gTAGIwc0zI167slEuYDuG10RkyFlABBuLBuv4lz+2xuZfu9vsHAIEn3jA2oae9qjy8vEo+oCFIRZEcjiggT4G5SrKvkCgbfqQjGPjvuR6Kd8BhD4En3qGa4rqMSkIuNB5DIdU/BPKitb8J3UBmgGqVg913+vxKK3RBrktPuFuazmVJ7RXJV/AO/9DZsEMHHZhLvARU8k+Hctudfx0sA0QQEs/RkFiopY2UE8oBHY9KFFHlKiLunhCLsCjg9PbdwGOqbHk1y+AAdLzZhTsY1UiZbWcNKMHFql/EFd9/oaKpY3IJrEGgno/AtY3q2/Cib34stNoSXiycJUQzZJM/t/lbxWIJqKBm7j02HBkJ4PGJqqj/he5C6TSE88BCbIUrBmtU7Pf9wPWaM77vTtghAi5G9ufvenmLHGNR7WrfaHS+8tEXsS34GNpIoim9Xf2tup9Pj73XNjl2j2PLwgx6apYapRo8S9Ko= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(396003)(366004)(136003)(376002)(346002)(9686003)(478600001)(21615005)(76116006)(6916009)(86362001)(6506007)(4326008)(66946007)(966005)(66574015)(186003)(316002)(2906002)(66476007)(166002)(53546011)(64756008)(8936002)(71200400001)(66446008)(52536014)(33656002)(83380400001)(8676002)(26005)(55016002)(66556008)(5660300002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RlpWK005MDdjQU9VTnlXT1VFblRqYXJoRkxabytIV1ZsYkk3RGg5Q2ZCWHdO?= =?utf-8?B?bmQwQ2FJd2J6Y0gwZ01OVmt3Nk5TbzVDWldoQXVqcHlkY2ZWSmcyS1NhaWhk?= =?utf-8?B?cU9tb3cyTDlRek8xVVpMTTFDekk1cHQvMjZZS3NBbFAwdktwWEZlSkhjTUl1?= =?utf-8?B?eVhvMzNac1htUEVDWkV0TGxUYnpWdldqeVdGSmpIam1pZG0vTGhJNEtaNTJD?= =?utf-8?B?SC8rMnFtbXBHdE5ITUkyTUR5TFdubC8vSEpHQ25KcFdaR09lMzlRdVJOYXM0?= =?utf-8?B?ZTdGRlNvSU1CUlpldkVKNk9mRW9iN2k0VlduTitRbXRxTTBGMjlkWUVsemJ0?= =?utf-8?B?RzRwOFpHUmo2U1NYMExNd2x6NDJwL0xMYk56dHVEdkppbWQ4dHVnbjBTNzlB?= =?utf-8?B?aU9jMFFaU0FRMDIzeG8vbmlrcm1uWUVPUGV2ZnhwUS9uSHVZVTQ0QmUyRThw?= =?utf-8?B?NW95amZ0ZGVoUmJVQ1NQRDJnb3hjbWxYY09mTThkYlNPV2N1L2VCeWZWR1hF?= =?utf-8?B?Wk5ySzNGWjViUml6bEJtMmRyVUM1KzM5Q2pBYnk5ZUNkK0pNTU9xZEFFeGtB?= =?utf-8?B?c2RtYVd2NkQ2cmJnSWYwN3E5MDhJTDZvS2NWQXAyWHQxc00wN1ZPZ2h2TVhI?= =?utf-8?B?QkdHVDFSSXVacW1LZVB4QXhpeHF4aCtSN3MzSzd5WXM5VTRyMXcwYjFZbWt2?= =?utf-8?B?NkxQeHpDWHl6ZFR2cVB0SEhCLzJtTjhlUUhBZmp2RU9hUWJSMnkrR3B2UnJ1?= =?utf-8?B?M1pPSmIvd3hvTHBMZzhWaFdEZG9kRjdmZ2k2Und1SWhqQS9kOTRadlR5bG4w?= =?utf-8?B?YVFrdGkrSmxXUEpKUGIxVWR1YTlkTVJCSzJvdmkvM3Q2ZmNoblp3WkNadTVz?= =?utf-8?B?M0dCL3NXQStDTUZUOFZEdDFNL0FiNGwwOFgybm96dWd3cm01elJDSWRScnpD?= =?utf-8?B?TkVxMm80ZmtnOVVCN3U4UHY3eGVWTlNDTlFFd2pCNUpUUVJtbmJRYUpZenNt?= =?utf-8?B?R1N2aUVsakQ1WUV4aHVVbExibzlCRmdlNGpVaEY2WkxNRlo4UDVuWklmUEhI?= =?utf-8?B?K2paK3lSckZkZXlialRiU05WQjNOd2dDdkloV1U2QVo0MzVmWXNzQ0F4eCs4?= =?utf-8?B?cXMybnFsbTJDSWwxUDJIaG05MXFVeFhTNGxpMFNNQnduWmZTRUpEcTQ2TlRq?= =?utf-8?B?WFBRcWNBRHNtSGlBOWRocUFIM0VVQnpvVTU2MlZPczRGRE1JRkt2bC9nbUtT?= =?utf-8?B?Ti9nU2JwN0xVVnkvaS9ZV1g5VmFyL3E5TEp3VFQ1M3I2Ni9pVW1XWjRMMUtT?= =?utf-8?B?N3gxNnh6VHhsc09WdUNaRStVRVRNbHJHaXlIcWY4aTNaTlFQK3BsdHEwRU1p?= =?utf-8?B?N1RncEFzUXJDZEJyS3hnc0VsTHFNWWVHUnlOcGJjaGVqTi9wbGtaZDZRUTlD?= =?utf-8?B?dTFGY25RelgvUkV4aEZUcVN5U1ExQXYydjBYR0NReVNBY3dOZ3JzVm5Ncll6?= =?utf-8?B?djZ1NXdyWGkvMXYzZlVwbFphTUR2WTB4OW5oZlUremdMSzlsVDVrSUtOTUtE?= =?utf-8?B?aFlTQ1lQcG5tOC9MYkJ5THVXSFZFYWlISVpneFVVWlR0V0FkVWQ0Y0ZsNXBY?= =?utf-8?B?SXRvcnNFSDBxdkNRWm1XU1BGQ1NGdWdxZlpXL0ZnR05uL0Z2VCsvYmJwZjJW?= =?utf-8?B?SnhWTGFIazkzZGRjdm5pWWRpbFVMUExVVmpxL2g2WFMxOWY0S1crK1FHdEZE?= =?utf-8?Q?gCZH94Hzg+3WyndsA+k7/Q2yQZcFXof446mNgVq?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR04MB4983C8AE1E79461C8721EB50A3809BYAPR04MB4983namp_" MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 47d36c9b-3a3b-4c65-11f5-08d8d8450397 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2021 21:50:19.6261 (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: 9DDWGkZwKBtPu+adVqQDFZAY+ZrOSKZHUa8qF0zt/IQY7gGhE74BHQkd2Ht/gPT+APqDWZgTVK7IeCJHYXvJWpZpzX/roNeKm8Y0DVHJSMk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB5688 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Tue, 23 Feb 2021 21:50:26 -0000 --_000_BYAPR04MB4983C8AE1E79461C8721EB50A3809BYAPR04MB4983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCBzb3VuZHMgcmVhc29uYWJsZS4NCg0KVGhhbmtzLg0KRXVnZW5lLg0KDQoNCkZyb206IEJy aWFuIFJvc2VuIDxickBicmlhbnJvc2VuLm5ldD4NClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDIz LCAyMDIxIDI6NDUgUE0NClRvOiBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBzb3Jl bnNvbi5jb20+DQpDYzogcnVtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1J1bV0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0KDQpbRVhURVJOQUxdIEhvdyBhYm91dDoNCg0K VGhlIG5ldyB1c2VyIHNpZ251cCBjb250YWN0IFVSSSBtYXkgb25seSBpbml0aWF0ZSBjcmVhdGlv biBvZiBhIG5ldyBhY2NvdW50LiAgVmFyaW91cyB2ZXR0aW5nLCBhcHByb3ZhbCBhbmQgb3RoZXIg cHJvY2Vzc2VzIG1heSBiZSBuZWVkZWQsIHdoaWNoIGNvdWxkIHRha2UgdGltZSwgYmVmb3JlIHRo ZSBhY2NvdW50IGlzIGVzdGFibGlzaGVkLiAgVGhlIHJlc3VsdCBvZiBjcmVhdGluZyBhIG5ldyBh Y2NvdW50IHdvdWxkIGJlIGEgdXNlcm5hbWUgYW5kIHBhc3N3b3JkLCB3aGljaCB3b3VsZCBiZSBt YW51YWxseSBlbnRlcmVkIGludG8gdGhlIFJVRSBkZXZpY2UgdG8gYWxsb3cgY29ubmVjdGlvbiB0 byB0aGUgUHJvdmlkZXIuDQoNCg0KT24gRmViIDIzLCAyMDIxLCBhdCA0OjQwIFBNLCBFdWdlbmUg Q2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb208bWFpbHRvOmVjaHJpc3RlbnNl bkBzb3JlbnNvbi5jb20+PiB3cm90ZToNCg0KVGhhbmsgeW91IEJyaWFuIGFuZCBQYXVsIGZvciB5 b3VyIHJlc3BvbnNlcy4NCg0KUmVnYXJkaW5nIElQdjQvSVB2NiwgSSBjYW4gc2VlIHlvdXIgcG9p bnQgdGhhdCBhIHBhdGggZm9yd2FyZCBpcyBuZWVkZWQgZHVlIHRvIHRoZSBkaW1pbmlzaGluZyBh dmFpbGFiaWxpdHkgb2YgSVB2NCBhZGRyZXNzZXMuICBUaGFua3MgUGF1bCBmb3IgcG9pbnRpbmcg b3V0IHRoYXQgdGhlIElQdjYgcmVxdWlyZW1lbnQgd291bGQgYmUgb24gdGhlIFJVRSBvbmx5IGFu ZCBzZXJ2ZXJzIGNhbiBjb250aW51ZSB0byBydW4gb24gZWl0aGVyL2JvdGggKHdpdGggYSBnYXRl d2F5IGlmIG5lY2Vzc2FyeSkuICBUaGlzIHNvdW5kcyBsaWtlIGFuIGFwcHJvcHJpYXRlIGFwcHJv YWNoLg0KDQpSZWdhcmRpbmcgc2VjdGlvbiA5LjIgYW5kIHRoZSB2ZXR0aW5nIG9mIG5ldyB1c2Vy cywgd2hlbiBJIHJlYWQgdGhyb3VnaCBpdCBpbml0aWFsbHksIG15IGFzc3VtcHRpb24gd2FzIHRo YXQgdGhlIHByb2Nlc3Mgd2FzIG9uZSB0aGF0IHdvdWxkIGJlIGNvbXBsZXRlZCBpbiByZWFsIHRp bWUuICBJdCBzb3VuZHMgbGlrZSB0aGF0IG11c3Qgbm90IGJlIHRoZSBpbnRlbnQuICBJIHdvbmRl ciBpZiBpdCBtaWdodCBiZSBoZWxwZnVsIHRvIGhhdmUgc29tZXRoaW5nIHRoYXQgY2FsbHMgdGhh dCBvdXQ7IHRoYXQgaXQgaXNu4oCZdCBpbnRlbmRlZCB0byBiZSBzeW5jaHJvbm91cyBmb3IgYSBu ZXcgdXNlciBidXQgcmF0aGVyIHRoYXQgaXQgcHJvdmlkZXMgYSBzdGFydGluZyBwb2ludCBmb3Ig Z2V0dGluZyByZWdpc3RlcmVkIHdpdGggdGhlIHByb3ZpZGVyPw0KDQpCVFcsIHRoYW5rIHlvdSBm b3IgYWRkaW5nIHRoYXQgYW4gQVBJIGtleSBNQVkgYmUgdXNlZC4NCg0KRXVnZW5lLg0KDQoNCg0K RnJvbTogQnJpYW4gUm9zZW4gPGJyQGJyaWFucm9zZW4ubmV0PG1haWx0bzpickBicmlhbnJvc2Vu Lm5ldD4+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA5LCAyMDIxIDk6NTQgQU0NClRvOiBFdWdl bmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb208bWFpbHRvOmVjaHJpc3Rl bnNlbkBzb3JlbnNvbi5jb20+Pg0KQ2M6IHJ1bUBpZXRmLm9yZzxtYWlsdG86cnVtQGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFtSdW1dIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNC50 eHQNCg0KW0VYVEVSTkFMXQ0KDQoNCg0KDQoNCk9uIEZlYiA5LCAyMDIxLCBhdCAxMToyNyBBTSwg RXVnZW5lIENocmlzdGVuc2VuIDxlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0bzplY2hy aXN0ZW5zZW5Ac29yZW5zb24uY29tPj4gd3JvdGU6DQoNCkhpIEJyaWFuLA0KDQpJIGhhdmUgYSBm ZXcgdGhvdWdodHMgb24gdGhpcyBhbmQgYSBmZXcgdHlwb3MgdGhhdCBJ4oCZbGwgcG9pbnQgb3V0 Lg0KDQpTdWJzdGFuY2UgQ29tbWVudHMNCg0KICAqICAgU2VjdGlvbiA0OiBSZXF1aXJlbWVudCBm b3IgSVB2NCBhbmQgSVB2Ni4gIFdoeSBpcyBJUHY2IG5vdyBhIHJlcXVpcmVtZW50PyAgV2h5IG5v dCBvcHRpb25hbD8NCkJlY2F1c2UgdGhlIHdvcmxkIGhhcyBtb3ZlZCBvbiwgdGhlcmUgYXJlIG5v IG1vcmUgSVB2NCBhZGRyZXNzZXMsIG1hbnkgbmV0d29ya3MgYXJlIElQdjYgb25seSBub3csIGFu ZCB3ZSBuZWVkIGEgZ29vZCByZWFzb24gdG8gbm90IHJlcXVpcmUgaXQgaW4gdGhlIElFVEYuDQoN Cg0KDQogICoNCiAgKiAgIFNlY3Rpb24gOS4yIC0gVGhlIHZldHRpbmcgcHJvY2VzcyBmb3IgYSBw b3RlbnRpYWwgY3VzdG9tZXIgZG9lcyBub3QgbGVuZCBpdHNlbGYgdG8gYSBwZXJzb24gYmVpbmcg YWJsZSB0byBzaW1wbHkgc2lnbiB1cCBsaWtlIHRoaXMuICBUaGUgY3VzdG9tZXIgd2lsbCBiZSBy ZXF1aXJlZCB0byBoYXZlIGFuIGFjY291bnQgYmVmb3JlIGJlaW5nIGFibGUgdG8gY29tbXVuaWNh dGUgd2l0aCB0aGUgcHJvdmlkZXIgc2VydmljZS4gIEkgdGhlcmVmb3JlIGJlbGlldmUgd2Ugc2hv dWxkIHJlbW92ZSB0aGUgYWJpbGl0eSBmb3IgdGhlIFJVRSBkZXZpY2UgdG8gY29tbXVuaWNhdGUg d2l0aCB0aGUgcHJvdmlkZXIgd2l0aG91dCBhIHVzZXJpZC9wYXNzd29yZC4NClRoZSBwcm9jZXNz IGhhcyB0byBzdGFydCBzb21lIGhvdyB0aGF0IGRvZXNu4oCZdCBpbnZvbHZlIGEgcGhvbmUgY2Fs bC4gIFRha2UgYSByZWFsbHkgc2ltcGxlIGV4YW1wbGU6IEnigJltIGRlYWYsIEkgaGF2ZSBhbiBh Y2NvdW50IHdpdGggcHJvdmlkZXIgWCwgSSB3YW50IHRvIGVzdGFibGlzaCBhbm90aGVyIGFjY291 bnQgd2l0aCBwcm92aWRlciBZLiAgQ2Fu4oCZdCBJIGRvIHRoYXQgd2l0aCBhIHdlYnNpdGU/ICBD YW4gSSBnZXQgaGVscCB2aWEgYSB2aWRlb3Bob25lPyAgVGhlIHdheSBpdOKAmXMgY3VycmVudGx5 IGRlZmluZWQgYWxsIHRoYXQgaGFwcGVucyBpcyB5b3UgZ2V0IGEgVVJJIGZvciB0aGUgd2Vic2l0 ZSBhbmQgYW5vdGhlciBmb3IgYSBoZWxwIGRlc2suICBZb3UgZG9u4oCZdCBnZXQgYW55dGhpbmcg b3V0IG9mIGl0LiAgV2hlbiBhbGwgdGhlIHZldHRpbmcgaXMgZmluaXNoZWQsIHlvdSBlbmQgdXAg d2l0aCBhIHVzZXJpZCBhbmQgcGFzc3dvcmQsIGFuZCB5b3UgbWFudWFsbHkgZW50ZXIgdGhhdCBp bnRvIHRoZSBSVUUuICBXaGF0IGFtIEkgbWlzc2luZz8NCg0KDQogICoNCiAgKiAgIFNlY3Rpb24g OS4yIC0gSW4gdGhlIHNlY3Rpb24gZm9yIHRoZSBwYXlsb2FkLCBpdCBpcyBtaXNzaW5nIHRoZSBw cm92aWRlci1kb21haW4gaW4gdGhlIHRleHQgc2VjdGlvbiBidXQgaXQgaXMgaW5jbHVkZWQgaW4g dGhlIGV4YW1wbGUuICBJIGV4cGVjdCB0aGlzIGlzIHNpbXBseSBhbiBvdmVyc2lnaHQuDQpJdOKA mXMgdGhlIGRvbWFpbiBpbiB0aGUgcHJvdmlkZXItbGlzdC4gIEkgY2FuIG1ha2UgdGhhdCBjbGVh cmVyDQoNCg0KDQogICoNCg0KVHlwbyBDb21tZW50cw0KVGhhbmtzIGZvciB0aGVzZSwgSeKAmWxs IGZpeCB0aGVtDQoNCg0KDQogICogICBTZWN0aW9uIDUuNSwgIFJlbW92ZSByZWR1bmRhbnQgInRo YXQiIGZyb20gZmlyc3Qgc2VudGVuY2UgInRoYXQgdGhhdCINCiAgKiAgIFNlY3Rpb24gOSwgIDJu ZCBzZW50ZW5jZSByZWFkcyBhd2t3YXJkbHkuICBQZXJoYXBzIGNoYW5nZSB0byAiT25lIHByb3Zp ZGVzIGEgZGlyZWN0b3J5IG9mIHByb3ZpZGVycyBzbyB0aGF0IGEgdXNlciBpbnRlcmZhY2UgYWxs b3dzIGVhc3kgcHJvdmlkZXIgc2VsZWN0aW9uIC4uLiINCiAgKiAgIFNlY3Rpb24gOS4xLCBnZXQg cmlkIG9mIGV4dHJhICJhIiBpbiB0aGUgc2VjdGlvbiAiLi4uYSBjb3VudHJ5IGNvZGUgc3VpdGFi bGUgZm9yIGRpc3BsYXksIHdpdGggYSBjb3JyZXNwb25kaW5nICJhIiBVUkkgLi4uDQogICogICBT ZWN0aW9uIDkuMiwgZ2V0IHJpZCBvZiBleHRyYSAidGhlIiBpbiB0aGUgZmlyc3Qgc2VudGVuY2Ug Ii4uLnByb3ZpZGVyIGNvbmZpZ3VyYXRpb24gInRoZSIgdXNpbmcgYSBzaW1wbGUuLi4iDQogICog ICBTZWN0aW9uIDkuNCAtIEdldCByaWQgb2YgdGhlIHJlZHVuZGFudCB3b3JkICJTZWN0aW9ucyIg aW4gdGhlIGZpcnN0IHNlbnRlbmNlICJUaGUgaW50ZXJmYWNlcyBpbiAiU2VjdGlvbnMiIFNlY3Rp b24gOS4xIC4uLiINCg0KDQpUaGFua3MuDQoNCkV1Z2VuZSBDaHJpc3RlbnNlbi4NCg0KDQpGcm9t OiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZz4+ IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogRnJpZGF5LCBGZWJydWFyeSA1LCAyMDIx IDM6MjcgUE0NClRvOiBydW1AaWV0Zi5vcmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NClN1YmplY3Q6 IFtSdW1dIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0KDQpbRVhU RVJOQUxdIEkgaGF2ZSBwb3N0ZWQgYSAtMDQgcmV2aXNpb24uICBUaGlzIHNob3VsZCBoYW5kbGUg YWxsIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZhciwgcGxlYXNlIGxldCBtZSBrbm93IGlmIEkgZm9y Z290IHNvbWV0aGluZy4NCg0KVGhpcyB2ZXJzaW9uIHJld29ya3MgdGhlIHByb3ZpZGVyIGxpc3Qg YW5kIGNvbmZpZ3VyYXRpb24gc2VjdGlvbnMgYWxvbmcgdGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBk aXNjdXNzaW5nLg0KDQpJIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGRvd25sb2FkIGEgdXNlcm5hbWUv cGFzc3dvcmQgZnJvbSBhIG5ldyBzaWdudXAuICBJ4oCZbSBoYXZpbmcgdHJvdWJsZSB0aGlua2lu ZyBhYm91dCBhIHNlY3VyZSB3YXkgdG8gZG8gdGhhdC4gIElmIGFueW9uZSBoYXMgYW4gaWRlYSwg SeKAmW0gdmVyeSB3aWxsaW5nIHRvIHdyaXRlIHRleHQgZm9yIGl0LiAgSeKAmXZlIGNvbnNpZGVy ZWQgdGhpbmdzIGxpa2UgamF2YXNjcmlwdCB0aGF0IHN0YXNoZXMgaXQgaW4gYSBmaWxlIG9yIHNv bWV3aGVyZSBlbHNlLCBoYXZpbmcgc29tZSB3ZWIgcGFnZSBmdW5jdGlvbiB0aGF0IHRyaWdnZXJz IGEgbG9jYWwgZGlzcGxheSBvZiBhbiBlbnRyeSBmb3JtIGZvciB1c2VybmFtZSBhbmQgcGFzc3dv cmQsIGFuZCBhIGNvdXBsZSBvZiBvdGhlciB0aGluZ3MuDQoNCk9uZSBub3RlIG9uIHRoZSBjb25m aWd1cmF0aW9uIG1lY2hhbmlzbSAtIGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgdGhlIGxvY2FsIFJV RSBkZXZpY2UgbmVlZHMgdG8ga2VlcCBpcyB0aGUgdXNlcm5hbWUgcGFzc3dvcmQgYWdhaW5zdCBh IHByb3ZpZGVyIElEIG9mIHNvbWUga2luZCwgdGhlcmUgaXNu4oCZdCBhbnkgbmVlZCB0byBzdGFu ZGFyZGl6ZSBob3cgdGhhdCB3b3JrcywgYW5kIHNvIGl04oCZcyBjb21wbGV0ZWx5IGFic2VudCBp biB0aGUgdGV4dC4NCg0KRm9yIG5vdywgSeKAmXZlIHJlbW92ZWQgdGhlIHN0ZXAgYnkgc3RlcCBk aWFncmFtIHRoYXQgc2hvd2VkIGhvdyB0aGUgY29uZmlnIG1lY2hhbmlzbSBpcyB1c2VkLiAgSSB0 aGluayB3aGF0IGlzIHRoZXJlIGlzIGRlYWQgc2ltcGxlIGFuZCBuZWVkcyBubyBleHBsYW5hdGlv bjogaXTigJlzIGEgc3RyYWlnaHRmb3J3YXJkIFJFU1QvSlNPTiB3ZWIgc2VydmljZSB1c2luZyB1 c2VybmFtZS9wYXNzd29yZCBhdXRoZW50aWNhdGlvbiBmb3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhh cyBhY2NvdW50cyB3aXRoLiAgSSBjYW4gYnJpbmcgYmFjayB0aGUgZGlhZ3JhbSBpZiB0aGF0IGlz IG5lZWRlZC4NCg0KQnJpYW4NCg0KDQoNCg0KDQpCZWdpbiBmb3J3YXJkZWQgbWVzc2FnZToNCg0K RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQpE YXRlOiBGZWJydWFyeSA1LCAyMDIxIGF0IDU6MTc6MTUgUE0gRVNUDQpUbzogPGktZC1hbm5vdW5j ZUBpZXRmLm9yZzxtYWlsdG86aS1kLWFubm91bmNlQGlldGYub3JnPj4NCkNjOiBydW1AaWV0Zi5v cmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NClJlcGx5LVRvOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4sIHJ1bUBpZXRmLm9yZzxtYWlsdG86 cnVtQGlldGYub3JnPg0KDQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMg YSB3b3JrIGl0ZW0gb2YgdGhlIFJlbGF5IFVzZXIgTWFjaGluZSBXRyBvZiB0aGUgSUVURi4NCg0K ICAgICAgIFRpdGxlICAgICAgICAgICA6IEludGVyb3BlcmFiaWxpdHkgUHJvZmlsZSBmb3IgUmVs YXkgVXNlciBFcXVpcG1lbnQNCiAgICAgICBBdXRob3IgICAgICAgICAgOiBCcmlhbiBSb3Nlbg0K ICAgICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNC50 eHQNCiAgICAgICAgICAgICAgICBQYWdlcyAgICAgICAgICAgOiAzMw0KICAgICAgICAgICAgICAg IERhdGUgICAgICAgICAgICA6IDIwMjEtMDItMDUNCg0KQWJzdHJhY3Q6DQogIFZpZGVvIFJlbGF5 IFNlcnZpY2UgKFZSUykgaXMgYSB0ZXJtIHVzZWQgdG8gZGVzY3JpYmUgYSBtZXRob2QgYnkNCiAg d2hpY2ggYSBoZWFyaW5nIHBlcnNvbnMgY2FuIGNvbW11bmljYXRlIHdpdGggZGVhZi9IYXJkIG9m IEhlYXJpbmcNCiAgdXNlciB1c2luZyBhbiBpbnRlcnByZXRlciAoIkNvbW11bmljYXRpb25zIEFz c2lzdGFudCIpIGNvbm5lY3RlZCB2aWENCiAgYSB2aWRlb3Bob25lIHRvIHRoZSBkZWFmL0hvSCB1 c2VyIGFuZCBhbiBhdWRpbyB0ZWxlcGhvbmUgY2FsbCB0byB0aGUNCiAgaGVhcmluZyB1c2VyLiAg VGhlIENBIGludGVycHJldHMgdXNpbmcgc2lnbiBsYW5ndWFnZSBvbiB0aGUNCiAgdmlkZW9waG9u ZSBsaW5rIGFuZCB2b2ljZSBvbiB0aGUgdGVsZXBob25lIGxpbmsuICBPZnRlbiB0aGUNCiAgaW50 ZXJwcmV0ZXJzIG1heSBiZSBzdXBwbGllZCBieSBhIGNvbXBhbnkgb3IgYWdlbmN5IHRlcm1lZCBh DQogICJwcm92aWRlciIgaW4gdGhpcyBkb2N1bWVudC4gIFRoZSBwcm92aWRlciBhbHNvIHByb3Zp ZGVzIGEgdmlkZW8NCiAgc2VydmljZSB0aGF0IGFsbG93cyB1c2VycyB0byBjb25uZWN0IHZpZGVv IGRldmljZXMgdG8gdGhlaXIgc2VydmljZSwNCiAgYW5kIHN1YnNlcXVlbnRseSB0byBDQXMgYW5k IG90aGVyIGRlYWYvSG9IIHVzZXJzLiAgSXQgaXMgZGVzaXJhYmxlDQogIHRoYXQgdGhlIHZpZGVv cGhvbmVzIHVzZWQgYnkgdGhlIGRlYWYvSG9IL0gtSSB1c2VyIGNvbmZvcm0gdG8gYQ0KICBzdGFu ZGFyZCBzbyB0aGF0IGFueSBkZXZpY2UgbWF5IGJlIHVzZWQgd2l0aCBhbnkgcHJvdmlkZXIgYW5k IHRoYXQNCiAgdmlkZW8gY2FsbHMgZGlyZWN0IGJldHdlZW4gZGVhZi9Ib0ggdXNlcnMgd29yay4g IFRoaXMgZG9jdW1lbnQNCiAgZGVzY3JpYmVzIHRoZSBpbnRlcmZhY2UgYmV0d2VlbiBhIHZpZGVv cGhvbmUgYW5kIGEgcHJvdmlkZXIuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBh Z2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1pZXRmLXJ1bS1ydWUvDQoNClRoZXJlIGlzIGFsc28gYW4gSFRNTCB2ZXJzaW9uIGF2YWls YWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1ydW0t cnVlLTA0Lmh0bWwNCg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxh YmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcnVt LXJ1ZS0wNA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2ZXJz aW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVybmV0 LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCkktRC1B bm5vdW5jZUBpZXRmLm9yZzxtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0 IGRpcmVjdG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0KDQo= --_000_BYAPR04MB4983C8AE1E79461C8721EB50A3809BYAPR04MB4983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsN CglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0 LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNv LXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0K CXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo1MzQxMjEyOTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNzY1Mjg4MzI7fQ0KQGxp c3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3NTUyMDE5NTQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi0xNjM2Njg3NzQ2O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6ODY1 ODcwMzMxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTUzODM0NTU1NDt9DQpAbGlzdCBsMjps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwy OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwzDQoJe21zby1saXN0LWlkOjEwMjU3ODU0NTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xNzY0MzQ3MzE4O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIu MGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTQ2MzIzMTY3 MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzMjY3OTc0NjQ7fQ0KQGxpc3QgbDQ6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9Indv cmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGF0IHNvdW5kcyByZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdWdlbmUu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBCcmlhbiBSb3NlbiAmbHQ7YnJAYnJpYW5yb3Nlbi5uZXQmZ3Q7IDxicj4NCjxiPlNlbnQ6PC9i PiBUdWVzZGF5LCBGZWJydWFyeSAyMywgMjAyMSAyOjQ1IFBNPGJyPg0KPGI+VG86PC9iPiBFdWdl bmUgQ2hyaXN0ZW5zZW4gJmx0O2VjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBydW1AaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtSdW1dIEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNC50eHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltFWFRFUk5BTF08L3NwYW4+ Jm5ic3A7SG93IGFib3V0OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIG5ldyB1c2VyIHNpZ251cCBjb250YWN0IFVSSSBtYXkgb25seSBpbml0aWF0ZSBj cmVhdGlvbiBvZiBhIG5ldyBhY2NvdW50LiAmbmJzcDtWYXJpb3VzIHZldHRpbmcsIGFwcHJvdmFs IGFuZCBvdGhlciBwcm9jZXNzZXMgbWF5IGJlIG5lZWRlZCwgd2hpY2ggY291bGQgdGFrZSB0aW1l LCBiZWZvcmUgdGhlIGFjY291bnQgaXMgZXN0YWJsaXNoZWQuICZuYnNwO1RoZSByZXN1bHQgb2Yg Y3JlYXRpbmcgYSBuZXcgYWNjb3VudCB3b3VsZA0KIGJlIGEgdXNlcm5hbWUgYW5kIHBhc3N3b3Jk LCB3aGljaCB3b3VsZCBiZSBtYW51YWxseSBlbnRlcmVkIGludG8gdGhlIFJVRSBkZXZpY2UgdG8g YWxsb3cgY29ubmVjdGlvbiB0byB0aGUgUHJvdmlkZXIuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDIzLCAyMDIxLCBhdCA0OjQwIFBN LCBFdWdlbmUgQ2hyaXN0ZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplY2hyaXN0ZW5zZW5Ac29y ZW5zb24uY29tIj5lY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFuayB5b3UgQnJpYW4g YW5kIFBhdWwgZm9yIHlvdXIgcmVzcG9uc2VzLiZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkaW5nIElQdjQvSVB2NiwgSSBjYW4gc2VlIHlv dXIgcG9pbnQgdGhhdCBhIHBhdGggZm9yd2FyZCBpcyBuZWVkZWQgZHVlIHRvIHRoZSBkaW1pbmlz aGluZyBhdmFpbGFiaWxpdHkgb2YgSVB2NCBhZGRyZXNzZXMuJm5ic3A7IFRoYW5rcyBQYXVsIGZv ciBwb2ludGluZyBvdXQgdGhhdCB0aGUgSVB2NiByZXF1aXJlbWVudCB3b3VsZCBiZSBvbiB0aGUg UlVFIG9ubHkgYW5kIHNlcnZlcnMgY2FuIGNvbnRpbnVlIHRvDQogcnVuIG9uIGVpdGhlci9ib3Ro ICh3aXRoIGEgZ2F0ZXdheSBpZiBuZWNlc3NhcnkpLiZuYnNwOyBUaGlzIHNvdW5kcyBsaWtlIGFu IGFwcHJvcHJpYXRlIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRpbmcgc2VjdGlvbiA5LjIgYW5kIHRoZSB2ZXR0aW5n IG9mIG5ldyB1c2Vycywgd2hlbiBJIHJlYWQgdGhyb3VnaCBpdCBpbml0aWFsbHksIG15IGFzc3Vt cHRpb24gd2FzIHRoYXQgdGhlIHByb2Nlc3Mgd2FzIG9uZSB0aGF0IHdvdWxkIGJlIGNvbXBsZXRl ZCBpbiByZWFsIHRpbWUuJm5ic3A7IEl0IHNvdW5kcyBsaWtlIHRoYXQgbXVzdCBub3QgYmUgdGhl IGludGVudC4mbmJzcDsgSSB3b25kZXIgaWYgaXQgbWlnaHQgYmUNCiBoZWxwZnVsIHRvIGhhdmUg c29tZXRoaW5nIHRoYXQgY2FsbHMgdGhhdCBvdXQ7IHRoYXQgaXQgaXNu4oCZdCBpbnRlbmRlZCB0 byBiZSBzeW5jaHJvbm91cyBmb3IgYSBuZXcgdXNlciBidXQgcmF0aGVyIHRoYXQgaXQgcHJvdmlk ZXMgYSBzdGFydGluZyBwb2ludCBmb3IgZ2V0dGluZyByZWdpc3RlcmVkIHdpdGggdGhlIHByb3Zp ZGVyPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CVFcsIHRoYW5rIHlvdSBmb3IgYWRkaW5nIHRoYXQgYW4gQVBJIGtleSBNQVkgYmUgdXNlZC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RXVn ZW5lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5CcmlhbiBSb3NlbiAm bHQ7PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlhbnJvc2VuLm5ldDwv YT4mZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxi cj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj5UdWVzZGF5LCBGZWJydWFyeSA5LCAyMDIxIDk6NTQgQU08YnI+DQo8Yj5Ubzo8L2I+ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkV1Z2VuZSBD aHJpc3RlbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20i PmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb208L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRv OnJ1bUBpZXRmLm9yZyI+cnVtQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW1J1bV0gSS1E IEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+W0VYVEVSTkFMXTwvc3Bhbj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRmViIDksIDIwMjEsIGF0IDExOjI3 IEFNLCBFdWdlbmUgQ2hyaXN0ZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzplY2hyaXN0ZW5zZW5A c29yZW5zb24uY29tIj5lY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaSBCcmlhbiw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZSBhIGZl dyB0aG91Z2h0cyBvbiB0aGlzIGFuZCBhIGZldyB0eXBvcyB0aGF0IEnigJlsbCBwb2ludCBvdXQu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPlN1YnN0YW5jZSBDb21tZW50czwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzEiPg0KU2Vj dGlvbiA0OiBSZXF1aXJlbWVudCBmb3IgSVB2NCBhbmQgSVB2Ni4mbmJzcDsgV2h5IGlzIElQdjYg bm93IGEgcmVxdWlyZW1lbnQ/Jm5ic3A7IFdoeSBub3Qgb3B0aW9uYWw/PG86cD48L286cD48L2xp PjwvdWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5CZWNhdXNlIHRoZSB3b3JsZCBoYXMgbW92ZWQgb24sIHRoZXJlIGFyZSBubyBtb3JlIElQdjQg YWRkcmVzc2VzLCBtYW55IG5ldHdvcmtzIGFyZSBJUHY2IG9ubHkgbm93LCBhbmQgd2UgbmVlZCBh IGdvb2QgcmVhc29uIHRvIG5vdCByZXF1aXJlIGl0IGluIHRoZSBJRVRGLjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi10 b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0K Jm5ic3A7PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFy Z2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0K U2VjdGlvbiA5LjIgLSBUaGUgdmV0dGluZyBwcm9jZXNzIGZvciBhIHBvdGVudGlhbCBjdXN0b21l ciBkb2VzIG5vdCBsZW5kIGl0c2VsZiB0byBhIHBlcnNvbiBiZWluZyBhYmxlIHRvIHNpbXBseSBz aWduIHVwIGxpa2UgdGhpcy4mbmJzcDsgVGhlIGN1c3RvbWVyIHdpbGwgYmUgcmVxdWlyZWQgdG8g aGF2ZSBhbiBhY2NvdW50IGJlZm9yZSBiZWluZyBhYmxlIHRvIGNvbW11bmljYXRlIHdpdGggdGhl IHByb3ZpZGVyIHNlcnZpY2UuJm5ic3A7IEkgdGhlcmVmb3JlIGJlbGlldmUNCiB3ZSBzaG91bGQg cmVtb3ZlIHRoZSBhYmlsaXR5IGZvciB0aGUgUlVFIGRldmljZSB0byBjb21tdW5pY2F0ZSB3aXRo IHRoZSBwcm92aWRlciB3aXRob3V0IGEgdXNlcmlkL3Bhc3N3b3JkLjxvOnA+PC9vOnA+PC9saT48 L3VsPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHByb2Nlc3MgaGFzIHRvIHN0YXJ0IHNvbWUgaG93IHRoYXQgZG9lc27igJl0IGludm9sdmUg YSBwaG9uZSBjYWxsLiAmbmJzcDtUYWtlIGEgcmVhbGx5IHNpbXBsZSBleGFtcGxlOiBJ4oCZbSBk ZWFmLCBJIGhhdmUgYW4gYWNjb3VudCB3aXRoIHByb3ZpZGVyIFgsIEkgd2FudCB0byBlc3RhYmxp c2ggYW5vdGhlciBhY2NvdW50IHdpdGggcHJvdmlkZXIgWS4gJm5ic3A7Q2Fu4oCZdCBJIGRvIHRo YXQgd2l0aCBhIHdlYnNpdGU/ICZuYnNwO0Nhbg0KIEkgZ2V0IGhlbHAgdmlhIGEgdmlkZW9waG9u ZT8gJm5ic3A7VGhlIHdheSBpdOKAmXMgY3VycmVudGx5IGRlZmluZWQgYWxsIHRoYXQgaGFwcGVu cyBpcyB5b3UgZ2V0IGEgVVJJIGZvciB0aGUgd2Vic2l0ZSBhbmQgYW5vdGhlciBmb3IgYSBoZWxw IGRlc2suICZuYnNwO1lvdSBkb27igJl0IGdldCBhbnl0aGluZyBvdXQgb2YgaXQuICZuYnNwO1do ZW4gYWxsIHRoZSB2ZXR0aW5nIGlzIGZpbmlzaGVkLCB5b3UgZW5kIHVwIHdpdGggYSB1c2VyaWQg YW5kIHBhc3N3b3JkLCBhbmQgeW91DQogbWFudWFsbHkgZW50ZXIgdGhhdCBpbnRvIHRoZSBSVUUu ICZuYnNwO1doYXQgYW0gSSBtaXNzaW5nPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDow aW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOjBpbjttYXJnaW4tYm90dG9tOjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+DQombmJz cDs8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4t dG9wOjBpbjttYXJnaW4tYm90dG9tOjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+DQpTZWN0 aW9uIDkuMiAtIEluIHRoZSBzZWN0aW9uIGZvciB0aGUgcGF5bG9hZCwgaXQgaXMgbWlzc2luZyB0 aGUgcHJvdmlkZXItZG9tYWluIGluIHRoZSB0ZXh0IHNlY3Rpb24gYnV0IGl0IGlzIGluY2x1ZGVk IGluIHRoZSBleGFtcGxlLiZuYnNwOyBJIGV4cGVjdCB0aGlzIGlzIHNpbXBseSBhbiBvdmVyc2ln aHQuPG86cD48L286cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JdOKAmXMgdGhlIGRvbWFpbiBpbiB0aGUgcHJvdmlkZXItbGlz dC4gJm5ic3A7SSBjYW4gbWFrZSB0aGF0IGNsZWFyZXI8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlw ZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6MGlu O21hcmdpbi1ib3R0b206MGluO21zby1saXN0OmwzIGxldmVsMSBsZm80Ij4NCiZuYnNwOzxvOnA+ PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPlR5cG8gQ29tbWVudHM8L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhhbmtzIGZvciB0aGVzZSwgSeKAmWxsIGZpeCB0aGVtPGJyPg0KPGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4i IHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tdG9w OjBpbjttYXJnaW4tYm90dG9tOjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvNSI+DQpTZWN0aW9u IDUuNSwmbmJzcDsgUmVtb3ZlIHJlZHVuZGFudCAmcXVvdDt0aGF0JnF1b3Q7IGZyb20gZmlyc3Qg c2VudGVuY2UgJnF1b3Q7dGhhdCB0aGF0JnF1b3Q7PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0i TXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0KU2VjdGlvbiA5LCZuYnNwOyAybmQgc2VudGVuY2UgcmVh ZHMgYXdrd2FyZGx5LiZuYnNwOyBQZXJoYXBzIGNoYW5nZSB0byAmcXVvdDtPbmUgcHJvdmlkZXMg YSBkaXJlY3Rvcnkgb2YgcHJvdmlkZXJzIHNvIHRoYXQgYSB1c2VyIGludGVyZmFjZSBhbGxvd3Mg ZWFzeSBwcm92aWRlciBzZWxlY3Rpb24gLi4uJnF1b3Q7PG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0KU2VjdGlvbiA5LjEsIGdldCByaWQgb2YgZXh0cmEg JnF1b3Q7YSZxdW90OyBpbiB0aGUgc2VjdGlvbiAmcXVvdDsuLi5hIGNvdW50cnkgY29kZSBzdWl0 YWJsZSBmb3IgZGlzcGxheSwgd2l0aCBhIGNvcnJlc3BvbmRpbmcgJnF1b3Q7YSZxdW90OyBVUkkg Li4uPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LXRvcDowaW47bWFyZ2luLWJvdHRvbTowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzUiPg0KU2Vj dGlvbiA5LjIsIGdldCByaWQgb2YgZXh0cmEgJnF1b3Q7dGhlJnF1b3Q7IGluIHRoZSBmaXJzdCBz ZW50ZW5jZSAmcXVvdDsuLi5wcm92aWRlciBjb25maWd1cmF0aW9uICZxdW90O3RoZSZxdW90OyB1 c2luZyBhIHNpbXBsZS4uLiZxdW90OzxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb1BsYWlu VGV4dCIgc3R5bGU9Im1hcmdpbi10b3A6MGluO21hcmdpbi1ib3R0b206MGluO21zby1saXN0Omwx IGxldmVsMSBsZm81Ij4NClNlY3Rpb24gOS40IC0gR2V0IHJpZCBvZiB0aGUgcmVkdW5kYW50IHdv cmQgJnF1b3Q7U2VjdGlvbnMmcXVvdDsgaW4gdGhlIGZpcnN0IHNlbnRlbmNlICZxdW90O1RoZSBp bnRlcmZhY2VzIGluICZxdW90O1NlY3Rpb25zJnF1b3Q7IFNlY3Rpb24gOS4xIC4uLiZxdW90Ozxv OnA+PC9vOnA+PC9saT48L3VsPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5FdWdlbmUgQ2hyaXN0ZW5zZW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5S dW0gJmx0OzxhIGhyZWY9Im1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZyI+cnVtLWJvdW5jZXNA aWV0Zi5vcmc8L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9iPkJyaWFuDQogUm9zZW48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJpZGF5LCBGZWJydWFy eSA1LCAyMDIxIDM6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydW1AaWV0Zi5vcmciPnJ1 bUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W1J1bV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLXJ1bS1ydWUtMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bRVhURVJOQUxdPC9zcGFuPiZuYnNwO0kgaGF2 ZSBwb3N0ZWQgYSAtMDQgcmV2aXNpb24uICZuYnNwO1RoaXMgc2hvdWxkIGhhbmRsZSBhbGwgY29t bWVudHMgcmVjZWl2ZWQgc28gZmFyLCBwbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBmb3Jnb3Qgc29t ZXRoaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhpcyB2ZXJzaW9uIHJld29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZpZ3VyYXRpb24g c2VjdGlvbnMgYWxvbmcgdGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5v dCBoYXZlIGEgd2F5IHRvIGRvd25sb2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQgZnJvbSBhIG5ldyBz aWdudXAuICZuYnNwO0nigJltIGhhdmluZyB0cm91YmxlIHRoaW5raW5nIGFib3V0IGEgc2VjdXJl IHdheSB0byBkbyB0aGF0LiAmbmJzcDtJZiBhbnlvbmUgaGFzIGFuIGlkZWEsIEnigJltIHZlcnkg d2lsbGluZyB0byB3cml0ZSB0ZXh0IGZvciBpdC4gJm5ic3A7SeKAmXZlIGNvbnNpZGVyZWQgdGhp bmdzIGxpa2UgamF2YXNjcmlwdCB0aGF0DQogc3Rhc2hlcyBpdCBpbiBhIGZpbGUgb3Igc29tZXdo ZXJlIGVsc2UsIGhhdmluZyBzb21lIHdlYiBwYWdlIGZ1bmN0aW9uIHRoYXQgdHJpZ2dlcnMgYSBs b2NhbCBkaXNwbGF5IG9mIGFuIGVudHJ5IGZvcm0gZm9yIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwg YW5kIGEgY291cGxlIG9mIG90aGVyIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG5vdGUgb24gdGhlIGNvbmZpZ3VyYXRp b24gbWVjaGFuaXNtIC0gYmVjYXVzZSB0aGUgb25seSB0aGluZyB0aGUgbG9jYWwgUlVFIGRldmlj ZSBuZWVkcyB0byBrZWVwIGlzIHRoZSB1c2VybmFtZSBwYXNzd29yZCBhZ2FpbnN0IGEgcHJvdmlk ZXIgSUQgb2Ygc29tZSBraW5kLCB0aGVyZSBpc27igJl0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXpl IGhvdyB0aGF0IHdvcmtzLCBhbmQgc28gaXTigJlzIGNvbXBsZXRlbHkNCiBhYnNlbnQgaW4gdGhl IHRleHQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb3Igbm93LCBJ4oCZdmUgcmVtb3ZlZCB0aGUgc3RlcCBieSBzdGVwIGRp YWdyYW0gdGhhdCBzaG93ZWQgaG93IHRoZSBjb25maWcgbWVjaGFuaXNtIGlzIHVzZWQuICZuYnNw O0kgdGhpbmsgd2hhdCBpcyB0aGVyZSBpcyBkZWFkIHNpbXBsZSBhbmQgbmVlZHMgbm8gZXhwbGFu YXRpb246IGl04oCZcyBhIHN0cmFpZ2h0Zm9yd2FyZCBSRVNUL0pTT04gd2ViIHNlcnZpY2UgdXNp bmcgdXNlcm5hbWUvcGFzc3dvcmQgYXV0aGVudGljYXRpb24NCiBmb3IgcHJvdmlkZXJzIHRoZSB1 c2VyIGhhcyBhY2NvdW50cyB3aXRoLiAmbmJzcDtJIGNhbiBicmluZyBiYWNrIHRoZSBkaWFncmFt IGlmIHRoYXQgaXMgbmVlZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9hPjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1y dW0tcnVlLTA0LnR4dDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkRh dGU6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5GZWJydWFyeSA1LCAyMDIxIGF0IDU6MTc6MTUgUE0gRVNUPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZsdDs8YSBocmVmPSJtYWlsdG86aS1kLWFu bm91bmNlQGlldGYub3JnIj5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L2E+Jmd0Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJtYWlsdG86cnVtQGll dGYub3JnIj5ydW1AaWV0Zi5vcmc8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5SZXBseS1Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4sPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydW1AaWV0Zi5vcmciPnJ1 bUBpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJv bSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFm dCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZSBJRVRG Ljxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1Rp dGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOzogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVxdWlwbWVu dDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvciAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEJy aWFuIFJvc2VuPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dDxicj4NCjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFu PjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QYWdlcyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs6IDMzPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPkRhdGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMDIxLTAyLTA1PGJyPg0KPGJyPg0KQWJz dHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7VmlkZW8gUmVsYXkgU2VydmljZSAoVlJTKSBpcyBhIHRl cm0gdXNlZCB0byBkZXNjcmliZSBhIG1ldGhvZCBieTxicj4NCiZuYnNwOyZuYnNwO3doaWNoIGEg aGVhcmluZyBwZXJzb25zIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGRlYWYvSGFyZCBvZiBIZWFyaW5n PGJyPg0KJm5ic3A7Jm5ic3A7dXNlciB1c2luZyBhbiBpbnRlcnByZXRlciAoJnF1b3Q7Q29tbXVu aWNhdGlvbnMgQXNzaXN0YW50JnF1b3Q7KSBjb25uZWN0ZWQgdmlhPGJyPg0KJm5ic3A7Jm5ic3A7 YSB2aWRlb3Bob25lIHRvIHRoZSBkZWFmL0hvSCB1c2VyIGFuZCBhbiBhdWRpbyB0ZWxlcGhvbmUg Y2FsbCB0byB0aGU8YnI+DQombmJzcDsmbmJzcDtoZWFyaW5nIHVzZXIuICZuYnNwO1RoZSBDQSBp bnRlcnByZXRzIHVzaW5nIHNpZ24gbGFuZ3VhZ2Ugb24gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7dmlk ZW9waG9uZSBsaW5rIGFuZCB2b2ljZSBvbiB0aGUgdGVsZXBob25lIGxpbmsuICZuYnNwO09mdGVu IHRoZTxicj4NCiZuYnNwOyZuYnNwO2ludGVycHJldGVycyBtYXkgYmUgc3VwcGxpZWQgYnkgYSBj b21wYW55IG9yIGFnZW5jeSB0ZXJtZWQgYTxicj4NCiZuYnNwOyZuYnNwOyZxdW90O3Byb3ZpZGVy JnF1b3Q7IGluIHRoaXMgZG9jdW1lbnQuICZuYnNwO1RoZSBwcm92aWRlciBhbHNvIHByb3ZpZGVz IGEgdmlkZW88YnI+DQombmJzcDsmbmJzcDtzZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNv bm5lY3QgdmlkZW8gZGV2aWNlcyB0byB0aGVpciBzZXJ2aWNlLDxicj4NCiZuYnNwOyZuYnNwO2Fu ZCBzdWJzZXF1ZW50bHkgdG8gQ0FzIGFuZCBvdGhlciBkZWFmL0hvSCB1c2Vycy4gJm5ic3A7SXQg aXMgZGVzaXJhYmxlPGJyPg0KJm5ic3A7Jm5ic3A7dGhhdCB0aGUgdmlkZW9waG9uZXMgdXNlZCBi eSB0aGUgZGVhZi9Ib0gvSC1JIHVzZXIgY29uZm9ybSB0byBhPGJyPg0KJm5ic3A7Jm5ic3A7c3Rh bmRhcmQgc28gdGhhdCBhbnkgZGV2aWNlIG1heSBiZSB1c2VkIHdpdGggYW55IHByb3ZpZGVyIGFu ZCB0aGF0PGJyPg0KJm5ic3A7Jm5ic3A7dmlkZW8gY2FsbHMgZGlyZWN0IGJldHdlZW4gZGVhZi9I b0ggdXNlcnMgd29yay4gJm5ic3A7VGhpcyBkb2N1bWVudDxicj4NCiZuYnNwOyZuYnNwO2Rlc2Ny aWJlcyB0aGUgaW50ZXJmYWNlIGJldHdlZW4gYSB2aWRlb3Bob25lIGFuZCBhIHByb3ZpZGVyLjxi cj4NCjxicj4NCjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlz IGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtcnVtLXJ1ZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWlldGYtcnVtLXJ1ZS88L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZl cnNpb24gYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2Fy Y2hpdmUvaWQvZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3Jn L2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0bWw8L2E+PGJyPg0KPGJyPg0KQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUt MDQiPmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUt MDQ8L2E+PGJyPg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNv dXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuPGJyPg0KPGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9u eW1vdXMgRlRQIGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvIj5mdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+ DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkktRC1Bbm5vdW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SS1ELUFu bm91bmNlQGlldGYub3JnIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC9hPjxicj4NCklu dGVybmV0LURyYWZ0IGRpcmVjdG9yaWVzOiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3No YWRvdy5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPjxicj4NCm9yIDxh IGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0Ij5mdHA6Ly9m dHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR04MB4983C8AE1E79461C8721EB50A3809BYAPR04MB4983namp_-- From nobody Wed Feb 24 09:41:54 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 4F8C83A18A8 for ; Wed, 24 Feb 2021 09:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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] 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 S4jBZ3Pz9J9W for ; Wed, 24 Feb 2021 09:41:44 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2056.outbound.protection.outlook.com [40.107.220.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 28BEC3A18BF for ; Wed, 24 Feb 2021 09:41:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JDWeAKBwdYnmOixLtEHP1aeXVC3VDzgoe1/ZCIxntpNPRyiCAIiN8+XIjiLWgOBFnuMVHNhHquLdpxxrv+X1tUfipJC0lb/HL60jqtd+F1GseVOH3uWyvcJyJNtsKZ4/uAce57d5IPlD40pCmUblhWCpsBAreHImiJSSTvfSxuy+2mnL9+TBwBj+tht1d+BEatBxlgIy9GH6fbNs8WKnRSoaCmh0ykk0U4Ny7JPhQZleWMvu48xSasPBKyV6TfCb+JH+X09dFAPZgy5wyq8F2QfWVoqd8c931RZRXdDVWkPRgv5yR1BMFrpISguvY9Mct8yo+6h8m7SLCHHuVPhDWQ== 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=psKii8KsV6qBB4/IdgFGGo+Tjn7QyfdpmcAgT6TIluQ=; b=VIekFfeZLAgKrgPWGuaKGYT5rIrTSjcyeU8t45qY+FIy59FuX5zd/8ceRxUGxLpvcRAghygPB8ymiM/pgypi+39xmPq1wceHD/SmV1fy5kU4f/v5cgpIU2+Gco1KGfdZzjXqGHXqDs14VYCYWHmSRZMp8CkQ+ZVPktzJKWVKaV3hzGlRSU78ZsGj9hK1YhmaMlLIVfGZX+A8iUmfQ/IhuxzRzxGDFH1tCjOvNcFhAsX/S/+KKJ7OTa9qfR9LxDakIZFqXQUUkqr3wZntptd7KVaNjerWGjtgljuSII+YDnzFgpxdxnpLfob47b9LwCDyPTuPxw8DVWYBE/fMJfwxRA== 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=psKii8KsV6qBB4/IdgFGGo+Tjn7QyfdpmcAgT6TIluQ=; b=WqAFoZqlOlVT/iWYjner+rNE/HBvH0x6Mt34eBLkfSbtEPMj+aw55q0iwdhdTv7jV/OfHkprVg+qfW1083QvLqU4KJpRPG3HWzMOYqOUEnw2LygRWPs/3kNj+1itwQ1fCkaZ6rU2ZSO1tcgSbDv/mGKHJ0z5pvXQ5IiPq6N46z8= Received: from CY4PR1701CA0005.namprd17.prod.outlook.com (2603:10b6:910:5e::15) by MWHPR1201MB0189.namprd12.prod.outlook.com (2603:10b6:301:59::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.27; Wed, 24 Feb 2021 17:41:42 +0000 Received: from CY1NAM02FT046.eop-nam02.prod.protection.outlook.com (2603:10b6:910:5e:cafe::5b) by CY4PR1701CA0005.outlook.office365.com (2603:10b6:910:5e::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Wed, 24 Feb 2021 17:41:42 +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 CY1NAM02FT046.mail.protection.outlook.com (10.152.74.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Wed, 24 Feb 2021 17:41: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 11OHfdjN014470 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Wed, 24 Feb 2021 12:41:40 -0500 To: Brian Rosen Cc: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <3F27DC25-DED9-4669-BE8A-332F4C432824@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Wed, 24 Feb 2021 12:41:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: <3F27DC25-DED9-4669-BE8A-332F4C432824@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: 38f82518-0b43-482f-a856-08d8d8eb7241 X-MS-TrafficTypeDiagnostic: MWHPR1201MB0189: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1fCNfWWZeiqRpxUy6JCo1/pnJDjujE4Ag+pq/N1QsI+GUUG0mgr+IZiY456jGehwTUX8PRTAhJNUQ72JUuOL/boWXVLOmu4VE88ymTrCzOi/VqICLnCNRfy2PMJGG4dy0h7jgbG6v6nR+qPInIbabefrRosgDYGQEmvnw46+rZPocKfSRrsSXnMX+nqDrZWDzgTuB6HgNi4ZfLB0R5VEnUGrzWpzIr9g20KFpsD2eaPn84LBgZzWv/mX0mayQx379x5v9AL6RJnS5whSqaTQWQyXgjXqiGdtx7NX4cjlvkFCfgoCBdCFwQ63bEvwrj6tOOVWCCkpg5jLFbxSnNTtFBgNs48btgOK2ux4d5qxLq2iU1VjqEMki9Csa47r84HjkYwa50vN6sKo77VxWrAlW4NMAtwhUerCLWzDw7g/2AkKh5wVsz4zdkuf0LLbDgQ5nmJfgK7ZATItdrnyln6tdT6rBCoVrSH6BaHfw23wthkfjijLf9C0ZxkGQ9IYQZw3G4AuXX9wPtgJKZmeO1/3ZqK+oNA+yViROR0YkmwUY+Gs4YkAGLiMHejab2pgo1cQ9/KQqjCeUvXlfznjWYuEsYnej2XfmBctW2fN+FNUCPavR0kfO39lVoysXu7jismXX2Dkrbe5yQDuzZSSqrsxczSrasJ9j3p7RQnuhbygA7FKKIM/YmBywrO3taFc8Q9s 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)(396003)(346002)(376002)(36840700001)(46966006)(26005)(53546011)(82310400003)(31686004)(316002)(8936002)(36906005)(36860700001)(786003)(75432002)(8676002)(336012)(47076005)(6916009)(30864003)(70206006)(83380400001)(31696002)(356005)(956004)(70586007)(7596003)(2906002)(2616005)(5660300002)(86362001)(186003)(82740400003)(4326008)(478600001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Feb 2021 17:41:41.5916 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 38f82518-0b43-482f-a856-08d8d8eb7241 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: CY1NAM02FT046.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1201MB0189 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Wed, 24 Feb 2021 17:41:53 -0000 Brian, On 2/8/21 7:48 PM, Brian Rosen wrote: > Thanks for the comments.  Responses inline I just realized I never replied to this. >> On Feb 6, 2021, at 5:08 PM, Paul Kyzivat > > wrote: >> >> Brian, >> >> Comments on this posted version: >> >> * "Dial-around call": what about inbound dial-around calls? Is there >> anything meaningful that we can say about them? IIUC the only way to >> achieve that is for the hearing user to dial the front door number of >> the provider he wants to handle the call. If that is the only way then >> the RUE and its user are not involved and so nothing can/should be said. > Yeah, the RUE doesn’t directly deal with them.  They go to the default > provider, who forwards them to the RUE.  Do we need to say that? Hmm. Not sure. Perhaps not, since the RUE has no role in it. Perhaps somewhere we could say *that* - that handling of inbound dial-around is out-of-scope for this document. >> *  5.2.4 Incoming Calls: >> >> This says: >> >>   The RUE MUST only accept inbound calls sent to it by the proxy >>   mentioned in the configuration. >> >> But IIUC if proxies are configured then the RUE is require to use >> [RFC5626] (Outbound). But the provider isn't required to support/use >> outbound. What is to happen with a provider that doesn't? Perhaps we >> need to separate the configuration of proxies from configuring the use >> of outbound with those proxies. > Can we say that if multiple proxies are mentioned the provider MUST > support Outbound? You mean that if *one* proxy is configured then outbound is optional, but if two or more are configured then outbound is required? ISTM that in the absence of outbound the way to utilize multiple proxies is undefined. I can think of two possibilities: 1) All included in the Route header. I don't see any reason to have this as a feature. (If needed it can be accomplished with Service-Route.) 2) The RUE uses them as alternatives. This can be accomplished using DNS, so doing via explicit configuration seems silly.) Unless there is some other compelling way to use multiple proxies without outbound then I am fine with reserving this for use with outbound. >> If outbound *is* used then it is easy to determine that incoming calls >> arrive from the proxy. But if outbound *isn't* used then there isn't >> any obvious way for the RUE to figure this out >> >> ISTM we either must *require* use of outbound, or remove this >> requirement to only accept calls from the configured proxy, or detail >> how to do this verification in the absence of outbound. >> >> (I think there may be some resistance to use of outbound in mobile >> RUEs because it can significantly increase the power demand.) In the absence of outbound I still don't see how the RUE can restrict the source of incoming requests. Perhaps we simply say that if using outbound then requests MUST only be accepted via the outbound connection. But note that is further complicated if the RUE is connected to multiple providers. I think the wording to cover this may be tricky. But we need to sort out what we want the rules to be before deciding how best to state them. >> * 9.1 RUE Provider Selection >> >> This section talks about backward compatibility without defining it. >> While people may have an intuitive understanding of it, they may not >> all understand it the same way. >> >> It may be better to define this as a requirement that if you advertise >> support for M.N you are also implicitly promising that you support M.i >> for 0<=i> minor version is defined in order to make it feasible for >> implementations to make this guarantee, but we need not go into that.) > I reworded it to say: > To achieve backwards compatibility, implementations MUST ignore any > object members they do not implement and minor version definitions SHALL > only add objects, non-required members of existing objects, and > non-mandatory-to use functions and SHALL NOT delete any objects, members > of objects or functions.  This means an implementation of a specific > major version and minor version is backwards compatible with all minor > versions of the major version. As I noted above, defining the requirement for backward compatibility is distinct from deciding how revisions should be written to facilitate that compatibility. I agree with the first part of your statement above, but suggest a slight rewording: "To facilitate backwards compatibility, implementations MUST ignore any object members they do not implement." The other part isn't a requirement on implementation of this spec. It is a requirement on how future revisions of this spec are to be written. I don't think normative language is appropriate here. But I think it could be reworked as a note for future revisions: "NOTE: In the future, when the schema for a new minor version is written it should only add objects, non-required members of existing objects, and non-mandatory-to use functions and should not delete any objects, members of objects or functions. Then an implementation of that new minor version will automatically be backwards syntactically compatible with the predecessor." (There could be behavior changes not reflected in the schema that also impact backward compatibility. E.g., deprecation of versions of protocols.) >> This way of handling versioning has one limitation: The manner of >> retrieving the version list must remain supported for all future >> versions. Alternatively, we might instead put some or all of this >> version info into the IANA registry, so that future versions might >> require some other sort of interface. > Yes, the version mechanism has to remain available and at least > backwards compatible to V1.  I don’t think that is a problem, and there > are no protocol police if some future work group breaks the assumption. At the least, I think we should add the requirement to ignore unknown object members, so that revisions to the version list are possible. >> * 9.2 RUE Configuration Service: >> >> What is the intended purpose/use of the language tags? Should this >> indicate the spoken language supported by the interpreter for >> interacting with hearing people? Or the written language on a web >> interface? Or the language used in finger spelling? Or different >> versions of sign language? > Sign language for interacting with the RUE user [NOTE: I am woefully uninformed about language coding, so I am likely to be saying something stupid here.] I note that the example codes "en" and "es", which I think are spoken and/or written language codes. ISTM that there are likely to be reasons to code sign language, spoken language and written language. But we may need to specify exactly what coding a particular language is promising. Can some providers please chime in here? What degrees of freedom do you have in this regard? >> For dialAround and helpDesk, should there be a URI or phone number or >> both? How would the RUE and deaf user use the URI to initiate a call? >> (Currently the spec constrains the To URI in a call to be based on an >> E164 number.) We don't specify the UI, but presumably the RUE might >> offer special UI for these, or not. If not then I guess it would have >> to make this configuration info available somehow. Else these things >> could be pre-populated in the address book. (I think that is how >> providers do it today.) > For the help desk, I wanted this to not require an existing relationship > with any provider.  So it’s a SIP URI that doesn’t need a proxy that > establishes a video call to a sign-language capable helper. One point I was making here is that we don't currently provide any specification for calling by sip URL - only by phone number. If the config specifies a phone number then we have enough defined for the RUE to implement this. If we specify a URL here then we need to add some text elsewhere for initiating calls by URL, even if that is only for configured URLs and not for ones entered via the GUI. > For dial around, it’s whatever it takes to video call point-to-point > using the default provider.  In the US that would be a 10 digit number > that was in the iTRS Directory, but that might be different in some > other country For frontDoor, same comment as above for helpdesk. For oneStage, while the provider config includes a oneStage dialaround URL and Figure 1 shows using that in a Route header, I can find no normative text specifying the inclusion of that URL in a Route for a dialaround call. I guess it should be added to section 5.2.2. > Suggestions on wording? > >> >> Re "outbound-proxy": this needs to be a list/array to allow multiple >> values. The example shows this (and calls the key "outbound-proxies") >> but the description is singular and doesn't mention an array. > I can fix that, but I want to ask if there is an actual use case for it? >  Why would a provider have more than one URI for a particular > user/phone number?  Happy to fix it, but we would need to say how the > RUE uses it.  Incoming is clear (accept calls from any configured proxy). I'm baffled here. If using RFC5626 (outbound) then normally the UA will be using the same proxies for both inbound and outbound traffic. Multiple proxies configured for redundancy. And in any case your example already is showing multiple proxies although the schema doesn't agree. >> Finally, a style issue: The keywords are named in a mixture of >> camelCase and hyphenated words. (Like snake-case but with hyphens >> instead of underscores. I don't know of a name for this.) I think we >> need to pick a consistent style. > Pick one and I’ll fix everything to be consistent.  I like camelCase, > but don’t care I don't care either. If you like camelCase then that is fine. >> * 9.4 OpenAPI Interface Descriptions >> >> I don't know yaml, so I'm not going to attempt to comment on this now. >> I'll aim to come back after studying up on it. ... >> If the need for a new password occurs when the user is not present at >> the RUE, then it probably means that the user will no longer have >> incoming phone service until he notices. That is potentially a safety >> problem. So we should consider how to minimize this case. >> >> For instance, a few days/weeks before the provider ages out the >> password, it should notify the user, so the user can actively change >> the password and update the RUE. Of course the provider can do this >> out-of-band via email, but it would be nice to have a way to cause the >> RUE to inform the user. E.g., perhaps a MESSAGE sent from the provider >> to the RUE, that the RUE can then display. >> >> (And when the provider does invalidate a password the RUE should have >> enough information so it can take action to alert the user that action >> is required on his part to restore service. But 401 or 404 responses >> are probably sufficient to trigger this.) > Since, at the moment, there is no mechanism other than manual entry for > the RUE to learn the username and password, I think all of this is also > manual.  We could add mechanism for a password update if that’s helpful > without the initial password capture, but that would only be secure if > it used the old password to authenticate to update to a new one. I have become convinced that it can be left up to the provider to notify the user in advance when there is an impending requirement to revise the password. There are a variety of mechanisms they can use to do that, including video mail that could be signaled through the RUE. In the case of a need for provider to force a credential change without advanced notice, the worst case will end up with the RUE being forced to ask the user for new credentials that the user will have to learn out of band some way. A provider can probably find a way to avoid the worst of this. For instance, it might not revoke an existing registration, but still challenge an outgoing request for new credentials. But this becomes a quality-of-implementation issue. BTW, ISTM that the best way to do the manual configuration of pw is via the normal case of a request that has been sent to server, challenged by the server, and then the challenge being exposed to the user in the GUI. Thanks, Paul From nobody Thu Feb 25 00:21: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 01C3A3A156F for ; Thu, 25 Feb 2021 00:21:07 -0800 (PST) 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 Dbj1IlFos1Xl for ; Thu, 25 Feb 2021 00:21:01 -0800 (PST) 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 3ACB83A1575 for ; Thu, 25 Feb 2021 00:20:58 -0800 (PST) Received: from pinguicula.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 2FA9F3FA; Thu, 25 Feb 2021 09:20:56 +0100 (CET) From: "Olle E. Johansson" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_CBAB6DC0-42FB-4961-A8A4-2FF6374C86DD" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Thu, 25 Feb 2021 09:20:55 +0100 In-Reply-To: <1614100014388.54843@purple.us> Cc: Olle E Johansson , Brian Rosen , Jim Malloy , "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> <1614100014388.54843@purple.us> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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, 25 Feb 2021 08:21:07 -0000 --Apple-Mail=_CBAB6DC0-42FB-4961-A8A4-2FF6374C86DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think RUE should invent it=E2=80=99s own authentication = handling. For information on token handlings, including access tokens and refresh = tokens, please refer to Oauth2. That way we can simply reuse what=E2=80=99s existing. /O > On 23 Feb 2021, at 18:06, James Hamlin wrote: >=20 >=20 > It's been a while since the refresh token was discussed; but if it is = returned in the configuration, the RUE should replace/overwrite it's = stored copy of the user password with the token. The token would then be = valid where the user password was valid initially. Similarly, in further = refreshes of the config, if a refresh token is returned, it replaces the = previous token. That wouldn't have any effect on the ability to recover = from power failure.=20 > =20 > James >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Brian Rosen > > Sent: 23 February 2021 15:09 > To: James Hamlin > Cc: Jim Malloy; rum@ietf.org > Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =20 >=20 > Tell me a little more about how you think the refresh token would = work. Would it allow a device to have a power failure, come back, and = accept incoming calls? >=20 > Brian >=20 >=20 >=20 >> On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: >>=20 >> Brian >>=20 >> I think having the flexibility to optionally return separate = SIP/STUN/TURN credentials could be useful. Optionally returning a = refresh token which the RUE would hold in place of the user login = password would also be useful, as it would mean the login password would = not have to be stored after the first configuration; refreshing an = expired configuration would be done with the refresh token. >>=20 >> James >>=20 >>=20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com = >> The information contained in this e-mail message is intended=20 >> only for the personal and confidential use of the recipient(s)=20 >> named above. If you have received this communication in error,=20 >> please notify us immediately by e-mail, and delete the original=20 >> message. >>=20 >> From: Brian Rosen > >> Sent: 22 February 2021 18:46 >> To: James Hamlin >> Cc: Jim Malloy; rum@ietf.org >> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> Can we figure out how to converge on this?=20 >>=20 >> There are: >> a) Actual user login credentials >> b) SIP credentials >> c) STUN/TURN credentials >>=20 >> The current draft treats them all as identical. Is there a reason to = make them separate? My VoIP accounts have only one set. I=E2=80=99m = okay adding a separate SIP/STUN/TURN credential returned in the config = file, protected by the actual user login credentials, if that is really = useful. Maybe it could be optional, and if not provided, the = userid/password is used for everything. >>=20 >> Brian >>=20 >>> On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: >>>=20 >>> Jim >>>=20 >>> Yes credentials have to be cached, but not necessarily the user's = primary account credentials. The previous text allowed the configuration = service to send back separate credentials for SIP/STUN/TURN which could = have a shorter validity period than the main account credentials. This = offers greater flexibility in how a user's use of different RUE's can be = isolated. >>>=20 >>> I'll accept that the provider could offer a separate password for = use with each RUE type; we'd need to think about the logistical = implications of that. >>>=20 >>> Best Regards >>>=20 >>> James >>>=20 >>>=20 >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com = >>> The information contained in this e-mail message is intended=20 >>> only for the personal and confidential use of the recipient(s)=20 >>> named above. If you have received this communication in error,=20 >>> please notify us immediately by e-mail, and delete the original=20 >>> message. >>>=20 >>> =20 >>> From: Jim Malloy > >>> Sent: 09 February 2021 14:20 >>> To: Brian Rosen; James Hamlin >>> Cc: rum@ietf.org >>> Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> =E2=80=9CEvery VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use=E2=80=9D >>> =20 >>> James =E2=80=93=20 >>> =20 >>> Do existing ZVRS/Purple devices or mobile applications cache = authentication credentials? (Mobile applications may do so at the OS = level even if the application doesn=E2=80=99t explicitly do so.) If so, = is there a reason to treat the RUE Differently? >>> =20 >>> Thanks, >>>=20 >>> Jim Malloy >>> Principal Information System Engineer >>> The MITRE Corp. >>> 703 983 2835 >>> =20 >>> From: Rum > On = Behalf Of Brian Rosen >>> Sent: Tuesday, February 9, 2021 8:44 AM >>> To: Hamlin, James > >>> Cc: rum@ietf.org >>> Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> I=E2=80=99ll delete the text in registration. =20 >>> Every VoIP phone I=E2=80=99ve ever seen or used caches username and = passwords for stand alone use. Every one. They do that for a simple = reason - so incoming calls work after a power loss. Most also are = effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? >>> =20 >>> The text currently uses the same credentials for the HTTP service = and the SIP service, but that=E2=80=99s it. I think that=E2=80=99s = pretty reasonable. >>> =20 >>> If you have another proposal for how we can maintain the config data = securely, please suggest one. >>> =20 >>> Brian >>>=20 >>>=20 >>> On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: >>> =20 >>> Brian >>> =20 >>> Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >>> =20 >>> Best regards >>> =20 >>> James >>> =20 >>> =20 >>> =20 >>> =20 >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com = >>> The information contained in this e-mail message is intended=20 >>> only for the personal and confidential use of the recipient(s)=20 >>> named above. If you have received this communication in error,=20 >>> please notify us immediately by e-mail, and delete the original=20 >>> message. >>> =20 >>> From: Rum > on = behalf of Brian Rosen > >>> Sent: 05 February 2021 22:26 >>> To: rum@ietf.org >>> Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >>> =20 >>> This version reworks the provider list and configuration sections = along the lines we have been discussing. >>> =20 >>> I do not have a way to download a username/password from a new = signup. I=E2=80=99m having trouble thinking about a secure way to do = that. If anyone has an idea, I=E2=80=99m very willing to write text for = it. I=E2=80=99ve considered things like javascript that stashes it in a = file or somewhere else, having some web page function that triggers a = local display of an entry form for username and password, and a couple = of other things. >>> =20 >>> One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >>> =20 >>> For now, I=E2=80=99ve removed the step by step diagram that showed = how the config mechanism is used. I think what is there is dead simple = and needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >>> =20 >>> Brian >>> =20 >>>=20 >>>=20 >>> Begin forwarded message: >>> =20 >>> From: internet-drafts@ietf.org >>> Subject: I-D Action: draft-ietf-rum-rue-04.txt >>> Date: February 5, 2021 at 5:17:15 PM EST >>> To: > >>> Cc: rum@ietf.org >>> Reply-To: internet-drafts@ietf.org = , rum@ietf.org >>> =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-04.txt >>> Pages : 33 >>> Date : 2021-02-05 >>>=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-04.html = >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>>=20 >>>=20 >>> Please note that it may take a couple of minutes from the time of = submission >>> until the htmlized version and diff are available at tools.ietf.org = . >>>=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 >>> =20 >>=20 >>=20 >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_CBAB6DC0-42FB-4961-A8A4-2FF6374C86DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = don=E2=80=99t think RUE should invent it=E2=80=99s own authentication = handling.

For = information on token handlings, including access tokens and refresh = tokens, please refer to Oauth2.
That way we can simply = reuse what=E2=80=99s existing.

/O

On 23 = Feb 2021, at 18:06, James Hamlin <james.hamlin@purple.us> wrote:


It's been a while since the refresh = token was discussed; but if it is returned in the = configuration, the RUE should replace/overwrite = it's stored copy of the user password with the = token. The token would then be valid where the = user password was valid initially. Similarly, in = further refreshes of the config, if a refresh token is = returned, it replaces the previous token. That wouldn't have = any effect on the ability to recover from power failure. 
 
James

James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 15:09
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =  

Tell me a = little more about how you think the refresh token would work. =  Would it allow a device to have a power failure, come back, and = accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, = James Hamlin <james.hamlin@purple.us> wrote:

Brian

I think = having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a = refresh token which the RUE would hold in = place of the user = login password would also be useful, as it = would mean the login password would not = have to be stored after the = first configuration; refreshing an expired configuration = would be done with the refresh token.

James


James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP = credentials
c) STUN/TURN credentials

The current draft treats = them all as identical.  Is there a reason to make them separate? =  My VoIP accounts have only one set.  I=E2=80=99m okay adding = a separate SIP/STUN/TURN credential returned in the config file, = protected by the actual user login credentials, if that is really = useful.  Maybe it could be optional, and if not provided, the = userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote:

Jim

Yes = credentials have to be cached, but not necessarily the user's primary = account credentials. The previous text allowed the configuration service = to send back separate credentials for SIP/STUN/TURN which could have a = shorter validity period than the main account credentials. This offers = greater flexibility in how a user's use of = different RUE's can be isolated.

I'll accept that the provider could offer a = separate password for use with each RUE type; we'd need to think about = the logistical implications of that.

Best Regards

James


James = Hamlin
Contractor
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: Jim Malloy <jmalloy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James = Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D = Action: draft-ietf-rum-rue-04.txt
 
=E2=80=9CEvery VoIP phone = I=E2=80=99ve ever seen or used caches username and passwords for stand = alone use=E2=80=9D

 

James =E2=80=93 

 

Do existing ZVRS/Purple devices = or mobile applications cache authentication credentials?  (Mobile = applications may do so at the OS level even if the application doesn=E2=80= =99t explicitly do so.)  If so, is there a reason to treat the RUE = Differently?

 

Thanks,

Jim Malloy
Principal Information = System Engineer
The MITRE Corp.
703 983 = 2835

 

From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Tuesday, February 9, 2021 = 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt

 

I=E2=80=99ll delete the text in = registration.  
Every VoIP = phone I=E2=80=99ve ever seen or used caches username and passwords for = stand alone use.  Every one.  They do that for a simple reason = - so incoming calls work after a power loss.  Most also are = effectively set and forget, which is what you want in a phone.  Why = would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP = service and the SIP service, but that=E2=80=99s it.  I think = that=E2=80=99s pretty reasonable.

 

If you have another proposal for how we can maintain the = config data securely, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> = wrote:

 

Brian

 

Section 5.1 Registration says that = "The credentials to be used (username and password) MUST be supplied = within the credentials section of the configuration and identified by = the realm the registrar uses in a digest challenge. This = username/password combination SHOULD NOT be the same as that used for = other purposes, such as retrieving the RUE configuration or logging into = the Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we = need to avoid the RUM RUE caching the user's main account password, = which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 = February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt

 

I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.

 

This version reworks the provider list and configuration = sections along the lines we have been discussing.

 

I do not have a way to download a username/password from a new = signup.  I=E2=80=99m having trouble thinking about a secure way to = do that.  If anyone has an idea, I=E2=80=99m very willing to write = text for it.  I=E2=80=99ve considered things like javascript that = stashes it in a file or somewhere else, having some web page function = that triggers a local display of an entry form for username and = password, and a couple of other things.

 

One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =  

 

For now, I=E2=80=99ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is = dead simple and needs no explanation: it=E2=80=99s a straightforward = REST/JSON web service using username/password authentication for = providers the user has accounts with.  I can bring back the diagram = if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM = EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

 


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html=

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04<= br class=3D"">

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

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


_______________________________________________
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

 

 

 



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

= --Apple-Mail=_CBAB6DC0-42FB-4961-A8A4-2FF6374C86DD-- From nobody Thu Feb 25 00:50: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 767D83A15E5 for ; Thu, 25 Feb 2021 00:50:44 -0800 (PST) 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 0E4MeLNrdbl9 for ; Thu, 25 Feb 2021 00:50:40 -0800 (PST) Received: from outbound-ip1a.ess.barracuda.com (outbound-ip1a.ess.barracuda.com [209.222.82.168]) (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 AF5AD3A15EB for ; Thu, 25 Feb 2021 00:50:39 -0800 (PST) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx-outbound45-162.us-east-2c.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Thu, 25 Feb 2021 08:50:35 +0000 Received: from 1-WP-401-EXCH.purplenetwork.net (10.0.10.143) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 25 Feb 2021 00:49:51 -0800 Received: from 1-WP-401-EXCH.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb]) by 1-wp-401-exch.purplenetwork.net ([fe80::e190:fa54:4b11:2dfb%13]) with mapi id 15.00.1263.000; Thu, 25 Feb 2021 00:49:51 -0800 From: James Hamlin To: Brian Rosen CC: Jim Malloy , "rum@ietf.org" Thread-Topic: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHXCUsDkPazAWu3o0uzeatovVjWl6pl1NTpgACKVID//5fEj4AAjTQA//96TRyAAJttAIAB+P61 Date: Thu, 25 Feb 2021 08:49:50 +0000 Message-ID: <1614242988980.87424@purple.us> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> <1614100014388.54843@purple.us> <7AB4E72F-09B8-4016-A2CE-49C6B12EAA48@brianrosen.net> <1614102529543.36715@purple.us>, <2271089B-063E-4EAD-A508-4B5963D4E772@brianrosen.net> In-Reply-To: <2271089B-063E-4EAD-A508-4B5963D4E772@brianrosen.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_161424298898087424purpleus_" MIME-Version: 1.0 X-BESS-ID: 1614243034-111682-9172-149565-1 X-BESS-VER: 2019.1_20210223.2145 X-BESS-Apparent-Source-IP: 208.17.91.144 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.230446 [from cloudscan15-153.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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, 25 Feb 2021 08:50:45 -0000 --_000_161424298898087424purpleus_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Brian Having consulted internally, we are content if support for separate passwor= ds and tokens is dropped, as providers could always allocate users separate= RUM RUE passwords if required. Also we think the refresh token, as it was previously discussed, would have= been the result of using OAuth. So OAuth would have provided a token that = allowed the RUE to refresh its config without retaining the user password; = which fit's with Olle's suggestion. James James Hamlin Contractor 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: 23 February 2021 18:39 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Okay, let=92s walk through how this is used: 1. The user creates a new account. They create a username/password for the= account. That is stored in the device 2. The device retrieves configuration using the username/password 3. Configuration may contain a refresh token. This is a password. The tok= en is used instead if the actual password, but with the actual username, to= do SIP/STUN/TURN authentication. 4. The refresh token is used until the config retrieval changes it. Is that right? Can you explain why this is better than just using the acco= unt username/password? Brian On Feb 23, 2021, at 12:48 PM, James Hamlin > wrote: I was assuming the refresh token would simply stand in for the password lit= erally. That said, when the idea was previously discussed, the token would = have solely been used in authentication for config retrieval, as SIP would = use the password set by configuration. It has been a long time since the re= fresh token was discussed so others might remember more. I think the provider needs to keep one token valid until the next is first = used or make it valid for much longer than the configuration lifetime. James James Hamlin Contractor 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: 23 February 2021 17:21 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Is the token a username/password equivalent (meaning, does it use the norma= l SIP REGISTER authentication)? As long as it=92s valid until replaced, that=92s OK with me. Brian On Feb 23, 2021, at 12:06 PM, James Hamlin > wrote: It's been a while since the refresh token was discussed; but if it is retur= ned in the configuration, the RUE should replace/overwrite it's stored copy= of the user password with the token. The token would then be valid where t= he user password was valid initially. Similarly, in further refreshes of th= e config, if a refresh token is returned, it replaces the previous token. T= hat wouldn't have any effect on the ability to recover from power failure. James James Hamlin Contractor 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: 23 February 2021 15:09 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Okay, I=92ll add optional SIP/STUN/TURN credentials. Tell me a little more about how you think the refresh token would work. Wo= uld it allow a device to have a power failure, come back, and accept incomi= ng calls? Brian On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: Brian I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a refresh token which the= RUE would hold in place of the user login password would also be useful, a= s it would mean the login password would not have to be stored after the fi= rst configuration; refreshing an expired configuration would be done with t= he refresh token. James James Hamlin Contractor 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: 22 February 2021 18:46 To: James Hamlin Cc: Jim Malloy; rum@ietf.org Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt Can we figure out how to converge on this? There are: a) Actual user login credentials b) SIP credentials c) STUN/TURN credentials The current draft treats them all as identical. Is there a reason to make = them separate? My VoIP accounts have only one set. I=92m okay adding a se= parate SIP/STUN/TURN credential returned in the config file, protected by t= he actual user login credentials, if that is really useful. Maybe it could= be optional, and if not provided, the userid/password is used for everythi= ng. Brian On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: Jim Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater fle= xibility in how a user's use of different RUE's can be isolated. I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= . Best Regards James James Hamlin Contractor 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: Jim Malloy > Sent: 09 February 2021 14:20 To: Brian Rosen; James Hamlin Cc: rum@ietf.org Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt =93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94 James =96 Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials? (Mobile applications may do so at the OS level even if the a= pplication doesn=92t explicitly do so.) If so, is there a reason to treat = the RUE Differently? Thanks, Jim Malloy Principal Information System Engineer The MITRE Corp. 703 983 2835 From: Rum > On Behalf Of = Brian Rosen Sent: Tuesday, February 9, 2021 8:44 AM To: Hamlin, James > Cc: rum@ietf.org Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt I=92ll delete the text in registration. Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use. Every one. They do that for a simple reason - so incomi= ng calls work after a power loss. Most also are effectively set and forget= , which is what you want in a phone. Why would we require manual entry for= the RUE? The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it. I think that=92s pretty reasonable. If you have another proposal for how we can maintain the config data secure= ly, please suggest one. Brian On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: Brian Section 5.1 Registration says that "The credentials to be used (username an= d password) MUST be supplied within the credentials section of the configur= ation and identified by the realm the registrar uses in a digest challenge.= This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 draft, password= s are no longer returned in the configuration. I think we need to avoid the= RUM RUE caching the user's main account password, which this draft seems t= o require. Best regards James James Hamlin Contractor 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: Rum > on behalf of = Brian Rosen > Sent: 05 February 2021 22:26 To: rum@ietf.org Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt I have posted a -04 revision. This should handle all comments received so = far, please let me know if I forgot something. This version reworks the provider list and configuration sections along the= lines we have been discussing. I do not have a way to download a username/password from a new signup. I= =92m having trouble thinking about a secure way to do that. If anyone has = an idea, I=92m very willing to write text for it. I=92ve considered things= like javascript that stashes it in a file or somewhere else, having some w= eb page function that triggers a local display of an entry form for usernam= e and password, and a couple of other things. One note on the configuration mechanism - because the only thing the local = RUE device needs to keep is the username password against a provider ID of = some kind, there isn=92t any need to standardize how that works, and so it= =92s completely absent in the text. For now, I=92ve removed the step by step diagram that showed how the config= mechanism is used. I think what is there is dead simple and needs no expl= anation: it=92s a straightforward REST/JSON web service using username/pass= word authentication for providers the user has accounts with. I can bring = back the diagram if that is needed. Brian Begin forwarded message: From: internet-drafts@ietf.org Subject: I-D Action: draft-ietf-rum-rue-04.txt Date: February 5, 2021 at 5:17:15 PM EST To: > Cc: rum@ietf.org Reply-To: internet-drafts@ietf.org, rum@ie= tf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. 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-04.txt Pages : 33 Date : 2021-02-05 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-04.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ 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 --_000_161424298898087424purpleus_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Brian


Having consulted interna= lly, we are content if support for separate passwords and tokens is dropped= , as providers could always allocate users separate RUM RUE passwords if re= quired.


Also we think the refres= h token, as it was previously discussed, would have been the result of usin= g OAuth. So OAuth would have provided a token that allowed the RUE to refre= sh its config without retaining the user password; which fit's with Olle's suggestion.


James


James Hamlin
Contractor
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 <= /div>
message.


From: Brian Rosen <br@= brianrosen.net>
Sent: 23 February 2021 18:39
To: James Hamlin
Cc: Jim Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Okay, let=92s walk through how this is used:
1. The user creates a new account.  They create a user= name/password for the account.  That is stored in the device
2. The device retrieves configuration using the username/pa= ssword
3. Configuration may contain a refresh token.  This is= a password.  The token is used instead if the actual password, but wi= th the actual username, to do SIP/STUN/TURN authentication.
4. The refresh token is used until the config retrieval cha= nges it.

Is that right?  Can you explain why this is better tha= n just using the account username/password?

Brian


On Feb 23, 2021, at 12:48 PM, James Hamlin <james.hamlin@purple.us> wro= te:


I was assuming the refresh token would simply stand in for the passwor= d literally. That said, when the idea was previously discussed, the token w= ould have solely been used in authentication for config retrieval, as SIP w= ould use the password set by configuration. It has been a long time since the refresh token was discussed so others mi= ght remember more.

I think the provider needs to keep one token valid until the= next is first used or make it valid for much longer than th= e configuration lifetime.


James



James Hamlin
Contractor
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 orig= inal 
message.


From: Brian Rosen <br@brianrosen.net>
Sent: 2= 3 February 2021 17:21
To: Jam= es Hamlin
Cc: Jim= Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Is the token a username/password equivalent (meaning, does = it use the normal SIP REGISTER authentication)?
As long as it=92s valid until replaced, that=92s OK with me= .

Brian


On Feb 23, 2021, at 12:06 PM, James Hamlin <james.hamlin@purple.us> wro= te:


It's been a while since the refresh token was discussed; but if it is retur= ned in the configuration, the RUE should replace/overwrite i= t's stored copy of the user password with the token. Th= e token would then be valid where the user passwor= d was valid initially. Similarly, in further refreshes of the config, if a refresh token is return= ed, it replaces the previous token. That wouldn't have any effect=  on the ability to recover from power failure. 
 
James

James Hamlin
Contractor
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 orig= inal 
message.


 
From: Brian Rosen <br@brianrosen.net>
Sent: 2= 3 February 2021 15:09
To: Jam= es Hamlin
Cc: Jim= Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Okay, I=92ll add optional SIP/STUN/TURN credentials.  

Tell me a little more about how you think the refresh token= would work.  Would it allow a device to have a power failure, come ba= ck, and accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, James Hamlin <james.hamlin@purple.us> wrot= e:

Brian

I think having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a ref= resh token which the RUE would hold in place&= nbsp;of the user login password would also be usef= ul, as it would mean the login password would=  not have to be stored after the first configuration; refre= shing an expired configuration would be done with the refres= h token.

James


James Hamlin
Contractor
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 orig= inal 
message.


 
From: Brian Rosen <br@brianrosen.net>
Sent: 2= 2 February 2021 18:46
To: Jam= es Hamlin
Cc: Jim= Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP credentials
c) STUN/TURN credentials

The current draft treats them all as identical.  Is th= ere a reason to make them separate?  My VoIP accounts have only one se= t.  I=92m okay adding a separate SIP/STUN/TURN credential returned in = the config file, protected by the actual user login credentials, if that is really useful.  Maybe it could be optional, a= nd if not provided, the userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote= :

Jim

Yes credentials have to be cached, but not necessarily the user's primary a= ccount credentials. The previous text allowed the configuration service to = send back separate credentials for SIP/STUN/TURN which could have a shorter= validity period than the main account credentials. This offers greater flexibility in how a user's use=  of different RUE's can be isolated.

I'll accept that the provider could offer a separate password for use with = each RUE type; we'd need to think about the logistical implications of that= .

Best Regards

James


James Hamlin
Contractor
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 orig= inal 
message.


 
From: Jim Malloy <jmalloy@mitre.org>
Sent: 0= 9 February 2021 14:20
To: Bri= an Rosen; James Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt
 
=93Every VoIP phone I=92ve ever seen or used caches username and passwords = for stand alone use=94

 

James =96 

 

Do existing ZVRS/Purple devices or mobile applications cache authentication= credentials?  (Mobile applications may do so at the OS level even if = the application doesn=92t explicitly do so.)  If so, is there a reason= to treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE Corp.
703 983 2835

 

From: R= um <rum-bounces@ietf.= org> On Behalf Of Brian Rosen
Sent: T= uesday, February 9, 2021 8:44 AM
To: Ham= lin, James <james.h= amlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt

 

I=92ll delete the text in registration.  
Every VoIP phone I=92ve ever seen or used caches username and passwords for= stand alone use.  Every one.  They do that for a simple reason -= so incoming calls work after a power loss.  Most also are effectively= set and forget, which is what you want in a phone.  Why would we require manual entry for the RUE?

 

The text currently uses the same credentials for the HTTP service and the S= IP service, but that=92s it.  I think that=92s pretty reasonable.

 

If you have another proposal for how we can maintain the config data secure= ly, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <jame= s.hamlin@purple.us> wrote:

 

Brian

 

Section 5.1 Registration says tha= t "The credentials to be used (username and password) MUST be supplied= within the credentials section of the configuration and identified by the = realm the registrar uses in a digest challenge. This username/password combination SHOULD NOT be the same as that used for= other purposes, such as retrieving the RUE configuration or logging into t= he Provider's customer service portal.". However, in the 04 = draft, passwords are no longer returned in the configuration. I think we need to avoid the RUM RUE caching the user's mai= n account password, which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 0= 5 February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt

 

I have posted a -04 revision. &nb= sp;This should handle all comments received so far, please let me know if I= forgot something.<= /div>

 

This version reworks the provider= list and configuration sections along the lines we have been discussing.

 

I do not have a way to download a= username/password from a new signup.  I=92m having trouble thinking a= bout a secure way to do that.  If anyone has an idea, I=92m very willi= ng to write text for it.  I=92ve considered things like javascript that stashes it in a file or somewhere else, having some web pa= ge function that triggers a local display of an entry form for username and= password, and a couple of other things.

 

One note on the configuration mec= hanism - because the only thing the local RUE device needs to keep is the u= sername password against a provider ID of some kind, there isn=92t any need= to standardize how that works, and so it=92s completely absent in the text.  

 

For now, I=92ve removed the step = by step diagram that showed how the config mechanism is used.  I think= what is there is dead simple and needs no explanation: it=92s a straightfo= rward REST/JSON web service using username/password authentication for providers the user has accounts with.  I can bring= back the diagram if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.t= xt
Date: February 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ie= tf.org

 


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

       Title     &nb= sp;     : Interoperability Profile for Relay User = Equipment
       Author     &n= bsp;    : Brian Rosen
Filename        : draft-ietf-rum-rue-04.= txt
Pages           : 33
Date            : 20= 21-02-05

Abstract:
  Video Relay Service (VRS) is a term used to describe a method b= y
  which a hearing persons can communicate with deaf/Hard of Heari= ng
  user using an interpreter ("Communications Assistant"= ) connected via
  a videophone to the deaf/HoH user and an audio telephone call t= o the
  hearing user.  The CA interprets using sign language on th= e
  videophone link and voice on the telephone link.  Often th= e
  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 ser= vice,
  and subsequently to CAs and other deaf/HoH users.  It is d= esirable
  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 t= hat
  video calls direct between deaf/HoH users work.  This docu= ment
  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/<= /a>

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

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


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

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


_______________________________________________
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://ft= p.ietf.org/ietf/1shadow-sites.txt

 

 

 








--_000_161424298898087424purpleus_-- From nobody Thu Feb 25 12:25: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 A8AB93A040F for ; Thu, 25 Feb 2021 12:25:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 XMR3FadPvck6 for ; Thu, 25 Feb 2021 12:25:40 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2053.outbound.protection.outlook.com [40.107.94.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 170413A03FA for ; Thu, 25 Feb 2021 12:25:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ct+KCaLcJJDScIZNIDKXxKZmR4I2pXwGaFOwsK+Z2XUPrdyHGRALhQnNrc3ec1L+sPFWBU8MnsyzQhXf3xAiGINx2Sqhs7xny6PGLqjkEZ1l/dPj4gLnjGxes8pqcNK7dbHicFlxyoh2qUNuxH/dE+EyOgQB4qiYVP1Da2vKQz5fxJmndjHPRc79YWVbnKN/IbOcrv/bLcH+N6HzhJ4iUb7W104tY5fATLHCuCMU4XW1yCy8iJXXY4PwP8THZGEbnQCuOi2zVCZpgufK8QHfSBLfsoF3/A/wiDIlnSpJR9Y1ZW5vRYAJ4waBv/4x6/5mKkBT2vle8bIpX15t8X35Iw== 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=aR7cF6c3S6V2wKA+h14TOcl/+5vJ1b3VoLQS4FVsq5s=; b=THd8vuS3O5l2Y1RQSVIQ5JCq3rUxMiO6zi9ZTgMTzjgKXVp67LiZ4O99aE8f4WMo5dWOQtM78cS4f7q81Bp1pXB0m6BwS0GBTSxJYnbZ8c3aVpN63oUt8SZq5vX15W+38e3lkD0U2Q0xubr194rymihw6Y+P+vp5v/NtgQCvSLQork2HL2WCGTITenVJNBQA1AS4lWbwtZQOGT5iXhFGVDsJiddfcfhP1sN3UcNBBaTHRGgNnhqtczCF4V499GXYx8FUumwWK560fwpdY+6xMjoplce82WxMurIM2/YDtVKL0AipjeKxJzc81tebtqu4w2/K0s/zFnoys3YQqhrdkA== 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=aR7cF6c3S6V2wKA+h14TOcl/+5vJ1b3VoLQS4FVsq5s=; b=e3hDZIVKugmVpw/GSZYh4uG0258UdNZV4q4TREoTxWdrB6D6/ITgetb058f7f8Tpe/O9/Fgok/hiGmhR6w2IAUA6KGeIPP0QG4Atpz+QeAZMIFZTRUF/L9B1zQYZ5g9/ogIf5Pm9Gy6yc7NwVUBIjmWYMr3FUqTBKh8mfWzJCuk= Received: from SN6PR04MB4990.namprd04.prod.outlook.com (2603:10b6:805:9a::11) by SN6PR04MB4205.namprd04.prod.outlook.com (2603:10b6:805:30::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.32; Thu, 25 Feb 2021 20:25:34 +0000 Received: from SN6PR04MB4990.namprd04.prod.outlook.com ([fe80::29b5:a2d7:fca2:38a]) by SN6PR04MB4990.namprd04.prod.outlook.com ([fe80::29b5:a2d7:fca2:38a%6]) with mapi id 15.20.3890.019; Thu, 25 Feb 2021 20:25:34 +0000 From: Eugene Christensen To: Brian Rosen , "rum@ietf.org" Thread-Topic: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHW/A4SODw/7X3ac0aP3CLF9a5ZCapn/9Mg Date: Thu, 25 Feb 2021 20:25:33 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> In-Reply-To: <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@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-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 60ba8898-c19e-47f8-9b5f-08d8d9cb8126 x-ms-traffictypediagnostic: SN6PR04MB4205: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0rE/iRoNnO2xG2wtcioza5jAyPom7YTnNDkhLG/994+J2hOTJS2eu5MFOHNjQlCz5PrK1Ap1PG5PMHOmxiKdaJm9lLjChiaAYcguBCtXlNx/Y0xYRIgnrLjcbzU5vhv8is7G9D5/Oyx/oDyrr0bF6BhL074aZSCBbRe3fpa8G6nG7zjUuCDyKdtW3OAV5SmQf11EGgnuMD3ohKi6ZOBHe+yucaZp9ymIP4O4UgUCb6UCFDZjxeD5AyZ9AwLNdM0M7X2PgLwVC0bqbr2KZ+zlPu2TFM5dkpf0pBWR2eWPji5HB19vMZjCRT5RiBiQRV8h3Jc3sPuGr6n09FjhvlmMU+0XBH/gwj/21gVIdDGJGOicTYnb5D8tkus6FuFlnvUSW5uZFNLks0aZ53Y7LREtWpMGth17qBv1GeJVOYqQNVvK9lHjG4vp+5fomcb8A0WWpho1iLAjSRhxk7lg/CIW+dkMJLrDV6TgbN5v6ebn+uTNe0cTW1fZY1/ie8ZacCK4pzWujj6MgulDAyXLwRwXaJtcW7lbQKaE4klQo9YCEgBpC7re6QEAszpOytGuLdwGHUgNPv8ueOPVU9XbMSXLPANNwMvUK1xGzooHPf+Wres= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR04MB4990.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(39850400004)(396003)(136003)(366004)(71200400001)(478600001)(83380400001)(8936002)(66574015)(86362001)(66476007)(166002)(18074004)(66556008)(66446008)(2906002)(110136005)(33656002)(66946007)(316002)(52536014)(55016002)(8676002)(64756008)(6506007)(26005)(9686003)(186003)(7696005)(5660300002)(966005)(76116006)(53546011); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?L1M0QmVmRXNPeGJHZjZzWUJyVUw1c0xwNEZYZjNZSmY2czdSbXkxb3hXL3hT?= =?utf-8?B?ZHFwdWxkTlNzRjZFS3R6ZWtNOTRiejYvTUV6TzRnRWx3bTlZNHhvU0JzN0xa?= =?utf-8?B?R2owZ3kycTV5Y1RpN0ppVFpMczBYcC9PU0paMlNkUDAxOVJFM01BaHBENHFZ?= =?utf-8?B?bEQ3dzFuSlVDc2djOWRnWEFsTVlGVkdvZVlEbVpVemlxMXJUZHV4bDB2ZU1a?= =?utf-8?B?dXNaOE9pcllNaHRPeWlhdzZ2cDBURHVoNzRyUTZMTzF1TkdZUGdsQXBjSlpa?= =?utf-8?B?NW9jNm9VNzA1N2oySEwxSTI4QTJLSmJTR2VVZitOSnl1Q0l5bjlQanlFMUh0?= =?utf-8?B?S3Rub0REd1VlV2MzMlFPTzFwaTEzeFZ1L2pqaDhLSndKWVNHUWlRaUUxMS9q?= =?utf-8?B?Qm43ZVE5TStvdncvZW1BcForNkxLdFBBMHduclM1ZnJjaXBnSDR1Q3YxcTNX?= =?utf-8?B?QjlmT1JLa200WlgzQUJ0emMrd0I5a29tTmtNaGZiQ1hVUmdpT1pUZDA5Qyt4?= =?utf-8?B?VE0vbzduUkozamxMQWdQN0s3VkdBeU92Q2YxcFlBVGMyNmgrTUZmVFNHUEVH?= =?utf-8?B?OUptOUthVWVTODFnZlFQVkIxOUlLQnN0cjdQVjBWV3AyNm5LOCtXZXZFYzBo?= =?utf-8?B?d01YWnpjYWJHTkpSTEpYTUNkRnJtcTFKeENhMVFmdzNrRyt1ZXl4WUVDbURt?= =?utf-8?B?MGpIdFRraFZPYjd3c2ZYZ2FmSERWL0hQNkw4WWIvdUZTQkVxVXhEQ3lSMUNo?= =?utf-8?B?QWRxbEpJL2JFZ2JRT0VmYXRzaHFyREl1TS8wU3cvUC9FSW9VVm1paUExWDZJ?= =?utf-8?B?dU5qNldzbHFUcGtVeUlXNThlVmxPUU5ZYzh1NWtHam9nOXE3NEV1Z09zVGg5?= =?utf-8?B?MnN2MCt1MGtDcmJ0d3pId3dvOC9IeGVpRWxMNTBkWXp6TE03UFhpOS81Q205?= =?utf-8?B?NHBHMU5CZTNQNTRPSktGS0JkQVUwWHltWm5ONXFRSkFnbmFaYUJOM2R6SmVW?= =?utf-8?B?Yll0UmU1USthZzVSRW5LeC9nbEpHd2d4cmFwQVUwSmgyUXNWSXd3cFJwNmFV?= =?utf-8?B?VE5SczZ0WHhVMFBJeWZDUzF1RWV4MEM4UmU4WWVNbU1sUkltZ3lhVmJtUkh5?= =?utf-8?B?eFV3U1Z6WktYQVBwYUFlMk9UYnZNTk5FM1Y0bFpHRlJ1akNOQWc1Z0JEUTVM?= =?utf-8?B?TUxsQlFLZjZCZHdVbXVVVGljRTYxSGV4QzV6Yk02MkFmSFpPNjBPNFk5UzM5?= =?utf-8?B?em9HTDRxK0NSZmMvcW91dGFhZ3RoL05oWm5Da3NSNmF3ZGZHdEhtaXV6Nkho?= =?utf-8?B?WWFiamc2MndjY2V3VllJNGU4QVFDdHdBTk10enlEQ2NibzFPcktEYTk2WStH?= =?utf-8?B?b0w3MGNJQzFsOGIyR1hpNGF5WnNxNUZueVdDZFI1b2tRRWJad3dnMmVacnVu?= =?utf-8?B?VnBTeU9OMmtZQ2d2Vm9TbTdjRzhTb1BzRWNXRmU0VEs2QSsveGwraXk5VFpM?= =?utf-8?B?d05qQmFzSDBDRnVLVVNCYVV2Yk03RGY4SkJpZGhxeFFFU3FtaGFwaXlWa3hL?= =?utf-8?B?a0UxdnpSdmJRcS9KMTNuRUR4QWxIWlpVVnp2UmlaL01Rdk4zejBOaGRZVVRl?= =?utf-8?B?dnU2Ykdkb0g4ZVcxQWtCTjM5dGZrdncvZjhKdWtKV2ZkSFZROWQxdGNWZzdW?= =?utf-8?B?QkwxdG1LNWdnUWNyWFR5TE9RajE1KzhsSHhCQlJ1Q1NrbFA5TlZza0NOVXJ6?= =?utf-8?Q?gjweGl7LWpxaq5BsMS1CGUq5YIxtbLHC0d7Yumc?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR04MB49904C9CC693996F0D9A1575A39E9SN6PR04MB4990namp_" MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR04MB4990.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 60ba8898-c19e-47f8-9b5f-08d8d9cb8126 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2021 20:25:33.6703 (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: gIM+7Rw9CvMYSvKyXnwLSDpsmLN4m5AkC3lQb8wz6keFX/p0kSZpSb3G4Fy6XaXwzQTxcuQHwXUCqooyaVKRMvmG3KU6FeQuzqX1hnKKisQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR04MB4205 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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, 25 Feb 2021 20:25:43 -0000 --_000_SN6PR04MB49904C9CC693996F0D9A1575A39E9SN6PR04MB4990namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQnJpYW4uDQoNCknigJl2ZSBiZWVuIHJldmlld2luZyBkcmFmdCA0IHNvbWUgbW9yZSBhbmQg ZGlzY3Vzc2luZyBpdCBpbnRlcm5hbGx5IGFuZCB3b25kZXIgYWJvdXQgdGhlIGZvbGxvd2luZzoN Cg0KU2VjdGlvbiA1LjIuNSBFbWVyZ2VuY3kgQ2FsbHMNCkl0IHNlZW1zIHRoYXQgc2luY2UgdGhl IFJVRSBjb3VsZCBiZSBvbiBtYW55IGRpZmZlcmVudCBkZXZpY2UgdHlwZXMsIGluY2x1ZGluZyBu b24tbm9tYWRpYyBkZXZpY2VzIHN1Y2ggYXMgZGVza3RvcHMsIHdlIHNob3VsZCByZXF1aXJlIHRo ZSBSVUUgdG8gcHJvdmlkZSBhIHdheSB0byBmb3IgdGhlIHVzZXIgdG8gaW5wdXQgdGhlaXIgYWRk cmVzcy4gIFdpdGhvdXQgc3VjaCwgaXQgd2lsbCByZXF1aXJlIHRoZSBDQSB0byBhc2sgdGhlIGNh bGxlciBpbiBhbiBlbWVyZ2VuY3kgc2l0dWF0aW9uIGZvciB0aGVpciBsb2NhdGlvbi4gIFRoZSBj YWxsZXIgbWF5IGJlIGhhdmluZyBpc3N1ZXMgYXQgdGhlIHRpbWUgb2YgdGhlIGNhbGwgYW5kIG1h eSBiZSBsaW1pdGVkIGluIHRoZWlyIGFiaWxpdHkgdG8gcHJvdmlkZSBzdWNoIGluZm9ybWF0aW9u IGFzIHRoZWlyIGxvY2F0aW9uLiAgRm9yIHRoaXMgcmVhc29uLCBJIHRoaW5rIHRoZSBSVUUgc2hv dWxkIGJlIHJlcXVpcmVkIHRvIGltcGxlbWVudCBVSSB0byBvYnRhaW4gdGhpcyBhaGVhZCBvZiB0 aW1lIGFuZCBhbHNvIHRvIGJlIHVwZGF0ZWFibGUuDQoNClNlY3Rpb24gNi4yIFRleHQtQmFzZWQg Q29tbXVuaWNhdGlvbiBhbmQgV2ViUlRDDQpHaXZlbiB0aGF0IFdlYlJUQyBkb2VzIG5vdCB5ZXQg c3VwcG9ydCBULjE0MCBhbmQgYSB0cmFuc2NvZGVyIHdpbGwgYmUgcmVxdWlyZWQgKGFzIGFscmVh ZHkgbm90ZWQgaW4gc2VjdGlvbiA2LjIpLiAgSWYgdGhlIGVuZHBvaW50IGlzIGEgV2ViUlRDIHNv bHV0aW9uLCBJIHdvbmRlciBpZiB0aGUgdHJhbnNjb2RlciBzaG91bGQgYmUgcmVxdWlyZWQgb2Yg dGhlIGRldmVsb3BlciBvZiB0aGUgV2ViUlRDIHNvbHV0aW9uIGFuZCBub3QgdGhlIHByb3ZpZGVy cy4gIEkgYmVsaWV2ZSBsYW5ndWFnZSBleHByZXNzaW5nIHRoaXMgc2hvdWxkIGJlIGFkZGVkIHRv IHRoaXMgc2VjdGlvbiB1bnRpbCBzdWNoIHRpbWUgdGhhdCBXZWJSVEMgaGFzIGFuIGFjY2VwdGFi bGUgc29sdXRpb24gZm9yIFQuMTQwLg0KDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0UuIFRoaXMg ZS1tYWlsIHRyYW5zbWlzc2lvbiwgYW5kIGFueSBkb2N1bWVudHMsIGZpbGVzIG9yIHByZXZpb3Vz IGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hlZCB0byBpdCwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IGFuZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVzcG9uc2libGUgZm9yIGRlbGl2ZXJpbmcgaXQgdG8g dGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkg ZGlzY2xvc3VyZSwgY29weWluZywgZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMgU1RS SUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWlsIGF0 IGVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb208bWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5j b20+IG9yIGJ5IHRlbGVwaG9uZSBhdCArMSAoODAxKSAyODctOTQxOSwgYW5kIGRlc3Ryb3kgdGhl IG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIHdpdGhvdXQgcmVhZGlu ZyB0aGVtIG9yIHNhdmluZyB0aGVtIHRvIGRpc2suDQoNCkZyb206IFJ1bSA8cnVtLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDogRnJpZGF5LCBGZWJydWFy eSA1LCAyMDIxIDM6MjcgUE0NClRvOiBydW1AaWV0Zi5vcmcNClN1YmplY3Q6IFtSdW1dIEZ3ZDog SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0KDQpbRVhURVJOQUxdIEkgaGF2 ZSBwb3N0ZWQgYSAtMDQgcmV2aXNpb24uICBUaGlzIHNob3VsZCBoYW5kbGUgYWxsIGNvbW1lbnRz IHJlY2VpdmVkIHNvIGZhciwgcGxlYXNlIGxldCBtZSBrbm93IGlmIEkgZm9yZ290IHNvbWV0aGlu Zy4NCg0KVGhpcyB2ZXJzaW9uIHJld29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZpZ3Vy YXRpb24gc2VjdGlvbnMgYWxvbmcgdGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nLg0K DQpJIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGRvd25sb2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQgZnJv bSBhIG5ldyBzaWdudXAuICBJ4oCZbSBoYXZpbmcgdHJvdWJsZSB0aGlua2luZyBhYm91dCBhIHNl Y3VyZSB3YXkgdG8gZG8gdGhhdC4gIElmIGFueW9uZSBoYXMgYW4gaWRlYSwgSeKAmW0gdmVyeSB3 aWxsaW5nIHRvIHdyaXRlIHRleHQgZm9yIGl0LiAgSeKAmXZlIGNvbnNpZGVyZWQgdGhpbmdzIGxp a2UgamF2YXNjcmlwdCB0aGF0IHN0YXNoZXMgaXQgaW4gYSBmaWxlIG9yIHNvbWV3aGVyZSBlbHNl LCBoYXZpbmcgc29tZSB3ZWIgcGFnZSBmdW5jdGlvbiB0aGF0IHRyaWdnZXJzIGEgbG9jYWwgZGlz cGxheSBvZiBhbiBlbnRyeSBmb3JtIGZvciB1c2VybmFtZSBhbmQgcGFzc3dvcmQsIGFuZCBhIGNv dXBsZSBvZiBvdGhlciB0aGluZ3MuDQoNCk9uZSBub3RlIG9uIHRoZSBjb25maWd1cmF0aW9uIG1l Y2hhbmlzbSAtIGJlY2F1c2UgdGhlIG9ubHkgdGhpbmcgdGhlIGxvY2FsIFJVRSBkZXZpY2UgbmVl ZHMgdG8ga2VlcCBpcyB0aGUgdXNlcm5hbWUgcGFzc3dvcmQgYWdhaW5zdCBhIHByb3ZpZGVyIElE IG9mIHNvbWUga2luZCwgdGhlcmUgaXNu4oCZdCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBob3cg dGhhdCB3b3JrcywgYW5kIHNvIGl04oCZcyBjb21wbGV0ZWx5IGFic2VudCBpbiB0aGUgdGV4dC4N Cg0KRm9yIG5vdywgSeKAmXZlIHJlbW92ZWQgdGhlIHN0ZXAgYnkgc3RlcCBkaWFncmFtIHRoYXQg c2hvd2VkIGhvdyB0aGUgY29uZmlnIG1lY2hhbmlzbSBpcyB1c2VkLiAgSSB0aGluayB3aGF0IGlz IHRoZXJlIGlzIGRlYWQgc2ltcGxlIGFuZCBuZWVkcyBubyBleHBsYW5hdGlvbjogaXTigJlzIGEg c3RyYWlnaHRmb3J3YXJkIFJFU1QvSlNPTiB3ZWIgc2VydmljZSB1c2luZyB1c2VybmFtZS9wYXNz d29yZCBhdXRoZW50aWNhdGlvbiBmb3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhhcyBhY2NvdW50cyB3 aXRoLiAgSSBjYW4gYnJpbmcgYmFjayB0aGUgZGlhZ3JhbSBpZiB0aGF0IGlzIG5lZWRlZC4NCg0K QnJpYW4NCg0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBpbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NClN1YmplY3Q6 IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcnVtLXJ1ZS0wNC50eHQNCkRhdGU6IEZlYnJ1YXJ5IDUs IDIwMjEgYXQgNToxNzoxNSBQTSBFU1QNClRvOiA8aS1kLWFubm91bmNlQGlldGYub3JnPG1haWx0 bzppLWQtYW5ub3VuY2VAaWV0Zi5vcmc+Pg0KQ2M6IHJ1bUBpZXRmLm9yZzxtYWlsdG86cnVtQGll dGYub3JnPg0KUmVwbHktVG86IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnPiwgcnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0Zi5vcmc+DQoN Cg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50 ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgVGl0bGUgICAg ICAgICAgIDogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVxdWlwbWVu dA0KICAgICAgIEF1dGhvciAgICAgICAgICA6IEJyaWFuIFJvc2VuDQogICAgICAgICAgICAgICAg RmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0KICAgICAgICAgICAg ICAgIFBhZ2VzICAgICAgICAgICA6IDMzDQogICAgICAgICAgICAgICAgRGF0ZSAgICAgICAgICAg IDogMjAyMS0wMi0wNQ0KDQpBYnN0cmFjdDoNCiAgVmlkZW8gUmVsYXkgU2VydmljZSAoVlJTKSBp cyBhIHRlcm0gdXNlZCB0byBkZXNjcmliZSBhIG1ldGhvZCBieQ0KICB3aGljaCBhIGhlYXJpbmcg cGVyc29ucyBjYW4gY29tbXVuaWNhdGUgd2l0aCBkZWFmL0hhcmQgb2YgSGVhcmluZw0KICB1c2Vy IHVzaW5nIGFuIGludGVycHJldGVyICgiQ29tbXVuaWNhdGlvbnMgQXNzaXN0YW50IikgY29ubmVj dGVkIHZpYQ0KICBhIHZpZGVvcGhvbmUgdG8gdGhlIGRlYWYvSG9IIHVzZXIgYW5kIGFuIGF1ZGlv IHRlbGVwaG9uZSBjYWxsIHRvIHRoZQ0KICBoZWFyaW5nIHVzZXIuICBUaGUgQ0EgaW50ZXJwcmV0 cyB1c2luZyBzaWduIGxhbmd1YWdlIG9uIHRoZQ0KICB2aWRlb3Bob25lIGxpbmsgYW5kIHZvaWNl IG9uIHRoZSB0ZWxlcGhvbmUgbGluay4gIE9mdGVuIHRoZQ0KICBpbnRlcnByZXRlcnMgbWF5IGJl IHN1cHBsaWVkIGJ5IGEgY29tcGFueSBvciBhZ2VuY3kgdGVybWVkIGENCiAgInByb3ZpZGVyIiBp biB0aGlzIGRvY3VtZW50LiAgVGhlIHByb3ZpZGVyIGFsc28gcHJvdmlkZXMgYSB2aWRlbw0KICBz ZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3QgdmlkZW8gZGV2aWNlcyB0byB0aGVp ciBzZXJ2aWNlLA0KICBhbmQgc3Vic2VxdWVudGx5IHRvIENBcyBhbmQgb3RoZXIgZGVhZi9Ib0gg dXNlcnMuICBJdCBpcyBkZXNpcmFibGUNCiAgdGhhdCB0aGUgdmlkZW9waG9uZXMgdXNlZCBieSB0 aGUgZGVhZi9Ib0gvSC1JIHVzZXIgY29uZm9ybSB0byBhDQogIHN0YW5kYXJkIHNvIHRoYXQgYW55 IGRldmljZSBtYXkgYmUgdXNlZCB3aXRoIGFueSBwcm92aWRlciBhbmQgdGhhdA0KICB2aWRlbyBj YWxscyBkaXJlY3QgYmV0d2VlbiBkZWFmL0hvSCB1c2VycyB3b3JrLiAgVGhpcyBkb2N1bWVudA0K ICBkZXNjcmliZXMgdGhlIGludGVyZmFjZSBiZXR3ZWVuIGEgdmlkZW9waG9uZSBhbmQgYSBwcm92 aWRlci4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm dCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnVtLXJ1 ZS8NCg0KVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvYXJjaGl2ZS9pZC9kcmFmdC1pZXRmLXJ1bS1ydWUtMDQuaHRtbA0KDQpB IGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQpodHRwczov L3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1ydW0tcnVlLTA0DQoNCg0KUGxl YXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRp bWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNv IGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy8NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNlQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50 ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwN Cm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQoNCg== --_000_SN6PR04MB49904C9CC693996F0D9A1575A39E9SN6PR04MB4990namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTphcHBsZS10YWItc3Bhbjt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXpl OjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFy Z2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpX b3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRp Zl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0 Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpYW4uPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPknigJl2ZSBiZWVuIHJldmlld2luZyBkcmFmdCA0IHNvbWUgbW9yZSBh bmQgZGlzY3Vzc2luZyBpdCBpbnRlcm5hbGx5IGFuZCB3b25kZXIgYWJvdXQgdGhlIGZvbGxvd2lu Zzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHU+U2VjdGlvbiA1LjIuNSBFbWVyZ2VuY3kg Q2FsbHM8bzpwPjwvbzpwPjwvdT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2Vl bXMgdGhhdCBzaW5jZSB0aGUgUlVFIGNvdWxkIGJlIG9uIG1hbnkgZGlmZmVyZW50IGRldmljZSB0 eXBlcywgaW5jbHVkaW5nIG5vbi1ub21hZGljIGRldmljZXMgc3VjaCBhcyBkZXNrdG9wcywgd2Ug c2hvdWxkIHJlcXVpcmUgdGhlIFJVRSB0byBwcm92aWRlIGEgd2F5IHRvIGZvciB0aGUgdXNlciB0 byBpbnB1dCB0aGVpciBhZGRyZXNzLiZuYnNwOyBXaXRob3V0IHN1Y2gsIGl0IHdpbGwgcmVxdWly ZSB0aGUgQ0ENCiB0byBhc2sgdGhlIGNhbGxlciBpbiBhbiBlbWVyZ2VuY3kgc2l0dWF0aW9uIGZv ciB0aGVpciBsb2NhdGlvbi4mbmJzcDsgVGhlIGNhbGxlciBtYXkgYmUgaGF2aW5nIGlzc3VlcyBh dCB0aGUgdGltZSBvZiB0aGUgY2FsbCBhbmQgbWF5IGJlIGxpbWl0ZWQgaW4gdGhlaXIgYWJpbGl0 eSB0byBwcm92aWRlIHN1Y2ggaW5mb3JtYXRpb24gYXMgdGhlaXIgbG9jYXRpb24uJm5ic3A7IEZv ciB0aGlzIHJlYXNvbiwgSSB0aGluayB0aGUgUlVFIHNob3VsZCBiZSByZXF1aXJlZA0KIHRvIGlt cGxlbWVudCBVSSB0byBvYnRhaW4gdGhpcyBhaGVhZCBvZiB0aW1lIGFuZCBhbHNvIHRvIGJlIHVw ZGF0ZWFibGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjx1PlNlY3Rpb24gNi4yIFRleHQt QmFzZWQgQ29tbXVuaWNhdGlvbiBhbmQgV2ViUlRDPG86cD48L286cD48L3U+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoYXQgV2ViUlRDIGRvZXMgbm90IHlldCBzdXBwb3J0 IFQuMTQwIGFuZCBhIHRyYW5zY29kZXIgd2lsbCBiZSByZXF1aXJlZCAoYXMgYWxyZWFkeSBub3Rl ZCBpbiBzZWN0aW9uIDYuMikuJm5ic3A7IElmIHRoZSBlbmRwb2ludCBpcyBhIFdlYlJUQyBzb2x1 dGlvbiwgSSB3b25kZXIgaWYgdGhlIHRyYW5zY29kZXIgc2hvdWxkIGJlIHJlcXVpcmVkIG9mIHRo ZSBkZXZlbG9wZXIgb2YgdGhlIFdlYlJUQyBzb2x1dGlvbg0KIGFuZCBub3QgdGhlIHByb3ZpZGVy cy4mbmJzcDsgSSBiZWxpZXZlIGxhbmd1YWdlIGV4cHJlc3NpbmcgdGhpcyBzaG91bGQgYmUgYWRk ZWQgdG8gdGhpcyBzZWN0aW9uIHVudGlsIHN1Y2ggdGltZSB0aGF0IFdlYlJUQyBoYXMgYW4gYWNj ZXB0YWJsZSBzb2x1dGlvbiBmb3IgVC4xNDAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpuYXZ5Ij5DT05GSURFTlRJQUxJVFkgTk9USUNFLjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOm5hdnkiPiBUaGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBhbnkgZG9j dW1lbnRzLCBmaWxlcyBvcg0KIHByZXZpb3VzIGUtbWFpbCBtZXNzYWdlcyBhdHRhY2hlZCB0byBp dCwgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGFuZCBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgb3IgYSBwZXJzb24gcmVzcG9u c2libGUgZm9yIGRlbGl2ZXJpbmcgaXQgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFy ZSBoZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgZGlzY2xvc3VyZSwgY29weWluZywNCiBkaXN0cmli dXRpb24gb3IgdXNlIG9mIGFueSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIG9yIGF0 dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBQUk9ISUJJVEVELiBJZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5 IG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86ZWNo cmlzdGVuc2VuQHNvcmVuc29uLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5lY2hyaXN0ZW5zZW5Ac29yZW5z b24uY29tPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6bmF2eSI+IG9yIGJ5IHRlbGVwaG9u ZSBhdCArMSAoODAxKSAyODctOTQxOSwNCiBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJhbnNt aXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2aW5n IHRoZW0gdG8gZGlzay48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdCI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUnVtICZsdDtydW0tYm91bmNlc0BpZXRmLm9yZyZndDsg PGI+T24gQmVoYWxmIE9mIDwvYj4NCkJyaWFuIFJvc2VuPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgRmVicnVhcnkgNSwgMjAyMSAzOjI3IFBNPGJyPg0KPGI+VG86PC9iPiBydW1AaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW1J1bV0gRndkOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1 bS1ydWUtMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6cmVkIj5bRVhURVJOQUxdPC9zcGFuPiZuYnNwO0kgaGF2ZSBwb3N0ZWQg YSAtMDQgcmV2aXNpb24uICZuYnNwO1RoaXMgc2hvdWxkIGhhbmRsZSBhbGwgY29tbWVudHMgcmVj ZWl2ZWQgc28gZmFyLCBwbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBmb3Jnb3Qgc29tZXRoaW5nLjxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyB2ZXJzaW9u IHJld29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZpZ3VyYXRpb24gc2VjdGlvbnMgYWxv bmcgdGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCBoYXZlIGEgd2F5IHRv IGRvd25sb2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQgZnJvbSBhIG5ldyBzaWdudXAuICZuYnNwO0ni gJltIGhhdmluZyB0cm91YmxlIHRoaW5raW5nIGFib3V0IGEgc2VjdXJlIHdheSB0byBkbyB0aGF0 LiAmbmJzcDtJZiBhbnlvbmUgaGFzIGFuIGlkZWEsIEnigJltIHZlcnkgd2lsbGluZyB0byB3cml0 ZSB0ZXh0IGZvciBpdC4gJm5ic3A7SeKAmXZlIGNvbnNpZGVyZWQgdGhpbmdzIGxpa2UgamF2YXNj cmlwdCB0aGF0DQogc3Rhc2hlcyBpdCBpbiBhIGZpbGUgb3Igc29tZXdoZXJlIGVsc2UsIGhhdmlu ZyBzb21lIHdlYiBwYWdlIGZ1bmN0aW9uIHRoYXQgdHJpZ2dlcnMgYSBsb2NhbCBkaXNwbGF5IG9m IGFuIGVudHJ5IGZvcm0gZm9yIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5kIGEgY291cGxlIG9m IG90aGVyIHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+T25lIG5vdGUgb24gdGhlIGNvbmZpZ3VyYXRpb24gbWVjaGFuaXNtIC0gYmVj YXVzZSB0aGUgb25seSB0aGluZyB0aGUgbG9jYWwgUlVFIGRldmljZSBuZWVkcyB0byBrZWVwIGlz IHRoZSB1c2VybmFtZSBwYXNzd29yZCBhZ2FpbnN0IGEgcHJvdmlkZXIgSUQgb2Ygc29tZSBraW5k LCB0aGVyZSBpc27igJl0IGFueSBuZWVkIHRvIHN0YW5kYXJkaXplIGhvdyB0aGF0IHdvcmtzLCBh bmQgc28gaXTigJlzIGNvbXBsZXRlbHkNCiBhYnNlbnQgaW4gdGhlIHRleHQuICZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igbm93 LCBJ4oCZdmUgcmVtb3ZlZCB0aGUgc3RlcCBieSBzdGVwIGRpYWdyYW0gdGhhdCBzaG93ZWQgaG93 IHRoZSBjb25maWcgbWVjaGFuaXNtIGlzIHVzZWQuICZuYnNwO0kgdGhpbmsgd2hhdCBpcyB0aGVy ZSBpcyBkZWFkIHNpbXBsZSBhbmQgbmVlZHMgbm8gZXhwbGFuYXRpb246IGl04oCZcyBhIHN0cmFp Z2h0Zm9yd2FyZCBSRVNUL0pTT04gd2ViIHNlcnZpY2UgdXNpbmcgdXNlcm5hbWUvcGFzc3dvcmQg YXV0aGVudGljYXRpb24NCiBmb3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhhcyBhY2NvdW50cyB3aXRo LiAmbmJzcDtJIGNhbiBicmluZyBiYWNrIHRoZSBkaWFncmFtIGlmIHRoYXQgaXMgbmVlZGVkLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ccmlh bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWdpbiBm b3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5G cm9tOiA8L3NwYW4+PC9iPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+U3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1ydW0tcnVlLTA0LnR4dDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkRhdGU6IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5GZWJydWFyeSA1LCAyMDIxIGF0IDU6 MTc6MTUgUE0gRVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7Ij5UbzogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmktZC1h bm5vdW5jZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSBOZXVlJnF1b3Q7Ij5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+Jmd0Ozwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+Q2M6IDwvc3Bh bj48L2I+PGEgaHJlZj0ibWFpbHRvOnJ1bUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5ydW1AaWV0Zi5vcmc8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5SZXBseS1U bzogPC9zcGFuPg0KPC9iPjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiwNCjwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnVt QGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDsiPnJ1bUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFi bGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhp cyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRo ZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO1RpdGxlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzogSW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVx dWlwbWVudDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1 dGhvciAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDs6IEJyaWFuIFJvc2VuPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dDxi cj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IDwvc3Bhbj5QYWdlcyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDMzPGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRh Yi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPkRhdGUgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiAyMDIxLTAyLTA1PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7Jm5ic3A7 VmlkZW8gUmVsYXkgU2VydmljZSAoVlJTKSBpcyBhIHRlcm0gdXNlZCB0byBkZXNjcmliZSBhIG1l dGhvZCBieTxicj4NCiZuYnNwOyZuYnNwO3doaWNoIGEgaGVhcmluZyBwZXJzb25zIGNhbiBjb21t dW5pY2F0ZSB3aXRoIGRlYWYvSGFyZCBvZiBIZWFyaW5nPGJyPg0KJm5ic3A7Jm5ic3A7dXNlciB1 c2luZyBhbiBpbnRlcnByZXRlciAoJnF1b3Q7Q29tbXVuaWNhdGlvbnMgQXNzaXN0YW50JnF1b3Q7 KSBjb25uZWN0ZWQgdmlhPGJyPg0KJm5ic3A7Jm5ic3A7YSB2aWRlb3Bob25lIHRvIHRoZSBkZWFm L0hvSCB1c2VyIGFuZCBhbiBhdWRpbyB0ZWxlcGhvbmUgY2FsbCB0byB0aGU8YnI+DQombmJzcDsm bmJzcDtoZWFyaW5nIHVzZXIuICZuYnNwO1RoZSBDQSBpbnRlcnByZXRzIHVzaW5nIHNpZ24gbGFu Z3VhZ2Ugb24gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7dmlkZW9waG9uZSBsaW5rIGFuZCB2b2ljZSBv biB0aGUgdGVsZXBob25lIGxpbmsuICZuYnNwO09mdGVuIHRoZTxicj4NCiZuYnNwOyZuYnNwO2lu dGVycHJldGVycyBtYXkgYmUgc3VwcGxpZWQgYnkgYSBjb21wYW55IG9yIGFnZW5jeSB0ZXJtZWQg YTxicj4NCiZuYnNwOyZuYnNwOyZxdW90O3Byb3ZpZGVyJnF1b3Q7IGluIHRoaXMgZG9jdW1lbnQu ICZuYnNwO1RoZSBwcm92aWRlciBhbHNvIHByb3ZpZGVzIGEgdmlkZW88YnI+DQombmJzcDsmbmJz cDtzZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3QgdmlkZW8gZGV2aWNlcyB0byB0 aGVpciBzZXJ2aWNlLDxicj4NCiZuYnNwOyZuYnNwO2FuZCBzdWJzZXF1ZW50bHkgdG8gQ0FzIGFu ZCBvdGhlciBkZWFmL0hvSCB1c2Vycy4gJm5ic3A7SXQgaXMgZGVzaXJhYmxlPGJyPg0KJm5ic3A7 Jm5ic3A7dGhhdCB0aGUgdmlkZW9waG9uZXMgdXNlZCBieSB0aGUgZGVhZi9Ib0gvSC1JIHVzZXIg Y29uZm9ybSB0byBhPGJyPg0KJm5ic3A7Jm5ic3A7c3RhbmRhcmQgc28gdGhhdCBhbnkgZGV2aWNl IG1heSBiZSB1c2VkIHdpdGggYW55IHByb3ZpZGVyIGFuZCB0aGF0PGJyPg0KJm5ic3A7Jm5ic3A7 dmlkZW8gY2FsbHMgZGlyZWN0IGJldHdlZW4gZGVhZi9Ib0ggdXNlcnMgd29yay4gJm5ic3A7VGhp cyBkb2N1bWVudDxicj4NCiZuYnNwOyZuYnNwO2Rlc2NyaWJlcyB0aGUgaW50ZXJmYWNlIGJldHdl ZW4gYSB2aWRlb3Bob25lIGFuZCBhIHByb3ZpZGVyLjxicj4NCjxicj4NCjxicj4NClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnVtLXJ1ZS8iPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnVtLXJ1ZS88L2E+PGJy Pg0KPGJyPg0KVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj4N Cmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0 bWw8YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFi bGUgYXQ6PGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYt cnVtLXJ1ZS0wNDxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmll dGYub3JnLjxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg YW5vbnltb3VzIEZUUCBhdDo8YnI+DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRz Lzxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdDxicj4NCkktRC1Bbm5vdW5j ZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1k LWFubm91bmNlPGJyPg0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0 Zi5vcmcvc2hhZG93Lmh0bWw8YnI+DQpvciBmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0Zi8xc2hhZG93 LXNpdGVzLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN6PR04MB49904C9CC693996F0D9A1575A39E9SN6PR04MB4990namp_-- From nobody Thu Feb 25 14:45:52 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 EBDAB3A0E4D for ; Thu, 25 Feb 2021 14:45:50 -0800 (PST) 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_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 rIg06W6tEZes for ; Thu, 25 Feb 2021 14:45:46 -0800 (PST) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2045.outbound.protection.outlook.com [40.107.92.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 3B33B3A0E28 for ; Thu, 25 Feb 2021 14:45:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FW/6u3a/Y76SRP/S7O/zd10rIAO8BQZy7VqIbbiNyIOP20OMPH6D/NKs4MUk7yQDB8NwjfAr8emLJOYjGp6Qc4hhWTGUlfMhkp3chBG0qKndvbKvBSatlqET3DcAEa/gfbK8G7NNUqIkjltDy2Lq0Nwv6r1Oj/FBkG6Dex4cERaJJxEMrSKIUA1J4J2UB64YHmM4TykYLSYMkIvLw9pquHizIQFRVsmi74rRYTPqNy5k/FMjoFtBtB/+OmCm/3X/dLwjLl7nLHtK4J6gJ2VNUgxFKitYiJWKnj//c7Uak1cgBNauaFzwPFrfiOdpoRY5Tf3v+JbqIOCU+eHZRActfg== 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=q31xH0dob+Yd6rBukbwP9vWx2105vZfBkybFkF9++oo=; b=VDc9VvUd2k90G5J7tbSJVR1q/ASu5SynA1+eGiLQroH9RMICX/EkY0Oy/gluS8Dz37Cw60z2C/1+ggzqHR++9Byq6vVZlK3HaHaJl+n9kcd6jEHd9V/VuK5QrfZSP4ndOZ0RKo2/8wqynOSjw4FXE9bkjRU/WNE/GWhxk2dsBeshKXySImTl3I0eEO8lU41L8jDp/GYgeP2tR29cWZO6rY/GdgrBKAQM2015/M4phBjR9sFJOPuD57KUxHchdtfTx6zW+der82ztMrQq/urVs4+LmaDxuznTwfkAYM64OdmVd2al7TcDKvfm44BCC3758IT+6I3Imi+3jdO+Zqntvw== 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=q31xH0dob+Yd6rBukbwP9vWx2105vZfBkybFkF9++oo=; b=G4lNEwtukKhd2uC2NmDqDmituMVzQjNN04s/IUYqjEkjwgITZA0iD2GSuxJRY56b5K+QJN3IY3yBGUIhtYsR57SMnVeBTsetGcvPdYtaIoFEnxT/ZbbTrPrCWDtUs/KPMGphY5HWXujYXTouV/yedQHXERnL4d+wt8mz1Ohi/NU= Received: from SN6PR01CA0029.prod.exchangelabs.com (2603:10b6:805:b6::42) by BN6PR1201MB0132.namprd12.prod.outlook.com (2603:10b6:405:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3868.32; Thu, 25 Feb 2021 22:45:43 +0000 Received: from SN1NAM02FT011.eop-nam02.prod.protection.outlook.com (2603:10b6:805:b6:cafe::58) by SN6PR01CA0029.outlook.office365.com (2603:10b6:805:b6::42) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 22:45:43 +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 SN1NAM02FT011.mail.protection.outlook.com (10.152.72.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Thu, 25 Feb 2021 22:45: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 11PMjd4i025211 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 25 Feb 2021 17:45:40 -0500 To: rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> From: Paul Kyzivat Message-ID: <1e064a43-b3c5-7ffb-2965-448eae62ff20@alum.mit.edu> Date: Thu, 25 Feb 2021 17:45:39 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 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: 59af192e-2ae9-4dd9-c40b-08d8d9df14b6 X-MS-TrafficTypeDiagnostic: BN6PR1201MB0132: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: AQSQ7Z3KJ8bFyaYqGr+Twq16n5U/DCotwuP8SsDqJGAYbsk1KpSTexpvwWPMSPXpySBVV6FCmkhhO0cBN9y/nOTCikmPX5AcEZl8nqbNWhAG21nY0VY4ddLMxAAn7a+BB6YVmjkmhHYHBr0QxHopfELGawN+0NYIKr7NwjQh8Pe6HOW9mAS/R8s8tjW5I/9rfk5JxL4B99E2UaxjYLY/HuyIn/8JP4Zr+/ILw9q4mCVaTe2+WU+pUntqxxX8uvDfeOHFZ1FIfI029o9zZBkgLrCpWCHu8uvQhUrUUMyvHSF9OBvqTQbYOvTJDzR0oKoaL8lRMmEMNJ4vbVrmZbAVyn9tz7ZMhvJTXo3E1WR/cHcMiq9fLWPCaNUBPgTVyy5wXauk2ortJlDllK1IEVa1AIKufXCFjKLLssrIDqN9djO45V5ocYT9r/k8e3YXH/smUHaQNpyZPf1g9OBM7EVMgTucZ3oj3aRyBfYb+z13bIEnWiLpyFQDF8miK7ByowtQtbOj5gQ3Iwkw0BpK9kRV7SB1OfeRQ/3NQxmWdlPfupEJtU0/iubTdtLnA0KFXM2ZCdbeHcdT/NcE5g+U9uCDEq412Z+J6Qldl/P/a7YEaEYi1q8iDQCzYt0eYM/s7PTkNMBnd0rDyiYcdWpWTudDmvrDxd1Bo5lzNDy2nlcEiZvX4BR2uyETemMx5KBZ31wl 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)(53546011)(70206006)(82310400003)(8676002)(83380400001)(47076005)(86362001)(336012)(6916009)(356005)(8936002)(31686004)(2906002)(956004)(7596003)(36860700001)(70586007)(478600001)(26005)(31696002)(2616005)(82740400003)(75432002)(36906005)(316002)(186003)(786003)(5660300002)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Feb 2021 22:45:41.8433 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 59af192e-2ae9-4dd9-c40b-08d8d9df14b6 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: SN1NAM02FT011.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1201MB0132 Archived-At: Subject: Re: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.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, 25 Feb 2021 22:45:51 -0000 Eugene, On 2/25/21 3:25 PM, Eugene Christensen wrote: > Hi Brian. > > I’ve been reviewing draft 4 some more and discussing it internally and > wonder about the following: > *_Section 6.2 Text-Based Communication and WebRTC_* > > Given that WebRTC does not yet support T.140 and a transcoder will be > required (as already noted in section 6.2).  If the endpoint is a WebRTC > solution, I wonder if the transcoder should be required of the developer > of the WebRTC solution and not the providers.  I believe language > expressing this should be added to this section until such time that > WebRTC has an acceptable solution for T.140. I don't think there is any implication here that the providers would be required to provide that transcoding. Putting up a RUM-compatible solution that uses WebRTC will require running a service somewhere that has a WebRTC interface on one side and a RUM-compliant interface on the other side that connects to providers. (In this case the service is actually the RUE, and WebRTC is simply part of the UI implementation in the RUE.) That service will have to provide a T.140 transcoder in order to pass the T.140 to the provider. It is unclear to me who would build and operate such a service. We might imagine some future day when the providers might themselves host such a server as part of their offering. Conceivably some provider might do that on their own because they see it in their best interest. But it is out of scope for the current spec. Thanks, Paul From nobody Thu Feb 25 22:51: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 11A873A11C4 for ; Thu, 25 Feb 2021 22:51:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqhTQAECcmoF for ; Thu, 25 Feb 2021 22:51:18 -0800 (PST) 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 D6C063A11C1 for ; Thu, 25 Feb 2021 22:51:16 -0800 (PST) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id B5DD63FA; Fri, 26 Feb 2021 07:51:13 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: "Olle E. Johansson" In-Reply-To: <1e064a43-b3c5-7ffb-2965-448eae62ff20@alum.mit.edu> Date: Fri, 26 Feb 2021 07:51:11 +0100 Cc: Olle E Johansson Content-Transfer-Encoding: quoted-printable Message-Id: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1e064a43-b3c5-7ffb-2965-448eae62ff20@alum.mit.edu> To: Paul Kyzivat , rum@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 06:51:20 -0000 > On 25 Feb 2021, at 23:45, Paul Kyzivat wrote: >=20 > Eugene, >=20 > On 2/25/21 3:25 PM, Eugene Christensen wrote: >> Hi Brian. >> I=E2=80=99ve been reviewing draft 4 some more and discussing it = internally and wonder about the following: >=20 >> *_Section 6.2 Text-Based Communication and WebRTC_* >> Given that WebRTC does not yet support T.140 and a transcoder will be = required (as already noted in section 6.2). If the endpoint is a WebRTC = solution, I wonder if the transcoder should be required of the developer = of the WebRTC solution and not the providers. I believe language = expressing this should be added to this section until such time that = WebRTC has an acceptable solution for T.140. >=20 > I don't think there is any implication here that the providers would = be required to provide that transcoding. >=20 > Putting up a RUM-compatible solution that uses WebRTC will require = running a service somewhere that has a WebRTC interface on one side and = a RUM-compliant interface on the other side that connects to providers. = (In this case the service is actually the RUE, and WebRTC is simply part = of the UI implementation in the RUE.) That service will have to provide = a T.140 transcoder in order to pass the T.140 to the provider. >=20 > It is unclear to me who would build and operate such a service. We = might imagine some future day when the providers might themselves host = such a server as part of their offering. Conceivably some provider might = do that on their own because they see it in their best interest. But it = is out of scope for the current spec. When talking about WebRTC there is always confusion. There=E2=80=99s a = library called WebRTC and a set of standards. Where in the set of standards does it forbid T.140? I don=E2=80=99t = think that the assumption that IETF/W3C WebRTC doesn=E2=80=99t support T.140 is correct. That browsers hasn=E2=80=99t implemented support is another issue. /O From nobody Fri Feb 26 08:06: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 C19143A0D9A for ; Fri, 26 Feb 2021 08:06:46 -0800 (PST) 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 7FcaDXj_rZEL for ; Fri, 26 Feb 2021 08:06:43 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 AF2D73A0D99 for ; Fri, 26 Feb 2021 08:06:43 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id n28so8019697qkk.4 for ; Fri, 26 Feb 2021 08:06:43 -0800 (PST) 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=auZJ4VUt0rgbJJg6iLy4D+Q/pqWcRqGL3vSX5P+R5pI=; b=Gmqr6vkvNm9ZgPWWGpUSHjKBdFx0iyM9uocnBh3wLchK/IJ4hf4jeoBHiBguXD6Dc2 Kwl3ZIXMItJzPiiXUY+bL3MW54o7b91W+k/B1ApeKagRj5z9I91qoWwnr3n1R0qvRPBs CH/YOYjBWDUZ5sECTUr/GKktTDCCibvZejr6h5TDNtrXVqZnSWJQa6VA4fWje79jKHMH n0kSPGGjO9IriZutqCKx/U5veWE0N9EcIvnz4kzbokGg/q4x6pCUX9RnJQaM6exJJfAx u2pbY1WFr1YHzFa+Yv4ExPfxoaMWY4oI3UHE/JX4UmWfHBmxpNaCe4FZflrO/ATDTj1r 5MLw== 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=auZJ4VUt0rgbJJg6iLy4D+Q/pqWcRqGL3vSX5P+R5pI=; b=AaxZ+/CoXIIj3vgccvsRIWM/LpOmZa5ZfVIVWP8OQBAqkZK6WhCnzMXXZOzb2C1SP5 duGzuhmwVOHuAwTmXrA87JvB2aH/WaVvksmkmo1b+gBOoeJyYgzI9oYUxqqXohqlH5aS SNXa/i1jkWh4Rl4PnuD/ycynFcPG2pR9j1eQ7ihjWOqO+XRxg1hynQzizLvKcYmkatuX JwzqEXXpFm26BT0Tc1vCZOQMkMkYXDbOfFyQlGuw5he4BASwVZPU/7/56l+9BO84uNlC te8W1Kj4ikPiEdZHA+kWLLus909C43a6CubrW+eJ6FUO+j8omjf3AaydEp5ueJXA3tS2 M1Iw== X-Gm-Message-State: AOAM531BNkFH0sNodLM/EhEE8rkW2tbrGSAb2wDRm4H6leqq+TXEn5eK 0b3j2XDaoLPOxCAG3rjo5iGT4tZZ4JZxyc8x X-Google-Smtp-Source: ABdhPJwcYDhtMo09I3ITNTKWLx7B/szMZRFW0Go0YXlFQ1ZwtX5ESOPNub47BnOXp8Qldpt9I+8p9A== X-Received: by 2002:a37:a282:: with SMTP id l124mr3226762qke.37.1614355602748; Fri, 26 Feb 2021 08:06:42 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id 73sm725573qkk.131.2021.02.26.08.06.41 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 08:06:42 -0800 (PST) From: Brian Rosen Message-Id: <435B03D2-3AC7-4A41-A265-3E90936D7E8D@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_E86EC26C-BD48-482D-879B-226B2F098379" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 26 Feb 2021 11:06:40 -0500 In-Reply-To: Cc: "rum@ietf.org" To: Eugene Christensen References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 16:06:47 -0000 --Apple-Mail=_E86EC26C-BD48-482D-879B-226B2F098379 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for these comments. With respect to emergency calls, you are limited by FCC regulations in = the US, I believe, although there are 3rd party entities that supply = extra location information from Google and Apple after the call is = received at a PSAP. I think you have to use a location collected (and = verified) as part of account establishment. Typically there is a = website that updates this as necessary. I don=E2=80=99t like that as = the answer, but I think we=E2=80=99re stuck with it. Other countries = may have more flexibility. To be sure, the device MAY add a location = via the Geolocation header. It=E2=80=99s just that the provider MUST = add a location. I can make that clear in the text. The thing about WebRTC is that it does specify T.140, but transport is = in the data channel. The RUE spec is T.140 in SDP. The transport = adapter would be the RUE device and not the provider. I can try to = improve the wording there to make it more clear. Brian > On Feb 25, 2021, at 3:25 PM, Eugene Christensen = wrote: >=20 > Hi Brian. > =20 > I=E2=80=99ve been reviewing draft 4 some more and discussing it = internally and wonder about the following: > =20 > Section 5.2.5 Emergency Calls > It seems that since the RUE could be on many different device types, = including non-nomadic devices such as desktops, we should require the = RUE to provide a way to for the user to input their address. Without = such, it will require the CA to ask the caller in an emergency situation = for their location. The caller may be having issues at the time of the = call and may be limited in their ability to provide such information as = their location. For this reason, I think the RUE should be required to = implement UI to obtain this ahead of time and also to be updateable. > =20 > Section 6.2 Text-Based Communication and WebRTC > Given that WebRTC does not yet support T.140 and a transcoder will be = required (as already noted in section 6.2). If the endpoint is a WebRTC = solution, I wonder if the transcoder should be required of the developer = of the WebRTC solution and not the providers. I believe language = expressing this should be added to this section until such time that = WebRTC has an acceptable solution for T.140. > =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 > From: Rum > On = Behalf Of Brian Rosen > Sent: Friday, February 5, 2021 3:27 PM > To: rum@ietf.org > Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt > =20 > [EXTERNAL] I have posted a -04 revision. This should handle all = comments received so far, please let me know if I forgot something. > =20 > This version reworks the provider list and configuration sections = along the lines we have been discussing. > =20 > I do not have a way to download a username/password from a new signup. = I=E2=80=99m having trouble thinking about a secure way to do that. If = anyone has an idea, I=E2=80=99m very willing to write text for it. = I=E2=80=99ve considered things like javascript that stashes it in a file = or somewhere else, having some web page function that triggers a local = display of an entry form for username and password, and a couple of = other things. > =20 > One note on the configuration mechanism - because the only thing the = local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 > =20 > For now, I=E2=80=99ve removed the step by step diagram that showed how = the config mechanism is used. I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. > =20 > Brian > =20 >=20 >=20 > Begin forwarded message: > =20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-ietf-rum-rue-04.txt > Date: February 5, 2021 at 5:17:15 PM EST > To: > > Cc: rum@ietf.org > Reply-To: internet-drafts@ietf.org , = rum@ietf.org > =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-04.txt > Pages : 33 > Date : 2021-02-05 >=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-04.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=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 --Apple-Mail=_E86EC26C-BD48-482D-879B-226B2F098379 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for these comments.

With respect to emergency calls, you = are limited by FCC regulations in the US, I believe, although there are = 3rd party entities that supply extra location information from Google = and Apple after the call is received at a PSAP.  I think you have = to use a location collected (and verified) as part of account = establishment.  Typically there is a website that updates this as = necessary.  I don=E2=80=99t like that as the answer, but I think = we=E2=80=99re stuck with it.  Other countries may have more = flexibility.  To be sure, the device MAY add a location via the = Geolocation header.  It=E2=80=99s just that the provider MUST add a = location.   I can make that clear in the text.

The thing about WebRTC = is that it does specify T.140, but transport is in the data channel. =  The RUE spec is T.140 in SDP.  The transport adapter would be = the RUE device and not the provider. I can try to improve the wording = there to make it more clear.

Brian

On Feb = 25, 2021, at 3:25 PM, Eugene Christensen <echristensen@sorenson.com> wrote:

Hi Brian.
 
I=E2=80=99ve been reviewing draft 4 some more = and discussing it internally and wonder about the following:
 
Section 5.2.5 Emergency Calls
It seems that since = the RUE could be on many different device types, including non-nomadic = devices such as desktops, we should require the RUE to provide a way to = for the user to input their address.  Without such, it will require = the CA to ask the caller in an emergency situation for their = location.  The caller may be having issues at the time of the call = and may be limited in their ability to provide such information as their = location.  For this reason, I think the RUE should be required to = implement UI to obtain this ahead of time and also to be updateable.
 
Section 6.2 Text-Based Communication and WebRTC
Given that WebRTC = does not yet support T.140 and a transcoder will be required (as already = noted in section 6.2).  If the endpoint is a WebRTC solution, I = wonder if the transcoder should be required of the developer of the = WebRTC solution and not the providers.  I believe language = expressing this should be added to this section until such time that = WebRTC has an acceptable solution for T.140.
 
 
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.
 
From: Rum= <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Friday, February 5, 2021 = 3:27 PM
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt
 
[EXTERNAL] I have posted a -04 revision. =  This should handle all comments received so far, please let me = know if I forgot something.
 
This = version reworks the provider list and configuration sections along the = lines we have been discussing.
 
I do = not have a way to download a username/password from a new signup. =  I=E2=80=99m having trouble thinking about a secure way to do that. =  If anyone has an idea, I=E2=80=99m very willing to write text for = it.  I=E2=80=99ve considered things like javascript that stashes it = in a file or somewhere else, having some web page function that triggers = a local display of an entry form for username and password, and a couple = of other things.
 
One note on the configuration mechanism = - because the only thing the local RUE device needs to keep is the = username password against a provider ID of some kind, there isn=E2=80=99t = any need to standardize how that works, and so it=E2=80=99s completely = absent in the text.  
 
For = now, I=E2=80=99ve removed the step by step diagram that showed how the = config mechanism is used.  I think what is there is dead simple and = needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with.  I can bring back the diagram if that is = needed.
 
Brian
 


Begin forwarded message:
 
From: internet-drafts@ietf.org
Subject: I-D Action: draft-ietf-rum-rue-04.txt
Date: February = 5, 2021 at 5:17:15 PM EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org
 

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
        &= nbsp;       Filename =        : draft-ietf-rum-rue-04.txt
        &= nbsp;       Pages =           : 33
        &= nbsp;       Date =            : = 2021-02-05

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-04.html<= br class=3D"">
A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04


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

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


_______________________________________________
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

= --Apple-Mail=_E86EC26C-BD48-482D-879B-226B2F098379-- From nobody Fri Feb 26 08: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 35BA43A12BD for ; Fri, 26 Feb 2021 08:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.877 X-Spam-Level: X-Spam-Status: No, score=-1.877 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_KAM_HTML_FONT_INVALID=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 StQtSd5BuFxU for ; Fri, 26 Feb 2021 08:09:53 -0800 (PST) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 204DE3A11CA for ; Fri, 26 Feb 2021 08:09:40 -0800 (PST) Received: by mail-qk1-x72d.google.com with SMTP id z128so9494629qkc.12 for ; Fri, 26 Feb 2021 08:09:40 -0800 (PST) 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=AAS2PToqdeHeCDIqRjZcFOCbmCKA6SB9KRv/9gHBYLM=; b=mLI+SkTYXwJLcoNpK0tlybEvJAkNBx2i1JyLuzMjhqCjTCqAowcNgK64/geJmMf7pm KgenjS1sRrDFC6C8OKKEq0X2vhtv74n6Igcn/bk0p9qxz2V2lbsKD+o11MNUZ5AWvfPR +5BSZ4MRPpRT8MN6Ys3mBHLFS81Ln88s9zDCdeXFp3KPr+tntjvR04jixtuNBqlJuwIP 8ThyHe0r/BOckGqqW1FQA+I0CNKZNFnfDAbUxc/4+x9SjD6NSRCzptsEbG6xyWhgXQDz 1d3S11HeklWRrQkdRk+ZoFq9TqnLZLKeMSzkmLz7viDOP0EfBisWRBOCrkK7Zzq9WG0E U3aA== 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=AAS2PToqdeHeCDIqRjZcFOCbmCKA6SB9KRv/9gHBYLM=; b=ntk8PzyK1xY1aEaLyPKGU9hVrNy91o51gMVpfREkF4eVVy374QLgTKM4HyZ3lyUGYw uqjN1dOFjqvMSDIkWtMg66ZDQeVso+OPPU0Huv2dL7ctYqG+UpNdVFW4RjWnca2K9lLR 1xi1f28TKszbfGNQXdb5Fudk6z6bAzi1pViXEuotHcJxFHR55HhdLsjyV7/2CFKZ4ARI odeiusdBHsKh0ZPJ9x0gDRhMqpNWtxVnjNlO0bsW8yF0XgvcyVW+RnBzcmGQAgGtjNUE nVeUI402HtXoi3DjpnZJbYE3qs28+8wRyuiymO+ZDNmeA/dfRVOiznksGOmb6kX/0LvJ Slfg== X-Gm-Message-State: AOAM533ZzpZZzOfV+qA01hX4fsHrXu9T2rGiKAouDLJhiDVgq87iKNtm 1lLkBkxsRt1ddkHCWxRrw7tMPUH82DL5kElL X-Google-Smtp-Source: ABdhPJzqVC2ghYqjJWL4pvcsz1aM2tTDoQdMn5eHVEeGVZjgqHjrdWrSfAAkbYR0fpBj/BOw8og0sw== X-Received: by 2002:a37:4907:: with SMTP id w7mr3261241qka.259.1614355778980; Fri, 26 Feb 2021 08:09:38 -0800 (PST) Received: from brians-mbp.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id i37sm5909663qtb.46.2021.02.26.08.09.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Feb 2021 08:09:38 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9843C7C3-B2A9-4A6A-9069-6BCD0AE2D95D" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 26 Feb 2021 11:09:36 -0500 In-Reply-To: <1614242988980.87424@purple.us> Cc: Jim Malloy , "rum@ietf.org" To: James Hamlin References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1612863753040.41656@purple.us> <29289_1612878233_60229198_29289_1214_1_C24662A2-AFBC-4403-894A-A617E2F2447A@brianrosen.net> <1612881684171.60834@purple.us> <5132EF0F-CBCA-45CD-8CDE-42AE3FCE7687@brianrosen.net> <1614092297144.68835@purple.us> <1614100014388.54843@purple.us> <7AB4E72F-09B8-4016-A2CE-49C6B12EAA48@brianrosen.net> <1614102529543.36715@purple.us> <2271089B-063E-4EAD-A508-4B5963D4E772@brianrosen.net> <1614242988980.87424@purple.us> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rum] [EXT] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 16:10:05 -0000 --Apple-Mail=_9843C7C3-B2A9-4A6A-9069-6BCD0AE2D95D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 What do you want to do with OAuth? Make it mandatory, optional or not = included? I=E2=80=99m happy with any of these. If it is included, is = it used for authentication to the configuration service, the = SIP/STUN/TURN services or both? Brian > On Feb 25, 2021, at 3:49 AM, James Hamlin = wrote: >=20 > Brian >=20 > Having consulted internally, we are content if support for separate = passwords and tokens is dropped, as providers could always allocate = users separate RUM RUE passwords if required. >=20 > Also we think the refresh token, as it was previously discussed, would = have been the result of using OAuth. So OAuth would have provided a = token that allowed the RUE to refresh its config without retaining the = user password; which fit's with Olle's suggestion. >=20 > James >=20 > James Hamlin > Contractor > Purple, a Division of ZP Better Together, LLC > purplevrs.com > The information contained in this e-mail message is intended=20 > only for the personal and confidential use of the recipient(s)=20 > named above. If you have received this communication in error,=20 > please notify us immediately by e-mail, and delete the original=20 > message. >=20 > From: Brian Rosen > Sent: 23 February 2021 18:39 > To: James Hamlin > Cc: Jim Malloy; rum@ietf.org > Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt > =20 > Okay, let=E2=80=99s walk through how this is used: > 1. The user creates a new account. They create a username/password = for the account. That is stored in the device > 2. The device retrieves configuration using the username/password > 3. Configuration may contain a refresh token. This is a password. = The token is used instead if the actual password, but with the actual = username, to do SIP/STUN/TURN authentication. > 4. The refresh token is used until the config retrieval changes it. >=20 > Is that right? Can you explain why this is better than just using the = account username/password? >=20 > Brian >=20 >=20 >> On Feb 23, 2021, at 12:48 PM, James Hamlin > wrote: >>=20 >>=20 >> I was assuming the refresh token would simply stand in for the = password literally. That said, when the idea was previously discussed, = the token would have solely been used in authentication for config = retrieval, as SIP would use the password set by configuration. It has = been a long time since the refresh token was discussed so others might = remember more. >>=20 >> I think the provider needs to keep one token valid until the next is = first used or make it valid for much longer than the configuration = lifetime. >>=20 >>=20 >> James >>=20 >>=20 >>=20 >> James Hamlin >> Contractor >> Purple, a Division of ZP Better Together, LLC >> purplevrs.com = >> The information contained in this e-mail message is intended=20 >> only for the personal and confidential use of the recipient(s)=20 >> named above. If you have received this communication in error,=20 >> please notify us immediately by e-mail, and delete the original=20 >> message. >>=20 >> =20 >> From: Brian Rosen > >> Sent: 23 February 2021 17:21 >> To: James Hamlin >> Cc: Jim Malloy; rum@ietf.org >> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >> =20 >> Is the token a username/password equivalent (meaning, does it use the = normal SIP REGISTER authentication)? >> As long as it=E2=80=99s valid until replaced, that=E2=80=99s OK with = me. >>=20 >> Brian >>=20 >>=20 >>> On Feb 23, 2021, at 12:06 PM, James Hamlin > wrote: >>>=20 >>>=20 >>> It's been a while since the refresh token was discussed; but if it = is returned in the configuration, the RUE should replace/overwrite it's = stored copy of the user password with the token. The token would then be = valid where the user password was valid initially. Similarly, in further = refreshes of the config, if a refresh token is returned, it replaces the = previous token. That wouldn't have any effect on the ability to recover = from power failure.=20 >>> =20 >>> James >>>=20 >>> James Hamlin >>> Contractor >>> Purple, a Division of ZP Better Together, LLC >>> purplevrs.com = >>> The information contained in this e-mail message is intended=20 >>> only for the personal and confidential use of the recipient(s)=20 >>> named above. If you have received this communication in error,=20 >>> please notify us immediately by e-mail, and delete the original=20 >>> message. >>>=20 >>> =20 >>> From: Brian Rosen > >>> Sent: 23 February 2021 15:09 >>> To: James Hamlin >>> Cc: Jim Malloy; rum@ietf.org >>> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>> =20 >>> Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =20 >>>=20 >>> Tell me a little more about how you think the refresh token would = work. Would it allow a device to have a power failure, come back, and = accept incoming calls? >>>=20 >>> Brian >>>=20 >>>=20 >>>=20 >>>> On Feb 23, 2021, at 9:58 AM, James Hamlin > wrote: >>>>=20 >>>> Brian >>>>=20 >>>> I think having the flexibility to optionally return separate = SIP/STUN/TURN credentials could be useful. Optionally returning a = refresh token which the RUE would hold in place of the user login = password would also be useful, as it would mean the login password would = not have to be stored after the first configuration; refreshing an = expired configuration would be done with the refresh token. >>>>=20 >>>> James >>>>=20 >>>>=20 >>>> James Hamlin >>>> Contractor >>>> Purple, a Division of ZP Better Together, LLC >>>> purplevrs.com = >>>> The information contained in this e-mail message is intended=20 >>>> only for the personal and confidential use of the recipient(s)=20 >>>> named above. If you have received this communication in error,=20 >>>> please notify us immediately by e-mail, and delete the original=20 >>>> message. >>>>=20 >>>> =20 >>>> From: Brian Rosen > >>>> Sent: 22 February 2021 18:46 >>>> To: James Hamlin >>>> Cc: Jim Malloy; rum@ietf.org >>>> Subject: Re: [EXT] [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>>> =20 >>>> Can we figure out how to converge on this?=20 >>>>=20 >>>> There are: >>>> a) Actual user login credentials >>>> b) SIP credentials >>>> c) STUN/TURN credentials >>>>=20 >>>> The current draft treats them all as identical. Is there a reason = to make them separate? My VoIP accounts have only one set. I=E2=80=99m = okay adding a separate SIP/STUN/TURN credential returned in the config = file, protected by the actual user login credentials, if that is really = useful. Maybe it could be optional, and if not provided, the = userid/password is used for everything. >>>>=20 >>>> Brian >>>>=20 >>>>> On Feb 9, 2021, at 9:41 AM, James Hamlin > wrote: >>>>>=20 >>>>> Jim >>>>>=20 >>>>> Yes credentials have to be cached, but not necessarily the user's = primary account credentials. The previous text allowed the configuration = service to send back separate credentials for SIP/STUN/TURN which could = have a shorter validity period than the main account credentials. This = offers greater flexibility in how a user's use of different RUE's can be = isolated. >>>>>=20 >>>>> I'll accept that the provider could offer a separate password for = use with each RUE type; we'd need to think about the logistical = implications of that. >>>>>=20 >>>>> Best Regards >>>>>=20 >>>>> James >>>>>=20 >>>>>=20 >>>>> James Hamlin >>>>> Contractor >>>>> Purple, a Division of ZP Better Together, LLC >>>>> purplevrs.com = >>>>> The information contained in this e-mail message is intended=20 >>>>> only for the personal and confidential use of the recipient(s)=20 >>>>> named above. If you have received this communication in error,=20 >>>>> please notify us immediately by e-mail, and delete the original=20 >>>>> message. >>>>>=20 >>>>> =20 >>>>> From: Jim Malloy > >>>>> Sent: 09 February 2021 14:20 >>>>> To: Brian Rosen; James Hamlin >>>>> Cc: rum@ietf.org >>>>> Subject: RE: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>>>> =20 >>>>> =E2=80=9CEvery VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use=E2=80=9D >>>>> =20 >>>>> James =E2=80=93=20 >>>>> =20 >>>>> Do existing ZVRS/Purple devices or mobile applications cache = authentication credentials? (Mobile applications may do so at the OS = level even if the application doesn=E2=80=99t explicitly do so.) If so, = is there a reason to treat the RUE Differently? >>>>> =20 >>>>> Thanks, >>>>>=20 >>>>> Jim Malloy >>>>> Principal Information System Engineer >>>>> The MITRE Corp. >>>>> 703 983 2835 >>>>> =20 >>>>> From: Rum > On = Behalf Of Brian Rosen >>>>> Sent: Tuesday, February 9, 2021 8:44 AM >>>>> To: Hamlin, James > >>>>> Cc: rum@ietf.org >>>>> Subject: [EXT] Re: [Rum] I-D Action: draft-ietf-rum-rue-04.txt >>>>> =20 >>>>> I=E2=80=99ll delete the text in registration. =20 >>>>> Every VoIP phone I=E2=80=99ve ever seen or used caches username = and passwords for stand alone use. Every one. They do that for a = simple reason - so incoming calls work after a power loss. Most also = are effectively set and forget, which is what you want in a phone. Why = would we require manual entry for the RUE? >>>>> =20 >>>>> The text currently uses the same credentials for the HTTP service = and the SIP service, but that=E2=80=99s it. I think that=E2=80=99s = pretty reasonable. >>>>> =20 >>>>> If you have another proposal for how we can maintain the config = data securely, please suggest one. >>>>> =20 >>>>> Brian >>>>>=20 >>>>>=20 >>>>> On Feb 9, 2021, at 4:42 AM, James Hamlin > wrote: >>>>> =20 >>>>> Brian >>>>> =20 >>>>> Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service portal.". = However, in the 04 draft, passwords are no longer returned in the = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require. >>>>> =20 >>>>> Best regards >>>>> =20 >>>>> James >>>>> =20 >>>>> =20 >>>>> =20 >>>>> =20 >>>>> James Hamlin >>>>> Contractor >>>>> Purple, a Division of ZP Better Together, LLC >>>>> purplevrs.com = >>>>> The information contained in this e-mail message is intended=20 >>>>> only for the personal and confidential use of the recipient(s)=20 >>>>> named above. If you have received this communication in error,=20 >>>>> please notify us immediately by e-mail, and delete the original=20 >>>>> message. >>>>> =20 >>>>> From: Rum > on = behalf of Brian Rosen > >>>>> Sent: 05 February 2021 22:26 >>>>> To: rum@ietf.org >>>>> Subject: [Rum] Fwd: I-D Action: draft-ietf-rum-rue-04.txt >>>>> =20 >>>>> I have posted a -04 revision. This should handle all comments = received so far, please let me know if I forgot something. >>>>> =20 >>>>> This version reworks the provider list and configuration sections = along the lines we have been discussing. >>>>> =20 >>>>> I do not have a way to download a username/password from a new = signup. I=E2=80=99m having trouble thinking about a secure way to do = that. If anyone has an idea, I=E2=80=99m very willing to write text for = it. I=E2=80=99ve considered things like javascript that stashes it in a = file or somewhere else, having some web page function that triggers a = local display of an entry form for username and password, and a couple = of other things. >>>>> =20 >>>>> One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =20 >>>>> =20 >>>>> For now, I=E2=80=99ve removed the step by step diagram that showed = how the config mechanism is used. I think what is there is dead simple = and needs no explanation: it=E2=80=99s a straightforward REST/JSON web = service using username/password authentication for providers the user = has accounts with. I can bring back the diagram if that is needed. >>>>> =20 >>>>> Brian >>>>> =20 >>>>>=20 >>>>>=20 >>>>> Begin forwarded message: >>>>> =20 >>>>> From: internet-drafts@ietf.org >>>>> Subject: I-D Action: draft-ietf-rum-rue-04.txt >>>>> Date: February 5, 2021 at 5:17:15 PM EST >>>>> To: > >>>>> Cc: rum@ietf.org >>>>> Reply-To: internet-drafts@ietf.org = , rum@ietf.org >>>>> =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-04.txt >>>>> Pages : 33 >>>>> Date : 2021-02-05 >>>>>=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-04.html = >>>>>=20 >>>>> A diff from the previous version is available at: >>>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04 = >>>>>=20 >>>>>=20 >>>>> Please note that it may take a couple of minutes from the time of = submission >>>>> until the htmlized version and diff are available at = tools.ietf.org = . >>>>>=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 >>>>> =20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 --Apple-Mail=_9843C7C3-B2A9-4A6A-9069-6BCD0AE2D95D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 What = do you want to do with OAuth?  Make it mandatory, optional or not = included?  I=E2=80=99m happy with any of these.  If it is = included, is it used for authentication to the configuration service, = the SIP/STUN/TURN services or both?

Brian


On Feb 25, 2021, at 3:49 AM, James Hamlin <james.hamlin@purple.us> wrote:

Brian

Having consulted internally, we are content if support = for separate passwords and tokens is dropped, as providers could always = allocate users separate RUM RUE passwords if required.

Also we think the refresh token, as it was previously = discussed, would have been the result of using OAuth. So OAuth would = have provided a token that allowed the RUE to refresh its config without = retaining the user password; which fit's with Olle's = suggestion.

James

James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 18:39
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Okay, let=E2=80=99s walk through how this is used:
1. The user creates a new account.  They create a = username/password for the account.  That is stored in the = device
2. The device retrieves configuration using = the username/password
3. Configuration may contain = a refresh token.  This is a password.  The token is used = instead if the actual password, but with the actual username, to do = SIP/STUN/TURN authentication.
4. The refresh token = is used until the config retrieval changes it.

Is that right?  Can you explain = why this is better than just using the account = username/password?

Brian


On Feb 23, 2021, at 12:48 PM, James Hamlin = <james.hamlin@purple.us> wrote:


I was = assuming the refresh token would simply stand in for the password = literally. That said, when the idea was previously discussed, the token = would have solely been used in authentication for config retrieval, as = SIP would use the password set by configuration. It has been a long time = since the refresh token was discussed so others might remember = more.

I think the provider needs to keep one = token valid until the next is first used or make it valid = for much longer than the configuration lifetime.


James



James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 17:21
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Is the token a username/password equivalent (meaning, does it = use the normal SIP REGISTER authentication)?
As long as = it=E2=80=99s valid until replaced, that=E2=80=99s OK with me.

Brian


On Feb 23, 2021, at 12:06 PM, = James Hamlin <james.hamlin@purple.us> wrote:


It's = been a while since the refresh token was discussed; but if it is = returned in the configuration, the RUE should = replace/overwrite it's stored copy of the user = password with the token. The token would = then be valid where the user password was = valid initially. Similarly, in further refreshes of the = config, if a refresh token is returned, it replaces the = previous token. That wouldn't have any effect on the = ability to recover from power failure. 
 
James

James = Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 23 February 2021 15:09
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Okay, I=E2=80=99ll add optional SIP/STUN/TURN credentials. =  

Tell me a = little more about how you think the refresh token would work. =  Would it allow a device to have a power failure, come back, and = accept incoming calls?

Brian



On Feb 23, 2021, at 9:58 AM, = James Hamlin <james.hamlin@purple.us> wrote:

Brian

I think = having the flexibility to optionally return separate SIP/STUN/TURN = credentials could be useful. Optionally returning a = refresh token which the RUE would hold in = place of the user = login password would also be useful, as it = would mean the login password would not = have to be stored after the = first configuration; refreshing an expired configuration = would be done with the refresh token.

James


James Hamlin
Contractor
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 <br@brianrosen.net>
Sent: 22 February 2021 18:46
To: James Hamlin
Cc: Jim = Malloy; rum@ietf.org
Subject: Re: [EXT] [Rum] I-D Action: = draft-ietf-rum-rue-04.txt
 
Can we figure out how to converge on this? 

There are:
a) Actual user login credentials
b) SIP = credentials
c) STUN/TURN credentials

The current draft treats = them all as identical.  Is there a reason to make them separate? =  My VoIP accounts have only one set.  I=E2=80=99m okay adding = a separate SIP/STUN/TURN credential returned in the config file, = protected by the actual user login credentials, if that is really = useful.  Maybe it could be optional, and if not provided, the = userid/password is used for everything.

Brian

On Feb 9, 2021, at 9:41 AM, James Hamlin <james.hamlin@purple.us> wrote:

Jim

Yes = credentials have to be cached, but not necessarily the user's primary = account credentials. The previous text allowed the configuration service = to send back separate credentials for SIP/STUN/TURN which could have a = shorter validity period than the main account credentials. This offers = greater flexibility in how a user's use of = different RUE's can be isolated.

I'll accept that the provider could offer a = separate password for use with each RUE type; we'd need to think about = the logistical implications of that.

Best Regards

James


James = Hamlin
Contractor
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: Jim Malloy <jmalloy@mitre.org>
Sent: 09 February 2021 14:20
To: Brian Rosen; James = Hamlin
Cc: rum@ietf.org
Subject: RE: [EXT] Re: [Rum] I-D = Action: draft-ietf-rum-rue-04.txt
 
=E2=80=9CEvery VoIP phone = I=E2=80=99ve ever seen or used caches username and passwords for stand = alone use=E2=80=9D

 

James =E2=80=93 

 

Do existing = ZVRS/Purple devices or mobile applications cache authentication = credentials?  (Mobile applications may do so at the OS level even = if the application doesn=E2=80=99t explicitly do so.)  If so, is = there a reason to treat the RUE Differently?

 

Thanks,

Jim Malloy
Principal Information System Engineer
The MITRE = Corp.
703 983 2835

 

From: Rum <rum-bounces@ietf.org> On Behalf = Of Brian Rosen
Sent: Tuesday, February 9, 2021 = 8:44 AM
To: Hamlin, James <james.hamlin@purple.us>
Cc: rum@ietf.org
Subject: [EXT] Re: [Rum] I-D Action: = draft-ietf-rum-rue-04.txt

 

I=E2=80=99ll delete = the text in registration.  
Every VoIP phone I=E2=80=99ve ever seen or used caches = username and passwords for stand alone use.  Every one.  They = do that for a simple reason - so incoming calls work after a power loss. =  Most also are effectively set and forget, which is what you want = in a phone.  Why would we require manual entry for the = RUE?

 

The text = currently uses the same credentials for the HTTP service and the SIP = service, but that=E2=80=99s it.  I think that=E2=80=99s pretty = reasonable.

 

If you have another proposal for how we can maintain the = config data securely, please suggest one.

 

Brian


On Feb 9, 2021, at 4:42 AM, James Hamlin <james.hamlin@purple.us> = wrote:

 

Brian

 

Section 5.1 Registration says that "The credentials to be used = (username and password) MUST be supplied within the credentials section = of the configuration and identified by the realm the registrar uses in a = digest challenge. This username/password combination SHOULD NOT be the = same as that used for other purposes, such as retrieving the RUE = configuration or logging into the Provider's customer service = portal.". However, in the 04 draft, passwords are no longer = returned in the  = configuration. I think we need to avoid the RUM RUE caching the user's = main account password, which this draft seems to require.

 

Best regards

 

James

 

 

 

 

James Hamlin
Contractor
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: Rum <rum-bounces@ietf.org> on behalf of Brian Rosen <br@brianrosen.net>
Sent: 05 = February 2021 22:26
To: rum@ietf.org
Subject: [Rum] Fwd: I-D Action: = draft-ietf-rum-rue-04.txt

 

I = have posted a -04 revision.  This should handle all comments = received so far, please let me know if I forgot something.

 

This version reworks the provider list and configuration sections = along the lines we have been discussing.

 

I = do not have a way to download a username/password from a new signup. =  I=E2=80=99m having trouble thinking about a secure way to do that. =  If anyone has an idea, I=E2=80=99m very willing to write text for = it.  I=E2=80=99ve considered things like javascript that stashes it = in a file or somewhere else, having some web page function that triggers = a local display of an entry form for username and password, and a couple = of other things.

 

One note on the configuration mechanism - because the only thing = the local RUE device needs to keep is the username password against a = provider ID of some kind, there isn=E2=80=99t any need to standardize = how that works, and so it=E2=80=99s completely absent in the text. =  

 

For now, I=E2=80=99ve removed the step by step diagram that = showed how the config mechanism is used.  I think what is there is = dead simple and needs no explanation: it=E2=80=99s a straightforward = REST/JSON web service using username/password authentication for = providers the user has accounts with.  I can bring back the diagram = if that is needed.

 

Brian

 



Begin forwarded message:

 

From: internet-drafts@ietf.org
Subject: I-D Action: = draft-ietf-rum-rue-04.txt
Date: February 5, 2021 at 5:17:15 PM = EST
To: <i-d-announce@ietf.org>
Cc: rum@ietf.org
Reply-To: internet-drafts@ietf.org, rum@ietf.org

 


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-04.txt
Pages =           : 33
Date =            : = 2021-02-05

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-04.html=

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-rum-rue-04<= br class=3D"">

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

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


_______________________________________________
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

 

 

 










= --Apple-Mail=_9843C7C3-B2A9-4A6A-9069-6BCD0AE2D95D-- From nobody Fri Feb 26 09:09: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 417F73A128E for ; Fri, 26 Feb 2021 09:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 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] 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 MPf7NnJr0vhm for ; Fri, 26 Feb 2021 09:09:21 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750044.outbound.protection.outlook.com [40.107.75.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 BF93B3A129E for ; Fri, 26 Feb 2021 09:09:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YspQj01DlRv37dZv7VzQRjoQhf4+wWISae2cN19eeZpOjeymoRKcFI0TEEHMUK2Sf1JD9KsPOuB29GwL8g3jQHW50+2d9UpM302VBEk+eeaPy7l5rKlwCQMDq3Fg+UlDiBM77/NevdPWdpQBDr2PUWKkEXZbid9cOihqOWfF91vbbu7rdAD0w0846xCRUzYvJOC4xVBU2qMFOoMhVumGGEVaVSDjXHhy3/LdqsER5qx/NZW6dnEOzo18KsDvcN483KZJZ6juH1vFRCHNefpP1aPPJUe4NdTKVK3oPkOBVyhLDQcdOwEUWfKjpKtYUduRUwXx/To6sW7TMnHFrT5c/g== 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=OozajVpZudZGYyryCGIsPHARc9IlegJMAwJhewJlCgw=; b=hgMOwyqPQK13cLKq5CPu+28TJAcRjy6Yj+xla+9H1iatug5gf/3bvGKB1NAi9N4DIg5LBDOsQTVKtx1t3qDb3Eg5jp+C6baiHK/2MUfDoB2Y/qujoT0I6xGSyvidMngiJtDnaCFinMH2aBEVIuT9jRtzZkZyxrvyb0ri5fb1TIO+gv7uDVWLlTUWqEn1QFMtrNzJANxjtGhXaJS2RPxpLtZai0UEZer1rkXdU1V0as472LuE6cnSpWAwjTe8glu5v1WGrQz/CwES29Q/eWg1v6qjpJCTxalurCNoFId41GkwWdODVKRiV6KOGihChs06RntBLcN/no9GPuoqpmt5TQ== 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=OozajVpZudZGYyryCGIsPHARc9IlegJMAwJhewJlCgw=; b=aiTR0603agTLgMGFgbVtYJSOdP/xr83gvS0d87BPZa+b4k1JvGuvjhVQuQLfIYPrVCP88dauttbw1rnlr3aTQ1GOFGhbPln9TgjTnh8yKtLqkPxSkhCD74nhkcDjDnT+Mkz1l288earOi/fG7cHlh56yyS6q6olMd8uISvQxzHE= Received: from SA9PR13CA0094.namprd13.prod.outlook.com (2603:10b6:806:24::9) by DM5PR1201MB0203.namprd12.prod.outlook.com (2603:10b6:4:56::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.20; Fri, 26 Feb 2021 17:09:17 +0000 Received: from SN1NAM02FT063.eop-nam02.prod.protection.outlook.com (2603:10b6:806:24:cafe::37) by SA9PR13CA0094.outlook.office365.com (2603:10b6:806:24::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.11 via Frontend Transport; Fri, 26 Feb 2021 17:09:17 +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 SN1NAM02FT063.mail.protection.outlook.com (10.152.72.213) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19 via Frontend Transport; Fri, 26 Feb 2021 17:09:15 +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 11QH9DLq004967 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Fri, 26 Feb 2021 12:09:14 -0500 To: "Olle E. Johansson" , rum@ietf.org References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1e064a43-b3c5-7ffb-2965-448eae62ff20@alum.mit.edu> From: Paul Kyzivat Message-ID: Date: Fri, 26 Feb 2021 12:09:13 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 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: ba4dc403-6278-479c-0320-08d8da793f55 X-MS-TrafficTypeDiagnostic: DM5PR1201MB0203: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:6108; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: rIe3dRPBtmyGwKvLy+kMHBINLc22rSu7bglcTygrsX+ImEfY67GjZ+rrJnL3p2K767nR4i+J+SbVvZjs5f0zfSdOPAyAv/08p9Tm8Mg8jURBFIkP/6eQoWWfhKGN5TKAN+xVN2/icShx1tmZIwzhw726lqxUedq5Lwtp3H6OpmYGhSPbIf1Ddei8uJBnbCCl2F9WGDQqbJmbykWX8gmQRXaG9cjPviVvf5XutUezgUDf5gZagd7c4U8YayiPTcydQFa65TZIP38qv7A5URRZSDfEivjwf9h0XBIk3kd4D12Kz3+2ZAv9v6IxuOfHGXiilEv9r3KPPLW9+nCLsyE9SRUhbwMfbIBhgxrDGd9ICJ36X14KQiQ2hSv26soTMyg/W2GTrksPv89UtcbYyJevQZD9OCOeQBqalSbAuajRcbHRzmfn8D/e4d9hQDri4rnE1jqu4LqAZTthuT/vCltrPySoX5S+HRJl7iTOfGBshzmPTgNFDMiXJplfW3uN8aZ1PMdgVCpkIPXRfweJn0ZtjTBBjazqOMR7RZEj0l1V95PclKj5EMbHpjjY2iefbJLw4knK5XIixMDudv87QWd4kzG41Am3rOTEI43iNa/k0fNU/Zovy9jqHtlGtNBNBjO6Bno5/wMyt8VcTAWo/KlEvx3kSr+Q0EzECYrvl1Ukg3/q1lFm+JQMnH1AtumCtp3M 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)(136003)(376002)(36840700001)(46966006)(36906005)(478600001)(356005)(316002)(786003)(956004)(47076005)(2616005)(8676002)(4744005)(82310400003)(7596003)(31696002)(86362001)(70586007)(186003)(36860700001)(336012)(82740400003)(8936002)(53546011)(26005)(75432002)(2906002)(70206006)(5660300002)(31686004)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Feb 2021 17:09:15.8030 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ba4dc403-6278-479c-0320-08d8da793f55 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: SN1NAM02FT063.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1201MB0203 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 17:09:23 -0000 On 2/26/21 1:51 AM, Olle E. Johansson wrote: > When talking about WebRTC there is always confusion. There’s a library called WebRTC and a set of standards. > > Where in the set of standards does it forbid T.140? I don’t think that the assumption that IETF/W3C WebRTC > doesn’t support T.140 is correct. > > That browsers hasn’t implemented support is another issue. That browsers haven't implemented it is *the* issue. Since webrtc has defined T.140 over data channel it is hard for me to imagine what would them to support it directly over RTP. There is no way to get there from here. Thanks, Paul From nobody Fri Feb 26 09:53: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 7F39B3A13D2 for ; Fri, 26 Feb 2021 09:53:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDQCOym1Ra5C for ; Fri, 26 Feb 2021 09:53:51 -0800 (PST) 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 CB63C3A13D1 for ; Fri, 26 Feb 2021 09:53:49 -0800 (PST) Received: from macbook-pro.webway.org (h-205-16.A165.corp.bahnhof.se [176.10.205.16]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1FB7A3FA; Fri, 26 Feb 2021 18:53:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: "Olle E. Johansson" In-Reply-To: Date: Fri, 26 Feb 2021 18:53:45 +0100 Cc: Olle E Johansson , rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <997CF563-D2D8-4B95-8498-4A03059F7AAB@edvina.net> References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1e064a43-b3c5-7ffb-2965-448eae62ff20@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 17:53:54 -0000 > On 26 Feb 2021, at 18:09, Paul Kyzivat wrote: >=20 > On 2/26/21 1:51 AM, Olle E. Johansson wrote: >=20 >> When talking about WebRTC there is always confusion. There=E2=80=99s = a library called WebRTC and a set of standards. >> Where in the set of standards does it forbid T.140? I don=E2=80=99t = think that the assumption that IETF/W3C WebRTC >> doesn=E2=80=99t support T.140 is correct. >> That browsers hasn=E2=80=99t implemented support is another issue. >=20 > That browsers haven't implemented it is *the* issue. >=20 > Since webrtc has defined T.140 over data channel it is hard for me to = imagine what would them to support it directly over RTP. There is no way = to get there from here. >=20 I can accept that, but we can=E2=80=99t write that =E2=80=9CWebRTC does = not support T.140=E2=80=9D. If you write your own implementation nothing = stops you from implementing T.140 in RTP or over data channel. /O :-) From nobody Fri Feb 26 12:57: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 92B033A08A5 for ; Fri, 26 Feb 2021 12:57:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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=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 f4DLPlUA2AJa for ; Fri, 26 Feb 2021 12:57:11 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2071.outbound.protection.outlook.com [40.107.94.71]) (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 B79CB3A089C for ; Fri, 26 Feb 2021 12:57:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lEd1pXW5z/6+nxqkQLGCx6rA70zcWyGJF6KuEQbrZCFyOGYyeyCdF1KQ7WT/mTKgBXXfGD6p2JwsmzLzRYiDRhJV6W7wDTytXYtEdx9flnKXFiMTl//pNGi1D/TqzcItYMd9wEVyK1p3vnqI+uLb7XNOOdSY8T2JohM3N7EwK1eXghixKUyUk4FGHXF57Xym6X2f3rPuOFaW8zmlkv6EYmfx5C+W4VCo02F3P1qvNIt65ZqmoUjLwaVc1CEip/i9nac/QStk30/G3A/YvMSvMm5DRO1G+XhZFttMPtAWJ5R/C1REAPyYVl3+LbmrLPU0UOLB7ZUUh/hXsCf1VzT1Wg== 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=ggQaxDFlfSbXlBKNtu5Z51o6On/Y/Q0QbS4bRBvNNFc=; b=ngAKwojhSV6CL7h0MJI2kYXOPkAAlHLn5x9wFgoKJGZfz7OZ5BagM0Rne+PB7MbBEmM3728xQtiGT6SKbC/mjwMlUoyduFjmeK+EJXmU1LAa/xikmsY8ZtkZIKm5rZBbbVk9xU24fdcR27HDHvOlzEq4OhmghyfXSLFg/Ebw+4i+acs7psJRMvY7YNO8za05mEzYnHguu7SpQrhC/tkjuNt/c+F0mEF38iQBklcdZV3IAk5gb7sy7yiwRj3sTGjws6xfNYFEvv2vfNjab7nm2uh9Bg064mHkWZ4pXw+GNnq1aT6yDtPhR3CmcYwVdGzIJYrW7tnz+RuDbq/QXJqG/g== 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=ggQaxDFlfSbXlBKNtu5Z51o6On/Y/Q0QbS4bRBvNNFc=; b=MHx3428sAt8VU9KTuRimR3JB3CJN0CWawL3SBTvedK3zcPX6S5SCAHCXY80nm7CWAvJIlrz3H3a3ZRTjHXzpsmmUupp+ndpLcOMAemM1a/clBzIqa1VzNbkNurBf7XBgbr/9kK7645EGq7P/+lHtwkr/m7AgoJt5h+GvXZ3RCR4= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BYAPR04MB4136.namprd04.prod.outlook.com (2603:10b6:a02:f3::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Fri, 26 Feb 2021 20:57:09 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681%6]) with mapi id 15.20.3868.033; Fri, 26 Feb 2021 20:57:09 +0000 From: Eugene Christensen To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHXDFl09ClV00YhdkatG794CYRulapq6C6w Date: Fri, 26 Feb 2021 20:57:08 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <435B03D2-3AC7-4A41-A265-3E90936D7E8D@brianrosen.net> In-Reply-To: <435B03D2-3AC7-4A41-A265-3E90936D7E8D@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-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89ec3085-5ad4-436d-c3f5-08d8da991515 x-ms-traffictypediagnostic: BYAPR04MB4136: x-ms-exchange-minimumurldomainage: ietf.org#9484 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZKsAk/EcMNZiqCQy43vxwEJonY/zcdEOveVrpxyFUujRjCHLVbobQyeoinEUfgTfbHq/DXNDZ/7pxZxSXcdDKzvodlsaLFsKoe/OMYfP76ghGl6C3jTUDuOMnRgYD/iPIXNZMAvAbUhcLmE9+FvtrA4Skz9jZVrJULtpY9okC+y8vy/1xsbalIyDVwCJ3eQhWYVCo/32v8wK3H4pA9h39ADrZC+2rdKPH+BoKFDf2f6Wn5g5INBcKFJX+KrZIiUS/+DFmNQ8d37m8e0OsiJS+1SZygwLYmGNXeSEj0pzWOULAkg3GanHPDHzC/qx4DfL+V7eBPe+K+/TmI+UmYAyt5oEXB0GjNisGGxfLSAxvRMDmkng1MG13CMtZzGgGr4Kc+ZjF9HQm5/gUKDzQkUPB3hbl8CYELammWfDlam13szvnfJvhPoT1Pn0pcuJrWWPgYtBpPwAbR7MLoZfeTv8jIOi5QnAG7IJ4lYbmiiBjVa/jkyABRtrBMh7wCpqnVQtGdxXQdNCGWg87UaldvHSpNYQgwFViHQJjW8VVQ9PnP+3vRicHUiOMbvelbdC5LfZrLG61nv/OT11AMYQua9GWw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(39850400004)(136003)(376002)(366004)(396003)(7696005)(316002)(66476007)(8676002)(66556008)(966005)(71200400001)(6506007)(186003)(64756008)(21615005)(52536014)(76116006)(66946007)(26005)(18074004)(6916009)(86362001)(66574015)(4326008)(33656002)(2906002)(9686003)(478600001)(5660300002)(53546011)(8936002)(166002)(66446008)(83380400001)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?V0xPb2p3R1M3Zzl3NkVVdmxmdDJrYm9VSGQ4Y3l1U2tMZW5lOUM0blQwTnIv?= =?utf-8?B?ckV6ZVRFaDFXWnhtejNBc3Bab2ZMZUgrMzlzVVRzVVZBR2R4V2V4NjJJaTMv?= =?utf-8?B?Ujh0blhhKzVTZCtSWko3OTlLVnl2dXdxMVFNOGNoZkZrK2hhakxVZkVuTktZ?= =?utf-8?B?ZVQ3S0hHSDI0c3prQ2c4ZGYxL0ovdnZuV1VYWlluU1pUYlkzSHJTVHdtNGJU?= =?utf-8?B?Wm43YllKc2g4Z2pmMUR0K3E3T3NNTW9lN2FjWjhWb1hiL3VTYWNSZDVBcyt4?= =?utf-8?B?aVFEOU53U3ZwRFJhVWJad0lxTCtIYlJ5cmVaK1crbVg3Vm8yS3crVk5NQ3Bs?= =?utf-8?B?U3VCOStnM1hoNktadHo5STdNN1A0NUpQYUd2M0p5UktNNFpVVGVlakVlbjNI?= =?utf-8?B?SytnbVB3U1NlOFdrVTFNN2Z5VEd0ZXdBakxScTREcTM0bHpkY3NIMndiMVY4?= =?utf-8?B?Y2R6MnVSNEZkdkVHeVdRNnRoRElxdFF6bTJORGdTZ2VPY2VCQklodUYyeTVl?= =?utf-8?B?VmlKWnVjVnpVYzd3Qm9ZSEZoSkFFVjBUTW9oWUQ3QnM2bHozLzZTaW5SU2Zz?= =?utf-8?B?aDNRa0hEWnU5cVpIMjJjeGI5aUVPc3VDVjQ4cEdXSHJ1K2JBWVZzUkdLNENs?= =?utf-8?B?ZHByMnhtdUNNZzlqTmpyUHV5UXk4ODZGaUdLakkveW03VHRVclRISnU3aVY2?= =?utf-8?B?QmFkNUdVVmVDY0pJdmNza2pzWStiNFlzYS9EYjhOdUFBeDBLaTJ3Qm1SZ2Ew?= =?utf-8?B?Z0hnM05OSE5pSDRMUVFHNmlRUUdCTytuaTBkenFJUkJqOExrMnlONm41L3lq?= =?utf-8?B?cDRHTnpMMmU4SU9pNU53YzFYYjZ2SFRZOTZDdzE3QmhnemQrUDdTbUJLdzVw?= =?utf-8?B?YzA5ZEdpK1psYVUwTUlybFJpZGFXbDNya3RUWkd6THJkQ201V1NLNVVKZUhY?= =?utf-8?B?WDc5akcxcDdUTVl2RXRyZENUVnFlZWM1YSt2ek1QaU9NR0Z1aXYwak93UERI?= =?utf-8?B?aVA0VHdOemtaTmxkM1RucXlHKzhaclJIcXR3NVl4ek1SaHF0REovMFdkNDF5?= =?utf-8?B?d2dJREUxQ3dWbWZCYzdsbWZ0a3kyZC9nT1ExT0Y1enZTSGEzb0dRK2RzSk90?= =?utf-8?B?NkZPQ2hDa2xmUEpvQW9WcmoweVk1WStHRW1LVzZ4bEM1SS95NVhRajlRTERv?= =?utf-8?B?cEFWM2NHdG9HUDJtdmswZVExY0UvVFRWMVc0VFY3UW1MbVJXVTlzS1FzSFVx?= =?utf-8?B?bDRBOVdodXcwUEYzMytLOXVkNzM0YXpTLzdYYVlvdDNrcHdJMS9YaGFjTUR1?= =?utf-8?B?RHZwY2RmS25tQzZGZGtPMmw0aFJqeGdPeUJZV1ErSkd5SjRKSlU4cHJhdW9a?= =?utf-8?B?OWY3UHVvbXNHalZSeC9UdktxdGpGUEp1alMyYTRQdkFtMjNTeGR3U29iYXM3?= =?utf-8?B?MzJDbTJTR09JVjNQaExsUUVRUzB6R002YTRtNWU0dks0NkF3QUJTVWc0eG5t?= =?utf-8?B?NnBjclU5bytYOC81NUQzbXJ0R1hZSHN2UDlMVElWUXZIaklsSEdpS1U3SGpX?= =?utf-8?B?dVVwaUdmckthQjc2bHFEU205SDF4WWQ0R3dFL09ocHNWZ0lOVTVuaUVsZWJl?= =?utf-8?B?a1JFalY3NHlYMW8zSFRrdTIvT01RNmg5RHo1alZTcld6N3ZOVHFjZ1gxdTNj?= =?utf-8?B?WWFRMXNYQjZaRHdnWEltWklVN09VRzF1eFpJaTRrVjlNeTBMSTlYbjVKY0pU?= =?utf-8?Q?yezAqgv4ROAyJLoL7rIjMGlDqc6csZcpvlj9DDN?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR04MB4983FF05A3240251C3124A72A39D9BYAPR04MB4983namp_" MIME-Version: 1.0 X-OriginatorOrg: sorenson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89ec3085-5ad4-436d-c3f5-08d8da991515 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 20:57:08.9445 (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: sqQaRTKaNGBs+f5t/FZVzHz55kKClE0p86A23ATnaXVBJ4/9bw5zTib+9AvwFZywZinAqfjuDocjmiobSqCiOwwuVB9sKbsbZpQXQR9Y3MI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4136 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 20:57:15 -0000 --_000_BYAPR04MB4983FF05A3240251C3124A72A39D9BYAPR04MB4983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9yIGVtZXJnZW5jeSBjYWxscyBhbmQgdGhlIGFiaWxpdHkgdG8gYWRkIGEgbG9jYXRpb24gb24g dGhlIGRldmljZSwgd2UgbmVlZCB0byBrZWVwIGluIG1pbmQgdGhhdCBhIGN1c3RvbWVyIGNvdWxk IGhhdmUgbXVsdGlwbGUgZGV2aWNlcy4gIFNvbWVob3csIHdlIG5lZWQgdG8gdGllIHRoZSBwaHlz aWNhbCBhZGRyZXNzIHRvIGVhY2ggZGV2aWNlLiAgUGVyaGFwcyBieSBNQUMgYWRkcmVzcywgSeKA mW0gbm90IHN1cmUgaG93IGVhY2ggb2YgdGhlIGN1cnJlbnQgVlJTIHByb3ZpZGVycyBkbyB0aGlz LiAgQWxzbywgaXQgd291bGQgYmUgZ29vZCB0byBrZWVwIHRoZSBhYmlsaXR5IHRvIHVwZGF0ZSB0 aGUgYWRkcmVzcyBkaXJlY3RseSBvbiB0aGUgZGV2aWNlLCBhcyBpdCBpcyBub3cuICBJbiBmYWN0 LCBzaW5jZSB3ZSBuZWVkIHRvIHBvc3NpYmx5IHJlZ2lzdGVyIGFkZHJlc3Mgb24gbXVsdGlwbGUg UlVFcyBmb3IgdGhlIHNhbWUgdXNlciwgZG9pbmcgc28gb24gdGhlIGRldmljZSBzZWVtcyB0byBi ZSBhIG5hdHVyYWwgc29sdXRpb24uDQoNClRoYW5rcy4NCg0KRXVnZW5lLg0KDQpDT05GSURFTlRJ QUxJVFkgTk9USUNFLiBUaGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBhbnkgZG9jdW1lbnRz LCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3BvbnNpYmxlIGZv ciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8g dGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklURUQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1l IGJ5IHJlcGx5IGUtbWFpbCBhdCBlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0bzplY2hy aXN0ZW5zZW5Ac29yZW5zb24uY29tPiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0 MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2ht ZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KDQpGcm9t OiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ+DQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5 IDI2LCAyMDIxIDk6MDcgQU0NClRvOiBFdWdlbmUgQ2hyaXN0ZW5zZW4gPGVjaHJpc3RlbnNlbkBz b3JlbnNvbi5jb20+DQpDYzogcnVtQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1J1bV0gSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dA0KDQpbRVhURVJOQUxdIFRoYW5rcyBmb3Ig dGhlc2UgY29tbWVudHMuDQoNCldpdGggcmVzcGVjdCB0byBlbWVyZ2VuY3kgY2FsbHMsIHlvdSBh cmUgbGltaXRlZCBieSBGQ0MgcmVndWxhdGlvbnMgaW4gdGhlIFVTLCBJIGJlbGlldmUsIGFsdGhv dWdoIHRoZXJlIGFyZSAzcmQgcGFydHkgZW50aXRpZXMgdGhhdCBzdXBwbHkgZXh0cmEgbG9jYXRp b24gaW5mb3JtYXRpb24gZnJvbSBHb29nbGUgYW5kIEFwcGxlIGFmdGVyIHRoZSBjYWxsIGlzIHJl Y2VpdmVkIGF0IGEgUFNBUC4gIEkgdGhpbmsgeW91IGhhdmUgdG8gdXNlIGEgbG9jYXRpb24gY29s bGVjdGVkIChhbmQgdmVyaWZpZWQpIGFzIHBhcnQgb2YgYWNjb3VudCBlc3RhYmxpc2htZW50LiAg VHlwaWNhbGx5IHRoZXJlIGlzIGEgd2Vic2l0ZSB0aGF0IHVwZGF0ZXMgdGhpcyBhcyBuZWNlc3Nh cnkuICBJIGRvbuKAmXQgbGlrZSB0aGF0IGFzIHRoZSBhbnN3ZXIsIGJ1dCBJIHRoaW5rIHdl4oCZ cmUgc3R1Y2sgd2l0aCBpdC4gIE90aGVyIGNvdW50cmllcyBtYXkgaGF2ZSBtb3JlIGZsZXhpYmls aXR5LiAgVG8gYmUgc3VyZSwgdGhlIGRldmljZSBNQVkgYWRkIGEgbG9jYXRpb24gdmlhIHRoZSBH ZW9sb2NhdGlvbiBoZWFkZXIuICBJdOKAmXMganVzdCB0aGF0IHRoZSBwcm92aWRlciBNVVNUIGFk ZCBhIGxvY2F0aW9uLiAgIEkgY2FuIG1ha2UgdGhhdCBjbGVhciBpbiB0aGUgdGV4dC4NCg0KVGhl IHRoaW5nIGFib3V0IFdlYlJUQyBpcyB0aGF0IGl0IGRvZXMgc3BlY2lmeSBULjE0MCwgYnV0IHRy YW5zcG9ydCBpcyBpbiB0aGUgZGF0YSBjaGFubmVsLiAgVGhlIFJVRSBzcGVjIGlzIFQuMTQwIGlu IFNEUC4gIFRoZSB0cmFuc3BvcnQgYWRhcHRlciB3b3VsZCBiZSB0aGUgUlVFIGRldmljZSBhbmQg bm90IHRoZSBwcm92aWRlci4gSSBjYW4gdHJ5IHRvIGltcHJvdmUgdGhlIHdvcmRpbmcgdGhlcmUg dG8gbWFrZSBpdCBtb3JlIGNsZWFyLg0KDQpCcmlhbg0KDQoNCk9uIEZlYiAyNSwgMjAyMSwgYXQg MzoyNSBQTSwgRXVnZW5lIENocmlzdGVuc2VuIDxlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1h aWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPj4gd3JvdGU6DQoNCkhpIEJyaWFuLg0KDQpJ 4oCZdmUgYmVlbiByZXZpZXdpbmcgZHJhZnQgNCBzb21lIG1vcmUgYW5kIGRpc2N1c3NpbmcgaXQg aW50ZXJuYWxseSBhbmQgd29uZGVyIGFib3V0IHRoZSBmb2xsb3dpbmc6DQoNClNlY3Rpb24gNS4y LjUgRW1lcmdlbmN5IENhbGxzDQpJdCBzZWVtcyB0aGF0IHNpbmNlIHRoZSBSVUUgY291bGQgYmUg b24gbWFueSBkaWZmZXJlbnQgZGV2aWNlIHR5cGVzLCBpbmNsdWRpbmcgbm9uLW5vbWFkaWMgZGV2 aWNlcyBzdWNoIGFzIGRlc2t0b3BzLCB3ZSBzaG91bGQgcmVxdWlyZSB0aGUgUlVFIHRvIHByb3Zp ZGUgYSB3YXkgdG8gZm9yIHRoZSB1c2VyIHRvIGlucHV0IHRoZWlyIGFkZHJlc3MuICBXaXRob3V0 IHN1Y2gsIGl0IHdpbGwgcmVxdWlyZSB0aGUgQ0EgdG8gYXNrIHRoZSBjYWxsZXIgaW4gYW4gZW1l cmdlbmN5IHNpdHVhdGlvbiBmb3IgdGhlaXIgbG9jYXRpb24uICBUaGUgY2FsbGVyIG1heSBiZSBo YXZpbmcgaXNzdWVzIGF0IHRoZSB0aW1lIG9mIHRoZSBjYWxsIGFuZCBtYXkgYmUgbGltaXRlZCBp biB0aGVpciBhYmlsaXR5IHRvIHByb3ZpZGUgc3VjaCBpbmZvcm1hdGlvbiBhcyB0aGVpciBsb2Nh dGlvbi4gIEZvciB0aGlzIHJlYXNvbiwgSSB0aGluayB0aGUgUlVFIHNob3VsZCBiZSByZXF1aXJl ZCB0byBpbXBsZW1lbnQgVUkgdG8gb2J0YWluIHRoaXMgYWhlYWQgb2YgdGltZSBhbmQgYWxzbyB0 byBiZSB1cGRhdGVhYmxlLg0KDQpTZWN0aW9uIDYuMiBUZXh0LUJhc2VkIENvbW11bmljYXRpb24g YW5kIFdlYlJUQw0KR2l2ZW4gdGhhdCBXZWJSVEMgZG9lcyBub3QgeWV0IHN1cHBvcnQgVC4xNDAg YW5kIGEgdHJhbnNjb2RlciB3aWxsIGJlIHJlcXVpcmVkIChhcyBhbHJlYWR5IG5vdGVkIGluIHNl Y3Rpb24gNi4yKS4gIElmIHRoZSBlbmRwb2ludCBpcyBhIFdlYlJUQyBzb2x1dGlvbiwgSSB3b25k ZXIgaWYgdGhlIHRyYW5zY29kZXIgc2hvdWxkIGJlIHJlcXVpcmVkIG9mIHRoZSBkZXZlbG9wZXIg b2YgdGhlIFdlYlJUQyBzb2x1dGlvbiBhbmQgbm90IHRoZSBwcm92aWRlcnMuICBJIGJlbGlldmUg bGFuZ3VhZ2UgZXhwcmVzc2luZyB0aGlzIHNob3VsZCBiZSBhZGRlZCB0byB0aGlzIHNlY3Rpb24g dW50aWwgc3VjaCB0aW1lIHRoYXQgV2ViUlRDIGhhcyBhbiBhY2NlcHRhYmxlIHNvbHV0aW9uIGZv ciBULjE0MC4NCg0KDQpDT05GSURFTlRJQUxJVFkgTk9USUNFLiBUaGlzIGUtbWFpbCB0cmFuc21p c3Npb24sIGFuZCBhbnkgZG9jdW1lbnRzLCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2Fn ZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRh cnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9y IGEgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNv cHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklU RUQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVh c2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1lIGJ5IHJlcGx5IGUtbWFpbCBhdCBlY2hyaXN0ZW5zZW5A c29yZW5zb24uY29tPG1haWx0bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPiBvciBieSB0ZWxl cGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFu c21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZp bmcgdGhlbSB0byBkaXNrLg0KDQpGcm9tOiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzpydW0tYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBCcmlhbiBSb3Nlbg0KU2VudDog RnJpZGF5LCBGZWJydWFyeSA1LCAyMDIxIDM6MjcgUE0NClRvOiBydW1AaWV0Zi5vcmc8bWFpbHRv OnJ1bUBpZXRmLm9yZz4NClN1YmplY3Q6IFtSdW1dIEZ3ZDogSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1ydW0tcnVlLTA0LnR4dA0KDQpbRVhURVJOQUxdIEkgaGF2ZSBwb3N0ZWQgYSAtMDQgcmV2aXNp b24uICBUaGlzIHNob3VsZCBoYW5kbGUgYWxsIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZhciwgcGxl YXNlIGxldCBtZSBrbm93IGlmIEkgZm9yZ290IHNvbWV0aGluZy4NCg0KVGhpcyB2ZXJzaW9uIHJl d29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZpZ3VyYXRpb24gc2VjdGlvbnMgYWxvbmcg dGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5nLg0KDQpJIGRvIG5vdCBoYXZlIGEgd2F5 IHRvIGRvd25sb2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQgZnJvbSBhIG5ldyBzaWdudXAuICBJ4oCZ bSBoYXZpbmcgdHJvdWJsZSB0aGlua2luZyBhYm91dCBhIHNlY3VyZSB3YXkgdG8gZG8gdGhhdC4g IElmIGFueW9uZSBoYXMgYW4gaWRlYSwgSeKAmW0gdmVyeSB3aWxsaW5nIHRvIHdyaXRlIHRleHQg Zm9yIGl0LiAgSeKAmXZlIGNvbnNpZGVyZWQgdGhpbmdzIGxpa2UgamF2YXNjcmlwdCB0aGF0IHN0 YXNoZXMgaXQgaW4gYSBmaWxlIG9yIHNvbWV3aGVyZSBlbHNlLCBoYXZpbmcgc29tZSB3ZWIgcGFn ZSBmdW5jdGlvbiB0aGF0IHRyaWdnZXJzIGEgbG9jYWwgZGlzcGxheSBvZiBhbiBlbnRyeSBmb3Jt IGZvciB1c2VybmFtZSBhbmQgcGFzc3dvcmQsIGFuZCBhIGNvdXBsZSBvZiBvdGhlciB0aGluZ3Mu DQoNCk9uZSBub3RlIG9uIHRoZSBjb25maWd1cmF0aW9uIG1lY2hhbmlzbSAtIGJlY2F1c2UgdGhl IG9ubHkgdGhpbmcgdGhlIGxvY2FsIFJVRSBkZXZpY2UgbmVlZHMgdG8ga2VlcCBpcyB0aGUgdXNl cm5hbWUgcGFzc3dvcmQgYWdhaW5zdCBhIHByb3ZpZGVyIElEIG9mIHNvbWUga2luZCwgdGhlcmUg aXNu4oCZdCBhbnkgbmVlZCB0byBzdGFuZGFyZGl6ZSBob3cgdGhhdCB3b3JrcywgYW5kIHNvIGl0 4oCZcyBjb21wbGV0ZWx5IGFic2VudCBpbiB0aGUgdGV4dC4NCg0KRm9yIG5vdywgSeKAmXZlIHJl bW92ZWQgdGhlIHN0ZXAgYnkgc3RlcCBkaWFncmFtIHRoYXQgc2hvd2VkIGhvdyB0aGUgY29uZmln IG1lY2hhbmlzbSBpcyB1c2VkLiAgSSB0aGluayB3aGF0IGlzIHRoZXJlIGlzIGRlYWQgc2ltcGxl IGFuZCBuZWVkcyBubyBleHBsYW5hdGlvbjogaXTigJlzIGEgc3RyYWlnaHRmb3J3YXJkIFJFU1Qv SlNPTiB3ZWIgc2VydmljZSB1c2luZyB1c2VybmFtZS9wYXNzd29yZCBhdXRoZW50aWNhdGlvbiBm b3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhhcyBhY2NvdW50cyB3aXRoLiAgSSBjYW4gYnJpbmcgYmFj ayB0aGUgZGlhZ3JhbSBpZiB0aGF0IGlzIG5lZWRlZC4NCg0KQnJpYW4NCg0KDQoNCg0KQmVnaW4g Zm9yd2FyZGVkIG1lc3NhZ2U6DQoNCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWls dG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1ydW0tcnVlLTA0LnR4dA0KRGF0ZTogRmVicnVhcnkgNSwgMjAyMSBhdCA1OjE3OjE1IFBN IEVTVA0KVG86IDxpLWQtYW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRm Lm9yZz4+DQpDYzogcnVtQGlldGYub3JnPG1haWx0bzpydW1AaWV0Zi5vcmc+DQpSZXBseS1Ubzog aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+ LCBydW1AaWV0Zi5vcmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NCg0KDQpBIE5ldyBJbnRlcm5ldC1E cmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0 b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBSZWxheSBVc2VyIE1hY2hp bmUgV0cgb2YgdGhlIElFVEYuDQoNCiAgICAgICBUaXRsZSAgICAgICAgICAgOiBJbnRlcm9wZXJh YmlsaXR5IFByb2ZpbGUgZm9yIFJlbGF5IFVzZXIgRXF1aXBtZW50DQogICAgICAgQXV0aG9yICAg ICAgICAgIDogQnJpYW4gUm9zZW4NCiAgICAgICAgICAgICAgICBGaWxlbmFtZSAgICAgICAgOiBk cmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQogICAgICAgICAgICAgICAgUGFnZXMgICAgICAgICAg IDogMzMNCiAgICAgICAgICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDIxLTAyLTA1DQoNCkFi c3RyYWN0Og0KICBWaWRlbyBSZWxheSBTZXJ2aWNlIChWUlMpIGlzIGEgdGVybSB1c2VkIHRvIGRl c2NyaWJlIGEgbWV0aG9kIGJ5DQogIHdoaWNoIGEgaGVhcmluZyBwZXJzb25zIGNhbiBjb21tdW5p Y2F0ZSB3aXRoIGRlYWYvSGFyZCBvZiBIZWFyaW5nDQogIHVzZXIgdXNpbmcgYW4gaW50ZXJwcmV0 ZXIgKCJDb21tdW5pY2F0aW9ucyBBc3Npc3RhbnQiKSBjb25uZWN0ZWQgdmlhDQogIGEgdmlkZW9w aG9uZSB0byB0aGUgZGVhZi9Ib0ggdXNlciBhbmQgYW4gYXVkaW8gdGVsZXBob25lIGNhbGwgdG8g dGhlDQogIGhlYXJpbmcgdXNlci4gIFRoZSBDQSBpbnRlcnByZXRzIHVzaW5nIHNpZ24gbGFuZ3Vh Z2Ugb24gdGhlDQogIHZpZGVvcGhvbmUgbGluayBhbmQgdm9pY2Ugb24gdGhlIHRlbGVwaG9uZSBs aW5rLiAgT2Z0ZW4gdGhlDQogIGludGVycHJldGVycyBtYXkgYmUgc3VwcGxpZWQgYnkgYSBjb21w YW55IG9yIGFnZW5jeSB0ZXJtZWQgYQ0KICAicHJvdmlkZXIiIGluIHRoaXMgZG9jdW1lbnQuICBU aGUgcHJvdmlkZXIgYWxzbyBwcm92aWRlcyBhIHZpZGVvDQogIHNlcnZpY2UgdGhhdCBhbGxvd3Mg dXNlcnMgdG8gY29ubmVjdCB2aWRlbyBkZXZpY2VzIHRvIHRoZWlyIHNlcnZpY2UsDQogIGFuZCBz dWJzZXF1ZW50bHkgdG8gQ0FzIGFuZCBvdGhlciBkZWFmL0hvSCB1c2Vycy4gIEl0IGlzIGRlc2ly YWJsZQ0KICB0aGF0IHRoZSB2aWRlb3Bob25lcyB1c2VkIGJ5IHRoZSBkZWFmL0hvSC9ILUkgdXNl ciBjb25mb3JtIHRvIGENCiAgc3RhbmRhcmQgc28gdGhhdCBhbnkgZGV2aWNlIG1heSBiZSB1c2Vk IHdpdGggYW55IHByb3ZpZGVyIGFuZCB0aGF0DQogIHZpZGVvIGNhbGxzIGRpcmVjdCBiZXR3ZWVu IGRlYWYvSG9IIHVzZXJzIHdvcmsuICBUaGlzIGRvY3VtZW50DQogIGRlc2NyaWJlcyB0aGUgaW50 ZXJmYWNlIGJldHdlZW4gYSB2aWRlb3Bob25lIGFuZCBhIHByb3ZpZGVyLg0KDQoNClRoZSBJRVRG IGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1ydW0tcnVlLw0KDQpUaGVyZSBpcyBhbHNv IGFuIEhUTUwgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwczovL3d3dy5pZXRmLm9yZy9hcmNo aXZlL2lkL2RyYWZ0LWlldGYtcnVtLXJ1ZS0wNC5odG1sDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2 aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUtMDQNCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1 bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xz LmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255 bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpJLUQtQW5ub3Vu Y2UgbWFpbGluZyBsaXN0DQpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc8bWFpbHRvOkktRC1Bbm5vdW5j ZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFu bm91bmNlDQpJbnRlcm5ldC1EcmFmdCBkaXJlY3RvcmllczogaHR0cDovL3d3dy5pZXRmLm9yZy9z aGFkb3cuaHRtbA0Kb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN Cg0K --_000_BYAPR04MB4983FF05A3240251C3124A72A39D9BYAPR04MB4983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29u dmVydGVkLXNwYWNlO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBw bGUtdGFiLXNwYW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgZW1l cmdlbmN5IGNhbGxzIGFuZCB0aGUgYWJpbGl0eSB0byBhZGQgYSBsb2NhdGlvbiBvbiB0aGUgZGV2 aWNlLCB3ZSBuZWVkIHRvIGtlZXAgaW4gbWluZCB0aGF0IGEgY3VzdG9tZXIgY291bGQgaGF2ZSBt dWx0aXBsZSBkZXZpY2VzLiZuYnNwOyBTb21laG93LCB3ZSBuZWVkIHRvIHRpZSB0aGUgcGh5c2lj YWwgYWRkcmVzcyB0byBlYWNoIGRldmljZS4mbmJzcDsgUGVyaGFwcyBieSBNQUMgYWRkcmVzcywg SeKAmW0gbm90IHN1cmUNCiBob3cgZWFjaCBvZiB0aGUgY3VycmVudCBWUlMgcHJvdmlkZXJzIGRv IHRoaXMuJm5ic3A7IEFsc28sIGl0IHdvdWxkIGJlIGdvb2QgdG8ga2VlcCB0aGUgYWJpbGl0eSB0 byB1cGRhdGUgdGhlIGFkZHJlc3MgZGlyZWN0bHkgb24gdGhlIGRldmljZSwgYXMgaXQgaXMgbm93 LiZuYnNwOyBJbiBmYWN0LCBzaW5jZSB3ZSBuZWVkIHRvIHBvc3NpYmx5IHJlZ2lzdGVyIGFkZHJl c3Mgb24gbXVsdGlwbGUgUlVFcyBmb3IgdGhlIHNhbWUgdXNlciwgZG9pbmcgc28gb24gdGhlDQog ZGV2aWNlIHNlZW1zIHRvIGJlIGEgbmF0dXJhbCBzb2x1dGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdWdlbmUuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6bmF2eSI+Q09ORklERU5U SUFMSVRZIE5PVElDRS48L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpuYXZ5Ij4gVGhpcyBl LW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3INCiBwcmV2aW91 cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRl ZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBkZWxpdmVyaW5nIGl0IHRv IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55 IGRpc2Nsb3N1cmUsIGNvcHlpbmcsDQogZGlzdHJpYnV0aW9uIG9yIHVzZSBvZiBhbnkgb2YgdGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiBvciBhdHRhY2hlZCB0byB0aGlzIG1lc3NhZ2UgaXMg U1RSSUNUTFkgUFJPSElCSVRFRC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Np b24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSBub3RpZnkgbWUgYnkgcmVwbHkgZS1tYWls IGF0DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5jb20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOm5hdnkiPiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTksDQog YW5kIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRz IHdpdGhvdXQgcmVhZGluZyB0aGVtIG9yIHNhdmluZyB0aGVtIHRvIGRpc2suPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OC4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEJy aWFuIFJvc2VuICZsdDtickBicmlhbnJvc2VuLm5ldCZndDsgPGJyPg0KPGI+U2VudDo8L2I+IEZy aWRheSwgRmVicnVhcnkgMjYsIDIwMjEgOTowNyBBTTxicj4NCjxiPlRvOjwvYj4gRXVnZW5lIENo cmlzdGVuc2VuICZsdDtlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gcnVtQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUnVtXSBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5bRVhURVJOQUxdPC9zcGFuPiZuYnNw O1RoYW5rcyBmb3IgdGhlc2UgY29tbWVudHMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XaXRoIHJlc3BlY3QgdG8gZW1lcmdlbmN5IGNhbGxzLCB5b3UgYXJl IGxpbWl0ZWQgYnkgRkNDIHJlZ3VsYXRpb25zIGluIHRoZSBVUywgSSBiZWxpZXZlLCBhbHRob3Vn aCB0aGVyZSBhcmUgM3JkIHBhcnR5IGVudGl0aWVzIHRoYXQgc3VwcGx5IGV4dHJhIGxvY2F0aW9u IGluZm9ybWF0aW9uIGZyb20gR29vZ2xlIGFuZCBBcHBsZSBhZnRlciB0aGUgY2FsbCBpcyByZWNl aXZlZCBhdCBhIFBTQVAuICZuYnNwO0kgdGhpbmsNCiB5b3UgaGF2ZSB0byB1c2UgYSBsb2NhdGlv biBjb2xsZWN0ZWQgKGFuZCB2ZXJpZmllZCkgYXMgcGFydCBvZiBhY2NvdW50IGVzdGFibGlzaG1l bnQuICZuYnNwO1R5cGljYWxseSB0aGVyZSBpcyBhIHdlYnNpdGUgdGhhdCB1cGRhdGVzIHRoaXMg YXMgbmVjZXNzYXJ5LiAmbmJzcDtJIGRvbuKAmXQgbGlrZSB0aGF0IGFzIHRoZSBhbnN3ZXIsIGJ1 dCBJIHRoaW5rIHdl4oCZcmUgc3R1Y2sgd2l0aCBpdC4gJm5ic3A7T3RoZXIgY291bnRyaWVzIG1h eSBoYXZlIG1vcmUgZmxleGliaWxpdHkuDQogJm5ic3A7VG8gYmUgc3VyZSwgdGhlIGRldmljZSBN QVkgYWRkIGEgbG9jYXRpb24gdmlhIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIuICZuYnNwO0l04oCZ cyBqdXN0IHRoYXQgdGhlIHByb3ZpZGVyIE1VU1QgYWRkIGEgbG9jYXRpb24uICZuYnNwOyBJIGNh biBtYWtlIHRoYXQgY2xlYXIgaW4gdGhlIHRleHQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSB0aGluZyBhYm91dCBXZWJSVEMgaXMgdGhh dCBpdCBkb2VzIHNwZWNpZnkgVC4xNDAsIGJ1dCB0cmFuc3BvcnQgaXMgaW4gdGhlIGRhdGEgY2hh bm5lbC4gJm5ic3A7VGhlIFJVRSBzcGVjIGlzIFQuMTQwIGluIFNEUC4gJm5ic3A7VGhlIHRyYW5z cG9ydCBhZGFwdGVyIHdvdWxkIGJlIHRoZSBSVUUgZGV2aWNlIGFuZCBub3QgdGhlIHByb3ZpZGVy LiBJIGNhbiB0cnkgdG8gaW1wcm92ZSB0aGUgd29yZGluZyB0aGVyZSB0byBtYWtlDQogaXQgbW9y ZSBjbGVhci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QnJpYW48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIEZlYiAyNSwgMjAyMSwgYXQgMzoyNSBQTSwgRXVnZW5lIENocmlzdGVuc2VuICZsdDs8YSBo cmVmPSJtYWlsdG86ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbSI+ZWNocmlzdGVuc2VuQHNvcmVu c29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgQnJpYW4uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPknigJl2ZSBiZWVuIHJldmlld2luZyBkcmFmdCA0IHNvbWUgbW9y ZSBhbmQgZGlzY3Vzc2luZyBpdCBpbnRlcm5hbGx5IGFuZCB3b25kZXIgYWJvdXQgdGhlIGZvbGxv d2luZzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHU+U2VjdGlvbiA1LjIuNSBFbWVyZ2VuY3kgQ2FsbHM8L3U+PC9iPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgdGhhdCBz aW5jZSB0aGUgUlVFIGNvdWxkIGJlIG9uIG1hbnkgZGlmZmVyZW50IGRldmljZSB0eXBlcywgaW5j bHVkaW5nIG5vbi1ub21hZGljIGRldmljZXMgc3VjaCBhcyBkZXNrdG9wcywgd2Ugc2hvdWxkIHJl cXVpcmUgdGhlIFJVRSB0byBwcm92aWRlIGEgd2F5IHRvIGZvciB0aGUgdXNlciB0byBpbnB1dCB0 aGVpciBhZGRyZXNzLiZuYnNwOyBXaXRob3V0IHN1Y2gsIGl0IHdpbGwgcmVxdWlyZSB0aGUgQ0EN CiB0byBhc2sgdGhlIGNhbGxlciBpbiBhbiBlbWVyZ2VuY3kgc2l0dWF0aW9uIGZvciB0aGVpciBs b2NhdGlvbi4mbmJzcDsgVGhlIGNhbGxlciBtYXkgYmUgaGF2aW5nIGlzc3VlcyBhdCB0aGUgdGlt ZSBvZiB0aGUgY2FsbCBhbmQgbWF5IGJlIGxpbWl0ZWQgaW4gdGhlaXIgYWJpbGl0eSB0byBwcm92 aWRlIHN1Y2ggaW5mb3JtYXRpb24gYXMgdGhlaXIgbG9jYXRpb24uJm5ic3A7IEZvciB0aGlzIHJl YXNvbiwgSSB0aGluayB0aGUgUlVFIHNob3VsZCBiZSByZXF1aXJlZA0KIHRvIGltcGxlbWVudCBV SSB0byBvYnRhaW4gdGhpcyBhaGVhZCBvZiB0aW1lIGFuZCBhbHNvIHRvIGJlIHVwZGF0ZWFibGUu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi Pjx1PlNlY3Rpb24gNi4yIFRleHQtQmFzZWQgQ29tbXVuaWNhdGlvbiBhbmQgV2ViUlRDPC91Pjwv Yj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdp dmVuIHRoYXQgV2ViUlRDIGRvZXMgbm90IHlldCBzdXBwb3J0IFQuMTQwIGFuZCBhIHRyYW5zY29k ZXIgd2lsbCBiZSByZXF1aXJlZCAoYXMgYWxyZWFkeSBub3RlZCBpbiBzZWN0aW9uIDYuMikuJm5i c3A7IElmIHRoZSBlbmRwb2ludCBpcyBhIFdlYlJUQyBzb2x1dGlvbiwgSSB3b25kZXIgaWYgdGhl IHRyYW5zY29kZXIgc2hvdWxkIGJlIHJlcXVpcmVkIG9mIHRoZSBkZXZlbG9wZXIgb2YgdGhlIFdl YlJUQyBzb2x1dGlvbg0KIGFuZCBub3QgdGhlIHByb3ZpZGVycy4mbmJzcDsgSSBiZWxpZXZlIGxh bmd1YWdlIGV4cHJlc3NpbmcgdGhpcyBzaG91bGQgYmUgYWRkZWQgdG8gdGhpcyBzZWN0aW9uIHVu dGlsIHN1Y2ggdGltZSB0aGF0IFdlYlJUQyBoYXMgYW4gYWNjZXB0YWJsZSBzb2x1dGlvbiBmb3Ig VC4xNDAuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpuYXZ5Ij5DT05GSURFTlRJQUxJVFkg Tk9USUNFLjwvc3Bhbj48L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOm5hdnkiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOm5hdnkiPlRoaXMNCiBlLW1haWwgdHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywg ZmlsZXMgb3IgcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVkIHRvIGl0LCBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJl IG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3Ig ZGVsaXZlcmluZyBpdCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UNCiBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8g dGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklURUQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1l IGJ5IHJlcGx5IGUtbWFpbCBhdDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmVjaHJpc3RlbnNlbkBzb3JlbnNvbi5j b20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZiI+ZWNocmlzdGVuc2VuQHNvcmVuc29uLmNvbTwvc3Bhbj48L2E+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4 LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnki PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOm5hdnkiPm9yDQogYnkgdGVs ZXBob25lIGF0ICsxICg4MDEpIDI4Ny05NDE5LCBhbmQgZGVzdHJveSB0aGUgb3JpZ2luYWwgdHJh bnNtaXNzaW9uIGFuZCBpdHMgYXR0YWNobWVudHMgd2l0aG91dCByZWFkaW5nIHRoZW0gb3Igc2F2 aW5nIHRoZW0gdG8gZGlzay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5SdW0gJmx0OzxhIGhyZWY9Im1haWx0bzpydW0tYm91bmNlc0BpZXRmLm9yZyI+ cnVtLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48Yj5PbiBCZWhhbGYgT2Y8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPkJyaWFuDQogUm9zZW48YnI+DQo8Yj5TZW50 OjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+RnJp ZGF5LCBGZWJydWFyeSA1LCAyMDIxIDM6MjcgUE08YnI+DQo8Yj5Ubzo8L2I+PHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpydW1A aWV0Zi5vcmciPnJ1bUBpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+W1J1bV0gRndkOiBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6cmVkIj5bRVhURVJOQUxdPC9zcGFuPiZuYnNwO0kgaGF2ZSBwb3N0ZWQgYSAtMDQgcmV2 aXNpb24uICZuYnNwO1RoaXMgc2hvdWxkIGhhbmRsZSBhbGwgY29tbWVudHMgcmVjZWl2ZWQgc28g ZmFyLCBwbGVhc2UgbGV0IG1lIGtub3cgaWYgSSBmb3Jnb3Qgc29tZXRoaW5nLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhpcyB2ZXJzaW9uIHJld29ya3MgdGhlIHByb3ZpZGVyIGxpc3QgYW5kIGNvbmZp Z3VyYXRpb24gc2VjdGlvbnMgYWxvbmcgdGhlIGxpbmVzIHdlIGhhdmUgYmVlbiBkaXNjdXNzaW5n LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvIG5vdCBoYXZlIGEgd2F5IHRvIGRvd25s b2FkIGEgdXNlcm5hbWUvcGFzc3dvcmQgZnJvbSBhIG5ldyBzaWdudXAuICZuYnNwO0nigJltIGhh dmluZyB0cm91YmxlIHRoaW5raW5nIGFib3V0IGEgc2VjdXJlIHdheSB0byBkbyB0aGF0LiAmbmJz cDtJZiBhbnlvbmUgaGFzIGFuIGlkZWEsIEnigJltIHZlcnkgd2lsbGluZyB0byB3cml0ZSB0ZXh0 IGZvciBpdC4gJm5ic3A7SeKAmXZlIGNvbnNpZGVyZWQgdGhpbmdzIGxpa2UgamF2YXNjcmlwdCB0 aGF0DQogc3Rhc2hlcyBpdCBpbiBhIGZpbGUgb3Igc29tZXdoZXJlIGVsc2UsIGhhdmluZyBzb21l IHdlYiBwYWdlIGZ1bmN0aW9uIHRoYXQgdHJpZ2dlcnMgYSBsb2NhbCBkaXNwbGF5IG9mIGFuIGVu dHJ5IGZvcm0gZm9yIHVzZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5kIGEgY291cGxlIG9mIG90aGVy IHRoaW5ncy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T25lIG5vdGUgb24gdGhlIGNvbmZp Z3VyYXRpb24gbWVjaGFuaXNtIC0gYmVjYXVzZSB0aGUgb25seSB0aGluZyB0aGUgbG9jYWwgUlVF IGRldmljZSBuZWVkcyB0byBrZWVwIGlzIHRoZSB1c2VybmFtZSBwYXNzd29yZCBhZ2FpbnN0IGEg cHJvdmlkZXIgSUQgb2Ygc29tZSBraW5kLCB0aGVyZSBpc27igJl0IGFueSBuZWVkIHRvIHN0YW5k YXJkaXplIGhvdyB0aGF0IHdvcmtzLCBhbmQgc28gaXTigJlzIGNvbXBsZXRlbHkNCiBhYnNlbnQg aW4gdGhlIHRleHQuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igbm93LCBJ 4oCZdmUgcmVtb3ZlZCB0aGUgc3RlcCBieSBzdGVwIGRpYWdyYW0gdGhhdCBzaG93ZWQgaG93IHRo ZSBjb25maWcgbWVjaGFuaXNtIGlzIHVzZWQuICZuYnNwO0kgdGhpbmsgd2hhdCBpcyB0aGVyZSBp cyBkZWFkIHNpbXBsZSBhbmQgbmVlZHMgbm8gZXhwbGFuYXRpb246IGl04oCZcyBhIHN0cmFpZ2h0 Zm9yd2FyZCBSRVNUL0pTT04gd2ViIHNlcnZpY2UgdXNpbmcgdXNlcm5hbWUvcGFzc3dvcmQgYXV0 aGVudGljYXRpb24NCiBmb3IgcHJvdmlkZXJzIHRoZSB1c2VyIGhhcyBhY2NvdW50cyB3aXRoLiAm bmJzcDtJIGNhbiBicmluZyBiYWNrIHRoZSBkaWFncmFtIGlmIHRoYXQgaXMgbmVlZGVkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJy Pg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5CZWdpbiBmb3J3YXJkZWQgbWVzc2FnZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Gcm9tOjxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PC9i PjxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+aW50ZXJuZXQtZHJhZnRzQGll dGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+U3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1ydW0tcnVlLTA0LnR4dDwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPkRhdGU6PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5GZWJydWFyeSA1LCAyMDIx IGF0IDU6MTc6MTUgUE0gRVNUPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5Ubzo8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPiZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOmktZC1hbm5vdW5jZUBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5pLWQtYW5ub3VuY2VAaWV0Zi5vcmc8L3NwYW4+PC9h PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+Jmd0 Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90OyI+Q2M6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L2I+PGEgaHJlZj0ibWFpbHRvOnJ1bUBpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5ydW1AaWV0 Zi5vcmc8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5SZXBseS1Ubzo8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48YSBocmVmPSJtYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDsiPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij4sPHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVm PSJtYWlsdG86cnVtQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhIE5ldWUmcXVvdDsiPnJ1bUBpZXRmLm9yZzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24t bGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0KVGhpcyBkcmFmdCBpcyBhIHdv cmsgaXRlbSBvZiB0aGUgUmVsYXkgVXNlciBNYWNoaW5lIFdHIG9mIHRoZSBJRVRGLjxicj4NCjxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlICZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzog SW50ZXJvcGVyYWJpbGl0eSBQcm9maWxlIGZvciBSZWxheSBVc2VyIEVxdWlwbWVudDxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvciAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IEJyaWFuIFJvc2Vu PGJyPg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5i c3A7PC9zcGFuPkZpbGVuYW1lICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOzogZHJhZnQtaWV0Zi1ydW0tcnVlLTA0LnR4dDxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10 YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5QYWdlcyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IDMzPGJy Pg0KPHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDs8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPkRhdGUgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiAyMDIxLTAyLTA1PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJy Pg0KJm5ic3A7Jm5ic3A7VmlkZW8gUmVsYXkgU2VydmljZSAoVlJTKSBpcyBhIHRlcm0gdXNlZCB0 byBkZXNjcmliZSBhIG1ldGhvZCBieTxicj4NCiZuYnNwOyZuYnNwO3doaWNoIGEgaGVhcmluZyBw ZXJzb25zIGNhbiBjb21tdW5pY2F0ZSB3aXRoIGRlYWYvSGFyZCBvZiBIZWFyaW5nPGJyPg0KJm5i c3A7Jm5ic3A7dXNlciB1c2luZyBhbiBpbnRlcnByZXRlciAoJnF1b3Q7Q29tbXVuaWNhdGlvbnMg QXNzaXN0YW50JnF1b3Q7KSBjb25uZWN0ZWQgdmlhPGJyPg0KJm5ic3A7Jm5ic3A7YSB2aWRlb3Bo b25lIHRvIHRoZSBkZWFmL0hvSCB1c2VyIGFuZCBhbiBhdWRpbyB0ZWxlcGhvbmUgY2FsbCB0byB0 aGU8YnI+DQombmJzcDsmbmJzcDtoZWFyaW5nIHVzZXIuICZuYnNwO1RoZSBDQSBpbnRlcnByZXRz IHVzaW5nIHNpZ24gbGFuZ3VhZ2Ugb24gdGhlPGJyPg0KJm5ic3A7Jm5ic3A7dmlkZW9waG9uZSBs aW5rIGFuZCB2b2ljZSBvbiB0aGUgdGVsZXBob25lIGxpbmsuICZuYnNwO09mdGVuIHRoZTxicj4N CiZuYnNwOyZuYnNwO2ludGVycHJldGVycyBtYXkgYmUgc3VwcGxpZWQgYnkgYSBjb21wYW55IG9y IGFnZW5jeSB0ZXJtZWQgYTxicj4NCiZuYnNwOyZuYnNwOyZxdW90O3Byb3ZpZGVyJnF1b3Q7IGlu IHRoaXMgZG9jdW1lbnQuICZuYnNwO1RoZSBwcm92aWRlciBhbHNvIHByb3ZpZGVzIGEgdmlkZW88 YnI+DQombmJzcDsmbmJzcDtzZXJ2aWNlIHRoYXQgYWxsb3dzIHVzZXJzIHRvIGNvbm5lY3Qgdmlk ZW8gZGV2aWNlcyB0byB0aGVpciBzZXJ2aWNlLDxicj4NCiZuYnNwOyZuYnNwO2FuZCBzdWJzZXF1 ZW50bHkgdG8gQ0FzIGFuZCBvdGhlciBkZWFmL0hvSCB1c2Vycy4gJm5ic3A7SXQgaXMgZGVzaXJh YmxlPGJyPg0KJm5ic3A7Jm5ic3A7dGhhdCB0aGUgdmlkZW9waG9uZXMgdXNlZCBieSB0aGUgZGVh Zi9Ib0gvSC1JIHVzZXIgY29uZm9ybSB0byBhPGJyPg0KJm5ic3A7Jm5ic3A7c3RhbmRhcmQgc28g dGhhdCBhbnkgZGV2aWNlIG1heSBiZSB1c2VkIHdpdGggYW55IHByb3ZpZGVyIGFuZCB0aGF0PGJy Pg0KJm5ic3A7Jm5ic3A7dmlkZW8gY2FsbHMgZGlyZWN0IGJldHdlZW4gZGVhZi9Ib0ggdXNlcnMg d29yay4gJm5ic3A7VGhpcyBkb2N1bWVudDxicj4NCiZuYnNwOyZuYnNwO2Rlc2NyaWJlcyB0aGUg aW50ZXJmYWNlIGJldHdlZW4gYSB2aWRlb3Bob25lIGFuZCBhIHByb3ZpZGVyLjxicj4NCjxicj4N Cjxicj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll dGYtcnVtLXJ1ZS8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt cnVtLXJ1ZS88L2E+PGJyPg0KPGJyPg0KVGhlcmUgaXMgYWxzbyBhbiBIVE1MIHZlcnNpb24gYXZh aWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQv ZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0bWwiPmh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUv aWQvZHJhZnQtaWV0Zi1ydW0tcnVlLTA0Lmh0bWw8L2E+PGJyPg0KPGJyPg0KQSBkaWZmIGZyb20g dGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUtMDQiPmh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJ1bS1ydWUtMDQ8L2E+PGJy Pg0KPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbjxicj4NCnVudGlsIHRoZSBodG1saXpl ZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0K PGJyPg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ IGF0Ojxicj4NCjxhIGhyZWY9ImZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvIj5m dHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1B bm5vdW5jZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGll dGYub3JnIj5JLUQtQW5ub3VuY2VAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlPC9hPjxicj4NCkludGVybmV0LURy YWZ0IGRpcmVjdG9yaWVzOiA8YSBocmVmPSJodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Ij5odHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sPC9hPjxicj4NCm9yIDxhIGhyZWY9ImZ0 cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0Ij5mdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR04MB4983FF05A3240251C3124A72A39D9BYAPR04MB4983namp_-- From nobody Fri Feb 26 12:58: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 CCB7A3A08F9 for ; Fri, 26 Feb 2021 12:58:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_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 ptR7XCQ-Ukkz for ; Fri, 26 Feb 2021 12:58:41 -0800 (PST) Received: from NAM10-MW2-obe.outbound.protection.outlook.com (mail-mw2nam10on2084.outbound.protection.outlook.com [40.107.94.84]) (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 859283A08F4 for ; Fri, 26 Feb 2021 12:58:41 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VKRCCKc06B4iSgTmDiZuIfSfn/yhFs3bZcz8eD2g8hOJhhr7EY1zmyDEdapIqV7cYS46juP89tKhDnlDAPh0XD/EqVyh+ClO5uqg08dy5UQA1+d57xRERBnOtjzMFfSaPUvUMfvyLwg0je8t2WBIT86jL2Ss1d1BuOrJsTuGsB536PHwWaOnpXIMc2rErDMCDRbGKDaf8ZegiOslFIPtBwS3vYFZ9BQPscS/kRolGPekMS+GQmn3BxyjWZyx//8T+RrvbhASBi9Ch+pDM3AxOzvFnXrLENR2NIpViN1yzAWoRKzdXDqR3JWr0Ld5/xWffQJW80qhfduycmXFmToKPw== 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=gvPzRk5bgpuG7TqiiTlRRI7eXQ1Ct6wtLEMg4X+dYiU=; b=MAUlQ8jSe2IgS25ry33yrVtUyn00j7zUhSRN17VZelxTLmAkAB7Ln6nKHcdEUsZ8z2Zv7G3kTOM6uA8t85QvpazxyAZahtS0/fg2v2hfwZ4qTaWFTxCKwM04dcSi1ihkmFlQMizrbNxiVFpU5VkMcavabRK9lnIx+7rVxtsTsWQ8bSntql1zTDhIyqBvb+3MtYYCM+47rTjrUaYg7yb085Lwe33e6pLIym9Hz3B4FEmLY+0k41YvgFisHEUrNffrUJsUj/UKKnXUD8lWqld+YHiGOAwhz/Asg4XZaQvOOaDAfyIfAa2BYZ/PyPVtMfZ+6wGMPkvhoTTPy4ltwWymTw== 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=gvPzRk5bgpuG7TqiiTlRRI7eXQ1Ct6wtLEMg4X+dYiU=; b=nBfIL/3R8wm2IXSYJ73nEL9w2qiAYKoxQp5giLBSwe8CHvv19Sqj8B9NQhqzLJCUoa0fq+hGrSjev+YmwQPEB2oZ+iAw1aJaesqpIEEjNek+gbVUcRKDXEUL72pLRRj9bH8nuwu8s9qHvRVg0U7YliqVjZX+w6x9RfckNLmrsqo= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BYAPR04MB4136.namprd04.prod.outlook.com (2603:10b6:a02:f3::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3890.19; Fri, 26 Feb 2021 20:58:40 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::a9b9:95ca:f09e:681%6]) with mapi id 15.20.3868.033; Fri, 26 Feb 2021 20:58:40 +0000 From: Eugene Christensen To: "Olle E. Johansson" , Paul Kyzivat CC: "rum@ietf.org" Thread-Topic: [Rum] I-D Action: draft-ietf-rum-rue-04.txt Thread-Index: AQHXDAvTwQ/2jjmz80a2NUoPFj634apqrB6AgAAMcYCAADNNAA== Date: Fri, 26 Feb 2021 20:58:40 +0000 Message-ID: References: <161256343562.29866.6213353287492521738@ietfa.amsl.com> <35F20BB4-4EEF-4749-9AAB-F2E89B11F814@brianrosen.net> <1e064a43-b3c5-7ffb-2965-448eae62ff20@alum.mit.edu> <997CF563-D2D8-4B95-8498-4A03059F7AAB@edvina.net> In-Reply-To: <997CF563-D2D8-4B95-8498-4A03059F7AAB@edvina.net> Accept-Language: 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=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 54a5dfe0-2004-4e05-3ebb-08d8da994b84 x-ms-traffictypediagnostic: BYAPR04MB4136: x-ms-exchange-minimumurldomainage: ietf.org#9484 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IXGvfvk/ktMsIb6iYJnmPa8zZuT1V5vT02+vor7kanXG+r2gTWlO8XT77RvcF5oYGgm6NH6QAqOozixQF9sr0lnLwLAvJFj56cvlZ7h1n5TpkQhOoTrUzaXw7JLtRPKq+0cRUENyiwDLmFwVMDuJG4gpnwbk3eOAXzV+8PBhSrO+BH09pKmxsmDfy6W4mtRkHixmk4Z+jtWbBvCfVOWR+iTQ/VbzZhVUIimZiW0MBaWiHdYKKnYBoT9lkfHWPp4+ne5RbMAz4QHuSiwPctPg2tGBEE8eJdvYiKzor7P4esvuhCf/RXdHtrTwKDmFQAXnX332EJPbUY70GiO/OPmk3VEhD4oj96+Ys/xmu/cWx7U9J9i9lJwuOA3cn3/R+gxHDo9BIs+/tJ7+Z5un9yzD8Y7wtMjM5f5jEk6MvsF3Fjm/wtRM02anjzLsWcW9w48GuZM0k1hKkS6LiML4NgoHqEd4RQw7niMV02MKLZnUrmKg7SCMGhBfUnj0v+I5ZSKK7kJFzDg6GmFlSrtSdOgg2eCH6Y3piMUFqfvoN5S7Q6f+KURmzofqEwalQSE3hRqrgVOZO9+9Y6FYG5yi82p8roCLv29OszQGwTmmLgBoQDU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR04MB4983.namprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(366004)(376002)(136003)(39850400004)(346002)(9686003)(2906002)(33656002)(4326008)(55016002)(83380400001)(53546011)(8936002)(478600001)(5660300002)(66446008)(316002)(66476007)(8676002)(7696005)(966005)(66556008)(110136005)(26005)(86362001)(186003)(64756008)(66946007)(71200400001)(6506007)(52536014)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?ZnE5SVdkZ2I2Q3YzbEtMcHJTZlJGdzAyV0puOExncENWZHhhcFY4cnBGbUJi?= =?utf-8?B?V2hubFVOMUwyeVdpbU9kTTFnZzN0NHF3U3lTVTdoT2xtTExIMFR1eFdoWmtv?= =?utf-8?B?WVdpYTlzaHZKWk9kelJyRldRcGJNSmxHNmNqMkx3QSszREMxTDVoKzVnZERu?= =?utf-8?B?bG41TzBPV0FqTEpPa2dwd1ZmZEhZVmExYThlUE9uTk96RGhsZWQ1TlUyYlM2?= =?utf-8?B?dkNHNmliWVJWNkZ0Q3FPcEZ0V0ZFS3c2blVqVkNSaG9DbTUyelFxR3cwVnQz?= =?utf-8?B?RUtMREVvTEwrL1RvYkxZKzBpOXVwd1NSa0tqcFNiWDQya3VjSVhUMXVOdisr?= =?utf-8?B?SlZKdHduSVEyK3J6SXdhSEtWVzVvcHREK2QvWGJKRDV5S0RCODFoOWxibUk3?= =?utf-8?B?UHZtME9DY1ROVW80U3Y3NVRqS245clJ1NlNSNjdhZEdxL0xYQnM4N0owaklk?= =?utf-8?B?TE5INVJ2UDhsVkZLVWVVNVdiRWJwTkxCa3J6a1pkWDFDQ2czYWtueE51QXgx?= =?utf-8?B?S0t6YXpVKzlpNmNYcUJnQ1c0T2NZc0dkcm80dzRDbThCUng3ZXBNSUswUHpF?= =?utf-8?B?VzM3NzFNVkI0RnRvVmU2RGJkYWxzQWZrNkgwK0x3cUFjRFBXaUNzb0I4QjBz?= =?utf-8?B?R3BRSlBQT1ZGTHRzV2phbWpiMTE3ODFWaHh1SWNRMElmWUV2V3JJdWFYanBI?= =?utf-8?B?bFNVM21qRzcrR0RBTlJaZzVqR1MveDhDNDJJS1U0bnZKdEoycjBmWWhVU3Ar?= =?utf-8?B?Zzk2ZjNLdDcxa0liMDFLVnVENFYyaGU3aFNQTlRIclZSUWtBYmlsTnQ1TmdM?= =?utf-8?B?ZzJid0VLN24zRXN2emdhZlZZUlNRVVBnajVMK3ZKWFMvSVlXbm11V09sRlp4?= =?utf-8?B?RXpMSGRKMkJzLzJNZjR6cTd6VEsvK2VWOE9NaXRNMVpiVENyQWxoR3NCQ3g1?= =?utf-8?B?amN0RGFDZ0FpVVZqT21vT1lHUmxIRStEYlNUUG5ERVdMM3loSXowVUFMZHdM?= =?utf-8?B?NHdwYWp6WkdKWGRUMHBjNDVBM0Q0cFhwZ0FpZnVmcHBOenZ6ODlGb3dZUUl3?= =?utf-8?B?TEtNSk01RndPL1dtS214TXYrbVJMekJMSkJOdWE3RFVyWnkzZWI0VjVodzAx?= =?utf-8?B?b1d5QW9yYXRsbVRBVVQxU3hxcUc2cWkrRll1K2hpVjRtOXdlWjc2NkFkSllP?= =?utf-8?B?RTc3R1Ixc2ExVTFkQUptdUcwaGkxckNDN3o4b3daS1YwdWw5TVJydytRQW4z?= =?utf-8?B?UjJab0haa2IzYmJGdld3MnVzN0hJWHBiV0dkS2llVE5MR2RRRHRwZ3lmdVhy?= =?utf-8?B?ZXpsTGlJQXEwZytINFUyKzlxUktOV3UxS016Z2xKUFRsRkxCbHVobkI3bys3?= =?utf-8?B?cTVVTDVjU3FreGY5Q2dIR1EreEEzZDBuWUtPY284WVVYMkQxdHAyVHJ3R2lZ?= =?utf-8?B?SCthbytHeVZSOGhMbkt0ak9JYWtMc0NSZkRGQ2xQUlFtOFl4Tkk2RjVwdTE0?= =?utf-8?B?MDA5YXFwK1lkS1VPREJQUlJ5Sms0MXVlNFpBUlpDaXJEVFdKWHZDVEM0dVlx?= =?utf-8?B?c0M3T3RUdDRLanNhRXUyaWNtTXhVUlYxM0xzS1ZHcDBocVREcjBmN0I5YzFr?= =?utf-8?B?QjlwZGY5N3c3Q2VxRTZYdjkxd1ppdTlJMFhHVlhVL1FxRklEckw0VnpLeUc1?= =?utf-8?B?ckhOd2E3d0w2cFhlYldoUW5KYXNOb3d5dUdITm1zaml4UytQa05Ed0tsN3BW?= =?utf-8?Q?M9x/0mLnchndqjbQvXa91mcteEToFAh6K6LIkN7?= 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: BYAPR04MB4983.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 54a5dfe0-2004-4e05-3ebb-08d8da994b84 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2021 20:58:40.3875 (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: aXhLQNVGukR9wAFfMX43E0ozrzgt8uk5VBmb4Uwa8vbZ6fN1QQLO7I5XLWXMfbKJmTLKOlCTRHPkTNdSWh9Qi4xrkYyvRKqB/FqOi7DJNlM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR04MB4136 Archived-At: Subject: Re: [Rum] I-D Action: draft-ietf-rum-rue-04.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: Fri, 26 Feb 2021 20:58:44 -0000 SSBtYXkgaGF2ZSBtaXMtc3Bva2UgYWJvdXQgV2ViUlRDIGFuZCBzdXBwb3J0IGZvciBULjE0MCBi dXQgSSBiZWxpZXZlIGV2ZXJ5b25lIGhhcyB1bmRlcnN0b29kIHRoZSBjaGFsbGVuZ2UuICBBcyBs b25nIGFzIGl0IGlzIGNsZWFyIHRoYXQgdGhlIFJVRSBkZXZpY2UgaXMgcmVzcG9uc2libGUgZm9y IHRyYW5zY29kaW5nLCBub3QgdGhlIHByb3ZpZGVyIHRoYXQgd291bGQgYmUgc2F0aXNmYWN0b3J5 Lg0KDQpUaGFuayB5b3UuDQoNCg0KQ09ORklERU5USUFMSVRZIE5PVElDRS4gVGhpcyBlLW1haWwg dHJhbnNtaXNzaW9uLCBhbmQgYW55IGRvY3VtZW50cywgZmlsZXMgb3IgcHJldmlvdXMgZS1tYWls IG1lc3NhZ2VzIGF0dGFjaGVkIHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHBy b3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBvciBhIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUgaW50 ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9z dXJlLCBjb3B5aW5nLCBkaXN0cmlidXRpb24gb3IgdXNlIG9mIGFueSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGluIG9yIGF0dGFjaGVkIHRvIHRoaXMgbWVzc2FnZSBpcyBTVFJJQ1RMWSBQ Uk9ISUJJVEVELiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlIGltbWVkaWF0ZWx5IG5vdGlmeSBtZSBieSByZXBseSBlLW1haWwgYXQgZWNocmlz dGVuc2VuQHNvcmVuc29uLmNvbSBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0MTks IGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50 cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KDQotLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZz4gT24g QmVoYWxmIE9mIE9sbGUgRS4gSm9oYW5zc29uDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDI2LCAy MDIxIDEwOjU0IEFNDQpUbzogUGF1bCBLeXppdmF0IDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+DQpD YzogcnVtQGlldGYub3JnOyBPbGxlIEUgSm9oYW5zc29uIDxvZWpAZWR2aW5hLm5ldD4NClN1Ympl Y3Q6IFJlOiBbUnVtXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJ1bS1ydWUtMDQudHh0DQoNCltF WFRFUk5BTF0gDQoNCg0KPiBPbiAyNiBGZWIgMjAyMSwgYXQgMTg6MDksIFBhdWwgS3l6aXZhdCA8 cGt5eml2YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4gDQo+IE9uIDIvMjYvMjEgMTo1MSBBTSwg T2xsZSBFLiBKb2hhbnNzb24gd3JvdGU6DQo+IA0KPj4gV2hlbiB0YWxraW5nIGFib3V0IFdlYlJU QyB0aGVyZSBpcyBhbHdheXMgY29uZnVzaW9uLiBUaGVyZeKAmXMgYSBsaWJyYXJ5IGNhbGxlZCBX ZWJSVEMgYW5kIGEgc2V0IG9mIHN0YW5kYXJkcy4NCj4+IFdoZXJlIGluIHRoZSBzZXQgb2Ygc3Rh bmRhcmRzIGRvZXMgaXQgZm9yYmlkIFQuMTQwPyBJIGRvbuKAmXQgdGhpbmsgDQo+PiB0aGF0IHRo ZSBhc3N1bXB0aW9uIHRoYXQgSUVURi9XM0MgV2ViUlRDIGRvZXNu4oCZdCBzdXBwb3J0IFQuMTQw IGlzIGNvcnJlY3QuDQo+PiBUaGF0IGJyb3dzZXJzIGhhc27igJl0IGltcGxlbWVudGVkIHN1cHBv cnQgaXMgYW5vdGhlciBpc3N1ZS4NCj4gDQo+IFRoYXQgYnJvd3NlcnMgaGF2ZW4ndCBpbXBsZW1l bnRlZCBpdCBpcyAqdGhlKiBpc3N1ZS4NCj4gDQo+IFNpbmNlIHdlYnJ0YyBoYXMgZGVmaW5lZCBU LjE0MCBvdmVyIGRhdGEgY2hhbm5lbCBpdCBpcyBoYXJkIGZvciBtZSB0byBpbWFnaW5lIHdoYXQg d291bGQgdGhlbSB0byBzdXBwb3J0IGl0IGRpcmVjdGx5IG92ZXIgUlRQLiBUaGVyZSBpcyBubyB3 YXkgdG8gZ2V0IHRoZXJlIGZyb20gaGVyZS4NCj4gDQpJIGNhbiBhY2NlcHQgdGhhdCwgYnV0IHdl IGNhbuKAmXQgd3JpdGUgdGhhdCDigJxXZWJSVEMgZG9lcyBub3Qgc3VwcG9ydCBULjE0MOKAnS4g SWYgeW91IHdyaXRlIHlvdXIgb3duIGltcGxlbWVudGF0aW9uIG5vdGhpbmcgc3RvcHMgeW91IGZy b20gaW1wbGVtZW50aW5nIFQuMTQwIGluIFJUUCBvciBvdmVyIGRhdGEgY2hhbm5lbC4NCg0KL08g Oi0pDQoNCi0tDQpSdW0gbWFpbGluZyBsaXN0DQpSdW1AaWV0Zi5vcmcNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vcnVtDQo=