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 <jmh(_at_)joelhalpern(_dot_)com>
Date: Saturday, 24 December 2016 at 4:45 AM
To: "gen-art(_at_)ietf(_dot_)org" <gen-art(_at_)ietf(_dot_)org>
Cc: "bfcpbis(_at_)ietf(_dot_)org" <bfcpbis(_at_)ietf(_dot_)org>, "ietf(_at_)ietf(_dot_)org"
<ietf(_at_)ietf(_dot_)org>, "draft-ietf-bfcpbis-sdp-ws-uri(_dot_)all(_at_)ietf(_dot_)org"
<draft-ietf-bfcpbis-sdp-ws-uri(_dot_)all(_at_)ietf(_dot_)org>
Subject: Review of draft-ietf-bfcpbis-sdp-ws-uri-07
Resent-From: <alias-bounces(_at_)ietf(_dot_)org>
Resent-To: <rmohanr(_at_)cisco(_dot_)com>, <gsalguei(_at_)cisco(_dot_)com>,
<keith(_dot_)drage(_at_)alcatel-lucent(_dot_)com>, <eckelcu(_at_)cisco(_dot_)com>,
<ben(_at_)nostrum(_dot_)com>, <alissa(_at_)cooperw(_dot_)in>, <aamelnikov(_at_)fastmail(_dot_)fm>, Charles
Eckel <eckelcu(_at_)cisco(_dot_)com>
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