Request to review type in draft-ietf-fecframe-interleaved-fec-scheme
Bjoern Hoehrmann
derhoermi at gmx.net
Wed Dec 16 12:38:00 CET 2009
* 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/
More information about the Ietf-types
mailing list