http://permalink.gmane.org/gmane.ietf.fecframe hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.ietf.fecframe/101 <pre>Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without</pre> johnsonhammond2-revL73yDgGBWk0Htik3J/w< at >public.gmane.org 2013-04-27T17:01:48 http://permalink.gmane.org/gmane.ietf.fecframe/99 <pre>Dear all, The remaining milestones of the FECFRAME WG have been: Mar 2012 Simple LDPC-Staircase FEC Scheme submitted to IESG as PS Mar 2012 Simple RS FEC Scheme submitted to IESG as PS Jun 2012 Pseudo CDP for protecting multiple flows submitted to IESG as PS All those milestones have been finally published as RFCs: - RFC 6816: Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME - RFC 6865: Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME - RFC 6801: Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework The FECFRAME WG will be officially closed soon, as all milestones were successfully completed. The WG mailing list will remain open. Thank you to the WG and the WG chairs. Regards, Martin </pre> Martin Stiemerling 2013-03-05T20:08:11 http://permalink.gmane.org/gmane.ietf.fecframe/98 <pre> A new Request for Comments is now available in online RFC libraries. RFC 6865 Title: Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME Author: V. Roca, M. Cunche, J. Lacan, A. Bouabdallah, K. Matsuzono Status: Standards Track Stream: IETF Date: February 2013 Mailbox: vincent.roca-MZpvjPyXg2s&lt; at &gt;public.gmane.org, mathieu.cunche-MZpvjPyXg2s&lt; at &gt;public.gmane.org, jerome.lacan-8VgXtmBoT4Q&lt; at &gt;public.gmane.org, abouabdallah-IEqO1jj1GLU&lt; at &gt;public.gmane.org, kazuhisa-xqhEY8SlFfaoIvZxdBGiKQ&lt; at &gt;public.gmane.org Pages: 23 Characters: 48493 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-simple-rs-06.txt URL: http://www.rfc-editor.org/rfc/rfc6865.txt This document describes a fully-specified simple Forward Er</pre> rfc-editor-i4YTrOVFbXmRpAAqCnN02g< at >public.gmane.org 2013-02-27T19:34:04 http://permalink.gmane.org/gmane.ietf.fecframe/97 <pre>The IESG has approved the following document: - 'Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME' (draft-ietf-fecframe-simple-rs-06.txt) as Proposed Standard This document is the product of the FEC Framework Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ Technical Summary This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 &lt;= m &lt;= 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. They are also systematic codes, which means that the source symbols are part of the encoding symbols. The price to pay is a limit on the maximum source block size, on the maximum number of e</pre> The IESG 2013-01-10T15:47:25 http://permalink.gmane.org/gmane.ietf.fecframe/95 <pre> A new Request for Comments is now available in online RFC libraries. RFC 6816 Title: Simple Low-Density Parity Check (LDPC) Staircase Forward Error Correction (FEC) Scheme for FECFRAME Author: V. Roca, M. Cunche, J. Lacan Status: Standards Track Stream: IETF Date: December 2012 Mailbox: vincent.roca-MZpvjPyXg2s&lt; at &gt;public.gmane.org, mathieu.cunche-MZpvjPyXg2s&lt; at &gt;public.gmane.org, jerome.lacan-8VgXtmBoT4Q&lt; at &gt;public.gmane.org Pages: 24 Characters: 49938 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-ldpc-04.txt URL: http://www.rfc-editor.org/rfc/rfc6816.txt This document describes a fully specified simple Forward Error Correction (FEC) scheme for Low-Density Parity Check (LDPC) Staircase codes that can be used to protect media strea</pre> rfc-editor-i4YTrOVFbXmRpAAqCnN02g< at >public.gmane.org 2012-12-22T01:30:49 http://permalink.gmane.org/gmane.ietf.fecframe/94 <pre> A new Request for Comments is now available in online RFC libraries. RFC 6801 Title: Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in the Forward Error Correction (FEC) Framework Author: U. Kozat, A. Begen Status: Informational Stream: IETF Date: November 2012 Mailbox: kozat-oCy43pJ5qIXdm96je9WymdBPR1lH4CV8&lt; at &gt;public.gmane.org, abegen-FYB4Gu1CFyUAvxtiuMwx3w&lt; at &gt;public.gmane.org Pages: 11 Characters: 24923 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-fecframe-pseudo-cdp-05.txt URL: http://www.rfc-editor.org/rfc/rfc6801.txt This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the Forward Error Correction (FEC) Framework and the Session Description Protocol (SDP) elements defined for th</pre> rfc-editor-i4YTrOVFbXmRpAAqCnN02g< at >public.gmane.org 2012-11-30T23:01:48 http://permalink.gmane.org/gmane.ietf.fecframe/93 <pre>Vincent, Thanks, I think this will help the document. Mike On 11/6/12 4:38 PM, "Vincent Roca" &lt;vincent.roca-MZpvjPyXg2s&lt; at &gt;public.gmane.org&gt; wrote: </pre> Luby, Michael 2012-11-06T16:10:07 http://permalink.gmane.org/gmane.ietf.fecframe/91 <pre>Mike, Thanks for your comments. It seems your email didn't show up in the fecframe list (it's not in the mailing list archive either) which explains why we didn't answer so far. Concerning (1), you're right and here is the way we address it both in the introduction and section 5.3. ** Introduction: OLD: More specifically, the [RFC5510] document introduced such Reed- Solomon codes and several associated FEC schemes that are compatible with the [RFC5052] framework. The present document inherits from [RFC5510] the specification of the core Reed-Solomon codes based on Vandermonde matrices, and specifies a simple FEC scheme that is compatible with the FECFRAME framework [RFC6363]. Therefore this document specifies only the information specific to the FECFRAME context and refers to [RFC5510] for the core specifications of the codes. To that purpose, the present document introduces: o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that specifies a simple way of</pre> Vincent Roca 2012-11-06T15:38:58 http://permalink.gmane.org/gmane.ietf.fecframe/90 <pre>The IESG has approved the following document: - 'Simple LDPC-Staircase Forward Error Correction (FEC) Scheme for FECFRAME' (draft-ietf-fecframe-ldpc-04.txt) as Proposed Standard This document is the product of the FEC Framework Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-fecframe-ldpc/ Technical Summary This document describes a fully-specified simple FEC scheme for LDPC-Staircase codes that can be used to protect media streams along the lines defined by the FECFRAME framework. Working Group Summary There is consensus within the FECFrame WG to publish this document. The document has been actively discussed on the wg list and in wg meetings. There was no controversy with the progression of this document. Document Quality Performance evaluation of this: K. Matsuzono, J. Detchart, M. Cunche, V. Roca, H. Asaeda, ``Performance Analysis of a High-Performance Real-Time Application with </pre> The IESG 2012-10-25T14:54:26 http://permalink.gmane.org/gmane.ietf.fecframe/89 <pre>Thanks Martin, I didn't know there was an open question, but I'm happy to hear that it is addressed. Best, Mike On 10/17/12 8:12 AM, "Martin Stiemerling" &lt;martin.stiemerling-kcmmt4fgdiuHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; wrote: </pre> Luby, Michael 2012-10-17T15:58:47 http://permalink.gmane.org/gmane.ietf.fecframe/88 <pre>Hi Michael and Vincent, all, On 10/17/2012 03:41 PM, Luby, Michael wrote: [...] My open points are addressed, i.e., my question of the IPR declarations for RFC 5170 and any potential relationship to draft-ietf-fecframe-ldpc. I will go forward with draft-ietf-fecframe-ldpc and ship it off to the RFC editor. Thank you! Martin </pre> Martin Stiemerling 2012-10-17T15:12:26 http://permalink.gmane.org/gmane.ietf.fecframe/87 <pre>Hi Michael, On 10/17/2012 03:24 PM, Luby, Michael wrote: Ok, thanks. This is solely meant for discussion and to get any questions resolved. We have had some discussion during the IESG evaluation if IPR declared for RFC 5170 is also valid for draft-ietf-fecframe-ldpc. Thus the linkage between your email and what has happened in the IESG. This is not out of a bad intention, but it is more your AD which wanted some more clarity on this. Thank you, Martin </pre> Martin Stiemerling 2012-10-17T15:02:20 http://permalink.gmane.org/gmane.ietf.fecframe/86 <pre>Mike, IPR disclosure transitivity is only possible if the conditions of use are exactly the same as that of the initial document. This is not the case since we restrict to cases where G==1 and only focus on LDPC- Staircase codes, and you recognized it. Additionally you acknowledged in Oct. 2009 that using G&gt;1 was the only reason that motivated 10 patents of this IPR disclosure. See: http://www.ietf.org/mail-archive/web/rmt/current/msg01358.html So we have good reasons to believe that an IPR disclosure specific to this I-D could differ from that of RFC5170. Do you agree or not? I'd like to understand your point. Cheers, Vincent </pre> Vincent Roca 2012-10-17T14:13:37 http://permalink.gmane.org/gmane.ietf.fecframe/85 <pre>The IESG has approved the following document: - 'Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework' (draft-ietf-fecframe-pseudo-cdp-05.txt) as Informational RFC This document is the product of the FEC Framework Working Group. The IESG contact persons are Martin Stiemerling and Wesley Eddy. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-fecframe-pseudo-cdp/ Technical Summary This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework (RFC6363) and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-pledged protocol, but to show how the defined framework and SDP elements can be combined together to design a CDP. Working Group Summary There is consensus within the FECFrame WG to publish this document. The document has been actively discussed on the wg list a</pre> The IESG 2012-10-17T13:58:22 http://permalink.gmane.org/gmane.ietf.fecframe/84 <pre>Vincent, You are welcome. Responses below. Best, Mike On 10/17/12 4:59 AM, "Vincent Roca" &lt;vincent.roca-MZpvjPyXg2s&lt; at &gt;public.gmane.org&gt; wrote: *** The above suggestions I made are clarifying comments, and if they aren't incorporated it only means that the spec is a little less easy to understand and implement, it isn't earth shattering. *** Ok. However, the difference is that RFC 5053 and RFC 6330 and RFC 6681 don't have any survey like comparisons to other FEC technology (except that of course the 6330 does have text to justify its existence vis a vis 5053), whereas this specification does seems to try and make some comparisons to other technologies out there. Its ok as is, just means it isn't quite as good of a comparison list as it could have been given that a comparison survey is included at all. The other option of course would have been not to have such comparisons to other FEC within the document at all, which is the path that 5053 and 6330 take. *** This specification inherits technology fro</pre> Luby, Michael 2012-10-17T13:41:59 http://permalink.gmane.org/gmane.ietf.fecframe/83 <pre>Hi Martin, Comments below. Best, Mike On 10/17/12 2:13 AM, "Martin Stiemerling" &lt;martin.stiemerling-kcmmt4fgdiuHXe+LvDLADg&lt; at &gt;public.gmane.org&gt; wrote: *** My comments aren't crucial, and it seems they are going to be ignored anyway. I wish I had time to look at it earlier, but I didn't. They are clarifying comments, and if they aren't incorporated it only means that the spec is a little less easy to understand, it isn't earth shattering. *** I don't understand this comment, as there were no IPR-related comments in my feedback. </pre> Luby, Michael 2012-10-17T13:24:07 http://permalink.gmane.org/gmane.ietf.fecframe/82 <pre>Mike, Thanks for your feedback. I have no doubt that an implementer will find its way in RFC5170 and identify what needs to be used. With the further restriction of having G=1, the specifications of RFC5170 become fairly small (~14 technical pages, pseudo-code included) and easy to understand IMHO. We are not planning to change anything here unless the IESG asks us to do so. This list is not intended to be exhaustive. No other FEC scheme tries to provide an exhaustive list: RFC5053 (Raptor) does not reference any other FEC scheme, and RFC6330 (RaptorQ) / RFC6681 (Raptor(Q) for FECFRAME) only reference Raptor. More importantly. Since: 1- you noticed we impose restrictions on the way LDPC-Staircase codes are being used in section 4.1; 2- you certainly remember the discussion we had in 2009 concerning 10 out of the 13 patents mentioned in the RFC5170 IPR disclosure, whose conclusion is here: http://www.ietf.org/mail-archive/web/rmt/current/msg01384.html 3- the present I-D only considers LDPC-</pre> Vincent Roca 2012-10-17T11:59:31 http://permalink.gmane.org/gmane.ietf.fecframe/81 <pre>Hi Michael, all, Thanks for your comments, but I would have wished to see them either during the WG Last Call or latest during IETF LC. Anyhow, apart from the timing, the questions are probably good to be discussed. Especially, as there are IPR declarations for RFC 5170. Any feedback from the WG? Thanks, Martin </pre> Martin Stiemerling 2012-10-17T09:13:55 http://permalink.gmane.org/gmane.ietf.fecframe/80 <pre> 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 : Pseudo Content Delivery Protocol (CDP) for Protecting Multiple Source Flows in FEC Framework Author(s) : Ulas C. Kozat Ali Begen Filename : draft-ietf-fecframe-pseudo-cdp-05.txt Pages : 13 Date : 2012-10-16 Abstract: This document provides a pseudo Content Delivery Protocol (CDP) to protect multiple source flows with one or more repair flows based on the FEC Framework and the Session Description Protocol (SDP) elements defined for the framework. The purpose of the document is not to provide a full-fledged protocol, but to show how the defined framework and SDP elements can be combined together to implement a CDP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-fecframe-pseudo-cdp There's also a htmli</pre> internet-drafts-EgrivxUAwEY< at >public.gmane.org 2012-10-17T06:50:19 http://permalink.gmane.org/gmane.ietf.fecframe/78 <pre>Some quick comments. (1) This proposal relies upon parts of RFC 5170 for the definition of the underlying LDPC staircase code. However, it isn't completely explicit in this proposal about what exact parts/sections of RFC 5170 are to be used in this proposal and how. It would seem that explicit references to the particular sections of RFC 5170 that are being used, and exactly how these parts of RFC 5170 are being inherited and used, would be useful (probably necessary). Note that there are several codes with different FEC encoding IDs defined in RFC 5170, so making exact references to which parts are used and how is important. An example of how this is not at all precisely defined: Because of the requirement to have exactly one encoding symbol per group, i.e., because G MUST be equal to 1 (Section 4.1 &lt;http://tools.ietf.org/html/draft-ietf-fecframe-ldpc-04#section-4.1&gt;), several parts of [RFC5170 &lt;http://tools.ietf.org/html/rfc5170&gt;] are useless. In particular, this is the case of Section 5.6 &lt;h</pre> Luby, Michael 2012-10-11T18:23:34 http://permalink.gmane.org/gmane.ietf.fecframe/76 <pre> The IESG has received a request from the FEC Framework WG (fecframe) to consider the following document: - 'Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME' &lt;draft-ietf-fecframe-simple-rs-04.txt&gt; as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf-EgrivxUAwEY&lt; at &gt;public.gmane.org mailing lists by 2012-10-22. Exceptionally, comments may be sent to iesg-EgrivxUAwEY&lt; at &gt;public.gmane.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes a fully-specified simple FEC scheme for Reed- Solomon codes over GF(2^^m), with 2 &lt;= m &lt;= 16, that can be used to protect arbitrary media streams along the lines defined by the FECFRAME framework. Reed-Solomon codes belong to the class of Maximum Distance Separable (MDS) codes which means they offer optimal protection against packet erasures. </pre> The IESG 2012-10-08T14:11:29 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.ietf.fecframe