FECFrame Minutes, IETF 68, Prague

Mark presenting FECframe document update:
  - requirement status is frozen, no comments since ietf67
  - open issues:

    - Fec scheme requirements

      - Most requirements can be likely imported from RMT

      - Lorenzo: feedback from RMT: good to have this scheme definition
        to have good quality of resulting FEC drafts later on

    - Q: are there any transport specific considerations
      - considered: UDP and DCCP
      - Rajiv Asati: L4 ? Yes.
      - Q: has RTP been cnsidered ? Currently arbitrary flow across
        UDP - includes of course RTP (on top of RTP). A: nothing specific
	to RTP currently. RTP is on top of UDP. Other groups (DVB) have
	tried to do this. Pro and Cons of trying to be specific to RTP.
      - James Wendel/Microsoft: RTP is also a framework in itself. 
        there are fields in RTP obvious you wold want to exploit. RTP
	is for time critical flows. Some impact on semantics too.
      - Greg/Mark: Specific FEC scheme could rely on existing RTP fields
        and not need to add them to it's own header. ALso backward compatible
      - Lorenzo: Hybrid scheme possible ? (Header format that is flexible
        to be optimized with RTP as payload vs. non RTP payload).
	Mark: Mostly documentation issue.
      - CMagnus: (didn't understand what he said)
      - Lorenzo: Add permanent piece of header and optional header 
        only present when payload is not RTP.
      - Magnus: probably not useful from complexity perspective.

    - sdp elements...
      description of properties of toolkit of SDP elements to be used
      in content delivery protocols. Not normative, but indicidual FEC
      schemes may choose to use them.
        - transport protocol identifiers for FEC repair flows
        - Association of source flows to repair flow
        - FEC-scheme specific configuration
      - Greg: Rosetta stone draft needed describing where information is
        being pulled in from (RMT specs, etc..)
      - Rajiv: Why SDP ? Mark: Not manadated, optional.
      - SPD requires coordination with mmusic, avt and rmt.

 Next Steps:
   - Streaming Content Delivery Protocol. Need to defne a specific protocol,
     maybe based on SDP toolkit, provide explicit example cases. Have
     an example of a concrete example of how to use the framework.
     - Greg/Mark: separate document from Framework.
     - (Unnamed) Proposal: Just use XOR as a simple example

 - Lorenzo: What plans to take from what RMT did ?
  - Mark: Could be lot of reuse of RMT work. Maybe just a few pages spec
    in FEC frame and refer to an algorithm defined in RMT.
  - Mark: Do we want to systematically pull in RMT ? Probably not,
    leave it up to proponents of individual schemes.
 - Lorenzo: IANA registration defined ?
  - Mark: not yet. Probably in future. Three choices:
    - Dfine when signaling of FEC is defined
    - Do same thing as RMT did (signaling independent code space)
    - Directly clone/reuse RMT defined code space.
  - Rajiv: Preferred solution to reuse work from RMT
  - Magnus: Only 256 code points in RMT definition. Maybe too little.
    Especially with dynamic mapping.