Re: [bfcpbis] Review of draft-ietf-bfcpbis-sdp-ws-uri-07

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

Hi Joel,

Thanks for your response. Please see inline

-----Original Message-----
From: Joel Halpern <[e-mail]>
Date: Saturday, 24 December 2016 at 4:45 AM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, Charles Eckel <[e-mail]>
Resent-Date: Saturday, 24 December 2016 at 4:45 AM

    Reviewer: Joel Halpern
    Review result: Ready with Nits
    
    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair.  Please treat these comments just
    like any other last call comments.
    
    For more information, please see the FAQ at
    
    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    
    Document: draft-ietf-bfcpbis-sdp-ws-uri-??
    Reviewer: Joel Halpern
    Review Date: 2016-12-23
    IETF LC End Date: 2017-01-12
    IESG Telechat date: 2017-01-19
    
    Summary: This document is ready for publication as a Proposed Standard
    RFC.  I have a few minor comments that should be considered s they may
    improve future understanding of the document.
    
    Major issues: None
    
    Minor issues:
        In reading section 4.2 and 4.3, I believe I can guess at certain
    intended behaviors, but it is not as clearly stated as I think is
    desirable.  There is also one odd statement in section 4.3
    
        Taking the odd statement first, the text in section 4.3 refers the
    active answerer "towards
       the IP address and port of the offerer".  But when WebSockets is
    used, one does not connect to the IP address and port, but to the URI
    specified.

<Ram> I will replace the text as below:

EXISTING:
Towards the IP address and port of the offerer using the procedures described
   in [RFC6455]
    
NEW:
Towards the URI specified in a=ws-uri or a=wss-uri attribute using procedures described 
   in [RFC6455]

        I believe that the intent in 4.2 and 4.3 is that whichever side
    will be "passive" is required to provide an a=ws-uri or a=wss-uri so
    that the other side can establish the connection to the URI.  But
    section 4.2 does not say that. 

<Ram>
EXISTING:
   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.

NEW:
   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 also
have URI in the a=ws-uri or a=wss-uri attribute.

 And the text in section4.3 that talks
    about providing the URI in the a= does not qualify whether it is
    required with active, passive, or both.  

<Ram>
NEW:
If the answers assigns SDP “setup” attribute with “passive”, then it MUST have URI in either 
a=ws-uri or a=wss-uri attribute.

Does this look good and makes it more clear ?

Regards,
Ram
    
    Nits/editorial comments:  N/A