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

["Murray S. Kucherawy" <[e-mail]>]

Although the DISCUSS has cleared (and thanks for making that happen), does
the WG have anything in response to the comments left in the ballot
position?

-MSK

On Tue, Jul 20, 2021 at 8:26 AM Zaheduzzaman Sarker via Datatracker <
[e-mail]> wrote:

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