Re: [MMUSIC] Mirja Kühlewind's No Objection on draft-ietf-mmusic-sdp-mux-attributes-14: (with COMMENT)

["Ben Campbell" <[e-mail]>]

On 28 Oct 2016, at 3:24, Mirja Kühlewind wrote:

> Hi Suhas,
>
> see below.
>
> On 28.10.2016 06:29, Suhas Nandakumar wrote:
>  >
>  >             2) Is the new registry for the Mux Category really 
> needed? Is it
>  >         expected
>  >             to (much) more categories in future?
>  >
>  >
>  >         [Suhas] -  We need the registry to list the currently 
> defined Mux
>  >         Categories
>  >         and also we do see there might be couple of more categories 
> (if not many)
>  >         that might get defined in the future.
>  >
>  >
>  >     This seems really vague for me. I would assume that you 
> actually don't
>  >     need a registry now and if there will be more categories 
> defined in the
>  >     future (which doesn't seem very likely) a new doc could still 
> define a
>  >     registry and update this RFC.
>  >
>  >
>  >
>  > [Suhas]
>  >  Section 15.2 and its sub-sections assign the multiplexing 
> categories  to
>  > several of the sub-registries in the IANA SDP Parameters registry. 
> This is
>  > done by adding a new column called 'Mux Category' to each of the
>  > sub-registries in the SDP Parameters registry.
>  > Having a registry defined to identify the names of these 
> Multiplexing
>  > categories ( as in Section 15.1) will ensure there is a formal 
> place for
>  > these names and formal rules to expand the category set in the 
> future.
>
> The formal place where these categories are explained is this RFC. 
> This RFC could also talk about the opportunity or even process to 
> expand this list in future. However, as long as it is not clear that 
> any expansion will be really needed in future, I don't see a need for 
> e registry.
>
> That's my view point. Please consult your AD for final advise.

I understand that the working group thinks that the chance that new 
categories will come up is high enough that they prefer to define the 
registry (and more importantly, the registration policy) in advance. I 
agree that this is a borderline case, and reasonable people could go 
either way. I don't think we should overrule the working group consensus 
this late in the process.

Thanks!

Ben.