Subject: [bfcpbis] Alexey Melnikov's No Objection on draft-ietf-bfcpbis-bfcp-websocket-13: (with COMMENT)

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 17 Jan 2017 08:34:43 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-bfcpbis-bfcp-websocket-13: No Objection

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-bfcp-websocket/

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

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.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 30 Jan 2017 15:11:20 +0000

Hi Alexey,

Please see inline <Ram> for my responses

-----Original Message-----
From: Alexey Melnikov <[email-masked]>
Date: Tuesday, 17 January 2017 at 10:04 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "[email-masked]" <[email-masked]>, "Charles Eckel (eckelcu)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Alexey Melnikov's No Objection on draft-ietf-bfcpbis-bfcp-websocket-13: (with COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Tuesday, 17 January 2017 at 10:04 PM

    

    In 4.2, last sentence: wouldn't that require a new WebSocket sub-protocol
    identifier?
<Ram> Yes section 10 of this draft defines the new sub-protocol identifier. Do you see a need for anything else ?
    
    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.
<Ram> I have fixed this now in my local copy. Now we are having only one attribute (a=websocket-uri) that will point to either ws-URI or wss-URI. 
    
    In 7.2: when referencing Section 3, you are missing the RFC number. At
    least section 3 of this draft is not relevant.
<Ram> I fixed this now. I have pointed to the section of ietf-bfcpbis-sdp-ws-uri where the new SDP attribute is defined.
    
    In 8: HTTP authentication text is rather weak.
<Ram> I will add the below text (considering the feedback from Kathleen Moriarty and Stephen as well)
EXISTING:
         If the status code received from the server is not 101,
          the WebSocket client stack handles the response per HTTP
          [RFC7230] procedures, in particular the
          client might perform authentication if it receives 401
          status code.
NEW:
        If the status code received from the server is not 101,
          the WebSocket client stack handles the response per HTTP
          [RFC7230] procedures, in particular the
          client might perform authentication if it receives 401
          status code.  The WebSocket clients are vulnerable to the attacks
         of basic authentication (mentioned in Section 4 of [RFC7617]) and 
        digest authentication (mentioned in Section 5 of [RFC7616]). To overcome
        some of these weakness, the WebSocket clients can use HTTP Origin-Bound Authentication (HOBA)
        mechanism mentioned in [RFC7486].

Does this look ok ?
Regards,
Ram