IETF Last Call Review of draft-ietf-avtcore-rtp-j2k-scl-05
review-ietf-avtcore-rtp-j2k-scl-05-secdir-lc-hardaker-2025-05-16-00

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is: ready with a few minor comments/nits

Version reviewed: -05

Overall: the document is extremely well written with less typos than I've
generally seen in most documents (especially my own).  Well done!

Comments:

- I'm less familiar with the anima work, but generally there are a lot of
acronyms that don't get an early spell-out-expansion (eg: PLM, PLT, ORDH, ORDB,
POS, PID, SOC, EOC, etc).  But maybe this is normal for anima documents?

- The biggest of the security related things I've wondered is what happens if
things like MUSTs are not followed.  For example, if the timestamp frames do
not advance at required regular intervals, what does the client get and can
that be used to mess with their results in some way?  What happens if the ESEQ
* 65536 + sequence number wraps around an int32 or int64?

- What happens to a client if the jpeg2000-scl type is sent with parameters of
width=HUGE, height=HUGE?  Is 2^32 bits really needed?  What happens if a client
ties to pre-allocate memory based on receiving this sizing requirements?

- the smallest of nits ever I think:  in appendix A, the table order is NAME
SAMP COMPS ... but the description order is NAME COMPS SAMP ...