[Gen-art] Gen-ART review of draft-ietf-mmusic-sdp-media-capabilities-15

Alexey Melnikov <alexey.melnikov@isode.com> Mon, 26 November 2012 12:03 UTC

Return-Path: <alexey.melnikov@isode.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD9C21F8588 for <gen-art@ietfa.amsl.com>; Mon, 26 Nov 2012 04:03:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nBUS9whrAhZi for <gen-art@ietfa.amsl.com>; Mon, 26 Nov 2012 04:03:03 -0800 (PST)
Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8E21F8585 for <gen-art@ietf.org>; Mon, 26 Nov 2012 04:03:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1353931380; d=isode.com; s=selector; i=@isode.com; bh=WnJpnVLFhLuzTbOwhFbXJG9fsAj+19EfZTD84EvTuSc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=m2P2HLsBRn22xQhyZk44/SZ89LXRlOuTp9jNstNO7pSpfxZo9PeumBKCr2xspiUeMtD3f6 nkIAsqG511wT25xntY3KS5+h4DjqzW/FJ0aoxY9fvOP91vVA5FwLUEoXKX7CXCp6rwY5eP sRnA7Yrz8r8KdYk1AcvketvMcrTsCVQ=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id <ULNadAAbAgH8@statler.isode.com>; Mon, 26 Nov 2012 12:03:00 +0000
Message-ID: <50B35AAF.20104@isode.com>
Date: Mon, 26 Nov 2012 12:03:59 +0000
From: Alexey Melnikov <alexey.melnikov@isode.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
To: "gen-art@ietf.org" <gen-art@ietf.org>, draft-ietf-mmusic-sdp-media-capabilities.all@tools.ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Gen-art] Gen-ART review of draft-ietf-mmusic-sdp-media-capabilities-15
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Nov 2012 12:03:04 -0000

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.