Hi all,

Below, please find an updated charter for PERC.=C2=A0 Magnus ha= s updated the charter to incorporate feedback from the DISPATCH WG mailing = list discussions and we've made a round of editorial changes.=C2=A0 It = should be ready for Ben to submit to the IESG for consideration as a new WG= .=C2=A0 So, please review and provide any final comments no later than 18:0= 0 GMT on Monday, May 25th (and yeah, I know it's a US holiday but folks= in the US have the rest of today to review and there really should be no s= urprises;)=C2=A0

Regards= ,

Mary

DISPATCH WG co-chair

=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Name: Privacy Enhance= d RTP Conferencing (PERC)

Area: ART

Chairs: TBD

Mailing List: <using disp= atch@ietf.org for now>

Motivation for new WG

RTP-based real-time= multi-party interactive media conferencing is in widespread use today. Man= y of the deployments use one or more centrally located media distribution d= evices that perform selective forwarding of mixed-media streams received fr= om the participating endpoints. The media transport protocol commonly used = is RTP (RFC3550). There are various signaling systems used to establish the= se multi-party conferences.

These conferences require security to= ensure that the RTP media and related metadata of the conference is kept p= rivate and only available to the set of invited participants and other devi= ces trusted by those participants with their media.=C2=A0 At the same time,= multi-party media conferences need source authentication and integrity che= cks to protect against modifications, insertions, and replay attacks.=C2=A0= Media distribution devices supporting these conferences may also perform R= TP header changes, and they often consume and create RTCP messages for effi= cient media handling.

To date, deployment models for these multi-pa= rty media distribution devices do not enable the devices to perform their f= unctions without having keys to decrypt the participants=E2=80=99 media, pr= imarily using Secure RTP (RFC3711) to provide session security.

This tru= st model has limitations and prevents or hampers deployment of secure RTP c= onferencing in a multitude of cases, including outsourcing, legal requireme= nts on confidentiality, and utilization of virtualized servers. Thus, a new= architectural model and related specifications are needed, with a focused = effort from the RTP and Security communities.

WG Objectives

<= p dir=3D"ltr" style=3D"line-height:1.38;margin-top:0pt;margin-bottom:0pt"><= span style=3D"font-size:15px;font-family:Arial;color:rgb(0,0,0);vertical-al= ign:baseline;white-space:pre-wrap;background-color:transparent">This WG wil= l work on a solution that enables centralized SRTP-based conferencing, wher= e the central device distributing the media is not required to be trusted w= ith the keys to decrypt the participants=E2=80=99 media. The media must be = kept confidential and authenticated between an originating endpoint and the= explicitly allowed receiving endpoints or other devices.=C2=A0 Further, it= is desired that a solution still provides replay protection, so that the m= edia distribution devices can=E2=80=99t replay previous parts of the media.=

The solution must also provide security for each hop between endpoints a= nd multi-party media distribution devices and between multi-party media dis= tribution devices. The RTCP messages and RTP header extensions required for= the media distribution device to perform the selective media forwarding ma= y require both source authentication and integrity as well as confidentiali= ty. The solution may also consider providing end-to-end security for a subs= et of the RTCP messages or RTP header extensions.

The solution should b= e implementable by both SIP (RFC3261) and WebRTC (draft-ietf-rtcweb-overview) endpoints. How telepresence endpoint= s using the protocols defined in the CLUE working group could utilize the d= efined security solution needs to be considered. However, it is acknowledge= d that limitations may exist, resulting in restricted functionality or need= for additional adaptations of the CLUE protocols.

This working group = will perform the following work:

1. =C2=A0=C2=A0=C2=A0Define= a general architecture and RTP topology(s) that enables end-to-end media s= ecurity for multi-party RTP conferencing.

2. =C2=A0=C2=A0=C2= =A0= Define the trust model and describe the resulting security properties.

3.=C2=A0 Document models considered for integrating the soluti= on with WebRTC, SIP and CLUE establishment of conferencing sessions.=

4. =C2=A0=C2=A0=C2=A0Specify any necessary extensions to SRTP.

5. =C2=A0=C2=A0Define needed Key Management Functions that distribute the= keys. The system needs to be able to bind the media to the sender of the m= edia=E2=80=99s identity and/or the identity of the conference.

Collabora= tion

If there is identification of missing protocols or functionalities, = such work can be requested to be done in another working group with a suita= ble charter or by requests for chartering it in this WG or another WG. Pote= ntial items that might require work in other WGs are DTLS extensions (TLS W= G) and RTP header extensions (AVTEXT WG). This work requires strong collabo= ration with the security area. We will notify AVTCore, CLUE, MMUSIC, RTCWEB= , SIPREC, W3C WebRTC, and other related groups about this work.

Non-Goal= s

The PERC working group is not chartered to extend any signaling system = used to establish the RTP-based conferences. It will, however, need to cons= ider in its architecture how the solution may integrate with these systems,= and document such consideration for WebRTC, SIP, and CLUE. The specificati= on of how a particular system integrates the security solution will happen = outside of this working group, in suitable venues.

The WG will not con= sider non-real-time usage, multicast-based media distribution, or Security = descriptions-based keying (RFC4568).

Goals and Milestones

=C2=A0

TBD = =C2=A0Submit architecture or framework specification to IESG (Standards Tra= ck)

TBD Submit documentation of how to integrate solution in SIP, WebRT= C and CLUE to IESG (Informational)

TBD =C2=A0Submit SRTP protocol extensi= on specification to IESG (Standards Track)

TBD =C2=A0Submit Key-managem= ent protocol specification to IESG (Standards Track)

Input to the WG=

Proposals already existing relating to this charter proposal:

https://datatracker.ietf.org= /doc/draft-jones-avtcore-private-media-reqts/
https://datatracker.ietf.org/doc/draf= t-jones-avtcore-private-media-framework/
https://datatracker.ietf.org/doc/draft-cheng-avtcore-sr= tp-cloud/

--001a11c3b43427b0a40516ada40e-- From nobody Fri May 22 09:16:22 2015 Return-Path: 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 29FC31A6EE6 for ; Fri, 22 May 2015 09:16:21 -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 TcmlySHmx4W2 for ; Fri, 22 May 2015 09:16:19 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6C61A6F20 for ; Fri, 22 May 2015 09:16:16 -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 t4MGG9dt083562 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 22 May 2015 11:16:10 -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: <555F5649.7020706@nostrum.com> Date: Fri, 22 May 2015 11:16:09 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mary Barnes , DISPATCH References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Ben Campbell , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 16:16:21 -0000 On 5/22/15 10:52, Mary Barnes wrote: > Monday, May 25th (and yeah, I know it's a US holiday but folks in the > US have the rest of today to review and there really should be no > surprises;) FWIW, it's also a holiday in many European countries (cf. ). /a From nobody Fri May 22 13:22:54 2015 Return-Path: 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 20F151A87CD for ; Fri, 22 May 2015 13:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 w7vGu7wmhiVd for ; Fri, 22 May 2015 13:22:51 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7526B1A87D4 for ; Fri, 22 May 2015 13:22:48 -0700 (PDT) Received: by lbbuc2 with SMTP id uc2so20231150lbb.2 for ; Fri, 22 May 2015 13:22:47 -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=EJOtKrI9Sq/rwfRGS/iqtCW7mW6Bjtmqln8vnvlD0Dk=; b=Z0XMQ5GEMsHlrGm4Lnb+shz90qF2TJOkRHrbdQT8/z0IL+HpAfL8R85j4F9Uay4l4j lVqHs5bxUJ1H9uYIX278mAgdMUIk7XkABA+IFOIn9LqQAOS0jkh7f8eeZ+RYUiR2OqWV glb7+TNhrZSuCEWy+94K+MFidPPASB25A/WZ3RruN/JwBrjccr33MYxggbM3fLe6vZfW e0TYeqcCtx2yRZYSbr6ihbcnJm6KWI/Uo7wzvlrfpslQzAnL+3jTEJO+T+Ji1v7Aoo7A ykazk/x3mOA0ljVZDj9VUOIoO5UTp132lCrgNQEfaJslw4lAhjvqwFEJBfIrMSQ3Lz+g tR2w== MIME-Version: 1.0 X-Received: by 10.112.35.230 with SMTP id l6mr7804430lbj.5.1432326166978; Fri, 22 May 2015 13:22:46 -0700 (PDT) Received: by 10.25.128.207 with HTTP; Fri, 22 May 2015 13:22:46 -0700 (PDT) Date: Fri, 22 May 2015 15:22:46 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a11c3787662a77b0516b16c7b Archived-At: Cc: Cullen Jennings , Ben Campbell Subject: [dispatch] Reminder: DISPATCH WG IETF-93 Deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2015 20:22:53 -0000 --001a11c3787662a77b0516b16c7b Content-Type: text/plain; charset=UTF-8 Hi all, June is fast approaching as are the deadlines for IETF-93: http://trac.tools.ietf.org/wg/dispatch/trac/wiki - June 8, 2015. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. - June 15, 2015. Cutoff for charter proposals for topics. - June 22, 2015. Announcement of topics that have been dispatched for IETF-93. - July 6, 2015. Draft deadline. Regards, Mary DISPATCH WG co-chair --001a11c3787662a77b0516b16c7b Content-Type: text/html; charset=UTF-8

Hi all,

June is fast approaching as are the deadlines for IETF-93:

http://trac.tools.ietf.org/wg/dispatch/trac/wiki

June 8, 2015. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal.

June 15, 2015. Cutoff for charter proposals for topics.

June 22, 2015. Announcement of topics that have been dispatched for IETF-93.

July 6, 2015. Draft deadline.

Regards,

Mary

DISPATCH WG co-chair

--001a11c3787662a77b0516b16c7b-- From nobody Sat May 23 00:28:01 2015 Return-Path: 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 590691A92B7 for ; Sat, 23 May 2015 00:27:59 -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 ouU2-EdEpdpo for ; Sat, 23 May 2015 00:27:56 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FF61A92B8 for ; Sat, 23 May 2015 00:27:55 -0700 (PDT) Received: by wicmx19 with SMTP id mx19so7143788wic.0 for ; Sat, 23 May 2015 00:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=M+PtMMe7bUhLSxsmvXD5RlIsqVFsGCWacHQOeiJ0T0A=; b=KFzg0oSWNSlGZQjrze3ktMW4Z5aEHKdvtuaPZAs+Md9nkfUqFH2b6SvktnJNCpRmrW GCK5x7hvHBRqts85xS2it/IlL+mnbaSHcSuLhQHRhLLmrZ+gn2lSAh3gAKODAIQvGPKw 7uTOZ0/Z0qG1rBXEG6cgcp/J5jRx3Rj3humaItwlUJ8UtUxtFxIysal20jfjkKmcs72j tP7ucsCfsuaBDw3ykDm1n5i2ERxi5LVoZGPQ9PJGqsO0jjLbQmCLBG8Zoe7yuxOjcboQ qOlGDGNHmnvkIjmCPixXLboStv88gew72Ox2bqSpK0pRGYOILSXKyBu2Ae+JIX8JUuVS qGgQ== X-Received: by 10.194.11.73 with SMTP id o9mr22302854wjb.116.1432366074176; Sat, 23 May 2015 00:27:54 -0700 (PDT) Received: from RoniE ([109.65.144.138]) by mx.google.com with ESMTPSA id be3sm1693707wib.21.2015.05.23.00.27.50 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 23 May 2015 00:27:52 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'DISPATCH'" References: In-Reply-To: Date: Sat, 23 May 2015 10:27:41 +0300 Message-ID: <03a201d09529$f606e870$e214b950$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03A3_01D09543.1B55CE20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMeczP7p56zGI9386mjnB7ayVQMqZrtax9A Content-Language: en-us Archived-At: Cc: 'Ben Campbell' , 'Barry Leiba' Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 07:27:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03A3_01D09543.1B55CE20 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, The charter looks good to me, =20 One comment about the milestone, the first milestone is for architecture = while the first bullet in the work to be done also mentions the RTP = topologies, so I assume that the first milestone also includes new RTP = topologies or will the RTP topologies to be used will only be topologies = from draft-ietf-avtcore-rtp-topologies-update-07 = = ? =20 Roni Even =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary = Barnes Sent: 22 May, 2015 6:52 PM To: DISPATCH Cc: Barry Leiba; Ben Campbell Subject: [dispatch] Updated PERC Charter proposal =20 Hi all, =20 Below, please find an updated charter for PERC. Magnus has updated the = charter to incorporate feedback from the DISPATCH WG mailing list = discussions and we've made a round of editorial changes. It should be = ready for Ben to submit to the IESG for consideration as a new WG. So, = please review and provide any final comments no later than 18:00 GMT on = Monday, May 25th (and yeah, I know it's a US holiday but folks in the US = have the rest of today to review and there really should be no = surprises;)=20 =20 Regards, Mary DISPATCH WG co-chair =20 =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 =20 =20 Name: Privacy Enhanced RTP Conferencing (PERC) Area: ART Chairs: TBD Mailing List: dispatch@ietf.org for = now>=20 =20 Motivation for new WG RTP-based real-time multi-party interactive media conferencing is in = widespread use today. Many of the deployments use one or more centrally = located media distribution devices that perform selective forwarding of = mixed-media streams received from the participating endpoints. The media = transport protocol commonly used is RTP (RFC3550). There are various = signaling systems used to establish these multi-party conferences. These conferences require security to ensure that the RTP media and = related metadata of the conference is kept private and only available to = the set of invited participants and other devices trusted by those = participants with their media. At the same time, multi-party media = conferences need source authentication and integrity checks to protect = against modifications, insertions, and replay attacks. Media = distribution devices supporting these conferences may also perform RTP = header changes, and they often consume and create RTCP messages for = efficient media handling. =20 To date, deployment models for these multi-party media distribution = devices do not enable the devices to perform their functions without = having keys to decrypt the participants=E2=80=99 media, primarily using = Secure RTP (RFC3711) to provide session security.=20 This trust model has limitations and prevents or hampers deployment of = secure RTP conferencing in a multitude of cases, including outsourcing, = legal requirements on confidentiality, and utilization of virtualized = servers. Thus, a new architectural model and related specifications are = needed, with a focused effort from the RTP and Security communities. WG Objectives This WG will work on a solution that enables centralized SRTP-based = conferencing, where the central device distributing the media is not = required to be trusted with the keys to decrypt the = participants=E2=80=99 media. The media must be kept confidential and = authenticated between an originating endpoint and the explicitly allowed = receiving endpoints or other devices. Further, it is desired that a = solution still provides replay protection, so that the media = distribution devices can=E2=80=99t replay previous parts of the media. The solution must also provide security for each hop between endpoints = and multi-party media distribution devices and between multi-party media = distribution devices. The RTCP messages and RTP header extensions = required for the media distribution device to perform the selective = media forwarding may require both source authentication and integrity as = well as confidentiality. The solution may also consider providing = end-to-end security for a subset of the RTCP messages or RTP header = extensions. =20 The solution should be implementable by both SIP (RFC3261) and WebRTC ( = = draft-ietf-rtcweb-overview) endpoints. How telepresence endpoints using = the protocols defined in the CLUE working group could utilize the = defined security solution needs to be considered. However, it is = acknowledged that limitations may exist, resulting in restricted = functionality or need for additional adaptations of the CLUE protocols.=20 =20 This working group will perform the following work: 1. Define a general architecture and RTP topology(s) that enables = end-to-end media security for multi-party RTP conferencing. 2. Define the trust model and describe the resulting security = properties. 3. Document models considered for integrating the solution with WebRTC, = SIP and CLUE establishment of conferencing sessions. 4. Specify any necessary extensions to SRTP. 5. Define needed Key Management Functions that distribute the keys. = The system needs to be able to bind the media to the sender of the = media=E2=80=99s identity and/or the identity of the conference.=20 Collaboration If there is identification of missing protocols or functionalities, such = work can be requested to be done in another working group with a = suitable charter or by requests for chartering it in this WG or another = WG. Potential items that might require work in other WGs are DTLS = extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work = requires strong collaboration with the security area. We will notify = AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related = groups about this work.=20 Non-Goals The PERC working group is not chartered to extend any signaling system = used to establish the RTP-based conferences. It will, however, need to = consider in its architecture how the solution may integrate with these = systems, and document such consideration for WebRTC, SIP, and CLUE. The = specification of how a particular system integrates the security = solution will happen outside of this working group, in suitable venues.=20 =20 The WG will not consider non-real-time usage, multicast-based media = distribution, or Security descriptions-based keying (RFC4568). =20 Goals and Milestones =20 TBD Submit architecture or framework specification to IESG (Standards = Track) =20 TBD Submit documentation of how to integrate solution in SIP, WebRTC and = CLUE to IESG (Informational) TBD Submit SRTP protocol extension specification to IESG (Standards = Track) =20 TBD Submit Key-management protocol specification to IESG (Standards = Track) =20 Input to the WG =20 Proposals already existing relating to this charter proposal: =20 = = https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/= = = https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framew= ork/ = https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ =20 ------=_NextPart_000_03A3_01D09543.1B55CE20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi,

The charter looks good to me,

One comment about the milestone, the first milestone is for = architecture while the first bullet in the work to be done also mentions = the RTP topologies, so I assume that the first milestone also includes = new RTP topologies or will the RTP topologies to be used will only be = topologies from draft-ietf-avtcore-rtp-topologies-update-07 = ?

Roni Even

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 22 May, 2015 6:52 PM
To: = DISPATCH
Cc: Barry Leiba; Ben Campbell
Subject: = [dispatch] Updated PERC Charter = proposal

Hi = all,

Below, please find an updated charter for PERC. = Magnus has updated the charter to incorporate feedback from the DISPATCH = WG mailing list discussions and we've made a round of editorial = changes. It should be ready for Ben to submit to the IESG for = consideration as a new WG. So, please review and provide any final = comments no later than 18:00 GMT on Monday, May 25th (and yeah, I know = it's a US holiday but folks in the US have the rest of today to review = and there really should be no = surprises;)

Regards,

Mary

DISPATCH WG co-chair

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

N= ame: Privacy Enhanced RTP Conferencing (PERC)

A= rea: ART

C= hairs: TBD

M= ailing List: <using dispatch@ietf= .org = for now>

M= otivation for new WG

R= TP-based real-time multi-party interactive media conferencing is in = widespread use today. Many of the deployments use one or more centrally = located media distribution devices that perform selective forwarding of = mixed-media streams received from the participating endpoints. The media = transport protocol commonly used is RTP (RFC3550). There are various = signaling systems used to establish these multi-party = conferences.

T= hese conferences require security to ensure that the RTP media and = related metadata of the conference is kept private and only available to = the set of invited participants and other devices trusted by those = participants with their media. At the same time, multi-party media = conferences need source authentication and integrity checks to protect = against modifications, insertions, and replay attacks. Media = distribution devices supporting these conferences may also perform RTP = header changes, and they often consume and create RTCP messages for = efficient media handling.

T= o date, deployment models for these multi-party media distribution = devices do not enable the devices to perform their functions without = having keys to decrypt the participants=E2=80=99 media, primarily using = Secure RTP (RFC3711) to provide session security. =

T= his trust model has limitations and prevents or hampers deployment of = secure RTP conferencing in a multitude of cases, including outsourcing, = legal requirements on confidentiality, and utilization of virtualized = servers. Thus, a new architectural model and related specifications are = needed, with a focused effort from the RTP and Security = communities.

W= G Objectives

T= his WG will work on a solution that enables centralized SRTP-based = conferencing, where the central device distributing the media is not = required to be trusted with the keys to decrypt the = participants=E2=80=99 media. The media must be kept confidential and = authenticated between an originating endpoint and the explicitly allowed = receiving endpoints or other devices. Further, it is desired that = a solution still provides replay protection, so that the media = distribution devices can=E2=80=99t replay previous parts of the = media.

T= he solution must also provide security for each hop between endpoints = and multi-party media distribution devices and between multi-party media = distribution devices. The RTCP messages and RTP header extensions = required for the media distribution device to perform the selective = media forwarding may require both source authentication and integrity as = well as confidentiality. The solution may also consider providing = end-to-end security for a subset of the RTCP messages or RTP header = extensions.

T= he solution should be implementable by both SIP (RFC3261) and WebRTC = (draft-ietf-rt= cweb-overview)= endpoints. How telepresence endpoints using the protocols defined in = the CLUE working group could utilize the defined security solution needs = to be considered. However, it is acknowledged that limitations may = exist, resulting in restricted functionality or need for additional = adaptations of the CLUE protocols.

T= his working group will perform the following = work:

1= . = D= efine a general architecture and RTP topology(s) that enables end-to-end = media security for multi-party RTP conferencing.

2= . = D= efine the trust model and describe the resulting security = properties.

3= . Document models considered for integrating the solution with = WebRTC, SIP and CLUE establishment of conferencing = sessions.

4= . = S= pecify any necessary extensions to SRTP.

5= . = D= efine needed Key Management Functions that distribute the keys. The = system needs to be able to bind the media to the sender of the = media=E2=80=99s identity and/or the identity of the conference. =

C= ollaboration

I= f there is identification of missing protocols or functionalities, such = work can be requested to be done in another working group with a = suitable charter or by requests for chartering it in this WG or another = WG. Potential items that might require work in other WGs are DTLS = extensions (TLS WG) and RTP header extensions (AVTEXT WG). This work = requires strong collaboration with the security area. We will notify = AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related = groups about this work.

N= on-Goals

T= he PERC working group is not chartered to extend any signaling system = used to establish the RTP-based conferences. It will, however, need to = consider in its architecture how the solution may integrate with these = systems, and document such consideration for WebRTC, SIP, and CLUE. The = specification of how a particular system integrates the security = solution will happen outside of this working group, in suitable venues. =

T= he WG will not consider non-real-time usage, multicast-based media = distribution, or Security descriptions-based keying = (RFC4568).

G= oals and Milestones

&= nbsp;

T= BD Submit architecture or framework specification to IESG = (Standards Track)

T= BD Submit documentation of how to integrate solution in SIP, WebRTC and = CLUE to IESG (Informational)

T= BD Submit SRTP protocol extension specification to IESG (Standards = Track)

T= BD Submit Key-management protocol specification to IESG (Standards = Track)

I= nput to the WG

P= roposals already existing relating to this charter = proposal:

https://datat= racker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/
https://datat= racker.ietf.org/doc/draft-jones-avtcore-private-media-framework/
https://datat= racker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/

------=_NextPart_000_03A3_01D09543.1B55CE20-- From nobody Sat May 23 09:09:57 2015 Return-Path: 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 2D4621A038F for ; Sat, 23 May 2015 09:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 dW6NkAcfBVQ4 for ; Sat, 23 May 2015 09:09:52 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C84E1A01F0 for ; Sat, 23 May 2015 09:09:51 -0700 (PDT) Received: by lagv1 with SMTP id v1so29225745lag.3 for ; Sat, 23 May 2015 09:09:49 -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=JLavyz6fZhOQ1VmLlWQnzv9LZujiEmgCBJIz3VrEaTQ=; b=JNEisoPyM9M7zh+Z7HSHboYZHNoc7vSekszbHDN6Mk/RI9VN/6/iuM1IgPtX8xL/bZ ury/DA9vqUeOXwDEBcC6BhrU0a2t7n/RUtqVrWsp55QNZHfBlCKK85Ot7pSbzxik6hRA cNNY6Kg6M3wRQuPd1l7aK48ERk70niRWm9iakWElclLHruaXISFjiMV71zxWnqdP5xoK nLjo+Ht+4Nx4wONGRKV+cT3wH24cgy1+yuzcaF/Qos0Ah3fdSw0t2hFiznFEkhFBreVH 1lwOuhL6LnTary26GJq0sTqQjVOBDZeAWMkG9n7IJYbCV3vm4lYuBhseM5hIJbxh2RYG nHdg== MIME-Version: 1.0 X-Received: by 10.112.12.68 with SMTP id w4mr4274930lbb.87.1432397389582; Sat, 23 May 2015 09:09:49 -0700 (PDT) Received: by 10.25.128.206 with HTTP; Sat, 23 May 2015 09:09:49 -0700 (PDT) In-Reply-To: <03a201d09529$f606e870$e214b950$@gmail.com> References: <03a201d09529$f606e870$e214b950$@gmail.com> Date: Sat, 23 May 2015 11:09:49 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=001a11c3b4349557fd0516c2018d Archived-At: Cc: Ben Campbell , DISPATCH , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 May 2015 16:09:55 -0000 --001a11c3b4349557fd0516c2018d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Roni, My understanding of the charter is that the first milestone will encompass deliverables 1. and 2, thus new RTP topologies that may be required would be considered as part of that milestone. Regards, Mary. On Sat, May 23, 2015 at 2:27 AM, Roni Even wrote: > Hi, > > The charter looks good to me, > > > > One comment about the milestone, the first milestone is for architecture > while the first bullet in the work to be done also mentions the RTP > topologies, so I assume that the first milestone also includes new RTP > topologies or will the RTP topologies to be used will only be topologies > from draft-ietf-avtcore-rtp-topologies-update-07 > > ? > > > > Roni Even > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Mary > Barnes > *Sent:* 22 May, 2015 6:52 PM > *To:* DISPATCH > *Cc:* Barry Leiba; Ben Campbell > *Subject:* [dispatch] Updated PERC Charter proposal > > > > Hi all, > > > > Below, please find an updated charter for PERC. Magnus has updated the > charter to incorporate feedback from the DISPATCH WG mailing list > discussions and we've made a round of editorial changes. It should be > ready for Ben to submit to the IESG for consideration as a new WG. So, > please review and provide any final comments no later than 18:00 GMT on > Monday, May 25th (and yeah, I know it's a US holiday but folks in the US > have the rest of today to review and there really should be no surprises;= ) > > > > Regards, > > Mary > > DISPATCH WG co-chair > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > > > > Name: Privacy Enhanced RTP Conferencing (PERC) > > Area: ART > > Chairs: TBD > > Mailing List: > > > > Motivation for new WG > > RTP-based real-time multi-party interactive media conferencing is in > widespread use today. Many of the deployments use one or more centrally > located media distribution devices that perform selective forwarding of > mixed-media streams received from the participating endpoints. The media > transport protocol commonly used is RTP (RFC3550). There are various > signaling systems used to establish these multi-party conferences. > > These conferences require security to ensure that the RTP media and > related metadata of the conference is kept private and only available to > the set of invited participants and other devices trusted by those > participants with their media. At the same time, multi-party media > conferences need source authentication and integrity checks to protect > against modifications, insertions, and replay attacks. Media distributio= n > devices supporting these conferences may also perform RTP header changes, > and they often consume and create RTCP messages for efficient media > handling. > > > > To date, deployment models for these multi-party media distribution > devices do not enable the devices to perform their functions without havi= ng > keys to decrypt the participants=E2=80=99 media, primarily using Secure R= TP > (RFC3711) to provide session security. > > This trust model has limitations and prevents or hampers deployment of > secure RTP conferencing in a multitude of cases, including outsourcing, > legal requirements on confidentiality, and utilization of virtualized > servers. Thus, a new architectural model and related specifications are > needed, with a focused effort from the RTP and Security communities. > > WG Objectives > > This WG will work on a solution that enables centralized SRTP-based > conferencing, where the central device distributing the media is not > required to be trusted with the keys to decrypt the participants=E2=80=99= media. > The media must be kept confidential and authenticated between an > originating endpoint and the explicitly allowed receiving endpoints or > other devices. Further, it is desired that a solution still provides > replay protection, so that the media distribution devices can=E2=80=99t r= eplay > previous parts of the media. > > The solution must also provide security for each hop between endpoints an= d > multi-party media distribution devices and between multi-party media > distribution devices. The RTCP messages and RTP header extensions require= d > for the media distribution device to perform the selective media forwardi= ng > may require both source authentication and integrity as well as > confidentiality. The solution may also consider providing end-to-end > security for a subset of the RTCP messages or RTP header extensions. > > > > The solution should be implementable by both SIP (RFC3261) and WebRTC ( > draft-ietf-rtcweb-overview > ) > endpoints. How telepresence endpoints using the protocols defined in the > CLUE working group could utilize the defined security solution needs to b= e > considered. However, it is acknowledged that limitations may exist, > resulting in restricted functionality or need for additional adaptations = of > the CLUE protocols. > > > > This working group will perform the following work: > > 1. Define a general architecture and RTP topology(s) that enables > end-to-end media security for multi-party RTP conferencing. > > 2. Define the trust model and describe the resulting security > properties. > > 3. Document models considered for integrating the solution with WebRTC, > SIP and CLUE establishment of conferencing sessions. > > 4. Specify any necessary extensions to SRTP. > > 5. Define needed Key Management Functions that distribute the keys. The > system needs to be able to bind the media to the sender of the media=E2= =80=99s > identity and/or the identity of the conference. > > Collaboration > > If there is identification of missing protocols or functionalities, such > work can be requested to be done in another working group with a suitable > charter or by requests for chartering it in this WG or another WG. > Potential items that might require work in other WGs are DTLS extensions > (TLS WG) and RTP header extensions (AVTEXT WG). This work requires strong > collaboration with the security area. We will notify AVTCore, CLUE, MMUSI= C, > RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work. > > Non-Goals > > The PERC working group is not chartered to extend any signaling system > used to establish the RTP-based conferences. It will, however, need to > consider in its architecture how the solution may integrate with these > systems, and document such consideration for WebRTC, SIP, and CLUE. The > specification of how a particular system integrates the security solution > will happen outside of this working group, in suitable venues. > > > > The WG will not consider non-real-time usage, multicast-based media > distribution, or Security descriptions-based keying (RFC4568). > > > > Goals and Milestones > > > > TBD Submit architecture or framework specification to IESG (Standards > Track) > > > > TBD Submit documentation of how to integrate solution in SIP, WebRTC and > CLUE to IESG (Informational) > > TBD Submit SRTP protocol extension specification to IESG (Standards Trac= k) > > > > TBD Submit Key-management protocol specification to IESG (Standards Trac= k) > > > > Input to the WG > > > > Proposals already existing relating to this charter proposal: > > > > https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ > > https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framew= ork/ > https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ > > > --001a11c3b4349557fd0516c2018d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Roni,

My understanding of the = charter is that the first milestone will encompass deliverables 1. and 2, t= hus new RTP topologies that may be required would be considered as part of = that milestone. =C2=A0

Regards,

Mary.=C2=A0

On Sat, = May 23, 2015 at 2:27 AM, Roni Even <ron.even.tlv@gmail.com> wrote:

The charter looks good to me,
=C2=A0
One comment about the milestone, = the first milestone is for architecture while the first bullet in the work = to be done also mentions the RTP topologies, so I assume that the first mil= estone also includes new RTP topologies or will the RTP topologies to be us= ed will only be topologies from draft-ietf-avtco= re-rtp-topologies-update-07 ?
=C2=A0
Roni Even
=C2=A0=
From:= dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ma= ry Barnes
Sent: 22 May, 2015 6:52 PM
To: DISPATCH
Cc: Barry Leiba; Ben Campbell
Subject: [dispatch] Updated PE= RC Charter proposal
=C2=A0
Hi all,
= =C2=A0
Below, please find an up= dated charter for PERC.=C2=A0 Magnus has updated the charter to incorporate= feedback from the DISPATCH WG mailing list discussions and we've made = a round of editorial changes.=C2=A0 It should be ready for Ben to submit to= the IESG for consideration as a new WG.=C2=A0 So, please review and provid= e any final comments no later than 18:00 GMT on Monday, May 25th (and yeah,= I know it's a US holiday but folks in the US have the rest of today to= review and there really should be no surprises;)=C2=A0
=C2=A0
Regards,
= Mary
DISPATCH WG co-chai= r
=C2=A0
=C2=A0
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
= =C2=A0
=C2=A0
=
=C2=A0
Name: Privacy Enhanced RTP C= onferencing (PERC)
Area: ART
Chairs: TB= D
Mailing List: <using dispatch@ietf.org for now>
=C2=A0
<= span style=3D"font-size:11.5pt;font-family:"Arial","sans-ser= if";color:black">Motivation for new WG
RTP-based rea= l-time multi-party interactive media conferencing is in widespread use toda= y. Many of the deployments use one or more centrally located media distribu= tion devices that perform selective forwarding of mixed-media streams recei= ved from the participating endpoints. The media transport protocol commonly= used is RTP (RFC3550). There are various signaling systems used to establi= sh these multi-party conferences.
These conferences requi= re security to ensure that the RTP media and related metadata of the confer= ence is kept private and only available to the set of invited participants = and other devices trusted by those participants with their media.=C2=A0 At = the same time, multi-party media conferences need source authentication and= integrity checks to protect against modifications, insertions, and replay = attacks.=C2=A0 Media distribution devices supporting these conferences may = also perform RTP header changes, and they often consume and create RTCP mes= sages for efficient media handling.
=C2=A0
To date, deployment models= for these multi-party media distribution devices do not enable the devices= to perform their functions without having keys to decrypt the participants= =E2=80=99 media, primarily using Secure RTP (RFC3711) to provide session se= curity.
This trust model has limitations and prevents or= hampers deployment of secure RTP conferencing in a multitude of cases, inc= luding outsourcing, legal requirements on confidentiality, and utilization = of virtualized servers. Thus, a new architectural model and related specifi= cations are needed, with a focused effort from the RTP and Security communi= ties.
WG Objectives
This WG will work o= n a solution that enables centralized SRTP-based conferencing, where the ce= ntral device distributing the media is not required to be trusted with the = keys to decrypt the participants=E2=80=99 media. The media must be kept con= fidential and authenticated between an originating endpoint and the explici= tly allowed receiving endpoints or other devices.=C2=A0 Further, it is desi= red that a solution still provides replay protection, so that the media dis= tribution devices can=E2=80=99t replay previous parts of the media.<= u>
The solution must also provide security for each hop between en= dpoints and multi-party media distribution devices and between multi-party = media distribution devices. The RTCP messages and RTP header extensions req= uired for the media distribution device to perform the selective media forw= arding may require both source authentication and integrity as well as conf= identiality. The solution may also consider providing end-to-end security f= or a subset of the RTCP messages or RTP header extensions.=
=C2=A0
The solution should be imp= lementable by both SIP (RFC3261) and WebRTC (draft-ietf-rtcweb-overview) endpoints= . How telepresence endpoints using the protocols defined in the CLUE workin= g group could utilize the defined security solution needs to be considered.= However, it is acknowledged that limitations may exist, resulting in restr= icted functionality or need for additional adaptations of the CLUE protocol= s.
=C2=A0
=
This w= orking group will perform the following work:
1. =C2=A0=C2=A0= =C2=A0Define a general architecture and RTP t= opology(s) that enables end-to-end media security for multi-party RTP confe= rencing.
2. =C2=A0=C2=A0=C2=A0De= fine the trust model and describe the resulting security properties.=
3.=C2=A0 Document mode= ls considered for integrating the solution with WebRTC, SIP and CLUE establ= ishment of conferencing sessions.
4. =C2=A0=C2=A0=C2=A0= Specify any necessary extensions to SRTP.<= /u>
5. =C2=A0=C2=A0Define needed Key Managemen= t Functions that distribute the keys. The system needs to be able to bind t= he media to the sender of the media=E2=80=99s identity and/or the identity = of the conference.
Collaboration
If th= ere is identification of missing protocols or functionalities, such work ca= n be requested to be done in another working group with a suitable charter = or by requests for chartering it in this WG or another WG. Potential items = that might require work in other WGs are DTLS extensions (TLS WG) and RTP h= eader extensions (AVTEXT WG). This work requires strong collaboration with = the security area. We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3= C WebRTC, and other related groups about this work.
Non-= Goals
The PERC working group is not chartered to extend a= ny signaling system used to establish the RTP-based conferences. It will, h= owever, need to consider in its architecture how the solution may integrate= with these systems, and document such consideration for WebRTC, SIP, and C= LUE. The specification of how a particular system integrates the security s= olution will happen outside of this working group, in suitable venues.
=C2=A0
The WG will n= ot consider non-real-time usage, multicast-based media distribution, or Sec= urity descriptions-based keying (RFC4568).
=C2=A0
Goals and Milestones<= /p>
=C2= =A0
<= span style=3D"font-size:11.5pt;font-family:"Arial","sans-ser= if";color:black">TBD =C2=A0Submit architecture or framework specificat= ion to IESG (Standards Track)
=C2=A0
TBD Submit documentation of how to integrate solution i= n SIP, WebRTC and CLUE to IESG (Informational)
TBD =C2=A0= Submit SRTP protocol extension specification to IESG (Standards Track)
=C2=A0
TBD =C2=A0Subm= it Key-management protocol specification to IESG (Standards Track)
=C2=A0
Input to the WG
=C2=A0
Proposals al= ready existing relating to this charter proposal:
<= p class=3D"MsoNormal">=C2=A0
https://datatracke= r.ietf.org/doc/draft-jones-avtcore-private-media-reqts/
https://datatracker.ietf.org/doc/draft-jones-avtcore-priva= te-media-framework/
<= /span>https://datatracker.ietf.org/doc/d= raft-cheng-avtcore-srtp-cloud/

=C2=A0

--001a11c3b4349557fd0516c2018d-- From nobody Mon May 25 00:25:02 2015 Return-Path: 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 A3FFD1B2B04 for ; Mon, 25 May 2015 00:25:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 kvLZgbdvGSpr for ; Mon, 25 May 2015 00:24:56 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EB61B2AD2 for ; Mon, 25 May 2015 00:24:55 -0700 (PDT) X-AuditID: c1b4fb3a-f79ec6d000006dc0-a7-5562ce454554 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id D0.D2.28096.54EC2655; Mon, 25 May 2015 09:24:53 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.210.2; Mon, 25 May 2015 09:24:52 +0200 Message-ID: <5562CE45.5080300@ericsson.com> Date: Mon, 25 May 2015 09:24:53 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mary Barnes , Roni Even References: <03a201d09529$f606e870$e214b950$@gmail.com> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvra7ruaRQgwPTVS0OLb7EajG/8zS7 xdJJC1gtPu/fz2zxt53ZgdWjZVUvs8fOWXfZPZYs+cnkMWvnE5YAligum5TUnMyy1CJ9uwSu jIs7owsesFe8vHuXsYFxGVsXIyeHhICJxIZ/nUwQtpjEhXvrgeJcHEICRxkl5iyYxwLhLGeU OPFqLTNIFa+AtsTKybtYQGwWAVWJmc+ng3WzCVhI3PzRCDZVVCBKYurjdSwQ9YISJ2c+AbNF BIIkpjzaD1bDLJApMatjOjuILSxgKrFk5w+ozQcZJfrOPgNKcHBwCgRK3J+eBmIyC9hLPNha BtEqL9G8dTbYOUJA5zQ0dbBOYBSchWTbLISOWUg6FjAyr2IULU4tLs5NNzLSSy3KTC4uzs/T y0st2cQIDO2DW35b7WA8+NzxEKMAB6MSD69CU1KoEGtiWXFl7iFGaQ4WJXFez66QUCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2Mkg9Wvf88aVLBGr08BrvTU84+0Jz5o09yS5xazO3k4jqz 6ImNv+ZqMrVvYjH3m2JxLELZyJzdsuSfZhZb4i6nKWUuLVxrF56aWNS8sCzw8UHrzW828j3/ YvjuXOX0rV4aO07PWFG2NHmRv05k5jtRWas2T8ZKNj7D9GC+mX0NfQyquR7H9bcpsRRnJBpq MRcVJwIAKaHYnk4CAAA= Archived-At: Cc: Ben Campbell , DISPATCH , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 07:25:00 -0000 Mary Barnes skrev den 2015-05-23 18:09: > Hi Roni, > > My understanding of the charter is that the first milestone will > encompass deliverables 1. and 2, thus new RTP topologies that may be > required would be considered as part of that milestone. From my perspective, the intention here is to ensure that the architecture makes clear which RTP topologies that are considered and supported for the solution. This includes both existing ones, as well as new ones if there are a need. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F�r�gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon May 25 05:58:58 2015 Return-Path: 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 66F421A89A7 for ; Mon, 25 May 2015 05:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hmUbggUMI63P for ; Mon, 25 May 2015 05:58:52 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC9F1A89A0 for ; Mon, 25 May 2015 05:58:51 -0700 (PDT) X-AuditID: c1b4fb25-f79b66d000001131-d0-55631c89cc8d Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 07.33.04401.98C13655; Mon, 25 May 2015 14:58:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.210.2; Mon, 25 May 2015 14:58:47 +0200 Message-ID: <55631C88.3050108@ericsson.com> Date: Mon, 25 May 2015 14:58:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Mary Barnes , DISPATCH References: In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvrW6nTHKowa0TMhaHFl9itZjfeZrd YumkBawWn/fvZ3Zg8WhZ1cvssXPWXXaPJUt+MnnM2vmEJYAlissmJTUnsyy1SN8ugSvjQMcN xoJGnormjXPYGhiPc3YxcnJICJhIHNjxhhXCFpO4cG89WxcjF4eQwFFGicu79kM5yxklOle8 Ye9i5ODgFdCW2P/PBKSBRUBV4vPEP4wgNpuAhcTNH41sILaoQJTE1MfrWEBsXgFBiZMzn4DZ IgJeEi9+f2ACsZkFPCV2bd8CFhcW0JLoPzOfBWS8kECAxKKlISBhToFAibkXW1ghyi0kZs4/ zwhhy0s0b53NDGILAV3T0NTBOoFRcBaSbbOQtMxC0rKAkXkVo2hxanFSbrqRsV5qUWZycXF+ nl5easkmRmBQH9zyW3UH4+U3jocYBTgYlXh4FZuSQoVYE8uKK3MPMUpzsCiJ83p2hYQKCaQn lqRmp6YWpBbFF5XmpBYfYmTi4JRqYMycKt/zoexiosuJWz2bUm9me++9WeB86vFe2SMC6ga/ N3oy8Ch9ZG09nhxluTJZsPb07L0MaqLHri3k1fpgerp086Ot2+VyWTLP2aR9fcSxUz3glJXO 7urwC2nzctycfsj/vfSF/92VoJXP3290ZrEx4VnCf2VHXePtOKai0Ly9rSXxVXGi/kosxRmJ hlrMRcWJAL43DYpLAgAA Archived-At: Cc: Ben Campbell , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 12:58:56 -0000 Hi, I have some additional proposed tweaks to the charter text: OLD: The solution should be implementable by both SIP (RFC3261) and WebRTC (draft-ietf-rtcweb-overview) endpoints. NEW: The solution should be implementable by both SIP (RFC3261) and WebRTC endpoints (draft-ietf-rtcweb-overview). Comment: I think we should actually refer to the definition of WebRTC endpoints that are in the overview document, thus the move of the reference. OLD: 5. Define needed Key Management Functions that distribute the keys. The system needs to be able to bind the media to the sender of the media’s identity and/or the identity of the conference. NEW: 5. Define needed Key Management Functions that distribute the keys. The system needs to be able to bind the media to the identity of the sender of the media and/or the identity of the conference. Comment: Suggest that we are explicit that we are binding the media to an asserted identity for a particular media stream sender. Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Mon May 25 08:11:00 2015 Return-Path: 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 7B1BD1A907B for ; Mon, 25 May 2015 08:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 ivRaQFJA9SSz for ; Mon, 25 May 2015 08:10:54 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B021A9072 for ; Mon, 25 May 2015 08:10:53 -0700 (PDT) X-AuditID: c1b4fb30-f798d6d0000009ec-73-55633b7ba528 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id C6.A8.02540.B7B33655; Mon, 25 May 2015 17:10:51 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.71]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0210.002; Mon, 25 May 2015 17:10:51 +0200 From: =?Windows-1252?Q?G=F6ran_Eriksson_AP?= To: Mary Barnes , DISPATCH Thread-Topic: [dispatch] Updated PERC Charter proposal Thread-Index: AQHQlKdG9ChevnWVek2TK9VDBGzQpZ2M0KkA Date: Mon, 25 May 2015 15:10:50 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.0.150423 x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="Windows-1252" Content-ID: <19CD0FF7E7BDA140AE57F18E195EF085@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM+JvrW61dXKowfuVqhaHFl9itZjfeZrd YumkBawWn/fvZ3Zg8WhZ1cvssXPWXXaPJUt+MnnM2vmEJYAlissmJTUnsyy1SN8ugSujfcc6 loKLLhX7f6g2MP606GLk5JAQMJH4N7+BDcIWk7hwbz2YLSRwlFFi8huxLkYuIHsxo8TGmbdZ QRJsAr4S/+fsBbNFBLwkXvz+wARiMwt4StzZ8pwRxBYWMJVYsvMHG0SNmcTH/WtZIGwjibXf 9oDFWQRUJRZt+8AMYvMKWEucbHkPVMMBtCxAYtHSEJAwp0CgxNyLLWCrGAVkJe5/v8cCsUpc 4taT+UwQNwtILNlznhnCFpV4+fgfWL2ogJ7E0q+noWoUJdqfNjBC9BpIvD83nxnCtpbYtf0y 1ExtiWULX0OdIyhxcuYTlgmMErOQrJuFpH0WkvZZSNpnIWlfwMi6ilG0OLU4KTfdyEgvtSgz ubg4P08vL7VkEyMwVg9u+W2wg/Hlc8dDjAIcjEo8vApNSaFCrIllxZW5hxilOViUxHk9u0JC hQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAu4aqqWsbxb1LKrB+/27tae1hP3j3bFPE/huGD +hTL3ltHnTd/EF2VVvHr06owwTTBozKvPpz79ZmRv+qY7VX9DX8a7vNVN3rUrFlz/8TPmxb6 zIuXvnt2QvKy4azvazUdZa/Os/T59/xc/9O9Xavs+/a+XlKSf/KJfKjTcnWx1d3dMhE10a16 SizFGYmGWsxFxYkAXaZ4SrYCAAA= Archived-At: Cc: Ben Campbell , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 15:10:58 -0000 Hi, I have some minor comments concerning the meaning of =B3SIP=B2 and =B3WebRT= C=B2 endpoints. Sorry for the late response and for top-posting but it became a bit messy to add inline: 1. The link to=20 https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ did not work? 2. The text uses =B3SIP=B2 and =B3WebRTC=B2 to describe the different kind = of end-points that are in scope. W3C WebRTC WG recognises the fact that the WebRTC end points can be browser end points=20 (browser + web (client portion of) web app) or native WebRTC (or rather rtcweb) clients and both are in scope for the W3C WG. The browser endpoint trust model is different from that of native clients and it is also evolving. I think that clarity in how different endpoints trust model and security framework look like and different is beneficial for several of the deliverables, notably 2,3 and 5. 3. The charter says it will =B3notify=B2 W3C WebRTC about this activity; wh= at do the WG expect to get back and why not =8Ccoordinate=B9? And are there ot= her W3C WG=B9s that are relevant? Again, sorry for not being able to give this feedback previously. If all of the above is clear to anyone except me, then I do apologise for having missed that.=20 In any case, I personally see these comments as minor and about clarifications, neither which should prevent the charter from being submitted to IESG. Best Regards G=F6ran -----Original Message----- From: Mary Barnes Date: Friday 22 May 2015 17:52 To: Dispatch Cc: Barry Leiba , Ben Campbell Subject: [dispatch] Updated PERC Charter proposal >Hi all, > > >Below, please find an updated charter for PERC. Magnus has updated the >charter to incorporate feedback from the DISPATCH WG mailing list >discussions and we've made a round of editorial changes. It should be >ready for Ben to submit to the IESG for > consideration as a new WG. So, please review and provide any final >comments no later than 18:00 GMT on Monday, May 25th (and yeah, I know >it's a US holiday but folks in the US have the rest of today to review >and there really should be no surprises;) > > >Regards, >Mary >DISPATCH WG co-chair > > > > >=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > > >Name: Privacy Enhanced RTP Conferencing (PERC) >Area: ART >Chairs: TBD >Mailing List: dispatch@ietf.org > for now>=20 > >Motivation for new WG > >RTP-based real-time multi-party interactive media > conferencing is in widespread use today. Many of the deployments use one >or more centrally located media distribution devices that perform >selective forwarding of mixed-media streams received from the >participating endpoints. The media transport protocol commonly > used is RTP (RFC3550). There are various signaling systems used to >establish these multi-party conferences. > > >These > conferences require security to ensure that the RTP media and related >metadata of the conference is kept private and only available to the set >of invited participants and other devices trusted by those participants >with their media. At the same time, multi-party > media conferences need source authentication and integrity checks to >protect against modifications, insertions, and replay attacks. Media >distribution devices supporting these conferences may also perform RTP >header changes, and they often consume and create > RTCP messages for efficient media handling. > > >To date, deployment models for these multi-party > media distribution devices do not enable the devices to perform their >functions without having keys to decrypt the participants=B9 media, >primarily using Secure RTP (RFC3711) to provide session security. > > >This trust model has limitations and prevents or > hampers deployment of secure RTP conferencing in a multitude of cases, >including outsourcing, legal requirements on confidentiality, and >utilization of virtualized servers. Thus, a new architectural model and >related specifications are needed, with a focused > effort from the RTP and Security communities. > >WG Objectives > >This WG will work on a solution that enables centralized > SRTP-based conferencing, where the central device distributing the media >is not required to be trusted with the keys to decrypt the participants=B9 >media. The media must be kept confidential and authenticated between an >originating endpoint and the explicitly > allowed receiving endpoints or other devices. Further, it is desired >that a solution still provides replay protection, so that the media >distribution devices can=B9t replay previous parts of the media. > >The solution must also provide security for each > hop between endpoints and multi-party media distribution devices and >between multi-party media distribution devices. The RTCP messages and RTP >header extensions required for the media distribution device to perform >the selective media forwarding may require > both source authentication and integrity as well as confidentiality. The >solution may also consider providing end-to-end security for a subset of >the RTCP messages or RTP header extensions. > >The solution should be implementable by both SIP > (RFC3261) and WebRTC (draft-ietf-rtcweb-overview >) > endpoints. How telepresence endpoints using the protocols defined in the >CLUE working group could utilize the defined security solution needs to >be considered. However, it is acknowledged that limitations may exist, >resulting in restricted functionality or > need for additional adaptations of the CLUE protocols. > >This working group will perform the following work: > >1. > Define a general architecture and RTP topology(s) that enables >end-to-end media security for multi-party RTP > conferencing. >2. > Define the trust model and describe the resulting security properties. >3. Document models considered for integrating the solution with WebRTC, >SIP and CLUE establishment of conferencing sessions. >4. > Specify any necessary extensions to SRTP. >5. > Define needed Key Management Functions that distribute the keys. The >system needs to be able to bind the media > to the sender of the media=B9s identity and/or the identity of the >conference.=20 > >Collaboration > >If there is identification of missing protocols > or functionalities, such work can be requested to be done in another >working group with a suitable charter or by requests for chartering it in >this WG or another WG. Potential items that might require work in other >WGs are DTLS extensions (TLS WG) and RTP > header extensions (AVTEXT WG). This work requires strong collaboration >with the security area. We will notify AVTCore, CLUE, MMUSIC, RTCWEB, >SIPREC, W3C WebRTC, and other related groups about this work. > > >Non-Goals > >The PERC working group is not chartered to extend > any signaling system used to establish the RTP-based conferences. It >will, however, need to consider in its architecture how the solution may >integrate with these systems, and document such consideration for WebRTC, >SIP, and CLUE. The specification of how > a particular system integrates the security solution will happen outside >of this working group, in suitable venues. > > >The WG will not consider non-real-time usage, multicast-based > media distribution, or Security descriptions-based keying (RFC4568). > >Goals and Milestones >=20 >TBD Submit architecture or framework specification > to IESG (Standards Track) > >TBD Submit documentation of how to integrate solution > in SIP, WebRTC and CLUE to IESG (Informational) > >TBD Submit SRTP protocol extension specification > to IESG (Standards Track) > >TBD Submit Key-management protocol specification > to IESG (Standards Track) > > >Input to the WG > >Proposals already existing relating to this charter > proposal: > >https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-reqts/ >=20 >>https://datatracker.ietf.org/doc/draft-jones-avtcore-private-media-framew >>ork/ >=20 >ork/>https://datatracker.ietf.org/doc/draft-cheng-avtcore-srtp-cloud/ > > > > > From nobody Tue May 26 12:30:12 2015 Return-Path: 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 6FCB81A87A2 for ; Tue, 26 May 2015 12:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -114.511 X-Spam-Level: X-Spam-Status: No, score=-114.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] 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 86PpNsWAILNs for ; Tue, 26 May 2015 12:30:09 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFEB11A00B1 for ; Tue, 26 May 2015 12:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2709; q=dns/txt; s=iport; t=1432668608; x=1433878208; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3mFzE7jjxDMFr89VLaUmBi3RLlJZUwCSGajMPqD6w9c=; b=cNrXRU+AMXVWXCQmXnatfJk9kJGthgLPYUgHV1k39/11bO8TyM9laq7O erlTr6eqDoX9m7u2PzIb7cb6JUHKen/kA72oEPMMFmZExEyP7LkWv8OPG yXR5tdbTLQObLKaPRZN2hb36bmm1sFYBMmQ2P3la4E9u7KLStM6V7uMtH w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AABADhyGRV/5BdJa1cgxBUXgbDKgmBTwqFLUoCgUk4FAEBAQEBAQGBCoQiAQEBAwEBAQE3NAYFBQsCAQgYHhAhBgEKJQIEDgUUiAMDCggNywwNhHABAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYIFMwIFgxeBFgWTCIQ1hB5jgVmBKT6ORYMqg1kjg3hvgUaBAQEBAQ X-IronPort-AV: E=Sophos;i="5.13,500,1427760000"; d="scan'208";a="153572425" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP; 26 May 2015 19:30:08 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t4QJU7Ib025413 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 26 May 2015 19:30:08 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.147]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 26 May 2015 14:30:07 -0500 From: "Cullen Jennings (fluffy)" To: Tessa Fallon Thread-Topic: [dispatch] Standardization of FFV1, Matroska Thread-Index: AQHQl+pfXykvb3tTtUOx8KkIWH3cpA== Date: Tue, 26 May 2015 19:30:06 +0000 Message-ID: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: <9F062845E91DDE4FA9EB4DFBF1879305@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 19:30:11 -0000 As a user, I'd like to see well defined specifications for both of these. I= think dispatch is a good place to discuss how we could move this work forw= ard.=20 Cullen > On May 21, 2015, at 10:30 AM, Tessa Fallon wrote= : >=20 > Greetings! >=20 > MediaConch: Media Conformance Checker (maintained by MediaArea and funded= by PREFORMA*) is looking to solicit feedback from the IETF for proposed st= andardization of FFV1 and Matroska. =20 >=20 > The current (and under development) specifications for FFV1 exist here: h= ttps://mediaarea.net/ffv1.html > and here for Matroska: > http://matroska.org/technical/specs/index.html >=20 > The goal of the PREFORMA project is to address the challenge of implement= ing good quality standardised file formats for preserving data content in t= he long term. Our objective in regards to standardization FFV1 and Matroska= is to improve the sustainability factors for both formats including disclo= sure, credibility, and transparency while also creating a mechanism to clar= ify, authoritatively, the intent of the specifications. After careful resea= rch into past IETF work (in particular Daala and Opus), we are planning to = prepare FFV1 and Matroska for submission to the IETF. >=20 > Our preparations are not yet at the stage where we have created a formal = draft or submission for the IETF. Before we proceed, we'd like to engage t= he IETF community in discussion of the specifications and suitability for I= ETF. >=20 > Briefly, FFV1 is a lossless video codec and Matroska is an extensible ope= n source media container. Matroska is the base of WebM, and WebM is the p= referred container for VP9, which has a draft RFC: https://tools.ietf.org/h= tml/draft-grange-vp9-bitstream-00 >=20 > Work on FFV1 is coordinated through the GitHub and the ffmpeg-devel maili= ng list (http://ffmpeg.org/mailman/listinfo/ffmpeg-devel). Work on Matroska= is coordinated through GitHub and the Matroska.org devel mailing list (htt= p://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel).=20 >=20 > GitHub repositories are here: > https://github.com/MediaArea/FFV1 > https://github.com/Matroska-Org/ebml-specification >=20 > =20 > We look forward to hearing your thoughts and suggestions. >=20 > Best wishes, >=20 >=20 > Tessa Fallon, on behalf of MediaArea >=20 > * PREFORMA is a project funded by the European Union as part of FP7. More= information about PREFORMA can be found here: http://www.preforma-project.= eu/ > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue May 26 13:23:14 2015 Return-Path: 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 86F811B3122 for ; Tue, 26 May 2015 13:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.922 X-Spam-Level: X-Spam-Status: No, score=0.922 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, SPF_FAIL=0.001] 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 owWbBGqJRaSU for ; Tue, 26 May 2015 13:23:11 -0700 (PDT) Received: from smtp.mozilla.org (mx1.scl3.mozilla.com [63.245.214.155]) (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 F081A1ACE1D for ; Tue, 26 May 2015 13:23:10 -0700 (PDT) Received: from localhost (localhost6.localdomain [127.0.0.1]) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTP id 4EA75C25D3 for ; Tue, 26 May 2015 20:23:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at mozilla.org Received: from smtp.mozilla.org ([127.0.0.1]) by localhost (mx1.mail.scl3.mozilla.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QG-1VTJPAOpz for ; Tue, 26 May 2015 20:23:10 +0000 (UTC) Received: from [10.252.26.23] (corp.mtv2.mozilla.com [63.245.221.32]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.scl3.mozilla.com (Postfix) with ESMTPSA id 3B5A2C258F for ; Tue, 26 May 2015 20:23:10 +0000 (UTC) Message-ID: <5564D62E.9070506@xiph.org> Date: Tue, 26 May 2015 13:23:10 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 SeaMonkey/2.26 MIME-Version: 1.0 To: "dispatch@ietf.org" References: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> In-Reply-To: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 May 2015 20:23:12 -0000 Cullen Jennings (fluffy) wrote: > As a user, I'd like to see well defined specifications for both of these. I think dispatch is a good place to discuss how we could move this work forward. +1 From nobody Wed May 27 19:24:29 2015 Return-Path: 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 7C2751A00E1 for ; Wed, 27 May 2015 19:24:27 -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 a_c36GzPNnYP for ; Wed, 27 May 2015 19:24:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72CF61A00B1 for ; Wed, 27 May 2015 19:24:26 -0700 (PDT) Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t4S2OFVS073894 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 27 May 2015 21:24:25 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23] From: "Ben Campbell" To: "Timothy B. Terriberry" Date: Wed, 27 May 2015 21:24:15 -0500 Message-ID: In-Reply-To: <5564D62E.9070506@xiph.org> References: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> <5564D62E.9070506@xiph.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.1r5084) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 02:24:27 -0000 On 26 May 2015, at 15:23, Timothy B. Terriberry wrote: > Cullen Jennings (fluffy) wrote: >> As a user, I'd like to see well defined specifications for both of >> these. I think dispatch is a good place to discuss how we could move >> this work forward. > > +1 > (no hats) Also +1. From nobody Thu May 28 16:08:19 2015 Return-Path: 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 8A42D1A914B; Thu, 28 May 2015 15:30:41 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version" X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 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, SPF_PASS=-0.001, 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 qfxjhlHhQuNe; Thu, 28 May 2015 15:30:40 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 526F11ACC8A; Thu, 28 May 2015 15:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1432852242; x=1464388242; h=message-id:date:to:from:subject; bh=cnAfKUN5I40bXwqdl8AN0B3LEB62kyOBnnmylajfE00=; b=uBSDWsawOL+hJL12MvVCRuP6q2s+PwtLhbkSa9srNk2y9Qz3RaF270G+ AsEzHSvjAaqeQTyN6LHr+ahUIuVOn3C0GERw350v82mIT6/iEoImObhl+ LT+RuzuzPkRVvWO86k/ygs9sw80XqoAJ6t0zU1WNeRiz/VVVS6tD7hd3h A=; X-IronPort-AV: E=McAfee;i="5700,7163,7815"; a="90947120" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth02.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2015 15:30:34 -0700 X-IronPort-AV: E=Sophos;i="5.13,514,1427785200"; d="scan'208";a="928347419" Received: from plus.qualcomm.com ([10.52.255.8]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 May 2015 15:30:32 -0700 Received: from Ironmsg03-R.qualcomm.com (ironmsg03-R.qualcomm.com [172.30.46.17]) by plus.qualcomm.com (8.14.2/8.14.2/1.0) with ESMTP id t4SMUW5E007451; Thu, 28 May 2015 15:30:32 -0700 X-IronPort-AV: E=Sophos;i="5.13,514,1427785200"; d="scan'208";a="928347218" X-ojodefuego: yes Received: from myvpn-l-00214.ras.qualcomm.com (HELO [99.111.97.136]) ([10.64.133.249]) by Ironmsg03-R.qualcomm.com with ESMTP; 28 May 2015 15:30:26 -0700 Mime-Version: 1.0 Message-Id: X-Mailer: Eudora for Mac OS X Date: Thu, 28 May 2015 15:30:25 -0700 To: (mmusic@ietf.org), (dispatch@ietf.org) From: Randall Gellens Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 X-Random-Sig-Tag: 1.0b28 Archived-At: X-Mailman-Approved-At: Thu, 28 May 2015 16:08:19 -0700 Subject: [dispatch] Virtual Bar-BoF for SLIM X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 May 2015 22:30:41 -0000 I'm sending this message to the mmusic and dispatch lists, but all discussion should take place on the SLIM list. I've created a Doodle poll to set a time and date for a virtual Bar-BoF for SLIM. To follow up on the SLIM face-to-face discussion in Dallas, this virtual bar-BoF provides an opportunity for further discussion with a goal of gaining consensus on moving forward with a charter. In particular: (1) Are there objections to the current proposed charter wording, or is it acceptable? (2) Are there objections to moving forward on this basis? Please participate in the Doodle poll to select the time/date, and then in the virtual Bar-BoF. http://doodle.com/ryuai9ieqxi7hue2 -- Randall Gellens Opinions are personal; facts are suspect; I speak for myself only -------------- Randomly selected tag: --------------- I loathe housework. You make beds, wash dishes -- and six months later you have to start all over again. --Joan Rivers From nobody Fri May 29 02:32:39 2015 Return-Path: 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 758CA1B2AB0 for ; Fri, 29 May 2015 02:32:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, 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 dsvF-jT9VPep for ; Fri, 29 May 2015 02:32:36 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FDF01B2AAF for ; Fri, 29 May 2015 02:32:36 -0700 (PDT) X-AuditID: c1b4fb2d-f794d6d000004501-f8-556832322483 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 42.E6.17665.23238655; Fri, 29 May 2015 11:32:34 +0200 (CEST) Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.50) with Microsoft SMTP Server id 14.3.210.2; Fri, 29 May 2015 11:32:34 +0200 Message-ID: <55683230.3020600@ericsson.com> Date: Fri, 29 May 2015 11:32:32 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: =?windows-1252?Q?G=F6ran_Eriksson_AP?= , Mary Barnes , DISPATCH References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvra6RUUaowdW3GhaHFl9itZjfeZrd YumkBawWn/fvZ3Zg8WhZ1cvssXPWXXaPJUt+MnnM2vmEJYAlissmJTUnsyy1SN8ugStjSdtE 9oJpohVPtx9jaWB8JdDFyMkhIWAisWvjc0YIW0ziwr31bF2MXBxCAkcZJV4cvcIE4SxnlNh6 p5MdpIpXQFvixuO3LCA2i4CqxKlb08BsNgELiZs/GtlAbFGBKImpj9exQNQLSpyc+YQFZJCI wFRGidaDL5lAEswCnhK7tm8BKxIWMJVYsvMH1OoGRokj5yeydjFycHAK2EgsOJgKYjIL2Es8 2FoG0Sov0bx1NjOILQR0T0NTB+sERsFZSNbNQuiYhaRjASPzKkbR4tTi4tx0I2O91KLM5OLi /Dy9vNSSTYzAsD645bfuDsbVrx0PMQpwMCrx8CYyZIQKsSaWFVfmHmKU5mBREuf16goJFRJI TyxJzU5NLUgtii8qzUktPsTIxMEp1cDI2HNko33gYZM1j33v6y4/Fh+7qX691lQVm7RCzfsW Kx9xlXhtmZlia2BuYbQ0ytF9ecc+tbcnH1c8/ZIxr8d4tWpU1KoInvzSxzt7a36oB2y/rtq+ WLoubZLLjXN3p09iWbbgzt63XFKz5cIm/tveHR5u+a3O3th5x1f1u3M+ln+O2mEsKvhBiaU4 I9FQi7moOBEA6/yjl0wCAAA= Archived-At: Cc: Ben Campbell , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 09:32:38 -0000 Hi, I hope others can comment on this also. G�ran Eriksson AP skrev den 2015-05-25 17:10: > Hi, > > I have some minor comments concerning the meaning of �SIP� and �WebRTC� > endpoints. > > Sorry for the late response and for top-posting but it became a bit messy > to add inline: > > 1. The link to > https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ did not work? It works fine for me. > 2. The text uses �SIP� and �WebRTC� to describe the different kind of > end-points that are in scope. > W3C WebRTC WG recognises the fact that the WebRTC end points can be > browser end points > (browser + web (client portion of) web app) or native WebRTC (or rather > rtcweb) clients and both are in scope for the W3C WG. > The browser endpoint trust model is different from that of native > clients and it is also evolving. > I think that clarity in how different endpoints trust model and > security framework look like and different is beneficial for several of > the deliverables, notably 2,3 and 5. The use of WebRTC endpoints where deliberate by my and intended to cover not only browsers but anything meeting the WebRTC endpoint definition. So the question, does this need to be made more explicit in the charter? > > 3. The charter says it will �notify� W3C WebRTC about this activity; what > do the WG expect to get back and why not �coordinate�? And are there other > W3C WG�s that are relevant? I think the expectation is that in the end W3C and likely RTCWEB WG agrees to integrate the PERC solution into their specifications so that one can actually use it with WebRTC. In intermediate step I think it will be a question of notifying for example when there exist a proposed blue-print for integration. This may be an example of where coordinate might be needed. I could see that we could change the last sentence in the collaboration part from: "We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work." to "We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work." Opinions? Cheers Magnus Westerlund ---------------------------------------------------------------------- Services, Media and Network features, Ericsson Research EAB/TXM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F�r�gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From nobody Fri May 29 07:54:00 2015 Return-Path: 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 DC49C1A92B5 for ; Fri, 29 May 2015 07:53:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.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, USER_IN_WHITELIST=-100] 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 vDyq2-OWoRMG for ; Fri, 29 May 2015 07:53:56 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BD071AC3AD for ; Fri, 29 May 2015 07:53:52 -0700 (PDT) Received: by lbbqq2 with SMTP id qq2so50087259lbb.3 for ; Fri, 29 May 2015 07:53:50 -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=nMB1xGYGYLNZOHoUi/ghXBwoatb1ka95U2osb+SwgRQ=; b=LFt8pCkoWo08KfnE4zq91aT2Snys1LQehsXhqIlfiGI1wnCB2QcabR8KPcMIYeXM2Q oQ1naaKVFuFRoqiAwp/97vqvzjipgmePJeTa52MU+B3z8hQV5NY6vgpv78ddH1aj3gzA ESchNv6CGCbuE3iZ2zxHEbZkv4OQKNUVofhIHwMGS9i11xaern3Zj/zJuRmxJoy+uoAl FfjQR1PZFCtNF/1w+L/dWnANjlTLmWh+N52QRYnWmXWvld/xuTCFG59IhdkVL0EI7beK t6y9AA3h7ApM8NUaGL2OpZw9dA+bBsdAlZpDmiUC1ZBg4gVybzGpwd/j3FMjnnRXslhb OH4g== MIME-Version: 1.0 X-Received: by 10.112.130.129 with SMTP id oe1mr8170077lbb.37.1432911230880; Fri, 29 May 2015 07:53:50 -0700 (PDT) Received: by 10.25.128.206 with HTTP; Fri, 29 May 2015 07:53:50 -0700 (PDT) In-Reply-To: <55683230.3020600@ericsson.com> References: <55683230.3020600@ericsson.com> Date: Fri, 29 May 2015 09:53:50 -0500 Message-ID: From: Mary Barnes To: Magnus Westerlund Content-Type: multipart/alternative; boundary=e89a8f64732fe9526d051739a43a Archived-At: Cc: Ben Campbell , DISPATCH , Barry Leiba Subject: Re: [dispatch] Updated PERC Charter proposal X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 May 2015 14:53:59 -0000 --e89a8f64732fe9526d051739a43a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I hope others can comment on this also. > > G=C3=B6ran Eriksson AP skrev den 2015-05-25 17:10: > >> Hi, >> >> I have some minor comments concerning the meaning of =C2=B3SIP=C2=B2 and= =C2=B3WebRTC=C2=B2 >> endpoints. >> >> Sorry for the late response and for top-posting but it became a bit mess= y >> to add inline: >> >> 1. The link to >> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview/ did not >> work? >> > > It works fine for me. > > 2. The text uses =C2=B3SIP=C2=B2 and =C2=B3WebRTC=C2=B2 to describe the = different kind of >> end-points that are in scope. >> W3C WebRTC WG recognises the fact that the WebRTC end points can be >> browser end points >> (browser + web (client portion of) web app) or native WebRTC (or >> rather >> rtcweb) clients and both are in scope for the W3C WG. >> The browser endpoint trust model is different from that of native >> clients and it is also evolving. >> I think that clarity in how different endpoints trust model and >> security framework look like and different is beneficial for several of >> the deliverables, notably 2,3 and 5. >> > > The use of WebRTC endpoints where deliberate by my and intended to cover > not only browsers but anything meeting the WebRTC endpoint definition. So > the question, does this need to be made more explicit in the charter? [MB] I think this is fine as is in the charter - certainly it needs to be clear in the deliverables but that's a detail we can deal with there. [/MB] > > > >> 3. The charter says it will =C2=B3notify=C2=B2 W3C WebRTC about this act= ivity; what >> do the WG expect to get back and why not =C5=92coordinate=C2=B9? And are= there other >> W3C WG=C2=B9s that are relevant? >> > > I think the expectation is that in the end W3C and likely RTCWEB WG agree= s > to integrate the PERC solution into their specifications so that one can > actually use it with WebRTC. In intermediate step I think it will be a > question of notifying for example when there exist a proposed blue-print > for integration. This may be an example of where coordinate might be need= ed. > > I could see that we could change the last sentence in the collaboration > part from: > "We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and > other related groups about this work." > > to > "We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSIC, > RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work." > > Opinions? > > [MB] I think the suggested change is fine. [/MB] > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > --e89a8f64732fe9526d051739a43a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Fri, May 29, 2015 at 4:32 AM, Magnus Westerlund &l= t;magnu= s.westerlund@ericsson.com> wrote:

Hi,

I hope others can comment on this also.

G=C3=B6ran Eriksson AP skrev den 2015-05-25 17:10:

Hi,

I have some minor comments concerning the meaning of =C2=B3SIP=C2=B2 and = =C2=B3WebRTC=C2=B2
endpoints.

Sorry for the late response and for top-posting but it became a bit messy to add inline:

1. The link to
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-overview= / did not work?

It works fine for me.

2. The text uses =C2=B3SIP=C2=B2 and =C2=B3WebRTC=C2=B2 to describe the dif= ferent kind of
end-points that are in scope.
=C2=A0 =C2=A0 W3C WebRTC WG recognises the fact that the WebRTC end points = can be
browser end points
=C2=A0 =C2=A0 (browser + web (client portion of) web app) or native WebRTC = (or rather
rtcweb) clients and both are in scope for the W3C WG.
=C2=A0 =C2=A0 The browser endpoint trust model is different from that of na= tive
clients and it is also evolving.
=C2=A0 =C2=A0 I think that clarity in how different endpoints trust model a= nd
security framework look like and different is beneficial for several of
the deliverables, notably 2,3 and 5.

The use of WebRTC endpoints where deliberate by my and intended to cover no= t only browsers but anything meeting the WebRTC endpoint definition. So the= question, does this need to be made more explicit in the charter?
[MB] I think this is fine as is in the charter - certainly it need= s to be clear in the deliverables but that's a detail we can deal with = there. [/MB]=C2=A0

3. The charter says it will =C2=B3notify=C2=B2 W3C WebRTC about this activi= ty; what
do the WG expect to get back and why not =C5=92coordinate=C2=B9? And are th= ere other
W3C WG=C2=B9s that are relevant?

I think the expectation is that in the end W3C and likely RTCWEB WG agrees = to integrate the PERC solution into their specifications so that one can ac= tually use it with WebRTC. In intermediate step I think it will be a questi= on of notifying for example when there exist a proposed blue-print for inte= gration. This may be an example of where coordinate might be needed.

I could see that we could change the last sentence in the collaboration par= t from:
"We will notify AVTCore, CLUE, MMUSIC, RTCWEB, SIPREC, W3C WebRTC, and= other related groups about this work."

to
"We will notify, and when needed coordinate with, AVTCore, CLUE, MMUSI= C, RTCWEB, SIPREC, W3C WebRTC, and other related groups about this work.&qu= ot;

Opinions?

[MB] I think the suggested change is fine. [/MB]=C2=A0
= =C2=A0

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

--e89a8f64732fe9526d051739a43a-- From nobody Sun May 31 13:33:50 2015 Return-Path: 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 31A021AC3D5 for ; Sun, 31 May 2015 13:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.701 X-Spam-Level: X-Spam-Status: No, score=-0.701 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 jSdN2ogmIiSl for ; Sun, 31 May 2015 13:33:46 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967671AC3C6 for ; Sun, 31 May 2015 13:33:46 -0700 (PDT) Received: from [192.168.1.11] (chello212186126020.11.vie.surfer.at [::ffff:212.186.126.20]) (AUTH: PLAIN bubestinger@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Sun, 31 May 2015 22:33:42 +0200 id 00000000000000DD.00000000556B7026.00007C62 Message-ID: <556B7026.8050808@das-werkstatt.com> Date: Sun, 31 May 2015 22:33:42 +0200 From: "Peter B." User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <5FF8B7A3-BEB0-4F7B-9825-0F56F193C2D6@cisco.com> <5564D62E.9070506@xiph.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] Standardization of FFV1, Matroska X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 May 2015 20:33:48 -0000 On 05/28/2015 04:24 AM, Ben Campbell wrote: > On 26 May 2015, at 15:23, Timothy B. Terriberry wrote: > >> Cullen Jennings (fluffy) wrote: >>> As a user, I'd like to see well defined specifications for both of >>> these. I think dispatch is a good place to discuss how we could move >>> this work forward. >> >> +1 >> > > (no hats) Also +1. As an early adopter and supporter of FFV1, and since we're using FFV1 for production/preservation at the Austrian Mediathek (national A/V archive), we'd be more than interested in well defined reference specifications, too! So: +3 (=me, plus 2 of my colleagues from the video department) Regards, Peter B.