Subject: [Rmt] AD review: draft-ietf-rmt-bb-fec-raptorq-04

From: "David Harrington" <[email-masked]>
Date: Wed, 26 Jan 2011 12:38:44 -0500

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-masked] (preferred for ietf)
[email-masked]
+1 603 828 1401 (cell)

---

From: "David Harrington" <[email-masked]>
Date: Wed, 26 Jan 2011 18:40:41 -0500

Hi,

The next step will be to start an IETF Last call on the document.
I have started the LC

On point #1, I am asking for a tsvdir volunteer to review the math
portions.
This is a process point that I will oversee. The WG needs do nothing
on this point.
The expert review can be done at the same time as IETF LC.

For all the rest of my points, these are purely editorial changes.
Save these editorial changes and treat them as LC comments.
i.e., a new revision is not needed at this time.
We will want a new revision after IETF LC to address these and other
comments.

dbh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of David Harrington
> Sent: Wednesday, January 26, 2011 12:39 PM
> To: [email-masked]
> Subject: [Rmt] AD review: draft-ietf-rmt-bb-fec-raptorq-04
> 
> Hi,
> 
> _______________________________________________
> Rmt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rmt
>