Re: [Ice] Adam Roach's Discuss on draft-ietf-ice-trickle-18: (with DISCUSS and COMMENT)

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

Hi Adam, thanks for the review. Comments inline.

On 4/3/18 6:54 PM, Adam Roach wrote:
> Adam Roach has entered the following ballot position for
> draft-ietf-ice-trickle-18: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> This document is part of the multi-document problem I flag in my DISCUSS on
> draft-ietf-mmusic-trickle-ice-sip, and needs to block on finding a solution to
> that issue.
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This document appears to generally be in good shape. I have some fairly minor
> comments.
> 
> ---------------------------------------------------------------------------
> 
> §11:
> 
>>  signaling protocol in use.  When this happens, agents will use
>>  [rfc5245bis] semantics to determine whether or not the new candidate
>>  information require an ICE restart.
> 
> nit: "require"

Fixed in working copy.

> ---------------------------------------------------------------------------
> 
> §12:
> 
>> 12.  Unilateral Use of Trickle ICE (Half Trickle)
> 
> I find the use of the word "Unilateral" here to be confusing: the offering party
> indicates support, and the answering party takes advantage of that support. I
> would suggest using a different term ("Asymmetrical" maybe?); or, even more
> simply, just replacing the entire section title with "Half Trickle".

Just replacing is good.

> ---------------------------------------------------------------------------
> 
> §12:
> 
> The following passage indicates that the offer in a half-trickle situation might
> not contain a full generation of candidates:
> 
>>  The initial ICE
>>  description for half trickle would typically contain an end-of-
>>  candidates indication, although this is not mandatory because if
>>  trickle support is confirmed then the initiator can choose to trickle
>>  additional candidates before it conveys an end-of-candidates
>>  indication.
> 
> But then, two sentences later:
> 
>>  Because the initial ICE description contain a full
>>  generation of candidates...
> 
> ...which seems to contradict that indication.

Good catch. I suggest:


   In half trickle, the initiator conveys the initial ICE description
   with a usable (but not necessarily full) generation of candidates.
   This ensures that the ICE description can be processed by a regular
   ICE responder and is mostly meant for use in cases where support for
   Trickle ICE cannot be confirmed prior to conveying the initial ICE
   description.  The initial ICE description indicates support for
   Trickle ICE, so that the responder can respond with something less
   than a full generation of candidates and then trickle the rest.  The
   initial ICE description for half trickle can contain an
   end-of-candidates indication, although this is not mandatory because
   if trickle support is confirmed then the initiator can choose to
   trickle additional candidates before it conveys an end-of-candidates
   indication.

> (also, nit: "contains" rather than "contain")
> 
> ---------------------------------------------------------------------------
> 
> §15:
> 
>>    a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>>        raddr 2001:db8:a0b:12f0::1 rport 8998
>>    a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 5001 typ srflx
>>        raddr 2001:db8:a0b:12f0::1 rport 8998
> 
> [repeating a comment from draft-ietf-mmusic-trickle-ice-sip]
> 
> Thanks for the IPv6 example; however, I have a *lot* of heartburn with the
> selection of an example that demonstrates IPv6 NAT behavior. Since ICE's srflx
> behavior is fundamentally tied to IPv4 NATs (and should not be an issue with
> IPv6, as NATs are unnecessary), I think it's okay for the srflx examples to go
> ahead and show IPv4 addresses.
> 
> I *really* don't want to publish an RFC that demonstrates NATting of IPv6.

I feel your pain and would prefer IPv4 addresses here, too.

Peter