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

[Flemming Andreasen <[e-mail]>]

Apologies for joining in late here, but I would like to go back to the 
beginning of this thread to understand better why we believe there is a 
need for attributes to specifically define whether they can be used with 
the "dcsa" attribute.

The way I see it, the "dcsa" attribute is simply an encapsulating 
attribute that specifies attributes for the data channel sub-protocol. 
What I believe we need here is a set of clear procedures that explain 
how you take those encapsulated procedures, "decapsulate" them and 
negotiate based on the resulting set of parameters (which may need to 
include a few parameters from the media description containing them). 
This is similar to the approach we took with SDP Capability Negotiation 
(RFC 5939). It has the benefit of specifying a generic algorithm for 
dealing with these, and above and beyond that, it's up to the entity 
generating the SDP to include a set of parameters that make sense for 
the given sub-protocol. This is similar to what we do with normal SDP 
(i.e. don't specify all the valid combinations) and avoids the rather 
painful approach that we have with mux-attributes.

Thanks

-- Flemming



On 12/11/15 10:25 AM, Paul Kyzivat wrote:
> On 12/10/15 7:25 PM, DRAGE, Keith (Keith) wrote:
>> I agree with Christian.
>>
>> But Paul and myself have had this discussion before. He seems 
>> convinced we can essentially put stuff in the IANA registry that 
>> needs to be in an RFC.
>
> Keith - yes, we continue to disagree. But not for the reason you say. 
> I do not, and have never, proposed that things be put into the 
> registry *instead* of into a document.
>
> But I do believe that registries are important as an index/discovery 
> tool. You cannot expect people to be aware of every pertinent RFC that 
> may have been published that pertains to something of interest. If I 
> have an interop problem with a new peer, and see something being used 
> that I am not familiar with, then I need a way discover the specs that 
> might pertain to that. The IANA registries serve that function.
>
> (There are *some* cases where the registries are more important. When 
> there is something where the bar for extension is low, and no public 
> document is required, then the registry becomes only public place to 
> learn about it.)
>
>> It is probably worth others (such as the WG chairs) weighing on this 
>> discussion.
>
> Agreed.
>
>     Thanks,
>     Paul
>
>> Keith
>>
>> -----Original Message-----
>> From: mmusic [mailto:[e-mail]] On Behalf Of Christian 
>> Groves
>> Sent: 11 December 2015 00:21
>> To: [e-mail]
>> Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
>>
>> 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:[e-mail]] On Behalf Of
>>>>>>> Christian Groves
>>>>>>> Sent: 01 December 2015 00:53
>>>>>>> To: [e-mail]
>>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>> _______________________________________________
>> mmusic mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> .
>