Re: [payload] AD Evaluation of draft-ietf-payload-rtp-vc2hq-04

Ben Campbell <ben@nostrum.com> Wed, 02 May 2018 23:24 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D9A12E044; Wed, 2 May 2018 16:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.88
X-Spam-Level:
X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=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 ymagaQVl5qL7; Wed, 2 May 2018 16:24:37 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 1290812E03A; Wed, 2 May 2018 16:24:37 -0700 (PDT)
Received: from [10.0.1.86] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w42NOXhm054016 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 2 May 2018 18:24:34 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.86]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <789D1E0E-9308-4167-BB79-5A595795C744@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_34A7A4A3-3A36-43C4-841D-2FD98FCD37F9"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Wed, 02 May 2018 18:24:32 -0500
In-Reply-To: <2A8CBF26-3D91-4B52-956E-F79E9126F438@nostrum.com>
Cc: "draft-ietf-payload-rtp-vc2hq.all@ietf.org" <draft-ietf-payload-rtp-vc2hq.all@ietf.org>, "payload@ietf.org" <payload@ietf.org>
To: James Barrett <James.Barrett@bbc.co.uk>
References: <91D7A133-DB5E-4CA7-A519-A46CA6A18EA8@nostrum.com> <48814733-6800-4BAD-9AA8-0AF67A28B550@bbc.co.uk> <2A8CBF26-3D91-4B52-956E-F79E9126F438@nostrum.com>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/IWPZim4PGlMwM26mH9PBkN9U7NQ>
Subject: Re: [payload] AD Evaluation of draft-ietf-payload-rtp-vc2hq-04
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 02 May 2018 23:24:38 -0000

Hi,

Version 05 fixes most of my concerns, but does not appear to have captured the change discussed below. However, I think it’s in good enough shape for IETF last call. I will request that shortly, and the below change can be addressed along with any last call feedback.

Thanks!

Ben.

> On Apr 5, 2018, at 3:52 PM, Ben Campbell <ben@nostrum.com> wrote:
> 
>>> 
>>> ??4.4: ??? If a Sequence intended for tranmission does not conform to these restrictions then it MAY be possible to simply convert it???"
>>> 
>>> This seems like a statement of fact rather than a grant of permission. As such, it should not use the 2119 keyword.
>> 
>> Yes, how about:
>> 
>> ???Informative note: Some streams which do not meet these restrictions can be converted into streams which do without the need to reencode the encoded data simply by adjusting the distribution of slices into fragments, others cannot.???
> 
> Works for me.