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

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 9 Dec 2015 14:24:38 +0100

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:[email-masked]] On Behalf Of Christian Groves
> Sent: 01 December 2015 00:53
> To: [email-masked]
> 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)
>>>>>
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Dec 2015 10:43:15 -0500

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.
>
>
> 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
>
>
>> 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
>>
>> 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
>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Dec 2015 15:04:17 +1100

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.

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?

Regards, Christian

On 10/12/2015 2:43 AM, Paul Kyzivat wrote:
> The attribute registration is (going to be) updated so that there is 
> one table containing all attributes, with fields indicating for each 
> 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.
>
> 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.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Dec 2015 23:47:31 -0500

> 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.

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?

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.

> completed in order to populate the IANA registry field that you're

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.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 11 Dec 2015 11:20:34 +1100

Hello Paul,

> index getting you to the right place, and helping you figure out what 
[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.
> 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.
>
[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

>>>>>>>>> but do not have any comments, please send a note to that 
>>>>>>>>> effect as
>>>>>>>>> well.
>>>>>>>>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 11 Dec 2015 00:25:17 +0000

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.

It is probably worth others (such as the WG chairs) weighing on this discussion.

Keith

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 11 December 2015 00:21
To: [email-masked]
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

Hello Paul,

On 10/12/2015 3:47 PM, Paul Kyzivat wrote:
>> 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?
[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.
> 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.
>> 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?
>
[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

>>> least in part be determined by whether the protocol that it applies 
>>> to can run over a data channel.
>>>
>>> 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:
>>>
>>> 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 
>>> 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
>>>
>>>> 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 
>>>> 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
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>> 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
>>>>>
>>>>> check all the existing attributes to see whether they're 
>>>>> applicable due to the fact that quite alot may be used when multiplexing occurs.
>>>>> 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
>>>>>
>>>>>>> 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.
>>>>>>> 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
>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>>> 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!
>>>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Dec 2015 10:25:57 -0500

> 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