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

[Ben Campbell <[e-mail]>]

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?

§4.2, definitions of I and F: Same question as for §4.1.

- 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.)

- 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.

§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.

§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”)

- “ 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?



*** 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.

§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.

§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.

§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.