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
