Vincent, Thanks, I think this will help the document. Mike On 11/6/12 4:38 PM, "Vincent Roca" <vincent.roca@xxxxxxxx> wrote: >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 using of Reed-Solomon codes over > GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for > arbitrary packet flows; > > >NEW: > 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], Section 8 "Reed-Solomon Codes Specification for the > Erasure Channel", the specifications of the core Reed-Solomon codes > based on Vandermonde matrices, and specifies a simple FEC scheme that > is compatible with the FECFRAME framework [RFC6363]: > > o the Fully-Specified FEC Scheme with FEC Encoding ID XXX that > specifies a simple way of using of Reed-Solomon codes over > GF(2^^m), with 2 <= m <= 16, with a simple FEC encoding for > arbitrary packet flows; > > Therefore sections 4, 5, 6 and 7 of [RFC5510], that define [RFC5052] > specific Formats and Procedures, are not considered and are replaced > by FECFRAME specific Formats and Procedures. > >** Section 5.3: > >OLD: > > The present document inherits from [RFC5510] the specification of the > core Reed-Solomon codes based on Vandermonde matrices for a packet > transmission channel. > >NEW: > > The present document inherits from [RFC5510], Section 8 "Reed-Solomon > Codes Specification for the Erasure Channel", the specifications of > the core Reed-Solomon codes based on Vandermonde matrices. > > >As soon as possible, I'll update the LDPC document as well, unlike >what I said previously, in the same manner. Saying that all the Formats >and Procedures of RFC5170 are replaced by FECFRAME variants >can clarify a little bit the document. > > >Concerning (2), same answer than for the LDPC document (it's not >an exhaustive list). > > >Cheers, > > Vincent, on behalf of the authors > > >--- > € From: "Luby, Michael" <luby at qti.qualcomm.com> > € To: "ietf at ietf.org" <ietf at ietf.org> > € Cc: "Luby, Michael" <luby at qti.qualcomm.com>, "fecframe at ietf.org" ><fecframe at ietf.org> > € Date: Thu, 11 Oct 2012 17:30:31 +0000 > € In-reply-to: <20121008141129.10923.33854.idtracker at ietfa.amsl.com> > >Some quick comments. > >(1) This proposal relies upon parts of RFC 5510 for the definition of the >underlying Reed-Solomon code. However, it isn't completely explicit in >this proposal about what exact parts/sections of RFC 5510 are to be used >in this proposal and how. It would seem that explicit references to the >particular sections of RFC 5510 that are being used, and exactly how these >parts of RFC 5510 are being inherited and used, would be useful (probably >necessary). > >(2) This proposal references RFC 5170 and RFC 5053, and makes some >comparisons. However, there is also RFC 6330 that is relevant and is not >mentioned or referenced in this proposal. It would seem appropriate to do >so. > >Thanks, Mike > > >On Oct 8, 2012, 16:11, The IESG wrote: >> >> 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' >> <draft-ietf-fecframe-simple-rs-04.txt> 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@xxxxxxxx mailing lists by 2012-10-22. Exceptionally, comments may >>be >> sent to iesg@xxxxxxxx instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document describes a fully-specified simple FEC scheme for Reed- >> Solomon codes over GF(2^^m), with 2 <= m <= 16, that can be used to >> protect arbitrary media streams along the lines defined by the >> FECFRAME framework. Reed-Solomon codes belong to the class of >> Maximum Distance Separable (MDS) codes which means they offer optimal >> protection against packet erasures. They are also systematic codes, >> which means that the source symbols are part of the encoding symbols. >> The price to pay is a limit on the maximum source block size, on the >> maximum number of encoding symbols, and a computational complexity >> higher than that of LDPC codes for instance. >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-ietf-fecframe-simple-rs/ballot/ >> >> >> No IPR declarations have been submitted directly on this I-D. >> >> >> _______________________________________________ >> Fecframe mailing list >> Fecframe@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/fecframe >