Re: [MMUSIC] New Version Notification for draft-ietf-mmusic-data-channel-sdpneg-05.txt
Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 06 October 2015 16:37 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 5D8861ACDF6 for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 09:37:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Level:
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, 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 i1pf9g4aUOQj for <mmusic@ietfa.amsl.com>; Tue, 6 Oct 2015 09:37:37 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 648451ACDEC for <mmusic@ietf.org>; Tue, 6 Oct 2015 09:37:32 -0700 (PDT)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-12v.sys.comcast.net with comcast id RscM1r00726dK1R01sdXyo; Tue, 06 Oct 2015 16:37:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-01v.sys.comcast.net with comcast id RsdX1r0063Ge9ey01sdXbA; Tue, 06 Oct 2015 16:37:31 +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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <5613F8CA.2030804@alum.mit.edu>
Date: Tue, 06 Oct 2015 12:37:30 -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: <5613E645.8090302@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=1444149451; bh=ckPAta6egMrKptZHpByDD4rhXgyGVUFf1wDN7i51R+k=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=oYO19hmou+ycdpOMOtFjSGGpmR4sTaX6jvpwby4EqtOmBzgRKeaZaMyblWwYCtTeY UfEEe6fdbXIxTIJEwf2wYxcWObbJji8RDP9HMXESmVkM3H+wO4MN6mlK2RhXqyF+Rz 9W8JhQCx6oguQN30YLBT55RbxOTC6kMVvaCF0SCynjJ6Pr/F1LiRE2Rvlzy6OGQqBw ejtq4w1Sz51SnAgMflMoGzfJCZr9Dyi7q/qfljqUjWsA1seP/wNn56VQnTVz4/0rQj RoKq0mx2hlCt0imHMrKqjIBlPyYgEGwEE68CVlVQG5aVRde1UIjySI1RCTN/BjnM9P xplinYTomXMMA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/jVA1DJX7nh8X9Kfs73nq-h6R-Z8>
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: Tue, 06 Oct 2015 16:37:39 -0000
See inline. On 10/6/15 11:18 AM, Juergen Stoetzer-Bradler wrote: > Hello Paul, > > Thanks much for your comments. > Please see my replies inserted below. > > Thank you, > Juergen > > > On 05.10.2015 23:12, Paul Kyzivat wrote: >> 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...". > [Juergen] In this second paragraph of 5.1.1.2 I wanted to express that > this document defines the a=dcmap attribute only for > X/DTLS/SCTP attribute lines - quite similar to the mux category > description of the a=sctp-port attribute in section 5.3 of > draft-ietf-mmusic-sctp-sdp-15. > As multiplexing of multiple SCTP associations over one DTLS connection > is not considered by draft-ietf-mmusic-sctp-sdp, > and as there can be just one DTLS connection within one BUNDLE group > (potentially used by multiple media descriptions within this BUNDLE group) > my understanding is that in fact there can be just one SCTP association > over DTLS within such a BUNDLE group. > Therefore I thought there's no need to define a multiplexing semantic > for the a=dcmap (and a=dcsa) attribute (as described in the 3rd paragraph). > > I am not sure "Multiplexing of this attribute is only applicable when > associated with X/DTLS/SCTP "m" line" would be consistent > with the intended meaning of the 3rd paragraph. > >> >> 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. >> * 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. > [Juergen] I see, thanks, > Thus contact name would then e.g. be "MMUSIC Chairs"? Yeah, I think so. 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 >>> > > _______________________________________________ > mmusic mailing list > mmusic@ietf.org > https://www.ietf.org/mailman/listinfo/mmusic >
- Re: [MMUSIC] New Version Notification for draft-i… Juergen Stoetzer-Bradler
- Re: [MMUSIC] New Version Notification for draft-i… Paul Kyzivat
- Re: [MMUSIC] New Version Notification for draft-i… Juergen Stoetzer-Bradler
- Re: [MMUSIC] New Version Notification for draft-i… Paul Kyzivat
- Re: [MMUSIC] New Version Notification for draft-i… Christian Groves
- Re: [MMUSIC] New Version Notification for draft-i… Juergen Stoetzer-Bradler
- Re: [MMUSIC] New Version Notification for draft-i… Christian Groves
- Re: [MMUSIC] New Version Notification for draft-i… Paul Kyzivat