Subject: [MMUSIC] RE: SDP Capability Negotiation

From: "Francois Audet" <[email-masked]>
Date: Fri, 23 Feb 2007 17:50:09 -0600

> 	From: Elwell, John [mailto:[email-masked]] 
>
> 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.

Same here. I agree 100% with John.

Here are my comments:

- What do we do with RFC 3407 and RFC 3388? Are we deprecating them? 
  If not, what are the interactions of this draft with them? I think
this 
  needs to be covered. (Maybe it's as simple as saying MUST not be used 
  together: I don't know).

- Woulnd't the a=csup: cap-v0 be functionaly identical to a:creq:
cap-v0??? 
  I think they would. If that's the case, I'd like clarification of if 
  a=csup: cap-v0 is legal or or not to include (I'd say no). The fact
that 
  a-csup: cap-v0 is specifically spelled out in examples on page 10 is 
  very confusing because I can't figure out a use case. If John's point 
  about the whole cap-v0 being redundant and therefore should be
removed, 
  then it would solve the problem. 

	- Generally speaking, there are quite a few cases in the spec
where 
	  you "could include a parameter, or not". This generally leads
to 
	  interop problems unless the spec is absolutely clear on if it
is 
	  mandatory or not.

	- Similartly, there are cases where different format for the
same 
	  things can be used, also leading to uncessary complexity and
potential 
	  interop problems. For example, a single line saying "a=creq:
cap-v0, foo" 
	  or two lines "a=creq: capv0" and "a=creq: foo". I know we have
precedents
	  for this, but it seems gratuitous parsing complexity.

- Section 3.5.2.1. Why is that example there? Shouldn't it be moved into
4.2 
  (replacing the current example)? 

- Section 3.5.2.1: I see that we can have an a=pcfg line per m line.
That is 
  a bit confusing to me. Does it semantic vary depending on if it is one
per 
  m-line or one for an a-line. How would we incate the following 2
subcases: 

	- Session level MIKEY (both audio and video) OR SDES for audio
and for
	  Video, vs 

	- Session level MIKEY (both audio and video) OR SDES for audio
or for 
	  Video, but not both 

- Section 4.1: 

	- I find the second Offer/Answer in the diagram to be
distracting. 
	  I'd rather it would be omitted, and the text on page 33
describing the 
	  possibility of having a second offer/answer to "lock down" the
exchange 
	  to describe it more as an optional procedure. I.e., it should
be more 
	  clear that this is really just OPTIONAL (in fact, I think this
whole 
	  second offer/answer thing should be in a 4.1.1 subsection,
clearly 
	  labelled as an optional enhancement). 

- Section 4.2: 

	- I really don't understand what is the difference between 4.2
and 4.1. 
	  They seem identical, except that 4.2 adds an explicit "a=pcfg:
10 t=2"
	  line. If I understand the procedure correctly, this line does
absolutely 
	  nothing as it is implied from the m line anyways. 

		- I don't like this idea of having two ways to say the
same thing. 
	        I'd rather we either always explicitely list all the t
lines, or 
	        we always assume that the m line is the implicit missing
one 
 
- Here is another idea. Could we redefine cap-v0 to be "best-effort
transport 
  negotiation"? All the examples in this document are related to that
(which 
  I'm okay with). I'm a bit worried that the scope of cap-v0 is wider
than that 
  and since it is pretty vague what it would be used for, it would be an
undue 
  requirement for people who need to support the only concrete usecase
we have 
  today (i.e., best-effort SRTP/RTP?). Kind of a blank check. We could
defer to 
  cap-v1 for other applications. 

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

---

From: Flemming Andreasen <[email-masked]>
Date: Sun, 25 Feb 2007 16:04:11 -0500

Hi Francois

Thanks for the review and comments.

Please see below for responses.....

>   needs to be covered. (Maybe it's as simple as saying MUST not be used 
3407 (simcap) provides both more and less than the core SDP capability 
negotiation framework. More in terms of covering things like codecs, and 
min/max values. Less in terms of only providing capabilities; there is 
nothing related to potential configurations and their associated 
negotiation. Once you add the media capabilities extensions to the mix, 
it's a different story though. Consequenlty, the media capabilities 
draft says something about 3407, whereas this one does not (there are no 
interactions between "pure" core SDP cap neg and 3407, just a bit of 
overlap). Let me know if you think that needs to be called out (and/or 
something differently should be said).

With respect to 3388 (grouping), I don't see any overlap or interactions 
either (at least not with the core), however you can clearly define 
grouping semantics and/or SDP Capability Negotiation extensions that 
does lead to overlap. I'm not sure what to say about that in the core 
document (or that we even should be saying anything about it). Instead, 
we should be aware of this potential overlap and interactions when (if) 
defining new extensions for either, and may need to deal with them on a 
case-by-case basis. I'm pretty sure there is both a need and use for 
both though (albeit, if we were to do it all over, maybe not with all 
the currently defined grouping semantics).

>   then it would solve the problem. 
Note that the example on page 10 is merely an isolated parameter 
encoding example. Having said that, you could envision a "cap-v1" 
extension at some point, and you may have a need to indicate that you 
also support "cap-v1". Another (more immediate) example is an offer 
requiring support an extensions the answerer does not have; the answer 
will then not perform sdp capability negotiation, however the answer 
will include the "csup" attribute with a list of supporting extensions - 
"cap-v0" would be in that list.

> 	  interop problems unless the spec is absolutely clear on if it
Can you provide some specific pointers (and ideally highlight your 
concern in each case) ?

> 	  for this, but it seems gratuitous parsing complexity.
I'm open to having a single "csup" and "creq" line at the session-level 
as well as at most one per media description of you want. Are there 
other specific cases you can point to ?

>   (replacing the current example)? 
No - it is providing example text for a particular piece of answerer 
operation detailed in the section right before it. I thought that 
particular piece of text/logic could use some illustrative examples, 
however it seemed a bit much to include it right where the relevant 
answerer processing text was (not least considering John's concern about 
section length), so I put in a following sub-section for ease of 
reference. We can move it though if you prefer.

> - Section 3.5.2.1: I see that we can have an a=pcfg line per m line. That is 
>   m-line or one for an a-line. 
You can have several "pcfg" lines per "m=" line and each includes 
references to capabilities, such as transport protocol and attribute 
capabilities. You don't have a "pcfg" line "per attribute" capability 
per se.

> How would we incate the following 2
> subcases: 
>
The core framework does not enable you to express any constraints on 
inter-media description configuration selection (too complicated). You 
can specify session-level MIKEY by use of a session-level key-mgmt 
attribute capability and media-level sdescriptions by use of a 
media-level crypto-attribute for both the audio and the video stream. 
You will then have a potential configuration attribute for each media 
description listing MIKEY and sdescriptions as alternatives. However, 
the solution does not have the expressive power to require selection of 
the same mechanism by both media descriptions, or alternative 
mechanisms. Do you have a use case in mind for this ? Is this something 
you see as important for the core negotiation framework ?

> 	  labelled as an optional enhancement). 
That probably requires further discussion. It is currently at 
RECOMMENDED/SHOULD strength (specified in Section 3.5.3), whereas ICE 
has similar functionality at MUST strength (ice-13, Section 8). Can you 
elaborate on why you want this to be at OPTIONAL/MAY strength ?

> 	  nothing as it is implied from the m line anyways. 
Sorry - it's old text to be ignored (the very first line in the section 
says "[EDITOR'S NOTE: Example to be updated - old copy below]")

> 	        we always assume that the m line is the implicit missing
So, it's a bad example (hence to be updated), however there is another 
use case. Let's assume we had a third transport protocol supported, 
however it is even less preferred than the actual configuration in the 
offer. The only way we would be able to specifiy that is by explicitly 
listing it in a "pcfg" attribute; there would then be another (less 
preferred) "pcfg" attribute using the third alternative transport protocol.

>   I'm okay with). 
I'm not sure what that means or more importantly what the draft 
implications of doing that are. Can you elaborate ?

> I'm a bit worried that the scope of cap-v0 is wider
> than that 
>   today (i.e., best-effort SRTP/RTP?). 
Please see the media capabilities extensions for something else it will 
be used for. Use for other transport protocols (e.g. AVPF) is a use-case 
as well.
> Kind of a blank check. We could
> defer to 
If I understand correctly, I think this would amount to essentially 
throwing all the generality we have built-in out, and focus on solving 
the best-effort SRTP use case (plus maybe other transport protocols) 
only. That's not the guidance we got from either the AD(s) or the WG 
chairs, and it's also not what the requirements and hence current scope 
(and solution) is. I hope you are not arguing against that direction at 
this (late) point. We've tried pretty hard to focus on the core part 
that is of importance to the best-effort SRTP (and transport protocol in 
general) folks, while at the same time making it somewhat general and 
extensible so that people with additional requirements can use it as 
well (by way of defining extensions). In the process of doing that, 
there is no doubt a bit more implementation work than a "best-effort 
SRTP" only solution would incur, however we normally try and come up 
with somewhat general and reusable specifications as opposed to 
point-specific solutions. Again, we've tried pretty hard to make this 
delta as small as possible (witness the exclusion of media capabilities 
for example) while still making it generally usable. If you have 
specific suggestions for how we can better do that (and preferably have 
them specified before and agreed to in Prague), then please let us know.

Thanks

-- Flemming