Subject: Re: [Last-Call] Opsdir last call review of draft-ietf-cellar-ffv1-17

From: Qin Wu <[email-masked]>
Date: Mon, 7 Sep 2020 02:28:57 +0000

-----邮件原件-----
发件人: Jerome Martinez [mailto:[email-masked]] 
发送时间: 2020年9月6日 18:55
收件人: Qin Wu <[email-masked]>; [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Re: Opsdir last call review of draft-ietf-cellar-ffv1-17

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.

[Qin]: I get impression you change update RFC process, usually we have existing, published RFC first, and then make bis document and revise the existing RFC, now you progress multiple release in parallel, which is something I haven't seen before.
Anyway, this is WG decision, which I have no strong opinion on this.
>   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.

[Qin]: We also see OPUS with RTP transport has been published as RFC7587. Anyway I leave this issue to you.

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

[Qin]: Good, thanks for your clarification.

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

[Qin]: which protocol is used to configure these parameters? How do you prevent misconfiguration from malicious client?

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

---

From: Michael Richardson <[email-masked]>
Date: Sun, 06 Sep 2020 22:40:30 -0400

<#secure method=pgpmime mode=sign>

Qin Wu <[email-masked]> wrote:
    > [Qin]: I get impression you change update RFC process, usually we have
    > existing, published RFC first, and then make bis document and revise
    > the existing RFC, now you progress multiple release in parallel, which
    > is something I haven't seen before.

There are many processes.
The IETF has often published an Informational draft on an existing
"defacto" specification that is unchangeable because it is already deployed.
I believe this happened for POP3, IMAP, HTTP 0.9, and a number of other well
known protocols.

Then we do "v2.0" which is standards track, and which is subject to IETF
change control.  Except that this time, it is 4.0 not 2.0.
[In fact, there is no v2 for ffv because it never got deployed]

(Such a process was not done, btw. for TACACS for reasons that were never
adequately explained to me)

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

    > [Qin]: We also see OPUS with RTP transport has been published as
    > RFC7587. Anyway I leave this issue to you.

Yes, but RFC7587 does not define the OPUS CODEC.
The OPUS Codec is defined in RFC6716.

RFC7587 defines how to carry RFC6716 transmissions in RFC3550 format.
We have a document, draft-ietf-cellar-matroska, which is a bit equivalent to RFC7587.
But, not involving RTP.  If there were interest in using ffv4 in the future
over RTP, then we'd have to explain how to do that.
CELLAR is focused on archival needs, not real time needs.

    > [Qin]: which protocol is used to configure these parameters? How do you
    > prevent misconfiguration from malicious client?

First, it's a data format, not a protocol.
So there is no configuration or negotiation involved.

The chosen parameters are either valid, and the decoder can deal with them,
or it can't.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide