[Ballot comment]

- 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)