I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-avt-rtp-jpeg2000-18.txt Reviewer: Brian Carpenter Review Date: 2008-03-03 IETF LC End Date: 2008-03-15 IESG Telechat date: (if known) Summary: Almost ready. Comments: Is [11] really only an informative reference? " * Priority importance of the packet using methods described in RFC XXXX [11]. * Main header recovery using methods described in RFC XXXX [11]. Additional usage of the payload header is described in RFC XXXX [11]. " " mh_id (Main Header Identification) : 3 bits Main header identification value. This is used for JPEG 2000 main header recovery. For implementations following only this specification, the sender SHOULD set this value to 0 and the receiver SHOULD ignore this field on processing. Additional usage of this header is described in further detail in supplmental RFC draft: RTP Payload format for JPEG 2000: Extensions for Scalability and Main Header Recovery. Please consult RFC XXXX [11] " These look like technical dependencies to me, especially the main header recovery, since we also find "If the main header is lost, the image cannot be decoded." Even though this is an optional feature, it is still a normative dependency. " 6. Security Consideration ... Note that the appropriate mechanism to provide security to RTP and payloads following this memo may vary. It is dependent on the application, the transport, and the signalling protocol employed. Therefore a single mechanism is not sufficient, although if suitable the usage of SRTP [4] is recommended. Other mechanism that may be used are IPsec [12] and TLS [13] (RTP over TCP), but also other alternatives may exist. " I think this needs to be clearer with respect to the BCP 61 (RFC 3365) requirement. What is the required minimum security?