[homegate] homegate Working Group charter approved
Ralph Droms <rdroms.ietf@gmail.com> Thu, 14 July 2011 16:43 UTC
Return-Path: <rdroms.ietf@gmail.com>
X-Original-To: homegate@ietfa.amsl.com
Delivered-To: homegate@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D86F21F8D31; Thu, 14 Jul 2011 09:43:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.999
X-Spam-Level:
X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAuV312uOszF; Thu, 14 Jul 2011 09:43:53 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4377621F8D1D; Thu, 14 Jul 2011 09:43:53 -0700 (PDT)
Received: by iye7 with SMTP id 7so434472iye.31 for <multiple recipients>; Thu, 14 Jul 2011 09:43:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=2zkwftcCP9cAx81H2/2EaWxx4M1QnKYQhbCDpjzKVRg=; b=RCVM9xFkrPBTVDoGKGL1ptH2CmyC01obawQKEfAqu8EaQ1PrsLul4IjnDH02f6quK3 KBfHuGOzElGQvsbNbXN9YYWhkdWoNZAXTOWNbazJjDRXrEzH0gq7pLB4KVoaicLwU9Iy V+Bk1vlyR1Lordqv37E11Q/VDujb3n8HUTeFc=
Received: by 10.231.81.18 with SMTP id v18mr2216713ibk.42.1310661832734; Thu, 14 Jul 2011 09:43:52 -0700 (PDT)
Received: from sjc-vpnasa-468.cisco.com (128-107-239-233.cisco.com [128.107.239.233]) by mx.google.com with ESMTPS id d5sm244544ibi.11.2011.07.14.09.43.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 14 Jul 2011 09:43:51 -0700 (PDT)
From: Ralph Droms <rdroms.ietf@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 14 Jul 2011 12:43:48 -0400
Message-Id: <ABCB6171-6FC6-425F-8E37-04D3B25950CC@gmail.com>
To: homegate@ietf.org
Mime-Version: 1.0 (Apple Message framework v1084)
X-Mailer: Apple Mail (2.1084)
Cc: The IESG <iesg@ietf.org>
Subject: [homegate] homegate Working Group charter approved
X-BeenThere: homegate@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Broadband Home Gateway Discussion <homegate.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homegate>, <mailto:homegate-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/homegate>
List-Post: <mailto:homegate@ietf.org>
List-Help: <mailto:homegate-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homegate>, <mailto:homegate-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Jul 2011 16:43:54 -0000
All - I had a brief moment of brain-lockup (helped along by e-mail autocompletion). This message was intended to announce the approval of the homenet WG. Please ignore anything I might have said about homegate... - Ralph ===== The IESG approved the formation of the homegate Working Group during today's telechat. The WG's first meeting will be in Quebec, as shown in the IETF-81 meeting agenda. The initial charter for the WG is included below. Mark Townsley has agreed to be one of the WG co-chairs (thanks, Mark!). We will be choosing a second co-chair soon, so please let Jari and me know if you're interested in taking on that role. Mark will start a thread here soon to develop the agenda for the upcoming WG meeting. Thanks to all of you who have been following the development of the WG and especially for the enthusiastic discussion about the charter. We're counting on all of you to continue your contributions to the success of the WG. - Ralph Droms Internet Area Director Home Networks (homenet) ----------------------------------- Current Status: Proposed Last Edit: Wednesday, July 14th, 2011 Chairs: "W. Mark Townsley" <townsley@cisco.com> Internet Area Directors: Ralph Droms <rdroms.ietf@gmail.com> Jari Arkko <jari.arkko@piuha.net> Internet Area Advisor: Ralph Droms <rdroms.ietf@gmail.com> Routing Area Technical Advisor: TBD Security Area Technical Advisor: TBD Mailing Lists: General Discussion: fun@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/fun Archive: http://www.ietf.org/mail-archive/web/fun Description of Working Group: This working group focuses on the evolving networking technology within and among relatively small "residential home" networks. For example, an obvious trend in home networking is the proliferation of networking technology in an increasingly broad range and number of devices. This evolution in scale and diversity sets some requirements on IETF protocols. Some of the relevant trends include: o Multiple segments: While less complex L3-toplogies involving as few subnets as possible are preferred in home networks for a variety of reasons including simpler management and service discovery, the introduction of more than one subnet into a home network is enough to add complexity that needs to be addressed, and multiple dedicated segments are necessary for some cases. For instance, a common feature in modern home routers in the ability to support both guest and private network segments. Also, link layer networking technology is poised to become more heterogeneous, as networks begin to employ both traditional Ethernet technology and link layers designed for low-powered sensor networks. Finally, similar needs for segmentation may occur in other cases, such as separating building control or corporate extensions from the Internet access network for the home. Different segments may be associated with subnets that have different routing and security policies. o Service providers are deploying IPv6, and support for IPv6 is increasingly available in home gateway devices. While IPv6 resembles IPv4 in many ways, it changes address allocation principles and allows direct IP addressability and routing to devices in the home from the Internet. This is a promising area in IPv6 that has proved challenging in IPv4 with the proliferation of NAT. o End-to-end communication is both an opportunity and a concern as it enables new applications but also exposes nodes in the internal networks to receipt of unwanted traffic from the Internet. Firewalls that restrict incoming connections may be used to prevent exposure, however, this reduces the efficacy of end-to-end connectivity that IPv6 has the potential to restore. Home networks need to provide the tools to handle these situations in a manner accessible to all users of home networks. Manual configuration is rarely, if at all, possible, as the necessary skills and in some cases even suitable management interfaces are missing. The purpose of this working group is to focus on this evolution, in particular as it addresses the introduction of IPv6, by developing an architecture addressing this full scope of requirements: o prefix configuration for routers o managing routing o name resolution o service discovery o network security The task of the group is to produce an architecture document that outlines how to construct home networks involving multiple routers and subnets. This document is expected to apply the IPv6 addressing architecture, prefix delegation, global and ULA addresses, source address selection rules and other existing components of the IPv6 architecture, as appropriate. The architecture document should drive what protocols changes, if any, are necessary. Specific protocol work described below is expected to be within the scope of the working group once the architecture work is complete. However, the group is required to review its charter and milestones with the IESG and IETF community before submitting documents that make protocol changes. It is expected that the group has to discuss some of the below solutions, however, in order to complete the architecture work. The group will apply existing protocols to handle the five requirements above. For prefix configuration, existing protocols are likely sufficient, and at worst may need some small enhancements, such as new options. For automatic routing, it is expected that existing routing protocols can be used as is, however, a new mechanism may be needed in order to turn a selected protocol on by default. For name resolution and service discovery, extensions to existing multicast-based name resolution protocols are needed to enable them to work across subnets. For network security, the group shall document the concept of "advanced security" as a further development of "simple security" from RFC 6092. The main goal of this work is to enable a security policy that adapts to IPv6 threats as they emerge, taking into account not only traffic from the Internet at large, but within and leaving the home network itself. It is expected that the working group will define a set of protocol specifications to accomplish the five requirements from above. However, it is not in the scope of the working group to define entirely new routing protocols or address allocation protocols. As noted, additional options or other small extensions may be necessary to use the existing protocols in these new configuration tasks. The working group shall also not make any changes to IPv6 protocols or addressing architecture. Prefix configuration, routing, and security related work shall not cause any changes that are not backwards compatible to existing IPv6 hosts. There may be host visible changes in the work on naming and discovery protocols, however. In its design, the working group shall also consider security aspects and the impact on manageability. The main focus of the working group is home networks, but the group's results may also find applications in other small networks. The group should assume that an IPv4 network may have to co-exist alongside the IPv6 network and should take this into account insofar as alignment with IPv6 is desirable. But the group should also ensure that even IPv6-only are possible, and while IP-version agnostic work is of course desirable, IPv4-specific work is outside the scope of the group. The working group will liaise with the relevant IETF working groups. In particular, the group should work closely with the V6OPS working group, review any use or extension of DHCP with the DHC working group, and work with additional DNS requirements with the DNSEXT and DNSOP working groups. If it turns out that additional options are needed for a routing protocol, they will be developed in the appropriate Routing Area working group, with the HOMENET working group providing the architecture and requirements for such enhancements. The working group will also liason with external standards bodies where it is expected that there are normative dependencies between the specifications of the two bodies. It is expected that in the architecture definition stage liaising with the Broadband Forum, DLNA, and UPnP Forum is necessary, as is understanding existing technology from these groups. Milestones: Jul 2011 Formation of the working group Sep 2011 First WG draft on the architecture Dec 2011 Submission of the architecture draft to the IESG as Informational RFC Dec 2011 Charter re-evaluation based on the architecture work Dec 2011 First WG draft on prefix configuration Dec 2011 First WG draft on routing Jan 2012 First WG draft on name resolution Feb 2012 First WG draft on service discovery Feb 2012 First WG draft on perimeter security Feb 2012 Start of routing related work in the relevant routing area working group, if needed Mar 2012 Submission of the prefix configuration draft to the IESG as Standards Track RFC Apr 2012 Submission of the routing draft to the IESG as Informational RFC Sep 2012 Submission of the name resolution draft to the IESG as Standards Track RFC Nov 2012 Submission of the service discovery draft to the IESG as Standards Track RFC Dec 2012 Submission of the perimeter security draft to the IESG as Informational RFC
- [homegate] homegate Working Group charter approved Ralph Droms
- Re: [homegate] homegate Working Group charter app… Mark Townsley
- [homegate] homegate Working Group charter approved Ralph Droms