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

Qin Wu <bill.wu@huawei.com> Mon, 07 September 2020 02:53 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 D33DD3A1445; Sun, 6 Sep 2020 19:53:56 -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 2Ff9qH7uY-WS; Sun, 6 Sep 2020 19:53:55 -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 280783A1444; Sun, 6 Sep 2020 19:53:55 -0700 (PDT)
Received: from lhreml744-chm.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1C833A2A0AFDC47F1A67; Mon, 7 Sep 2020 03:53:52 +0100 (IST)
Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 7 Sep 2020 03:53:51 +0100
Received: from DGGEML405-HUB.china.huawei.com (10.3.17.49) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 7 Sep 2020 03:53:51 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.186]) by dggeml405-hub.china.huawei.com ([10.3.17.49]) with mapi id 14.03.0487.000; Mon, 7 Sep 2020 10:53:46 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
CC: Jerome Martinez <jerome@mediaarea.net>, "ops-dir@ietf.org" <ops-dir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-cellar-ffv1.all@ietf.org" <draft-ietf-cellar-ffv1.all@ietf.org>, "cellar@ietf.org" <cellar@ietf.org>
Thread-Topic: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17
Thread-Index: AdaEwa1X1/v+oztpQ/KoO4IbPmC/Uw==
Date: Mon, 7 Sep 2020 02:53:45 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD99CA8B@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/y5LoWdtKUyZuFi36gsVHHo0u1Vo>
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:53:57 -0000

-----邮件原件-----
发件人: Michael Richardson [mailto:mcr+ietf@sandelman.ca] 
发送时间: 2020年9月7日 10:41
收件人: Qin Wu <bill.wu@huawei.com>
抄送: Jerome Martinez <jerome@mediaarea.net>et>; ops-dir@ietf.org; last-call@ietf.org; draft-ietf-cellar-ffv1.all@ietf.org; cellar@ietf.org
主题: Re: [Cellar] Opsdir last call review of draft-ietf-cellar-ffv1-17


<#secure method=pgpmime mode=sign>

Qin Wu <bill.wu@huawei.com> 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)
[Qin]: Good clarification, thanks Michale.
    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]:Not my suggestion to support RTP, just provide analogy. Your clarification looks good to me now. Thanks.

    > [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.
[Qin]: Good explanation, the word "configuration" confuses me a lot, which make me wonder who generate configuration, who install configuration, where these configuration is executed.
--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide