Change:
4.1.17. <del> The addIceCandidate method provides a remote candidate to the ICE agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  The pair of MID and ufrag is used to determine the m= section and ICE candidate generation to which the candidate belongs. If the MID is not present, the m= section index is used to look up the locally generated MID (see sec.applying-a-remote-desc), which is used in place of a supplied MID.  If these values or the candidate string are invalid, an error is generated. The purpose of the ufrag is to resolve ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is absent, the candidate MUST be assumed to belong to the most recently applied remote description.  Connectivity checks will be sent to the new candidate. This method can also be used to provide an end-of-candidates indication to the ICE agent, as defined in I-D.ietf-ice-trickle). The MID and ufrag are used as described above to determine the m= section and ICE generation for which candidate gathering is complete. If the ufrag is not present, then the end-of-candidates indication MUST be assumed to apply to the relevant m= section in the most recently applied remote description.  If neither the MID nor the m= index is present, then the indication MUST be assumed to apply to all m= sections in the most recently applied remote description. This call will result in a change to the state of the ICE Agent, and may result in a change to media state if it results in connectivity being established. </del> <ins> The addIceCandidate method provides an update to the ICE agent via an IceCandidate object sec.ice-candidate-format.  If the IceCandidate's candidate field is filled in, the IceCandidate is treated as a new remote ICE candidate, which will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  Otherwise, the IceCandidate is treated as an end-of-candidates indication, as defined in I-D.ietf-ice-trickle. In either case, the m= section index, MID, and ufrag fields from the supplied IceCandidate are used to determine which m= section and ICE candidate generation the IceCandidate belongs to, as described in sec.ice-candidate-format above.  In the case of an end-of-candidates indication, the absence of both the m= section index and MID fields is interpreted to mean that the indication applies to all m= sections in the specified ICE candidate generation.  However, if both fields are absent for a new remote candidate, this MUST be treated as an invalid condition, as specified below. If any IceCandidate fields contain invalid values, or an error occurs during the processing of the IceCandidate object, the supplied IceCandidate MUST be ignored and an error MUST be returned. Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate, connectivity checks will be sent to the new candidate. </ins> 4.2.

Discussion:
Upon review, it became apparent that this section needed more work to handle the end-of-candidates case properly. I took a first cut at reworking it, but more polish is needed. NAME NAME PTAL to see if you see anything egregiously wrong before I finish polishing it up.
At 4.1.17's first paragraph: Why is "if parsed successfully" necessary to call out? I suggest removing the phrase.
I think it's useful to remind people of this.
I don't care
Suggest moving this text to the last sentence of this para, where we already mention error conditions.