Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes-06 review

Suhas Nandakumar <> Fri, 16 January 2015 03:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 477981A914E for <>; Thu, 15 Jan 2015 19:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tvSSb70A07pq for <>; Thu, 15 Jan 2015 19:05:12 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 18B1B1A9142 for <>; Thu, 15 Jan 2015 19:05:11 -0800 (PST)
Received: by with SMTP id lf10so21460398pab.4 for <>; Thu, 15 Jan 2015 19:05:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5cbY8hsiulBdDTfTV1oLmxdhuzAyd5o7ECWhD7Hl1yo=; b=NCUrJ/3d9AFZEi3Ig1p5IgxAwo8NpYmL0qDCrp8s/++mm5BCNc8t4a2PmUw1p0aYAj C1Nxp48aBgb5LM6coz+c568phTMkNg1l4q4k1TOGOXFwjIMAs4VrcVrGZdoPLPAJ2Pih aDwsMPOKhN18b85p9R+9J9A/CbP0lCxDkp02ZwDXmoX9cQ9V5aBbIdaK39Ct2t5xXFT/ ZsEoL0roPty8UCiUYMhDbhQjVqHa0xmTXopbA/WQgR/F26GagGqBCjCQKWH/lO8ASn51 jWXYVjd4dGQX1CE/g0Pd409/CKilrYs7umguSoL0y3vKEVbg/2B563mp+nIbpiqaCwYK tv6g==
MIME-Version: 1.0
X-Received: by with SMTP id xd4mr19394002pab.54.1421377510303; Thu, 15 Jan 2015 19:05:10 -0800 (PST)
Received: by with HTTP; Thu, 15 Jan 2015 19:05:10 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 15 Jan 2015 19:05:10 -0800
Message-ID: <>
From: Suhas Nandakumar <>
To: =?UTF-8?B?QXJpIEtlcsOkbmVu?= <>
Content-Type: multipart/alternative; boundary=047d7b86e42297eca1050cbc3d5b
Archived-At: <>
Cc: mmusic <>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes-06 review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 16 Jan 2015 03:05:16 -0000

Thanks Ari for the review. Regarding the abstract, please let me know if
the below introductory paragraph captures what is needed.

"The Session Description Protocol (SDP) provides mechanisms to
       describe attributes of multimedia sessions and of individual media
       streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
       multimedia session. Typically media associated with individual
       media descriptions ("m=" lines) represent separate RTP Sessions
       and thus carried over individual underlying transport layer flows.
       For scenarios
       where SDP is used to negotiate the usage of single 5-tuple for
       sending and receiving media associated with multiple media
descriptions, it is required to understand the semantic implications of the
 attributes associated with the RTP Media Streams multiplexed over a
       single underlying transport layer flow"


On Wed, Jan 14, 2015 at 5:25 AM, Ari Keränen <>

> Hi Suhas,
> I have couple of more comments on the latest draft's bundle references.
> The Bundle draft is currently listed as Informative reference, but
> considering how Bundle is referenced and used in this document, I think it
> should be a Normative reference instead.
> Also, in general the Abstract should not contain references (unless they
> are completely defined within the Abstract; see [1] for details), so I
> would suggest replacing the Bundle draft reference in the Abstract with
> some more general text about the Bundling feature.
> Finally, I noticed that the latest version has many of the MUSTs and MAYs
> changed to (non-RFC2119) lower case versions. What was the reason for this?
> For some I see why, e.g., in "This may or may not work [...]", but for
> some, e.g. "multiplexing must not be performed even in this alternate
> scenario" RFC2119 language seems more appropriate.
> Cheers,
> Ari
> [1]