[Fecframe] a few comments on draft-begen-fecframe-sdp-elements-00

[Vincent Roca <[e-mail]>]

Dear Ali,

I've read you I-D and have a few comments. Some of them
are probably a little bit naive, sorry in advance. They may also
reflect the fact that the document is not selft-sufficient...

Cheers,

  Vincent


1/ What are the relationships between this document and the RFC5052
(FEC Building Block)? This document is not mentionned at all in the
references while there are implicit references.
More specifically:
- how does the concept of "scheme ID" relate to the "fully specified
  FEC scheme" or "undert-specified FEC scheme"? Is it an {FEC Enc. ID/
  FEC Inst. ID} equivalent (or FEC Enc. ID in case of fully-specified
  scheme)? Clarification needed e.g., for section 3.3/bullet 3.
  This clarification is also needed since the document says that "Scheme
  ID needs to be registered with IANA" (section 4.5).
- is the FSSI the same as the "Scheme Specific Elements" of RFC5052?


2/ section 3.3, bullet 4:
- This paragraph is a little bit obscure.
  Instead of:
    "However, in the case that the Explicit Source FEC Payload ID is used"
  I think the author should say:
   "A value is greater than zero indicates that an explicit Source
    FEC Payload ID is used. However, in that case, only one FEC scheme..."
- This paragraph does not indicate nor give any reference to the concept
  of "generic tag". The terms "tag" and "Source FEC Payload ID" seem to
  refer to the same thing, but it's not clearly stated.
- It is suggested that multiple FEC schemes can be used when there
  is no explicit Source FEC Payload ID. Is that true and why?


3/ section 3.3, list of FEC Framework Config Info:
Is this list exhaustive? For instance:
- repair flows (bullet 1) are "identified", but not "defined"
  (unlike source flows, bullet 2.).
- Is the identifier used for repair flows similar to the one used
  for source flows?
- Is the FSSI sufficient to carry all FEC related parameters (see
  the question 1/ above on the relationship with RFC5052)?
- the length of the FEC Payload ID is mentioned here, but not its
  content/format. Is it implied by the FEC Scheme (in a way similar
  to RFC5052)? This should be clarified.


4/ section 4.1 Transport protocol identifiers
The differences between "fec/udp" and "udp/fec" are not clear.
Latter on, in section 7 "IANA considerations", only two <proto>/FEC
(in upper case this time) are defined.


5/ section 4.2: example in fig. 1
The example shows a complex source/repair mapping. Is this example
realistic or is it a "view of the mind" meant to illustrate the
flexibility of the underlying FEC framework?


6/ General question:
Parameters carried within a Session Announcement are by nature
applicable to the whole session. Is that sufficient or do we
lack some flexibility to reflect a dynamic change in the session
(e.g. when new source flows are added to the "group", or some source
flows diseapper from the "group")?

_______________________________________________
Fecframe mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/fecframe