From internet-drafts@ietf.org Wed Oct 3 06:56:03 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE7421F8652; Wed, 3 Oct 2012 06:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8-DyLPyHwdC; Wed, 3 Oct 2012 06:56:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B8B21F84F6; Wed, 3 Oct 2012 06:56:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121003135603.15635.45313.idtracker@ietfa.amsl.com> Date: Wed, 03 Oct 2012 06:56:03 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-simple-rs-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 13:56:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Simple Reed-Solomon Forward Error Correction (FEC) Schem= e for FECFRAME Author(s) : Vincent Roca Mathieu Cunche Jerome Lacan Amine Bouabdallah Kazuhisa Matsuzono Filename : draft-ietf-fecframe-simple-rs-04.txt Pages : 21 Date : 2012-10-03 Abstract: This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 <=3D m <=3D 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-fecframe-simple-rs-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-simple-rs-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Thu Oct 4 02:39:00 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3BE821F869F; Thu, 4 Oct 2012 02:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxAXgqgS3itu; Thu, 4 Oct 2012 02:39:00 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB5221F8692; Thu, 4 Oct 2012 02:39:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121004093900.19956.22357.idtracker@ietfa.amsl.com> Date: Thu, 04 Oct 2012 02:39:00 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-03.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 09:39:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Simple LDPC-Staircase Forward Error Correction (FEC) Sch= eme for FECFRAME Author(s) : Vincent Roca Mathieu Cunche Jerome Lacan Filename : draft-ietf-fecframe-ldpc-03.txt Pages : 20 Date : 2012-10-04 Abstract: This document describes a fully-specified simple FEC scheme for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow, or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-ldpc-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon Oct 8 07:11:29 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E743D21F87C5; Mon, 8 Oct 2012 07:11:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfVJtuK9oVS2; Mon, 8 Oct 2012 07:11:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 561CF21F87C0; Mon, 8 Oct 2012 07:11:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121008141129.10923.33854.idtracker@ietfa.amsl.com> Date: Mon, 08 Oct 2012 07:11:29 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] Last Call: (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 14:11:30 -0000 The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-10-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract 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. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/ No IPR declarations have been submitted directly on this I-D. From internet-drafts@ietf.org Tue Oct 9 06:22:07 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D343111E80EA; Tue, 9 Oct 2012 06:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgFNdLN0-84A; Tue, 9 Oct 2012 06:22:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9FB221F88A7; Tue, 9 Oct 2012 06:22:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121009132206.25631.82737.idtracker@ietfa.amsl.com> Date: Tue, 09 Oct 2012 06:22:06 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Oct 2012 13:22:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Simple LDPC-Staircase Forward Error Correction (FEC) Sch= eme for FECFRAME Author(s) : Vincent Roca Mathieu Cunche Jerome Lacan Filename : draft-ietf-fecframe-ldpc-04.txt Pages : 22 Date : 2012-10-09 Abstract: This document describes a fully-specified simple FEC scheme for LDPC- Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. These codes have many interesting properties: they are systematic codes, they perform close to ideal codes in many use-cases and they also feature very high encoding and decoding throughputs. LDPC-Staircase codes are therefore a good solution to protect a single high bitrate source flow, or to protect globally several mid-rate flows within a single FECFRAME instance. They are also a good solution whenever the processing load of a software encoder or decoder must be kept to a minimum. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-ldpc-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From luby@qti.qualcomm.com Thu Oct 11 11:24:02 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0191F21F85AE; Thu, 11 Oct 2012 11:24:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.554 X-Spam-Level: X-Spam-Status: No, score=-106.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mN7eBX3rGU0Q; Thu, 11 Oct 2012 11:24:01 -0700 (PDT) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by ietfa.amsl.com (Postfix) with ESMTP id C6DC021F854C; Thu, 11 Oct 2012 11:23:59 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6862"; a="246552256" Received: from ironmsg02-l.qualcomm.com ([172.30.48.16]) by wolverine02.qualcomm.com with ESMTP; 11 Oct 2012 11:23:36 -0700 X-IronPort-AV: E=Sophos;i="4.80,573,1344236400"; d="scan'208";a="124881201" Received: from nasanexhc13.na.qualcomm.com ([172.30.48.20]) by ironmsg02-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 11 Oct 2012 11:23:36 -0700 Received: from NASANEXD02C.na.qualcomm.com ([169.254.6.73]) by nasanexhc13.na.qualcomm.com ([172.30.48.20]) with mapi id 14.02.0318.001; Thu, 11 Oct 2012 11:23:34 -0700 From: "Luby, Michael" To: "internet-drafts@ietf.org" , "i-d-announce@ietf.org" Thread-Topic: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt Thread-Index: AQHNpiEgQHxRRh+VfUSBSAt8xaBu5Je0bsiA Date: Thu, 11 Oct 2012 18:23:34 +0000 Message-ID: In-Reply-To: <20121009132206.25631.82737.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.45.230.6] Content-Type: text/plain; charset="us-ascii" Content-ID: <288A87A830FF6D4DB268920B3FBC3001@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Oct 2012 18:24:02 -0000 Some quick comments. (1) This proposal relies upon parts of RFC 5170 for the definition of the underlying LDPC staircase code. However, it isn't completely explicit in this proposal about what exact parts/sections of RFC 5170 are to be used in this proposal and how. It would seem that explicit references to the particular sections of RFC 5170 that are being used, and exactly how these parts of RFC 5170 are being inherited and used, would be useful (probably necessary). Note that there are several codes with different FEC encoding IDs defined in RFC 5170, so making exact references to which parts are used=20 and how is important. An example of how this is not at all precisely defined:=20 Because of the requirement to have exactly one encoding symbol per group, i.e., because G MUST be equal to 1 (Section 4.1 ), several parts of [RFC5170 ] are useless. In particular, this is the case of Section 5.6=20 . "Identifying the G Symbols of an Encoding Symbol Group". =20 This snippet above that says several parts of RFC 5170 are useless (very vague), and it seems instead it should explicitly state what parts are to be used and exactly how. It provides one example of something that is not is to be used from RFC 5170, but it seems that it should be the other way around, stating explicitly what should be used and how. (2) This proposal references RFC 5170 and RFC 5053, and makes some comparisons. However, there is also RFC 6330 that is relevant and is not mentioned or referenced in this proposal. It would seem appropriate to do so. Thanks, Mike On 10/9/12 6:22 AM, "internet-drafts@ietf.org" wrote: > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the FEC Framework Working Group of the IETF. > > Title : Simple LDPC-Staircase Forward Error Correction (FEC) >Scheme for FECFRAME > Author(s) : Vincent Roca > Mathieu Cunche > Jerome Lacan > Filename : draft-ietf-fecframe-ldpc-04.txt > Pages : 22 > Date : 2012-10-09 > >Abstract: > This document describes a fully-specified simple FEC scheme for LDPC- > Staircase codes that can be used to protect media streams along the > lines defined by the FECFRAME framework. These codes have many > interesting properties: they are systematic codes, they perform close > to ideal codes in many use-cases and they also feature very high > encoding and decoding throughputs. LDPC-Staircase codes are > therefore a good solution to protect a single high bitrate source > flow, or to protect globally several mid-rate flows within a single > FECFRAME instance. They are also a good solution whenever the > processing load of a software encoder or decoder must be kept to a > minimum. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-ldpc-04 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Fecframe mailing list >Fecframe@ietf.org >https://www.ietf.org/mailman/listinfo/fecframe From internet-drafts@ietf.org Tue Oct 16 23:50:19 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A817C21F87B3; Tue, 16 Oct 2012 23:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa7+hFPAYKEL; Tue, 16 Oct 2012 23:50:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B8821F8516; Tue, 16 Oct 2012 23:50:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017065019.32007.62120.idtracker@ietfa.amsl.com> Date: Tue, 16 Oct 2012 23:50:19 -0700 Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action: draft-ietf-fecframe-pseudo-cdp-05.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 06:50:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the FEC Framework Working Group of the IETF. Title : Pseudo Content Delivery Protocol (CDP) for Protecting Mu= ltiple Source Flows in FEC Framework Author(s) : Ulas C. Kozat Ali Begen Filename : draft-ietf-fecframe-pseudo-cdp-05.txt Pages : 13 Date : 2012-10-16 Abstract: This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol, but to show how the defined framework and SDP elements can be combined together to implement a CDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-fecframe-pseudo-cdp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-fecframe-pseudo-cdp-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-pseudo-cdp-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Martin.Stiemerling@neclab.eu Wed Oct 17 02:14:07 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23A2C21F8622 for ; Wed, 17 Oct 2012 02:14:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.016 X-Spam-Level: X-Spam-Status: No, score=-103.016 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROfni8Opt-fE for ; Wed, 17 Oct 2012 02:14:06 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3521F861F for ; Wed, 17 Oct 2012 02:14:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 70835102200; Wed, 17 Oct 2012 11:14:05 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBlU7tV4cGO5; Wed, 17 Oct 2012 11:14:05 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 56E631021DB; Wed, 17 Oct 2012 11:13:55 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 11:13:55 +0200 Message-ID: <507E76D3.9060001@neclab.eu> Date: Wed, 17 Oct 2012 11:13:55 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 MIME-Version: 1.0 To: "Luby, Michael" , "fecframe@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.1.1.190] Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 09:14:07 -0000 Hi Michael, all, Thanks for your comments, but I would have wished to see them either during the WG Last Call or latest during IETF LC. Anyhow, apart from the timing, the questions are probably good to be discussed. Especially, as there are IPR declarations for RFC 5170. Any feedback from the WG? Thanks, Martin -- IETF Transport Area Director martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 On 10/11/2012 08:23 PM, Luby, Michael wrote: > Some quick comments. > > (1) This proposal relies upon parts of RFC 5170 for the definition of the > underlying LDPC staircase code. However, it isn't completely explicit in > this proposal about what exact parts/sections of RFC 5170 are to be used > in this proposal and how. It would seem that explicit references to the > particular sections of RFC 5170 that are being used, and exactly how these > parts of RFC 5170 are being inherited and used, would be useful (probably > necessary). Note that there are several codes with different FEC encoding > IDs defined in RFC 5170, so making exact references to which parts are > used > and how is important. An example of how this is not at all precisely > defined: > > Because of the requirement to have exactly one encoding symbol per > group, i.e., because G MUST be equal to 1 (Section 4.1 > ), > several > parts of [RFC5170 ] are useless. In > particular, this is the case of > Section 5.6 > . > "Identifying the G Symbols of an Encoding Symbol > Group". > > This snippet above that says several parts of RFC 5170 are useless (very > vague), and it seems instead it should explicitly state what > parts are to be used and exactly how. It provides one example of > something that is not is to be used from RFC 5170, but it seems that > it should be the other way around, stating explicitly what should be used > and how. > > > (2) This proposal references RFC 5170 and RFC 5053, and makes some > comparisons. However, there is also RFC 6330 that is relevant and is not > mentioned or referenced in this proposal. It would seem appropriate to do > so. > > Thanks, Mike > > > > On 10/9/12 6:22 AM, "internet-drafts@ietf.org" > wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the FEC Framework Working Group of the IETF. >> >> Title : Simple LDPC-Staircase Forward Error Correction (FEC) >> Scheme for FECFRAME >> Author(s) : Vincent Roca >> Mathieu Cunche >> Jerome Lacan >> Filename : draft-ietf-fecframe-ldpc-04.txt >> Pages : 22 >> Date : 2012-10-09 >> >> Abstract: >> This document describes a fully-specified simple FEC scheme for LDPC- >> Staircase codes that can be used to protect media streams along the >> lines defined by the FECFRAME framework. These codes have many >> interesting properties: they are systematic codes, they perform close >> to ideal codes in many use-cases and they also feature very high >> encoding and decoding throughputs. LDPC-Staircase codes are >> therefore a good solution to protect a single high bitrate source >> flow, or to protect globally several mid-rate flows within a single >> FECFRAME instance. They are also a good solution whenever the >> processing load of a software encoder or decoder must be kept to a >> minimum. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-fecframe-ldpc-04 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe > From vincent.roca@inria.fr Wed Oct 17 04:59:36 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2222521F8789 for ; Wed, 17 Oct 2012 04:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.405 X-Spam-Level: X-Spam-Status: No, score=-110.405 tagged_above=-999 required=5 tests=[AWL=-0.156, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scF+W+3U8cQt for ; Wed, 17 Oct 2012 04:59:35 -0700 (PDT) Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by ietfa.amsl.com (Postfix) with ESMTP id 3DAA121F8786 for ; Wed, 17 Oct 2012 04:59:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,600,1344204000"; d="scan'208";a="177612031" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 17 Oct 2012 13:59:33 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: <507E76D3.9060001@neclab.eu> Date: Wed, 17 Oct 2012 13:59:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <507E76D3.9060001@neclab.eu> To: "Luby, Michael" X-Mailer: Apple Mail (2.1085) Cc: Mathieu Cunche , =?iso-8859-1?Q?J=E9r=F4me_Lacan?= , fecframe@ietf.org, Stephen Farrell Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 11:59:36 -0000 Mike, Thanks for your feedback. >> (1) This proposal relies upon parts of RFC 5170 for the definition of = the >> underlying LDPC staircase code. However, it isn't completely = explicit in >> this proposal about what exact parts/sections of RFC 5170 are to be = used >> in this proposal and how. It would seem that explicit references to = the >> particular sections of RFC 5170 that are being used, and exactly how = these >> parts of RFC 5170 are being inherited and used, would be useful = (probably >> necessary). Note that there are several codes with different FEC = encoding >> IDs defined in RFC 5170, so making exact references to which parts = are >> used >> and how is important. An example of how this is not at all precisely >> defined: >>=20 >> Because of the requirement to have exactly one encoding symbol = per >> group, i.e., because G MUST be equal to 1 (Section 4.1 >> = ), >> several >> parts of [RFC5170 ] are = useless. In >> particular, this is the case of >> Section 5.6 >> . >> "Identifying the G Symbols of an Encoding Symbol >> Group". >>=20 >> This snippet above that says several parts of RFC 5170 are useless = (very >> vague), and it seems instead it should explicitly state what >> parts are to be used and exactly how. It provides one example of >> something that is not is to be used from RFC 5170, but it seems that >> it should be the other way around, stating explicitly what should be = used >> and how. I have no doubt that an implementer will find its way in RFC5170 and = identify what needs to be used. With the further restriction of having G=3D1, the specifications of RFC5170 become fairly small (~14 technical pages, = pseudo-code included) and easy to understand IMHO. We are not planning to change anything here unless the IESG asks us to = do so. >> (2) This proposal references RFC 5170 and RFC 5053, and makes some >> comparisons. However, there is also RFC 6330 that is relevant and is = not >> mentioned or referenced in this proposal. It would seem appropriate = to do >> so. This list is not intended to be exhaustive. No other FEC scheme tries to = provide an exhaustive list: RFC5053 (Raptor) does not reference any other FEC = scheme, and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference Raptor. More importantly. Since: 1- you noticed we impose restrictions on the way LDPC-Staircase codes = are being used in section 4.1; 2- you certainly remember the discussion we had in 2009 concerning 10 = out of the 13 patents mentioned in the RFC5170 IPR disclosure, whose = conclusion is here: http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html 3- the present I-D only considers LDPC-Staircase codes whereas RFC5170 defines two FEC schemes; you will probably conclude like us that QC's IPR disclosure for RFC5170 = does not necessarily apply to this I-D. Hence our question: does QC intend to = do a new IPR disclosure? When? Regards, Vincent, on behalf of the authors NB: I'm adding Stephen Farrell who first identified the IPR disclosure = question during IESG review. From luby@qti.qualcomm.com Wed Oct 17 06:24:16 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7E0821F85ED for ; Wed, 17 Oct 2012 06:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.563 X-Spam-Level: X-Spam-Status: No, score=-104.563 tagged_above=-999 required=5 tests=[AWL=-1.964, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLnmylQHthVM for ; Wed, 17 Oct 2012 06:24:15 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0F83F21F8625 for ; Wed, 17 Oct 2012 06:24:09 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6867"; a="381415" Received: from ironmsg01-lv.qualcomm.com ([10.47.202.180]) by sabertooth01.qualcomm.com with ESMTP; 17 Oct 2012 06:10:52 -0700 X-IronPort-AV: E=Sophos;i="4.80,600,1344236400"; d="scan'208";a="449913" Received: from nasanexhc03.na.qualcomm.com ([172.30.48.26]) by ironmsg01-lv.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2012 06:24:08 -0700 Received: from NASANEXD02C.na.qualcomm.com ([169.254.6.25]) by NASANEXHC03.na.qualcomm.com ([172.30.48.26]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 06:24:08 -0700 From: "Luby, Michael" To: Martin Stiemerling , "Luby, Michael" , "fecframe@ietf.org" Thread-Topic: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt Thread-Index: AQHNpiEgQHxRRh+VfUSBSAt8xaBu5Je0bsiAgAlJxYD//9CMgA== Date: Wed, 17 Oct 2012 13:24:07 +0000 Message-ID: In-Reply-To: <507E76D3.9060001@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [199.106.115.132] Content-Type: text/plain; charset="us-ascii" Content-ID: <7ECA0CB96FBEE64FB75AC0A01240D68A@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:24:16 -0000 Hi Martin, Comments below. Best, Mike On 10/17/12 2:13 AM, "Martin Stiemerling" wrote: >Hi Michael, all, > >Thanks for your comments, but I would have wished to see them either >during the WG Last Call or latest during IETF LC. *** My comments aren't crucial, and it seems they are going to be ignored anyway. I wish I had time to look at it earlier, but I didn't. They are clarifying comments, and if they aren't incorporated it only means that the spec is a little less easy to understand, it isn't earth shattering. > >Anyhow, apart from the timing, the questions are probably good to be >discussed. Especially, as there are IPR declarations for RFC 5170. *** I don't understand this comment, as there were no IPR-related comments in my feedback. > >Any feedback from the WG? > >Thanks, > > Martin > >--=20 >IETF Transport Area Director > >martin.stiemerling@neclab.eu > >NEC Laboratories Europe - Network Research Division NEC Europe Limited >Registered Office: NEC House, 1 Victoria Road, London W3 6BL >Registered in England 283 > > >On 10/11/2012 08:23 PM, Luby, Michael wrote: >> Some quick comments. >> >> (1) This proposal relies upon parts of RFC 5170 for the definition of >>the >> underlying LDPC staircase code. However, it isn't completely explicit >>in >> this proposal about what exact parts/sections of RFC 5170 are to be used >> in this proposal and how. It would seem that explicit references to the >> particular sections of RFC 5170 that are being used, and exactly how >>these >> parts of RFC 5170 are being inherited and used, would be useful >>(probably >> necessary). Note that there are several codes with different FEC >>encoding >> IDs defined in RFC 5170, so making exact references to which parts are >> used >> and how is important. An example of how this is not at all precisely >> defined: >> >> Because of the requirement to have exactly one encoding symbol per >> group, i.e., because G MUST be equal to 1 (Section 4.1 >> ), >> several >> parts of [RFC5170 ] are useless. >>In >> particular, this is the case of >> Section 5.6 >> . >> "Identifying the G Symbols of an Encoding Symbol >> Group". >> >> This snippet above that says several parts of RFC 5170 are useless (very >> vague), and it seems instead it should explicitly state what >> parts are to be used and exactly how. It provides one example of >> something that is not is to be used from RFC 5170, but it seems that >> it should be the other way around, stating explicitly what should be >>used >> and how. >> >> >> (2) This proposal references RFC 5170 and RFC 5053, and makes some >> comparisons. However, there is also RFC 6330 that is relevant and is >>not >> mentioned or referenced in this proposal. It would seem appropriate to >>do >> so. >> >> Thanks, Mike >> >> >> >> On 10/9/12 6:22 AM, "internet-drafts@ietf.org" >> >> wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the FEC Framework Working Group of the >>>IETF. >>> >>> Title : Simple LDPC-Staircase Forward Error Correction (FEC) >>> Scheme for FECFRAME >>> Author(s) : Vincent Roca >>> Mathieu Cunche >>> Jerome Lacan >>> Filename : draft-ietf-fecframe-ldpc-04.txt >>> Pages : 22 >>> Date : 2012-10-09 >>> >>> Abstract: >>> This document describes a fully-specified simple FEC scheme for >>>LDPC- >>> Staircase codes that can be used to protect media streams along the >>> lines defined by the FECFRAME framework. These codes have many >>> interesting properties: they are systematic codes, they perform >>>close >>> to ideal codes in many use-cases and they also feature very high >>> encoding and decoding throughputs. LDPC-Staircase codes are >>> therefore a good solution to protect a single high bitrate source >>> flow, or to protect globally several mid-rate flows within a single >>> FECFRAME instance. They are also a good solution whenever the >>> processing load of a software encoder or decoder must be kept to a >>> minimum. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-fecframe-ldpc-04 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >> > From luby@qti.qualcomm.com Wed Oct 17 06:42:06 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB54C21F8617 for ; Wed, 17 Oct 2012 06:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.236 X-Spam-Level: X-Spam-Status: No, score=-104.236 tagged_above=-999 required=5 tests=[AWL=-1.636, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8k4CgUey1yG1 for ; Wed, 17 Oct 2012 06:42:06 -0700 (PDT) Received: from sabertooth02.qualcomm.com (sabertooth02.qualcomm.com [65.197.215.38]) by ietfa.amsl.com (Postfix) with ESMTP id F3F6621F853B for ; Wed, 17 Oct 2012 06:42:05 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6867"; a="378077" Received: from ironmsg04-r.qualcomm.com ([172.30.46.18]) by sabertooth02.qualcomm.com with ESMTP; 17 Oct 2012 06:20:48 -0700 X-IronPort-AV: E=Sophos;i="4.80,600,1344236400"; d="scan'208";a="408590129" Received: from nasanexhc04.na.qualcomm.com ([172.30.48.17]) by Ironmsg04-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2012 06:42:01 -0700 Received: from NASANEXD02C.na.qualcomm.com ([169.254.6.25]) by nasanexhc04.na.qualcomm.com ([172.30.48.17]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 06:42:00 -0700 From: "Luby, Michael" To: Vincent Roca , "Luby, Michael" Thread-Topic: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt Thread-Index: AQHNpiEgQHxRRh+VfUSBSAt8xaBu5Je0bsiAgAlJxYCAAC5EgP//p0cA Date: Wed, 17 Oct 2012 13:41:59 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [199.106.115.132] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mathieu Cunche , =?iso-8859-1?Q?J=E9r=F4me_Lacan?= , "fecframe@ietf.org" , Stephen Farrell Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:42:07 -0000 Vincent, You are welcome. Responses below. Best, Mike On 10/17/12 4:59 AM, "Vincent Roca" wrote: >Mike, > >Thanks for your feedback. > >>> (1) This proposal relies upon parts of RFC 5170 for the definition of >>>the >>> underlying LDPC staircase code. However, it isn't completely explicit >>>in >>> this proposal about what exact parts/sections of RFC 5170 are to be >>>used >>> in this proposal and how. It would seem that explicit references to >>>the >>> particular sections of RFC 5170 that are being used, and exactly how >>>these >>> parts of RFC 5170 are being inherited and used, would be useful >>>(probably >>> necessary). Note that there are several codes with different FEC >>>encoding >>> IDs defined in RFC 5170, so making exact references to which parts are >>> used >>> and how is important. An example of how this is not at all precisely >>> defined: >>>=20 >>> Because of the requirement to have exactly one encoding symbol per >>> group, i.e., because G MUST be equal to 1 (Section 4.1 >>> ), >>> several >>> parts of [RFC5170 ] are useless. >>>In >>> particular, this is the case of >>> Section 5.6 >>> . >>> "Identifying the G Symbols of an Encoding Symbol >>> Group". >>>=20 >>> This snippet above that says several parts of RFC 5170 are useless >>>(very >>> vague), and it seems instead it should explicitly state what >>> parts are to be used and exactly how. It provides one example of >>> something that is not is to be used from RFC 5170, but it seems that >>> it should be the other way around, stating explicitly what should be >>>used >>> and how. > >I have no doubt that an implementer will find its way in RFC5170 and >identify >what needs to be used. With the further restriction of having G=3D1, the >specifications of RFC5170 become fairly small (~14 technical pages, >pseudo-code >included) and easy to understand IMHO. > >We are not planning to change anything here unless the IESG asks us to do >so. *** The above suggestions I made are clarifying comments, and if they aren't incorporated it only means that the spec is a little less easy to understand and implement, it isn't earth shattering. > > >>> (2) This proposal references RFC 5170 and RFC 5053, and makes some >>> comparisons. However, there is also RFC 6330 that is relevant and is >>>not >>> mentioned or referenced in this proposal. It would seem appropriate >>>to do >>> so. > >This list is not intended to be exhaustive. No other FEC scheme tries to >provide >an exhaustive list: RFC5053 (Raptor) does not reference any other FEC >scheme, >and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference >Raptor. *** Ok. However, the difference is that RFC 5053 and RFC 6330 and RFC 6681 don't have any survey like comparisons to other FEC technology (except that of course the 6330 does have text to justify its existence vis a vis 5053), whereas this specification does seems to try and make some comparisons to other technologies out there. Its ok as is, just means it isn't quite as good of a comparison list as it could have been given that a comparison survey is included at all. The other option of course would have been not to have such comparisons to other FEC within the document at all, which is the path that 5053 and 6330 take. > > >More importantly. Since: > >1- you noticed we impose restrictions on the way LDPC-Staircase codes are > being used in section 4.1; > >2- you certainly remember the discussion we had in 2009 concerning 10 out > of the 13 patents mentioned in the RFC5170 IPR disclosure, whose >conclusion > is here: > http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html > >3- the present I-D only considers LDPC-Staircase codes whereas RFC5170 > defines two FEC schemes; > >you will probably conclude like us that QC's IPR disclosure for RFC5170 >does >not necessarily apply to this I-D. Hence our question: does QC intend to >do >a new IPR disclosure? When? *** This specification inherits technology from RFC 5170, and we have made IPR declarations with regards to RFC 5170. As far as I know, we do not plan to make any further IPR declarations on this specification. > > >Regards, > > > Vincent, on behalf of the authors > > >NB: I'm adding Stephen Farrell who first identified the IPR disclosure >question >during IESG review. > From iesg-secretary@ietf.org Wed Oct 17 06:58:23 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8985521F8794; Wed, 17 Oct 2012 06:58:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.527 X-Spam-Level: X-Spam-Status: No, score=-102.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLmApVO2zbLt; Wed, 17 Oct 2012 06:58:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9D6021F8796; Wed, 17 Oct 2012 06:58:22 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121017135822.16789.93717.idtracker@ietfa.amsl.com> Date: Wed, 17 Oct 2012 06:58:22 -0700 Cc: fecframe chair , fecframe mailing list , RFC Editor Subject: [Fecframe] Document Action: 'Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework' to Informational RFC (draft-ietf-fecframe-pseudo-cdp-05.txt) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 13:58:23 -0000 The IESG has approved the following document: - 'Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework' (draft-ietf-fecframe-pseudo-cdp-05.txt) as Informational RFC This document is the product of the FEC Framework Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-fecframe-pseudo-cdp/ Technical Summary This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework (RFC6363) and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. Working Group Summary There is consensus within the FECFrame WG to publish this document. The document has been actively discussed on the wg list and in wg meetings. There was no controversy with the progression of this document. Document Quality It has undergone thorough review within the AVT and FEC communities. The document has been actively discussed on the WG mailing list and in WG meetings. No Implementations available. Personnel Greg Shepherd is the document shepherd and Martin Stiemerling is the responsible Area Director. From vincent.roca@inria.fr Wed Oct 17 07:13:41 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8F521F84D9 for ; Wed, 17 Oct 2012 07:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.379 X-Spam-Level: X-Spam-Status: No, score=-110.379 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-NMdW-7n+vg for ; Wed, 17 Oct 2012 07:13:39 -0700 (PDT) Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by ietfa.amsl.com (Postfix) with ESMTP id AD58821F84B8 for ; Wed, 17 Oct 2012 07:13:38 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.80,600,1344204000"; d="scan'208";a="159365003" Received: from geve.inrialpes.fr ([194.199.24.116]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 17 Oct 2012 16:13:37 +0200 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Vincent Roca In-Reply-To: Date: Wed, 17 Oct 2012 16:13:37 +0200 Content-Transfer-Encoding: 7bit Message-Id: <6B7DE333-64BD-445F-ADC7-38226E270142@inria.fr> References: To: "Luby, Michael" X-Mailer: Apple Mail (2.1085) Cc: Mathieu Cunche , =?iso-8859-1?Q?J=E9r=F4me_Lacan?= , "fecframe@ietf.org" , Stephen Farrell Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 14:13:41 -0000 Mike, >> More importantly. Since: >> >> 1- you noticed we impose restrictions on the way LDPC-Staircase codes are >> being used in section 4.1; >> >> 2- you certainly remember the discussion we had in 2009 concerning 10 out >> of the 13 patents mentioned in the RFC5170 IPR disclosure, whose >> conclusion >> is here: >> http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html >> >> 3- the present I-D only considers LDPC-Staircase codes whereas RFC5170 >> defines two FEC schemes; >> >> you will probably conclude like us that QC's IPR disclosure for RFC5170 >> does >> not necessarily apply to this I-D. Hence our question: does QC intend to >> do >> a new IPR disclosure? When? > > *** This specification inherits technology from RFC 5170, and we have made > IPR declarations with regards to RFC 5170. As far as I know, we do not > plan to make any further IPR declarations on this specification. IPR disclosure transitivity is only possible if the conditions of use are exactly the same as that of the initial document. This is not the case since we restrict to cases where G==1 and only focus on LDPC- Staircase codes, and you recognized it. Additionally you acknowledged in Oct. 2009 that using G>1 was the only reason that motivated 10 patents of this IPR disclosure. See: http://www.ietf.org/mail-archive/web/rmt/current/msg01358.html So we have good reasons to believe that an IPR disclosure specific to this I-D could differ from that of RFC5170. Do you agree or not? I'd like to understand your point. Cheers, Vincent From Martin.Stiemerling@neclab.eu Wed Oct 17 08:02:38 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E329821F872A for ; Wed, 17 Oct 2012 08:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.06 X-Spam-Level: X-Spam-Status: No, score=-103.06 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8B2nIxcMAzG for ; Wed, 17 Oct 2012 08:02:32 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id AE2E821F86CF for ; Wed, 17 Oct 2012 08:02:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 1D00610221B; Wed, 17 Oct 2012 17:02:31 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sY-LcsYhE68V; Wed, 17 Oct 2012 17:02:31 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id EC6791021EC; Wed, 17 Oct 2012 17:02:20 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 17:02:20 +0200 Message-ID: <507EC87C.9020209@neclab.eu> Date: Wed, 17 Oct 2012 17:02:20 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 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 X-Originating-IP: [10.1.1.190] Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:02:39 -0000 Hi Michael, On 10/17/2012 03:24 PM, Luby, Michael wrote: > Hi Martin, > Comments below. > Best, Mike > > On 10/17/12 2:13 AM, "Martin Stiemerling" > wrote: > >> Hi Michael, all, >> >> Thanks for your comments, but I would have wished to see them either >> during the WG Last Call or latest during IETF LC. > *** My comments aren't crucial, and it seems they are going to be ignored > anyway. I wish I had time to look at it earlier, but I didn't. They are > clarifying comments, and if they aren't incorporated it only means that > the spec is a little less easy to understand, it isn't earth shattering. Ok, thanks. >> >> Anyhow, apart from the timing, the questions are probably good to be >> discussed. Especially, as there are IPR declarations for RFC 5170. > *** I don't understand this comment, as there were no IPR-related comments > in my feedback. This is solely meant for discussion and to get any questions resolved. We have had some discussion during the IESG evaluation if IPR declared for RFC 5170 is also valid for draft-ietf-fecframe-ldpc. Thus the linkage between your email and what has happened in the IESG. This is not out of a bad intention, but it is more your AD which wanted some more clarity on this. Thank you, Martin >> >> Any feedback from the WG? >> >> Thanks, >> >> Martin >> >> -- >> IETF Transport Area Director >> >> martin.stiemerling@neclab.eu >> >> NEC Laboratories Europe - Network Research Division NEC Europe Limited >> Registered Office: NEC House, 1 Victoria Road, London W3 6BL >> Registered in England 283 >> >> >> On 10/11/2012 08:23 PM, Luby, Michael wrote: >>> Some quick comments. >>> >>> (1) This proposal relies upon parts of RFC 5170 for the definition of >>> the >>> underlying LDPC staircase code. However, it isn't completely explicit >>> in >>> this proposal about what exact parts/sections of RFC 5170 are to be used >>> in this proposal and how. It would seem that explicit references to the >>> particular sections of RFC 5170 that are being used, and exactly how >>> these >>> parts of RFC 5170 are being inherited and used, would be useful >>> (probably >>> necessary). Note that there are several codes with different FEC >>> encoding >>> IDs defined in RFC 5170, so making exact references to which parts are >>> used >>> and how is important. An example of how this is not at all precisely >>> defined: >>> >>> Because of the requirement to have exactly one encoding symbol per >>> group, i.e., because G MUST be equal to 1 (Section 4.1 >>> ), >>> several >>> parts of [RFC5170 ] are useless. >>> In >>> particular, this is the case of >>> Section 5.6 >>> . >>> "Identifying the G Symbols of an Encoding Symbol >>> Group". >>> >>> This snippet above that says several parts of RFC 5170 are useless (very >>> vague), and it seems instead it should explicitly state what >>> parts are to be used and exactly how. It provides one example of >>> something that is not is to be used from RFC 5170, but it seems that >>> it should be the other way around, stating explicitly what should be >>> used >>> and how. >>> >>> >>> (2) This proposal references RFC 5170 and RFC 5053, and makes some >>> comparisons. However, there is also RFC 6330 that is relevant and is >>> not >>> mentioned or referenced in this proposal. It would seem appropriate to >>> do >>> so. >>> >>> Thanks, Mike >>> >>> >>> >>> On 10/9/12 6:22 AM, "internet-drafts@ietf.org" >>> >>> wrote: >>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>> directories. >>>> This draft is a work item of the FEC Framework Working Group of the >>>> IETF. >>>> >>>> Title : Simple LDPC-Staircase Forward Error Correction (FEC) >>>> Scheme for FECFRAME >>>> Author(s) : Vincent Roca >>>> Mathieu Cunche >>>> Jerome Lacan >>>> Filename : draft-ietf-fecframe-ldpc-04.txt >>>> Pages : 22 >>>> Date : 2012-10-09 >>>> >>>> Abstract: >>>> This document describes a fully-specified simple FEC scheme for >>>> LDPC- >>>> Staircase codes that can be used to protect media streams along the >>>> lines defined by the FECFRAME framework. These codes have many >>>> interesting properties: they are systematic codes, they perform >>>> close >>>> to ideal codes in many use-cases and they also feature very high >>>> encoding and decoding throughputs. LDPC-Staircase codes are >>>> therefore a good solution to protect a single high bitrate source >>>> flow, or to protect globally several mid-rate flows within a single >>>> FECFRAME instance. They are also a good solution whenever the >>>> processing load of a software encoder or decoder must be kept to a >>>> minimum. >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc >>>> >>>> There's also a htmlized version available at: >>>> http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04 >>>> >>>> A diff from the previous version is available at: >>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-fecframe-ldpc-04 >>>> >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> Fecframe mailing list >>>> Fecframe@ietf.org >>>> https://www.ietf.org/mailman/listinfo/fecframe >>> >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>> >> > -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From Martin.Stiemerling@neclab.eu Wed Oct 17 08:12:58 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C4921F85EF for ; Wed, 17 Oct 2012 08:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.065 X-Spam-Level: X-Spam-Status: No, score=-103.065 tagged_above=-999 required=5 tests=[AWL=0.534, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qeJl+xiEyowJ for ; Wed, 17 Oct 2012 08:12:58 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id E972821F85C4 for ; Wed, 17 Oct 2012 08:12:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 620FD10221B; Wed, 17 Oct 2012 17:12:56 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avCeMdPtWEur; Wed, 17 Oct 2012 17:12:56 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 46E9D1021EC; Wed, 17 Oct 2012 17:12:26 +0200 (CEST) Received: from [10.1.1.190] (10.1.1.190) by skoll.office.hd (192.168.125.11) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 17 Oct 2012 17:12:26 +0200 Message-ID: <507ECADA.5010809@neclab.eu> Date: Wed, 17 Oct 2012 17:12:26 +0200 From: Martin Stiemerling User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 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 X-Originating-IP: [10.1.1.190] Cc: =?ISO-8859-1?Q?J=E9r=F4me_?= =?ISO-8859-1?Q?Lacan?= , Mathieu Cunche , "fecframe@ietf.org" , Stephen Farrell Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:12:58 -0000 Hi Michael and Vincent, all, On 10/17/2012 03:41 PM, Luby, Michael wrote: > Vincent, You are welcome. Responses below. Best, Mike > > On 10/17/12 4:59 AM, "Vincent Roca" wrote: > >> Mike, >> >> Thanks for your feedback. [...] >> >> >> More importantly. Since: >> >> 1- you noticed we impose restrictions on the way LDPC-Staircase >> codes are being used in section 4.1; >> >> 2- you certainly remember the discussion we had in 2009 concerning >> 10 out of the 13 patents mentioned in the RFC5170 IPR disclosure, >> whose conclusion is here: >> http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html >> >> 3- the present I-D only considers LDPC-Staircase codes whereas >> RFC5170 defines two FEC schemes; >> >> you will probably conclude like us that QC's IPR disclosure for >> RFC5170 does not necessarily apply to this I-D. Hence our >> question: does QC intend to do a new IPR disclosure? When? > > *** This specification inherits technology from RFC 5170, and we > have made IPR declarations with regards to RFC 5170. As far as I > know, we do not plan to make any further IPR declarations on this > specification. My open points are addressed, i.e., my question of the IPR declarations for RFC 5170 and any potential relationship to draft-ietf-fecframe-ldpc. I will go forward with draft-ietf-fecframe-ldpc and ship it off to the RFC editor. Thank you! Martin -- martin.stiemerling@neclab.eu NEC Laboratories Europe - Network Research Division NEC Europe Limited Registered Office: NEC House, 1 Victoria Road, London W3 6BL Registered in England 283 From luby@qti.qualcomm.com Wed Oct 17 08:58:50 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 645A821F857D for ; Wed, 17 Oct 2012 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5U2ZluUSeoWr for ; Wed, 17 Oct 2012 08:58:49 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) by ietfa.amsl.com (Postfix) with ESMTP id 7D92C21F8550 for ; Wed, 17 Oct 2012 08:58:49 -0700 (PDT) X-IronPort-AV: E=McAfee;i="5400,1158,6867"; a="414856" Received: from ironmsg03-r.qualcomm.com ([172.30.46.17]) by sabertooth01.qualcomm.com with ESMTP; 17 Oct 2012 08:45:32 -0700 X-IronPort-AV: E=Sophos;i="4.80,601,1344236400"; d="scan'208";a="352878007" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-R.qualcomm.com with ESMTP/TLS/RC4-SHA; 17 Oct 2012 08:58:48 -0700 Received: from NASANEXD02C.na.qualcomm.com ([169.254.6.25]) by nasanexhc06.na.qualcomm.com ([172.30.48.21]) with mapi id 14.02.0318.001; Wed, 17 Oct 2012 08:58:48 -0700 From: "Luby, Michael" To: Martin Stiemerling , "Luby, Michael" Thread-Topic: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt Thread-Index: AQHNpiEgQHxRRh+VfUSBSAt8xaBu5Je0bsiAgAlJxYCAAC5EgP//p0cAgACOoAD//5eZAA== Date: Wed, 17 Oct 2012 15:58:47 +0000 Message-ID: In-Reply-To: <507ECADA.5010809@neclab.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.4.120824 x-originating-ip: [10.222.89.74] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <7F74A03822E38447A2D7A38962701312@qualcomm.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Mathieu Cunche , =?iso-8859-1?Q?J=E9r=F4me_Lacan?= , "fecframe@ietf.org" , Stephen Farrell Subject: Re: [Fecframe] I-D Action: draft-ietf-fecframe-ldpc-04.txt X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2012 15:58:50 -0000 Thanks Martin,=20 I didn't know there was an open question, but I'm happy to hear that it is addressed. Best, Mike On 10/17/12 8:12 AM, "Martin Stiemerling" wrote: >Hi Michael and Vincent, all, > >On 10/17/2012 03:41 PM, Luby, Michael wrote: >> Vincent, You are welcome. Responses below. Best, Mike >> >> On 10/17/12 4:59 AM, "Vincent Roca" wrote: >> >>> Mike, >>> >>> Thanks for your feedback. >[...] > > >>> >>> >>> More importantly. Since: >>> >>> 1- you noticed we impose restrictions on the way LDPC-Staircase >>> codes are being used in section 4.1; >>> >>> 2- you certainly remember the discussion we had in 2009 concerning >>> 10 out of the 13 patents mentioned in the RFC5170 IPR disclosure, >>> whose conclusion is here: >>> http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html >>> >>> 3- the present I-D only considers LDPC-Staircase codes whereas >>> RFC5170 defines two FEC schemes; >>> >>> you will probably conclude like us that QC's IPR disclosure for >>> RFC5170 does not necessarily apply to this I-D. Hence our >>> question: does QC intend to do a new IPR disclosure? When? >> >> *** This specification inherits technology from RFC 5170, and we >> have made IPR declarations with regards to RFC 5170. As far as I >> know, we do not plan to make any further IPR declarations on this >> specification. > >My open points are addressed, i.e., my question of the IPR declarations >for RFC 5170 and any potential relationship to draft-ietf-fecframe-ldpc. > >I will go forward with draft-ietf-fecframe-ldpc and ship it off to the >RFC editor. > >Thank you! > > Martin > >--=20 >martin.stiemerling@neclab.eu > >NEC Laboratories Europe - Network Research Division NEC Europe Limited >Registered Office: NEC House, 1 Victoria Road, London W3 6BL >Registered in England 283 From iesg-secretary@ietf.org Thu Oct 25 07:54:29 2012 Return-Path: X-Original-To: fecframe@ietfa.amsl.com Delivered-To: fecframe@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A689D21F8974; Thu, 25 Oct 2012 07:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms+XxI+UE1vk; Thu, 25 Oct 2012 07:54:27 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D6321F898E; Thu, 25 Oct 2012 07:54:26 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121025145426.25133.98308.idtracker@ietfa.amsl.com> Date: Thu, 25 Oct 2012 07:54:26 -0700 Cc: fecframe chair , fecframe mailing list , RFC Editor Subject: [Fecframe] Protocol Action: 'Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME' to Proposed Standard (draft-ietf-fecframe-ldpc-04.txt) X-BeenThere: fecframe@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion of FEC Framework List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2012 14:54:30 -0000 The IESG has approved the following document: - 'Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME' (draft-ietf-fecframe-ldpc-04.txt) as Proposed Standard This document is the product of the FEC Framework Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc/ Technical Summary This document describes a fully-specified simple FEC scheme for LDPC-Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. Working Group Summary There is consensus within the FECFrame WG to publish this document. The document has been actively discussed on the wg list and in wg meetings. There was no controversy with the progression of this document. Document Quality Performance evaluation of this: K. Matsuzono, J. Detchart, M. Cunche, V. Roca, H. Asaeda, ``Performance Analysis of a High-Performance Real-Time Application with Several AL-FEC Schemes", 35th Annual IEEE Conference on Local Computer Networks 2010 (LCN 2010), October 2010. (PDF) Personnel Greg Shepherd is the document shepherd and Martin Stiemerling is the responsible Area Director.