Re: [MMUSIC] Review Request- draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5939 Related)

Flemming Andreasen <fandreas@cisco.com> Mon, 15 July 2013 05:29 UTC

Return-Path: <fandreas@cisco.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34E221F9C4F for <mmusic@ietfa.amsl.com>; Sun, 14 Jul 2013 22:29:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.654
X-Spam-Level:
X-Spam-Status: No, score=-9.654 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXCob0OhY+Fe for <mmusic@ietfa.amsl.com>; Sun, 14 Jul 2013 22:29:07 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 16B3121F9ABB for <mmusic@ietf.org>; Sun, 14 Jul 2013 22:29:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7066; q=dns/txt; s=iport; t=1373866147; x=1375075747; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=2Y6g+Nbf4v84/jAbiY+xLZ/mtBP+5A7NHoICVge4HE0=; b=W7cv0Qz5Xlmw9R0Q54IgU7AfBIdruOk/kIgegHWinwSUXxWeldPwP94i DXLp/oNbE8pRtoJxwYXt3LAc1+dOQu+4PG0szCIrmT0VhE4oTqVJ/A4AT BZv1Na3ZjRWjIETiT0zlr28Wsim981RFVW4lWBypu1s2d74MuaLL+HRe6 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AtAjAGmI41GtJXHB/2dsb2JhbABaJoJgNIkypGoClACBDhZ0giMBAQEBA3gBEAsYCRYPCQMCAQIBRQYNAQcBAYgMDLUtj2QHg3gDl1yBKZAkgVmBVSA
X-IronPort-AV: E=Sophos; i="4.89,667,1367971200"; d="scan'208,217"; a="234801388"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 15 Jul 2013 05:29:02 +0000
Received: from Flemmings-MacBook-Pro.local (rtp-vpn4-549.cisco.com [10.82.210.37]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6F5Swb3016247; Mon, 15 Jul 2013 05:29:00 GMT
Message-ID: <51E34C6A.5020704@cisco.com>
Date: Sun, 14 Jul 2013 21:12:10 -0400
From: Flemming Andreasen <fandreas@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Suhas Nandakumar <suhasietf@gmail.com>
References: <CAMRcRGTGDbHhXmJKYVph-xBE8AOViwXaaAhfmEFiyX91XwFiKA@mail.gmail.com>
In-Reply-To: <CAMRcRGTGDbHhXmJKYVph-xBE8AOViwXaaAhfmEFiyX91XwFiKA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------020306050508010102050601"
Cc: mmusic WG <mmusic@ietf.org>
Subject: Re: [MMUSIC] Review Request- draft-nandakumar-mmusic-sdp-mux-attributes-02 - (RFC5939 Related)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2013 05:29:11 -0000

Section 5.28 defines the following attributes with the category shown in 
brackets:

a=pcfg (SPECIAL)
a=acfg (SPECIAL)
a=csup (SPECIAL)
a=creq (SPECIAL)
a=acap (SPECIAL)
a=tcap (IDENTICAL)

I think the definition of "SPECIAL" needs to be changed and maybe we 
need two versions of it: A "SPECIAL" for existing attributes, in which 
case the mux-attributes draft will have to define the handling that is 
needed, and a "SPECIAL NEW", which would essentially impose a new 
requirement on all new SDP attribute definitions to have one of the 
mux-attribute categories assigned to them, and if it's "SPECIAL NEW", 
then define the handling with muxing.

Moving on to the categories suggested above:

On the "tcap" one, it's debatable whether they need to be "IDENTICAL" 
since they are purely capabilities and as such not being used at this 
point in time; the "pcfg" atttribute is what would instantiate their 
use. Also, repeating the comment from the RFC 3407 attributes, we have 
an example of an attribute where there can be multiple different values 
(on purpose) and they are all equally valid. In this case, the 
negotiation process would end up picking one of them, and what you 
probably want for mux-attributes is the negotiation process to pick the 
same one for all the multiplexed m-lines; this seems well suited for a 
"SPECIAL" description (there are probably several other nuances to be 
covered). Similar considerations apply for "acap".

For the "csup" and "creq" ones, I don't think there is anything 
"SPECIAL". They each list one or more option tags supported or required 
for capability negotiation to be used, and I believe they can just 
continue to do so when doing multi-plexing. In other words, I think 
"NORMAL" would be right for these.

For "acfg" and "pcfg" I agree that further description on how they would 
be used with multiplexing would be needed (need to drive consistent 
negotiation across the multi-plexed m-lines).

Thanks

-- Flemming



On 4/26/13 5:31 PM, Suhas Nandakumar wrote:
> Hello Flemming
> This is a request for reviewing the following sections
> 5.28
>
> of the draft
> draft-nandakumar-mmusic-sdp-mux-attributes-02
>
> It will be greatly appreciated if you could inform on your willingness 
> for reviewing the aforementioned sessions.
>
> It would be great to have your review feedback/comments/input before 
> June 9th 2013.
>
> The document is available here:
> http://tools.ietf.org/html/draft-nandakumar-mmusic-sdp-mux-attributes-02
>
>
> Thanks in Advance
>
> Regards
> Suhas Nandakumar