From nobody Sun Aug 3 18:29:13 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C311B27EF for ; Sun, 3 Aug 2014 18:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham 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 B1tL8z8KB8hk for ; Sun, 3 Aug 2014 18:29:10 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A67B1B27E8 for ; Sun, 3 Aug 2014 18:29:10 -0700 (PDT) Received: from ppp118-209-253-106.lns20.mel6.internode.on.net ([118.209.253.106]:55523 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XE749-000114-F8 for clue@ietf.org; Mon, 04 Aug 2014 11:27:57 +1000 Message-ID: <53DEE1E2.7080208@nteczone.com> Date: Mon, 04 Aug 2014 11:29:06 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53D05C32.8080500@nteczone.com> In-Reply-To: <53D05C32.8080500@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GL2gA9mW4hXZsET7gllmT6nAnEo Subject: Re: [clue] READV X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 01:29:12 -0000 Any reasoning? I can't see the reason why READV-ACK must contain an CLUEinfo structure. Christian On 24/07/2014 11:06 AM, Christian Groves wrote: > Hello > > I heard that there were some discussions at the meeting regarding the > READV and in particular questions: > 1. Do we need a separate READV response message to carry the CLUE data? > 2. Couldn't the READV simply trigger the MP to send an ADV? > > It seems that the answer at the meeting to 1 was "Yes" and the answer > to 2 was "No". Can anyone give some background / reasons for those > answers? Is there some fundamental issue with using the READV as a > trigger rather having to send CLUE Advertisement data in the READV > response? The state machines in the protocol draft appear to use ADV > in response to a READV. > > > Regards, Christian > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Aug 4 10:19:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2825A1A0026 for ; Mon, 4 Aug 2014 10:19:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 tETsLmqrR4ko for ; Mon, 4 Aug 2014 10:19:16 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD5F1A0054 for ; Mon, 4 Aug 2014 10:19:15 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so8052009wes.18 for ; Mon, 04 Aug 2014 10:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=VVczA3A2rxeEGPdKTwbN/QP0tAWPYRorrb8m3GgJ+NQ=; b=y1LsItgf2+leYzRDtGLXKUgcqRWTgvmum7kpzsQfyXXWhJ8eEH3amHFZRvDgz0AF4R X/nSCNFOsdqnldXs0bPxnQXnwauDzcYt7DZPDaAvPNOrZqIxRG4At4Rft/Q5/SA6MIxk M8yinfQlVQcVKNmPcG6YNhPNIrLIY8g67mdh/wwtlrTN/LcvF5Vtom3DunYxW/Xz38tU f4OsL+FydsnAG89xjVwf2c5Jl8NjWbCIPfPsM5ad0lotXyLuzKiPTFt5/VVabuiPiV3h GM2EoutOoz9ec8hzyxg2AO/ejZSX6p/cBIvZWwH20UqIYfBuiJYnpQJiyORuG8tmB+Q6 2Kaw== MIME-Version: 1.0 X-Received: by 10.194.175.41 with SMTP id bx9mr6532217wjc.123.1407172751683; Mon, 04 Aug 2014 10:19:11 -0700 (PDT) Received: by 10.216.222.10 with HTTP; Mon, 4 Aug 2014 10:19:11 -0700 (PDT) Date: Mon, 4 Aug 2014 12:19:11 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e014937d20075f204ffd0f03e Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HUbw6CBPTDhoPGsOpwHi1HXTLoE Subject: [clue] No design team call tomorrow - August 4th, 2014 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Aug 2014 17:19:18 -0000 --089e014937d20075f204ffd0f03e Content-Type: text/plain; charset=UTF-8 Since there's only been 3 emails on the list since IETF-90, there does not seem to be a need for a call tomorrow. If you think otherwise, let us know ASAP. We will try to get a list of targeted topics on the wiki within a couple days. Mary. --089e014937d20075f204ffd0f03e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Since there's only been 3 emails on the list since IET= F-90, there does not seem to be a need for a call tomorrow. If you think ot= herwise, let us know ASAP. =C2=A0We will try to get a list of targeted topi= cs on the wiki within a couple days.

Mary.
--089e014937d20075f204ffd0f03e-- From nobody Thu Aug 7 14:08:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4361A01F3 for ; Thu, 7 Aug 2014 14:08:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 ojjDfhKX0SYH for ; Thu, 7 Aug 2014 14:08:42 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 754731A0140 for ; Thu, 7 Aug 2014 14:08:42 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id boHM1o0050Fqzac59x8ijm; Thu, 07 Aug 2014 21:08:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id bx8h1o00X3ZTu2S3Ux8hXw; Thu, 07 Aug 2014 21:08:41 +0000 Message-ID: <53E3EAD9.7020600@alum.mit.edu> Date: Thu, 07 Aug 2014 17:08:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407445722; bh=cMYaX14zWPj+ibLRdVJEOFcgCZL3/JSUKE/g5FC1tuw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wgU+JCx6xDmf8eHr9yWn3L1qfChXkwiLtI/2RIglBzul58KsPZASA6N/0HHyl7YHq HseBBde9fmxo5YYhbPaSH98U4YpaLunmL2w3Z50G+u6mWJ9i01XDFSbtl9CDFwnKGM FS9F148gx6Rzr0O3o2p4Ihz77NpjTGO+MbJuUpKA21GPOgAUIGu4YFVOscKYiogKSQ Ee79pagCXFbCRKgLXS0T0ygk5bYDc6rwZzU/ITy5SWog92LUI2rbzr6IjIvZSadP5/ MjXY3HVeco6VMrAZQ6Mis89+th8taKvOAeyoQh48/07eJYD+J+WgNCKnTj9kgrj70q DEQxqRRrjKfzA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/8DaAHWjasB6WUC1UyajKucicPyQ Subject: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Aug 2014 21:08:45 -0000 CLUE people should review draft-ietf-rtcweb-alpn-00. It has some implications for us. It defines some two specific ALPN protocol names for use with webrtc. These are used during DTLS initialization, and identify the application layer protocol running on top of DTLS. If we are to be interoperable with webrtc, then it seems clue implementations will be required to follow this draft. The two ALPN names defined are: - webrtc - c-webrtc The value "c-webrtc" is used when "confidential" media streams are being conveyed. IIUC this is mostly a browser issue. The draft says: Private communications in WebRTC depend on separating control (i.e., signaling) capabilities and access to media [I-D.ietf-rtcweb-security-arch]. In this way, an application can establish a session that is end-to-end confidential, where the ends in question are user agents (or browsers) and not the signaling application. A browser is required to enforce this control using isolation controls similar to those used in cross-origin protections. These protections ensure that media is protected from applications. Applications are not able to read or modify the contents of a protected flow of media. Media that is produced from a session using the "c-webrtc" identifier MUST only be displayed to users. ... RTP middleboxes and entities that forward media or data cannot promise to maintain confidentiality. Any entity that forwards content, or records content for later access by entities other than the authenticated peer, MUST NOT offer or accept a session with the "c-webrtc" identifier. I don't know how to interpret this in the CLUE context. The simple answer would be to only define CLUE for use with "webrtc" as the ALPN, and leave support of "c-webrtc" undefined for now. Or possibly we should not discuss the ALPN at all. But I fear that will lead to interop problems. Thanks, Paul From nobody Thu Aug 7 18:15:46 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4682D1B28AC for ; Thu, 7 Aug 2014 18:15:45 -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] autolearn=ham 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 t14UPvOj2KXq for ; Thu, 7 Aug 2014 18:15:43 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C60B1B2896 for ; Thu, 7 Aug 2014 18:15:43 -0700 (PDT) Received: from ppp118-209-12-77.lns20.mel4.internode.on.net ([118.209.12.77]:51316 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XFYlm-00007t-Fb for clue@ietf.org; Fri, 08 Aug 2014 11:14:58 +1000 Message-ID: <53E424B8.7070700@nteczone.com> Date: Fri, 08 Aug 2014 11:15:36 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> In-Reply-To: <53E3EAD9.7020600@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3O-OuHCan3QD9-Kf89CiSx9bJIs Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 01:15:45 -0000 Hello Paul, As I've raised on the WebRTC list its not clear to me that either an alpn of webrtc or c-webrtc is correct for CLUE as the definition of these indicates the presence webrtc media and datachannel. CLUE may be used in environments where WebRTC controlled media is NOT used. Sending an alpn with 'webrtc' for a datachannel only case doesn't seem correct. Christian On 8/08/2014 7:08 AM, Paul Kyzivat wrote: > CLUE people should review draft-ietf-rtcweb-alpn-00. It has some > implications for us. > > It defines some two specific ALPN protocol names for use with webrtc. > These are used during DTLS initialization, and identify the > application layer protocol running on top of DTLS. > > If we are to be interoperable with webrtc, then it seems clue > implementations will be required to follow this draft. > > The two ALPN names defined are: > - webrtc > - c-webrtc > > The value "c-webrtc" is used when "confidential" media streams are > being conveyed. IIUC this is mostly a browser issue. The draft says: > > Private communications in WebRTC depend on separating control (i.e., > signaling) capabilities and access to media > [I-D.ietf-rtcweb-security-arch]. In this way, an application can > establish a session that is end-to-end confidential, where the ends > in question are user agents (or browsers) and not the signaling > application. > > A browser is required to enforce this control using isolation > controls similar to those used in cross-origin protections. These > protections ensure that media is protected from applications. > Applications are not able to read or modify the contents of a > protected flow of media. Media that is produced from a session using > the "c-webrtc" identifier MUST only be displayed to users. > ... > RTP middleboxes and entities that forward media or data cannot > promise to maintain confidentiality. Any entity that forwards > content, or records content for later access by entities other than > the authenticated peer, MUST NOT offer or accept a session with the > "c-webrtc" identifier. > > I don't know how to interpret this in the CLUE context. > > The simple answer would be to only define CLUE for use with "webrtc" > as the ALPN, and leave support of "c-webrtc" undefined for now. > > Or possibly we should not discuss the ALPN at all. But I fear that > will lead to interop problems. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Aug 7 19:26:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99A01A0411 for ; Thu, 7 Aug 2014 19:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 WgFD485QMe7V for ; Thu, 7 Aug 2014 19:26:08 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 165E41A0410 for ; Thu, 7 Aug 2014 19:26:08 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by QMTA11.westchester.pa.mail.comcast.net with comcast id c1PC1o0011c6gX85B2S74c; Fri, 08 Aug 2014 02:26:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id c2S71o00L3ZTu2S3j2S7yD; Fri, 08 Aug 2014 02:26:07 +0000 Message-ID: <53E4353F.3010904@alum.mit.edu> Date: Thu, 07 Aug 2014 22:26:07 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> In-Reply-To: <53E424B8.7070700@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407464767; bh=6hUzV2RU4mC6ES2lRrjQstaYFktOB48e6FA3vzaSkQ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=nTLXMb+LtSYv377urucBFKCxiMzHJlOV/maG0e992eLbcSm0ixETRglytOLc6LVeO +TF1p4IhnGoagdMq3i5twHmgPX2dLuC80o/9xT3juvJn5OEiP3cCv5404t56V44hFO f4P6xFNl8/VGMxQzBai8g00GyD1fsti9aGHMAXih6Xvbs+RW98v8AtcKf8tr5AXwUa regasDr4sbQ3f6sm1Y4dnWbxVtiYeEBFZY9zOl7/yFSMdwaYqssb0GbXJTqCKn+ysq L5z/og21Lk6xkM004gCmPMeWx3lbuJs3VYI5QPw4zAF6bvCvTtXED4dJrJNtNR5nd+ 18G0xGDORKpKQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/0CS5StW5LtkBHOoxLMgP1oL3ZZQ Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 02:26:09 -0000 On 8/7/14 9:15 PM, Christian Groves wrote: > Hello Paul, > > As I've raised on the WebRTC list its not clear to me that either an > alpn of webrtc or c-webrtc is correct for CLUE as the definition of > these indicates the presence webrtc media and datachannel. CLUE may be > used in environments where WebRTC controlled media is NOT used. Sending > an alpn with 'webrtc' for a datachannel only case doesn't seem correct. That argument applies equally to webrtc itself. There will no doubt be webrtc applications that only use the data channels, not the media streams. Note that I did post a query to the rtcweb list asking about use of other ALPN ids with WebRTC. Thanks, Paul > Christian > > On 8/08/2014 7:08 AM, Paul Kyzivat wrote: >> CLUE people should review draft-ietf-rtcweb-alpn-00. It has some >> implications for us. >> >> It defines some two specific ALPN protocol names for use with webrtc. >> These are used during DTLS initialization, and identify the >> application layer protocol running on top of DTLS. >> >> If we are to be interoperable with webrtc, then it seems clue >> implementations will be required to follow this draft. >> >> The two ALPN names defined are: >> - webrtc >> - c-webrtc >> >> The value "c-webrtc" is used when "confidential" media streams are >> being conveyed. IIUC this is mostly a browser issue. The draft says: >> >> Private communications in WebRTC depend on separating control (i.e., >> signaling) capabilities and access to media >> [I-D.ietf-rtcweb-security-arch]. In this way, an application can >> establish a session that is end-to-end confidential, where the ends >> in question are user agents (or browsers) and not the signaling >> application. >> >> A browser is required to enforce this control using isolation >> controls similar to those used in cross-origin protections. These >> protections ensure that media is protected from applications. >> Applications are not able to read or modify the contents of a >> protected flow of media. Media that is produced from a session using >> the "c-webrtc" identifier MUST only be displayed to users. >> ... >> RTP middleboxes and entities that forward media or data cannot >> promise to maintain confidentiality. Any entity that forwards >> content, or records content for later access by entities other than >> the authenticated peer, MUST NOT offer or accept a session with the >> "c-webrtc" identifier. >> >> I don't know how to interpret this in the CLUE context. >> >> The simple answer would be to only define CLUE for use with "webrtc" >> as the ALPN, and leave support of "c-webrtc" undefined for now. >> >> Or possibly we should not discuss the ALPN at all. But I fear that >> will lead to interop problems. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Fri Aug 8 14:06:43 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C1E1A854D for ; Fri, 8 Aug 2014 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 c-sE8sNDZg-p for ; Fri, 8 Aug 2014 14:06:30 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC141A0379 for ; Fri, 8 Aug 2014 14:06:29 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so6196388wes.34 for ; Fri, 08 Aug 2014 14:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=MGJ1Yoj1Xjrk6hz2BuZlhukK2Vqsd5nI6/LIRlsV5k8=; b=FxWzkZYJzvK7Sin5byuLkSH8MFW0o33XKhWzpjxAPF4kYYhYyjgyoaJ1ugt/YmKIqV rL+xcA8JVDgM3C0h/cyDx7ZMoACAuM1X44W2wfUtDIPgM7cWCEvFXZyk9IRP9zFm96Ll yrKC0ccIOSkfyQCU6ghK2Muh0tCfQRy60TuiPmw3cY2szeW+uVUUwCCFO1N8wqrPJAv6 Y+3Pudt7qy3t6Axo38Qraevtnh+SxAHYgP/4k69uGqpMxXA9QrAd/OPdOCfeWkbBEMlp RGprJFPCqa6M3sBVa4NIQO5VhZvq2uXrFzXvMrmBF6idxGHLAFb7zS/+4tLYW7jDZTjc /T8w== MIME-Version: 1.0 X-Received: by 10.194.62.67 with SMTP id w3mr34404171wjr.32.1407531987958; Fri, 08 Aug 2014 14:06:27 -0700 (PDT) Received: by 10.216.222.10 with HTTP; Fri, 8 Aug 2014 14:06:27 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Aug 2014 16:06:27 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=047d7b872e9a2701eb05002494ce Archived-At: http://mailarchive.ietf.org/arch/msg/clue/9tPWdEx1M5OkbBQngqvqZonqGq8 Subject: [clue] Fwd: [rtcweb] AD review of draft-ietf-rtcweb-data-protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:06:37 -0000 --047d7b872e9a2701eb05002494ce Content-Type: text/plain; charset=UTF-8 FYI...since this document is a dependency for the draft-ietf-clue-datachannel, it would be good for folks to review the RTCWEB document alongside the clue data channel document during IETF Last Call which is basically our last chance to provide any input. Regards, Mary. ---------- Forwarded message ---------- From: Richard Barnes Date: Fri, Aug 8, 2014 at 3:27 PM Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-protocol To: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-protocol@tools.ietf.org I have reviewed this document in preparation for IETF LC. In general, it looks good, and I have requested LC. There are some comments below that should be addressed along with IETF LC comments. --Richard MAJOR: Section 4. "To avoid glare..." The term "glare" is undefined in this document, and will probably be unfamiliar to many readers. Please add it to the Terminology section. Section 4. "When using SCTP over DTLS..." This qualification is unnecessary, since data channels always use SCTP/DTLS/UDP: """ The DTLS encapsulation of SCTP packets as described in [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used. """ So this should be "Since data channels use the DTLS encapsulation of SCTP..." Section 6. "... all parameters in the DATA_CHANNEL_OPEN message are valid" The receiver MUST fail if the parameters are invalid, but you never define what validation needs to be performed. For example, is the DCEP layer supposed to verify that the Protocol and Label fields are valid UTF-8? Section 10.2. [I-D.ietf-rtcweb-data-channel] This reference needs to be normative, since, after all, this is a protocol for negotiating data channels. MINOR / EDITORIAL: Section 5.1. [packet diagram] The diagram seems to imply that the protocol field starts on a 4-octet boundary, even though this is not true. It might be good if you could find a way to reformat the diagram to make this clearer. Section 5.1. "The suggested value of this field for IANA is 0x03" You're defining the initial contents of this registry. Just say it. Likewise for the same text in Section 5.2. Section 6. "an Stream identifier" -> "a stream identifier" _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --047d7b872e9a2701eb05002494ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...since this document is a dependency for the draft-ie= tf-clue-datachannel, it would be good for folks to review the RTCWEB docume= nt alongside the clue data channel document during IETF Last Call which is = basically our last chance to provide any input.

Regards,
Mary.

-= --------- Forwarded message ----------
From: Richard Barnes <rlb@ipv.sx>
Date: = Fri, Aug 8, 2014 at 3:27 PM
Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-protocol
To: "= ;rtcweb@ietf.org" <rtcweb@ietf.org>, draft-ietf-rtcweb-data-protocol= @tools.ietf.org


I have reviewed this document in pr= eparation for IETF LC.=C2=A0 In general, it looks good, and I have requeste= d LC.=C2=A0 There are some comments below that should be addressed along wi= th IETF LC comments.
--Richard


MAJOR:

=
Section 4. "To avoid glare..."
The term "= glare" is undefined in this document, and will probably be unfamiliar = to many readers.=C2=A0 Please add it to the Terminology section.

Section 4. "When using SCTP over DTLS..."
This qualification is unnecessary, since data channels always use SCT= P/DTLS/UDP:
"""
=C2=A0=C2=A0 The DTLS encapsulation of= SCTP packets as described in
=C2=A0=C2=A0 [I-D.ietf-tsvwg-sctp-dtls-encaps] MUST be used.
""= ;"
So this should be "Since data channels use the D= TLS encapsulation of SCTP..."

Section 6. "... a= ll parameters in the DATA_CHANNEL_OPEN message are valid"
The receiver MUST fail if the parameters are invalid, but you never define=20 what validation needs to be performed.=C2=A0 For example, is the DCEP layer= =20 supposed to verify that the Protocol and Label fields are valid UTF-8?
<= br>
Section 10.2. [I-D.ietf-rtcweb-data-channel]
Th= is reference needs to be normative, since, after all, this is a protocol fo= r negotiating data channels.



MINOR / EDITORIAL:

Section 5.1. [packet diagram]
The diagram seems to imply th= at the protocol field starts on a 4-octet boundary, even though this is not= true.=C2=A0 It might be good if you could find a way to reformat the diagr= am to make this clearer.

Section 5.1. "The suggested value of this field for IANA is 0x03&q= uot;
You're defining the initial contents of this registr= y.=C2=A0 Just say it.=C2=A0 Likewise for the same text in Section 5.2.
<= br>
Section 6. "an Stream identifier" -> "a stream ident= ifier"


_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--047d7b872e9a2701eb05002494ce-- From nobody Fri Aug 8 14:07:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 079091A0AD6 for ; Fri, 8 Aug 2014 14:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 TqCSwl0vc3Wx for ; Fri, 8 Aug 2014 14:07:53 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735441A0379 for ; Fri, 8 Aug 2014 14:07:53 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so6271912wes.9 for ; Fri, 08 Aug 2014 14:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TOWJ5ITWqL5QtlKbvLq86be+au5cYnWqRoS1D/nyc7g=; b=ho5zRrqOvdGD0GCeWRWNrVxXNAjlZC3A5dd/uxUM+NhZlflmjv4TRT0UaWhU5Mk5Q3 L4GVWdnkhJLI/EPWHGFWZ9q06XbIrBQyM9SUQTMYsRni/3vkHoyVdOkQ3UeKdmaVtvMW yPEP9akmCpz7cEYReKsGcXp+/9REaEw9F6FniydWOTU7ZsjLGJysMQPCemGdrJoWQ6Ct 5l2peNu0JVKNfwSodnJYsQlYifMk8CdC/MEQg6pUuF8DOzIEvC7xfeUrWzjWB3cosIyw d1franmOhbhwsGifxKfdzsECsDajFp7/kpAIX9+6uIR97pItr7Yne2vITub9sLO6GKWV 4CYw== MIME-Version: 1.0 X-Received: by 10.180.107.170 with SMTP id hd10mr2376491wib.77.1407532072028; Fri, 08 Aug 2014 14:07:52 -0700 (PDT) Received: by 10.216.222.10 with HTTP; Fri, 8 Aug 2014 14:07:51 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Aug 2014 16:07:51 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e89a8f2354ef29d34e05002499dd Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VtO71WOgetrbQGgV4hX4fSolwuI Subject: [clue] Fwd: [rtcweb] AD review of draft-ietf-rtcweb-data-channel X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Aug 2014 21:07:57 -0000 --e89a8f2354ef29d34e05002499dd Content-Type: text/plain; charset=UTF-8 Ditto my message on the rtcweb data-protocol document. Mary ---------- Forwarded message ---------- From: Richard Barnes Date: Fri, Aug 8, 2014 at 3:27 PM Subject: [rtcweb] AD review of draft-ietf-rtcweb-data-channel To: "rtcweb@ietf.org" , draft-ietf-rtcweb-data-channel@tools.ietf.org I have reviewed this document in preparation for IETF Last Call. I have gone ahead and requested last call, but there are some comments below that I would like to be addressed before the document goes to the IESG. --Richard MAJOR: Section 6.2. I'm very concerned about interoperability of data channels given that, e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not required, and (2) DCEP only works if it is used by both endpoints (it resets any streams that are used without DCEP negotiation). In order to avoid interoperability failure of this type, whatever mechanism is used to establish an SCTP association that is used for data channels must also negotiate the mechanism(s) that will be used to establish data channels over that association. That could be directly (by negotiating some data channels at the same time as the association), or indirectly (by indicating that DCEP or some other protocol will be used), but either way, the endpoints of the association need to know how data channels will be negotiated before they can create any data channels. This section needs to state this requirement so that applications using data channels can know that they need to meet it. Section 6.4. This section lists in passing several properties of a data channel, but doesn't give a full definition of all the things that need to be defined in order to define a data channel. Fortunately, such a list is given in draft-ietf-rtcweb-data-protocol (Section 4); I would suggest moving that here. MINOR / EDITORIAL: Figures 1 and 2 list ICE as a separate layer. That seems incorrect, since ICE isn't actually involved once the connection is set up. Section 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as properties of channels" "... (as opposed to SCTP, which applies these concepts to messages)" Section 6.4. "... and waiting for onopen to fire ... meaning of the streams" This sentence doesn't really parse, and it's not clear why these API-level considerations are relevant here. Section 6.4. "stream SCTP identifier" -> "SCTP stream identifier" ? Section 6.6. "The sender SHOULD disable the Nagle algorithm..." A reference to RFC 1122 would be helpful here. _______________________________________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/listinfo/rtcweb --e89a8f2354ef29d34e05002499dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ditto my message on the rtcweb data-protocol document.
Mary

---------- Forwarded= message ----------
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, Aug 8, 2014 at 3:27 PM
Subject: [rtcweb] AD review of draft-i= etf-rtcweb-data-channel
To: "rtc= web@ietf.org" <rtcweb@ietf.o= rg>, draft-ietf-rtcweb-data-channel@tools.ietf.org


I have reviewed this= document in preparation for IETF Last Call.=C2=A0 I have gone ahead and re= quested last call, but there are some comments below that I would like to b= e addressed before the document goes to the IESG.
--Richard


MAJOR:

S= ection 6.2.
I'm very concerned about interoperability of data chann= els given that, e.g., (1) DCEP [draft-ietf-rtcweb-data-protocol] is not req= uired, and (2) DCEP only works if it is used by both endpoints (it resets a= ny streams that are used without DCEP negotiation).=C2=A0 In order to avoid= interoperability failure of this type, whatever mechanism is used to estab= lish an SCTP association that is used for data channels must also negotiate= the mechanism(s) that will be used to establish data channels over that as= sociation.=C2=A0 That could be directly (by negotiating some data channels = at the same time as the association), or indirectly (by indicating that DCE= P or some other protocol will be used), but either way, the endpoints of th= e association need to know how data channels will be negotiated before they= can create any data channels.=C2=A0 This section needs to state this requi= rement so that applications using data channels can know that they need to = meet it.

Section 6.4.
This section lists in= passing several properties of a data channel, but doesn't give a full = definition of all the things that need to be defined in order to define a d= ata channel.=C2=A0 Fortunately, such a list is given in draft-ietf-rtcweb-d= ata-protocol (Section 4); I would suggest moving that here.



MINOR / EDITORIAL:

Figures 1 and = 2 list ICE as a separate layer.=C2=A0 That seems incorrect, since ICE isn&#= 39;t actually involved once the connection is set up.

Section = 6.4. "... in-sequence, out-of-sequence, reliable and unreliable as pro= perties of channels"
"... (as opposed to SCTP, which applies these concepts to messag= es)"

Section 6.4. "... and waiting for onopen t= o fire ... meaning of the streams"
This sentence doesn&#= 39;t really parse, and it's not clear why these API-level consideration= s are relevant here.

Section 6.4. "stream SCTP identifier" -= > "SCTP stream identifier" ?

Section 6.= 6. "The sender SHOULD disable the Nagle algorithm..."
A reference to RFC 1122 would be helpful here.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
= https://www.ietf.org/mailman/listinfo/rtcweb


--e89a8f2354ef29d34e05002499dd-- From nobody Sat Aug 9 11:51:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A593D1A0196; Sat, 9 Aug 2014 11:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.132 X-Spam-Level: X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668] autolearn=ham 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 vSQSEH-718yU; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 C66561A0009; Sat, 9 Aug 2014 11:48:16 -0700 (PDT) Received: from [10.0.1.23] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id s79ImD3G015211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 9 Aug 2014 13:48:15 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.23] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ben Campbell Date: Sat, 9 Aug 2014 13:48:13 -0500 X-Mao-Original-Outgoing-Id: 429302893.093861-e61d2b4180cda6697e5d18b3ca4c2570 Content-Transfer-Encoding: quoted-printable Message-Id: <941BB385-72AA-42F2-A40C-0C1ACC3D2334@nostrum.com> References: To: tsvwg@ietf.org, avt@ietf.org, "clue@ietf.org" , mmusic@ietf.org, rtcweb@ietf.org, rmcat@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ThKjFyk9pJiC3AT7WIlr0__KzSY Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org Subject: [clue] Fwd: WGLC: draft-ietf-dart-dscp-rtp-02 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Aug 2014 18:48:25 -0000 Hi, The DART working group has started a last call for = draft-ietf-dart-dscp-rtp-02, ending on August 22. This informational = draft describes considerations for the use of DiffServ code points in = situations where one multiplexes multiple RTP packet streams, and = potentially other protocol streams, that share the same 5-tuple.=20 Since this draft is likely of interest to several working groups, I = would like to solicit additional reviews from participants of TSVWG, = AVTCORE, MMUSIC, CLUE, RTCWEB, and RMCAT. Please send any feedback = (including feedback to the effect of "this is ready to progress") to the = DART working group mailing list. Thanks! Ben. Begin forwarded message: > Resent-From: draft-alias-bounces@tools.ietf.org > From: Ben Campbell > Subject: WGLC: draft-ietf-dart-dscp-rtp-02 > Date: August 9, 2014 at 12:50:16 PM CDT > Resent-To: ben@nostrum.com, david.black@emc.com, paulej@packetizer.com > To: dart@ietf.org > Cc: draft-ietf-dart-dscp-rtp.all@tools.ietf.org, mls.ietf@gmail.com, = Richard Barnes >=20 > This is a DART Working Group Last Call of draft-ietf-dart-dscp-rtp-02. = It's available on the data tracker at the following URL: >=20 > https://datatracker.ietf.org/doc/draft-ietf-dart-dscp-rtp/ >=20 > The WGLC will conclude on 22 August, 2014. Please send your comments = to the authors and the DART mailing list. If you've reviewed it and = think it's good to go, please say so. >=20 > Thanks! >=20 > Ben. >=20 From nobody Mon Aug 11 18:08:47 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD7971A0026 for ; Mon, 11 Aug 2014 18:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5] autolearn=ham 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 orj1XxHlHyOh for ; Mon, 11 Aug 2014 18:08:42 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 055E11A0032 for ; Mon, 11 Aug 2014 18:08:41 -0700 (PDT) Received: from ppp118-209-171-186.lns20.mel6.internode.on.net ([118.209.171.186]:53972 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XH0YI-0007nm-JO for clue@ietf.org; Tue, 12 Aug 2014 11:07:02 +1000 Message-ID: <53E96915.3060407@nteczone.com> Date: Tue, 12 Aug 2014 11:08:37 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> <53E4353F.3010904@alum.mit.edu> In-Reply-To: <53E4353F.3010904@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/zqU8IPwneVB6KmpJDaOpKug1oaI Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 01:08:45 -0000 Hello Paul, I guess this relates to your comments about data channel being a general purpose mechanism and not a "webRTC" specific one. I think its fair for a WebRTC device/browser only using data channels to assert an ALPN with "webrtc" or "c-webrtc". But if there's a non-webrtc device e.g. a CLUE endpoint using data channel is that still really "webrtc"? Regards, Christian On 8/08/2014 12:26 PM, Paul Kyzivat wrote: > On 8/7/14 9:15 PM, Christian Groves wrote: >> Hello Paul, >> >> As I've raised on the WebRTC list its not clear to me that either an >> alpn of webrtc or c-webrtc is correct for CLUE as the definition of >> these indicates the presence webrtc media and datachannel. CLUE may be >> used in environments where WebRTC controlled media is NOT used. Sending >> an alpn with 'webrtc' for a datachannel only case doesn't seem correct. > > That argument applies equally to webrtc itself. There will no doubt be > webrtc applications that only use the data channels, not the media > streams. > > Note that I did post a query to the rtcweb list asking about use of > other ALPN ids with WebRTC. > > Thanks, > Paul > >> Christian >> >> On 8/08/2014 7:08 AM, Paul Kyzivat wrote: >>> CLUE people should review draft-ietf-rtcweb-alpn-00. It has some >>> implications for us. >>> >>> It defines some two specific ALPN protocol names for use with webrtc. >>> These are used during DTLS initialization, and identify the >>> application layer protocol running on top of DTLS. >>> >>> If we are to be interoperable with webrtc, then it seems clue >>> implementations will be required to follow this draft. >>> >>> The two ALPN names defined are: >>> - webrtc >>> - c-webrtc >>> >>> The value "c-webrtc" is used when "confidential" media streams are >>> being conveyed. IIUC this is mostly a browser issue. The draft says: >>> >>> Private communications in WebRTC depend on separating control (i.e., >>> signaling) capabilities and access to media >>> [I-D.ietf-rtcweb-security-arch]. In this way, an application can >>> establish a session that is end-to-end confidential, where the ends >>> in question are user agents (or browsers) and not the signaling >>> application. >>> >>> A browser is required to enforce this control using isolation >>> controls similar to those used in cross-origin protections. These >>> protections ensure that media is protected from applications. >>> Applications are not able to read or modify the contents of a >>> protected flow of media. Media that is produced from a session >>> using >>> the "c-webrtc" identifier MUST only be displayed to users. >>> ... >>> RTP middleboxes and entities that forward media or data cannot >>> promise to maintain confidentiality. Any entity that forwards >>> content, or records content for later access by entities other than >>> the authenticated peer, MUST NOT offer or accept a session with the >>> "c-webrtc" identifier. >>> >>> I don't know how to interpret this in the CLUE context. >>> >>> The simple answer would be to only define CLUE for use with "webrtc" >>> as the ALPN, and leave support of "c-webrtc" undefined for now. >>> >>> Or possibly we should not discuss the ALPN at all. But I fear that >>> will lead to interop problems. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Aug 11 18:27:24 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16EA61A0045 for ; Mon, 11 Aug 2014 18:27:23 -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] autolearn=ham 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 5hpajJ2vvC8o for ; Mon, 11 Aug 2014 18:27:21 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508D51A0035 for ; Mon, 11 Aug 2014 18:27:21 -0700 (PDT) Received: from ppp118-209-171-186.lns20.mel6.internode.on.net ([118.209.171.186]:54136 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XH0qM-0002Tx-UY for clue@ietf.org; Tue, 12 Aug 2014 11:25:43 +1000 Message-ID: <53E96D75.6050501@nteczone.com> Date: Tue, 12 Aug 2014 11:27:17 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140722135051.17260.70318.idtracker@ietfa.amsl.com> In-Reply-To: <20140722135051.17260.70318.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VbAQOLO7hiwHZs1voJ3RVL8Kuvw Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 01:27:23 -0000 Hello, I had a look through just to see how the draft was sitting with the current state of CLUE. A couple of comments/questions: cl.4 3rd para: The paragraph states "Even though Session multiplexing is supported by CLUE, for scaling reasons, CLUE recommends using SSRC multiplexing in a single or multiple sessions." Do any of the current drafts/RFCs state this? I thought multiplexing was outside CLUE. Cl.6.1 - The example needs to be updated to align with the framework work. i.e. the "purpose" was changed to "content". Switched and Composed have been removed. Cl.6.1 - Should the SIP offer still show group="CLUE" etc. as per the signalling draft? Regards, Christian On 22/07/2014 11:50 PM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. > > Title : Mapping RTP streams to CLUE media captures > Authors : Roni Even > Jonathan Lennox > Filename : draft-ietf-clue-rtp-mapping-02.txt > Pages : 17 > Date : 2014-07-22 > > Abstract: > This document describes mechanisms and recommended practice for > mapping RTP media streams defined in SDP to CLUE media captures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Aug 12 05:06:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1FC11A0818 for ; Tue, 12 Aug 2014 05:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 h03NBdhZNZZs for ; Tue, 12 Aug 2014 05:06:16 -0700 (PDT) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D20B1A07D1 for ; Tue, 12 Aug 2014 05:06:15 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id ho1so5728447wib.14 for ; Tue, 12 Aug 2014 05:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:thread-index :content-language; bh=A9gBpvvqJlK/suJzKAyt5XMrYuNiASFdMgbjX9YqUQQ=; b=CLAw1Epv8L1p6H050JmGeuQjjB57DrSJWduMHiTs3lY585MIofV2+L4yyh0HFLztji Wba6AYKZ2JJFGF/iaMQcRBXTf4vjx4bmP8uJ/nJpY3yRvHX2bGM41DrOeYiNXebRqozS CcjwIebDYxhx1nClIC1jL1VCSd+zLXlqlPuKcUIqT+YajBqucCHPxz6Y1Ug/X1IdPZmC nMgNQvyicnVrjuXizo11+Qtrdw/H9DC7BqfEhUvbI7wH7xYGTLJ0Ty81G+Sr6cyKBEjc aBU9LkkQo+n82Q+eUzuoCge1K4nkfitgfdeACEpW13E9urSrbnIsQ0+sA4SNiN1ddETt Dq6Q== X-Received: by 10.180.24.225 with SMTP id x1mr31810047wif.14.1407845173972; Tue, 12 Aug 2014 05:06:13 -0700 (PDT) Received: from RoniE (bzq-79-177-13-40.red.bezeqint.net. [79.177.13.40]) by mx.google.com with ESMTPSA id h3sm8877567wjn.10.2014.08.12.05.06.11 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Aug 2014 05:06:13 -0700 (PDT) From: "Roni Even" To: "'Christian Groves'" , References: <20140722135051.17260.70318.idtracker@ietfa.amsl.com> <53E96D75.6050501@nteczone.com> In-Reply-To: <53E96D75.6050501@nteczone.com> Date: Tue, 12 Aug 2014 15:06:09 +0300 Message-ID: <054f01cfb625$cf33aff0$6d9b0fd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKrdo/E/h4aCOvOsVx18WQHeZiW9AHRWCAamgbTZgA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/9NPEWm6Yxds3Y8iyKlFgQVTmk9A Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 12:06:18 -0000 Hi Christian, Thanks for your comments. The draft needs a major re-write and also address RTP usage is CLUE. I will do it before next IEWTF meeting Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: 12 August, 2014 4:27 AM > To: clue@ietf.org > Subject: Re: [clue] I-D Action: draft-ietf-clue-rtp-mapping-02.txt > > Hello, > > I had a look through just to see how the draft was sitting with the current state > of CLUE. A couple of comments/questions: > > cl.4 3rd para: The paragraph states "Even though Session multiplexing is > supported by CLUE, for scaling reasons, CLUE recommends using SSRC > multiplexing in a single or multiple sessions." Do any of the current drafts/RFCs > state this? I thought multiplexing was outside CLUE. > Cl.6.1 - The example needs to be updated to align with the framework work. > i.e. the "purpose" was changed to "content". Switched and Composed have > been removed. > Cl.6.1 - Should the SIP offer still show group="CLUE" etc. as per the signalling > draft? > > Regards, Christian > > On 22/07/2014 11:50 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > This draft is a work item of the ControLling mUltiple streams for > tElepresence Working Group of the IETF. > > > > Title : Mapping RTP streams to CLUE media captures > > Authors : Roni Even > > Jonathan Lennox > > Filename : draft-ietf-clue-rtp-mapping-02.txt > > Pages : 17 > > Date : 2014-07-22 > > > > Abstract: > > This document describes mechanisms and recommended practice for > > mapping RTP media streams defined in SDP to CLUE media captures. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ > > > > There's also a htmlized version available at: > > http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-02 > > > > A diff from the previous version is available at: > > http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-02 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Aug 12 09:57:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646631A035E for ; Tue, 12 Aug 2014 09:57:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 aTJlbXiyXJd4 for ; Tue, 12 Aug 2014 09:57:16 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8BE1A035C for ; Tue, 12 Aug 2014 09:57:15 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta14.westchester.pa.mail.comcast.net with comcast id dsnM1o0060EZKEL5EsxFJ2; Tue, 12 Aug 2014 16:57:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id dsxE1o00s3ZTu2S3MsxFCc; Tue, 12 Aug 2014 16:57:15 +0000 Message-ID: <53EA476A.7050506@alum.mit.edu> Date: Tue, 12 Aug 2014 12:57:14 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> <53E4353F.3010904@alum.mit.edu> <53E96915.3060407@nteczone.com> In-Reply-To: <53E96915.3060407@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407862635; bh=PhDeP8/xXNPM5V+j+QWPvdEHLpCJhUYGBXxk++gsaQo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ZXVd1Y7m1nGn6SrUjbTIbeuZGUHExzQ6GTYn34Ay8BL51yF6H2B1LBI55suM7bQzg faK7t6O0O11tFJYcjDaj6E74VAI5EOoGdwqsjMglrGDV7BxQXlzk+s17wbro7p/8d2 Bscs8z/9e7bgCmitiyVknhDwTxot/qMvXzkXPBsIGnHOgcjfKmZ7UuTz4de3pabg9g tEcynxKMfXB37vp84mHmqFWgTP+g5WCpI91ftoUB9dGfKtdNKtXvSI/VllYIZ11s+W QnO3eghsZup3yMaAY7Vib4PjQvOam3uq1lti4/r8yP4n0SYxmL+ILxgX3bU++wcfoO BLFGnXP+FssVA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/blvpOmghwf1MpAP-hT-B9Qokcl8 Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 16:57:18 -0000 On 8/11/14 9:08 PM, Christian Groves wrote: > Hello Paul, > > I guess this relates to your comments about data channel being a general > purpose mechanism and not a "webRTC" specific one. I think its fair for > a WebRTC device/browser only using data channels to assert an ALPN with > "webrtc" or "c-webrtc". But if there's a non-webrtc device e.g. a CLUE > endpoint using data channel is that still really "webrtc"? I think we need to distinguish between the behavior and the name that is attached to the behavior. We want some of the behavior specified in webrtc and rtcweb specs, for multiple reasons. In some cases we want it in order to enable interoperation with devices that are constrained by webrtc. We also want some features that happen to have been defined as part of webrtc, without regard to interoperation with webrtc. And further, if we need to behave one way when interoperating, then it is convenient to specify that we will also operate that way when not interoperating, just to keep things simple. To achieve those things, we end up needing to use some of the names for things that webrtc is choosing. My *preference* is to convince them to use generic (non-webrtc-specific) names for things that have broader applicability. But if we loose those battles then so be it - they are just names, even if stupid ones. Using them doesn't prevent us for doing what we need to do. It just presents an additional documentation challenge. While we could conceivably use different names depending on context, that is likely to just make things more complex. Somebody did suggest that as a client we could offer alternative alpn values, and let the server choose one. So we could offer both "clue" and "webrtc", and be happy with either of them being accepted. And we could act exactly the same in both cases. But that buys us the obligation to define what it means when the "clue" alpn is used. That is extra work for us. Thanks, Paul > Regards, Christian > > On 8/08/2014 12:26 PM, Paul Kyzivat wrote: >> On 8/7/14 9:15 PM, Christian Groves wrote: >>> Hello Paul, >>> >>> As I've raised on the WebRTC list its not clear to me that either an >>> alpn of webrtc or c-webrtc is correct for CLUE as the definition of >>> these indicates the presence webrtc media and datachannel. CLUE may be >>> used in environments where WebRTC controlled media is NOT used. Sending >>> an alpn with 'webrtc' for a datachannel only case doesn't seem correct. >> >> That argument applies equally to webrtc itself. There will no doubt be >> webrtc applications that only use the data channels, not the media >> streams. >> >> Note that I did post a query to the rtcweb list asking about use of >> other ALPN ids with WebRTC. >> >> Thanks, >> Paul >> >>> Christian >>> >>> On 8/08/2014 7:08 AM, Paul Kyzivat wrote: >>>> CLUE people should review draft-ietf-rtcweb-alpn-00. It has some >>>> implications for us. >>>> >>>> It defines some two specific ALPN protocol names for use with webrtc. >>>> These are used during DTLS initialization, and identify the >>>> application layer protocol running on top of DTLS. >>>> >>>> If we are to be interoperable with webrtc, then it seems clue >>>> implementations will be required to follow this draft. >>>> >>>> The two ALPN names defined are: >>>> - webrtc >>>> - c-webrtc >>>> >>>> The value "c-webrtc" is used when "confidential" media streams are >>>> being conveyed. IIUC this is mostly a browser issue. The draft says: >>>> >>>> Private communications in WebRTC depend on separating control (i.e., >>>> signaling) capabilities and access to media >>>> [I-D.ietf-rtcweb-security-arch]. In this way, an application can >>>> establish a session that is end-to-end confidential, where the ends >>>> in question are user agents (or browsers) and not the signaling >>>> application. >>>> >>>> A browser is required to enforce this control using isolation >>>> controls similar to those used in cross-origin protections. These >>>> protections ensure that media is protected from applications. >>>> Applications are not able to read or modify the contents of a >>>> protected flow of media. Media that is produced from a session >>>> using >>>> the "c-webrtc" identifier MUST only be displayed to users. >>>> ... >>>> RTP middleboxes and entities that forward media or data cannot >>>> promise to maintain confidentiality. Any entity that forwards >>>> content, or records content for later access by entities other than >>>> the authenticated peer, MUST NOT offer or accept a session with the >>>> "c-webrtc" identifier. >>>> >>>> I don't know how to interpret this in the CLUE context. >>>> >>>> The simple answer would be to only define CLUE for use with "webrtc" >>>> as the ALPN, and leave support of "c-webrtc" undefined for now. >>>> >>>> Or possibly we should not discuss the ALPN at all. But I fear that >>>> will lead to interop problems. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Aug 12 13:54:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704341A01E8 for ; Tue, 12 Aug 2014 13:53:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham 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 VlrwwBt2fgbd for ; Tue, 12 Aug 2014 13:53:50 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F9B41A0231 for ; Tue, 12 Aug 2014 13:53:50 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so10460078wes.7 for ; Tue, 12 Aug 2014 13:53:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J2HKGvlEcV7CwIxjkmGxtb4Huxog4HrVI41rahv1aFQ=; b=xMLl5UtxrMgTPLoQWx83cwFZs+8SbErEzbnJ2Ywgs5N2CE/pnzeXhjMIuJ17uPKRNi NKO2ZkTngsXk8Z3EnQ1OUHysyfsvuQMlze+1hYiYfHA3590Mm2zuhrZQXLRChu27ITTD zQyyYHZXVLBJSpxzmPrR5a65Q1iTg6fEEIe/Ivn6GwOSN5RnKC/np+e92ptSY6NHtE7e zroWNV0YPc+SBPpe0yosI0Cqnt8Mhar2xWwKHMN8DdhuXeCO0eygCNveKyihXHk06WIB H5tqtP9PFg5Bzga90Vy3gL5nPbNwg/NinsItSHN3B3G+5MmfVEL+HfuSST3EOrjNMVSY Pz1w== MIME-Version: 1.0 X-Received: by 10.180.198.100 with SMTP id jb4mr35634069wic.72.1407876828768; Tue, 12 Aug 2014 13:53:48 -0700 (PDT) Received: by 10.216.222.10 with HTTP; Tue, 12 Aug 2014 13:53:48 -0700 (PDT) In-Reply-To: <53EA476A.7050506@alum.mit.edu> References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> <53E4353F.3010904@alum.mit.edu> <53E96915.3060407@nteczone.com> <53EA476A.7050506@alum.mit.edu> Date: Tue, 12 Aug 2014 15:53:48 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=047d7b624608443390050074deb3 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4C_EjFlMsYPsKhF-wnbOBLtg8I0 Cc: CLUE Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Aug 2014 20:53:53 -0000 --047d7b624608443390050074deb3 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat wrote: > On 8/11/14 9:08 PM, Christian Groves wrote: > >> Hello Paul, >> >> I guess this relates to your comments about data channel being a general >> purpose mechanism and not a "webRTC" specific one. I think its fair for >> a WebRTC device/browser only using data channels to assert an ALPN with >> "webrtc" or "c-webrtc". But if there's a non-webrtc device e.g. a CLUE >> endpoint using data channel is that still really "webrtc"? >> > > I think we need to distinguish between the behavior and the name that is > attached to the behavior. > > We want some of the behavior specified in webrtc and rtcweb specs, for > multiple reasons. In some cases we want it in order to enable > interoperation with devices that are constrained by webrtc. We also want > some features that happen to have been defined as part of webrtc, without > regard to interoperation with webrtc. And further, if we need to behave one > way when interoperating, then it is convenient to specify that we will also > operate that way when not interoperating, just to keep things simple. > > To achieve those things, we end up needing to use some of the names for > things that webrtc is choosing. My *preference* is to convince them to use > generic (non-webrtc-specific) names for things that have broader > applicability. But if we loose those battles then so be it - they are just > names, even if stupid ones. Using them doesn't prevent us for doing what we > need to do. It just presents an additional documentation challenge. > > While we could conceivably use different names depending on context, that > is likely to just make things more complex. > > Somebody did suggest that as a client we could offer alternative alpn > values, and let the server choose one. So we could offer both "clue" and > "webrtc", and be happy with either of them being accepted. And we could act > exactly the same in both cases. But that buys us the obligation to define > what it means when the "clue" alpn is used. That is extra work for us. > [MB] As an individual, I don't see CLUE defining another alpn value to be a negative. I think it adds clarity and can help us avoid confusion. Documenting what it means when "clue" alpn is used is a good thing IMHO, as we really should describe how alpn works for CLUE regardless of the alpn value.[/MB] > > Thanks, > Paul > > > Regards, Christian >> >> On 8/08/2014 12:26 PM, Paul Kyzivat wrote: >> >>> On 8/7/14 9:15 PM, Christian Groves wrote: >>> >>>> Hello Paul, >>>> >>>> As I've raised on the WebRTC list its not clear to me that either an >>>> alpn of webrtc or c-webrtc is correct for CLUE as the definition of >>>> these indicates the presence webrtc media and datachannel. CLUE may be >>>> used in environments where WebRTC controlled media is NOT used. Sending >>>> an alpn with 'webrtc' for a datachannel only case doesn't seem correct. >>>> >>> >>> That argument applies equally to webrtc itself. There will no doubt be >>> webrtc applications that only use the data channels, not the media >>> streams. >>> >>> Note that I did post a query to the rtcweb list asking about use of >>> other ALPN ids with WebRTC. >>> >>> Thanks, >>> Paul >>> >>> Christian >>>> >>>> On 8/08/2014 7:08 AM, Paul Kyzivat wrote: >>>> >>>>> CLUE people should review draft-ietf-rtcweb-alpn-00. It has some >>>>> implications for us. >>>>> >>>>> It defines some two specific ALPN protocol names for use with webrtc. >>>>> These are used during DTLS initialization, and identify the >>>>> application layer protocol running on top of DTLS. >>>>> >>>>> If we are to be interoperable with webrtc, then it seems clue >>>>> implementations will be required to follow this draft. >>>>> >>>>> The two ALPN names defined are: >>>>> - webrtc >>>>> - c-webrtc >>>>> >>>>> The value "c-webrtc" is used when "confidential" media streams are >>>>> being conveyed. IIUC this is mostly a browser issue. The draft says: >>>>> >>>>> Private communications in WebRTC depend on separating control (i.e., >>>>> signaling) capabilities and access to media >>>>> [I-D.ietf-rtcweb-security-arch]. In this way, an application can >>>>> establish a session that is end-to-end confidential, where the ends >>>>> in question are user agents (or browsers) and not the signaling >>>>> application. >>>>> >>>>> A browser is required to enforce this control using isolation >>>>> controls similar to those used in cross-origin protections. These >>>>> protections ensure that media is protected from applications. >>>>> Applications are not able to read or modify the contents of a >>>>> protected flow of media. Media that is produced from a session >>>>> using >>>>> the "c-webrtc" identifier MUST only be displayed to users. >>>>> ... >>>>> RTP middleboxes and entities that forward media or data cannot >>>>> promise to maintain confidentiality. Any entity that forwards >>>>> content, or records content for later access by entities other than >>>>> the authenticated peer, MUST NOT offer or accept a session with the >>>>> "c-webrtc" identifier. >>>>> >>>>> I don't know how to interpret this in the CLUE context. >>>>> >>>>> The simple answer would be to only define CLUE for use with "webrtc" >>>>> as the ALPN, and leave support of "c-webrtc" undefined for now. >>>>> >>>>> Or possibly we should not discuss the ALPN at all. But I fear that >>>>> will lead to interop problems. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --047d7b624608443390050074deb3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat &l= t;pkyzivat@alum.= mit.edu> wrote:
On 8/11/14 9:08 PM, Christia= n Groves wrote:
Hello Paul,

I guess this relates to your comments about data channel being a general purpose mechanism and not a "webRTC" specific one. I think its fa= ir for
a WebRTC device/browser only using data channels to assert an ALPN with
"webrtc" or "c-webrtc". But if there's a non-webrtc= device e.g. a CLUE
endpoint using data channel is that still really "webrtc"?

I think we need to distinguish between the behavior and the name that is at= tached to the behavior.

We want some of the behavior specified in webrtc and rtcweb specs, for mult= iple reasons. In some cases we want it in order to enable interoperation wi= th devices that are constrained by webrtc. We also want some features that = happen to have been defined as part of webrtc, without regard to interopera= tion with webrtc. And further, if we need to behave one way when interopera= ting, then it is convenient to specify that we will also operate that way w= hen not interoperating, just to keep things simple.

To achieve those things, we end up needing to use some of the names for thi= ngs that webrtc is choosing. My *preference* is to convince them to use gen= eric (non-webrtc-specific) names for things that have broader applicability= . But if we loose those battles then so be it - they are just names, even i= f stupid ones. Using them doesn't prevent us for doing what we need to = do. It just presents an additional documentation challenge.

While we could conceivably use different names depending on context, that i= s likely to just make things more complex.

Somebody did suggest that as a client we could offer alternative alpn value= s, and let the server choose one. So we could offer both "clue" a= nd "webrtc", and be happy with either of them being accepted. And= we could act exactly the same in both cases. But that buys us the obligati= on to define what it means when the "clue" alpn is used. That is = extra work for us.
[MB] As an individual, I don't see CLUE defining anot= her alpn value to be a negative. =C2=A0I think it adds clarity and can help= us avoid confusion. Documenting what it means when "clue" alpn i= s used is a good thing IMHO, as we really should describe how alpn works fo= r CLUE regardless of the alpn value.[/MB]

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

Regards, Christian

On 8/08/2014 12:26 PM, Paul Kyzivat wrote:
On 8/7/14 9:15 PM, Christian Groves wrote:
Hello Paul,

As I've raised on the WebRTC list its not clear to me that either an alpn of webrtc or c-webrtc is correct for CLUE as the definition of
these indicates the presence webrtc media and datachannel. CLUE may be
used in environments where WebRTC controlled media is NOT used. Sending
an alpn with 'webrtc' for a datachannel only case doesn't seem = correct.

That argument applies equally to webrtc itself. There will no doubt be
webrtc applications that only use the data channels, not the media
streams.

Note that I did post a query to the rtcweb list asking about use of
other ALPN ids with WebRTC.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Paul

Christian

On 8/08/2014 7:08 AM, Paul Kyzivat wrote:
CLUE people should review draft-ietf-rtcweb-alpn-00. It has some
implications for us.

It defines some two specific ALPN protocol names for use with webrtc.
These are used during DTLS initialization, and identify the
application layer protocol running on top of DTLS.

If we are to be interoperable with webrtc, then it seems clue
implementations will be required to follow this draft.

The two ALPN names defined are:
- webrtc
- c-webrtc

The value "c-webrtc" is used when "confidential" media = streams are
being conveyed. IIUC this is mostly a browser issue. The draft says:

=C2=A0 =C2=A0Private communications in WebRTC depend on separating control = (i.e.,
=C2=A0 =C2=A0signaling) capabilities and access to media
=C2=A0 =C2=A0[I-D.ietf-rtcweb-security-arch]. =C2=A0In this way, an = application can
=C2=A0 =C2=A0establish a session that is end-to-end confidential, where the= ends
=C2=A0 =C2=A0in question are user agents (or browsers) and not the signalin= g
=C2=A0 =C2=A0application.

=C2=A0 =C2=A0A browser is required to enforce this control using isolation<= br> =C2=A0 =C2=A0controls similar to those used in cross-origin protections. Th= ese
=C2=A0 =C2=A0protections ensure that media is protected from applications.<= br> =C2=A0 =C2=A0Applications are not able to read or modify the contents of a<= br> =C2=A0 =C2=A0protected flow of media. =C2=A0Media that is produced from a s= ession
using
=C2=A0 =C2=A0the "c-webrtc" identifier MUST only be displayed to = users.
...
=C2=A0 =C2=A0RTP middleboxes and entities that forward media or data cannot=
=C2=A0 =C2=A0promise to maintain confidentiality. =C2=A0Any entity that for= wards
=C2=A0 =C2=A0content, or records content for later access by entities other= than
=C2=A0 =C2=A0the authenticated peer, MUST NOT offer or accept a session wit= h the
=C2=A0 =C2=A0"c-webrtc" identifier.

I don't know how to interpret this in the CLUE context.

The simple answer would be to only define CLUE for use with "webrtc&qu= ot;
as the ALPN, and leave support of "c-webrtc" undefined for now.
Or possibly we should not discuss the ALPN at all. But I fear that
will lead to interop problems.

=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Paul

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

--047d7b624608443390050074deb3-- From nobody Tue Aug 12 19:32:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7347E1A6FDD for ; Tue, 12 Aug 2014 19:31:59 -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] autolearn=ham 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 e4ohOhPAg9jE for ; Tue, 12 Aug 2014 19:31:57 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1759F1A6F36 for ; Tue, 12 Aug 2014 19:31:56 -0700 (PDT) Received: from ppp118-209-186-65.lns20.mel6.internode.on.net ([118.209.186.65]:54699 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHOKB-0004tl-5B for clue@ietf.org; Wed, 13 Aug 2014 12:30:03 +1000 Message-ID: <53EACE16.7090807@nteczone.com> Date: Wed, 13 Aug 2014 12:31:50 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> <53E4353F.3010904@alum.mit.edu> <53E96915.3060407@nteczone.com> <53EA476A.7050506@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/JJL_p74LGl1-YEmL1aR1R7VbqbA Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 02:31:59 -0000 Please see my comments below. Regards, Christian On 13/08/2014 6:53 AM, Mary Barnes wrote: > > > > On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat > wrote: > > On 8/11/14 9:08 PM, Christian Groves wrote: > > Hello Paul, > > I guess this relates to your comments about data channel being > a general > purpose mechanism and not a "webRTC" specific one. I think its > fair for > a WebRTC device/browser only using data channels to assert an > ALPN with > "webrtc" or "c-webrtc". But if there's a non-webrtc device > e.g. a CLUE > endpoint using data channel is that still really "webrtc"? > > > I think we need to distinguish between the behavior and the name > that is attached to the behavior. > > We want some of the behavior specified in webrtc and rtcweb specs, > for multiple reasons. In some cases we want it in order to enable > interoperation with devices that are constrained by webrtc. We > also want some features that happen to have been defined as part > of webrtc, without regard to interoperation with webrtc. And > further, if we need to behave one way when interoperating, then it > is convenient to specify that we will also operate that way when > not interoperating, just to keep things simple. > [CNG] I agree that we need some behaviour. I'm generally not fussed with names. In behaviour terms it seems strange to offer an ALPN that indicates the behaviour of "webrtc- the DTLS session is used to establish keys for a Secure Real-time Transport Protocol (SRTP) - known as DTLS-SRTP - as described in [RFC5764]." when for CLUE usage (outside WebRTC) the use of SRTP is not the case. > > > To achieve those things, we end up needing to use some of the > names for things that webrtc is choosing. My *preference* is to > convince them to use generic (non-webrtc-specific) names for > things that have broader applicability. But if we loose those > battles then so be it - they are just names, even if stupid ones. > Using them doesn't prevent us for doing what we need to do. It > just presents an additional documentation challenge. > [CNG] Preferably it would be good to use just "data channel" for the name. I think it could easily be solved by adding an ALPN just for data channel: datcha: The DTLS record layer is used for WebRTC data channels [I-D.ietf-rtcweb-data-channel]. > > While we could conceivably use different names depending on > context, that is likely to just make things more complex. > > Somebody did suggest that as a client we could offer alternative > alpn values, and let the server choose one. So we could offer both > "clue" and "webrtc", and be happy with either of them being > accepted. And we could act exactly the same in both cases. But > that buys us the obligation to define what it means when the > "clue" alpn is used. That is extra work for us. > > [MB] As an individual, I don't see CLUE defining another alpn value to > be a negative. I think it adds clarity and can help us avoid > confusion. Documenting what it means when "clue" alpn is used is a > good thing IMHO, as we really should describe how alpn works for CLUE > regardless of the alpn value.[/MB] [CNG] I think we need to take a step back on this and look from the general case. The ALPN mechanism allows the specification of multiple protocols and the selection of one. An endpoint could advertise "webrtc" and "clue" but does the selection of "webrtc" really indicate CLUE support? What happens if the endpoint uses data channel for multiple protocols i.e. CLUE and BFCP? The server chooses one, so how does it indicate CLUE AND BFCP? It could use an ALPN for datachannel but that's not being defined. With the current values the server would have to choose webrtc. Implying support of SRTP when its not actually used. Its going to get messy when specifying multiple "application" protocols. > > Thanks, > Paul > > > Regards, Christian > > On 8/08/2014 12:26 PM, Paul Kyzivat wrote: > > On 8/7/14 9:15 PM, Christian Groves wrote: > > Hello Paul, > > As I've raised on the WebRTC list its not clear to me > that either an > alpn of webrtc or c-webrtc is correct for CLUE as the > definition of > these indicates the presence webrtc media and > datachannel. CLUE may be > used in environments where WebRTC controlled media is > NOT used. Sending > an alpn with 'webrtc' for a datachannel only case > doesn't seem correct. > > > That argument applies equally to webrtc itself. There will > no doubt be > webrtc applications that only use the data channels, not > the media > streams. > > Note that I did post a query to the rtcweb list asking > about use of > other ALPN ids with WebRTC. > > Thanks, > Paul > > Christian > > On 8/08/2014 7:08 AM, Paul Kyzivat wrote: > > CLUE people should review > draft-ietf-rtcweb-alpn-00. It has some > implications for us. > > It defines some two specific ALPN protocol names > for use with webrtc. > These are used during DTLS initialization, and > identify the > application layer protocol running on top of DTLS. > > If we are to be interoperable with webrtc, then it > seems clue > implementations will be required to follow this draft. > > The two ALPN names defined are: > - webrtc > - c-webrtc > > The value "c-webrtc" is used when "confidential" > media streams are > being conveyed. IIUC this is mostly a browser > issue. The draft says: > > Private communications in WebRTC depend on > separating control (i.e., > signaling) capabilities and access to media > [I-D.ietf-rtcweb-security-arch]. In this way, > an application can > establish a session that is end-to-end > confidential, where the ends > in question are user agents (or browsers) and > not the signaling > application. > > A browser is required to enforce this control > using isolation > controls similar to those used in cross-origin > protections. These > protections ensure that media is protected from > applications. > Applications are not able to read or modify the > contents of a > protected flow of media. Media that is > produced from a session > using > the "c-webrtc" identifier MUST only be > displayed to users. > ... > RTP middleboxes and entities that forward media > or data cannot > promise to maintain confidentiality. Any > entity that forwards > content, or records content for later access by > entities other than > the authenticated peer, MUST NOT offer or > accept a session with the > "c-webrtc" identifier. > > I don't know how to interpret this in the CLUE > context. > > The simple answer would be to only define CLUE for > use with "webrtc" > as the ALPN, and leave support of "c-webrtc" > undefined for now. > > Or possibly we should not discuss the ALPN at all. > But I fear that > will lead to interop problems. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Aug 13 12:19:14 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1EE41A0642 for ; Wed, 13 Aug 2014 12:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=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 5qZXPT4Ioh4N for ; Wed, 13 Aug 2014 12:19:08 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 698121A04AB for ; Wed, 13 Aug 2014 12:19:08 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta09.westchester.pa.mail.comcast.net with comcast id eCwC1o0051vXlb859KK73W; Wed, 13 Aug 2014 19:19:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by omta17.westchester.pa.mail.comcast.net with comcast id eKK71o00d3Ge9ey3dKK7Xa; Wed, 13 Aug 2014 19:19:07 +0000 Message-ID: <53EBBA52.7050306@alum.mit.edu> Date: Wed, 13 Aug 2014 15:19:46 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> <53E4353F.3010904@alum.mit.edu> <53E96915.3060407@nteczone.com> <53EA476A.7050506@alum.mit.edu> <53EACE16.7090807@nteczone.com> In-Reply-To: <53EACE16.7090807@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1407957548; bh=t13EsW6ZVmgcPBOzz5ACaLR6x6yYjDM866QrMfifHL4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=VPf4nXLwTaAAhjjsNpCI6DalXsVtbXsAzYM8W+QVnr57U7tf4caUYIphA4t/y80qh cc/CoF6Og/zJRkKcm1XL6XPnxFEcmEyGcMwq8RwIe7zqbK/gVuE1jdp6vxMhL+siEO AApTB7padMGE5E2/j5kdikEoPZHghE1NvJstkxvCA0MJANJ1DMQUgv8J9BrhmexW5w FZ9OYEl2Zif0IF2RAej3jaCzfr3fLK8MKfBUjs2sM3lIGgeht+lzlqg3jD8X/UsCjc GRgSHUkzrszx28j5EJMJ3p5HveDByRJdKaRKXOF7KHl5fABBGWCwvp/6QEnwA7huZ5 C4fx7HXdTuQtw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Um88Y0pqx4GA2XJJhricNrlpSo0 Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Aug 2014 19:19:11 -0000 On 8/12/14 10:31 PM, Christian Groves wrote: > Please see my comments below. > > Regards, Christian > > On 13/08/2014 6:53 AM, Mary Barnes wrote: >> >> >> >> On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat > > wrote: >> >> On 8/11/14 9:08 PM, Christian Groves wrote: >> >> Hello Paul, >> >> I guess this relates to your comments about data channel being >> a general >> purpose mechanism and not a "webRTC" specific one. I think its >> fair for >> a WebRTC device/browser only using data channels to assert an >> ALPN with >> "webrtc" or "c-webrtc". But if there's a non-webrtc device >> e.g. a CLUE >> endpoint using data channel is that still really "webrtc"? >> >> >> I think we need to distinguish between the behavior and the name >> that is attached to the behavior. >> >> We want some of the behavior specified in webrtc and rtcweb specs, >> for multiple reasons. In some cases we want it in order to enable >> interoperation with devices that are constrained by webrtc. We >> also want some features that happen to have been defined as part >> of webrtc, without regard to interoperation with webrtc. And >> further, if we need to behave one way when interoperating, then it >> is convenient to specify that we will also operate that way when >> not interoperating, just to keep things simple. >> > [CNG] I agree that we need some behaviour. I'm generally not fussed with > names. In behaviour terms it seems strange to offer an ALPN that > indicates the behaviour of "webrtc- the DTLS session is used to > establish keys for a Secure Real-time Transport Protocol (SRTP) - known > as DTLS-SRTP - as described in [RFC5764]." when for CLUE usage (outside > WebRTC) the use of SRTP is not the case. AFAIK we do allow clue captures to share to be bundled with the SCTP. I can imagine that some implementations will prefer to do it that way. And the use of the ALPN for one DTLS session says nothing about what happens on other unbundled m-lines. Note what else ALPN is used to denote - HTTP vs SPDY. Those aren't applications either. AFAICT, the behavior being negotiated is behavior that can/should be the same between clue and webrtc. I don't like the name, but neither do I want to invent another name and have two different behaviors. >> To achieve those things, we end up needing to use some of the >> names for things that webrtc is choosing. My *preference* is to >> convince them to use generic (non-webrtc-specific) names for >> things that have broader applicability. But if we loose those >> battles then so be it - they are just names, even if stupid ones. >> Using them doesn't prevent us for doing what we need to do. It >> just presents an additional documentation challenge. >> > [CNG] Preferably it would be good to use just "data channel" for the name. I have proposed using data-channel instead of webrtc-datachannel on the m-line for sctp. But data-channel seems wrong here because it is about more than that - about SRTP as well. > I think it could easily be solved by adding an ALPN just for data channel: > datcha: The DTLS record layer is used for WebRTC data channels > [I-D.ietf-rtcweb-data-channel]. Then that would presumably forbid bundling media with it. Why would we want to forbid that? >> While we could conceivably use different names depending on >> context, that is likely to just make things more complex. >> >> Somebody did suggest that as a client we could offer alternative >> alpn values, and let the server choose one. So we could offer both >> "clue" and "webrtc", and be happy with either of them being >> accepted. And we could act exactly the same in both cases. But >> that buys us the obligation to define what it means when the >> "clue" alpn is used. That is extra work for us. >> >> [MB] As an individual, I don't see CLUE defining another alpn value to >> be a negative. I think it adds clarity and can help us avoid >> confusion. Documenting what it means when "clue" alpn is used is a >> good thing IMHO, as we really should describe how alpn works for CLUE >> regardless of the alpn value.[/MB] > [CNG] I think we need to take a step back on this and look from the > general case. The ALPN mechanism allows the specification of multiple > protocols and the selection of one. Yes. Unfortunately it seems to not be very clear about what it means to select one or another. Exactly what is it that you are selecting? > An endpoint could advertise "webrtc" > and "clue" but does the selection of "webrtc" really indicate CLUE > support? Why should it? We have other mechanisms to indicate clue support. For this to be used with clue the m-line needs to be in the clue group. > What happens if the endpoint uses data channel for multiple > protocols i.e. CLUE and BFCP? The server chooses one, so how does it > indicate CLUE AND BFCP? This just further points out the confusion about what an ALPN does and doesn't name. And it should be possible for a webrtc browser to be a clue client and use the SCTP association for both a clue channel and a bfcp channel. I guess it would be clearer if we were just trying to negotiate what DTLS payload is being used for. The answer to that is SCTP. But that is already known from the SDP. I suspect this ALPN thing may be an artifact for cases where there is no SDP negotiation. > It could use an ALPN for datachannel but that's > not being defined. With the current values the server would have to > choose webrtc. Implying support of SRTP when its not actually used. Its > going to get messy when specifying multiple "application" protocols. I have run out of things to say. Thanks, Paul >> Thanks, >> Paul >> >> >> Regards, Christian >> >> On 8/08/2014 12:26 PM, Paul Kyzivat wrote: >> >> On 8/7/14 9:15 PM, Christian Groves wrote: >> >> Hello Paul, >> >> As I've raised on the WebRTC list its not clear to me >> that either an >> alpn of webrtc or c-webrtc is correct for CLUE as the >> definition of >> these indicates the presence webrtc media and >> datachannel. CLUE may be >> used in environments where WebRTC controlled media is >> NOT used. Sending >> an alpn with 'webrtc' for a datachannel only case >> doesn't seem correct. >> >> >> That argument applies equally to webrtc itself. There will >> no doubt be >> webrtc applications that only use the data channels, not >> the media >> streams. >> >> Note that I did post a query to the rtcweb list asking >> about use of >> other ALPN ids with WebRTC. >> >> Thanks, >> Paul >> >> Christian >> >> On 8/08/2014 7:08 AM, Paul Kyzivat wrote: >> >> CLUE people should review >> draft-ietf-rtcweb-alpn-00. It has some >> implications for us. >> >> It defines some two specific ALPN protocol names >> for use with webrtc. >> These are used during DTLS initialization, and >> identify the >> application layer protocol running on top of DTLS. >> >> If we are to be interoperable with webrtc, then it >> seems clue >> implementations will be required to follow this >> draft. >> >> The two ALPN names defined are: >> - webrtc >> - c-webrtc >> >> The value "c-webrtc" is used when "confidential" >> media streams are >> being conveyed. IIUC this is mostly a browser >> issue. The draft says: >> >> Private communications in WebRTC depend on >> separating control (i.e., >> signaling) capabilities and access to media >> [I-D.ietf-rtcweb-security-arch]. In this way, >> an application can >> establish a session that is end-to-end >> confidential, where the ends >> in question are user agents (or browsers) and >> not the signaling >> application. >> >> A browser is required to enforce this control >> using isolation >> controls similar to those used in cross-origin >> protections. These >> protections ensure that media is protected from >> applications. >> Applications are not able to read or modify the >> contents of a >> protected flow of media. Media that is >> produced from a session >> using >> the "c-webrtc" identifier MUST only be >> displayed to users. >> ... >> RTP middleboxes and entities that forward media >> or data cannot >> promise to maintain confidentiality. Any >> entity that forwards >> content, or records content for later access by >> entities other than >> the authenticated peer, MUST NOT offer or >> accept a session with the >> "c-webrtc" identifier. >> >> I don't know how to interpret this in the CLUE >> context. >> >> The simple answer would be to only define CLUE for >> use with "webrtc" >> as the ALPN, and leave support of "c-webrtc" >> undefined for now. >> >> Or possibly we should not discuss the ALPN at all. >> But I fear that >> will lead to interop problems. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Aug 13 17:39:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9747F1A0640 for ; Wed, 13 Aug 2014 17:39:14 -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] autolearn=ham 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 GCsIr_VuJQCU for ; Wed, 13 Aug 2014 17:39:12 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C44A31A0639 for ; Wed, 13 Aug 2014 17:39:11 -0700 (PDT) Received: from ppp118-209-186-33.lns20.mel6.internode.on.net ([118.209.186.33]:57359 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XHj2Q-0005WM-AA for clue@ietf.org; Thu, 14 Aug 2014 10:37:06 +1000 Message-ID: <53EC0529.50800@nteczone.com> Date: Thu, 14 Aug 2014 10:39:05 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53E3EAD9.7020600@alum.mit.edu> <53E424B8.7070700@nteczone.com> <53E4353F.3010904@alum.mit.edu> <53E96915.3060407@nteczone.com> <53EA476A.7050506@alum.mit.edu> <53EACE16.7090807@nteczone.com> <53EBBA52.7050306@alum.mit.edu> In-Reply-To: <53EBBA52.7050306@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YxNG3FCoIAfDysGsXDcyAFrpTlY Subject: Re: [clue] Implications of draft-ietf-rtcweb-alpn-00 c-webrtc X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Aug 2014 00:39:14 -0000 Hello Paul, Please see below. Regards, Christian On 14/08/2014 5:19 AM, Paul Kyzivat wrote: > On 8/12/14 10:31 PM, Christian Groves wrote: >> Please see my comments below. >> >> Regards, Christian >> >> On 13/08/2014 6:53 AM, Mary Barnes wrote: >>> >>> >>> >>> On Tue, Aug 12, 2014 at 11:57 AM, Paul Kyzivat >> > wrote: >>> >>> On 8/11/14 9:08 PM, Christian Groves wrote: >>> >>> Hello Paul, >>> >>> I guess this relates to your comments about data channel being >>> a general >>> purpose mechanism and not a "webRTC" specific one. I think its >>> fair for >>> a WebRTC device/browser only using data channels to assert an >>> ALPN with >>> "webrtc" or "c-webrtc". But if there's a non-webrtc device >>> e.g. a CLUE >>> endpoint using data channel is that still really "webrtc"? >>> >>> >>> I think we need to distinguish between the behavior and the name >>> that is attached to the behavior. >>> >>> We want some of the behavior specified in webrtc and rtcweb specs, >>> for multiple reasons. In some cases we want it in order to enable >>> interoperation with devices that are constrained by webrtc. We >>> also want some features that happen to have been defined as part >>> of webrtc, without regard to interoperation with webrtc. And >>> further, if we need to behave one way when interoperating, then it >>> is convenient to specify that we will also operate that way when >>> not interoperating, just to keep things simple. >>> >> [CNG] I agree that we need some behaviour. I'm generally not fussed with >> names. In behaviour terms it seems strange to offer an ALPN that >> indicates the behaviour of "webrtc- the DTLS session is used to >> establish keys for a Secure Real-time Transport Protocol (SRTP) - known >> as DTLS-SRTP - as described in [RFC5764]." when for CLUE usage (outside >> WebRTC) the use of SRTP is not the case. > > AFAIK we do allow clue captures to share to be bundled with the SCTP. > I can imagine that some implementations will prefer to do it that way. > And the use of the ALPN for one DTLS session says nothing about what > happens on other unbundled m-lines. > > Note what else ALPN is used to denote - HTTP vs SPDY. Those aren't > applications either. > > AFAICT, the behavior being negotiated is behavior that can/should be > the same between clue and webrtc. [CNG] CLUE only requires the use of data channel. It can be used by WebRTC devices and any other sort of devices. These devices can use bundling, RTP, SRTP etc. The part that is problematic for me is that the APLN indicates the DTLS is used for SRTP. For many devices where CLUE is used this will not be the case. > > I don't like the name, but neither do I want to invent another name > and have two different behaviors. > >>> To achieve those things, we end up needing to use some of the >>> names for things that webrtc is choosing. My *preference* is to >>> convince them to use generic (non-webrtc-specific) names for >>> things that have broader applicability. But if we loose those >>> battles then so be it - they are just names, even if stupid ones. >>> Using them doesn't prevent us for doing what we need to do. It >>> just presents an additional documentation challenge. >>> >> [CNG] Preferably it would be good to use just "data channel" for the >> name. > > I have proposed using data-channel instead of webrtc-datachannel on > the m-line for sctp. > > But data-channel seems wrong here because it is about more than that - > about SRTP as well. [CNG] Yes that's why I think there needs to be a separate value for data-channel where SRTP is not involved. > >> I think it could easily be solved by adding an ALPN just for data >> channel: >> datcha: The DTLS record layer is used for WebRTC data channels >> [I-D.ietf-rtcweb-data-channel]. > > Then that would presumably forbid bundling media with it. Why would we > want to forbid that? [CNG] If you want to bundle media and use SRTP then use the ALPN "webrtc". If you only want to use a data channel and transmit media via another connection use "datachannel". > >>> While we could conceivably use different names depending on >>> context, that is likely to just make things more complex. >>> >>> Somebody did suggest that as a client we could offer alternative >>> alpn values, and let the server choose one. So we could offer both >>> "clue" and "webrtc", and be happy with either of them being >>> accepted. And we could act exactly the same in both cases. But >>> that buys us the obligation to define what it means when the >>> "clue" alpn is used. That is extra work for us. >>> >>> [MB] As an individual, I don't see CLUE defining another alpn value to >>> be a negative. I think it adds clarity and can help us avoid >>> confusion. Documenting what it means when "clue" alpn is used is a >>> good thing IMHO, as we really should describe how alpn works for CLUE >>> regardless of the alpn value.[/MB] >> [CNG] I think we need to take a step back on this and look from the >> general case. The ALPN mechanism allows the specification of multiple >> protocols and the selection of one. > > Yes. Unfortunately it seems to not be very clear about what it means > to select one or another. Exactly what is it that you are selecting? > >> An endpoint could advertise "webrtc" >> and "clue" but does the selection of "webrtc" really indicate CLUE >> support? > > Why should it? We have other mechanisms to indicate clue support. For > this to be used with clue the m-line needs to be in the clue group. [CNG] I agree. That's why I don't think adding a "CLUE" ALPN is going to help. > >> What happens if the endpoint uses data channel for multiple >> protocols i.e. CLUE and BFCP? The server chooses one, so how does it >> indicate CLUE AND BFCP? > > This just further points out the confusion about what an ALPN does and > doesn't name. And it should be possible for a webrtc browser to be a > clue client and use the SCTP association for both a clue channel and a > bfcp channel. > > I guess it would be clearer if we were just trying to negotiate what > DTLS payload is being used for. The answer to that is SCTP. But that > is already known from the SDP. I suspect this ALPN thing may be an > artifact for cases where there is no SDP negotiation. [CNG] I agree. > >> It could use an ALPN for datachannel but that's >> not being defined. With the current values the server would have to >> choose webrtc. Implying support of SRTP when its not actually used. Its >> going to get messy when specifying multiple "application" protocols. > > I have run out of things to say. > > Thanks, > Paul > >>> Thanks, >>> Paul >>> >>> >>> Regards, Christian >>> >>> On 8/08/2014 12:26 PM, Paul Kyzivat wrote: >>> >>> On 8/7/14 9:15 PM, Christian Groves wrote: >>> >>> Hello Paul, >>> >>> As I've raised on the WebRTC list its not clear to me >>> that either an >>> alpn of webrtc or c-webrtc is correct for CLUE as the >>> definition of >>> these indicates the presence webrtc media and >>> datachannel. CLUE may be >>> used in environments where WebRTC controlled media is >>> NOT used. Sending >>> an alpn with 'webrtc' for a datachannel only case >>> doesn't seem correct. >>> >>> >>> That argument applies equally to webrtc itself. There will >>> no doubt be >>> webrtc applications that only use the data channels, not >>> the media >>> streams. >>> >>> Note that I did post a query to the rtcweb list asking >>> about use of >>> other ALPN ids with WebRTC. >>> >>> Thanks, >>> Paul >>> >>> Christian >>> >>> On 8/08/2014 7:08 AM, Paul Kyzivat wrote: >>> >>> CLUE people should review >>> draft-ietf-rtcweb-alpn-00. It has some >>> implications for us. >>> >>> It defines some two specific ALPN protocol names >>> for use with webrtc. >>> These are used during DTLS initialization, and >>> identify the >>> application layer protocol running on top of DTLS. >>> >>> If we are to be interoperable with webrtc, then it >>> seems clue >>> implementations will be required to follow this >>> draft. >>> >>> The two ALPN names defined are: >>> - webrtc >>> - c-webrtc >>> >>> The value "c-webrtc" is used when "confidential" >>> media streams are >>> being conveyed. IIUC this is mostly a browser >>> issue. The draft says: >>> >>> Private communications in WebRTC depend on >>> separating control (i.e., >>> signaling) capabilities and access to media >>> [I-D.ietf-rtcweb-security-arch]. In this way, >>> an application can >>> establish a session that is end-to-end >>> confidential, where the ends >>> in question are user agents (or browsers) and >>> not the signaling >>> application. >>> >>> A browser is required to enforce this control >>> using isolation >>> controls similar to those used in cross-origin >>> protections. These >>> protections ensure that media is protected from >>> applications. >>> Applications are not able to read or modify the >>> contents of a >>> protected flow of media. Media that is >>> produced from a session >>> using >>> the "c-webrtc" identifier MUST only be >>> displayed to users. >>> ... >>> RTP middleboxes and entities that forward media >>> or data cannot >>> promise to maintain confidentiality. Any >>> entity that forwards >>> content, or records content for later access by >>> entities other than >>> the authenticated peer, MUST NOT offer or >>> accept a session with the >>> "c-webrtc" identifier. >>> >>> I don't know how to interpret this in the CLUE >>> context. >>> >>> The simple answer would be to only define CLUE for >>> use with "webrtc" >>> as the ALPN, and leave support of "c-webrtc" >>> undefined for now. >>> >>> Or possibly we should not discuss the ALPN at all. >>> But I fear that >>> will lead to interop problems. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Aug 26 16:49:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9695A1A017A; Tue, 26 Aug 2014 16:49:41 -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] autolearn=ham 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 K7hdCX5iPFU3; Tue, 26 Aug 2014 16:49:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FBD1A00AA; Tue, 26 Aug 2014 16:49:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p5 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140826234940.8102.90014.idtracker@ietfa.amsl.com> Date: Tue, 26 Aug 2014 16:49:40 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1pqwV8qnn9mBoCh0llom8281D04 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 23:49:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-03.txt Pages : 32 Date : 2014-08-26 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.presta-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-signaling-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Aug 26 16:54:18 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 852E81A01EB for ; Tue, 26 Aug 2014 16:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 kbRXqKoRKQih for ; Tue, 26 Aug 2014 16:54:13 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF1DB1A00E0 for ; Tue, 26 Aug 2014 16:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2100; q=dns/txt; s=iport; t=1409097253; x=1410306853; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=jd6HLWDQxC1zv9RhOx1n8lcZSD9mGPZ3jMCl8dARyxU=; b=eNJofZ6oVokN+5R23ZZvqrl5TXzxwWFaSmFBJVsFwIKlzsfCpNzf5zBh yJRVBXh5Ti78G6wbpW86CORhxOg72ORghE+THXAGLhdflLmnuP3S4k6u0 UWnMbBiGvvHOJzrM75Q8reUNTOnCM4eLE8sCLt556W4il+QYJNX9LpzL6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAYd/VOtJV2P/2dsb2JhbABbgw1TUwQEzFAKh0wBgRIWd4QDAQEBBAEBATc0FwQCAQgRBAEBCxQJBycLFAkIAgQTCAGIOQgFv08Xjxs4BoMpgR0FkS2EK4hUkzyDXmyBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,407,1406592000"; d="scan'208";a="350552917" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP; 26 Aug 2014 23:54:13 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id s7QNsAJO020474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 26 Aug 2014 23:54:12 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.136]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 26 Aug 2014 18:54:10 -0500 From: "Robert Hansen (rohanse2)" To: "clue@ietf.org" Thread-Topic: [clue] I-D Action: draft-ietf-clue-signaling-03.txt Thread-Index: AQHPwYhp5Ma+RBshOkOUv4Y9C7WU35vjjkRg Date: Tue, 26 Aug 2014 23:54:10 +0000 Message-ID: References: <20140826234940.8102.90014.idtracker@ietfa.amsl.com> In-Reply-To: <20140826234940.8102.90014.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.193] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/PWu8hhQA7us7ZsRl1n7vpa0vaEA Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Aug 2014 23:54:17 -0000 This was mostly an update to go through the examples and make sure all the = syntax and behaviour was up-to-date and add more detail. I also corrected s= ome issues Paul identified with the previous draft, and corrected a few lan= guage issues. See the change history for a few more details. Rob=20 -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet-drafts@ietf= .org Sent: 27 August 2014 00:50 To: i-d-announce@ietf.org Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : CLUE Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-03.txt Pages : 32 Date : 2014-08-26 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.presta-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-signaling-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-signaling-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed Aug 27 01:22:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469E11A04AC for ; Wed, 27 Aug 2014 01:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.3 X-Spam-Level: X-Spam-Status: No, score=0.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_BACKHAIR_41=1, J_CHICKENPOX_18=0.6, J_CHICKENPOX_34=0.6] autolearn=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 2_Kk7nHkJ5nQ for ; Wed, 27 Aug 2014 01:22:33 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D79B51A04AB for ; Wed, 27 Aug 2014 01:22:32 -0700 (PDT) Received: from ppp118-209-27-161.lns20.mel4.internode.on.net ([118.209.27.161]:56448 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XMYTK-0001Pa-My for clue@ietf.org; Wed, 27 Aug 2014 18:20:50 +1000 Message-ID: <53FD9542.70403@nteczone.com> Date: Wed, 27 Aug 2014 18:22:26 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140826234940.8102.90014.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/9DCG0BznZ658TnrYDlwEmnjxrWA Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Aug 2014 08:22:34 -0000 Hello Rob, Thanks for the update. A few comments: Cl.4.3 - ID.presta-clue-protocol can be updated to draft-ietf-clue-protocol-01 Cl.4.4.1 - Indicates that STUN/DTLS must be sent if negotiated and on a CONFIGURE media packets are sent. Do we need to say that if the Configure doesn't select the encoding then any STUN/security associations are removed? or? Also I take packets aren't sent until the CONFIGURE message is received AND the SDP is updated to a=sendonly? In the paragraphs above it indicates that sendonly or inactive may be sent. I guess this also relates to cl.5.2. Cl.4.4.1.1 - "...SHOULD represent<> an encoding..." in two places Cl.5.1 Paragraph 1 - "/likewise the implementation's ability to send a new CLUE// // ADVERTISEMENT or CONFIGURE message is not restricted by the results// // of or the state of the most recent SDP negotiation./" That's not strictly true. The SDP negotiation may have removed the data channel in which case the endpoint can't use CLUE messages. Cl.5.1 Paragraph 2 - "An implementation that is" Seems to be an incomplete sentence. Cl.5.1 Para.3 - "...NOT reject a CLUE protocol message<> soley because it contains element that do not match a