Re: [rtcweb] Consent alternative

On 22 Nov 2013, at 09:55, Martin Thomson <martin.thomson@gmail.com> wrote:

> I know that I've been a fan of consent via ICE, but with the decision
> in Berlin to move to DTLS only, several of us have observed that
> perhaps RFC 6520 might be a better alternative.
> 
> We've put together an exploration of the idea here:
> 
> http://tools.ietf.org/html/draft-thomson-rtcweb-consent-00
> 
> The best part of this is that it changes the dynamics (for the better,
> I think).  You don't need to send extra packets if you are actively
> using the flow.  That means that 1:1 sessions won't need to spend
> extra cycles or bytes on keeping the session live.
> 
> There are some gotchas for multiparty sessions, but I believe those to
> be manageable.

I have misgivings about this - It feels to me to force a mixing of layers in the 
packet handling - At the moment in the implementation I’m familiar with, the ICE/DTLS/SRTP 
state machines are almost completely isolated. This proposal seems (at first glance)
to make them intertwine in a quite complex way - consent is generated (if I understand it correctly)
by any of the layers. Likewise each of the layers needs to know if the others have generated consent 
granting packets. 

If we are to blur the boundaries like this, we should go the whole hog and get some real benefits - like
for example remove some round-trips in session establishment by (say) carrying the DTLS hello in the
same STUN packet as has ICE USE-CANDIDATE set - for example.

I’m against including this sort of change at this stage in the standards process.

T.

> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb