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

Alexey Melnikov <alexey.melnikov@isode.com> Wed, 12 December 2012 19:13 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 DD7D621E8088 for <gen-art@ietfa.amsl.com>; Wed, 12 Dec 2012 11:13:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.48
X-Spam-Level:
X-Spam-Status: No, score=-102.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 AkgNWUPv+kSy for <gen-art@ietfa.amsl.com>; Wed, 12 Dec 2012 11:13:28 -0800 (PST)
Received: from waldorf.isode.com (cl-125.lon-03.gb.sixxs.net [IPv6:2a00:14f0:e000:7c::2]) by ietfa.amsl.com (Postfix) with ESMTP id BACF121E810D for <gen-art@ietf.org>; Wed, 12 Dec 2012 11:13:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1355339605; d=isode.com; s=selector; i=@isode.com; bh=fGA/ivfAncdA4Kd2RJEpFQ9b7+lUeHonhklykoecG8E=; 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=iqYKIgSl+5Ga2Q5+1fxhtw3ocjJWxpd5ddF/rtzIsRLRYNetuw+o5h/wsmIgPFEEilwjJF dlnB3Id7EOaWTMbun1TnBmaBoeASFTqjwAUjZLUKbsoz/h9rjWWX9v6FcLr7ccoLIP554V Zj59aKsIPLnkllY/P9Sl9jPg7MjIFqE=;
Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by waldorf.isode.com (submission channel) via TCP with ESMTPA id <UMjXVAB1sLnq@waldorf.isode.com>; Wed, 12 Dec 2012 19:13:25 +0000
Message-ID: <50C8D762.1090709@isode.com>
Date: Wed, 12 Dec 2012 19:13:38 +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: Flemming Andreasen <fandreas@cisco.com>
References: <50B35AAF.20104@isode.com> <50BE3DF4.6040206@cisco.com>
In-Reply-To: <50BE3DF4.6040206@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-mmusic-sdp-media-capabilities.all@tools.ietf.org, "gen-art@ietf.org" <gen-art@ietf.org>
Subject: Re: [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: Wed, 12 Dec 2012 19:13:29 -0000

On 04/12/2012 18:16, Flemming Andreasen wrote:
> Hi Alexey,
Hi Flemming,
> Thank you for your review of the document - comments below:
>
> On 11/26/12 7:03 AM, Alexey Melnikov wrote:
>> 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?
>>
> I don't believe so. The document is an extension of SDP (RFC 4566) 
> which maintains its own media type name space and registry and hence 
> it simply follows the rules of SDP (as defined in RFC 4566, which did 
> change from the old SDP spec defined in RFC 2327).
>
> RFC 4288 (which I presume you are referring to here) should not apply.
I think SDP has to be in agreement with RFC 4288 or we have a bigger 
problem. In particular media type syntax. But I am Ok with no change in 
this area.
>> 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.
> How about this:
> <quote>
>           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. A latent configuration MUST include a media 
> type (mt=) and a transport protocol configuration parameter
>       since the latent configuration is independent
>           of any media line present. In most cases, the media 
> configuration
>           (m=) parameter needs to be present as well (see Section 4 
> for examples).
> </quote>
Yes, this is exactly what I had in mind. Thanks.
>>    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?
>>
> Is this better:
> <quote>
>          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. Since the keying material will be visible but 
> not actually used at this stage (since it's a latent configuration),
>       the value(s) of the keying material SHOULD be meaningless, and 
> the receiver of the lcfg attribute
>       MUST ignore the values.
> </quote>
This is better. I was actually most wondering about the meaning of 
"meaningless". Did you mean "not a real value you would use for a real 
exchange"?
>> receiver of the lcfg attribute MUST ignore the values.
>> .
Best Regards,
Alexey