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

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

On 4/3/18 11:55 AM, Ben Campbell wrote:
>
>> On Apr 3, 2018, at 11:22 AM, Peter Saint-Andre <[email-masked]> wrote:
>>
>> + ICE WG to address the cross-document DISCUSS only.
>>
>> On 4/3/18 1:29 AM, Adam Roach wrote:
>>
>> <snip/>
>>
>>> 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.
>> 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?
> 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: 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: 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:
> 
> 
> 
> On Tue, Apr 3, 2018 at 10:38 AM, Roman Shpount <[email-masked]> wrote:
> 
> 
> 
> On Tue, Apr 3, 2018 at 1:26 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> On Tue, Apr 3, 2018 at 10:24 AM, Adam Roach <[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: 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: 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: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: 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: 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: 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

---

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