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

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 1 Feb 2018 14:20:49 -0700

On 1/31/18 10:31 PM, Ben Campbell wrote:
> 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.

BTW, given that draft-ietf-ice-rfc5245bis and
draft-ietf-mmusic-trickle-ice-sip are already in IETF Last Call, I hope
that they will not be considered by the IESG apart from
draft-ietf-ice-trickle. Concurrent review will help ensure that the
specs are in sync.

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

OLD
   the initiator SHOULD generate and transmit their initial ICE
   description as early as possible, so that the remote party can start
   gathering and trickling candidates.

NEW
   the user experience is improved if the initiator generates and
   transmits their initial ICE description as early as possible (thus
   enabling the remote party to start gathering and trickling
   candidates).

> - 5, 2nd to last paragraph, last sentence: Should “fallback to
> [RFC3264]” be “fallback to non-ICE processing rules”?

Yes, that's better.

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

This would be better:

   Before conveying an end-of-candidates indication, either agent MAY
   convey subsequent candidate information at any time allowed by the
   signaling protocol in use.

> -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”?

Good catch. The term "component with a lower ID number" seems more
accurate than "earlier components". I suggest:

   Therefore candidates for a given component MUST NOT be conveyed prior
   to candidates for a component with a lower ID number within the same
   foundation.

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

s/MUST/would/g

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

Agreed.

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

Given that draft-ietf-ice-trickle merely provides a method for
communicating ICE candidates incrementally instead of all at once, it
seems to me that it does not have an impact on the permissions model
behind exposing ICE candidates in the first place; thus I expect that
the text being added to 5245bis is enough. But thanks for the heads-up.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 2 Feb 2018 14:54:23 -0700

Ben, if it's OK with you I will submit a revised I-D containing these fixes.

Peter

---

From: Ben Campbell <[email-masked]>
Date: Thu, 8 Feb 2018 15:47:44 -0600

Apologies for the delay in responding; it’s been a pretty crazy week.

Your responses look good to me; I will request IETF LC on version 16.

You recommended considering all of the ICE drafts together. The current plan is to consider ice-trickle and trickle-ice-sip together. I don’t want to delay 5245bis to accomplish that unless it’s absolutely necessary. The IESG will probably review 5245bis on the Feb 22 telechat, then the two trickle drafts on the next telechat—I think that ICE will still be fresh in people’s minds by then. Hopefully they will all be on a telechat prior to London.

Thanks!

Ben.

> On Feb 2, 2018, at 3:54 PM, Peter Saint-Andre <[email-masked]> wrote:
> 
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 8 Feb 2018 14:59:56 -0700

> Your responses look good to me; I will request IETF LC on version

Excellent.

> You recommended considering all of the ICE drafts together. The
> current plan is to consider ice-trickle and trickle-ice-sip together.
> I don’t want to delay 5245bis to accomplish that unless it’s
> absolutely necessary. The IESG will probably review 5245bis on the
> Feb 22 telechat, then the two trickle drafts on the next telechat—I
> think that ICE will still be fresh in people’s minds by then.
> Hopefully they will all be on a telechat prior to London.

That works! My concern about spreading them out too widely has been allayed.

Thanks, Ben.

Peter