Subject: [Fecframe] Last Call: <draft-ietf-fecframe-rtp-raptor-05.txt> (RTP Payload Format for Raptor FEC) to Proposed Standard

From: The IESG <[email-masked]>
Date: Thu, 20 Oct 2011 06:47:16 -0700

The IESG has received a request from the FEC Framework WG (fecframe) to
consider the following document:
- 'RTP Payload Format for Raptor FEC'
  <draft-ietf-fecframe-rtp-raptor-05.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2011-11-03. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document specifies an RTP Payload Format for Forward Error
   Correction repair data produced by the Raptor FEC Schemes.  Raptor
   FEC Schemes are specified for use with the IETF FEC Framework which
   supports transport of repair data over both UDP and RTP.  This
   document specifies the Payload Format which is required for the use
   of RTP to carry Raptor repair flows.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-fecframe-rtp-raptor/

No IPR declarations have been submitted directly on this I-D.

---

From: Vincent Roca <[email-masked]>
Date: Tue, 25 Oct 2011 09:27:50 +0200

Hi everybody,

I've already mentioned this point in March 18th, this year, in the
FECFrame list.

Unless I missed some key sentence, I have the feeling that this
I-D **leaves implicit** the strong requirement that there  must not be any
RTP packet loss (or reordering) before reaching the Fecframe encoder,
i.e. that the RTP Sequence Numbers used to identify  source symbols in
the FEC block are always in sequence.

This is a key requirement that MUST be clearly stated rather than
being left implicit.

I haven't checked carefully in draft-ietf-fecframe-raptor-05, but sections
8.2.2. and 8.2.4. in this I-D do not seem to be more explicit on this point.

This requirement, that is specific to situations where RTP source packets
are left unchanged, and some solutions to mitigate it, have already been
discussed on the list and guidelines have been added in RFC6363:

10.2. Operational and Management Recommendations
[...]
5.  Management of Communication Issues before Reaching the Sending
       FECFRAME Instance:

Cheers,

   Vincent

On Oct. 20, 2011, 15:47, The IESG wrote:
> _______________________________________________
> Fecframe mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/fecframe