[Gen-art] Gen-ART Last Call review of draft-ietf-payload-rtp-h265-13

Brian E Carpenter <brian.e.carpenter@gmail.com> Mon, 10 August 2015 06:37 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09A61AC3A2; Sun, 9 Aug 2015 23:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_INVITATION=-2, SPF_PASS=-0.001] autolearn=ham
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 Qh8D1kRIkU8V; Sun, 9 Aug 2015 23:37:07 -0700 (PDT)
Received: from mail-pd0-x235.google.com (mail-pd0-x235.google.com [IPv6:2607:f8b0:400e:c02::235]) (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 53AC11AC3AC; Sun, 9 Aug 2015 23:37:04 -0700 (PDT)
Received: by pdbfa8 with SMTP id fa8so27850331pdb.1; Sun, 09 Aug 2015 23:37:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=FoStTE2K5DG3Gt80NycWiQbkNNoEpXgbE+3rpPv2ZVw=; b=CVOK1vPKdNn6h7ItOnT7wzwyTgf0OFBH8sY0DZJWFGFzROZPRnhmGJ5A41mOxcdJ8c hioghdH0zYC+Xx0x0f8DLmykTaGMawroPkeVyHLaZEIrGzUE2oXJhcAQ0YW/FoVU29G/ ntKTcFJcWKNUlE9VrsESEwGkJVSF0MGuQoS8rD7B2drsr6WWoDt1Th5yetjFD+Rjs5CK SRt+OHgs+RCDkdM8jMzuEDXr4t0xpvI/DJWjFOJyRUdopZBPvgrnpwadE2u+uO/SvWUw jRsE/u5wW9pBDwVp2vwilO0H2dPtYBFpI6vttZhm15yxd/+d01M4L0ZjAHhnaf8c1+KJ rldg==
X-Received: by 10.70.1.102 with SMTP id 6mr41221787pdl.32.1439188623885; Sun, 09 Aug 2015 23:37:03 -0700 (PDT)
Received: from [172.18.222.190] ([116.84.121.234]) by smtp.gmail.com with ESMTPSA id fy6sm5707883pdb.11.2015.08.09.23.37.01 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2015 23:37:02 -0700 (PDT)
Message-ID: <55C8468A.6090109@gmail.com>
Date: Mon, 10 Aug 2015 18:36:58 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: draft-ietf-payload-rtp-h265.all@ietf.org, General Area Review Team <gen-art@ietf.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/6OHv0ZqkijxBN4qx3Sm6avlMc9U>
Subject: [Gen-art] Gen-ART Last Call review of draft-ietf-payload-rtp-h265-13
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 06:37:09 -0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-payload-rtp-h265-13.txt
Reviewer: Brian Carpenter
Review Date: 2015-08-10
IETF LC End Date: 2015-08-14
IESG Telechat date:

Summary: Almost ready
--------

Comment:
--------
This is a well written document with good explanatory text as well
as the specification material. However, a non-expert cannot effectively
review the hundreds of technical details in this document.

Note that there are four (F)RAND IPR disclosures that the shepherd
indicates are known to the WG.

Minor issues:
-------------

I recommend including the string "H.265" in the document's title, to assist
searching.

Section 3.1.1 duplicates many definitions from H.265, which is helpful for
the reader. But should the draft be specific that it depends on H.265-2013?
What happens if ITU-T updates the definitions in a future version?

(Section 7.1 Media Type Registration , page 71, and a similar
note on the previous page):

   "Informative note: depack-buf-cap indicates the maximum
    possible size of the de-packetization buffer of the
    receiver only.  When network jitter can occur, an
    appropriately sized jitter buffer has to be available as
    well."

Firstly, IMHO there is no network without jitter in the IETF world.
More seriously, "appropriately sized"  is an information-free phrase
(and an invitation to buffer bloat). It would be cleaner to say

   "Informative note: depack-buf-cap indicates the maximum
    possible size of the de-packetization buffer of the
    receiver only, without allowing for network jitter."

Nits:
-----

There are numerous uses of the phrase "has to" which in plain English
is exactly the same as "must". Have these all been checked to be sure that
none of them need to be "MUST"? There is one use of "have to" where the
same question applies.

Just to prove that I did look into the text a bit, this sentence is broken
(Section 7.1 Media Type Registration , page 61):

"The highest level (specified by max-recv-level-id) MUST be such that the
receiver is fully capable of supporting."

I think this means
"The highest level (specified by max-recv-level-id) MUST be the highest that
the receiver is fully capable of supporting."

A couple of ID-nits need attention (probably deletion):

  == Unused Reference: 'RFC6190' is defined on line 3841, but no explicit
     reference was found in the text

  == Unused Reference: 'I-D.ietf-mmusic-sdp-bundle-negotiation' is defined on
     line 3878, but no explicit reference was found in the text