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

Christian Groves <Christian.Groves@nteczone.com> Fri, 11 December 2015 00:20 UTC

Return-Path: <Christian.Groves@nteczone.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 D59AD1B3057 for <mmusic@ietfa.amsl.com>; Thu, 10 Dec 2015 16:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_LOW=-0.7] 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 DeDiM-KzRZ2R for <mmusic@ietfa.amsl.com>; Thu, 10 Dec 2015 16:20:46 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D3D1AD0A7 for <mmusic@ietf.org>; Thu, 10 Dec 2015 16:20:45 -0800 (PST)
Received: from ppp118-209-221-213.lns20.mel8.internode.on.net ([118.209.221.213]:51926 helo=[192.168.1.22]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from <Christian.Groves@nteczone.com>) id 1a7BRw-00310b-1U for mmusic@ietf.org; Fri, 11 Dec 2015 11:20:40 +1100
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> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <566A16D2.1070108@nteczone.com>
Date: Fri, 11 Dec 2015 11:20:34 +1100
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: <566903E3.8020108@alum.mit.edu>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: cserver5.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RRm6bI5Elg5wrgyKVlQrJ8Cxlv4>
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, 11 Dec 2015 00:20:50 -0000

Hello Paul,

On 10/12/2015 3:47 PM, Paul Kyzivat wrote:
> On 12/9/15 11:04 PM, Christian Groves wrote:
>> Hello Juergen and Paul,
>>
>> The proposed text by Juergen is OK.
>>
>> Paul: Is an IANA registry the right place to capture the nuances of what
>> you're describing below? I agree that when people are defining new
>> attributes that they should consider their use with data channels, but
>> shouldn't that be documented in an RFC rather than the IANA registry?
>> People need to read the RFC rather than simply relying on the registry.
>
> It shouldn't *only* be in the IANA registry. The registry serves as an 
> index getting you to the right place, and helping you figure out what 
> you need to read.
[CNG] This is what I was getting at. It not just a registry update we're 
talking about there's a much more significant document explaining the 
use of the attributes with dcsa.
>
> Won't it be confusing if the registry covers usage of attributes a 
> session, media, and source level but doesn't cover their use in dcsa?
[CNG] The registry is a short cut. Even if the registry mentions that 
its a source attribute, a person still needs to read the RFC to see how 
it works. I see that people want to use an attribute for its 
functionality not because of what the IANA reg says.
>
> If this isn't needed for dcsa, then by the same logic we ought to 
> strip out that other information, and reduce the table to contain only 
> references to documents.
>
>> Also isn't the consequence of what you're suggesting is that another
>> draft similar to draft-ietf-mmusic-sdp-mux-attributes would have to be
>> completed in order to populate the IANA registry field that you're
>> proposing?
>
> Perhaps. We'd have to discuss the best way. It may be that most of the 
> existing attributes can be covered with a couple of default rules, and 
> maybe a few exceptions.
[CNG] Still the analysis of each attribute would need to be done and 
documented to get to the few rules. I not completely against doing this, 
I'm just keen to get this work finished and this will just delay things.

Regards, Christian

>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>
>> On 10/12/2015 2:43 AM, Paul Kyzivat wrote:
>>> Juergen and others,
>>>
>>> What you have below is a good start.
>>>
>>> I still think we need to at least specify how dcsa impacts IANA
>>> registration of attributes.
>>>
>>> The attribute registration is (going to be) updated so that there is
>>> one table containing all attributes, with fields indicating for each
>>> attribute whether it can be used at session level, media level, or
>>> source level.
>>>
>>> Now consider an attribute usable at media and/or source level:
>>>
>>> It *might* *also* be usable with dcsa, or it might not. That will at
>>> least in part be determined by whether the protocol that it applies to
>>> can run over a data channel.
>>>
>>> There was a suggestion (Keith?) that media level attributes be
>>> implicitly allowed with dcsa if the protocol they apply to is defined
>>> over a data channel. I find that plausible. But then the instructions
>>> for registration ought to say that. Also, if there can be exceptions
>>> (attributes that *can't* be used with dcsa even when the protocol is
>>> defined over data channel) then there should be a way to register that.
>>>
>>> Source level attributes add another complication. They only apply over
>>> RTP. For now, RTP isn't defined over a data channel. (Though in
>>> principle it *could* be.) If it were, then I suppose the ussage would
>>> have to be 'a=dcsa nn source ...'. I don't think we need to deal with
>>> that right now.
>>>
>>> And then there is the possibility of new attributes being defined that
>>> can be used *only* with dcsa, not directly at media level:
>>>
>>> If this is because the protocol is only defined to run over a data
>>> channel, then it could possibly be registered as a media level
>>> attribute (which is then allowed by default with dcsa). If the
>>> protocol were ever defined over another transport the sdp would be
>>> ready for it.
>>>
>>> But if, for some reason, the protocol can run over a data channel and
>>> also over some other transport, but for some reason a particular
>>> attribute only applies with data channels, or only applies without
>>> data channels, then there ought to be a way to record that in the
>>> registry.
>>>
>>> The worst case is for every spec that defines an attribute to pick its
>>> own way to specify all this, and for there to be no hint in the iana
>>> registry.
>>>
>>> IMO it is still better for the iana registry to be given another field
>>> to indicate applicability with data channels.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>> On 12/9/15 8:24 AM, Juergen Stoetzer-Bradler wrote:
>>>> 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)
>>>>>>>>>
>>>>>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>