Re: [MMUSIC] Mux Category and RFC4566bis

[Paul Kyzivat <[e-mail]>]

On 8/10/19 2:46 AM, Christer Holmberg wrote:
> Hi,
> 
>> After further consideration I concluded that maybe the problem isn't as bad as I was thinking, at least for 4566bis. >bwtype and attribute are the only parameters that 4566bis is concerned with that have a mux category. And for >bwtype it isn't too confusing because nothing is really being changed. I'm just going to punt on saying anything >about how one would choose the mux category for a new bwtype.
>>
>> I just submitted -37 of 4566bis. Please take a look and see if it works for you.
> 
> I think it would have been useful to have a few words about b= is sometimes referred to as an attribute, and point out that the mux category needs to be defined to new bandwidth types.

At this point, lets see what other feedback there is before doing more.

	Thanks,
	Paul

> Otherwise it looks ok.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> On 8/9/19 4:06 PM, Christer Holmberg wrote:
>> Hi,
>>
>>       >>>     Upon looking further at mux-attributes, perhaps it is a more likely
>>       >>>     candidate to reference criteria for new parameter values. In particular,
>>       >>>     section 4 (SDP Attribute Analysis Framework) comes close to serving the
>>       >>>     purpose.
>>       >>
>>       >> I agree. When one defines a new attribute, one needs to read the semantics of the mux categories, and pick
>>       >> the one that fits the new attribute. I am not sure what else could be said regarding "how to choose a category".
>>       >
>>       > Me either. But if an expert were charged with approving a new attribute,
>>       > what criteria would he use for deciding if the mux category was "right"?
>>       > Is the answer just "IESG review"?
>>       
>>       New attributes should also be reviewed by the SDP directorate, right? I guess we just have to assume there are people who are able to make the correct judgement.
>>
>>       Normally I think it shouldn't be that difficult to pick the mux category.
>>
>>       As a last resort, I guess one can assign a TBD category. However, I think there should be a good technical reason for that. One should not assign a TBD category just because one is lazy and doesn't want to bother with the mux stuff...
>>
>> ---
>>           
>>       >>>     I have a concern about it as it stands: this section only talks about
>>       >>>     *attributes*. But mux categories apply to many SDP parameters other than
>>       >>>     attributes. I *think* this is perhaps just sloppy terminology, and it is
>>       >>>     intended to apply more generally to parameters that are affected by mux
>>       >>>     category.
>>       >>
>>       >> What other SDP parameters than attributes and b= do you think it applies to?
>>       >
>>       > mux-attributes updates a whole bunch of parameter registries. Other than
>>       > the actual attribute registries, none of them *are* attributes. Many of
>>       > them are carried in a field in a value of some attribute, but that is
>>       > different from them *being* an attribute.
>>       
>> Ok, I hear you.
>>
>> But, as you say, they are still associated with attributes.
>>
>>       >> As far as calling b= an attribute is concerned, RFC 3556 actually DOES call it an attribute (see e.g., Section 2). Same thing for RFC 3890 (see e.g., section 1.1).
>>       >>
>>       >> So, perhaps we could add some text to RFC4566bis saying that b= is often referred to as an attribute?
>>       >
>>       > It may be that the most practical fix is to put some explanation
>>       > somewhere in 4566, even though that is probably not the most ideal way.
>>       > I'm groping for how to do that.
>>       
>>       I would suggest something like this to work on:
>>
>>       "Note that the bandwidth-field is often referred to as an attribute in other specifications. In addition, reference-to-mux-categories defines mux categories for the different bandwidth types.
>>        As for attributes, and attribute values, when a new bandwith type is defined the mux category for the type MUST be specified."
>>       
>>       > I'm wondering whether it might actually make sense to create another
>>       > document that factors the Mux Category *framework* out from the specific
>>       > analysis for preexisting values. It would have more in the way of
>>       > guidance on how to choose. And maybe it could also consider what needs
>>       > to be done in the future when another SDP parameter is defined that has
>>       > interactions with bundle. (Can we do an update to a document that hasn't
>>       > yet made it to RFC?)
>>
>>       My suggestion would be to add text to 4566bis based on this
>> discussion, publish draft-mux-categories in its current form, and then
>> wait and see whether there in future will be a need for an additional
>> document. It can be called "MUX Clarifications" - similar to the tons
>> of offer/answer clarification documents we have produced :)
> 
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
> 
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>