Ballot for draft-ietf-ice-trickle
Yes
No Objection
Recuse
Note: This ballot was opened for revision 17 and is now closed.
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.
[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.
UPDATED: I am recusing as I am an author. As the below are comments, feel free to do whatever with them. Comments in context: https://mozphab-ietf.devsvcdev.mozaws.net/D3650 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"