Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <150272618954.396.2989336786082869936.idtracker@ietfa.amsl.com>
Date: Mon, 14 Aug 2017 14:30:27 -0500
Cc: The IESG <iesg@ietf.org>, tterriberry@mozilla.com, codec-chairs@ietf.org, 
 codec@ietf.org, draft-ietf-codec-opus-update@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <EE4F96D5-E98F-4539-8FA1-2993E893F3C1@nostrum.com>
References: <150272618954.396.2989336786082869936.idtracker@ietfa.amsl.com>
To: =?utf-8?Q?Mirja_K=C3=BChlewind?= <ietf@kuehlewind.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/codec/Xn2xYKl5OZJTBQn0PQQwA8NCpCo>
Subject: Re: [codec] 
 =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft?=
 =?utf-8?q?-ietf-codec-opus-update-08=3A_=28with_COMMENT=29?=
Precedence: list


> On Aug 14, 2017, at 10:56 AM, Mirja K=C3=BChlewind =
<ietf@kuehlewind.net> wrote:
>=20
> Mirja K=C3=BChlewind has entered the following ballot position for
> draft-ietf-codec-opus-update-08: No Objection
>=20
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut =
this
> introductory paragraph, however.)
>=20
>=20
> Please refer to =
https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>=20
>=20
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-codec-opus-update/
>=20
>=20
>=20
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>=20
> While I support the publication as this seems to be the right thing =
for me to
> do in this situation, I find it really weird that we have to publish =
an RFC to
> fix bugs in an example implementation in the appendix (that is even =
encoded).
> While it is a good thing to have code in an RFC as far as this helps
> implementation, maybe rfc6716 went to far with putting a whole =
reference
> implementation in there. I guess that has also led to a situation =
where
> everybody is just using the provided code while efforts to reimplement =
the spec
> could have detected these bugs earlier in the process. Maybe it's an =
item for
> the IESG to thinking about how to provide a reference implementation =
with an
> RFC (that maybe can be updated easier) other than just putting it in =
the
> appendix

The reference implementation in the appendix in RFC 6716 is not just an =
example implementation. It contains the normative specification of the =
bit stream decoder=E2=80=94which makes up the majority of the normative =
bits in that document.=20

That has, so far, been a very uncommon approach, and I don=E2=80=99t =
know that we would do it again. But if we choose to do so, I absolutely =
agree we should consider whether it can be done in an easier to update =
fashion.=20

Ben.

>=20
> One more actionable comment: I think the abstract could say more about =
the
> updates, especially maybe noticing that this only updates the code in =
the
> appendix and not the normative language in the body.
>=20
>=20