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

[Justin Uberti <[e-mail]>]

Thanks for your comments, see below:

On Sun, Feb 17, 2019 at 7:06 AM Eric Rescorla <[e-mail]> wrote:

> 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?
>

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.

>
>
> 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.```
>

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.