From nobody Tue Jul 9 12:48:08 2019 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 9E3241206AC for ; Tue, 9 Jul 2019 12:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.592 X-Spam-Level: X-Spam-Status: No, score=-0.592 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFhSvZGYrgY3 for ; Tue, 9 Jul 2019 12:48:05 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D702C12068C for ; Tue, 9 Jul 2019 12:48:04 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id t8so80457qkt.1 for ; Tue, 09 Jul 2019 12:48:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=CMgUUMwLmiIe2d1YREc3mUKnOVOsfPuImtMTTUmSqtI=; b=tRi7kYNDRU+RKXzSMK6XBSBERbmetdY8hZV7LgPETbA2U8j/rjb9W0/JMM+Qgh9dAR 7nouQWe0Z1TxTed4bBBQFBbumnfauvl1m8uM+TdPLuXhGBTNZLztCLrVRptL61QulIef ++tMpHI2Vg+/iBb18osSIlFCpeEZ+YuGGDDHrApSUofnpdGrqtFR5JvWOblVMsHXO/AB +taaWL1SxTDtfiEkx4tmMngigg50ZlBBhI6XRUVfugLlL0Ski2iOjG2IpVe7QpicMsTn ApoGUfSDo9f6dGhpwkeMyLhLyMjUWAWHKQX5lvhAu7VknSDqjF+r8OTxv8ZAmfOJQcSz 9YTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=CMgUUMwLmiIe2d1YREc3mUKnOVOsfPuImtMTTUmSqtI=; b=omm50JZdt+DqQy2CEoVGUeHjOSVwQHsCfucJnhQmH86gXh0EYC+6YPh78wX/+p8HG9 uye+/9jhDyq3E8fT4JaVGhyR1uOdlpZ9REJw5YfzeTnJC69IIihyeIT42daXPmtk0I7M V1YXtJWEAGjsEMpV5jaVn57gKYq3+0Z1/BNgaxh2rd4V+295Bbx37Wf8Wy2Ieueo2/vn 0TzguiER0vfqVfCoMTgGd4bzgO4/nJ4aSVM5OziuVHN2867rwHJ7dvfML9Z36hqRqgIn mpSxK6pE/bFTroWkWpyeEMqqwR4Xq2g7sPdzwrRroplKKLHyipNrnZ4wJgLrvkfqBgen OU1g== X-Gm-Message-State: APjAAAUJmS4qBcvTZXA3dDa+gzmGDuhL6JCo4r1qpJHun+g1HpdWOEhM F0mHR0JcNZbdb1w6F6dc7oWGszkPlyk= X-Google-Smtp-Source: APXvYqyHLCK3utfBGmNkEN3UroieiBlUpQJQar+bNv4umSy2CeuIYwvauEibnyKny7zyjIy63Ron9g== X-Received: by 2002:a37:2e07:: with SMTP id u7mr20002904qkh.383.1562701683772; Tue, 09 Jul 2019 12:48:03 -0700 (PDT) Received: from brians-mbp-2264.lan (dynamic-acs-24-101-114-50.zoominternet.net. [24.101.114.50]) by smtp.gmail.com with ESMTPSA id 6sm1036705qkp.82.2019.07.09.12.48.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 12:48:03 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_0FFB5851-21E7-4F1D-B5E7-D91BAE3E5AF5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> Date: Tue, 9 Jul 2019 15:48:01 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Rum] Let's get into it X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2019 19:48:07 -0000 --Apple-Mail=_0FFB5851-21E7-4F1D-B5E7-D91BAE3E5AF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please read https://tools.ietf.org/html/draft-rosen-rue-00 = Please comment on anything. I will propose we adopt this as the basis = of our work, but I=E2=80=99m happy to do anything on it before hand. If it is adopted, chairs will appoint a non-chair editor. One specific I know about: The charter discusses re-using the WebRTC media specs. The most direct = way to do that is reference: For media and media transport: https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17 = https://tools.ietf.org/html/rfc7874 = https://tools.ietf.org/html/rfc7742 = https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17 = For issues around media security: https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.1 = = https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#section-6.5= = Paul K made a suggestion that there were the SIP/MMUSIC documents done = or in progress that are themselves intended to be compatible with = WebRTC. Preferences? Brian --Apple-Mail=_0FFB5851-21E7-4F1D-B5E7-D91BAE3E5AF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please read https://tools.ietf.org/html/draft-rosen-rue-00

Please comment on = anything.  I will propose we adopt this as  the basis of our = work, but I=E2=80=99m happy to do anything on it before hand.
If it is adopted, chairs will appoint a non-chair = editor.

One = specific I know about:

The charter discusses re-using the WebRTC media specs. =  The most direct way to do that is reference:
For media and media transport:

https://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-17<= br class=3D"">https://tools.ietf.org/html/rfc7874
https://tools.ietf.org/html/rfc7742
https://tools.ietf.org/html/draft-ietf-rtcweb-transports-17=

For issues around media security:
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5= .1
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-18#= section-6.5


Paul K made a suggestion that there = were the SIP/MMUSIC documents done or in progress that are themselves = intended to be compatible with WebRTC.

Preferences?

Brian

= --Apple-Mail=_0FFB5851-21E7-4F1D-B5E7-D91BAE3E5AF5-- From nobody Wed Jul 10 03:28:36 2019 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 CEDB112011A for ; Wed, 10 Jul 2019 03:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q7wGNTRafr-J for ; Wed, 10 Jul 2019 03:28:30 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1D1120099 for ; Wed, 10 Jul 2019 03:28:29 -0700 (PDT) Received: from [192.168.1.80] (static-212-247-19-62.cust.tele2.se [212.247.19.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 15A32A40; Wed, 10 Jul 2019 12:28:26 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_52F0934B-C0F9-47CB-8AB1-2AE32245BA6B" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 10 Jul 2019 12:28:25 +0200 In-Reply-To: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> Cc: Olle E Johansson , rum@ietf.org To: Brian Rosen References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] Let's get into it 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, 10 Jul 2019 10:28:34 -0000 --Apple-Mail=_52F0934B-C0F9-47CB-8AB1-2AE32245BA6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 9 Jul 2019, at 21:48, Brian Rosen wrote: >=20 > Please comment on anything. Section 5: "Both HTTPS and all SIP Transactions MUST use TLS 1.2=E2=80=9D =E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well here. = =E2=80=9CConnections=E2=80=9D would be better. Instead of hard-coding a specific version of TLS you may want to point = to the BCP by the UTA wg, unless you anyway will update this profile from time to time. " During the establishment of secure connections with a provider, the RUE MAY be asked by the server for a client certificate. In that case it SHOULD provide a client certificate. Providers MAY reject requests that fail to provide a recognized certificate.=E2=80=9D What=E2=80=99s in the client cert? How do you validate the client certs? Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume that = would apply. Since you are using phone numbers as identifiers, I from an EU = standpoint suggest disallowing all non-secure transports. Phone numbers are=20 considered personal identifiers and are affected by the EU GDPR. Section 6.2.1 forbids Route headers in initial INVITE requests. The = example in 6.2.2 has a very visible Route: header in the initial request. Section 6.2.3 talks about an xCard without any references or comments about trust for that information. Section 6.2.4: "The RUE MUST accept inbound calls sent to it by the proxy mentioned in the configuration.=E2=80=9D The proxy is found using DNS and may be a list created from NATPR/DNS = SRV records. What is the defintion of =E2=80=9Cthe proxy=E2=80=9D in this = statement? "If Multiple simultaneous RUE SIP registrations from different RUE devices with the same SIP URI exist, the Provider MUST parallel fork = the call to all registered RUEs so that they ring at the same time. The first RUE to reply with a 200 OK answers the call and the Provider MUST CANCEL other call branches. " Is this normative (you have many MUST here). If so - how does this change the behaviour of RFC 3261? Also, I think this texts forgets about SIP outbound. Since Outbound is a = MUST, you need to clarify the mix of parallell and serial forking that will = happen. Section 6.3: "The RUE MUST support REFER to enable call transfer.=E2=80=9C Which combination of REFER? I assume that =E2=80=9CMid call signaling=E2=80= =9D is =E2=80=9Cin-dialog transactions=E2=80=9D in SIP lingo, but REFER with or without Replaces? With or without subscription for = updates? Section 6.4: " Relay Service URIs and User Address of Records (AoR) MUST resolve (in accord with [RFC3263 ]) to = globally routable IPv4 addresses. The AoRs MAY also resolve to IPv6 addresses.=E2=80=9D How do you resolve a complete URI into an IP address? I guess you mean the domain part that resolves to a list of addresses using DNS. Why is IPv4 a MUST? Section 8: "All media streams between the RUE and another endpoint or relay Provider MUST be exchanged using the secure real-time transport protocol (SRTP) [RFC3550 ] using = DTLS [RFC5763 ], [RFC5764 = ], except that for backwards compatibility with older video endpoints, RTP MAY be negotiated if SRTP negotiation fails. =E2=80=9C How do you handle the risk of downgrade attacks here? That exception is = dangerous and maybe should be handled elsewhere, not in the client.=20 Section 11.1 The example operator URI for red.example.net = seems to lack =E2=80=9C;user=3Ddialstring=E2=80=9D Section 11.2 "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be used when sending requests to the Provider. Multiple URIs identify alternative (redundant) paths to the Provider. =E2=80=9C Outbound proxy is of course something you look up in DNS to get the list = of actual servers. Is there a need to have an additional list in this json = format? " ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t remember = seeing =E2=80=9Cice server=E2=80=9D as a term. As turn servers are also STUN servers, I think =E2=80=9Cturn-servers=E2=80= =9D is better. =E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this, even if it=E2=80=99s over HTTPS is an interesting approach in this age = and time. Regardless of that, make sure you consider OAuth/OpenID connect auth for some services. =E2=80=9Clifetime=E2=80=9D:; You are really not clear on what happens = when the configuration expires. Is the RUE forbidden to use anything here? What about emergency = calls - will they work even without configuration? General: You do not mention bundling of RTP streams, which may be beneficial = here. Good work! /O --Apple-Mail=_52F0934B-C0F9-47CB-8AB1-2AE32245BA6B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 9 Jul 2019, at 21:48, Brian Rosen <br@brianrosen.net> = wrote:

Please comment on = anything.

Section = 5:

"Both HTTPS and all SIP Transactions = MUST use TLS 1.2=E2=80=9D
<= div class=3D"">
=E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well = here. =E2=80=9CConnections=E2=80=9D would be = better.
Instead = of hard-coding a specific version of TLS you may want to point to the = BCP by the UTA wg,
unless you anyway will update this profile from time to = time.

" During the establishment of secure connections with a = provider, the
   RUE MAY be asked by the server for a client certificate.  In =
that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.=E2=80=9D
<= pre class=3D"newpage" style=3D"font-size: 13.333333015441895px; = margin-top: 0px; margin-bottom: 0px; break-before: page;">
What=E2=80=99s in the client cert? How do you validate the client =
certs?

Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume =
that would apply.


Since you are using phone numbers as identifiers, I from an EU =
standpoint
suggest disallowing all non-secure transports. Phone numbers are =

considered =
personal identifiers and are affected by the EU GDPR.


Section 6.2.1 forbids =
Route headers in initial INVITE requests. The example
in 6.2.2 has a very =
visible Route: header in the initial request.

Section 6.2.3 talks about =
an xCard without any references or comments
about trust for that =
information.

Section 6.2.4:

"The RUE MUST accept inbound calls sent to it by the proxy =
mentioned
   in the configuration.=E2=80=9D

The proxy is found using =
DNS and may be a list created from NATPR/DNS SRV
records. What is the =
defintion of =E2=80=9Cthe proxy=E2=80=9D in this statement?

"If Multiple simultaneous =
RUE SIP registrations from different RUE
   devices with the same SIP =
URI exist, the Provider MUST parallel fork   the call to all registered =
RUEs so that they ring at the same time.

   The first =
RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.
"
Is this normative (you have many MUST here). If so - how does =
this
change the behaviour of RFC 3261?
Also, I think this texts =
forgets about SIP outbound. Since Outbound is a MUST,
you need to clarify the =
mix of parallell and serial forking that will happen.


Section 6.3:

"The RUE MUST support   =
REFER to enable call transfer.=E2=80=9C

Which combination of REFER? I assume = that =E2=80=9CMid call signaling=E2=80=9D is =E2=80=9Cin-dialog = transactions=E2=80=9D in SIP lingo,
but REFER with = or without Replaces? With or without subscription for updates?

Section 6.4:

" Relay Service URIs and User Address = of Records (AoR) MUST resolve (in
   accord with [RFC3263]) to globally routable IPv4 addresses.  The AoRs
   MAY also resolve to IPv6 addresses.=E2=80=9D

How do you resolve a =
complete URI into an IP address? I guess you mean
the domain part that =
resolves to a list of addresses using DNS.
Why is IPv4 a MUST?

Section 8:

"All media streams between =
the RUE and another endpoint or relay
   Provider MUST be exchanged =
using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.
=E2=80=9C

How do you handle the risk of downgrade attacks here? That = exception is dangerous
and maybe should be handled = elsewhere, not in the client. 


Section 11.1

The example operator URI for red.example.net seems to lack = =E2=80=9C;user=3Ddialstring=E2=80=9D

Section 11.2

"outbound-proxies: (OPTIONAL) A list of = URIs of SIP proxies to be
      used when sending =
requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.
=E2=80=9C

Outbound proxy is of course something you look up in DNS to = get the list of
actual servers. Is there a need to = have an additional list in this json format?

" = ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t remember = seeing =E2=80=9Cice server=E2=80=9D as a term.
As turn servers are also STUN = servers, I think =E2=80=9Cturn-servers=E2=80=9D is = better.

=E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending = credentials in clear text like this,
even if it=E2=80=99s over HTTPS is an interesting = approach in this age and time.
Regardless of that, make sure you consider = OAuth/OpenID connect auth
for some services.

=E2=80=9Clifetime=E2=80=9D:; You are really not clear on what = happens when the configuration
expires. Is the RUE forbidden to use anything = here? What about emergency calls
- will they work even without = configuration?

General:

You do not mention bundling of = RTP streams, which may be beneficial here.

Good work!

/O





= --Apple-Mail=_52F0934B-C0F9-47CB-8AB1-2AE32245BA6B-- From nobody Mon Jul 15 02:14:36 2019 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 06AE712006E for ; Mon, 15 Jul 2019 02:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLBpg0EkvHN0 for ; Mon, 15 Jul 2019 02:14:31 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 32D4F1201B3 for ; Mon, 15 Jul 2019 02:14:31 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx11.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 09:14:24 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 Jul 2019 02:14:12 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Mon, 15 Jul 2019 02:14:12 -0700 From: James Hamlin To: "br@brianrosen.net" CC: "rum@ietf.org" Thread-Topic: [Rum] rum - Requested session has been scheduled for IETF 105 Thread-Index: AQHVOu1rxHkeTSb1r0Kay91wJh3tRw== Date: Mon, 15 Jul 2019 09:14:12 +0000 Message-ID: <1563182052810.34440@purple.us> References: <156176267487.11015.7325622691659550911.idtracker@ietfa.amsl.com> In-Reply-To: <156176267487.11015.7325622691659550911.idtracker@ietfa.amsl.com> 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: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-BESS-ID: 1563182053-893020-6038-67450-1 X-BESS-VER: 2019.1_20190708.1727 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.215966 [from cloudscan15-134.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 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=BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] rum - Requested session has been scheduled for IETF 105 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, 15 Jul 2019 09:14:34 -0000 Brian=0A= =0A= Has remote dial-in been provisioned for this meeting?=0A= =0A= Best regards=0A= =0A= James=0A= =0A= ________________________________________=0A= From: Rum on behalf of "IETF Secretariat" =0A= Sent: 28 June 2019 23:57=0A= To: rum-chairs@ietf.org; br@brianrosen.net=0A= Cc: rum@ietf.org; adam@nostrum.com=0A= Subject: [Rum] rum - Requested session has been scheduled for IETF 105=0A= =0A= Dear Brian Rosen,=0A= =0A= The session(s) that you have requested have been scheduled.=0A= Below is the scheduled session information followed by=0A= the original request.=0A= =0A= =0A= rum Session 1 (1:30 requested)=0A= Tuesday, 23 July 2019, Afternoon Session II 1520-1650=0A= Room Name: Notre Dame size: 50=0A= ---------------------------------------------=0A= =0A= =0A= iCalendar: https://datatracker.ietf.org/meeting/105/sessions/rum.ics=0A= =0A= Request Information:=0A= =0A= =0A= ---------------------------------------------------------=0A= Working Group Name: Relay User Machine=0A= Area Name: Applications and Real-Time Area=0A= Session Requester: Brian Rosen=0A= =0A= Number of Sessions: 1=0A= Length of Session(s): 1.5 Hours=0A= Number of Attendees: 20=0A= Conflicts to Avoid:=0A= First Priority: avtcore dispatch modern sipcore rtcweb ecrit=0A= Second Priority: quic mmusic=0A= =0A= =0A= =0A= People who must be present:=0A= Adam Roach=0A= Brian Rosen=0A= Paul Kyzivat=0A= =0A= Resources Requested:=0A= =0A= Special Requests:=0A= =0A= ---------------------------------------------------------=0A= =0A= --=0A= Rum mailing list=0A= Rum@ietf.org=0A= https://www.ietf.org/mailman/listinfo/rum=0A= From nobody Mon Jul 15 04:13:13 2019 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 23D8D1202AD for ; Mon, 15 Jul 2019 04:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 T9I-7o_b1jAe for ; Mon, 15 Jul 2019 04:12:57 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 873A6120186 for ; Mon, 15 Jul 2019 04:12:57 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id d23so15129424qto.2 for ; Mon, 15 Jul 2019 04:12:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LlGpKVxGB2WD0Y3ckXN3j7ONm5V6esE/TbnLRoxz3I8=; b=MhVRGpjmdBLdUDDocwwELJHCXwP9SkZHV9ks1wgCo1Ei1Nj4b8B0CBk94MNtr9gRNm dfOujlVbuCPVTJ/9X2mK2kI4lhfo58EfPJeFnq0uqJisRbJFpiWQui4c48VZYOitz3UZ fZUlYlYc+hpbA6MKJs/stTGPKNpbN+UmElY+kA+95Lp4LEtrZ0iAl0+ODDnMfEaNbrab zVh5/H95nEyURgXFWkEsJYVBJFZzoNmvwnYn74kmHZexXlGhUNspcCfft7ssMyhvN8KY P86Y7vh/ViaZRqyaXsVqa3SsTQH7U+XvoHcGAc1U5FSTyQjrBA3+/ziUYv1K7Xqd1mvi ABig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LlGpKVxGB2WD0Y3ckXN3j7ONm5V6esE/TbnLRoxz3I8=; b=TawmDjLoLoDtPXqY9FqNOUL0W2+nOB/0IOJVoR39vkF0jPbkGTOUkC/1MzSRxUQofJ NbpBrh6+xMk8xLhVXjFyJn+TDHRR1EdJUU7a4wyNSubdoQwO69ORvnH6fbOGmxMCafcp fwNj4aBRiLwtYihmLNOOvrQEiy1Wx5k2WvTxtqQ95s939jyOOP/uC1ZbMx0YDkm6Dld5 Uz0nL5DkYEG8qAB877XgAKN6Bl1g/pkix6/UXcKUlkToL7rEAncKcGp0x5tD6apCiLYu /VYdmtmBUeGjP8ADhX1oxzmISY7ZB+fz+UKAqzfet8w76S0+CANLTTEu+wq4SgJBN86x RsTw== X-Gm-Message-State: APjAAAUqSJitqbJpwnf2lBhSutv28n4u1AEOvDz8/YlIEGjt2vHrKzL0 J52lPUhwYNyr4MhcvXE61lYLygS+LfoFBY8s0JA= X-Google-Smtp-Source: APXvYqwA43aZC8Tsf6Y2KhTHKsL/TMWPMEF8pig2+gfCQX/9b/iyjYJ4riJMYsr3zo1ltGP+Qs6kQPnCw7Xa1QwMvyg= X-Received: by 2002:ac8:2971:: with SMTP id z46mr16897038qtz.322.1563189176474; Mon, 15 Jul 2019 04:12:56 -0700 (PDT) MIME-Version: 1.0 References: <156176267487.11015.7325622691659550911.idtracker@ietfa.amsl.com> <1563182052810.34440@purple.us> In-Reply-To: <1563182052810.34440@purple.us> From: Brian Rosen Date: Mon, 15 Jul 2019 07:12:45 -0400 Message-ID: To: James Hamlin Cc: "rum@ietf.org" Content-Type: multipart/alternative; boundary="00000000000094b1f6058db657cf" Archived-At: Subject: Re: [Rum] rum - Requested session has been scheduled for IETF 105 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, 15 Jul 2019 11:13:11 -0000 --00000000000094b1f6058db657cf Content-Type: text/plain; charset="UTF-8" Yes! On Mon, Jul 15, 2019 at 5:14 AM James Hamlin wrote: > Brian > > Has remote dial-in been provisioned for this meeting? > > Best regards > > James > > ________________________________________ > From: Rum on behalf of "IETF Secretariat" < > agenda@ietf.org> > Sent: 28 June 2019 23:57 > To: rum-chairs@ietf.org; br@brianrosen.net > Cc: rum@ietf.org; adam@nostrum.com > Subject: [Rum] rum - Requested session has been scheduled for IETF 105 > > Dear Brian Rosen, > > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. > > > rum Session 1 (1:30 requested) > Tuesday, 23 July 2019, Afternoon Session II 1520-1650 > Room Name: Notre Dame size: 50 > --------------------------------------------- > > > iCalendar: https://datatracker.ietf.org/meeting/105/sessions/rum.ics > > Request Information: > > > --------------------------------------------------------- > Working Group Name: Relay User Machine > Area Name: Applications and Real-Time Area > Session Requester: Brian Rosen > > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 20 > Conflicts to Avoid: > First Priority: avtcore dispatch modern sipcore rtcweb ecrit > Second Priority: quic mmusic > > > > People who must be present: > Adam Roach > Brian Rosen > Paul Kyzivat > > Resources Requested: > > Special Requests: > > --------------------------------------------------------- > > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum > --00000000000094b1f6058db657cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes!

On Mon, Jul 15, 2019 at 5:14 AM James Hamlin <james.hamlin@purple.us> wrote:
Brian

Has remote dial-in been provisioned for this meeting?

Best regards

James

________________________________________
From: Rum <rum= -bounces@ietf.org> on behalf of "IETF Secretariat" <agenda@ietf.org> Sent: 28 June 2019 23:57
To: rum-chairs@iet= f.org; br@brianr= osen.net
Cc: rum@ietf.org; adam@nostrum.com
Subject: [Rum] rum - Requested session has been scheduled for IETF 105

Dear Brian Rosen,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.


=C2=A0 =C2=A0 rum Session 1 (1:30 requested)
=C2=A0 =C2=A0 Tuesday, 23 July 2019, Afternoon Session II 1520-1650
=C2=A0 =C2=A0 Room Name: Notre Dame size: 50
=C2=A0 =C2=A0 ---------------------------------------------


iCalendar: https://datatracker.ietf.org/mee= ting/105/sessions/rum.ics

Request Information:


---------------------------------------------------------
Working Group Name: Relay User Machine
Area Name: Applications and Real-Time Area
Session Requester: Brian Rosen

Number of Sessions: 1
Length of Session(s):=C2=A0 1.5 Hours
Number of Attendees: 20
Conflicts to Avoid:
=C2=A0First Priority: avtcore dispatch modern sipcore rtcweb ecrit
=C2=A0Second Priority: quic mmusic



People who must be present:
=C2=A0 Adam Roach
=C2=A0 Brian Rosen
=C2=A0 Paul Kyzivat

Resources Requested:

Special Requests:

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

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--00000000000094b1f6058db657cf-- From nobody Mon Jul 15 09:01:45 2019 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 EF4E5120088 for ; Mon, 15 Jul 2019 09:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 Y_7pPgCGUBRk for ; Mon, 15 Jul 2019 09:01:41 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (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 9C72C120045 for ; Mon, 15 Jul 2019 09:01:40 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.144]) by mx7.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 15 Jul 2019 16:01:34 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-402-exch.purplenetwork.net (10.0.10.144) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 15 Jul 2019 09:01:30 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Mon, 15 Jul 2019 09:01:30 -0700 From: James Hamlin To: Brian Rosen CC: "rum@ietf.org" Thread-Topic: [Rum] rum - Requested session has been scheduled for IETF 105 Thread-Index: AQHVOu1rxHkeTSb1r0Kay91wJh3tR6bL+/KA///bEBA= Date: Mon, 15 Jul 2019 16:01:30 +0000 Message-ID: <1563206490030.41999@purple.us> References: <156176267487.11015.7325622691659550911.idtracker@ietfa.amsl.com> <1563182052810.34440@purple.us>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_156320649003041999purpleus_" MIME-Version: 1.0 X-BESS-ID: 1563206491-893012-6191-81280-1 X-BESS-VER: 2019.1_20190708.1727 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.215980 [from cloudscan15-249.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] rum - Requested session has been scheduled for IETF 105 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, 15 Jul 2019 16:01:44 -0000 --_000_156320649003041999purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Many thanks We'll await a dial-in number. Best regards James ________________________________ From: Brian Rosen Sent: 15 July 2019 12:12 To: James Hamlin Cc: rum@ietf.org Subject: Re: [Rum] rum - Requested session has been scheduled for IETF 105 Yes! On Mon, Jul 15, 2019 at 5:14 AM James Hamlin > wrote: Brian Has remote dial-in been provisioned for this meeting? Best regards James ________________________________________ From: Rum > on behalf of = "IETF Secretariat" > Sent: 28 June 2019 23:57 To: rum-chairs@ietf.org; br@brianrosen.net Cc: rum@ietf.org; adam@nostrum.com Subject: [Rum] rum - Requested session has been scheduled for IETF 105 Dear Brian Rosen, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. rum Session 1 (1:30 requested) Tuesday, 23 July 2019, Afternoon Session II 1520-1650 Room Name: Notre Dame size: 50 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/rum.ics Request Information: --------------------------------------------------------- Working Group Name: Relay User Machine Area Name: Applications and Real-Time Area Session Requester: Brian Rosen Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 20 Conflicts to Avoid: First Priority: avtcore dispatch modern sipcore rtcweb ecrit Second Priority: quic mmusic People who must be present: Adam Roach Brian Rosen Paul Kyzivat Resources Requested: Special Requests: --------------------------------------------------------- -- Rum mailing list Rum@ietf.org https://www.ietf.org/mailman/listinfo/rum --_000_156320649003041999purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Many thanks


We'll await a dial-in number.


Best regards


James

From: Brian Rosen <br@= brianrosen.net>
Sent: 15 July 2019 12:12
To: James Hamlin
Cc: rum@ietf.org
Subject: Re: [Rum] rum - Requested session has been scheduled for IE= TF 105
 
Yes!

On Mon, Jul 15, 2019 at 5:14 AM James= Hamlin <james.hamlin@purple.u= s> wrote:
Brian

Has remote dial-in been provisioned for this meeting?

Best regards

James

________________________________________
From: Rum <rum= -bounces@ietf.org> on behalf of "IETF Secretariat" <agenda@ietf.org> Sent: 28 June 2019 23:57
To: rum-chairs@iet= f.org; br@brianrosen.net
Cc: rum@ietf.org; adam@nostrum.com
Subject: [Rum] rum - Requested session has been scheduled for IETF 105

Dear Brian Rosen,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.


    rum Session 1 (1:30 requested)
    Tuesday, 23 July 2019, Afternoon Session II 1520-1650
    Room Name: Notre Dame size: 50
    ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/105/sessions/rum.ics

Request Information:


---------------------------------------------------------
Working Group Name: Relay User Machine
Area Name: Applications and Real-Time Area
Session Requester: Brian Rosen

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of Attendees: 20
Conflicts to Avoid:
 First Priority: avtcore dispatch modern sipcore rtcweb ecrit
 Second Priority: quic mmusic



People who must be present:
  Adam Roach
  Brian Rosen
  Paul Kyzivat

Resources Requested:

Special Requests:

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

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
--_000_156320649003041999purpleus_-- From nobody Mon Jul 15 09:45:34 2019 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 B0417120099 for ; Mon, 15 Jul 2019 09:45:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 BKKbdJYPjR-t for ; Mon, 15 Jul 2019 09:45:30 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 53838120026 for ; Mon, 15 Jul 2019 09:45:30 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id l9so16317096qtu.6 for ; Mon, 15 Jul 2019 09:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ChE4ciQ66tozHGvKbcrAu6QZlLZ6ebvdn0GA/uAlGFw=; b=WoFGUnH3+I3z97QJ2NNB3vWDEu3UcL22QixdO44E8xERbDcgLSIYxN9c40gywsFjDb B24nAhdZnycD1HekeGwgrcnul/tc59o9e+8Q6a+HjVS94PuNpmSrKl1F6vKVENL7Q3km xXZ/Z5aio5ql+ltXyqenF/7U4+TQ1XS3hT7DZVAvb2fRHRI7C84Am1EOFNzaD7bOQo38 KV8HwipE0VTZwqO6m6gEqBbs3d1hB+ziBpXwEKGesv+eJIPumAtuRqqZKGa0qZtgcegs 1E8uKNToRfrYu5d7OvAteAKoZMOHThy0gE6ttOswDLS+8V9VG0FJwDOVIuDP71O0urFw wWAw== 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=ChE4ciQ66tozHGvKbcrAu6QZlLZ6ebvdn0GA/uAlGFw=; b=ZjSFi7xhSpRySCkAjcug3wY4rH+Yql4IlT72lqCYSw5XOWeOqhK5PBfYeNfVYnVwEa mtUMjISlN20D29azIxr+C9tCe+OWmM6x9wtaxkJ5ypKHCzVw+z6LM3VSCV++WWeXIdq/ Vw+qKyPB1bqm/rYBqtPeVvvQsRD90YONP4924RMEGHXo1W4zUxiI0xJgmcytDgrZ3Fzt uMZZXwk/CZf9sKtbNmkBtd+C9lrPQiiMTsjQKwm3AZ8rTEcqGdR3dMYoJKfowMAC6eGI lMphc0ZgT5LobYojgwvsFlYlaK/xO0D9agUFNW44wgrzZ/58UyeRcIByXjERvHciBEvp cgEQ== X-Gm-Message-State: APjAAAWm/V0ObYji2SiDbooC0sovTA6CBq0Wli7GJ9z9E83/NxTOgWdz M1PNnkqkexbOhKg4kSlGZELeaGgp X-Google-Smtp-Source: APXvYqyqz3KYkPaDmzMu46N3jINGQWVOcZS7GPRccMWZgJZET7k9WeubQ8c/SQnCFH/2BryNvMUBAw== X-Received: by 2002:ac8:282b:: with SMTP id 40mr18983454qtq.49.1563209129348; Mon, 15 Jul 2019 09:45:29 -0700 (PDT) Received: from brians-mbp-2369.lan (dynamic-acs-24-101-114-50.zoominternet.net. [24.101.114.50]) by smtp.gmail.com with ESMTPSA id c5sm10111302qta.5.2019.07.15.09.45.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 09:45:28 -0700 (PDT) From: Brian Rosen Message-Id: <5678B6E5-13E5-49A2-99AD-03ECEF3E9EFD@brianrosen.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_9150A539-BC18-48A8-BA93-CECB00F5B8C2" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 12:45:25 -0400 In-Reply-To: <1563206490030.41999@purple.us> Cc: "rum@ietf.org" To: James Hamlin References: <156176267487.11015.7325622691659550911.idtracker@ietfa.amsl.com> <1563182052810.34440@purple.us> <1563206490030.41999@purple.us> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Rum] rum - Requested session has been scheduled for IETF 105 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, 15 Jul 2019 16:45:33 -0000 --Apple-Mail=_9150A539-BC18-48A8-BA93-CECB00F5B8C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 You don=E2=80=99t get a dial in number. You go to the agenda: https://datatracker.ietf.org/meeting/agenda/ = Find our meeting (Tuesday afternoon session I) and click the audio or = video link on the right when the session starts. Brian > On Jul 15, 2019, at 12:01 PM, James Hamlin = wrote: >=20 > Many thanks >=20 > We'll await a dial-in number. >=20 > Best regards >=20 > James > From: Brian Rosen > Sent: 15 July 2019 12:12 > To: James Hamlin > Cc: rum@ietf.org > Subject: Re: [Rum] rum - Requested session has been scheduled for IETF = 105 > =20 > Yes! >=20 > On Mon, Jul 15, 2019 at 5:14 AM James Hamlin > wrote: > Brian >=20 > Has remote dial-in been provisioned for this meeting? >=20 > Best regards >=20 > James >=20 > ________________________________________ > From: Rum > on = behalf of "IETF Secretariat" > > Sent: 28 June 2019 23:57 > To: rum-chairs@ietf.org ; = br@brianrosen.net > Cc: rum@ietf.org ; adam@nostrum.com = > Subject: [Rum] rum - Requested session has been scheduled for IETF 105 >=20 > Dear Brian Rosen, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request. >=20 >=20 > rum Session 1 (1:30 requested) > Tuesday, 23 July 2019, Afternoon Session II 1520-1650 > Room Name: Notre Dame size: 50 > --------------------------------------------- >=20 >=20 > iCalendar: https://datatracker.ietf.org/meeting/105/sessions/rum.ics = >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: Relay User Machine > Area Name: Applications and Real-Time Area > Session Requester: Brian Rosen >=20 > Number of Sessions: 1 > Length of Session(s): 1.5 Hours > Number of Attendees: 20 > Conflicts to Avoid: > First Priority: avtcore dispatch modern sipcore rtcweb ecrit > Second Priority: quic mmusic >=20 >=20 >=20 > People who must be present: > Adam Roach > Brian Rosen > Paul Kyzivat >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 > -- > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum = --Apple-Mail=_9150A539-BC18-48A8-BA93-CECB00F5B8C2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 You = don=E2=80=99t get a dial in number.  You go to the agenda:
https://datatracker.ietf.org/meeting/agenda/

Find our meeting = (Tuesday afternoon session I) and click the audio or video link on the = right when the session starts.

Brian

On Jul 15, 2019, at 12:01 PM, James Hamlin <james.hamlin@purple.us> wrote:

Many thanks

We'll await a dial-in = number.

Best = regards

James
From: Brian Rosen <br@brianrosen.net>
Sent: 15 July 2019 12:12
To: James Hamlin
Cc: rum@ietf.org
Subject: Re: [Rum] rum - Requested = session has been scheduled for IETF 105
 
Yes!

On Mon, Jul = 15, 2019 at 5:14 AM James Hamlin <james.hamlin@purple.us> wrote:
Brian

Has remote dial-in been provisioned for this = meeting?

Best regards

James

________________________________________
From: = Rum <rum-bounces@ietf.org> on behalf of "IETF Secretariat" = <agenda@ietf.org>
Sent: 28 June 2019 = 23:57
To: rum-chairs@ietf.org; br@brianrosen.net
Cc: rum@ietf.org; adam@nostrum.com
Subject: [Rum] rum - = Requested session has been scheduled for IETF 105

Dear Brian Rosen,

The session(s) = that you have requested have been scheduled.
Below is the = scheduled session information followed by
the original = request.


    rum = Session 1 (1:30 requested)
    Tuesday, 23 July = 2019, Afternoon Session II 1520-1650
    Room = Name: Notre Dame size: 50
    = ---------------------------------------------


iCalendar: https://datatracker.ietf.org/meeting/105/sessions/rum.ics
Request Information:


---------------------------------------------------------
Working Group Name: Relay User Machine
Area = Name: Applications and Real-Time Area
Session Requester: = Brian Rosen

Number of Sessions: 1
Length of Session(s):  1.5 Hours
Number of = Attendees: 20
Conflicts to Avoid:
 First = Priority: avtcore dispatch modern sipcore rtcweb ecrit
 Second Priority: quic mmusic



People who must be present:
  Adam Roach
  Brian Rosen
  Paul Kyzivat

Resources = Requested:

Special Requests:

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

--
Rum mailing list
Rum@ietf.org
https://www.ietf.org/mailman/listinfo/rum
<= br class=3D"">
= --Apple-Mail=_9150A539-BC18-48A8-BA93-CECB00F5B8C2-- From nobody Mon Jul 15 09:56:55 2019 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 888A11201A3 for ; Mon, 15 Jul 2019 09:56:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 TeQJmaZJvLBy for ; Mon, 15 Jul 2019 09:56:51 -0700 (PDT) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 EA4AF12011D for ; Mon, 15 Jul 2019 09:56:50 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id 44so16310150qtg.11 for ; Mon, 15 Jul 2019 09:56:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:mime-version:subject:message-id:date:to; bh=jvUPCZnJ8pxjbN00BmRy1qaGUGQePNQnQUilSPoiXn8=; b=Y/aFC/j2/98vHe3+IerPRnXbnBFQ3R10aaIhPCln6EZOCFc1GKEZ2jy8HwuMQ1M1sk VBB5q9TlPSxcew2RYCas27VlxQF4YYpgUeMvqo9/6IOzo7E7PcCqcm/V3t/gDGv9RBS2 inreoA4arKiWG2U60wg/3Ot38wDviZt29GCPnv6dtfZCnmKN5ATcWEMwktvaEQjywDjR dage+GZ/tQnt1XWG0Px8VOK9u6MArSjAUBK7Nk+u2goKY/SM9Q4kLNNAEVTdShvb2F1C j8ImXEAWekFODhVj4h+mDoH3uuI5TLbc87ydshAGzb/rJYFs6Q/qOx8FmOP8mOK5pOfk Hg9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=jvUPCZnJ8pxjbN00BmRy1qaGUGQePNQnQUilSPoiXn8=; b=KQ4U0F0wWN8XCnRMmDgPCRSbqpHnKJypDaKRapmpuWe2BRx1TfTDhihfDmnCDP3uIH aBU0MFu3PuctT3OKAddKmW2xX3AwFg0/97hi7rGnGBDmaVDXVLRTDipHOWB3ffq7MyIT niUTfz37GxznRzuLZQH2mpAQRvJTABkuG2ktMs3a5kL1V5a3Msm2YdX8XcJMpJFmr98A MOOmSlG0UFK9b5FpNCJVnC3BZHFl8L2wsgcydsPyPGs1b2duxf3v3r6OVd4CV8TVFKsL eOlc8KQhj+WQAlL3hsxWHx1wqrepZxdUDIvjepnlP2PnwMFrsNZsWCkrrNnefLIz/EFF XHeQ== X-Gm-Message-State: APjAAAXLAfxPjEwrLAU37351o75qxPG23pSBN21KCmE3frh23ZucDYoR o9q56sDAECTyKtH+nOwtTBKC4UVA X-Google-Smtp-Source: APXvYqzoI4D7aLPgXUqkqvjIyTjRRlwsRLcL1zhc5o2+MP77xTkJW5OVbRjkUzmHQvie1crM6Y37YQ== X-Received: by 2002:ac8:4252:: with SMTP id r18mr18870268qtm.357.1563209809882; Mon, 15 Jul 2019 09:56:49 -0700 (PDT) Received: from brians-mbp-2369.lan (dynamic-acs-24-101-114-50.zoominternet.net. [24.101.114.50]) by smtp.gmail.com with ESMTPSA id s8sm7622621qkg.64.2019.07.15.09.56.49 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Jul 2019 09:56:49 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_D7F23D03-A926-4580-8778-9B814EF65EF3" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: <958A19F1-6366-4317-AA84-CE10DFA4DD48@brianrosen.net> Date: Mon, 15 Jul 2019 12:56:48 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [Rum] Remote participation in the rum meeting 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, 15 Jul 2019 16:56:53 -0000 --Apple-Mail=_D7F23D03-A926-4580-8778-9B814EF65EF3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Our meeting is: 15:20-16:50 Tuesday Afternoon = session II 2 = Notre Dame = = art = rum = Relay User Machine = = =20 If you find that entry on the meeting agenda: https://datatracker.ietf.org/meeting/agenda/ = you will find the links for audio and video participation (on the = right). For convenience, the audio link is: http://mp3.conf.meetecho.com/ietf/ietf1054.m3u = And the video link (recommended) is: http://www.meetecho.com/ietf105/rum/ = --Apple-Mail=_D7F23D03-A926-4580-8778-9B814EF65EF3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Our meeting is:
15:20-16:50 Tuesday Afternoon session II
2 Notre Dame rum Relay User Machine

If you find that entry on the meeting agenda:

you will find the links for audio and video participation (on the right).  For convenience, the audio link is:

And the video link (recommended) is:



--Apple-Mail=_D7F23D03-A926-4580-8778-9B814EF65EF3-- From nobody Tue Jul 23 14:20:53 2019 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 AB16C1202CC for ; Tue, 23 Jul 2019 14:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 lNQPC57zYVRe for ; Tue, 23 Jul 2019 14:20:47 -0700 (PDT) Received: from vsp-unauthed02.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (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 5B28E1202C3 for ; Tue, 23 Jul 2019 14:20:47 -0700 (PDT) X-Halon-ID: b894f67e-ad8f-11e9-bdc3-005056917a89 Authorized-sender: gunnar.hellstrom@omnitor.se Received: from [192.168.43.70] (unknown [94.234.32.120]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id b894f67e-ad8f-11e9-bdc3-005056917a89; Tue, 23 Jul 2019 23:20:41 +0200 (CEST) To: "Olle E. Johansson" , Brian Rosen Cc: rum@ietf.org References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= Message-ID: <850aa083-2426-0e9b-b7e2-b6de6ccf0bbb@omnitor.se> Date: Tue, 23 Jul 2019 23:20:41 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> Content-Type: multipart/alternative; boundary="------------6247E26842754230531789EB" Content-Language: en-US Archived-At: Subject: Re: [Rum] Let's get into it X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 21:20:52 -0000 This is a multi-part message in MIME format. --------------6247E26842754230531789EB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Brian, I agree with Olle. For now, just a couple of minor comments. 1: Section 5. General requirements. These requirements are not exactly general. Most of them are security related. Security interested readers might miss them under the current header. I suggest to make two subsections under 5: 5.1 General security requirements 5.2 General coding requirements (the last two lines) 2: Section 8: "All media streams between the RUE and another endpoint or relay Provider MUST be exchanged using the secure real-time transport protocol (SRTP) [RFC3550 ] using DTLS [RFC5763 ], [RFC5764 ], except that for backwards compatibility with older video endpoints, RTP MAY be negotiated if SRTP negotiation fails. “ I assume that the reference for SRTP should be RFC 3711. You may move the reference to RFC 3550 one line forwards, to after RTP. Good work Gunnar Den 2019-07-10 kl. 12:28, skrev Olle E. Johansson: > > >> On 9 Jul 2019, at 21:48, Brian Rosen > > wrote: >> >> Please comment on anything. > > Section 5: > > "Both HTTPS and all SIP Transactions MUST use TLS 1.2” > > “Transactions” doesn’t work well here. “Connections” would be better. > Instead of hard-coding a specific version of TLS you may want to point > to the BCP by the UTA wg, > unless you anyway will update this profile from time to time. > > "During the establishment of secure connections with a provider, the > RUE MAY be asked by the server for a client certificate. In that > case it SHOULD provide a client certificate. Providers MAY reject > requests that fail to provide a recognized certificate.” > What’s in the client cert? How do you validate the client certs? > Section 6 doesn’t mentionSIP over WebSockets. I assume that would apply. > Since you are using phone numbers as identifiers, I from an EU standpoint > suggest disallowing all non-secure transports. Phone numbers are > considered personal identifiers and are affected by the EU GDPR. > Section 6.2.1 forbids Route headers in initial INVITE requests. The example > in 6.2.2 has a very visible Route: header in the initial request. > Section 6.2.3 talks about an xCard without any references or comments > about trust for that information. > Section 6.2.4: > "The RUE MUST accept inbound calls sent to it by the proxy mentioned > in the configuration.” > The proxy is found using DNS and may be a list created from NATPR/DNS SRV > records. What is the defintion of “the proxy” in this statement? > "If Multiple simultaneous RUE SIP registrations from different RUE > devices with the same SIP URI exist, the Provider MUST parallel fork the call to all registered RUEs so that they ring at the same time. > The first RUE to reply with a 200 OK answers the call and the > Provider MUST CANCEL other call branches. > " > Is this normative (you have many MUST here). If so - how does this > change the behaviour of RFC 3261? > Also, I think this texts forgets about SIP outbound. Since Outbound is a MUST, > you need to clarify the mix of parallell and serial forking that will happen. > Section 6.3: > "The RUE MUST support REFER to enable call transfer.“ > > Which combination of REFER? I assume that “Mid call signaling” is > “in-dialog transactions” in SIP lingo, > but REFER with or without Replaces? With or without subscription for > updates? > > Section 6.4: > > "Relay Service URIs and User Address of Records (AoR) MUST resolve (in > accord with [RFC3263 ]) to globally routable IPv4 addresses. The AoRs > MAY also resolve to IPv6 addresses.” > How do you resolve a complete URI into an IP address? I guess you mean > the domain part that resolves to a list of addresses using DNS. > Why is IPv4 a MUST? > Section 8: > "All media streams between the RUE and another endpoint or relay > Provider MUST be exchanged using the secure real-time transport > protocol (SRTP) [RFC3550 ] using DTLS [RFC5763 ], [RFC5764 ], except > that for backwards compatibility with older video endpoints, RTP MAY > be negotiated if SRTP negotiation fails. > “ > > How do you handle the risk of downgrade attacks here? That exception > is dangerous > and maybe should be handled elsewhere, not in the client. > > > Section 11.1 > > The example operator URI for red.example.net >  seems to lack “;user=dialstring” > > Section 11.2 > > "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be > used when sending requests to the Provider. Multiple URIs > identify alternative (redundant) paths to the Provider. > “ > > Outbound proxy is of course something you look up in DNS to get the > list of > actual servers. Is there a need to have an additional list in this > json format? > > "ice-servers” - propably a bad name. I don’t remember seeing “ice > server” as a term. > As turn servers are also STUN servers, I think “turn-servers” is better. > > “credentials”: This is tricky indeed. Sending credentials in clear > text like this, > even if it’s over HTTPS is an interesting approach in this age and time. > Regardless of that, make sure you consider OAuth/OpenID connect auth > for some services. > > “lifetime”:; You are really not clear on what happens when the > configuration > expires. Is the RUE forbidden to use anything here? What about > emergency calls > - will they work even without configuration? > > General: > > You do not mention bundling of RTP streams, which may be beneficial here. > > Good work! > > /O > > > > > > -- ----------------------------------------- Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46 708 204 288 --------------6247E26842754230531789EB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Brian,

I agree with Olle.

For now, just a couple of minor comments.

1:

Section 5. General requirements.

These requirements are not exactly general. Most of them are security related. Security interested readers might miss them under the current header.

I suggest to make two subsections under 5:

5.1 General security requirements

5.2 General coding requirements

(the last two lines)

2:

Section 8:

    
"All media streams between the RUE and another endpoint or relay

    
   Provider MUST be exchanged using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.

    
“

    
I assume that the reference for SRTP should be RFC
      3711.

    
You may move the reference to RFC 3550 one line
      forwards, to after RTP.

    


    

    


    

    
Good work

    


    

    
Gunnar

    

    


    

    
Den 2019-07-10 kl. 12:28, skrev Olle E.
      Johansson:

    

    

      
      

      


        

          
On 9 Jul 2019, at 21:48, Brian Rosen <br@brianrosen.net> wrote:

          

          
Please comment on anything.

        

        

      

      
Section 5:

      

      
"Both HTTPS and all SIP Transactions MUST use TLS 1.2”

      


        

      
“Transactions” doesn’t work
          well here. “Connections” would be better.

      
Instead of hard-coding a
          specific version of TLS you may want to point to the BCP by
          the UTA wg,

      
unless you anyway will
          update this profile from time to time.

      


        

      
" During the
          establishment of secure connections with a provider, the

      
   RUE MAY be asked by the server for a client certificate.  In that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.”

      

      
What’s in the client cert? How do you validate the client certs?

      

      
Section 6 doesn’t mentionSIP over WebSockets. I assume that would apply.

      

      

      
Since you are using phone numbers as identifiers, I from an EU standpoint

      
suggest disallowing all non-secure transports. Phone numbers are 

      
considered personal identifiers and are affected by the EU GDPR.

      

      

      
Section 6.2.1 forbids Route headers in initial INVITE requests. The example

      
in 6.2.2 has a very visible Route: header in the initial request.

      

      
Section 6.2.3 talks about an xCard without any references or comments

      
about trust for that information.

      

      
Section 6.2.4:

      

      
"The RUE MUST accept inbound calls sent to it by the proxy mentioned

      
   in the configuration.”

      

      
The proxy is found using DNS and may be a list created from NATPR/DNS SRV

      
records. What is the defintion of “the proxy” in this statement?

      

      
"If Multiple simultaneous RUE SIP registrations from different RUE

      
   devices with the same SIP URI exist, the Provider MUST parallel fork   the call to all registered RUEs so that they ring at the same time.


      
   The first RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.

      
"

      
Is this normative (you have many MUST here). If so - how does this

      
change the behaviour of RFC 3261?

      
Also, I think this texts forgets about SIP outbound. Since Outbound is a MUST,

      
you need to clarify the mix of parallell and serial forking that will happen.

      

      

      
Section 6.3:

      

      
"The RUE MUST support   REFER to enable call transfer.“

      


      

      
Which combination of REFER? I assume that “Mid call
        signaling” is “in-dialog transactions” in SIP lingo,

      
but REFER with or without Replaces? With or without
        subscription for updates?

      


      

      
Section 6.4:

      


      

      
" Relay Service URIs and User Address of Records (AoR)
          MUST resolve (in

      
   accord with [RFC3263]) to globally routable IPv4 addresses.  The AoRs
   MAY also resolve to IPv6 addresses.”

      

      
How do you resolve a complete URI into an IP address? I guess you mean

      
the domain part that resolves to a list of addresses using DNS.

      
Why is IPv4 a MUST?

      

      
Section 8:

      

      
"All media streams between the RUE and another endpoint or relay

      
   Provider MUST be exchanged using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.

      
“

      


      

      
How do you handle the risk of downgrade attacks
        here? That exception is dangerous

      
and maybe should be handled elsewhere, not in the
        client. 

      


      

      


      

      
Section 11.1

      


      

      
The example operator URI for red.example.net seems
        to lack “;user=dialstring”

      


      

      
Section 11.2

      


      

      
"outbound-proxies: (OPTIONAL) A list of URIs of SIP
          proxies to be

      
      used when sending requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.

      
“

      


      

      
Outbound proxy is of course something you look up in
        DNS to get the list of

      
actual servers. Is there a need to have an
        additional list in this json format?

      


      

      
" ice-servers” - propably a
          bad name. I don’t remember seeing “ice server” as a term.

      
As turn servers are also
          STUN servers, I think “turn-servers” is better.

      


        

      
“credentials”: This is
          tricky indeed. Sending credentials in clear text like this,

      
even if it’s over HTTPS is
          an interesting approach in this age and time.

      
Regardless of that, make
          sure you consider OAuth/OpenID connect auth

      
for some services.

      


        

      
“lifetime”:; You are really
          not clear on what happens when the configuration

      
expires. Is the RUE
          forbidden to use anything here? What about emergency calls

      
- will they work even
          without configuration?

      


      

      
General:

      


        

      
You do not mention bundling
          of RTP streams, which may be beneficial here.

      


        

      
Good work!

      


        

      
/O

      


        

      


      

      


      

      


      

      


      

      

      

    

    
-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  


--------------6247E26842754230531789EB--


From nobody Tue Jul 23 14:23:20 2019
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 E74131202CC for ; Tue, 23 Jul 2019 14:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level: 
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AcWueVPlDy1W for ; Tue, 23 Jul 2019 14:23:14 -0700 (PDT)
Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 675F2120159 for ; Tue, 23 Jul 2019 14:23:14 -0700 (PDT)
Received: by mail-qt1-x834.google.com with SMTP id h21so43296376qtn.13 for ; Tue, 23 Jul 2019 14:23:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=uiFzCq21yN3X2ADEbBlxLMe+bF6wZg7Gahz/e1rT+Ns=; b=WvxgtK9C42pCmQUtb4tLCPjO6B7P+x4vZZPsz/JGLUoQonxSLrbI8zg8AbRAIL2BUf tAyrGF/q8EGtMoNs+oimEFwYHda/AT/m6JUHPUkChObSVJisJ4o/xoGHjc/26Aq343zK 84UomJy9BbaqMvAKNn/xlw2Ct/YE0ecWsfNVXiCcVb9FAnqpVOuJF0cGw5KA2/Oa3PVf 495zX7+FVR8Fb1RGQhVU488lOrhrc6YFRbOwrfO3aBIRMIOA3HaGAkkzfJkepKzZOXYj t95u5voxuDhXzvpARqnhCitYr4a38IsAZ7Z4p5dOjS57/NitsTk35nz+UuUlrP/EGLYs +K5Q==
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=uiFzCq21yN3X2ADEbBlxLMe+bF6wZg7Gahz/e1rT+Ns=; b=K44aHFV6HSSWIrjYg/wlspB/aWnOpUS0z2K2IswA6dYLyU8S4pAgxD7cJD1W/zP1YO IptR5TVbhrl/C2YJJhHGYTgoI+RKPBwwokjY6FK6+GDutIVBsCaqgN8fWETajj/0Dh+S NwKtFZpGFvTut6E+lOUtUdVXNaWqLZkUQ+XSuhgJpVJF1tfCt2Fc628SgGc50HGk7g7W NHt83uKu7ed1N/YadHdnqenxPeW2IaNusRuFeN6osYftFdvMkn77Hn8/c0ZtTgJyMyPE zsXyS3SDNj/xZd5vLui9sGQvZr/j8mttEmVv9XkYC/BnQEp013qdZ8/bKcSeSEohqiRm UprQ==
X-Gm-Message-State: APjAAAXhSogF5NGVVHiAt2aeC9m186P6SH/OaC/I5IcfOmTe+RphANMk 8ruqweidCc2m8WRcAyxyShZ3i1YRI7c=
X-Google-Smtp-Source: APXvYqxTM+wy9VAFG/FPfxhdS0zoIuJm8Ou2IS+pBlSWMrpdMRQuu/fpoU34N1Em/2T0qsZTUDeFaw==
X-Received: by 2002:a05:6214:1312:: with SMTP id a18mr55687121qvv.241.1563916993388;  Tue, 23 Jul 2019 14:23:13 -0700 (PDT)
Received: from ?IPv6:2001:67c:370:128:70ce:3281:16a7:a4ae? ([2001:67c:370:128:70ce:3281:16a7:a4ae]) by smtp.gmail.com with ESMTPSA id t76sm21120503qke.79.2019.07.23.14.23.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Jul 2019 14:23:13 -0700 (PDT)
From: Brian Rosen 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_9B85C179-D4DC-4BA7-B201-065CF78C28B7"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Tue, 23 Jul 2019 17:23:09 -0400
In-Reply-To: <850aa083-2426-0e9b-b7e2-b6de6ccf0bbb@omnitor.se>
Cc: "Olle E. Johansson" , rum@ietf.org
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= 
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <850aa083-2426-0e9b-b7e2-b6de6ccf0bbb@omnitor.se>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: 
Subject: Re: [Rum] Let's get into it
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jul 2019 21:23:18 -0000

--Apple-Mail=_9B85C179-D4DC-4BA7-B201-065CF78C28B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks.

I think when we bring in the WebRTC media specs, the SRTP stuff comes =
with it, so this text may leave.

I=E2=80=99ll look into separating the general requirements as you =
suggest but I=E2=80=99m not a fan of a one paragraph subsection.

Brian

> On Jul 23, 2019, at 5:20 PM, Gunnar Hellstr=C3=B6m =
 wrote:
>=20
> Brian,
>=20
> I agree with Olle.
>=20
> For now, just a couple of minor comments.
>=20
> 1:
>=20
> Section 5. General requirements.
>=20
> These requirements are not exactly general. Most of them are security =
related. Security interested readers might miss them under the current =
header.
>=20
> I suggest to make two subsections under 5:
>=20
> 5.1 General security requirements
>=20
> 5.2 General coding requirements
>=20
> (the last two lines)
>=20
> 2:
>=20
> Section 8:
> "All media streams between the RUE and another endpoint or relay
>    Provider MUST be exchanged using the secure real-time transport
>    protocol (SRTP) [RFC3550 ] =
using DTLS [RFC5763 ], [RFC5764 =
], except
>    that for backwards compatibility with older video endpoints, RTP =
MAY
>    be negotiated if SRTP negotiation fails.
> =E2=80=9C
> I assume that the reference for SRTP should be RFC 3711.
> You may move the reference to RFC 3550 one line forwards, to after =
RTP.
>=20
>=20
> Good work
>=20
> Gunnar
>=20
> Den 2019-07-10 kl. 12:28, skrev Olle E. Johansson:
>>=20
>>=20
>>> On 9 Jul 2019, at 21:48, Brian Rosen > wrote:
>>>=20
>>> Please comment on anything.
>>=20
>> Section 5:
>>=20
>> "Both HTTPS and all SIP Transactions MUST use TLS 1.2=E2=80=9D
>>=20
>> =E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work well here. =
=E2=80=9CConnections=E2=80=9D would be better.
>> Instead of hard-coding a specific version of TLS you may want to =
point to the BCP by the UTA wg,
>> unless you anyway will update this profile from time to time.
>>=20
>> " During the establishment of secure connections with a provider, the
>>    RUE MAY be asked by the server for a client certificate.  In that
>>    case it SHOULD provide a client certificate.  Providers MAY reject
>>    requests that fail to provide a recognized certificate.=E2=80=9D
>> What=E2=80=99s in the client cert? How do you validate the client =
certs?
>> Section 6 doesn=E2=80=99t mentionSIP over WebSockets. I assume that =
would apply.
>> Since you are using phone numbers as identifiers, I from an EU =
standpoint
>> suggest disallowing all non-secure transports. Phone numbers are=20
>> considered personal identifiers and are affected by the EU GDPR.
>> Section 6.2.1 forbids Route headers in initial INVITE requests. The =
example
>> in 6.2.2 has a very visible Route: header in the initial request.
>> Section 6.2.3 talks about an xCard without any references or comments
>> about trust for that information.
>> Section 6.2.4:
>> "The RUE MUST accept inbound calls sent to it by the proxy mentioned
>>    in the configuration.=E2=80=9D
>> The proxy is found using DNS and may be a list created from NATPR/DNS =
SRV
>> records. What is the defintion of =E2=80=9Cthe proxy=E2=80=9D in this =
statement?
>> "If Multiple simultaneous RUE SIP registrations from different RUE
>>    devices with the same SIP URI exist, the Provider MUST parallel =
fork   the call to all registered RUEs so that they ring at the same =
time.
>>    The first RUE to reply with a 200 OK answers the call and the
>>    Provider MUST CANCEL other call branches.
>> "
>> Is this normative (you have many MUST here). If so - how does this
>> change the behaviour of RFC 3261?
>> Also, I think this texts forgets about SIP outbound. Since Outbound =
is a MUST,
>> you need to clarify the mix of parallell and serial forking that will =
happen.
>> Section 6.3:
>> "The RUE MUST support   REFER to enable call transfer.=E2=80=9C
>>=20
>> Which combination of REFER? I assume that =E2=80=9CMid call =
signaling=E2=80=9D is =E2=80=9Cin-dialog transactions=E2=80=9D in SIP =
lingo,
>> but REFER with or without Replaces? With or without subscription for =
updates?
>>=20
>> Section 6.4:
>>=20
>> " Relay Service URIs and User Address of Records (AoR) MUST resolve =
(in
>>    accord with [RFC3263 ]) to =
globally routable IPv4 addresses.  The AoRs
>>    MAY also resolve to IPv6 addresses.=E2=80=9D
>> How do you resolve a complete URI into an IP address? I guess you =
mean
>> the domain part that resolves to a list of addresses using DNS.
>> Why is IPv4 a MUST?
>> Section 8:
>> "All media streams between the RUE and another endpoint or relay
>>    Provider MUST be exchanged using the secure real-time transport
>>    protocol (SRTP) [RFC3550 ] =
using DTLS [RFC5763 ], [RFC5764 =
], except
>>    that for backwards compatibility with older video endpoints, RTP =
MAY
>>    be negotiated if SRTP negotiation fails.
>> =E2=80=9C
>>=20
>> How do you handle the risk of downgrade attacks here? That exception =
is dangerous
>> and maybe should be handled elsewhere, not in the client.=20
>>=20
>>=20
>> Section 11.1
>>=20
>> The example operator URI for red.example.net =
 seems to lack =E2=80=9C;user=3Ddialstring=E2=80=9D=

>>=20
>> Section 11.2
>>=20
>> "outbound-proxies: (OPTIONAL) A list of URIs of SIP proxies to be
>>       used when sending requests to the Provider.  Multiple URIs
>>       identify alternative (redundant) paths to the Provider.
>> =E2=80=9C
>>=20
>> Outbound proxy is of course something you look up in DNS to get the =
list of
>> actual servers. Is there a need to have an additional list in this =
json format?
>>=20
>> " ice-servers=E2=80=9D - propably a bad name. I don=E2=80=99t =
remember seeing =E2=80=9Cice server=E2=80=9D as a term.
>> As turn servers are also STUN servers, I think =E2=80=9Cturn-servers=E2=
=80=9D is better.
>>=20
>> =E2=80=9Ccredentials=E2=80=9D: This is tricky indeed. Sending =
credentials in clear text like this,
>> even if it=E2=80=99s over HTTPS is an interesting approach in this =
age and time.
>> Regardless of that, make sure you consider OAuth/OpenID connect auth
>> for some services.
>>=20
>> =E2=80=9Clifetime=E2=80=9D:; You are really not clear on what happens =
when the configuration
>> expires. Is the RUE forbidden to use anything here? What about =
emergency calls
>> - will they work even without configuration?
>>=20
>> General:
>>=20
>> You do not mention bundling of RTP streams, which may be beneficial =
here.
>>=20
>> Good work!
>>=20
>> /O
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
> --=20
> -----------------------------------------
> Gunnar Hellstr=C3=B6m
> Omnitor
> gunnar.hellstrom@omnitor.se 
> +46 708 204 288


--Apple-Mail=_9B85C179-D4DC-4BA7-B201-065CF78C28B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks.

I =
think when we bring in the WebRTC media specs, the SRTP stuff comes with =
it, so this text may leave.

I=E2=80=99ll look into separating the general requirements =
as you suggest but I=E2=80=99m not a fan of a one paragraph =
subsection.

Brian

On Jul 23, 2019, at 5:20 PM, =
Gunnar Hellstr=C3=B6m <gunnar.hellstrom@omnitor.se> wrote:


 =20
    
 =20
  
Brian,
I agree with Olle.

    
For now, just a couple of minor comments.
1:

    
Section 5. General requirements.
These requirements are not exactly general. Most of them are
      security related. Security interested readers might miss them
      under the current header.

    
I suggest to make two subsections under 5:
5.1 General security requirements
5.2 =
General coding requirements
(the last two lines)

    
 2:

    

    
Section =
8:

    

    
"All media =
streams between the RUE and another endpoint or relay

    
   Provider =
MUST be exchanged using the secure real-time transport
   protocol (SRTP) [RFC3550] using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.

    
=E2=80=9C

    
I assume that the reference for SRTP should be RFC
      3711.

    
You may move the reference to RFC 3550 one line
      forwards, to after RTP.

    


    

    


    

    
Good work

    


    

    
Gunnar

    

    


    

    
Den 2019-07-10 kl. 12:28, skrev Olle =
E.
      Johansson:

    

    

      
      

      


        

          
On 9 Jul 2019, at 21:48, Brian Rosen <br@brianrosen.net> wrote:

          

          
Please comment on =
anything.

        

        

      

      
Section 5:

      

      
"Both HTTPS and all SIP Transactions MUST use TLS =
1.2=E2=80=9D

      


        

      
=E2=80=9CTransactions=E2=80=9D doesn=E2=80=99t work
          well here. =E2=80=9CConnections=E2=80=9D would be =
better.

      
Instead of hard-coding =
a
          specific version of TLS you may want to point to the BCP by
          the UTA wg,

      
unless you anyway will
          update this profile from time to time.

      


        

      
" During the
          establishment of secure connections with a provider, =
the

      
   RUE MAY be =
asked by the server for a client certificate.  In that
   case it SHOULD provide a client certificate.  Providers MAY reject
   requests that fail to provide a recognized certificate.=E2=80=9D

      

      
What=E2=80=99s =
in the client cert? How do you validate the client certs?

      

      
Section 6 =
doesn=E2=80=99t mentionSIP over WebSockets. I assume that would =
apply.

      

      

      
Since you are =
using phone numbers as identifiers, I from an EU standpoint

      
suggest =
disallowing all non-secure transports. Phone numbers are 

      
considered =
personal identifiers and are affected by the EU GDPR.

      

      

      
Section 6.2.1 =
forbids Route headers in initial INVITE requests. The example

      
in 6.2.2 has a =
very visible Route: header in the initial request.

      

      
Section 6.2.3 =
talks about an xCard without any references or comments

      
about trust =
for that information.

      

      
Section =
6.2.4:

      

      
"The RUE MUST =
accept inbound calls sent to it by the proxy mentioned

      
   in the =
configuration.=E2=80=9D

      

      
The proxy is =
found using DNS and may be a list created from NATPR/DNS SRV

      
records. What =
is the defintion of =E2=80=9Cthe proxy=E2=80=9D in this statement?

      

      
"If Multiple =
simultaneous RUE SIP registrations from different RUE

      
   devices =
with the same SIP URI exist, the Provider MUST parallel fork   the call =
to all registered RUEs so that they ring at the same time.


      
   The first =
RUE to reply with a 200 OK answers the call and the
   Provider MUST CANCEL other call branches.

      
"

      
Is this =
normative (you have many MUST here). If so - how does this

      
change the =
behaviour of RFC 3261?

      
Also, I think =
this texts forgets about SIP outbound. Since Outbound is a MUST,

      
you need to =
clarify the mix of parallell and serial forking that will happen.

      

      

      
Section =
6.3:

      

      
"The RUE MUST =
support   REFER to enable call transfer.=E2=80=9C

      


      

      
Which combination of REFER? I assume that =E2=80=9CM=
id call
        signaling=E2=80=9D is =E2=80=9Cin-dialog transactions=E2=80=9D =
in SIP lingo,

      
but REFER with or without Replaces? With or =
without
        subscription for updates?

      


      

      
Section 6.4:

      


      

      
" Relay Service URIs and User Address of Records (AoR)
          MUST resolve (in

      
   accord with =
[RFC3263]) to globally routable IPv4 =
addresses.  The AoRs
   MAY also resolve to IPv6 addresses.=E2=80=9D

      

      
How do you =
resolve a complete URI into an IP address? I guess you mean

      
the domain =
part that resolves to a list of addresses using DNS.

      
Why is IPv4 a =
MUST?

      

      
Section =
8:

      

      
"All media =
streams between the RUE and another endpoint or relay

      
   Provider =
MUST be exchanged using the secure real-time transport
   protocol (SRTP) [RFC3550] =
using DTLS [RFC5763], [RFC5764], except
   that for backwards compatibility with older video endpoints, RTP MAY
   be negotiated if SRTP negotiation fails.

      
=E2=80=9C

      


      

      
How do you handle the risk of downgrade attacks
        here? That exception is dangerous

      
and maybe should be handled elsewhere, not in the
        client. 

      


      

      


      

      
Section 11.1

      


      

      
The example operator URI for red.example.net seems
        to lack =E2=80=9C;user=3Ddialstring=E2=80=9D

      


      

      
Section 11.2

      


      

      
"outbound-proxies: (OPTIONAL) A list of URIs of SIP
          proxies to be

      
      used =
when sending requests to the Provider.  Multiple URIs
      identify alternative (redundant) paths to the Provider.

      
=E2=80=9C

      


      

      
Outbound proxy is of course something you look up =
in
        DNS to get the list of

      
actual servers. Is there a need to have an
        additional list in this json format?

      


      

      
" ice-servers=E2=80=9D =
- propably a
          bad name. I don=E2=80=99t remember seeing =E2=80=9Cice =
server=E2=80=9D as a term.

      
As turn servers are =
also
          STUN servers, I think =E2=80=9Cturn-servers=E2=80=9D is =
better.

      


        

      
=E2=80=9Ccredentials=E2=80=
=9D: This is
          tricky indeed. Sending credentials in clear text like =
this,

      
even if it=E2=80=99s =
over HTTPS is
          an interesting approach in this age and time.

      
Regardless of that, =
make
          sure you consider OAuth/OpenID connect auth

      
for some =
services.

      


        

      
=E2=80=9Clifetime=E2=80=9D=
:; You are really
          not clear on what happens when the configuration

      
expires. Is the RUE
          forbidden to use anything here? What about emergency =
calls

      
- will they work even
          without configuration?

      


      

      
General:

      


        

      
You do not mention =
bundling
          of RTP streams, which may be beneficial here.

      


        

      
Good =
work!

      


        

      
/O

      


        

      


      

      


      

      


      

      


      

      

      

    

    
--=20
-----------------------------------------
Gunnar Hellstr=C3=B6m
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288

  




=

--Apple-Mail=_9B85C179-D4DC-4BA7-B201-065CF78C28B7--


From nobody Tue Jul 23 14:59:26 2019
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 E40AD12001B for ; Tue, 23 Jul 2019 14:59:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Level: 
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEy__luG6cwg for ; Tue, 23 Jul 2019 14:59:11 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06F91209A0 for ; Tue, 23 Jul 2019 14:59:11 -0700 (PDT)
Received: from dhcp-9ab9.meeting.ietf.org ([IPv6:2001:67c:1232:144:ad94:7b0b:cb29:fa61]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6NLx9kZ053194 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Tue, 23 Jul 2019 16:59:10 -0500 (CDT) (envelope-from mahoney@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563919151; bh=JZMs5q/KMuaXlQfPm2QIRz1Ye9z9tvMIZw3GMZ936y0=; h=To:From:Subject:Date; b=NY0z2KfdxNqxQtJw9hfrERjzbv0k4hu6hfaD5eAe2HsS4HYM12zTHHZqp6Ad/peAj +jp27bj3Zzkg6mfDN5nk/86+Yngi3MdVjg9w92wRClqDSOJicMKSfsAPdbwieCWtuV 74U26E1hTiifwed3F515SZ6MBUbxR7zRDWwMSldE=
X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:1232:144:ad94:7b0b:cb29:fa61] claimed to be dhcp-9ab9.meeting.ietf.org
To: rum@ietf.org
From: "A. Jean Mahoney" 
Message-ID: <3ee04a2f-b70f-0275-9fb5-08168cbff01e@nostrum.com>
Date: Tue, 23 Jul 2019 17:59:09 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [Rum] Notes from the IETF 105 RUM meeting
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Jul 2019 21:59:24 -0000

See below. I marked things that I missed with ...

Corrections/additions welcome!

Jean

========================================================================

RUM WG Meeting
IETF 105 - Montreal
Tuesday, July 23, 2019, 1520 - 1650
Chairs: Brian Rosen, Paul Kyzivat

------------------------------------------------------------------------
Introduction [0:10]
Chairs
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-chair-slides-00

Note taker - Jean Mahoney
Jabber scribe - Jonathan Lennox

No changes to the agenda.

------------------------------------------------------------------------
Goal review - why we need and are ready for a standard: [0:15]
Eric Burger
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-rum-goal-review-00

Eric - How the IETF and governments can work together. Video 
interpretation for deaf users. The video phones are proprietary - either 
HW and/or SW. The time is right to create a globally standard interface 
- this is not limited to the US. We have the tools - the vendors may 
consider SRTP. Looking forward to refinements and help on coming up with 
a standard.

The FCC runs (through a contractor) an interoperability event. We can 
make sure the profile we create works.

Any questions?



------------------------------------------------------------------------
Document History: [0:15]
Henning Schulzrinne
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-rum-history-background-00

slide 1: Title

slide 2: What is a Video Relay Service Call?

Henning - The solution has been around for a long time. Started with 
H323 and TV sets, now looks like modern video conferencing.

slide 3: Databases

Henning - ENUM database is used to establish eligibility of users, binds 
a TN to a Tel URL and management and eligibility info.

slide 4: All relay services are just media combinations

Henning - The largest user of VRS is for communication between deaf 
individuals - p2p, but relay services should inform our discussions.

slide 5: 

slide 6: What are the recurring problems?

Henning - There is difficulty with making calls between providers. One 
provider has 85% market share. Had been difficult getting good quality 
connection between two different providers. That problem is mainly 
solved. The remaining problem is device/SW porting. 300k users of VRS - 
small market.



Henning - Want to support additional platforms beyond Apple or Windows - 
in-home platforms for instance. Users want to switch providers when 
calls drop or there are long waits.

slide 7: The full interoperability cake

Henning - In the IETF we never managed to get configuration retrieval 
standardized and used. Cherry on top is voice & video mail, address book 
porting

slide 8: Incomplete timeline

Henning - We have tried for the last 7 years to work on this. MITRE's 
initial release VATRP is Windows only. There are a lot of people that 
are not eligible - can sign ASL but are friends, or teachers, or 
corporations or governments that want to hire ASL signers and use the 
service. MITRE's been working on it.

slide 9: 

Henning - Original charter at SIPForum.

slide 10: 

Henning - What we do in the working group should be compatible with this.

slide 11: VRS interoperability events

slide 12: Other related efforts

Henning - RCS has fleshed out the specs. It will be helpful to consider 
them. It would be good to create a bridge between RUM and RCS, if they 
are gatewayable without media gateways.

Paul Kyzivat - In full disclosure. I've been the editor of the VRS 
Profile. The new version will have SRTP.

------------------------------------------------------------------------
Interoperability Profile for Relay User Equipment [0:30]
Brian Rosen
https://tools.ietf.org/html/draft-rosen-rue-00
https://datatracker.ietf.org/meeting/105/materials/slides-105-rum-draft-rosen-rue-00

slide 1: Title

Brian - I'm working on an update to the draft. I'm going to incorporate 
Olle's feedback, and I appreciate his feedback. If others could read the 
draft and provide input, that would be great.

slide 2: Table of Contents

Brian -  The media section will reference WebRTC media specs in next 
version.

slide 3: SIP Signaling

Brian - the VRS-specific case here is dial-round, and short-circuit 
signaling for that.

slide 4: Media

slide 5: SRTP

Brian - This section will be impacted by the WebRTC specs.

slide 6: Contacts

slide 7: Provisioning

slide 8: What's next?

Brian - If the WG decides to adopt the draft, we'll decide which 
sections we want to keep or change. The next version will include Olle's 
feedback and WebRTC specs, before the end of this week hopefully. I will 
appreciate any reviews.

Jonathon Lennox - a tricky thing - WebRTC doesn't include real-time text.

Brian - Yes, but if we use the data channel - there's issue with 
backward compatibility. Realtime text is not a high bitrate... Solve 
this in the standard SIP-based way.

Paul - Has anyone implemented realtime text over datachannel?

Adam Roach - I don't know. It's something an application would 
implement, not the browser. It's simple, but you don't want to push it 
into terminals that don't implement the datachannel stack. Use the SIP 
related one. Maybe after we deploy this we could add it on.

Brian - There are some university groups that code these kind of apps. 
Maybe we can get a group together - this is a student-sized project. See 
if we can get a group interested in an open source environment.

Bernard Aboba - ORTCweb (sp?) - there's an open source project.

Brian - Send me an email on that.

ACTION: Bernard to send Brian email regarding the open source project 
that Bernard mentioned.

Chris Wendt - Authentication, giving out SIP credentials... MD5 hash. 
Are there thoughts about expanding that?

Brian - It's not secure enough. We need to change that. What's in the 
draft won't fly in the IETF - get that in the notes.

Henning - 

Brian - Henning is talking about user configuration - current solution 
is username and password stored in files. Need to change that. Current 
doc has a standard method for configuration - a json object. Hope to 
refine that.

Jonathan for James Hamlin - Can we clarify that RUM is a user endpoint 
interface whereas access from call centers and other video platforms is 
a network to network interface. Sorry for delayed interruption.

Brian - this is the UNI interface, not an NNI interface. Not provider to 
provider.

Paul - The stuff MITRE is doing - they act like a provider. Interface 
NNI - connect to users who are not deaf.

Brian - the FCC has contracted MITRE to do interop testing. VATRP - they 
test it through their own provider interface. They make another call to 
another provider endpoint. VATRP is based on winphone - just does a user 
device.

Paul - To James' point - If you have a call center that has employees 
that can sign and want to communicate to deaf people, you have to 
connect to one of the existent providers. There are no regulations for 
that. Or need support for the NNI interface.

Brian - NNI interface is out of scope. MITRE has an interface like that 
- uses WebRTC. Scope is user device to provider.

Eric - is there source code available?

Brian - There's a release process with the standard lawyer problem. I'll 
post it to the list.

Henning - January 2019 in GitHub, for Windows. It's in the links of my 
presentation.

Jim Malloy in chat room - v1.0 (Jan 2019) is here 
https://github.com/mitrefccace/fcc-vatrp

Jonathan Lennox - Is it a goal that it should be implementable in a 
browser in WebRTC?

Brian - During the bashing the charter, earlier versions said desirable, 
now there is less emphasis. As an individual, I would like to see that. 
Build a WebRTC server with a SIP backend to meet the spec. Interop with 
VRS endpoint. I would appreciate your help in doing that.

Chris Wendt - That should be possible.

Paul - need to get the media right.

Chris - Do we take on security in provisioning?

Brian - If we can't do that, then shouldn't be in the draft. I welcome 
suggestions on how to do that. IETF has tried to do provisioning. Not 
implementable. You have to get security right or it won't get implemented.

Jonathan for Meetecho - That sounds like something Janus can help with 
:) https://janus.conf.meetecho.com.  It's open source, and has a 
controllable SIP gatewaying functionality in the server.

Gunner Hellstrom - This is a good action. I heard from Eric he wants it 
to be global. In Europe we haven't discussed security provisioning. We 
have an ETSI standard for VRS, but it does not cover security or 
provisioning. I don't know how to handle contacts. Maybe move it into 
another spec. The hope I hear from Henning, GSMA interoperability is in 
conflict with the hope to have WebRTC interoperability. WebRTC is not 
IMS. Need to specify which way to go.

Brian - We can split the doc into multiple drafts. I would like to find 
the problem we can't solve quickly. Hope the contact will .... security 
issues that don't have obvious answers. Personally, I want to see the 
WebRTC specs. IR-94 - proper subset. .... we'll check out.

Henning - IR94 - I would like to see gatewaying relatively 
straightforward. plain SIP on one side, IMS on the other side. On 
provisioning, one of the differences that makes it tractable - it's a 
2-stage provisioning model. Users have identities with providers. Stores 
with public key/private key. Non-visible bootstrapping that you can use. 
Maybe it  looks like a cloud, ssh kind of model. Or strings that you 
copy into a SIP registrar.

Brian - Or could do it with oauth. Have a primary that stores the info. 
We can explore.

Chris - oauth is something to look at. Sometimes terminals don't have 
the capabilities to enter that information though.

Brian - we'll have to decide how far down the rat hole we want to go 
down. Devices have gotten better, but there are still devices that have 
issues.

Lennox - I didn't find in the draft, how do you specify multiple 
possible sign languages?

Brian - lang tags in the INVITE. I thought I had it in there, but maybe 
not.

Paul - With regard for call to adopt, more than half dozen have read it --

Brian - I'll put the new version out, and then we'll do a call of the 
adoption on -01 on list.


[End of meeting]



From nobody Thu Jul 25 13:07:09 2019
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 38C081201E3 for ; Thu, 25 Jul 2019 13:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mitre.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jpUlQV5jte5 for ; Thu, 25 Jul 2019 13:07:05 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (smtpvmsrv1.mitre.org [192.52.194.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C88231201DB for ; Thu, 25 Jul 2019 13:07:05 -0700 (PDT)
Received: from smtpvmsrv1.mitre.org (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 116726C0040; Thu, 25 Jul 2019 16:07:05 -0400 (EDT)
Received: from smtprhmv1.mitre.org (unknown [128.29.154.203]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by smtpvmsrv1.mitre.org (Postfix) with ESMTPS id 014EC6C003A; Thu, 25 Jul 2019 16:07:05 -0400 (EDT)
Received: from mwfesmtp-mgt.mitre.org (unknown [192.52.194.235]) by smtprhmv1.mitre.org (Postfix) with ESMTP id E97D280BE7B; Thu, 25 Jul 2019 16:07:04 -0400 (EDT)
Received: by mwfesmtp-mgt.mitre.org (Postfix, from userid 600) id 45vjt06bkzz3DY9m; Thu, 25 Jul 2019 20:06:16 +0000 (UTC)
Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01lp2054.outbound.protection.outlook.com [104.47.62.54]) by mwfesmtp-mgt.mitre.org (Postfix) with ESMTPS id 45vjs23trRz3DY8S; Thu, 25 Jul 2019 20:06:14 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fBLrwSVHCAPQjCgbqK3tzIjfXi+d0dNhRJAnWIWGj3S+IT28l8Sor6n0h9c18n94e3ilgSlp6hjcGxa0vAF07AqqgdgrIb5427O3OOCY8j5GSxBz5Fpr94MB54tkEBmVWJ2pZnB6/ScOYoHUIci/W0kBvyoq5wKsnzZJ6jNbcSOP5+ZbY1MEu9hfH1LEhEAcz7UTJ4QQwkscotiEAl2eOpGl0z9C6IB94r1Li+xGl++2ZPRKHmAwfzkKguVMa37Vi5S2ccjeQvUGWYT7UNaY4e4SDIb0CYxWM88EGbWC35UW9bUU4mi03/BQEu+lHfYrtVJTTysex6XxPcPl5q5Mkg==
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=od3sbHBBeuoQx864dgukV7mYwA9ut17ZGelyVo1dMa8=; b=VLLGgf+tMvQE5JWWRo7+VHDCKepmp8m4AgH+IateaqaL8DE+LEIB4g4znt3ENqGLjnBW6twwxGuykUCgJ6hC2wcj2N3WSFDnIHcv0os4A4k0Gad3IIWuR4IFTG3H1W572FGJiES3tQfQozdw/F9m/H8lm0Uif2W8mcm/6cTmllUD3DUTOoHhUfWcWy7iTUqPfbjKg0WJYdXHn8oeXqKq1DcuhC3ejJglGt1NkpslWTn8Jf5SXBaLviBrI2EuWWKm0xjqKGrnAmpv+bSHVfSFv61f4NyavpZ+ti2MJMXjj/pYCKZedb8naS0IYnYnygIIp1b5xveR9ord+MplTh0BsQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mitre.org;dmarc=pass action=none header.from=mitre.org;dkim=pass header.d=mitre.org;arc=none
Received: from BY5PR09MB4018.namprd09.prod.outlook.com (52.133.255.141) by BY5PR09MB4166.namprd09.prod.outlook.com (52.135.41.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Thu, 25 Jul 2019 20:06:13 +0000
Received: from BY5PR09MB4018.namprd09.prod.outlook.com ([fe80::81c6:2fd5:83d2:7a21]) by BY5PR09MB4018.namprd09.prod.outlook.com ([fe80::81c6:2fd5:83d2:7a21%7]) with mapi id 15.20.2115.005; Thu, 25 Jul 2019 20:06:13 +0000
From: "Janett, Amy E." 
To: Brian Rosen , "rum@ietf.org" 
Thread-Topic: [EXT] [Rum] Let's get into it
Thread-Index: AQHVNo9R1b8FPTab7UqSjk8nVF1Si6bb2eQw
Date: Thu, 25 Jul 2019 20:06:13 +0000
Message-ID: 
References: <28503_1562701690_5D24EF7A_28503_65_4_8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net>
In-Reply-To: <28503_1562701690_5D24EF7A_28503_65_4_8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
authentication-results: spf=none (sender IP is ) smtp.mailfrom=ajanett@mitre.org; 
x-originating-ip: [192.80.55.89]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 13a408ae-c2e3-4399-5077-08d7113b8b4b
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BY5PR09MB4166; 
x-ms-traffictypediagnostic: BY5PR09MB4166:
x-ms-exchange-purlcount: 10
x-microsoft-antispam-prvs: 
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0109D382B0
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(136003)(366004)(39860400002)(199004)(189003)(7736002)(6246003)(110136005)(3846002)(790700001)(6116002)(316002)(99286004)(33656002)(76176011)(7696005)(14444005)(186003)(256004)(71190400001)(68736007)(71200400001)(446003)(476003)(8936002)(8676002)(81156014)(81166006)(6506007)(2501003)(53546011)(102836004)(52536014)(236005)(966005)(86362001)(478600001)(606006)(53936002)(2906002)(486006)(6436002)(76116006)(74316002)(14454004)(66946007)(66446008)(64756008)(66556008)(66476007)(9686003)(26005)(229853002)(25786009)(54896002)(6306002)(5660300002)(55016002)(66066001)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY5PR09MB4166; H:BY5PR09MB4018.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: mitre.org does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: SOx7BWPkILBGA7W3ke54WUaiOU0+PrsRKrh1vX3DlyIML251V2S9Za9JbhtSBgVGUtldYcKCiTjZPXgw2mYbxL5urhMEczlA1LIBKlJWx4OwfciUvf0b7R1etUA6VXVKJno2VY3C5F7wpFWnYCeFlfN9RLXf1T28QLUC22FLpMoxcZRwr7/8VSM/HA6GhYta5Z+y95NCLjrW4X2h1U2gWsA6k3CLV5mLdeU4R+zikeEv/kzPv3CMKDzjUfJ//OTSvHxPHG3+jU8ApP/DgNl0DW2Bf05H1peMGqAY1Zvg59MeeEKTm/GXYyO9FfuL60n1i9DTMdpnPpBa4Rmv5zGGITGEbuiyHm/5BHPL/TS3Ku25FqJN2jbS1BcOsiSzP2eBjsIBa+rH0MuT2n6vXtVPVYHUH55zGr0kGuQfLKzoRiw=
Content-Type: multipart/alternative; boundary="_000_BY5PR09MB4018854DBC4F0BFA4C1448D3A8C10BY5PR09MB4018namp_"
MIME-Version: 1.0
X-OriginatorOrg: mitre.org
X-MS-Exchange-CrossTenant-Network-Message-Id: 13a408ae-c2e3-4399-5077-08d7113b8b4b
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2019 20:06:13.2217 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: AJANETT@MITRE.ORG
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB4166
X-MITRE: 8GQsMWxq66rxk57w
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mitre.org; h=from:to:subject:date:message-id:references:in-reply-to:content-type:mime-version; s=selector1; bh=od3sbHBBeuoQx864dgukV7mYwA9ut17ZGelyVo1dMa8=; b=tM0OntCY486LsKgNNv9IuBDmkOOm34n75BYawz1XlhezhUkglCGNXilEZHZMMC1K49hkl2dksDS2wwfTT8Tg/3BuIbClyFwyLit9G06CbSXxBe/f+qmaGKylykpMgPnguX2+zN6E9m9WrDuw6u1E/7HzrBuuDsSMK7EIrDS9+qE=
Archived-At: 
Subject: Re: [Rum] [EXT]  Let's get into it
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 25 Jul 2019 20:07:08 -0000

--_000_BY5PR09MB4018854DBC4F0BFA4C1448D3A8C10BY5PR09MB4018namp_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SW4gc2VjdGlvbiAxMS4yIFJVRSBDb25maWd1cmF0aW9uIFNlcnZpY2UsIHRoZXJlIGFyZSAyIGFy
ZWFzIHdoZXJlIHRoZSBleGFtcGxlIEpTT04gZmlsZSBpcyBtYWxmb3JtYXR0ZWQ6DQoNCjEuIFRo
ZSDigJxjb250YWN0c+KAnSBVUkwgbmVlZHMgYSBjb21tYSBhdCB0aGUgZW5kIG9mIHRoaXMgbGlu
ZToNCg0KICAgICAiY29udGFjdHMiOiAiaHR0cHM6Ly9yZWQuZXhhbXBsZS5uZXQ6NDQzL2NvbnRh
Y3RzLzFkZXNzNDVhd2Q8aHR0cHM6Ly9yZWQuZXhhbXBsZS5uZXQvY29udGFjdHMvMWRlc3M0NWF3
ZD4iDQoNCjIuIFRoZSBvYmplY3RzIGluIHRoZSDigJxpY2Utc2VydmVyc+KAnSBhcnJheSBuZWVk
IHRvIHRha2UgYSBmaWVsZDp2YWx1ZSBmb3JtYXQsIG5vdCBqdXN0IHN0cmluZ3MuIEkgcHJvcG9z
ZSB1c2luZyBlaXRoZXIg4oCcc3R1buKAnSBvciDigJx0dXJu4oCdIGFzIHRoZSBmaWVsZCwgYW5k
IHVzaW5nIHRoZSBjdXJyZW50IHN0cmluZyBhcyB0aGUgdmFsdWUuIEZvciBleGFtcGxlLA0KImlj
ZS1zZXJ2ZXJzIjogWw0KICAgICAgICAgIHvigJxzdHVu4oCdOiJzdHVuOnN0dW4ubC5nb29nbGUu
Y29tOjE5MzAyIn0sDQogICAgICAgICAge+KAnHR1cm7igJ06InR1cm46dHVybi5yZWQuZXhhbXBs
ZS5uZXQ6MzQ3OCJ9DQogICAgICAgXSwNCkFub3RoZXIgb3B0aW9uIHdvdWxkIGJlIHRvIHVzZSDi
gJx1cmnigJ0gZm9yIHRoZSBmaWVsZCBmb3IgYm90aCBTVFVOIGFuZCBUVVJOIHNlcnZlcnMuDQoN
Cg0KRnJvbTogUnVtIDxydW0tYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEJyaWFuIFJv
c2VuDQpTZW50OiBUdWVzZGF5LCBKdWx5IDksIDIwMTkgMTU6NDgNClRvOiBydW1AaWV0Zi5vcmcN
ClN1YmplY3Q6IFtFWFRdIFtSdW1dIExldCdzIGdldCBpbnRvIGl0DQoNClBsZWFzZSByZWFkIGh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3Nlbi1ydWUtMDANCg0KUGxlYXNlIGNv
bW1lbnQgb24gYW55dGhpbmcuICBJIHdpbGwgcHJvcG9zZSB3ZSBhZG9wdCB0aGlzIGFzICB0aGUg
YmFzaXMgb2Ygb3VyIHdvcmssIGJ1dCBJ4oCZbSBoYXBweSB0byBkbyBhbnl0aGluZyBvbiBpdCBi
ZWZvcmUgaGFuZC4NCklmIGl0IGlzIGFkb3B0ZWQsIGNoYWlycyB3aWxsIGFwcG9pbnQgYSBub24t
Y2hhaXIgZWRpdG9yLg0KDQpPbmUgc3BlY2lmaWMgSSBrbm93IGFib3V0Og0KDQpUaGUgY2hhcnRl
ciBkaXNjdXNzZXMgcmUtdXNpbmcgdGhlIFdlYlJUQyBtZWRpYSBzcGVjcy4gIFRoZSBtb3N0IGRp
cmVjdCB3YXkgdG8gZG8gdGhhdCBpcyByZWZlcmVuY2U6DQpGb3IgbWVkaWEgYW5kIG1lZGlhIHRy
YW5zcG9ydDoNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcnRjd2Vi
LXJ0cC11c2FnZS0xNw0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc4NzQNCmh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzQyDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0
bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJhbnNwb3J0cy0xNw0KDQpGb3IgaXNzdWVzIGFyb3VuZCBt
ZWRpYSBzZWN1cml0eToNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0
Y3dlYi1qc2VwLTI1I3NlY3Rpb24tNS4uMTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtaWV0Zi1ydGN3ZWItanNlcC0yNSNzZWN0aW9uLTUuMT4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNoLTE4I3NlY3Rpb24tNi41DQoN
ClBhdWwgSyBtYWRlIGEgc3VnZ2VzdGlvbiB0aGF0IHRoZXJlIHdlcmUgdGhlIFNJUC9NTVVTSUMg
ZG9jdW1lbnRzIGRvbmUgb3IgaW4gcHJvZ3Jlc3MgdGhhdCBhcmUgdGhlbXNlbHZlcyBpbnRlbmRl
ZCB0byBiZSBjb21wYXRpYmxlIHdpdGggV2ViUlRDLg0KDQpQcmVmZXJlbmNlcz8NCg0KQnJpYW4N
Cg0K

--_000_BY5PR09MB4018854DBC4F0BFA4C1448D3A8C10BY5PR09MB4018namp_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj
cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv
VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg
Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv
ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl
PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m
YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx
IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg
NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i
Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg
Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp
bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh
bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1
bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy
bGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAw
MDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K
c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt
YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI
VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLm1zb25v
cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z
b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K
CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp
emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h
aWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5
OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg
djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm
IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw
IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm
XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw
bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu
IHNlY3Rpb24gMTEuMiBSVUUgQ29uZmlndXJhdGlvbiBTZXJ2aWNlLCB0aGVyZSBhcmUgMiBhcmVh
cyB3aGVyZSB0aGUgZXhhbXBsZSBKU09OIGZpbGUgaXMgbWFsZm9ybWF0dGVkOjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4xLiBUaGUg4oCcY29udGFjdHPigJ0gVVJMIG5lZWRzIGEgY29tbWEgYXQg
dGhlIGVuZCBvZiB0aGlzIGxpbmU6PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZxdW90O2NvbnRhY3RzJnF1b3Q7
OiAmcXVvdDs8YSBocmVmPSJodHRwczovL3JlZC5leGFtcGxlLm5ldC9jb250YWN0cy8xZGVzczQ1
YXdkIj5odHRwczovL3JlZC5leGFtcGxlLm5ldDo0NDMvY29udGFjdHMvMWRlc3M0NWF3ZDwvYT4m
cXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Mi4gVGhlIG9iamVjdHMgaW4g
dGhlIOKAnGljZS1zZXJ2ZXJz4oCdIGFycmF5IG5lZWQgdG8gdGFrZSBhIGZpZWxkOnZhbHVlIGZv
cm1hdCwgbm90IGp1c3Qgc3RyaW5ncy4gSSBwcm9wb3NlIHVzaW5nIGVpdGhlciDigJxzdHVu4oCd
IG9yIOKAnHR1cm7igJ0gYXMgdGhlIGZpZWxkLCBhbmQgdXNpbmcgdGhlIGN1cnJlbnQgc3RyaW5n
IGFzIHRoZSB2YWx1ZS4gRm9yIGV4YW1wbGUsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD
b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+JnF1b3Q7aWNlLXNlcnZlcnMmcXVvdDs6IFs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv
cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IHvigJxzdHVu4oCdOiZxdW90O3N0dW46c3R1bi5sLmdvb2dsZS5jb206MTkzMDImcXVv
dDt9LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7
O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsge+KAnHR1cm7igJ06JnF1b3Q7dHVybjp0dXJuLnJlZC5leGFtcGxlLm5ldDoz
NDc4JnF1b3Q7fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
XSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Bbm90aGVyIG9w
dGlvbiB3b3VsZCBiZSB0byB1c2Ug4oCcdXJp4oCdIGZvciB0aGUgZmllbGQgZm9yIGJvdGggU1RV
TiBhbmQgVFVSTiBzZXJ2ZXJzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv
bzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk
ICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48Yj5Gcm9tOjwvYj4gUnVtICZsdDtydW0tYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+
T24gQmVoYWxmIE9mIDwvYj4NCkJyaWFuIFJvc2VuPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXks
IEp1bHkgOSwgMjAxOSAxNTo0ODxicj4NCjxiPlRvOjwvYj4gcnVtQGlldGYub3JnPGJyPg0KPGI+
U3ViamVjdDo8L2I+IFtFWFRdIFtSdW1dIExldCdzIGdldCBpbnRvIGl0PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgcmVhZCZuYnNwOzxhIGhyZWY9Imh0dHBz
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3Nlbi1ydWUtMDAiPmh0dHBzOi8vdG9vbHMu
aWV0Zi5vcmcvaHRtbC9kcmFmdC1yb3Nlbi1ydWUtMDA8L2E+PG86cD48L286cD48L3A+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgY29tbWVudCBvbiBhbnl0aGluZy4gJm5i
c3A7SSB3aWxsIHByb3Bvc2Ugd2UgYWRvcHQgdGhpcyBhcyAmbmJzcDt0aGUgYmFzaXMgb2Ygb3Vy
IHdvcmssIGJ1dCBJ4oCZbSBoYXBweSB0byBkbyBhbnl0aGluZyBvbiBpdCBiZWZvcmUgaGFuZC48
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGl0
IGlzIGFkb3B0ZWQsIGNoYWlycyB3aWxsIGFwcG9pbnQgYSBub24tY2hhaXIgZWRpdG9yLjxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz
cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbmUgc3Bl
Y2lmaWMgSSBrbm93IGFib3V0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5UaGUgY2hhcnRlciBkaXNjdXNzZXMgcmUtdXNpbmcgdGhlIFdlYlJU
QyBtZWRpYSBzcGVjcy4gJm5ic3A7VGhlIG1vc3QgZGlyZWN0IHdheSB0byBkbyB0aGF0IGlzIHJl
ZmVyZW5jZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+Rm9yIG1lZGlhIGFuZCBtZWRpYSB0cmFu
c3BvcnQ6PGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0xNyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWlldGYtcnRjd2ViLXJ0cC11c2FnZS0xNzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov
L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzg3NCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L3JmYzc4NzQ8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm
Yzc3NDIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NzQyPC9hPjxicj4NCjxhIGhy
ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi10cmFuc3Bv
cnRzLTE3Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1ydGN3ZWItdHJh
bnNwb3J0cy0xNzwvYT48YnI+DQo8YnI+DQpGb3IgaXNzdWVzIGFyb3VuZCBtZWRpYSBzZWN1cml0
eTo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y
dGN3ZWItanNlcC0yNSNzZWN0aW9uLTUuMSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry
YWZ0LWlldGYtcnRjd2ViLWpzZXAtMjUjc2VjdGlvbi01Li4xPC9hPjxicj4NCjxhIGhyZWY9Imh0
dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJ0Y3dlYi1zZWN1cml0eS1hcmNo
LTE4I3NlY3Rpb24tNi41Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1y
dGN3ZWItc2VjdXJpdHktYXJjaC0xOCNzZWN0aW9uLTYuNTwvYT48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGF1bCBLIG1hZGUgYSBzdWdnZXN0
aW9uIHRoYXQgdGhlcmUgd2VyZSB0aGUgU0lQL01NVVNJQyBkb2N1bWVudHMgZG9uZSBvciBpbiBw
cm9ncmVzcyB0aGF0IGFyZSB0aGVtc2VsdmVzIGludGVuZGVkIHRvIGJlIGNvbXBhdGlibGUgd2l0
aCBXZWJSVEMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
UHJlZmVyZW5jZXM/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5CcmlhbjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--_000_BY5PR09MB4018854DBC4F0BFA4C1448D3A8C10BY5PR09MB4018namp_--