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

Colin,

Thanks for these comments. Apologies that it has taken rather a while to get back to you on them. Please see my responses inline.

Best,

Mark

On Oct 29, 2009, at 11:26 AM, Colin Perkins wrote:

> 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?

The one specified in the "rate" parameter, which as you point out is mandatory ;-) I will clarify this.

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

It is not quite empty: the procedures and data formats for generating FEC repair streams are fully defined by the combination of the FEC Framework and an FEC Scheme of your choice. In this case we choose the Raptor FEC Scheme and define how the repair data is carried over RTP. So there is very little to do in this document other than reference the FEC Framework, the Raptor FEC Scheme and to state that the Repair Packet Payload defined in those documents becomes the RTP Payload when RTP is used for the repair flow.

I can add some text to clarify this point, but one thing I do not want to do is duplicate specification material from the FEC Framework or Raptor FEC Schemes.

> 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.

Ok.

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

Ok. I will add it.

> 
> 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.

Ok. I will add some material on this.

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

Ok. I will add some material on this.

> 
> 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
> 

Ok, I will add the references to these documents. Actually in the Raptor FECFRAME draft we do not identify any security considerations over and above those mentioned in the FEC Framework itself. That is, we do not see that the choice of Raptor as an FEC code has any specific security issues which do not apply to the use of FEC in general.

> 
> 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/
> 
> 
> 
> _______________________________________________
> Fecframe mailing list
> Fecframe@ietf.org
> https://www.ietf.org/mailman/listinfo/fecframe