Draft: draft-ietf-ice-rfc5245bis

Commentary: The following issues are addressed in this commit : 
 LGTM 
 To prevent one check list from starving . 
 This was discussed ( and , as far as I am concerned , agreed ) on the list 1st June . But , it 's good to have a reminder :) 
 This one has not been addressed as far as I can tell . Now we get to decided if it 's important enough or not to do something about :) 
 I had a look at this , but for some reason it never got implemented . I think it should be an easy fix . 
 The changes section looks very small compared to how many changes we 've made , so it definitely needs updating . Now we need to decide whether we have to update it before or after requesting publication . 
 Yes - we just have to remember everything :) However , I do n't think we should go into details : the major changes ( that I can think of when writing this ) are removal of regular / aggressive nomination , and the changes related to " Emil 's table " . 
 LGTM
In order to limit the attacks described in sec-ice-hammer, an ICE
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 order to limit the attacks described in sec-ice-hammer, an ICE
agent MUST limit the total number of connectivity checks the agent
performs across all check lists in the check list set.  This is done
by limiting the total number of candidate pairs in the check list
set.  The default limit of candidate pairs for the check list set is
100, but the value MUST be configurable.  The limit is enforced by,
within in each check list, discarding lower-priority candidate pairs
until the total number of candidate pairs in the check list set is
smaller than the limit value.  The discarding SHOULD be done evenly
so that the number of candidate pairs in each check list is reduced
the same amount.
It is RECOMMENDED that a lower limit value than the default is picked
when possible, and that the value is set to the maximum number of
plausible candidate pairs that might be created 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.
The specification was generalized to be more usable with any
protocol and the parts that are specific to SIP and SDP were moved
to a SIP/SDP usage document I-D.ietf-mmusic-ice-sip-sdp.
Default candidates, multiple components, ICE mismatch detection,
subsequent offer/answer, and role conflict resolution were made
optional since they are not needed with every protocol using ICE.
With IPv6, the precedence rules of RFC 6724 are used instead of
the obsoleted RFC 3483 and using address preferences provided by
the host operating system is recommended.
Clarify procedures in RFC 5245.
Make technical changes, due to discovered flows in RFC 5245 and
based on feedback from the community that has implemented and
deployed ICE applications based on RFC 5245.
Make the procedures signaling protocol independent, by removing
the SIP and SDP procedures.  Procedures specific to a signaling
protocol will be defined in separate usage documents.  I-D.ietf-
mmusic-ice-sip-sdp defines the ICE usage with SIP and SDP.
Aggressive nomination removed.
The procedures for calculating candidate pair states and
scheduling connectivity checks modified.
Procedures for calculation of Ta and RTO modified.
Active check list and frozen check list definitions removed.
'ice2' ice option added.
IPv6 considerations modified.