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
>