Re: Last Call: draft-ietf-rmt-bb-fec-rs (Reed-Solomon Forward Error Correction (FEC) Schemes) to Experimental RFC

Vincent,

My apologies for a really late response and thanks for the detailed 
analysis.

I largely agree with your conclusions and the current n-algorithm is 
indeed operational. However, I still feel that it unnecessarily limits 
how the server can choose n, however lightly, and, since it's not really 
required for interop between the server and the client, I think it'd be 
nice to change the use of n-algorithm for Reed-Solomon to RECOMMENDED 
instead of the implied MUST. That is, the first paragraph in section 6.2 
could be rephrased to something like the following:

"The following algorithm, also called "n-algorithm", explains how to 
determine the actual number of encoding symbols for a given block. It is 
RECOMMENDED that the algorithm be used by the server to determine n and 
max_n; it MAY be used by the client to get an estimate of n. If the 
client uses the n-algorithm, it MUST be prepared to handle symbols with 
ESNs higher than the computed n, e.g. it can choose to simply drop them."

I guess the last sentence is not really necessary, it's what any robust 
implementation will do regardless of the algorithm used.

Also, it'd be nice to mention more explicitly that the use of the block 
partitioning algorithm is a MUST for FEC Encoding IDs 2 and 5 (it's 
already stated as a MAY for 129) rather than implying this within 
n-algorithm description.

Thank you,
Igor Slepchin