Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol
draft-ietf-ice-trickle-21
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-06-01
|
21 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2020-05-08
|
21 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2020-03-16
|
21 | (System) | RFC Editor state changed to RFC-EDITOR from IESG |
2018-09-07
|
21 | (System) | RFC Editor state changed to IESG from AUTH48 |
2018-08-13
|
21 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2018-07-20
|
21 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2018-06-11
|
21 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2018-05-25
|
21 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2018-05-25
|
21 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2018-05-22
|
21 | (System) | RFC Editor state changed to EDIT |
2018-05-22
|
21 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2018-05-22
|
21 | (System) | Announcement was received by RFC Editor |
2018-05-22
|
21 | (System) | IANA Action state changed to In Progress |
2018-05-22
|
21 | Cindy Morgan | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2018-05-22
|
21 | Cindy Morgan | IESG has approved the document |
2018-05-22
|
21 | Cindy Morgan | Closed "Approve" ballot |
2018-05-22
|
21 | Ben Campbell | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2018-05-21
|
21 | Ben Campbell | Ballot approval text was generated |
2018-05-01
|
21 | Adam Roach | [Ballot comment] [DISCUSS regarding document reference issue removed -- this document will probably not need to change to address the issue] This document appears to … [Ballot comment] [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. |
2018-05-01
|
21 | Adam Roach | [Ballot Position Update] Position for Adam Roach has been changed to No Objection from Discuss |
2018-04-15
|
21 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-21.txt |
2018-04-15
|
21 | (System) | New version approved |
2018-04-15
|
21 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Peter Saint-Andre , Eric Rescorla |
2018-04-15
|
21 | Peter Saint-Andre | Uploaded new revision |
2018-04-09
|
20 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-04-09
|
20 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-20.txt |
2018-04-09
|
20 | (System) | New version approved |
2018-04-09
|
20 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Peter Saint-Andre , Eric Rescorla |
2018-04-09
|
20 | Peter Saint-Andre | Uploaded new revision |
2018-04-05
|
19 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2018-04-05
|
19 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-04-05
|
19 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-19.txt |
2018-04-05
|
19 | (System) | New version approved |
2018-04-05
|
19 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Peter Saint-Andre , Eric Rescorla |
2018-04-05
|
19 | Peter Saint-Andre | Uploaded new revision |
2018-04-05
|
18 | Ignas Bagdonas | [Ballot comment] Have read through the document but did not perform a detailed review. |
2018-04-05
|
18 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2018-04-05
|
18 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
2018-04-04
|
18 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-04-04
|
18 | Eric Rescorla | [Ballot comment] UPDATED: I am recusing as I am an author. As the below are comments, feel free to do whatever with them. Comments in … [Ballot comment] 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" |
2018-04-04
|
18 | Eric Rescorla | [Ballot Position Update] Position for Eric Rescorla has been changed to Recuse from No Objection |
2018-04-04
|
18 | Suresh Krishnan | [Ballot comment] Even though I am happy to see IPv6 examples, I share Adam's concern about using IPv6 with srflx being seen as an implicit … [Ballot comment] 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. |
2018-04-04
|
18 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2018-04-04
|
18 | Sarah Banks | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Sarah Banks. Sent review to list. |
2018-04-03
|
18 | Adam Roach | [Ballot discuss] This document is part of the multi-document problem I flag in my DISCUSS on draft-ietf-mmusic-trickle-ice-sip, and needs to block on finding a … [Ballot discuss] This document is part of the multi-document problem I flag in my DISCUSS on draft-ietf-mmusic-trickle-ice-sip, and needs to block on finding a solution to that issue. |
2018-04-03
|
18 | Adam Roach | [Ballot comment] This document appears to generally be in good shape. I have some fairly minor comments. --------------------------------------------------------------------------- §11: > signaling protocol in use. When … [Ballot comment] 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. |
2018-04-03
|
18 | Adam Roach | Ballot comment and discuss text updated for Adam Roach |
2018-04-03
|
18 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2018-04-03
|
18 | Alissa Cooper | [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper |
2018-04-03
|
18 | Mirja Kühlewind | [Ballot comment] Thanks for the well written doc! On minor comment on the use of normative language: Section 8: "Also, candidate trickling needs to be … [Ballot comment] 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. |
2018-04-03
|
18 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-04-03
|
18 | Adam Roach | [Ballot discuss] I haven't yet reviewed this document, but it is part of the multi-document problem I flag in my DISCUSS on draft-ietf-mmusic-trickle-ice-sip, and … [Ballot discuss] I haven't yet reviewed this document, but it is part of the multi-document problem I flag in my DISCUSS on draft-ietf-mmusic-trickle-ice-sip, and needs to block on finding a solution to that issue. |
2018-04-03
|
18 | Adam Roach | [Ballot Position Update] New position, Discuss, has been recorded for Adam Roach |
2018-04-02
|
18 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2018-04-02
|
18 | Eric Rescorla | [Ballot comment] 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 … [Ballot comment] 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" |
2018-04-02
|
18 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
2018-04-02
|
18 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2018-03-29
|
18 | Benjamin Kaduk | [Ballot comment] Please consider using the RFC 8174 boilerplate to supplement RFC 2119. Section 5 implies that plain ICE includes a provision for an … [Ballot comment] 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. |
2018-03-29
|
18 | Benjamin Kaduk | [Ballot Position Update] New position, Yes, has been recorded for Benjamin Kaduk |
2018-03-28
|
18 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2018-03-28
|
18 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-18.txt |
2018-03-28
|
18 | (System) | New version approved |
2018-03-28
|
18 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Peter Saint-Andre , Eric Rescorla |
2018-03-28
|
18 | Peter Saint-Andre | Uploaded new revision |
2018-03-08
|
17 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: David Mandelberg. |
2018-03-02
|
17 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2018-02-26
|
17 | Ben Campbell | Changed consensus to Yes from Unknown |
2018-02-26
|
17 | Ben Campbell | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2018-02-26
|
17 | Ben Campbell | Ballot has been issued |
2018-02-26
|
17 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
2018-02-26
|
17 | Ben Campbell | Created "Approve" ballot |
2018-02-26
|
17 | Ben Campbell | Ballot writeup was changed |
2018-02-25
|
17 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA - Not OK |
2018-02-25
|
17 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-17.txt |
2018-02-25
|
17 | (System) | New version approved |
2018-02-25
|
17 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Peter Saint-Andre , Eric Rescorla |
2018-02-25
|
17 | Peter Saint-Andre | Uploaded new revision |
2018-02-22
|
16 | Ben Campbell | Telechat date has been changed to 2018-04-05 from 2018-03-08 |
2018-02-22
|
16 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2018-02-20
|
16 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
2018-02-20
|
16 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-ice-trickle-16. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Services Operator has completed its review of draft-ietf-ice-trickle-16. If any part of this review is inaccurate, please let us know. The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete. In the ICE Options registry on the Interactive Connectivity Establishment (ICE) registry page located at: https://www.iana.org/assignments/ice/ A single, new registration will be made as follows: Name: trickle Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. The IANA Services Operator understands that this is the only action required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
2018-02-16
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2018-02-16
|
16 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Sarah Banks |
2018-02-11
|
16 | Roni Even | Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Roni Even. Sent review to list. |
2018-02-08
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2018-02-08
|
16 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to David Mandelberg |
2018-02-08
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-02-08
|
16 | Jean Mahoney | Request for Last Call review by GENART is assigned to Roni Even |
2018-02-08
|
16 | Ben Campbell | Placed on agenda for telechat - 2018-03-08 |
2018-02-08
|
16 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-02-08
|
16 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-02-22): From: The IESG To: IETF-Announce CC: ben@nostrum.com, ice-chairs@ietf.org, Nils Ohlmeier , draft-ietf-ice-trickle@ietf.org, … The following Last Call announcement was sent out (ends 2018-02-22): From: The IESG To: IETF-Announce CC: ben@nostrum.com, ice-chairs@ietf.org, Nils Ohlmeier , draft-ietf-ice-trickle@ietf.org, ice@ietf.org, nohlmeier@mozilla.com Reply-To: ietf@ietf.org Sender: Subject: Last Call: (Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol) to Proposed Standard The IESG has received a request from the Interactive Connectivity Establishment WG (ice) to consider the following document: - 'Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-02-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document describes "Trickle ICE", an extension to the Interactive Connectivity Establishment (ICE) protocol that enables ICE agents to send and receive candidates incrementally rather than exchanging complete lists. With such incremental provisioning, ICE agents can begin connectivity checks while they are still gathering candidates and considerably shorten the time necessary for ICE processing to complete. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/ballot/ No IPR declarations have been submitted directly on this I-D. |
2018-02-08
|
16 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-02-08
|
16 | Ben Campbell | Last call was requested |
2018-02-08
|
16 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-02-08
|
16 | Ben Campbell | Last call announcement was generated |
2018-02-08
|
16 | Ben Campbell | Ballot writeup was changed |
2018-02-08
|
16 | Ben Campbell | Ballot approval text was generated |
2018-02-02
|
16 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-02-02
|
16 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-16.txt |
2018-02-02
|
16 | (System) | New version approved |
2018-02-02
|
16 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , ice-chairs@ietf.org, Eric Rescorla , Peter Saint-Andre |
2018-02-02
|
16 | Peter Saint-Andre | Uploaded new revision |
2018-01-31
|
15 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-01-31
|
15 | Ben Campbell | This is my AD evaluation of draft-ietf-ice-trickle-16. The document is general well written and easy to follow. I have a few comments and questions I’d … This is my AD evaluation of draft-ietf-ice-trickle-16. The document is general well written and easy to follow. I have a few comments and questions I’d like to address prior to IETF LC. —————————————————— - section 3, 2nd to last paragraph: [Note: I already brought this up in a separate email, and Peter suggested a fix. I’m including it here for completeness] This paragraph is written in terms of the SDP ice-options attribute. It should talk about the generic ICE option described in section 10 of 5245bis. - 4, last sentence: “early as possible” seems a bit subjective for use with the SHOULD, especially since that will be very application depended. I imagine developers trying to decide if they should send an initial offer the second a user hovers over a contact (which may or may not be a good idea.) Please consider restating this without the 2119 SHOULD. - 5, 2nd to last paragraph, last sentence: Should “fallback to [RFC3264]” be “fallback to non-ICE processing rules”? -13, first sentence: "Either agent MAY convey subsequent candidate information at any time allowed by the signaling protocol in use.” I’m a little confused by this, since previous text said you MUST NOT keep trickling after sending end-of-candidates. From the context of the section, I assume this is talking about future exchanges (e.g. a new offer) , not trickling as a result of a previous change, but the words seem ambiguous. -16, 2nd paragraph: "Therefore a candidate for a specific component MUST NOT be conveyed prior to candidates for other components within the same foundation.” I’m confused by this sentence; it seems like a deadlock where no component candidates can be conveyed first. Should “other components” be “earlier components”? -16, paragraph after the SDP example: This seems to be an explanation of the example, not a normative statement. Please consider stating without the 2119 keywords. -18: Please consider using the IESG (iesg@ietf.org) as the contact. I know we’ve had individual contacts for these in the past, but the iesg address is (hopefully) more stable than individual or WG addresses. -19, 2nd paragraph: Stephen’s SecDir review[1] of 5245bis asked for a stronger statement about the application’s ability to control control which network interfaces are exposed in ICE candidates.. It may be that having such a statement in 5245bis is enough, but don’t be surprised if it comes up in IETF LC or IESG review. [1] https://mailarchive.ietf.org/arch/msg/ice/fyhuRfrMJqdnCJnE6MJ_0peMFsw |
2018-01-31
|
15 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
2018-01-24
|
15 | Ari Keränen | 1. Summary The document shepherd is Nils Ohlmeier. The responsible Area Director is Ben Campbell. This document extends the Interactive Connectivity Establishment (ICE) by adding … 1. Summary The document shepherd is Nils Ohlmeier. The responsible Area Director is Ben Campbell. This document extends the Interactive Connectivity Establishment (ICE) by adding an option to ICE agents to send and receive candidates incrementally rather than exchanging a complete list. The working group is confident that this document is correctly classified on the Standards Track. 2. Review and Consensus The extension is reasonably easy to add to an existing ICE implementation. Several independent implementations are deployed and are interoperable. Though the number of reviews during Working Group Last Call was low, the document received quite a few reviews over its lifetime. No formal reviews are needed. The shepherd has no remaining concerns. 3. Intellectual Property All authors have confirmed conformance with BCP 78 and 79. There are no IPR disclosures referencing this document. 4. Other Points Idnits points out three occurrences of 172.16.0.1 in the Appendix A section. As ICE is about NAT traversal it appears appropriate to leave this in a RFC1918 range and not use RFC 6890 addresses here. |
2018-01-24
|
15 | Ari Keränen | Responsible AD changed to Ben Campbell |
2018-01-24
|
15 | Ari Keränen | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2018-01-24
|
15 | Ari Keränen | IESG state changed to Publication Requested |
2018-01-24
|
15 | Ari Keränen | IESG process started in state Publication Requested |
2018-01-24
|
15 | Nils Ohlmeier | Changed document writeup |
2017-11-13
|
15 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-15.txt |
2017-11-13
|
15 | (System) | New version approved |
2017-11-13
|
15 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , ice-chairs@ietf.org, Eric Rescorla , Peter Saint-Andre |
2017-11-13
|
15 | Peter Saint-Andre | Uploaded new revision |
2017-09-11
|
14 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-14.txt |
2017-09-11
|
14 | (System) | New version approved |
2017-09-11
|
14 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , ice-chairs@ietf.org, Eric Rescorla , Peter Saint-Andre |
2017-09-11
|
14 | Peter Saint-Andre | Uploaded new revision |
2017-07-16
|
13 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-13.txt |
2017-07-16
|
13 | (System) | New version approved |
2017-07-16
|
13 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-07-16
|
13 | Peter Saint-Andre | Uploaded new revision |
2017-06-27
|
12 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-12.txt |
2017-06-27
|
12 | (System) | New version approved |
2017-06-27
|
12 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-06-27
|
12 | Peter Saint-Andre | Uploaded new revision |
2017-06-13
|
11 | Ari Keränen | Notification list changed to Nils Ohlmeier <nohlmeier@mozilla.com> |
2017-06-13
|
11 | Ari Keränen | Document shepherd changed to Nils Ohlmeier |
2017-05-25
|
11 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-11.txt |
2017-05-25
|
11 | (System) | New version approved |
2017-05-25
|
11 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-05-25
|
11 | Peter Saint-Andre | Uploaded new revision |
2017-05-09
|
10 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-10.txt |
2017-05-09
|
10 | (System) | New version approved |
2017-05-09
|
10 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-05-09
|
10 | Peter Saint-Andre | Uploaded new revision |
2017-04-23
|
09 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-09.txt |
2017-04-23
|
09 | (System) | New version approved |
2017-04-23
|
09 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-04-23
|
09 | Peter Saint-Andre | Uploaded new revision |
2017-03-27
|
08 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-08.txt |
2017-03-27
|
08 | (System) | New version approved |
2017-03-27
|
08 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-03-27
|
08 | Peter Saint-Andre | Uploaded new revision |
2017-02-27
|
07 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-07.txt |
2017-02-27
|
07 | (System) | New version approved |
2017-02-27
|
07 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-02-27
|
07 | Peter Saint-Andre | Uploaded new revision |
2017-02-22
|
06 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-06.txt |
2017-02-22
|
06 | (System) | New version approved |
2017-02-22
|
06 | (System) | Request for posting confirmation emailed to previous authors: Justin Uberti , Emil Ivov , Eric Rescorla , Peter Saint-Andre |
2017-02-22
|
06 | Peter Saint-Andre | Uploaded new revision |
2017-01-31
|
05 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-05.txt |
2017-01-31
|
05 | (System) | New version approved |
2017-01-31
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Eric Rescorla" , "Peter Saint-Andre" , "Justin Uberti" , "Emil Ivov" |
2017-01-31
|
05 | Peter Saint-Andre | Uploaded new revision |
2016-10-31
|
04 | Ari Keränen | Added to session: IETF-97: ice Mon-1330 |
2016-09-08
|
04 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-04.txt |
2016-07-20
|
03 | Emil Ivov | New version available: draft-ietf-ice-trickle-03.txt |
2016-06-06
|
02 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-02.txt |
2016-04-04
|
01 | Ari Keränen | Added to session: IETF-95: ice Thu-1400 |
2015-12-10
|
01 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-01.txt |
2015-10-19
|
00 | Ari Keränen | Intended Status changed to Proposed Standard from None |
2015-10-19
|
00 | Ari Keränen | This document now replaces draft-ietf-mmusic-trickle-ice instead of None |
2015-10-19
|
00 | Ari Keränen | Added suggested replacement relationships: draft-ietf-mmusic-trickle-ice |
2015-10-19
|
00 | Ari Keränen | This document now replaces None instead of None |
2015-10-19
|
00 | Peter Saint-Andre | New version available: draft-ietf-ice-trickle-00.txt |