Re: [MMUSIC] Comments on draft-ietf-mmusic-trickle-ice-01

[Rajmohan Banavi <[e-mail]>]

I just saw that a new version of the trickle ice draft
- draft-ietf-mmusic-trickle-ice-02.txt is out. Have my earlier comments
below on the previous draft been taken care of?

Thanks,
Rajmohan

On Thu, Sep 18, 2014 at 12:03 PM, Rajmohan Banavi <[e-mail]>
wrote:

> Comments on draft-ietf-mmusic-trickle-ice-01
>
>
>    - "Sec 4 Determining Support for Trickle ICE" - "According to
>    [RFC5245] every time an agent supporting trickle ICE generates an offer or
>    an answer,".
>
> Need to be reworded as RFC 5245 has no idea of trickle
>
> "According to [RFC5245] every time an agent supporting an extension
> generates an offer or answer, it must include an identification token in
> the ice-options attribute. Accordingly, an agent supporting trickle ICE
> must include the "trickle" token in the ice-options attribute."
>
>
>    - Trivial typo in sec 1 Introduction.  "gathering, candidates" --->
>     "gathering candidates".
>
>
>
>    -  Sec 5 Paragraph 5: Fallback must be to Half Trickle rather than
>    vanilla ICE
>
> Prior to actually sending an initial offer, agents MAY verify if the
> remote party supports trickle ICE, where such mechanisms actually
>
> exist.  If absence of such support is confirmed agents MUST fall back
>
> to using vanilla ICE or abandon the entire session.
>
> If it is not possible to determine if the remote party support trickle
> ice, then the agent must make use of Half Trickle mechanism described in
> sec 4.1.
>
>
>    - Sec 8.1 "Check List and Timer State Updates" - there is something
>    wrong here in this paragraph. Why would a vanilla ICE agent set the state
>    of a check list to Failed if the pairs in the check list are in succeeded
>    state (bullet 1)? Further, it says that "if the following two conditions
>    are satisfied". Is it either one of the two conditions? Good idea to
>    provide a reference to RFC 5245 (sec 7.1.3.3), since we are describing the
>    operation of vanilla ICE.
>
>
>
>    - Trivial type. Sec 9.3 - "Announcing End of Candidates". Duplication
>    of sentence
>
>
>
>    - During implementation, one of the issues that surfaced was regarding
>    the check list timer. RFC 5245 Sec 5.8 "Scheduling Checks" mentions that if
>    there is no such pair, "Terminate the timer for that check list". This is
>    obviously not going to work with trickled ice candidates as the candidate
>    pairs list will keep filling up incrementally. So for trickled ice, the
>    conditions for stopping of the check list timer must be changed. Probably
>    the checklist timer must not be stopped until the checklist moves to
>    completed or Failed state.
>
>
> Cheers,
> Rajmohan
>
>