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

[Eric Rescorla <[e-mail]>]

On Fri, Feb 22, 2019 at 4:18 PM Justin Uberti <[e-mail]> wrote:

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

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



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

LGTM

-Ekr