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 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
