[payload] Pos-Dir last call review for draft-ietf-payload-rtp-vc2hq-05

Nevil Brownlee <n.brownlee@auckland.ac.nz> Sat, 12 May 2018 02:55 UTC

To: "ops-dir@ietf.org" <ops-dir@ietf.org>, draft-ietf-payload-rtp-vc2hq.all@ietf.org, payload@ietf.org
From: Nevil Brownlee <n.brownlee@auckland.ac.nz>
Message-ID: <88bea593-3697-9626-4f20-953f8f428f41@auckland.ac.nz>
Date: Sat, 12 May 2018 14:54:34 +1200
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/uGSBKJ-jd7-V8VQ86v8qfImbbpU>
Subject: [payload] Pos-Dir last call review for draft-ietf-payload-rtp-vc2hq-05
Precedence: list

Reviewer: Nevil Brownlee
Review Result:  Ready

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written with the intent of improving the operational
aspects of the IETF drafts. Comments that are not addressed in last call may 
be included in AD reviews during the IESG review.  Document editors and WG
chairs should treat these comments just like any other last call comments.

    "This memo describes an RTP Payload format for the High Quality (HQ)
    profile of SMPTE Standard ST 2042-1 known as VC-2.  This document
    describes the transport of HQ Profile VC-2 in RTP packets and has
    applications for low-complexity, high-bandwidth streaming of both
    lossless and lossy compressed video."

This draft simply describes in detail the way in which a stream of VC-2
information must be carried ina stream of RTP packets.  It's well-written,
with sufficient detail to allow for inter-operating implementations.
It's Security Considerations are clear.  As with all documents of this
kind, operators will need to be sure that the implementations of this
kind of RTP stream do conform to this draft's eventual RFC.

I noticed a few slightly puzzling things:

Section 4.1 Payload Type says that the PT is "A dynamically allocated
   payload type field that designates the payload as VC-2 coded video."
   Given that it's dynamically allocated, how does a  VC-2 receiver know
   what value has been allocated for PT?

Section 4.4 has two lists of acceptable Parse Code values. but those
   sentences end with 'and'.  Should that really be 'or', indicating
   that any of the listed values of allowed?

Cheers, Nevil

-- 
--------------------------------------------------
  Nevil Brownlee                    Computer Science Department | ITS
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand

[payload] Pos-Dir last call review for draft-ietf… Nevil Brownlee
Re: [payload] Pos-Dir last call review for draft-… Roni Even