[video-codec] Mirja Kühlewind's Abstain on draft-ietf-netvc-testing-08: (with COMMENT)

Mirja Kühlewind via Datatracker <noreply@ietf.org> Wed, 05 June 2019 19:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: video-codec@ietf.org
Delivered-To: video-codec@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9816712021B; Wed, 5 Jun 2019 12:33:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-netvc-testing@ietf.org, Matthew Miller <linuxwolf+ietf@outer-planes.net>, netvc-chairs@ietf.org, linuxwolf+ietf@outer-planes.net, video-codec@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Mirja Kühlewind <ietf@kuehlewind.net>
Message-ID: <155976320861.22415.998674089792385186.idtracker@ietfa.amsl.com>
Date: Wed, 05 Jun 2019 12:33:28 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/video-codec/QZ6Ly79fV9gg1KS9ynhFhvQPZhk>
Subject: [video-codec] Mirja Kühlewind's Abstain on draft-ietf-netvc-testing-08: (with COMMENT)
X-BeenThere: video-codec@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Video codec BoF discussion list <video-codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/video-codec>, <mailto:video-codec-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/video-codec/>
List-Post: <mailto:video-codec@ietf.org>
List-Help: <mailto:video-codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/video-codec>, <mailto:video-codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Jun 2019 19:33:28 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-netvc-testing-08: 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-netvc-testing/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update: This document has no security considerations section, while having this
section is required.

This document reads more like a user manual of the Daala tools repository
(together with the test sequences). I wonder why this is not simply achieved
within the repo? What’s the benefit of having this in an RFC? Especially I’m
worried that this document is basically useless in case the repo and test
sequences disappear, and are therefore not available anymore in future, or
change significantly. I understand that this is referenced by OAM and therefore
publication is desired, however, I don't think that makes my concern about the
standalone usefulness of this document invalid. If you really want to publish
in the RFC series, I would recommend to reduce the dependencies to these repos
and try to make this document more useful as a standalone test description
(which would probably mean removing most of section 4 and adding some
additional information to other parts).

Also, the shepherd write-up seems to indicate that this document has an IPR
disclosure that was filed after WG last call. Is the wg aware of this? Has this
been discussed in the wg?

Other more concrete comments:
1) Quick question on 2.1: Is the tester supposed to view one image after the
other or both at the same time? And if one ofter the other, could the order
impact the results (and should maybe be randomly chosen therfore)?

2) Sec 2.3: Would it make sense to provide a (normative) reference to MOS? Or
is that supposed to be so well know that that is not even necessary?

3) Sec 3.1: maybe spell out PSNR on first occurrence. And would it make sense
to provide a reference for PSNR?

4) Sec 3.2: “ The weights used by the dump_pnsrhvs.c tool in
   the Daala repository have been found to be the best match to real MOS
   scores.”
Maybe document these weights in this document as well…?

5) Sec 5.3: Maybe spell out CQP at first occurrence