Re: [Ice] Benjamin Kaduk's Yes on draft-ietf-ice-trickle-18: (with COMMENT)

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

Hi Ben, welcome to the IESG! :-)

On 3/29/18 2:59 PM, Benjamin Kaduk wrote:
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ice-trickle-18: Yes
> 
> 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:
> ----------------------------------------------------------------------
> 
> Please consider using the RFC 8174 boilerplate to supplement RFC 2119.

My preferred solution is to scrub lowercase instances from the document,
which I will do in the next revision.

> Section 5 implies that plain ICE includes a provision for an ICE description
> with no candidates, but I'm failing to find that reference.  The rfc5245bis draft seems
> to always assume that there will be at least a host candidate.
> Is perhaps a different reference intended?

I see a few things in 5245bis, but perhaps I'm missing something...

§2.1

   At least one viable candidate has a transport address obtained
   directly from a local interface.  Such a candidate is called a host
   candidate.

§5.3

   ICE agents (initiating and responding) need the following information
   about candidates to be exchanged.  Each ICE usage MUST define how the
   information is exchanged with the using protocol.  This section
   describes the information that needs to be exchanged.

   Candidates:   One or more candidates.  For each candidate:

Also, §3 says:

   This document specifies generic use of ICE with protocols that
   provide means to exchange candidate information between the ICE
   agents.  The specific details of (i.e how to encode candidate
   information and the actual candidate exchange process) for different
   protocols using ICE (referred to as using protocol) are described in
   separate usage documents.

I'm not seeing anything in 5245bis specifying that an ICE description
(or ICE candidate exchange) MUST contain at least one candidate. Can you
point to the text?

IMHO Trickle ICE defines one way of completing the candidate exchange
(e.g., offer/answer is another), and its methods are not forbidden by
5245bis.

> In section 8.2:
> 
>    o  As a standalone notification (e.g., after STUN Binding requests or
>       TURN Allocate requests to a server time out and the agent has is
>       not actively gathering candidates)
> 
> s/has is/is/

That text is not in -18. I fear you might have reviewed -17? I published
-18 late yesterday. (Note that some section numbers changed, too.)

> Section 13 says that trickled candidate information may cause an ICE
> restart using the 5245bis semantics, but I don't see anywhere in
> 5245bis that would have additional candidate information induce a
> restart.  Is this the right reference?

5245bis states:

   To restart ICE, an agent MUST change both the password and the
   username fragment for the data stream(s) being restarted.

Such a change could be included when sending candidate information.

> Thanks for updating per the secdir review about the in-order requirement!
> However, we currently have language about transmitting candidates/end-of-candidates
> "not more than once", but we kind of do want exactly-once semantics for
> end-of-candidates, unless ICE terminates normally prior to that.
> Is there a good way to phrase that more clearly?

Not-more-than-once and exactly-once are indeed different things, with
the latter being more difficult to accomplish. Do we kind of want to
impose stricter requirements on implementations and using protocols, or
do we really want to? ;-)

> Maybe the last bullet of section 15 (must be able to send
> end-of-candidates) should come earlier in the list, in particular before the
> requirement for nonduplication and in-order.

That's an unordered list ('symbols' not 'numbers' in the XML). The
bullets are ordered by the appearance of those points in the text. I
have no particular allegiance to that order - but if you believe in the
serial-position effect then first or last is best. :-)

Thanks for the review!

Peter