[rtcweb] Review of draft-ietf-rtcweb-stun-consent-freshness-05

[Paul Kyzivat <[e-mail]>]

Some comments from reading the latest version:

Introduction:

    WebRTC endpoints are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    endpoints interwork with other endpoints that support only ICE-lite
    (e.g. gateways) those endpoints will not generate consent checks, but
    just respond to consent checks they receive.

Having just read the overview document, I question the terminology 
above. The following would be more consistent with the overview:

    WebRTC browsers are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    browsers interwork with other WebRTC devices that support only
    ICE-lite (e.g. gateways) those endpoints will not generate consent
    checks, but just respond to consent checks they receive.

or perhaps you mean:

    WebRTC devices are required to support full ICE as specified in
    section 3.4 of [I-D.ietf-rtcweb-transports].  However, when WebRTC
    devices interwork with other endpoints that support only ICE-lite
    (e.g. gateways) those endpoints will not generate consent checks, but
    just respond to consent checks they receive.

Section 4.1:

    ...  To prevent expiry of consent, a STUN binding
    request is sent every N milliseconds, where N SHOULD be 5000
    milliseconds and MUST be randomized at least 20% above and 20% below
    that value (to prevent prevent network synchronization).  Using the
    value 5000 milliseconds and that 20% randomization range, N would be
    a value between 4000 and 6000.  ...

The normative requirement is weird here. (I MUST do the randomization, 
but that forces me to violate the SHOULD.) Do you mean the central value 
SHOULD be 5000, but in the case that it is some other value then the 
range should be from 20% below to 20% above that value? Would that 20% 
be appropriate if I changed N to 500 or 50000? Also, is the 
randomization to be done once for the session, or repeated for each 
consent request that is sent?

I think the following gives the same rule in an easier to understand way:

    ...  To prevent expiry of consent, a STUN binding request MUST be
    every N milliseconds, where N is chosen randomly in the interval
    [.8N, 1.2N] (to prevent prevent network synchronization), where N
    SHOULD be 5000.  Using the value 5000 milliseconds and that 20%
    randomization range, N would be a value between 4000 and 6000.  ...

Note this is equivalent to [N, 1.5N] with the recommended value of N 
changed to 4000. That might be easier.

(And, if I remember my math, it would be more proper to write the 
interval as "[N, 1.5N)". But that may be disturbing to programmers. As a 
programmer I'd more likely write "[N, int(1.5N)-1]", but that is ugly in 
text.)

	Thanks,
	Paul