[AVTCORE] Mohamed Boucadair's Discuss on draft-ietf-avtcore-rtp-jpegxs-3ed-02: (with DISCUSS and COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-avtcore-rtp-jpegxs-3ed-02: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-jpegxs-3ed/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# Set: bits can be set to 1 or 0

OLD:
      The T bit is set to indicate that packets are sent sequentially by
      the transmitter.

NEW:
      The T bit is set to 1 to indicate that packets are sent sequentially by
      the transmitter.

OLD:  The K bit is set to indicate which packetization mode is used.

NEW: The K bit is set to 1 to indicate which packetization mode is used.

OLD:
      The L bit is set to indicate the last packet of a packetization
      unit.

NEW:
      The L bit is set to 1 to indicate the last packet of a packetization
      unit.

OLD: the L bit is set whenever the M bit is set.

NEW: the L bit is set to 1 whenever the M bit is set to 1.

(alternatively, you can have a note in the terminology section that says that
"set" means "set to 1").

# Strengthen the behavior?

CURRENT:
   In addition, [RFC8083] is an update to [RFC3550] that defines
   criteria for when one is required to stop sending RTP Packet Streams
   and which can be used for relevant applications.

   Finally, [RFC8085] provides additional information on the best
   practices for applying congestion control to UDP streams.

Both 8083 and 8085 are cited as normative but how these are called out in the
text a bit loose.

If the current wording is maintained, I think these two RFCs should be then
listed as Informative.

# You may consider adding an appendix that lists the changes vs. RFC9143

Cheers,
Med