Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 02 October 2014 01: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 ED9501A888A for <mmusic@ietfa.amsl.com>; Wed, 1 Oct 2014 18:49:08 -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 ZlbYjLpvBeYg for <mmusic@ietfa.amsl.com>; Wed, 1 Oct 2014 18:49:08 -0700 (PDT)
Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 137F11A888C for <mmusic@ietf.org>; Wed, 1 Oct 2014 18:49:07 -0700 (PDT)
Received: from resomta-po-19v.sys.comcast.net ([96.114.154.243]) by resqmta-po-12v.sys.comcast.net with comcast id y1ou1o0035FMDhs011p7iu; Thu, 02 Oct 2014 01:49:07 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-19v.sys.comcast.net with comcast id y1p61o00M3Ge9ey011p6az; Thu, 02 Oct 2014 01:49:07 +0000
Message-ID: <542CAF12.1070600@alum.mit.edu>
Date: Wed, 01 Oct 2014 21:49:06 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <542A9E4B.2050608@nteczone.com> <542AA680.1030809@nteczone.com> <2AB21794-B955-48A3-ACC1-B0D838354BFA@ericsson.com> <542C0DA1.4000903@alum.mit.edu> <542C8D3C.7070105@nteczone.com>
In-Reply-To: <542C8D3C.7070105@nteczone.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=1412214547; bh=iBMowgfZV1M2CbaMvyMojtyNY7tNdGie/r9k7VbnRtw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HGYwFeqWxIRovuc/9ooT0DdJKPh+S6rk+y3QwbK9VkATBsWq3fZ3LIq5FtPQST0Sa W7GVCyfUWFZS+aXTuIfdd3lxyB3Zt5YZR3K9BxCnepH3AvkVzwQR+PNa6DS35WTKAF xYyhkTSwG96SQp6k3GxUp6PreUKA+ZCH0xcg2jtj7h4BH5jHUjI8xUNYEU42npT+JH +jbzzX9lEufrG0b4QZHde/0ls3bqREr7EvaPJHFkivz4hZ0w/eSpG00TJ7vLzrKYLa W5YE0AVYrmdtfKj/jNQ/GKFuADCC5SI4E7pn8lIPQC0Zt9y49h0fJKHZBstpP2uhc6 EsgGTmQAOOSEA==
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/Tfkybk68C_9WjKDhY2ZY8kc-I34
Subject: Re: [MMUSIC] draft-ietf-mmusic-sctp-sdp-07 SCTP SDP syntax question
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: <http://www.ietf.org/mail-archive/web/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: Thu, 02 Oct 2014 01:49:09 -0000

On 10/1/14 7:24 PM, Christian Groves wrote:

>> The association-usage is describing how the association as a whole,
>> including all of the streams, is used/managed.
>>
>> It doesn't provide a means to separately describe how individual
>> streams within it are to be used. If that is to be done in SDP then
>> something like draft-ejzak... would be required.
>
> [CNG] My comments on this are in the context of the note in cl.10 of the
> draft: "[Note] TBD whether a new registry is necessary to register the
> different possible "association-usage" values."

Well, the alternatives to establishing a new registry are:

- use an existing registry
- define all the values directly in the draft.
   (This will then require a revision to define new ones.)

I don't see how we could use an existing one, since the semantics of 
what are being defined are entirely new. (The websocket protocol 
registry isn't right for this. It defines a *protocols* that run over a 
websocket, or at least something similar in nature to a websocket. What 
we are defining here isn't a protocol in the same sense - it is a 
*convention* for how to use an SCTP association including the many 
streams it contains. Each of those streams may have its own protocol.)

We could live without any registry *if* we think there is very low 
likelihood of needing to define new values. But I think it is already 
clear that is a bad assumption.

> I'm just thinking of the specification effort to introduce new
> sub-protocols. Consider a gateway scenario where I have a DTLS/SCTP
> association running datachannel with bfcp and on the other side a SCTP
> association running BFCP. In either scenario bfcp runs in an SCTP
> stream. However it means to introduce BFCP (and any other protocol) we
> have to update two registries with essentially the same value.
>
> If we do have a new registry just for "association-usage" it would be
> good to have some text with regards to a template of information that
> someone registering the information would need to consider. i.e. what
> information would someone need to specify to registry BFCP as opposed to
> just registering BFCP as websocket sub-protocol.

One approach would be to define one new association-usage (beyond the 
one for rtcweb), that says the usages of the individual streams will be 
negotiated with SDP, using something like draft-ejzak. Then go ahead and 
finish that draft.

	Thanks,
	Paul