Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
draft-ietf-bfcpbis-rfc4583bis-27
Yes
(Adam Roach)
No Objection
(Alvaro Retana)
(Deborah Brungard)
(Ignas Bagdonas)
(Martin Vigoureux)
(Spencer Dawkins)
Note: This ballot was opened for revision 26 and is now closed.
Adam Roach Former IESG member
Yes
Yes
(for -26)
Unknown
Alissa Cooper Former IESG member
Yes
Yes
(2018-10-24 for -26)
Sent
Glad to see this document getting published! I support Ben's DISCUSS.
Ben Campbell Former IESG member
(was Discuss)
Yes
Yes
(2018-12-21)
Sent
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.
Alexey Melnikov Former IESG member
No Objection
No Objection
(2018-10-23 for -26)
Sent
I have one small issue with this document which applies to several sections: 5.2. SDP 'confid' Attributes The Augmented BNF syntax [RFC5234] for the attribute is: conference-id = 1*DIGIT Is there any limit on the maximum allowed value of this attribute? The same issue in all the following sections where "1*DIGIT" construct is used: 5.3. SDP 'userid' Attribute 5.4. SDP 'floorid' Attribute 5.5. SDP 'bfcpver' Attribute
Alvaro Retana Former IESG member
No Objection
No Objection
(for -26)
Not sent
Benjamin Kaduk Former IESG member
(was Discuss)
No Objection
No Objection
(2018-10-25 for -26)
Sent
It seems that my DISCUSS points have been adequately discussed already; thanks. For posterity, they were: I will go ahead and say that we should discuss the "UDP/TLS/BFCP" naming. In particular, while I see the previous discussion that there may be existing deployments out there, why can we not give it the same treatment as "mstrm", and make the official name "UDP/DTLS/BFCP" while documenting that you should accept the old name? We also had a very long discussion about the usage of the term "initial offer" in the context of draft-ietf-mmusic-sdp-bundle-negotiation; I do not propose to rehash that discussion, but want to ask whether we should stick to the established precedent with regard to the use of the term (which, IIUC, would involve a change to this document). Original COMMENT preserved below Section 4 m=<media> <port> <proto> <fmt> ... The media field MUST have a value of "application". This is "For BFCP streams, the media field MUST have a value of application", right? I might just swap the "This section describes [...]" paragraph to be after the exerpt from RFC4566 to avoid confusion. 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. The fmt list is ignored, or the whole m= line (and section)? Section 5.1 The interpretation of the "c-s" value is not mentioned prior to the table in which it appears, which kind of leaves the reader hanging. (But I guess that is still a style matter, so I should have no say on it.) Table 1 could probably benefit from some discussion of how it is applied, since (e.g.) an offer could include both c-only and c-s, and if the answere includes s-only, the offerer needs to know which role it is performing. It seems like this would be "the offerer proceeds through the following table, and if the offer and answer included the values present in the current line of the table, that line is a match and determines what role the offerer will use". (This would be a DISCUSS but I am not convinced that there is a way to actually do the wrong thing as an implementation.) Endpoints compliant with [RFC4583] might not include the 'floorctrl' attribute in offers and answerer. If the 'floorctrl' attribute is not present the offerer will act as floor control client, and the answerer will act as floor control server. I assume this is going to be backwards compatible, but it might be worth explicitly saying so. Section 5.4, 5.5 I'd go with "decimal integer representation" for consistency with the preceding sections. Section 7 Note: When using Interactive Connectivity Establishment (ICE) [RFC8445], TCP/DTLS/BFCP, and UDP/TLS/BFCP, the straight-forward procedures for connection management as UDP/BFCP described above apply. [...] nit: this sentence as written applies only when all three of ICE, TCP/DTLS/BFCP, and UDP/TLS/BFCP apply (which is nonsensical). I assume the intended grouping is: (1) ICE is used, and (2) either TCP/DTLS/BFCP or UDP/TLS/BFCP is used. Section 8 When TLS is used with TCP, once the underlying connection is established, the answerer always acts as the TLS server. If the TCP connection is lost, the active endpoint is responsible for re- establishing the TCP connection. Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles. IMPORTANT: "TLS session" is a term of art, and is in fact nonsensical here. I think that you mean "TLS connection" or maybe "TLS handshake". Section 10 If the 'm' line 'proto' value is 'TCP/TLS/BFCP', 'TCP/DTLS/BFCP' or 'UDP/TLS/BFCP', the offerer and answerer follow the generic procedures defined in [RFC8122]. Why is 8122 the reference even for the DLTS values (as opposed to mmusic-dtls-sdp)? Section 10.2 So the answerer can indicate multiple BFCP versions in the bfcpver attribute and is not using that attribute to indicate the selected BFCP version in use? A ref to RFC 4145 for the 'active' endpoint might be helpful. Section 10.3 The "Note" is indented as if it is part of the list, but it should not be part of the list. Section 10.4 When an offerer sends an updated offer, in order to modify a My knowledge of SDP is rusty (and was sparse to begin with), but can't the answerer also send a mid-session offer to start renegotiation of various parameters? That is, it is not just the offerer that can send an offer during an existing session. Section 12 It's probably worth noting explicitly that the non-(D)TLS proto values offer neither integrity protection nor confidentiality protection to the BFCP stream. An attacker able to view the SDP exchanges can determine which media flows contain which content, which could exacerbate existing metadata leakage channels in some circumstances. As Ekr notes in his comment, the potential for privacy considerations relating to the various identifiers transmitted in the session description should be discussed. If the various integer IDs are just local to the physical premises (even better if they're periodically randomized!), the impact is going to be fairly limited, but should still be covered. Section 14 2. Authentication (Section 8): In last paragraph, made clear that a TCP connection was described. I'm rather confused at what this is attempting to describe.
Deborah Brungard Former IESG member
No Objection
No Objection
(for -26)
Not sent
Eric Rescorla Former IESG member
(was Discuss)
No Objection
No Objection
(2018-11-21 for -26)
Sent
Based on Adam's comments, I am changing my DISCUSS to No Objection
Ignas Bagdonas Former IESG member
No Objection
No Objection
(for -26)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -26)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(2018-10-24 for -26)
Not sent
1) Section 4: „This is one of the options when ICE is used (Section 9).“ Maybe you can make this sentence slightly more specific because that was one thing I was wondering about all the time until I read 9 (why TCP/DTLS/BFCP is needed), e.g. „This is one of the options where when ICE is used only one DTLS session is established but there are candidate pairs for UDP and TCP (Section 9).“ Also why is 'UDP/TLS/BFCP' not called 'UDP/DTLS/BFCP‘? 2) Section 6 provides multiplexing considerations for bfcpver, however all other attributes also have a Mux Category: TBD. When will these be defined? 3) Section 7.1: Sorry for the lack of understanding here, but why does the reconnecting endpoint need to send a new offer at all, instead of just re-opening a new TCP connection with the same parameters as before? 4) Section 8: „If the TCP connection is lost, the active endpoint is responsible for re- establishing the TCP connection.“ What does active mean here? Also in section 10.2 and 10.3 'active' is used a well but with quotes, however, it is never really defined. 5) Section 8: „Unless a new TLS session is negotiated, subsequent SDP offers and answers will not impact the previously negotiated TLS roles.“ Quick question: Does that mean that when the TCP connection breaks and is re-opened, there is no new TLS handshake? 6) Section 10.4: „if the offerer does not want to re-establish an existing TCP connection, the offerer MUST associate an SDP 'connection' attribute with a value of "existing", with the 'm' line;“ Just double-checking: Is this correct that If the offerer does NOT what to use the existing TCP connection, it adds the „existing“ attribute…?
Spencer Dawkins Former IESG member
No Objection
No Objection
(for -26)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(2018-10-24 for -26)
Sent
Similar to Mirja, I was also wondering why UDP/TLS/BFCP is not called UDP/DTLS/BFCP instead since it does use DTLS?