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

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

(Ben Campbell) (was Discuss) Yes

Comment (2017-02-08)
No email
send info
Thanks for addressing my DISCUSS points and other comments!

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2017-01-17 for -13)
No email
send info
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?

(Jari Arkko) No Objection

Comment (2017-01-18 for -14)
No email
send info
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.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

(Stephen Farrell) No Objection

Comment (2017-01-19 for -14)
No email
send info
- 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.

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2017-01-17 for -13)
No email
send info
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. “

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2017-01-17 for -13)
No email
send info
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.

(Kathleen Moriarty) No Objection

Comment (2017-01-18 for -14)
No email
send info
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.

Alvaro Retana No Objection