Subject: [MMUSIC] Comments on draft-ietf-mmusic-sdescriptions-00.txt

From: Magnus Westerlund <[email-masked]>
Date: Sun, 16 Mar 2003 17:45:09 +0100

Hi,

I have a a number of comments on this draft.

1. The short copyright statement are missing on the title page.

2. I am missing a chapter that clearly explains what one must define and 
think of if defining extensions to the framework defined by this draft. 
One thing I don't think the draft has considered sufficiently in form of 
how the text is written is how to adapt it to other profiles. First one 
mentions using this for non RTP transports, secondly it seems obvious 
that we should in the near future define the combination of AVPF and SAVP.

3. Chapter 2.0: I find the usage of sub chapter 0 a bit strange. I am 
definitely used to having 2, 2.1 or 2.1.1 type of difference between 
chapter levels.

4. Chapter 2.0 The second paragraph: Introduction chapter are normally 
informative and therefore one avoids all normative language. But this 
contain a normative SHOULD.

5. Section 4.1 Crypto suites for SRTP. I think this section is badly 
written it could be much clearer. To my eyes it looks like any crypto 
suite must contain a certain number of parameters. These parameters 
should be defined and explained. Then each definition can contain a note 
on usage and a table with the values. Last the defining new crypto suit 
then is a piece of cake as it simple requires any defined crypto suit to 
define values for all parameters. Last it should also define that there 
is a repository with IANA for crypto suits and that they should be 
registered.

6. Section 4.2: What is the reasons that one must have SRTP even if one 
is only receiving media streams and only sends SRTCP? Please provide 
motivation.

7. Section 4.3.2 second paragraph: I think it is a bit unclear when one 
uses right as telling which bytes to truncate. I would think that using 
end or last bytes is better. Also the inclusion of little end here is a 
bit strange. Where is this defined? It is not a term that I normally 
encounter. If you are going to use it it should be defined in the terms 
section.

8. Section 4.3.2 third paragraph || is defined. please put this also in 
a the definitions section.

9. Section 4.4.1: This section does not take into account that a single 
sender/issuer may use multiple SSRCs. This case needs to be handled as 
it is for example one that can result from employing RTP retransmission 
with SSRC-multiplexing.

10. Section 4.4.2: Isn't each ROC connected to a SSRC. Shouldn't they be 
bound together and allowed to exist in multiple cases to handle comment 9.

11. Section 5.0:  I know that you defines a new attributes for SRTP. 
However if one runs a totally defaulted session is it still impossible 
to use the k= attribute? I have understanding that a more competent way 
is needed.

12. Section 5.1: First sentence: "On each SDP media line (m=) where the 
<transport> is "RTP/SAVP", the offerer MAY follow that media line with 
at least one a=crypto line." Two things. First I think using better 
terms on how a line is included in the SDP should be used. Secondly the 
I think one should be as clear as possible about if one or more is 
allowed. From my view one or more is clearer than at least, of course 
context must be considered. However my proposal would be: "Each media 
description that on its m= lines has a transport parameter of 
"RTP/SAVP"  MAY contain one or more a=crypto line."

13. Section 5.2 first paragraph: I think you have an offer answer error 
here. Media streams must be included in the answer independently if one 
is accepting or not, unless the whole session is refused. So the last 
otherwise seems to be wrong. A refusal of a stream would be performed by 
setting port to 0.

14. Section 5.3: I think it is badly pointed out that the offerer must 
be responsible for accepting or refusing the answered security level.

15. Section 5: What is the potentials for performing bid-downs attacks 
when using this solution. It seems dependent on the security of the SDP 
transport level.

16. Section 5.6: How does one know from which packet the new keys apply. 
The synchronization between SIP and RTP are only loose. Wouldn't there 
be need for including a a complete ROI || seq per SSRC one rekeys?

17. Section 6.2 Second paragraph: Shouldn't the SHOULD here be a SHALL? 
Any use of these attributes in a SDP that are unprotected END-to-END is 
a fatal security breach.

18. Section 7.0: I have a number of comments on the grammar:
a. The grammar should define already today how the extension mechanism 
looks. What values that are allowed when defining new usage's. For 
example "application" should allow an "app-ext" that is then defined. 
This need for extensions are also true when it comes to cipher defintions.
b. One of the defined cipher suits are missing in the grammar.
c. The SSRC/ROC must be resolved in the ABNF

19. Section 11. You are missing the IPR statement, see ID-nits.

-- 

Magnus Westerlund 

Multimedia Technologies, Ericsson Research ERA/TVA/A
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic