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 10/8/12 7:11 AM, "The IESG" <iesg-secretary@xxxxxxxx> 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