Re: draft-ietf-rmt-fec-bb-revised-01 WG Last-Call

Dear Mark/Mike/Lorenzo,

I have a question related to FEC BB revised (a bit late but...)

Is there any good reason not to include the "n-algorithm" in this
FEC BB framework document? The motivation is the following:

For FEC codes with rate > 0, the decoder usually needs to figure
out the Encoding symbol length value (n) for each source block
(in practice, since only A_large/A_small blocks are considered, this
needs to be done for these two values only).
This information is not carried directly by the FEC OTI or FPI, and
therefore needs to be calculated by both ends.
The method for doing that is fairly simple, but it needs to be made
explicit somewhere (in particular there are several possible choices
when doing double to integer conversions).

You can find the proposed text in section:
5.4  Determining the Number of Encoding Symbols of a Block
of the latest LDPC I-D.

What do you think?

Regards,

  Vincent