Skip to main content

Basic Forward Error Correction (FEC) Schemes
draft-ietf-rmt-bb-fec-basic-schemes-revised-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    rmt mailing list <rmt@ietf.org>, 
    rmt chair <rmt-chairs@tools.ietf.org>
Subject: Protocol Action: 'Basic Forward Error Correction (FEC) 
         Schemes' to Proposed Standard 

The IESG has approved the following document:

- 'Basic Forward Error Correction (FEC) Schemes '
   <draft-ietf-rmt-bb-fec-basic-schemes-revised-07.txt> as a Proposed Standard

This document is the product of the Reliable Multicast Transport Working 
Group. 

The IESG contact persons are Magnus Westerlund and Lars Eggert.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-rmt-bb-fec-basic-schemes-revised-07.txt

Ballot Text

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. 
    This is an update of the experimentally published version.

Personal

    Brian Adamson is the Document Shepherd.
    Magnus Westerlund is the Responsible Area Director.

Note to RFC Editor
 
3.2.2.2.

OLD:

   Transfer-Length:  a non-negative integer less than 2^^48.

   Encoding-Symbol-Length:  a non-negative integer less than 2^^16.

   Maximum-Source-Block-Length:  a non-negative integer less than 2^^32.

NEW:

   Transfer-Length:  a non-negative integer, less than 2^^48, indicating

      the length of the object in octets

   Encoding-Symbol-Length:  a non-negative integer, less than 2^^16, 
      indicating the length of each encoding symbol in octets

   Maximum-Source-Block-Length:  a non-negative integer, less than 2^^32,


      indicating the maximum number of source symbols in a source block

RFC Editor Note