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

From: Magnus Westerlund <[email-masked]>
Date: Mon, 06 Feb 2006 18:21:00 +0100

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