Session Description Protocol (SDP) Capability Negotiation
draft-ietf-mmusic-sdp-capability-negotiation-13

[Ballot comment]
This is a very detailed document, which I really like.

3.4.2. Transport Protocol Capability Attribute

  The "tcap" attribute by itself can only specify transport protocols
  as defined by  in [RFC4566], however full specification of a
  media stream requires further qualification of the transport
  protocol by one or more media format descriptions, which themselves
  often depend on the transport protocol.  As an example, [RFC3551]
  defines the "RTP/AVP" transport for use with audio and video codecs
  (media formats), whereas [RFC4145] for example defines the "TCP"
  transport protocol which may be used to negotiate, e.g. image/t38,
  application/iptv_rtsp, etc. In a non-SDP context, some of these

Using application/iptv_rtsp example here is not good idea, because
this media type registration request is not yet approved by IESG.
There is some debate on whether it will actually be approved.

  media formats could be viewed as transports themselves (e.g. T.38)
  however in the context of SDP and SDP Capability Negotiation, they
  are not. If capability negotiation is required for such media
  formats, they MUST all either be valid under the transport protocol
  indicated in the "m=" line included for the media stream
  description, or a suitable extension must be used, e.g. SDP Media
  Capabilities [SDPMedCap].



3.3.2. Required Capability Negotiation Extensions Attribute

[...]

  A recipient that receives an SDP and does not support one or more of
  the required extensions listed in a "creq" attribute, MUST NOT

I might be confused here. Is this MUST NOT ...

  perform the SDP Capability Negotiation defined in this document. For
  non-supported extensions provided at the session-level, this implies
  that SDP Capability Negotiation MUST NOT be performed at all. For
  non-supported extensions at the media-level, this implies that SDP
  Capability Negotiation MUST NOT be performed for the media stream in
  question. 

    An entity that does not support the SDP Capability Negotiation
    framework at all, will ignore these attributes (as well as the
    other SDP Capability Negotiation attributes) and not perform any
    SDP Capability Negotiation in the first place.

  When an SDP recipient does not support one or more required SDP
  Capability Negotiation extensions listed in the option tags, the
  recipient MUST proceed as if the SDP Capability Negotiation

... the same as this MUST?

  attributes were not included in the first place, i.e. all the
  capability negotiation attributes should be ignored.  In that case,
  if the SDP recipient is an SDP answerer [RFC3264], the recipient
  SHOULD include a "csup" attribute in the resulting SDP answer
  listing the SDP Capability Negotiation extensions it actually
  supports.

[Ballot discuss]
I would like to vote "Yes" on this document, but I have 1 points I would like to clarify first:

9.2. Informative References

  [ICE]    J. Rosenberg, "Interactive Connectivity Establishment
            (ICE): A Methodology for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", work in progress,
            September 2007.

Use of this document seems to be Normative to me. In particular the whole section 3.7.

[Ballot comment]
This is a very detailed document, which I really like.

3.4.2. Transport Protocol Capability Attribute

  The "tcap" attribute by itself can only specify transport protocols
  as defined by  in [RFC4566], however full specification of a
  media stream requires further qualification of the transport
  protocol by one or more media format descriptions, which themselves
  often depend on the transport protocol.  As an example, [RFC3551]
  defines the "RTP/AVP" transport for use with audio and video codecs
  (media formats), whereas [RFC4145] for example defines the "TCP"
  transport protocol which may be used to negotiate, e.g. image/t38,
  application/iptv_rtsp, etc. In a non-SDP context, some of these

Using application/iptv_rtsp example here is not good idea, because
this media type registration request is not yet approved by IESG.
There is some debate on whether it will actually be approved.

  media formats could be viewed as transports themselves (e.g. T.38)
  however in the context of SDP and SDP Capability Negotiation, they
  are not. If capability negotiation is required for such media
  formats, they MUST all either be valid under the transport protocol
  indicated in the "m=" line included for the media stream
  description, or a suitable extension must be used, e.g. SDP Media
  Capabilities [SDPMedCap].



3.3.2. Required Capability Negotiation Extensions Attribute

[...]

  A recipient that receives an SDP and does not support one or more of
  the required extensions listed in a "creq" attribute, MUST NOT

I might be confused here. Is this MUST NOT ...

  perform the SDP Capability Negotiation defined in this document. For
  non-supported extensions provided at the session-level, this implies
  that SDP Capability Negotiation MUST NOT be performed at all. For
  non-supported extensions at the media-level, this implies that SDP
  Capability Negotiation MUST NOT be performed for the media stream in
  question. 

    An entity that does not support the SDP Capability Negotiation
    framework at all, will ignore these attributes (as well as the
    other SDP Capability Negotiation attributes) and not perform any
    SDP Capability Negotiation in the first place.

  When an SDP recipient does not support one or more required SDP
  Capability Negotiation extensions listed in the option tags, the
  recipient MUST proceed as if the SDP Capability Negotiation

... the same as this MUST?

  attributes were not included in the first place, i.e. all the
  capability negotiation attributes should be ignored.  In that case,
  if the SDP recipient is an SDP answerer [RFC3264], the recipient
  SHOULD include a "csup" attribute in the resulting SDP answer
  listing the SDP Capability Negotiation extensions it actually
  supports.

[Ballot discuss]
I would like to vote "Yes" on this document, but I have 1 points I would like to clarify first:

9.2. Informative References

  [ICE]    J. Rosenberg, "Interactive Connectivity Establishment
            (ICE): A Methodology for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", work in progress,
            September 2007.

Use of this document seems to be Normative to me. In particular there is a SHOULD about using ICE together with the capability negotiation specified in this draft (see section 3.7).

[Ballot comment]
This is a very detailed document, which I really like.

3.3.2. Required Capability Negotiation Extensions Attribute

[...]

  A recipient that receives an SDP and does not support one or more of
  the required extensions listed in a "creq" attribute, MUST NOT

I might be confused here. Is this MUST NOT ...

  perform the SDP Capability Negotiation defined in this document. For
  non-supported extensions provided at the session-level, this implies
  that SDP Capability Negotiation MUST NOT be performed at all. For
  non-supported extensions at the media-level, this implies that SDP
  Capability Negotiation MUST NOT be performed for the media stream in
  question. 

    An entity that does not support the SDP Capability Negotiation
    framework at all, will ignore these attributes (as well as the
    other SDP Capability Negotiation attributes) and not perform any
    SDP Capability Negotiation in the first place.

  When an SDP recipient does not support one or more required SDP
  Capability Negotiation extensions listed in the option tags, the
  recipient MUST proceed as if the SDP Capability Negotiation

... the same as this MUST?

  attributes were not included in the first place, i.e. all the
  capability negotiation attributes should be ignored.  In that case,
  if the SDP recipient is an SDP answerer [RFC3264], the recipient
  SHOULD include a "csup" attribute in the resulting SDP answer
  listing the SDP Capability Negotiation extensions it actually
  supports.

[Ballot discuss]
I would like to vote "Yes" on this document, but I have 1 points I would like to clarify first:

9.2. Informative References

  [ICE]    J. Rosenberg, "Interactive Connectivity Establishment
            (ICE): A Methodology for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", work in progress,
            September 2007.

Use of this document seems to be Normative to me. In particular there is a SHOULD about using ICE together with the capability negotiation specified in this draft (see section 3.9).

[Ballot comment]
This is a very detailed document, which I really like.

Some comments I have so far:

3.6.3.  Offerer Processing of the Answer

  When the offerer attempted to use SDP Capability Negotiation in the
  offer, the offerer MUST examine the answer for actual use of SDP
  Capability Negotiation. 

  For each media description where the offerer included a potential
  configuration attribute ("a=pcfg"), the offerer MUST first examine
  that media description for the presence of an actual configuration
  attribute ("a=acfg"). If an actual configuration attribute is not
  present in a media description, then the offerer MUST process the
  answer SDP for that media stream per the normal offer/answer rules
  defined in [RFC3264]. However, if one is found, the offerer MUST
  instead process the answer as follows:

  o  The actual configuration attribute specifies which of the
      potential configurations was used by the answerer to generate the
      answer for this media stream. This includes all the supported
      attribute capabilities and the transport capabilities referenced
      by the potential configuration selected, where the attribute
      capabilities have any associated delete-attributes included.
      Extension capabilities supported by the answerer are included as
      well. 

  o  The offerer MUST now process the answer in accordance with the
      rules in [RFC3264], except that it must be done as if the offer
      consisted of the selected potential configuration instead of the
      original actual configuration, including any transport protocol
      changes in the media ("m=") line(s), attributes added and deleted
      by the potential configuration at the media and session level,
      and any extensions used.

[This might be an issue with the base SDP spec, so I moved it to the COMMENT part.]

What should the offerer do if the answerer response doesn't correspond to one of the potential configurations?
If the offerer just process the received response without checking that it matches one of the potential configurations, then maybe this can be used to bypass some policy checks. I think this is an additional security consideration that needs to be discussed in the document.


3.3.2. Required Capability Negotiation Extensions Attribute

[...]

  A recipient that receives an SDP and does not support one or more of
  the required extensions listed in a "creq" attribute, MUST NOT

I might be confused here. Is this MUST NOT ...

  perform the SDP Capability Negotiation defined in this document. For
  non-supported extensions provided at the session-level, this implies
  that SDP Capability Negotiation MUST NOT be performed at all. For
  non-supported extensions at the media-level, this implies that SDP
  Capability Negotiation MUST NOT be performed for the media stream in
  question. 

    An entity that does not support the SDP Capability Negotiation
    framework at all, will ignore these attributes (as well as the
    other SDP Capability Negotiation attributes) and not perform any
    SDP Capability Negotiation in the first place.

  When an SDP recipient does not support one or more required SDP
  Capability Negotiation extensions listed in the option tags, the
  recipient MUST proceed as if the SDP Capability Negotiation

... the same as this MUST?

  attributes were not included in the first place, i.e. all the
  capability negotiation attributes should be ignored.  In that case,
  if the SDP recipient is an SDP answerer [RFC3264], the recipient
  SHOULD include a "csup" attribute in the resulting SDP answer
  listing the SDP Capability Negotiation extensions it actually
  supports. 

3.6.1. Generating the Initial Offer

[...]

  If the offerer requires support for more or extensions (besides the

I think you meant "support for one or more extensions ..."

  base protocol defined here), then the offerer MUST include one or
  more "a=creq" attributes as follows:


3.6.2. Generating the Answer

[...]

  o  If attribute capabilities are present with a delete-attributes
      session indication ("-s"), then all session-level attributes from
      the actual configuration SDP MUST be deleted in accordance with
      the procedures in Section 3.5.1. If attribute capabilities are
      present with a delete-attributes media indication ("-m"), then
      all attributes from the actual configuration SDP inside this
      media description MUST be deleted. 

"-ms" is not listed here? (It is listed in other places talking about -s and -m)

[...]

  If the answerer has exhausted all potential configurations for the
  media description, without finding a valid one that is also
  supported, then the answerer MUST process the offered media stream
  based on the actual configuration plus any session-level attributes
  added by a valid and supported potential configuration from another
  media description in the offered SDP.

This seems overly complicated.

6.2. New SDP Capability Negotiation Option Tag Registry

  The IANA is hereby requested to create a new SDP Capability
  Negotiation Option Tag registry. An IANA SDP Capability Negotiation
  option tag registration MUST be documented in an RFC in accordance
  with the [RFC5226] Specification Required policy. The RFC MUST
  provide the name of the option tag, a syntax and a semantic
  specification of any new SDP attributes and any extensions to the
  potential and actual configuration attributes provided in this
  document.

It would be useful to mention that this section talks about extensions to
"a=pcfg" and "a=acfg".

  New SDP attributes that are intended to be capabilities
  for use by the capability negotiation framework

You lost me here. Please expand this sentence to make it clearer.

  MUST adhere to the
  guidelines provided in Section 3.4.3.

[Ballot discuss]
I would like to vote "Yes" on this document, but I have 2 points (which might or might not result in changes to the document) I would like to discuss first.

Note that point 2 needs to be discussed with the rest of IESG. Please talk to your shepherding AD.

1).
9.2. Informative References

  [ICE]    J. Rosenberg, "Interactive Connectivity Establishment
            (ICE): A Methodology for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", work in progress,
            September 2007.

Use of this document seems to be Normative to me. In particular there is a SHOULD about using ICE together with the capability negotiation specified in this draft (see section 3.9).

2). In the Security Considerations section I see a recommendation to use S/MIME for securing SDP payloads in SIP. This advice is not consistent with an advice I was given by RAI Area, stating that S/MIME is not deployable in SIP.

[Ballot comment]
1) Support the suggestion to say "the SDP message" instead of
  "the SDP" when that's what's meant.

2) The last paragraph of 3.6.1 has a mixed use of "SHOULD" and "should".
  Both instances probably should be SHOULD.

3) Please double-check the last example (on page 69). There are two
  instances of a=pcfg:1 in that message (which I think is wrong).
  Also, the example of using -m makes sence for the given m=audio
  stream, but in the m=video stream the overall set of attributes
  is exactly the same after deleting and adding the rtpmap. I would
  prefer not to suggest that this is the right thing to do when you
  are not changing the description at all.

4) (Very minor) The last paragraph could be misconstrued as
  permission to "play out garbage". The intent was to say that
  the offerer might not be able to render received media correctly
  until the answer arrives. There are a few other instances of
  "playing garbage" that would be better said "playing the received
    media incorrectly".

[Ballot discuss]
1) It's not clear in the normative text (or perhaps I missed it?)
  that the attributes used for negotiation (a=acap..., or worse,
  a=creq:cap_v1 for example) are not deleted by the -s and -m
  delete-attribute indicators. (Most places where they are
  mentioned currently say something like "deletes all attribute
  lines").

2) It's not clear what it would mean to encounter
  a=acap:1 acap:2 ptime:30
  The spec should call out whether constructs like this should be
  allowed.

3) It's not clear whether or not the config-number indicated in a acfg
  line is chosen by the answerer or if the answerer has to copy that
  number from some pcfg line in an offer.

4) In section 3.4.3, if an extension does have an option tag, why isn't
  IANA registration of it mandatory?

[Ballot comment]
Section 5, paragraph 6

suggest referencing 3.11 as well as 3.1 in the discussion of DOS through inclusion
of a large number of offers...

[Ballot comment]
Minor editorial point: I think the acronym SDP is overloaded, to mean both Session Description Protocol, and a specific SDP session configuration; for example as in this text from the third paragraph in section 1:

  This offer SDP is sent to the answerer, [...]

Is there another expansion for SDP that could be included in the text to clarify this use of the acronym, or some explanation that could be given about this use of the acronym?

[Ballot comment]
section 3.3.1

  att-value        = option-tag-list
      option-tag-list  = option-tag *("," option-tag)
      option-tag        = token    ; defined in [RFC4566]

  A special base option tag with a value of "cap-v0" is defined for
  the basic SDP Capability Negotiation framework defined in this
  document. Entities can use this option tag with the "a=csup"
  attribute to indicate support for the SDP Capability Negotiation
  framework specified in this document. 

  The following examples illustrate use of the "a=csup" attribute with
  the "cap-v0" option tag and two hypothetical option tags, "foo" and
  "bar" (note the lack of white space):

      a=csup:cap-v0

      a=csup:foo

      a=csup:bar

      a=csup:cap-v0,foo,bar

This construction disallows white spaces between option tags. I think this is likely to fail. Why was spaces disallowed? At a minimum I think the "note" should be strengthen to directly say that white space are not allowed.

Section 3.4.1:

When the attribute capability contains session-level attributes, the
  "acap" attribute can only be provided at the session level.
 
Is the english in the first sentence really clear. Shouldn't it be clearer if the sentence said: When the attribute capability contain a session-level attribute, the "acap" attribute can only be provided at the session level.

Section 3.5.1:

Why isn't the handling of already present attributes in the actual configuration discussed in the overview. Now you have read a particular paragraph in section 3.5.1 until you learn about this capability.

  Each attribute configuration list can optionally begin with
  instructions for how to handle attributes that are part of the
  actual configuration SDP (i.e., the "a=" lines present in the
  original SDP). By default, such attributes will remain as part of
  the configuration in question. However, if delete-attributes
  indicates "-m", then all attribute lines within the media
  description in question will be deleted (i.e., all "a=" lines under
  the "m=" line in question). If delete-attributes indicates "-s",
  then all attribute lines at the session-level will be deleted (i.e.,
  all "a=" lines before the first "m=" line). If delete-attributes
  indicates "-ms", then all attribute lines within this media
  description ("m=" line) and all attribute lines at the session-level
  will be deleted. 

I would suggest including some overview explanation of how to handle attributes in the actual configuration that are not desired in an alternative one.

[Ballot discuss]
It is great that this is finally being request to be published. However, before allowing it to go forward I have some issues that needs discussion and resolution.

Section 3.4.1:

  Conversely, media level attributes can be provided in attribute
  capabilities at either the media level or session-level. The base
  SDP Capability Negotiation framework however only defines procedures
  for use of media-level attribute capabilities at the media level
  (extensions may define use at the session level). 
 
I found this confusing, are there any difference to say that media attributes in attribute capabilities may only be provided at media level? If you are expecting implementations to have a specific support related to this, please express that requirement clearly.


Section 3.4.1 and Section 3.4.2:

att-cap-num = 1*DIGIT ;defined in [RFC5234]

trpr-cap-num  = 1*DIGIT ;defined in [RFC5234]

Why isn't the number of digit limited, the range is limied by the text, please provide a limitation in number of digits also to avoid syntactical correct but resource exhausting attacks.

Section 3.4.2:

I fail to find any discussion about the limitation for the tcap attribute with no possibility to specify alternative format strings. That restricts any media lines tcap alternatives to protocols that has coampatible format strings, and where the content of the format string is not changed based on the protocol. This happens to be true for RTP and the profiles defined so far.

Section 3.5.1:

config-number  = 1*DIGIT ;defined in [RFC5234]

Also here should the number of digits be limited.

Section 3.5.1:

ABNF is in error, no construct | in RFC 5234 ABNF. I think / (slash) is intended here:

mo-att-cap-list      = mandatory-optional-att-cap-list |
                                    mandatory-att-cap-list |
                                      optional-att-cap-list
                                     
I would also note that not having the equal mark on the same line as the
rule name like for the "attribute-config-list" prevents it from being a rule.

  attribute-config-list
                        = "a=" [delete-attributes ":"]
                                mo-att-cap-list *(BAR mo-att-cap-list)
     
Section 3.5.1:

What about potential configurations without any attributes? And don't forget about the case when one wants to delete the actual configuration attributes but not add any new attributes. That could be the case fore transports that don't need attributes for configuration.

      attribute-config-list = "a=" [delete-attributes ":"]
                                mo-att-cap-list *(BAR mo-att-cap-list)
   
      delete-attributes = DELETE ( "m"    ; media attributes
                              / "s"    ; session attributes
                              / "ms" ) ; media and session attributes


    mo-att-cap-list      = mandatory-optional-att-cap-list |
                                    mandatory-att-cap-list |
                                      optional-att-cap-list

      mandatory-optional-att-cap-list  = mandatory-att-cap-list 
                                            "," optional-att-cap-list
      mandatory-att-cap-list          = att-cap-list
      optional-att-cap-list            = "[" att-cap-list "]"

I think allowing the empty list as a mo-att-cap-list is the simplest solution.


Section 3.6.1:

So there is consensus in the WG in killing early media?

  The above rule assumes that the offerer can determine whether
  incoming media adheres to the actual configuration offered or one of
  the potential configurations instead; this may not always be the
  case. If the offerer wants to ensure he does not play out any
  garbage, the offerer SHOULD discard all media received before the
  answer SDP is received. Conversely, if the offerer wants to avoid
  clipping, he should attempt to play any incoming media as soon as it
  is received (at the risk of playing out garbage). For further
  details, please refer to Section 3.9. 

As any combination of AVP in the actual configuration offer and SAVP or SAVPF in the potential configuration may result in garbage due to the SRTP encryption it seems that discarding media will be the norm. I just want to ensure that there is consensus on killing early media, as that has always been a hot potato and requiring support.

In relation to this I think the following text is ambigous:

3.9. Processing Media before Answer

  The offer/answer model requires an offerer to be able to receive
  media in accordance with the offer prior to receiving the answer.
  This property is retained with the SDP Capability Negotiation
  extensions defined here, but only when the actual configuration is
  selected by the answerer. If a potential configuration is chosen, it
  is permissible for the offerer to not process any media received
  before the answer is received. This may lead to clipping.

Because if the answerer may select a potential configuration that results in an offerer playing back the packets and them resulting in garbage then any mandate which can't be determined by the offerer is plain useless.

So please clarify if there is a requirement to play early media or a wish which the offerer may do what ever it want with.

Section 3.10:

"Also, the Transport Independent
  Application Specific Maximum (TIAS) bandwidth type defined in
  [RFC3890] can be used to alleviate bandwidth variability concerns
  due to different transport protocols."
 
Considering that the offer/answer behavior for TIAS is broken, I don't think this should be recommended as a remedy for the issue.

Section 6.2:

The IANA is hereby requested to create a new SDP Capability
  Negotiation Option Tag registry. An IANA SDP Capability Negotiation
  option tag registration MUST be documented in an RFC in accordance
  with the [RFC5226] Specification Required policy.
 
This text clearly has an addition to the specification required policy that requires an RFC. I wan't to confirm that this was intentional. And in that case why not use the "RFC Required" policy, or the IETF Review one. Please note, that I personally think Specification required without the "RFC" requirement being a suitable policy.

[Ballot discuss]
I would like to vote "Yes" on this document, but I have 3 points (which might or might not result in changes to the document) I would like to discuss first.
Note that point 3 needs to be discussed with the rest of IESG.

1).
3.6.3.  Offerer Processing of the Answer

  When the offerer attempted to use SDP Capability Negotiation in the
  offer, the offerer MUST examine the answer for actual use of SDP
  Capability Negotiation. 

  For each media description where the offerer included a potential
  configuration attribute ("a=pcfg"), the offerer MUST first examine
  that media description for the presence of an actual configuration
  attribute ("a=acfg"). If an actual configuration attribute is not
  present in a media description, then the offerer MUST process the
  answer SDP for that media stream per the normal offer/answer rules
  defined in [RFC3264]. However, if one is found, the offerer MUST
  instead process the answer as follows:

  o  The actual configuration attribute specifies which of the
      potential configurations was used by the answerer to generate the
      answer for this media stream. This includes all the supported
      attribute capabilities and the transport capabilities referenced
      by the potential configuration selected, where the attribute
      capabilities have any associated delete-attributes included.
      Extension capabilities supported by the answerer are included as
      well. 

  o  The offerer MUST now process the answer in accordance with the
      rules in [RFC3264], except that it must be done as if the offer
      consisted of the selected potential configuration instead of the
      original actual configuration, including any transport protocol
      changes in the media ("m=") line(s), attributes added and deleted
      by the potential configuration at the media and session level,
      and any extensions used. 

What should the offerer do if the answerer response doesn't correspond to one of the potential configurations?
If the offerer just process the received response without checking that it matches one of the potential configurations, then maybe this can be used to bypass some policy checks. I think this is an additional security consideration that needs to be discussed in the document.

2).
9.2. Informative References

  [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.

  [ICE]    J. Rosenberg, "Interactive Connectivity Establishment
            (ICE): A Methodology for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", work in progress,
            September 2007.

Use of these 2 RFCs seems to be Normative to me. In particular there is a SHOULD about using ICE together with the capability negotiation specified in this draft.

3). In the Security Considerations section I see a recommendation to use S/MIME for securing SDP payloads in SIP. This advice is not consistent with an advice I was given by RAI Area, stating that S/MIME is not deployable in SIP.

[Ballot comment]
This is a very detailed document, which I really like.


Some comments I have so far:

3.3.2. Required Capability Negotiation Extensions Attribute

[...]

  A recipient that receives an SDP and does not support one or more of
  the required extensions listed in a "creq" attribute, MUST NOT

I might be confused here. Is this MUST NOT ...

  perform the SDP Capability Negotiation defined in this document. For
  non-supported extensions provided at the session-level, this implies
  that SDP Capability Negotiation MUST NOT be performed at all. For
  non-supported extensions at the media-level, this implies that SDP
  Capability Negotiation MUST NOT be performed for the media stream in
  question. 

    An entity that does not support the SDP Capability Negotiation
    framework at all, will ignore these attributes (as well as the
    other SDP Capability Negotiation attributes) and not perform any
    SDP Capability Negotiation in the first place.

  When an SDP recipient does not support one or more required SDP
  Capability Negotiation extensions listed in the option tags, the
  recipient MUST proceed as if the SDP Capability Negotiation

... the same as this MUST?

  attributes were not included in the first place, i.e. all the
  capability negotiation attributes should be ignored.  In that case,
  if the SDP recipient is an SDP answerer [RFC3264], the recipient
  SHOULD include a "csup" attribute in the resulting SDP answer
  listing the SDP Capability Negotiation extensions it actually
  supports. 

3.5.1. Potential Configuration Attribute

[...]

  A potential configuration list is normally provided after the
  configuration number. When the potential configuration list is
  omitted, the potential configuration equals the actual
  configuration. The potential configuration list contains one or more
  of attribute, transport and extension configuration lists. A
  potential configuration may for example include attribute
  capabilities and transport capabilities, transport capabilities
  only, or some other combination of capabilities. 

So what is the meaning of "attribute capabilities with no transport capabilities"? I.e., is the transport capability required if any configuration list is provided at all?


3.5.1. Potential Configuration Attribute

[...]

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s= 
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 53456 RTP/AVPF 0 18 
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32   
        inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 
      a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF
      a=pcfg:1 t=4|3 a=1
      a=pcfg:8 t=1|2

  We have two potential configuration attributes listed here. The
  first one (and most preferred, since its configuration number is
  "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP
  (specified by the transport protocol capability numbers 4 and 3) can
  be supported with attribute capability 1 (the "crypto" attribute);
  RTP/SAVPF is preferred over RTP/SAVP since its capability number (4)
  is listed first in the preferred potential configuration. Note that
  although we have a single potential configuration attribute and
  associated handle, we have two potential configurations.

Just to confirm: a line like this:

      a=pcfg:1 t=4|3 a=1|2

would actually define 4 potential configuration, right?

3.6.1. Generating the Initial Offer

[...]

  If the offerer requires support for more or extensions (besides the

I think you meant "support for one or more extensions ..."

  base protocol defined here), then the offerer MUST include one or
  more "a=creq" attributes as follows:


3.6.2. Generating the Answer

[...]

  o  If attribute capabilities are present with a delete-attributes
      session indication ("-s"), then all session-level attributes from
      the actual configuration SDP MUST be deleted in accordance with
      the procedures in Section 3.5.1. If attribute capabilities are
      present with a delete-attributes media indication ("-m"), then
      all attributes from the actual configuration SDP inside this
      media description MUST be deleted. 

"-ms" is not listed here?

[...]

  If the answerer has exhausted all potential configurations for the
  media description, without finding a valid one that is also
  supported, then the answerer MUST process the offered media stream
  based on the actual configuration plus any session-level attributes
  added by a valid and supported potential configuration from another
  media description in the offered SDP.

This seems overly complicated.

6.2. New SDP Capability Negotiation Option Tag Registry

  The IANA is hereby requested to create a new SDP Capability
  Negotiation Option Tag registry. An IANA SDP Capability Negotiation
  option tag registration MUST be documented in an RFC in accordance
  with the [RFC5226] Specification Required policy. The RFC MUST
  provide the name of the option tag, a syntax and a semantic
  specification of any new SDP attributes and any extensions to the
  potential and actual configuration attributes provided in this
  document.

It would be useful to mention that this section talks about extensions to
"a=pcfg" and "a=acfg".

  New SDP attributes that are intended to be capabilities
  for use by the capability negotiation framework

You lost me here.

  MUST adhere to the
  guidelines provided in Section 3.4.3.

[Ballot discuss]
The Gen-ART Review by  Christian Vogt posted on 24-Oct-2008 has gone
  unanswerd.  The review says that the document is basically ready for
  publication, but it has minor issues that should be fixed before
  publication.

  The review says:

    The document on "SDP Capability Negotiation" is very well written
    and should be published soon.  I have one suggestion regarding the
    differentiation between actual and potential configurations, which
    is used in the document as part of the negotiation model:

    One of the main purposes for differentiating between actual and
    potential configurations is to express preferences of the offerer:
    Potential configuration are of higher preference for the offerer
    than actual configurations.  This property does not become
    sufficiently clear in the introduction and model description at the
    beginning of the document.  On the contrary, a reader may assume
    the opposite preference order, namely, that actual configuration are
    preferred because the offerer would have to re-configure in order to
    use any of the potential configurations.  Suggest to clarify the
    correct prioritization early on in the document.

  Please respond to this review.

[Ballot discuss]
3.6.3.  Offerer Processing of the Answer 

  When the offerer attempted to use SDP Capability Negotiation in the
  offer, the offerer MUST examine the answer for actual use of SDP
  Capability Negotiation. 

  For each media description where the offerer included a potential
  configuration attribute ("a=pcfg"), the offerer MUST first examine
  that media description for the presence of an actual configuration
  attribute ("a=acfg"). If an actual configuration attribute is not
  present in a media description, then the offerer MUST process the
  answer SDP for that media stream per the normal offer/answer rules
  defined in [RFC3264]. However, if one is found, the offerer MUST
  instead process the answer as follows:

  o  The actual configuration attribute specifies which of the
      potential configurations was used by the answerer to generate the
      answer for this media stream. This includes all the supported
      attribute capabilities and the transport capabilities referenced
      by the potential configuration selected, where the attribute
      capabilities have any associated delete-attributes included.
      Extension capabilities supported by the answerer are included as
      well. 

  o  The offerer MUST now process the answer in accordance with the
      rules in [RFC3264], except that it must be done as if the offer
      consisted of the selected potential configuration instead of the
      original actual configuration, including any transport protocol
      changes in the media ("m=") line(s), attributes added and deleted
      by the potential configuration at the media and session level,
      and any extensions used. 

What should the offerer do if the answerer response doesn't correspond to one of the potential configurations?
If the offerer just process the received response without checking that it matches one of the potential configurations, then maybe this can be used to bypass some policy checks.

[Ballot comment]
This is a very detailed document, which I really like.


Some comments I have so far:

3.3.2. Required Capability Negotiation Extensions Attribute

[...]

  A recipient that receives an SDP and does not support one or more of
  the required extensions listed in a "creq" attribute, MUST NOT

I might be confused here. Is this MUST NOT ...

  perform the SDP Capability Negotiation defined in this document. For
  non-supported extensions provided at the session-level, this implies
  that SDP Capability Negotiation MUST NOT be performed at all. For
  non-supported extensions at the media-level, this implies that SDP
  Capability Negotiation MUST NOT be performed for the media stream in
  question. 

    An entity that does not support the SDP Capability Negotiation
    framework at all, will ignore these attributes (as well as the
    other SDP Capability Negotiation attributes) and not perform any
    SDP Capability Negotiation in the first place.

  When an SDP recipient does not support one or more required SDP
  Capability Negotiation extensions listed in the option tags, the
  recipient MUST proceed as if the SDP Capability Negotiation

... the same as this MUST?

  attributes were not included in the first place, i.e. all the
  capability negotiation attributes should be ignored.  In that case,
  if the SDP recipient is an SDP answerer [RFC3264], the recipient
  SHOULD include a "csup" attribute in the resulting SDP answer
  listing the SDP Capability Negotiation extensions it actually
  supports. 

3.5.1. Potential Configuration Attribute

[...]

  A potential configuration list is normally provided after the
  configuration number. When the potential configuration list is
  omitted, the potential configuration equals the actual
  configuration. The potential configuration list contains one or more
  of attribute, transport and extension configuration lists. A
  potential configuration may for example include attribute
  capabilities and transport capabilities, transport capabilities
  only, or some other combination of capabilities. 

So what is the meaning of "attribute capabilities with no transport capabilities"? I.e., is the transport capability required if any configuration list is provided at all?


3.5.1. Potential Configuration Attribute

[...]

      v=0
      o=- 25678 753849 IN IP4 192.0.2.1
      s= 
      c=IN IP4 192.0.2.1
      t=0 0
      m=audio 53456 RTP/AVPF 0 18 
      a=acap:1 crypto:1 AES_CM_128_HMAC_SHA1_32   
        inline:NzB4d1BINUAvLEw6UzF3WSJ+PSdFcGdUJShpX1Zj|2^20|1:32 
      a=tcap:1 RTP/AVPF RTP/AVP RTP/SAVP RTP/SAVPF
      a=pcfg:1 t=4|3 a=1
      a=pcfg:8 t=1|2

  We have two potential configuration attributes listed here. The
  first one (and most preferred, since its configuration number is
  "1") indicates that either of the profiles RTP/SAVPF or RTP/SAVP
  (specified by the transport protocol capability numbers 4 and 3) can
  be supported with attribute capability 1 (the "crypto" attribute);
  RTP/SAVPF is preferred over RTP/SAVP since its capability number (4)
  is listed first in the preferred potential configuration. Note that
  although we have a single potential configuration attribute and
  associated handle, we have two potential configurations.

Just to confirm: a line like this:

      a=pcfg:1 t=4|3 a=1|2

would actually define 4 potential configuration, right?

3.6.1. Generating the Initial Offer

[...]

  If the offerer requires support for more or extensions (besides the

I think you meant "support for one or more extensions ..."

  base protocol defined here), then the offerer MUST include one or
  more "a=creq" attributes as follows:


3.6.2. Generating the Answer

[...]

  o  If attribute capabilities are present with a delete-attributes
      session indication ("-s"), then all session-level attributes from
      the actual configuration SDP MUST be deleted in accordance with
      the procedures in Section 3.5.1. If attribute capabilities are
      present with a delete-attributes media indication ("-m"), then
      all attributes from the actual configuration SDP inside this
      media description MUST be deleted. 

"-ms" is not listed here?

[...]

  If the answerer has exhausted all potential configurations for the
  media description, without finding a valid one that is also
  supported, then the answerer MUST process the offered media stream
  based on the actual configuration plus any session-level attributes
  added by a valid and supported potential configuration from another
  media description in the offered SDP.

This seems overly complicated.

6.2. New SDP Capability Negotiation Option Tag Registry

  The IANA is hereby requested to create a new SDP Capability
  Negotiation Option Tag registry. An IANA SDP Capability Negotiation
  option tag registration MUST be documented in an RFC in accordance
  with the [RFC5226] Specification Required policy. The RFC MUST
  provide the name of the option tag, a syntax and a semantic
  specification of any new SDP attributes and any extensions to the
  potential and actual configuration attributes provided in this
  document.

It would be useful to mention that this section talks about extensions to
"a=pcfg" and "a=acfg".

  New SDP attributes that are intended to be capabilities
  for use by the capability negotiation framework

You lost me here.

  MUST adhere to the
  guidelines provided in Section 3.4.3.

9.2. Informative References

  [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
            A., Peterson, J., Sparks, R., Handley, M., and E.
            Schooler, "SIP: Session Initiation Protocol", RFC 3261,
            June 2002.

  [ICE]    J. Rosenberg, "Interactive Connectivity Establishment
            (ICE): A Methodology for Network Address Translator (NAT)
            Traversal for Offer/Answer Protocols", work in progress,
            September 2007.

Use of these 2 RFCs seems to be Normative to me. (I might upgrade this to DISCUSS if I turn out to be right.)

IANA Last Call comments:

Action 1 (Section 6.1):

Upon approval of this document, the IANA will make the following assignments
in the "att-field" registry at
http://www.iana.org/assignments/sdp-parameters

Type SDP Name Reference
---- ------------------ ---------
att-field (both session and media level)
csup
[RFC-mmusic-sdp-capability-negotiation-09]
creq
[RFC-mmusic-sdp-capability-negotiation-09]
acap
[RFC-mmusic-sdp-capability-negotiation-09]
tcap
[RFC-mmusic-sdp-capability-negotiation-09]

att-field (media level only)
pcfg
[RFC-mmusic-sdp-capability-negotiation-09]
acfg
[RFC-mmusic-sdp-capability-negotiation-09]


Action 2 (Section 6.2):

Upon approval of this document, the IANA will create the registry "SDP
Capability Negotiation Option Tags" at
http://www.iana.org/assignments/TBD

Registration Procedures: Specification Required
Initial contents of this registry will be:

Capability Reference
---------- ---------
cap-v0 [RFC-mmusic-sdp-capability-negotiation-09]


Action 3 (Section 6.3):

Upon approval of this document, the IANA will create the registry "SDP
Capability Negotiation Potential Configuration Parameters" at
http://www.iana.org/assignments/TBD

Registration Procedures: Specification Required
Initial contents of this registry will be:

Encoding Name Descriptive Name Reference
------------- ---------------- ---------
a attribute
[RFC-mmusic-sdp-capability-negotiation-09]
t transport protocol
[RFC-mmusic-sdp-capability-negotiation-09]


We understand the above to be the only IANA Actions for this document.

The procedures described in RFC 4858 are being used for the MMUSIC Internet-Draft titled "SDP Capability Negotiation", draft-ietf-mmusic-sdp-capability-negotiation-09.txt,
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-09

Requested Publication Status: Proposed Standard
Document Shepherd: Jean-Francois Mule (jf.mule@cablelabs.com)

--------------------------------------------------------------------
--- (1.a)
          Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Jean-Francois Mule, MMUSIC co-chair (jf.mule@cablelabs.com) is the Document Shepherd. He has personally reviewed this version of the Internet-Draft.
Based on the WG discussion and Document Shepherd review, I believe this Internet-Draft document is ready for forwarding to the IESG for publication.


--- (1.b)
          Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

Yes, the SDP capability negotiation draft received numerous comments and reviews from participants that are WG members. The Document Shepherd does not have any particular concerns about the depth of the reviews that have been performed.

--- (1.c)
          Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

No. This Internet-Draft has been reviewed by folks involved in the RAI area, including AVT, and more importantly SIP and SIPPING where SDP is an essential part of their protocol toolkit. Additional reviews from folks outside the RAI area are always welcome.

--- (1.d)

        Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of?  For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it.  In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. 
No concerns given the WGLC, subsequent mailing list discussions and the time elapsed since the last version without new comments.

        Has an IPR disclosure related to this document
        been filed?  If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

Yes. An IPR disclosure has been filed by Cisco Systems and announced to the working group by the author each time the I-D was reviewed or discussed. More details can be found at:
https://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=15573
and
https://datatracker.ietf.org/ipr/761/

--- (1.e) 
          How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

There is solid consensus for publication.

--- (1.f)
        Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarize the areas of conflict in
        separate email messages to the Responsible Area Director.  (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No.

--- (1.g)
          Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the
          document met all formal review criteria it needs to, such as
          the MIB Doctor, media type and URI type reviews?


Yes, draft-09 checked against idnits 2.08.11.
The warnings for missing references are not applicable (test quoted between brackets).  There is one additional warning for 1 instance of lines with non-RFC3330-compliant IPv4 addresses in the document (idnits does not provide the line number and search on IP addresses seem to return IPs in 192.0.2.0/24 per RFC 3330.
See http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf-mmusic-sdp-capability-negotiation-09.txt


--- (1.h)
        Has the document split its references into normative and
        informative? 
Yes.

        Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state?  If such normative references exist, what is the
        strategy for their completion? 
No.

        Are there normative references
        that are downward references, as described in [RFC3967]?  If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].
No.

--- (1.i)
        Has the Document Shepherd verified that the document's IANA
        Considerations section exists and is consistent with the body
        of the document? 
Yes.

If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries?
Yes.
        Are the IANA registries clearly identified?
Yes.

        If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations?  Does it suggest a
        reasonable name for the new registry?  See [RFC2434].  If the
        document describes an Expert Review process, has the Document
        Shepherd conferred with the Responsible Area Director so that
        the IESG can appoint the needed Expert during IESG Evaluation?
This document creates 2 new SDP registries and the IANA section seems fine.


--- (1.j)
          Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

Yes, checked abnf with http://www.apps.ietf.org/abnf.html.


--- (1.k)
        The IESG approval announcement includes a Document
        Announcement Write-Up.  Please provide such a Document
        Announcement Write-Up.  Recent examples can be found in the
        "Action" announcements for approved documents.  The approval
        announcement contains the following sections:
        Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

        Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?
          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'


Here is the proposed Document Announcement Write-Up:

        Technical Summary
This document defines a general SDP Capability Negotiation framework.  It also specifies how to provide attributes and transport protocols as capabilities and negotiate them using the framework.

          Working Group Summary
The MMUSIC Working Group has consensus to publish this document as a Proposed Standard.

          Document Quality
This mechanism was specifically designed to allow some shortcomings seen in the field that could help deploy secure RTP (SRTP).  See page 11 of the document, these SDP extensions allow an SDP agent to offer both RTP and SRTP as alternatives, with SRTP being the preferred option using the Offer/Answer mechanism.

   
      Personnel
The Document Shepherd is Jean-Francois Mule, and the Responsible Area
Director is Cullen Jennings.