Draft: draft-ietf-ice-rfc5245bis

Commentary: Prune clarification , and adding the text about removing lower - priority candidates into separate section . Also clarifying that check list procedures are re - done whenever a check list is updated . 
 Looks good to me if the typo gets fixed .
The base of a server reflexive candidate is the host candidate
from which it was derived.  A host candidate is also said to have
a base, equal to that candidate itself.  Similarly, the base of a
relayed candidate is that candidate itself.
The transport address that an agent sends from for a particular
candidate.  For host-, server reflexive- and peer reflexive
candidates the base is the same as the host candidate.  For
relayed candidates the base is the same as the relayed candidate
(i.e., the transport address used by the TURN server to send
from).
The candidate pair selected by ICE for sending and receiving media
is called the selected pair, and each of its candidates is called
the selected candidate.
The candidate pair selected by ICE for sending and receiving media
is called the selected pair, and each of its candidates is called
the selected candidate.  Before a candidiate pair has been
selected, any valid candidiate pair can be used for sending and
receiving media (only one candidiate pair at any given time).
An agent gathers candidates when it believes that communication is
imminent.  An initiating agent can do this based on a user interface
cue, or based on an explicit request to initiate a session.  Every
candidate is a transport address.  It also has a type and a base.
Four types are defined and gathered by this specification -- host
candidates, server reflexive candidates, peer reflexive candidates,
and relayed candidates.  The server reflexive candidates are gathered
using STUN or TURN, and relayed candidates are obtained through TURN.
Peer reflexive candidates are obtained in later phases of ICE, as a
consequence of connectivity checks.  The base of a candidate is the
candidate that an agent must send from when using that candidate.
An agent gathers candidates when it believes that communication is
imminent.  An initiating agent can do this based on a user interface
cue, or based on an explicit request to initiate a session.  Every
candidate is a transport address.  It also has a type and a base.
Four types are defined and gathered by this specification -- host
candidates, server reflexive candidates, peer reflexive candidates,
and relayed candidates.  The server reflexive candidates are gathered
using STUN or TURN, and relayed candidates are obtained through TURN.
Peer reflexive candidates are obtained in later phases of ICE, as a
consequence of connectivity checks.
There is one check list per in-use media stream resulting from the
candidate exchange.  To form the check list for a media stream, the
agent forms candidate pairs, computes a candidate pair priority,
orders the pairs by priority, prunes them, and sets their states.
These steps are described in this section.
First, the agent takes each of its candidates for a media stream
(called LOCAL CANDIDATES) and pairs them with the candidates it
received from its peer (called REMOTE CANDIDATES) for that media
stream.  In order to prevent the attacks described in sec-ice-hammer,
agents MAY limit the number of candidates they'll accept in an
candidate exchange process.  A local candidate is paired with a
remote candidate if and only if the two candidates have the same
component ID and have the same IP address version.  It is possible
that some of the local candidates won't get paired with remote
candidates, and some of the remote candidates won't get paired with
local candidates.  This can happen if one agent doesn't include
candidates for the all of the components for a media stream.  If this
happens, the number of components for that media stream is
effectively reduced, and considered to be equal to the minimum across
both agents of the maximum component ID provided by each agent across
all components for the media stream.
There is one check list per in-use media stream resulting from the
candidate exchange.  To form the check list for a media stream, the
agent forms candidate pairs, computes a candidate pair priority,
orders the pairs by priority, prunes them, removes lower-priority
candidates and sets their states.  These steps are described in this
section.  If a check list is updated (e.g, due to detection of peer
reflexive candidates), the agent will re-perform the steps for the
updated check list.
First, the agent takes each of its candidates for a media stream
(called LOCAL CANDIDATES) and pairs them with the candidates it
received from its peer (called REMOTE CANDIDATES) for that media
stream.  A local candidate is paired with a remote candidate if and
only if the two candidates have the same component ID and have the
same IP address version.  It is possible that some of the local
candidates won't get paired with remote candidates, and some of the
remote candidates won't get paired with local candidates.  This can
happen if one agent doesn't include candidates for the all of the
components for a media stream.  If this happens, the number of
components for that media stream is effectively reduced, and
considered to be equal to the minimum across both agents of the
maximum component ID provided by each agent across all components for
the media stream.
The candidate pairs whose local and remote candidates are both the
default candidates for a particular component is called,
unsurprisingly, the default candidate pair for that component.  This
is the pair that would be used to transmit media if both agents had
not been ICE aware.
The candidate pairs whose local and remote candidates are both the
default candidates for a particular component is called the default
candidate pair for that component.  This is the pair that would be
used to transmit media if both agents had not been ICE aware.
This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed.  Each check involves
sending a request from a local candidate to a remote candidate.
Since an agent cannot send requests directly from a reflexive
candidate, but only from its base, the agent next goes through the
sorted list of candidate pairs.  For each pair where the local
candidate is server reflexive, the server reflexive candidate MUST be
replaced by its base.  Once this has been done, the agent MUST prune
the list.  This is done by removing a pair if its local and remote
candidates are identical to the local and remote candidates of a pair
higher up on the priority list.  The result is a sequence of ordered
candidate pairs, called the check list for that media stream.
In addition, in order to limit the attacks described in sec-ice-
hammer, an agent MUST limit the total number of connectivity checks
the agent performs across all check lists to a specific value, and
this value MUST be configurable.  A default of 100 is RECOMMENDED.
This limit is enforced by discarding the lower-priority candidate
pairs until there are less than 100.  It is RECOMMENDED that a lower
value be utilized when possible, set to the maximum number of
plausible checks that might be seen in an actual deployment
configuration.  The requirement for configuration is meant to provide
a tool for fixing this value in the field if, once deployed, it is
found to be problematic.
This sorted list of candidate pairs is used to determine a sequence
of connectivity checks that will be performed.  Each check involves
sending a request from a local candidate to a remote candidate.
Since an agent cannot send requests directly from a reflexive
candidate (server reflexive or peer reflexive), but only from its
base, the agent next goes through the sorted list of candidate pairs.
For each pair where the local candidate is reflexive, the candidate
MUST be replaced by its base.  Once this has been done, the agent
MUST prune the list.  This is done by removing a pair if its local
and remote candidates are identical to the local and remote
candidates of a pair higher up on the priority list.  The result is a
sequence of ordered candidate pairs, called the check list for that
media stream.
In order to limit the attacks described in sec-ice-hammer, an agent
MUST limit the total number of connectivity checks the agent performs
across all check lists to a specific value, and this value MUST be
configurable.  A default of 100 is RECOMMENDED.  This limit is
enforced by discarding the lower-priority candidate pairs until there
are less than 100.  It is RECOMMENDED that a lower value be utilized
when possible, set to the maximum number of plausible checks that
might be seen in an actual deployment configuration.  The requirement
for configuration is meant to provide a tool for fixing this value in
the field if, once deployed, it is found to be problematic.
In this state, ICE checks have produced nominated pairs for each
component of the media stream.
In this state, ICE checks have produced selected pairs for each
component of the media stream.
It will be very common that the pair will not be on any check list.
Recall that the check list has pairs whose local candidates are never
server reflexive; those pairs had their local candidates converted to
the base of the server reflexive candidates, and then pruned if they
were redundant.  When the response to the STUN check arrives, the
mapped address will be reflexive if there is a NAT between the two.
In that case, the valid pair will have a local candidate that doesn't
match any of the pairs in the check list.
It will be very common that the pair will not be on any check list.
Recall that the check list has pairs whose local candidates are never
reflexive; those pairs had their local candidates converted to the
base of the reflexive candidates, and then pruned if they were
redundant.  When the response to the STUN check arrives, the mapped
address will be reflexive if there is a NAT between the two.  In that
case, the valid pair will have a local candidate that doesn't match
any of the pairs in the check list.
Agents always send media using a candidate pair, called the selected
candidate pair.  An agent will send media to the remote candidate in
the selected pair (setting the destination address and port of the
packet equal to that remote candidate), and will send it from the
local candidate of the selected pair.  When the local candidate is
server or peer reflexive, media is originated from the base.  Media
sent from a relayed candidate is sent from the base through that TURN
server, using procedures defined in RFC5766.
If the local candidate is a relayed candidate, it is RECOMMENDED that
an agent create a channel on the TURN server towards the remote
candidate.  This is done using the procedures for channel creation as
defined in Section 11 of RFC5766.
Agents always send media using a candidate pair, using candidate
pairs in the Valid list.  Once a candidiate pair has been selected
only that candidiate pair (referred to as selected pair) is used for
sending media.  An agent will send media to the remote candidate
(i.e., setting the destination address and port of the packet equal
to that remote candidate), and will send it from the base associated
with the candidiate pair used for sending media.  In case of a
relayed candidate, media is sent from the agent and forwareded
through the base (located in the TURN server), using the procedures
defined in RFC5766.
If the local candidate is a relayed candidate, it is RECOMMENDED that
an agent creates a channel on the TURN server towards the remote
candidate.  This is done using the procedures for channel creation as
defined in Section 11 of RFC5766.
If the selected pair for at least one component of a media stream is
empty, an agent MUST NOT send media for any component of that media
stream.  If the selected pair for each component of a media stream
has a value, an agent MAY send media for all components of that media
stream.
Unless an agent is able to produce a selected pair for all components
associated with a media stream, the agent MUST NOT continue sending
media for any component associated with that media stream.
A lite implementation MUST NOT send media until it has a Valid list
that contains a candidate pair for each component of that media
stream.  Once that happens, the agent MAY begin sending media
packets.  To do that, it sends media to the remote candidate in the
pair (setting the destination address and port of the packet equal to
that remote candidate), and will send it from the local candidate.
A lite implementation MUST NOT send media until it has a Valid list
that contains a candidate pair for each component of that media
stream.  Once that happens, the agent MAY begin sending media
packets.  To do that, it sends media to the remote candidate in the
pair (setting the destination address and port of the packet equal to
that remote candidate), and will send it from the base associated
with the candidiate pair used for sending media.  In case of a
relayed candidate, media is sent from the agent and forwareded
through the base (located in the TURN server), using the procedures
defined in RFC5766.
ICE implementations MUST be prepared to receive media on each
component on any candidates provided for that component in the most
recent candidate exchange (in the case of RTP, this would include
both RTP and RTCP if candidates were provided for both).
Even though ICE agents are only allowed to send media using valid
candidiate pairs (and, once a candidiate pair has been selected, only
on the selected pair) ICE implementations SHOULD by default be
prepared to receive media on any of the candidiates provided in the
most recent candidiate exchange with the peer.  Specific ICE usages
MAY define rules that differe from this, e.g., by defining that media
must not be sent until selected pairs have been procduced for each
component associated with that media.