Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 12 February 2016 17:39 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 6FCB11A8715 for <mmusic@ietfa.amsl.com>; Fri, 12 Feb 2016 09:39:53 -0800 (PST)
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 Pgflz2E4lS_7 for <mmusic@ietfa.amsl.com>; Fri, 12 Feb 2016 09:39:52 -0800 (PST)
Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31BC61A7030 for <mmusic@ietf.org>; Fri, 12 Feb 2016 09:39:52 -0800 (PST)
Received: from resomta-ch2-01v.sys.comcast.net ([69.252.207.97]) by resqmta-ch2-03v.sys.comcast.net with comcast id HVfF1s00526dK1R01Vfrfr; Fri, 12 Feb 2016 17:39:51 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-01v.sys.comcast.net with comcast id HVfq1s00Y3KdFy101Vfqd3; Fri, 12 Feb 2016 17:39:51 +0000
To: Flemming Andreasen <fandreas@cisco.com>, mmusic@ietf.org, "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>, "bradler >> Juergen Stoetzer-Bradler" <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <565C6CE3.3050007@alum.mit.edu> <565CDF90.7050107@nteczone.com> <565CEA14.2040607@alum.mit.edu> <565CEF7B.7010305@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE16A00@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BCF663.7020708@alum.mit.edu> <56BCF97F.8000404@cisco.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56BE18E6.2050306@alum.mit.edu>
Date: Fri, 12 Feb 2016 12:39:50 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BCF97F.8000404@cisco.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=1455298791; bh=EbKvpAoKTvT1HQjM6KX4Gq+3PwntWLd2hNstYUqr4ig=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=BWDllmJP3Ib3LQxhWWh4Gwv7qR09ZiVaYTCb4r4Dp3zWiHYSHhf7Uf8BGBTiSaklz 0XoPimqxFDAGXHBCY4dGE6JqX2FgSLwRZA3Lz6dTfE8F5r3vfzZsjnHQx5oyTdufA1 iR84729fIQyFLM5+D+zYm0+bDGUkD6iiF16rw6hwcBfLIG2I1eFUKtFVDGl1WAO5Iz 5pkhQ6W1PjjE4q7OKZ8xa0nANgsEWae3vKdMwtc/py+DXXBNGm2dBon+v8V2m+ugfZ wx4ucpwFeDtnIt/W2Pt9RNKLrkvO3JFBBERRg+I1HThJDPj+ZjSkp/Sl+Q752RMG/v RX3A4y2SwX7cw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/hksv0aI8sES8zPMaDosIrhN-Cjg>
Cc: draft-ietf-mmusic-data-channel-sdpneg@ietf.org
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
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, 12 Feb 2016 17:39:53 -0000

On 2/11/16 4:13 PM, Flemming Andreasen wrote:

>>> We are getting closer, but it's still not obvious to me that you cannot
>>> use an attribute with dcsa if it has not been explicitly defined for the
>>> attribute in question.
>>
>> Can you give me an example?
>>
> How about preconditions ?

I don't see how any of the currently defined precondition types 
(connectivity, qos, security) make sense at the data channel level. But 
all of them could make sense when applied to the overall SCTP 
association over which the channels run.

I suppose *in theory* some hypothetical new precondition type might 
apply to a channel, but we have nothing suggesting that.

I will grant that we could just take the position that any attribute can 
be used anywhere, and that the general "ignore if you don't understand" 
rule will prevent problems.

My basic concern is that when an attribute is used in some context, that 
the semantics for such use are well defined, so that an independent 
observer can determine whether the usage is proper.

	Thanks,
	Paul