Re: [MMUSIC] Use of the "TBD" Mux Category in bfcpbis.

[Ben Campbell <[e-mail]>]

Does anyone have further thoughts on this?

> On Oct 24, 2018, at 1:22 PM, Ben Campbell <[e-mail]> wrote:
> 
> Signed PGP part
> Hi Suhas,
> 
> As I mentioned, I am not suggesting we add this to the mux-attributes draft. My question was, what is the correct category to use for a new attribute associated with a non-muxable protocol?
> 
> Ben.
> 
>> On Oct 24, 2018, at 1:08 PM, Suhas Nandakumar (snandaku) <[e-mail]> wrote:
>> 
>> Hi Ben
>> 
>> The mmusic WG agreed  to freeze further categorizations inside mux draft and that any new draft has to define the categories for the attributes they define. In this case the bis draft needs to define the needed categories and update IANA.
>> The procedures for the same as defined in Mux draft as well
>> 
>> Thanks
>> Suhas
>> Sent from my iPhone
>> 
>>> On Oct 24, 2018, at 9:37 AM, Ben Campbell <[e-mail]> wrote:
>>> 
>>> Hi,
>>> 
>>> I’d like to get the opinions of MMUSIC participants on the use of the “TBD” mux category.
>>> 
>>> draft-ietf-bfcpbis-rfc4583bis ( in IESG evaluation) defines a new SDP attribute “bfcpver”. Since it’s associated with bfcp, which does not specify mux/demux procedures, the draft gives it a mux-category of “TBD”. Is that the right choice? If not, what is?
>>> 
>>> draft-ietf-mmusic-sdp-mux-attributes describes TBD as follows:
>>> 
>>>> The attributes in the TBD category have not been analyzed under the
>>>> proposed multiplexing framework and SHOULD NOT be multiplexed.
>>> 
>>> However, mux-attributes goes on to use TBD for several attributes, including one for bfcp, with notes to the effect of the following:
>>> 
>>>> NOTE: As per section 9 of [I-D.ietf-mmusic-sdp-bundle-negotiation
>>>> ],
>>>> there exists no publicly available specification that defines
>>>> procedures for multiplexing/demultiplexing BFCP streams over a single
>>>> 5-tuple.  Once such a specification is available, the multiplexing
>>>> categories assignments for the attributes in this section could be
>>>> revisited.
>>> 
>>> That doesn’t really fit the definition. It seems more like the attributes _have_ been analyzed, and the note states the conclusion.
>>> 
>>> This is further complicated by the fact that  the only change 4566bis allows to an existing mux-category registration is to move from “TBD” to something else. Any other choice will make life harder if we later update bfcp with mux/demux procedures.
>>> 
>>> I am not (yet) suggesting a change to mux-attributes or 4566bis; I’m just trying to figure out the right way to specify mux-categories for new attributes.
>>> 
>>> Thanks!
>>> 
>>> Ben.
>>> 
>>> 
>>> 
>>> 
> 
>