From nobody Thu Dec 3 09:25:35 2020 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 ECE463A09A8 for ; Thu, 3 Dec 2020 09:25:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEnRAoE6vc45 for ; Thu, 3 Dec 2020 09:25:31 -0800 (PST) Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com [IPv6:2607:f8b0:4864:20::f2d]) (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 23A9E3A0983 for ; Thu, 3 Dec 2020 09:25:31 -0800 (PST) Received: by mail-qv1-xf2d.google.com with SMTP id k3so1327201qvz.4 for ; Thu, 03 Dec 2020 09:25:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=KWeFHdJhZSRbMTbY7hAN8GkxnHJ4A9V9SMJVsmfdqtU=; b=Ru6ofOi/g7/T6azwgHFJN2/Hbpy3CMgFdJnzlkviHW3JnGpG6kWMjUsHo7d4Gwnur8 f9r/WXzc6YRHMnSt/0qkf8aL7RBAFgj4nzNuv36Ujaq/wb2UKX5tEdo0wF7LtvvESbGb aOhH8CBLP9j5UxfS5exbmnDyagzrsDUUTNsGwdA8CQoL05GhKU79juniyzHLcz0U/PHR C4Gqg5YVM275phHtnLqLr6Bwwt3lDbuNGo/B0xLWYtwt7pmxi7Enh2wFVKXoc43Xromm A/W/0X9tVKsizRTO64MRUxY5CGNNi/OZXPME3M9hvDJbZ8tNnAEbU17vqv0kAGLpnkMg Xyvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=KWeFHdJhZSRbMTbY7hAN8GkxnHJ4A9V9SMJVsmfdqtU=; b=EVYi6RIzQm8snD1ynpTDQ1SaouWkOQs793bO9g/i1tfjyZwmDutxtYzdgrbVTQR0U8 2p4KVsAFZoCPPgVR6AJzljiTivuqmegz4mvqGtQgweT3ww1rDHhLQjyaANlc9ZZAYJ24 I+NfeQVEL7SeLl7c23ze6DAc4Q1Sb0BRly9q2KuK7P8hiE5qwNa7g5wIFq0fHn0dDru5 beIHXwGQaL9MJjTFOi0vt9rUJfdv2jahxNZE3V21sDrv5hY9iek9CIoyh18dHg2jUqgm u2c6+arqQHss8jjmnqKp/Ings/kWe52ZGsx57t/qHIhJ69wavHexVacsVc52xw2KmkRn A08g== X-Gm-Message-State: AOAM53365XVQdiEPbCS5J89uWArsSvh5roemTcUNdUzrb4nobiGHhiaP Bni0gR6W/tlMon4fBpbM+ZOLwrLWFvLxx7ii X-Google-Smtp-Source: ABdhPJzdT1fJZxUvW7TuxSRQoFO7V0xdZ/D+lhuB4FucChyW+ZqCUEZuW/35uFDR2hYHPtXDrmv/EQ== X-Received: by 2002:a0c:85a3:: with SMTP id o32mr14383qva.52.1607016329951; Thu, 03 Dec 2020 09:25:29 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id z81sm1766778qkb.116.2020.12.03.09.25.28 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Dec 2020 09:25:28 -0800 (PST) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Thu, 3 Dec 2020 12:25:27 -0500 To: rum@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Rum] Proposed Solution for Configuration 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, 03 Dec 2020 17:25:33 -0000 Olle will have an alternative proposal, here is mine. I start with the provider list. There is a list of providers per = country. There is an IANA registry that has a country code and a URL to = get that list. The list has an entry per provider. The entry has sets of data objects, = one set per language supported. Each set is an object with Iname for = the provider, a URL for its configuration service, a URL for its = customer sign up service, a URL for a help desk, and a SIP URI for a = dial around front door. =20 A user starts with the sign up service, which uses a browser. The = result is a username/password for the account. =20 The RUE has an administrative account, which it maintains locally. = There is a username and password for that. The RUE stores the URLs for = a provider configuration service, username and password locally. Only a = user with the administrative username/password can see or change the = data. When the RUE restarts for any reason, or following a change in = username/password, it connects to the configuration service via HTTPS, = authenticates with username/password and provides the API Key. If the = API Key is good, the configuration service responds with all of the = server information (Registrar, outbound proxy, TURN server, =E2=80=A6) = for that user. The RUE then configures for that provider, REGISTERs with the stored = username and password, and is then ready to place or receive calls. I=E2=80=99m thinking about some cleverness where if the RUE provides the = browser that is used to sign up, perhaps there is a secure way for the = provider to download username/password so it can be locally stored as = above, so the user doesn=E2=80=99t have to enter it into the RUE. Brian From nobody Fri Dec 4 06:58:12 2020 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 C75A33A0D04 for ; Fri, 4 Dec 2020 06:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-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 7NHl9NHqEhYk for ; Fri, 4 Dec 2020 06:58:08 -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 CCEE03A0C8B for ; Fri, 4 Dec 2020 06:58:07 -0800 (PST) Received: from smtp.purple.us (smtp02.purple.us.91.17.208.in-addr.arpa [208.17.91.144]) by mx2.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 04 Dec 2020 14:58:04 +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; Fri, 4 Dec 2020 06:58:03 -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; Fri, 4 Dec 2020 06:58:02 -0800 From: James Hamlin To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] Proposed Solution for Configuration Thread-Index: AQHWyky5ctqwSp3zHUeJNn0SY484xg== Date: Fri, 4 Dec 2020 14:58:02 +0000 Message-ID: <1607093882955.49029@purple.us> 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_160709388295549029purpleus_" MIME-Version: 1.0 X-BESS-ID: 1607093883-893003-13733-81936-1 X-BESS-VER: 2019.1_20201203.2046 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.228613 [from cloudscan15-167.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] Proposed Solution for Configuration 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, 04 Dec 2020 14:58:10 -0000 --_000_160709388295549029purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian Just one small point: it would be good to keep the amount of data in any ce= ntrally managed list to a minimum. A list of Provider names and domains nam= es, would be enough for the RUM RUE to display a list of providers to the u= ser and to go to the provider's domains to get further information. Central= ly managed data will always cause an administrative headache. 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: Brian Rosen Message-Id: Date: Thu, 3 Dec 2020 12:25:27 -0500 To: rum@ietf.org Subject: [Rum] Proposed Solution for Configuration List-Id: Relay User Machine List-Post: Sender: "Rum" Olle will have an alternative proposal, here is mine. I start with the provider list. There is a list of providers per country. = There is an IANA registry that has a country code and a URL to get that li= st. The list has an entry per provider. The entry has sets of data objects, on= e set per language supported. Each set is an object with Iname for the pro= vider, a URL for its configuration service, a URL for its customer sign up = service, a URL for a help desk, and a SIP URI for a dial around front door. A user starts with the sign up service, which uses a browser. The result i= s a username/password for the account. The RUE has an administrative account, which it maintains locally. There i= s a username and password for that. The RUE stores the URLs for a provider= configuration service, username and password locally. Only a user with th= e administrative username/password can see or change the data. When the RUE restarts for any reason, or following a change in username/pas= sword, it connects to the configuration service via HTTPS, authenticates wi= th username/password and provides the API Key. If the API Key is good, the= configuration service responds with all of the server information (Registr= ar, outbound proxy, TURN server, ...) for that user. The RUE then configures for that provider, REGISTERs with the stored userna= me and password, and is then ready to place or receive calls. I'm thinking about some cleverness where if the RUE provides the browser th= at is used to sign up, perhaps there is a secure way for the provider to do= wnload username/password so it can be locally stored as above, so the user = doesn't have to enter it into the RUE. Brian --_000_160709388295549029purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian


Just one small point: it would be good to keep the amount of data in any= centrally managed list to a minimum. A list of Provider names and domains = names, would be enough for the RUM RUE to display a list of providers to th= e user and to go to the provider's domains to get further information. Centrally managed data will always cau= se an administrative headache.


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: Brian Rosen <br@brianrosen.net>=0A=
Message-Id: <D434111F-8C8F-40AC-BAC7-DFA8616F4FA8@brianrosen.net>=0A=
Date: Thu, 3 Dec 2020 12:25:27 -0500=0A=
To: rum@ietf.org=0A=
Subject: [Rum] Proposed Solution for Configuration=0A=
List-Id: Relay User Machine <rum.ietf.org>=0A=
List-Post: <mailto:rum@ietf.org>=0A=
Sender: "Rum" <rum-bounces@ietf.org>

Olle will have =
an alternative proposal, here is mine.

I start with the provider lis=
t.  There is a list of providers per country.  There is an IANA registry th=
at has a country code and a URL to get that list.

The list has an en=
try per provider.  The entry has sets of data objects, one set per language=
 supported.  Each set is an object with Iname for the provider, a URL for i=
ts configuration service, a URL for its customer sign up service, a URL for=
 a help desk, and a SIP URI for a dial around front door.  

A user s=
tarts with the sign up service, which uses a browser.  The result is a user=
name/password for the account.  

The RUE has an administrative accou=
nt, which it maintains locally.  There is a username and password for that.=
  The RUE stores the URLs for a provider configuration service, username an=
d password locally.  Only a user with the administrative username/password =
can see or change the data.

When the RUE restarts for any reason, or=
 following a change in username/password, it connects to the configuration =
service via HTTPS, authenticates with username/password and provides the AP=
I Key.  If the API Key is good, the configuration service responds with all=
 of the server information (Registrar, outbound proxy, TURN server, …=
) for that user.

The RUE then configures for that provider, REGISTER=
s with the stored username and password, and is then ready to place or rece=
ive calls.

I’m thinking about some cleverness where if the RUE=
 provides the browser that is used to sign up, perhaps there is a secure wa=
y for the provider to download username/password so it can be locally store=
d as above, so the user doesn’t have to enter it into the RUE.
Brian


--_000_160709388295549029purpleus_-- From nobody Fri Dec 4 07:01:08 2020 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 4ACAD3A067A for ; Fri, 4 Dec 2020 07:01:07 -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 BJD-LhqRE5Z8 for ; Fri, 4 Dec 2020 07:01:04 -0800 (PST) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 4E6963A0C8B for ; Fri, 4 Dec 2020 07:01:04 -0800 (PST) Received: by mail-qt1-x831.google.com with SMTP id p12so4075120qtp.7 for ; Fri, 04 Dec 2020 07:01: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=YE1AiJi8Fsf55IEiAssYNMG+7emS2CPo0HeZKgVSLio=; b=Q+O8+RkwwdtrVHJSdjayI5lg5oxfyiJiJv3qkdE7k6mGlj6szJ2nkkPKCILSJb3e5U k8hkHvdmHqhIt8M1JqIYLLQ7rOO5T3bTydiMhasAbWvM23IlTG1swb/SQgJrioZdWA7V AbiKsiuZwQ+xqjcBerBgSGU2h8eK3kCRA+lUjqkPnBbWjS8wBt/OJrFD+yabTXXhZabf A8BuOusvXpFEmaoc55qxruSXP1gqEqRHTy0HqL3UqC183jiN36u1kRwez/QX1smdH0/S jWr29jHfnGnwpGC6r/g74EHAbPLKtW/CVBVOvw2+8u3/6JF27RVhrdzE56zb7vkV58IL UP6g== 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=YE1AiJi8Fsf55IEiAssYNMG+7emS2CPo0HeZKgVSLio=; b=VJOZOkYNndOiWvlCof+L2akKgGzZxwBHLMxv0psl1HC8ldF/z84dQ7GW+VJJaNhx/d ZtTgxKGC1BqC9i9JThiwbvxfFR4MTtu/f4N0nMvFVfC/Gi5TWTZaXvIrWd5seOzDa+gD ugcSxzAannKi5Hsv7o2gwX3uHIZIBJ0C6pj4SWKPY5cKzG8ZGBnf9WcSsOGpsLeMHGNf G+qxjjqMrHgMPtkuWpUmOMvYbMoS4VeN/2gppYeGziCjfyZzwD7RMPhKXRVtBLEuHAs+ 0hph8Y3rNxKDAlplLpetrPtgKMeEWFxd5OipZ310SekjuuW4kT1Ok0WnKJ5Jy2wvzKrG jpDA== X-Gm-Message-State: AOAM532lGtFyyeycTYqJhnU6e8PPAM5Akr3WTkCxbVATUK49FPwiNBMS z7MflJsL0+2Ca+iG51BH62zJxg== X-Google-Smtp-Source: ABdhPJxQPXrDGL7O/5EzJl/eeSZeptpNEtP0pnjSFABRxq1CLHSemFtoc+Obn3eKjAKO4oMhtj8Cjg== X-Received: by 2002:aed:33c3:: with SMTP id v61mr9665990qtd.271.1607094062877; Fri, 04 Dec 2020 07:01:02 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id b33sm5538201qta.62.2020.12.04.07.01.01 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 07:01:01 -0800 (PST) From: Brian Rosen Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5D271522-C634-48CC-A154-30C6269AD338" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 4 Dec 2020 10:01:00 -0500 In-Reply-To: <1607093882955.49029@purple.us> Cc: "rum@ietf.org" To: James Hamlin References: <1607093882955.49029@purple.us> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rum] Proposed Solution for Configuration 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, 04 Dec 2020 15:01:07 -0000 --Apple-Mail=_5D271522-C634-48CC-A154-30C6269AD338 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 James Thanks for the comment. I think you are right. There is a tradeoff of = how much mechanism providers will supply vs managing the list. If = providers were willing to return an object to any querier on, say, a = =E2=80=9Cwell known=E2=80=9D URL in the domain contained in the central = list, then, as you suggest, all we need is the display name and that = domain. Definitely willing to write the text that way. Brian > On Dec 4, 2020, at 9:58 AM, James Hamlin = wrote: >=20 > Brian >=20 > Just one small point: it would be good to keep the amount of data in = any centrally managed list to a minimum. A list of Provider names and = domains names, would be enough for the RUM RUE to display a list of = providers to the user and to go to the provider's domains to get further = information. Centrally managed data will always cause an administrative = headache. >=20 > Best regards >=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 >=20 >=20 >=20 >=20 >=20 > From: Brian Rosen > > Message-Id: > > Date: Thu, 3 Dec 2020 12:25:27 -0500 > To: rum@ietf.org > Subject: [Rum] Proposed Solution for Configuration > List-Id: Relay User Machine > > List-Post: > > Sender: "Rum" > >=20 > Olle will have an alternative proposal, here is mine. >=20 > I start with the provider list. There is a list of providers per = country. There is an IANA registry that has a country code and a URL to = get that list. >=20 > The list has an entry per provider. The entry has sets of data = objects, one set per language supported. Each set is an object with = Iname for the provider, a URL for its configuration service, a URL for = its customer sign up service, a URL for a help desk, and a SIP URI for a = dial around front door. =20 >=20 > A user starts with the sign up service, which uses a browser. The = result is a username/password for the account. =20 >=20 > The RUE has an administrative account, which it maintains locally. = There is a username and password for that. The RUE stores the URLs for = a provider configuration service, username and password locally. Only a = user with the administrative username/password can see or change the = data. >=20 > When the RUE restarts for any reason, or following a change in = username/password, it connects to the configuration service via HTTPS, = authenticates with username/password and provides the API Key. If the = API Key is good, the configuration service responds with all of the = server information (Registrar, outbound proxy, TURN server, =E2=80=A6) = for that user. >=20 > The RUE then configures for that provider, REGISTERs with the stored = username and password, and is then ready to place or receive calls. >=20 > I=E2=80=99m thinking about some cleverness where if the RUE provides = the browser that is used to sign up, perhaps there is a secure way for = the provider to download username/password so it can be locally stored = as above, so the user doesn=E2=80=99t have to enter it into the RUE. >=20 > Brian >=20 >=20 --Apple-Mail=_5D271522-C634-48CC-A154-30C6269AD338 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 James

Thanks for the comment.  I think you are right. =  There is a tradeoff of how much mechanism providers will supply vs = managing the list.  If providers were willing to return an object = to any querier on, say, a =E2=80=9Cwell known=E2=80=9D URL in the domain = contained in the central list, then, as you suggest, all we need is the = display name and that domain.

Definitely willing to write the text = that way.

Brian


On Dec = 4, 2020, at 9:58 AM, James Hamlin <james.hamlin@purple.us> wrote:

Brian

Just one small point: it would be good to keep the amount of = data in any centrally managed list to a minimum. A list of Provider = names and domains names, would be enough for the RUM RUE to display a = list of providers to the user and to go to the provider's domains to get = further information. Centrally managed data will always cause an = administrative headache.

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: =
Brian Rosen <br@brianrosen.net>
Message-Id: <D434111F-8C8F-40AC-BAC7-DFA8616F4FA8@brianrosen.net>
Date: Thu, 3 Dec 2020 12:25:27 -0500
To: rum@ietf.org
Subject: [Rum] Proposed Solution for Configuration
List-Id: Relay User Machine <rum.ietf.org>
List-Post: <mailto:rum@ietf.org>
Sender: "Rum" <rum-bounces@ietf.org>

Olle =
will have an alternative proposal, here is mine.

I start with the provider list.  There is a list of providers =
per country.  There is an IANA registry that has a country code and a =
URL to get that list.

The list has an entry =
per provider.  The entry has sets of data objects, one set per language =
supported.  Each set is an object with Iname for the provider, a URL for =
its configuration service, a URL for its customer sign up service, a URL =
for a help desk, and a SIP URI for a dial around front door.  

A user starts with the sign up service, which =
uses a browser.  The result is a username/password for the account.  

The RUE has an administrative account, which =
it maintains locally.  There is a username and password for that.  The =
RUE stores the URLs for a provider configuration service, username and =
password locally.  Only a user with the administrative username/password =
can see or change the data.

When the RUE =
restarts for any reason, or following a change in username/password, it =
connects to the configuration service via HTTPS, authenticates with =
username/password and provides the API Key.  If the API Key is good, the =
configuration service responds with all of the server information =
(Registrar, outbound proxy, TURN server, =E2=80=A6) for that user.

The RUE then configures for that provider, =
REGISTERs with the stored username and password, and is then ready to =
place or receive calls.

I=E2=80=99m =
thinking about some cleverness where if the RUE provides the browser =
that is used to sign up, perhaps there is a secure way for the provider =
to download username/password so it can be locally stored as above, so =
the user doesn=E2=80=99t have to enter it into the RUE.

Brian




= --Apple-Mail=_5D271522-C634-48CC-A154-30C6269AD338-- From nobody Sat Dec 5 09:07:17 2020 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 226383A08BB for ; Sat, 5 Dec 2020 09:07: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 gqcA0OJVNGsd for ; Sat, 5 Dec 2020 09:07:13 -0800 (PST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2045.outbound.protection.outlook.com [40.107.223.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 856373A08B0 for ; Sat, 5 Dec 2020 09:07:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NP6qIbycNrndzyXXOChq3dskfqni1gvO8JNkrz7Qf/OdQa+VsVvCU/RdrdbDIBLOu5yI0wUnp6CPotom0JA0VEfc3wFuuwyD5ZuPRxoNtzoccQcTwfh9UujGSNEAOVtHNy0TLLpZQO6N40RPDqxm3QEFtMT2636aYUKQPjIdA5zWdsx1ElI6w0ApP4RH1Fn0VyGXXio9Viqieknki3adF/QxlmgEmpJ5r4mYjEuv1fegWsKfDghvA3U5Bm4vOxVK6hHMkwuRxNmxMxMOao/F7Tu6iKsPjCEicOnXCD9LF98c5mrLz0QQVdKyai77gKj31ltOd+P6PrRnRVSPbscipQ== 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=Z0IbKsEnfxd6Jsy7bWvhf6iVxMEaFlXJbtBqRtuYWZ0=; b=RRssOsEkfVUmiRB7sAMEdD0rpRxTBw7APTumGvvAIFSgFsBl+1VDhpVmnpf/5rl9XVM4jYzCl2eM12RfAYN2kABujOMi+w93+UOV0BJwhMFZru97AHkxrGYvuB1uFr+ePlUrsNFRK0adWr9DHVGAot16EfZJmYuQwJfzhyy2yaSm10BqOgPEJgOY4rnfbVDCff4pIJMVuaA3jBAWxslVN3j/WvtHhb7uzeC4ii8R9/UNgoyTBnRI7HB7IuNiZFSA8odbj4Xg8R1uB9rrvFzXtnGiI9tzI59T3WHW7ChTHFzC7+cHpXdUiQ0vNCRjqvz3DjZR83A4AH6sYspQnmGbOQ== 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=Z0IbKsEnfxd6Jsy7bWvhf6iVxMEaFlXJbtBqRtuYWZ0=; b=YyNZIIlQCZ3E7SmughXAvYlTpxWpMZFAXC00OZgGUI3XcXawQgzEBQ0ORU4YAW2nInplxpHADFPRqiEpakF5bLgC+7ZsL6vcHaBGiHH53yMh0SPh1nKMRYXKNRSOSmIDPL/BXaSlC0WowRGZgJqQ2Y51SGijE0PXTvEC65gjgjg= Received: from SN6PR05CA0036.namprd05.prod.outlook.com (2603:10b6:805:de::49) by MN2PR12MB4471.namprd12.prod.outlook.com (2603:10b6:208:26f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Sat, 5 Dec 2020 17:07:11 +0000 Received: from SN1NAM02FT033.eop-nam02.prod.protection.outlook.com (2603:10b6:805:de:cafe::c0) by SN6PR05CA0036.outlook.office365.com (2603:10b6:805:de::49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.5 via Frontend Transport; Sat, 5 Dec 2020 17:07:11 +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 SN1NAM02FT033.mail.protection.outlook.com (10.152.72.133) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21 via Frontend Transport; Sat, 5 Dec 2020 17:07:10 +0000 Received: from PaulKyzivatsMBP.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 0B5H77qK006032 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Sat, 5 Dec 2020 12:07:09 -0500 To: rum@ietf.org References: From: Paul Kyzivat Message-ID: <6bcd7fd7-cb50-a577-3c7a-d1ad555be019@alum.mit.edu> Date: Sat, 5 Dec 2020 12:07:07 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.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: 503a6ee5-5cdc-4b52-f3ab-08d899403479 X-MS-TrafficTypeDiagnostic: MN2PR12MB4471: 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: 6yVfnXK26OgI/TIto7s3rlPKxspqGNf76+ZTwuv6Sx0O8bG1GKF01EL6eAHMjDIspSf7dK/7FWg8/On7tne1aTxZ9ukgUiVykVj276/zajcsNfgC+4gcQVDz/6Bvdjde5zhuzCyJzJ7kh6ILnfB1DAqasn24Bhw3PdUaCxCyZAjd1MUy34LsVYt2bK5ookPdqWqFUYJnz8iitc9OheGazXMOO2rD2L/wQ0bRGoU6+mwHu7l0nHRVeCKvuEp9CTWrj+7ZzB2A4vGIfpGAMq0ZM3PMr2UktuwWFz/m00YNSZgFHsWrL2KSCmVScu8zM3BvUOvXpwjNT1GVy1ZNJFrv6Z0bM0Onra8/mB6kFE++6kUYq2fCT8Fp6TkbsinKa8uZ/CYojDv9sObeaaQDVNEmF6RyJHzzTCp7e6DxA0ZrlpAtFtorr/cQhXOUspTIQDNQ 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)(39860400002)(136003)(396003)(346002)(46966005)(83380400001)(356005)(70206006)(8936002)(7596003)(5660300002)(6916009)(31696002)(26005)(66574015)(82740400003)(8676002)(70586007)(186003)(786003)(2616005)(316002)(47076004)(956004)(336012)(2906002)(31686004)(82310400003)(53546011)(75432002)(86362001)(478600001)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Dec 2020 17:07:10.7730 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 503a6ee5-5cdc-4b52-f3ab-08d899403479 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: SN1NAM02FT033.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR12MB4471 Archived-At: Subject: Re: [Rum] Proposed Solution for Configuration 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, 05 Dec 2020 17:07:16 -0000 Brian, With my chair hat OFF: On 12/3/20 12:25 PM, Brian Rosen wrote: > Olle will have an alternative proposal, here is mine. > > I start with the provider list. There is a list of providers per country. There is an IANA registry that has a country code and a URL to get that list. > > The list has an entry per provider. The entry has sets of data objects, one set per language supported. Each set is an object with Iname for the provider, a URL for its configuration service, a URL for its customer sign up service, a URL for a help desk, and a SIP URI for a dial around front door. I agree with James on this: simplify the list and retrieve all the provider-specific data from the provider site, probably via well known URLs. > A user starts with the sign up service, which uses a browser. The result is a username/password for the account. Can providers give us some insight here. Will there be any potential customers that need some alternative mechanism to a browser? > The RUE has an administrative account, which it maintains locally. There is a username and password for that. The RUE stores the URLs for a provider configuration service, username and password locally. Hopefully the RUE can save information for more than one provider account - all those for which the user has accounts. Question: is it permissible for a RUE to only support one provider? Only one particular provider? > Only a user with the administrative username/password can see or change the data. Can someone without the admin id/pw make and answer calls? (I presume yes.) If so, what can a person without the admin id/pw see? I think they should be able to see the phone numbers assigned to each provider account, and probably the names of the corresponding providers. > When the RUE restarts for any reason, or following a change in username/password, it connects to the configuration service via HTTPS, authenticates with username/password and provides the API Key. If the API Key is good, the configuration service responds with all of the server information (Registrar, outbound proxy, TURN server, …) for that user. When you say "change in username/password" above, which one do you mean? The RUE won't necessarily know when the id/pw for the provider account changes. What it can know soonest is when the registration to the sip server ends and an attempt to register is rejected for a bad password. (Or similar failure when attempting to access address book.) If that happens, reloading the configuration should get fresh versions of needed credentials. It is more of a problem if the provider has need to force a change in the password for the users web account. But that is much like any web account, where typically the user is given a long time to make a change. Perhaps there needs to be an indicator in the configuration data that the user needs to contact the provider. > The RUE then configures for that provider, REGISTERs with the stored username and password, and is then ready to place or receive calls. > > I’m thinking about some cleverness where if the RUE provides the browser that is used to sign up, perhaps there is a secure way for the provider to download username/password so it can be locally stored as above, so the user doesn’t have to enter it into the RUE. Yes, that would be very helpful. Thanks, Paul From nobody Mon Dec 7 07:20:14 2020 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 4D2BB3A1257 for ; Mon, 7 Dec 2020 07:20:13 -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 8T0yDKLWCEcs for ; Mon, 7 Dec 2020 07:20:11 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 E41123A0E2D for ; Mon, 7 Dec 2020 07:20:10 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id n142so2616941qkn.2 for ; Mon, 07 Dec 2020 07:20:10 -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=VLHxzfAtIF2tdGGFDRS/p5//9N4zIx5IjZ/9wWbBQFg=; b=n5nc+Zlf6sS8abG+4PQ4NaUbQcL+9gq6fsgPPFHnT5oAb+8SvVhdkhWm6p8FpBvWub DllLrhFyi62VKceH2zeTAxwqiU9qN1eJTPw1ueALk7j6mwREorX/o6royoxpmVphds7r tAieVCXyI3vV3FjSan3sl9NaxyzubfxKvL65lFBL5DVxxdXZequDf+i01k9osTFmXI+1 iqpLe1uziepm2Sw/orKLHGPqPnCq6NXGIVpsf0bkNVHX/kpYXaweAR1kH0Uz+iNvr3l1 A9oQkH5RiOILe6AGYGamnLD5AJosZRZ3+6dpZC4Ckt2tgrP/SFQHUgjnYyNJleQuDK1O JQqg== 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=VLHxzfAtIF2tdGGFDRS/p5//9N4zIx5IjZ/9wWbBQFg=; b=GH6Jis9JN4TmVFNxfKRuBUGBAC3vpWOpHL8vA7nDbBs7GVXv0Q0I0OjvvRrKmlTPdV nzTNGglraiC38DPKUMQ56MA/ePPQfZ00mNUKbRem40O/OzkGHI5jBR/1QTcZNu3e0hrj 5BWx5Phx5p3QofHaES1YECoB+4keoIbXRW7CoFDK0JG0Lb16pS5oWYO9GY4+bWmmIfF3 9u8VyZNA9Nae+KBmlXnSj/ghmmZUmCYshMa8/KAO9CL+5slhJ+gYwU8M6PLXuiUmiqNl wyDAwqs8IRrZ1lIwp3Ph4Lgts1jnbayNPQsmizQPfQoNRVAjyzs3bpfZm3X0VhtOziHD YcIg== X-Gm-Message-State: AOAM532dE/j1s8qCmKePxJsGYcZLjeqMVS2MLmWrum29BM0pvVgSJ6uc oZ5POwGjFoRAbV+h9fiYpztbsA== X-Google-Smtp-Source: ABdhPJxA/JXHNp/Dv18Xmkrdli8c3xHRZxjcqvx4vBQPyGcL/tUPsR++bmwPL6YQE2zHPMS+5ItHfA== X-Received: by 2002:a37:4782:: with SMTP id u124mr14908299qka.82.1607354409849; Mon, 07 Dec 2020 07:20:09 -0800 (PST) Received: from brians-mbp-2871.lan ([24.154.119.158]) by smtp.gmail.com with ESMTPSA id b14sm11260260qtx.36.2020.12.07.07.20.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Dec 2020 07:20:09 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Brian Rosen In-Reply-To: <6bcd7fd7-cb50-a577-3c7a-d1ad555be019@alum.mit.edu> Date: Mon, 7 Dec 2020 10:20:04 -0500 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <5C2DB83F-854A-4758-BC62-021DA03156B6@brianrosen.net> References: <6bcd7fd7-cb50-a577-3c7a-d1ad555be019@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rum] Proposed Solution for Configuration 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, 07 Dec 2020 15:20:13 -0000 Responses in line (as author/contributor) > On Dec 5, 2020, at 12:07 PM, Paul Kyzivat = wrote: >=20 > Brian, >=20 > With my chair hat OFF: >=20 > On 12/3/20 12:25 PM, Brian Rosen wrote: >> Olle will have an alternative proposal, here is mine. >> I start with the provider list. There is a list of providers per = country. There is an IANA registry that has a country code and a URL to = get that list. >> The list has an entry per provider. The entry has sets of data = objects, one set per language supported. Each set is an object with = Iname for the provider, a URL for its configuration service, a URL for = its customer sign up service, a URL for a help desk, and a SIP URI for a = dial around front door. >=20 > I agree with James on this: simplify the list and retrieve all the = provider-specific data from the provider site, probably via well known = URLs. Will Do >=20 >> A user starts with the sign up service, which uses a browser. The = result is a username/password for the account. >=20 > Can providers give us some insight here. Will there be any potential = customers that need some alternative mechanism to a browser? There is no problem doing this, as long as the result is an account with = username/password >=20 >> The RUE has an administrative account, which it maintains locally. = There is a username and password for that. The RUE stores the URLs for = a provider configuration service, username and password locally.=20 >=20 > Hopefully the RUE can save information for more than one provider = account - all those for which the user has accounts. Yes, that was the idea >=20 > Question: is it permissible for a RUE to only support one provider? = Only one particular provider? Our goal was to not do that, but of course it=E2=80=99s possible. >=20 >> Only a user with the administrative username/password can see or = change the data. >=20 > Can someone without the admin id/pw make and answer calls? (I presume = yes.) Yes, in the same sense that if any existing device is logged in, and = someone other than the account owner is sitting in front of it, it will = work, There are legal implications of that in some jurisdictions, but = no device I know requires login per call. >=20 > If so, what can a person without the admin id/pw see? I think they = should be able to see the phone numbers assigned to each provider = account, and probably the names of the corresponding providers. Yeah, although that=E2=80=99s probably not something I think we would = put in the doc other than possibly noting that=E2=80=99s an issue in the = security considerations. >=20 >> When the RUE restarts for any reason, or following a change in = username/password, it connects to the configuration service via HTTPS, = authenticates with username/password and provides the API Key. If the = API Key is good, the configuration service responds with all of the = server information (Registrar, outbound proxy, TURN server, =E2=80=A6) = for that user. >=20 > When you say "change in username/password" above, which one do you = mean? =E2=80=9CForgot Password=E2=80=9D type reset, or something where the = username has to change. If either changes, the local file has to change >=20 > The RUE won't necessarily know when the id/pw for the provider account = changes. What it can know soonest is when the registration to the sip = server ends and an attempt to register is rejected for a bad password. = (Or similar failure when attempting to access address book.) Yeah, and I don=E2=80=99t think we care. There would have to be UI to = change it, and there might be errors until it does. If it=E2=80=99s = changes, REGISTER would be re-run. >=20 > If that happens, reloading the configuration should get fresh versions = of needed credentials. There is only the local file. If one account changes, nothing would = affect other accounts. What other credentials are there? >=20 > It is more of a problem if the provider has need to force a change in = the password for the users web account. But that is much like any web = account, where typically the user is given a long time to make a change. Yes >=20 > Perhaps there needs to be an indicator in the configuration data that = the user needs to contact the provider. More UI stuff that probably isn=E2=80=99t in the spec. >=20 >> The RUE then configures for that provider, REGISTERs with the stored = username and password, and is then ready to place or receive calls. >> I=E2=80=99m thinking about some cleverness where if the RUE provides = the browser that is used to sign up, perhaps there is a secure way for = the provider to download username/password so it can be locally stored = as above, so the user doesn=E2=80=99t have to enter it into the RUE. >=20 > Yes, that would be very helpful. >=20 > Thanks, > Paul >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Mon Dec 7 08:01:06 2020 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 400E93A1412 for ; Mon, 7 Dec 2020 08:01:04 -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 XrPcRSLAAsLu for ; Mon, 7 Dec 2020 08:01:00 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770089.outbound.protection.outlook.com [40.107.77.89]) (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 B40BC3A140F for ; Mon, 7 Dec 2020 08:01:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KnxRT1aInEgrEBrX0Ycmok2eGl00ukp/wp2Oy3ngkJJmmUOnxk/7iOUgS7cGHwJbCDfSsoWd4JxwyzIJcDR6/66Kl9/mQVqD7kWA4Ml8xljEV5LL6vs3DZR7fHEUnwPHHtCOaP2TDnYZC/wNQgWufq6jmVR8b0TmkBSDk/N4axSreZIeKkPAqVoO0eIJ0KnXbt6Xj8XvnxK5ObPBjSSlY9YYyLBCIPKGHtkjGiTngS8/xglw3zrooW3rYKmKEqfzZUzVkhmNM6PHYanWOpCxqmkheIE+GgbJbxVyQVbWNaXUoK2KTdrZt17y4zu1p6kGPDHozvOlLTGZarRPo1LzYA== 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=pT/GgajYRp1kRT59XXajua6bLHwjfaBW1C34KPeECoI=; b=aRSRHkgtMNeKNKdUyiMiOERln4PFryv61DlMHyW9wq+opGDTDRvldv3DrVgD+AefKdzhOTy8hjUp3IkUq0nYIXhvUb/frk7Gw6i0rPcNTewAy/WYyTlOt11b80vv3jmb3Rk65ZbUqMtsC9qvYuDqVr2ysyWgzjnfqnCpcZ4hpz5MwMM2u2h/QaZhViXBFOnZ3b3lQFe5P73diUnBOlAd+KNc/v2Lv0U4NCwBZASC/6AK8aaQvmcqcUiG0xzXoS01fCk3piC7zrmIxtjUD5T1s5SXnmtXPjEVvLgIq+EwrDg1r/Jf9d11erneayhCqFAYAUfC0QMIAi6XgKdLkBCnZg== 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=pT/GgajYRp1kRT59XXajua6bLHwjfaBW1C34KPeECoI=; b=PW1iTRd4oOQDvXfoicC2ynQKwuQXhqGVOeXPrtgIjJluNVp3xp4mE56Y6wN4LVLaU5MantMOVNt8+B94KbUupe1Uyp5uslt/o03DJbXMPcjuVqHN1U+ZS7ZBeQDBb1jCfV7QVFK8Wgdzdxq6mN05qAgdWMezJhsWv78eSwKVQYo= Received: from BL1PR13CA0421.namprd13.prod.outlook.com (2603:10b6:208:2c3::6) by BY5PR12MB3682.namprd12.prod.outlook.com (2603:10b6:a03:195::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Mon, 7 Dec 2020 16:00:59 +0000 Received: from BL2NAM02FT033.eop-nam02.prod.protection.outlook.com (2603:10b6:208:2c3:cafe::83) by BL1PR13CA0421.outlook.office365.com (2603:10b6:208:2c3::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.10 via Frontend Transport; Mon, 7 Dec 2020 16:00:58 +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 BL2NAM02FT033.mail.protection.outlook.com (10.152.77.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.21 via Frontend Transport; Mon, 7 Dec 2020 16:00:58 +0000 Received: from PaulKyzivatsMBP.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 0B7G0uER027379 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 7 Dec 2020 11:00:57 -0500 To: rum@ietf.org References: <6bcd7fd7-cb50-a577-3c7a-d1ad555be019@alum.mit.edu> <5C2DB83F-854A-4758-BC62-021DA03156B6@brianrosen.net> From: Paul Kyzivat Message-ID: Date: Mon, 7 Dec 2020 11:00:56 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <5C2DB83F-854A-4758-BC62-021DA03156B6@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: 73f1e3a3-8cb3-49e7-5a92-08d89ac9496b X-MS-TrafficTypeDiagnostic: BY5PR12MB3682: 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: Waqh3SVLmKRv5mPR8UE/SU9cWS3uOKIOLJSQBW3Cub+BsqtLlR+Tj0i2kIufUn3ADy6nEnC8Vdd7vHd276g7B3c1whebzQ5UtdF4Rh796CDhu1Q2fRLtBYQuN4n0MSXH+YXkqE+GYML8VbOL/RGLbuM57P6q/zn7GtTmfqNmnKBMHedaSvMcWsmsbp1sXdpMEQZ5yBQLULR4F4TXwhplJXdrevmMq9V1GMepfxLHfuWOKxc4bs50PKC8AYKMTVdksAsJ38M6k8bNzPRohcOdabim2RSoHciihzurwLDMpQ2lNvOhegDEebg1K9uPoJYp5TgRV+uwmDIKFKEt+5YycXlqApi34aYIco/X5nShau7//VzFurXXV6BhOu/tNn3oUDyBME3wfOFh1Q7OY0BmoF+X1NBSFLnsUk8Dv5v3GYPQKiKmW5m1iETH3gFDlGwk 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)(396003)(39860400002)(136003)(46966005)(53546011)(70586007)(6916009)(7596003)(786003)(31696002)(8936002)(26005)(2906002)(356005)(5660300002)(66574015)(186003)(70206006)(8676002)(83380400001)(316002)(47076004)(2616005)(75432002)(336012)(31686004)(36906005)(478600001)(86362001)(82310400003)(956004)(82740400003)(43740500002); DIR:OUT; SFP:1101; X-OriginatorOrg: alum.mit.edu X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2020 16:00:58.2941 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 73f1e3a3-8cb3-49e7-5a92-08d89ac9496b 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: BL2NAM02FT033.eop-nam02.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB3682 Archived-At: Subject: Re: [Rum] Proposed Solution for Configuration 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, 07 Dec 2020 16:01:04 -0000 Hi Brian, More inline. On 12/7/20 10:20 AM, Brian Rosen wrote: > Responses in line (as author/contributor) > >> On Dec 5, 2020, at 12:07 PM, Paul Kyzivat wrote: [snip] >>> A user starts with the sign up service, which uses a browser. The result is a username/password for the account. >> >> Can providers give us some insight here. Will there be any potential customers that need some alternative mechanism to a browser? > There is no problem doing this, as long as the result is an account with username/password I guess worst case is that a potential customer without any browser device might need to request the assistance of somebody with a browser to do the initial signup. Given that pretty much any cell phone has this capability that is probably not too much to ask. So I agree we should be able to ignore this as a problem. >>> The RUE has an administrative account, which it maintains locally. There is a username and password for that. The RUE stores the URLs for a provider configuration service, username and password locally. >> >> Hopefully the RUE can save information for more than one provider account - all those for which the user has accounts. > Yes, that was the idea >> >> Question: is it permissible for a RUE to only support one provider? Only one particular provider? > Our goal was to not do that, but of course it’s possible. The question is whether one or both of these features should be part of the spec. >>> Only a user with the administrative username/password can see or change the data. >> >> Can someone without the admin id/pw make and answer calls? (I presume yes.) > Yes, in the same sense that if any existing device is logged in, and someone other than the account owner is sitting in front of it, it will work, There are legal implications of that in some jurisdictions, but no device I know requires login per call. Again, we should consider whether this needs to be part of the spec. >> If so, what can a person without the admin id/pw see? I think they should be able to see the phone numbers assigned to each provider account, and probably the names of the corresponding providers. > Yeah, although that’s probably not something I think we would put in the doc other than possibly noting that’s an issue in the security considerations. Seems worthwhile to say *something*, even if non-normative. >>> When the RUE restarts for any reason, or following a change in username/password, it connects to the configuration service via HTTPS, authenticates with username/password and provides the API Key. If the API Key is good, the configuration service responds with all of the server information (Registrar, outbound proxy, TURN server, …) for that user. >> >> When you say "change in username/password" above, which one do you mean? > “Forgot Password” type reset, or something where the username has to change. If either changes, the local file has to change I think your intent was regarding change in the administrative id/pw. But the text wasn't clear about that. You might have meant to include change to the one of the id/pws that had previously been loaded via the configuration. I was just seeking clarification of the text. >> The RUE won't necessarily know when the id/pw for the provider account changes. What it can know soonest is when the registration to the sip server ends and an attempt to register is rejected for a bad password. (Or similar failure when attempting to access address book.) > Yeah, and I don’t think we care. There would have to be UI to change it, and there might be errors until it does. If it’s changes, REGISTER would be re-run. I'm just seeking clarity in how various issues are indicated by the provider and how the RUE is expected to respond to them so that the RUE isn't required to have provider-specific logic in order to provide good service. >> If that happens, reloading the configuration should get fresh versions of needed credentials. > There is only the local file. If one account changes, nothing would affect other accounts. What other credentials are there? IIUC, the configuration downloaded by the RUE from a provider contains credentials for sip registration, address book sync, etc. If the provider finds a need to change those, it should not require a reload of the RUE or any overt action by the user for the RUE to discover that it needs to reload the configuration to fix the problem. And this is independent for each provider the RUE is attached to. >> It is more of a problem if the provider has need to force a change in the password for the users web account. But that is much like any web account, where typically the user is given a long time to make a change. > Yes >> >> Perhaps there needs to be an indicator in the configuration data that the user needs to contact the provider. > More UI stuff that probably isn’t in the spec. What the UI looks like in response is out of scope. But an indicator in the config that action by the user is required could be in scope. Perhaps we could simply include in the config some announcement text that the RUE should display to the user. Alternately we could just assume that if the provider needs to alert the user of some needed action then it has other means, such as email, to send that alert. Thanks, Paul From nobody Tue Dec 8 07:12:33 2020 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 A37533A0F74; Tue, 8 Dec 2020 07:12:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744035066.24024.17761946750112098407@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:12:30 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:12:31 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4428/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:13:23 2020 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 126073A0FC0; Tue, 8 Dec 2020 07:13:12 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744039206.11518.663754600775305265@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:13:12 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:13:20 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4429/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:13:56 2020 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 1299F3A0FEA; Tue, 8 Dec 2020 07:13:46 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744042606.7712.8167459307481747164@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:13:46 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:13:54 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4430/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:14:26 2020 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 1EBA23A0F7F; Tue, 8 Dec 2020 07:14:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: ipr-announce@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744046111.15988.5657172704860723114@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:14:21 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:14:21 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4432/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:15:08 2020 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 A44113A0FF5; Tue, 8 Dec 2020 07:14:57 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744049766.32564.9580295590484621857@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:14:57 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:15:05 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4433/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:15:37 2020 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 515063A0FAD; Tue, 8 Dec 2020 07:15:32 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744053232.11494.12297445406572263417@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:15:32 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:15:32 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4436/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:16:16 2020 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 350933A0FB1; Tue, 8 Dec 2020 07:16:14 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744057420.11494.16565242257570800533@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:16:14 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:16:14 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4439/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 07:16:41 2020 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 F22383A0FAD; Tue, 8 Dec 2020 07:16:36 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744059698.10582.13848099543512014419@ietfa.amsl.com> Date: Tue, 08 Dec 2020 07:16:36 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 15:16:37 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4438/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Tue Dec 8 08:56:36 2020 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 5F9703A102B; Tue, 8 Dec 2020 08:56:35 -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, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.23.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160744659538.11518.13233064499128759209@ietfa.amsl.com> Date: Tue, 08 Dec 2020 08:56:35 -0800 Archived-At: Subject: [Rum] IPR Disclosure Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue 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: Tue, 08 Dec 2020 16:56:35 -0000 Dear Brian Rosen: An IPR disclosure that pertains to your Internet-Draft entitled "Interoperability Profile for Relay User Equipment" (draft-ietf-rum-rue) was submitted to the IETF Secretariat on 2020-11-05 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/4431/). The title of the IPR disclosure is "Sorenson IP Holdings LLC's Statement about IPR related to draft-ietf-rum-rue" Thank you IETF Secretariat From nobody Wed Dec 9 10:17:15 2020 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 56F503A16E1 for ; Wed, 9 Dec 2020 10:17: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_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 SDPI1OV99HxA for ; Wed, 9 Dec 2020 10:17:12 -0800 (PST) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2081.outbound.protection.outlook.com [40.107.220.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 040113A16E2 for ; Wed, 9 Dec 2020 10:17:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h9W50GDCMlPt3+QIA26mGfnQYi+/aVew2alkSu02QrouiFSmqk3BE8VK005v49TGGcFuufaYC3HPiEw3lCKZqZSb1c2WDMijJNazdvumq64aowxkEM3U9Zc2BinCtbErIVPxRBjnCRd44A0imNcOr9+q478NQibkR4dry4j+4Xjj5RIMWc7i6+rmv+NZPqn6cZsQ9P4urlXu/8SykFAx4owgIvGH+gt/elTw6bHFP7ZvAspg/Ho5mGoKHsISR1g5g20YD6CwN3OGHDwYtiEIGgpPx9g+CiNCTMbG7ZsXyRTh7LiXk757CJIZM7+sB1n9hftd1dfRZ0T+2mMF7yI1zA== 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=CUQUW6gukdrreoCQCt47lPkAWX40qn7/DfI9GJH1QGY=; b=N5rwG2xyRXHaVmgWyhxQ3uYkYsU42YaW5JH/CpbvGgo8J9TumvH8K/Nv9AK1f53oez7lLXKadb/4HH1C/+5srx9vgJc2kCEl0MtpCW6iyOfhVGJlVPKuM61ECe/cHDw4llRxidsA79gVp/BUSiFeW2ExwXS9lW8F87+PK2XvvW4Ti1fu9ZXH0IimJhwNGu9nq3hlayAl9XHGdQFdTRlWJTo4aEdUh5yaITSjVIK/FjFAuMjkkggxDMtxfUiJl7kC3x9RvDgrbNT4T0n5fkbJw9Fn0QV6MAwkr8604W8w+5uHbH3MnTUfA2/+jGHqv0Ja6sA4Sh0oirqiHSqYowcldw== 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=CUQUW6gukdrreoCQCt47lPkAWX40qn7/DfI9GJH1QGY=; b=x1K8s2T4Cu5oUzM46aNYqkKnTFaY0sAuGsEyiwHlIFLb0SpOxLe9z4ELVvS6kDYogcezYH7yYVQtKZKZ7TD5TKxKeb206mdHgIVfiGRJjnHZ4TRussaGJe9RHeJDRQhsQ0qB4z7sTFMtNQMl2+W/MctQn2wBYi/ribBmo18dL2Y= Received: from BYAPR04MB4983.namprd04.prod.outlook.com (2603:10b6:a03:41::29) by BY5PR04MB6961.namprd04.prod.outlook.com (2603:10b6:a03:22b::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Wed, 9 Dec 2020 18:17:08 +0000 Received: from BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1]) by BYAPR04MB4983.namprd04.prod.outlook.com ([fe80::e09a:6be0:ccf6:a8b1%7]) with mapi id 15.20.3632.021; Wed, 9 Dec 2020 18:17:08 +0000 From: Eugene Christensen To: Brian Rosen , James Hamlin CC: "rum@ietf.org" Thread-Topic: [Rum] Proposed Solution for Configuration Thread-Index: AQHWyky5ctqwSp3zHUeJNn0SY484xqnnB/QAgAgSHrA= Date: Wed, 9 Dec 2020 18:17:06 +0000 Message-ID: References: <1607093882955.49029@purple.us> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=sorenson.com; x-originating-ip: [75.146.88.198] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a7d09bd7-8453-4f68-2528-08d89c6ea3c7 x-ms-traffictypediagnostic: BY5PR04MB6961: 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: +4k27EdsmRhQXjeFUvVpnCK6sxHuREjKGVIHsn9vQgDmoAHkZicyRQeeXGNHp/uRL+PztZi5lqoX/WyqMsH8AcRw2jrY4S7ar1dMfobAB1h9To0obdQr4sdMlMXqZpXcr3lSaGl5oUz0oRNb8PV+NdHNknZO20un+phKm+sJIN4tkkkUgqe00eEcwcwWhCHCu6C/lgRugGWXWBtN8O63L/87lJRb0RKSDbX5v9Px1etkKgplWSyNsL2qSTCLTA6qQicsXYvPzuoszVSwC65O3ZGdb+IN+tgojeWQ3cWmT2MMiDhMI+Xep0np4XjPBoLJ/oAPMKpjteH+qcYHh9PWD6Rph7Lb4kbv8EcRCyigEEdzIIWfu2iKRo/M7rNIWS9Ux9VqKdvGKJfJOsqH1dSV9A== 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)(136003)(376002)(366004)(66946007)(52536014)(66476007)(66446008)(64756008)(66556008)(76116006)(6506007)(7696005)(8936002)(186003)(508600001)(18074004)(26005)(8676002)(110136005)(53546011)(66574015)(83380400001)(71200400001)(166002)(4326008)(9686003)(33656002)(55016002)(86362001)(2906002)(5660300002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?b2FXZ25LalJaV0RsYThwZUV0WkU4aSt0RHZOM05KQlhwV242UDNxY2V3dG8z?= =?utf-8?B?b1dPS3pybDU3U1FXNkRiV2FoaG8xaWhja0pFSnk5akEwUXhMOFJkc1d5Szcr?= =?utf-8?B?YlRUTnkxK3JmdzVBM013eVJOM1RWUC9OeUgycGVTRlVJWlloKzFpNnc5b3dC?= =?utf-8?B?Z2M0K1NoMTY4L3RrMGRDK2MyendFdWJRT3NEd0lZeS83T2haOXBZWUwza2R2?= =?utf-8?B?cnJvbnNoaGN6R2VkOEpWeEZ5MEJCL3RQM1pMZHRRSmxnakdEZGdCeDFPaGd5?= =?utf-8?B?Rks1QkFUbGRhVEEwQXJIQVU0QlF0bzFQTWRkTEpSVnlTVEdvL1FVQXQ1NFFV?= =?utf-8?B?MEdzb3EzWW9GYy9KU2EzcEFzVkRxTldYSVZLenllakNtemNaTmZHSlFOUUlP?= =?utf-8?B?ejcxZzNLSFlxNjlDb2RYWm5ERXJHREpYelgyWTM3Z29GTzBtSU43a1ZIcDgz?= =?utf-8?B?UEFXbUNNOFJGQitaNFdvTGx0TFVJNnNoRzZycGxXK1ZxOVVYSWZ1cHVvb3Vj?= =?utf-8?B?MkV6aTJoa0VjMkpnOERRMFFwNnc3aDRHYk15eHNvMUVUWXp5SXdjTEEvUFRk?= =?utf-8?B?QncwRWtJS000SUpud2dZeWwxeHlFMlVFTzhxa0daWnpSbkpEMHVKSVZST0pC?= =?utf-8?B?d2IzaVlmKzRDaXphZHNBWk9KdjR2ZXZETTlMSnExNndaMmYrZURjRVo2LzN0?= =?utf-8?B?cjczN0Z1M3BuSndTbU9ZSWZuQWlkSjVYa2FheU1yTkZHSm1mTGV5aERLN1V4?= =?utf-8?B?eGV6NUhPWGtEUzV3djRPandCdkxYRUxzOU5YdFluajRLM280amZDaWh3N21M?= =?utf-8?B?eitleW0wM2oxdW11a3RKdlRoSGRXNU1EQkFGQUV5SFR2aFZtN092MU03d1ZK?= =?utf-8?B?aWdXNmdobG5DZXpYcFk0Y3p3WXgvMUVTNmcya0l5Sk1kSDk0SU43RUxSd2pp?= =?utf-8?B?RFo0S2pjRUdDdHNZbFJVeXpEQStIYzRWd01pbjdiYnVsbUpmSE9YWmpyQ2h2?= =?utf-8?B?VG81d0ZSb3ZhaTR4S01lUWdneEZzMTB1aFFZOHFtdGJtQVlJVUJXYlI0OEFR?= =?utf-8?B?cUxrcjUwYWh1K3R2b2p4bUpoeWNFVngvWU83aU0zMlZqQkwxc3lVOHZNNUdP?= =?utf-8?B?bDdlb1V3VUNGNlhNTHV4TnZqMW8yZnduZnJWZ2F1UGl1MHR5R3BrQkNSR0wy?= =?utf-8?B?bWtHdVphNG5yYWt3U3k4ZGpROGlkdEkzWEd2NkNqN3hLUkRYdXFyS2Z6UUVQ?= =?utf-8?B?cDhuVzRtVWtjam5KalpTRnZlaG9NaTB1SkZ0UmpBVWpuS0I2OUtVbmEydHRz?= =?utf-8?Q?zXkHSDXHpw0Tc=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR04MB4983A128C87204E2053DF21DA3CC0BYAPR04MB4983namp_" 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: a7d09bd7-8453-4f68-2528-08d89c6ea3c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Dec 2020 18:17:07.9459 (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: n2wMfaMn6N9DI5s10lB2zM5VZOXUdKaOCEv647+eYgyMcbI5CDJ+DJPY/0P86/OUbYtR2dnyMYQTy5Z+oN2Usdj1W9AWsDLDAbmjhBgW3wU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR04MB6961 Archived-At: Subject: Re: [Rum] Proposed Solution for Configuration 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, 09 Dec 2020 18:17:14 -0000 --_000_BYAPR04MB4983A128C87204E2053DF21DA3CC0BYAPR04MB4983namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbHNvIGFncmVlIHdpdGggSmFtZXMg4oCcdG8ga2VlcCB0aGUgYW1vdW50IG9mIGRhdGEgaW4g YW55IGNlbnRyYWxseSBtYW5hZ2VkIGxpc3QgdG8gYSBtaW5pbXVt4oCdLg0KDQpDT05GSURFTlRJ QUxJVFkgTk9USUNFLiBUaGlzIGUtbWFpbCB0cmFuc21pc3Npb24sIGFuZCBhbnkgZG9jdW1lbnRz LCBmaWxlcyBvciBwcmV2aW91cyBlLW1haWwgbWVzc2FnZXMgYXR0YWNoZWQgdG8gaXQsIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBhbmQgcHJvcHJpZXRhcnkgaW5mb3JtYXRpb24uIElmIHlvdSBh cmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIGEgcGVyc29uIHJlc3BvbnNpYmxlIGZv ciBkZWxpdmVyaW5nIGl0IHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5 IG5vdGlmaWVkIHRoYXQgYW55IGRpc2Nsb3N1cmUsIGNvcHlpbmcsIGRpc3RyaWJ1dGlvbiBvciB1 c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gb3IgYXR0YWNoZWQgdG8g dGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklURUQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgbm90aWZ5IG1l IGJ5IHJlcGx5IGUtbWFpbCBhdCBlY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tPG1haWx0bzplY2hy aXN0ZW5zZW5Ac29yZW5zb24uY29tPiBvciBieSB0ZWxlcGhvbmUgYXQgKzEgKDgwMSkgMjg3LTk0 MTksIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2ht ZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBzYXZpbmcgdGhlbSB0byBkaXNrLg0KDQpGcm9t OiBSdW0gPHJ1bS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NClNl bnQ6IEZyaWRheSwgRGVjZW1iZXIgNCwgMjAyMCA4OjAxIEFNDQpUbzogSmFtZXMgSGFtbGluIDxq YW1lcy5oYW1saW5AcHVycGxlLnVzPg0KQ2M6IHJ1bUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtS dW1dIFByb3Bvc2VkIFNvbHV0aW9uIGZvciBDb25maWd1cmF0aW9uDQoNCltFWFRFUk5BTF0gSmFt ZXMNCg0KVGhhbmtzIGZvciB0aGUgY29tbWVudC4gIEkgdGhpbmsgeW91IGFyZSByaWdodC4gIFRo ZXJlIGlzIGEgdHJhZGVvZmYgb2YgaG93IG11Y2ggbWVjaGFuaXNtIHByb3ZpZGVycyB3aWxsIHN1 cHBseSB2cyBtYW5hZ2luZyB0aGUgbGlzdC4gIElmIHByb3ZpZGVycyB3ZXJlIHdpbGxpbmcgdG8g cmV0dXJuIGFuIG9iamVjdCB0byBhbnkgcXVlcmllciBvbiwgc2F5LCBhIOKAnHdlbGwga25vd27i gJ0gVVJMIGluIHRoZSBkb21haW4gY29udGFpbmVkIGluIHRoZSBjZW50cmFsIGxpc3QsIHRoZW4s IGFzIHlvdSBzdWdnZXN0LCBhbGwgd2UgbmVlZCBpcyB0aGUgZGlzcGxheSBuYW1lIGFuZCB0aGF0 IGRvbWFpbi4NCg0KRGVmaW5pdGVseSB3aWxsaW5nIHRvIHdyaXRlIHRoZSB0ZXh0IHRoYXQgd2F5 Lg0KDQpCcmlhbg0KDQoNCg0KT24gRGVjIDQsIDIwMjAsIGF0IDk6NTggQU0sIEphbWVzIEhhbWxp biA8amFtZXMuaGFtbGluQHB1cnBsZS51czxtYWlsdG86amFtZXMuaGFtbGluQHB1cnBsZS51cz4+ IHdyb3RlOg0KDQpCcmlhbg0KDQpKdXN0IG9uZSBzbWFsbCBwb2ludDogaXQgd291bGQgYmUgZ29v ZCB0byBrZWVwIHRoZSBhbW91bnQgb2YgZGF0YSBpbiBhbnkgY2VudHJhbGx5IG1hbmFnZWQgbGlz dCB0byBhIG1pbmltdW0uIEEgbGlzdCBvZiBQcm92aWRlciBuYW1lcyBhbmQgZG9tYWlucyBuYW1l cywgd291bGQgYmUgZW5vdWdoIGZvciB0aGUgUlVNIFJVRSB0byBkaXNwbGF5IGEgbGlzdCBvZiBw cm92aWRlcnMgdG8gdGhlIHVzZXIgYW5kIHRvIGdvIHRvIHRoZSBwcm92aWRlcidzIGRvbWFpbnMg dG8gZ2V0IGZ1cnRoZXIgaW5mb3JtYXRpb24uIENlbnRyYWxseSBtYW5hZ2VkIGRhdGEgd2lsbCBh bHdheXMgY2F1c2UgYW4gYWRtaW5pc3RyYXRpdmUgaGVhZGFjaGUuDQoNCkJlc3QgcmVnYXJkcw0K DQpKYW1lcw0KDQoNCg0KSmFtZXMgSGFtbGluDQpDb250cmFjdG9yDQpQdXJwbGUsIGEgRGl2aXNp b24gb2YgWlAgQmV0dGVyIFRvZ2V0aGVyLCBMTEMNCnB1cnBsZXZycy5jb208aHR0cDovL3B1cnBs ZXZycy5jb20vPg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIGUtbWFpbCBtZXNz YWdlIGlzIGludGVuZGVkDQpvbmx5IGZvciB0aGUgcGVyc29uYWwgYW5kIGNvbmZpZGVudGlhbCB1 c2Ugb2YgdGhlIHJlY2lwaWVudChzKQ0KbmFtZWQgYWJvdmUuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwNCnBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRl bHkgYnkgZS1tYWlsLCBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbA0KbWVzc2FnZS4NCg0KDQoNCg0K DQoNCg0KDQpGcm9tOiBCcmlhbiBSb3NlbiA8YnJAYnJpYW5yb3Nlbi5uZXQ8bWFpbHRvOmJyQGJy aWFucm9zZW4ubmV0Pj4NCg0KTWVzc2FnZS1JZDogPEQ0MzQxMTFGLThDOEYtNDBBQy1CQUM3LURG QTg2MTZGNEZBOEBicmlhbnJvc2VuLm5ldDxtYWlsdG86RDQzNDExMUYtOEM4Ri00MEFDLUJBQzct REZBODYxNkY0RkE4QGJyaWFucm9zZW4ubmV0Pj4NCg0KRGF0ZTogVGh1LCAzIERlYyAyMDIwIDEy OjI1OjI3IC0wNTAwDQoNClRvOiBydW1AaWV0Zi5vcmc8bWFpbHRvOnJ1bUBpZXRmLm9yZz4NCg0K U3ViamVjdDogW1J1bV0gUHJvcG9zZWQgU29sdXRpb24gZm9yIENvbmZpZ3VyYXRpb24NCg0KTGlz dC1JZDogUmVsYXkgVXNlciBNYWNoaW5lIDxydW0uaWV0Zi5vcmc8aHR0cDovL3J1bS5pZXRmLm9y Zy8+Pg0KDQpMaXN0LVBvc3Q6IDxtYWlsdG86cnVtQGlldGYub3JnPg0KDQpTZW5kZXI6ICJSdW0i IDxydW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cnVtLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KDQpP bGxlIHdpbGwgaGF2ZSBhbiBhbHRlcm5hdGl2ZSBwcm9wb3NhbCwgaGVyZSBpcyBtaW5lLg0KDQpJ IHN0YXJ0IHdpdGggdGhlIHByb3ZpZGVyIGxpc3QuICBUaGVyZSBpcyBhIGxpc3Qgb2YgcHJvdmlk ZXJzIHBlciBjb3VudHJ5LiAgVGhlcmUgaXMgYW4gSUFOQSByZWdpc3RyeSB0aGF0IGhhcyBhIGNv dW50cnkgY29kZSBhbmQgYSBVUkwgdG8gZ2V0IHRoYXQgbGlzdC4NCg0KVGhlIGxpc3QgaGFzIGFu IGVudHJ5IHBlciBwcm92aWRlci4gIFRoZSBlbnRyeSBoYXMgc2V0cyBvZiBkYXRhIG9iamVjdHMs IG9uZSBzZXQgcGVyIGxhbmd1YWdlIHN1cHBvcnRlZC4gIEVhY2ggc2V0IGlzIGFuIG9iamVjdCB3 aXRoIEluYW1lIGZvciB0aGUgcHJvdmlkZXIsIGEgVVJMIGZvciBpdHMgY29uZmlndXJhdGlvbiBz ZXJ2aWNlLCBhIFVSTCBmb3IgaXRzIGN1c3RvbWVyIHNpZ24gdXAgc2VydmljZSwgYSBVUkwgZm9y IGEgaGVscCBkZXNrLCBhbmQgYSBTSVAgVVJJIGZvciBhIGRpYWwgYXJvdW5kIGZyb250IGRvb3Iu DQoNCkEgdXNlciBzdGFydHMgd2l0aCB0aGUgc2lnbiB1cCBzZXJ2aWNlLCB3aGljaCB1c2VzIGEg YnJvd3Nlci4gIFRoZSByZXN1bHQgaXMgYSB1c2VybmFtZS9wYXNzd29yZCBmb3IgdGhlIGFjY291 bnQuDQoNClRoZSBSVUUgaGFzIGFuIGFkbWluaXN0cmF0aXZlIGFjY291bnQsIHdoaWNoIGl0IG1h aW50YWlucyBsb2NhbGx5LiAgVGhlcmUgaXMgYSB1c2VybmFtZSBhbmQgcGFzc3dvcmQgZm9yIHRo YXQuICBUaGUgUlVFIHN0b3JlcyB0aGUgVVJMcyBmb3IgYSBwcm92aWRlciBjb25maWd1cmF0aW9u IHNlcnZpY2UsIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBsb2NhbGx5LiAgT25seSBhIHVzZXIgd2l0 aCB0aGUgYWRtaW5pc3RyYXRpdmUgdXNlcm5hbWUvcGFzc3dvcmQgY2FuIHNlZSBvciBjaGFuZ2Ug dGhlIGRhdGEuDQoNCldoZW4gdGhlIFJVRSByZXN0YXJ0cyBmb3IgYW55IHJlYXNvbiwgb3IgZm9s bG93aW5nIGEgY2hhbmdlIGluIHVzZXJuYW1lL3Bhc3N3b3JkLCBpdCBjb25uZWN0cyB0byB0aGUg Y29uZmlndXJhdGlvbiBzZXJ2aWNlIHZpYSBIVFRQUywgYXV0aGVudGljYXRlcyB3aXRoIHVzZXJu YW1lL3Bhc3N3b3JkIGFuZCBwcm92aWRlcyB0aGUgQVBJIEtleS4gIElmIHRoZSBBUEkgS2V5IGlz IGdvb2QsIHRoZSBjb25maWd1cmF0aW9uIHNlcnZpY2UgcmVzcG9uZHMgd2l0aCBhbGwgb2YgdGhl IHNlcnZlciBpbmZvcm1hdGlvbiAoUmVnaXN0cmFyLCBvdXRib3VuZCBwcm94eSwgVFVSTiBzZXJ2 ZXIsIOKApikgZm9yIHRoYXQgdXNlci4NCg0KVGhlIFJVRSB0aGVuIGNvbmZpZ3VyZXMgZm9yIHRo YXQgcHJvdmlkZXIsIFJFR0lTVEVScyB3aXRoIHRoZSBzdG9yZWQgdXNlcm5hbWUgYW5kIHBhc3N3 b3JkLCBhbmQgaXMgdGhlbiByZWFkeSB0byBwbGFjZSBvciByZWNlaXZlIGNhbGxzLg0KDQpJ4oCZ bSB0aGlua2luZyBhYm91dCBzb21lIGNsZXZlcm5lc3Mgd2hlcmUgaWYgdGhlIFJVRSBwcm92aWRl cyB0aGUgYnJvd3NlciB0aGF0IGlzIHVzZWQgdG8gc2lnbiB1cCwgcGVyaGFwcyB0aGVyZSBpcyBh IHNlY3VyZSB3YXkgZm9yIHRoZSBwcm92aWRlciB0byBkb3dubG9hZCB1c2VybmFtZS9wYXNzd29y ZCBzbyBpdCBjYW4gYmUgbG9jYWxseSBzdG9yZWQgYXMgYWJvdmUsIHNvIHRoZSB1c2VyIGRvZXNu 4oCZdCBoYXZlIHRvIGVudGVyIGl0IGludG8gdGhlIFJVRS4NCg0KQnJpYW4NCg0KDQoNCg== --_000_BYAPR04MB4983A128C87204E2053DF21DA3CC0BYAPR04MB4983namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5hcHBsZS1j b252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30N CnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxz byBhZ3JlZSB3aXRoIEphbWVzIOKAnDxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij50byBr ZWVwIHRoZSBhbW91bnQgb2YgZGF0YSBpbiBhbnkgY2VudHJhbGx5IG1hbmFnZWQgbGlzdCB0byBh IG1pbmltdW3igJ0uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOm5hdnkiPkNPTkZJREVOVElBTElUWSBOT1RJQ0UuPC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6bmF2eSI+IFRoaXMgZS1tYWlsIHRyYW5zbWlzc2lvbiwgYW5kIGFu eSBkb2N1bWVudHMsIGZpbGVzIG9yDQogcHJldmlvdXMgZS1tYWlsIG1lc3NhZ2VzIGF0dGFjaGVk IHRvIGl0LCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgYW5kIHByb3ByaWV0YXJ5IGluZm9ybWF0 aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBvciBhIHBlcnNvbiBy ZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyBpdCB0byB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNjbG9zdXJlLCBjb3B5aW5nLA0KIGRp c3RyaWJ1dGlvbiBvciB1c2Ugb2YgYW55IG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4g b3IgYXR0YWNoZWQgdG8gdGhpcyBtZXNzYWdlIGlzIFNUUklDVExZIFBST0hJQklURUQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRp YXRlbHkgbm90aWZ5IG1lIGJ5IHJlcGx5IGUtbWFpbCBhdA0KPC9zcGFuPjxhIGhyZWY9Im1haWx0 bzplY2hyaXN0ZW5zZW5Ac29yZW5zb24uY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPmVjaHJpc3RlbnNlbkBz b3JlbnNvbi5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpuYXZ5Ij4gb3IgYnkgdGVs ZXBob25lIGF0ICsxICg4MDEpIDI4Ny05NDE5LA0KIGFuZCBkZXN0cm95IHRoZSBvcmlnaW5hbCB0 cmFuc21pc3Npb24gYW5kIGl0cyBhdHRhY2htZW50cyB3aXRob3V0IHJlYWRpbmcgdGhlbSBvciBz YXZpbmcgdGhlbSB0byBkaXNrLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjguMHB0Ij48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBSdW0gJmx0O3J1bS1ib3VuY2VzQGlldGYub3Jn Jmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KQnJpYW4gUm9zZW48YnI+DQo8Yj5TZW50OjwvYj4g RnJpZGF5LCBEZWNlbWJlciA0LCAyMDIwIDg6MDEgQU08YnI+DQo8Yj5Ubzo8L2I+IEphbWVzIEhh bWxpbiAmbHQ7amFtZXMuaGFtbGluQHB1cnBsZS51cyZndDs8YnI+DQo8Yj5DYzo8L2I+IHJ1bUBp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1J1bV0gUHJvcG9zZWQgU29sdXRpb24g Zm9yIENvbmZpZ3VyYXRpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPltFWFRFUk5BTF08L3NwYW4+Jm5ic3A7SmFtZXM8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3IgdGhl IGNvbW1lbnQuICZuYnNwO0kgdGhpbmsgeW91IGFyZSByaWdodC4gJm5ic3A7VGhlcmUgaXMgYSB0 cmFkZW9mZiBvZiBob3cgbXVjaCBtZWNoYW5pc20gcHJvdmlkZXJzIHdpbGwgc3VwcGx5IHZzIG1h bmFnaW5nIHRoZSBsaXN0LiAmbmJzcDtJZiBwcm92aWRlcnMgd2VyZSB3aWxsaW5nIHRvIHJldHVy biBhbiBvYmplY3QgdG8gYW55IHF1ZXJpZXIgb24sIHNheSwgYSDigJx3ZWxsIGtub3du4oCdIFVS TCBpbiB0aGUgZG9tYWluDQogY29udGFpbmVkIGluIHRoZSBjZW50cmFsIGxpc3QsIHRoZW4sIGFz IHlvdSBzdWdnZXN0LCBhbGwgd2UgbmVlZCBpcyB0aGUgZGlzcGxheSBuYW1lIGFuZCB0aGF0IGRv bWFpbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RGVmaW5pdGVseSB3aWxsaW5nIHRvIHdyaXRlIHRoZSB0ZXh0IHRoYXQgd2F5LjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CcmlhbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBEZWMgNCwgMjAy MCwgYXQgOTo1OCBBTSwgSmFtZXMgSGFtbGluICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMuaGFt bGluQHB1cnBsZS51cyI+amFtZXMuaGFtbGluQHB1cnBsZS51czwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Ccmlh bjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i YmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkp1c3Qgb25lIHNtYWxsIHBvaW50OiBpdCB3b3VsZCBiZSBnb29kIHRvIGtlZXAgdGhlIGFt b3VudCBvZiBkYXRhIGluIGFueSBjZW50cmFsbHkgbWFuYWdlZCBsaXN0IHRvIGEgbWluaW11bS4g QSBsaXN0IG9mIFByb3ZpZGVyIG5hbWVzIGFuZCBkb21haW5zIG5hbWVzLCB3b3VsZCBiZSBlbm91 Z2gNCiBmb3IgdGhlIFJVTSBSVUUgdG8gZGlzcGxheSBhIGxpc3Qgb2YgcHJvdmlkZXJzIHRvIHRo ZSB1c2VyIGFuZCB0byBnbyB0byB0aGUgcHJvdmlkZXIncyBkb21haW5zIHRvIGdldCBmdXJ0aGVy IGluZm9ybWF0aW9uLiBDZW50cmFsbHkgbWFuYWdlZCBkYXRhIHdpbGwgYWx3YXlzIGNhdXNlIGFu IGFkbWluaXN0cmF0aXZlIGhlYWRhY2hlLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkJlc3QgcmVnYXJkczwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkphbWVzPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9IlNpZ25hdHVyZSI+DQo8ZGl2IG5h bWU9ImRpdnRhZ2RlZmF1bHR3cmFwcGVyIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+SmFtZXMgSGFtbGluPGJyPg0KQ29udHJhY3Rvcjxicj4NClB1cnBsZSwgYSBEaXZpc2lvbiBv ZiBaUCBCZXR0ZXIgVG9nZXRoZXIsIExMQzxicj4NCjxhIGhyZWY9Imh0dHA6Ly9wdXJwbGV2cnMu Y29tLyI+cHVycGxldnJzLmNvbTwvYT48YnI+DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlu IHRoaXMgZS1tYWlsIG1lc3NhZ2UgaXMgaW50ZW5kZWQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0Kb25seSBmb3IgdGhlIHBlcnNvbmFsIGFuZCBj b25maWRlbnRpYWwgdXNlIG9mIHRoZSByZWNpcGllbnQocyk8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KbmFtZWQgYWJvdmUuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciw8c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5wbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbCwg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+bWVzc2FnZS48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJh Y2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBz dHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiBC cmlhbiBSb3NlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyQGJyaWFucm9zZW4ubmV0Ij5ickBicmlh bnJvc2VuLm5ldDwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJi YWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk1lc3NhZ2UtSWQ6ICZs dDs8YSBocmVmPSJtYWlsdG86RDQzNDExMUYtOEM4Ri00MEFDLUJBQzctREZBODYxNkY0RkE4QGJy aWFucm9zZW4ubmV0Ij5ENDM0MTExRi04QzhGLTQwQUMtQkFDNy1ERkE4NjE2RjRGQThAYnJpYW5y b3Nlbi5uZXQ8L2E+Jmd0Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0iYmFj a2dyb3VuZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EYXRlOiBUaHUsIDMgRGVj IDIwMjAgMTI6MjU6MjcgLTA1MDA8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9 ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VG86IDxhIGhyZWY9 Im1haWx0bzpydW1AaWV0Zi5vcmciPnJ1bUBpZXRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48 L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+U3ViamVjdDogW1J1bV0gUHJvcG9zZWQgU29sdXRpb24gZm9yIENvbmZpZ3VyYXRpb248 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+TGlzdC1JZDogUmVsYXkgVXNlciBNYWNoaW5lICZsdDs8 YSBocmVmPSJodHRwOi8vcnVtLmlldGYub3JnLyI+cnVtLmlldGYub3JnPC9hPiZndDs8L3NwYW4+ PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+TGlzdC1Qb3N0OiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJ1bUBpZXRm Lm9yZyI+bWFpbHRvOnJ1bUBpZXRmLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlNlbmRlcjogJnF1b3Q7UnVtJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cnVtLWJvdW5jZXNA aWV0Zi5vcmciPnJ1bS1ib3VuY2VzQGlldGYub3JnPC9hPiZndDs8YnI+PGJyPk9sbGUgd2lsbCBo YXZlIGFuIGFsdGVybmF0aXZlIHByb3Bvc2FsLCBoZXJlIGlzIG1pbmUuPGJyPjxicj5JIHN0YXJ0 IHdpdGggdGhlIHByb3ZpZGVyIGxpc3QuJm5ic3A7IFRoZXJlIGlzIGEgbGlzdCBvZiBwcm92aWRl cnMgcGVyIGNvdW50cnkuJm5ic3A7IFRoZXJlIGlzIGFuIElBTkEgcmVnaXN0cnkgdGhhdCBoYXMg YSBjb3VudHJ5IGNvZGUgYW5kIGEgVVJMIHRvIGdldCB0aGF0IGxpc3QuPGJyPjxicj5UaGUgbGlz dCBoYXMgYW4gZW50cnkgcGVyIHByb3ZpZGVyLiZuYnNwOyBUaGUgZW50cnkgaGFzIHNldHMgb2Yg ZGF0YSBvYmplY3RzLCBvbmUgc2V0IHBlciBsYW5ndWFnZSBzdXBwb3J0ZWQuJm5ic3A7IEVhY2gg c2V0IGlzIGFuIG9iamVjdCB3aXRoIEluYW1lIGZvciB0aGUgcHJvdmlkZXIsIGEgVVJMIGZvciBp dHMgY29uZmlndXJhdGlvbiBzZXJ2aWNlLCBhIFVSTCBmb3IgaXRzIGN1c3RvbWVyIHNpZ24gdXAg c2VydmljZSwgYSBVUkwgZm9yIGEgaGVscCBkZXNrLCBhbmQgYSBTSVAgVVJJIGZvciBhIGRpYWwg YXJvdW5kIGZyb250IGRvb3IuJm5ic3A7IDxicj48YnI+QSB1c2VyIHN0YXJ0cyB3aXRoIHRoZSBz aWduIHVwIHNlcnZpY2UsIHdoaWNoIHVzZXMgYSBicm93c2VyLiZuYnNwOyBUaGUgcmVzdWx0IGlz IGEgdXNlcm5hbWUvcGFzc3dvcmQgZm9yIHRoZSBhY2NvdW50LiZuYnNwOyA8YnI+PGJyPlRoZSBS VUUgaGFzIGFuIGFkbWluaXN0cmF0aXZlIGFjY291bnQsIHdoaWNoIGl0IG1haW50YWlucyBsb2Nh bGx5LiZuYnNwOyBUaGVyZSBpcyBhIHVzZXJuYW1lIGFuZCBwYXNzd29yZCBmb3IgdGhhdC4mbmJz cDsgVGhlIFJVRSBzdG9yZXMgdGhlIFVSTHMgZm9yIGEgcHJvdmlkZXIgY29uZmlndXJhdGlvbiBz ZXJ2aWNlLCB1c2VybmFtZSBhbmQgcGFzc3dvcmQgbG9jYWxseS4mbmJzcDsgT25seSBhIHVzZXIg d2l0aCB0aGUgYWRtaW5pc3RyYXRpdmUgdXNlcm5hbWUvcGFzc3dvcmQgY2FuIHNlZSBvciBjaGFu Z2UgdGhlIGRhdGEuPGJyPjxicj5XaGVuIHRoZSBSVUUgcmVzdGFydHMgZm9yIGFueSByZWFzb24s IG9yIGZvbGxvd2luZyBhIGNoYW5nZSBpbiB1c2VybmFtZS9wYXNzd29yZCwgaXQgY29ubmVjdHMg dG8gdGhlIGNvbmZpZ3VyYXRpb24gc2VydmljZSB2aWEgSFRUUFMsIGF1dGhlbnRpY2F0ZXMgd2l0 aCB1c2VybmFtZS9wYXNzd29yZCBhbmQgcHJvdmlkZXMgdGhlIEFQSSBLZXkuJm5ic3A7IElmIHRo ZSBBUEkgS2V5IGlzIGdvb2QsIHRoZSBjb25maWd1cmF0aW9uIHNlcnZpY2UgcmVzcG9uZHMgd2l0 aCBhbGwgb2YgdGhlIHNlcnZlciBpbmZvcm1hdGlvbiAoUmVnaXN0cmFyLCBvdXRib3VuZCBwcm94 eSwgVFVSTiBzZXJ2ZXIsIOKApikgZm9yIHRoYXQgdXNlci48YnI+PGJyPlRoZSBSVUUgdGhlbiBj b25maWd1cmVzIGZvciB0aGF0IHByb3ZpZGVyLCBSRUdJU1RFUnMgd2l0aCB0aGUgc3RvcmVkIHVz ZXJuYW1lIGFuZCBwYXNzd29yZCwgYW5kIGlzIHRoZW4gcmVhZHkgdG8gcGxhY2Ugb3IgcmVjZWl2 ZSBjYWxscy48YnI+PGJyPknigJltIHRoaW5raW5nIGFib3V0IHNvbWUgY2xldmVybmVzcyB3aGVy ZSBpZiB0aGUgUlVFIHByb3ZpZGVzIHRoZSBicm93c2VyIHRoYXQgaXMgdXNlZCB0byBzaWduIHVw LCBwZXJoYXBzIHRoZXJlIGlzIGEgc2VjdXJlIHdheSBmb3IgdGhlIHByb3ZpZGVyIHRvIGRvd25s b2FkIHVzZXJuYW1lL3Bhc3N3b3JkIHNvIGl0IGNhbiBiZSBsb2NhbGx5IHN0b3JlZCBhcyBhYm92 ZSwgc28gdGhlIHVzZXIgZG9lc27igJl0IGhhdmUgdG8gZW50ZXIgaXQgaW50byB0aGUgUlVFLjxi cj48YnI+QnJpYW48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR04MB4983A128C87204E2053DF21DA3CC0BYAPR04MB4983namp_--