Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
RFC 8838

Note: This ballot was opened for revision 17 and is now closed.

(Ben Campbell) Yes

(Alissa Cooper) Yes

Benjamin Kaduk Yes

Comment (2018-03-29 for -18)
No email
send info
Please consider using the RFC 8174 boilerplate to supplement RFC 2119.

Section 5 implies that plain ICE includes a provision for an ICE description
with no candidates, but I'm failing to find that reference.  The rfc5245bis draft seems
to always assume that there will be at least a host candidate.
Is perhaps a different reference intended?

In section 8.2:

   o  As a standalone notification (e.g., after STUN Binding requests or
      TURN Allocate requests to a server time out and the agent has is
      not actively gathering candidates)

s/has is/is/

Section 13 says that trickled candidate information may cause an ICE
restart using the 5245bis semantics, but I don't see anywhere in
5245bis that would have additional candidate information induce a
restart.  Is this the right reference?

Thanks for updating per the secdir review about the in-order requirement!
However, we currently have language about transmitting candidates/end-of-candidates
"not more than once", but we kind of do want exactly-once semantics for
end-of-candidates, unless ICE terminates normally prior to that.
Is there a good way to phrase that more clearly?

Maybe the last bullet of section 15 (must be able to send
end-of-candidates) should come earlier in the list, in particular before the
requirement for nonduplication and in-order.

(Ignas Bagdonas) No Objection

Comment (2018-04-05 for -18)
No email
send info
Have read through the document but did not perform a detailed review.

(Deborah Brungard) No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Comment (2018-04-04 for -18)
No email
send info
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.

(Mirja Kühlewind) No Objection

Comment (2018-04-03 for -18)
No email
send info
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.

(Alexey Melnikov) No Objection

(Adam Roach) (was Discuss) No Objection

Comment (2018-05-01)
No email
send info
[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



>  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.  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".



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")



>    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.

Martin Vigoureux No Objection

(Eric Rescorla) (was No Objection) Recuse

Comment (2018-04-04 for -18)
No email
send info
UPDATED: I am recusing as I am an author. As the below are comments,
feel free to do whatever with them.

Comments in context:

I'm a listed author on this document, but I haven't worked on it in quite
some time, so this is read with mostly fresh eyes.

Important comments:
   agent SHOULD follow a policy of keeping the higher priority candidate
   unless it is peer reflexive.
IMPORTANT: This section is confusing wrt how pruning works. AIUI, you
follow ordinary 5245 pruning procedures at the beginning of the
connection for whatever candidates you have. Is that incorrect?

Also, why are you proposing prioritizing other candidates over prflx candidates? That's not the procedure in 5245.

   maximum number of candidate pairs (100 by default as per
   [rfc5245bis]), the new pair is discarded.
IMPORTANT: Why are you discarding before you check for redundancy?
This seems like it evicts the wrong pair.

   new candidate to the priority of the pre-existing candidate and then
   re-sorting the check list.
IMPORTANT: This seems to slow down checks if the existing check is
already running. What is the rationale for this?

Other comments:

   Generation:  All of the candidates conveyed within an ICE session (as
      defined in [rfc5245bis]).

Note that "generation" isn't a 5245 term, so this text could be clearer.

   ICE Description:  Any session-related (as opposed to candidate-
      related) attributes required to configure an ICE agent.  These

It might be helpful to say "ICE session" to distinguish from session-level attributes in SDP

   for instance, the encoding for the Session Description Protocol (SDP)
   [RFC4566] is defined in [I-D.ietf-mmusic-trickle-ice-sip].

Note that this has the side effect of precluding agressive nomination

   consider the overall session to be under active negotiation as soon
   as possible.)
   As noted in Section 3, in application protocols that use SDP the

Why is this a benefit, actually? I see why it is in the offer so that you can parallelize the gathering on both sides, but why here?

   (rather than as a part of the initial ICE description or a response
   thereto), it is the responsibility of the using protocol to define
   methods for associating the indication with one or more specific data

I see here you say "using protocol" as opposed to "application"

   o  A signaling protocol SHOULD provide a way for parties to advertise
      and discover support for Trickle ICE before an ICE session begins

And here you use "signaling protocol" rather than "using protocl"

   To achieve this, when trickling candidates, agents MUST respect the
   order of components as reflected by their component IDs; that is,

I'm surprised to see a MUST paired with "While not crucial"