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

Christian Groves <Christian.Groves@nteczone.com> Fri, 09 October 2015 03:17 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 3E9811B30A7 for <mmusic@ietfa.amsl.com>; Thu, 8 Oct 2015 20:17:12 -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 F5oq3Kipy39D for <mmusic@ietfa.amsl.com>; Thu, 8 Oct 2015 20:17:11 -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 0CA9A1B30A5 for <mmusic@ietf.org>; Thu, 8 Oct 2015 20:17:11 -0700 (PDT)
Received: from ppp118-209-33-227.lns20.mel4.internode.on.net ([118.209.33.227]:52807 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.85) (envelope-from <Christian.Groves@nteczone.com>) id 1ZkOBB-002bfB-2U for mmusic@ietf.org; Fri, 09 Oct 2015 14:17:09 +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>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <561731AE.2060108@nteczone.com>
Date: Fri, 9 Oct 2015 14:17:02 +1100
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: <5613F8CA.2030804@alum.mit.edu>
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-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/BpyVe6yeh4iMUQlF35_LYgna8QM>
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: Fri, 09 Oct 2015 03:17:12 -0000

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