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

From: Brian E Carpenter <[email-masked]>
Date: Tue, 04 Mar 2008 11:32:19 +1300

_______________________________________________
Gen-art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/gen-art

---

From: Colin Perkins <[email-masked]>
Date: Wed, 19 Mar 2008 18:54:25 +0000

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/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 20 Mar 2008 10:04:09 +1300

Hi Colin,

On 2008-03-20 07:54, Colin Perkins wrote:
>> I have been selected as the General Area Review Team (Gen-ART) reviewer
>>       *  Main header recovery using methods described in RFC XXXX [11].
>>
>>       Main header identification value.  This is used for JPEG 2000 main
>>       header recovery.
>>
>>       For implementations following only this specification, the sender
>>       Additional usage of this header is described in further detail in
>> These look like technical dependencies to me, especially the main header
> 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.

>>    Therefore a single mechanism is not sufficient, although if suitable
> 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