On 3 Mar 2008, at 22:32, Brian E Carpenter wrote: > 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.
The authors can clarify, but the intent is explicitly that implementers of draft-ietf-avt-rtp-jpeg2000 do not need to read, understand, reference, or implement draft-ietf-avt-rtp-jpeg2000-beam (reference [11]). The opposite is not true, of course, and the -beam draft explicitly builds on this. > " 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? See draft-perkins-avt-srtp-not-mandatory-00.txt for an initial attempt to answer that question. RTP is intentionally designed to support a range of security mechanisms, and it's not appropriate for the draft to mandate any single solution. -- Colin Perkins http://csperkins.org/ _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
