[rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)
Eric Rescorla <ekr@rtfm.com> Sun, 17 February 2019 15:06 UTC
Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietf.org
Delivered-To: rtcweb@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9ED12D4EA; Sun, 17 Feb 2019 07:06:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Eric Rescorla <ekr@rtfm.com>
To: The IESG <iesg@ietf.org>
Cc: Ted Hardie <ted.ietf@gmail.com>, ted.ietf@gmail.com, rtcweb@ietf.org, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.91.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155041598050.4092.17319548267050845938.idtracker@ietfa.amsl.com>
Date: Sun, 17 Feb 2019 07:06:20 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/awYTxGFFFNN-6ohL343qZIw0sec>
Subject: [rtcweb] Eric Rescorla's No Objection on draft-ietf-rtcweb-fec-08: (with COMMENT)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Feb 2019 15:06:21 -0000
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.```
- [rtcweb] Eric Rescorla's No Objection on draft-ie… Eric Rescorla
- Re: [rtcweb] Eric Rescorla's No Objection on draf… Justin Uberti
- Re: [rtcweb] Eric Rescorla's No Objection on draf… Eric Rescorla