Re: [secdir] Secdir early review of draft-ietf-cellar-ffv1-02

Dave Rice <dave@dericed.com> Fri, 01 June 2018 14:38 UTC

Return-Path: <dave@dericed.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B82B12D883; Fri, 1 Jun 2018 07:38:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
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 y81H5uBOlKEp; Fri, 1 Jun 2018 07:37:57 -0700 (PDT)
Received: from server172-3.web-hosting.com (server172-3.web-hosting.com [68.65.122.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E665912D885; Fri, 1 Jun 2018 07:37:53 -0700 (PDT)
Received: from [146.96.19.240] (port=20616 helo=[10.10.201.39]) by server172.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <dave@dericed.com>) id 1fOlBe-000MvB-HD; Fri, 01 Jun 2018 10:37:52 -0400
From: Dave Rice <dave@dericed.com>
Message-Id: <FA4ABD88-3916-4564-A504-8DD30D768431@dericed.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_71F82103-5CE2-45B9-B7B5-22D0629ED470"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Fri, 1 Jun 2018 10:37:49 -0400
In-Reply-To: <152784500007.15152.9045057653501275171@ietfa.amsl.com>
Cc: secdir@ietf.org, draft-ietf-cellar-ffv1.all@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission <cellar@ietf.org>, ietf@ietf.org
To: Liang Xia <frank.xialiang@huawei.com>
References: <152784500007.15152.9045057653501275171@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3273)
X-OutGoing-Spam-Status: No, score=-2.4
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server172.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - dericed.com
X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com
X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/0WCIm8Ljpoq2NSRItDZSieiwchs>
Subject: Re: [secdir] Secdir early review of draft-ietf-cellar-ffv1-02
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2018 14:38:03 -0000

Hi,
Thanks for this review.

> On Jun 1, 2018, at 5:23 AM, Liang Xia <frank.xialiang@huawei.com> wrote:
> 
> Reviewer: Liang Xia
> Review result: Ready
> 
> The whole draft is in good shape and well written.
> Some nits:
> 1. every word should start with capital letter for the section title;
> 2. section 2.2.4: / ceil(a) the largest integer less than or equal to a /
> ceil(a) the smallest integer larger than or equal to a / 3. section 3.7.2:
> [ISO.15444-1.2016]? 4. section 12.1: [I-D.ietf-cellar-ffv1]? 5. section 12.2:
> should all the RFC move to the Normative References (section 12.1)?

I added a pull request at https://github.com/FFmpeg/FFV1/pull/116 <https://github.com/FFmpeg/FFV1/pull/116> that addresses many of these issues.

Regarding 
> section 12.1: [I-D.ietf-cellar-ffv1]?
I found that Media Type Definitions within RFC’s tend to be self-referencing. Since there is no RFC number here on this draft, I’ve used [I-D.ietf-cellar-ffv1] as a temporary self reference.

> Issues for clarification:
> In Security Considerations, besides the DoS attacks brought by the malicious
> payloads, is there any other kinds of attack possibly? For example, virus or
> worm are hidden in the malicious payloads to attack the system for more
> damages? Does it make sense and what's the consideration?

I haven’t done any update for this. Nudge to Michael Niedermayer and Jérôme Martinez.
Best Regards,
Dave Rice