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

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Alexey,

Thanks for your feedback. Please see inline

-----Original Message-----
From: Alexey Melnikov <[e-mail]>
Date: Thursday, 2 February 2017 at 8:15 PM
To: "Ram Mohan R (rmohanr)" <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "Charles Eckel (eckelcu)" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Alexey Melnikov's No Objection on draft-ietf-bfcpbis-bfcp-websocket-13: (with COMMENT)

    Hi Ram,
    
    On Mon, Jan 30, 2017, at 03:11 PM, Ram Mohan R (rmohanr) wrote:
    > Hi Alexey,
    > 
    > Please see inline <Ram> for my responses
    > 
    > -----Original Message-----
    > From: Alexey Melnikov <[e-mail]>
    > Date: Tuesday, 17 January 2017 at 10:04 PM
    > To: The IESG <[e-mail]>
    > Cc: "[e-mail]"
    > <[e-mail]>, "Charles Eckel (eckelcu)"
    > <[e-mail]>, "[e-mail]" <[e-mail]>,
    > "Charles Eckel (eckelcu)" <[e-mail]>, "[e-mail]"
    > <[e-mail]>
    > Subject: Alexey Melnikov's No Objection on
    > draft-ietf-bfcpbis-bfcp-websocket-13: (with COMMENT)
    > Resent-From: <[e-mail]>
    > Resent-To: <[e-mail]>, <[e-mail]>,
    > <[e-mail]>, <[e-mail]>,
    > <[e-mail]>, <[e-mail]>
    > Resent-Date: Tuesday, 17 January 2017 at 10:04 PM
    > 
    >     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?
    > <Ram> Yes section 10 of this draft defines the new sub-protocol
    > identifier. Do you see a need for anything else ?
    
    [Alexey]: The sentence in question was:
    
       While this specification assumes that BFCP encoding is only TLV
       binary, future documents may define other mechanisms like JSON
       serialization.
    
    I suggest you add some text saying that if the encoding changes new
    subprotocol identifier would need to be selected. Because otherwise old
    implementation (that use TLV binary) can't interop with new ones (that
    use JSON).

<Ram> Ok I will a line at the end saying if encoding changes new subprotocol identifier would need to be selected

Regards,
Ram
    
    >     
    >     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. 
    
    Ok.
    
    >     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.
    
    Ok.
    
    >     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 ?
    
    New text is better. Thank you!
    
    > Regards,
    > Ram
    >     
    >     
    >