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

["Joel M. Halpern" <[e-mail]>]

Yes, those fixes ddress my concerns.  Thank you.
Joel

On 1/3/17 3:36 AM, Ram Mohan R (rmohanr) wrote:
> 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
>
>
>
>