Subject: Re: [Gen-art] review: draft-ietf-rmt-bb-fec-raptorq-04

From: "Luby, Michael" <[email-masked]>
Date: Thu, 3 Feb 2011 15:52:24 -0800

Joel, We have taken a look at your comments and indeed you have a good
point.  This will be addressed in the revised version that will be provided
after last call is concluded.  Thanks, Mike Luby

On 1/27/11 2:35 PM, "Joel M. Halpern" <[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
> 
> Please resolve these comments along with any other Last Call comments
> you may receive.
> 
> Document: draft-ietf-rmt-bb-fec-raptorq-04
>      RaptorQ Forward Error Correction Scheme for Object Delivery
> Reviewer: Joel M. Halpern
> Review Date: 27-January-2011
> IETF LC End Date: 09-Feb-2011
> IESG Telechat date: N/A
> 
> Summary: This document is ready for publicaiton as a Proposed Standard.
> 
> Note: The reviewer did not attempt to verify the actual FEC behaviors,
> but did focus on whether he believed an implementor could follow the
> instructions to implement the algorithm.  The comments below should be
> considered if the document is revised.
> 
> Major issues: None
> 
> Minor issues:
> It would probably be helpful in section 3.2.3 if there was some comment
> as to why the number of source blocks is a 12 bit field when the last
> paragraph of 3.2.2 says that the number of source blocks is limited to 256.
>      The order of presentation of material in section 5.3 is somewhat
> confusing.  Rather than changing it however, I think it woudl suffice if
> a forward reference, in the text early in 5.3.3.3 is added, saying that
> the algorithm describes here assumes that the C symobls have been
> calculated according to the constraints in section 5.3.3.4.  (The
> challenge appears to be a matter of providing sufficient clarity without
> over-constraining implementors.)
>      In describing the "First Phase" algorithm in section 5.4.2.2, the
> chosing and arranging step seems to ensure that the first row of V has a
> 1 in the first column of V.  Confusingly, the text then refers to the
> chosen row having an entry alpha in the first column of V.  It may be
> that I misread the steps (in which case we should check if clarification
> is needed), it may be that alpha is indeed always 1, in which case we
> should say so, or it may be that the "ones" in the earlier selection
> criteria is merely supposed to be "non-zeros".
> 
> Nits/editorial comments:
>      In 4.4.1.2 when defining the symbols IL, IS, JL, and JS, the
> formula for JL gets split across a line boundary.  It is very easy for a
> reader to miss a piece, and get the completely wrong formula.  (The
> split causes the bind to invert the operator priority, if it does not
> completely miss the extra operation.)