Subject: [MMUSIC] RE: SDP Capability Negotiation

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Feb 2007 13:11:20 +0000

Flemming,
 
Given the requirement for a general purpose capability negotiation
framework, then this seems a reasonable solution. I still maintain it is
overkill for best effort SRTP negotiation, but I am prepared to support it
if we can get it moving forward very quickly. If we can't achieve consensus
at the Prague meeting that it is ready for WGLC, I would wish to reconsider
Hadriel's alternative.
 
Some comments on 03:
 
1. Section 1, 2nd bullet "A set of potential configurations indicating which
of those capabilities can be used for the session" - Can we include the word
"combination", e.g. "A set of potential configurations indicating which
combinations of those capabilities can be used for the session"
 
2. Section 1, 3rd bullet. Does it really provide "A set of actual
configurations"? I thought it just provided a single actual configuration,
selected from the set of potential configurations.
 
3. Section 3.1 "Two new attributes to support versioning and extensions ..."
Now that the version attribute has gone, should we remove "versioning"?
 
4. Section 3.1 - there is no point in listing the supported or required base
- this can be implied simply by the presence of a=csup / a=creq.
 
5. Section 3.1, "A new attribute ("a=acap") that defines how to list
attribute parameter values.." In fact it contains complete attributes or
attribute values, not attribute parameter values.
 
6. Section 3.1 "A new attribute ("a=acfg") to be used in an answer SDP. The
attribute identifies which of the potential configurations from an offer
were used as actual configurations..." Should it be "was used as the actual
configuration"? Surely you can select only one.
 
7. Section 3.1 "Potential configurations are always preferred over actual
configurations..." I find this confusing, because the example offer to which
it refers does not have an a=acfg attribute. We should use a different term
to express what is indicated by the "regular" transport and attributes. In
fact in lots of places in the document I think the term "actual
configuration" is used with different meanings.
 
8. Section 3.2.1. I don't see the need for the cap-v0 option tag - isn't it
implied by the presence of a=csup/creq? What is the meaning of receiving
a=csup/creq without the cap-v0 option tag?
 
9. Section 3.2.2 - the first paragraph could be replaced by a reference to
3.2.1 for the meaning of option tags.
 
10. Section 3.4.2 states "The actual configuration attribute identifies
which of the potential  configurations from an offer SDP were used as actual
configurations..." Again this seems to suggest multiple actual
configurations, but the meaning of this is not given. As I understand it,
there are multiple capabilities in an actual configuration, but only one
actual configuration.
 
11. Section 3.5.2 says that attributes from a potential configuration are
added to the regular attributes. This could result in two attributes of the
same type, e.g., two a=crypto lines. What happens in this case?
 
12. Section 3.5.2, last paragraph. Again I have trouble with the term actual
configuration. It is not clear whether this refers to the regular
configuration in the offer or in the answer (the latter corresponding to the
actual configuration indicated by the a=acfg line).
 
13. In the same paragraph there seems to be a contradiction. The MUST NOT
sentence seems to be contradicted by the subsequent MAY sentence. Again I
think this is because of ambiguity in the term "actual configuration". I
think what it is trying to say is that you MUST NOT send media in accordance
with the m-line in the offer if you have selected a potential configuration,
but instead you MAY send media in accordance with the a=acfg line in the
answer.
 
14. Do we need to make any statements about asymmetrical
(direction-sensitive) attributes? I am thinking here of things like
a=sendonly and a=rcvonly. If you have an a=acap:1 a=sendonly line, and this
is used by a potential configuration that gets selected as the actual
configuration by the answerer, then if the answerer promotes the sendonly
attribute to a regular a=sendonly line in the answer, then this is clearly
wrong (but a=rcvonly would be correct). I don't have any practical use cases
for using this, so perhaps we just need to exclude this type of attribute
from use in a=acap lines.
 
15. There are some very long sections in the draft. Is it not possible to
break some of them up into sub-sections so that specific aspects can be
referenced more easily?
 
John

  _____  

From: Flemming Andreasen [mailto:[email-masked]] 
Sent: 20 February 2007 20:59
To: Elwell, John 
Cc: Francois Audet; Hadriel Kaplan; Flemming Andreasen
Subject: SDP Capability Negotiation [Was Re: test (Nortel filter problem)]

Elwell, John wrote: 

Yes, I share Francois' concerns. I appreciate the efforts the design team
has put in over the last few weeks to simplify the solution compared with
the earlier proposal. If we had nothing at all, I guess the current proposal
would be reasonable. But given the variety of existing implementations of
best effort SRTP, it is hard to see how quickly the MMUSIC solution will
gain traction in the market.

That's fine - there's nothing the IETF can do about that. What I'm looking
for at this stage is feedback of the form "yes, this looks like a decent
solution, and legacy pre-standard deployment issues aside, this is the path
we should try and head down", or "no, this is terrible, there is no way in
h... I'm ever going to look at this useless piece of s... again". More
constructive comments somewhere in between those two will of course be
welcome as well :-). Basically, the goal here is to get as close as possible
to WG consensus before Prague, and since you are all significant
stakeholders, I'm looking for any feedback you may have at this point that
will bring us closer to that goal. 

-- Flemming 

John

  _____  

From: Francois Audet [mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: 20 February 2007 18:06
To: Flemming Andreasen
Cc: Hadriel Kaplan; Elwell, John
Subject: RE: test (Nortel filter problem)

Our spam filter is completely useless. It filters more good emails than bad
ones.
 
Can you send the email that keeps getting bounced to [email-masked]
<mailto:[email-masked]> ?
Along with a description of the problem, i.e., that you need to send it to
me and that it keeps getting bounced?
 
I'll take a look at the two documents again.
 
Here is my main question:

*	What timing do we expect for publication as an RFC? 

I'm ok with the content, I guess, although I'm a bit worried about
complexity.
 
I am also very worried about how to handle the plethora of "pre-standard"
implemenatations of best-effort security out there. And since the timing for
the "standard" solution is very bad, it will get worst. I do not think that
we can hide our heads in the sand. I believe the following mechnanisms are
out there and have to be reckoned with:

*	Multiple c lines, one with AVP the other with SAVP 

*	with port overloading 

*	without port overloading 

*	Use of crypto/kmgmt without SAVP profile 

*	return of crypto/kmgmt in Answer means SRTP 

*	Sometimes based on a=encryption:optional tag 

  _____  

From: Flemming Andreasen [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, February 20, 2007 09:14
To: Audet, Francois (SC100:3055)
Subject: Re: test (Nortel filter problem)

well that surely is weird - I'm trying to send you another e-mail which the
Nortel mail filters keep bouncing. Let me try and cut and paste here without
including any URLs:

Hi Francois and Hadriel 

We've been doing a bunch of work on the SDP Capability Negotiation stuff
since the last IETF, and I believe we are at a point where the core document
is fairly solid (still need to add a few more examples). The goal is to try
and get consensus around the document in Prague and then move to WGLC after
that. To facitilitate that, it would be very helpful if both of you can
review the current document (preferably before Sunday 2/25/07) and let us
know if you have any major (or minor) issues with it. Please send any
comments you may have to the MMUSIC list. 

Thanks. 

-- Flemming 

PS: Latest document can be obtained from <see e-mail on MMUSIC list>

Francois Audet wrote: 

Yep. 

-----Original Message-----

From: Flemming Andreasen [mailto:[email-masked]
<mailto:[email-masked]> ] 

Sent: Tuesday, February 20, 2007 08:00

To: Audet, Francois (SC100:3055)

Subject: test (Nortel filter problem)

let me know if you got this

-- Flemming

  

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

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Feb 2007 15:00:31 -0500

Thanks for the review and comments John

Responses below.....

Elwell, John wrote:
> framework, then this seems a reasonable solution. I still maintain it 
> is overkill for best effort SRTP negotiation, but I am prepared to 
> support it if we can get it moving forward very quickly. If we can't 
> achieve consensus at the Prague meeting that it is ready for WGLC, I 
> would wish to reconsider Hadriel's alternative.
>  
> Some comments on 03:
>  
> 1. Section 1, 2nd bullet "A set of potential configurations indicating 
> which of those capabilities can be used for the session" - Can we 
> include the word "combination", e.g. "A set of potential 
> configurations indicating which combinations of those capabilities can 
> be used for the session"
fixed
> configurations"? I thought it just provided a single actual 
> configuration, selected from the set of potential configurations.
changed accordingly

>  
> 3. Section 3.1 "Two new attributes to support versioning and 
> extensions ..." Now that the version attribute has gone, should we 
> remove "versioning"?
>
removed
> 4. Section 3.1 - there is no point in listing the supported or 
> required base - this can be implied simply by the presence of a=csup / 
> a=creq.
>
You could have a rule like that, but what does it then mean when say 
"cap-v1" is included in a "a=csup" ? Would "cap-v0" be supported as well 
? I suppose that would be up to the definition of "cap-v1", but let's 
say "cap-v1" is not 100% backwards compatible, how would the offerer 
then indicate that it supports both "cap-v0" and "cap-v1" operation ? 
With the current definitions, we could have a "creq" attribute listing 
"cap-v0", and then a "csup" attribute listing "cap-v1" - the rules for 
"v1" could then say that you can "upgrade" to using "v1" operation. A 
"v1" compliant endpoint could do that, whereas a "v0" compliant endpoint 
would just continue with the "v0" operation.

If we infer "v0" support by presence of certain attributes instead (I'd 
prefer the "pcfg" attribute since that would then allow for omitting the 
"csup" and "creq" attributes in the best-effort SRTP case today), then 
we can easily do something similar, however what about the case where 
the offerer supports only "v1" operation ? We would now need to include 
a "creq=cap-v1" attribute, but I suppose that's fine: We don't have to 
pay the price until (if) v1 actually comes along.

I'll wait for others to chime in here, since the current solution was 
agreed to by the design team, but it seems ok to me (we still need the 
option tag but don't have to require its use in an offer that supports 
"v0" or other independent extensions only).

> attribute parameter values.." In fact it contains complete attributes 
> or attribute values, not attribute parameter values.
>
reworded

> 6. Section 3.1 "A new attribute ("a=acfg") to be used in an answer 
> SDP. The attribute identifies which of the potential configurations 
> from an offer were used as actual configurations..." Should it be "was 
> used as the actual configuration"? Surely you can select only one.
>
reworded - there can be multiple of these attributes in an answer SDP, 
but only one at the session level and one per media description.

> 7. Section 3.1 "Potential configurations are always preferred over 
> actual configurations..." I find this confusing, because the example 
> offer to which it refers does not have an a=acfg attribute. We should 
> use a different term to express what is indicated by the "regular" 
> transport and attributes. In fact in lots of places in the document I 
> think the term "actual configuration" is used with different meanings.
>
I don't believe so - can you provides some examples of where you see 
such inconsistencies ?  The use of the term "actual configuration" to 
reference what is in the offerered "m=" line, etc. is both deliberate 
and in line with the overall use of this term (AFAIK), so I would prefer 
not to have two different terms here.

The reason for having the "actual configuration" attribute ("acfg") is 
because the answerer may use a different configuration from the offer 
than what was actually included as the actual configuration in the 
offer, and the offerer needs to know about that in order to process both 
the answer and incoming media correctly. Thus, the "selected 
configuration" from the offer is now what the offerer needs to use as 
the actual configuration (combined with the answer).

In any case, I've rephrased the above referenced sentence slightly to 
try and make it clearer.

> 8. Section 3.2.1. I don't see the need for the cap-v0 option tag - 
> isn't it implied by the presence of a=csup/creq? What is the meaning 
> of receiving a=csup/creq without the cap-v0 option tag?
See answer to 4) above.

> 9. Section 3.2.2 - the first paragraph could be replaced by a 
> reference to 3.2.1 for the meaning of option tags.
>
ok

> 10. Section 3.4.2 states "The actual configuration attribute 
> identifies which of the potential  configurations from an offer SDP 
> were used as actual configurations..." Again this seems to suggest 
> multiple actual configurations, but the meaning of this is not given. 
> As I understand it, there are multiple capabilities in an actual 
> configuration, but only one actual configuration.
reworded.

>  
> 11. Section 3.5.2 says that attributes from a potential configuration 
> are added to the regular attributes. This could result in two 
> attributes of the same type, e.g., two a=crypto lines. What happens in 
> this case?
sdescriptions (RFC 4568) has rules for dealing with this; you simply 
pick one (based on the order in the resulting SDP). It brings up a good 
point though, namely how the answerer conceptually constructs the 
"viewed" offer SDP; I've added some additional rules saying potential 
configuration attributes are to be added before the originally provided 
attributes, and in the order specified by the potential configuration.
>  
> 12. Section 3.5.2, last paragraph. Again I have trouble with the term 
> actual configuration. It is not clear whether this refers to the 
> regular configuration in the offer or in the answer (the latter 
> corresponding to the actual configuration indicated by the a=acfg line).
I've tried rephrasing slightly to hopefully make it clearer.

>  
> 13. In the same paragraph there seems to be a contradiction. The MUST 
> NOT sentence seems to be contradicted by the subsequent MAY sentence. 
> Again I think this is because of ambiguity in the term "actual 
> configuration". I think what it is trying to say is that you MUST NOT 
> send media in accordance with the m-line in the offer if you have 
> selected a potential configuration, but instead you MAY send media in 
> accordance with the a=acfg line in the answer.
I don't see a contradiction in that paragraph, however I've tried to 
rephrase slightly to make it clearer.

> a=sendonly and a=rcvonly. If you have an a=acap:1 a=sendonly line, and 
> this is used by a potential configuration that gets selected as the 
> actual configuration by the answerer, then if the answerer promotes 
> the sendonly attribute to a regular a=sendonly line in the answer, 
> then this is clearly wrong (but a=rcvonly would be correct).
Agreed.

> I don't have any practical use cases for using this, so perhaps we 
> just need to exclude this type of attribute from use in a=acap lines.
I'm not following this part - why can direction attributes not be 
provided in acap lines ? Conversely, it sounds to me like you want us to 
outlaw something that is already forbidden by the existing o/a 
procedures (as supplemented by the procedures here) ?

>  
> 15. There are some very long sections in the draft. Is it not possible 
> to break some of them up into sub-sections so that specific aspects 
> can be referenced more easily?
>
Please let me know of any specific suggestions here (the current section 
splits seem natural to me, and, examples aside, most sections are 2 
pages or less, and only two sections are close to 4 pages long)

Thanks

-- Flemming