[bfcpbis] Ben Campbell's Yes on draft-ietf-bfcpbis-rfc4583bis-27: (with COMMENT)

[Ben Campbell <[e-mail]>]

Ben Campbell has entered the following ballot position for
draft-ietf-bfcpbis-rfc4583bis-27: Yes

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/



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

Update: The RFC Editor is updating the mux-attribute draft to match the
mux-categories described in this draft. Therefore I have cleared my DISCUSS
position. Thanks to all involved! I have left my previous non-blocking comments
below for reference purposes.

---------------------------

The following point was part of my DISCUSS position. Since the problem seems
broader than for just this draft,  I won't hold the draft hostage to it's
solution. But I hope we can find a cleaner approach in general:

<old-discuss-point>

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

Update: After a bit of discussion and a re-read of
draft-ietf-mmusic-sdp-mux-attributes, I see that, while the use of "TBD" does
not seem consistent with the definition of TBD, it does seem consistent with
the practice in mux-attributes of assigning a category of TBD to attributes
associated with non-muxable protocols. I've sent an email to the MMUSIC WG for
guidance on the intended use.

</old-discuss-point>

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