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

[Colin Perkins <[e-mail]>]

Thanks - that seems like a useful addition, and the other changes  
look fine to me also. Please submit, with this one extra change  
included.

Colin


On 24 Jun 2008, at 17:08, [e-mail] wrote:
> 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:[e-mail]]
>> Sent: Monday, June 23, 2008 11:16 PM
>> To: Black, David
>> Cc: [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> 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
>>
>>
>> [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]
>>



-- 
Colin Perkins
http://csperkins.org/



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