From nobody Sun Oct 4 00:41:13 2020 Return-Path: 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 30B833A128C for ; Sun, 4 Oct 2020 00:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Y+HxjIZq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=pWihcKvv 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 1ASn_FcX6wqn for ; Sun, 4 Oct 2020 00:41:04 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A93033A128B for ; Sun, 4 Oct 2020 00:41:04 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 7F88D5C0098 for ; Sun, 4 Oct 2020 03:33:04 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 04 Oct 2020 03:33:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=xvZp+ojJP0exQCgJ+tukqRKn76Od6NJyhxdwDJEAJX0=; b=Y+HxjIZq pzDVu17AmsswZRsebTR/rlAaomRotm9JYAFRWTo9j8tuTVhW8jevCMtHiy3zWBOe 9TdloVDdHUZztKosoAaOR6DD5K/LAdHcGCMHwzFValPFB6o2473/DllnG7p7N1Tn 9k473KYfCgLILgnUscEqWQfKdwBOUNt1Q+iBrvW0OZ9hcKjnr9Fv/peS6Tbaql3J R8Ii0E0zm4c2o6Od+jqtBh+xwopdCnCP+5fV+zJUE4U5qWfU6xCz8LgH7OOt3Jfg pRBeSBFu7IMoeHykDBaQyHl5YwyzwKD18TMbEicXXuC5pTgcT7DJu/rxVQHSJjxO CUombDAC0df/iQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=xvZp+ojJP0exQCgJ+tukqRKn76Od6 NJyhxdwDJEAJX0=; b=pWihcKvvU453AE8+YFSNwJsLueM00G7iAn2mAW3QmSczV 9FRxjRhfb4Fv+KM3SbjuCCrJoOrgOwtMW27aC9dnLL6kDpSsKLVDV6X3Fhwc7tVL uqqCqKCdsMS9wGvDsBL9/G69kmfs0HN8zewv0xvuHGAywmRYcOqJ6y/uT4pwMKxc Tg8v3UXQ3tLIHYnzAvIsmfM32NAI/i3QXOjAw4WDbuqTN7tVR/iB6y0ayMxQRnGV 5L7LtCumw/Tby6OR68Ru/frM/7+h31RvUJZcTS1zpAuO+30Jafz1VGeg5CoStFVn 68EmnNALIt0ZTOkIQHM5yqtPvX51NodkMSSNosnZg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrfeelgdduudekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepvddtrdeggedrleekrddufe elnecuvehluhhsthgvrhfuihiivgepvdenucfrrghrrghmpehmrghilhhfrhhomhepugho pghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az12.internal.cloudapp.net (unknown [20.44.98.139]) by mail.messagingengine.com (Postfix) with ESMTPA id 25BCE3064610 for ; Sun, 4 Oct 2020 03:33:04 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3628461118087044735==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201004073304.25BCE3064610@mailuser.nyi.internal> Date: Sun, 4 Oct 2020 03:33:04 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Oct 2020 07:41:08 -0000 --===============3628461118087044735== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC3) 2 issues received 3 new comments: - #422 Consider providing a facility for integer-fraction timescales (1 b= y robUx4) https://github.com/cellar-wg/matroska-specification/issues/422=20 - #419 Specify requirements around ReferenceBlock elements and how BlockG= roups signal random access points (2 by mjbshaw, robUx4) https://github.com/cellar-wg/matroska-specification/issues/419 [clarifi= cations] [spec_main]=20 * FFmpeg/FFV1 (+2/-1/=F0=9F=92=AC9) 2 issues created: - Nothing in the Makefile removes the genarated *.svg files (by michaelni) https://github.com/FFmpeg/FFV1/issues/240=20 - Build produces pages of warnings and errors (by michaelni) https://github.com/FFmpeg/FFV1/issues/234=20 2 issues received 9 new comments: - #234 Build produces pages of warnings and errors (8 by dericed, michael= ni) https://github.com/FFmpeg/FFV1/issues/234=20 - #221 [v4] Consider other RCTs (1 by michaelni) https://github.com/FFmpeg/FFV1/issues/221=20 1 issues closed: - Build produces pages of warnings and errors https://github.com/FFmpeg/F= FV1/issues/234=20 Pull requests ------------- * FFmpeg/FFV1 (+6/-2/=F0=9F=92=AC10) 6 pull requests submitted: - Ballot Barry part 2 (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/241=20 - Remove quotes from defined words (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/239=20 - Ballot Barry part 1 (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/238=20 - Makefile: add xml2rfc.version-ok xmlstarlet.version-ok pdfcrop.version-= ok tests (by michaelni) https://github.com/FFmpeg/FFV1/pull/237=20 - Test mmark version in Makefile experiment (by michaelni) https://github.com/FFmpeg/FFV1/pull/236=20 - mention pandoc as dependency (by dericed) https://github.com/FFmpeg/FFV1/pull/235=20 5 pull requests received 10 new comments: - #239 Remove quotes from defined words (2 by JeromeMartinez, michaelni) https://github.com/FFmpeg/FFV1/pull/239=20 - #237 Makefile: add xml2rfc.version-ok xmlstarlet.version-ok pdfcrop.ver= sion-ok tests (1 by dericed) https://github.com/FFmpeg/FFV1/pull/237=20 - #236 Test mmark version in Makefile experiment (3 by dericed, michaelni) https://github.com/FFmpeg/FFV1/pull/236=20 - #235 mention pandoc as dependency (2 by dericed, michaelni) https://github.com/FFmpeg/FFV1/pull/235=20 - #232 simplify artwork process (2 by dericed, michaelni) https://github.com/FFmpeg/FFV1/pull/232=20 2 pull requests merged: - Ballot Barry part 1 https://github.com/FFmpeg/FFV1/pull/238=20 - Makefile: add xml2rfc.version-ok xmlstarlet.version-ok pdfcrop.version-= ok tests https://github.com/FFmpeg/FFV1/pull/237=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/ebml-specification * https://github.com/cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/cellar-wg/Cellar-FLAC * https://github.com/cellar-wg/chair-notes --===============3628461118087044735== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday October 04, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC3)

2 issues received 3 new comments:

FFmpeg/FFV1 (+2/-1/=F0=9F=92=AC9)

2 issues created:

2 issues received 9 new comments:

1 issues closed:

Pull requests

FFmpeg/FFV1 (+6/-2/=F0=9F=92=AC10)

6 pull requests submitted:

5 pull requests received 10 new comments:

2 pull requests merged:

Repositories tracked by this digest:

--===============3628461118087044735==-- From nobody Sun Oct 4 20:06:33 2020 Return-Path: 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 A60803A0B58 for ; Sun, 4 Oct 2020 20:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Ct2SaaGpspSd for ; Sun, 4 Oct 2020 20:06:23 -0700 (PDT) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FF03A0B56 for ; Sun, 4 Oct 2020 20:06:23 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id e2so3458208vsr.7 for ; Sun, 04 Oct 2020 20:06:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aHyDl0hUjXGc5mFYbjzwK6kwGbSPJtND4kspvadAaqM=; b=Cdt3wsOWrMp2ygj/Omeyk+r2woQhXUgzwj4MdQoRwyEjX6MpBpY7EQPkSakc91BZS2 sSMgffLcK3BOTumvlNFoFlpfclBIgOejhmolNjw75FeDnld9GTXvpfA6j9bLrbNtaDv3 oeI6ZU+8xZLHMSIcyLZNw5XBDSwqSjZm57mVv/sDZvgK820s0PEg5XCcjEu0M3zk0YfV Ovp31WAZaSitewGWJYxlpctfIVzOCLiNrYg2nkCuHoB2fDITWY78VcJ6QuEvNgIS4+PT gwMPYfoIBDk11mDXJfsGViCCvMR6A6JicY4WFEs1Lvesp/PTSn2UtIyfogTmIn4xPmUZ pvIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aHyDl0hUjXGc5mFYbjzwK6kwGbSPJtND4kspvadAaqM=; b=CD8FmOj8xg+8a+vkz1W9UEzfhc+pgZjBaA64ZmDj0EO6yABjepKtaOlJLIkV87/V6G jJSaqQSDHJ6kB05mN9HfyJi5mgjZZvXnquTfdYVtkeLO7TWDlvsIPY6PH7LkoYwdsdXm r28A9bOMQw0MCou6sFbcGMOROXeXgY2fAc7G/mbFEw3JGZcxfPnx6YxfhhJbdyIRD+Ce QaWf/1jEddmq2frBfQ8944HzScT77NnrKsbUHgTVvqw5ArasHnoAyB8h3Ppic+HjNI0U 1mCqmsLi5y+blN4hjgRyVIqeMYI2jTON9FplZFlpy0QM0OIf9nC6skgHMo4B8zScAqOA 0NMg== X-Gm-Message-State: AOAM530qngE+a6KQu5yK1uszjmL3sSdvkjRYendik0CHdnXspczOTOjN V5UHLvVl+jg1g3xQv0L4Y7iej82LUSuxpSlKiFtJVdiWYAc= X-Google-Smtp-Source: ABdhPJyrUL+pM6jj0a9mI2f3mfnIlFz5G/6Sl2Le/1r3R/lDhHRTmstev15lZVHx3mQrheicdkpdZxWdf2U/jUf9dm0= X-Received: by 2002:a67:e248:: with SMTP id w8mr1718692vse.33.1601867182306; Sun, 04 Oct 2020 20:06:22 -0700 (PDT) MIME-Version: 1.0 References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <564afa37-447d-4edf-d815-0f12d9ded2da@mediaarea.net> In-Reply-To: <564afa37-447d-4edf-d815-0f12d9ded2da@mediaarea.net> From: "Murray S. Kucherawy" Date: Sun, 4 Oct 2020 20:06:09 -0700 Message-ID: To: Jerome Martinez Cc: Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="00000000000060f94805b0e3c4ba" Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 03:06:32 -0000 --00000000000060f94805b0e3c4ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks; please let me know if you need more time than that. On Thu, Sep 24, 2020 at 2:10 AM Jerome Martinez wrote: > On 24/09/2020 11:07, Murray S. Kucherawy wrote: > > > There were enough issues raised in Barry's DISCUSS that I decided to push > this document off of this week's telechat agenda to the next one (in two > weeks) rather than having the whole IESG look at it. Could we get a new > version out by, say, October 4th, that clarifies as much of this as > possible? > > > We are working on the issues, October 4th seems a good dead line for a ne= w > version. > > J=C3=A9r=C3=B4me > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > --00000000000060f94805b0e3c4ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks; please let me know if you need more time than that= .

On Thu, Sep 24, 2020 at 2:10 AM Jerome Martinez <jerome@mediaarea.net> wrote:
=20 =20 =20
On 24/09/2020 11:07, Murray S. Kucherawy wrote:
=20

There were enough issues raised in Barry's DISCUSS that I decided to push this document off of this week's telechat agenda to the next one (in two weeks) rather than having the whole IESG look at it.=C2=A0 Could we get = a new version out by, say, October 4th, that clarifies as much of this as possible?

We are working on the issues, October 4th seems a good dead line for a new version.

J=C3=A9r=C3=B4me

_______________________________________________
Cellar mailing list
Cellar@ietf.org https://www.ietf.org/mailman/listinfo/cellar
--00000000000060f94805b0e3c4ba-- From nobody Mon Oct 5 00:04:47 2020 Return-Path: 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 B71463A08FA for ; Mon, 5 Oct 2020 00:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.112 X-Spam-Level: X-Spam-Status: No, score=-2.112 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H2=-0.001, 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 drK3Dbbxxe6S for ; Mon, 5 Oct 2020 00:04:43 -0700 (PDT) Received: from 2.mo177.mail-out.ovh.net (2.mo177.mail-out.ovh.net [178.33.109.80]) (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 4A9663A0820 for ; Mon, 5 Oct 2020 00:04:42 -0700 (PDT) Received: from player693.ha.ovh.net (unknown [10.109.146.213]) by mo177.mail-out.ovh.net (Postfix) with ESMTP id 11EF914165E for ; Mon, 5 Oct 2020 09:04:39 +0200 (CEST) Received: from mediaarea.net (p548f938d.dip0.t-ipconnect.de [84.143.147.141]) (Authenticated sender: jerome@mediaarea.net) by player693.ha.ovh.net (Postfix) with ESMTPSA id 5CA5F16C706FB for ; Mon, 5 Oct 2020 07:04:38 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G00175c189ab-fc06-465f-bb67-a401345601e1, 8178DF97D6CAB652DFE84199EC146FBAF544A128) smtp.auth=jerome@mediaarea.net To: cellar@ietf.org References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> <564afa37-447d-4edf-d815-0f12d9ded2da@mediaarea.net> From: Jerome Martinez Message-ID: Date: Mon, 5 Oct 2020 09:04:38 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DC721720AE33C9CEC376BB7B" Content-Language: en-US X-Ovh-Tracer-Id: 14233345150166569105 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgedugdduudekucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucenucfjughrpefuvfhfhffkffgfgggjtgesrgdtreertdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhephfehveelvdevhffhffehueduueevjeehhedtteehieegfedttddvfeehgfeiuddunecuffhomhgrihhnpehgihhthhhusgdrtghomhdpihgvthhfrdhorhhgnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegjedrudegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrheileefrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 07:04:46 -0000 This is a multi-part message in MIME format. --------------DC721720AE33C9CEC376BB7B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit We have some delays. Most of the changes to answer Barry's comments are merged: https://github.com/FFmpeg/FFV1/pull/238 https://github.com/FFmpeg/FFV1/pull/239 But there is still some discussion on: https://github.com/FFmpeg/FFV1/pull/241 https://github.com/FFmpeg/FFV1/pull/242 So right, we need a bit more time :(. Jérôme On 05/10/2020 05:06, Murray S. Kucherawy wrote: > Thanks; please let me know if you need more time than that. > > On Thu, Sep 24, 2020 at 2:10 AM Jerome Martinez > wrote: > > On 24/09/2020 11:07, Murray S. Kucherawy wrote: >> >> There were enough issues raised in Barry's DISCUSS that I decided >> to push this document off of this week's telechat agenda to the >> next one (in two weeks) rather than having the whole IESG look at >> it.  Could we get a new version out by, say, October 4th, that >> clarifies as much of this as possible? > > We are working on the issues, October 4th seems a good dead line > for a new version. > > Jérôme > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar > > > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --------------DC721720AE33C9CEC376BB7B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
We have some delays.

Most of the changes to answer Barry's comments are merged:
https://github.com/FFmpeg/FFV1/pull/238
https://github.com/FFmpeg/FFV1/pull/239

But there is still some discussion on:
https://github.com/FFmpeg/FFV1/pull/241
https://github.com/FFmpeg/FFV1/pull/242

So right, we need a bit more time :(.

Jérôme

On 05/10/2020 05:06, Murray S. Kucherawy wrote:
Thanks; please let me know if you need more time than that.

On Thu, Sep 24, 2020 at 2:10 AM Jerome Martinez <jerome@mediaarea.net> wrote:
On 24/09/2020 11:07, Murray S. Kucherawy wrote:

There were enough issues raised in Barry's DISCUSS that I decided to push this document off of this week's telechat agenda to the next one (in two weeks) rather than having the whole IESG look at it.  Could we get a new version out by, say, October 4th, that clarifies as much of this as possible?

We are working on the issues, October 4th seems a good dead line for a new version.

Jérôme

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar


--------------DC721720AE33C9CEC376BB7B-- From nobody Mon Oct 5 00:27:13 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4307B3A0B3A; Mon, 5 Oct 2020 00:27:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= Message-ID: <160188283124.21655.15143738833011161583@ietfa.amsl.com> Date: Mon, 05 Oct 2020 00:27:11 -0700 Archived-At: Subject: [Cellar] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-cellar-ffv1-17=3A_=28with_COMMENT=29?= X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 07:27:11 -0000 Éric Vyncke has entered the following ballot position for draft-ietf-cellar-ffv1-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. I found it fascinating while it describes the codec algorithms. Please find below a couple of non-blocking COMMENT points. I also support Alissa's point about using figure numbers/legends. I hope that this helps to improve the document, Regards, -éric == COMMENTS == -- Abstract -- May I suggest to expand/explain FFV1 on first use ? Still wondering what FFV1 means BTW... Also, the lossless encoding is probably the key property of this codec and should probably be mentioned in the abstract. -- Section 2 -- In an informational document, the use of BCP 14 is not required. Suggest to remove this part. -- Section 7 -- Should it be included in section 8 rather than referenced to? From nobody Mon Oct 5 01:05:17 2020 Return-Path: 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 B28873A0E1E for ; Mon, 5 Oct 2020 01:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 EKa9acCuSCfu for ; Mon, 5 Oct 2020 01:05:15 -0700 (PDT) Received: from 10.mo179.mail-out.ovh.net (10.mo179.mail-out.ovh.net [46.105.79.46]) (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 CF1503A0E15 for ; Mon, 5 Oct 2020 01:05:14 -0700 (PDT) Received: from player688.ha.ovh.net (unknown [10.108.57.245]) by mo179.mail-out.ovh.net (Postfix) with ESMTP id DC7B917762E for ; Mon, 5 Oct 2020 10:05:11 +0200 (CEST) Received: from mediaarea.net (p548f938d.dip0.t-ipconnect.de [84.143.147.141]) (Authenticated sender: jerome@mediaarea.net) by player688.ha.ovh.net (Postfix) with ESMTPSA id 6259716BB1CC0; Mon, 5 Oct 2020 08:05:04 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-99G0033bc0c976-45a4-4ae0-a30c-45ea28b86e0d, 8178DF97D6CAB652DFE84199EC146FBAF544A128) smtp.auth=jerome@mediaarea.net To: =?UTF-8?Q?=c3=89ric_Vyncke?= , The IESG Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." References: <160188283124.21655.15143738833011161583@ietfa.amsl.com> From: Jerome Martinez Message-ID: <321b1372-14a0-039d-d022-0670db78c55a@mediaarea.net> Date: Mon, 5 Oct 2020 10:05:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <160188283124.21655.15143738833011161583@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 15255662263859155053 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgedvgddtudcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpedvueegheeiiefhvefgvdfftdffkeekffetiedujedvkeelvdevieffheefgeejvdenucffohhmrghinhepihgvthhfrdhorhhgpdhgihhthhhusgdrtghomhdpfhhfmhhpvghgrdhorhhgpdifihhkihhpvgguihgrrdhorhhgnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegjedrudegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrheikeekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-cellar-ffv1-17=3A_=28with_COMMENT=29?= X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 08:05:17 -0000 Hi Éric, thank you for you review. Answers inline: On 05/10/2020 09:27, Éric Vyncke via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. I found it fascinating while it > describes the codec algorithms. > > Please find below a couple of non-blocking COMMENT points. > > I also support Alissa's point about using figure numbers/legends. > > I hope that this helps to improve the document, > > Regards, > > -éric We added a couple of explanations and references, I hope it is easier to read now. > == COMMENTS == > > -- Abstract -- > May I suggest to expand/explain FFV1 on first use ? Still wondering what FFV1 > means BTW... Also, the lossless encoding is probably the key property of this > codec and should probably be mentioned in the abstract. I don't get the comment, as in my opinion it is fulfilled with the first sentence of the abstract "This document defines FFV1, a lossless intra-frame video encoding format." for both what is FFV1 and its lossless property. And it is similar to https://tools.ietf.org/html/rfc6716 . Could you be more explicit about what is missing from your point of view? I added a definition of "FFV1" letters in https://github.com/FFmpeg/FFV1/pull/243 (source of the early origin, for curious people: https://ffmpeg.org/pipermail/ffmpeg-devel/2006-February/010315.html ) Note: we don't use the term "codec" for FFV1 itself as per https://en.wikipedia.org/wiki/Video_coding_format#Distinction_between_%22format%22_and_%22codec%22 > -- Section 2 -- > In an informational document, the use of BCP 14 is not required. Suggest to > remove this part. Even if it is an informational document so not required, we like to conform to it for being clear about the meaning of the related words, and this specification is the base of the FFV1 version 4 specification which is expected to be a standard document, I would prefer to keep the binding to BCP 14 instead of removing from this FFV1 version 0/1/3 specification then reintroducing it in FFV1 version 4 specification, if not a blocking point. > -- Section 7 -- > Should it be included in section 8 rather than referenced to? I move section 7 in section 8, in https://github.com/FFmpeg/FFV1/pull/243 Jérôme From nobody Mon Oct 5 01:10:16 2020 Return-Path: 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 31F573A0E26; Mon, 5 Oct 2020 01:10:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=jdYlVkpK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=huiPhMXB 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 Rr6Dg5YbmgOn; Mon, 5 Oct 2020 01:10:11 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC5F3A0E25; Mon, 5 Oct 2020 01:10:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1601885411; x=1603095011; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ej0Ev64lHiAy8qF0ES2yGwmcUnG7tbLphybBHh/DlE8=; b=jdYlVkpKn1PUwikqV6iM6yqWAMyV9EyJdy173kR0HkQX0kevoTcuEr/t v8MEhLL9lTesLadcmu4CUuvSLGRCr5dAwPagft3FfZPgbFVmRO6/3ZeDP tSB2fA6eFn8q0ce3/D7254JQna3NENMfO6Ojy8A75Y8GLJQ78wlq7hiL9 Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A2bG/Kx0WObFkm9LxsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWFv6dogVPIVIzB5vsCjefK4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8Pza1zbq2e/5HgUFw?= =?us-ascii?q?msfQZwL/7+T4jVicn/3uuu+prVNgNPgjf1Yb57IBis6wvLscxDiop5IaF3wR?= =?us-ascii?q?zM8XY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DMCQAD1Hpf/5BdJa1ggQmDIVEHcFk?= =?us-ascii?q?vLIN9QINGA41KJph7glMDVQsBAQENAQElCAIEAQGESgIXgiECJTgTAgMBAQs?= =?us-ascii?q?BAQUBAQECAQYEbYVcDIVyAQEBAQMMBhERDAEBNwELBAIBBgIRAwECAQICJgI?= =?us-ascii?q?CAjAVBQMIAgQBDQUigwQBgksDLgEOizKQaQKBOYhhdoEygwEBAQWBMwGDYRi?= =?us-ascii?q?CEAMGgQ4qgnKCXIENgikbhBIbgUE/gREnDBCCTT6CXAEBAQEBgVwXgwAzgi2?= =?us-ascii?q?QG4MipBQKgmeIfpFjAx+DDooChTyOU4RTjkGKbpUoAgQCBAUCDgEBBYFrI4F?= =?us-ascii?q?XcBVICBUBgj5QFwINjisXg06FFIVCdDcCBgEJAQEDCQF7jUwBAQ?= X-IronPort-AV: E=Sophos;i="5.77,338,1596499200"; d="scan'208";a="589135737" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2020 08:10:09 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0958A9SL028116 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 5 Oct 2020 08:10:09 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 03:10:09 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 5 Oct 2020 03:10:08 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 5 Oct 2020 03:10:08 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H9cNPSAdoM3Ii2tCz7wboW0900tv7mTM5SBfMDoeCbPiEWxf6YotqWGubduaY5zkCVZ7QbN/lnxI9Bh5Mfm2uD+JsBL/vIZDnkt4fnUIqxnbwHWqMnXoDEFPB1EcKflKObkOLF5cMv05G9MarnMaHACjzJza+GBIClIWtTLPHaH57b+pbMlMQ1A/vTuVewAJIUkxCg7NkYp7+RhlXd3QypbihwiOXgoqFweFpPXuS5RpxhIc1VzDcmCpZPwtd8YPPYf9KtQcYaYpcpiMYRmnRYWsadg7tZva0gJFcNKxp87l+6Y0uyDtL9UV3rGNKqL8jkvTpdX5fRr0OZd7QAoG4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ej0Ev64lHiAy8qF0ES2yGwmcUnG7tbLphybBHh/DlE8=; b=Hlf4Xoz8q1+riXaCekYnuTEpdjVuGd0nPAiXBHcwZMLJBtk+fZeoxstwbYpyJBUL2aQX43wpG+paQPoojWCx/iD8L6Ey9+JcBgh0RVsBzn9cGGp8Pvl8AlZMNaVIX62G+fPxs49Rb7ykdgZyeEQRVMskhNhGemuTGX3snCWxEIEoWUAmmlDXnomAH6FpiZmkGOB2zpLnXEyq8fAu2jA1xO014fKbM3TG26VHZ8eAMWNQssMymQqdYg0Vq4TsL/Pc7+oIomCHbWo9RdGnOHE2uCpaTMAyjHdpaWuFriPUXlIimDGwQ7e02IVWIgcWJn9+E6G8JkOozWqVlRXdj9S9ew== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ej0Ev64lHiAy8qF0ES2yGwmcUnG7tbLphybBHh/DlE8=; b=huiPhMXBdC0CtItfREFRaWAogSbjUej6RZRFui89KPGHYWJwSlytMkB+vrmUVM1Nb8fCw5JvblmdhevbWXFlNxNRN5AOcRZbESwFLH50R0WLm5kkJCxulvPcFFVXfwI6PY5aVCeeo5Fnr1Xu5Melwfg1QVUK4yup0WtMmlpMFsY= Received: from BN6PR11MB1844.namprd11.prod.outlook.com (2603:10b6:404:103::20) by BN6PR11MB1844.namprd11.prod.outlook.com (2603:10b6:404:103::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.32; Mon, 5 Oct 2020 08:10:07 +0000 Received: from BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::d525:a81a:74e0:12e7]) by BN6PR11MB1844.namprd11.prod.outlook.com ([fe80::d525:a81a:74e0:12e7%12]) with mapi id 15.20.3433.044; Mon, 5 Oct 2020 08:10:07 +0000 From: "Eric Vyncke (evyncke)" To: Jerome Martinez , The IESG CC: "draft-ietf-cellar-ffv1@ietf.org" , "cellar-chairs@ietf.org" , "cellar@ietf.org" , Michael Richardson , "Peter B." Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtY2Vs?= =?utf-8?Q?lar-ffv1-17:_(with_COMMENT)?= Thread-Index: AQHWmuj4UM24dP4tb0mXVD+YgPAYqqmIpqQAgAAi8IA= Date: Mon, 5 Oct 2020 08:10:07 +0000 Message-ID: <3A76E85A-4D3E-4884-8F05-FFFC259F5999@cisco.com> References: <160188283124.21655.15143738833011161583@ietfa.amsl.com> <321b1372-14a0-039d-d022-0670db78c55a@mediaarea.net> In-Reply-To: <321b1372-14a0-039d-d022-0670db78c55a@mediaarea.net> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.41.20091302 authentication-results: mediaarea.net; dkim=none (message not signed) header.d=none;mediaarea.net; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:c0c1:36:46b:7d98:7dda:35e7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 794d590a-9ba3-4ace-88ac-08d8690612c5 x-ms-traffictypediagnostic: BN6PR11MB1844: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WPZAylKRdJkTCVJeeFRtfan3o0JCcmYejS06VyCjEzNPV8KluTDDQjIWXa8R4/MhWtaOeOmRglI4wQZlS/XOmwWZtmWeSz/leB1o3CHuu3redQb2YIwmoW4GO05TL+gpCpQSn79coSKV5eNrSkiEaGljxFmBBeT53YvHT7yDoHJVYfOy+O8akL8ByfIlUDTVmiyosVH4WqPM4EAVYRStC6BLONspseDL4HTxzFXJTD++ptzCjhHPfPb9s0TegW3He8kJ2fl9QG5ps14UhnpGkNVtarFre1ueE4gC4+aV8QfFFmeCO4m3zajXq/wnpWOnlMHU3IbMUEOuDjYTV07DKbXHsdlWzHQKsqRo1xJ1q8MfCKCU4uuKv8KNZAEEnPxl/nIeL6OlrzUPMaw4VX9m9g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB1844.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(376002)(396003)(136003)(39860400002)(366004)(478600001)(316002)(966005)(71200400001)(83080400001)(2616005)(4326008)(86362001)(110136005)(224303003)(6506007)(53546011)(54906003)(66946007)(66446008)(64756008)(66556008)(66476007)(186003)(6512007)(76116006)(91956017)(33656002)(6486002)(2906002)(8936002)(5660300002)(66574015)(83380400001)(36756003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: LS+vmQwMZ7Qds/jaQSCBQ1dstFLiOpPzvYqQbXUNYGhc6+MZYFJZbd/c1zIEJoPnKq6w94baQ3EXtXwv86C7sIp8QdC5xxaMqWs6qfT9XJUpk3VpctJFICb1iBlIKqbQyhRUlsD06DTUoEKMdwJXWuaXeDoUxnJ3ZCe7rwHmvrXk3CgFCT/j5XMrDzMhh76aLFEx1l6/Pvp1A6t3Oth4Gx19srG0dAt4yWCAkn6OiiCpC2ehtduWD6U0zJAHHgfDAUzHyVPcArH+rHP/X7E6rdDDkcf9+KwjPSMx+iTMfhn3k6s5eDjF+ppsocdvOAp7vG7brCNTQlw1RzR6bMnoKpzI4+YXIAa8Dq29esvQ+93rwQ5WZFC/592YzIYafdHHsVwSFb86lCnPrDbKCntLRm0TX5qhQY2a/xRqavqLYmf4jagH5xJbxKjiwszZdoRoW1MYzegaxW7z7EKXCfjDpZK2OEF8cm2q0T5uP/aNspQsnRq5Stq+jna6Yd6JD7gR/UZcHP5X4Poy9V5ixsm8R6d09OxauiGAJVHoHmG9OoRSvrkHuObKRmnmrcP1xWa8/JMrAAfbEOwfNxyGEk3hY5tRct4/OwoN68ssGjEyQ93RWxWb19VriC1naQB5SXmL+iYwAZ79e+q54YmM7FSLTUb25dlGdnV9rqRDJM6zf5ZJ9e/Ugl9cUt7uA3RyJvToUTSY46hgaI+6BOXK+Cdj0g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB1844.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 794d590a-9ba3-4ace-88ac-08d8690612c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2020 08:10:07.7721 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WfEEBOVaZqZUKVssiNGjHKJTZphLgYNutJINqyeEh4sPHz+pe5UupV25KhaF8SidtGKeyRPqKwXNuurxNS3NyQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1844 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Cellar] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ie?= =?utf-8?q?tf-cellar-ffv1-17=3A_=28with_COMMENT=29?= X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 08:10:13 -0000 Qm9uam91ciBKw6lyw7RtZSAod2lsZCBndWVzcyBiYXNlZCBvbiB0aGUgdXNlIG9mIGFjY2VudGVk IGxldHRlcnMpLA0KDQpUaGFuayB5b3UgZm9yIHJlYWRpbmcsIHJlcGx5aW5nLCBhbmQgYWN0aW5n IG9uIG15IHJldmlldy4gDQoNClBsZWFzZSBhY2NlcHQgbXkgYXBvbG9naWVzIGZvciB0aGUgJ2xv c3NsZXNzJyBpbiB0aGUgYWJzdHJhY3QsIGl0IGRpZCBub3Qgc3RyaWtlIG1lIGF0IGZpcnN0IHJl YWRpbmcuLi4gbGV0J3MgcHV0IHRoaXMgY29tbWVudCBvbiBub3QgZW5vdWdoIGNvZmZlZSBvbiBh biBlYXJseSBNb25kYXkgbW9ybmluZw0KDQpJIGhhdmUgbGVhcm5lZCBzb21ldGhpbmcgYWJvdXQg dGhlIGRpZmZlcmVuY2UgYmV0d2VlbiBjb2RlYyAoaW1wbGVtZW50YXRpb24pIGFuZCBmb3JtYXQg KHNwZWNpZmljYXRpb24pLiBBIGdvb2Qgd2VlayBzdGFydCBmb3IgbWUgIQ0KDQpCZXN0IHJlZ2Fy ZHMsDQoNCi3DqXJpYw0KDQrvu78tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogSmVy b21lIE1hcnRpbmV6IDxqZXJvbWVAbWVkaWFhcmVhLm5ldD4NCkRhdGU6IE1vbmRheSwgNSBPY3Rv YmVyIDIwMjAgYXQgMTA6MDUNClRvOiBFcmljIFZ5bmNrZSA8ZXZ5bmNrZUBjaXNjby5jb20+LCBU aGUgSUVTRyA8aWVzZ0BpZXRmLm9yZz4NCkNjOiAiZHJhZnQtaWV0Zi1jZWxsYXItZmZ2MUBpZXRm Lm9yZyIgPGRyYWZ0LWlldGYtY2VsbGFyLWZmdjFAaWV0Zi5vcmc+LCAiY2VsbGFyLWNoYWlyc0Bp ZXRmLm9yZyIgPGNlbGxhci1jaGFpcnNAaWV0Zi5vcmc+LCAiY2VsbGFyQGlldGYub3JnIiA8Y2Vs bGFyQGlldGYub3JnPiwgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+ LCAiUGV0ZXIgQi4iIDxwYkBkYXMtd2Vya3N0YXR0LmNvbT4NClN1YmplY3Q6IFJlOiDDiXJpYyBW eW5ja2UncyBObyBPYmplY3Rpb24gb24gZHJhZnQtaWV0Zi1jZWxsYXItZmZ2MS0xNzogKHdpdGgg Q09NTUVOVCkNCg0KICAgIEhpIMOJcmljLCB0aGFuayB5b3UgZm9yIHlvdSByZXZpZXcuDQogICAg QW5zd2VycyBpbmxpbmU6DQoNCiAgICBPbiAwNS8xMC8yMDIwIDA5OjI3LCDDiXJpYyBWeW5ja2Ug dmlhIERhdGF0cmFja2VyIHdyb3RlOg0KICAgID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgID4gQ09NTUVO VDoNCiAgICA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+DQogICAgPiBUaGFuayB5b3UgZm9yIHRoZSB3 b3JrIHB1dCBpbnRvIHRoaXMgZG9jdW1lbnQuIEkgZm91bmQgaXQgZmFzY2luYXRpbmcgd2hpbGUg aXQNCiAgICA+IGRlc2NyaWJlcyB0aGUgY29kZWMgYWxnb3JpdGhtcy4NCiAgICA+DQogICAgPiBQ bGVhc2UgZmluZCBiZWxvdyBhIGNvdXBsZSBvZiBub24tYmxvY2tpbmcgQ09NTUVOVCBwb2ludHMu DQogICAgPg0KICAgID4gSSBhbHNvIHN1cHBvcnQgQWxpc3NhJ3MgcG9pbnQgYWJvdXQgdXNpbmcg ZmlndXJlIG51bWJlcnMvbGVnZW5kcy4NCiAgICA+DQogICAgPiBJIGhvcGUgdGhhdCB0aGlzIGhl bHBzIHRvIGltcHJvdmUgdGhlIGRvY3VtZW50LA0KICAgID4NCiAgICA+IFJlZ2FyZHMsDQogICAg Pg0KICAgID4gLcOpcmljDQoNCiAgICBXZSBhZGRlZCBhIGNvdXBsZSBvZiBleHBsYW5hdGlvbnMg YW5kIHJlZmVyZW5jZXMsIEkgaG9wZSBpdCBpcyBlYXNpZXIgdG8gDQogICAgcmVhZCBub3cuDQoN CiAgICA+ID09IENPTU1FTlRTID09DQogICAgPg0KICAgID4gLS0gQWJzdHJhY3QgLS0NCiAgICA+ IE1heSBJIHN1Z2dlc3QgdG8gZXhwYW5kL2V4cGxhaW4gRkZWMSBvbiBmaXJzdCB1c2UgPyBTdGls bCB3b25kZXJpbmcgd2hhdCBGRlYxDQogICAgPiBtZWFucyBCVFcuLi4gQWxzbywgdGhlIGxvc3Ns ZXNzIGVuY29kaW5nIGlzIHByb2JhYmx5IHRoZSBrZXkgcHJvcGVydHkgb2YgdGhpcw0KICAgID4g Y29kZWMgYW5kIHNob3VsZCBwcm9iYWJseSBiZSBtZW50aW9uZWQgaW4gdGhlIGFic3RyYWN0Lg0K DQoNCiAgICBJIGRvbid0IGdldCB0aGUgY29tbWVudCwgYXMgaW4gbXkgb3BpbmlvbiBpdCBpcyBm dWxmaWxsZWQgd2l0aCB0aGUgZmlyc3QgDQogICAgc2VudGVuY2Ugb2YgdGhlIGFic3RyYWN0ICJU aGlzIGRvY3VtZW50IGRlZmluZXMgRkZWMSwgYSBsb3NzbGVzcyANCiAgICBpbnRyYS1mcmFtZSB2 aWRlbyBlbmNvZGluZyBmb3JtYXQuIiBmb3IgYm90aCB3aGF0IGlzIEZGVjEgYW5kIGl0cyANCiAg ICBsb3NzbGVzcyBwcm9wZXJ0eS4gQW5kIGl0IGlzIHNpbWlsYXIgdG8gDQogICAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL3JmYzY3MTYgLiBDb3VsZCB5b3UgYmUgbW9yZSBleHBsaWNpdCBh Ym91dCANCiAgICB3aGF0IGlzIG1pc3NpbmcgZnJvbSB5b3VyIHBvaW50IG9mIHZpZXc/DQogICAg SSBhZGRlZCBhIGRlZmluaXRpb24gb2YgIkZGVjEiIGxldHRlcnMgaW4gDQogICAgaHR0cHM6Ly9n aXRodWIuY29tL0ZGbXBlZy9GRlYxL3B1bGwvMjQzDQogICAgKHNvdXJjZSBvZiB0aGUgZWFybHkg b3JpZ2luLCBmb3IgY3VyaW91cyBwZW9wbGU6IA0KICAgIGh0dHBzOi8vZmZtcGVnLm9yZy9waXBl cm1haWwvZmZtcGVnLWRldmVsLzIwMDYtRmVicnVhcnkvMDEwMzE1Lmh0bWwgKQ0KDQogICAgTm90 ZTogd2UgZG9uJ3QgdXNlIHRoZSB0ZXJtICJjb2RlYyIgZm9yIEZGVjEgaXRzZWxmIGFzIHBlciAN CiAgICBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9WaWRlb19jb2RpbmdfZm9ybWF0I0Rp c3RpbmN0aW9uX2JldHdlZW5fJTIyZm9ybWF0JTIyX2FuZF8lMjJjb2RlYyUyMg0KDQoNCiAgICA+ IC0tIFNlY3Rpb24gMiAtLQ0KICAgID4gSW4gYW4gaW5mb3JtYXRpb25hbCBkb2N1bWVudCwgdGhl IHVzZSBvZiBCQ1AgMTQgaXMgbm90IHJlcXVpcmVkLiBTdWdnZXN0IHRvDQogICAgPiByZW1vdmUg dGhpcyBwYXJ0Lg0KDQogICAgRXZlbiBpZiBpdCBpcyBhbiBpbmZvcm1hdGlvbmFsIGRvY3VtZW50 IHNvIG5vdCByZXF1aXJlZCwgd2UgbGlrZSB0byANCiAgICBjb25mb3JtIHRvIGl0IGZvciBiZWlu ZyBjbGVhciBhYm91dCB0aGUgbWVhbmluZyBvZiB0aGUgcmVsYXRlZCB3b3JkcywgDQogICAgYW5k IHRoaXMgc3BlY2lmaWNhdGlvbiBpcyB0aGUgYmFzZSBvZiB0aGUgRkZWMSB2ZXJzaW9uIDQgc3Bl Y2lmaWNhdGlvbiANCiAgICB3aGljaCBpcyBleHBlY3RlZCB0byBiZSBhIHN0YW5kYXJkIGRvY3Vt ZW50LCBJIHdvdWxkIHByZWZlciB0byBrZWVwIHRoZSANCiAgICBiaW5kaW5nIHRvIEJDUCAxNCBp bnN0ZWFkIG9mIHJlbW92aW5nIGZyb20gdGhpcyBGRlYxIHZlcnNpb24gMC8xLzMgDQogICAgc3Bl Y2lmaWNhdGlvbiB0aGVuIHJlaW50cm9kdWNpbmcgaXQgaW4gRkZWMSB2ZXJzaW9uIDQgc3BlY2lm aWNhdGlvbiwgaWYgDQogICAgbm90IGEgYmxvY2tpbmcgcG9pbnQuDQoNCg0KICAgID4gLS0gU2Vj dGlvbiA3IC0tDQogICAgPiBTaG91bGQgaXQgYmUgaW5jbHVkZWQgaW4gc2VjdGlvbiA4IHJhdGhl ciB0aGFuIHJlZmVyZW5jZWQgdG8/DQoNCiAgICBJIG1vdmUgc2VjdGlvbiA3IGluIHNlY3Rpb24g OCwgaW4gaHR0cHM6Ly9naXRodWIuY29tL0ZGbXBlZy9GRlYxL3B1bGwvMjQzDQoNCiAgICBKw6ly w7RtZQ0KDQo= From nobody Mon Oct 5 07:54:38 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9507D3A0B32; Mon, 5 Oct 2020 07:54:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Wilton via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Wilton Message-ID: <160190967658.31262.3611106747790904168@ietfa.amsl.com> Date: Mon, 05 Oct 2020 07:54:36 -0700 Archived-At: Subject: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Oct 2020 14:54:37 -0000 Robert Wilton has entered the following ballot position for draft-ietf-cellar-ffv1-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thank you for taking the time to document FFV1 version 0, 1 and 3. I support Barry's discuss in that I found this document hard to read and interpret. I think that I would struggle to implement a FFV1 encoder/decoded from scratch based on this document. However, this is a long way outside my area of expertise and there is perhaps a corpus of basic video codec knowledge that is assumed in this specification. Is the intention of this document that it gets obsoleted when FFV1 version 4 is documented? I haven't reviewed the entirety of this document, but I do have some comments of particular areas of the document that I found hard to follow that additional text or explanation may be helpful. Overall, having some more introduction text explaining the overall structure of the encoding , i.e. how the different parts fit together would likely help readability. 3.1. Border Figure 2: A depiction of FFV1's assumed border for a set example Samples. I wasn't sure whether an extra row at the bottom of this table would have been helpful, but perhaps it is not required because it is not referenced. 3.2. Samples The labels for these relative "Samples" are made of the first letters of the words Top, Left and Right. Don't feel obliged to change this, but I wonder whether keep lowercase for all of the relative positions might have been clearer. E.g., perhaps using "tt" instead of "T" and "ll" instead of "L". 3.3. Median Predictor Exception for the median predictor ... Possibly putting the exception text into a 3.3.1 sub-section would aid readability. 3.4. Quantization Table Sets It wasn't clear to me what a "Quantized Sample Differences" is. 3.7.2. RGB Cb = b - g Cr = r - g Y = g + (Cb + Cr) >> 2 g = Y - (Cb + Cr) >> 2 r = Cr + g b = Cb + g Perhaps split into two sets of 3 equations to define the relationship in either direction. Exception for the JPEG2000-RCT conversion ... Again, putting this into a sub-section (3.7.2.1) might aid readability, i.e. the split between what is desired vs what is being described due to bugs in real implementations. 3.8. Coding of the Sample Difference coder_input = [(sample_difference + 2 ^ (bits - 1)) & (2 ^ bits - 1)] - 2 ^ (bits - 1) It wasn't clear to me what [] brackets meant here. 3.8.1.1. Range Binary Values I found this hard to follow, as in I couldn't figure out what it means. 3.8.1.4. State Transition Table It wasn't really clear to me what these were used for. 3.8.2.1. Signed Golomb Rice Codes Unclear what is meant by "ESC case" Regards, Rob From nobody Wed Oct 7 08:16:21 2020 Return-Path: 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 329883A0DE4 for ; Wed, 7 Oct 2020 08:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 ZVCApiUy7XB6 for ; Wed, 7 Oct 2020 08:16:17 -0700 (PDT) Received: from 5.mo7.mail-out.ovh.net (5.mo7.mail-out.ovh.net [178.32.120.239]) (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 5E7DC3A0C3D for ; Wed, 7 Oct 2020 08:16:16 -0700 (PDT) Received: from player158.ha.ovh.net (unknown [10.108.42.215]) by mo7.mail-out.ovh.net (Postfix) with ESMTP id 506F717BF46 for ; Wed, 7 Oct 2020 17:16:13 +0200 (CEST) Received: from mediaarea.net (p548f938d.dip0.t-ipconnect.de [84.143.147.141]) (Authenticated sender: jerome@mediaarea.net) by player158.ha.ovh.net (Postfix) with ESMTPSA id C050A16E25064; Wed, 7 Oct 2020 15:16:04 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-95G001228cb78f-619a-4e4e-800b-6f1d137f53f8, FD998853DF21057F47A4E278FE6EA1CC7EFEAE1C) smtp.auth=jerome@mediaarea.net To: Robert Wilton , The IESG Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> From: Jerome Martinez Message-ID: <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> Date: Wed, 7 Oct 2020 17:16:04 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <160190967658.31262.3611106747790904168@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 15833530390383104109 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgeeigdekkecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeekledvfeduhfeufeekjeevudffveduveevffehjedtjeffuefhvdevhefhudefleenucffohhmrghinhepghhithhhuhgsrdgtohhmpdgtohhmphhrvghsshgtohhnshhulhhtrdgtohhmnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegjedrudegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhduheekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:16:20 -0000 Hi Robert, Thank you for your comments. Answers inline: On 05/10/2020 16:54, Robert Wilton via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Hi, > > Thank you for taking the time to document FFV1 version 0, 1 and 3. > > I support Barry's discuss in that I found this document hard to read and > interpret. I think that I would struggle to implement a FFV1 encoder/decoded > from scratch based on this document. However, this is a long way outside my > area of expertise and there is perhaps a corpus of basic video codec knowledge > that is assumed in this specification. > > Is the intention of this document that it gets obsoleted when FFV1 version 4 is > documented? There is no definitive answer but I think that at long term FFV1 version 4 specification is intended to be on IETF standard track, with the decoder based on the specification, and that we will remove all the parts specific to FFV1 version 0, 1 and 3 e.g. all the exceptions documented due to the spec written after the decoder and all the "if version is" related to previous versions, so this document would not be obsoleted when FFV1 version 4 is accepted as an IETF standard. > I haven't reviewed the entirety of this document, but I do have some comments > of particular areas of the document that I found hard to follow that additional > text or explanation may be helpful. > > Overall, having some more introduction text explaining the overall structure of > the encoding , i.e. how the different parts fit together would likely help > readability. Since the last IETF version we added a couple of  introduction texts, with links to other parts, hoping that it helps to clarify the specification. > > 3.1. Border > > Figure 2: A depiction of FFV1's assumed border for a set example > Samples. > > I wasn't sure whether an extra row at the bottom of this table would have been > helpful, but perhaps it is not required because it is not referenced. I don't get this sentence. In my opinion the figure has an arbitrary choice of a slice of 3x3 samples showing the dependencies between samples, showing the exception for the 1st and last lines and columns, and the references are all at the top, left or right. No bottom line here because the compute of the samples doesn't include any sample below the 3x3 samples. > > 3.2. Samples > > The labels for these relative "Samples" are made of the first letters > of the words Top, Left and Right. > > Don't feel obliged to change this, but I wonder whether keep lowercase for all > of the relative positions might have been clearer. E.g., perhaps using "tt" > instead of "T" and "ll" instead of "L". I am personally not in favor of that, the 2-letter lowercase strings being also used for the samples near the reference one, so in my opinion it makes sense to have another method for the sampls far from the reference one. I let another specification writer send a patch if there is a disagreement. > > 3.3. Median Predictor > > Exception for the median predictor ... > > Possibly putting the exception text into a 3.3.1 sub-section would aid > readability. I added this suggestion in https://github.com/FFmpeg/FFV1/pull/247 > > 3.4. Quantization Table Sets > > It wasn't clear to me what a "Quantized Sample Differences" is. I added an introduction in https://github.com/FFmpeg/FFV1/pull/247 > > 3.7.2. RGB > > Cb = b - g > Cr = r - g > Y = g + (Cb + Cr) >> 2 > g = Y - (Cb + Cr) >> 2 > r = Cr + g > b = Cb + g > > Perhaps split into two sets of 3 equations to define the relationship in either > direction. I have split the formulae in https://github.com/FFmpeg/FFV1/pull/247 > > Exception for the JPEG2000-RCT conversion ... > > Again, putting this into a sub-section (3.7.2.1) might aid readability, i.e. > the split between what is desired vs what is being described due to bugs in > real implementations. I added this suggestion in https://github.com/FFmpeg/FFV1/pull/247 > > 3.8. Coding of the Sample Difference > > coder_input = [(sample_difference + 2 ^ (bits - 1)) & > (2 ^ bits - 1)] - 2 ^ (bits - 1) > > It wasn't clear to me what [] brackets meant here. It was for doing the difference between "near" parenthesis and "far" parenthesis, but maybe not a good idea. I added this suggestion to use only parenthesis in https://github.com/FFmpeg/FFV1/pull/247 > > 3.8.1.1. Range Binary Values > > I found this hard to follow, as in I couldn't figure out what it means. This is the mathematical explanation behind the algorithm of Range Coder, without reproducing literature like in http://www.compressconsult.com/rangecoder/#literature I would not change that part because it would be hard in any case, due to the need of specific math skills. > > 3.8.1.4. State Transition Table > > It wasn't really clear to me what these were used for. I added an introduction in https://github.com/FFmpeg/FFV1/pull/247 > 3.8.2.1. Signed Golomb Rice Codes > > Unclear what is meant by "ESC case" I added an explanation in https://github.com/FFmpeg/FFV1/pull/247 Jérôme From nobody Wed Oct 7 08:27:15 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB27A3A0A3C; Wed, 7 Oct 2020 08:27:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160208443280.14819.13101657268052077987@ietfa.amsl.com> Date: Wed, 07 Oct 2020 08:27:12 -0700 Archived-At: Subject: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:27:13 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cellar-ffv1-17: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review). I support Barry Lieba’s Discuss position. A few additional comments on the framing of the codec description not already mentioned by my peers: ** Section 1. Is “non-experimental use” the same as production use? ** References. Why use C89/90 for syntax and C18 for operator precedence? Wouldn’t C18 work for both? ** References. -- Doesn’t Section 4.3.3.2 required [ISO.14496-12.2015] as a normative reference to parse the "glbl" box in the ConfigurationRecord bitstream? -- Doesn’t Section 4.3.3.3 required [NUT] as a normative reference to parse the ConfigurationRecord bitstream? On the security considerations: ** Section 6. Per the reference to [RFC4732], which selection is relevant here? Is it Section 2.1.1? If so, the risks due to end-point compromise are much broader than DoS. ** Section 6. The assertions about the security properties of [REFIMPL] don’t make sense to me in this document. While it is extremely helpful that there is a high-quality reference implementation, it’s relevance to this spec isn’t clear. This code isn’t normative. Recommend removal all text after the paragraph “None of the content carried in FFV1 is intended to be executable”. From nobody Wed Oct 7 08:52:46 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C65FD3A0DC8; Wed, 7 Oct 2020 08:52:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Roman Danyliw via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Roman Danyliw Message-ID: <160208595678.10340.14249512049911790799@ietfa.amsl.com> Date: Wed, 07 Oct 2020 08:52:36 -0700 Archived-At: Subject: [Cellar] Roman Danyliw's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 15:52:42 -0000 Roman Danyliw has entered the following ballot position for draft-ietf-cellar-ffv1-17: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- A simple clarification. Section 6. Implementations of the FFV1 codec need to take appropriate security considerations into account, as outlined in [RFC4732] RFC4732 only covers DoS. A buffer overflow (as described in the subsequent text of this paragraph) in a codec implementation could have dramatically more significant consequences for the endpoint (or the services it provides) than a DoS. It could potentially lead to arbitrary remote code execution on the system (barring defensive mitigations provided by sandboxing in the app, OS execution protections; and/or end-point protection software) which pretty much enables an attacker to do anything of their choosing on the system. Please note that. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- (Sorry for any confusion with the updated ballot. I didn't cut-and-paste all of the text. COMMENT is the same. DISCUSS is added.) Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for providing the review). I support Barry Lieba’s Discuss position. A few comments on the framing of the codec description: ** Section 1. Is “non-experimental use” the same as production use? ** References. Why use C89/90 for syntax and C18 for operator precedence? Wouldn’t C18 work for both? ** References. -- Doesn’t Section 4.3.3.2 required [ISO.14496-12.2015] as a normative reference to parse the "glbl" box in the ConfigurationRecord bitstream? -- Doesn’t Section 4.3.3.3 required [NUT] as a normative reference to parse the ConfigurationRecord bitstream? On the security considerations: ** Section 6. Per the reference to [RFC4732], which selection is relevant here? Is it Section 2.1.1? ** Section 6. The assertions about the security properties of [REFIMPL] don’t make sense to me in this document. While it is extremely helpful that there is a high-quality reference implementation, it’s relevance to this spec isn’t clear. This code isn’t normative. Recommend removal all text after the paragraph “None of the content carried in FFV1 is intended to be executable”. From nobody Wed Oct 7 09:00:28 2020 Return-Path: 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 F26443A0AB2; Wed, 7 Oct 2020 09:00:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ihnoZ_uEHGpj; Wed, 7 Oct 2020 09:00:25 -0700 (PDT) Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646CA3A0AAB; Wed, 7 Oct 2020 09:00:25 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id b142so2192564ybg.9; Wed, 07 Oct 2020 09:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TACsWBtpBYp4yXJ7v03nb6c+yadRnjiGJun9UI23F8E=; b=XktUgNe07qKW+SP5c9xy0JXv5Ylp7qHhZq4UvInjPpJd0QJj/moAeoSNd3yaEHEisI xU3BUK0rCsZd2UvE5mzzQljjQX9usH8yJzKn6MoRqAzia/5eVuHRZng94k1T2nYIhZ69 mrCCVRBSXzexOouBCICrY9XVZGv04IdD3/T9g8mbjSUt24mnBNTN/hxjV20vgPq706cq ayx7P9iN0zOztQzWOvRakX2LniOMc9Iy8tXwyCFkRplI8VNR+MCdGyr+DaY8GQU7q/sP 9f6HeqY/d/gGloazIOA9zCz1a47RjClfY41ZLBVJyVEFTVFLdezh2gMK5AYxjwrif8wV 4rqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TACsWBtpBYp4yXJ7v03nb6c+yadRnjiGJun9UI23F8E=; b=kkCI7t80nM6yFL2Bt1IEB3KXPhWZT4gTOsFtA9kHvvTibjn/dkirOEIxNCug8nvAri ZSl07ioa8SanSnHan5EgX0Damo/9KJ4gQn+a4+/qaSZC62d1LLg/pZl2MAwqiozrXkzM 7qxmembL9Kx6dJSGRCX0IIVuAY0FylHerZtBqo0UdbcqQWQj530Vv2KekEYpR7b5MJ08 uPpZ2SJ/N0ogmot3WWsu9XCodXu/ZpEmmD7RLr1dFsom3IdPM8c2mSMs96zxg+vNtMOT pTQO8ZGkV9Q1yzuV+cXsR94rUt24e0/EMrk10PYIO6qu9DX3MGl1lz28Rp7BHhPkdKTI xyKQ== X-Gm-Message-State: AOAM533LpsVPj4Qd3onBqkVtREEtG0ur77wp3xsBcjRWa8QP5OARezZK 7cpIBeuBt+kgPzS0/3BITOpi90pnrT+bXTGyVTg= X-Google-Smtp-Source: ABdhPJyyDeyp9r2/mK5E9fUZSZzzWAN4hO5sfHxO9xXoc+bzG7WSdTYas54aTkjX9VRbdmKBAKmgXXJZuI9WdWmuJNg= X-Received: by 2002:a25:384e:: with SMTP id f75mr4912909yba.389.1602086424588; Wed, 07 Oct 2020 09:00:24 -0700 (PDT) MIME-Version: 1.0 References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> In-Reply-To: <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> From: Spencer Dawkins at IETF Date: Wed, 7 Oct 2020 10:59:58 -0500 Message-ID: To: Jerome Martinez Cc: Robert Wilton , The IESG , draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , Michael Richardson , "Peter B." Content-Type: multipart/alternative; boundary="0000000000003cb6be05b116d0c0" Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 16:00:27 -0000 --0000000000003cb6be05b116d0c0 Content-Type: text/plain; charset="UTF-8" Hi, Robert, On Wed, Oct 7, 2020 at 10:16 AM Jerome Martinez wrote: > Hi Robert, > Thank you for your comments. Answers inline: > > On 05/10/2020 16:54, Robert Wilton via Datatracker wrote: > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Hi, > > > > Thank you for taking the time to document FFV1 version 0, 1 and 3. > > > > I support Barry's discuss in that I found this document hard to read and > > interpret. I think that I would struggle to implement a FFV1 > encoder/decoded > > from scratch based on this document. However, this is a long way > outside my > > area of expertise and there is perhaps a corpus of basic video codec > knowledge > > that is assumed in this specification. > > > > Is the intention of this document that it gets obsoleted when FFV1 > version 4 is > > documented? > > There is no definitive answer but I think that at long term FFV1 version > 4 specification is intended to be on IETF standard track, with the > decoder based on the specification, and that we will remove all the > parts specific to FFV1 version 0, 1 and 3 e.g. all the exceptions > documented due to the spec written after the decoder and all the "if > version is" related to previous versions, so this document would not be > obsoleted when FFV1 version 4 is accepted as an IETF standard. > Just to follow up on Jerome's more experienced answer, https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ is listed as Standards Track, so yes, that's the goal. Questions of what's obsoleted, or declared Historic, or otherwise done to FFV1 version 0, 1 and 3, would be decided by the working group, AD, and IESG when FFV1 version 4 is in IESG Evaluation, I think? If that's not the case, I'll let someone correct me. Best, Spencer --0000000000003cb6be05b116d0c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Robert,=C2=A0

On Wed, Oct 7, 2020 at 1= 0:16 AM Jerome Martinez <jerome@= mediaarea.net> wrote:
Hi Robert,
Thank you for your comments. Answers inline:

On 05/10/2020 16:54, Robert Wilton via Datatracker wrote:
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Hi,
>
> Thank you for taking the time to document FFV1 version 0, 1 and 3.
>
> I support Barry's discuss in that I found this document hard to re= ad and
> interpret.=C2=A0 I think that I would struggle to implement a FFV1 enc= oder/decoded
> from scratch based on this document.=C2=A0 However, this is a long way= outside my
> area of expertise and there is perhaps a corpus of basic video codec k= nowledge
> that is assumed in this specification.
>
> Is the intention of this document that it gets obsoleted when FFV1 ver= sion 4 is
> documented?

There is no definitive answer but I think that at long term FFV1 version 4 specification is intended to be on IETF standard track, with the
decoder based on the specification, and that we will remove all the
parts specific to FFV1 version 0, 1 and 3 e.g. all the exceptions
documented due to the spec written after the decoder and all the "if <= br> version is" related to previous versions, so this document would not b= e
obsoleted when FFV1 version 4 is accepted as an IETF standard.

Just to follow up on Jerome's more experienced = answer,=C2=A0https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ i= s listed as Standards Track, so yes, that's the goal.

Questions of what's obsoleted, or declared Historic, or otherwi= se done to=C2=A0FFV1 version 0, 1 and 3, would be decided by the working gr= oup, AD, and IESG when FFV1 version 4 is in IESG Evaluation, I think?
=

If that's not the case, I'll let someone correc= t me.

Best,

Spencer
=
--0000000000003cb6be05b116d0c0-- From nobody Wed Oct 7 09:09:24 2020 Return-Path: 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 CA48A3A0AF1 for ; Wed, 7 Oct 2020 09:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.111 X-Spam-Level: X-Spam-Status: No, score=-2.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 F7YjR96Z6S6d for ; Wed, 7 Oct 2020 09:09:20 -0700 (PDT) Received: from 7.mo173.mail-out.ovh.net (7.mo173.mail-out.ovh.net [46.105.44.159]) (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 EA70A3A0AE6 for ; Wed, 7 Oct 2020 09:09:19 -0700 (PDT) Received: from player798.ha.ovh.net (unknown [10.108.57.49]) by mo173.mail-out.ovh.net (Postfix) with ESMTP id CDBFE14F9BB for ; Wed, 7 Oct 2020 18:09:17 +0200 (CEST) Received: from mediaarea.net (p548f938d.dip0.t-ipconnect.de [84.143.147.141]) (Authenticated sender: jerome@mediaarea.net) by player798.ha.ovh.net (Postfix) with ESMTPSA id 3B37817046033; Wed, 7 Oct 2020 16:09:10 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-105G00673067e21-019e-422d-9bf8-582af52ed9ff, FD998853DF21057F47A4E278FE6EA1CC7EFEAE1C) smtp.auth=jerome@mediaarea.net To: Roman Danyliw , The IESG Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." References: <160208443280.14819.13101657268052077987@ietfa.amsl.com> From: Jerome Martinez Message-ID: <42401d7a-9de3-5bc5-f7f8-5c7bd5c53488@mediaarea.net> Date: Wed, 7 Oct 2020 18:09:10 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <160208443280.14819.13101657268052077987@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 16730028194635649133 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgeeigddutddtucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuqfggjfdpvefjgfevmfevgfenuceurghilhhouhhtmecuhedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepuffvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomheplfgvrhhomhgvucforghrthhinhgviicuoehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvtheqnecuggftrfgrthhtvghrnhepkefhvdfguefhgfeghfffhfdtheffhfduueevjedtgfejgfelleeujeehteffgfejnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkpheptddrtddrtddrtddpkeegrddugeefrddugeejrddugedunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpqdhouhhtpdhhvghlohepphhlrgihvghrjeelkedrhhgrrdhovhhhrdhnvghtpdhinhgvtheptddrtddrtddrtddpmhgrihhlfhhrohhmpehjvghrohhmvgesmhgvughirggrrhgvrgdrnhgvthdprhgtphhtthhopegtvghllhgrrhesihgvthhfrdhorhhg Archived-At: Subject: Re: [Cellar] Roman Danyliw's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 16:09:22 -0000 Hi Roman, Thank you for your comments, answers inline: On 07/10/2020 17:27, Roman Danyliw via Datatracker wrote: > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for responding to the SECDIR feedback (and thank you to Liang Xia for > providing the review). > > I support Barry Lieba’s Discuss position. > > A few additional comments on the framing of the codec description not already > mentioned by my peers: > > ** Section 1. Is “non-experimental use” the same as production use? I would rather say that the bitstream is frozen, flagged as stable. I suggested a change in the wording in https://github.com/FFmpeg/FFV1/pull/248 > > ** References. Why use C89/90 for syntax and C18 for operator precedence? > Wouldn’t C18 work for both? the previous reference was written years before C18 doc, I don't see any conflict with C18 here so I proposed to change to C18 in https://github.com/FFmpeg/FFV1/pull/248 > > ** References. > -- Doesn’t Section 4.3.3.2 required [ISO.14496-12.2015] as a normative > reference to parse the "glbl" box in the ConfigurationRecord bitstream? In understand that the normative reference is when its knowledge is essential to the understanding, and this is not the case here as it is only for people wanting to implement FFV1 in [ISO.14496-12.2015]. Isn't it correct? > -- Doesn’t Section 4.3.3.3 required [NUT] as a normative reference to parse the > ConfigurationRecord bitstream? In addition to the remark about [ISO.14496-12.2015], NUT is very informal, no standardization, so even less essential. > > On the security considerations: > ** Section 6. Per the reference to [RFC4732], which selection is relevant > here? Is it Section 2.1.1? If so, the risks due to end-point compromise are > much broader than DoS. > > ** Section 6. The assertions about the security properties of [REFIMPL] don’t > make sense to me in this document. While it is extremely helpful that there is > a high-quality reference implementation, it’s relevance to this spec isn’t > clear. This code isn’t normative. Recommend removal all text after the > paragraph “None of the content carried in FFV1 is intended to be executable”. > > > I have open a discussion with other writers specifically about the security considerations at https://github.com/FFmpeg/FFV1/pull/249 Jérôme From nobody Wed Oct 7 09:51:36 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 259BE3A0B83; Wed, 7 Oct 2020 09:51:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160208949210.20172.8797037420619341327@ietfa.amsl.com> Date: Wed, 07 Oct 2020 09:51:32 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-18.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 16:51:32 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 0, 1, and 3 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-18.txt Pages : 56 Date : 2020-10-07 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ There is also an HTML version available at: https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-18 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 7 09:51:40 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A8B3A0B29; Wed, 7 Oct 2020 09:51:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160208949304.14760.1313891718082014400@ietfa.amsl.com> Date: Wed, 07 Oct 2020 09:51:33 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-ffv1-v4-15.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 16:51:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : FFV1 Video Coding Format Version 4 Authors : Michael Niedermayer Dave Rice Jerome Martinez Filename : draft-ietf-cellar-ffv1-v4-15.txt Pages : 56 Date : 2020-10-07 Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1-v4/ There is also an HTML version available at: https://www.ietf.org/id/draft-ietf-cellar-ffv1-v4-15.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-v4-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 7 11:39:50 2020 Return-Path: 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 F128E3A0F55; Wed, 7 Oct 2020 11:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 YDo79YgNDY0n; Wed, 7 Oct 2020 11:39:46 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A1613A0F50; Wed, 7 Oct 2020 11:39:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0355A389E2; Wed, 7 Oct 2020 14:45:09 -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 oy79imdXhr-G; Wed, 7 Oct 2020 14:45:08 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F3721389C9; Wed, 7 Oct 2020 14:45:07 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 305EBF5; Wed, 7 Oct 2020 14:39:44 -0400 (EDT) From: Michael Richardson To: Robert Wilton , The IESG , draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , "Peter B." In-Reply-To: References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> 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 Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 18:39:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Spencer Dawkins at IETF wrote: > Questions of what's obsoleted, or declared Historic, or otherwise done > to FFV1 version 0, 1 and 3, would be decided by the working group, AD, > and IESG when FFV1 version 4 is in IESG Evaluation, I think? I understood that FFV1 version 0/1/3 was Informational. I guess it could be marked Historic by the IESG at some point. I didn't think that time would be when FFV1 v4 was published, but sure. I thought that this was even in our charter somewhere, so I'm confused by this thread. This follows the pattern of publishing an RFC that is not within IETF revision control that documents "current practice", and then publishing an RFC on standards track, that is within IETF revision control. Here "revision control" means we can change the bits-in-the-wire (or in the file) in incompatible ways. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9+C28ACgkQgItw+93Q 3WV9eQf6AiV+lQI+Uc5YmaCwc6ikAu5vAdw+574nsF+oTRMBOoFcgLrEZC4ZHy+s wVDymEm6tcf1EKrhh13/ZHlMz7McYvLu3+5qwUv3PQs3G/haDaX9mgxWzT8AAN59 CVDu83KR3ViDWwakzvSoiKhT+BW7rmwlqg876FpM6FlNhS6EN1lGZJyzIzzqJZqE wxYMxXV3pK6WIjeKIpAcO/aJ5RQycAAVMLJt0kIo+2e0ccZxmazhhZHm/FvgvbUQ aG9bPZnFUrrBPLBjsUaAR4rxLhAsAwQ18roTred3Zx7weFUgAeljVgfm7jk80eRJ aJ5MZC0N2khOvJNJ/L2AnzoZOckIjA== =EmzM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 7 11:54:15 2020 Return-Path: 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 C35DE3A1302; Wed, 7 Oct 2020 11:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 Lkn1K06YiWZZ; Wed, 7 Oct 2020 11:54:08 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6822C3A1301; Wed, 7 Oct 2020 11:54:08 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id h6so2577269ybi.11; Wed, 07 Oct 2020 11:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nNAiFlr30tBmAHIEBqfwC6fMBdpApMGANQCsmgZsXuI=; b=s498soME5BW1yd2WTvRJnLd35nbtmeM5ngm2mkgQ0GN/D4Rlz3oE9ebLx0LjEFQBQ6 h6G2x5YaDoRxpewkeLL4Ly1aBWiweBdeOekzCEln53YXLMh49oX4yhKU/S5kq4CD+S9L iU7sTm4MRnq3O3OPNuajUyGt8cmF0MSfQ7EqY9OAaFtia+tlVYy+isiLJG5DhXTl3cAW pK0eNPih70JVps/ileYUTc2EytoSzkzDAnjKy3ScFnu552M43PsoQvly25VkyRxtmu+Y BQmq4lL9+Bh25qPx7jPscET1K451MwbnVBDy8ieSkbLLWVotlGTG9EPX+KCirEvBbp1E ejdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nNAiFlr30tBmAHIEBqfwC6fMBdpApMGANQCsmgZsXuI=; b=YlEk2HRHmmUU2QhsMmN01cdwNOHaMUcShEzr00fY9dFvTuv9vw0LCEtV63XnHWyz8P DUh+azeepvohdENxWZfQev4cA51gNg0p0a0Ka22oldpu1Iv/CkzFQdt8brNuZX6abywc 0gBaXeoL0Pqga9CYi1BkZ7+3UC1UXumQ5IROZwU2fNFHUimNY+gxvi8QjUoF8KxB5H3p Kif56MYGCLlJkXwFZd0rLAkaMtH+Kf7oN6nbZ8Dp+m5R/sdqkpERLuaWMJaJ0j4zpHfe M2TBZtRh3km7K6sAseY01P6f5sm94Ij0SRSXLDdZjH1syB+3h49taTX1V7UipB1W3YEs 2ebw== X-Gm-Message-State: AOAM532/Zdw4klvyF4ANuWah2D5rRTve86a82Deg+nnQbgCTPEUnMFoH R7mhHYabQQiuQwOUuJbJ9Mns8/4kE11s0s3E0QY= X-Google-Smtp-Source: ABdhPJyJK75txZZqnE9f/jYMaRTup2lRFiX13q1KN4dkVClNu4uFNVKq9QCJB9rXOf+nL29KDQvYh/Fq7D7vG5JGvnE= X-Received: by 2002:a25:ae4d:: with SMTP id g13mr5669369ybe.288.1602096847605; Wed, 07 Oct 2020 11:54:07 -0700 (PDT) MIME-Version: 1.0 References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> <18667.1602095984@localhost> In-Reply-To: <18667.1602095984@localhost> From: Spencer Dawkins at IETF Date: Wed, 7 Oct 2020 13:53:41 -0500 Message-ID: To: Michael Richardson Cc: Robert Wilton , The IESG , draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, Codec Encoding for LossLess Archiving and Realtime transmission , "Peter B." Content-Type: multipart/alternative; boundary="0000000000007f555b05b1193dce" Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 18:54:10 -0000 --0000000000007f555b05b1193dce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Michael, On Wed, Oct 7, 2020 at 1:39 PM Michael Richardson wrote: > > Spencer Dawkins at IETF wrote: > > Questions of what's obsoleted, or declared Historic, or otherwise > done > > to FFV1 version 0, 1 and 3, would be decided by the working group, > AD, > > and IESG when FFV1 version 4 is in IESG Evaluation, I think? > > I understood that FFV1 version 0/1/3 was Informational. > I guess it could be marked Historic by the IESG at some point. > I didn't think that time would be when FFV1 v4 was published, but sure. > Yeah, I should have said "at the earliest, when FFV1 version 4 was approved", but my intention was to say "not yet". I could have also reasonably said "or takes no action to twiddle the status of FFV1 version 0/1/3" - that's also a path that would be open. And I wasn't trying to guess what would happen. Different IESGs have handled these situations on a case by case basis. > I thought that this was even in our charter somewhere, so I'm confused by > this thread. > Yup. I'm looking at this, from the charter. - Informational specification for FFV1 video codec versions 0, 1 and 3 to IESG for publication Best, Spencer > This follows the pattern of publishing an RFC that is not within IETF > revision control that documents "current practice", and then publishing a= n > RFC on standards track, that is within IETF revision control. > > Here "revision control" means we can change the bits-in-the-wire > (or in the file) in incompatible ways. > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > --0000000000007f555b05b1193dce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Michael,

On Wed, Oct 7, 2020 at 1:39 P= M Michael Richardson <mcr+iet= f@sandelman.ca> wrote:

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
=C2=A0 =C2=A0 > Questions of what's obsoleted, or declared Historic,= or otherwise done
=C2=A0 =C2=A0 > to FFV1 version 0, 1 and 3, would be decided by the work= ing group, AD,
=C2=A0 =C2=A0 > and IESG when FFV1 version 4 is in IESG Evaluation, I th= ink?

I understood that FFV1 version 0/1/3 was Informational.
I guess it could be marked Historic by the IESG at some point.
I didn't think that time would be when FFV1 v4 was published, but sure.=

Yeah, I should have said "at the = earliest, when FFV1 version 4 was approved", but my intention was to s= ay "not yet".

I could have also reasonab= ly said "or takes no action to twiddle the status of FFV1 version 0/1/= 3" - that's also a path that would be open.=C2=A0

And I wasn't trying to guess what would happen. Different IESG= s have handled these situations on a case by case basis.
=C2=A0
I thought that this w= as even in our charter somewhere, so I'm confused by
this thread.

Yup. I'm looking at th= is, from the charter.

=C2=A0- Informational specif= ication for FFV1 video codec versions 0, 1 and 3 to IESG for publication

Best,

Spencer

This follows the pattern of publishing an RFC that is not within IETF
revision control that documents "current practice", and then publ= ishing an
RFC on standards track, that is within IETF revision control.

Here "revision control" means we can change the bits-in-the-wire<= br> (or in the file) in incompatible ways.


--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




--0000000000007f555b05b1193dce-- From nobody Wed Oct 7 16:46:16 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 89D8E3A14E9; Wed, 7 Oct 2020 16:46:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-cellar-ffv1@ietf.org, cellar-chairs@ietf.org, cellar@ietf.org, Michael Richardson , "Peter B." , pb@das-werkstatt.com X-Test-IDTracker: no X-IETF-IDTracker: 7.19.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <160211437299.10379.9560967604011732157@ietfa.amsl.com> Date: Wed, 07 Oct 2020 16:46:13 -0700 Archived-At: Subject: [Cellar] Benjamin Kaduk's Abstain on draft-ietf-cellar-ffv1-18: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Oct 2020 23:46:14 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-cellar-ffv1-18: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Roman's Discuss. I am balloting Abstain in that I am not confident that this document has received sufficient review, but have not identified specific flaws or areas of uncertainty that sould justify blocking publication, and accordingly do not wish to block its publication. In particular, I am not confident that I myself understand how all the pieces fit together -- even though some of my comments below might indicate internal inconsistencies or other issues that would justify a Discuss position, I am not fully confident in that, nor am I confident that I could judge that they have been adequately addressed by any proposed changes to the document's text. (This is in large part related to Barry's Discuss.) That said, my review comments on the document appear below. It might make sense to have a bit of discussion on what types of things would (or would not) change in a new micro version, vs new "macro" version, and what could be said to be "invariants" of the format overall. Should we give more treatment (or even an IANA registry) for how extensibility will be achieved for (e.g.) new "coder_type" and "colorspace_type" values? Section 2.2.9.4 "get_bits( i )" is the action to read the next "i" bits in the bitstream, from most significant bit to least significant bit, and to return the corresponding value. [...] [I guess this "value" is always in the form of an unsigned integer.] Section 3.3 It is expected (to be confirmed) to remove this exception for the median predictor in the next version of the FFV1 bitstream. When can/will the confirmation process happen? When version 4 is finalized? Section 3.6 The discussion seems to imply that the chroma planes are not used in FFV4 (and so the check for "version <= 3" in the logic here is just for future compatibility); is that correct? Section 3.7 color space. In YCbCr for each "Plane", each "Line" is coded from top to bottom and for each "Line", each "Sample" is coded from left to right. In JPEG2000-RCT for each "Line" from top to bottom, each Is there a reason that we use "JPEG2000-RCT" in the prose here, but "RGB" for the section 3.7.2 heading? Section 3.8.1.1 The defined terms do not cover all terms used (so I conclude that there are unnamed intermediate values) and the formulae themself do not do a great job of conveying where the overall inputs/outputs are, thus the flow of the encoding logic. Captions on the figures might help, which could include indications of which intermediate values from from formula to formula. It also seems like some of the intermediate values could be usefully named, e.g., R_(i) seems to serve the role of the remaining range at a given step. Section 3.8.1.2 Does "non binary" mean "non-integer", i.e., floating point? We don't seem to use the "non binary" term elsewhere in the document. I'm also not sure I'm reading the formula properly -- state is a uint8_t but the indexing into it seems to make more sense to me if treated as bit indexing, not byte indexing. (E.g., 'a' is only doubled when iterating through 22..31, indicating bitwise representation.) int e = 0; while (get_rac(c, state + 1 + min(e, 9)) { //1..10 e++; } It looks like this enters an infinite loop if get_rac(c, state + 10) returns true; is there something to enforce that this does not happen? "get_rac" returns a boolean, computed from the bytestream as described in Section 3.8.1.1. I suggest saying a little bit more about how this works, e.g., that the boolean is a single-bit integer value, and how this functional notation maps to the interfaces of the expressions in Section 3.8.1.1. Section 3.8.2.1 What is 'bits' (the argument to the last get_bits() call) in Figure 20? (Is it the same "bits_per_raw_sample" from §3.8? If so, that description should be qualified to apply more broadly than just "the equation below".) Section 3.8.2.2.1 What are 'x' and 'w' (and how are they set)? What are the semantics of "run_mode" values 1 vs 2? Section 3.8.2.3 I guess it's implicit that "output_number" is of the appropriate (width) type for the desired output bit width. Section 3.8.2.4 I guess "i += i" vs "i *= 2" is just a matter of style. Where does the 'bits' input to sign_extend() come from? (Is it the same "bits_per_raw_sample" from §3.8? If so, that description should be qualified to apply more broadly than just "the equation below".) Section 3.8.2.4.1 I suggest rewording or using a section reference for "normal difference coding" as the phrase "difference coding" does not suffice (via text search) to find the referenced procedure, since this is the only instance of the phrase in the document. Section 4.1 I'm not sure how to parse "number of equal entries -1". In combination with the example I can guess what is meant, but I still can't parse the text. The "Table" listed in the example does not seem to conform to "second half [...] is identical to the first with flipped sign". Also, the QuantizationTable() pseudocode suggests that the Table should have 256 entries, but this example only has 16. (That may be fine for example purposes, but the difference should be called out.) Section 4.2 C uses 0-indexed arrays, but the pseudocode seems to use 1-indexed arrays (e.g., state_transition_delta[]). Perhaps this is noteworthy. Section 4.5 If 'reserved' is only present when version <=1, it seems unlikely that a revision of this specification would assign semantics to it. Section 4.6.x nit: "if not present" could be taken to suggest that this field is optional at field-level granularity (vs. at header-/version-level granularity); "if header not present" might be slightly more clear. Section 6 If we are attempting to differentiate between "format" and "codec", are the uses of "codec" in this section all correct? It may (or may not) be worth calling out the importance of internal consistency within an implementation as to whether the Parameters() appear in the ConfigurationRecord() or in each Frame(). In all of the conditions above, the decoder and encoder was run inside the [VALGRIND] memory debugger as well as clangs address sanitizer [Address-Sanitizer], which track reads and writes to nit: "clang's" with apostrophe. Section 10 I don't see a particular reason that RFC 6716 needs to be a normative reference. (I also agree with Roman that there doesn't seem to be need to reference both C90 and C18.) Appendix A, B It is surprising to see BCP 14 keywords in these nominally informative sections. From nobody Thu Oct 8 03:40:18 2020 Return-Path: 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 0063A3A0AB8; Thu, 8 Oct 2020 03:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hpdbQ+aL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=n9m8Xr6Z 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 zKKYo8aEY4cb; Thu, 8 Oct 2020 03:40:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5A13A05A6; Thu, 8 Oct 2020 03:40:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3396; q=dns/txt; s=iport; t=1602153614; x=1603363214; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=G0p06beKp9A46IuHcmlXesbyfx+MMNbJ2CSYm3/KZ88=; b=hpdbQ+aL67px+s49hoUipQpnMGg0ztUhUsKpbWUvQeFzcKqcEG0B4xBr dEv18rIw5UB1PhTr+1EG5kTr+eXIScCbZAK/VJobio9cXpiUd8cQd6wC5 EqF7jx4FQKbXxnRPpKutL4GTm2uKnz5kVWFhvFMYMs3q/SxcK3WLbcjeZ g=; IronPort-PHdr: =?us-ascii?q?9a23=3Agf9cExC74WcnSc7UANkuUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw31A3SVIPX5vZBguyQuKmzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutfFTUrnC26DcUXB?= =?us-ascii?q?72ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CWGgCW635f/4wNJK1gHgEBCxIMQIM?= =?us-ascii?q?hIy4HgUkvLAqEM4NGA411ihGOaoJTA1ULAQEBDQEBLQIEAQGBVYJ1AheBcgI?= =?us-ascii?q?lOBMCAwEBCwEBBQEBAQIBBgRthVwMhXIBAQEBAxIREQwBASkPCwQCAQgRBAE?= =?us-ascii?q?BAQICJgICAh8RFQgIAgQBEggahVADLgEDnXkCgTmIYXaBMoMBAQEFhSwNC4I?= =?us-ascii?q?QCYEOKoJyg2uCRIQSG4FBP4ERQ4JNPoIagiWDFTOCLZArgxmjR1IKgmiVXIU?= =?us-ascii?q?toS+TGo1bkkECBAIEBQIOAQEFgWsjgVdwFYMkUBcCDY4fDBeDToodATh0NwI?= =?us-ascii?q?GAQkBAQMJfIw7AYEQAQE?= X-IronPort-AV: E=Sophos;i="5.77,350,1596499200"; d="scan'208";a="809485151" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 10:40:12 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 098AeClY023061 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2020 10:40:12 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 05:40:12 -0500 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 05:40:11 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 06:40:10 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DcABI/Hd5lbj90N/BLJu6m+rvtz+U8KbjtG2BxSvu7RgdlX7xZtOZFduwkxKdAoD8H6lU/ehp+WsW9Dxh+JuEsPIFuV7IeikzWobY+Cm4TthJOgeZfav87vE7x8KkXGQGvywMyshVS3Z+ZGA6MZAWhusbF8dK4vL96H5QU22HfpZq13e4whAfdPj7EKl1R6MA3qfeicNf0cVZ19Ptc8cBgadgTecSU6CRo4t2jSr5mB25DcC5HqQeFmPobnP6KsQqq3kwHt1FSMNbcFMQUOJ3FQuhVpyA/psj1IROs1KcgeQ6rCNaONzq4OBEVh2hTxiXzKNqJk1qvTUU8TUugCdiw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G0p06beKp9A46IuHcmlXesbyfx+MMNbJ2CSYm3/KZ88=; b=BMNZZaKAzZo/zqKwXEAmfSKDh8f28yA4cf+1vl2BKngQNxwcBgP4I/ZfcBJcyTtjf/G1PJTf6vu/g5ORbYyj4fvy0Ch183BScuuTamWomSAqX5YAC1JCEoz0d6akqmHXkwJxrvKmJzGzGfEjDy8ev9huCXcY9kQGRF8Hm0nrbsMKkdmYPd70VMrZndN00BxxfTuo+ui2qpmLgJ8VSftTKCO9kRPdAXvrNHaOLQAqsW8pRrXt/hVrir+KUZgOeelOyYiqEoX2hYVxLUnj2OpGKHMUH3ZpGr6T8ppfZIzBtM7vWJ6gkprQRQ9pL3PYygi5i2jprCUacr53qly73uHMhQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=G0p06beKp9A46IuHcmlXesbyfx+MMNbJ2CSYm3/KZ88=; b=n9m8Xr6Z9im3MGZOZJkaOjn4Tv4asgoKtJ8KXRbMD1KgFi2ukfKpPkyDejpOOta1dLQZZjfHlf7GUgt9bHIXl/O097FAuMpU7bgKc+cClQsk1nEwT97YTj/anyt29q3eZU27i2lQJ9M6e8f6OAYkSc869yXdALdT41tiMi4IfHc= Received: from MN2PR11MB4366.namprd11.prod.outlook.com (2603:10b6:208:190::17) by BL0PR11MB3059.namprd11.prod.outlook.com (2603:10b6:208:30::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3455.23; Thu, 8 Oct 2020 10:40:09 +0000 Received: from MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241]) by MN2PR11MB4366.namprd11.prod.outlook.com ([fe80::d84a:115:9ce0:8241%4]) with mapi id 15.20.3433.045; Thu, 8 Oct 2020 10:40:09 +0000 From: "Rob Wilton (rwilton)" To: Michael Richardson , The IESG , "draft-ietf-cellar-ffv1@ietf.org" , "cellar-chairs@ietf.org" , "Codec Encoding for LossLess Archiving and Realtime transmission" , "Peter B." Thread-Topic: Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) Thread-Index: AQHWmyeD7J+mL43sBU2OrWKIrRaQbKmMQzwAgAAMRACAACyjAIAA5B8A Date: Thu, 8 Oct 2020 10:40:09 +0000 Message-ID: References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> <18667.1602095984@localhost> In-Reply-To: <18667.1602095984@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: sandelman.ca; dkim=none (message not signed) header.d=none;sandelman.ca; dmarc=none action=none header.from=cisco.com; x-originating-ip: [82.12.233.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b3a02bab-1723-49de-d6f0-08d86b76877f x-ms-traffictypediagnostic: BL0PR11MB3059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: srLN33A9SbOchO2SMHzo4wkPGO4vTL9LVotRjeyJttCUtkAGV6+rdiVlT1NOPh9qA5Emf7IVUJVVE9ffWqsYg+xbUhbPn93BMAWsn252dt+YkKvl5fGz68q+PUVZzaXPbK5zTfWLXjMCw3Luv6vcp6JjB0phf9gSWzQqffiri7KvQjh9H5+vSaQMQ9ybtuUvujixyEQegpzvIwGqNyNotYQ4WxCmnDaKRka5RiblKL1EKaZQrts/Uq69DNsui8fKqb/J7WRcFIwD1KWapiKxB9rKssh0JgHUahLdPDQj43beACdkyzCT1JejrP0IH1FlMY9dCdutntQkmt2ZCKlRlQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB4366.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(136003)(39860400002)(376002)(33656002)(2906002)(316002)(7696005)(86362001)(110136005)(53546011)(9686003)(6506007)(5660300002)(8676002)(52536014)(66946007)(66476007)(64756008)(76116006)(66556008)(66446008)(478600001)(8936002)(83380400001)(26005)(71200400001)(186003)(55016002)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: yvdXJEl3dDHIPnO6gHRhM6Co1oV9Y0usc5wZ7xo4D9JKN/zy+poY9uBMaCsRVhnJJVQ2Tt40q0WzTnosliVHs8hGsQYCD5+QMzRZ6mSA/Fs1yJtX8nDQOsbGh8tAvgCgYNtzbqem+cfkoyQ3NT2JeOlN0GWgZl2/sfG+wuZg6r7Zk2UmHGDpMGjf9nZ9hYOe4dCNt1nqZUsh+Rsi/uZGdYzDxAI5X8oJb3EghBStgjgKcczFd6I1Xjo5ImnhFvmFMiskW2pIwhJQWO0psbfzGimjrT6YuvZvnzXJl+NPOU6n11N6Nqk2k5ZvIJPeidRPnL2z8H/S+dt4bN+b9405W8iPQuLuVSHzJcN0w5HJTobcTJq4Jm7rN6Imqwp20UzcrTDaDmArJWddPIabFI0mOiZ9DNHhRGYPh+eKOt1Bro0C6HSHIIcu12iy4R+nkNfwzGIuUiSyJoXgfsogn6ilfsdJbCwqL9Uy4/IqpgAxVOD7DvJhYDqOvhTeGDV5YMEudOJh1TR1etP8Z/bTT+I6QY+oKlh4J+Y6VxO0iyL+n7aqBYj2zC45jR8gHO4PHGuZ6H65pha2NAAJHrkSz9udjzLAei9VOYvG5YVMi1fzPa50gJ5gcGEcCzUpmxYPtVJ9gfPuCVVB4jzi8OayIvGe9A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR11MB4366.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b3a02bab-1723-49de-d6f0-08d86b76877f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 10:40:09.2052 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: S5JAKlk3J2Oh66uyiPVt9omtMe38S77V9c4ZmkvbXbVX0ORGWJM0C/loUYVHWJK857LQlc+dPCER0F7KwMSeiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3059 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 10:40:16 -0000 SGkgTWljaGFlbCwgU3BlbmNlciwNCg0KU28sIHRoZSByZWFzb24gdGhhdCBJIGFza2VkIHRoZSBx dWVzdGlvbiBhcyB0byB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgd291bGQgZW5kIHVwIGhpc3Rvcmlj YWwgd2FzIHRvIHRyeSBhbmQgZ2F1Z2UgaG93IGltcG9ydGFudCBpdCBpcyBmb3IgdGhpcyBzcGVj aWZpY2F0aW9uIHRvIGJlIGdlbmVyYWxseSBpbXBsZW1lbnRhYmxlLg0KDQpQZXJzb25hbGx5LCBJ IHdvdWxkIGZpbmQgdGhpcyBzcGVjaWZpY2F0aW9uIHZlcnkgaGFyZCB0byBpbXBsZW1lbnQgY29y cmVjdGx5IGluIGFuIGludGVyb3BlcmFibGUgd2F5LiAgSG93ZXZlciwgSSBkb24ndCBoYXZlIGFu eSBleHBlcnRpc2UgaW4gdmlkZW8gY29kZWNzLCBhbmQgaWYgSSBkaWQgdGhlbiBwZXJoYXBzIHRo aXMgc3BlY2lmaWNhdGlvbiB3b3VsZCBiZSBzdWZmaWNpZW50LCBpdCBpcyBoYXJkIHRvIGp1ZGdl LiAgSG93ZXZlciwgaWYgdGhpcyBkb2N1bWVudCBpcyBwcmltYXJpbHkgaW50ZW5kZWQgdG8gYWN0 IGFzIGEgaGlzdG9yaWNhbCByZWNvcmQgZm9yIGV4aXN0aW5nIEZGVjEgaW1wbGVtZW50YXRpb25z LCB3aXRoIHRoZSBtYWluIGZvY3VzIGJlaW5nIG9uIGEgc3RhbmRhcmRzIHRyYWNrIEZGVjEgdmVy c2lvbiA0LCB0aGVuIHRoZSBmYWN0IHRoYXQgcGFydHMgb2YgdGhpcyBkb2N1bWVudCBhcmUgYSBi aXQgb3BhcXVlIG1heSBub3QgcmVhbGx5IGJlIGltcG9ydGFudCBpbiB0aGUgbG9uZ2VyIHRlcm0s IHBhcnRpY3VsYXJseSBpZiB0aGUgRkZWMSB2NCBzcGVjaWZpY2F0aW9uIGlzIG1vcmUgYWNjZXNz aWJsZS4NCg0KSG9wZWZ1bGx5IHRoYXQgY2xhcmlmaWVzIHRoZSBwdXJwb3NlIG9mIG15IHF1ZXN0 aW9uLg0KDQpSZWdhcmRzLA0KUm9iDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBpZXNnIDxpZXNnLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBNaWNoYWVs IFJpY2hhcmRzb24NCj4gU2VudDogMDcgT2N0b2JlciAyMDIwIDE5OjQwDQo+IFRvOiBSb2IgV2ls dG9uIChyd2lsdG9uKSA8cndpbHRvbkBjaXNjby5jb20+OyBUaGUgSUVTRyA8aWVzZ0BpZXRmLm9y Zz47DQo+IGRyYWZ0LWlldGYtY2VsbGFyLWZmdjFAaWV0Zi5vcmc7IGNlbGxhci1jaGFpcnNAaWV0 Zi5vcmc7IENvZGVjIEVuY29kaW5nDQo+IGZvciBMb3NzTGVzcyBBcmNoaXZpbmcgYW5kIFJlYWx0 aW1lIHRyYW5zbWlzc2lvbiA8Y2VsbGFyQGlldGYub3JnPjsgUGV0ZXINCj4gQi4gPHBiQGRhcy13 ZXJrc3RhdHQuY29tPg0KPiBTdWJqZWN0OiBSZTogUm9iZXJ0IFdpbHRvbidzIE5vIE9iamVjdGlv biBvbiBkcmFmdC1pZXRmLWNlbGxhci1mZnYxLTE3Og0KPiAod2l0aCBDT01NRU5UKQ0KPiANCj4g DQo+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIDxzcGVuY2VyZGF3a2lucy5pZXRmQGdtYWlsLmNv bT4gd3JvdGU6DQo+ICAgICA+IFF1ZXN0aW9ucyBvZiB3aGF0J3Mgb2Jzb2xldGVkLCBvciBkZWNs YXJlZCBIaXN0b3JpYywgb3Igb3RoZXJ3aXNlDQo+IGRvbmUNCj4gICAgID4gdG8gRkZWMSB2ZXJz aW9uIDAsIDEgYW5kIDMsIHdvdWxkIGJlIGRlY2lkZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsDQo+ IEFELA0KPiAgICAgPiBhbmQgSUVTRyB3aGVuIEZGVjEgdmVyc2lvbiA0IGlzIGluIElFU0cgRXZh bHVhdGlvbiwgSSB0aGluaz8NCj4gDQo+IEkgdW5kZXJzdG9vZCB0aGF0IEZGVjEgdmVyc2lvbiAw LzEvMyB3YXMgSW5mb3JtYXRpb25hbC4NCj4gSSBndWVzcyBpdCBjb3VsZCBiZSBtYXJrZWQgSGlz dG9yaWMgYnkgdGhlIElFU0cgYXQgc29tZSBwb2ludC4NCj4gSSBkaWRuJ3QgdGhpbmsgdGhhdCB0 aW1lIHdvdWxkIGJlIHdoZW4gRkZWMSB2NCB3YXMgcHVibGlzaGVkLCBidXQgc3VyZS4NCj4gDQo+ IEkgdGhvdWdodCB0aGF0IHRoaXMgd2FzIGV2ZW4gaW4gb3VyIGNoYXJ0ZXIgc29tZXdoZXJlLCBz byBJJ20gY29uZnVzZWQgYnkNCj4gdGhpcyB0aHJlYWQuDQo+IA0KPiBUaGlzIGZvbGxvd3MgdGhl IHBhdHRlcm4gb2YgcHVibGlzaGluZyBhbiBSRkMgdGhhdCBpcyBub3Qgd2l0aGluIElFVEYNCj4g cmV2aXNpb24gY29udHJvbCB0aGF0IGRvY3VtZW50cyAiY3VycmVudCBwcmFjdGljZSIsIGFuZCB0 aGVuIHB1Ymxpc2hpbmcgYW4NCj4gUkZDIG9uIHN0YW5kYXJkcyB0cmFjaywgdGhhdCBpcyB3aXRo aW4gSUVURiByZXZpc2lvbiBjb250cm9sLg0KPiANCj4gSGVyZSAicmV2aXNpb24gY29udHJvbCIg bWVhbnMgd2UgY2FuIGNoYW5nZSB0aGUgYml0cy1pbi10aGUtd2lyZQ0KPiAob3IgaW4gdGhlIGZp bGUpIGluIGluY29tcGF0aWJsZSB3YXlzLg0KPiANCj4gDQo+IC0tDQo+IE1pY2hhZWwgUmljaGFy ZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiAgIC4gbyBPICggSVB2NiBJw7hUIGNvbnN1bHRp bmcgKQ0KPiAgICAgICAgICAgIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3JrcyBJbmMsIE90dGF3YSBh bmQgV29ybGR3aWRlDQo+IA0KPiANCj4gDQoNCg== From nobody Thu Oct 8 03:51:49 2020 Return-Path: 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 3D3763A0400 for ; Thu, 8 Oct 2020 03:51:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.11 X-Spam-Level: X-Spam-Status: No, score=-2.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 NJl6WfuVkiH7 for ; Thu, 8 Oct 2020 03:51:46 -0700 (PDT) Received: from 17.mo1.mail-out.ovh.net (17.mo1.mail-out.ovh.net [87.98.179.142]) (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 695DD3A02BB for ; Thu, 8 Oct 2020 03:51:46 -0700 (PDT) Received: from player718.ha.ovh.net (unknown [10.109.143.216]) by mo1.mail-out.ovh.net (Postfix) with ESMTP id 4E2411D901F for ; Thu, 8 Oct 2020 12:51:44 +0200 (CEST) Received: from mediaarea.net (p548f938d.dip0.t-ipconnect.de [84.143.147.141]) (Authenticated sender: jerome@mediaarea.net) by player718.ha.ovh.net (Postfix) with ESMTPSA id 1054816DAA1B3; Thu, 8 Oct 2020 10:51:37 +0000 (UTC) Authentication-Results: garm.ovh; auth=pass (GARM-105G006c7c73a4d-8ca4-4575-8148-f25c290d4099, 24DC83216394C896C66FF9538730B18FFE9C3246) smtp.auth=jerome@mediaarea.net To: "Rob Wilton (rwilton)" , Michael Richardson , The IESG , "draft-ietf-cellar-ffv1@ietf.org" , "cellar-chairs@ietf.org" , Codec Encoding for LossLess Archiving and Realtime transmission , "Peter B." References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> <18667.1602095984@localhost> From: Jerome Martinez Message-ID: <2258f8f9-db99-998b-e816-24af571641d8@mediaarea.net> Date: Thu, 8 Oct 2020 12:51:37 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Ovh-Tracer-Id: 17239779376920924269 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedrgeelgddtiecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefuvfhfhffkffgfgggjtgfgsehtkeertddtfeejnecuhfhrohhmpeflvghrohhmvgcuofgrrhhtihhnvgiiuceojhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtqeenucggtffrrghtthgvrhhnpeehveejvefgheevteefgeeuhfevveekteeuheeludejgeffgeefkeffkedvgfffteenucffohhmrghinhephihouhhtuhgsvgdrtghomhdpmhgvughirggrrhgvrgdrnhgvthdpghhithhhuhgsrdgtohhmnecukfhppedtrddtrddtrddtpdekgedrudegfedrudegjedrudegudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdqohhuthdphhgvlhhopehplhgrhigvrhejudekrdhhrgdrohhvhhdrnhgvthdpihhnvghtpedtrddtrddtrddtpdhmrghilhhfrhhomhepjhgvrhhomhgvsehmvgguihgrrghrvggrrdhnvghtpdhrtghpthhtoheptggvlhhlrghrsehivghtfhdrohhrgh Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 10:51:48 -0000 On 08/10/2020 12:40, Rob Wilton (rwilton) wrote: > Personally, I would find this specification very hard to implement correctly in an interoperable way. However, I don't have any expertise in video codecs, and if I did then perhaps this specification would be sufficient, it is hard to judge. There was a write from scratch of a decoder, based on this document. Presentation video: https://www.youtube.com/watch?v=4HB7v7dItWE Slides: https://mediaarea.net/Events/2019-12-05_NoTimeToWait4/13.%20Derek%20Buitenhuis%20-%20I%20Wrote%20an%20FFV1%20decoder%20in%20Go%20for%20Fun,%20What%20I%20learned%20going%20from%20Spec%20to%20Implementation/derek_nttw4_ffv1.pdf And this led to some issues publicly raised: https://github.com/FFmpeg/FFV1/issues?q=is%3Aissue+author%3Adwbuiten+created%3A2019 (and fixed) Jérôme From nobody Thu Oct 8 10:49:32 2020 Return-Path: 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 35D523A0B91; Thu, 8 Oct 2020 10:49:26 -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 xS7qbosfU4jR; Thu, 8 Oct 2020 10:49:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46AC83A0B90; Thu, 8 Oct 2020 10:49:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8FF5C389C2; Thu, 8 Oct 2020 13:54:50 -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 uxSk7sAFqJdU; Thu, 8 Oct 2020 13:54:49 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6F933389C0; Thu, 8 Oct 2020 13:54:49 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0761518B; Thu, 8 Oct 2020 13:49:22 -0400 (EDT) From: Michael Richardson To: "Rob Wilton \(rwilton\)" , The IESG , "draft-ietf-cellar-ffv1\@ietf.org" , "cellar-chairs\@ietf.org" , "Codec Encoding for LossLess Archiving and Realtime transmission" , "Peter B." In-Reply-To: References: <160190967658.31262.3611106747790904168@ietfa.amsl.com> <61aa6a30-a10a-0460-dbcb-aace9936a468@mediaarea.net> <18667.1602095984@localhost> 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 Archived-At: Subject: Re: [Cellar] Robert Wilton's No Objection on draft-ietf-cellar-ffv1-17: (with COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Oct 2020 17:49:26 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Rob Wilton (rwilton) wrote: > Personally, I would find this specification very hard to implement > correctly in an interoperable way. However, I don't have any experti= se > in video codecs, and if I did then perhaps this specification would be > sufficient, it is hard to judge. However, if this document is > primarily intended to act as a historical record for existing FFV1 > implementations, with the main focus being on a standards track FFV1 > version 4, then the fact that parts of this document are a bit opaque > may not really be important in the longer term, particularly if the > FFV1 v4 specification is more accessible. Ah, I understand you concern much better now. Given that there is significant content in this format which is being archived, one should assume that someone might want to write a new decoder = in some new language in 50 years. I think that FFV1 v4 builds upon the notation and concepts in v013, so I think that any clarifications or style changes that we can make on this pass will help when v4 comes forward. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl9/USEACgkQgItw+93Q 3WXmywf/ShVDY6N1H9O6MEaXUuZRN0mjJc16iEwGQ0qviKg8VX9LK6RCSRgI/Vn+ O2+02D8a8M+o2FFvnqJ3Rqz5UoMdsBa8NRll5jvfkbw3jGERDTTpOon1FO58wFAO +WmGSvk+JyhbGZsWuSdGFwxE9cF8yMlc2k8L/YwOl6YgGOFwMiIP1cm2Kn1wfLDj +GuSoRiv3Neo4j3QfHkMiVzKeDUv8P90a2kOaCvgvp+0ONWCm/HkU2bW2Na+BghM ZHJh3gg8zx+lCcZ4jWJEFnfZ3aZZ5pq9qJsRpQqxz/rMofd7iAlDsieRvUQGnT3W wdZVrBaPMxmB0eDAtqCGZAFCbpEniw== =TfNn -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 11 00:40:57 2020 Return-Path: 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 74C113A0F67 for ; Sun, 11 Oct 2020 00:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ZlkUUktS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UxynlaeC 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 QsbS7FbILPzd for ; Sun, 11 Oct 2020 00:40:53 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EFAA3A0F61 for ; Sun, 11 Oct 2020 00:40:53 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 982935C00C9 for ; Sun, 11 Oct 2020 03:33:06 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 11 Oct 2020 03:33:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm3; bh=GyL6JgRMextDQxr4tPVQAkuDtbFg6LZ3YBUl2x0AKQI=; b=ZlkUUktS d2/nah6gRf20bed8qivCkCl8qDAMkleJP1FhO/ki9NNPjilalkI1AFsJP9Ii3U5+ A262wGH73H6txJ6RpvGMhKrjfun8MIZcUEHpWf2f6WG4tBEOqSPUWXeXOT7u2Icy 14gBb3grHa88NXp8xlAwPINs0I2u5/pvGcxDRuOdi3xMc2wnxLPUi8b0LztpHlI1 Tffp6Y3DfUb8Vj64TqAWUcWiSFW8CYLjqRY3UzvvpiM/F8WeJfnrUjHRMz3Nj9JH t55OXTxi2HafNwPViOvGw3In9n95r+CZfZnBbVyuHEL9ijocXkqmadThs5ZI1hBV 6PsZBanIXsbFcw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=GyL6JgRMextDQxr4tPVQAkuDtbFg6 LZ3YBUl2x0AKQI=; b=UxynlaeCrBa8iU8dY5UgauZ/5AGg9clJO5/WuA1eyuBjl HY9HO2VkLfkJAsEdQFLnWhhSfnus2zU7LdT4uzWLj4mNERGoqt6EdxS3Ea06XUJq UOvw7RhZvvoPHmFDxuce/HsWdMFDH88mxaUY+C8/rjHLMXtGnw1sUg4jx0/aQ5/W RSK/jRkSNVctlYACHN9QK9VP1/BlcXxDn6qjc8FmWuglQBE4SxbtP2YC7EVRtxgg XszyksFhGKPR3afgV0yQ/AdbXackF+LY9ktsf8eaUeoFqloUNwDVcR95tfd9rP7k MlSJIiYHULHb80QzAmsFs6bcmdvdOIODTDFKGly2g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrheeggddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddugeeirdefjedrud ehjeenucevlhhushhtvghrufhiiigvpeefnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az54.internal.cloudapp.net (unknown [52.146.37.157]) by mail.messagingengine.com (Postfix) with ESMTPA id 5E3ED306467D for ; Sun, 11 Oct 2020 03:33:06 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============7676069870660299545==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201011073306.5E3ED306467D@mailuser.nyi.internal> Date: Sun, 11 Oct 2020 03:33:06 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Oct 2020 07:40:56 -0000 --===============7676069870660299545== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #422 Consider providing a facility for integer-fraction timescales (1 b= y robUx4) https://github.com/cellar-wg/matroska-specification/issues/422=20 * FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC2) 2 issues received 2 new comments: - #231 section 3.8.1.1 should have pseudocode (1 by dwbuiten) https://github.com/FFmpeg/FFV1/issues/231=20 - #230 section 3.8.1.2 needs to define get_rac (1 by dericed) https://github.com/FFmpeg/FFV1/issues/230=20 Pull requests ------------- * FFmpeg/FFV1 (+8/-4/=F0=9F=92=AC8) 8 pull requests submitted: - [WIP] Ballot Roman, security part (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/249=20 - Ballot Roman (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/248=20 - Ballot robert (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/247=20 - bump to ffv1 18 and ffv1 v4 15 (by dericed) https://github.com/FFmpeg/FFV1/pull/246=20 - cross-references for get_rac (by dericed) https://github.com/FFmpeg/FFV1/pull/245=20 - correct the name of an author (by dericed) https://github.com/FFmpeg/FFV1/pull/244=20 - Ballot Eric (by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/243=20 - Add pseudocode exmaples for Range Binary Values (by dwbuiten) https://github.com/FFmpeg/FFV1/pull/242=20 4 pull requests received 8 new comments: - #247 Ballot Robert (2 by JeromeMartinez) https://github.com/FFmpeg/FFV1/pull/247=20 - #246 bump to ffv1 18 and ffv1 v4 15 (1 by dericed) https://github.com/FFmpeg/FFV1/pull/246=20 - #245 cross-references for get_rac (1 by dericed) https://github.com/FFmpeg/FFV1/pull/245=20 - #241 Ballot Barry part 2 (4 by JeromeMartinez, dericed, dwbuiten) https://github.com/FFmpeg/FFV1/pull/241=20 4 pull requests merged: - Ballot Roman https://github.com/FFmpeg/FFV1/pull/248=20 - Ballot Barry part 2 https://github.com/FFmpeg/FFV1/pull/241=20 - Ballot Eric https://github.com/FFmpeg/FFV1/pull/243=20 - Remove quotes from defined words=20 https://github.com/FFmpeg/FFV1/pull/239=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/ebml-specification * https://github.com/cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/cellar-wg/Cellar-FLAC * https://github.com/cellar-wg/chair-notes --===============7676069870660299545== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday October 11, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

FFmpeg/FFV1 (+0/-0/=F0=9F=92=AC2)

2 issues received 2 new comments:

Pull requests

FFmpeg/FFV1 (+8/-4/=F0=9F=92=AC8)

8 pull requests submitted:

4 pull requests received 8 new comments:

4 pull requests merged:

Repositories tracked by this digest:

--===============7676069870660299545==-- From nobody Sun Oct 18 00:51:24 2020 Return-Path: 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 33ADC3A1529 for ; Sun, 18 Oct 2020 00:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=LhP90rIT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Idz+pHrO 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 byEhHA_CXGIy for ; Sun, 18 Oct 2020 00:51:20 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F1C93A1528 for ; Sun, 18 Oct 2020 00:51:20 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id B81214E4 for ; Sun, 18 Oct 2020 03:33:49 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 18 Oct 2020 03:33:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=4gW/AL1awJ54L0TcCX1LAlVCFO3qr4VrI33yHZS9Iqw=; b=LhP90rIT wt8odmExNYMxmIgp1zaKiFrPmfz9eLa/p6yqPcs2kyQUeGzQ93usfkS1CnkqQ8Px D0jLzHe6XXTBY94f/wcYycZksWS8Crt8mI3/vDlMqcc68A/Nx48D4MeEgP+7FhDb sdQyV23MMYtOwSBr9Uh5x+5XPKUA7A4MQMeVNkqZtQgVRC+v1kqLzKSzTGv4Ys6g ZzGsiOj1hdeqiyrweXu8c9EuXz1PxqAMqlfdrtK6TOxOdoV+3kkfYXetmfg3cW4b GyHCUxVZBfwIhRYBv8e3eCIsPtXjvAKXwiEZmUP69zJZaPhGxBGwMpx7qKPlIH4/ rHIn68KZb6BX2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=4gW/AL1awJ54L0TcCX1LAlVCFO3qr 4VrI33yHZS9Iqw=; b=Idz+pHrOSxNdJA6/quwFGqwWkKU4Tn6DluOiHkY/hy53Q WmZGfHOWdBG0WJcCGZWgIKwEKhy2ullNaTI91CPSPhxVfQwSyYdwoXY/2IZmm68x tUsncgN0DYWCQrbi39SXGwM5R0wP4/x9suGlXr2zVJsj1HsJAjOqKYQjdmObC/eu trIlFA8d8N5l+v279NnZ7LVX+x6fVlYMuAu7QNVaxqhMvsFYjU6mHCIdjUhy1ksQ DNXA9YD0s1hPZaWvqblE5CAIMK70BOtPVWaLfhsoH1UOCRYPNDTV55p8LQwYibs8 bbSXNUcxVSAOw6wTMvM6hfhUulup9w36+0SnBPJHQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrieekgdduvddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphephedvrddvheehrddugedtrd dukedvnecuvehluhhsthgvrhfuihiivgepfeenucfrrghrrghmpehmrghilhhfrhhomhep ughopghnohhtpghrvghplhihsehmnhhothdrnhgvth X-ME-Proxy: Received: from fv-az54.internal.cloudapp.net (unknown [52.255.140.182]) by mail.messagingengine.com (Postfix) with ESMTPA id 2B1603064674 for ; Sun, 18 Oct 2020 03:33:49 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============3138380439117781751==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201018073349.2B1603064674@mailuser.nyi.internal> Date: Sun, 18 Oct 2020 03:33:49 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 07:51:22 -0000 --===============3138380439117781751== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC1) 1 issues received 1 new comments: - #164 Add a Rational Number type (1 by robUx4) https://github.com/cellar-wg/ebml-specification/issues/164 [format addi= tion]=20 * cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC3) 2 issues received 3 new comments: - #422 Consider providing a facility for integer-fraction timescales (2 b= y robUx4) https://github.com/cellar-wg/matroska-specification/issues/422 [clarifi= cations] [format addition]=20 - #306 Move the WebM flag in a separate document (1 by robUx4) https://github.com/cellar-wg/matroska-specification/issues/306 [enhance= ment] [formatting] [webm]=20 1 issues closed: - Move the WebM flag in a separate document https://github.com/cellar-wg/= matroska-specification/issues/306 [enhancement] [formatting] [webm]=20 Pull requests ------------- * cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC1) 1 pull requests submitted: - Proposal to add some rational number in timestamps (by robUx4) https://github.com/cellar-wg/matroska-specification/pull/425 [format ad= dition]=20 1 pull requests received 1 new comments: - #425 Proposal to add some rational number in timestamps (1 by robUx4) https://github.com/cellar-wg/matroska-specification/pull/425 [format ad= dition]=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/ebml-specification * https://github.com/cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/cellar-wg/Cellar-FLAC * https://github.com/cellar-wg/chair-notes --===============3138380439117781751== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday October 18, 2020

Events without label "editorial"

Issues

cellar-wg/ebml-specification (+0/-0/=F0=9F=92=AC1)

1 issues received 1 new comments:

cellar-wg/matroska-specification (+0/-1/=F0=9F=92=AC3)

2 issues received 3 new comments:

1 issues closed:

Pull requests

cellar-wg/matroska-specification (+1/-0/=F0=9F=92=AC1)

1 pull requests submitted:

1 pull requests received 1 new comments:

--===============3138380439117781751==-- From nobody Mon Oct 19 06:03:30 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6FD3A0820; Mon, 19 Oct 2020 06:03:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160311260801.7734.11951091533984748557@ietfa.amsl.com> Date: Mon, 19 Oct 2020 06:03:28 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-matroska-06.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 13:03:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Matroska Media Container Format Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-matroska-06.txt Pages : 171 Date : 2020-10-19 Abstract: This document defines the Matroska audiovisual container, including definitions of its structural elements, as well as its terminology, vocabulary, and application. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-matroska/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-cellar-matroska-06.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-matroska-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 06:03:39 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5243A0838; Mon, 19 Oct 2020 06:03:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160311260860.10011.15001104956558840768@ietfa.amsl.com> Date: Mon, 19 Oct 2020 06:03:28 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-codec-05.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 13:03:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Matroska Media Container Codec Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-codec-05.txt Pages : 53 Date : 2020-10-19 Abstract: This document defines the Matroska codec mappings, including the codec ID, layout of data in a "Block Element" and in an optional "CodecPrivate Element". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-codec/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-cellar-codec-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-codec-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 19 06:03:52 2020 Return-Path: X-Original-To: cellar@ietf.org Delivered-To: cellar@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0786B3A0A24; Mon, 19 Oct 2020 06:03:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cellar@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.20.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: cellar@ietf.org Message-ID: <160311261599.321.641251584874158961@ietfa.amsl.com> Date: Mon, 19 Oct 2020 06:03:36 -0700 Archived-At: Subject: [Cellar] I-D Action: draft-ietf-cellar-tags-05.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 13:03:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Codec Encoding for LossLess Archiving and Realtime transmission WG of the IETF. Title : Matroska Media Container Tag Specifications Authors : Steve Lhomme Moritz Bunkus Dave Rice Filename : draft-ietf-cellar-tags-05.txt Pages : 17 Date : 2020-10-19 Abstract: This document defines the Matroska tags, namely the tag names and their respective semantic meaning. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cellar-tags/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-cellar-tags-05.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-tags-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 21 11:03:52 2020 Return-Path: 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 DF1CE3A13F7; Wed, 21 Oct 2020 11:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 195PLzOTeTpO; Wed, 21 Oct 2020 11:03:49 -0700 (PDT) Received: from mail-yb1-xb2f.google.com (mail-yb1-xb2f.google.com [IPv6:2607:f8b0:4864:20::b2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2FAE3A13F5; Wed, 21 Oct 2020 11:03:48 -0700 (PDT) Received: by mail-yb1-xb2f.google.com with SMTP id l15so2555219ybp.2; Wed, 21 Oct 2020 11:03:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sbhh6yZrKCguiHgMmiAZH+PhzRt2/VLghm2yQouU5yw=; b=CeIFtsmg4+o+Z6OAUAzVB9GcgQTRWyOiUg+S9rVdYJX2wZ7dItPwMajf1AM88SqJnK vudUaEGw+cM6q4xRlobRzflb6h+5jJr5UDgul+7+bNso3CvpbEo4qlEkZxsEaQBIltZK r73oHC5962ALoXrg6Mf024K6nv63oaAHqCh/onvSzuyFP7GDkdB+IltVvUnv55d5xUiT bFBMvedkfOtaxqSwB4WIXq9Qt8bhQEYoC3D6yuLx05IjB/KMOQ7jzHy9JEq+qvmPeJPG xYPGep+lnjXKXzS76Bmlihs9IpAr2JLTQwx/K8Iwl0C+AjwUz4wHAfM9+ZQv4V3xmp+v 00lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sbhh6yZrKCguiHgMmiAZH+PhzRt2/VLghm2yQouU5yw=; b=rE3kAVMru3gq8P9XzCqJnGAwk4KMMshOsc8zc3asZr11cT9lmx8KdSXeg7QY+wawtz f68fScRbgsBQMsgnn/gSX51yOV0UqbvE4mtKihSFhzjROTFrB0WMDkoxoIITvcY6ilYB JURT1JRCJPbBme9jDKahlDcjFOblQoH7gZXZt+rKwzh1SF7m+iqKgLu/WMKfqEskA1Si 2WNuwEE80fb93tLIdEIMHDjbA/vT9OJ8iEnuMj2Pg8KhbBnHniO3jRLzt+dHBfPtsQHV 1xaPbiR+lVXtjL4tcQPLuxkhZL6IEcBGyvmGCrkiTFc0rSeNppbrH90uASKE3nqtLqAQ c8jQ== X-Gm-Message-State: AOAM533/ehHn5VbqbNKW74fzI4vifPKNLOgH0BI0bOzGOzOP8TZn6cv9 nolaL8by6ofQ+ufzvAeZsvZpDBjhrOIeM+N2CS4= X-Google-Smtp-Source: ABdhPJzIh0Zxyfjfnqi3+MPmCjOqq1vjrs6rjWDYndQtiiMs+VrpwalqBbDqsChWLjkxoi3Op48I/CN/gLw1qOoRd8A= X-Received: by 2002:a25:cc89:: with SMTP id l131mr6337422ybf.154.1603303427763; Wed, 21 Oct 2020 11:03:47 -0700 (PDT) MIME-Version: 1.0 References: <160208949226.20172.3161875416157552929@ietfa.amsl.com> In-Reply-To: From: Spencer Dawkins at IETF Date: Wed, 21 Oct 2020 13:03:21 -0500 Message-ID: To: Roman Danyliw Cc: "draft-ietf-cellar-ffv1@ietf.org" , "draft-ietf-cellar-ffv1.chairs@ietf.org" , Barry Leiba , Codec Encoding for LossLess Archiving and Realtime transmission Content-Type: multipart/alternative; boundary="0000000000004771df05b2322bb2" Archived-At: Subject: Re: [Cellar] FW: New Version Notification - draft-ietf-cellar-ffv1-18.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 18:03:51 -0000 --0000000000004771df05b2322bb2 Content-Type: text/plain; charset="UTF-8" Hi, Roman, On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw wrote: > Hi! > (I can't find your response email to my ballot in my mail client despite > it being in the archive, so apologizes for making the new thread). > > Thanks for the -18 which cleared most of the COMMENTs. I updated my > ballot. > > In the spirit of clearing what I consider a straightforward DISCUSS, might > I suggest: > > OLD > > Implementations of the FFV1 codec need to take appropriate security > considerations into account, as outlined in [RFC4732]. It is > extremely important for the decoder to be robust against malicious > payloads. Malicious payloads MUST NOT cause the decoder to overrun > its allocated memory or to take an excessive amount of resources to > decode. The same applies to the encoder, ... > > NEW > > Implementations of the FFV1 codec need to take appropriate security > considerations into account. Those related to denial of service are > outlined in Section 2.1 of [RFC4732]. It is extremely important for the > decoder to be robust against malicious payloads. Malicious payloads MUST > NOT cause the decoder to overrun its allocated memory or to take an > excessive amount of resources to decode. An overrun in allocated memory > could lead to arbitrary code execution by an attacker. The same applies to > the encoder, ... > > Regards, > Roman > Thanks for this! and I am including the working group in my reply, so everyone will see it. Best, Spencer > > -----Original Message----- > From: internet-drafts@ietf.org > Sent: Wednesday, October 7, 2020 12:52 PM > To: Michael Richardson ; superuser@gmail.com; > barryleiba@computer.org; Roman Danyliw ; Peter B. < > pb@das-werkstatt.com> > Subject: New Version Notification - draft-ietf-cellar-ffv1-18.txt > > > A new version (-18) has been submitted for draft-ietf-cellar-ffv1: > https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.txt > https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html > > > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ > > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=draft-ietf-cellar-ffv1-18 > > Please note that it may take a couple of minutes from the time of > submission until the diff is available at tools.ietf.org. > > IETF Secretariat. > > > --0000000000004771df05b2322bb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Roman,

On Wed, Oct 21, 2020 at 12:38 P= M Roman Danyliw <rdd@cert.org> wr= ote:
Hi!
(I can't find your response email to my ballot in my mail client despit= e it being in the archive, so apologizes for making the new thread).

Thanks for the -18 which cleared most of the COMMENTs.=C2=A0 I updated my b= allot.

In the spirit of clearing what I consider a straightforward DISCUSS, might = I suggest:

OLD

=C2=A0 Implementations of the FFV1 codec need to take appropriate security<= br> =C2=A0 =C2=A0considerations into account, as outlined in [RFC4732].=C2=A0 I= t is
=C2=A0 =C2=A0extremely important for the decoder to be robust against malic= ious
=C2=A0 =C2=A0payloads.=C2=A0 Malicious payloads MUST NOT cause the decoder = to overrun
=C2=A0 =C2=A0its allocated memory or to take an excessive amount of resourc= es to
=C2=A0 =C2=A0decode.=C2=A0 The same applies to the encoder, ...

NEW

Implementations of the FFV1 codec need to take appropriate security conside= rations into account.=C2=A0 Those related to denial of service are outlined= in Section 2.1 of [RFC4732].=C2=A0 It is extremely important for the decod= er to be robust against malicious payloads.=C2=A0 Malicious payloads MUST N= OT cause the decoder to overrun its allocated memory or to take an excessiv= e amount of resources to decode.=C2=A0 =C2=A0 An overrun in allocated memor= y could lead to arbitrary code execution by an attacker.=C2=A0 The same app= lies to the encoder, ...

Regards,
Roman

Thanks for this! and I am includi= ng the working group in my reply, so everyone will see it.

Best,

Spencer
=C2=A0

-----Original Message-----
From: interne= t-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Wednesday, October 7, 2020 12:52 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>; superuser@gmail.com; barryleiba@computer.org; Roman Dan= yliw <rdd@cert.org= >; Peter B. <pb@das-werkstatt.com>
Subject: New Version Notification - draft-ietf-cellar-ffv1-18.txt


A new version (-18) has been submitted for draft-ietf-cellar-ffv1:
https://www.ietf.org/id/draft-ietf-cellar-ffv1-= 18.txt
https://www.ietf.org/id/draft-ietf-cellar-ffv1= -18.html


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-= cellar-ffv1/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=3Ddra= ft-ietf-cellar-ffv1-18

Please note that it may take a couple of minutes from the time of submissio= n until the diff is available at tools.ietf.org.

IETF Secretariat.


--0000000000004771df05b2322bb2-- From nobody Fri Oct 23 07:26:24 2020 Return-Path: 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 EBE043A0EA7 for ; Fri, 23 Oct 2020 07:26:22 -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 bHIrfiiHMnCz for ; Fri, 23 Oct 2020 07:26:21 -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 CED0E3A0BEE for ; Fri, 23 Oct 2020 07:26:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 431C338996 for ; Fri, 23 Oct 2020 10:32:42 -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 NVxwcC1vcEfe for ; Fri, 23 Oct 2020 10:32:41 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6567A38995 for ; Fri, 23 Oct 2020 10:32:41 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 086FC61B for ; Fri, 23 Oct 2020 10:26:18 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr 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 Archived-At: Subject: [Cellar] 2020-10-27 virtual interim -- DRAFT agenda X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 14:26:23 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable CELLAR -- DRAFT AGENDA for Virtual Interim Meeting October 27, 2020 21:00 Amsterdam *** 20:00 UTC 16:00 NYC 13:00 San Francisco (Europe has changed clocks, North America has not. Time is anchored to Amst= erdam) INFO: https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-08-cellar-02/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from September 22 meeting (attached below) 3. Logistics for Meeting. 3a) Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-virtual <- New as of this meet= ing. 3b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 3c) Roll call 4. WG status update * some documents expired: ** I-D was expired :draft-ietf-cellar-matroska-05.txt ** I-D was expired :draft-ietf-cellar-codec-04.txt ** I-D was expired :draft-ietf-cellar-tags-04.txt * FFV1 -- version 18 was posted 2020-10-07, waiting for revision 5. remaining FFV1 issues from DISCUSS * ?? 6. Matroska issues 8. FLAC issues AOB? NEXT MEETING October 27, 2020. NOTES from previous meeting CELLAR -- DRAFT AGENDA for Virtual Interim Meeting September 22, 2020 21:00 Amsterdam *** 19:00 UTC 15:00 NYC 12:00 San Francisco INFO: https://datatracker.ietf.org/doc/agenda-interim-2020-cellar-09-cellar-02/ WEB CONFERENCE: https://whereby.com/cellar-interim THERE IS NO TELEPHONE DIALIN (You can try this at any time.) These notes at: https://github.com/cellar-wg/chair-notes 1. Note Well. https://www.ietf.org/about/note-well/ 2. Accept draft minutes from April 28 meeting (attached below) 3. Logistics for Meeting. 3a) Shared COMIMD for notetaking: https://codimd.ietf.org/notes-cellar-v= irtual <- New as of this meeting. 3b) APPEAR.IN is now called "whereby.com" https://whereby.com/cellar-interim 3c) Roll call 4. WG status update * EBML -- * FFV1 -- version 17 was posted 2020-08-21, now in IESG Evaluation ballots are at https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1= /ballot/ *** Likely to be moved one or two telechats into the future after Barry = Leiba Discuss ballot with comments *** 5. Confirm no action required on https://datatracker.ietf.org/doc/rfc8794/ = HTML5.2 reference 6. EBML PRs 7. Matroska issues 8. FLAC issues AOB? NEXT MEETING October 27, 2020. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+S6AkACgkQgItw+93Q 3WU+rQgAwQIwu2QJ7SBXAdfndoZwFhUUREw4AJUY99bGA25U0IoECUnE0S+lXGnJ IiwSnYhGTLv4CUrNGSHZ9J2wH3svPdyuRxImUcTrtCNaBLC30oEkMjcCRl744SDb wLdCNRqBrbendocCKrhKK5wvKV1Fat4RZvlJiknQSyS9eUecLIiw8/FijzBY4WBu DPqUOuAmu+XqK9O+3T/0+TsqVjiQDz1tW4zBoliC3YvQlkBElDarmYZGiqX834Ts TdSAsy115eDjJXjNYa74z97x0Dy0r1XXZdqwXvykzxKw/RgDkHQZKaykH0gkZqTc ZBNyrQE/7iChmSPdcOyLc3d1QuJ2EA== =ZOVf -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 25 00:41:01 2020 Return-Path: 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 4717F3A1479 for ; Sun, 25 Oct 2020 00:41:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=GubseZ91; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Twg1yyPp 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 DwGK8VNZleas for ; Sun, 25 Oct 2020 00:40:58 -0700 (PDT) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 835D33A1477 for ; Sun, 25 Oct 2020 00:40:58 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0746B788 for ; Sun, 25 Oct 2020 03:35:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 25 Oct 2020 03:35:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject:message-id:date; s= fm1; bh=nIz8eClSyMs2gQawvEi4boIxjgeJuIzA31R9qBG4ym4=; b=GubseZ91 C4nW+Qvp9UGnG/Q22LW3zKuoYveirPfYxqyDEAf2uGnuKQgDLhdfgEZJ4tURgWhG +l9Es6YkvblBEjGFKETLdmmq84Mh3MaxLvdCqC7CwHXuDOQkhYOIJ8N7FNVk72fK Kaiejt0lCzeiGjxiUEkVt+o8Qf3k2fY1Wpp0UM3At1YJxwVD+2DCU1j4Nl8tyTqU WJ2ortpALhHMlJyslrLNGS9EJtD7RVyjij4SR/JAivEcIV+UQIFbVoiPuQVp3aqZ fWG8HGkEDplJ5qBC9/T8y45TltuKVB5HMXr2VqXGrBHQVn6WnNgMhj55ZF9F4Ega siV8B13A4DCsEw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:subject:to:x-me-proxy:x-me-proxy:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=nIz8eClSyMs2gQawvEi4boIxjgeJu IzA31R9qBG4ym4=; b=Twg1yyPpXH3TawtG+ybmVNZgh4c6uvReZBUEtcj3toV4u Npgg971ZiyirtM+NmvQ6jhuF8RR3dQvkbnelt3JxlCSTWTqvPq+Orn8pxCYgBOUJ RXIY9UcrZLbimc03ibs+mlwcTagHKwHcv9PtSd1kM8WVUDOUHyTi2GdV724jIYn4 IKuy2wTu+DVcvT+PII6202Xj6UPIFcDNRp/H2631Y4JDw64LO1BQmFqAj50AwXpQ hxxgAkgjOd9NRIiCdKzaFbgp4Rf1Jhrjlx7/jy8TZ34hSG5wyd98mbg7853qSIRR YL0iodIFDf/zXxh54ssHTyWi1FaqU7pH5s/lYsZMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrkeefgdduvddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfhvffusegrtddtredttdejne cuhfhrohhmpeftvghpohhsihhtohhrhicutegtthhivhhithihucfuuhhmmhgrrhihuceu ohhtuceoughopghnohhtpghrvghplhihsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepkeefvdduteejvdefkeehieevuefgfefhteetveegffekffefteffvdelheduieet necuffhomhgrihhnpehgihhthhhusgdrtghomhenucfkphepgedtrdejledrjeehrdegud enucevlhhushhtvghrufhiiigvpedvnecurfgrrhgrmhepmhgrihhlfhhrohhmpeguohgp nhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: from fv-az60.internal.cloudapp.net (unknown [40.79.75.41]) by mail.messagingengine.com (Postfix) with ESMTPA id 6C8713064610 for ; Sun, 25 Oct 2020 03:35:11 -0400 (EDT) Content-Type: multipart/alternative; boundary="===============5524627642815503015==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: cellar@ietf.org Message-Id: <20201025073511.6C8713064610@mailuser.nyi.internal> Date: Sun, 25 Oct 2020 03:35:11 -0400 (EDT) Archived-At: Subject: [Cellar] Weekly github digest (CELLAR Activity Summary) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Oct 2020 07:41:00 -0000 --===============5524627642815503015== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events without label "editorial" Issues ------ * cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC5) 1 issues received 5 new comments: - #422 Consider providing a facility for integer-fraction timescales (5 b= y robUx4) https://github.com/cellar-wg/matroska-specification/issues/422 [clarifi= cations] [format addition]=20 Pull requests ------------- * FFmpeg/FFV1 (+2/-0/=F0=9F=92=AC5) 2 pull requests submitted: - setting more captions in range coding description (by dericed) https://github.com/FFmpeg/FFV1/pull/251=20 - Ballot roman, security part, alt (by dericed) https://github.com/FFmpeg/FFV1/pull/250=20 2 pull requests received 5 new comments: - #250 Ballot roman, security part, alt (2 by dericed, mcr) https://github.com/FFmpeg/FFV1/pull/250=20 - #249 [WIP] Ballot Roman, security part (3 by JeromeMartinez, dericed, r= etokromer) https://github.com/FFmpeg/FFV1/pull/249=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/cellar-wg/ebml-specification * https://github.com/cellar-wg/matroska-specification * https://github.com/FFmpeg/FFV1 * https://github.com/cellar-wg/Cellar-FLAC * https://github.com/cellar-wg/chair-notes --===============5524627642815503015== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (CELLAR Activity Summary)

Sunday October 25, 2020

Events without label "editorial"

Issues

cellar-wg/matroska-specification (+0/-0/=F0=9F=92=AC5)

1 issues received 5 new comments:

Pull requests

FFmpeg/FFV1 (+2/-0/=F0=9F=92=AC5)

2 pull requests submitted:

2 pull requests received 5 new comments:

Repositories tracked by this digest:

--===============5524627642815503015==-- From nobody Tue Oct 27 09:25:50 2020 Return-Path: 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 3E8133A10CA for ; Tue, 27 Oct 2020 09:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, 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 VSA8jvbGhAMF for ; Tue, 27 Oct 2020 09:25:47 -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 889163A11D3 for ; Tue, 27 Oct 2020 09:25:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2289C389C9 for ; Tue, 27 Oct 2020 12:32:14 -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 WOcYzr-yAu4p for ; Tue, 27 Oct 2020 12:32:13 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CBF53389C8 for ; Tue, 27 Oct 2020 12:32:13 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 11EB518B for ; Tue, 27 Oct 2020 12:25:35 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org X-Attribution: mcr 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 Archived-At: Subject: [Cellar] reminder virtual interim meeting today - 2020-10-27 21:00 CEST X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2020 16:25:49 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Today's virtual meeting is at 21:00 CEST (Amsterdam/Berlin/Paris). That's not the same UTC time as previously. For us North Americans, who haven't changed our clocks yet, it's an hour later at 16:00 EDT rather than 15:00 EDT. >> CELLAR -- DRAFT AGENDA for Virtual Interim Meeting >> October 27, 2020 21:00 Amsterdam *** >> 20:00 UTC >> 16:00 NYC >> 13:00 San Francisco >> (Europe has changed clocks, North America has not. Time is anchored = to >> Amsterdam) =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+YSf4ACgkQgItw+93Q 3WUQTwgAqAnglBg8I7oFEohLLssQ55d4PwNr01CgpE9qFUV1X0Nef5y7KQ/h0GPm ifzaUIIiV6pEisggDzsa0TfZA8FGmeupJ0C9J43EsYeRDrU+NsURr+CJ6Dcd1YNs WBBGlyKlG0JRIwR9WufFwVbf8WkRokoMFAXeQfk4f9XPb9qQI8D0K47RKkoavSYg uVESWTYAR65DvPmSeRmy2N0B+k+zHWZ/i3c8yw8P6bnFr/UEQy10tdOhEvhUHwep pT4Ob14eO/5IQ1I69mbvfuIkWtk0vP2O1ccbGOZXJhT6DnYfrGhxRircxv1jkbNA Agz9P73Q+nP5T/+hx1GByjhsFpkbkQ== =OTL7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Oct 30 07:27:52 2020 Return-Path: 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 2BA573A0EE5 for ; Fri, 30 Oct 2020 07:27:50 -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 JetjFJ-RrghX for ; Fri, 30 Oct 2020 07:27:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE0A83A0EEB for ; Fri, 30 Oct 2020 07:27:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 3556D389BB for ; Fri, 30 Oct 2020 10:34:36 -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 DFBZUxzCmYIW for ; Fri, 30 Oct 2020 10:34:35 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A3F56389AC for ; Fri, 30 Oct 2020 10:34:35 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id DE8C2617 for ; Fri, 30 Oct 2020 10:27:45 -0400 (EDT) From: Michael Richardson To: cellar@ietf.org 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 Archived-At: Subject: [Cellar] Please fill out our survey on IETF authoring tools (fwd) IETF Executive Director: Please fill out our survey on IETF authoring tools X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 14:27:50 -0000 --=-=-= Content-Type: text/plain Your input would be appreciated. CELLAR has a different workflow than many others, so good to capture them. <#secure method=pgpmime mode=sign> --=-=-= Content-Type: message/rfc822 Content-Disposition: inline; filename=403 Content-Description: forwarded message Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3:216:3eff:fe7c:d1f3] by localhost with IMAP (fetchmail-6.4.0.beta4) for (single-drop); Fri, 30 Oct 2020 07:30:54 -0400 (EDT) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus git2.4.17+0-Debian-2.4.17+nocaldav-0+deb8u2) with LMTPA; Thu, 29 Oct 2020 21:21:47 -0400 X-Sieve: CMU Sieve 2.4 Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5860E389D9; Thu, 29 Oct 2020 21:21:47 -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 TYas4re1PY3R; Thu, 29 Oct 2020 21:21:45 -0400 (EDT) Received: from mail.ietf.org (mail.ietf.org [4.31.198.44]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 21F7E389D3; Thu, 29 Oct 2020 21:21:45 -0400 (EDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7403A0C12; Thu, 29 Oct 2020 18:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1604020495; bh=i9ZzKABuFE/bbe1VCwC2xsqkoCHLfCKJl12HVTckNaQ=; h=From:Subject:Date:To:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=WnhYV1PEnUR1gYmz4yP5gW5ozPOyuyXwuSZA7/vYnIhbvhH7XecoEBjlb6VTnUAE0 MGHqzhpjEZSrFTop70qYDo3SZNQmIFWl7A/mKGZgZTqxZ4/slGTlkPSpr7VWV5NWEa pgNL5rDINy0YgUgL0pGpX8v/Nt2Y5qowv6x/y7Ec= X-Mailbox-Line: From ietf-surveys-bounces@ietf.org Thu Oct 29 18:14:52 2020 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC1733A08DC; Thu, 29 Oct 2020 18:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1604020490; bh=i9ZzKABuFE/bbe1VCwC2xsqkoCHLfCKJl12HVTckNaQ=; h=From:Subject:Date:To:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=qOuXcxRigUVVhPOHyvldwYjduhUgYf1EIe+2kJXjwDwqcO9oaeQTnWOA1c8LdPP/r atCjNx91Xb4IRogU4L8lJs50sDLOKJIDrgNTJYmgqdqSwQnlmqUTlNAvVvYWoB5K4o 5ZZkMW91D1xQpn6QtF5/RlqB3dzRK0qiJBKihbyg= X-Original-To: ietf-surveys@ietfa.amsl.com Delivered-To: ietf-surveys@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8D23A0B16 for ; Thu, 29 Oct 2020 18:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 0nPj7g8B7szp for ; Thu, 29 Oct 2020 18:14:47 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 10F743A08DC for ; Thu, 29 Oct 2020 18:14:46 -0700 (PDT) From: IETF Executive Director Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\)) Subject: Please fill out our survey on IETF authoring tools Message-Id: Date: Fri, 30 Oct 2020 14:14:44 +1300 To: ietf-surveys@ietf.org X-Mailer: Apple Mail (2.3608.120.23.2.1) Archived-At: X-BeenThere: ietf-surveys@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ietf-surveys-bounces@ietf.org Sender: "Ietf-surveys" Hi=20 I am writing to ask you to fill out an IETF survey to help us understand = what tools and formats you use for authoring IETF Internet Drafts = (I-Ds), how you use them and what more you need from them. The data = from this survey is vital for our future planning of tools investment. Your email address has been selected because you have been listed as the = author or submitter of an I-D in the last five years. Please help us by taking a few minutes to fill out this survey, even if = you do not author I-Ds any more: https://ietf.iad1.qualtrics.com/jfe/form/SV_8d21RFqe5dBijOJ Thank you Jay --=20 Jay Daley IETF Executive Director exec-director@ietf.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable -- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-=-- From nobody Fri Oct 30 10:42:31 2020 Return-Path: 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 9A4BC3A1076; Fri, 30 Oct 2020 10:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 G0TYet9wB-1C; Fri, 30 Oct 2020 10:42:27 -0700 (PDT) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 A390B3A107C; Fri, 30 Oct 2020 10:42:27 -0700 (PDT) Received: from cpe-104-162-85-222.nyc.res.rr.com ([104.162.85.222]:52706 helo=[192.168.0.177]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kYYPs-0005Jl-3Z; Fri, 30 Oct 2020 13:42:26 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_AAE730E0-01D7-47BA-AE89-05C98DADD093" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 30 Oct 2020 13:41:51 -0400 In-Reply-To: Cc: "draft-ietf-cellar-ffv1.chairs@ietf.org" , "draft-ietf-cellar-ffv1@ietf.org" , Codec Encoding for LossLess Archiving and Realtime transmission , Barry Leiba To: Spencer Dawkins at IETF , Roman Danyliw References: <160208949226.20172.3161875416157552929@ietfa.amsl.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] New Version Notification - draft-ietf-cellar-ffv1-18.txt X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 17:42:30 -0000 --Apple-Mail=_AAE730E0-01D7-47BA-AE89-05C98DADD093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you Roman, > On Oct 21, 2020, at 2:03 PM, Spencer Dawkins at IETF = wrote: >=20 > Hi, Roman, >=20 > On Wed, Oct 21, 2020 at 12:38 PM Roman Danyliw > wrote: > Hi! > (I can't find your response email to my ballot in my mail client = despite it being in the archive, so apologizes for making the new = thread). >=20 > Thanks for the -18 which cleared most of the COMMENTs. I updated my = ballot. >=20 > In the spirit of clearing what I consider a straightforward DISCUSS, = might I suggest: >=20 > OLD >=20 > Implementations of the FFV1 codec need to take appropriate security > considerations into account, as outlined in [RFC4732]. It is > extremely important for the decoder to be robust against malicious > payloads. Malicious payloads MUST NOT cause the decoder to overrun > its allocated memory or to take an excessive amount of resources to > decode. The same applies to the encoder, ...=20 >=20 > NEW >=20 > Implementations of the FFV1 codec need to take appropriate security = considerations into account. Those related to denial of service are = outlined in Section 2.1 of [RFC4732]. It is extremely important for the = decoder to be robust against malicious payloads. Malicious payloads = MUST NOT cause the decoder to overrun its allocated memory or to take an = excessive amount of resources to decode. An overrun in allocated = memory could lead to arbitrary code execution by an attacker. The same = applies to the encoder, ... The recommendation looks appropriate to me and more clear. I moved it to = a pull request at https://github.com/FFmpeg/FFV1/pull/253 for the = consideration of the other authors. Kind Regards, Dave Rice > Regards, > Roman >=20 > Thanks for this! and I am including the working group in my reply, so = everyone will see it. >=20 > Best, >=20 > Spencer > =20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org = >=20 > Sent: Wednesday, October 7, 2020 12:52 PM > To: Michael Richardson >; superuser@gmail.com = ; barryleiba@computer.org = ; Roman Danyliw >; Peter B. > > Subject: New Version Notification - draft-ietf-cellar-ffv1-18.txt >=20 >=20 > A new version (-18) has been submitted for draft-ietf-cellar-ffv1: > https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.txt = > https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html = >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ = >=20 > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ffv1-18 = >=20 > Please note that it may take a couple of minutes from the time of = submission until the diff is available at tools.ietf.org = . >=20 > IETF Secretariat. >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_AAE730E0-01D7-47BA-AE89-05C98DADD093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Thank= you Roman,

On Oct 21, 2020, at 2:03 PM, Spencer Dawkins = at IETF <spencerdawkins.ietf@gmail.com> wrote:

Hi, Roman,

On Wed, Oct = 21, 2020 at 12:38 PM Roman Danyliw <rdd@cert.org> wrote:
Hi!
(I can't find your response email to my ballot in my mail client despite = it being in the archive, so apologizes for making the new thread).

Thanks for the -18 which cleared most of the COMMENTs.  I updated = my ballot.

In the spirit of clearing what I consider a straightforward DISCUSS, = might I suggest:

OLD

  Implementations of the FFV1 codec need to take appropriate = security
   considerations into account, as outlined in = [RFC4732].  It is
   extremely important for the decoder to be robust against = malicious
   payloads.  Malicious payloads MUST NOT cause the = decoder to overrun
   its allocated memory or to take an excessive amount of = resources to
   decode.  The same applies to the encoder, ...

NEW

Implementations of the FFV1 codec need to take appropriate security = considerations into account.  Those related to denial of service = are outlined in Section 2.1 of [RFC4732].  It is extremely = important for the decoder to be robust against malicious payloads.  = Malicious payloads MUST NOT cause the decoder to overrun its allocated = memory or to take an excessive amount of resources to decode.  =   An overrun in allocated memory could lead to arbitrary code = execution by an attacker.  The same applies to the encoder, ...

The recommendation looks appropriate to me and = more clear. I moved it to a pull request at https://github.com/FFmpeg/FFV1/pull/253 for the = consideration of the other authors.
Kind = Regards,
Dave Rice


Regards,
Roman

Thanks for this! and I am including the working group in my = reply, so everyone will see it.

Best,

Spencer
 

-----Original Message-----
From: internet-drafts@ietf.org <internet-drafts@ietf.org>
Sent: Wednesday, October 7, 2020 12:52 PM
To: Michael Richardson <mcr+ietf@sandelman.ca>; superuser@gmail.com; barryleiba@computer.org; Roman Danyliw <rdd@cert.org>; Peter B. <pb@das-werkstatt.com>
Subject: New Version Notification - draft-ietf-cellar-ffv1-18.txt


A new version (-18) has been submitted for draft-ietf-cellar-ffv1:
https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.txt
https://www.ietf.org/id/draft-ietf-cellar-ffv1-18.html


The IETF datatracker page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/
Diff from previous version:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-cellar-ffv1-18

Please note that it may take a couple of minutes from the time of = submission until the diff is available at tools.ietf.org.

IETF Secretariat.


_______________________________________________
Cellar = mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_AAE730E0-01D7-47BA-AE89-05C98DADD093-- From nobody Fri Oct 30 11:30:23 2020 Return-Path: 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 E8F143A10C5; Fri, 30 Oct 2020 11:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.119 X-Spam-Level: X-Spam-Status: No, score=-1.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 ONQtqKPLeDJ1; Fri, 30 Oct 2020 11:30:14 -0700 (PDT) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 AEA233A10A0; Fri, 30 Oct 2020 11:30:14 -0700 (PDT) Received: from cpe-104-162-85-222.nyc.res.rr.com ([104.162.85.222]:53381 helo=[192.168.0.177]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kYZA5-000haH-Ae; Fri, 30 Oct 2020 14:30:13 -0400 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Dave Rice In-Reply-To: <160049032442.20595.4616862102756589735@ietfa.amsl.com> Date: Fri, 30 Oct 2020 14:29:36 -0400 Cc: The IESG , Michael Richardson , draft-ietf-cellar-ffv1@ietf.org, cellar@ietf.org, cellar-chairs@ietf.org, pb@das-werkstatt.com Content-Transfer-Encoding: quoted-printable Message-Id: <92029D16-621F-4AE0-BC3F-03C08AB21ADE@dericed.com> References: <160049032442.20595.4616862102756589735@ietfa.amsl.com> To: Barry Leiba X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OutGoing-Spam-Status: No, score=0.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Barry Leiba's Discuss on draft-ietf-cellar-ffv1-17: (with DISCUSS and COMMENT) X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 18:30:17 -0000 Hi all, I=E2=80=99m writing this as an update to what aspects of this DISCUSS = are resolved and what may remain. I added a summary at the end, but the = tl;dr is that in my opinion all discuss and comment points are resolved = in our git repository but Section 3.8.1.1 could use a new look in light = of the discuss comments against it. > On Sep 19, 2020, at 12:38 AM, Barry Leiba via Datatracker = wrote: >=20 > Barry Leiba has entered the following ballot position for > draft-ietf-cellar-ffv1-17: Discuss >=20 > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut = this > introductory paragraph, however.) >=20 >=20 > Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. >=20 >=20 > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-cellar-ffv1/ >=20 >=20 >=20 > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- >=20 > There are a number of things I=E2=80=99d like to discuss, because I = find them not > understandable. Perhaps it=E2=80=99s simply because I=E2=80=99m not a = codec expert, but, while > I understand that this is written for readers who will actually be = implementing > he FFV1 codec, some of them will also not be =E2=80=9Cexperts=E2=80=9D. = That said, I=E2=80=99m sure > some of this is just a case of =E2=80=9Cgive Barry some clue and = it=E2=80=99s fine.=E2=80=9D >=20 > =E2=80=94 Section 2.1 =E2=80=94 > You use the term =E2=80=9Csymbol=E2=80=9D here and later, without = defining it, and I don=E2=80=99t know > what it is. A byte? A character? A string of bits? What length? Symbol is defined in = https://github.com/FFmpeg/FFV1/commit/baa92e69bbdb5cece9f99556267906beffcd= 0fd2 as: `Symbol`: A value stored in the bitstream, which is defined and = decoded through one of the methods described in = [@tablePseudoCodeSymbols]. > =E2=80=94 Section 3.8.1.1 =E2=80=94 > I=E2=80=99m not sure how to interpret the stuff in this section. = First, I don=E2=80=99t know > why there are seven =E2=80=9Cfigures=E2=80=9D, with no captions nor = other explanation. Second, > I=E2=80=99m having trouble making sense out of things like this: >=20 > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > l_(i) =3D L_(i) AND > t_(i) =3D R_(i) - r_(i) <=3D=3D > b_(i) =3D 0 <=3D=3D> > L_(i) < R_(i) - r_(i) >=20 > Can you explain how this is meant to be read? Maybe it=E2=80=99s just = me, and maybe > after you explain it I=E2=80=99ll whack myself on the head and say, = =E2=80=9CDoh!=E2=80=9D Reading this would take correlation to Section 2.2.5 (Mathematical = Functions) for definitions of <=3D=3D and <=3D=3D> and the form of a_(b) = and a_(b,c). To read this out-loud would be like: The i-th value of b equaling zero implies that the i-th value of L is = less than the result of i-th value of R minus the i-th value of r. The = reserve implication is also true. These implications both imply that the = =E2=80=98i+1,C_(i)' value of S equals the =E2=80=98S_(i, C_(i))=E2=80=99 = of zero_state as well as the i-th value of l equaling the i-th value of = L as well as the i-th value of t equaling the i-th value of R minus the = i-th value or r. > Third, you say, =E2=80=9CS_(0, i) is the i-th initial state,=E2=80=9D = but you haven=E2=80=99t > previously introduced the term =E2=80=9Cstate=E2=80=9D, and I don=E2=80=99= t know what it means. Section 3.8 includes an informational reference to range coding. An = understanding on how range coding works could make this section more = clear. More captions were added to these figures in = https://github.com/FFmpeg/FFV1/commit/32cb9ea3e697036e81722f1ceced47f74b70= 549f and = https://github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06ae= fca0. > =E2=80=94 Section 3.8.1.2 =E2=80=94 >=20 > "get_rac" returns a boolean, computed from the bytestream as > described in Section 3.8.1.1. >=20 > I see nothing in Section 3.8.1.1 that describes get_rac. We=E2=80=99ve added a definition = https://github.com/FFmpeg/FFV1/commit/199ce1b95eb426e807ddbfd5d8338243d845= 8db1 and cross-references in = https://github.com/FFmpeg/FFV1/commit/ae3de36f528dbcef3fe5fdcc5b63bd5b06ae= fca0. > =E2=80=94 Section 3.8.1.3 =E2=80=94 >=20 > At keyframes all Range coder state variables are set to their = initial > state. >=20 > What does =E2=80=9Cat keyframes=E2=80=9D mean? It was presumed that =E2=80=98at keyframe=E2=80=99 meant a frame where = the keyframe value was set to 1. This is clarified in = https://github.com/FFmpeg/FFV1/commit/4b4d6f3c180fa2c4debefcc73793fc65ddd8= 52c0. > =E2=80=94 Section 3.8.1.5 =E2=80=94 > This is just a list of numbers with no explanation. It needs text = explaining > what it means. An introduction to this table is added at = https://github.com/FFmpeg/FFV1/commit/69dda1b8a4f02bcce47b860df83a2f26afdc= a909 The introduction is: In this mode a State Transition Table is used, indicating in which state = the decoder will move to, based on the current state and the value = extracted from [@figureGetRacPseudoCode]. > =E2=80=94 Section 3.8.2.2 =E2=80=94 >=20 > The level is identical to the predicted one. > The run and the first different level are coded. >=20 > What does =E2=80=9Clevel=E2=80=9D mean? It=E2=80=99s not defined = anywhere. This was rewording to use the term =E2=80=9Csample difference=E2=80=9D = rather than level at = https://github.com/FFmpeg/FFV1/commit/d6fbc97aa32699d5bafba9760e4f5093fcaa= 6120 and to cross-reference to the section that defines sample = difference. > =E2=80=94 Section 4.3.1 =E2=80=94 >=20 > "reserved_for_future_use" has semantics that are reserved for future > use. >=20 > Yes, that seems rather obvious, though it=E2=80=99s oddly worded. But = then you say > what to do with =E2=80=9Cthis value=E2=80=9D, and nowhere do you say = what the value is. How > does one know? This was clarified in = https://github.com/FFmpeg/FFV1/commit/e7f6b342ae5e1c326357479bbbfb2934fe6d= 83f1. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- >=20 > Some editorial comments that I ask you to please consider: >=20 > General: It=E2=80=99s jarring to see the defined terms, such as = =E2=80=9CSample=E2=80=9D and =E2=80=9CPixel=E2=80=9D in > quotes every time they=E2=80=99re used. More common practice is to = quote them when > they=E2=80=99re first defined, and then to just use the capitalization = to show that > they=E2=80=99re defined terms. I find that the quotes affect the = readability and make > it somewhat more of a challenge to read. We agreed. These excessive quotes were removed in = https://github.com/FFmpeg/FFV1/commit/f0eb24b7820889fbd93b68d1e707d4380a90= ded1. > =E2=80=94 Section 2.1 =E2=80=94 >=20 > "Plane": A discrete component of a static image comprised of >=20 > Total, total nit, and pet peeve: =E2=80=9Ccomposed of=E2=80=9D or = =E2=80=9Ccomprising=E2=80=9D, but not > =E2=80=9Ccomprised of=E2=80=9D. Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. > =E2=80=94 Section 2.2.2 =E2=80=94 > You=E2=80=99re missing =E2=80=9Ca % b=E2=80=9D, which is referenced in = Section 2.2.6. Nice catch. We removed this in = https://github.com/FFmpeg/FFV1/commit/34ec93cdacef056c6cb53ca3120d5a021acf= b911 as it is unused in the document. > =E2=80=94 Section 2.2.4 =E2=80=94 >=20 > "a > b" means a is greater than b. > "a >=3D b" means a is greater than or equal to b. > "a < b" means a is less than b. > "a <=3D b" means a is less than or equal b. > "a =3D=3D b" means a is equal to b. > "a !=3D b" means a is not equal to b. >=20 > I don=E2=80=99t think anyone will misunderstand this, so it=E2=80=99s = a very small thing, but=E2=80=A6 > might this be better said as, =E2=80=98 "a > b" is true when a is = greater than b. =E2=80=98 > (and similarly for the rest)? Reworded as suggested in = https://github.com/FFmpeg/FFV1/commit/6ef98dc138d34966cc686f64d1f4224202e6= b263. > =E2=80=94 Section 2.2.5 =E2=80=94 >=20 > "min(a,b)" means the smallest of two values a and b. > "max(a,b)" means the largest of two values a and b. >=20 > Nit: =E2=80=9Csmaller=E2=80=9D and =E2=80=9Clarger=E2=80=9D, for only = two. Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. > =E2=80=94 Section 2.2.7 =E2=80=94 >=20 > "a...b" means any value starting from a to b, inclusive. >=20 > =E2=80=9Cstarting=E2=80=9D? I would leave that word out. Fixed as suggested in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. > =E2=80=94 Section 2.2.9.1 =E2=80=94 >=20 > "remaining_bits_in_bitstream( )" means the count of remaining bits >=20 > Section 2.2.9.3 uses remaining_bits_in_bitstream( NumBytes ), as do = Sections > 4.4 and 4.5. This should too, yes? Yes. Fixed in = https://github.com/FFmpeg/FFV1/commit/5685a9e8c35ce5ca8420b97cbb336aad8fa5= ad0c and = https://github.com/FFmpeg/FFV1/commit/5056a894d16c517a63aaa4925f8ca1a91803= f205. > =E2=80=94 Section 3.2 =E2=80=94 >=20 > Figure 3: A depiction of how relatively positions Samples are > references within this document. >=20 > I think you mean =E2=80=9Cpositioned=E2=80=9D and =E2=80=9Creferenced=E2= =80=9D, yes? Yes. Fixed in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. > =E2=80=94 Section 3.3 =E2=80=94 >=20 > Background: a two's complement signed 16-bit signed integer was used >=20 > I=E2=80=99d remove the first =E2=80=9Csigned=E2=80=9D. Fixed in = https://github.com/FFmpeg/FFV1/commit/55c200e145ed9067459d31910d3eda592109= 7098. > =E2=80=94 Section 3.8.2 =E2=80=94 >=20 > The end of the bitstream of the "Frame" is filled with 0-bits until > that the bitstream contains a multiple of 8 bits. >=20 > Is =E2=80=9Cthat=E2=80=9D just an extra word that needs to be struck, = or is something else > wrong here? And is this meant to be what we usually call = =E2=80=9Cpadding=E2=80=9D? Fixed in = https://github.com/FFmpeg/FFV1/commit/fe219d9b2afff5583b40ea597918b5633d11= 88ea. > =E2=80=94 Section 4 =E2=80=94 >=20 > Within the following sub-sections, pseudo-code is used to explain = the > structure of each FFV1 bitstream component, as described in > Section 2.2.1. >=20 > I read this as saying that Section 2.2.1 describes the structure of = each FFV1 > bitstream component, until I went back there and looked. I suggest = reordering > the sentence to help the reader a bit: >=20 > NEW > Within the following sub-sections, pseudo-code is used, as described > in Section 2.2.1, to explain the structure of each FFV1 bitstream > component. > END The suggested was taken and used in = https://github.com/FFmpeg/FFV1/commit/ab5a5c944d518ad72a982118b3c90b99a78d= 5d7c. > =E2=80=94 Section 4.5 =E2=80=94 >=20 > Encoders SHOULD NOT fill these bits. > Decoders SHOULD ignore these bits. >=20 > Before this you describe two kinds of bits, and it=E2=80=99s not clear = whether these > are talking about both kinds, or just the latter. I think changing = =E2=80=9Cthese=E2=80=9D to > =E2=80=9Creserved=E2=80=9D is better. Adjusted in = https://github.com/FFmpeg/FFV1/commit/12bfc977f5f868404b69f434501f011a850e= e9c0. > =E2=80=94 Section 6 =E2=80=94 >=20 > A frequent security problem in image > and video codecs is also to not check for integer overflows, for > example to allocate "frame_pixel_width * frame_pixel_height" in > "Pixel" count computations without considering that the > multiplication result may have overflowed the arithmetic types = range. >=20 > This is somewhat complex and awkward (arguably a comma splice), and I = suggest > splitting the sentence thus: >=20 > NEW > A frequent security problem in image > and video codecs is failure to check for integer overflows. An > example is allocating "frame_pixel_width * frame_pixel_height" in > "Pixel" count computations without considering that the > multiplication result may have overflowed the arithmetic types = range. > END Fixed in = https://github.com/FFmpeg/FFV1/commit/741f67b405b2bfbe683a2a3d9dc83468bca9= 60cf. > I might also make the =E2=80=9Cmust=E2=80=9D in the last sentence of = that paragraph be =E2=80=9CMUST=E2=80=9D. Fixed in = https://github.com/FFmpeg/FFV1/commit/50d9e14ad889cc833d65a905a01637ea8b52= 6a45. summary: In my opinion, all discuss and comments listed in this review have been = resolved with the exception of the status of comments on Section 3.8.1.1 = being less clear. I=E2=80=99m pasting in the current state of Section = 3.8.1.1 for consideration: > 3.8.1.1. Range Binary Values >=20 > To encode binary digits efficiently a Range coder is used. C_(i) = is > the i-th Context. B_(i) is the i-th byte of the bytestream. b_(i) = is > the i-th Range coded binary value, S_(0, i) is the i-th initial > state. The length of the bytestream encoding n binary symbols is > j_(n) bytes. >=20 > r_(i) =3D floor( ( R_(i) * S_(i, C_(i)) ) / 2 ^ 8 ) >=20 > Figure 11: A formula of the read of a binary value in Range > Binary mode. >=20 > S_(i + 1, C_(i)) =3D zero_state_(S_(i, C_(i))) AND > l_(i) =3D L_(i) AND > t_(i) =3D R_(i) - r_(i) <=3D=3D > b_(i) =3D 0 <=3D=3D> > L_(i) < R_(i) - r_(i) >=20 > S_(i + 1, C_(i)) =3D one_state_(S_(i, C_(i))) AND > l_(i) =3D L_(i) - R_(i) + r_(i) AND > t_(i) =3D r_(i) <=3D=3D > b_(i) =3D 1 <=3D=3D> > L_(i) >=3D R_(i) - r_(i) >=20 > Figure 12 >=20 > S_(i + 1, k) =3D S_(i, k) <=3D=3D C_(i) !=3D k >=20 > Figure 13: The "i+1,k"-th State is equal to the "i,k"-th State if > the value of "k" is unequal to the i-th value of Context. >=20 > R_(i + 1) =3D 2 ^ 8 * t_(i) AND > L_(i + 1) =3D 2 ^ 8 * l_(i) + B_(j_(i)) AND > j_(i + 1) =3D j_(i) + 1 <=3D=3D > t_(i) < 2 ^ 8 >=20 > R_(i + 1) =3D t_(i) AND > L_(i + 1) =3D l_(i) AND > j_(i + 1) =3D j_(i) <=3D=3D > t_(i) >=3D 2 ^ 8 >=20 > Figure 14: The "i+1"-th values for "Range", "Low", and the length > of the bytestream encoding are conditionally set depending on the > "i-th" value of "t". >=20 > R_(0) =3D 65280 >=20 > Figure 15: The initial value for "Range". >=20 > L_(0) =3D 2 ^ 8 * B_(0) + B_(1) >=20 > Figure 16: The initial value for "Low" is set according to the > first two bytes of the bytestream. >=20 > j_(0) =3D 2 >=20 > Figure 17: The initial value for "j", the length of the > bytestream encoding. >=20 > range =3D 0xFF00; > end =3D 0; > low =3D get_bits(16); > if (low >=3D range) { > low =3D range; > end =3D 1; > } >=20 > Figure 18: A pseudo-code description of the initial states in > Range Binary mode. >=20 > refill() { > if (range < 256) { > range =3D range * 256; > low =3D low * 256; > if (!end) { > c.low +=3D get_bits(8); > if (remaining_bits_in_bitstream( NumBytes ) =3D=3D 0) { > end =3D 1; > } > } > } > } >=20 > Figure 19: A pseudo-code description of refilling the Range > Binary Value coder buffer. >=20 > get_rac(state) { > rangeoff =3D (range * state) / 256; > range -=3D rangeoff; > if (low < range) { > state =3D zero_state[state]; > refill(); > return 0; > } else { > low -=3D range; > state =3D one_state[state]; > range =3D rangeoff; > refill(); > return 1; > } > } >=20 > Figure 20: A pseudo-code description of the read of a binary > value in Range Binary mode. Best Regards, Dave Rice From nobody Fri Oct 30 13:33:04 2020 Return-Path: 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 ADAEE3A0A20 for ; Fri, 30 Oct 2020 13:33:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.118 X-Spam-Level: X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 JdXzg6W3V5-D for ; Fri, 30 Oct 2020 13:33:01 -0700 (PDT) Received: from server172-4.web-hosting.com (server172-4.web-hosting.com [68.65.122.112]) (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 16A743A1226 for ; Fri, 30 Oct 2020 13:33:01 -0700 (PDT) Received: from cpe-104-162-85-222.nyc.res.rr.com ([104.162.85.222]:54838 helo=[192.168.0.177]) by server172.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1kYb4v-002J7E-BN; Fri, 30 Oct 2020 16:33:00 -0400 From: Dave Rice Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E87E19CF-E62B-460D-9691-1AC589070087" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 30 Oct 2020 16:32:34 -0400 In-Reply-To: <15392.1604068065@localhost> Cc: cellar@ietf.org To: Michael Richardson References: <15392.1604068065@localhost> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-OutGoing-Spam-Status: No, score=-0.2 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server172.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - dericed.com X-Get-Message-Sender-Via: server172.web-hosting.com: authenticated_id: dave@dericed.com X-Authenticated-Sender: server172.web-hosting.com: dave@dericed.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [Cellar] Please fill out our survey on IETF authoring tools (fwd) IETF Executive Director: Please fill out our survey on IETF authoring tools X-BeenThere: cellar@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Codec Encoding for LossLess Archiving and Realtime transmission List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 20:33:03 -0000 --Apple-Mail=_E87E19CF-E62B-460D-9691-1AC589070087 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, I completed the survey, as I think this working group is the first IETF = authoring experience for many of the authors, I was generally ticking = off lots of 'always' and =E2=80=98never=E2=80=99 to just highlight the = particular markdown-to-rfc-xml-version-3 path that we use. Dave > On Oct 30, 2020, at 10:27 AM, Michael Richardson = wrote: >=20 >=20 > Your input would be appreciated. > CELLAR has a different workflow than many others, so good to capture = them. >=20 > <#secure method=3Dpgpmime mode=3Dsign> >=20 > From: IETF Executive Director > Subject: Please fill out our survey on IETF authoring tools > Date: October 29, 2020 at 9:14:44 PM EDT > To: ietf-surveys@ietf.org >=20 >=20 > Hi=20 >=20 > I am writing to ask you to fill out an IETF survey to help us = understand what tools and formats you use for authoring IETF Internet = Drafts (I-Ds), how you use them and what more you need from them. The = data from this survey is vital for our future planning of tools = investment. >=20 > Your email address has been selected because you have been listed as = the author or submitter of an I-D in the last five years. >=20 > Please help us by taking a few minutes to fill out this survey, even = if you do not author I-Ds any more: >=20 > https://ietf.iad1.qualtrics.com/jfe/form/SV_8d21RFqe5dBijOJ >=20 > Thank you > Jay >=20 > --=20 > Jay Daley > IETF Executive Director > exec-director@ietf.org >=20 >=20 >=20 >=20 >=20 >=20 > -- > Michael Richardson . o O ( IPv6 I=C3=B8T = consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide >=20 >=20 >=20 >=20 > _______________________________________________ > Cellar mailing list > Cellar@ietf.org > https://www.ietf.org/mailman/listinfo/cellar --Apple-Mail=_E87E19CF-E62B-460D-9691-1AC589070087 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michael,
I completed the survey, as I think this working = group is the first IETF authoring experience for many of the authors, I = was generally ticking off lots of 'always' and =E2=80=98never=E2=80=99 = to just highlight the particular markdown-to-rfc-xml-version-3 path that = we use.
Dave

On Oct = 30, 2020, at 10:27 AM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:


Your = input would be appreciated.
CELLAR has a different = workflow than many others, so good to capture them.

<#secure method=3Dpgpmime mode=3Dsign>

From: IETF Executive Director <exec-director@ietf.org>
Subject: = Please fill out = our survey on IETF authoring tools
Date: = October 29, 2020 at 9:14:44 PM = EDT
To: = ietf-surveys@ietf.org


Hi

I am writing = to ask you to fill out an IETF survey to help us understand what tools = and formats you use for authoring IETF Internet Drafts (I-Ds), how you = use them and what more you need from them.  The data from this = survey is vital for our future planning of tools investment.

Your email address has been selected because = you have been listed as the author or submitter of an I-D in the last = five years.

Please help us by taking a few = minutes to fill out this survey, even if you do not author I-Ds any = more:

https://ietf.iad1.qualtrics.com/jfe/form/SV_8d21RFqe5dBijOJ=

Thank you
Jay

--
Jay Daley
IETF = Executive Director
exec-director@ietf.org





--
Michael Richardson = <mcr+IETF@sandelman.ca>   . o O ( IPv6 I=C3=B8T = consulting )
=           Sandelman = Software Works Inc, Ottawa and Worldwide




_______________________________________________
Cellar mailing list
Cellar@ietf.org
https://www.ietf.org/mailman/listinfo/cellar

= --Apple-Mail=_E87E19CF-E62B-460D-9691-1AC589070087--