Subject: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sun, 17 Feb 2019 07:06:20 -0800

Eric Rescorla has entered the following ballot position for
draft-ietf-rtcweb-fec-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3278

COMMENTS
S 5.2.
>      as described in [RFC5956], Section 4.1 is not currently defined for
>      WebRTC, and SHOULD NOT be offered.
>   
>      Answerers SHOULD reject any FEC-only m-lines, unless they
>      specifically know how to handle such a thing in a WebRTC context
>      (perhaps defined by a future version of the WebRTC specifications).

It seems like the above three paragraphs are generic to this document,
and just grouped with video because the audio codecs tend to have
internal FEC? If so, maybe put them elasewhere?

S 9.
>   
>      As described in [RFC3711], Section 10, the default processing when
>      using FEC with SRTP is to perform FEC followed by SRTP at the sender,
>      and SRTP followed by FEC at the receiver.  This ordering is used for
>      all the SRTP Protection Profiles used in DTLS-SRTP [RFC5763], as
>      described in [RFC5764], Section 4.1.2.

I of course agree with this text, but I wonder if it's maximally
clear. Perhaps rewrite the
first sentence as:

```The FEC schemes described in this document use other packets to
recover when a packet is lost or damaged but do not allow for recovery
of a damaged packet on its own. This is consistent with the default
processing for using FEC with SRTP described in RFC 3711, which is to
perform FEC followed by SRTP at the sender, and SRTP followed by FEC
at the receiver, which implies that damaged packets will be rejected
by the SRTP integrity check and discarded.```

---

From: Justin Uberti <[email-masked]>
Date: Fri, 22 Feb 2019 16:18:42 -0800

Thanks for your comments, see below:

> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-fec/

As noted elsewhere in the document, the recommendation is to only use
flexfec with video. These paras could be put elsewhere, e.g., in a
"negotiating flexfec" section, and then 5.2 could point to said section,
but it's not clear this would enhance readability.

> by the SRTP integrity check and discarded.```

I rewrote this in the most recent commit,
https://github.com/juberti/draughts/commit/6e991d1eeaf1e505bb89957319be38df4ada56f5.
LMK if you think that still needs to be clarified.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 23 Feb 2019 04:29:46 -0800

> but it's not clear this would enhance readability.

OK. I'm not going to push on this point.

> LMK if you think that still needs to be clarified.

LGTM

-Ekr