Re: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)

Jerome Martinez <> Wed, 07 October 2020 16:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CA48A3A0AF1 for <>; Wed, 7 Oct 2020 09:09:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.111
X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id F7YjR96Z6S6d for <>; Wed, 7 Oct 2020 09:09:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA70A3A0AE6 for <>; Wed, 7 Oct 2020 09:09:19 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id CDBFE14F9BB for <>; Wed, 7 Oct 2020 18:09:17 +0200 (CEST)
Received: from ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 3B37817046033; Wed, 7 Oct 2020 16:09:10 +0000 (UTC)
Authentication-Results:; auth=pass (GARM-105G00673067e21-019e-422d-9bf8-582af52ed9ff, FD998853DF21057F47A4E278FE6EA1CC7EFEAE1C)
To: Roman Danyliw <>, The IESG <>
Cc:,,, Michael Richardson <>, "Peter B." <>
References: <>
From: Jerome Martinez <>
Message-ID: <>
Date: Wed, 7 Oct 2020 18:09:10 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Ovh-Tracer-Id: 16730028194635649133
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgeeigddutddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepkefhvdfguefhgfeghfffhfdtheffhfduueevjedtgfejgfelleeujeehteffgfejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkpheptddrtddrtddrtddpkeegrddugeefrddugeejrddugedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeelkedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg
Archived-At: <>
Subject: Re: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Oct 2020 16:09:22 -0000

Hi Roman,
Thank you for your comments, answers inline:

On 07/10/2020 17:27, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for
> providing the review).
> I support Barry Lieba’s Discuss position.
> A few additional comments on the framing of the codec description not already
> mentioned by my peers:
> ** Section 1.  Is “non-experimental use” the same as production use?

I would rather say that the bitstream is frozen, flagged as stable.
I suggested a change in the wording in

> ** References.  Why use C89/90 for syntax and C18 for operator precedence?
> Wouldn’t C18 work for both?

the previous reference was written years before C18 doc, I don't see any 
conflict with C18 here so I proposed to change to C18 in

> ** References.
> -- Doesn’t Section required [ISO.14496-12.2015] as a normative
> reference to parse the "glbl" box in the ConfigurationRecord bitstream?

In understand that the normative reference is when its knowledge is 
essential to the understanding, and this is not the case here as it is 
only for people wanting to implement FFV1 in
[ISO.14496-12.2015]. Isn't it correct?

> -- Doesn’t Section required [NUT] as a normative reference to parse the
> ConfigurationRecord bitstream?

In addition to the remark about [ISO.14496-12.2015], NUT is very 
informal, no standardization, so even less essential.

> On the security considerations:
> ** Section 6.  Per the reference to [RFC4732], which selection is relevant
> here? Is it Section 2.1.1?  If so, the risks due to end-point compromise are
> much broader than DoS.
> ** Section 6.  The assertions about the security properties of [REFIMPL] don’t
> make sense to me in this document.  While it is extremely helpful that there is
> a high-quality reference implementation, it’s relevance to this spec isn’t
> clear.  This code isn’t normative.  Recommend removal all text after the
> paragraph “None of the content carried in FFV1 is intended to be executable”.
I have open a discussion with other writers specifically about the 
security considerations at