Re: [Fecframe] Review for draft-ietf-fecframe-rtp-raptor-02

[Colin Perkins <csp at csperkins.org>]

Hi,

I have some comments, in addition to those made by Ali. This looks  
like a decent initial draft, but  does not appear to be ready for  
working group last call.

Section 4.1: what timestamp rate is used?

Section 4.3 is empty? This seems to be missing the important content  
that describes how the payload format works.

Section 6.x:
- The change controller is listed as the AVT working group, but AVT  
has never seen this draft. This draft should be presented in AVT and  
the WG last call should be copied to the AVT list.

- The "rate" is a required parameter for RTP payload formats, but  
isn't listed here.

The offer/answer considerations in Section 8 cannot be "None." if this  
is to be used with SDP offer/answer, such as with SIP. This section  
needs to specify how the parameters are to be negotiated.

Section 9: again, this cannot be "None", and needs to specify how the  
media parameters are to be used with declarative SDP.

Section 11 (Security Considerations) is insufficient. At minimum, the  
security considerations from the Raptor FECFRAME draft, RFC 3550 and  
any applicable RTP profiles apply. See also draft-ietf-avt-rtp-howto-06


Colin






On 28 Oct 2009, at 04:59, Ali C. Begen (abegen) wrote:
> Here is the list of my comments for this draft. As I mentioned  
> earlier, this draft should be reviewed by AVT as well.
>
> - RFC 3550 needs to be cited in the introduction section and in  
> other relevant places.
>
> - Section 3: "... In this case, in the language of the FEC  
> Framework, there is no explicit FEC Source Payload Id." --> "...  
> there is no (need for) explicit ..."
>
> - Section 4.1, Market bit: I believe "shall" should be "SHALL" in  
> this sentence.
>
> - Section 4.1: What about the other fields in the RTP header? If  
> there are no specific usage rules, a note saying that RFC 3550 rules  
> shall apply should be added.
>
> - Section 4.2 and 4.3: This is the part that needs some work. I  
> don't think we can simply refer to the framework and fecframe-raptor  
> drafts and leave these parts (which are the most critical sections  
> in a payload draft) empty. First of all, why is there a reference to  
> the framework draft? Secondly, this section needs to make it clear  
> that the payload draft is for the last FEC scheme introduced in the  
> fecframe-raptor draft (Section 8).
>
> In the current draft, it says there is no (FEC) payload header. So,  
> I guess everything goes into the RTP payload. However, IMO it is  
> better to introduce the Repair FEC Payload ID (section 8.1.3 of the  
> fecframe-raptor draft) as the FEC payload header, and then put the  
> repair symbols as the RTP payload. This makes it a better  
> representation and easier for others to visualize the encoding/ 
> decoding ops.
>
> - Are there any requirements for max-sbl and symbol-size parameters?  
> If yes, they must be stated in every subsection of 6.3.
>
> - Search for " definedf" and replace it with " defined".
>
> - Section 5: Are not there any special considerations for Raptor  
> FEC? The CC section in the framework is pretty generic IMO. Some  
> specific guidelines, if any, would be appropriate to put here. And  
> this section should be moved to the end.
>
> - Section 7: The mapping to the SDP parameters should be explained.  
> There is a boilerplate for it. Just apply it to your document.
>
> - Section 8 and 9: I am pretty sure there are some offer/answer  
> model and declarative SDP considerations. Again, there is a  
> boilerplate for it, but it must be modified a little bit to fit to  
> the specifics of this payload format.
>
> - Section 10: Before IANA considerations, I was hoping to have a  
> section describing the "Protection and Recovery Procedures." The  
> protection part explains how the repair packets are constructed.  
> This can be kept brief with proper references to the fecframe-raptor  
> draft, but there should sufficient text that gives a general idea to  
> the readers. For the recovery procedures, they should be detailed  
> more since even the other draft does not explain this AFAICT.
>
> - An SDP example showing the RTP format parameters is essential.
>
> - Section 11: There is a boilerplate for security considerations  
> section and all RTP payload format drafts use it. That should be  
> included here.
>
> HTH,
> -acbegen



--
Colin Perkins
http://csperkins.org/