FEC Object Transmission Information format for FEC Encoding ID 5 appears to deviate from RFC 5510

[ronald-intvelt]

Per RFC 5510, section 5.2, the format of the EXT_FTI header extension for FEC Encoding ID 5 is:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   HET = 64    |    HEL = 3    |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                      Transfer Length (L)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Encoding Symbol Length (E)  | MaxBlkLen (B) |     max_n     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

where max_n is defined as:

the maximum number of encoding symbols generated for any source block

According to section 6.2, max_n = ceil (B / CR) where CR is the code rate.

However, member function SetFecNumParity() of class NormFtiExtension5 appears to write the number of generated repair symbols (n_r in RFC 5510 notation) into this field of the FTI extension header instead.

[bebopagogo]

Ron - thank you for catching that (and good to hear from you ... I hope all is well as it can be in these crazy times). I guess I assumed "encoding symbols" meant parity symbols without paying close attention to the specification. I will make a note to address that. I will also look to see if I made the same mistake elsewhere. However, it will impact interoperability for existing NORM deployments. I suspect current use cases are generally deploying any NORM code updates uniformly, so I can probably still get away with making the change. It's definitely good to catch it now in case NORM ever gets more popular.

[bebopagogo]

It looks like I was consistent with my mistake and the other FEC Encoding ID object transport information (OTI) fields should be corrected similarly. In fact, this actually points to an error in RFC 5740 where it uses the nomenclature "fec_num_parity" to describe the (OTI) field that corresponds to maximum encoding symbols (max_n). We should probably submit an errata for RFC 5740 to correct this there, too.