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

[Satoshi Futemma <[e-mail]>]

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


[e-mail] 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
> [phone]             FAX: [phone]
> [e-mail]        Mobile: [phone]
> ----------------------------------------------------
> 

-- 
Satoshi Futemma, Ph.D. / [e-mail]

Network Software Development Dept.,
Common Technology Div., Technology Development Group,
Sony Corporation
5-1-12 Kitashinagawa Shinagawa-ku, Tokyo, 141-0001 Japan
Tel. [phone] / fax. [phone]

_______________________________________________
IETF mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf