AD review: draft-ietf-rmt-bb-fec-raptorq-04

Hi,

I have reviewed this draft and have the follwoing comments:

Technical and process concerns:
1) This document includes linear algebraic calculations, and I have
not done linear algeabra since college, so I am asking for expert
review.
2) in section 7, IANA actually performs assignments, not this
document. This would be better rephrased as IANA is requested to
assign a value under the ietf:rmt:fec: encoding name-space to "RaptorQ
Code", preferably the value 6. 

Editorial:
I found the English parts of this document well-written, but it might
benefit from a few editorial changes.
1) In 4.4.1.2, the third paragraph starts with the statement that
function partition takes input parameters I and J. But this text
doesn't describe what those two values represent. The second sentnece
decsribes the purpose of Partition. It would be easier on the reader
to state the purpose before showing the processing. i.e., put the
second and third sentences before the first sentence. 
2) in 4.4.2, the text "Otherwise, only whole symbols MUST be
included." (So if otherwise is false - the last block is NOT a partial
block - then the requirement for whole blocks does not apply?) I think
this is slightly ambiguous, and might be better stated as "Otherwise,
the packet MUST contain only whole symbols"
3) in 5.1.1, LT is defined by self-reference. If somebody doesn't what
LT menas, they probably don't what an LT neighbor is.
4) section 5 defines variables and functions that are used in earlier
sections. It would seem to make sense to move section 5.1 forward so
the definition preceded the usage, i.e prior to section 3.
5) section 5.2 talks about a pseudo-random generator. Is this
consistent with other IETF uses of pseudo-random, e.g., in the SEC
area? In SEC, there are serious consequences of random or
pseudo-random numbers being predictable. Are there any serious
consequences of these numbers being predictable?
6) in 5.3.3.3, a number of terms are used before being defined nearby:
LDPC and HDPC and PI, for example. I recommend that on first use, it
be treated as "Low Density Parity Check (LDPC)"
7) While terms like LDPC are defined in the terminolgy section, if a
reader doesn't know what a Low Density Parity Check is, this
definition is not helpful. I would be good if the terminology section
had pointers to informative references.
8) in 5.3.3.3, "evaluate to zero" using what types of mechanisms?  I
recommend this section describe what readers are expected to know
before reading this, such as a basic understanding of linear algebra.
The recommendation could be in the Introduction if so desired.
9) in 5.3.3.4, s/inSection/in Section/
10) in 5.4.2.1, s/in Sections Section 5.3/in Section 5.3/  -- check
this
11) I had a bit of difficulty parsing the sentence "Furthermore, for
each such encoding symbol it is assumed that the number and set of
intermediate symbols whose sum is equal to the encoding symbol is
passed to the decoder." If I parse it correcetly, should this be "the
number and set ... are passed"? Why are you assuming? Is this not
definitive?
12) in 5.8, s/generated generated/generated/

David Harrington
Director, IETF Transport Area
[email protected] (preferred for ietf)
[email protected]
+1 603 828 1401 (cell)