[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] FW: New Version Notification for draft-ietf-fecframe-interleaved-fec-scheme-03
Hi,
I am sorry that I did not review the draft before since I am not subscribed
to fecframe and AVT was not cc'ed on the WGLC.
I have some editorial comments:
1. In section 1 you reference RFC2733, I think it was obsolete by RFC 5109 ,
do you need this downref?
2. In the registration section 5.1, the comments applies to all subtypes:
2.1 You have for security considerations and published specification
"this document" it is better to write RFC xxxx and have a note to the
RFC editor to replace it with the RFC number allocated, this will show in
the IANA registry with the write pointer.
2.2 In the restriction on usage I assume that the document is using RTP
framing and is not specified for other types, if this is the case it
should say so. E.g. " This media type depends on RTP framing, and hence is
only defined for transfer via RTP [RFC3550]. Transport within other
framing protocols is not defined at this time"
2.3 You need to add the "additional information" that is in the template
probably saying none
3. In section 5.2.1 it looks like you require symmetry between the send and
received stream. Is this your requirement.
4. In section 5.2.1 can the answerer send a response with no FEC at all even
if not offered.
5. In section 5.2.2 Can the receiver just ignore the fec stream, the text
has a MUST use the configuration that is offered which can hint that it MUST
use FEC.
6. In section 7 you discuss an exchange using grouping. Is it also allowed
to use FEC withoutout grouping using the video or audio media types like
section 14 in RFC 5109
Thanks
Roni Even
-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On Behalf Of Ali C.
Begen (abegen)
Sent: Sunday, April 19, 2009 12:04 AM
To: fecframe at ietf.org
Cc: avt at ietf.org
Subject: [AVT] FW: New Version Notification for
draft-ietf-fecframe-interleaved-fec-scheme-03
This update addresses all the comments received in the WGLC period initated
on April 1st. If there are further comments, please post them soon as we
would like to move forward with this draft.
http://www.ietf.org/internet-drafts/draft-ietf-fecframe-interleaved-fec-sche
me-03.txt
BR,
-acbegen
-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org]
Sent: Saturday, April 18, 2009 1:58 PM
To: Ali C. Begen (abegen)
Subject: New Version Notification for
draft-ietf-fecframe-interleaved-fec-scheme-03
A new version of I-D, draft-ietf-fecframe-interleaved-fec-scheme-03.txt has
been successfuly submitted by Ali Begen and posted to the IETF repository.
Filename: draft-ietf-fecframe-interleaved-fec-scheme
Revision: 03
Title: RTP Payload Format for 1-D Interleaved Parity FEC
Creation_date: 2009-04-18
WG ID: fecframe
Number_of_pages: 31
Abstract:
This document defines a new RTP payload format for the Forward Error
Correction (FEC) that is generated by the 1-D interleaved parity code
from a source media encapsulated in RTP. The 1-D interleaved parity
code is a systematic code, where a number of repair symbols are
generated from a set of source symbols and sent in a repair flow
separate from the source flow that carries the source symbols. The
1-D interleaved parity code offers a good protection against bursty
packet losses at a cost of decent complexity. The new payload format
defined in this document is used (with some exceptions) as a part of
the DVB Application-layer FEC specification.
The IETF Secretariat.
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt