[AVT] RE: Comments on draft-ietf-avt-mime-h224-02.txt

["Even, Roni" <[e-mail]>]

Magnus,
Thanks for going over the document.
In line 
Roni

-----Original Message-----
From: Magnus Westerlund [mailto:[e-mail]] 
Sent: Monday, June 27, 2005 3:43 PM
To: Even, Roni; IETF AVT WG
Subject: Comments on draft-ietf-avt-mime-h224-02.txt

Hi Roni,

I have some comments on the draft:

1. First, it is quite irritating that the draft lacks the correct page
break markers.

Roni: I am using xmk2rfc so it is a bit strange, can you show me an
example.

2. Section 1, Introduction

I think the introduction could be clarified to better explain:
- The media type is for H.224 over RTP, with packetization according to
Annex Q of H.323.
- FECC is the only real usage of H.224, however the protocol is not
limited to FECC.

Roni: I tried to make it short based on Colin's comment. But I can make
it more in line with you comment.

Another comment is that media type registrations are done to not be
limited to SDP. However other protocols like SDP-NG or FOO would need to
specify a mapping. Therefore I have some problems with the usage of
SDP-based. However I do not have a better proposal.

Roni: I assume that this is a general comment applicable to all medi
type registration. So if there is are guidelinesI would follow them.

Due to this I would prefer to have some attempt to improve the
introduction for clarity.


3. On a number of places there is missing spaces between the text and
the brackets ([ or ]) for the references.

Roni: OK, so the right way is with space. 

4. Section 4. I think you should clarify that this registration is also
in accordance with RFC 3555.

Roni: I will do it, does this apply to all media type registerations?

5. I am missing the "Restrictions on usage:"
entry. I would suggest that you use the following text:

         This media type depends on RTP framing, and hence is only
         defined for transfer via RTP [3]. Transport within other
framing
         protocols is not defined at this time.

Roni: OK

6. The encoding consideration should be clarified to indicate what type
of data this is. Again I think the following text would be appropriate
to add.

         This media type is framed (see section 4.8 in [31]) and
         partially contains binary data.

Roni: OK

7. Section 5. First bullet:
"The media name in the "m=" line of SDP MUST be application.  The
    transport SHOULD be RTP and the payload type is dynamic."

I have two questions here. First is why it is only a SHOULD in regards
to RTP. To me this media type is defined for RTP only and can with
defined transport only be used with RTP. Usage of another transport than
RTP would require explicit signalling. Secondly wouldn't it be better to
discuss also profiles? There should be no limitations when it comes to
profiles, but as it is the combination of RTP and profile etc it might
be appropriate to mention this.

Roni: I will change to SHALL. As for the profile I can only refer to
current profiles, I will add a sentence like "any applicable RTP profile
(e.g., [RFC3551])"

8. Section 5, third bullet:
The clock rate in the "a=rtpmap" line MUST be 0.

Here I see a serious problem. RTP needs an clock rate, 0 is not a valid
value here. Is there a clock rate defined when using annex Q or is it
media dependent.

Roni: Thanks, the default in annex Q is 4800, I will fix it.

9. Section 6, first paragraph.
    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [RFC3550].

I prefer the extended sentence that discusses profiles also:

    RTP packets using the payload format defined in this specification
    are subject to the security considerations discussed in the RTP
    specification [RFC3550] and any applicable profile, e.g. RFC 3551 or
    RFC 3711.

Roni: OK

10. Section 6. I am missing a discussion on the security sensitivity of
the H.224 content of the RTP packets. As H.224 contains a negotiation
protocol it seems it would be very sensitive to attacks. Also rouge
control of the camera may need to be discussed. I think this should be
used as motivation for using authentication and integrity protection.

Roni: OK

11. Section 7. I think it might be best if all the MIME registration
related references are informal: RFC 3555, RFC 2048 and Freed's draft.

OK


Cheers

Magnus Westerlund

Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]

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