I have been selected as the General Area Review Team (Gen-ART) reviewer
for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-rmt-bb-fec-ldpc-06.txt
Reviewer: Brian Carpenter
Review Date: 2007-10-17
IETF LC End Date: 2007-10-22
IESG Telechat date: (if known)
Summary: Almost ready, two concerns

Comments: 

I have one technical and one IPR concern.

Technical:

4.2.3.  Scheme-Specific Elements

   The following elements MUST be defined with the present FEC Scheme:

   o  G: a non-negative integer indicating the number of encoding
      symbols per group (i.e. per packet).  The default value is 1,
      meaning that each packet contains exactly one symbol.  Values
      greater than 1 can also be defined, as explained in Section 5.3.

   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.
  
At first sight, the word "optional" conflicts with "MUST be defined."
If I understand the intent correctly, this would be better expressed as
something like
      This element MAY be present in the FEC OTI... If the PRNG seed
      is not carried within the FEC OTI, the encoder and decoders
      MUST use another way...

However, if this is a correct description of the intention, I believe it
leaves the way open for interoperability issues. It means that encoders
and decoders from different implementers might be incompatible. This would
scrape past in an Experimental protocol but seems wrong in a Proposed Standard.
Shouldn't all implementations be obliged to support transmission of the
seed in the FEC OTI, as a "MUST implement, MAY configure" feature?

IPR:

There are code extracts in the draft. There is also a statement in
the Introduction that

   A publicly available reference implementation of these codes is
   available and distributed under a GNU/LGPL license [8].

I believe it would be desirable to add an explicit statement that
the code extracts in the draft are directly contributed to the IETF 
process by their authors (i.e., they are are not subject to LGPL).


Nits:
=====

id-nits finds reference errors:

 == Outdated reference: draft-ietf-rmt-fec-bb-revised has been published as
     RFC 5052

  == Outdated reference: A later version (-04) exists of
     draft-ietf-rmt-flute-revised-03

  == Outdated reference: A later version (-05) exists of
     draft-ietf-rmt-pi-norm-revised-04