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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Wed, 07 Oct 2020 08:27:12 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-cellar-ffv1-17: 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-cellar-ffv1/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

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

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

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

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

---

From: Jerome Martinez <[email-masked]>
Date: Wed, 7 Oct 2020 18:09:10 +0200

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

I would rather say that the bitstream is frozen, flagged as stable.
I suggested a change in the wording in 
https://github.com/FFmpeg/FFV1/pull/248

> 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 
https://github.com/FFmpeg/FFV1/pull/248

> 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?

> ConfigurationRecord bitstream?

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

> 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 https://github.com/FFmpeg/FFV1/pull/249

Jérôme