RaptorQ Forward Error Correction Scheme for Object Delivery
draft-ietf-rmt-bb-fec-raptorq-06
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
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-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 |