# Éric Vyncke INT AD comments for draft-ietf-avtcore-rtp-jpegxs-3ed-03
CC @evyncke

Thank you for the work put into this document.

Please find below some blocking DISCUSS points (easy to address), some non-blocking COMMENT points/nits (replies would be appreciated even if only for my own education).

I hope that this review helps to improve the document,

Regards,

-éric

Note: this ballot comments follow the Markdown syntax of https://github.com/mnot/ietf-comments/tree/main, i.e., they can be processed by a tool to create github issues.

## DISCUSS (blocking)

As noted in https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, a DISCUSS ballot is a request to have a discussion on the points below; I really think that the document would be improved with a change here, but can be convinced otherwise.

### Section 4.4

Why not a "MUST NOT" in `Moreover, any changed value in the boxes SHOULD NOT violate any restrictions imposed by the application layer.` ?

See also https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ requiring guidance for the use of SHOULD (e.g., "else the receiver won't be able to decode").

### Section 5

Beside the ambiguous use of "SHOULD" in `In such a case, the session description SHOULD signal the compliance with the media type parameter TP.` how can this compliance be signaled ? If described in this I-D or in another reference, then add a normative reference to it.

### Section 6

Even if semi-obvious, please explain what will happen if the 2 "SHOULD" in this section are not followed.

### Section 7.1

This section also contains several BCP14 "SHOULD" that could probably be "MUST".

I have a single DISCUSS which should be simple to fix.

ection 4.2, RTP Header Usage, Timestamp field:

534 >    used.  If the sampling instant does not correspond to an integer
535 >    value of the clock, the value SHALL be rounded up to the next
536 >    lowest integer, with no ambiguity.

This sentence is self-contradictory as written: "rounded up" means the value moves to the next *highest* integer, while "the next lowest integer" means the opposite. Taken literally, a compliant implementation cannot satisfy both instructions at once, which is a strange result for a sentence that ends by asserting "with no ambiguity."

I compared this against RFC 9134, which this document obsoletes. RFC 9134 Section 4.2 says the value "SHALL be truncated to the next lowest integer, with no ambiguity" — a clear, internally consistent statement (truncation and "next lowest integer" agree). It looks to me like "truncated" was changed to "rounded up" somewhere in the revision process while "next lowest integer" was left untouched, producing the contradiction.

I would ask the authors to restore consistency here, e.g. by reverting to "truncated to the next lowest integer" (or otherwise picking one direction and matching the wording to it).

Hi Tim, Thomas, Corentin, and Antonin, 

Thank you for the effort put into this specification. Appreciate in particular the operational considerations section and the discussion on backward compatibility.

I used https://author-tools.ietf.org/diff?doc_1=RFC9134&doc_2=draft-ietf-avtcore-rtp-jpegxs-3ed&wdiff=1 for my review.

Please find below some points for DISCUSSion:

# 21122-1 ISO/IEC

ISO/IEC 21122-1:2024 - Information technology — JPEG XS low-latency lightweight image coding system — Part 1: Core coding system indicates that it has an amendment (https://www.iso.org/standard/85247.html#amendment) on slice synchronous metadata. 

## I don’t have access to the ISO/IEC specs that are listed in the document, so I can’t assess whether this amendment impacts any part of this spec. Can we please clarify?

## BTW, can we please refer to an explicit version of the spec: ISO/IEC 21122-1:2024?

# Compliance/SMPTE2110-21

CURRENT:
   In order to facilitate proper synchronization between senders and
   receivers, it is RECOMMENDED to implement traffic shaping and
   delivery timing in accordance with the Network Compatibility Model
   compliance definitions specified in [SMPTE2110-21].  In such a case,
   the session description SHALL signal the compliance with the media
   type parameter TP.

I’m afraid assessing this compliance requires [SMPTE2110-21], which makes it normative.

# Class of services

CURRENT: 
   Accordingly, if best-effort service is being used, users of this
   payload format SHALL monitor packet loss to ensure that the packet
   loss rate is within acceptable parameters.  

   If enhanced service is being used,
   receivers SHOULD monitor packet loss to ensure that the service that
   was requested is actually being delivered.

## I don’t understand the rationale that led to these SHALL/SHOULD behaviors. 

## If we have to put a requirement, I would intuitively intervert the SHALL/SHOULD above as there are no guarantees for the BE class, while there might be for other classes. 

## Similar to how this same point was addressed in a https://author-tools.ietf.org/iddiff?url1=draft-ietf-avtcore-rtp-v3c-15&url2=draft-ietf-avtcore-rtp-v3c-16&difftype=--html, a simple fix would to have the SHALL monitor for all traffic users without any restriction on the class of service.

# Ambiguity; 

CURRENT:
   If it is not, then they
   SHOULD assume that they are receiving best-effort service and behave
   accordingly.

It is not clear what “is not” in the text above. Is this is when no “enhanced service is being used”? but in that case you already have a MUST …

Please clarify. Thanks.

# BT* 

CURRRENT:
         Signals utilizing the non-constant luminance Y'C'B C'R signal
         format of [BT601-7], [BT709-6], [BT2020-2], or [BT2100-2] SHALL
         use the appropriate one of the following values for the Media
         Type Parameter "sampling":

         …

         Signals utilizing the Constant Luminance Y'C C'BC C'RC signal
         format of [BT2020-2] SHALL use the appropriate one of the
         following values for the Media Type Parameter "sampling":

         ..
         Signals utilizing the constant intensity I CT CP signal format
         of [BT2100-2] SHALL use the appropriate one of the following
         values for the Media Type Parameter "sampling":
         …
         Signals utilizing the [BT2100-2] colorimetry SHOULD also signal
         the representational range using the optional parameter RANGE
         ..

These formats are normative for these SHALL/SHOULD. Unless I’m missing something, these need to be fixed.