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

Suhas Nandakumar <suhasietf@gmail.com> Mon, 19 January 2015 22:13 UTC

Return-Path: <suhasietf@gmail.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA5961B2CD7 for <mmusic@ietfa.amsl.com>; Mon, 19 Jan 2015 14:13:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKi7L6z1RZ_t for <mmusic@ietfa.amsl.com>; Mon, 19 Jan 2015 14:13:09 -0800 (PST)
Received: from mail-pd0-x22a.google.com (mail-pd0-x22a.google.com [IPv6:2607:f8b0:400e:c02::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55C231B2CCF for <mmusic@ietf.org>; Mon, 19 Jan 2015 14:13:09 -0800 (PST)
Received: by mail-pd0-f170.google.com with SMTP id p10so27308981pdj.1 for <mmusic@ietf.org>; Mon, 19 Jan 2015 14:13:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5+b5j+Q5at9XvfomkQc7/q6YUTGdpJHYLQQ0jG4Ifjg=; b=k59KMEbseL3mFtGm3WZVNZUS4Q8K2uYOiWOKecccK9DmVEDolLrQGA2jUsgjPgbvlF jJ2vE4zmaxL1Qax6qX2XyvQMy2+omtmNiqFnZk81qV+6/IS/ZmlTdpByP1f1pm9WqWZJ U4awOpbsK2oU4M/TggHhRzXFXUAlfYNM3C6U+SvNIFb0Ucpnt3+h3qdmE/AonfZhCk1b /awWuntifUHp3+ba36cWgqyVAQgF3kE0SakPN+B+xstrHRpxYEMGO06wHRGEXTMzBrLS nMKFLDKIRJAm9ebsSwI55OEOB/hgrTU2hAJ2IMT+WtL0OwZBDabS2nXfktz2SzlZxuJZ nj6g==
MIME-Version: 1.0
X-Received: by 10.70.135.137 with SMTP id ps9mr48474744pdb.135.1421705588653; Mon, 19 Jan 2015 14:13:08 -0800 (PST)
Received: by 10.70.103.200 with HTTP; Mon, 19 Jan 2015 14:13:08 -0800 (PST)
In-Reply-To: <54BD138C.2070703@ericsson.com>
References: <54B66E38.4020007@ericsson.com> <CAMRcRGR=VBAWtLTOBBnYK11SSSP5q8jYkM2=yGRfGeP3kXkaUw@mail.gmail.com> <54BD138C.2070703@ericsson.com>
Date: Mon, 19 Jan 2015 14:13:08 -0800
Message-ID: <CAMRcRGTMCkqkt6THhAD2WL=YFfFm0y0s4fj2VHcztYMfRkeWGw@mail.gmail.com>
From: Suhas Nandakumar <suhasietf@gmail.com>
To: Ari Keränen <ari.keranen@ericsson.com>
Content-Type: multipart/alternative; boundary="001a1133426c9645ea050d08a0f8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/KVq-uy32AcY8T8RfzHVPH2ErUV8>
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] draft-ietf-mmusic-sdp-mux-attributes-06 review
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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, 19 Jan 2015 22:13:13 -0000

Thanks Ari .. I will go ahead and submit a new version with the fix


Also I am seeing a problem with the hyperlink to BUNDLE draft
  - The link leads to a wrong place when tried in this html link:
http://tools.ietf.org/html/draft-ietf-mmusic-sdp-mux-attributes-07
  - but leads to the right place when tried with this HTML link :
http://tools.ietf.org/id/draft-ietf-mmusic-sdp-mux-attributes-07.html

Any ideas why this could be happening

Cheers
Suhas

On Mon, Jan 19, 2015 at 6:24 AM, Ari Keränen <ari.keranen@ericsson.com>
wrote:

> Hi Suhas,
>
> That's better, thanks!
>
> There might be a word missing though. I'd suggest, e.g.:
> s/and thus carried/and are thus carried/
>
>
> Cheers,
> Ari
>
> On 16/01/15 05:05, Suhas Nandakumar wrote:
>
>> 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"
>>
>> Thanks
>> Suhas
>>
>>
>> On Wed, Jan 14, 2015 at 5:25 AM, Ari Keränen <ari.keranen@ericsson.com
>> <mailto:ari.keranen@ericsson.com>> wrote:
>>
>>     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] http://www.ietf.org/ietf-ftp/__1id-guidelines.txt
>>     <http://www.ietf.org/ietf-ftp/1id-guidelines.txt>
>>
>>
>>
>