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

Christian Groves <Christian.Groves@nteczone.com> Wed, 21 October 2015 15:02 UTC

Return-Path: <Christian.Groves@nteczone.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 81F6C1A1BCD for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:02:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 7jNNBkhIBk8S for <mmusic@ietfa.amsl.com>; Wed, 21 Oct 2015 08:02:47 -0700 (PDT)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F1D1A1AAD for <mmusic@ietf.org>; Wed, 21 Oct 2015 08:01:59 -0700 (PDT)
Received: from [156.106.225.28] (port=54299) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <Christian.Groves@nteczone.com>) id 1Zoutn-000ACq-2q for mmusic@ietf.org; Thu, 22 Oct 2015 02:01:55 +1100
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: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <5627A8DF.40407@nteczone.com>
Date: Wed, 21 Oct 2015 17:01:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; 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
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/GuaGncsgGKs2_VqfKZX_47JXYCE>
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:02:54 -0000

Hello Juergen,

Sorry for the slow reply. Its OK with me.

Regards, Christian

On 9/10/2015 2:54 PM, 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