[AVTCORE] Re: Mahesh Jethanandani's Discuss on draft-ietf-avtcore-rtp-jpegxs-3ed-03: (with DISCUSS and COMMENT)

[Tim Bruylants <[e-mail]>]

Dear Mahesh and IESG,

In a follow up on the open last DISCUSS and open last COMMENT from Mahesh Jethanandani, I would like to

Regarding the DISCUSS in the timestamp field in section 4.2, we modified the text to the following:
"If the sampling instant does not correspond to an integer value of the clock, the value SHALL be set to the smallest integer greater than the sampling instant, with no ambiguity."
We believe this is unambiguous and an improvement on any of the previous versions.

Regarding the COMMENT, we added PsF to the abbreviations and created a PsF paragraph in section 3.4 to state that PsF packetization follows interlaced packetization. This should make it clear that 10 or 11 for the I-bits has to be used.

Finally, I issued a -05 version of the document that updates the Security section to better reflect modern practices (result of the feedback by Deb Cooley). We believe it represents a significant improvement.

As such, we kindly ask you to take the time to provide any further feedback.

Kind regards,
Tim Bruylants.


From: Tim Bruylants <[e-mail]>
Date: Tuesday, 18 August 2026 at 16:10
To: Mahesh Jethanandani <[e-mail]>; The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: Mahesh Jethanandani's Discuss on draft-ietf-avtcore-rtp-jpegxs-3ed-03: (with DISCUSS and COMMENT)

Hi Mahesh and IESG,

Thank you for the thorough review. We have uploaded revision -04 to
address these comments. Please see our point-by-point responses below (all prepended by [Authors]).

Best regards,
Tim Bruylants (on behalf of the authors)


From: Mahesh Jethanandani via Datatracker <[e-mail]>
Date: Tuesday, 7 July 2026 at 23:50
To: The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Mahesh Jethanandani's Discuss on draft-ietf-avtcore-rtp-jpegxs-3ed-03: (with DISCUSS and COMMENT)

Mahesh Jethanandani has entered the following ballot position for
draft-ietf-avtcore-rtp-jpegxs-3ed-03: 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:
----------------------------------------------------------------------

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

[Authors] Actually, ceil(x) is defined as the smallest integer larger than x. Even though this sounds contradicting maybe at first, it is the proper definition. Maybe to clarify: “...the value SHALL be rounded up to the smallest integer larger than the sampling instant”. Thus, I do not see a contradiction here, but using a more precise language may help.

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

[Authors] In porting RFC9134 to this draft, the word “truncated” was replaced by “rounded up” (leaving the rest of the paragraph unchanged) after a comment was made (not sure by whom, in 2025). The comment was that “truncate” means throwing away the fractional part of a number. However, the number must also become the next integer (meaning the integer one larger than the result of truncation). So the combination of “truncate” and “next integer” was ambiguous, or at least causing confusion. But, after reading this comment, we agree that the overall message is still ambiguous.

[Authors] So, to avoid a language discussion, the text was updated to say: “If the sampling instant does not correspond to an integer value of the clock, the value SHALL be set to the smallest integer greater than the sampling instant, with no ambiguity.” We hope this is clear and unambiguous.


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


Section 7.1, Optional parameters, "interlace" and "segmented":

1025 >       interlace:  If this parameter name is present, it indicates that
1026 >          the video is interlaced, or that the video is Progressive
1027 >          segmented Frame (PsF).  If this parameter name is not present,
1028 >          the progressive video format SHALL be assumed.
1029 >
1030 >       segmented:  If this parameter name is present, and the interlace
1031 >          parameter name is also present, then the video is a Progressive
1032 >          segmented Frame (PsF).  Signaling of this parameter without the
1033 >          interlace parameter is forbidden.

Progressive segmented Frame (PsF) is introduced here as something a sender can
negotiate via SDP, but I could not find it mentioned anywhere else in the
document — not in the terminology of Section 2, not in the packetization
description of Section 4.1, and not in the Interlaced information (I) field
description of Section 4.3, which only defines values for progressive (00) and
the two fields of an interlaced frame (10/11). Structurally, a PsF frame is a
full progressive frame, not two picture segments each covering half the frame
height, so it's not obvious to me whether I=00 is the correct payload-header
setting for PsF content, or whether some other treatment is intended. I
checked, and this gap is inherited unchanged from RFC 9134, so it's not
something -03 introduced. But given that this revision otherwise goes out of
its way to add clarifications for implementers (Section 11 lists several), I'd
suggest the authors take the opportunity to either add a sentence tying PsF
signaling to a specific I-field/packetization treatment, or note explicitly
that PsF is only an SDP-level declaration with no distinct RTP-level handling.

[Authors] Indeed, PsF should be clarified while we are reworking the RFC. We added PsF to the abbreviations. We added a PsF paragraph in section 3.4 to state that PsF packetization follows interlaced packetization. This should make it clear that 10 or 11 for the I-bits has to be used. Can you please check if this is now clear and well defined? Thank you.

----------------------------------------------------------------------
NIT
----------------------------------------------------------------------

All comments below are about very minor potential issues that you may
choose to address in some way - or ignore - as you see fit. Some were
flagged by automated tools (via
https://github.com/larseggert/ietf-reviewtool) so there will likely
be some false positives. There is no need to let me know what you did
with these suggestions.

Section 3.4, JPEG XS frame and picture segment:

344 >    In the case of a progressive video stream, each JPEG XS frame
345 >    consists of one single JPEG XS picture segment.

s/one single JPEG XS picture segment/a single JPEG XS picture segment/

[Authors] We agree. Modified as requested.