Subject: Re: [MMUSIC] [Ice] Updated charter

From: "Ben Campbell" <[email-masked]>
Date: Tue, 22 Sep 2015 12:38:01 -0500

Hi,

If we hope to have ICE approved as a working group in time for Yokohama, 
we would need to start the IESG internal review by this Thursday. IMO, 
this language is about right. I think there's still an open issue about 
where the SDP bit lives. Can we close on that?

Thanks!

Ben.

On 16 Sep 2015, at 7:17, Pal Martinsen (palmarti) wrote:

> Hi,
>
> Based on list discussion the charter is now updated.
> For the github draft enthusiasts out there the pull request can be 
> found at:
> https://github.com/petithug/icewg/pulls.
>
> —————— Start —————-
> Charter for Working Group
>
> Interactive Connectivity Establishment was published as RFC 5245 in 
> April 2010. Until recently the protocol had seen rather limited 
> deployment. ICE was slow to achieve widespread adoption, as other 
> mechanisms were already being used by the VoIP industry. This 
> situation has changed drastically as ICE is mandatory to implement in 
> WebRTC, a set of technologies developed at the IETF and W3C to 
> standardize Real Time Communication on the Web.
>
> Interactive Connectivity Establishment (ICE) is at the same time a NAT 
> traversal technique, a multihomed address selection technique, and a 
> dual stack address selection technique that works by including a 
> multiplicity of IP addresses and ports in both the request and 
> response messages of a connectivity establishment transaction.  The IP 
> addresses and ports provided by each side are paired and tested by 
> peer-to-peer connectivity checks until one of these pair is selected 
> to transport data. ICE follows the end to end principle where the 
> clients themselves discovers, test and choose the network path to use. 
> It makes no assumptions regarding network topology on the local or 
> remote side.
>
> ICE was originally defined for the Offer-Answer (RFC 3264) protocol 
> used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP 
> (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and 
> other realtime media establishment protocol have used the protocol. 
> ICE is also used by non-realtime media protocols, like HIP (RFC 5770) 
> and RELOAD (RFC 6940).
>
> The goal of the ICE Working Group is to consolidate the various 
> initiatives to update ICE to make it more suitable for the WebRTC 
> environment but also to all the current usages of ICE. Current work in 
> this area includes an updated version of the ICE RFC (ICEbis), Trickle 
> ICE and dualstack/multihomed fairness. It is worth noticing that this 
> work will make ICE more flexible, robust and more suitable for 
> changing mobile environments without major changes to the original ICE 
> RFC. The ICE workgroup will consider new work items that follow this 
> pattern.
>
> ICE is an application controlled protocol that leverages a set of 
> network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and 
> related protocol work done in the TRAM working group must be closely 
> synchronized with the work in this working group. To avoid 
> interoperability issues and unwanted behavior it is desired to 
> increase the interaction with other working groups dealing with 
> network protocols closer to the wire. Example of such work may be, but 
> not limited to; issues regarding multi-homing, multi subnet and 
> prefixes, QoS, transport selection and congestion control. From the 
> application side, the users of ICE, there is a need to make sure what 
> is specified is actually usable. Getting input from the application 
> working groups will be helpful (RTCWEB, HIP, MMUSIC, P2PSIP).
>
>
>
> Milestones
>
> - Jan 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
> draft-ietf-mmusic-ice-dualstack-fairness
> - Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
> draft-ietf-mmusic-rfc5245bis
> (draft-ietf-mmusic-ice-sip-sdp remains in MMUSIC)
> - Jan 2016 Submit Trickle ICE as Proposed Standard
> draft-ietf-mmusic-trickle-ice
> (draft-ietf-mmusic-trickle-ice-sip remains in MMUSIC)
>
> ————— STOP ———————
>
> .-.
> Pål-Erik
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice

---

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Tue, 22 Sep 2015 17:51:46 +0000

> On 22 Sep 2015, at 19:38, Ben Campbell <[email-masked]> wrote:
> 
> Hi,
> 
> If we hope to have ICE approved as a working group in time for Yokohama, we would need to start the IESG internal review by this Thursday. IMO, this language is about right. I think there's still an open issue about where the SDP bit lives. Can we close on that?

I think the arguments can be summarised as follows.

- Keeping SDP in MMUSIC helps ICE focus on core ICE things
- MMUSIC has a lot of SDP knowledge needed to get things right

I support keeping ICE in ICE and SDP in MMUSIC.

.-.
Pål-Erik

>> For the github draft enthusiasts out there the pull request can be found at:
>> Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. ICE was slow to achieve widespread adoption, as other mechanisms were already being used by the VoIP industry. This situation has changed drastically as ICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web.
>> 
>> Interactive Connectivity Establishment (ICE) is at the same time a NAT traversal technique, a multihomed address selection technique, and a dual stack address selection technique that works by including a multiplicity of IP addresses and ports in both the request and response messages of a connectivity establishment transaction.  The IP addresses and ports provided by each side are paired and tested by peer-to-peer connectivity checks until one of these pair is selected to transport data. ICE follows the end to end principle where the clients themselves discovers, test and choose the network path to use. It makes no assumptions regarding network topology on the local or remote side.
>> 
>> ICE was originally defined for the Offer-Answer (RFC 3264) protocol used by SIP (RFC 3261). Later XMPP (XEP-0176), RTSP (draft-ietf-mmusic-rtsp-nat), RTCWeb (draft-ietf-rtcweb-jsep) and other realtime media establishment protocol have used the protocol. ICE is also used by non-realtime media protocols, like HIP (RFC 5770) and RELOAD (RFC 6940).
>> 
>> The goal of the ICE Working Group is to consolidate the various initiatives to update ICE to make it more suitable for the WebRTC environment but also to all the current usages of ICE. Current work in this area includes an updated version of the ICE RFC (ICEbis), Trickle ICE and dualstack/multihomed fairness. It is worth noticing that this work will make ICE more flexible, robust and more suitable for changing mobile environments without major changes to the original ICE RFC. The ICE workgroup will consider new work items that follow this pattern.
>> 
>> ICE is an application controlled protocol that leverages a set of network defined protocols. The STUN (RFC 5389), TURN (RFC 5766) and related protocol work done in the TRAM working group must be closely synchronized with the work in this working group. To avoid interoperability issues and unwanted behavior it is desired to increase the interaction with other working groups dealing with network protocols closer to the wire. Example of such work may be, but not limited to; issues regarding multi-homing, multi subnet and prefixes, QoS, transport selection and congestion control. From the application side, the users of ICE, there is a need to make sure what is specified is actually usable. Getting input from the application working groups will be helpful (RTCWEB, HIP, MMUSIC, P2PSIP).
>> 
>> 
>> 
>> Milestones
>>

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 23 Sep 2015 11:20:49 -0500

On 22 Sep 2015, at 12:51, Pal Martinsen (palmarti) wrote:

>> If we hope to have ICE approved as a working group in time for 
>> Yokohama, we would need to start the IESG internal review by this 
>> Thursday. IMO, this language is about right. I think there's still an 
>> open issue about where the SDP bit lives. Can we close on that?
>

Does anyone still object to keeping the SDP part in MMUSIC?

>>> situation has changed drastically as ICE is mandatory to implement 
>>> in WebRTC, a set of technologies developed at the IETF and W3C to 
>>> Interactive Connectivity Establishment (ICE) is at the same time a 
>>> NAT traversal technique, a multihomed address selection technique, 
>>> and a dual stack address selection technique that works by including 
>>> a multiplicity of IP addresses and ports in both the request and 
>>> response messages of a connectivity establishment transaction.  The 
>>> IP addresses and ports provided by each side are paired and tested 
>>> by peer-to-peer connectivity checks until one of these pair is 
>>> selected to transport data. ICE follows the end to end principle 
>>> where the clients themselves discovers, test and choose the network 
>>> path to use. It makes no assumptions regarding network topology on 
>>> the local or remote side.
>>>
>>> ICE is also used by non-realtime media protocols, like HIP (RFC 
>>> 5770) and RELOAD (RFC 6940).
>>>
>>> environment but also to all the current usages of ICE. Current work 
>>> in this area includes an updated version of the ICE RFC (ICEbis), 
>>> Trickle ICE and dualstack/multihomed fairness. It is worth noticing 
>>> that this work will make ICE more flexible, robust and more suitable 
>>> for changing mobile environments without major changes to the 
>>> original ICE RFC. The ICE workgroup will consider new work items 
>>> that follow this pattern.
>>>
>>> network protocols closer to the wire. Example of such work may be, 
>>> but not limited to; issues regarding multi-homing, multi subnet and 
>>> application side, the users of ICE, there is a need to make sure 
>>> what is specified is actually usable. Getting input from the 
>>> application working groups will be helpful (RTCWEB, HIP, MMUSIC, 
>>> P2PSIP).
>>>
>>>
>>>
>>> Milestones
>>>
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Ari Keränen <[email-masked]>
Date: Wed, 23 Sep 2015 22:40:06 +0300

On 22/09/15 20:51, Pal Martinsen (palmarti) wrote:
>> If we hope to have ICE approved as a working group in time for Yokohama,we would need to start the IESG internal review by this Thursday. IMO, this language is about right. I think there's still an open issue about where the SDP bit lives. Can we close on that?
>

I agree that a focused ICE group is a good idea. And there are already 
many "core" items the group will potentially start working on, so 
reducing the amount of extra items is in general a good idea.

One point made at the Prague meeting for having also ICE SDP in ICE WG 
is that often SDP related to a protocol has been done jointly in the WG 
defining the protocol and SDP directorate has been used to make sure the 
SDP parts get proper review. On the other hand, now protocols using 
*ICE* would be done in different WGs, so perhaps MMUSIC with SDP should 
be considered as such.

Regarding the charter text, I think it looks good, but I'm not sure if 
we need the first "history" paragraph. Maybe rather mentioned WebRTC and 
it's key role only with other protocols in the later paragraph?

Cheers,
Ari

>>> Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. ICE was slow to achieve widespread adoption, as other mechanisms were alreadybeing used by the VoIP industry. This situation has changed drastically asICE is mandatory to implement in WebRTC, a set of technologies developed at the IETF and W3C to standardize Real Time Communication on the Web.
>>>
>>> The goal of the ICE Working Group is to consolidate the various initiatives to update ICE to make it more suitable for the WebRTC environment but also to all the current usages of ICE. Current work in this area includes an updated version of the ICE RFC (ICEbis), Trickle ICE and dualstack/multihomed fairness. It is worth noticing that this work will make ICE more flexible, robust and more suitable for changing mobile environments without major changes to the original ICE RFC. The ICE workgroup will consider new workitems that follow this pattern.
>>>

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Sep 2015 09:48:04 -0400

Hi Everyone,

I put the latest charter text and milestones from gitbub into the 
datatracker at https://datatracker.ietf.org/doc/charter-ietf-ice/ . I 
plan to put this into IESG internal review, and on the next IESG 
telechat.

  I know there's still a conversation going on about where to put the 
SDP bits. Please continue that conversation; hopefully we can close on 
it before the telechat.

Thanks!

Ben.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 24 Sep 2015 09:08:46 -0600

On 9/24/15 7:48 AM, Ben Campbell wrote:
> plan to put this into IESG internal review, and on the next IESG telechat.

This sentence doesn't pass my grammar parser:

    The goal of the ICE Working Group is to consolidate the various
    initiatives to update ICE to make it more suitable for the WebRTC
    environment but also to all the current usages of ICE.

"but also to all"? To address or to document or to ensure consistency 
with or something like that?

Peter

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Sep 2015 11:11:51 -0400

[Oops, forgot the ICE list. Sorry for the repeat]

Hi Everyone,

Thanks!

Ben.

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Sep 2015 11:12:23 -0400

On 23 Sep 2015, at 15:38, Ari Keränen wrote:

> we need the first "history" paragraph. Maybe rather mentioned WebRTC 
> and it's key role only with other protocols in the later paragraph?

On a related note: Barry commented that paragraphs 2 and 3 seem 
unnecessary for the charter. I tend to agree. But if were were to remove 
those, I think paragraph 1 would become more important.

Thoughts?

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 24 Sep 2015 09:19:40 -0600

> those, I think paragraph 1 would become more important.

IMHO those paragraphs provide useful context (especially for readers who 
are not deeply familiar with ICE and its history and uses). However, we 
could probably live without them, too.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 24 Sep 2015 11:45:13 -0400

On 24 Sep 2015, at 11:19, Peter Saint-Andre - &yet wrote:

> IMHO those paragraphs provide useful context (especially for readers 
> who are not deeply familiar with ICE and its history and uses). 
> However, we could probably live without them, too.

(as individual)

I think paragraph 2 goes deeper into explaining what ICE is than is 
needed--perhaps it could be pared down. Paragraph 3 is more about the 
history and relation to other work. That might have more value for a 
charter.

Ben.