Re: [rtcweb] WG Last Call for draft-ietf-rtcweb-stun-consent-freshness

[Muthu Arul Mozhi Perumal <[e-mail]>]

An ICE-lite entity by definition doesn't generate STUN requests which means
it doesn't perform consent freshness as described in the draft. If it does,
it is not a ICE-lite entity. You have only two types of entities to interop
test with. I don't see any use of specifying a MUST NOT for ICE-lite.

Muthu

On Mon, Aug 25, 2014 at 6:13 PM, Roman Shpount <[e-mail]> wrote:

> On Mon, Aug 25, 2014 at 6:55 AM, Muthu Arul Mozhi Perumal <
> [e-mail]> wrote:
>
>> I thought a "SHOULD perform" is more appropriate for a WebRTC device as
>> it doesn't implement the public API and might run a proprietary/native app
>> running in a constrained environment and the overhead of performing the
>> periodic consent might overweigh the benefits. However, I don't have an
>> issue of making it a MUST -- at least no one has objected so far. I hear
>> the following options from the discussions so far:
>>
>> Option 1:
>> WebRTC browser - MUST
>> WebRTC device - MUST
>> Other (WebRTC/non-WebRTC) entities - MAY
>>
>> Option 2:
>> Any WebRTC entity doing full ICE - MUST
>> Other (WebRTC/non-WebRTC) entities - MAY
>>
>>
>>
> To be clear, my opinion is
>
> Any WebRTC entity implementing full ICE - MUST
> Any WebRTC entity (such as WebRTC gateway) implementing ICE-lite -- MUST
> NOT
>
> This way we are not inventing entity types and not defining behaviors
> which would never be used (such as sending consent from an end point which
> would send no STUN requests otherwise). This will also reduce the number of
> interop cases from four (full ICE with consent, full iCE without consent,
> ICE-lite, ICE-lite with consent) to only two (full ICE with consent,
> ICE-lite).
> _____________
> Roman Shpount
>
>