From abegen@cisco.com Wed Mar 3 16:23:29 2010 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 6A0283A89D8 for ; Wed, 3 Mar 2010 16:23:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.444 X-Spam-Level: X-Spam-Status: No, score=-10.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 9FZ5WJQnobRC for ; Wed, 3 Mar 2010 16:23:27 -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 003AD3A85B5 for ; Wed, 3 Mar 2010 16:23:26 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADOMjkurRN+K/2dsb2JhbACbEHOdeZhShHwEgxc X-IronPort-AV: E=Sophos;i="4.49,577,1262563200"; d="scan'208";a="95482928" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 04 Mar 2010 00:23:28 +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 o240NP2G020063 for ; Thu, 4 Mar 2010 00:23:25 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.3959); Wed, 3 Mar 2010 16:23:25 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Mar 2010 16:22:20 -0800 Message-ID: <04CAD96D4C5A3D48B1919248A8FE0D540B6F354A@xmb-sjc-215.amer.cisco.com> In-Reply-To: <067E6CE33034954AAC05C9EC85E2577CFE1087@XMB-RCD-111.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Working Group Last Callondraft-ietf-fecframe-config-signaling Thread-Index: AcnAUCNYynfRGSGsQD6kxc3yiHM2EQHSdwDAEHso/WAsalwL0A== References: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C893B@xmb-sjc-215.amer.cisco.com> <067E6CE33034954AAC05C9EC85E2577CFE1087@XMB-RCD-111.cisco.com> From: "Ali C. Begen (abegen)" To: "Rajiv Asati (rajiva)" , X-OriginalArrivalTime: 04 Mar 2010 00:23:25.0543 (UTC) FILETIME=[E7CF5770:01CABB30] Subject: Re: [Fecframe] Working Group Last Callondraft-ietf-fecframe-config-signaling 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: Thu, 04 Mar 2010 00:23:29 -0000 Thanks for addressing these. But, I need to refresh my memory on this draft. Also, some stuff may need revision once the framework is revised. Which reminds me that the wglc has been running for the framework draft since the last IETF (over two months). A revision based on the comments already made on the draft is already overdue. Can we get a revised version so that maybe we can eventually finalize all the work and other drafts in fecframe? -acbegen > -----Original Message----- > From: Rajiv Asati (rajiva) > Sent: Wednesday, February 24, 2010 7:50 PM > To: Ali C. Begen (abegen); Marshall Eubanks; fecframe@ietf.org > Subject: RE: [Fecframe] Working Group Last Callondraft-ietf-fecframe-config-signaling >=20 > Hi Ali, >=20 > Sorry about the delayed response. Thank you so much for your review during the WGLC and useful > comments. I have incorporated all of the comments in the -02 version (attached) and answered each of > your comment below: >=20 > 1. Very good catch. I have expanded your suggestion a bit for further clarity as shown below: >=20 > This document does not make any assumption that the 'FEC sender' and 'Media Source/Sender' > functionalities are implemented on the same device, though that may be the case. Similarly, this > document does not make any assumption that 'FEC receiver' and 'Media Receiver' functionalities are > implemented on the same device, though that may be the case. >=20 > 2. I think that you meant to say 'encoding format', not signaling protocol. If so, then I agree to > your suggestion and update the text as shown below: >=20 > Independent of what all encoding formats supported by an FEC scheme, each instance of the FEC > Framework must use a single encoding format to describe e.g. encode all of the configuration > information associated with that instance. >=20 >=20 > 3. >=20 > > "Unicasted", "multicasted" should be "unicast", "multicast" >=20 > =3D=3D> Fixed. >=20 >=20 > 4. >=20 > > - page 10: > > > > There is an editor's note, which should be removed (the note itself > > could be kept). > > >=20 > 'Editor's note' removed. >=20 > 5. >=20 > > - Section 4.2.2: > > > > Is this section suggesting/assigning/registering any new RTSP > > parameters? If so, is there a proper way of doing it? Any IANA > > considerations that this document needs to have? >=20 > Good point. >=20 > I have updated this section accordingly to explicitly request an option-tag for 'FEC protection > required'. Also updated the IANA considerations. >=20 > Do we need to include anything else? >=20 >=20 > 6. >=20 > > - Section 4.2.3: > > > > Not sure how useful this section is. At least, the document should > > provide the references for the mentioned specs. >=20 >=20 > Agreed to the limited usefulness. Section 4.2.3 has been deleted now. >=20 >=20 > > Nits: > > - "Configuration Information" is sometimes capitalized, sometimes not. > > The document needs to be consistent. >=20 > Fixed. >=20 > > - Typo in page 2: "FEC scheme specifics information". Use FSSI where possible. >=20 > Fixed. >=20 > > - Need for plural versions at the end of Section 1, i.e., multicast > > applications, unicast applications, security considerations. "section X" > > should be "Section X". >=20 > Fixed. >=20 > > - Inconsistent capitalization in the numbered list on page 3. >=20 > Fixed. All capital. >=20 > > - Missing commas before and after "i.e." >=20 > Fixed. >=20 > > - Spell out "OAM" on page 4 >=20 > Done >=20 > > - "provide a mean" --> "provide a means" on page 4 >=20 > Fixed. >=20 > > - The capitalization of special words like "MUST, MAY, SHOULD" be > > checked as there are many occasions where the capitalized versions > > would probably make more sense. >=20 > Fixed. >=20 > > - Typo on page 9: "doesn't already exists" >=20 > Fixed. >=20 > > - Conclusions section can be removed. >=20 > Done. >=20 > Cheers, > Rajiv >=20 > > -----Original Message----- > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > > Behalf Of Ali C. Begen (abegen) > > Sent: Monday, April 27, 2009 9:23 PM > > To: Marshall Eubanks; fecframe@ietf.org > > Subject: Re: [Fecframe] Working Group Last > > Callondraft-ietf-fecframe-config- signaling > > > > These are my comments for this draft. I suppose due to normative > > references, this document will have to wait for the framework and SDP drafts anyway. > > > > BR, > > -acbegen > > > > > > - Page 4: > > > > "This document does not make any assumption that the 'FEC sender and > > receiver' functionality and the 'Media Source/Receiver' functionality > > are implemented on the single device, though it may be the case." > > > > Should read: > > > > "This document does not make any assumption that the Media Sender and > > FEC Sender functionalities or the Media Receiver and FEC Receiver > > functionalities are implemented on the same host, although this may be the case." > > > > - page 5: > > > > "Each instance of the FEC Framework muse use a single encoding format > > to describe e.g. encode all of the configuration information > > associated with that instance." > > > > I believe we need to make it clear that an FEC scheme can support > > multiple signaling protocols but it must use a single encoding format in a particular > > instance. > > > > - page 5 and beyond: > > > > "Unicasted", "multicasted" should be "unicast", "multicast". > > > > - page 10: > > > > There is an editor's note, which should be removed (the note itself > > could be kept). > > > > - Section 4.2.2: > > > > Is this section suggesting/assigning/registering any new RTSP > > parameters? If so, is there a proper way of doing it? Any IANA > > considerations that this document needs to have? > > > > - Section 4.2.3: > > > > Not sure how useful this section is. At least, the document should > > provide the references for the mentioned specs. > > > > > > Nits: > > - "Configuration Information" is sometimes capitalized, sometimes not. > > The document needs to be consistent. > > - Typo in page 2: "FEC scheme specifics information". Use FSSI where possible. > > - Need for plural versions at the end of Section 1, i.e., multicast > > applications, unicast applications, security considerations. "section X" > > should be "Section X". > > - Inconsistent capitalization in the numbered list on page 3. > > - Missing commas before and after "i.e." > > - Spell out "OAM" on page 4 > > - "provide a mean" --> "provide a means" on page 4 > > - The capitalization of special words like "MUST, MAY, SHOULD" be > > checked as there are many occasions where the capitalized versions > > would probably make more sense. > > - Typo on page 9: "doesn't already exists" > > - Conclusions section can be removed. > > > > > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org > > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Marshall Eubanks > > > Sent: Saturday, April 18, 2009 11:04 AM > > > To: fecframe@ietf.org > > > Subject: [Fecframe] Working Group Last Call > > > ondraft-ietf-fecframe-config-signaling > > > > > > I think that this document is also ready, so I would like to issue a > > > working group last call on draft-ietf-fecframe-config-signaling-01. > > > This document can be > > > found at > > > > > > http://tools.ietf.org/id/draft-ietf-fecframe-config-signaling-01.txt > > > > > > I encourage everyone to read this document and comment during the > > > last call period. > > > > > > This last call will end on Monday, May 4th, 2009. > > > > > > Regards > > > Marshall Eubanks > > > _______________________________________________ > > > 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 rajiva@cisco.com Wed Mar 3 16:46:31 2010 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 B762028C4BA for ; Wed, 3 Mar 2010 16:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[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 NQ1aSMNZmbRN for ; Wed, 3 Mar 2010 16:46:30 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2E8BD28C183 for ; Wed, 3 Mar 2010 16:46:30 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADORjkutJV2Y/2dsb2JhbACbEHOeCJhRhHwEgxc X-IronPort-AV: E=Sophos;i="4.49,577,1262563200"; d="scan'208";a="90435911" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 04 Mar 2010 00:46:31 +0000 Received: from xbh-rcd-201.cisco.com (xbh-rcd-201.cisco.com [72.163.62.200]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o240kUK2010554 for ; Thu, 4 Mar 2010 00:46:30 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 3 Mar 2010 18:46:30 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Mar 2010 18:46:29 -0600 Message-ID: <067E6CE33034954AAC05C9EC85E2577C01142277@XMB-RCD-111.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540B6F354A@xmb-sjc-215.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] Working Group Last Callondraft-ietf-fecframe-config-signaling Thread-Index: AcnAUCNYynfRGSGsQD6kxc3yiHM2EQHSdwDAEHso/WAsalwL0AAA/y2Q References: <387DA3D4-8B91-48C8-BB08-3C0725D112F8@multicasttech.com> <04CAD96D4C5A3D48B1919248A8FE0D54092C893B@xmb-sjc-215.amer.cisco.com> <067E6CE33034954AAC05C9EC85E2577CFE1087@XMB-RCD-111.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540B6F354A@xmb-sjc-215.amer.cisco.com> From: "Rajiv Asati (rajiva)" To: "Ali C. Begen (abegen)" , X-OriginalArrivalTime: 04 Mar 2010 00:46:30.0761 (UTC) FILETIME=[2176D590:01CABB34] Subject: Re: [Fecframe] Working Group Last Callondraft-ietf-fecframe-config-signaling 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: Thu, 04 Mar 2010 00:46:31 -0000 Hi Ali, Thanks. Would appreciate your feedback. Cheers, Rajiv > -----Original Message----- > From: Ali C. Begen (abegen) > Sent: Wednesday, March 03, 2010 7:22 PM > To: Rajiv Asati (rajiva); 'fecframe@ietf.org' > Subject: RE: [Fecframe] Working Group Last Callondraft-ietf-fecframe- > config-signaling >=20 > Thanks for addressing these. But, I need to refresh my memory on this > draft. Also, some stuff may need revision once the framework is revised. >=20 > Which reminds me that the wglc has been running for the framework draft > since the last IETF (over two months). A revision based on the comments > already made on the draft is already overdue. Can we get a revised > version so that maybe we can eventually finalize all the work and other > drafts in fecframe? >=20 > -acbegen >=20 > > -----Original Message----- > > From: Rajiv Asati (rajiva) > > Sent: Wednesday, February 24, 2010 7:50 PM > > To: Ali C. Begen (abegen); Marshall Eubanks; fecframe@ietf.org > > Subject: RE: [Fecframe] Working Group Last Callondraft-ietf-fecframe- > config-signaling > > > > Hi Ali, > > > > Sorry about the delayed response. Thank you so much for your review > during the WGLC and useful > > comments. I have incorporated all of the comments in the -02 version > (attached) and answered each of > > your comment below: > > > > 1. Very good catch. I have expanded your suggestion a bit for further > clarity as shown below: > > > > This document does not make any assumption that the 'FEC sender' and > 'Media Source/Sender' > > functionalities are implemented on the same device, though that may be > the case. Similarly, this > > document does not make any assumption that 'FEC receiver' and 'Media > Receiver' functionalities are > > implemented on the same device, though that may be the case. > > > > 2. I think that you meant to say 'encoding format', not signaling > protocol. If so, then I agree to > > your suggestion and update the text as shown below: > > > > Independent of what all encoding formats supported by an FEC scheme, > each instance of the FEC > > Framework must use a single encoding format to describe e.g. encode all > of the configuration > > information associated with that instance. > > > > > > 3. > > > > > "Unicasted", "multicasted" should be "unicast", "multicast" > > > > =3D=3D> Fixed. > > > > > > 4. > > > > > - page 10: > > > > > > There is an editor's note, which should be removed (the note itself > > > could be kept). > > > > > > > 'Editor's note' removed. > > > > 5. > > > > > - Section 4.2.2: > > > > > > Is this section suggesting/assigning/registering any new RTSP > > > parameters? If so, is there a proper way of doing it? Any IANA > > > considerations that this document needs to have? > > > > Good point. > > > > I have updated this section accordingly to explicitly request an > option-tag for 'FEC protection > > required'. Also updated the IANA considerations. > > > > Do we need to include anything else? > > > > > > 6. > > > > > - Section 4.2.3: > > > > > > Not sure how useful this section is. At least, the document should > > > provide the references for the mentioned specs. > > > > > > Agreed to the limited usefulness. Section 4.2.3 has been deleted now. > > > > > > > Nits: > > > - "Configuration Information" is sometimes capitalized, sometimes > not. > > > The document needs to be consistent. > > > > Fixed. > > > > > - Typo in page 2: "FEC scheme specifics information". Use FSSI where > possible. > > > > Fixed. > > > > > - Need for plural versions at the end of Section 1, i.e., multicast > > > applications, unicast applications, security considerations. "section > X" > > > should be "Section X". > > > > Fixed. > > > > > - Inconsistent capitalization in the numbered list on page 3. > > > > Fixed. All capital. > > > > > - Missing commas before and after "i.e." > > > > Fixed. > > > > > - Spell out "OAM" on page 4 > > > > Done > > > > > - "provide a mean" --> "provide a means" on page 4 > > > > Fixed. > > > > > - The capitalization of special words like "MUST, MAY, SHOULD" be > > > checked as there are many occasions where the capitalized versions > > > would probably make more sense. > > > > Fixed. > > > > > - Typo on page 9: "doesn't already exists" > > > > Fixed. > > > > > - Conclusions section can be removed. > > > > Done. > > > > Cheers, > > Rajiv > > > > > -----Original Message----- > > > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > > > Behalf Of Ali C. Begen (abegen) > > > Sent: Monday, April 27, 2009 9:23 PM > > > To: Marshall Eubanks; fecframe@ietf.org > > > Subject: Re: [Fecframe] Working Group Last > > > Callondraft-ietf-fecframe-config- signaling > > > > > > These are my comments for this draft. I suppose due to normative > > > references, this document will have to wait for the framework and SDP > drafts anyway. > > > > > > BR, > > > -acbegen > > > > > > > > > - Page 4: > > > > > > "This document does not make any assumption that the 'FEC sender > and > > > receiver' functionality and the 'Media Source/Receiver' > functionality > > > are implemented on the single device, though it may be the case." > > > > > > Should read: > > > > > > "This document does not make any assumption that the Media Sender and > > > FEC Sender functionalities or the Media Receiver and FEC Receiver > > > functionalities are implemented on the same host, although this may > be the case." > > > > > > - page 5: > > > > > > "Each instance of the FEC Framework muse use a single encoding > format > > > to describe e.g. encode all of the configuration information > > > associated with that instance." > > > > > > I believe we need to make it clear that an FEC scheme can support > > > multiple signaling protocols but it must use a single encoding format > in a particular > > > instance. > > > > > > - page 5 and beyond: > > > > > > "Unicasted", "multicasted" should be "unicast", "multicast". > > > > > > - page 10: > > > > > > There is an editor's note, which should be removed (the note itself > > > could be kept). > > > > > > - Section 4.2.2: > > > > > > Is this section suggesting/assigning/registering any new RTSP > > > parameters? If so, is there a proper way of doing it? Any IANA > > > considerations that this document needs to have? > > > > > > - Section 4.2.3: > > > > > > Not sure how useful this section is. At least, the document should > > > provide the references for the mentioned specs. > > > > > > > > > Nits: > > > - "Configuration Information" is sometimes capitalized, sometimes > not. > > > The document needs to be consistent. > > > - Typo in page 2: "FEC scheme specifics information". Use FSSI where > possible. > > > - Need for plural versions at the end of Section 1, i.e., multicast > > > applications, unicast applications, security considerations. "section > X" > > > should be "Section X". > > > - Inconsistent capitalization in the numbered list on page 3. > > > - Missing commas before and after "i.e." > > > - Spell out "OAM" on page 4 > > > - "provide a mean" --> "provide a means" on page 4 > > > - The capitalization of special words like "MUST, MAY, SHOULD" be > > > checked as there are many occasions where the capitalized versions > > > would probably make more sense. > > > - Typo on page 9: "doesn't already exists" > > > - Conclusions section can be removed. > > > > > > > > > > > > > -----Original Message----- > > > > From: fecframe-bounces@ietf.org > > > > [mailto:fecframe-bounces@ietf.org] On Behalf Of Marshall Eubanks > > > > Sent: Saturday, April 18, 2009 11:04 AM > > > > To: fecframe@ietf.org > > > > Subject: [Fecframe] Working Group Last Call > > > > ondraft-ietf-fecframe-config-signaling > > > > > > > > I think that this document is also ready, so I would like to issue > a > > > > working group last call on draft-ietf-fecframe-config-signaling-01. > > > > This document can be > > > > found at > > > > > > > > http://tools.ietf.org/id/draft-ietf-fecframe-config-signaling- > 01.txt > > > > > > > > I encourage everyone to read this document and comment during the > > > > last call period. > > > > > > > > This last call will end on Monday, May 4th, 2009. > > > > > > > > Regards > > > > Marshall Eubanks > > > > _______________________________________________ > > > > 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 gjshep@gmail.com Thu Mar 4 05:27:19 2010 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 7EE093A88DE for ; Thu, 4 Mar 2010 05:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcpInX9wdYmh for ; Thu, 4 Mar 2010 05:27:18 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id B47A83A88C2 for ; Thu, 4 Mar 2010 05:27:18 -0800 (PST) Received: by vws20 with SMTP id 20so1374967vws.31 for ; Thu, 04 Mar 2010 05:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=10+54RqJz+bdgJRTvxkhCeZcMT4SQYR7uAMFFwR0GKQ=; b=HRbTDCFhbMMZXvSEuksQvOydsFmUMaDkcvoYUSIUbjKG2+BwO1ITYC5xmugO3RSov+ GC5vXBGmp+A/N4bZex3roNK2PAeWflCem/ppK/GcD94Q/0wd2bdv6J47l2QjGZlhNwKp Oy72fHI65pF4KWJFnGEVv0KHE3KxnpKYmEDqo= 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=k1JJ6rRIs+lgTwS/R1QCzPDuhd8JgCEjfWFXcdC5Z+UEu4dc5mJPBzxY5TQYqzNxsh IllUJ9ChKws0t7lORUKXSrHT8qj8PGcgnjUKjiDXflfhet6Tfbg1hqw161++cVAlMgw7 JsGGij2TCEhIZDBvLQiy2Ci3HVwpXJEFsSv/o= MIME-Version: 1.0 Received: by 10.224.54.204 with SMTP id r12mr873706qag.271.1267709237065; Thu, 04 Mar 2010 05:27:17 -0800 (PST) Date: Thu, 4 Mar 2010 05:27:16 -0800 Message-ID: <38c19b541003040527n369bcf77o4bf2362a5a795fb2@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Agenda Items Please! 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, 04 Mar 2010 13:27:19 -0000 Please send any/all FECFrame agenda items to me asap. Thanks!, Greg From watson@qualcomm.com Fri Mar 5 14:46:49 2010 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 52C2428C3CA for ; Fri, 5 Mar 2010 14:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.999 X-Spam-Level: X-Spam-Status: No, score=-105.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_66=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 mVWE5K64zX4O for ; Fri, 5 Mar 2010 14:46:47 -0800 (PST) Received: from wolverine02.qualcomm.com (wolverine02.qualcomm.com [199.106.114.251]) by core3.amsl.com (Postfix) with ESMTP id 1725E3A8DEE for ; Fri, 5 Mar 2010 14:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1267829210; x=1299365210; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20|To:=20V incent=20Roca=20|CC:=20"fecfra me@ietf.org"=20|Date:=20Fri,=205=20Mar =202010=2014:46:15=20-0800|Subject:=20Re:=20[Fecframe]=20 review=20of=20draft-ietf-fecframe-framework-05 |Thread-Topic:=20[Fecframe]=20review=20of=20draft-ietf-fe cframe-framework-05|Thread-Index:=20Acq8taW+NMq4a8kVS3q9j yYfs9iCcw=3D=3D|Message-ID:=20<1F4A44A8-6200-42EC-B67E-EB 537AEDF4EA@qualcomm.com>|References:=20<4B47A253.5080806@ inrialpes.fr>|In-Reply-To:=20<4B47A253.5080806@inrialpes. fr>|Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=+RFhaSAxxH95ihbiOn1vV1TNaEtF8E+TsEgw7esQ8Qk=; b=MUCQ2xYcs75a/68iM+YLUp71dlkuZc93Va57bUj8FKfqoQ6vD6/pAmVZ giXXYrJpjnoQlGIQ4p/zi+MsCGfqkXT0MghI7cJUXQDoOsFh0Q75RsBE1 DWhKUbn1P4vwm6DAqYSreb52UFwkzK3Yhpapp6dDdAc6+rUvtqkW60KMT U=; X-IronPort-AV: E=McAfee;i="5400,1158,5911"; a="35686822" Received: from ironstorm.qualcomm.com ([172.30.39.153]) by wolverine02.qualcomm.com with ESMTP; 05 Mar 2010 14:46:17 -0800 X-IronPort-AV: E=Sophos;i="4.49,587,1262592000"; d="scan'208";a="50161071" Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 05 Mar 2010 14:46:17 -0800 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 5 Mar 2010 14:46:09 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Fri, 5 Mar 2010 14:46:08 -0800 From: "Watson, Mark" To: Vincent Roca Date: Fri, 5 Mar 2010 14:46:15 -0800 Thread-Topic: [Fecframe] review of draft-ietf-fecframe-framework-05 Thread-Index: Acq8taW+NMq4a8kVS3q9jyYfs9iCcw== Message-ID: <1F4A44A8-6200-42EC-B67E-EB537AEDF4EA@qualcomm.com> References: <4B47A253.5080806@inrialpes.fr> In-Reply-To: <4B47A253.5080806@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] review of draft-ietf-fecframe-framework-05 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, 05 Mar 2010 22:46:49 -0000 Vincent, Thanks for the detailed review. My responses are below. I will submit an -0= 6 draft shortly. ...Mark On Jan 8, 2010, at 1:23 PM, Vincent Roca wrote: > Mark, all, > > Here is a review of draft-ietf-fecframe-framework-05. > It *includes and replaces* the comments I've sent at > the end of October. > > Cheers, > > Vincent > > > ** Abstract: > > > - typo: "This document describes for a framework" -> remove "for" > > Ok > ** Section 2: > > > - 'Transport protocol' is defined as "the protocol used for transport of > the source data flow". This is misleading since it is also used to > transport the *repair* data flow. > Suggest: "The protocol used for transport of the source and repair data flo= ws" > - 'Application Data Unit' is defined WRT the transport layer: "Data used > as the payload for the transport layer". This is misleading, since in > a FECFRAME system, the transport layer will also carry repair symbols. > IMHO, the ADU should be defined WRT to the application, e.g.: > > Application Data Unit (ADU): at a sender (resp. receiver), a unit of > data coming from (resp. given to) the media delivery application. > Depending on the use-case, an ADU can use an RTP encapsulation. > How about: "The unit of source data provided as payload to the transport la= yer" The problem I see with your definition is that the boundary of "media deliv= ery application" is not clear. > I also suggest you add a sentence like: "The Source data flow consists > of ADUs" (either here or in the definition of 'Source data flow'). Ok > > - 'FEC Code' definition mentions it can be used to be resilient to > *corruptions*. I understand that this is for the general case, however > it has been clearly stated in Introduction that we are only considering > the case of erasures! This is therefore misleading. > Suggestion: "An algorithm for encoding data such that the encoded data flow= is resiliant to data loss (Note: in general FEC Codes may also be used to = make a data flow resiliant to corruption, but that is not considered here).= " > - 'Source Block' is defined as "the group of source data packets which > are to be FEC protected as a single block". But nowhere the notion of > "source data packets" has been defined. I suggest to refer to ADUs > instead. > Ok > IMHO the term "source block" is confusing because it's overloaded. > It is primarily a term used by FEC codes (i.e. a set of source symbols > over which FEC encoding takes place). Using the same term in the > context of the FEC framework creates confusion, especially as some > FEC Schemes may define several source blocks from a single ADU block > (e.g. our Reed-Solomon I-D). > > For clarification purposes I suggest to use the term of ADU block in > this I-D and to keep the traditional meaning of "source block". > If you agree, there are many locations (e.g. section 5 and 6) that > refer to source blocks. I agree that there could be some confusion because for some codes the Sourc= e Blocks from the point of view of the code are subsets of the Source Block= as defined here. My concern with changing the terminology is that this ter= minology is used outside this document as well and I'm not confident we wil= l be able to find all the occurrences which need updating and do that in a = coordinated manner. I think here we will just have to be careful when defining FEC Schemes to a= void the term "Source Block" for the systematic part of a codeword when it = does not coincide with the FECFRAME Source Block, or just be careful to def= ine clearly. > > - FEC Payload ID and the Source|Repair FEC Payload IDs: These three > definitions refer resp. to packet|source packet|repair packet. But the > notion of packet has not been defined. I suggest to add: > > FEC Source Packet: at a sender (resp. receiver) a data packet submitt= ed > to (resp. received from) the Transport protocol. It contains an ADU > along with its optional Source FEC Payload ID, if any. > > FEC Repair Packet: at a sender (resp. receiver) a repair packet > submitted > to (resp. received from) the Transport protocol. It contains a repa= ir > symbol along with its Repair FEC Payload ID and possibly RTP header= . > Ok, I suggest the following minor rewording: FEC Source Packet: At a sender (resp. receiver) a payload submitted to (res= p. received from) the Transport protocol containing an ADU along with an op= tional Source FEC Payload ID. FEC Repair Packet: At a sender (resp. receiver) a payload submitted to (res= p. received from) the Transport protocol containing one or more repair symb= ols along with a Repair FEC Payload ID and possibly an RTP header. > - IMHO you should add a few definitions coming from [RFC5052] for > clarity. E.g. the definition of a 'Source block' should appear here. > There's an example in draft-roca-fecframe-rs-01.txt (sorry, the same > reference once again ;-)) where we split definitions between those that > are FEC Scheme specific and those that are FEC Framework specific. > I think it would help. > Ok, I added the same ones as in your draft. > > ** Section 4: > > > - p.10, end of 1st paragraph: I don't understand the sentence: > "In this case the interface to the FEC Framework, at > least for the repair flows, can be thought of as equivalent to that > between RTP and users of RTP." > > Which "interface to the FEC Framework" does it refer to? The one with > overlying protocols (e.g. RTP) or the one with underlying ones (e.g. > UDP)? In any case FEC repair packets with RTP framing won't reach the > application, so I don't see the relationships with the "users of RTP". > I suggest to remove the sentence altogether. > Ok. > - p.10: it is said: > "the FEC Framework passes groups of transport packet payloads > to the FEC Scheme for FEC Encoding." > > What does "transport packet payloads" mean? I suggest instead 'ADUs'. > Moreover: Encoding -> encoding. > Ok - I think this was just missed when the ADU term was introduced. > - p.10: In sentence: > > "The FEC Scheme returns FEC > repair packet payloads, encoded FEC Payload ID information for each > of the repair packets and, in some cases, encoded FEC Payload ID > information for each of the source packets." > > "encoded FEC Payload ID" -> "repair FEC Payload ID". > I also suggest to simplify a bit (see comment for Fig. 2 concerning > the use of "repair symbol"): > > "The FEC Scheme returns repair symbols with their associated > Repair FEC Payload ID, and in some case the Source FEC Payload ID, > depending on the FEC Scheme." > Ok. > - p.10: there is no reason to use "'" in the following sentence since > Source data flow and Repair data flow have been formally defined in > Section 2. > "... and the > relationship(s) between these 'source' and 'repair' flows..." > Ok. > - p.11 and fig 1: > The notion of "transport flow" has not been defined. Use "Source data > flow" or (better IMHO) "ADU flow" instead. And there are many other > instances of "transport flow(s)" in the document that need to be > corrected. > Ok, and I will add a definition for ADU flow. > - p.11: It is said: > "From the FEC > Framework point of view, RTP source flows are sequences of UDP packet > payloads like any other protocol over UDP." > > It might be another protocol than UDP, right? I know RTP/DCCP has been > discussed at IETF in the past. I don't know the current status. > I think what is meant is better said as follows: "From the FEC Framework po= int of view, RTP source flows are ADU flows like any other, with the RTP he= ader included within the ADU". > - p.11, typo: "the the repair payload" -> "the repair payload". > And in the same sentence, *repair* data is not necessarily *parity* > data. It depends on the FEC code being used. The term "parity" appears > two other times in this paragraph. > Ok. I will replace "parity bytes" with "repair data" > - Fig 1: I suggest you add "example" in the figure caption to highlight > the fact RTP is not a mandatory part of the architecture, and similarly > that you add the "optional" keyword in the top RTP box. > Change "Transport flows" by either Source data flow(s) or ADU flow(s). > I'd prefer that the main architecture was not just an "example" ;-) Otherwi= se ok. > > ** Section 5: > > > - Section 5.1 p.14: you refer to "encoded FEC Payload IDs" with both > FEC source and repair packets. By "encoded" I understand that it is > stored in a FEC Scheme specific format that does not have to be > understood by the FEC Framework. I'd rather say in the two bullets > something like: > > o optionally, FEC Payload IDs (encoded according to a FEC Scheme > specific format) for each of... > Ok. > - a detail, p14: "source Application Data Units" -> "Application Data Uni= ts" > (it's sufficient). Ok. > > - Section 5.1 says that a CDP MAY define the mapping between ADUs and > a source block (I prefer "an ADU block" as said above). > You should also say that a FEC Scheme MAY also define this mapping, > or at least provide some rules (e.g. a limit on the maximum source > block size (k) which will limit the maximum ADU block size). > More generally, the CDP versus FEC Scheme responsibilities in terms > of what is defined where are not clear, at least for me. > I suggest adding the following: "FEC Schemes MAY define limitations on this= mapping, such as maximum size of source blocks, but SHOULD NOT attempt to = define specific mappings." What is stated is that the CDP or implementations are responsible for defin= ing the mapping of ADUs to Source Blocks. This is as it should be since thi= s mapping is very application-dependent and FEC Schemes are supposed as far= as possible to be application independent. But this is all recommendation = strength, since FEC Schemes will vary in their generality and some might be= quite specific to particular applications. > - Section 5.2, bottom of p.16: > "...on the eventual IP FEC Source Packet..." > What is an IP FEC Source Packet? I guess you mean "an IP datagram > carrying a FEC source packet". > Ok. > - Fig. 2: What is the "Repair transport payload"? This is not defined > in section 2. I guess this payload plus the Repair FEC Payload ID form > the transport payload. > I suggest you use the term "repair symbol" (which should be > defined in Section 2 too) instead. Ok. > > - Fig. 3: Similarly, I don't like "Repair RTP payloads" since this > name refers to the RTP box below rather than to the FEC Scheme that > produced this unit of data. I'd rather say: "repair symbol". > Ok. > And another remark: step 6 creates the FEC repair packet, but RTP > framing happens later, after step 7'. > In my understanding, an FEC repair packet already includes the RTP > header, isn't it? > Yes, it should be "repair RTP payloads", though unfortunately that will not= fit in the diagram. I hope "repair payloads" is sufficient. > - Section 5.3, step 4: > The algorithm that is described is the one where all the ADUs of an > ADU block are kept by the FEC framework until it is known that either > all the ADUs are available (received or decoded), or that no additional > FEC repair packet will be received for this block in case one or severa= l > ADUs are missing. This technique corresponds to the strategy where > the FEC framework performs buffering and in-order delivery of the > available ADUs to the application (discussion of section 5.1). This > should be clearly mentioned. Actually, Step 4 describes processing done by the FEC Scheme. Or do you mea= n that the Framework and Scheme together perform these functions, rather th= an forwarding received ADUs directly to the applications possibly out-of-or= der ? I suggest adding "Note that the description above defines functionali= ty responsibilities but does not imply a specific set of timing relationshi= ps. For example, ADUs may eb provided to the application as soon as they ar= e received or recovered (and hence potentially out-of-order) or they may be= buffered are delivered to the application in-order." > > Additionally, step 4 requires that the received FEC source and repair > packets be kept in the FEC framework during (at most) the ADU block > reception duration. This is not mentioned explicitly. I'd like to > see a loop somewhere in this description. Well, this gets into implementation: the FEC Framework is not a software co= mponent and implementations are possible where there is no component corres= ponding to the FEC Framework itself (the functions would be integrated with= application packet handling. So I don't think it makes sense to talk about= packets being "kept in the FEC Framework" - we are just defining functiona= l components here. > > In step 5 there a missing final "s" in Units, 1st line. > Ok. > - Section 5.3, p.21: > Instead of "source packets" or "original source packets", you should > use ADUs. > Ok. > Additionally: > The way this paragraph is currently written is strange since what > you say in the last sentence ("Alternatively, buffering...") is > exactly what has been detailed before in the algorithm. > I suggest you just explain here that other strategies are possible > that do not necessarily rely on buffering unlike what has been presente= d > just before. But in any case the FEC framework/scheme usually needs to > keep a copy of the FEC source/repair packets of the current block (for > decoding purposes), even if ADUs are given to the application as soon a= s > possible. > I don't think the description implies anything about buffering or where it = takes place. It describes functions that are performed. Obviously you need = input data for those functions, but whether and where that is stored is not= described (for example, there may be an implementation where the received = source symbols can be processed as they arrive and only the result of some = source symbol computations needs to be stored in order to make later use of= repair data). > > ** Section 6: > > > I didn't read, sorry. > > > ** Section 7: > > > - typos: "recieved", "inaccuate". Ok > > - It is said: > New applications which require such feedback SHOULD use RTP/RTCP > [RFC3550]. > > Isn't "SHOULD" a little bit too strong here? I agree it's a convenient, > on-the-shelf, solution, but alternatives may exist. > I don't have an opinion, but I think this was discussed and we agreed to re= commend RTP/RTCP. SHOULD is not really all that strong since the formal def= inition is essentially "MUST unless you have a good reason" - so we are jus= t saying don't use an alternative for no good reason. > > ** Globally, I have the feeling that the use of RTP for the repair data > flow is not sufficiently motivated. There's a small paragraph in the > introduction to say that a motivation is to use "RTP instrumentation". > Later on, in section 4 (Architecture), it is said that the source and > repair data flows can be multiplexed on the same UDP flow (1st > paragraph). > There are two additional paragraphs in section 4 to explain what the > RTP repair data packet consists in and the fact it's decoupled from the > source data flow > > I'd like to see a sub-section that explains clearly, in a single place, > all the motivations for using an RTP framing with repair packets > (in particular the backward compatibility benefits, the possibility > to multiplex the various flows on the same UDP flow, etc.). > Me too, but it was not my proposal or preference to have this option ... > > ** To finish: the FECFRAME group should probably be thanked too in > section 12 ;-) > Ok! > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From watson@qualcomm.com Fri Mar 5 15:05:19 2010 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 F28DC28C3D4 for ; Fri, 5 Mar 2010 15:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=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 HrpVpYODXsmN for ; Fri, 5 Mar 2010 15:05:16 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id E7B5C28C3CA for ; Fri, 5 Mar 2010 15:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1267830319; x=1299366319; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20|To:=20O rly=20Peck=20|CC:=20"fecframe@ietf.o rg"=20|Date:=20Fri,=205=20Mar=202010 =2015:05:15=20-0800|Subject:=20Re:=20[Fecframe]=20WG=20La st=20Call=20-=20Framework|Thread-Topic:=20[Fecframe]=20WG =20Last=20Call=20-=20Framework|Thread-Index:=20Acq8uE1Qr6 wGnSULRduOpLUr8KZpdA=3D=3D|Message-ID:=20|References:=20|In-Reply-To:=20|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=dRf98t0BqREEwQMDNkVEfw71euP0VI+FQsKEWjPlAdA=; b=GhmhxX4u0WLjdFz5KbFyKLDbLYI468yXTTDt3DzOtSHZwZyjA7HmsouU wurWOgd8Me3nsSiWhShrxAR1j+Ez034QklBNlut/SXBiDFmwgGopr6AaG ZBQnHLN9+BWHHRkgzPnytva1hElmpNjXNGqmSJwU+MuLXGXTNfOWu5ep5 E=; X-IronPort-AV: E=McAfee;i="5400,1158,5911"; a="35746055" Received: from ironrogue.qualcomm.com ([129.46.61.164]) by wolverine01.qualcomm.com with ESMTP; 05 Mar 2010 15:05:18 -0800 X-IronPort-AV: E=Sophos;i="4.49,587,1262592000"; d="scan'208";a="49224760" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 05 Mar 2010 15:05:18 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 5 Mar 2010 15:05:10 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 5 Mar 2010 15:05:09 -0800 From: "Watson, Mark" To: Orly Peck Date: Fri, 5 Mar 2010 15:05:15 -0800 Thread-Topic: [Fecframe] WG Last Call - Framework Thread-Index: Acq8uE1Qr6wGnSULRduOpLUr8KZpdA== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] WG Last Call - Framework 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, 05 Mar 2010 23:05:19 -0000 Orly, Thanks for your detailed comments. My responses are below. An -06 draft wil= l be available shortly. ...Mark On Jan 19, 2010, at 11:28 PM, Orly Peck wrote: > Hi, > Following are my comments for draft-ietf-fecframe-framework-05: >=20 > 1) On page 11, last sentence: "a repair packet carried over RTP starts wi= th an RTP header of its own which is immediately followed by parity data...= " - what about a FEC header that follows the RTP header? Good point. I will replace "immediately followed by" with "followed (after = the Repair Payload ID) by" >=20 > 2) on page 14 - "a CDP specification MUST define how a receiver determine= s the length of time it should wait to receive FEC repair packets for any g= iven source blocks".=20 > Sometimes only the receiver knows how much time it can wait for a FEC rep= air packet due to latency considerations or any other consideration the rec= eiving application may take into account. IMHO the sender can define a MINI= MUM time that the sender should wait for the repair packet. Agreed. If we say "...how a receiver determines a minimum length of time ..= ." does that address the issue ?=20 >=20 > 3) typo - on page 22 section 6.2 - "For each sApplication Data Units..." = - remove "s". Ok. >=20 > 4) same paragraph - I think that the FEC scheme should (optionally) rece= ive the information of the index of the ADU in the source block (this is im= portant for FEC codes where order is significant). >=20 Agreed. I re-worded the sentence before the bullet list as "Each Source Blo= ck provided to the FEC scheme consists of an ordered sequence of Applicatio= n Data Units where the following information is provided for each ADU: " Th= is way the FEC Scheme gets the ordering but we do not have to define any ki= nd of specific index. > 5) page 23 - IMHO it should be mentioned that using the Explicit Source F= EC Payload ID is not backward compatible with non-FEC support receivers, an= d therefore is a disadvantage. I think it should be recommended that if the= re is a way to avoid using the Explicit Source FEC Payload ID appended to t= he end of the source packet, then it should be avoided. >=20 I agree this should be mentioned, but I am not sure we can make a recommend= ation at the level of the Framework. Backwards compatibility considerations= are highly application and even deployment-specific. Even where a well-kno= wn existing protocol is being enhanced with FEC there may not be any equipm= ent deployed in the target environment supporting the existing protocol and= so then backwards compatibility in that case is not a consideration. Exist= ing protocols may also have other compatibility mechanisms (e.g. negotiatio= n) which mean the Explicit Source FEC Payload ID could be used without brea= king backwards compatibility. What I suggest to add is just the following: "In many applications, support for Forward Error Correction is added to a p= re-existing protocol and in this case use of the Explicit Source FEC Payloa= d ID may break backwards compatibility, since source packets are modified." This raises the issue in a suitably innocuous way and lets the reader decid= e how important this point is to them. > 6) typo - page 24, section 6.3.1, second paragraph - "construction source= packets within a gioven source block...." - gioven=3Dgiven. Ok. >=20 > 7) typo - same paragraph - "values in the sequence nmber space..." nmber= =3Dnumber. Ok >=20 > 8) page 25, section 6.5, third paragraph - "...provides FEC protection fo= r all packets of the specified set of Source Data Flows..." - I am not sure= I understand this sentence. Sometimes not all packets of a source flow are= protected (e.g. using mask).=20 >=20 Agreed. I suggest removing the word "all". >=20 > Thanks, > Orly Peck. >=20 >=20 >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Beh= alf Of Orly Peck > Sent: Thursday, January 14, 2010 12:31 PM > To: Magnus Westerlund; fecframe@ietf.org > Subject: Re: [Fecframe] WG Last Call - Framework >=20 > Hi,=20 > I will review the document early next week. > Thanks, > Orly Peck. >=20 > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Beh= alf Of Magnus Westerlund > Sent: Thursday, January 14, 2010 12:15 PM > To: fecframe@ietf.org > Subject: Re: [Fecframe] WG Last Call - Framework >=20 > WG, >=20 > This is one of your core documents. I have seen ONE (1) single comment > that someone has read the document. I do expect to see a bit more > reviews on this before I can consider there be consensus for publication > in the WG. >=20 > Magnus Westerlund >=20 > Greg Shepherd skrev 2009-12-04 16:49: >> Yes, we called LC on this earlier but I received feedback that there >> just wasn't enough time... >>=20 >> So, let's keep the WG LC open with a comment due date pushed out to >> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep >> everyone on task. Please read and respond so we can ship and shut. ;-) >>=20 >> Thanks!, >> Greg >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >=20 >=20 > --=20 >=20 > Magnus Westerlund >=20 > IETF Transport Area Director > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From root@core3.amsl.com Fri Mar 5 15:30:01 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6A4D63A8E4E; Fri, 5 Mar 2010 15:30:01 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100305233001.6A4D63A8E4E@core3.amsl.com> Date: Fri, 5 Mar 2010 15:30:01 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-06.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, 05 Mar 2010 23:30:01 -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 Filename : draft-ietf-fecframe-framework-06.txt Pages : 39 Date : 2010-03-05 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 Forward Error Correction 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 Forward Error Correction 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-06.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-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-05152605.I-D@ietf.org> --NextPart-- From watson@qualcomm.com Fri Mar 5 16:38:04 2010 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 DF64F3A9053 for ; Fri, 5 Mar 2010 16:38:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.149 X-Spam-Level: X-Spam-Status: No, score=-106.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 w6ovtRb-CCxE for ; Fri, 5 Mar 2010 16:38:02 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 7B5723A904F for ; Fri, 5 Mar 2010 16:38:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1267835885; x=1299371885; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20|To:=20" fecframe@ietf.org"=20|Date:=20Fri,=205 =20Mar=202010=2016:37:48=20-0800|Subject:=20draft-ietf-fe cframe-raptor-01|Thread-Topic:=20draft-ietf-fecframe-rapt or-01|Thread-Index:=20Acq8xTrGGfQnHGYdRLu+sPmP6W5WPQ=3D =3D|Message-ID:=20<1640B071-FE28-4FF7-8EA4-391899420552@q ualcomm.com>|References:=20<04CAD96D4C5A3D48B1919248A8FE0 D540AFD8433@xmb-sjc-215.amer.cisco.com>=0D=0A=20=0D=0A=20<04CAD96D4C5A3D48B191 9248A8FE0D540B06A3DC@xmb-sjc-215.amer.cisco.com> |In-Reply-To:=20<04CAD96D4C5A3D48B1919248A8FE0D540B06A3DC @xmb-sjc-215.amer.cisco.com>|Accept-Language:=20en-US |Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"us-ascii" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=aHPqeQj5ZjwWQpzHJmGCMzYFTVchaPdkafMFZfwJSQc=; b=usvUTO2g4KNAQTmlzMF+1QvD2spQogcy7Hf3r6luSoh+7lV6lu3paFAm 36qKnWKN66qxyUVK1lI0rBzW/oZK/l357Q4J972RpP00A+fL3VSrSd+2f o02gsc8/YUN7ppD4MY5r0dEHuwM46YOTanmkOJsZQswx0UAHmcbAlp5gK c=; X-IronPort-AV: E=McAfee;i="5400,1158,5911"; a="35751412" Received: from ironrogue.qualcomm.com ([129.46.61.164]) by wolverine01.qualcomm.com with ESMTP; 05 Mar 2010 16:37:50 -0800 X-IronPort-AV: E=Sophos;i="4.49,587,1262592000"; d="scan'208";a="49248376" Received: from nasanexhub04.qualcomm.com (HELO nasanexhub04.na.qualcomm.com) ([129.46.134.222]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 05 Mar 2010 16:37:50 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub04.na.qualcomm.com (129.46.134.222) with Microsoft SMTP Server (TLS) id 8.2.234.1; Fri, 5 Mar 2010 16:37:42 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Fri, 5 Mar 2010 16:37:42 -0800 From: "Watson, Mark" To: "fecframe@ietf.org" Date: Fri, 5 Mar 2010 16:37:48 -0800 Thread-Topic: draft-ietf-fecframe-raptor-01 Thread-Index: Acq8xTrGGfQnHGYdRLu+sPmP6W5WPQ== Message-ID: <1640B071-FE28-4FF7-8EA4-391899420552@qualcomm.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540AFD8433@xmb-sjc-215.amer.cisco.com> <04CAD96D4C5A3D48B1919248A8FE0D540B06A3DC@xmb-sjc-215.amer.cisco.com> In-Reply-To: <04CAD96D4C5A3D48B1919248A8FE0D540B06A3DC@xmb-sjc-215.amer.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Fecframe] draft-ietf-fecframe-raptor-01 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: Sat, 06 Mar 2010 00:38:04 -0000 All, I received an offline comment on this draft which is that there is now a ne= w version of the Raptor code, named RaptorQ, and it would be trivial to enh= ance this FEC Schemes document to allow both the original Raptor (RFC5053) = and RaptorQ (http://tools.ietf.org/html/draft-ietf-rmt-bb-fec-raptorq-01) t= o be used. So unless there are objections, I propose to do that in the next revision. ...Mark= From orlyp@radvision.com Sun Mar 7 10:35:45 2010 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 923003A9106 for ; Sun, 7 Mar 2010 10:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 55W5+uN6YIKJ for ; Sun, 7 Mar 2010 10:35:43 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id AC1793A8DA0 for ; Sun, 7 Mar 2010 10:35:42 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o27IZF6i025302 for fecframe@ietf.org; Sun, 7 Mar 2010 20:35:15 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o27IZFfB025296 for ; Sun, 7 Mar 2010 20:35:15 +0200 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" Date: Sun, 7 Mar 2010 20:35:37 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-peck-fecframe-rtp-mf-01 Thread-Index: Acq91i1dv54MV5SxRUCGIAxaRdndtQAADqAQ From: "Orly Peck" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by eframer.radvision.com id o27IZFfB025296 Subject: [Fecframe] FW: New Version Notification for draft-peck-fecframe-rtp-mf-01 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: Sun, 07 Mar 2010 18:35:45 -0000 Hi, Please find the updated version for draft-peck-fecframe-rtp-mf-01: http://tools.ietf.org/id/draft-peck-fecframe-rtp-mf-01.txt Any comments will be appreciated. Thanks, Orly Peck. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Sunday, March 07, 2010 11:11 AM To: Orly Peck Subject: New Version Notification for draft-peck-fecframe-rtp-mf-01 A new version of I-D, draft-peck-fecframe-rtp-mf-01.txt has been successfuly submitted by Orly Peck and posted to the IETF repository. Filename: draft-peck-fecframe-rtp-mf Revision: 01 Title: RTP Payload Format for Multi-Flow FEC Creation_date: 2010-03-07 WG ID: Independent Submission Number_of_pages: 16 Abstract: This document defines a new RTP payload format for the Forward Error Correction (FEC) that is used to protect multiple source flows. The format defined by this document enables the protection of multiple media sources encapsulated in RTP with one or more repair flows and is based on the FEC framework (described in [I-D.ietf-fecframe- framework]) and the SDP Elements for FEC Framework (described in [I-D.ietf-fecframe-sdp-elements]). The IETF Secretariat. From watson@qualcomm.com Sun Mar 7 18:23:52 2010 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 7533A3A6837 for ; Sun, 7 Mar 2010 18:23:52 -0800 (PST) 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, 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 LMbaRllCCb5h for ; Sun, 7 Mar 2010 18:23:51 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id D20513A6830 for ; Sun, 7 Mar 2010 18:23:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1268015035; x=1299551035; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20|To:=20C olin=20Perkins=20|CC:=20"fecframe@ietf .org"=20|Date:=20Sun,=207=20Mar=202010 =2018:23:53=20-0800|Subject:=20Re:=20[Fecframe]=20Review =20for=20draft-ietf-fecframe-rtp-raptor-02|Thread-Topic: =20[Fecframe]=20Review=20for=20draft-ietf-fecframe-rtp-ra ptor-02|Thread-Index:=20Acq+Zl3Yaa3iAv5nROuTzzy60YVtDw=3D =3D|Message-ID:=20<6F1C045F-CB94-418E-BA3F-EC888D7494C8@q ualcomm.com>|References:=20<04CAD96D4C5A3D48B1919248A8FE0 D540A843093@xmb-sjc-215.amer.cisco.com>=0D=0A=20|In-Reply-To: =20 |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"us-as cii"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=0J9C+rfezMfwWxf07b/hiZQ1HAlWrCRSaqUtdtt9QJk=; b=r2o+a5esWw0034jwvAp3KKV2fGLbM+PjEuJb5nhBgYAtq6KSSVpIzp2K ZQTZqnh4h9Gr5r9rghdJ8ls8+NCN2BRqeMRVbj7Fc9d705T4mUBb9flxq PpE58xtqGIeDJfb9bp9plU4HNmfYMpYo74M3WbqP42n7M7HfLk0t0/Y8g E=; X-IronPort-AV: E=McAfee;i="5400,1158,5913"; a="35832870" Received: from ironrogue.qualcomm.com ([129.46.61.164]) by wolverine01.qualcomm.com with ESMTP; 07 Mar 2010 18:23:54 -0800 X-IronPort-AV: E=Sophos;i="4.49,598,1262592000"; d="scan'208";a="49723939" Received: from nasanexhub03.na.qualcomm.com ([10.46.93.98]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 07 Mar 2010 18:23:54 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Sun, 7 Mar 2010 18:23:40 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Sun, 7 Mar 2010 18:23:40 -0800 From: "Watson, Mark" To: Colin Perkins Date: Sun, 7 Mar 2010 18:23:53 -0800 Thread-Topic: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02 Thread-Index: Acq+Zl3Yaa3iAv5nROuTzzy60YVtDw== Message-ID: <6F1C045F-CB94-418E-BA3F-EC888D7494C8@qualcomm.com> References: <04CAD96D4C5A3D48B1919248A8FE0D540A843093@xmb-sjc-215.amer.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02 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, 08 Mar 2010 02:23:52 -0000 Colin, Thanks for these comments. Apologies that it has taken rather a while to ge= t back to you on them. Please see my responses inline. Best, Mark On Oct 29, 2009, at 11:26 AM, Colin Perkins wrote: > Hi, >=20 > I have some comments, in addition to those made by Ali. This looks =20 > like a decent initial draft, but does not appear to be ready for =20 > working group last call. >=20 > Section 4.1: what timestamp rate is used? The one specified in the "rate" parameter, which as you point out is mandat= ory ;-) I will clarify this. >=20 > Section 4.3 is empty? This seems to be missing the important content =20 > that describes how the payload format works. >=20 It is not quite empty: the procedures and data formats for generating FEC r= epair streams are fully defined by the combination of the FEC Framework and= an FEC Scheme of your choice. In this case we choose the Raptor FEC Scheme= and define how the repair data is carried over RTP. So there is very littl= e to do in this document other than reference the FEC Framework, the Raptor= FEC Scheme and to state that the Repair Packet Payload defined in those do= cuments becomes the RTP Payload when RTP is used for the repair flow. I can add some text to clarify this point, but one thing I do not want to d= o is duplicate specification material from the FEC Framework or Raptor FEC = Schemes. > Section 6.x: > - The change controller is listed as the AVT working group, but AVT =20 > has never seen this draft. This draft should be presented in AVT and =20 > the WG last call should be copied to the AVT list. Ok. >=20 > - The "rate" is a required parameter for RTP payload formats, but =20 > isn't listed here. Ok. I will add it. >=20 > The offer/answer considerations in Section 8 cannot be "None." if this =20 > is to be used with SDP offer/answer, such as with SIP. This section =20 > needs to specify how the parameters are to be negotiated. Ok. I will add some material on this. >=20 > Section 9: again, this cannot be "None", and needs to specify how the =20 > media parameters are to be used with declarative SDP. Ok. I will add some material on this. >=20 > Section 11 (Security Considerations) is insufficient. At minimum, the =20 > security considerations from the Raptor FECFRAME draft, RFC 3550 and =20 > any applicable RTP profiles apply. See also draft-ietf-avt-rtp-howto-06 >=20 Ok, I will add the references to these documents. Actually in the Raptor FE= CFRAME draft we do not identify any security considerations over and above = those mentioned in the FEC Framework itself. That is, we do not see that th= e choice of Raptor as an FEC code has any specific security issues which do= not apply to the use of FEC in general. >=20 > Colin >=20 >=20 >=20 >=20 >=20 >=20 > On 28 Oct 2009, at 04:59, Ali C. Begen (abegen) wrote: >> Here is the list of my comments for this draft. As I mentioned =20 >> earlier, this draft should be reviewed by AVT as well. >>=20 >> - RFC 3550 needs to be cited in the introduction section and in =20 >> other relevant places. >>=20 >> - Section 3: "... In this case, in the language of the FEC =20 >> Framework, there is no explicit FEC Source Payload Id." --> "... =20 >> there is no (need for) explicit ..." >>=20 >> - Section 4.1, Market bit: I believe "shall" should be "SHALL" in =20 >> this sentence. >>=20 >> - Section 4.1: What about the other fields in the RTP header? If =20 >> there are no specific usage rules, a note saying that RFC 3550 rules =20 >> shall apply should be added. >>=20 >> - Section 4.2 and 4.3: This is the part that needs some work. I =20 >> don't think we can simply refer to the framework and fecframe-raptor =20 >> drafts and leave these parts (which are the most critical sections =20 >> in a payload draft) empty. First of all, why is there a reference to =20 >> the framework draft? Secondly, this section needs to make it clear =20 >> that the payload draft is for the last FEC scheme introduced in the =20 >> fecframe-raptor draft (Section 8). >>=20 >> In the current draft, it says there is no (FEC) payload header. So, =20 >> I guess everything goes into the RTP payload. However, IMO it is =20 >> better to introduce the Repair FEC Payload ID (section 8.1.3 of the =20 >> fecframe-raptor draft) as the FEC payload header, and then put the =20 >> repair symbols as the RTP payload. This makes it a better =20 >> representation and easier for others to visualize the encoding/=20 >> decoding ops. >>=20 >> - Are there any requirements for max-sbl and symbol-size parameters? =20 >> If yes, they must be stated in every subsection of 6.3. >>=20 >> - Search for " definedf" and replace it with " defined". >>=20 >> - Section 5: Are not there any special considerations for Raptor =20 >> FEC? The CC section in the framework is pretty generic IMO. Some =20 >> specific guidelines, if any, would be appropriate to put here. And =20 >> this section should be moved to the end. >>=20 >> - Section 7: The mapping to the SDP parameters should be explained. =20 >> There is a boilerplate for it. Just apply it to your document. >>=20 >> - Section 8 and 9: I am pretty sure there are some offer/answer =20 >> model and declarative SDP considerations. Again, there is a =20 >> boilerplate for it, but it must be modified a little bit to fit to =20 >> the specifics of this payload format. >>=20 >> - Section 10: Before IANA considerations, I was hoping to have a =20 >> section describing the "Protection and Recovery Procedures." The =20 >> protection part explains how the repair packets are constructed. =20 >> This can be kept brief with proper references to the fecframe-raptor =20 >> draft, but there should sufficient text that gives a general idea to =20 >> the readers. For the recovery procedures, they should be detailed =20 >> more since even the other draft does not explain this AFAICT. >>=20 >> - An SDP example showing the RTP format parameters is essential. >>=20 >> - Section 11: There is a boilerplate for security considerations =20 >> section and all RTP payload format drafts use it. That should be =20 >> included here. >>=20 >> HTH, >> -acbegen >=20 >=20 >=20 > --=20 > Colin Perkins > http://csperkins.org/ >=20 >=20 >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From watson@qualcomm.com Sun Mar 7 19:36:58 2010 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 967993A6891 for ; Sun, 7 Mar 2010 19:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.774 X-Spam-Level: X-Spam-Status: No, score=-105.774 tagged_above=-999 required=5 tests=[AWL=-0.375, BAYES_00=-2.599, J_CHICKENPOX_56=0.6, J_CHICKENPOX_65=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 saBZ+r1FGE8G for ; Sun, 7 Mar 2010 19:36:55 -0800 (PST) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 289353A6880 for ; Sun, 7 Mar 2010 19:36:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qualcomm.com; i=watson@qualcomm.com; q=dns/txt; s=qcdkim; t=1268019419; x=1299555419; h=from:to:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version; z=From:=20"Watson,=20Mark"=20|To:=20" fecframe@ietf.org"=20|Date:=20Sun,=207 =20Mar=202010=2019:36:56=20-0800|Subject:=20Re:=20[Fecfra me]=20WG=20Last=20Call=20-=20Framework|Thread-Topic:=20[F ecframe]=20WG=20Last=20Call=20-=20Framework|Thread-Index: =20Acq+cJKB9IiRIxnETLG9KNA3PYAAKg=3D=3D|Message-ID:=20<70 B259F1-EA33-42AA-9CC9-820D2308CEDC@qualcomm.com> |References:=20=0D=0A=20|In-Reply-To:=20|Accept-Language: =20en-US|Content-Language:=20en-US|X-MS-Has-Attach: |X-MS-TNEF-Correlator:|acceptlanguage:=20en-US |Content-Type:=20text/plain=3B=20charset=3D"iso-8859-1" |Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0; bh=M+UWX1+0XSUwrAewGsJf8RtKA2udgn9swP2ewZimIIo=; b=O0pvhiACc8hHl22mKcp5OS611b8u2syU2DY0/Ead0JYrhe1Cd5SBTChc pxiXasvdVynWxnySbclCfaUmZVnbVJT2ZSVlh94SEJuvEnSs966NKTIoV f8/oY8k5H8q7uiMAaufN+aVhvKhfLSOHevZVHvqCOqookzGszwTBpDBe1 c=; X-IronPort-AV: E=McAfee;i="5400,1158,5913"; a="35835428" Received: from ironrogue.qualcomm.com ([129.46.61.164]) by wolverine01.qualcomm.com with ESMTP; 07 Mar 2010 19:36:58 -0800 X-IronPort-AV: E=Sophos;i="4.49,598,1262592000"; d="scan'208";a="49734081" Received: from nasanexhub05.na.qualcomm.com ([129.46.134.219]) by ironrogue.qualcomm.com with ESMTP/TLS/RC4-MD5; 07 Mar 2010 19:36:58 -0800 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanexhub05.na.qualcomm.com (129.46.134.219) with Microsoft SMTP Server (TLS) id 8.2.234.1; Sun, 7 Mar 2010 19:36:45 -0800 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Sun, 7 Mar 2010 19:36:44 -0800 From: "Watson, Mark" To: "fecframe@ietf.org" Date: Sun, 7 Mar 2010 19:36:56 -0800 Thread-Topic: [Fecframe] WG Last Call - Framework Thread-Index: Acq+cJKB9IiRIxnETLG9KNA3PYAAKg== Message-ID: <70B259F1-EA33-42AA-9CC9-820D2308CEDC@qualcomm.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Fecframe] WG Last Call - Framework 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, 08 Mar 2010 03:36:58 -0000 All, In addressing comments on the Raptor FEC Schemes document I found there wer= e some additional changes needed to the framework (specifically related to = text encoding of the FEC Scheme-specific FEC Framework Configuration Inform= ation). So there is a -07 draft for the Framework now. Please ignore the -06. ...Mark On Mar 5, 2010, at 3:05 PM, Watson, Mark wrote: > Orly, >=20 > Thanks for your detailed comments. My responses are below. An -06 draft w= ill be available shortly. >=20 > ...Mark >=20 > On Jan 19, 2010, at 11:28 PM, Orly Peck wrote: >=20 >> Hi, >> Following are my comments for draft-ietf-fecframe-framework-05: >>=20 >> 1) On page 11, last sentence: "a repair packet carried over RTP starts w= ith an RTP header of its own which is immediately followed by parity data..= ." - what about a FEC header that follows the RTP header? >=20 > Good point. I will replace "immediately followed by" with "followed (afte= r the Repair Payload ID) by" >=20 >>=20 >> 2) on page 14 - "a CDP specification MUST define how a receiver determin= es the length of time it should wait to receive FEC repair packets for any = given source blocks".=20 >> Sometimes only the receiver knows how much time it can wait for a FEC re= pair packet due to latency considerations or any other consideration the re= ceiving application may take into account. IMHO the sender can define a MIN= IMUM time that the sender should wait for the repair packet. >=20 > Agreed. If we say "...how a receiver determines a minimum length of time = ..." does that address the issue ?=20 >=20 >>=20 >> 3) typo - on page 22 section 6.2 - "For each sApplication Data Units..."= - remove "s". >=20 > Ok. >=20 >>=20 >> 4) same paragraph - I think that the FEC scheme should (optionally) rec= eive the information of the index of the ADU in the source block (this is i= mportant for FEC codes where order is significant). >>=20 >=20 > Agreed. I re-worded the sentence before the bullet list as "Each Source B= lock provided to the FEC scheme consists of an ordered sequence of Applicat= ion Data Units where the following information is provided for each ADU: " = This way the FEC Scheme gets the ordering but we do not have to define any = kind of specific index. >=20 >> 5) page 23 - IMHO it should be mentioned that using the Explicit Source = FEC Payload ID is not backward compatible with non-FEC support receivers, a= nd therefore is a disadvantage. I think it should be recommended that if th= ere is a way to avoid using the Explicit Source FEC Payload ID appended to = the end of the source packet, then it should be avoided. >>=20 >=20 > I agree this should be mentioned, but I am not sure we can make a recomme= ndation at the level of the Framework. Backwards compatibility consideratio= ns are highly application and even deployment-specific. Even where a well-k= nown existing protocol is being enhanced with FEC there may not be any equi= pment deployed in the target environment supporting the existing protocol a= nd so then backwards compatibility in that case is not a consideration. Exi= sting protocols may also have other compatibility mechanisms (e.g. negotiat= ion) which mean the Explicit Source FEC Payload ID could be used without br= eaking backwards compatibility. What I suggest to add is just the following= : >=20 > "In many applications, support for Forward Error Correction is added to a= pre-existing protocol and in this case use of the Explicit Source FEC Payl= oad ID may break backwards compatibility, since source packets are modified= ." >=20 > This raises the issue in a suitably innocuous way and lets the reader dec= ide how important this point is to them. >=20 >> 6) typo - page 24, section 6.3.1, second paragraph - "construction sourc= e packets within a gioven source block...." - gioven=3Dgiven. >=20 > Ok. >=20 >>=20 >> 7) typo - same paragraph - "values in the sequence nmber space..." nmber= =3Dnumber. >=20 > Ok >=20 >>=20 >> 8) page 25, section 6.5, third paragraph - "...provides FEC protection f= or all packets of the specified set of Source Data Flows..." - I am not sur= e I understand this sentence. Sometimes not all packets of a source flow ar= e protected (e.g. using mask).=20 >>=20 >=20 > Agreed. I suggest removing the word "all". >=20 >>=20 >> Thanks, >> Orly Peck. >>=20 >>=20 >>=20 >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half Of Orly Peck >> Sent: Thursday, January 14, 2010 12:31 PM >> To: Magnus Westerlund; fecframe@ietf.org >> Subject: Re: [Fecframe] WG Last Call - Framework >>=20 >> Hi,=20 >> I will review the document early next week. >> Thanks, >> Orly Peck. >>=20 >> -----Original Message----- >> From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On Be= half Of Magnus Westerlund >> Sent: Thursday, January 14, 2010 12:15 PM >> To: fecframe@ietf.org >> Subject: Re: [Fecframe] WG Last Call - Framework >>=20 >> WG, >>=20 >> This is one of your core documents. I have seen ONE (1) single comment >> that someone has read the document. I do expect to see a bit more >> reviews on this before I can consider there be consensus for publication >> in the WG. >>=20 >> Magnus Westerlund >>=20 >> Greg Shepherd skrev 2009-12-04 16:49: >>> Yes, we called LC on this earlier but I received feedback that there >>> just wasn't enough time... >>>=20 >>> So, let's keep the WG LC open with a comment due date pushed out to >>> Jan 8th to allow for the Holidays. I'll send weekly reminders to keep >>> everyone on task. Please read and respond so we can ship and shut. ;-) >>>=20 >>> Thanks!, >>> Greg >>> _______________________________________________ >>> Fecframe mailing list >>> Fecframe@ietf.org >>> https://www.ietf.org/mailman/listinfo/fecframe >>>=20 >>=20 >>=20 >> --=20 >>=20 >> Magnus Westerlund >>=20 >> IETF Transport Area Director >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=E4r=F6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >>=20 >> _______________________________________________ >> Fecframe mailing list >> Fecframe@ietf.org >> https://www.ietf.org/mailman/listinfo/fecframe >=20 > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From root@core3.amsl.com Sun Mar 7 19:45:02 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 289CE3A6881; Sun, 7 Mar 2010 19:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308034502.289CE3A6881@core3.amsl.com> Date: Sun, 7 Mar 2010 19:45:02 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-framework-07.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: Mon, 08 Mar 2010 03:45:02 -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 Filename : draft-ietf-fecframe-framework-07.txt Pages : 40 Date : 2010-03-07 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 Forward Error Correction 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 Forward Error Correction 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-07.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-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-07193133.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Mar 7 19:45:02 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3B7253A6887; Sun, 7 Mar 2010 19:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308034502.3B7253A6887@core3.amsl.com> Date: Sun, 7 Mar 2010 19:45:02 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-raptor-02.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: Mon, 08 Mar 2010 03:45:02 -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 : Raptor FEC Schemes for FECFRAME Author(s) : M. Watson Filename : draft-ietf-fecframe-raptor-02.txt Pages : 21 Date : 2010-03-07 This document describes Fully-Specified Forward Error Correction (FEC) Schemes for the Raptor and RaptorQ codes and their application to reliable delivery of media streams in the context of FEC Framework. The Raptor and RaptorQ codes are systematic codes, where a number of repair symbols are generated from a set of source symbols and sent in one or more repair flows in addition to the source symbols that are sent to the receiver(s) within a source flow. The Raptor and RaptorQ codes offer close to optimal protection against arbitrary packet losses at a low computational complexity. Six FEC Schemes are defined, two for protection of arbitrary packet flows, two that are optimised for small source blocks and another two for protection of a single flow that already contains a sequence number. Repair data may be sent over arbitrary datagram transport (e.g. UDP) or using RTP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-raptor-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-fecframe-raptor-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-07193136.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Mar 7 19:45:02 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 404283A67D9; Sun, 7 Mar 2010 19:45:02 -0800 (PST) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100308034502.404283A67D9@core3.amsl.com> Date: Sun, 7 Mar 2010 19:45:02 -0800 (PST) Cc: fecframe@ietf.org Subject: [Fecframe] I-D Action:draft-ietf-fecframe-rtp-raptor-03.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: Mon, 08 Mar 2010 03:45:02 -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 : RTP Payload Format for Raptor FEC Author(s) : M. Watson Filename : draft-ietf-fecframe-rtp-raptor-03.txt Pages : 21 Date : 2010-03-07 This document specifies an RTP Payload Format for Forward Error Correction 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. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-fecframe-rtp-raptor-03.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-rtp-raptor-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-03-07193140.I-D@ietf.org> --NextPart-- From orlyp@radvision.com Mon Mar 8 12:20:44 2010 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 AE2B23A69C6 for ; Mon, 8 Mar 2010 12:20:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0vc6iJDy82jQ for ; Mon, 8 Mar 2010 12:20:34 -0800 (PST) Received: from eframer.radvision.com (rvil-eframer.radvision.com [80.74.106.104]) by core3.amsl.com (Postfix) with ESMTP id 6FC3D3A6991 for ; Mon, 8 Mar 2010 12:20:33 -0800 (PST) Received: (from root@localhost) by eframer.radvision.com (8.13.4/8.12.9) id o28KKAbQ018173 for fecframe@ietf.org; Mon, 8 Mar 2010 22:20:10 +0200 Received: from rvil-mail1.RADVISION.com (rvil-mail1.radvision.com [172.20.2.100]) by eframer.radvision.com (8.13.4/8.12.9) with ESMTP id o28KKAj6018167 for ; Mon, 8 Mar 2010 22:20:10 +0200 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" Date: Mon, 8 Mar 2010 22:20:33 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-galanos-fecframe-rtp-reedsolomon-01 Thread-Index: Acq+4nnwGP2BzehYR1yZfP+BRjIByAAGixpQ From: "Orly Peck" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by eframer.radvision.com id o28KKAj6018167 Subject: [Fecframe] FW: New Version Notification for draft-galanos-fecframe-rtp-reedsolomon-01 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, 08 Mar 2010 20:20:44 -0000 Hi, Please find the updated version for draft-galanos-fecframe-rtp-reedsolomon-01: http://tools.ietf.org/id/draft-galanos-fecframe-rtp-reedsolomon-01.txt Any comments will be appreciated. Thanks, Orly Peck. -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, March 08, 2010 7:12 PM To: Orly Peck Cc: Sarit Galanos; vincent.roca@inria.fr Subject: New Version Notification for draft-galanos-fecframe-rtp-reedsolomon-01 A new version of I-D, draft-galanos-fecframe-rtp-reedsolomon-01.txt has been successfuly submitted by Orly Peck and posted to the IETF repository. Filename: draft-galanos-fecframe-rtp-reedsolomon Revision: 01 Title: RTP Payload Format for Reed Solomon FEC Creation_date: 2010-03-08 WG ID: Independent Submission Number_of_pages: 28 Abstract: This document defines an RTP payload format for the Forward Error Correction (FEC) that uses Reed-Solomon codes. 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 (described in [I-D.ietf-fecframe-framework]) and the SDP Elements for FEC Framework (described in [I-D.ietf-fecframe-sdp-elements]). The Reed-Solomon codes used in this document belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against random and bursty packet losses. The IETF Secretariat. From vincent.roca@inrialpes.fr Mon Mar 8 12:42:04 2010 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 976253A69AB for ; Mon, 8 Mar 2010 12:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 1iX7z7OYZVyz for ; Mon, 8 Mar 2010 12:42:03 -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 167DF3A69A7 for ; Mon, 8 Mar 2010 12:42:02 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.49,604,1262559600"; d="scan'208,217";a="46185667" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO macbook-pro-de-roca.local) ([82.236.155.50]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 08 Mar 2010 21:42:04 +0100 Message-ID: <4B956118.5090006@inrialpes.fr> Date: Mon, 08 Mar 2010 21:42:00 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.7) Gecko/20100111 Thunderbird/3.0.1 MIME-Version: 1.0 To: fecframe@ietf.org Content-Type: multipart/alternative; boundary="------------050607080909050308080201" Cc: =?UTF-8?B?SsOpcsO0bWUgTGFjYW4=?= Subject: [Fecframe] Fwd: New Version Notification for draft-roca-fecframe-rs-02 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, 08 Mar 2010 20:42:04 -0000 This is a multi-part message in MIME format. --------------050607080909050308080201 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hello everybody, Here is an update of our I-D on the use of Reed-Solomon codes in the context of fecframe: https://datatracker.ietf.org/doc/draft-roca-fecframe-rs/ Cheers, Vincent -------- Message original -------- Sujet: New Version Notification for draft-roca-fecframe-rs-02 Date : Mon, 8 Mar 2010 08:43:00 -0800 (PST) De : IETF I-D Submission Tool Pour : vincent.roca@inria.fr Copie à : Amine.Bouabdallah@isae.fr,kazuhisa@sfc.wide.ad.jp,jerome.lacan@isae.fr,mathieu.cunche@inria.fr A new version of I-D, draft-roca-fecframe-rs-02.txt has been successfuly submitted by Vincent Roca and posted to the IETF repository. Filename: draft-roca-fecframe-rs Revision: 02 Title: Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME Creation_date: 2010-03-08 WG ID: Independent Submission Number_of_pages: 20 Abstract: This document describes two fully-specified FEC schemes for Reed- Solomon codes that can be used to protect 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 sparse parity check based FEC codes. However, this complexity remains compatible with software codecs. The first scheme is for Reed-Solomon codes over GF(2^^m), with m in {2..16}, a simple FEC encoding and arbitrary packet flows. The second scheme is similar to the first scheme, with the exception that it is for a single sequenced flow. The IETF Secretariat. --------------050607080909050308080201 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hello everybody,

Here is an update of our I-D on the use of Reed-Solomon codes in the
context of fecframe:
    https://datatracker.ietf.org/doc/draft-roca-fecframe-rs/
Cheers,

   Vincent

-------- Message original --------
Sujet: New Version Notification for draft-roca-fecframe-rs-02
Date : Mon, 8 Mar 2010 08:43:00 -0800 (PST)
De : IETF I-D Submission Tool <idsubmission@ietf.org>
Pour : vincent.roca@inria.fr
Copie à : Amine.Bouabdallah@isae.fr,kazuhisa@sfc.wide.ad.jp,jerome.lacan@isae.fr,mathieu.cunche@inria.fr 


A new version of I-D, draft-roca-fecframe-rs-02.txt has been successfuly submitted by Vincent Roca and posted to the IETF repository.

Filename:	 draft-roca-fecframe-rs
Revision:	 02
Title:		 Reed-Solomon Forward Error Correction (FEC) Schemes for FECFRAME
Creation_date:	 2010-03-08
WG ID:		 Independent Submission
Number_of_pages: 20

Abstract:
This document describes two fully-specified FEC schemes for Reed-
Solomon codes that can be used to protect 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 sparse parity check
based FEC codes.  However, this complexity remains compatible with
software codecs.

The first scheme is for Reed-Solomon codes over GF(2^^m), with m in
{2..16}, a simple FEC encoding and arbitrary packet flows.  The
second scheme is similar to the first scheme, with the exception that
it is for a single sequenced flow.
                                                                                  


The IETF Secretariat.
--------------050607080909050308080201-- From gjshep@gmail.com Tue Mar 9 21:41:20 2010 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 B17FE3A6850 for ; Tue, 9 Mar 2010 21:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+7mpgZjBfeW for ; Tue, 9 Mar 2010 21:41:19 -0800 (PST) Received: from mail-iw0-f180.google.com (mail-iw0-f180.google.com [209.85.223.180]) by core3.amsl.com (Postfix) with ESMTP id A5E0F3A6846 for ; Tue, 9 Mar 2010 21:41:19 -0800 (PST) Received: by iwn10 with SMTP id 10so1665404iwn.31 for ; Tue, 09 Mar 2010 21:41:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=bWXRh+FKU9In9kKjiAI8lqRoiPko7iQbJn5qFCUZBqE=; b=it0uewUKFAVQerXjgwiVfpNkaiS/awXfTRQslIwBkWRXlttvSnyf1iLRqUj3lCfBr5 WeUe3BZnveD2fn3NlUVnIaBhdq9C++KajGVPDQUeUFIhkqJyc3MrCFDyTbbjqVuLoQAd xJpR69pF/hDBuPcjlkJ9VHHKEWlqIp+L5M1pk= 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=ZkqLEX1iRa146299Q3W/y2B4dY3CXm7hAv7xmjanZPsCJab/Jne/yUdAKOUavI/bEY ADEpTrHP2+atkEoLm7omPGvc/staWsmeOQTqaT1MWVy2789bqpwNCGY1CPTnL/Etqgcp md/vD73Z1dIN2PqEv21m2AhoUg0OgsNCGErPs= MIME-Version: 1.0 Received: by 10.231.158.195 with SMTP id g3mr243942ibx.46.1268199681072; Tue, 09 Mar 2010 21:41:21 -0800 (PST) Date: Tue, 9 Mar 2010 21:41:21 -0800 Message-ID: <38c19b541003092141m183a426eh8606b29f843ec430@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] Upcoming Agenda 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, 10 Mar 2010 05:41:20 -0000 Below is the current list of updated drafts. Can you please let me know soon if you'll be at the WG meeting to present. Orly Peck draft-peck-fecframe-rtp-mf-01 draft-galanos-fecframe-rtp-reedsolomon-01 Mark Watson Framework draft-ietf-fecframe-rtp-raptor draft-roca-fecframe-rs Vincent Roca draft-roca-fecframe-rs Rajiv Asati draft-ietf-fecframe-config-signaling Pierre Roux draft-roux-fecframe-repacketization-00.txt Ali Begen draft-ietf-fecframe-interleaved-fec-scheme-09.txt Thanks, Greg From rajiva@cisco.com Wed Mar 10 04:34:28 2010 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 1E7D23A6912 for ; Wed, 10 Mar 2010 04:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] 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 GRQStMuroGEx for ; Wed, 10 Mar 2010 04:34:27 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id DB1F43A6911 for ; Wed, 10 Mar 2010 04:34:25 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EABkgl0utJV2Z/2dsb2JhbACbBQJzoymYUIR5BIMXiA4 X-IronPort-AV: E=Sophos;i="4.49,613,1262563200"; d="scan'208";a="494542106" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by sj-iport-6.cisco.com with ESMTP; 10 Mar 2010 12:34:30 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id o2ACYUn8008654; Wed, 10 Mar 2010 12:34:30 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 10 Mar 2010 06:34:30 -0600 Received: from 128.107.191.87 ([128.107.191.87]) by XMB-RCD-111.cisco.com ([72.163.62.153]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Mar 2010 12:34:30 +0000 References: <38c19b541003092141m183a426eh8606b29f843ec430@mail.gmail.com> Message-ID: <72E7CFD1-451C-45D7-9042-D3EDEAE452BB@cisco.com> Thread-Topic: [Fecframe] Upcoming Agenda From: "Rajiv Asati (rajiva)" Thread-Index: AcrATgfAs2Rpeq5xT46eVcU6V1S4tA== To: In-Reply-To: <38c19b541003092141m183a426eh8606b29f843ec430@mail.gmail.com> Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit MIME-Version: 1.0 (iPhone Mail 7E18) Date: Wed, 10 Mar 2010 07:34:28 -0500 X-OriginalArrivalTime: 10 Mar 2010 12:34:30.0969 (UTC) FILETIME=[081EAA90:01CAC04E] Cc: fecframe@ietf.org Subject: Re: [Fecframe] Upcoming Agenda 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, 10 Mar 2010 12:34:28 -0000 Hi Greg, I won't be attending the meeting. Could I present remotely? Cheers, Rajiv Sent from my Phone On Mar 10, 2010, at 12:41 AM, "Greg Shepherd" wrote: > Below is the current list of updated drafts. Can you please let me > know soon if you'll be at the WG meeting to present. > > Orly Peck > draft-peck-fecframe-rtp-mf-01 > draft-galanos-fecframe-rtp-reedsolomon-01 > > Mark Watson > Framework > draft-ietf-fecframe-rtp-raptor > draft-roca-fecframe-rs > > Vincent Roca > draft-roca-fecframe-rs > > Rajiv Asati > draft-ietf-fecframe-config-signaling > > Pierre Roux > draft-roux-fecframe-repacketization-00.txt > > Ali Begen > draft-ietf-fecframe-interleaved-fec-scheme-09.txt > > Thanks, > Greg > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From gjshep@gmail.com Fri Mar 12 10:35:26 2010 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 A24823A6821 for ; Fri, 12 Mar 2010 10:35:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11] 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 pO1U6BjI+iZ8 for ; Fri, 12 Mar 2010 10:35:25 -0800 (PST) Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by core3.amsl.com (Postfix) with ESMTP id AB0153A689D for ; Fri, 12 Mar 2010 10:35:20 -0800 (PST) Received: by iwn16 with SMTP id 16so365910iwn.31 for ; Fri, 12 Mar 2010 10:35:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=naH5v10yP9nY5sxrXcBL8zi/3Lt4xP8nQQ1i8I11LZQ=; b=RKA2aBb60E8JUhOxm9JMkF4/kvPfH3Rno6NmisbMELPHezJO0QYY38faepUwjjnqQ3 NryMmATboCLWgdbqp3gBLr/sqEmGRxGTGfweLOkjRh7ymY1R0dssBHNyHcRsMCk5Sa/5 ZF/YSnKf/VVCIJ8cIX3wXgDjNXS7ou2ZN5yZ8= 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=stDCeZkPxff12E6kg0RzWOHB5l1cuZEpndpactZOzm8U6bNa7kHU1SXLf0gbjTVtRX WruHBMEQFa6dMpuBb7S/iTvahgPbDA77GEDBZH4sgdNAiANY9EDKWFywgGJZ8d+Hf3vd bTOLduVCuuTmlinRUttqJktdunaXeMToo6Ckg= MIME-Version: 1.0 Received: by 10.231.146.74 with SMTP id g10mr13265ibv.98.1268418924136; Fri, 12 Mar 2010 10:35:24 -0800 (PST) Date: Fri, 12 Mar 2010 10:35:24 -0800 Message-ID: <38c19b541003121035v3f139beaof787464121b48550@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] WG Agenda, IETF 77 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, 12 Mar 2010 18:35:26 -0000 Please review the agenda below and let me know if there are any changes. Thanks!, Greg FECFrame WG Agenda IETF 77, Anaheim California Tuesday, March 23, 1520-1720 Huntington Intro / Agenda bash Greg Shepherd 10min Framework Update draft-ietf-fecframe-rtp-raptor draft-roca-fecframe-rs Mark Watson 30min draft-peck-fecframe-rtp-mf-01 draft-galanos-fecframe-rtp-reedsolomon-01 Orly Peck 20min draft-roca-fecframe-rs Greg Shepherd for Vincent Roca 10min draft-ietf-fecframe-config-signaling Greg Shepherd for Rajiv Asati 10min draft-roux-fecframe-repacketization-00.txt Greg Shepherd for Pierre Roux 10min From vincent.roca@inrialpes.fr Mon Mar 15 06:51:46 2010 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 846413A682A for ; Mon, 15 Mar 2010 06:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.504 X-Spam-Level: X-Spam-Status: No, score=-5.504 tagged_above=-999 required=5 tests=[AWL=-0.745, BAYES_05=-1.11, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 u5aj9Gz74U4G for ; Mon, 15 Mar 2010 06:51:45 -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 1576E3A67AC for ; Mon, 15 Mar 2010 06:51:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.49,643,1262559600"; d="scan'208,217";a="46897859" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Mar 2010 14:51:50 +0100 Message-ID: <4B9E3B75.7040202@inrialpes.fr> Date: Mon, 15 Mar 2010 14:51:49 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100225 Fedora/3.0.2-1.fc12 Thunderbird/3.0.2 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: "Luby, Michael" , "Watson, Mark" References: <4AAE5330.1090403@inrialpes.fr> In-Reply-To: <4AAE5330.1090403@inrialpes.fr> Content-Type: multipart/alternative; boundary="------------080706070400040204000606" Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] [Fwd: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-01] 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, 15 Mar 2010 13:51:46 -0000 This is a multi-part message in MIME format. --------------080706070400040204000606 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Mike, ---- Hi Vincent, Indeed, quite fresh news. See United States Patent 7,660,245, which was issued on February 9, 2010. Our IPR statements will be updated to reflect this at some point in the near future. Best, Mike --- Thanks a lot for having clarified this issue. As you probably saw, we have updated our I-D in order to take it into account. Could you please tell us if it solves the problem according to you? Thanks! Regards, Vincent, on behalf of the authors. On 14/09/2009 16:29, Vincent Roca wrote: > Hello everybody, > > I am forwarding the IPR disclosure we received last week to the > fecframe mailing list, so that everybody be aware of the situation. > > > Concerning the IPR disclosure now... > > > Mike and Mark, > > After looking at the disclosure, I see that the disclosure relates > to an "unpublished pending patent application". > Indeed, a search on various dedicated sites did not enable me to > retrieve any document. > > Since I do want to understand your concern, could you please answer > to the following questions: > > - Do I understand the situation correctly? > > - Do you plan to provide the above document(s) to the fecframe WG > or to the authors, even if they are not published? > > - If not, do you plan to indicate which part(s) of our I-D is covered > according to you, and why? > > Thanks in advance. > Cheers, > > Vincent > > > > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe --------------080706070400040204000606 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Mike,

----
Hi Vincent,
Indeed, quite fresh news.  See United States Patent 7,660,245, which was issued on February 9, 2010.  Our IPR statements will be updated to reflect this at some point in the near future.
Best, Mike
---

Thanks a lot for having clarified this issue.
As you probably saw, we have updated our I-D in order to take
it into account. Could you please tell us if it solves the problem
according to you? Thanks!

Regards,


   Vincent, on behalf of the authors.


On 14/09/2009 16:29, Vincent Roca wrote: 
Hello everybody,

I am forwarding the IPR disclosure we received last week to the
fecframe mailing list, so that everybody be aware of the situation.


Concerning the IPR disclosure now...


Mike and Mark,

After looking at the disclosure, I see that the disclosure relates
to an "unpublished pending patent application".
Indeed, a search on various dedicated sites did not enable me to
retrieve any document.

Since I do want to understand your concern, could you please answer
to the following questions:

- Do I understand the situation correctly?

- Do you plan to provide the above document(s) to the fecframe WG
  or to the authors, even if they are not published?

- If not, do you plan to indicate which part(s) of our I-D is covered
  according to you, and why?

Thanks in advance.
Cheers,

   Vincent
  

_______________________________________________
Fecframe mailing list
Fecframe@ietf.org
https://www.ietf.org/mailman/listinfo/fecframe

--------------080706070400040204000606-- From vincent.roca@inrialpes.fr Mon Mar 15 07:58:52 2010 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 294943A6B69 for ; Mon, 15 Mar 2010 07:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.877 X-Spam-Level: X-Spam-Status: No, score=-5.877 tagged_above=-999 required=5 tests=[AWL=0.373, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 8tgcaHkISzXJ for ; Mon, 15 Mar 2010 07:58:51 -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 A4C923A685B for ; Mon, 15 Mar 2010 07:58:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.49,643,1262559600"; d="scan'208";a="46902859" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 15 Mar 2010 15:58:50 +0100 Message-ID: <4B9E4B2A.8090302@inrialpes.fr> Date: Mon, 15 Mar 2010 15:58:50 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100225 Fedora/3.0.2-1.fc12 Thunderbird/3.0.2 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: "fecframe@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Luby, Michael" Subject: [Fecframe] Concerning Qualcomm's US Patent 7,660,245 and 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: Mon, 15 Mar 2010 14:58:52 -0000 Hello Everybody, *FYI and in order to comply with RFC 3979's rules concerning IPR* To the question of possible patents that could apply to the FECFRAME framework, Mark Watson answered in a private email in March 2009 that no patent from Qualcomm apply to the current draft-ietf-fecframe-framework. So there's no problem. However... Let's imagine: - you want to protect source packets coming from a streaming application; - you create FEC source packets, as in FECFRAME; - you have a system that segments the various source packets into a *potentially different* number of source symbols (e.g. because source packets have significantly different sizes); - you perform FEC encoding from this source block and produce repair symbols; - and you generate one or more FEC repair packets from these repair symbols, as in FECFRAME; ... then you'd better have a look to Qualcomm's US Patent 7,660,245 (e.g. Claim 1): http://www.freepatentsonline.com/7660245.pdf This patent has been published in February 2010 and was previously an "unpublished pending patent", so I only discovered it after Mike's clarification a few weeks ago. With that in mind, if I read draft-ietf-fecframe-framework once again, I now understand why Section 6.2. "Structure of the source block" does not go into details. Admittedly the way the source block is created is FEC Scheme specific (I fully agree), but it's clearly not the only reason. Mike/Mark, is my understanding of the situation correct? Regards, Vincent From luby@qualcomm.com Thu Mar 18 12:33:11 2010 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 D53403A69B2 for ; Thu, 18 Mar 2010 12:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.868 X-Spam-Level: X-Spam-Status: No, score=-102.868 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 Yt2duDLO+h2e for ; Thu, 18 Mar 2010 12:33:10 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 68E793A6972 for ; Thu, 18 Mar 2010 12:33:07 -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=1268940799; x=1300476799; 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:acceptlanguage: content-type:mime-version; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20"fecframe@i etf.org"=0D=0A=09|CC:=20"Watson,=20Mar k"=20,=20"Luby,=20Michael"=20|Date:=20Thu,=2018=20Mar=202010=2012:33:17=20 -0700|Subject:=20Re:=20Concerning=20Qualcomm's=20US=20Pat ent=207,660,245=20and=20FECFRAME|Thread-Topic:=20Concerni ng=20Qualcomm's=20US=20Patent=207,660,245=20and=20FECFRAM E|Thread-Index:=20AcrET/LWwalnVufIRHanQFcXStoJFwCgejey |Message-ID:=20 |In-Reply-To:=20<4B9E4B2A.8090302@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C7C7CE0DC92Clubyqualcommcom_" |MIME-Version:=201.0; bh=U1F94LEJTS0aLL0eXtIc6EFT7Qc+Kgk6gFpMUYPu2Y4=; b=MFh6OeOAQbDkkb2SZdicGE+avQfuKLhYde8XI0S9jULFS90PIgnb4lgq IcBFxD+Jq2j0XmGDPhmrpZhF9vV/Rc8JGU4CMx6gjvH7tJGZU9l5PlOtM X/jnsmQT+8jZ4//khfOmHA665d97AoQLV5yuuoKW+Q7CxfoIEgVWSFNUm Q=; X-IronPort-AV: E=McAfee;i="5400,1158,5924"; a="36732222" Received: from ironstorm.qualcomm.com ([172.30.39.153]) by wolverine01.qualcomm.com with ESMTP; 18 Mar 2010 12:33:19 -0700 X-IronPort-AV: E=Sophos;i="4.51,267,1267430400"; d="scan'208,217";a="54633171" Received: from unknown (HELO nasanexhub03.na.qualcomm.com) ([10.46.93.98]) by ironstorm.qualcomm.com with ESMTP/TLS/RC4-MD5; 18 Mar 2010 12:33:19 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub03.na.qualcomm.com (10.46.93.98) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 18 Mar 2010 12:32:33 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 18 Mar 2010 12:32:33 -0700 From: "Luby, Michael" To: Vincent Roca , "fecframe@ietf.org" Date: Thu, 18 Mar 2010 12:33:17 -0700 Thread-Topic: Concerning Qualcomm's US Patent 7,660,245 and FECFRAME Thread-Index: AcrET/LWwalnVufIRHanQFcXStoJFwCgejey Message-ID: In-Reply-To: <4B9E4B2A.8090302@inrialpes.fr> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7C7CE0DC92Clubyqualcommcom_" MIME-Version: 1.0 Subject: Re: [Fecframe] Concerning Qualcomm's US Patent 7, 660, 245 and 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: Thu, 18 Mar 2010 19:33:11 -0000 --_000_C7C7CE0DC92Clubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Vincent, In the original individual submission of the FECFRAME framework document (d= raft-watson-tsvwg-fec-sf-00) there was some Digital Fountain/Qualcomm IPR (= and we declared this at the time). As you might recall, there was pressure= in the FECFRAME group to remove known IPR from the FECFRAME framework docu= ment, and to make the FECFRAME framework document more of a high level docu= ment without FEC-scheme specific details. When the FECFRAME framework docu= ment was rewritten and submitted as a working group document, certain FEC-s= cheme specific details were removed, some of which involved Digital Fountai= n/Qualcomm IPR, one of which you have identified below, and as a consequenc= e there is no longer any Digital Fountain/Qualcomm IPR that is or will be d= eclared on the current FECFRAME framework document. Regards, Mike On 3/15/10 7:58 AM, "Vincent Roca" wrote: Hello Everybody, *FYI and in order to comply with RFC 3979's rules concerning IPR* To the question of possible patents that could apply to the FECFRAME framework, Mark Watson answered in a private email in March 2009 that no patent from Qualcomm apply to the current draft-ietf-fecframe-framework. So there's no problem. However... Let's imagine: - you want to protect source packets coming from a streaming application= ; - you create FEC source packets, as in FECFRAME; - you have a system that segments the various source packets into a *potentially different* number of source symbols (e.g. because source packets have significantly different sizes); - you perform FEC encoding from this source block and produce repair symbols; - and you generate one or more FEC repair packets from these repair symbols, as in FECFRAME; ... then you'd better have a look to Qualcomm's US Patent 7,660,245 (e.g. Claim 1): http://www.freepatentsonline.com/7660245.pdf This patent has been published in February 2010 and was previously an "unpublished pending patent", so I only discovered it after Mike's clarification a few weeks ago. With that in mind, if I read draft-ietf-fecframe-framework once again, I now understand why Section 6.2. "Structure of the source block" does not go into details. Admittedly the way the source block is created is FEC Scheme specific (I fully agree), but it's clearly not the only reason. Mike/Mark, is my understanding of the situation correct? Regards, Vincent --_000_C7C7CE0DC92Clubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Concerning Qualcomm's US Patent 7,660,245 and FECFRAME Hi Vincent,
In the original individual submission of the FECFRAME framework document (d= raft-watson-tsvwg-fec-sf-00) there was some Digital Fountain/Qualcomm IPR (= and we declared this at the time).  As you might recall, there was pre= ssure in the FECFRAME group to remove known IPR from the FECFRAME framework= document, and to make the FECFRAME framework document more of a high level= document without FEC-scheme specific details.  When the FECFRAME fram= ework document was rewritten and submitted as a working group document, cer= tain FEC-scheme specific details were removed, some of which involved Digit= al Fountain/Qualcomm IPR, one of which you have identified below, and as a = consequence there is no longer any Digital Fountain/Qualcomm IPR that is or= will be declared on the current FECFRAME framework document.
Regards, Mike



On 3/15/10 7:58 AM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:

Hello Everybody,


*FYI and in order to comply with RFC 3979's rules concerning IPR*

To the question of possible patents that could apply to the FECFRAME
framework, Mark Watson answered in a private email in March 2009 that
no patent from Qualcomm apply to the current draft-ietf-fecframe-framework.=
So there's no problem.

However...

Let's imagine:
   - you want to protect source packets coming from a stream= ing application;
   - you create FEC source packets, as in FECFRAME;
   - you have a system that segments the various source pack= ets into a
     *potentially different* number of source symb= ols (e.g. because source
     packets have significantly different sizes);<= BR>    - you perform FEC encoding from this source block and pro= duce repair
     symbols;
   - and you generate one or more FEC repair packets from th= ese repair
     symbols, as in FECFRAME;

... then you'd better have a look to Qualcomm's US Patent 7,660,245
(e.g. Claim 1):
     http://www.freepatentsonline.com/7660245.pdf

This patent has been published in February 2010 and was previously an
"unpublished pending patent", so I only discovered it after Mike'= s
clarification a few weeks ago.

With that in mind, if I read draft-ietf-fecframe-framework once again,
I now understand why Section 6.2. "Structure of the source block"= does
not go into details. Admittedly the way the source block is created is FEC<= BR> Scheme specific (I fully agree), but it's clearly not the only reason.

Mike/Mark, is my understanding of the situation correct?


Regards,


     Vincent

--_000_C7C7CE0DC92Clubyqualcommcom_-- From wwwrun@core3.amsl.com Thu Mar 25 10:08:47 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6BFAA3A6E05; Thu, 25 Mar 2010 10:08:47 -0700 (PDT) To: watson@qualcomm.com From: IETF Secretariat Message-Id: <20100325170847.6BFAA3A6E05@core3.amsl.com> Date: Thu, 25 Mar 2010 10:08:47 -0700 (PDT) Cc: fecframe@ietf.org, ipr-announce@ietf.org Subject: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-02 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: Thu, 25 Mar 2010 17:08:47 -0000 Dear 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 2010-03-18 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1290/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-raptor-02." The IETF Secretariat From wwwrun@core3.amsl.com Thu Mar 25 10:08:59 2010 Return-Path: X-Original-To: fecframe@ietf.org Delivered-To: fecframe@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6E7FA3A6C02; Thu, 25 Mar 2010 10:08:59 -0700 (PDT) To: abegen@cisco.com,stockhammer@nomor.de From: IETF Secretariat Message-Id: <20100325170859.6E7FA3A6C02@core3.amsl.com> Date: Thu, 25 Mar 2010 10:08:59 -0700 (PDT) Cc: fecframe@ietf.org, ipr-announce@ietf.org Subject: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-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: Thu, 25 Mar 2010 17:08:59 -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 2010-03-18 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1291/). The title of the IPR disclosure is "QUALCOMM Incorporated's Statement about IPR related to draft-ietf-fecframe-dvb-al-fec-04." The IETF Secretariat From gjshep@gmail.com Thu Mar 25 10:34:54 2010 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 C4C0C3A6E68 for ; Thu, 25 Mar 2010 10:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] 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 gMEjNWtsKs00 for ; Thu, 25 Mar 2010 10:34:54 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 687263A6EA8 for ; Thu, 25 Mar 2010 10:28:46 -0700 (PDT) Received: by pvh1 with SMTP id 1so4316269pvh.31 for ; Thu, 25 Mar 2010 10:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:date:message-id :subject:from:to:content-type; bh=PL9a0DvcIsnxj65gRaIbTw2rmFalZF5HWGqmVjch5cg=; b=ANB2akIL6eNAptVuEq5qSI/3ydfJ6kUa1VpCboqxc//OJym1fQ0EtoI/NsA94LEEJ8 0ZhfjQOJy1egEOkG+chnME6pdlPpmezNkxA9ms7RgjZ3h20r3Tc2ri1bxLPe5c3+xqFS 1vfynH3IlwyQMpSb2+GVNzmXQhr/0eb8pM0x8= 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=W0TTFCMPVEjDNNNpfKapFHxmaqyZRq/6CKQ8sbQ3eXqzeeIUdnQssUCyMemz7LAIqW pvr+nVmj18VPIlJCbERj7sco88hlp42kNg9+x7y7HRFcR5QWIV7Md/Rx7krgnpR6c+2b IXEWxYL8xGamy/12i4fBLOPDpI3APkexNUmEI= MIME-Version: 1.0 Received: by 10.115.113.22 with SMTP id q22mr6932097wam.62.1269538145853; Thu, 25 Mar 2010 10:29:05 -0700 (PDT) Date: Thu, 25 Mar 2010 10:29:05 -0700 Message-ID: <38c19b541003251029h6c9702eew12b6d4f80281f6b2@mail.gmail.com> From: Greg Shepherd To: fecframe@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Fecframe] IETF 77 Minutes 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, 25 Mar 2010 17:34:54 -0000 Please let me know if you see any important bits missing from the minutes below before I post them. Thanks!, Greg Agenda bashing: Feedback needed on the framework draft. SDP elements will be last-called again in fecframe and mmusic WGs. Mark presenting his slides. Framework: Going through the major changes. Addressed comments raised in the list. Ready for a new WGLC? Raptor: Added the support for the new RaptorQ. RTP Payload Format for Raptor: Addressed comments raised in the mailing list. It will be last called in avt and fecframe. The AD Magnus suggests Mark to look at the RTP how-to document to put some text around the security considerations. Orly presenting her slides. Multi-Flow FEC: Mike Luby asked about the potential waste of header bytes for listing all the SSRCs. But, this proposal was not favored last time due to the complexity it introduced. Orly is going through the concerns raised in the last meeting by Colin P. and Ali B. Mike L. gave the example from 3GPP called the MBMS spec that proposed a similar idea of combining multiple source flows and protecting them with a single repair flow. Mark W. asked for more descriptive text about how to generate the source blocks. RS Payload Format: Going through the changes. FEC header structure and repair-window issues. Mark W. is asking for how this relates to the other RS draft from Vincent. Mark W. also brought up the issue of using a generic RTP payload format for different FEC schemes. But, that idea was not favored by the AVT folks some time ago. And the folks in the room vaguely remembered some issues related to RTCP reporting. The WG should probably look into this discussion again. The chair is trying to get yeah/nah for the drafts presented to become WG items. The voting will continue in the list. The chair is presenting the slides from Vincent and Rajiv. In Rajiv slides, the question is about the selection of the announcement intervals. And should that draft be informational or standards track? Final deck from Roux. The Chair is going thru the slides mostly in a silent mode. Results are shown but questions are welcome on the list. -acbegen From rajiva@cisco.com Thu Mar 25 11:57:14 2010 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 8DE603A6CE4 for ; Thu, 25 Mar 2010 11:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 8Epd1hT6WZbd for ; Thu, 25 Mar 2010 11:57:13 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 2A07E3A6C6F for ; Thu, 25 Mar 2010 11:57:13 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANtOq0utJV2a/2dsb2JhbACbKHOmO5kPhH0Egx4 X-IronPort-AV: E=Sophos;i="4.51,309,1267401600"; d="scan'208";a="96286075" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 25 Mar 2010 18:57:34 +0000 Received: from xbh-rcd-202.cisco.com (xbh-rcd-202.cisco.com [72.163.62.201]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o2PIvY0G006294; Thu, 25 Mar 2010 18:57:34 GMT Received: from xmb-rcd-111.cisco.com ([72.163.62.153]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Mar 2010 13:57:34 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Mar 2010 13:57:33 -0500 Message-ID: <067E6CE33034954AAC05C9EC85E2577C0153A9F0@XMB-RCD-111.cisco.com> In-Reply-To: <38c19b541003251029h6c9702eew12b6d4f80281f6b2@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fecframe] IETF 77 Minutes Thread-Index: AcrMQYqc/EhvHzFqQsSkJ2HIU3XQNgAC1OoQ References: <38c19b541003251029h6c9702eew12b6d4f80281f6b2@mail.gmail.com> From: "Rajiv Asati (rajiva)" To: , X-OriginalArrivalTime: 25 Mar 2010 18:57:34.0340 (UTC) FILETIME=[07790440:01CACC4D] Subject: Re: [Fecframe] IETF 77 Minutes 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: Thu, 25 Mar 2010 18:57:14 -0000 > The chair is presenting the slides from Vincent and Rajiv. In Rajiv > slides, the question is about the selection of the announcement > intervals. And should that draft be informational or standards track? Was there any input to both of the Q?=20 Greg, thanks a lot for presenting the slides.=20 Cheers, Rajiv > -----Original Message----- > From: fecframe-bounces@ietf.org [mailto:fecframe-bounces@ietf.org] On > Behalf Of Greg Shepherd > Sent: Thursday, March 25, 2010 1:29 PM > To: fecframe@ietf.org > Subject: [Fecframe] IETF 77 Minutes >=20 > Please let me know if you see any important bits missing from the > minutes below before I post them. >=20 > Thanks!, > Greg >=20 > Agenda bashing: > Feedback needed on the framework draft. SDP elements will be last-called > again in fecframe and mmusic WGs. >=20 > Mark presenting his slides. >=20 > Framework: Going through the major changes. Addressed comments raised in > the list. Ready for a new WGLC? > Raptor: Added the support for the new RaptorQ. > RTP Payload Format for Raptor: Addressed comments raised in the mailing > list. It will be last called in avt and fecframe. The AD Magnus suggests > Mark to look at the RTP how-to document to put some text around the > security considerations. >=20 > Orly presenting her slides. >=20 > Multi-Flow FEC: Mike Luby asked about the potential waste of header bytes > for listing all the SSRCs. But, this proposal was not favored last time > due to the complexity it introduced. Orly is going through the concerns > raised in the last meeting by Colin P. and Ali B. Mike L. gave the > example from 3GPP called the MBMS spec that proposed a similar idea of > combining multiple source flows and protecting them with a single repair > flow. Mark W. asked for more descriptive text about how to generate the > source blocks. >=20 > RS Payload Format: Going through the changes. FEC header structure and > repair-window issues. Mark W. is asking for how this relates to the > other RS draft from Vincent. Mark W. also brought up the issue of using > a generic RTP payload format for different FEC schemes. But, that idea > was not favored by the AVT folks some time ago. And the folks in the > room vaguely remembered some issues related to RTCP reporting. The WG > should probably look into this discussion again. >=20 > The chair is trying to get yeah/nah for the drafts presented to become > WG items. The voting will continue in the list. >=20 > The chair is presenting the slides from Vincent and Rajiv. In Rajiv > slides, the question is about the selection of the announcement > intervals. And should that draft be informational or standards track? >=20 > Final deck from Roux. The Chair is going thru the slides mostly in a > silent mode. Results are shown but questions are welcome on the list. >=20 > -acbegen > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From vincent.roca@inrialpes.fr Thu Mar 25 13:18:52 2010 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 697763A67FC; Thu, 25 Mar 2010 13:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] 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 6j4SUz6Kzde7; Thu, 25 Mar 2010 13:18:45 -0700 (PDT) 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 284553A6BDB; Thu, 25 Mar 2010 13:18:39 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,309,1267398000"; d="scan'208";a="59714006" Received: from vpnloria21.inrialpes.fr (HELO dhcp-wired-48-132.meeting.ietf.org) ([194.199.16.149]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 25 Mar 2010 21:18:57 +0100 Message-ID: <4BABC52E.20602@inrialpes.fr> Date: Thu, 25 Mar 2010 21:18:54 +0100 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3 MIME-Version: 1.0 To: "Luby, Michael" , fecframe@ietf.org References: <20100325170822.B3D9B3A6DE3@core3.amsl.com> In-Reply-To: <20100325170822.B3D9B3A6DE3@core3.amsl.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: housley@vigilsec.com, ipr-announce@ietf.org Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 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: Thu, 25 Mar 2010 20:18:52 -0000 Mike, I discover that QC just updated its previous IPR disclosure against our I-D in: https://datatracker.ietf.org/ipr/1288/ This disclosure refers to draft-roca-fecframe-rs-02, i.e. the latest version where we tried to solve the potential IPR issue as I explained to you in my previous emails (sent before the IPR disclosure update): http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html So I take it as QC's official answer: the issue is not solved in -02 version according to QC! Since it seems I have no choice, let's put everything on the table: ** Concerning US Patent 7,660,245: This patent has three independent claims: 1, 16 and 18. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols. Unless we forgot something, we removed from our I-D all references to this technique, which is sufficient to conclude that version -02 cannot infringe US Patent 7,660,245. ** Concerning Patent 20100050057: This patent has four independent claims: 1, 10, 16 and 24. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols, so my answer is exactly the same. I'd like to understand. *I am doing significant efforts but I now have the feeling this is not reciprocal.* What's wrong? I need an answer. Regards, Vincent On 25/03/10 18:08, IETF Secretariat wrote: > Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine Bouabdallah: > > An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon > Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs) > was submitted to the IETF Secretariat on 2010-03-18 and has been posted on the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure is > "QUALCOMM Incorporated's Statement about IPR related to > draft-roca-fecframe-rs-02." > > The IETF Secretariat > From stewe@stewe.org Thu Mar 25 13:57:22 2010 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 AC0023A6D29 for ; Thu, 25 Mar 2010 13:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=1.332, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] 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 nGShh4Hc46Zm for ; Thu, 25 Mar 2010 13:57:21 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id D62ED3A6C00 for ; Thu, 25 Mar 2010 13:57:19 -0700 (PDT) Received: from [130.129.29.160] (unverified [130.129.29.160]) by stewe.org (SurgeMail 3.9e) with ESMTP id 625465-1743317 for multiple; Thu, 25 Mar 2010 21:57:41 +0100 User-Agent: Microsoft-Entourage/12.23.0.091001 Date: Thu, 25 Mar 2010 13:57:35 -0700 From: Stephan Wenger To: Vincent Roca , Message-ID: Thread-Topic: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 Thread-Index: AcrMXctmAqKhKm6bt06Gl7TBO6wm8A== In-Reply-To: <4BABC52E.20602@inrialpes.fr> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 130.129.29.160 X-Authenticated-User: stewe@stewe.org Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 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: Thu, 25 Mar 2010 20:57:22 -0000 Hi Vincent, all, I'm tempted to unsubscribe from the Fecframe mailing list after this post. I'm not interested in reading a layman's interpretation of patent claims, or their mapping against a draft. I'm not interest in being advised of patent numbers other than those of my employer. I want to preserve my freedom of studying the IPR disclosures if and when I choose, which may very well include "never". I'm not interested in witnessing design-around attempts, even if they include "significant efforts" of yours. I'm certain I'm not alone in the above. I would appreciate if you were showing just a bit more sensitivity towards the practical needs of employees of large and small corporations. Stephan On 3.25.2010 13:18 , "Vincent Roca" wrote: > Mike, > > I discover that QC just updated its previous IPR disclosure > against our I-D in: https://datatracker.ietf.org/ipr/1288/ > > This disclosure refers to draft-roca-fecframe-rs-02, i.e. the > latest version where we tried to solve the potential IPR issue > as I explained to you in my previous emails (sent before the > IPR disclosure update): > http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html > > So I take it as QC's official answer: the issue is not solved in > -02 version according to QC! > > > Since it seems I have no choice, let's put everything on the > table: > > ** Concerning US Patent 7,660,245: > This patent has three independent claims: 1, 16 and 18. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols. > Unless we forgot something, we removed from our I-D all > references to this technique, which is sufficient to conclude that > version -02 cannot infringe US Patent 7,660,245. > > ** Concerning Patent 20100050057: > This patent has four independent claims: 1, 10, 16 and 24. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols, so > my answer is exactly the same. > > > I'd like to understand. *I am doing significant efforts but > I now have the feeling this is not reciprocal.* What's wrong? > I need an answer. > > > Regards, > > Vincent > > > On 25/03/10 18:08, IETF Secretariat wrote: >> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine >> Bouabdallah: >> >> An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon >> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs) >> was submitted to the IETF Secretariat on 2010-03-18 and has been posted on >> the >> "IETF Page of Intellectual Property Rights Disclosures" >> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure is >> "QUALCOMM Incorporated's Statement about IPR related to >> draft-roca-fecframe-rs-02." >> >> The IETF Secretariat >> > _______________________________________________ > Fecframe mailing list > Fecframe@ietf.org > https://www.ietf.org/mailman/listinfo/fecframe From luby@qualcomm.com Thu Mar 25 18:19:41 2010 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 E4F873A6A7F; Thu, 25 Mar 2010 18:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.468 X-Spam-Level: X-Spam-Status: No, score=-105.468 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, 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 zEqqcHDRvnaP; Thu, 25 Mar 2010 18:19:33 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 5B81A3A6949; Thu, 25 Mar 2010 18:19:29 -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=1269566392; x=1301102392; 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:acceptlanguage: content-type:mime-version:x-ironport-av; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20,=20"fecframe@i etf.org"=0D=0A=09|CC:=20"housley@vigil sec.com"=20,=20"ipr-announce@ietf.o rg"=0D=0A=09|Date:=20Thu,=2025=20M ar=202010=2018:19:49=20-0700|Subject:=20Re:=20Posting=20o f=20IPR=20Disclosure=20related=20to=20QUALCOMM=20Incorpor ated's=0D=0A=20Statement=20about=20IPR=20related=20to=20d raft-roca-fecframe-rs-02|Thread-Topic:=20Posting=20of=20I PR=20Disclosure=20related=20to=20QUALCOMM=20Incorporated' s=0D=0A=20Statement=20about=20IPR=20related=20to=20draft- roca-fecframe-rs-02|Thread-Index:=20AcrMWH8S/zO5YJ1JQda+L wGDvqSQagAKe6Fa|Message-ID:=20|In-Reply-To:=20<4BABC52E.20602@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20multipart/alternative=3B=0D=0A =09boundary=3D"_000_C7D159C5CD03lubyqualcommcom_" |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5931"=3B=20a=3D"37317242"; bh=SBePhzKUyVDW2o8TQPbZ+95gxJU7yQUuSUDmGW8xIJI=; b=JXKw841rMYqhISryQd4hxGCkxKkARCsKDFHVqfg0W3RBhGvuJvjTBm/W nmZTK517hj/SF5uhZY5k81H+qdNkBFO44SqIIV3yqY9MBr1V/9NWz+RF/ xv55hgQhhew3yIlutzjD5G12v4wwLd5AqpeYdTVxyb72GN9drI9jR2XPP E=; X-IronPort-AV: E=McAfee;i="5400,1158,5931"; a="37317242" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com with ESMTP; 25 Mar 2010 18:19:51 -0700 Received: from nasanexhub02.na.qualcomm.com ([10.46.143.120]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 25 Mar 2010 18:19:52 -0700 Received: from nasclexhc02.na.qualcomm.com (10.227.147.13) by nasanexhub02.na.qualcomm.com (10.46.143.120) with Microsoft SMTP Server (TLS) id 8.2.234.1; Thu, 25 Mar 2010 18:19:48 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc02.na.qualcomm.com ([10.227.147.13]) with mapi; Thu, 25 Mar 2010 18:19:50 -0700 From: "Luby, Michael" To: Vincent Roca , "fecframe@ietf.org" Date: Thu, 25 Mar 2010 18:19:49 -0700 Thread-Topic: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 Thread-Index: AcrMWH8S/zO5YJ1JQda+LwGDvqSQagAKe6Fa Message-ID: In-Reply-To: <4BABC52E.20602@inrialpes.fr> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C7D159C5CD03lubyqualcommcom_" MIME-Version: 1.0 Cc: "housley@vigilsec.com" , "ipr-announce@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 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, 26 Mar 2010 01:19:41 -0000 --_000_C7D159C5CD03lubyqualcommcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable All, I agree with and respect Stephan's remarks, this is not the forum to discus= s specific IPR. Mike On 3/25/10 1:18 PM, "Vincent Roca" wrote: Mike, I discover that QC just updated its previous IPR disclosure against our I-D in: https://datatracker.ietf.org/ipr/1288/ This disclosure refers to draft-roca-fecframe-rs-02, i.e. the latest version where we tried to solve the potential IPR issue as I explained to you in my previous emails (sent before the IPR disclosure update): http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html So I take it as QC's official answer: the issue is not solved in -02 version according to QC! Since it seems I have no choice, let's put everything on the table: ** Concerning US Patent 7,660,245: This patent has three independent claims: 1, 16 and 18. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols. Unless we forgot something, we removed from our I-D all references to this technique, which is sufficient to conclude that version -02 cannot infringe US Patent 7,660,245. ** Concerning Patent 20100050057: This patent has four independent claims: 1, 10, 16 and 24. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols, so my answer is exactly the same. I'd like to understand. *I am doing significant efforts but I now have the feeling this is not reciprocal.* What's wrong? I need an answer. Regards, Vincent On 25/03/10 18:08, IETF Secretariat wrote: > Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amin= e Bouabdallah: > > An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Sol= omon > Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe= -rs) > was submitted to the IETF Secretariat on 2010-03-18 and has been posted o= n the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure= is > "QUALCOMM Incorporated's Statement about IPR related to > draft-roca-fecframe-rs-02." > > The IETF Secretariat > --_000_C7D159C5CD03lubyqualcommcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's Sta= tement about IPR related to draft-roca-fecframe-rs-02 All,
I agree with and respect Stephan’s remarks, this is not the forum to = discuss specific IPR.
Mike  


On 3/25/10 1:18 PM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:

Mike,

I discover that QC just updated its previous IPR disclosure
against our I-D in:    https://datatracker.ietf.org/ipr/1288/

This disclosure refers to draft-roca-fecframe-rs-02, i.e. the
latest version where we tried to solve the potential IPR issue
as I explained to you in my previous emails (sent before the
IPR disclosure update):
http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html

So I take it as QC's official answer: the issue is not solved in
-02 version according to QC!


Since it seems I have no choice, let's put everything on the
table:

** Concerning US Patent 7,660,245:
This patent has three independent claims: 1, 16 and 18.
*All of them* are restricted to situations where different source
packets contribute to a different number of source symbols.
Unless we forgot something, we removed from our I-D all
references to this technique, which is sufficient to conclude that
version -02 cannot infringe US Patent 7,660,245.

** Concerning Patent 20100050057:
This patent has four independent claims: 1, 10, 16 and 24.
*All of them* are restricted to situations where different source
packets contribute to a different number of source symbols, so
my answer is exactly the same.


I'd like to understand. *I am doing significant efforts but
I now have the feeling this is not reciprocal.* What's wrong?
I need an answer.


Regards,

  Vincent


On 25/03/10 18:08, IETF Secretariat wrote:
> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, A= mine Bouabdallah:
>
> An IPR disclosure that pertains to your Internet-Draft entitled "= Reed-Solomon
> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-= fecframe-rs)
> was submitted to the IETF Secretariat on 2010-03-18 and has been poste= d on the
> "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracke= r.ietf.org/ipr/1288/). The title of the IPR disclosure is
> "QUALCOMM Incorporated's Statement about IPR related to
> draft-roca-fecframe-rs-02."
>
> The IETF Secretariat
>  

--_000_C7D159C5CD03lubyqualcommcom_-- From vincent.roca@inrialpes.fr Mon Mar 29 06:32:23 2010 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 BF4C33A6970; Mon, 29 Mar 2010 06:32:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 DDuK0TWMa1Cz; Mon, 29 Mar 2010 06:32:15 -0700 (PDT) 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 0B31C3A68F7; Mon, 29 Mar 2010 06:31:35 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.51,328,1267398000"; d="scan'208,217";a="59873694" Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 29 Mar 2010 15:32:01 +0200 Message-ID: <4BB0ABD1.9050905@inrialpes.fr> Date: Mon, 29 Mar 2010 15:32:01 +0200 From: Vincent Roca Organization: INRIA User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100225 Fedora/3.0.2-1.fc12 Thunderbird/3.0.2 ThunderBrowse/3.2.8.1 MIME-Version: 1.0 To: "Luby, Michael" References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010100040806050208040306" Cc: "housley@vigilsec.com" , "ipr-announce@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 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, 29 Mar 2010 13:32:23 -0000 This is a multi-part message in MIME format. --------------010100040806050208040306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hello Stephan and Mike, I think your emails deserve an answer. Generals considerations first, and then I'll focus on the specific point under discussion. -- I'm also fed up with all these IPR issues that oblige me to leave my primary activities all too often. I'm researcher, not an IPR lawyer and I have no natural inclination for these legal aspects. That being said, I also want my work to be useful to the whole community (within or outside of the IETF, Nokia and QC included). From this point of view, if there's an IPR disclosure and if I have the feeling an alternative solution exists, I'll examine it instead of "passively accepting" the situation. In any case be assured my behavior is only governed by the desire to be useful to the community. One big difference between you and me is the fact I don't have any legal department in charge of examining IPR aspects. If my documents are subject of a disclosure, I can either ignore it (as many colleagues do) or tackle its analysis. If I want to achieve my above goal of being useful to the community, this second option is the only possible. Yes, I'd like we could all work just like 30-40 years ago, when smart people were eager to design the best possible Internet, using the best possible techniques, just because it was the right answer to the situation. It's worth remembering this heritage. It's perhaps an utopia today, however I'm doing my best to stick with this philosophy since I currently have the freedom to do that. Finally, you can find many examples of WGs going into this kind of discussion, e.g. in the informational RFC 3669 (https://datatracker.ietf.org/doc/rfc3669/). A few excerpts of the lessons learned: o IPR claims should never be disregarded without good cause. Due diligence should be done to understand the consequences of each claim. [...] o It's sometimes beneficial to push IPR claimants to find out what they think their claims cover and what their licensing terms are. o Possibilities of prior art should be considered. o It's all right, and sometimes beneficial, to discuss IPR claims and gather information about possible prior art on the group list. The results of such discussion can be considered when deciding whether to develop a technology (but remember that neither the IETF nor any working group takes a stand on such claims as a body, and the group is not the best place to get legal advice). The above sentences are not definite rules, of course, and each situation is specific and needs to be handled appropriately. However saying that "[the FECFRAME mailing list] is not the forum to discuss specific IPR" is a personal interpretation that is in-line with the IETF practices. -- Now, concerning the topic that triggered this discussion: - I've updated the I-D and in theory it's sufficient for QC to be aware of our attempts to solve the problem; - However I explicitly told Mike what we've done and asked him to clarify QC's position. No answer; - I met Mike just before the fecframe meeting and asked again the same question. Unless I misunderstood what he said, I didn't get any answer; - the situation was once again explained in my slides. I was not there unfortunately, but I didn't see anything in the Minutes; - And then came this new IPR disclosure that completely ignores any effort I've made to try understand the situation and to solve it. At this point, I'm now wondering if QC's strategy is not to leave this point open until everybody forget? Anyway, if QC does not want to answer, I want it to be clearly stated and justified. How long it will take me to have this clarification is not under my control. I'm not responsible of the whole story. Especially as last year I even made sure that there was no IPR issue in FECFRAME. Now DF/QC chose the submarine patent approach ("undisclosed pending patent") and to keep it secret till it's granted, last month. It's their right but me and my co-authors are the victims in this story. Last but not least... In all my emails exchanges, I pay attention not to offend anybody. I don't have the feeling that any email I sent (including this one) was offending, but if somebody has a different feeling, then I apologize since this was not my goal. Sorry for this very long email. I hope that you now better understand my attitude. Stephan, if you are not interested by my IPR-related emails, which I can understand, then please ignore them. And long life to the IETF that already enabled me to solve similar issues, without having to waste time, energy and money in a court, whereas a consensus was easily achievable as long as both parties are working toward this goal. Last Autumn discussion with Mike on the RMT mailing list proved it's possible. Thanks! Best regards, Vincent On 26/03/2010 02:19, Luby, Michael wrote: > All, > I agree with and respect Stephan's remarks, this is not the forum to > discuss specific IPR. > Mike > > > On 3/25/10 1:18 PM, "Vincent Roca" wrote: > > Mike, > > I discover that QC just updated its previous IPR disclosure > against our I-D in: https://datatracker.ietf.org/ipr/1288/ > > This disclosure refers to draft-roca-fecframe-rs-02, i.e. the > latest version where we tried to solve the potential IPR issue > as I explained to you in my previous emails (sent before the > IPR disclosure update): > http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html > > So I take it as QC's official answer: the issue is not solved in > -02 version according to QC! > > > Since it seems I have no choice, let's put everything on the > table: > > ** Concerning US Patent 7,660,245: > This patent has three independent claims: 1, 16 and 18. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols. > Unless we forgot something, we removed from our I-D all > references to this technique, which is sufficient to conclude that > version -02 cannot infringe US Patent 7,660,245. > > ** Concerning Patent 20100050057: > This patent has four independent claims: 1, 10, 16 and 24. > *All of them* are restricted to situations where different source > packets contribute to a different number of source symbols, so > my answer is exactly the same. > > > I'd like to understand. *I am doing significant efforts but > I now have the feeling this is not reciprocal.* What's wrong? > I need an answer. > > > Regards, > > Vincent > > > On 25/03/10 18:08, IETF Secretariat wrote: > > Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu > Cunche, Amine Bouabdallah: > > > > An IPR disclosure that pertains to your Internet-Draft entitled > "Reed-Solomon > > Forward Error Correction (FEC) Schemes for FECFRAME" > (draft-roca-fecframe-rs) > > was submitted to the IETF Secretariat on 2010-03-18 and has been > posted on the > > "IETF Page of Intellectual Property Rights Disclosures" > > (https://datatracker.ietf.org/ipr/1288/). The title of the IPR > disclosure is > > "QUALCOMM Incorporated's Statement about IPR related to > > draft-roca-fecframe-rs-02." > > > > The IETF Secretariat > > > --------------010100040806050208040306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello Stephan and Mike,


I think your emails deserve an answer.
Generals considerations first, and then I'll focus on
the specific point under discussion.

--

I'm also fed up with all these IPR issues that oblige me to
leave my primary activities all too often. I'm researcher,
not an IPR lawyer and I have no natural inclination for
these legal aspects.

That being said, I also want my work to be useful to the
whole community (within or outside of the IETF, Nokia and
QC included). From this point of view, if there's an IPR
disclosure and if I have the feeling an alternative
solution exists, I'll examine it instead of "passively
accepting" the situation. In any case be assured my
behavior is only governed by the desire to be useful to
the community.

One big difference between you and me is the fact I don't
have any legal department in charge of examining IPR
aspects. If my documents are subject of a disclosure, I
can either ignore it (as many colleagues do) or tackle
its analysis. If I want to achieve my above goal of being
useful to the community, this second option is the only
possible.

Yes, I'd like we could all work just like 30-40 years ago,
when smart people were eager to design the best possible
Internet, using the best possible techniques, just because
it was the right answer to the situation. It's  worth
remembering this heritage. It's perhaps an utopia
today, however I'm doing my best to stick with this
philosophy since I currently have the freedom to do
that.

Finally, you can find many examples of WGs going into this
kind of discussion, e.g. in the informational RFC 3669
(https://datatracker.ietf.org/doc/rfc3669/).
A few excerpts of the lessons learned:

   o  IPR claims should never be disregarded without good cause.  Due
      diligence should be done to understand the consequences of each
      claim.
[...]
   o  It's sometimes beneficial to push IPR claimants to find out what
      they think their claims cover and what their licensing terms are.

   o  Possibilities of prior art should be considered.

   o  It's all right, and sometimes beneficial, to discuss IPR claims
      and gather information about possible prior art on the group list.
      The results of such discussion can be considered when deciding
      whether to develop a technology (but remember that neither the
      IETF nor any working group takes a stand on such claims as a body,
      and the group is not the best place to get legal advice).

The above sentences are not definite rules, of course, and
each situation is specific and needs to be handled
appropriately. However saying that "[the FECFRAME mailing
list] is not the forum to discuss specific IPR" is a
personal interpretation that is in-line with the IETF
practices.


--

Now, concerning the topic that triggered this discussion:

- I've updated the I-D and in theory it's sufficient for
  QC to be aware of our attempts to solve the problem;
- However I explicitly told Mike what we've done and
  asked him to clarify QC's position. No answer;
- I met Mike just before the fecframe meeting and asked
  again the same question. Unless I misunderstood what he
  said, I didn't get any answer;
- the situation was once again explained in my slides.
  I was not there unfortunately, but I didn't see
  anything in the Minutes;
- And then came this new IPR disclosure that completely
  ignores any effort I've made to try understand the
  situation and to solve it.

At this point, I'm now wondering if QC's strategy is not
to leave this point open until everybody forget? Anyway,
if QC does not want to answer, I want it to be clearly
stated and justified. How long it will take me to have
this clarification is not under my control.

I'm not responsible of the whole story. Especially as
last year I even made sure that there was no IPR issue
in FECFRAME. Now DF/QC chose the submarine patent
approach ("undisclosed pending patent") and to keep it
secret till it's granted, last month.  It's their right but me
and my co-authors are the victims in this story.


Last but not least...
In all my emails exchanges, I pay attention not to offend
anybody. I don't have the feeling that any email I sent
(including this one) was offending, but if somebody has a
different feeling, then I apologize since this was not my
goal.

Sorry for this very long email. I hope that you now better
understand my attitude. Stephan, if you are not interested
by my  IPR-related emails, which I can understand, then
please  ignore them.

And long life to the IETF that already enabled me to solve
similar issues, without having to waste time, energy and
money in a court, whereas a consensus was easily achievable
as long as both parties are working toward this goal. Last
Autumn discussion with Mike on the RMT mailing list proved
it's possible. Thanks!

Best regards,


    Vincent



On 26/03/2010 02:19, Luby, Michael wrote:
Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 All,
I agree with and respect Stephan’s remarks, this is not the forum to discuss specific IPR.
Mike  


On 3/25/10 1:18 PM, "Vincent Roca" <vincent.roca@inrialpes.fr> wrote:
Mike,

I discover that QC just updated its previous IPR disclosure
against our I-D in:    https://datatracker.ietf.org/ipr/1288/

This disclosure refers to draft-roca-fecframe-rs-02, i.e. the
latest version where we tried to solve the potential IPR issue
as I explained to you in my previous emails (sent before the
IPR disclosure update):
http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html

So I take it as QC's official answer: the issue is not solved in
-02 version according to QC!


Since it seems I have no choice, let's put everything on the
table:

** Concerning US Patent 7,660,245:
This patent has three independent claims: 1, 16 and 18.
*All of them* are restricted to situations where different source
packets contribute to a different number of source symbols.
Unless we forgot something, we removed from our I-D all
references to this technique, which is sufficient to conclude that
version -02 cannot infringe US Patent 7,660,245.

** Concerning Patent 20100050057:
This patent has four independent claims: 1, 10, 16 and 24.
*All of them* are restricted to situations where different source
packets contribute to a different number of source symbols, so
my answer is exactly the same.


I'd like to understand. *I am doing significant efforts but
I now have the feeling this is not reciprocal.* What's wrong?
I need an answer.


Regards,

  Vincent


On 25/03/10 18:08, IETF Secretariat wrote:
> Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amine Bouabdallah:
>
> An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Solomon
> Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe-rs)
> was submitted to the IETF Secretariat on 2010-03-18 and has been posted on the
> "IETF Page of Intellectual Property Rights Disclosures"
> (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure is
> "QUALCOMM Incorporated's Statement about IPR related to
> draft-roca-fecframe-rs-02."
>
> The IETF Secretariat
>  
--------------010100040806050208040306-- From stewe@stewe.org Mon Mar 29 07:31:53 2010 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 4BEE63A6918 for ; Mon, 29 Mar 2010 07:31:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.853 X-Spam-Level: * X-Spam-Status: No, score=1.853 tagged_above=-999 required=5 tests=[AWL=-0.675, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] 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 T3BAAZa25orf for ; Mon, 29 Mar 2010 07:31:49 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 564AA3A6A7D for ; Mon, 29 Mar 2010 07:31:36 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 628234-1743317 for multiple; Mon, 29 Mar 2010 16:32:03 +0200 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Mon, 29 Mar 2010 07:31:29 -0700 From: Stephan Wenger To: Vincent Roca Message-ID: Thread-Topic: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 Thread-Index: AcrPTIUKrLgP2QXMOU+V3zXznvHgGA== In-Reply-To: <4BB0ABD1.9050905@inrialpes.fr> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3352692721_1440684" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 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, 29 Mar 2010 14:31:53 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3352692721_1440684 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Vincent, I stand to my points. Three more things: 1. I=B9m not with Nokia IPR/legal anymore, I=B9m now with a video-conferencing company called Vidyo. My access to legal resources here is limited. 2. I have not implied that you are out of policy, although that may also be the case. I have implied (and state here now directly) that the way you ar= e working on IPR topic is dangerous to me, to my employer, possibly to my previous employers, and arguably to yourself. It=B9s also rude to push information towards people who have expressed to you many times that they are not interested in. The reasons for that lack of interest are not your concern.=20 3. When patent numbers are involved and details of claim language are discussed on a public mailing list, there is no such thing as =B3ignoring=B2. One may well =B3notice=B2 (in any sense of this word you wish to tag to it). Regards, Stephan --B_3352692721_1440684 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorpo= rated's Statement about IPR related to draft-roca-fecframe-rs-02 Vincent,
I stand to my points.  Three more things:
  1. I’m not with Nokia IPR/legal anymore, I’= m now with a video-conferencing company called Vidyo.  My access to leg= al resources here is limited.
  2. I have not implied that you are out of policy, although = that may also be the case.  I have implied (and state here now directly= ) that the way you are working on IPR topic is dangerous to me, to my employ= er, possibly to my previous employers, and arguably to yourself.  It= 217;s also rude to push information towards people who have expressed to you= many times that they are not interested in.  The reasons for that lack= of interest are not your concern.
  3. When patent numbers are involved and details of claim la= nguage are discussed on a public mailing list, there is no such thing as = 220;ignoring”.  One may well “notice” (in any sense o= f this word you wish to tag to it).
Regards,
Stephan --B_3352692721_1440684-- From luby@qualcomm.com Mon Mar 29 09:54:33 2010 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 0BC7C3A6AC4; Mon, 29 Mar 2010 09:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.469 X-Spam-Level: X-Spam-Status: No, score=-105.469 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 O4HsKMTTu8uP; Mon, 29 Mar 2010 09:54:31 -0700 (PDT) Received: from wolverine01.qualcomm.com (wolverine01.qualcomm.com [199.106.114.254]) by core3.amsl.com (Postfix) with ESMTP id 515233A6AC5; Mon, 29 Mar 2010 09:54:31 -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=1269881700; x=1301417700; h=from:to:cc:date:subject:thread-topic:thread-index: message-id:references:in-reply-to:accept-language: content-language:x-ms-has-attach:x-ms-tnef-correlator: acceptlanguage:content-type:content-transfer-encoding: mime-version:x-ironport-av; z=From:=20"Luby,=20Michael"=20|To:=20Vi ncent=20Roca=20|CC:=20"fecfram e@ietf.org"=20,=20"housley@vigilsec.co m"=0D=0A=09,=20"ipr-announce@ietf.o rg"=20,=0D=0A=09"Luby,=20Michael" =20|Date:=20Mon,=2029=20Mar=202010=200 9:54:27=20-0700|Subject:=20RE:=20Posting=20of=20IPR=20Dis closure=20related=20to=20QUALCOMM=20Incorporated's=0D=0A =20Statement=20about=20IPR=20related=20to=20draft-roca-fe cframe-rs-02|Thread-Topic:=20Posting=20of=20IPR=20Disclos ure=20related=20to=20QUALCOMM=20Incorporated's=0D=0A=20St atement=20about=20IPR=20related=20to=20draft-roca-fecfram e-rs-02|Thread-Index:=20AcrPRF2if2a9x8tyRZSSgFN7fIoWowAF/ ad5|Message-ID:=20|References:=20,<4BB0ABD1.9050905@inrialpes.fr> |In-Reply-To:=20<4BB0ABD1.9050905@inrialpes.fr> |Accept-Language:=20en-US|Content-Language:=20en-US |X-MS-Has-Attach:|X-MS-TNEF-Correlator:|acceptlanguage: =20en-US|Content-Type:=20text/plain=3B=20charset=3D"Windo ws-1252"|Content-Transfer-Encoding:=20quoted-printable |MIME-Version:=201.0|X-IronPort-AV:=20E=3DMcAfee=3Bi=3D"5 400,1158,5935"=3B=20a=3D"37523795"; bh=Akb/wARV111E9aIJ8terRPUPksdLiB5foJ9t1DeMbAQ=; b=kSXqmg+kjrfSJfXLd+HafL3m7JaFCfXZqIjcqQjrk8H5xChLd/8xoisA YF5ETMbzQ3CwdCDtp02vedYDlKyWUNl2TcTbDBUHbXslZWVFlMkRJrH1S wg2FtCnUgJs9yexUELGLklIw/M73hXrMG/446TMX9Ryr67j0v05sDMlOY Y=; X-IronPort-AV: E=McAfee;i="5400,1158,5935"; a="37523795" Received: from ironmsg01-r.qualcomm.com ([172.30.46.15]) by wolverine01.qualcomm.com with ESMTP; 29 Mar 2010 09:54:29 -0700 Received: from nasanexhub06.na.qualcomm.com ([129.46.134.254]) by ironmsg01-r.qualcomm.com with ESMTP/TLS/RC4-MD5; 29 Mar 2010 09:54:29 -0700 Received: from nasanex14h01.na.qualcomm.com (10.46.94.107) by nasanexhub06.na.qualcomm.com (129.46.134.254) with Microsoft SMTP Server (TLS) id 8.2.234.1; Mon, 29 Mar 2010 09:54:28 -0700 Received: from nasclexhc01.na.qualcomm.com (10.227.147.14) by nasanex14h01.na.qualcomm.com (10.46.94.107) with Microsoft SMTP Server (TLS) id 14.0.689.0; Mon, 29 Mar 2010 09:54:28 -0700 Received: from NASCLEXMB02.na.qualcomm.com ([10.227.144.112]) by nasclexhc01.na.qualcomm.com ([10.227.147.14]) with mapi; Mon, 29 Mar 2010 09:54:27 -0700 From: "Luby, Michael" To: Vincent Roca Date: Mon, 29 Mar 2010 09:54:27 -0700 Thread-Topic: Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 Thread-Index: AcrPRF2if2a9x8tyRZSSgFN7fIoWowAF/ad5 Message-ID: References: ,<4BB0ABD1.9050905@inrialpes.fr> In-Reply-To: <4BB0ABD1.9050905@inrialpes.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "housley@vigilsec.com" , "ipr-announce@ietf.org" , "fecframe@ietf.org" Subject: Re: [Fecframe] Posting of IPR Disclosure related to QUALCOMM Incorporated's Statement about IPR related to draft-roca-fecframe-rs-02 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, 29 Mar 2010 16:54:33 -0000 Some remarks below. (***) ________________________________________ From: Vincent Roca [vincent.roca@inrialpes.fr] Sent: Monday, March 29, 2010 6:32 AM To: Luby, Michael Cc: fecframe@ietf.org; housley@vigilsec.com; ipr-announce@ietf.org Subject: Re: Posting of IPR Disclosure related to QUALCOMM Incorporated's S= tatement about IPR related to draft-roca-fecframe-rs-02 Hello Stephan and Mike, I think your emails deserve an answer. Generals considerations first, and then I'll focus on the specific point under discussion. -- I'm also fed up with all these IPR issues that oblige me to leave my primary activities all too often. I'm researcher, not an IPR lawyer and I have no natural inclination for these legal aspects. That being said, I also want my work to be useful to the whole community (within or outside of the IETF, Nokia and QC included). From this point of view, if there's an IPR disclosure and if I have the feeling an alternative solution exists, I'll examine it instead of "passively accepting" the situation. In any case be assured my behavior is only governed by the desire to be useful to the community. *** There is IPR disclosures on many specifications within the IETF, and th= e standards in which they exist are useful to the whole community. Your pr= emise is flawed, and thus much of the reasoning below. One big difference between you and me is the fact I don't have any legal department in charge of examining IPR aspects. If my documents are subject of a disclosure, I can either ignore it (as many colleagues do) or tackle its analysis. If I want to achieve my above goal of being useful to the community, this second option is the only possible. Yes, I'd like we could all work just like 30-40 years ago, when smart people were eager to design the best possible Internet, using the best possible techniques, just because it was the right answer to the situation. It's worth remembering this heritage. It's perhaps an utopia today, however I'm doing my best to stick with this philosophy since I currently have the freedom to do that. *** Much of the best technology used on the Internet has/had IPR, including= Reed-Solomon codes, all video codecs, etc. Finally, you can find many examples of WGs going into this kind of discussion, e.g. in the informational RFC 3669 (https://datatracker.ietf.org/doc/rfc3669/). A few excerpts of the lessons learned: o IPR claims should never be disregarded without good cause. Due diligence should be done to understand the consequences of each claim. [...] o It's sometimes beneficial to push IPR claimants to find out what they think their claims cover and what their licensing terms are. o Possibilities of prior art should be considered. o It's all right, and sometimes beneficial, to discuss IPR claims and gather information about possible prior art on the group list. The results of such discussion can be considered when deciding whether to develop a technology (but remember that neither the IETF nor any working group takes a stand on such claims as a body, and the group is not the best place to get legal advice). The above sentences are not definite rules, of course, and each situation is specific and needs to be handled appropriately. However saying that "[the FECFRAME mailing list] is not the forum to discuss specific IPR" is a personal interpretation that is in-line with the IETF practices. -- Now, concerning the topic that triggered this discussion: - I've updated the I-D and in theory it's sufficient for QC to be aware of our attempts to solve the problem; - However I explicitly told Mike what we've done and asked him to clarify QC's position. No answer; - I met Mike just before the fecframe meeting and asked again the same question. Unless I misunderstood what he said, I didn't get any answer; *** You got an answer, which I'll repeat here: the one issue that we discus= sed previously was addressed, but there are other issues which we have iden= tified that still need to be considered and addressed. - the situation was once again explained in my slides. =20 I was not there unfortunately, but I didn't see anything in the Minutes; - And then came this new IPR disclosure that completely ignores any effort I've made to try understand the situation and to solve it. *** The main change to the new IPR disclosures (and we updated them all in = RMT and FECFRAME, not just this one) compared to previous is the licensing = terms, that rationally should put the whole issue to rest. Clearly, this d= idn't mollify you, as it seems that any IPR, even if the licensing terms ar= e quite quite favorable, is unacceptable in your opinion. However, during = the course of the IPR update process, we did reexamine the spec and underst= ood that there were still some technical issues with the current draft that= probably would have to be changed to be clear of the particular IPR that i= s declared on the current draft. If I remember correctly, you also mention= ed that you would be adding some new elements to the next version of the dr= aft, and be aware and forewarned that these will also have to be carefully = scrutinized, as part of our obligations, to see if there is any necessity t= o declare additional IPR.=20 At this point, I'm now wondering if QC's strategy is not to leave this point open until everybody forget? Anyway, if QC does not want to answer, I want it to be clearly stated and justified. How long it will take me to have this clarification is not under my control. *** This is not nor ever has been QC strategy. I'm not responsible of the whole story. Especially as last year I even made sure that there was no IPR issue in FECFRAME. Now DF/QC chose the submarine patent approach ("undisclosed pending patent") and to keep it secret till it's granted, last month. It's their right but me and my co-authors are the victims in this story. *** It was not a submarine patent, and it is dangerous to allege this. Last but not least... In all my emails exchanges, I pay attention not to offend anybody. I don't have the feeling that any email I sent (including this one) was offending, but if somebody has a different feeling, then I apologize since this was not my goal. Sorry for this very long email. I hope that you now better understand my attitude. Stephan, if you are not interested by my IPR-related emails, which I can understand, then please ignore them. And long life to the IETF that already enabled me to solve similar issues, without having to waste time, energy and money in a court, whereas a consensus was easily achievable as long as both parties are working toward this goal. Last Autumn discussion with Mike on the RMT mailing list proved it's possible. Thanks! *** Nothing was achieved in RMT in my opinion. That was a huge waste of ti= me and energy in my opinion to try and resolve the situation, and didn't ac= hieve anything, as still it is the case that QC has declared IPR on some of= your drafts and you have declared loudly and publicly in many forums that = this is not the case. How is that a good resolution? Best regards, Vincent On 26/03/2010 02:19, Luby, Michael wrote: All, I agree with and respect Stephan=92s remarks, this is not the forum to disc= uss specific IPR. Mike On 3/25/10 1:18 PM, "Vincent Roca" wrote: Mike, I discover that QC just updated its previous IPR disclosure against our I-D in: https://datatracker.ietf.org/ipr/1288/ This disclosure refers to draft-roca-fecframe-rs-02, i.e. the latest version where we tried to solve the potential IPR issue as I explained to you in my previous emails (sent before the IPR disclosure update): http://www.ietf.org/mail-archive/web/fecframe/current/msg00636.html So I take it as QC's official answer: the issue is not solved in -02 version according to QC! Since it seems I have no choice, let's put everything on the table: ** Concerning US Patent 7,660,245: This patent has three independent claims: 1, 16 and 18. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols. Unless we forgot something, we removed from our I-D all references to this technique, which is sufficient to conclude that version -02 cannot infringe US Patent 7,660,245. ** Concerning Patent 20100050057: This patent has four independent claims: 1, 10, 16 and 24. *All of them* are restricted to situations where different source packets contribute to a different number of source symbols, so my answer is exactly the same. I'd like to understand. *I am doing significant efforts but I now have the feeling this is not reciprocal.* What's wrong? I need an answer. Regards, Vincent On 25/03/10 18:08, IETF Secretariat wrote: > Dear Vincent Roca, Jerome Lacan, Kazuhisa Matsuzono, Mathieu Cunche, Amin= e Bouabdallah: > > An IPR disclosure that pertains to your Internet-Draft entitled "Reed-Sol= omon > Forward Error Correction (FEC) Schemes for FECFRAME" (draft-roca-fecframe= -rs) > was submitted to the IETF Secretariat on 2010-03-18 and has been posted o= n the > "IETF Page of Intellectual Property Rights Disclosures" > (https://datatracker.ietf.org/ipr/1288/). The title of the IPR disclosure= is > "QUALCOMM Incorporated's Statement about IPR related to > draft-roca-fecframe-rs-02." > > The IETF Secretariat >