Re: [Ice] Re-nomination and candidate pair switching in RFC 5245bis - PROPOSAL

[Peter Thatcher <[e-mail]>]

On Wed, Aug 30, 2017 at 11:23 AM Bernard Aboba <[e-mail]>
wrote:

> On Aug 30, 2017, at 12:28 PM, Peter Thatcher <[e-mail]> wrote:
>
> On Wed, Aug 30, 2017 at 9:26 AM Peter Thatcher <[e-mail]>
> wrote:
>
> As far as "just enough" so that it isn't a hindrance: that's why I wanted
>> to say that agents *may* switch.  It allows a renomination in the future.
>> Saying they MUST NOT is a hindrance.  I would be fine if the *may* requires
>> negotiation.  That's what
>> https://www.ietf.org/archive/id/draft-thatcher-ice-renomination-01.txt does:
>> it negotiates "renomination".  And that's what Chrome's implementation of
>> WebRTC does.
>>
>
> [BA] It seems like the document would at least need to talk about consent
> to include a "may". As it is, negotiating "ice2" only means that you're
> talking to a slightly refurbished RFC 5245 implementation. That's like the
> difference between a new car with driver assist (a modern WebRTC ICE
> implementation with Trickle) and an Edsel that's been waxed and given an
> oil change.
>

You always need to have consent to use a candidate pair.  I guess the
question you're asking is how recent does the consent need to be.  But I'm
not sure we need to standardize that.  If an implementation chooses to be
too aggressive about switching, it will send a path that doesn't work.  In
your analogy, you're worried about the driver assist doing something dumb
and crashing into the Edsel.  Well, don't ship a car that crashes.  Do we
need to standardize "don't switch to a candidate pair that doesn't work"
(AKA don't crash)?