[Fecframe] Review for draft-ietf-fecframe-raptor-01

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

- Abstract says " An RTP Payload Type is defined for this latter case. " I'd suggest to remove this sentence as this draft does not provide the payload format.

- Also in the abstract and introduction, it says two FEC schemes are defined. In the Raptor RTP draft, it said three. You might wanna fix it for consistency.

- Introduction:

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair flows,
   respectively.

In case of RTP transport, source and repair data can be in different RTP streams, where they are SSRC multiplexed in the same RTP session. From outside, they look like a single UDP flow. The sentence above contradicts with this. I suggest to change it as follows:

   Per the FEC Framework requirements, the sender MUST transmit the
   source and repair packets in different source and repair streams,
   respectively.

Accordingly, the definitions (source and repair flow) will need to be changed as well in section 4.

- I admit that I did not check all the definitions/formulas in sections 6-8 in detail. 

- Section 8.2.4. What about the length of the RTP header extensions?

- Section 9: No specific security considerations?

- Section 10: I suggest to reference 4756bis instead of 4756 and update the semantics accordingly. Also "a=repair-window: 200" should be "a=repair-window:200" (remove the space). 

- As agreed in the last meeting, the current SDP elements draft says: 

   The variable-length SS-FSSI and FSSI containers transmit the
   information in textual representation and MAY contain multiple
   distinct elements.  For the fully-specified FEC schemes, a full
   description of these elements for both containers MUST be provided.

This will require some changes in the SDP example. The draft also needs to explain the elements that will be used in this textual representation.

HTH,
-acbegen