RTP Payload Format for Flexible Forward Error Correction (FEC)
draft-ietf-payload-flexible-fec-scheme-20

Note: This ballot was opened for revision 16 and is now closed.

Alvaro Retana No Objection

Benjamin Kaduk (was Discuss) No Objection

Comment (2019-03-08 for -18)
No email
send info
Thank you for addressing my DISCUSS points (and de-confusing me on how the
recovery state is consolidated across the different SSRCs and packets it covers)!

Martin Vigoureux No Objection

Warren Kumari No Objection

Comment (2019-02-20 for -17)
No email
send info
Like others, I found the 2-D description confusing -- but I'm *so* not a SME here, and figured it's probably just me :-)

(Ben Campbell; former steering group member) Yes

Yes ( for -16)
No email
send info

(Adam Roach; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Alexey Melnikov; former steering group member) No Objection

No Objection (2019-02-19 for -17)
No email
send info
I found 2-D description confusing as well.

(Deborah Brungard; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Ignas Bagdonas; former steering group member) No Objection

No Objection ( for -17)
No email
send info

(Mirja K├╝hlewind; former steering group member) No Objection

No Objection (2019-02-21 for -17)
Thanks for the well-written document! And thanks for addressing the TSV-ART comments (and thanks Bernard for the review)!

(Spencer Dawkins; former steering group member) No Objection

No Objection (2019-02-19 for -17)
I do have one question - the IESG has approved https://datatracker.ietf.org/doc/draft-ietf-tsvwg-fecframe-ext/, which updates RFC 6363 to support sliding encoding window codes, in addition to block codes, and it seems like that would be useful for real-time payload FEC here. Is that something that people have looked at?

(Suresh Krishnan; former steering group member) No Objection

No Objection ( for -17)
No email
send info