Re: ID Tracker State Update Notice: <draft-ietf-rmt-bb-fec-raptorq-04.txt>

David,
I've implemented the responses to the comments you made.  We'll send out the
official revised RaptorQ spec once the Last Call is finished, but below are
comments on your comments, and attached is an informal Word document that
shows the proposed responses to your comments (that also contains the
suggested fixes in response to the GenArt review from Joel Halpern).
Best, Mike

> AD Evaluation:
> 
> 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.
*** Changed wording as suggested.
> 
> 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.
*** Reorganized and simplified as suggested.

> 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"
*** Reworded as suggested.

> 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.
*** Expanded Section 5.1.1 and deleted Section 5.1.3 (incorporated what was
relevant in this section into 5.1.1).  Added an informative reference to the
"LT codes" paper.

> 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.
*** The reason this is here is that it makes it possible to reference this
section as a stand alone section in other RFCs, i.e., Section 5 is a
self-contained section that describes the RaptorQ code itself, and can be
referenced in a streaming specification using RaptorQ without having to
rewrite a new RaptorQ code specification (we tried to only define what was
needed here to make section 5 standalone).  Earlier, in the spec whatever
relevant definitions are needed are defined and explained there in the
relevant context.

> 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?
*** The only consequence is that if the loss channel is correlated in the
wrong way with the pseudo-random generator then the number of encoding
symbols that need to be received to recover a source block might be higher.
There aren't any security concerns about this, where in the security context
the properties of the pseudo-random generator can dramatically affect the
security of the overall solution (I'm pretty familiar with the issues of a
pseudo-random generator when used in the security context pretty well: see
for example the monograph titled "Pseudorandomness and Cryptographic
Applications", Princeton Univ Press, 1996.)

> 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.
*** Section 5.1.1 has been expanded and annotated to hopefully take care of
these concerns, and as mentioned above there is an informative reference
added to take care of the one "undefined in this text" term: "LT" informally
stands for "Luby Transform", which hopefully we can avoid spelling out and
instead just make the proper reference. ;)

> 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.
*** Retitled Section 5.1 to "Background" and added the relevant math
background there that would be good to have to be able to read and implement
the RaptorQ code.
 
> 9) in 5.3.3.4, s/inSection/in Section/
*** Fixed

> 10)
> in 5.4.2.1, s/in Sections Section 5.3/in Section 5.3/  -- check this
*** Fixed

> 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?
*** Changed "is" to "are".  This is just an example implementation, and how
the information is passed around in the decoder is implementation specific.
We didn't want to mandate a particular implementation here.

> 12) in 5.8, s/generated generated/generated/
*** Fixed.

_______________________________________________
Rmt mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rmt