Re: [Rum] Media security

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 01 October 2019 23:51 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 433CB1202A0 for <rum@ietfa.amsl.com>; Tue, 1 Oct 2019 16:51:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 anKKuX9MAfpx for <rum@ietfa.amsl.com>; Tue, 1 Oct 2019 16:51:42 -0700 (PDT)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (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 E932E120132 for <rum@ietf.org>; Tue, 1 Oct 2019 16:51:41 -0700 (PDT)
Received: from Kokiri.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x91NpabF009404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 1 Oct 2019 19:51:37 -0400
To: Brian Rosen <br@brianrosen.net>, MARTIN C DOLLY <md3135@att.com>
Cc: "rum@ietf.org" <rum@ietf.org>
References: <8FB5F5A0-E3FE-40F8-A6D0-35D9002C6770@brianrosen.net> <85828597-D024-4E7E-8876-F1C4753E6B7D@edvina.net> <64B406DC-4171-41EB-9171-A2AF7B78B409@brianrosen.net> <a3d82911-8d07-16a3-780b-0592e48e37bd@alum.mit.edu> <69F15B2A-0158-4D23-B090-642497E3BDC7@brianrosen.net> <fa8e7a65-d818-58eb-a432-f8a57ed6af95@nostrum.com> <3fdefa0c-3a64-3445-8ceb-d293fe4b4831@alum.mit.edu> <60DFA478-5042-41FD-87CD-DD2154D6B1E6@brianrosen.net> <C4670F1F-4AEC-45BE-9898-06FF2E28A6A9@standardstrack.com> <1fed09ae-8a03-2d82-3784-c4b47095cff0@alum.mit.edu> <1567413580412.20641@purple.us> <53694d4e-5d50-6848-d631-7367dd407793@alum.mit.edu> <4870F224-EB7F-4E58-99AD-19D5449E745F@brianrosen.net> <62dcb70c-dbb9-63d9-0470-3149fc67bca3@omnitor.se> <D7293188-DC0C-40A8-9514-308566342170@brianrosen.net> <158541eb-e6c9-0989-9ea5-e2093d813c3e@alum.mit.edu> <0dc33e35-24a0-243e-b65b-a1429f55b853@alum.mit.edu> <86E626A9-C13D-4106-B423-98223BF26D84@att.com> <8D68FC26-6F7B-45AA-B615-BCA8193BC76F@brianrosen.net>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <8297d07c-b488-4e04-745b-df38b9b317e9@alum.mit.edu>
Date: Tue, 1 Oct 2019 19:51:36 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <8D68FC26-6F7B-45AA-B615-BCA8193BC76F@brianrosen.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rum/uMLMd6djr9uuh9WtLCJgWvAw1MQ>
Subject: Re: [Rum] Media security
X-BeenThere: rum@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Relay User Machine <rum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rum>, <mailto:rum-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rum/>
List-Post: <mailto:rum@ietf.org>
List-Help: <mailto:rum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rum>, <mailto:rum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Oct 2019 23:51:46 -0000

On 10/1/19 5:13 PM, Brian Rosen wrote:
> As a practical matter, isn’t it the case that all providers have Session 
> Border Controllers in the path, and they anchor media at the SBC?

Not entirely. There is some use of ICE, along with e2e media for p2p 
calls. And there is a desire to encourage that.

> If that is true, the RUE can be secure and still connect to an insecure 
> older device.

I don't think it is forbidden (as it is with SIPS) but downgrading 
security along the path is at least deceptive in that it might lead the 
user into a false sense of security.

	Thanks,
	Paul

> Brian
> 
>> On Oct 1, 2019, at 4:19 PM, DOLLY, MARTIN C <md3135@att.com 
>> <mailto:md3135@att.com>> wrote:
>>
>> Agree w Paul
>>
>> Martin C. Dolly
>> Lead Member of Technical Staff
>> Government & Services Standards
>> AT&T
>> Cell: +1.609.903..3360 <tel:+1.609.903.3360>
>> Email: md3135@att.com <mailto:md3135@att.com>
>>
>> On Oct 1, 2019, at 4:14 PM, Paul Kyzivat <pkyzivat@alum.mit.edu 
>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>
>>> I would like to revive the point raised in the attached message that 
>>> had no followup discussion.
>>>
>>> The problem with calling for mandatory media security on the RUE is 
>>> that current VRS calls use insecure media. The VRS Provider Profile 
>>> currently does not specify the RUE interface. It is the 
>>> responsibility of the provider to interface (using SDP rewriting or 
>>> media bridging) the calling RUE to either the terminating RUE or the 
>>> other provider where the terminating RUE is connected. But it would 
>>> be inappropriate (deceptive) to interface secure media to insecure media.
>>>
>>> There are plans to upgrade media security over the VRS Provider 
>>> Profile. The following is a likely path forward, though steps 3-5 are 
>>> speculation on my part:
>>>
>>> 1) The current VRS Provider Profile (v1) specifies insecure media. 
>>> That is what is currently deployed by VRS providers.
>>>
>>> 2) There is a revised VRS Provider Profile (v2) in development. It 
>>> hopefully will be approved by the end of this year. It calls for 
>>> opportunistic media security [RFC8643] between providers. The reason 
>>> is to allow gradual migration of providers to the revised profile.
>>>
>>> 3) Based on past history it may well take a year or more to 
>>> accomplish a complete migration of all providers to the new profile. 
>>> At that time all calls will be using secure media.
>>>
>>> 4) Once that migration is complete it will be possible to make a 
>>> further revision to the profile (v3) that mandates offering 
>>> unprovisional media security while still allowing the acceptance of 
>>> offers of provisional media security. Again this is to allow a 
>>> phase-in period.
>>>
>>> 5) Once that is complete, a v4 of the profile could then mandate 
>>> unprovisional media security.
>>>
>>> If the new RUE spec isn't introduced until step (5) then media 
>>> security can be achieved without any bridging or SDP rewriting. But 
>>> that will likely be multiple years in the future.
>>>
>>> To incorporate the new RUE spec earlier some compromises will be 
>>> required.
>>>
>>> It would be easy to change the RUE spec to use opportunistic media 
>>> security. This would still result in secure media if all entities on 
>>> the signaling path support it. It that won't be assured until step 
>>> (3). Getting this to work with a WebRTC-based RUE (that requires 
>>> secure media) will require at least SDP rewriting.
>>>
>>> Thoughts?
>>>
>>>    Thanks,
>>>    Paul
>>>
>>> On 9/5/19 4:31 PM, Paul Kyzivat wrote:
>>>> On 9/4/19 10:37 AM, Brian Rosen wrote:
>>>>> Yes, for sure T.140 (RFC4103).
>>>>> The providers have SBCs that anchor media, so they can handle 
>>>>> security on one side but not the other.  That’s not a great answer, 
>>>>> but it’s an answer.  Transcoding video is not reasonable.
>>>> The soon to be released updated version of the Provider Profile 
>>>> specifies opportunistic media security [RFC8643].
>>>> Also, while providers use SBCs, some of them can set up e2e media 
>>>> for point to point calls, where the media won't be anchored and 
>>>> security can't be twiddled.
>>>> I think this can be a problem if RUM requires the RUE to signal 
>>>> mandatory media security, which (I think) WebRTC requires.
>>>>     Thanks,
>>>>     Paul
>>>>> Brian
>>>>>
>>>>>> On Sep 4, 2019, at 10:35 AM, Gunnar Hellström 
>>>>>> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> 
>>>>>> <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>>>>>
>>>>>>
>>>>>> Den 2019-09-04 kl. 15:54, skrev Brian Rosen:
>>>>>>> I think our consensus is MTI:
>>>>>>> Audio: G.711 and Opus
>>>>>>> Video: H.264
>>>>>>
>>>>>>  Real-time text: T.140        (I think you said it is mandatory 
>>>>>> for clients, and optional for services.)
>>>>>>
>>>>>>
>>>>>> All these need then transport and security details specified to 
>>>>>> assure interop with RUM.
>>>>>>
>>>>>> How can you hope for backward compatibility with legacy devices 
>>>>>> when it is said in RUM that the security requirements must be met?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Gunnar
>>>>>>
>>>>>>>
>>>>>>> We need to get into the details of H.264 to maintain 
>>>>>>> compatibility with the WebRTC specs and as much backwards 
>>>>>>> compatibility as possible.
>>>>>>>
>>>>>>> Anyone object?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Sep 3, 2019, at 10:48 AM, Paul Kyzivat <pkyzivat@alum.mit.edu 
>>>>>>>> <mailto:pkyzivat@alum.mit.edu> <mailto:pkyzivat@alum.mit.edu>> 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 9/2/19 4:39 AM, James Hamlin wrote:
>>>>>>>>> Just to add: the VRS industry supports a variety of endpoints, 
>>>>>>>>> many of which are hardware based and not built by VRS providers 
>>>>>>>>> themselves. H.264 and G..711 therefore need to be in the MTI list.
>>>>>>>>> I believe the FCC order related to compensation by compliant 
>>>>>>>>> providers not that every call had to come from a compliant 
>>>>>>>>> endpoint.
>>>>>>>> Sorry if I got that wrong. I wrote that from memory and perhaps 
>>>>>>>> my memory is faulty.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Paul
>>>>>>>>
>>>>>>>>> Best Regards
>>>>>>>>> James
>>>>>>>>> ________________________________________
>>>>>>>>> From: Rum <rum-bounces@ietf.org <mailto:rum-bounces@ietf.org> 
>>>>>>>>> <mailto:rum-bounces@ietf.org>> on behalf of Paul Kyzivat 
>>>>>>>>> <pkyzivat@alum..mit.edu <http://mit.edu/> 
>>>>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__mit.edu&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=kUpNW-xdqJT1L5sFJAfr4ONBeIYy3UqsPDUR0lVw8D0&e=>>
>>>>>>>>> Sent: 28 August 2019 16:48
>>>>>>>>> To: rum@ietf.org <mailto:rum@ietf.org> <mailto:rum@ietf.org>
>>>>>>>>> Subject: Re: [Rum] Codec requirements in draft-rosen-rue-01
>>>>>>>>> On 8/28/19 11:25 AM, Eric Burger wrote:
>>>>>>>>>> I guess the question is whether we want today’s devices to 
>>>>>>>>>> have a chance of being RUM compatible. I don’t think anyone 
>>>>>>>>>> will be surprised if a five-year-old device is history. Is it 
>>>>>>>>>> realistic for current devices to get VP8 upgrade? [Would be 
>>>>>>>>>> nice for some manufacturers or others building such devices to 
>>>>>>>>>> pipe in here.]
>>>>>>>>> Lets be clear about what we mean by "RUM compatible".
>>>>>>>>> When Henning and I were working on this with the providers in 
>>>>>>>>> 2014 and
>>>>>>>>> 2015 there was an expectation that the providers would be 
>>>>>>>>> required to
>>>>>>>>> support the defined RUE devices, but they would also be 
>>>>>>>>> permitted to
>>>>>>>>> support their existing proprietary devices. The RUE devices 
>>>>>>>>> could have
>>>>>>>>> requirements that their existing devices don't meet. But calls 
>>>>>>>>> between
>>>>>>>>> the two were expected to work.
>>>>>>>>> There was great consternation when subsequently the FCC issued a
>>>>>>>>> proposed order that said only VRS calls involving 
>>>>>>>>> RUE-compatible devices
>>>>>>>>> would be compensated. (But that was in 2015.. I presume it has 
>>>>>>>>> not happened.)
>>>>>>>>> If there is an intent to exclude non-RUM-compliant devices from 
>>>>>>>>> use in
>>>>>>>>> VRS calls then there needs to be a migration plan to get from 
>>>>>>>>> here to there.
>>>>>>>>>         Thanks,
>>>>>>>>>         Paul
>>>>>>>>>>> On Aug 28, 2019, at 10:38 AM, Brian Rosen <br@brianrosen.net 
>>>>>>>>>>> <mailto:br@brianrosen.net> <mailto:br@brianrosen.net>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> If we require OPUS and G.711 as MTI and we require both H.264 
>>>>>>>>>>> and VP8 as MTI, then we get backwards compatibility without 
>>>>>>>>>>> transcoding and forwards compatibility with WebRTC.  Isn’t 
>>>>>>>>>>> that what we want?
>>>>>>>>>>>
>>>>>>>>>>> Brian
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 28, 2019, at 10:15 AM, Paul Kyzivat 
>>>>>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu> 
>>>>>>>>>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Inline...
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/27/19 5:57 PM, Adam Roach wrote:
>>>>>>>>>>>>> I certainly have thoughts. The executive summary is that I 
>>>>>>>>>>>>> personally believe RUM should specify Opus as the one audio 
>>>>>>>>>>>>> codec MTI, and match RFC 7742's "Non-Browser" requirements 
>>>>>>>>>>>>> for the video codec MTI. Rationale below.
>>>>>>>>>>>>>  From an interop perspective, the important thing is that 
>>>>>>>>>>>>> any given profile has (at least) one MTI video codec and 
>>>>>>>>>>>>> (at least) one MTI audio codec.. I know there is a strong 
>>>>>>>>>>>>> desire -- one that I share -- that these endpoints can talk 
>>>>>>>>>>>>> to/be implemented in web browsers without the need for 
>>>>>>>>>>>>> media transcoding.
>>>>>>>>>>>>> For audio: WebRTC selected G.711 and Opus as both MTI; the 
>>>>>>>>>>>>> former because it works without transcoding to landline 
>>>>>>>>>>>>> PSTN destinations, and the latter because it sounds much, 
>>>>>>>>>>>>> much better. RUM could make the same decision; or it could 
>>>>>>>>>>>>> decide to move away from a codec that is as old as I am and 
>>>>>>>>>>>>> opt to designate Opus as the only MTI. Given that RUM 
>>>>>>>>>>>>> inherently needs to deploy into audio/video environments, 
>>>>>>>>>>>>> backwards compatibility with the PSTN seems to be 
>>>>>>>>>>>>> unnecessary baggage.
>>>>>>>>>>>> Please keep in mind where we are coming from. The RUM will 
>>>>>>>>>>>> be a new interface to the *existing* VRS infrastructure. 
>>>>>>>>>>>> That infrastructure currently has proprietary devices that 
>>>>>>>>>>>> serve the RUE function, deployed to VRS users and to 
>>>>>>>>>>>> Communications Assistants (CAs, Interpreters). These have 
>>>>>>>>>>>> G.711 MTI, and also *recommend* G.722.2.
>>>>>>>>>>>>
>>>>>>>>>>>> Making OPUS the only MTI audio codec would be problematic.
>>>>>>>>>>>>
>>>>>>>>>>>>> For video: While specifying either VP8 or H..264 would be 
>>>>>>>>>>>>> sufficient for system interop, and for interop with 
>>>>>>>>>>>>> compliant WebRTC endpoints, I'd really prefer not to 
>>>>>>>>>>>>> re-live the WebRTC video codec wars. Concretely, what I 
>>>>>>>>>>>>> would propose is that RUM indicate that the video codec 
>>>>>>>>>>>>> requirements are defined to be identical to those defined 
>>>>>>>>>>>>> for "WebRTC Non-Browsers" in Section 5 of RFC 7742. It 
>>>>>>>>>>>>> should be made clear that RUM endpoints *are* *not* WebRTC 
>>>>>>>>>>>>> Non-Browsers per se; merely that they comply with the same 
>>>>>>>>>>>>> video codec requirements as WebRTC Non-Browsers.
>>>>>>>>>>>> Continuing my comment above, existing devices have H.264 
>>>>>>>>>>>> Constrained Baseline Profile, Level 1.3, packetization mode 
>>>>>>>>>>>> 1 as the MTI codec. Odds are many of these devices aren't 
>>>>>>>>>>>> capable of VP8.
>>>>>>>>>>>>
>>>>>>>>>>>> We can't realistically require a wholesale swap out of 
>>>>>>>>>>>> existing devices before the RUE defined by RUM can work. We 
>>>>>>>>>>>> can *discuss* whether forcing the providers to transcode is 
>>>>>>>>>>>> a practical way forward. I'm dubious.
>>>>>>>>>>>>
>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>     Paul
>>>>>>>>>>>>
>>>>>>>>>>>>> /a
>>>>>>>>>>>>> On 8/27/19 2:34 PM, Brian Rosen wrote:
>>>>>>>>>>>>>> Well, we certainly want interoperability, and I think we 
>>>>>>>>>>>>>> can only get that with MTI codecs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think we really are talking about a WebRTC-compatible 
>>>>>>>>>>>>>> endpoint, but we want interoperability with a WebRTC 
>>>>>>>>>>>>>> browser endpoint.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Not sure how to say this.  Maybe Adam can help.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Brian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:20 PM, Paul Kyzivat 
>>>>>>>>>>>>>>> <pkyzivat@alum.mit.edu <mailto:pkyzivat@alum.mit.edu> 
>>>>>>>>>>>>>>> <mailto:pkyzivat@alum.mit.edu>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> draft-rosen-rue-01 changes the video codec requirements. 
>>>>>>>>>>>>>>> It now simply references webrtc RFC7742.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> RFC7742 distinguishes three types of endpoints: "WebRTC 
>>>>>>>>>>>>>>> browser", "WebRTC non-browser", and "WebRTC-compatible 
>>>>>>>>>>>>>>> endpoint". AFAIK it assumes that each end is one of these.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Is the expectation here that both the RUE and the 
>>>>>>>>>>>>>>> provider comply with one of these? In particular, that 
>>>>>>>>>>>>>>> the provider may simply be a "WebRTC-compatible endpoint? 
>>>>>>>>>>>>>>> Notably:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    "WebRTC-compatible endpoints" are free to implement 
>>>>>>>>>>>>>>> any video codecs
>>>>>>>>>>>>>>>    they see fit.  This follows logically from the 
>>>>>>>>>>>>>>> definition of "WebRTC-
>>>>>>>>>>>>>>>    compatible endpoint"..  It is, of course, advisable to 
>>>>>>>>>>>>>>> implement at
>>>>>>>>>>>>>>>    least one of the video codecs that is mandated for 
>>>>>>>>>>>>>>> WebRTC browsers,
>>>>>>>>>>>>>>>    and implementors are encouraged to do so.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Similarly, the audio requirements have been changed to 
>>>>>>>>>>>>>>> reference webrtc RFC7874. That one doesn't have the 
>>>>>>>>>>>>>>> distinction between "WebRTC browser", "WebRTC 
>>>>>>>>>>>>>>> non-browser", and "WebRTC-compatible endpoint". It 
>>>>>>>>>>>>>>> applies the same requirements to all. In particular, it 
>>>>>>>>>>>>>>> requires OPUS support. I don't know why it doesn't make 
>>>>>>>>>>>>>>> the same endpoint distinctions as for video.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think simply referencing these documents isn't 
>>>>>>>>>>>>>>> sufficient. Seems like we need a more nuanced 
>>>>>>>>>>>>>>> specification of what is required, though we may still 
>>>>>>>>>>>>>>> reference these docs with qualifications.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>>>     Paul
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>> -- 
>>>>>>>>>>> Rum mailing list
>>>>>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
>>>>>>>>>>
>>>>>>>>> -- 
>>>>>>>>> Rum mailing list
>>>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
>>>>>>>> -- 
>>>>>>>> Rum mailing list
>>>>>>>> Rum@ietf.org <mailto:Rum@ietf.org> <mailto:Rum@ietf.org>
>>>>>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=
>>>>>>
>>>>>> -- 
>>>>>> -----------------------------------------
>>>>>> Gunnar Hellström
>>>>>> Omnitor
>>>>>> gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se> 
>>>>>> <mailto:gunnar.hellstrom@omnitor.se>
>>>>>> +46 708 204 288
>>>>>
>>>
>>> -- 
>>> Rum mailing list
>>> Rum@ietf.org <mailto:Rum@ietf.org>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e= 
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www..ietf.org_mailman_listinfo_rum&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=G9v8uCSSQhCmpw7ItG0r2g&m=rzxzuZmop7EiiQJd79oRL972tvXJxqhn01LZRSIbMUU&s=X7xP468QMBuG_vivuofaYnOnkS2XR-MaoASurKoOoLc&e=>
>> -- 
>> Rum mailing list
>> Rum@ietf.org <mailto:Rum@ietf.org>
>> https://www.ietf.org/mailman/listinfo/rum
>