Low Density Parity Check (LDPC) Staircase and Triangle Forward Error Correction (FEC) Schemes
draft-ietf-rmt-bb-fec-ldpc-08

[Ballot comment]
I'm not happy publishing code that fails to check the return
value of malloc() in a standard.  I recommend either explicitly stating
such checks are omitted for clarity of examples, or put them in.

[Ballot discuss]
The document needs a normative reference for base64 as used in section 4.2.4.2.

It could be to the XML schema document, or to RFC 4648.

[Ballot comment]
The authors should be commended for the great improvement in the Security Considerations
section between draft -06 and -07.  The current text is probably *too* prescriptive, given that
the broad applicability of the LDPC staircase and triangle FECs.  I can not in good conscience
block this document for being too perscriptive, since the changes were a vigorous response to
a secdir review of the fec-rs draft, but I do believe that the points Steve Kent raised in his
re-review of that document should be addressed.  I have appended his re-review comments
below.

--- re-review comments on fec-rs section 9 (security considerations), which are identical to
section 8 of this draft  ---

I appreciate the efforts of the authors to make this section more precise and technically accurate.  However, in retrospect, I wonder if a document that is so broad in its scope of applicability (it contains no normative references to ANY specific protocols for multicast content distribution) ought to make statements about requirements for specific security mechanisms. I think it might be appropriate to remove the MAYs and SHOULDs from this section, and just cite examples of relevant IETF standards that are probably appropriate for use in this context. Also, the authors need not assume the burden of making security recommendations for all multicast content distribution schemes.  They should focus only on the need for such security relative to use of FEC. This is what they sate in the intro to section 9, but the text that follows tends to ignore this statement in most instances.

Section 9.2.1

        IPsec is misspelled.

        The use of "access control" here seems a bit odd.  We usually say that encryption is employed to provide confidentiality for objects during transmission (or in storage).  We say that access control is afforded to objects in storage, or to machines or networks. Finally, since the focus of this document is use of FEC in a multicast context, this section should refer to MSEC documents that describe use of IPsec confidentiality in that context, not just RFC 4303, if the section is retained.

        I think this subsection should be removed, or substantially reduced in size, since the authors note that there appear to be no confidentiality implications of using FEC in this context.

Section 9.2.2

        the discussion of object-level integrity and authentication discusses PKCS #1. I think that a reference to RFC 3852 (CMS) would be more appropriate, as it is standards track while PKCS #1 is Informational.  Also I question the use of MAY here, given the overall flavor of this document, and the lack of a similar requirements statement for any of the other alternatives presented in this subsection.

        The discussion of ECC use needs to be improved. First, it is not clear that ECC is fast enough and imposes low enough overhead to make it an acceptable per-packet solution in all contexts, contrary to what the text here suggests.  Also, the comments about ECC patent claims should be softened (and the phrase "proprietary patents" is poor English).

        TESLA may be fine in some contexts, but here too the authors seem to endorse it too broadly, given the very general nature of the multicast content distribution contexts where the FEC technology might be employed. Soften the text a bit here as well.

        The very brief discussion of key management here is probably not worth including, since it is bereft of any citations to relevant IETF standards.

        Since IETF specs like this are oriented toward protocol developers, the following statement seems odd: "It is up to the developer and deployer, who know the security requirements and features of the target application area, to define which solution is the most appropriate."  Just refer to the content distribution  protocol developers, not users or "deployers."

Section 9.3

        The recommendation for use of an XML signature to protect FEC OTI when it is carried in an FDT Instance makes sense, given that this data structure is an XML construct. If FEC OTI is sent out-of-band, then the corresponding recommendation should be more specific, e.g., to use CMS, rather than just saying "digitally signing it."

[Ballot discuss]
The document Introduction says:
  >
  > A publicly available reference implementation of these codes is
  > available and distributed under a GNU/LGPL license [LDPC-codec].
  > Besides, the code extracts included in this document (except
  > Appendix A that is only provided as an example) are directly
  > contributed to the IETF process by the authors of this document and
  > by Radford M. Neal.
  >
  However, the code in Appendix A mentions another author, Robin Whittle.
  We either need a similar contribution from this author or we need to
  remove the code that was written by this author.

[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place. The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts. I would have included the type declarations for the loop variables or complete functions, however. Or added an explicit warning where this is not convenient.

Finally, code appears within the text and its hard to determine whether it is normative or informative, except for the appendix which is informative.

[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place. The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts, perhaps even some simplification that the authors did to the code. I would have included the type declarations for the loop variables.

Finally, code appears within the text and its hard to determine whether it is normative or informative, except for the appendix which is informative.

[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place.
The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts, perhaps even some simplification that the authors did to the code. I would have included the type declarations for the loop variables.

Finally, code appears within the text and its hard to determine whether it is normative or informative.

[Ballot comment]
The code excerpts look like C, but do not really compile due to a number of problems. Not all type declarations for h, i, j, and so on in place.
The definition of the "rand" function within the code collides with a different definition and different argument list from POSIX, should this code be used within a program that needs to include standard header files.

I applaud the authors for including code -- and I can see that its well written. We should have more RFCs with C code in them. The problems relate to including code excerpts, perhaps even some simplification that the authors did to the code.

Finally, code appears within the text and its hard to determine whether it is normative or informative.

[Ballot discuss]
Based on the Gen-ART Review by Brian Carpenter.

  Section 4.2.3 includes the following:
  >
  > o  PRNG seed: the seed is a 32 bit unsigned integer between 1 and
  >    0x7FFFFFFE (i.e. 2^^31-2) inclusive.  This value is used to
  >    initialize the Pseudo Random Number Generator (Section 5.6).  This
  >    element is optional.  Whether or not it is present in the FEC OTI
  >    is signaled in the associated encoding format through an
  >    appropriate mechanism (Section 4.2.4).  When the PRNG seed is not
  >    carried within the FEC OTI, it is assumed that encoder and
  >    decoders use another way to communicate the information, or use a
  >    fixed, predefined value.
  >
  I understand the desire for optional transmission of the seed to save
  32 bits when this FEC OTI is carried within an EXT_FTI header extension.
  There is a risk that independent developers use different seed values
  when the value is carried out-of-band.  Solving this concern requires
  a "MUST implement and MUST configure" (rather than "MUST implement and
  MAY configure").  A default value is another possible consideration.

  There are code extracts in the document, and the Introduction says:
  >
  > A publicly available reference implementation of these codes is
  > available and distributed under a GNU/LGPL license [8].
  >
  It would be desirable to add an explicit statement that the code
  extracts in the document are directly contributed to the IETF process
  by their authors (i.e., they are are not subject to LGPL).  To this
  end, the authors have proposed:
  >
  > The code extracts in this document are directly contributed to the
  > IETF process by their authors, unless otherwise mentionned.
  >
  The document authors don't own the copyright of all of the source code,
  and therefore cannot contribute it to the IETF process. This is the
  case for Pseudo Random Number Generator in Section 5.6 and the Parity
  Check Matrix Creation in Section 6.2.  The origin of this source code
  is clearly stated.  There has been a huge amount of discussion about
  source code in RFCs, and it is not clear that the rights offered are
  adequate for a standards track RFC.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Reliable Multicast Transport (RMT) FEC
Encoding IDs and FEC Instance IDs - per [RFC5052]" registry located
at
http://www.iana.org/assignments/rmt-fec-parameters
sub-registry "ietf:rmt:fec:encoding"

Value| Description | Reference
-----+ ---------------------------+---------
3 | LDPC Staircase Codes | [RFC-rmt-bb-fec-ldpc-06]
4 | LDPC Triangle Codes | [RFC-rmt-bb-fec-ldpc-06]

We understand the above to be the only IANA Action for this document.

Technical Summary

    This document is an optional Building Block usable to fully define
    an RMT Transport Protocol.  It fully-specifies Low Density Parity
    Check (LDPC) Forward Error Correction (FEC) Codes within the guidelines
    of draft-ietf-rmt-fec-bb-revised. It also specifies procedures and
    packet-header fields, as required by draft-ietf-rmt-fec-bb-revised.

    The combination of this document and draft-ietf-rmt-fec-bb-revised
    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).
   
    LDPC FEC codes generate parity symbols using a sparse set of source
    symbols.  The LDPC codes described in this document belong to the class of
    large block codes, which means they can easily operate on blocks that are
    composed of a huge number of source symbols.  For bulky information content,
    this is a great advantage over similar small-block FEC codes, like the popular
    Reed-Solomon codes, that can also work over a packet erasure channel.
Working Group Summary

    There is consensus in the WG to publish these documents.

Document Quality

    The authors have a working, open source implementation of the FEC algorithms
    this document describes.  The FEC implementation has been used in working
    RMT protocol code.

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