Document: draft-ietf-avt-rtp-amr-bis-05
Reviewer: Harald Alvestrand
Review Date:  September 22, 2006
IETF LC Date: 2006-09-11

Summary: Almost ready for reissuing as Proposed

Comments:

I found this a very slow document to read. It's fairly information-dense, and is in an unfamiliar area.
That is not a complaint; it is more an explanation of why the review has taken longer than I'd have liked.

This document is an update to RFC 3267. This means that the technology basically can't change much without harming interoperability, and I mainly read it for understandability and new features.

I found the technology described difficult to get to grips with. It is a type of communication that relies enormously on out-of-band negotiation (witness the number of parameters in section 8), where any error in negotiation will cause an inability to communicate, while also doing a little bit of inband negotiation (the CMR feature described in section 3.3).
This also means that it's really hard to decode a bitstream captured on the wire without also having captured the out-of-band negotiation; since there is only a dozen or two modes, that's no security, but it makes debugging more difficult.
However, that's a decision that was made before 3267 was written, so it's not reasonable to ask for a change here.

I found the "required to implement" hard to find in this document. Section 3.3 says that all codecs have to support *all* of the bit rates defined there, but that the transport system might limit the available modes (without specifying why) while section 4.5 states that *none* of the operating modes are mandatory to implement. There is a SHOULD for 2 modes of single audio channel in that section; I don't understand why it is not a MUST.

If SHOULD is the desired thing, then I think it would be wise to say something on the order of "any specification that uses this codec SHOULD specify at least one operating mode as mandatory for that application of the codec". See the discussion of interoperable ciphers in TLS for a parallel.

There are some language and spelling errors ("tothe"), and some stylistic choices I disagree with (I like CRCs, not CRC's - the CRC doesn't own anything). These can be handled at the RFC Editor stage.

Apart from the issue of "required to implement", I found no technical choice that I disagreed with and see as reasonable to change at this stage in the process.