Session Description Protocol (SDP) Media Capabilities Negotiation
draft-ietf-mmusic-sdp-media-capabilities-17

One minor question added to my original comments: The writeup does not indicate any implementation of this. Is that true? There are no implementations yet?

This stuff is well outside of my area of expertise. After a read through, I have found nothing *in* my area of expertise that is problematic. A couple of requirements language issues, but nothing that should stop the document unless other ADs think these problems could cause serious problems:

3.4.1.1:

The following happens elsewhere in the document, but this is a good example:

   Each potential configuration
   MUST include a config-number that is unique in the entire SDP...

That's ambiguous. What "MUST" be done here? Do you mean:

   Each potential configuration MUST include a config-number, which is
   unique in the entire SDP.

Or do you mean:

   The config-number of each potential configuration MUST be
   unique in the entire SDP.
   
Or do you mean:

   Each potential configuration MUST include a config-number, and
   each config-number MUST be unique in the entire SDP.
   
Which is it? They have 3 different meanings. The first is saying to the implementer, "You might not think the config number is required, but it is and you'll screw up the other side if you leave it out." The second is saying, "You might not think the config number needs to be unique, but it does and you'll screw up the other side if it's not." And the third is saying the combination of the first two.

It is probably worth reviewing 2119 usage throughout the document, as ambiguities in requirements is a bad thing. And even though this is ambiguous, the RFC Editor will likely not try to correct it because they always assume that things around requirements language were worded carefully. Please check them.

3.4.2.1:

   The answerer MUST first determine...

I very much doubt that this is an interoperability requirement. There are several instances of this sort. Please remove these MUSTs.

Thank you for including the specific ways in which
this document updates RFC 5939:

   This document updates RFC 5939 [RFC5939] by updating the IANA
   Considerations.  All other extensions defined in this document are
   considered extensions above and beyond RFC 5939 [RFC5939].

- 3.3.5: Does the crypto field only ever contain symmetric key
material or initialisation values? If so, why only have a
SHOULD NOT for use of real key materials in a latent (or
potential?) configuration? I don't see why that is not a MUST
NOT. Actually, having a MUST for some known value would
maybe be even better, e.g. all zeros, so long as that didn't
break anything.  (Same thing if crypto can occur in an answer
as a latent value.)