[rtcweb] AD evaluation: draft-ietf-rtcweb-stun-consent-freshness-11

[Alissa Cooper <[e-mail]>]

I have reviewed draft-ietf-rtcweb-stun-consent-freshness-11 in preparation for IETF LC. The document is in good shape and I will request the last call shortly. I have a couple of questions I’d like to discuss while the last call is ongoing, though. I’m not entirely caught up on mailing list traffic so apologies if these questions/comments have already been discussed.

Section 4.1:
"An endpoint that is not sending any application data does not need to
   maintain consent.  However, failure to send could cause any NAT or
   firewall mappings for the flow to expire.  Furthermore, having one
   peer unable to send is detrimental to many protocols."

It sounds like the unstated implication here is that if you are such an endpoint, you should keep doing consent checks anyway to maintain consent. Should that be stated explicitly, or am I misunderstanding?

Section 7:
The normative MAY here seems odd. It seems like this section could be replaced with:

"The W3C specification [cite] may provide an API hook that generates an event when consent has expired for a given 5-tuple, meaning that transmission of data has ceased.  This could indicate what application data is affected, such as media or data channels.”

Alissa