Re: [rtcweb] [BEHAVE] Fwd: New Version Notification for draft-uberti-behave-turn-rest-00.txt

[Rajmohan Banavi <[e-mail]>]

> So there are two parts to the proposal - the HTTP request for the
> credentials and interactions with WebRTC, and the stateless implementation
> that avoids the need for communication between web and TURN servers. And it
> is true that other implementations besides the suggested stateless one are
> possible, e.g. OAuth2.
>
> Would you prefer that I address the protocol and implementation parts
> separately in the document, and mention that other implementations with the
> same HTTP protocol are possible? RFC 5766 does something similar, where it
> defines the TURN protocol, but in Section 6.2 talks about how a "stateless
> stack" implementation can be used to simplify the processing on the TURN
> server.
>
> As you pointed out, the draft essentially has 2 parts - the REST API and
the stateless stack implementation which are completely independent. So
yes, separating them would help because we want other implementations to
also be compliant to the spec. Having said that, I would like opinions and
consensus from others as well.

Just to make my earlier point clearer - The credentials are generated by
TURN server and validated by TURN server. None of the other components in
the chain - web server, web application and the webrtc client, are
concerned with it (sort of like a blob). So the interoperability is not an
issue at all irrespective of what implementation approach you take.

I had some other comments earlier, which are collated below.

   1. What does the web server do with the shared (with TURN server) secret
   key? This is not clear from the text.
   2. Sec 4.2 Server - "Note that the REALM value supplied by the server is
   not meaningful in this context, and can be set to any valid value". Which
   realm value is being referred here? The REALM attribute value in the 401
   challenge response sent by the TURN server (in response to initial ALLOCATE
   request)?
   3. The 2 statements seem to be contradictory: sec 1 "However, as a relay
   service, it imposes a nontrivial cost on the service provider". sec 5.1
   "The assumption is that TURN services are of low enough value that waiting
   for the timeout to expire is a valid approach for dealing with
   possibly-compromised credentials". I am OK with the text, but would prefer
   if this could be reworded in anyway.