Subject: [MMUSIC] Comments draft-andreasen-mmusic-sdp-capability-negotiation-reqts-00

From: "Even, Roni" <[email-masked]>
Date: Tue, 12 Dec 2006 17:11:00 +0200

Hi,
I find the draft representing a good statement of the requirements and
current state.
 
Some comments and nits
 
1. In the abstarct I think that the profile negotiation is just an
example of the problem we are trying to solve so maybe add 
"SDP and its current extensions however do not have, for example, "

2. In the introduction "Such restrictions are not generally acceptable
to conversional multimedia session " I added conversional.

3. You need to add reference to RFC 3264 in the introduction.

4. In the introduction you mention that the answerer may reduce the set
of actual configuration but it gets more complicated since the offerer
may reduce the set again to preevent a change without signaling and now
the original offer is not valid so the answerer cannot change any mode.

5.  In the introduction "2. Review relevant existing work in the are of
SDP capability "  change are to area

6. In 3.1 second line "two or" missing more

7. About the security consideartion. I assume that if you offer
alternative you should know what it means. Otherwise do not offer
alternatives.

Roni

 

 

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

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 17 Dec 2006 17:57:37 -0500

> 3. You need to add reference to RFC 3264 in the introduction.
Fixed.

> 4. In the introduction you mention that the answerer may reduce the 
> set of actual configuration but it gets more complicated since the 
> offerer may reduce the set again to preevent a change without 
> signaling and now the original offer is not valid so the answerer 
> cannot change any mode.
>
>
I'm not sure I follow - the answerer is free to initiate a new 
offer/answer exchange at any point (provided there is not one in 
progress already).

>  
>
> 5.  In the introduction "2. Review relevant existing work in the are 
> of SDP capability "  change are to area
>
>  
>
Fixed.

> alternative you should know what it means. Otherwise do not offer 
Knowing what it means and having thought through the security risks as 
well as possible ways of mitigating those risks are two different things 
though. I think we will need to do a bit more work in this area, at 
least when it comes to the solution (if we don't, I'm sure our ADs will 
ask us to). For now, the question is whether we need specific security 
requirements for the capability negotiation solution itself or not.

Thanks for the comments

-- Flemming

> Roni
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>  
>
>------------------------------------------------------------------------
>