Subject: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item

From: Flemming Andreasen <[email-masked]>
Date: Wed, 02 Feb 2011 17:04:12 -0500

Hi

I've taken a look at

         draft-garcia-mmusic-sdp-icap-bcap-00.txt

and have a few questions and comments.

First of all, based on Jean-Francois' e-mail to the list on July 30, 
2010, it is my understanding that this draft is a WG item, so the next 
version should be submitted as "draft-ietf-mmusic...".

Secondly, here are my draft comments:

- Given the scope of the draft is now "media title" and "media 
bandwidth", I'd suggest changing the title accordingly.

- Section 1, 2nd, paragraph: Why are we talking about "k=" here ? It's 
possible to define lots of things, so why call this one out as one we 
don't ?

- Section 3.1, "The optional "+" is used to indicate that the entire 
configuration, not just the parameter, must be ignored if the parameter 
is not supported "
The wording is technically correct, but counter intuitive to the 
careless reader compared to the RFC 5939 wording. In order to avoid 
confusion, I'd suggest rephrasing it.

- Section 3.1, "Therefore, capabilities referenced by any configuration 
attribute MUST appear at the media level when a configuration is 
"converted" to a corresponding media block"
I'm not sure how to interpret this paragraph. Please elaborate/clarify text

- Section 3.1 and other places: I'd suggest we call "icap" for "media 
title" capability instead of media information, etc. for consistency 
with RFC 4566.

- Section 3.1.1, ABNF: We've limited capability numbers syntactically to 
10 digits in RFC 5939. For consistency, I'd do the same here.

- Section 3.1.1.1, first paragraph: Description of "acfg" is inaccurate 
(it does not convey potential configurations to be negotiated, but 
rather the potential configuration that was actually used for negotiation).

- Section 3.1.1.1, ABNF: 10 digit limit again and s/b-/bw-/

- Section 3.1.1.1, first paragraph after ABNF:
What does it mean to have more than one of these, and in particular, can 
there be more than one with a given bw-type ?
Also s/b-/bw-/

- Section 3.1.2: Suggest changing "Information Capability" to "Media 
Title Capability"

- Section 3.1.2, ABNF: 10 digit limit again.

- Section 3.1.2.1, first paragraph: Inaccurate description of "acfg" 
attribute (similar to above)

- Section 3.1.2.1, ABNF: Missing the optional "+" and associated 
description of it. Also, When would you have more than one media title 
in a given pcfg ? Can you give an example ? Lastly, 10 digit limit again.

- Section 3.1.2.2: May want to add a comment about use of "+" not being 
very likely either (or maybe include that as part of previous comment).

- Section 3.2, first sentence. Delete "ccap". Suggest adding the 
following to the end of the sentence: ", i.e. the capabilities they 
provide can only result in media level types and values (not session 
level)"

- Section 4: Suggest changing "at the base media level" to " within the 
media description in question " (Note: Two occurrences).

- Section ?: Missing an offer/answer section.

- Section 5: Suggest changing "Information Capability" to "Media Title 
Capability"

- Section 5.2: s/ccap/icap

- Section 6: Security considerations need to be expanded with specific 
considerations for these parameters (e.g. specific threats)

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Thu, 3 Feb 2011 10:55:46 +0000

Hello Flemming, and thanks for your detailed review.
Please see below lines marked with [SV].

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Flemming Andreasen
Sent: 03 February, 2011 00:04
To: mmusic
Cc: Simo Veikkolainen
Subject: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item

Hi 

I've taken a look at 

[SV] Incidentally, I just yesterday submitted a -01 version of the draft. However, the content was only modified to clean up some text and to remove the last remaining references to "ccap" attribute.

First of all, based on Jean-Francois' e-mail to the list on July 30, 2010, it is my understanding that this draft is a WG item, so the next version should be submitted as "draft-ietf-mmusic...". 

[SV] Ok will send the next version as WG item.

- Given the scope of the draft is now "media title" and "media bandwidth", I'd suggest changing the title accordingly. 

[SV] Changed this to "Media title and Media bandwidth Capabilities Negotiation in the SDP"

- Section 1, 2nd, paragraph: Why are we talking about "k=" here ? It's possible to define lots of things, so why call this one out as one we don't ? 

[SV] I think "k=" was mentioned there before since we mentioned that we are defining capabilities for the rest of the (meaningful) attribute lines which were not covered anywhere else. Now that "ccap" is not part of the draft anymore, I think we can also remove the text regarding "k=" lines.

- Section 3.1, "The optional "+" is used to indicate that the entire configuration, not just the parameter, must be ignored if the parameter is not supported "
The wording is technically correct, but counter intuitive to the careless reader compared to the RFC 5939 wording. In order to avoid confusion, I'd suggest rephrasing it. 

[SV] Changed this to follow RFC5939 wording: "The optional "+" is used to indicate that the extension is mandatory and MUST be supported in order to use that potential configuration."

- Section 3.1, "Therefore, capabilities referenced by any configuration attribute MUST appear at the media level when a configuration is "converted" to a corresponding media block" 
I'm not sure how to interpret this paragraph. Please elaborate/clarify text  

[SV] The intention has been to say that even though "i=" can appear either at session or media level, we are defining the "icap" attribute only for media level. I think the sentence becomes clearer by just deleting "..when a configuration is "converted" to a corresponding media block".

- Section 3.1 and other places: I'd suggest we call "icap" for "media title" capability instead of media information, etc. for consistency with RFC 4566. 

[SV] Ok.

- Section 3.1.1, ABNF: We've limited capability numbers syntactically to 10 digits in RFC 5939. For consistency, I'd do the same here. 

[SV] Changed.

- Section 3.1.1.1, first paragraph: Description of "acfg" is inaccurate (it does not convey potential configurations to be negotiated, but rather the potential configuration that was actually used for negotiation). 

[SV] Right. I removed the text "which can carry one or more potential configuration to be negotiated".

[SV] Done.

- Section 3.1.1.1, first paragraph after ABNF: 
What does it mean to have more than one of these, and in particular, can there be more than one with a given bw-type ? 
Also s/b-/bw-/

[SV] Hmm, good catch. I would assume there is only one "b=" line for each media block. Or are there cases when more than one bandwidth value would be needed? If this is the case, then also in the configuration parameters it would suffice to only have one. 

- Section 3.1.2: Suggest changing "Information Capability" to "Media Title Capability"

[SV] Changed.

[SV] Ok.

- Section 3.1.2.1, first paragraph: Inaccurate description of "acfg" attribute (similar to above)

[SV] Changed as in above (deleted the text after the comma).

- Section 3.1.2.1, ABNF: Missing the optional "+" and associated description of it. 

[SV] Here we thought that the "+" would not be needed since it is unlikely that the potential configuration should be rejected if the media title capability is not supported. Do you see this differently?

Also, When would you have more than one media title in a given pcfg ? Can you give an example ? 

[SV] I'm tempted to limit also this one to only one, unless I hear objections.

Lastly, 10 digit limit again. 

[SV] Ok.

- Section 3.1.2.2: May want to add a comment about use of "+" not being very likely either (or maybe include that as part of previous comment). 

[SV] Do we need the "+" at all? For consistency's sake I guess yes, but is there a use case?

- Section 3.2, first sentence. Delete "ccap". Suggest adding the following to the end of the sentence: ", i.e. the capabilities they provide can only result in media level types and values (not session level)" 

[SV] Done.

- Section 4: Suggest changing "at the base media level" to " within the media description in question " (Note: Two occurrences). 

[SV] Changed.

[SV] You mean a section defining the offerer and answerer behaviour like in Media capabilities draft Section 3.4? I guess we could add such a section.

- Section 5: Suggest changing "Information Capability" to "Media Title Capability"

[SV] Done.

[SV] Done.

- Section 6: Security considerations need to be expanded with specific considerations for these parameters (e.g. specific threats)

[SV] Do you have any specific examples mind?

[SV] Thanks, Simo

Thanks 

-- Flemming

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 03 Feb 2011 11:53:04 -0500

Thanks for the updates Simo. A few follow-ups below...

>
> - Section 3.1, "Therefore, capabilities referenced by any 
> configuration attribute MUST appear at the media level when a 
> configuration is "converted" to a corresponding media block"
> [SV] The intention has been to say that even though "i=" can appear 
> either at session or media level, we are defining the "icap" attribute 
> only for media level. I think the sentence becomes clearer by just 
> deleting "..when a configuration is "converted" to a corresponding 
> media block".
>
I think you should elaborate on the text so there is no confusion 
between capabilities being present at the session-level and media-level 
versus generating a configuration from a pcfg attribute present within a 
media description that references them, and hence effectively 
instantiates them at the media-level (except for session-level 
attributes, which is fraught with challenges as per RFC 5939). An 
accompanying example may help as well.

> What does it mean to have more than one of these, and in particular, 
> can there be more than one with a given bw-type ?
> Also s/b-/bw-/
>
> [SV] Hmm, good catch. I would assume there is only one "b=" line for 
> each media block. Or are there cases when more than one bandwidth 
> value would be needed? If this is the case, then also in the 
> configuration parameters it would suffice to only have one.
>
You can have different bandwidth types, so I can see where you might 
want to have more than one "b=" line per configuration, however I'm not 
sure I see how it would be useful to have different values for the same 
bw-type within a given potential configuration (which one do you pick, 
and why ?)

> description of it.
> [SV] Here we thought that the "+" would not be needed since it is 
> unlikely that the potential configuration should be rejected if the 
> media title capability is not supported. Do you see this differently?
>
Not really, but since RFC 5939 includes the "+" for extensions, and 
there doesn't seem to be any harm in allowing it here either, I would 
include it for consistency with a note that you wouldn't normally expect 
it to be used (but then again, you never know what use cases people come 
up with).

> [SV] I'm tempted to limit also this one to only one, unless I hear 
One seems right to me as well.

>
> - Section 3.1.2.2: May want to add a comment about use of "+" not 
> being very likely either (or maybe include that as part of previous 
> comment).
>
I can come up with a contrived use case if necessary, but it's not 
obvious. I'd keep it for consistency.

> [SV] You mean a section defining the offerer and answerer behaviour 
> like in Media capabilities draft Section 3.4? I guess we could add 
> such a section.
>
Sounds good.

> [SV] Do you have any specific examples mind?

Describe what happens if an attacker is able to change one or more of 
these new parameters. The bw in particular seems to be the one that 
might have some ramifications, since choice of a potential configuration 
could be affected by its expected bw usage (and hence you could launch a 
denial of service attack this way, or at least impact the service 
quality). Changing title information seems more like a nuisance, but 
still, if it's used to select between configurations (e.g. via human 
interaction), it could impact service. The mechanisms to address these 
threats are the same as in RFC 5939 I believe, however we need to ensure 
people understand the threats they are faced with.

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 11:52:03 +0000

From: ext Flemming Andreasen [mailto:[email-masked]] 
Sent: 03 February, 2011 18:53
To: Veikkolainen Simo (Nokia-MS/Helsinki)
Cc: [email-masked]
Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments and WG item

I think you should elaborate on the text so there is no confusion between capabilities being present at the session-level and media-level versus generating a configuration from a pcfg attribute present within a media description that references them, and hence effectively instantiates them at the media-level (except for session-level attributes, which is fraught with challenges as per RFC 5939). An accompanying example may help as well. 

[SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST appear only at media level. Therefore, the "icap" and "bcap" capabilities referenced by pcfg attribute are always on media level. 

Simo

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 12:40:04 +0000

Hi,
See below (again with [SV]).

---

[SV] I sent a separate email on this.

You can have different bandwidth types, so I can see where you might want to have more than one "b=" line per configuration, however I'm not sure I see how it would be useful to have different values for the same bw-type within a given potential configuration (which one do you pick, and why ?) 

[SV] Right, but now looking at RFC4566 it does not say anything about having different values for the same bwtype in the same media block. I'm not sure we should limit this either, even though I agree there might not be use it. 

[SV] Here we thought that the "+" would not be needed since it is unlikely that the potential configuration should be rejected if the media title capability is not supported. Do you see this differently?
Not really, but since RFC 5939 includes the "+" for extensions, and there doesn't seem to be any harm in allowing it here either, I would include it for consistency with a note that you wouldn't normally expect it to be used (but then again, you never know what use cases people come up with). 

[SV] Ok we can add it for consistency.

[SV] Ok.

[SV] Do we need the "+" at all? For consistency's sake I guess yes, but is there a use case?
I can come up with a contrived use case if necessary, but it's not obvious. I'd keep it for consistency. 

[SV] Ok.

[SV] Coming up in next version.

Simo

[SV] Done.

Describe what happens if an attacker is able to change one or more of these new parameters. The bw in particular seems to be the one that might have some ramifications, since choice of a potential configuration could be affected by its expected bw usage (and hence you could launch a denial of service attack this way, or at least impact the service quality). Changing title information seems more like a nuisance, but still, if it's used to select between configurations (e.g. via human interaction), it could impact service. The mechanisms to address these threats are the same as in RFC 5939 I believe, however we need to ensure people understand the threats they are faced with.  

Thanks

-- Flemming

---

From: <[email-masked]>
Date: Mon, 7 Feb 2011 13:38:01 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Veikkolainen Simo (Nokia-MS/Helsinki)
> Sent: 07 February, 2011 13:52
> To: [email-masked]
> Cc: [email-masked]
> versus generating a configuration from a pcfg attribute present within
> a media description that references them, and hence effectively
> [SV] I'm not sure I follow you. We define that "icap" and "bcap" MUST
> appear only at media level. Therefore, the "icap" and "bcap"
> capabilities referenced by pcfg attribute are always on media level.

Correcting myself. We have the following piece of text in Section 3.2:

	  The icap and bcap attributes can appear at the session
	  level and/or at the media level, but MUST be interpreted
	  as a media-level capability,

so I guess we could either do
1) declare icap and bcap as media-level only, or
2) describe in more detail in this section how session-level capability attributes should be treated.

Option 1) could be simpler to implement and understand, while 2) would provide more generality. Any opinions?

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

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Feb 2011 13:14:52 -0500

On 2/7/11 7:40 AM, [email-masked] wrote:
> between capabilities being present at the session-level and 
> media-level versus generating a configuration from a pcfg attribute 
> present within a media description that references them, and hence 
> effectively instantiates them at the media-level (except for 
> session-level attributes, which is fraught with challenges as per RFC 
> 5939). An accompanying example may help as well.
>
ok
> want to have more than one "b=" line per configuration, however I'm 
> not sure I see how it would be useful to have different values for the 
> same bw-type within a given potential configuration (which one do you 
> pick, and why ?)
>
> [SV] Right, but now looking at RFC4566 it does not say anything about 
> having different values for the same bwtype in the same media block. 
> I'm not sure we should limit this either, even though I agree there 
> might not be use it.
>
ok - maybe just add an informative note about it then.

> include it for consistency with a note that you wouldn't normally 
> expect it to be used (but then again, you never know what use cases 
> people come up with).
>
Thanks

-- Flemming

> might have some ramifications, since choice of a potential 
> configuration could be affected by its expected bw usage (and hence 
> you could launch a denial of service attack this way, or at least 
> impact the service quality). Changing title information seems more 
> like a nuisance, but still, if it's used to select between 
> configurations (e.g. via human interaction), it could impact service. 
> The mechanisms to address these threats are the same as in RFC 5939 I 
> believe, however we need to ensure people understand the threats they 
> are faced with.
>
> Thanks
>
> -- Flemming
>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Feb 2011 13:38:21 -0500

>           as a media-level capability,
Yeah, and I suspect this was probably introduced with an eye towards the 
latent configuration mechanism defined by the media capabilities draft.

> provide more generality. Any opinions?
My understanding is that the bcap and icap attributes are specifically 
defined for the media-level only currently in the draft, but maybe it 
needs to be made clearer. It gets tricky when we mix types that can 
appear at both the session and media-level, and then start interpreting 
what they actually are, *not* based on whether they indeed are at the 
session or the media-level, but how they are referenced. The latent 
configuration attribute ("lcfg") in the media capabilities draft 
currently relies on this, however I'm not keen on it (opens up a can of 
worms). The media capabilities authors are discussing this and, assuming 
the only reason you want to allow the above is for latent 
configurations, then I think we need to settle that discussion first. 
Alternatively, you could adopt wording similar to Section 3.4.1 in RFC 
5939, which deals with the same problem for attribute capabilities (and 
basically only defines usage at the media-level, but allows for the 
media capabilities framework to extend that and define procedures above 
and beyond the media-leve only procedures defined in RFC 5939).

-- Flemming

---

From: Bob Gilman <[email-masked]>
Date: Tue, 08 Feb 2011 12:21:42 -0700

> latent configuration mechanism defined by the media capabilities draft.
[rrg]: Your suspicion is correct.  However, I think I've found a better
        way to define the latent configuration attribute that makes this
        media-level-only restriction unnecessary for these attributes, or
        for other attributes referenced by a latent configuration (except
        mcap, mfcap, or mscap attributes defined in the media cap draft.)
> and beyond the media-leve only procedures defined in RFC 5939).
[rrg]: I think it would be most flexible if we could allow a potential
        or latent configuration to select both a session-level and
        media-level bandwidths, for example, and the specification of
        RFC5939 seems easiest: session-level capabilities are declared
        at the session level, and media-level caps are declared at the
        media level.  I think this is easily accommodated in the media
        caps document by defining the lcfg attribute as a media-level
        attribute, rather than a session-level attribute.
>> > Simo

-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 08 Feb 2011 15:35:14 -0500

On 2/8/11 2:21 PM, Bob Gilman wrote:
> >> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments 
> and WG
> >> > item
> >> >
> >> > Subject: Re: [MMUSIC] draft-garcia-mmusic-sdp-icap-bcap comments 
> and WG
> >> > item
> >> >
> configuration
> >> > I'm not sure how to interpret this paragraph. Please 
> elaborate/clarify
> >> > text
> >> >
> media-level

That sounds like a good way forward. Will that still allow for latent 
media streams as well ?

Thanks

-- Flemming

---

From: Bob Gilman <[email-masked]>
Date: Tue, 08 Feb 2011 14:31:14 -0700

Flemming-
Defining the latent configuration attribute as a media-level
attribute (and treating it as if it were another m-line) allows
the lcfg attribute to refer to either session-level capabilities
or media-level capabilities (following the a=lcfg line.)
The only potential problem is if such an offer is given to an
endpoint that recognizes cap negotiation, but doesn't recognize
media caps.   If media capabilities is not required in the offer,
the unique numbering of any lcfg-referenced capabilites should
permit them to be ignored (go unused) by the answerer.  The one
thing that shouldn't be done is to place a non-capability attribute
(what we've called a "conventional attribute") after the a=lcfg
line - which could be associated with the preceding m-line media
block if media caps is not recognized or required.  At some point,
it would be desirable to have a capability attribute for every
possible SDP line that might be associated with an lcfg attribute.
I'll try to make this more clear in the coming version of the
media capabilities document.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780