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

["David Harrington" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] On 
> Behalf Of David Harrington
> Sent: Wednesday, January 26, 2011 12:39 PM
> To: [e-mail]
> Subject: [Rmt] 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
> [e-mail] (preferred for ietf)
> [e-mail]
> [phone] (cell)
> 
> _______________________________________________
> Rmt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rmt
>