From wwwrun@rfc-editor.org Thu Aug 2 12:01:20 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 C860811E827E; Thu, 2 Aug 2012 12:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.989 X-Spam-Level: X-Spam-Status: No, score=-101.989 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHEuz49Fpabk; Thu, 2 Aug 2012 12:01:20 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8FF6111E8181; Thu, 2 Aug 2012 12:01:14 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CD585621A0; Thu, 2 Aug 2012 12:00:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120802190032.CD585621A0@rfc-editor.org> Date: Thu, 2 Aug 2012 12:00:28 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6679 on Explicit Congestion Notification (ECN) for RTP over UDP 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, 02 Aug 2012 19:01:21 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6679 Title: Explicit Congestion Notification (ECN) for RTP over UDP Author: M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg Status: Standards Track Stream: IETF Date: August 2012 Mailbox: magnus.westerlund@ericsson.com, ingemar.s.johansson@ericsson.com, csp@csperkins.org, piers.ohanlon@oii.ox.ac.uk, carlberg@g11.org.uk Pages: 58 Characters: 148560 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avtcore-ecn-for-rtp-08.txt URL: http://www.rfc-editor.org/rfc/rfc6679.txt This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialisation methods are also defined. [STANDARDS-TRACK] This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From ray.vanbrandenburg@tno.nl Thu Aug 2 19:23:00 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 748B211E80A4 for ; Thu, 2 Aug 2012 19:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.238 X-Spam-Level: X-Spam-Status: No, score=0.238 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0plhekrldkO for ; Thu, 2 Aug 2012 19:22:59 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id F2EC221F8510 for ; Thu, 2 Aug 2012 19:22:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.77,704,1336341600"; d="scan'208,217";a="15928396" Received: from unknown (HELO mail.tno.nl) ([134.221.225.220]) by mailhost1b.tno.nl with ESMTP; 03 Aug 2012 04:22:53 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.96]) by EXC-CASHUB01.tsn.tno.nl ([134.221.225.220]) with mapi id 14.02.0298.004; Fri, 3 Aug 2012 04:22:53 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" , Magnus Westerlund , "csp@csperkins.org" Thread-Topic: Comments on draft-ietf-avt-srtp-not-mandatory-09 Thread-Index: AQHNcQ90k9ZpJzgdtEut8HGzsNKSdJdHW6aN Date: Fri, 3 Aug 2012 02:22:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_FD4DC1EEF3B946C9ABD3CAA59AB45EDBtnonl_" MIME-Version: 1.0 Subject: [AVTCORE] Comments on draft-ietf-avt-srtp-not-mandatory-09 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, 03 Aug 2012 02:23:00 -0000 --_000_FD4DC1EEF3B946C9ABD3CAA59AB45EDBtnonl_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Colin/Magnus, This is my review of draft-ietf-avt-srtp-not-mandatory-09. Since I'm not a = security expert, I can't say anything about the security implications of th= e document. That said, I do have some other comments. I've not been followi= ng the discussion on this topic very closely on the list, so please excuse = me if any topics I bring up have already been discussed on list earlier. 1) The page-header of the draft is 'SRTP is not the only RTP Security Optio= n'. Although I understand that this header summarizes the rationale for wri= ting the draft in the first place, from reading the abstract and introducti= on of the draft, this header seems a little out of place. I would suggest t= o either more clearly describe its relevance in the abstract or introductio= n (where SRTP is not mentioned), or choose a different header. 2) Section 3, paragraph 3 states that SRTP is not suitable for some scenari= os and applications. I completely agree with this, but the text could use a= t least one example of such an application or scenario, and reasons for SRT= P not being applicable to that application, especially since it is fundamen= tal to the argument being made in the draft (that there is no individual RT= P security methods which is suitable for all applications). Basically, the = draft spends a lot of time explaining why RTP is a framework and it is ther= efore not possible to mandate any single security mechanism, however, it do= esn't explain why the most-used security mechanism (SRTP) is not suitable f= or this. 3) Section 6 describes the actual guidelines for future security extensions= for RTP that are mentioned in the abstract, and in that sense forms a impo= rtant part of the draft. It might be useful to more clearly indicate/highli= ght them in that way (e.g. by changing the section title to include the wor= d 'guidelines'). 4) The conclusion (section 7) states 'it is hoped that this memo explains w= hy SRTP is not mandatory as the media security solution for RTP-based syste= ms'. This conclusion could be supported by more substantial arguments in th= e rest of the document, especially related to SRTP, which is not mentioned = apart from the brief mention in section 3, where no actual arguments are gi= ven. See also comment 2). 5) And some nits: - Section 7: comon -> common - Section 7: important consider -> important to consider - Section 7: applications -> application Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FD4DC1EEF3B946C9ABD3CAA59AB45EDBtnonl_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable

Hi Colin/Magnus,


This is my review of draft-ietf-avt-srtp-not-mandatory-09. = Since I'm not a security expert, I can't say anything about the security im= plications of the document. That said, I do have some other comments. = I've not been following the discussion on this topic very closely on the list, so please excuse me if any topics = I bring up have already been discussed on list earlier.


1) The page-header of the draft is 'SRTP is not the only RT= P Security Option'. Although I understand that this header summarizes the r= ationale for writing the draft in the first place, from reading the abstrac= t and introduction of the draft, this header seems a little out of place. I would suggest to either more clearly= describe its relevance in the abstract or introduction (where SRTP is not = mentioned), or choose a different header. 


2) Section 3, paragraph 3 states that SRTP is not suitable = for some scenarios and applications. I completely agree with this, but the = text could use at least one example of such an application or scenario, and= reasons for SRTP not being applicable to that application, especially since it is fundamental to the argument be= ing made in the draft (that there is no individual RTP security methods whi= ch is suitable for all applications). Basically, the draft spends a lo= t of time explaining why RTP is a framework and it is therefore not possible to mandate any single security mechanism,= however, it doesn't explain why the most-used security mechanism (SRTP) is= not suitable for this. 


3) Section 6 describes the actual guidelines for future sec= urity extensions for RTP that are mentioned in the abstract, and in that se= nse forms a important part of the draft. It might be useful to more clearly= indicate/highlight them in that way (e.g. by changing the section title to include the word 'guidelines').&nbs= p;


4) The conclusion (section 7) states 'it is hoped that this= memo explains why SRTP is not mandatory as the media security solution for= RTP-based systems'. This conclusion could be supported by more substantial= arguments in the rest of the document, especially related to SRTP, which is not mentioned apart from the brief me= ntion in section 3, where no actual arguments are given. See also comm= ent 2). 


5) And some nits:

- Section 7: comon -> common

- Section 7: important consider -> important to consider=

- Section 7: applications -> application


Best regards,


Ray

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

--_000_FD4DC1EEF3B946C9ABD3CAA59AB45EDBtnonl_-- From bill.wu@huawei.com Fri Aug 3 00:33:33 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 53DDA21F8D31 for ; Fri, 3 Aug 2012 00:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.819 X-Spam-Level: X-Spam-Status: No, score=-1.819 tagged_above=-999 required=5 tests=[AWL=-2.574, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YFq6SWts-5v for ; Fri, 3 Aug 2012 00:33:29 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 55DB921F8D30 for ; Fri, 3 Aug 2012 00:33:29 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIM14054; Thu, 02 Aug 2012 23:33:27 -0800 (PST) Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 00:31:21 -0700 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml405-hub.china.huawei.com (10.193.5.102) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 00:31:19 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.147]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.003; Fri, 3 Aug 2012 15:30:43 +0800 From: Qin Wu To: "avt@ietf.org" Thread-Topic: Is IDMS XR BLOCK in IDMS draft the only way to calculate one way delay? Thread-Index: Ac1xSeKfLEuYFSGFR7ao94QH5aQM1g== Date: Fri, 3 Aug 2012 07:30:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.111] Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA4301C507szxeml523mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] Is IDMS XR BLOCK in IDMS draft the only way to calculate one way delay? 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, 03 Aug 2012 07:33:33 -0000 --_000_B8F9A780D330094D99AF023C5877DABA4301C507szxeml523mbschi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGmjug0KSSByZWFkIHJlY2VudCB2ZXJzaW9uIG9mIElETVMgZHJhZnQsIGl0IHNlZW1zIHNvbWUg b2YgbXkgY29tbWVudHMgdG8gdmVyc2lvbiAoLTA1KSB3cm90ZSBvbiBKdW4gMjggaGFzbqGvdCBi ZWVuIHRha2VuIGluIHRoZSB2ZXJzaW9uICgtMDYpDQpQbGVhc2Ugc2VlIDoNCmh0dHA6Ly93d3cu aWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9hdnQvY3VycmVudC9tc2cxNTQzNC5odG1sDQoNCk9u ZSBtb3JlIGlzc3VlIEkgbGlrZSB0byByYWlzZSBpcyB0byBJRE1TIFhSIEJMT0NLIGRlZmluZWQg aW4gc2VjdGlvbiA3Og0KSXQgc2VlbXMgdG8gbWUgSURNUyBYUiBCTE9DSyBkZWZpbmVkIGluIElE TVMgZHJhZnQgaXMgb25seSB1c2VkIGZvciB0aGUgZGVkaWNhdGVkIElETVMgYXBwbGljYXRpb24g dG8gcmVwb3J0IG9uZSB3YXkgZGVsYXkgbWV0cmljLCB3aGljaCBmYWlscyB0byBmb2xsb3cgZ3Vp ZGVsaW5lIHdlIGRlZmluZWQgaW4gZHJhZnQtaWV0Zi1hdnRjb3JlLW1vbmFyY2gNCqGwDQphIG5l dyBYUiBibG9jayBzaG91bGQgY29udGFpbiBhIHNpbmdsZSBtZXRyaWMgb3IgYSBzbWFsbCBudW1i ZXIgb2YgbWV0cmljcyByZWxldmFudA0KICAgdG8gYSBzaW5nbGUgcGFyYW1ldGVyIG9mIGludGVy ZXN0IG9yIGNvbmNlcm4sIHJhdGhlciB0aGFuIGNvbnRhaW5pbmcNCiAgIGEgbnVtYmVyIG9mIG1l dHJpY3Mgd2hpY2ggYXR0ZW1wdCB0byBwcm92aWRlIGZ1bGwgY292ZXJhZ2Ugb2YgYWxsDQogICB0 aG9zZSBwYXJhbWV0ZXJzIG9mIGNvbmNlcm4gdG8gYSBzcGVjaWZpYyBhcHBsaWNhdGlvbi4NCg0K obENCkluIG90aGVyIHdvcmRzLCBJRE1TIFhSIEJMT0NLIHNlZW1zIHRvIGJlIGRlZmluZWQgaW4g Y3VycmVudCB2ZXJzaW9uIHRvbyBtdWNoIHNwZWNpZmljIGFuZCBpcyBkaWZmaWN1bHQgdG8gcmUt dXNlZCBieSBvdGhlciBSVFAgYXBwbGljYXRpb25zLg0KDQpPbmUgYWx0ZXJuYXRpdmUgd2F5IGlz IGp1c3QgdG8gcmVwb3J0IG1heGltdW0gb25lIHdheSBkZWxheSBtZXRyaWMgZnJvbSBlYWNoIFND IGlzIG1vcmUgdGhhbiBlbm91Z2guIFRoZSBvbmUgd2F5IGRlbGF5IGNhbiBiZSBjYWxjdWxhdGVk DQpCYXNlZCBvbiB0aGUgc3VtIG9mIG9uZSB3YXkgbmV0d29yayBkZWxheSBhbmQgcmVjZWl2ZXIt c2lkZSBlbmQgc3lzdGVtIGRlbGF5KGluY2x1ZGUgZGVjb2RpbmcgZGVsYXkgYW5kIHBsYXlvdXQg ZGVsYXkpIGFuZCBjYW4gcmVwbGFjZSA2NGJpdCBOVFAgdGltZXN0YW1wICsgMzIgYml0IFJUUCB0 aW1lc3RhbXAgKzMyYml0DQpwcmVzZW50ZWQgdGltZXN0YW1wIGFuZCBzYXZlIGF0IGxlYXN0IDEy IGJ5dGVzLg0KDQpTdXBwb3NlIDMgU0NzIHJlcG9ydCAzIGRpZmZlcmVudCBvbmUgd2F5IGRlbGF5 IGZyb20gZWFjaCBTQywgdGhlIHNlcnZlciBjb3VsZCBjaG9vc2UgdGhlIG1heGltdW0gb25lIHdh eSBkZWxheSBhbmQgc2VuZCB0byBlYWNoIFNDLCBTQw0KQ2FuIGNvbXBhcmUgdGhlIGRpZmZlcmVu Y2UgYmV0d2VlbiByZWNlaXZlZCBvbmUgd2F5IGRlbGF5IGZyb20gdGhlIHNlcnZlciBhbmQgdGhl IG9uZSB3YXkgZGVsYXkgc2VudCBieSBpdHNlbGYgYW5kIHNlZSBob3cgdG8gc3luY2hyb25pemUg bWVkaWEgc3RyZWFtLg0KDQoNCkFub3RoZXIgdGhpbmcgaXMgaXQgc2VlbXMgSURNUyBYUiBCTE9D SyBpcyB1c2VkIHRvIHJlcG9ydCBvbiBzcGVjaWZpYyBSVFAgcGFja2V0IChpLmUuLHRoZSAxc3Qg UlRQIHBhY2tldCBjb250YWluaW5nIHN0YXJ0IG9mIEktZnJhbWUgb3IgbGFzdCByZWNlaXZlZCBw YWNrZXQpLg0KDQpJZiBJRE1TIFhSIEJMT0NLIHJlcG9ydHMgb24gdGhlIDFzdCBwYWNrZXQgY29u dGFpbmluZyBkZWNvZGFibGUgZnJhbWUsIElETVMgWFIgQkxPQ0sgY2FuIHJlcG9ydCBib3RoIHJl Y2VpdmVkIHRpbWVzdGFtcCBhbmQgcHJlc2VudGVkIHRpbWVzdGFtcC4NCg0KDQoNCkhvd2V2ZXIg aWYgSURNUyBYUiBCTE9DSyByZXBvcnRzIG9uIHRoZSBsYXN0IHJlY2VpdmVkIHBhY2tldCBkdXJp bmcgcmVwb3J0aW5nIGludGVydmFsLCBJRE1TIFhSIEJMT0NLIGNhbiBub3QgcmVwb3J0IHByZXNl bnRlZCB0aW1lc3RhbXAuDQoNClRoYXQgbWVhbnMgeW91IGlnbm9yZSBzdW0gb2YgZGVjb2Rpbmcg ZGVsYXkgYW5kIHBsYXlvdXQgZGVsYXkoaS5lLiwgcmVjZWl2ZXItc2lkZSBlbmQgc3lzdGVtIGRl bGF5KSBpbiBlYWNoIFNDLCB3aGVuIGVhY2ggU0MgaGFzIGRpZmZlcmVudCBlbmQgc3lzdGVtIGRl bGF5LA0KDQpUaGF0IG1heSBjYXVzZSBvbmUgd2F5IGRlbGF5IGNhbGN1bGF0ZWQgbm90IHByZWNp c2VseSBhbmQgaW1wYWN0IHN5bmNocm9uaXphdGlvbiBtZXRhZGF0YSBvZiBtZWRpYSBzdHJlYW0g c2VudCB0byBkaWZmZXJlbnQgU0NzLg0KDQoNCg0KQWxzbyBjb21wYXJpbmcgcmVwb3J0aW5nIG9u bHkgbWF4aW11bSBvbmUgd2F5IGRlbGF5IG1ldHJpYywgcmVwb3J0IG9uIHRoZSBsYXN0IHJlY2Vp dmVkIHBhY2tldCBtYXkgYmUgbm90IGNsb3NlIG9yIHByZWNpc2UgdG8gbWF4aW11bSBvbmUgd2F5 IGRlbGF5IG1ldHJpYw0KDQpTaW5jZSBtYXhpbXVtIG9uZSB3YXkgZGVsYXkgc2hvdWxkIGtlZXAg dHJhY2sgb2YgZWFjaCByZWNlaXZlZCBSVFAgcGFja2V0IGluIGVhY2ggcmVwb3J0IEludGVydmFs IGFuZCBnZXQgdGhlIG1heGltdW0gb25lIHdheSBkZWxheSBpbiB0aGUgd2hvbGUgcmVwb3J0aW5n DQoNCmludGVydmFsLg0KDQpSZWdhcmRzIQ0KLVFpbg0K --_000_B8F9A780D330094D99AF023C5877DABA4301C507szxeml523mbschi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi=A3=BA

I read recent version of IDMS d= raft, it seems some of my comments to version (-05) wrote on Jun 28 hasn=A1= =AFt been taken in the version (-06)

Please see : =

http://www.ietf.org/mail-archiv= e/web/avt/current/msg15434.html

 

One more issue I like to raise = is to IDMS XR BLOCK defined in section 7:

It seems to me IDMS XR BLOCK de= fined in IDMS draft is only used for the dedicated IDMS application to repo= rt one way delay metric, which fails to follow guideline we defined in draf= t-ietf-avtcore-monarch

=A1=B0

a new XR block should contain a single metric or a smal= l number of metrics relevant

=    to a single parameter of interest or concern, rather than cont= aining

=    a number of metrics which attempt to provide full coverage of = all

=    those parameters of concern to a specific application.

 

=A1=B1

In other words, IDMS XR BLOCK s= eems to be defined in current version too much specific and is difficult to= re-used by other RTP applications.

 

One alternative way is just to = report maximum one way delay metric from each SC is more than enough. The o= ne way delay can be calculated

Based on the sum of one way net= work delay and receiver-side end system delay(include decoding delay and pl= ayout delay) and can replace 64bit NTP timestamp + 32 bit RTP timestamp= +32bit

presented timestamp and save at= least 12 bytes.

 

Suppose 3 SCs report 3 differen= t one way delay from each SC, the server could choose the maximum one way d= elay and send to each SC, SC

Can compare the difference betw= een received one way delay from the server and the one way delay sent by it= self and see how to synchronize media stream.

 

Another thing is it seems ID= MS XR BLOCK is used to report on specific RTP packet (i.e.,the 1st RTP pack= et containing start of I-frame or last received packet).<= /p>

If IDMS XR BLOCK reports on = the 1st packet containing decodable frame, IDMS XR BLOCK can rep= ort both received timestamp and presented timestamp.

 

However if IDMS XR BLOCK rep= orts on the last received packet during reporting interval, IDMS XR BLOCK c= an not report presented timestamp.

That means you ignore sum of= decoding delay and playout delay(i.e., receiver-side end system delay) in = each SC, when each SC has different end system delay,

That may cause one way delay= calculated not precisely and impact synchronization metadata of media stre= am sent to different SCs.

 

Also comparing reporting onl= y maximum one way delay metric, report on the last received packet may be n= ot close or precise to maximum one way delay metric

Since maximum one way delay = should keep track of each received RTP packet in each report Interval and g= et the maximum one way delay in the whole reporting

interval.<= /p>

 

Regards!

-Qin

--_000_B8F9A780D330094D99AF023C5877DABA4301C507szxeml523mbschi_-- From bill.wu@huawei.com Fri Aug 3 09:58: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 A132021F8E21 for ; Fri, 3 Aug 2012 09:58:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.743 X-Spam-Level: *** X-Spam-Status: No, score=3.743 tagged_above=-999 required=5 tests=[AWL=-8.067, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, GB_SUMOF=5, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, J_CHICKENPOX_57=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ESTABLISH_PX=2.222, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mkb4Xb1Oav6I for ; Fri, 3 Aug 2012 09:58:01 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA9A21F8DD4 for ; Fri, 3 Aug 2012 09:58:01 -0700 (PDT) Received: from 172.18.9.243 (EHLO dfweml201-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIQ96664; Fri, 03 Aug 2012 08:58:01 -0800 (PST) Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 09:55:02 -0700 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Fri, 3 Aug 2012 09:55:09 -0700 Received: from SZXEML523-MBS.china.huawei.com ([169.254.6.147]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.003; Sat, 4 Aug 2012 00:55:04 +0800 From: Qin Wu To: Mario Montagud Climent Thread-Topic: [AVTCORE] Is IDMS XR BLOCK in IDMS draft the only way to calculate one way delay? Thread-Index: Ac1xSeKfLEuYFSGFR7ao94QH5aQM1v//90iA//9naYA= Date: Fri, 3 Aug 2012 16:55:03 +0000 Message-ID: References: <20120803165929.21192kn198xyf3v5@wm.upv.es> In-Reply-To: <20120803165929.21192kn198xyf3v5@wm.upv.es> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.44] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "avt@ietf.org" Subject: [AVTCORE] =?gb2312?b?tPC4tDogIElzIElETVMgWFIgQkxPQ0sgaW4gSURNUyBk?= =?gb2312?b?cmFmdCB0aGUgb25seSB3YXkgdG8gY2FsY3VsYXRlIG9uZSB3YXkgZGVsYXk/?= 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, 03 Aug 2012 16:58:02 -0000 SGksIE1hcmlvOg0KSSB0aGluayByZXBvcnRpbmcgb25lIHdheSBuZXR3b3JrIGRlbGF5IG9yIG9u ZSB3YXkgZGVsYXkgaW5jbHVkaW5nIGRlY29kaW5nIGRlbGF5IGFuZCBwbGF5b3V0IGRlbGF5IGlz IG1vcmUgc3RyYWlnaHRmb3J3YXJkIGFuZCBzaW1wbGUgd2F5IGNvbXBhcmluZyByZXBvcnRpbmcg bWVkaWEgc3luY2hyb25pemF0aW9uIG1ldGFkYXRhIGluZm9ybWF0aW9uIHVzaW5nIElETVMgWFIg YmxvY2suDQpCdXQgbWF5YmUgYm90aCByZXBvcnRpbmcgY2FuIGNvZXhpc3QgYW5kIGJlIHVzZWQg dG8gc3VwcG9ydCBJRE1TLiANClBsZWFzZSBzZWUgbXkgcmVwbGllcyBpbmxpbmUgYmVsb3cuDQoN ClJlZ2FyZHMhDQotUWluDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTWFyaW8gTW9udGFn dWQgQ2xpbWVudCBbbWFpbHRvOm1hbW9udG9yQHBvc2dyYWRvLnVwdi5lc10gDQq3osvNyrG85Dog MjAxMsTqONTCM8jVIDIyOjU5DQrK1bz+yMs6IFFpbiBXdQ0Ks63LzTogYXZ0QGlldGYub3JnDQrW 98ziOiBSZTogW0FWVENPUkVdIElzIElETVMgWFIgQkxPQ0sgaW4gSURNUyBkcmFmdCB0aGUgb25s eSB3YXkgdG8gY2FsY3VsYXRlIG9uZSB3YXkgZGVsYXk/DQoNCg0KSGkgUWluLCBhbGwsDQoNClNl ZSBvdXIgY29tbWVudHMgaW5saW5lLg0KDQpRaW4gV3UgPGJpbGwud3VAaHVhd2VpLmNvbT4gZXNj cmliaaiuOg0KDQo+IEhpPw0KPiBJIHJlYWQgcmVjZW50IHZlcnNpb24gb2YgSURNUyBkcmFmdCwg aXQgc2VlbXMgc29tZSBvZiBteSBjb21tZW50cyB0byAgDQo+IHZlcnNpb24gKC0wNSkgd3JvdGUg b24gSnVuIDI4IGhhc24/dCBiZWVuIHRha2VuIGluIHRoZSB2ZXJzaW9uICgtMDYpDQo+IFBsZWFz ZSBzZWUgOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvYXZ0L2N1cnJl bnQvbXNnMTU0MzQuaHRtbA0KPg0KPiBPbmUgbW9yZSBpc3N1ZSBJIGxpa2UgdG8gcmFpc2UgaXMg dG8gSURNUyBYUiBCTE9DSyBkZWZpbmVkIGluIHNlY3Rpb24gNzoNCj4gSXQgc2VlbXMgdG8gbWUg SURNUyBYUiBCTE9DSyBkZWZpbmVkIGluIElETVMgZHJhZnQgaXMgb25seSB1c2VkIGZvciAgDQo+ IHRoZSBkZWRpY2F0ZWQgSURNUyBhcHBsaWNhdGlvbiB0byByZXBvcnQgb25lIHdheSBkZWxheSBt ZXRyaWMsIHdoaWNoICANCj4gZmFpbHMgdG8gZm9sbG93IGd1aWRlbGluZSB3ZSBkZWZpbmVkIGlu IGRyYWZ0LWlldGYtYXZ0Y29yZS1tb25hcmNoDQo+ID8NCj4gYSBuZXcgWFIgYmxvY2sgc2hvdWxk IGNvbnRhaW4gYSBzaW5nbGUgbWV0cmljIG9yIGEgc21hbGwgbnVtYmVyIG9mICANCj4gbWV0cmlj cyByZWxldmFudA0KPiAgICB0byBhIHNpbmdsZSBwYXJhbWV0ZXIgb2YgaW50ZXJlc3Qgb3IgY29u Y2VybiwgcmF0aGVyIHRoYW4gY29udGFpbmluZw0KPiAgICBhIG51bWJlciBvZiBtZXRyaWNzIHdo aWNoIGF0dGVtcHQgdG8gcHJvdmlkZSBmdWxsIGNvdmVyYWdlIG9mIGFsbA0KPiAgICB0aG9zZSBw YXJhbWV0ZXJzIG9mIGNvbmNlcm4gdG8gYSBzcGVjaWZpYyBhcHBsaWNhdGlvbi4NCj4NCj4gPw0K PiBJbiBvdGhlciB3b3JkcywgSURNUyBYUiBCTE9DSyBzZWVtcyB0byBiZSBkZWZpbmVkIGluIGN1 cnJlbnQgdmVyc2lvbiAgDQo+IHRvbyBtdWNoIHNwZWNpZmljIGFuZCBpcyBkaWZmaWN1bHQgdG8g cmUtdXNlZCBieSBvdGhlciBSVFAgIA0KPiBhcHBsaWNhdGlvbnMuDQo+DQo+IE9uZSBhbHRlcm5h dGl2ZSB3YXkgaXMganVzdCB0byByZXBvcnQgbWF4aW11bSBvbmUgd2F5IGRlbGF5IG1ldHJpYyAg DQo+IGZyb20gZWFjaCBTQyBpcyBtb3JlIHRoYW4gZW5vdWdoLiBUaGUgb25lIHdheSBkZWxheSBj YW4gYmUgY2FsY3VsYXRlZA0KPiBCYXNlZCBvbiB0aGUgc3VtIG9mIG9uZSB3YXkgbmV0d29yayBk ZWxheSBhbmQgcmVjZWl2ZXItc2lkZSBlbmQgIA0KPiBzeXN0ZW0gZGVsYXkoaW5jbHVkZSBkZWNv ZGluZyBkZWxheSBhbmQgcGxheW91dCBkZWxheSkgYW5kIGNhbiAgDQo+IHJlcGxhY2UgNjRiaXQg TlRQIHRpbWVzdGFtcCArIDMyIGJpdCBSVFAgdGltZXN0YW1wICszMmJpdA0KPiBwcmVzZW50ZWQg dGltZXN0YW1wIGFuZCBzYXZlIGF0IGxlYXN0IDEyIGJ5dGVzLg0KPg0KPiBTdXBwb3NlIDMgU0Nz IHJlcG9ydCAzIGRpZmZlcmVudCBvbmUgd2F5IGRlbGF5IGZyb20gZWFjaCBTQywgdGhlICANCj4g c2VydmVyIGNvdWxkIGNob29zZSB0aGUgbWF4aW11bSBvbmUgd2F5IGRlbGF5IGFuZCBzZW5kIHRv IGVhY2ggU0MsIFNDDQo+IENhbiBjb21wYXJlIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gcmVjZWl2 ZWQgb25lIHdheSBkZWxheSBmcm9tIHRoZSAgDQo+IHNlcnZlciBhbmQgdGhlIG9uZSB3YXkgZGVs YXkgc2VudCBieSBpdHNlbGYgYW5kIHNlZSBob3cgdG8gIA0KPiBzeW5jaHJvbml6ZSBtZWRpYSBz dHJlYW0uDQo+DQoNCltGICYgTV0gV2UgZG9uP3QgdGhpbmsgdGhlIFhSIGJsb2NrIGZvciBJRE1T LCBvciBJRE1TIHJlcG9ydCwgYXR0ZW1wdHMgIA0KdG8gY292ZXIgYSA/ZnVsbCBjb3ZlcmFnZT8g b2YgcmVsZXZhbnQgbWV0cmljcyBvZiBjb25jZXJuIHRvID9hICANCnNwZWNpZmljIGFwcGxpY2F0 aW9uPy4gSXQgcmVwb3J0cyBvbiByZWNlcHRpb24gdGltZXMgKG1hbmRhdG9yeSkgIA0KYW5kL29y IHByZXNlbnRhdGlvbiB0aW1lcyAob3B0aW9uYWwpLCB3aGljaCBpbiBvdXIgb3BpbmlvbiBhcmUg dHdvICANCnJlbGV2YW50IG1ldHJpY3MgZm9yIHRob3NlIGFwcGxpY2F0aW9ucyByZXF1aXJpbmcg SURNUyAobm90IGZvciBhICANCmRlZGljYXRlZCBhcHBsaWNhdGlvbiksIGJvdGggcmVmZXJyZWQg dG8gdGhlIFJUUCB0aW1lc3RhbXAgb2YgYSAgDQpzcGVjaWZpYyBSVFAgcGFja2V0Lg0KDQpbUWlu XTogbXkgcG9pbnQgaXMgdGhvc2UgbWV0cmljcyBhcmUgb25seSBkZWRpY2F0ZWQgYnkgSURNUyBh cHBsaWNhdGlvbi4NCg0KUmVwb3J0aW5nIG9uIFJUUCBwYWNrZXQgcmVjZXB0aW9uIHRpbWVzIGlz IG1hbmRhdG9yeS4gSXQgY2FuIGJlIHVzZWQgIA0KdG8gaW5mZXIgdGhlIG9uZS13YXkgbmV0d29y ayBkZWxheSB3aGljaCBjYW4gYmUgZWFzaWx5IGNhbGN1bGF0ZWQgYnkgIA0KdGhlIHRhcmdldCBz aWRlIChlLmcuIE1TQVMpLiANCg0KW1Fpbl06IFdoeSBub3QgcmVwb3J0IG9uZSB3YXkgbmV0d29y ayBkZWxheSBtZXRyaWMgZGlyZWN0bHk/DQpJdCBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZCBhbmQg c2ltcGxlIGFuZCBzYXZlIG1vcmUgYnl0ZXMgdG8gYmUgc2VudC4NCg0KUHJlc2VudGF0aW9uIHRp bWVzIGdpdmUgaW5mb3JtYXRpb24gb2YgIA0KdGhlIGVuZC10by1lbmQgb25lLXdheSBkZWxheSAo ZnJvbSBnZW5lcmF0aW9uIGF0IHRoZSBzZW5kZXIgc2lkZSB0byAgDQpwcmVzZW50YXRpb24gYXQg dGhlIGNsaWVudCBzaWRlKSBmb3IgdGhlIFJUUCBwYWNrZXQgdGhlIFhSIGJsb2NrICANCnJlcG9y dHMgb24sIGFuZCB0aGV5IGFyZSBvcHRpb25hbCBzaW5jZSBub3QgYWxsIHRoZSBhcHBsaWNhdGlv bnMgd291bGQgIA0KYmUgYWJsZSB0byB0cmFjayBSVFAgcGFja2V0cyB1bnRpbCB0aGVpciBwcmVz ZW50YXRpb24gdGltZSAodGhpcyBjYW4gIA0KYmUgc2VlbiBhcyBhIGxheWVyLXZpb2xhdGlvbiBp biBzb21lIFJUUCBpbXBsZW1lbnRhdGlvbnMsIGFzIGl0IHdhcyAgDQphbHJlYWR5IGRpc2N1c3Nl ZCBpbiB0aGUgQVZUQ09SRSBtYWlsaW5nIGxpc3QgaW4gcHJldmlvdXMgdmVyc2lvbnMgb2YgIA0K dGhlIElETVMgZHJhZnQpLg0KDQpbUWluXTogUmlnaHQgcHJlc2VudGVkIHRpbWVzdGFtcCBpcyBv cHRpb25hbCBtZXRyaWMgbm90IG1hbmRhdG9yeSBtZXRyaWMuDQpJZiBzb21lIFNDcyBzdXBwb3J0 IHJlcG9ydGluZyBwcmVzZW50ZWQgdGltZXN0YW1wIHdoaWxlIHNvbWUgU0NzIGRvbid0LA0KdGhl IHNldmVyIG11c3QgaWdub3JlIHRoaXMgcHJlc2VudGVkIHRpbWVzdGFtcCBldmVuIHNvbWUgU0Nz IHNlbmQNCnRoZWlyIG93biBwcmVzZW50ZWQgdGltZXN0YW1wLg0KDQpGcm9tIHRoaXMgcGVyc3Bl Y3RpdmUsIGl0IGlzIGVxdWl2YWxlbnQgdG8gcmVwb3J0IHJlY2VpdmVkIHRpbWVzdGFtcCBvciBv bmUgd2F5IG5ldHdvcmsgZGVsYXkuDQpXaHkgd2UgY2hvb3NlIHRvIHJlcG9ydCByZWNlaXZlZCB0 aW1lc3RhbXBlLg0KDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB3ZSBjYW4gdGFrZSB0aGUgc3VtIG9m IGRlY29kaW5nIGRlbGF5IGFuZCBwbGF5b3V0IGRlbGF5IGF0IHRoZSBjbGllbnQgc2lkZSBpbnRv IGFjY291bnQgd2hlbg0KV2UgY2hvb3NlIHRvIHJlcG9ydCBvbmUgd2F5IGRlbGF5IGRpcmVjdGx5 LiBUaGF0IGlzIHRvIHNheSwgU0MgY2FuIHNlbmQgb25seSBvbmUgd2F5IG5ldHdvcmsgZGVsYXkg dG8gdGhlIHNlcnZlciwNCk9ubHkgU0MgcmVwb3J0IHRoZSBzdW0gb2Ygb25lIHdheSBuZXR3b3Jr IGRlbGF5IGluIHRoZSBuZXR3b3JrIHNpZGUgYW5kIGRlY29kaW5nIGRlbGF5LCBwbGF5b3V0IGRl bGF5IGF0IHRoZSBjbGllbnQgc2lkZSB3aGljaCB3ZSBjYWxsIGl0DQoib25lIHdheSBkZWxheSIs IHRoZW4gd2UgY2FuIHVzZSBvbmUgZmxhZyBiaXQgaW4gdGhlIEJsb2NrIGhlYWRlciB0byBpbmRp Y2F0ZSB3aGljaCB0byByZXBvcnQuDQpJbiB0aGlzIHNlbnNlLCBpdCBpcyBlcXVpdmFsZW50IHRv IHJlcG9ydCByZWNlaXZlZCB0aW1lc3RhbXAgYW5kIHByZXNlbnRlZCB0aW1lc3RhbXAgb3IgIm9u ZSB3YXkgZGVsYXkiLg0KDQoNCkJ5IGluY2x1ZGluZyBib3RoIG1ldHJpY3MsIHRoZSBNU0FTIGNh biBrbm93IGlmIGFuIGluY3JlYXNlL2RlY3JlYXNlICANCm9mIHRoZSBlbmQtdG8tZW5kIGRlbGF5 IGZvciBhIHNwZWNpZmljIFNDIGlzIGR1ZSB0byB0aGUgIA0KaW5jcmVhc2UvZGVjcmVhc2Ugb2Yg dGhlIG5ldHdvcmsgZGVsYXkgKGUuZy4gY29uZ2VzdGlvbiBpbiB0aGUgIA0KbmV0d29yayksIHNp bmNlIGl0IGlzIGdpdmVuIGJ5IHRoZSB0aW1lIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgIA0KcmVj ZXB0aW9uIGFuZCBnZW5lcmF0aW9uIHRpbWUgb2YgdGhhdCBSVFAgcGFja2V0LCBvciBpdCBpcyBk dWUgdG8gdGhlICANCmluY3JlYXNlL2RlY3JlYXNlIG9mIHRoZSBkZWxheSBhdCB0aGUgZW5kLXN5 c3RlbSBzaWRlIChlLmcuIGJ1ZmZlcmluZywgIA0KZGVjb2RpbmcsIGRlLXBhY2tldGl6YXRpb24s IHByb2Nlc3NpbmcsIHJlbmRlcmluZywgZXRjLiwgZGVsYXlzKSwgIA0Kc2luY2UgaXQgaXMgZ2l2 ZW4gYnkgdGhlIHRpbWUgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBwcmVzZW50YXRpb24gYW5kICAN CnJlY2VwdGlvbiB0aW1lIGZvciB0aGF0IFJUUCB0aW1lc3RhbXAuDQoNCldlIHRoaW5rIGJvdGgg bWV0cmljcyBhcmUgbmVlZGVkIHNpbmNlIHRoZXkgaW5kaWNhdGUgdXNlZnVsICANCmluZm9ybWF0 aW9uIGZvciBJRE1TLg0KDQpbUWluXTogWW91IGNhbiBub3QgZ3VhcmFudGVlIHJlcG9ydGluZyBi b3RoIG1ldHJpY3Mgc2luY2UgaW4gc29tZSBjYXNlcywgU0NzDQphcmUgbm90IGludGVsbGlnZW50 IHRvIHJlcG9ydCBwcmVzZW50ZWQgdGltZXN0YW1wLg0KPg0KPiBBbm90aGVyIHRoaW5nIGlzIGl0 IHNlZW1zIElETVMgWFIgQkxPQ0sgaXMgdXNlZCB0byByZXBvcnQgb24gIA0KPiBzcGVjaWZpYyBS VFAgcGFja2V0IChpLmUuLHRoZSAxc3QgUlRQIHBhY2tldCBjb250YWluaW5nIHN0YXJ0IG9mICAN Cj4gSS1mcmFtZSBvciBsYXN0IHJlY2VpdmVkIHBhY2tldCkuDQo+DQo+IElmIElETVMgWFIgQkxP Q0sgcmVwb3J0cyBvbiB0aGUgMXN0IHBhY2tldCBjb250YWluaW5nIGRlY29kYWJsZSAgDQo+IGZy YW1lLCBJRE1TIFhSIEJMT0NLIGNhbiByZXBvcnQgYm90aCByZWNlaXZlZCB0aW1lc3RhbXAgYW5k ICANCj4gcHJlc2VudGVkIHRpbWVzdGFtcC4NCj4NCj4NCj4NCj4gSG93ZXZlciBpZiBJRE1TIFhS IEJMT0NLIHJlcG9ydHMgb24gdGhlIGxhc3QgcmVjZWl2ZWQgcGFja2V0IGR1cmluZyAgDQo+IHJl cG9ydGluZyBpbnRlcnZhbCwgSURNUyBYUiBCTE9DSyBjYW4gbm90IHJlcG9ydCBwcmVzZW50ZWQg dGltZXN0YW1wLg0KPg0KPiBUaGF0IG1lYW5zIHlvdSBpZ25vcmUgc3VtIG9mIGRlY29kaW5nIGRl bGF5IGFuZCBwbGF5b3V0IGRlbGF5KGkuZS4sICANCj4gcmVjZWl2ZXItc2lkZSBlbmQgc3lzdGVt IGRlbGF5KSBpbiBlYWNoIFNDLCB3aGVuIGVhY2ggU0MgaGFzICANCj4gZGlmZmVyZW50IGVuZCBz eXN0ZW0gZGVsYXksDQo+DQo+IFRoYXQgbWF5IGNhdXNlIG9uZSB3YXkgZGVsYXkgY2FsY3VsYXRl ZCBub3QgcHJlY2lzZWx5IGFuZCBpbXBhY3QgIA0KPiBzeW5jaHJvbml6YXRpb24gbWV0YWRhdGEg b2YgbWVkaWEgc3RyZWFtIHNlbnQgdG8gZGlmZmVyZW50IFNDcy4NCj4NCg0KW0YgJiBNXSBJZiBw cmVzZW50YXRpb24gdGltZXMgYXJlIGluY2x1ZGVkIGluIHRoZSBYUiBibG9jayBmb3IgSURNUywg IA0KdGhlIFNDcyBTSE9VTEQgcmVwb3J0IG9uIHRoZSBsYXN0IHByZXNlbnRlZCBSVFAgVGltZXN0 YW1wLCBub3Qgb24gdGhlICANCmxhc3QgcmVjZWl2ZWQgUlRQIFRpbWVzdGFtcCwgYXMgaXQgaXMg aW5kaWNhdGVkIGluIHRoZSBsYXN0IHZlcnNpb24gb2YgIA0KdGhlIElETVMgZHJhZnQuIFRoaXMg c29sdmVzIHRoZSBzaXR1YXRpb24geW91IG1lbnRpb24uDQoNCltRaW5dOiBUaGF0IHN0aWxsIG5v dCBhZGRyZXNzZXMgbXkgY29tbWVudHMgYWJvdmUgc2luY2UgaW4gc29tZSBjYXNlcywgDQpTQyBt YXkgYmUgbm90IGFibGUgdG8gcmVwb3J0IHByZXNlbnRlZCB0aW1lc3RhbXAgZXZlbiB0aGV5IGNh biByZXBvcnQNClJlY2VpdmVkIHRpbWVzdGFtcC4NCj4NCj4gQWxzbyBjb21wYXJpbmcgcmVwb3J0 aW5nIG9ubHkgbWF4aW11bSBvbmUgd2F5IGRlbGF5IG1ldHJpYywgcmVwb3J0ICANCj4gb24gdGhl IGxhc3QgcmVjZWl2ZWQgcGFja2V0IG1heSBiZSBub3QgY2xvc2Ugb3IgcHJlY2lzZSB0byBtYXhp bXVtICANCj4gb25lIHdheSBkZWxheSBtZXRyaWMNCj4NCj4gU2luY2UgbWF4aW11bSBvbmUgd2F5 IGRlbGF5IHNob3VsZCBrZWVwIHRyYWNrIG9mIGVhY2ggcmVjZWl2ZWQgUlRQICANCj4gcGFja2V0 IGluIGVhY2ggcmVwb3J0IEludGVydmFsIGFuZCBnZXQgdGhlIG1heGltdW0gb25lIHdheSBkZWxh eSBpbiAgDQo+IHRoZSB3aG9sZSByZXBvcnRpbmcNCj4NCj4gaW50ZXJ2YWwuDQo+DQo+IFJlZ2Fy ZHMhDQo+IC1RaW4NCj4NCg0KW0YgJiBNXSBEZXNwaXRlIG9mIHRoZSBvbmUtd2F5IGRlbGF5IGNh biBiZSB2YXJpYWJsZSBkdXJpbmcgYW4gUlRDUCAgDQpyZXBvcnQgaW50ZXJ2YWwgZHVlIHRvIG5l dHdvcmsgaml0dGVyLCB0aGUgZW5kLXRvLWVuZCBkZWxheSBzaG91bGQgYmUgIA0Ka2VwdCBpbiBh IHNtb290aCB3YXkgaWYgYSBwcm9wZXIgcGxheW91dCBidWZmZXJpbmcgKGludHJhLXN0cmVhbSBz eW5jKSAgDQppcyBhZG9wdGVkIGF0IHRoZSBjbGllbnQgc2lkZSAoaS5lLiB0aGUgdGVtcG9yYWwg ZGVwZW5kZW5jaWVzIG9mIHRoZSAgDQppbmNvbWluZyBtZWRpYSBzdHJlYW0gYXJlIHJlLXN0YWJs aXNoZWQgYXQgdGhlIGppdHRlci9wbGF5b3V0IGJ1ZmZlciAgDQpzaWRlKS4NCg0KW1Fpbl06IEl0 IGRvZXNuJ3QgbWF0dGVyLCBzaW5jZSBzdXBwb3NlIGVuZCB0byBlbmQgZGVsYXkgaXMga2VwdCBp biBhIHNtb290aCB3YXksDQpUaGF0IG1lYW5zIG1heGltdW0gb25lIHdheSBkZWxheSBkb2Vzbid0 IGRvIGZyZXF1ZW50IGNoYW5nZS4NCg0KQW5vdGhlciBpc3N1ZSBpcyB0aGF0IHJlcG9ydGluZyBv biBsYXN0IHJlY2VpdmVkL3ByZXNlbnRlZCBSVFAgIA0KdGltZXN0YW1wcyBnaXZlcyBpbmZvcm1h dGlvbiBvbiB0aGUgbGFzdCB1cGRhdGVkIHN0YXRpc3RpY3MgZm9yIElETVMuICANClJlcG9ydGlu ZyBvbiB0aGUgbWF4aW11bSBvbmUtd2F5IGRlbGF5IG1heSBub3QgYmUgYXMgYWNjdXJhdGUgaWYg ZS5nLiAgDQphIHNwb3JhZGljIHBlYWsgb2YgZGVsYXkgb2NjdXJzIGR1cmluZyB0aGUgUlRDUCBy ZXBvcnQgaW50ZXJ2YWwuDQoNCltRaW5dOiBJIGRpc2FncmVlLCBob3cgZG8geW91IGd1YXJhbnRl ZSB0aGUgc3BvcmFkaWMgcGVhayBvZiBkZWxheSBpcyBub3QgYXBwbGllZA0KdG8gbGFzdCByZWNl aXZlZC9wcmVzZW50ZWQgUlRQIHRpbWVzdGFtcC4gSW4gb3RoZXIgd29yZHMsDQpSZXBvcnQgbGFz dCByZWNlaXZlZC9wcmVzZW50ZWQgdGltZXN0YW1wIGlzIHlvdSBvbmx5IG1lYXN1cmUgb25jZSBp biBvbmUgcmVwb3J0aW5nDQpJbnRlcnZhbCwgaG93IGRvIHlvdSBndWFyYW50ZWUgdGhlIHJlY2Vp dmVkL3ByZXNlbnRlZCB0aW1lc3RhbXAgY2FuIHJlZmxlY3QgdGhlIHJlYWwgb25lIHdheSBkZWxh eSBhbmQNCk5vdCBhZmZlY3QgYnkgc3BvcmFkaWMgcGVhayBvZiBkZWxheS4NCg0KT24gdGhlIGhh bmQsIGJhc2VkIG9uIFJGQzI2NzksIG9uZSB3YXkgZGVsYXkgDQpmb3IgSVBQTSwgc3VjaCBwZWFr IHZhbHVlIGNhbiBiZSBzb3J0ZWQgb3V0Lg0KQWxzbyB5b3UgY2FuIGNob29zZSB0byByZXBvcnQg YXZlcmFnZSB2YWx1ZSBvZiBvbmUgd2F5IGRlbGF5IHlvdSByZWNlaXZlZCBpbiBlYWNoIHJlcG9y dGluZyBpbnRlcnZhbC4NCg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgY29tbWVudHMhDQoNClJlZ2Fy ZHMsIEZlcm5hbmRvIEJvcm9uYXQgJiBNYXJpbyBNb250YWd1ZA0KDQoNCg0K From ron.even.tlv@gmail.com Fri Aug 3 10:59: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 5EF8021F8DC9 for ; Fri, 3 Aug 2012 10:59:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.854 X-Spam-Level: X-Spam-Status: No, score=-2.854 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gkZF1ZhliRyP for ; Fri, 3 Aug 2012 10:59:05 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id D60C221F8D7B for ; Fri, 3 Aug 2012 10:59:04 -0700 (PDT) Received: by yhq56 with SMTP id 56so1252086yhq.31 for ; Fri, 03 Aug 2012 10:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=EY7fAHXIqC7O4n/w29kfQwMoh08uSZ0QAEqMvQ9wdXo=; b=sfWbjRcDZp/DFnc+GhE+riMLOYQ0yiX6SidQH45Eq4oqEhX89sF7wSXtQ1hYHqvYAC pTOimbDyYZKsbFyliJhZ9+V76kqjCvCR2eNrDn2+n7RbD4vc8k8YsKq1XkFEMI9KqOuG TnQ3bbrfQSTzQKnxz7mtPWD6UFL1Y55L2kl4VOzTSLnmAccp54DwQV+mcuJ920rp2Vex a02r01ki2UMuDljhEVYqDdsJOwev7C/nDuSNAPMoHLNJRpN3aGCAyu8rYrGbmMkSWTv2 76VBKtdItJaAVid1T24MK1lRb4pAwDo3zdNZoODYjiLW3wqZdFbWfeZQpT7k9NWbRfDx Fjww== Received: by 10.50.212.35 with SMTP id nh3mr4988388igc.19.1344016743980; Fri, 03 Aug 2012 10:59:03 -0700 (PDT) Received: from RoniE ([2001:df8:0:16:dd2:5043:f9e7:78f4]) by mx.google.com with ESMTPS id k6sm23350560igz.9.2012.08.03.10.59.02 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 03 Aug 2012 10:59:02 -0700 (PDT) From: "Roni Even" To: Date: Fri, 3 Aug 2012 20:57:55 +0200 Message-ID: <001801cd71a9$e59e2210$b0da6630$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01CD71BA.A926F210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1xqc42fCS8pIfFQV6SG2MdBlqPzg== Content-Language: en-us Subject: [AVTCORE] new version of clock source presentation 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, 03 Aug 2012 17:59:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0019_01CD71BA.A926F210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I am sorry but we got last minute change in the presentation so please download the latest version from today Roni Even ------=_NextPart_000_0019_01CD71BA.A926F210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I am sorry but = we got last minute change in the presentation so please download the = latest version from today

Roni = Even

------=_NextPart_000_0019_01CD71BA.A926F210-- From ron.even.tlv@gmail.com Mon Aug 6 15:51:48 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 18D7011E80A5 for ; Mon, 6 Aug 2012 15:51:48 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrsAPCBmqMM7 for ; Mon, 6 Aug 2012 15:51:47 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A96411E808A for ; Mon, 6 Aug 2012 15:51:47 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7401724obb.31 for ; Mon, 06 Aug 2012 15:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=UW2x7mVSkKEsLZdtl565vY0zgks8OUlZLBZr12oXnGw=; b=FOYTJlMitUd03rJMtD1am8jMWpkpvO4P9xu4Jv9poMpLm7VyQDjIruuFfeWYi5nDxu fqMr60jpDzzOu74ZWTCMkfRYIqA+HajcN7BUpoOaKubw9ou5IaRJ9bZWIo1BMOBxynNZ fgvH/jLmDNWJ/bIochxLePGQUHLnGtBFAiKRUziO0MA2BktHtwj09Yk+WFE1f5jhPPoL SS2Htr1SVdYk/3oOEoPuRE3tM9JCMhAGBfMZNGHbsZ1Z7dY7QbfgCEb4GjfadAJfG5LK qpT/ACQdrj6Oto/YnNDZFl5uECvHyThzzhKSw5jnGjbQMhp8QFYK2Z4BSyYCe0SM04VN H/vQ== Received: by 10.60.2.74 with SMTP id 10mr21309458oes.64.1344293507161; Mon, 06 Aug 2012 15:51:47 -0700 (PDT) Received: from RoniE ([75.111.46.80]) by mx.google.com with ESMTPS id kf5sm313860obc.7.2012.08.06.15.51.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 15:51:46 -0700 (PDT) From: "Roni Even" To: Date: Tue, 7 Aug 2012 01:50:38 +0200 Message-ID: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0082_01CD743F.0CD32BE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac10LhTmju1M62YdRMialEQ0Fp3CYA== Content-Language: en-us Subject: [AVTCORE] IETF 84 AVTcore minutes 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, 06 Aug 2012 22:51:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0082_01CD743F.0CD32BE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We have uploaded the AVTcore minutes. http://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore Please review and send any comments to the mailing list Thanks Roni and Magnus AVTcore chairs ------=_NextPart_000_0082_01CD743F.0CD32BE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We have = uploaded the AVTcore minutes.  ht= tp://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore =

Please review and send any comments = to the mailing list

 

Thanks

Roni and = Magnus AVTcore chairs

------=_NextPart_000_0082_01CD743F.0CD32BE0-- From jonathan@vidyo.com Mon Aug 6 16:38:33 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 5191511E80A5 for ; Mon, 6 Aug 2012 16:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyHMbqYsWfwb for ; Mon, 6 Aug 2012 16:38:32 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 03DE311E80BF for ; Mon, 6 Aug 2012 16:38:31 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9E358A68CF8; Mon, 6 Aug 2012 19:17:05 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C0AE8A68D97; Mon, 6 Aug 2012 19:17:04 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Mon, 6 Aug 2012 19:38:25 -0400 From: Jonathan Lennox To: Roni Even , "avt@ietf.org" Date: Mon, 6 Aug 2012 19:38:29 -0400 Thread-Topic: [AVTCORE] IETF 84 AVTcore minutes Thread-Index: Ac10LhTmju1M62YdRMialEQ0Fp3CYAAAlfoQ Message-ID: References: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> In-Reply-To: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> 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_C3759687E4991243A1A0BD44EAC823034DF5B109C1BE235maillan_" MIME-Version: 1.0 Subject: Re: [AVTCORE] IETF 84 AVTcore minutes 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, 06 Aug 2012 23:38:33 -0000 --_000_C3759687E4991243A1A0BD44EAC823034DF5B109C1BE235maillan_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On the Multiple Media Streams presentation: "Jonathan would like to leave implementers in the dark" - missing "not"! On this presentation there was also a comment from Harald expressing the op= inion that reporting by endpoint rather than by source reflects physical re= ality, so it'd be good to have that expressed in RTCP. (Harald, correct me= if I've mis-represented what you said.) On the RTP Clock Source Signaling: My comment that "this sounds like it should be in RTCP" was specifically wi= th respect to clock source confidence (or uncertainty) reporting, not the w= hole proposal. From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, August 07, 2012 8:51 AM To: avt@ietf.org Subject: [AVTCORE] IETF 84 AVTcore minutes Hi, We have uploaded the AVTcore minutes. http://www.ietf.org/proceedings/84/m= inutes/minutes-84-avtcore Please review and send any comments to the mailing list Thanks Roni and Magnus AVTcore chairs --_000_C3759687E4991243A1A0BD44EAC823034DF5B109C1BE235maillan_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

On the Multiple Media Streams presentation:=

 

“Jonathan = would like to leave implementers in the dark” – missing “= not”!

 

On this presentation there was also a comment from Harald expr= essing the opinion that reporting by endpoint rather than by source reflect= s physical reality, so it’d be good to have that expressed in RTCP.&n= bsp; (Harald, correct me if I’ve mis-represented what you said.)=

&n= bsp;

 

On the RTP Clock Source Signaling:

 

My comment that “this sounds lik= e it should be in RTCP” was specifically with respect to clock source= confidence (or uncertainty) reporting, not the whole proposal.<= /span>

 

 = ;

From: Roni Even [mailto:= ron.even.tlv@gmail.com]
Sent: Tuesday, August 07, 2012 8:51 AMTo: avt@ietf.org
Subject: [AVTCORE] IETF 84 AVTcore minu= tes

 =

Hi,

We have upl= oaded the AVTcore minutes.  http://www.ietf.org/proceedings/84/minutes/= minutes-84-avtcore

Please review an= d send any comments to the mailing list

=  

Thanks

Roni and Magnus AVTcore chairs

= --_000_C3759687E4991243A1A0BD44EAC823034DF5B109C1BE235maillan_-- From ron.even.tlv@gmail.com Mon Aug 6 22:29:26 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 CBA5821F8585 for ; Mon, 6 Aug 2012 22:29:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14y980dWIEyw for ; Mon, 6 Aug 2012 22:29:25 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFC4321F855D for ; Mon, 6 Aug 2012 22:29:24 -0700 (PDT) Received: by obbwc20 with SMTP id wc20so7893042obb.31 for ; Mon, 06 Aug 2012 22:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=xDot+6nXlmnEPLrrHmgQYD8olNfvMCaQQoPRiJE48Eg=; b=YLL3Q1VTBe0vB5hS5QQpCG8I63w2FXzlhUgRVZQxpiEUHMlKsq8lRk5kq/CEjLeQln 53Zwzgp2wWauC5eruy7eOLpHK/4KhXmVCHOMPiGhEbWrGZwBobxcbHxyuVSWagykodHt 53aKS/n6ZIfOdzjhUiTDJNTPFVirMN3ke0um+ARbjG0Aqo8vWt23gMRmupbfIG4kDofy kY5+cADxDBeJCIeuFN7bjRpBYuwkETkdHNe4hkTFzSy6AfRh+q8ddfQdBW+WdHh3mdN4 782WM0r/rQwCDs5ctEBQyQNcgReZP3m9ZNA9YMx7PuKAeu8BJpcBn/YUk9gr6+MBZ1lE SdIg== Received: by 10.182.98.108 with SMTP id eh12mr22860074obb.6.1344317364439; Mon, 06 Aug 2012 22:29:24 -0700 (PDT) Received: from RoniE ([75.111.46.80]) by mx.google.com with ESMTPS id 6sm14653538oef.6.2012.08.06.22.29.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Aug 2012 22:29:23 -0700 (PDT) From: "Roni Even" To: "'Jonathan Lennox'" , References: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> In-Reply-To: Date: Tue, 7 Aug 2012 08:28:15 +0200 Message-ID: <00a801cd7465$d520ade0$7f6209a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A9_01CD7476.98AB52A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJH+eVKHrZ9sm+HmwRib7zRr4iCvAJ3XKLDlkUcXIA= Content-Language: en-us Subject: Re: [AVTCORE] IETF 84 AVTcore minutes 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, 07 Aug 2012 05:29:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A9_01CD7476.98AB52A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jonathan, Thanks, I also agree that Harald expressed that point and can add it to the notes, and saw it in the meeting notes Roni From: Jonathan Lennox [mailto:jonathan@vidyo.com] Sent: 07 August, 2012 1:38 AM To: Roni Even; avt@ietf.org Subject: RE: [AVTCORE] IETF 84 AVTcore minutes On the Multiple Media Streams presentation: "Jonathan would like to leave implementers in the dark" - missing "not"! On this presentation there was also a comment from Harald expressing the opinion that reporting by endpoint rather than by source reflects physical reality, so it'd be good to have that expressed in RTCP. (Harald, correct me if I've mis-represented what you said.) On the RTP Clock Source Signaling: My comment that "this sounds like it should be in RTCP" was specifically with respect to clock source confidence (or uncertainty) reporting, not the whole proposal. From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: Tuesday, August 07, 2012 8:51 AM To: avt@ietf.org Subject: [AVTCORE] IETF 84 AVTcore minutes Hi, We have uploaded the AVTcore minutes. http://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore Please review and send any comments to the mailing list Thanks Roni and Magnus AVTcore chairs ------=_NextPart_000_00A9_01CD7476.98AB52A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jonathan,

Thanks, I also agree = that Harald expressed that point and can add it to the notes, and saw it = in the meeting notes

Roni

 

From:= = Jonathan Lennox [mailto:jonathan@vidyo.com]
Sent: 07 August, = 2012 1:38 AM
To: Roni Even; avt@ietf.org
Subject: = RE: [AVTCORE] IETF 84 AVTcore = minutes

 

On the Multiple Media Streams = presentation:

 

“Jonathan would = like to leave implementers in the dark” – missing = “not”!

 

On this presentation = there was also a comment from Harald expressing the opinion that = reporting by endpoint rather than by source reflects physical reality, = so it’d be good to have that expressed in RTCP.  (Harald, = correct me if I’ve mis-represented what you = said.)

 

 

On the RTP Clock Source = Signaling:

 

My comment that = “this sounds like it should be in RTCP” was specifically = with respect to clock source confidence (or uncertainty) reporting, not = the whole proposal.

 

 

From:= = Roni Even [mailto:ron.even.tlv@gmai= l.com]
Sent: Tuesday, August 07, 2012 8:51 = AM
To: avt@ietf.org
Subject: = [AVTCORE] IETF 84 AVTcore minutes

 

Hi,

We have = uploaded the AVTcore minutes.  ht= tp://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore =

Please review and send any comments = to the mailing list

 

Thanks

Roni and = Magnus AVTcore chairs

------=_NextPart_000_00A9_01CD7476.98AB52A0-- From csp@csperkins.org Tue Aug 7 02:27:03 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 845CB21F8613 for ; Tue, 7 Aug 2012 02:27:03 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UAG10IIbrZBh for ; Tue, 7 Aug 2012 02:26:59 -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 B78A221F859C for ; Tue, 7 Aug 2012 02:26:59 -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 1Syg42-0004O6-lL; Tue, 07 Aug 2012 09:26:58 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> Date: Tue, 7 Aug 2012 10:26:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B1445E9-423A-4E66-A400-154D6F08E6A7@csperkins.org> References: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> To: Roni Even X-Mailer: Apple Mail (2.1278) Cc: avt@ietf.org Subject: Re: [AVTCORE] IETF 84 AVTcore minutes 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, 07 Aug 2012 09:27:03 -0000 On 7 Aug 2012, at 00:50, Roni Even wrote: > We have uploaded the AVTcore minutes. = http://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore > Please review and send any comments to the mailing list For the circuit-breakers draft, my understanding was that the comment = from Jonathan was that the mechanism should work if RTP/AVPF is used, = but that we don't need to define a more sophisticated circuit breaker = for the RTP/AVPF profile. --=20 Colin Perkins http://csperkins.org/ From jonathan@vidyo.com Tue Aug 7 02:53:48 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 E8C1A21F85D2 for ; Tue, 7 Aug 2012 02:53:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaEhFTa702dO for ; Tue, 7 Aug 2012 02:53:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.244]) by ietfa.amsl.com (Postfix) with ESMTP id 44A8121F85D0 for ; Tue, 7 Aug 2012 02:53:48 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 1C4BC4169B1; Tue, 7 Aug 2012 05:53:41 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB016.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id CB82B4169AD; Tue, 7 Aug 2012 05:53:40 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB016.mail.lan ([10.110.17.16]) with mapi; Tue, 7 Aug 2012 05:53:32 -0400 From: Jonathan Lennox To: Colin Perkins , Roni Even Date: Tue, 7 Aug 2012 05:53:35 -0400 Thread-Topic: [AVTCORE] IETF 84 AVTcore minutes Thread-Index: Ac10gioGe/NVM32LRlurz6odlrdMUQAAE0gQ Message-ID: References: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> <9B1445E9-423A-4E66-A400-154D6F08E6A7@csperkins.org> In-Reply-To: <9B1445E9-423A-4E66-A400-154D6F08E6A7@csperkins.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] IETF 84 AVTcore minutes 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, 07 Aug 2012 09:53:49 -0000 On Tuesday, August 7 2012, "Colin Perkins" wrote: > For the circuit-breakers draft, my understanding was that the comment fro= m Jonathan was that the mechanism should work if RTP/AVPF is used, but that= we don't need to define a more sophisticated circuit breaker for the RTP/A= VPF profile. Yes, that's correct. --=20 Jonathan Lennox jonathan@vidyo.com=20 From tterribe@xiph.org Tue Aug 7 14:32: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 C7CB821F85F3 for ; Tue, 7 Aug 2012 14:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.557 X-Spam-Level: X-Spam-Status: No, score=-1.557 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKzrEj7uzrcW for ; Tue, 7 Aug 2012 14:32:29 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id DA32721F85EF for ; Tue, 7 Aug 2012 14:32:29 -0700 (PDT) Received: from [10.250.6.54] (corp-240.mv.mozilla.com [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id A0765F2625 for ; Tue, 7 Aug 2012 14:32:29 -0700 (PDT) Message-ID: <5021896D.9000108@xiph.org> Date: Tue, 07 Aug 2012 14:32:29 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120626 SeaMonkey/2.10.1 MIME-Version: 1.0 To: avt@ietf.org References: <20120807211707.12041.88980.idtracker@ietfa.amsl.com> In-Reply-To: <20120807211707.12041.88980.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120807211707.12041.88980.idtracker@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------020409070501030202080109" Subject: [AVTCORE] Fwd: New Version Notification for draft-terriberry-avp-codecs-00.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, 07 Aug 2012 21:32:31 -0000 This is a multi-part message in MIME format. --------------020409070501030202080109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Colin Perkins pointed out that if we do not want to make implementing the DVI4 codec a SHOULD in rtcweb, then we need to update the AVP profile which rtcweb relies on. I also added, at Colin's suggestion, a sentence noting that G.711 may be mandatory in some environments. --------------020409070501030202080109 Content-Type: message/rfc822; name="New Version Notification for draft-terriberry-avp-codecs-00_txt.eml" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="New Version Notification for draft-terriberry-avp-codecs-00_"; filename*1="txt.eml" Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on kizuka.merseine.nu X-Spam-Level: X-Spam-Status: No, score=-1.9 required=4.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-Original-To: derf@kizuka.merseine.nu Delivered-To: derf@kizuka.merseine.nu Received: from mail.xiph.org (westfish.xiph.osuosl.org [140.211.166.32]) by kizuka.merseine.nu (Postfix) with ESMTP id 87E7875C02F for ; Tue, 7 Aug 2012 17:17:09 -0400 (EDT) Received: by mail.xiph.org (Postfix) id EE3B61CDA4; Tue, 7 Aug 2012 14:17:08 -0700 (PDT) Delivered-To: tterribe@xiph.org Received: from silver.osuosl.org (silver.osuosl.org [140.211.166.136]) by mail.xiph.org (Postfix) with ESMTP id E6C6D1CDA3 for ; Tue, 7 Aug 2012 14:17:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id DE94C24D4A for ; Tue, 7 Aug 2012 21:17:08 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mOs4z5sb4bh for ; Tue, 7 Aug 2012 21:17:08 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by silver.osuosl.org (Postfix) with ESMTP id F318025071 for ; Tue, 7 Aug 2012 21:17:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C2B11E80E3 for ; Tue, 7 Aug 2012 14:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWRrIWj++ywy for ; Tue, 7 Aug 2012 14:17:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145C211E80DC for ; Tue, 7 Aug 2012 14:17:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: tterribe@xiph.org Subject: New Version Notification for draft-terriberry-avp-codecs-00.txt X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120807211707.12041.88980.idtracker@ietfa.amsl.com> Date: Tue, 07 Aug 2012 14:17:07 -0700 A new version of I-D, draft-terriberry-avp-codecs-00.txt has been successfully submitted by Timothy B. Terriberry and posted to the IETF repository. Filename: draft-terriberry-avp-codecs Revision: 00 Title: Update to Recommended Codecs for the AVP RTP Profile Creation date: 2012-08-07 WG ID: Individual Submission Number of pages: 10 URL: http://www.ietf.org/internet-drafts/draft-terriberry-avp-c= odecs-00.txt Status: http://datatracker.ietf.org/doc/draft-terriberry-avp-codecs Htmlized: http://tools.ietf.org/html/draft-terriberry-avp-codecs-00 Abstract: [RFC3551] defines the AVP RTP profile, which is the basis for many other profiles, such as SAVP [RFC3711], AVPF [RFC4585], and SAVPF [RFC5124]. This document updates [RFC3551] (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. = = The IETF Secretariat --------------020409070501030202080109-- From stewe@stewe.org Tue Aug 7 21:01: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 ED37921F85D0 for ; Tue, 7 Aug 2012 21:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.636 X-Spam-Level: X-Spam-Status: No, score=-3.636 tagged_above=-999 required=5 tests=[AWL=-0.037, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwnqMnNO-ZIb for ; Tue, 7 Aug 2012 21:01:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id DF7DF21F85C9 for ; Tue, 7 Aug 2012 21:01:24 -0700 (PDT) Received: from mail28-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE002.bigfish.com (10.43.70.52) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 04:01:24 +0000 Received: from mail28-ch1 (localhost [127.0.0.1]) by mail28-ch1-R.bigfish.com (Postfix) with ESMTP id 2445B801DF; Wed, 8 Aug 2012 04:01:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.236.133; KIP:(null); UIP:(null); IPV:NLI; H:BY2PRD0710HT001.namprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: PS1(zf7Iz98dIzz1202h1082kzz8275dhz2fh2a8h668h839h944he5bhf0ah107ah) Received-SPF: pass (mail28-ch1: domain of stewe.org designates 157.56.236.133 as permitted sender) client-ip=157.56.236.133; envelope-from=stewe@stewe.org; helo=BY2PRD0710HT001.namprd07.prod.outlook.com ; .outlook.com ; Received: from mail28-ch1 (localhost.localdomain [127.0.0.1]) by mail28-ch1 (MessageSwitch) id 1344398482789999_24469; Wed, 8 Aug 2012 04:01:22 +0000 (UTC) Received: from CH1EHSMHS007.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.230]) by mail28-ch1.bigfish.com (Postfix) with ESMTP id BD89120007E; Wed, 8 Aug 2012 04:01:22 +0000 (UTC) Received: from BY2PRD0710HT001.namprd07.prod.outlook.com (157.56.236.133) by CH1EHSMHS007.bigfish.com (10.43.70.7) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 04:01:22 +0000 Received: from BY2PRD0710MB354.namprd07.prod.outlook.com ([169.254.11.15]) by BY2PRD0710HT001.namprd07.prod.outlook.com ([10.255.86.36]) with mapi id 14.16.0175.005; Wed, 8 Aug 2012 04:01:16 +0000 From: Stephan Wenger To: "Timothy B. Terriberry" , "avt@ietf.org" Thread-Topic: [AVTCORE] Fwd: New Version Notification for draft-terriberry-avp-codecs-00.txt Thread-Index: AQHNdRp00eX7UUsVmkyDc1LIcqjivw== Date: Wed, 8 Aug 2012 04:01:15 +0000 Message-ID: In-Reply-To: <5021896D.9000108@xiph.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.255.102.5] Content-Type: text/plain; charset="us-ascii" Content-ID: <049454B9A542E241B298C60ACDC6665F@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-terriberry-avp-codecs-00.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: Wed, 08 Aug 2012 04:01:26 -0000 Hi, As I said in the meeting, I disagree with Colin that an update of 3551 is needed. Rtcweb is producing essentially a suite of profiling/systems specs, and many other IETF technologies are profiled therein. I don't see why AVPF needs to be an exception. That said, if the group chooses to follow Colin's arguments, should the resulting (new) profile not have a different name, registration, etc.? Also, while we are at it, shouldn't we do away with other known and commonly agreed shortcomings of AVPF? All pre-reserved payload types come to mind... Finally, what about SAVPF? In the past, we tried to align the two. Shouldn't this draft not at least mention that it is intended to update SAVPF as well? I'm not trying to be difficult here, and I don't want to open a can of worms larger than necessary. However, single-use, rtcweb local fixes ought to be dealt with in rtcweb, and not here. If these fixes ought to have general applicability, then, I think, we need to consider thins a bit more broadly. Stephan On 8.7.2012 14:32 , "Timothy B. Terriberry" wrote: >Colin Perkins pointed out that if we do not want to make implementing >the DVI4 codec a SHOULD in rtcweb, then we need to update the AVP >profile which rtcweb relies on. I also added, at Colin's suggestion, a >sentence noting that G.711 may be mandatory in some environments. From tterribe@xiph.org Tue Aug 7 21:28:14 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 2163111E80E2 for ; Tue, 7 Aug 2012 21:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xd1hfIUqb-nW for ; Tue, 7 Aug 2012 21:28:12 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id B4CA221F854F for ; Tue, 7 Aug 2012 21:28:11 -0700 (PDT) Received: from [172.17.0.31] (c-69-181-137-38.hsd1.ca.comcast.net [69.181.137.38]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 0850DF2031 for ; Tue, 7 Aug 2012 21:28:10 -0700 (PDT) Message-ID: <5021EADA.7030901@xiph.org> Date: Tue, 07 Aug 2012 21:28:10 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: "avt@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-terriberry-avp-codecs-00.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: Wed, 08 Aug 2012 04:28:14 -0000 Stephan Wenger wrote: > Finally, what about SAVPF? In the past, we tried to align the two. > Shouldn't this draft not at least mention that it is intended to update > SAVPF as well? The draft mentions that SAVPF is derived from AVP (indeed, that is the point, since rtcweb is not really interested in AVP by itself). I can try to make the language indicate more explicitly that this update covers all profiles which include AVP by reference. As for the rest of your points, I will defer to the consensus of the working group. From csp@csperkins.org Wed Aug 8 00:37:39 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 7173521F8648 for ; Wed, 8 Aug 2012 00:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-enZeNbuHgh for ; Wed, 8 Aug 2012 00:37:38 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by ietfa.amsl.com (Postfix) with ESMTP id A530F21F8645 for ; Wed, 8 Aug 2012 00:37:38 -0700 (PDT) Received: from starkperkins.demon.co.uk ([80.176.158.71] helo=[192.168.0.11]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Sz0pl-0003Gr-hX; Wed, 08 Aug 2012 07:37:37 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Colin Perkins In-Reply-To: Date: Wed, 8 Aug 2012 08:37:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1C25B3E0-F704-47AA-B6A6-4CCC163D28BC@csperkins.org> References: To: Stephan Wenger X-Mailer: Apple Mail (2.1278) Cc: "avt@ietf.org" Subject: Re: [AVTCORE] New Version Notification for draft-terriberry-avp-codecs-00.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: Wed, 08 Aug 2012 07:37:39 -0000 On 8 Aug 2012, at 05:01, Stephan Wenger wrote: > Hi, > As I said in the meeting, I disagree with Colin that an update of 3551 = is needed. Rtcweb is producing essentially a suite of profiling/systems = specs, and many other IETF technologies are profiled therein. I don't = see why AVPF needs to be an exception. RTCWeb needs something to update RFC 3551 to remove the "SHOULD use = DVI4" recommendation. That could be the rtp-usage draft, making the = change specific to RTCWeb, or it could be a separate draft. As I = understand it, virtually no-one follows the DVI4 recommendation in 3551, = so we should reflect reality, and write a general draft updating 3551. Colin > That said, if the group chooses to follow Colin's arguments, should = the > resulting (new) profile not have a different name, registration, etc.? > Also, while we are at it, shouldn't we do away with other known and > commonly agreed shortcomings of AVPF? All pre-reserved payload types = come > to mind... > Finally, what about SAVPF? In the past, we tried to align the two. > Shouldn't this draft not at least mention that it is intended to = update > SAVPF as well? > I'm not trying to be difficult here, and I don't want to open a can of > worms larger than necessary. However, single-use, rtcweb local fixes > ought to be dealt with in rtcweb, and not here. If these fixes ought = to > have general applicability, then, I think, we need to consider thins a = bit > more broadly. > Stephan >=20 >=20 > On 8.7.2012 14:32 , "Timothy B. Terriberry" wrote: >=20 >> Colin Perkins pointed out that if we do not want to make implementing >> the DVI4 codec a SHOULD in rtcweb, then we need to update the AVP >> profile which rtcweb relies on. I also added, at Colin's suggestion, = a >> sentence noting that G.711 may be mandatory in some environments. >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --=20 Colin Perkins http://csperkins.org/ From james.peters@skype.net Wed Aug 8 01:45:57 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 64E6521F8645 for ; Wed, 8 Aug 2012 01:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.501, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Hlmig0I-mjR for ; Wed, 8 Aug 2012 01:45:55 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1ED21F862A for ; Wed, 8 Aug 2012 01:45:55 -0700 (PDT) Received: from mail173-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE016.bigfish.com (10.243.66.79) with Microsoft SMTP Server id 14.1.225.23; Wed, 8 Aug 2012 08:45:54 +0000 Received: from mail173-co1 (localhost [127.0.0.1]) by mail173-co1-R.bigfish.com (Postfix) with ESMTP id 68F07C0016E for ; Wed, 8 Aug 2012 08:45:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:131.107.125.8; KIP:(null); UIP:(null); IPV:NLI; H:TK5EX14MLTC103.redmond.corp.microsoft.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VS-1(zzc85fh62a3I13e6Kc0c9kzz1202hzz8275ch8275bh8275dhz2fh2a8h668h839hd25hf0ah107ah) Received-SPF: pass (mail173-co1: domain of skype.net designates 131.107.125.8 as permitted sender) client-ip=131.107.125.8; envelope-from=james.peters@skype.net; helo=TK5EX14MLTC103.redmond.corp.microsoft.com ; icrosoft.com ; Received: from mail173-co1 (localhost.localdomain [127.0.0.1]) by mail173-co1 (MessageSwitch) id 1344415552633209_32062; Wed, 8 Aug 2012 08:45:52 +0000 (UTC) Received: from CO1EHSMHS013.bigfish.com (unknown [10.243.78.236]) by mail173-co1.bigfish.com (Postfix) with ESMTP id 950A73C004C for ; Wed, 8 Aug 2012 08:45:52 +0000 (UTC) Received: from TK5EX14MLTC103.redmond.corp.microsoft.com (131.107.125.8) by CO1EHSMHS013.bigfish.com (10.243.66.23) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 8 Aug 2012 08:45:51 +0000 Received: from DB3EX14HUBC303.europe.corp.microsoft.com (10.166.18.183) by TK5EX14MLTC103.redmond.corp.microsoft.com (157.54.79.174) with Microsoft SMTP Server (TLS) id 14.2.298.5; Wed, 8 Aug 2012 08:45:48 +0000 Received: from DB3EX14MBXC301.europe.corp.microsoft.com ([169.254.1.68]) by DB3EX14HUBC303.europe.corp.microsoft.com ([10.166.18.183]) with mapi id 14.02.0309.003; Wed, 8 Aug 2012 08:45:42 +0000 From: "James Peters (Brook Street)" To: "avt@ietf.org" Thread-Topic: Skype - WebRTC Thread-Index: Ac11Qi+e5EGoapE4QFWo+cBOL62cFA== Date: Wed, 8 Aug 2012 08:45:41 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.166.18.96] Content-Type: multipart/related; boundary="_005_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: skype.net Subject: [AVTCORE] Skype - WebRTC 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, 08 Aug 2012 08:45:57 -0000 --_005_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_ Content-Type: multipart/alternative; boundary="_000_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_" --_000_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello & Good Morning, I hope all is well. As you are maybe aware by a blog written by Matthew Kaufman on our website = yesterday, we are getting involved in a WebRTC project. http://blogs.skype.= com/en/2012/08/customizable_ubiquitous_real_t.html In London, where we are currently embarking on building a development cente= r, we are recruiting heavily for Senior Software Engineers with a backgroun= d in RTP, IETF Standards with C++. If you'd be keen to hear more and discus= s these opportunities with me, I'd love to speak with you. Best Regards, James Peters Talent Attraction Specialist Skype: jamescpeters7 email: james.peters@skype.net tel: +44 208 133 4262 [Description: Description: Description: Description: Your Home Page] [Description: Description: Description: btn_liprofile_blue_80x15] We're Hiring : http://bit.ly/JeiHnv Follow Skype Jobs at: http://twitter.com/skypejobs Follow us on Facebook: http://on.fb.me/SkypeCareers This electronic message contains information from Skype, which may be privi= leged or confidential. The information is intended for use only by the indi= vidual(s) or entity named above. If you are not the intended recipient, be = aware that any disclosure, copying, distribution or use of the contents of = this information is strictly prohibited. If you have received this electron= ic message in error, please delete it and notify me, using the contact deta= ils above, immediately. --_000_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello & Good Morning,

 

I hope all is well.

As you are maybe aware by a blog written by Matthew = Kaufman on our website yesterday, we are getting involved in a WebRTC proje= ct. http://blogs.skype.com/en/2012/08/customi= zable_ubiquitous_real_t.html

 

In London, where we are currently embarking on build= ing a development center, we are recruiting heavily for Senior Software Eng= ineers with a background in RTP, IETF Standards with C++. If you= 217;d be keen to hear more and discuss these opportunities with me, I’d love to speak with you.

 

Best Regards,

 

James Peters

Talent Attraction Specialist

Skype: jamescpeters7

email:    ja= mes.peters@skype.net

tel:         &#= 43;44 208 133 4262

3D"Descript=

<= span style=3D"color:windowtext;text-decoration:none">3D"Description:


We're Hiring : http://bit.ly/J= eiHnv

Follow Skype Jobs at: = http://twitter.com/skypejobs<= /o:p>

Follow us on Facebook:= http://on.fb.me/SkypeCareers<= /o:p>

 

This electronic message contains inform= ation from Skype, which may be privileged or confidential. The information = is intended for use only by the individual(s) or entity named above. If you are not the intended recipient, be aware tha= t any disclosure, copying, distribution or use of the contents of this info= rmation is strictly prohibited. If you have received this electronic messag= e in error, please delete it and notify me, using the contact details above, immediately.=

 

--_000_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_-- --_005_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_ Content-Type: image/png; name="image001.png" Content-Description: image001.png Content-Disposition: inline; filename="image001.png"; size=3070; creation-date="Wed, 08 Aug 2012 08:45:41 GMT"; modification-date="Wed, 08 Aug 2012 08:45:41 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAGkAAAAvCAMAAADXXRR5AAADAFBMVEX///8Ar/BizvYwvvOz5/o9 wvTK7vy+6vpUyfVGmrlq0PYBr/Bo0PbT8fyD1PIbnMtt0fZSyfV41fdRo8JJxvRjzvYuvfNv0vf1 +fpNo8NFxfQ4sd4gufJlz/YCsPBcobsZt/Emu/IJsvEduPLx+v1Mx/Rem7JJwe1Bsdxx0vcYs+w1 wPPr8vVczPVcxu6P3Pif4flhzfYomsQRtPEovPLm9/1Snrp3z+8StfFLrNAOpdx/1fU0uuzf9f1U oL2k4/ri9v1ErdRyrcM6vOwSrOWW3vnv+v6H2fiXydsuuu57ssdNuuIRo9oCru2R3Phmq8U4wfPD 6/rW5uwkrN5bzPVSu+JcvOHh7PGV2vSY2/MqoMsEsPBZy/U6tuRCnr+62eWJ2vgVtfGv5vokseWu zdn6/f5Lqct21PcMs/HD2uJWxu6lx9T8/v6q5Pq4090rrNt/1/eawc+Lu8xSxvELr+tZyfIqsePP 8Pyh3POu4PNezfVDxPSK2PT2/P5fxOkHquYkpNRKvukBq+pezPV81vd0utR61ff+//9Ao8jN4OeM 2/gFrewyr94nue9yqLwEr+4yteXX8vxdyfG26PpOxfAJodpty+4dpNY7rdh00/f+/v72+vuj4PZZ udzp9/xkttVWyPKC2PdqweF+1/g/w/RGw/Gq0+J80O8GpN/+/v8PtPFTwOiC2Pglt+xizfYDp+Rp zfNLxPCK1fHh8/pPx/Ucqd3Z8/1/0vADrOtSxO45v/A2qdPo+P5+0/SGtcZanLRnobcnu/JTrtB2 0fM+wvOQu8pkwOLn9foTndENn9VEtuFIt+AtpdLd8fkVqN4Freo7mbxdzPZ8rsFwvttsqL5jo7lV xO1Nt92OyuHn9/46wfSly9nB5/XI6/h/uc9HosRXnrhGqMtNqMlmx+vh9PxDwfBIxfRwzvJfzfY9 nMBjzfWr0N1Wm7REu+dAvu7e9PwXoNMJpuEMqOJmzfODvtVCr9hnz/Zcy/VVwuoptema3/hPsNQx p9M4qNGn4/r///8LLO20AAABAHRSTlP///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8AU/cHJQAA B61JREFUeNq1lwtYU9cdwO8JEWKCg4RHgiYBIUQCwUsKcVALjVRCWVeKTKRq3AChgAgLVkxHRCcy qPhYNWDFOgs2Fqm0rl2GilaLpV1rW1f7YGu3ri/L2LN7uq1buTvnf26uVx7t10p/fB/3fx73/M7j /u+Xy3DT8JPxCIvTY+BmjGlMB59amMtK81sbpF+x6eDXdWW147eO1453H/pqTfc5bk3h+ehjbgoO e9olFotpfG/bjZkeuq09h+eTy91TnGHvAp+8pb9fbZE1SCtuxBQ0zLLs69HG6NdZtme3neMqDC7X 2Sb/1q7c5ijJyWcx+TlO2d8P34Cp11dSUrLBzJg3nMzNjQkKfHqhz+2O717saiML/jC8tSRXoP3q k0FfxNRkMPSRyzJWYpGc3Bbe339EwzCM5ojTOT9SGdraXlLSrroq+/EVrmKL0tnvFNGjOjpJZTA0 TWk6GPjbdUrZvk8CN5/2ORxyU2P8dpXqCEM4olJ5k50trSpMa0t/173f6/U9gktiWtVHreJD9Dj3 jSjX7WOX0WTsAy2YHto/VyYJDg4dc1+ubK3sMnVhTKbnwfS86Tq6VLPCK02TcHRbayMsEvYKx+3t HWmUVzofcapCJQ1PX+H6fr1QpuxefJiYmrbEq9Whcnmo2oQvAivAtEI+geCr8smEzvI65DqdrOPQ UyO6SjXuFRwsDzVVSu69+2ujyfgq6/gYm/bPlesiJsObIgQk0xNh0V3Fa9LJh2Vq3RMWP0/o1Eov bsBBREcF88otY9svY5KTk49nZJ03GrPCMo7jQhGYipKBD4xZ64reOx+1bjnPPVlRRUVhWffgil9E vYdvyhhxOBzJY43LHY6RjDBccz4r47hjeWOjFdPSYg0fZ/LfdsiA01F7agrxA1e8o2ZP1DbZHWC6 A5oW1TGF0dlmTfUHMsr75YXV2dk7CsvDZEvOVZvxTTVvLvG3vVmzA9doCvEwHUql0qq0BgZaleGM +20fcDG6mhHY8cbFlyB4KR7zbjGOislTX7cgHvgVyQAz6fjPeoaiqX+ftCxYVE46Uqqj/xQebgu3 9fTY4tOYoYK5wF1mRoQm+yJcL+KWd0VTWAJ9E64N9htGoPyA2+3OKmZEFL/xZ7cN/7lt3gBGG+Al HIAeb6Wo1flvkcicAF0Thofvp6IU+P/wMOECI0DmN8DHG26bdT8MY0ixyFRQqwmbRUnLZSRxBYT/ Qt9BiKU4ss6DinkFZ+og6ClwkcujBQVJSUm3w3AMMBCMK3qgoDnzAHS2Hk3CDAaRuHBXEiFSW8F4 0gMIP2IIeQFAS2DQ4C6o2PU/eg4tAQFbYAmbcHMeTPwQA768SEIDFH7wKVxORwJ5oL9AQm1cIMes v0WbhqGm6JfXpvF8FyoyqEiFKx6H6MzQ0BA0GdZAeeUQhS7gHwwmcD7PZlKqw0FVko28I17ZGKPV ajfRXa/f88ffrVqrxXwLKujW1WoJHpg2Di7AkmiHB7QUmhSw2ONanrWwpdq4uFIXfe9trorBkHGg BafTolWJMTAQzy9jCDBYIQ4eJcEa2iGGIu5eb+R5zd8jTkpNtanpmERQUczlWZd+KjIVrkon2En8 YPpS8rzZ0mmHVB4oTYUdN8Z4qEmaXgWMSkWu7O8zIsq/GYtZCRkVCy0nYy9BSywFSlORuQ83lkp5 U+pqP+58l38T+ZR00Tz6xim9Xg9nebv+YXJZqr8ZGjr1lAcZAbdeMYFU3mRNR5jmzhOI8JiPjm2m op2nMkH8bYSxk/oT3yFTRYiaPkUUyEfKy2gi6WepqS8RF05En9vzAqKAivIfhPLoUYXghrtJtIq8 ivb7TX84hgjHqmFeZbBqwXCTcTY0a9uoievQI0Turw9BwApG4GZcZOlRdSK0VHjwt/pNmuwX8X6E ZEPhQ8gx800IaJ5dx5jvwoFexvEmTyxCCTDaq53kNhgrUzAhFz2qZoRIZR+ZPAITqJ4zGp+p0cBj tpV2rX71xWZ07AV42Zpxz1iP37T+cQXaSvfoHLkNwoXXTIl0SLziXobybzBN5FmENtphmOeeMb5W DyedgpAiso2aMPf9HKEx5jrGLvEmghriA7B9wCkw0aUDdFDMblAJuHDP1bWi33sf4ZMKCBJlgZc+ aHZEgaZLOKADlyHBtJ9leFgEbEwRZa2TnJKvTWQ6nKhA2OUMshNNyhjMriyzbDei7EzJdPlIQPd0 zTVTAvKWYb2L1SI/WjWpYYJYuEMRaeB4E/AzUH0+9DibxabPRpFm4wTTF1H9hR7I55sEkX3SF4Dh yTvRdaT+vnSCPCQkZAOD2TSdqdQ7uvr6Mf7VNNW3hnS3yPXY6AD3zk4kZnZNebkG3kTTmEpzcG4O 3ikawzXdV82y0DQyp6qq+aazpPyOeEs7ixlKHgL+CoV5EMNNJjp/GzuqJ4/caP7Zz/x+Wj9nzt4B oWQVbekJO59piAfKfyN71MWyOQNf8ttdYFnDDxHPYBnOkDKvoD6aSRNGEXkDX9RiKuaw7YN6JEah VYiPfXyGTHBgG5GY0oHFsFJAr+RmyAQ0iBelV3Hcs6f8hfi2GTWtz4P9EsaGnIB9ZPu4mTOBSsiT 1O382HNYlvVAPJMmYRGQjWJm2gQYcK41cV+W/wOia0t+Dz1Z3AAAAABJRU5ErkJggg== --_005_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=3366; creation-date="Wed, 08 Aug 2012 08:45:41 GMT"; modification-date="Wed, 08 Aug 2012 08:45:41 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAAGQAAAATCAYAAABmxagtAAAAAXNSR0ICQMB9xQAAAAlwSFlzAAAS dAAAEnQB3mYfeAAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAAymSURBVFjD zVlpWJZlFubXTDVZZilKak1N63SluU5ao6PjaCmuZZZLbmXu+xKWigKSu6Yp4oKpuSKgCLIjiywq IgqCICIoyOaOu95z38/H+4VeOaN/yve6zvW8z3mf5Zz7Puc8z3d9Dq6urg5Dl+3x6zxjB+p1d4eT 8yy82MXt8ZfObnCi1HlE0ZzHxQdhLcw7z/CDOBAXDsOWBfu2m+BT2GH6VvRdHobBPjFGBq19vGXg 2r3otyoavb2jHkn6r9lr5g/+g+23cO67PBztp21F2/FrC4eSCwdnVz+0mboZfb0j4RqbC8/kAiOz H1dJKoBHUj5tzMe27DIkFlcg4SEksaQC0YWXsDS1EO6J+fDg/D/SDwtnYd7HKwJtXDah80w/ONTr PhvdFgdjUlgmJkccN+3E0EyMCs7A8N3ppp1I3aSwLCNj9hwz+hFBGZgQatPr+/0i/bgQ21iJ3h80 9kEyqbKtasv4ENmXhdWHCpB34Soe5bl++w4i88rhtvcE/ch4JFv+v633+is7hZXBL/RXX+6XyRFZ 5lt3cvBSj9lwUC3+ZHkExkVkY4QWCzxq2klcZKoGs1V/GPUS9V2jsjEt8jhGBdn0lhFVRfoxNEZr SPT+oLEPlN+w5eudRzCSutSiSwbkkorryCm/YqSU75eu38TF35AL126SkNuGlBX7T6G/3+FHs+UB MqJSZJfwmEFsXKOzMVbBQ0Imh2XacX3QfGEvDsSFQ90u7uiyNAxDOXkQjeznewiD/dMQfqIMBRev mVb93ttT8MW2FGw4fAZnLl1DevElTGCU9dqSggE7UjGQc9Va79LPic0xa0jmxOXgsy0H7xkz0C/V 3rd0g4zetlaf7YdMPzznV1v6+aaiP78dKbYRklp0AZNCMozo/fadu7h+6/Y9co1y9eZt3Ll718xZ lpSHTzcfvGevqjKo0o779ffbbI0byPeeXM+T/p4mNsJnFknZkHoacafK8XVAmsH1t/aQCHtxIC4c 6nV1R4eFe9A/4Ai+2HoQPX7Zjz4EPr34sjFerfrdqe+5+QAmk4SlCbmYz80HcJNOPyeh64ZkM8+Z 75Kemw7AeX0SFu3LtZeLxXxvtybB6LtwfC860H3jftM3uvXUkbA+W1Psa7Vbm2DGHi68aLdFNmj9 A2cuGF351RuIzz9npKzixgPLVSUXhpT5cSfQiXv25l7aszP3tuzoRpuEg6RbVfvus9kap/kfr0vE PK4ZnlOK5YknsSBO2KQi4kQpTp6rwJcMLPnUrepcztP+WkPYiwNxYQhpMzcIPbemohs31eI9OCG5 4LxxQK36H/kkojNBGrv7KBbGn4B71HH0Zha4sZ0ZmWX0q1gKJH25UZNlMfBklFjPFBLZn4atSynA So7pzr1cQo9hI6NoE7NOa4qEf66Mw8TgdLOOV3Ke+X6a2WHZYpGeXHDO6ERCFDNnb24ZS9Mt5J27 Cv/0IgRmnkXgsbPm3ZpvETKbdrVdvQ+d1pEUArOEwaJ9dnDsnJhstFll+yYff+ZZ5Xu00Ngim+Vv 1XEdiddcBqey4uK1W1h7MN98+5zk7eT+GQyiruvlV7zRW3MVnB25hwgW9uLATsgHs3fBeeMBfMSI bOMdj44EPyHf5rBa9VsRqA+94gjeaaMvpAFfMfXi8spwvOwKYnlYWs/aA/lmnWlhx3DXyhACHkBj Klg6kgjmTJ4JKYxyrXOC9f8CnREAnbjX9iOF9rWu3LiNG6z7li3/JggSy759LAmtvOLNfoeLLhoC 3v8p1hDb/KcYNGNgCID8yguACJkRnokWy2PQckUsBjHLS6/cQAnl6NlLiGRUD9lxGM4Eaz8D4PKN WwT1EhLzbTaLaGvcNyw3wmZL2mlDhmzVPiqRLixDG0hmauEFdGUAac3grGIknDpn2lE8czT3PwwM YS8O7IQ0cwtAW58ktKYT79MJORdfCXDsyTJ8QMMbLolCox+jsJ4RrucMo64voyssu8T0VaOv37IB p9Yz+jjG7ErDzTs2SuT0TQIbw0iWI1mllw04Gw7lY26MLZM0ds3+PIQeLzb9osvX4HPwFI6V2M4L 2dRSQFIs++JOlqP5sr0G4EMsbYrmBoujzJj2a/YZn5osjTZgWo8Lzxv50/jHaAzg2VjEoPiRWdKI /QWMdhE7mNm8j+DtoS0tiMkw/8PIZuCpVFvjMktYzrccQFOuH5xZbEibyEqhMvU9s9+H2RJH/AZx La25klmmoFf255ZXoN+2g8YGYS8O7IQ05C/FFiv3ofnSvWhIZ1owqmIJnJ5oRkLjJdF4bW443pof jtXJp4xem37KFN7NtDTlJP88oyLdRLyehayjQ3Ycske39finF8LZJ8EQqif//FXk0FHr8T1yxpBW euU65pGojnQgkrXZBAf1jWifxLLP0jWlY8q4bZz/V89QdGEpieC8cYFH8PzM3RgZcNi+xwSC9sa8 cLw9PwJf8Ew6RRtk+xPf7cS00AwUMMoH8dyU75tYymq47jZRriyaRqCtcaUsl5/zbKg5MwhbOC4i pwS92NeFZzJvXKtIQBTX6MM95K9EmV1UWd4++yUZbxJTYS8ODCH1u3rgre980WBpDN5dGInX54Th vUVRNKbMngnb0s5gBQ+rtoy2BTE5Rp/LMuNMsFSG9GhMa69YE0V63BiRA3hg3U/IVqb3vzju7OXr pp934RpWscSN3pmG0byNTKEjSTRapcKP0a6DL9oeHGV4k0BKBJYVMOq/syACB06ftwE4Yze6E8By AjaT5elJAliVkFF8r+u+By/NDkEPHugKrrHMZoex2zGJZBXRtj48A8KZ/dZ6GneeV2d9t8apL72+ b2EpjxQhPBPSz17EGPqzIuGkWUMkyV8F7+Sgo5jK83Qoy30zZpaCXNiLA3FhCHl1yla8tiASr/0Q irpuwXiTpMRXOROs50um5+xIW+orOjqsikdIlq28qFW/tPKm40FC+jEyrCf8eImpxXJepG5MyUcx jSxk1HmTEBExdtcRfMoDMCD91zMk5exlXGI5tErWSx57UJ8SUVkqg1nTqxHw56btMt8VlQ6jt+F9 ZowybzivqQ7DN6M3QbGeITw3akwPRE1GfnuW5zzatJvrKHPWcP4ilqNWLHkpJHgHM+6Z73eiKbPQ KzGXFSIP45l1atWXXt/908/wfCjHJyTo1PkKE1yreL3WGq1Y8hfFZmMpz1EFgwsJUQA2ZALIH2Ev DmyEdPNA/YmbUc8zDPXcguA4IxAvuwfjp/hcw3Q6D7BjBDKNd/yOq+MxjGVIegHxDzq9mBupr1Z9 6dUfSqc/5njbGhfRwTsO3/imGFJ0RjRjDZ/Lc0brZ0ioT2LNbu8dyz1Sbfpi2976rjVkk6NrIOqw BO2tzBCB0NYrBu1WxiKNB+hOktmQ2fIV6/Nplp553OPduaGYznPDer5iOXrqW39UmxqAD3n+iBCV Ee0pQmoRA6dZu7GZh7InA/B5ki0RPvqexbNDrfrWtx+isuCddBJtmP3+JLEXA8uF2aA1tJbWXJ18 0vgkUUA1I5nPkUxhLw7EhTlDnMZvQm2PENRmxEjqUN5gtjRYEH6P1Gf2vEJG9f7OPP6QmRVkH6dW fenV1ziNb0Bw1BeI6jdaGIH3qHNkmv+NJeM99psujjQENVkUaca87G7bQ8A2XhRhxlh7VGc2OHGf wIwi+61JV1+Jfmvo4lDCzNMvcz261al/hSXQunD03bQff5rkhyem+KM1M+EUCZnFX9Sve4bg7blh qEGAFZh6l06YCFAB/3fqmtNWtepLr++v/xDCyhJKkoLNNwW1/NMaWqtGlbkiQjgIr1rEobZ7iOHA nCH6deg0aj0cZwWjNg8nLe5IeYaOP8kosuSpbwPwwnTbwuo/7RKAmtzo2cpxatWXXn2N03hr/v+a a9/D5d497hfZ9Pz0Xca+Xhv4W6Ty6vuwj8hawsuGyH3mu13482R/tGE5KeI5qZruMHKrKX9WYFab utPYaPWr4qLWsVIv0TjpatL+p5l5z7Ot/v0us4Y1piqmf6GvhsxZtqrkNHId6ipDWk7YhFeGeKMm SanNclDbbQ8cydjjK3tQizbWYUZ/tukg3KNzHlqmhGbyuhuNFxh8tdxCUN01CG8vjOIP0WNo7b0P z84I+l19UWaIqJrDffDq4BVoOWkzHJzdd/g2HuZV+MrX3qgzwgdOY3+B07jHX2rTzuoj1+Mvw9Y9 tDw9/GfUHL0RdSrXeJFlwnHsRlSj/oXRG0z/d/Ohci9h/upgLzT5ZnmhuHDQv1Rd3H39WvBQUcrU 6+JhDpfHXlhvVW4f7V86d1OndZupuo5d/7vaL6zlgxtakBxxIC7+C2m8JUO6hcuYAAAAAElFTkSu QmCC --_005_ED5816537A1DE44D809B971DCC04888A0727F73FDB3EX14MBXC301e_-- From csp@csperkins.org Wed Aug 8 01:54:21 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 4D46621F872D for ; Wed, 8 Aug 2012 01:54:21 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxMkW94GOWJ2 for ; Wed, 8 Aug 2012 01:54:20 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by ietfa.amsl.com (Postfix) with ESMTP id 7382921F8723 for ; Wed, 8 Aug 2012 01:54:20 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1Sz21z-0001Td-dW; Wed, 08 Aug 2012 08:54:19 +0000 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9503DE0-9AF4-41A3-892C-ACF757ABAAD5" From: Colin Perkins In-Reply-To: <5021896D.9000108@xiph.org> Date: Wed, 8 Aug 2012 09:54:17 +0100 Message-Id: <05D10294-10A0-44CD-85EE-33FF438474C1@csperkins.org> References: <20120807211707.12041.88980.idtracker@ietfa.amsl.com> <5021896D.9000108@xiph.org> To: Timothy B. Terriberry X-Mailer: Apple Mail (2.1278) Cc: avt@ietf.org Subject: Re: [AVTCORE] New Version Notification for draft-terriberry-avp-codecs-00.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: Wed, 08 Aug 2012 08:54:21 -0000 --Apple-Mail=_F9503DE0-9AF4-41A3-892C-ACF757ABAAD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 7 Aug 2012, at 22:32, Timothy B. Terriberry wrote: > Colin Perkins pointed out that if we do not want to make implementing = the DVI4 codec a SHOULD in rtcweb, then we need to update the AVP = profile which rtcweb relies on. I also added, at Colin's suggestion, a = sentence noting that G.711 may be mandatory in some environments. This looks good to me. Thanks for preparing it. --=20 Colin Perkins http://csperkins.org/ --Apple-Mail=_F9503DE0-9AF4-41A3-892C-ACF757ABAAD5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Colin Perkins pointed out that if = we do not want to make implementing the DVI4 codec a SHOULD in rtcweb, = then we need to update the AVP profile which rtcweb relies on. I also = added, at Colin's suggestion, a sentence noting that G.711 may be = mandatory in some environments.

This = looks good to me. Thanks for preparing it.

http://csperkins.org/



= --Apple-Mail=_F9503DE0-9AF4-41A3-892C-ACF757ABAAD5-- From harald@alvestrand.no Wed Aug 8 07:28:33 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 0D93821F865E for ; Wed, 8 Aug 2012 07:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.318 X-Spam-Level: X-Spam-Status: No, score=-110.318 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFUJcSFWR+PO for ; Wed, 8 Aug 2012 07:28:32 -0700 (PDT) Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 76A2021F8653 for ; Wed, 8 Aug 2012 07:28:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4163439E106 for ; Wed, 8 Aug 2012 16:28:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XOEUR+jyAefO for ; Wed, 8 Aug 2012 16:28:25 +0200 (CEST) Received: from hta-dell.lul.corp.google.com (unknown [IPv6:2620:0:1043:1:be30:5bff:fede:bcdc]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 5752739E058 for ; Wed, 8 Aug 2012 16:28:25 +0200 (CEST) Message-ID: <50227788.4030903@alvestrand.no> Date: Wed, 08 Aug 2012 16:28:24 +0200 From: Harald Alvestrand User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: avt@ietf.org References: <20120807211707.12041.88980.idtracker@ietfa.amsl.com> <5021896D.9000108@xiph.org> In-Reply-To: <5021896D.9000108@xiph.org> Content-Type: multipart/alternative; boundary="------------050007080308000103020802" Subject: Re: [AVTCORE] Fwd: New Version Notification for draft-terriberry-avp-codecs-00.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: Wed, 08 Aug 2012 14:28:33 -0000 This is a multi-part message in MIME format. --------------050007080308000103020802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/07/2012 11:32 PM, Timothy B. Terriberry wrote: > Colin Perkins pointed out that if we do not want to make implementing > the DVI4 codec a SHOULD in rtcweb, then we need to update the AVP > profile which rtcweb relies on. I also added, at Colin's suggestion, a > sentence noting that G.711 may be mandatory in some environments. This is delightfully short, and would be even shorer if it didn't have pagebreaks at every top level section. I support the publication of this draft. > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt --------------050007080308000103020802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 08/07/2012 11:32 PM, Timothy B. Terriberry wrote:
Colin Perkins pointed out that if we do not want to make implementing the DVI4 codec a SHOULD in rtcweb, then we need to update the AVP profile which rtcweb relies on. I also added, at Colin's suggestion, a sentence noting that G.711 may be mandatory in some environments.

This is delightfully short, and would be even shorer if it didn't have pagebreaks at every top level section.

I support the publication of this draft.



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

--------------050007080308000103020802-- From kmigoe@nsa.gov Wed Aug 8 10:54:09 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 2F48A11E80F4 for ; Wed, 8 Aug 2012 10:54:09 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-jIweOuKMM9 for ; Wed, 8 Aug 2012 10:54:06 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id C93FE11E80BA for ; Wed, 8 Aug 2012 10:54:05 -0700 (PDT) X-TM-IMSS-Message-ID: <860c2740000523ec@nsa.gov> Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1) id 860c2740000523ec ; Wed, 8 Aug 2012 13:53:55 -0400 Received: from MSIS-GH1-UEA02.corp.nsa.gov (10.215.225.44) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server id 14.1.289.1; Wed, 8 Aug 2012 13:53:49 -0400 Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSIS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Aug 2012 13:53:48 -0400 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CD758E.C3652E3B" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 8 Aug 2012 13:53:48 -0400 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425C70@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01 Thread-Index: Ac1jFrdWK/01SeYRS0GjqISoVYllLgSdwrxA References: From: "Igoe, Kevin M." To: Woo-Hwan Kim , , X-OriginalArrivalTime: 08 Aug 2012 17:53:48.0759 (UTC) FILETIME=[C364EE70:01CD758E] Cc: Daesung Kwon , Je Hong Park Subject: Re: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01 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, 08 Aug 2012 17:54:09 -0000 ------_=_NextPart_001_01CD758E.C3652E3B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'd like to thank Woo-Hwang Kim for the effort he put into reviewing draft-ietf-avtcore-srtp-aes-gcm-01. He raised many valid points, and the authors have a -02 draft nearing completion that addresses his observations. Many thanks to Woo-Hwan and the AVTCORE mailing list. =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Woo-Hwan Kim Sent: Monday, July 16, 2012 1:49 AM To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Cc: Daesung Kwon; Je Hong Park Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-01 =20 Hi. =20 Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-01. =20 1. typos and minors =20 p.4 DTLS -> DTLS-SRTP p.8 ROS -> ROC p.11 the corresponding STRCP encrypted -> the corresponding SRTCP encrypted p.13 C_max -> C_MAX p.18 AEAD_AES_128_CCM -> AEAD_AES_128_GCM p.18 AEAD_AES_256_CCM -> AEAD_AES_256_GCM =20 2. On the CCM decryption =20 In this draft, there is no separation between GCM and CCM except "Tag_Size_Flag".=20 It means both modes have the same parameters (nonce length, counter block length etc.) and the same IV format (described in Sections 8.1 and 9.1).=20 But that does not hold if the authors intend to apply the interfaces of CCM described in RFC 5116.=20 For example, the counter block length parameter q is not 4 but 3 when the length of nonce is 12 octets.=20 =20 According to the InputFormatting Function proposed in NIST SP 800-38C (and referred by RFC 5116),=20 Tag_Size_Flag recommended in this draft is derived when q=3D3.=20 Note that such parameter is related to several AEAD parameters, and so a large portion of the draft should be revised. =20 3. CCM Tag Validation =20 Section 5.3 says "The ciphertext MUST NOT be decrypted until the AEAD tag has been validated. The associated data MUST NOT be released until the AEAD tag has been validated." =20 The above does not hold for CCM mode of operation,=20 because it is required to decrypt ciphertext before confirming the validation of the AEAD tag. =20 4. Ciphertext length expansion for SRTP =20 Section 9.2 says "Since the AEAD cipher is larger than the plaintext by exactly the length of the AEAD authentication=20 tag, the corresponding STRCP encrypted packet replaces the plaintext field with a slightly larger=20 field containing the cipher." =20 Does this sentence only hold for SRTCP? =20 5. Input/output data for CCM (Sections 5.2.1 and 5.2.2) =20 Both input and output data for CCM require Tag_Size_Flag, but that is the value which can be computed=20 by three parameters (defined in NIST SP 800-38C). Because Tag_Size_Flag is not included in SRTP/SRTCP=20 packets, the only way to share the same Tag_Size_Flag is to fix authentication tag length and counter=20 block length in advance. =20 Additionally, Section 5.2.1 says the only output of "Encrypt Mode" is "Ciphertext" with bit string length =3D legnth length(ciphertext)-tag_length.=20 What is the difference between "ciphertext" and "Ciphertext". If length of the "Ciphertext" does not consider the length of "authentication tag",=20 where is authentication tag? =20 =20 6. CCM tag length specification =20 Section 10.3 =20 RFC5116 only defines AEAD_AES_128/256_CCM with 16 octets tag length. =20 Section 13.2 =20 "Note that these SRTP Protection Profiles do not specify an auth_function, auth_key_length, or=20 auth_tag_length because all of these profiles use AEAD algorithms, and thus do not use a separate auth_function, auth_key, or auth_tag." =20 In IANA AEAD registry, there is no entry for AEAD_AES_128/256_CCM_12.=20 It means that there is no official reference for AES_CCM with 96-bit authentication tag. So it is required to define=20 AEAD_AES_128/256_CCM_12 independently in this document, similar to AEAD_AES_128/256_CCM_8 defined for=20 TLS usage(internet draft, AES-CCM Cipher Suites for TLS).=20 =20 For SDES, it may be necessary to add CCM-related crypto suites with 64- and 96-bit authentication tags. =20 Thanks. =20 Woo-Hwan Kim ------_=_NextPart_001_01CD758E.C3652E3B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’d = like to thank Woo-Hwang Kim for the effort he put into = reviewing

draft-ietf-avtcore= -srtp-aes-gcm-01.  He raised many valid points, and the = authors

have a -02 = draft nearing completion that addresses his observations.  Many = thanks

to Woo-Hwan = and the AVTCORE mailing list.=

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Woo-Hwan Kim
Sent: Monday, July 16, 2012 1:49 = AM
To: avt@ietf.org; = draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
Cc: Daesung = Kwon; Je Hong Park
Subject: [AVTCORE] Comments on the = draft-ietf-avtcore-srtp-aes-gcm-01

 

Hi.

 

Here are some comments on the = draft-ietf-avtcore-srtp-aes-gcm-01.

 

1. typos and minors

 

p.4 DTLS -> DTLS-SRTP

p.8 ROS -> ROC

p.11 the corresponding STRCP encrypted -> the = corresponding SRTCP encrypted

p.13 C_max -> C_MAX

p.18 AEAD_AES_128_CCM -> = AEAD_AES_128_GCM

p.18 = AEAD_AES_256_CCM -> AEAD_AES_256_GCM

 

2. On the CCM decryption

 

In this draft, there is no separation between GCM and = CCM except "Tag_Size_Flag“. 

It means both modes have the same parameters (nonce = length, counter block length etc.) and the same IV format = (described in Sections 8.1 and 9.1). 

But that does not hold if the authors intend to apply = the interfaces of CCM described in RFC = 5116. 

For example, = the counter block length parameter q is not 4 but 3 when the length of = nonce is 12 octets. 

 

According to the InputFormatting Function proposed in = NIST SP 800-38C (and referred by RFC = 5116), 

Tag_Size_Flag = recommended in this draft is derived when = q=3D3. 

Note that = such parameter is related to several AEAD parameters, and so a = large portion of the draft should be = revised.

 

3. CCM Tag Validation

 

Section 5.3 says

"The ciphertext MUST NOT be decrypted until the = AEAD tag has been validated. The associated = data

MUST NOT be released = until the AEAD tag has been validated."

 

The above does not hold for CCM mode of = operation, 

because = it is required to decrypt ciphertext before confirming the = validation of the AEAD tag.

 

4. Ciphertext length expansion for = SRTP

 

Section 9.2 says

"Since the AEAD cipher is larger than the = plaintext by exactly the length of the AEAD = authentication 

tag, = the corresponding STRCP encrypted packet replaces the plaintext field = with a slightly larger 

field containing the = cipher."

 

Does this sentence only hold for = SRTCP?

 

5. Input/output data for CCM (Sections 5.2.1 and = 5.2.2)

 

Both input and output data for CCM require = Tag_Size_Flag, but that is the value which can be = computed 

by three = parameters (defined in NIST SP 800-38C). Because Tag_Size_Flag is not = included in SRTP/SRTCP 

packets, the only way to share the same Tag_Size_Flag = is to fix authentication tag length and = counter 

block length = in advance.

 

Additionally, Section 5.2.1 says the only output of = "Encrypt Mode" is "Ciphertext" with bit = string length =3D legnth = length(ciphertext)-tag_length. 

What is the difference between "ciphertext" = and "Ciphertext". If length of the "Ciphertext" = does not consider the length of "authentication = tag", 

where is = authentication tag?

 

 

6. CCM tag length = specification

 

Section 10.3

 

RFC5116 only defines AEAD_AES_128/256_CCM with 16 = octets tag length.

 

Section 13.2

 

"Note that these SRTP Protection Profiles do not = specify an auth_function, auth_key_length, = or 

auth_tag_length = because all of these profiles use AEAD algorithms, and thus do not use a = separate auth_function, auth_key, or = auth_tag."

 

In IANA AEAD registry, there is no entry for = AEAD_AES_128/256_CCM_12. 

It means that there is no official reference for = AES_CCM with 96-bit authentication tag. So it is required to = define 

AEAD_AES_128/256_CCM_12 independently in this = document, similar to AEAD_AES_128/256_CCM_8 defined = for 

TLS = usage(internet draft, AES-CCM Cipher Suites for = TLS). 

 

For SDES, it may be necessary to add CCM-related = crypto suites with 64- and 96-bit = authentication tags.

 

Thanks.

 

Woo-Hwan = Kim

------_=_NextPart_001_01CD758E.C3652E3B-- From cris.pascual.gonzalez@gmail.com Sat Aug 11 00:04: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 EC2DF11E80D9 for ; Sat, 11 Aug 2012 00:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.07 X-Spam-Level: X-Spam-Status: No, score=-5.07 tagged_above=-999 required=5 tests=[AWL=-0.471, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ek2azY2Tdbou for ; Sat, 11 Aug 2012 00:04:28 -0700 (PDT) Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id A854911E80A3 for ; Sat, 11 Aug 2012 00:04:27 -0700 (PDT) Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id q7B74PfT027959 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 11 Aug 2012 09:04:25 +0200 Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id q7B74PEK004177 for ; Sat, 11 Aug 2012 09:04:25 +0200 Received: from JLLORET (vpn245-14.vpns.upv.es [158.42.245.14]) by smtp.upv.es (8.13.6/8.13.6) with SMTP id q7B74Oxv001342 for ; Sat, 11 Aug 2012 09:04:24 +0200 Date: Sat, 11 Aug 2012 09:04:24 +0200 Message-Id: <201208110704.q7B74Oxv001342@smtp.upv.es> From: Cristina Pascual To: avt@ietf.org CC: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailman-Approved-At: Sat, 11 Aug 2012 08:06:01 -0700 Subject: [AVTCORE] CfP: VisGra 2013 || January 27 - February 1, 2013 - Seville, Spain 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: Sat, 11 Aug 2012 07:04:29 -0000 INVITATION: ================= Please consider to contribute to and/or forward to the appropriate groups the following opportunity to submit and publish original scientific results to VisGra 2013. The submission deadline is September 14, 2012. Authors of selected papers will be invited to submit extended article versions to one of the IARIA Journals: http://www.iariajournals.org ================= ============== VisGra 2013 | Call for Papers =============== CALL FOR PAPERS, TUTORIALS, PANELS VisGra 2013, The Second International Workshop on Computer Vision and Computer Graphics January 27 - February 1, 2013 - Seville, Spain General page: http://www.iaria.org/conferences2013/VisGra.html Call for Papers: http://www.iaria.org/conferences2013/VisGra.html#CallForPapers - regular papers - short papers (work in progress) - posters - industrial presentations Submission page: http://www.iaria.org/conferences2013/VisGra.html#SubmitAPaper Submission deadline: September 14, 2012 Sponsored by IARIA, www.iaria.org Extended versions of selected papers will be published in IARIA Journals: http://www.iariajournals.org Print proceedings will be available via Curran Associates, Inc.: http://www.proceedings.com/9769.html Articles will be archived in the free access ThinkMind Digital Library: http://www.thinkmind.org Please note the Poster and Work in Progress options. The topics suggested by the conference can be discussed in term of concepts, state of the art, research, standards, implementations, running experiments, applications, and industrial case studies. Authors are invited to submit complete unpublished papers, which are not under review in any other conference or journal in the following, but not limited to, topic areas. All tracks are open to both research and industry contributions, in terms of Regular papers, Posters, Work in progress, Technical/marketing/business presentations, Demos, Tutorials, and Panels. Before submission, please check and comply with the Editorial rules: http://www.iaria.org/editorialrules.html VisGra 2013 Topics (topics and submission details: see CfP on the site) Fundamental algorithms for computer graphics and computer vision Model representation and simplification Parametric curves and surfaces Illumination techniques Colors and color systems Virtual and augmented reality, haptic systems Human-computer interaction Real time rendering Image processing, image reconstruction Pattern recognition 3D scene reconstruction Segmentation Motion detection Scientific and technical visualization Medical imaging Information visualization 3D TV Mobile graphics and vision system Industrial application of computer graphics and vision ---------------------- Committee: http://www.iaria.org/conferences2013/VisGra.html#Committees to be updated soon ================= From wwwrun@rfc-editor.org Sat Aug 11 13:58: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 508F311E808D for ; Sat, 11 Aug 2012 13:58:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.301 X-Spam-Level: X-Spam-Status: No, score=-102.301 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t58lbsC49jwA for ; Sat, 11 Aug 2012 13:58:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9943811E8097 for ; Sat, 11 Aug 2012 13:58:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id F2134B1E002; Sat, 11 Aug 2012 13:57:08 -0700 (PDT) To: jo@acm.org, stewe@stewe.org, sato652@oki.com, carsten.burmeister@eu.panasonic.com, jose.rey@eu.panasonic.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20120811205708.F2134B1E002@rfc-editor.org> Date: Sat, 11 Aug 2012 13:57:08 -0700 (PDT) X-Mailman-Approved-At: Sun, 12 Aug 2012 09:40:32 -0700 Cc: rfc-editor@rfc-editor.org, avt@ietf.org Subject: [AVTCORE] [Technical Errata Reported] RFC4585 (3313) 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: Sat, 11 Aug 2012 20:58:24 -0000 The following errata report has been submitted for RFC4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4585&eid=3313 -------------------------------------- Type: Technical Reported by: Mo Zanaty Section: 4.2 Original Text ------------- rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty Corrected Text -------------- rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] Notes ----- RFC 4585 defines and allows generic NACK (with no further parameters) but not generic ACK (which always requires further parameters). Section 4.2 says: ... Parameters MUST be provided to further distinguish different types of positive acknowledgement feedback. ... The feedback type "nack", without parameters, indicates use of the Generic NACK feedback format as defined in Section 6.2.1. ... The ABNF incorrectly allows nothing after "ack", implying that generic ACK is valid. Even the approved errata, which replaces the invalid empty alternate with optional [], still allows nothing after "ack". Note that recent interest in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard ACK. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4585 (draft-ietf-avt-rtcp-feedback-11) -------------------------------------- Title : Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF) Publication Date : July 2006 Author(s) : J. Ott, S. Wenger, N. Sato, C. Burmeister, J. Rey Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From ron.even.tlv@gmail.com Tue Aug 14 09:12: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 F3B5921F863B for ; Tue, 14 Aug 2012 09:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Gs+oMrDwKYI for ; Tue, 14 Aug 2012 09:11:59 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB7521F85AC for ; Tue, 14 Aug 2012 09:11:58 -0700 (PDT) Received: by weyu54 with SMTP id u54so472983wey.31 for ; Tue, 14 Aug 2012 09:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=CSV6Gh79EhPpdgfC1G57A1FBu1ejew12CvIvRMvj1dk=; b=nGdkgnUG5faUgEBer0B89++i9A3/UJHZbuablh1r5c7ixwQfBwleco16RsX4nXnkYd TOhv3NK+bEUNBAubzVUk6vTyjEB5mcjJESequGLgnRKcekzbMFLs0laA2vaDIG8/JHn1 o8zL9ldfzDvWdo3VC+r+GDizBxB5/qdUX6viyp4xnwL79dXwTYA6j5SEWQPNJqQxNIQk lfAel11eY3qppjXPVyUnP/iZLbfp10aDb6H+mUJgsyWAjzWxaLypooZVHWfT0Ug9CiPy kWZwhnKTLfvtTigYUSSTNhnem1BaDD3BZAlRrPrd0duOoPO3eXt8m882i///ZawPIswI uLyA== Received: by 10.180.74.33 with SMTP id q1mr29136915wiv.4.1344960718253; Tue, 14 Aug 2012 09:11:58 -0700 (PDT) Received: from RoniE ([109.65.229.195]) by mx.google.com with ESMTPS id z11sm33768700wiv.10.2012.08.14.09.11.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Aug 2012 09:11:57 -0700 (PDT) From: "Roni Even" To: Date: Tue, 14 Aug 2012 19:10:45 +0200 Message-ID: <003401cd7a3f$c0332cc0$40998640$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0035_01CD7A50.83BC4AE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac16P6f6WmMis8SESIGEP8t5eA264w== Content-Language: en-us Subject: [AVTCORE] Updtaed minutes of the IETF84 meeting 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, 14 Aug 2012 16:12:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0035_01CD7A50.83BC4AE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Based on comments I got this are the updated minutes http://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore Roni Even AVTcore co-chair ------=_NextPart_000_0035_01CD7A50.83BC4AE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Based on = comments I got this are the updated minutes ht= tp://www.ietf.org/proceedings/84/minutes/minutes-84-avtcore =

Roni Even

AVTcore co-chair

------=_NextPart_000_0035_01CD7A50.83BC4AE0-- From kevin.gross@avanw.com Tue Aug 14 10:47: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 0551B21F876A for ; Tue, 14 Aug 2012 10:47:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.215 X-Spam-Level: X-Spam-Status: No, score=-0.215 tagged_above=-999 required=5 tests=[AWL=1.427, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQejSV71ddRU for ; Tue, 14 Aug 2012 10:47:07 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 3898921F85E0 for ; Tue, 14 Aug 2012 10:47:07 -0700 (PDT) Received: (qmail 6500 invoked by uid 0); 14 Aug 2012 17:46:44 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy7.bluehost.com with SMTP; 14 Aug 2012 17:46:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=GS+IwcCdjxCdvyCIXhK8INl73WMIbmfEEUEvRYQxI2M=; b=bWNH4qs0uNmXFK0ocFiGMoXFMTd0SiV3bdlUoLrFafirxXf/gQHyAYvetZyyoP8egsFCR/grmNgW+k26xJEmhnw37UeEFQBCULja699iHtKi7IwTO6D01iA/KypU2pNp; Received: from [74.125.82.172] (port=40025 helo=mail-we0-f172.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.76) (envelope-from ) id 1T1LCS-0000Mx-Uw for avt@ietf.org; Tue, 14 Aug 2012 11:46:41 -0600 Received: by weyu54 with SMTP id u54so542438wey.31 for ; Tue, 14 Aug 2012 10:46:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.97.135 with SMTP id ea7mr29714713wib.11.1344966399315; Tue, 14 Aug 2012 10:46:39 -0700 (PDT) Received: by 10.223.83.66 with HTTP; Tue, 14 Aug 2012 10:46:39 -0700 (PDT) In-Reply-To: References: <008101cd742e$494a5be0$dbdf13a0$@gmail.com> <9B1445E9-423A-4E66-A400-154D6F08E6A7@csperkins.org> Date: Tue, 14 Aug 2012 11:46:39 -0600 Message-ID: From: Kevin Gross To: Jonathan Lennox Content-Type: multipart/alternative; boundary=f46d043bdb4e7750c104c73d64d5 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 74.125.82.172 authed with kevin.gross@avanw.com} Cc: Colin Perkins , "avt@ietf.org" Subject: Re: [AVTCORE] IETF 84 AVTcore minutes 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, 14 Aug 2012 17:47:08 -0000 --f46d043bdb4e7750c104c73d64d5 Content-Type: text/plain; charset=ISO-8859-1 A couple corrections to RTP Clock Source Signalling section based on notes I took during and after my presentation: - A specific suggestion from Martin was to replace GPS and other specific traceable clock specifications with a generic traceable clock with stratum specification - Johnathan's comment suggesting using RTCP was during the clock confidence discussion, not stream identification - Magnus recommended generating a unique identifier to cross reference streams as part of stream identification Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Aug 7, 2012 at 3:53 AM, Jonathan Lennox wrote: > On Tuesday, August 7 2012, "Colin Perkins" wrote: > > > For the circuit-breakers draft, my understanding was that the comment > from Jonathan was that the mechanism should work if RTP/AVPF is used, but > that we don't need to define a more sophisticated circuit breaker for the > RTP/AVPF profile. > > Yes, that's correct. > > -- > Jonathan Lennox > jonathan@vidyo.com > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d043bdb4e7750c104c73d64d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable A couple corrections to RTP Clock Source Signalling section based on notes = I took during and after my presentation:
  • A specific suggestion = from Martin was to replace GPS and other specific traceable clock specifica= tions with a generic traceable clock with stratum specification
  • Johnathan's comment suggesting using RTCP was during the clock conf= idence discussion, not stream identification
  • Magnus recommended gen= erating a unique identifier to cross reference streams as part of stream id= entification

Kevin Gross
Media Network Consultant
AVA Networks -=A0w= ww.AVAnw.com,=A0www.X= 192.org



On Tue, Aug 7, 2012 at 3:53 AM, Jonathan= Lennox <jonathan@vidyo.com> wrote:
On Tuesday, August 7 2012, "Colin Perkins" wrote:

> For the circuit-breakers draft, my understanding was that the comment = from Jonathan was that the mechanism should work if RTP/AVPF is used, but t= hat we don't need to define a more sophisticated circuit breaker for th= e RTP/AVPF profile.

Yes, that's correct.

--
Jonathan Lennox
jonathan@vidyo.com<= /a>

--f46d043bdb4e7750c104c73d64d5-- From wwwrun@rfc-editor.org Tue Aug 14 15:24: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 9064A21E80BC for ; Tue, 14 Aug 2012 15:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.297 X-Spam-Level: X-Spam-Status: No, score=-102.297 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPlkUOwA4Tn1 for ; Tue, 14 Aug 2012 15:24:28 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id C95BE21E80B9 for ; Tue, 14 Aug 2012 15:24:28 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 91888B1E002; Tue, 14 Aug 2012 15:23:02 -0700 (PDT) To: yekuiwang@huawei.com, even.roni@huawei.com, tom.kristensen@tandberg.com, rjesup@wgate.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, keith.drage@alcatel-lucent.com, even.roni@huawei.com From: RFC Errata System Message-Id: <20120814222302.91888B1E002@rfc-editor.org> Date: Tue, 14 Aug 2012 15:23:02 -0700 (PDT) X-Mailman-Approved-At: Wed, 15 Aug 2012 11:47:21 -0700 Cc: weix@avaya.com, avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Technical Errata Reported] RFC6184 (3318) 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, 14 Aug 2012 22:24:29 -0000 The following errata report has been submitted for RFC6184, "RTP Payload Format for H.264 Video". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6184&eid=3318 -------------------------------------- Type: Technical Reported by: Xiaohui Wei (Joanne) Section: 8.1 Original Text ------------- On page 46 start from line 7: "When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 3 / 8. Consequently, a receiver that signals max-dpb ^^^^^ MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 3 / 8 / ( PicWidthInMbs * FrameHeightInMbs), ^^^^^ 16)" Corrected Text -------------- When max-dpb is signaled, the receiver MUST be able to decode NAL unit streams that conform to the signaled highest level, with the exception that the MaxDpbMbs value in Table A-1 of [1] for the signaled highest level is replaced with the value of max-dpb * 8 / 3. Consequently, a receiver that signals max-dpb ^^^^^ MUST be capable of storing the following number of decoded frames, complementary field pairs, and non-paired fields in its decoded picture buffer: Min(max-dpb * 8 / 3 / ( PicWidthInMbs * FrameHeightInMbs), ^^^^^ 16) Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6184 (draft-ietf-avt-rtp-rfc3984bis-12) -------------------------------------- Title : RTP Payload Format for H.264 Video Publication Date : May 2011 Author(s) : Y.-K. Wang, R. Even, T. Kristensen, R. Jesup Category : PROPOSED STANDARD Source : Audio/Video Transport Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From Internet-Drafts@ietf.org Thu Aug 16 09:32:16 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 8EA6C21F8549; Thu, 16 Aug 2012 09:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 houDDbfRqSXH; Thu, 16 Aug 2012 09:32:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0263621F8495; Thu, 16 Aug 2012 09:32:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.33 Message-ID: <20120816163216.27790.42862.idtracker@ietfa.amsl.com> Date: Thu, 16 Aug 2012 09:32:16 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D ACTION:draft-ietf-avtcore-srtp-aes-gcm-02.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: Thu, 16 Aug 2012 16:32:16 -0000 --NextPart 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 : AES-GCM and AES-CCM Authenticated Encryption in Secure RTP (SRTP) Author(s) : D. McGrew, et al Filename : draft-ietf-avtcore-srtp-aes-gcm Pages : 26 Date : Aug. 16, 2012 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-avtcore-srtp-aes-gcm-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-avtcore-srtp-aes-gcm"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2012-08-16093215.I-D@ietf.org> --NextPart-- From internet-drafts@ietf.org Thu Aug 23 19:48:28 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 95E4021F8577; Thu, 23 Aug 2012 19:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 h1K+wfFoGhVQ; Thu, 23 Aug 2012 19:48:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A15221F850B; Thu, 23 Aug 2012 19:48:28 -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: <20120824024828.13627.96983.idtracker@ietfa.amsl.com> Date: Thu, 23 Aug 2012 19:48:28 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-monarch-18.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, 24 Aug 2012 02:48:28 -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-18.txt Pages : 28 Date : 2012-08-23 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-18 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-monarch-18 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Mon Aug 27 09:39: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 C432821F8534 for ; Mon, 27 Aug 2012 09:39:31 -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 0a7jh6KpIJPY for ; Mon, 27 Aug 2012 09:39:31 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 18FCE21F8554 for ; Mon, 27 Aug 2012 09:39:29 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2379900wgb.13 for ; Mon, 27 Aug 2012 09:39:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=Jn436XrbAwqdm9Qk4AzQSZhb463thlRP3mkoY9fOT6g=; b=tILJpM0GvRyPaCW77sR9y/I2zAHhUkJgCg023XMJoXKiaqf01qZBEFy3FF27kY43T5 McbFqBq9UZbH0tTBiF+I+lDTRzfINgNEXOVWErANXTW6s4ckPbJSf6zVS1CE+M3WBBqh J+EDTXV0sSAUChMtW5y09KGzaWpVLh+lLSzbXrU0pXPqxHU0GdeTReVgtOusktlMfu2P kT+IC/IoHMcvLVyyVzOZAj9DWZzKDkBf0NYN9mnjk2AOJlz9T9DMGWPkFChsGIuuXQaL TYIMVYCZQJxCKP3mtsFg6rsmshAi4k08OvWTIePsFMlcbl4iFiSl7ZxOB6jaM6/8oTLR 78jA== Received: by 10.180.77.34 with SMTP id p2mr26736993wiw.0.1346085565064; Mon, 27 Aug 2012 09:39:25 -0700 (PDT) Received: from RoniE ([109.67.233.208]) by mx.google.com with ESMTPS id cu1sm85732wib.6.2012.08.27.09.39.22 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 27 Aug 2012 09:39:23 -0700 (PDT) From: "Roni Even" To: Date: Mon, 27 Aug 2012 19:38:05 +0200 Message-ID: <009701cd847a$b92727c0$2b757740$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01CD848B.7CB09400" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2EejHhiI5me+oXTBmO+PlMv8LH2Q== Content-Language: en-us Subject: [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, 27 Aug 2012 16:39:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0098_01CD848B.7CB09400 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0098_01CD848B.7CB09400 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would like to = start a second WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-srtp-encrypted-h= eader-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

------=_NextPart_000_0098_01CD848B.7CB09400-- From woohwankim@gmail.com Mon Aug 27 21:14:41 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 A5DEE21F849D for ; Mon, 27 Aug 2012 21:14:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 brQU+iE7n4EK for ; Mon, 27 Aug 2012 21:14:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id B4A3B21F8495 for ; Mon, 27 Aug 2012 21:14:37 -0700 (PDT) Received: by iabz21 with SMTP id z21so10941650iab.31 for ; Mon, 27 Aug 2012 21:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=m1hU7iKYuzHaaiLFi111BD+HqLp8QEh9cAV/waouYoc=; b=s7z3Fwj55ftHjPgH2bfe5wwxN6MVvkxxb9Q6mH6QENolykMX5PQoo84vLpSE1/6TMz S8ZI/iO1O8+kD2mCCjSQL4/KAA6eKPFAArAOaSjXaQgjGwZkhxs1HdknkKvZ76fRwutr LVuX52mHRc8OCv9lgXwglMeTD/3c4QDiTFEfBXqoXUuHezk3RXpOJWNVNdgL5dgQ/qbV Xf+Fx/a7TVZ14JFADWMcP69raviM80OjU9RWVmCJv3WRw2zX8Eq3zqhzs5o45TWBGxWV mSf15wyKMiyM6qYqJxN+nWCtaXG49oVRqlXl3xdsAyJT/X4MFjP+Hc8QVfUuHK7lg+LR dPXg== MIME-Version: 1.0 Received: by 10.50.6.168 with SMTP id c8mr12156848iga.21.1346127274851; Mon, 27 Aug 2012 21:14:34 -0700 (PDT) Sender: woohwankim@gmail.com Received: by 10.64.64.164 with HTTP; Mon, 27 Aug 2012 21:14:34 -0700 (PDT) Date: Tue, 28 Aug 2012 13:14:34 +0900 X-Google-Sender-Auth: 5Js2YVfuBUqRQ-IpVEO6Rk2rUhI Message-ID: From: Woo-Hwan Kim To: avt@ietf.org, draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Content-Type: multipart/alternative; boundary=e89a8f6467150a3e2804c84bae43 Cc: Daesung Kwon , Je Hong Park Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-02 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, 28 Aug 2012 04:14:41 -0000 --e89a8f6467150a3e2804c84bae43 Content-Type: text/plain; charset=EUC-KR Content-Transfer-Encoding: quoted-printable Hi. Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-02. 1. Typos Sections 5.2.1, 6. length(plaintext) =A1=E6 length(Plaintext) i.e. plaintex= t =3D> Plaintext Section 5.2.2. length(ciphertext) =A1=E6 length(Ciphertext) i.e. ciphertext =3D> Ciphertext Section 6. 12 octet IV =3D> 12-octet IV Section 6. ~ to form cipher =3D> to form ciphertext Section 6(CCM part). 4-octet block counter =3D> 3-octet block counter Section 6(CCM pseudocode). assert len(plaintext) <=3D 2**28 =3D> ... (2**2= 8-16) Section 6. keystream of length of up to 2^24 octets for AES-CCM =3D> ... 2^28-16 octgets ... * In CCM counter starts from 0 and the first block is used for generation the tag. Sections 9.1, 10.1 12 octet initialization vector =3D> 12-octet initialization vector (IV) Section 10.3. cipher field =3D> ciphertext field Section 11.1. C_MAX CCM: MUST be at most 2^24+16 octets =3D> ... 2^28 octet= s ... 2. Mode of operations In Section 6, keystream generation parts of GCM and CCM are described. But, both descriptions have some flaws based on NIST specifications For GCM, pseudocode should be modified as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D def GCM_keystream(Plaintext, IV, Encryption_key): assert len(Plaintext) <=3D=3D (2**36 - 32) key_stream =3D "" block_counter =3D 1 first_key_block =3D AES_ENC(data =3D IV || block_counter, key =3D Encryption_key) while len(key_stream) < len(Plaintext): block_counter =3D block_counter + 1 key_block =3D AES_ENC(data =3D IV || block_counter, key =3D Encryption_key) key_stream =3D key_stream || key_block key_stream =3D truncate(key_stream, len(Plaintext)) return (key_stream, first_key_block) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here, the role of the "first_key_block" (or pre_counter block stated in NIST SP 800-38C) is the same as that of the "last_key_block" For CCM, pseudocode should be modified as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D def CCM_keystream(Plaintext, IV, Counter_Flag, Encryption_key): assert len(Plaintext) <=3D=3D 2**28 key_stream =3D "" block_counter =3D 0 first_key_block =3D AES_ENC(data =3D Counter_block_Flag || IV || block_counter, key =3D Encryption_key) while len(key_stream) < len(Plaintext): block_counter =3D block_counter + 1 key_block =3D AES_ENC(data =3D Counter_Flag || IV || block_counter, key =3D Encryption_key) key_stream =3D key_stream || key_block key_stream =3D truncate(key_stream, len(Plaintext)) return (key_stream, first_key_block) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tag_Size_Flag is only used as the leading octet of the output value of InputFormattingFunction. And there is a separate flag namely Counter_Flag to formatting the counter block. Because the pseudocode described in this draft is related to keystream generation, the flag should be Counter_Block_Flag. As noted in GCM, the "first_key_block" is used to generate AEAD authenticated tag. 3. In Section 5.2, AES-CCM uses a Tag_Size_Flag...: There are two kinds of flags in CCM. One is in the input formatting function and the other is in the counter block. "Tag_Size_Flag" seems to be the former and it is determined by the existence of associated data, tag size and block counter size. Thus the term "Tag_Size_Flag" seems to be unsuitable. Moreover, the term "Tag_Size_Flag" does not have to be used, since the algorithm choice determines the tag size in CCM similarly to GCM, 4. RFC 4771 It seems that there are some differences on implementing RFC 4771 when AEAD authentication mechanism is used instead of general MAC algorithm. Though the description of those differences is out of scope of this draft, it may be possible to make certain of it. 5. In Sections 9.2, 10.2 and 10.3, the length of authentication tags for SRTP and SRTCP have the same fixed value (32-bit). In RFC 3711, however, authentication tag length is configurable. 6. In Section 10.2 (Data types in encrypted SRTCP compounded packets), can the case of empty plaintext field be occurred? 7. Comparing with Figure 4, the only difference of Figure 5 is that the plaintext field is to be authenticated but not encrypted. It would be better to unify the description of Sections 10.2 and 10.3 like Section 3.4 in RFC 3711. 8. In Section 11.2 and 11.3, the tag size of mandatory implementation for GCM is 8 octets while that for CCM is 16 octets. Are there any reasons causing this difference? 9. What about addition of the following cipher suites in 14.1 like DTLS? - AEAD_AES_128_CCM_8, AEAD_AES_128_CCM_12, AEAD_AES_256_CCM_8, AEAD_AES_256_CCM_12. Thanks. Woo-Hwan Kim --e89a8f6467150a3e2804c84bae43 Content-Type: text/html; charset=EUC-KR Content-Transfer-Encoding: quoted-printable
Hi.

Here are some comments on t= he draft-ietf-avtcore-srtp-aes-gcm-02.

1. Ty= pos
Sections 5.2.1, 6. length(plaintext) =A1=E6 length(Plaintext) i.e. pla= intext =3D> Plaintext
Section 5.2.2. length(ciphertext) =A1=E6= length(Ciphertext) i.e. ciphertext =3D> Ciphertext
Section 6. 12 octet IV  =3D>  12-octet IV
Section 6. ~ to form cipher  =3D>  to form ciphertext
Section 6(CCM part). 4-octe= t block counter  =3D>  3-octet block counter
Section 6(CCM pseudocode= ). assert len(plaintext) <=3D 2**28  =3D> ... (2**28-16)
Section 6. keystream of length of up to 2^24 octets for AES-CCM =3D> = ... 2^28-16 octgets ...
* In CCM counter starts from 0 and the first block is used for generat= ion the tag.
Sections 9.1, 10.1 12 octet initialization vector&nb= sp; =3D>  12-octet initialization vector (IV)
Section 10= .3. cipher field  =3D>  ciphertext field
Section 11.1. C_MAX CCM: MUST= be at most 2^24+16 octets =3D> ... 2^28 octets ...

=
2. Mode of operations
In Section 6, keystream generation par= ts of GCM and CCM are described. 
But, both descriptions have some flaws based on NIST specifications
For GCM, pseudocode should be modified as follows:
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
def GCM_keystream(Plaintext, IV, Encryption_key):    assert len(P= laintext) <=3D=3D (2**36 – 32)
    key_stream = =3D “”
    block_counter =3D 1
&n= bsp;   first_key_block =3D AES_ENC(data =3D IV || block_counter,  = ;                     &nb= sp;       
                    =                      = ;      key =3D Encryption_key)
    while= len(key_stream) < len(Plaintext):
       = block_counter =3D block_counter + 1
        = key_block =3D AES_ENC(data =3D IV || block_counter,
                    =            key =3D Encryption_key)
=         key_stream =3D key_stream || key_block
    key_stream =3D truncate(key_stream, len(Plaintext))
    return (key_stream, first_key_block)
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Here= , the role of the “first_key_block” (or pre_counter block state= d in NIST SP 800-38C) is the same as that of the “last_key_block&rdqu= o;

For CCM, pseudocode should be modified as follows:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
def = CCM_keystream(Plaintext, IV, Counter_Flag, Encryption_key):    as= sert len(Plaintext) <=3D=3D 2**28
    key_stream =3D “”
    bl= ock_counter =3D 0
    first_key_block =3D AES_ENC(data = =3D Counter_block_Flag || IV || block_counter,         =                      = ;  
                =                      = ;         key =3D Encryption_key)
    while len(key_stream) < len(Plaintext):
&nb= sp;       block_counter =3D block_counter + 1
&nbs= p;       key_block =3D AES_ENC(data =3D Counter_Flag || IV |= | block_counter,
             =                     &nbs= p;         key =3D Encryption_key)
        key_stream =3D key_stream || key_block
    key_stream =3D truncate(key_stream, len(Plaintext))
    return (key_stream, first_key_block)
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Tag_Size_Flag is only used as the leading octet of the output value of= InputFormattingFunction. 
And there is a separate flag name= ly Counter_Flag to formatting the counter block. 
Because th= e pseudocode described in this draft is  related to keystream generati= on, the flag should be Counter_Block_Flag.

As noted in GCM, the “first_key_block” is u= sed to generate AEAD authenticated tag.

3. In Sect= ion 5.2, AES-CCM uses a Tag_Size_Flag...: 
There are two kin= ds of flags in CCM. One is in the input formatting function and the other i= s in the counter block. 
"Tag_Size_Flag" seems to be the former and it is determined = by the existence of associated data, tag size and block counter size.
=
 Thus the term "Tag_Size_Flag" seems to be unsuitable.&= nbsp;
Moreover, the term "Tag_Size_Flag" does not have to be used,= since  the algorithm choice determines the tag size in CCM similarly = to GCM,

4. RFC 4771
It seems that there = are some differences on implementing RFC 4771 when AEAD authentication mech= anism is used instead of general MAC algorithm. 
Though the description of those differences is out of scope of this dr= aft, it may be possible to make certain of it.

5. = In Sections 9.2, 10.2 and 10.3, the length of authentication tags for SRTP = and SRTCP have the same fixed value (32-bit).
In RFC 3711, however, authentication tag length is configurable.
=

6. In Section 10.2 (Data types in encrypted SRTCP compo= unded packets), can the case of empty plaintext field be occurred?

7. Comparing with Figure 4, the only difference of Figu= re 5 is that the plaintext field is to be authenticated but not encrypted.&= nbsp;
It would be better to unify the description of Sections 10.= 2 and 10.3 like Section 3.4 in RFC 3711.

8. In Section 11.2 and 11.3, the tag size of mandatory = implementation for GCM is 8 octets while that for CCM is 16 octets.
 Are there any reasons causing this difference?

9. What about addition of the following cipher suites in 14.1 like DTL= S?
- AEAD_AES_128_CCM_8, AEAD_AES_128_CCM_12, AEAD_AES_256_CCM_8,= AEAD_AES_256_CCM_12.

Thanks.

Woo-Hwan Kim


--e89a8f6467150a3e2804c84bae43-- From kmigoe@nsa.gov Thu Aug 30 12:00: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 2909E21F8605 for ; Thu, 30 Aug 2012 12:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.893 X-Spam-Level: X-Spam-Status: No, score=-8.893 tagged_above=-999 required=5 tests=[AWL=-0.895, BAYES_50=0.001, 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 uQl2zBPGEizw for ; Thu, 30 Aug 2012 12:00:07 -0700 (PDT) Received: from nsa.gov (emvm-gh1-uea09.nsa.gov [63.239.67.10]) by ietfa.amsl.com (Postfix) with ESMTP id 3F40221F85C4 for ; Thu, 30 Aug 2012 12:00:05 -0700 (PDT) X-TM-IMSS-Message-ID: Received: from MSHT-GH1-UEA02.corp.nsa.gov ([10.215.227.181]) by nsa.gov ([63.239.67.10]) with ESMTP (TREND IMSS SMTP Service 7.1) id f7938e7f0009b8d8 ; Thu, 30 Aug 2012 15:01:23 -0400 Received: from MSMR-GH1-UEA08.corp.nsa.gov (10.215.225.3) by MSHT-GH1-UEA02.corp.nsa.gov (10.215.227.181) with Microsoft SMTP Server (TLS) id 14.1.289.1; Thu, 30 Aug 2012 14:59:47 -0400 Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA08.corp.nsa.gov ([10.215.225.3]) with mapi id 14.01.0289.001; Thu, 30 Aug 2012 14:59:47 -0400 From: "Igoe, Kevin M." To: 'Woo-Hwan Kim' , "avt@ietf.org" , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" Thread-Topic: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-02 Thread-Index: AQHNhNOrY6KlpjyIQE66hqxGwKvgKpdyrCqg Date: Thu, 30 Aug 2012 18:59:45 +0000 Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA07493698@MSMR-GH1-UEA03.corp.nsa.gov> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.254.27] Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA07493698MSMRGH1UEA03cor_" MIME-Version: 1.0 Cc: Daesung Kwon , Je Hong Park Subject: Re: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-02 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, 30 Aug 2012 19:00:12 -0000 --_000_3C4AAD4B5304AB44A6BA85173B4675CA07493698MSMRGH1UEA03cor_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Once again, many thanks to Woo-Hwan for his careful review. I=1B$B!G=1B(Bd caught the bug about taking the last_key_block instead of th= e first_key_block about 3 minutes after hitting the submit button. Murhpy=1B$B!G=1B(Bs law! Typos & changes suggested in (1) and (2) have been made. (3) Since the CCM octet flag is constant (0x02) in this application, I hard= wired it into the pseudo-code and eliminated the Tag_Size_Flag/Counter_Flag variable entirely. (4) Not sure what you mean in this comment. (5) The diagrams in section 9.2, 10.2 and 10.3 are largely copied from RFC = 3711. Since we deprecate the use of the existing SRTP authentication field, I thi= nk I=1B$B!G=1B(Bll leave the diagrams as they are. (6) If there is no plaintext in the packet, you really should be using sect= ion 10.3 (i.e. the encryption bit set to 0). However there is no harm in havin= g an empty plaintext field, save that the cipher text field will be non-trivi= al since it contains the AEAD-MAC. Section 10.3 addresses where the MAC should be put, section 10.2 doesn=1B$B!G=1B(Bt. (7) On unifying Figure 4 and Figure 5: I=1B$B!G=1B(Bve had a hard time typ= esetting this to meet the maximum line length specification for RFCs. My attempts at combining them kept pushing my over that limit, whence my decision to split into tow figures. (8) and (9): There is a peculiar difference between how CCM and GCM specify the size of the authentication tag. In CCM the tag length is an ex= ternal parameter, CCM with an 8-octet tag and CCM with a 12-octet tag are considered to be the same algorithm running with a different tag size parameter. But in GCM it has been traditional to consider GCM-8 and GCM-12 to be separate algorithms. The draft requires that GCM-8 MUST be supported, but by definition any compliant implementation of CCM must b= e capable of handling 4, 6, 8, 10, 12, 14 and 16 octet authentication tags. I agree the distinction between the two approached is largely sophistry, but it is there none the less. That affects how things go into the IANA re= gistry. It also explains why CCM has no single =1B$B!H=1B(Bmandatory to implement= =1B$B!I=1B(B tag size. Of course any given system is likely to hardwire in one tag size which is felt to best meet their security and latency constraints. We felt 8-octets was a reasonable compromise, whence making AES-8 mandatory to implement for GCM (by definition an 8-octet tag is already mandatory to implement for CCM, as are the other 6 values.) I have a draft -03 ready to go, just holding off until I get some more feed= back. Let me know if you=1B$B!G=1B(Bd like to see it before Iformally submit it t= o the IETF. From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Woo-H= wan Kim Sent: Tuesday, August 28, 2012 12:15 AM To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org Cc: Daesung Kwon; Je Hong Park Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-02 Hi. Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-02. 1. Typos Sections 5.2.1, 6. length(plaintext) =1B$B"*=1B(B length(Plaintext) i.e. pl= aintext =3D> Plaintext Section 5.2.2. length(ciphertext) =1B$B"*=1B(B length(Ciphertext) i.e. ciph= ertext =3D> Ciphertext Section 6. 12 octet IV =3D> 12-octet IV Section 6. ~ to form cipher =3D> to form ciphertext Section 6(CCM part). 4-octet block counter =3D> 3-octet block counter Section 6(CCM pseudocode). assert len(plaintext) <=3D 2**28 =3D> ... (2**2= 8-16) Section 6. keystream of length of up to 2^24 octets for AES-CCM =3D> ... 2^= 28-16 octgets ... * In CCM counter starts from 0 and the first block is used for generation t= he tag. Sections 9.1, 10.1 12 octet initialization vector =3D> 12-octet initializ= ation vector (IV) Section 10.3. cipher field =3D> ciphertext field Section 11.1. C_MAX CCM: MUST be at most 2^24+16 octets =3D> ... 2^28 octet= s ... 2. Mode of operations In Section 6, keystream generation parts of GCM and CCM are described. But, both descriptions have some flaws based on NIST specifications For GCM, pseudocode should be modified as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D def GCM_keystream(Plaintext, IV, Encryption_key): assert len(Plaintext) = <=3D=3D (2**36 - 32) key_stream =3D =1B$B!H!I=1B(B block_counter =3D 1 first_key_block =3D AES_ENC(data =3D IV || block_counter, key =3D Encryption_key) while len(key_stream) < len(Plaintext): block_counter =3D block_counter + 1 key_block =3D AES_ENC(data =3D IV || block_counter, key =3D Encryption_key) key_stream =3D key_stream || key_block key_stream =3D truncate(key_stream, len(Plaintext)) return (key_stream, first_key_block) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Here, the role of the =1B$B!H=1B(Bfirst_key_block=1B$B!I=1B(B (or pre_count= er block stated in NIST SP 800-38C) is the same as that of the =1B$B!H=1B(B= last_key_block=1B$B!I=1B(B For CCM, pseudocode should be modified as follows: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D def CCM_keystream(Plaintext, IV, Counter_Flag, Encryption_key): assert l= en(Plaintext) <=3D=3D 2**28 key_stream =3D =1B$B!H!I=1B(B block_counter =3D 0 first_key_block =3D AES_ENC(data =3D Counter_block_Flag || IV || block_= counter, key =3D Encryption_key) while len(key_stream) < len(Plaintext): block_counter =3D block_counter + 1 key_block =3D AES_ENC(data =3D Counter_Flag || IV || block_counter, key =3D Encryption_key) key_stream =3D key_stream || key_block key_stream =3D truncate(key_stream, len(Plaintext)) return (key_stream, first_key_block) =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Tag_Size_Flag is only used as the leading octet of the output value of Inpu= tFormattingFunction. And there is a separate flag namely Counter_Flag to formatting the counter = block. Because the pseudocode described in this draft is related to keystream gen= eration, the flag should be Counter_Block_Flag. As noted in GCM, the =1B$B!H=1B(Bfirst_key_block=1B$B!I=1B(B is used to gen= erate AEAD authenticated tag. 3. In Section 5.2, AES-CCM uses a Tag_Size_Flag...: There are two kinds of flags in CCM. One is in the input formatting functio= n and the other is in the counter block. "Tag_Size_Flag" seems to be the former and it is determined by the existenc= e of associated data, tag size and block counter size. Thus the term "Tag_Size_Flag" seems to be unsuitable. Moreover, the term "Tag_Size_Flag" does not have to be used, since the alg= orithm choice determines the tag size in CCM similarly to GCM, 4. RFC 4771 It seems that there are some differences on implementing RFC 4771 when AEAD= authentication mechanism is used instead of general MAC algorithm. Though the description of those differences is out of scope of this draft, = it may be possible to make certain of it. 5. In Sections 9.2, 10.2 and 10.3, the length of authentication tags for SR= TP and SRTCP have the same fixed value (32-bit). In RFC 3711, however, authentication tag length is configurable. 6. In Section 10.2 (Data types in encrypted SRTCP compounded packets), can = the case of empty plaintext field be occurred? 7. Comparing with Figure 4, the only difference of Figure 5 is that the pla= intext field is to be authenticated but not encrypted. It would be better to unify the description of Sections 10.2 and 10.3 like = Section 3.4 in RFC 3711. 8. In Section 11.2 and 11.3, the tag size of mandatory implementation for G= CM is 8 octets while that for CCM is 16 octets. Are there any reasons causing this difference? 9. What about addition of the following cipher suites in 14.1 like DTLS? - AEAD_AES_128_CCM_8, AEAD_AES_128_CCM_12, AEAD_AES_256_CCM_8, AEAD_AES_256= _CCM_12. Thanks. Woo-Hwan Kim --_000_3C4AAD4B5304AB44A6BA85173B4675CA07493698MSMRGH1UEA03cor_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

Once again, many thanks t= o Woo-Hwan for his careful review. 

 <= /p>

I=1B$B!G=1B(Bd caught the= bug about taking the last_key_block instead of the first_key_block

about 3 minutes after hit= ting the submit button.  Murhpy=1B$B!G=1B(Bs law!

 <= /p>

Typos & changes sugge= sted in (1) and (2) have been made. 

 <= /p>

(3) Since the CCM octet f= lag is constant (0x02) in this application, I hard wired it

into the pseudo-code and = eliminated the Tag_Size_Flag/Counter_Flag variable

entirely.

 <= /p>

(4) Not sure what you mea= n in this comment.

 <= /p>

(5) The diagrams in secti= on 9.2, 10.2 and 10.3 are largely copied from RFC 3711.

Since we deprecate the us= e of the existing SRTP authentication field, I think

I=1B$B!G=1B(Bll leave the= diagrams as they are.

 <= /p>

(6) If there is no plaint= ext in the packet, you really should be using section

10.3 (i.e. the encryption= bit set to 0).  However there is no harm in having<= /p>

an empty plaintext field,= save that the cipher text field will be non-trivial

since it contains the AEA= D-MAC.  Section 10.3 addresses where the MAC

should be put, section 10= .2 doesn=1B$B!G=1B(Bt.

 <= /p>

(7) On unifying Figure 4 = and Figure 5:  I=1B$B!G=1B(Bve had a hard time typesetting this to

meet the maximum line len= gth specification for RFCs.  My attempts at

combining them kept pushi= ng my over that limit, whence my decision to split

into tow figures.

 <= /p>

(8) and (9):  There = is a peculiar difference between how CCM and GCM

specify the size of the a= uthentication tag.  In CCM the tag length is an external

parameter, CCM with an 8-= octet tag and CCM with a 12-octet tag are

considered to be the same= algorithm running with a different tag

size parameter.  But= in GCM it has been traditional to consider GCM-8 and

GCM-12  to be separa= te algorithms.  The draft requires that GCM-8 MUST

be supported,  but b= y definition any compliant implementation of CCM must be<= /p>

capable of handling 4, 6,= 8, 10, 12, 14 and 16 octet authentication tags.

I agree the distinction b= etween the two approached is largely sophistry,

but it is there none the = less.  That affects how things go into the IANA registry.

It also explains why CCM = has no single =1B$B!H=1B(Bmandatory to implement=1B$B!I=1B(B tag size.=

 <= /p>

Of course any given syste= m is likely to hardwire in one tag size which is

felt to best meet their s= ecurity and latency constraints.  We felt

8-octets was a reasonable= compromise, whence making AES-8 mandatory

to implement for GCM (by = definition an 8-octet tag is already mandatory to

implement for CCM, as are= the other 6 values.)

 <= /p>

I have a draft -03 ready = to go, just holding off until I get some more feedback. 

Let me know if you=1B$B!G= =1B(Bd like to see it before Iformally submit it to the IETF.

 <= /p>

From: avt-boun= ces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Woo-Hwan Kim
Sent: Tuesday, August 28, 2012 12:15 AM
To: avt@ietf.org; draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org
Cc: Daesung Kwon; Je Hong Park
Subject: [AVTCORE] Comments on the draft-ietf-avtcore-srtp-aes-gcm-0= 2

 

= Hi.

=  

= Here are some comments on the draft-ietf-avtcore-srtp-aes-gcm-02.

 

1. Typos

Sections 5.2.1, 6. length(plaintext) =1B$B"*=1B(B le= ngth(Plaintext) i.e. plaintext =3D> Plaintext

Section 5.2.2. length(ciphertext) =1B$B"*=1B(B lengt= h(Ciphertext) i.e. ciphertext =3D> Ciphertext

Section 6. 12 octet IV  =3D>  12-o= ctet IV

Section 6. ~ to form cipher  =3D>  = ;to form ciphertext

Section 6(CCM part). 4-octet block counter  =3D= >  3-octet block counter

Section 6(CCM pseudocode). assert len(plaintext) <= ;=3D 2**28  =3D> ... (2**28-16)

Section 6. keystream of length of up to 2^24 octets = for AES-CCM =3D> ... 2^28-16 octgets ...

* In CCM counter starts from 0 and the first block i= s used for generation the tag.

Sections 9.1, 10.1 12 octet initialization vector&nb= sp; =3D>  12-octet initialization vector (IV)

Section 10.3. cipher field  =3D>  = ciphertext field

Section 11.1. C_MAX CCM: MUST be at most 2^24+16= octets =3D> ... 2^28 octets ...

 

2. Mode of operations

In Section 6, keystream generation parts of GCM and = CCM are described. 

But, both descriptions have some flaws based on NIST= specifications

For GCM, pseudocode should be modified as follows:

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

def GCM_keystream(Plaintext, IV, Encryption_key): &n= bsp;  assert len(Plaintext) <=3D=3D (2**36 – 32)

    key_stream =3D =1B$B!H!I=1B(B

    block_counter =3D 1

    first_key_block =3D AES_ENC(data =3D I= V || block_counter,                =               

              &nb= sp;                     &= nbsp;          key =3D Encryption_key)<= /p>

    while len(key_stream) < len(Plainte= xt):

        block_counter =3D block_= counter + 1

        key_block =3D AES_ENC(da= ta =3D IV || block_counter,

              &nb= sp;                key =3D Encrypti= on_key)

        key_stream =3D key_strea= m || key_block

    key_stream =3D truncate(key_stream, le= n(Plaintext))

    return (key_stream, first_key_block)

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

Here, the role of the =1B$B!H=1B(Bfirst_key_block=1B= $B!I=1B(B (or pre_counter block stated in NIST SP 800-38C) is the same as t= hat of the =1B$B!H=1B(Blast_key_block=1B$B!I=1B(B

 

For CCM, pseudocode should be modified as follows:

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

def CCM_keystream(Plaintext, IV, Counter_Flag, Encry= ption_key):    assert len(Plaintext) <=3D=3D 2**28<= /p>

    key_stream =3D =1B$B!H!I=1B(B

    block_counter =3D 0

    first_key_block =3D AES_ENC(data =3D C= ounter_block_Flag || IV || block_counter,          = ;                     &nb= sp;

              &nb= sp;                     &= nbsp;         key =3D Encryption_key)

    while len(key_stream) < len(Plainte= xt):

        block_counter =3D block_= counter + 1

        key_block =3D AES_ENC(da= ta =3D Counter_Flag || IV || block_counter,

              &nb= sp;                     &= nbsp;       key =3D Encryption_key)

        key_stream =3D key_strea= m || key_block

    key_stream =3D truncate(key_stream, le= n(Plaintext))

    return (key_stream, first_key_block)

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

Tag_Size_Flag is only used as the leading octet of t= he output value of InputFormattingFunction. 

And there is a separate flag namely Counter_Flag to = formatting the counter block. 

Because the pseudocode described in this draft is &n= bsp;related to keystream generation, the flag should be Counter_Block_Flag.=

 

As noted in GCM, the =1B$B!H=1B(Bfirst_key_block=1B$= B!I=1B(B is used to generate AEAD authenticated tag.

 

3. In Section 5.2, AES-CCM uses a Tag_Size_Flag...:&= nbsp;

There are two kinds of flags in CCM. One is in the i= nput formatting function and the other is in the counter block. <= /o:p>

"Tag_Size_Flag" seems to be the former and= it is determined by the existence of associated data, tag size and block c= ounter size.

 Thus the term "Tag_Size_Flag" seems = to be unsuitable. 

Moreover, the term "Tag_Size_Flag" does no= t have to be used, since  the algorithm choice determines the tag size= in CCM similarly to GCM,

 

4. RFC 4771

It seems that there are some differences on implemen= ting RFC 4771 when AEAD authentication mechanism is used instead of general= MAC algorithm. 

Though the description of those differences is out o= f scope of this draft, it may be possible to make certain of it.=

 

5. In Sections 9.2, 10.2 and 10.3, the length of aut= hentication tags for SRTP and SRTCP have the same fixed value (32-bit).

In RFC 3711, however, authentication tag length is c= onfigurable.

 

6. In Section 10.2 (Data types in encrypted SRTCP co= mpounded packets), can the case of empty plaintext field be occurred?<= /o:p>

 

7. Comparing with Figure 4, the only difference of F= igure 5 is that the plaintext field is to be authenticated but not encrypte= d. 

It would be better to unify the description of Secti= ons 10.2 and 10.3 like Section 3.4 in RFC 3711.

 

8. In Section 11.2 and 11.3, the tag size of mandato= ry implementation for GCM is 8 octets while that for CCM is 16 octets.=

 Are there any reasons causing this difference?=

 

9. What about addition of the following cipher suite= s in 14.1 like DTLS?

- AEAD_AES_128_CCM_8, AEAD_AES_128_CCM_12, AEAD_AES_= 256_CCM_8, AEAD_AES_256_CCM_12.

 

Thanks.

 

Woo-Hwan Kim

 

 

--_000_3C4AAD4B5304AB44A6BA85173B4675CA07493698MSMRGH1UEA03cor_--