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

Michael Richardson <mcr+ietf@sandelman.ca> Mon, 07 September 2020 02:40 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 954BD3A13BB; Sun, 6 Sep 2020 19:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=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 LQiBER7LosOM; Sun, 6 Sep 2020 19:40:34 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AF33A13AB; Sun, 6 Sep 2020 19:40:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CC740389C1; Sun, 6 Sep 2020 22:19:24 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id m5qsfq5wZnV0; Sun, 6 Sep 2020 22:19:22 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5644C389BD; Sun, 6 Sep 2020 22:19:22 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A4DCA4D7; Sun, 6 Sep 2020 22:40:30 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Qin Wu <bill.wu@huawei.com>
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>
In-Reply-To: <B8F9A780D330094D99AF023C5877DABAAD99BA25@dggeml511-mbs.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABAAD99BA25@dggeml511-mbs.china.huawei.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Sun, 06 Sep 2020 22:40:30 -0400
Message-ID: <14274.1599446430@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cellar/h7uA_0zeDLrstyL3Y4EpaPz7WyY>
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:40:38 -0000

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

    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 <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide