IETF Last Call Review of draft-ietf-avtcore-rtp-j2k-scl-05
review-ietf-avtcore-rtp-j2k-scl-05-genart-lc-enghardt-2025-04-25-00
Request | Review of | draft-ietf-avtcore-rtp-j2k-scl |
---|---|---|
Requested revision | No specific revision (document currently at 08) | |
Type | IETF Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2025-04-28 | |
Requested | 2025-04-14 | |
Authors | Pierre-Anthony Lemieux , David Taubman | |
I-D last updated | 2025-06-13 (Latest revision 2025-06-13) | |
Completed reviews |
Secdir IETF Last Call review of -05
by Wes Hardaker
(diff)
Genart IETF Last Call review of -05 by Reese Enghardt (diff) |
|
Assignment | Reviewer | Reese Enghardt |
State | Completed | |
Request | IETF Last Call review on draft-ietf-avtcore-rtp-j2k-scl by General Area Review Team (Gen-ART) Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/gen-art/jKQBYiicIwb4EjjkhOebTJt-ypQ | |
Reviewed revision | 05 (document currently at 08) | |
Result | Ready w/nits | |
Completed | 2025-04-25 |
review-ietf-avtcore-rtp-j2k-scl-05-genart-lc-enghardt-2025-04-25-00
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-avtcore-rtp-j2k-scl-05 Reviewer: Reese Enghardt Review Date: 2025-04-25 IETF LC End Date: 2025-04-28 IESG Telechat date: Not scheduled for a telechat Summary: The document is clear and concise, and it is ready for publication as Proposed Standard. Below are a few suggestions to make the document easier to understand and potentially more consistent. Major issues: None. Minor issues: Intro: "the payload format includes the following features specifically designed for streaming applications" Does "streaming applications" mean specifically Live streaming? If so, please consider being more specific here. In addition, please consider adding a bit more context on why these features such as sub-codestream latency are necessary and useful for use cases beyond prior RFCs. Similarly, what is preferable about JPEG2000 for the intended use cases, rather than using other options? Please consider adding a sentence or two. Section 3: "JPEG 2000 represents an image as one or more components, e.g., R, G and B, each uniformly sampled on a common rectangular reference grid." Please consider providing a definition for component. Assuming that, for example, "R" means only the red compontent of an image, does the above sentence imply that an image could be only one component, e.g., only R, on a grid? "The coded image data ultimately consists of code-blocks, each containing coded samples belonging to a rectangular (spatial) region within one resolution level of one component." Please consider providing a definition for resolution level. "Resolution Layer (R) The information needed to reconstruct the lower spatial resolutions of the image come before the information needed to reconstruct the higher spatial resolutions of the image" Is a resolution layer the same as a resolution level? If so, please consider unifying the terminology here. Section 5: This section references a "SOD marker", while Section 3 mentiones a "SOT marker". Is this intentional, and if so, what is the difference between SOD and SOT markers? The "SOT marker" also appears in Section 5.3, whereas the "SOD marker" only appears in section 5.1. "When concatenated, the sequence of JPEG 2000 codestream fragments emitted by the sender MUST be a sequence of JPEG 2000 codestreams where two successive JPEG 2000 codestreams MAY be separated by one or more arbitrary padding bytes (see Figure 1)." In the "Packets" in Figure 1, is each component delineated as "Main" or "Body" a single packet, or is it a sequence of packets? Does packet still mean RTP packet here? Please consider stating this explicitly when describing the figure. "A JPEG 2000 codestream fragment does not necessarily contain complete JPEG 2000 packets, as defined in [jpeg2000-1]." Is a JPEG 2000 packet different from an RTP packet? If so, how? Please consider defining a JPEG 2000 packet. Section 9: Is it intentional to provide the registry information in this section, rather than under "IANA Considerations" where many IETF readers would expect it? Please consider moving it under "IANA Considerations". Nits/editorial comments: None.