IETF Logo Mail Archive

Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)

Adam Roach <adam@nostrum.com> Thu, 16 April 2015 18:29 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dispatch@ietfa.amsl.com
Delivered-To: dispatch@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE02F1B3437 for <dispatch@ietfa.amsl.com>; Thu, 16 Apr 2015 11:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 PiXcWBSKT8FV for <dispatch@ietfa.amsl.com>; Thu, 16 Apr 2015 11:29:54 -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 8E2811B3434 for <dispatch@ietf.org>; Thu, 16 Apr 2015 11:29:42 -0700 (PDT)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3GITcIR064392 (version=TLSv1.2 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2015 13:29:40 -0500 (CDT) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
Message-ID: <552FFF92.9040709@nostrum.com>
Date: Thu, 16 Apr 2015 13:29:38 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, dispatch@ietf.org
References: <55134454.9050302@ericsson.com> <DF642B61-47ED-4F33-BE7F-3F70FF80B294@nostrum.com> <5527E01F.9040507@nostrum.com> <552B7F5C.9060107@ericsson.com> <552C5F01.3090207@nteczone.com> <552D1D5E.1090504@alum.mit.edu> <552FF93F.4000107@nostrum.com> <552FFE3C.80104@alum.mit.edu>
In-Reply-To: <552FFE3C.80104@alum.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dispatch/HnwzCmv57I74Est_huzlriUTc4c>
Subject: Re: [dispatch] Proposal for a new WG: Privacy Enhanced RTP Conferencing (PERC)
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch/>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Apr 2015 18:29:56 -0000

On 4/16/15 13:23, Paul Kyzivat wrote:
> The advertisements are send over a data channel.

Is this like a "data channel" in the same sense that WebRTC uses that 
term? If so, I think there are some good ways to handle this in line 
with PERC's goals (there are reasonable ways to ensure that the data 
channels terminate at the trusted key management node rather than the 
mixer).

/a

v2.23.0 | Report a Bug | By Email