Request to review type in draft-ietf-fecframe-interleaved-fec-scheme

[Bjoern Hoehrmann]

* Magnus Westerlund wrote:
>This document
>http://www.ietf.org/id/draft-ietf-fecframe-interleaved-fec-scheme-06.txt
>has been through an IETF last call. Unfortunately this hasn't been
>announced on this list either in WG last call or when the IETF last call
>started. Thus I would like a review before bringing this to the IESG. I
>would be thankful if the review could happen before the 7th of January.
>However, if a committed reviewer needs additional time due to the
>holidays that can be granted. But please tell me so that I can postpone
>the IESG review.
>
>Here is the media type template for the 4 types present in this document.

I think it's confusing to re-iterate the same text in each template; the
templates in RFCs are not used out of context, later templates should
just reference the first one. I could not immediately find a rationale
for registering the same sub type under 4 different top level types. It
would be helpful if someone could post one to this list, and it should
be added in the introductory section 5.1.

>   Required parameters:
>
>   o  rate:  The RTP timestamp (clock) rate.  The rate SHALL be larger
>      than 1000 Hz to provide sufficient resolution to RTCP operations.
>      However, it is RECOMMENDED to select the rate that matches the
>      rate of the protected source RTP stream.

I am not sure from this what the syntax is, the text makes it sound
like rate="1001 Hz" might be it. Perhaps something like "The RTP time-
stamp (clock) rate in Hz. The rate SHALL be larger than 1000 ..." to
make it clearer. Alternatively "an integer ..." like some of the other
parameters say.

>   o  repair-window:  The time that spans the source packets and the
>      corresponding repair packets.  An FEC encoder processes a block of
>      source packets and generates a number of repair packets, which are
>      then transmitted within a certain duration.  At the receiver, the
>      FEC decoder tries to decode all the packets received within the
>      repair window to recover the missing packets.  Assuming that there
>      is no issue of delay variation, the FEC decoder SHOULD NOT wait
>      longer than the repair window since additional waiting would not
>      help the recovery process.  The size of the repair window is
>      specified in microseconds.

Here the syntax definition is also just "time".

>   Applications that use this media type:  Multimedia applications that
>   want to improve resiliency against packet loss by sending redundant
>   data in addition to the source media.

That's perhaps a bit too promotional and unspecific.

>   Additional information:  None.

(I note that it is common for RTP-only types to omit this section.)
-- 
Björn Höhrmann · mailto:bjoern at hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/