Session Traversal Utilities for NAT (STUN) Usage for Consent Freshness
draft-ietf-rtcweb-stun-consent-freshness-16

This looks good overall. I have a few minor comments:

-- General: 

After re-reading this, and the relevant parts of rtcweb-security-architecture, I think a novice reader might find the meaning of "consent" a bit vague, especially in terms of how it might differ from "reachability". Can you offer an example of when an otherwise reachable peer might choose to withdraw consent?

-- section 1, first paragraph:

I think readers are going to stumble over why we think a device that plans to attack a peer is going to worry about consent. This makes more sense in section 2. It might be helpful to move (or copy) the bit about "... deployments of WebRTC..." and "... malicious javascript" forward to the intro.

- 4, 3rd paragraph:

Should the reader infer that the receipt of a package that is strongly assured to have come from a party implies consent from that party? If so, it might be worth an explicit mention.

-- 5.1, first paragraph:

The normative MUST feels wrong here, (and is probably redundant with other normative language further down in the section.) For example, could a sender just choose to stop sending?

-- 5.1, 5th paragraph:

From the next paragraph, I infer that you mean consent expires after 30 seconds when you have been sending binding request every few seconds, not 30 seconds after sending any particular binding request. If that's correct it might be helpful to add a few words to that effect.

-- 5.1, 6th paragraph:

Does the "MUST NOT" refer to the general interval between checks prior to randomization, or to the specific interval between a pair of checks after randomization?

Nits:

-- 2, 2nd paragraph: "verify peer's consent"

Missing article (or "verify peer consent")

-- 5.1, paragraph 3:

s/sending an stun binding/sending a stun binding

-- 5.1, 7th paragraph: "Each STUN binding request for consent MUST use a new STUN transaction
   identifier for every consent binding request..."

That's sort of redundant. I suggest something to the effect of "each consent binding request MUST use a new stun transaction identifier. "