Subject: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Mon, 02 Apr 2018 15:54:35 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-mmusic-trickle-ice-sip-14: 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-mmusic-trickle-ice-sip/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

   the Offer (as would be the case when Half Trickle is performed or
   when new candidates have not been learned since then).
IMPORTANT: They must be in order, right?

   'application/trickle-ice-sdpfrag' bodies do not interfere with the
   Offer/Answer procedures as specified in [RFC3264].
IMPORTANT: "pseudo" m= lines are not defined in 5888 so this is very unclear.

   sent under the same combination of "a=ice-pwd:" and "a=ice-ufrag:" in
   the same order as they were gathered.  In other words, the sequence
   of a previously sent list of candidates MUST NOT change in subsequent

IMPORTANT: This appears to conflict with the guidance in Section 6 of
the trickle document, which is about reordering candidates from how
they were gathered.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

  SIP message.  At the remote agent the gathering procedure is repeated
   and candidates are sent to the first agent.  Finally, a third phase
   starts where connectivity between all candidates in both sets is

This suggests that they have to happen in sequence, but that's not true.

   include in each "m="-line a "a=mid:" attribute in accordance to
   [RFC5888].

Why is this required?

   section 8.1.1 of [I-D.ietf-mmusic-ice-sip-sdp] except that an Answer
   is not yet provided.

Can you explain why you cease retransmitting on receiving INFO? I assume
because it's an implicit ACK of your INFO?

   m=lines that they pertain to.  The correspondence can be made via the
   "a=mid:" attributes.

This whole section needs to be rewritten to make clear what's going on:

    candidates are grouped in sections headed by "pseudo" m=lines
    These sections contain a=mid values which point back to the true m=line.

---

From: Thomas Stach <[email-masked]>
Date: Tue, 3 Apr 2018 20:46:05 +0200

EKR,

thanks for your comments, responses inline

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
I'm not sure what the issues is here.
The cited text addresses the first of two cases, i.e. the case where the 
INFO requests repeats
  the exact same set of candidates that was already provided in the 
initial offer.
This could happen when
a) Half Trickle is used (all candidate were already in the initial offer) or
b) Full Trickle is used where  the offerer is currently gathering 
additional candidates, but did not yet get them.

The second case (Full Trickle with additional candidates already 
available) is addressed in the subsequent paragraph.
.. and yes the candidates are sent in the order as they were gathered.
> IMPORTANT: "pseudo" m= lines are not defined in 5888 so this is very unclear.
5888 is cited as it defines the a=mid: attribute that we used for 
identifying the m-line to which a candidate belongs.
The a=mid: attribute helps in case of multiple m-lines, when we already 
have gathered candidates
for e.g. the first and fourth m-line, but not for the 2nd and 3rd.
> the trickle document, which is about reordering candidates from how

Do you mean section 7  which talks about reordering candidate _pairs_ at 
the IE agents?
We  require that the ordering of the _candidates_ MUST not change
when the candidates are sent several times from one  ICE agent to its 
peer in subsequent INFO requests.
I don't see a conflict.
As above, the a=mid: attribute helps in case of multiple m-lines, when 
we already have gathered candidates
for e.g. the first and fourth m-line, but not for the 2nd and 3rd.
> because it's an implicit ACK of your INFO?
The INFO is an ACK that an early dialog is now established, such that 
INFOs can be send in the reverse direction as well.
>      These sections contain a=mid values which point back to the true m=line.
Would it be sufficient to rephrase as follows?

Note, that there is no requirement that the Info request body
    contains as many pseudo m= lines as the Offer/Answer contains m=
    lines, nor that the pseudo m= lines be in the same order as the
    m=lines that they pertain to.  The correspondence can be made via the
    "a=mid:" attributes since candidates are grouped in sections headed by "pseudo" m=lines.
     These sections contain a=mid: attribute values which point back to the true m=line.

Kind regards
Thomas

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Apr 2018 06:57:24 -0700

On Tue, Apr 3, 2018 at 11:46 AM, Thomas Stach <[email-masked]>
wrote:

> The document, along with other ballot positions, can be found here:https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
>
>
>
>  the exact same set of candidates that was already provided in the initial
> offer.
> This could happen when

Right. I'm saying you need to say that.

> for e.g. the first and fourth m-line, but not for the 2nd and 3rd.

Right. You need to describe what a pseudo-m= line is because it's not
defined anywhere.

> Do you mean section 7  which talks about reordering candidate _pairs_ at

No. Section 16, sorry for the typo.

   To achieve this, when trickling candidates, agents MUST respect the
   order in which the components and streams appear (implicitly or
   explicitly) as they have been negotiated by means of the relevant
   candidate information.  Therefore candidates for a given component
   MUST NOT be conveyed prior to candidates for a component with a lower
   ID number within the same foundation.  In addition, candidates MUST
   be paired, following the procedures in Section 8.1.1, in the same
   order they are conveyed.

> when the candidates are sent several times from one  ICE agent to its peer
> in subsequent INFO requests.
>

The problem is the text "same order they were gathered" because the ICE
trickle text
requires sending them in an order different from when they were gathered.

I don't see a conflict.
> As above, the a=mid: attribute helps in case of multiple m-lines, when we
> already have gathered candidates

Right. You need to actually explain this.

> INFOs can be send in the reverse direction as well.

It would be helpful to explain this as well. I defer to the ART ADs on the
suitability of this technique.

>     These sections contain a=mid: attribute values which point back to the true m=line.
Sure.

---

From: Thomas Stach <[email-masked]>
Date: Thu, 5 Apr 2018 22:10:58 +0200

EKR,

On 2018-04-05 15:57, Eric Rescorla wrote:
>
>
> On Tue, Apr 3, 2018 at 11:46 AM, Thomas Stach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     EKR,
>
>>     Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
>>     <https://www.ietf.org/iesg/statement/discuss-criteria.html>
>>     <https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/>
>>
>>
>>
>     The cited text addresses the first of two cases, i.e. the case 
>     where the INFO requests repeats
OK, will do
>     The a=mid: attribute helps in case of multiple m-lines, when we
Well, we have this text in section 4.4 at the first occurrence of the term.

    "... this is handled through the use of pseudo "m=" lines
    and identification tags in "a=mid:" attributes as defined in
    [RFC5888 <https://tools.ietf.org/html/rfc5888>].  Pseudo "m=" lines follow the SDP syntax for "m=" lines as
    defined in [RFC4566 <https://tools.ietf.org/html/rfc4566>], but provide no semantics other than indicating
    to which "m=" line a candidate belongs. "

Isn't that good enough?
>     Do you mean section 7  which talks about reordering candidate
>     _pairs_ at the IE agents?
>
>
Section 15? :-)
>     when the candidates are sent several times from one  ICE agent to
>     its peer in subsequent INFO requests.
>
>
> The problem is the text "same order they were gathered" because the 
> ICE trickle text
OK, now I see. I will clarify and refer to section 15 of draft-ice-trickle
>     As above, the a=mid: attribute helps in case of multiple m-lines,
>     when we already have gathered candidates
I'll do
>     The INFO is an ACK that an early dialog is now established, such
>     that INFOs can be send in the reverse direction as well.
>
>
> It would be helpful to explain this as well. I defer to the ART ADs on 
> the suitability of this technique.
I'll do
>          These sections contain a=mid: attribute values which point back to the true m=line.
Thanks
Thomas

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 5 Apr 2018 13:27:18 -0700

>    to which "m=" line a candidate belongs. "

Not really. The way it reads is that pseudo m= lines are defines in 5888
but they're not. This is the
normative source of them. I would rephrase
"use of pseudo "m=" lines, which follow the SDP syntax of..." and then talk
about mid in the next
sentence.

-Ekr

---

From: Thomas Stach <[email-masked]>
Date: Sun, 8 Apr 2018 21:11:41 +0200

EKR,

On 2018-04-05 22:27, Eric Rescorla wrote:
>
>
> On Thu, Apr 5, 2018 at 1:10 PM, Thomas Stach <[email-masked] 
>>     On Tue, Apr 3, 2018 at 11:46 AM, Thomas Stach
>>     <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>         EKR,
>>
>>         The cited text addresses the first of two cases, i.e. the
>>         case  where the INFO requests repeats
>>          the exact same set of candidates that was already provided
>>         in the initial offer.
>>         This could happen when
>>         b) Full Trickle is used where  the offerer is currently
>>         gathering additional candidates, but did not yet get them.
>>
>>         The second case (Full Trickle with additional candidates
>>         already available) is addressed in the subsequent paragraph.
>>         5888 is cited as it defines the a=mid: attribute that we used
>>         for identifying the m-line to which a candidate belongs.
>>         The a=mid: attribute helps in case of multiple m-lines, when
>>     Right. You need to describe what a pseudo-m= line is because it's
>>     not defined anywhere.
> Not really. The way it reads is that pseudo m= lines are defines in 
> 5888 but they're not. This is the
> "use of pseudo "m=" lines, which follow the SDP syntax of..." and then 
> talk about mid in the next
> sentence.
I'll change to

"... this is handled through the use of pseudo "m=" lines.
     Pseudo "m=" lines follow the SDP syntax for "m=" lines as
    defined in [RFC4566 <https://tools.ietf.org/html/rfc4566>], but provide no semantics other than indicating
    to which "m=" line a candidate belongs.
    A pseudo  "m=" line is linked to the corresponding "m=" line in the
    SDP Offer or Answer via the identification tag in a "a=mid:" attribute as defined in [RFC5888 <https://tools.ietf.org/html/rfc5888>].
"

Kind Regards
Thomas

>>         when the candidates are sent several times from one  ICE
>>         agent to its peer in subsequent INFO requests.
>>
>>
>>     The problem is the text "same order they were gathered" because
>>     the ICE trickle text
>>         As above, the a=mid: attribute helps in case of multiple
>>         m-lines, when we already have gathered candidates
>>         The INFO is an ACK that an early dialog is now established,
>>         such that INFOs can be send in the reverse direction as well.
>>
>>
>>     It would be helpful to explain this as well. I defer to the ART
>>     ADs on the suitability of this technique.
>     I'll do
>>
>>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 8 Apr 2018 15:09:48 -0700

LGTM.

On Sun, Apr 8, 2018 at 12:11 PM, Thomas Stach <[email-masked]>
wrote:

>>> The cited text addresses the first of two cases, i.e. the case  where
>>> the INFO requests repeats