Re: [payload] Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT)

Barry Leiba <barryleiba@computer.org> Sat, 05 September 2015 03:26 UTC

Return-Path: <barryleiba@gmail.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 791561AD373; Fri, 4 Sep 2015 20:26:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 looYg0JrY5ku; Fri, 4 Sep 2015 20:26:06 -0700 (PDT)
Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c:c05::231]) (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 C38FC1B3B71; Fri, 4 Sep 2015 20:26:05 -0700 (PDT)
Received: by vkbf67 with SMTP id f67so21019820vkb.0; Fri, 04 Sep 2015 20:26:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=B+PP0RRgsoRjfl/G8ZRkSugwy/2YISsNRlgXuoQmHVA=; b=TBJuVcuIiZQ3xGMiAiPBSPDlb0uIYkEmK7Fy9lYN9xXxJsPr5Ujxd2S17pMqgNaomP RnrZNcNBI4PGJMqOSyiSNl+QFPOQuAsWu0ciGkCSZuNowtdgM1GitN/RjZjjlZl9xCdi JYSpjnBetR2Ztc/bD2co4cusFmTk0WEdwcbRk7X/sXtEjXeIccslOyMMYMoLszFYjZLX h7SvvyYNOueZj4UIAtH8XZa3mvM2PhseLKHK0sVlwgd3ievBJ+s6o+G/BJbXePmbPY7J FRyorxVQtP7gWkFWYbyYU13Udk0VSnpD0rd9kuuvvmocz+7Mc/+zHc2KAkJw2l+A9Ydz MvfQ==
MIME-Version: 1.0
X-Received: by 10.52.184.163 with SMTP id ev3mr9336642vdc.63.1441423564846; Fri, 04 Sep 2015 20:26:04 -0700 (PDT)
Sender: barryleiba@gmail.com
Received: by 10.31.88.196 with HTTP; Fri, 4 Sep 2015 20:26:04 -0700 (PDT)
In-Reply-To: <4816a58da40947eaa58167a46c08d591@NALASEXR01H.na.qualcomm.com>
References: <20150902050950.30223.95513.idtracker@ietfa.amsl.com> <4816a58da40947eaa58167a46c08d591@NALASEXR01H.na.qualcomm.com>
Date: Fri, 04 Sep 2015 23:26:04 -0400
X-Google-Sender-Auth: S4QPtnY3vGc9bS_LzWSiEKRs3zg
Message-ID: <CALaySJLoc=0OkcRwgkc=bdApPQ44SOWMr2=Sp0xQL-kkTWZRqQ@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: "Wang, Ye-Kui" <yekuiw@qti.qualcomm.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/payload/y1EbUA_Kz76m9YUOZN0A1CYdSfY>
Cc: "draft-ietf-payload-rtp-h265@ietf.org" <draft-ietf-payload-rtp-h265@ietf.org>, "payload-chairs@ietf.org" <payload-chairs@ietf.org>, The IESG <iesg@ietf.org>, "payload@ietf.org" <payload@ietf.org>
Subject: Re: [payload] Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Sep 2015 03:26:07 -0000

YK, thanks for the response.  I'm happy with the part about the HEVC
overview -- if the working group thinks it's useful to have it, I have
no further concern.

On not reorganizing the registration template, I'll also step aside.
I think it's the wrong decision, but if it's the working group's
decision it's not for me to say otherwise.  Again, thanks for
considering my comments.

Barry

On Fri, Sep 4, 2015 at 5:29 PM, Wang, Ye-Kui <yekuiw@qti.qualcomm.com> wrote:
> Hi Barry,
>
> Thanks a lot for your review.
>
> On the first point (on the HEVC overview): We tried to provide some easy-to-understand descriptions of the HEVC features that implementers of this document may be interested. This followed the document structure of earlier video codec RTP payload format such as RFC 3984/6184 and RFC 6190.
>
> As Stephan clarified in the reply to Stephen Farrell, which I copy here: The WG heard this comment before and discussed it.  It is my understanding of the WG consensus that the level of detail is about right.  For your information, the H.265 version 1 spec is an extremely dense document (much denser than the payload format) and, set out in 10 pt. Times Roman, spans 300 pages.  We cover the core codec only superficially, but dig in a bit deeper in those aspects where we added signaling support for capability exchange (for example, parallelization tools).
>
> On the second point (on the media type parameters and IANA registration): This point has also been discussed by the WG, and explicitly discussed at a recent face-to-face IETF meeting, with the decision being to keep it as is.
>
> BR, YK
>
> -----Original Message-----
> From: Barry Leiba [mailto:barryleiba@computer.org]
> Sent: Tuesday, September 01, 2015 10:10 PM
> To: The IESG
> Cc: payload-chairs@ietf.org; draft-ietf-payload-rtp-h265@ietf.org; payload@ietf.org
> Subject: Barry Leiba's No Objection on draft-ietf-payload-rtp-h265-14: (with COMMENT)
>
> Barry Leiba has entered the following ballot position for
> draft-ietf-payload-rtp-h265-14: 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-payload-rtp-h265/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 1. Section 1.1 is hugely long, and I wonder why it's necessary.  Can someone really skip the HEVC reference because you've included all this?
> Is it really worth including all this, when people who need to know it should be getting it from the proper HEVC documents?
>
> 2. In Section 7.1, the media-type registration template has a tremendously long "optional parameters" section.  I strongly suggest that you move all that text into another subsection, and refer to it in the template, like this:
>
> NEW
>    OPTIONAL parameters:
>       profile-space, tier-flag, profile-id, profile-compatibility-
>       indicator, interop-constraints, and level-id.  See
>       Section <whatever> of RFC XXXX for details.
> END
>
> IANA will keep the template and make it available, and it's not intended to have such an extended technical exposition in it.  That belongs in the reference document only.
>
>