From nobody Wed Apr 10 06:40:01 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 446D51203B8; Wed, 10 Apr 2019 06:39:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Magnus Westerlund via Datatracker To: "The IESG" Cc: rum-chairs@ietf.org, rum@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Magnus Westerlund Message-ID: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 06:39:56 -0700 Archived-At: Subject: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) 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: Wed, 10 Apr 2019 13:40:00 -0000 Magnus Westerlund has entered the following ballot position for charter-ietf-rum-00-02: Block 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/ ---------------------------------------------------------------------- BLOCK: ---------------------------------------------------------------------- Why are the no discussion of security mechanism being part of the profile? Considering that the profile includes the media plane, I assume at least mandatory to implement media protection security mechansism and what ciphers should be defined. Then is the of the key-management and its tie into the establishment signalling. I understand that one want to establisha a border for what is in scope and out of scope. But as I read the charter now it is completely missing. All that I find are this part: The working group will consider issues related to authentication of the parties involved in the video relay call. No protocol changes are anticipated by this work. This sounds like actually discusssing the security model. It is possible to be more explicit of how one handle the fact that one have three parties, where only one part talks to both. From nobody Wed Apr 10 07:31:09 2019 Return-Path: X-Original-To: rum@ietfa.amsl.com Delivered-To: rum@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9317B1202E7 for ; Wed, 10 Apr 2019 07:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 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, 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 BPrKEmOGPZKz for ; Wed, 10 Apr 2019 07:31:06 -0700 (PDT) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (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 776B0120021 for ; Wed, 10 Apr 2019 07:31:06 -0700 (PDT) Received: by mail-qk1-x729.google.com with SMTP id n68so1348529qka.1 for ; Wed, 10 Apr 2019 07:31:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T7wEdfyZgkz+RAvRPgY50g2joWMkImoBlha7p3lSDDM=; b=GaYs9P8l6mbO8pAZSZKPRn6vB/v6Ktx5Fj4xQs5i9YN153cHAY3hh8cPhrAmPwuaXc JCbkiJWIBCxNocRoCr3feMBZME/mVYlX9VEmdd5+RtE3+VYSUOUmy6+M73CPbwq6/h/z Ky3qDFd267fg+32qX4NvOJG+Wk5UigrNKUjKks1dexKkl3bAlR9M5nnX8lPCmhxDl0vu iHDapLLSWNXacHFO7E8O1sFkw38mxMJ41Sgzp1jLYH8SYt0roR3631Rw8WistgH2CANd ntVKUm2qEa4mSVB+EJ8PFS4hlmR48vlvF4SJdNwBrQtNFQRg2Csz2K1RziyCZqPwcQbU 9H+g== 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=T7wEdfyZgkz+RAvRPgY50g2joWMkImoBlha7p3lSDDM=; b=HtBz1IKJ8cUquDn9DIn/ybfjB+co80H7FRMcJm0jMC3A+u0lH1DXCHPb3Il2Orw4vg ofw/Abt/zDqfKHo498KYrh9KdEzC/ql5KeqW1ezFHiWgGq/KR+chuEwMZccIaMNTMB7O ogP47J2oNsDZN2KXl6i2aptpjY3eBab7YfBAIMxNgq8oJ6qw1vDzKDhUdPIu7HQO5Vrx O/YpQKJfZyl9+ElEg0KXtOeYXWDmwReTia6dUg34tpNFSu8qOcIQcsP5V4FcuxJwJopQ AVIfIg4MCRVekVCHZ00SNp7J6XOPYagK4aM0nyXhGO30pcoFAhyFo2q5VfKFF2lBknfZ h5NA== X-Gm-Message-State: APjAAAWnnU6tWpRSQ0iAfp85TpXbFhWh9uvle9Qfask4OvUBuNApcJZK 2CU3KJQFXO/DVlmVWO+YF1lxrd3gkjo= X-Google-Smtp-Source: APXvYqzIpUVPEHNzwtdkx8499ggtd7+uB/g3ZMUnY+LP34aEmUG6gshOvWj3aEJAuN9JTBY/vmkJ4A== X-Received: by 2002:a37:9d06:: with SMTP id g6mr33980701qke.25.1554906665354; Wed, 10 Apr 2019 07:31:05 -0700 (PDT) Received: from brians-mbp-4.lan ([24.129.255.66]) by smtp.gmail.com with ESMTPSA id m18sm22183384qki.64.2019.04.10.07.31.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 10 Apr 2019 07:31:04 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Brian Rosen In-Reply-To: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 10:31:02 -0400 Cc: The IESG , rum-chairs@ietf.org, rum@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> To: Magnus Westerlund X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 14:31:08 -0000 The profile will most certainly include all the best practice security = mechanisms for SIP. The charter discusses using the most up to date = media plane recommendations, which are the WebRTC recommendations, = including DTLS-SRTP, and we will require TLS in the signaling plane. = As these are UAs, and not proxy servers, the usual security mechanisms = for registration will be required. We certainly don=E2=80=99t plan to = innovate other than exploring the issues raised of explicit = man-in-the-middle, but we will require all implementations to maintain = current best practice on security mechanisms. We=E2=80=99ll craft some = language to include in the charter. =20 Maybe: The profile will specify current best practice security = mechanisms for SIP based end devices as mandatory to implement > On Apr 10, 2019, at 9:39 AM, Magnus Westerlund via Datatracker = wrote: >=20 > Magnus Westerlund has entered the following ballot position for > charter-ietf-rum-00-02: Block >=20 > 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.) >=20 >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/charter-ietf-rum/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > BLOCK: > ---------------------------------------------------------------------- >=20 > Why are the no discussion of security mechanism being part of the = profile? > Considering that the profile includes the media plane, I assume at = least > mandatory to implement media protection security mechansism and what = ciphers > should be defined. Then is the of the key-management and its tie into = the > establishment signalling. I understand that one want to establisha a = border > for what is in scope and out of scope. But as I read the charter now = it is > completely missing. >=20 > All that I find are this part: > The working group will consider issues related to authentication of = the > parties involved in the video relay call. No protocol changes are = anticipated > by this work. >=20 > This sounds like actually discusssing the security model. It is = possible to be > more explicit of how one handle the fact that one have three parties, = where > only one part talks to both. >=20 >=20 >=20 >=20 From nobody Wed Apr 10 08:15: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 D8ECB1205D3; Wed, 10 Apr 2019 08:15:01 -0700 (PDT) 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.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?Mirja_K=C3=BChlewind?= Message-ID: <155490930181.9012.10425075507990091132.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2019 08:15:01 -0700 Archived-At: Subject: [Rum] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-rum-00-02=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: Wed, 10 Apr 2019 15:15:02 -0000 Mirja Kühlewind has entered the following ballot position for charter-ietf-rum-00-02: 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 find it a bit excessive to create a 8-month working group for one document, but sure... From nobody Wed Apr 10 08:30:39 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 69486120611; Wed, 10 Apr 2019 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-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 Ey3RULrG3BIN; Wed, 10 Apr 2019 08:30:24 -0700 (PDT) Received: from mail-it1-f177.google.com (mail-it1-f177.google.com [209.85.166.177]) (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 19EDE12060F; Wed, 10 Apr 2019 08:30:21 -0700 (PDT) Received: by mail-it1-f177.google.com with SMTP id w15so4095780itc.0; Wed, 10 Apr 2019 08:30:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XfqHGTkKJ5gBKW7Tv56wVq8DsDdN90cK1iK14LgJORo=; b=MHlxEeW3P5Gv6JbJCklr4fTg/qsg6gt9RlDUdTpfuIQUp6KrjZ08rk4a/aM2fupfdp sNUX/dB4GStno8BQheI3Dx3PqtjqELvgQjU+IaptxMnLTcF0wLVZxOsO+0/SoWYWe0NC kBEymssFJTz06TJ0PIfMgg3LA1s1CPvgMhyLYHMVqT1hkfO4Heh1fUtp5suss7C9KogK QyQhnNlFcAvn50IqiSW1raPCxKPg4xQ6X1iej6RfZMClavrB1vXyE4nE6ijH597OHebT aH5vIy5kAHoVfKZ/NwANYTSoRuJOXSnG6lIdffHJjHU9dWTRlonCS6D/vAPY84aobDBf /TUg== X-Gm-Message-State: APjAAAXBKFalAkiADho06aF+HuNBNOyVUD32iAHEXuQN3Gr+8VfDGWnf lzY36Grj6thsTu+uz8J5ib8GRNw16cvgh5hMscSyew== X-Google-Smtp-Source: APXvYqwrPqB5iNV0kboN7rCCTMXg13vubkv5NB7qQzlPLkFIRi3mBnOXNuT73F9n84nbUOCUZwlLX6LaFZS+3z72Xe0= X-Received: by 2002:a24:3d94:: with SMTP id n142mr3527096itn.147.1554910220054; Wed, 10 Apr 2019 08:30:20 -0700 (PDT) MIME-Version: 1.0 References: <155490930181.9012.10425075507990091132.idtracker@ietfa.amsl.com> In-Reply-To: <155490930181.9012.10425075507990091132.idtracker@ietfa.amsl.com> From: Barry Leiba Date: Wed, 10 Apr 2019 11:30:08 -0400 Message-ID: To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: The IESG , rum@ietf.org, rum-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Rum] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-rum-00-02=3A_=28with_COMMENT=29?= X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 15:30:32 -0000 > I still find it a bit excessive to create a 8-month working group for one document Really? Why? I think it's a perfect way to handle things, creating a short-lived, tightly focused working group for this sort of thing. It's far better than AD-sponsoring a document, which almost always gets inadequate community review. We've used such working groups very effectively in the ART area (and its predecessors). Barry From nobody Wed Apr 10 09:09:32 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 137551203C1; Wed, 10 Apr 2019 09:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpyQB_6ZpFVs; Wed, 10 Apr 2019 09:09:22 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 00EB51203B7; Wed, 10 Apr 2019 09:09:21 -0700 (PDT) Received: from ewa_guest_internet_sthlm_nat2.ericsson.net ([192.176.1.97] helo=[10.148.125.253]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1hEFmn-00014x-2a; Wed, 10 Apr 2019 18:09:17 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Mirja Kuehlewind In-Reply-To: Date: Wed, 10 Apr 2019 18:09:16 +0200 Cc: rum@ietf.org, The IESG , rum-chairs@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <606CEF44-EBBC-4E00-9A66-58A812BF2774@kuehlewind.net> References: <155490930181.9012.10425075507990091132.idtracker@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3445.104.8) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1554912562;88853e65; X-HE-SMSGID: 1hEFmn-00014x-2a Archived-At: Subject: Re: [Rum] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_charter?= =?utf-8?q?-ietf-rum-00-02=3A_=28with_COMMENT=29?= X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 16:09:24 -0000 In transport we have the tsvwg which is chartered to catch up this kind = of working and provide a place for the community to meetings and = discuss. I guess at this point it doesn=E2=80=99t matter anymore but it = saves you the overhead of working on a charter and run it though the = IETF and IESG process. > On 10. Apr 2019, at 17:30, Barry Leiba = wrote: >=20 >> I still find it a bit excessive to create a 8-month working group for = one document >=20 > Really? Why? >=20 > I think it's a perfect way to handle things, creating a short-lived, > tightly focused working group for this sort of thing. It's far better > than AD-sponsoring a document, which almost always gets inadequate > community review. We've used such working groups very effectively in > the ART area (and its predecessors). >=20 > Barry >=20 >=20 From nobody Wed Apr 10 10:27: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 3798A120650; Wed, 10 Apr 2019 10:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 aKxu9b9CtB4b; Wed, 10 Apr 2019 10:27:12 -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 6D45312060E; Wed, 10 Apr 2019 10:27:12 -0700 (PDT) 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 x3AHR4VK026894 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 10 Apr 2019 12:27:05 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554917227; bh=dAbz9OzEHQo3Z+WhvN5P/XjpMmptqDWIuDonEZhfnTo=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=i0FWvQygW8TiCmoNN+0DkWWzVDWU9z/M98aMhIIT257TxhN5AfXBbDjfj7izwNHgE 9/LrDx9ws9Sl+8sp55lD915snMMzvqdd5DAGRV28QQpKf3/JxYo+GS3nboxrgau+e9 so6xQ1DxCU0out4mro6Sw2LK4Csax0QVkhd/dgps= 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: Brian Rosen , Magnus Westerlund Cc: rum@ietf.org, The IESG , rum-chairs@ietf.org References: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <5cbae522-4692-d293-e6f8-a69698269f4a@nostrum.com> Date: Wed, 10 Apr 2019 12:26:59 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 17:27:20 -0000 I've added: "The profile will require best-practice security mechanisms for SIP-based end devices." /a On 4/10/19 9:31 AM, Brian Rosen wrote: > The profile will most certainly include all the best practice security mechanisms for SIP. The charter discusses using the most up to date media plane recommendations, which are the WebRTC recommendations, including DTLS-SRTP, and we will require TLS in the signaling plane. As these are UAs, and not proxy servers, the usual security mechanisms for registration will be required. We certainly don’t plan to innovate other than exploring the issues raised of explicit man-in-the-middle, but we will require all implementations to maintain current best practice on security mechanisms. We’ll craft some language to include in the charter. > > Maybe: The profile will specify current best practice security mechanisms for SIP based end devices as mandatory to implement > > > >> On Apr 10, 2019, at 9:39 AM, Magnus Westerlund via Datatracker wrote: >> >> Magnus Westerlund has entered the following ballot position for >> charter-ietf-rum-00-02: Block >> >> 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/ >> >> >> >> ---------------------------------------------------------------------- >> BLOCK: >> ---------------------------------------------------------------------- >> >> Why are the no discussion of security mechanism being part of the profile? >> Considering that the profile includes the media plane, I assume at least >> mandatory to implement media protection security mechansism and what ciphers >> should be defined. Then is the of the key-management and its tie into the >> establishment signalling. I understand that one want to establisha a border >> for what is in scope and out of scope. But as I read the charter now it is >> completely missing. >> >> All that I find are this part: >> The working group will consider issues related to authentication of the >> parties involved in the video relay call. No protocol changes are anticipated >> by this work. >> >> This sounds like actually discusssing the security model. It is possible to be >> more explicit of how one handle the fact that one have three parties, where >> only one part talks to both. >> >> >> >> From nobody Thu Apr 11 00:50:47 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 9CA0C120289; Thu, 11 Apr 2019 00:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 uY65xzYS3Mhu; Thu, 11 Apr 2019 00:50:36 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60081.outbound.protection.outlook.com [40.107.6.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25C9712017D; Thu, 11 Apr 2019 00:50:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8sQiYMTzgrf6fcNG+wtC6toDJQVjw77XAYeURpAiua4=; b=eODJYAZoIUSbzQC7S7iZDKN1jXYfgL3KKTlcSNPaWd1MBZAyGmpjdsX12x6tFH0mmT141brfNrpVDHiOd5bXrKZ+PJSGa1rfB1nuOQVOq0ZAIsidmAJPKSNo7f6IZ09NjWrKsMh6kXOeJhmdSAwp3wBN3JRJXsv4YSEs3P5hJgU= Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com (10.168.128.149) by HE1PR0701MB2649.eurprd07.prod.outlook.com (10.168.186.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.3; Thu, 11 Apr 2019 07:50:33 +0000 Received: from HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505]) by HE1PR0701MB2522.eurprd07.prod.outlook.com ([fe80::107c:5f27:2ef:8505%5]) with mapi id 15.20.1792.009; Thu, 11 Apr 2019 07:50:33 +0000 From: Magnus Westerlund To: Adam Roach , Brian Rosen CC: "rum@ietf.org" , The IESG , "rum-chairs@ietf.org" Thread-Topic: Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) Thread-Index: AQHU76L/FbYWsJjh80C5nutsW/HBXQ== Date: Thu, 11 Apr 2019 07:50:33 +0000 Message-ID: References: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> <5cbae522-4692-d293-e6f8-a69698269f4a@nostrum.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=magnus.westerlund@ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c97ef27-35a1-4271-79dc-08d6be526065 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2649; x-ms-traffictypediagnostic: HE1PR0701MB2649: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(346002)(376002)(39860400002)(136003)(189003)(199004)(53936002)(33656002)(97736004)(8936002)(6246003)(105586002)(6116002)(3846002)(68736007)(316002)(44832011)(478600001)(6306002)(5660300002)(52536014)(14454004)(66066001)(55016002)(106356001)(2906002)(486006)(9686003)(966005)(81166006)(446003)(71200400001)(305945005)(476003)(256004)(71190400001)(7736002)(74316002)(7696005)(86362001)(81156014)(54906003)(110136005)(8676002)(6506007)(14444005)(4326008)(26005)(25786009)(99286004)(53546011)(186003)(102836004)(76176011)(229853002)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2649; H:HE1PR0701MB2522.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: A/Cio0t7WsRGrN5MGEBrPXtz3PEhGZfJ7r4tEwC/jHjrDDfzG3w5Nzveo++xYYy1aSaCwUNfVB+zqEfsqBoU7kSAI+CxJ39jyvZejAqQK4ujBxOWvacSo83SVEwNm6V/JqWjFjn6ow6KlRD3XU+WF2nX/WGtsLvP1mt7EVP64xUfIHTjmq0mpk9BxnTzpFo7OIe+90AO1pXnTIExrAWHSVJNj7mMtUCdQQe+/hfyLBrpQo4+pezCECPjQW7qXUe4PUZ2JSkT1tiw0g9YsFI0itzsZG4RzSWNJvYHdFVGyrdC2B6BHUe+NHTV92LRTEJoL0uiSrzusWttdwrkw8dxV+rwEkaQHb7Z4bMMfr0W3OVgrV6TQq91/+0VyGImEWenuo4xdZBt3jcJ5vD8fnTg2KYiCAFs/AgH7zTO5WDldi0= Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c97ef27-35a1-4271-79dc-08d6be526065 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 07:50:33.2301 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2649 Archived-At: Subject: Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) 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, 11 Apr 2019 07:50:39 -0000 Thanks,=0A= =0A= Have cleared.=0A= =0A= Cheers=0A= =0A= Magnus=0A= =0A= On 2019-04-10 19:27, Adam Roach wrote:=0A= > I've added: "The profile will require best-practice security mechanisms = =0A= > for SIP-based end devices."=0A= >=0A= > /a=0A= >=0A= > On 4/10/19 9:31 AM, Brian Rosen wrote:=0A= >> The profile will most certainly include all the best practice security m= echanisms for SIP. The charter discusses using the most up to date media p= lane recommendations, which are the WebRTC recommendations, including DTLS-= SRTP, and we will require TLS in the signaling plane. As these are UAs, a= nd not proxy servers, the usual security mechanisms for registration will b= e required. We certainly don=92t plan to innovate other than exploring the= issues raised of explicit man-in-the-middle, but we will require all imple= mentations to maintain current best practice on security mechanisms. We=92= ll craft some language to include in the charter.=0A= >>=0A= >> Maybe: The profile will specify current best practice security mechanism= s for SIP based end devices as mandatory to implement=0A= >>=0A= >>=0A= >>=0A= >>> On Apr 10, 2019, at 9:39 AM, Magnus Westerlund via Datatracker wrote:=0A= >>>=0A= >>> Magnus Westerlund has entered the following ballot position for=0A= >>> charter-ietf-rum-00-02: Block=0A= >>>=0A= >>> When responding, please keep the subject line intact and reply to all= =0A= >>> email addresses included in the To and CC lines. (Feel free to cut this= =0A= >>> introductory paragraph, however.)=0A= >>>=0A= >>>=0A= >>>=0A= >>> The document, along with other ballot positions, can be found here:=0A= >>> https://datatracker.ietf.org/doc/charter-ietf-rum/=0A= >>>=0A= >>>=0A= >>>=0A= >>> ----------------------------------------------------------------------= =0A= >>> BLOCK:=0A= >>> ----------------------------------------------------------------------= =0A= >>>=0A= >>> Why are the no discussion of security mechanism being part of the profi= le?=0A= >>> Considering that the profile includes the media plane, I assume at leas= t=0A= >>> mandatory to implement media protection security mechansism and what ci= phers=0A= >>> should be defined. Then is the of the key-management and its tie into t= he=0A= >>> establishment signalling. I understand that one want to establisha a b= order=0A= >>> for what is in scope and out of scope. But as I read the charter now it= is=0A= >>> completely missing.=0A= >>>=0A= >>> All that I find are this part:=0A= >>> The working group will consider issues related to authentication of the= =0A= >>> parties involved in the video relay call. No protocol changes are antic= ipated=0A= >>> by this work.=0A= >>>=0A= >>> This sounds like actually discusssing the security model. It is possibl= e to be=0A= >>> more explicit of how one handle the fact that one have three parties, w= here=0A= >>> only one part talks to both.=0A= >>>=0A= >>>=0A= >>>=0A= >>>=0A= >=0A= =0A= -- =0A= =0A= Magnus Westerlund =0A= =0A= ----------------------------------------------------------------------=0A= Network Architecture & Protocols, Ericsson Research=0A= ----------------------------------------------------------------------=0A= Ericsson AB | Phone +46 10 7148287=0A= Torshamnsgatan 23 | Mobile +46 73 0949079=0A= SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com=0A= ----------------------------------------------------------------------=0A= =0A= From nobody Thu Apr 11 01:21:38 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 4AFBD12017D; Thu, 11 Apr 2019 01:21:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoF0QRmlG7uG; Thu, 11 Apr 2019 01:21:28 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [212.3.14.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 196FD12011D; Thu, 11 Apr 2019 01:21:27 -0700 (PDT) Received: from [192.168.1.78] (static-212-247-19-62.cust.tele2.se [212.247.19.62]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp7.webway.se (Postfix) with ESMTPSA id 1917729BE; Thu, 11 Apr 2019 10:21:24 +0200 (CEST) From: "Olle E. Johansson" Message-Id: <3DB5825E-3F5C-4BF3-9225-F85B8655EC3F@edvina.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_DE182D67-5FD8-41CF-AF8D-98229EBB4C8E" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Thu, 11 Apr 2019 10:21:21 +0200 In-Reply-To: <5cbae522-4692-d293-e6f8-a69698269f4a@nostrum.com> Cc: Olle E Johansson , Brian Rosen , Magnus Westerlund , rum@ietf.org, The IESG , rum-chairs@ietf.org To: Adam Roach References: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> <5cbae522-4692-d293-e6f8-a69698269f4a@nostrum.com> X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) 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, 11 Apr 2019 08:21:30 -0000 --Apple-Mail=_DE182D67-5FD8-41CF-AF8D-98229EBB4C8E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10 Apr 2019, at 19:26, Adam Roach wrote: >=20 > I've added: "The profile will require best-practice security = mechanisms for SIP-based end devices.=E2=80=9D And where do we have a definition of =E2=80=9Cbest-practice security = mechanisms for SIP=E2=80=9D ? There=E2=80=99s a lot of issues to take care of before we can practice = security in SIP=E2=80=A6=20 /O= --Apple-Mail=_DE182D67-5FD8-41CF-AF8D-98229EBB4C8E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10 Apr 2019, at 19:26, Adam Roach <adam@nostrum.com> = wrote:

I've added: "The profile will = require best-practice security mechanisms for SIP-based end = devices.=E2=80=9D
And where do we have a = definition of =E2=80=9Cbest-practice security mechanisms for SIP=E2=80=9D = ?

There=E2=80=99s a = lot of issues to take care of before we can practice security in = SIP=E2=80=A6 

/O
= --Apple-Mail=_DE182D67-5FD8-41CF-AF8D-98229EBB4C8E-- From nobody Thu Apr 11 08:56:44 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 C975A1202F1; Thu, 11 Apr 2019 08:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" 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 VGbhBD0hw8BL; Thu, 11 Apr 2019 08:56:41 -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 EFED91203E6; Thu, 11 Apr 2019 08:56:40 -0700 (PDT) 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 x3BFuNOD046791 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 11 Apr 2019 10:56:24 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1554998186; bh=wsnocGLOsooKbemX/2j0aeQwGCdIdoHjNhMFQcK/iSk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=rJPhUtmWx5+lDu6sPLPrpbw2x2Q/zR/5XsOWpBmkeYtq1/wNoqpNKCWSF7VG+rVRx iocu1kW0X7Ru3lBY+Bkq9wLRaqI82RpVFifsX+crNQ4UsIp0ZcUdKiVhM/44Bev4/P ZNixLCFFSxDR0jtqPBjAsPyMQJ6kMuXrnbpdqDfk= 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: "Olle E. Johansson" Cc: Magnus Westerlund , rum@ietf.org, The IESG , Brian Rosen , rum-chairs@ietf.org References: <155490359622.22876.4380616673767598799.idtracker@ietfa.amsl.com> <5cbae522-4692-d293-e6f8-a69698269f4a@nostrum.com> <3DB5825E-3F5C-4BF3-9225-F85B8655EC3F@edvina.net> From: Adam Roach Message-ID: <2f1eac96-ff5f-e7f2-50a3-7c636c48f046@nostrum.com> Date: Thu, 11 Apr 2019 10:56:18 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <3DB5825E-3F5C-4BF3-9225-F85B8655EC3F@edvina.net> Content-Type: multipart/alternative; boundary="------------0F4A4067284A3E630BE5453C" Content-Language: en-US Archived-At: Subject: Re: [Rum] Magnus Westerlund's Block on charter-ietf-rum-00-02: (with BLOCK) 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, 11 Apr 2019 15:56:42 -0000 This is a multi-part message in MIME format. --------------0F4A4067284A3E630BE5453C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 4/11/19 3:21 AM, Olle E. Johansson wrote: > > >> On 10 Apr 2019, at 19:26, Adam Roach > > wrote: >> >> I've added: "The profile will require best-practice security >> mechanisms for SIP-based end devices.” > And where do we have a definition of “best-practice security > mechanisms for SIP” ? This is certainly a topic I would expect the working group to spend considerable time discussing. The goal of a charter is to steer and constrain work, not to actually perform the work; and to answer your question in the charter would require us to do the work of the working group before chartering the working group. /a --------------0F4A4067284A3E630BE5453C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 4/11/19 3:21 AM, Olle E. Johansson wrote:


On 10 Apr 2019, at 19:26, Adam Roach <adam@nostrum.com> wrote:

I've added: "The profile will require best-practice security mechanisms for SIP-based end devices.”
And where do we have a definition of “best-practice security mechanisms for SIP” ?


This is certainly a topic I would expect the working group to spend considerable time discussing. The goal of a charter is to steer and constrain work, not to actually perform the work; and to answer your question in the charter would require us to do the work of the working group before chartering the working group.

/a

--------------0F4A4067284A3E630BE5453C-- From nobody Fri Apr 12 10:05: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 240931203D0; Fri, 12 Apr 2019 10:05:37 -0700 (PDT) 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.95.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , rum@ietf.org, rum-chairs@ietf.org Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Message-ID: <155508873709.16847.13123331095108578014.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2019 10:05:37 -0700 Archived-At: Subject: [Rum] WG Action: Formed 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, 12 Apr 2019 17:05:38 -0000 A new IETF WG has been formed in the Applications and Real-Time Area. For additional information, please contact the Area Directors or the WG Chairs. 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 Alexey Melnikov Barry Leiba 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). The profile will require best-practice security mechanisms for SIP-based end devices. The working group will consider issues related to authentication of the parties involved in the video relay call. 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 Fri Apr 26 07:59:17 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 347D212049E for ; Fri, 26 Apr 2019 07:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl-hOt0n_L4T for ; Fri, 26 Apr 2019 07:59:04 -0700 (PDT) Received: from 1pmail.ess.barracuda.com (1pmail.ess.barracuda.com [209.222.82.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1DC12051B for ; Fri, 26 Apr 2019 07:58:45 -0700 (PDT) Received: from smtp.purple.us (unknown [208.17.91.143]) by mx11.us-east-2a.ess.aws.cudaops.com (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NO); Fri, 26 Apr 2019 14:58:07 +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; Fri, 26 Apr 2019 07:56:55 -0700 Received: from 1-WP-402-EXCH.purplenetwork.net ([fe80::b41b:40df:b152:6817]) by 1-wp-402-exch.purplenetwork.net ([fe80::b41b:40df:b152:6817%27]) with mapi id 15.00.1263.000; Fri, 26 Apr 2019 07:56:55 -0700 From: James Hamlin To: "rum@ietf.org" Thread-Topic: RUM reference in DA-19-271A1 Thread-Index: AQHU/DbVfTONjwjpYUKApZnrQNRy5g== Date: Fri, 26 Apr 2019 14:56:55 +0000 Message-ID: <1556290615470.19147@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_155629061547019147purpleus_" MIME-Version: 1.0 X-BESS-ID: 1556290664-893020-32270-39-4 X-BESS-VER: 2019.1_20190425.1806 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.212451 [from cloudscan28.us-east-2a.ess.aws.cudaops.com] Rule breakdown below pts rule name description ---- ---------------------- -------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_BESS_OUTBOUND META: BESS Outbound X-BESS-Outbound-Spam-Status: SCORE=0.00 using global scores of KILL_LEVEL=7.0 tests=HTML_MESSAGE, BSF_BESS_OUTBOUND X-BESS-BRTS-Status: 1 Archived-At: Subject: [Rum] RUM reference in DA-19-271A1 X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 14:59:16 -0000 --_000_155629061547019147purpleus_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It may be of interest to the RUM group, that its work is referred to in US = regulation. In an order DA-19-271A1 (April 9, 2019):- The RUE Profile has been substantially revised over the last year, and the = revised version has been submitted for review under the auspices of the Int= ernet Engineering Task Force (IETF). ... By extending the compliance date to April 29, 2020, we allow additional tim= e for IETF review, And:- As a further step in the Commission's evaluation process, the revised versi= on of the standard has been submitted for review by the Internet Engineerin= g Task Force (IETF). 32 ... 32 See Internet Engineering Task Force(IETF), Datatracker, Interoperability= Profile for Relay User Equipment, https://datatracker.ietf.org/doc/draft-r= osen-rue/ (last visited Mar. 29, 2019). The order doesn't refer to the RUM group directly but I assume it is the gr= oup's work that is being referred to. The order is publicly available ( https://docs.fcc.gov/public/attachments/DA-19-271A1.pdf ) and many on the g= roup will already be aware, but it seems sensible to mention on the mail li= st . James ________________________________ Purple Communications, Inc. www.purple.us Download P3 today at: http://www.purple.us/p3 --_000_155629061547019147purpleus_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


It may be of interest to the RUM group, that its work is referred to in = US regulation. In an order DA-19-271A1 (April 9, 2019):-


The RUE Profile has been substantially revised over the= last year, and the revised version has been submitted for review under the auspices of the Internet En= gineering Task Force (IETF).

...

By extending the compliance date to April 29, 2020, we allow add= itional time for IETF review,

And:-

As a further step in the Commission’s evaluation process, the revi= sed version of the standard has been submitted for review by the Internet Engineering Task Force (IETF). 32

...

32 See Internet Engineering Task Force(IETF), Datatracker, Interoperabil= ity Profile for Relay User Equipment, https= ://datatracker.ietf.org/doc/draft-rosen-rue/ (last visite= d Mar. 29, 2019).

The order doesn't refer to the RUM group directly but I assume it is the= group's work that is being referred to. The order is publicly available (<= /p>

http= s://docs.fcc.gov/public/attachments/DA-19-271A1.pdf ) and many on = the group will already be aware, but it seems sensible to mention on the ma= il list .


James



Purple Communications, Inc.
www.purple.us

Download P3 today at:
http://www.purple.us/p3
 --_000_155629061547019147purpleus_-- From nobody Fri Apr 26 10:28:32 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 E392E120316 for ; Fri, 26 Apr 2019 10:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 MkSuAE3whvg3 for ; Fri, 26 Apr 2019 10:28:28 -0700 (PDT) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AA391201A4 for ; Fri, 26 Apr 2019 10:28:28 -0700 (PDT) Received: by mail-qt1-x82c.google.com with SMTP id s10so4929929qtc.11 for ; Fri, 26 Apr 2019 10:28:28 -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=nMB4tn4ucML70Fu6RVQvEAkfMYXlL3R2Gh7ogarXyDo=; b=TINPNZlvICOt2tmr/OXHYSOIqGTpuO1p9MApWy4FUSyqeJRI9xM6KfosmgRfZ93Ipk Ea7qvEeMwoRz2pQSF678HufK8DYtqwLD80xjoEJXBSgFxqRVpY5IFXuswZ1WfzE2qfzw mw6jWtvHBOCkh1beZkbLZYakPZ0gX6IIt2A2TCkmks+CxvseZtP9ROMKFqVxXrGdlVLo udITidGs+AdSHo5utWqncvL3b/MZ5k2EsC4qsymfc/X+JOI5gMUfNLpkDYF+I7YN5wZw +pyLFmOa8t+g6ddNHmN1ZYSOI/azRsMu1qnfaNoro0W2tmqBtdw5EFEX5gYFIJHoO1LN TDmg== 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=nMB4tn4ucML70Fu6RVQvEAkfMYXlL3R2Gh7ogarXyDo=; b=ejQCElxIwz0abiVm/mnIK7iuzv9S/eaY1RcR8+oENjPKM2QRp4NrABQxrr9bpwV71i uH/CGUxWJqsEUzu9eKtluBOUVaxSpBsdiG82tOjbe753Y+Qq78Yk8QQeulBIGiXUSjW9 M5OYBOHoWc62mUsCQG5xvEYr9B2fwlMZhBQHHqdL3ls/AQJv1nqiSA3Do4x9sskY1/UR 1Cz1kSmtZZu0cNtpIyINLRBLjtfQrlLlPfMWuZMei1qGVRrKkFg/1v9WlxnZULf+FAVH oLA1qGuQrV0YQngHOU8PKl0Bkx9E4j+KLEW7EEUk82pLsaanKK+Q6p4SZ/IpQMQaywY7 XpmA== X-Gm-Message-State: APjAAAVfNiJcPwSGmty2bUZFWA2RfmyPOUl4zABog1aVnLwXc9htWFi8 jqy8XEd4E0UqYeyI+zc2rwa75P+oAfXgGg== X-Google-Smtp-Source: APXvYqwy20SreJdELlrYhPyAKSa4H7BQbM5WwyLkD3blVRSsENdwzEGvzAmLU+MHVsSHLg2Hmo9v+g== X-Received: by 2002:ac8:66c2:: with SMTP id m2mr8819773qtp.189.1556299706897; Fri, 26 Apr 2019 10:28:26 -0700 (PDT) Received: from brians-mbp-6.lan ([24.129.255.66]) by smtp.gmail.com with ESMTPSA id e22sm625063qtq.40.2019.04.26.10.28.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Apr 2019 10:28:26 -0700 (PDT) From: Brian Rosen Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <2CAA20A5-B10C-4D1F-9625-4A7FCF4B1022@brianrosen.net> Date: Fri, 26 Apr 2019 13:28:25 -0400 To: rum@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Rum] IETF 105 Montreal meeting slot X-BeenThere: rum@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Relay User Machine List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Apr 2019 17:28:30 -0000 Hello Rummers! We=E2=80=99re going to request a slot at IETF105. The question is how = long? I=E2=80=99m thinking 1.5 hours. I don=E2=80=99t think we need = 2.5, and I think 1 hour is too short. I do plan to resubmit draft-rosen-rue as draft-rosen-rum-rue shortly. I = will then request we consider adopting it as a work group item. Brian=