Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
draft-ietf-ice-trickle-21

[DISCUSS regarding document reference issue removed -- this document will probably not need to change to address the issue]

This document appears to generally be in good shape. I have some fairly minor
comments.

---------------------------------------------------------------------------

§11:

>  signaling protocol in use.  When this happens, agents will use
>  [rfc5245bis] semantics to determine whether or not the new candidate
>  information require an ICE restart.

nit: "require"

---------------------------------------------------------------------------

§12:

> 12.  Unilateral Use of Trickle ICE (Half Trickle)

I find the use of the word "Unilateral" here to be confusing: the offering party
indicates support, and the answering party takes advantage of that support. I
would suggest using a different term ("Asymmetrical" maybe?); or, even more
simply, just replacing the entire section title with "Half Trickle".


---------------------------------------------------------------------------

§12:

The following passage indicates that the offer in a half-trickle situation might
not contain a full generation of candidates:

>  The initial ICE
>  description for half trickle would typically contain an end-of-
>  candidates indication, although this is not mandatory because if
>  trickle support is confirmed then the initiator can choose to trickle
>  additional candidates before it conveys an end-of-candidates
>  indication.

But then, two sentences later:

>  Because the initial ICE description contain a full
>  generation of candidates...

...which seems to contradict that indication.

(also, nit: "contains" rather than "contain")

---------------------------------------------------------------------------

§15:

>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998
>    a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 8998

[repeating a comment from draft-ietf-mmusic-trickle-ice-sip]

Thanks for the IPv6 example; however, I have a *lot* of heartburn with the
selection of an example that demonstrates IPv6 NAT behavior. Since ICE's srflx
behavior is fundamentally tied to IPv4 NATs (and should not be an issue with
IPv6, as NATs are unnecessary), I think it's okay for the srflx examples to go
ahead and show IPv4 addresses.

I *really* don't want to publish an RFC that demonstrates NATting of IPv6.

Have read through the document but did not perform a detailed review.

Thanks for the well written doc! On minor comment on the use of normative language:

Section 8: "Also, candidate trickling needs to be correlated to a specific ICE
   session, so that if there is an ICE restart, any delayed updates for
   a previous session can be recognized as such and ignored by the
   receiving party. "
Maybe use normative language here: "Also, candidate trickling MUST be correlated to a specific ICE
   session, so that if there is an ICE restart, any delayed updates for
   a previous session can be recognized as such and ignored by the
   receiving party. "
I assume this is not using normative language because there is a normative requirement in sec 14. However, not using normative language in both cases seems rather confusing to me. Alternatively , I would suggest to add a forward reference.

Even though I am happy to see IPv6 examples, I share Adam's concern about using IPv6 with srflx being seen as an implicit endorsement of IPv6 NATs.