Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Vincent,

just adding another copyright does not make the existing copyright invalid. Further there is no need to at this copyright in the code as the copyright notice is already at the beginning of the document which covers the whole document including the code. However, that’s exactly the problem. There are currently two contradicting copyright statements.

Mirja



> Am 18.01.2019 um 08:25 schrieb Vincent Roca <[e-mail]>:
> 
> Dear IESG members, all,
> 
> First of all, thanks a lot for your highly valuable feedback. It took us time to consider
> them all, we sometimes significantly changed some parts of the I-D, but here is the
> result.
> 
> Because there are many comments, we first answer globally (main  topics, TinyMT32
> and parameter derivations) in this email, and in a second email we go through each
> comment, as it appears in: 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/ballot/
> 
> Once again, thanks you.
> Cheers,
> 
>   Vincent, Belkacem, Emmanuel.
> 
> 
> 
> PART I:  GLOBAL ANSWERS
> 
> 
> 1- About TinyMT32 source code
> -----------------------------
> 
> ** A PRNG specified through C code is now unavoidable
> 
> Time passed and trivial PRNGs like the Linear Congruential one are no longer sufficient.
> TinyMT32 is defined by the authors through its C reference codec. Extracting a pseudo-code
> description is not feasible.
> 
> 
> ** Clearing the copyright issue (hopefully)
> 
> Being a derived work, we added the following copyrigh after the original licence:
> NEW:
>    /**
>     * The derived work of this document is:
>     * Copyright (c) 2018 IETF Trust and the persons identified as the
>     * document authors. All rights reserved.
>     */
> 
> The licence itself is not an issue as the original authors' and IETF Trust licences are the same.
> 
> 
> ** Addressing IESG concerns on TinyMT32 deterministic behavior
> 
> PRNG determinism, for a given seed, is a MUST. With Emmanuel Baccelli (new co-author), we:
> 
> - tested on several platforms:
>   In particular we used embedded 32-bits platforms featuring ARM Cortex M* and running RIOT,
>   plus 8-bit and 16-bit platforms (details in Appendix A. "TinyMT32 Validation Criteria (Normative)").
>   Note that TinyMT32 is already the default PRNG in RIOT:
>   https://github.com/RIOT-OS/RIOT/tree/master/sys/random/tinymt32
> 
> - added 3 normative random number sequences:
>   These random number sequences MUST be matched for any implementation of
>   the PRNG to be validated. The Japanese authors already provide one in:
>   https://github.com/MersenneTwister-Lab/TinyMT/blob/master/tinymt/check32.out.txt
>   for the core TinyMT32 functions. We added two new ones for the two functions that
>   scale down to 4 and 8 bits, whose determinism is as important as that of the core
>   functions.
> 
> - moved the normative source code to section 3.5. "Pseudo-Random Number Generator (PRNG)"
>   in order to avoid any confusion on what is normative and informative.
> 
> - removed the dangerous double-float multiplication/divisions.
>   Instead we use define two new functions that scale down the uint32 pseudo-random number
>   generated by the tinymt32_generate_uint32 () core function to the target 4-bit or
>   8-bit interval (used by generate_coding_coefficients()).
>   Using masking to scale down a 32-bit PRNG value is **usually a bad practice**, but
>   here it works. This is discussed in:
>   Appendix B.  Assessing the PRNG Adequacy (Informational)
> 
> ** About C language style in the original TinyMT32
> 
> We cleaned up a few things as suggested.
> 
> 
> 2- About section 3.1. "Possible Parameter Derivations"
> ------------------------------------------------------
> 
> ** We moved all suggestions as "Informational" in Appendix C
> 
>   All the 3.1.* sub-sections provide recommendations (hence the use of
>   "Possible" in the title).
>   It is non normative because doing differently does not break
>   interoperability: an encoder and a decoder written by different programmers
>   will still interoperate (a decoder has enough information to correctly decode).
> 
>   To reflect this, we moved all the 3.1.* sub-sections in an Annex tagged
>   as "(informational)". The remaining Section 3.1 merely introduces the main
>   parameters and refers to the annex for **possible** parameter derivations.
> 
>   NB: already existing FEC Scheme RFCs do not go so far and omit to
>          suggest parameter derivation.  
> 
> 
> ** An additional parameter in the FEC Scheme-Specific Information (FSSI)
> 
>   Adding this parameter avoids the ambiguity in the choice of the arbitrary
>   0.75 parameter in certain formulas for parameter derivation.
> 
>   We add the WSR (window size ratio) parameter, an integer in {0 .. 255}.
>   WSR is communicated at session startup along with the FSSI that anyway
>   needs to be shared between encoder and decoder(s).
>         value 0: ignore         => it's not used because
>                 there's another technique to derive parameters.
>         0 < value < 1:          => use it as follows:
>                 ew_max_size = dw_max_size * WSR / 255
>                 e.g. WSR=191 leads to: 191/255=0.749
>                 191 is suggested as a "reasonable value"
>                 but no longer recommended since it is anyway
>                 communicated to the receiver(s).
>                 Even if there's a rounding "error", it's not a big deal and
>                 it does not compromize interoperability.
> 
> 
>> Le 17 janv. 2019 à 22:12, [e-mail] a écrit :
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>> 
>>        Title           : Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC) Schemes for FECFRAME
>>        Authors         : Vincent Roca
>>                          Belkacem Teibi
>>                          Emmanuel Baccelli
>> 	Filename        : draft-ietf-tsvwg-rlc-fec-scheme-10.txt
>> 	Pages           : 43
>> 	Date            : 2019-01-17
>> 
>> Abstract:
>>   This document describes two fully-specified Forward Erasure
>>   Correction (FEC) Schemes for Sliding Window Random Linear Codes
>>   (RLC), one for RLC over the Galois Field (A.K.A.  Finite Field)
>>   GF(2), a second one for RLC over the Galois Field GF(2^^8), each time
>>   with the possibility of controlling the code density.  They can
>>   protect arbitrary media streams along the lines defined by FECFRAME
>>   extended to sliding window FEC codes, as defined in [fecframe-ext].
>>   These sliding window FEC codes rely on an encoding window that slides
>>   over the source symbols, generating new repair symbols whenever
>>   needed.  Compared to block FEC codes, these sliding window FEC codes
>>   offer key advantages with real-time flows in terms of reduced FEC-
>>   related latency while often providing improved packet erasure
>>   recovery capabilities.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-tsvwg-rlc-fec-scheme-10
>> https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-rlc-fec-scheme-10
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-tsvwg-rlc-fec-scheme-10
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>