From abegen@cisco.com Tue Mar 1 16:38:01 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A71643A6AE0 for ; Tue, 1 Mar 2011 16:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.536 X-Spam-Level: X-Spam-Status: No, score=-10.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lCdDgYzsZzUb for ; Tue, 1 Mar 2011 16:38:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 5E4053A6A45 for ; Tue, 1 Mar 2011 16:38:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=2422; q=dns/txt; s=iport; t=1299026345; x=1300235945; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=+BRKMM+ARyD9OOgsrhwoqUj81ftG+z7MxFDURFtx1tQ=; b=kuns3Nl2WkTK81PoXcmjttPo2xJhWlt/hY8O+fDW6JfIMb3doaxznW/C 3M7rZ7o2fMAgamZWJZqfgt0pATxg7bnOy3bNGsfZh+zerSgMkclHmB9zu VSPy4tsfXNnb2vkbOwTVztl4U5jPtIZkjhF3cAXk0ucbR8rOf2KVrGzx9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvkAAHMgbU2rRN+K/2dsb2JhbACXfo5WdKIdm3qFYQSFEopTgw4 X-IronPort-AV: E=Sophos;i="4.62,250,1297036800"; d="scan'208";a="267597665" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 02 Mar 2011 00:39:04 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p220d44v002716; Wed, 2 Mar 2011 00:39:04 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 16:39:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2011 16:38:18 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E6BFF29@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: FEC Framework DISCUSSes (was RE: [Fecframe] Ops/Management Cons. text for fecframe) Thread-Index: AcvYcgSHX4Izzxi0QeayL1ccCJWuBw== From: "Ali C. Begen (abegen)" To: "Sean Turner" , "Russ Housley" , X-OriginalArrivalTime: 02 Mar 2011 00:39:04.0436 (UTC) FILETIME=[3B624B40:01CBD872] Cc: fecframe@ietf.org Subject: [Fecframe] FEC Framework DISCUSSes (was RE: Ops/Management Cons. text for fecframe) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 00:38:01 -0000 We are dangerously getting close to the submission deadline and as the = authors, we would like to complete this draft so that remaining work can = move forward. Russ, Sean, David,=20 Could you please review the changes and let us know whether you are ok = with them or require further changes? https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ballot/=20 -acbegen > -----Original Message----- > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] > Sent: Wednesday, February 16, 2011 5:14 AM > To: Ali C. Begen (abegen); gjshep@gmail.com > Cc: fecframe@ietf.org; Sean Turner; Russ Housley > Subject: RE: [Fecframe] Ops/Management Cons. text for fecframe >=20 > I cleared. >=20 > Thank you for addressing my concerns. >=20 > Regards, >=20 > Dan >=20 >=20 > > -----Original Message----- > > From: Ali C. Begen (abegen) [mailto:abegen@cisco.com] > > Sent: Wednesday, February 16, 2011 12:09 AM > > To: gjshep@gmail.com > > Cc: Romascanu, Dan (Dan); fecframe@ietf.org; Sean Turner; Russ = Housley > > Subject: RE: [Fecframe] Ops/Management Cons. text for fecframe > > > > Revision has been submitted. > > > > Dan, David, Russ and Sean, > > > > Please let us know if this revision addressed your concerns > > and DISCUSSes. > > https://datatracker.ietf.org/doc/draft-ietf-fecframe-framework/ > > > > Thanks. > > -acbegen > > > > > -----Original Message----- > > > From: Greg Shepherd [mailto:gjshep@gmail.com] > > > Sent: Tuesday, February 15, 2011 10:59 AM > > > To: Ali C. Begen (abegen) > > > Cc: Romascanu, Dan (Dan); fecframe@ietf.org; Sean Turner; > > Russ Housley > > > Subject: Re: [Fecframe] Ops/Management Cons. text for fecframe > > > > > > Ali, > > > > > > Yes, please submit a revision with these changes. > > > > > > Thanks, > > > Greg > > > > > > On Mon, Feb 14, 2011 at 3:35 AM, Ali C. Begen (abegen) > > wrote: > > > > > > > >> I am OK with your proposed changes. > > > > > > > > Thanks. > > > > > > > > David, > > > > > > > > Should we submit a revision with these changes (and > > addressing the comments from the list)? > > > > > > > > -acbegen > > > > > > > >> Regards, > > > >> > > > >> Dan > > > >> > > > > _______________________________________________ > > > > Fecframe mailing list > > > > Fecframe@ietf.org > > > > https://www.ietf.org/mailman/listinfo/fecframe > > > > > > From Internet-Drafts@ietf.org Fri Mar 4 08:00:04 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE6023A6946; Fri, 4 Mar 2011 08:00:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.389 X-Spam-Level: X-Spam-Status: No, score=-102.389 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqqcERD4cIaS; Fri, 4 Mar 2011 08:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DABF3A69BE; Fri, 4 Mar 2011 08:00:01 -0800 (PST) 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: 3.12 Message-ID: <20110304160001.23982.39397.idtracker@localhost> Date: Fri, 04 Mar 2011 08:00:01 -0800 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-14.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:00:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Forward Error Correction (FEC) Framework Author(s) : M. Watson, et al. Filename : draft-ietf-fecframe-framework-14.txt Pages : 47 Date : 2011-03-04 This document describes a framework for using Forward Error Correction (FEC) codes with applications in public and private IP networks to provide protection against packet loss. The framework supports applying FEC to arbitrary packet flows over unreliable transport and is primarily intended for real-time, or streaming, media. This framework can be used to define Content Delivery Protocols that provide FEC for streaming media delivery or other packet flows. Content Delivery Protocols defined using this framework can support any FEC scheme (and associated FEC codes) which is compliant with various requirements defined in this document. Thus, Content Delivery Protocols can be defined which are not specific to a particular FEC scheme, and FEC schemes can be defined which are not specific to a particular Content Delivery Protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-framework-14.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-fecframe-framework-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-04075340.I-D@ietf.org> --NextPart-- From abegen@cisco.com Fri Mar 4 08:04:39 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B9E5A3A68EE for ; Fri, 4 Mar 2011 08:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WXhoSqCsCaIE for ; Fri, 4 Mar 2011 08:04:38 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B5AB73A6802 for ; Fri, 4 Mar 2011 08:04:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=abegen@cisco.com; l=1836; q=dns/txt; s=iport; t=1299254748; x=1300464348; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=FXRbmbTP0xO7F6hA6MRVpXYWGAbIDqwDDu6L3F5rhqA=; b=G5Top/SJ3/NUuVQ/1KTA7jVHlaoGQqqNkfPgyqRmAHy7p6LD7tt7W07C BVEG6pH3SR//qBF+5lHqfgYxnb0Rn5g7hBQMHlqeQjkGdB2HPo9y2z1Xq 6nth+dNbPjjHneN3HPd/QCc6V70+B+3lTtNEEzc4w65RR4hEjPbJWs2Jl s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAD+ccE2rRN+J/2dsb2JhbACEKZN9jVthdKM3iwyQYoEng0R2BIUcilw X-IronPort-AV: E=Sophos;i="4.62,264,1297036800"; d="scan'208";a="269630776" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2011 16:05:48 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p24G5lam001921; Fri, 4 Mar 2011 16:05:48 GMT Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 08:05:47 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 4 Mar 2011 08:05:37 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540E7610B9@xmb-sjc-215.amer.cisco.com> In-Reply-To: <20110304160003.23982.80335.idtracker@localhost> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification - draft-ietf-fecframe-framework-14.txt Thread-Index: AcvahXDaFFt4HZrvRJeD5AT9ZOYjHQAAGYqQ References: <20110304160003.23982.80335.idtracker@localhost> From: "Ali C. Begen (abegen)" To: , , , , X-OriginalArrivalTime: 04 Mar 2011 16:05:47.0817 (UTC) FILETIME=[06686990:01CBDA86] Cc: fecframe@ietf.org Subject: Re: [Fecframe] New Version Notification - draft-ietf-fecframe-framework-14.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 16:04:39 -0000 Q29uc2lkZXJpbmcgdGhlIGFwcHJvYWNoaW5nIGRlYWRsaW5lIChpbiBjYXNlIHdlIHdvdWxkIG5l ZWQgb25lIG1vcmUgcmV2aXNpb24pIGFuZCBtaW5vciBjb21tZW50cyBwcm92aWRlZCBvbiB0aGUg bGFzdCB2ZXJzaW9uLCBJIHN1Ym1pdHRlZCBhIG5ldyB2ZXJzaW9uLg0KDQpEaWZmIGlzIGhlcmU6 DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZmVjZnJhbWUt ZnJhbWV3b3JrLTE0IA0KDQpUaGVyZSBhcmUgY3VycmVudGx5IDMgRElTQ1VTU2VzIGFuZCB3ZSBn b3QgV0cgY29uc2Vuc3VzIGluIGFkZHJlc3NpbmcgZWFjaC4NCg0KRGF2aWQncyBESVNDVVNTIHdh cyBhZGRyZXNzZWQgaW4gdmVyc2lvbiAxMy4NClNlYW4ncyBESVNDVVNTIHdhcyBhZGRyZXNzZWQg aW4gdmVyc2lvbiAxMg0KUnVzcycgRElTQ1VTUyB3YXMgYWRkcmVzc2VkIGluIHZlcnNpb24gMTEu DQoNCkNvdWxkIHlvdSBwbGVhc2UgY2xlYXIgeW91ciBESVNDVVNTZXMgc28gdGhhdCB3ZSBjb3Vs ZCBwcm9jZWVkIHdpdGggdGhlIGRlcGVuZGVudCBkcmFmdHM/IElmIHlvdSBzdGlsbCBoYXZlIGNv bmNlcm5zLCB3ZSB3aWxsIGRvIG91ciBiZXN0IHRvIGFkZHJlc3MgdGhlbSBiZWZvcmUgdGhlIGN1 dG9mZiBkYXRlLg0KDQpUaGFua3MuDQotYWNiZWdlbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IEludGVybmV0LURyYWZ0QGlldGYub3JnIFttYWlsdG86SW50ZXJuZXQt RHJhZnRAaWV0Zi5vcmddDQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMDQsIDIwMTEgMTE6MDAgQU0N Cj4gVG86IGZlY2ZyYW1lLWNoYWlyc0B0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1mZWNmcmFt ZS1mcmFtZXdvcmtAdG9vbHMuaWV0Zi5vcmc7IGlldGZkYmhAY29tY2FzdC5uZXQ7DQo+IGhvdXNs ZXlAdmlnaWxzZWMuY29tOyBpZXRmZGJoQGNvbWNhc3QubmV0OyB0dXJuZXJzQGllY2EuY29tDQo+ IFN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiAtIGRyYWZ0LWlldGYtZmVjZnJhbWUt ZnJhbWV3b3JrLTE0LnR4dA0KPiANCj4gTmV3IHZlcnNpb24gKC0xNCkgaGFzIGJlZW4gc3VibWl0 dGVkIGZvciBkcmFmdC1pZXRmLWZlY2ZyYW1lLWZyYW1ld29yay0xNC50eHQuDQo+IGh0dHA6Ly93 d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtZmVjZnJhbWUtZnJhbWV3b3Jr LTE0LnR4dA0KPiANCj4gDQo+IERpZmYgZnJvbSBwcmV2aW91cyB2ZXJzaW9uOg0KPiBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtZmVjZnJhbWUtZnJhbWV3b3Jr LTE0DQo+IA0KPiBJRVRGIFNlY3JldGFyaWF0Lg0K From vincent.roca@inrialpes.fr Mon Mar 7 02:17:10 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76583A67DF for ; Mon, 7 Mar 2011 02:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0lhN+vFKg6S for ; Mon, 7 Mar 2011 02:17:10 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id C55913A6950 for ; Mon, 7 Mar 2011 02:17:08 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,276,1297033200"; d="scan'208";a="77259873" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Mar 2011 11:18:20 +0100 Message-ID: <4D74B0EB.3080407@inrialpes.fr> Date: Mon, 07 Mar 2011 11:18:19 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "fecframe@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fecframe] "Simple Reed-Solomon FEC Scheme" I-D updated X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 10:17:11 -0000 Hello, We have updated the Simple Reed-Solomon FEC Scheme for FECFRAME as a WG Item I-D. The document is not yet reflected in the datatracker (it's awaiting Greg's official approval as an -00 version). In the meantime you can get it from: http://planete.inrialpes.fr/people/roca/doc/draft-ietf-fecframe-simple-rs-00.txt Main changes: - new "Security Considerations" section: this section discusses topics that are specific to this I-D and refers to the FEC Framework for general security discussions. - added an "Operations and Management" section: similarly this section discusses topics that are specific to this I-D and refers to the FEC Framework for general O&M discussions. We now believe this I-D will be ready for WGLC once published. Cheers, Vincent et al. From vincent.roca@inrialpes.fr Mon Mar 7 02:54:02 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DCA13A695D for ; Mon, 7 Mar 2011 02:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.603 X-Spam-Level: X-Spam-Status: No, score=-9.603 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, HELO_EQ_FR=0.35, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VppvqghSeCuF for ; Mon, 7 Mar 2011 02:54:01 -0800 (PST) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id E3B723A67AE for ; Mon, 7 Mar 2011 02:54:00 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.62,276,1297033200"; d="scan'208";a="89349736" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 07 Mar 2011 11:55:12 +0100 Message-ID: <4D74B990.4050501@inrialpes.fr> Date: Mon, 07 Mar 2011 11:55:12 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 CC: "fecframe@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Fecframe] "Simple LDPC-Staircase FEC Scheme" I-D updated X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 10:54:02 -0000 Hello, We did the same with the other scheme, namely the Simple LDPC-Staircase FEC scheme. For the same reason this document is not yet reflected in the datatracker (it's awaiting Greg's official approval as an -00 version). In the meantime you can get it from: http://planete.inrialpes.fr/people/roca/doc/draft-ietf-fecframe-ldpc-00.txt Main changes: - new "Security Considerations" section: this section discusses topics that are specific to this I-D and refers to the FEC Framework for general security discussions. - added an "Operations and Management" section: similarly this section discusses topics that are specific to this I-D and refers to the FEC Framework for general O&M discussions. - we've added a 4-bit reserved field (set to 0) in the FSSI binary encoding format since the n1m3 field (initially coded over 7 bits) belongs to 0-7 and only needs 3 bits. We now believe this I-D will be ready for WGLC once published. Cheers, Vincent et al. From gjshep@gmail.com Wed Mar 9 16:53:06 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96B1F3A698A for ; Wed, 9 Mar 2011 16:53:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.487 X-Spam-Level: X-Spam-Status: No, score=-103.487 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kQT-FRHdD0k5 for ; Wed, 9 Mar 2011 16:53:06 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id DB3713A67B8 for ; Wed, 9 Mar 2011 16:53:05 -0800 (PST) Received: by iwl42 with SMTP id 42so1317082iwl.31 for ; Wed, 09 Mar 2011 16:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=Ncq+yzReQjb1EBSNNEhecTsrRBAjApKTpi+f4HcN8Gk=; b=SVJUjVc++0+KNZ9k2vNW3lj3Ap0OpMVrn/L24YbNv4lFgpPVi5i+YSWR1jaZt+QMe9 /1egRtZBxqmjCgcoD44P4WhmHyVrFvp9imtLWCw8TZ8OVGakAeXfnO98OFVn+MjJPa0s OZUVxqm6HClCw0XQBmCkGd8EMZhJd1nbfX/WI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=QAd5kBLymZOty4Cst4Ea7YJxQFMFPUBSbRAHLcKcnyablJNA72Ag3Z7yZ96NlJ844I ssdGpmjUMQ6wC3QEeqU6B03tYvXAPxt2hFLXATiJ0wOLT9X0n3S1Zv+R2luPC9NM53Pf 0B845cAerRdLSlGQE7qtt+wRbv0IP1pmfXqI8= MIME-Version: 1.0 Received: by 10.231.80.193 with SMTP id u1mr5521129ibk.87.1299718462884; Wed, 09 Mar 2011 16:54:22 -0800 (PST) Received: by 10.231.144.75 with HTTP; Wed, 9 Mar 2011 16:54:22 -0800 (PST) Date: Wed, 9 Mar 2011 16:54:22 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Call For Agenda Items X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 00:53:06 -0000 *, Prague is approaching so please send your agenda items in so we can post beforehand. Thanks!, Greg From gjshep@gmail.com Fri Mar 11 04:12:10 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 699833A6A21; Fri, 11 Mar 2011 04:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+HZ-t+6H-8x; Fri, 11 Mar 2011 04:12:09 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 109F33A6A17; Fri, 11 Mar 2011 04:12:09 -0800 (PST) Received: by iyj8 with SMTP id 8so3151834iyj.31 for ; Fri, 11 Mar 2011 04:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type; bh=lmHn6ryXBXRJPUGpWS9W9PhzsQbny88bcFptxslUHeA=; b=v3UKVcu7W/MCkj4r0B8OMd8Dfq8tN2ecOi5VdK+qBTsBhh1eRrxX/ZUE27gGq5pOc+ vHvAzboHyG3XDCdjSxrF3QxjkEfrHlSTcnkhvEb+CaGMoaykjTU+EbWBZ34Sa1TKryZG rxeAsc13fwPgqlPTA9Z7JuCwiwTAXeEwrPeLE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type; b=w/Z37GnRn3UtcksKB67CbeZwfa/p4D4QUboxhHNhVboAY9Uzo7Nh8GFLzk8lIIhW7O ljJDBy7STf0sR5exdrSpnt3xx+mwyISG0rwwsLw6EKmv0l/dcYkQOgUJKVnsV4uylF+Y ortj4plnf5I+W2iYyEPUs5vcOYs9qNbqgRCCc= MIME-Version: 1.0 Received: by 10.43.47.72 with SMTP id ur8mr4695897icb.9.1299845608153; Fri, 11 Mar 2011 04:13:28 -0800 (PST) Received: by 10.231.144.75 with HTTP; Fri, 11 Mar 2011 04:13:28 -0800 (PST) Date: Fri, 11 Mar 2011 04:13:28 -0800 Message-ID: From: Greg Shepherd To: iesg-secretary@ietf.org, David Harrington , fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] request for pub draft-ietf-rtp-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 12:12:10 -0000 *, The document draft-ietf-fecframe-rtp-raptor-04 is now ready for publication. Please see the Document Shepherd Write-up below. Thanks, Greg --- Document Shepherd Write-up for draft-ietf-rtp-raptor-04 as per RFC 4858, template dated September 17, 2008 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? I, Greg Shepherd as the document shepherd have personally reviewed this document and believe it to be ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The document has had adequate review both from within and from outside the FECFrame working group. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? There are no concerns regarding the need for additional expanded review. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. There are no specific concerns with this document. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? There is solid WG consensus for this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) There is no discontent. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See the Internet-Drafts Checklist and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? Only two miscellaneous warnings and one outdated reference which can be addressed with editor's notes: == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 25, 2010) is 46 days in the past. Is this intentional? == Outdated reference: A later version (-04) exists of draft-ietf-fecframe-raptor-02 (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. Normative and informative references are split with two reference to drafts that are currently in the editor's queue or will be soon. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC5226]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Section 12 describes the IANA considerations, which refers to Section 5 for a comprehensive registration description. The document itself is primarily a document of media registrations/definitions. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? The xml code validates correctly (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary This document specifies an RTP payload format for Forward Error Correction / (FEC) repair data produced by the Raptor FEC schemes. Raptor FEC schemes are specified for use with the IETF FEC Framework which supports transport of repair data over both UDP and RTP. This document specifies the payload format which is required for the use of RTP to carry Raptor repair flows. Working Group Summary There were no seriously contentious issues during the WG process. Document Quality The Working Group feedback covered both the quality of the document itself as well as the technical issues with the content of the document. Personal Document Shepherd - Greg Shepherd Responsible Area Director - David Harrington From gjshep@gmail.com Fri Mar 11 04:12:35 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5C5E3A692C for ; Fri, 11 Mar 2011 04:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.549 X-Spam-Level: X-Spam-Status: No, score=-103.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yv7KCwre9GB3 for ; Fri, 11 Mar 2011 04:12:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id AB4BB3A688C for ; Fri, 11 Mar 2011 04:12:34 -0800 (PST) Received: by mail-iy0-f172.google.com with SMTP id 8so3151834iyj.31 for ; Fri, 11 Mar 2011 04:13:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=kmhwSYpjCnMbUpE3uaNjqvjoAWcntDlc/5u44FlNu50=; b=EkD0LiAV2yTnry5K0TNiUn1K19382/MeJ0VCAbvUOgc7BzKGrmZ/zcbzecebqqmtrM prshWRYXIzIqARNqfgRI11OdkgVK/2I1p+EwoEppW6f49Om33pRFLMlb9V48gguDOYH4 kv03VXMBZUVRcRz9SkqMU8WSF8o9tUxvvRj1Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=lRB3tnYTJkz/3bOL4UuPpRF8NfejGW2d+guea6itoDc1VFZoxKn4R+B4KGalkZQE1U 0FptbY1nHNcTmLyhBQLXiTLIwvf9uU61l/Vtbz/UbtxmgkI8nZxlGUU5LTkpQ7xMwMML 9TV8RKlMyKTTje3S2eOtrftywOvN3HdWYLq4Y= MIME-Version: 1.0 Received: by 10.231.52.194 with SMTP id j2mr7097385ibg.12.1299845633945; Fri, 11 Mar 2011 04:13:53 -0800 (PST) Received: by 10.231.144.75 with HTTP; Fri, 11 Mar 2011 04:13:53 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Mar 2011 04:13:53 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] Fwd: Request for pub draft-ietf-config-signaling-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 12:12:35 -0000 ---------- Forwarded message ---------- From: Greg Shepherd Date: Fri, Mar 11, 2011 at 4:10 AM Subject: Request for pub draft-ietf-config-signaling-04 To: iesg-secretary@ietf.org, David Harrington *, The document draft-ietf-fecframe-config-signaling-04 is now ready for publication. Please see the Document Shepherd Write-up below. If this meets your approval I will send this along to the secretary and cc the WG. Thanks, Greg --- Document Shepherd Write-up for draft-ietf-config-signaling-04 as per RFC 4858, template dated September 17, 2008 (1.a) Who is the Document Shepherd for this document? Has the =A0 =A0 =A0 =A0Document Shepherd personally reviewed this version of the =A0 =A0 =A0 =A0document and, in particular, does he or she believe this =A0 =A0 =A0 =A0version is ready for forwarding to the IESG for publication? I, Greg Shepherd as the document shepherd have personally reviewed this document and believe it to be ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members =A0 =A0 =A0 =A0and from key non-WG members? Does the Document Shepherd have =A0 =A0 =A0 =A0any concerns about the depth or breadth of the reviews that =A0 =A0 =A0 =A0have been performed? The document has had adequate review both from within and from outside the FECFrame working group. (1.c) Does the Document Shepherd have concerns that the document =A0 =A0 =A0 =A0needs more review from a particular or broader perspective, =A0 =A0 =A0 =A0e.g., security, operational complexity, someone familiar wit= h =A0 =A0 =A0 =A0AAA, internationalization or XML? There are no concerns regarding the need for additional expanded review. (1.d) Does the Document Shepherd have any specific concerns or =A0 =A0 =A0 =A0issues with this document that the Responsible Area Director =A0 =A0 =A0 =A0and/or the IESG should be aware of? For example, perhaps he =A0 =A0 =A0 =A0or she is uncomfortable with certain parts of the document, = or =A0 =A0 =A0 =A0has concerns whether there really is a need for it. In any =A0 =A0 =A0 =A0event, if the WG has discussed those issues and has indicate= d =A0 =A0 =A0 =A0that it still wishes to advance the document, detail those =A0 =A0 =A0 =A0concerns here. Has an IPR disclosure related to this documen= t =A0 =A0 =A0 =A0been filed? If so, please include a reference to the =A0 =A0 =A0 =A0disclosure and summarize the WG discussion and conclusion on =A0 =A0 =A0 =A0this issue. There are no specific concerns with this document. (1.e) How solid is the WG consensus behind this document? Does it =A0 =A0 =A0 =A0represent the strong concurrence of a few individuals, with =A0 =A0 =A0 =A0others being silent, or does the WG as a whole understand an= d =A0 =A0 =A0 =A0agree with it? There is solid WG consensus for this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme =A0 =A0 =A0 =A0discontent? If so, please summarise the areas of conflict in =A0 =A0 =A0 =A0separate email messages to the Responsible Area Director. (I= t =A0 =A0 =A0 =A0should be in a separate email because this questionnaire is =A0 =A0 =A0 =A0entered into the ID Tracker.) There is no discontent. (1.g) Has the Document Shepherd personally verified that the =A0 =A0 =A0 =A0document satisfies all ID nits? (See the Internet-Drafts Che= cklist =A0 =A0 =A0 =A0and http://tools.ietf.org/tools/idnits/). Boilerplate checks= are =A0 =A0 =A0 =A0not enough; this check needs to be thorough. Has the documen= t =A0 =A0 =A0 =A0met all formal review criteria it needs to, such as the MIB =A0 =A0 =A0 =A0Doctor, media type and URI type reviews? There are no significant nits of any kind. (1.h) Has the document split its references into normative and =A0 =A0 =A0 =A0informative? Are there normative references to documents tha= t =A0 =A0 =A0 =A0are not ready for advancement or are otherwise in an unclear =A0 =A0 =A0 =A0state? If such normative references exist, what is the =A0 =A0 =A0 =A0strategy for their completion? Are there normative reference= s =A0 =A0 =A0 =A0that are downward references, as described in [RFC3967]? If =A0 =A0 =A0 =A0so, list these downward references to support the Area =A0 =A0 =A0 =A0Director in the Last Call procedure for them [RFC3967]. Normative and informative references are split with two reference to drafts that are currently in the editor's queue or will be soon. (1.i) Has the Document Shepherd verified that the document IANA =A0 =A0 =A0 =A0consideration section exists and is consistent with the body =A0 =A0 =A0 =A0of the document? If the document specifies protocol =A0 =A0 =A0 =A0extensions, are reservations requested in appropriate IANA =A0 =A0 =A0 =A0registries? Are the IANA registries clearly identified? If =A0 =A0 =A0 =A0the document creates a new registry, does it define the =A0 =A0 =A0 =A0proposed initial contents of the registry and an allocation =A0 =A0 =A0 =A0procedure for future registrations? Does it suggest a =A0 =A0 =A0 =A0reasonable name for the new registry? See [RFC5226]. If the =A0 =A0 =A0 =A0document describes an Expert Review process has Shepherd =A0 =A0 =A0 =A0conferred with the Responsible Area Director so that the IES= G =A0 =A0 =A0 =A0can appoint the needed Expert during the IESG Evaluation? Section 7 describes the IANA considerations, and is consistent with the rest of the document, referring to the details discussed in section 4.2.2 and 3.8.1. (1.j) Has the Document Shepherd verified that sections of the =A0 =A0 =A0 =A0document that are written in a formal language, such as XML =A0 =A0 =A0 =A0code, BNF rules, MIB definitions, etc., validate correctly i= n =A0 =A0 =A0 =A0an automated checker? The xml code validates correctly (1.k) The IESG approval announcement includes a Document =A0 =A0 =A0 =A0Announcement Write-Up. Please provide such a Document =A0 =A0 =A0 =A0Announcement Write-Up? Recent examples can be found in the =A0 =A0 =A0 =A0"Action" announcements for approved documents. The approval =A0 =A0 =A0 =A0announcement contains the following sections: Technical Summary =A0 =A0 =A0 =A0This document describes how to use existing signaling protoc= ols to determine and dynamically communicate the Configuration information between sender(s) and receiver(s) compliant with the FEC Framework document. Working Group Summary =A0 =A0 =A0 =A0There were no seriously contentious issues during the WG pro= cess. Document Quality =A0 =A0 =A0 =A0The Working Group feedback covered both the quality of the d= ocument itself as well as the technical issues with the content of the document. Personal =A0 =A0 =A0 =A0Document Shepherd - Greg Shepherd =A0 =A0 =A0 =A0Responsible Area Director - David Harrington From gjshep@gmail.com Fri Mar 11 04:13:13 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0FDF3A692C for ; Fri, 11 Mar 2011 04:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XY2kjHi6xFX for ; Fri, 11 Mar 2011 04:13:12 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 95CCE3A688C for ; Fri, 11 Mar 2011 04:13:12 -0800 (PST) Received: by iwl42 with SMTP id 42so3190421iwl.31 for ; Fri, 11 Mar 2011 04:14:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=RbYRhsy1R329pUqHL6XVUkI3aACr0nKUKYgNtM6dTIs=; b=O45Z27h5Z/htkYafq9VjMT/ajjimCMqQDPpfqonGiy97Cetrjjte377xtMRDAP8xAR DNcD4p4lCjNShHTzS+/RcO5Sywg9vpiqEUGp9VMe4ecckfPAEJFvc+lvSZ6eK5qJOEXR 2o2B7XSvQNjqAfCCQaE+IWdP/yqQawXche2a4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type:content-transfer-encoding; b=o8knqij/KGxdGp9VNsDD2xL/R3Ruq9sB6g8XXUWEIJYxI/EBoQp99CiE2pqyHBGvHV pkxLH4To+TMhG4nOJSzZLp+ykgukjaCLavUEiEahmYVNmV4SFzF6eoMYpEmtvLlmpPVG rnH9YQCFPUzPnEpqvvcLTaamn4reQVS4irRy8= MIME-Version: 1.0 Received: by 10.231.177.69 with SMTP id bh5mr7130036ibb.62.1299845671076; Fri, 11 Mar 2011 04:14:31 -0800 (PST) Received: by 10.231.144.75 with HTTP; Fri, 11 Mar 2011 04:14:31 -0800 (PST) In-Reply-To: References: Date: Fri, 11 Mar 2011 04:14:31 -0800 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] Fwd: request for pub draft-ietf-fecframe-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 12:13:13 -0000 ---------- Forwarded message ---------- From: Greg Shepherd Date: Fri, Mar 11, 2011 at 4:11 AM Subject: request for pub draft-ietf-fecframe-raptor-04 To: iesg-secretary@ietf.org, David Harrington *, The document draft-ietf-fecframe-raptor-04 is now ready for publication. Please see the Document Shepherd Write-up below. If this meets your approval I will send this along to the secretary and cc the WG. Thanks, Greg --- Document Shepherd Write-up for draft-ietf-raptor-04 as per RFC 4858, template dated September 17, 2008 (1.a) Who is the Document Shepherd for this document? Has the =A0 =A0 =A0 =A0Document Shepherd personally reviewed this version of the =A0 =A0 =A0 =A0document and, in particular, does he or she believe this =A0 =A0 =A0 =A0version is ready for forwarding to the IESG for publication? I, Greg Shepherd as the document shepherd have personally reviewed this document and believe it to be ready for forwarding to the IESG. (1.b) Has the document had adequate review both from key WG members =A0 =A0 =A0 =A0and from key non-WG members? Does the Document Shepherd have =A0 =A0 =A0 =A0any concerns about the depth or breadth of the reviews that =A0 =A0 =A0 =A0have been performed? The document has had adequate review both from within and from outside the FECFrame working group. (1.c) Does the Document Shepherd have concerns that the document =A0 =A0 =A0 =A0needs more review from a particular or broader perspective, =A0 =A0 =A0 =A0e.g., security, operational complexity, someone familiar wit= h =A0 =A0 =A0 =A0AAA, internationalization or XML? There are no concerns regarding the need for additional expanded review. (1.d) Does the Document Shepherd have any specific concerns or =A0 =A0 =A0 =A0issues with this document that the Responsible Area Director =A0 =A0 =A0 =A0and/or the IESG should be aware of? For example, perhaps he =A0 =A0 =A0 =A0or she is uncomfortable with certain parts of the document, = or =A0 =A0 =A0 =A0has concerns whether there really is a need for it. In any =A0 =A0 =A0 =A0event, if the WG has discussed those issues and has indicate= d =A0 =A0 =A0 =A0that it still wishes to advance the document, detail those =A0 =A0 =A0 =A0concerns here. Has an IPR disclosure related to this documen= t =A0 =A0 =A0 =A0been filed? If so, please include a reference to the =A0 =A0 =A0 =A0disclosure and summarize the WG discussion and conclusion on =A0 =A0 =A0 =A0this issue. There are no specific concerns with this document. (1.e) How solid is the WG consensus behind this document? Does it =A0 =A0 =A0 =A0represent the strong concurrence of a few individuals, with =A0 =A0 =A0 =A0others being silent, or does the WG as a whole understand an= d =A0 =A0 =A0 =A0agree with it? There is solid WG consensus for this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme =A0 =A0 =A0 =A0discontent? If so, please summarise the areas of conflict in =A0 =A0 =A0 =A0separate email messages to the Responsible Area Director. (I= t =A0 =A0 =A0 =A0should be in a separate email because this questionnaire is =A0 =A0 =A0 =A0entered into the ID Tracker.) There is no discontent. (1.g) Has the Document Shepherd personally verified that the =A0 =A0 =A0 =A0document satisfies all ID nits? (See the Internet-Drafts Che= cklist =A0 =A0 =A0 =A0and http://tools.ietf.org/tools/idnits/). Boilerplate checks= are =A0 =A0 =A0 =A0not enough; this check needs to be thorough. Has the documen= t =A0 =A0 =A0 =A0met all formal review criteria it needs to, such as the MIB =A0 =A0 =A0 =A0Doctor, media type and URI type reviews? Only three miscellaneous warnings which can be addressed with editor's note= s: =A0=3D=3D The copyright year in the IETF Trust and authors Copyright Line does not match the current year =A0=3D=3D The document seems to lack a disclaimer for pre-RFC5378 work, but was first submitted before 10 November 2008. =A0Should you add the disclaimer? (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) -- however, there's a paragraph with a matching beginning. Boilerplate error? =A0-- The document date (December 9, 2010) is 32 days in the past. =A0Is this intentional? (1.h) Has the document split its references into normative and =A0 =A0 =A0 =A0informative? Are there normative references to documents tha= t =A0 =A0 =A0 =A0are not ready for advancement or are otherwise in an unclear =A0 =A0 =A0 =A0state? If such normative references exist, what is the =A0 =A0 =A0 =A0strategy for their completion? Are there normative reference= s =A0 =A0 =A0 =A0that are downward references, as described in [RFC3967]? If =A0 =A0 =A0 =A0so, list these downward references to support the Area =A0 =A0 =A0 =A0Director in the Last Call procedure for them [RFC3967]. Normative and informative references are split with one reference to draft that is currently in the editor's queue. (1.i) Has the Document Shepherd verified that the document IANA =A0 =A0 =A0 =A0consideration section exists and is consistent with the body =A0 =A0 =A0 =A0of the document? If the document specifies protocol =A0 =A0 =A0 =A0extensions, are reservations requested in appropriate IANA =A0 =A0 =A0 =A0registries? Are the IANA registries clearly identified? If =A0 =A0 =A0 =A0the document creates a new registry, does it define the =A0 =A0 =A0 =A0proposed initial contents of the registry and an allocation =A0 =A0 =A0 =A0procedure for future registrations? Does it suggest a =A0 =A0 =A0 =A0reasonable name for the new registry? See [RFC5226]. If the =A0 =A0 =A0 =A0document describes an Expert Review process has Shepherd =A0 =A0 =A0 =A0conferred with the Responsible Area Director so that the IES= G =A0 =A0 =A0 =A0can appoint the needed Expert during the IESG Evaluation? Section 12 describes the FEC Encoding ID values for registration consistent with the document. (1.j) Has the Document Shepherd verified that sections of the =A0 =A0 =A0 =A0document that are written in a formal language, such as XML =A0 =A0 =A0 =A0code, BNF rules, MIB definitions, etc., validate correctly i= n =A0 =A0 =A0 =A0an automated checker? The xml code validates correctly (1.k) The IESG approval announcement includes a Document =A0 =A0 =A0 =A0Announcement Write-Up. Please provide such a Document =A0 =A0 =A0 =A0Announcement Write-Up? Recent examples can be found in the =A0 =A0 =A0 =A0"Action" announcements for approved documents. The approval =A0 =A0 =A0 =A0announcement contains the following sections: Technical Summary =A0 =A0 =A0 =A0This document describes Full-Specified Forward Error Correct= ion (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. Working Group Summary =A0 =A0 =A0 =A0There were no seriously contentious issues during the WG pro= cess. Document Quality =A0 =A0 =A0 =A0The Working Group feedback covered both the quality of the d= ocument itself as well as the technical issues with the content of the document. Personal =A0 =A0 =A0 =A0Document Shepherd - Greg Shepherd =A0 =A0 =A0 =A0Responsible Area Director - David Harrington From vincent.roca@inrialpes.fr Tue Mar 15 10:42:13 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410C63A6D78 for ; Tue, 15 Mar 2011 10:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.066 X-Spam-Level: X-Spam-Status: No, score=-10.066 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfJ+xlCOhk3Y for ; Tue, 15 Mar 2011 10:42:12 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id D2B6A3A6971 for ; Tue, 15 Mar 2011 10:42:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,188,1299452400"; d="scan'208,217";a="93890962" Received: from unknown (HELO macbook-de-roca.local) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Mar 2011 18:43:35 +0100 Message-ID: <4D7F6786.6090508@inrialpes.fr> Date: Tue, 15 Mar 2011 14:20:06 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "fecframe@ietf.org" Content-Type: multipart/alternative; boundary="------------020505030308030408030401" Subject: [Fecframe] Fwd: New Version Notification for draft-galanos-fecframe-rtp-reedsolomon-03 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 17:42:13 -0000 This is a multi-part message in MIME format. --------------020505030308030408030401 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello everybody, We have updated the RTP version of the Reed-Solomon FEC Scheme. Even if the group decided to make it a WG Item document, this version is still an individual I-D (because we've missed the -00 version deadline). There is still some work to do on this version. Our plan is to improve it till Prague's meeting and to resubmit a consolidated version at that time, when submission re-opens, as an -00 I-D this time. Several important changes have been done, in particular to reflect the latest discussions on the Fecframe framework I-D. I'll discuss them at Prague. Cheers, Vincent -------- Message original -------- Sujet: New Version Notification for draft-galanos-fecframe-rtp-reedsolomon-03 Date : Mon, 14 Mar 2011 15:52:55 -0700 (PDT) De : IETF I-D Submission Tool Pour : vincent.roca@inria.fr Copie à : orly.peck@kaminario.com,sarit@radvision.com A new version of I-D, draft-galanos-fecframe-rtp-reedsolomon-03.txt has been successfully submitted by Vincent Roca and posted to the IETF repository. Filename: draft-galanos-fecframe-rtp-reedsolomon Revision: 03 Title: RTP Payload Format for Reed Solomon FEC Creation_date: 2011-03-14 WG ID: Independent Submission Number_of_pages: 27 Abstract: This document defines an RTP payload format for the Reed-Solomon Forward Error Correction (FEC) codes for the erasure channel. The format defined by this document enables the protection of source media encapsulated in RTP with one or more repair flows and is based on the FEC framework and the SDP Elements for FEC Framework. The Reed-Solomon codes used in this document belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection, and they are effective in front of random or bursty packet losses. The IETF Secretariat. --------------020505030308030408030401 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello everybody,

We have updated the RTP version of the Reed-Solomon
FEC Scheme. Even if the group decided to make it a WG Item
document, this version is still an individual I-D (because we've
missed the -00 version deadline).

There is still some work to do on this version. Our plan is
to improve it till Prague's meeting and to resubmit a
consolidated version at that time, when submission re-opens,
as an -00 I-D this time.

Several important changes have been done, in particular to
reflect the latest discussions on the Fecframe framework
I-D. I'll discuss them at Prague.

Cheers,

  Vincent

-------- Message original --------
Sujet: New Version Notification for draft-galanos-fecframe-rtp-reedsolomon-03
Date : Mon, 14 Mar 2011 15:52:55 -0700 (PDT)
De : IETF I-D Submission Tool <idsubmission@ietf.org>
Pour : vincent.roca@inria.fr
Copie à : orly.peck@kaminario.com,sarit@radvision.com 


A new version of I-D, draft-galanos-fecframe-rtp-reedsolomon-03.txt has been successfully submitted by Vincent Roca and posted to the IETF repository.

Filename:	 draft-galanos-fecframe-rtp-reedsolomon
Revision:	 03
Title:		 RTP Payload Format for Reed Solomon FEC
Creation_date:	 2011-03-14
WG ID:		 Independent Submission
Number_of_pages: 27

Abstract:
This document defines an RTP payload format for the Reed-Solomon
Forward Error Correction (FEC) codes for the erasure channel.  The
format defined by this document enables the protection of source
media encapsulated in RTP with one or more repair flows and is based
on the FEC framework and the SDP Elements for FEC Framework.  The
Reed-Solomon codes used in this document belong to the class of
Maximum Distance Separable (MDS) codes which means they offer optimal
protection, and they are effective in front of random or bursty
packet losses.
                                                                                  


The IETF Secretariat.
--------------020505030308030408030401-- From vincent.roca@inrialpes.fr Tue Mar 15 10:42:14 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3920C3A6E2E for ; Tue, 15 Mar 2011 10:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.112 X-Spam-Level: X-Spam-Status: No, score=-10.112 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFwdAX34XgMS for ; Tue, 15 Mar 2011 10:42:13 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id D0A253A6B10 for ; Tue, 15 Mar 2011 10:42:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,188,1299452400"; d="scan'208";a="93890975" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-de-roca.local) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Mar 2011 18:43:37 +0100 Message-ID: <4D7F6A68.1000600@inrialpes.fr> Date: Tue, 15 Mar 2011 14:32:24 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "fecframe@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Fecframe] Call For Agenda Items X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 17:42:14 -0000 Hi Greg, > Prague is approaching so please send your agenda items in so we can > post beforehand. ** "RTP Payload Format for Reed Solomon FEC", draft-galanos-fecframe-rtp-reedsolomon (Vincent Roca, 5') Quick discussion of the changes made to this I-D and next steps. ** "Simple LDPC-Staircase FEC Scheme" and "Simple Reed-Solomon FEC Scheme" (Vincent Roca, 5') Since both I-D still await official approval using the WG Chair tools, they are not reflected in the official IETF site. You can find them below in the meantime... http://planete.inrialpes.fr/people/roca/doc/draft-ietf-fecframe-ldpc-00.txt http://planete.inrialpes.fr/people/roca/doc/draft-ietf-fecframe-simple-rs-00.txt Quick overview of the modifications done and next steps. Otherwise I imagine we'll have the opportunity to discuss the FECFRAME Framework status and remaining open points if any. Cheers, Vincent From wwwrun@core3.amsl.com Tue Mar 15 12:52:18 2011 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8E38F3A6E17; Tue, 15 Mar 2011 12:52:18 -0700 (PDT) To: abegen@cisco.com,stockhammer@nomor.de From: IETF Secretariat Message-Id: <20110315195218.8E38F3A6E17@core3.amsl.com> Date: Tue, 15 Mar 2011 12:52:18 -0700 (PDT) Cc: wes@mti-systems.com, housley@vigilsec.com, ipr-announce@ietf.org, fecframe@ietf.org Subject: [Fecframe] IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-04 (2) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:52:18 -0000 Dear Ali Begen, Thomas Stockhammer: An IPR disclosure that pertains to your Internet-Draft entitled "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection" (draft-ietf-fecframe-dvb-al-fec) was submitted to the IETF Secretariat on 2011-03-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1510/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-04 (2)." The IETF Secretariat From ietfdbh@comcast.net Tue Mar 15 18:44:34 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55A903A6B1F for ; Tue, 15 Mar 2011 18:44:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFs6Ch-+CiDt for ; Tue, 15 Mar 2011 18:44:33 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [76.96.62.40]) by core3.amsl.com (Postfix) with ESMTP id 701333A6A7E for ; Tue, 15 Mar 2011 18:44:33 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id KdC81g0041ei1Bg54dlz3X; Wed, 16 Mar 2011 01:46:00 +0000 Received: from davidPC ([67.189.235.106]) by omta24.westchester.pa.mail.comcast.net with comcast id Kdlu1g0042JQnJT3kdlu8u; Wed, 16 Mar 2011 01:45:55 +0000 From: "David Harrington" To: , Date: Tue, 15 Mar 2011 21:45:52 -0400 Message-ID: <912B18A560F14E26B575FC533FADB437@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvjSqSrHcjYrCreRFai0c4nODQ0nwAMPBfg X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Subject: [Fecframe] FW: IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 01:44:34 -0000 Hi, The request to publish (the shepherding document) must be updated to document the WG discussion of the IPR declaration. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org] Sent: Tuesday, March 15, 2011 3:52 PM To: stockhammer@nomor.de; luby@qualcomm.com; watsonm@netflix.com Cc: ietfdbh@comcast.net; lars.eggert@nokia.com; wes@mti-systems.com; fecframe@ietf.org; gjshep@gmail.com; ipr-announce@ietf.org; housley@vigilsec.com Subject: IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-04 Dear Thomas Stockhammer, Michael Luby, Mark Watson: An IPR disclosure that pertains to your Internet-Draft entitled "Raptor FEC Schemes for FECFRAME" (draft-ietf-fecframe-raptor) was submitted to the IETF Secretariat on 2011-03-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1509/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-04." The IETF Secretariat From ietfdbh@comcast.net Tue Mar 15 18:45:36 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0490C3A6BA0 for ; Tue, 15 Mar 2011 18:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOk0WFm4pSBh for ; Tue, 15 Mar 2011 18:45:35 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by core3.amsl.com (Postfix) with ESMTP id 1D63F3A6BA4 for ; Tue, 15 Mar 2011 18:45:35 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta08.westchester.pa.mail.comcast.net with comcast id Kdn11g0010bG4ec58dn1dH; Wed, 16 Mar 2011 01:47:01 +0000 Received: from davidPC ([67.189.235.106]) by omta03.westchester.pa.mail.comcast.net with comcast id Kdmy1g02D2JQnJT3Pdmzo3; Wed, 16 Mar 2011 01:47:00 +0000 From: "David Harrington" To: , Date: Tue, 15 Mar 2011 21:46:56 -0400 Message-ID: <534BBEBEC2874CBCA9E3A4A5FA63FE95@davidPC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcvjSrEwwCL47G2ATouJP+N5U+E98gAMTYmA X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Cc: tsv-ads@tools.ietf.org Subject: [Fecframe] FW: IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-04 (2) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 01:45:36 -0000 Hi, The request to publish (the shepherding document) must be updated to document the WG discussion of the IPR declaration. David Harrington Director, IETF Transport Area ietfdbh@comcast.net (preferred for ietf) dbharrington@huaweisymantec.com +1 603 828 1401 (cell) -----Original Message----- From: IETF Secretariat [mailto:ietf-ipr@ietf.org] Sent: Tuesday, March 15, 2011 3:52 PM To: abegen@cisco.com; stockhammer@nomor.de Cc: ietfdbh@comcast.net; lars.eggert@nokia.com; wes@mti-systems.com; fecframe@ietf.org; gjshep@gmail.com; ipr-announce@ietf.org; housley@vigilsec.com Subject: IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-04 (2) Dear Ali Begen, Thomas Stockhammer: An IPR disclosure that pertains to your Internet-Draft entitled "Guidelines for Implementing DVB-IPTV Application-Layer Hybrid FEC Protection" (draft-ietf-fecframe-dvb-al-fec) was submitted to the IETF Secretariat on 2011-03-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1510/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-04 (2)." The IETF Secretariat From Internet-Drafts@ietf.org Wed Mar 16 10:30:34 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A22ED3A6A07; Wed, 16 Mar 2011 10:30:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98ZRudX7fIBR; Wed, 16 Mar 2011 10:30:27 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B2D3A69E1; Wed, 16 Mar 2011 10:30:02 -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: 3.12 Message-ID: <20110316173002.15703.10357.idtracker@localhost> Date: Wed, 16 Mar 2011 10:30:02 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-simple-rs-00.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:30:34 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME Author(s) : V. Roca, et al. Filename : draft-ietf-fecframe-simple-rs-00.txt Pages : 21 Date : 2011-02-28 This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of encoding symbols, and a computational complexity higher than that of LDPC codes for instance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-simple-rs-00.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-fecframe-simple-rs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-16102740.I-D@ietf.org> --NextPart-- From gjshep@gmail.com Wed Mar 16 10:35:58 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B8383A6A07 for ; Wed, 16 Mar 2011 10:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.558 X-Spam-Level: X-Spam-Status: No, score=-103.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3j7ep14IA6Yy for ; Wed, 16 Mar 2011 10:35:57 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by core3.amsl.com (Postfix) with ESMTP id 9EAE83A69F2 for ; Wed, 16 Mar 2011 10:35:57 -0700 (PDT) Received: by iyi12 with SMTP id 12so2251842iyi.31 for ; Wed, 16 Mar 2011 10:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=TQbu8HecMGLdiwzb0kyrYAhdM6x1ywgG44lBuEtk6D8=; b=ZjOQDKpVqN3AZ8MsJ1QyzrFvJFqSt3ZzQIkQYxlGsQ38VuY7uZju+KXm4EpeHJRmFl SOAC8lKxWR3koZcv/Ww40LLIXeKrADJy5bjI3rPfPc0bTRF3vEPHBNS6e1yoWOSQsr+0 UNb0+bY3I6suBCzKpFFOZKgX99UWh8PRFPvDQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; b=sBiXOvIPDOOTvYdHbkQiryGgnnOumFZgZOZ72Nnd4gWZc1k5QT/1UEEeLIAHA9QWt3 AVBPGfbR62TUjYbcIsxcDfX879pPFG8YTTKE97NRsSTT4BIXDQRrJviiyNWK8GwlGpgM ybkO2oIOu3Qu8Uxyj+SGAO/IkrxaPuYGeoKuE= MIME-Version: 1.0 Received: by 10.231.213.93 with SMTP id gv29mr253220ibb.37.1300297043958; Wed, 16 Mar 2011 10:37:23 -0700 (PDT) Received: by 10.231.144.75 with HTTP; Wed, 16 Mar 2011 10:37:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 16 Mar 2011 10:37:23 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Fecframe] Call For Agenda Items X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 17:35:58 -0000 Agenda posted: http://www.ietf.org/proceedings/80/agenda/fecframe.html FECFrame WG Meeting Agenda IETF 80 Friday, April 1, 2011 Karlin II & III Welcome, Agenda Bash Chair 5min RTP Payload Format for Reed Solomon FEC draft-galanos-fecframe-rtp-reedsolomon Vincent Roca 5min Simple LDPC-Staircase FEC Scheme draft-roca-fecframe-ldpc-01 Vincent ROca 5min Simple Reed-Solomon FEC Scheme draft-roca-fecframe-simple-rs-01 Vincent Roca 5min Framework status update draft-ietf-fecframe-framework-14 Ali Begin 5min WG Shutdown schedule Chair 5min Please send me any updates or corrections. Thanks!, Greg On Wed, Mar 9, 2011 at 4:54 PM, Greg Shepherd wrote: > *, > > Prague is approaching so please send your agenda items in so we can > post beforehand. > > Thanks!, > Greg > From vincent.roca@inrialpes.fr Fri Mar 18 07:17:03 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F143A68B1; Fri, 18 Mar 2011 07:17:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.088 X-Spam-Level: X-Spam-Status: No, score=-10.088 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A594-rWvR8tC; Fri, 18 Mar 2011 07:17:01 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by core3.amsl.com (Postfix) with ESMTP id F330A3A691A; Fri, 18 Mar 2011 07:17:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,205,1299452400"; d="scan'208";a="78650597" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 18 Mar 2011 15:18:28 +0100 Message-ID: <4D8369B3.6020204@inrialpes.fr> Date: Fri, 18 Mar 2011 15:18:27 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: gjshep@gmail.com, "Luby, Michael" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: iesg-secretary@ietf.org, fecframe@ietf.org Subject: Re: [Fecframe] request for pub draft-ietf-rtp-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 14:17:03 -0000 Greg, Mike, everybody, We had a discussion last month on the topic: "Managing losses between the sending application and the FECFRAME instance" as part of the framework I-D (see the bottom of page 41 for the agreed text). The RTP Raptor I-D is of course concerned by this discussion and unfortunately this -04 version is from November 2010, before the discussion. Unless I missed some key sentence, I have the feeling that this I-D implicitly assumes there CANNOT be any RTP packet loss before reaching the Fecframe encoder, i.e. the RTP SN are always in sequence. (NB: the only text I've found that discusses RTP SN is in section 3 and does not mention this requirement at all) It's a critical requirement that MUST be clearly stated. If there is any risk this requirement does not hold, the I-D MUST define an appropriate behavior. So it's worth a quick fix (it's fairly easy) IMHO. Note that it might also be an attack (in specific deployment scenarios, not all of them of course), so it's also worth saying a few words in section 12 as well (BTW, we should do the same in the FEC Framework I-D, I didn't realize that before, sorry). Cheers, Vincent On 11/03/11 13:13, Greg Shepherd wrote: > *, > > The document draft-ietf-fecframe-rtp-raptor-04 is now ready for > publication. Please see the Document Shepherd Write-up below. > > Thanks, > Greg > > --- > > Document Shepherd Write-up for draft-ietf-rtp-raptor-04 as per RFC > 4858, template dated September 17, 2008 > > (1.a) Who is the Document Shepherd for this document? Has the > Document Shepherd personally reviewed this version of the > document and, in particular, does he or she believe this > version is ready for forwarding to the IESG for publication? > > I, Greg Shepherd as the document shepherd have personally reviewed > this document and believe it to be ready for forwarding to the IESG. > > (1.b) Has the document had adequate review both from key WG members > and from key non-WG members? Does the Document Shepherd have > any concerns about the depth or breadth of the reviews that > have been performed? > > The document has had adequate review both from within and from outside > the FECFrame working group. > > (1.c) Does the Document Shepherd have concerns that the document > needs more review from a particular or broader perspective, > e.g., security, operational complexity, someone familiar with > AAA, internationalization or XML? > > There are no concerns regarding the need for additional expanded review. > > (1.d) Does the Document Shepherd have any specific concerns or > issues with this document that the Responsible Area Director > and/or the IESG should be aware of? For example, perhaps he > or she is uncomfortable with certain parts of the document, or > has concerns whether there really is a need for it. In any > event, if the WG has discussed those issues and has indicated > that it still wishes to advance the document, detail those > concerns here. Has an IPR disclosure related to this document > been filed? If so, please include a reference to the > disclosure and summarize the WG discussion and conclusion on > this issue. > > There are no specific concerns with this document. > > (1.e) How solid is the WG consensus behind this document? Does it > represent the strong concurrence of a few individuals, with > others being silent, or does the WG as a whole understand and > agree with it? > > There is solid WG consensus for this document. > > (1.f) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in > separate email messages to the Responsible Area Director. (It > should be in a separate email because this questionnaire is > entered into the ID Tracker.) > > There is no discontent. > > (1.g) Has the Document Shepherd personally verified that the > document satisfies all ID nits? (See the Internet-Drafts Checklist > and http://tools.ietf.org/tools/idnits/). Boilerplate checks are > not enough; this check needs to be thorough. Has the document > met all formal review criteria it needs to, such as the MIB > Doctor, media type and URI type reviews? > > Only two miscellaneous warnings and one outdated reference which can > be addressed with editor's notes: > > == The copyright year in the IETF Trust and authors Copyright Line does not > match the current year > > -- The document date (November 25, 2010) is 46 days in the past. Is this > intentional? > > == Outdated reference: A later version (-04) exists of > draft-ietf-fecframe-raptor-02 > > (1.h) Has the document split its references into normative and > informative? Are there normative references to documents that > are not ready for advancement or are otherwise in an unclear > state? If such normative references exist, what is the > strategy for their completion? Are there normative references > that are downward references, as described in [RFC3967]? If > so, list these downward references to support the Area > Director in the Last Call procedure for them [RFC3967]. > > Normative and informative references are split with two reference to > drafts that are currently in the editor's queue or will be soon. > > (1.i) Has the Document Shepherd verified that the document IANA > consideration section exists and is consistent with the body > of the document? If the document specifies protocol > extensions, are reservations requested in appropriate IANA > registries? Are the IANA registries clearly identified? If > the document creates a new registry, does it define the > proposed initial contents of the registry and an allocation > procedure for future registrations? Does it suggest a > reasonable name for the new registry? See [RFC5226]. If the > document describes an Expert Review process has Shepherd > conferred with the Responsible Area Director so that the IESG > can appoint the needed Expert during the IESG Evaluation? > > Section 12 describes the IANA considerations, which refers to Section > 5 for a comprehensive registration description. The document itself is > primarily a document of media registrations/definitions. > > (1.j) Has the Document Shepherd verified that sections of the > document that are written in a formal language, such as XML > code, BNF rules, MIB definitions, etc., validate correctly in > an automated checker? > > The xml code validates correctly > > (1.k) The IESG approval announcement includes a Document > Announcement Write-Up. Please provide such a Document > Announcement Write-Up? Recent examples can be found in the > "Action" announcements for approved documents. The approval > announcement contains the following sections: > > Technical Summary > This document specifies an RTP payload format for Forward Error > Correction / (FEC) repair data produced by the Raptor FEC schemes. > Raptor FEC schemes are specified for use with the IETF FEC Framework > which supports transport of repair data over both UDP and RTP. This > document specifies the payload format which is required for the use of > RTP to carry Raptor repair flows. > > Working Group Summary > There were no seriously contentious issues during the WG process. > > Document Quality > The Working Group feedback covered both the quality of the document > itself as well as the technical issues with the content of the > document. > > Personal > Document Shepherd - Greg Shepherd > Responsible Area Director - David Harrington > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Mon Mar 21 15:39:42 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C50F73A68FB; Mon, 21 Mar 2011 15:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAWyO7qyhhyy; Mon, 21 Mar 2011 15:39:34 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id F256528C0FA; Mon, 21 Mar 2011 15:39:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1300747267; x=1332283267; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20Greg=20Shep herd=20|CC:=20"iesg-secretary@ietf.org" =20,=20David=20Harrington=0D=0A =09,=20"fecframe@ietf.org"=20|Date:=20Mon,=2021=20Mar=202011=2015:40:59=20 -0700|Subject:=20Re:=20[Fecframe]=20request=20for=20pub =20draft-ietf-rtp-raptor-04|Thread-Topic:=20[Fecframe]=20 request=20for=20pub=20draft-ietf-rtp-raptor-04 |Thread-Index:=20Acvld11BCeVTxsAlQOWEIpdOxLOHawCoa8mC |Message-ID:=20 |In-Reply-To:=20<4D8369B3.6020204@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=A3lZ4DI9Mpy63UX1YE6vPZvvml9xbPksEa1q49bpdHA=; b=YbdPGix4yQY4umqp7msIl45pVpgruPRCNPBZjuXclxBpTMXuhI/si5+g AV+cC9o927H7JvvBGcb9cDz2ZvcLJ2xd69jJbCqI0A+sNuqMPmIOnr8EU etrd8XC/+C5NOWL7Lck4IKnm63c+o4HziVT9gz+2UwC9NqbOE7GBKDbUg Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6292"; a="81053532" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by wolverine02.qualcomm.com with ESMTP; 21 Mar 2011 15:41:06 -0700 X-IronPort-AV: E=Sophos;i="4.63,219,1299484800"; d="scan'208";a="60607502" Received: from nasanexhub01.na.qualcomm.com ([10.46.93.121]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-MD5; 21 Mar 2011 15:41:05 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub01.na.qualcomm.com (10.46.93.121) with Microsoft SMTP Server (TLS) id 8.3.83.0; Mon, 21 Mar 2011 15:41:05 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Mon, 21 Mar 2011 15:40:46 -0700 From: "Luby, Michael" To: Vincent Roca , Greg Shepherd Date: Mon, 21 Mar 2011 15:40:59 -0700 Thread-Topic: [Fecframe] request for pub draft-ietf-rtp-raptor-04 Thread-Index: Acvld11BCeVTxsAlQOWEIpdOxLOHawCoa8mC Message-ID: In-Reply-To: <4D8369B3.6020204@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg-secretary@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] request for pub draft-ietf-rtp-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 22:39:42 -0000 Hi Vincent, Some comments inline. Best, Mike On 3/18/11 7:18 AM, "Vincent Roca" wrote: > Greg, Mike, everybody, >=20 > We had a discussion last month on the topic: > "Managing losses between the sending application > and the FECFRAME instance" > as part of the framework I-D (see the bottom of page 41 for > the agreed text). >=20 > The RTP Raptor I-D is of course concerned by this discussion > and unfortunately this -04 version is from November 2010, > before the discussion. >=20 > Unless I missed some key sentence, I have the feeling that this > I-D implicitly assumes there CANNOT be any RTP packet loss > before reaching the Fecframe encoder, i.e. the RTP SN are always > in sequence. *** Yes, makes sense. >=20 > (NB: the only text I've found that discusses RTP SN is in > section 3 and does not mention this requirement at all) >=20 > It's a critical requirement that MUST be clearly stated. If there is > any risk this requirement does not hold, the I-D MUST define an > appropriate behavior. So it's worth a quick fix (it's fairly easy) IMHO. > Note that it might also be an attack (in specific deployment > scenarios, not all of them of course), so it's also worth saying a > few words in section 12 as well (BTW, we should do the same in > the FEC Framework I-D, I didn't realize that before, sorry). *** There seems to be a couple of ways to solve this. One, as you suggest, is to mandate that the solution must have all source packets arrive at the FEC encoder. Another way is to have logic at the FEC encoder that detects if there are missing packets (easy to do in this case because of the RTP sequence numbers), and if so, for FEC encoding purposes (not transmission purposes), creates a dummy packet of all zeroes for each missing sequence number (or whatever the receiver is going to interpret as a valid packet bu= t with no real audio/video info inside), and encode the source block includin= g the dummy packet(s). Probably best to point out the problem and then mention some possible ways to solve it. *** It should be noted that in any system where not all the source packets containing video/audio data get to the FEC encoder is pretty badly designed= , as no matter how you overcome it, you are still going to be missing video/audio at all the clients that receive the stream. At least if you have RTP sequence numbers in the source packets you will know this at the FEC encoder (may not be true of other solutions, i.e., it may even be hard to detect that not all the video/audio source packets get to the FEC encoder, and this probably should be pointed out for other solutions). =20 >=20 > Cheers, >=20 > Vincent >=20 > On 11/03/11 13:13, Greg Shepherd wrote: >> *, >>=20 >> The document draft-ietf-fecframe-rtp-raptor-04 is now ready for >> publication. Please see the Document Shepherd Write-up below. >>=20 >> Thanks, >> Greg >>=20 >> --- >>=20 >> Document Shepherd Write-up for draft-ietf-rtp-raptor-04 as per RFC >> 4858, template dated September 17, 2008 >>=20 >> (1.a) Who is the Document Shepherd for this document? Has the >> Document Shepherd personally reviewed this version of the >> document and, in particular, does he or she believe this >> version is ready for forwarding to the IESG for publication? >>=20 >> I, Greg Shepherd as the document shepherd have personally reviewed >> this document and believe it to be ready for forwarding to the IESG. >>=20 >> (1.b) Has the document had adequate review both from key WG members >> and from key non-WG members? Does the Document Shepherd have >> any concerns about the depth or breadth of the reviews that >> have been performed? >>=20 >> The document has had adequate review both from within and from outside >> the FECFrame working group. >>=20 >> (1.c) Does the Document Shepherd have concerns that the document >> needs more review from a particular or broader perspective, >> e.g., security, operational complexity, someone familiar with >> AAA, internationalization or XML? >>=20 >> There are no concerns regarding the need for additional expanded review. >>=20 >> (1.d) Does the Document Shepherd have any specific concerns or >> issues with this document that the Responsible Area Director >> and/or the IESG should be aware of? For example, perhaps he >> or she is uncomfortable with certain parts of the document, or >> has concerns whether there really is a need for it. In any >> event, if the WG has discussed those issues and has indicated >> that it still wishes to advance the document, detail those >> concerns here. Has an IPR disclosure related to this document >> been filed? If so, please include a reference to the >> disclosure and summarize the WG discussion and conclusion on >> this issue. >>=20 >> There are no specific concerns with this document. >>=20 >> (1.e) How solid is the WG consensus behind this document? Does it >> represent the strong concurrence of a few individuals, with >> others being silent, or does the WG as a whole understand and >> agree with it? >>=20 >> There is solid WG consensus for this document. >>=20 >> (1.f) Has anyone threatened an appeal or otherwise indicated extreme >> discontent? If so, please summarise the areas of conflict in >> separate email messages to the Responsible Area Director. (It >> should be in a separate email because this questionnaire is >> entered into the ID Tracker.) >>=20 >> There is no discontent. >>=20 >> (1.g) Has the Document Shepherd personally verified that the >> document satisfies all ID nits? (See the Internet-Drafts Checkl= ist >> and http://tools.ietf.org/tools/idnits/). Boilerplate checks ar= e >> not enough; this check needs to be thorough. Has the document >> met all formal review criteria it needs to, such as the MIB >> Doctor, media type and URI type reviews? >>=20 >> Only two miscellaneous warnings and one outdated reference which can >> be addressed with editor's notes: >>=20 >> =3D=3D The copyright year in the IETF Trust and authors Copyright Lin= e does >> not >> match the current year >>=20 >> -- The document date (November 25, 2010) is 46 days in the past. Is = this >> intentional? >>=20 >> =3D=3D Outdated reference: A later version (-04) exists of >> draft-ietf-fecframe-raptor-02 >>=20 >> (1.h) Has the document split its references into normative and >> informative? Are there normative references to documents that >> are not ready for advancement or are otherwise in an unclear >> state? If such normative references exist, what is the >> strategy for their completion? Are there normative references >> that are downward references, as described in [RFC3967]? If >> so, list these downward references to support the Area >> Director in the Last Call procedure for them [RFC3967]. >>=20 >> Normative and informative references are split with two reference to >> drafts that are currently in the editor's queue or will be soon. >>=20 >> (1.i) Has the Document Shepherd verified that the document IANA >> consideration section exists and is consistent with the body >> of the document? If the document specifies protocol >> extensions, are reservations requested in appropriate IANA >> registries? Are the IANA registries clearly identified? If >> the document creates a new registry, does it define the >> proposed initial contents of the registry and an allocation >> procedure for future registrations? Does it suggest a >> reasonable name for the new registry? See [RFC5226]. If the >> document describes an Expert Review process has Shepherd >> conferred with the Responsible Area Director so that the IESG >> can appoint the needed Expert during the IESG Evaluation? >>=20 >> Section 12 describes the IANA considerations, which refers to Section >> 5 for a comprehensive registration description. The document itself is >> primarily a document of media registrations/definitions. >>=20 >> (1.j) Has the Document Shepherd verified that sections of the >> document that are written in a formal language, such as XML >> code, BNF rules, MIB definitions, etc., validate correctly in >> an automated checker? >>=20 >> The xml code validates correctly >>=20 >> (1.k) The IESG approval announcement includes a Document >> Announcement Write-Up. Please provide such a Document >> Announcement Write-Up? Recent examples can be found in the >> "Action" announcements for approved documents. The approval >> announcement contains the following sections: >>=20 >> Technical Summary >> This document specifies an RTP payload format for Forward Error >> Correction / (FEC) repair data produced by the Raptor FEC schemes. >> Raptor FEC schemes are specified for use with the IETF FEC Framework >> which supports transport of repair data over both UDP and RTP. This >> document specifies the payload format which is required for the use of >> RTP to carry Raptor repair flows. >>=20 >> Working Group Summary >> There were no seriously contentious issues during the WG process. >>=20 >> Document Quality >> The Working Group feedback covered both the quality of the document >> itself as well as the technical issues with the content of the >> document. >>=20 >> Personal >> Document Shepherd - Greg Shepherd >> Responsible Area Director - David Harrington >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe From wwwrun@core3.amsl.com Tue Mar 15 12:51:56 2011 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5D4283A6E68; Tue, 15 Mar 2011 12:51:55 -0700 (PDT) To: stockhammer@nomor.de,luby@qualcomm.com,watsonm@netflix.com From: IETF Secretariat Message-Id: <20110315195156.5D4283A6E68@core3.amsl.com> Date: Tue, 15 Mar 2011 12:51:56 -0700 (PDT) X-Mailman-Approved-At: Tue, 22 Mar 2011 08:15:15 -0700 Cc: wes@mti-systems.com, housley@vigilsec.com, ipr-announce@ietf.org, fecframe@ietf.org Subject: [Fecframe] IPR Disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Mar 2011 19:51:56 -0000 Dear Thomas Stockhammer, Michael Luby, Mark Watson: An IPR disclosure that pertains to your Internet-Draft entitled "Raptor FEC Schemes for FECFRAME" (draft-ietf-fecframe-raptor) was submitted to the IETF Secretariat on 2011-03-08 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1509/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-04." The IETF Secretariat From vincent.roca@inrialpes.fr Wed Mar 23 01:43:04 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E4B53A6774; Wed, 23 Mar 2011 01:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.82 X-Spam-Level: X-Spam-Status: No, score=-9.82 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r2wSRFY7tD-p; Wed, 23 Mar 2011 01:42:59 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by core3.amsl.com (Postfix) with ESMTP id ECF7E3A6452; Wed, 23 Mar 2011 01:42:58 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,230,1299452400"; d="scan'208";a="94671703" Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 23 Mar 2011 09:44:31 +0100 Message-ID: <4D89B2EF.8020603@inrialpes.fr> Date: Wed, 23 Mar 2011 09:44:31 +0100 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "iesg-secretary@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] request for pub draft-ietf-rtp-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 08:43:04 -0000 Hello Mike, > *** There seems to be a couple of ways to solve this. One, as you suggest, > is to mandate that the solution must have all source packets arrive at the > FEC encoder. Another way is to have logic at the FEC encoder that detects > if there are missing packets (easy to do in this case because of the RTP > sequence numbers), and if so, for FEC encoding purposes (not transmission > purposes), creates a dummy packet of all zeroes for each missing sequence > number (or whatever the receiver is going to interpret as a valid packet but > with no real audio/video info inside), and encode the source block including > the dummy packet(s). Probably best to point out the problem and then > mention some possible ways to solve it. I agree, let's point the issue first and then suggest a few ways to fix or mitigate it. Which solution to prefer depends on the use-case. This is already discussed in version -14 of the framework I-D (section 10.2): --- In this case, another solution SHOULD be considered that is use-case specific and whose consequences need to be carefully considered (e.g., by duplicating the last ADU received before the loss, or by inserting a zero'ed ADU, depending on the ADU flow nature). --- However inserting a dummy source packet and not sending it means it will be considered as erased at the FECFRAME decoding, which impacts the recovery capabilities of the FEC scheme. And we have no way to signal to the receiver this is a dummy source packet. So there are two good reasons such erasures do not happen too often: 1) because a missing audio/video source packet impacts the perceived quality, 2) because it also impacts the FEC protection of source packets that are considered by the FECFRAME encoder. An alternative is of course to send such dummy source packets of signal them to the receiver (not feasible with current specs). > *** It should be noted that in any system where not all the source packets > containing video/audio data get to the FEC encoder is pretty badly designed, > as no matter how you overcome it, you are still going to be missing > video/audio at all the clients that receive the stream. At least if you > have RTP sequence numbers in the source packets you will know this at the > FEC encoder (may not be true of other solutions, i.e., it may even be hard > to detect that not all the video/audio source packets get to the FEC > encoder, and this probably should be pointed out for other solutions). Good point. However I guess there are other means to identify missing ADUs within the upper application, even if it's not visible at FECFRAME level. Cheers, Vincent From luby@qualcomm.com Wed Mar 23 10:56:04 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83DFA3A693F; Wed, 23 Mar 2011 10:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.299 X-Spam-Level: X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XN5XS3+6JP-0; Wed, 23 Mar 2011 10:56:03 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1FFC93A693C; Wed, 23 Mar 2011 10:56:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=luby@qualcomm.com; q=dns/txt; s=qcdkim; t=1300903057; x=1332439057; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:in-reply-to:accept-language:content-language: x-ms-has-attach:x-ms-tnef-correlator:user-agent: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20|CC:=20Greg=20S hepherd=20,=20"iesg-secretary@ietf.org" =0D=0A=09,=20David=20Harrington =20,=0D=0A=09"fecframe@ietf.org"=20< fecframe@ietf.org>|Date:=20Wed,=2023=20Mar=202011=2010:57 :28=20-0700|Subject:=20Re:=20[Fecframe]=20request=20for =20pub=20draft-ietf-rtp-raptor-04|Thread-Topic:=20[Fecfra me]=20request=20for=20pub=20draft-ietf-rtp-raptor-04 |Thread-Index:=20AcvpNooXss4inijsSRK0/eNTkErU+gATTvJv |Message-ID:=20 |In-Reply-To:=20<4D89B2EF.8020603@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|user-agent:=20Mic rosoft-Entourage/13.8.0.101117|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=IE+pGN73KtUe69/1tAXGwsDqnAKXm+wz20VTfWhQiDo=; b=zHpwvXzlKiY821WYDHHZLN3XjMFhZ9LjHMCOMoCHGMSSWFDuj1BiAiMA UytktkJKoOUfypvA9D06qrX3UxWIxqC7vT03VM4sGJyPKXW31Dz+6rJfu mrwWHw/Wryc+q5yTFEhE3b6lpMeUnVtav5UhuzhqLN5lGW78RjMyAxm90 o=; X-IronPort-AV: E=McAfee;i="5400,1158,6294"; a="81434900" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by wolverine02.qualcomm.com with ESMTP; 23 Mar 2011 10:57:37 -0700 X-IronPort-AV: E=Sophos;i="4.63,231,1299484800"; d="scan'208";a="22550543" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/AES128-SHA; 23 Mar 2011 10:57:37 -0700 Received: from nasclexhc01.na.qualcomm.com (172.30.48.1) by nasanexhc04.na.qualcomm.com (172.30.48.17) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 23 Mar 2011 10:57:36 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.113]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Wed, 23 Mar 2011 10:57:31 -0700 From: "Luby, Michael" To: Vincent Roca Date: Wed, 23 Mar 2011 10:57:28 -0700 Thread-Topic: [Fecframe] request for pub draft-ietf-rtp-raptor-04 Thread-Index: AcvpNooXss4inijsSRK0/eNTkErU+gATTvJv Message-ID: In-Reply-To: <4D89B2EF.8020603@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.8.0.101117 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "iesg-secretary@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] request for pub draft-ietf-rtp-raptor-04 X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 17:56:04 -0000 Comments below. Cheers, Mike On 3/23/11 1:44 AM, "Vincent Roca" wrote: > Hello Mike, >=20 >> *** There seems to be a couple of ways to solve this. One, as you sugge= st, >> is to mandate that the solution must have all source packets arrive at t= he >> FEC encoder. Another way is to have logic at the FEC encoder that detec= ts >> if there are missing packets (easy to do in this case because of the RTP >> sequence numbers), and if so, for FEC encoding purposes (not transmissio= n >> purposes), creates a dummy packet of all zeroes for each missing sequenc= e >> number (or whatever the receiver is going to interpret as a valid packet= but >> with no real audio/video info inside), and encode the source block inclu= ding >> the dummy packet(s). Probably best to point out the problem and then >> mention some possible ways to solve it. >=20 > I agree, let's point the issue first and then suggest a few ways to fix > or mitigate it. Which solution to prefer depends on the use-case. > This is already discussed in version -14 of the framework I-D > (section 10.2): > --- > In this case, > another solution SHOULD be considered that is use-case specific > and whose consequences need to be carefully considered (e.g., by > duplicating the last ADU received before the loss, or by inserting > a zero'ed ADU, depending on the ADU flow nature). > --- >=20 > However inserting a dummy source packet and not sending it > means it will be considered as erased at the FECFRAME decoding, > which impacts the recovery capabilities of the FEC scheme. > And we have no way to signal to the receiver this is a dummy > source packet. >=20 > So there are two good reasons such erasures do not happen > too often: > 1) because a missing audio/video source packet impacts the > perceived quality, > 2) because it also impacts the FEC protection of source packets > that are considered by the FECFRAME encoder. >=20 > An alternative is of course to send such dummy source packets > of signal them to the receiver (not feasible with current specs). *** There is no benefit of sending the dummy source packets that I can see, as they don't contain any information that can help the receiver. The rest seems ok. >=20 >=20 >> *** It should be noted that in any system where not all the source packe= ts >> containing video/audio data get to the FEC encoder is pretty badly desig= ned, >> as no matter how you overcome it, you are still going to be missing >> video/audio at all the clients that receive the stream. At least if you >> have RTP sequence numbers in the source packets you will know this at th= e >> FEC encoder (may not be true of other solutions, i.e., it may even be ha= rd >> to detect that not all the video/audio source packets get to the FEC >> encoder, and this probably should be pointed out for other solutions). > Good point. However I guess there are other means to identify > missing ADUs within the upper application, even if it's not > visible at FECFRAME level. *** Not always true. For example, using MPEG2-TS format (pretty typical for broadcasters where this technology might be deployed) doesn't have any real easy to extract a unique packet identifier at the FEC sender to verify that there isn't any packet loss, and thus at the very least there would have to be a pretty deep packet inspection at the FEC sender to determine i= f there are missing source packets. >=20 > Cheers, >=20 > Vincent From gjshep@gmail.com Wed Mar 23 11:28:23 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5819C28C10B for ; Wed, 23 Mar 2011 11:28:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.562 X-Spam-Level: X-Spam-Status: No, score=-103.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdc-doqLOHuz for ; Wed, 23 Mar 2011 11:28:22 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 576DE28C116 for ; Wed, 23 Mar 2011 11:28:22 -0700 (PDT) Received: by qyk29 with SMTP id 29so4335289qyk.10 for ; Wed, 23 Mar 2011 11:29:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:date:message-id:subject :from:to:content-type:content-transfer-encoding; bh=quLuMAXQFSZPSSOalgY/QDNWbhf1pVJt04tAWdXp8EE=; b=Q2UDNGXei/o6hklU6V1N3xO0jj670tYxZ2poyDDL+ezwK00rE/VZiYCPEguyktmCgF qTMEeIEymw23JdlFujFSx0EyXvK8VXCKE1l0w6tjqyoSKQVFWdYHQboN3cIFHQhhUe9b wcp3CbtLzL+rb+P+D3oVGSYwI8i+vNg2rAzMg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:date:message-id:subject:from:to:content-type :content-transfer-encoding; b=fa5hhbctTPRbSxH9ESBgStht5nkGnN7abVJnUWljmJnll8TWsqk1Qe6QKYxYC2N0wB JBhhpwP/ejXnzmFMvnaHZAeoFXJnVe2kfekbI6lc4b6Nag3bDpAAIymuTs5g1/c5I4Nm SD7AnqBjty8pvjA93Yh69IAwfVt1cyVMDWXqM= MIME-Version: 1.0 Received: by 10.224.197.3 with SMTP id ei3mr5996061qab.387.1300904996191; Wed, 23 Mar 2011 11:29:56 -0700 (PDT) Received: by 10.229.9.206 with HTTP; Wed, 23 Mar 2011 11:29:56 -0700 (PDT) Date: Wed, 23 Mar 2011 11:29:56 -0700 Message-ID: From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Fecframe] FECFrame Presos for Prague X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: gjshep@gmail.com List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 18:28:23 -0000 Please send your presentations to me as soon as you can so we can get them posted before the WG meeting. Thanks!, Greg On Wed, Mar 16, 2011 at 10:37 AM, Greg Shepherd wrote: > Agenda posted: > > http://www.ietf.org/proceedings/80/agenda/fecframe.html > > FECFrame WG Meeting Agenda > IETF 80 > Friday, April 1, 2011 > > Karlin II & III > > Welcome, Agenda Bash > Chair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5min > > RTP Payload Format for Reed Solomon FEC > draft-galanos-fecframe-rtp-reedsolomon > Vincent Roca =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A05min > > Simple LDPC-Staircase FEC Scheme > draft-roca-fecframe-ldpc-01 > Vincent ROca =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A05min > > Simple Reed-Solomon FEC Scheme > draft-roca-fecframe-simple-rs-01 > Vincent Roca =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A05min > > Framework status update > draft-ietf-fecframe-framework-14 > Ali Begin =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5min > > WG Shutdown schedule > Chair =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 5min > > > Please send me any updates or corrections. > > Thanks!, > Greg > > On Wed, Mar 9, 2011 at 4:54 PM, Greg Shepherd wrote: >> *, >> >> Prague is approaching so please send your agenda items in so we can >> post beforehand. >> >> Thanks!, >> Greg >> > From vincent.roca@inrialpes.fr Wed Mar 30 12:28:47 2011 Return-Path: X-Original-To: fecframe@core3.amsl.com Delivered-To: fecframe@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65B983A6BB3; Wed, 30 Mar 2011 12:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.248 X-Spam-Level: X-Spam-Status: No, score=-10.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMbsE66Hk5Wi; Wed, 30 Mar 2011 12:28:46 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by core3.amsl.com (Postfix) with ESMTP id AE2BD3A67ED; Wed, 30 Mar 2011 12:28:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.63,269,1299452400"; d="scan'208,217";a="104079867" Received: from 78-80-198-253.tmcz.cz (HELO macbook-de-roca.local) ([78.80.198.253]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 30 Mar 2011 21:30:21 +0200 Message-ID: <4D9384CD.3010702@inrialpes.fr> Date: Wed, 30 Mar 2011 21:30:21 +0200 From: Vincent Roca User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: David Harrington References: <20110315213931.22139.58807.idtracker@localhost> In-Reply-To: <20110315213931.22139.58807.idtracker@localhost> Content-Type: multipart/alternative; boundary="------------060400000904040508090001" Cc: fecframe-chairs@tools.ietf.org, "fecframe@ietf.org" , The IESG , draft-ietf-fecframe-framework@tools.ietf.org Subject: Re: [Fecframe] David Harrington's Discuss on draft-ietf-fecframe-framework-14: (with DISCUSS) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 19:28:47 -0000 This is a multi-part message in MIME format. --------------060400000904040508090001 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit David, Please find below our proposal in order to try to address your two comments. Thanks. Cheers, Vincent and Ali --- 9.6. Baseline Secure FEC Framework Operation This section describes a baseline mode of secure FEC Framework operation based on the application of the IPsec security protocol, which is one possible solution to solve or mitigate the security threats introduced by the use of the FEC Framework. ** All the FEC Framework implementations MUST implement this baseline secure mode of operation, even if it is not mandatory to use it. ** Two related documents are of interest. [...] 10. Operations and Management Considerations [...] 10.1. What are the Key Aspects to Consider? Several aspects need to be considered since they will directly impact the way the FEC Framework and the associated FEC schemes can be operated and managed. This section lists them as follows: [...] * * o Interoperability Considerations: generally speaking, it is highly desirable that devices coming from different vendors, possibly designed for different use-cases, interoperate. However the FEC Framework has been designed in such a way to accommodate a large variety of situations. Many options are left open in the current document and can only be clarified in the context of a given use-case. * * 10.2. Operational and Management Recommendations [...] * * o Interoperability Considerations: in the general case, it is difficult to provide clear recommendations on how to achieve interoperability by mandating the use of certain protocols, tools or configurations, since such considerations are usually use-case dependent. However the following is representative of the way the FEC Framework MAY be used over the Internet: - use RTP/RTCP over FEC Framework over UDP; - use either point to point or point-to-multipoint, bidirectional communications; In order to increase the probability that devices coming from different vendors interoperate, the following is RECOMMENDED: - if there is a risk a client does not support the FEC Framework or the sender's FEC scheme(s), then it is RECOMMENDED to use RTP framing of FEC repair packets, with different RTP Payload Type (PT) values. - if there is a risk a client does not support the grouping semantics [RFC 5956], then it is RECOMMENDED not to use it (otherwise this client would not understand the bindings). - it is RECOMMENDED that the clients and server support regular RTCP reports. ** --- On 15/03/11 22:39, David Harrington wrote: > David Harrington has entered the following ballot position for > draft-ietf-fecframe-framework-14: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > updated for -14- > > The new revision has added significantly improved operations and management considerations and security consdierations. > I think the text is still lacking a bit, and the fix should be fairly easy. > > 1) In the operations and management consideration section, it says: > In particular, this section discusses the questions of > interoperability across vendors/use cases and whether defining > mandatory to implement (but not mandatory to use) solutions is > beneficial. > > The section however fails to discuss interoperability across vendors at all (teh term interoperability is only in the above text). > A paragraph should be added explaining how interoperability of management across vendors will be achieved, at least when the framework is used in the Internet.. > > 2) The Security Considerations says: > The goals of this section are to state the > problem, discuss the risks and identify solutions when feasible. It > also defines a mandatory to implement (but not mandatory to use) > security scheme. > IPsec appears to be the baseline security, but the language surrounding IPsec is not specified in RFC2119 langauge that would make this mandatory to implement. Please specify the mandatory to implement security scheme in RFC2119 REQUIRED/MUST language. > > > > > > > > > --------------060400000904040508090001 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit David,

Please find below our proposal in order to try to address
your two comments. Thanks.

Cheers,

   Vincent and Ali

---

9.6.  Baseline Secure FEC Framework Operation

   This section describes a baseline mode of secure FEC Framework
   operation based on the application of the IPsec security protocol,
   which is one possible solution to solve or mitigate the security
   threats introduced by the use of the FEC Framework.
<new text>
   All the FEC Framework implementations MUST implement this baseline
   secure mode of operation, even if it is not mandatory to use it.
<end new text>

   Two related documents are of interest.
[...]


10.  Operations and Management Considerations

[...]

10.1.  What are the Key Aspects to Consider?

   Several aspects need to be considered since they will directly impact
   the way the FEC Framework and the associated FEC schemes can be
   operated and managed.

   This section lists them as follows:
[...]

<new text>
   o Interoperability Considerations: generally speaking, it is highly
     desirable that devices coming from different vendors, possibly
     designed for different use-cases, interoperate. However the FEC
     Framework has been designed in such a way to accommodate a large
     variety of situations. Many options are left open in the current
     document and can only be clarified in the context of a given
     use-case.
<end new text>

10.2.  Operational and Management Recommendations

[...]

<new text>
    o Interoperability Considerations: in the general case, it is
      difficult to provide clear recommendations on how to achieve
      interoperability by mandating the use of certain protocols, tools
      or configurations, since such considerations are usually use-case
      dependent. However the following is representative of the way the
      FEC Framework MAY be used over the Internet:
        - use RTP/RTCP over FEC Framework over UDP;
        - use either point to point or point-to-multipoint, bidirectional
          communications;
      In order to increase the probability that devices coming from
      different vendors interoperate, the following is RECOMMENDED:
        - if there is a risk a client does not support the FEC Framework
          or the sender's FEC scheme(s), then it is RECOMMENDED to use RTP
          framing of FEC repair packets, with different RTP Payload Type
          (PT) values.
        - if there is a risk a client does not support the grouping semantics
          [RFC 5956], then it is RECOMMENDED not to use it (otherwise this
          client would not understand the bindings).
        - it is RECOMMENDED that the clients and server support regular RTCP
          reports.
<end new text>
---

On 15/03/11 22:39, David Harrington wrote: 
David Harrington has entered the following ballot position for
draft-ietf-fecframe-framework-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

updated for -14-

The new revision has added significantly improved operations and management considerations and security consdierations.
I think the text is still lacking a bit, and the fix should be fairly easy.

1) In the operations and management consideration section, it says:
   In particular, this section discusses the questions of
   interoperability across vendors/use cases and whether defining
   mandatory to implement (but not mandatory to use) solutions is
   beneficial.

The section however fails to discuss interoperability across vendors at all (teh term interoperability is only in the above text).
A paragraph should be added explaining how interoperability of management across vendors will be achieved, at least when the framework is used in the Internet..

2) The Security Considerations says:
   The goals of this section are to state the
   problem, discuss the risks and identify solutions when feasible.  It
   also defines a mandatory to implement (but not mandatory to use)
   security scheme.
IPsec appears to be the baseline security, but the language surrounding IPsec is not specified in RFC2119 langauge that would make this mandatory to implement. Please specify the mandatory to implement security scheme in RFC2119 REQUIRED/MUST language.
--------------060400000904040508090001--