Subject: [Fecframe] WG Minutes

From: Greg Shepherd <[email-masked]>
Date: Fri, 26 Nov 2010 10:11:15 -0800

First, a huge thank you to Ali for stepping here to chair in my
absence. Here are the minutes from the meeting. Please let me know if
you have any corrections/clarifications or if you approve of the
minutes as is. I'd like to post these asap.

Thanks,
Greg

----snip---
The interim chair goes over the agenda and draft status. Thomas S. is
the new editor for the Raptor drafts. Questions about Raptor drafts
(should they be informational as opposed to standards track?). Magnus
says there is benefit in publishing them in standards track (as RMT
did).

The AD wants to confirm that the next two drafts (that Vincent is to
present) are in the charter or not. They are not in the charter
specifically but they are within the scope of FEC schemes.

Vincent starts with the first slide deck. Goes over the issues
(related to IPR) that were addressed in the latest version. Says the
draft is pretty mature to be adopted. The chair will ask the list.

The second slide deck. This is the RTP payload format for the RS
codes. It will be finished by the next meeting, and accompanies the RS
draft. AVT will have to review this and the chair will ask the WG to
adopt it or not.

The AD - on the mic - says that if these FEC schemes will not be
implemented by multiple vendors, they could actually go thru the
AD-sponsored path.

The third deck. Motivation for this work is the low-decoding
complexity for high-bitrate apps. It has different use cases compared
to other existing FEC schemes. Discussing a very recent paper that
explains the code and its performance. The AD asks whether there is
any IPR on this. Vincent says "today, there is not on this draft but
there are some IPR disclosures on a related RFC," which is 5170.

Ali starts discussing the IESG comments for the framework draft (Ali
is the new editor).

* Concerning Management and Operations:

AD: IESG want to make sure that you properly thought about these
issues, so try to put some simple text and guidelines. What should an
operator like to know? What should a FECFRAME implementation provide?

* Concerning Congestion Control:

AD: If you don't know the history of the WG, it's hard to figure out
why there is this rule of no more than twice the bandwidth.
Colin: There is a frequent misunderstanding about congestion control and FEC.

* Concerning Security:

Vincent: I'm the one who performed the SecDir review for this
document. I think it's extremely important to have a detailed
"security
considerations" section since this is a framework document that is
referenced by all  other FECFRAME documents. Among the things I think
are required is a "mandatory to implement but not necessarily to use"
security mechanism. It seems that requiring IPsec/ESP be mandatory is
fine.
AD: I agree.

David (AD hat off): if we anticipate that FECFRAME will be used for
something else than real-time flows, for instance for MIKEY or other
applications, then it's better to mention it. MIKEY was just an
example.
Magnus: You can use it as well for DNS. It needs to be better clarified.
David: You can have a discussion on how to apply it to a specific
use-case in the Operations and Management section.

Concerning some fields starting from 0:
Colin: Clarify the assumptions about wrapping. There's also an issue
about possible rekeying before the end of a block. You can have a look
at the RTP security considerations.

Discussion started on how to handle future FEC Schemes if the FECFRAME
is closed. Proposal is to have schemes with RTP framing of repair
packets be managed by the AVT WG, and other schemes by the TSV WG.
---snip---