Re: [MMUSIC] Mux category for non-muxable protocols (was Re: Use of the "TBD" Mux Category in bfcpbis.)

Hello Ben

Please see inline

On Wed, Nov 28, 2018 at 8:14 AM Ben Campbell <ben@nostrum.com> wrote:

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

(I changed the email subject to match)
>
> Ben.
>
> > On Nov 28, 2018, at 2:29 AM, Christer Holmberg <
> christer.holmberg@ericsson.com> wrote:
> >
> > 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" <ben@nostrum.com> wrote:
> >
> >    Does anyone have further thoughts on this?
> >
> >> On Oct 24, 2018, at 1:22 PM, Ben Campbell <ben@nostrum.com> 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) <
> snandaku@cisco.com> 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 <ben@nostrum.com> 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.
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >>
> >
> >
> >
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>