From roni.even@mail01.huawei.com Wed Sep 5 21:45:31 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FADF21F846F for ; Wed, 5 Sep 2012 21:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0DC6eWToHSDy for ; Wed, 5 Sep 2012 21:45:30 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 1BECC21F8475 for ; Wed, 5 Sep 2012 21:45:28 -0700 (PDT) Received: from szxpml204-edg.exmail.huawei.com ([172.17.1.119]) by hwsga02-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADC00667; Thu, 6 Sep 2012 12:45:23 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml204-edg.exmail.huawei.com 5 none Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml204-edg.exmail.huawei.com (172.24.2.15) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 12:45:20 +0800 Received: from SZXPML504-MBX.exmail.huawei.com ([169.254.3.38]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Thu, 6 Sep 2012 12:45:22 +0800 From: Roni Even To: "avt@ietf.org" Thread-Topic: Help the NomCom: Nominations and Feedback Thread-Index: AQHNi8WUBgOkdSm2xE6b1eACmqdmCpd8vQcP Date: Thu, 6 Sep 2012 04:45:22 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B42198@szxpml504-mbx.exmail.huawei.com> References: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> In-Reply-To: <20120906002129.10667.70960.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [AVTCORE] FW: Help the NomCom: Nominations and Feedback X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Sep 2012 04:45:31 -0000 FYI ________________________________________ From: wgchairs-bounces@ietf.org [wgchairs-bounces@ietf.org] on behalf of No= mCom Chair [nomcom-chair@ietf.org] Sent: Thursday, September 06, 2012 3:21 AM To: Working Group Chairs Subject: Help the NomCom: Nominations and Feedback The IETF Nominations Committee (NomCom) is currently seeking nominations for individuals to serve on the IESG, IAB, and IAOC. Additionally, this is an announcement that the NomCom is seeking feedback on individuals who have accepted nominations for IETF leadership positions. It is very important to the NomCom process that we get input from a broad spectrum of the community. Therefore, in case members of your working group do not read the IETF announcement and discussion lists, the NomCom would appreciate your help in disseminating the following information. The NomCom website contains information about this year's NomCom including the positions we are seeking to fill, and the qualifications required for these positions: https://www.ietf.org/group/nomcom/2012/ The NomCom is accepting nominations until September 24. Nominations for any position can be made using the following web tool: https://www.ietf.org/group/nomcom/2012/nominate Feedback about individuals who the NomCom is considering can be providing using the following web tool: https://www.ietf.org/group/nomcom/2012/input The feedback tool provides a list of individuals who have agreed to be considered for each position. We will be updating this list in the coming weeks as more individuals accept nominations. Feedback provided to the NomCom is kept strictly confidential! Note that use of the NomCom web tools require an ietf.org (i.e., datatracker) account. You can create an ietf.org account by visiting the following URL: https://datatracker.ietf.org/accounts/create/ As an alternative to using the web tools, you can send email to the NomCom at nomcom12@ietf.org to make a nomination or provide input to the committee. Thank you for your help, - Matt Lepinski nomcom-chair@ietf.org= From ron.even.tlv@gmail.com Mon Sep 10 08:33:02 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5AB21F8499 for ; Mon, 10 Sep 2012 08:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ki-eVNI4OAk for ; Mon, 10 Sep 2012 08:33:01 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6786221F86F0 for ; Mon, 10 Sep 2012 08:33:01 -0700 (PDT) Received: by oagk14 with SMTP id k14so668422oag.31 for ; Mon, 10 Sep 2012 08:32:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=ZG2DzX2ik20giDQUeFRQMrGAW4mHjsJtgtumo3okuZY=; b=Rsa8rC0GLduRd643TMEtN4sEdWlEtwy7UTJolHCoV0tfSDV26L1ncnpGiScJP+wBZr oD5beP7P2/qdH61vot9mnVkKebnIwcr2HL0JIUIaEwDWpnKU8g7l02+DE4zgWUAitM+S Hxgag6Z3UJ1MdtQl7DgtqudxLrD3f1VnSHIUpYqsyD3JZwUcOVVcy4UWap+PLTunCtsl pbkiwczjNMrFv9ty475jU3JNwROI5l5XHWehWCrim9QOV63wOzVlnZsw4X4wFh/pP7ze XbnlU2wmT0BRih/pcMSOuCYDH5DRNJ5Ksehgbxy+lGOauyedrCkoUIXD6sxh7pGHdb2J vQXQ== MIME-Version: 1.0 Received: by 10.182.37.41 with SMTP id v9mr14860997obj.23.1347291174623; Mon, 10 Sep 2012 08:32:54 -0700 (PDT) Received: by 10.76.162.2 with HTTP; Mon, 10 Sep 2012 08:32:54 -0700 (PDT) In-Reply-To: <009701cd847a$b92727c0$2b757740$@gmail.com> References: <009701cd847a$b92727c0$2b757740$@gmail.com> Date: Mon, 10 Sep 2012 18:32:54 +0300 Message-ID: From: Ron Even To: avt@ietf.org Content-Type: multipart/alternative; boundary=14dae939969bdf57f704c95aab57 Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Sep 2012 15:33:02 -0000 --14dae939969bdf57f704c95aab57 Content-Type: text/plain; charset=ISO-8859-1 Hi, Plesae review the document Roni On Mon, Aug 27, 2012 at 8:38 PM, Roni Even wrote: > Hi,**** > > I would like to start a second WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-02. > **** > > The draft finished a WGLC and there were comments from the WG chairs. > These comments were addressed but since we did not have enough reviewers we > are asking for more reviews**** > > ** ** > > Please review the documents and send any comments by September 15th**** > > ** ** > > Thanks**** > > Roni Even**** > > AVTCore co-chair**** > --14dae939969bdf57f704c95aab57 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Plesae review the document
Ro= ni

On Mon, Aug 27, 2012 at 8:38 PM,= Roni Even <ron.even.tlv@gmail.com> wrote:
Hi,

I would like to start a second = WGLC on http://tools.ietf.org/html/draft-ietf= -avtcore-srtp-encrypted-header-ext-02 .

The draft finished a WGLC and there were comments fr= om the WG chairs. These comments were addressed but since we did not have e= nough reviewers we are asking for more reviews

=A0

Please review the documents and= send any comments by September 15th

=A0

Thanks=

Roni Even

AV= TCore co-chair


--14dae939969bdf57f704c95aab57-- From internet-drafts@ietf.org Mon Sep 10 18:13:51 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94B0221F8717; Mon, 10 Sep 2012 18:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQg6mWxruPTW; Mon, 10 Sep 2012 18:13:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE4621F86F0; Mon, 10 Sep 2012 18:13:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911011351.20582.84262.idtracker@ietfa.amsl.com> Date: Mon, 10 Sep 2012 18:13:51 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-19.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 01:13:51 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Use of the RTP Monitoring Framework Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-19.txt Pages : 28 Date : 2012-09-10 Abstract: This memo proposes an extensible RTP monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-monarch-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-19 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-ipr@ietf.org Tue Sep 11 13:09:24 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0521F8741; Tue, 11 Sep 2012 13:09:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.437 X-Spam-Level: X-Spam-Status: No, score=-102.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nt2fBZ0Jvg6E; Tue, 11 Sep 2012 13:09:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDFC621F843F; Tue, 11 Sep 2012 13:09:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: stewe@cs.tu-berlin.de X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120911200922.11452.14609.idtracker@ietfa.amsl.com> Date: Tue, 11 Sep 2012 13:09:22 -0700 Cc: avt@ietf.org, ipr-announce@ietf.org Subject: [AVTCORE] IPR Disclosure: Nokia Corporation's Statement about IPR related to RFC 3984 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 20:09:24 -0000 Dear Dr. Stephan Wenger: An IPR disclosure that pertains to your RFC entitled "RTP Payload Format f= or H.264 Video" (RFC3984) was submitted to the IETF Secretariat on 2012-09-11 = and has been posted on the "IETF Page of Intellectual Property Rights Disclosur= es" (https://datatracker.ietf.org/ipr/1877/). The title of the IPR disclosure is "Nokia Corporation's Statement about IPR related to RFC 3984.""); The IETF Secretariat From csp@csperkins.org Tue Sep 11 14:39:25 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24D221E8037 for ; Tue, 11 Sep 2012 14:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sswSbM4EJ0Zx for ; Tue, 11 Sep 2012 14:39:24 -0700 (PDT) Received: from lon1-msapost-1.mail.demon.net (lon1-msapost-1.mail.demon.net [195.173.77.180]) by ietfa.amsl.com (Postfix) with ESMTP id 0B73221F86A8 for ; Tue, 11 Sep 2012 14:39:24 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.12]) by lon1-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1TBYB0-00036a-ZK; Tue, 11 Sep 2012 21:39:23 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_6F472F5A-014F-4DED-9DBB-FDF731D609CC" From: Colin Perkins In-Reply-To: Date: Tue, 11 Sep 2012 22:39:07 +0100 Message-Id: References: <009701cd847a$b92727c0$2b757740$@gmail.com> To: Ron Even X-Mailer: Apple Mail (2.1278) Cc: avt@ietf.org Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2012 21:39:25 -0000 --Apple-Mail=_6F472F5A-014F-4DED-9DBB-FDF731D609CC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Roni, I read the -02 version of the draft. The proposal looks reasonable to = me. Colin On 10 Sep 2012, at 16:32, Ron Even wrote: > Hi, > Plesae review the document > Roni >=20 > On Mon, Aug 27, 2012 at 8:38 PM, Roni Even = wrote: > Hi, >=20 > I would like to start a second WGLC on = http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-02= . >=20 > The draft finished a WGLC and there were comments from the WG chairs. = These comments were addressed but since we did not have enough reviewers = we are asking for more reviews >=20 > =20 >=20 > Please review the documents and send any comments by September 15th >=20 > =20 >=20 > Thanks >=20 > Roni Even >=20 > AVTCore co-chair >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_6F472F5A-014F-4DED-9DBB-FDF731D609CC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
Hi,
Plesae review the = document
Roni

On Mon, = Aug 27, 2012 at 8:38 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,

I would like to start a = second WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encry= pted-header-ext-02 .

The = draft finished a WGLC and there were comments from the WG chairs. These = comments were addressed but since we did not have enough reviewers we = are asking for more reviews

 

Please review the = documents and send any comments by September = 15th

 

Thanks

Roni = Even

AVTCore = co-chair


_______________________________________________
Audio/Video Transport = Core Maintenance
avt@ietf.org
https://www.ietf.org/mail= man/listinfo/avt



-- 
Colin Perkins



= --Apple-Mail=_6F472F5A-014F-4DED-9DBB-FDF731D609CC-- From magnus.westerlund@ericsson.com Wed Sep 12 00:27:32 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB29721F854E for ; Wed, 12 Sep 2012 00:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id roT0+lD-9Np0 for ; Wed, 12 Sep 2012 00:27:30 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6791721F845B for ; Wed, 12 Sep 2012 00:27:29 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-d0-5050395f2dc3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id B6.A3.17130.F5930505; Wed, 12 Sep 2012 09:27:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Wed, 12 Sep 2012 09:27:27 +0200 Message-ID: <5050395E.90004@ericsson.com> Date: Wed, 12 Sep 2012 09:27:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <009701cd847a$b92727c0$2b757740$@gmail.com> In-Reply-To: <009701cd847a$b92727c0$2b757740$@gmail.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VjfeMiDA4Md0LYuXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMXd9ScExjop9rw+yNjDeZ+ti5OSQEDCRWDbnLZQtJnHh3nog m4tDSOAUo8T/qUtYIJzljBKfHy1hBqniFdCUWLzwFFgHi4CqxKPVLWBxNgELiZs/GsHiogLB EpP2b2GBqBeUODnzCZgtIiAgsWL7XzBbWCBI4u+T32D1QgLmEqtmL2YFsTmB5vQ2fmKBuEhS 4s3km2A2s4CexJSrLYwQtrxE89bZzBC92hINTR2sExgFZyFZNwtJyywkLQsYmVcxCucmZuak l5vrpRZlJhcX5+fpFaduYgSG5cEtvw12MG66L3aIUZqDRUmcV091v7+QQHpiSWp2ampBalF8 UWlOavEhRiYOTqkGxuXKvNZiPDsUp9+u0mm1PVnmK+ogm8y6rOVxzwbX1I3zOmviS2+YNK26 leIifcBvS9BP28tqlx7J21uZuO6p4/64ysfm7dHkN4qPFW8l35r257adr2R27cymKpGktw1n zd9uMd7E0nWzkG3NWwPLHj+7kOhfcRZpJ4N1m6tlDG0Omq+aGnlBiaU4I9FQi7moOBEAOwJ4 VRkCAAA= Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 07:27:32 -0000 As Individual, I have review this version and think it is suitable for publication. Mvh Magnus On 2012-08-27 19:38, Roni Even wrote: > Hi, > > I would like to start a second WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-header-ext-02 . > > The draft finished a WGLC and there were comments from the WG chairs. > These comments were addressed but since we did not have enough reviewers > we are asking for more reviews > > > > Please review the documents and send any comments by September 15^th > > > > Thanks > > Roni Even > > AVTCore co-chair > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 mcgrew@cisco.com Wed Sep 12 05:08:12 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25CC221F8584 for ; Wed, 12 Sep 2012 05:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPtvXjPJEQFR for ; Wed, 12 Sep 2012 05:08:11 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id EB63221F8564 for ; Wed, 12 Sep 2012 05:08:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9972; q=dns/txt; s=iport; t=1347451691; x=1348661291; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=4sp0UaJ4zG+E5lKqewQCxPQ9B3X/hjlDx7e17Q71ZPY=; b=Ki1xPHpDFHwVUZZLLN2aBFJb11+imgq2VyjrNkw97ptdUb1qlShvY3zr UL9ymnx7wyUFdmpcVxk49VpZrRVsfcEKvRD1vZqGijO1Ikm1wXc1ozD9v T4X9W1m+qnIjNn1NND8HYRRwnImrkfTLcqNlvxyyK63FMm2/mDYyhlqZC M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACV6UFCtJXG8/2dsb2JhbABFgkuwHwGIVYEHgiABAgQSAXgBCBEDAQIoKBEUCQgCBAESIodcAwwLnAyWYg2JU4otY4ZCA5QKgVWBFIoBgyGBaYJmgVwjGA X-IronPort-AV: E=Sophos;i="4.80,408,1344211200"; d="scan'208,217";a="120763415" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 12 Sep 2012 12:08:10 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8CC8AqF017651 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 12 Sep 2012 12:08:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.001; Wed, 12 Sep 2012 07:08:10 -0500 From: "David McGrew (mcgrew)" To: Ron Even , "avt@ietf.org" Thread-Topic: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext Thread-Index: AQHNkN9FPSdFfPNgyEirfdRzihGPdQ== Date: Wed, 12 Sep 2012 12:08:08 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19178.005 x-tm-as-result: No--49.721100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC75E6DDE6D23mcgrewciscocom_" MIME-Version: 1.0 Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Sep 2012 12:08:12 -0000 --_000_CC75E6DDE6D23mcgrewciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Roni, I've read the new version. I think this is a good idea, and the draft is = well written. I have only a few specific suggestions. Most importantly,= it is not clear (to me, anyway) how the mask is generated. It will be es= sential for interoperability that all of the participants in the session us= e identical values for the mask, but the draft doesn't describe how a recei= ver would know the mask value that the sender has selected. I had expected= that the mask value would be sent as a part of "urn:ietf:params:rtp-hdrext= :encrypt", or something like that. I think this point needs to be clarifie= d in the draft. The header encryption operation is described in a way that would change the= CTR (or f8) encryption operation ("The SRTP participant bitwise-ANDs the e= ncryption mask with the keystream to produce a masked keystream"). Howeve= r, what I hope/expect that implementations will do is implement header encr= yption in a way that does not change any of the crypto functions. The he= ader encryption can be described in terms of manipulations of the plaintext= and ciphertext, like this: EncryptedHeader =3D (Encrypt(Key, Plaintext) AND MASK) OR (Plaintext = AND (NOT MASK)) Many implementations would prefer this approach, because it enables them to= use their encryption functions in a way that is unchanged. For instance,= the crypto function might be implemented in a separate software library, o= r provided by a hardware function; the encryption function might be part of= a validated crypto module, and thus there would be strong motivation not t= o alter it (and undo the validation). The current text in the draft is c= lear, so I don't recommend changing it. But I suggest providing an altern= ative description of the algorithm in a separate paragraph that follows the= current description. The security of the mask-based mechanism is sound, when used with the exist= ing SRTP crypto transforms, as described in Section 3. However, if the me= chanism is applied to other encryption methods, like ECB or CBC, then it wo= uld not be a sound approach. The alternative way of describing the encryp= tion scheme in terms of plaintext manipulations might make it look like the= scheme could be applied to ECB or CBC. So I suggest putting a statement = in the security considerations saying "This technique can only be applied t= o encryption transforms that work by generating a pseudorandom keystream an= d bitwise exclusive-oring it with the plaintext, such as CTR or f8; it MUST= NOT be used with ECB, CBC, or any other encryption method that does not us= e a keystream, or a loss of security will entail." David From: Ron Even > Date: Monday, September 10, 2012 11:32 AM To: "avt@ietf.org" > Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-hea= der-ext Hi, Plesae review the document Roni On Mon, Aug 27, 2012 at 8:38 PM, Roni Even > wrote: Hi, I would like to start a second WGLC on http://tools.ietf.org/html/draft-iet= f-avtcore-srtp-encrypted-header-ext-02 . The draft finished a WGLC and there were comments from the WG chairs. These= comments were addressed but since we did not have enough reviewers we are = asking for more reviews Please review the documents and send any comments by September 15th Thanks Roni Even AVTCore co-chair --_000_CC75E6DDE6D23mcgrewciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Roni,

I've read the new version.   I think this is a good idea, and the= draft is well written.   I have only a few specific suggestions. &nbs= p; Most importantly, it is not clear (to me, anyway) how the mask is genera= ted.   It will be essential for interoperability that all of the participants in the session use identical values for the m= ask, but the draft doesn't describe how a receiver would know the mask valu= e that the sender has selected.  I had expected that the mask value wo= uld be sent as a part of "urn:ietf:params:rtp-hdrext:encrypt", or something like that.  I think this point needs to be clarified in = the draft.  

The header encryption operation is described in a way that would chang= e the CTR (or f8) encryption operation ("The SRTP participant bitwise-= ANDs the encryption mask with the keystream to produce a masked keystr= eam").   However, what I hope/expect that implementations will do is implement header encryption in a way that does = not change any of the crypto functions.    The header encryption = can be described in terms of manipulations of the plaintext and ciphertext,= like this:

    EncryptedHeader =3D (Encrypt(Key, Plaintext)  AND M= ASK)  OR (Plaintext AND (NOT MASK))

Many implementations would prefer this approach, because it enables th= em to use their encryption functions in a way that is unchanged.   For= instance, the crypto function might be implemented in a separate software = library, or provided by a hardware function; the encryption function might be part of a validated crypto module, and th= us there would be strong motivation not to alter it (and undo the validatio= n).    The current text in the draft is clear, so I don't recomme= nd changing it.   But I suggest providing an alternative description of the algorithm in a separate paragraph that f= ollows the current description.  

The security of the mask-based mechanism is sound, when used with the = existing SRTP crypto transforms, as described in Section 3.   However,= if the mechanism is applied to other encryption methods, like ECB or CBC, = then it would not be a sound approach.   The alternative way of describing the encryption scheme in terms of= plaintext manipulations might make it look like the scheme could be applie= d to ECB or CBC.   So I suggest putting a statement in the security co= nsiderations saying "This technique can only be applied to encryption transforms that work by generating a pseudorandom= keystream and bitwise exclusive-oring it with the plaintext, such as CTR o= r f8; it MUST NOT be used with ECB, CBC, or any other encryption method tha= t does not use a keystream, or a loss of security will entail." 

David

From: Ron Even <ron.even.tlv@gmail.com>
Date: Monday, September 10, 2012 11= :32 AM
To: "avt@ietf.org" <avt@ietf.= org>
Subject: Re: [AVTCORE] Second WGLC = on draft-ietf-avtcore-srtp-encrypted-header-ext

 --_000_CC75E6DDE6D23mcgrewciscocom_-- From ray.vanbrandenburg@tno.nl Thu Sep 13 00:05:01 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CBD21E8037 for ; Thu, 13 Sep 2012 00:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqHOuogtDhNu for ; Thu, 13 Sep 2012 00:05:00 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id EA74F21E8039 for ; Thu, 13 Sep 2012 00:04:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,415,1344204000"; d="scan'208,217";a="16234994" Received: from unknown (HELO mail.tno.nl) ([134.221.225.221]) by mailhost1b.tno.nl with ESMTP; 13 Sep 2012 09:04:50 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.243]) by EXC-CASHUB02.tsn.tno.nl ([134.221.225.221]) with mapi id 14.02.0298.004; Thu, 13 Sep 2012 09:04:49 +0200 From: "Brandenburg, R. (Ray) van" To: Ron Even , "avt@ietf.org" Thread-Topic: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext Thread-Index: Ac2EejHhiI5me+oXTBmO+PlMv8LH2QK3pYsAAIlMeNA= Date: Thu, 13 Sep 2012 07:04:49 +0000 Message-ID: References: <009701cd847a$b92727c0$2b757740$@gmail.com> In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581C6B3DF8EXCMBX03tsntnon_" MIME-Version: 1.0 Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Sep 2012 07:05:01 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581C6B3DF8EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Roni, I have reviewed this document and think it is ready for publication. Ray From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ron E= ven Sent: maandag 10 september 2012 17:33 To: avt@ietf.org Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-hea= der-ext Hi, Plesae review the document Roni On Mon, Aug 27, 2012 at 8:38 PM, Roni Even > wrote: Hi, I would like to start a second WGLC on http://tools.ietf.org/html/draft-iet= f-avtcore-srtp-encrypted-header-ext-02 . The draft finished a WGLC and there were comments from the WG chairs. These= comments were addressed but since we did not have enough reviewers we are = asking for more reviews Please review the documents and send any comments by September 15th Thanks Roni Even AVTCore co-chair This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581C6B3DF8EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Roni,

 = ;

I have rev= iewed this document and think it is ready for publication.

 = ;

Ray

 = ;

From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ron Even
Sent: maandag 10 september 2012 17:33
To: avt@ietf.org
Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encryp= ted-header-ext

 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581C6B3DF8EXCMBX03tsntnon_-- From bill.wu@huawei.com Thu Sep 13 22:39:05 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B3821F8710 for ; Thu, 13 Sep 2012 22:39:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.452 X-Spam-Level: X-Spam-Status: No, score=-5.452 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY0wE3vM9NjT for ; Thu, 13 Sep 2012 22:39:04 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 232FE21F86FE for ; Thu, 13 Sep 2012 22:39:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJQ74548; Fri, 14 Sep 2012 05:39:03 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 06:38:17 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 06:38:32 +0100 Received: from w53375 (10.138.41.149) by szxeml420-hub.china.huawei.com (10.82.67.159) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 14 Sep 2012 13:38:24 +0800 Message-ID: From: Qin Wu To: Ron Even , References: <009701cd847a$b92727c0$2b757740$@gmail.com> Date: Fri, 14 Sep 2012 13:38:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0300_01CD927E.3622B030" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] Second WGLC ondraft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 05:39:05 -0000 ------=_NextPart_000_0300_01CD927E.3622B030 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: base64 SSBoYXZlIG5vIGNvbW1lbnRzIGFuZCB0aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24u DQoNClJlZ2FyZHMhDQotUWluDQogIC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIEZy b206IFJvbiBFdmVuIA0KICBUbzogYXZ0QGlldGYub3JnIA0KICBTZW50OiBNb25kYXksIFNlcHRl bWJlciAxMCwgMjAxMiAxMTozMiBQTQ0KICBTdWJqZWN0OiBSZTogW0FWVENPUkVdIFNlY29uZCBX R0xDIG9uZHJhZnQtaWV0Zi1hdnRjb3JlLXNydHAtZW5jcnlwdGVkLWhlYWRlci1leHQNCg0KDQog IEhpLA0KICBQbGVzYWUgcmV2aWV3IHRoZSBkb2N1bWVudA0KICBSb25pDQoNCg0KICBPbiBNb24s IEF1ZyAyNywgMjAxMiBhdCA4OjM4IFBNLCBSb25pIEV2ZW4gPHJvbi5ldmVuLnRsdkBnbWFpbC5j b20+IHdyb3RlOg0KDQogICAgSGksDQoNCiAgICBJIHdvdWxkIGxpa2UgdG8gc3RhcnQgYSBzZWNv bmQgV0dMQyBvbiBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUt c3J0cC1lbmNyeXB0ZWQtaGVhZGVyLWV4dC0wMiAuDQoNCiAgICBUaGUgZHJhZnQgZmluaXNoZWQg YSBXR0xDIGFuZCB0aGVyZSB3ZXJlIGNvbW1lbnRzIGZyb20gdGhlIFdHIGNoYWlycy4gVGhlc2Ug Y29tbWVudHMgd2VyZSBhZGRyZXNzZWQgYnV0IHNpbmNlIHdlIGRpZCBub3QgaGF2ZSBlbm91Z2gg cmV2aWV3ZXJzIHdlIGFyZSBhc2tpbmcgZm9yIG1vcmUgcmV2aWV3cw0KDQoNCg0KICAgIFBsZWFz ZSByZXZpZXcgdGhlIGRvY3VtZW50cyBhbmQgc2VuZCBhbnkgY29tbWVudHMgYnkgU2VwdGVtYmVy IDE1dGgNCg0KDQoNCiAgICBUaGFua3MNCg0KICAgIFJvbmkgRXZlbg0KDQogICAgQVZUQ29yZSBj by1jaGFpcg0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQoNCiAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgQXVkaW8vVmlkZW8gVHJh bnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCiAgYXZ0QGlldGYub3JnDQogIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo= ------=_NextPart_000_0300_01CD927E.3622B030 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWlz by04ODU5LTEiIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlPg0KPE1FVEEgbmFtZT1HRU5FUkFUT1Ig Y29udGVudD0iTVNIVE1MIDguMDAuNjAwMS4xOTI1OCI+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+SSBoYXZlIG5vIGNvbW1lbnRzIGFuZCB0 aGluayBpdCBpcyByZWFkeSBmb3IgcHVibGljYXRpb24uPC9ESVY+DQo8RElWPiZuYnNwOzwvRElW Pg0KPERJVj5SZWdhcmRzITwvRElWPg0KPERJVj4tUWluPC9ESVY+DQo8QkxPQ0tRVU9URSANCnN0 eWxlPSJCT1JERVItTEVGVDogIzAwMDAwMCAycHggc29saWQ7IFBBRERJTkctTEVGVDogNXB4OyBQ QURESU5HLVJJR0hUOiAwcHg7IE1BUkdJTi1MRUZUOiA1cHg7IE1BUkdJTi1SSUdIVDogMHB4Ij4N CiAgPERJViBzdHlsZT0iRk9OVDogOXB0ICYjMjM0MzU7JiMyMDMwNzsiPi0tLS0tIE9yaWdpbmFs IE1lc3NhZ2UgLS0tLS0gPC9ESVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYj MjAzMDc7OyBCQUNLR1JPVU5EOiAjZTRlNGU0OyBmb250LWNvbG9yOiBibGFjayI+PEI+RnJvbTo8 L0I+IA0KICA8QSB0aXRsZT1yb24uZXZlbi50bHZAZ21haWwuY29tIGhyZWY9Im1haWx0bzpyb24u ZXZlbi50bHZAZ21haWwuY29tIj5Sb24gDQogIEV2ZW48L0E+IDwvRElWPg0KICA8RElWIHN0eWxl PSJGT05UOiA5cHQgJiMyMzQzNTsmIzIwMzA3OyI+PEI+VG86PC9CPiA8QSB0aXRsZT1hdnRAaWV0 Zi5vcmcgDQogIGhyZWY9Im1haWx0bzphdnRAaWV0Zi5vcmciPmF2dEBpZXRmLm9yZzwvQT4gPC9E SVY+DQogIDxESVYgc3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TZW50Ojwv Qj4gTW9uZGF5LCBTZXB0ZW1iZXIgMTAsIDIwMTIgMTE6MzIgDQogIFBNPC9ESVY+DQogIDxESVYg c3R5bGU9IkZPTlQ6IDlwdCAmIzIzNDM1OyYjMjAzMDc7Ij48Qj5TdWJqZWN0OjwvQj4gUmU6IFtB VlRDT1JFXSBTZWNvbmQgV0dMQyANCiAgb25kcmFmdC1pZXRmLWF2dGNvcmUtc3J0cC1lbmNyeXB0 ZWQtaGVhZGVyLWV4dDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJViBkaXI9bHRyPg0K ICA8RElWPkhpLDwvRElWPg0KICA8RElWPlBsZXNhZSByZXZpZXcgdGhlIGRvY3VtZW50PC9ESVY+ DQogIDxESVY+Um9uaTxCUj48QlI+PC9ESVY+DQogIDxESVYgY2xhc3M9Z21haWxfcXVvdGU+T24g TW9uLCBBdWcgMjcsIDIwMTIgYXQgODozOCBQTSwgUm9uaSBFdmVuIDxTUEFOIA0KICBkaXI9bHRy PiZsdDs8QSBocmVmPSJtYWlsdG86cm9uLmV2ZW4udGx2QGdtYWlsLmNvbSIgDQogIHRhcmdldD1f Ymxhbms+cm9uLmV2ZW4udGx2QGdtYWlsLmNvbTwvQT4mZ3Q7PC9TUEFOPiB3cm90ZTo8QlI+DQog IDxCTE9DS1FVT1RFIA0KICBzdHlsZT0iQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4 IHNvbGlkOyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBQQURESU5HLUxFRlQ6IDFleCIgDQog IGNsYXNzPWdtYWlsX3F1b3RlPg0KICAgIDxESVYgbGFuZz1FTi1VUyBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCiAgICA8RElWPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD5IaSw8VT48L1U+ PFU+PC9VPjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+SSB3b3VsZCBsaWtlIHRvIHN0YXJ0 IGEgc2Vjb25kIFdHTEMgb24gPEEgDQogICAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1hdnRjb3JlLXNydHAtZW5jcnlwdGVkLWhlYWRlci1leHQtMDIiIA0KICAg IHRhcmdldD1fYmxhbms+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1hdnRj b3JlLXNydHAtZW5jcnlwdGVkLWhlYWRlci1leHQtMDI8L0E+IA0KICAgIC48VT48L1U+PFU+PC9V PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+VGhlIGRyYWZ0IGZpbmlzaGVkIGEgV0dMQyBh bmQgdGhlcmUgd2VyZSBjb21tZW50cyBmcm9tIA0KICAgIHRoZSBXRyBjaGFpcnMuIFRoZXNlIGNv bW1lbnRzIHdlcmUgYWRkcmVzc2VkIGJ1dCBzaW5jZSB3ZSBkaWQgbm90IGhhdmUgDQogICAgZW5v dWdoIHJldmlld2VycyB3ZSBhcmUgYXNraW5nIGZvciBtb3JlIHJldmlld3M8VT48L1U+PFU+PC9V PjwvUD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+PFU+PC9VPjxVPjwvVT4mbmJzcDs8L1A+DQog ICAgPFAgY2xhc3M9TXNvTm9ybWFsPlBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50cyBhbmQgc2Vu ZCBhbnkgY29tbWVudHMgYnkgDQogICAgU2VwdGVtYmVyIDE1PFNVUD50aDxVPjwvVT48VT48L1U+ PC9TVVA+PC9QPg0KICAgIDxQIGNsYXNzPU1zb05vcm1hbD48VT48L1U+PFU+PC9VPiZuYnNwOzwv UD4NCiAgICA8UCBjbGFzcz1Nc29Ob3JtYWw+VGhhbmtzPFU+PC9VPjxVPjwvVT48L1A+DQogICAg PFAgY2xhc3M9TXNvTm9ybWFsPlJvbmkgRXZlbjxVPjwvVT48VT48L1U+PC9QPg0KICAgIDxQIGNs YXNzPU1zb05vcm1hbD5BVlRDb3JlIA0KICBjby1jaGFpcjxVPjwvVT48VT48L1U+PC9QPjwvRElW PjwvRElWPjwvQkxPQ0tRVU9URT48L0RJVj48QlI+PC9ESVY+DQogIDxQPg0KICA8SFI+DQoNCiAg PFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJS PkF1ZGlvL1ZpZGVvIA0KICBUcmFuc3BvcnQgQ29yZSANCiAgTWFpbnRlbmFuY2U8QlI+YXZ0QGll dGYub3JnPEJSPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0PEJSPjwv QkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0300_01CD927E.3622B030-- From internet-drafts@ietf.org Fri Sep 14 02:19:35 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DA921F8555; Fri, 14 Sep 2012 02:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.585 X-Spam-Level: X-Spam-Status: No, score=-102.585 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aorgQ-QTu13W; Fri, 14 Sep 2012 02:19:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63B021F8458; Fri, 14 Sep 2012 02:19:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120914091934.28584.55385.idtracker@ietfa.amsl.com> Date: Fri, 14 Sep 2012 02:19:34 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-20.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 09:19:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Use of the RTP Monitoring Framework Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-20.txt Pages : 29 Date : 2012-09-14 Abstract: This memo proposes an extensible Real-Time Protocol (RTP) monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-monarch-20 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-20 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jonathan@vidyo.com Fri Sep 14 09:38:29 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01C3421F84A1 for ; Fri, 14 Sep 2012 09:38:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hLKpjPCJXh-C for ; Fri, 14 Sep 2012 09:38:28 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.241]) by ietfa.amsl.com (Postfix) with ESMTP id ECEAF21F8497 for ; Fri, 14 Sep 2012 09:38:27 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8E105416A02; Fri, 14 Sep 2012 12:38:34 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB023.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 8A911416A15; Fri, 14 Sep 2012 12:38:06 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB023.mail.lan ([10.110.17.23]) with mapi; Fri, 14 Sep 2012 12:37:58 -0400 From: Jonathan Lennox To: "David McGrew (mcgrew)" Date: Fri, 14 Sep 2012 12:37:57 -0400 Thread-Topic: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext Thread-Index: Ac2Slz1HoeXSyS2hQwO7C1DMmJPR3g== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_A50628D795F9461EA112122EEC5EF7F0vidyocom_" MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 16:38:29 -0000 --_000_A50628D795F9461EA112122EEC5EF7F0vidyocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, David -- thanks for your comments! On Sep 12, 2012, at 8:08 AM, David McGrew (mcgrew) wrote: I've read the new version. I think this is a good idea, and the draft is = well written. I have only a few specific suggestions. Most importantly,= it is not clear (to me, anyway) how the mask is generated. It will be es= sential for interoperability that all of the participants in the session us= e identical values for the mask, but the draft doesn't describe how a recei= ver would know the mask value that the sender has selected. I had expected= that the mask value would be sent as a part of "urn:ietf:params:rtp-hdrext= :encrypt", or something like that. I think this point needs to be clarifie= d in the draft. Since the header extension elements' header bytes are sent in the clear, th= e mask can be calculated for each packet. You know from the SDP which head= er extension IDs correspond to encrypted elements. When you parse a header= extension, you see the ID and length for each header extension element, an= d calculate the mask accordingly. The mask can differ on a packet-by-packet basis, since different header ext= ension elements (either encrypted or plaintext) can be sent in different pa= ckets. I can clarify this in the text, if you think it would be helpful. The header encryption operation is described in a way that would change the= CTR (or f8) encryption operation ("The SRTP participant bitwise-ANDs the e= ncryption mask with the keystream to produce a masked keystream"). Howeve= r, what I hope/expect that implementations will do is implement header encr= yption in a way that does not change any of the crypto functions. The he= ader encryption can be described in terms of manipulations of the plaintext= and ciphertext, like this: EncryptedHeader =3D (Encrypt(Key, Plaintext) AND MASK) OR (Plaintext = AND (NOT MASK)) Many implementations would prefer this approach, because it enables them to= use their encryption functions in a way that is unchanged. For instance,= the crypto function might be implemented in a separate software library, o= r provided by a hardware function; the encryption function might be part of= a validated crypto module, and thus there would be strong motivation not t= o alter it (and undo the validation). The current text in the draft is c= lear, so I don't recommend changing it. But I suggest providing an altern= ative description of the algorithm in a separate paragraph that follows the= current description. That's a good idea. I think an earlier version of the draft may have prese= nted it in the alternate way you suggest; but I agree, giving both descript= ions, and making it clear that they're equivalent, would probably be helpfu= l. The security of the mask-based mechanism is sound, when used with the exist= ing SRTP crypto transforms, as described in Section 3. However, if the me= chanism is applied to other encryption methods, like ECB or CBC, then it wo= uld not be a sound approach. The alternative way of describing the encryp= tion scheme in terms of plaintext manipulations might make it look like the= scheme could be applied to ECB or CBC. So I suggest putting a statement = in the security considerations saying "This technique can only be applied t= o encryption transforms that work by generating a pseudorandom keystream an= d bitwise exclusive-oring it with the plaintext, such as CTR or f8; it MUST= NOT be used with ECB, CBC, or any other encryption method that does not us= e a keystream, or a loss of security will entail." I agree, good idea. Thanks! -- Jonathan Lennox jonathan@vidyo.com --_000_A50628D795F9461EA112122EEC5EF7F0vidyocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi, David -- thanks f= or your comments!

On Sep 12, 2012, at 8:08 AM, David McG= rew (mcgrew) wrote:

I've read the new version.   I think this is a good idea, and the= draft is well written.   I have only a few specific suggestions. &nbs= p; Most importantly, it is not clear (to me, anyway) how the mask is genera= ted.   It will be essential for interoperability that all of the participants in the session use identical values for the m= ask, but the draft doesn't describe how a receiver would know the mask valu= e that the sender has selected.  I had expected that the mask value wo= uld be sent as a part of "urn:ietf:params:rtp-hdrext:encrypt", or something like that.  I think this point needs to be clarified in = the draft.  

Since the hea= der extension elements' header bytes are sent in the clear, the mask can be= calculated for each packet.  You know from the SDP which header exten= sion IDs correspond to encrypted elements.  When you parse a header ex= tension, you see the ID and length for each header extension element, and c= alculate the mask accordingly.

The mask can differ= on a packet-by-packet basis, since different header extension elements (ei= ther encrypted or plaintext) can be sent in different packets.
I can clarify this in the text, if you think it would be helpf= ul.

The header encryption operation is described in a way that would chang= e the CTR (or f8) encryption operation ("The SRTP participant bitwise-ANDs = the encryption mask with the keystream to produce a masked keystream")= .   However, what I hope/expect that implementations will do is implement header encryption in a way that does = not change any of the crypto functions.    The header encryption = can be described in terms of manipulations of the plaintext and ciphertext,= like this:

    EncryptedHeader =3D (Encrypt(Key, Plaintext)  AND M= ASK)  OR (Plaintext AND (NOT MASK))

Many implementations would prefer this approach, because it enables th= em to use their encryption functions in a way that is unchanged.   For= instance, the crypto function might be implemented in a separate software = library, or provided by a hardware function; the encryption function might be part of a validated crypto module, and th= us there would be strong motivation not to alter it (and undo the validatio= n).    The current text in the draft is clear, so I don't recomme= nd changing it.   But I suggest providing an alternative description of the algorithm in a separate paragraph that f= ollows the current description.  

That's a good idea.  I think an earlier version of the draft m= ay have presented it in the alternate way you suggest; but I agree, giving = both descriptions, and making it clear that they're equivalent, would proba= bly be helpful.


The security of the mask-based mechanism is sound, when used with the = existing SRTP crypto transforms, as described in Section 3.   However,= if the mechanism is applied to other encryption methods, like ECB or CBC, = then it would not be a sound approach.   The alternative way of describing the encryption scheme in terms of= plaintext manipulations might make it look like the scheme could be applie= d to ECB or CBC.   So I suggest putting a statement in the security co= nsiderations saying "This technique can only be applied to encryption transforms that work by generating a pseudorandom= keystream and bitwise exclusive-oring it with the plaintext, such as CTR o= r f8; it MUST NOT be used with ECB, CBC, or any other encryption method tha= t does not use a keystream, or a loss of security will entail." 

I agree, good idea.

Thanks!

=
= --_000_A50628D795F9461EA112122EEC5EF7F0vidyocom_-- From mcgrew@cisco.com Fri Sep 14 10:01:46 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEA321F8528 for ; Fri, 14 Sep 2012 10:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yqDTbWHArFSU for ; Fri, 14 Sep 2012 10:01:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id B66F021F851C for ; Fri, 14 Sep 2012 10:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14018; q=dns/txt; s=iport; t=1347642105; x=1348851705; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=bAkg3ug2jnqDpG6YnCIp2zponlsPziAc1wAymsH7HNQ=; b=D2H34KiLVnLaLXN0/PO4k545CJXc9HW1axx6mKbw1PVQgkN5wamnQ/OW z8pBWxx8bLeEcunIUaxw9d5a3EjgbgQLz1H1LXehIGw/jd5F8gF2nvpWV +lb+ynYlFLngQjdTNHEY63qtdfi2rtemU4CdrRaXVL3UIa868Kt20fU4F A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHdiU1CtJXG//2dsb2JhbABFgku5M4EHgiABAgQSAWYSAQgRAwECKCgRFAkIAgQOBSKHXAMMm0+WPA2JU4oyY4ZoA5QMgVWLF4MhgWmCZoFcIxg X-IronPort-AV: E=Sophos;i="4.80,423,1344211200"; d="scan'208,217";a="118697393" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 14 Sep 2012 17:01:45 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8EH1i1F003407 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Sep 2012 17:01:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.159]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.001; Fri, 14 Sep 2012 12:01:44 -0500 From: "David McGrew (mcgrew)" To: Jonathan Lennox Thread-Topic: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext Thread-Index: AQHNkN9FPSdFfPNgyEirfdRzihGPdZeKYKqA///DlAA= Date: Fri, 14 Sep 2012 17:01:43 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.1.120420 x-originating-ip: [10.117.10.227] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19182.004 x-tm-as-result: No--59.245600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_CC78D7BBF5BF7mcgrewciscocom_" MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-header-ext X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Sep 2012 17:01:47 -0000 --_000_CC78D7BBF5BF7mcgrewciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Jonathan, From: Jonathan Lennox > Date: Friday, September 14, 2012 12:37 PM To: Cisco Employee > Cc: Ron Even >, "avt@= ietf.org" > Subject: Re: [AVTCORE] Second WGLC on draft-ietf-avtcore-srtp-encrypted-hea= der-ext Hi, David -- thanks for your comments! On Sep 12, 2012, at 8:08 AM, David McGrew (mcgrew) wrote: I've read the new version. I think this is a good idea, and the draft is = well written. I have only a few specific suggestions. Most importantly,= it is not clear (to me, anyway) how the mask is generated. It will be es= sential for interoperability that all of the participants in the session us= e identical values for the mask, but the draft doesn't describe how a recei= ver would know the mask value that the sender has selected. I had expected= that the mask value would be sent as a part of "urn:ietf:params:rtp-hdrext= :encrypt", or something like that. I think this point needs to be clarifie= d in the draft. Since the header extension elements' header bytes are sent in the clear, th= e mask can be calculated for each packet. You know from the SDP which head= er extension IDs correspond to encrypted elements. When you parse a header= extension, you see the ID and length for each header extension element, an= d calculate the mask accordingly. That makes sense. I went back for a second look at the draft, and I reali= zed that this was my stumbling block: I did not keep in mind the fact that = "The encryption mask corresponds to the entire payload of each header exten= sion element that is encrypted." I was (incorrectly) thinking that a mask= might cover only part of a payload for a particular header extension. The mask can differ on a packet-by-packet basis, since different header ext= ension elements (either encrypted or plaintext) can be sent in different pa= ckets. I can clarify this in the text, if you think it would be helpful. That might be useful (though I am the only person that got confused on this= point :-) The header encryption operation is described in a way that would change the= CTR (or f8) encryption operation ("The SRTP participant bitwise-ANDs the e= ncryption mask with the keystream to produce a masked keystream"). Howeve= r, what I hope/expect that implementations will do is implement header encr= yption in a way that does not change any of the crypto functions. The he= ader encryption can be described in terms of manipulations of the plaintext= and ciphertext, like this: EncryptedHeader =3D (Encrypt(Key, Plaintext) AND MASK) OR (Plaintext = AND (NOT MASK)) Many implementations would prefer this approach, because it enables them to= use their encryption functions in a way that is unchanged. For instance,= the crypto function might be implemented in a separate software library, o= r provided by a hardware function; the encryption function might be part of= a validated crypto module, and thus there would be strong motivation not t= o alter it (and undo the validation). The current text in the draft is c= lear, so I don't recommend changing it. But I suggest providing an altern= ative description of the algorithm in a separate paragraph that follows the= current description. That's a good idea. I think an earlier version of the draft may have prese= nted it in the alternate way you suggest; but I agree, giving both descript= ions, and making it clear that they're equivalent, would probably be helpfu= l. The security of the mask-based mechanism is sound, when used with the exist= ing SRTP crypto transforms, as described in Section 3. However, if the me= chanism is applied to other encryption methods, like ECB or CBC, then it wo= uld not be a sound approach. The alternative way of describing the encryp= tion scheme in terms of plaintext manipulations might make it look like the= scheme could be applied to ECB or CBC. So I suggest putting a statement = in the security considerations saying "This technique can only be applied t= o encryption transforms that work by generating a pseudorandom keystream an= d bitwise exclusive-oring it with the plaintext, such as CTR or f8; it MUST= NOT be used with ECB, CBC, or any other encryption method that does not us= e a keystream, or a loss of security will entail." I agree, good idea. Sounds good. Let's make this an RFC. David Thanks! -- Jonathan Lennox jonathan@vidyo.com --_000_CC78D7BBF5BF7mcgrewciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <2B57D207B35D9C42BFBCD7A6A61BC7B2@cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Jonathan,

From: Jonathan Lennox <jonathan@vidyo.com>
Date: Friday, September 14, 2012 12= :37 PM
To: Cisco Employee <mcgrew@cisco.com>
Cc: Ron Even <ron.even.tlv@gmail.com>, "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] Second WGLC = on draft-ietf-avtcore-srtp-encrypted-header-ext

Hi, David -- thanks for your comments!

On Sep 12, 2012, at 8:08 AM, David McGrew (mcgrew) wrote:

I've read the new version.   I think this is a good idea, and the= draft is well written.   I have only a few specific suggestions. &nbs= p; Most importantly, it is not clear (to me, anyway) how the mask is genera= ted.   It will be essential for interoperability that all of the participants in the session use identical values for the m= ask, but the draft doesn't describe how a receiver would know the mask valu= e that the sender has selected.  I had expected that the mask value wo= uld be sent as a part of "urn:ietf:params:rtp-hdrext:encrypt", or something like that.  I think this point needs to be clarified in = the draft.  

Since the header extension elements' header bytes are sent in the clea= r, the mask can be calculated for each packet.  You know from the SDP = which header extension IDs correspond to encrypted elements.  When you= parse a header extension, you see the ID and length for each header extension element, and calculate the mask accor= dingly.

That makes sense.   I went back for a second look at the draft, a= nd I realized that this was my stumbling block: I did not keep in mind the = fact that "The encryption mask corresponds to the entire payload = of each header extension element that is encrypted."   I was (incorrectly) thinking that a mask might cover only part of a= payload for a particular header extension.  


The mask can differ on a packet-by-packet basis, since different heade= r extension elements (either encrypted or plaintext) can be sent in differe= nt packets.

I can clarify this in the text, if you think it would be helpful.

That might be useful (though I am the only person that got confused on= this point :-)   


The header encryption operation is described in a way that would chang= e the CTR (or f8) encryption operation ("The SRTP participant bitwise-= ANDs the encryption mask with the keystream to produce a masked keystr= eam").   However, what I hope/expect that implementations will do is implement header encryption in a way that does = not change any of the crypto functions.    The header encryption = can be described in terms of manipulations of the plaintext and ciphertext,= like this:

    EncryptedHeader =3D (Encrypt(Key, Plaintext)  AND M= ASK)  OR (Plaintext AND (NOT MASK))

Many implementations would prefer this approach, because it enables th= em to use their encryption functions in a way that is unchanged.   For= instance, the crypto function might be implemented in a separate software = library, or provided by a hardware function; the encryption function might be part of a validated crypto module, and th= us there would be strong motivation not to alter it (and undo the validatio= n).    The current text in the draft is clear, so I don't recomme= nd changing it.   But I suggest providing an alternative description of the algorithm in a separate paragraph that f= ollows the current description.  

That's a good idea.  I think an earlier version of the draft may = have presented it in the alternate way you suggest; but I agree, giving bot= h descriptions, and making it clear that they're equivalent, would probably= be helpful.


The security of the mask-based mechanism is sound, when used with the = existing SRTP crypto transforms, as described in Section 3.   However,= if the mechanism is applied to other encryption methods, like ECB or CBC, = then it would not be a sound approach.   The alternative way of describing the encryption scheme in terms of= plaintext manipulations might make it look like the scheme could be applie= d to ECB or CBC.   So I suggest putting a statement in the security co= nsiderations saying "This technique can only be applied to encryption transforms that work by generating a pseudorandom= keystream and bitwise exclusive-oring it with the plaintext, such as CTR o= r f8; it MUST NOT be used with ECB, CBC, or any other encryption method tha= t does not use a keystream, or a loss of security will entail." 

I agree, good idea.

Sounds good.   Let's make this an RFC.

David


Thanks!

--
Jonathan Lennox
jonathan@vidyo.com


 --_000_CC78D7BBF5BF7mcgrewciscocom_-- From internet-drafts@ietf.org Tue Sep 18 05:58:38 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F8921E80B1; Tue, 18 Sep 2012 05:58:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efvz8oglyU9F; Tue, 18 Sep 2012 05:58:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 618BB21F86FC; Tue, 18 Sep 2012 05:58:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120918125837.22816.25141.idtracker@ietfa.amsl.com> Date: Tue, 18 Sep 2012 05:58:37 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-srtp-aes-gcm-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Sep 2012 12:58:38 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : AES-GCM and AES-CCM Authenticated Encryption in Secure R= TP (SRTP) Author(s) : David A. McGrew Kevin M. Igoe Filename : draft-ietf-avtcore-srtp-aes-gcm-03.txt Pages : 27 Date : 2012-09-18 Abstract: This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-srtp-aes-gcm There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-srtp-aes-gcm-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-srtp-aes-gcm-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Sep 20 20:33:12 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A86921F84F9; Thu, 20 Sep 2012 20:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.483 X-Spam-Level: X-Spam-Status: No, score=-102.483 tagged_above=-999 required=5 tests=[AWL=0.116, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSPKCty11puI; Thu, 20 Sep 2012 20:33:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A490E21F84A7; Thu, 20 Sep 2012 20:33:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> Date: Thu, 20 Sep 2012 20:33:11 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 03:33:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Use of the RTP Monitoring Framework Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-21.txt Pages : 29 Date : 2012-09-20 Abstract: This memo proposes an extensible Real-Time Protocol (RTP) monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-monarch-21 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-21 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From csp@csperkins.org Fri Sep 21 02:38:58 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6968521F8720 for ; Fri, 21 Sep 2012 02:38:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IQyKlSjCs54G for ; Fri, 21 Sep 2012 02:38:57 -0700 (PDT) Received: from lon1-msapost-2.mail.demon.net (lon1-msapost-2.mail.demon.net [195.173.77.181]) by ietfa.amsl.com (Postfix) with ESMTP id 890C421F8723 for ; Fri, 21 Sep 2012 02:38:57 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1TEzhI-0002vQ-an for avt@ietf.org; Fri, 21 Sep 2012 09:38:56 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1283) From: Colin Perkins In-Reply-To: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> Date: Fri, 21 Sep 2012 10:38:55 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org> References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> To: "avt@ietf.org WG" X-Mailer: Apple Mail (2.1283) Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:38:58 -0000 On 21 Sep 2012, at 04:33, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Audio/Video Transport Core = Maintenance Working Group of the IETF. >=20 > Title : Guidelines for Use of the RTP Monitoring = Framework > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-21.txt > Pages : 29 > Date : 2012-09-20 >=20 > Abstract: > This memo proposes an extensible Real-Time Protocol (RTP) monitoring > framework for extending RTP Control Protocol (RTCP) with a new RTCP > Extended Reports (XR) block type to report new metrics regarding > media transmission or reception quality. In this framework, a new = XR > block should contain a single metric or a small number of metrics > relevant to a single parameter of interest or concern, rather than > containing a number of metrics which attempt to provide full = coverage > of all those parameters of concern to a specific application. > Applications may then "mix and match" to create a set of blocks = which > covers their set of concerns. Where possible, a specific block > should be designed to be re-usable across more than one application, > for example, for all of voice, streaming audio and video. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch I'm a little confused by the changes to this draft. The last paragraph = of the Introduction now has a strong focus on definition of new metrics, = and explicitly refers to the RFC 6390 guidelines for defining new = metrics. However, we've been pretty consistent that new RTCP XR report = blocks don't define new metrics, but rather explicitly convey metrics = that have been defined elsewhere.=20 I'd suggest changing: In the Performance Metrics Framework [RFC6390], guidelines for Considering New Performance Metric Development are provided. The objective of this document is to describe an extensible RTP monitoring framework to provide a small number of re-usable Quality of Service (QoS) / QoE metrics which facilitate reduced implementation costs and help maximize inter-operability. The "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] has stated that, where RTCP is to be extended with a new metric, the preferred mechanism is by the addition of a new RTCP XR [RFC3611] block. This memo assumes that all the guidelines from RFC 5968 must apply on top of the guidelines in this document. In the Performance Metrics Framework [RFC6390], guidelines for Considering New Performance Metric Development are provided. When new performance metrics are specified, they must follow the RFC 6390 rules: specifically, the performance metric definition template (see section 5.4.4, RFC 6390) must be used. to: The objective of this document is to describe an extensible RTP monitoring framework to provide a small number of re-usable Quality of Service (QoS) / QoE metrics which facilitate reduced implementation costs and help maximize inter-operability. The "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] has stated that, where RTCP is to be extended with a new metric, the preferred mechanism is by the addition of a new RTCP XR [RFC3611] block. This memo assumes that all the guidelines from RFC 5968 must apply on top of the guidelines in this document. Guidelines for=20 developing new performance metrics are specified in [RFC6390]. New RTCP XR report block definitions should not define new performance metrics, but should rather refer to metrics defined elsewhere. It is expected that the referenced metrics will conform to [RFC6390]. Colin=20 --=20 Colin Perkins http://csperkins.org/ From bill.wu@huawei.com Fri Sep 21 02:48:30 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D51A21F8570 for ; Fri, 21 Sep 2012 02:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.228 X-Spam-Level: X-Spam-Status: No, score=-5.228 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BqAX50I+ZtRn for ; Fri, 21 Sep 2012 02:48:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ACCBE21F856F for ; Fri, 21 Sep 2012 02:48:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJW68857; Fri, 21 Sep 2012 09:48:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 10:47:15 +0100 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 10:47:42 +0100 Received: from w53375 (10.138.41.149) by szxeml407-hub.china.huawei.com (10.82.67.94) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 21 Sep 2012 17:47:34 +0800 Message-ID: <9470EA6D0AA3454A88EC20BD16EBFD7E@china.huawei.com> From: Qin Wu To: Colin Perkins , References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org> Date: Fri, 21 Sep 2012 17:47:33 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 09:48:30 -0000 R29vZCBwb2ludCwgdGhhbmsgZm9yIGNsYXJpZmljYXRpb24gYW5kIHByb3Bvc2VkIGNoYW5nZS4N Cg0KUmVnYXJkcyENCi1RaW4NCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQpGcm9tOiAi Q29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3JnPg0KVG86IDxhdnRAaWV0Zi5vcmc+DQpT ZW50OiBGcmlkYXksIFNlcHRlbWJlciAyMSwgMjAxMiA1OjM4IFBNDQpTdWJqZWN0OiBSZTogW0FW VENPUkVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoLTIxLnR4dA0KDQoN Cj4gT24gMjEgU2VwIDIwMTIsIGF0IDA0OjMzLCBJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgd3Jv dGU6DQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQo+PiBUaGlzIGRyYWZ0IGlzIGEgd29yayBp dGVtIG9mIHRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZSBXb3JraW5n IEdyb3VwIG9mIHRoZSBJRVRGLg0KPj4gDQo+PiBUaXRsZSAgICAgICAgICAgOiBHdWlkZWxpbmVz IGZvciBVc2Ugb2YgdGhlIFJUUCBNb25pdG9yaW5nIEZyYW1ld29yaw0KPj4gQXV0aG9yKHMpICAg ICAgIDogUWluIFd1DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgR2VvZmYgSHVudA0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgIFBoaWxpcCBBcmRlbg0KPj4gRmlsZW5hbWUgICAgICAg IDogZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gtMjEudHh0DQo+PiBQYWdlcyAgICAgICAgICAg OiAyOQ0KPj4gRGF0ZSAgICAgICAgICAgIDogMjAxMi0wOS0yMA0KPj4gDQo+PiBBYnN0cmFjdDoN Cj4+ICAgVGhpcyBtZW1vIHByb3Bvc2VzIGFuIGV4dGVuc2libGUgUmVhbC1UaW1lIFByb3RvY29s IChSVFApIG1vbml0b3JpbmcNCj4+ICAgZnJhbWV3b3JrIGZvciBleHRlbmRpbmcgUlRQIENvbnRy b2wgUHJvdG9jb2wgKFJUQ1ApIHdpdGggYSBuZXcgUlRDUA0KPj4gICBFeHRlbmRlZCBSZXBvcnRz IChYUikgYmxvY2sgdHlwZSB0byByZXBvcnQgbmV3IG1ldHJpY3MgcmVnYXJkaW5nDQo+PiAgIG1l ZGlhIHRyYW5zbWlzc2lvbiBvciByZWNlcHRpb24gcXVhbGl0eS4gIEluIHRoaXMgZnJhbWV3b3Jr LCBhIG5ldyBYUg0KPj4gICBibG9jayBzaG91bGQgY29udGFpbiBhIHNpbmdsZSBtZXRyaWMgb3Ig YSBzbWFsbCBudW1iZXIgb2YgbWV0cmljcw0KPj4gICByZWxldmFudCB0byBhIHNpbmdsZSBwYXJh bWV0ZXIgb2YgaW50ZXJlc3Qgb3IgY29uY2VybiwgcmF0aGVyIHRoYW4NCj4+ICAgY29udGFpbmlu ZyBhIG51bWJlciBvZiBtZXRyaWNzIHdoaWNoIGF0dGVtcHQgdG8gcHJvdmlkZSBmdWxsIGNvdmVy YWdlDQo+PiAgIG9mIGFsbCB0aG9zZSBwYXJhbWV0ZXJzIG9mIGNvbmNlcm4gdG8gYSBzcGVjaWZp YyBhcHBsaWNhdGlvbi4NCj4+ICAgQXBwbGljYXRpb25zIG1heSB0aGVuICJtaXggYW5kIG1hdGNo IiB0byBjcmVhdGUgYSBzZXQgb2YgYmxvY2tzIHdoaWNoDQo+PiAgIGNvdmVycyB0aGVpciBzZXQg b2YgY29uY2VybnMuICBXaGVyZSBwb3NzaWJsZSwgYSBzcGVjaWZpYyBibG9jaw0KPj4gICBzaG91 bGQgYmUgZGVzaWduZWQgdG8gYmUgcmUtdXNhYmxlIGFjcm9zcyBtb3JlIHRoYW4gb25lIGFwcGxp Y2F0aW9uLA0KPj4gICBmb3IgZXhhbXBsZSwgZm9yIGFsbCBvZiB2b2ljZSwgc3RyZWFtaW5nIGF1 ZGlvIGFuZCB2aWRlby4NCj4+IA0KPj4gDQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoDQo+IA0KPiANCj4gSSdtIGEgbGl0dGxlIGNv bmZ1c2VkIGJ5IHRoZSBjaGFuZ2VzIHRvIHRoaXMgZHJhZnQuIFRoZSBsYXN0IHBhcmFncmFwaCBv ZiB0aGUgSW50cm9kdWN0aW9uIG5vdyBoYXMgYSBzdHJvbmcgZm9jdXMgb24gZGVmaW5pdGlvbiBv ZiBuZXcgbWV0cmljcywgYW5kIGV4cGxpY2l0bHkgcmVmZXJzIHRvIHRoZSBSRkMgNjM5MCBndWlk ZWxpbmVzIGZvciBkZWZpbmluZyBuZXcgbWV0cmljcy4gSG93ZXZlciwgd2UndmUgYmVlbiBwcmV0 dHkgY29uc2lzdGVudCB0aGF0IG5ldyBSVENQIFhSIHJlcG9ydCBibG9ja3MgZG9uJ3QgZGVmaW5l IG5ldyBtZXRyaWNzLCBidXQgcmF0aGVyIGV4cGxpY2l0bHkgY29udmV5IG1ldHJpY3MgdGhhdCBo YXZlIGJlZW4gZGVmaW5lZCBlbHNld2hlcmUuIA0KPiANCj4gSSdkIHN1Z2dlc3QgY2hhbmdpbmc6 DQo+IA0KPiAgIEluIHRoZSBQZXJmb3JtYW5jZSBNZXRyaWNzIEZyYW1ld29yayBbUkZDNjM5MF0s IGd1aWRlbGluZXMgZm9yDQo+ICAgQ29uc2lkZXJpbmcgTmV3IFBlcmZvcm1hbmNlIE1ldHJpYyBE ZXZlbG9wbWVudCBhcmUgcHJvdmlkZWQuICBUaGUNCj4gICBvYmplY3RpdmUgb2YgdGhpcyBkb2N1 bWVudCBpcyB0byBkZXNjcmliZSBhbiBleHRlbnNpYmxlIFJUUA0KPiAgIG1vbml0b3JpbmcgZnJh bWV3b3JrIHRvIHByb3ZpZGUgYSBzbWFsbCBudW1iZXIgb2YgcmUtdXNhYmxlIFF1YWxpdHkNCj4g ICBvZiBTZXJ2aWNlIChRb1MpIC8gUW9FIG1ldHJpY3Mgd2hpY2ggZmFjaWxpdGF0ZSByZWR1Y2Vk DQo+ICAgaW1wbGVtZW50YXRpb24gY29zdHMgYW5kIGhlbHAgbWF4aW1pemUgaW50ZXItb3BlcmFi aWxpdHkuICBUaGUNCj4gICAiR3VpZGVsaW5lcyBmb3IgRXh0ZW5kaW5nIHRoZSBSVFAgQ29udHJv bCBQcm90b2NvbCAoUlRDUCkiIFtSRkM1OTY4XQ0KPiAgIGhhcyBzdGF0ZWQgdGhhdCwgd2hlcmUg UlRDUCBpcyB0byBiZSBleHRlbmRlZCB3aXRoIGEgbmV3IG1ldHJpYywgdGhlDQo+ICAgcHJlZmVy cmVkIG1lY2hhbmlzbSBpcyBieSB0aGUgYWRkaXRpb24gb2YgYSBuZXcgUlRDUCBYUiBbUkZDMzYx MV0NCj4gICBibG9jay4gIFRoaXMgbWVtbyBhc3N1bWVzIHRoYXQgYWxsIHRoZSBndWlkZWxpbmVz IGZyb20gUkZDIDU5NjggbXVzdA0KPiAgIGFwcGx5IG9uIHRvcCBvZiB0aGUgZ3VpZGVsaW5lcyBp biB0aGlzIGRvY3VtZW50LiAgSW4gdGhlIFBlcmZvcm1hbmNlDQo+ICAgTWV0cmljcyBGcmFtZXdv cmsgW1JGQzYzOTBdLCBndWlkZWxpbmVzIGZvciBDb25zaWRlcmluZyBOZXcNCj4gICBQZXJmb3Jt YW5jZSBNZXRyaWMgRGV2ZWxvcG1lbnQgYXJlIHByb3ZpZGVkLiAgV2hlbiBuZXcgcGVyZm9ybWFu Y2UNCj4gICBtZXRyaWNzIGFyZSBzcGVjaWZpZWQsIHRoZXkgbXVzdCBmb2xsb3cgdGhlIFJGQyA2 MzkwIHJ1bGVzOg0KPiAgIHNwZWNpZmljYWxseSwgdGhlIHBlcmZvcm1hbmNlIG1ldHJpYyBkZWZp bml0aW9uIHRlbXBsYXRlIChzZWUgc2VjdGlvbg0KPiAgIDUuNC40LCBSRkMgNjM5MCkgbXVzdCBi ZSB1c2VkLg0KPiANCj4gdG86DQo+IA0KPiAgIFRoZSBvYmplY3RpdmUgb2YgdGhpcyBkb2N1bWVu dCBpcyB0byBkZXNjcmliZSBhbiBleHRlbnNpYmxlIFJUUA0KPiAgIG1vbml0b3JpbmcgZnJhbWV3 b3JrIHRvIHByb3ZpZGUgYSBzbWFsbCBudW1iZXIgb2YgcmUtdXNhYmxlIFF1YWxpdHkNCj4gICBv ZiBTZXJ2aWNlIChRb1MpIC8gUW9FIG1ldHJpY3Mgd2hpY2ggZmFjaWxpdGF0ZSByZWR1Y2VkDQo+ ICAgaW1wbGVtZW50YXRpb24gY29zdHMgYW5kIGhlbHAgbWF4aW1pemUgaW50ZXItb3BlcmFiaWxp dHkuICBUaGUNCj4gICAiR3VpZGVsaW5lcyBmb3IgRXh0ZW5kaW5nIHRoZSBSVFAgQ29udHJvbCBQ cm90b2NvbCAoUlRDUCkiIFtSRkM1OTY4XQ0KPiAgIGhhcyBzdGF0ZWQgdGhhdCwgd2hlcmUgUlRD UCBpcyB0byBiZSBleHRlbmRlZCB3aXRoIGEgbmV3IG1ldHJpYywgdGhlDQo+ICAgcHJlZmVycmVk IG1lY2hhbmlzbSBpcyBieSB0aGUgYWRkaXRpb24gb2YgYSBuZXcgUlRDUCBYUiBbUkZDMzYxMV0N Cj4gICBibG9jay4gIFRoaXMgbWVtbyBhc3N1bWVzIHRoYXQgYWxsIHRoZSBndWlkZWxpbmVzIGZy b20gUkZDIDU5NjggbXVzdA0KPiAgIGFwcGx5IG9uIHRvcCBvZiB0aGUgZ3VpZGVsaW5lcyBpbiB0 aGlzIGRvY3VtZW50LiBHdWlkZWxpbmVzIGZvciANCj4gICBkZXZlbG9waW5nIG5ldyBwZXJmb3Jt YW5jZSBtZXRyaWNzIGFyZSBzcGVjaWZpZWQgaW4gW1JGQzYzOTBdLiBOZXcNCj4gICBSVENQIFhS IHJlcG9ydCBibG9jayBkZWZpbml0aW9ucyBzaG91bGQgbm90IGRlZmluZSBuZXcgcGVyZm9ybWFu Y2UNCj4gICBtZXRyaWNzLCBidXQgc2hvdWxkIHJhdGhlciByZWZlciB0byBtZXRyaWNzIGRlZmlu ZWQgZWxzZXdoZXJlLiBJdA0KPiAgIGlzIGV4cGVjdGVkIHRoYXQgdGhlIHJlZmVyZW5jZWQgbWV0 cmljcyB3aWxsIGNvbmZvcm0gdG8gW1JGQzYzOTBdLg0KPiANCj4gQ29saW4gDQo+IA0KPiANCj4g LS0gDQo+IENvbGluIFBlcmtpbnMNCj4gaHR0cDovL2NzcGVya2lucy5vcmcvDQo+IA0KPiANCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IEF1 ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+IGF2dEBpZXRmLm9yZw0KPiBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPg== From glenzorn@gmail.com Fri Sep 21 03:12:54 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253AD21F86BA for ; Fri, 21 Sep 2012 03:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.116 X-Spam-Level: X-Spam-Status: No, score=-3.116 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwuAUZKK2ohU for ; Fri, 21 Sep 2012 03:12:53 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F88321F8678 for ; Fri, 21 Sep 2012 03:12:53 -0700 (PDT) Received: by pbbjt11 with SMTP id jt11so4909917pbb.31 for ; Fri, 21 Sep 2012 03:12:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fYsAHZSW0iLzzhL03/6SnXlz6VgEQPH0HEuc09n6ql4=; b=mZS827XtA/kvLwmhI9MALE+DyzfoTg6ifoBTkkHoKf5P+go14PYuvRv+UND2Xp642W FsBrEXA6xBRRmCnhSHVAYLTd61sKVpeSVtUEV9VKl1V0PqNs3pSHEAiJeRw4+6a2jfhC wlnwdt231VadmmzOyZRzXPbARFW18J7U79UyHqvsZu3ZZl3Qrn/cfmJQHHQR0s6q6S6P QUwVgubgxf2jdBJ7tv/uyhS1K14SS0dfstMKNzmm1hSPCUOvulmSkF5eYF8x3wPtFeJD rvmQQVpyYKQ8KxNbwsn9GTF1p7SHriDLdAIeF3fj6Oj5r/evcw8cNLWcOAoJaHbiVFvd FkDQ== Received: by 10.66.75.104 with SMTP id b8mr12169741paw.21.1348222373309; Fri, 21 Sep 2012 03:12:53 -0700 (PDT) Received: from [192.168.0.102] (ppp-110-169-206-48.revip5.asianet.co.th. [110.169.206.48]) by mx.google.com with ESMTPS id bs6sm3918227pab.30.2012.09.21.03.12.51 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 03:12:52 -0700 (PDT) Message-ID: <505C3DA1.1060003@gmail.com> Date: Fri, 21 Sep 2012 17:12:49 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Colin Perkins References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org> In-Reply-To: <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avt@ietf.org WG" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 10:12:54 -0000 On 09/21/2012 04:38 PM, Colin Perkins wrote: ... > I'm a little confused by the changes to this draft. The last > paragraph of the Introduction now has a strong focus on definition of > new metrics, and explicitly refers to the RFC 6390 guidelines for > defining new metrics. However, we've been pretty consistent that new > RTCP XR report blocks don't define new metrics, but rather explicitly > convey metrics that have been defined elsewhere. > > I'd suggest changing: > > In the Performance Metrics Framework [RFC6390], guidelines for > Considering New Performance Metric Development are provided. The > objective of this document is to describe an extensible RTP > monitoring framework to provide a small number of re-usable Quality > of Service (QoS) / QoE metrics which facilitate reduced > implementation costs and help maximize inter-operability. The > "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] > has stated that, where RTCP is to be extended with a new metric, the > preferred mechanism is by the addition of a new RTCP XR [RFC3611] > block. This memo assumes that all the guidelines from RFC 5968 must > apply on top of the guidelines in this document. In the Performance > Metrics Framework [RFC6390], guidelines for Considering New > Performance Metric Development are provided. When new performance > metrics are specified, they must follow the RFC 6390 rules: > specifically, the performance metric definition template (see > section 5.4.4, RFC 6390) must be used. > > to: > > The objective of this document is to describe an extensible RTP > monitoring framework to provide a small number of re-usable Quality > of Service (QoS) / QoE metrics which facilitate reduced > implementation costs and help maximize inter-operability. The > "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] > has stated that, where RTCP is to be extended with a new metric, the > preferred mechanism is by the addition of a new RTCP XR [RFC3611] > block. This memo assumes that all the guidelines from RFC 5968 must > apply on top of the guidelines in this document. Guidelines for > developing new performance metrics are specified in [RFC6390]. New > RTCP XR report block definitions should not define new performance > metrics, but should rather refer to metrics defined elsewhere. It is > expected that the referenced metrics will conform to [RFC6390]. I think that that is all fine, except the last sentence. To give one example from a draft currently under discussion, draft-ietf-xrblock-rtcp-xr-pdv uses metrics developed by ITU-T. Can we reasonably expect that ITU-T metrics will conform to RFC 6390? > > Colin > > From csp@csperkins.org Fri Sep 21 03:22:08 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FE9621F8776 for ; Fri, 21 Sep 2012 03:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wdj+nvzqQ7bq for ; Fri, 21 Sep 2012 03:22:07 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9D48621F8770 for ; Fri, 21 Sep 2012 03:22:07 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1TF0N4-0007cF-lE; Fri, 21 Sep 2012 10:22:06 +0000 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Colin Perkins In-Reply-To: <505C3DA1.1060003@gmail.com> Date: Fri, 21 Sep 2012 11:22:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <6528A053-4ABF-4150-BF12-E3D0F5218116@csperkins.org> References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org> <505C3DA1.1060003@gmail.com> To: Glen Zorn X-Mailer: Apple Mail (2.1283) Cc: "avt@ietf.org WG" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 10:22:08 -0000 On 21 Sep 2012, at 11:12, Glen Zorn wrote: > On 09/21/2012 04:38 PM, Colin Perkins wrote: > ... >> I'm a little confused by the changes to this draft. The last > > paragraph of the Introduction now has a strong focus on definition = of > > new metrics, and explicitly refers to the RFC 6390 guidelines for > > defining new metrics. However, we've been pretty consistent that new > > RTCP XR report blocks don't define new metrics, but rather = explicitly > > convey metrics that have been defined elsewhere. > > > > I'd suggest changing: > > > > In the Performance Metrics Framework [RFC6390], guidelines for > > Considering New Performance Metric Development are provided. The > > objective of this document is to describe an extensible RTP > > monitoring framework to provide a small number of re-usable Quality > > of Service (QoS) / QoE metrics which facilitate reduced > > implementation costs and help maximize inter-operability. The > > "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] > > has stated that, where RTCP is to be extended with a new metric, the > > preferred mechanism is by the addition of a new RTCP XR [RFC3611] > > block. This memo assumes that all the guidelines from RFC 5968 must > > apply on top of the guidelines in this document. In the Performance > > Metrics Framework [RFC6390], guidelines for Considering New > > Performance Metric Development are provided. When new performance > > metrics are specified, they must follow the RFC 6390 rules: > > specifically, the performance metric definition template (see > > section 5.4.4, RFC 6390) must be used. > > > > to: > > > > The objective of this document is to describe an extensible RTP > > monitoring framework to provide a small number of re-usable Quality > > of Service (QoS) / QoE metrics which facilitate reduced > > implementation costs and help maximize inter-operability. The > > "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] > > has stated that, where RTCP is to be extended with a new metric, the > > preferred mechanism is by the addition of a new RTCP XR [RFC3611] > > block. This memo assumes that all the guidelines from RFC 5968 must > > apply on top of the guidelines in this document. Guidelines for > > developing new performance metrics are specified in [RFC6390]. New > > RTCP XR report block definitions should not define new performance > > metrics, but should rather refer to metrics defined elsewhere. It is > > expected that the referenced metrics will conform to [RFC6390]. >=20 > I think that that is all fine, except the last sentence. To give one = example from a draft currently under discussion, = draft-ietf-xrblock-rtcp-xr-pdv uses metrics developed by ITU-T. Can we = reasonably expect that ITU-T metrics will conform to RFC 6390? Good point - I guess we could add "...if developed in the IETF", or we = could just remove the last sentence. --=20 Colin Perkins http://csperkins.org/ From glenzorn@gmail.com Fri Sep 21 06:24:35 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAFEE21F8799 for ; Fri, 21 Sep 2012 06:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.065 X-Spam-Level: X-Spam-Status: No, score=-3.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFTE6hgUR5qM for ; Fri, 21 Sep 2012 06:24:34 -0700 (PDT) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 91CFC21F847B for ; Fri, 21 Sep 2012 06:24:34 -0700 (PDT) Received: by padfb11 with SMTP id fb11so438557pad.31 for ; Fri, 21 Sep 2012 06:24:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=RndrZkM7j3wN2jOFS9PjGUVImu4x+kfExsnavzNWPyI=; b=BRqZ3cPuSRGiGQZIdDXLkG3XirnAttBnESynhZIsZ8TVlH+meJek7PkRO7wZuBkZma RlG0B+FUgLG/mMpU0BJ8toR6RwtDcFbaGfzgjSrJlel3ooA+1AdbVhVm3W7vKKPVY57f F1/OoSyf/X+ig/azpVJ5wKHcKLB6tRttMLYhTgTgH5PkgHDcBNCMRlNkD9vZ4tQsbiBD IestwvKfIN45/+H3mzUikYgkptjAuLn/X+gJJD1bVh/+pdeqaPSSYjPkT/+hBTm1fLTz FQMkgIMuXBb2gjrqH44/8vzMTk4IJlYbU8jxcdB++0lcXX4z9p3AhfiUd1sUfKanPqOh zJcQ== Received: by 10.66.75.229 with SMTP id f5mr13261309paw.47.1348233874357; Fri, 21 Sep 2012 06:24:34 -0700 (PDT) Received: from [192.168.0.102] (ppp-110-169-206-48.revip5.asianet.co.th. [110.169.206.48]) by mx.google.com with ESMTPS id uu10sm5149237pbc.2.2012.09.21.06.24.32 (version=SSLv3 cipher=OTHER); Fri, 21 Sep 2012 06:24:33 -0700 (PDT) Message-ID: <505C6A8E.4010302@gmail.com> Date: Fri, 21 Sep 2012 20:24:30 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120830 Thunderbird/15.0 MIME-Version: 1.0 To: Colin Perkins References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com> <94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org> <505C3DA1.1060003@gmail.com> <6528A053-4ABF-4150-BF12-E3D0F5218116@csperkins.org> In-Reply-To: <6528A053-4ABF-4150-BF12-E3D0F5218116@csperkins.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "avt@ietf.org WG" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 13:24:35 -0000 On 09/21/2012 05:22 PM, Colin Perkins wrote: ... > > > The objective of this document is to describe an extensible RTP > monitoring framework to provide a small number of re-usable Quality > of Service (QoS) / QoE metrics which facilitate reduced > implementation costs and help maximize inter-operability. The > "Guidelines for Extending the RTP Control Protocol (RTCP)" [RFC5968] > has stated that, where RTCP is to be extended with a new metric, the > preferred mechanism is by the addition of a new RTCP XR [RFC3611] > block. This memo assumes that all the guidelines from RFC 5968 must > apply on top of the guidelines in this document. Guidelines for > developing new performance metrics are specified in [RFC6390]. New > RTCP XR report block definitions should not define new performance > metrics, but should rather refer to metrics defined elsewhere. It is > expected that the referenced metrics will conform to [RFC6390]. >> >> I think that that is all fine, except the last sentence. To give >> one example from a draft currently under discussion, >> draft-ietf-xrblock-rtcp-xr-pdv uses metrics developed by ITU-T. >> Can we reasonably expect that ITU-T metrics will conform to RFC >> 6390? > > > Good point - I guess we could add "...if developed in the IETF", or > we could just remove the last sentence. > Deleting is easy :-). From padpriya@cisco.com Fri Sep 21 03:34:29 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B983E21F8777 for ; Fri, 21 Sep 2012 03:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U29TYcfRsv3O for ; Fri, 21 Sep 2012 03:34:29 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 0892221F8776 for ; Fri, 21 Sep 2012 03:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3813; q=dns/txt; s=iport; t=1348223669; x=1349433269; h=from:to:cc:subject:date:message-id:mime-version; bh=NdrvKRyI0o9aIT+3Z6U1ituiIeXGpY1e0ZDoO6vEaJo=; b=VMtZLMCtyGfTPwcB4JW5JVp6KV/gFxkhnLOXQWtt5mAZlKwDet/bFWzX iyx8RqoSuClQybBeEOpsRll6iVm5HY+Jc2eD7QTbJne5EIBY0K3qRD+WJ C6p5fqCgec1xj5SmFaDSgyKG5v+hHgx7pfKs9/NCLzFalUmuCuPLttBfs M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABFCXFCtJV2Y/2dsb2JhbABFgku7RYEIgiIBBBIBGj4OEgEMHlYmAQQODRqHY5kcoBmQYmADpB2BaYJnghc X-IronPort-AV: E=Sophos;i="4.80,462,1344211200"; d="scan'208,217";a="123952577" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-3.cisco.com with ESMTP; 21 Sep 2012 10:34:28 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id q8LAYSSg004595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Sep 2012 10:34:28 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.223]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Fri, 21 Sep 2012 05:34:28 -0500 From: "Padma Priya (padpriya)" To: "avt@ietf.org" Thread-Topic: Retransmission interval for RTCP FIR packet. Thread-Index: Ac2X5KyLDWPptUM8QQi4lraHRmvBYQ== Date: Fri, 21 Sep 2012 10:34:28 +0000 Message-ID: <5986739F16AAF344951CC2C4AB13153D064132@xmb-aln-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.64.10] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19200.001 x-tm-as-result: No--26.600600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_5986739F16AAF344951CC2C4AB13153D064132xmbalnx05ciscocom_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 21 Sep 2012 10:13:17 -0700 Subject: [AVTCORE] Retransmission interval for RTCP FIR packet. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Sep 2012 10:35:48 -0000 --_000_5986739F16AAF344951CC2C4AB13153D064132xmbalnx05ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Experts, I am working on a call flow where one of the video endpoints joins= the video call while the call is in progress. RTP is used for media. So we trigger RTCP FIR packet to the existing video endpoints in the call w= hen a new user joins. To mitigate UDP packet loss, we are planning to have a retransmission mecha= nism for the RTCP FIR packet. I am looking for inputs on what should be the frequency and how many times = we might have to retransmit the RTCP FIR packet. I know it would be greatly dependent on the network as such, but wanted som= e kind of default value that would mostly suffice. Regards, Priya --_000_5986739F16AAF344951CC2C4AB13153D064132xmbalnx05ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Experts,

         I a= m working on a call flow where one of the video endpoints joins the video c= all while the call is in progress. RTP is used for media.

So we trigger RTCP FIR packet to the existing video = endpoints in the call when a new user joins.

To mitigate UDP packet loss, we are planning to have= a retransmission mechanism for the RTCP FIR packet.

 

I am looking for inputs on what should be the freque= ncy and how many times we might have to retransmit the RTCP FIR packet.

I know it would be greatly dependent on the network = as such, but wanted some kind of default value that would mostly suffice.

 

Regards,

Priya

 

 

--_000_5986739F16AAF344951CC2C4AB13153D064132xmbalnx05ciscocom_-- From padpriya@cisco.com Mon Sep 24 09:20:38 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 167F321F87EE for ; Mon, 24 Sep 2012 09:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hfk77meCGoBq for ; Mon, 24 Sep 2012 09:20:37 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BAB3F21F8699 for ; Mon, 24 Sep 2012 09:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3888; q=dns/txt; s=iport; t=1348503635; x=1349713235; h=from:to:subject:date:message-id:mime-version; bh=L5K/QsbwROw2eFXhrr7Pd98B3M633hhOH8qcCNkVBV8=; b=A/UmZgHcBFSfPU2CuBrYpKfuiTxUPG59NlizHkiJwz9jRnasBJh1O844 CkSWLUIFICrvt/hrKvP7JHtjmmSyN9rL5M/zTDyp4zijkstOpPraN8E2T nucy9XCNYk9iP9CJB7wtrHhl7E97GBjYi5IDr8h9kb/Rla5kUxBFOSCsi U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAEGHYFCtJXG//2dsb2JhbABFgku7dIEIgiIBBBIBGj4gAQweViYBBBsah2OXL4Eon2KQZmADpB+BaYJnghc X-IronPort-AV: E=Sophos;i="4.80,476,1344211200"; d="scan'208,217";a="124706425" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 24 Sep 2012 16:20:35 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8OGKZ1D002880 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 24 Sep 2012 16:20:35 GMT Received: from xmb-aln-x05.cisco.com ([169.254.11.223]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0298.004; Mon, 24 Sep 2012 11:20:35 -0500 From: "Padma Priya (padpriya)" To: "avt@ietf.org" Thread-Topic: Retransmission interval for RTCP FIR packet. Thread-Index: Ac2X5KyLDWPptUM8QQi4lraHRmvBYQCi8vbA Date: Mon, 24 Sep 2012 16:20:34 +0000 Message-ID: <5986739F16AAF344951CC2C4AB13153D064805@xmb-aln-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.84.102] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19206.004 x-tm-as-result: No--26.600600-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_5986739F16AAF344951CC2C4AB13153D064805xmbalnx05ciscocom_" MIME-Version: 1.0 Subject: [AVTCORE] Retransmission interval for RTCP FIR packet. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Sep 2012 16:20:38 -0000 --_000_5986739F16AAF344951CC2C4AB13153D064805xmbalnx05ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Experts, I am working on a call flow where one of the video endpoints joins= the video call while the call is in progress. RTP is used for media. So we trigger RTCP FIR packet to the existing video endpoints in the call w= hen a new user joins. To mitigate UDP packet loss, we are planning to have a retransmission mecha= nism for the RTCP FIR packet. I am looking for inputs on what should be the frequency and how many times = we might have to retransmit the RTCP FIR packet. I know it would be greatly dependent on the network as such, but wanted som= e kind of default value that would mostly suffice. Regards, Priya --_000_5986739F16AAF344951CC2C4AB13153D064805xmbalnx05ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Experts,

         I a= m working on a call flow where one of the video endpoints joins the video c= all while the call is in progress. RTP is used for media.

So we trigger RTCP FIR packet to the existing video = endpoints in the call when a new user joins.

To mitigate UDP packet loss, we are planning to have= a retransmission mechanism for the RTCP FIR packet.

 

I am looking for inputs on what should be the freque= ncy and how many times we might have to retransmit the RTCP FIR packet.

I know it would be greatly dependent on the network = as such, but wanted some kind of default value that would mostly suffice.

 

Regards,

Priya

 

--_000_5986739F16AAF344951CC2C4AB13153D064805xmbalnx05ciscocom_-- From bill.wu@huawei.com Mon Sep 24 20:41:11 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7DB621F88FB for ; Mon, 24 Sep 2012 20:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.994 X-Spam-Level: X-Spam-Status: No, score=-4.994 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lk735g+PQYPI for ; Mon, 24 Sep 2012 20:41:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8904721F88EE for ; Mon, 24 Sep 2012 20:41:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AJZ32551; Tue, 25 Sep 2012 03:41:09 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 04:40:31 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 04:41:08 +0100 Received: from w53375 (10.138.41.149) by szxeml422-hub.china.huawei.com (10.82.67.161) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 25 Sep 2012 11:41:04 +0800 Message-ID: From: Qin Wu To: Glen Zorn , Colin Perkins References: <20120921033311.2019.17521.idtracker@ietfa.amsl.com><94BFF0B8-B69E-41C7-8C73-9CD38EF5F938@csperkins.org><505C3DA1.1060003@gmail.com><6528A053-4ABF-4150-BF12-E3D0F5218116@csperkins.org> <505C6A8E.4010302@gmail.com> Date: Tue, 25 Sep 2012 11:41:04 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: base64 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Originating-IP: [10.138.41.149] X-CFilter-Loop: Reflected Cc: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-21.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 03:41:11 -0000 SGksDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogIkdsZW4gWm9ybiIgPGds ZW56b3JuQGdtYWlsLmNvbT4NClRvOiAiQ29saW4gUGVya2lucyIgPGNzcEBjc3BlcmtpbnMub3Jn Pg0KQ2M6IDxhdnRAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIFNlcHRlbWJlciAyMSwgMjAxMiA5 OjI0IFBNDQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0 Y29yZS1tb25hcmNoLTIxLnR4dA0KDQoNCj4gT24gMDkvMjEvMjAxMiAwNToyMiBQTSwgQ29saW4g UGVya2lucyB3cm90ZToNCj4gDQo+IC4uLg0KPiANCj4+DQo+ID4NCj4gPiBUaGUgb2JqZWN0aXZl IG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gZGVzY3JpYmUgYW4gZXh0ZW5zaWJsZSBSVFANCj4gPiBt b25pdG9yaW5nIGZyYW1ld29yayB0byBwcm92aWRlIGEgc21hbGwgbnVtYmVyIG9mIHJlLXVzYWJs ZSBRdWFsaXR5DQo+ID4gb2YgU2VydmljZSAoUW9TKSAvIFFvRSBtZXRyaWNzIHdoaWNoIGZhY2ls aXRhdGUgcmVkdWNlZA0KPiA+IGltcGxlbWVudGF0aW9uIGNvc3RzIGFuZCBoZWxwIG1heGltaXpl IGludGVyLW9wZXJhYmlsaXR5LiBUaGUNCj4gPiAiR3VpZGVsaW5lcyBmb3IgRXh0ZW5kaW5nIHRo ZSBSVFAgQ29udHJvbCBQcm90b2NvbCAoUlRDUCkiIFtSRkM1OTY4XQ0KPiA+IGhhcyBzdGF0ZWQg dGhhdCwgd2hlcmUgUlRDUCBpcyB0byBiZSBleHRlbmRlZCB3aXRoIGEgbmV3IG1ldHJpYywgdGhl DQo+ID4gcHJlZmVycmVkIG1lY2hhbmlzbSBpcyBieSB0aGUgYWRkaXRpb24gb2YgYSBuZXcgUlRD UCBYUiBbUkZDMzYxMV0NCj4gPiBibG9jay4gVGhpcyBtZW1vIGFzc3VtZXMgdGhhdCBhbGwgdGhl IGd1aWRlbGluZXMgZnJvbSBSRkMgNTk2OCBtdXN0DQo+ID4gYXBwbHkgb24gdG9wIG9mIHRoZSBn dWlkZWxpbmVzIGluIHRoaXMgZG9jdW1lbnQuIEd1aWRlbGluZXMgZm9yDQo+ID4gZGV2ZWxvcGlu ZyBuZXcgcGVyZm9ybWFuY2UgbWV0cmljcyBhcmUgc3BlY2lmaWVkIGluIFtSRkM2MzkwXS4gTmV3 DQo+ID4gUlRDUCBYUiByZXBvcnQgYmxvY2sgZGVmaW5pdGlvbnMgc2hvdWxkIG5vdCBkZWZpbmUg bmV3IHBlcmZvcm1hbmNlDQo+ID4gbWV0cmljcywgYnV0IHNob3VsZCByYXRoZXIgcmVmZXIgdG8g bWV0cmljcyBkZWZpbmVkIGVsc2V3aGVyZS4gSXQgaXMNCj4gPiBleHBlY3RlZCB0aGF0IHRoZSBy ZWZlcmVuY2VkIG1ldHJpY3Mgd2lsbCBjb25mb3JtIHRvIFtSRkM2MzkwXS4NCj4gPj4NCj4gPj4g SSB0aGluayB0aGF0IHRoYXQgaXMgYWxsIGZpbmUsIGV4Y2VwdCB0aGUgbGFzdCBzZW50ZW5jZS4g VG8gZ2l2ZQ0KPiA+PiBvbmUgZXhhbXBsZSBmcm9tIGEgZHJhZnQgY3VycmVudGx5IHVuZGVyIGRp c2N1c3Npb24sDQo+ID4+IGRyYWZ0LWlldGYteHJibG9jay1ydGNwLXhyLXBkdiB1c2VzIG1ldHJp Y3MgZGV2ZWxvcGVkIGJ5IElUVS1ULg0KPiA+PiBDYW4gd2UgcmVhc29uYWJseSBleHBlY3QgdGhh dCBJVFUtVCBtZXRyaWNzIHdpbGwgY29uZm9ybSB0byBSRkMNCj4gPj4gNjM5MD8NCj4gPg0KPiA+ DQo+ID4gR29vZCBwb2ludCAtIEkgZ3Vlc3Mgd2UgY291bGQgYWRkICIuLi5pZiBkZXZlbG9wZWQg aW4gdGhlIElFVEYiLCBvcg0KPiA+IHdlIGNvdWxkIGp1c3QgcmVtb3ZlIHRoZSBsYXN0IHNlbnRl bmNlLg0KPiA+DQo+IA0KPiBEZWxldGluZyBpcyBlYXN5IDotKS4NCg0KW1Fpbl06T2theSwgbG9v a3MgZ29vZCB0byBtZS4NCg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPiBh dnRAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQ= From internet-drafts@ietf.org Mon Sep 24 20:49:15 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8DB421F890F; Mon, 24 Sep 2012 20:49:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJCdYgKBHH-t; Mon, 24 Sep 2012 20:49:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7881A21F8905; Mon, 24 Sep 2012 20:49:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20120925034915.32308.14794.idtracker@ietfa.amsl.com> Date: Mon, 24 Sep 2012 20:49:15 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-22.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 03:49:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Use of the RTP Monitoring Framework Author(s) : Qin Wu Geoff Hunt Philip Arden Filename : draft-ietf-avtcore-monarch-22.txt Pages : 29 Date : 2012-09-24 Abstract: This memo proposes an extensible Real-Time Protocol (RTP) monitoring framework for extending RTP Control Protocol (RTCP) with a new RTCP Extended Reports (XR) block type to report new metrics regarding media transmission or reception quality. In this framework, a new XR block should contain a single metric or a small number of metrics relevant to a single parameter of interest or concern, rather than containing a number of metrics which attempt to provide full coverage of all those parameters of concern to a specific application. Applications may then "mix and match" to create a set of blocks which covers their set of concerns. Where possible, a specific block should be designed to be re-usable across more than one application, for example, for all of voice, streaming audio and video. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-monarch-22 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-22 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Tue Sep 25 08:20:08 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF2911E8097 for ; Tue, 25 Sep 2012 08:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HPma8+dB2LnY for ; Tue, 25 Sep 2012 08:20:06 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2C011E808A for ; Tue, 25 Sep 2012 08:20:05 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-54-5061cba334f0 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id C6.51.17130.3ABC1605; Tue, 25 Sep 2012 17:20:03 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.264.1; Tue, 25 Sep 2012 17:20:03 +0200 Message-ID: <5061CBA2.7080402@ericsson.com> Date: Tue, 25 Sep 2012 17:20:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: IETF AVTCore WG , "rai-ads@tools.ietf.org" References: <20120925034915.32308.14794.idtracker@ietfa.amsl.com> In-Reply-To: <20120925034915.32308.14794.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvre7i04kBBt3LBC1e9qxkt9i7fR6j A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWx/9QyxoKdkhX/Pu5ib2CcKdLFyMEhIWAi sXGVQBcjJ5ApJnHh3nq2LkYuDiGBU4wSP6cvYIVwljNKvLraxQRSxSugLXFr+11mEJtFQFVi 2r1bjCA2m4CFxM0fjWwgtqhAsMSk/VtYIOoFJU7OfAJmiwhESBxd0gvWKyxgJbHj+S4wW0jA UaL52TawXk4BJ4k91zYxQVwkKfFm8k2wXmYBPYkpV1sYIWx5ieats6F6tSUamjpYJzAKzkKy bhaSlllIWhYwMq9iFM5NzMxJLzfXSy3KTC4uzs/TK07dxAgM1YNbfhvsYNx0X+wQozQHi5I4 r57qfn8hgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjBUdHxSyP0Tc3Zp7d6+Wp5CaVtUGBcHY V26+524V3ErL6t998vLZcwf8/60+veg/zz3u7HM5afu64viWBM7JeXTv/mQB3cnh1kHR7gks dkbczoYPI5P3Oej39n6yZJ2x+8dBlaISvmduLC6PEj3WMenO9v//wLpiRdE8I93sCet8HXY8 O/xSVImlOCPRUIu5qDgRABTgY7IjAgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-22.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Sep 2012 15:20:08 -0000 ADs, WG, With the latest set of changes the IESG appears to all have cleared. Which means this document will go forward. Based on that there has been additional changes I would request that the AD's don't approve the document for another week (until the 3rd of October) to allow people to react on the latest changes. A document diff comparing the version we requested IESG review again on and the latest can be found here: https://www.ietf.org/rfcdiff?url1=draft-ietf-avtcore-monarch-17&difftype=--html&submit=Go!&url2=draft-ietf-avtcore-monarch-22 Cheers Magnus Westerlund On 2012-09-25 05:49, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Guidelines for Use of the RTP Monitoring Framework > Author(s) : Qin Wu > Geoff Hunt > Philip Arden > Filename : draft-ietf-avtcore-monarch-22.txt > Pages : 29 > Date : 2012-09-24 > > Abstract: > This memo proposes an extensible Real-Time Protocol (RTP) monitoring > framework for extending RTP Control Protocol (RTCP) with a new RTCP > Extended Reports (XR) block type to report new metrics regarding > media transmission or reception quality. In this framework, a new XR > block should contain a single metric or a small number of metrics > relevant to a single parameter of interest or concern, rather than > containing a number of metrics which attempt to provide full coverage > of all those parameters of concern to a specific application. > Applications may then "mix and match" to create a set of blocks which > covers their set of concerns. Where possible, a specific block > should be designed to be re-usable across more than one application, > for example, for all of voice, streaming audio and video. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-monarch > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-monarch-22 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-22 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- 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 magnus.westerlund@ericsson.com Thu Sep 27 01:08:29 2012 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E88F21F84D3 for ; Thu, 27 Sep 2012 01:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XbbquxqTS7jU for ; Thu, 27 Sep 2012 01:08:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 702F921F848B for ; Thu, 27 Sep 2012 01:08:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-52-5064097bc6d2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D3.03.11467.B7904605; Thu, 27 Sep 2012 10:08:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.264.1; Thu, 27 Sep 2012 10:08:17 +0200 Message-ID: <50640925.4000204@ericsson.com> Date: Thu, 27 Sep 2012 10:07:01 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: "Padma Priya (padpriya)" References: <5986739F16AAF344951CC2C4AB13153D064805@xmb-aln-x05.cisco.com> In-Reply-To: <5986739F16AAF344951CC2C4AB13153D064805@xmb-aln-x05.cisco.com> X-Enigmail-Version: 1.4.4 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDLMWRmVeSWpSXmKPExsUyM+JvrW41Z0qAwdXd8hYve1ayW5z6/I/J gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mp4+X0WS0GjcEVv30vWBsZnfF2MnBwSAiYS i/+dZoGwxSQu3FvP1sXIxSEkcIpR4t+JVlYIZzmjxJRJi8GqeAW0JR5uOcsMYrMIqEo8v9cC ZrMJWEjc/NHIBmKLCgRLTNq/BapeUOLkzCdgtoiAocTq081ANgcHs4CixKR2SZCwsICzxN1N h5lAbCEBL4nlXz6ygticAt4Se/79YoM4TlLizeSbYGOYBfQkplxtYYSw5SWat85mhujVlmho 6mCdwCg0C8nmWUhaZiFpWcDIvIpRODcxMye93FAvtSgzubg4P0+vOHUTIzCED275rbuD8dQ5 kUOM0hwsSuK8XEn7/YUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwusdJPFYxKVx4WaRs95Gk qRlCVT+FqtYtbhBbN+vSi43R7e3KaoF5bYcTDzkKqugYmkdfzrTlm3H1w1qVivP3e99YiX3U 766ZIunkbpoqongwcdWSvXwK8nzlqRaSPH+f/HI6zb804/Ame7l6wXSX/dr3BZKZD8+usXrA pFbN8uzatP5lMfuUWIozEg21mIuKEwFi/OkkLwIAAA== Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Retransmission interval for RTCP FIR packet. X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Sep 2012 08:08:29 -0000 Hi, (as individual) First of all the frequency of the FIR retransmissions are limited by the rules of transmitting RTCP packets. Secondly, as soon as one RTCP packet in each direction has been sent for a session participant that is sending media will have an RTT estimate to the participant. That should be used to avoid unnecessary retransmissions. I note that RFC 5104 says the following: 4.3.1.3. Timing Rules The timing follows the rules outlined in section 3 of [RFC4585]. FIR commands MAY be used with early or immediate feedback. The FIR feedback message MAY be repeated. If using immediate feedback mode, the repetition SHOULD wait at least one RTT before being sent. In early or regular RTCP mode, the repetition is sent in the next regular RTCP packet. I think there are two strategies that can be employed here. Either one repetition per RTT until a reaction is received. Or one sends (likely more) narrowly spaced repetitions that have a really high probability of reaching the media sender. Thus the interval needs to be longer than likely burst drops and allowed by the transmissions rules. Cheers Magnus On 2012-09-24 18:20, Padma Priya (padpriya) wrote: > Hi Experts, > > I am working on a call flow where one of the video endpoints > joins the video call while the call is in progress. RTP is used for media. > > So we trigger RTCP FIR packet to the existing video endpoints in the > call when a new user joins. > > To mitigate UDP packet loss, we are planning to have a retransmission > mechanism for the RTCP FIR packet. > > > > I am looking for inputs on what should be the frequency and how many > times we might have to retransmit the RTCP FIR packet. > > I know it would be greatly dependent on the network as such, but wanted > some kind of default value that would mostly suffice. > > > > Regards, > > Priya > > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------