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

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Mar 2018 13:59:42 -0700

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.

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?

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/

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?

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?

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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Mar 2018 15:36:13 -0600

Hi Ben, welcome to the IESG! :-)

> https://datatracker.ietf.org/doc/draft-ietf-ice-trickle/

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

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

>       not actively gathering candidates)

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

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

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

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Mar 2018 15:51:39 -0600

Correction inline!

> do we really want to? ;-)

Sorry, I mis-read your comment. By "not-more-than-once" I'm pretty sure
we meant "exactly-once" (I suppose the former includes not delivering
the data at all, but delivery is implied by the text "MUST deliver ...
not more than once" in §8). So this is an editorial matter, not a
technical matter as I see it. (It's the difference between exactly once
and at least once that I was thinking about.)

Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 29 Mar 2018 17:02:03 -0500

> Hi Ben, welcome to the IESG! :-)

Thanks :)

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

> (or ICE candidate exchange) MUST contain at least one candidate. Can you

(No, just the above note.)

> (e.g., offer/answer is another), and its methods are not forbidden by

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.

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

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

> do we really want to? ;-)

[other clarification followed, but for this situation it might
actually just be "kind-of want to"]

> 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 29 Mar 2018 17:15:45 -0600

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

It's possible this sentence referred to text in 5245bis that's now gone.
In particular, RFC 5245 was tied to the offer/answer model (RFC 3264)
but that is no longer the case and this seems like an offer/answer
stricture. In any case, we've tried to remove text from the trickle spec
that summarizes or duplicates or describes what 5245bis specifies, and
this seems like more text to remove.

> reviews of either until today.)  I will look at the diff from -17 to

Sorry about that. We received some late-ish feedback that needed to be
addressed.

> delayed updates from a previous session and detecting a desire to

Yes, this is handled by ICE agents by tracking which ICE session is in
force (through the combination of Username Fragment and Password). I'm
not sure it's all so subtle, though.

> actually just be "kind-of want to"]

Do you agree this a matter of phrasing, or do you have a technical concern?

> the document that we're hearing about any of these, so do as you

OK. I'll look at that order again (perhaps it makes sense to order them
by importance or difficulty).

Peter

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 31 Mar 2018 12:52:25 -0500

> this seems like more text to remove.

Okay.

> not sure it's all so subtle, though.

I think it's a question of do you only keep one ufrag+password as
state ("the current sesion"), or some level of history.  In the
former case, you can't tell between a delayed packet coming in from
an old session and a request to start a new one, IIUC.  So the
subtlety would be if there is actually a requirement to track more
history than just the current session.

> Do you agree this a matter of phrasing, or do you have a technical concern?

I do not have a technical concern with the text.

> by importance or difficulty).

Thanks!

-Benjamin