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

From: Adam Roach <[email-masked]>
Date: Tue, 03 Apr 2018 00:29:53 -0700

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

Thanks to everyone who worked on this document. I have a couple of concerns that
need to be cleared up before the document can move forward.

---------------------------------------------------------------------------

§4.3.4 discusses the interaction of 3PCC with the trickle ICE mechanism.
Unfortunately, the diagrams used in this section do not show a 3PCC signaling
flow; they show a two-party call flow with an offerless INVITE. A 3PCC call flow
would necessarily involve a 3PCC controller sending an offerless INVITE to one
party, receiving an offer from that party (typically in a reliable provisional
response or in a 200 OK), and then sending an INVITE to the other party
containing that offer.

The text in this section matches the diagrams, and consequently does not appear
to be an analysis of 3PCC behavior. It is an analysis of two-party offerless
INVITE behavior.

If this section remains, it needs to be substantially re-worked: the diagrams
need to show three parties, with a 3PCC controller performing the controlling
role as described in RFC 3725. While I haven't stepped through the implications
for Trickle ICE when a controller is actually involved and is moving offers and
answers around between different message types, I suspect that the analysis in
here is substantially different once this starts happening.

I would personally be okay if the entire section were removed; however, I
have no desire to override working group consensus regarding the value of a
section dealing with 3PCC considerations.

---------------------------------------------------------------------------

The second issue doesn't necessarily pertain to this document per se as much
as it does the interaction among this document, draft-ietf-ice-trickle (Trickle
ICE), draft-ietf-mmusic-ice-sip-sdp (ICE SDP), and draft-ietf-rtcweb-jsep
(JSEP). The problem doesn't lie with any single document, but in the overall
result of how they're currently structured.

JSEP (in the RFC editor queue) refers to the "a=end-of-candidates" SDP attribute
as appearing in Trickle ICE, section 9.3, which was true at one point in time.
Somewhere along the line, this attribute's definition was moved from there
into this document.

There are several ways to fix this, each with their own drawbacks:

1. Move the SDP syntax for "a=end-of-candidates" back into the Trickle ICE
   draft. Drawback: Trickle ICE does not currently define any normative SDP
   behavior; and, in fact, could work in a system that doesn't use SDP at all.

2. Move the SDP syntax into the ICE SDP draft. This is pretty elegant from the
   perspective that ICE SDP defines SDP syntax for ICE in general (for both
   SIP and JSEP), and such a move aggregates all of the SDP syntax into a
   single document that is already necessary to reference from any document
   that uses SDP for Trickle ICE. Drawback: the document doesn't presently
   discuss Trickle ICE at all, and this would require a somewhat awkward
   section that basically says "If you use [Trickle ICE] with SDP, the syntax
   for the end-of-candidate marker is..."

3. Change JSEP to normatively depend on this document for the
   "a=end-of-candidates" syntax. Drawback: This document is extremely
   SIP-specific, while JSEP is based solely on RFC 4566 syntax and RFC 3264
   behavior, independent of any SIP semantics.  Forcing JSEP to normatively
   depend on a SIP specific document for a simple attribute syntax definition
   seems to be letting the tail wag the dog.

I believe that #2 is the least inelegant option, but I'm open to #1 and #3.
However, The *current* situation -- in which JSEP normatively points to a
document from which the text is cites has been removed out from under it -- is
clearly wrong.

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

§4.1.4:

>  If the initial Answer included the attribute a=ice-options:trickle,
>  the Offerer MUST be prepared for receiving trickled candidates later
>  on.

I don't think this makes sense. If the initial *Offer* includes that option,
then the Offerer must be prepared to receive trickled candidates, even before
the Answer arrives. Figure 6 shows an example of this. I believe that the
paragraph I quote above needs to be entirely removed, as it may lead
implementors to incorrectly assume that they can't get trickled candidates prior
to an Answer.

---------------------------------------------------------------------------

§4.3:

>    o  The dialog at both peers MUST be in early or confirmed state.

This makes no sense. Dialogs exist in precisely two states, ever: early or
confirmed. Prior to "early," they don't exist. The only exit from "confirmed" is
destruction. (See RFC 3261 §12).

I think what this means to say is "A dialog MUST have been created between the
peers."

---------------------------------------------------------------------------

§4.3.2:

>  These retransmissions MUST
>  cease on receipt of an INFO request carrying a 'trickle-ice' Info
>  Package body or on transmission of the Answer in a 2xx response.

Why does this require that specific INFO to stop retransmission? The only
requirement is that the answerer knows that the offerer has received the
provisional response. The offerer cannot send post-INVITE requests to the
answerer until a dialog is established, and the only ways a dialog can be
established at the offerer is receipt of a provisional or final response. So, as
soon as you get *any* request from the offerer, you know that the provisional
response has arrived.

I think this passage means to say "These retransmissions MUST cease on receipt
of any in-dialog request from the offerer. The offerer cannot send in-dialog
requests until it receives a response, so the arrival of such a request proves
that the response has arrived."

---------------------------------------------------------------------------

§4.3.2:

>  The Offerer MUST send a Trickle ICE INFO request as soon as it
>  receives an SDP Answer in an unreliable provisional response.  This
>  INFO request MUST repeat the candidates that were already provided in
>  the Offer (as would be the case when Half Trickle is performed or
>  when new candidates have not been learned since then).

It is probably worth mentioning that it's possible that this INFO contains no
candidates, depending on how the offerer gathers its candidates and how long it
takes to do so.

---------------------------------------------------------------------------

§4.3.3:

>  These retransmissions MUST cease on receipt
>  of an INFO request or on transmission of the Answer in a 2xx
>  response.

Same comment as above for §4.3.2.

---------------------------------------------------------------------------

§4.3.4:

>  As specified in Section 4 this offerless INVITE
>  MUST include the SIP option-tag 'trickle-ice' in a SIP Supported:
>  header field in order to indicate support for Trickle-ICE to the
>  Offerer (at the User Agent Server (UAS)).

How does the 3PCC controller know to include this option tag? Is it simply
indicating that the 3PCC controller supports the Trickle mechanism? If so,
what happens if the second party (the one who receives the offer in an INVITE)
doesn't support Trickle ICE? This is one of the sharper corner cases that I
think arises when you go to fix the analysis I describe in my DISCUSS above.

---------------------------------------------------------------------------

§4.4:

>     a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 5000 typ srflx
>         raddr 2001:db8:a0b:12f0::1 rport 8998

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 srvflx examples to go
ahead and show IPv4 addresses.

I *really* don't want to publish an RFC that demonstrates NATting of IPv6.

---------------------------------------------------------------------------

§4.4:

>  An "a=end-of-candidates" attribute, preceding any pseudo "m=" line,
>  indicates the end of all trickling from that agent, as opposed to end
>  of trickling for a specific "m=" line, which would be indicated by a
>  media level "a=end-of-candidates" attribute.

I finally did figure out what this meant, but it's confusing. The use of "any"
in the phrase "any pseudo 'm=' line" implies that the following sdpfrag would
qualify:

      a=ice-pwd:asd88fgpdd777uzjYhagZg
      a=ice-ufrag:8hhY
      m=audio 9 RTP/AVP 0
      a=mid:1
      a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 5000 typ host
      a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 5001 typ host
      a=end-of-candidates
      m=audio 9 RTP/AVP 0
      a=mid:2
      a=candidate:1 1 UDP 2130706431 2001:db8:a0b:12f0::1 6000 typ host
      a=candidate:1 2 UDP 2130706431 2001:db8:a0b:12f0::1 6001 typ host

The end-of-candidates *does* appear before the second pseudo "m=" line, which is
one of the lines (thereby satisfying the "any" criteria).

I think you mean "preceding the first pseudo 'm=' line..."

This is true later in the section also:

>  will not send any further candidates.  When included at session
>  level, i.e. before any pseudo "m=" line, this indication applies to

---------------------------------------------------------------------------

§4.4:

>  Note: At the time of writing this specification there were ongoing
>  discussions if a functionality for removing already exchanged
>  candidates would be useful.  Such a functionality is out of the scope
>  of this specification and most likely needs to be signaled by means
>  of a yet to be defined ICE extension, although it could in principle
>  be achieved quite easily, e.g. without anticipating any solution by
>  simply omitting a previously sent candidate from a subsequent INFO
>  request.  However, if an implementation according to this
>  specification receives such an INFO request with a missing candidate
>  it would have to treat that as an exceptional case.  Implementing
>  appropriate recovery procedures at the receiving side is advisable
>  for this situation.  Ignoring that a candidate was missing might be a
>  sensible strategy.

This seems like an interop nightmare. If you want a note about this possibly
being included in the future, please simply indicate that such an ability will
need to be explicitly signaled. Don't imply that implementations might get SDP
that violates the behavior defined in this document in some ill-defined way,
and just need to kind of gracefully deal with it, even if we don't really know
what it means at this point in time. There's no sensible way to code for that.

---------------------------------------------------------------------------

§4.4:

>     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
...
>     a=candidate:2 1 UDP 1694498815 2001:db8:a0b:12f0::3 6000 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 9998
>     a=candidate:2 2 UDP 1694498815 2001:db8:a0b:12f0::3 6001 typ srflx
>        raddr 2001:db8:a0b:12f0::1 rport 9998

Same comment as above regarding IPv6 and NATs. Note that it would be Good and
Helpful to show SDP with a mixture of IPv4 and IPv6 anyway.

---------------------------------------------------------------------------

§5:

>  SIP User Agents (UAs) that support and intend to use trickle ICE are
>  required by [I-D.ietf-ice-trickle] to indicate that in their Offers
>  and Answers using the attribute "a=ice-options:trickle" and MUST
>  include the SIP option-tag "trickle-ice" in a SIP Supported: header
>  field.

Is this intended to imply that the option tag cannot be used in a Require header
field? I don't think that's a good idea; however, if that is the working group's
intention, please say so explicitly.

Suggest "...in a SIP 'Supported' or 'Require' header field."

---------------------------------------------------------------------------

§5.1:

This section discusses behavior in a walled garden. I'm generally fine with
this, as long as the failure modes when someone starts adding doors to the
walled garden are well-defined. I don't think this kind of provisioning is
okay unless it has a requirement that Offerers assuming Trickle ICE support
MUST include a "Require: trickle-ice" header field. That way, if the
provisioned assumption of Trickle ICE support ends up being incorrect, the
failure is (a) operationally easy to track down, and (b) recoverable by the
client (i.e.: they can re-send the request without the "Require" header field
and without the assumption of Trickle ICE support).

---------------------------------------------------------------------------

§6:

>  This INFO request indicates that the Answerer supports and uses RTP
>  and RTCP multiplexing as well.  It allows the Offerer to omit
>  gathering of RTCP candidates or releasing already gathered RTCP
>  candidates.

It's not clear how this "releasing already gathered RTCP candidates" interacts
with the requirement in §4.4:

>  In other words, the sequence
>  of a previously sent list of candidates MUST NOT change in subsequent
>  INFO requests and newly gathered candidates MUST be added at the end
>  of that list.

So, if I had already trickled candidates for the RTCP component of a connection
and *then* got an INFO from the Answerer indicating that it supports
multiplexing, does that mean I free the resources and exclude them from future
INFO messages? That seems to contravene the §4.4 requirement. Or do I free them
but continue to include them? I suppose that's okay (maybe?), but it's
extremely counterintuitive, and would need to be called out explicitly if you
expect implementors to get it right.

---------------------------------------------------------------------------

§7:

>  A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute
>  [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle-
>  ice-sdpfrag body if it supports and uses bundling.

This needs to clearly indicate that this needs to be included at the session
level (rather than the media level).

---------------------------------------------------------------------------

§7:

>  The Offerer can use this information e.g. for stopping the gathering
>  of candidates for the remaining "m=" lines in a bundle and/or for
>  freeing corresponding resources.

Same comment as for §6, above (regarding interaction with the requirement from
§4.4)

---------------------------------------------------------------------------

§7:

>      a=group:BUNDLE foo bar
>      a=ice-pwd:asd88fgpdd777uzjYhagZg
>      a=ice-ufrag:8hhY
>      m=audio 9 RTP/AVP 0
>      a=mid:foo
>      a=rtcp-mux
>      a=candidate:1 1 UDP 1658497328 2001:db8:a0b:12f0::3 5000 typ host
>      m=audio 9 RTP/AVP 0
>      a=mid:bar

The presence of the second m= line here is confusing, given the following text
from §4.4:

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

The §4.4 text strongly implies that it is nonsensical to include an m= section
without candidates. Is the example in §7 intended to imply that the section
needs to be included because its mid is mentioned in the "a=group:BUNDLE" line?
If so, please say so. If not, please remove the second m= section.

---------------------------------------------------------------------------

§9.2:

The syntax for "session-level-fields", "pseudo-media-descriptions", and
"trickle-ice-attribute-fields" include extremely strict rules around ordering of
fields (e.g., including ice-ufrag before ice-pwd would be syntactically
invalid). That level of strictness seems unlikely to lead to interoperable
implementations.

If the intention is to be rigid in this fashion, please add prominent prose
that warns implementors that fields MUST appear in the order specified, and
that all other orders are invalid and MUST be rejected.

If that's *not* your intention (and I suspect it isn't), then please fix the
syntax definition to allow for arbitrary ordering of attributes in the same way
as SDP does. For example:

    session-level-fields = *(session-level-field CRLF)

    session-level-field = bundle-group-attribute /
                          ice-lite-attribute /
                          ice-pwd-attribute /
                          ice-ufrag-attribute /
                          ice-options-attribute /
                          ice-pacing-attribute /
                          end-of-candidates-attribute /
                          extension-attribute-fields
                                 ; for future extensions

---------------------------------------------------------------------------

§9.2:

The syntax for "session-level-fields" implies that "ice-pwd" and "ice-ufrag" are
mandatory at the session level. This seems to conflict with the text in §4.4:

>  The "a=ice-pwd:" and "a=ice-ufrag:" attributes MUST appear at the
>  same level as the ones in the Offer/Answer exchange.  In other words,
>  if they were present as session-level attributes, they will also
>  appear at the beginning of all INFO request payloads, i.e. preceding
>  all pseudo "m=" lines.  If they were originally exchanged as media
>  level attributes, potentially overriding session-level values, then
>  they will also be included in INFO request payloads following the
>  corresponding pseudo "m=" lines.

The fix I propose above removes this implication that such attributes are
mandatory at the session level; however, if you choose to fix it some other way,
please ensure that the ABNF does not conflict with the normative language I
quote above.

---------------------------------------------------------------------------

§10.6:

Same comment as for §5 above.

---------------------------------------------------------------------------

§10.9:

>  If the INFO requests are sent on top of TCP, which is probably the
>  standard way, this is not an issue for the network anymore, but it
>  can remain one for SIP proxies and other intermediaries forwarding
>  the SIP INFO messages.  Also, an endpoint may not be able to tell
>  that it has congestion controlled transport all the way.

This seems kind of blithe about congestion control, as it concedes that the INFO
requests might end up on UDP at some point. Minimally, I would think that you
want to require some minimum quarantine period between INFO requests (probably
something in the range of 20 ms), during which any new candidates that are
gathered are aggregated into the next INFO message.

===========================================================================

Nits:

Expand "ICE" in the title.

---------------------------------------------------------------------------

draft-ietf-mmusic-ice-sip-sdp has undergone a major restructuring since version
16; as a consequence, all notes of the form:

>  [RFC EDITOR NOTE: The section 4.2.1.2.1 in above sentence is correct
>  for version 16 of said I-D.  Authors need to cross-check during
>  Auth48 since it could have have changed in the meantime.]

...are already out of date. It's probably worthwhile to fix these now, as they
are (in my opinion) quite unlikely to change again; and the current misdirection
makes it somewhat difficult to use the draft in its current form.

---------------------------------------------------------------------------

§4.1.3:

>  If the Answerer includes candidates in its initial Answerer, it MUST

"...initial Answer..."

---------------------------------------------------------------------------

§7:

>  A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute

Remove the space before "BUNDLE"

---------------------------------------------------------------------------

§11:

>  Trickle ICE uses two mechanism for exchange of candidate information.

"mechanisms"

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 3 Apr 2018 09:25:52 -0500

For what it's worth ...

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

I THOUGHT that was wrong!

Thanks for being smart enough to ask about it ...

Spencer

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 3 Apr 2018 10:22:39 -0600

+ ICE WG to address the cross-document DISCUSS only.

On 4/3/18 1:29 AM, Adam Roach wrote:

<snip/>

> document from which the text is cites has been removed out from under it -- is

IMHO the ICE WG had consensus to remove all normative SDP references
from draft-ietf-ice-trickle and place them in
draft-ietf-mmusic-trickle-ice-sip. Does it really matter what kind of
document JSEP points to, as long as the "a=end-of-candidates" definition
can be found there?

Peter

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 11:42:15 -0500

Comment on first discuss point:

> On Apr 3, 2018, at 2:29 AM, Adam Roach <[email-masked]> wrote:
> 

I suspect (and assumed while reading this) is that the consideration that matters is the offer/answer exchange with a delayed offer. It calls it a 3PCC consideration because 3PCC uses it. I doubt people had in mind to fully specify 3PCC. If the WG agrees that is the case, would it make sense to re-label the section as “delayed offer considerations”, and merely mention that 3PCC uses that technique?

[…]

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 11:55:27 -0500

> On Apr 3, 2018, at 11:22 AM, Peter Saint-Andre <[email-masked]> wrote:
> 

I was working on a comment to the same effect when I saw Peter’s.

I see Adam’s option 1 as a non-starter since it explicitly reverses that consensus. I see 2 and 3 to be equally awkward, in which case 3 requires the least amount of structural change. If there was an option that required no change to jsep at all(since it is currently with the RFC editor), but IIUC, none of the choices allow for that.

Thanks!

Ben.

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Apr 2018 12:17:37 -0500

> I suspect (and assumed while reading this) is that the consideration that matters is the offer/answer exchange with a delayed offer. It calls it a 3PCC consideration because 3PCC uses it. I doubt p…

I'm not sure how useful that is, as it's not entirely clear that Trickle 

> think arises when you go to fix the analysis I describe in my DISCUSS above.

Absent 3PCC, the "early offer" case is not interesting. Aside from 3PCC, 
its only purpose is interop with a version of H.323 that was obsoleted 
in 1998.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Apr 2018 12:24:18 -0500

+rtcweb. This is a three-WG situation, and I suspect rtcweb participants 
have an opinion on the topic.

/a

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 12:26:24 -0500

> On Apr 3, 2018, at 12:17 PM, Adam Roach <[email-masked]> wrote:
> 
> I'm not sure how useful that is, as it's not entirely clear that Trickle ICE works with 3PCC at all -- see, for example, my later comment:

I’d also be perfectly happy to remove it, if the WG agrees. If someone cares, they can write a separate draft :-)

> Absent 3PCC, the "early offer" case is not interesting. Aside from 3PCC, its only purpose is interop with a version of H.323 that was obsoleted in 1998.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Apr 2018 10:26:39 -0700

On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach <[email-masked]> wrote:

>> I see Adam’s option 1 as a non-starter since it explicitly reverses that
>> consensus. I see 2 and 3 to be equally awkward, in which case 3 requires
>> the least amount of structural change. If there was an option that required
>> no change to jsep at all(since it is currently with the RFC editor), but
>> IIUC, none of the choices allow for that.
>>
>
I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on
SIP. If you think #2 and #3 are equally awkward, lets do #2.

-Ekr

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 12:35:52 -0500

> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies on SIP. If you think #2 and #3 are equally awkward, lets do #2.
> 

I said they are equally awkward (by which I mean equally awkward for readers after publication), but 3 requires fewer changes (that is, less effort.).

If we want to go for least awkward, that probably means a separate trickle-ice-sdp draft in parallel to the ice sdp draft. But that’s the past of most effort.

But honestly, I think this is the sort of point that we should defer to WG consensus.

Ben.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Apr 2018 13:38:39 -0400

> SIP. If you think #2 and #3 are equally awkward, lets do #2.
Do you want to move all other trickle ICE specific SDP related changes from
 draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp?

It is not just end-of-candidates, but also support for c=0.0.0.0 in offers,
SDP offers without the candidates, different mismatch rules. As it stands,
draft-ietf-mmusic-trickle-ice-sip changes how
draft-ietf-mmusic-ice-sip-sdp works
when trickle ICE is used.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Apr 2018 10:43:01 -0700

On Tue, Apr 3, 2018 at 10:38 AM, Roman Shpount <[email-masked]> wrote:

>>>> I see Adam’s option 1 as a non-starter since it explicitly reverses
>>>> that consensus. I see 2 and 3 to be equally awkward, in which case 3
>>>> requires the least amount of structural change. If there was an option that
>>>> required no change to jsep at all(since it is currently with the RFC
>>>> editor), but IIUC, none of the choices allow for that.
>>>>
>>>
> Do you want to move all other trickle ICE specific SDP related changes
> from  draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp?
>
> It is not just end-of-candidates, but also support for c=0.0.0.0 in
> offers, SDP offers without the candidates, different mismatch rules. As it
> stands,  draft-ietf-mmusic-trickle-ice-sip changes how
> draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used.
>

I want to do whatever is necessary to remove the normative dependency from
JSEP to SIP

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Apr 2018 10:43:58 -0700

On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <[email-masked]> wrote:

> I said they are equally awkward (by which I mean equally awkward for
> readers after publication), but 3 requires fewer changes (that is, less
> effort.).
>
> If we want to go for least awkward, that probably means a separate
> trickle-ice-sdp draft in parallel to the ice sdp draft. But that’s the past
> of most effort.
>

Which WG? As I understand it, this would require a change to JSEP, which
would also require WG consensus, plus a change to an IESG-approved document.

-Ekr

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Apr 2018 12:48:21 -0500

On 4/3/18 12:38 PM, Roman Shpount wrote:
> offers, SDP offers without the candidates, different mismatch rules. 
> As it stands, draft-ietf-mmusic-trickle-ice-sip changes how 

To be clear, the other changes you cite are specific to SIP, as 
evidenced by the fact that JSEP does not need to make use of them. I 
don't see a major problem with moving them (other than it being 
make-work), but I also don't see any value in doing so.

/a

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 12:49:34 -0500

> On Apr 3, 2018, at 12:43 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> Do you want to move all other trickle ICE specific SDP related changes from  draft-ietf-mmusic-trickle-ice-sip to draft-ietf-mmusic-ice-sip-sdp?
> 
> It is not just end-of-candidates, but also support for c=0.0.0.0 in offers, SDP offers without the candidates, different mismatch rules. As it stands,  draft-ietf-mmusic-trickle-ice-sip changes how draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used.
> 
> I want to do whatever is necessary to remove the normative dependency from JSEP to SIP

We do references to “section XXX of RFC YYYY” all the time to refer to specific points in an RFC of larger scope. I agree it’s not ideal, but “not done” is also not ideal.

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 12:54:19 -0500

> Which WG? As I understand it, this would require a change to JSEP, which would also require WG consensus, plus a change to an IESG-approved document.

I mean consensus of the WGs producing the documents. it’s quite reasonable for a dependent WG to offer feedback, but I don’t think a dependent WG gets to just override that consensus.

Ben.

---

From: Roman Shpount <[email-masked]>
Date: Tue, 3 Apr 2018 14:00:34 -0400

On Tue, Apr 3, 2018 at 1:48 PM, Adam Roach <[email-masked]> wrote:

> To be clear, the other changes you cite are specific to SIP, as evidenced
> by the fact that JSEP does not need to make use of them. I don't see a
> major problem with moving them (other than it being make-work), but I also
> don't see any value in doing so.
>

All the things I have referenced are being used by JSEP.

For instance current in draft-ietf-rtcweb-jsep-24 (
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.2.1):

If the m= section is marked as bundle-only, then the port value MUST be set
to 0.  Otherwise, the port value is set to the port of the default ICE
candidate for this m= section, but given that no candidates are available
yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in
[I-D.ietf-ice-trickle], Section 5.1.

I am fairly sure this is no longer in ietf-ice-trickle  and was moved to
draft-ietf-mmusic-trickle-ice-sip (
https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-14#section-4.1.1
).

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Apr 2018 13:03:28 -0500

> I mean consensus of the WGs producing the documents. it’s quite reasonable for a dependent WG to offer feedback, but I don’t think a dependent WG gets to just override that consensus.

I don't think it's as clean cut as that. JSEP could have defined the 
"a=end-of-candidates" syntax, and certainly would have if MMUSIC and ICE 
had pulled it out of their documents. But I don't think we want both 
documents independently registering identical syntaxes with identical 
meanings, right? Or I suppose JSEP could have decided -- having finished 
first -- that they should define the syntax and have the trickle-ice-sip 
document reference JSEP?

I'm offering those up as examples, not proposals. I think the first is a 
nonstarter, and the second is... well, it's as awkward as what you're 
proposing.

I'm beginning to think we need to to take the question to ART rather 
than the three working groups.

/a

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 03 Apr 2018 18:21:59 +0000

Adding a data point

Icebis doesn’t talk about trickle ice and hence ice-sip-SDP doesn’t either.

In the same context, would ice trickle and ice-trickle-sip-SDP focussing on
trickle ice only procedures and usages makes sense ?

Does that work ?

On Tue, Apr 3, 2018 at 11:04 AM Adam Roach <[email-masked]> wrote:

> >>> I don't think #3 is acceptable. AFAIK JSEP has no other dependencies
> on SIP. If you think #2 and #3 are equally awkward, lets do #2.
> >>>
> >> Which WG? As I understand it, this would require a change to JSEP,
> which would also require WG consensus, plus a change to an IESG-approved
> document.
> >
> > I mean consensus of the WGs producing the documents. it’s quite
> reasonable for a dependent WG to offer feedback, but I don’t think a
> dependent WG gets to just override that consensus.
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 03 Apr 2018 18:27:58 +0000

Just to complete, ice-bis doesn’t normatively reference ice-sip-SDP draft
when it moved to using “usages “ indirections for signaling protocols.

Trickle ice can use similar approach and refer to trickle-sip as usage for
trickle.

Thanks
Suhas

On Tue, Apr 3, 2018 at 11:21 AM Suhas Nandakumar <[email-masked]>
wrote:

> In the same context, would ice trickle and ice-trickle-sip-SDP focussing
> on trickle ice only procedures and usages makes sense ?
>
>
> Does that work ?
>
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 3 Apr 2018 13:28:56 -0500

Like I said originally, none of these are particularly clean. Your 
proposal points towards either #1 or #3, and I highlighted their 
drawbacks in my original message.

Fundamentally, the suggestion Ben made is the only clean one: split 
trickle-ice-sip into two documents: one deals with SIP (think a parallel 
to RFC 3261) while the other deals with SDP (think a parallel to RFC 
3264). But I also agree with him that sending the document back to the 
WG for such a split would introduce a significant amount of work.

Absent that, we need to pick which wart we're going to accept.

/a

On 4/3/18 1:21 PM, Suhas Nandakumar wrote:
> In the same context, would ice trickle and ice-trickle-sip-SDP 
> focussing on trickle ice only procedures and usages makes sense ?
>
>
> Does that work ?
>
>
> On Tue, Apr 3, 2018 at 11:04 AM Adam Roach <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     >> On Apr 3, 2018, at 12:43 PM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >>
>     >> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>
>     >>
>     >>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     >>>
>     >>> I don't think #3 is acceptable. AFAIK JSEP has no other
>     dependencies on SIP. If you think #2 and #3 are equally awkward,
>     lets do #2.
>     >>>
>     >> I said they are equally awkward (by which I mean equally
>     awkward for readers after publication), but 3 requires fewer
>     changes (that is, less effort.).
>     >>
>     >> If we want to go for least awkward, that probably means a
>     separate trickle-ice-sdp draft in parallel to the ice sdp draft.
>     But that’s the past of most effort.
>     >>
>     >> Which WG? As I understand it, this would require a change to
>     JSEP, which would also require WG consensus, plus a change to an
>     IESG-approved document.
>     >
>     reasonable for a dependent WG to offer feedback, but I don’t think
>     a dependent WG gets to just override that consensus.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Apr 2018 18:39:50 +0000

Hi,

> I don't think it's as clean cut as that. JSEP could have defined the "a=end-of-candidates" syntax, and certainly 
> would have if MMUSIC and ICE had pulled it out of their documents. But I don't think we want both documents 
> independently registering identical syntaxes with identical meanings, right? Or I suppose JSEP could have decided 
> -- having finished first -- that they should define the syntax and have the trickle-ice-sip document reference JSEP?
>
> I'm offering those up as examples, not proposals. I think the first is a nonstarter, and the second is... well, it's as 
> awkward as what you're proposing.

Having trickle-ice-sip referencing JSEP, just for the attribute, would be even more awkward in my opinion :) 

In addition, we would also have to add the generic O/A procedures for the attribute to JSEP.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Apr 2018 18:43:09 +0000

Hi,

>Like I said originally, none of these are particularly clean. Your proposal points towards either #1 or #3, and
>I highlighted their drawbacks in my original message.
>
>Fundamentally, the suggestion Ben made is the only clean one: split trickle-ice-sip into two documents: one deals with SIP (think a parallel to RFC 3261) >while the other deals with SDP (think a parallel to RFC 3264). But I also agree with him that sending the document back to the WG for such a split would >introduce a significant amount of work.

Not exactly sure what “deals with SDP” would mean, but one idea would be to ONLY define the attribute, and the associated O/A procedures, in a separate draft, that would be referenced by draft-ietf-mmusic-trickle-ice-sip and JSEP.

Regards,

Christer

In the same context, would ice trickle and ice-trickle-sip-SDP focussing on trickle ice only procedures and usages makes sense ?

Does that work ?

On Tue, Apr 3, 2018 at 11:04 AM Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:
On 4/3/18 12:54 PM, Ben Campbell wrote:
>
>> On Apr 3, 2018, at 12:43 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>
>> On Tue, Apr 3, 2018 at 10:35 AM, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>
>>> On Apr 3, 2018, at 12:26 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
>>>

/a

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 3 Apr 2018 13:20:08 -0600

On 4/3/18 12:27 PM, Suhas Nandakumar wrote:
> Just to complete, ice-bis doesn’t normatively reference ice-sip-SDP
> draft when it moved to using “usages “ indirections for signaling protocols.
> 
> 
> Trickle ice can use similar approach and refer to trickle-sip as usage
> for trickle.

It already does. That's why we pulled all the SDP/SIP stuff out of
draft-ietf-ice-trickle.

Peter

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 14:22:07 -0500

> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre <[email-masked]> wrote:
> 

I assume Suhas meant separating the SDP stuff from the SIP stuff. (I also assume he will correct me if I am wrong.)

Thanks,

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Tue, 3 Apr 2018 14:34:20 -0500

> On Apr 3, 2018, at 1:28 PM, Adam Roach <[email-masked]> wrote:
> 
> Like I said originally, none of these are particularly clean. Your proposal points towards either #1 or #3, and I highlighted their drawbacks in my original message.
> 
> Fundamentally, the suggestion Ben made is the only clean one: split trickle-ice-sip into two documents: one deals with SIP (think a parallel to RFC 3261) while the other deals with SDP (think a parallel to RFC 3264). But I also agree with him that sending the document back to the WG for such a split would introduce a significant amount of work.
> 

> It is not just end-of-candidates, but also support for c=0.0.0.0 in offers, SDP offers without the candidates, different mismatch rules. As it stands, draft-ietf-mmusic-trickle-ice-sip changes how…

… and also …

> For instance current in draft-ietf-rtcweb-jsep-24 (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.2.1):
> 
> If the m= section is marked as bundle-only, then the port value MUST be set to 0.  Otherwise, the port value is set to the port of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.
> 
> I am fairly sure this is no longer in ietf-ice-trickle  and was moved to draft-ietf-mmusic-trickle-ice-sip (https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-14#section-4.1.1).

I think maybe we need a sweep of jsep to get a definitive list of references that need to change due the current document structure. Without that list, it’s hard to really assess the amount of work implied by each proposed fix. (Note that we will need such a list one way or another before JSEP can be published—so this does not add new work per se.)

Roman and Peter: Can you compile a list? Perhaps with the assistance of a JSEP author?  (I’d suggest Ekr, but I know that as an AD his time is scarce this week.)

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Apr 2018 20:12:27 +0000

Hi,

>> Fundamentally, the suggestion Ben made is the only clean one: split trickle-ice-sip into two documents: one deals with 
>> SIP (think a parallel to RFC 3261) while the other deals with SDP (think a parallel to RFC 3264). But I also agree with him 
>> that sending the document back to the WG for such a split would introduce a significant amount of work.
>> 
> Roman suggested in a separate thread branch that there is more to this than just "a=end-of-candidates”. Roman said:
>
> It is not just end-of-candidates, but also support for c=0.0.0.0 in offers, SDP offers without the candidates, different mismatch 
> rules. As it stands, draft-ietf-mmusic-trickle-ice-sip changes how draft-ietf-mmusic-ice-sip-sdp works when trickle ICE is used.
>
>… and also …
>
> If the m= section is marked as bundle-only, then the port value MUST be set to 0.  Otherwise, the port value is set to the port 
> of the default ICE candidate for this m= section, but given that no candidates are available yet, the "dummy" port value of 
> 9 (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle], Section 5.1.
> 
> I am fairly sure this is no longer in ietf-ice-trickle  and was moved to draft-ietf-mmusic-trickle-ice-sip 
> (https://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-sip-14#section-4.1.1).

In addition to that, draft-ietf-mmusic-trickle-ice-sip also defines the SDP usage of "a=ice-options:trickle". JSEP currently references draft-ietf-ice-trickle regarding usage of the attribute (see below), but the only thing draft-ietf-ice-trickle does is registering the "trickle" token. 

Examples:

Section 5.2.1 says:

"o  An "a=ice-options" line with the "trickle" option MUST be added,
      as specified in [I-D.ietf-ice-trickle], Section 4."

There is no text about the "trickle" option in Section 4 of draft-ietf-ice-trickle.

Section 5.2.1 also says:

      "If the m= section is marked as bundle-only, then the port value
      MUST be set to 0.  Otherwise, the port value is set to the port of
      the default ICE candidate for this m= section, but given that no
      candidates are available yet, the "dummy" port value of 9
      (Discard) MUST be used, as indicated in [I-D.ietf-ice-trickle],
      Section 5.1."

...and:

   "The m= line MUST be followed immediately by a "c=" line, as specified
   in [RFC4566], Section 5.7.  Again, as no candidates are available
   yet, the "c=" line must contain the "dummy" value "IN IP4 0.0.0.0",
   as defined in [I-D.ietf-ice-trickle], Section 5.1."

There is no text about dummy values (ports or addresses) etc in Section 5.1 of draft-ietf-ice-trickle.

Similar text exists for the answer in section 5.3.1.

Regards,

Christer

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 3 Apr 2018 13:41:29 -0700

On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell <[email-masked]> wrote:

> I assume Suhas meant separating the SDP stuff from the SIP stuff. (I also
> assume he will correct me if I am wrong.)
>
>
That's right Ben .. I was just thinking minimal localized changes (thus
small time to get new draft done) and then asking trickle, trickle-sip to
refer to the new one. (work done to refer is much smaller for these drafts
that are at the very end of approval journey)

I do agree with Adam, no matter what version of the proposal we pick, there
is some work that needs to be done and we
should do it.

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 03 Apr 2018 23:44:32 -0400

> Somewhere along the line, this attribute's definition was moved from there

It seems to me that the problem is that the documents have these
combinations of topics:

    ice-trickle
    ice-sdp-sip
    ice-trickle-sdp-rtcweb
    ice-trickle-sdp-sip

and that the definition of "a=end-of-candidates" is in the domain
ice-trickle-sdp.  Viz., the only documents that include both ice-trickle
and sdp include either rtcweb or sip.  As such, there is no document in
which to place the definition of the attribute on which the documents
that need the attribute can nicely depend.

As Roman says, there's a bunch of "trickle ICE specific SDP related
changes", and they need to go into a document with topic
ice-trickle-sdp.  You could avoid having an additional document by
putting them in an "SDP topics" section of ice-trickle (the section is
ice-trickle-sdp), but Peter notes "IMHO the ICE WG had consensus to
remove all normative SDP references from draft-ietf-ice-trickle and
place them in draft-ietf-mmusic-trickle-ice-sip."

Dale

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Apr 2018 01:11:49 -0400

Dale,

I think the best approach is to treat trickle-ice-sip as an update to
ice-sip-sdp with trickle specific procedures, i.e. make it trickle-ice-sip-sdp.
It seems, no one has a problem that ice-sip-sdp, which deals with both SIP
and SDP specific issues. It should be straight forward to separate generic
SDP issues from SIP specific issues in trickle-ice-sip similar to ice-sip-sdp.
This way we will have nice parallel structure between the base ICE/ICE-SDP
drafts and trickle-ice/tricle-ice-sdp drafts. In any case, I think this
would be cleaner then adding SDP related topics to trickle-ice.

Regards,
_____________
Roman Shpount

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 4 Apr 2018 10:07:39 -0600

On 4/3/18 2:41 PM, Suhas Nandakumar wrote:
> 
> 
> On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell <[email-masked]
>     > On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre <[email-masked] <mailto:[email-masked]>> wrote:
>     >
>     I assume Suhas meant separating the SDP stuff from the SIP stuff. (I
>     also assume he will correct me if I am wrong.)
> 
> 
> refer to the new one. (work done to refer is much smaller for these
> drafts that are at the very end of approval journey)
> 
> I do agree with Adam, no matter what version of the proposal we pick,
> there is some work that needs to be done and we
> should do it.

These documents are on the telechat tomorrow. Are we proposing to delay
consideration by the IESG while we get this mess sorted out? ;-)

Peter

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 4 Apr 2018 16:47:30 +0000

On Apr 3, 2018, at 11:43 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

I think a big part of the RTCWeb/WebRTC community would strongly object to JSEP normatively depending on SIP.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Apr 2018 13:05:54 -0400

On Wed, Apr 4, 2018 at 12:47 PM, Cullen Jennings (fluffy) <[email-masked]>
wrote:

>
> On Apr 3, 2018, at 11:43 AM, Eric Rescorla <[email-masked]> wrote:
>

Do you have any issues with dependency on RFC5245 and the portion of it
which went into draft-mmusic-ice-sip-sdp? Both define SIP procedures in
addition to offer/answer. We are kind of dealing with the same thing here.
Other drafts, like mmusic-dtls-sdp have SIP consideration sections in them.
It did not seem to cause any issues either.

As I have mentioned earlier, I think,  trickle-ice-sip should internally
clearly identify generic offer/answer SDP procedures and SIP specific
considerations. Once it is done it would be no different then all the other
offer/answer drafts we put together recently.
_____________
Roman Shpount

---

From: Ben Campbell <[email-masked]>
Date: Wed, 4 Apr 2018 12:23:04 -0500

> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre <[email-masked]> wrote:
> 

Hi Peter,

I currently plan to leave it on. We may discuss a way forward on the telechat. Also, I’d like to get feedback on the rest of the draft(s) from the other ADs sooner than later.

Thanks!

Ben.

---

From: Thomas Stach <[email-masked]>
Date: Wed, 4 Apr 2018 21:12:50 +0200

Adam,
thanks for the comments.
As your DISCUSS points are already treated on other threads,
There are  just some replies in the comment section below.

> https://datatracker.ietf.org/doc/draft-ietf-mmusic-trickle-ice-sip/
Will remove
> I think what this means to say is "A dialog MUST have been created between the
I'll change to your wording
> that the response has arrived."
Sure, any other request will do the trick as well. However, as it is not 
guaranteed that a request
other than said INFO is sent, I'd prefer to say

"These retransmissions MUST cease on receipt
of an INFO request carrying a 'trickle-ice' Info
  Package body, on receipt any in-dialog request from the offerer or on transmission
of the Answer in a 2xx response. The offerer cannot send in-dialog
requests until it receives a response, so the arrival of such a request proves
that the response has arrived."

> candidates, depending on how the offerer gathers its candidates and how long it
Will add
> Same comment as above for §4.3.2.
sane answer
> think arises when you go to fix the analysis I describe in my DISCUSS above.
Well, the 3PCC is usually in the signaling path and can detect if 
Trickle-ICE is supported at the parties...
However there will certainly appear other corner cases that are not yet 
covered in that section.
Thus, like Ben, I'd also be happy to remove that section, if we get WG 
consensus for doing so.
@Fleming, would you be OK to ask for that?
> I *really* don't want to publish an RFC that demonstrates NATting of IPv6.
I concur with Peter's response on your same comment on draft-ice-trickle 
and use another candidate type for IPv6
Will change to your wording
>>   level, i.e. before any pseudo "m=" line, this indication applies to
Ok, I'll change the address family to IPv4 for the srvflx and add IPv4 
host candidates
Ok. It wasn't intended to disallow usage of Require: Trickle-ice
Ok. I could add (re-using some of your text):
" An Offerer assuming Trickle ICE support MUST include a "Require: 
trickle-ice" header field.
That way, if the provisioned assumption of Trickle ICE support ends up 
being incorrect,
the failure is (a) operationally easy to track down, and (b) recoverable 
by the client,
i.e., they can re-send the request without the Require: header field and 
without the assumption of Trickle ICE support."
Well, the implicit assumption was that the RTCP might have been 
gathered, but not yet been sent to the peer.
If there were sent in a previous INFO they would still need to be included.
I will call this out explicitly
OK
Same handling envisaged as above
I'll remove
I'll change.
I'd go with your proposal
Ok. It wasn't intended to disallow usage of Require: trickle-ice.
I can add this
That note was intended for covering exactly this scenario and catch such 
numbering changes.
Will updated in the revision
thx
thx
thx

Thanks again for the thorough review!
Thomas

---

From: Adam Roach <[email-masked]>
Date: Wed, 4 Apr 2018 14:42:30 -0500

Thanks for your quick responses! Your proposed resolutions all look good 
to me. I notice that you didn't respond to my comment on the "NOTE" in 
§4.4. Should I expect an additional reply to address that comment?

/a

On 4/4/18 2:12 PM, Thomas Stach wrote:
>> Please refer to 
>> https://www.ietf.org/iesg/statement/discuss-criteria.html
> Sure, any other request will do the trick as well. However, as it is 
> not guaranteed that a request
> However there will certainly appear other corner cases that are not 
> yet covered in that section.
> I concur with Peter's response on your same comment on 
> draft-ice-trickle and use another candidate type for IPv6
>>
> the failure is (a) operationally easy to track down, and (b) 
> recoverable by the client,
> i.e., they can re-send the request without the Require: header field 
> and without the assumption of Trickle ICE support."
> That note was intended for covering exactly this scenario and catch 
> such numbering changes.

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 4 Apr 2018 16:56:16 -0400

> @Fleming, would you be OK to ask for that?
Sure - just start a new thread on the MMUSIC list explaining the issue 
and with a clear Subject-line.

Thanks

-- Flemming

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 5 Apr 2018 07:53:52 +0000

Hi,

...

>> Why does this require that specific INFO to stop retransmission? The 
>> only requirement is that the answerer knows that the offerer has 
>> received the provisional response. The offerer cannot send 
>> post-INVITE requests to the answerer until a dialog is established, 
>> and the only ways a dialog can be established at the offerer is 
>> receipt of a provisional or final response. So, as soon as you get 
>> *any* request from the offerer, you know that the provisional 
>> response has arrived.
>>
>> I think this passage means to say "These retransmissions MUST cease 
>> on receipt of any in-dialog request from the offerer. The offerer 
>> cannot send in-dialog requests until it receives a response, so the 
>> arrival of such a request proves that the response has arrived."
>>
> not guaranteed that a request other than said INFO is sent, I'd prefer 
> to say
>
> "These retransmissions MUST cease on receipt of an INFO request 
> carrying a 'trickle-ice' Info
>  Package body, on receipt any in-dialog request from the offerer or on 
> transmission of the Answer in a 2xx response. The offerer cannot send 
> in-dialog requests until it receives a response, so the arrival of 
> such a request proves that the response has arrived."

Do you need to talk about receipt of a body? 

I suggest "on receipt of an INFO request associated with the 'trickle-ice' Info Package".

Regards,

Christer

---

From: Thomas Stach <[email-masked]>
Date: Thu, 5 Apr 2018 21:48:39 +0200

Adam,

On 2018-04-04 21:42, Adam Roach wrote:
> Thanks for your quick responses! Your proposed resolutions all look 
> good to me. 
Thanks!
> I notice that you didn't respond to my comment on the "NOTE" in §4.4. 
> Should I expect an additional reply to address that comment?
Yes, you should.
I was distracted and then ....

<snip/>
As the discussion that led to the text ceased long ago, I would be happy 
to remove the text,
especially as it is just a note.
OK ?

Thanks
Thomas

---

From: Adam Roach <[email-masked]>
Date: Thu, 5 Apr 2018 14:55:09 -0500

On 4/5/18 2:48 PM, Thomas Stach wrote:
> As the discussion that led to the text ceased long ago, I would be 
> happy to remove the text,

I think that would be fine.

/a

---

From: Thomas Stach <[email-masked]>
Date: Thu, 5 Apr 2018 21:55:21 +0200

Christer,

> Do you need to talk about receipt of a body?
I just want to mirror what is specified to be  sent by  the offerer.
An INFO with another body would fall in the "receipt of any in-dialog 
request" bucket
> I suggest "on receipt of an INFO request associated with the 'trickle-ice' Info Package".
I'd prefer not to over-use the verb "associate"

Thanks
Thomas

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 6 Apr 2018 06:52:03 +0000

Hi,

...

> I'd prefer not to over-use the verb "associate"

You can use another word if you want, but my point is that you receive an INFO request associated with the 'trickle-ice' Info Package - whether the INFO contains a body or not is irrelevant.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Apr 2018 12:06:52 +0000

Hi,

>>>>> Just to complete, ice-bis doesn¹t normatively reference ice-sip-SDP
>>>>> draft when it moved to using ³usages ³ indirections for signaling
>>>>>protocols.
>>>>> 
>>>>> 
>I currently plan to leave it on. We may discuss a way forward on the
>telechat. Also, I¹d like to get feedback on the rest of the draft(s) from
>the other ADs sooner than later.

Did you discuss this at the telechat?

Any other discussions on how to move forward with this?

Regards,

Christer

---

From: Ben Campbell <[email-masked]>
Date: Fri, 13 Apr 2018 09:56:02 -0500

> On Apr 13, 2018, at 7:06 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
>>>>>> Just to complete, ice-bis doesnąt normatively reference ice-sip-SDP
>>>>>> draft when it moved to using łusages ł indirections for signaling
>>>>>> protocols.
>>>>>> 
>>>>>> 
>> telechat. Also, Iąd like to get feedback on the rest of the draft(s) from

Yes, Adam and I have been discussing this with the RTCWEB chairs. We’ve since discovered that this is not the only JSEP normative reference chain back to SIP. The RTCWEB chairs are currently discussing whether they can live with that. They may decide to just reference things as they stand. If their answer involves a request to restructure anything, I will pull in the authors and MMUSIC/ICE chairs.

Thanks!

Ben.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 13 Apr 2018 18:29:08 +0000

Hi,

In addition, as I mentioned earlier, there are cases where JSEP references draft-ice-trickle for things and procedures that don’t exist in draft-ice-trickle. Instead those references should be to draft-mmusic-trickle.

Regards,

Christer

Sent from my iPhone

On 13 Apr 2018, at 17.56, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Apr 13, 2018, at 7:06 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>>
wrote:

On Tue, Apr 3, 2018 at 12:22 PM, Ben Campbell <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

Trickle ice can use similar approach and refer to trickle-sip as
usage
for trickle.

That's right Ben .. I was just thinking minimal localized changes (thus
small time to get new draft done) and then asking trickle, trickle-sip
to
refer to the new one. (work done to refer is much smaller for these
drafts that are at the very end of approval journey)

Hi Peter,

Thanks!

Ben.

---

From: Ben Campbell <[email-masked]>
Date: Fri, 13 Apr 2018 14:55:59 -0500

Yes. The question is whether to just move the references in JSEP to point to mmusic-trickle-sip, or do something different.

> On Apr 13, 2018, at 1:29 PM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
> 
> On 13 Apr 2018, at 17.56, Ben Campbell <[email-masked]> wrote:
> 
>> 
>>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 Apr 2018 07:16:48 +0000

Hi,

> Yes. The question is whether to just move the references in JSEP to point to mmusic-trickle-sip, or do something different.

I think it would be good to have a list of all the reference instances that need to be modified.

Regards,

Christer

>>>>> On Apr 4, 2018, at 11:07 AM, Peter Saint-Andre 
>>>>> <[email-masked]>
>>>>> wrote:
>>>>> 
>>>>>>> On Apr 3, 2018, at 2:20 PM, Peter Saint-Andre 
>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>> 
>>>>>>>> Just to complete, ice-bis doesnąt normatively reference 
>>>>>>>> ice-sip-SDP draft when it moved to using łusages ł indirections 
>>>>>>>> for signaling protocols.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Trickle ice can use similar approach and refer to trickle-sip 
>>>>>>>> as usage for trickle.
>>>>>>> 
>>>>>>> It already does. That's why we pulled all the SDP/SIP stuff out 
>>>>>>> of draft-ietf-ice-trickle.
>>>>>> 
>>>>>>  I assume Suhas meant separating the SDP stuff from the SIP 
>>>>>> stuff. (I  also assume he will correct me if I am wrong.)
>>>>>> 
>>>>>> 
>>>>>> That's right Ben .. I was just thinking minimal localized changes 
>>>>>> (thus small time to get new draft done) and then asking trickle, 
>>>>>> trickle-sip to refer to the new one. (work done to refer is much 
>>>>>> smaller for these drafts that are at the very end of approval 
>>>>>> journey)
>>>>>> 
>>>>>> I do agree with Adam, no matter what version of the proposal we 
>>>>>> pick, there is some work that needs to be done and we should do 
>>>>>> it.
>>>>> 
>>>>> These documents are on the telechat tomorrow. Are we proposing to 
>>>>> delay consideration by the IESG while we get this mess sorted out? 
>>>>> ;-)
>>>> 
>>>> Hi Peter,
>>>> 
>>>> I currently plan to leave it on. We may discuss a way forward on 
>>>> the telechat. Also, Iąd like to get feedback on the rest of the 
>>>> draft(s) from the other ADs sooner than later.
>>>

---

From: westhawk <[email-masked]>
Date: Sun, 15 Apr 2018 09:22:56 +0200

> On 13 Apr 2018, at 16:56, Ben Campbell <[email-masked]> wrote:
> 

For what it is worth, I’d argue we can live with it.
My thinking is that having a reference chain back to SIP in the documents reflects
the reality of RTCWeb 1.0 implementations. The SDP is there because it was believed
that using it would make interop with other (typically SIP based) systems easier.

Much of the actual implementations grew out of SIP heritage codebases.

I think it is only reasonable that the documents reflect this reality.

T.

> rtcweb mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/rtcweb <https://www.ietf.org/mailman/listinfo/rtcweb>

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 15 Apr 2018 15:36:01 +0000

Hi,

As far as the MMUSIC ICE and trickle-ICE drafts are concerned, can’t we simply add a sentence to each of those drafts saying something like:

“The SIP procedures and requirements in this specification do not apply to scenarios where the SDP offer/answer procedures are used with other protocols and APIs than SIP.”

Problem solved?

Regards,

Christer

From: westhawk [mailto:[email-masked]]
Sent: 15 April 2018 09:23
To: Ben Campbell <[email-masked]>
Cc: Christer Holmberg <[email-masked]>; [email-masked]; mmusic WG <[email-masked]>; [email-masked]; [email-masked]; The IESG <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-trickle-ice-sip-14: (with DISCUSS and COMMENT)

On 13 Apr 2018, at 16:56, Ben Campbell <[email-masked]<mailto:[email-masked]>> wrote:

Thanks!

Ben.

T.

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb