Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17

[Jerome Martinez <[e-mail]>]

Hi Qin,

Thank you for your review, answers inline:

On 06/09/2020 10:28, Qin Wu via Datatracker wrote:
> Reviewer: Qin Wu
> Review result: Ready
>
> I have reviewed this document on behalf of the Operations and Management
> Directorate. Four questions  need to be clarified： 1. why document v0,v1,v3 in
> draft-ietf-cellar-ffv1 as informational and document v4 in
> draft-ietf-cellar-ffv1-v4-14 as standard track? Not clear the key difference
> between v04 and all other previous versions?

v0,v1,v3 bitstreams are already in the wild, the FFV1 v0,v1,v3 
specification documents what is already in use and we adapt the 
specification (including documenting issues found during the review of 
the encoders and decoders) to the bitstream in the wild instead of a 
clean change of the bistream when an issue is found, this is not really 
a standard with a consensus during the writing of the specification, the 
choice was to have informational status due to this.

FFV1 v4 is not in the wild (the only encoder able to create such 
bitstream need to receive a "experimental" flag in order to create such 
bitstream), it is a future specification, clean, and we'll adapt the 
encoders/decoders to the decided specification, so standard status. Note 
that v4 i based on v0,v1,v3 so evolves at the same time but is not ready 
and not part of this last call review.


>   2. Why not specify transport, is
> container sto which the ffv1 is mapped equivalent to transport? without
> transport, how to provide confidentiality, integrity, and source authenticity?

FFV1 is a video coding format, like Opus is an audio coding format, Opus 
does not specify transport too. FFV1 is intended to be encapsulated in a 
container and we don't feel the need to have a dedicated transport for 
FFV1, we use (de facto or not) standard like MP4 (ISO standard) or 
Matroska (de facto standard and IETF standard candidate) for the 
transport. Note that Opus is an IETF standard (RFC 6716) without transport.

Confidentiality, integrity, and source authenticity is delegated to the 
transport layer, as it is the case with Opus or many other coding formats.


> 3. how error_status and crc parity are used? e.g., using crc parity detect
> error? can error be repaired? how?

error_status was intended for storing information about errors found in 
the bitstream, AFAIK it is not used in any encoder or decoder for 
filling (it is always 0) or reading (value discarded) this value but the 
informal specification has always planned this byte for error status so 
we currently keep it as instead of flagging it e.g as "reserved". We can 
not remove it from the bitstream as we document what is already in use 
in v0,v1,v3.

crc parity is used for detecting a transport or storage error, in order 
to detect that losslessness is compromised by an unintentional change.
the reference decoder (FFmpeg) first computes the CRC and rejects the 
slice if a CRC is not the expected one before trying to decode, and a 
conformance checker like MediaConch indicates that the file has a 
problem if a CRC is not the expected one.

The purpose is not especially to repair (this is not an error correction 
code), only to detect integrity issues, but there is a proof of concept 
of repairing a bit flip based on CRC at 
https://mediaarea.net/MediaConch/Documentation/Fixity


>   4. Is bitstream parameters such as version,
> micor-version,num_h_slices,num_v_slices sensitity information that can
> disclosed? any security risk?

All these parameters are needed for setting up the decoder, and they are 
not sensitive, it i just a configuration of the bitstream (for example 
an higher minor_version could indicate that there is an extra field 
after the configuration but would not indicate the encoder name).
We documented the security risks we know in the security section 
(updated through 
https://mailarchive.ietf.org/arch/msg/cellar/XVidil8tTd7eNoGmTCQPOI_C-sA/ 
after a remark from Secdir), and the decoder is expected to reject 
incoherent values e.g. num_h_slices bigger than pixel width.

Jérôme