Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hello!

From: Vincent Roca [mailto:[e-mail]]
Sent: Tuesday, June 18, 2019 4:46 AM
To: Roman Danyliw <[e-mail]>; Benjamin Kaduk <[e-mail]>
Cc: Vincent Roca <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [tsvwg] Benjamin Kaduk's No Objection on draft-ietf-tsvwg-rlc-fec-scheme-14: (with COMMENT)

Hi Roman, Benjamin, all,

Back to the RLC I-D.
I have copied below the Discuss/Comments made for the -14 version of the document.

Many thanks, the document quality has been further improved.
Cheers,

   Vincent and Belkacem

===

> Roman Danyliw Discuss
> Discuss (2019-05-28)
>
> A few code nits for Section 3.6 so that the code compiles:
> ** To make the combination of this source code and that in draft-ietf-tsvwg-tinymt32 compile requires that the directive “#include <string.h>” be added (for the memset).
>
> ** The final return in Section 3.6 is missing a semicolon:
> s/return 0/return 0;/

[VR] Done. I usually don't add system headers to focus on key aspects, but it does not hurt. And thanks for the ";".

===

> Comment (2019-05-28)
>
> (1) Section 3.5  Is there any guidance that needs to be provided on the value of the seed to tinymt32_init?

[VR] Good point. Anything is accepted, which is now clearly stated. Since we already discuss Repair_Key management (this repair_key is used as seed), we refer to section 6.1.

NEW:
   With the FEC Schemes defined in this document, the seed is in
   practice restricted to a value between 0 and 0xFFFF inclusive (note
   that this PRNG accepts a seed value equal to 0), since this is the
   Repair_Key 16-bit field value of the Repair FEC Payload ID
   (Section 4.1.3).  In practice, how to manage the seed and Repair_Key
   values (both are equal) is left to the implementer, using a
   monotonically increasing counter being one possibility (Section 6.1).


> (2) Section 3.6.  In the code comments for cc_nb, I recommend explicitly stating:
> s/number of entries in the table/
> number of entries in the cc_tab[] table/

[VR] Done.


> (3) Section 3.6.  Multiple C code fragments are used in the text.  Somewhere the text should state that the examples are C code and made a reference to what version -- consider C99 (ISO/IEC 9899:1999), C11 (ISO/IEC 9899:2011), C18 (ISO/IEC 9899:2018).

[VR] Yes. I added the same C99 normative reference as in the TinyMT32 I-D
and included some text to clearly state it. I did it for both Sections, 3.5
and 3.6.

NEW (3.6):
   Figure 3 shows the reference generate_coding_coefficients()
   implementation.  This is a C language implementation, written for C99
   [C99].


> (4) Other References Nits
> Section 1.  Please include a reference for FECFRAME on first introduction.

[VR] Done.

> Section 1.1.  What is the reference for Raptor/RaptorQ?

[VR] Added RFC6681.


> (6) Editorial Nits
> Abstract.  No references are permitted in the abstract

[VR] Removed.

> Section 1.1.  Multiple Typos.  s/either a end-/either an end-/g
> Section 1.2.  Extra space. s/constraints) ./constraints)./
> Section 1.4.  Multiple Typos.  s/signalling/signaling/g
> Section 6.2.  Typo.  s/Section Section 3.6/Section 3.6/

[VR] Done. Thanks.

[Roman] Thank you for making these changes.  They address all of my feedback.

Regards,
Roman