[Gen-art] Re: Gen-ART review of draft-ietf-avt-rtp-amr-bis-05

[Magnus Westerlund <[e-mail]>]

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

_______________________________________________
Gen-art mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/gen-art