Re: [rtcweb] I-D Action: draft-ietf-rtcweb-stun-consent-freshness-08.txt - Some additional questions

[Christer Holmberg <[e-mail]>]

Hi Martin,

>It is really hard following these threads, but it looks like this is being over-thought.
>
>"This document defines what it takes to obtain, maintain, and lose consent to send. Consent 
>to send applies to a single 5-tuple. What applications choose to do with this information is not 
>described in this document."
>
>Add that to the introduction perhaps. We run the risk of expanding scope otherwise.

I agree that we don't need to specify application behaviour. But, I think we do need to be clear regarding the impacts on the transport/ICE layer, when/if/how it can be later re-used etc.

>As for the question of re-acquisition of consent, I think that we should keep it simple. For this:
>
>"After consent is lost for any reason, the same ICE credentials MUST NOT be used on the affected 5-tuple again. 
>That means that a new session, or an ICE restart at least, is needed to obtain consent to send."

My question is how/if the consent lost impacts "normal" ICE (STUN keep-alives etc), transport layer heartbeats etc.

Also, as the entity may still receive media on the 5-tuple, that also means it still have to respond to incoming STUN requests etc.

I think that should be clear in the draft. 

>I think that we should consider a keep alive as application data, and subject to rules of consent.
>The text should note that firewall and NAT bindings could be lost, instead.

I am ok with such approach, as long as we document it :)

What about DTLS heartbeats, and other information sent on the transport layer? I ASSUME the entity will maintain those, as it still may receive media

Regards,

Christer