Subject: [Gen-art] A *new* batch of IETF LC reviews - 27 Jan 2011

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 27 Jan 2011 12:30:11 -0600

Hi all,

Here's the link to the new LC assignments:
http://www.softarmor.com/rai/temp-gen-art/reviewers-110127-lc.html

The assignments are captured in the spreadsheets:
http://www.softarmor.com/rai/temp-gen-art/gen-art.html
http://www.softarmor.com/rai/temp-gen-art/gen-art-by-reviewer.html

The standard template is included below.

Thanks,

Jean

-------------------------------------------------------------------

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:
Reviewer:
Review Date:
IETF LC End Date:
IESG Telechat date: (if known)

Summary:

Major issues:

Minor issues:

Nits/editorial comments:

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 27 Jan 2011 17:35:05 -0500

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