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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxx        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
IETF mailing list
IETF@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]