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

Flemming Andreasen <fandreas@cisco.com> Fri, 19 February 2016 17:24 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 4A36B1B330B for <mmusic@ietfa.amsl.com>; Fri, 19 Feb 2016 09:24:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.307
X-Spam-Level:
X-Spam-Status: No, score=-13.307 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.006, 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 P5Eh9tmvrpdR for <mmusic@ietfa.amsl.com>; Fri, 19 Feb 2016 09:24:49 -0800 (PST)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E143C1B3309 for <mmusic@ietf.org>; Fri, 19 Feb 2016 09:24:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15116; q=dns/txt; s=iport; t=1455902688; x=1457112288; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=8Ft+0UMIeM16g+h1tw+a+ji60C8wPanB1clBkXhgNQM=; b=frWLQoiJZeLHBBg9ai1dmFN2IBadIGg0+rhqnZeKmW718ytOBpzxdTZD cAzvnlNBnjbb1IH/Jttvx5X+zcxIxfxNEurIo8QNXypL+PTP3Ow9jV4UR f6ppMnci1okGJaiumEnSqRXEh1T+n7fH7t6GjwOAdbz2ijK8l6Bv0uWUi s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLBQAKT8dW/5ldJa1eDoMsUm24MoIhg?= =?us-ascii?q?WghhSJKAoFWORMBAQEBAQEBZCeEQQEBAQMBIxVABgsLGAICBRYLAgIJAwIBAgF?= =?us-ascii?q?FBgEMCAEBBYgJCA6sTo8KAQEBAQEBAQEBAQEBAQEBAQEZe4UXhDuEBREBgx6BO?= =?us-ascii?q?gWNKnSIaY1eiSGFUo5IIgI+gylZHi4BhwqBMQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,471,1449532800"; d="scan'208";a="75040655"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 17:24:47 +0000
Received: from [10.98.149.195] (bxb-fandreas-8812.cisco.com [10.98.149.195]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u1JHOkoF000360; Fri, 19 Feb 2016 17:24:46 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> <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> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com> <56C6156C.2070308@cisco.com> <56C71EF3.6040208@alcatel-lucent.com>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <56C74FDE.4040902@cisco.com>
Date: Fri, 19 Feb 2016 12:24:46 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56C71EF3.6040208@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/bDoXsJu94KhhoumoFSifCtN0HG4>
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, 19 Feb 2016 17:24:52 -0000


On 2/19/16 8:56 AM, Juergen Stoetzer-Bradler wrote:
> Flemming,
>
> Regarding
>> Sounds reasonable with the caveat that you may have attributes 
>> defined for use with a particular sub-protocol outside the 
>> subprotocol draft itself (e.g. because such an attribute was either 
>> defined subsequently or its use with a specific subprotocol is 
>> defined subsequently). If so, we would need an IANA registry 
>> structure (under SDP) that for each subprotocol defines the set of 
>> attributes that have been defined with specific semantics for that 
>> subprotocol. 
>
> Let's assume a future document defines how to establish MSRP sessions 
> over a transport protocol unequal to TCP, TLS, or data channel, and 
> that this document also defines a new MSRP related attribute, whose 
> semantic is only defined for this new transport case (like a maximal 
> MSRP chunk size specific for the new transport). I assume that this 
> future document would request to add this new attribute to one of the 
> existing IANA SDP attribute tables (assumingly to the "att-field 
> (media level only)" table).
So far so good, however the case I had in mind is one where the new 
attribute would apply to one or more existing subprotocols .
> Let's further assume that an implementation creates an SDP offer for 
> an MSRP session over a data channel and adds this new attribute as 
> dcsa embedded MSRP subprotocol attribute (for whatever reasons).
>
> Somebody seeing and inspecting this SDP offer could use the dcmap 
> attribute's subprotocol value "MSRP" to get a reference to the 
> msrp-usage-data-channel document. That document would not mention that 
> new attribute at all. The next step could then be to consult the IANA 
> SDP tables, and there this new attribute would be found together with 
> a reference to this future document.
> As assumingly this new MSRP related attribute would only be defined 
> for this new transport,
While that is certainly a valid use case, I wasn't thinking of 
restricting it to that and hence the request for an actual sub-registry 
for each of these subprotocols to register attributes that can be used 
with each of them (some attributes may apply to multiple).

> I think this new attribute should then be ignored by the recipient of 
> this SDP offer.
> Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 
> now contains two related recommendations:
>
> 'SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 
> attribute is unknown.
>  *  The receiver of such an SDP offer or answer SHOULD ignore this 
> entire "a=dcsa" attribute line.
>
> SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 
> attribute is known, but whose subprotocol attribute semantic is not 
> known for the data channel transport case.
>  *  The receiver of such an SDP offer or answer SHOULD ignore this 
> entire "a=dcsa" attribute line.'
>
> Would these recommendations address the case you are describing?
>
They only address the case(s) partally per the above.

Thanks

-- Flemming


> Thanks,
> Juergen
>
>
>
> On 18.02.2016 20:03, EXT Flemming Andreasen wrote:
>>
>>
>> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote:
>>> Flemming,
>>>
>>> Regarding
>>>> 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. 
>>>
>>> On Friday Paul mentioned in his email two potential use cases, where 
>>> no subprotocol identifiers might be added to a data channel's dcmap 
>>> attribute. In my last email I hadn't thought of such cases. If we 
>>> don't want to exclude such cases, then requiring the subprotocol ids 
>>> always to be present might indeed be too restrictive.
>>>
>>> Regarding
>>>> 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 ? 
>>>
>>> I now think that the sdpneg draft might recommend SDP offerers and 
>>> answerers to always add a subprotocol identifier to a data channel's 
>>> dcmap attribute if dcsa embedded attributes are also negotiated for 
>>> the data channel's subprotocol. I also think we could explicitly add 
>>> text to sdpneg saying that subprotocol identifiers should be added 
>>> to the IANA Websocket (and in future combined data channel) 
>>> registry. And that this registration should be done via a document, 
>>> which then explicitly describes the usages and semantics of dcsa 
>>> embedded subprotocol attributes, _if_ those usages or semantics 
>>> deviate from cases, where these attributes are not dcsa 
>>> encapsulated. I think that in those cases, where the usage and 
>>> meaning of an attribute (always related to the data channel's 
>>> subprotocol) does not deviate from the non-dcsa encapsulated use 
>>> cases, such an attribute may not explicitly need to be described for 
>>> data channel usage. But I think it might be helpful to explicitly 
>>> say so in the sdpneg draft.
>>>
>>> Somebody inspecting an SDP offer or answer, which was generated by 
>>> an implementation following these two recommendations (and which 
>>> hence contains an IANA registered subprotocol id if it contains any 
>>> dcsa embedded attributes), could then refer to that IANA table, 
>>> would then find the reference to the document, which defines this 
>>> subprotocol id for data channel usage, and there could check if any 
>>> of the dcsa embedded attributes has a data channel specific 
>>> semantic. If yes, that specific semantic would be described in that 
>>> document. If such a specific semantic were not described in that 
>>> document, then the default usage and semantic of the attribute would 
>>> apply also to that data channel transport case.
>>>
>> Sounds reasonable with the caveat that you may have attributes 
>> defined for use with a particular sub-protocol outside the 
>> subprotocol draft itself (e.g. because such an attribute was either 
>> defined subsequently or its use with a specific subprotocol is 
>> defined subsequently). If so, we would need an IANA registry 
>> structure (under SDP) that for each subprotocol defines the set of 
>> attributes that have been defined with specific semantics for that 
>> subprotocol.
>>
>>
>>> But in that context I'd have an IANA table related question.
>>> A certain subprotocol might be defined for Websocket usage as well 
>>> as for data channel usage. MSRP is already such a case, where 
>>> draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP 
>>> over data channels, and where draft-pd-dispatch-msrp-websocket 
>>> defines how to use MSRP over Websockets.
>>> Would the IANA WebSocket Subprotocol Name Registry on 
>>> http://www.iana.org/assignments/websocket/websocket.xml then contain 
>>> two MSRP related rows? Or just one row containing references to both 
>>> the Websocket and data channel documents?
>>> Should we add related text to the IANA registration section of the 
>>> sdpneg draft?
>> See above.
>>
>> Thanks
>>
>> -- Flemming
>>>
>>> Thanks,
>>> Juergen
>>>
>>>
>>> On 12.02.2016 15:52, EXT Flemming Andreasen wrote:
>>>>
>>>>
>>>> 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
>>>>>>>>>>>
>>>
>>>
>>> .
>>>
>>
>
>