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

[Christer Holmberg <[e-mail]>]

Great! __

Can I submit a new version of the draft?

Regards,

Christer

On 04/12/2018, 19.36, "Ben Campbell" <[e-mail]> wrote:

    I can live with it :-)
    
    > On Dec 4, 2018, at 7:13 AM, Christer Holmberg <[e-mail]> wrote:
    > 
    > Are people ok with TBD?
    > 
    > Regards,
    > 
    > Christer
    > 
    > 
    > On 03/12/2018, 8.15, "Suhas Nandakumar (snandaku)" <[e-mail]> wrote:
    > 
    > 
    >    ________________________________________
    >    From: Christer Holmberg <[e-mail]>
    >    Sent: Sunday, December 2, 2018 3:32 AM
    >    To: Ben Campbell
    >    Cc: Suhas Nandakumar (snandaku); [e-mail]; [e-mail]; [e-mail]; The IESG; [e-mail]
    >    Subject: Re: Mux category for non-muxable protocols (was Re: [MMUSIC] Use of the "TBD" Mux Category in bfcpbis.)
    > 
    >    Hi,
    > 
    >> 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? T
    >> BD doesn’t seem right, but that’s what we’ve used so far.
    > 
    >    Well, we don't know whether someone in the future will make BFCP muxable, and with TBD I assume such work would only require an extension draft defining the mux procedures.
    > 
    >    If we choose another value), then I assume a future work to make BFCP muxable would require another BFCPbis.
    > 
    >    So, my suggestion is to use TBD.
    > 
    >    [Suhas] Having thought about it a bit more, i seem to agree with Christer here.
    > 
    >    Regards,
    > 
    >    Christer
    > 
    > 
    >> On Nov 28, 2018, at 2:29 AM, Christer Holmberg <[e-mail]> 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" <[e-mail]> wrote:
    >> 
    >>   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.
    >>>>> 
    >>>>> 
    >>>>> 
    >>>>> 
    >>> 
    >>> 
    >> 
    >> 
    >> 
    > 
    > 
    > 
    > 
    >