RaptorQ Forward Error Correction Scheme for Object Delivery
RFC 6330

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    rmt mailing list <rmt@ietf.org>,
    rmt chair <rmt-chairs@tools.ietf.org>
Subject: Protocol Action: 'RaptorQ Forward Error Correction Scheme for Object Delivery' to Proposed Standard (draft-ietf-rmt-bb-fec-raptorq-06.txt)

The IESG has approved the following document:
- 'RaptorQ Forward Error Correction Scheme for Object Delivery'
  (draft-ietf-rmt-bb-fec-raptorq-06.txt) as a Proposed Standard

This document is the product of the Reliable Multicast Transport Working

The IESG contact persons are David Harrington and Wesley Eddy.

A URL of this Internet Draft is:

Technical Summary

    This document is an optional Building Block usable to fully define
    an RMT Transport Protocol.  It fully-specifies a Forward Error
    Correction Code, called "RaptorQ", within the guidelines of
    RFC 5052. It also specifies procedures and
    packet-header fields, as required by RFC 5052.

    The combination of this document and RFC 5052 allows the
    implementation of an interoperable Forward Error Correction
    scheme usable in the context of an RMT transport protocol (e.g.
    LCT/ALC or NORM).
    RaptorQ is a fountain code, i.e., as many encoding symbols
    as needed can be generated by the encoder on-the-fly from the
    source symbols of a source block of data. The decoder is able to
    recover the source block from any set of encoding symbols only
    generally equal to or occasionally with slightly more in number 
    than the number of source symbols.

    The RaptorQ code described here is a systematic code, meaning that all
    the source symbols are among the encoding symbols that can be generated

Working Group Summary

   There is consensus in the WG to publish these documents.

As a result of the IESG questions and discussions, a further revised IPR
statement was filed by Qualcomm Incorporated.  See the following link:


Because of this updated IPR disclosure, an additional RMT Working Group Last Call 
was conducted.  The only resultant working group email discussion to the revised IPR
was that it was an improvement in that it more clearly covered unicast as well as
multicast use cases of the technology.  The following URL points to the mailing
list archive message thread regarding this additional WGLC:

It is important to note, as had been described in the earlier publication writeup for
this specification that, although IPR is in place, this forward error correction
technique is just one of several types that the RMT WG has specified and other,
unencumbered techniques have been defined.  Thus, the RMT WG had  previously discussed 
this matter concluding that it wished to publish this document regardless of the IPR
since this new FEC code is one of multiple alternatives that can  be used to implement
the RMT higher-level protocols, as such the possible IPR covering this does not
preclude the unencumbered implementation of the RMT Protocols.  The IPR licensing terms presented by Qualcomm appear to be reasonable.

 Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

    The document is similar in content to the prior "Raptor"
    codec of RFC 5053 and benefits from the development and reviews 
    of that specification.  Additionally, an independent implementation 
    was conducted from the version 03 draft and only minor suggestions 
   were made (and were incorporated) by that developer to clarify the document.


   Document Shepherd: Brian Adamson (adamson@itd.nrl.navy.mil)
   Responsible Area Director: David Harrington