[Ice] Eric Rescorla's No Objection on draft-ietf-ice-trickle-18: (with COMMENT)

[Eric Rescorla <[e-mail]>]

Eric Rescorla has entered the following ballot position for
draft-ietf-ice-trickle-18: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/



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