[MMUSIC] Next steps on "passive-aggressive" nomination

[Justin Uberti <[e-mail]>]

At IETF 92, we discussed passive-aggressive nomination, which allows
implementations to
a) send media as soon as a single check succeeds (like aggressive nom)
b) give the controlling side full discretion in terms of which pair to
select (like regular nom)
c) allow the controlled side to know when nomination is complete (like
regular nom)

The conclusion from IETF 92
<http://www.ietf.org/proceedings/92/minutes/minutes-92-mmusic#h.vqmjfv9a7r6k>
was that this looked promising (although we *might* want to have some SDP
signaling to control when it is used). We also agreed to solicit alternate
proposals and decide at IETF 93 which proposal we wanted to proceed with.
On that topic, I am currently aware of one competing proposal, namely this
document <https://tools.ietf.org/html/draft-jennings-mmusic-ice-fix-00> from
Cullen.

I have asked for agenda time to discuss the comments that came up at IETF
92, namely:
- potential interoperability concerns with endpoints that only do regular
nomination (may drop media that arrives before USE-CANDIDATE)
- potential interoperability concerns with endpoints that only do
aggressive nomination (may ignore selected pair indicated in USE-CANDIDATE;
may drop media before USE-CANDIDATE; may not send media until USE-CANDIDATE)
- do we need some way to negotiate use of passive-aggressive nomination, to
prevent the above problems
- do we need some way to suppress use of aggressive nomination, to allow us
to avoid needing to support regular, passive-aggressive, and aggressive
nomination in future clients

Are there any other concerns that I missed?