Definition of the Opus Audio Codec
RFC 6716

Note: This ballot was opened for revision 14 and is now closed.

(Robert Sparks) Yes

(Ron Bonica) No Objection

(Stewart Bryant) (was Discuss) No Objection

Comment (2012-06-28 for -15)
No email
send info
I am clearing my discuss on the agreement that text similar to the following will be added to header of the files:

"This file is extracted from RFCXXXX. Please see that RFC for additional information." 

Where XXXX will be replaced by the actual RFC number.

I understand similar but more grammatically appropriate text will be added to the README file.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Ralph Droms) No Objection

Comment (2012-06-06 for -14)
No email
send info
Is FEC really an accurate title for the mechanism described in section 2.1.7?

(Wesley Eddy) No Objection

Comment (2012-06-06 for -14)
No email
send info
(non-blocking comments for the AD and editors)

reference [Burg] has nothing but an author and title; it has to be locatable somehow other than google

wikipedia references should be replaced by an actual textbook or other materials, in my opinion

(Adrian Farrel) No Objection

Comment (2012-06-04 for -14)
No email
send info
I am balloting No Objection on this document on the basis that it has
no impact on the internet's routing infrastructure, and that the WG and
ADs have done a substantive review

---

Per the Apps Dir review by Claudio Allocchio, I like the idea of adding
a note (IESG Note?) to this document to highlight and make an exception
of the use of code as a specification language.

(Stephen Farrell) (was Discuss) No Objection

Comment (2012-06-19 for -15)
No email
send info


- I agree that Pete's discuss needs to be resolved. It may be
that there's a way to do that without the IETF trust owning the
code, I don't know. I did also note that celt/pitch.c also has a
CSIRO copyright from 2007-2008.  Were people from CSIRO involved
in the WG? If so, does whatever code is involved constitute an
IETF contribution (I would think so) and has someone checked
that no IPR declarations from CSIRO are needed?  (Same question
applies for all such contributors.) This is (I think) a varition
on Pete's discuss since I guess that people from Xiph and Skype
(the examples he quoted) have been involved in this work so any
IPR declartions from them will have been done already.

- If code comments conflict with the text of the body of the
draft, then which is normative? Its clear that code wins but I'm
not sure about comments within the code.  I'm ok with any
reasonable answer here, but wanted to check.

- The code contains things like "#ifdef FIXED_POINT" which is
commented out in the top level Makefile. If the normative
specification is the source code, what is the normative status
of code that's only conditionally compiled and that is not
compiled with the distributed Makefile? Have all such
conditionally compiled code fragments been tested to the same
extent as the code that is compiled with the default Makefile?
I'm ok with any reasonable answer here, but wanted to check.

- I think a few references to introductory materials about
codecs would be useful in the intro for the poor victim^Wreader
who's handed this and told to implement or optimise opus.

- p13, [SRTP-VBR], RFC 6562, says that VBR SHOULD NOT be used
for "highly sensitive" voice and goes on to say that VBR is ok
if you're just matching the bandwidth but maybe not if the
variation is driven by the speech signal. I think it'd be good
to note both of those aspects here. I'd also personally prefer
if both 6562 and this said "possibly sensitive" rather than
"highly sensitive" since I don't know how code at this layer
could know what's really sensitive or not. This might also be
worth repeating in (or moving to) the security considerations as
well as it would perhaps be more visible there.

nits

- p28, says "This same data MUST also be returned as raw bits
when requested." Requested by whom? I didn't get that.

- p30, says "this draft" s/draft/memo/ or whatever

- p31, says "SHOULD take measures to conceal the error" but
doesn't say what those might be 

- p32, all those "1/8th bit" phrases read oddly to me but maybe
that's standard fare for codec folks.
 
- p151, says that padding is used in CBR mode but doesn't seem
to say what kind of padding. If its the same as for my discuss
(i.e. zero padding) then maybe the same considerations apply
here? (Not sure)

(Brian Haberman) No Objection

Comment (2012-06-06 for -14)
No email
send info
I support both Pete's and Sean's DISCUSS issues.

I will also add that the instructions for extracting the source code does not work on a Mac running OS X 10.7.4.  The base64 utility present in OS X generates an unrecognizable archive format that cannot be decompressed by tar.

(Russ Housley) No Objection

Barry Leiba No Objection

Comment (2012-06-05 for -14)
No email
send info
Substantive comments; these are non-blocking, but please consider them
seriously, and feel free to chat with me about them:

-- 1.1.3 --
                    clamp(lo,x,hi) = max(lo,min(x,hi))

  With this definition, if lo > hi, the lower bound is the one that is
  enforced.

I'm not sure I understand what that text means.  Are you saying that
if, for example, you write "clamp(5,x,2)", it means the same as
"clamp(2,x,5)" ?  If that's the case, then maybe it should be defined
as this:

  clamp(a,x,b) = max(min(a,b),min(x,(max(a,b)))

In any case, please re-phrase the text to make clearer what you mean.

-- 4.4 --
Have packet loss and clock drift been modelled, and have the recommendations in 4.4 and 4.4.1 thus been validated?  There seems to be a lot of speculation there, and I wonder how much basis in real experimentation there is.

========
Other comments; no need to respond to these:

This is easily the most technically dense and esoteric document I've every read, in the IETF or elsewhere.

I'm not qualified to judge most of this document, and I expect that the number of people in the IETF who are can be counted on one hand.  I'm afraid that includes the participants in the codec working group, and that was one of the concerns some of us had when the WG was chartered.  How many in the working group *really* reviewed this entire document, and understand it?  How much consensus is there in the WG and in the IETF as a whole behind this, in all its details?

That said, everything I can tell about this codec is that it's a good one, and that it was worth doing, despite the extraordinary number of IPR statements that apply to it (considering the WG's goals).  So I approve of the publication of it, and I've reviewed it as best I could.

There was concern brought up in the Applications Directorate review about the mechanism of using C code as a specification.  I don't have a concern about that, and find it an acceptable mechanism.

I did find myself wondering idly, as I read section 4.2.7.5.6, whether "cos(pi*n[k])" was intentional, and whether anyone asked Victoria's Secret about an IPR statement with respect to trademark....

(Pete Resnick) (was Discuss) No Objection

Comment (2012-06-28 for -15)
No email
send info
Glad to see the updated copyright statements. Thanks.

As I stated earlier, the files in the git repository cited in the document probably also should have the IETF Trust copyright. Moreover, I would prefer to see the repository hosted on an IETF site rather than on xiph.org. I am concerned about drift of the code on xiph from the code in the RFC and ending up in a situation where the xiph version is -- de facto -- the place to go for the standard.

Like others, I don't feel I can give a substantive review to much of this document and will simply trust that it has gotten sufficient review. The one technical thing I noticed: A few variables that need to be unsigned because they're used in shift right (>>) operations are not explicitly specified as unsigned, in particular ft (used in 4.1.5) and b0 (used in 4.1.1). You do note other variables as unsigned, so I took these as omissions, but it may be clear from context. It seems to me a review of such variables might be useful.

Like other ADs, I have some concerns about the use of source code for the normative spec:

- First of all, this does turn the entire concept of "independent interoperable implementations" on its head. If the source code is normative, I don't see how we could ever judge that an implementation was independent and therefore how this spec would be advanced along the standards track.

- Furthermore, I've got some concerns that we may, at some point in the future, encounter a small edge case where the code simply has a bug, but the text of the document makes it clear what the intention was. I would hate for us to say, "Well, the code is the normative reference, so the bug must stand and we must update the descriptive text to suit." I doubt that would happen, but we are in unchartered waters by using source as the normative spec.

- Finally, the source code here is in base64, compressed, tarred format. It is completely unreadable in the spec. I do not know of any other RFC that has humanly-unreadable text in it. Again, we are in completely unchartered waters.

And it is these "unchartered waters" that are the real issue all around. We may need to discuss how we handle this document now and in the future. But we signed up for this in the charter, so I'm willing to see it play out. There is no doubt that this document is an entirely odd duck.

(Martin Stiemerling) No Objection

Comment (2012-06-05 for -14)
No email
send info
A nit:
Section 3., paragraph 1:

[...]
>    the internal framing used to pack multiple frames into a single
>    packet.  This framing is not self-delimiting.  Instead, it assumes
>    that a higher layer (such as UDP or RTP [RFC3550] or Ogg [RFC3533] or
>    Matroska [Matroska-website]) will communicate the length, in bytes,

  You mean that some lower layer (UDP, RTP, etc) will take care
 of this. Those are not higher layers in the IETF sense.

(Sean Turner) (was Discuss) No Objection