Re: [Gen-art] Gen-ART LC review of draft-ietf-avt-rtp-jpeg2000-18.txt

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
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art