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

[Spencer Dawkins at IETF <[e-mail]>]

Following up as (for a bit longer) responsible AD ... and beginning by
thanking you for your work on this document.

On Fri, Jan 18, 2019 at 4:25 AM Mirja Kuehlewind (IETF) <[e-mail]>
wrote:

> 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.
>

I am not surprised about this, at all.

What I was hoping would be possible, was that you might be able to describe
the characteristics of "deterministic behavior", say "you must use a PRNG
that has these behaviors", and helpfully point out that TinyMT32 is one
such PRNG, with those behaviors, but there may be others (so, the
specification could be implemented without TinyMT32 specifically, making it
an informational reference that you could use without including the code
here).

If that's not possible, I understand, but I wanted to ask that question
clearly before we put you to a lot of work trying to figure out how to keep
TinyMT32 code in this document.

Do you have any thoughts about this?

Spencer


> >  ** 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/
> >>
> >
>
>