From nobody Mon Mar 4 20:08:53 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3BC6130E81; Mon, 4 Mar 2019 20:08:51 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ben Campbell To: "The IESG" Cc: rum-chairs@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155175893161.5224.13269249124891149616.idtracker@ietfa.amsl.com> Date: Mon, 04 Mar 2019 20:08:51 -0800 Archived-At: Subject: [Rum] Ben Campbell's Yes on charter-ietf-rum-00-00: (with COMMENT) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 04:08:52 -0000 Ben Campbell has entered the following ballot position for charter-ietf-rum-00-00: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-rum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "While WebRTC could be used to implement a RUM" seems to be the only use of RUM as something one might implement vs a WG. Is that intentional? From nobody Wed Mar 6 18:45:43 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 2DF5A131348; Wed, 6 Mar 2019 18:45:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 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] 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 QPiPAbOwcRys; Wed, 6 Mar 2019 18:45:39 -0800 (PST) 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 B2BED13131F; Wed, 6 Mar 2019 18:45:33 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x272jVwm051246 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 6 Mar 2019 20:45:32 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551926733; bh=AZ6EBq6f6j2w74R1R60VrF0yTWu1QasL0nHvK1ARmRs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=hr/aWcM72cId9ALjzEPuHnefHaNkU8SLHz4B4lKzOXiKnH5kFd0Ijd31HWYKEIYWP JRMSU05pwX3HU2/IIm4SK/mbjIVQ6vGXhzl9EAZpUJUHUfathrKMWvxIN9xl3rFf9l g7SFTeHP8SibYJPhT5kAWCXYPnAoYGN2evqRvikI= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Ben Campbell , The IESG Cc: rum@ietf.org, rum-chairs@ietf.org References: <155175893161.5224.13269249124891149616.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <1f3c301b-dfa5-c31a-f25d-0870be065bfe@nostrum.com> Date: Wed, 6 Mar 2019 20:45:26 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 In-Reply-To: <155175893161.5224.13269249124891149616.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Ben Campbell's Yes on charter-ietf-rum-00-00: (with COMMENT) 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, 07 Mar 2019 02:45:41 -0000 On 3/4/19 10:08 PM, Ben Campbell wrote: > "While WebRTC could be used to implement a RUM" seems to be the only use of RUM > as something one might implement vs a WG. Is that intentional? > On review, this does read somewhat awkwardly. I'll be updating it momentarily to "...to implement a profile to fulfill RUM's requirements..." /a From nobody Thu Mar 7 01:49:47 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F8D131412 for ; Thu, 7 Mar 2019 01:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1551952135; bh=D1nk/yHG57wXLr/xqqHglQodHHopoAOcxB5kMjtsXdg=; h=From:To:Cc:Subject:Date; b=Qiz3c+ROXFUpcE/TPTap4gOwpozYPzsYyImLH2LWMfRWG9bHtxc88QvXfp1yV6vaP r5jTuDafG7Tjv1FhhSfM0pukTq04AN+ngIZUe+MmVSj9aTDUfEuisOTLZZe4jmzbjI zTk3BjagOepX+aasp1/RT7E2jn6KYCBMyqJCSUZc= X-Original-To: rum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Datatracker on behalf of Alissa Cooper To: "The IESG" Cc: rum-chairs@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155192987013.13710.16500637154062382505.idtracker@ietfa.amsl.com> Date: Wed, 06 Mar 2019 19:37:50 -0800 Archived-At: Subject: [Rum] Alissa Cooper's No Objection on charter-ietf-rum-00-01: (with COMMENT) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 09:49:00 -0000 Alissa Cooper has entered the following ballot position for charter-ietf-rum-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-rum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- "The scope of the work includes mechanisms to provision the user’s device with common features such as speed dial lists, provider to contact, videomail service interface point and similar items." It's hard for me to understand the scope of what falls into "other similar items." Could any "common feature" fall in here? Or is there some narrower scope limitation? From nobody Thu Mar 7 06:33:56 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ABA0F12426A; Thu, 7 Mar 2019 06:33:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla via Datatracker To: "The IESG" Cc: rum-chairs@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155196922769.24586.6098996402270809298.idtracker@ietfa.amsl.com> Date: Thu, 07 Mar 2019 06:33:47 -0800 Archived-At: Subject: [Rum] Eric Rescorla's No Objection on charter-ietf-rum-00-01: (with COMMENT) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 14:33:48 -0000 Eric Rescorla has entered the following ballot position for charter-ietf-rum-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-rum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I note that RUM is a term of art on the Apps side of the house in ART ("Real User Monitoring") so you might reconsider the name. From nobody Thu Mar 7 06:42:04 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0948812008F; Thu, 7 Mar 2019 06:41:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind_via_Datatracker?= To: "The IESG" Cc: rum-chairs@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155196971795.24830.18012812011487965984.idtracker@ietfa.amsl.com> Date: Thu, 07 Mar 2019 06:41:57 -0800 Archived-At: Subject: [Rum] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-rum-00-01=3A_=28with_COMMENT=29?= X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 14:41:58 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-rum-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-rum/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I still think that it is too much overhead to from a new wg for just this one doc. However, I understand that there might not be a better option in ART. Maybe it's worth it to consider forming some kind of area group in the future that could handle these kind of proposals. From nobody Thu Mar 7 13:31: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 BD3DD1310F0; Thu, 7 Mar 2019 13:31:20 -0800 (PST) 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 vBiTt9LXA9iU; Thu, 7 Mar 2019 13:31:18 -0800 (PST) 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 8C401130FE5; Thu, 7 Mar 2019 13:31:18 -0800 (PST) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x27LVF0E042655 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 7 Mar 2019 15:31:16 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1551994278; bh=Vgbi3HPws+VviBrWiaT4U19E2gVVipX8XqxAJAq/1Do=; h=To:From:Subject:Date; b=q+CkpXlj+9eB2LbQVoekJsnM2XfY8/d0DtzBLN+w6DPyocBJrm/THzX58m/o3QDcs goxonwPiy+RHist980i2eFn5XXKpZbLIBiJ/Fh7tJEMf+PfQp0OEV421vOZp5ppQuc m3Q4RoyBoNE1OTeb+GArlgXALkuauq1xYR7Vfr4Q= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: The IESG , rum-chairs@ietf.org, rum@ietf.org From: Adam Roach Message-ID: <4ab52b09-20d0-f8e4-cf4f-7c9ccf3f34be@nostrum.com> Date: Thu, 7 Mar 2019 15:31:09 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Rum] Follow-up on RUM charter feedback 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, 07 Mar 2019 21:31:21 -0000 I would respond to the ballot emails directly, but many of these appear to be caught in the tools snafu from earlier. Thanks again to everyone for taking the time to review and comment. Alissa commented: > "The scope of the work includes mechanisms to provision the user’s > device with > common features such as speed dial lists, provider to contact, videomail > service interface point and similar items." > > It's hard for me to understand the scope of what falls into "other > similar items." Could any "common feature" fall in here? Or is there > some narrower scope limitation? Benjamin commented: > "[M]echanisms to provision the user’s device with > common features such as speed dial lists, provider to contact, videomail > service interface point and similar items" are a bit far afield from > our usual ambit of > "bits on the wire", but I do not object to them in this case. Grouping these two comments together: I'm fairly sure what the proponents have in mind here is configuration based on RFC 6080 and/or RFC 6011 mechanisms. I wouldn't be surprised if they end up registering a new Configuration Profile Type in , for example. If either of you think there is a better way to phrase this, please propose text. Benjamin commented: > Do we want to give guidance on what track the document that is the > output of this group > would be published? I think I'm happy with letting the WG decide this based on the contents of the document they produce. The charter already indicates that no new protocol mechanism will be defined. I don't see the value in pre-deciding, e.g., Informational versus BCP. Mirja commented: > I still think that it is too much overhead to from a new wg for just > this one doc. However, I understand that there might not be a better > option in ART. Maybe it's worth it to consider forming some kind of > area group in the future that could handle these kind of proposals. The ART community finds the DISPATCH model useful for providing focus. I'll note that SEC has found this useful enough that it has adopted a similar model in the form of SECDISPATCH. EKR Commented: > I note that RUM is a term of art on the Apps side of the house in ART > ("Real User Monitoring") so you might reconsider the name. While I do find evidence of this usage out in the world at large, I don't see evidence that it collides with use inside the IETF [1]. I plan to keep the name as-is, and will ask the secretariat to send the charter for review momentarily. /a ____ [1] https://www.google.com/search?q=site%3Aietf.org+"real+user+monitoring" From nobody Fri Mar 8 13:16:41 2019 Return-Path: X-Original-To: rum@ietf.org Delivered-To: rum@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BB491224E8; Fri, 8 Mar 2019 13:16:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Cc: rum@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit Message-ID: <155207979953.3197.17666319801069575461.idtracker@ietfa.amsl.com> Date: Fri, 08 Mar 2019 13:16:39 -0800 Archived-At: Subject: [Rum] WG Review: Relay User Machine (rum) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 21:16:39 -0000 A new IETF WG has been proposed in the Applications and Real-Time Area. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-03-18. Relay User Machine (rum) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: Brian Rosen Paul Kyzivat Assigned Area Director: Adam Roach Applications and Real-Time Area Directors: Adam Roach Ben Campbell Alexey Melnikov Mailing list: Address: rum@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/rum Archive: https://mailarchive.ietf.org/arch/browse/rum/ Group page: https://datatracker.ietf.org/group/rum/ Charter: https://datatracker.ietf.org/doc/charter-ietf-rum/ Many current instances of Video Relay Service (VRS), sometimes called Video Interpretation Service, use the Session Initiation Protocol (SIP) and other IETF multimedia protocols. VRS is used by deaf/hard-of-hearing persons and by persons with speech impairments to communicate with hearing persons. The deaf, hard-of-hearing, or speech-impaired person (D-HOH-SI) uses a SIP-based video phone to connect with an interpreter, and the interpreter places a phone call to the hearing person. The hearing person can also reach D-HOH-SI individuals in the same manner as calling any hearing user. The D-HOH-SI person uses sign language and possibly real-time text with the interpreter and the interpreter uses spoken language with the hearing person, providing on-line, real-time, two-way communication. Having a standard interface between the end-user device and the VRS provider allows vendors and open-source developers to build devices that work with multiple service providers; devices can also be retained when changing providers. In this instance, “device” could be a purpose-built videophone or could be downloadable software on a general purpose computing platform or mobile phone. To ensure interoperability of the key features of this service, certain aspects (e.g., codecs, media transport, addressing and SIP features) must be specified as mandatory-to-implement for SIP-based VRS devices. These specified features effectively form a profile for SIP and the media it negotiates. This working group will produce a single document: a profile of SIP and media features for use with video relay services (which includes video, real time text, and audio), and other similar interpretation services that require multimedia. It will reference the IETF’s current thinking on multimedia communication, including references to work beyond SIP (e.g., WebRTC and SLIM). No protocol changes are anticipated by this work. Often, the hearing user is on the PSTN, and RUM will include interoperability specifications for that use, including the use of telephone numbers. RUM will not assume hearing users are on the PSTN. While WebRTC could be used to implement a profile to fulfill RUM's requirements, the group’s work will focus on the device-to-provider interface. The working group will consider ways for WebRTC based services to interwork with a RUM-compliant provider, but is not required to make such interwork possible. RUM devices will be expected to be able to place emergency calls conforming to the current IETF emergency call recommendations. The scope of the work includes mechanisms to provision the user’s device with common features such as speed dial lists, provider to contact, videomail service interface point and similar items. These features allow users to more easily switch providers temporarily (a feature known as “dial around”) or permanently, while retaining their data. Devices used in VRS can be used to place point-to-point calls where both communicating parties use sign language. When used for point-to-point calling where the participants are not served by the same VRS provider, or when one provider provides the originating multimedia transport environment, but another provides the interpreter (“dial-around call”), the call traverses two providers. Both of these uses impose additional requirements on a RUM device and are in scope for this work. Although the interface between providers also requires standardization to enable multi-provider point-to-point and dial-around calls, that interface has already been defined in a SIP Forum document and is thus out of scope for RUM. Milestones: Dec 2019 - Submit a profile of SIP and media features for use with video relay services to the IESG for publication From nobody Sat Mar 23 05:37:11 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 011751200D7 for ; Sat, 23 Mar 2019 05:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y2EDj0KvEqgQ for ; Sat, 23 Mar 2019 05:37:08 -0700 (PDT) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 20D47130EC0 for ; Sat, 23 Mar 2019 05:37:06 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id d201so3907637iof.7 for ; Sat, 23 Mar 2019 05:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=Wd7bxqas3fUmu2/hWLXJRIXTQwuXehm5+0jhj5jLuJc=; b=MOWxnATpDHsMAM2j6AS6i+Nq3tlMah0l8xjh9XfcCG8ALb5UeAhT8bXWSQJfwHkTA3 ecVKYCDoXtULZ9jQ6RHBqE25m91Mw23dGN+kojGlDNWGeCiD7u1SFVqfvPvzHC/TkN0f qKpDTlxCZG62p16UF+HNrhU2aeSPmyBxcj7dJOXMvQcrRxkoMaTml4RIOKYII+VLMMpf VxD2FxdiQuW4uA5z6xIqpWsxRddYtJbm/Z/sYd739JHDV6PlugsA5KmzfjZev8SxIqX8 cg7PDRePTwlu4YrqiWXdLUYPjOAGxmTYc0H7LmZlBjVd4uTgZvkIGQS+PR2rW3HfAX3p nxJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=Wd7bxqas3fUmu2/hWLXJRIXTQwuXehm5+0jhj5jLuJc=; b=Kbc9cv3kN50Vt3dHzwRnf4lwk/O+2i2O2RUxdE14lAQp1fuRDCFPNtoIBR5BX7GzBg /s2Hf1/O23DSsJRe9dDtDudZs04Bsvx2CntqOrKpb4G/iOtfZn5blliQdDt5pX6I3bnV oEehWJrXPHm8RhSeQhoUvK1aPpbE33wYUawDEO6Ta/yqIoft09s+Pbs5y/k8uHmt8Bst f7tevZlpPMomkBd5zX2h+ZkptXEx2b5682+bDiR74XoNChD9R9vRjInG/UWosFh3KpOg E2joo+Isjk/+8aRXr+02iY331W7u1eKLrwkLeNRcPjuGPZp6JeSzK/WeOky4Tw5cJq/6 fNCQ== X-Gm-Message-State: APjAAAXC4vfzuQHERTkNU9XCh5u4O/L1h86WtK445DWNtKf0JtHG6YIO UHrJh0bncTbCOtfqgCjLHPTSm1Qh81M= X-Google-Smtp-Source: APXvYqyYSG29IGPMegk0yvPMvF53cQ9gMHLBO6SG5gl1uNITUGgbCLIpFVYuLEolLIuVzKfGBJ5Q+g== X-Received: by 2002:a5e:9908:: with SMTP id t8mr8878660ioj.205.1553344624999; Sat, 23 Mar 2019 05:37:04 -0700 (PDT) Received: from [10.219.22.235] ([69.54.63.217]) by smtp.gmail.com with ESMTPSA id v19sm4487258iol.27.2019.03.23.05.37.04 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Mar 2019 05:37:04 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <6E53E567-9B79-4CF8-9A4D-9E1397E57316@brianrosen.net> Date: Sat, 23 Mar 2019 08:37:03 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Rum] Meetings at IETF104 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Mar 2019 12:37:10 -0000 We have a slot in DISPATCH agenda on Monday morning. We also have the = Paris meeting room reserved at 10 AM. There is no Meetecho or other = remote service available for the Wednesday meeting, sorry. Brian= From james.hamlin@purple.us Mon Mar 25 06:23:37 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 E2C8E1203E7 for ; Mon, 25 Mar 2019 06:23:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 FEqJOPQVPSc0 for ; Mon, 25 Mar 2019 06:23:36 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.13]) (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 E7D101203F5 for ; Mon, 25 Mar 2019 06:23:35 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx12.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Mon, 25 Mar 2019 13:23:33 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 25 Mar 2019 06:23:18 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::a968:f529:2be7:c099]) by 1-wp-402-exch.purplenetwork.net ([fe80::a968:f529:2be7:c099%27]) with mapi id 15.00.1263.000; Mon, 25 Mar 2019 06:23:18 -0700 From: James Hamlin To: "rum@ietf.org" Thread-Topic: [Rum] Meetings at IETF104 Thread-Index: AQHU4wyLTWP94wHN/kCw/NwPiUBHcg== Date: Mon, 25 Mar 2019 13:23:17 +0000 Message-ID: <1553520197778.78802@purple.us> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_155352019777878802purpleus_" MIME-Version: 1.0 X-BESS-ID: 1553520198-893022-7833-64452-1 X-BESS-VER: 2019.1_20190322.2057 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.211017 [from cloudscan23.us-east-2b.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] Meetings at IETF104 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, 25 Mar 2019 13:28:32 -0000 --_000_155352019777878802purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Brian As this meeting has been announced at very short notice, it has not been po= ssible for VRS relay providers to attend. VRS relay providers have a consid= erable interest in this work, and so remote access would be in the interest= s of inclusive discussion. Would it be possible for remote access to be arranged at this stage? Also, = is there any more agenda information? I see a one hour slot (10-11 CET) des= cribed " Rum organizational, cont from DISPATCH". Best regards James ---- We have a slot in DISPATCH agenda on Monday morning. We also have the Pari= s meeting room reserved at 10 AM. There is no Meetecho or other remote ser= vice available for the Wednesday meeting, sorry. Brian --_000_155352019777878802purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Brian


As this meeting has been announced at very short notice, it has not been= possible for VRS relay providers to attend. VRS relay providers have a con= siderable interest in this work, and so remote access would be in the inter= ests of inclusive discussion.

Would it be possible for remote access to be arranged at this stage? Als= o, is there any more agenda information? I see a one hour slot (10-11 CET) = described "

Rum organizational, cont from DISPATCH".


Best regards


James


----

We have a slot in DISPATCH agenda on=
 Monday morning.  We also have the Paris meeting room reserved at 10 AM.  T=
here is no Meetecho or other remote service available for the Wednesday mee=
ting, sorry.=0A=
=0A=
Brian=0A=


--_000_155352019777878802purpleus_-- From nobody Tue Mar 26 06:00:31 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 DB4DC12031F for ; Tue, 26 Mar 2019 06:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 opjI0fwZT20j for ; Tue, 26 Mar 2019 06:00:24 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 179951202F4 for ; Tue, 26 Mar 2019 06:00:23 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id t124so12766119wma.4 for ; Tue, 26 Mar 2019 06:00:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cyNQUR6Aw9LbPpSOa2s5ZyptVVSDWG8zKPyYsIzgJks=; b=1pP9dj4FfT3MlRMEZ5M8XdAhWtXKu1cZoyjIbYAuhm3n7t+c3EFDsavghXrO5iivgB p4VIjkbsGKOsY8ckT/IiXGjHo3wYFxNyYraBrUjcpUC4tG6ru4DECKP2RFBi66Wdtdt2 ht4JWNh7MDs561OFeSUgJpxi/HMWtxKd+tzU80eOoPv34VMf192Lf1v3S5gWmSI7bn4W 5dDcun4FR7L1PTOTItTl+4cvezL8L1JcC6W+zeyVzFKi5S5j3Yi2fl8e8fawHdldyBgC akQw67X7QsPgQFT6oo4S4JK5+r4DJ+l/VzYY9lgwYsr3WlveBrPLaBbOMWfKQnj0o/cE YrcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=cyNQUR6Aw9LbPpSOa2s5ZyptVVSDWG8zKPyYsIzgJks=; b=CZnUWjTtmzyT4zqZZMRYFNLk+F9Bi7Rri2CW2ehaZc6b63LUhZDgfep7gn7qhtSy7M i+oEtazQvZHiAZJBGa3XlCU/567sxpJIhV6BBaLSzNDgdbm3qT7cpthg2tKrevEG2E3k d9LiSf7gIGyhzIc9gMwR4sZqVFwHAV7MifmBvD3nxDap2OkSe7+xjbAgeUuUad8NE8Av BpBqhsP/2VDyKg3jJWjkAKppzzjgt5SAnyFYnPi1grMmW48xguEfhqrYAhfpyJiAQ97R jqBU5LV1QH6juE5xeCski3Ri7FVOiRt/tMP9cZwHNaBbHCxE3QYvJgZl8Z1iSaIQTx1w sXxg== X-Gm-Message-State: APjAAAVqtevzE7KMOqFFHgXaxO562ntn0kAMQN/daq5+OWGvoUyqZIkE py3bDg8sBEXrAzi9h26l4WwHa4BYhO0= X-Google-Smtp-Source: APXvYqwFP6PXYtensEkJsD4cxWot1ADDic4daALteTQzVnUtQMi01fISNDGJpdOw8vVt8ocTIj594Q== X-Received: by 2002:a05:600c:211a:: with SMTP id u26mr10354443wml.74.1553605221362; Tue, 26 Mar 2019 06:00:21 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:8913:9200:93fb:b045? ([2001:67c:370:128:8913:9200:93fb:b045]) by smtp.gmail.com with ESMTPSA id f1sm15777104wmh.44.2019.03.26.06.00.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 06:00:20 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <2A8A4791-5496-4EE1-A51A-2A9C847CB043@brianrosen.net> Date: Tue, 26 Mar 2019 14:00:19 +0100 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Rum] There will be an audio call-in for the side meeting 10 AM Prague time 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, 26 Mar 2019 13:00:29 -0000 Secretariat will provide a polycom phone for a side meeting. I will = have the number soon. Brian= From nobody Tue Mar 26 09:51:57 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 204481203D6 for ; Tue, 26 Mar 2019 09:51:56 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 WTG0wTlw4VB7 for ; Tue, 26 Mar 2019 09:51:54 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.102]) (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 CCD59120372 for ; Tue, 26 Mar 2019 09:51:53 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx7.us-east-2b.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Tue, 26 Mar 2019 16:51:52 +0000 Received: from 1-WP-402-EXCH.purplenetwork.net (10.0.10.144) by 1-wp-401-exch.purplenetwork.net (10.0.10.143) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 26 Mar 2019 09:51:45 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::a968:f529:2be7:c099]) by 1-wp-402-exch.purplenetwork.net ([fe80::a968:f529:2be7:c099%27]) with mapi id 15.00.1263.000; Tue, 26 Mar 2019 09:51:45 -0700 From: James Hamlin To: "rum@ietf.org" Thread-Topic: [Rum] There will be an audio call-in for the side meeting 10 AM Prague time Thread-Index: AQHU4/QTFvETbL1/wEiE9gTCIQ+/cQ== Date: Tue, 26 Mar 2019 16:51:45 +0000 Message-ID: <1553619104499.97394@purple.us> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.0.10.15] Content-Type: multipart/alternative; boundary="_000_155361910449997394purpleus_" MIME-Version: 1.0 X-BESS-ID: 1553619106-893013-13051-114721-1 X-BESS-VER: 2019.1_20190322.2057 X-BESS-Apparent-Source-IP: 208.17.91.143 X-BESS-Outbound-Spam-Score: 0.00 X-BESS-Outbound-Spam-Report: Code version 3.2, rules version 3.2.2.211046 [from cloudscan36.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 BSF_BESS_OUTBOUND META: BESS Outbound 0.00 HTML_MESSAGE BODY: HTML included in message X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=BSF_BESS_OUTBOUND, HTML_MESSAGE X-BESS-BRTS-Status: 1 Archived-At: Subject: Re: [Rum] There will be an audio call-in for the side meeting 10 AM Prague time 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, 26 Mar 2019 16:51:56 -0000 --_000_155361910449997394purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks James --_000_155361910449997394purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks


James

--_000_155361910449997394purpleus_-- From nobody Wed Mar 27 01:09:18 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 E576C120250 for ; Wed, 27 Mar 2019 01:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 mDJD5DzC049W for ; Wed, 27 Mar 2019 01:09:05 -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 EBA0F12026B for ; Wed, 27 Mar 2019 01:09:04 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id x12so17765473qts.7 for ; Wed, 27 Mar 2019 01:09:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Os/9auWd/EXR9j2psZUWq0UOzMFsqKd21zRFV1q8r2Y=; b=U0RV1dZxtFOO0ImpfVGTpA3olIWTZwIoGjRdG5W7GE77/TyXDXx3ptQ+e2ZnJQKVKN OPdgXt5HNzwo8iYy/ffVqHwKya1L38p5Yo6mYn5axbt0pgR7Ga3t5i3gcOUZPsA+Ho/E KG1VDnmxSM+giiV1w9qi3rvJ4aWKcDUzlp06o+CkvQpzVxNHp1gAzr2UhLRhNEn/Sp2d kq9i4lM/8u/MoXt4QjfcOrcQGMnUbTLKfuipJ4VMUl6ZkYT2o15+ACTfLK4R2K3+96xz OxsY1/HFlQfXDiAC5bqP1SHSLjlWEn/d43j0cOyzNYGZikflO78SLyNdeWufvdLJwAB8 JWng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Os/9auWd/EXR9j2psZUWq0UOzMFsqKd21zRFV1q8r2Y=; b=Osuwf8+0VtnOlAiW60CBV1+HveVoAWGvlmMG7xPoVZqeocvesF5gGUB+/gV+f/qaoZ gSkBx6/Wzu/Xx+OOv9aHPMcImG3liiJ5rieR18ZSuOt6E+BbR2bFb3s4NaGuXi32uUY+ WeNyRv+mA/GG7obzRMmM3NX0/ZrQXbKMkf5WOapT5alpQHqdtCpMJpx9JcXrtOVF5HS4 I8reo7Zt2Z7plbL8PK/wHcw74rJ9zcY+U9wzHmbGrxr3FXpO7Qjjtnznu/vdP53f+/jh U0uA5iYTYeuhiR6u1sm4Cib/DzD1vx5QIzXEn8KZYeAx0ABytb0zkbokaqqUlW6demfB Glww== X-Gm-Message-State: APjAAAU6faAWmfGhKtr3sFCrjta5SPW76tTLUhr1YVIbItj8K1toaBta 2f1AoPErhtthZ86MUwloaOcVlOnyUIQQHdrB+5YoGN3f X-Google-Smtp-Source: APXvYqxMLX2CxJydgVafcwAe8zxvGw2hhGAHw44axwhMgnNx6Bbe6puQhYuaHM9JxU9xb8R6SA8V/Smfce+YsrPUQB0= X-Received: by 2002:ac8:3216:: with SMTP id x22mr344920qta.114.1553674143740; Wed, 27 Mar 2019 01:09:03 -0700 (PDT) MIME-Version: 1.0 From: Brian Rosen Date: Wed, 27 Mar 2019 09:08:52 +0100 Message-ID: To: "rum@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006f415805850ef310" Archived-At: Subject: [Rum] Side Meeting today 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, 27 Mar 2019 08:09:09 -0000 --0000000000006f415805850ef310 Content-Type: text/plain; charset="UTF-8" We will meet in Paris at 10. For those of you remote, we will have at least an audio bridge, number to be announced via this list. There is no rum jabber room yet, but we can use the sipcore (sipcore@jabber.ietf.org) one. Brian --0000000000006f415805850ef310 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
We will meet in Paris at 10. For those of you remote, we = will have at least an audio bridge, number to be announced via this list.= =C2=A0 There is no rum jabber room yet, but we can use the sipcore (sipcore@jabber.ietf.org) one.=C2=A0=

Brian
--0000000000006f415805850ef310-- From nobody Wed Mar 27 01:54:29 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 161E512027D for ; Wed, 27 Mar 2019 01:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.891 X-Spam-Level: X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 jSOK9-6sj3ny for ; Wed, 27 Mar 2019 01:54:25 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 003FE12027B for ; Wed, 27 Mar 2019 01:54:24 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id j9so17493607wrn.6 for ; Wed, 27 Mar 2019 01:54:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=WZrhw+jqnVXDxtVWDNfqVTImk0XwO3bikslLjPLvTdQ=; b=dH7uUVHMkoFlLOOv+K82+p1J+uitC4z2rq2UQDNq2lxmOXG1CoVqjeVWgoI2T/BAvl Cs7N2eS1eoxI4Y+ocEYlTw4mST4+D8yIQPNwa53ZZAZ2jRjJrravCMbvM+W2wLGFewL3 RguBqMHyjq2abqEFlSi4ftwx1vPYeJXsF1ewfjE5U3qzkP+TZOeVgWtNmls/4rKuPnXX e2V3Vw7RqrZn3MCPuDC583tozNXrrvqbG0sWMnlCnwbO8ADc003GF6wQ8qTNFtV8pFU0 yY1JLU0wmcvessAyTQrt5XdItUSpn5/6apKyWdNumW8bBQDw9ttxfCU3sjZI0zEbXNym MQ2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=WZrhw+jqnVXDxtVWDNfqVTImk0XwO3bikslLjPLvTdQ=; b=fhPBQWql515eeiAPzbtlb71zCqENRuizqjGCy3z2ci9UZviytHin/VNDwBoXMi0PGN v7QQCxD6SF4vRLt0QbUp9wb3bFDYjo2/BZ3MQROirlu3TJPIyeRplKSEyk/rvFxEVMX9 oVhBIWqxRPxtD5LtZDGJPpnq4teJyCeWdgl1GYefJgqHZI7fSsin40yIMVPgZglhniBX 9OKcZE4FTlDW5G6ctqdAKHV/ddrTLZiYsh1WHg5lZ4qYikJbrWgR38cBAQ3eH9Z2eEjc 76aptR2BGgCoCflUOb+Mwv05hG/Dr7GfnezA3/II0vWrNW58C5REAmmtf993inEs8Rvd GIcg== X-Gm-Message-State: APjAAAWJX+7SKtxw2v+7ryobP5ILJPWArSMl2UPHani2BHzneUmz0QhK JqjYPWFCQPJjaEmrRS5Is5zxmfLjQ6Q= X-Google-Smtp-Source: APXvYqwBQ8bZ+Kg4vs7h4+9Hkgrmi09LjaI1aIN5rPUuHjSRB8UFXfBwbdN/75LkiJQBbWj8yjFhcQ== X-Received: by 2002:a5d:510b:: with SMTP id s11mr1053229wrt.131.1553676863249; Wed, 27 Mar 2019 01:54:23 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:c85d:3da1:2ad8:90f9? ([2001:67c:370:1998:c85d:3da1:2ad8:90f9]) by smtp.gmail.com with ESMTPSA id b10sm30091535wrt.86.2019.03.27.01.54.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 01:54:22 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Wed, 27 Mar 2019 09:54:19 +0100 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Rum] Bridge number for side 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: Wed, 27 Mar 2019 08:54:27 -0000 224-225-1234. PIN 7093# From nobody Wed Mar 27 01:58:22 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 EFE041204C1 for ; Wed, 27 Mar 2019 01:58:13 -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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 4-m0k3X-6xCV for ; Wed, 27 Mar 2019 01:58:11 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 2BB0D12046F for ; Wed, 27 Mar 2019 01:58:11 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id v14so15808919wmf.2 for ; Wed, 27 Mar 2019 01:58:11 -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:references:to:date; bh=ZcfUnTNZFgNmvTL3vGBXUGY3PKH4LT0qqvnATo+OxhA=; b=FV2nYd+IzpOpoTu2P6iJkOCatCCePjvjdXTCUH+66k+6EuzodR3IBiSjL4k0NCKj9X N0xFOQIQrHOdUfLSm5iFTMO+bot475s+OxG0marxby4GHks2Uh3CmowsiHT+EXI5SvsG Eqyj9Pc3CrnatZOa4UBbUQzlYuJE9tXigBCA9BBlGlExVgGS/CxOZQYlrsorGNAAtf7l gO8vok9zsvFB4ELweBCPOprfXywn+9so8yP3Ql5XgTzctd1MmocgcLo+VXASJR4qBGhz Mz7P5RcfINC7jiHkXIHSlk4omMfeVf7qqygXxzdr6/fortLKLTWkBLZ5gDg9syEg6DkM oShQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:references :to:date; bh=ZcfUnTNZFgNmvTL3vGBXUGY3PKH4LT0qqvnATo+OxhA=; b=N771wLRwjmx00R1XQ4tJB9yi01O72h1+SHcAvu1KLISnze168QdxG4US31BpuvXnhO XzpY6t95/t6Z0mu4mF5sYiXHd11Hy+VuJGY14xdHdgV/qo/+qgb0VH94ygNTt80YkPBi bVxfglTQSsMq5hcq9r41OY44nPwwFlkOxJALfuXAyu96cLa7fh/HZeN8cpWSXabzioOZ FHLDxF27YkSAmIGOw+K8ZnVsXJXcHafrm32eU9r6266QU0vMohbap+2ESUZrnbaPJ/nB 4bfb0IK4px/irf8am8ldMTG/mEMRDsRhc0djm+83Flwd0X6DzE1ebJiK7D7ZObmj2hCK 8oeQ== X-Gm-Message-State: APjAAAUrghXh0kws5dFs+y+tZeuL+PRdO0iaipdqVxtYsYe/2t5UgOWS DCywl9thGwPuZSHsay0NPUnQRNCaPCU= X-Google-Smtp-Source: APXvYqyE/z9lJr69CLBMupaiveDpVB81H4gk4VgLMYB2+qP8gD9lW00UJFmtV7NUh736ZaihCBhnsg== X-Received: by 2002:a1c:6c17:: with SMTP id h23mr11533470wmc.122.1553677089378; Wed, 27 Mar 2019 01:58:09 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:c85d:3da1:2ad8:90f9? ([2001:67c:370:1998:c85d:3da1:2ad8:90f9]) by smtp.gmail.com with ESMTPSA id c8sm18321906wrx.6.2019.03.27.01.58.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 01:58:08 -0700 (PDT) From: Brian Rosen Content-Type: multipart/alternative; boundary="Apple-Mail=_90A14BB0-C64F-498B-BA2C-0A7D669F849D" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <0F7689F7-061E-4F34-88C8-A4B034F49757@brianrosen.net> References: To: rum@ietf.org Date: Wed, 27 Mar 2019 09:58:05 +0100 X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Rum] Fwd: RUM bar bof 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, 27 Mar 2019 08:58:21 -0000 --Apple-Mail=_90A14BB0-C64F-498B-BA2C-0A7D669F849D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Let=E2=80=99s use this bridge instead! > Begin forwarded message: >=20 > From: Eric Burger > Subject: Re: RUM bar bof > Date: March 27, 2019 at 9:49:01 AM GMT+1 > To: Rosen Brian >=20 > Eric Burger is inviting you to a scheduled Zoom meeting. >=20 > Topic: IETF RUM > Time: Mar 27, 2019 10:00 AM Prague Bratislava >=20 > Join Zoom Meeting > https://georgetown.zoom.us/j/7566188401 = >=20 > One tap mobile > +16465588656,,7566188401# US (New York) > +16699006833,,7566188401# US (San Jose) >=20 > Dial by your location > +1 646 558 8656 US (New York) > +1 669 900 6833 US (San Jose) > Meeting ID: 756 618 8401 > Find your local number: https://zoom.us/u/abcgIg0S7f = >=20 > Join by SIP > 7566188401@zoomcrc.com >=20 > Join by H.323 > 162.255.37.11 (US West) > 162.255.36.11 (US East) > 221.122.88.195 (China) > 115.114.131.7 (India) > 213.19.144.110 (EMEA) > 202.177.207.158 (Australia) > 209.9.211.110 (Hong Kong) > 64.211.144.160 (Brazil) > 69.174.57.160 (Canada) > Meeting ID: 756 618 8401 >=20 > Join by Skype for Business > https://georgetown.zoom.us/skype/7566188401 = >=20 >=20 >> On Mar 27, 2019, at 2:57 AM, Brian Rosen > wrote: >>=20 >> It=E2=80=99s a single line with a US number. Got a bridge? >>=20 >> On Wed, Mar 27, 2019 at 7:33 AM Brian Rosen > wrote: >> They are supposed to be getting me a polycom phone. Stay tuned.=20 >>=20 >> On Wed, Mar 27, 2019 at 2:47 AM Eric Burger = > wrote: >> Got video coordinates? If not, I can volunteer a Georgetown Zoom.=20 >>=20 >>=20 >>=20 >> Bless or curse LEMONADE for mobile email. See = https://www.standardstrack.com/ietf/lemonade = --Apple-Mail=_90A14BB0-C64F-498B-BA2C-0A7D669F849D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Let=E2=80=99s use this bridge instead!

Begin = forwarded message:

From: = Eric Burger <eburger@standardstrack.com>
Subject: = Re: RUM bar = bof
Date: = March 27, 2019 at 9:49:01 AM = GMT+1
To: = Rosen Brian <br@brianrosen.net>

Eric = Burger is inviting you to a scheduled Zoom meeting.

Topic: IETF = RUM
Time: Mar 27, 2019 10:00 AM Prague = Bratislava

Join = Zoom Meeting
https://georgetown.zoom.us/j/7566188401

One tap mobile
+16465588656,,7566188401# US (New York)
+16699006833,,7566188401# US (San Jose)

Dial by your = location
        +1 646 558 = 8656 US (New York)
        +1 = 669 900 6833 US (San Jose)
Meeting ID: 756 618 = 8401
Find your local number: https://zoom.us/u/abcgIg0S7f

Join by SIP
7566188401@zoomcrc.com

Join by H.323
162.255.37.11 (US West)
162.255.36.11 = (US East)
221.122.88.195 (China)
115.114.131.7 (India)
213.19.144.110 = (EMEA)
202.177.207.158 (Australia)
209.9.211.110 (Hong Kong)
64.211.144.160 = (Brazil)
69.174.57.160 (Canada)
Meeting ID: 756 618 8401

Join by Skype for Business
https://georgetown.zoom.us/skype/7566188401


On Mar 27, 2019, at 2:57 AM, = Brian Rosen <br@brianrosen.net> wrote:

It=E2=80=99s a single line with a US number. Got = a bridge?

On Wed, Mar = 27, 2019 at 7:33 AM Brian Rosen <br@brianrosen.net> wrote:
They are supposed to be getting me a polycom = phone.  Stay tuned. 

On Wed, Mar 27, 2019 at 2:47 AM Eric Burger <eburger@standardstrack.com> wrote:
Got video coordinates? If not, I can volunteer a Georgetown = Zoom. 



Bless or curse LEMONADE for mobile email. See https://www.standardstrack.com/ietf/lemonade

= --Apple-Mail=_90A14BB0-C64F-498B-BA2C-0A7D669F849D-- From nobody Wed Mar 27 06:49:56 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 4A1201200E0 for ; Wed, 27 Mar 2019 06:49:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 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] 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 fCGtZdocToFk for ; Wed, 27 Mar 2019 06:49:52 -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 4F74B12000F for ; Wed, 27 Mar 2019 06:49:52 -0700 (PDT) Received: from dhcp-99fe.meeting.ietf.org ([IPv6:2001:67c:1232:144:dd9e:62ae:870b:a094]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x2RDnnsU092022 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Wed, 27 Mar 2019 08:49:51 -0500 (CDT) (envelope-from mahoney@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1553694591; bh=TNHT8E4vUxAUB6SJNQykeGTHIHK3pLL26iVE000WZkU=; h=To:From:Subject:Date; b=l+h2P14XflSIXViRCd9lL2ETWQm0mAo2MUlGQL82MWxEYPqibNKuWnn2Ssk0ScimC qwF/eNKv+zByQ/KKMykBojPUYfjmme6Z/eLXbpp1TtQGrvscP6TEjlWcDlqdETAZBT E6Z5t9c5mmNMac1T3WX0uquER6+QbVeJQDncMy2w= X-Authentication-Warning: raven.nostrum.com: Host [IPv6:2001:67c:1232:144:dd9e:62ae:870b:a094] claimed to be dhcp-99fe.meeting.ietf.org To: rum@ietf.org From: "A. Jean Mahoney" Message-ID: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com> Date: Wed, 27 Mar 2019 14:49:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.6.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 today's side 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: Wed, 27 Mar 2019 13:49:55 -0000 Hi all, Below are my summarized notes from today's meeting. Below the summary is more of a blow-by-blow transcript (missing pieces marked with *** or ...). Corrections/additions welcome. Thanks! Jean --------------------------------------------------------------------- RUM side meeting - IETF 104 2019 March 27, 11am - 12 pm, Paris meeting room Chair: Brian Rosen Agenda: Continue discussions started in the earlier DISPATCH session regarding authentication issues. Summary: Charter should be approved shortly after the April 11 telechat. Adam Roach, as AD, said that the working group will need to consider authentication issues, and added the following sentence to the charter: "The working group will consider issues related to authentication of the parties involved in the video relay call." Chris Wendt mentioned STIR and SHAKEN for authentication mechanisms. Adam pointed out that once you have a human in the middle, it is hard to solve authentication issues. Ben Campbell said it could be done, via code words for instance, but the use experience would be awful. Trust relationships could be talked about. Eric Burger said that there were legal, contractual ways to enforce it in the US. Regarding the current draft draft-rosen-rue, it was originally an effort to define the user-to-service interface in the US. It was written for a different audience and was going to be published in the Independent Stream, but the authors were were asked to go through the consensus process. The draft will be offered to the working group, but it's up to the WG to adopt it. The draft's US-specific solution needs to be expanded. If the draft is adopted, Brian will pass the editorship to Henning Schulzrinne since he cannot be both chair and editor. There was a discussion of the solution covered in the draft, and the goal of moving from a proprietary user-to-service interface (UNI interface) to a standards based UNI interface that would allow a user to move to another service provider while keeping their device. The current solution is a conventional video service with SIP REGISTER, and outbound call to outbound proxy. It has the notion of a default provider that the deaf user calls. An assigned interpreter places a call to the other end. The call from hearing person's point of view looks like it's from the deaf user. The deaf person's device can be a smart phone, laptop or desktop. The device can be custom built hardware or it can be an application. The deaf community wants to add realtime text to their devices, and wants to be able to change providers without changing devices. One solution would be for the user to have a WebRTC client and the server does the interwork to the profile. The G.711 audio codec has to be supported. As for authentication, the leg from the interpreter to the called user is out of scope if the other leg is unknown tech. If the other leg has STIR credentials, those can be passed along. Adam recommended removing mention of MD5 from the draft. As for provisioning, it is up to the working group to choose to pursue it. Adam suggested that text be added to the charter to make it less open ended, or RFC6011 and RFC 6080 could be analyzed, and if found insufficient, the WG could recharter. For configuration, Adam suggested the WG keep an eye on the jcard work being proposed. For registration, Chris Wendt point out that mobile apps cannot constantly ping a service, but Brian pointed out that SIP Push was just finalized and could be used. Brian asked if the draft was missing anything. If there is a required minimum frame rate, it would need to be captured in the draft. Adam said that once the WG started importing WebRTC information into the draft, they would find things to add. FEC for instance. Adam said he could be the WG contact for WebRTC information. EOM -------------------------------------------------------------------- RUM side meeting - IETF 104 2019 March 27, 11am - 12 pm, Paris meeting room Chair: Brian Rosen Attendees: Brian Rosen, Chris Wendt, Jean Mahoney, Eric Burger (remote), Andy Hutton, Adam Roach, Alan Ford, Ben Campbell. James Hamlin (remote), Stephen Botzko, John Martin (remote) Brian Brian - Adam, when do you think chartering go through? Adam Roach - I think it will sail through, shortly after next formal telechat (4/11) since it's noncontroversial. Brian - I sent you a note regarding the issue raised during dispatch. Adam - saw that. Brian - I'm looking at doing peer to peer. adam - The working group will need to consider authentication issues. Brian - Do you have something for us, Chris? Chris Wendt - The idea is that you can verify other parties in the call. Adam - Called Party ID. Brian - Since this is explicitly Man-in-the-Middle (MitM), we want to know the ID of the two parties. Adam - Once you have a human in the middle, an air gap, you can't easily solve that. Brian - you have a chance of getting the signaling right, but not the media. Ben Campbell - Do they get the translator or both? Alan - is this considered a multi-party call? Brian - It's two legs with human in between. Ben - There are things you can do - you could exchange code words for instance - but the user experience would be awful. Just say that you don't want to go there. Adam - I wanted to make the charter more open. Permission to look into these things, but not saying that you have to implement anything. Ben - You can just state that the solution is fraught with authentication issues. Eric Burger - we can acknowledge it. The conference case or PBX case would work in North America because you have registered entities that are doing the MitM. There are judicial ways to handle it, make it behave but not in the protocol. Ben - talk about trust relationships. Brian - what Eric says is USA specific. James Hamlin - What's the agenda for this meeting? Brian - We are continuing the dispatch discussion about authentication issues - whether it is possible for the two parties to be able to authenticate one another, when there is an explicit MitM. The IETF is concerned about that. The conclusion is that we'll look at it since no great solutions are coming to us right now. *** - it's been discussed in a lot of forums - shaken, stir. Brian - There are some things that we can use from that work. We'll look at it. We will have a working group week after next. The chairs are me and Paul. This meeting is subject to Note Well. Jean Mahoney is taking notes. Eric - I can record this if you want. Brian - not necessary. John Martin - I've joined. Brian - I don't have specific agenda. There's draft-rosen-rue. We'll offer it to the WG, but it's up to the WG to adopt it. Since I'm the co-chair of the WG, I can't be the editor of the document if it is adopted. Probably Henning Schulzrinne will become editor. Ben - Does Henning have the bandwidth? Brian - Yes, and Paul and I will be helping him. We want to pull other IETF work into this doc by reference - for instance, WebRTC media. Where do people want to go with this meeting? Andy - I'm new to the discussion - How did we get here? Brian - Relay is common across the world, but organized in different ways across the globe - government run, private run. No standards for the device interface. Interfaces are built on existing systems - based on SIP, H323. The user to service part of it is proprietary. There's a desire to have a consistent interface. There's an effort started in US to define the interface. Originally we wanted to publish in the Independent Stream, but we were asked to go through the consensus process. Andy - you have a specific solution in mind? Brian - we have a document that's US-specific, and will be expanded. There's a notion of a default provider, from there you can place a call by telephone number, to an interpreter, who places a call to the other end. The call from hearing person's point of view looks like it's from the deaf user. Hard of hearing user -> interpreter -> receiver Remote caller - ... Brian - It's a very conventional video service. SIP REGISTER, outbound call to outbound proxy. an interpreter is assigned, they call the receiver. Ben - It's a call into a call center. Brian - Yes and calling the deaf user is also a call into the call center. Andy - In the UK, it's not BT or Vodofone providing this. Brian - in the US, there's an underlying service providing services. Eric - There are contracts that put them into legal jurisdiction. John - We are regulated by the FCC in the US. Andy - Any requirements on the deaf user's device - can it be a laptop? Brian -There's a variety devices - smart phones, laptops, desktops. The deaf community has desires on how this works - they want real-time text. Ben - Are they generic clients or purpose built? Brian - Runs the gamut. Custom built devices or apps. Alan - We want to standardize the interface. Brian - yes. There's no standard that lets the user keep their device right now. Ben - they might have custom headers? Brian - some do, some use SIP phones. Chris - In some places we don't use SIP digest, I see lots of provisioning things here. Could this be a modern take on UNI interface? Brian - That's up to the WG. Scope is always your friend. Saying that things are out of scope is your friend. I don't want to make this cover the most generic scope. In dispatch someone asked about using this for French to English translation. Andy - The problem you are trying to solve is that the customer has a very expensive device and can't move it to different providers. Ben - Downloading code to ... is common to WebRTC. Brian - it would be great to build the interface from the WebRTC server. The user has a WebTRC client. The server does the interwork to the profile. chis - ...to UNI too. Adam - you want the RTP stream going direct. Chris - any of the ... Brian - We have to support G.711. Andy - We aren't trying to standardize the user interface? Brian - No. Scope says UNI. others are saying NNI, don't want to get into that. Ben - When we say PSTN, are we saying that it is not our problem? Brian - Correct except for G.711. UNI interface from device to provider. What the provider does on the other side is out of scope. The WebRTC server is creating the UNI interface. Chris - WebRTC doesn't create a ... Adam - go direct, and the WebRTC media stack is the modern way that media should work. Ben - So for the authentication cases - one end is completely out of scope. Brian - In the media. Ben - If the other leg is unknown tech. Brian - We could say that, if the other leg has STIR credentials, we can pass along those credentials, provide a path. adam - It can be SHAKEN compatible. Brian -the charter doesn't restrict to just telephone numbers, but the common case is that both ends have TNs. Alan - it's a 3-person conference, which doesn't map completely, but its like telemedicine. I don't know if that's in scope. Brian - We want to maintain the scope that's in charter, but we also want the most general applicability we can get without going beyond scope. Chris - Relay is about the 2 legs rather than a 3-way conference, it would add tons of requirements if we go toward conference. Eric - We need to finish this. Chris - We could use it for point-to-point video. That wouldn't add scope. *** - Brian - There's the case of a deaf person calling another deaf person. Stephen - Are there two translators? Brian - Try not to do that. There's a check the database for the telephone number to see if they are in the system, if so, they go point to point. Providers have different profiles. you -> your provider -> other provider -> other caller. The other profile is out of scope, scope is UNI. Any other issues or questions? Andy - Is the management part staying in scope? Brian - I would like to keep the provisioning part, but the WG may choose not to. Once we brought this into the consensus process, we lose control of the document. I wouldn't be surprised if it's cut. Chris - It's an industry problem. Adam - To address the charter comments - both Alissa and Benjamin of the IESG asked about provisioning. Can we add something to the charter to make it less open ended? I suspect if the text remains as is, there will be questions from the IESG. Brian - The draft deals with contact issues and who's you provider. Adam - use RFC... for this. Brian - ... give you a piece of JSON, downloaded from provider Adam - Sounds familiar - RFC6011 - there are candidate mechanisms. Brian - no problem. Do a gap analysis and recharter if existing mechanisms are insufficient. Chris - RFC 6080, download JSON Brian - Where do you down load it from? Can add to the charter - We will consider existing mechanisms like 6080. Adam - I don't see the text as problematic. Brian - This draft was done elsewhere, and written for a different audience. It is likely to change. The client has to implement these things, there are fewer requirements on the server. The client has to handle more variations from the providers. Client requires ICE and REFER, but providers don't. Chris - On registration - are mobile apps desired? mobile apps can't constantly ping. Brian - SIP push is there. Chris - If SIP push is available, I'd advocate it. Adam - Mentioning SIP MD5 in the draft is waving a red flag in front of the security guys. We don't want to create new mechanisms for MD5. Ben - Removing MD5 cannot be left out of a bis document. Brian - Section 6.2.2 is US-specific. We can talk about making it work. 6.2.3 is something the providers requested - up to us whether to keep it. Need to figure out how much backward compatibility to maintain, tolerate. Stephen - I see a lot of MAYs. They don't seem necessary. Brian - need to figure out what to do with those. Andy - not going to find something that does both INFO and SRTCP Adam - if you want to use JSON, you may want to keep an eye on the jcard work being proposed. Harmonizing with WebRTC, which uses FEC. Brian - is there something missing? Adam - once you start importing from WebRTC, you'll find things to add. Stephen - the provider would have a minimum bandwidth they would want in order to do sign language translation. Brian - they probably do have that. Stephen Botzko - would need know that those guys will participate. Brian - The providers have some secret sauce. If you have a certain amount of bandwidth, frame rates change,... *** - any modern codec would work here. Brian - it will be a negotiation. *** - if there's a desire for a minimum frame rate. Brian - if there is, should be in here. Adam - look at WebRTC for parameters to consider. Brian - who should I ask for WebRTC insight? Adam - I'm probably the contact. I've updated the charter and want to run by the group - "The working group will consider issues related to authentication of the parties involved in the video relay call." Brian - sounds good. EOM From nobody Wed Mar 27 08:04: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 2675F1202D6 for ; Wed, 27 Mar 2019 08:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.69 X-Spam-Level: X-Spam-Status: No, score=-1.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 mQ6huLofaRIG for ; Wed, 27 Mar 2019 08:04:43 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 EC37B1202DB for ; Wed, 27 Mar 2019 08:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=To:Date:Message-Id:Subject:Mime-Version: Content-Type:From:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=IJA0cyLI754Y7iJrEaSRfSdpoome4r4T5DCwekSpoE0=; b=g1d8ZJaZlH6wsn+M6dUCaLKrjW M2gc4yMwJf2gPZ93EHrbo9MLKfohpWhQDuuELtEYRpp3coW4fBWukQ0C4UucNKffI3x/STykMqwOM M7ZCZua9PQtFqxSqiEFw61IIQPuQPp3U85ebDw/uP817XzqJOm6kHjdeWyUZ1dQ2gK58=; Received: from [174.204.14.136] (port=2527 helo=[192.168.43.104]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h9A6U-0000wP-GJ for rum@ietf.org; Wed, 27 Mar 2019 08:04:42 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_541E1035-47F5-4B7A-8DAC-023EB0FD94B9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: Date: Wed, 27 Mar 2019 11:04:32 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Rum] How to do the impossible: MITMs that aren't but are 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, 27 Mar 2019 15:04:44 -0000 --Apple-Mail=_541E1035-47F5-4B7A-8DAC-023EB0FD94B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 In DISPATCH it was pointed out that RUM is a man-in-the-middle (MITM) = attack. We pointed out that it is a MITM that users expect. The good news is we have existing use cases that look a lot like the RUM = scenario: a PBX re-originating a call and a multimedia conference = bridge. However, neither of those scenarios have end-to-end, = cryptographic integrity of the identity of the end parties to each = other. I would offer that we have non-protocol solutions to this problem that = could be enabled through the protocol. How about this as an outline: o Note the originating party can pass an opaque token to the = Interpreter to pass to the called party (e.g., a STIR token) o Note the Interpreter can pass that token to the called party (noting = that STIR tokens are somewhat cut-and-paste attack resistant) o Note that in many jurisdictions, communications regulators have = authority over Interpreters to ensure they act responsibly o Note that in many jurisdictions, communications regulators impose = mechanisms that apply cryptographic tools so that a called party knows = the Interpreter is really a =E2=80=98legal=E2=80=99 (in the legal sense) = Interpreter (e.g., SHAKEN) Would that work? Otherwise, I think we are trying to solve an unsolvable = problem: specifically a MITM that knows when to set the Evil Bit. --Apple-Mail=_541E1035-47F5-4B7A-8DAC-023EB0FD94B9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlybkQAACgkQDDCGh758 rslvdw//Vc1fCBXjGENH3XYsndDFrCC96bHn/uWJtYN6BPUyvTRBkelFU+DZAXP1 6RAEkU4T43iCnuWi2VZoZ+Kmv+IuAaZo74zqZLAgw4HF07ZCkjeylKuRA4rLZnYu Chn6eW98Aihn9D1MVDMFAAfJWm3pVU5bwpECGMg7FV3esocyGobWn6Tb88WhIPLt CPq7gjNAV9cvQXLINxiKgELvWoBgjpwh23HxIk1HHJHp6+euEAFWzbLv/EkulESb D2SnIOEcFnGMYE2h2fjeJYoC3cbAc9NbWyDLL2G9Yh95MrvwKr6ka87VvwoW+oUz 75cSWzFM0aLZG1UQ1E+lFHz5ZwZWGTrbM0wTduncQnoGnvmkUABplMj0sC17WUYP A4gkJQOO9OrWkHyNtX5fN4+phXOb5IOQlVfuRvV2l9wheFRMvzSiP6tUhEj2pczo 9juA1KqMx8S//rDKKZTJPmiZVqY87Kz/JKFB7a802hWZ+8sVuInP4331xI1JL4eV Y351UyH61pjvclLA1nxG5HdWtAH097P3zY6K0w5uQI4sV+TZmBomvEZuROo2SJmO Nr4X0lY266J+ltLg3mNwbAH/IpJh5TiN5hGGQf/q80OKdlWTv6l9KSIgxFPwf18S zQ7O/qM7cJqkyd/iGwbOuwEJWZqTSy0lQFKKK7wBG+u1VdLkkvU= =INP3 -----END PGP SIGNATURE----- --Apple-Mail=_541E1035-47F5-4B7A-8DAC-023EB0FD94B9-- From nobody Wed Mar 27 08:21:10 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 C5FF41202EC for ; Wed, 27 Mar 2019 08:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.689 X-Spam-Level: X-Spam-Status: No, score=-1.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=standardstrack.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 G87KE8n10SZA for ; Wed, 27 Mar 2019 08:21:07 -0700 (PDT) Received: from biz221.inmotionhosting.com (biz221.inmotionhosting.com [198.46.93.79]) (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 DC7CC120073 for ; Wed, 27 Mar 2019 08:21:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=standardstrack.com; s=default; h=Message-Id:In-Reply-To:To:References:Date: Subject:Mime-Version:Content-Type:From:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=NbNESIehpJI24ovm5D7V73I6glmUttLvW9QopiRM/J0=; b=b0U+RjF0Y6aZkvyhNzDdbP9Pd HDvnxxszSnmSFzXt+r0uJPam3xkVn8Qk4GLsNOIhsW0BoAXTHI21txNvHqc5n1SRFxeeI+fBHieLG DUtDUbQ0aBUTGFv1EJWXEBTzeJB32LpywF3lAY1YgJgibLlb7XIEXdrEV+JNbO4F5BUCU=; Received: from [174.204.14.136] (port=2509 helo=[192.168.43.104]) by biz221.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from ) id 1h9AMM-000GZS-7Y for rum@ietf.org; Wed, 27 Mar 2019 08:21:06 -0700 From: Eric Burger Content-Type: multipart/signed; boundary="Apple-Mail=_6F195680-3332-48D4-9238-936C1DA7DB1E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Wed, 27 Mar 2019 11:20:56 -0400 References: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com> To: rum@ietf.org In-Reply-To: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com> Message-Id: <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com> X-Mailer: Apple Mail (2.3445.104.8) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz221.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Get-Message-Sender-Via: biz221.inmotionhosting.com: authenticated_id: eburger+standardstrack.com/only user confirmed/virtual account not confirmed X-Authenticated-Sender: biz221.inmotionhosting.com: eburger@standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: [Rum] Minimum Technical Features in RUM? 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, 27 Mar 2019 15:21:09 -0000 --Apple-Mail=_6F195680-3332-48D4-9238-936C1DA7DB1E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is there a compelling reason to go here? > On Mar 27, 2019, at 9:49 AM, A. Jean Mahoney = wrote: >=20 > Brian asked if the draft was missing anything. If there is a required = minimum frame rate, it would need to be captured in the draft. Adam said = that once the WG started importing WebRTC information into the draft, = they would find things to add. FEC for instance. Adam said he could be = the WG contact for WebRTC information. I agree: it would be nice to say, =E2=80=9CThe device MUST be usable.=E2=80= =9D However, doesn=E2=80=99t the definition of usable change over time? = Looking at my real-time messaging work in the late 1990=E2=80=99s, we = might have said something like, =E2=80=9CYou MUST have an ultra = high-speed, 384kb/s connection.=E2=80=9D Wouldn=E2=80=99t that look = quaint today. In other words, talking about FEC, minimum frame rates, minimum display = sizes, etc. is IMHO is way out of scope. If someone chose to build a = device that was unusable, that is not our problem. They would find = adoption to be about 0%. Conversely, if someone is seriously building a = device that meets RUM, they would presumably check to see what would be = viable in the (then current) market. --Apple-Mail=_6F195680-3332-48D4-9238-936C1DA7DB1E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIzBAEBCAAdFiEEfEc/N7T7IfiAuDEHDDCGh758rskFAlyblNgACgkQDDCGh758 rsm4WA/+No67f78PH8sM4HJVPnr34G80ukolGSYQ4cIU8epquEaOsHTlZzL7eK4T ptfFuU61C0ytor3lx4CoOYU8fS0o9XrY7EfRjIyQIPzOIbYX3aApqeNRHlA4a/dD PN3UMcxNw1UuKRmyGNpls3MDDH8uTckdqyYl+Sk3m0GH20wSDDp4rol1+SU+mkI/ PUTCalrLdVjkkT66ewoXcmBZIf8hZaHq8iKrOPALhScU3gvTbyqx4UU+4Dm0QFQU BsFq8YleqWi2BFyErmRjLUQDZyLDu4DdcWMoH6Ku+ARABG+Dsu2EFpt/SL0YeMxx PIfDQqGItkbcP9NFM/wCya7IpdktV4GgVx6iTOjcBBm7w08/FBz45Eg3zdG7QIf8 Z91OzfWHCrkxuorK7QQHyjuEeCOOEIXq3IEhiNalADHvKzwSFm1T5hFWm4z7vFgZ J+bD3Am9ad01I/y5Uz+PVNNVkadm56OiN2a7bwemGAv4dCp4Nc3Z4gufamb7um/n s0cO/Tp+al+x5jlQYkUrEAfJJoPySGTcjM8eNSTPu7chehCk8ut599C7VJlitmxs jLzViTdnCLgMwCGWuof0cGkVFETDKIUPo2ubrQvP9PiPTy2Cs+Q/JyI+ZIXk2zoO 6Eq8/p+RHSpAk0RkR9hILQOx1HX5NEPbRq7TAaNztcCb0rnT9U8= =dtxr -----END PGP SIGNATURE----- --Apple-Mail=_6F195680-3332-48D4-9238-936C1DA7DB1E-- From nobody Wed Mar 27 08:30:24 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 E3A631202DB for ; Wed, 27 Mar 2019 08:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=chriswendt-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 Xrd_gpMHJWJx for ; Wed, 27 Mar 2019 08:30:21 -0700 (PDT) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 412E4120073 for ; Wed, 27 Mar 2019 08:30:21 -0700 (PDT) Received: by mail-qt1-x82f.google.com with SMTP id v20so19262361qtv.12 for ; Wed, 27 Mar 2019 08:30:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chriswendt-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q4QRkwNu2uCG7mn0BrtDOlIRc3dzr8pNTM0X8dc9Tcc=; b=lTdeo7wuebX8/amiyjJXRkfbKP/rvAgtxf7p46hUZH2cAChGF3tBclhAhUICe2lPko gBVtW9v8/iTDBcw6jzF5oAx/cClPi6o8FlTJ7TFH3dq+qEjjmfa2wnefybrpZw5noJK/ 5JZKHZHz1YebL/EKCpeTng2O6EPC9xdho26QorXgfyoK//ffPeBgEp/gwc/bDMvbFfNp Xh3N49CipQTqIH1NkbZnQnc9vWFqTjryEOIHPgUO40CPdY9ecKPLn26FHPsuapZ12alr Ns31+MFe+64zRLgBYjZvX3iGUXxSnbL4G759STUS76iYK2v39U0NHK2ILOTka5eOc3Nr I8SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Q4QRkwNu2uCG7mn0BrtDOlIRc3dzr8pNTM0X8dc9Tcc=; b=ewPdDe1mDJWxZlUTWCCB7XQUbhJH/c9BO5WqIhnRQPg3zul26OE7sxx4M7Fb/z9w11 SDzKHvNuJThbLmUSIyzz6Pv9oe4gaqqzI424ki+DJm8faUxlsgz9ncCUhrIkmzBXh2gS FDEDBHuTgMGfD1Wp5/3XmNdE/NEmaf2lqZAYjH9h6JaKPgi+6oBd1kozvOwJL3TFp0fF iGG82gr4JCA5vNYAJ/cgLo+v8tOnqoYKinWByLyORB+iZWu8c4KFt1EQ+bamr8Ub5U69 qV66N4t4D7uHLLUxDShZEXTjLEhKWIxkuRk8kti4ZlTgtvVBN6cd6GGtOCf5ahZrbkg0 H6lg== X-Gm-Message-State: APjAAAXD6S1CPugfiFrosYdgeYm3nbwG1hCz98Zd/qfO5dB/1COVS3T3 kEpooiwcMVc8qiNg4p8Vrzg2CXAZA9g= X-Google-Smtp-Source: APXvYqwRhxp1ieYNa44jyytR44bWylasWTSWz4Uyw45yKG12JRGw090TwJDA+3aEUHnM+e+tz/i/vw== X-Received: by 2002:a0c:9236:: with SMTP id a51mr32149719qva.217.1553700620370; Wed, 27 Mar 2019 08:30:20 -0700 (PDT) Received: from [10.26.44.23] ([64.237.40.140]) by smtp.gmail.com with ESMTPSA id c207sm9418926qkg.14.2019.03.27.08.30.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Mar 2019 08:30:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Chris Wendt In-Reply-To: <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com> Date: Wed, 27 Mar 2019 16:30:17 +0100 Cc: rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <421FADC7-8C6A-436E-A792-1D5676A689E7@chriswendt.net> References: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com> <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com> To: Eric Burger X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Rum] Minimum Technical Features in RUM? 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, 27 Mar 2019 15:30:23 -0000 I think we can hopefully point to the webrtc video specs which I believe = at least define minimums in terms of MTI codecs, resolutions, etc. = Maybe they will be updated over time, but we are getting to the point = that having beyond a 4k video stream for your video call may produce = diminishing returns. Some would argue 1080p/30 or 60 is already at that = point. So while, you never say never, i believe it=E2=80=99s pretty = safe to say for the kind of video we are addressing in RUM, there is = soon going to be some pretty comfortable stability for a while. I = don=E2=80=99t think that=E2=80=99s a controversial statement but maybe = could be proven wrong :) > On Mar 27, 2019, at 4:20 PM, Eric Burger = wrote: >=20 > Is there a compelling reason to go here? >=20 >> On Mar 27, 2019, at 9:49 AM, A. Jean Mahoney = wrote: >>=20 >> Brian asked if the draft was missing anything. If there is a required = minimum frame rate, it would need to be captured in the draft. Adam said = that once the WG started importing WebRTC information into the draft, = they would find things to add. FEC for instance. Adam said he could be = the WG contact for WebRTC information. >=20 > I agree: it would be nice to say, =E2=80=9CThe device MUST be = usable.=E2=80=9D However, doesn=E2=80=99t the definition of usable = change over time? Looking at my real-time messaging work in the late = 1990=E2=80=99s, we might have said something like, =E2=80=9CYou MUST = have an ultra high-speed, 384kb/s connection.=E2=80=9D Wouldn=E2=80=99t = that look quaint today. >=20 > In other words, talking about FEC, minimum frame rates, minimum = display sizes, etc. is IMHO is way out of scope. If someone chose to = build a device that was unusable, that is not our problem. They would = find adoption to be about 0%. Conversely, if someone is seriously = building a device that meets RUM, they would presumably check to see = what would be viable in the (then current) market. > --=20 > Rum mailing list > Rum@ietf.org > https://www.ietf.org/mailman/listinfo/rum From nobody Wed Mar 27 08:51:56 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 63D2A12027E for ; Wed, 27 Mar 2019 08:51:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOp2E--9_nkK for ; Wed, 27 Mar 2019 08:51:52 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (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 A4AE41202CC for ; Wed, 27 Mar 2019 08:51:52 -0700 (PDT) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x2RFmUUM000957; Wed, 27 Mar 2019 11:51:51 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by mx0a-00191d01.pphosted.com with ESMTP id 2rgbay9pcp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Mar 2019 11:51:51 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x2RFpmKF007954; Wed, 27 Mar 2019 11:51:50 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x2RFphtq007688; Wed, 27 Mar 2019 11:51:44 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id DF5124030707; Wed, 27 Mar 2019 15:51:43 +0000 (GMT) Received: from MISOUT7MSGHUBAA.ITServices.sbc.com (unknown [130.9.129.145]) by zlp27126.vci.att.com (Service) with ESMTPS id CA55B403070B; Wed, 27 Mar 2019 15:51:43 +0000 (GMT) Received: from MISOUT7MSGUSRDB.ITServices.sbc.com ([169.254.2.222]) by MISOUT7MSGHUBAA.ITServices.sbc.com ([130.9.129.145]) with mapi id 14.03.0439.000; Wed, 27 Mar 2019 11:51:42 -0400 From: "DOLLY, MARTIN C" To: Chris Wendt CC: Eric Burger , "rum@ietf.org" Thread-Topic: [Rum] Minimum Technical Features in RUM? Thread-Index: AQHU5LC6WCVHY4/xBEud8nd0enOB+qYf3aKA///C718= Date: Wed, 27 Mar 2019 15:51:42 +0000 Message-ID: <933CB03A-1818-4C45-85D8-54F0C440481E@att.com> References: <2a40ff1d-45d0-bc2c-eeee-5a28b5bcd3fd@nostrum.com> <21080EDE-D5F5-48EF-9CFA-C26B992E65BA@standardstrack.com>, <421FADC7-8C6A-436E-A792-1D5676A689E7@chriswendt.net> In-Reply-To: <421FADC7-8C6A-436E-A792-1D5676A689E7@chriswendt.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-27_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=675 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903270110 Archived-At: Subject: Re: [Rum] Minimum Technical Features in RUM? 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, 27 Mar 2019 15:51:55 -0000 I agree with Chris Or=20 We could the debate the codec for a few years Martin C Dolly AT&T Lead Member of Technical Staff Government & Services Standards +1 609 903 3360 > On Mar 27, 2019, at 11:30 AM, Chris Wendt wro= te: >=20 > I think we can hopefully point to the webrtc video specs which I believe = at least define minimums in terms of MTI codecs, resolutions, etc. Maybe t= hey will be updated over time, but we are getting to the point that having = beyond a 4k video stream for your video call may produce diminishing return= s. Some would argue 1080p/30 or 60 is already at that point. So while, yo= u never say never, i believe it=92s pretty safe to say for the kind of vide= o we are addressing in RUM, there is soon going to be some pretty comfortab= le stability for a while. I don=92t think that=92s a controversial stateme= nt but maybe could be proven wrong :) >=20 >> On Mar 27, 2019, at 4:20 PM, Eric Burger wr= ote: >>=20 >> Is there a compelling reason to go here? >>=20 >>> On Mar 27, 2019, at 9:49 AM, A. Jean Mahoney wrot= e: >>>=20 >>> Brian asked if the draft was missing anything. If there is a required m= inimum frame rate, it would need to be captured in the draft. Adam said tha= t once the WG started importing WebRTC information into the draft, they wou= ld find things to add. FEC for instance. Adam said he could be the WG conta= ct for WebRTC information. >>=20 >> I agree: it would be nice to say, =93The device MUST be usable.=94 Howev= er, doesn=92t the definition of usable change over time? Looking at my real= -time messaging work in the late 1990=92s, we might have said something lik= e, =93You MUST have an ultra high-speed, 384kb/s connection.=94 Wouldn=92t = that look quaint today. >>=20 >> In other words, talking about FEC, minimum frame rates, minimum display = sizes, etc. is IMHO is way out of scope. If someone chose to build a device= that was unusable, that is not our problem. They would find adoption to be= about 0%. Conversely, if someone is seriously building a device that meets= RUM, they would presumably check to see what would be viable in the (then = current) market. >> --=20 >> Rum mailing list >> Rum@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mail= man_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7I= tG0r2g&m=3DS90utjdt6fldt2pc4TJiVpuj-Hjl-_fSznBcu_OsSaw&s=3Dhnoq2Q6LRiypWSPz= TGe5CLJWdlM_T-rZL3DtGbZdjv4&e=3D >=20 > --=20 > Rum mailing list > Rum@ietf.org > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailm= an_listinfo_rum&d=3DDwIGaQ&c=3DLFYZ-o9_HUMeMTSQicvjIg&r=3DG9v8uCSSQhCmpw7It= G0r2g&m=3DS90utjdt6fldt2pc4TJiVpuj-Hjl-_fSznBcu_OsSaw&s=3Dhnoq2Q6LRiypWSPzT= Ge5CLJWdlM_T-rZL3DtGbZdjv4&e=3D