Re: [bfcpbis] Ben Campbell's Yes on draft-ietf-bfcpbis-sdp-ws-uri-08: (with COMMENT)

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

Hi Ben,

Please see inline for <Ram>

-----Original Message-----
From: Ben Campbell <[e-mail]>
Date: Thursday, 19 January 2017 at 8:37 AM
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: Ben Campbell's Yes on draft-ietf-bfcpbis-sdp-ws-uri-08: (with COMMENT)

    Ben Campbell has entered the following ballot position for
    draft-ietf-bfcpbis-sdp-ws-uri-08: Yes
    
    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-sdp-ws-uri/
    
    
    
    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------
    
    How does this interact with websocket sub-protocol specifications? Is
    there an expectation one might take some existing media protocol and use
    it with this draft _without_ a sub-protocol spec? I note the examples use
    bfcp, which in fact has a sub-protocol spec on this same telechat. (Most
    of my detailed comments are related to this)
<Ram> I would expect there will be additional specification for each protocol that wishes to use this specification like we have one for BFCP over WebSocket.

    
    - 4.2, first paragraph: Am I correct that the "proto" field would also
    include the sub-protocol? (e.g. TCP/WSS/BFCP)? Would you ever have a
    "proto" filed value of just "TCP/WS(S)?
<Ram> this draft uses BFCP over WS to demonstrate the use of the new SDP attribute being defined here. I would expect other protocols that want to use this specification to extend the “proto” field as appropriate. I don’t see a use-case where the proto value would be just TCP/WS or TCP/WSS.
    
    - 4.2, 2nd paragraph
    I wonder if the guidance here (the recommendation that the offerer is the
    active party) doesn't vary by sub-protocol? Or if it doesn't, if it's
    more a matter of topology (e.g. servers with global IP addresses vs
    clients behind NATs) than a matter of who sends the offer?

<Ram> Good point.  Yes its more a matter of topology and not a matter of who sends the offer.  
It is NOT required that offerer be the active party always. Even a server side (WebSocket server) can be a offerer (and that will have ws-URI in its SDP), and the answerer in that case will be active party which will initiate the webSocket connection.  The main point that we wanted to highlight is - WebSocket client is always likely to be the active party as clients (endpoints, browsers e.t.c) are likely to be behind NATs and servers are likely to have global addresses. So the clients will have to be active entity and setup the TCP connection. I read the section  4.2 again and don’t see this point clear.  Section 4.3 does not make the assumption and so will keep the text there as it is.


Will add a new para in Section 4.1 (General) with below text:

NEW:
Both offeror or answerer can initiate a webSocket connection. It is expected that based on the topology (for example, if the client is behind NAT and server is on global IP address) the offeror and answers decides who will initiate the webSocket connection and appropriately set the a=setup attribute in SDP following the procedures of [RFC4145].


Will re-word the text in 4.2 something like this

EXISTING:
An SDP offerer in order to negotiate WebSocket as a transport MUST
   indicate the same in the "proto" field of the "m=" line.  For
   example, to negotiate BFCP-over-WebSocket the "proto" value in the
   "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST
   be TCP/WS/BFCP.

   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection), unless the offerer insists on being a receiver of an
   incoming connection, in which case the offerer SHOULD use a value of
   "passive".  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value.  If the "setup" attribute has a value "passive"
   it MUST have a URI in the "a=ws-uri" or "a=wss-uri" attribute.

NEW:
An SDP offerer in order to negotiate WebSocket as a transport MUST
   indicate the same in the "proto" field of the "m=" line.  For
   example, to negotiate BFCP-over-WebSocket the "proto" value in the
   "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST
   be TCP/WS/BFCP.

   The offerer SHOULD assign the SDP "setup" attribute with a value of
   "active" (the offerer will be the initiator of the outgoing TCP
   connection) or "passive", if the offerer wishes to be a receiver of an
   incoming connection following the procedures described in [RFC4145]
.  The offerer MUST NOT assign an SDP "setup" attribute with
   a "holdconn" value.  If the "setup" attribute has a value "passive"
   it MUST have a URI in the "a=websocket-uri" attribute.

Does this sound better ?

>Also, please consider citing 4145 in this paragraph. (You do in 4.3).

<Ram> Sure see above