Re: [bfcpbis] Ben Campbell's Discuss on draft-ietf-bfcpbis-rfc4583bis-26: (with DISCUSS and COMMENT)

On 10/24/18 12:20 PM, Ben Campbell wrote:
> 
> On a re-read of mux-attributes, I’m going to have to partially agree and partially disagree with Christer :-)
> 
> Mux-attributes does use “TBD" for attributes for protocols that have no specification for how to multiplex, and includes explicit notes to that effect. I find this counter-intuitive, and counter to the definition of TBD that Christer cited. Saying that attributes have not been analyzed is very different from saying the related protocol doesn’t specify multiplexing. In the latter case, it seems more reasonable to say that we _have_ analyzed the attribute and decided you shouldn’t bundle it.

Well...

ISTM that the analysis, while possibly started, hasn't been completed - 
it has been deferred to a future document. So it really is TBD.

Of course there is currently no plan to produce such a document. But I 
think one *could* be done, and it seems like it would be quite useful 
when the media subject to floor control is itself bundled.

	Thanks,
	Paul

> The definition for CAUTION includes an example of a protocol that cannot be multiplexed, so that seem more fitting. But CAUTION is also a bit counter-intuitive.
> 
> An additional issue is that the only change that 4566bis allows for existing mux-category registrations is to change it from TBD to something else. That seems makes TBD the only choice for non mux-able protocols unless we want to prevent any future revision from becoming mux-able.
> 
> So at this point, I can’t really say that 4583bis is using TBD incorrectly because it follows the practice, if not the definition, from mux-attributes. I would like to get some clarification of the intent in mux-attributes; We should probably include MMUSIC in this discussion; I will send a separate email there that summarized the issue for people for people who haven’t followed this thread.
> 
> 
> On a related note, I noticed that mux-attributes defines all of the existing BFCP related attributes as “NORMAL” except for floorctrl, which is “TBD”. 4583bis lists them all as “TBD”. Which is correct?
> 
> Thanks!
> 
> Ben.
> 
>> On Oct 24, 2018, at 3:31 AM, Christer Holmberg <christer.holmberg@ericsson.com> wrote:
>>
>> Hi,
>>
>> I am not sure I agree that "TBD" is a free pass.
>>
>> The definition of "TBD" is:
>>
>> "The attributes in the TBD category have not been analyzed under the proposed multiplexing framework and SHOULD NOT be multiplexed."
>>
>> Now, the WG decided, as is reflected in Section 6, that we are not going to define how BFCP streams are multiplexed/bundled in this spec, and that further analysis would be needed in a separate specification. One could of course claim that the decision not to define multiplexing was done based on an analysis __
>>
>> I don't think we can use "special", because at least in my understanding it means that multiplexing IS possible, but there are special considerations etc that needs to be taken into account.
>>
>> I am not sure whether "caution" is suitable either, because it is not whether one should multiplex or not - how to multiplex is not defined to begin with. However, I guess "caution" is the only alternative if "TBD" doesn't work.
>>
>> Also keep in mind that, IF someone later defines how to multiplex, we probably would have to change the value.
>>
>> Regards,
>>
>> Christer
>>
>>
>> On 24/10/2018, 6.39, "Ben Campbell" <ben@nostrum.com> wrote:
>>
>>
>>
>>> On Oct 23, 2018, at 10:22 PM, Adam Roach <adam@nostrum.com> wrote:
>>>
>>> On 10/23/18 10:11 PM, Ben Campbell wrote:
>>>> Ideally, I think that this draft should assign a "real" mux category for each
>>>> attribute in it. Failing that, it at least needs to do so for "bfcpver". I'm
>>>> guessing that should be "caution" or "special". (Perhaps unfortunately,
>>>> draft-ietf-mmusic-sdp-mux-attributes did not define a category of "nope":-)  )
>>>
>>>
>>> Right. My reading of this was that these attributes must not be multiplexed. And the only category that the SDP mux attributes document defined for "do not multiplex" was "TBD". Are you proposing that this document define a new MUX category that says "do not multiplex”?
>>
>>     Not really; I’m just kind of wishing that mux-attributes had done so. “TBD” does mean “do not multiplex”, but it has connotations that this is because we haven’t gotten around to determining if it is safe, not that we have determined that it is unsafe.
>>
>>> Or merely that it says that the category is "special," and that the special considerations are "do not multiplex”?
>>
>>     That’s one approach. There’s also “caution”, which means something to the effect of “you really shouldn’t multiplex this”.
>>
>>>
>>> /a
>>>
>>
>>
>>
> 
> 
> 
> _______________________________________________
> bfcpbis mailing list
> bfcpbis@ietf.org
> https://www.ietf.org/mailman/listinfo/bfcpbis
> 