Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-data-channel-sdpneg-05.txt

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 05 October 2015 21:12 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 DE1931A1EF3 for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 14:12:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] 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 i7Fp-sNXGamu for <mmusic@ietfa.amsl.com>; Mon, 5 Oct 2015 14:12:23 -0700 (PDT)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EBC11A2130 for <mmusic@ietf.org>; Mon, 5 Oct 2015 14:12:22 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-03v.sys.comcast.net with comcast id RZC01r0042VvR6D01ZCM8u; Mon, 05 Oct 2015 21:12:21 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id RZCM1r0013Ge9ey01ZCMvS; Mon, 05 Oct 2015 21:12:21 +0000
To: mmusic@ietf.org
References: <20151005124526.4291.89663.idtracker@ietfa.amsl.com> <5612739A.4080608@alcatel-lucent.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5612E7B4.7020805@alum.mit.edu>
Date: Mon, 05 Oct 2015 17:12:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5612739A.4080608@alcatel-lucent.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1444079541; bh=HXw+J+devgNJECEn8YDdF+E8BsjjxIakz0HBGNtRyGM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=qCtrAxwqJEjEvecXWz5vIuCc/sbbY8bsiU1hypMbSFnzb1rx07ZIbVOjxnR6vJCHG ZFfhWXMOG/xKtJdeduA3z8B6COxnleB8mb2AR7sI4FI7ctttSbhIHRCgt6MKuhH0SP CjbzFi3Z/+PAZ9gYYMN9aL0tP1pX2ZXIUFsFybOJnM2o3yqD+ei8fzTl5K4RMzGdf3 yQTY+ePEb9VoVpM9x/4TYKwUgSO4DFGe3zrLDXb9iJfiLAOMcyhEBTXsiMvj8M7N1b yLlxINDak3QspnlcXkABSLpe5E1jLbNvb3DWPyHgNx5I5z4JIFvNzVE4eREEu80NXW YSBeVrH3RhE5Q==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/gtwbZ2LwVR_zgq2q0DPcdeeIg4M>
Subject: Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-data-channel-sdpneg-05.txt
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: <https://mailarchive.ietf.org/arch/browse/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, 05 Oct 2015 21:12:25 -0000

These changes mostly seem good. I have a couple of small points:

* Section 5.1.1.2:

This section starts with:

    The multiplexing category of the "a=dcmap:" attribute is SPECIAL.
    Usage of this attribute is only applicable when associated with
    UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines.

One issue is that usage of this attribute is also defined over pure 
SCTP. So I think it would be more accurate to say "*Multiplexing* of 
this attribute...".

Also, saying this is *only applicable* unnecessarily blocks future 
changes. I think it would be better to say *only defined*, or *outside 
the scope*.

* Section 5.1.2.2:

Analogous comment to that for 5.1.1.2.

* Section 8.2:

IIUC current practice is for documents coming through WGs to list the WG 
chair (e.g. mmusic-chairs@ietf.org) as the contact.

	Thanks,
	Paul

On 10/5/15 8:56 AM, Juergen Stoetzer-Bradler wrote:
> Hello,
>
> This version 05 adds the IANA registration sections for the dcmap and
> dcsa attributes
> and adds new mux category related sections for both attributes.
> It also adds [I-D.ietf-mmusic-sdp-mux-attributes] to the list of
> normative references,
> as that draft is referenced by the two new mux category sections.
>
> Additionally, this version updates section 5.1.1.5 regarding the dmap's
> 'subprotocol' parameter
> as per the related MMUSIC discussion initiated by Christian in August,
> http://www.ietf.org/mail-archive/web/mmusic/current/msg14946.html
>
> Thanks,
> Juergen
>
>
> On 05.10.2015 14:45, internet-drafts@ietf.org wrote:
>> A new version of I-D, draft-ietf-mmusic-data-channel-sdpneg-05.txt
>> has been successfully submitted by Juergen Stoetzer-Bradler and posted
>> to the
>> IETF repository.
>>
>> Name:        draft-ietf-mmusic-data-channel-sdpneg
>> Revision:    05
>> Title:        SDP-based Data Channel Negotiation
>> Document date:    2015-10-05
>> Group:        mmusic
>> Pages:        35
>> URL:
>> https://www.ietf.org/internet-drafts/draft-ietf-mmusic-data-channel-sdpneg-05.txt
>>
>> Status:
>> https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
>> Htmlized:
>> https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-05
>> Diff:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg-05
>>
>>
>> Abstract:
>>     The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>>     charged to provide protocols to support direct interactive rich
>>     communications using audio, video, and data between two peers' web-
>>     browsers.  For the support of data communication, the RTCWeb working
>>     group has in particular defined the concept of bi-directional data
>>     channels over SCTP, where each data channel might be used to
>>     transport other protocols, called sub-protocols.  Data channel setup
>>     can be done using either the in-band Data Channel Establishment
>>     Protocol (DCEP) or using some out-of-band non-DCEP protocol.  This
>>     document specifies how the SDP offer/answer exchange can be used to
>>     achieve such an out-of-band non-DCEP negotiation.  Even though data
>>     channels are designed for RTCWeb use initially they may be used by
>>     other protocols like, but not limited to, the CLUE protocol.  This
>>     document is intended to be used wherever data channels are used.
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of
>> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>