Re: [tsvwg] Datatracker State Update Notice: <draft-ietf-tsvwg-rlc-fec-scheme-09.txt>

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

Dear Wes the Document Shepherd,

So, here's the deal on this one. (the companion draft is approved, pending
my review of revisions to address comments, so don't worry about that one)

On Thu, Oct 11, 2018 at 9:51 AM IETF Secretariat <
[e-mail]> wrote:

> IESG state changed:
>
> New State: IESG Evaluation::Revised I-D Needed
>
> (The previous state was IESG Evaluation)
>
>
> Datatracker URL:
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-rlc-fec-scheme/


The most significant concerns that I was catching on today's telechat for
this draft were basically related. Everything else seems to be on track to
resolve (even the question about the copyright is off as a question to the
lawyer).

Multiple ADs expressed concerns based on using code as a normative
specification, based on their experience in RAI/ART with the OPUS codec,
specified in https://tools.ietf.org/html/rfc6716#appendix-A as a reference
implementation.

I am told that everyone working on OPUS decided that was the right thing to
do then, and has now decided it was the wrong thing to do now.

There are two problems they ran into:

   - Ensuring that their reference implementation is consistent across
   generations of processors and compilers, with people using different
   versions of the C language, turns out to be really hard. Whether C89, C99,
   C11, C18, or some future version of the language will suddenly return
   unexpected results on some processor that hasn't been tested, really can't
   be known in practice. So this isn't as stable a specification as we would
   have thought it would be.
   - Worse(!), after the publication of RFC 6716, everyone immediately
   extracted the code from the RFC and started changing it for their product
   implementations. So when the working group started to update the codec
   specification, which involved changing the reference implementation, all
   the implementers had to figure out what to change in their modified code to
   match the changes in the reference implementation, and that turned out to
   be a nightmare.

So, the question to me, and now to you, is, "do you REALLY want to do this?
Because we wanted to do this with OPUS, and we all thought it was a great
plan, and we were wrong, and we don't understand why this will turn out
better than OPUS".

The theory is that this mechanism would be pretty simple to express in
text.

We didn't discuss this, but I suspect that if the implementation was an
example, and not a reference implementation, that would help a lot.

The ADs who have the most experience with this issue for OPUS are Ben
Campbell, Adam Roach, and Eric Rescorla (yeah, he's a SEC AD, but also
worked on OPUS).

If you would like for me to put this on an agenda for the next informal
telechat (would be a week from today), I'd be happy to do that.

If you would like for me to arrange a meeting in Bangkok with one or more
of these ADs, I'd be happy to do that (I'd start with Ben, who actually
closed CODEC).

Please let me know how you/the working group would like to proceed.

Spencer