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

[Benjamin Kaduk <[e-mail]>]

On Thu, Mar 29, 2018 at 03:36:13PM -0600, Peter Saint-Andre wrote:
> Hi Ben, welcome to the IESG! :-)

Thanks :)

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

Maybe this is what I'm thinking of.  (I appreciate the help
searching from someone more familiar with the space.)

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

(No, just the above note.)

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

I don't think I want to dispute your statement.  I'm looking at this
text:

   [...] Specifically,
   the rules from [rfc5245bis] would imply that ICE itself is not
   supported if the initial ICE description includes no candidates;
   however, such a conclusion is not warranted if the responder can
   confirm that the initiator supports Trickle ICE,

and need help figuring out what part of 5245bis is intended as the
reference.

> > 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.)

I did review the -17, yes.  (I had this and the sip profile open
simultaneously since yesterday to cross-reference, but didn't submit
reviews of either until today.)  I will look at the diff from -17 to
-18 after I send this.

> > 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 the clarification.  There is perhaps some subtle
state-keeping requirement on implementations, then, as section 8 (of
-18) notes:

   Also, candidate trickling needs to be correlated to a specific ICE
   session, so that if there is an ICE restart, any delayed updates for
   a previous session can be recognized as such and ignored by the
   receiving party.

In that one needs to keep state in order to tell between ignoring
delayed updates from a previous session and detecting a desire to
start a new session.


> > 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? ;-)

[other clarification followed, but for this situation it might
actually just be "kind-of 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. :-)

I was just going off the principle that concepts should be
(re)introduced before they are (re)used, not any particular sense of
ordering or priority.  And it's not like this is the first time in
the document that we're hearing about any of these, so do as you
want :)

> Thanks for the review!

You're welcome!

-Benjamin