I'm OK with the -19 version, and I will leave the security question to the security experts.
Thanks Brian On 2008-03-20 10:04, Brian E Carpenter wrote: > Hi Colin, > > On 2008-03-20 07:54, Colin Perkins wrote: >> 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. > > OK, I understand the intent. Indeed there are no normative keywords > attached to the references to [11]. What confused me was the > phrase "Please consult RFC XXXX [11]", which made me think there was > a dependency. I think the paragraph including that sentence repeats > what is in the clearly informational text at the beginning of > section 3. > >>> " 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. > > Fair enough, but you may find yourselves having that discussion with > the security ADs. So I still suggest making the text more explicit > on that point (or adding a reference). > > Brian > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
