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

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Oct 2018 20:11:40 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-bfcpbis-rfc4583bis-26: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bfcpbis-rfc4583bis/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for the work on this document. I have one item that I want to make sure
is discussed prior to publication, thus the DISCUSS position:

This document lists all the SDP attributes as having an a Mux Category of
"TBD". draft-ietf-mmusic-sdp-mux-attributes did indeed assign a category of
"TBD" to all the attributes, save for bfcpver, which didn't exist at the time.
But the point of "TBD" was to say that draft-ietf-mmusic-sdp-mux-attributes did
not actually analyze the attributes to determine a "real" mux category. It's
not intended as free pass to let other attribute definitions skip that analysis.

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

*** Substantive Comments ***

§4: "The fmt (format) list is not applicable to BFCP. The fmt list of ’m’
lines in the case of any proto field value related to BFCP MUST
contain a single "*" character. If the the fmt list contains any
other value it is ignored."

It seems like the last sentence should use a MUST to match the one in the
previous sentence.

*** Editorial Comments ***

§3: "Typically, a client that establishes a BFCP
stream with a conference server will act as a floor control client,
while the conference server will act as a floor control server."

The use of "typically" seems odd without a discussion of when it might not.
Perhaps a forward reference to section 7 would help?

§6: "[I-D.ietf-mmusic-sdp-mux-attributes] defines the mux categories for
the SDP attributes defined in this specification. Table 2 defines
the mux category for the ’bfcpver’ attribute:"

I assume the first sentence should say "... except for bfcpver."?

§10, 3rd paragraph: Incorrect comma use in "... SDP), in ..."
§10.1, last paragraph: "... value, in the offer, ...": The first comma is
incorrect. §10.3: First paragraph: "When the offerer receives an answer, which
contains an ’m’ line..." s/ ", which" / "that"

§16.2: It seems like [I-D.ietf-mmusic-sdp-mux-attributes] should be a normative
reference.

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Oct 2018 22:22:38 -0500

On 10/23/18 10:11 PM, Ben Campbell wrote:
> 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"? Or 
merely that it says that the category is "special," and that the special 
considerations are "do not multiplex"?

/a

---

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Oct 2018 22:39:29 -0500

> On Oct 23, 2018, at 10:22 PM, Adam Roach <[email-masked]> wrote:
> 
> 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”.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Oct 2018 08:31:49 +0000

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" <[email-masked]> wrote:

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 24 Oct 2018 13:03:11 +0200

> On Oct 24, 2018, at 5:11 AM, Ben Campbell <[email-masked]> wrote:
> 

Maybe it should? Now that seems like an unfortunate omission.

Alissa

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 11:20:22 -0500

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.

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 <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 11:39:52 -0500

In a separate thread branch, I noted that mux-attributes uses TBD in a way consistent with what 4583bis is doing, but inconsistent with the definition. I’ve started a thread on the mmusic list to get opinions on the right way to handle this.

Thanks!

Ben.

> On Oct 24, 2018, at 6:03 AM, Alissa Cooper <[email-masked]> wrote:
> 
> 
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 24 Oct 2018 17:56:50 +0000

Hi,

...

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

No.

I THINK I mentioned it to Suhas at some point, but I may be wrong. Suhas?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Oct 2018 23:22:15 -0400

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

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

> _______________________________________________
> bfcpbis mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bfcpbis
>