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

[Peter Saint-Andre <[e-mail]>]

The intent is to address your comments in -19, which will be submitted
as soon as the responsible AD tells me to.

On 4/4/18 4:14 PM, Eric Rescorla wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-ice-trickle-18: Recuse
> 
> 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:
> ----------------------------------------------------------------------
> 
> 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"
> 
>