Subject: [apps-discuss] APPSDIR review of draft-ietf-codec-opus-14

From: Claudio Allocchio <[email-masked]>
Date: Sat, 2 Jun 2012 19:25:02 +0200 (CEST)

Hello all,

I have been selected as the Applications Area Directorate reviewer for 
this draft (for background on appsdir, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you 
may receive. Please wait for direction from your document shepherd or AD 
before posting a new version of the draft.

Document: draft-ietf-codec-opus-14
Title: Definition of the Opus Audio Codec
Reviewer: Claudio Allocchio
Review Date: 02.Jun.2012
IETF Last Call Date: 26.04.2012
IESG Telechat Date: 07.Jun.2012

Summary:

This draft follows a quite unusual specification method: I see the real 
specification as is "a piece of software code", and the text specification 
is intented as an extended "comment" to the software code itself. I 
personally do not have a strong opinion if this method is an acceptable 
IETF practice; for sure it is the opposite of what's normally done, where 
the normative text gives instruction and suggestions on how to write the 
indipendent implementations (mostly software code) later on. If this is 
already common practice, just ignore my comment. If it is not, the IESG 
should consider adding a consideration about this pracice in the published 
document preface.

Apart this general consideation, my guess is that the draft is well 
written and there are no major issues to prevent its publication. As I am 
not an audio engineer, I might, however, have missed some detailes in the 
coding/decoding mathematics, thus a furhter review by an audio engineer 
expert could help.

Major Issues:

The full draft has one only other IETF normative reference... the one 
which all RFCs have: RFC2119. I call this a major issue because I wonder 
how this specification relates to other activities in IETF. It can also be 
a non issue at all, of course. But I'm puzzled... this specification can 
happily live without the internet existance, because the data can be sent 
from the encode to the decoder with any other mean, including a storage 
device. Ok, this is philosophy, but I'm nevertheless puzzled.

Minor Issues:

In general, all over the specification, there is very little reference or 
considerations on what the network trasmission of audio data encoded using 
the Opus codec might be affected by various network conditions. The only 
case which is considered a number of times is the event of a packet (to be 
more exact of "data") loss. What about some considerations about how 
bandwidth, jitter, latency might affect ? Of course this is a generic 
consideration which has to do with buffering the data, but I guess at 
least some comments should be added.

In the introduction the document say that the codec can be used also for 
real time music interactions (I guess over the network). Given the way the 
coded behaves, allowing switching between various modes on the fly, and 
providing support for acoustic echo cancellations (AEC) my guess is that 
this real time music interaction cannot be done using this codec. There 
are other existing applications which allows real time music interaction 
of the network (like the one described at 
http://www.conts.it/artistica/lola-project for example) which rely on 
abolishing all codecs, sending raw audio/video data and using fast 
reliable error free networks to do this. Thus I suggest removing that 
sentence about "real time music interaction"  from the introduction of the 
draft.

2. Opus Codec Overview.

FB (fullband). The draft declares that the codec can be used also for 
music performances. But here it declares that it just "ingnores" anthing 
above 20 Khz because we cannot hear it. This is a well known nonsense in 
music wordld, where all higher frequencies are preserved because they 
anyhow make wave interferences with the others, and create ambience etc. I 
suggest removing that explanation and add another one, for example "even 
if we know this will limit the full quality of the encoded sound, this 
will anyhow result in minor problems, and it is common practice".

2.1.4 Frame duration.

"20ms are a good choice for most applications" 
should be supplemented by adding "however, this already enters the latency 
range where real time interaction experinces difficutlies, in particuar 
for music". It is experimentally know that above 20ms musicians can 
already detect latency and delays.

6. Conformance

the whole section describes a testing and benchmarking procedure which in 
general is not specified by the specification itself. This makes quite 
complex to apply the paradigm of the two indipendent interworking 
implementations, when at lease the "exceptions" makes conpulsory to use 
at least some very same piece of code.

7 Security Considerations.

the text of the first section neutrally applies to any piece of software 
which handles data received by an extenal source, not only this specific 
case. As I pointed out in the beginning, given than this draft is "a piece 
of software with comments" I can understand this part of the security 
consideration which could be named "secure programming considerations". 
However... it this relevant? Ok, it does not harm... but I'd point out 
that this apply to any case in programming.

A. appendix A

as said, it is quite unusual that a piece of code is the specificaton 
itself. As a general IETF practice, is this the correct way to go? Should 
exixt a "reference implementation" of a specification?

  Nits:

none

------------------------------------------------------------------------------
Claudio Allocchio             G   A   R   R          [email-masked]
                         Senior Technical Officer
tel: +39 040 3758523      Italian Academic and       G=Claudio; S=Allocchio;
fax: +39 040 3758565        Research Network         P=garr; A=garr; C=it;

            PGP Key: http://www.cert.garr.it/PGP/keys.php3#ca

---

From: SM <[email-masked]>
Date: Sat, 02 Jun 2012 12:17:59 -0700

Hi Claudio,
>Reviewer: Claudio Allocchio

Thanks for performing this review.  It is the most complex draft I 
have come across.

Regards,
S. Moonesamy