What does it mean to NOT nominate candidatePair?

[jan-ivar]

The steps to nominate a candidate pair say: "If accepted is false, instruct the ICE agent to not nominate candidatePair, and instead to continue to perform connectivity checks."

What does it mean to "not nominate"? Can we just say "instruct the ICE agent to continue to perform connectivity checks"?

Or is it a nomination ban for that particular pair forever? If not, how long should the agent wait before trying again?

A non-normative note (with normative MAY?) suggests that calling setSelectedCandidatePair allows the agent to nominate again, but is that the only case?

Some clarifications of how and when the ICE agent is expected to respond would be useful for interoperability.

[jan-ivar]

cc @sam-vi

[jan-ivar]

It continues: "The ICE agent may continue to send data using the candidate pair indicated by candidatePair unless instructed to use another candidate pair with setSelectedCandidatePair."

Is this "may" a normative MAY, or a MUST? If not, we could use "will" and use a non-normative note if this is just an observation.

It's a bit tricky since we seem to be modifying ICE agent behavior here.

[sam-vi]

"not nominate" means that the ICE agent should continue to perform connectivity checks and maybe propose another candidate pair for nomination.

RFC8445 section 8.1.1 permits this flexibility:

The criteria for stopping the connectivity checks and for picking a pair for nomination are outside the scope of this specification. They are a matter of local optimization.

So whether a cancelled nomination is a ban or a deferral for a certain period is an implementation detail of the ICE agent. This shouldn't affect interoperability because the exact behaviour wasn't constrained to begin with by RFC8445 (or by webrtc-pc).

The non-normative note could be extended to clarify that the same candidate pair could be nominated again either by the ICE agent or as a result of setSelectedCandidatePair.

It continues: "The ICE agent may continue to send data using the candidate pair indicated by candidatePair unless instructed to use another candidate pair with setSelectedCandidatePair."

Is this "may" a normative MAY, or a MUST? If not, we could use "will" and use a non-normative note if this is just an observation.

It's a bit tricky since we seem to be modifying ICE agent behavior here.

This is not a normative statement, and the intention is not to modify ICE agent behaviour. This refers to RFC8445 section 12.1:

An ICE agent MAY send data on any valid pair before selected pairs have been produced for the data stream.

So your suggestion to change to "will" and extract out the observation into a non-normative note makes sense.

I can draft a PR with the clarifications.

[pthatcher]

Nominating a candidate pair means sending the USE_CANDIDATE STUN attribute (or the "nomination" attribute from draft-thatcher-ice-renomination-01). Not nominating means not sending that STUN attribute.

[jan-ivar]

Understood. Algorithms however normally detail what steps to take, not steps not to take (which I think risks introducing ambiguity about when steps are done). How about:

"8. If accepted is false, abort these steps and instruct the ICE agent to continue to perform connectivity checks."

...and put the rest in a note?

Note: The ICE agent will continue to send data using the candidate pair indicated by candidatePair unless instructed to use another candidate pair with setSelectedCandidatePair.

Aborting the steps to ahead of the final step to "instruct the ICE agent to nominate the candidate pair indicated by candidatePair." is hopefully clear enough.