I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at < http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-mmusic-sdp-media-capabilities-15 Reviewer: Alexey Melnikov Review Date: 2012-11-26 IETF LC End Date: 2012-11-12 IESG Telechat date: not scheduled Summary: This document is ready for publication as Proposed Standard, with nits. Nits/editorial comments: This might be obvious to a SIP implementer, but the media type/subtype definition RFC is not referenced anywhere. Should it be? 3.3.5. The Latent Configuration Attribute Latent configurations may be announced by use of the latent configuration attribute, which is defined in a manner very similar to the potential configuration attribute. The latent configuration attribute combines the properties of a media line and a potential configuration. The media type (mt=) and the transport protocol(s) (t=) MUST be specified since the latent configuration is independent of any media line present. In most cases, the media configuration (m=) parameter MUST be present as well (see Section 4 for examples). This doesn't look like a correct use of MUST, please reword not to use any RFC 2119 keyword or at least provide a pointer to a document that contains the original requirement. The lcfg attribute is a media level attribute. [...] If a cryptographic attribute, such as the SDES "a=crypto:" attribute [RFC4568], is referenced by a latent configuration through an acap attribute, any keying material required in the conventional attribute, such as the SDES key/salt string, MUST be included in order to satisfy formatting rules for the attribute. The actual value(s) of the keying material SHOULD be meaningless, and the Can you please elaborate on what are you trying to say here? receiver of the lcfg attribute MUST ignore the values.