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

["Black, David" <[e-mail]>]

Hi Mirja,

> There are currently two contradicting copyright statements.

I respectfully disagree, as use of multiple copyright statements for code is common, particularly when a BSD code license is used.

However, the IESG clearly needs the view of IETF legal counsel on this topic - when might we expect to see that, and how can I help?

Thanks, --David

> -----Original Message-----
> From: tsvwg [mailto:[e-mail]] On Behalf Of Mirja
> Kuehlewind (IETF)
> Sent: Friday, January 18, 2019 5:25 AM
> To: Vincent Roca
> Cc: Emmanuel Baccelli; [e-mail]; Belkacem TEIBI; The IESG
> Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-rlc-fec-scheme-10.txt
> 
> 
> [EXTERNAL EMAIL]
> 
> 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/
> >>
> >