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

[Ben Campbell <[e-mail]>]

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

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.

In the process, I noticed that the category assignments in this draft do not
match the existing assignments in mux-attributes, which marks "floorctrl" as
"TBD", and the others as "NORMAL". This draft marks all attributes as "TBD".

I am going to hold the DISCUSS position for now, until discussion of the use of
TBD resolves a bit further, and until the assignment mismatch is corrected.

Original DISCUSS text:

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.