Skip to main content

Last Call Review of draft-ietf-mmusic-sdp-media-capabilities-15

Request Review of draft-ietf-mmusic-sdp-media-capabilities
Requested revision No specific revision (document currently at 17)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2012-11-12
Requested 2012-10-29
Authors Robert Gilman , Roni Even , Flemming Andreasen
I-D last updated 2012-11-26
Completed reviews Genart Last Call review of -15 by Alexey Melnikov (diff)
Genart Telechat review of -16 by Alexey Melnikov (diff)
Assignment Reviewer Alexey Melnikov
State Completed
Request Last Call review on draft-ietf-mmusic-sdp-media-capabilities by General Area Review Team (Gen-ART) Assigned
Reviewed revision 15 (document currently at 17)
Result Ready w/nits
Completed 2012-11-26
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

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.