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

Ben Campbell <ben@nostrum.com> Thu, 05 April 2018 20:52 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 40E5512D7EC; Thu, 5 Apr 2018 13:52:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] 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 BInJxk1kWycY; Thu, 5 Apr 2018 13:52:07 -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 0FA4512D7E8; Thu, 5 Apr 2018 13:52:07 -0700 (PDT)
Received: from [10.0.1.91] (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 w35Kq3BM003367 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Apr 2018 15:52:04 -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.91]
From: Ben Campbell <ben@nostrum.com>
Message-Id: <2A8CBF26-3D91-4B52-956E-F79E9126F438@nostrum.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_5D226CF5-5B8F-4E51-937B-A591E4F16E12"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
Date: Thu, 05 Apr 2018 15:52:02 -0500
In-Reply-To: <48814733-6800-4BAD-9AA8-0AF67A28B550@bbc.co.uk>
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>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/YYEVKnObwkoaLhR0lPx387rmj9o>
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: Thu, 05 Apr 2018 20:52:10 -0000

Hi, please see inline:

> On Mar 7, 2018, at 5:00 AM, James Barrett <James.Barrett@bbc.co.uk> wrote:
> 
> On 5 Mar 2018, at 23:11, Ben Campbell <ben@nostrum.com> wrote:
>> 
>> Hi,
>> 
>> Here is my AD Evaluation of draft-ietf-payload-rtp-vc2hq-04. It???s mostly in good shape, but I do have some comments and questions. I would like to discuss at least my substantive comments before IETF LC.
>> 
>> Thanks!
>> 
>> Ben.
>> 
>> *** Substantive Comments:
>> 
>> ??4.1: ??? A Sequence Header packet SHOULD have the same timestamp as the next picture which will follow it in the stream.  An End of Sequence packet SHOULD have the same timestamp as the previous picture which appeared in the stream.???
>> 
>> Why are those SHOULDs not MUSTs? Do you envision circumstances where it might be reasonable to violate them? What are the consequences if you do?
> 
> I honestly can???t think of any real consequences for violating this, but since these packets need to have some value for timestamp it seemed reasonable to make a recommendation.

Does it need to use a SHOULD or MUST at all? Typically, we reserve BCP 14 keywords for situations that do have consequences. RFC 2119 says they should only be used in cases where they impact interoperability or otherwise cause problems when violated.

> 
>> ??4.2, definitions of I and F: Same question as for ??4.1.
> 
> Yes, these should probably be MUST.
> 

Okay

>> - Slice Prefix Bytes and Slice Size Scaler: Both contain disclaimers saying ???unlikely to be too large.??? But IIUC, there are normative requirements later in the draft that prevent them from ever being to large. If my understanding is correct, it would be helpful to clarify this here. (Otherwise reviewers may see ???unlikely to be ??? as a red flag.)
> 
> Ok, I???ll clarify that.
> 
>> - This section is inconsistent about using normative keywords for field contents. Most do, but starting with ???Fragment Length??? they are stated descriptively. For matters of definition, I am okay with either approach but it would be good to be consistent.
> 
> Ok, I???ll fix them all to use normative keywords.

Okay, but see my previous comment about BCP 14 keywords.

> 
>> ??4.4: "Every High Quality Picture Fragment MUST contain no more than 65535 slices.???
>> 
>> This seems non-constraining giving the following requirement that it must not contain over 65535 bytes.
> 
> Fair point. Maybe I should just list the bytes limit and then add the explanation ???and hence cannot contain over 65535 slices either???.

That works for me.

> 
>> ??5: ??? The circuit breakers is to be implemented and followed.???
>> Was there a reason not to use a MUST here? (also it seems like there???s a missing word after ???breakers???)
> 
> Yeah, that seems wrong.
> 
>> - ??? If used on a closed network which has been correctly provisioned for the expected data rates then profile MAY be used without congestion control, but on the open internet some sort of congestion control approach MUST be taken.???
>> 
>> That sort of statement is dangerous; code that is intended for use in private networks has a habit of escaping onto the internet. Is the code supposed to know?  Would it make sense to require implementations to default to using congestion control unless explicitly configured otherwise?
> 
> How about a change to the same sort of wording used in RFC 8130?
> 
> "Since UDP does not provide congestion control, applications that use
> RTP over UDP SHOULD implement their own congestion control above the
> UDP layer [RFC8085] and MAY also implement a transport circuit
> breaker [RFC8083].  Work in the RMCAT working group [RMCAT] describes
> the interactions and conceptual interfaces necessary between the
> application components that relate to congestion control, including
> the RTP layer, the higher-level media codec control layer, and the
> lower-level transport interface, as well as components dedicated to
> congestion control functions.”

That language would seem to contradict the previous paragraph (taken from RFC 8088).

My concern was that the original text pretty much said you can skip worrying about congestion if on a sufficiently provisioned closed network. I fear people will write code that assumes it is always on such a network. My preference would be to simply remove the sentence starting with “If used on a closed network”. If that is not acceptable, would it make sense to say that one must implement congestion control, and default to use it, but MAY allow an operator to turn it off by configuration? (Even that is likely to see close scrutiny from the transport area directors.)


> 
> 
>> *** Editorial Comments and Nits:
>> 
>> ??2: Please consider using the new boilerplate from RFC 8175. There are a few lowercase instances of ???should??? and ???must???. At least some of the ???should??? instances to not appear to be normative
> 
> Do you mean 8174? If so then yes, that makes sense.

Yes, sorry.

> 
>> ??3: " Each High Quality Fragment data unit contains either a set of parameters for a picture or a series of coded Slices.
>> 
>> Does this mean ???set of parameters for (a picture or a series of coded slices), or (set of parameters for a picture) or (a series of coded slices)?
>> 
>> Also it would be good to clarify in ??3 that only fragments are used with this payload format.
> 
> It means the latter. Yes I will reword to be clearer.
> 
>> ??4: Caption for figure 2: The text describes figure 2 as ?????? carries the Picture Fragment containing the VC-2 Transform Parameters for a Picture. It would help to mention that (perhaps in a shortened form) in the caption.
> 
> ok.
> 
>> ??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.

> 
> Should I submit a revised draft with the above changes made?

Please submit when you are ready.

Thanks!

Ben.