Basic Forward Error Correction (FEC) Schemes
draft-ietf-rmt-bb-fec-basic-schemes-revised-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 Jari Arkko |
2009-01-22
|
06 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-01-22
|
06 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-01-22
|
06 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2008-12-22
|
06 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2008-12-16
|
06 | (System) | IANA Action state changed to In Progress |
2008-12-15
|
06 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2008-12-15
|
06 | Cindy Morgan | IESG state changed to Approved-announcement sent |
2008-12-15
|
06 | Cindy Morgan | IESG has approved the document |
2008-12-15
|
06 | Cindy Morgan | Closed "Approve" ballot |
2008-12-11
|
06 | Amy Vezza | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Amy Vezza |
2008-12-11
|
06 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley |
2008-12-11
|
06 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to No Objection from Discuss by Jari Arkko |
2008-12-11
|
06 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2008-12-11
|
06 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2008-12-11
|
06 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-12-11
|
06 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-12-10
|
06 | Pasi Eronen | [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen |
2008-12-10
|
06 | Jari Arkko | [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block … [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block > length are encoded as unsigned integers, of length 48 bits, 16 bits > and 32 bits respectivly. In what units are the length values expressed, bits, bytes, four octets, etc? I had to read much further into the document to find out some text that seemed to indicate symbol lengths were expressed in bytes. So it would be good to make the format say this explicitly. Please check the other similar fields in the documents as well. Secondly, I grepped the document for occurrences of the word "max" to find out what are the semantics of the Max Source Block Length Field. All I found was the format, and the explanation that it is a non- negative integer. Shouldn't its use be described somewhere? Again, I'm sure I'm missing something, and certainly someone who is not reading his first RMT RFC would know the answer immediately. And I have not had any coffee yet this morning. |
2008-12-10
|
06 | Jari Arkko | [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block … [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block > length are encoded as unsigned integers, of length 48 bits, 16 bits > and 32 bits respectivly. In what units are the length values expressed, bits, bytes, four octets, etc? I had to read much further into the document to find out some text that seemed to indicate symbol lengths were expressed in bytes. So it would be good to make the format say this explicitly. Please check the other similar fields in the documents as well. Secondly, I grepped the document for occurrences of the word "max" to find out what are the semantics of the Max Source Block Length Field. All I found was the format, and the explanation that it is a non- negative integer. Shouldn't its use be described somewhere? Again, I'm sure I'm missing something, and certainly someone is not reading his first RMT RFC would know the answer immediately. And I have not had any coffee yet this morning. |
2008-12-10
|
06 | Jari Arkko | [Ballot comment] There were typos, e.g., correspondance Exprimental interger reciever respectivly specifictions |
2008-12-10
|
06 | Jari Arkko | [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block … [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block > length are encoded as unsigned integers, of length 48 bits, 16 bits > and 32 bits respectivly. In what units are the length values expressed, bits, bytes, four octets, etc? I had to read much further into the document to find out some text that seemed to indicate symbol lengths were expressed in bytes. So it would be good to make the format say this explicitly. Please check the other similar fields in the documents as well. Secondly, I grepped the document for occurrences of the word "max" to find out what the semantics of the Max Source Block Length Field. All I found was the format, and the explanation that it is a non- negative integer. Shouldn't its use be described somewhere? Again, I'm sure I'm missing something, and certainly someone is not reading his first RMT RFC would know the answer immediately. And I have not had any coffee yet this morning. |
2008-12-10
|
06 | Jari Arkko | [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block … [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block > length are encoded as unsigned integers, of length 48 bits, 16 bits > and 32 bits respectivly. In what units are the length values expressed, bits, bytes, four octets, etc? I had to read much further into the document to find out some text that seemed to indicate symbol lengths were expressed in bytes. So it would be good to make the format say this explicitly. Please check the other similar fields in the documents as well. Secondly, I grepped the document for occurrences of the word "max" to find out what the semantics of the Max Source Block Length Field. All I found was the format, and the explanation that it is a non- negative integer. Shouldn't its use be described somewhere. Again, I'm sure I'm missing something, and certainly someone is not reading his first RMT RFC would know the answer immediately. And I have not had any coffee yet this morning. |
2008-12-10
|
06 | Jari Arkko | [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block … [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block > length are encoded as unsigned integers, of length 48 bits, 16 bits > and 32 bits respectivly. In what units are these length values expressed, bits, bytes, four octets, etc? I had to read much further into the document to find out some text that seemed to indicate symbol lengths were expressed in bytes. So it would be good to make the format say this explicitly. Please check the other similar fields in the documents as well. |
2008-12-10
|
06 | Jari Arkko | [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block … [Ballot discuss] I'm sure I'm missing some information somewhere else, but the document says: > The Transfer Length, Encoding Symbol Length and Maximum Source Block > length are encoded as unsigned integers, of length 48 bits, 16 bits > and 32 bits respectivly. In what units are these length values expressed, bits, bytes, etc? I had to read much further into the document to find out some text that seemed to indicate symbol lengths were expressed in bytes. So it would be good to make the format say this explicitly. |
2008-12-10
|
06 | Jari Arkko | [Ballot Position Update] New position, Discuss, has been recorded by Jari Arkko |
2008-12-10
|
06 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-12-10
|
06 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-12-10
|
06 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-12-10
|
06 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-12-10
|
06 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-10
|
06 | Russ Housley | [Ballot comment] As pointed out by Elwyn Davies in his Gen-ART Review: s9, para 2: s/ces/References/ |
2008-12-10
|
06 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-12-10
|
06 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-12-10
|
06 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2008-11-18
|
06 | Magnus Westerlund | Telechat date was changed to 2008-12-11 from 2008-12-04 by Magnus Westerlund |
2008-11-03
|
06 | Magnus Westerlund | [Ballot Position Update] New position, Yes, has been recorded for Magnus Westerlund |
2008-11-03
|
06 | Magnus Westerlund | Ballot has been issued by Magnus Westerlund |
2008-11-03
|
06 | Magnus Westerlund | Created "Approve" ballot |
2008-11-03
|
06 | Magnus Westerlund | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup by Magnus Westerlund |
2008-11-03
|
06 | Magnus Westerlund | Placed on agenda for telechat - 2008-12-04 by Magnus Westerlund |
2008-10-31
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-10-31
|
06 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-06.txt |
2008-08-06
|
06 | Sam Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Hilarie Orman. |
2008-08-04
|
06 | Magnus Westerlund | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for AD Go-Ahead by Magnus Westerlund |
2008-08-04
|
06 | Magnus Westerlund | Waiting for updates to address last call comments in Gen-art review and IANA comments. |
2008-07-29
|
06 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-07-25
|
06 | Amanda Baber | IANA Last Call comments: QUESTION: should references to this document actually replace references to [RFC3695] and [RFC3452], rather than supplement them? … IANA Last Call comments: QUESTION: should references to this document actually replace references to [RFC3695] and [RFC3452], rather than supplement them? Action 1: Upon approval of this document, the IANA will make the following changes in the "ietf:rmt:fec:encoding" registry located at http://www.iana.org/assignments/rmt-fec-parameters OLD: Value Description Reference ----- ----------------------------- --------- 0 Compact No-Code [RFC3695] NEW: Value Description Reference ----- ---------------------------- --------- 0 Compact No-Code [RFC3695,RFC-rmt-bb-fec-basic-schemes-revised-05] Action 2: Upon approval of this document, the IANA will make the following changes in the "ietf:rmt:fec:encoding" registry located at http://www.iana.org/assignments/rmt-fec-parameters OLD Value Description Reference Section ------- ------------------------------------- ----------- 128 Small Block, Large Block and Expandable FEC Codes [RFC3452] 5.1 129 Small Block Systematic FEC Codes [RFC3452] 5.2 130 Compact FEC [RFC3695] NEW: Value Description Reference Section ------- ------------------------------------- ----------- 128 Small Block, Large Block and Expandable FEC Codes [RFC3452,RFC-rmt-bb-fec-basic-schemes-revised-05] 129 Small Block Systematic FEC Codes [RFC3452,RFC-rmt-bb-fec-basic-schemes-revised-05] 130 Compact FEC [RFC3695,RFC-rmt-bb-fec-basic-schemes-revised-05] |
2008-07-18
|
06 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2008-07-18
|
06 | Sam Weiler | Request for Last Call review by SECDIR is assigned to Hilarie Orman |
2008-07-15
|
06 | Amy Vezza | Last call sent |
2008-07-15
|
06 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-07-15
|
06 | Magnus Westerlund | State Changes to Last Call Requested from AD Evaluation::AD Followup by Magnus Westerlund |
2008-07-15
|
06 | Magnus Westerlund | Last Call was requested by Magnus Westerlund |
2008-07-15
|
06 | (System) | Ballot writeup text was added |
2008-07-15
|
06 | (System) | Last call text was added |
2008-07-15
|
06 | (System) | Ballot approval text was added |
2008-07-14
|
06 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-07-14
|
05 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-05.txt |
2008-04-18
|
06 | Magnus Westerlund | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Magnus Westerlund |
2008-04-18
|
06 | Magnus Westerlund | Comments sent to the WG mail list. |
2008-04-17
|
06 | Magnus Westerlund | State Changes to AD Evaluation from Publication Requested by Magnus Westerlund |
2008-04-07
|
06 | Magnus Westerlund | draft-ietf-rmt-bb-fec-basic-schemes-revised-04 intended for publication in the "Proposed Standard" category. This writeup complies with RFC 4858. (1.a) Who is the Document Shepherd for this … draft-ietf-rmt-bb-fec-basic-schemes-revised-04 intended for publication in the "Proposed Standard" category. This writeup complies with RFC 4858. (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 key WG members and from key non-WG members. The document provides information in the context of the RMT "FEC Building Blocks" for a range of expected FEC code variants. The document provides a reference framework that non fully-specified FEC codes can use for incorporation in RMT protocols and has been used for such in working implementations. It also provides a framework for "No-Code" FEC types that may be used for testing purposes. (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. There are no specific concerns or known IPR issues with this document. (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 summarise 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 discontent has been noted. (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 ID nits are satisfied. There _is_ an intentional reference to an earlier version of FEC Building Block (RFC 5052) and the nit checker misinterprets a line using brackets "[]" for array notation as a reference. (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. 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 draft-ietf-rmt-fec-bb-revised. No new registry is defined. This document does update/obsolete some previous FEC descriptions that have registered code types within in the "ietf:rmt:fec:encoding" namespace, but no new registry entries are requested. (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. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? 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? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? Document Announcement Write-Up follows. Technical Summary This document is an optional Building Block usable to fully define an RMT Protocol. The document describes some "basic" FEC schemes in the context of RMT protocols. It provides FEC Object Transport Information (OTI) formats for a couple of expected common FEC forms. A "No-Code" type is also specified that may be used for testing or other purpose. This document provides a template for developers that may wish to implement non-fully-specified FEC codes (as described in RFC5052) in RMT protocols presuming the FEC code matches one of the general types (Small Block, Large Block, etc) described in this document. Working Group Summary There is consensus in the WG to publish these documents. Document Quality The FEC basic scheme implementation has been used in working RMT NORM implementations to described Reed Solomon (RS) code variants until the fully-specified standard for RS Encoding was published. Brian Adamson is the Document Shepherd. Magnus Westerlund is the Responsible Area Director. |
2008-04-07
|
06 | Magnus Westerlund | State Changes to Publication Requested from AD is watching by Magnus Westerlund |
2007-11-17
|
06 | (System) | State Changes to AD is watching from Dead by system |
2007-11-16
|
04 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-04.txt |
2007-08-27
|
06 | (System) | State Changes to Dead from AD is watching by system |
2007-08-27
|
06 | (System) | Document has expired |
2007-02-24
|
06 | (System) | State Changes to AD is watching from Dead by system |
2007-02-23
|
03 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-03.txt |
2006-09-04
|
06 | (System) | State Changes to Dead from AD is watching by system |
2006-09-04
|
06 | (System) | Document has expired |
2006-04-03
|
06 | Magnus Westerlund | Shepherding AD has been changed to Magnus Westerlund from Allison Mankin |
2006-03-04
|
06 | Allison Mankin | Draft Added by Allison Mankin in state AD is watching |
2006-03-03
|
02 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-02.txt |
2005-10-20
|
01 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-01.txt |
2005-07-15
|
00 | (System) | New version available: draft-ietf-rmt-bb-fec-basic-schemes-revised-00.txt |