Hi Harald,
Thanks for the review.
Harald Alvestrand skrev:
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.
This is true for most RTP payload format developed the last 5 years.
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.
The codec modes requirements is simply stating a fact that is present in
the codec specification. The reduced set is motivated in section 3.3:
For example, the GSM radio link can only use a subset of at most
four different modes in a given session. This subset can be any
combination of the eight AMR modes for an AMR session or any
combination of the nine AMR-WB modes for an AMR-WB session.
This is to support GW functionality towards circuit switched networks
such as the above mentioned GSM network.
The reason for not mandating any mode is that the applications and their
need is so diverse that we have been hesitant specify such a mode. If I
was able to go back in time then I maybe would change that. However
based on the reality today I prefer not to change this. There are
applications that mandate one and only one mode, while others mandate
others. For example in 3GPP the conversational service mandates the
bandwidth efficient mode, while the streaming mandates the octet-align
mode. Thus applications would need to implement modes they have no use
of or be in violation of the RFC.
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.
This is is not a bad idea.
Section 4.5:
OLD:
No operating mode of the payload format is mandatory to implement.
The requirements of the application using the payload format should
be used to determine what to implement. To achieve basic
interoperability an implementation SHOULD at least implement both
bandwidth-efficient and octet-aligned modes for a single audio
channel. The other operating modes: interleaving, robust sorting,
and frame-wise CRC in both single and multi-channel, are OPTIONAL to
implement.
NEW:
No operating mode of the payload format is mandatory to implement.
The requirements of the application using the payload format should
be used to determine what to implement. To achieve basic
interoperability an implementation SHOULD at least implement both
bandwidth-efficient and octet-aligned modes for a single audio
channel. The other operating modes: interleaving, robust sorting,
and frame-wise CRC in both single and multi-channel, are OPTIONAL to
implement. Any specification that utilize this RTP payload format
SHOULD specify at least one payload format mode as mandatory to
implement.
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.
A number of these have been handled in a updated already available.
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [EMAIL PROTECTED]
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
