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

From: Ben Campbell <[email-masked]>
Date: Tue, 27 Nov 2018 16:47:57 -0600

Does anyone have further thoughts on this?

> On Oct 24, 2018, at 1:22 PM, Ben Campbell <[email-masked]> 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) <[email-masked]> 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 <[email-masked]> 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.
>>> 
>>> 
>>> 
>>> 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 28 Nov 2018 08:29:57 +0000

Hi,

While we may not add new attributes to the mux-category draft, don't we have to CHANGE the category of some BFCP related attributes already in the draft, in order to align with BFCPbis?

Regards,

Christer

On 28/11/2018, 0.48, "Ben Campbell" <[email-masked]> wrote:

---

From: Ben Campbell <[email-masked]>
Date: Wed, 28 Nov 2018 10:13:23 -0600

There are some misalignments between BFCPbis and mux-category that we need to deal with, yes.

But my question was more general: What is the correct category to use for a new attribute associated with a known-to-be-non-muxable protocol? TBD doesn’t seem right, but that’s what we’ve used so far.

(I changed the email subject to match)

Ben.

> On Nov 28, 2018, at 2:29 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 29 Nov 2018 00:47:24 -0800

Hello Ben

Please see inline

On Wed, Nov 28, 2018 at 8:14 AM Ben Campbell <[email-masked]> wrote:

> But my question was more general: What is the correct category to use for
> a new attribute associated with a known-to-be-non-muxable protocol? TBD
> doesn’t seem right, but that’s what we’ve used so far.
>
>
[Suhas]  The only 2 options i see with the categorization is either
"CAUTION" or "SPECIAL". Former implies multiplex at your own risk and later
requires specification that defines such a attribute to further clarify on
the behavior under multiplexing, if allowed.

> > While we may not add new attributes to the mux-category draft, don't we
> have to CHANGE the category of some BFCP related attributes already in the
> draft, in order to align with BFCPbis?
> >
> > Regards,
> >
> > Christer
> >
> >> 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.
> >>
> >>> 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.
> >>>> 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?
> >>>>
> >>>> However, mux-attributes goes on to use TBD for several attributes,
> including one for bfcp, with notes to the effect of the following:
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> >
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>