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

["Ali C. Begen (abegen)" <abegen at cisco.com>]

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