Subject: [AVT] Re: Comments on draft-ietf-rtp-jpeg2000-10

From: Andrew Leung <[email-masked]>
Date: Thu, 24 Aug 2006 23:27:37 +0900

Hi Magnus,

I know you're not AVT Chair anymore, but what is the current situation 
of our draft? More comments? revisions needed? We would like to see this 
through to RFC.

Regards,
andrew

Magnus Westerlund wrote:

> Hi,
>
> I have reviewed the draft and have a few comments on it. With the 
> exception of the Offer/Answer and security consideration sections I 
> think the text is basically ready for a WGLC. The rest of the comments 
> are minor details.
>
> 1. Section 1:
> "JPEG 2000 supports many powerful features that are not supported in
>    the current JPEG standard [1] & [9]:"
>
> This usage of reference seems at least to me to imply that the old 
> JPEG standard are in reference 1 and 9, while these are for JPEG2k. 
> Can you please correct this to be less confusing.
>
> 2. Section 3. Here is both RFC XXX and RFC XXXX used. Please use a 
> single one. Also you will need a RFC editor Note that explains that 
> RFC XXXX is referring to the future RFC number 
> draft-ietf-avt-rtp-jpeg2000-beam will receive. I would recommend to 
> add that not in Section 1.1 after the current text:
>
> RFC-Editor Note: The RFC Editor is requested to replace all 
> occurrences of RFC XXXX with the RFC number 
> draft-ietf-avt-rtp-jpeg2000-beam receives. At that time please remove 
> this note.
>
> 3. Section 4.2: mh_id field specification:
>
> I think a reference to RFC XXXX is in order in this section.
>
> 4. Section 4.2,priority field: Also here a reference to RFC XXXX seems 
> to be in order.
>
> 5. Section 5: Please replace the use of MIME with only Media Type. The 
> media types defined for RTP payload formats are not used in MIME 
> unless they are doubly defined. This distinction is also clarified by 
> RFC 4288. I know this is hard to remember, we have very long called 
> them MIME types despite the fact that MIME is a protocol that utilizes 
> Media types.
>
> 6. Section 6. Lets do a bit of surgery on this section.
> a) First the third and forth paragraph should be moved to its own 
> section Congestion Control.
>
> b) In the first paragraph I would propose the following wording change 
> from:
>    Data
>    compression used with this payload format is applied end-to-end,
>    encryption may be performed on the compressed data so there is no
>    conflict between the two operations.
> to:
>    Data
>    compression used with this payload format is applied end-to-end, any
>    encryption is performed on the compressed data so there is no
>    conflict between the two operations.
>
> We have previously received comments on this wording that data 
> compression must happen prior to encryption or the compression doesn't 
> work.
>
> However I think one could extend on this to be more complete covering 
> all the three issues of confidentiality, integrity and source 
> authentication.
>
> I have written the below paragraph as a proposal text to be used in 
> future payload formats. It still hasn't received any review by a 
> Security AD. However at least it consider all the issues and comments 
> that has been raised in the last year or two on the security 
> consideration section.
>
>    RTP packets using the payload format defined in this specification
>    are subject to the security considerations discussed in the RTP
>    specification [4], and in any applicable RTP profile.  The main
>    security considerations for the RTP packet carrying the RTP payload
>    format defined within this memo are confidentiality, integrity and
>    source authentecy.  Confidentiality is achieved by encryption of the
>    RTP payload.  Integrity of the RTP packets through suitable
>    cryptographic integrity protection mechanism.  Cryptographic system
>    may also allow the authentication of the source of the payload.  A
>    suitable security mechanism for this RTP payload format should
>    provide confidentialtiy, integrity protection and at least source
>    authentication capable of determining if an RTP packet is from a
>    member of the RTP session or not.
>
>    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 [RFC3711] is recommended.  Other mechanism that may
>    be used are IPsec [RFC4301] and TLS [RFC2246] (RTP over TCP), but
>    also other alternatives may exist.
>
>
> c) The last paragraph can be removed. In my opinion it is not relevant 
> as a security issue for RTP payload format. It is something that 
> applies for host implementations in general. In addition it is wrong 
> as there is no need for a future IGMP version for doing this. IGMPv3 
> supports this.
>
> d) Regarding the second paragraph. The statement as currently written 
> is a open statement that does not explain or not if it applies to 
> JPEG2000. If JPEG2000 do have significant non-uniformity, then please 
> change the paragraph to state that. If it doesn't please remove this 
> paragraph.
>
>
> 6. Section 7.1: I can't remember if this has been discussed before. Is 
> it at all possible to add more color sampling spaces to JPEG-2000? In 
> that case the sampling parameter should define a registry for its 
> color samplings and specify extension rules.
>
> 7. Section 7.1: Please replace the current encoding consideration with:
> "This media type is framed and binary, see section 4.8 in RFC4288
>    [RFC4288]."
>
> 8. Section 7.1: Please add Restriction on usage after Intended usage:
>
> "   Restrictions on usage:
>
>    This media type depends on RTP framing, and hence is only defined for
>    transfer via RTP [RFC3550].  Transport within other framing protocols
>    is not defined at this time."
>
> 9. Section 7.2: For the optional parameters. Either include all 
> parameters in the enumeration or use something to indicate that the 
> listed ones are examples.
>
> 10. Section 8. This offer/answer section will unfortunately not make 
> anyone any favor. The only two rule that makes sense is the that both 
> height and width needs to be specified and that unknown options are 
> not put into the answer. However the height width rule belong in my 
> opinion with the parameter definition itself.
>
> I unfortunately know to little about the JPEG2000 codec to write a 
> good offer/answer section. But lets ask a few questions about the 
> parameters.
>
> - To me it seems likely that you will use the same color sampling in 
> all directions of a session. Thus the color sampling should be a 
> parameter that is offered and then accepted or not.
>
> - The width and heigth seem to be declarative as they are maximum 
> values. Thus all side can declare their maximum values. One might 
> consider if they should not be changed in multicast, but otherwise any 
> value represents the largest value that one accept in the receiver 
> direction.
>
> - Interlace also seems to be a parameter that should be uses 
> symmetrically in the session. But here I am less certain and some 
> consideration on what the effect would be of using interlaced in one 
> direction and not the other would be appreciated. Please consider 
> multiparty conferencing and multicast sessions.
>
> 11. In section A.1: Please put in some kind of separator, like ":" 
> between label and the descriptive text.
>
> 12. Section A.2: I think there should be a space between the data 
> lengths and the word "bytes" for better readability.
>
> 13. Is Andrew's contact information really correct. It indicates that 
> he is still associated with Sony, while he has another email address.
>
> If you are unsure of something please ask me what I mean. Also don't 
> take this suggestions as the law. But if you are of other opinion 
> please motivate.
>
> Cheers
>
> Magnus Westerlund
>
> Multimedia Technologies, Ericsson Research EAB/TVA/A
> ----------------------------------------------------------------------
> Ericsson AB                | Phone +46 8 4048287
> Torshamsgatan 23           | Fax   +46 8 7575550
> S-164 80 Stockholm, Sweden | mailto: [email-masked]
>

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt