Re: [AVTCORE] AD Review of draft-ietf-payload-vp9-12

Jonathan Lennox <jonathan.lennox@8x8.com> Fri, 07 May 2021 18:38 UTC

Return-Path: <jonathan.lennox@8x8.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 ED72C3A2715 for <avt@ietfa.amsl.com>; Fri, 7 May 2021 11:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=8x8.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 AKvYtasliHdo for <avt@ietfa.amsl.com>; Fri, 7 May 2021 11:38:44 -0700 (PDT)
Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 9E14F3A2D6F for <avt@ietf.org>; Fri, 7 May 2021 11:31:37 -0700 (PDT)
Received: by mail-qk1-x72e.google.com with SMTP id a2so9430921qkh.11 for <avt@ietf.org>; Fri, 07 May 2021 11:31:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=8x8.com; s=googlemail; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=npiEoMw1NBAHEmWcSQJzt+lrN2y1/Mmq0X7Sbl5Nd3Q=; b=hR/3ie8ki9Gz8WLIPcjsBEen26dUSylpFA+IzWiZXiC8woLmh3vgr48BJsE1kNgfre Jyckwd4/jCrVaELHFI0YBjlKC9e/t6ATn7C19y089YY+I53ZBTUZOnFDAunDALgOB4Bl 1JNJcGYhylqGX8PZPxGWf9izq8ib4JfpORQ5g=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=npiEoMw1NBAHEmWcSQJzt+lrN2y1/Mmq0X7Sbl5Nd3Q=; b=WqSR1TFezoDgwjAvnrnBeh/K/0kaGJwwkh0IoR7zPba0Cx6t5qrYOGXaFgt78ZS0/s CiJu55YzlV03PIA4VKaT5IIZwKXGxf3DCgNRSYZ6AQ32ifIS4o88kEgBDoDDY9C6/rkP /XKdZbsL3gR4zRT7+6fHVGwbpXZx4caezTpEQbKF+T2QfLeK7S0EGTSC0eFY99Rm94Zu 3BcFuv4FHZf5Xy6bkP5n1Q3s6jDFxIkG3FL0eekor7TfdqL5Ol98Y3UlARAB9L9LXZSQ 3FBLZXcyttpf26ybA96Vh0Gexs2pY2ZtLbI27YSJrOLLk5QlyWuM753emslRw63mzEVs Em1A==
X-Gm-Message-State: AOAM5302rOlZ7kQq9F4QvtCgZpP/HIEa5UX8vzcdwgUityWZoFmKpQM7 2sshf5gMlP6+xaUi+a4oMoAlbg==
X-Google-Smtp-Source: ABdhPJxHstqBFJY+moBCv3kxzgU0nb4hrm2zlgbLhkcLensIFnyNs2QQfJg7LVYbg1xCfMgskh0P8Q==
X-Received: by 2002:a37:ac17:: with SMTP id e23mr11301474qkm.184.1620412294158; Fri, 07 May 2021 11:31:34 -0700 (PDT)
Received: from smtpclient.apple (c-24-0-149-15.hsd1.nj.comcast.net. [24.0.149.15]) by smtp.gmail.com with ESMTPSA id z4sm5341057qtq.34.2021.05.07.11.31.33 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 May 2021 11:31:33 -0700 (PDT)
From: Jonathan Lennox <jonathan.lennox@8x8.com>
Message-Id: <93575A29-792C-405C-8455-F39560A21E2F@8x8.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_925561F4-E5B6-450F-8867-D2473EAEA12E"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\))
Date: Fri, 7 May 2021 14:31:32 -0400
In-Reply-To: <CAL0qLwZhFSG=zciLMt=USudw-YGPWXmNka84oeS=rWagbC5WFA@mail.gmail.com>
Cc: IETF AVTCore WG <avt@ietf.org>
To: "Murray S. Kucherawy" <superuser@gmail.com>
References: <CAL0qLwZhFSG=zciLMt=USudw-YGPWXmNka84oeS=rWagbC5WFA@mail.gmail.com>
X-Mailer: Apple Mail (2.3654.80.0.2.43)
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/RPJju1NK9cY6mdSnRov8fO5K1nc>
Subject: Re: [AVTCORE] AD Review of draft-ietf-payload-vp9-12
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 07 May 2021 18:38:50 -0000

Hi - sorry for not responding sooner.  Responses inline.

Do you want me to publish a version -13 with the changes mentioned here?  In the meantime my changes are in the GitHub repo at https://github.com/juberti/draughts/tree/master/vp9 <https://github.com/juberti/draughts/tree/master/vp9>.

> On Apr 19, 2021, at 6:32 PM, Murray S. Kucherawy <superuser@gmail.com> wrote:
> 
> This is my review of draft-ietf-payload-vp9-12.
> 
> Video codecs are not exactly my strong suit, so finding technical errors wasn't an expected part of my mission here.  I'm going on faith that this is all technically correct, and just looking for editorial or procedural things.
> 
> -MSK
> 
> --
> 
> Shepherd writeup:
> 
> * We should probably explain why a document coming out of AVTCORE bears a name that doesn't start with "draft-ietf-avtcore-...".  The shepherd writeup should mention this.  Or if you don't want to do that, please let me know what the history is there so I can include it in a note to the IESG.

Either in the writeup or in the note is fine, but the history is that the Payload Working Group was merged back into the AVTCore group in September 2019, whereas this draft was first adopted as a WG item of the Payload group in 2015.  (Yes, we’ve been very slow about finishing this draft.)

> * The writeup identifies draft-ietf-avtext-lrr as a downward reference, but that document is in the queue already for Proposed Standard status, and this one is going for the same, so I don't believe this is a downward reference (once both are published).
>  <>
> General nits:
> 
> * Referring to an I-D as a "memo" is a little outdated.  Suggest "document" or "specification" instead.

Ok.

> 
> Section 1:
> 
> * Should this document obsolete VP8 (RFC 6386)?

No, VP8 and VP9 are two different codecs, and they’re both expected to remain in active use.

> Section 3:
> 
> * The Editor's Note seems like it should've been resolved by now.  If no suggestion for improved terminology arrives by the end of IESG Evaluation, should that paragraph be removed?

I’ve kept the clarification (that “Picture Group” and “Group of Pictures” are different), but removed the request for better terminology.

> Section 4.1:
> 
> * For "Timestamp", did you mean to say "alternately" (i.e., every other one; alternating) or "alternatively" (i.e., presenting a different choice)?

“Alternatively”; changed.

> Section 4.2:
> 
> * First sentence, "The" shouldn't be capitalized.

Ok.

> 
> * The use of CONDITIONALLY RECOMMENDED or CONDITIONALLY REQUIRED is puzzling because one of them is a BCP 14 word and one isn't, but both look like they're supposed to be.  This might be better described in the prose for each of these fields, and just use the BCP 14 words here (or omit them entirely).

I’ve made “Conditionally” only initially capitalized, and clarified the description of the fields to have capitalized BCP 14 words.

> * The description of PID refers to a "maximum ID", but that's not specified anywhere.  Is it simply the largest PID that will fit in the available bits, or is there some other maximum to be observed?

The maximum that will fit in the available bits; I’ve clarified.

> 
> * For the "D:" bullet, I think "MUST be set to one if current spatial layer SID frame depends on spatial layer SID-1 frame of the same picture. MUST only be set to zero if current spatial layer SID frame does not depend on spatial layer SID-1 frame of the same picture." can be reduced to "MUST be set to one if and only if the current spatial layer SID frame depends on spatial layer SID-1 frame of the same picture."

Good improvement.

> 
> Section 6.1:
> 
> * Does the media type's subtype name have to be "VP9", in specifically that case?

No, media subtype names aren’t case-sensitive.  Do you think it would be clearer to write it in lower-case here?

> * Per RFC 6838, please change Required Parameters to "N/A" instead of "None".

Ok.

> * I think it's unusual for the BCP 14 text to appear in a media type registration (specifically, the Optional Parameters).  You might consider moving that discussion to some other prose section, and in the media type registration just list the supported parameters and their syntaxes.

I’ve reorganized this section; I think it generally flows better now.

Thank you for your comments!

— 
Jonathan Lennox
jonathan.lennox@8x8.com