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

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 21 October 2015 15:49 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 89DFF1AD09B for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:49:43 -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 vBWQ9F89cSGO for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:49:42 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9381AD08F for <mmusic@ietf.org>; Wed, 21 Oct 2015 08:49:41 -0700 (PDT)
Received: from resomta-ch2-12v.sys.comcast.net ([69.252.207.108]) by resqmta-ch2-05v.sys.comcast.net with comcast id Xrof1r0022LrikM01rphyX; Wed, 21 Oct 2015 15:49:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-12v.sys.comcast.net with comcast id Xrpg1r00R3Ge9ey01rpgPB; Wed, 21 Oct 2015 15:49:41 +0000
To: mmusic@ietf.org
References: <20151005124526.4291.89663.idtracker@ietfa.amsl.com> <5612739A.4080608@alcatel-lucent.com> <5612E7B4.7020805@alum.mit.edu> <5613E645.8090302@alcatel-lucent.com> <5613F8CA.2030804@alum.mit.edu> <561731AE.2060108@nteczone.com> <5617B912.9080207@alcatel-lucent.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5627B413.3010802@alum.mit.edu>
Date: Wed, 21 Oct 2015 11:49:39 -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: <5617B912.9080207@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=1445442581; bh=O0MVNKqK/7KKS91Vtuub0+mGra2rOkUeNh8RReBOThM=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uqXJBISnXKEopKDN6DUKaq7FTjH9ma+PhAX8uF7p2aZwrS0XqcPfFc0lz74wcFVca CbOfCDzZ2t0Ahp0QtoDTu3X3kqbCawPMv/lIcwTGBtH8n0Wy4j3//4PXJbnTm9XYbW bfzskhKsqvIhrirZXNPYtQ1/OH8km7YL/L21JLgRerAdcBjHUsZ6uMGGhuyoJaNPx6 SWtzamKO3aBwvjHpQm8k1l3MBFH0X6fDlLKIbkKjUpNmJtWdbvmAJItO4Hws7BlWrA btC39xkewJHR2+GH85h4HEPWXXyEB9jvrhOoq/GMvc7mUfeDdUdulhE9mltTrLCUbX pZcINnezw0HCA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/tpap_yAqunSs4FTcyL0Atq9uPwQ>
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: Wed, 21 Oct 2015 15:49:43 -0000

Sorry for not responding sooner. I see you put the proposed language 
into -06. I'm satisfied with that.

	Thanks,
	Paul

On 10/9/15 8:54 AM, Juergen Stoetzer-Bradler wrote:
> Hello Paul, Christian,
>
> Thank you for your feedback.
>
> I was indeed much focused on the WebRTC data channel protocol stacks
> (SCTP over DTLS) when writing the mux category sections for dcmap and dcsa.
> My reading of draft-ietf-rtcweb-data-channel-13 (e.g. sec 6.1) is that
> DTLS transport of SCTP must actually be used.
> However, in order not to explicitly restrict potential future usage of
> the dcmap and dcsa attributes to x/DTLS/SCTP m-lines I'd propose to
> modify the text in section
> 5.1.1.2 as follows. (And correspondingly to also modify the dcsa related
> text in 5.1.2.2.)
>
> Would you agree to following wording?
>
> 5.1.1.2.  dcmap Multiplexing Category
>     Multiplexing characteristics of SDP attributes are described in
>     [I-D.ietf-mmusic-sdp-mux-attributes].  Various SDP attribute
>     multiplexing categories are introduced there.
>
>     The multiplexing category of the "a=dcmap:" attribute is SPECIAL.
>
>     As the usage of multiple SCTP associations on top of a single DTLS
>     connection is outside the scope of [I-D.ietf-mmusic-sctp-sdp], no
>     "a=dcmap:" attribute multiplexing rules are specified for the
> UDP/DTLS/SCTP
>     and TCP/DTLS/SCTP proto values.
>     This document also does not specify multiplexing rules for this
> attribute
>     for SCTP or SCTP/DTLS proto values.
>     If future extensions of [I-D.ietf-mmusic-sctp-sdp] define how to
> negotiate
>     multiplexing of multiple SCTP associations of top of a single DTLS
> connection
>     or how to multiplex multiple SCTP associations within one BUNDLE group,
>     then multiplexing rules for the "a=dcmap:" attribute need to be
> defined as
>     well, for instance in an extension of this SDP based data channel
>     negotiation specification.
>
>
> Thanks,
> Juergen
>
> On 09.10.2015 05:17, Christian Groves wrote:
>> Hello Juergen and Paul,
>>
>> You're updates look OK to me. I think this is ready for WGLC.
>>
>> Please see below.
>>
>>>>>
>>>>> Also, saying this is *only applicable* unnecessarily blocks future
>>>>> changes. I think it would be better to say *only defined*, or *outside
>>>>> the scope*.
>>>> [Juergen] Agree. How about the following?
>>>> "This document defines usage of this attribute only when associated
>>>> with
>>>> UDP/DTLS/SCTP or TCP/DTLS/SCTP proto SDP "m" lines".
>>>
>>> Ahh! I think we disagree on what the scope of this draft should be.
>>>
>>> draft-ietf-mmusic-sctp-sdp defines several transport configurations
>>> for sctp: SCTP, SCTP/DTLS, UDP/DTLS/SCTP, TCP/DTLS/SCTP.
>>>
>>> draft-ietf-rtcweb-data-channel defines data channels over sctp, but
>>> doesn't anything about allowed transport configurations of sctp.
>>>
>>> Elsewhere webrtc specifies that only UDP/DTLS/SCTP and TCP/DTLS/SCTP
>>> are to be used for webrtc data channels.
>>>
>>> I guess this draft is trying to restrict its applicability to only
>>> UDP/DTLS/SCTP and TCP/DTLS/SCTP. I see no reason to do that. This
>>> draft defines the dcmap and dcsa attributes. AFAIK there is *nothing*
>>> that prevents using data channels and these attributes over SCTP or
>>> SCTP/DTLS. That ought to be allowed and covered by this document.
>>>
>>> Multiplexing in bundles is a different matter. As you point out, use
>>> in bundles is not defined for SCTP and SCTP/DTLS, while UDP/DTLS/SCTP
>>> and TCP/DTLS/SCTP can appear at most once in a bundle. So
>>> multiplexing of these attributes in bundles is currently undefined.
>>> This needs to be noted (and left for future work), but without
>>> excluding *unbundled* use with the other transports.
>>
>> Do we really need to extend the scope to SCTP or SCTP/DTLS? The
>> mechanism is clearly related to the use of WebRTC data channel. Is
>> SCTP and SCTP/DTLS going to be used for data channel in the future?
>> There is "something" preventing data channels being used on SCTP or
>> SCTP/DTLS its draft-ietf-rtcweb-data-channel which clearly shows the
>> stack as UDP/DTLS/SCTP and TCP/DTLS/SCTP.
>>
>> Regards, Christian
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>