Subject: [MMUSIC] Mux Category and RFC4566bis

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Aug 2019 11:19:13 -0400

Christer, Suhas, and others,

Based on IESG feedback I'm working on clarifying the IANA considerations 
for the various registry tables defined by 4566. In the process of that 
I'm having difficulty deciding what to do about Mux Category.

The document aims to spell out the requirements for registration of new 
parameter values. For the ones that require Mux Category (attributes & 
bwtype) I think it really needs to say *something*.

So far there is *nothing* for bwtype.

For attributes a new registry format is defined and includes the Mux 
Category column, and a reference to the mux-attributes draft, but no 
text saying anything about how the proper value is to be defined for 
future attributes.

Nor, as best I can tell, do the bundle or mux-attributes drafts say 
anything about how one should choose a mux category when defining new 
values in the future. This really needs to be specified.

I'm uncertain where this information ought to be. Does it belong in 
4566bis or in bundle? (I don't think it belongs in mux-attributes since 
that is only intended to "catch up" previously defined parameters.)

I think it will be hard to incorporate it into 4566bis because the 
context needed to talk about it isn't present there - it is dependent on 
bundle. It would perhaps work to just add references to bundle in all 
the places where this should come up, but I think that will require some 
new text in bundle.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Aug 2019 11:39:33 -0400

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

I don't know if it is possible, given it is the the editor's queue, to 
update mux-attributes. Is it *good enough* to reference without change?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2019 18:07:19 +0000

Hi Paul,

>    section 4 (SDP Attribute Analysis Framework) comes close to serving the 
  
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".
  
>    intended to apply more generally to parameters that are affected by mux 
  
What other SDP parameters than attributes and b= do you think it applies to?

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?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Aug 2019 15:24:13 -0400

> 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…

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"?

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

> 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 guess I'll try to come up with something, but then I'll need others to 
review whether I've succeeded in being clear.

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?)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 9 Aug 2019 20:06:36 +0000

Hi,

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

---
        
    > different from them *being* an attribute.
    
Ok, I hear you.

But, as you say, they are still associated with attributes.

    > 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."
    
    > interactions with bundle. (Can we do an update to a document that hasn't 

    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 :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 9 Aug 2019 17:23:08 -0400

Christer,

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 10 Aug 2019 06:46:56 +0000

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.

Otherwise it looks ok. 

Regards,

Christer

On 8/9/19 4:06 PM, Christer Holmberg wrote:
>      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
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Aug 2019 11:30:09 -0400

> 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