Re: [Fecframe] Last Call: <draft-ietf-fecframe-simple-rs-04.txt> (Simple Reed-Solomon Forward Error Correction (FEC) Scheme for FECFRAME) to Proposed Standard

[Vincent Roca <[e-mail]>]

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
> [e-mail] mailing lists by 2012-10-22. Exceptionally, comments may be
> sent to [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/fecframe