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

Qin Wu <bill.wu@huawei.com> Mon, 07 September 2020 02:29 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: cellar@ietfa.amsl.com
Delivered-To: cellar@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76813A1404; Sun, 6 Sep 2020 19:29:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQLdexvylYJn; Sun, 6 Sep 2020 19:29:06 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE07B3A1400; Sun, 6 Sep 2020 19:29:05 -0700 (PDT)
Received: from lhreml702-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 648F9D666DA1C035E49C; Mon, 7 Sep 2020 03:29:04 +0100 (IST)
Received: from lhreml702-chm.china.huawei.com (10.201.108.51) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Mon, 7 Sep 2020 03:29:04 +0100
Received: from DGGEML423-HUB.china.huawei.com (10.1.199.40) by lhreml702-chm.china.huawei.com (10.201.108.51) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Mon, 7 Sep 2020 03:29:03 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.186]) by dggeml423-hub.china.huawei.com ([10.1.199.40]) with mapi id 14.03.0487.000; Mon, 7 Sep 2020 10:28:57 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Jerome Martinez <jerome@mediaarea.net>, "ops-dir@ietf.org" <ops-dir@ietf.org>
CC: "last-call@ietf.org" <last-call@ietf.org>, "cellar@ietf.org" <cellar@ietf.org>, "draft-ietf-cellar-ffv1.all@ietf.org" <draft-ietf-cellar-ffv1.all@ietf.org>
Thread-Topic: Opsdir last call review of draft-ietf-cellar-ffv1-17
Thread-Index: AdaEvHLbKy+w4BDOQSGasCL9iR9XPA==
Date: Mon, 7 Sep 2020 02:28:57 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD99BA25@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.101.103]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/3pPQeVvpxPgj7FYSQggsV-vNZEU>
Subject: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17
X-BeenThere: cellar@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <cellar.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cellar>, <mailto:cellar-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cellar/>
List-Post: <mailto:cellar@ietf.org>
List-Help: <mailto:cellar-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cellar>, <mailto:cellar-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Sep 2020 02:29:08 -0000

-----邮件原件-----
发件人: Jerome Martinez [mailto:jerome@mediaarea.net] 
发送时间: 2020年9月6日 18:55
收件人: Qin Wu <bill.wu@huawei.com>om>; ops-dir@ietf.org
抄送: last-call@ietf.org; cellar@ietf.org; draft-ietf-cellar-ffv1.all@ietf.org
主题: 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