Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rtp-vvc-15.txt

"Murray S. Kucherawy" <superuser@gmail.com> Mon, 02 May 2022 05:02 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69DB5C157B57 for <avt@ietfa.amsl.com>; Sun, 1 May 2022 22:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.094
X-Spam-Level:
X-Spam-Status: No, score=-2.094 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 76nG2q2i9n2r for <avt@ietfa.amsl.com>; Sun, 1 May 2022 22:02:00 -0700 (PDT)
Received: from mail-vk1-xa2e.google.com (mail-vk1-xa2e.google.com [IPv6:2607:f8b0:4864:20::a2e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAC2C157B53 for <avt@ietf.org>; Sun, 1 May 2022 22:02:00 -0700 (PDT)
Received: by mail-vk1-xa2e.google.com with SMTP id e144so6140721vke.9 for <avt@ietf.org>; Sun, 01 May 2022 22:02:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CRt97XkhDToGA/gwe1NQBzjFa5IE2sYAyvODw01vR2g=; b=ghRh4z8+LcU7eIKI6gqKk0tPbbAloKL/E3DjmPabXd9IhRQAU3la/FfZUMN1cypHui l1THuqSER+byhI6hb0kwNj4GuwQ/QmmvoiWdd1o3JaVer7oqvTkBl60D09bgmW6olzRP xfH/B0LLycnRUvocqOwjNErX8Sau832XRzRbCZRdNZtXfz+Wvxi2zgOD6j5eItStP772 LRrCq8ZNtOs9ILAMPKlpEzgYJrPa8d0DHymKllvvd/RWCZkuK/CpTdLn6AU7bCY/JNT3 puzZ3JX3Ca1pnHGxDK7iGpI3gbMno8E2bmc2UZPzcFEAUixLfHT6wMVGVPW7K96zb1Rf n7cQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CRt97XkhDToGA/gwe1NQBzjFa5IE2sYAyvODw01vR2g=; b=gpLvidjJXUW0SX8gjKrbC1ko2QDuNCGAiXc4kHw/kh9qOaF7cnu/V3j6qIjuhAhdQp o6A5b4eypUbz/FiiLfntoDggji6ybPCAaqiDkozn8d+BTvNdCygOY69iGEf4wpdFWywS pgdx3b5iJVbKGZjkWkdqtQ6pPeNuQGeXK3KHx0sG7/GaPWRA1nyK0MacwthfvIxpi9J1 6/NSW9wRgqc8skMdLbG+k+z4UnKMxD/STfYqIimUNn56z2OMjtlX3IJy+O9PFQJ+0FBE 9E7XAVCX2oKqA2NdD+j/W/OUQTyL6SpF46IqUlgvr1YOh2noJmHQplUY4If2yTpklHGT W/uQ==
X-Gm-Message-State: AOAM530CfQBoPGhUGf4OGcT/CYFw2sF3sOnFa4VPV1JTWqcfxGFGJERa jdtlT3MW0DsyGhtEh8iKJdJTpdAgaCjTMfpdID8=
X-Google-Smtp-Source: ABdhPJxY4F3xSJHqQIlYUqKVJ4Uv/VThyf6gSD5AKQ1OzLLkdJonUYPk7xInThgpid7CRpdbOrwsh9KTYSyi19kcaRA=
X-Received: by 2002:a05:6122:d93:b0:331:4fb0:7162 with SMTP id bc19-20020a0561220d9300b003314fb07162mr2701677vkb.4.1651467719363; Sun, 01 May 2022 22:01:59 -0700 (PDT)
MIME-Version: 1.0
References: <165067964372.9634.12335635644469786982@ietfa.amsl.com> <PH0PR17MB57280E8DEEFFEA27C2B7FB38F4F69@PH0PR17MB5728.namprd17.prod.outlook.com> <5713154A-0C5A-4B11-AF80-D360DC0C431D@ieee.org>
In-Reply-To: <5713154A-0C5A-4B11-AF80-D360DC0C431D@ieee.org>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 01 May 2022 22:01:48 -0700
Message-ID: <CAL0qLwacjKpLgBG2C+y5qqZPRkneiuEEDBk05CkNyu3OQ837=g@mail.gmail.com>
To: shuai zhao <shuai.zhao@ieee.org>
Cc: "bernard.aboba@gmail.com" <bernard.aboba@gmail.com>, "christer.holmberg@ericsson.com" <christer.holmberg@ericsson.com>, IETF AVTCore WG <avt@ietf.org>, "Miska M. Hannuksela" <miska.hannuksela@nokia.com>, Stephan Wenger <stewe@stewe.org>, Yago Sanchez <yago.sanchez@hhi.fraunhofer.de>, Ye-Kui Wang <yekui.wang@bytedance.com>
Content-Type: multipart/alternative; boundary="000000000000c553fb05de004a45"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/02NsbYs79njOcXDQbdkKMhEx1xM>
Subject: Re: [AVTCORE] New Version Notification for draft-ietf-avtcore-rtp-vvc-15.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 May 2022 05:02:04 -0000

I still have some concerns about Section 7.1.  I did see Stephan's other
threads about it.  In one of them he said:

> I wonder whether there’s anyone here on this list with a) an interest in
VVC’s media type registration, and b) at least basic knowledge of the
requirements of RFC6838?  If that person would step forward and help us
with that section, I would very much appreciate it.

When not serving on the IESG, I am one of the reviewers of media type
requests, so I think I can be of service here.  :-)

There are two issues.  The first, simpler, one is that you've now added all
the missing fields from RFC 6838, but one of them says "N/A" for
"Applications that use this media type".  If none are using it (or will
be), why are we registering it?

The other is that you list "profile-id, tier-flag, sub-profile-id,
interop-constraints, and level-id" as optional parameters, but then proceed
to describe those plus all of the following:

sprop-sublayer-id
sprop-ols-id
recv-sublayer-id
recv-ols-id
max-recv-level-id
sprop-dci
sprop-vps
sprop-sps
sprop-pps
max-lsr
max-fps
sprop-max-don-diff
sprop-depack-buff-bytes
depack-buf-cap

At a minimum, the upper list should be extended so that it's complete.
However, I would suggest that a section be added that contains the
description of each of the optional parameters, one per subsection.  Then
the current Section 7.1 (which now includes the registration template) can
include the list without also being the full specifications of those
parameters.  Otherwise IANA has to copy that entire blob of text into the
registration, when all they really need is the reference to this document
once published.

Note that this is just a proposal for organizing the material, not changing
anything within it.

-MSK

On Mon, Apr 25, 2022 at 10:18 AM shuai zhao <shuai.zhao@ieee.org> wrote:

> Resent to the group and hopefully everyone has a copy now.
>
> Best,
> Shuai
>
> On Apr 24, 2022, at 10:06 AM, shuai zhao <shuai.zhao@ieee.org> wrote:
>
> Thanks Murray, Bernard, Christer and Bernard for the review on revision 14.
>
> Note: I could not reply to individual email since I did not receive any
> email from avtcore mailing list since March 25th. A very convenient
> excuse to disappear….
>
> So I compiled some the major comments with proposed fix below… for minor
> and editorial fix, please see the diff.
>
>
> *To Christer Holmberg:*
>
>    - Q1 Section 7.2.1, replace “this parameter” with “fmtp”
>    - Q2 Section 7.2.1, add informative note for more clarity
>    - Q3: Section 7.2.1, no need to add text for “fmtp” since we had such
>    text in a paragraph above
>    - Q4: exemplary SDP O/A is added under section 7.2.1, As well as the
>    RFC6838 template.
>    - Q5: Based on the mailing list discussion, no action is needed here.
>    - Q6: Based on the mailing list discussion, no action is needed here.
>    - Q7: Based on the mailing list discussion, no action is needed here.
>
>
> *To Murray:*
>
>    - Section 1, fix the grammar
>    - Section 7.1, add back informative note for “optional parameters”
>    - Section 3.2 Removed unused “RPS” abbr
>    - Section 4.3.2: Based on the mailing list discussion, no action is
>    needed here.
>    - Add RFC editor note under Appendix A
>    - Fix all editorial typo/errors
>
>
>
> Best,
> Shuai
>
>
> *From: *internet-drafts@ietf.org <internet-drafts@ietf.org>
> *Date: *Friday, April 22, 2022 at 7:07 PM
> *To: *Miska M. Hannuksela <miska.hannuksela@nokia.com>, Miska Hannuksela <
> miska.hannuksela@nokia.com>, Shuai Zhao <shuai.zhao@ieee.org>, Stephan
> Wenger <stewe@stewe.org>, Yago Sanchez <yago.sanchez@hhi.fraunhofer.de>,
> Ye-Kui Wang <yekui.wang@bytedance.com>
> *Subject: *New Version Notification for draft-ietf-avtcore-rtp-vvc-15.txt
>
>
> A new version of I-D, draft-ietf-avtcore-rtp-vvc-15.txt
> has been successfully submitted by Shuai Zhao and posted to the
> IETF repository.
>
> Name:           draft-ietf-avtcore-rtp-vvc
> Revision:       15
> Title:          RTP Payload Format for Versatile Video Coding (VVC)
> Document date:  2022-04-22
> Group:          avtcore
> Pages:          67
> URL:
> https://www.ietf.org/archive/id/draft-ietf-avtcore-rtp-vvc-15.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-vvc/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-ietf-avtcore-rtp-vvc
> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-rtp-vvc-15
>
> Abstract:
>    This memo describes an RTP payload format for the video coding
>    standard ITU-T Recommendation H.266 and ISO/IEC International
>    Standard 23090-3, both also known as Versatile Video Coding (VVC) and
>    developed by the Joint Video Experts Team (JVET).  The RTP payload
>    format allows for packetization of one or more Network Abstraction
>    Layer (NAL) units in each RTP packet payload as well as fragmentation
>    of a NAL unit into multiple RTP packets.  The payload format has wide
>    applicability in videoconferencing, Internet video streaming, and
>    high-bitrate entertainment-quality video, among other applications.
>
>
>
>
>
>
> The IETF Secretariat
>
>
>