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

Eric Rescorla <ekr@rtfm.com> Sat, 23 February 2019 12:30 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C789130EE7 for <rtcweb@ietfa.amsl.com>; Sat, 23 Feb 2019 04:30:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJ7VueBH2Iyt for <rtcweb@ietfa.amsl.com>; Sat, 23 Feb 2019 04:30:28 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B29B1130EC9 for <rtcweb@ietf.org>; Sat, 23 Feb 2019 04:30:27 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id g80so3779014ljg.6 for <rtcweb@ietf.org>; Sat, 23 Feb 2019 04:30:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4kHrOpR9YNWAUGMomS8HMqqDEQ29itIBr7Sy1GawsPE=; b=kvDaHJe7Wxdreo3N7gGwe7a67OUGkWvSim1HsgBr5PBno31CML2bBL69phdWDLtV2v quJ0/sM8CV2PV2ulE0Eyjtse5RL+4zb2tgvuw8IuDbMg/L5BFcjGCGkrIExiXH4aoDnf YX+l2H45Gj2znN8f3DmKdBv9fdXuP7C3VaU6qJ+NcpZ3D5uXrfyRxTQSu250T4DaM9lz HI8ZgFJwXpayJC89gofr+8knQU1TU75Ld7iE+LzEISz0cyoFjkTznk7PSDx/tRdG/Yll xfr2iU5tweJHeGIxoc2Lx2TQLrvOGNj1cmQFx2bO6L2sxzpJcgKkiVW4Ti9vfj3BrduL Uphg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4kHrOpR9YNWAUGMomS8HMqqDEQ29itIBr7Sy1GawsPE=; b=Jr2ZawvKmID1FOdpJeBiISpgKuQtZ1n/AT+6fBG+KI5ZuVNYJVgnIF3BDElCO/jqBk BWyWmzh1JEVVLEkK1AGTMsQFV2oX80VLsWIVfTS+YcdUnzoCOAiP3icaxX2yK7R1c3+D AxGdGpm/bVPCmqLZSza1MoM/+2ubux6cqHkT4nVaMDszHU/4djFwwh3pfDC5JiFsPHro Dvx2aaOfRaF/O4ueqwlqGIR7+UJ5mQUQ1tPFlr1zblJOrw52Q/vs5L7lVGacEXE2fjPf xI2KigCf6HkeH9tPq9ZOn+Ty4TEYQ5/eJbYD1t697hmXDXjRbIcy1N/vqo8CToIeacbu P3FA==
X-Gm-Message-State: AHQUAuaN1nE7jhsRqSKN4q7UDokujUTod2prpzY+GKh2N++xbc7Yov+S VZ/p3Qib0Tx1tz2OCZhXK3dPY6/Kmt7kbsbfniclcg==
X-Google-Smtp-Source: AHgI3IYkieSBXEoZdw0SY3Ec+uDcR0RazvoaijjZq/UAWOk3yLF5QZqvdjHaHS3TIMBjapGL6peSNJwj7Z7ZW6paJuU=
X-Received: by 2002:a2e:3c19:: with SMTP id j25mr4949833lja.72.1550925025392; Sat, 23 Feb 2019 04:30:25 -0800 (PST)
MIME-Version: 1.0
References: <155041598050.4092.17319548267050845938.idtracker@ietfa.amsl.com> <CAOJ7v-3+qd8cH_TYFFvo0Axg=77Rz32oxnkqLFVPSysDyD4BmQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-3+qd8cH_TYFFvo0Axg=77Rz32oxnkqLFVPSysDyD4BmQ@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 23 Feb 2019 04:29:46 -0800
Message-ID: <CABcZeBMFpDD0WQvMWGxF_WzhF4H_uZJEaUG-DyCBKKpAabtz8g@mail.gmail.com>
To: Justin Uberti <juberti@google.com>
Cc: The IESG <iesg@ietf.org>, RTCWeb IETF <rtcweb@ietf.org>, rtcweb-chairs@ietf.org, draft-ietf-rtcweb-fec@ietf.org
Content-Type: multipart/alternative; boundary="00000000000036533c05828edfd4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtcweb/a7FYry-NkYrBstCjBOJ87qQrpso>
Subject: Re: [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
Precedence: list
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: Sat, 23 Feb 2019 12:30:30 -0000

On Fri, Feb 22, 2019 at 4:18 PM Justin Uberti <juberti@google.com>; wrote:

> Thanks for your comments, see below:
>
> On Sun, Feb 17, 2019 at 7:06 AM Eric Rescorla <ekr@rtfm.com>; 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