[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:


Rich version of this review at:

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