Skip to main content

The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
draft-ietf-bfcpbis-bfcp-websocket-15

Yes

(Alissa Cooper)

No Objection

(Alia Atlas)
(Alvaro Retana)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 13 and is now closed.

Alissa Cooper Former IESG member
Yes
Yes (for -13) Unknown

                            
Ben Campbell Former IESG member
(was Discuss) Yes
Yes (2017-02-08) Unknown
Thanks for addressing my DISCUSS points and other comments!
Spencer Dawkins Former IESG member
Yes
Yes (2017-01-17 for -13) Unknown
I have a couple of questions on authentication in this draft.

Does this text,

      Since the WebSocket API does not distinguish between certificate
      errors and other kinds of failure to establish a connection, it is
      expected that browser vendors will warn end users directly of any
      kind of problem with the server certificate.

apply to any WebSocket-based application?

In this text,

   A floor control server that receives a message over TCP/WS can
   request the use of TCP/WSS by generating an Error message, as
   described in Section 13.8 of [I-D.ietf-bfcpbis-rfc4582bis], with an
   Error code with a value of 9 (use TLS).

is "request" the right word? Or is "require" more accurate, if the server isn't going to establish a TCP/WS connection?
Alexey Melnikov Former IESG member
No Objection
No Objection (2017-01-17 for -13) Unknown
In 4.2, last sentence: wouldn't that require a new WebSocket sub-protocol identifier?

In 6.2: some formatting errors in the PDF version. Also, I think you meant Section 3.3 (not 3.2) when talking about WSS.

In 7.2: when referencing Section 3, you are missing the RFC number. At least section 3 of this draft is not relevant.

In 8: HTTP authentication text is rather weak.
Alia Atlas Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2017-01-18 for -14) Unknown
There is ongoing discussion based on the security considerations questions from Robert Sparks in his Gen-ART review. That discussion is not yet finished, but needs to finish before we can approve this document.
Joel Jaeggli Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2017-01-18 for -14) Unknown
I agree with Alexey's comment on section 8.  If fallback to HTTP authentication happens, the implementer should be aware of the weaknesses in HTTP basic [RFC7617] and digest [RFC7616] spelled out in the respective security considerations sections.  The HTTPAuth WG put out a few experimental RFCs with methods to eliminate some of the weaknesses, like HOBA [RFC7486] that gets rid of the need for passwords.  Adding this detail would be helpful.
Mirja Kühlewind Former IESG member
No Objection
No Objection (2017-01-17 for -13) Unknown
1) I find this sentence slightly confusing: 
„This document specifies a new WebSocket sub-
   protocol as a reliable transport mechanism between Binary Floor
   Control Protocol (BFCP) entities to enable usage of BFCP in new
   scenarios.“
because it suggests that this document specifies a new protocol which is not true.
How about the following instead:
„This document specifies the use of Binary Floor
   Control Protocol (BFCP) as a new WebSocket sub-
   protocol enabling a reliable transport mechanism between 
   BFCP entities in new scenarios.“
If this change is used, please also check similar wording in the rest of the doc.
2) In section 4.1: 
„The WebSocket messages transmitted over this connection MUST conform to
   the negotiated WebSocket sub-protocol.“
Not sure if this is actually meaningful given the subsequent MUSTs in the next section. I guess this sentence could simply be removed… Also would this mean that it is the task of the BFCP WS sub protocol to verify that BFCP messages are valid?
3) In section 5: „Each BFCP message MUST be carried within a single WebSocket message,
   and a WebSocket message MUST NOT contain more than one BFCP message.“
This seem to be long rather in section 4.2 than in 5.
4) The following sentence in section 6.2 is basically copied and pasted from ietf-bfcpbis-sdp-ws-uri. It’s usually not a good idea to duplicate normative text (as problems when updating might occur). I’d recommend to either a) remove this text (and only refer to ietf-bfcpbis-sdp-ws-uri), or b) use quotes to make clear that this is a citation, or c) rephrase in non-normative language (with a clear indication that the normative text can be found in ietf-bfcpbis-sdp-ws-uri).
„When the 'ws-uri' or 'wss-uri' attribute is present in the
   media section of the SDP, the IP and port information provided in the
   'c' lines SHALL be ignored and the full URI SHALL be used instead to
   open the WebSocket connection. “
Stephen Farrell Former IESG member
No Objection
No Objection (2017-01-19 for -14) Unknown
- I support Ben's discuss and hope the discussion about the
gen-art review continues and reaches a good conclusion.

- WRT Kathleen's comment, while I think it'd be a fine thing
were HOBA usable with ws/wss, I doubt that browsers will do
that, so adding the reference may be misleading.
Suresh Krishnan Former IESG member
No Objection
No Objection (for -14) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -14) Unknown