Subject: [Ice] AD Evaluation of draft-ietf-ice-trickle-16

From: Ben Campbell <[email-masked]>
Date: Wed, 31 Jan 2018 23:31:51 -0600

Hi,

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.

Thanks!

Ben.

——————————————————

- 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 ([email-masked]) 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