[AVTCORE] Zaheduzzaman Sarker's No Objection on draft-ietf-payload-rtp-jpegxs-17: (with COMMENT)

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-payload-rtp-jpegxs-17: No Objection

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/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


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



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

Thanks to the authors and Stephan Wenger for prompt action to make the ISO
specification available to us.

I have removed the discuss as the main reason for the discuss was resolved.

I however have one major issue which I think need to be addressed.

* Section 4.1 : the assertion here is that the jpeg xs produces constant
bitrate. However, now I know that this codec can operate on both constant and
variable bitrate mode. This section should clarify that when VBR mode is used
the RTP payload format still holds or not. Also it might be helpful to discuss
the two mode of operations somewhere in the introduction and state if the focus
is only on constant bitrate mode with reasoning. The will level out the scope
of the payload definition and also the impact on section 6.

And more comments:

* I can agree with Martin Duke's comment that the polymorphic use of
"end-to-end latency" need to be explained a bit.

* Section 3:  having the statement that we are describing some terminologies or
naming for this specification like it section 4 does, would help the reader to
understand the context a bit more.

* Section 3.3: I would suggest to add reference to Ppih and Plev at the first
use of them.

* Section 4.3: says --

    "If codestream packetization mode is
      used, L bit and M bit are equivalent."

   does this mean it is enough to set the M bit only in the codestream
   packetization mode?

* Section 4.3: says --
    "In the case of codestream packetization mode (K=0), this
         counter resets whenever the Packet counter resets (see
         hereunder)"

   hereunder? can we give more specific reference instead?

* Section 6: Usually when RTP is used congestion control and corresponding
required rate control is done by the RTP applications. The use of RTP AVPF
profile is the recommended profile to be used for real-time communication when
efficient rate control (nope not the video encoder rate control :-)) is needed.
Hence, I think we should recommend that use of AVPF profile here and also refer
to RFC8888. The inclusion of circuit breaker makes lot of sense here. I also
got to know that jpeg xs is designed to be used in a controller network
environment. Hence, there should be a warning about use of this in a best
effort Internet prior to the requirement on packetloss observation. If there is
any acceptable parameter defined somewhere for packet loss then that also
should be referenced here.