I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-avt-rtp-amr-bis-05
Reviewer: Harald Alvestrand
Review Date: September 22, 2006
IETF LC Date: 2006-09-11
IESG Telechat date: (if known)
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.
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
