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

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.

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.

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."