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

From: Nevil Brownlee <[email-masked]>
Date: Sat, 12 May 2018 14:54:34 +1200

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

---

From: "Roni Even" <[email-masked]>
Date: Sat, 12 May 2018 08:19:52 +0300

Hi,
Thanks for the review

About section 4.1. The pt number is negotiated in the signaling , for
example using SDP see section 6.2. This is how it works for all payload type
numbers who are dynamically  allocated

m=video 30000 RTP/AVP 112
             a=rtpmap:112 vc2/90000
             a=fmtp:112 profile=HQ;version=3;level=0

the pt = 122 and it is mapped to vc2

Roni Even

> -----Original Message-----
> From: payload [mailto:[email-masked]] On Behalf Of Nevil
Brownlee
> Sent: Saturday, May 12, 2018 5:55 AM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: [payload] Pos-Dir last call review for
draft-ietf-payload-rtp-vc2hq-05
> I have reviewed this document as part of the Operational directorate's
ongoing
> effort to review all IETF documents being processed by the IESG.
> 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
with
> sufficient detail to allow for inter-operating implementations.
kind,
> operators will need to be sure that the implementations of this kind of
RTP
> stream do conform to this draft's eventual RFC.
> 
> _______________________________________________
> payload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/payload