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

Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Wed, 09 December 2015 13:24 UTC

Return-Path: <juergen.stoetzer-bradler@alcatel-lucent.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 661F71A9147 for <mmusic@ietfa.amsl.com>; Wed, 9 Dec 2015 05:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level:
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 iZUm39rB6A8v for <mmusic@ietfa.amsl.com>; Wed, 9 Dec 2015 05:24:45 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7BF1A9135 for <mmusic@ietf.org>; Wed, 9 Dec 2015 05:24:44 -0800 (PST)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id EDC989BC1EB0 for <mmusic@ietf.org>; Wed, 9 Dec 2015 13:24:40 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id tB9DOgOq025780 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Wed, 9 Dec 2015 14:24:42 +0100
Received: from [149.204.68.185] (135.239.27.40) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 9 Dec 2015 14:24:38 +0100
To: mmusic@ietf.org
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>
From: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
Message-ID: <56682B96.9020008@alcatel-lucent.com>
Date: Wed, 09 Dec 2015 14:24:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BADE16A00@FR712WXCHMBA11.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [135.239.27.40]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/bmU6NndSnUHR5qRPLXzPfHEUtU0>
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: Wed, 09 Dec 2015 13:24:50 -0000

Paul, Christian, Keith,

Would propose to add following two new paragraphs to the end of current section 5.1.2.1 (dcsa 
Attribute) in order to more clearly describe the relationship of a subprotocol's attribute and the 
subprotocol's transport protocol, especially data channel.


    It is assumed that in general the usages of subprotocol related media
    level attributes are independent from the subprotocol's transport
    protocol.  Such transport protocol independent subprotocol related
    attributes are used in the same way as defined in the original
    subprotocol specification, also if the subprotocol is transported
    over a data channel and if the attribute is correspondingly embedded
    in a "a=dcsa" attribute.

    There may be cases, where the usage of a subprotocol related media
    level attribute depends on the subprotocol's transport protocol.  In
    such cases the subprotocol related usage of the attribute is expected
    to be described for the data channel transport, e.g. in an extension
    of the original subprotocol specification.


Section 5.1.2 already explicitly mentions that (subprotocol related) media level attributes may 
follow a data channel declaration (the a=dcmap line). Thus the restriction to subprotocol related 
media level attributes only  seems to be covered already.

Thanks,
Juergen


On 01.12.2015 02:12, DRAGE, Keith (Keith) wrote:
> I think we need to be a little bit careful here.
>
> In a large number of cases, the use of the attribute will be unaltered by the transport that is being used, and I do not think we should have a need of saying anything if this is the case - it should be the default.
>
> So for example for MSRP, there are a number of attributes associated with MSRP - for file transfer and so on, and as far as I can tell, they are used when MSRP is sent over a data channel in exactly the same way as when MSRP is sent over TCP or SCTP. We don't write special rules for TCP, so why write special rules for datachannel.
>
> We do need to identify how we document any special cases, and yes when we find them, drafts like the msrp draft are the way to do that.
>
> Additionally, if we find when defining a new attribute, that it is inappropriate for datachannel usage in some way, then we can write that in the defining specification for the new attribute (although I suspect in this case it will be inappropriate to other transports than just datachannel).
>
> I do assume this entire discussion is limited to attributes that can be applied to media lines. We might find it useful to say that in the general draft, if we have not done so already.
>
> Regards
>
> Keith
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Christian Groves
> Sent: 01 December 2015 00:53
> To: mmusic@ietf.org
> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
>
> Hello Paul,
>
> I actually meant to post the reply to the list, sorry for the confusion.
>
> I do understand your concerns. For multiplexing it makes sense to check all the existing attributes to see whether they're applicable due to the fact that quite alot may be used when multiplexing occurs. I think the data channel usage is quite a bit more narrow in scope.
>
> Whilst this draft does introduce a general purpose mechanism the actual use of the dcsa is being defined by other drafts. E.g.
> draft-ietf-mmusic-msrp-usage-data-channel on MSRP discusses what happens when both a=setup and a=dcsa:setup are present. msrp-cema is another one discussed, etc.
>
> I think you need to understand the application protocol being carried in a data channel before you can say whether particular attributes should be carried in dcsa and what that actually means. Going through the IANA registry wouldn't be trivial and unless the attributes are put in context of an application protocol I don't think it will be terribly helpful.
>
> draft-ietf-mmusic-data-channel-sdpneg in cl.5.1.2.1 does indicate that the dsca parameters follow the procedures defined in the subprotocol specific documents. Maybe we could strengthen this to indicate that the use of dsca by an application protocol should be documented in a specification?
>
>
> Regards, Christian
>
> On 1/12/2015 11:30 AM, Paul Kyzivat wrote:
>> Christian,
>>
>> On 11/30/15 6:45 PM, Christian Groves wrote:
>>> Is this level of detail really needed? There are several drafts for
>>> CLUE, MSRP and BFCP related to the use of this sdpneg mechanism. E.g.
>>> CLUE doesn't use dcsa and MSRP provides guidelines on the use of dcsa.
>>>
>>> Can't we just follow the principle that the use of the dcsa attribute
>>> should be detailed in a specification and leave it at that? I'm not
>>> sure what we gain by analysing every existing attribute and forcing
>>> every new attribute to do this analyses when the set of possible
>>> parameters in likely to be very small.
>> I guess it is arguable both ways. Originally there was only session
>> level and media level. That was always supposed to be identified, but
>> it wasn't always followed.
>>
>> Then we got source level. That has complicated the registry and the
>> usage. I am not convinced that two SDP experts would come up with the
>> same list of which attributes can be used at source level.
>>
>> The dcsa attribute becomes the 4th "level" for attributes. It at least
>> makes sense to me that it ought to be managed analogously to the
>> source attribute. But I agree it doesn't provide the same degree of
>> confusion as the others. It only makes sense if the usage the
>> attribute applies to works over a data channel. And that should be
>> known to whatever is processing the SDP.
>>
>> I see this was a private message. Why don't you repost it on the list
>> and lets see what other people think? (Feel free to repost this reply
>> if you wish.)
>>
>>      Thanks,
>>      Paul
>>
>>> Regards, Christian
>>>
>>> On 1/12/2015 2:36 AM, Paul Kyzivat wrote:
>>>> One thing occurred to me that we may have forgotten about:
>>>>
>>>> This draft introduces the dcsa attribute, which allows other
>>>> attributes to be used in this new scope. It notes that not all
>>>> attributes are suitable for use this way.
>>>>
>>>> ISTM that in the future other attribute definitions should include
>>>> an indication of whether they can be used with dcsa, and the IANA
>>>> registration of the attribute ought to include this. And then there
>>>> is a need to update the iana registry for all the existing attributes.
>>>>
>>>>      Thanks,
>>>>      Paul
>>>>
>>>> On 11/25/15 4:52 AM, Bo Burman wrote:
>>>>> This is to announce a 4 week Working Group Last Call for
>>>>>
>>>>>                   draft-ietf-mmusic-data-channel-sdpneg-06
>>>>>
>>>>> as proposed standard.
>>>>>
>>>>> Please review and provide any comments you may have on the document
>>>>> by Wednesday, December 23, 2015. Comments should be sent to the
>>>>> document authors and the MMUSIC WG list. If you review the document
>>>>> but do not have any comments, please send a note to that effect as well.
>>>>>
>>>>> Please also forward this WGLC call to any other interested parties
>>>>> who may be able to review the draft, asking them to also direct
>>>>> their comments to the authors and the list as above.
>>>>>
>>>>> Thank you!
>>>>>
>>>>>           Bo Burman (MMUSIC co-chair)
>>>>>
>>>>>