Skip to main content

Last Call Review of draft-ietf-payload-melpe-04

Request Review of draft-ietf-payload-melpe
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2017-01-13
Requested 2016-12-21
Authors Victor Demjanenko , David Satterlee
I-D last updated 2016-12-25
Completed reviews Genart Last Call review of -04 by Brian E. Carpenter (diff)
Opsdir Last Call review of -04 by Carlos Pignataro (diff)
Genart Telechat review of -05 by Brian E. Carpenter (diff)
Assignment Reviewer Brian E. Carpenter
State Completed
Review review-ietf-payload-melpe-04-genart-lc-carpenter-2016-12-25
Reviewed revision 04 (document currently at 06)
Result Ready w/issues
Completed 2016-12-25
Gen-ART Last Call review of draft-ietf-6tisch-minimal-17

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

Document: draft-ietf-payload-melpe-04.txt
Reviewer: Brian Carpenter
Review Date: 2016-12-26
IETF LC End Date: 2017-01-13
IESG Telechat date:  

Summary: Ready with minor issues

Major Issues: None

Minor issues:

> 3.1  MELPe Bitstream Definition
>   The total number of bits used to describe one frame of 2400 bps
>   speech is 54, which fits in 7 octets (with two unused bits). For the
>   1200 bps speech the total number of bits used is 81, which fits in 11
>   octets (with seven unused bits). For the 600 bps speech the total
>   number of bits used is 54, which fits in 7 octets (with two unused
>   bits).  Unused bits are coded as described in 3.3 in support of
>   dynamic bit-rate switching.

It would help the reader if the last sentence said something like:

   Unused bits, shown below as RSVA, RSVB, etc., are coded as described
   in 3.3 in support of dynamic bit-rate switching.

> 3.3  Multiple MELPe frames in a RTP packet
>   When dynamic bit-rate switching is used and more than one frame is
>   contained in a RTP packet, it is recommended to inspect the coder
>   rate bits contained in the last octet.  If the coder bit rate
>   indicates a Comfort Noise frame, then inspect the third last octet
>   for the coder bit rate.  All MELPe speech frames in the RTP packet
>   will be of this same coder bit rate.

I agree with the AD review that this should be RECOMMENDED.

> 4.2  Mapping to SDP
>   Alternative encoding name types,
>   "MELP2400", "MELP1200", and "MELP600", may be used in SDP to convey
>   fixed bit-rate configurations. 

I think that should be MAY. If you really want to discourage this usage,
you would need to say SHOULD NOT. Lower-case "may" is unclear in this case.

> 6  Packet Loss Concealment

The "may" and "recommended" in this section are unclear - should they

According to the writeup "There are existing implementations." It's a shame
that there is no Implementation Status section (RFC 6982).


"declaritive" should be "declarative" (twice)

> 3.4  Congestion Control Considerations
>   The target bitrate of MELPe can be adjusted at any point in time,
>   thus allowing efficient congestion control.  Furthermore, the amount

I would rephrase "efficient congestion control", because at present the
word "efficient" isn't really justified by the text. How about
"thus allowing straightforward congestion management"?

>   of encoded speech or audio data encoded in a single packet can be
>   used for congestion control, since the transmission rate is inversely
>   proportional to the packet duration.

Make that "the packet rate", because "transmission rate" could refer to the
bit rate or the packet rate. At the moment the reader might miss that until
the following sentence.