Subject: [MMUSIC] ICE WG Charter version 2 (Proposed changes)

From: "Pal Martinsen (palmarti)" <[email-masked]>
Date: Fri, 25 Sep 2015 09:18:30 +0000

Hi,

Based on mailing-list discussions i propose the following changes:
(A pull request can be found at: https://github.com/petithug/icewg/pull/5)

- Merge section 1 and 3. Moved former 2 to 1.
Better introduction to what ICE is and having all the history in the same section. The intended effect of the edit is to emphasise the versatility of ICE and maybe attract more “network” people to attend join the wg.

- Rewrote the start of the goal section to pass strict parsers.
“The goal of the ICE Working Group is to consolidate the various initiatives to update and improve ICE, and to help ensure suitability and consistency in the environments ICE operates in.”

I wanted to remove webRTC from the sentence. If WG FOO comes with the same amount of positive energy to help improve ICE  I think it would deserve to get the same amount of attention.

The charter would then look like:

Charter for Working Group

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. It makes no assumptions regarding network topology on the local or remote side.

Interactive Connectivity Establishment was published as RFC 5245 in April 2010. Until recently the protocol had seen rather limited deployment. 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. 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 and improve ICE, and to help ensure suitability and consistency in the environments ICE operates in. 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, PPSP).

.-.
Pål-Erik

---

From: Ari Keränen <[email-masked]>
Date: Fri, 25 Sep 2015 19:05:14 +0300

> (A pull request can be found at: https://github.com/petithug/icewg/pull/5)

This works for me. I added couple of editorial comments in the github 
pull request.

Cheers,
Ari

> Better introduction to what ICE is and having all the history in the
> same section. The intended effect of the edit is to emphasise the
> versatility of ICE and maybe attract more “network” people to attend
> join the wg.
>
> “The goal of the ICE Working Group is to consolidate the various
> initiatives to update and improve ICE, and to help ensure suitability
> and consistency in the environments ICE operates in.”
>
> I wanted to remove webRTC from the sentence. If WG FOO comes with the
> same amount of positive energy to help improve ICE  I think it would
> deserve to get the same amount of attention.
>
>
> 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. It makes no
> assumptions regarding network topology on the local or remote side.
>
> Interactive Connectivity Establishment was published as RFC 5245 in
> April 2010. Until recently the protocol had seen rather limited
> deployment. 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. 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 and improve ICE, and to help ensure suitability
> and consistency in the environments ICE operates in. 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, PPSP).
>
>
> .-.
> Pål-Erik
>
>
>
>
>
>
> _______________________________________________
> Ice mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ice
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Sep 2015 14:54:25 -0500

I think this version looks good enough for the IESG internal review. 
Unless I see an objection really soon now, I will update the charter in 
the datatracker to match.

Thanks!

Ben.

On 25 Sep 2015, at 4:18, Pal Martinsen (palmarti) wrote:

> (A pull request can be found at: 
> https://github.com/petithug/icewg/pull/5)
>
> versatility of ICE and maybe attract more “network” people to 
> attend join the wg.
>
> multiplicity of IP addresses and ports in both the request and 
> response messages of a connectivity establishment transaction. It 
> makes no assumptions regarding network topology on the local or remote 
> side.
>
> 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).
>
> 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.
>
> 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, PPSP).
>
>
> .-.
> Pål-Erik
>
>
>
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 28 Sep 2015 20:27:51 -0500

I went ahead and updated this in the tracker, since the IESG review is 
coming up soon. I made a few of very minor edits. Please take a look and 
let me know asap if anything doesn't look right.

http://datatracker.ietf.org/doc/charter-ietf-ice/

Thanks!

Ben.

On 28 Sep 2015, at 14:54, Ben Campbell wrote:

> Unless I see an objection really soon now, I will update the charter 
> in the datatracker to match.
>
>
> Thanks!
>
> Ben.
>
>> 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 
>> makes no assumptions regarding network topology on the local or 
>> remote side.
>>
>> deployment. This situation has changed drastically as ICE is 
>> mandatory to implement
>> 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).
>>
>> 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

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 29 Sep 2015 04:36:08 -0600

Looks good to me.

Thanks.

On 09/28/2015 07:27 PM, Ben Campbell wrote:
> I went ahead and updated this in the tracker, since the IESG review is coming up soon. I made a few of very minor edits. Please take a look and let me know asap if anything doesn't look right.
> 
>> I think this version looks good enough for the IESG internal review. Unless I see an objection really soon now, I will update the charter in the datatracker to match.
>>
>>
>> Thanks!
>>
>> Ben.
>>

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 30 Sep 2015 17:04:50 +0200

I like this charter.

Only one linguistic comment:

"It is worth noticing that this
> mobile environments without major changes to the original ICE RFC."

Everything before "this work" is linguistic fluff. Can we simply say
"This work will make ICE ...."?