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

From: [email-masked]
Date: Thu, 17 Jan 2019 13:12:18 -0800

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/

---

From: Vincent Roca <[email-masked]>
Date: Fri, 18 Jan 2019 08:25:22 +0100

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, [email-masked] a écrit :
> 
>

---

From: Vincent Roca <[email-masked]>
Date: Fri, 18 Jan 2019 08:34:11 +0100

Dear IESG members, all,

Part II, the long, detailed answers.
Cheers,

  Vincent

---

From: "Mirja Kuehlewind (IETF)" <[email-masked]>
Date: Fri, 18 Jan 2019 11:25:28 +0100

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 <[email-masked]>:
> 
> Dear IESG members, all,
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Fri, 18 Jan 2019 09:11:22 -0600

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) <[email-masked]>
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
>
>
>

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

> >>        Title           : Sliding Window Random Linear Code (RLC)
> Forward Erasure Correction (FEC) Schemes for FECFRAME
> >>        Authors         : Vincent Roca
> >>                          Belkacem Teibi
> >>                          Emmanuel Baccelli

---

From: "Black, David" <[email-masked]>
Date: Mon, 21 Jan 2019 14:41:48 +0000

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:[email-masked]] On Behalf Of Mirja
> Kuehlewind (IETF)
> Sent: Friday, January 18, 2019 5:25 AM
> To: Vincent Roca
> Cc: Emmanuel Baccelli; [email-masked]; 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
> 
> 
> 
> >   https://github.com/MersenneTwister-
> Lab/TinyMT/blob/master/tinymt/check32.out.txt

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Mon, 21 Jan 2019 16:52:35 -0600

Hi, David,

On Mon, Jan 21, 2019 at 8:44 AM Black, David <[email-masked]> wrote:

> 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

(snip)

There's been a certain amount of to/cc trimming and adding on Mirja's
discuss thread, by multiple ADs, and maybe by other folk, so I'm not sure
who has actually seen this response from the IETF counsel, Brad Biddle.

So, at least we are all starting from the same place now?

Spencer

 > Am 14.10.2018 um 00:25 schrieb Brad Biddle <[email-masked]>:
>
> Alissa and all — I think the inclusion of BSD-licensed code with a third
party copyright notice is inconsistent with the literal requirements of BCP
78, as Mirja and Adam suggest in then thread below. Further, I don’t think
that the TLP provision or blog post that Adam cites necessarily suggest
support in spirit for this approach (I believe each are making different
points, described further below). I agree with Adam’s conclusion that there
is likely little practical impact here of including BSD licensed code with
a copyright notice of a third party instead of the IETF, given that the
rights are functionally identical either way. But think there are several
reasons to NOT simply proceed with this as our practice, absent an explicit
decision to do so and and effort to align our practices and IPR documents
accordingly:
>
>       • Of course, we should follow the rules we set for ourselves, and
the “additional copyright notices are not permitted” [1] rule is clear. BCP
78 does have an explicit exception process that that doesn’t seem
applicable here. I don’t read either TLP Section 4 [2] or the cited blog
post [3] as providing or suggesting additional exceptions. The TLP Section
4(c) provision that Adam cites is focused on clarifying that a party that
takes a license from IETF under BSD terms is not simultaneously subject to
Section 3’s more restrictive terms — i.e. it’s a different question than
what we’re discussing here. Likewise, I understand the blog post to be
focused on when an IETF copyright notice is required, and not focused on
the idea of a third party notice. So: I think we have an unambiguous rule
of no third party copyright notices.
>
>       • More substantively, the rights that the IETF gets under our
normal BCP 78 terms and the rights we get when licensing in code under BSD
terms are not identical. BCP 78 enables essentially unlimited future use by
the IETF. BSD licensed code comes with some additional (modest)
restrictions, such as the requirement to always provide particular required
notices and disclaimers with any reuse. If we take in contributions under
different terms, we have to make sure we manage our use to map to those
terms. Our normal BCP 78 model avoids this problem: we get all
contributions in under identical, broad terms.
>
>       • Here, and I suspect in future cases if we were to make this a
practice, it’s not clear that labeling the code with only third party
notices is appropriate. In this case I gather that there were some
IETF-specific
tweaks. Assuming these are reflected in copyrightable elements of the code,
it’s inaccurate to only list the original copyright owners and not IETF.
>
> I suggest that we ask the authors of this code to provide to IETF as a
normal BCP 78 “Contribution,” and then include the code with an IETF
copyright notice. If they don’t want to do so (or can’t for some reason),
then I suggest removing the code from the draft.
>
> If there is a desire to include third party BSD code on a ‘license-in =
license-out’ basis, I think that’s potentially feasible, but I’d suggest we
explicitly change our rules to address this scenario, and consider whether
there are are practical implications for how we manage our contributions if
we have materials coming in under two different licensing models.
>
> Please let me know if you think I’m missing something. Happy to discuss
further, of course.
>
> Thanks,
> Brad
> (IETF legal counsel)
>
> Brad Biddle | [email-masked] | +1.503.502.1259 (mobile) |
http://biddle.law

---

From: Vincent Roca <[email-masked]>
Date: Tue, 22 Jan 2019 22:43:35 +0100

Dear Spencer, Mirja, David, all,

Thanks a lot for help. From the official IETF counsel answer (I never saw it before), I see the best option is
to engage discussions with the two TinyMT32 authors.

I’ll do that tomorrow, keeping only Wes in CC (our shepherd) to avoid annoying you all (otherwise tell me).
I’ll let them choose between two options: 

- they authorize us to remove their copyright and licence (since I also understand there’s a slight difference
  in the licence) in the existing I-D;

- or they co-author with us a new I-D that only focusses on the core PRNG that we add as normative reference
  to this I-D. In that case we'll just keep the two mapping functions in the RLC I-D (it’s really specific to RLC and
  masking is **usually a bad practice**).

Cheers,

  Vincent

> Le 21 janv. 2019 à 23:52, Spencer Dawkins at IETF <[email-masked]> a écrit :
> 
> Hi, David,
> 
> On Mon, Jan 21, 2019 at 8:44 AM Black, David <[email-masked] <mailto:[email-masked]>> wrote:
> Hi Mirja,
> 
> There's been a certain amount of to/cc trimming and adding on Mirja's discuss thread, by multiple ADs, and maybe by other folk, so I'm not sure who has actually seen this response from the IETF counsel, Brad Biddle. 
> 
> > Alissa and all — I think the inclusion of BSD-licensed code with a third party copyright notice is inconsistent with the literal requirements of BCP 78, as Mirja and Adam suggest in then thread below. Further, I don’t think that the TLP provision or blog post that Adam cites necessarily suggest support in spirit for this approach (I believe each are making different points, described further below). I agree with Adam’s conclusion that there is likely little practical impact here of including BSD licensed code with a copyright notice of a third party instead of the IETF, given that the rights are functionally identical either way. But think there are several reasons to NOT simply proceed with this as our practice, absent an explicit decision to do so and and effort to align our practices and IPR documents accordingly:
> > 
> >       • Of course, we should follow the rules we set for ourselves, and the “additional copyright notices are not permitted” [1] rule is clear. BCP 78 does have an explicit exception process that that doesn’t seem applicable here. I don’t read either TLP Section 4 [2] or the cited blog post [3] as providing or suggesting additional exceptions. The TLP Section 4(c) provision that Adam cites is focused on clarifying that a party that takes a license from IETF under BSD terms is not simultaneously subject to Section 3’s more restrictive terms — i.e. it’s a different question than what we’re discussing here. Likewise, I understand the blog post to be focused on when an IETF copyright notice is required, and not focused on the idea of a third party notice. So: I think we have an unambiguous rule of no third party copyright notices.
> > 
> >       • More substantively, the rights that the IETF gets under our normal BCP 78 terms and the rights we get when licensing in code under BSD terms are not identical. BCP 78 enables essentially unlimited future use by the IETF. BSD licensed code comes with some additional (modest) restrictions, such as the requirement to always provide particular required notices and disclaimers with any reuse. If we take in contributions under different terms, we have to make sure we manage our use to map to those terms. Our normal BCP 78 model avoids this problem: we get all contributions in under identical, broad terms.
> > 
> >       • Here, and I suspect in future cases if we were to make this a practice, it’s not clear that labeling the code with only third party notices is appropriate. In this case I gather that there were some IETF-specific tweaks. Assuming these are reflected in copyrightable elements of the code, it’s inaccurate to only list the original copyright owners and not IETF.
> > 
> > I suggest that we ask the authors of this code to provide to IETF as a normal BCP 78 “Contribution,” and then include the code with an IETF copyright notice. If they don’t want to do so (or can’t for some reason), then I suggest removing the code from the draft.
> > 
> > If there is a desire to include third party BSD code on a ‘license-in = license-out’ basis, I think that’s potentially feasible, but I’d suggest we explicitly change our rules to address this scenario, and consider whether there are are practical implications for how we manage our contributions if we have materials coming in under two different licensing models.
> > 
> > Please let me know if you think I’m missing something. Happy to discuss further, of course.
> > 
> > Thanks,
> > Brad
> > (IETF legal counsel)
> > 
> > Brad Biddle | [email-masked] | +1.503.502.1259 (mobile) | http://biddle.law <http://biddle.law/>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 22 Jan 2019 16:21:57 -0600

Hi, Vincent,

On Tue, Jan 22, 2019 at 3:43 PM Vincent Roca <[email-masked]> wrote:

>   to this I-D. In that case we'll just keep the two mapping functions in
> the RLC I-D (it’s really specific to RLC and

This sounds like a way forward to me, and I apologize for apparently
managing to notify every single person at the IETF except the guy who was
going to resolve this issue :-) ...

Believe me, that was not my plan!

Mirja and I were talking with Magnus yesterday (and exchanging e-mail this
morning) about which AD gets which working groups, but the default would be
Magnus would be responsible for TSVWG, so I cc him directly on this e-mail
(I'm sure he's on TSVWG, but he may be filtering working group e-mail at a
lower priority than e-mail sent directly to him).

We also talked about this draft, so he'll be aware of the background if we
don't get it approved before Wednesday evening in Prague.

Wes is an excellent shepherd and is one of the TSVWG chairs, but if
anything comes up that you two need a quick response to, please feel free
to include me.

And best wishes in your conversations with the TinyMT32 folk.

Spencer

> party copyright notice is inconsistent with the literal requirements of
> BCP 78, as Mirja and Adam suggest in then thread below. Further, I don’t
> think that the TLP provision or blog post that Adam cites necessarily
> suggest support in spirit for this approach (I believe each are making
> different points, described further below). I agree with Adam’s conclusion
> that there is likely little practical impact here of including BSD licensed
> code with a copyright notice of a third party instead of the IETF, given
> that the rights are functionally identical either way. But think there are
> several reasons to NOT simply proceed with this as our practice, absent an
> explicit decision to do so and and effort to align our practices and IPR
> documents accordingly:
> >
> the “additional copyright notices are not permitted” [1] rule is clear.
> BCP 78 does have an explicit exception process that that doesn’t seem
> takes a license from IETF under BSD terms is not simultaneously subject
> to Section 3’s more restrictive terms — i.e. it’s a different question than
> notices is appropriate. In this case I gather that there were some IETF-specific