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

Flemming Andreasen <fandreas@cisco.com> Fri, 12 February 2016 14:53 UTC

Return-Path: <fandreas@cisco.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 91B731A0A85 for <mmusic@ietfa.amsl.com>; Fri, 12 Feb 2016 06:53:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.302
X-Spam-Level:
X-Spam-Status: No, score=-13.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] 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 efLkmTepvYmy for <mmusic@ietfa.amsl.com>; Fri, 12 Feb 2016 06:52:59 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5C921A09CF for <mmusic@ietf.org>; Fri, 12 Feb 2016 06:52:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7464; q=dns/txt; s=iport; t=1455288778; x=1456498378; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=13ZyZxMqmrZQnVyc9/eAjTFse45YZRhrkDEzi9zMK84=; b=I+kW7sxpITUQO4Fx/OYiqINaIN7hcKtguJSksXDDSBgq4uFryKakErhK IvlV7l0+ohYuyAPlpwzQSaWkiMl2rjVt+qZg1n+5mNdMyZ/wxvlm6++oh CuC/0gGzd1bf9MdXhQK+qY39Gg36pkZJQaOOT9GQP05uIuk+JdTIFiMfe 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuBAAp8b1W/xbLJq1eDoN+bYhbsycXC?= =?us-ascii?q?oUiSgKCAwEBAQEBAYELhEEBAQEDAQEBASAVNgoGCwsYAgIFFgsCAgkDAgECARU?= =?us-ascii?q?wBgEMBgIBAYgOCA6yUI8QAQEBAQEBAQEBAQEBAQEBAQEBARMEe4UWhDaHMoE6B?= =?us-ascii?q?Y0ndIhcjVWJJIVSjj5igylZHi6IKgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,436,1449532800"; d="scan'208";a="631455172"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2016 14:52:56 +0000
Received: from [10.98.149.199] (bxb-fandreas-8816.cisco.com [10.98.149.199]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u1CEqtMC013484; Fri, 12 Feb 2016 14:52:55 GMT
To: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>, Paul Kyzivat <pkyzivat@alum.mit.edu>, mmusic@ietf.org, "DRAGE, Keith (Keith)" <keith.drage@nokia.com>, "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@nokia.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> <56BDB7BC.1060104@alcatel-lucent.com>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <56BDF1C6.9080707@cisco.com>
Date: Fri, 12 Feb 2016 09:52:54 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56BDB7BC.1060104@alcatel-lucent.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Wc-g2mD9eSObXPSv9wS0lKVR804>
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 14:53:01 -0000


On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote:
> Flemming, Paul,
>
> The current a=dcmap related text in 
> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the 
> 'subprotocol' parameter must always be present - rather it is 
> specified as an optional parameter. Thus, current sdpneg text would 
> allow to create an SDP offer for a data channel, which contains one 
> a=dcmap attribute and potentially multiple a=dcsa attributes without 
> the subprotocol actually being given. Based on this discussion I am 
> wondering if the subprotocol parameter should actually be mandatory.
>
It would probably simplify the overall SDP negotiation part, but I don't 
know if it would constrain the way data channels were envisioned to be 
used.


> In the specific case of MSRP, the msrp-usage-data-channel draft says 
> in 5.1.1.1 that the dcmap attribute includes the label and subprotocol 
> parameters. The current text could possible be made more explicit by 
> saying that the 'subprotocol="MSRP"' parameter must always be present.
> Have just submitted version 04 of the msrp-usage-data-channel draft, 
> which proposes to add subprotocol identifier "MSRP" to the WebSocket 
> Subprotocol Name registry. This registry would then associate 
> subprotocol id "MSRP" with the msrp-usage-data-channel document.
> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa 
> attribute are specified. And there the MSRP specific SDP attributes, 
> which can be dcsa embedded, are described.
> 'setup' is an attribute, whose semantic changes when being dcsa 
> embedded and associated with subprotocol MSRP, as compared to the 
> meaning of an "a=setup" media level attribute of a TCP/MSRP m-line. 
> Hence these semantical differences are explicitly addressed in the 
> msrp-usage-data-channel draft.
>
> Regarding sdpneg, I also think that the current text in sdpneg seems 
> to be sufficient regarding the usage of dcsa encapsulated SDP 
> attributes as being bound to the data channel's subprotocol. But as 
> the semantic of a dcsa encapsulated attribute may be subprotocol 
> specific (like 'setup'), I'd now tend to consider the subprotocol 
> parameter in the dcmap attribute as being mandatory, as mentioned 
> above. As already discussed, the Websocket subprotocol registry would 
> then refer to the document, which specifies the subprotocol specific 
> usage of dcsa encapsulated parameters.
>
Ok. Going back to discussion between Paul and I, do you believe that in 
for an attribute to be encapsulated in dcsa, the attribute MUST have 
been explicitly define to support this (Paul's suggestion below) or do 
you believe that this is overly constraining, and if so, how shoud we 
relax it ?

Thanks

-- Flemming


> Thanks,
> Juergen
>
>
> On 11.02.2016 21:52, Flemming Andreasen wrote:
>>
>>
>> On 2/8/16 12:09 PM, Paul Kyzivat wrote:
>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote:
>>>>
>>>>
>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote:
>>>>> On 2/4/16 10:43 PM, Christian Groves wrote:
>>>>>> Isn't this the approach we're taking today?
>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific
>>>>>> drafts are used to describe protocols that use the mechanism (i.e.
>>>>>> draft-ietf-mmusic-msrp-usage-data-channel &
>>>>>> draft-ietf-clue-datachannel).
>>>>>
>>>>> It remains to be seen if that will be enough. E.g., there currently
>>>>> aren't any iana considerations in
>>>>> draft-ietf-mmusic-msrp-usage-data-channel.
>>>>>
>>>>> Suppose I encounter some sdp that uses msrp over a data channel, but
>>>>> that usage is unknown to me. How do I find the spec (the reference to
>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage?
>>>>>
>>>>> I would like to think that the iana registries will allow me to trace
>>>>> back to the relevant specs.
>>>>>
>>>> No disagreement on that part, however having taken another look at 
>>>> both
>>>> sdpneg and the msrp-usage documents, I still don't agree with your
>>>> original request for all (existing and new) attributes to specify how
>>>> they may or may not be used with the dcsa attribute defined by sdpneg.
>>>>
>>>> As Christian noted, the sub-protocol specifics are defined in 
>>>> individual
>>>> documents (like msrp-usage), which calls your the parameters that 
>>>> are at
>>>> least needed to be supported for that usage. Taking MSRP as an 
>>>> example,
>>>> why isn't that enough, and how do you see the resulting set of
>>>> attributes that may or may not be used with MSRP differ between use 
>>>> in a
>>>> data-channel (and hence encapsulated in dcsa) or as a regular media
>>>> stream ?
>>>
>>> Based on this discussion, I conclude that it should be sufficient 
>>> for this draft to say that before an attribute can be used with 
>>> dcsa, such usage must be defined somewhere. This could be either:
>>> - as part of the definition of the attribute, OR
>>> - as part of the definition of the protocol referenced on the m-line.
>>>
>> 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. Clearly, there are attributes 
>> that wouldn't make sense over data channels, just like there are 
>> attributes that don't make sense over particular media descriptions.
>>
>> Again, I'd like to hear from more people on this, including the authors.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Also, it would be good to hear from more people on this, including the
>>>> document authors.
>>>>
>>>> Thanks
>>>>
>>>> -- Flemming
>>>>
>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>>> Regards, Christian
>>>>>>
>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote:
>>>>>>>
>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we 
>>>>>>>> need to
>>>>>>>> expliclty specify attribute interactions for "dcsa", then it 
>>>>>>>> should be
>>>>>>>> part of the IANA registry. What I am not agreeing with at this
>>>>>>>> point is
>>>>>>>> that there is indeed a need to explicitly speficy these
>>>>>>>> interactions as
>>>>>>>> opposed to relying on a more general algorithmic approach (plus 
>>>>>>>> the
>>>>>>>> offerer being responsible for generating a valid offer if he 
>>>>>>>> wants to
>>>>>>>> establish a data channel).
>>>>>>>
>>>>>>> Well, an obvious one is that the protocol(s) the attribute 
>>>>>>> pertains to
>>>>>>> need to be defined to work over data channels.
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Paul
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> mmusic@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> mmusic@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> mmusic@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>> .
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>> .
>>>
>>
>
>