RE: Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt

Black_David@emc.com Tue, 24 June 2008 20:13 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E713A6A95; Tue, 24 Jun 2008 13:13:48 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 22F8228C10B; Tue, 24 Jun 2008 09:09:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fE7G5+nmKnzv; Tue, 24 Jun 2008 09:09:07 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id B25903A6A60; Tue, 24 Jun 2008 09:09:07 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m5OG91mH018508 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 Jun 2008 12:09:02 -0400 (EDT)
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Tue, 24 Jun 2008 11:47:52 -0400
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m5OG8hFG027842; Tue, 24 Jun 2008 12:08:54 -0400 (EDT)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jun 2008 12:08:53 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt
Date: Tue, 24 Jun 2008 12:08:52 -0400
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F6489@CORPUSMX20A.corp.emc.com>
In-Reply-To: <486066D2.5080202@sm.sony.co.jp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt
Thread-Index: AcjVqQYkywnBP/AQSUe3cmdi8u3fxwAahC5A
References: <8CC6CEAB44F131478D3A7B429ECACD91016F6414@CORPUSMX20A.corp.emc.com> <486066D2.5080202@sm.sony.co.jp>
To: satosi-f@sm.sony.co.jp
X-OriginalArrivalTime: 24 Jun 2008 16:08:53.0691 (UTC) FILETIME=[992248B0:01C8D614]
X-Tablus-Inspected: yes
X-Tablus-Classifications: public
X-Tablus-Action: allow
X-Mailman-Approved-At: Tue, 24 Jun 2008 13:13:47 -0700
Cc: fluffy@cisco.com, tom.taylor@rogers.com, ietf@ietf.org, gen-art@ietf.org, avt@ietf.org, Black_David@emc.com, itakura@sm.sony.co.jp, andrew@ualberta.net, csp@csperkins.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Futemma-san,

The proposed new version of the draft looks ok to me - it has dealt
with all of the concerns in the Gen-ART review.  I have one comment
on the changes.

The second paragraph of Section 8 now recommends clearing the
saved mh_id (and I would think also the saved header) if the
decoder detects an inconsistency between the header and payload.
It would be useful to repeat that recommendation in Section 4.2
(so that all of the situations in which the receiver should
clear saved information are explained in that section) with
a recommendation to see Section 8 for more explanation. 

Thanks,
--David

> -----Original Message-----
> From: Satoshi Futemma [mailto:satosi-f@sm.sony.co.jp] 
> Sent: Monday, June 23, 2008 11:16 PM
> To: Black, David
> Cc: gen-art@ietf.org; andrew@ualberta.net; 
> itakura@sm.sony.co.jp; ietf@ietf.org; avt@ietf.org; 
> fluffy@cisco.com; csp@csperkins.org; roni.even@polycom.co.il; 
> tom.taylor@rogers.com
> Subject: Re: Gen-ART review of draft-ietf-avt-rtp-jpeg2000-beam-10.txt
> 
> Dear,
> 
> An attachment is the changes of draft-ietf-avt-rtp-jpeg2000-beam
> we propose.
> 
> The changes are:
> 
>    - The abstract became more clear and added RFC editor note.
>    - added the algorithm to calculate priority value of progression
>      based order in "Section 3.2"
>    - the media type "video/jpeg2000" eppeared in "Section 5" and
>      "Section 7".
>    - Changed the last sentence in "8. Security Section"
> 
> If they are ok, I will submit the document.
> 
> Best Regards,
> 
> Futemma
> 
> 
> Black_David@emc.com 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 wait for direction from your document shepherd 
> > or AD before posting a new version of the draft. 
> > 
> > Document: draft-ietf-avt-rtp-jpeg2000-beam-10.txt
> > Reviewer: David Black
> > Review Date: 16 June 2008
> > IESG Telechat date: 19 June 2008
> > 
> > Summary:
> > 
> > This draft is on the right track, but has open issues,
> > described in the review.
> > 
> > Comments:
> > 
> > The authors have only partially addressed the open issues noted in
> > the Gen-ART review of the -09 version.  More work is needed:
> > 
> > [1] The review of the -09 version stated: "Section 3.2 
> doesn't provide
> > enough
> > information to calculate a packet priority value from 
> layer, resolution
> > and
> > component values.  In fact the example it gives appears to be simple
> > enough
> > to also be an example of the component based ordering 
> defined in Section
> > 3.5.
> > Section 3.2 needs to explain how the priority value is 
> calculated and
> > use a
> > more complex example to illustrate the results of the calculation."
> > 
> > In my opinion, Section 3.2, while improved, is still not 
> clear enough to
> > be interoperably implemented in its current form.
> > 
> > A more complex example is now used, but the text does not state the
> > the algorithm used to generate the priority, nor does it provide the
> > specific algorithm for the example.
> > 
> > The general algorithm is that the ordering is based on the triple
> > <layer, resolution, component> and the minimum priority is 1, so, if
> > 	- There are ltotal layers (layer value range is 0 to ltotal-1)
> > 	- There are rtotal resolutions (resolution value range is 0 to
> > rtotal-1)
> > 	- There are ctotal components (component value range is 0 to
> > ctotal-1)
> > then for a triple <lval, rval, cval>, 
> > 	- priority = 1 + cval + (ctotal*rval) + (ctotal*rtotal*lval)
> > and for the example where ltotal=1, rtotal=2 and ctotal=3,
> > 	- priority = 1 + cval + 3*rval
> > because lval=0 hence the  ctotal*rtotal*lval  term is zero (3*2*0)
> > and hence does not contribute to the priority computation.
> > 
> > [2] The review of the -09 version stated "Section 4.1 contains this
> > problematic text:
> > 
> >    An initial value of mh_id MUST be selected randomly 
> between 1 and 7
> >    for security reasons."
> > 
> > This has been partially addressed.  While section 2.1 now 
> requires that
> > the initial value of mh_id always be zero, the above 
> "problematic text"
> > remains, and still needs to be removed from Section 4.1.
> > 
> > In addition, Security Considerations paragraph on mh_id 
> concludes with
> > a rather cryptic statement that "Care should be taken to prevent
> > implementation bugs with potential security consequences."  Either
> > more specific guidance should be given, or the entire 
> paragraph should
> > be removed, as mh_id does not appear to have any security value.
> > 
> > In addition, there is a new open issue:
> > 
> > [3] Section 7 does not appear to instruct IANA on what is 
> to be done.
> > It appears that IANA should add the new parameters in section 5 to
> > the existing registration of a media type, but neither section 5
> > nor section 7 tells IANA what do to or which media type registration
> > is to be modified.
> > 
> > Nits:
> > 
> > Reference [1] has still not been corrected.  The Gen-ART review of
> > the -09 version stated:
> > 
> >   Reference [1] should reference the Internet Draft by name.
> >    [1]  Futemma, "RTP Payload Format for JPEG 2000 Video Streams",
> >         RFC XXXY, April 2007.
> >   I believe this is draft-ietf-avt-rtp-jpeg2000-18.txt.  That should
> >   be in the reference instead of RFC XXXY.  Then add an RFC Editor
> >   note asking the RFC Editor to replace all instances of RFC XXXY
> >   with the RFC number assigned when reference [1] is published as an
> > RFC.
> > 
> > The version of this draft has now advanced to -19.
> > 
> > idnits 2.08.04 flagged reference [1] as a possible problem,
> > and was confused by reference [3].  Reference [3] is fine as-is;
> > no change is needed.
> > 
> > ----------------------------------------------------
> > David L. Black, Distinguished Engineer
> > EMC Corporation, 176 South St., Hopkinton, MA  01748
> > +1 (508) 293-7953             FAX: +1 (508) 293-7786
> > black_david@emc.com        Mobile: +1 (978) 394-7754
> > ----------------------------------------------------
> > 
> 
> -- 
> Satoshi Futemma, Ph.D. / satosi-f@sm.sony.co.jp
> 
> Network Software Development Dept.,
> Common Technology Div., Technology Development Group,
> Sony Corporation
> 5-1-12 Kitashinagawa Shinagawa-ku, Tokyo, 141-0001 Japan
> Tel. +81-3-5448-3175 / fax. +81-3-5448-6438
> 
_______________________________________________
IETF mailing list
IETF@ietf.org
https://www.ietf.org/mailman/listinfo/ietf