Re: [MMUSIC] [Ice] New version of the proposed charter

"Ben Campbell" <ben@nostrum.com> Wed, 09 September 2015 17:55 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383231B4101; Wed, 9 Sep 2015 10:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3CQvU3KQafqV; Wed, 9 Sep 2015 10:55:38 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D46931B40F5; Wed, 9 Sep 2015 10:55:25 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id t89Ht2al082419 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 9 Sep 2015 12:55:12 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Marc Petit-Huguenin <petithug@acm.org>
Date: Wed, 09 Sep 2015 12:55:02 -0500
Message-ID: <D08F05FD-1475-4F2B-BB23-894187D30E6A@nostrum.com>
In-Reply-To: <55E6E9AE.7080400@acm.org>
References: <55E6E9AE.7080400@acm.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Mailer: MailMate (1.9.2r5107)
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/e5bDiBkRlJJZEXuFAraGWRn1hJA>
Cc: DISPATCH list <dispatch@ietf.org>, mmusic@ietf.org, ice@ietf.org
Subject: Re: [MMUSIC] [Ice] New version of the proposed charter
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Sep 2015 17:55:40 -0000

Comments inline:

On 2 Sep 2015, at 7:21, Marc Petit-Huguenin wrote:

> Please find below a new version of the proposed charter, trying to 
> take in account all the comments so far.
>
> The discussions are taking place in the ice mailing-list, please do 
> not cross-post.
>
> Thanks.
>
> - 
> ---------------------------------------------------------------------------------
>
> 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.

I'd like to see more specifics here. There are three milestones--the 
charter text should describe the work items supported by those 
milestones and expected output. If those milestones are assumed to be 
based on existing drafts, please name them.

We also need to be clear on how open or closed ended this is. Is the 
goal to finish specific work and close?
Or do you expect the wg to add new work items in the future as new ICE 
requirements become apparent? (Note that a "standing" maintenance 
working group may get more charter scrutiny than one intended to finish 
and close.)


> 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 
> synchronised with the work in this working group. Synching with other 
> network related working groups to make sure existing mechanisms like 
> QoS, congestion control and other networking mechanisms still work 
> would be essential if we want to improve how ICE works (MIF, TAPS, 
> TSWG, HOMENET, etc...). 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 essential 
> (RTCWEB, HIP, MMUSIC, P2PSIP).
>
> Milestones
>
>  Jun 2016 Submit Dual-stack Fairness with ICE as Proposed Standard
>  Apr 2016 Submit a revision of ICE (RFC 5245) as Proposed Standard
>  Jan 2016 Submit Trickle ICE as Proposed Standard
>
> - --
> Marc Petit-Huguenin
> Email: marc@petit-huguenin.org
> Blog: http://blog.marc.petit-huguenin.org
> Profile: http://www.linkedin.com/in/petithug
>
> _______________________________________________
> Ice mailing list
> Ice@ietf.org
> https://www.ietf.org/mailman/listinfo/ice