Skip to main content

RaptorQ Forward Error Correction Scheme for Object Delivery
RFC 6330

Revision differences

Document history

Date Rev. By Action
2020-06-03
06 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2018-12-20
06 (System)
Received changes through RFC Editor sync (changed abstract to 'This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, …
Received changes through RFC Editor sync (changed abstract to 'This document describes a Fully-Specified Forward Error Correction (FEC) scheme, corresponding to FEC Encoding ID 6, for the RaptorQ FEC code and its application to reliable delivery of data objects.

RaptorQ codes are a new family of codes that provide superior flexibility, support for larger source block sizes, and better coding efficiency than Raptor codes in RFC 5053. RaptorQ is also a fountain code, i.e., as many encoding symbols as needed can be generated on the fly by the encoder from the source symbols of a source block of data. The decoder is able to recover the source block from almost any set of encoding symbols of sufficient cardinality -- in most cases, a set of cardinality equal to the number of source symbols is sufficient; in rare cases, a set of cardinality slightly more than the number of source symbols is required.

The RaptorQ code described here is a systematic code, meaning that all the source symbols are among the encoding symbols that can be generated. [STANDARDS-TRACK]')
2018-11-08
06 (System) Received changes through RFC Editor sync (added Errata tag)
2015-10-14
06 (System) Notify list changed from rmt-chairs@ietf.org, draft-ietf-rmt-bb-fec-raptorq@ietf.org to (None)
2015-03-20
Naveen Khan Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to RFC 6330
2013-02-06
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to RFC 6330
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Stewart Bryant
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Peter Saint-Andre
2012-08-22
06 (System) post-migration administrative database adjustment to the No Objection position for Stephen Farrell
2011-08-12
06 (System) RFC published
2011-06-21
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2011-06-21
06 Amy Vezza State changed to RFC Ed Queue from Approved-announcement sent.
2011-06-20
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2011-06-20
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2011-06-20
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2011-06-20
06 (System) IANA Action state changed to In Progress
2011-06-20
06 Amy Vezza IESG state changed to Approved-announcement sent
2011-06-20
06 Amy Vezza IESG has approved the document
2011-06-20
06 Amy Vezza Closed "Approve" ballot
2011-06-20
06 Amy Vezza State changed to Approved-announcement to be sent from Waiting for AD Go-Ahead.
2011-06-20
06 Amy Vezza Ballot writeup text changed
2011-06-20
06 David Harrington Approval announcement text regenerated
2011-06-20
06 Stewart Bryant [Ballot Position Update] Position for Stewart Bryant has been changed to No Objection from Discuss
2011-06-17
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-06-16
06 Amanda Baber
IANA understands that, upon approval of this document, there is a single
IANA Action that IANA must complete.

In the ietf:rmt:fec:encoding - Fully-Specified FEC schemes …
IANA understands that, upon approval of this document, there is a single
IANA Action that IANA must complete.

In the ietf:rmt:fec:encoding - Fully-Specified FEC schemes (0-127) in
the Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance
IDs registry located at:

http://www.iana.org/assignments/rmt-fec-parameters/rmt-fec-parameters.xhtml

a single new value will be registered as follows:

Value: tbd
Description: RaptorQ Code
Reference: [RFC-to-be]

IANA notes that the authors have requested the value of 6 to be used for
this identifier.
2011-06-03
06 Amy Vezza Last call sent
2011-06-03
06 Amy Vezza
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RaptorQ Forward Error Correction Scheme for Object Delivery) to Proposed Standard


The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'RaptorQ Forward Error Correction Scheme for Object Delivery'
  as a 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@ietf.org mailing lists by 2011-06-17. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

This is a second IETF Last Call. At IESG request, an updated IPR disclosure
related to this document was filed by Qualcomm Incorporated to clarify the
licensing terms vis-a-vis different applications of the technology. 
See the following link: https://datatracker.ietf.org/ipr/1553/
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:

http://www.ietf.org/mail-archive/web/rmt/current/msg01547.html

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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/
2011-06-03
06 Amy Vezza Last Call text changed
2011-06-03
06 David Harrington Ballot writeup text changed
2011-06-03
06 David Harrington Ballot writeup text changed
2011-06-03
06 David Harrington Last Call was requested
2011-06-03
06 David Harrington State changed to Last Call Requested from IESG Evaluation::AD Followup.
2011-06-03
06 David Harrington Last Call text changed
2011-06-03
06 David Harrington
"draft-ietf-rmt-bb-fec-raptorq-04" intended for publication in the "Proposed Standard" category.

This writeup complies with the current publication writeup template.

  (1.a)  Who is the Document Shepherd …
"draft-ietf-rmt-bb-fec-raptorq-04" intended for publication in the "Proposed Standard" category.

This writeup complies with the current publication writeup template.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Brian Adamson, who has personally
reviewed this version of the document and believes it is ready
for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had adequate review both from key WG members
and from key non-WG members.  In fact an independent reviewer was able
to develop an implementation from the specification and provided feedback
to the document authors.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No additional reviews needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

An earlier version of this document was originally submitted for publication
and an IESG review was conducted.  During this time, some questions were raised
regarding an additional and revised IPR disclosure made against the document.
As a result of the IESG questions and discussions, a further revised IPR
statement was filed by Qualcomm Incorporated.  See the following link:

https://datatracker.ietf.org/ipr/1553/

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:

http://www.ietf.org/mail-archive/web/rmt/current/msg01547.html

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.



  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represent a solid consensus of the RMT WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No notable discontent.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The Document Shepherd has personally verified that the document
satisfies all ID nits.  It should be noted that some of the nomenclature
in the document causes some false alarms (warnings) in the ID Nits check.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and
informative. There are no downward references.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists, it is consistent with the rest
of the document and is consistent with the registration guidelines
specified in RFC 5052. No new registry is defined. No Expert Review
Process is necessary for the IANA assignments requested by this document.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The documents contains no section written in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents. 

Document Announcement Write-Up follows.

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.

Document Quality

    The document quality is high.  It 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.

Brian Adamson is the Document Shepherd.
Dave Harrington is the Responsible Area Director.

2011-05-27
06 David Harrington working group is reviewing the clarified IPR disclosure; then the shepherding doc will be updatedl then a LC will be issued with updated IPR information.
2011-05-24
06 Stewart Bryant [Ballot discuss]
The IETF Last Call needs to be re-issued drawing attention to the IPR statement.
2011-05-23
06 David Harrington Last Call text changed
2011-05-21
06 Stephen Farrell [Ballot comment]
Its a pity that its not clear whether or not the terms specified apply to 
things like open source libraries.
2011-05-21
06 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2011-05-16
06 David Harrington Last Call text changed
2011-05-16
06 David Harrington Ballot writeup text changed
2011-05-16
06 David Harrington Approval announcement text changed
2011-05-16
06 David Harrington Approval announcement text regenerated
2011-05-11
06 Peter Saint-Andre [Ballot Position Update] Position for Peter Saint-Andre has been changed to No Objection from Discuss
2011-05-11
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-rmt-bb-fec-raptorq-06
2011-05-06
06 Stephen Farrell
[Ballot discuss]
(1) Its not clear to me that an implementer of this would understand whether or not they'd be covered by the IPR declaration …
[Ballot discuss]
(1) Its not clear to me that an implementer of this would understand whether or not they'd be covered by the IPR declaration which only seems to call out specific uses. One solution might be to add an applicability statement to the draft that matches the conditions under which the IPR situation is well-defined.
2011-05-05
06 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-06.txt
2011-04-14
06 Cindy Morgan Removed from agenda for telechat
2011-04-14
06 Cindy Morgan State changed to IESG Evaluation::AD Followup from IESG Evaluation.
2011-04-14
06 Sean Turner [Ballot Position Update] Position for Sean Turner has been changed to No Objection from Discuss
2011-04-14
06 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded
2011-04-14
06 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded
2011-04-14
06 Ralph Droms [Ballot Position Update] New position, No Objection, has been recorded
2011-04-14
06 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded
2011-04-13
06 Stephen Farrell
[Ballot discuss]
(1) Its not clear to me that an implementer of this would understand whether or not they'd be covered by the IPR declaration …
[Ballot discuss]
(1) Its not clear to me that an implementer of this would understand whether or not they'd be covered by the IPR declaration which only seems to call out specific uses. One solution might be to add an applicability statement to the draft that matches the conditions under which the IPR situation is well-defined.

(2) Is there a reason to prefer sha-1 in the security considerations section? sha-256 may be better as an algorithm that will have a longer shelf-life. If you want to stick with sha-1 then you should make it clear what properties of the hash algorithm are required (collision resistance, pre-image resistance...)
2011-04-13
06 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded
2011-04-13
06 Sean Turner
[Ballot discuss]
Revised:

Hoping that these will be cleared before or on the telechat call:

#1) I have to ask whether this document should be …
[Ballot discuss]
Revised:

Hoping that these will be cleared before or on the telechat call:

#1) I have to ask whether this document should be obsoleting RFC 5053 based on the following text in the introduction:

  The RaptorQ code described herein is a next generation of
  the Raptor code described in RFC5053 [RFC5053].

#2) addressed
2011-04-13
06 Stewart Bryant
[Ballot discuss]
I could not see an IPR disclosure in the Last Call text.

I am by no means an IPR expert, but the IPR …
[Ballot discuss]
I could not see an IPR disclosure in the Last Call text.

I am by no means an IPR expert, but the IPR claim seems to imply different terms depending on whether packets containing this protocol are sent over different types of network. That seems contra to the IETF position of wanting to be able to send our protocols over any link type. It therefore seems particularly important that the community's attention be draft to the IPR statement when deciding whether to proceed with the Standard.

Presumably if there is a single a digit error in any one of the number of very large tables of numbers there will be at the very least an interoperability issue with existing implementations, or even a broken protocol. Is it possible to make the generator polynomials for these tables normative, and the tables themselves informative? This would substantially reduce the scope for a process error somewhere between the original compilation of these tables and the final publication of the RFC.
2011-04-13
06 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded
2011-04-12
06 Peter Saint-Andre
[Ballot discuss]
Given that various fields are longer than 8 bits (e.g., the Encoding Symbol ID (ESI), Transfer Length (F), and Symbol Size (T) elements), …
[Ballot discuss]
Given that various fields are longer than 8 bits (e.g., the Encoding Symbol ID (ESI), Transfer Length (F), and Symbol Size (T) elements), please specify the network byte order (probably it is network byte order, but it needs to be specified).
2011-04-12
06 Peter Saint-Andre [Ballot Position Update] New position, Discuss, has been recorded
2011-04-12
06 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded
2011-04-12
06 Sean Turner
[Ballot discuss]
Hoping that these will be cleared before or on the telechat call:

#1) I have to ask whether this document should be obsoleting …
[Ballot discuss]
Hoping that these will be cleared before or on the telechat call:

#1) I have to ask whether this document should be obsoleting or updating RFC 5053 based on the following text in the introduction:

  The RaptorQ code described herein is a next generation of
  the Raptor code described in RFC5053 [RFC5053].

#2) The IANA considerations are the same as RFC 5053 with the exception of the encoding ID: here 6 in 5053 it's 1.  Should the name be "Raptor Code v2"?
2011-04-12
06 Sean Turner
[Ballot discuss]
Hoping that this one will be cleared before or on the telechat call:

#1) I have to ask whether this document should be …
[Ballot discuss]
Hoping that this one will be cleared before or on the telechat call:

#1) I have to ask whether this document should be obsoleting or updating RFC 5053 based on the following text in the introduction:

  The RaptorQ code described herein is a next generation of
  the Raptor code described in RFC5053 [RFC5053].

#2) The IANA considerations are the same as RFC 5053 with the exception of the encoding ID: here 6 in 5053 it's 1.  Should the name be "Raptor Code v2"?
2011-04-12
06 Sean Turner [Ballot Position Update] New position, Discuss, has been recorded
2011-04-11
06 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded
2011-04-11
06 Stewart Bryant
[Ballot discuss]
I could not see an IPR disclosure in the Last Call text.

I am by no means an IPR expert, but the IPR …
[Ballot discuss]
I could not see an IPR disclosure in the Last Call text.

I am by no means an IPR expert, but the IPR claim seems to imply different terms depending on whether packets containing this protocol are sent over different types of network. That seems contra to the IETF position of wanting to be able to send our protocols over any link type. It therefore seems particularly important that the community's attention be draft to the IPR statement when deciding whether to proceed with the Standard.

I have no technical issue with the document and will clear one this matter has been discussed by the IESG.
2011-04-11
06 Stewart Bryant [Ballot Position Update] New position, Discuss, has been recorded
2011-04-11
06 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded
2011-04-10
06 Robert Sparks [Ballot Position Update] New position, No Objection, has been recorded
2011-03-31
06 Wesley Eddy [Ballot Position Update] New position, Yes, has been recorded
2011-03-22
06 David Harrington State changed to IESG Evaluation from Waiting for AD Go-Ahead.
2011-03-14
06 David Harrington Approval announcement text changed
2011-03-14
06 David Harrington Approval announcement text regenerated
2011-03-14
06 David Harrington [Ballot Position Update] New position, Yes, has been recorded for David Harrington
2011-03-14
06 David Harrington Ballot has been issued
2011-03-14
06 David Harrington Created "Approve" ballot
2011-03-14
06 David Harrington Placed on agenda for telechat - 2011-04-14
2011-03-14
06 David Harrington Area acronym has been changed to tsv from gen
2011-03-08
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-rmt-bb-fec-raptorq-05
2011-03-07
05 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-05.txt
2011-02-09
06 (System) State changed to Waiting for AD Go-Ahead from In Last Call.
2011-02-07
06 Amanda Baber
IANA understands that, upon approval of this document, there is a single
IANA Action that IANA must complete.

In the ietf:rmt:fec:encoding - Fully-Specified FEC schemes …
IANA understands that, upon approval of this document, there is a single
IANA Action that IANA must complete.

In the ietf:rmt:fec:encoding - Fully-Specified FEC schemes (0-127) in
the Reliable Multicast Transport (RMT) FEC Encoding IDs and FEC Instance
IDs registry located at:

http://www.iana.org/assignments/rmt-fec-parameters/rmt-fec-parameters.xhtml

a single new value will be registered as follows:

Value: tbd
Description: RaptorQ Code
Reference: [RFC-to-be]

IANA notes that the authors have requested the value of 6 to be used for
this identifier.
2011-02-02
06 David Harrington Request for Last Call review by TSVDIR is assigned to Marshall Eubanks
2011-02-02
06 David Harrington Request for Last Call review by TSVDIR is assigned to Marshall Eubanks
2011-02-01
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Nicolas Williams
2011-02-01
06 Samuel Weiler Request for Last Call review by SECDIR is assigned to Nicolas Williams
2011-01-26
06 Cindy Morgan
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: …
State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RaptorQ Forward Error Correction Scheme for Object Delivery) to Proposed Standard


The IESG has received a request from the Reliable Multicast Transport WG
(rmt) to consider the following document:
- 'RaptorQ Forward Error Correction Scheme for Object Delivery'
  as a 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@ietf.org mailing lists by 2011-02-09. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-rmt-bb-fec-raptorq/
2011-01-26
06 David Harrington Last Call was requested
2011-01-26
06 David Harrington State changed to Last Call Requested from Expert Review.
The expert review can be done at the same time as IETF LC.
2011-01-26
06 (System) Ballot writeup text was added
2011-01-26
06 (System) Last call text was added
2011-01-26
06 (System) Ballot approval text was added
2011-01-26
06 David Harrington State changed to Expert Review from AD Evaluation.
seeking tsvdir review, especially for the math sections
2011-01-25
06 David Harrington
AD Evaluation:

Technical and process concerns:
1) This document includes linear algebraic calculations, and I have not done linear algeabra since college, so I am …
AD Evaluation:

Technical and process concerns:
1) This document includes linear algebraic calculations, and I have not done linear algeabra since college, so I am asking for expert review.
2) in section 7, IANA actually performs assignments, not this document. This would be better rephrased as IANA is requested to assign a value under the ietf:rmt:fec: encoding name-space to "RaptorQ Code", preferably the value 6.

Editorial:
I found the English parts of this document well-written, but it might benefit from a few editorial changes.
1) In 4.4.1.2, the third paragraph starts with the statement that function partition takes input parameters I and J. But this text doesn't describe what those two values represent. The second sentnece decsribes the purpose of Partition. It would be easier on the reader to state the purpose before showing the processing. i.e., put the second and third sentences before the first sentence.
2) in 4.4.2, the text "Otherwise, only whole symbols MUST be included." (So if otherwise is false - the last block is NOT a partial block - then the requirement for whole blocks does not apply?) I think this is slightly ambiguous, and might be better stated as "Otherwise, the packet MUST contain only whole symbols"
3) in 5.1.1, LT is defined by self-reference. If somebody doesn't what LT menas, they probably don't what an LT neighbor is.
4) section 5 defines variables and functions that are used in earlier sections. It would seem to make sense to move section 5.1 forward so the definition preceded the usage, i.e prior to section 3.
5) section 5.2 talks about a pseudo-random generator. Is this consistent with other IETF uses of pseudo-random, e.g., in the SEC area? In SEC, there are serious consequences of random or pseudo-random numbers being predictable. Are there any serious consequences of these numbers being predictable?
6) in 5.3.3.3, a number of terms are used before being defined nearby: LDPC and HDPC and PI, for example. I recommend that on first use, it be treated as "Low Density Parity Check (LDPC)"
7) While terms like LDPC are defined in the terminolgy section, if a reader doesn't know what a Low Density Parity Check is, this definition is not helpful. I would be good if the terminology section had pointers to informative references.
8) in 5.3.3.3, "evaluate to zero" using what types of mechanisms?  I recommend this section describe what readers are expected to know before reading this, such as a basic understanding of linear algebra. The recommendation could be in the Introduction if so desired.
9) in 5.3.3.4, s/inSection/in Section/
10) in 5.4.2.1, s/in Sections Section 5.3/in Section 5.3/  -- check this
11) I had a bit of difficulty parsing the sentence "Furthermore, for each such encoding symbol it is assumed that the number and set of intermediate symbols whose sum is equal to the encoding symbol is passed to the decoder." If I parse it correcetly, should this be "the number and set ... are passed"? Why are you assuming? Is this not definitive?
12) in 5.8, s/generated generated/generated/
2010-12-20
06 David Harrington State changed to AD Evaluation from Publication Requested.
2010-09-21
06 Cindy Morgan
"draft-ietf-rmt-bb-fec-raptorq-04" intended for publication in the "Proposed Standard" category.

This writeup complies with the current publication writeup template.

  (1.a)  Who is the Document Shepherd …
"draft-ietf-rmt-bb-fec-raptorq-04" intended for publication in the "Proposed Standard" category.

This writeup complies with the current publication writeup template.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Document Shepherd is Brian Adamson, who has personally
reviewed this version of the document and believes it is ready
for forwarding to the IESG for publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document had adequate review both from key WG members
and from key non-WG members.  In fact an independent reviewer was able
to develop an implementation from the specification and provided feedback
to the document authors.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No additional reviews needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

An IPR disclosure related to this document was filed by Qualcomm Incorporated. 
See the following link: https://datatracker.ietf.org/ipr/1292/

The RMT WG discussed this matter concluding that it wished to publish
this document.  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.


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represent a solid consensus of the RMT WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

No notable discontent, except for the IPR discussion, see point (1.d).

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

The Document Shepherd has personally verified that the document
satisfies all ID nits.  It should be noted that some of the nomenclature
in the document causes some false alarms (warnings) in the ID Nits check.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The document splits its references into normative and
informative. There are no downward references.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists, it is consistent with the rest
of the document and is consistent with the registration guidelines
specified in RFC 5052. No new registry is defined. No Expert Review
Process is necessary for the IANA assignments requested by this document.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

The documents contains no section written in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents. 

Document Announcement Write-Up follows.

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.

Document Quality

    The document quality is high.  It 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.

Brian Adamson is the Document Shepherd.
Dave Harrington is the Responsible Area Director.

2010-09-21
06 Cindy Morgan Draft added in state Publication Requested by Cindy Morgan
2010-09-21
06 Cindy Morgan [Note]: 'Brian Adamson (adamson@itd.nrl.navy.mil) is the document shepherd.' added by Cindy Morgan
2010-08-24
04 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-04.txt
2010-06-22
03 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-03.txt
2010-03-18
(System) Posted related IPR disclosure: QUALCOMM Incorporated's Statement about IPR related to draft-ietf-rmt-bb-fec-raptorq-02
2010-03-08
02 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-02.txt
2010-02-11
01 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-01.txt
2010-01-28
00 (System) New version available: draft-ietf-rmt-bb-fec-raptorq-00.txt